...
| Name | Output suffix | 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 | - | .exp | An export of the contents belonging to transactiontype "Medicationscheme" of the vault. | - |
Input file | - | .inp | The original input file. | The filename does not include the number of transactions in the vault. |
Gateway scheme PDF (from 3.4.0 onwards) | gatewayscheme | A visualisation of the global scheme in PDF format, generated by the gateway. Only generated in case EVS connects to the Vitalink Gateway. | - |
Each filename of transactiontype "Sumehr" exists out of:
...
After copy paste of the example files, insert the correct info for the new patient:
Since EVS follows all the rules for eHealth and Vitalink, it is up to the user to make sure the proper eHealth dependencies (informed consent, therapeutic relation, ...) are set in function of the wanted behaviour.
...
| 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. | ||
| dailyMedicationSchemeDate generateGatewayMedicationScheme (from 3.4.0 onwards) | true|false | true: Each action should be followed by the generation of a global scheme visualisation by the gateway. false: No global scheme visualisation by the gateway is needed. | ||
| dailyMedicationSchemeDate | date("yyyy-MM-dd") | If no date has been given | 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. | ||
| shiftAction | no_tag_and_no_shift tag_and_no_shift shift_and_tag |
Example of a parameterisation:
Appendix A: Folder structure EVS 2.x.y
This paragraph gives a brief overview of the folder structure after initial installation. It can be used as reference while using and configuring EVS.
hub (from 3.5.0 onwards) | VITALINK RSW | The Hub to send requests to. |
searchType (from 3.5.0 onwards) | LOCAL GLOBAL | LOCAL: instruct the hub to search only locally. GLOBAL: instruct the hub to search also elsewhere. Only applicable after the hubs will have been linked which is not the case at the time of writing (23/08/2018) |
Example of a parameterisation:
Appendix A: Folder structure EVS 2.x.y
This paragraph gives a brief overview of the folder structure after initial installation. It can be used as reference while using and configuring EVS.
| Path | Reserved path | Reserved name | Explanation | |||||||
|---|---|---|---|---|---|---|---|---|---|---|
| EVS |  | | The root folder. The name and location can be freely chosen. Keep in mind that paths used in scenarios, patient and | |||||||
| Path | Reserved path | Reserved name | Explanation | |||||||
| EVS | | | 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 EVS, configured as needed by the user. | ||||||
| \actors | | | All the actors that can be used by EVS. | |||||||
| \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 EVS. | |||||||
| \exe | | | ||||||||
| \certificates | | | The certificates used in the actor configuration files. | |||||||
| \exports | |
| The folder were the EVS-exporter will put exported vault contents, see AppendixB:EVSexporter | |||||||
| \interaction | | | ||||||||
| \input | | | ||||||||
| \katrien | | | ||||||||
| \gp_van_gucht | | | ||||||||
| \m | | | This folder contains the actions for transactiontype "Medicationscheme" | |||||||
| \add | | | ||||||||
| \export | | | ||||||||
\generateREF | | | ||||||||
| \replace | | | ||||||||
| \updateschemeREF | | | ||||||||
| \s | | | This folder contains the actions for transactiontype "Sumehr" | |||||||
| \add | | | ||||||||
| \empty | | | ||||||||
| \export | | | ||||||||
| \generateREF | | | ||||||||
| \removeREF | | | ||||||||
| \replace | | | ||||||||
| \updateREF | | | ||||||||
| \d | add | | | This folder contains the actions for transactiontype "Diarynote" | ||||||
| export | | | ||||||||
| generateREF | | | ||||||||
| updateREF | | | ||||||||
| \patient_template | | | ||||||||
| \processed | | | ||||||||
| \logs | | | Can be configured through the log4j settings. | |||||||
| \communication | | | ||||||||
\scenarios | | | ||||||||
| \basic_example | | | ||||||||
| \system | | | ||||||||
| \dependency-jars | | | ||||||||
...
| Name | Values | Meaning | |||
|---|---|---|---|---|---|
| transactionType | "medicationscheme" "sumehr" "diarynote" | EVS-exporter supports 3 transactiontypes: medicationscheme, sumehr and diarynote. Change this value accordingly. | |||
| 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.
| |||
| generateGatewayMedicationScheme | true|false | true: Each action should be followed by the generation of a global scheme visualisation by the gateway false: No global scheme visualisation by the gateway is needed. | |||
| dailyMedicationSchemeDate | date("yyyy-MM-dd") | If no date | 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. |
hub (from 3.5.0 onwards) | VITALINK RSW | The Hub to send requests to. | |||
searchType (from 3.5.0 onwards) | LOCAL GLOBAL | LOCAL: instruct the hub to search only locally. GLOBAL: instruct the hub to search also elsewhere. Only applicable after the hubs will have been linked which is not the case at the time of writing (23/08/2018) |
Example of a parameterisation:
...