Note

title	Under construction

This page is still under construction.

Table of Contents

Introduction

EVS allows the manipulation of vault contents using specific actors and specific patients, manually or based on previously exported vault contents.

After initial installation, some examples are available to get familiar with the functionalities of EVS, without the need for further configuration.

This manual describes EVS EVSg v2.1.0.

Functionality

General

EVS2 EVSg allows a certain actor to perform, for a certain patient, a number of actions.

These actions are triggered by dropping input files in (subfolders of) the input-folder:

EVS2 EVSg watches these folder(s), executes the action(s) and generates output in the processed-folder:

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

The behaviour of EVS2 EVSg 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 EVS2 EVSg user manual.

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 files?

Any type of files, with any extension, can be dropped. They are considered as "input-files". EVS2 EVSg will, depending on the action folder, parse the files and extract the Kmehrmessage(s).

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.

EVS2 EVSg will work with Kmehrmessages of Kmehr-standard 20120401 and Kmehr-standard 20161201. It will automatically convert Kmehrmessages of Kmehr-standard 20120401 to Kmehr-standard 20160401.

All data (among which the metadata) will be generated by the EVS2 EVSg and/or the Vitalink platform. As input the business data as depicted in blue here below will be used:

Image Modified

How is a transaction within a Kmehrmessage identified?

For some actions, typically removing and updating data entries, the transaction that should be changed needs to have an identification and it has to be of type "medicationschemeelement". Those 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 transaction.

...

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.

Which actions?

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

Action "add"

This action will add a data entry to the vault for each Kmehrmessage found in all dropped files.

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

Action "export"

This action will export the contents of the vault, 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 transaction of type "medicationschemelement" in the input file, and will then replace the contents of the vault by all the Kmehrmessages found in the input file.

...

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 by all the Kmehrmessages 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 Kmehrmessages of the last input file!

In the next example, after processing the next 3 input files, the vault contains 2 data entries.

Action "updateschemeREF"

This action will update the complete contents of the vault, based on the input file compared with the current contents of the vault.

...

The next actions will take place:

an input-Kmehrmessage with EVS REF not yet existing in the vault will be added to the vault
an input-Kmehrmessage with EVS REF already existing in the vault will cause an update but only if the input-Kmehrmessage differs from the vault-Kmehrmessage
all vault-Kmehrmessages without corresponding EVS REF in the input file will be removed from the vault

If the input-file contains Kmehrmessages without EVS REF or if the EVS REFs used are not unique, the action will not be executed and an error will be thrown.

Processed-folder

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

The next screenshot shows the output of a successful add-action. Each output file will be explained below:

Image Removed

Each filename exists out of:

...

Validation file

...

VALIDATION-OK

VALIDATION-<###>-FAILED

...

The filename contains the number of warnings and errors when the validation fails.

...

Global scheme PDF

...

Daily scheme PDF

...

This is the scheme of the medication that should be taken today.
For the moment, only "today" is generated. Future EVS releases will add free choice of the date.

...

Export file

...

Input file

...

---------------------------------------------------------------

an input-Kmehrmessage with EVS REF not yet existing in the vault will be added to the vault
an input-Kmehrmessage with EVS REF already existing in the vault will cause an update but only if the input-Kmehrmessage differs from the vault-Kmehrmessage
all vault-Kmehrmessages without corresponding EVS REF in the input file will be removed from the vault

If the input-file contains Kmehrmessages without EVS REF or if the EVS REFs used are not unique, the action will not be executed and an error will be thrown.

Processed-folder

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

The next screenshot shows the output of a successful add-action. Each output file will be explained below:

Image Added

Each filename exists out of:

If for some reason the action fails, an error output file is generated:

Image Removed

Name	Output suffix	Extension	Description	Remarks
Error file	-	.err	The report containing the error.	The content of the error file will identify the problem.

Configuration

This paragraph explains how to configure EVS2.

How to add a patient?

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

Image Removed

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:

Image Removed

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.

Note

title	Restart EVS

EVS (and EVS-exporter) should be restarted when newly added patients will be used.

How to add an actor? ---- to check

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

Image Removed

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 3 different types of actors: doctor, nurse and pharmacy.

After copy paste of the appropriate example file, insert the correct info for the new actor:

