2.0 Functionalities ‐ General
EVS allows a certain actor to perform a number of actions for a certain patient. These actions are different, depending on the transactiontype.
These actions are triggered by dropping input files in (subfolders of) the input-folder:
EVS watches these folder(s), executes the action(s) and generates output in the processed-folder:
EVS can be launched via the "vault-uploader.cmd" batch file:
The behaviour of EVS must be determined by passing some mandatory parameters. Instead of using the "vault-uploader.cmd" batch file, it is easier to use the example batch file "start EVS.cmd":
This batch file contains parameter values for a standard behaviour. How the parameters change the behaviour can be found in the paragraph Parameterisation.
The patient is determined by the folder under "..\exe\interaction\input". After initial installation, 1 patient named "katrien" is available:
The actor is determined by the folder under "..\exe\interaction\input<patient folder>". After initial installation, 1 actor named "gp_van_gucht" is available:
The transactiontype is determined by the folder under "..\exe\interaction\input<patient folder><actor folder>". After initial installation, 3 types named "m", "s" and "d" (meaning "Medicationscheme", "Sumehr" and "Diarynote" respectively) are available:
Any type of files, with any extension, can be dropped. They are considered as "input-files". EVS will, depending on the action folder, parse the files and extract the MSE, TS, Sumehr and Diarynote transactions.
Since EVS went opensource we decided to not use a hard-coded acceptation-key anymore but a 'replaceable' key in the config which is read at run-time. This key can be added in the (to be used) actor configuration file at the location as described hereabove in the topic 'Which actor?'.
Example:
<!-- Acceptation key location in actor config file -->
<authenticationConfiguration>
<evs>
<type>fallback</type>
<certificates>
<certificate>
<type>identification</type>
<path>..\config\certificates\SSIN=[INSS+SPECIAL CODE].acc-p12</path>
<password>[PW]</password>
</certificate>
</certificates>
</evs>
<ehealth>
<entry>kmehr.hubservicev3.software.id.local.value.1=[VITALINK ACC-KEY]</entry>
<entry>user.inss=[INSZ]</entry>
<entry>user.nihii=[NIHII]</entry>
<entry>user.firstname=[FIRSTNAME]</entry>
<entry>user.lastname=[LASTNAME]</entry>
<entry>careprovider.inss=${user.inss}</entry>
<entry>careprovider.nihii=${user.nihii}</entry>
<entry>careprovider.firstname=${user.firstname}</entry>
<entry>careprovider.lastname=${user.lastname}</entry>
...A Kmehrmessage is a part of the file that starts with <kmehrmessage ...> and ends with . One file can contain 0 or more Kmehrmessages. One Kmehrmessage can contain either 0 or more MSE and TS transactions, or it can contain 0 or more Sumehr transactions.
EVS will work with Kmehrmessages of Kmehr-standard 20120401 and Kmehr-standard 20161201 as input.
All extra data needed for the communication with the gateway will be generated by the EVS. As input the data as depicted in the image below will be used:
For some actions, typically removing and updating "medications", the medication that should be changed needs to have an identification. Those medications are expressed as MSE transactions. These MSE transactions are identified by using an EVS reference.
For some actions, typically removing and updating "sumehrs", the sumehr that should be changed needs to have an identification. Those sumehrs are expressed as Sumehr transactions. These Sumehr transactions are identified by using an EVS reference.
For some actions, typically removing "diarynotes", the diarynote that should be changed needs to have an identification. Those sumehrs are expressed as Diarynote transactions. These Diarynote transactions are identified by using an EVS reference.
An EVS reference is put in 1 (and only 1) free text field in the concerned MSE, Sumehr or Diarynote 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===. EVS 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.
If multiple EVS REFs have been given for 1 MSE or Sumehr transaction, EVS will not execute the action and will raise an error.
After execution of an action a variable number of output files are generated in the processed folder. The next 2 screenshots show the output of a successful action. The first screenshot shows the output of a successful add-action for transactiontype "Medicationscheme". The second screenshot shows the output of a successful export-action for transactiontype "Sumehr". Each output file will be explained below:
Each filename of transactiontype "Medicationscheme" exists out of:
<date>-<time>_<transactiontype>_<patient>_<actor>_<action>_<input filename>_size-<nr of MSE transactions>_<output suffix>.<output extension>
| Name | Format | Description | Output suffix | Remarks |
|---|---|---|---|---|
| Validation File | .val | The report of the validation. | VALIDATION-OK | |
| VALIDATION-<###>-FAILED | The filename contains the number of warnings and errors when the validation fails. | |||
| Global Scheme PDF | A visualization of the global scheme in PDF format. | globalscheme | ||
| Daily Scheme PDF | A visualization of the daily scheme in PDF format. | dailyscheme-<date> |
This is the scheme of the medication that should be taken today. | |
| Export File | .exp | An export of the contents belonging to transaction type "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 | A visualization 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:
<date>-<time>_<transactiontype>_<patient>_<actor>_<action>_<input filename>_size-<nr of Sumehr transactions>.<output extension>
| Name | Extension | Description | Remarks |
|---|---|---|---|
| Export File | .exp | An export of the contents belonging to transaction type "Sumehr" of the vault | - |
| Input File | .inp | The original input file. | The filename does not include the number of transactions in the vault. |
Each filename of transactiontype "Diarynote" exists out of:
<date>-<time>_<transactiontype>_<patient>_<actor>_<action>_<input filename>_size-<nr of Diarynote transactions>.<output extension>
| Name | Extension | Description | Remarks |
|---|---|---|---|
| Export File | .exp | An export of the contents belonging to transaction type "Diarynote" of the vault | - |
| Input File | .inp | The original input file. | The filename does not include the number of transactions in the vault. |
If for some reason the action fails, an error output file is generated:
This folder will be automatically generated once "start EVS.cmd" or "start EVS exporter.cmd" has been run for the first time.
This folder contains:
- the eHealth technical connector logs for EVS: ehealth_uploader*.log
- the eHealth technical connector logs for EVS-exporter: ehealth_exporter*.log
- the proprietary EVS log for EVS: evs_uploader.log
- the proprietary EVS log for EVS-exporter: evs_exporter.log
- a folder 'communication'
This folder contains all the requests and responses done by EVS when communicating with the gateway.
