3.0 Configuration
Extra patients can be added by creating files in the next folder:
After initial installation, 2 patient config files are already present. Both can be used as example (copy-paste) to add extra patients. The name of the file, without the extension, needs to be used to identify for which patient the action needs to performed.
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.
Extra actors can be added by creating files in the next folder:
After initial installation, some actor config files are already present. All can be used as example (copy-paste) to add extra actors. The name of the file, without the extension, needs to be used to identify by which actor the action needs to be performed.
The template examples are given for 5 different types of actors: doctor, nurse and pharmacy, hospital, retirement home
After copy paste of the appropriate example file, insert the correct info for the new actor:
The needed info in the above template is:
- the certificate name e.g. 'xxx.p12'
- the password of the certificate,
- the SSIN,
- the NIHII number
- the actor's name
The location of the certificate can be freely chosen, but it is good practice to put it in the same folder as the example by installation:
Since EVS follows all the rules for eHealth and Vitalink, it is up to the user to make sure the proper eHealth dependencies (therapeutic relation, ...) are set in function of the wanted behaviour.
The next parameters can be passed when launching EVS:
| 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 corresponding 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. |
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 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 |
See Parameter shiftAction |
hub |
VITALINK | RSW | RSB |
The Hub to send requests to. |
searchType |
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). |
logCommunicationType |
WITHOUT_SECURITY | WITH_SECURITY | ALL
|
Ability to also log encrypted incoming and outgoing communication. Default: WITHOUT_SECURITY |
Example of a parameterisation:
Besides the interaction provided by dropping files in the input folder, EVS offers as extended functionality the continuous monitoring of the vault contents. This functionality is provided by EVS-exporter.
EVS-exporter can be launched via the "vault-exporter.cmd" batch file:
The behaviour of EVS-exporter must be determined by passing some mandatory parameters. Instead of using the "vault-exporter.cmd" batch file, it is easier to use the example batch file "start EVS exporter.cmd":
After initial installation, launching the EVS-exporter means that the vault contents of the patient "katrien" will be monitored.
When EVS-exporter detects for the given patients a change in the vault contents, an export is executed. The export is also executed after initial 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 in the processed-folder, but the filenames differ. As such, there are different naming conventions for "Medicationscheme", "Sumehr" and "Diarynote".
For EVS-exporter, each filename of transactiontype "Medicationscheme" exists out of:
<current-date>-<current-time>_<transactiontype>_<version>_<patient>_<date>_<time>-<author>_size-<nr of MSE transactions>_<unique code>_<output suffix>.<output extension>
| Name | Meaning |
|---|---|
| current-date | Date of performing the export (from 3.3.0 onwards) |
| current-time | Time of performing the export (from 3.3.0 onwards) |
| Transactiontype | |
| Version | - "Version" from the MS transaction. |
| - In case of an empty medicationscheme, the "version" is derived from the getLatestUpdate method. | |
| Patient | Name of the patient as defined in the EVS configuration. |
| Date | Date of the latest update derived from the MS transaction. |
| Time | Time of the latest update derived from the MS transaction. |
| Author | "Author" of the latest update, derived from the MS transaction->UpdatedBy as returned by the gateway. |
| Nr of MSE transactions | The amount of MSE transactions in the vault. |
| Unique code | Code making the filename unique in case an 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. |
For EVS-exporter, each filename of transactiontype "Sumehr" exists out of:
<current-date>-<current-time>_<transactiontype>_<version>_<patient>_size-<nr of Sumehr transactions>_<unique code>.<output extension>
| Name | Meaning |
|---|---|
| current-date | Date of performing the export (from 3.3.0 onwards) |
| current-time | Time of performing the export (from 3.3.0 onwards) |
| Transactiontype | |
| Version | - "Version" from the MS transaction. |
| - In case of an empty medicationscheme, the "version" is derived from the getLatestUpdate method. | |
| Patient | Name of the patient as defined in the EVS configuration. |
| Nr of Sumehr transactions | The amount of Sumehr transactions in the vault. |
| Unique code | Code making the filename unique in case an export exists already. |
| Output extension | Hard coded, depending on file type. |
For EVS-exporter, each filename of transactiontype "Diarynote" exists out of:
<current-date>-<current-time>_<transactiontype>_<version>_<patient>_size-<nr of Diarynote transactions>_<unique code>.<output extension>
| Name | Meaning |
|---|---|
| current-date | Date of performing the export (from 3.3.0 onwards) |
| current-time | Time of performing the export (from 3.3.0 onwards) |
| Nr of Diarynote transactions | The amount of Diarynote transactions in the vault. |
| Output extension | Hard coded, depending on file type. |
| Patient | Name of the patient as defined in the EVS configuration. |
| Transactiontype | |
| Unique code | Code making the filename unique in case an export exists already. |
| Version | - "Version" from the MS transaction. |
| - In case of an empty medicationscheme, the "version" is derived from the getLatestUpdate method. |
When the export fails, an error file will be generated, which is the same behaviour as for the folder-triggered export action of EVS.
| Name | Values | Meaning |
|---|---|---|
| transactionType |
"medicationscheme", "sumehr", "diarynote"
|
EVS-exporter supports 3 transaction types: 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 visualization PDF.- false: No global scheme visualization is needed. |
| generateDailyMedicationScheme | true|false |
- true: Each action should be followed by the generation of a daily scheme visualization PDF.- false: No daily scheme visualization is needed. |
| generateGatewayMedicationScheme | true|false |
- true: Each action should be followed by the generation of a global scheme visualization by the gateway.- false: No global scheme visualization by the gateway 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. |
| hub (from 3.5.0 onwards) | VITALINK|RSW|RSB (from 3.6.0 onwards) |
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:
This paragraph gives an explanation about what shiftAction is and how to use it.
shiftAction is a parameter than can be passed when launching EVS. Using shiftActions ensures that the dates of the tests are within a usable range. Not in the past and not too far in the future. Because of this the dates of the tests don't need to be manually altered anymore.
shiftAction has three different values:
- tag_and_no_shift
- shift_and_tag
- no_tag_and_no_shift
Tag sets or updates a reference date as a "recorddatetime"-tag in the XML-file. This reference date is ALWAYS today's date.
Shift ensures that all other dates in the XML-file are adjusted in reference to the reference date.
tag_and_no_shift will set a new reference date to today's date or update an existing reference date. This reference date will be added/updated in the XML-file as a "recorddatetime"-tag. it will not change any other date in the XML-file.
shift_and_tag ensures that all other dates in the XML-file are adjusted in reference to today's date. Afterwards it will update the "recorddatetime"-tag.
Suppose that today's date is 6 june 2018 :
| Description | Original date | Date after shift_and_tag |
|---|---|---|
| May 25, 2018 | June 6, 2018 | |
| transaction 1: tomorrow | May 26, 2018 | June 7, 2018 |
| transaction 2: yesterday | May 24, 2018 | June 5, 2018 |
| transaction 3: three days from now | May 28, 2018 | June 9, 2018 |
Problem case:
Software vendor wants to alter all dates in the xml to other, more relevant dates. For example, sw-vendor's application can only show the current week of the medicationscheme, but all dates in the XML are starting and ending in 2030.
Solution:
- Enter a referencedate in the xmlrequest (underneath as seen in this chapter) to the first startmoment of the medication.
- change startup parameter to shift_and_tag
- send the xmlrequest to the vault
no_tag_and_no_shift will not create or update the "recorddatetime"-tag and it will not adjust all other dates according to today's date.
e.g. -dailyMedicationSchemeDate="2016-01-13" -shiftAction=no_tag_and_no_shift