This is not an actual test, but we want to ensure you find and readthe web page with general information about ATNA testing for Connectathons.

Instructions

Please read the ATNA Testing & digital certificates for IHE Connectathons 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 your local gazelle as the Log Return file for pre-Connectathon test 11099.

Overview of the test

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

If you have not tested at an IHE Connectathons in since 2018, and your system performs transactions over TLS, you **MUST GENERATE A NEW DIGITAL CERTIFICATE**.  Digital Certificates from previous years will not work at Connectathons in 2019 and later.

Prerequisite for this test

(1) If you have not yet read this ATNA Testing Resources page, please do that before proceeding with this test.  That page contains important content for using the digital certificates for pre-Connectathon and Connectathon tests.  The instructions below only tell you how to generate a digital certificate.

(2) When you generate your digital certificate, you will need to know two values:

1. The hostname of your test system on the Connectathon network.  This is assigned to your test system in the European Gazelle or North American Gazelle for Test Management.  To find the hostname for your test system, log into Gazelle Test Management, then select menu Configurations-->System configuration.
2. The Domain Name of the Connectathon network.  For the NA 2020 Connectathon, it is ihe-us-test.net. For the EU 2020 Connectathon, it is ihe-europe.net (to be confirmed).
   

Location Gazelle Security Suite (GSS) tool:

• For European and North American Connectathons: http://gazelle.ihe.net/gss

Log in to the tool

There are separate CAS systems for European and North American Connectathons.  The European CAS is linked to http://gazelle.ihe.net/EU-CAT/ and the North American CAS is linked to https://gazelle.iheusa.org/gazelle-na/.   You will use your username & password from Gazelle for either the European or NA Connectathon:

• On the tool 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 the European or North American instances of Gazelle Test Management linked above
• If you don't have an account, you can create a new one via login page on the European Gazelle or North American Gazelle for Test Management.

Instructions - Obtain a Certificate

• Select menu PKI-->Request a certificate
• Complete the fields on page:
• Certificate type:  Choose "Client and Server" from dropdown list  (Required field)
• key size: (optional)
• Country (C): (required)
• Organization (O):  Your organization name in Gazelle   (Required field)
• Common Name (CN):  The Keyword for your test system in Gazelle (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: <=== New at Connectathons in 2019 & later.  
• You must enter at least one value in this field -- the fully-qualified domain name of your test system on the Connectathon network.  This is a combination of the hostname assigned in Gazelle to your system and the domain name for the Connectathon test network.  For the 2019 NA Connectathon network, the domain name is ihe-us-test.net.  So, an example of a fully-qualified domain name entered in this field for a digital certificate for the NA Connectathon is acme0.ihe-us-test.net
• You may optionally enter more than one value.  Multiple values are separated by a comma.  These values will be additional fully-qualified domain name(s) for your test system that is operating in a non-Connectathon environment with a different domain name, eg you are testing with the NIST XDS Tools in your home test lab. 
• 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 the tool)
• 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
• 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 your local gazelle as the Log Return file for pre-Connectathon test 11100.

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

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 capabilities of your test system during the Connectathon.

The contents of your ATNA Questionnaire are directly linked to the profiles and actors that you have registered to test at a given Connectathon.  You will be asked to validate audit messages for transactions you support.  You will be asked to demonstrate successful TLS connections for the transports you support (eg DICOM, MLLP, HTTP).

Prerequisite for this test

Before you can generate your on-line ATNA questionnaire...

• You must have a test system registered in Gazelle Test Management for the upcoming NA or EU Connectathon
• Your test system must be registered to test an ATNA actor, eg. Secure Node, Secure Application, Audit Record Repository...
• Your test system must have a status of "Completed"
• 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 the NA or EU Gazelle Test Management. Select menu Registration->Manage Systems.
• On the System summary for your system, is the Registration Status set to "Completed"?

Location of the ATNA Tools:  Gazelle Security Suite

• For Europe and North America: http://gazelle.ihe.net/gss

Log in to the tool

There are separate CAS systems for European and North American Connectathons.  The European CAS is linked to http://gazelle.ihe.net/EU-CAT/ and the North American CAS is linked to https://gazelle.iheusa.org/gazelle-na/.   You will use your username & password from Gazelle Test management for either the European or NA Connectathon:

• On the tool 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 the European or North American instances of Gazelle Test Management linked above
• If you don't have an account, you can create a new one via login page on the European Gazelle or North American Gazelle for Test Management.

Important note:  Because the contents of your ATNA Questionnaire is linked to your Connectathon test system in Gazelle for EU or Gazelle for NA, your user account in gazelle must be working in the current testing session.  Use menu Gazelle--> Change Testing Session.

Instructions

1. 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 column to:

View the content of the questionnaire

• Edit it
• Review it (monitors only)
• Delete it (administrators 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.

7. Finally, create a text file stating that your questionnaire is ready for review. Upload that text file into your local gazelle as the Log Return file for pre-Connectathon test 11106.

Evaluation

Although we encourage you to complete your ATNA Questionnaire before you arrive at Connectathon, it is the Connectathon monitors who will review and verify your form *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.

Prerequisite for this test

(1) If you have not yet read the ATNA Testing Resources page, do that before proceeding with this test.

(2) To perform this test, your Connectathon digital certificates 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).

Overview of the test

In this test, you will use the Gazelle Security Suite (GSS) tool to verify that you are able to communicate with TLS clients and servers using digital certificates.   In particular, you will ensure that you can configure your test system to make connections using the TLS configuration used during Connectathon week:

• TLS v1.2
• TLS_RSA_WITH_AES_128_CBC_SHA cipher
• digital certificate issued by the GSS tool

The GSS tool contains multiple client and server simulators.  The table below identifies which simulators are used in this test.  (Other simulators are used in test 11109).

Log in to the GSS tool

There are separate CAS systems for European and North American Connectathons.  The European CAS is linked to http://gazelle.ihe.net/EU-CAT/ and the North American CAS is linked to https://gazelle.iheusa.org/gazelle-na/.   You will use your username & password from Gazelle Test Management for either the European or NA Connectathon:

• On the tool 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 the European or North American instances of Gazelle linked above
• If you don't have an account, you can create a new one via login page on the European Gazelle or North American Gazelle for Test Management.

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. 

2. Select the "Server RAW TLS 1.2 Connectathon" simulator, and then configure your client to connect to that 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. You may choose any protocol (HL7v2, webservices, DICOM...).  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 timestamped entry in the results list at the bottom of the page.   Blue dot means OK, red NOT OK.

6. When you make a successful connection, view the result with the icon in the "Action" column.  Copy the Permanent Link (URL) to as the result for pre-Connectathon test 11108 in Gazelle Test Management. The link must be formatted like https://.../connection.seam?id=...

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. Select the "Client RAW TLS 1.2 Connectathon" simulator.

3. In the "Start  Connection" section of the page, you will have to specify :

• Client type : protocol supported (you may choose one of... HL7, DICOM, WS, SYSLOG, or RAW)
• Target host : public IP of your server
• Target port : public port of your server

4. Then click on "Start client".

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

6. When you make a successful connection, view the result with the icon in the "Action" column.  Copy the Permanent Link (URL) to as the result for pre-Connectathon test 11108 in Gazelle Test Management. The link must be formatted like https://.../connection.seam?id=...

 Evaluation 

The tool reports success or failure for each test you perform.  Your test system must demonstrate successful TLS handshake for the configuration used at the Connectathon

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

Prerequisite for this test

(1) If you have not yet read the ATNA Testing Resources page, do that before proceeding with this test.

(2) To perform this test, your Connectathon digital certificates 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 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.0 or TLS v1.2, including protocol (DICOM, HL7/MLLP, HTTPS/WS, or syslog)
• cipher suite (TLS_RSA_WITH_AES_128_CBC_SHA, 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:

Log in to the GSS tool

There are separate CAS systems for European and North American Connectathons.  The European CAS is linked to http://gazelle.ihe.net/EU-CAT/ and the North American CAS is linked to https://gazelle.iheusa.org/gazelle-na/.   You will use your username & password from Gazelle Test Management for either the European or NA Connectathon:

• On the tool 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 the European or North American instances of Gazelle linked above
• If you don't have an account, you can create a new one via login page on the European Gazelle or North American Gazelle for Test Management.

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 (TLS 1.2 Floor...).

• You will test only the protocols you support -- those listed on the "TLS Tests" tab of your ATNA questionnaire.
• You may choose either the TLS 1.0 or TLS 1.2 servers.  You don't need to use all for this test (but you may choose to do so).

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 timestamped 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.
• You may choose either the TLS 1.0 or TLS 1.2 client.  You don't need to use both for this test (but you may choose to do so).
• 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 

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 a Connectathon, a Connectathon monitor will verify your results as follows. The monitor will:

1. Access the TLS tests tab in the ATNA questionnaire.  You will only do the tests for the protocols your test system supports, and skip the ones you don't support.
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 of the test

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

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

Prerequisite for this test

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

Location of the ATNA Tools:  Gazelle Security Suite

• For Europe and North America: http://gazelle.ihe.net/gss

Log in to the tool

There are separate CAS systems for European and North American Connectathons.  The European CAS is linked to http://gazelle.ihe.net/EU-CAT/ and the North American CAS is linked to https://gazelle.iheusa.org/gazelle-na/.   You will use your username & password from gazelle for either the European or NA Connectathon:

• On the tool 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 the European or North American instances of Gazelle Test Management linked above
• If you don't have an account, you can create a new one via the login page on the European Gazelle or North American Gazelle for Test Management.

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 the chat window in gazelle for pre-Connectathon test 11110 or Connectathon test ATNA_Authenticate_Error_Cases

Evaluation

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 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

• For Europe and North America: http://gazelle.ihe.net/gss

Log in to the tool

There are separate CAS systems for European and North American Connectathons.  The European CAS is linked to http://gazelle.ihe.net/EU-CAT/ and the North American CAS is linked to https://gazelle.iheusa.org/gazelle-na/.   You will use your username & password from Gazelle Test Management for either the European or NA Connectathon:

• On the tool 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 the European or North American instances of Gazelle Test Management linked above
• If you don't have an account, you can create a new one via the login page on the European Gazelle or North American Gazelle for Test Management.

Instructions

You may perform this test directly in the ATNA Questionnaire **or** you may use the Gazelle EVSClient tool.  If you are preparing for a 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 connectathon 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.   You should validate all messages that you have marked "Implemented".
3. 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 pre-Connectathon test 11116, and change the status of the test to "Verified by vendor".  

---->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 pre-Connectathon test 11116, and change the status of the test to "Verified by vendor".

Evaluation

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

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)

• For Europe and North America: http://gazelle.ihe.net/gss

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 pre-Connectathon 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.

.

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 2020 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:  Expected by Dec 31, 2019: 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

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

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

Connectathon-related Considerations

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

• If you are an Image Display actor in the MAMMO, SMI or DBT profile, please plan to bring a diagnostic-quality monitor and a photometer to the Connectathon. The test managers do not provide a photometer on-site.
• If you are testing the CPI profile, as an alternative to shipping a monitor to the Connectathon, please perform the calibration in your home lab as described below. Record a video of the calibration task as performed in your lab and bring it 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.

Testing Instructions

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

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

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: http://gazelle.ihe.net/EVSClient
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. If you are performing a pre-Connectathon test in gazelle, paste the Permanent links to your results into the comment field, instead of uploading a log file.
4. Change the status of the test to Verified by vendor
   
   

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:  ITITF-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: http://gazelle.ihe.net/EVSClient
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. If you are performing a pre-Connectathon test in gazelle, paste the Permanent links to your results into the comment field, instead of uploading a log file.
4. Change the status of the test to Verified by vendor
   
   

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

In this test, Acquisition Modality & 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.

