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

Overview of the Demographic Data Server (DDS) project

When running a test we often need to inject demographic data. The aim of the tool is to generate the necessary data. Generated data are fictious (not real) but looks like real data. Demographic characteristics consist of

• a name, last name, mother maiden name ...

• date of birth,

• sex,

• religion,

• race,

• address

• etc ...

The address consists of the street, town, state, zip code and country. Addresses are randomly generated. We use the geonames database and googlemaps geocoding webservices in order to generate random addresses or more specific research. Generated addresses contains zip code information, matching the city name. Currently generated demographic information can be generated for the United-States, France, Germany and Japan. We are working on including data for more countries. Demographic Dataserver is taking into account information about the frequency of firstname, lastname, race and religion. The Demographic Data Server provides a Web User interface as well as a Web Service interface.

The java documentation of this project is available here.

DDS Web User interface 

User can access to DDS using the DDS web page. The GUI offers the possibility to generate patient data, see all generated patient data and shre this patient data with other systems in HL7 v2 or v3.

How to create a new patient data ?

To create a new patient, go to the  menu. In the create patient page, user will have the choice between to tabs : "Patient's generation" and "Advances Patient's generation". 

• In the first tab, "Patient's generation", the user will be allow to create patient information by selecting the country . Once the country has been selected, hit the "Generate Demographic Data" button. The generated patient will have basic information (last name, first name, other firstname, mother maiden name, gender, data of birth, patient identifier in DDS, National Patient Identifier and one address). It is possible that some of this information are missing. At the bottom of the Patient Information panel, the  button can be used to send patient (with HL7 v2 or v3 messages) to the user system. Go to the next part below to send a patient with DDS. See below, one example of a generated patient : 

• In the second tab, "Advances Patient's generation", the user will be allow to create advanced patient information by using a lot of criteria. Criteria are all in the "Generation Options" panel. Once the user has set option, just hit the  button to generate patient information. DDS offers to the user to Preset the generation option according to the selected patient preset(s). For that, select the preset in the left panel, and hit the  button. Once you have selected all desire presets (selected preset are in the right panel), hit the  button to preset the option according to the selected preset(s). Then, hit the  button. (You can select more than one preset at the same time). For example, if user choose the "Dead Patient" preset, the "Dead Patient" option will be set to "Yes". This functionnality allows the user to quickly set the generation option. See below the result of a generated patient information.

How to consult existing patient data ?

To see all patient data generated by DDS, go to the  menu. This page show to the use, in a table, all patient data generated by DDS. User can use the FirstName and the LastName filters to search a specific patient. It is also possible to sort the patient data by Id (Id in DDS), FirstName, LastName, Gender, Race, Religion ... by hiting the  button.

In the action column : 

• The  button allows user to see the patient data in a pop-up. 
• The   button allows user to add the selected patient in the selected patient list. This list can be used to share patient. User can add to this list many patients as he wants. 

Finally, just below the patient data table, the user could find all patients of the selected patient list : 

• The  button can be used to share all patient data of the selected patient list.
• The  button can be used to reset the selected patient list.

The  button (over the patient table) can be used to refresh the patients list of the patient data table.

How to share patient data ?

The GUI allows the user to send the selected patients through an HL7 V2 or V3 messages. Once user has selected the patients to send to his system (see the section over), it is necessary to configure the sending option : 

1. User must select the HL7 message type and version. Four options are available, see the screenshot below.
2. Once the message typas has been seleted, the user must choose the character set encoding to use (only available for the HL7 version 2). The list of character set encoding depends on the country of the patients to send.  
3. Then, the user must fill the Targets Selected fields. This information are relative to the user system which will receive the patient data. It is possible to send the patient data to several system at the same time. See the example below, for HL7 v2. Hit the Add button to add the configuration to the list of configuration. Be careful, your target must have a port open on the internet. Before sending messages to your system, ensure that your firewall options give to DDS the access to your system. 
4. Finally, hit the  button to send all selected patient data to the configuration(s). A summury of exchanges will appear just below the configuration panel. For each message, you can hit the    button to see the full sent message content or the full acknowlegdment message content. See the example below.

Web Services Interface

The WSDL file describing the web service is here. You can also download an example of a project soapUI that use these methods from here.

Functionalities

Functionalities of DDS can be used by web services methods. In fact, DDS implement 7 methods on web service :

• returnAddress : generate random address from the country code
• returnAddressByCoordinates : generate a specific address from country code and coordinates
• returnAddressBtTown : generate a specific address from a town
• returnHL7Message : generate HL7 message on format XML from a country code
• returnPatient : generate a patient from a country code. We can restrict generation on same persons by specifying attributes like the gender, or on specifying a nearby name or a part of the name
• returnPatientWithAllOptions : generate a patient from a country code. All options to generate a patient are available here.
• returnPerson : generate a person without address, using the same attributes of generation of a patient
• sendHL7Message : generate and send a HL7 message to a target host and port.

The documentation of classes on this jar is there.

Web Services Limitation

We do not have limited ressources to offer for this service. Thus the access to the webservice is limited to a "reasonnable" number of request per days/minute. We'd like to avoid DoS on the gazelle tools because someone is requesting fake patients every second. 

Thus our limitation are :

• No more than 30 requests per IP address per minute
• No more than 3000 requests per period of 24 hours per IP address

If you'd like to generate large random data, please get in contact with Eric Poiseau and we will try to help you and generate data to fill your needs. 

Web Services Interface

The WSDL file describing the web service is here. You can also download an example of a project soapUI that use these methods from here.

Functionalities

Functionalities of DDS can be used by web services methods. In fact, DDS implement 12 methods on web service. See the table below to have further information :

Static WS Client for DDS

We have implemented a Static WSClient for DDS. This related jar is easy to use. You have only to add the jar file to the project, and use it. The jar file is downloadable here (on the Gazelle Maven repository). 

Web Services Limitation

We do not have limited ressources to offer for this service. Thus the access to the webservice is limited to a "reasonnable" number of request per days/minute. We'd like to avoid DoS on the gazelle tools because someone is requesting fake patients every second. 

Thus our limitation are :

• No more than 30 requests per IP address per minute
• No more than 3000 requests per period of 24 hours per IP address

If you'd like to generate large random data, please get in contact with Eric Poiseau and we will try to help you and generate data to fill your needs. 

You can allow specific IPs to do not have limited ressources.

To do this you need to update database with this kind of request : 

 UPDATE dds_user_request_historic SET unlimited=true WHERE ip_address='62.212.122.29';

The following table summarizes the list of features in the Gazelle Test Management Tool.

Testing Session Management

Gazelle Test Management can handle multiple testing sessions. The Multiple Test session can be run in parallel.  Monitor and Systems register for specific testing session. One can select the coverage of the testing session in terms of Domain and/or Profile. One can also specify the type of testing to be performed in a testing session : Pre-Connectathon, Connectathon, Certification.

Users Management

Module for the management of gazelle users and their roles. Handles the users account management: registration, lost password, user information update. Handles the management of the roles of the users.

Users are associated to an organization. .

Contacts Management

Management of the contacts for a participating company. Allows the participating companies to enter contacts within Gazelle. Contacts are mainly used for administrative purposes. Used to identify the financial contact, the contact for marketing questions and the contact for technical questions.

Contacts are NOT required to have a login.

Organizations Management

Management of all organization relative information. This information is mainly for the purpose of the connectathon management. Users, Contacts and Systems belongs to an organization. The module allows the management of the information about the organization : Address, Contacts, VAT information,... Read more...

Contract Management

Component that manages the creation of the contract for testing session participants. Summarize the registration of the participants and create a pdf document based on a template that can be customized for each testing session. This makes use of the jasperreport library. The link to the jasperreport template for the contract definition in a testing session, is specified within the properties of the testing session. One has the choice to enable or disable it for a given testing session. Read more...

Fees Management

Component for the management of invoice (generation of the invoice, based on a template) and estimation of the amount of the fees to be gathered for an event based on participation. Helpful for connectathon management. Invoice generation is dependent of the testing session and as for the contract based on a template that can be specific to a session.  Can be disabled for a given testing session. Read more..

Systems Management

Module for the management of Systems Under Tests (SUT). Manages the registration of the SUT for a testing session. What are the actors, integration profiles and options supported by each SUT. Allow participants to copy system characteristics from one testing session to the other.

Contains a rules engine that checks if the system correctly implements the IHE requirements of dependencies among the actors and profiles.

Tests Management

Modules for the definition of the tests. Test requirements per Actor/Profile/Options. Test script definition : Who are the participants ? What are the instructions for the participants ? What are the steps required to perform the test ?

Proxy Management

Interation with the Proxy component. Control of the proxy, instruct the proxy of the interfaces to open and close for testing purposes. Allow participants to link test instance steps to corresponding messages captured by the proxy.

Simulator Management

Component for the declaration and the management of the simulators that Gazelle uses to perform the tests.

Configuration Management

Management of the configuration of the systems and simulators performing together in a testing session. Knowing that most of the time spend during testing is lost during exchange of configuration parameters, it is essential that Gazelle allows the test participants to correctly and rapidly share configuration informations. That component allows the user to provide the information relative to their own systems. It also allow the test participants to rapidly find the relevant information about their peers in a test.

Monitor Management

Management of the monitors. Monitors are the independent and neutral individuals that check and validate the test performed during a testing session. The component allows the Technical Manager to assign tests to specific monitors. It allows the manager to split the load of test verification among the monitors. Test can be assigned to monitors either test by test, or monitor by monitor

Samples Sharing Management

Module for sharing samples. This component allows registered system to share and find samples. Some system need to provide samples, some need to render them. The component allows the participants to easily find the samples relevant for their systems. The sample sharing module is linked to External Validation Services for checking the conformity of the shared samples. The component makes also use of internal validation services

When relevant, the component module allows sample creators to provide a screen capture of the rendering of their samples. It also allows sample readers to provide a screen capture of the rendering of the sample on their system.

A sample and a test can be linked together. This is usefull in the case of scrutiny test. Read more...

Pre-connectathon Test Management

Allows managers to define the pre-connectathon test : Where to find the tool ? Where to find the documentation ? What actors/profile/options are concerned by the test.

Allows participants to find out what pre-connectathon tests they have to perform, to return corresponding logs and view result of logs grading. Read more...

Connectathon Test Management

Allows the managers to define the tests.

• What is the purpose of the test ? (assertion tested)
• What actors/profile/options are concerned by the test ? (test participants including the cardinality for each participants)
• The scenario of the test (sequence diagram of the interactions between the participants to the test), including the definition of what need to be checked at each step.
• How many instances of the test are required for a SUT to be declared as successfull to the test.

Allows engineers to find out what test need to be performed by their systems.

Allows engineers to start a test and select its participants (peer system under test or simulators)

Connectathon Test Grading

Module to allow the grading of systems participation during the connectathon. Allows the project managers to review test performed a determine success or not of a system to the participation of a specific actor / integration profile / option combination.

Patient Demographics for Testing Purposes

Module for sharing patients among the participants to a test instance. The module allow generation of simulated patient data using the Demographic Data Server. Generated patient data can be send to a selection of test participants using HL7 V2 or HL7 V3 messages.

Selection of the target is done based on systems configuration as declared in Gazelle. Target can be also configured manually. The component allows the management of multiple patient identification domains. The generated patient are assigned a unique id in the various patient identification domains of the target systems.

Stored data information can be used for validation of messages exchange by test instance participants.

Single Sign On

When enable component of Gazelle Test Management allows user to use a CAS server for their identification. Allows harmonization of the logins among the different applications. All Gazelle simulators also use the CAS login component. JIRA bug tracking system makes also use of it. Read more...

Test Update Notification

The purpose of the Test Update Notification is to reduce the load on the server that is hosting the Gazelle application. It allows connectathon participants to be informed of updates on the test instances that are of concern for them. Instead of refreshing the Gazelle Connectathon Dashboard all the times the participants are informed of new tests instances creation, updates, comments and grading.

