--> Prior to performing ATNA tests, please read this page for guidelines that address frequently asked questions about testing expectations. <--

THIS PAGE APPLIES TO ATNA TESTING AT 2024 IHE CONNECTATHONs. 

• ATNA Requirements
• Gazelle Security Suite (GSS) tool for ATNA testing
• Security Policy (TLS & audit) for the 2022 IHE EU/NA Connectathon
• GSS: Digital Certificates for IHE Connectathons
• GSS: ATNA Questionnaire
• GSS: ATNA Logging Tests - TLS Syslog
• Questions about ATNA testing?
• Evaluation

ATNA Requirements

The ATNA requirements are in the IHE Technical Framework:

• ITI Technical Framework, Vol 1, Section 9 - ATNA Profile.
• ITI Technical Framework Vol 2, for the [ITI-19] and [ITI-20] transactions.
• The RESTful ATNA (Query and Feed) Trial Implementation Supplement specifies additional features.

NOTE:  The folloing options were retired in 2021 via CP-ITI-1247 and are no longer tested at IHE Connectathons:

• STX: TLS 1.0 Floor with AES Option
• STX: TLS 1.0 Floor using BCP195 Option

Gazelle Security Suite (GSS) tool for ATNA testing:

Tool-based testing of TLS (node authentication) and of the format and transport of your audit messages is consolidated in one tool - the Gazelle Security Suite (GSS).

• Link to the tool: http://gazelle.ihe.net/gss.  
• Instructions for use of the tool are contained in ATNA test descriptions - here.

Security Policy (TLS & audit) for the 2024 IHE EU/NA Connecthon

In order to ensure interoperability between systems doing interoperability (peer-to-peer) testing over TLS (e.g. XDS, XCA...) the Connectathon technical managers have selected a TLS version and ciphers to use for interoperability tests during Connectathon week.  (This is analagous to a hospital mandating similar requirements at a given deployment.)

TLS POLICY for [ITI-19]:

*** For the 2022 IHE Connectathon, interoperabily testing over TLS shall be done using:

• TLS 1.2
• cipher suite  - any one of:
  
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• A digital certificate, issued by the Gazelle Security Suite (GSS) tool.  See details below.

AUDIT MESSAGE POLICY for [ITI-20]:

Before 2020, an ATNA Audit Record Repository (ARR) was required to support receiving audit messages in both TLS syslog and UDP syslog.   That meant that all Secure Node/Applications could send their audit messaes to any ARR.

Now, all actors sending and receiving audit messages may choose to support TLS Syslog, UDP Syslog, and/or FHIR Feed for transport.   We expect that the Audit Record Repositories at the NA and EU Connectathons will provide good coverage of the options (TLS, UDP, FHIR), though some ARRs may support a subset.  In particular, the FHIR Feed Option in ITI-20 may have less support because it was new as of 2020.

Connectathon technical managers will not select one transport for all audit records exchanged during Connectathon.  Instead, Secure Node/Applications will choose ARRs for test partners that are compatible with the audit records they send in ITI-20.  Gazelle Test Management will show compatible partners for ITI-20 interoperability tests:  "ATNA_Logging_*.

==> GSS: Digital Certificates for IHE Connectathons

The Gazelle Security Suite (GSS) tool is the SINGLE PROVIDER OF DIGITIAL CERTIFICATES for IHE Connectathons.  

To obtain a digital certificate from the GSS tool for preparatory & Connectathon testing, follow the instructions in test 11100.   That test contains instructions that apply to an IHE Connectathon, whether face-to-face or online.

Some facts about the digital certificates for Connectathon testing:

1. The digital certificate you generate in GSS:
1. is from Certificate Authority (CA) with a key of 2048 length.  You must add the certificate for the new CA in your trust store.
2. will contain the fully-qualified domain name (FQDN) of your Connectathon test system.   When you use GSS to request the certificate, the tool will prompt you for this value.  The FQDN value(s) will be in the subjectAltName entry of your digital certificate.  (You may need to provide more than one FQDN when you generate your certificate, e.g., if you will use your system to test TLS connections outside of the Connectathon network, such as using the NIST XDS Tools in your local test lab.)
2. Test 11100 contains detailed instructions for generating your certificate, including how to get the fully-qualified domain name for your test system.
3. Item (1.b.) means that each system testing TLS transactions during Connectathon week will have a digital certificate that is compatible with the 'FQDN Validation Option' in ATNA.  Thus, TLS connections with test partners will work whether the client is performing FQDN validation, or not.  This is intentional.
4. The certificates are only for testing purposes and cannot be used outside of the IHE Connectathon context.

==> GSS: ATNA Questionnaire

Systems testing ATNA are required to complete the ATNA Questionnaire in the GSS tool, ideally prior to Connectathon week.  Embedded in the questionnaire are Audit Record tests and TLS tests customized for the profiles & actors you registered to test at Connectathon.

• Follow instructions in test 11106.

==> GSS: ATNA Logging Tests - ATX: TLS Syslog Option

Read the Technical Framework documentation; you are responsible for all requirements in Record Audit Event [ITI-20] transaction. We will not repeat the requirements here.

WHICH SCHEMA???:  The Record Audit Event [ITI-20] specifies use of the DICOM schema for audit messages sent using the ATX: TLS Syslog and ATX: UDP Syslog options.  The DICOM schema is found in DICOM Part 15, Section A.5.1.  

• The Gazelle Security Suite tool uses the DICOM schema with IHE modifications.  The schema used by the GSS tool is: https://gazelle.ihe.net/XSD/IHE/ATNA/dicom_ihe_current.xsd

We expect implementations to be compliant; we have tested audit messages using the DICOM schema at IHE Connectathons since 2016.

• The GSS tool will only provide validation against the DICOM schema. If you fail that test, it is our signal to you that your audit messages are not compliant with the latest DICOM schema.  See test 11116.
• We expect interoperability testing at the Connectathon to occur using audit records that are compliant with the DICOM schema.

SENDING AUDIT MESSAGES:   You can send your audit records to the GSS tool simulating an Audit Record Repository.  See test 11117.

Questions about ATNA Testing?

Contact the Technical Project Manager for the IT Infrastructure domain.  Refer to the Contact Us page.

Evaluation 

There is no specific evaluation for this test.  

Create a text file stating that you found and read the page. Upload that text file into Gazelle Test Management as the Log Return file for test 11099.

• Overview
• Prerequisites
• Gazelle Security Suite
• Instructions
• Evaluation

Overview of the test

This test contains instructions for obtaining a digital certificate for your test system that is registered for an IHE Connectathon.   You will obtain your digital certificate(s) from the Gazelle Security Suite tool.

Prerequisites for this test

First, please read the ATNA Testing Resources page before proceeding with this test.  That page contains important context for using the digital certificates for Connectathon-related tests. 

When you generate your digital certificate in Gazelle Security Suite, you will need to know two values:

(1) The hostname(s) for your test system:

• For IHE Connectathons face-to-face:  The hostname(s) are assigned to your test system by Gazelle Test Management.  (See https://gazelle.ihe.net/TM/ for the 2022 IHE Connectathon; the link may differ for other testing events). 
  To find the hostname for your test system, log into Gazelle Test Management, then select menu Preparation-->* Network Interfaces.
• For IHE Connectathons Online     This is the public hostname(s) for your test system.  For Connectathons Online, hostname and IP addresses are determined by the operator of the test system.   (The operator still shares its hostname(s) with other participants using Gazelle Test Management.)

(2) Domain Name:

• For IHE Connectathons face-to-face:  The domain name of the Connectathon network.  This information is published by the Technical Manager of each IHE Connectathon.  (E.g., for the IHE Connectathon 2022, the Domain Name is ihe-europe.net).
• For IHE Connectathons Online:  Your public domain name.

Location Gazelle Security Suite (GSS) tool

•  http://gazelle.ihe.net/gss

Log in to the GSS tool

When logging in to GSS, you will use your username & password from Gazelle Test Management for your Connectathon.  There are separate CAS systems for different instances of Gazelle Test Management, and you will have to take this into account when logging in to GSS:

• The European CAS is linked to Gazelle Test Management at http://gazelle.ihe.net/TM/ <---This will be used for the 2022 IHE EU/NA Connectathon
• The North American CAS is linked to Gazelle Test Management at https://gazelle.iheusa.org/gazelle-na/
• If you don't have an account, you can create a new on the Gazelle Test Management home page.

On the GSS home page (http://gazelle.ihe.net/gss) find the "Login" link at the upper right of the page.  

• Select either "European Authentication" or "North American Authentication"
• Enter the username and password from either Gazelle Test Management linked above.

Instructions - Obtain a Certificate

• In GSS, select menu PKI-->Request a certificate
• Complete the fields on page:
• Certificate type:  Choose "Client and Server" from dropdown list  (Required field)
• key size: 2048
• Country (C): (required)
• Organization (O):  Your organization name in Gazelle Test Management   (Required field)
• Common Name (CN):  The Keyword for your test system in Gazelle Test Management (eg EHR_MyMedicalCo)  (Required field)
• Title:  (optional)
• Given name: (optional)
• Surname: (optional)
• Organizational Unit: (optional)
• eMail:  (optiional) email of a technical contact making the request
• Subject Alternative Names: 
• You must enter at least one value in this field:   the fully-qualified domain name of your test system.
• For a face-to-face Connectathon, this is a combination of the hostname of your test system and the domain name. (See the Prerequisites section above)
• E.g., for Connectathon network, the hostname of your system might be acme0, and the domain name might be ihe-test.net.  So, an example of a fully-qualified domain name entered in this field for a digital certificate is acme0.ihe-test.net
• This value may contain additional fully-qualified domain name(s) for your test system when it is operating outside of a face-to-face Connectathon, e.g. when you are testing with the NIST XDS Tools in your home test lab, or if you are participating in an online Connectathon.
• If you have more than one hostname, multiple values are separated by a comma.
• Click the "Request" button.
• You will then be taken to a page listing all requested certificates.  Find yours on the top of the list, or use the filters at the top.
• In the "Action" column, click the "View Certificate" (sun) icon.  Your certificate details are displayed.  Use the "Download" menu to download your certificate and/or the Keystore.
  

It is also possible to find your certificate using the menu:

• Select menu PKI-->List certificates
• In the "Requester" column, filter the list by entering your username at the top of the column (the username you used to log in to GSS)
• Use the icon in the "Action" column to find and download your certificate, as described above.

You are now ready to use this certificate for performing:

• authentication tests with the Gazelle Security Suite tool
• interoperability (peer-to-peer) tests with your Connectathon partners

Evaluation 

There is no specific evaluation for this test.  

Create a text file stating that you have requested & received your certificate(s). Upload that text file into Gazelle Test Management as the Log Return file for test 11100.

In subsequent tests (eg 11109 Authentication test), you will verify the proper operation of your test system with your digital certificate.

• Overview
• Prerequisites
• Gazelle Security Suite
• Instructions
• Evaluation

Overview of the test

In this test you complete a form which collects information that will help us evaluate the Audit Logging and Node Authentication (ATNA) capabilities of your test system.

The contents of your ATNA Questionnaire are customized based on the the profiles and actors that you have registered in Gazelle Test Management for a given testing event (e.g. an IHE Connectathon).  Depending on which profiles/actors you have registered for, the ATNA Questionnaire will ask you to validate audit messages for transactions you support, and you will be asked to demonstrate successful TLS connections for the transports you support (eg DICOM, MLLP, HTTP).

Prerequisites for this test

Before you can generate your on-line ATNA questionnaire:

• You must have a test system registered in Gazelle Test Management for an upcoming testing event.
• (See https://gazelle.ihe.net/TM/ for the 2022 IHE Connectathon; the link may differ for other testing events).
• Your test system must be registered to test an ATNA actor, e.g., Secure Node, Secure Application, Audit Record Repository.
• Your test system must have a status of "Completed" in Gazelle Test Management.
• This is because the content of the Questionnaire is build based on the profiles & actors you support. We want to know that your registration is complete.
• To check this, log in to Gazelle Test Management.
• Select menu Registration.
• On the System summary tab for your test system, you must set your Registration Status to "Completed" before you start your ATNA Questionnaire.

Location of the ATNA Tools:  Gazelle Security Suite (GSS)

•  http://gazelle.ihe.net/gss

Log in to the GSS tool

When logging in to GSS, you will use your username & password from Gazelle Test Management for your testing event.  There are separate CAS systems for different instances of Gazelle Test Management, and you will have to take this into account when logging in to GSS:

• The European CAS is linked to Gazelle Test Management at http://gazelle.ihe.net/TM/ <---This will be used for the 2022 IHE EU/NA Connectathon
• The North American CAS is linked to Gazelle Test Management at https://gazelle.iheusa.org/gazelle-na/
• If you don't have an account, you can create a new on the Gazelle Test Management home page.

On the GSS home page (http://gazelle.ihe.net/gss) find the "Login" link at the upper right of the page.  

• Select either "European Authentication" or "North American Authentication"
• Enter the username and password from either Gazelle Test Management linked above.

Instructions

1. In GSS, select menu Audit Trail --> ATNA Questionnaires

2. First, search for any existing questionnaires for your organization. Use the filters at the top of the page to search based on various criteria.  You will only be able to access the questionnaires created for your organization's test systems.  Admins and monitors can access all of them.

 3. You can use the icons in the right 'Actions' column to:

• View the content of the questionnaire
• Edit it
• Delete it (administrators only)
• Review it (monitors only)

4. If no questionnaire is available for your test system, you need to create a new one.  

• Click on the "New ATNA Questionnaire" button
• From the dropdown list, select the name of your test system.   Note: If your system doesn't appear...
• ...is your test system registered with status of "Completed"?
• ...are you registered for ATNA Secure Node or Secure Application?
• ...is the testing session closed (ie is the connectathon over)?
• Next, click the "Back to list" button.  Use the filter at the top to find your questionnaire in the list.  Use the "Edit" icon in the "Action" column to begin.

5. Complete the questionnaire.  You are now in the ATNA Questionnaire Editor.

• In the System details, identify the ATNA actor you support.  Choose either "Secure Node (SN)" or "Secure Application (SA)"
• Complete the "Inbound network communications" tab
• Complete the "Outbound network communications" tab
• Complete the "Authentication process for local users" tab
• Complete the "Audit messages" tab.  This tab is used with test 11116.
• Secure Nodes only:  Complete the "Non network means for accessing PHI" tab 
• Complete the "TLS Tests" tab.  This tab is used with test 11109. 

6.  Mark your questionnaire "Ready for review"

• When all tabs in the questionnaire are complete, set the Questionnaire's status to "Ready for review" in the "Questionnaire details" section.  This is a signal that you have completed your work; we do not want to have monitors evaluating incomplete questionnairs.

Evaluation

Depending on the testing event, the results of this test may be reviewed in advance.  More typically, it will be reviewed and graded by a Monitor during the test event itself (e.g. during Connectathon week).

Note:  You cannot get connectathon credit (i.e. a "Pass") for your ATNA Secure Node/Application without completing and submitting your questionnaire.

• Prerequisites
• Overview
• Gazelle Security Suite
• Instructions for clients
• Instructions for servers
• Evaluation

Prerequisites for this test

(1) Read the ATNA Testing Resources page before proceeding with this test.

(2) To perform this test, your digital certificate must be set up on your system (server and/or client).  Follow the instructions in test 11000 to obtain digital certificate(s) for your test system(s).

(3) You should create your ATNA Questionnaire (test 11106) prior to running this test.  

• The ATNA Questionnaire has a "TLS Tests" tab that identifies the inbound /outbound communications you support.  
• That tab determines which of the "Server" and "Client" tests that you must run below.  
• You will also record your successful results on that tab.

Overview of the test

In this test, you will use the Gazelle Security Suite (GSS) tool (https://gazelle.ihe.net/gss) to verify that you are able to communicate with TLS clients and servers using digital certificates.

The GSS tool contains multiple client and server simulators that check:

• transport over TLS v1.2, including protocol (DICOM, HL7/MLLP, HTTPS/WS, or syslog)
• cipher suite (TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, and more....),
• certificate authentication
• Digital certificates for pre-Connectathon & Connectathon testing are generated by GSS.  See test 11100.

The TLS simulators available in the GSS tool are listed in Column 1 in the following table, along with notes on which you should use for this test:

Location Gazelle Security Suite (GSS) tool:

•  http://gazelle.ihe.net/gss

Log in to the GSS tool

When logging in to GSS, you will use your username & password from Gazelle Test Management for your testing event.  There are separate CAS systems for different instances of Gazelle Test Management, and you will have to take this into account when logging in to GSS:

• The European CAS is linked to Gazelle Test Management at http://gazelle.ihe.net/TM/ <---This will be used for the 2022 IHE EU/NA Connectathon
• The North American CAS is linked to Gazelle Test Management at https://gazelle.iheusa.org/gazelle-na/
• If you don't have an account, you can create a new on the Gazelle Test Management home page.

On the GSS home page (http://gazelle.ihe.net/gss) find the "Login" link at the upper right of the page.  

• Select either "European Authentication" or "North American Authentication"
• Enter the username and password from either Gazelle Test Management linked above.

Instructions for outbound transactions (Client side is tested)

If your test system (SUT) does not act as a client (i.e., does not initiate any transactions), then skip this portion of the test and only test the Server side below).

If your SUT acts as a client, you must be able to access to TLS server's public IP. You have to test your client by connecting to Server Simulators in the Gazelle Security Suite tool.

1. On the home page for the Gazelle Security Suite, select menu TLS/SSL-->Simulators-->Servers to find the list of server simulators.  There are servers for different protocls (DICOM, HL7...) and for different ATNA options (e.g., TLS 1.2 Floor...).

• You will test only the protocols you support -- those listed on the "TLS Tests" tab of your ATNA questionnaire.

2. Configure your client to connect to the test TLS server.

3. Check that the server is started before trying to connect to it. Click on the link for the server you want and look for status "Running"

4. In your SUT, perform a connection (eg send a query) to the test server. The TLS connection is valid, but at transaction level you will get invalid replies because we are only checking for the TLS connection.

5. You should then get a time-stamped entry in the results list at the bottom of the page.   Blue dot means OK, red NOT OK.

5. For each successful connection, view the result with the icon in the "Action" column.  Copy the Permanent link (URL) to the result into your ATNA Questionnaire, on the "TLS Tests" tab The link must be formatted like https://.../connection.seam?id=...

6. Repeat these steps for each supported protocol (HL7v2 , DICOM, Syslog server ...) : e.g., if your system has no DICOM capabilities, you can skip that portion of the test.

Instructions for inbound transactions (Server side is tested)

If your test system (SUT) does not act as a server (i.e., does not respond to any transactions initiated by others), then skip this portion of the test and only perform the Client test above).

If your SUT acts as a server (i.e. a responder to IHE transactions), your server must be accessible from the outside so that the GSS tool, as a client simulator, can connect to your SUT. 

1. On the home page for the Gazelle Security Suite, select menu TLS/SSL-->Simulators-->Clients to find the list of client simulators. 

2. In the "Start Connection" section of the page, you will have to specify, for each supported protocol :

• Client type : protocol supported (HL7, DICOM, WS, SYSLOG, or RAW)
• You will test only the protocols you support -- those listed on the "TLS Tests" tab of your ATNA questionnaire.
• Target host : public IP of your server
• Target port : public port of your server

3. Then click on "Start client".

4. You should then get a time-stamped entry in the results list.   Blue means OK, red NOT OK.

5. For each successful connection, view the result at the bottom of the page using the icon in the "Actions" column.  Copy the Permanent Link (URL) to the result into your ATNA Questionnaire, on the "TLS Tests" tab. The link must be formatted like https://.../connection.seam?id=...

6. Repeat these steps for each supported protocol (HL7v2, DICOM, Syslog client, ...) : e.g., if your system has no DICOM capabilities, you can skip that portion of the test.

Evaluation 

Depending on the testing event, the results of this test may be reviewed in advance.  More typically, it will be reviewed and graded by a Monitor during the test event itself (e.g. during Connectathon week).

The tool reports success or failure for each test you perform.  Your test system must demonstrate successful TLS handshake for each inbound and outbound protocol you support.

If you are performing this test in preparation for an IHE Connectathon, a Connectathon monitor will verify your results as follows. The monitor will:

1. Access the TLS tests tab in the ATNA Questionnaire.  (The SUT only performs tests for the protocols it supports, and skips the ones not supported.)
2. For each "SERVER" tested side :
   • The test result must be PASSED.
   • During a Connectathon, these items can also be verified:
   • the SUT host must be the IP specified in the configuration of the system.
   • the SUT port must be the one specified in the configuration of the system for the protocol.
3. For each "CLIENT" tested side :
   • The connection must succeed (blue dot).
   • During a Connectathon, this item can also be verified:
   • the host in the SUT address must be the IP specified in the configuration of the system. The port is not verified for outbound transactions.
4. During the Connectathon, the monitor may choose to ask the vendor to re-run a test if the results raise questions about the system's support of TLS.

• Overview
• Prerequisites
• Gazelle Security Suite
• Instructions
• Evaluation

Overview of the test

*** If your ATNA Secure Node/Secure Application is only a client (ie it only initiates transactions), then this test case is not applicable for you.  Skip it. ***

This test exercises several error cases.  You will use the TLS Tool in the Gazelle Security Suite as a simulated client, trying to connect to a Secure Node (SN) or Secure Application (SA) acting as a server.

Prerequisite for this test

Perform test 11109 Authentication Test before running this 'error cases' test.

Location of the ATNA Tools:  Gazelle Security Suite

•  http://gazelle.ihe.net/gss

Log in to the GSS tool

When logging in to GSS, you will use your username & password from Gazelle Test Management for your testing event.  There are separate CAS systems for different instances of Gazelle Test Management, and you will have to take this into account when logging in to GSS:

• The European CAS is linked to Gazelle Test Management at http://gazelle.ihe.net/TM/ <---This will be used for the 2022 IHE Connectathon
• The North American CAS is linked to Gazelle Test Management at https://gazelle.iheusa.org/gazelle-na/
• If you don't have an account, you can create a new on the Gazelle Test Management home page.

On the GSS home page (http://gazelle.ihe.net/gss) find the "Login" link at the upper right of the page.  

• Select either "European Authentication" or "North American Authentication"
• Enter the username and password from either Gazelle Test Management linked above.

Instructions

1. Select menu TLS/SSL-->Testing-->Test Cases
2. Run each of the error test cases listed:
1. IHE_ErrorCase_Corrupted
2. IHE_ErrorCase_Expired
3. IHE_ErrorCase_Revoked
4. IHE_ErrorCase-Self-Signed
5. IHE_ErrorCase_Unknown
6. IHE_ErrorCase_Without_Authentication
7. IHE_ErrorCase_Wrong_Key
3. Once you are on the 'Run a test' page, use the 'Client type' dropdown list to select the transport supported on your server (HL7v2, DICOM, HL7, DICOM_ECHO, WEBSERVICE, SYSLOG, or RAW)
4. Input the host / IP address and port of your system and click on 'Run'.
5. If you implement several transports as a server, you should mix message types over those error test cases in order to have at least one implemented protocol covered by one step.   It is not necessary to run each of the test cases for each transport.
6. After each test case, find your result in the list of Test Executions.
7. Capture the permanent links to your PASSED results.  Copy/paste the links into Gazelle Test Management as your results for test 11110.

Evaluation

Depending on the testing event, the results of this test may be reviewed in advance.  More typically, it will be reviewed and graded by a Monitor during the test event itself (e.g. during Connectathon week).

Each error case must have a result of 'PASSED'. 

Each transport type (HL7v2, DICOM, HL7, DICOM_ECHO, WEBSERVICE, SYSLOG, or RAW) implemented by your system as a server must have been tested at least one time in the list of error cases.

If you are performing this test in preparation for a Connectathon, a Connectathon monitor will verify your results pasted into each test step.

• Overview
• Gazelle Security Suite
• Instructions
• Evaluation

Overview of the test

This test applies to a Secure Node/Application that supports the ATX: TLS Syslog or ATX: TLS UDP Option.

In this test, a Secure Node or Secure Application tests audit messages it sends.  

• We use the Gazelle Security Suite (GSS) tool to test the content of the audit message against the schema and against requirements documented in the IHE Technical Framework for some transactions.  
• In this test, we do not test the transport of the audit message (TLS or UDP).

The Gazelle Security Suite tool provides the ability to validate audit messages against the DICOM schema and the audit message definitions for many transactions in IHE Technical Frameworks.  (We are not longer testing the RFC 3881 schema; the ATNA profile requires support for the DICOM schema for syslog audit messages sent via ITI-20.)

Location of the ATNA Tools:  Gazelle Security Suite

•  http://gazelle.ihe.net/gss

Log in to the GSS tool

When logging in to GSS, you will use your username & password from Gazelle Test Management for your testing event.  There are separate CAS systems for different instances of Gazelle Test Management, and you will have to take this into account when logging in to GSS:

• The European CAS is linked to Gazelle Test Management at http://gazelle.ihe.net/TM/ <---This will be used for the 2022 IHE Connectathon
• The North American CAS is linked to Gazelle Test Management at https://gazelle.iheusa.org/gazelle-na/
• If you don't have an account, you can create a new on the Gazelle Test Management home page.

On the GSS home page (http://gazelle.ihe.net/gss) find the "Login" link at the upper right of the page.  

• Select either "European Authentication" or "North American Authentication"
• Enter the username and password from either Gazelle Test Management linked above.

Instructions

You may perform this test directly in the ATNA Questionnaire **or** you may use the Gazelle EVSClient tool.  If you are preparing for an IHE Connectathon, you should use the instructions below for the ATNA Questionnaire.

---->Instructions for checking audit messages using the ATNA Questionnaire:

1. Create a new ATNA Questionnaire for your test system using the instructions for test 11106.
2. Find the Audit Messages tab in the questionnaire.  That tab contains "Instructions" and enables you to upload and validate audit messages directly on that tab.   
3. You should validate all messages that you have marked "Implemented".
4. When you are done, find the Permanent Link to the your ATNA Questionnaire.  Copy/paste that link into the chat window in Gazelle Test Management for test 11116.  

---->Instructions for checking audit messages using the EVSClient tool:

1. In the Gazelle EVSClient, select menu IHE-->Audit messages-->Validate
2. Select the Add button, and upload the XML file for your audit message
3. From the Model based validation dropdown list, select the entry that matches your audit message. (Note that additional validations will be added over time.)
4. Select the Validate button.  
5. You should validate all audit messages associated with functionality & transactions supported by your test system.
6. In the Validation Results displayed, find the Permanent Link to the results.  Copy/paste the link(s) into the chat window in Gazelle Test Management for 11116.

Evaluation

Depending on the testing event, the results of this test may be reviewed in advance.  More typically, it will be reviewed and graded by a Monitor during the test event itself (e.g. during Connectathon week).

The tool reports the results of the validation of your messages.  We are looking for PASSED results.

• Overview
• Gazelle Security Suite
• Instructions
• Evaluation
• Tips

Overview of the test

In this test, a client sends audit records or event reports using transaction [ITI-20] Record Audit Event to the Syslog Collector tool acting as an Audit Record Repository or Event Repository.   The Syslog Collector is one of the tools embedded in the Gazelle Security Suite.  

This test is performed by an ATNA Secure Node, Secure Application or Audit Record Forwarder.  It is also performed by a SOLE Event Reporter.

Note that this test checks the transport of audit messages.  The content of your audit message is verified in a different test.   

Location of the ATNA Tools:  Gazelle Security Suite (GSS)

•  http://gazelle.ihe.net/gss

Log in to the GSS tool

When logging in to GSS, you will use your username & password from Gazelle Test Management for your testing event.  There are separate CAS systems for different instances of Gazelle Test Management, and you will have to take this into account when logging in to GSS:

• The European CAS is linked to Gazelle Test Management at http://gazelle.ihe.net/TM/ <---This will be used for the 2022 IHE Connectathon
• The North American CAS is linked to Gazelle Test Management at https://gazelle.iheusa.org/gazelle-na/
• If you don't have an account, you can create a new on the Gazelle Test Management home page.

On the GSS home page (http://gazelle.ihe.net/gss) find the "Login" link at the upper right of the page.  

• Select either "European Authentication" or "North American Authentication"
• Enter the username and password from either Gazelle Test Management linked above.

Instructions

• Access the Syslog Collector in GSS under menu Audit Trail --> Syslog Collector.  This page displays the tool's IP address and UPD and TCP-TLS ports.
• Configure your application to send your audit messages (event reports) to the Syslog Collector.
• Then trigger any event that initiate an ITI-20 transaction. This event may be an IHE transaction or other system activity (eg system start/stop or one of the SOLE events). Your system should finally send the message to the Syslog Collector.
• IMPORTANT NOTE:  The Syslog Collector tool is a free, shared resource. It is intended for intended for brief, intermittent use.  Developers SHOULD NOT configure their system to send syslog messages to the tool on a long-term basis.  Flooding the tool with audit messages can make it unavailble for use by others.

Evaluation

You must check that your audit message has been received by the Syslog Collector and that the protocol SYSLOG is correctly implemented.

• Go to Gazelle Security Suite, on page Audit Trail > Syslog Collector.
• Filter the list of received messages by the host or the IP of the sender, and find the message you sent according to the timestamps.
• Click on the magnifying glass to display the message details.
• If the protocol is UDP or TLS, if there is a message, a message content, no errors and RFC5424 parsing succeeeded, then the test is successful.  There is an example screenshot below.
• Copy the URL to your successful result and paste it into your local Gazelle Test Management as the Log Return file for test 11117.  
• Do not forget to stop sending audit-messages to the Syslog Collector once you’ve finished the test. If your system sends a large amount of messages, administrators of the tool may decide to block all your incoming transactions to prevent spam.

Tips

TCP Syslog is using the same framing requirement as TLS Syslog. You can first use the TCP port of Syslog Collector to debug your implementation. Keep in mind that the IHE ATNA Profile expects at least UDP or TLS for actors that produce SYSLOG messages.

.

THIS TEST IS UNDER CONSTRUCTION AND NOT YET AVAILABLE...

Overview of the test

This test applies to a Secure Node/Application that supports the ATX: FHIR Feed Option.

The RESTful ATNA TI Supplement, Section 3.20.4.2.2.1, defines a mapping between DICOM Audit Messages and FHIR AuditEvent Resources. Implementers should be creating their AuditEvent Resources according to the defined mappings, and expect that they will be examined according those mappings at IHE Connecthons.

• In test EVS_FHIR_Resource_Validation, a Secure Node or Secure Applicationis  asked to use the Gazelle EVSClient tool to test the content of the AuditEvent Resource against the baseline FHIR Requirements.
• In this AuditEventResource check test:   Gazelle tools will be enhanced to provide additional validation of AuditResource based on constraints in [ITI-20]. The RESTful ATNA TI Supplement, Section 3.20.4.2.2.1.That mapping will enable Gazelle tooling to verify specifics of the IHE-defined audit records that are sent as FHIR AuditEvent Resources.  
  

Instructions

---->Instructions for checking additional constraints on AuditEvent Resources (mapping defifned in ITI TF-2b: 3.20.4.2.2.1):

1. Instructions TBD when tool update is complete.

Evaluation

Depending on the testing event, the results of this test may be reviewed in advance.  More typically, it will be reviewed and graded by a Monitor during the test event itself (e.g. during Connectathon week).

The tool reports the results of the validation of your Resources.  We are looking for PASSED results.

Image Displays some profiles are required to be able to calibrate a monitor according to the the DICOM Grayscale Standard Display Function (GSDF):

• CPI Image Display
• MAMMO Image Display
• DBT Image Display
• SMI Image Display

Connectathon-related Instructions

Ideally, the monitor calibration would be done during the Connectathon; however, we recognize that there are costs associated with shipping a monitor to the Connectathon.

(1) If you are testing an Image Display the CPI profile but not MAMMO, DBT, or SMI, as an alternative to shipping a monitor to the Connectathon you may:

• Perform the calibration in your home lab as described in test DICOMScope_ImageDisplay.
• Record a video of the calibration task as performed in your lab
• Bring the recording to Connectathon as evidence for this test in order to convince the Connectathon monitor that it was performed correctly. Then, you will not need to perform calibration on-site during the Connectathon.
• If you do not perform/record calibration in advance of Connectathon, you will be required to perform it on-site at Connectathon (with diagnostic-quality monitor and photometer provided by you) as described in (2) below.

(2) If you are an Image Display actor in the MAMMO, SMI or DBT profile:

• Perform calibration as described in (1) above.  You are highly encouraged to do it in advance, as described.  Otherwise, you will have to do that task during Connectathon week.
• Also, plan to bring a diagnostic-quality monitor and a photometer to the Connectathon. The test managers do not provide a photometer on-site. For these profiles, you must bring a diagnostic-quality monitor to Connectathon in order to perform the required display tests with your modality partner's images.

Evaluation

There is no evaluation for this informational 'test'. You will share you calibration results in the DICOMScope test.

Introduction

Image Displays some profiles are required to be able to calibrate a monitor according to the the DICOM Grayscale Standard Display Function (GSDF):

• CPI Image Display
• MAMMO Image Display
• DBT Image Display
• SMI Image Display

We use software and test plans developed by OFFIS to test these actors.

Hardware Instructions for Image Displays

Please refer to test Hardware_Rqmts_ImageDisplay.

Instructions

1. Install the DICOMScope software available here: https://dicom.offis.de/dscope.php.en   See also https://dicom.offis.de/download/dscope/dscope364/
2. Access imgdisplay_testplan.doc and gsdf_lum.xls on Google Drive in: IHE Documents > Connectathon > tools > RAD-CPI-DICOMScope > CPI_Tests_2004_Release > documents
3. Access imgdisplay_gsdf.zip for test cases referenced in the Image Display test plan in: IHE Documents > Connectathon > tools > RAD-CPI-DICOMScope > CPI_Tests_2004_Release
4. Follow the instructions in Section 2.2 of the "Test Plan for Image Displays" document.

Evaluation

Please upload the completed gsdf_lum.xls file produced in the DICOMScope test procedure into Gazelle Test Management as the results for this test.

Introduction

Actors in several profiles are required to implement the [RAD-23] “Print Request with Presentation LUT” transaction as an SCU:

• CPI Print Composer
• MAMMO Print Composer
• DBT Print Domposer

We use software and test plans developed by OFFIS to test these actors.

Instructions

1. Install the DICOMScope software available here: https://dicom.offis.de/dscope.php.en See also https://dicom.offis.de/download/dscope/dscope364/
2. Access printscu_testplan.doc from Google Drive in: IHE Documents > Connectathon > tools > RAD-CPI-DICOMScope > CPI_Tests_2004_Release > documents
3. Follow the instructions in Section 2 of the "Test Plan for Print Composers" document.

Evaluation

Capture and submit your results:

1. Section 2.3 of the "Test Plan for Print Composers" describes log files created during the test procedure.  When you have successfully completed the print jobs described, caputure the log files and upload them into Gazelle Test Management as results for this pre-Connectathon test.
2. Change the status of the test to Verified by vendor

Introduction

Actors in several profiles are required to implement the [RAD-23] “Print Request with Presentation LUT” transaction as an SCP:

• CPI Print Server
• MAMMO Print Server
• DBT Print Server

We use test plans developed by OFFIS to test these actors.  The goal of the Print calibration tests is to demonstrate that printed output conforms to the GSDF. 

Instructions

1. Access printscp_testplan.doc and gsdf_od.xls on Google Drive in: IHE Documents > Connectathon > tools > RAD-CPI-DICOMScope > CPI_Tests_2004_Release > documents
2. Access printscp_testcases.zip for test cases referenced in the test plan.  See Google Drive in: IHE Documents > Connectathon > tools > RAD-CPI-DICOMScope > CPI_Tests_2004_Release
3. Follow the instructions in Section 2 of the "Test Plan for Print Servers" document.

Evaluation

Capture and submit your results:

1. Upload the completed gsdf_od.xls file into Gazelle Test Management as results for this pre-Connectathon test.
2. Change the status of the test to Verified by vendor

This is an index of Do This First  and Read This First tests that apply to testing across multiple domains

This is an index of Do This First  and Read This First tests defined for profiles in the IHE IT Infrastructure (ITI) domain.

This is an index of Do This First and Read This First tests defined for profiles in the IHE Patient Care Coordination (PCC) domain.

This is an index of Do This First tests defined for profiles in the IHE Radiology (RAD) domain.

This test concerns the POCDM actor of the LPOCT profile. You will need to validate with EVSClient tool the IHE conformance of your HL7 messages.

Instructions

As your system implements the  POCDM   actor, you will need to test the HL7 messages used in the LAB-32 transaction : "Accepted Observation Set".
Your system must be able to send HL7 messages (to the Oder Filler actor) of types :

• ORU^R30^ORU_R30, for the LAB-32  transaction
• ORU^R31^ORU_R30 , for the LAB-32  transaction

To test the IHE conformance of your HL7 messages, go to the EVSCLient tool at this location : EVSClient
If it is your first time with this tool, please read the user manual : EVSClient User Manual
    
In the EVSClient tool, go to the HL7 menu entry and choose "HL7v2" then click on "Message Validation".
Paste your message to validate in the box. (You can hit the "Guess" button to preset the Message Profile OID.)
    
For example, for the ORU^R30^ORU_R30 message :

1. Copy the ORU^R30^ORU_R30 HL7 message from your system. Paste it in the box in the EVSClient page. 
2. Select the Message profile OID according to your message. In this example : 
   • Affinity Domain : IHE
   • Domain : Laboratory
   • Actor : Point Of Care Data Manager
   • Transaction : LAB-32
   • Message Type : ORU^R30^ORU_R30
   • HL7 Version : HL7v2.5
3. Once you have selected the Profile OID, press the "Validate" button. If the Validation Result is not "PASSED", it means your HL7 message is not according to the LPOCT Profile of the Laboratory  Technical Framework. If the Validation Result is "PASSED", copy the "Permanent link" and paste it in Gazelle as the result of this test. For further details, see this tutorial : How enter your pre-connectathon test result in Gazelle (only for the LAW, LCSD, LPOCT and LBL Profiles of the Laboratory Domain) ?

Do this for all messages and don't forget to copy/paste the "Permanent link" of the validation result to Gazelle.

Evaluation

• The validation status shall be "PASSED" for all messages.
• The message type shall be the right message type, according to IHE.
• Each of the three messages must be validated at least one time and the permanent link must be paste to Gazelle.

This test concerns the Order Filler actor of the LPOCT profile. You will need to validate with EVSClient tool the IHE conformance of your HL7 messages.

Instructions

As your system implements the Order Filler actor, you will need to test the HL7 messages used in the LAB-32 transaction : "Accepted Observation Set".
Your system must be able to send HL7 message (to the POCDM actor) of type:

• ACK^R33^ACK, for the LAB-32  transaction

To test the IHE conformance of your HL7 messages, go to the EVSCLient tool at this location : EVSClient
If it is your first time with this tool, please read the user manual : EVSClient User Manual
    
In the EVSClient tool, go to the HL7 menu entry and choose "HL7v2" then click on "Message Validation".
Paste your message to validate in the box. (You can hit the "Guess" button to preset the Message Profile OID.)
    
For example, for the ACK^R33^ACK message :

1. Copy the ACK^R33^ACK HL7 message from your system. Paste it in the box in the EVSClient page. 
2. Select the Message profile OID according to your message. In this example : 
   • Affinity Domain : IHE
   • Domain : Laboratory
   • Actor : Department System Scheduler/Order Filler
   • Transaction : LAB-32
   • Message Type : ACK^R33^ACK
   • HL7 Version : HL7v2.5
3. Once you have selected the Profile OID, press the "Validate" button. If the Validation Result is not "PASSED", it means your HL7 message is not according to the LPOCT Profile of the Laboratory  Technical Framework. If the Validation Result is "PASSED", copy the "Permanent link" and paste it in Gazelle as the result of this test. For further details, see this tutorial : How enter your pre-connectathon test result in Gazelle (only for the LAW, LCSD, LPOCT and LBL Profiles of the Laboratory Domain) ?

Do this for all messages and don't forget to copy/paste the "Permanent link" of the validation result to Gazelle.

Evaluation

• The validation status shall be "PASSED" for all messages.
• The message type shall be the right message type, according to IHE.
• The Acknowledgment code of the ACK^R33^ACK messages shall be "AA" (MSA-1).
• Each of the three messages must be validated at least one time and the permanent link must be paste to Gazelle.

This test applies to the Content Data Structure Creator actor in the Aggregate Data Exchange (ADX) profile.

This test ensures that the DSD file produced by the Content Data Structure Creator actor is conformant to the ADX schematron specification.

Reference:  QRPH TF-3: 8.2 and Appendix 8A, currently in the ADX Trial Implementation Supplement.

The gazelle External Validation Service (aka EVSClient) hosts the schmatron file and is used to check the DSD.

Instructions

1. Access the Gazelle EVSClient application: https://gazelle.ihe.net/evs
2. From the EVS Client user interface, select menu IHE-->SDMX-->Validate
3. Upload the XML file for the document produced by your application
4. Select the schmatron for ADX.
5. Click on Validate
   

Evaluation

1. The tool reports the results of the evaluation
2. The EVS Client creates a Permanent link to your results.
3. Finally, paste the Permanent Link into Gazelle Test Management as the results for this test.

This test applies to the Content Creator actor in the Advanced Patient Privacy Consents (APPC) profile.

This test ensures that the file produced by the Content Creator actor is conformant to the specification.

Reference:  ITI TF-3: 5.6, currently in the APPC Trial Implementation Supplement.

The gazelle External Validation Service (aka EVSClient) hosts the schmatron file used to check the APPC documents.

Instructions

1. Access the Gazelle EVSClient application: https://gazelle.ihe.net/evs
2. From the EVS Client user interface, select menu IHE-->APPC-->Validate
3. Upload the XML file for the document produced by your application
4. Select the APPC schematron
5. Click on Validate
   

Evaluation

1. The tool reports the results of the evaluation
2. The EVS Client creates a Permanent link to your results.
3. Finally, paste the Permanent Link into Gazelle Test Management as the results for this test.

Overview

We use DICOM validator tools hosted in the Gazelle External Validation Service (EVS) to evaluate your DICOM objects.

In this test, Acquisition Modality, Lightweight Modality, or Evidence Creator systems evaluate samples of Composite Objects that you create using the DICOM evaluation tools available in the Gazelle External Validation Service (EVS).   This test also applies to actors such as Importers that modify objects originally created by other actors.

The number of evaluations you run depends on the types of images or SRs that you produce. We will not list specific requirements, but ask you to apply good judgment. For example, a CT scanner that produces Localizer and Axial images would evaluate samples from both of those image types. A CR device may evaluate an AP chest, a lateral chest and an image of a limb.  A Lightweight Modality might create a VL Photographic Image IOD or a Video Photographic Image IOD.

You must evaluate and provide the output for at least one DICOM Composite Object using '''one'' of the available validation tools.   If you support multiple profiles and create different DICOM IODs, you should validate each type. 

One or more of these tools may be available from within the Gazelle EVS.  (Note:  The links below are for resource pages for each tool.)

• dcm4che
• dicom3tools from David Clunie
• dcmcheck from OFFIS
• PixelMed  used for DICOM SRs, including SRs for the Evidence Documents, AI Results, REM, and REM-NM Profiles
• NOTE:  The label for the PixelMed validator may  say "Dose SR", but it can be used for all DICOM SR oblects

Evaluating your objects using the different tools available as well as evaluating different objects can only help your implementation.

There are two ways to access the validators: (1) in the Samples area of Gazelle Test Management, or (2) directly in the EVS tool.  Either method may be used.

(1) Instructions for accessing the DICOM validators from the Samples area of Gazelle Test Management:

1. Access Gazelle Test Management and log in.
2. Select menu Testing-->Sample exchange
3. Select your test system from the dropdown list
4. On the 'Samples to share' tab, find the entry for 'DICOM_OBJECTS'
5. Select the '+' and proceed to upload a DICOM file(s)
6. Once the file is uploaded, you will be able to use the green triangle icon to call the DICOM validator in EVS.

(2) Instructions for accessing the DICOM validators in the Gazelle EVS Tool:

1. Access the Gazelle EVS: https://gazelle.ihe.net/evs/home.seam
2. Select menu IHE-->DICOM-->Validate
3. Upload the file you want to validate.
4. Then, select one of the DICOM validator tools from the dropdown list.  To get the best coverage, we encourage you to try multiple validators, as applicable.
5. Click Execute.
6. You will see your results. (to find them later, Select menu IHE-->DICOM-->Validation logs
   
7. The tool identifies errors in your content.  Examine your results.
   -->You are finished with this test when you have either satisfied all of the errors detected by the tool. If you disagree with the results of the tool, you can write a short (1 or 2 line) description that describes why your object is correct and the DICOM tool software is in error.
8. Find the Permanent link to the results

Finally, capture your results:

1. Copy either the permanent link to your sample or the permanent link to your results in the EVS and paste the link as the result for this test in Gazelle Test Management. (This is also where you can comment on the results of the validation.)  

This test applies to the Content Creator actor in the Document Digital Signature (DSG) profile.

This test ensures that the file produced by the Content Creator actor is conformant to the specification.

Reference:  ITI TF-3: 5.5.

Instructions

1. Instructions are in the EVS Client User Manual here: https://gazelle.ihe.net/gazelle-documentation/EVS-Client/user.html#validation-of-digital-signatures

Evaluation

1. The tool reports the results of the evaluation
2. The EVS Client creates a Permanent link to your results.
3. Paste the Permanent Link into Gazelle Test Management as the results for this test.

• Test Summary
• Who performs this test
• Instructions
• Evaluation

Test Summary

The Gazelle External Validation Service (EVS) performs validation using FHIR StructureDefinitions contained in IHE profiles published in FHIR Implementation Guide (IG) format (e.g. the ITI Mobile Access to Health Documents (MHD) IG, and many others).  The StructureDefinitions used by EVS are found on the "Artifacts" page of the IG. 

In this test, you will use the Gazelle EVS tool to validate:

• FHIR®© Resources created by your application and/or returned by your application in response to a query
• IHE transactions based on FHIR:  outbound messages and responses with constraints defined in IHE transaction definitions.

The validators are available in EVS under menu IHE-->FHIR IG-based -->Validate.

Who performs this test

This test appears in Gazelle Test Management as a Preparatory test, so... 

• If your actor icreates FHIR resources and/or initiates a transaction containing one or more FHIR Resources in XML or JSON format, you should perform this test to use the EVS tool ensure the Resource(s) and transactions you create pass validation.
• If your actor responds to a query and returns FHIR Resource(s) in XML or JSON format, you should perform this test.
• If your actor audits a transaction using an ATNA ATX FHIR Feed (AuditEvent), you should validate your audit messages.
  
  
• How do you know which resources and transactions to test?  IHE profiles that exchange FHIR-based Resources identify the actor(s) and the applicable transactions and resources.  We will not restate the requirements for each actor here, but here are some examples:
• A PDQm Patient Demographics Supplier responds to an [ITI-78] query by sending a Bundle of one or more Patient Resources.  The Patient Resource is not constrained in the PDQm profile
• An IPS Content Creator creates a FHIR bundle with IPS content.
• An MHD Document Source sends [ITI-65].  Depending on the type of submission, ITI-65 sends a Transaction Bundle with a combination of List, DocumentReference, Binary and Patient Resources, with constraints defined in MHD.
• An ATNA Secure Node/Application that supports the ATX: FHIR Feed option for [ITI-20] sends AuditEvent Resources to an Audit Record Repository; some IHE transactions have constraints on the AuditEvent Resource.
• You should validate Resources that your system has created.  For some actors (e.g. PDQm Supplier, mCSD Supplier), Connectathon technical managers provide pre-defined test data used in Connectathon tests.   You should not validate these resources; instead, we assume that your application is also able to create Patient, Practitioner, Organzation, etc Resources.  These are the ones you should test.
  
  

Instructions

• Identify the FHIR Resources and FHIR-based transactions supported by your application.
• Access the Gazelle EVS: https://gazelle.ihe.net/evs
• From the EVS user interface, select menu IHE-->FHIR IG-based-->Validate 
• Upload the XML or JSON file produced by your application
• Select the correct Validator from the dropdown list.
• Click on Validate.
• Repeat as needed for other resources or transactions.

Evaluation

• The EVS creates a Permanent link to your results under IHE-->FHIR IG-based-->Validation Log
• Paste the Permanent Link into Gazelle Test Management as the results for this test.
• Many systems will have more than one result to report.

This test has been deprecated as of the 2022 IHE Connectathon

• Test Summary
• Scope of testing available in Gazelle EVSClient
• Who this test applies to
• Instructions
• Evaluation

Test Summary

You will use the Gazelle EVSClient tool to validate:

• FHIR®© Resources created by your application and/or returned by your application in response to a query
• IHE transactions based on FHIR:  outbound messages and responses with constraints defined in IHE transaction definitions.

Scope of testing available in Gazelle EVSClient

1. Validation of Resources using the baseline requirements defined in FHIR.   This is available in EVSClient under menu FHIR®©-->Validate.
2. Validation of Resources and transactions based on constraints defined in IHE profiles.  This is available in EVSClient under menu IHE-->FHIR®©-->Validate.  The contraints tested by EVSClient are defined in FHIR conformance resources published by IHE (e.g., StructureDefinition and ValueSet resources)
   

• For IHE profiles published in FHIR Implementation Guide (IG) format (e.g. MHD, mCSD, and more), conformance resources are found on the "Artifacts" page of the IG.
  
• For IHE profiles published in PDF format, conformance resources are found on https://github.com/IHE/fhir

Who this test applies to

This test appears in Gazelle Test Management as a preparatory test for actors in all FHIR-based IHE profiles, so... 

• If your actor initiates a transaction containing one or more FHIR Resources in XML or JSON format, you should perform this test to use the EVSClient tool ensure the Resource(s) and transactions you create pass validation.
• If your actor responds to a query and returns FHIR Resource(s) in XML or JSON format, you should perform this test.
• If your actor, produces/sends FHIR Resources, how do you know which resources and transactions to test?  IHE profiles that exchange FHIR-based Resources identify the actor(s) and the applicable transactions and resources.  We will not restate the requirements for each actor here, but here are some examples:
• A PDQm Patient Demographics Supplier responds to an [ITI-78] query by sending a Bundle of one or more Patient Resources.  The Patient Resource is not constrained in the PDQm profile.
• An MHD Document Source sends [ITI-65].  Depending on the type of submission, ITI-65 sends a Transaction Bundle with a combination of List, DocumentReference, Binary and Patient Resources, with constraints defined in MHD.
• A mACM Alert Reporter sends an [ITI-84] alert request that contains a CommunicationRequest Resource.  The Alert Aggregator's  [ITI-84] response contains a CommunicationRequest Resource and Communication Resource(s).
• An ATNA Secure Node/Application that supports the ATX: FHIR Feed option for [ITI-20] sends AuditEvent Resources to an Audit Record Repository; some IHE transactions have constraints on the AuditEvent Resource.
• You should validate Resources that your system has created.  For some actors (e.g. PDQm Supplier, mCSD Supplier), Connectathon technical managers provide pre-defined test data used in Connectathon tests.   You should not validate these resources; instead, we assume that your application is also able to create Patient, Practioner, Organzation, etc Resources.  These are the ones you should test.
• If your actor only consumes FHIR Resources (i.e., it only receives them from other actors), then you can skip this test.  (**However** you may be interested in testing with Resources submitted by others and collected in the tool.  In the EVSClient, select menu IHE-->FHIR®©-->Validation logs and use the filters on the page to find Resources of interest to you.)

Instructions

• Identify the FHIR Resources and FHIR-based transactions supported by your application,
• Access the Gazelle EVSClient application: https://gazelle.ihe.net/evs
• From the EVSClient user interface, select menu IHE-->FHIR®©-->Validate (to test IHE constraints) or FHIR®©-->Validate (to test baseline requirements for FHIR Resources)
• Upload the XML or JSON file produced by your application
• Select the correct Model Based Validation from the dropdown list.
• Click on Validate.
• Repeat as needed for other resources or transactions.

Evaluation

• The EVSClient creates a Permanent link to your results under IHE-->FHIR®©-->Validation Log or FHIR®©-->Validation Log
• Paste the Permanent Link into Gazelle Test Management as the results for this test.
• Many systems will have more than one result to report.

This test uses the Gazelle EVS Tool to validate a QIDO-RS Query Request or Response message.

Actors tested:   Any initiator or responder in the [RAD-129] QIDO-RS Query transaction

Instructions

• Access the Gazelle EVS application:  https://gazelle.ihe.net/evs/home.seam
• From the EVS user interface, select menu IHE-->DICOM Web - QIDO-RS Query-->Validate or IHE-->DICOM Web - QIDO-RS Response-->Validate
• Upload a file with the QIDO-RS Query request or response message produced by your application.
• From the dropdown list, select a validator that matches your message; the tool provides several validators for different messages in the WIA or AIR profile.
• Click on Validate.

Evaluation

• The EVS Client creates a Permanent link to your results.
• Paste the Permanent Link into Gazelle Test Management as the results for this test.

Overview of the test

This test has two parts:

(1) First, the Event Reporter identifies the SOLE events that it supports.  This helps your Connectathon test partners and the Connectathon monitors understand the capabilities of your system.

(2)  Then, you will use the Gazelle EVSClient tool to test the content of the event record(s) you create against the DICOM schema & SOLE Event Requirements. This tool does not test the transport of the event record.

(1) Identify your SOLE Event Reports

• We use a google doc to collect this information from all SOLE Event Reporters.  Click HERE to open it.
• The rows in the table list the Baseline SOLE events from the SOLE Profile, Vol 3, Table 6.3.2-1.
• The columns hold information for each Connectathon test system.  Column C is an example
• In the next available column, add your company and test system name, then mark the Events you support with an 'X'.

(2) Test your SOLE Event Reports

1. In the Gazelle EVSClient, select menu IHE-->ATNA Audit messages-->Validate
2. Select the Add button, and upload the XML file for your event report
3. From the Model based validation dropdown list, select the entry that matches the event, eg "IHE - RAD - SOLE101 - Order Filled"
4. Select the Validate button.  
5. You should validate at least 3 event records; of course, we encourage you to do more.

Evaluation

• The EVS Client creates a Permanent link to your results.
• Paste the Permanent Link into Gazelle Test Management as the results for this test.
• You may report more than one result.

This tests the request in the WADO Retrieve [RAD-55] transaction

In XDS-I or IOCM, the Imaging Document Consumer is required to support one or more of RAD-55, RAD-68 or RAD-16 (or other C-MOVE).

• So, if your Imaging Document Consumer does not support RAD-55, you should skip this test.

The aim of this test is to verify that the Imaging Document Consumer is able to create a valid WADO request (the list of parameters is well specified, there are no inconsistency between them, etc). To do so, we use a WADO validator of the request from EVSClient tool.

In this test we do not verify that the request was well treated, or not, by the server side.

Instructions

• From the Gazelle EVS user interface, select menu IHE-->RAD-55 WADO Request-->Validate
• Paste/upload your request, select the correct validator, and Validate. (Yes you can use any WADO back-end and any data set, to create your request ).

Evaluation

• The EVS creates a Permanent link to your results.
• Paste the Permanent Link into Gazelle Test Management as the results for this test.

Content Creator creates a Workflow dDocument and validates it

Content Creator will create a workflow document produced by your application.  This could be as defined in the base XDW profile, or on the specialized workflow documents such as XTHM, XBeR, and others.

Then you will use the XDW Validator in Gazelle EVS Client to verify your Workflow Document.

Finally, you will upload your sample document into Gazelle Test Management so that Content Consumers can access your sample and test with it prior to the Connectathon. 

Instructions

For this test, you will create a Workflow Document for a task that is relevant to your product/application; the contents of the task you complete should be in the context of the clinical functions your product performs.

For this test, you do not have to submit your workflow document to an XDS Repository/Registry.

(1) Once you have created/updated the workflow document, upload it into the Samples area of Gazelle Test Management:

• Select the Samples to share tab for your test system
• For the XDW entry (or XTHM, or XBeR... entry) select the 'Add sample' (+) icon.
• Upload the XML for your XDW document.  Name the XML file using this convention: <your-system-name>-<profile>.xml, eg EHR_XYXMedicalCo-XTHM.xml
• Select the "Validate" icon.

Alternative:  Access XDW Validator via the Gazelle External Validation Service (EVS):

• Access the External Validation Service: https://gazelle.ihe.net/evs
• Select menu:  IHE / XDW / Validate
• Upload the XML for your XDW document.
• Select the appropriate Validator from the 'Model Based Validation' drop-down list.
• Select the Validate button
• Next, find your results.  Select menu:  IHE / XDW / Validated XDW documents
• Use the interface to find your validated document.  This will show your results.

Evaluation

• The validation service creates a Permanent link to your results
• Paste the Permanent Link into Gazelle Test Management as the results for this test.

Your test partners that are Content Consumers will also be able to access your sample in Gazelle Test Management.

Content Updater updates a Workflow Document

In this test you will access a sample workflow made by a Content Creator; then you will update that document using your application, and use the XDW Validator provided in Gazelle EVS Client to validate your updated document.  

Finally, you will upload your 'updated' Workflow Document into the Samples area of Gazelle Test Management.  

Instructions

For this test, you will update a workflow document 

(1) For the base XDW profile, access this sample workflow document: XDW-Document-for-Updater.xml

--  If you are testing XBeR, XTHM, we do not have a generic sample for you to start from.  You may use a sample submitted by a 'Creator' vendor in your profile.

(2) Download the Workflow Document into your local environment, then update the document and add a task that is relevant to your product/application.

• Your new task should contain an input document, and output document, or both

For this test, you do not have to submit your workflow document to an XDS Repository/Registry

(3) Once you have created the updated workflow document, upload your document into the Samples area of Gazelle Test Management:

• Select the Samples to share tab for your test system
• For the XDW entry, select the 'Add sample' (+) icon.
• Upload the XML for your XDW document.  Name the XML file using this convention:
• SYSTEMNAME_XDW.xml, where "SYSTEMNAME" is your test system's name in gazelle, eg: EHR_XYZmed_XDW.xml
• Select use "Pre-Connectathon" from the dropdown list on the summary of the sample.
• Select the "Validate" button.

Alternative:  Access XDW Validator via the Gazelle External Validation Service (EVS):

• Access the External Validation Service: https://gazelle.ihe.net/evs
• Select menu:  IHE / XDW / Validate
• Upload the XML for your XDW document.
• Select the Validate button
• Next, find your results.  Select menu:  IHE / XDW / Validated XDW documents
• Use the interface to find your validated document.  This will show your results.

Evaluation

• The EVS Client creates a Permanent link to your results.
• Paste the Permanent Link into Gazelle Test Management as the results for this test.

Your test partners that are Content Consumers will also be able to access your sample in Gazelle Test Management.

We use this 'test' to inform you of the Gazelle HPD Simulator & Validator tool available for your testing. 

HPD actors simulated:

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

Location of the tool: https://gazelle.ihe.net/HPDSimulator/home.seam

Tool user manual: https://gazelle.ihe.net/content/hpd-simulator

We encourage you to test with the simulator prior to the Connectathon.

There are no results to upload into Gazelle Test Management for this test.

This test concerns the LB (Label Broker) actor. You will use the Order Manager tool to send a request to your system under test.

Instructions

Access the LBL Simulator tool at this location : Order Manager
If it is your first time with this tool, please read the user manual : Order Manager user manual
Please be remind that if you are logged in your configurations will be private.

In this test, the SUT (System Under Test) must received the labeling instructions from the LBL Simulator.

As the SUT implements the LB (LB acts as a responder in this test) :

1. Create or update the configuration corresponding to the SUT.
2. Then, go to the "Laboratory" menu entry and choose Label Information Provider > [LAB-61] page to begin the test. 
3. In the SUT Configurations drop-down list, select the SUT configuration.
4. Once you have selected the patient, hit the "Send" button. The simulator will send the message to the SUT with the labeling instructions.
5. Check the simulator has properly received your acknowledgement message.

The messages exchanged between the simulator and the SUT can be found in the message table on the very same page or from the HL7 Message menu entry.
Hit the link on the left side  of the raw (first column of the table), to display the Permanent Link to the test report for the corresponding HL7 message. (You can access to the hl7v2 report tutorial for more details.)
If the validation report status is passed for the message and the response, copy the "test result link" and paste it in Gazelle as the result of this test.
For further details, see this tutorial : How enter your pre-connectathon test result in Gazelle (only for the LAW, LCSD and LBL Profiles of the Laboratory Domain which send HL7v2 messages)?

Evaluation

• The validation status must be passed for the two messages of the transaction. The message type must be the right message type, according to IHE.
• The Acknowledgment code must be "AA" (MSA-1) in the acknowledgment message.

This test concerns only the LIP (Label Information Provider) actor. Your system under test will request the Order Manager tool (acting as Label Broker) to deliver the labels (LAB-61 transaction).

Instructions

Access the LBL Simulator tool at this location : Order Manager
If it is your first time with this tool, please read the user manual : Order Manager user manual
Please be remind that if you are logged in your configurations will be private.

In this test, the SUT (System Under Test) must send the labeling instructions to the LBL Simulator.

As your system under test implements the LIP (LIP acts as an initiator in this test) :

1. You do not need to create a SUT configuration for your system. Just go to the "Laboratory" menu entry and choose Label Broker > Configuration page to begin your test.
2. Configure your system under test to send the messages to IP address and port displayed on screen.
3. Don't forget to hit the "Refresh List" button after to have send your message.
4. Check the simulator has properly received and acknowledged your message.

The messages exchanged between the simulator and the SUT can be found in the message table on the very same page or from the HL7 Message menu entry.
Hit the link on the left side of the raw (first column of the table), to display the Permanent Link to test report for the corresponding HL7 message. (You can access to the hl7v2 report tutorial for more details.)
If the validation report status is passed for the message and the response, copy the "test result link" and paste it in the comment section of the pre-connectathon log return page as the result for this test.
For further details, see this tutorial : How enter your pre-connectathon test result in Gazelle (only for the LAW, LCSD and LBL Profiles of the Laboratory Domain which send HL7v2 messages)?

Evaluation

• The validation status must be passed for the two messages of the transaction. The message type must be the right message type, according to IHE.
• The Acknowledgment code must be "AA" (MSA-1) in the acknowledgment message.

This test concerns only the LIP (Label Information Provider) actor. You will need to communicate with the LBL Simulator, in order to simulate the LAB-62 transaction of the LBL Profile.

Instructions

Access the LBL Simulator tool at this location : Order Manager
If it is your first time with this tool, please read the user manual : Order Manager User Manual
Please be remind that if you are logged in your configurations will be private. Requirements :

As your system implements the LIP (LIP acts as a responder in this test) :

1. Create or update the configuration corresponding to the SUT (System Under Test).
2. Then, go to the "Laboratory" menu entry and choose Label Broker > [LAB-62] page to begin your test.
3. In the SUT Configurations drop-down list, select your LB system.
4. In order to construct your request, you will need to fill the request parameters table. You will find all information in the SUT system.

In this test, you must use the LBL Simulator to query the SUT. Send severals messages using different parameters. All (Required) possibilities are defined in the steps below :

• Step 1 : Label Broker (Simulator) queries the Label Information Provider (SUT) using the patient ID.
• Step 2 : Label Broker (Simulator) queries the Label Information Provider (SUT) using the Placer Visit Number.
• Step 3 : Label Broker (Simulator) queries the Label Information Provider (SUT) using the Placer Group Number.
• Step 4 : Label Broker (Simulator) queries the Label Information Provider (SUT) using the Placer Order Number.
• Step 5 : Label Broker (Simulator) queries the Label Information Provider (SUT) using the Filler Order Number.
• Step 6 : Label Broker (Simulator) queries the Label Information Provider (SUT) using the search period and patient id.
• Step 7 : Label Broker (Simulator) queries the Label Information Provider (SUT) using the search period and patient visit number.
• Step 8 : Label Broker (Simulator) queries the Label Information Provider (SUT) using a patient ID which is unknown by the LIP. (This is an error case, to test the answer of your LIP in this situation.)

Take an example, for the step 1 :

1. In the request parameters table, fill the Patient ID field with a patient ID from you SUT.
2. Then hit the "Send" button. 3.The LBL Simulator will send the message to your system and will get a response (if the SUT answers).
3. Check the simulator has properly received your acknowledgement message.
4. The messages exchanged between the simulator and the SUT can be found in the message table on the very same page or from the HL7 Message menu entry. Hit the link on the left side of the raw (first column of the table), to display the Permanent Link to test report for the corresponding HL7 message. (You can access to the hl7v2 report tutorial for more details.)
   If the validation report status is passed for the message and the response, copy the "test result link" and paste it in the comment section of the pre-connectathon log return page as the result for this test. For further details, see this tutorial : How enter your pre-connectathon test result in Gazelle (only for the LAW, LCSD and LBL Profiles of the Laboratory Domain which send HL7v2 messages) ?

Do this for all steps and don't forget to copy/paste the "test result link". Link the step number to the "test result link".

Evaluation

• The point below must be verified for each steps :
• The validation status must be passed for the two messages of the transaction. The message type must be the right message type, according to IHE.
• The Acknowledgment code must be "AA" (MSA-1) in the acknowledgment message.
• All steps must have been done.

This test concerns the LB (Label Broker) actor. You will need to communicate with the LBL Simulator, in order to simulate
the LAB-62 transaction of the LBL Profile.

Instructions

Access the LBL Simulator tool at this location : Order Manager
If it is your first time with this tool, please read the user manual : Order Manager User Manual
Please be remind that if you are logged in your configurations will be private. Requirements :

As your system implements the LB (LB acts as an initiator in this test) :

1. You do not need to register your SUT (System Under Test) configuration in the simulator. Just go to the "Laboratory" menu entry and choose Label Information Provider > Configuration page to begin your test.
2. Configure your SUT to send messages to IP Address and Port of the simulator.
3. Go to the Messages > HL7v2 messages

In this test, the SUT must query the LBL Simulator. Send severals messages using different parameters. All (Required) possibilities are defined in the steps below :

• Step 1 : Label Broker (SUT) queries the Label Information Provider (Simulator) using the patient ID.
• Step 2 : Label Broker (SUT) queries the Label Information Provider (Simulator) using the Placer Visit Number.
• Step 3 : Label Broker (SUT) queries the Label Information Provider (Simulator) using the Placer Group Number.
• Step 4 : Label Broker (SUT) queries the Label Information Provider (Simulator) using the Placer Order Number.
• Step 5 : Label Broker (SUT) queries the Label Information Provider (Simulator) using the Filler Order Number.

Take an example, for the step 1 :

1. The SUT queries the LBL Simulator using a patient ID (the SUT send a message to the LBL Simulator). See the "Patient Information available for your Request to the simulator" panel to get the patient Identifier. This panel give information about the patients of the LBL simulator.
2. The messages exchanged between the simulator and the SUT can be found in the message table on the very same page or from the HL7 Message menu entry.
3. Check the simulator has properly received and acknowledged your message.
4. Hit the link on the left side of the raw (first column of the table), to display the Permanent Link to test report for the corresponding HL7 message. (You can access to the hl7v2 report tutorial for more details.) If the validation report status is passed for the message and the response, copy the "test result link" and paste it in the comment section of the pre-connectathon log return page as the result for this test. For further details, see this tutorial : How enter your pre-connectathon test result in Gazelle (only for the LAW, LCSD and LBL Profiles of the Laboratory Domain which send HL7v2 messages) ?

Do this for all steps and don't forget to copy/paste the "test result link". Link the step number to the "test result link".

Evaluation

The point below must be verified for each steps :

• The validation status must be passed for the two messages of the transaction. The message type must be the right message type, according to IHE.
• The Acknowledgment code must be "AA" (MSA-1) in the acknowledgment message.
• All steps must have been done.

This test concerns the LIP (Label Information Provider) actor. Your SUT will receive the label delivered notification from the Order Manager tool acting as Label Broker.

In this test, the Label Broker notifies the effective labeled containers production to the Label Information Provider.
So, the LBL Simulator, needs to know the labeling instruction, before to send a notification message to the LIP for the effective labels printing and labeled containers production.
Two steps are necessary in this test :

• First, the SUT (System Under Test) will send the labeling instruction to the LBL Simulator (see test LBL Request Mode For Labeling Instruction).
• Second, the LBL Simulator will notify the SUT for the effective labels printing and labeled containers production (this test).

Instructions

Access the LBL Simulator tool at this location : Order Manager
If it is your first time with this tool, please read the user manual : Order Manager User Manual
Please be remind that if you are logged in your configurations will be private.

1. Create or update the configuration corresponding to your SUT from the SUT Configurations > HL7v2 responders page.
2. Go to the "Laboratory" menu entry and choose Label Broker > [LAB-63] page to begin your test.
3. In the SUT Configurations drop-down list, select your LIP system.
4. Then, select in the "Table on the tubes label by the LB simulator" table, the tube according to your labeling instruction send to the LBL Simulator in the first step of this test. You can use the filter option to find it easy.
5. Once you have selected the right tube to confirm, hit the "Send the confirmation of the selected labeled tubes" button. The LBL Simulator will send the message to your system.
6. Check the simulator has properly received your acknowledgement message.
7. The messages exchanged between the simulator and the SUT can be found in the message table on the very same page or from the HL7 Message menu entry. Hit the link on the left side  of the raw (first column of the table), to display the Permanent Link to test report for the corresponding HL7 message. (You can access to the hl7v2 report tutorial for more details.) If the validation report status is passed for the message and the response, copy the "test result link" and paste it in the comment section of the pre-connectathon log return page as the result for this test. For further details, see this tutorial : How enter your pre-connectathon test result in Gazelle (only for the LAW, LCSD and LBL Profiles of the Laboratory Domain which send HL7v2 messages) ?

Evaluation

• The validation status must be passed for the two messages of the transaction.
• The message type must be the right message type, according to IHE.
• The Acknowledgment code must be "AA" (MSA-1) in the acknowledgment message.

This test concerns the LB (Label Broker) actor. You will use the Order Manager tool to simulate the Label Information Provider actor.

In this test, the Label Broker notify the effective labeled containers production to the Label Information Provider.
So, the SUT (System Under Test), needs to know the labeling instruction, before to label the tubes and to send a notification message to the LIP for the effective labels printing and labeled containers production.
Two steps are necessary in this test :

• First, the LBL Simulator will send the labeling instruction to the SUT (see test "LBL Request Mode For Labeling Instruction")
• Second, the SUT will notify the LBL Simulator for the effective labels printing and labeled containers production.

Instructions

Access the LBL Simulator tool at this location : Order Manager
If it is your first time with this tool, please read the user manual : Order Manager User Manual
Please be remind that if you are logged in your configurations will be private.

1. Go to the "Laboratory" menu entry and choose Label Information Provider > Configuration page to begin your test.
2. Configure your SUT to send messages to the IP Address and Port displayed on screen.
3. Send a message to the LBL Simulator for the effective labels printing and labeled containers production.
4. Access the messages exchanged between your SUT and the simulator under Messages > HL7v2 messages.
5. Check the simulator has properly received your acknowledgement message.
6. The messages exchanged between the simulator and the SUT can be found in the message table on the very same page or from the HL7 Message menu entry. Hit the link on the left side  of the raw (first column of the table), to display the Permanent Link to test report for the corresponding HL7 message. (You can access to the hl7v2 report tutorial for more details.) If the validation report status is passed for the message and the response, copy the "test result link" and paste it in Gazelle as the result of this test. For further details, see this tutorial : How enter your pre-connectathon test result in Gazelle (only for the LAW, LCSD and LBL Profiles of the Laboratory Domain which send HL7v2 messages) ?

Evaluation

The validation status must be passed for the two messages of the transaction. The message type must be the right message type, according to IHE.
The Acknowledgment code must be "AA" (MSA-1) in the acknowledgment message.

This test concerns the CSC (Code Set Consumer) actor. You will need to communicate with the LCSD Simulator, in order to simulate the LAB-51 transaction of the LCSD Profile.

Instructions

Access the LCSD Simulator tool at this location : LCSD Simulator
If it is your first time with this tool, please read the user manual : LCSD Simulator User Manual
Please be remind that if you are logged in your configurations will be private.
   
As your system implements the CSC (CSC acts as a responder in this test) :

1. Create or update the configuration corresponding to the SUT (System Under Test).
2. Then, go to the "Simulators" menu entry and choose "CSM" page to begin your test.
3. In the SUT Configurations drop-down list, select your CSC system.
4. You will need to select the Code Set Category, then the Code Sets to send. Hit the "Send" button and the LCSD Simulator will send the message with selected code sets to your system.

Send at least, one code set for each code set category (Battery, Calculated, Not Numeric and Numeric. The Batch mode is not available yet in the LCSD Simulator.)
All (Required) possibilities are defined in the steps below.   

• Step 1 : The CSM (Simulator) send a Battery code set to the CSC (SUT).
• Step 2 : The CSM (Simulator) send a Calculated code set to the CSC (SUT).
• Step 3 : The CSM (Simulator) send a Not Numeric code set to the CSC (SUT).
• Step 4 : The CSM (Simulator) send a Numeric code set to the CSC (SUT).

How run and log this steps ?
For example, for the step 1:

1. choose in the code set category : "Battery" and select one code set among the available code sets.
2. Then hit the "Send" button. The LBL Simulator will send the message to your system and will get a response (if the SUT answers). 
3. Check the simulator has properly received your acknowledgement message.   

The messages exchanged between the simulator and the SUT can be found in the message table on the very same page or from the HL7 Message menu entry.
Hit the link on the left side of the raw (first column of the table), to display the Permanent Link to test report for the corresponding HL7 message. (You can access to the hl7v2 report tutorial for more details.)
If the validation report status is passed for the message and the response, copy the "test result link", and paste it in Gazelle.
For further details, see this tutorial : How enter your pre-connectathon test result in Gazelle (only for the LAW, LCSD and LBL Profiles of the Laboratory Domain which send HL7v2 messages) ?

Do this for all steps and don't forget to copy/paste the "test result link". Link the step number to the "test result link".

Evaluation

• The validation status shall be passed for the two messages of the transaction.
• The message type shall be the right message type, according to IHE.
• The Acknowledgment code shall be "AA" (MSA-1) in the acknowledgment message.

This test concerns only the CSM (Code Set Master) actor. You will need to communicate with the LCSD Simulator, in order to simulate
the LAB-51 transaction of the LCSD Profile.

Instructions

Access the LCSD Simulator tool at this location : LCSD Simulator
If it is your first time with this tool, please read the user manual : LCSD Simulator User Manual
Please be remind that if you are logged in your configurations will be private.
   
As your system implements the CSM (CSM acts as an initiator in this test) :

1. Don't need to create a SUT (System Under Test) configuration for your system. Just go to the "Simulators" menu entry and choose "CSC" page to begin your test.
2. In the charset drop-down list, select the desired charset. 
3. Use the Ip Address and the Port linked to this charset to send your message to the LCSD Simulator.
4. Don't forget to hit the "Refresh List" button after to have send your message.

Send at least, one code set for each code set category (Battery, Calculated, Not Numeric and Numeric. The Batch mode is not available yet in the LCSD Simulator.)
All (Required) possibilities are defined in the steps below.

• Step 1 : The CSM (SUT) send a Battery code set to the CSC (Simulator).
• Step 2 : The CSM (SUT) send a Calculated code set to the CSC (Simulator).
• Step 3 : The CSM (SUT) send a Not Numeric code set to the CSC (Simulator).
• Step 4 : The CSM (SUT) send a Numeric code set to the CSC (Simulator).

How run and log this steps ?
For example, for the step 1 :

1. The SUT must send a code set from the category : "Battery".
2. The LCSD Simulator will respond with an acknowledgment.
3. Check the simulator has properly received and acknowledged your message. 

The messages exchanged between the simulator and the SUT can be found in the message table on the very same page or from the HL7 Message menu entry.
Hit the link on the left side of the raw (first column of the table), to display the Permanent Link to test report for the corresponding HL7 message. (You can access to the hl7v2 report tutorial for more details.)
If the validation report status is passed for the message and the response, copy the "test result link" and paste it in Gazelle as the result of this test.
For further details, see this tutorial : How enter your pre-connectathon test result in Gazelle (only for the LAW, LCSD and LBL Profiles of the Laboratory Domain which send HL7v2 messages) ?  

Evaluation

• The validation status shall be passed for the two messages of the transaction.
• The message type shall be the right message type, according to IHE.
• The Acknowledgment code shall be "AA" (MSA-1) in the acknowledgment message.

The NIST FHIR Toolkit is used by developers before and during IHE North American and European Connectathons.  

The FHIR Toolkit is used by participants and monitors during Connectathon week, so participants should prepare by using the tools in their home lab prior to Connectathon.

Location of tool and associated documentation: 

Home page for documentation:  https://github.com/usnistgov/asbestos/wiki

Source code and release notes for FHIR Toolkit are found here:  https://github.com/usnistgov/asbestos/releases/

Installation Guilde:  https://github.com/usnistgov/asbestos/wiki/Installation-Guide

IHE profiles/actors tested:

The NIST FHIR Toolkit contains tests for these actors:

• MHD - Mobile access to Health Documents:
• Document Source 
• Document Recipient

Test instructions for each actor:

The list of tests and detail test instructions for each actor reside within the toolkit package. 

--> You should perform the tests for the actor(s) and options you have implemented   .e.g. support for Comprehensive metadata vs. Minimal metadata.

Preparatory test list in Gazelle Test Management:

In Gazelle Test Management, your preparatory test list will contain one test per actor you are testing with the FHIR Toolkit.  The naming convention is FHIR_Toolkit_<profile>-<actor>, e.g., FHIR_Toolkit_MHD-Doc_Source.

Because this tool is new, you will not upload any logs as part of preparatory testing.  Instead, you may add a note in the test instance that says, "I have successfully performed testing with the FHIR Toolkit."

Stay informed: 

Join the MHD implementer google group to receive information on updates to the tools and to follow Q&A within the developer community.  Users of FHIR Toolkit should subscribe.

January 2024:  Note that the PIX/PDQ tool used in this test has been retired by NIST.  IHE is grateful to NIST for their efforts to develop and support this tool.  It was used for over 10 years by participants testing their PIX/PDQ and XPID implementations at IHE Connectathons.

The test description below is now DEPRECATED, but kept here for historical purposes.

========

The NIST PIX/PDQ tool is used by developers before and during IHE North American and European Connectathons.  The tools enable developers to test actors in several IHE profiles listed below.

Location of tool and associated documentation: 

The tool is found here: https://pixpdqtests.nist.gov/pixpdqtool/

For help using the tool, see the Documentation tab in the tool

IHE profiles/actors tested:

The NIST PIX/PDQ Tool contains tests for these actors:

• PDQ - Patient Demographics Query (HL7v2)
• Patient Demographics Consumer
• Patient Demographics Consumer with Pediatric Demographics Option
• Patient Demographics Supplier
• Patient Demographics Supplier with Pediatric Demographics Option
• PDQv3 - Patient Demographics Query (HL7v3)
• Patient Demographisc Consumer
• Patient Demographics Consumer with Pediatric Demographics Option
• Patient Demographics Supplier
• Patient Demographics Supplier with Pediatric Demographics Option
• PIX - Patient Identifier Cross Referencing (HL7v2)
• Patient Identifier (PIX) Source
• Patient Identifier (PIX) Consumer
• Patient Identifier (PIX) Cross-Reference Manager
• PIXv3 - Patient Identifier Cross Referencing (HL7v3)
• Patient Identifier (PIX) Source
• Patient Identifier (PIX) Consumer
• Patient Identifier (PIX) Cross-Reference Manager
• XPID - XAD-PID Change Management
• Patient Identifier Cross-Reference Manager (for ITI-64 only)

Test instructions for each actor:

The list of tests and the test instrictions for each actor reside on the tool website.  

• Access the tool at the link above
• Select the Tests tab
• Select  HL7v2 or HL7v3
• From the "Actor" Dropdown list, select the profile/actor that you want to test
• After selecting the actor, you will be presented with a list of tests to perform.   When you select an individual test, the instructions will be displayed.

Evaluation

In Gazelle Test Management, your preparatory test list will contain one test per actor you are testing with the tools.  The naming convention is NIST_<profile>-<actor>, e.g., NIST_PIX-Manager

When you have successfully finished testing your actor, capture evidence of success (eg a screenshot).  

Upload that file into Gazelle Test Management as the result for this actor.

The NIST XDS Toolkit is used by developers before and during IHE North American and European Connectathons.

The XDS Tools will be used during Connectathon week, so participants should prepare by using the tools in their home lab prior to Connectathon.

Location of tool and associated documentation: 

Refer to the home page for the NIST Document Conformant Test Tools here: https://ihexds.nist.gov/

Source code and release notes for XDS Toolkit are found here: https://github.com/usnistgov/iheos-toolkit2/releases

IHE profiles/actors tested:

The NIST XDS Toolkit contains tests for these actors:

• XDS.b - Cross-Enterprise Document Sharing:
• Document Registry
• Document Registry for Metadata Update (ITI-57)
• Document Repository
• Integrated Source/Repository??
• XDR - Cross-Enterprise Document Reliable Interchange:
• Document Recipient
• XCA - Cross Community Access:
• Initiating Gateway
• Responding Gateway
• MPQ - Multi-patient Query
• Document Registry
• RMD - Remove Metadata and Documents:
• Document Registry
• Document Repository
• RMU - Restricted Metadata Update:
• Update Responder (XDS Persistence Option & XCA Persistence Option)

Test instructions for each actor:

The list of tests for each actor now reside within the toolkit package.  Likewise, the test definitions are distributed in the package.

--> You should perform the tests for the actor(s) you have implemented   You will be instructed to create a 'test session' within the tool to represent the actor you are testing.  When you do this, all of your results are collected within one directory.

Evaluation:

In Gazelle Test Management, your preparatory test list will contain one test per actor you are testing with the XDS Toolkit.  The naming convention is XDS_Toolkit_<profile>-<actor>, e.g., XDS_Toolkit_XDS.b-Doc_Repository.

When you have successfully finished testing your actor, create a zip file of the result files located in toolkit in the {ExternalCache}/TestLogCache directory.  

Upload that zip file into Gazelle Test Management as the result for this actor.

Stay informed: 

Join the XDS implementer google group to receive information on updates to the tools and to follow Q&A within the developer community.  Users of XDS Toolkit should subscribe.

This test will be performed against the PAMSimulator tool. The goal of this test is to check the capability of your system to send/receive the messages defined within the ITI-31 (Patient Encounter Management) transaction. This test is only dealing with the basic set of trigger events defined for ITI-31, that means Patient admisssion, registration, discharge and the relative cancellation.

You will retrieve the patients the simulator has sent or received under the "All patients" menu; for each patient, the list of relative encounters is available under the tab entitled "Patient's encounters". You may want to use the filter to facilitate your search. If you are using the simulator as a PES, you can log onto the application using the CAS mechanism (use your Gazelle credentials) and easily retrieve the patients you have created within the application by checking the "see only patients created by me" checkbox. If you use the simulator as a PEC, the creator of the patients/encounters received by the simulator is the sending facility_sending application of your system under test.  Once you have found the right patient, click on the magnifying glass you will get the permanent link to this patient; copy and paste it into the comment box of your pre-connectathon test instance. 

Before starting your test, please read the instructions at http://gazelle.ihe.net/content/pre-connectathon-tests/pam

This test requires three patients we will name Patient1, Patient2 and Patient3. According the PAM profile, there is no need for the consumer to be aware of these patients before receiving encounter notifications for them.

This test is divided into two parts:

• section concerning testing of the Patient Encounter Supplier actor
• section concerning testing of the Patient Encounter Consumer actor

Patient Encounter Supplier

You will use the PAM Simulator as a Patient Encounter Consumer. Go to the Patient Encounter/Management/Patient Encounter Consumer page in order to retrieve the configuration (IP address, port, receiving facility/application) of the simulator.

1. Admit patient

1. Within your system, create Patient1 and Patient2. Patient class for both patients needs to be "inpatient" (I). If you are not inspired for creating patient demographics, you can use the Demographic Data Server Gazelle application, or, if your system is also a Patient Demographic Consumer, use the PAM Simulator for receiving patients.
2. For each patient, send a ADT^A01^ADT_A01 message to the simulator in order to admit them as inpatient.
3. Check the simulator has properly received and acknowledged your messages. Copy and paste the permanent link to the test reports into Gazelle Test Management.

2. Register patient

1. Within your system, create Patient3. Patient class for this patient must be "outpatient" (O). 
2. Send a ADT^A04^ADT_A01 message to the simulator to register this patient.
3. Check the simulator has properly received and acknowledged your message. Copy and paste the permanent link to the test report into Gazelle Test Management.

3. Cancel admission

1. Within your system, cancel the admission of Patient1.
2. Send a ADT^A11^ADT_A09 message to notify the simulator of the cancellation of admission for Patient1.
3. Check the simulator has properly received and acknowledged your message. Copy and paste the permanent link to the test report into Gazelle Test Management. 

4. Discharge patient

1. Within your system, end the encounter of Patient2.
2. Send a ADT^A03^ADT_A03 message to notify the simulator of the ending of the encounter for Patient2.
3. Check the simulator has properly received and acknowledges your message. Copy and paste the permanent link to the test report into Gazelle Test Management.

5. Cancel discharge

1. Within your system, cancel the discharge of Patient2.
2. Send a ADT^A13^ADT_A01 message to notify the simulator of the cancellation of discharge for Patient2.
3. Check the simulator has properly received and acknowledged your message. Copy and paste the permanent link to the test report into Gazelle Test Management.

In order to help the connectathon manager with checking this test, go to "All patients" page and retrieve Patient1, Patient2, Patient3. For each of those patients, copy the permanent link and paste it in Gazelle Test Management.

Patient Enconter Consumer

You will use the PAM Simulator as a Patient Encounter Supplier. You may want to log onto the application to easily retrieve the patients/encounter you will create. Go to the Patient Encounter Management/Patient Encounter Supplier page.

1. Admit patient

In this step, you are going to create Patient1 and Patient2 and to admit them as inpatients.

1. Select your system under test in the drop-down menu.
2. Set the category of event to "Admit  inpatient" and the action to perform to "INSERT (A01)"
3. Select the "Generate a patient" option and in the "Patient generation with DDS" panel, select a country and click on the "Generate patient" button.
4. Fill out the encounter showing up below the patient information, do not forget to choose "Inpatient" as patient class.
5. Hit the "Send" button at the bottom of the page and check the simulator receives an acknowledgment from your system.
6. Copy and Paste the permanent link to the test report into Gazelle Test Management. 
7. Hit the "Perform another test" button and redo steps 1 to 6 for admitting Patient2.
8. Take a screenshot of your application that shows a proof of admission of those two patients and upload it into Gazelle Test Management.

2. Register patient

In this step, you are expected to create Patient3 and to register them as outpatient.

1. Select your system under test in the drop-down menu.
2. Set the category of event to "Register  outpatient" and the action to perform to "INSERT (A04)"
3. Select the "Generate a patient" option and in the "Patient generation with DDS" panel, select a country and click on the "Generate patient" button.
4. Fill out the encounter showing up below the patient information, do not forget to choose "Outpatient" as patient class.
5. Hit the "Send" button at the bottom of the page and check the simulator receives an acknowledgment from your system.
6. Copy and Paste the permanent link to the test report into Gazelle Test Management. 
7. Take a screenshot of your application that shows a proof of the registration of this patient and upload it into Gazelle

3. Cancel admission

In this step, you are expected to cancel the admission of Patient1.

1. Select your system under test in the drop-down menu.
2. Set the category of event to "Admit  inpatient" and the action to perform to "CANCEL (A11)"
3. Select Patient1 from the list displayed and cancel his/her admission.
4. Copy and Paste the permanent link to the test report into Gazelle Test Management
5. Take a screenshot of your application that shows a proof of the cancellation of this admission.

4. Discharge patient

In this step, you are expected to discharge Patient2.

1. Select your system under test in the drop-down menu.
2. Set the category of event to "Discharge patient" and the action to perform to "INSERT (A03)"
3. Select Patient2 from the list displayed, then, select the encounter to end. Do not forget to fill out the discharge date/time  before clicking on the "Send" button.
4. Copy and Paste the permanent link to the test report into Gazelle Test Management
5. Take a screenshot of your application that shows a proof that the patient is discharged.

5. Cancel discharge

In this step, your are expected to cancel the discharge of Patient2

1. Select your system under test in the drop-down menu.
2. Set the category of event to "Discharge  patient" and the action to perform to "CANCEL (A13)"
3. Select Patient2 from the list displayed and select the encounter to reopen. Cancel the discharge.
4. Copy and Paste the permanent link to the test report into Gazelle Test Management
5. Take a screenshot of your application that shows a proof that the encounter has been reopened.

In order to help the connectathon manager with checking this test, go to "All patients" page and retrieve Patient1, Patient2, Patient3. For each of those patients, copy the permanent link and paste it in Gazelle Test Management.

The aim of this pre-connectathon test is to check your system under test is able to receive/send the messages exchanged within the ITI-30 (Patient Identification Management) transaction. Here, we are testing your capability to create a new patient, update his/her demographics and identifiers and, depending of the set of options you support, to merge and/or link patient demographic information.

Both actors (Patient Demographic Consumer and Patient Demographic Supplier) will be asked to test against the PAM Simulator. For each step of this test, you are expected to provide the permanent link to the patient sent or received by the simulator and the permanent link to the test report.

You will retrieve the patients the simulator has sent or received under the "All patients" menu. You may want to use the filter to facilitate your search. If you are using the simulator as a PDS or PES, you can log onto the application using the CAS mechanism (use your Gazelle credentials) and easily retrieve the patients you have created within the application by checking the "see only patients created by me" checkbox. If you use the simulator as a PDC or PEC, the creator of the patients received by the simulator is the sending facility_sending application of your system under test.  Once you have found the right patient, click on the magnifying glass you will get the permanent link to this patient; copy and paste it into the comment box of your pre-connectathon test instance. 

The test report is also available through a permanent link. Go to the "HL7 Messages" page and select the message related to the current step, you will be the link to the test report.

Before starting your test, please read the instructions at http://gazelle.ihe.net/content/pre-connectathon-tests/pam

Test definition for Patient Demographic Consumer actor

Test definition for Patient Demographic Supplier actor

Patient Demographic Consumer

You will use the PAM Simulator as a Patient Demographic Supplier. You may want to log onto the application to easily retrieve the patients you will create. You will have to switch among the pages available under the Patient Identification Management/Patient Demographic Supplier menus.

1. Patient creation

In this step, you are expected to send to your simulator two new patients (ADT^A28^ADT_A05 messages). Go to Patient Identification Management/Patient Demographic Supplier/Create new Patient. 

1. Select your system under test in the drop-down menu.
2. Select "generate a patient" option. 
3. Within the "Patient Generation with DDS" panel, set the creation criteria of your choice and click the "Generate patient"  button. If you need your patient to have a specific identifier, then click on the "Modify patient data"  button and go to the Patient's identifiers tab and update the identifiers in a way your system under test will accept the patient.
4. Finally, hit the "Send ADT^A28^ADT_A05" button. 
5. Make sure the simulator receives an ackwnoledgment from your system and that the patient is properly registered in your system.
6. Take a screenshot of your application or your database as a proof of the good registration of the patient. Retrieve the permanent link to the test report and to the patient and copy them in Gazelle Test Management with a comment "Patient creation". This patient will be called Patient1 further.
7. Hit the "Create another patient"  button and redo steps 2 to 5. The aim of this second run is to create another patient who will be used later for merge or link. You only need to enter into Gazelle Test Management the permanent link to this new patient. This patient will be called Patient2 further.

2. Update patient information

In this step, you are expected to update the first name of Patient1 and send the notification to your system under test. Go to Patient Identification Management/Patient Demographic Supplier/ Update patient information.

1. Select your system under test in the drop-down menu.
2. Retrieve patient1 and hit the "update" button in order to edit his/her demographics. Update the first name of this patient and click on the "Send ADT^A31^ADT_A05"  button. 
3. Make sure the simulator receives and acknowledgment from your system and that the patient is properly updated in your system.
4. Take a screenshot of your application or your database as a proof of the good update of the patient. Retrieve the permanent link to the test report and to the patient and copy them in Gazelle Test Management with a comment "Update patient information".

3. Change patient's identifier list

In this step, you are expected to change one of the identifiers of Patient1. Go to Patient Identification Management/Patient Demographic Suppliser/Change patient identifier list.

1. Select your system under test in the drop-down menu
2. Retrieve the patient you have just edited and hit the "update patient identifier list" button.
3. Change one of the identifiers of the patient, for example replace "DDS" by "NW" in the ID part of the identifier (DDS-1234 becomes NW-1234). Click on the "Send ADT^A47^ADT_A30" button.
4. Make sure the simulator receives and acknowledgment from your system and that the patient identifier is properly updated in your system.
5. Take a screenshot of your application or your database as a proof of the good update of the patient. Retrieve the permanent link to the test report and to the patient and copy them in Gazelle Test Management with a comment "Update patient information".

4. Merge patients (if option supported by your SUT)

In this step, you will reuse Patient1 and Patient2 and merge them. Go to Patient Identification Management/Patient Demographic Supplier/Merge patients.

1. Select your system under test in the drop-down menu.
2. Retrieve the two patients to merge. 
3. Drag and drop Patient2 to the first box (Patient with incorrect identifier)
4. Drag and drop Patient1 to the second box (Target patient) and hit the "Send ADT^A40^ADT_A39"  button.
5. Make sure the simulator receives and acknowledgment from your system and that the patients are properly merged within your system (Patient1 must remain).
6. Take a screenshot of your application or your database as a proof of the good merging of the patients. Retrieve the permanent link to the test report and to Patient2 and copy them in Gazelle Test Management with a comment "Update patient information".

5. Link patients (if option supported by your SUT)

In this step, you will reuse Patient1 and Patient2 and merge them. If your SUT supports both merge and link options and if you have already performed step4; please create a third patient to replace Patient2 in this test. Go to Patient Identification Management/Patient Demographic Supplier/Link Unlink patients.

1. Select your system under test in the drop-down menu.
2. Retrieve the patients to link.
3. Drag and drop Patient1 to the first box (Patient One)
4. Drag and drop Patient2 to the second bow (Patient Two) and hit the "Send ADT^A24^ADT_A24" button.
5. Make sure the simulator receives and acknowledgment from your system and that the patients are properly linked within your system.
6. Take a screenshot of your application or your database as a proof of the good merging of the patients. Retrieve the permanent link to the test report and to Patient2 and copy them in Gazelle Test Management with a comment "Update patient information".

Patient Demographic Supplier

You will use the PAM Simulator as a Patient Demographic Consumer. The creator of the patients you will send to the simulator will be set up from the sending facility and application values contained in the received HL7 messages. The configuration of this part of the simulator is available under Patient Identification Management/Patient Demographic Consumer/Configuration and messages.

1. Patient creation

1. Within your system, create two patients. If you are not inspired, you can use the Demographic Data Server application to get demographic data for those patients. First name of the second patient (named Patient2 further, other one will be named Patient1) shall be "Wrong". Note that the simulator accepts patient identifiers from any assigning authority.
2. Send a ADT^A28^ADT_A05 message to the simulator for each of the patients.
3. In the simulator, hit the "Refresh List" button, you may see the messages you have sent to the simulator. Open those messages and copy and paste the permanent link to test report into Gazelle Test Management.
4. Go to the "All patients" page and retrieve the patients you have sent to the simulator. Copy and paste their permanent links into Gazelle Test Management.

2. Update patient information

1. Within your system, change the first name of Patient1 to "Updated".
2. Send a ADT^A31^ADT_A05 message to the simulator to notify the update of Patient1.
3. In the simulator, hit the "Refresh List" button, you may see the message you have sent to the simulator. Open the message and copy and paste the permanent link to test report into Gazelle Test Management.
4. Go to the "All patients" page and retrieve the patient you have updated. Copy and paste its permanent link into Gazelle Test Management.

3. Change patient's identifier list

1. Within your system, update the identifier of Patient1 by prefixing the ID by NW.
2. Send a ADT^A47^ADT_A30 message to the simulator to notify the update of Patient1.
3. In the simulator, hit the "Refresh List" button, you may see the message you have sent to the simulator. Open the message and copy and paste the permanent link to test report into Gazelle Test Management.
4. Go to the "All patients" page and retrieve the patient you have updated. Copy and paste its permanent link into Gazelle Test Management.

4. Merge patients (if option supported by your SUT)

1. Within your system, merge Patient1 and Patient2 in a way that Patient1 remains.
2. Send a ADT^A40^ADT_A39 message to the simulator to notify the merging of those patients.
3. In the simulator, hit the "Refresh List" button, you may see the message you have sent to the simulator. Open the message and copy and paste the permanent link to test report into Gazelle Test Management.
4. Go to "All patients" page and retrieve Patient2. Copy and paste its permanent link into Gazelle Test Management.

5. Link patients (if option supported by your SUT)

1. Within your system, link Patient with Patient2.
2. Send a ADT^A24^ADT_A24 message to the simulator to notify the linking of this patients.
3. In the simulator, hit the "Refresh List" button, you may see the message you have sent to the simulator. Open the message and copy and paste the permanent link to test report into Gazelle Test Management.
4. Go to "Patient Identification Management/Patient Demographic Consumer/Received Patient links and check that the link has been properly created.

This test deals with the subset of trigger events defined for the Inpatient/Outpatient Encounter Management option of ITI-31 transaction. As a reminder, here is the list of events your system must support to fulfill the requirements of this option:

• Pre-admit patient (A05/A38)
• Transfer patient (A02/A12)
• Change inpatient to outpatient (A07)
• Change outpatient to inpatient (A06)

This test is written for both Patient Encounter Supplier and Patient Encounter Consumer, refer to the right section according the actors your system under test supports.

Patient Encounter Supplier

In this test, we check the capability of your system under test to send messages for notifying the PEC actor of new events. You are asked to test against the PAMSimulator. Your first task is to configured your system under test to tell it to send the messages to the PAMSimulator. To do so, retrieve the configuration of the PEC part of the simulator under Patient Encounter Management/Patient Encounter Consumer/Configuration. Do not forgot to select the right character encoding before specifying the port to your system.

1. Initialize test

In this first step, you will feed the PAMSimulator with a new patient and encounter.

1. Create a new patient and a new encounter (patient class = I) within your system
2. Send a ADT^A01^ADT_A01 message to admit the patient
3. Retrieve this patient in the simulator (use the All patients menu) and copy and paste the permanent link to the patient in your pre-connectathon logs.

2. Transfer patient and cancel movement

Once the patient is admitted, we will transfer him/her to a new bed.

1. Within your system, update the bed (PL-3) in the patient location.
2. Send a ADT^A02^ADT_A02 message to the simulator to transfer the patient to this new bed.
3. Check that the simulator acknowledges the message with MSA-1 = AA.
4. Tell your system under test that you have made a mistake and want to cancel the transfer.
5. Send a ADT^A12^ADT_A12 message to cancel the transfer.
6. Check that the simulator acknowledges the message with MSA-1 = AA.
7. Go to HL7 messages menu of the simulator and retrieve the two messages you have sent to the simulator. Copy the permanent links to the test report and paste them in your pre-connectathon logs.

3. Change inpatient to outpatient

In this step, we will change the patient class to outpatient.

1. Within your system, change the patient class to outpatient (code = O)
2. Send a ADT^A07^ADT_A06 message to the simulator to update the patient class
3. Check that the simulator acknowledges the message with MSA-1 = AA.
4. Go to HL7 messages menu of the simulator and retrieve the message you have sent to the simulator. Copy the permanent link to the test report and paste it in your pre-connectathon logs.

4. Change outpatient to inpatient

In this step, we will change back the patient class to inpatient

1. Within your system, put the patient class to inpatient (code = I)
2. Send a ADT^A06^ADT_A06 message to the simulator to update the patient class
3. Check that the simulator acknowledges the message with MSA-1 = AA.
4. Go to HL7 messages menu of the simulator and retrieve the mesage you have sent to the simulator. Copy the permanent link to the test report and paste it in your pre-connectathon logs.

5. Pre-admit the patient for a new encounter and cancel it

This last step is used to check the ability of your system to send a pre-admission notification and its cancellation

1. Within your system, pre-admit the patient for a new encounter planned on May, 20th 2012 at noon.
2. Send a ADT^A05^ADT_A05 message to the simulator to notify it of this new encounter
3. Tell your system under test that you have made a mistake and want to cancel the pre-admission.
4. Send a ADT^A38^ADT_A38 message to cancel the pre-admission.
5. Check that the simulator acknowledges the message with MSA-1 = AA.
6. Go to HL7 messages menu of the simulator and retrieve the two messages you have sent to the simulator. Copy the permanent links to the test report and paste them in your pre-connectathon logs.

Patient Encounter Consumer

In this step, we check the capability of your system under test to act as a Patient Encounter Consumer for the PAM profile, and for the Inpatient/Outpatient Encounter Management option in particular. We want you to demonstrate that your system is able to integrate the notifications received from the PAM Simulator and to correctly acknowledge them.

1. Initialize test

1. Access the PAMSimulator
2. You can log in using CAS if you want to be set as the creator of the patients and encounters you will generate.
3. You may have already registered your system under test within the simulator when performing test #12122.
4. Go to Patient Encounter Management/Patient Encounter Supplier section of the PAM Simulator
5. Create a new patient and a new inpatient encounter (class code = I/Inpatient)  for this patient. Patient's location must be the following:
{syntaxhighlighter brush: as3;fontsize: 100; first-line: 1; }Point of care: Nursing station 1-East Room: Room 10 (1-East) Bed: Aisle Facility: British Hospital{/syntaxhighlighter}
6. Send a ADT^A01^ADT_A01 message to your system under test (refer to test #12122 for detailed informations)
7. Take a screenshot of your application as a proof of the admission of the patient (ensure that the assigned location of the patient is visible)
8. Retrieve this patient in the simulator (use the All patients menu) and copy and paste the permanent link to the patient in your pre-connectathon logs.

2. Transfer patient to new bed and cancel the movement

In this step, we will transfer the patient to a new bed.

1. Go to Patient Encounter Management/Patient Encounter Supplier section of the PAM Simulator
2. From the "category of event" drop-down menu, select Transfer patient
3. From the "action to perform" drop-down list, select INSERT (A02)
4. Select the patient you have previously admitted and update his/her new bed. New patient's location must be the following {syntaxhighlighter brush: as3;fontsize: 100; first-line: 1; }Point of care: Nursing station 1-East Room: Room 10 (1-East) Bed: Middle Facility: British Hospital{/syntaxhighlighter}
5. Click on the send button and check that your system returns an acknowledgement with MSA-1=AA
6. Take a screenshot of your application as a proof of the transfer of the patient (we must see the new location)
7. Click on "Perform another test"
8. From the "action to perform" drop-down list, select CANCEL(A12) and select the patient's encounter you are working on
9. Confirm the movement cancellation to send the ADT^A12^ADT_A12 message to your system under test.
10. Take a screenshot of your application as a proof of the cancellation of the transfer (we must see the previous location)
11. Go to the HL7 messages section of the simulator, retrieve the two previous messages, copy the permanent links to the test report and paste them in your pre-connectathon logs.

3. Change patient class to outpatient

This step is used to change the patient class to outpatient (code = O)

1. Go back to  Patient Encounter Management/Patient Encounter Supplier section of the PAM Simulator
2. From the "category if event" drop-down menu, select Change patient class to outpatient
3. Select the patient/encounter you have previously admitted
4. Edit the informations about the new outpatient encounter and click on "Send message"
5. Check that your system returns an acknowledgement with MSA-1=AA
6. Take a screenshot of your application as a proof of the modification of the patient class
7. Go to the HL7 messages section of the simulator, retrieve the message you have just sent, copy the permanent link to the test report and paste it in your pre-connectathon logs.

4. Change patient class to inpatient

This step is used to change the patient class to inpatient (code = I)

1. Go back to  Patient Encounter Management/Patient Encounter Supplier section of the PAM Simulator
2. From the "category if event" drop-down menu, select Change patient class to inpatient
3. Select the patient/encounter you have previously admitted
4. Edit the informations about the new inpatient encounter and click on "Send message"
5. Check that your system returns an acknowledgement with MSA-1=AA
6. Take a screenshot of your application as a proof of the modification of the patient class
7. Go to the HL7 messages section of the simulator, retrieve the message you have just sent, copy the permanent link to the test report and paste it in your pre-connectathon logs.

5. Pre-admit patient and cancel the pre-admission

In this step, we test the capability of your system to pre-admit a patient and to cancel this pre-admission.

1. Go to Patient Encounter Management/Patient Encounter Supplier section of the PAM Simulator
2. From the "category of event" drop-down menu, select Pre-admit patient
3. From the "action to perform" drop-down list, select INSERT (A05)
4. Select the patient you have previously admitted and create a new encounter for him/her.
5. Click on the "Send message" button and check that your system returns an acknowledgement with MSA-1=AA
6. Take a screenshot of your application as a proof of the pre-admission of this patient
7. Click on "Perform another test"
8. From the "action to perform" drop-down list, select CANCEL(A38) and select the patient's encounter you are working on
9. Confirm the movement cancellation to send the ADT^A38^ADT_A38 message to your system under test.
10. Take a screenshot of your application as a proof of the cancellation of the pre-admission
11. Go to the HL7 messages section of the simulator, retrieve the two previous messages, copy the permanent links to the test report and paste them in your pre-connectathon logs.

This tests the ability of your application to receive an ITI-10 PIX update notification message.  This applies only to PIX Consumers that support the PIX Update Notification option.

This test is performed with the Patient Manager simulator http://gazelle.ihe.net/PatientManager sending ITI-10 messages to your system under test.

Tool documentation is located at http://gazelle.ihe.net/content/patient-manager-user-manual

Test Setup

1. Before starting test steps, please configure the tool to send to your appliction using the SUT Configurations menu in the tool.
2. Go to menu All Patients and, in the drop-down box "Simulated actor", select Patient Identity Cross-Reference Manager.  The page then lists the patients known by the PIX Manager.
3. Choose one of the available patients to use for this test.  You should then manually create that in your system (because this test will send you an update).
   

Test Steps

In these steps, you will use the Patietn Manager tool to send a PIX update notification to your application. 

1. Go to menu PIX --> Patient Identity Cross-Reference Manager --> Cross-references management
2. Check the box entitled "Send update notifications"
3. Select your System under Test in the drop-down menu.
4. Select the list of domains for which you will receive update notifications.
5. From the list of all patients, select the patient you have previously entered within your system. (Use the magnifying glass in the Action column)
6. The "Selected patient" is displayed at the bottom of the page.
7. Next, Drag and drop an identifier from the list of patients above into the 'Selected patient'. This creates a 'cross-reference' between the two patients.  A message is displayed to inform you that a message was sent to your system.
8. Make sure the simulator receives an acknowledgment from your system and that the patient is properly updated in your system.
9. Take a screenshot of your application or your database as a proof of the good registration of the patient. Retrieve the permanent link to the test report and to the patient and copy them in Gazelle Test Management with a comment "Patient creation". 

Evaluation

The screen shots demonstrate that you have successfully processed the received message(s).

This test applies to Patient Demographic Consumers in the PDQ or PDQv3 Profiles.

This test is performed with the Patient Manager simulator http://gazelle.ihe.net/PatientManager acting as a Patient Demographic Supplier responding to these queries.  Note that the test steps are the same no matter the transaction...you will choose the transaction(s) supported by your Consumer.

• ITI-21 and ITI 22 - Patient Demograhics (and Visit) Query (HL7v2) 
• ITI-47 - Patient Demographics Query (HL7v3)

Tool documentation is located at http://gazelle.ihe.net/content/patient-manager-user-manual

Test Setup

1. Go to menu All Patients and, in the drop-down box "Simulated actor", select PDS - Patient Demographic Supplier.  The page then lists the patients known by the PDQ Supplier simulator.
2. Choose one or more of the available patients to use as the target for your query in  this test.  
   

Test Steps

In these steps, you will use the Patient Manager as a Patient Demographics Supplier (PDS) Simulator to respond to your PDQ Query.

1. Access the Patient Manager tool: http://gazelle.ihe.net/PatientManager
2. Go to menu PDQ-->Patient Demographic Supplier
3. Next, select HL7v2 Configuration or HL7v3 Configuration
   
4. The tool will now display the configuration details you will need to query the PDS Simulator.  Ensure the status of the Simulator is "Running"
5. Perform your query.
6. You can use menu HL7 messages to find the query & response captured by the tool.
7. Take a screenshot of your application or your database as a proof of receipt of the query response. Retrieve the permanent link to the transaction instance, and paste that as evidence for this test.
8. If you support more than one transaction (ITI-21, ITI-22, ITI-47), you should repeat these steps for all you support.

Evaluation

The permanent link captures the message exchange. The screen shot demonstrates that you have successfully processed the received query response(s).

This test applies to Patient Demographics Suppliers in the PDQ or PDQv3 Profiles.

This test is performed with the Patient Manager simulator http://gazelle.ihe.net/PatientManager acting as a Patient Demographic Consumer to initiate these queries.  Note that the test steps are the same no matter the transaction...you will choose the transaction(s) supported by your Supplier.

• ITI-21 and ITI 22 - Patient Demograhics (and Visit) Query (HL7v2) 
• ITI-47 - Patient Demographics Query (HL7v3)

Tool documentation is located at http://gazelle.ihe.net/content/patient-manager-user-manual

Test Setup

1. Before starting test steps, please configure the tool to query your Patient Demographics Supplier appliction using the SUT Configurations menu in the tool to enter your configuration parameters.

Test Steps

In these steps, you will use the Patient Manager as a Patient Demographic Consumer (PDC) Simulator to initiate a PDQ Query to your Supplier.

1. Access the Patient Manager tool: http://gazelle.ihe.net/PatientManager
2. Go to menu PDQ-->Patient Demographic Consumer
3. Next, select ITI-21/ITI-22, or ITI-47.
4. In the 'System under test' drop down list, select the entry for your PDQ Consumer
5. Next, enter 'Demographic information' to build a query that will match patient(s) in your Patient Demographic Supplier database.   When you are ready to initiate the query, select the 'Send message' button.
6. You can use menu HL7 messages to find the query & response captured by the tool.
7. Take a screenshot of your application or your database as a proof of receipt of the query response. Retrieve the permanent link to the transaction instance, and paste that as evidence for this test.
8. If you support more than one transaction (ITI-21, ITI-22, ITI-47), you should repeat these steps for all you support.

Evaluation

The permanent link captures the message exchange. The screen shots demonstrate that you have successfully processed the received message(s).

This test applies to initiators of the [ITI-78] Patient Demographics Query for Mobile transaction:  Patient Demographics Consumers in the PDQm or PMIR Profiles.

This test is performed with the Patient Manager simulator https://gazelle.ihe.net/PatientManager acting as a Patient Demographic Supplier to  response to PDQm queries.  

Test step up

The list of patients available on the supplier side are available under the Patients menu. Select "simulated actor" = "PDS" to see which one can be returned in a PDQm query response.

The endpoint to contact is available under menu PDQ* > Patient Demographics Supplier> FHIR configuration.

Evaluation

Verify the conformance of each query issued by your system (blue play icon in the "query" column) and copy the permanent link to the message in your pre-connectathon test in Gazelle Test Management (available from the magnifying glass icon). 

The messages received by the simulator are available under HL7 Messages. To restrict the search, either access the page using the "history" icon on the FHIR Configuration page, either sent the following filters in the search criteria panel:

• Simulated actor = PDS - Patient Demographic Supplier
• Transaction = ITI-78 - Mobile Patient Demographics Query

Steps to execute

Not all the following test cases might be of relevance for your system under test. The purpose of this test is to make sure you correctly implement the portions of the specifications which are of interest for your system (based on the use cases it supports).

Query for a patient pick list

For this first step, we assume that the operator wants to retrieve a list of patients based on some demographics traits. You might want to repeat this step with various combinations of parameters among the following ones to see how the supplier understand your query:

• given and/or family: Partial or complete (exact) patient name (you might have the ability to provide the various given names of the patient)
• identifier: One or more Patient identifiers
• birthdate: Date of birth or age range (your system might allow you to input the exact birth date or a date interval)
• telecom: One or more contact points (phone number, email etc)
• address (or address-city, address-country, address-postalcode, address-state): Partial or complete address
• gender: The gender of the patient
• active: Whether you want to fetch inactive patients as well - By default the simulator will only send back active records if not otherwise requested in the query
• _id: Patient resource's id - The simulator uses the UUID field displayed in the GUI as resource's ID
• mathersMaidenName: Mother's maiden name if your system supports the Pediatric Demographics Option.

For each query, your system should at least display the number of retrieved entries and some of the demographic traits for each entry in the list.

Note that queries with no search parameter will return no entry at all.

Response encoding

If your system supports both JSON and XML encoding, repeat at least once of the previous query with the second encoding so that you can verify that your system correctly set the requested encoded. You might use the HTTP header or the _format query parameter.

Retrieve patient

In addition to the query feature, your system shall support the retrieve patient feature. Choose one patient out of the list and directly retrieve the associated resource by performing the retrieve operation.

Example: https://gazelle.ihe.net/PatientManager/fhir/Patient/UUID.

No Match

Send a new query to your system under test, make sure the query parameters do not match any patient in the tool. Your system is expected to inform the final user that no match has been found.

Query for patient with identifiers in other domains

You must execute the steps below if your system is able to constrain the domains from which patient identifiers are returned from the Patient Demographics Supplier. 

Query with no domain

If you can turn off the domain restriction in your system. First, choose a combination of parameters that will return at least one patient with identifiers in several domains. Under the Connectathon > Patient Demographics menu, you will find the patients that will be pre-loaded by suppliers during the Connectathon; they are also known by the Patient Demographics Supplier implemented in the tool. Each patient has an identifier in at least four domains.

Your system shall receive the patient(s) with identifiers in the IHEBLUE, IHEFACILITY, IHEREF and IHEGREEN domains at least.

Query with a known domain

Reuse the same query parameters as for the previous test but restrict the domain to the IHEBLUE (urn:oid:1.3.6.1.4.1.21367.13.20.3000) domain.

If your query is correctly formatted, the returned patient(s) should only have identifiers with system = urn:oid:1.3.6.1.4.1.21367.13.20.3000.

Query with more than one domain

If your system supports more than one domain, repeat the operation above: constraint the identification domain to IHEBLUE and IHERED (urn:oid:urn:oid:1.3.6.1.4.1.21367.13.20.1000).

Once again, if your query is correctly formatted, the returned patient(s) should only have identifiers with system urn:oid:1.3.6.1.4.1.21367.13.20.3000 and urn:oid:1.3.6.1.4.1.21367.13.20.1000.

Query for an unknown domain

Reuse the same query parameters once again and restrict the domain to urn:oid:1.3.6.1.4.1.21367.13.20.9999999. This domain is unknown from the Patient Demographics Supplier.

If your query is correctly formatted, you should receive HTTP 404 error code with an OperationOutcome resource in which the unknown domain is precised. You might or might not give feedback on such error to the final user. No entry shall be displayed to the user (none will be returned by the Patient Demographics Supplier).

Paging

Execute this step if your system supports the paging mechanism, meaning that it can add the _count parameter to the query. In this step we assume that the user is able to set the number of records to fetch at one time. If your system does not provide this ability (default quantity, or quantity to choose from a list), simply adapt the test data below.

Set search parameters in a way that they will select at least 3 entries (usually given=rob is a good candidate) and ask for only two records at a time. If your query is correctly formatted, the received Bundle should contain only 2 entries and 

• A link to the next results (2 or less);
• A total number of results higher to 2.

Ask for the next batch of results. You should be able to see at least one more patient.

This test applies to responders to the [ITI-78] Patient Demographics Query for Moblie transaction:   Patient Demographics Suppliers in the PDQm Profile or Patient Identity Registry in the PMIR Profiles

This test is performed with the Patient Manager simulator https://gazelle.ihe.net/PatientManager acting as a Patient Demographic Consumer to initiate these queries.  

Test set up

There is no prerequisite in terms of data to be load into your system. As such, choose relevant values for the various parameters based on the patient demographics known by your system under test so that matches are returned.

First of all, register your system under test within the tool as a FHIR Responder under SUT Configurations > FHIR Responders. Make sure to select IHE => ITI-78 (PDQm Consumer) in the list of usages.

Access the Patient Demographics Consumer for PDQm in Patient Manager from menu PDQ* > Patient Demographics Consumer > [ITI-78] Patient Demographics Query FHIR.

Evaluation

Verify the conformance of each response issued by your system (blue play icon in the "response" column) and copy the permanent link to the message in your pre-connectathon test in Gazelle Test Management (available from the magnifying glass icon).  Also verify that the response format expected in the query matches the response format (XML vs JSON) returned by your system. 

Steps to execute

Capability Statement

Upload the capability statement of your system (showing at least the PDQm Supplier features) in the pre-connectathon test in Gazelle Test Management.

Query for a patient pick list

For this first step, we assume that the consumer actor wants to retrieve a list of patients based on some demographics traits. You might want to repeat this step with various combinations of parameters among the following ones to test the behavior of your system:

• Partial or complete patient name (given and/or family)
• One or more Patient identifiers
• Date of birth or age range
• One or more contact points (phone number, email etc)
• Partial or complete address
• Gender
• Whether you want to fetch inactive patients as well

Note that for parameters of type string, "exact" modifier will be added to the query if the wildcard is not used in the field (when valued). If you want to search of patients with a given starting with Ro, enter Ro* in the form.

If your system supports the Pediatric Demographics Option, you might also want to make sure that your system supports the mothersMaidenName search extension.

For this step, you are asked not to modify the default parameters in the "Additional information" section of the page.

Once you have flll out the form, push the "Send message" button. If matches are returned by your system, they will be displayed at the bottom of the page.

After you have retrieved a first batch of patients. You should also be able to use the resource ID search parameter (_id). You can find the value to use in the response returned by your system in Bundle.entry.resource.Patient.id.value.

Response encoding

Your system under test shall be able to support at least both JSON and XML encodings. Previous step has been executed using "XML" as format to be returned. Return the step above at least one but select Response format = json before sending the message to your system.

Retrieve patient

Access the detail of the response content and for one of the entries, access the URL displayed in field entry.fullUrl.value. You should retrieve the content of the Patient resource.

No Match

Send a new query to your system under test, make sure the query parameters do not match any patient in your database. Your system is expected to send back a Bundle resource with Bundle.total.value = 0.

Query for patient with identifiers in other domains

In this step, we focus on the domain restriction feature. We assume that your system manages at least one domain for patient identification.

Query with no domain

First, choose a combination of parameters that will return at least one patient. If your system supports multiple identifier domains, make sure the returned patients will show at least identifiers from two different domains. DO NOT restrict the search to a particular domain. We are interested in knowing what are the identifiers known for this patient.

Query with a known domain

Repeat the search below but in the "Additional information" section, add the identifier of one of the domains for which the returned patient has a PID assigned. Click on "Add domain to list" for the tool to take the value into account.

Your system is expected to return the patients that are a PID assigned to this domain, only one PID shall appear for each of them.

Query with more than one domain

If your system supports more than one domain, repeat the operation above to add a second domain in the list of domains that are returned.

Once again, your system is expected to return the patients with PID in the mentioned domains. No other PID shall be returned.

Query for an unknown domain

Repeat the test but first clean up the list of domains to return and add "1.3.6.1.4.1.21367.13.20.9999"  instead (this domain might not be known by your system, otherwise choose another value).

No entry shall be returned. Refer to section 3.78.4.1.3 / Case 4 for details on the expected response (Code HTTP 404 with OperationOutcome or HTTP 200 with no content).

Paging

The Patient Demographics Supplier shall represent the incremental responses as specified in FHIR Paging. 

Empty the query form and enter parameters that will allow your system to match more than two patients. 

In the "Additional information" section, check the box for option "Limit number of responses" and set the limit value to "1".

Click on "Send message", the tool shall display the single entry that is returned by your system and the following message "More results are available on supplier side". As for the other steps, copy the link to this message in Gazelle Test Management.

Click on "Get next results".

In the "Returned patients" section, the number of pages increases. A single patient is displayed.

This test applies to Patient Identity Consumers who initiate queries in the PIX, PIXv3, PIXm, or PMIR Profiles.

This test is performed with the Patient Manager simulator http://gazelle.ihe.net/PatientManager acting as a Patient Identity Cross-Reference Manager (PIX Manager) responding to these queries.  Note that the test steps are the same no matter the transaction...you will choose the transaction(s) supported by your Consumer.

• ITI-9- PIX Query (HL7v2) 
• ITI-45 - PIX Query (HL7v3)
• ITI-83 - PIXm Query (HL7 FHIR®©)

Tool documentation is located at http://gazelle.ihe.net/content/patient-manager-user-manual

Test Setup

1. Go to menu All Patients and, in the drop-down box "Simulated actor", select PAT_IDENTITY_X_REF_MANAGER.  The page then lists the patients known by the PIX Manager simulator.
2. Choose one or more of the available patients to use as the target for your query in  this test.  
   

Test Steps

In these steps, you will use the Patient Manager as a PIX Manager Simulator to respond to your PIX Query.

1. Access the Patient Manager tool: http://gazelle.ihe.net/PatientManager
2. Go to menu PIX-->Patient Identity Cross-Reference Manager
3. Next, select HL7v2 Configuration, HL7v3 Configuration, or FHIR Configuration
4. The tool will now display the configuration details you will need to query the PIX Manager Simulator.  Ensure the status of the Simulator is "Running"
5. Perform your query.
6. You can use menu HL7 messages to find the query & response captured by the tool.
7. Take a screenshot of your application or your database as a proof of receipt of the query response. Retrieve the permanent link to the transaction instance, and paste that as evidence for this test.
8. If you support more than one transaction (ITI-9, ITI-45, ITI-83), you should repeat these steps for all you support.

Evaluation

The permanent link captures the message exchange. The screen shot demonstrates that you have successfully processed the received query response(s).

This test applies to Patient Identifier Cross-Reference Managers (PIX Managers) in the PIX, PIXv3, PIXm, or PMIR Profiles.

This test is performed with the Patient Manager simulator http://gazelle.ihe.net/PatientManager acting as a PIX Consumer to initiate these queries.  Note that the test steps are the same no matter the transaction...you will choose the transaction(s) supported by your Supplier.

• ITI-9 - PIX Query (HL7v2) 
• ITI-45 - PIX Query (HL7v3)
• ITI-83 - PIXm Query (HL7 FHIR®©)

Tool documentation is located at http://gazelle.ihe.net/content/patient-manager-user-manual

Test Setup

1. Before starting test steps, please configure the tool to query your PIX Manager application using the SUT Configurations menu in the tool to enter your configuration parameters.

Test Steps

In these steps, you will use the Patient Manager as a PIX Consumer Simulator to initiate a PIX Query to your PIX Manager

1. Access the Patient Manager tool: http://gazelle.ihe.net/PatientManager
2. Go to menu PIX-->Patient Identity Consumer
3. Next, select ITI-9, or ITI-45, or ITI-83
4. In the 'System under test' drop down list, select the entry for your PIX Manager
5. Next, enter values for the Query parameters (eg for Patient ID and assigning authority) to build a query that will match patient(s) in your PIX Manager database.   When you are ready to initiate the query, select the 'Send message' button.
6. You can use menu HL7 messages to find the query & response captured by the tool.
7. Retrieve the permanent link to the transaction instance, and paste that as evidence for this test.
8. If you support more than one transaction (ITI-9, ITI-45, ITI-83), you should repeat these steps for all you support.

Evaluation

The permanent link captures the message exchange. 

This tests the ability of your application to receive RAD-1 and RAD-12 patient registration and update messages.

This test is performed with the Patient Manager simulator http://gazelle.ihe.net/PatientManager sending messages to your system under test.

Tools documentation is located at http://gazelle.ihe.net/content/patient-manager-user-manual

Before starting your tests, please configure the tool to send to your appliction using the SUT Configurations menu in the tool.

Test Steps

1. Patient creation

In this step, you are expected to send a new patient to your application .

1. Go to menu ADT-->[RAD-1] Patient Registration. 
2. Select your System under Test in the drop-down menu.
3. Select the Category of Event and Action to perform to initiate an AO1, A04 or A00
4. Select the "generate patient" option. 
5. Within the "Patient Generation with DDS" panel, set the creation criteria of your choice and click the "Generate patient"  button. If you need your patient to have a specific identifier, then click on the "Modify patient data"  button and go to the Patient's identifiers tab and update the identifiers in a way your system under test will accept the patient.
6. Finally, hit the "Send" button. 
7. Make sure the simulator receives an acknowledgment from your system and that the patient is properly registered in your system.
8. Take a screenshot of your application or your database as a proof of the good registration of the patient. Retrieve the permanent link to the test report and to the patient and copy them in Gazelle Test Management with a comment "Patient creation". 

2. Update patient information

In this step, you are expected to update the first name of the new and send the notification to your system under test.

1. Go to menu ADT-->[RAD-12] Patient Update
2. Select your system under test in the drop-down menu.
3. Select the Category of event to be Update Patient Information
4. Select the patient you just created 
5. Change the patient's first name.  Then hit the Send  button
   
6. Make sure the simulator receives and acknowledgment from your system and that the patient is properly updated in your system.
7. Take a screenshot of your application or your database as a proof of the good update of the patient. Retrieve the permanent link to the test report and to the patient and copy them in Gazelle Test Management with a comment "Update patient information".

Evaluation

The screen shots demonstrate that you have successfully handled the received ADT messages.

This test applies to the XCPD Initiating Gateway actot that supports the Deferred Response Opiton.  See ITI TF-1: 27.2.2 and ITI TF-2b: 3.55.6.2.

This test is performed with the Gazelle Patient Manager simulator: https://gazelle.ihe.net/PatientManager 

See also the User Manual for testing XCPD with the Patient Manager here.

Instructions

The instructions for this test are detailed in the User Manual for the Patient Manager tool, so they are not repeated here. See:  https://gazelle.ihe.net/gazelle-documentation/Patient-Manager/user.html#deferred-response-on-initiating-gateway

Evaluation

After you perform the test, the Patient Manager tool will produce a Test Report.  Copy the Permanent Link to to Test Report, then paste that link into Gazelle Test Management as the results for this test.

The basline requirements of the XCPD profile do not require the actors to also implement XUA; however, this test enables you to test your XCPD Initiating Gateway actor that also support XUA X-Service User

This test is performed with the Gazelle Patient Manager simulator: https://gazelle.ihe.net/PatientManager 

See also the User Manual for testing XCPD with the Patient Manager here.

Instructions

The instructions for this test are detailed in the User Manual for the Patient Manager tool, so they are not repeated here. See the instructions for XUA over XCPD for the X-Service User here: https://gazelle.ihe.net/gazelle-documentation/Patient-Manager/user.html#xua-over-xcpd

Evaluation

After you perform the test, find your result in the Patient Manager tool under menu XUA >  X-Service User logs.  Copy. the URL for your result and paste it into Gazelle Test Management as the result for this test.

This test applies to the XCPD Responding Gateway actot that supports the Deferred Response Opiton.  See ITI TF-1: 27.2.2 and ITI TF-2b: 3.55.6.2.

This test is performed with the Gazelle Patient Manager simulator: https://gazelle.ihe.net/PatientManager 

See also the User Manual for testing XCPD with the Patient Manager here.

Instructions

The instructions for this test are detailed in the User Manual for the Patient Manager tool, so they are not repeated here. See: https://gazelle.ihe.net/gazelle-documentation/Patient-Manager/user.html#deferred-response-on-responding-gateway

Evaluation

After you perform the test, the Patient Manager tool will produce a Test Report.  Copy the Permanent Link to to Test Report, then paste that link into Gazelle Test Management as the results for this test.

The baseline requirements of the XCPD profile do not require the actors to also implement XUA; however, this test enables you to test your XCPD Responding Gateway actor that also support XUA X-Service Provider

This test is performed with the Gazelle Patient Manager simulator: https://gazelle.ihe.net/PatientManager 

See also the User Manual for testing XCPD with the Patient Manager here.

Instructions

The instructions for this test are detailed in the User Manual for the Patient Manager tool, so they are not repeated here. See the instructions for XUA over XCPD for the X-Service Provider here:  https://gazelle.ihe.net/gazelle-documentation/Patient-Manager/user.html#xua-over-xcpd

Evaluation

After you perform the test, find your result in the Patient Manager tool under menu XUA >  X-Service Provider logs.  Copy. the URL for your result and paste it into Gazelle Test Management as the result for this test.

This test will be performed against the Order Filler part of the OrderManager Gazelle simulator. Here, we are only checking the initiator part of the Order Placer; that means that, in this test, your system is only asked to send messages to the simulator to create and cancel orders. The receiver part of the Order Placer (used to receive notifications from the Order Filler) is tested in the test #30002.

First step to perform: retrieve the configuration of the Order Filler to which send messages: 

1. Go to the OrderManager simulator
2. Log onto the application using the CAS login (it uses your Gazelle -European instance- credentials)
3. Select the Laboratory domain (bottom-right drop-down menu)
4. Go to Order Management --> Order Filler --> Order Filler configuration
5. Select the character set encoding you will use to send messages to the simulator and enter the given configuration within your Order Placer.

Pre-requisites

The LAB-1 (Lab Placer Order Management) transaction defines three structures of messages (OML^O21^OML_O21, OML^O33^OML_O33, OML^O35^OML_O35). As an initiator in this test, you are free to use the structure  your system under test supports. Please, add a comment into the pre-connectathon test instance you have started to tell us which structures your system uses.

Your Order Placer is assumed to be coupled with a PAM actor, that means that you should be able either to enter a new patient/encounter into your system or to receive a new patient/encounter from a PAM/PDS or PAM/PES actor. If you need to populate your system with a patient and encounter using an external system, you are free to use the PAMSimulator tool to do so.

Order creation

1. Enter a new order within your system under test
2. Send a message to the Order Filler part of the simulator. ORC-1 must be valued with "NW".
3. Go to the "HL7 messages" part of the simulator and retrieve the message you have sent. Click on the message id (left-hand column) to get its permanent link and the validation result.
4. Copy and Paste the "permanent link to the test report" into Gazelle
5. Go to Browse Data/All orders and retrieve the order you have sent. Copy and paste its permanent link into Gazelle

Order cancellation

1. Within your system, cancel the previous order and send the notification to the simulator. ORC-1 must be valued with "CA".
2. Go to the "HL7 messages" part of the simulator and retrieve the message you have sent. Click on the message id (left-hand column) to get its permanent link and the validation result.
3. Copy and Paste the "permanent link to the test report" into Gazelle

The purpose of this test is checking that the Order Placer is able to integrate messages received from the Order Filler in the context of the LAB-2 (creation of new orders) and LAB-1 (cancellation and status updates) transactions. We will also check that the acknowledgements are properly built.

Pre-requisites

Before beginning this test, do not forgot to check that the configuration (IP address, port, application/facility names) of your system under test is enter within the simulator. 

Your Order Placer is assumed to be coupled with a PAM actor, that means that you should be able either to enter a new patient/encounter into your system or to receive a new patient/encounter from a PAM/PDS or PAM/PES actor. If you need to populate your system with a patient and encounter using an external system, you are free to use the PAMSimulator tool to do so. The Order Manager must also know this patient/encounter, to share the patient between the PAMSimulator and the Order Manager tools, read the tutorial available here. If you have already performed the test #30001, you can use the same patient.

We strongly recommend to read the tutorial available here.

1. Assign a number to an order created by the Order Filler (LAB-2)

In this step, you show the ability of your Order Placer to accept the creation of orders by the laboratory (ORC-1 = "SN") and to assign placer order numbers to these orders. The acknowledgement message (ORL of the corresponding message structure, with ORC-1="NA") must carry the placer order number (ORC-2).

As a receiver in this test, your Order Placer shall be able to integrate all of the three message structures defined in the technical framework. As a consequence, you are asked to perform this step three times.

1. Go to Order management --> Order Filler --> Notify order placer of orders
2. Select your system under test in the drop-down list
3. Select "Create a new order" as action to perform
4. Select one of the three message structures
5. Select the patient for whom you want to create a new laboratory order
6. Fill the order and click on the "send message" button
7. Retrieve the permanent link to the test report and paste it in Gazelle.
8. Take a screenshot of your application as a proof of the good integration of the message. Upload it in Gazelle.
9. Play this step again with another message structure

2. Integrate the cancellation of an order on the laboratory initiative (LAB-1)

In this step, you show the ability of your Order Placer to intefration te cancellation of orders by the laboratory (ORC-1="OC") and to acknowledge it (ORL of the corresponding message structure, with ORC-1 = "OK")

1. Go to Order management --> Order Filler --> Notify order placer of orders
2. Select your system under test in the drop-down list
3. Select "Cancel an existing order" as action to perform
4. Select the message structure to use
5. Select the laboratory order to cancel and when the pop-up raises, click on the "Yes" button.
6. Retrieve the permanent link to the test report and paste it in Gazelle
7. Take a screenshot of your application as a proof of the good integration of the message. Upload it in Gazelle.

3. Integration an order status change notified by the Order Filler (LAB-1)

In this step, you show the ability of your Order Placer to integrate a change of status of an order (OBR-25 must change of calue, this must be visible in your application screenshot), notified by the Order Filler (ORC-1="SC") and to acknowledge it (ORL of the corresponding message structure, witch ORC-1 = "OK")

1. Go to Order management --> Order Filler --> Notify order filler of orders
2. Select your system under test in the drop-down list
3. Select "Update order status" as action to perform
4. Select the message structure to use
5. Select the laboratory order to update and when the pop-up raises, select the new status and click on the "Send update notification" button.
6. Retrieve the permanent link to the test report  and paste it in Gazelle
7. Take a screenshot of your application as a proof of the good integration of the message. Upload it in Gazelle