You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 47 Next »

Intro

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

Functionality

General

The EVS 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:

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

Watching of these folders is done by the EVS application. The application can be launched via the "vault-uploader.cmd" batch file:

The behaviour of application 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 EVS_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". EVS will, depending on the action folder, parse the files and extract the Kmehrmessage(s).

What is a Kmehrmessage?

A Kmehrmessage is that part of the file that starts with <kmehrmessage ...> and ends with </kmehrmessage>. One file can contain 0 or more Kmehrmessages. 

EVS will only work with Kmehrmessages of Kmehr-standard 20120401. In this standard, 1 medicationschemeelement transaction and 0 or more treatmentsuspension transactions were considered as the business data of 1 "data entry".

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

How is a Kmehrmessage identified?

For some actions, typically removing and updating data entries, the input Kmehrmessage need to have an identification.

There are 2 way to identify Kmehrmessages: by Vitalink ID and by EVS reference.

Identification by Vitalink ID

The Kmehrmessage can be preceeded by a Vitalink URI.

The Vitalink ID can not be chosen, but are dynamically generated by the Vitalink platform when adding new data entries. As a consequence, they are not deterministic and are hard to use in when defining scenarios.

In the next example, this URI is /subject/83051839468/medication-scheme/32055/1. EVS detects the reserved format  "/subject/###########/medication-scheme/32055" and finally uses "32055" as unique ID.

Identification by EVS reference

An EVS reference is put in 1 (and only 1) free text field in the concerned Kmehrmessage.

The EVS reference can be freely chosen, and support the definition and execurion of scenarios.

In the next example, this REF is "===EVSREF:901===". EVS detects the reserved format  "===EVSREF:###===" and finally uses "901" as unique REF.

Which actions?

Depending on the folder where the inout-file is dropped, EVS 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 "empty"

This action will remove all data entries from the vault. EVS 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 data entries:

Action "export"

This action will export the contents of the vault, without any change to the vault itself. EVS will do this action once for each dropped file, without any parsing. .

In the example below, a newly created file will trigger exporting the contents of the vault by removing all existing data entries:

Action "removeID"

This action will remove the data entries identified by the Vitalink ID in the input file from the vault.

Action "removeREF"

This action will remove the data entries identified by the EVS REF in the input file from the vault.

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 the 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 "updateID"

This action will update the data entries identified by the Vitalink ID in the input file.

Action "updateREF"

This action will update the data entries identified by the EVS REF in the input file.

Processed-folder

After successful execution of an action typically specific files are generated and put in the processed folder.

The next screenshot shows the output of an add-action, each output file will be explained:

Each filename exists out of:

<date>-<time>_<patient>_<actor>_<action>_<input filename>_size-<nr of data entries>_<output suffix>.<output extension>

NameOutput sufficExtensionDescriptionRemarks

Validation file

VALIDATION-OK

VALIDATION-<###>-FAILED

.valThe report of the validation.

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

 

Global scheme PDF

globalscheme.pdfA visualisation of the global scheme in PDF format.-

Daily scheme PDF

dailyscheme-<date>.pdfA visualisation of the daily scheme in PDF format.

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

Export file

implicit by extension.expAn export of the contents of the vault.-

Input file

implict by extension.inpThe original input file.The filename does not include the number of data entries in the vault.

Configuration

This paragraph explains how to configure the EVS.

How to add a patient?

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.

How to add an actor?

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

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 recommended to put 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 (informed consent, therapeutic relation, ...) are set in function of the wanted behaviour.

Parameterisation

The next parameters can be passed when launching EVS:

Name

Values

Meaning
writeAsIstrue|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.

exportAfterUploadtrue|false

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

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

validateExportAfterUploadtrue|false

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

false: No validation is needed.

generateGlobalMedicationSchemetrue|false

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

false: No global scheme visualisation is needed.

generateDailyMedicationSchemetrue|false

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

false: No daily scheme visualisation is needed.

 

Appendix A: Folder structure EVS 1.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 the EVS.

Path

Reserved

path

Reserved

name

Explanation
EVS      (error)(error)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     (tick)(tick)

Everything that defines the behaviour of EVS, configured as needed by the user.

  \actors    (tick)(tick)All the actors that can be used by EVS.
  \log4j    (tick)(tick)Settings of the log4j library. Please refer to https://logging.apache.org/log4j/2.x/manual/configuration.html for more explanation.
  \patients    (tick)(tick)All the patients that can be used by EVS.
 \exe     (tick)(tick) 
  \certificates    (error)(error)The certificates used in the actor configuration files.
  \exports    (tick)

(tick)

The folder were the EVS-exporter will put exported vault contents, see EVS_Manual
  \interaction    (tick)(tick) 
   \input   (tick)(tick) 
    \katrien  (tick)(error) 
     \gp_van_gucht (tick)(error) 
      \add(tick)(tick) 
      \empty(tick)(tick) 
      \export(tick)(tick) 
      \removeID(tick)(tick) 
      \removeREF(tick)(tick) 
      \replace(tick)(tick) 
      \updateID(tick)(tick) 
      \updateREF(tick)(tick) 
    \patient_template  (tick)(tick) 
   \processed   (tick)(tick) 
 

\scenarios

     (error)(error) 
  \basic_example    (error)(error) 
 \system     (tick)(tick) 
  \dependency-jars    (tick)(tick) 

Appendix B: EVS exporter

 

Identification by Vitalink ID

  • No labels