Order Manager Binding

This feature is an extension of the Patient Demographic for testing purposes. It allows in addition of the creation of dummy patients, to create encounters and orders for them and send them to test participants. This is useful in the context of preparing the right conditions for a test.  All SUT participating to a test can be aware of the same patient, encounter and order. Read more...

Mobile Test Grading for Monitors

This feature add a webservice front end to Gazelle Test Management in order to allow the grading of the test using a mobile device like a WIFI enabled tablet PC (iPad) or a smart phone (iPhone, android...). Monitors can use their mobile device to scan a QR code on the page of test instance to grade and then directly access the page on their device. Read more...

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

This page indexes the different links to the user manual for the Gazelle Test Management application.

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

This section of the user guide is dedicated to the administrator of Gazelle Test Management, Gazelle Product Registry and Gazelle Master Model tools. It explains how to configure the tool, how to manage users, systems and so on.

Gazelle Test Management release notes can be found on the JIRA pages of the project at the following URL :

http://gazelle.ihe.net/jira/browse/GZL#selectedTab=com.atlassian.jira.plugin.system.project%3Achangelog-panel

Click to here to enter the TF overview 

Project overview

The Technical Framework (TF) overview is a tool that displays a graphical interface for the navigation among the TF concepts, indicating the description of those concepts and the access to their informations page.

Web user interface

Description

1. Breadcrumb : indicates the path in the navigation among TF concepts

2. Root : the keyword of the concept selected

3. Children : results concerning the root

4. Edge : link between the root and its children

5. Description : information about the child whose the mouse is over it

6. Link to access to the information page of the concept in the description

7. To close the description

Navigation

The first graphical representation displays all domains of the Technical Framework. Then, the navigation must be done in the following order :

• all integration profiles for given domain
• all actors for given integration profile
• all transactions and all integration profile options for given actor and integration profile
• all initiatiors and responders for given transaction

A click on the keyword of a children allows to generate the graphic. A click on the root allows to go back in the navigation and it allows to generate the previous graphic.

Project overview

On the information page of an integration profile, the integration profile diagram is a graphical representation that displays the transactions between the actors for this integration profile.

Technical Framework Web user interface

Description

1. diagram of actor/transaction pairs in the selected integration profile
2. zoom out
3. zoom in
4. save the diagram on the user computer

Introduction

Gazelle Master Model (GMM) allows administrators to add new Integration Profile information into Gazelle.  This enables vendors to register testing these profiles at a Connectathon.    Gazelle must be configured to know about the actors, transactions, and options defined within an Integration Profile.  It must know which Domain the Integration Profile belongs to.

Entering IHE Profile information consists of these 6 steps detailed in this documentation:

1. Add New Actors
2. Add New Transactions
3. Link Transactions to Actors
4. Add New Options
5. Add a New Integration Profile
6. Link Actors, Transactions, and Options to the Integration Profile
7. Link the Integration Profile to a Domain

Not currently covered in this document, but needed in order for profile entry to be complete:

1. Entering profile mandatory groupings (aka profile dependencies)   ie Actor A in Profile P must also implement Actor B in  profile Q (eg all actors in the XDS.b profile must also implement ATNA Secure Node)
2. Entering default configurations for transactions in the profile
3. Entering sample definitions
4. Entering Roles for test definitions

Test definitions are available

• in Gazelle Master Model under Tests Definition --> Tests Definition (read/write)
• in Test Management under Tests Definiton --> Tests Definition (read only)

Test definitions are, with the technical framework, the basis of Gazelle and its important feature to prepare for and participate in a connect-a-thon. The tests define the scenarios the different actors implemented by a system must pass to be validated by the connect-a-thon managers. This section of the documentation is mostly dedicated to test editors to explain the different sections of a test and how they have to be filled when creating new tests.

Prior to writing a test, three main concepts have to be introduced that determine who will see the test and when.

• Test type: indicates whether the test has to be performed during the connectathon or the pre-connect-a-thon period. A third type was added in order to gather the tests dedicated to HITSP profiles.
• Test status: indicates the level of advancement of the test. Only "ready" tests will be displayed in the participants' system's tests list during the connect-a-thon or pre-connect-a-thon period. "To be completed" are test currently under development, but are not yet ready to expose to participants.  "Deprecated" tests are those which are not used anymore, in the same way the storage/subsitute tests have been replaced by more relevant ones. Finally, the "convert later" status has been created when the test definitions have been imported from the Kudu system; it means that we do not need this test by now and consequently it is not a priority to work on it.
• Test Peer Type: indicates if the system can perform this test with "no peer" (no transaction to exchange with a vendor test partner), "peer to peer" are tests covering a subset of a profile, typically with 2, or sometimes 3, partners.  "Group tests" cover a workflow within an integration profile and are tests run by a full set of actors within the profile; group test are typically supervised directly by a connectathon monitor.

Each test definitions is built of four parts which are defined below.  Each part is contained on an separate tab within the test

1. Test Summary

It gives general informations about the test:

• Keyword, name and the short description are used to identify the test.  By convention, the keyword name starts with the profile acronym.
• The test type is connectathon, pre-connectathon but can be other type as defined in the database.
• The test status indicates the readyness of the test. Only test with a status marked as ready are visible by the testers.
• The peer type indicates is the test is of type "No peer", "Peer to Peer" or "Group Test"
• The permanent link to the test is printed in this part (computed by Gazelle)
• The version of the test gives an indication of the most recent testing event for which the test was created/modified.
• The "Is orchestrable" attribute indicates whether the test will be run against a simulator (true) or against another system under test (false). When run against a simulator, the test requires the use of Bpel service and Gazelle web services to be orchestrated. Those services will enable the simulator to communicate with Gazelle in a standalone mode without any help from somebody.
• The "Is validated" attribute indicates whether the test is validated or not. 

2. Test Description

This section describes very precisely the test scenario and gives indications to the vendor on how to perform the test, which tools are required and so on. This part also gives keys to the monitor about the things to check, the message to validate and so on. This part of the test can be translated into different languages.  By convention, there are three sections in the test description:

• Special Instruction: contain information for the vendor of "special" considerations for this test, for example "ABC test must be run before this one", or "XYZ tool is used in this test"
• Description: Is a short overview of the scope of the test. 
• Evaluation:  These are the specific instructions to the connectathon monitor describing what evidence must be shown by the vendor in order to "pass" this test.

3. Test Roles

It is the most important part of the test, it is also the most complicated and confusing part of the work.

Assigning one or more Roles to a test determines which Actor/Integration Profile/Profile Option (AIPO) are involved in the test. Roles must be well-chosen for two reasons: (1) If a Role is assigned to a test, it means that the test will appear on the list of tests to do for any test system which supports the AIPO in the Role, and (2) only the transactions supported by the chosen Roles will be available when you define individual Test Steps on the next tab..

Prior to starting a test definition, you should ensure that the Test Roles you need for the test exist; if not, they can be created under Tests Definition --> Role in test management.

A test role (or role in test) is defined as a list of Actor/Integration profile/Profile Option and for each of these AIPO we must specify if the tuple is tested or not. The primary reason to include a Test Participant (ie an AIPO) in a Role with "Tested?" unchecked is because you want the transactions supported by that Test Participant (AIPO) to be used by the other test participants in that Role, but you do not want that test to show up as required for that test participant that is "not tested".  This primarily occurs when one actor is "grouped" with another actor.

The whole test role can be set as "played by a tool", for example the OrderManager (formally RISMall) or the NIST registry or a simulator or so on.

A convention has been put in place for the naming of test roles:

 <ACTOR_KEYWORD>_<INTEGRATION_PROFILE_KEYWORD>[_<PROFILE_OPTION_KEYWORD>|_ANY_OPTIONS][_WITH_SN][_WITH_ACTOR_KEYWORD][_HELPER]

If several actors from a profile or several profiles are used to defined the test role, only the main couple Actor/Integration Profile must be used to name the role.

By ANY_OPTIONS we mean that any system implementing one of the option defined for the profile must perform the tests involving this role.

_WITH_SN means that the transactions in which the role takes part must be run using TLS, consequently the involved actors must implement the Secure Node actor from ATNA profile. Note that, in that case, the Secure Node actor is set "not tested", so that failling this test do not fail the Secure Node actor.

_WITH_ACTOR_KEYWORD means that the system must support a second actor, the one is not tested, in order to perform some initialization steps. For example PEC_PAM_WITH_PDC gathers the Patient Encounter Consumer actor from the Patient Admission Management profile and the Patient Demographic Consumer from the same profile; this is required because we need to populate the database of the PEC with some data received thanks to the PDC. Keep in mind that such associations must be meaningful that means that the gathered actors are linked by an IHE dependency.

Finally, _HELPER means that the role is not tested but is required to ensure the coherence of the test.

Here are some examples to let you better understand the naming convention:

DOC_CONSUMER_XDS.b_ANY_OPTIONS gathers all the Document Consumer of the XDS.b profile no matter the options they support.

IM_SWF_HELPER gathers all the Image Manager from the Schedule Workflow profile but those actors are not tested.

If the test participant is a tool or a simulator, we will used the system name as test role name: <SIMULATOR or UTILITY_NAME>, for instance ORDER_MANAGER, CENTRAL_ARCHIVE, NIST_REGISTRY and so on.

Once you have chosen the roles involved in your test, you will be asked, for each of them to give some more information such as:

• # to realize: the number of times the system must realize with success this test for the tested actor to be validated.  Typically, this is "3" for peer to peer tests, and "1" for No Peer and Group tests.
• Card Min: (cardinality) how many (at least) systems with this role must be involved in the test
• Card Max: (cardinality) how many (at most) systems with this role can be involved in the test
• Optionality: whether or not this role is a mandatory participant in the test.  "Required" means a vendor cannot start the test until a system is identified for this role.  "Optional" means that the test may be run whether or not a system is identified for this role in the test.

4. Test Steps

To help vendors with performing the test, we cut the test into small entities called test steps. In a newly defined test, when you first arrive on this page, you will find a sequence diagram only filled with the different roles you have previously defined. As you add test steps, you will be able to see the sequence diagram is automatically updated according to the steps you have defined. The red arrows stand for secured transaction (TLS set to true)

Test steps are ordered based on the step index, in most of the cases, vendors will have to respect the given order, especially if the test is run against a simulator.

Each step is described as follows:

• Step index: index of the step
• Initiator role: test role in charge of initiating the transaction (only roles with actors which are initiators for at least one transaction can be used as initiator role)
• Responder role: test role acting as the receiver for this step (only roles with actors which are responders for at least one transaction can be used as responder role)
• Transaction: the transaction to perform by the two actors
• Secured: indicates whether the transaction must be perform over TLS or not
• Message type: the message sent by the initiator
• Option: indicates whether the test step is required or not
• Description: detailed instructions on how to perform the step

When editing a step, you can choose to check or not the Auto Response box. When it is checked, it indicates that the selected role has to perform a step alone (initialization, log ...), no transaction nor message type have to be specified.

In order not to waste time editing steps for a little change, the step index field, secured checkbox, option selection and description fields can be filled from the main page of test steps. The change is recorded in database each time you lose the focus of the modified field.

If you have chosen to write an orchestrated test, that means that the system under test will communicate with a simulator, you may have to enter some more informations called "Contextual Information". In some cases, those informations are needed by the simulator to build a message which match the system configuration or data. This can be used to specifiy a patient ID known by the system under test for instance.

Two kinds of contextual informations are defined:

• Input Contextual Information: The information provided to the simulator
• Output Contextual Information: The information sent back by the simulator and that can be used as input contextual information for the next steps

For each contextual information, you are expected to provide the label of the field and the path (it can be XPath or HL7 path if you need to feed a specific XML element or HL7v2 message segment). A default value can also be set.

