Gazelle interoperability testbed offers a large set of validation services which enable the Healthcare IT developers and users to test the conformance to IHE specifications of the messages and documents produced by their systems. All those services are available all the year long through web services. In order to increase the ease-of-use of those services, IHE-Europe also offers, through the Gazelle portal, a web-based application named External Validation Service Front-End (aka EVSClient). The tool is accessible from the following URL.
It is the entry point for validating the following types of messages and documents:
Concerning the messages, documents and assertions based on XML format, we use two mechanisms. Validation can be based on schematrons or based on model. An application namedSchematron-based Validatorhas been developed, it gathers all the schematrons used by the validation tool and provides a web service to validate documents. Both Schematron and Model Based Validation of XML documents also checks that the documents are well formed and valid according to the XSD.
The picture below illustrates how the EVS Client works.
This section introduces the various engines the Gazelle team has put in place to validate the Clinical documents.
The following graph based on a slide from René Spronk (Ringholm bv), summarizes the CDA Validation options.
René Spronk wrote an excellent white paper on MIF, we recommend its reading in order to better understand the concepts. The definition extracted from that white paper states : "The Model Interchange Format (MIF) is a set of XML formats used to support the storage and exchange of HL7 version 3 artefacts as part of the HL7 Development Framework. It is the pre-publication format of HL7 v3 artefacts used by tooling. It is also the formal definition of the HL7 metamodel. The MIF can be transformed into derived forms such as UML/XMI or OWL."
We use the tool H3ET writen by JivaMedical (http://www.jivamedical.com/hl7-v3/h3et-product-overview-2.html). The jar can be downloaded from page Eclipse Instance Editor at the following URL :
This page describes how to perform a CDA document validation using the SChematron Validator tool which have been developed for the gazelle project :
CDA documents validation is performed using Schematrons. A Schematrons defines the requirements to be tested in a CDA document. Note that there are some other ways to perform CDA content validation. For instance on can use the CDA Tools from OHT. More information about the CDA tool can be found here.
Due to limitation in time, we have not yet used the CDA Tools from OHT, however this tool is in our pipe line and we are investigating its use.
There are different ways to validating CDA documents using the :
The Schematrons used by the EVS are available for download from the External Validation Service Front End GUI, under the menu : schematrons. The rest of this section is of interest for the readers who would like to understand the mechanism of creating a Schematron or reusing the templates that are available on the forge in order to develop validation Schematron for other CDA documents.
The sources of Schematrons are available on the INRIA forge. Note that
Here is the URL pointing the location of the Schematron project repository, you can use svn to import the project into your workspace.
To perform a validation of any of the documents which Schematron is available, you need to execute two actions :
To generate the "dist" folder you need to run the 'make-dist.sh' script, this shell script is classified under '/workspace/schematron/epSOS/tools'.
To run this script :
~/workspace/schematron/epSOS/tools$ ./make_dist.sh
After been generated the "dist" folder will contain the final preprocessed Schematrons which will be used to validate your documents.
You will notice that the CDA Schematrons are divided into two kind
Now that the Schematrons are available in the "dist", the validation of a document is done thanks to the 'validate.sh' script, this shell script is classified under '/workspace/schematron/epSOS/tools'.
To run this script :
~/workspace/schematron/epSOS/tools$ ./validate.sh ../dist/cda/pivot/ePrescription.sch ../src/cda/samples/ePrescription/ePSample.xml
The first argument of the 'validate.sh' script will be the preprocessed Schematron and the second argument will be the document to validate. The example above shows the command to validate an ePrescription sample with the ePrescription schematron.
The result of the validation will figure in the "test-doc.svrl" file, you'll just need to open that file to see the result.
In order to make the result of the validation more readable, a transformation from 'svrl' to 'html' is done in the 'validate.sh' script which will out come with an html file : 'results.html'.
Here below the overall architecture of the project :
The main used folders are :
src:Contains the necessary files for the validation of CDA, SAML, ATNA and PRPA documents.
Each of these folders (cda, saml, audit...) is organized as follows :
table_data : Contains xml files that list the codes used for the validation.
tools : Contains all the libraries used to perfom the preprocessing of the Schematrons and the validation of the documents.
This script is placed under '/workspace/schematron/epSOS/tools'.
The main goal of this script is to preprocess the developed Schematrons available under '/workspace/schematron/epSOS/src/*/sch' in order to build a consolidated one and make them available in the "dist" folder under '/workspace/schematron/epSOS/dist/'.
The preprocessing conssist mainly on :
This script is placed under '/workspace/schematron/epSOS/tools'.
The main goal of this script is to validate an xml documents thanks to a schematron.
Schematron validation takes four XSLT stages :
The result of the validation is placed in the 'test-doc.svrl' file under '/workspace/schematron/epSOS/tools'.
The main goal of inclusion is to merge a number of XML information sets into a single composite infoset. In this project the inclusion is used to merge all the required schematron for the validation of a document in one Schematron file.
For example : An epSOS ePrescription document like all the CDA documents, contains different set of clinical informations. Every set of informations is represented by a 'templateId'. Every 'templateId' plays the role of a reference for the schematrons.
Almost every set of informations represented by a 'templateId' have a Schematron able of validating it.
Knowing that the ePrescription document (templateId 1.3.6.1.4.1.12559.11.10.1.3.1.1.1) must contain a Prescription Section (templateId 1.3.6.1.4.1.12559.11.10.1.3.1.2.1), and the Prescription Section, for his turn, shall include a Prescription Item Entry Content Module (templateId 1.3.6.1.4.1.12559.11.10.1.3.1.3.2)...The ePrescription Schematron which will be able to validate an ePrescription document, must include the Prescription Section schematron, and that last shall include the Prescription Item Entry Content Module schematron.
A FreeMind map available in '/workspace/schematron/epSOS/docs' describe all the set up inclusion for the CDA documents.
Issues on CDA Schematrons can be reported in the Gazelle issue tracker available here.
A Schematron specifies the checks to be performed on the tested CDA document, those tests are in fact a set of declarations for a process, it act like (test this, tell me that!). To perform the schematron's specifications, a Schematron processor is necessary :
In order to get your Schematron up and running we propose two environments that you can download from Oxygen web site:
More informations about the Oxygen XML Editor are here.
The basic Schematronbuilding blocks are :
A phase is used to activate patterns (templates) so that they can perform a validation. To activate a pattern you simply need to declare it in a phase.
ex: Activating the pattern which id = p-1.3.6.1.4.1.12559.11.10.1.3.1.1.2-errors.
<phase id="all"> <active pattern="p-1.3.6.1.4.1.12559.11.10.1.3.1.1.2-errors"/></phase>
In our case we create two kind of phases that we called 'all' and 'no-codes'. The phase we called 'all' is intended to perform a global validation, and so we have to declare in this phase all the patterns included by the Schematron (errors + warnings + notes + codes). On the other hand, the phase we called 'no-codes' is intended to perform a validation without using pivot codes, and so we have to declare in this phase all the patterns except the ones validating the pivot codes (errors + warnings + notes).
<phase id="all">
<active pattern="p-1.3.6.1.4.1.12559.11.10.1.3.1.1.2-errors"/>
<active pattern="p-1.3.6.1.4.1.12559.11.10.1.3.1.1.2-warnings"/>
<active pattern="p-1.3.6.1.4.1.12559.11.10.1.3.1.1.2-notes"/>
<active pattern="p-1.3.6.1.4.1.12559.11.10.1.3.1.1.2-codes"/>
</phase>
<phase id="no-codes">
<active pattern="p-1.3.6.1.4.1.12559.11.10.1.3.1.1.2-errors"/>
<active pattern="p-1.3.6.1.4.1.12559.11.10.1.3.1.1.2-warnings"/>
<active pattern="p-1.3.6.1.4.1.12559.11.10.1.3.1.1.2-notes"/>
</phase>
The CDA templates performing pivot codes validation are placed under "schematron/epSOS/src/cda/sch/templates/codes".
The default Phase parameter "defaultPhase" defined in the Schematron is the one responsible of choosing which phase to perform while validation. We manipulate this parameter in the 'Make_dist' script in order to generate :
The main goal of inclusion is to merge a number of XML information sets into a single composite infoset.
In our case we use inclusion to merge all included patterns into a one final Schematron.
<xi:include parse="xml" href="templates/errors/1.3.6.1.4.1.12559.11.10.1.3.1.1.1.sch" xpointer="xmlns(x=http://purl.oclc.org/dsdl/schematron) xpointer(//x:pattern)">
<xi:fallback>
<!-- xi:include error : file not found : templates/errors/1.3.6.1.4.1.12559.11.10.1.3.1.1.1.sch -->
</xi:fallback>
</xi:include>
The example shows the syntaxe we use to include the patterns available in the template "1.3.6.1.4.1.12559.11.10.1.3.1.1.1.sch" into the Schematrons who initiated this command.
PS: In order to use inclusion, you shall declare the following name space : "xmlns:xi="http://www.w3.org/2003/XInclude"
The CDA model based validation is a tool to validate CDA documents based on model specification. The validation can be done from the EVSClient or from a webservice of validation. Actual online validators are BASIC-CDA and XD-LAB validator. You can use the tool to validate the conformance of CDA document with various specifications.
You can access to the validator from http://gazelle.ihe.net/EVSClient/home.seam. Then from the menu, you go to menu -->IHE -->CDA --> CDA Validation.
For ASIP or epSOS the path to the validation page are respectively :
The following screen capture shows the CDA document validation page.
The tool offers the possibility to perform both a schematron and/or a model based validation. Here in this page we concentrate on the Model Based CDA Validation. For more information about Schematron validation of CDA document please refer to :
In order to validate a CDA document you first need to click on the Add.. button and upload the document to validate.
Then you need to select the validator to use in the listboxes. You need to select at least one of them.
To actually perform the validation you need to click on the "Validate" button.
The validation process checks that :
To track the error, you can go directly to its location on the XML file by clicking on the picture link (green arrow), as it it shown on the figures above and below :
When you click there, you go directly to the XML view of the document CDA, and you can see the error, warning or notification message by setting the cursor on the picture that appear on the XML :
You can access to all validated CDA document by going to the menu HL7--> CDA --> Validated CDA :
Here you can search for CDA validated using the model based tools. You have to use the attribute Model Based Validator, like this :
The validation of CDA document based on model specification can be done using an online webservice. This web service is :
http://gazelle.ihe.net/CDAGenerator-CDAGenerator-ejb/CDAValidatorWS?wsdl.
This web service contains an important method for validation of CDA document, which is : validateCDADocument.
Access the External Validation Service Front-end
This application has been developed with the purpose of aggregating in a same user interface, the access to all validation services developed for IHE. Services called are the following:
In the menu bar of the user interface, we have chosen to sort the validators by affinity domains, currently to differents affinity domains are available: IHE and epSOS.
Contents which can be validated using this tool are: HL7v2.x and HL7v3 messages, CDA documents, SAML assertions, ATNA audit messages, certificates, XD* messages, XDW documents and DICOM object.
Schematrons section allows the user to download the schematrons which are used to validate XML files. Those schematrons are sorted according the type of object they validate.
Note that when using the EVS Client application, if you are NOT logged in, every document/message that you validate is stored in our database, referenced and available to everybody. If you do not want to have your documents/messages public, then you need to log in using the "CAS login", it uses your Gazelle's (EU-CAT) credentials.
The application External Validation Service Front-End can be used for validating the following objects:
If the user is not log on the application, his/her validation requests and results (that means the document/message submitted to the tool and the validation outcome) are available to everybody. We say that the result is "public"; it will be listed in the list of validation requests and everybody will be able to access and download both the validated file and the validation report.
If the user is logged on the application, by default, his/her validation requests and results will be set as "private". That means that he/she will be the only one to see the validation requests in the list and to access it. A permanent link is created for each validation request, the ones leading to a private request have restricted permissions; only the owner of the validation requests (the one who performed the validation) will be able to access this page.
A logged on user can choose to have a given validation request available to everybody. In this case, everybody will be able to list the request and to access both the validated file and the validation report. To do so, once the validation is performed (or at any moment from the result page), click on the "Make this result public" button. At any time, the owner of the request (and only him/her) will be able to change back the visibility of the result to private.
A logged on user can choose to keep his/her validation request (file + result) private but to allow certain users to access it also. In this case, clicking on the "share this result" button will generate a random key which, added to the URL will ensure that only the persons who know the permanent link (including the key) will be able to access the content of the validation request. The owner of the validation request will still be the only one to see the result in the list gathering all results but everyone knowing the link will be allowed to display the page.
Note that the admin and monitor users are able to access all the validation requests. It's obvious that they were use them only for verification purposes and will not publish neither use them for other purposes.
By XML file we mean all messages or documents based on XML (CDA, HL7v3 messages, XD* metadata ...) All those kinds of files can be validating using a schematron and/or a model-based validator. Once you have selected (in the top bar menu) the kind of XML object you want to validate, you will reach a page which ask you to upload the XML file to validate (be careful, the application allows only files with .xml extension) and to select the schematron and/or model-based validator to use.
Below is an example of the different steps for validating an XD-LAB report.
1. Select the menu CDA Validation in the IHE drop-down menu
2. Hit the "Add" button and select the XML file to validate in your system explorer
3. Select the schematron and/or a model-based validator to use in the drop-down list(s)
4. Finally, hit the "validate" button. After a while, the validation result will be displayed below the selection area.
The validation result panel is divided into differents panels :
"Download result" button enables you to download an XML file gathering the validation result. The relative stylesheet is provided here.
"Information" gives information about the validated file, the validation date, the schematron used and the result of the validation. In this part, you will also find a permanent link to the current validation result. If you have asked for both schematron and model-based validation, two tabs will be displayed, one by validation result.
1. Select the menu HL7v2 menu in the IHE drop-down menu
2. Upload or paste your message
Enter your message in the box (paste your message, ER7 format) OR upload the file containing your message (be careful, the application allows only files with .hl7 or .txt extension).
Then, you must choose the HL7 message profile to use to validate your HL7 message. The "Guess profile" button, just below the box, can be used to guess automatically the HL7 message profile to use, it extracts fields MSH-9 and MSH-12 and filter on those values.
Finally, to launch the validation process, hit the on the right side of the line corresponding to the message profile to use.
If you don't know the content of your file, or the validator you need to choose to validate your document you can use the Message Content Analyzer.
Now,
After you click on the refresh button, the validation permanent link is added to the table and the validation result is displayed in the tree.
This tool is still in developement, all remarks are accepted and you can open a Jira.
Attachment | Size |
---|---|
Home.png | 32.31 KB |
Analyze.png | 109.13 KB |
partContent.png | 101.2 KB |
Validation.png | 101.86 KB |
GazelleHL7Validator is the part of the Gazelle platform dedicated to the validation of HL7 messages
These validation services are available through a web service API so it can be integrated in your application. If you wish to validate messages occasionally you can use the Gazelle Validation Front-End called EVS Client which puts at your disposal a user interface to validate HL7 messages, CDA documents, XD* requests and so on.
Concerning HL7v2 validation: the application also gathers the HL7 conformance profiles and the HL7 tables (codes) which can be browsed by any user. For each conformance profile, you will find information about its issuer (actor, domain, transaction) and the message type and HL7 version. Each conformance profile can be bound to one or several HL7 tables which gather a list of allowed values for a given field of the message.
The User interface allows you to browse the validation requests received by the tool and the associated result. For each validation request, the tool keeps trace of the IP address of the caller. This is the way we choose to "protect" your work. That means that, using this IP address we can restrain the access to the data you have submitted (message content) and the results of those validations. The access rules are the following:
All the HL7 message profiles available are gathered in the tool. You can either select a profile by its full OID (if known) or put filters on the table columns. Each profile is viewable inline and can also be downloaded.
An HL7 resource is an XML file gathering several HL7 tables. An HL7 table is uniquely defined by an ID and contains the set of allowed values. Those tables are referenced in the message profiles and at validation time, the validation engine can check that the value of a given field of the submitted message comes from the set of allowed codes for this field. As for the message profiles, you can see those tables inline or download them
The documentation of the constraints expressed in the model-based validation service is available through the user interface under the HL7v3 validation service menu.
The web service API of the tool offers two methods:
The definition of the web service API is available at https://gazelle.ihe.net/GazelleHL7v2Validator-ejb/gazelleHL7v2ValidationWSService/gazelleHL7v2ValidationWS?wsdl.
The validate() method has the following prototype:
public String validate(String, String, String) throws SOAPException;
As we also need the client side of this validation service, we have created some useful projects listed below.
Note that this validation tool is also available through the simulators based on HL7v2.x (the messages sent and received by the simulator can be validated) and the EVSClient.
see : https://gazelle.ihe.net/content/model-based-validation-web-services
Error is human. We try to maintain the message profiles and HL7 tables doing our best but we may do mistakes. If you think there are errors in one/several of our message profiles, please report an issue in our bug tracking system with mention of the profie OID, error location, appropriate fix and reference to the documentation.
Bug tracking URL is https://gazelle.ihe.net/jira/browse/HL7VAL
This part of the documentation is dedicated to the manager/administrator of the GazelleHL7Validator tool.
The validation of HL7v2 messages within the Gazelle platform is based on
HL7 conformance profiles : XML files which describe the structure of the HL7 messages, they are constrainable. For each segment, field, component and subcomponent, the usage (required, optional, not allowed...), the cardinality and the datatypes are defined.
HL7 resources : XML files which declare a set of HL7 tables (kind of value sets). HL7 conformance profiles may reference HL7 table for a field, component or subcomponent, in order to constrain the set of allowed values for this element of the message
Both HL7 conformance profiles and HL7 resources are stored in the database of the tool along with an OID as well as the links between the conformance profiles and the resources. Note that the conformance profile file only reference the number of the the HL7 table, that means that, for a given conformance profile, the tool must be able to know in which HL7 resources looking for the table.
For each HL7 conformance profile, we need to know to which part of the technical framework, which message it applies. That's why, the HL7 conformance profiles are actually referenced in Gazelle Master Model. This enables us to link a conformance profile to a tuple (Domain, Actor, Transaction, HL7 version, message type [, order control code]). GazelleHL7v2Validator and Gazelle Master Model are two tools which have independent databases; as a consequence, the OID is used as a foreign key and two web services offered by Gazelle Master Model allow us to exchange data between those two applications:
The URL of the Gazelle Master Model web services are configurable within the application preferences part of GazelleHL7v2Validator. Make sure to reference the correct instance of Gazelle Master Model.
The following sections detail the different actions you may need to perform to maintain the set of conformance profiles available in your instance of GazelleHL7v2Validator. In order to keep a consistency between the references in Gazelle Master Model and the conformance profiles actually available in GazelleHL7v2Validator, only one instance of GazelleHL7v2Validator must be used per instance of Gazelle Master Model.
HL7 conformance profiles and HL7 tables are assigned OIDs. Remember that an OID must be unique through the world; that means that, the first thing to do when you install a new instance of GazelleHL7v2Validator is to update the root of the OIDs which will be generated by the application. Three OIDs are used which are defined in oid_generator table:
Currently, no user interface is available to perform this update, you will need to modify those values, manually, in the database.
Adding a new conformance profile consists in two things:
When you have just developing a new conformance profile, make sure that the transaction for which it is defined is registered into your instance of Gazelle Master Model (also check the actor and domain). Then, in GazelleHL7v2Validator, go to Administration --> Register new profiles (you must be logged on as an administrator).
A form is displayed (see screenshot below). Fill out this form with the information that match the conformance profile you are working with. Note that, first, only the domain drop-down list is displayed, then the list of actors is computed depending on the domain you have selected and finally the transactions will be available depending on the actor/domain pair previously selected.
As you can notice it on the screenshot, a button is available on the right of the "Profile OID" field. Clicking on this button will ask the application to automatically assign an OID to this conformance profile.
GazelleHL7Validator uses HAPI as validation engine. At validation time, message to validate is converted to a java object. Although all the message structures defined by HL7 are available in HAPI, in some cases, you will need to generate your own java class describing the message and tell the application in which java package it will find it. That is the case when IHE defines a new segment or change the structure of a message.
A project called gazelle-hl7-messagestructures available on Gazelle's forge and based on HAPI libraries is available to generate the java classes from the conformance profiles.
Finally, upload the XML file representing the conformance profile. As soon as the form is filled and the file is uploaded a "Submit" button is available. Hit this button, the file will be stored in database and the reference to the profile will be sent to Gazelle Master Model.
In order to facilitate the management of the registered profiles, we recommand to rename the XML file (on your file system) with the OID assigned to the conformance profile.
Basically, one HL7 resource is registered for each version of HL7. In some cases, you will need to customize a table for a given conformance profile or for a set of conformance profiles. In that case, you may need to register a new resource.
Go to Administration --> Register new resources. A new form is displayed (see screenshot below).
As for the conformance profile, you can ask the application to generate an OID. Once the form is filled out and the XML file is uploaded, hit the "Submit" button and the HL7 resource will be stored in database.
Tip for filling out the weight attribute
When the tool initializes a validation, it retrieves all the HL7 resources linked to the selected conformance profile. Then, at validation time, for each reference to an HL7 table, it browses the selected resources to extract the set of allowed values. We have defined a mechanism of weight which allow us to tell the application in which order it must browse the resources. Actually, it may happen that you have overriden a table defined in several of the selected resources. The resource is the higher weight will be processed first. HL7 resources defined by HL7 have usually a weight equals to 1.
In order to facilitate the management of the registered resources, we recommand to rename the XML file (on your file system) with the OID assigned to the resource.
Go to Administration --> Link profiles to resources.
This page is composed of four parts:
To link HL7 resources to conformance profiles, process as follows:
This section assumes that you have renamed your XML files according to the previous advices; that means that on your file system, you have a set of files named [profile_oid|resource_oid].xml. Maintenance will be easier if you store the profiles and resources in two different directories.
To update the content of a conformance profile or a resource, go to Administration --> Configure application.
In this page, a section is entitled "HL7 message profiles and tables import".
To update the conformance profiles, configure the "Path to HL7 message profiles" and hit the Import/Update profiles. The path must point to a directory on the server.
To update the conformance profiles, configure the "Path to HL7 tables" and hit the Import/Update tables. The path must point to a directory on the server.
In both cases, the application browses the given folder and lists all the XML files. For each file, it tries to retrieve the relative conformance profile / resource and compare the date of the file with the date of the last changed. If the file on disk is newer than the last changed, then, the file will be imported into the database to replace the old content.
This section describes how we have chosen to organize the conformance profiles and resources on Gazelle's forge and how they are maintained and managed.
Currently, both IHE Europe development team and the NIST contribute to maintain profiles.
A project is called Data and is available at https://gforge.inria.fr/scm/viewvc.php/Data/?root=gazelle. This project is made of two main folders:
Finally, this project has been checked out on the server hosting GazelleHL7v2Validator application and is periodically updated; which allows us to easily perform the update of the profiles and resources in the application.
The list of HL7v3 constraints is available under the administration tab, by going to the “Manage HL7v3 constraints file” menu. From there, it’s possible to delete individually each HL7v3 constraint by clicking on the trash icon. It’s also possible to import an XML file with the constraints written inside. This file must be generated with “Topcased” software from the OCL constraints. Be careful when using the “Delete and Generate” button, because all the existing HL7v3 constraints are first deleted before the new ones are imported.
You can restrict the messages an user is allowed to see in the logs page by editing the user preferences from the Administration -> Manage users’ accesses page. By adding an user, you can restrict the allowed IP addresses to constraint this user to see only the messages coming from this IP address. You can add many IP addresses for a single user.
Gazelle HL7 Validator embeds a web service interface to query the HL7v3 validation service. This validation service has been developed using the model-based engine. All model-based validation service exposes a web service which uses the same definition. Refers to the general documentation if you want to use this service from your application.
This service can be easily called using the EVS Client application. Start from IHE --> HL7v3 --> Validation.
The model has been generated from the HL7v3 schema available at ftp://ftp.ihe.net/TF_Implementation_Material/ITI/schema/HL7V3/NE2008/. Constraints have been written in accordance with the IHE specifications available in ITI Technical Framework Appendix O and the section from the ITI Technical Framework volume 2 which deals with the HL7v3 protocol.
The following messages can be validated using this service :
Two additional messages can be validated with this tool though they are not HL7v3 based (but defined in the context of XCPD):
To increase the code maintainability and the power of the validation of XML documents and messages, we chose to develop model-based validation services. Those services are available through the External Validation Service Front-end (aka EVSClient) of the Gazelle platform but you can also implement your own client to the web services of validation. All of them are built on the same model so you will only need to develop the client once and then "play" with the WSDL location.
Below, we describe the methods offered by the web services and the expected parameters.
We have develop a web service client for our proper needs to access these services. It's a Maven based project available in our Nexus repository. The latest release is available at http://gazelle.ihe.net/nexus/index.html#nexus-search;gav~~gazelle-ws-client*~~~
Validation Service | Location | Descriminators |
CDA documents |
https://gazelle.ihe.net/CDAGenerator-ejb/ModelBasedValidationWSService/ModelBasedValidationWS?wsdl |
|
ATNA logging messages |
|
IHE, epSOS |
XD* metadata |
https://gazelle.ihe.net/XDStarClient-ejb/ModelBasedValidationWSService/ModelBasedValidationWS?wsdl |
IHE, epSOS |
DSUB messages |
https://gazelle.ihe.net/XDStarClient-ejb/DSUBModelBasedWSService/DSUBModelBasedWS?wsdl |
IHE |
HPD messages |
https://gazelle.ihe.net/HPDSimulator-ejb/ModelBasedValidationWSService/ModelBasedValidationWS?wsdl |
IHE |
SVS messages | ||
HL7v3 messages |
IHE |
|
XDW documents |
https://gazelle.ihe.net/XDWSimulator-ejb/ModelBasedValidationWSService/ModelBasedValidationWS?wsdl |
IHE |
SAML assertions |
https://gazelle.ihe.net/gazelle-xua-jar/ModelBasedValidationWSService/ModelBasedValidationWS?wsdl |
IHE |
WADO queries |
https://gazelle.ihe.net/XDStarClient-ejb/WADOModelBasedWSService/WADOModelBasedWS?wsdl |
IHE |
This tutorial consist on the following steps :
SAML documents validation is performed using Schematrons. Those schematrons define the requirements to be tested in an SAML document.
There is two ways of validating your SAML document :
Since the SAML and the CDA schematrons are part of the same project, please see Importing of the schematron project in the CDA section here.
as for the CDA Document validation based on schematron, the SAML validation steps are :
The current SAML schematron are the final schematrons used for the SAML documents validation in the Gazelle External Validation Service. Those schematron are available in :
Here below the source schematrons available for the SAML validation.
Details about the processing of this scrip, please see here.
Since the developed SAML schematrons doesn't use inclusion, nor phases,and all the requirements fits into one file, the 'makedist' script preprocessing consists mainly on :
The validation thanks to this script remains the same as for the CDA validation.
Issues on SAML schematrons can be reported in the Gazelle issue tracker available here.
Gazelle WADO Validator is dedicated to the validation of WADO request message through SOAP web service calls.
The validation of WADO request can be performed against DICOM PS 3.18 or IHE RAD TF-3 (RAD-55 transaction) standards. Notice that perform a validation against IHE RAD TF-3 includes the validation against DICOM PS 3.18.
This validation service is available through a web service API so it can be integrated in your application. If you wish to validate messages occasionnaly you can use the Gazelle Validation Front-End called EVS Client which puts at your disposal a user interface to validate WADO requests, HL7 messages, CDA documents, XD* requests and so on.
The web service API of the tool offers three methods:
The definition of the web service API is available here.
The validateDocument() method has the following prototype:
public String validateDocument(String, String) throws SOAPException ;
EVSClient use the webservice to offer a GUI for validation the WADO requests.
To access to the validation page you go to http://gazelle.ihe.net/EVSClient/ and from the menu -> IHE -> DICOMWeb -> Validate, you will access to this page :
Select the validator "IHE - WADO", and then copy and past the WADO URL to validate.
Example :
Click then on the button validate.
The result of validation will then displayed. It contains checks about the structure of the WADO request entered :
Here an example of a result of validation of a wado request.
You can access to the results of already validated WADO requests using the menu -> IHE -> WADO -> Validation logs
XDS Metadata validator is a module developped to validate metadatas on XDS / XCA / XDR / epSOS transactions. he validation is done throw two methods : web service validation, and validation from the GUI using EVSClient.
This validator is under test, this is actually the first version of XDS Metadata validator.
As it was done for XDW validator, the validation of XDS metadata was based on a model driven validation. The principle is the same : we create a model driven description of the content of the XML Metadata, then we write constrains through the model, and from the technical framework.
The webservice of validation is installed on XDStarClient (http://gazelle.ihe.net/XDStarClient/home.seam). The URL to the webservice is : http://131.254.209.20:8080/XDStarClient-XDStarClient-ejb/XDSMetadataValidatorWS?wsdl. This webservice contains two principal methods :
We advice you to use the first method : validateXDStarMetadataB64, this can prevent from errors due to encoding, white spaces, etc.
Here are an example of a SOAPUI project that uses this webservice to validate an XDS-epSOS metadata Document as XML, and to validate a base64 XDS file. The soapui used is soapUI-3.5.
EVSClient offers a user interface to validate directly XDS Metadata. So you can upload an XDx metadata, then you can validate it, or you can directly write your metadata to the GUI of the tool. To access to EVSClient you have to go to this link : http://gazelle.ihe.net/EVSClient/. On EVSClient, we have divided the XDS metadata to two kind : epSOS and IHE.
To access to epSOS metadata validation, you have to go first to EVSClient GUI, the you have to select the menu : XDS --> epSOS --> epSOS Metadata Validation :
When accessing to the validation page, you are able to upload a metadata document, a soap request or response, or the body of the soap message, the two kind are accepted by the validator. Also you can write the content of the metadata by selecting the radio button "write-doc".
The reset button allow you to initialize the upload area.
The list of validators available for epSOS are :
These validators are conform to V2.2 of the document WP34_D342. For the validators of OrderService:list and PatientService:list, they are conform to the V2.2, so the validation is done for the version conform to XCF and not to XCA. The validation generate a list of errors, warning and notes.
To access directly to the epSOS validator GUI, you can go directly to http://gazelle.ihe.net/EVSClient/xds/epsos/validator.seam.
To access to IHE metadata validation, you have to go first to EVSClient GUI, the you have to select the menu : XDS --> IHE --> IHE Metadata Validation :
The IHE XDS validation has the same GUI components : an upload area and a selectOneMenu item, to select what validator to use for the validation. Actual validators for IHE metadatas are :
for each of epSOS and IHE metadata, a page that list all validated metadatas was created. To access to list of validated epSOS metadata, you have to go to the menu : XDS --> epSOS --> Validated epSOS Metadatas
This page explains how to check that the PDF embedded in an XDS-SD document is a valid PDF/A document. The IT-Infrastructure technical framework requires that XDS-SD document embedding a PDF, that the PDF shall be conform to PDF/A ISO 19005-1b
In order to validate the embedded PDF, first the PDF needs to be extracted from the CDA document. Then it needs to be validated.
When validating CDA documents that contains embedded PDF documents, the EVS Client now proposes a link to validate the embedded PDF.
Use the HL7 -> Validate CDA tool , validate your CDA. If you click on the HTML tab to render the document. Then the embedded PDF will be displayed. You can then save it on your disk. Otherwize you can click on the link on the top of the document to access the PDF/A validation of the document.
Validation of PDF/A document is challenging topic and many tools are available to perform that task. More information about validation can be found in the following report :
Please find in that PDF/A Competence Center a list of PDF/A validation tool of interest. We are describing here how to perform the validation using two of the tool listed in the PDF/A Competence Center site : pdfaPilot2 from Callas. The tool is available for windows and mac platform. You can ask for a 7 day evaluation license.
An alternative tool : http://www.validatepdfa.com/fr/ will to validate a PDF/A per email. The report is sent to your mailbox.
You might as well use the JHOVE tool for the validation of your documents. See in the following example the output for a valid PDF/A-1 Level B document.
~$ jhove -m PDF-hul Inconnu-16.pdf Jhove (Rel. 1.4, 2009-07-30) Date: 2011-03-28 23:10:58 CEST RepresentationInformation: Inconnu-16.pdf ReportingModule: PDF-hul, Rel. 1.8 (2009-05-22) LastModified: 2011-03-28 23:10:47 CEST Size: 284080 Format: PDF Version: 1.3 Status: Well-Formed and valid SignatureMatches: PDF-hul MIMEtype: application/pdf Profile: Linearized PDF, ISO PDF/A-1, Level B PDFMetadata: Objects: 37 FreeObjects: 1 IncrementalUpdates: 1 DocumentCatalog: PageLayout: SinglePage PageMode: UseNone Info: ...
Generate valid PDF/A 1b documents
Note that OpenOffice is able to generate valid PDF/A documents
Please see also the C# and Java use of iText to generate PDF/A documents : there
Project Overview
The XDW validation service has been developed to validate XDW documents generated by XDW actors (Content Creator and Content Cpdater). The validation is done through two methods : web service validation, and validation from the GUI using EVSClient.
This validator is under test, this is actually the first version of XDW validator.
Summary of the validation process
This validation was based on a model driven validation. The content of XDW Document was presented as an UML model, each specification on the technical framework was writen as a constraint on this model. After that, a code generator was used to generate a java model, and a java validator classes. The code generated has an XML binding, using jaxb annotations. This binding allow to read XDW documents, to convert them to java instances, and then to validate them. The code of templates can be uploaded from the svn repository :
https://scm.gforge.inria.fr/svn/gazelle/branches/simulators/XDW-parent/net.ihe.gazelle.xdw.model/
Here there are an explanation of how to do the checkout of sources from the svn sources repository.
Webservice validation
A webservice was implemented to validate XDW document. The webservice contains two methods of validation, the first one is for the XDW document content, the second is a validation for XDW document encoded on base64. We recommand to use the second validation method, because some problems oN THE validation can occure when copying the content of the XML to the webservice.
The webservice used is :
Here are an example of a SOAPUI project that uses this webservice to validate an XDW Document as XML, and to validate a base64 XDW file. The soapui used is soapUI-3.0.1
User interface validation
EVSClient offers a user interface to validate directly XDW files. So you can upload an XDW file, then you can validate it. To access to EVSClient you have to go to this link : http://gazelle.ihe.net/EVSClient/. The tools for the validation of XDW documents is in this link : http://gazelle.ihe.net/EVSClient/xdw/validator.seam. You can access to this link from the menu on the EVSClient project : XDW --> XDW Validation.
The result of validation is like this :
The validation contains three types of validation :
For each validation, we generate a summary with the Validation Date and the Validation Status. Also for each validation we generate a unique permanent link, that we can refer to it when we need. The permanent link is like this : http://gazelle.ihe.net/EVSClient/xdwResult.seam?id=XXX. From this link, we can revalidate the document, or we can download the entire XDW file. Also we can view on this link the content of the XDW file, on the bottom of the html page.
XSL presentation
This tool offers the possibility to visualize the content of the XDW document using a stylesheet. The result of the view is generally like this :
This representation contains many informations from the XDW documents :
List of validated documents
We can access to the list of XDW documents validated by users, using the menu XDW --> Validated XDWs.
In this page, we can view all XDW documents, or we can perform an advanced search of documents. The seach can be done using attributes like validation status, user, and validation date. Each document has an unique ID.