This guide introduce the usability of Test Management platform.
The following table summarizes the list of features in the Gazelle Test Management Tool.
|Feature||Bordeaux 2010||Pisa 2011||Chicago 2012||Bern 2012|
|Registration Process Management|
|Test Definition Management|
|Binding to Gazelle Master Model||x||x||x|
|Test Session Management|
|Test Update Notification||disabled||x|
|Mobile Test Grading for Monitors||x||?||x|
|Single Sign On||x||disabled||x|
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.
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. Read more…
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.
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…
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…
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…
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. Read more…
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 ?
Interactions 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.
Component for the declaration and the management of the simulators that Gazelle uses to perform the tests.
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.
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
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 useful in the case of scrutiny test. Read more…
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…
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 successful 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)
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.
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…
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.
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…
See more information there. The Thorough / Supportive testing mode is defined at registration time.
A definition of a test involving one or more IHE actors in one or more profile.
One instance of a test with specific test partners
During the Registration process, the Gazelle Test Management Application gathers information needed in order for an organization to participate in an upcoming testing session.
To complete registration for a testing session, an organization uses Gazelle to enter:
When this information is complete, may be asked to generate a contract in Gazelle for the testing session.
This “How to” details for these tasks follow in the pages below.
In Gazelle Test Management, an organization is the entity that is presenting test systems at the Connectathon.
IHE publishes Connectathon results per organization, thus, the organization name, address, and finanical contact you enter in gazelle is important.
A “User” has a login and password to access the applications of the Gazelle Test Bed. Gazelle Test Management is managing the users. Other applications like simulators, validators, EVS Client do not have user management but allow user authentication throught a CAS (Single Sign On) application.
A “Contact” is a person in your organization who will interact with us in preparation for a testing session :
A user may, or may not, be a contact
Users and Contacts belong to an Organization
There are two levels of users in Gazelle Test Management :
In Gazelle, a ‘system’
Gazelle Test Management can manages multiple testing session. A testing sessions may represent:
When a user logs in to Gazelle, the user is viewing information for a single testing session. Gazelle always “remembers” the last testing session a user was working in. A user may switch between testing sessions. How-to instructions are here.
A “user” is person with a login and password to access the Gazelle Test Management tool. A user in Gazelle is always linked to an organization. A user can only view/modify information for the organization he/she belongs to.
Creating a new user account
To create a new user, go to the home page of Gazelle Test Management and click on the link “Create an account”
New user then needs to fill out the form with valid information.
If the organization is already known in gazelle, select it from the “Organization Name” dropdown list; otherwise select “New company” as the “Organization Name” in order to create a new organization in Gazelle.
Upon form submission, an email is then sent to the user in order to confirm the registration.
When entering a new organization in that form the user that is created automatically gets the administration rights for the organization.
When selecting an existing organization in that form. The creation of the account is conditionned to the acceptance of one of the users with the admin role in that organization.
In that case the new user account is not activated until a user with the role vendor_admin in your organization activates the account.
For more information on user rights see the next section on user priviledges.
User priviledges in Gazelle
A user with ‘vendor’ privileges in Gazelle (the default), can manage the tests and configurations for the organization’s test systems.
A user with ‘vendor_admin’ priviledges in Gazelle, is able in addition to the roles of ‘vendor’ :
Managing organization’s user account as a “vendor_admin” user
Users with the vendor_admin role can manage the users in his/her organization from the menu : Gazelle menu Registration -> Manage users
You can use this form to activate or de-activate user accounts, or update email or password for a user.
This page describe how to register the participants to a Testing Session. Participants to the testing session are the person who will get a badge an will be able to enter the floor where the testing in taking place.
Registration of the participants to the Testing Session can only take place when the registration of the systems is over.
Only the users with the role “vendor_admin” can register participants to the testing session.
One accesses the participants registration page through the menu Registration -> Testing Session Participants
See the illustration below :
There are 3 means to register a participant to a testing session :
import from users
import from contacts
By selecting the button import from users, one can select the participants to add in the list of registered users for the organization.
By selecting the button import from contacts, one can select the participants to add in the list of contacts already declared in Gazelle Test Management tool. Contacts do not need to have a login.
When selecting the button add participants, the users can enter manually all the information about the participant to register.
The system registration page is accessed through the menu : Registration -> Manage Systems.
In that page you can :
Add a system : This will create a new system in the gazelle tool.
Add a system from an existing testing session : This will attach a system that is already registered to another testing session to the session currently selected. The feature is interesting to register systems both for a connectathon testing session and internet testing session at the same time. Note that when attaching a system from another session to the current session you will not be able to remove actors / profiles registered. If you want to add a system to the current session that is based on a system in a previous session but that does not implement the same list of actors and profiles, then the feature you want to use is the Import systems from another testing session.
Copy systems from another testing session : A click on that button will create a new system, initialising it with the information of the selected system. The name and the keyword of the system are appended with the string “_COPY” in order to distinguish the new system from the old one.
The Gazelle software system is used to generate a contract for IHE Connectathons that includes the systems to be tested and several contacts within your organization. If any of these are missing, the software will not let you generate a contract.
To generate a contract, the administrator for your organization (the person who created the Gazelle account) will select Registration -> Financial Summary from the web interface. Next figure shows common error messages that occur when generating a contract. The error messages in red are generated by Gazelle. The numbers in ( ) are pasted onto the screen capture and refer to notes below the figure.
The mailing address is missing for the company
This is for general correspondence with your company.
Select Registration -> Manage company information
Under Mailing address, add an address for your company. This is on the right half of the form. Select Click here to add a new address. If you already have entered an address but you were presented with the error message, you need the next step that associates the address as your company mailing address. This first step adds an address to our database, but does not make it your mailing address.
The address that you entered is presented in a table with the rightmost column an action column. If you have added a second address, you will see a table with two lines. To associate an address as your mailing address, click on the Select link in the appropriate row.
You will now see the address copied from the right part of the form to the left side of the form, including the country flag. Scroll down and select Save. That should get rid of error (1).
Missing address for Financial Contacts
This address is for the person in your organization responsible for processing our requests for payment.
Select Registration -> Manage company information
Scroll down to the Billing address section. Add an address on the right side of the form; Select Click here to add a new address.
You might already have an address for your company that is the same for thisperson. Great; skip down to iii.
If you don’t have an address registered for this financial contact or the address of the financial contact differs from the main address, add it now.
In the table of addresses on the right side of the form, under the Billing address section, click on the Select link in the appropriate row.
You will now see the address copied from the right part of the form to the left side of the form.
Scroll down and select the Save button.
Missing Technical Contacts
We need to verify that there are one or more staff members in your organization we can contact for testing and other technical details.
Select Registration -> Manage contacts
You will see a table of contact points in your organization. That table might be empty or already have members. You can add a contact person with the Add a contact button in the upper right corner. For this error (Missing Technical Contacts), make sure you select the checkbox for Technical.
If the Technical Contact was already listed in the table but is not indicated as a Technical Contact in the Professional functions column, edit the row for that person (right most column of the table, edit button). Select the checkbox for Technical and do not forget to hit Save.
We require at least one contact entered in the system for the generation of the contract. You are welcome to enter more technical contacts. This will be useful for organizations that have multiple systems, each with a separate technical contact.
If you are bringing one system and three engineers, please enter one candidate as your technical contact. That person would be able to answer most technical questions or delegate to someone else. Please do not enter a person who is merely going to contact your engineers and pass along the questions.
Missing Marketing Contacts
We need to verify that there are one or more staff members we can contact if we have marketing questions (is there a logo we can use in documentation? What is the exact name to use for your company?).
Refer to (3) above. Rather than selecting the checkbox for Technical, select the checkbox for Marketing/Commercial.
The same person can fill the roles for Billing, Technical and Marketing/Commercial. We split them out for those organizations that have separate duties.
Missing System Information
If there is missing system information, you have registered zero systems for testing. The purpose of the contract is to explicitly list what you will test and include a computation for fees. You will need to register the system or systems you wish to test and all profile/actor pairs to be tested.
Select Registration -> Manage systems
Enter one or more systems.
Make sure you save the systems.
Make sure you select the Profile/Actors tab and enter what you want to test. Check for missing dependencies (ATNA requires CT).
Fill in information if you plan to participate in a Showcase/Demonstration
Missing Domain Information
This means you have either entered zero systems, or you have entered systems but included no profile/actor pairs.
Refer back to (5) for details.
Many IHE Integration Profiles have dependencies defined in the documentation. One example is that an ATNA Secure Node is always required to implement the Time Client actor in the Consistent Time profile. When you enter registration information, there is a button available to you labeled Check for Missing Dependencies. Rather than automatically register you, the system gives you this button to let you check when you feel it is appropriate. A box will pop up, list the missing dependencies, and give you the option to click a link to add them on the spot.
When you return to the financial page, one section will list all of your registered systems. The grid will give the system name, domains tested and fee information. One column will also indicate if all dependencies have been resolved. A green icon indicates sufficient registration; a red icon means that a dependency needs to be satisfied.
You cannot generate a contract if there are dependencies to be resolved, so you need to return to the page for managing systems.
The rules defining dependencies are written in the Technical Frameworks. We transcribe those rules into Gazelle and might make mistakes. Please check carefully. We may have added a dependency that is not a requirement, or left one out. If we have omitted a dependency in our automated rules and you do not register, you are still responsible for those tests during the Connectathon.
The rules defining dependencies do not identify all combinations that you will find important. For example, the XDS.b profile requires the Document Source and Document Consumer to obtain a consistent patient identifier for an Affinity Domain but does not specify the mechanism. We support that with the PIX and PDQ profiles for Connectathon testing, but do not require that. Participants fail to register for PIX or PDQ and are then surprised to realize they do not have a mechanism to obtain the patient identifier in the Affinity Domain.
User preferences are mainly used by Test Management application to customize some views according to the user’s wishes. The main preferences you may want to update are
The number of results (rows) in table
Whether or not you want the diagram sequence of a test to be displayed on the Test Instance page. If not, you may save some space in the page, the one will be lighter to load.
User preferences can also be used to communicate some useful pieces of information to monitors and other connectathon participants, such as your photo, the languages you speak…
To configure your own preferences, you have first to be logged in. Then, on the top right corner of Test Management, hit the link with your user name and preferences (shown below).
This link leads you to your preferences management page. If you never change anything, the page may look something like this.
As you can see in the screen capture above, this page also enables you to change your password. Some fields have been recently added as
Skype account During the connectathon week, it can be useful to communicate using Skype. Such a field already exists for the system but a monitor for example, who does not own systems may want to “publish” his/her Skype name to speak with other monitors or participants.
Table Label During the connectathon week, you will sit at a table, the one will be localized by everybody thanks to a table label, typically A1, J10… When you sit the first day of the connectathon, fill this value so that other attendees will find you more easily.
Spoken languages The languages you are able to speak.
Hit the Edit button to update those fields. The following panel will be displayed.
When you hit the “plus” icon, a menu is displayed and you can pick up your language(s). If need, hit the “red cross” button in front of a language to remove it from the list. When finish, hit the “finish” button.
Do not forget to save your changes before leaving this page.
Gazelle Test Management can handle multiple testing session. There are testing sessions for multiple purposes.
Testing sessions are created by Gazelle Test Management administrators and can be configure for the purposes listed above.
In order to change testing session, you need to click on Switch at the top of the application :
Then select the session of your choice and you will be redirected to the home page.
Make sure that once you have completed that task, the top of the screen displays the name of the testing session that you have selected.
Note that since Gazelle Test Management version 3.5 we can select different color scheme to differentiate the sessions.
This section is about sharing samples in the Gazelle Test Management application. Samples can be shared for testing purpose. Connectathon and Pre-connectathon scrutiny tests requires participants to share sample. Gazelle allows the participants to share the sample, find the samples shared by partners and perform validation of samples using External Validation Services access.
Gazelle has a feature that allows to share samples among the participants.
We are calling “sample” any document or object that an application creates and is used by another application. Typically samples are :
Gazelle Test Management provides the users with the list of possible sample to share or consume based on the registration of actor/profiles pair.
Samples are accessed from the Connectathon Menu as shown on the following screen capture.
Example of the screen shown to the participants with the list of possible samples that can be shared for the systems selected.
Exemple of the screen shown to the participants with the list of samples that partners have provided for sharing and are of concerns to the selected systems.
Default configurations are assigned to the systems participating to a testing session. Once the Testing Session manager has assigned the configurations, participants can edit them and approve them.
This section describe how to edit and approve the configuations in Gazelle Test Management
The configurations are accessed through the menu “Configurations” as shown on the following screen capture
This page present the form to edit the HL7v2 configurations :
This page explains how to export the configuration information from Gazelle in a format the SUT can use to configure themselves.
There are 2 methods to get the configurations from test partners :
For the moment the only export format is CSV (Comma Separated Values) files generation.
When searching for peers configurations in Gazelle (menu Configurations-> All Configurations)
In the configurations page, when available, click on the link “URL for downloading configurations as CSV” :
This URL is accessing the parametric service for downloading configurations.
testingSessionId, configurationType and systemKeyword are parameters that can be set by accessing the URL directly :
North America : http://ihe.wustl.edu/gazelle-na/systemConfigurations.seam
System keyword is given if you use the GUI.
You can build the url that matches your need and have periodic query to the tool in order to feed your SUT with the most up to date information from the database.
Here are examples on how to use it :
The response is a CSV file like this one :
"Configuration Type", "Company", "System" , "Host" , "Actor" , "is secured", "is approved" , "comment" , "aeTitle", "sopClass","transferRole","port" ,"port proxy" ,"port secured" "DICOM SCU","AGFA","WS\_AGFA\_0","agfa13","IMG\_DOC\_CONSUMER","false","false","For optional DICOM Q/R","WS\_AGFA\_0","QR","SCU","","","" "DICOM SCU","AKGUN","PACS\_AKGUN\_2012","akgun10","PPSM","false","false","","PACS\_AKGUN\_2012","MPPS","SCU","","",""
The wsdl of the webservice to access the peers configuration parameter is located there :
The function of the SOAP webservice are richer than the REST as the it allows filtering on the actor concerned by the configuration. If this functionality is need/requested it will be added to the REST service as well. Note that we do not provide a sample client for that service.
This page explains how to access the OID values assigned to the systems participating to a testing session.
There are 3 methods for that purpose :
You can get the list of OIDs from the GUI : configurations –> “OIDs for current session”. On this page, you can do a search for a specific OID by filtering on the institution, the systemKeyword, the testing session, the integration profile, the actor, the option, and the label of the OID (homeCommunityId, organization OID, etc).
You can then use the link “Export as Excel file” to get an xls file containing all OIDs looking for.
You can generate directly a CSV file containing the oid, the label and the system keyword, by using REST webservice. The URL of the webservice is :
where arguments used are :
|Argument||Opt||Type||List of Possible Values|
|requirement||O||String||- sourceID OID
- sender device id.root OID
- repositoryUniqueID OID
- receiver device id.root OID
- patient ID assigning authority OID
- homeCommunityID OID
- organization OID
The wsdl of the webservice to access the OIDs of systems is located there :
The concerned methods are :
Note that here again the testingSessionId is a required argument, then you need to specify either the systemKeyword or the requirement, or the both of them.
The page Network Configuration Overview provides the users with the necessary information for the current testing session.
The information provided in that page is of 2 kind.
A blob where the administrator of the current testing session can provide to the participants a list of usefull an relevant information. This can be the networking parameters:
But it may also contain the information for the printer that is on site.
The page also provides a button to download a hosts file for the configuration of the systems that do not support DNS.
THe preferred method is for the participants to the testing session to use DNS in order to resolv hostnames. However we have encountered some systems in some past session that could not use DNS. So we have provided a mean to give the participants the access to a hosts file that can be installed on their SUT for name resolution.
Note that hosts file is NOT dynamic and the hosts file will have to be reloaded and reconfigured by the participants who have chosen not to use DNS after each test partner IP or name change.
Once the hosts file is downloaded it can be used to configure the SUT. Please refer to the operating system of the SUT for the set up of that file. Below is a list of pointer for 3 OSes
Testing before IHE Connectathons is a requirement and is achieved using software written by several different organizations
An index to all available tools for testing IHE profiles is provided at the following URL: http://wiki.ihe.net/index.php?title=IHE_Test_Tool_Information
Gazelle helps Connectathon participants manage the pre-connectathon test.
The following screen capture present the pre-connectathon test overview page. The page is accessed through the menu : Connectathon->Pre-Connectathon Testing.
It shows for a given vendor the list of systems registered by the vendor and for each system :
Click on the number in order to view the detailed list of test for each system.
There are 3 types of tests :
Gazelle Test Management users access the connectathon dashboard through the menu “Connectathon -> Connectathon “ as shown on the following screen capture.
The dashboard offer advance filtering capabilities and allows the user to have an overview of the testing progress from different angles.
A test instance can have the following statuses :
Running : this is the initial state of a test instance, once the user press on the “Start” button.
Paused : A test instance can be paused, and the restarted by the user.
Aborted : If the test instance was started per mistake, or is a duplicate of an existing test instance. Then one can abort it. Aborted test instances are not checked by monitors.
To be verified : Once a test instance is completed, the user can set it status to “to be verified”. Monitors work list contains test instances with that status.
Failed : Based on the evidences and the observation of the logs or the actual run of the test by vendors, a monitor may fail a test.
Verified : A monitor once convinced that the test is successful can mark it as verified
Partially verified : If a monitor thinks that a test is incomplete but that their is a chance that the vendor may fix the problem during the test session, then he/she can mark the test as partially verified.
Critical : Sometime toward the end of the connectathon, the project manager activates the “critical” status mode in Gazelle. Monitors verify then the Test instances with the status critical first.
Monitors work on test instances that have one of the 3 following status:
The output status are :
The aim of this page is to explain how the validation result displayed on a test instance page are retrieved from the EVSClient tool.
When a test instance is created, the page looks like:
There are different possibilities, like the next sequence diagram shows :
If we choose the first case, which is to add the permanent link from the proxy in a step message :
When it ‘is added :
The file is to be validated in Proxy to EVSClient, the test instance page looks like (use the refresh button is not) :
We can see in data column the last validation status from EVSClient.
We can see in Actions column :
If the user click on color button, then he is redirected towards the last result of validation.
If the user click on refresh button, then TM reloads the last validation status.
The button’s color evolves according to the result and the date is update.
The purpose of this chapter is to explain how to use gazelle test management in order to perform testing over the internet.
Using Gazelle Test Management for Internet testing provides testers with the following functionalities.
Internet testing using Gazelle Test Management is very similar to testing during the connectathon. The major difference between connectathon testing and Internet testing is an increased difficulty to achieve the communication between the different test partners.
Registration to an Gazelle Internet testing session is easy. There is no need to create a specific system for the internet testing session. One can import a system that is already registered within another testing session.
The purpose of this chapter is to explain how to use presets in Gazelle pages where they are available.
Presets are available for the following page :
The aim of the preset is to allow the user to save some filtering configuration and directly load the page with the filtering value set with the saved ones. The intent is double : speed up navigation for the user and reduce the load on the server by avoiding loading all the tests when only a few of them needs to be loaded.
Let’s take the PreConnectathon result page for instance, it is very similar to the Connectathon page.
You can see in red rectangle the new feature.
Select an organization, add a name to your preset and clic on save. Your preset is added !
Two fonctions are available:
You can save up to 4 presets. Once they are all created, you need to remove one before creating a new one.
Now you can click on PreConnectathon results page and the loaded page is your default page :
As a user with the role vendor_admin visit the page Registration -> Manage Users
For each system, there are a permanent link from gazelle to go directly to the summary of the system on the specified session. The link contains the description of the system, implemented IHE actors/profiles, system information summary, and the list of demonstrations that the system is registered for.
This permanent link has this form :
Gazelle Test Management release notes can be found on the JIRA pages of the project at the following URL :