Introduction

EVSg is an evolution of EVS, using gateway-integration instead of Vitalink connector-integration. It allows the manipulation of vault contents using specific actors and specific patients, manually or based on previously exported vault contents.

...

This manual describes EVSg v3.3.0.

Functionality

General

EVSg allows a certain actor to perform a number of actions for a certain patient. These actions are different, depending on the transactiontype.

...

This batch file contains parameter values for a standard behaviour. How the parameters change the behaviour can be found in the paragraph EVS_3_ManualParameterisation.

Input-folder

Which patient?

The patient is determined by the folder under "..\exe\interaction\input".

After initial installation, 1 patient named "katrien" is available:

Which actor?

The actor is determined by the folder under "..\exe\interaction\input\<patient folder>".

After initial installation, 1 actor named "gp_van_gucht" is available:

Which transactiontype?

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:

Which files?

Any type of files, with any extension, can be dropped. They are considered as "input-files". EVSg will, depending on the action folder, parse the files and extract the MSE, TS, Sumehr and Diarynote transactions.

What is a Kmehrmessage?

A Kmehrmessage is a part of the file that starts with <kmehrmessage ...> and ends with </kmehrmessage>. 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.

...

All extra data needed for the communication with the gateway will be generated by the EVSg. As input the data as depicted in the image below will be used:

How is a "medication" identified?

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.

How is a "sumehr" identified?

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.

How is a "Diarynote" identified?

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.

Identification by EVS reference

An EVS reference is put in 1 (and only 1) free text field in the concerned MSE, Sumehr or Diarynote transaction.

...

If multiple EVS REFs have been given for 1 MSE or Sumehr transaction, EVSg will not execute the action and will raise an error.

Which actions for Medicationscheme?

Depending on the folder where the input-file is dropped, EVSg will execute an action.

Action "add"

This action will add a transaction to the vault for all transactions found in each Kmehrmessage found in all dropped files. If one of the MSE transactions within a kmehrmessage does not have an EVS REF yet, an EVS REF will be generated.

In the example below, 3 transactions are dropped to be added to the vault:

Action "export"

This action will export the contents of the vault that belong to transactiontype "Medicationscheme", without any change to the vault itself. EVSg will do this action once for each dropped file, without parsing this file.

In the example below, a newly created file will trigger an export of the contents of the vault:

Action "generateREF"

This action will generate an EVS REF for each MSE transaction currently in the vault.

...

If no EVS REF exists, the new EVS REF is put in the instructionforpatient field.

Action "replace"

This action will replace the contents of the vault that belong to transactiontype "Medicationscheme" by all the transactions 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 transactions of the last input file! If one of the MSE transactions within a file 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 4 transactions.

Action "updateschemeREF"

This action will update the complete contents of the vault that belong to transactiontype "Medicationscheme", based on the input file compared with the current contents of the vault.

...

Which actions for Sumehr?

Action "add"

This action will add a transaction to the vault for all transactions found in each Kmehrmessage found in all dropped files. If one of the Sumehr transactions within a kmehrmessage does not have an EVS REF yet, an EVS REF will be generated.

In the example below, 3 transactions are dropped in the add folder to be added to the vault:

Action "empty"

This action will remove all transactions from the vault that belong to transactiontype "Sumehr". EVSg will do this action once for each dropped file, without any parsing. 

In the example below, a newly created file will trigger emptying of the vault by removing all existing transactions of transactiontype "Sumehr":

Action "export"

This action will export the contents of the vault that belong to transactiontype "Sumehr", without any change to the vault itself. EVSg will do this action once for each dropped file, without parsing this file.

In the example below, a newly created file will trigger an export of the contents of the vault of transactiontype "Sumehr":

Action "generateRef"

This action will generate an EVS REF for each Sumehr transaction currently in the vault.

...

If no EVS REF exists, the new EVS REF is put in the first text field.

Action "removeRef"

This action will remove the transactions that belong to transactiontype "Sumehr" identified by the EVS REF in the input file from the vault.

Action "replace"

This action will replace the contents of the vault that belong to transactiontype "Sumehr" by all the transactions 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 transactions of the last input file! If one of the Sumehr transactions within a file 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 4 transactions.

Action "updateRef"

This action will update the transactions that belong to transactiontype "Sumehr" identified by the EVS REF in the input file.

Which actions for Diarynote?

Action "add"

This action will add a transaction to the vault for all transactions found in each Kmehrmessage found in all dropped files. If one of the Diarynote transactions within a kmehrmessage does not have an EVS REF yet, an EVS REF will be generated.

Action "export"

This action will export the contents of the vault that belong to transactiontype "Diarynote", without any change to the vault itself. EVSg will do this action once for each dropped file, without parsing this file.

Action "generateRef"

This action will generate an EVS REF for each Diarynote transaction currently in the vault.

...

If no EVS REF exists, the new EVS REF is put in the first Text or TextWithLayout field. If none of these exists, a new TextWithLayout field is created.

Action "updateRef"

This action will update the transactions that belong to transactiontype "Diarynote" identified by the EVS REF in the input file.

Processed-folder

After execution of an action a variable number of output files are generated in the processed folder.

...

...

Logs-folder

Root

This folder will be automatically generated once "start EVS.cmd" or "start EVS exporter.cmd" has been run for the first time.

...

• the eHealth technical connector logs for EVSg: ehealth_uploader*.log
• the eHealth technical connector logs for EVSg-exporter: ehealth_exporter*.log
• the proprietary EVSg log for EVSg: evs_uploader.log
• the proprietary EVSg log for EVSg-exporter: evs_exporter.log
• a folder 'communication'

Communicaton-folder

This folder contains all the requests and responses done by EVSg when communicating with the gateway.

Configuration

This paragraph explains how to configure EVSg.

How to add a patient?

Extra patients can be added by creating files in the next folder:

...

How to add an actor?

Extra actors can be added by creating files in the next folder:

...

Parameterisation

The next parameters can be passed when launching EVSg:

...

Example of a parameterisation:

Appendix A: Folder structure EVSg 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 EVSg.

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 EVS_3_Manual 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

Appendix B: EVSg-exporter

Besides the interaction provided by dropping files in the input folder, EVSg offers as extended functionality the continuous monitoring of the vault contents. This functionality is provided by EVSg-exporter.

Launching

EVSg-exporter can be launched via the "vault-exporter.cmd" batch file:

...

After initial installation, launching the EVSg-exporter means that the vault contents of the patient "katrien" will be monitored.

Output

When EVSg-exporter detects for the given patients a change in the vault contents, an export is executed. The export is also executed after initial launch.

...

When the export fails, an error file will be generated, which is the same behaviour as for the folder-triggered export action of EVSg.

Parameterisation

The next parameters can be passed when launching EVSg-exporter:

...

Example of a parameterisation:

Appendix C: Parameter shiftAction

This paragraph gives an explanation about what shiftAction is and how to use it.

...