If you have defined output contextual informations for previous steps, you can use them as input contextual information for next steps by importing them, as it is shown on the capture below. So that, the simulator will received the return of a previous step as new information and will be able to build next messages.

For more details about the expectation of simulators, read the developer manual of the simulator you want to involve in your test. A short example based on XCA Initiating Gateway Simulator use is given below.

XCA Initiating Gateway supports two transactions: ITI-38 for querying the responding gateway about the documents for a specific patient and ITI-39 to retrieve those documents. In a first step we may ask the responding gateway for the documents of patient 1234^^^&1.2.3.4.5.6&ISO, in the second step we will ask the responding gateway to send the first retrieved document.

In this way, no action on the simulator side is required from the vendor, he/she only has to set up his/her system under test and give the first input contextual information to the simulator through the Test Management user interface.

This page is not complete yet and need review

In some Peer to Peer tests, the transactions supported by one Role are identical across multiple different tests, yet that Role's partners across those tests are different.  This is best illustrated by an example:  In Cardiology and Radiology workflow profiles, a scheduling system (Order Filler Role) profiles a worklist to various imaging systems (Modality Roles).  A vendors' Order Filler may play the Order Filler Role in Radiology SWF profile and Cardiology ECHO, CATH and STRESS profiles.  If the Order Filler may be assigned a Peer to Peer "worklist" test with modalities in each of these profiles.  This could result in 12 worklist tests to pass for the Order Filler (3 worklist tests x 4 profiles).  Meta Tests allow test definers to eliminate this kind of redundant testing.

Meta tests are special tests are built of equivalent test definitions for a given test role. Actually, we try not to duplicate tests but it can happen that two different tests are the same according the point of view of one test role involved in both. In that case, we merge the two tests under one Meta Test for this specific role.

When a vendor sees a Meta Test in his/her system's test list the equivalent tests are listed within the meta test.  He/she is allowed to perform 3 instances of any of the tests within the meta test instead of three instances for each individual test.. That means that if the meta test is composed of 4 tests, the involved actor is expected to have any combination of 3 instances verified,

Meta tests are defined in gazelle under Test Definition --> Meta test list.  A Meta test is given a keyword and a short description; then the equivalent tests are linked to the meta test.

As an example, let's take the meta test with keyword Meta_Doc_Repository_Load. This Meta test gathers four tests defined, among other, for the Document Repository actor of the XDS-I.b profile. Each of these tests ask this actor to perform the RAD-68 and ITI-42 transactions against an actor supporting several options. From the point of view of the Document Repository, those four tests are equivalent since we are testing four times the same transactions. Consequently, running only three of the twelve instances it would have had to do is enough to be successfully graded.

This page provides the instructions on how to add a slave application to the master model.

Pre-requisite

• slony 2.0.6  : The version of slony on the slave and on the master shall be identical. Currently the version in use is 2.0.6. Run the following command to find out the version you are running 

admin@master:~$ slon -v 
slon version 2.0.6 
admin@master:~$ 
admin@slave:~$ slon -v 
slon version 2.0.6 
admin@slave:~$ 

• postgresql 8.4.x : the version of postgresql on the slave and on the master are not required to be identical. The version used shall be one of the 8.4 series. The master is running 8.4.7. The master system needs to access the database on the slave. This achieved by configuring the file pg_hba.conf on the slave.

• Make sure that the file pg_hba.conf on the slave contains the following entries. 

# TYPE DATABASE USER CIDR-ADDRESS METHOD 
host gazelle-on-slave gazelle 131.254.209.12/32 md5 
host gazelle-on-slave gazelle 131.254.209.13/32 md5 
host gazelle-on-slave gazelle 131.254.209.14/32 md5 
host gazelle-on-slave gazelle 131.254.209.15/32 md5

where host is the gazelle-on-slave is the name of the gazelle database on the slave. When the configuration of the slave is succesful then you should be able to run the following command 

psql -h slave -U username gazelle-on-slave

and access the remote database.

One this level of configuration is reach we can start configuring slony on the master and on the slave.

Initialisation of slony on the master system

I usually have them in ~/slony

The slony initialisation script is stored in the file : slonik_init.sk. The file should be executable. When this script is run it creates a new schema on each of the nodes (slaves and master). If you need to rerun the script, make sure that you delete the schema from each of the nodes 

DROP SCHEMA "_TF" CASCADE  ;

Content of the file : slonik_init.sk 

#!/usr/bin/slonik
define CLUSTER TF;
define PRIMARY 1;
define EPSOS 10;
define TM 20;
define PR 30;
define ORANGE 60;
cluster name = @CLUSTER;
# Here we declare how to access each of the nodes. Master is PRIMARY and others are the slaves.node @PRIMARY admin conninfo = 'dbname=master-model host=jumbo.irisa.fr user=gazelle password=XXXXXX';
node @TM admin conninfo = 'dbname=ihe-europe-2010 host=kujira.irisa.fr user=gazelle password=XXXXXX';
node @PR admin conninfo = 'dbname=product-registry host=jumbo.irisa.fr user=gazelle password=XXXXXX';
node @EVSCLIENT admin conninfo = 'dbname=evs-client-prod host=jumbo.irisa.fr user=gazelle password=XXXXXX';
node @ORANGE admin conninfo = 'dbname=gazelle-na-2012 host=gazelle-orange.wustl.edu user=gazelle password=XXXXXX'
# Initialisation of the cluster
init cluster (id=@PRIMARY, comment='Gazelle Master Model');
# Declaration of the slaves 
store node (id=@TM, event node=@PRIMARY, comment='Test Management Slave');
store node (id=@PR, event node=@PRIMARY, comment='Product Registry Slave');
store node (id=@EVSCLIENT, event node=@PRIMARY, comment='EVS Client Slave');
store node (id=@ORANGE, event node=@PRIMARY, comment='Test Management Slave Orange');
# Define the path from Slaves to Master 
store path (server=@PRIMARY, client=@TM, conninfo='dbname=master-model host=jumbo.irisa.fr user=gazelle');
store path (server=@PRIMARY, client=@PR, conninfo='dbname=master-model host=jumbo.irisa.fr user=gazelle');
store path (server=@PRIMARY, client=@EVSCLIENT, conninfo='dbname=master-model host=jumbo.irisa.fr user=gazelle');
store path (server=@PRIMARY, client=@ORANGE, conninfo='dbname=master-model host=jumbo.irisa.fr user=gazelle');
# Define the path from Master to Slaves
store path (server=@TM, client=@PRIMARY, conninfo='dbname=ihe-europe-2010 host=kujira.irisa.fr user=gazelle');
store path (server=@PR, client=@PRIMARY, conninfo='dbname=product-registry host=jumbo.irisa.fr user=gazelle');
store path (server=@EVSCLIENT, client=@PRIMARY, conninfo='dbname=evs-client-prod host=jumbo.irisa.fr user=gazelle');
store path (server=@ORANGE, client=@PRIMARY, conninfo='dbname=gazelle-na-2012 host=gazelle-orange.wustl.edu user=gazelle password=gazelle');

The next file to consider is : script_server.sk 

