Gazelle User guides

The up-to-date Gazelle tools user guides are available at https://gazelle.ihe.net/gazelle-documentation/

This page gathers the tool links and the user manuals for each of the tools developed in the context of the Gazelle project. If you want to install your own instance of one of those tools, consult our Installation guide.

If you want to learn more about the Gazelle purposes and achitecture, read the Gazelle general information page.

Gazelle Test Bed

Tool Description Documentation
Gazelle Master Model GMM contains the technical framework concepts and is the test repository for the connectathons installation | user guide
Test Management TM is the application used to manage the connectathon process, from registration through pre-Connectathon & Connectathon testing, until the generation of the test report installation | user guide
Assertion Manager The Assertion Manager tool is used to stored the requirements on which the tests and tools are based. It also allows the linkage between tests, steps, validators and requirements. installation | user guide

Support tools

Tool Description Documentation
Demographic Data Server DDS generates fake (but consistent) patient demographics for a large set of countries, user and webservice interface available installation | user guide
Product Registry Vendors can reference their products and users can search for specific implementations installation | user guide
Proxy "Man in the middle": captures the messages exchanged between two systems and forwards them to the validation service front-end installation | user guide
Gazelle Security Suite Fusion of the PKI and TLS simulator, Gazelle Security Suite (GSS) gathers a set of tools dedicated to security aspect testing. installation | user guide
STS This is a WS-Trust Security Token Service (STS) installationuser guide

Validation services

Validation services are dedicated to the conformance testing process. They perform static validation of messages and documents produced in the context of IHE and other e-Health projects

Tool Description Documentation
External Validation Service Front-end The EVSClient is a front-end which allows the user to use the external validation services from a user-friendly interface instead of the raw web service offered by the Gazelle tools. installation | user guide
Gazelle HL7 Validator Offers web services to validate HL7v2.x and HL7v3 messages exchanged in the context of IHE installation | user guide
Schematron-Based Validator Offers a web service to validate XML documents against schematrons installation | user guide
Gazelle Object Checker Embedded in CDA Generator tool, it offers a web service to validate a large set of different kinds of CDA using a model-based architecture  installation | user guide
XDS Metadata Validator Embedded in XD* Client simulator, it offers a web serivce to validate the metadata exchanged in the context of the XD* profiles  
XDW Validator    
Audit Message Validator Embedded in Gazelle Security Suite, it offers a web service to validate the ATNA messages produced in the context of IHE.  
Certificate Validator Embedded in GSS, it offers a web service to validate the certificates produced in the context of the epSOS project  
HPD Validator Embedded in HPDSimulator, it offers a web service to validate the messages exchanged in the context of the Healthcare Provider Directory profile  documentation
SVS validator Embedded in SVSSimulator, it offers a web service to validate the messages exchanged in the context of the Sharing Value Set profile  documentation
WADO validator  

documentation

XUA validator Embedded in GSS, it offers a web service to validate SAML assertions for the profile XUA.  

Simulators

Simulators are tools which emulated an IHE actor in order to allow user to test their products against an implementation of the technical framework. There are not reference implementation. Read the short introduction to simulators.

Tool Description Documentation
Patient Manager Emulates the actors defined in the PAM, PDQ/PDQV3/PDQm, PIX/PIXV3/PIXm, XCPD profiles and the SWF/ADT actor installation | user guide
Order Manager Emulates the actors from the LAW and LTW profiles and some parts of the SWF/SWF.b profile. It can also be used for some transactions of the A-EYECARE profile. installation | user guide
XD* Client Emulates the initiating actors of the XD* profiles (XDS.b, XCPD, XDR, XCA, DSUB ...) installation | user guide
HPD Simulator Emulates the actors of the HPD profile installation | user guide
SVS Simulator Emulates the actors defined by the SVS profile. It is also used as a value set repository for the simulators installation | user guide
LCSD Simulator Emulates the actors defined by the LCSD profile of laboratory installation | user guide
LBL Simulator Emulates the actors defined by the LBL profile of laboratory installation | user guide
HMW Simulator Emulates the actors defined by the HMW profile of pharmacy installation | user guide
SSL/TLS Simulator Emulates clients or servers to establish secured connections. Embedded in Gazelle Security Suite (GSS). installation | user guide
Gazelle Webservice Tester Allows the execution of SoapUI scripts from a Graphical User Interface.  Installation | user guide
XCPD Responding Gateway Emulates the XCPD Responding gateway actor (used only for epSOS) installation | user guide

Gazelle Test Bed General Information

Gazelle is a test bed for testing the interoperability of eHealth systems. It is developed by IHE Europe with the support of several other IHE countries (USA, Japan, Korea, Australia). The development was initiated in 2006 with a team of developers at INRIA and continued with the team moving to Kereval. The development of the Gazelle Test Bed is the second generation of Test Management tooling that IHE developed.

The first generation tooling was initiated in 2002 with the development of a tool called “Kudu” based on Postgresql and PHP. This first generation tool allowed IHE to structure the connectathon process and to improve the quality and auditability of the testing performed during the connectathon.

In 2006 with the growth in the number of participant to the connectathon, it became clear that the tool had to move to a more robust platform in order to support the load and the scalability of a large project. The choice of Java and Jboss was then made and a development team was established at INRIA Rennes. In 2011 the Gazelle Test Bed project reached maturity and it was decided to move the development team to a company specialized in testing (Kereval in Rennes) in order to offer a more robust software development environment and deploy a quality management compatible with the certification requirement of ISO 17025 and Guide 65.

Gazelle Test Bed Architecture

Gazelle Test Bed is using a Service Oriented Architecture (SOA). The following figure shows the different component of the test bed. It consists of simulators, validation tools, data generation tools, a proxy and a test management tool.

click on the image to get an interactived view of the architecture !

Gazelle SOA Architecture

Support tools

Gazelle is made of several kinds of tools:

  • Support tools (Gazelle Master Model (GMM), Proxy, Gazelle SSO (CAS)...)
  • Conformance validation tools (EVS)
  • Simulators

Authentication and authorization

Gazelle comes across several security problems :

  • Authentication of systems : SAML 2.0 (Security Assertion Markup Language 2.0)
  • Authentication of users : SSO (Single Sign On)
  • Webservice TLS (Transport Layer Security) : PKI (Public Key Infrastructure)

Gazelle Single Sign On : Authentication of users

Single Sign On : One Authentication shared by the different gazelle applications

As Gazelle is made of different webapps, it is necessary to share the authentication of the users among the different component.

Gazelle SSO

 

Single Sign On (SSO) using the CAS tool

To achieve that goal, SSO (Single Sign On) is used. When a user access a protected resource, the application validates its identity. If the user is not authenticated, it routes him to a shared application managing identities. When the user gets his credentials, he gives his ticket to the source application. That one checks against the SSO that the ticket is valid and authenticates him.

Therefore, user identities are shared among all applications. Gazelle CAS uses EU-CAT user database.

Gazelle is using Jasig CAS for SSO, feating perfectly all our needs. Applications have to be modified a bit to replace current authentication without too much effort.

However, Gazelle applications should be able to use or not the SSO. For Test Management and Product Registry, SSO can be enabled at runtime.

Gazelle's SSO is able to authenticate users using a X.509 browser certificate.

CAS autologin

As described in this page, Gazelle SSO supports authentication using X.509 certificates.

The CAS server asks the browser for a certificate proving identity. Process is seamless and allows magic login on Gazelle applications.

Automatic procedure (Firefox&Chrome)

Go to http://gazelle.ihe.net/pki/, login with your Gazelle credentials and go to http://gazelle.ihe.net/pki/request/createCAS.seam

If you are using Firefox, you can import CA certificate directly by clicking the first link. Otherwise, you have to download the PEM located here and install it in your browser.

You can also install an authentication certificate in your browser by clicking on "Compute certificate". Using this, you will not have to enter your login/password each time.

Note for development environments

To use the CAS autologin within your application (under development) on your machine, you need to add your cert on the Java keystore. To do that, follow those steps :

1. Download 643.pem

2. Execute the command :

On Windows :

C:\Program Files\Java\jdk1.6.0_26>.\jre\bin\keytool -keystore .\jre\lib\security\cacerts -storepass changeit -import -trustcacerts -v -alias ihe2 -file "C:\643.pem"

On MacOS :

sudo keytool -keystore /Library/Java/Home/lib/security/cacerts -storepass changeit -import -trustcacerts -v -alias ihe2 -file 643.pem

