...
Some Kmehr elements of the response have a meaning in the context of future manipulation of the medication scheme:
| Transaction | Element | Meaning | Store for later use? | Extra information |
|---|---|---|---|---|
| MS | id | S="ID-KMEHR" This is a unique Kmehr-identifier for the transaction within the transactionset. | NO | |
S="LOCAL" SL="vitalinkuri" This is the unique Vitalink-identifier for the MS transaction. | YES | This is the same value as the Vitalink-identier retrieved with getTransactionList. | ||
| MSE/TS | id | S="ID-KMEHR" This is a unique Kmehr-identifier for the transaction within the transactionset. | NO | Although storage is not needed for the web service manipulation flow, it is off course needed to know the link between TS transactions and the MSE transactions they poin to. |
S="LOCAL" SL="vitalinkuri" This is the unique Vitalink-identifier for the MSE/TS transaction. | YES |
Update a medication scheme
Updating a medication scheme means doing putTransactionSetRequest for a specific patient and with the id of the needed transaction MS.
| Note |
|---|
The number of MS MSE transactions in the kmehrmessage of a PutTransactionSetRequest should not exceed 100. The TS transactions are not taken into account for this maximum. |
In this set of transactions, MSE/TS transactions can be manipulated as follows:
Manipulation of MS/TSE transaction | Description |
|---|---|
| create | A new MS/TSE transaction is added to the set. Please refer to the paragraph below how created MS/TSE transactions are structured. |
| delete | The MS/TSE transaction that needs to be deleted is not present anymore in the <kmehrmessage> of the putTransactionSetRequest. |
| update | The MS/TSE transaction that needs to be updated is present in the <kmehrmessage> of the putTransactionSetRequest. Please refer to the paragraph below how updated MS/TSE transactions are structured. |
| preserve | The MS/TSE transaction that needs to be preserved is present in the <kmehrmessage> of the putTransactionSetRequest, and is an exact copy of the earlier read transaction. |
The MS transaction itself must also be passed as input for the putTransactionSetRequest.
| Element | Meaning | Extra information | ||||
|---|---|---|---|---|---|---|
| author | The author of the manipulation of the transaction set. | It is good practice to provide the author information of the user of the application. However, the Vitalink gateway will generate this information based on the used session certificates. | ||||
iscomplete | This is not used in the Vitalink business flow. | It is good practice to hard code this to "true". | ||||
isvalidated | This is not used in the Vitalink business flow. | It is good practice to hard code this to "true". | ||||
| version | The version of the medication scheme on which this manipulation is based. | An application must pass here the value that was earlier read in the reading sequence. The are several ways to retrieve the correct input value:
|
Here an example of an updated MS transaction:
...
An MSE/TS transaction needs to be composed, compliant to the structure described in M. Kmehrmessage Structure, where the following elements have a specific meaning:
| Element | Meaning | Extra information | |||||
|---|---|---|---|---|---|---|---|
| id S="ID-KMEHR" | A unique Kmehr-identifier that distinguishes this transaction from all others. | This does not need to be the same value from the orginally read one. However make sure the relations between TS and MSE transactions are not broken. | |||||
| id S="LOCAL" SL="vitalinkuri" | This should not be present! | Absence of this id means for Vitalink that this is a newly created transaction.
| |||||
| date | Date of creation | Typically, the creating application should choose "today". | |||||
| time | Time of creation | Typically, the creating application should choose "now". | |||||
| author | The author of the manipulation of the transaction set. | It is good practice to provide the author information of the user of the application. However, the Vitalink gateway will generate this information based on the used session certificates. | |||||
iscomplete | This is not used in the Vitalink business flow. | It is good practice to hard code this to "true". | |||||
isvalidated | This is not used in the Vitalink business flow. | It is good practice to hard code this to "true". |
Here an example of a created MS transaction:
...
An earlier MSE/TS transaction needs to be adapted, compliant to the structure described in M. Kmehrmessage Structure, where the following elements have a specific meaning:
| Element | Meaning | Extra information | |||||
|---|---|---|---|---|---|---|---|
| id S="ID-KMEHR" | A unique Kmehr-identifier that distinguishes this transaction from all others. | This does not need to be the same value from the orginally read one. However make sure the relations between TS and MSE transactions are not broken. | |||||
| id S="LOCAL" SL="vitalinkuri" | The unique identifier provided by Vitalink that distinguishes the MSE transaction from all other MSE transactions and the TS . | This need to be the same value from the orginally read one, in other words Vitalink needs to know which transaction needs to be updated.
| |||||
| date | Date of creation | Typically, the creating application should choose "today". | |||||
| time | Time of creation | Typically, the creating application should choose "now". The fact that the date and time are more recent than the original ones means for Vitalink that this is an updated transaction. | |||||
| author | The author of the manipulation of the transaction set. | It is good practice to provide the author information of the user of the application. However, the Vitalink gateway will generate this information based on the used session certificates. | |||||
iscomplete | This is not used in the Vitalink business flow. | It is good practice to hard code this to "true". | |||||
isvalidated | This is not used in the Vitalink business flow. | It is good practice to hard code this to "true". |
Here an example of an updated MS transaction:
...