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

Instructions

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

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

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

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

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

Evaluation

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

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

Instructions

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

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

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

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

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

Evaluation

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

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

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

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

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

Instructions

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

Evaluation

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

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

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

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

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

Instructions

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

Evaluation

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

Overview

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

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

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

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

One or more of these tools may be available from within the Gazelle EVS.  (Note:  The links below are for resource pages for each tool.). (For some testing events, the list of DICOM validators may be smaller or larger.)

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

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

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

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

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

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

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

Finally, capture your results:

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

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

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

Reference:  ITI TF-3: 5.5.

Instructions

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

Evaluation

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

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

Test Summary

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

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

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

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

Who performs this test

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

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

Instructions

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

Evaluation

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

This test has been deprecated as of the 2022 IHE Connectathon

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

Test Summary

You will use the Gazelle EVSClient tool to validate:

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

Scope of testing available in Gazelle EVSClient

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

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

Who this test applies to

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

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

Instructions

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

Evaluation

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

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

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

Instructions

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

Evaluation

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

Overview of the test

This test has two parts:

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

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

(1) Identify your SOLE Event Reports

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

(2) Test your SOLE Event Reports

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

Evaluation

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

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

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

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

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

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

Instructions

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

Evaluation

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

Content Creator creates a Workflow dDocument and validates it

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

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

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

Instructions

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

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

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

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

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

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

Evaluation

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

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

Content Updater updates a Workflow Document

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

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

Instructions

For this test, you will update a workflow document 

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

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

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

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

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

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

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

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

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

Evaluation

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

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