On Linux (JAVA_HOME can be /usr/local/jdk1.6, /usr/lib/jvm/java-6-oracle, or ...:

sudo $JAVA_HOME/jre/bin/keytool -keystore $JAVA_HOME/jre/lib/security/cacerts -storepass changeit -import -trustcacerts -v -alias ihe2 -file 643.pem

3. Start or restart your JBoss AS.

Gazelle ObjectsChecker

Abstract

Nonconformity of healthcare implementations to the medical standards has become a real source of troubles and loss of interoperability between systems. Healthcare documents frequently contain inconsistent requirements related to the standards they must conform to. Few standards and methodologies exist to deal with complex requirements, and often they are only dedicated to some specific kinds of healthcare standards, like CDA, HL7 and DICOM. The complexity of standards and their constant evolution have made difficult theimplementation of robust check methods and tools for healthcare documents.

References

you can refer to these links :

  1. paper of IHIC 2015 / presentation IHIC 2015
  2. paper of IHIC 2016 
  3. paper of IHIC 2017 / presentation of IHIC 2017
  4. paper of HEALTHINF 2014 : https://gazelle.ihe.net/files/HEALTHINF_2014_49_CR_2.pdf
  5. presentation of IHIC 2015 : https://gazelle.ihe.net/files/paper_ihic_presentation_0.pdf
  6. video presentation of IHIC 2015 : https://vimeo.com/119524890
  7. documentation of gazelle EVSClient validation : https://gazelle.ihe.net/content/cda-model-based-validation
  8. Blog in Ringholm : http://www.ringholm.com/column/HL7_CDA_Conformance_testing_tools_analysis.htm
  9. Eric Poiseau presentation in HL7 WGM of Paris, May 2015 : https://vimeo.com/127800129
  10. EVSClient : https://gazelle.ihe.net/EVSClient/
  11. eStandard Webinar, Nov 19, 2015, "Art-Decor and Gazelle Tools" : http://www.estandards-project.eu/index.cfm/tools/
  12. Presentation in Lisbon eHealth Week in December 2015 : https://gazelle.ihe.net/files/20151209-Art-decor_and_Gazelle_tools-Lisbon.pdf, here the context of the presentation.

Other links :

  1. HL7 Europe Newsletter http://www.hl7.eu/download/eun-05-2015.pdf
  2. Software Implementation of CDA http://wiki.hl7.org/index.php?title=Software_Implementation_of_CDA
  3. Requirements related to Validation of HL7 Templates Design for CDA : https://gazelle.ihe.net/files/cdatemplates_requirements_restriction.pdf
  4. Specification for HL7 Templates Converter Module https://gazelle.ihe.net/files/SpecificationsforHL7TemplatesConverterModule.pdf

 

Introduction

KEREVAL Health Lab, on behalf of IHE Europe,  has developed a tool to create validator for XML documents related to IHE specifications.
This validator tool can be used to validate any kind of XML document, especially CDA documents.
The aim of the tool is to transform assertions of standards into an UML models with constraints into it, and then create from this model Java code of validation of CDA documents, a documentation and unit testing of theses constraints.

Gazelle Objects Checker is not a CDA Authoring Tool. For authoring of CDA documents we recommend to use Art-Decor. Gazelle Objects Checker can be interfaced with authoring tools and import the definition of CDA document. 

 

Principle

Principle

The principle of this project is to extract assertions from CDA specifications and to insert them into a UML model. This model is then processed to generate validator, unit testing and documentation.

Purpose

Numerous regional and national healthcare initiatives are requiring eHealth applications to be tested for conformance to profiled standards. Meaningful Use (Melissa Markey, 2012) in the USA, Elga (Georg Duftschmid, 2009) in Austria or ASIP (ASIP, 2012a) in France illustrate the desire of healthcare organizations to build an infrastructure to share PHR. Most of those initiatives are profiling the HL7 CDA (HL7, 2005a) standards and/or the IHE XDS (IHE, 2012a) profiles specifications. CDA specifies how tostructure and code health records while XDS providesthe sharing mechanism of these records. Testing the conformance of healthcare solutions becomes an important issue in order to achieve the interoperability of the different components contributing to the sharing of such documents. Since both XD messages and CDA documents have an XML structure, we have developed a methodology that allows the conformance checking of XML documents in the context of hybrid healthcare standards. This methodology is based on UML modeling and MDA approach to describe the specifications. The main idea of this methodology is to inject constraints into UML models instead of executing xpath rules into XML documents. The result of this methodology is a report of validation generated automatically from the models describing the healthcare standards. Following a review of existing solutions for validating XML documents in the field of healthcare we will present our methodology and its evaluation based on its use on real life project like epSOS (Thorp, 2010) (epSOS, 2013).

Objectives

Our goal is to create a method that allows describing formally all requirements under an XML healthcare standard. This method should be generic and support inheritance between standards. The performance of this method shall be comparable to the performance of schematrons, and even better. This method shall provide a documentation and a coverage of the implemented requirements. The maintainability of the tools and models shall be better than schematrons maintainability. The method described here provide also generated unit testing for each implemented requirement, which is a huge advantage comparing to schematrons. The outcome of the proposed methodology is to provide a UML model and a set of methods used to convert it into documentation, validators and test procedures (Hans-Erik Erikson, 2004).

Standards inheritance :

We can point as example two standards that share the same basic parent standards, and extend them with more rules and requirements. These standards are the Swiss CDA Laboratory documents (eHealth Suisse, 2013), and the French CDA Laboratory documents (ASIP, 2012b). These two kinds of documents are based on the standards below, described on the figure 1. The two standards have a common base, and differ only on the top of the pyramid of standards. The method described here takes care of this kind of inheritance, and allows having shared models for shared standards.

Example

Principle of the method

Principle

The principle of the method that we propose for the validation of XML documents based on UML description, is the following :

  1. From medical standards like HL7, DICOM (Hongli Lin, 2010) and IHE standards, we extract all requirements, and we insert them into a specific UML model, which has a specific structure, that we will describe later. The UML model contains constraints written in OCL (Object Constraint Language) (OMG, 2012). The purpose of this language is to describe the relationship between elements of the UML model, which can not be simply described by diagrammatic notation. Each OCL constraint represents a requirement on a medical standard. OCL is a powerful language that permits many variants of constraints, like loops, search constraints, conditional constraints, etc. By our experience on more than 50 validators of IHE documents, OCL can generate the description of any kind of rules related to the model. The created UML model contains also the structure of the XML document. This structure allows linking the OCL constraint to its corresponding XML element.
  2. The OCL constraints are then processed to a programming language code like JAVA. In the industry, there are many processors of OCL. The most popular one is DresdenOCL, which is a library developed and maintained by students and scientists of the Software Technology Group at Dresden University of Technology (Birgit Demuth, 2009) (Birgit Demuth and Zschale, 2004).
  3. The UML models and the processed OCL constraints are then used by a UML model to text generator (M2T), to generate a specific validator based on the UML contents (OMG, 2008). There are many projects that present themselves as a UML model to text tool, the most popular one is Acceleo (OMG, 2008). Acceleo is not a classic generator of code from UML models, like EMF generator. To generate code you have to provide some M2T templates, which describe the generated text from the model. The generated text can be of any kind: html, java, or C++ for example. The idea was to generate java code that allows transforming the XML document to be validated from XML to JAVA instances, and then to validate these java instances by using the code generated by the OCL processor. The M2T method allows also to generate a documentation of the UML model, and unit tests for constraints written on OCL. Each module is described by its M2T templates.

 Healthcare requirements

Requirements on healthcare documents are generally written on human language, not a formal one. A major problem of the maintainability of schematrons was the fact that once the schematron written, we do not know which requirements are described on it, and which ones are not. We have no information about the coverage of rules written on schematrons, according to requirements from healthcare specifications. Many tools offer the possibility to list requirements, like TestLink for example. The one that we chose was an OASIS standard: taml (OASIS, 2011). This standard is a common structure for defining requirements. We used this standard and restricted its structure to better conform to the context of requirements on healthcare documents. This standard allows specifying the list of predicates, and for each predicate you can specify a list of tags which describe the predicate. We restricted the tags to: ’section’ and ’page’, which describe the section on the document and the page that refer to the requirement. Each predicate is defined by a unique identifier (/taml:testAssertion/@id), and each list of requirements is defined by a unique identifier: /testAssertionSet/common/normativeSource/target/@idscheme.

We restricted the OASIS taml standard by imposing that the common element of the taml:testAssertionSet shall be present, and this common element shall contain information about the healthcare document that we are processing, like the document name, version, source name, and a URI to the original document. These properties are included in the element taml:common/taml:refSourceItem. We forced the taml descriptor to have a unique identifier by adding the element taml:common:/taml:target. This is an example of taml assertion token from the taml document of CDA PADV specification:

<testAssertion id="CONF-5">
<predicate>The Pharmaceutical Advice section SHALL
contain code.</predicate>
    <prescription level="mandatory"/>
    <tag tname="Section">6.3</tag>
    <tag tname="Page">19</tag>
</testAssertion>

Each requirement is identified by a unique couple (target@idscheme , testAssertion@id). So we defined a stereotype applied on UML constraint elements, which describes the relationship between constraints and requirements. It contains two attributes: IDs and targetIDScheme, where IDs represents the list of ID on the taml document, and targetIDScheme is the identifier of the taml document.

Relationship between rules and requiremen

This correlation between constraints and requirements allows calculating the coverage of the validator according to the list of requirements, and then to identify requirements that are not implemented in the UML models.

UML models’ specification

Constraints’ specification

Each requirement extracted from the specifications of the XML document is translated into a UML constraint that contains an OpaqueExpression element with the attributes:

  • language: 'OCL'
  • body: the OCL constraint

The OCL constraint shall always have the result equals to true when applied to an UML instance specification. On healthcare standards, especially on HL7 ones, there are three kinds of rules: requirements, warning, and notes, which are specified by the keyword SHALL, SHOULD and MAY (Bradner, 1997). We specified a stereotype applied on UML constraint elements, which allows to specify if the constraint is an error, a warning, or a note. This stereotype is named ConstraintType.

 Stereotypes related to Constraint element

We defined also a stereotype to document a constraint when it is related to a valueSet: a dynamic list of values, that can be provided by a CTS or a SVS provider (IHE, 2010) (HL7, 2005b) (Heymans S, 2011). Each created constraint element shall be related to a UML class element.

Classes’ specification

There are two kinds of UML classes in this methodology: classes used to describe the content of the XML document, and classes used to apply a list of rules on a kind of XML element.

  1. Classes used to describe the content of the XML document: These classes, called in our specification StructureClass (SC), contain attributes with the same structure described in the schema of the XML document. The profile used to describe the relation between classes and the schema elements is ’Ecore’ profile (Dave Steinberg, 2008). From an XSD we can generate the UML model containing the description of the content of the XML document. The principal stereotypes used from this profile to describe the XML structure are: EPackage, Eclass, EEnum, EAttribute, and EReference. The generation of code binded to XML is based on these stereotypes. On this kind of classes, basic constraints can be included. If we are sure that a rule shall be applicable to any restriction of the standard, and it is not related to some specific context, we can add it directly on the class of description of the element.
  2. Classes used to apply rules on a kind of XML element: When we are on a special specification of a standard, or on an affinity domain which restrict the original standard, like for example epSOS CDA standard, we know that rules applied by these standards are not absolute, and we can not attach these rules directly to the class of description of the element. We defined the notion of ’package of constraints’. Each package of constraints contains a list of classes of constraints, and each class of constraints contains a list of constraints, has a generalization to the parent UML StructureClass or to another class of constraints, and has a stereotype that defines the kind of the class of constraints.
        We defined three kinds of stereotypes that describe the kind of a class of constraints:
  • TemplateSpec (TS): described by a (path, id). The list of constraints on this class is applied only when the value of the path on the XML instance has the same value as the id
  • ConstraintsSpec (CS): the list of constraints is applied automatically to any instance of the element described by the parent class
  • AdvancedTemplate (AT): defined by an OCL rule. The list of constraints on this kind of classes is applied only when the specified rule is verified on an instance of the parent class.

Stereotypes of classes of constraints

The UML classes that are described by these stereotypes are created manually in the UML model, in order to provide restrictions on the StructureClass (SC) classes, using UML constraints that describe requirements of the specifications. However, the StructureClass(SC) classes are created automatically from the XSD schema that describes the structure of the XML documents to be validated (R. Bhuvaneswari, 2012). This schema is generally provided by the standard specification.

The mixing of these kinds of classes of constraints can lead us to illogic situations, by generalization from one kind to another. So we defined some rules of inheritance between Template Spec (TS), ConstraintsSpec (CS), AdvancedTemplate (AT) and StructureClass (SC).

When a class of constraints generalizes another class of constraints, parent class rules are added to the child class rules, and the two lists of rules are executed only if we can execute the two lists in the same time. If we allow a TemplateSpec to inherit from another TemplateSpec, the rules of the child are executed only if the element tested on the XML document verifies the two paths of the parent and the child classes. If one of these paths is not verified, the rules are not executed, and here we have a problem because no error is reported to the designer of the XML document, showing that the XML element is missing a path, one or the other. For this reason, the table below specifies this kind of relationship between classes of constraints.

We also defined a stereotype to document classes of constraints, named DocumentationSpec. It allows specifying information about the standard which is the origin of constraints, and this provides a better documentation of the class of constraints when generating the documentation of the model of constraints.

M2T generation’s specification

XML binding

As explained on the principle of this method, as output we need to generate a code that allows transforming XML elements to object instances. In the implementation of this methodology, we chose JAXB as the API to bind XML to objects (McLaughlin, 2002). Oracle provides a tool, named xjc (McLaughlin, 2001), which allows to generate from an XML schema, java classes containing a full description of the XSD elements, based on JAXB annotations. The same functionality of generation of code containing a binding with XSD elements is done by a M2T template. Creating our own generator of java code gives us the possibility to add further methods and attributes, that are not generated by xjc. For example, we have introduced the ability to validate xpath constraints as a method of validation on the generated java code.

Validation code

The second kind of output from UML models is the classes of validation. This generated code is the combination of the OCL code transformed and processed by the OCL processor, and the generated code from a M2T template that links rules between themselves. The result of the execution of the generated code is a list of verifications. This list contains errors, warnings, notes and reports about processing of rules. For each package of classes of constraints, we generate a class of validation. This technique allows the reusability of the generated code, and simplifies the imbrication of standards. For example, in the laboratory domain described in figure 1, for each block in the two pyramids, we define a package of constraints. So for each of HL7 CDA, IHE PCC and XD-LAB, we define a unique package of validation. Then we define specific packages for CDA-FR, CDA-CH, and LAB-FR, LAB-CH. The validator is the combination of the common packages and the specific packages. The M2T templates generate code based on the visitor pattern: for each element on the object structure generated to describe the elements of the XML, we pass an instance of the package of validation, to a method generated from the template of generation of structured classes.

This method verifies the rules of the package on the current instances, and calls the same method on its attributes with the same package’s instance.

State principle of the visitor pattern applied on XML elements validation

Unit testing generation

The generation of unit tests is managed by a M2T template to facilitate the process of unit testing. This feature does not exist on the schematrons’ process. The generated code provides for each constraint, two tests: one OK and one KO. The principle of each test is to validate a whole document, and to verify if the result of the constraint is what it is supposed to be. The specification of the XML documents to be verified can not be done automatically; it is the role of the tester to provide them.

Templates coverage

As we define a structure of templates and advanced templates, the specified model of constraints provides an overview of the complexity of the XML document. This feature is very useful in CDA documents and in XDS metadatas analysis, as the specifications of these kinds of documents are based on templates structure. For example, in CDA documents, sections and entries have an attribute named templateId which is a unique identifier of the kind of the element, and it is referenced by the TemplateSpec stereotype (HL7, 2005a).

Documentation generation

Documentation generationThe defined stereotypes to document constraints and classes of constraints are used for the generation of the documentation. The generation is performed using a M2T template, with an html output. There are two kinds of documentation that can be generated:

  • the documentation of the structure of the XML document: this documentation is a description of the elements of the XML document. For each element we can document the cardinality, the type, the name, and the parent.
  • the documentation of classes of constraints: this documentation contains the relationship between constraints and classes, documentation of the kind of constraints and the kind of classes of constraints, and finally a documentation of the link between constraints and taml assertions.

Conclusions

We designed, Gazelle ObjectsChecker, a methodology of validation of XML documents on healthcare standards based on model based architecture. This methodology has allowed to remain with weaknesses of schematrons technology, especially problems of maintainability, reusability, unit testing, documentation and requirements coverage. It has also simplified the validation of pyramidical standards. The implementation of this methodology was done using open source tools, especially Topcased as editor, DresdenOCL as OCL processor, and Acceleo as M2T generator. The generated output code was on Java technology. The result of this implementation has covered the needs of developers and users of the generated validators. The use of this methodology to create validators for multiple kinds of healthcare standards in many domains like epSOS and IHE has proved the efficiency of this method: any kind of constraint can be expressed. And also, an important feature was, the model based validators are quicker than schematrons. Several improvements could be injected into this methodology and its implementation, like a self editor of the UML model, to simplify the creation and the management of classes and constraints. Also, the concept of stereotypes to describe classes and constraints can evolve to a meta-model that describes this set of stereotypes, and a use of GMF can improve the usability and minimize the risk of inconsistencies of UML models. Moreover, the model based validation of XML based healthcare standards could be adapted to other domains that use the XML technology.

Simulators

Gazelle testbed also offers applications known as simulators. Those tools implement IHE actors and exchange data with systems under test in the context of IHE transactions. Available online all year long, you can use our simulators to test the IHE interfaces of your systems off the connectathon periods. Using those tools, you will also be able to check the conformance of the messages issued by your system; actually, the simulators are configured to call the validation services offered by Gazelle.

Important Reminder

When you are testing against one of the Gazelle simulators, you are exchanging messages over the Internet. In order to ensure that your system will be able to communicate with our tools, please make sure that your firewall settings enable Gazelle to access to your system and that you have provided Gazelle with a public IP address. Read more about IPv4 networking consideration in Wikipedia. As a reminder, this is the list of private ranges of IP addresses, the ones that Gazelle is not able to reach.

STARTEND
10.0.0.0 10.255.255.255
172.16.0.0 172.31.255.255
192.168.0.0 192.168.255.255

List of simulators

see Simulators section of the Gazelle user guide

Simulated profiles and actors

Communication with gazelle

Gazelle communicates with the simulators using web services calls. A simulator thus needs to expose some specific webservice API. The API allow gazelle to inform the simulator of the test instance participants and to provide relevant participants configuration to the simulator and to ask the simulator about feedback of the message exchanged between the simulator and the other test participants.

All simulators should have the method startTestInstance, to create a new interaction between the simulator and a system under test. After establishing a communication with the simulator, gazelle sent configuration of partners of the simulator on the test using another web service method: setTestPartenerConfiguration. If the simulator is an initiator, gazelle use the web service method sendMessage to force the simulator to execute the test.

Developers interested in the development of new simulator should visit the Gazelle Simulator Developer Guide

HMW Simulator

Click to here to enter the HMW Simulator

Introduction

The HMW Simulator emulates the actors involved in the Hospital Medication Workflow (HMW) integration profile. The simulator can be used to simulate the missing partner when testing that profiles :

Integration ProfileActorOption
HMW Prescription Placer  Advance Prescription Notification
HMW Pharmaceutical Adviser  Validated Order Confirmation
HMW Medication Dispenser  Advance Prescription Notification
HMW Administration Informer

 Advance Prescription Notification

 Validated Order Confirmation

 

The HMW simulator can help testing applications implementing all the actors participating to the profile.

 

For more details about the various functionnalities of the HMW Simulator, visit the following links.

  1. How to get started
  2. General Presentation
  3. Create and send a Prescription
  4. Discontinue a Prescription
  5. Replace a Prescription
  6. Validate a Prescription
  7. Dispense a Medication
  8. Administer a Medication
  9. HL7 messages validation

HMW Simulator : How to get started

Get a Gazelle account

 

First of all, note that, like the other applications from Gazelle testing platform, the HMW Simulator is linked to our CAS service. That means that, if you have an account created in Gazelle, you can use it, if you do not have one, you can create one now by filling the form here. Create an account in Gazelle is free. The login link ("cas login") is located in the top right corner of the page.

Be careful, you must be logged in order to use the HMW Simulator.


Registration of Systems Under Test (SUT) acting as HL7 responders

 

If your system acts as an HL7 responder in one of the transactions offered by the simulator (for example your system is an Pharmaceutical Adviser and supports PHARM-H1 transaction), you will have to enter its configuration in the application. (No need to enter one configuration per transaction for your SUT. For example, the Pharmaceutical Adviser acts as a responder for the transaction PHARM-H1 and PHARM-H3. Just need to enter one configuration for your Pharmaceutical Adviser SUT.)

In order to proceed, go to "System Configurations" and hit the "Create a Configuration" button. You can also copy copy or Edit edit an existing configuration (one of yours !).

In both cases, the simulator needs to know:

  • A name for your configuration (displayed in the drop-down list menus)
  • The actor played by your system under test
  • The receiving facility/application
  • The IP address
  • The port the system is listening on
  • The charset expected by your SUT

If you are logged in when creating the configuration, you will be set as the owner of the configuration. If you do not want other testers to send messages to your SUT you can uncheck the box "Do you want this configuration to be public?" and you will be the only one to be able to select your system in the drop-down list and to edit it (if logged in!).

Before sending messages to your system under test, ensure that your firewall options give to HMW Simulator the access to your system.

 

What is the Workflow Setup in the HMW Simulator and how to manage it

 

More than a big simulator for all actors acting in the HMW Supplement, the HMW Simulator simulates a typical workflow concerning the prescription, dispensing, distribution and administration of medication.

What does it means for the user ?

    After to have enter your SUT configuration, you must create your own workflow setup. Each workflow setup will be linked to your gazelle account. So, you will be the only one to allow to modify your workflow setup. To create a new workflow setup, go to the workflow setup menu, enter the name of your workflow setup and configure each actors singly, below the sequence diagram.

     

    hmw workflow setup actorhmw workflow setup actor not simulated

     

    For each actors, you can decide to simulate this actor and choose the charset that you desire to use, OR select your SUT configuration in order to test your SUT. For example, if you want to test your Medication Dispenser actor, you will simulate the Prescription Placer, Pharmaceutical Adviser and the Administration Informer actors. Of course, you can have more than one SUT actor per workflow setup (with a maximum of three SUT).

     

    About the color of the actor panel configuration header, the green means that the actor will be simulated, and the blue means the actor will be not simulated.

    Don't forget to save your configuration in using the button below :

    save the workflow

     

     

    Soon as your workflow setup is ready, you can go to the next part and begin to use the HMW Simulator.

    (If you need to work with a charset which doesn't appear in the charset drop-down list when you simulate an actor, don't hesitate to talk us.)

     

    Visualize/Edit an existing Workflow Setup

      You have the possibility to visualize or edit an existing Workflow Setup which has been created. For that, select, in the top of the page, the option "Visualize/Edit an existing Workflow Setup". Then, choose, among the available list, the workflow configuration that you desire. You can edit as you want the different actors configuration. Don't forget to save it.

      HMW Simulator : General Presentation

      HMW Actors

       

      In the menu of the HMW Simulator, you can find the "simulators" label, which contains the access to the fourth actors define in the HMW TF supplement.

      hmw actor list

       

      When you hit one of this actor, you will arrive in the front page of the selected actor. The only action that you can do at this moment, it is to choose a Workflow configuration to work with it. A sequence diagram resumes the transaction(s) where the selected actor acts as an initiator.

      At this point, there are two possibilities :

      • In the selected workflow setup, the selected actor is not simulated, it is your SUT. So you will see only the resume of the workflow setup configuration just below the sequence diagram.
      • In the selected workflow setup, the selected actor is simulated. So you will have different pannels below the configuration resume. The first is here to show you all action that you can do with the selected actor. The second shows all HL7 messages that the selected actor has send and received from the other actors. (see "HL7 messages validation").

      (The color of the panel configuration header of the selected actor is salmon pink.)

      salmon pink

       

      Prescription Item Color highlighting

       

      In using the HMW Simulator, you should see that the prescription items can be highlighted with different colors. Theses colors are the reflection of the prescription item status.

      prescription item status

      A prescription item can take 5 different status :

      • White color :  The prescription item just has been created and is waiting for validation.
      • Green color : The prescription item has been validated by the Pharmaceutical Adviser actor.
      • Blue color :    The medication linked to the prescription item has been dispensed, and the Medication Preparation Report has been sent by the Medication Dispenser actor.
      • Purple color : The medication linked to the prescription item has been administered, and the Administration Report has been sent by the Aministration Informer actor.
      • Red color :     The prescription item has been canceled, either by a discontinuation order, or by a replacement order.

      HMW Simulator : Send a new prescription

      How to create and send a new Prescription Order

       

      If you decide to simulate the Prescription Placer actor, you will be able to access, to the Prescription Placer front page, see the tab below, which group all available action for the Prescription Placer actor.

      prescription placer action table

       

      In this section, we will see how to create and send a new Prescription Order to the other actors. First, choose, in the "Request Type" list : "New Order".

      You can see that the level of prescription encoding is : "Encoded Medication" by default and can't be changed at this moment (see the HMW TF Supplement part 5.6.4.1.2). It will be possible in further version of this simulator.

      At last, the "Advance Prescription Notification" option can be ticked or not. Please see the HMW TF Supplement, part 4.2 for more details about this option.

       

      Now that you have chosen your request type, you must select a Patient to begin the creation of a new prescription. To do that, you will have to hit this button button for patient selection. You will enter to the Patient Information tab panel below :

       

      panel to manage patient

      You can either generate a new patient information or select an existing patient with the button button for patient selectionin the Action column. Some filters are available in the header of the Patient data table, to make the patient search easier.

      The basic information about your selected patient will be display just below the Available Patient data table.

       

      selected patient information

       

      Once your patient has been selected, you must select the medication(s) that you desire put in your prescription. Hit the "Select the medication(s) to prescribe to the patient..." button to go to the Medication Information tab panel. Use the action button add a medication to add a medication to your prescription and the button delete a medication to delete it. The medication list of your selected medication(s) appear below the medication table. Use the button delete a medication next to the "Selected Medication" title to empty the entire list.

      As for the Patient data table, the Medication data table allows you to use the filter, locate in the data table header, to search a specific medication.

      medication information tab

       

      To go to the next step, hit the "Go to the prescription item(s) configuration page..." button.

      In this tab panel, you will be able to configure some information linked to each prescription item (if you don't remember what is a prescription item, go to the end of this part). You can come back to the previous tab panel when you want, to add or remove a medication or select an other patient for example.

      When your have finish the creation of your prescription, hit the "Send Prescription" button to send the New Prescription Order to the other(s) actor(s). In order to see the HL7 messages sent, go to see the last panel named : "Messages send and received by the Prescription Placer Actor.", at the end of the page.

       

      prescription item configuration

       

      (Don't forget : "One Prescription Order will be related to one patient, and may refer to a particular encounter (visit). It will contain one prescription, and this prescription refers one prescriber, and contains zero or more prescription items. A prescription item contains one medication item and zero or more observations." cf HMW TF Supplement part ).

      HMW Simulator : Discontinue a prescription

      How to send a discontinue order for a prescription item

       

      For the moment, only the Prescription Placer simulator allows to send a discontinuation order. This will be available for the Pharmaceutical Adviser simulator too in a future version of the HMW Simulator.

       

      With the prescription placer simulator :

      Always in the Prescription Placer actor page, if you desire discontinue a Prescription Order, select, in the "Request Type" List, the value : "Discontinuation". Then, hit the button select a prescription to select the prescription where the prescription item to discontinue is located.

       

      prescription table

       

      Some explanations about the Prescription Table :

      You will see the Prescription Table Over. This Table shows all Prescription Order sent by the Prescription Placer simulator. Each lines of this table represents one Prescription. The medication list, is linked to the prescription item list. Thereby, in this example, for the first prescription (with the identifier "11^IHE_HMW_PP..."), the mirtazapine medication corresponds to the precription item with the placer order number : "29^IHE_HMW_PP...".

      You can see, that for the second prescription, some prescription item are highlighted with a specific color. See the "Prescription Item Color highlighting" part of this tutorial for more information.

      About the Prescription Status, see the HMW TF Supplement part 4.5.1.

       

       

      discontinuation tab

      Now, you can select the prescription item to discontinue. Be careful, you can discontinue only one item at a time. Hit the change statusdiscontinuation buttonbuttons to change the status of the pescription item.

      change statusthe item won't be changed.

      discontinuation buttonthe itm will be discontinued.

      When your choice is made, hit the "Send Discontinuation Order" to send the discontinuation order to the Pharmaceutical Adviser actor.

      (You only can discontinue a prescription item which is not yet validated by the Pharmaceutical Adviser actor. In other words, a prescription item with the status equals to "P3" or "V2".)

       

      After to have send the discontinuation order, the HMW Simulator modifies the prescription item status to "P9".

      discontinuation order executed

       

       

      With the pharmaceutical adviser actor (not yet available)

      HMW Simulator : Replace a prescription

      How to send a replacement order for a prescription item

       

      For the moment, only the Prescription Placer simulator allows to send a replacement order. This will be available for the Pharmaceutical Adviser simulator too in a future version of the HMW Simulator.

       

      With the prescription placer simulator :

      Always in the Prescription Placer actor page, if you desire replace a Prescription Order, select, in the "Request Type" List, the value : "Replacement". Then, hit the button select a prescription to select the prescription where the prescription item to replace is located.

       

      prescription table

       

      Some explanations about the Prescription Table :

      You will see the Prescription Table Over. This Table shows all Prescription Order sent by the Prescription Placer simulator. Each lines of this table represents one Prescription. The medication list, is linked to the prescription item list. Thereby, in this example, for the first prescription (with the identifier "11^IHE_HMW_PP..."), the mirtazapine medication corresponds to the precription item with the placer order number : "29^IHE_HMW_PP...".

      You can see, that for the second prescription, some prescription item are highlighted with a specific color. See the "Prescription Item Color highlighting" part of this tutorial for more information.

      About the Prescription Status, see the HMW TF Supplement part 4.5.1.

       

      As for the discontinuation order, select one prescription to work on it. Once the prescription selected, you will choose the prescription item to replace. For that, hit the button replacement button, in the Action column.

       

      replacement order

       

      You will be able to edit some information about the prescription item that you want to replace. The first panel shows you the information of the old prescription item, the item that is to be replace. The second panel shows you the information of the new item. Of course, you can change the medication linked to this prescription item, just need to hit the button medication replacement. As soon as you want to send your replacement order, just hit the "Send Replacement Order" button.

       

      replacement configuration

       

      After to have send the replacement order, the HMW Simulator modifies the status of the old prescription item to "P9" (in this example, this is the prescription item with the placer order number "33^IHE_HMW..."). And the new prescription item (in this example, this is the item with the placer order number "36^IHE_HMW...") takes the place of the old prescription item.

       

      replacmenet works

       

      With the pharmaceutical adviser actor (not yet available)

      HMW Simulator : Validate a prescription

      How to send a validation order for a prescription item

       

      If you decided to simulate the Pahrmaceutical Adviser actor, you will be able to access, to the Pharmaceutical Adviser page, see the tab below, which group all available action for the Pharmaceutical Adviser actor.

      pharmaceutical adviser main page

       

      In this section, we will see how to send a Validated Order to the other actors. First, choose, in the "Request Type" list : "Validated Order".

      You can see that the level of prescription encoding is : "Encoded Medication" by default and can't be changed at this moment (see the HMW TF Supplement part 5.6.4.1.2). It will be possible in further version of this simulator.

      At last, the "Validated Order Confirmation" option can be ticked or not. Please see the HMW TF Supplement, part 4.2 for more details about this option.

       

      Now that you have chosen your request type, you must select a Prescription. To do that, hit this button select a prescription. You will enter to the Prescription tab panel below. Then, hit the button select a prescription to select the prescription to validate.

      prescription table

       

      Some explanations about the Prescription Table :

      You will see the Prescription Table Over. This Table shows all Prescription Order sent by the Prescription Placer simulator. Each lines of this table represents one Prescription. The medication list, is linked to the prescription item list. Thereby, in this example, for the first prescription (with the identifier "1^IHE_HMW_PP..."), the Visine medication corresponds to the precription item with the placer order number : "4^IHE_HMW_PP...".

      You can see, that some prescription item are highlighted with a specific color. See the "Prescription Item Color highlighting" part of this tutorial for more information.

      About the Prescription Status, see the HMW TF Supplement part 4.5.1.

       

      validation order

      Now, you can select the prescription item to validate. You can validate all item of a prescription at a time, or only some. Hit the change statusdiscontinuation buttonbuttons to validate or not the pescription item. When your choice is made, hit the "Send the Prescription Advice" button to send the validation order to the other actors.

      change statusthe prescription item will be validated.

      discontinuation button  the prescription item won't be validated.

      After to have send the validation order, the HMW Simulator modifies the prescription item status to "V3".

       

      validation order success

      HMW Simulator : Dispense a medication

      How to send a medication report

       

      If you decided to simulate the Medication Dispenser actor, you will be able to access, to the Dispenser actor page.

      medication dispenser main page

       

      In this section, we will see how to send a Medication Preparation Report Order to the other actors.

      Now, you must select a Prescription to work on it. To do that, hit this button select a prescription. You will enter to the Prescription tab panel below. Then, hit the button select a prescription to select the prescription to dispense.

      prescription table

       

      Some explanations about the Prescription Table :

      You will see the Prescription Table Over. This Table shows all Prescription Order sent by the Prescription Placer simulator. Each lines of this table represents one Prescription. The medication list, is linked to the prescription item list. Thereby, in this example, for the first prescription (with the identifier "3^IHE_HMW_PP..."), the Visine medication corresponds to the precription item with the placer order number : "5^IHE_HMW_PP...".

      You can see, that some prescription item are highlighted with a specific color. See the "Prescription Item Color highlighting" part of this tutorial for more information.

      About the Prescription Status, see the HMW TF Supplement part 4.5.1.

       

      medication order

      Now, you can select the prescription item(s) to send the Medication Preparation Report. You can dispense all item of a prescription at a time, or only some. Hit the change statusdiscontinuation buttonbuttons to dispense or not the pescription item. When your choice is made, hit the "Send theMedication Preparation Report" button to send the medication preparation report order to the other actors.

      change statusthe prescription item will be dispensed.

      discontinuation button  the prescription item won't be dispensed.

      After to have send the medication preparation report order, the HMW Simulator modifies the prescription item status to "D3".

       

      medication order success

      HMW Simulator : Administer a medication

      How to send a new administration report

       

      If you decided to simulate the Administration Informer actor, you will be able to access, to the Administration Informer page, see the tab below, which group all available action or the Administration Informer.

      aministation main page

       

      In this section, we will see how to send a new Administration Report Order to the other actors. First, choose, in the "Request Type" list : "New administration Report".

      Now that you have chosen your request type, you must select a Prescription to begin. To do that, hit this button select a prescription. You will enter to the Prescription tab panel below. Then, hit the button select a prescription to select the prescription to validate.

      prescription table

       

      Some explanations about the Prescription Table :

      You will see the Prescription Table Over. This Table shows all Prescription Order sent by the Prescription Placer simulator. Each lines of this table represents one Prescription. The medication list, is linked to the prescription item list. Thereby, in this example, for the first prescription (with the identifier "3^IHE_HMW_PP..."), the Visine medication corresponds to the precription item with the placer order number : "5^IHE_HMW_PP...".

      You can see, that for the second prescription, some prescription item are highlighted with a specific color. See the "Prescription Item Color highlighting" part of this tutorial for more information.

      About the Prescription Status, see the HMW TF Supplement part 4.5.1.

       

      administration order

      Now, you can select the prescription item to administer. You can administer all item of a prescription at a time, or only some. Hit the change statusdiscontinuation buttonbuttons to administer or not the pescription item. When your choice is made, hit the "Send Administration Report" button to send the administration report order to the other actors.

      change statusthe prescription item will be administered.

      discontinuation button  the prescription item won't be administered.

      After to have send the administration report order, the HMW Simulator modifies the prescription item status to "A3".

       

      administration order success

      LCSD Simulator

       

      Click to here to enter the LCSD Simulator

      Introduction

      The LCSD Simulator emulates the actors involved in the Laboratory Code Set Distribution (LCSD) integration profile. The simulator can be used to simulate the missing partner when testing that profiles :

       

      Integration ProfileActorOption
      LCSD Code Set Master  
      LCSD Code Set Consumer   

       

      The LCSD simulator can help testing applications implementing the Code Set Master  and/or the Code Set Consumer actor.

      Thanks to a mechanism which enables Gazelle TestManagement to communicate with the simulator, this one can also be picked as a test partner during a connectathon if no another system supports this actor.

       

      For more details about the various functionnalities of the HMW Simulator, visit the following links:

       

       

      Release Notes

      Roadmap

      LCSD Simulator: User Manual Introduction

      Click here to access the LCSD Simulator.

       

      Introduction

      The LCSD simulator is developed in conformance with the IHE technical framework, that means that national extensions are not (yet) taken into account.

      This simulator can be an Initiator and a Responder.

      As an initiator, this simulator is aimed to send messages to a responder. So, if your system is ready to listen and accessible from the Internet, you will be able to send some messages to it.

      As a Responder, this simulator is aimed to listen messages from an initiator.

      By now, this simulator can act as two different actors:

      • CSM (Code Set Master)
      • CSC (Code Set Consumer)

      The table below gathers the supported affinity domains, transactions and SUT actors.

       

      What is this simulator able to do ?

      The simulator has been developed with the purpose of helping the developers of actors, such as the Code Set Master and the Code Set Consumer actors.  We have tried to manage most of the use cases, and  most of message  defined in the technical framework for those actors  are supported by the simulator.

      The following table summarize the actors, profiles and transactions supported by the LCSD simulator.

       

      Integration Profile Actor Affinity Domain Transaction System Under Test

       LCSD 

        CSM  

       IHE

       

      LAB-51


       Code Set Master

       LCSD  

       CSC

       IHE

       

      LAB-51


       Code Set Consumer  

       

      Today the simulator supports all type of messages defined in the TF for the LCSD profile, except the batch option for which further development is required.

      • Observation Codes (MFN^M08^MFN_M08 message type)
      • Non-numeric Observation Codes (MFN^M09^MFN_M09 message type)
      • Battery Codes (MFN^M10^MFN_M10 message type)
      • Calculated Observation Codes (MFN^M11^MFN_M11 message type)
      • Batch option (IHE Lab Vol 1 section 8.3.1 )(Not Yet Available)

      LCSD Simulator: How to get started

      Get a Gazelle account

      First of all, note that, like the other applications from Gazelle testing platform, the HMW Simulator is linked to our CAS service. That means that, if you have an account created in Gazelle, you can use it, if you do not have one, you can create one now by filling the form here. Create an account in Gazelle is free. The login link ("cas login") is located in the top right corner of the page.


      Registration of Systems Under Test (SUT) acting as HL7 responders

      If your system acts as an HL7 responder in one of the transactions offered by the simulator (for example your system is Code Set Consumer and supports LAB-51 transaction), you will have to enter its configuration in the application. 

      In order to proceed, go to "System Configurations" and hit the "Create a Configuration" button. You can also copy copy or Edit edit an existing configuration (one of yours !).

      In both cases, the simulator needs to know:

      • A name for your configuration (displayed in the drop-down list menus)
      • The actor played by your system under test
      • The receiving facility/application
      • The IP address
      • The port the system is listening on
      • The charset expected by your SUT

      If you are logged in when creating the configuration, you will be set as the owner of the configuration. If you do not want other testers to send messages to your SUT you can uncheck the box "Do you want this configuration to be public?" and you will be the only one to be able to select your system in the drop-down list and to edit it (if logged in!).

      Before sending messages to your system under test, ensure that your firewall options give to LCSD Simulator the access to your system.

      LCSD Simulator: Code Set Master

      Using the Code Set Master simulator to send Codes to your Code Set Consumer SUT

      The CSM Simulator allows the users of the simulator to send Code Sets to CSC actors. The CSM simulator provides some sample Code Sets (at least one for each message type that can be used to feed client Code Set Consumer. In this case, the CSM Simulator acts as an initiator and the CSC SUT as a responder.

      To communicate with your system under test, the simulator needs your system's endpoint configuration. The CSC actor acts as a  Go to the LCSD Simulator: How to get started part of this tutorial for further details.

      1. First at all, go to LCSD Simulator menu bar and select the CSM menu entry.
      2. A sequence Diagram Picture is available to help you to understand the transaction and the role of each actors.
      3. Choose your SUT configuration in the System Under Test drop-down list.
      4. You must choose the Codes to send to the CSC. Begin to choose the Code Set Category in the drop-down list, then choose the Code Sets in the Code Sets drop-down list. Use the  Icon used to display LCSD Codes. button to display the selected codes. (The screeshot below illustrates this part).
      5. At least, hit the Send message button to send the selected codes to the CSC SUT.

      CSM Actor GUI sreenshot.

      A tab with all messages for the transaction and the actor selected is available at the bottom. You can find your messages in using the filter fields.

      You can display the codes send in each HL7 messages. To do that, just hit the Icon used to display LCSD Codes. buton in the action column. A new window will appear to display all codes contained in the selected HL7 message and send by the CSM actor.

       

      HL7 validation

      For further details about this functionnality of the LCSD Simulator, go to the HL7 messages validation page.

      LCSD Simulator: Code Set Consumer

      Send HL7 messages to the Code Set Consumer simulator

      The simulator can act as a Code Set Consumer and receive messages from a distant system that implements the Code Set Master actor. 

      1. First at all, go to LCSD Simulator menu bar and select the CSC menu entry.
      2. A sequence Diagram Picture is available to help you to understand the transaction and the role of each actors.
      3. Below this picture, a tab with all messages for the transaction and the actor selected is available. You can find your messages in using the filter fields.
      4. Don't forget to refresh this messages list after to have send your message to the Simulator. To do that, only hit the "Refresh List" buttom.

      You can display the codes send in each HL7 messages. To do that, just hit the Icon used to display LCSD Codes. buton in the action column. A new window will appear to display all codes contained in the selected HL7 message and send by the CSM actor.

      The CSC Simulator is a responder and is able to respond to your CSM SUT with the appropriate Acknowledgment message. If the CSM message send to the CSC Simulator is not consistent with the IHE technical framework, the CSC will respond with an error Acknowledgment.

       

      HL7 validation

      For further details about this functionnality of the LCSD Simulator, go to the HL7 messages validation page.

      HPD Simulator

      Access the HPD Simulator

      Introduction to the HPD Simulator tool

      The HPD Simulator tool is developed in conformance with the IHE technical framework, that means that national extensions are not taken into account. This simulator is expected to act as an initiator or as a responder depending on the emulated actors.

      As an initiator, this simulator is aimed to send messages to a responder. Consequently, if your system (named SUT or System Under Test) is ready to listen to a SOAP request and reachable from the Internet, you will be able to received messages from the simulator.

      The table below gathers the supported affinity domains, transactions and SUT actors.

      Integration profile

      Actor

      Option

      Transaction

      Affinity domain

      System under test actor

      Healthcare Provider Directory

      Provider Information Directory

      Provider information feed

      ITI-59

      IHE

      Provider Information Consumer

      "

      Provider Information Directory

      None

      ITI-58

      IHE

      Provider Information Source

      "

      Provider Information Consumer

      None

      ITI-59

      IHE

      Provider Information Directory

      "

      Provider Information Source

      None

      ITi-58

      IHE

      Provider Information Directory

       

      What is this simulator able to do ?

      This simulator has been developed with the purpose of helping developers of IHE systems to test their systems with another IHE compliant system off connectathon periods. We try to manage most of the cases, that means that, step by step, we planned to offer you all the features defined in the technical framework. We also plan to implement national extensions if requested by the different organizations. Nevertheless, this tool is not a reference implementation.

      For more detail, follow one of the links at the bottom of the page for instructions for these actors:

      • Provider Information Directory
      • Provider Information Consumer
      • Provider Information Source

      Adding your system as a receiver (Provider Information directory)

      In order to send messages to your system under test, the HPD Simulator tool needs to know the location of the web service endpoint of your system. This configuration has to be stored in the database of the application, so that you can re-use this configuration without creating it each time you need to perform a test. In order to proceed to configure the HPD Simulator, go to "SUT Configuration" and hit the "Create a new configuration" button. You can also copy or edit an existing configuration (one of yours !).

      In both cases, the simulator needs to know:

      • The name of your configuration (shall be unique throught the application)
      • The name of your system under test (informational)
      • The URL of your endpoint
      • The base DN of your LDAP directory (to pre-fill the messages)
      • The transactions supported by your system (so that the tool knows which configurations are available depending the cases)

      Message validation

      The HPD Simulator embeds the validation service for checking the conformance of DSMLv2 messages exchanged in the context of the HPD profile. For each received and sent messages, you can ask the simulator to validate the messages. Below is the meaning of the different icons you can meet in the Test Report section of each page or under the Messages menu (gathers all the messages received and sent by the simulator).

      Buttons (right-hand columns)
      find Redirect to the permanent link gathering all the information about the selected exchange of messages
      ok Call the validation service for the two messages (request/response) and display the result
      hide the message from users (only available to admin users)
      Icons (beside message type)
      fail The message has been validated but the the validation service has found errors
      ok The message has been validated, no error found
      The message has not been validated yet

      HPD - Provider Information Consumer

      The Provider Information Consumer part of the tool is able to send DSMLv2 messages to query for healthcare providers.

      To start, you will need to regiser your system under test as a HPD Provider Information Directory actor. To do so, go to SUT Configuration from the top menu bar and hit the “create a new configuration” button. Fill out the displayed form. Be aware that the URL you provide must be reachable by the tool (do not use private IP address nor host names).

      Then, go to Simulators → Provider Information Consumer.

      On that page, first select your system under test in the drop-down list and ensure that the connection information are correct.

      A DSML message can contain several queries. To add a searchRequest element to the message which will be sent to your system:

      1. Click on “Append a new request”

      2. Select the organizational unit to query on. This will set the base DN for search

      3. If needed, set the request options in the first panel

      4. Set the filter in the second panel. You can add assertions by dropping the boxes from left to right. Populate the required fields (marked with a red *) before adding another assertion.

      5. If you want to restrain the content of the response to a sub set of attributes, open the “Expected attributes selection” panel and select all the attributes one by one.

      Note that the tool has been populated with the list of object classes and attributes which might be known by the LDAP directory, this will help you with building your queries.

      When you have all your search requests ready, hit the “Send request” button. The response is stored in the database and parsed by the tool. If its contains entries, their content will be displayed below the test report. The latter contains the messages sent and received which can be validated by calling the Gazelle HPD validation service (hit the green button).

      Finally, a button invite you to perform another query. You will be able to either start a new message from scratch or to reuse the previous message.

      Tips

       

      When your message contains several searchRequest elements, you can edit or delete them using the icons on the right-hand of each message (under Batch Request).

      HPD - Provider Information Directory

      We did not implement our own LDAP directory but make use of the ApacheDS open source tool which supports LDAP3 and DSMLv2 queries.

      Nevertheless, we have implemented the web service part of the Provider Information Directory as stated in the IHE Technical Framework.

      SOAP web service: Provider Information Directory Service

      SOAP interface is available and has been developed to respect the web service definition specified by IHE. You will access the Provider Information Directory Service at the following location: http://ovh1.ihe-europe.net:8180/HPDSimulator-ejb/ProviderInformationDirectory_Service/ProviderInformationDirectory_PortType?wsdl

      This service offers the following methods:

      • ProviderInformationQueryRequest: it accepts batchRequest messages containing searchRequest elements

      • ProviderInformationFeedRequest : it accpets bachRequest messages containing addRequest, delRequest, modifyRequest and/or modDNRequest elements

      Link with the LDAP Server

      The Provider Information Directory Service is a front-end to the LDAP server configured as described in the first section of this document. The body part of the SOAP message is analysed and forwarded to ApacheDS through its DSML connector.

      The received request may raise errors in ApacheDS which will be reported in the batchResponse returned by the tool; in that case, the error is stored in our database and the response is formatted to fit IHE requirements (no error message are sent back to the sender).

      To verify that his/her query does not raise errors in the LDAP server, the user will be allowed to browse the logs under Simulators → Provider Information Directory → LDAP Server error logs.

      Configuration

      How to configure the LDAP Server (ApacheDS) and how to link the simulator and ApacheDS is explained in the Installation & Configuration manual of the tool and these actions shall only be performed by an administrator of the tool. If you feel like something is missing or goes wrong, feel free to contact the administator od the tool.

      Sequence diagram

      To better explain the workflow triggered by a call to the Provider Information Directory Service, a sequence diagram has been generated, see below.

      sequence diagram

      HPD - Provider Information Source

      The Provider Information Source part of the tool is able to send DSMLv2 messages to feed the provider information directory.

      To start, you will need to regiser your system under test as a HPD Provider Information Directory actor. To do so, go to SUT Configuration from the top menu bar and hit the “create a new configuration” button. Fill out the displayed form. Be aware that the URL you provide must be reachable by the tool (do not use private IP address nor host names).

      Then, go to Simulators → Provider Information Source.

      On that page, first select your system under test in the drop-down list and ensure that the connection information are correct.

      A DSML message can contain several queries. To add a an element to the message which will be sent to your system:

      1. Select the kind of request to add (addRequest, delRequest, modifyRequest or modDNRequest)
      2. Click on “Append a new request”
      3. Select the organizational unit to create. This will set the base DN of the request then, you have several choices
      • For an addRequest request
        • Complete the DN of this new entry
        • The mandatory attributes to populate are selected by the tool based on the type of provider
        • You can add values to those attribures (if they are multi-valued - a + signe is displayed)
        • You can add optional atrributes
      • For a delRequest request
        • Complete the DN with the uid of the entry to delete (for example)
      • For a modDNRequest request
        • Complete the DN of the entry to modify
        • Give the new RDN
        • Optionaly give the new superior 
        • Specify whether or not the old RDN must be deleted
      • For a modifyRequest
        • Complete the DN of the entry to modify
        • List all the modifications which have to be done

      Note that the tool has been populated with the list of object classes and attributes which might be known by the LDAP directory, this will help you with building your queries.

      When you have all your search requests ready, hit the “Send request” button. The response is stored in the database and parsed by the tool. If its contains entries, their content will be displayed below the test report. The latter contains the messages sent and received which can be validated by calling the Gazelle HPD validation service (hit the green button).

      Finally, a button invite you to perform another query. You will be able to either start a new message from scratch or to reuse the previous message.

      Tips

      When your message contains several searchRequest elements, you can edit or delete them using the icons on the right-hand of each message (under Batch Request).

      FAQ about tools

      FAQ about tools to be completed

      Gazelle - Terms and Conditions

      Gazelle Test Management is the application of the Gazelle Testbed dedicated to the management of interoperability test sessions.

      New in Gazelle !

      Things are moving around in Gazelle Test Management. Learn about the changes we are bringing to improve your experience with the test bed.

      Most of the changes we are bringing to Gazelle Test Management are driven by the experience from past years. Gazelle Test Management was first designed to address the Connectathon process but it is now used for a broader types of test sessions: Connectathon, Projectathon, Conformity assessment among others. The leitmotiv in our renovation work is thus to get rid of the Connectathon specific wording and fall back to more standard testing vocabulary.

      In the same way, all the test sessions are handled more on less the same way, with 4 main phases: Registration, Preparation, Testing, and Evaluation. This finding leads us to organise the tool for the user to easily find the features of interest in a given phase.

      Gazelle Test Management 6.10.0 - Released on 23 December 2022

      Beside bug fixes, this release introduces new content on the home page for the testing session manager and tool administrators. Actually, the Registration and Preparation phases are now populate for those users.

      As a testing session manager or tool administrator, for each testing session, you will find,

      • During the registration period:
        • The number of attendees and how many organisations registered participants;
        • The number of registered SUTs along with their statuses and how many organisations registered SUTs;
        • Statistics on the scope of the testing session.
      • During the preparation phase:
        • The number of accepted SUTs and how many are still awaiting acceptance
        • Your progress in reviewing the supportive requests
        • The status of the SUTs network interfaces (approved vs not approved) and hosts (IP address assigned vs waiting for an IP)
        • Statistics on preparatory tests (per status)
        • Statistics regarding the scope of the testing session
        • Number of attendees
        • Number of monitors

      In addition, this release introduces a new feature call "Testing session scope" and available under the Testing menu.

      This section lists all the Profiles which are selected for the testing session and, for each actors of a given profile, the SUTs that claim support to it. Testing session manager are allowed to give a status to each Profile: Testable, Few partners, or Dropped as well as to enter a comment.

      The testing session participants (users with role vendor, vendor_admin, or monitor) are allowed to see the status of the profile, and the list of SUTs per actor.

      Read more in Gazelle Test Management user manual.

      Gazelle Test Management 6.8.0 - Released on 3 September 2022

      This release comes with statistics for the testing session managers and tool administrator users. Only the testing and evaluation phase displays data.

      The testing session managers and tool administrators can now have quick access to PKI about the testing session.

      During the testing phase, the following informations are displayed:

      • Number of test runs and what are they statuses
      • Workload for the monitors
      • Number of test runs that are waiting for an action by a monitor for more than 24 hours.

      TSM testing

      During the evaluation phase, for each domain, the number of SUT AIPOs to be evaluated and what their statuses are, as well as the total number of test runs and their final statuses.

      evaluation for TSM

      Gazelle Test Management 6.7.0 - Released on 17 August 2022

      Statistics about test execution and system evaluation are displayed to the user.

      For continuous testing session or during the testing phase of an event, the user logs with vendor or vendor_admin roles see statistics for each of the systems of their organisation that have been accepted to the event.

      Test session process section - Testing

      During the evaluation phase of an event, the user logs with vendor or vendor_admin roles see statistics about the evaluation of their systems under test.

      Test session process section - Evaluation

      Gazelle Test Management 6.6.0 - Released on 4 August 2022

      This new release of Gazelle Test Management:

      Allows you to quickly see the status of your network configuration [Read more];

      Offers a new user interface for the testing dashboard [Read more].

       

      Statistics about your SUTs' network configuration

      Gazelle Test Management offers a feature for the systems under test to share the connectivity details of their network interfaces. Templates are generated by the tool based on the capabilities selected for each of your systems under test. 

      Before the testing event starts, you are expected to review those network interfaces and make sure the details match your implementation:

      • Is the port accurate?
      • Is the service protected by TLS?
      • Is the AETitle correct?
      • And so on.

      When you are logged in as vendor or vendor_admin, and at least one of your systems under test is accepted to the session, the home page displays information about the Preparation phase, including details about the network.

      For each systems under test that has been accepted, a progress bar shows you how many network interfaces have been approved and how many still need some review from you.

      Statistics

      Test execution page

      Although the principle of the test execution page remains the same, the layout has been deeply reviewed with the objective to lighten and clarify that page. We hope you will enjoy using it.

      You can still

      • access the list of test cases per SUT capability (Actor / Profile / Profile Option)
      • start new test runs (aka test instances)
      • filter your search
      • create presets (now known as "Quick filters"), use the floppy disk icon and give a name to your search
      • use a quick filter as your default test execution page, use the star icon

      What's new?

      Target

      • It is the number of test runs your system shall (for required tests)/should (for option tests) verified 
      • Orange is used for required test; grey is used for optional test
      • The target turns into green when it's reached

      Progress at capability level

      • The progress bar reaches 100% when all the targets for the required tests are reached. For this reason, the maximum number of test runs taken into account is the target nulber
      • Optional tests are not counted
      • Progress bar disapeared as soon as the capability is evaluated

      Not included

      • Progress in terms of percentage, it was often misleading
      • Ability to write an internal comment at a test case level, it was rarely used

       

      Gazelle Test Management 6.5.0 - Released on 22 July 2022

      This version of Gazelle Test Management can be integrated with KeyCloack as a identification provider. It allows users to log into third-party tools using their Gazelle's credentials.

      This version of Gazelle Test Management comes with a module to communicate with rocket.chat, it allows:

      • Creating users accounts for all the active users registered in Gazelle Test Management;
      • Creating a dedicated private channel when a test run is started;
      • Sending notification to the test run channel when changes are brought to the test run in Gazelle Test Management.

      Gazelle Test Management 6.4.0 - Released on 14 April 2022

      Continuous test session

      Test session managers can now create test session with no registration deadline, nor start and end dates. It will be more convenient than setting up dates far in the future. In such Continuous test sessions, participants can add and edit systems under test at any time.

      Support to participants in the test session process

      When participants logs into Gazelle Test Management with role vendor or vendor_admin, they will now see a new section on the home page. This section indicates which phase is ongoing: registration, preparation, testing, or evaluation and gives shortcuts to the features of interest in the given phase.

      In a next release, this section will be enriched with indicators about the progress of the Progress, Testing, and Evaluation for each accepted system under test.

      Test execution

      On the test execution page, the type of test is now displayed for each test. For the IHE Connectathon* 2022, it has been chosen to get rid of the Pre-Connectathon feature and rather use the Test execution page. When you access your test plan (Testing > Test execution), you will see the Preparatory-test, they are the tests you are expected to execute before the event starts.

      That is to say that you will now use the test instance page to report results about a Preparatory (Pre-Connectathon) test.

      Supportive/Thorough

      You still have the ability to request to test as "supportive", rules remain unchanged. This feature is now called Testing depth.

      Gazelle Test Management 6.3.0 - Released on March 18

      New menu

      The whole menu bar has been reorganised for all the users. 

      • TF (for Technical Framework) was a so obscure label that it has simply been renamed into Specifications. We've done some clean-up to keep only the sections of interest for each category of users. The first entry in the menu leads you to the website hosting the specifications this instance of Gazelle is used for.
      • Test session entry is only visible to administrators of the tool and test session managers (if they are assigned to the current session), it gathers the pointers to all the features that are dependent on the test session: Invoicing, SUT management, attendees management, KPI,...
      • Registration is where you will start your registration journey.
      • Preparation gather the pointers to the network configuration (including the configuration of your endpoints, now known as SUT network interface) as well as those to the Preparatory tests (formerly known as Pre-Connectathon menu).
      • Testing is where you will go during the actual testing phase of the test session. You will find the "Test execution and logs" page, formerly known as main Connectathon page.
        • Sample exchange is where to go to post and consume sample objects;
        • Testing session scope shows you what are the profiles being tested;
        • Available partners lists all the systems under test registered for the ongoing testing session;
        • Test repository is where all the test cases defined in your project (Connectathon, Projectathon) reside.
      • Evaluation is where you will find the final results of the test session, which capabilities are passed or failed for all the systems under test your organisation has registered.
      • Administration is available to test session managers, tool administrators and organisation owners. You will find there access to the user management, organisation details management and so on.

      New home page

      The home page is now fully editable. No more generated content you do not want to disclose to the users. The tool administrator can input his own content.

      A placeholder for the documentation has been added to the home page. It will allow the event organizers to gather all the resources in one place. 

      In the same way, you will notice a new "Tool index" section on the home page and on all pages in the Gazelle Test Management tools. It gathers all the useful pointers to the test tools of interest for the participants. This section is as well editable by the tool administrator.

      The registration page

      For users with role vendor or vendor owner, the page accessible from the Registration menu gathers three pages from the "old" Gazelle: Manage systems (now Participating systems under test), Test session participants (now Event attendees), Financial summary (now Fees and Contracts). In this first version, the edition of those objects is still performed using the old page.

      And next?

      The main changes to be brought in the coming months:

      • More accurate indicators and details about the test runs for SUT Operators
      • Apply feedbacks about the test execution page

      Test tools' configurations

      This page gathers the capabilities of the various actors emulated by Gazelle platform along with the link to their configuration information.

      Integration Profile System under test's role Tested transaction Tool Tool's role
      (link to configuration page)
      ATNA Audit Record Repository   Gazelle Security Suite  
      ATNA Secure Node/Secure Application   Gazelle Security Suite  
      CMPD Community Pharmacy Manager PHARM-1 XD* Client Medication Dispenser
      CT Time Client ITI-1 XD* Client Time Server
      DSUB     XD* Client  
      HMW Administration Informer   HMW Simulator  
      HMW Medication Dispenser   HMW Simulator  
      HMW Pharmaceutical Adviser   HMW Simulator  
      HMW Prescription Placer   HMW Simulator  
      HPD Provider Information Consumer ITI-58 HPD Simulator Provider Information Directory
      HPD Provider Information Directory ITI-58 HPD Simulator Provider Information Consumer
      ITI-59 HPD Simulator Provider Information Source
      HPD Provider Information Source ITI-59 HPD Simulator Provider Information Directory
      LAW Analyzer LAB-27
      LAB-29
      Order Manager Analyzer Manager (receiver)
      LAB-28 Order Manager Analyzer Manager (initiator)
      LAW Analyzer Manager LAB-27 Order Manager Analyzer (LAB-27 initiator)
      LAB-28 Order Manager Analyzer (responder)
      LAB-29 Order Manager Analyzer (LAB-29 initiator)
      LBL Label Broker LAB-61
      LAB-62
      LAB-63
      LBL Simulator Label Information Provider
      LBL Label Information Provider LAB-61
      LAB-62
      LAB-63
      LBL Simulator Label Broker
      LCSD Code Set Master LAB-51 LCSD Simulator Code Set Consumer
      LCSD Code Set Consumer LAB-51 LCSD Simulator Code Set Master
      LTW Order Filler LAB-3 Order Manager Order Result Tracker
      LAB-1
      LAB-2
      Order Manager Order Placer (initiator)
      Order Placer (responder)
      LAB-4 Order Manager Automation Manager (responder)
      LAB-5 Order Manager Automation Manager (initiator)
      LTW Order Placer LAB-1
      LAB-2
      Order Manager Order Filler (initiator)
      Order Filler (responder)

      LTW
      Automation Manager LAB-4 Order Manager Order Filler (initiator)
      LAB-5 Order Manager Order Filler (responder)
      LTW Order Result Tracker LAB-3 Order Manager Order Filler
      MPQ      XD* Client  
      PAM Patient Demographics Consumer ITI-30 Patient Manager Patient Demographics Supplier
      PAM Patient Demographics Supplier ITI-30 Patient Manager Patient Demographics Consumer
      PAM Patient Encounter Supplier ITI-31 Patient Manager Patient Encounter Consumer
      PAM Patient Encounter Consumer ITI-31 Patient Manager Patient Encounter Supplier
      PDQ Patient Demographics Consumer ITI-21
      ITI-22
      Patient Manager Patient Demographics Supplier
      PDQ Patient Demographics Supplier ITI-21
      ITI-22
      Patient Manager Patient Demographics Consumer
      PDQV3 Patient Demographics Consumer ITI-47 Patient Manager Patient Demographics Supplier
      PDQV3 Patient Demographics Supplier ITI-47 Patient Manager Patient Demographics Consumer
      PIX Patient Identity Consumer ITI-9 Patient Manager Patient Identifier Cross-Reference Manager (responder)
      ITI-10 Patient Manager Patient Identifier Cross-Reference Manager (initiator)
      PIX Patient Identity Source ITI-8
      ITI-30
      Patient Manager Patient Identifier Cross-Reference Manager (responder)
      PIX Patient Identifier Cross-Reference Manager ITI-9 Patient Manager Patient Identity Consumer (initiator)
      ITI-10 Patient Manager Patient Identity Consumer (responder)
      ITI-8 Patient Manager Patient Identity Source
      ITI-30 Patient Manager Patient Identity Source
      PIXV3 Patient Identity Consumer ITI-45 Patient Manager Patient Identifier Cross-Reference Manager (responder)
      ITI-46 Patient Manager Patient Identifier Cross-Reference Manager (initiator)
      PIXV3 Patient Identity Source ITI-44 Patient Manager Patient Identifier Cross-Reference Manager
      PIXV3 Patient Identifier Cross-Reference Manager ITI-45 Patient Manager Patient Identity Consumer (initiator)
      ITI-46 Patient Manager Patient Identity Consumer (Responder)
      ITI-44 Patient Manager Patient Identity Source
      SVS Value Set Repository ITI-48
      ITI-60
      SVS Simulator Value Set Consumer
      SVS Value Set Consumer ITI-48
      ITI-60
      SVS Simulator Value Set Repository
      SWF.b Order Filller
      Order Placer
      RAD-1 Patient Manager ADT
      SWF.b Order Filler
      Order Placer
      RAD-12 Patient Manager ADT
      SWF.b Acquisition Modality RAD-5 Order Manager Order Filler
      SWF.b

      Order Filler

      RAD-5 Order Manager Acquisition Modality
      RAD-2 Order Manager Order Placer (Initiator)
      RAD-3 Order Manager Order Placer (Responder)
      RAD-4
      RAD-13
      Order Manager Image/Report Manager
      SWF.b Order Placer RAD-2 Order Manager Order Filler (Responder)
      RAD-3 Order Manager Order Filler (Initiator)
      SWF.b Image Manager
      Report Manager
      RAD-4
      RAD-13
      Order Manager Order Filler
      XCA     XD* Client  
      XCA-I     XD* Client  
      XCF     XD* Client  
      XCPD     XD* Client  
      XDR     XD* Client  
      XDS.b     XD* Client  
      XDS-I.b     XD* Client  
      XUA     Gazelle Security Station  

      interoperability Testbed

      Overview

      This document captures the list of steps needed to execute an ITB test using the Patient Manager (simulator) application.

       

      Two servers

      For ITB Test Execution, we will be using two PatientManager instances, each deployed on a different server.  These systems will be configured as GATEWAY_OR1 and GATEWAY_OR2 in Gazelle TM.  

       

      GATEWAY_OR1 (deployed on Server A)

      This will be the initiating SUT that will submit the PIX Feed.  This instance of PatientManager cannot be deployed on same server as Gazelle Proxy.

       

      GATEWAY_OR2 (deployed on Server B)

      The responding SUT will be the PIX Manager.  This instance of PatientManager can be deployed alongside Gazelle TM and Gazelle Proxy (but does not have to be).

       

      PatientManager configuration on Server B

      1.1 On the responding PatientManager instance deployed on Server B, click on “Administration / HL7 Responders’ configuration” menu link.

       

      1.2 Verify that PDQ and PIX Manager actor IP addresses and ports are configured as highlighted below.  These are the default ports in Patient Manager for these actors.  The IP address of 127.0.0.1 means that these actors are running locally which is correct.  If these values are different for you, you’ll need to edit these rows to match these values. On this screen, it’s ok to use the loopback address (127.0.0.1).

       

      Gazelle TM configuration on Server B

      2.1 On Server B, log into Gazelle TM using the admin credentials.  

      2.2 Click on the “Configurations / All Configurations” menu item.

       

       

      2.3 Filter for “GATEWAY_OR2” in the system dropdown.  GATEWAY_OR2 will be the responding PatientManager on Server B.

       

      2.4 Verify that the IP address and ports in black font match the values from this step 1.2   Note that it’s best to use the actual IP address of the machine where the responding Patient Manager is installed (Server B) and not the loopback address (127.0.0.1).  You can focus on the rows highlighted in red.  Ignore the other rows.  If the ports or IP addresses are incorrect then edit the row.  Note that after editing the row, the proxy ports (in red font) will likely change dynamically.  Take a snapshot of your screen after you’ve made your edits as you’ll need the IP address and Proxy port (red) for later steps.

       

       

      To change the IP address of the “host” that Server B (GATEWAY_OR2) represents, you would need to follow the steps below:

      2.4.1  As admin user, click on “Administration / Manage / Configurations / Manage hosts’ configurations” menu item.

       

      2.4.2 Click on the Edit button for OR2:

       

      2.4.3 Change the IP address to the actual IP address of Server B.  Do not use loopback address (127.0.0.1).  Click on Save.

      Follow steps 2.4.1 – 2.4.3 for OR1 system.  This time you would be changing the IP address to IP address of Server A.

      Create test instance

      3.1 Log out of Gazelle and log back in as tuser1/tuser1.  This is the user representing the organization in control of GATEWAY_OR1.

       

      3.2. Click on the “Interoperability Dashboard” menu link:

       

      3.3. Filter for GATEWAY_OR1 in the system dropdown:

       

       

      3.4. Filter for PAT_IDENTITY_SRC in the Actor dropdown:

      3.5. Click on the plus sign next to ITB_PIX_FEED to start the “New Test Instance” wizard:

       

       

      3.6. Click the plus sign, then move “GATEWAY_OR2” to the right, and then click on “Add Selected Partners” button:

       

       

      3.7. Click the play button highlighted in red to create the test instance:

       

      3.8. Leave your current browser window and open a new browser window for the rest of the steps.

       

       

      Execute test

       

      4.1 On the initiating Patient Manager instance installed on Server A, click on “SUT Configurations” menu link.  Verify that the IP address and ports match the values from step 2.4 i.e. the IP address of the Server B (where the Proxy is installed) and the Proxy ports waiting for messages to be intercepted and forwarded to responding Patient Manager.  The ports on this step need to match the Proxy ports (in red) in step 2.4 and NOT the ports in black font.  If they don’t match, then click on Edit button and correct them.

       

      4.2. On the same initiating Patient Manager UI, click on the ITI-8 menu link

      4.3. Select “Patient Manager” in the SUT dropdown:

      4.4. Verify that the IP address and port matches the IP address and Proxy Port (red) values from step 2.4 for PIX Manager.  Then click on “generate patient” radio button.  Then click on “Generate patient” button.

       

      4.5. Click on “Fill in the encounter with random data” on the same screen:

       

      4.6. Click on the “Send” button.

       

      4.7. The execution might take a minute or so.  You should see the “Execution status” progress from Waiting Initiated Completed on your first browser window:

       

      10. Validation Context

       

      Notice in the Test Instance screen above that the Configuration column cells for Sending and Receiving Actors are empty.  No Validation Context files have been configured yet.  Validation Context files allow for more content validation using NIST Validation services.  You can upload Validation Context files as a Test Editor user on the Test Definition screen and recreate/re-execute a new test instance: