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. 

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 : 

• http://www.jivamedical.com/eclipse_update/InstanceValidator.jar

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 :

• How to perform a CDA document validation
• How to get the current CDA schematrons
• How does CDA validation works
• How to report a bug on CDA schematrons
• How to develop / correct a schematron

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 :

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 :

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

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

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.

Presentation of the GUI showing the results of the validation

The validation process checks that :

• the CDA is a well formed XML document. 
• the CDA contains valid XML 
• the CDA respect the rules defined in the specification.

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 : 

Access to all validated CDA document

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 :

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. 

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

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.

Validate an HL7v2.x message

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.

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.

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

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.

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