...
All data (among which the metadata) will be generated by the EVSg and/or the Vitalink platform. As input the business data as depicted in blue here below will be used:
How is a
...
medication within a Kmehrmessage identified?
For some actions, typically removing and updating data entries, the transaction medication that should be changed needs to have an identification and it has to be of type "medicationschemeelement". Those transactions medications are identified by using an EVS reference.
...
An EVS reference is put in 1 (and only 1) free text field in the concerned transactionmedication.
The EVS reference can be freely chosen, and facilitates the definition and execution of scenarios.
...
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.
If multiple EVS REFs have been given for 1 medication, EVSg will not execute an action and will raise an error.
Which actions?
Depending on the folder where the input-file is dropped, EVSg will execute an action.
...
This action will add a data entry to the vault for each Kmehrmessage found in all dropped files. If one of the medications within a kmehrmessage does not have an EVS REF yet, this will be generated.
In the example below, In the example below, 3 Kmehrmessages are dropped to be added to the vault:
...
This action will generate an EVS REF for 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 fileeach medication within a kmehrmessage.
If an EVS REF exists already in the transaction, the existing EVS REF is removed and the medication, no new EVS REF is put at the same locationwill be generated.
If no EVS REF exists, the new EVS REF is put in the instructionforpatient field.
...
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! If one of the medications within a kmehrmessage does not have an EVS REF yet, this will be generated.
In the next example, after processing the next 3 input files, the vault contains 2 data entries.
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.
...
The next actions will take place:
- an input-Kmehrmessage a medication with EVS REF not yet existing in the vault will be added to the vault
- an input-Kmehrmessage with a medication with EVS REF already existing in the vault will cause an update but only if the input-Kmehrmessage medication differs from the vault-Kmehrmessage medication
- all vault-Kmehrmessages medications without corresponding EVS REF in the input file will be removed from the vault
If the input-file contains Kmehrmessages without EVS REF or if the EVS REFs used contains medications with EVS REFs that are not unique, the action will not be executed and an error will be thrown.
...
| Note | ||
|---|---|---|
| ||
EVS (and EVS-exporter) should be restarted when newly added actors will be used. |
...
Parameterisation
The next parameters can be passed when launching EVSg:
| Name | Values | Meaning |
|---|---|---|
| rootdir | "..\exe\interaction" | Relative or absolute path to the folder that needs to be watched by EVS. This folder should contain the requested actions. |
| writeAsIs | true|false | false: All patient data from the source Kmehrmessage will be replaced by the correspondign data of the used input patient. Since the Kmehr data model is used for this transformation, it is possible that other Kmehr structure elements are slightly changed too. true: The Kmehrmessage will be sent to the vault untouched. Use this when really no manipulation on the source Kmehrmessage is desired. |
| exportAfterUpload | true|false | true: Each action, excepted "export" itself, should be followed by an export. false: No export is needed after execution of the triggered action. |
| validateExportAfterUpload | true|false | true: Each action should be followed by validation of the vault content. false: No validation is needed. |
| generateGlobalMedicationScheme | true|false | true: Each action should be followed by the generation of a global scheme visualisation PDF. false: No global scheme visualisation is needed. |
| generateDailyMedicationScheme | true|false | true: Each action should be followed by the generation of a daily scheme visualisation PDF. false: No daily scheme visualisation is needed.
|
Example of a parameterisation:
Appendix A: Folder structure EVSg 2.1.0 ← TO CHECK
This paragraph gives a brief overview of the folder structure after initial installation. It can be used as reference while using and configuring the EVS.
| dailyMedicationSchemeDate | date("yyyy-MM-dd") | If no date has been given, it will generate a daily medication scheme of the current date. If a date has been given, it will generate a daily medication scheme of the given date. |
| startTransactionId | number | This number will be the number for the first transaction within the kmehrmessage of a putTransactionSetRequest in the context of a medicationscheme. |
Example of a parameterisation:
Appendix A: Folder structure EVSg 2.1.0
This paragraph gives a brief overview of the folder structure after initial installation. It can be used as reference while using and configuring the EVS.
| Path | Reserved path | Reserved name | Explanation | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| EVSg |  | | The root folder. The name | ||||||||
| Path | Reserved path | Reserved name | Explanation | ||||||||
| EVSg | | | The root folder. The name and location can be freely chosen. Keep in mind that paths used in scenarios, patient and actor files are possibly impacted by changes to this! | ||||||||
| \config |  | | Everything that defines the behaviour of EVSg, configured as needed by the user. | |||||||
| \actors | | | All the actors that can be used by EVSg. | ||||||||
| \log4j | | | Settings of the log4j library. Please refer to https://logging.apache.org/log4j/2.x/manual/configuration.html for more explanation. | ||||||||
| \patients | | | All the patients that can be used by EVSg. | ||||||||
| \exe | | | |||||||||
| \certificates | | | The certificates used in the actor configuration files. | ||||||||
| \exports | |
| The folder were the EVS-exporter will put exported vault contents, see EVSg user manual | ||||||||
| \interaction | | | |||||||||
| \input | | | |||||||||
| \katrien | | | |||||||||
| \gp_van_gucht | | | |||||||||
| \add | | | |||||||||
| \export | | | |||||||||
\generateREF | | | |||||||||
| \replace | | | |||||||||
| \updateschemeREF | | | |||||||||
| \patient_template | | | |||||||||
| \processed | | | |||||||||
| \logs\communication | | | Can be configured through the log4j settings. | ||||||||
| \communication | | | |||||||||
\scenarios | \scenarios | | | ||||||||
| \basic_example | | | |||||||||
| \system | | | |||||||||
| \dependency-jars | | | |||||||||
...
After initial installation, launching the EVS-exporter means that the vault contents of the patient "katrien" will be monitored.
...
Output
When EVS-exporter detects for the given patients a change in the vault contents, and an export is executed. The export is also executed after intial launch.
The exported files are put in the next folder, with for each monitored patient a subfolder. The subfolder is automatically created when the monitoring for this patient is initially started.
The files contain the same as the files generated by EVS EVSg in the processed-folder, but the filenames differ.
For EVS-exporter, each filename exists out of:
sv-<subject version>_nv-<node version>MS_<version>_<patient>_<date>_<time>-<time>_<patient><author>_size-<nr of data entries>_<unique code>_updatedby_<actor>_<output suffix>.<output extension>MSE transactions>_<unique code>_<output suffix>.<output extension>
| Name | Source | ||
|---|---|---|---|
Version | |||
| Name | Source | ||
Subject version | "Version" from FetchDataEntriesResponse->Node as returned by the connector:
See http://www.vitalink.be/sites/default/files/atoms/files/Safe_Cookbook_API_v4%202.pdf
| ||
Node version | "Version" from
| ||
Date | Today. | ||
Time | Now. | ||
Patient | Name of the patient as defined in the EVS configuration. | ||
the medicationscheme transaction. In case of an empty medicationscheme, the "version" is derived from the getLatestUpdate method. | |||
Patient | Name of the patient as defined in the EVSg configuration. | ||
Date | Date of the latest update derived from the medicationsscheme transaction. | ||
Time | Time of the latest update derived from the medicationsscheme transaction. | ||
| Author | "Author" of the latest update derived from the medicationsscheme transaction->UpdatedBy as returned by the gateway. | ||
| Nr of MSE transactions | The amount of MSE transactions in the vault | Nr of data entries | Number of data entries in the vault as as returned by the connector. |
| Unique code | Code making the filename unique in case multiple exports where done in 1 second. | Actor | "Person" from FetchDataEntriesResponse->UpdatedBy as returned by the connectoran export exists already. |
| Output suffix | Hard coded, depending on file type. For the validation file, the number of warnings and errors and possible failure are shown. | ||
| Output extension | Hard coded, depending on file type. |
When the export fails, an error file will be generated, which is the same behaviour as for the folder-triggered export action of EVSEVSg.
...
Parameterisation
The next parameters can be passed when launching EVS-exporter:
| Name | Values | Meaning |
|---|---|---|
| transactionType | "medication-schememedicationscheme" | This parameter is for future use. For the moment only 1 transaction type is supported. |
| patients | name(s) as defined in EVS configuration, comma separated | This(these) is(are) the patient(s) that will be monitored and whose vault content(s) will be exported. |
| actor | name as defined in EVS configuration | This is the actor that will be used for exporting. |
| exportDir | default "..\exe\exports" | This is the path where the output files will be generated. This location can be freely chosen. |
| validate | true|false | true: Each export should be followed by validation of the vault content. false: No validation is needed. |
| generateGlobalMedicationScheme | true|false | true: Each action should be followed by the generation of a global scheme visualisation PDF. false: No global scheme visualisation is needed. |
| generateDailyMedicationScheme | true|false | true: Each action should be followed by the generation of a daily scheme visualisation PDF. false: No daily scheme visualisation is needed.
|
| dailyMedicationSchemeDate | date("yyyy-MM-dd") | If no date has been given, it will generate a daily medication scheme of the current date. If a date has been given, it will generate a daily medication scheme of the given date. |
Example of a parameterisation:
...