#!/usr/bin/slonik
define CLUSTER TF;
define PRIMARY 1;
define TM 20;
define PR 30;
define EVSCLIENT 40;
define ORANGE 60;
cluster name = @CLUSTER;
#Declaration of the nodes
node @PRIMARY admin conninfo = 'dbname=master-model host=jumbo.irisa.fr user=gazelle password=gazelle';node @TM admin conninfo = 'dbname=ihe-europe-2010 host=kujira.irisa.fr user=gazelle password=gazelle';
node @PR admin conninfo = 'dbname=product-registry host=jumbo.irisa.fr user=gazelle password=gazelle';
node @EVSCLIENT admin conninfo = 'dbname=evs-client-prod host=jumbo.irisa.fr user=gazelle password=gazelle';
node @ORANGE admin conninfo = 'dbname=gazelle-na-2012 host=gazelle-orange.wustl.edu user=gazelle password=gazelle';
# We need 2 sets: One for the Technical Framework (TF) part and one for the Test Definition (Test Management = TM) part 
create set (id=1, origin=@PRIMARY, comment='TF');
create set (id=2, origin=@PRIMARY, comment='TM');
# Assign the table and sequences to each of the nodes
set add table (id=176, set id=1, origin = @PRIMARY, fully qualified name = 'public.revinfo', comment = 'table');
set add table (id=174, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_actor', comment = 'table');
set add table (id=175, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_actor_aud', comment = 'table');
set add sequence (id=2, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_actor_id_seq', comment = 'seq');
set add table (id=3, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_hl7_message_profile_table', comment = 'table');
set add table (id=4, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_hl7_message_profile_table_aud', comment = 'table');
set add sequence (id=5, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_hl7_message_profile_table_id_seq', comment = 'seq');
set add table (id=6, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_actor_integration_profile_option', comment = 'table');
set add table (id=7, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_actor_integration_profile_option_aud', comment = 'table');
set add sequence (id=8, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_actor_integration_profile_option_id_seq', comment = 'seq');
set add table (id=9, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_integration_profile', comment = 'table');
set add table (id=10, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_integration_profile_aud', comment = 'table');
set add sequence (id=11, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_integration_profile_id_seq', comment = 'seq');
set add table (id=12, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_integration_profile_option', comment = 'table');
set add table (id=13, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_integration_profile_option_aud', comment = 'table');
set add sequence (id=14, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_integration_profile_option_id_seq', comment = 'seq');
set add table (id=15, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_actor_integration_profile', comment = 'table');
set add table (id=16, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_actor_integration_profile_aud', comment = 'table');
set add sequence (id=17, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_actor_integration_profile_id_seq', comment = 'seq');
set add table (id=18, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_integration_profile_type', comment = 'table');
set add table (id=19, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_integration_profile_type_aud', comment = 'table');
set add sequence (id=20, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_integration_profile_type_id_seq', comment = 'seq');
set add table (id=21, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_transaction_link', comment = 'table');
set add table (id=22, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_transaction_link_aud', comment = 'table');
set add sequence (id=23, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_transaction_link_id_seq', comment = 'seq');
set add table (id=24, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_transaction_option_type', comment = 'table');
set add table (id=25, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_transaction_option_type_aud', comment = 'table');
set add sequence (id=26, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_transaction_option_type_id_seq', comment = 'seq');
set add table (id=27, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_profile_link', comment = 'table');
set add table (id=28, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_profile_link_aud', comment = 'table');
set add sequence (id=29, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_profile_link_id_seq', comment = 'seq');
set add table (id=30, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_integration_profile_status_type', comment = 'table');
set add table (id=31, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_integration_profile_status_type_aud', comment = 'table');
set add sequence (id=32, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_integration_profile_status_type_id_seq', comment = 'seq');
set add table (id=33, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_profile_inria_hl7_validation_files', comment = 'table');
set add table (id=34, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_profile_inria_hl7_validation_files_aud', comment = 'table');
set add sequence (id=35, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_profile_inria_hl7_validation_files_id_seq', comment = 'seq');
set add table (id=36, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_configuration_mapped_with_aipo', comment = 'table');
set add table (id=37, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_configuration_mapped_with_aipo_aud', comment = 'table');
set add sequence (id=38, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_configuration_mapped_with_aipo_id_seq', comment = 'seq');
set add table (id=39, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_conf_mapping_w_aipo_w_conftypes', comment = 'table');
set add table (id=40, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_conf_mapping_w_aipo_w_conftypes_aud', comment = 'table');
set add table (id=42, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_conftype_w_ports_wstype_and_sop_class', comment = 'table');
set add table (id=43, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_conftype_w_ports_wstype_and_sop_class_aud', comment = 'table');
set add sequence (id=44, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_conftype_w_ports_wstype_and_sop_class_id_seq', comment = 'seq');
set add table (id=45, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_transaction_status_type', comment = 'table');
set add table (id=46, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_transaction_status_type_aud', comment = 'table');
set add sequence (id=47, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_transaction_status_type_id_seq', comment = 'seq');
set add table (id=48, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_configuration_type', comment = 'table');
set add table (id=49, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_configuration_type_aud', comment = 'table');
set add sequence (id=50, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_configuration_type_id_seq', comment = 'seq');
set add table (id=51, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_meta_test', comment = 'table');
set add table (id=52, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_meta_test_aud', comment = 'table');
set add sequence (id=53, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_meta_test_id_seq', comment = 'seq');
set add table (id=54, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_meta_test_test_roles', comment = 'table');
set add table (id=55, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_meta_test_test_roles_aud', comment = 'table');
set add table (id=57, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_role_in_test_test_participants', comment = 'table');
set add table (id=58, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_role_in_test_test_participants_aud', comment = 'table');
set add table (id=60, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_sop_class', comment = 'table');
set add table (id=61, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_sop_class_aud', comment = 'table');
set add sequence (id=62, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_sop_class_id_seq', comment = 'seq');
set add table (id=63, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_test_description', comment = 'table');
set add table (id=64, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_test_description_aud', comment = 'table');
set add sequence (id=65, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_test_description_id_seq', comment = 'seq');
set add table (id=66, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_test_participants', comment = 'table');
set add table (id=67, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_test_participants_aud', comment = 'table');
set add sequence (id=68, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_test_participants_id_seq', comment = 'seq');
set add table (id=69, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_test_test_description', comment = 'table');
set add table (id=70, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_test_test_description_aud', comment = 'table');
#set add sequence (id=71, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_test_test_description_id_seq', comment = 'seq');
set add table (id=72, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_test_steps_input_ci', comment = 'table');
set add table (id=73, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_test_steps_input_ci_aud', comment = 'table');
set add table (id=75, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_test_steps_option', comment = 'table');
set add table (id=76, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_test_steps_option_aud', comment = 'table');
set add sequence (id=77, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_test_steps_option_id_seq', comment = 'seq');
set add table (id=78, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_test_steps_output_ci', comment = 'table');
set add table (id=79, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_test_steps_output_ci_aud', comment = 'table');
set add table (id=81, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_test_steps', comment = 'table');
set add table (id=82, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_test_steps_aud', comment = 'table');
set add sequence (id=83, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_test_steps_id_seq', comment = 'seq');
set add table (id=84, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_test_status', comment = 'table');
set add table (id=85, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_test_status_aud', comment = 'table');
set add sequence (id=86, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_test_status_id_seq', comment = 'seq');
set add table (id=87, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_test_roles', comment = 'table');
set add table (id=88, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_test_roles_aud', comment = 'table');
set add sequence (id=89, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_test_roles_id_seq', comment = 'seq');
set add table (id=90, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_web_service_type', comment = 'table');
set add table (id=91, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_web_service_type_aud', comment = 'table');
set add sequence (id=92, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_web_service_type_id_seq', comment = 'seq');
set add table (id=93, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_test_type', comment = 'table');
set add table (id=94, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_test_type_aud', comment = 'table');
set add sequence (id=95, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_test_type_id_seq', comment = 'seq');
set add table (id=96, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_domain',  comment = 'table');
set add table (id=97, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_domain_aud', comment = 'table');
set add sequence (id=98, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_domain_id_seq', comment = 'seq');
set add table (id=99, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_integration_profile_type_link', comment = 'table');
set add table (id=100, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_integration_profile_type_link_aud', comment = 'table');
set add table (id=102, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_test_test_steps', comment = 'table');
set add table (id=103, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_test_test_steps_aud', comment = 'table');set add table (id=105, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_test_option', comment = 'table');
set add table (id=106, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_test_option_aud', comment = 'table');
set add sequence (id=107, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_test_option_id_seq', comment = 'seq');
set add table (id=108, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_test_peer_type', comment = 'table');
set add table (id=109, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_test_peer_type_aud', comment = 'table');
set add sequence (id=110, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_test_peer_type_id_seq', comment = 'seq');
set add table (id=111, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_hl7_message_profile', comment = 'table');
set add table (id=112, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_hl7_message_profile_aud', comment = 'table');
set add sequence (id=113, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_hl7_message_profile_id_seq', comment = 'seq');
set add table (id=114, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_domain_profile',   comment = 'table');
set add table (id=115, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_domain_profile_aud', comment = 'table');
set add table (id=117, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_transaction', comment = 'table');
set add table (id=118, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_transaction_aud', comment = 'table');
set add sequence (id=119, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_transaction_id_seq', comment = 'seq');
set add table (id=177, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_hl7_message_profile_affinity_domain', comment = 'table');
set add table (id=178, set id=1, origin = @PRIMARY, fully qualified name = 'public.tf_hl7_message_profile_affinity_domain_aud', comment = 'table');
set add table (id=120, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_test', comment = 'table');
set add table (id=121, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_test_aud', comment = 'table');
set add sequence (id=122, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_test_id_seq', comment = 'seq');
set add table (id=123, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_transport_layer_for_config', comment = 'table');
set add table (id=124, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_transport_layer_for_config_aud', comment = 'table');
set add sequence (id=125, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_transport_layer_for_config_seq', comment = 'seq');
set add table (id=126, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_role_in_test', comment = 'table');
set add table (id=127, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_role_in_test_aud', comment = 'table');
set add sequence (id=128, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_role_in_test_id_seq', comment = 'seq');
set add table (id=129, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_contextual_information', comment = 'table');
set add table (id=130, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_contextual_information_aud', comment = 'table');
set add sequence (id=131, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_contextual_information_id_seq', comment = 'seq');
set add table (id=132, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_object_file', comment = 'table');
set add table (id=133, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_object_file_aud', comment = 'table');
set add sequence (id=134, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_object_file_id_seq', comment = 'seq');
set add table (id=135, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_object_creator', comment = 'table');
set add table (id=136, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_object_creator_aud', comment = 'table');
set add sequence (id=137, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_object_creator_id_seq', comment = 'seq');
set add table (id=138, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_object_attribute', comment = 'table');
set add table (id=139, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_object_attribute_aud', comment = 'table');
set add sequence (id=140, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_object_attribute_id_seq', comment = 'seq');
set add table (id=141, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_object_file_method', comment = 'table');
set add table (id=142, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_object_file_method_aud', comment = 'table');
set add table (id=144, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_object_attribute_option', comment = 'table');
set add table (id=145, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_object_attribute_option_aud', comment = 'table');
set add sequence (id=146, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_object_attribute_option_id_seq', comment = 'seq');
set add table (id=147, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_object_class_validator', comment = 'table');
set add table (id=148, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_object_class_validator_aud', comment = 'table');
set add sequence (id=149, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_object_class_validator_id_seq', comment = 'seq');
set add table (id=150, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_object_file_type', comment = 'table');
set add table (id=151, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_object_file_type_aud', comment = 'table');
set add sequence (id=152, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_object_file_type_id_seq', comment = 'seq');
set add table (id=153, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_object_instance_validation', comment = 'table');
set add table (id=154, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_object_instance_validation_aud', comment = 'table');
set add sequence (id=155, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_object_instance_validation_id_seq', comment = 'seq');
set add table (id=156, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_object_method_parameter', comment = 'table');
set add table (id=157, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_object_method_parameter_aud', comment = 'table');
set add table (id=159, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_object_parameter_validator', comment = 'table');
set add table (id=160, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_object_parameter_validator_aud', comment = 'table');
set add sequence (id=161, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_object_parameter_validator_id_seq', comment = 'seq');
set add table (id=162, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_object_reader', comment = 'table');
set add table (id=163, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_object_reader_aud', comment = 'table');
set add sequence (id=164, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_object_reader_id_seq', comment = 'seq');
set add table (id=165, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_object_type_status', comment = 'table');
set add table (id=166, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_object_type_status_aud', comment = 'table');
set add sequence (id=167, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_object_type_status_id_seq', comment = 'seq');
set add table (id=168, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_object_type', comment = 'table');
set add table (id=169, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_object_type_aud', comment = 'table');
set add sequence (id=170, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_object_type_id_seq', comment = 'seq');
set add table (id=171, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_object_method_validator', comment = 'table');
set add table (id=172, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_object_method_validator_aud', comment = 'table');
set add sequence (id=173, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_object_method_validator_id_seq', comment = 'seq');
set add table (id=179, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_path', comment = 'table');
set add table (id=180, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_path_aud', comment = 'table');
set add sequence (id=181, set id=2, origin = @PRIMARY, fully qualified name = 'public.tm_path_id_seq', comment = 'seq');
set add table (id=182, set id=2, origin = @PRIMARY, fully qualified name = 'public.tf_ws_transaction_usage', comment = 'table');
set add table (id=183, set id=2, origin = @PRIMARY, fully qualified name = 'public.tf_ws_transaction_usage_aud', comment = 'table');
set add sequence (id=184, set id=2, origin = @PRIMARY, fully qualified name = 'public.tf_ws_transaction_usage_id_seq', comment = 'seq');
# Then for each slave we tell to start the sync
#TM
subscribe set (id = 1, provider = @PRIMARY, receiver = @TM);
sync(id=@PRIMARY);
wait for event(origin=@PRIMARY, confirmed=@TM, wait on=@PRIMARY);
subscribe set (id = 2, provider = @PRIMARY, receiver = @TM);
sync(id=@PRIMARY);
wait for event(origin=@PRIMARY, confirmed=@TM, wait on=@PRIMARY);
#EVSCLIENT
subscribe set (id = 1, provider = @PRIMARY, receiver = @EVSCLIENT);
sync(id=@PRIMARY);
wait for event(origin=@PRIMARY, confirmed=@EVSCLIENT, wait on=@PRIMARY);
#PR
subscribe set (id = 1, provider = @PRIMARY, receiver = @PR); 
sync(id=@PRIMARY);
wait for event(origin=@PRIMARY, confirmed=@PR, wait on=@PRIMARY);
#ORANGE
subscribe set (id = 1, provider = @PRIMARY, receiver = @ORANGE);
sync(id=@PRIMARY);
wait for event(origin=@PRIMARY, confirmed=@ORANGE, wait on=@PRIMARY);
subscribe set (id = 2, provider = @PRIMARY, receiver = @ORANGE);
sync(id=@PRIMARY);
wait for event(origin=@PRIMARY, confirmed=@ORANGE, wait on=@PRIMARY);                                                                                                            

Initialization of slony on the slaves

Starting the slon process is not an easy command to type, so I have made a script on each of the slaves to execute the command. 

nohup slon TF "dbname=evs-client-prod user=gazelle" > evs-client-prod.log

 Launching the synchronization or restarting the synchronization

If you are lauching the synchronization for the first time (seen from the master) then you can start from point 4. At any point in the process if you encounter an error, you will need to restart from 1.

1. kill the slon process on all slaves : killall slon
   
2. kill the slon process on the master : killall slon
   
3. drop the "_TF" schema in all slaves databases
4. on the master run the slonik_init.sk script.
5. on each of the slaves start the slon processes
6. on the master start the slon process
7. on the master run the script_server.sk script
8. check the log files on each of the slaves and the master in order to make sure that the synchronization is actually taking place.

Click to here to enter the Proxy

 Proxy trainings:

• presentation from 2012
• presentation from 2014

Introduction

Gazelle TestManagement tools can be used in conjunction with a proxy for the capture of the messages exchanged between a test participants.

The proxy is able to capture : 

• HL7v2 messages
• Dicom Transactions
• Webservices messages
• Syslog messages

The advantages of using the proxy when running a test are the followings :

• the Proxy is a neutral way to capture the exchanged messages.
• the Proxy displays the captured messages in a unified way for all the tests performed, simplifying the work of the monitors when examining the logs
• the Proxy provides permanent link to the captured messages that can be linked to test instance steps and avoid the cut and paste of logs in the chat window of the test instance. It then helps linking the logs to the test and enables all the participants to the test to see the entire set of messages exchanges between the test participants.
• the Proxy helps verifying the captured messages through a direct link to the EVS Client GUI.

Limitations

• Proxy acts as a network relay between two SUTs. As a result, system configuration has to be modified. The TCP connection must be established on the proxy on the system configuration's proxy port instead of opening a connection to the responder SUT directly.

How does it work ?

For each system in Gazelle TestManagement tool there is a set of configuration parameters. For each port that an SUT needs to open, there is a mirror port number on the proxy. 

All proxy ports must be opened by a Gazelle admin, each system configuration being mapped to a proxy port.

The proxy GUI can be access at the following URL : http://gazelle.ihe.net/proxy

Automated filtering

Proxy and Gazelle know each other, and each test step in Gazelle has a proxy link.

This link displays the list of the messages matching the test step configuration. It also filters the messages by time, showing only messages sent after the last test step marked as verified (or test instance started) and this test step marked as to be verified.

Finding captured messages manually

By accessing proxy directly using http://gazelle.ihe.net/proxy, messages can be filtered on different criterias. By clicking a value in the table, it either opens the message details for id column, or set the filter for other columns.

The messages list displays only one type of message, if HTTP is selected, HL7v2 messages are not shown.

Each captured message has a permanent link that can be used in Gazelle. The best way to use it is to add this link to a test step instance. The monitor will be then able to validate the message using EVSClient.

WebService API

• startAllChannels : It takes "List<Configuration> configurations" in argument. It start a new channel in proxy for each configuration set.
• startTestInstance : It takes "TestInstance testInstance" in argument. It start a new channel in proxy for a test instance.
• markTestStep : It takes "int testStepId" in argument. It set the date of a test step with the current.
• getMinProxyPort : It return the min_proxy_port define in proxy configuration.
• getMaxProxyPort : It return the max_proxy_port define in proxy configuration.

Login

 The login link ("cas login") is located in the top right corner of the page.

Note that, like the other applications from Gazelle testing platform, Order Manager is linked to our CAS service. That means that, if you have an account created in the European instance of Gazelle Test Management, you can use it, if you do not have one, you can create one now by filling the form here. Note that if you only have an account for the North Americal instance of Gazelle, it will not work with the OrderManager; you will need to create a new account.  The OrderManager application is dedicated to the test of several actors and transactions in different domains.

Being logged in the application will give you access to some additional features. As an example, each time you create a new object in the application (patient, order, worklist ...), if you are logged in, you will be set as its "creator", which will enables you to easily retrieve your items. If the system you are testing has to receive messages from the OrderManager, the system you have selected will be stored into your preferences and the application will offer you this one in first position, the next time you launch a test.

Registration of Systems Under Test acting as HL7 responders

Most of the transactions offered by the Order Manager are based on HL7v2.x standard. If your system acts as an HL7 responder in one of the transactions offered by the simulator, for example your system is an Order Placer and supports RAD-3 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  or 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 OrderManager the access to your system.

Starting a test

The menu part located at the top of the application offers access to the three IHE domains in which the Order Manager can be involved for testing. Each domain menu is divided into sub menu, each of them standing for an actor of the domain. The other entries are dedicated to the application configuration and browsing.

• SUT configurations is the starting point for users who test an HL7 responder, this menu is a link to the page of system configurations
• HL7 messages leads to the page gathering all the HL7 messages sent and received by the simulator.

Below are some tips to easily access the right page of the tool depending on what you want to do.

Send and receive queries for AWOS

If you want to test your Analyzer Manager, select Laboratory/Analyzer/[LAB-27]Query Analyzer Manager for AWOS to send messages (defined by LAB-27 transaction) to your system under test

If you want to test your  Analyzer, select Laboratory/Analyzer Manager/Configuration : this page shows the configuration of the Analyzer Manager actor to which your Analyzer can send messages in the context of a LAB-27 transaction. 

Create, cancel, replace ... an order

If you want to test your Order Filler, select the Radiology/Order placer submenu. This sub menu will offer you 2 choices

1. [RAD-2] Create/Cancel order: use this page to send the messages specified by the Placer Order Management transaction (RAD-2) to your Order Filler
2. Configuration : this page shows the configuration of the Order Placer to which your Order Filler can send messages in the context of a RAD-3 transaction. 

If you want to test your Order Placer, select the Radiology/Order filler submenu. This sub menu will offer you 2 choices

1. [RAD-3] Create/Update/Cancel order: use this page to send the messages specified by the Filler Order Management transaction (RAD-3) to your Order Placer
2. Configuration : this page shows the configuration of the Order Filler to which your Order Placer can send messages in the context of a RAD-3 transaction. 

If you want to test your Laboratory Order Placer, select the Laboratory/Order Filler submenu. This sub menu will offer 3 sets of transactions, only two of them are of your interest:

1. [LAB-1/LAB-2] Notify Order Placer of orders: use this page to send messages (from LAB-1 and LAB-2 transactions) to your system under test
2. Configuration:  this page shows the configuration of the Order Filler to which your Order Placer can send messages in the context of a LAB-1 transaction.

Create a worklist and query the SCP

The part of the simulator acting as an Order Filler is also able to create DICOM worklists, the latter can be queried by your modalities in the context of RAD-5 transaction for instance. A kind of proxy is running and listening to your C-FIND queries, the ones are forwarded to the DICOM Basic Worklist Management SCP (wlmscpfs) from the DICOM toolkit developed by OFFIS, DCMTK. Before being forwarded, the messages are stored in database and the received responses are also stored before being forwarded to your system. In this way you can look at the exchange messages and we plan to add a validation service. The log file produces by the SCP is split and stored in the database of the tool, in that way you can consult more details about the DICOM association performed with our tool.

This page is no longer maintain. Please visit https://gazelle.ihe.net/OrderManager/administration/valueSetManager.seam for the up-to-date list of codes.

 (1) This table contains the list of codes used by the Order Manager tool.  They are also codes at Connectathon by ADT, Order Placer and Order Filler actors exchanging HL7 patient registration and order messages.

All codes are stored in the Repository part of the SVS Simulator and can be retrieved from a REST service.

(2) The mapping between ordering codes in the following table and the procedure codes in Radiology is based on the file available at https://gazelle.ihe.net/common/order-manager/orderHierarchy4Radiology.xml

Order Filler and Order Placer actors needs to be aware of the patient's demographics and encounters. In the radiology and cardiology domains, this functionnality is assumed by the ADT actor with the RAD-1 and RAD-12 transactions. In other domains, the use of PAM (Patient Admission Management) integration profile is recommended and often required. In order to populate the Order Manager with consistent data, we have chosen to put in place a mechanism for sharing patient and encounter data between several applications from the Gazelle testing platform. In case you just need a patient and an encounter but you did not use PAM Simulator or Test Management applications to create it, you can randomly generate one.

Random generation of patient and encounter

For the needs of the OrderManager, a REST web service has been implemented in PAMSimulator application which enables the other applications to get random data for a patient and/or an encounter. As a consequence, if you want to create an order for a new patient or for a new encounter (you already have the patient created in OrderManager) you only have to select the country in the application (or the existing patient), the PAM Simulator will return you a patient and a related encounter or only an encounter.

The example below is taken from the page which enables a user to send a new order to his/her Order Filler.

1. Hit the button entitled "Create new patient and encounter" if none of the offered encounters nor patients meet your needs.

2. You will then have to choose the country of your patient. Here we have chosen India.

3. Finally, the patient and the encounter have been created

If you want to use a patient already registered in the application, use the "Create a new encounter for an existing patient" button, you will be asked to pick up one of the existing patient and an encounter will be automatically, randomly generated.

Import patient from PAM Simulator and Test Management

Both PAM Simulator and Test Management application enable the user to create patients according various criteria. In some tests, you will want to reuse the same patient without losting your time copying each piece of information one by one. In order to save your time during the connectathon or during your testing periods, we have added a feature in those application. You will only have to select the patient you need, hit a button, choose the patient identifier to use for creating the order or the worklist and send the request to the OrderManager.

In PAMSimulator, the button is available for each patient in the All Patients page. In Test Management, go to Connectathon --> Patient Generation and Sharing --> tab "Existing patients".

The screenshots below are taken from Test Management. 

1. Select the patient to import in Order Manager. Here we have chosen the first one, Yanira Gregg by hitting the "Create a worklist for this patient" button; the last button of the row, on the right.

2. A pop-up shows up and ask you from which assigning authority you want to use the patient identifier. Select the proper assigning authority and hit the green button.

3. I will then arrive in OrderManager, the patient demographics are filled and an encounter has been created randomly. You then need to tell the application if you want to create an order or a worklist for this patient. If you want to create an order, specified which actor will have to send it (Order Placer or Order Filler). If you choose to create a worklist, specified the integration profile for which you are performing the test. Finally, hit the "create" button.

Note that, if you choose to create a worklist, the order will be filled with random values.

Import encounter from PAM Simulator

If you have created an encounter in the PAM Simulator application, you may want to use it to create an order or an encounter. In this case, choose the encounter you want to import into OrderManager; go to its permanent page and hit the button "Create a worklist or an order for the selected encounter". You will also be asked to select the patient's identifier; then you will reach the page described in point 3.

The OrderManager tool is able to manage orders from various domains:

• Radiology, Eye Care, and Cardiology orders (RAD-2 and RAD-3 transactions)
• Laboratory orders (LAB-1 and LAB-2 transactions)
• Pathology orders (PAT-1 and PAT-2 transactions)

Radiology, Eye Care, and Cardiology orders

The order management part for radiology/cardiology is divided into two parts: placer order and filler order. The placer order part gathers the actions related to the Placer Order Management transaction (RAD-2) whereas the filler order part is dedicated to the Filler Order Management transaction (RAD-3). 

The orders can be created either by the Order Placer (RAD-2) or by the Order Filler (RAD-3). In both cases, each system attributes an order number to the just created order. In the RAD-3 transaction case, initiated by the Order Filler, the Order Placer has to notify the Order Filler of the number it has attributed to the order contain in the message sent by the Order Filler.

SWF.b

From version 4.0.0, the Order Manager tool supports the SWF.b profile. It will be able to handle and validate the OMG messages your SUT sent to it. You can also ask the tool to use HL7v2.5.1 instead of HL7v2.3.1 when configuring the message to send to your SUT, to do so, tick the "Send HL7v2.5.1 messages ?" checkbox.

Placer Order management (RAD-2)

The placer order management transaction is initiated by the Order Placer, the one sends a message of type ORM^O01^ORM_O01 to the Order Filler. Three actions can be performed, for each one, the order control code contained in the message (ORC-1) differs.

Your system plays the role of the Order Filler for this transaction, read the following lines:

You reach this page from menu Radiology/Order Placer/[RAD-2] Create/Cancel orders.

Create a new order (order control code = NW)

Firstly, select the configuration of your system under test; the simulator needs it to send the message. Then select "Create a new order" choice. The list of encounters stored in the simulator is displayed, you just have to select the one you want. If you are logged in, you can easily retrieve the encounters you have previously created by checking the "Display only my data" checkbox. The demographics of the patient related to the selected encounter and the details about the encounter are displayed. Below, you can see a panel entitled "The order". Here are the values required by the simulator to create the message. If you are boring with filling all the fields, you can fill only some (or none) of them and hit the "Randomly fill the order and send message". Random values will be taken from the SVS repository. If you feel courageous, fill the requried fields and hit "send message" button. Finally, the table gathering the message sent by the simulator and the one received from your system is displayed. You can used the validation button to check the conformance of the messages to the IHE specifications.

Hit the "Perform another test" button to continue testing.

Cancel an existing order (order control code = CA)

Select the action to perform as "Cancel an existing order". You will be provided with the list of orders holded by the Order Placer part of the simulator. Select the one you want to cancel, a pop-up shows up which ask you to confirm your choice. If you click "yes", the message is automatically sent to your Order Filler. If you click "no", the pop-up is closed and nothing else is done.

Stop the fullfilment of an "in progress" order (order control code = DC)

The order control code DC is sent when an order is already started. The action to perform are the same as the one for cancelling an order. 

Your system plays the role of the Order Placer for this transaction, read the following lines:

Read carefully the configuration of our Order Filler. To do so, go to Radiology/Order Filler/Configuration. The Order Filler will store all the messages it receives and integrates them; that means that it will create/cancel/discontinue the sent order. Be carefull to always send the same placer/filler order number for a given order. The orders received from your simulator are stored in the database and you can browse them from menu Radiology/Order Filler/Data Browser. The name of the creator is "{sending application}_{sending facility}".

Filler Order management (RAD-3)

The placer order management transaction is initiated by the Order Filler, the one sends a message of type ORM^O01^ORM_O01 to the Order Placer. Three actions can be performed, for each one, the order control code contained in the message (ORC-1) differs. 

Your system plays the role of the Order Placer for this transaction, read the following lines:

You reach this page from menu Radiology/Order Filler/[RAD-3] Create/Update/Cancel orders.

Create a new order (order control code = SN)

Firstly, select the configuration of your system under test; the simulator needs it to send the message. Then select "Create a new order" choice. The list of encounters stored in the simulator is displayed, you just have to select the one you want. If you are logged in, you can easily retrieve the encounters you have previously created by checking the "Display only my data" checkbox. The demographics of the patient related to the selected encounter and the details about the encounter are displayed. Below, you can see a panel entitled "The order". Here are the values required by the simulator to create the message. If you are boring with filling all the fields, you can fill only some (or none) of them and hit the "Randomly fill the order and send message". Random values will be taken from the SVS repository. If you feel courageous, fill the requried fields and hit "send message" button. Finally, the table gathering the message sent by the simulator and the one received from your system is displayed. You can used the validation button to check the correctness of the messages.

Hit the "Perform another test" button to continue testing.

Cancel an existing order (order control code = OC)

Select the action to perform as "Cancel an existing order". You will be provided with the list of orders holded by the Order Filler part of the simulator. Select the one you want to cancel, a pop-up shows up which ask you to confirm your choice. If you click "yes", the message is automatically sent to your Order Placer. If you click "no", the pop-up is closed and nothing else is done.

Update the status of an order (order control code = SC)

Select the action to perfrom as "Update order status". you will be provided with the lists of orders horded by the Order Filler part of the simulator. Select the order you want to update, a pop-up shows up which ask you to select the new status of the order. Click on the "Send update notification", the message will be automatically sent to your system under test.

Your system plays the role of the Order Filler for this transaction, read the following lines:

Read carefully the configuration of our Order Placer. To do so, go to Radiology/Order Placer/Configuration. The Order Placer will store all the messages it receives and integrates them; that means that it will create/cancel/update the sent order. Be carefull to always send the same placer/filler order number for a given order. The orders received from your simulator are stored in the database and you can browse them from menu Radiology/Order Placer/Data Browser. The name of the creator is "{sending application}_{sending facility}".

Laboratory orders

All the actors playing a role in the LTW and LAW integration profiles from the Laboratory domain are available under the Laboratory menu.

Order Placer

Under the Laboratory/Order Placer menu, you will find three sub menus:

• [LAB-1/LAB-2] Notify Order Filler of orders: this page is dedicated to the sending part of the Order Placer actor from LTW profile. You will be able to create/cancel an order and to send a message to your SUT acting as an Order Filler.
• Configuration: this page is dedicated to the receiving part of the Order Placer. You will find the IP address, port and receiving application/facility names of this part of the simulator.
• Data Browser: this entry points to the page where the patients and the orders/specimens owned by this part of the simulator are gathered.

Order Filler

Under the Order Filler menu, you will find five sub menus but only two of them deal with the management of orders :

• [LAB-1/LAB-2] Notify order placer of orders: this page is dedicated to the sending part of the Order Filler actor from the LTW profile. You will be able to create/cancel update the status of an order and send a message to your SUT acting as an Order Placer.
• Configuration: this page is dedicated to the receiving part of the Order Filler. You will find the IP address, port and receiving application/facility names of this part of the simulator.

Creation of a new order

Both Order Filler and Order Placer parts of this simulator work in the same way; only some little differences can be noticed due to differences between those two actors as described in the Technical Framework of Laboratory.

First of all, select your system under test from the drop-down list entitled "System Under Test".

Then select the action to perform: Create a new order

As defined in the Technical Framework, LAB-1 and LAB-2 transactions allows the Order Filler and Order Placer actors to exchange orders using different structures. In this part of the simulator, we enable you to test all of them. Differences between structures implies that the way to build an order in not the same depending on the message you want to send. As a consequence, before creating an order, you will have to tell the simulator which structure you want to use (see below).

Then select an encounter from the displayed list. Using "Create a new patient and encounter" you will be able to ask for the generation of a new patient with random demographic data, using "Create a new encounter for an existing patient" you will get a new encounter for a patient selected in the displayed list.

Laboratory order message (OML^O21^OML_O21) 

This message structure is battery-centric. To build such an order, follow the steps below:

1. You are first asked to fill out the order properties (use the "Fill with random values"  button for a random filling of the form).
2. Once you think the order is properly defined, click on "Create a specimen for order" button.
3. A new form appears, fill it out with specimen properties, in the same way as previously the "Fill with random values" button can help you for this task. 
4. Click on "Add to current order" to add the specimen to the order you have previously created.
5. If you need more than one specimen, click on "Add a specimen to this order" button and repeat steps 3 to 5.
6. Once all the specimens are created, click on "Send message" button.

Note that you can remove a specimen from the list using the red "minus" sign located on each row of the table.

Laboratory order for multiple orders related to a single specimen (OML^O33^OML_O33)

This message structure is specimen-centric. To build such an order, follow the steps below:

1. You are first asked to fill out the specimen properties (use the "Fill with random values" button for a random filling of the form).
2. Once you think the specimen is properly defined, click on "Create an order for specimen" button.
3. A new form appears, fill it out with order properties, in the same way as previously the "Fill with random values" button can help you for this task.
4. Click on "Add to current specimen" button to add the order to the specimen you have previously created.
5. If you need more than one order, click on "Add an order to this specimen" button and repeat steps 3 to 5.
6. Once all the orders are created, click on "Send message" button.

Note that you can remove an order from the list using the red "minus" sign located on each row of the table.

Laboratory order for multiple orders related to a single container of a specimen (OML^O35^OML_O35)

This message structure is specimen-centric. For each specimen, a list of containers is given and for each container, a list of orders is specified. To build such an order, follow the steps below:

1. You are first asked to fill out the specimen properties (use the "Fill with random values" button for a random filling of the form).
2. Once you think the specimen is properly defined, click on "Create a container for specimen" button. The list of containers specified for the current specimen is displayed. 
3. To add an order for a given specimen click on the "Add an order for this container" button.
4. Fill out the order properties and click on the "Add to current container" button. The order will be displayed within a table below the relative container.
5. Repeat steps 3 and 4 until you have created all the orders you want.
6. If you need to add another container to the specimen, click on "Add a container for specimen" button.
7. To add orders to this new container, repeat steps 3 and 4.
8. Finally, click on the "Send message" button.

Note that you can remove an order from a container using the red "minus" sign located on each row  of the table. You can also remove a container from the specimen by clicking on the red "minus" sign located beside the container identifier.

Cancellation of an order

Both Order Filler and Order Placer actors can cancel existing orders. See below the instructions to send such a message to your SUT.

1. Select your system under test from the drop-down list entitled "System Under Test".
2. Then select the action to perform: Cancel an existing order
3. Select the structure of message to use
4. Select the order to cancel. A pop-up raises, click on "Yes" to send the cancellation message.

Update of an order

Only the Order Filler has the capabilities to update the status of an order. See below the instructions to send such a message to your Order Placer.

1. Select your system under test from the drop-down list entitled "System Under Test".
2. Then select the action to perform: Update order status.
3. Select the structure of message to use
4. Select the order to update. A pop-up raises, select the new status of the order and click on "Send update notification" button.

Sending messages to the simulator from your SUT

As mentionned above, the simulator is able to act as an Order Filler and an Order Placer (receiving role) for LAB-1 and LAB-2 transactions. The messages supported by the simulator are the same as the one it is able to send, all of three defined structures will be understood by the simulator. To browse the orders received by the simulator, go to the Data Browser menu linked to the actor you are using:

• All orders (battery-centric) for the orders sent and received within OML^O21^OML_O21 messages
• All orders (specimen-centric) for the orders received and sent within OML^O33^OML_O33 and OML^O35^OML_O35 messages. In that page, you will first see the specimen, and then, for each specimen, the list of orders.

Pathology orders

Not yet implemented

The OrderManager tool is able to manage work orders; that means that it can act either as an Order Filler or an Automation Manager for the LAB-4 transaction defined in the Laboratory Technical Framework. As a consequence, both parts support OML^O21^OML_O21, OML^O33^OML_O33 and OML^O35^OML_O35 message structures.

Your SUT acts as an Order Filler

As an Order Filler, you may want to send messages to our Automation Manager. To do so, retrieve the configuration of the Automation Manager part of the simulator from menu Laboratory/Automation Manager/Configuration.

If you want to see the work orders received by the Automation Manager, go to Laboratory/Automation Manager/Browse data menu. The creator of the work orders contained in the messages you send is set to SendingApplication_SendingFacility.

Your SUT acts as an Automation Manager

There are two ways to send messages to your Automation Manager from the Order Manager tool. The first thing you have to do in both cases, is registering your system under test within the application. To do so, go to the "SUT Configurations" section of the tool, and click on the "Create a configuration..." button. Read the tutorial here for further explanation.

Creating a work order from scratch

Going to Laboratory/Order Filler/[LAB-4] Notify Automation Manager of work orders, you will reach the page which allows you to configure a new work order or to cancel a work order known by the Order Filler part of the tool.

As defined in the Laboratory Technical Framework, the Order Filler and the Automation Manager may use three different structures to share work orders. The Order Filler implemented in the tool is able to send all of them. Differences between structures imply that the way to build a work order in not the same depending on the message you want to send. As a consequence, before creating an order, you will have to tell the simulator which structure you want to use.

Then select an encounter from the displayed list. Using "Create a new patient and encounter" you will be able to ask for the generation of a new patient with random demographic data, using "Create a new encounter for an existing patient" you will get a new encounter for a patient selected in the displayed list.

Laboratory order message (OML^O21^OML_O21) 

This message structure is battery-centric. To build such a message, follow the steps below:

1. You are first asked to fill out the work order properties (use the "Fill with random values"  button for a random filling of the form).
2. Once you think the order is properly defined, click on "Create a specimen for order" button.
3. A new form appears, fill it out with the specimen properties, in the same way as previously the "Fill with random values" button can help you for this task. 
4. Click on "Add to current order" to add the specimen to the work order you have previously created.
5. If you need more than one specimen, click on "Add a specimen to this order" button and repeat steps 3 to 5.
6. Once all the specimens are created, click on "Send message" button.

Note that you can remove a specimen from the list using the red "minus" sign located on each row of the table.

Laboratory order for multiple orders related to a single specimen (OML^O33^OML_O33)

This message structure is specimen-centric. To build such a message, follow the steps below:

1. You are first asked to fill out the specimen properties (use the "Fill with random values" button for a random filling of the form).
2. Once you think the specimen is properly defined, click on "Create an order for specimen" button.
3. A new form appears, fill it out with the work order properties, in the same way as previously the "Fill with random values" button can help you for this task.
4. Click on "Add to current specimen" button to add the work order to the specimen you have previously created.
5. If you need more than one work order, click on "Add an order to this specimen" button and repeat steps 3 to 5.
6. Once all the orders are created, click on "Send message" button.

Note that you can remove a work order from the list using the red "minus" sign located on each row of the table.

Laboratory order for multiple orders related to a single container of a specimen (OML^O35^OML_O35)

This message structure is specimen-centric. For each specimen, a list of containers is given and for each container, a list of work orders is specified. To build such a message, follow the steps below:

1. You are first asked to fill out the specimen properties (use the "Fill with random values" button for a random filling of the form).
2. Once you think the specimen is properly defined, click on "Create a container for specimen" button. The list of containers specified for the current specimen is displayed. 
3. To add a work order for a given specimen click on the "Add an order for this container" button.
4. Fill out the work order properties and click on the "Add to current container" button. The work order will be displayed within a table below the relative container.
5. Repeat steps 3 and 4 until you have created all the work orders you want.
6. If you need to add another container to the specimen, click on "Add a container for specimen" button.
7. To add work orders to this new container, repeat steps 3 and 4.
8. Finally, click on the "Send message" button.

Note that you can remove a work order from a container using the red "minus" sign located on each row  of the table. You can also remove a container from the specimen by clicking on the red "minus" sign located beside the container identifier.

Cancellation of an order

See below the instruction to send a cancellation notification to your Automation Manager.

1. Select your system under test from the drop-down list entitled "System Under Test".
2. Then select the action to perform: Cancel an existing order
3. Select the structure of message to use
4. Select the order to cancel. A pop-up raises, click on "Yes" to send the cancellation message.

Creating a work order from an existing laboratory order

In the context of a workflow, the work order is created by the Order Filler from a laboratory order previously received from an Order Placer or created within the Order Filler itself. The tool allows the user to create a work order using a laboratory order owned by the Order Filler part of the tool. The message structure used to send such a work order will be the same that the one used at receiving/sending time of the related laboratory order.

To select the laboratory order to use, go to the "Laboratory/Order Filler/Browse data" section and select one of "All orders (battery-centric)" or "All orders (specimen-centric)". Use the  button to select the laboratory order/specimen to use. A new page will be opened, the lists of related work orders/specimens/containers are displayed. You can remove the entities which must not appear in the message using the  button. Do not forgot to select your system under test configuration in the drop-down list at the top of the page and click on the "Send message" button.

The OrderManager tool supports the LAW Profile of the Laboratory Domain. It means that the OrderManager tool is able to send and reveive query for AWOS (Analytical Work Order Step) (LAB-27 transaction) and to send and receive AWOS (LAB-28 transaction). 

Your SUT acts as an Analyzer

As an Analyzer, you may want to send a query for AWOS to our  Analyzer Manager (LAB-27) and receive AWOS from our Analyzer Manager (LAB-28).

Send queries for AWOS to the Analyzer Manager part of the simulator

As defined in the Laboratory Technical Framework Supplement for the Laboratory Analytical Workflow Domain (LAW), the Analyzer can query the Analyzer Manager for a WOS realated to a specimen. This is described in the LAB-27 transaction.

To do so, retrieve the configuration of the Analyzer Manager part of the simulator by going to Laboratory/Analyzer Manager/Configuration.

Receive an AWOS from the Analyzer Manager Simulator

As defined in the Laboratory Technical Framework Supplement for the Laboratory Analytical Workflow Domain (LAW), the Analyzer can receive a new AWOS or a cancelation on an existing AWOS, from the Analyzer Manager. This is described in the LAB-28 transaction.

Going to Laboratory/Analyzer Manager/[LAB-28]Analytical Work Order Step Broadcast, you will reach the page which enables you to configure a new work order or to cancel a work order known by the Analyzer Manager part of the tool.

First at all, select a System Under Test (SUT) configuration in the SUT configuration drop-down list.

For the "Action to perform", you have the choice between 2 different ways :

• "Create a new order" : Used to create and send a new order to your SUT.  

1. Select an encounter from the displayed list. Using "Create a new patient and encounter" you will be able to ask for the generation of a new patient with random demographic data, using "Create a new encounter for an existing patient" you will get a new encounter for a patient selected in the displayed list.
2. You are first asked to fill out the specimen properties (use the "Fill with random values" button for a random filling of the form).
3. Once you think the specimen is properly defined, click on "Create an order for specimen" button.
4. A new form appears, fill it out with the work order properties, in the same way as previously the "Fill with random values" button can help you for this task.
5. Click on "Add to current specimen" button to add the work order to the specimen you have previously created.
6. If you need more than one work order, click on "Add an order to this specimen" button and repeat steps 3 to 5.
7. (Note that you can remove a work order from the list using the red "minus" sign located on each row of the table.)

• "Cancel an existing order"

1. Select the order to cancel. A pop-up raises, click on "Yes" to send the cancellation message.

Your SUT acts as an Analyzer Manager

As an Analyzer Manager, you may want to receive a query for AWOS from our  Analyzer (LAB-27) and send an AWOS to our Analyzer (LAB-28).

Send queries for AWOS to the Analyzer Manager SUT

As defined in the Laboratory Technical Framework Supplement for the Laboratory Analytical Workflow Domain (LAW), the Analyzer can query the Analyzer Manager for a WOS related to a specimen. This is described in the LAB-27 transaction.

To do so, go to the Laboratory/Analyzer/[LAB-27] Query Analyzer Manager for AWOS. 

First at all, select a System Under Test (SUT) configuration in the SUT configuration drop-down list.

Then, select the "Query Mode" and fill the required parameters values. (See the desciption of the LAB-27 transaction in the LAW Technical Framework Supplement for further details about the usage of the parameters).

Finally, hit the "Send Query" button. The Analyzer Simulator will send the query to the SUT.

Receive an AWOS from the Analyzer Manager SUT

As defined in the Laboratory Technical Framework Supplement for the Laboratory Analytical Workflow Domain (LAW), the Analyzer can receive a new AWOS or a cancelation on an existing AWOS, from the Analyzer Manager. This is described in the LAB-28 transaction.

To do so, retrieve the configuration of the Analyzer part of the simulator by going to Laboratory/Analyzer/Configuration.

If you want to see the awos received by the Analyzer, go to Laboratory/Analyzer/Browse data. The creator of the work orders contained in the message you send is set to SendingApplication_SendingFacility.

The OrderManager also implements the transactions of the LTW and LAW integration profiles used to exchange results. That means that the simulator is able to play the role of Order Filler, Order Result Tracker, Automation Manager, Analyzer and Analyzer Manager actors in the following transactions:

• LAB-3: Order result management (OF and ORT)
• LAB-5: Test result management (AM and OF)
• LAB-29: AWOS Status Change (Analyzer and Analyzer Manager)

The Order Manager  enables the user to create a DICOM worklist from an existing procedure (or order, in that case a procedure is created from the order and then a worklist can be generated from the scheduled procedure steps). This order can be one of the orders received from a system under test or created by the Order Filler functionality of the application. The user has also the possibility to create an new order if his/her purpose is only to test a modality. 

Create a DICOM Worklist

Go to Radiology/Order Filler/Create a DICOM worklist or Eye care/Order Filler/Create a DICOM worklist

Basically, worklists are created from the scheduled procedure steps (not cancelled nor complete) which are owned by the Order Filler part of the tool. Nevertheless, you may want to create a worklist for an order for which no procedure exists yet or create a new order from scratch.

• Use an existing order : Click on the "Schedule an order" button. Select one of the orders displayed in the table. You can add some search criteria for restraining the search.
• Create a new order for an existing encounter: After reaching the page to schedule a new order, click on the "Create a new order for an existing encounter" link. The list of encounters known by the application will be displayed, pick one. Then, you are asked to fill the newly created order. Use the randomly fill order button if you do not want to select all values one by one; if some of them are set, only the empty attributes are valued.

Once the order is selected and filled, the procedure is created, set the start/date time of the procedure. Hit the "Save requested procedure" button. Finally, for each step of the procedure, a button "Create a worklis for this step" is displayed, choose one and hit the button. You will be asked to fill out the Station AE Title, do so and hit the button "create the worklist", the worklist is created. Note that the procedure and protocol codes and descriptions are selected in behalf of the Universal Service Id attribute of the order. The matching is done thanks to the XML file available here. 

The worklist is created and you can download the result of the generation. An XML file and the DICOM object are both available for download. Note that the worklist is first created in an XML form that match the DTD defined by OFFIS and then converting to a DICOM object using the xml2dcm tool from the DICOM toolkit DCMTK developed by OFFIS.

The configuration of the DICOM part of the Order Filler is available under Radiology/Order Filler/Configuration or Eye care/Order Filler/Configuration.

View all DICOM Worklist entries

Go to Radiology/Order Filler/Data browser or Eye care/Order Filler/Data browser

This page gathers all the worklists which are available in the SCP. For each worklist, you will retrieve the link to download the DICOM object and the associated XML file. In the same way, the configuration of the SCP to query is displayed again.

Worklist query messages

We have put in place a little proxy as a front-end of our SCP. Our SCP is played by the DICOM Basic worklist management SCP (wlmscpfs) developed by OFFIS and available in the DCMTK toolkit. The given port is one of those the OrderManager is listening on. When you send your DICOM query to the given configuration, the OrderManager stores the data set part of the message in its database after some processing (extracts some informations stored beside the request) and forwards it to the DICOM SCP. When the SCP sends you the response, it is first received by the OrderManager which saves it and then forwards the response to your system. See below the sequence diagram for a better understanding of the workflow.

The DICOM messages intercepted by the OrderManager are all available under menu Radiology/Worklists/Worklist query messages. 

For each message, we have extracted the data set and its content is converted into an XML file using the dcm2xml tool from OFFIS's toolkit. This file is displayed in the application using an XSL transformation, the XSL file we have written is available here.

In the same way, for a given message you will find a table gathering all the other messages received within the same channel of the proxy. It appears that a new channel is openned for each new association.

Worklist query logs

The error output of wlmscpfs tool is parsed as text is appended and the results of the parsing is stored in the database. You can view these logs in the page Radiology/Worklists/Worklist query logs or Eye care/Worklists/Worklist query logs.

The Order Manager tool is able to act in transactions RAD-4 (procedure scheduled) and RAD-13 (procedure update) as both Order Filler and Image Manager (or Report Manager). 

• Radiology/Order Filler/[RAD-4/RAD-13] Scheduled/Update procedures: Send procedures to your Image/Report Manager using our Order Filler
• Radiology/Image Manager/Configuration gives you the connection information to send messages to our Image Manager.

SWF.b

From version 4.0.0, the Order Manager tool supports the SWF.b profile. It will be able to handle and validate the OMG messages your SUT sent to it. You can also ask the tool to use HL7v2.5.1 instead of HL7v2.3.1 when configuring the message to send to your SUT, to do so, tick the "Send HL7v2.5.1 messages ?" checkbox.

Order Filler sends procedure notifications

The application offers you two ways of creating procedures:

• Schedule a procedure for an order already created within the Order Filler. This can be useful if you want to test a workflow and the Order Filler actor is missing and thus replaced by the tool
• Schedule a procedure for an order you create from scratch. This feature may be useful if you only need to test the behaviour of your Image Manager.

In those two cases, the procedure information are retrieved from an XML file which is used to map the ordering codes with the procedure informations. By now, we create only one requested procedure per order. If when reading those files you notice that an ordering code and/or procedure code your system supports is not available, please provide us with those informations and we will append them in our configuration files.

Ordering Codes (SVS file): http://gazelle.ihe.net/RetrieveValueSet?id=1.3.6.1.4.1.21367.101.118

Procedure mapping: http://gazelle.ihe.net/examples/Bern2012-orderHierarchy.xml

Procedure scheduled

The first time you use the application to send a procedure scheduled message to your Image Manager, you must register your system under test into the application, that means, providing the application with your connection informations: IP address, port, receiving application/facility. To do so, go to the SUT Configurations menu and click on the "Create a configuration..." button.

Then, go to  Radiology/Order Filler/[RAD-4/RAD-13] Procedure Scheduled/Update and follow the instructions below.

1. Select your system under test in the drop-down list and verify the connection information. Also check on your system under test that no firewall rules prevent Gazelle servers from accessing your system.
2. Select "Procedure scheduled" as action to perform. The list of available orders should be displayed
3. You can restrain the search by using both the filters on columns and the research fields above the table. When you have found the order you want to use, click on the select link in the last column of the table.
4. The Requested Procedure is then created by the application and you only have to set the Scheduled Procedure step start date/time and eventually the modality type (if not specified in the mapping file)
5. Finally click on "Send message" and wait for the application to receive the acknowledgement from your system. As a last step, you can validate the conformance of the acknowledgement your system has sent against our HL7 message profile.

Procedure Update

According to the table gathering the required order control codes and order statuses (Table 4.13-1 in RAD TF volume 1), there are 4 actions that the Order Filler and the Image Manager must be able to support. Those actions are gathered in the "Action to perfom" list.

• Procedure Update: cancel order request
• Procedure Update: discontinue order request
• Procedure Update: change order request
• Procedure Update: order has been completed

For the two first ones, you only have to select a procedure and to hit the "Yes" button when the pop-up raises. For the two last ones, you will be asked to update the start date/time and then you can press the "Send message" button. Note that once a procedure is cancelled, discontinued or said as completed, it does not show up again in the list of available procedures.

Image Manager receives procedure notifications

The Image Manager actor acts as responder in the transactions RAD-4 and RAD-13. As a consequence, you will have to feed your system under test with the connection information of this part of the tool. As mentionned earlier in this page, you must be logged in to access those information.

Go to Radiology/Image Manager/Configuration

Once your system is configured to communicate with the tool, you can send it ORM^O01^ORM_O01 messages as defined for transactions RAD-4 and RAD-13. Note that, the Image Manager implemented in the Order Manager only plays a role of a message recipient. New procedure will be created, updated, cancelled... according to the message content but no other actions will be taken by this part of the tool.

If you want to see how the messages you have sent have been integrated by the tool, go to the section Radiology/Image Manager/Browse Data.

This page describes the Test Result Management part of the Order Manager. This part involved 

Analyzer (LAW)

Analyzer Manager (LAW)

Order Filler (LTW)

Order Result Tracker (LTW) 

Automation Manager (LTW)

HL7 validation

The simulator communicates with our HL7 validator based on message profiles developed at INRIA and HAPI validation. 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 HL7 messages menu (gathers all the messages received and sent by the simulator).

	Opens the pop-up containing the received and sent messages beside their validation results. The validation service is automatically called each time you hit this button. Consequently, the validation result you see is always the one matching the newest version of the message profile.
	The message has not been validated yet. Hitting this button leads to the same action as the previous icon (magnifying glass).
	The message has been successfully validated. Hitting this button leads to the same action as the previous ones.
	The message has been validated but the message contains errors. Hitting this button leads to the same action as the previous ones.
	Opens a pop-up asking you to which system under test you want to send this message again. The simulator is able to replay a message it has already sent. The messages which have been received by the simulator (as responder) cannot be send a second time.

The Order Manager tool integrates a feature which allows the user to send Modality Worklist Information Model C-Find queries to order fillers.

Register your SUT as a DICOM SCP

If you are already a user of the Order Manager tool, you may have registered your System Under Test as an Order Filler, giving its HL7 configuration. In order to send the DICOM queries to your SUT, the tool also needs some informations about your DICOM configuration.

Create a new configuration under SUT Configurations / DICOM SCP. You need to provide a name (to easily retrieve your configuration), the hostname or IP address, the port and the AE title used by your SUT. If you are logged in when creating the configuration, you will be asked if you want this configuration to remain private or if you want to share it with others.

The AE Title sent by the tool is Gazelle_OM. If your SUT accepts only some AE titles, do not forget to add this one.

Configure the message to be sent

Go to Radiology / Acquisition Modality / [RAD-5] Modality Worklist Query.

In the top part of the page, select the configuration of your SUT. Connection information will be displayed on the right hand of the sequence diagram, check they are still up-to-date.

Then, the page is divided into two parts, on the left hand you have a tree representation of the C-FIND message being sent and on the right hand you have a panel to append additional tags to the query.

Tree representation and value setting

Each leaf of the tree represents a DICOM attribute: name tag <VR> <value>

To set a value to a leaf, just click on "value" and enter the attribute value to send. Then press ENTER key or click on the green mark. If you want to remove a value, either edit the tag and delete its content, either right-click on it and select "Empty attribute" in the contextual menu.

Each branch of the tree represents a DICOM sequence attribute : name tag <VR>

Appending attributes

To append an attribute to the root of the query, use the panel located on the right hand of the page; either enter the tag (use hexa format, eg. 0x0101,0x1010) the hit the "Add" button either select its name in the drop-down menu and hit the "Add" button. The list contains the name attribute which can be found in a worklist. If one of the attribute is missing, add it using its tag. 

To append an attribute to a sequence, right-click on the sequence name and select "Add an item". Then process as described just below. 

To value a newly added attribute, proceed as described in the previous section.

Removing tags

Each attribute/sequence attribute can be removed from the tree. Right-click on the attribute to delete and select "Remove attribute".

Options

The technical framework defines to set of matching key attributes to be supported by the acquisition modality and/or importer actors. You can choose to highlight those attributes in the tree.

Below the tree, an "Options" panel is available. You can expand it by clicking on its header. Three choices are available:

• None: nothing is highlighted
• Keys for Query by Patient: the attributes listed in table 4.5-1 of the technical framework will be highlighted. There are the matching keys to be supported when querying a worklist for a particular patient.
• Keys for Broad Worklist Query: the attributes listed in table 4.5-2 of the technical framework will be highlighted. There are the matching keys to be supported when performing a query for a broad worklist.

Send message

Once the query is ready to be sent to your system, hit the "Execute" button.

View exchanged messages

A proxy catches all the messages sent and received by the tool. When the execution of the query is complete, the list of messages exchanged between your system under test and the Gazelle tool will be available.

Pre-connectathon testing for systems implementing the LTW (Laboratory Testing Workflow) integration profile, plus Radiology, Cardiology & Eye Care workflow profiles, are perfomed against a Gazelle simulator named OrderManager. In this context we test actors independently of each other, that means that we do not take care of the workflow.

• The OrderManager tool is here: https://gazelle.ihe.net/OrderManager/home.seam
• Pre-Connectathon tests using the Order Manager are documented here: http://gazelle.ihe.net/content/order-manager-tests
• We recommend you read the OrderManager user manual here: http://gazelle.ihe.net/content/order-manager">http://gazelle.ihe.net/content/order-manager

Configuring the tool

Before starting your tests, please set up your system on the tool and give the correct information to the simulator in order to enable it to access your system under test.  Note that this simulator emulates actors from various domain, consequently, before starting your tests, make sure to select the proper domain from the top-level menu, eg select the Laboratory domain.

Order Placers

Depending of the transaction in which it is involved, the Order Placer is either an HL7 initiator or an HL7 responder. Consequently, in order to be able to communicate with the simulator, you need to enter the configuration of your system under test (IP address, port, application, facility...) into the simulator, go to section entitled "SUT Configurations". In addition, you need to enter the configuration of the different actors emulates by the simulator and which the ones you will interact. Those pieces of information are available under the Configuration menu of each actor.

Order Fillers

Depending of the transaction in which it is involved, the Order Filler is either an HL7 initiator or an HL7 responder. Consequently, in order to be able to communicate with the simulator, you need to enter the configuration of your system under test (IP address, port, application, facility...) into the simulator, go to section entitled "SUT Configurations". In addition, you need to enter the configuration of the different actors emulates by the simulator and which the ones you will interact. Those pieces of information are available under the Configuration menu of each actor.

Image Managers

As an HL7 responder, the Image Manager must enter its configuration into the OrderManager simulator. Go to "SUT Configurations" section to do so.

Automation managers

Depending of the transaction in which it is involved, the Automation Manager is either an HL7 initiator or an HL7 responder. Consequently, in order to be able to communicate with the simulator, you need to enter the configuration of your system under test (IP address, port, application, facility...) into the simulator, go to section entitled "SUT Configurations". In addition, you need to enter the configuration of the different actors emulates by the simulator and which the ones you will interact. Those pieces of information are available under the Configuration menu of each actor.

Order result trackers

As an HL7 responder, the Order result tracker must enter its configuration into the OrderManager simulator. Go to "SUT Configurations" section to do so.

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

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

• Schematron-based validation
• Model-based validation

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

Access the External Validation Service Front-end

Introduction

This application has been developed with the purpose of aggregating in a same user interface, the access to all validation services developed for IHE. Services called are the following:

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

In the menu bar of the user interface, we have chosen to sort the validators by affinity domains, currently to differents affinity domains are available: IHE and epSOS.

Contents which can be validated using this tool are: HL7v2.x and HL7v3 messages, CDA documents, SAML assertions, ATNA audit messages, certificates, XD* messages, XDW documents and DICOM object.

Schematrons section allows the user to download the schematrons which are used to validate XML files. Those schematrons are sorted according the type of object they validate.

Important notice

Note that when using the EVS Client application, if you are NOT logged in, every document/message that you validate is stored in our database, referenced and available to everybody. If you do not want to have your documents/messages public, then you need to log in using the "CAS login", it uses your Gazelle's (EU-CAT) credentials.

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

Application overview

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

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

These validation services are available through a web service API so it can be integrated in your application. If you wish to validate messages occasionally you can use the Gazelle Validation Front-End called EVS Client which puts at your disposal a user interface to validate HL7 messages, CDA documents, XD* requests and so on.

Concerning HL7v2 validation: the application also gathers the HL7 conformance profiles and the HL7 tables (codes) which can be browsed by any user. For each conformance profile, you will find information about its issuer (actor, domain, transaction) and the message type and HL7 version. Each conformance profile can be bound to one or several HL7 tables which gather a list of allowed values for a given field of the message.

User interface

Browse validation requests

The User interface allows you to browse the validation requests received by the tool and the associated result. For each validation request, the tool keeps trace of the IP address of the caller. This is the way we choose to "protect" your work. That means that, using this IP address we can restrain the access to the data you have submitted (message content) and the results of those validations. The access rules are the following:

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

Browse HL7 message profiles

All the HL7 message profiles available are gathered in the tool. You can either select a profile by its full OID (if known) or put filters on the table columns. Each profile is viewable inline and can also be downloaded.

Browse HL7 resources

An HL7 resource is an XML file gathering several HL7 tables. An HL7 table is uniquely defined by an ID and contains the set of allowed values. Those tables are referenced in the message profiles and at validation time, the validation engine can check that the value of a given field of the submitted message comes from the set of allowed codes for this field. As for the message profiles, you can see those tables inline or download them

Browse HL7v3 validation service documentation

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

Web service API

Gazelle HL7v2.x validation service

The web service API of the tool offers two methods:

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

The definition of the web service API is available at https://gazelle.ihe.net/GazelleHL7v2Validator-ejb/gazelleHL7v2ValidationWSService/gazelleHL7v2ValidationWS?wsdl.

The validate() method has the following prototype:

public String validate(String, String, String) throws SOAPException;

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

As we also need the client side of this validation service, we have created some useful projects listed below.

• SOAPui project example
• Gazelle web service client API (version 1.19.0 and higher)

Note that this validation tool is also available through the simulators based on HL7v2.x (the messages sent and received by the simulator can be validated) and the EVSClient.

Gazelle HL7v3 validation service

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

Bug tracking

Error is human. We try to maintain the message profiles and HL7 tables doing our best but we may do mistakes. If you think there are errors in one/several of our message profiles, please report an issue in our bug tracking system with mention of the profie OID, error location, appropriate fix and reference to the documentation. 

Bug tracking URL is https://gazelle.ihe.net/jira/browse/HL7VAL