...

...

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.

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:

Image Removed

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.

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.

Image Removed

Which actions for Medicationscheme?

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

to be translated:

ADD voegt nieuwe lijnen toe, dus daar sturen we nog geen vitalink URI mee waardoor de kluis het als een 'nieuwe' lijn beschouwt

REPLACE doet ( als ik me niet vergis) eerst een empty van de kluis door een puttransactionsetrequest te doen zonder medicatielijnen. Vervolgens een tweede call met daarin de lijnen van het inputbestand

ADD vraagt achterliggend ook eerst de hele kluisinhoud op, zodat we de nieuwe lijn kunnen toeveogen aan de bestaande kluisinhoud

want alles wat je niet zou meesturen wordt gewist uit vitalink

UPDATEF vraagt ook eerst alles op, en tracht dan de medicatielijn(en) uit het inputbestand op te zoeken in Vitalink, om vervolgens die lijnen als gewijzigd te markeren in uitgaande bericht

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:

Image Removed

Action "export"

This action will export the contents of the vault that belong to transactiontype "Medicationscheme", without any change to the vault itself. EVS 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:

Image Removed

Action "generateREF"

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

If an EVS REF exists already in the MSE transaction, no new EVS REF will be generated.

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

Image Removed

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.

Image Removed

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.

Image Removed

The next actions will take place:

• an MSE transaction with EVS REF not yet existing in the vault will be added to the vault, together with all TS transactions which are linked with this MSE transaction
• an MSE transaction with EVS REF already existing in the vault will cause an update if any difference between the input-transaction and vault-transaction is found
• all MSE transactions without corresponding EVS REF in the input file will be removed from the vault

...

Where to put the acceptation-environment-token from Vitalink ?

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: 

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

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.

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:

Image Added

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.

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.

Image Added

Which actions for Medicationscheme?

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

To be translated:

Actions

ADD voegt nieuwe lijnen toe, dus daar sturen we nog geen vitalink URI mee waardoor de kluis het als een 'nieuwe' lijn beschouwt, 

ADD vraagt achterliggend ook eerst de hele kluisinhoud op, zodat we de nieuwe lijn kunnen toevoegen aan de bestaande kluisinhoud want alles wat je niet zou meesturen wordt gewist uit vitalink (zoals updateREF)

REPLACE doet ( als ik me niet vergis) eerst een empty van de kluis door een puttransactionsetrequest te doen zonder medicatielijnen. Vervolgens een tweede call met daarin de lijnen van het inputbestand

UPDATEREF vraagt ook eerst alles op, en tracht dan de medicatielijn(en) uit het inputbestand op te zoeken in Vitalink, om vervolgens die lijnen als gewijzigd te markeren in uitgaande bericht

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:

Image Added

Action "export"

This action will export the contents of the vault that belong to transactiontype "Medicationscheme", without any change to the vault itself. EVS 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:

Image Added

Action "generateREF"

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

If an EVS REF exists already in the MSE transaction, no new EVS REF will be generated.

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

Image Added

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.

If you want to 'empty' the medicationscheme in the vault. Drop an empty textfile OR a valid XML without any MSE in the REPLACE folder.

In the next example, after processing the next 3 input files, the vault contains 4 transactions.

Image Added

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.

Image Added

The next actions will take place:

• an MSE transaction with EVS REF not yet existing in the vault will be added to the vault, together with all TS transactions which are linked with this MSE transaction
• an MSE transaction with EVS REF already existing in the vault will cause an update if any difference between the input-transaction and vault-transaction is found
• all MSE transactions without corresponding EVS REF in the input file will be removed from the vault

If the input-file contains MSE transactions with EVS REFs that are not unique, the action will not be executed and an error will be thrown.

Action "updateREF"

Looking a lot like updateSchemREF, this action will update 1 or more targetted MSE transactions within the transactiontype MedicationScheme on the vault without touching the other MSE's, not included in the source file. So the source file does NOT include the complete MS with updated + non-updated MSE's but an MS with only the MSE's you want to alter.

Image Added

An ERROR status is thrown in following cases:

• 1 or more of the included MSE in the MS of the sourcefile contains an EVSREF that was not found in the MS on the vault, no update will happen untill corrected
• 1 or more of the included MSE in the MS of the sourcefile does not contain an EVSREF, no update will happen untill corrected

If no difference is found between input MS and vault MS, no update will happen.

The next actions will take place: 

• If no ERROR is detected in the source file, before executing the update (PutTransaction), a list is provided in the EVS console of all MSE's entries with their maching EVSREF's found within the targetted MS on the vault, together if it will be updated or not.

Image Added

• an MSE transaction with EVSREF already existing in the vault will be updated if any difference between the input-MSE transaction and vault-MSE transaction is found and versionnr of MSE + MS will be +1

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:

Image Added

Action "empty"

This action will remove all transactions from the vault that belong to transactiontype "Sumehr". 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 transactions of transactiontype "Sumehr":

Image Added

Action "export"

This action will export the contents of the vault that belong to transactiontype "Sumehr", without any change to the vault itself. EVS 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":

Image Added

Action "generateRef"

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

If an EVS REF exists already in the Sumehr transaction, no new EVS REF will be generated.

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

Image Added

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.

Image Added

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.

Image Added

Action "updateRef"

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

Image Added

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. EVS 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 an EVS REF exists already in the Diarynote transaction, no new EVS REF will be generated.

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.

Image Added

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:

Image Removed

Action "empty"

This action will remove all transactions from the vault that belong to transactiontype "Sumehr". 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 transactions of transactiontype "Sumehr":

Image Removed

Action "export"

This action will export the contents of the vault that belong to transactiontype "Sumehr", without any change to the vault itself. EVS 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":

Image Removed

Action "generateRef"

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

If an EVS REF exists already in the Sumehr transaction, no new EVS REF will be generated.

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

Image Removed

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.

Image Removed

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.

Image Removed

Action "updateRef"

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

Image Removed

Which actions for Diarynote?

...

the input file.

Image Added

Which actions for PopulationBasedScreening?

Action "export"

This action will add a transaction export the contents of the vault that belong to transactiontype "PopulationBasedScreening", without any change 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.itself. EVS will do this action once for each dropped file, without parsing this file.

Which actions for ChildRecord?

Action "export"

This action will export the contents of the vault that belong to transactiontype "DiarynoteChildRecord", without any change to the vault itself.  EVS EVS 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 an EVS REF exists already in the Diarynote transaction, no new EVS REF will be generated.

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.

Image Removed

...

, without parsing this file.

Which actions for Vaccination?

Action "export"

This action will update the transactions export the contents of the vault that belong to transactiontype "Diarynote" identified by the EVS REF in the input file.Vaccination", without any change to the vault itself. EVS will do this action once for each dropped file, without parsing this file.

An overview pdf is generated automatically at the end of the export, visualizing all vaccinations of this patient in 1 list.Image Removed

Processed-folder

...

The template examples are given for 3 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:

...

...

Path								Reserved path	Reserved name	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.
	\exe
		\certificates								The certificates used in the actor configuration files.
		\exports								The folder were the EVS-exporter will put exported vault contents, see AppendixB:EVSexporterAppendix B: EVS-exporter
		\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: EVS-exporter

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.

...

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:

1. Enter a referencedate in the xmlrequest (underneath <usuallanguage> as seen in this chapter) to the first startmoment of the medication. 
2. change startup parameter to shift_and_tag
3. send the xmlrequest to the vault

...

e.g. -dailyMedicationSchemeDate="2016-01-13" -shiftAction=no_tag_and_no_shift

Appendix D: F.A.Q.

Q1: EVS could be started but error is shown of 'InvalidTherapeuticRelationException'

...