XC_Read_This_First
This informational 'test' provides an overview of peer-to-peer Connectathon testing for the cross-community (XC*) family of IHE Profiles. Please read what follows and complete the preparation described before the Connectathon.
Overview
Approach for Connectathon testing of cross-community profiles (XCA, XCPD, others):
Cross-community test scenarios are more complex than most in the Connectathon because of the effort to set up the initiating and responding communities' configuration.
Try to be efficient in testing gateways that support Cross-Community profiles. If your Gateway also supports multiple XC* profiles, you will want to run these tests while the XCA configurations are in place.
Explanatory resource material for these tests:
Please refer to these resources used to manage cross-community profile testing. These are shared during the Preparatory phase of the Connectathon:
- Each Initiating or Respondng Gateway test system is assigned to represent either a "Red", "Green", or "Blue" community for Connectathon week.
- An overview of Cross-Community (multiple affinity domain) testing is here: https://gazelle.ihe.net/content/connectathon-doc-sharing-testing-3-xds-affinity-domains-0
- Specific red/green/blue assigning authority assignments for each Connectathon are documented in this google spreadsheet.
Testing Scope and 'Pass' Criteria
How do I know if I have enough tests to "pass" at Connectathon??
This is what we will look for when we grade the XCA profile Connectathon tests:
-- Any XC* actor doing Supportive testing:
- You will Pass if you have **one verified peer-to-peer test** for a given profile/actor pair. The Connectathon Monitors will be focusing most of their attention assisting Gateways doing Thorough testing.
- Supportive systems are not required to test async (because you tested it a previous Connectathons). Because you are supportive, a test partner may ask you to help them test async.
-- XCA Initiating Gateways doing Thorough testing:
- For Cross-Gateway Query [ITI-38], you must demonstrate the ability to translate the Patient ID known in your community into the patient ID with the assigning authority in known in two different responding communities (eg, you take the 'red' patient ID as known in your initiating community and query a Responding Gateway with a 'blue' patient ID and another Responding Gateway with a 'green' patient ID).
- For Cross-Gateway Retrieve [ITI-39], you must demonstrate the ability retrieve from two different communities and consolidate those retrieved documents into your initiating community (e.g., if you are a 'red' Initiating Gateway, you must retrieve from both a 'blue' and 'green Responding Gateway).
- You do not have to do #1 and #2 three different times. If you have tested with Responding GWs from two different communities, you will have enough to pass. You may be asked to perform more tests in order to help your partners complete their work.
- You must do all your tests using TLS.
- Async testing:
- **If you have chosen to support the "Asynchronous Web Services Exchange (WS-Addressing-based)" option**, you must demonstrate once, your ability to do the query & retrieve using async communication. If you have signed up for this option, you will see a related test to perform, but you can pass as an Initiating Gateway without supporting this option.
- **If you have chosen to support the "AS4 Asynchronous Web Services Exchange" option**, you must demonstrate your ability to do the query & retrieve using AS4 async communication. If you have signed up for this option, you will see a related test to perform, but you can pass as an Initiating Gateway without supporting this option. Because AS4 is a newer requirement, we ask you to perform the test with two partners (if there are two).
-- XCA Responding Gateways doing Thorough testing:
- You must complete the XCA_Query_and_Retrieve test with at least two different Initiating Gateways. You may be asked to perform more tests in order to help you partners complete their work. (While your Init GW partner is likely to be in a different patient ID domain -- eg the Init GW is Red, your Resp GW is Blue -- note that since the Init GW does the patient ID translation all queries look the same from the Resp GW's point of view.)
- You must demonstrate your ability to support asynchronous communication You cannot pass as an XCA Responding GW without demonstrating async support. ***NEW as of 2019***, Responding Gateways shall support one of two types of async messaging. You may support both:
- Asynchronous Web Services Exchange (WS-Addressing based). This is the original async protocol included in the XCA profile.
- AS4 Asynchronous Web Services Exchange. This was added to the XCA Profile in fall of 2018.
Configuration / Test Data
homeCommunityID:
Each XC*IGateway is assigned a homeCommunityId value for use during Connectathon week. Gateways can find the homeCommunityId for their system and for their partner gateways in Gazelle Test Management under menu Preparation-->OID Registry
Configuration Setup:
XCA Initiating Gateways...
- must be configured for all Responding Gateways identified as test partners, eg, if you are a "Red" Initiating Gateway, you should be prepared to test with "Blue" and "Green Responding Gateways
- must be prepared to map Patient IDs in its community to patient IDs known by the responding community(ies). The Initiating Gateway must query each Responding Gateway with the correct patient identifier corresponding to the Responding GW's community.
- for Initiating GWs that support the XDS Affinity Domain option, you must trigger a "Find Documents" query and a "Retrieve Document Set to the Initiating Gateway to trigger the Cross-Gateway query and retrieve. You can do this several ways:
- use the NIST XDS Toolkit to act as an XDS.b Document Consumer simulator to quedry * retrieve
- ask another vendor's XDS.b Doc Consumer to help with the test
- or the Initiating Gateway may use its own application to trigger the Cross-Gateway Query and Retrieve
XCA Responding Gateways...
- The Responding Gateway will be configured to query the XDS.b Document Registry and retrieve from the Document Repository in its community. For XCA tests, it is OK if it is your own company's Registry or Repository in your local community.
--or-- - The Responding Gateway will have access to the test patient's documents through non-IHE mechanisms.
XCA-I Responding Imaging Gateways...
- must be configured to access one (or more) XDS.b Registry/Repository pairs that hold documents (ie DICOM manifests) for the XCA-I test patients. For XCA-I tests, it is OK if it is your own company's Registry or Repository in your 'local' community.
- must have access to an Imaging Document Source with the XDS-I DICOM Studies in order for the XCA-I query/retrieves to work. This Imaging Document Source must be on a test system from another vendor (eg company AAA's Responding Imaging Gateway cannot retrieve images from its own Imaging Document Source)
XCA-I Initiating Imaging Gateways...
- The Initiating Imaging Gateway must be in a 'local community' with a Registry/Repository and an Imaging Doc Source that contains the XDS-I test patients. It is OK for the Init Imaging GW, Registry, Repository and Imaging Doc Source to be from the same company
- For XCA-I testing (unlike for XCA testing), we do not use the NIST XDS toolkit to trigger query and retrieves in the initiating community. The Imaging Document Consumer must initiate the query and retrieve.
- Initiating Imaging Gateways must be configured to query Responding Imaging Gateway(s) identified as a test partner. Initiating Imaging Gateways must query for the correct patient ID (ie you must be aware of whether you are in a 'red', 'green' or 'blue' patient ID domain.
XCPD Responding Gateways have test data identified in the "XCPD_Responding_GW_Setup" test.
You must demonstrate your ability to support asynchronous communication You cannot pass as an XCPD Responding GW without demonstrating async support. ***NEW as of 2019***, Responding Gateways shall support one of two types of async messaging. You may support both.
- Asynchronous Web Services Exchange (WS-Addressing based). This is the original async protocol included in the XCA profile.
- AS4 Asynchronous Web Services Exchange. This was added to the profile in fall of 2018.
XCA / XCPD test patient:
We have a specific test patient we use for XCA and XCPD tests.
- Patient XCPD^Pat with patient IDs in 3 different communities: IHERED-1039 or IHEGREEN-1039 or IHEBLUE-1039
- The XC* profiles do not define how the Gateways learn of the Patient IDs. The Gateways may have been pre-loaded connectathon demographics, may receive a Patient Identity Feed, or may learn of Patient IDs by some other means. Initiating Gateways will need to do mapping of these these patient IDs to the appropriate value in the Responding Gateways it is connected to.
This patient is part of the 'connectathon demographics' which should be pre-loaded on XDS.b Registries, PIX Managers and Patient Identity Sources prior to the Connectathon. (Note that this patients also available in the 'pre-load' demographics provided in the Gazelle PatientManager tool. See instructions in preparatory test Preload Connectathon Test Patients.)
XCA test data -- documents to query/retrieve:
The XCA Responding Gateway must host in its community documents for the test patient. If you have an XDS Registry/Repository behind your Responding Gateway, host documents there. If your Responding Gateway is not using XDS.b, it will find another way to host documents for the test patient.
- If you have documents with a patient ID in metadata that matches the test patient, you may use them.
- Alternatively, in the NIST XDS Toolkit for the Connectathon we have test documents for test patient *1039*. You can use the NIST XDS Toolkit to Provide-and-Register the document to the Repository/Registry in your responding community, using correct patient ID IHERED-1039, IHEGREEN-1039 or IHEBLUE-1039. Find the templates for these documents in the XDS Toolkit: Select Connectathon Tools. Under "Load Test Data", you will find an entry to "Provide and Register" test data.
XCA-I patient and test data:
For XCA-I, each Initiating & Responding Gateway represents and XDS affinity domain with an Imaging Document Source, and XDS Registry and Repository. Each XCA-I community must host a DICOM Study and associated Manifest. for XCA-I testing, we one of the three DICOM studies that the Imaging Document Source used for XDS-I.b tests.
- They are stored in a zip file in Google Drive under: IHE Documents > Connectathon > test_data > RAD-profiles > XDS-I.b_test_data
- They may also be stored on the DICOM Central Archive at the Connectathon
- For reference, find a summary of key attributes in the DICOM headers for these studies here.
Summary of the DICOM studies
Patient ID Procedure Code Modality Series Count Image Count --------------------------------------------------------------------- C3L-00277 36643-5 DX 1 1 C3N-00953 42274-1 CT 3 11 <-----we use this one for XCA-I TCGA-G4-6304 42274-1 CT 3 13 Procedure Codes (0008,1032) --------------------------- 36643-5 / (LOINC / 2.16.840.1.113883.6.1) / XR Chest 2V 42274-1 / (LOINC / 2.16.840.1.113883.6.1) / CT Abd+Pelvis WO+W contr IV
Patient IDs to use with the XDS-I Manifest for the XCA-I tests.
The Patient ID in the DICOM header for the images is considered the 'local' or 'departmental' Patient ID for this patient, (ie sourcePatientId in the DocumentEntry metadata). When submitting a Manifest for this study to an XDS Repository/Registry, the Imaging Doc Source must use the affinity domain ID for the patient in the XDS metadata for the submitted manifest. This patient has Patient IDs included in the Connectathon Patient Demographics pre-loaded onto each Registry at Connectathon as follows:
For the CT study with "local" Patient ID C3N-00953, the affinity domain Patient IDs are listed here:
- IHERED-2737^^^IHERED&1.3.6.1.4.1.21367.13.20.1000&ISO
- IHEGREEN-2737^^^IHEGREEN&1.3.6.1.4.1.21367.13.20.2000&ISO
- IHEBLUE-2737^^^IHEBLUE&1.3.6.1.4.1.21367.13.20.3000&ISO
The Patient ID in the manifest will depend on the patient ID affinity domain (red, green, blue) of your local Registry & XCA-I Initiating or Responding Imaging Gateway.
Evaluation
There is no evaluation for this informational test. If the systems testing XC* profiles do not do the set-up described above, then cross-community tests at Connectathon will not work.