You must evaluate and provide the output for at least one DICOM Composite Object using '''one'' of the available validation tools (your choice).  One or more of these tools may be available from within the Gazelle EVSClient.  (Note:  The links below are for resource pages for each tool.)

• dicom3tools from David Clunie
• dcm4che
• PixelMed DoseUtility for Dose SRs (REM Profile)
• dcmcheck from OFFIS

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 of Gazelle Test Management, or (2) directly in the EVSClient 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 (eg Gazelle NA or Gazelle EU) and log in.
2. Select menu Connectathon-->Connectathon-->List of samples
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 EVSClient.

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

1. Access the Gazelle EVS Client: http://gazelle.ihe.net/EVSClient
2. Select menu IHE-->DICOM-->DICOM validation
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-->Validated DICOM objects)
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. For this pre-Connectathon test, instead of uploading a log file, you will paste the Permanent link to your results.  Copy either  the permanent link to your sample or the permanent link to your results in the EVSClient and paste it into the comment field of the EVS_DICOM_Object_Evaluation test instance in Gazelle Test Management. (This is also where you can comment on the results of the validation.)  
2. Change the status of the test to Verified by vendor

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. If you are performing a pre-Connectathon test in gazelle, paste the Permanent link to your results into the comment field, instead of uploading a log file.
4. Change the status of the test to Verified by vendor
   
   

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

First access the Gazelle EVSClient tool: https://gazelle.ihe.net/EVSClient/home.seam

• Log in to the tool:  There are separate CAS systems for European and North American Connectathons.  The European CAS is linked to http://gazelle.ihe.net/EU-CAT/ and the North American CAS is linked to http://ihe.wustl.edu/gazelle-na/.   You will use your username & password from Gazelle for either the European or NA Connectathon:
• On the tool home page, 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 the European or North American instances of gazelle linked above
• If you don't have an account, you can create a new one via login page on the European Gazelle or North American Gazelle for Test Management. 

Perform the validation:

1. In the Gazelle EVSClient, select menu IHE-->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.
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 pre-Connectathon test 'EVS_SOLE_Event_Report_Check', and change the status of the test to "Verified by vendor".

Evaluation

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

This tests the request in the RAD-55 transaction in the XDS-I.b profile

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

• 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 EVS Client user interface, select menu IHE-->DICOMWeb-->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 ), please refer to this documentation of EVSClient WADO validation.

Evaluation

• The EVS Client creates a Permanent link to your results
• For this pre-Connectathon test in gazelle, paste the Permanent links to your results into the comment field, instead of uploading a log file.
• Change the status of the test to Verified by vendor

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 gazelle's XDW Validator to verify your Workflow Document.

Finally, you will upload your sample document into gazelle so that Content Consumers can access your sample and test with it prior to the Connectathon.  We ask you to upload your sample two weeks in advance of the pre-Connectathon test deadline to give Consumers time to test with your document.

Instructions

For this pre-Connectathon 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 your sample into gazelle & run the validation:

• Log into gazelle.
• Select menu:  Connectathon / List of Samples
• 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: http://gazelle.ihe.net/EVSClient
• 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
• For this pre-Connectathon test in gazelle, paste the Permanent links to your results into the comment field, instead of uploading a log file.
• Change the status of the test to Verified by vendor

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

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 to validate your updated document.  

Finally, you will upload your 'updated' Workflow Document into gazelle as a sample.   We ask you to upload your sample two weeks in advance of the pre-Connectathon test deadline to give Consumers time to test with your document.

Instructions

For this pre-Connectathon 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 sample into gazelle & run the validation:

• Log into gazelle.
• Select menu:  Connectathon / List of Samples
• 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: http://gazelle.ihe.net/EVSClient
• 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 validation service creates a Permanent link to your results
• For this pre-Connectathon test in gazelle, paste the Permanent links to your results into the comment field, instead of uploading a log file.
• Change the status of the test to Verified by vendor

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

At the Connectathon, the HPD tests assume that a pre-defined set of Organizational and Individual provider information has been loaded on all of the Provider Information Directory actors under test.

Instructions

• Prior to the Connectathon, you must load this provider test data into your HPD Provider Information Directory:
• Connectathon tests depend on the presence of this test data: ftp://ftp.ihe.net/Connectathon/test_data/ITI-profiles/HPD-test-data/HPD_test_providers.xls
• We expect that your Directory will also contain other provider information, beyond what is in this test set.

Evaluation

There are no result files to upload into gazelle for this test.  Preloading these prior to the Connectathon is intended to save you precious time during Connectathon week.

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 pre-Connectathon results to upload for this test.

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

Instructions

Access the LBL Simulator tool at this location : LBL Simulator
If it is your first time with this tool, please read the user manual : LBL Simulator 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 "Simulators" menu entry and choose "LIP" page to begin the test. Select the "LAB-61 Transaction" tab.
3. In the SUT Configurations drop-down list, select the SUT configuration.
4. Once you have selected the patient, hit the "Send" button. The LBL 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. You will need to communicate with the LBL Simulator, in order to simulate
the LAB-61 transaction of the LBL Profile.

Instructions

Access the LBL Simulator tool at this location : LBL Simulator
If it is your first time with this tool, please read the user manual : LBL Simulator 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 the implements the LIP (LIP acts as an initiator in this test) :

1. Don't need to create a SUT configuration for your system. Just go to the "Simulators" menu entry and choose "LB" page to begin your test.
2. Select the "LAB-61 Transaction" tab.
3. In the charset drop-down list, select the desired charset.
4. Use the Ip Address and the Port linked to this charset to send your message with the labeling instructions to the LBL Simulator.
5. Don't forget to hit the "Refresh List" button after to have send your message.
6. 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 : LBL Simulator
If it is your first time with this tool, please read the user manual : LBL Simulator 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 "Simulators" menu entry and choose "LB" page to begin your test.
3. Select the "LAB-62 Transaction" tab. 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 : LBL Simulator
If it is your first time with this tool, please read the user manual : LBL Simulator 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. Don't need to create a SUT (System Under Test) configuration for your system. Just go to the "Simulators" menu entry and choose "LIP" page to begin your test.
2. Select the "LAB-62 Transaction" tab. 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 LBL Simulator.
4. Don't forget to hit the "Refresh List" button after to have send your message.

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. You will need to communicate with the LBL Simulator, in order to simulate the LAB-63 transaction of the LBL Profile.

In this test, the Label Broker notify 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.
• Second, the LBL Simulator will notify the SUT for the effective labels printing and labeled containers production.

You can't run this test if you don't passed the "LBL Request Mode For Labeling Instruction" pre-connectathon test.

Instructions

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

First step :

1. Go to the "Simulators" menu entry and choose "LB" page to begin your test.
2. Select the "LAB-61 Transaction" tab. 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 with the labeling instructions to the LBL Simulator.
4. Don't forget to hit the "Refresh List" button after to have send your message.

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

1. Create or update the configuration corresponding to the SUT.
2. Go to the "Simulators" menu entry and choose "LB" page to begin your test.
3. Select the "LAB-63 Transaction" tab. 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 need to communicate with the LBL Simulator, in order to simulate the LAB-63 transaction of the LBL Profile.

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.
• Second, the SUT will notify the LBL Simulator for the effective labels printing and labeled containers production.

You can't run this test if you don't passed the "LBL Request Mode For Labeling Instruction" pre-connectathon test.

Instructions

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

First step :
As your system implements the LB (LB acts as a responder in this part of the test) :

1. Create or update the configuration corresponding to the SUT.
2. Go to the "Simulators" menu entry and choose "LIP" page to begin your test.
3. Select the "LAB-61 Transaction" tab.
4. In the SUT Configurations drop-down list, select your LB system.
5. Once you have selected the patient, hit the "Send" button. The LBL Simulator will send the message to your system with the labeling instructions.

Second step :

1. Go to the "Simulators" menu entry and choose "LIP" page to begin your test.
2. Select the "LAB-63 Transaction" tab.
3. In the charset drop-down list, select the desired charset.
4. Use the Ip Address and the Port linked to this charset to send your notification message to the LBL Simulator for the effective labels printing and labeled containers production.
5. Don't forget to hit the "Refresh List" button after to have send your message.
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 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 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 now reside on the tool website.    These replace the test definitions maintained on wiki pages in prior years; those wiki pages are now obsolete.

• 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.

How to submit pre-Connectaton test results from NIST PIX/PDQ tool into Gazelle Test Management:

In Gazelle Test Management, your pre-Connectathon 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, and then change the status of that test to "Verified by vendor".

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

The FHIR Toolkit 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: 

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

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 for each actor reside within the toolkit package.  Likewise, the test definitions are distributed in the package.

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

Pre-Connectaton test lists in Gazelle Test Management:

In Gazelle Test Management, your pre-Connectathon 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_XDS.b-Doc_Source.

Because this tool is new, you will not upload any logs for this test.  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.

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

The FHIR Toolkit 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: 

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
• XDS-I.b - Cross-Enterprise Document Sharing for Imaging:
• Imaging Document Source
• XCA - Cross Community Access:
• Initiating Gateway
• Responding Gateway
• XCA-I - Cross Community Access for Imaging:
• Initiating Imaging Gateway
• Responding Imaging Gateway
• MPQ - Multi-patient Query
• Document Registry
• RMD - Remove Metadata and Documents:
• Document Registry
• Document Repository
• RMU - Restricted Metadata Update:
• Update Responder
• MHD - Mobile access to Health Documents:
• Document Source
• Document Recipient

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. (These replace the test definitions maintained on wiki pages in prior years; those wiki pages are now obsolete.)

--> 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.

How to submit pre-Connectaton test results from XDS Toolkit into Gazelle Test Management:

In Gazelle Test Management, your pre-Connectathon 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, and then change the status of that test to "Verified by vendor".

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 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

This test is dedicated to the LAB-1 transaction from the point of view of the Order Filler. In this test, we will check that the Order Filler is able to integrate the notifications of creation and cancellation of orders received from the Order Placer. In this test, you are asked to use the Order Manager tool as an Order Placer to send messages to your system under test.

Pre-requisite

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

Your Order Filler 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 #30004, you can use the same patient.

We strongly recommend to read the tutorial available here.

1. Laboratory Order creation

As a receiver in this test, your Order Filler 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 Placer --> Notify order filler 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. Cancellation of a laboratory order

In this step, your Order Filler shall prove its ability to accept and integrate an order cancellation sent by the Order Placer (ORC-1="CA") and to acknowledge it (ORC-1="CR").

1. Go to Order management --> Order Placer --> Notify order filler 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.

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

First step to perform: retrieve the configuration of the Order Placer 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 OrderManagement--> Order Placer --> Order Placer configuration
5. Select the character set encoding you will use to send messages to the simulator and enter the given configuration within your Order Filler.

Pre-requisites

The LAB-1 (Lab Placer Order Management) and LAB-2 (Lab Filler Order Management) transactions define 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.

As described in the Technical Framework  (TF-LAB volume 1), your system under test is assumed to implement actors from the PAM or PDQ profile in addition of the Order Filler actor from the LTW integration profile. That means that your system is able either to create a new patient and encounter or to receive those information from an external system. If your system under test implements PEC and/or PDC actors from the PAM profile, feel free to use the PAMSimulator tool to receive new patient and encounter for initializing this test.

Order creation

As a first step for this test, you will have to create two new orders (the status of the first one will be updated in step 2 and the second one will be cancelled in step 3).

1. Enter a new order within your system under test
2. Send a message to the Order Placer part of the simulator. ORC-1 must be valued with "SN".
3. Check the acknowledgment received by your system. (ORC-1="NA") with a placer order number provided in ORB-2.
4. Go to the "HL7messages" part of the simulator and retrieve the message you have sent. Click on the messageid(left-hand column) to get its permanent link and thevalidationresult.
5. Copy and Paste the "permanent link to the test report" into Gazelle
6. Go to Browse Data/All orders and retrieve the order you have sent. Copy and paste its permanent link into Gazelle.
7. Perform steps 1 to 6 a second time in order to create a second order (could be for the same patient).

Update order status

In this second step, the status of the fist placed order will be updated to "A" (Some but not all results available).

1. Update the status of the previous order to "A".
2. Send a notification to the Order Placer part of the simulator. ORC-1 must be valued with "SC", ORC-5="A", OBR-25="P".
3. Refresh the permanent page of the order and check its new status.
4. 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.
5. Copy and Paste the "permanent link to the test report" into Gazelle
6. Do not drop your database after this test; you may want to use this order to send results to the Order Result Tracker (test #30006)

Order cancellation on Order Filler's initiative

This third test is dedicated to the cancellation of the second order you have sent.

1. Within your system, cancel the order and send a notification (ORC-1="SC", ORC-5="CA", OBR-23="X") to the Order Placer part of the simulator.
2. Refresh the permanent page of the order and check it has been cancelled.
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

This test is used to test the capability of the Order Filler and Automation Manager actors to manage work orders. For both actors, the test will be performed against the Order Manager Gazelle tool.

Order Filler

First step to perform: retrieve the configuration of the Automation Manager to which send messages: 

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

Pre-requisites

The LAB-4 (Work 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 Filler 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.

1. Order creation

1. Enter a new work order within your system under test
2. Send a message to the Automation Manager 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 work orders and retrieve the order you have sent. Copy and paste its permanent link into Gazelle

2. Order cancellation

1. Within your system, cancel the previous work 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

Automation Manager

In this test, you will use the Order Manager tool to create a work order to send to your system under test. Before starting this test, make sure you have properly registered your system in the "SUT Configurations" section of the tool and that your system under test is reachable from the Internet (no firewall prevents it from receiving messages from our tools).

Pre-requisites

We strongly recommend to read the tutorial available here.

1. Work Order creation

As a receiver in this test, your Automation Manager 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 (if your system does not support all of the three messages, please leave a comment in Gazelle to explain which one it supports, and why it does not support all of them).

1. Go to Order management --> Order Filler --> Notify Automation Manager of work 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 work 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. Cancellation of a work order

In this step, you will cancel the first work order received by your Automation Manager.

1. Go to Order management --> Order Placer --> Notify order filler 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 work 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.

The aim of this test is to prove the capability of the Order Filler, Automation Manager and Order Result Tracker to manage laboratory test results. In other words, we check that your system is able to send, receive and/or integrate the messages defined in Order Result Management (LAB-3) and Test Result Management (LAB-5). 

Those tests have to be performed against the Order Manager Gazelle tool, which will play the role of Order Result Tracker, Order Filler or Automation Manager according to the cases.

Order Filler

The Order Filler actor is involved in both LAB-3 (as initiator) and LAB-5 (as receiver) transactions. In this test, we check that your system is able to integrate the test results sent by the Automation Manager (role played by the Order Manager Gazelle tool) and to send order results to the Order Result Tracker (role played by the Order Manager tool).

Order Result Management (LAB-3)

This part of the test will use the Order Manager as an Order Result Tracker. First step to perform: retrieve the configuration of the Order Result Tracker to which send messages: 

1. Go to the OrderManagersimulator
2. Log onto the application using the CAS login, it uses your Gazelle (EU-CAT) credentials
3. Select theLaboratorydomain (bottom-right drop-down menu)
4. Go to Results Management --> Order Result Tracker
5. Select the character set encoding you will use to send messages to the simulator and enter the given configuration within your Order Filler.

Pre-requisites

The LAB-3 (Order Result Management) transaction defines two structures of messages (OUL^R22^OUL_R22 and ORU^R01^ORU_R01). As an initiator in this transaction, you are free to use the structure  your system under test supports.

You are assumed to perform this test after working on test #30004 so that you can reuse the order previously placed in the Order Placer. If you have followed the instruction of the test #30004 you shall have the values: ORC-5="A" and OBR-25="P". 

1. The Order Filler notifies the Order Result Tracker of the clinical validation of the results

1. Retrieve the laboratory order to use (or create a new one with the previously given characteristics) and add two observations relative to the order (OBX-11 = "P" or OBX="F")
2. Send a notification to the Order Result Tracker 
3. Follow menu Browse data --> Order Result Tracker's data and retrieve the order you have just sent to the tool
4. Copy and paste the permanent link to this order in the pre-connectathon instance started in Test Management
5. 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.
6. Copy and Paste the "permanent link to the test report" into Gazelle

2. The Order Filler notifies the Order Result Tracker of the deletion of the test

1. Cancel the previous order from your Order Filler.
2. Send a notification to the Order Result Tracker. OBR-25 must be valued with "X", OBX-11 with "X" and ORC-5 with "CA"
3. Check that the tool has received the message and properly integrated it.
4. 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.
5. Copy and Paste the "permanent link to the test report" into Gazelle

Test Results Management (LAB-5)

This part of the test will use the Order Manager part as an Automation Manager. If you have already performed tests #30003 and #30004, your system under test is already registered within the tool. 

Pre-requisites

The LAB-5 (Test Results Management) transaction defines two structures of messages (OUL^R22^OUL_R22 and OUL^R23^OUL_R23). As a responder in this transaction, your system under test must be able to integrate both. Go to Results management --> Automation Manager.

1. The Automation Manager transmits multiple results related to a specimen to the Order Filler

1. Select your system under test in the drop-down list located at the top of the page
2. Select "Specimen centered result reporting" as Message structure to use
3. Click on "Create a new result from scratch". The list of available patients is displayed, pick one known by your Order Filler (You may have already used patients for previous tests)
4. Fill the specimen, put the specimen available (tick the "specimen available?" checkbox) and ask for created only one container. Then click on "Create an order for specimen".
5. Fill the new work order. Result status must be equal to "Results stored; not yet verified" and the order status to "Some but not all results available".
6. Click on "Add to current specimen". Then, click on "Add observations".
7. Add an observation relative to the work order. Observation result status must be equal to "Results entered - not verified".
8. Finally, send the message and check that it is properly received and integrated by your system under test.
9. 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.
10. Copy and Paste the "permanent link to the test report" into Gazelle
11. As a proof of the correct integration of the message within your system, take a screenshot of your application (showing the order and observation) and upload it in Test Management.

2. The Automation Manager transmits multiple results related to one or more specific containers with one specimen to the Order Filler

1. Click on "Perform another test"
2. Select "Reporting results related to one or more containers for a specific specimen" as Message structure to use
3. Select the same patient as for the previous test
4. Fill the specimen; it must be available (tick "specimen available ?"). Then click on "create a container for specimen"
5. For the created container, click on "Add an order for this container"
6. Fill the new order. Result status must be equal to "Results stored; not yet verified" and the order status to "Some but not all results available".
7. Click on "Add to current specimen" and then click on "Add observations"
8. Add an observation relative to the work order. Observation result status must be equal to "Results entered - not verified".
9. Finally, send the message and check that it is properly received and integrated by your system under test.
10. 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.
11. Copy and Paste the "permanent link to the test report" into Gazelle
12. As a proof of the correct integration of the message within your system, take a screenshot of your application (showing the order and observation) and upload it in Test Management.

Automation Manager

The Automation Manager is involved in LAB-5 transaction as an initiator. In this test, we check the capability of your system to send messages to the Order Filler part of the Order Manager Gazelle tool. LAB-5 transaction defines two message structures (OUL^R22^OUL_R22 and OUL^R23^OUL_R23); as an initiator for this transaction, your system under test must support one out of these two structures. If your system supports both, please repeat this test twice so that we can check the conformance of the messages produced by your system.

Pre-requisites

This part of the test will use the Order Manager as an Order Filler. 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 (EU-CAT) credentials
3. Select the Laboratory domain (bottom-right drop-down menu)
4. Go to Results 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 Filler.

The Automation Manager transmits multiple results to the Order Filler

1. Within your application, create a new work order with the following information OBR-25 = "R" and ORC-5="A"
2. Add an observation to this order with OBX-11 = "R"
3. Send the appropriate message to the Order Filler part of the Order Manager
4. Follow menu Browse data --> Order Filler's data and retrieve the work order you have just sent to the tool
5. Copy and paste the permanent link to this order in the pre-connectathon instance started in Test Management
6. 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.
7. Copy and Paste the "permanent link to the test report" into Gazelle

Order Result Tracker

The Order Result Tracker is involved in LAB-3 transaction as a responder. In this test, we check the capability of your system to integrate the messages received from an Order Filler (role played by the Order Manager Gazelle tool). This transaction defines two message structures (OUL^R22^OUL_R22 and ORU^R01^ORU_R01); as a responder your system must support both of them.

Pre-requisites

This test used the Order Manager tool as an Order Filler. In order to tell the simulator to which system send messages, your first action will be to create a new configuration for your system under test within the Order Manager. Go to the "SUT configurations" section to do so.

Then, go to Results management --> Order Filler --> Send test results to your SUT to start the test.

1. The Order Filler transmits specimen centered results to the ORT

1. Select your system under test in the drop-down list located at the top of the page
2. Select "Specimen centered result reporting" as Message structure to use
3. Click on "Create a new result from scratch". The list of available patients is displayed, select an existing one or create a new one.
4. Fill the specimen, put the specimen available (tick the "specimen available?" checkbox) and ask for created only one container. Then click on "Create an order for specimen".
5. Fill the new order. Result status must be equal to "Results stored; not yet verified" and the order status to "Some but not all results available".
6. Click on "Add to current specimen". Then, click on "Add observations".
7. Add an observation relative to the order. Observation result status must be equal to "Results entered - not verified".
8. Finally, send the message and check that it is properly received and integrated by your system under test.
9. 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.
10. Copy and Paste the "permanent link to the test report" into Gazelle
11. As a proof of the correct integration of the message within your system, take a screenshot of your application (showing the order and observation) and upload it in Test Management.

2. The Order Filler transmits order centered results to the ORT

1. Click on "Perform another test"
2. Select "Order centered result reporting" as Message structure to use
3. Select the same patient as for the previous test
4. Fill the new order. Result status must be equal to "Results stored; not yet verified" and the order status to "Some but not all results available". Then click on "Create a specimen for order".
5. Fill the specimen; it must be available (tick "specimen available ?") and ask for created only one container. Then click on "Add to current order"
6. Finally click on "Add observations"
7. Add an observation relative to the order. Observation result status must be equal to "Results entered - not verified".
8. Finally, send the message and check that it is properly received and integrated by your system under test.
9. 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.
10. Copy and Paste the "permanent link to the test report" into Gazelle
11. As a proof of the correct integration of the message within your system, take a screenshot of your application (showing the order and observation) and upload it in Test Management.

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

Instructions

As your system implements the Analyzer Manager actor, you will need to test the HL7 messages used in the LAB-27, LAB-28 and LAB-29 transactions.
Your system must be able to send HL7 messages (to the Analyzer actor) of types :

• RSP^K11^RSP_K11, for the LAB-27 transaction (Query for AWOS)
• OML^O33^OML_O33, for the LAB-28 transaction (Analytical Work Order Step Broadcast)
• ACK^R22^ACK_R22, for the LAB-29 transaction (AWOS Status Change)   

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 RSP^K11^RSP_K11 message :

1. Copy the RSP^K11^RSP_K11 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 : Analyzer Manager
   • Transaction : LAB-27
   • Message Type : RSP^K11^RSP_K11
   • HL7 Version : HL7v2.5.1  
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 LAW 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 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 RSP^K11^RSP_K11 and the ACK^R22^ACK_R22 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 concerns the bi-directional Analyzer actor. You will need to validate with EVSClient tool the IHE conformance of your HL7 messages.

Instructions

As your system implements the Analyzer actor and supports the bi-directional communication option, you will need to test the HL7 messages used in the LAB-27, LAB-28 and LAB-29 transactions.
Your system must be able to send HL7 messages (to the Analyzer Manager actor) of types :

• QBP^Q11^QBP_Q11, for the LAB-27 transaction (Query for AWOS)
• ORL^O34^ORL_O34, for the LAB-28 transaction (Analytical Work Order Step Broadcast)
• OUL^R22^OUL_R22, for the LAB-29 transaction (AWOS Status Change)

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, and hit the "Guess" button to preset the Profile OID.
   
For example, for the QBP^Q11^QBP_Q11 message :

1. Copy the QBP^Q11^QBP_Q11 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 : Analyzer
   • Transaction : LAB-27
   • Message Type : QBP^Q11^QBP_Q11
   • HL7 Version : HL7v2.5.1
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 LAW 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 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 ORL^O34^ORL_O34 message 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 concerns the Analyzer actor. You will need to validate with EVSClient tool the IHE conformance of your HL7 messages.

Instructions

As your system implements the Analyzer actor and supports the bi-directional communication option, you will need to test the HL7 message used in the LAB-29 transaction.
Your system must be able to send HL7 messages (to the Analyzer Manager actor) of type :    
OUL^R22^OUL_R22, for the LAB-29 transaction (AWOS Status Change)
   
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, and hit the "Guess" button to preset the Profile OID.
   
For example :

1. Copy the OUL^R22^OUL_R22 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 : Analyzer
   • Transaction : LAB-29
   • Message Type : OUL^R22^OUL_R22
   • HL7 Version : HL7v2.5.1
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 LAW 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 and LBL Profiles of the Laboratory Domain) ?

Evaluation

• The validation status shall be "PASSED" for all messages.
• The message type shall be the right message type, according to IHE.

This test concerns only the Analyzer Manager actor. You will need to communicate with the LAW Simulator (which is included in the Order Manager Simulator), in order to simulate the LAB-27 transaction of the LAW Profile.

Instructions

Access the LAW 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 reminded that if you are logged in your configurations will be private, otherwise it will be public. 

In this test, the LAW Simulator plays the role of the "Analyzer". It is used to query the SUT (System Under Test) for an AWOS related to the specimen. 

The SUT implements the Analyzer Manager (Analyzer Manager acts as a responder in this test) :

1. First at all, check that the selected "Domain for testing" (at the bottom right of the page) is "Laboratory".
2. Create or update the configuration corresponding to the SUT.
3. Then, go to the "Order Management" menu entry, choose "Analyzer", and click on the "Query Analyzer Manager for AWOS" page to begin the test.
4. In the "SUT Configurations" drop-down list, select the configuration matching the SUT.
5. Select the "Query Mode" and fill the required parameters values (See the description of the LAB-27 transaction in the LAW Technical Framework Supplement for further details about the usage of the parameters). 
6. Then, hit the "Send Query" button. The LAW Simulator will send the query to the SUT.
7. 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.
• The QPD segment of the RSP^K11^RSP_K11 message must contain the same information that the QPD segment of the QBP^Q11^QBP_Q11 message

This test concerns only the Analyzer actor. You will need to communicate with the LAW Simulator (which is included in the Order Manager Simulator), in order to simulate the LAB-27 transaction of the LAW Profile.

Instructions

Access the LAW 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

In this test, the LAW Simulator will be used to respond to the SUT (System Under Test) query.

As the SUT implements the Analyzer (Analyzer acts as an initiator in this test) :

1. First at all, check that the selected "Domain for testing" (at the bottom right of the page) is "Laboratory".
2. You must be log in to be able to continue this test.
3. Go to the "Order Management" menu entry and choose "Analyzer Manager", then "Analyzer Manager Configuration" page to begin the test.
4. In the charset drop-down list, select the desired charset. 
5. Use the Ip Address and the Port linked to this charset to send your message to the LAW Simulator. 
6. Don't forget to hit the "Refresh List" button after to have send your message. In this test, the Analyzer SUT queries the Analyzer Manager simulator for a WOS related to a specimen.
7. 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 Analyzer Manager actor. You will need to communicate with the LAW Simulator (which is included in the Order Manager Simulator), in order to simulate the LAB-28 transaction of the LAW Profile.

Instructions

Access the LAW 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

In this test, the LAW Simulator will receive the AWOS from the SUT, saves all information and responds with an acknowledgment.

As the SUT implements the Analyzer Manager (Analyzer Manager acts as an initiator in this test) :

1. First at all, check that the selected "Domain for testing" (at the bottom right of the page) is "Laboratory".
2. You must be log in to be able to achieve this test.
3. Then, go to the "Order Management" menu entry and choose "Analyzer", then "Analyzer Configuration" page to begin the test.
4. In the "SUT Configurations" drop-down list, select the configuration matching the SUT.
5. Use the Ip Address and the Port linked to this charset to send your message to the LAW Simulator.
6. There are two different steps in this test.
   1.  
      1. Send a "new AWOS" message to the Analyzer. This message is used to broadcast the AWOS from your SUT to the Analyzer simulator.
      2. Don't forget to hit the "Refresh List" button after to have send your message.
      3. Check the simulator has properly received and acknowledged your message.
   1.  
      1. Send a "cancel AWOS" message to the Analyzer to cancel the AWOS sent in the first step.
      2. Don't forget to hit the "Refresh List" button after to have send your message.
      3. Check the simulator has properly received, and acknowledged your message.
   • First Step : Send "new AWOS" to the Analyzer simulator.
   • Second Step : Cancel the AWOS sent in the first step.

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

• For all 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.
• For the First Step :
  • In the OML^O33^OML_O33 message, the ORC-1 must be filled with "NW".
  • In the ORL^O34^ORL_O34 message, the ORC-1 must be filled with "OK" and ORC-5 with "SC" or "IP".
• For the Second Step :
  • In the OML^O33^OML_O33 message, the ORC-1 must be filled with "CA".
  • In the ORL^O34^ORL_O34 message, the ORC-1 must be filled with "CR" and ORC-5 with "CA".

This test concerns only the Analyzer actor. You will need to communicate with the LAW Simulator (wich is included in the Order Manager Simulator), in order to simulate the LAB-28 transaction of the LAW Profile.

Instructions

Access the LAW 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 reminded that if you are logged in your configurations will be private, otherwise it will be public. 

In this test, the LAW Simulator will be used to send to the SUT (System Under Test) an AWOS related to a specimen.

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

1. First at all, check that the selected "Domain for testing" (at the bottom right of the page) is "Laboratory".
2. Create or update the configuration corresponding to the SUT.
3. Then, go to the "Order Management" menu entry, choose "Analyzer Manager", and click on the "Analytical Work Order Step Broadcast" page to begin the test.
4. In the SUT Configurations drop-down list, select the SUT configuration.
   1.  
      1. For the "Action to perform", select "Create a new order". 
      2. Select the patient to begin the test. Of course, you can create a new patient and a new encounter.(See the Order Manager user manual to have more information). 
      3. Once the patient and the encounter have been selected, go to the "Create specimen" panel and fill all required fields. It is possible to fill some fields randomly in hitting the "Fill with random values" button. 
      4. Hit the "create an order for specimen" button to save the specimen.
      5. Then, in the "Create order for current specimen" panel, fill all required fields. Once again, it is possible to fill some fields randomly in hitting the "Fill with random values" button.
      6. For the Result status, choose the value : "Final results: results stored and verified. Can only be changed with a corrected result.".
      7. At least, hit the "Add to current specimen and send message" button to send the order to the selected SUT.
      8. Check the simulator has properly received your acknowledgement message.
   1.  
      1. If you always are in the "Test Report" panel, hit the "Perform another test" button, otherwise return to the "Order Management" menu entry, choose "Analyzer Manager", and click on the "Analytical Work Order Step Broadcast" page.
      2. For the "Action to perform", select "Cancel an existing order".
      3. In the "Order Selection" panel, select the Order sent in the first step. You can use the filter option to search a specific Order.(See the Order Manager user manual to have more information). 
      4. A modal panel will ask you to confirm the order cancellation. Say "Yes". The LAW Simulator will send the cancellation order to the SUT.
      5. Check the simulator has properly received your acknowledgement message.
   • First Step : Create and send a new order.
   • Second Step : Cancel the AWOS sent in the first step.

The messages exchanged between the simulator and the SUT can be found in the message table on the very same page (see the "Test report" panel) 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

• For all 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.
• For the First Step :
  • In the ORL^O34^ORL_O34 message, the ORC-1 must be filled with "OK" and ORC-5 with "SC" or "IP".
• For the Second Step :
  • In the ORL^O34^ORL_O34 message, the ORC-1 must be filled with "CR" and ORC-5 with "CA".

This test concerns only the Analyzer Manager actor. You will need to communicate with the LAW Simulator (which is included in the Order Manager Simulator), in order to simulate the LAB-29 transaction of the LAW Profile.

Instructions

Access the LAW 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 reminded that if you are logged in your configurations will be private, otherwise it will be public.

In this test, the LAW Simulator will be used to send to the SUT (System Under Test) the test results.

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

1. Create or update the configuration corresponding to your system under test; go to SUT Configurations > HL7 Responders
2. Then, go to Laboratory > Analyzer > [LAB-29] AWOS Status Change
3. In the "SUT Configurations" drop-down list, select the configuration matching the SUT.
4. Select a specimen to work on it. You can use the filter option to search a specific Specimen. (See the Order Manager user manual to have more information).
5. In the "Specimen details" panel, you can Add an observation to this specimen (this is optional in this test). You will need to fill all required fields. For the "Observation result status" choose : "Final results". Then, hit the "Add observation to specimen" button.
6. Now, in the "Related orders" panel, add an observation for each order. Hit the "related observations" link, then hit the "Add an observation to this order" button. You will need to fill all required fields. For the "Observation result status" choose : "Final results". Then, hit the "Add observation to order" button.
7. Always in the "Related orders" panel, for each order, in the Status and Result Status columns : Update the "Status" to "Order is completed" and the "Result status" to "Final results" using the "Update" button.  
8. Finally, hit the "Send Message" button. The LAW Simulator will send the message to the SUT.
9. 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 Analyzer actor. You will need to communicate with the LAW Simulator (which is included in the Order Manager Simulator), in order to simulate the LAB-29 transaction of the LAW Profile.

Instructions

Access the LAW 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

In this test, the LAW Simulator will be used to respond to the SUT (System Under Test) query.

As the SUT implements the Analyzer Manager (Analyzer Manager acts as an initiator in this test) :

1. First at all, check that the selected "Domain for testing" (at the bottom right of the page) is "Laboratory".
2. You must be log in to be able to continue this test.
3. Go to the "Result Management" menu entry and choose the "Analyzer Manager Configuration" page to begin the test.
4. In the charset drop-down list, select the desired charset. 
5. Use the Ip Address and the Port linked to this charset to send your message to the LAW Simulator.
6. In this test, the Analyzer SUT needs to send test results related to a specimen.
7. Don't forget to hit the "Refresh List" button after to have send your message.
8. 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.

In this test, the OrderManager tool is a DICOM Modality Worklist SCP, and your application (most commonly an Acquisition Modality actor) is the MWL SCU.

The test is a sanity check of your worklist query capabilities for pre-Connectathon testing.   In some cases, the Order Manager is used as a MWL SCP during a Connectathon, and this test helps prepare you for that.

Prerequisite

Refer to the OrderManager User Manual for instructions on creating a DICOM worklist.

Test Steps

As a MWL SCU in this test, your application will query the OrderManager (MWL SCP) for a worklist.

1. First create a worklist entry in the Order Manager tool:
1. TO CREATE A WORKLIST ENTRY FROM AN ORDER ALREADY IN THE TOOL: In the OrderManager, select menu Radiology-->Order Filler-->Create a DICOM worklist (or Eye care-->Order Filler-->Create a DICOM worklist).  Then select one order from the table of existing order entries
2. TO CREATE NEW ORDER FOR A WORKLIST ENTRY: In the OrderManager, start by selecting  Radiology-->Order Filler-->[RAD-3] Create...orders (or Eye-->Order Filler-->[RAD-3] Create...orders).  Then proceed through the steps to create the order, schedule it, then create the worklist for your new order.
2. You will be prompted to provide your application's "Station AE Title" prior to selecting the "Generate worklist" button
3. Capture the "Permanent link" to your worklist details (ie the URL)
4. Use your application to query the OrderManager for modality worklist 
5. Create a screen capture from your application showing the worklist received.
6. For your pre-Connectathon test results in gazelle, upload the screen capture file and copy the permanent link into the comment box as the results for this
   test.

Evaluation

The link to the worklist entry & the screen shot demonstrate that you have successfully received worklist.

This tests the RAD-2 transaction from the point of view of the Order Filler as system under test.

In this test, we will check that your Order Filler is able to integrate the creation and cancellation of orders received from the OrderManager tool playing the role of the Order Placer actor. 

Prerequisite

1. CONFIGURATION: Before beginning this test, do not forget to check that the configuration (IP address, port, application/facility names) of your system under test is entered within the OrderManager tool.  Use the "SUT Configurations" menu. 
2. TEST PATIENT: Your Order Filler is assumed to be coupled with a ADT actor; that means that you should be able either to receive a new patient from an ADT or Patient Demographics Supplier actor.  To populate your system with a patient, use the PatientManager tool create a patient and an send ADT message to your system.  In the steps below, you will use that patient to create an order in the OrderManager.  Follow these  instructions for using PatientManager to create a patient that is then used by the OrderManager.

Refer to the OrderManager user manual and these details about sending RAD-2.

Test Steps

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

1. Create a new order

In this step, your Order Filler proves its ability to accept and integrate an order creation sent by the Order Placer (ORC-1="NW") 

1. Go to menu 'Radiology' or 'Eye care', then --> Order Placer --> [RAD-2] Create/Cancel orders
2. Select your system under test in the drop-down list
3. Select "Create a new order" as action to perform.  By default, you will get an HL7 v2.3.1 ORM.  If you want a HL7 v2.5.1 OMG messages, click that box.
4. Select the patient for whom you want to create a order
5. Fill the order and click on the "Send message" button
6. Retrieve the permanent link to the test report and paste it into Gazelle Test Management as the results for this test.
7. Take a screenshot of your application as a proof of the good integration of the message. Upload it in Gazelle.

2. Cancel an existing order

In this step, your Order Filler proves its ability to accept and integrate an order cancellation sent by the Order Placer (ORC-1="CA") and to acknowledge it (with an ACK message).

1. Go to Radiology --> Order Placer --> [RAD-2] Create/Cancel 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  order to cancel and when the pop-up raises, click on the "Yes" button.
5. Retrieve the permanent link to the test report and paste it in Gazelle.
6. Take a screenshot of your application as a proof of the good integration of the message. Upload it in Gazelle.

3. Stop the fulfillment of an order (DC)

In this step, your Order Filler proves its ability to accept the discontinue of an ongoing order sent by the Order Placer (ORC-1="DC") and to acknowledge it (with an ACK message).

1. Repeat step 1. Create a new order
2. On your Order Filler, starts processing the order. The Order Placer shall be notified that the order is "in progress": send a "Update Order Status" (RAD-3) message to the Order Placer actor of the tool (you will find its connection information under Radiology > Order Placer > Configuration). 
3. Go to Radiology --> Order Placer --> [RAD-2] Create/Cancel orders
4. Select your system under test in the drop-down list
5. Select "Stop the fulfillment of an order (DC)" as action to perform
6. Select the  order to discontinue and when the pop-up raises, click on the "Yes" 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.

Evaluation

The permanent links to the test report & the screen shots demonstrate that you have successfully handled the received order messages.

This tests the RAD-3 transaction from the point of view of the Order Placer as system under test.

In this test, we will check that your Order Placer is able to integrate the creation and cancellation of orders received from the Order Manager tool playing the role of the Order Filler actor. 

Prerequisite

1. CONFIGURATION: Before beginning this test, do not forget to check that the configuration (IP address, port, application/facility names) of your system under test is entered within the Order Manager tool.  Use the "SUT Configurations" menu. 
2. TEST PATIENT: Your Order Filler is assumed to be coupled with a ADT actor; that means that you should be able either to receive a new patient from an ADT or Patient Demographics Supplier actor.  To populate your system with a patient, use the Patient Manager tool create a patient and an send ADT message to your system.  In the steps below, you will use that patient to create an order in the Order Manager.  Follow these  instructions for using Patient Manager to create a patient that is then used by the Order Manager.

Refer to the Order Manager user manual.

Test Steps

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 three steps.

1. Create a new order

In this test, your Order Placer receives an ORM (v2.3.1) or OMG (v2.5.1) from the Order Manager acting as Order Filler.  You respond with an ORR (v2.3.1) or ORG (v2.5.1)

1. Go to menu 'Radiology' or 'Eye care', then --> Order Filler --> [RAD-3] Create/Update/Cancel orders
2. Select your system under test in the drop-down list
3. Select "Create a new order" as action to perform.  By default, you will get an HL7 v2.3.1 ORM.  If you want a HL7 v2.5.1 OMG messages, click that box.
4. Select the patient for whom you want to create a order
5. Fill the order and click on the "Send message" button
6. Retrieve the permanent link to the test report and paste it into Gazelle Test Management as the results for this test.
7. Take a screenshot of your application as a proof of the good integration of the message (a new order). Upload it in Gazelle.

2. Cancel an existing order

In this test, your Order Placer receives an ORM-Cancel (v2.3.1) or OMG-Cancel (v2.5.1) from the Order Manager acting as Order Filler.  You respond with an ACK.

1. Go to menu 'Radiology' or 'Eye care', then --> Order Filler --> [RAD-3] Create/Update/Cancel 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  order to cancel and when the pop-up raises, click on the "Yes" button.
5. Retrieve the permanent link to the test report and paste it in Gazelle.
6. Take a screenshot of your application as a proof of the good integration of the message (a cancelled order). Upload it in Gazelle.

3. Update order status

In this test, your Order Placer receives an ORM-Status update (v2.3.1) or OMG-Status update (v2.5.1) from the Order Manager acting as Order Filler.  You respond with an ACK.

1. Go to menu 'Radiology' or 'Eye care', then --> Order Filler --> [RAD-3] Create/Update/Cancel orders
2. Repeat step 1. Create a new order to place a new order in your Order Placer
3. Select your system under test in the drop-down list
4. Select "Update order status" as action to perform
5. Select the  order to updpate 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 (an updated order). Upload it in Gazelle.

 Evaluation

The permanent links to the test report & the screen shots demonstrate that you have successfully handled the received order messages.

This tests the RAD-4 (Procedure Scheduled) and RAD-13 (Procedure Updated) transactions from the point of view of the Image Manager as system under test.

In this test, we will check that your Image Manager is able to integrate the scheduling and cancelllation of procedures received from the Order Manager tool playing the role of the Order Filler actor. 

You may use the Order Manager to send

• RAD-4 and RAD-13:  HL7 v2.3.1 orders (SWF), or
• RAD-4 and RAD-13:  HL7 v2.5.1 orders (SWF.b)

Prerequisite

1. CONFIGURATION: Before beginning this test, do not forget to check that the configuration (IP address, port, application/facility names) of your system under test is entered within the Order Manager tool.  Use the "SUT Configurations" menu. 
2. TEST PATIENT:   In the steps below, you will use a test patient to create and schedule an order in the Order Manager.  Follow these  instructions for using Patient Manager to create a patient that is then used by the Order Manager.

Refer to the Order Manager user manual.

Test Steps

As a receiver in this test, your Image Manager shall be able to integrate all of the message structures defined in the technical framework. As a consequence, you are asked to perform these four steps.

1. Procedure Scheduled [RAD-4]

In this step, your Image Manager proves its ability to accept and integrate a new scheduled procedure sent by the Order Filler.

1. Go to menu 'Radiology' or 'Eye care', then --> Order Filler --> [RAD-4/13] Schedule/update procedures
2. Select your system under test in the drop-down list
3. Select "Procedure Scheduled" as action to perform.  

• By default, you will get an HL7 v2.3.1 ORM.  If you want an HL7 v2.5.1 OMG messages, click that box.

2. Procedure update:  cancel order request (CA) [RAD-13]

In this step, your Order Image Manager proves its ability to accept and integrate an order cancellation sent by the Order Filler (ORC-1="CA") and to acknowledge it.

1. Go to menu 'Radiology' or 'Eye care', then --> Order Filler --> [RAD-4/13] Schedule/update procedures
2. Select your system under test in the drop-down list
3. Select "Procedure update: cancel order request" as action to perform.  
1. By default, you will get an HL7 v2.3.1 ORM.  If you want an HL7 v2.5.1 OMI message, click that box. 
4. Select the procedure to cancel and when the pop-up raises, click on the "Yes" button.
5. Retrieve the permanent link to the test report and paste it in Gazelle.
6. Take a screenshot of your application as a proof of the good integration of the message. Upload it in Gazelle.

3. Procedure update: discontinue order request (DC) [RAD-13]

In this step, your Image Manager proves its ability to accept the discontinue of an ongoing order sent by the Order Filler (ORC-1="DC") and to acknowledge it.

1. Go to menu 'Radiology' or 'Eye care', then --> Order Filler --> [RAD-4/13] Schedule/update procedures
2. Select your system under test in the drop-down list
3. Select "Procedure update: discontinue order request" as action to perform.  
1. By default, you will get an HL7 v2.3.1 ORM.  If you want an HL7 v2.5.1 OMI message, click that box. 
4. Select the procedure to cancel and when the pop-up raises, click on the "Yes" button.
5. Retrieve the permanent link to the test report and paste it in Gazelle.
6. Take a screenshot of your application as a proof of the good integration of the message. Upload it in Gazelle.

4. Procedure update: change order request (XO) [RAD-13]

In this step, your Image Manager proves its ability to accept the procedure update/change order request (order still scheduled or in progress) sent by the Order Filler (ORC-1="XO") and to acknowledge it.

1. Go to menu 'Radiology' or 'Eye care', then --> Order Filler --> [RAD-4/13] Schedule/update procedures
2. Select your system under test in the drop-down list
3. Select "Procedure update: change order request" as action to perform.  
1. By default, you will get an HL7 v2.3.1 ORM.  If you want an HL7 v2.5.1 OMI message, click that box. 
4. Select the procedure to cancel and when the pop-up raises, click on the "Yes" button.
5. Retrieve the permanent link to the test report and paste it in Gazelle.
6. Take a screenshot of your application as a proof of the good integration of the message. Upload it in Gazelle.

5. Procedure update: order has been completed (XO) [RAD-13]

In this step, your Image Manager proves its ability to accept the procedure update/order completed sent by the Order Filler (ORC-1="XO") and to acknowledge it.

1. Go to menu 'Radiology' or 'Eye care', then --> Order Filler --> [RAD-4/13] Schedule/update procedures
2. Select your system under test in the drop-down list
3. Select "Procedure update: order has been completed" as action to perform.  
1. By default, you will get an HL7 v2.3.1 ORM.  If you want an HL7 v2.5.1 OMI message, click that box. 
4. Select the procedure to cancel and when the pop-up raises, click on the "Yes" button.
5. Retrieve the permanent link to the test report and paste it in Gazelle.
6. Take a screenshot of your application as a proof of the good integration of the message. Upload it in Gazelle.

Evaluation

The permanent links to the test report & the screen shots demonstrate that you have successfully handled the received order messages.

Introduction

To prepare for testing the RAD Encounter-based Imaging Workflow (EBIW) Profile, the EBIW actors must prepare to use a common set of DICOM codes. 

• Encounter Manager:  Please complete the configuration and preparation described below prior to performing any peer-to-peer Connectathon tests for the EBIW profile.
• Image Manager, Results Aggregator, Modality actors:   There is no work for you to perform, but this test contains a description of the procedures and patients that will be used in peer-to-peer EBIW tests.   You will benefit from reading them prior to the Connectathon. 
• Modalities:  If you find that the proposed DICOM codes do not adequately match what your application would use, please contact the Connectathon Radiology Technical Manager **well in advance** of the Connectathon so that the set of codes can be expanded to meet your needs.

Instructions

The codes you need are identified in the peer-to-peer test that you will perform at the Connectathon.

1.  In Gazelle Test Management for Europe or North America, find the test "EBIW_10_Read_This_First" on your main Connectathon page.

2.  Read the entire Test Description to understand the test scenario.

3.  For each of the DICOM attributes listed in the Test Description, the Encounter Manager should configure its system to be able to use the values in the bullet lists. This ensures that consistent values will be returned in modality worklist responses in peer-to-peer EBIW tests during the Connectathon.

Evaluation

There is no evaluation for this 'test'.   If you do not load the codes you need on your test system prior to the Connectathon, you may find yourself wasting valuable time on the first day of Connectathon syncing your codes with those of your test partners.

Introduction

To prepare for testing workflow profiles in RAD, CARD, LAB, and EYECARE domains, and also for the ITI PAM Profile, it is helpful for systems that send HL7 messages (eg patient registration and orders) and/or DICOM messages (modality worklist, storage) to work with a common set of codes. 

We ask ADT, Order Placer, Order Filler and Acquisistion Modality actors and PAM Patient Demographic & Encounter Supplier actors to load codes relevant to their system in advance of the Connectathon

These codes include, for example:

• Administrative sex codes in PID-8
• Dcotors sent in PV1
• Facility codes sent in HL7 PV1-3
• Universal Service ID (order codes) sent in OBR-4
• Priority codes sent in OBR-27 or TQ1-9
• Acquisition Modality code sent in OBR-24 and (0008,0060)
• ...and more

Instructions

The codes that you need depend on the profile/actors you support.  HL7 and DICOM codes used for Connectathon testing are the same set that is used in the Gazelle OrderManager tool. OrderManager contains simulators for some actors in workflow profiles.

** HL7 codes ** - are documented here:

• For patient registration messages: https://gazelle.ihe.net/PatientManager/administration/valueSetManager.seam
• For order-related messages:  https://gazelle.ihe.net/OrderManager/administration/valueSetManager.seam

Some of these codes are also mapped into DICOM messages.  Use the spy-glass icon in the right column to view the value set for each code.  (Note that the format of these files is compliant with the IHE SVS Sharing Value Sets profile.)

• ADT, Order Placer, and Order Filler plus PAM Supplier systems should review the link above and load codes relevant to the HL7 messages it supports

** DICOM codes ** - Order Filler and Acquisition Modality actors need a mapping between Requested Procedure codes, Scheduled Procedure codes, and Protocol Codes. 

For RAD and CARD, that hierarchy is here: https://gazelle.ihe.net/common/order-manager/orderHierarchy4Radiology.xml   
For EYECARE, that hierarchy is here: https://gazelle.ihe.net/common/order-manager/orderHierarchy4Eyecare.xml. (Note that this is documented in excel form here.)

• An Order Filler system should load codes relevant to the domain(s) it is testing. 
• An Acquisition Modality system should load codes relevant to the acquisitions it can perform. 

Evaluation

There is no evaluation for this 'test'.   If you do not load the codes you need on your test system prior to the Connectathon, you may find yourself wasting valuable time on the first day of Connectathon syncing your codes with those of your test partners.

Introduction

To prepare for testing the ITI Patient Location Tracking (PLT) Profile, the PLT Supplier, Consumer and Supplier actors must use a common set of HL7 codes. 

We ask these actors to load codes relevant to their system in advance of the Connectathon.

Instructions

The codes you need are identified in the peer-to-peer test that you will perform at the Connectathon.

1.  In Gazelle Test Management for Europe or North America, find the test "PLT_TRACKING_WORKFLOW" on your main Connectathon page.

2.  Read the entire test to understand the test scenario.

3.  Load the codes for PV1-11 Temporary Patient Location.  These are in a table at the bottom of the Test Description section.

Note:  These codes are are a subset of the HL7 codes used during Connectathon.  If you already performed pre-Connectathon test "PRELOAD_Codes_for_HL7_and_DICOM", then you already have these codes.

Evaluation

There is no evaluation for this 'test'.   If you do not load the codes you need on your test system prior to the Connectathon, you may find yourself wasting valuable time on the first day of Connectathon syncing your codes with those of your test partners.

Overview:

These instructions apply to:

• PIXv2/PIXv3/PIXm - PIX Managers
• PDQv2/PDQv3/PDQm - Patient Demographics Suppliers
• XD*, MHD - Document Sources submitting docs to XDS Reg/Rep or MHD Recipient
• XC* - Initiating & Responding Gateways
• SDC/MHD testing

To support PIX, PDQ, XDS, SDC and XC* tests, we ask you to arrive at the Connectathon with specific patients already loaded in your database.  These demograpics include two "well-known" patients FARNSWORTH^STEVE (for PIXv2) and WALTERS^WILLIAM (for PIXv3 & PIXm tests), plus several patients for PDQ/PDQv3/PDQm. There are also several patients used in XDS, SDC/MHD and XC* testing.

We use the Gazelle PatientManager tool to enable you to load these patients on to your Connectathon test system. 

You can use the PatientManager to:

• Download FHIR Patient Resources for these patients, individually or as a FHIR Bundle.
• Note:  as of Oct-2019 there is a known issue with datatype of the mothersMaidenName extension used in the Patient Resources in PatientManager.  See jira issue PAM-650.
  -- or --
• Send the patients to your system via an HL7v2 feed [ITI-8], and HL7 v3 feed [ITI-44], or by loading FHIR Resources. (These are easier methods because all patients can be loaded at once.)
  --or--
• Respond to PIX* or PDQ* or XCPD queries for these patients (These methods are not as easy because you have to query for patients individually.)

Gazelle PatientManager Tool:

• PatientManager Tool:  https://gazelle.ihe.net/PatientManager/home.seam
• PatientManager User Manual: https://gazelle.ihe.net/gazelle-documentation/Patient-Manager/user.html

Instructions:

Use the PatientManager tool to pre-load selected patients onto your test system.. Note: the regular pre-Connectathon test deadline does not apply to this pre-Connectathon 'test'. It will help you to get this task done before arriving at Connectathon.

Which patients?

The PatientManager contains patients to load for Connectathon testing.

• In the PatientManager tool, select menu Connectathon-->Patient Demographics. 
• All patients listed are applicable to the Connectathon.  Each patient has a Patient ID in multiple assigning authorities, each representing a different XDS Affinity domain.  If you are new to Connectathon testing, this is explained here.
• The patients you should load depend on what actor(s) you support:
• PIX* Manager -- Load all of the patients listed.  Load Patient IDs for all Assigning Authority values.
• PDQ* Supplier -- Load all of the patients listed.  Load Patient IDs one Assigning Authority (your choice) unless you are also a PIX Manager.
• Doc Registries -- Load all of the patients listed.  Load Patient IDs for only the one Assigning Authority assigned to your Registry here.
• XC* Gateways -- Load two patients with last name "Xcpd".  Load Patient IDs for only the one Assigning Authority assigned to your Gateway here.
• SDC/MHD testers -- Load patients with last name "SDC-ONE", "SDC-TWO", "SDC-THREE", "SDC-FOUR"

How?

• To download patients as FHIR Patient Resources, use the download icon to download an individual Patient Resource, or use that icon at the top of the Actions column to download all selected patients as a FHIR Bundle.

The User Manual contains documentation about:

• IHE actors simulated by the tool: https://gazelle.ihe.net/gazelle-documentation/Patient-Manager/user.html#what-is-this-simulator-able-to-do
• How to configure your system in the tool:  https://gazelle.ihe.net/gazelle-documentation/Patient-Manager/user.html#how-to-add-your-system-as-a-receiver
• How to select the Patient ID Assigning Authority for IDs sent by the tool:  https://gazelle.ihe.net/gazelle-documentation/Patient-Manager/user.html#sut-assigning-authorities
• How to use the tool to load Connectathon patients onto your system:  https://gazelle.ihe.net/gazelle-documentation/Patient-Manager/user.htmlsharing-of-demographics-for-connectathon-purposes

 Evaluation:

There is no log file associated with this 'test', so you do not need to upload pre-Connectathon results into Gazelle Test Management for this test.

Overview:

These instructions apply to actors that support the Pediatric Demographics option.  This test asks actors to load their database with patients for "twin" use cases.

Instructions:

Actors that support the Pediatric Demographics Option must run this 'test' to ensure that test patients with proper pediatric demographics are in its system in order to run subsequent tests on the Pediatric Demographics option.

• PIX/PIXv3 Patient Identity Source systems - load these patients into your database.  At the Connectathon, you will perform peer-to-peer tests, you will be asked to send them to a PIX Manager.

• PDQ/PDQv3/PDQm Patient Demographics Supplier systems - load these patients into your database.  At the Connectathon, you will perform peer-to-peer tests, you will be asked to respond to queries for these patients.

The Pediatric Demographics test patients are here: http://gazelle.ihe.net/files/Connectathon_TwinUseCases.xls

We ask you to manually load these patients.  Unfortunately, we cannot use the Gazelle Patient Manager tool because the 'special' pediatric fields are not supported by the tool.

Evaluation:

There is no log file associated with this 'test', so you do not need to upload pre-Connectathon results into Gazelle Test Management for this test.

Overview:

These instructions apply to the Patient Identity Manager actor in the Patient Master Identity Registry (PMIR) Profile.  This test systems that are a PMIR Manager to load their database with Patient Resources formatted for ITI-93 Mobile Patient Identity Feed, to support subscription tests during Connectathon.

Background Information:

Read this section for background information about test patients used for PMIR testing at the Connectathon. Otherwise, for instructions for loading test patients, skip to the Special Instructions below.

In a normal product deployment, a product is operating in an environment with a model for patient identity creation and sharing that remains stable.

At the Connectathon, systems test multiple profiles (for patient management:  PIX, PDQ, PMIR...  for document sharing:  XDS, MHD).   Thus, the Connectathon provides special challenges when requirements for actors differ across IHE Profiles.    Particularly relevant in PMIR and PIXm is the behavior of the server actor in response to the PIXm Query [ITI-83] used in both profiles:

PIXm Patient Identifier Cross-Reference Manager

Source of Patients in the profile: There is no Patient Identity Feed transaction in PIXm. Somehow, in a method currently undefined by the profile, the PIX Manager stores (eg via an HL7v2 or v3 Feed) multiple patient records, and a single patient (person) might have several records on the PIX Manager server that are cross-referenced. 
At the Connectathon, we ask PIX Managers to load “Connectathon Patient Demographics” that are stored in the Gazelle Patient Manager tool.  These contain four Patient Resources for each ‘patient’, each with identical demographics (name, address, DOB), but with different a Patient.identifier (with system values representing the IHE-RED, IHE-GREEN, IHE-BLUE, and IHE-FACILITY assigning authority values).   We expect that the PIX Manager will cross-reference these multiple records for a single patient since the demographics are the same.

QUERY: When a PIXm Consumer sends a PIXm Query [ITI-83] to the PIXm Manager with a sourceIdentifier representing the assigning authority and patient ID (e.g. urn:oid:1.3.6.1.4.1.21367.13.20.1000|IHERED-555), the PIX Manager can respond with [0..*] targetId(s) which contain a Reference to a Patient Resource (one reference for each matching Patient Resource on the server).
At the Connectathon, if a PIXm Consumer queried by a Patient ID in the RED domain (above example), if there is a match, the PIXm Manager would return a response with three matches, one each for GREEN, BLUE, and IHE-FACILITY.

A PMIR Manager Identity Manager

Source of Patients in the profile: The PMIR Patient Identity Source actor sends the Mobile Patient Identity Feed [ITI-93] transaction to the PMIR Patient Identity Manager to create, update, merge, and delete Patient Resources.   
The PMIR Manager maintains one FHIR Patient Resource per patient. The PMIR Manager does not cross-reference separate records for a patient.   The PMIR Manager relies on the Patient Identity Manager as the source of truth about new patient records (Patient Resources), and updates to existing patient records.
At the Connectathon, because some systems support PIX/PIXv3/PIXm and PMIR, we provide separate Patients (in ITI-93 format) with identifiers in a single, different assigning authority - urn:oid:1.3.6.1.4.1.21367.13.20.4000 (aka IHE-GOLD). These patients are used only for PMIR tests; these patients have different demographics than the traditional red/green/blue Connectathon patients.

QUERY: When a PIXm Consumer sends a PIXm Query [ITI-83] to the PMIR Manager with a sourceIdentifier representing the assigning authority and patient ID, if there is a match the PMIR Manager would return a response with the one (matching) Patient Reference.
At the Connectathon, if a PIXm Consumer queried by a Patient ID in the GOLD domain, if there is a match, the PMIR Manager would return a response with a reference to one Patient Reference.

Using the RED/GREEN/BLUE Patients for PIX* testing, and the GOLD Patients for PMIR testing enables us to separate expected results that differ depending on whether a server is a PIX* Patient Identifier Cross-reference Manager or a PMIR Patient Identity Manager in a given test.

Instructions:

In this test, the PMIR Patient Identity Manager loads a set of Patient Resources used in PMIR peer-to-peer tests.  We use a set of Patient Demographics (i.e. patient test data) for PMIR testing that are different than the Connectathon patients for testing the PIX & PDQ Profiles.

The patient test data is a Bundle formatted according to the requirements for a Mobile Patient Identity Feed [ITI-93] transaction.

The PMIR Patient Identity Manager should follow these steps to load the patient test data:

1. Find the test patients on the IHE FTP site:   http://ftp.ihe.net.    Username:  iheyr2    Password:  interop
2. Go to directory:  /Connectathon/test_data/ITI-profiles/PMIR-test-data
3. Download this file:  001_PMIR_Bundle_POST-AlfaBravoCharlie-GOLD.xml   (we only provide the data in xml format)
   That .xml file is a Bundle formatted according to the requirements for ITI-93.
4. POST that file to your PMIR Manager so that you are hosting the three Patient Resources within that file.
5. Note that there are other files in that directory that you can download now, but do not POST them to your Manager until instructed to do so in the Subscription test during the Connectathon.  It is important to wait because posting them during the Connectathon will be a trigger for a subscription.

Evaluation:

There is no log file associated with this 'test', so you do not need to upload pre-Connectathon results into Gazelle Test Management for this test.

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, PDQv3, PDQm, or PMIR 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)
• ITI-78 - Patient Demographics 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 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, HL7v3 Configuration, or FHIR 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, ITI-78), 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, PDQv3, PDQm, or PMIR 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)
• ITI-78 - Patient Demographics 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 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, or ITI-78
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, ITI-78), 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 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 - PIX 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 PDQ Supplier'
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 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. 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 test applies to Patient Identity Consumers 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 - PIX 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 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 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 unknwon 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 Patient Demographics Suppliers 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 Consumer to initiate these queries.  

Test step 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 unknwon 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.

We use the Portable Media Tester application and test plans developed by Northwestern to test PDI media created by a Portable Media Creator.

Connectathon-related Considerations

When you prepare your media for Connectathon testing, you should include on your media DICOM objects that represent the range of images, structured reports, GSPS objects, Key Image Notes, etc that can be produced by your application.   Including a full set (rather than one image) enhances the interoperability testing with your Portable Media Importer test partners.

Testing Instructions

Overview

The APPC profile enables creating Patient Privacy Policy Consent documents of many, many variations.  For Connectathon testing, we have defined tests based on use cases documented in the APPC Profile.   

It will help APPC Content Creators & Content Consumers to be familiar with the APPC tests prior arriving at Connectathon.

(Note:  We currently have no tool for evaluating APPC documents)

Instructions 

Before Connectathon -- for APPC Content Creators:

(1) Read Connectathon test APPC_10_Read_This_First.  Find this on your main Connectathon page in gazelle (menu Connectathon-->Connectathon).  This test specifies policies, organizations, facilities, and providers that you will need to encode in the APPC Policy Consent documents that you will create for Connectathon testing.

(2) Read the APPC Connectathon tests for Case1, Case5, Case6, and "Other".   For Connectathon, you will be required to create 3 documents.  

• You must perform any 2 of these 3 tests: Case1, Case5, Case6.

• You must perform test APPC_Other_Use_Case.

(3) We highly encourage Content Creators to create these documents prior to arriving at Connectathon.

• Create the APPC documents according to the instructions in the test cases.
• Upload your documents into the samples area of gazelle under menu Connectathon-->List of samples.  On the 'Samples to share' tab, find the entry for APPC.
  
• Providing your APPC policy consent document early enables Content Consumers to test with your document in advance.

Before Connectathon -- for APPC Content Consumers:

(1) Read Connectathon test APPC_10_Read_This_First.  Find this on your main Connectathon page in gazelle (menu Connectathon-->Connectathon).  This test specifies policies, organizations, facilities, and providers that Content Creators will use in the policy consent documents they create

(2) Above, we asked Content Creators to provide their sample APPC documents in advance of Connectathon, so...

(3) Check for sample APPC documents provided by Content Creators:

• In gazelle, look under menu Connectathon-->List of samples.  
• Check the 'Samples available for rendering' tab under the 'APPC' entry.

Evaluation

Finally, for both Creators & Consumers

1. In Gazelle, select menu Connectathon-->Pre-Connectathon testing 
2. Find the entry for this test instance, and change the status to "Verified by Vendor".  This is a signal to the Technical Manager that you have completed the task associated with your actor..

Overview

This is a family of tests. Each of the tests (40180-01, 02, 03, ...) is for a specific document type, but the instructions are the same.  We have different test numbers to let us keep track of the document type in the results database.

Please refer to the list of document types in the table below.

• Content Creators: You will create a document defined in a IHE profile -- CDA format and other formats -- and provide that as a sample for other participants to examine.
• Content Consumers:  You will import the samples into your system and test with them prior to the Connectathon to ensure that you can process the document.

The goal is 'No Surprises' at the Connectathon

Instructions for Content Creators:

Creators....please upload your samples two weeks before the normal due date for pre-Connectathon test results. This is to allow other participants to review your result.

1. Create a document according to the test number (see table below). Name the file using this convention:

• SYSTEMNAME_TESTNUMBER_type.xml, for example
• EHR_XYZmed_40180-01_XDSMS_Referral.xml

• Get your system name right, get the test number right, use common sense to express the type.

2. Upload the document into Gazelle Test Management under menu Connectathon-->List of samples.

• Click on the Samples to share tab for your system and add the appropriate document.

3. Finally in the Gazelle Pre-connectathon Testing "Tests to do" page, upload a brief note (txt file) indicating this task is done and upload the file as the results for this test.

4. Finally, change the status of the pre-Connectatho test to "Verified by Vendor".  This is a signal to the Technical Manager that you have completed the task associated with your actor.

5. Repeat these instructions for each document type you can create.

Instructions for Content Consumers:

1. Find samples uploaded by other vendors for test 40180-xx in Gazelle Test Management under menu Connectathon -> List of samples on the Samples available for rendering tab. (When a Content Creator or Form Filler has uploaded a sample, you will see a small triangle in front of their system name.)  This page will evolve as vendors add samples, so be patient. The deadline for Creators to submit samples is typically two weeks prior to the pre-connectathon test deadline. Managers of each event publishes the deadline.

2. Retrieve the documents created by the other vendors. "Process/render" them so that you are confident your software understands the content.

For Content Consumer actors, "Process/render" means to apply one or more of the options:

• View
• Document Import
• Section Import
• Discrete Data Import

For Form Manager actors, "Process/render" means to take the prepop data and make it part of the form.

3. You will perform one or more of those actions on the sample documents and then provide evidence that you have performed this action. That evidence will be some screen capture or database dump from your system.  Upload that evidence into Gazelle Test Management as the results for this pre-Connectathon test.

Document Types for this sample-sharing test:

Overview

In this “test”, Creators of DICOM objects submit a sample data set that will be reviewed by other Consumer test partners. The goal of this test is to prepare Consumer actors (Image Manager, Image Display) so they are not surprised during Connectathon events.

In order to facilitate this testing, Creators....please submit your samples 2-3 weeks before the usual pre-Connectathon test deadlines. 

Instructions for DICOM Image or SR Creators;

1. Determine a representative set of image(s), or a Structured Report, that would help other actors understand your content. We do not expect you to generate images for every combination of parameters; pick one set of parameters. However, if your system supports more than one SOP class, or can use more than one transfer syntax, we expect you to upload representative samples for each.  Create file(s) of these objects (i.e. .dcm files).
2. Assuming you have this ability, render the images or SR that you produced as a reference. The goal is for an Image Display actor to examine your rendering and compare to what their software produces. Perform a screen capture and/or save as JPEG or other reasonable format.
3. Upload sample objects and the screen capture snapshot into Gazelle Test Management (EU or NA) under Connectathon-->Connectathon--> List of Samples. On the Samples to share tab, upload your sample image(s) under the DICOM_OBJECTS entry.  On the "summary" tab for the sample, you will see a list of Attributes.  Choose the attribute that best describes your sample (e.g. "NMI" for a Nuc Med image, "SWF.b" for a general sample for that profile, etc)  Refer to these help pages for details on managing samples in Gazelle.
4. Some image sets are too large to upload, and Gazelle reports an error. If you encounter this, please contact the Connectathon Technical Project Manager for instructions on alternatives.
5. Create a short txt file indicating you have completed the upload step. Upload '''that''' txt file into gazelle as the result file for this pre-Connectathon test.
6. You may submit more than one set.
7. There is no specific evaluation for this test.  Feedback comes as your partner Image Display and Image Manager partners test with your images in their lab.

Instructions for DICOM Consumers;

1. Find sample images uploaded by other vendors in Gazelle Test Management (EU or NA) under Connectathon-->Connectathon -> List of samples.    On the Samples available for rendering tab you will find DICOM_OBJECTS submitted by other vendors.  (When a Content Creator or Form Filler has uploaded a sample, you will see a small triangle in front of their system name.)  This page will evolve as vendors add samples, so be patient. 
2. Find the samples that are relevant for your storage or display application.
3. Retrieve the DICOM or zip files created by the other vendors.  Refer to these help pages for details on this task in Gazelle.
4. Examine/import/render them so that you are confident your software understands the content.
5. When you are finished, create a .txt or other file that lists the samples you tested with, and a brief comment on your result (eg "ok", or "could not render"). Upload that txt file into gazelle as the result file for this pre-Connectathon test.
6. If you find issues with the images, send an email to the Connectathon Manager.
7. The evaluation of this test is performed by examining the text you provided to make sure you made a good faith effort to review the sample images. If you find problems with some samples, we will give your feedback to the Modality test partner.
8. The goal is no surprises.

Finally, for both Creators & Consumers

1. In Gazelle Test Management, select menu Connectathon-->Pre-Connectathon testing 
2. Find the entry for this test instance, and change the status to "Verified by Vendor".  This is a signal to the Technical Manager that you have completed this task.

Overview

Prior to the Connectathon, it is very beneficial for participants to have access to sample DICOM objects, HL7 messages,CDA documents, etc produced by their test partners' applications.  We use Gazelle as an intermediary to exchange samples.  In Gazelle, a "sample" is any object or message that an application creates and is used by another application.

This table lists samples from IHE Eye Care domain profiles U-EYECARE, GEE, and EC-Summary.  Beneath the table are instructions for Creators to upload samples into Gazelle prior to the Connectathon, and instructions for Consumers who want to download samples to test in advance of Connectathon.  Note that due to the size of some DICOM objects, we have separate instructions for exchange of DICOM samples.

The deadline for sharing samples is typically 2-3 weeks prior to the Connectathon.  The due date will be announced by the Technical Project Manager.

Instructions for Creators

1. Capture the sample content as produced by your system.  Create a file containing the contents of that message.
2. In Gazelle,select menu Connectathon-->Connectathon-->List of samples
3. On the "systems" dropdown list, select your system name
4. On the "Samples to share" tab, find the entry for your sample, matching Column 1 above
5. Upload the file containing your sample.  You may refer to this help page if you have never used Gazelle to upload samples
   

Instructions for Consumers

1. In Gazelle,select menu Connectathon-->Connectathon-->List of samples
2. On the "systems" dropdown list, select your system name
3. On the "Samples available for rendering" tab, you will see an entry for each sample type for which you are a Consumer.
4. The contents of this tab changes over time, as Creators upload samples.  Entries with a "+" sign contain samples from Creators. 
5. Download available samples.  You may refer to this help page if you have never downloaded samples from Gazelle.

Finally, for both Creators & Consumers

1. In Gazelle, select menu Connectathon-->Pre-Connectathon testing 
2. Find the entry for this test instance, and change the status to "Verified by Vendor".  This is a signal to the Technical Manager that you have completed this task.

Overview

The goal of this “test” is to provide samples for other vendors to display. You should submit a “representative sample” of the data produced by your system.

GSPS objects are supported in the Consistent Presentation of Images profile. CPI Evidence Creator actors create GSPS objects (requirement) and may optionally produce images. Likewise, CPI Acquisition Modalities actors create images and GSPS objects.

Each system (Modality or Evidence Creator) should submit samples of the Image and/or GSPS objects. The goal of this test is to prepare Consumer actors (Image Manager, Image Display) so they are not surprised during Connectathon.

In order to facilitate this testing, Creators....please submit your samples 2-3 weeks before the usual pre-Connectathon test deadlines. 

Instructions for DICOM Image and GSPS Creators:

FIRST, prepare the samples-->

Both Modality and Evidence Creator systems must provide samples that include both images and GSPS objects.  Acquisition Modalities will be the source of images for which GSPS objects will be created. 

The GSPS objects and images created by the Modality or Evidence Creator should be of the same genre as those normally generated by the Evidence Creator during expected clinical use.

To insure adequate testing of capabilities, the set of GSPS objects you create should include at least 15 elements drawn from the following GSPS capabilities:

1. a selection of display area (i.e., zoom)
2. a spatial transformation (rotation and/or flip)
3. a discernable adjustment to the Modality LUT, if appropriate to the image object
4. a discernable adjustment to the VOI LUT
5. a discernable adjustment to the Presentation LUT
6. a setting of display shutters (extra worthless brownie points to people who do bitmap shutters)
7. text annotation boxes
8. an anchor line associating a text box located in display coordinates with an anchor point in image coordinates
9. graphical objects in image coordinates
10. graphical objects in screen coordinates
11. specification of multiple graphical layers with different suggested colors
12. frame selection, if the associated image object is multi-frame
13. specification of mask and contrast frames for subtraction, if appropriate for the image object
14. a bitmap overlay

SECOND, upload your samples -->

1. Upload sample image and GSPS objects and the screen capture snapshot(s) into Gazelle Test Management (EU or NA) under Connectathon-->Connectathon--> List of Samples. On the Samples to share tab, upload your sample image(s) under the GSPS entry.   Refer to these help pages for details on managing samples in Gazelle.
2. Assuming you have this ability, render the objects you produced as a reference. The goal is for an Image Display actor to examine your rendered images/GSPS objects and compare to what their software produces. Perform a screen capture and/or save as JPEG or other reasonable format.  Upload the screenshot into Gazelle Test Management.
3. Create a short txt file indicating you have completed the upload step. Upload '''that''' txt file into Gazelle as the result file for this pre-Connectathon test.
4. There is no specific evaluation for this test.  Feedback comes as your partner Image Display and Image Manager partners test with your images in their lab.

Instructions for DICOM Image and GSPS Consumers:

1. Find sample images & GSPS objects uploaded by other vendors in Gazelle Test Management (EU or NA) under Connectathon-->Connectathon -> List of samples.    On the Samples available for rendering tab under the GSPS entry, you willl find samples and screen captures submitted by other vendors.  This page will evolve as vendors add samples, so be patient. 
2. Retrieve the DICOM or zip files created by the other vendors.  Refer to these help pages for details on this task in Gazelle.
3. Examine/import/render them so that you are confident your software understands the content.
4. When you are finished, create a .txt or other file that lists the samples you tested with, and a brief comment on your result (eg "ok", or "could not render"). Upload that txt file into gazelle as the result file for this pre-Connectathon test.
5. If you find issues with the images, send an email to the Connectathon Manager.
6. The evaluation of this test is performed by examining the text you provided to make sure you made a good faith effort to review the sample images. If you find problems with some samples, we will give your feedback to the Modality test partner.
7. The goal is no surprises.

Finally, for both Creators & Consumers

1. In Gazelle Test Management, select menu Connectathon-->Pre-Connectathon testing 
2. Find the entry for this test instance, and change the status to "Verified by Vendor".  This is a signal to the Technical Manager that you have completed this task.

Overview

The goal of this “test” is to provide MRRT Report Templates that are 'consumed' by other systems.

In order to facilitate this testing, Creators....please submit your samples 2-3 weeks before the usual pre-Connectathon test deadlines. 

Instructions for Creators:

FIRST, prepare the samples-->

We expect the Report Template Creator to create and provide a “representative sample” of the templates that represents the template-creating capabilities of your application AND that incorporate as many of the template structures defined in the MRRT Profile as possible. he better the samples you provide, the better interoperability testing we will have.

 Using your Report Template Creator application, create a template using this guidance:

1. the report template should contain at least on entry under coded_content
2. Include at least one TEXT-type field in the report template
3. Include at least one NUMBER-type field in the report template
4. Include at least one selection list field in the report template
5. Include at least one DATE-type field in the report template
6. Include at least one TIME-type field in the report template
7. You may optionally include a MERGE-type field in your report template
8. You may include other content as long as it follows the format specified for MRRT report templates

SECOND, upload your samples -->

1. Upload sample report templates and optional screen capture snapshot(s) into Gazelle Test Management (EU or NA) under Connectathon-->Connectathon--> List of Samples. On the Samples to share tab, upload your sample image(s) under the MRRT entry.   Refer to these help pages for details on managing samples in Gazelle.
2. Assuming you have this ability, render a sample report using the template(s) you produced.  Perform a screen capture and/or save as JPEG or other reasonable format.  Upload the screenshot into Gazelle Test Management.
3. Create a short txt file indicating you have completed the upload step. Upload '''that''' txt file into Gazelle as the result file for this pre-Connectathon test.
4. There is no specific evaluation for this test.  Feedback comes as your partner Image Display and Image Manager partners test with your images in their lab.

Instructions for Consumers:

1. Find sample MRRT Report Templates uploaded by other vendors in Gazelle Test Management (EU or NA) under Connectathon-->Connectathon -> List of samples.    On the Samples available for rendering tab under the MRRT entry, you willl find samples and screen captures submitted by other vendors.  This page will evolve as vendors add samples, so be patient. 
2. Retrieve the files created by the other vendors.  Refer to these help pages for details on this task in Gazelle.
3. Examine/import/render them so that you are confident your software understands the content.
4. When you are finished, create a .txt or other file that lists the samples you tested with, and a brief comment on your result (eg "ok", or "could not render"). Upload that txt file into gazelle as the result file for this pre-Connectathon test.
5. If you find issues with the images, send an email to the Connectathon Manager.
6. The evaluation of this test is performed by examining the text you provided to make sure you made a good faith effort to use the template in your system. If you find problems with some samples, we will give your feedback to the Modality test partner.
7. The goal is no surprises.

Finally, for both Creators & Consumers

1. In Gazelle Test Management, select menu Connectathon-->Pre-Connectathon testing 
2. Find the entry for this test instance, and change the status to "Verified by Vendor".  This is a signal to the Technical Manager that you have completed this task.

Overview

The goal of this “test” is for the Portable Media Creator system to prepare, in advance of the Connectathon, your PDI media that the Portable Media Importer partners will test with during the Connectathon.   Doing this in your home lab will save you valuable time during Connectathon week.

All PDI Portable Media Creators must support CD media; USB and DVD are optional. The media you create should contain a “representative sample” of the data produced by your system.  Complete and representative data on your media makes for a better interoperability test.

Instructions for PDI Portable Media Creators:

Prior to Connectathon, you should create two copies of your media: CD, USB, and/or DVD, depending on what you support.  On the first day of the Connectathon, you will give one copy to Connectathon monitor who is evaluating PDI tests.  You will keep one copy and use it for your peer-to-peer tests with your Importer partners.

Use the following guidelines when creating your media:

1. Modality systems shall put all IOD types on the media that it is capable of creating (eg. MG, US, KOS, SR, CAD-SR etc).  If you can create GSPS or KOS objects, these should also be included.
2. PACS vendors & multi-modality workstations shall put at least 5 different image types on their media.  If they support SR, KOS, etc, they shall also put those types on the media.
3. Media creators will create two copies of appropriate media with your images and other DICOM objects.
4. Label your physical media.  The label should contain:

• your system name in Gazelle Test Management
• your table location
• and the name of a technical contact at your table at the Connectathon

Note that you may not have the information to make your label until you arrive at Connectathon.

Optional:

Starting in 2019, the ITI and Radiology Technical Framework contains specifications for including PDI and XDM content on the same media.  If your Portable Media Creator supports both the PDI and XDM Profile, you should create media with the appropriate content.   For details, see:

• RAD TF-3: 4.47.4.1.2.3.3 "Content when Grouping with XDM"
• ITI TF-1: 16.1.1 "Cross profile considerations - RAD Portable Data for Imaging (PDI)"
• ITI TF-2b: 3.32.4.1.2.2. "Content Organization Overview"
• Connectathon test "PDI_with_XDM_Create"

Finally,

1. In Gazelle Test Management, select menu Connectathon-->Pre-Connectathon testing 
2. Find the entry for this test instance, and change the status to "Verified by Vendor".  This is a signal to the Technical Manager that you have completed this task. (There is no file to upload for this pre-Connectathon test.)
3. There is no specific evaluation for this test.  Feedback will come when your partners import the contents of your media during Connectathon week.
4. Make sure you pack up the media you created and bring it to Connectathon!

Overview

Starting at the EU2018 Connectathon, we added a new no-peer Connectathon test that asks XDS-I Imaging Document Source systems to create manifests for two studies provided by Connectathon technical managers. This differs from earlier years where Imaging Document Source systems created manifests for studies they provide (you will still be able to do that for peer-to-peer Connectathon tests).

This pre-Connectathon test gives you the opportunity to prepare those manifests before you arrive at Connectathon, to save you some time in the beginning of the week. 

Instructions for XDS-I.b Imaging Document Source:

The Connectathon test you are preparing for contains all of the instructions, so we will not duplicate them here.

Instead...

1. Go to Gazelle Test Management for your Connectathon.
   For EU: https://gazelle.ihe.net/EU-CAT/home.seam or for NA: https://gazelle.iheusa.org/gazelle-na/home.seam
2. On your Main Connectathon Page, filter the list of tests, and find the no-peer Connectathon test "XDS-I.b_Manifest_and_Metadata".
3. Read the "Test Description" section to get an overview of the test.
4. Perform test steps 10 through 40.  This will enable you to download the two DICOM studies (a DX study and a CT study) onto your Imaging Document Source, create two associated XDS-I manifests, and also upload the manifest for the CT study into the samples area of Gazelle.
5. We will not evaluate your manifest prior to Connectathon.  You will also have to wait until Connectaton week to submit your manifests to the NIST XDS Toolkit so that your metadata can be checked.

We hope that reading the new Connectathon test, loading the two studies, and preparing the manifests in advance of the Connectathon, is helpful for you.

We use this 'test' to inform you of the gazelle SVS simulator available for your testing.  

SVS actors simulated:

• Value Set Consumer
• Value Set Reponsitory.

Location of the tool: http://gazelle.ihe.net/SVSSimulator

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

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

There are no pre-Connectathon results to upload for this 'test'.

At the Connectathon, the SVS tests assume that a pre-defined set of value sets have been loaded on all of the Value Set Repository actors under test.

Instructions

• Prior to the Connectathon, SVS Repositories must load these value sets: http://gazelle.ihe.net/content/gazelle-value-sets
• Note that these value sets are also used in the SVS simulator tool referred to in test 14500 above
• Your Repository may also contain other additional value sets

Evaluation

Ther are no result files to upload into gazelle for this test.  Preloading these prior to the Connectathon is intended to save you precious time during Connectathon week.

Test Your Server with Gazelle XDStar Client Simulator

We use this test to inform you of the gazelle XDStar Client simulator tool available for your testing.  It simulates 'client' actors in XDS.b, XDR, XCA, MPQ, DSUB, XCPD, XDS.b On-demand Docs option, XCF, XCA-I and XDS-I.b

We encourage you to test with the simulator prior to the Connectathon, but there are no pre-Connectathon test results files to upload for this test.

***Note that at this time, the CAS login on the XDStarClient only works with username/passwords for the European instance of gazelle (EU-CAT), not with the North American gazelle (gazelle-na). Until this is implemented, testers will have to create a new user account. This can be done using the CAS login link at the upper-right of the XDStarClient.

Instructions

1. Access the XDStarClient: http://gazelle.ihe.net/XDStarClient/home.seam Configure your server using the "'SUT Configurations'" menu

2. Under the SIMU-Initiators menu, find the message you want to receive:

• ITI-18 : Register Stored Query (XDS.b)
• ITI-38 : Cross Gateway Query (XCA)
• ITI-39 : Cross Gateway Retrieve (XCA)
• ITI-41 : Provide and Register Set-b (XDS.b / XDR)
• ITI-43 : Retrieve Document Set (XDS.b)
• ITI-51 : Multi-Patient Stored Query (MPQ)
• ITI-52 : Document Metadata Subscribe (DSUB)
• ITI-54 : Document Metadata Publish (DSUB)
• ITI-55 : Cross Gateway Patient Discovery (XCPD)
• ITI-56 : Patient Location Query (XCPD)
• ITI-61 : Register On-Demand Document Entry (XDS.b On-Demand Docs option)
• ITI-63 : Cross Gateway Fetch (XCF)
• PHARM-1
• RAD-55 : WADO Retrieve
• RAD-68 : Provide and Register Imaging Document Set - MTOM/XOP
• RAD-69 : Retrieve Imaging Document Set #
• RAD-75 : Cross Gateway Retrieve Imaging Document Set

3. Follow the instructions on the page to send the selected message to the server you have configured Evaluation

Evaluation

The purpose of this test is to provide sample messages to test with your server. There are no pre-Connectathon test results files to upload for this test.

Overview of the test

Prior to arriving at the Connectathon, it is important for participants testing XUA to be familiar with:

• the Connectathon testing scenario for XUA, or for the IUA profile with the SAML Token option
• the tool used to provide assertions for XUA tests -- the Gazelle-STS Security Token Service

Instructions

(1) Read the Connectathon test scenario

• In Gazelle Test Management for your Connectathon (EU or NA), your Main Connectathon Page contains test XUA_Read_This_First.  Read this test now as part of your pre-Connectathon test preparation.   (If you are also testing IUA, there is a similar test: IUA_GetAndIncorporateToken_SAML.)

(2) Locate and use the Gazelle-STS Security Token Service

To familiarize yourself with the Gazelle-STS tool used for Connectathons:

• Read the STS information page: https://gazelle.ihe.net/gazelle-documentation/Gazelle-STS/user.html.  That page describes how to use the tool to request, renew, cancel, and validate a security token.   Systems testing X-Service User and X-Service Provider should use the STS prior to the Connectathon so you are familiar with its use.

Evaluation 

There is no specific evaluation for this test.  

Create a text file stating that you have followed the instructions above. Upload that text file into your local gazelle as the Log Return file for pre-Connectathon test 11120.