Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

EVS2 will work with Kmehrmessages of Kmehr-standard 20120401 and Kmehr-standard 20161201. It will automatically convert Kmehrmessages of Kmehr-standard 20120401 to Kmehr-standard 20160401.

All other data (among which the metadata) will be generated by the EVS EVS2 and/or the Vitalink platform. As input the business data as depicted in blue here below will be used:

Image Removed

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------

How is a Kmehrmessage identified?

For some actions, typically removing and updating data entries, the input Kmehrmessage needs to have an identification.

There are 2 ways to identify Kmehrmessages:

  • by Vitalink ID,
  • by EVS reference.
Identification by Vitalink ID

The Kmehrmessage should be preceeded by a Vitalink URI.

The Vitalink ID can not be chosen by the sender when adding new data entries, but are dynamically generated by the Vitalink platform. By consequence, they are not deterministic and are hard to use when defining scenarios.

In the next example, this URI is /subject/83051839468/medication-scheme/32055/1. EVS detects the reserved format  "/subject/###########/medication-scheme/32055" and finally uses "32055" as unique ID.

Image Removed

Identification by EVS reference

An EVS reference is put in 1 (and only 1) free text field in the concerned Kmehrmessage.

The EVS reference can be freely chosen, and facilitates the definition and execution of scenarios.

In the next example, this REF is "===EVSREF:901===". EVS detects the reserved format  "===EVSREF:<any text>===" and finally uses "<any text>" as unique REF.

As from EVS 2 the REF must contain a minimum of 3 characters and can contain up to 512 characters, so both ===EVSREF:123=== and ===EVSREF:A123456789B123456789=== are considered valid REFs.

Image Removed

Which actions?

Depending on the folder where the input-file is dropped, EVS2 will execute an action.

Action "add"

This action will add a data entry to the vault for each Kmehrmessage found in all dropped files.

In the example below, 3 Kmehrmessages are dropped to be added to the vault: -------------------- IMAGE TO BE CHANGED

Image Removed

Action "empty"

This action will remove all data entries from the vault. EVS2 will do this action once for each dropped file, without any parsing. 

In the example below, a newly created file will trigger emptying of the vault by removing all existing data entries: ---------------- IMAGE TO BE CHANGED

Image Removed

Action "export"

This action will export the contents of the vault, without any change to the vault itself. EVS2 will do this action once for each dropped file, without parsing this file.

In the example below, a newly created file will trigger an export of the contents of the vault: ------------------ IMAGE TO BE CHANGED

Image Removed

Action "replace"

This action will replace the contents of the vault by all the Kmehrmessages found in the input file. Be aware of the fact that dropping multiple files in the replace-folder will result in a vault with as contents the Kmehrmessages of the last input file!

In the next example, after processing the next 3 input files, the vault contains 2 data entries. ---------------------- IMAGE TO BE CHANGED

Image Removed

...

Image Added

How is a transaction within a Kmehrmessage identified?

For some actions, typically removing and updating data entries, the transaction that should be changed needs to have an identification and it has to be of type medicationschemeelement. Those transactions are identified by using an EVS reference.

Identification by EVS reference

An EVS reference is put in 1 (and only 1) free text field in the concerned transaction.

The EVS reference can be freely chosen, and facilitates the definition and execution of scenarios.

In the next example, this REF is "===EVSREF:901===". EVSg detects the reserved format  "===EVSREF:<any text>===" and finally uses "<any text>" as unique REF.

The REF must contain a minimum of 3 characters and can contain up to 512 characters, so both ===EVSREF:123=== and ===EVSREF:A123456789B123456789=== are considered valid REFs.

Image Added

Which actions?

Depending on the folder where the input-file is dropped, EVSg will execute an action.

Action "add"

This action will add a data entry to the vault for each Kmehrmessage found in all dropped files.

In the example below, 3 Kmehrmessages are dropped to be added to the vault:

Image Added

Action "export"

This action will export the contents of the vault, without any change to the vault itself. EVSg will do this action once for each dropped file, without parsing this file.

In the example below, a newly created file will trigger an export of the contents of the vault:

Image Added

Action "generateREF"

This action will generate an EVS REF for each Kmehrmessage each transaction of type "medicationschemelement" in the input file, and will then replace the contents of the vault by all the Kmehrmessages found in the input file.

A Vitalink ID must be present for each Kmehrmessage in the input file as the EVS REF is derived from the Vitalink ID.

If an EVS REF exists already in the Kmehrmessage, the existing EVS REF is removed and the new EVS REF is put at the same location.

If multiple EVS REFs exist in the Kmehrmessage, all EVS REFs are removed and the new EVS REF is put in the instructionforpatient field.

Likewise, if no EVS REF exists, the new EVS REF is also put in the instructionforpatient field.

If an EVS REF exists already in the transaction, the existing EVS REF is removed and the new EVS REF is put at the same location.

If no EVS REF exists, the new EVS REF is put in the instructionforpatient field.

Image Added

Action "replace"

This action will replace the contents of the vault by all the Kmehrmessages found in the input file. Be aware of the fact that dropping multiple files in the replace-folder will result in a vault with as contents the Kmehrmessages of the last input file!

In the next example, after processing the next 3 input files, the vault contains 2 data entries.

Image AddedImage Removed

Action "updateschemeREF"

This action will update the complete contents of the vault, based on the input file compared with the current contents of the vault. ------------- IMAGE TO BE CHANGED

Image AddedImage Removed

The next actions will take place:

...