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 is made of several kinds of tools:

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

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

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.

Principle of the method

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.

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.

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.

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.

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.

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.

List of simulators

see Simulators section of the Gazelle user guide

Simulated profiles and actors

• IT-Infrastructure
• HPD : Healthcare Provider Directory
• Provider Information Consumer
• Provider Informaion Source
• Provider Information Directory
• PAM : Patient Administration Management (integrated in PatientManager application)
• Patient Demographic Consumer
• Patient Demographic Supplier
• Patient Encounter Consumer
• Patient Encounter Supplier
• PDQ: Patient Demographic Query (integrated in PatientManager application)
• Patient Demographic Consumer 
• Patient Demographic Supplier
• PDQv3 : Patient Demographic Query HL7V3 (integrated in PatientManager application)
• Patient Demographic Consumer
• Patient Demographic Supplier
• PIX : Patient Identifier Cross-referencing for MPI (integrated in PatientManager application)
• Patient Identity Source
• Patient Identity Cross-Reference Manager
• Patient Identity Consumer
• SVS: Sharing Value Set
• Value Set Consumer
• Value Set Repository
• XCPD: Cross-Community Patient Discovery
• Initiating Gateway (integrated in XD* Client)
• Responding Gateway
• XDStarClient : Simulation of the initiator on XD* transactions (XDS.b, XDS-I.b, XDR and XCA)
• Document Source
• Document Consumer
• Initiating Gateway
• XDW: Cross-Enterprise Document Workflow
• XUA : Cross-Entreprise User Assertion
  • X-Assertion Provider
• Radiology
  • SWF: Radiology Scheduled Workflow
  • Image Display (access the simulator)
  • RAD-2, RAD-3, RAD-4, RAD-5, RAD-13 (integrated in OrderManager)
  • ADT  (integrated in PatientManager application)
  • SWF.b (integrated in OrderManager)
• Laboratory
• LAW: Laboratory Testing Workflow (integrated in OrderManager)
• LBL : Laboratory Specimen Barcode Labeling
• LCSD : Laboratory Code Set Distribution
• LTW: Laboratory Testing Workflow (integrated in OrderManager)
• Pharmacy
  • HMW : Hospital Medication Worflow (Work in progress)
• Cross-domain
  • Order Manager : The intent of the Order Manager is to manage Orders and Dicom Worklist generation for testing purposes.
• Cross-profile
  • Patient Manager : The Patient Manager tool emulates the actor/profiles dedicated to the management of the patient demographics and visits within the hospital.

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

FAQ about tools to be completed

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

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.

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.

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.

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.

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.

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

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

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: