[Deprecated] External Validation Services

Warning: This documentation is out-dated, newest version of the documentation is available at https://gazelle.ihe.net/gazelle-documentation

Overview

 

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.

 

[Deprecated] CDA Document Validation

Warning: This documentation is out-dated, newest version of the documentation is available at https://gazelle.ihe.net/gazelle-documentation

 

This section introduces the various engines the Gazelle team has put in place to validate the Clinical documents.

[Deprecated] CDA Validation using MIF

Warning: This documentation is out-dated, newest version of the documentation is available at https://gazelle.ihe.net/gazelle-documentation

Introduction

The following graph based on a slide from René Spronk (Ringholm bv), summarizes the CDA Validation options. 

CDA Validation Options

  1. We verify that the CDA is a well-formed XML Document. This corresponds to 1 on the graphic
  2. We verify that the CDA document is valid against the CDA Schema  
  3. If we have a template specific schema, then we use that one to check the validity of the CDA document.
  4. From the CDA implementation guide (IHE technical framework, epSOS specs,...) some business rules are expressed into a schematron document that we use to validate the CDA document.

MIF : Model Interchange Format

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

CDA Validation

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 : 

The jar is integrated to the Schematron Validation Tool, the MIF used are the one from the CDA R2. 

[Deprecated] CDA Validation using Schematrons

Warning: This documentation is out-dated, newest version of the documentation is available at https://gazelle.ihe.net/gazelle-documentation

This page describes how to perform a CDA document validation using the SChematron Validator tool which have been developed for the gazelle project :

Overview

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. 

How to perform a CDA document Validation

There are different ways to validating CDA documents using the :

  1. Using the Gazelle External Validation Service Front End. This tool provide a GUI to access the different validation services configured in the Gazelle plateform. For CDA validation is one of the services proposed by that tool.
  2. Download the Schematrons source code on your computer and perform the validation using an XSLT Processor. The Schematrons used by the External Validation Service Front End can be downloaded from the GUI
  3. Using the Schematron Validation Webservice. This solution might not be the easiest to implement, however it presents the advantage that it can be integrated in an application. 

How to get the current CDA schematrons

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 

Importing the Schematron project

Here is the URL pointing the location of the Schematron project repository, you can use svn to import the project into your workspace.

Validation steps

To perform a validation of any of the documents which Schematron is available, you need to execute two actions :

  1. Generate the "dist" folder
  2. Validate the document

Generating the "dist" folder

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 

  • Pivot : The Schematrons in this folder uses epSOS pivot codes listed in the epSOS_MVC_V1_5.xls for the validation 
  • Friendly : The Schematrons in this folder doesn't use epSOS pivot codes for the validation

Validating the CDA document

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. 

Validation result

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

 

 How does CDA validation works

Architecture

Here below the overall architecture of the project :

global architecture

The main used folders are :

src:Contains the necessary files for the validation of CDA, SAML, ATNA and  PRPA documents.

Source folder

 

Each of these folders (cda, saml, audit...) is organized as follows :

Source folder for CDA

  • samples : Contains valid samples (.xml)
  • sch : Contains the developed Schematrons (.sch)
  • xsd : Contains the used schema (.xsd)

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.

'Make_dist.sh' script 

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 :

  • Resolving inclusion
  • Reformating and indenting the schematrons
  • Building xsl from schematrons
  • Building the phases of the schematrons
  • Building friendly and pivot Schematrons (just for CDA)

'Validate.sh' script

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 val­i­da­tion takes four XSLT stages :

  • Pro­cess in­clu­sions
  • Pro­cess ab­stract pat­terns
  • Com­pile the schema
  • Val­i­date

The result of the validation is placed in the 'test-doc.svrl' file under '/workspace/schematron/epSOS/tools'.

Inclusion

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. 

Freemind map

A FreeMind map available in '/workspace/schematron/epSOS/docs' describe all the set up inclusion for the CDA documents. 

How to report a bug on CDA schematrons

Issues on CDA Schematrons can be reported in the Gazelle issue tracker available here.

How to develop / correct a schematron

Schematron is a ...

  • Well-formed XML document
  • Technique to specify and test statements about your XML document
    •  Elements
    • Attributes
    • Content

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 :

  • It reads and interprets your Schematron tests
  • Applies the tests to your documents
  • Reports back with any messages

Schematron development environment

In order to get your Schematron up and running we propose two environments that you can download from Oxygen web site:

  • Oxygen XML plugin for Eclipse
  • Oxygen XML Editor

More informations about the Oxygen XML Editor are here.

Writing Schematron

The basic Schematronbuilding blocks are :

  • Phases : Activate different families called patterns. (ex: There's two phases for the validation of the CDA documents, the "pivot" and the "friendly" ) 
     
  • Patterns : Rules are grouped into families called Patterns. 
     
  • Rules : Tests are collected into rules, which apply to particular XML elements (context)
     
  • Assertions : Conditions to test, and are divided into two kind 
    • assert : If the condition is true, fine! If it is not, you get your message
    • report : If the condition is true, you get your message
  • Messages : the log you get back if the condition fail (assert), or succeed (report). We defined four kind of messages in this project. Messages starting with :
    • "Error:" are interpreted as error messages
    • "Success:" are interpreted as success messages
    • "Note:" are interpreted as note messages
    • "Warning:" are interpreted as warning messages

Using Phases

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 :

  • Schematrons using pivot codes validation under 'schematron/epSOS/dist/cda/pivot' by setting the "defaultPhase" to "all"
  • Schematrons not using pivot codes validation under 'schematron/epSOS/dist/cda/friendly' by setting the "defaultPhase" to "no-codes"

Using inclusion

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"

 

[Deprecated] CDA model based validation

Warning: This documentation is out-dated, newest version of the documentation is available at https://gazelle.ihe.net/gazelle-documentation

Introduction

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.

  • Basic CDA (conformance to HL7 CDA specifications)
  • CCD
  • IHE Pharmacy domains profiles : 
    • Laboratory Domain (LAB)
      • IHE - XD-LAB : Sharing Lab Report profile
    • Pharmacy Domain (PHARM)
      • IHE - PHARM Prescription : Pharmacy Prescription profile
      • IHE - PHARM Dispensation : Pharmacy Dispense profile
      • IHE - PHARM Pharmaceutical Advice : Pharmacy Pharmaceutical Advice profile
    • IT-Infrastructure Domain (ITI)
      • IHE - XDS-SD : Cross-Enterprise Document Sharing of Scanned Documents profile
      • IHE - BPPC : Basic Patient Privacy Consents profile
    • Radiology domain (RAD)
      • IHE - XDS-SD XDS-I.b : Cross-Enterprise Document Sharing for Imaging profile
    • Patient Care Coordination Domain (PCC)
      • IHE - PCC BASIC : validation according to the list of templates of PCC domain
    • Cardiology Domain (CARD)
      • IHE - CARD Cath Report Content (CRC) : Cath Report Content profile
      • IHE - CARD Registry Content Submission (RCS-C) : Registry Content Submission profile
  • epSOS CDA
    • epSOS - Patient Summary Pivot
    • epSOS - ePrescription Pivot
    • epSOS - eDispensation Pivot
    • epSOS - Patient Summary Friendly
    • epSOS - ePrescription Friendly
    • epSOS - eDispensation Friendly
    • epSOS - eConsent
    • epSOS - Scanned Document
    • epSOS - HCER HealthCare Encounter Report
    • epSOS - MRO Medication Related Overview
  • ASIP 
    • ASIP - CDA Structuration minimale
    • ASIP - Fiche de Réunion de Concertation Pluridisciplinaire (FRCP)
  • ESANTE
    • LUX - Header Specifications

 

Validation from EVSClient

Access to the tool

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 :

  • CI-SIS France --> CDA --> CDA Validation and 
  • epSOS --> CDA --> CDA Validation

cda

The following screen capture shows the CDA document validation page. cd2

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.

Presentation of the GUI showing the results of the validation

The validation process checks that :

cda5

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 : 

down

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 : 

fidure

Access to all validated CDA document

You can access to all validated CDA document by going to the menu HL7--> CDA --> Validated CDA : 

cda6

Here you can search for CDA validated using the model based tools. You have to use the attribute Model Based Validator, like this :

cda7

Validation using the webservice 

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

[Deprecated] External Validation Service Front-end

Warning: This documentation is out-dated, newest version of the documentation is available at https://gazelle.ihe.net/gazelle-documentation 

Access the External Validation Service Front-end

Introduction

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:

  • Gazelle HL7 Validator for HL7v2.x and HL7v3 messages
  • Schematron-based Validator (CDA, Audit messages, HL7v3, assertions...)
  • Model-based validator for CDA
  • Model-based validator for XD* messages
  • Model-based validator for XDW
  • Model-based validator for DSUB
  • Model-based validator for SVS
  • Model-based validator for HPD
  • Certificates validation
  • JHOVE for PDF files validation
  • Dicom3Tools, DCMCHECK, Dcm4Che, Pixelmed for validating DICOM objects

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.

Important notice

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.

[Deprecated] User Manual

Warning: This documentation is out-dated, newest version of the documentation is available at https://gazelle.ihe.net/gazelle-documentation 

The application External Validation Service Front-End can be used for validating the following objects:

  • HL7 CDA files
  • HL7v2.x and HL7v3 messages
  • HPD messages
  • SVS messages
  • DSUB metadata
  • SAML assertions
  • Audit messages
  • Certificates
  • DICOM objects
  • PDF files
  • XD* messages (metadata)
  • XDW documents

Note about the privacy of validation results

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.

Validate an XML file

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

cda menu

2. Hit the "Add" button and select the XML file to validate in your system explorer

upload cda

3. Select the schematron and/or a model-based validator to use in the drop-down list(s)

select schematron

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.

Validate an HL7v2.x message

1. Select the menu HL7v2 menu in the IHE drop-down menu

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

hl7 message content

 

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 arrow on the right side of the line corresponding to the message profile to use.

select profile

How use Message Content Anaylzer

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.

  1. Upload your file
  2. Click on analyze
  3. You should have the file description in result part (if you have any trouble, don't hesitate to write a Jira)

 

Now,

  • You can click on each part of the tree or in the table to display the conten. You also can download each part.

  • You can click on the green arrow or validate part (I'm lucky validation can directly send you to the result valitation of your part)

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.

AttachmentSize
Image icon Home.png32.31 KB
Image icon Analyze.png109.13 KB
Image icon partContent.png101.2 KB
Image icon Validation.png101.86 KB

[Deprecated] Gazelle HL7 Validator

Warning: This documentation is out-dated, newest version of the documentation is available at https://gazelle.ihe.net/gazelle-documentation 

Application overview

GazelleHL7Validator is the part of the Gazelle platform dedicated to the validation of HL7 messages

  • HL7v2.x messages are validating against HL7 conformance profiles. The validation engine is based on HAPI libraries and the conformance profiles are written by the Gazelle team (helped by NIST).
  • HL7v3 messages are validating using a model-based engine

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.

User interface

Browse validation requests

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:

  • Administrator users have access to all validation requests and are allowed to permanently delete some of them on user requests
  • Not logged in users have only access to the validation requests coming from the same IP address as the one they are using when browsing the requests
  • Logged in users (Gazelle CAS) can ask the administrator of the tool to register a set of IP addresses they are allowed to see.

Browse HL7 message profiles

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.

Browse HL7 resources

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

Browse HL7v3 validation service documentation

The documentation of the constraints expressed in the model-based validation service is available through the user interface under the HL7v3 validation service menu.

Web service API

Gazelle HL7v2.x validation service

The web service API of the tool offers two methods:

  • validate(): validates the given message against the given message profiles and sends back a validation report
  • about(): gives information about the running version of the tool

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;
  • The first parameter is xmlValidationMetadata, it is an XML formatted String respecting the XSD schema given at http://gazelle.ihe.net/xsd/MessageMetadata.xsd. By now, this parameter is not used but our intent is to add custom validation. That means that, in addition of the basic Hapi validator, the user will be able to put additionnal validation requests as constraints on field usage, component value...
  • The second parameter is xmlValidationContext, it is an XML formatted String respecting the XSD schema given at https://gazelle.ihe.net/xsd/ValidationContext.xsd. This parameter is mandatory since it gives information about the HL7 message profile to use for the validation process. 
  • Finally, the third String stands for the message to validate itself. The message must use ER7 syntax (ie. pipe-based syntax)

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.

Gazelle HL7v3 validation service

see : https://gazelle.ihe.net/content/model-based-validation-web-services

Bug tracking

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

[Deprecated] HL7 Conformance profiles and HL7 tables management

Warning: This documentation is out-dated, newest version of the documentation is available at https://gazelle.ihe.net/gazelle-documentation 

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:

  • IHEConcepts: This web service lists the different concepts (domain, actor, transaction) based on other parameters. For instance, you can get the list of all domains, the list of actors involved in a given domain and so on.
  • Hl7MessageProfile: This web service offers methods to retrieve the complete list of conformance profiles registered in GMM, a subset of these profiles which match certain parameters (actor, message type, HL7 version...). This web service also offers a method to add a new conformance profile reference into the database of GMM.

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.

OID assignments

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:

  • One for the conformance profiles
  • One for the HL7 resources
  • One for the validation results (messages)

Currently, no user interface is available to perform this update, you will need to modify those values, manually, in the database.

Add a new conformance profile

Adding a new conformance profile consists in two things:

  1. Creating a new reference in Gazelle Master Model
  2. Importing the XML file representing the conformance profile to the database of GazelleHL7v2Validator

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.

add a new profile

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.

Add a new resource

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

register new resource

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.

Link conformance profiles to resources

Go to Administration --> Link profiles to resources.

This page is composed of four parts:

  • he list of available HL7 resources
  • The list of selected HL7 resources
  • A panel to select a set of conformance profile or a profile knowing its OID
  • A panel which lists the selected conformance profiles

To link HL7 resources to conformance profiles, process as follows:

  1. First select the HL7 resource(s) you want to link to a set of profiles. Click on the blue plus icon of each row.
  2. Then, select a set of conformance profile (use filters)
  3. Finally hit the button "Link the profiles displayed below to the selected profiles"

Update conformance profiles and resources

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.

How conformance profiles and resources are organized on Gazelle's forge

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: 

  • HL7MessageProfiles: In this folder, conformance profiles are organized by firstly actor keyword then transaction keyword and finally message type (messageType_triggerEvent). For instance, you will find the conformance profile for validating the ADT^A28^ADT_A05 message issued by the Patient Demographic Supplier actor in the context of the ITI-30 transaction at the following location: PDS/ITI-30/ADT_A28/profile/ADT_A28.xml. A sub-directory of HL7MessageProfiles is named ProfilesPerOid and contains a symbolic link to each profile. Name of the link is the OID assigned to the targeted message profile. In this way, when you want to update a profile you do not have to know its OID and in the same way, when updating the message profiles in the database of the tool, the mapping is correctly performed thanks to the symbolic links.
  • HL7Tables contains the HL7 resources all with a meaningful name and a child directory named TablesPerOid which contains a symbolic link to each resource. Name of the link is the OID assigned to the targeted resource.

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.

Manage HL7v3 Constraints file

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.

 

Manage users' accesses

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.

 

[Deprecated] HL7v3 Validation Service

Warning: This documentation is out-dated, newest version of the documentation is available at https://gazelle.ihe.net/gazelle-documentation 

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 : 

  • PDQv3 Accept Acknowledgement
  • PDQv3 Patient Demographic Query
  • PDQv3 Patient Demographic Query Cancellation
  • PDQv3 Patient Demographic Query Continuation
  • PDQv3 Patient Demographic Query Response
  • PIXV3 Patient Identity Feed HL7V3 (Add Patient Record)
  • PIXV3 Patient Identity Feed HL7V3 (Revise Patient Record)
  • PIXV3 Patient Identity Feed HL7V3 (Patient Identity Feed)
  • PIXV3 Patient Identity Feed HL7V3 (Acknowledgement)
  • PIXV3 Query
  • PIXV3 Query Response
  • PIXV3 Update Notification 
  • PIXV3 Update Notification Acknowledgement
  • XCPD Cross Gateway Patient Discovery Request
  • XCPD Cross Gateway Patient Discovery Request (Deferred option)

Two additional messages can be validated with this tool though they are not HL7v3 based (but defined in the context of XCPD):

  • XCPD Patient Location Request
  • XCPD Patient Location Response

[Deprecated] Model-based validation web services

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.

Documentation

Below, we describe the methods offered by the web services and the expected parameters.

  • about : Gives information about the called web service
  • validateDocument : Validates an XML document using the given model-based validator
    • @param document : the XML document to be validated
    • @param validator : the name of the validator kind
    • @return : an XML based structure of the result of the validation
  • validateBase64Document : Validates an XML document using the given model-based validator based on a B64 description of the document
    • @param base64Document : base64 encoded document
    • @param validator : the name of the validator kind
    • @return : an XML based structure of the result of the validation
  • getListOfValidators : Returns the list of available validators
    • @param descriminator: in some cases we may need to use the descriminator in order to select the validators to return (example : IHE, EPSOS, etc)
    • @return : a list of string containing allowed validators' name

Web service client

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*~~~

WSDL locations

Validation Service Location Descriminators
CDA documents

https://gazelle.ihe.net/CDAGenerator-ejb/ModelBasedValidationWSService/ModelBasedValidationWS?wsdl

IHE, epSOS, ASIP

ATNA logging messages

https://gazelle.ihe.net/gazelle-atna-ejb/AuditMessageValidationWSService/AuditMessageValidationWS?wsdl

 

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

http://ovh4.ihe-europe.net:8180/SVSSimulator-ejb/ModelBasedValidationWSService/ModelBasedValidationWS?wsdl

IHE

HL7v3 messages

https://gazelle.ihe.net/GazelleHL7v2Validator-ejb/ModelBasedValidationWSService/ModelBasedValidationWS?wsdl

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

[Deprecated] SAML Assertion Validation

Warning: This documentation is out-dated, newest version of the documentation is available at https://gazelle.ihe.net/gazelle-documentation 

This tutorial consist on the following steps :

Overview

SAML documents validation is performed using Schematrons. Those schematrons define the requirements to be tested in an SAML document. 

How to perform an SAML document Validation 

There is two ways of validating your SAML document :

  • Using the Gazelle External Validation Service here.
  • Importing schematrons source code to your workspace and process the validation in local.

Importing the schematron project

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.

Validation steps

as for the CDA Document validation based on schematron, the SAML validation steps are : 

  • verify the assertion is valid XML
  • verify the assertion is welformed (XSD validation)
  • verify the assertion pass the schematron checks 

How to get the current SAML schematrons

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 : 

 


How does SAML validation works

Architecture

Here below the source schematrons available for the SAML validation.

 

SAML source schematron

 

'Make_dist.sh' scipt 

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 :

  • Reformating and indenting the schematrons
  • Building xsl from schematrons

'Validate.sh' script

The validation thanks to this script remains the same as for the CDA validation.

How to report a bug on SAML schematrons

Issues on SAML schematrons can be reported in the Gazelle issue tracker available here.

[Deprecated] WADO validator

Warning: This documentation is out-dated, newest version of the documentation is available at https://gazelle.ihe.net/gazelle-documentation 

Gazelle WADO Validator

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.

Web Service

The web service API of the tool offers three methods:

  •     validateDocument(): validates the given message and sends back a validation report
  •     about(): gives information about the running version of the tool
  •     getListOfValidators() : return the list of validator names. Each validator represent a standard against the message can be validated.

The definition of the web service API is available here.

The validateDocument() method has the following prototype:

public String validateDocument(String, String) throws SOAPException ;
  •     The first parameter stands for the message to validate itself.
  •     The second parameter is the validator to use for validation. The available names list can be retreive using getListOfValidators().

EVSClient Validation

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 :

wado

Select the validator "IHE - WADO", and then copy and past the WADO URL to validate.

Example :

wado2

Click then on the button validate.

The result of validation will then displayed. It contains checks about the structure of the WADO request entered :

  • checks of the parameters entered
    • the structure of each attribute (the OID, etc)
    • check of mandatory parameters
    • etc
  • checks of the consistencies between the parameters

Here an example of a result of validation of a wado request.

Access to existing WADO validation results

You can access to the results of already validated WADO requests using the menu -> IHE -> WADO -> Validation logs

log

 

[Deprecated] XDS Metadata Validator

Warning: This documentation is out-dated, newest version of the documentation is available at https://gazelle.ihe.net/gazelle-documentation 

XDS Metadata Validator

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.

 

Summary of the validation process

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. 

 

Webservice validation

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 : 

  • validateXDStarMetadataB64 : validation of metadata document by sending a base 64 content to the webservice
  • validateXDStarMetadata : validation of a structured XML document

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.

User interface validation

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. 

  • epSOS metadata validation

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 : 

epsos

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

epsoThe reset button allow you to initialize the upload area.

The list of validators available for epSOS are : 

  • epSOS DispensationService:initialize - request
  • epSOS DispensationService:initialize - response
  • epSOS DispensationService:discard - request
  • epSOS DispensationService:discard - response
  • epSOS ConsentService:put - request
  • epSOS ConsentService:put - response
  • epSOS ConsentService:discard - request
  • epSOS ConsentService:discard - response
  • epSOS OrderService:list - request
  • epSOS OrderService:list - response
  • epSOS PatientService:list - request
  • epSOS PatientService:list - response

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.

sss

  • IHE metadata validation

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 :

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

  • IHE Provide and Register Set-b - request
  • IHE Provide and Register Set-b - response
  • IHE Registry Stored Query - request
  • IHE Registry Stored Query - response
  • IHE Retrieve Document Set - request
  • IHE Retrieve Document Set - response
  • IHE Cross Gateway Query - request
  • IHE Cross Gateway Retrieve - response

List of validated XDS Metadata

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

[Deprecated] XDS-SD Document validation

Warning: This documentation is out-dated, newest version of the documentation is available at https://gazelle.ihe.net/gazelle-documentation 

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.

Extract the PDF from the CDA

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. 

PDF/A document validation

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.

  • Start the callas pdfaPilot2 tool.
  • Drag the pdf in the application window
  • Generate the report

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 

[Deprecated] XDW Validation Service

Warning: This documentation is out-dated, newest version of the documentation is available at https://gazelle.ihe.net/gazelle-documentation

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 :

http://ovh1.ihe-europe.net:8380/XDWSimulator-ejb/ModelBasedValidationWSService/ModelBasedValidationWS?wsdl

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.

 xdw val

 

The result of validation is like this :

result validationThe validation contains three types of validation :

  • XML validation, to see if we have a well formed XML
  • XSD validation, to validate the XDW document using the schema of XDW.
  • model driven validation, using the model of XDW containing contraints writen from the TF of XDW.

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 :

xsl viewThis representation contains many informations from the XDW documents :

  • General information : instanceId, status, WD reference
  • Patient informations
  • List of authors
  • List of tasks
  • List of document histories

List of validated documents

We can access to the list of XDW documents validated by users, using the menu XDW --> Validated XDWs.

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