Image Removed

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 good practice to put it in the same folder as the example by installation:


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	.pdf	A visualisation of the global scheme in PDF format.	-
Daily scheme PDF	dailyscheme-<date>	.pdf	A visualisation of the daily scheme in PDF format.	This is the scheme of the medication that should be taken today. For the moment, only "today" is generated. Future EVS releases will add free choice of the date.
Export file	-	.exp	An export of the contents of the vault.	-
Input file	-	.inp	The original input file.	The filename does not include the number of data entries in the vault.

If for some reason the action fails, an error output file is generated:

Image Added

Name	Output suffix	Extension	Description	Remarks
Error file	-	.err	The report containing the error.	The content of the error file will identify the problem.

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:

Image Added

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:

Image AddedImage Removed

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.

Note

title	Restart EVS

EVS (and EVS-exporter) should be restarted when newly added actors patients will be used.

Parameterisation

The next parameters can be passed when launching EVS:

...

Values

...

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.

...

true: Each action, excepted "export" itself, should be followed by an export.

false: No export is needed after execution of the triggered action.

...

true: Each action should be followed by validation of the vault content.

false: No validation is needed.

...

true: Each action should be followed by the generation of a global scheme visualisation PDF.

false: No global scheme visualisation is needed.

...

true: Each action should be followed by the generation of a daily scheme visualisation PDF.

false: No daily scheme visualisation is needed.

This EVS functionality is still under development!

How to add an actor?

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

Image Added

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 3 different types of actors: doctor, nurse and pharmacy.

After copy paste of the appropriate example file, insert the correct info for the new actor:

Image Added

The needed info in the above template is the certificate name, the password of the certificate, the SSIN, the NIHII number and 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:

Image Added

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.

Note

title	Restart EVS

EVS (and EVS-exporter) should be restarted when newly added actors will be used.

Parameterisation ← TO CHECK

The next parameters can be passed when launching EVSg:

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. This EVS functionality is still under development!

Example of a parameterisation:

Image Added

Appendix A: Folder structure EVSg 2.1.0 ← TO CHECK

This paragraph gives a brief overview of the folder structure after initial installation. It can be used as reference while using and configuring the EVS.

Path

Reserved

path

Reserved

name

Explanation

EVSg

Example of a parameterisation:

Image Removed

Appendix A: Folder structure EVS 1.x.y ----- to check

This paragraph gives a brief overview of the folder structure after initial installation. It can be used as reference while using and configuring the EVS.

\exe exports \katrien

Path							Reserved path	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.
										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!
	\certificatesconfig								Everything that defines the behaviour of EVSg, configured as needed by the user The certificates used in the actor configuration files .
		\	actors					The folder were the EVS-exporter will put exported vault contents, see EVS2 user manual	All the actors that can be used by EVSg.
		\interactionlog4j							Settings of the log4j library. Please refer to https://logging.apache.org/log4j/2.x/manual/configuration.html for more explanation.
		\patients	\input					All the patients that can be used by EVSg.
	\exe
		\certificates			\gp_van_gucht			The certificates used in the actor configuration files.
		\exports					\add		The folder were the EVS-exporter will put exported vault contents, see EVSg user manual
		\interaction					\empty
			\input				\export
				\katrien			\removeID
					\gp_van_gucht		\removeREF
						\replaceadd
						\updateIDexport
						\ updateREF generateREF
						\generateREFreplace
						\updateschemeREF
				\patient_template
			\processed
	\logs
		\communication
	\scenarios
		\basic_example
	\system
		\dependency-jars

Appendix B: EVS-exporter

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

Launching

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

Image RemovedImage Added

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.cmd":

Image RemovedImage Added

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

...

Output ← TO CHECK

When EVS-exporter detects for the given patients a change in the vault contents, and export is executed. The export is also executed after intial launch.

...

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

...

Parameterisation ← TO CHECK

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

...

Space shortcuts

Page tree

Page History

Versions Compared

Old Version 5

New Version 6

Key

Introduction

Functionality

General

Input-folder

Which patient?

Which actor?

Which files?

What is a Kmehrmessage?

How is a transaction within a Kmehrmessage identified?

Identification by EVS reference

Which actions?

Action "add"

Action "export"

Action "generateREF"

Action "replace"

Action "updateschemeREF"