...
For some actions, typically removing and updating data entries, the input Kmehrmessage need to have an identification.
There are 2 way ways to identify Kmehrmessages:
- by Vitalink ID
...
- ,
- by EVS reference.
Identification by Vitalink ID
The Kmehrmessage can should be preceeded by a Vitalink URI.
...
In the next example, this REF is "===EVSREF:901===". EVS detects the reserved format "===EVSREF:###<any text>===" and finally uses "901<any text>" as unique REF.
As from release 1.1.0 the REF must contain a minimum of 3 characters and can contain up to 20 characters, so both ===EVSREF:123=== and ===EVSREF:A123456789B123456789=== will be are considered as valid REFs.
Which actions?
...
This action will export the contents of the vault, without any change to the vault itself. EVS will do this action once for each dropped file, without any parsing . this file.
In the example below, a newly created file will trigger exporting an export of the contents of the vault by removing all existing data entries:
...
This action will replace the contents of the vault by all the Kmehrmessages found in the input file. Be aware of the fact the that dropping multiple files in the replace-folder will result in a vault with as contents the Kmehrmessages of the last input file!
...
After execution of an action otuput a variable number of output files are generated and put in the processed folder.
The next screenshot shows the output of a successful add-action. Each output file will be explained below:
Each filename exists out of:
<date>-<time>_<patient>_<actor>_<action>_<input filename>_size-<nr of data entries>_<output suffix>.<output extension>
| Name | Output sufficsuffix | Extension | Description | Remarks |
|---|---|---|---|---|
Validation file | VALIDATION-OK VALIDATION-<###>-FAILED | .val | The report of the validation. | The filename contains the number of warnings and errors when the validation fails.
|
Global scheme PDF | globalscheme | A visualisation of the global scheme in PDF format. | - | |
Daily scheme PDF | dailyscheme-<date> | A visualisation of the daily scheme in PDF format. | This is the scheme of the medication that should be taken today. | |
Export file | implicit by extension | .exp | An export of the contents of the vault. | - |
Input file | implicit by extension | .inp | The original input file. | The filename does not include the number of data entries in the vault. |
For the moment, only "today" is generated. Future EVS releases will add free choice of the date.If for some reason the action fails, an error output file is generated:
| Name | Output sufficsuffix | Extension | Description | Remarks |
|---|---|---|---|---|
Error file | implicit by extension | .err | The report containing the error. | The content of the error file will identify the problem. |
...
The needed info in the above example is the SSIN, the location of the certificate and the password of the certificate. The location of the certificate can be freely chosen, but it is recommended good practice to put it in the same folder as the example by installation:
...
| 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 EVS 1.x.y
...
Besides the interaction provided by dropping files in the input folder, EVS offers a as extended functionality the continuous monitoring of the vault contents. This functionality is provided by EVS-exporter.
...
When the export fails, an error file will be generated, which is the same behaviour as for the folder-triggerd triggered export action of EVS.
Parameterisation
The next parameters can be passed when launching EVS-exporter:
| Name | Values | Meaning |
|---|---|---|
| transactionType | "medication-scheme" | 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 | These is(are) the patient(s) that will be used for exporting. |
| actor | name as defined in EVS configuration | These 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.
|
Example of a parameterisation:
