To help developing parties to implement message specifications, eHealth platform provides Schematron files. 

By its nature, an XML Schema (e.g. the KMEHR xsd) has limitations in expressing constraints. A Schematron file goes a step further e.g. it can require the presence of specific attributes in the root element of another element or it can define certain constrains on one element based on a different element.

The schematron files that are published here are only to optionally help in creating and validating messages, the ultimate responsibility of a sent message rests with the sending party. For instance, even a schematron file cannot validate if certain combinations of medical pathologies make sense in a medical logic.


The 'overview.xml' gives an overview of the locations where to find the most recent version of the schematron files. Note for every message specification there can be only one schematron file available: the one for the most recent version of that transaction.

The overview.xml file.

Example fragment of this overview.xml:






This fragment should be read like this:

<name>: Name of the transaction

<path>: URL of the schematron

<hash>: Unique hash value of this version of the schematron. If the schematron files changes, this hash will change.

Proposed use

Using the overview.xml file, a software implementation that uses the schematron can follow this logic to make sure it always has the latest schematron file for a certain message:

1. Time Ti: Software downloads the latest schematron file and its hash hl for project Px via the locations found in overview.xml

2. Time Ti+1h: Sofware retrieves the new schematron hash in overview.xml for project Px: hn

3. Software compares hl to hn. If not equal go to step 1

4. i = i +1, go to step 2