The CDA validation engine of the existing Online-CDA-Validators (such as ELGA Online-CDA-Validator, the "eHealth Suisse" Online-CDA-Validator or the medshare Testserver) was made available in the eHealth Connector. Many thanks to ELGA!
All Online-CDA-Validators are designed for the technical examination of test CDA documents, not containing any real patient data only! With the eHealth Connector you are able to validate productive CDA documents within your safe infrastructure.
The following validation mechanisms are supported by the eHealth Connector:
Schema validation (W3C)
Schematron (ISO Schematron)
Embedded PDF/A Validation
This feature was released with the spring 2016 release R201604 and optimized with spring 2017 release R201704. veraPDF was added with autumn 2017 release R201711. With release R201807 the external compenents were updated t:
3-Heights™ PDF Validator V126.96.36.199
The main entry in the convenience API for the CDA Validation is the following class:
It supports the following main convenience methods, which can be used by providing the CDA document as File, StreamSource or byte:
Perform CDA validation
Performs all three following validation steps in the given order.
Validates your CDA document against your instance of the CDA XML Schema Definition (XSD).
Validates your CDA document against your Schematron rules.
Validates all embedded PDF documents within your CDA document whether they are valid PDF/A documents. Please notice that there are two different PDF validation engines integrated in the eHealth Connector_
3-Heights™ PDF Validator: This validation engine is NOT Open Source. If you want the eHealth Connector to perform the PDF/A validation using this engine, you are required to buy a license .
veraPDF : If you have no valid 3-Heights™ PDF Validator license installed on your machine the eHealth Connector will use this engine for the PDF/A validation. This is is the way the eHealth Connector preserve its Open Source spirit.
After a performed validation you want to inspect the validation results. The validation results can be accessed with the following class:
It supports the following main convenience methods:
Inspecting validation results
This methods allow to inspect CDA validation results. There are for both types of methods three methods: one for Schema
(Xsd), one for Schematron (Sch) and one for PDF/A (Pdf) validation results.
Returns true, when the CDA document is valid regarding this type of validation and false otherwise.
Returns an instance of a validator specific class that contains all necessary information.
Xsd: String result of the XML Schema validation (single string)
Sch: List result of all fired Schematron patterns, rules, successful reports and failed asserts of the Schematron validation (multiple classes)
PDF: List result of all messages fired by the PDF/A validation (string and severity)
The easiest way to get familiar with the eHealth Connector Convenience API is to look at the provided examples in the eHealthConnector demo project, which can be downloaded from the sourceforge SVN (/demo). It demonstrates how to validate sample CDA files using the eHealth Connector convenience API.
There is a dotnet demo application which provides a UI to start the demo functions. You will find it under: /demo/dotnet.
Another way is to start the java demo application via the Main.java class in /demo/java/ehealthconnectorDemo and provide the appropriate arguments. This can either be done from your IDE (e.g. Eclipse) or from the shell. When you start the main class with the parameters “DemoValidation configFn cdaFn”, the demo will validate the CDA document specified using the cdaFn argument against the schema/schematron resources configured in the config file using the configFn argument and displays the validation results on the console.
If you are an application programmer and want to see, how the API is used to validate CDA documents, take a look inside the java or dotnet demo project. The methods “org.ehealth_connector.demo.validation.DemoValidation.doDemo()” (java demo application) and “eHealthConnectorDemo.MainForm.btnCDAValidationDemo_Click” (dotnet demo application) are good starting points.
The CDA validation needs configuration for several parameters. The configuration is stored in a xml file. Before you validate against your own Schemas/Schematrons you need to configure them in a personalized config file.
Your are free in naming the config file (e.g. config.xml). You need to provide its full path and filename when instancing the CdaValidator class.
Refer to the XML schema of the config file where you find also the documentation of the different elements.
used for the demo application when validating against the ELGA enhanced CDA Schema and ELGA Schematrons.
Notes to the 3-Heights™ PDF Validator and its installation
An eHealth Connector deployment with veraPDF Validator is similar to a "Community Edition" and an eHealth Connector deployment including 3-Heights™ PDF Validator is therefore similar to a "Enterprise Edition".
Installation / configuration checklist for 3-Heights™ PDF Validator:
Make sure you install exactly the same version of the PdfValidatorAPI as the VALA.jar (which is included in the eHealth Connector). With the current release this must be version 188.8.131.52.
Make sure you install the PdfValidatorAPI in the correct plattform edition (32- or 64-bit)
Confiigure your license key in the configuration file mentioned above (element: license-key).
Bind the eHealth Connector with your PdfValidatorAPI installation:
On Windows with the eHC Jar (Java):
Make sure you provide the VM argument for the java.library.path pointing to your PdfValidatorAPI bin folder:
On Windows with the eHC Dll (.Net):
Make sure you provide the IKVM argument for the java.library.path pointing to your PdfValidatorAPI bin folder.
For this reason create an appSettings entry in your app.config:
<appSettings> <add key="ikvm:java.library.path" value="<path to your PdfValidatorAPI.dll>;" /></appSettings>
On Linux with eHC Jar (Java):
Copy the PdfValidatorAPI in your /usr/lib/ directory:
With the release R201807, the veraPDF validation-model, version 1.12.1 has been integrated. Regarding veraPDF 1.12.1, the following issues are currently known:
veraPDF 1.12.1 seems not fully thread-save (further investigations required). The batch and random validation features of the eHealth Connector may therefore fail.
veraPDF does not provide the same results as the 3-Heights PDF Validator from PDF Tools.
veraPDF does not provide the same results when used by the eHealth Connector in Java and .Net. The following messages are are currently suppressed by the eHealth Connector because they are only shown when using it as .Net dll, but they seem to be false positives (see VeraPdfValidator.java)