Introduction

To enable interoperability testing at an IHE Connectathon, some actors require OIDs to be assigned for various attributes in the messages they will exchange.  Gazelle Test Management assigns these OID values.

For example:

• homeCommunityID OID for Gateway actors in XCA, XCPD...
• patient ID assigning authority OID for actors that create Patient IDs:  e.g., Patient Identity Sources, Radiology ADT systems, more...
• organization ID OID for actors sending/receiving HL7v3 messages
• repositoryUniqueId OID for XDS Document Repositories
• and more...

Instructions

• Log in to Gazelle Test Management (https://gazelle.ihe.net/TM - the link may be different for your testing session)
• Access menu Preparation-->OID registry
• Note that the Connectathon Technical Manager will announce when OIDs have been generated for a test session.  If you don't see any OID entries on this page, then they have not been generated yet.
• Find the OIDS for your system:
• Use the dropdown list at the top of the page to search for the OIDs for your "System". 
• If there is no entry for your system, it means that you have not registered for an actor that needs an OID assignment
• Find the OIDs for your test partners:
• Use the dropdown list to filter by OID "Label" or "Profile / Actor" to find the OIDs for your test partners,
  e.g.:
• Initiating Gateways need the homeCommunityId OID of their Responding Gateway partners
• XDS Document Repositories need the sourceId OID of their Document Source partners
  
  
• Special note for FHIR Servers:  For some FHIR-based profiles, a server base URL may be used instead of an assigning authority OID.  For example, for a PIXm Patient Identity Source system, a FHIR server with base http://fhir.mydomain.com would use that value as the patient ID assigning authority (rather than an assigning authrority such as urn:oid:1.2.3.4.5).    In this case, the FHIR Server may use its own base URL, rather than the OID value assigned in Gazelle Test Management.

Once you find the OIDs you need, configure your Test System in advance so that you are ready to start testing at the beginning of the Connectathon.

Evaluation

There is no result file to upload into Gazelle Test Management for this test.

Introduction

This informational 'test' provides an overview of APPC tests and defines value sets used when creating Patient Privacy Policy Consent documents during Connectathon. Please read what follows and complete the preparation described before the Connectathon.

Instructions

WHICH APPC TESTS SHOULD I RUN?

The APPC profile enables creating Patient Privacy Policy Consent documents of many, many variations.  We have created test cases that cover some of the common use cases in the APPC profile for consent documents that would be commonly created for patients in health care facilities, eg consent disclose patient's data to an facility or to restrict disclosure of data from a specific individual provider.

Content Creators: 

• Run tests for two of the APPC uses cases; you may choose from the Meta test which two you want to run.  Test names are APPC_Case*.
• Run one test -- APPC_Other_Use_Case -- that allows you to create a Patient Privacy Policy Consent document of your choosing. We hope you use this to demonstrate the depth & breadth of your capabilities as a APPC Content Creator.
• Support your APPC Content Consumer test partners that want to demonstrate their View or Structured Policy Processing capabilities using your APPC document(s).
• Optional:  There is no requirement in APPC that the Content Creator be able to act as an XDS Doc Source and thus be able to submit your APPC documents to an XDS Repository/Registry.  If you have this capability, you can run test APPC_Submit_PolicyConsentDoc.

Content Consumers: 

• If you support the View Option, we assume that you can render any APPC document from a Content Creator
• If you support the Structured Policy Processing Option, you will run the associated test.

 

HOW DO APPC DOCUMENTS GET FROM THE CONTENT CREATOR TO THE CONTENT CONSUMER?

The APPC Profile does not mandate how Consent documents get from a Content Creator to a Content Consumer.  It could be XDS, another IHE profile, or a non-IHE method.  

At the Connectathon, we ask Content Creators to upload the Patient Privacy Policy Consent documents it creates into the Samples area of Gazelle (menu Connectathon-->Connectathon-->List of samples, on the 'Samples to share' tab.   Content Consumers will find uploaded samples under the same menu on the 'Samples available for rendering' tab.

 

WHICH PATIENT SHOULD BE USED FOR APPC TESTS?

Each APPC Patient Privacy Policy Consent document applies to a single PATIENT.  In a consent document, the patient ID and assigning authority values are encoded with the AttributeId urn:ihe:iti:ser:2016:patient-id .  A patient may have more than one privacy policy consent.  

We do not identify a single 'test patient' that must be used for creating APPC documents for Connectathon testing.  The Content Creator may include any valid Patient ID.  If the policy restricts or allows access based on values the XDS metadata for a patient's documents, the Content Creator may use a Patient ID in for clinical document(s) the policy applies to.

 

WHAT PRIVACY POLICIES, & OTHER VALUE SETS ARE DEFINED FOR APPC TESTING?

APPC Patient Privacy Policy Consent documents rely on the affinity domain agreeing to a set of PATIENT PRIVACY POLICIES that apply to ORGANIZATIONS and INDIVIDUAL PROVIDERS.  These policies, organizations, providers are identified by unique identifiers that are recognized within the affinity domain, and are encoded in a patient's consent document.

To enable the APPC Content Creator to specify different policies, this test defines values for various attributes used in policies:

• Policies - that a patient may apply to his/her documents
• Facilities - where a patient could receive care; facilities have an identified type.
• Providers - who provide care for a patient; providers have an identified role.
• Doc Sources - who create a patient's document(s) shared in an XDS environment
• Confidentiality Codes - applied to a patient's document that can be part of a policy
• Purpose of Use - 

The tables below contain value sets that are defined for the purpose of Connectathon testing of the APPC profile.

• APPC tests will ask Content Creators to use these when creating APPC Patient Privacy documents.  
• APPC Content Consumers should recognize these values.

 

---

POLICIES FOR CONNECTATHON TESTING OF APPC:

Policies: (APPC use case)	PolicySetIdReference	Policy description
FOUNDATIONAL POLICY (all use cases)	urn:connectathon:bppc:foundational:policy	By default, in this Connectathon affinity domain, document sharing is based on the value of Confidentiality Code (DocumentEntry.confidentialityCode).  This policy (inherited from BPPC) is applied to all documents.    Documents with a confidentialityCode of “N” (normal) are always shared unless a patient selects a more restrictive policy. Documents with a confidentialityCode of “R” (restricted) are not shared **unless** a patient explicitly “Opts in”, by agreeing to a less restrictive policy below Documents with a confidentialityCode of “V” (very restricted) are never shared, even if a patient also chooses a less restrictive policy. This is an artificial condition that enables testing. Documents with a confidentiality code of "U" (unrestricted) are always shared.   It is not allowed to apply a more restrictive policy to these documents. A patient may also choose to apply one of the additional policies below. This means that when an APPC document is created with multiple rules, then RuleCombiningAlgId=urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:permit-overrides
FULL ACCESS TO ALL	urn:connectathon:policy:full-access	The patient agrees that the document may always be shared.  (This is equivalent to having a confidentiality code of "U".)
DENY ACCESS TO ALL	urn:connectathon:policy:deny-access	The patient prohibits the document from ever being shared.  (This is equivalent to having a confidentiality code of "V".)
DENY ACCESS EXCEPT TO PROVIDER	urn:connectathon:policy:deny-access-except-to-provider	The patient prohibits the document from being shared except with the provider(s) identified in the consent document.
DENY ACCESS TO PROVIDER (use case 5)	urn:connectathon:policy:deny-access-to-provider	The patient prohibits the document from being shared with the provider(s) identified in the consent document.   The referenced individual provider(s) is prohibited from accessing this patient's documents (ie no read or write access).
DENY ACCESS EXCEPT TO FACILITY (use case 1)	urn:connectathon:policy:deny-access-except-to-facility	The patient prohibits the document from being shared except with the facility(ies) identified in the consent document.
DENY TO ROLE	urn:connectathon:policy:deny-access-to-role	The patient prohibits the document from being shared with providers who have the role(s) identified in the consent document
FULL ACCESS TO ROLE	urn:connectathon:policy:full-access-to-role	The patient allows the document to be shared with providers who have the role(s) identified in the consent document.  The patient prohibits the document from being shared with providers with any other role(s).
LIMIT DOCUMENT VISIBILITY (use case 6)	1.3.6.1.4.1.21367.2017.7.104	The patient prohibits sharing the referenced clinical document(s) and this privacy policy consent document with any healthcare provider or facility.

 

ORGANIZATIONS/FACILITIES defined in the "Connectathon Domain":

XACML AttributeId--> Facility Name:	urn:ihe:iti:appc:2016:document-entry:healthcare-facility-type-code (DocumentEntry.healthcareFacilityTypeCode)	urn:oasis:names:tc:xspa:1.0:subject:organization-id
Connectathon Radiology Facility for IDN One	code=”Fac-A” displayName=”Caregiver Office” codeSystem=”1.3.6.1.4.1.21367.2017.3"	urn:uuid:e9964293-e169-4298-b4d0-ab07bf0cd78f
Connectathon Radiology Facility for NGO Two	code=”Fac-A” displayName=”Caregiver Office” codeSystem=”1.3.6.1.4.1.21367.2017.3"	urn:uuid:e9964293-e169-4298-b4d0-ab07bf0cd12c
Connectathon Dialysis Facility One	code=”Fac-B” displayName=”Outpatient Services” codeSystem=”1.3.6.1.4.1.21367.2017.3"	urn:uuid:a3eb03db-0094-4059-9156-8de081cb5885
Connectathon Dialysis Facility Two	code=”Fac-B” displayName=”Outpatient Services” codeSystem=”1.3.6.1.4.1.21367.2017.3"	urn:uuid:be4d27c3-21b8-481f-9fed-6524a8eb9bac

 

INDIVIDUAL HEALTHCARE PROVIDERS defined in the "Connectathon Domain":

XACML AttributeId--> Provider Name:	urn:oasis:names:tc:xacml:1.0:subject:subject-id	urn:oasis:names:tc:xspa:1.0:subject:npi	urn:oasis:names:tc:xacml:2.0:subject:role
Dev Banargee	devbanargee	urn:uuid:a97b9397-ce4e-4a57-b12a-0d46ce6f36b7	code=”105-007” displayName=“Physician/Medical Oncology” codeSystem="1.3.6.1.4.1.21367.100.1"
Carla Carrara	carlacarrara	urn:uuid:d973d698-5b43-4340-acc9-de48d0acb376	code=”105-114” displayName=”Radiology Technician” codeSystem="1.3.6.1.4.1.21367.100.1"
Jack Johnson	jackjohnson	urn:uuid:4384c07a-86e2-40da-939b-5f7a04a73715	code=”105-114” displayName=”Radiology Technician” codeSystem="1.3.6.1.4.1.21367.100.1"
Mary McDonald	marymcdonald	urn:uuid:9a879858-8e96-486b-a2be-05a580f0e6ee	code=”105-007” displayName=“Physician/Medical Oncology” codeSystem="1.3.6.1.4.1.21367.100.1"
Robert Robertson	robertrobertson	urn:uuid:b6553152-7a90-4940-8d6a-b1017310a159	code=”105-007” displayName=“Physician/Medical Oncology” codeSystem="1.3.6.1.4.1.21367.100.1"
William Williamson	williamwilliamson	urn:uuid:51f3fdbe-ed30-4d55-b7f8-50955c86b2cf	code=”105-003” displayName=“Nurse Practitioner” codeSystem="1.3.6.1.4.1.21367.100.1"

 

XDS Document Sources:

XACML AttributeId--> Source Id:	urn:ihe:iti:appc:2016:source-system-id (SubmissionSet.sourceId)
Use sourceId as assigned in Gazelle to Connectathon XDS Doc Sources	Various XDS Document Sources systems

 

CONFIDENTIALITY CODES:

XACML AttributeId--> ConfidentialityCode:	urn:ihe:iti:appc:2016:confidentiality-code (DocumentEntry.confidentialityCode)
normal	code=”N” displayName=”normal” codeSystem=”2.16.840.1.113883.5.25"
restricted	code=”R” displayName=”restricted” codeSystem=”2.16.840.1.113883.5.25"
very restricted	code=”V” displayName=”very restricted” codeSystem=”2.16.840.1.113883.5.25"
unrestricted	code=”U” displayName=”unrestricted” codeSystem=”2.16.840.1.113883.5.25"

 

PURPOSE OF USE:

XACML AttributeId--> Purpose of use:	urn:oasis:names:tc:xspa:1.0:subject:purposeofuse
TREATMENT	code=”99-101” displayName=”TREATMENT” codeSystem="1.3.6.1.4.1.21367.3000.4.1"
EMERGENCY	code=”99-102” displayName=”EMERGENCY” codeSystem="1.3.6.1.4.1.21367.3000.4.1"
PUBLICHEALTH	code=”99-103” displayName=”PUBLICHEALTH” codeSystem="1.3.6.1.4.1.21367.3000.4.1"
RESEARCH	code=”99-104” displayName=”RESEARCH” codeSystem="1.3.6.1.4.1.21367.3000.4.1"

Evaluation

There is no evaluation for this informational test. If the systems testing the APPC Profile do not do the set-up described above, then APPCC tests at Connectathon will not work.

Introduction

This is an informational 'test'. We want all actors involved in testing the BPPC Profile and the BPPC Enforcement Option to read the "Privacy Policy Definition for IHE Connectathon Testing".

Instructions

Prior to arriving at the Connectathon, read this document: Privacy Policy Definition for IHE Connectathon Testing. This contains the policy for XDS Affinity Domains at the Connectathon, including 2 BPPC-related items.

Evaluation

There is no evaluation for this informational test. If the systems do not do the set-up described above, then BPPC Profile tests and BPPC Enforcement Options tests at Connectathon will not work.

Introduction

This is a "task" (ie not a test) that ensures that your '''CSD Care Services Directory''' is loaded with the entries that we will use as part of Connectathon testing.

Instructions

The Care Services Directory is loaded with Connectathon test data: (1) Codes, and (2) Organization, Provider, Facility, and Service information. 

(1) Load Connectathon code sets:

ITI TF-1:35.1.1.1 states, "Implementing jurisdictions may mandate code sets for Organization Type, Service Type, Facility Type, Facility Status, Provider Type, Provider Status, Contact Point Type, Credential Type, Specialization Code, and language code. A Care Services Directory actors shall be configurable to use these codes, where mandated."

For Connectathon testing, we define these codes and ask that you load them onto your Directory prior to arriving at the connectathon. They are documented in the format defined in IHE's SVS (Sharing Value Sets) profile, though support for SVS is not mandated in IHE.

The code sets are found here in Google Drive under IHE Documents > Connectathon > test_data > ITI-profiles > CSD-test-data >  CSD_Directory_Codes. (They are also available in the SVS Simulator: http://gazelle.ihe.net/SVSSimulator/browser/valueSetBrowser.seam

• 1.3.6.1.4.1.21367.200.101-CSD-organizationTypeCode.xml
• 1.3.6.1.4.1.21367.200.102-CSD-serviceTypeCode.xml
• 1.3.6.1.4.1.21367.200.103-CSD-facilityTypeCode.xml
• 1.3.6.1.4.1.21367.200.104-CSD-facilityStatusCode.xml
• 1.3.6.1.4.1.21367.200.105-CSD-providerTypeCode.xml
• 1.3.6.1.4.1.21367.200.106-CSD-providerStatusCode.xml
• 1.3.6.1.4.1.21367.200.108-CSD-credentialTypeCode.xml
• 1.3.6.1.4.1.21367.200.109-CSD-specializationTypeCode.xml
• 1.3.6.1.4.1.21367.200.110-CSD-languageCode.xml

(2) Load Connectathon Organization, Provider, Facility, and Services entries

In order to perform query testing with predictable results, Care Services Directories must be populated with the entries in the following files here in Google Drive under IHE Documents > Connectathon > test_data > ITI-profiles > CSD-test-data >  CSD_Directory_Entries.

Some directories may support only a subset of these entry types:

• CSD-Organizations-Connectathon-<date>.xml
• CSD-Providers-Connectathon-<date>.xml
• CSD-Facilities-Connectathon-<date>.xml
• CSD-Services-Connectathon-<date>.xml

(3) Additional Organization, Provider, Facility, and Services entries

The Connectathon entries are limited in scope.  We expect Directories to be populated with additional Organization, Provider, Facility & Service entries.  We give no specific guidance on the number of entries, but we are looking for a more realistic database.  Good entries offer better testing opportunities.

Evaluation

Create a short text file saying that you have finished loading your codes. Upload that text file into Gazelle Test Management as the results for this 'test'. That is your signal to use that you are ready for Connectathon testing.

Introduction

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, the HPD Provider Information Directory must load this provider test data into your HPD Provider Information Directory:
• Connectathon tests depend on the presence of this test data.  It is in the HPD_test_providers.xls file in Github here:  https://github.com/IHE/connectathon-artifacts/tree/main/profile_test_data/ITI/HPD

• 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 Test Management for this test.  Preloading these prior to the Connectathon is intended to save you precious time during Connectathon week.

 

Introduction

This is not an actual "test". Rather it is a task that ensures that the mCSD Care Services Selective Supplier is loaded with the Resources and value sets that we will use as part of Connectathon testing.

Instuctions for Supplier Systems

The instructions below apply to mCSD Supplier systems. (The mCSD Consumer actor is included on this test so that it is aware of this test mCSD test data, but it has no preload work to do. During Connectathon, the Consumer will be performing queries based on the content of these Resources.)

(1) Connectathon FHIR Resources

In order to perform query testing with predictable results, the Care Services Selective Supplier system must be populated with the entries from pre-defined FHIR Resources:

• Organization
• Location
• HealthcareService
• Practitioner
• PractitionerRoles

**Some Suppliers may support only a subset of these. **

These resources are available in two places  (the test data is the same in both places, so you only need to access/load one set):

• In Github here:  https://github.com/IHE/connectathon-artifacts/tree/main/profile_test_data/ITI/mCSD
  
  --or--

• On the HAPI FHIR Read/Write Server deployed for Connectathon.  (note that the link to this server be published by the technical manager of your testing event).

(2) Additional Resources

The pre-defined Connectathon test data are limited in scope.  We expect Suppliers to be populated with additional Organization, Provider, Facility & Service Resources.  We give no specific guidance on the number of Resources, but we are looking for a more realistic database.  Good entries offer better testing opportunities.

(3) Value Sets for some codes:

The FHIR Resources for mCSD testing contain codes from some pre-defined ValueSet Resources.

These ValueSets are also found in Github and on the FHIR Read/Write Server at the links above.

code	FHIR ValueSet Resource id
Organization Type	IHE-CAT-mCSD-organizationTypeCode
Service Type	IHE-CAT-mCSD-serviceTypeCode
Facility Type	IHE-CAT-mCSD-facilityTypeCode
Facility Status	IHE-CAT-mCSD-facilityStatusCode
Provider Type	IHE-CAT-mCSD-providerTypeCode
Provider Status	IHE-CAT-mCSD-providerStatusCode
Credential Type	IHE-CAT-mCSD-credentialTypeCode
Specialty Type	IHE-CAT-mCSD-specializationCode
Language	languages
Provider Qualification	v2-2.7-0360

 

The mCSD Resources also contain codes from these FHIR ValueSets:

• Language Codes: http://hl7.org/fhir/ValueSet/languages (with coding.system of urn:ietf:bcp:47)
• Provider Qualification Codes: https://www.hl7.org/fhir/v2/0360/2.7/index.html

Evaluation

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

 

Introduction

This is not an actual "test". The Instructions section below describe the testing approach for the mXDE Profile. It provides context and preparation information prior to performing Connectathon tests with your test partners.

Instructions

Please read the following material prior to performing Connectathon tests for the mXDE Profile.

Overall Assumptions:

(1) There is a significant overlap between the mXDE and QEDm profiles.  Each mXDE actor must be grouped with its QEDm actor counterpart.  Thus, you should successfully complete tests for QEDm before attempting mXDE tests.

(2) The mXDE Profile refers to extracting data from documents but does not specify the document types. For purpose of Connectathon testing, we will provide and enforce use of specific patients and specific documents.  We intend to use the same clinical test data for both QEDm and mXDE tests.   See details about test patients and documents in the QEDm ReadThisFirst and DoThisFirst tests.

• For mXDE, we will extract data from documents for patient Chadwick Ross.
• If our test data (CDA documents, FHIR Resources) are not compatible with your system, please let us know as soon as possible. We would prefer to use realistic test data. It is not our intention to have you write extra software to satisfy our test data.
• Some of the coded data with the documetns may use code systems that are not in your configuration. For example, they might be local to a region. You will be expected to configure your systems to use these codes just as you would at a customer site.
• We will require that the extraction process be automated on the mXDE Data Element Extractor system.

(3) The mXDE Data Element Extractor actor is grouped with an XDS Document Registry and Repository or an MHD Document Responder.

• When grouped with the XDS Document Registry and Repository, we will expect the Data Element Extractor to accept (CDA) documents that are submitted by XDS transactions to initiate the extraction process.
• When grouped with an MHD Document Responder, we will expect the Data Element Extractor to accept (CDA) documents submitted to an MHD Document Recipient to initiate the extraction process.
• In summary, you may not extract from your own internal documents.  You must use the Connectathon test data provided.

(4) The tests reference several patients identifed in QEDm: Read_This_First. These same patients are used for mXDE tests.  The Data Element Extractor may choose to reference the patients on the Connectathon FHIR Read/Write Server or may import the Patient Resources and host them locally.

(5) The Provenance Resource is required to contain a reference to the device that performed the extraction. Because the device is under control of the Data Element Extractor, the Data Element Extractor will be required to host the appropriate Device Resource. You are welcome to use multiple devices as long as the appropriate Device resources exist.  (See QEDm Vol 2, Sec 3.44.4.2.2.1).

(6) The QEDm Profile says the Provenance Resource created by the mXDE Data Element Extractor shall have [1..1] entity element which point to the document from which the data was extracted. 

• The Data Element Extractor that supports both the MHD and XDS grouping may create one Provenance Resource that references both forms of access (via MHD, via XDS) or may create separate Provenance resources to reference the individual documents.

(6) During the Connectathon, we want you to execute mXDE tests using the Gazelle Proxy. That will simplify the process of collecting transaction data for monitor review.

mXDE Data Element Extractor actor:

Overall mXDE test workflow:

(1) Create one or more Device Resources in your server (to be referenced by Provenance Resources you will create).

(2) Import the required test patients or configure your system to reference the test Patient Resources on the FHIR Read/Write Server.

(3) Repeat this loop:

• The Extractor will host the test document(s) on your system (you may have received them via MHD or XDS).
• Your system will extract the relevant data and create FHIR Resources (Observation, and/or Medication, and or...) on your server.
• Your system will create a least one Provenance Resource for each of the FHIR Resources created.
• The Provenance Resource will reference at least one entity (MHD or XDS) and may reference both entities if supported.
• A software tool or Data Element Provenance Consumer will send FHIR search requests to your system. A set of queries that might be sent is included below. [Lynn: refer to the relevant *Search* test]

mXDE Data Element Provenance Consumer actor:

Overall mXDE test workflow:

(1) Configure your system with the endpoint of the Data Element Extractor partner.

(2) Repeat this loop for each data element supported (Observation, Medication, ...); some of the items might occur in a different order based on your software implementation:

• Send a search request of the form: GET [base]/[Resource-type]?_revinclude=Provenance:target&criteria
• Retrieve the source document or documents referenced in the Provenance Resource(s).
• IHE profiles usually do not defined how a consumer system makes use of clinical data. The mXDE Profile is no different. We will expect you to demonstrate some reasonable action with the FHIR resources that have been retrieved and the source document(s).

Evaluation

There are no result files to upload into Gazelle Test Management for this test.  Understanding the testing approach in advance is intended to make testing during Connectathon week more efficient.

 

On this page:

• Overview
• Background Information
• In conclusion...
• Instructions
• Evaluation

Overview:

These instructions apply to the Patient Identity Registry actor in the Patient Master Identity Registry (PMIR) Profile.  In this test, a PMIR Registry will load its database with Patient Resources formatted for [ITI-93] Mobile Patient Identity Feed, to support subscription tests that will occur later, during the 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 Instructions below.

 

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

However, at the Connectathon, we 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 (the PMIR Patient Identity Registry & the PIXm Cross-Reference Manager).

A PIXm Patient Identifier Cross-Reference Manager:

Source of Patients in the PIXm Profile: The PIX Manager has many patient records, and a single patient (person) might have several records on the PIX Manager server that are cross-referenced because they apply to the same patient.   The Patient Identity Feed [ITI-104] transaction in PIXm was introduced in PIXm Rev 3.0.2 in March 2022.   The PIX Manager may also have other sources of patient information (eg HL7v2 or v3 Feed).
At the Connectathon, we ask PIX Managers to preload “Connectathon Patient Demographics” that are are provided via the Gazelle Patient Manager tool (in HL7v2, v3, or FHIR Patient Resource format).  These Connectathon Patient Demographics contain four Patient records for each ‘patient’, each with identical demographics (name, address, DOB), but with a different Patient.identifier (with system values representing the IHERED, IHEGREEN, IHEBLUE, and IHEFACILITY 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.3000.1.6|IHEFACILITY-998), the PIXm Manager would 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 IHEFACILITY domain (above example), if there is a match, the PIXm Manager would return a response with three matches, one each for RED, GREEN, and BLUE, e.g.:

 

A PMIR Patient Identity Registry:

Source of Patients in the PMIR Profile: The PMIR Profile is intended for use in an environment where each patient has a single “Golden Patient record”. In PMIR, a patient has a single “Patient Master Identity” (a.k.a. Golden Patient record) that is comprised of identifying information, such as business identifiers, name, phone, gender, birth date, address, marital status, photo, contacts, preference for language, and links to other patient identities (e.g. a mother’s identity linked to a newborn).

The PMIR Patient Identity Source actor sends the Mobile Patient Identity Feed [ITI-93] transaction to the PMIR Patient Identity Registry to create, update, merge, and delete Patient Resources.  

The PMIR Regsitry persists one "Patient identity" per patient.  The PMIR Registry relies on the Patient Identity Source actor as the source of truth about new patient records (FHIR Patient Resources), and about updates/merges/deletes of existing patient records (i.e. the Registry does whatever the Source asks). The PMIR Registry does not have algorithms to 'smartly' cross-reference multiple/separate records for a patient.  .

In the FHIR Patient Resource in PMIR, there are two attributes that hold identifiers for a patient:

1. Patient.id - in response to a Mobile Patient Identity Feed [ITI-93] from a Source requesting to 'create' a new patient, the Patient Identity Registry assigns the value of Patient.id in the new Patient Resource. This value is *the* unique id for the patient's 'golden identity' in the domain.
2. Patient.identifiers - the Patient Resource may contain [0-*] other identifiers for the patient, e.g. Patient ID(s) with assigning authority, a driver's license number, Social Security Number, etc.  In the pre-defined Patient Resources used for some PMIR tests, we have defined a single assigning authority value. (urn:oid:1.3.6.1.4.1.21367.13.20.4000, aka the "IHEGOLD" domain). This distinguishes these patients from patients in the red/green/blue domains used to test other profiles.

At the Connectathon, because some systems support PIX/PIXv3/PIXm and PMIR, we provide separate Patients (in [ITI-93] format) for PMIR testing with identifiers in a single assigning authority - urn:oid:1.3.6.1.4.1.21367.13.20.4000 (aka IHEGOLD). PMIR Registry systems will preload these patients, and they are only used for PMIR tests.  These patients have different demographics than the traditional red/green/blue Connectathon patients used for PIX, PDQ, XDS, and XCA.

QUERY: When a PMIR Patient Identifier Cross-Referece Consumer sends a PIXm Query [ITI-83] to the PMIR Registry with a sourceIdentifier representing the assigning authority and patient ID  (e.g. urn:oid:1.3.6.1.4.1.21367.13.20.4000|IHEGOLD-555), if there is a match, the PMIR Registry would return a response with the one (matching) Patient Resource (the 'Golden' patient record). 

At the Connectathon, if a Patient Identifier Cross-Reference Consumer send a PIXm Query by a Patient ID in the GOLD domain, if there is a match, the PMIR Registry would return a response with a reference to one Patient Resource.

 

In conclusion, 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 Registry in a given test.  We have managed testing expectations by using patients in different domains for testing the two profiles, but we don't tell you how you manage this in your product if you support both PMIR and PIX.

Instructions:

In this test, the PMIR Patient Identity Registry loads a set of FHIR Patient Resources used in PMIR peer-to-peer subscription tests.  We use a set of FHIR Patient Resources 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 in Github here: https://github.com/IHE/connectathon-artifacts/tree/main/profile_test_data/ITI/PMIR
2. 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.
3. POST that file to your PMIR Registry so that you are hosting the three Patient Resources within that file.
4. Note that there are other files in that directory that you can access now, but do not POST them to your Registry 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 results into Gazelle Test Management for this test.

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

Introduction:

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
• MHD testing

To support PIX, PDQ, XDS, 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.
• 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.  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.  These records each have Patients IDs with the 4 Assigning Authorities used at the Connectathon (IHERED, IHEGREEN, IHEBLUE, and IHEFACILITY.  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.

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 results into Gazelle Test Management for this test.

Introduction

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 to load these patients 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 results into Gazelle Test Management for this test.

This “Read This First” test helps to prepare you to test RFD-based profiles at an IHE Connectathon.

A Pre-Connectathon Task for Form Managers & Form Processors

Documenting RFD_Form_Identifiers: This is a documentation task. We request all Form Managers and Form Processors to help their Form Filler test partners by documenting the Form Identifiers (formID) that the Form Fillers will use during Connectathon testing. Follow the instructions in preparatory test RFD_formIDs

Overview of RFD Connectathon Testing

RFD and its 'sister' profiles:

The number of IHE profiles based on RFD has grown over the years.  These 'sister' profiles re-use actors (Form Filler, Receiver, Manager, Processor, Archiver) and transactions (ITI-34, -35, -36) from the base RFD profile.

Starting at 2016 Connectathons, to reduce redundant testing, we have removed peer-to-peer tests for RFD only.  If you successfully complete testing for an actor in a 'sister' profile, you will automatically get a 'Pass' for the same actor in the baseline RFD profile.  For example, if you "Pass" as a Form Filler in CRD, you will get a "Pass" for a Form Filler in RFD for 'free' (no additional tests).

Similar test across profiles:

Baseline Triangle and Integrated tests: These RFD tests exercise the basic RFD functions Retrieve Form and Submit Form.

"Triangle" and "Integrated" refer to the combinations of actors in the tests. A Triangle test uses a Form Filler, Form Manager and Form Receiver (triangle). An Integrated test refers to the Form Processor that is an integrated system (supports both ITI-34 and ITI-35); the Integrated test uses a Form Filler and a Form Processor.

CDA Document Tests: We have tried to be more thorough in our definitions of tests for CDA documents; we still have some work to do. There are “Create_Document” tests that ask actors that create CDA documents to produce a document and submit that document for scrutiny/validation by a monitor. There are test sequences that need those documents for pre-population or as an end product; you cannot run those tests until you have successfully completed the “Create_Document” test. We have modified the test instructions for the sequence tests that use CDA documents to require the creator to document which “Create_Document” test was used. We do not want to run the sequence tests before we know we have good CDA documents.

Archiving Forms:  We have a single test -- "RFD-based_Profiles_Archive_Form" to test Form Archivers and Form Fillers that support the 'archive' option.  There are separate tests for archiving source documents.

Testing of options: IHE does not report Connectathon test results for Options in IHE profiles. We readily admit that the tests that cover options will vary by domain and integration profile. If you read the tests in domains other than QRPH (or even in QRPH), you may find profiles that have no tests for named options. We continue to try to enhance tests for named options and other combinations of parameters found in the QRPH profiles.

1. This has created an explosion of tests. You can look in the BFDRe, FP, SDC and VRDR tests and see this. BFDR-E and VRDR are interesting because they specify two different classes of pre-pop documents. SDC has three named options that control the Retrieve Form transaction. Finally, we still have to consider the Form Processor vs. Form Manager + Form Receiver issue.
2. This is mainly directed at Form Fillers, but is relevant for other actors: If you have registered as a Form Filler with multiple options (say in SDC for HTML Package, URI Form and XML Form), you only have to complete testing for one of the paths to receive Connectathon credit. We are happy to work with you to test the other options; we do not have the systems in place for our public reporting to make this distinction.
3. An option that you support might be something we need to test in order to validate a different actor from a different organization. If you decide to not test an option, we may still request your help with that option to help test another system for whom that behavior is required.

ATNA Logging: If you implement the ATNA profile, one of the requirements is that you send audit messages for certain transactions, primarily those that carry PHI. The ITI-35 can be a PHI export transaction, implying that Form Filler who also supports ATNA should send an audit message. This is an issue for a Form Filler when the form was retrieved as an unencoded form (just retrieved the Form URI); the Form Filler does not actually have control over the form.

If your Form Filler has requested an encoded form and has an XML form to process, it does have control over the ITI-35 transaction and should be able to send the appropriate audit message. The same issue exists for the ITI-36 Archive Form transaction.

Form Instance Identifiers: The RFD profile discusses the concept of partial or interim storage of a form. In order to make this work, the Form Filler needs to have a Form Instance ID to retrieve the correct instance of the form that was stored. There are two different mechanisms for a Form Filler to obtain a Form Instance ID:

1. The Form Instance ID is an optional field in the response to ITI-34.
2. The Form Instance ID is an optional field in the response to ITI-35.

That is, the Form Processor or Form Manager is going to control when the Form Instance ID is returned to the Form Filler. We need to get clarification from the ITI Technical Committee if the intended sequence included the Form Filler obtaining that Form Instance ID from the ITI-34 or from the ITI-35 transaction. Until we have that clarification, we will have to work with test participants and their interpretation of this mechanism.

Use of the Gazelle Proxy

Because RFD transactions are generally not sent over TLS connections (unless required by a specific profile), RFD tests are good candidates to use the Gazelle proxy. It will record HTTP transactions and allow you and the monitors to review those logs in a centralized manner.  We highly encourage you to use the proxy when performing this test.   It will allow you to easily see the messages exchanged between test partners and to document them for the monitor.

Evaluation

There is no result to upload into Gazelle Test Management for this informational test.

Introduction

In this tes preparatory test, Form Managers and Form Processors document the formID(s)  that will be used during a Connectathon in the [ITI-34] transaction.

The formID may apply to the base RFD profile, or it may apply to content profile(s) based on RFD (eg CRD, VRDR, many others)

Instructions

Form Managers and Form Processors:

For Connectathon testing, we expect that you create your own forms for content profiles with your own identifiers (formID).

Edit the google spreadsheet linked below. Add one row to the spreadsheet for each formID hosted on your test system.

Please do this in advance of the Connectathon. The goal is to provide documentation for your Form Filler test partners.

Form Fillers:

There is no specific task for you; however, access the spreadsheet linked below to see the formIDs you will use during Connectathon testing.

RFD Form Identifiers google spreadsheet: https://docs.google.com/spreadsheets/d/11LM9eKzuA_CKJZKsQA7PRJ8uXjYLQ7LTukNJU4LzkDg/edit#gid=1667031332

Evaluation

When you complete the task above, create a small text file stating that your entries are complete. Upload that file into Gazelle Test Management as the results for this test.

Introduction

At the Connectathon, the SVCM Connectathon tests assume that a pre-defined set of FHIR Resources have been loaded on all of the  Terminology Repository actors under test.

Instructions

Prior to performing Connectathon tests, SVCM Terminology Repositories must load FHIR Resources:

• CodeSystems
• ValueSets
• ConceptMaps

These resources are available in Github here:  https://github.com/IHE/connectathon-artifacts/tree/main/profile_test_data/ITI/SVCM

For reference only: This google sheet contains a list of the above resources.

 

Your Repository may also contain other additional FHIR Resources during Connectathon.

Evaluation

There are no result files to upload into Gazelle Test Management.  Preloading these Resources in advance is intended to save you precious time during Connectathon week.

 

Introduction

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

(1) 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 Gazelle SVS Simulator tool referred to in test 14500

(2) Ideally, your Repository will also contain other additional value sets during Connectathon.

Evaluation

There are no result files to upload into Gazelle Test Management.  Preloading these prior to the Connectathon is intended to save you precious time during Connectathon week.

 

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
• Testing Scope and Pass Criteria
• Configuration and Test Data

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: 

1. 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.
2. 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:

1. 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).
2. 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).
3. 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.
4. You must do all your tests using TLS.
5. 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).

**If you have chosen to support the "XDS Affinity Domain" or "On Demand Docs" option**, you must pass one of these tests to get credit for the option.  You can pass as an Initiating Gateway without supporting these options.

-- XCA Responding Gateways doing Thorough testing:

1. 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.)
2. 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.

You must do all of your tests using TLS.

**If you have chosen to support the "On Demand Documents" option**, you must do one of these tests.  You can pass as a Responding Gateway without supporting this option.

 

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.

Introduction

This test applies to Portable Media Creators in the XDM Profile that create either CD-R or USB media, or a ZIP file for the ZIP over Email optionl.  

This test case is used to create XDM-formatted media (CD-R and/or USB). The media you create will be used by Portable Media Importers during the Connectathon in the XDM_Import_* peer-to-peer tests.

Instructions

As a Portable Media Creator, when you create your media, we encourage to to put documents  from the various IHE content profiles your system supports (eg APR, BPPC, EDES,  EDR, IC,  XDS-MS, XDS-SD, XD-LAB, XPHR, etc).  A larger variety of document types will help the Importer systems find compatible content.

You will also be required to demonstrate that you send an 'export' audit message when you create XDM media.

To create your XDM media for exchange during Connectathon:

STEP 1: Create 2 copies of physical media:  USB and/or CD/R, if you support those options.

STEP 2:  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.  Also include the document types you have included on media (eg XPHR, XDS-SD, etc...)  (We recognize the space limitations on USB; create a piece of paper that can accompany your media.) Bring your media with you to the Connectathon.

STEP 3: Create a zip file of the file structure on your XDM media. Upload that zip file into the samples area of Gazelle Test Management: menu Connectathon-->Connectathon-->List of Samples. On the 'Samples to share' tab, upload your zip file under the 'XDM' entry.

Evaluation

During Connectathon, a Monitor will do a two-part evaluation of your media.   You should do these for yourself in advance of the Connectathon so that you are confident your test will pass.

EVALUATION PART 1 - METADATA  VALIDATION:

Earlier versions of this test involved manual scrutiny of the METADATA.XML file.  Now, we use the Gazelle EVSClient:

1. Access https://gazelle.ihe.net/EVSClient/home.seam
2. Select menu IHE--> XD* Metadata -->Validate
3. Click the "Add" button then upload one METADATA.XML from the media under test.
4. From the "Model Based Validation" dropdown list, select "IHE XDM ITI-32 Distribute Document Set on Media"
5. The Monitor will be looking for a validation results with no errors.

 

EVALUATION PART 2 - Validate XDM structure using the Edge Test Tool

1. Validate the zip file that you created above using the XDM validator in https://ett.healthit.gov/ett/#/validators/xdm
2. Create a screen capture of the successful results from the validator and upload it into the Samples area of Gazelle Test Management, along with your ZIP file.

This page instructions for preloading coded values used during Connectathon testing

of IHE document sharing profiles -- > XD*, XC*, and MHD

Introduction

IHE profiles for Document Sharing (XD*, XC*, MHD) rely on coded values provided in the metadata when documents are submitted and searched. These Document Sharing profiles define the structure of the document metadata as well as coded values for some metadata attributes; however, allowable values for many of the coded values are not constrained by IHE, but are defined by the Affinity Domain that will deploy and support the document sharing systems.

• Source-type actors include coded values in metadata in document submission transactions
• Recipient-type actors perform metadata validation based on coded values received in a document submission
• Consumer-type actors use coded values for metadata when performing queries for documents

For testing of Document Sharing profiles at IHE North America and Europe Connectathons, the set of allowable code values for document sharing metadata are defined by IHE Technical Project Managers and deployed in the NIST XDS Toolkit. 

This page describes where to find the set of allowable codes for document sharing testing at IHE Connectathons.  This enables you to configure your test system prior to performing these types of tests. 

(NOTE:  Some Connectathons or Projectathons may use different codes for metadata.  If that is the case, the Technical Project Manager will provide other guidance.)

Which metadata attributes have coded values?

These documentEntry metadata attributes have defined codes:

• associationDocumentation
• classCode
• confidentialityCode
• contentTypeCode
• eventCodeList
• folderCodeList
• formatCode
• healthcareFacilityTypeCode
• mimeType
• practiceSettingCode
• typeCode

 

Instructions

Find the coded values then load these coded values onto your test system.  Loading these codes is a prerequisite to performing any preparatory tests with the NIST XDS tools or NIST FHIR Tools.  It is also a prerequisite to performing peer-to-peer Connectathon test for the XD*, XC* and MHD profles.

 

For IHE NA and EU Connectathons, allowable codes for Document Sharing metadata are contained in the codes.xml file distributed here: https://tools.iheusa.org/xdstools/sim/codes/default 

Note 1:  These codes are deployed on the public version of NIST XDS Toolkit hosted here:  https://tools.iheusa.org/xdstools/

 

Note 2 : These codes are also available in SVS format, but values of codes in SVS format may not exactly match those in codes.xml above.  See the Gazelle SVS Simulator tool that hosts many value sets, including codes for metadata attributes.

 

Evaluation

There is no result file to upload to Gazelle Test Management for this test. If you do not do the configuration described above, then tests with tools or your test partners will not work.

 

How to request an update to codes.xml

If you find an error in codes.xml, or to request that a code be added, please submit an issue in the Github repository for XDS Toolkit: https://github.com/usnistgov/iheos-toolkit2/issues. You may also directly edit the codes.xml file here with your suggested change and submit a Pull request.

Introduction

XDS.b Document Registries must complete the preparation described here before performing XDS.b Connectathon tests.

Instructions

(1) Affinity Domains for Registries:  During Connectathon, each XDS.b Document Registry has been assigned to an affinity domain that determines the Patient IDs your Registry will accept.  These affinity domains are referred to as the "Red", "Blue" or "Green". (If this is your first Connectathon, these affinity domains are explained here.)  The Connectathon Project Manager announces the Red/Blue/Green assignments in advance of the Connectathon.  It is documented in this google spreadsheet.  

(2) Connectathon patients to pre-load on your Registry:  To support XDS tests, Registries load patient demographics provided in advance by the Connectathon Technical Project Manager.  If you  have performed pre-Connecthon test Preload_Connectathon_Test_Patients , you already have these patients in your database; otherwise follow the instructions in that test now.   You will only load patients for the Affinity Domain you were assigned to above

(3) Metadata Codes:  Document Registries must also be configured with codes for Connectathon Affinity Domain Metadata.  These are documented in the codes.xml file found in the latest release of the NIST XDS Toolkit here:  https://github.com/usnistgov/iheos-toolkit2/releases/.  First-time Connectathon participants can read background information about metadata codes here.

NOTE:  Some Connectathons may use different codes for metadata.  If that is the case, the Technical Project Manager will provide other guidance.

Evaluation

There is no result file to upload to Gazelle Test Management for this informational test. If the Document Registry does not do the set-up described above, then peer-to-peer XDS.b tests at Connectathon will not work.

Introduction

Prior to arriving at the Connectathon, it is important for participants testing XUA (or the IUA profile with the SAML Token option) to be familiar with:

• the Connectathon testing scenario
• the tool used to provide assertions for XUA tests -- the Gazelle-STS Security Token Service

The description that follows:

• explains the structure of the Connectathon tests and related tools
• describes preparation to do before you start testing XUA at the Connectathon.

Tool and SAML Token Information

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.

Assertions used for Connectathon testing:  

The [ITI-40] transaction (ITI TF-2: 3.40.4.1.2) specifies the SAML assertion, including that all assertions contain a Subject (principal).  The 'Subject' in the assertion could be a user or it could be an 'application'. 

For Connectathon, we have pre-defined Subjects (ie HTTP authentication users) that we use for XUA testing .  Several different Subject/users are defined, and they are associated with a different assertions used for the XUA "success" test - XUA_Transaction_with_Assertion and the "fail" test XUA_Restrict_Access.

Please refer to the Gazelle STS user manual for the list of assertions available:  https://gazelle.ihe.net/gazelle-documentation/Gazelle-STS/user.html#requesting-a-security-token.

The Gazelle-STS tool is able to generate assertions with the success and failure conditions defined in the tests.  (We expect that X-Service Users that are generating their own assertions will have less flexibility.)

Note  - Many options are possible for the AuthnStatement parameter in the Assertion. For the Connectathon, the assertions provided to the X-Service Users by the X-Assertion Providers will encode a timestamp representing when the authentication occurred and that the password class was used, eg:

• urn:oasis:names:tc:SAML:2.0:ac:classes:Password

Configuration Details:

For X-Service Users who will request assertions from the Gazelle-STS, three configuration items have been identified. When requesting a security token, the X-Service User needs to provide the X-Assertion Provider with:
   (1) An HTTP authentication user
   (2) A valid password
   (3) The 'AudienceRestriction' of the X-Service Provider

For item (3) at the Connectathon, to ease configuration, we will apply the same URL to all X-Service Providers, eg all Registries and Repositories. (Note that this URL is **not** the URL the Document Consumer will use to query a Registry or retrieve documents from a Repository).  This same, general URL used as the value of 'AudienceRestriction' for all service providers will simplify the STS configuration and will ensure that users can' access any Registry/Repository with the SAML token obtained from the STS.

The required URL is :

• http://ihe.connectathon.XUA/X-ServiceProvider-IHE-Connectathon

XUA Connectathon Test Approach

Actors in the XUA Profile can be grouped with actors in any IHE profile using webservices transactions (eg. XDS.b, XDR, PDQv3, PIXv3, RFD, XCA, many others...). Thus, you will be testing the exchange of XUA assertions in conjunction with transactions from another profile. This means you not only need to find your XUA test partners, you must also find a partner which supports a webservices transaction that you support.

Here is the sequence of activities you must do to accomplish your XUA testing during the Connetathon:

1. Before any XUA peer-to-peer tests can be run, each X-Service Provider actor must run one instance of test XUA_X-Service_Provider_Setup. Do that first.
2. The XUA profile allows X-Service User actors to get their assertions from an external assertion provider or generate their own. You need to talk to your test partners about how your system works in this regard.  
   • The Connectathon provides the Gazelle-STS (Security Token Service) tool to provide assertions used for XUA tests. 
3. You will need to find XUA test partners who support a webservices-based IHE profile that you also support.
4. There are 3 'flavors' of XUA Connectathon tests.  You can do these tests in conjunction with any webservices transaction:
   • The 'success' case (XUA_Transaction_with_Assertion test). 
   • The 'fail' case (XUA_Restrict_Access test).
   • A test where the X-Service Provider does not trust the Assertion Provider (XUA_Policy_Test).
5. When you perform XUA tests, you must use TLS and enable ATNA logging.

These notes apply to testing of the XUA profile at the Connectathon:

1. The method that the X-Service User uses to get the SAML Identity Assertion is not constrained by the XUA profile.  Test cases for this profile allow use of these two methods.  The first is most common.
   • SAML Assertion Provider -- The X-Service User will authenticate against an identity provider (XUA X-Assertion Provider).
     For Connectathon testing, we provide the Gazelle-STS tool as an X-Assertion Provider from which X-Service Users can request assertions, and against which X-Service Providers can validate assertions received. The certificate to trust in order to access that service is available here.
     The Gazelle-STS will verify signature, validity and trusted chain relations for Assertions, but will not check specific content such as AudienceRestriction value, IHE rules (or other standards business rules). This is the responsibility of the X-Service Provider, so it should not fully delegate the validation of the Assertion to the Gazelle-STS. See associated documentation here.
   • Self-assertion -- The X-Service User does not rely on an external assertion provider; rather, it generates its own valid SAML assertions
     (In this scenario, if you want Gazelle-STS to be able to verify signature and trust-chain, the certificate/or its CA signing the assertion must be available in Gazelle Security Suite (GSS) PKI. You can either use a certificate delivered by GSS, or you can contact a Gazelle Administrator to update your public certificate into GSS.)
2. XUA X-Service Providers need to be able to 'trust' assertions provided by a mix of X-Service Users who either:
   • do self-assertion
   • or, send an assertion which originated at an external STS (X-Assertion Provider). This is the more common case.
3. X-Service Providers should be configurable to 'not trust' assertions from a selected assertion provider.
4. (This test has been deferred: X-Service Providers need to be able to be configured to 'not trust' assertions containing certain parameters. For example, for the Connectathon, we will define a 'policy' that assertions containing an authentication method of 'InternetProtocol' in its AuthnStatment should fail validation.)
5. The XUA Profile constrains only a subset of the possible parameters that can be included in a SAML assertion. The proper use of these specific parameters is tested.  It is valid to include other parameters in the assertion, but these are not tested. Other parameters will not affect the validity of the assertion. The XUA X-Service Provider must accept all valid SAML assertions and process attributes profiled in ITI-40.
6. In these tests, XDS.b Document Registry and Document Repository actors which are also XUA X-Service Providers do not need to support a scenario where some Document Consumers in the Affinity Domain support XUA, and some do not. This will not be a required test at Connectathon; however, vendors are welcome to test this scenario if they wish.
7. All transactions, including those with the X-Assertion Provider, shall be done using TLS.
8. Auditing will be tested:
   • The XUA profile requires that the X-Service Provider generate an ATNA audit event for 'Authentication Failure' whenever its validation of the assertion fails. Eg. The Document Consumer must send an audit message when it initiates a Registry Stored Query. These audit events are tested in these tests.
   • The XUA profile requires that "Any ATNA Audit Messages recorded by Actor grouped with the X-Service Provider Actor, shall have the user identity recorded according to the XUA specific ATNA encoding rules" (See ITI TF-2:3.40.4.2 ATNA Audit encoding). For example: when the XDS.b Document Consumer actor records the Stored Query event, this event record will include the identity provided in the XUA Identity Assertion. This assures that the X-Service User and X-Service Provider ATNA Audit messages can be correlated at the ATNA Audit Repository. This will be tested in the XUA tests.
9. Authorization is out-of-scope for XUA (that is tested in the IUA and SeR Profiles), i.e., there are no XUA tests that allow or restrict a user's access to a document based on who a user (principal) is, nor are there tests that allow a user to see a subset of a patient's document based on the contents of the assertion. Either the validation succeeds at the X-Service Provider, and all of a patient's record is returned to the X-Service User, or validation fails, and the X-Service User receives nothing.

Evaluation

There is no result file to upload to Gazelle Test Management for this informational test. If the systems testing XUA do not do the set-up described above, then peer-to-peer XUA tests at Connectathon will not work.

 

This page applies to vendors testing IHE's document sharing profiles:  XD*, XC*, MHD
and supporting Patient ID manangement profiles:  PIX*, PDQ*

 

If you're testing these profiles, please review this page prior to the IHE Connectathon.

Note that there are updates below related to Patient IDs in Patient Resources in some IHE profiles based on HL7® FHIR®.

 

At IHE Connectathons in both Europe and North America, we define three Affinity Domains. These represent three different document sharing (XDS) communities.

Patient IDs in Connectathon Affinity Domains

Each of these domains is associated with its own Patient ID assigning authority. For ease of reference we refer to these as:

• Red Patient ID domain.  The Patient ID assigning authority value is:
• 1.3.6.1.4.1.21367.13.20.1000 for Patient IDs used in the PIX, PIXv3, PDQ, PDQv3 and XDS.b profiles
• urn:oid:1.3.6.1.4.1.21367.13.20.1000 for Patient IDs used in FHIR-based profiles PIXm, PDQm, MHD
• Green Patient ID domain.  The Patient ID assigning authority value is:
• 1.3.6.1.4.1.21367.13.20.2000 for Patient IDs used in the PIX, PIXv3, PDQ, PDQv3 and XDS.b profiles
• urn:oid:1.3.6.1.4.1.21367.13.20.2000 for Patient IDs used in FHIR-based profiles PIXm, PDQm, MHD
• Blue Patient ID domain.  The Patient ID assigning authority value is:
• 1.3.6.1.4.1.21367.13.20.3000 for Patient IDs used in the PIX, PIXv3, PDQ, PDQv3 and XDS.b profiles
• urn:oid:1.3.6.1.4.1.21367.13.20.3000 for Patient IDs used in FHIR-based profiles PIXm, PDQm, MHD
• We also have a 'local' Patient ID assigning authority (1.3.6.1.4.1.21367.3000.1.6 and urn:oid:1.3.6.1.4.1.21367.3000.1.6).

We have a tool -- the Gazelle PatientManager --  for creating a patient with a Patient ID with a Red, Green or Blue assigning authority and sending it via HL7v2 or v3 to your test system.  It also can create equivalent FHIR Patient Resources.  Instructions on how to use this tool to populate your test system with patients for Connectathon testing are found in pre-Connectathon test Preload_Connectathon_Test_Patients.

Explanatory resources:

• Multiple-affinity-domains.pdf: This presentation gives you an overview of the 3-affinity-domain scheme used at the IHE Connectathon.
• Three-domain-assigning-authority: XDS.b Registries and XC*Gateways are assigned to one of the 3 affinity domains for the entire connectathon week.
• These assignments are in the spreadsheet linked above.
• Registries accept a patient identity feed, and register documents, with patient IDs in their assigned domain (ie with their designated Patient ID assigning authority)
• Likewise, Gateway actors represent communities with documents in their one assigned domain.
• PIX Managers, and some PDQ Suppliers, can operate across domains.
• XC* testing schedule during Connectathon week - contains the Tues/Wed/Thur schedule for XC testing for the current Connectathon.  

We have a presentation and an illustration which are are specific to the Cross-Community profiles (XC*):

• XC-cluster.pdf: This presentation shows the actor/transaction diagram for each XC* profile, and the associated Connecthon tests (in red font)

• Introduction
• Cross-Profile Considerations
• Testing Overview
• Fixed Patients
• Clinical Content
• IPS Data Exchange
• Software Test Tools

Introduction

At the Connectathon, the IPS Content Creator is required to provide documents that meet the requirements of the International Patient Summary (IPS) Profile.  The IPS Content Creator is required to accept / retrieve documents and process them using one or more of the options defined by the IPS Profile.

This page provides a general overview of the IPS testing process.

Cross-Profile Considerations

• Value Sets for some of the data elements / resources are coordinated with testing the SVCM profile in the ITI domain.
• Content of the documents is coordinated with testing the QEDm profile in the PCC domain. We intend to reuse patients and content across the IPS and QEDm profiles to reduce work for systems that create / host the clinical test data.

Testing Overview

1. A fixed set of patients with demographics and defined clinical content are specified. See those details below, including consideration for changes needed to support regional testing.
2. The Content Creator enters the data with the defined clinical content into their system. See details below.
3. As part of testing, monitors will test IPS documents with a software tool. See details below.
4. Interoperability tests are executed for both CDA and FHIR versions of the IPS documents. Content Creator and Content Consumer actors are welcome to test either flavor.
5. The IHE IPS profile says that the Content Creator makes the IPS document available through the PCC-1 Document Sharing transaction. This transaction takes on several forms, but the key aspect of this is that the Content Creator actively exports the document. The Content Consumer does not query for an IPS document using a FHIR search transaction.

Fixed Patients

The table below lists the patients defined for testing. Demographic information can be found in the Connectathon Artifacts GitHub repository (see the IPS-QEDm README.md) or in the Gazelle Patient Manager. The Optionality column indicates if the patient data is required for IPS testing (R for Required, O for Optional).

• It is in your best interests to use the patient names and demographics that are listed as this will simplify testing. IPS tests do not examine patient address, so you are welcome to substitute values that are defined for your region. If you have issues with the specific patient name, you can also use a different patient. Be clear in your communication with your test partners.

Name	DOB	Trillium Bridge ID	IHERED ID	Optionality
Charles Merlot	1966.04.04	EUR01P0008	IHERED-3158	R
Mary Gines	1963.09.09	EUR01P0020	IHERED-3159	R
Annelise Black	1988	EUR01P0002	IHERED-3160	O
Marco Peroni	1995.07.28	EUR01P0011	IHERED-3163	O
Allen Perot	1963.02.18	EUR01P0013	IHERED-3161	O

 

Defined Clinical Content

As mentioned above, a set of patients is defined for QEDm testing. Clinical content should be extracted from the files described here: https://github.com/IHE/connectathon-artifacts/tree/main/profile_test_data/PCC/IPS-QEDm. The README.md file in the GitHub repository provides an index to files but does not describe the clinical content. Further notes:

• The IPS profile does not place requirements on the method for entering the resource data into the Content Creator. For IPS testing, the Content Creator is allowed to use any method of extraction / translation. That method will not be examined / reviewed.
• The table below indicates the number of resources that should be extracted and included in the IPS document.
• The Connectathon Artifacts repository has sample IPS documents for the patients listed above. Most of the files correspond to the previous DSTU3 version that were created as part of the Trillium Bridge project. One file follows the R4 format. You will need to extract the clinical content and place it in your system.
• The two required patients (Merlot, Gines) exercise required sections in the IPS document and include encodings where values are not known. The optional patients include other IPS sections.

 

	Merlot (DSTU3)	Gines (DSTU3)	Black (DSTU3)	Peroni (R4)	Perot (DSTU3)
Required
Medication Summary	2	No information	2	2	3
Allergies and Intolerances	NKA	1	NKA	NKA	1
Problem List (Condition)	2	No known	3	4	5
Recommended
Immunizations		1	1	2	2
History of Procedures
Medical Devices			No known
Diagnostic Results
Optional
Vital Signs
Past History of Illness
Pregnancy			1
Social History
Functional Status
Plan of Care
Advance Directives

 

You will find that clinical content in this folder https://github.com/IHE/connectathon-artifacts/tree/main/profile_test_data/PCC/IPS-QEDm in the Connectathon Artifacts GitHub repository. Find the data you need by matching the patients listed in the table above with the README.md file in that folder.

Please do not enter less content or more content than is defined for each patient. You might add content to an individual resource, but do not add or substract resources. Validation of test results is difficult when you do not include the expected data.

You might discover that the data in the patient record is contradictory and/or might generate alerts because medications do not go with diagnoses. Please contact the owner of the test data to help resolve the issue and make corrections.

The document that you create/export is a self-contained document. If you are creating a FHIR Bundle, the resources that are referenced in the document must also exist in the document. The FHIR Bundle does not refer to resources that exist on a FHIR server. 

IPS Data Exchange

We use the Samples area of Gazelle Test Management to exchange IPS documents (CDA or FHIR format) between Content Creator and Content Consumer systems.  There are a separate Preparatory tests containing instructions.  See:

• IPS: Create CDA and FHIR Documents for Connectathon Testing
• CDA_Document_Sample_Exchange

In addition, the IHE IPS Profile says that the Content Creator transmits the IPS document to the Content Consumer using the PCC-1 transaction. That transaction contains a number of options:

• XDS
• XDM
• XDR
• XCA
• MPQ
• MHD
• RFD
• "others as appropriate"

During Connectathon, we will communicate with test participants and work with them to resolve the mechanism for exchanging the document.  The Content Creator creates the document and actively exports the document. This is not a FHIR search request to retrieve a summary document. The HL7 IPS Implementation Guide does not forbid a FHIR search / read requests, but the IHE profile has used the push model of a document.

For Preparatory testing purposes, we are more concerned with document content and reliable data import and less concerned with the mechanics of creating/exporting the document.

Software Test Tools

We use the Gazelle External Validation Service (evs) tool (https://gazelle.ihe.net/evs/home.seam) to validate IPS Content.  There are a separate Preparatory tests containing instructions.  See: 

• EVS_FHIR_IG-based_Validation
• EVS_CDA_Validation

Introduction

At the Connectathon, the IPS Content Creator is required to provide documents that meet the requirements of the International Patient Summary (IPS) Profile. This test tells you where to find the documentation that describes what is expected for testing.

Instructions

First, create your IPS Documents:

These instructions are for the IHE IPS Content Creator.

The page IPS Read This First describes the set of patients and where to locate the clinical information for each patient. Please refer to that page prior to creating your IPS content below.

Required - CDA Option

Create the clinical content in your system that you need to produce an IPS CDA document for these two patients:

• Merlot
• Gines

Required - FHIR Option

Create the clinical content in your system that you need to produce an IPS FHIR document for these two patients:

• Merlot
• Gines

Optional Content - CDA Complete Option

Create the clinical content in your system that you need to produce an IPS CDA document for one or more of these patients:

• Black
• Peroni
• Perot

Optional Content - FHIR Complete Option

Create the clinical content in your system that you need to produce an IPS FHIR document for one or more these patients:

• Black
• Peroni
• Perot

Next, upload your IPS content into Gazelle Test Management:

• If you create IPS content in CDA format, follow the instructions in: CDA_Document_Sample_Exchange
• If you create IPS content in FHIR format, follow the instructions in:  FHIR_Resource_Sample_Exchange

 

 

Introduction

At the Connectathon, the QEDm Clinical Data Source is required to respond to search requests for one or more FHIR Resources as defined by the QEDm profile. The QEDm Clinical Data Consumer is required to search for one or more one or more FHIR Resources as defined by the QEDm profile. The resources used in the search depend on the QEDm options declared by a system.

This page provides a general overview of the QEDm testing process.

Cross Profile Considerations

• Value Sets for some of the data elements / resources are coordinated with testing the SVCM profile in the ITI domain.
• Clinical content is coordinated with testing the IPS profile in the PCC domain. We intend to reuse patients and content across the IPS and QEDm profiles to reduce work for systems that create / host the clinical test data.
• Provenance testing for the QEDm Provenance Option is coordinated with testing of the ITI mXDE profile.

Testing Overview

1. A fixed set of patients with demographics and defined clinical content are specified. See those details below, including consideration for changes needed to support regional testing.
2. The Clinical Data Source enters the resources with the defined clinical content into their system. See details below.
3. As part of conformance testing, monitors will query the Clinical Data Source with a software tool. See details below.
4. Interoperability tests are executed for those resources where there is overlap between the Clinical Data Source and Clinical Data Consumer. Overlap means that both the Source and Consumer support one or more of the same options.
5. Interoperability tests focus on the search functions defined in the QEDm profile. Search functions and query paramters are specific to each FHIR resource. You can see the list of search parameters below.
6. Testing of the QEDm Provenance option is related to testing of the ITI mXDE Profile. You can read about that testing environment here: mXDE Read This First

Fixed Patients

The table below lists the patients defined for testing. Demographic information can be found in the Connectathon Artifacts GitHub repository (see the IPS-QEDm README.md) or in the Gazelle Patient Manager. The Optionality column indicates if the patient data is required for QEDm testing (R for Required, O for Optional).

• It is in your best interests to use the patient names and demographics that are listed as this will simplify testing. QEDm tests do not examine patient address, so you are welcome to substitute values that are defined for your region. If you have issues with the specific patient name, you can also use a different patient. Be clear in your communication with your test partners.

Name	DOB	Trillium Bridge ID	IHERED ID	Optionality
Charles Merlot	1966.04.04	EUR01P0008	IHERED-3158	R
Mary Gines	1963.09.09	EUR01P0020	IHERED-3159	R
Chadwick Ross	1960.02.29		IHERED-3162	R
Annelise Black	1988	EUR01P0002	IHERED-3160	O
Marco Peroni	1995.07.28	EUR01P0011	IHERED-3163	O
Allen Perot	1963.02.18	EUR01P0013	IHERED-3161	O

 

Defined Clinical Content

As mentioned above, a set of patients is defined for QEDm testing. Clinical content should be extracted from the files described here: https://github.com/IHE/connectathon-artifacts/tree/main/profile_test_data/PCC/IPS-QEDm. The README.md file in the GitHub repository provides an index to files but does not describe the clinical content. Further notes:

• The QEDm profile does not place requirements on the method for entering the resource data into the Clinical Data Source. For QEDm testing, the Clinical Data Source is allowed to use any method of extraction / translation. That method will not be examined / reviewed.
• The table below indicates the number of resources that should be extracted and made available for query.
• The IPS files for patients Merlot and Gines provide a simple source of data for FHIR resources as these files contain FHIR Bundles.
• The files for Ross (CCD, Procedure, Diag Imaging) are Consolidated CDA documents are provide some challenges:
• Note that the CCD document has 20 observations. These are scattered throughout the document. If you already have CDA software that automatically extracts observation data, please use it. If you do not have automated software, extract 5 observations by hand and move on.
• We will provide some flexibility when looking at the FHIR resources you have defined by looking at the CDA documents. We hope that a future version of the test environment will be more explicit.

 

	Merlot (IPS)	Gines (IPS)	Ross (CCD)	Ross (Procedure)	Ross (Diag Imaging)
Observation			20	1
AllergyIntolerance	1	1	2
Condition	2
Diagnostic Report				1	1
MedicationStatement	2	1	2
MedicationRequest
Immunization		1	5
Procedure			3	1
Encounter			1

 

You will find that clinical content in this folder https://github.com/IHE/connectathon-artifacts/tree/main/profile_test_data/PCC/IPS-QEDm in the Connectathon Artifacts GitHub repository. Find the data you need by matching the patients listed in the table above with the README.md file in that folder.

Please do not enter less content or more content than is defined for each patient. You might add content to an individual resource, but do not add or substract resources. Validation of test results is difficult when you do not include the expected data.

You might discover that the data in the patient record is contradictory and/or might generate alerts because medications do not go with diagnoses. Please contact the owner of the test data to help resolve the issue and make corrections.

 

Software Test Tools

 

QEDm Search Functions

The search parameters in QEDm depend on the FHIR resource. The summary table below shows the combinations of query parameters defined for the various resources. The last row for Provenance is special because you do not search directly for a Provenance resource. You search for a base resource and ask the server to include Provenance resources in the response.

 

	Patient	Patient + Category	Patient + Category + Code	Patient + Category + Date	Patient + Category + Code + Date	Patient + Clinical Status	Patient + Date	_include
Observation		x	x	x	x
AllergyIntolerance	x
Condition	x	x				x
DiagnosticReport		x	x	x	x
MedicationStatement	x							x
MedicationRequest	x							x
Immunization	x
Procedure	x						x
Encounter	x						x
Provenance

 

 

 

 

 

 

 

Introduction

This page provides instructions for the Clinical Data Source when testing the QEDm profile. You should read the overview at QEDm: Read This First and then follow the instructions below.

Instructions

Find clinical content in IPS bundles and CDA documents in the IPQ-QEDm folder of the Connectathon Artifacts repository. For each content option you support (e.g., Observation, Allergy/Intolerance), load FHIR resources into your system per the subsections below.  

• Please do not enter less content or more content than is defined for each patient. You might add content to an individual resource, but do not add or substract resources. Validation of test results is difficult when you do not include the expected data.
• Separate disclaimer under Observations
• You might discover that the data in the patient record is contradictory and/or might generate alerts because medications do not go with diagnoses. Please contact the owner of the test data to help resolve the issue and make corrections.
• The QEDm profile does not place requirements on the method for entering the resource data into the Clinical Data Source. For QEDm testing, the Clinical Data Source is allowed to use any method of extraction / translation. That method will not be examined / reviewed.
• The IPS files for patients Merlot and Gines provide a simple source of data for FHIR resources as these files contain FHIR Bundles.
• The files for Ross (CCD, Procedure, Diag Imaging) are Consolidated CDA documents and provide some challenges. You are welcome to use automated software to extract the clinical data or extract by hand.
• We will allow some flexibility when looking at the FHIR resources you have defined by looking at the CDA documents. We hope that a future version of the test environment will be more explicit. 

 

Observation

The Observation resource is more difficult than the other clinical items as there are 20 observations in the Ross CCD file and one observation in the Ross Procedure File.

• Extract and enter the one observaton from the Ross Procedure file.
• Extract and enter at least 5 observations from the Ross CCD file. As mentioned above, this can be a manual or automated process.

 

AllergyIntolerance

Extract and enter 4 clinical data items for Allergy/Intolerance from these sources and enter into your system:

Merlot / IPS	1
Gines / IPS	1
Ross / CCD	2

 

Condition

Extract and enter 2 clinical data items for Condition from these sources and enter into your system:

Merlot / IPS

2

 

 

Diagnostic Report

Extract and enter 2 clinical data items for DiagnosticReport from these sources and enter into your system:

Ross / Procedure	1
Ross / Diagnostic Imaging	1

 

 

MedicationStatement

The documents listed below include medications for three patients. Extract the medications from the documents and convert to MedicationStatement resources with the related Medication resources.

Merlot / IPS	2
Gines / IPS	1
Ross / CCD	2

 

 

MedicationRequest

The section above tells you to create MedicationStatement resources from medications found in three documents. Follow the same guidance to create MedicationRequest resources for these three patients. That is, you can assume that each medication is also described by a MedicationRequest.

Merlot / IPS	1
Gines / IPS	1
Ross / CCD	2

 

 

Immunization

Extract and enter 5 clinical data items for Immunization from these sources and enter into your system:

Gines / IPS	1
Ross / CCD	4

 

 

Procedure

Extract and enter 2 clinical data items for Procedure from these sources and enter into your system:

Ross / CCD	1
Ross / Procedure	1

 

Encounter

Extract and enter 1 clinical data items for Encounter from these sources and enter into your system:

Ross / CCD

1

 

Provenance

You might be expecting to find directions for Provenance resources here. Testing for Provenance resources is coupled with mXDE testing. You can read about that testing environment on the mXDE Read This First page.

 

Overview

The AI Results (AIR) Profile specifies how AI Results encoded as DICOM Structured Reports (SRs).   Depending on the AI algorithms implemented on the AIR Evidence Creator (EC) actor, the EC will create/encode one or more of the different result primitives in its SRs, e.g. qualitative findings, measurements, locations, regions, parametric maps, tracking identifiers, image references.

For the Connectathon, there is a set of no-peer tests to evaluate how the Evidence Creator encodes its AI results; the tests follow the naming pattern AIR_Content_*. Each of these tests align with a different result primitive included in an AI results SR.  We have created separate tests for the different result primitives to make it test execution and evaluation more manageable.  The Evidence Creator will perform Connectathon tests that are applicable to the SRs and primitives it has implemented.

The purpose of this Preparatory test is to have the Evidence Creator describe in narrative form the nature of its AI results implementation.     Reading this description will help the Connectathon monitor have the proper context to evaluate your Evidence Creator application, the AI results you produce, and the result primitives included in your AI SR instances.

Instructions for Evidence Creators

For this test you (the Evidence Creator) will produce a short document describing your implementation in the context of the AI Results Profile specification.  The format of the document is not important.  It may be a PDF, a Word or google doc, or some other narrative format.

Your document shall include the following content:

1. Your system name in Gazelle Test Management (eg. OTHER_XYZ-Medical)
2. AI Algorithm Description - this should be a sentence or two describing what your algorithm does (e.g. detect lung nodules)
3. DICOM IODs implemented (one or more of:  Comprehensive 3D SR Storage IOD, Segmentation Storage IOD, Parametfic Map Storage IOD, Key Object Selection (KOS) Document Storage IOD)
4. Result primitives encoded in the AI Result SR. (one more of: qualitative findings, measurements, locations, regions, parametric maps, tracking identifiers, image references)
5. If you encode measurements, indicate whether your measurements reflect a planar region of an image (i.e. use TID 1411, a volume (TID 1410), or are measurements that are not tied to a planar region or volume (TID 1501). (Refer to RAD TF-3: 6.5.3.3 in the AIR TI Supplement for details.)
6. If you encode regions, indicate whether they are contour-based regions (i.e. use TID 1410 or 1411) or pixel/voxel-based regions (i.e. use the DICOM Segmentation Storage SOP Class) (Refer to RAD TF-3: 6.5.3.5 for details).
7. Please add any additional information (e.g. screen shots) that would help the reader understand your algorithm, and output.
8. REPEAT 2 - 7 for each AI Algorithm that produces result(s) on your Evidence Creator
9. Finally, in order to share it with your test partners, upload your document as a Sample in Gazelle Test Management.  On the 'List of Samples' page, use the dropdowns to find your test system, and on the 'Samples to share' tab, add a new "AIR_EC_Capabilities" sample and upload your document there.   When you save your sample, it will be visible to your test partners.

 

Instructions for AIR 'consumer' systems

1. Each Evidence Creator should have uploaded a description of their AI algorithms and inputs and outputs into Gazelle Test Management (Gazelle TM under Testing-> Sample exchange.    On the Samples available for rendering tab under the AIR_EC_Capabilities entry,  This page will evolve as your partners add samples, so be patient. 
2. Retrieve the document uploaded. The purpose is to give you an understanding of the types of AI content that your Image Display, Image Manager or Imaging Doc Cosumer will store/display/process  Refer to these help pages for details on this task.

Evaluation

There is no "pass/fail" for this test.  However, you must complete it because it is a prerequisite for several Connectathon tests.  The Connectathon monitor will be looking for the document you produce here and use it when s/he is evaluating your AI result content.

Overview

This Preparatory test in informational.  It is intended to prepare the AIR Evidence Creator for Connectathon tests that will be used to evaluate the AI result SRs producted by the Evidence Creator.

Another Preparatory test, AIR_EC_Capabilities, instructs the Evidence Creator to upload AI result SRs into the Samples area of Gazelle Test Management.  In that test, the Evidence Creator will also use the Pixelmed DICOM validator to perform DICOM validation of your SRs.   The Pixelmed validator checks the baseline requirements of the DICOM SR, including the requirements of the Templale IDs (TIDs) within the SR.   The tool does not, however, check the requirements and constraints that are part of the content specification in the AIR Profile.

In Gazelle Test Managment, on your Test Execution page, you will find a set of no-peer tests used toevaluate encoding of AI results; these Connectathon tests follow the naming pattern AIR_Content_*.  The different tests align with different result primitives that are included in an AI results SR, e.g. qualitative findings, measurements, locations, regions, parametric maps, tracking identifiers, image references.

Depending on the AI algorithms it implements, we expect an Evidence Creator to create/encode one or more of these types of result primitives.  We have created separate tests for the different result primitives to make it test execution and evaluation more manageable during the Connectathon.

Instructions

Prior to the start of the Connectathon, we highly recommend that the Connectathon participant that will test the Evidence Creator actor read each AIR_Content_* Connectathon test

>>Note:  There is a Content test for each of the AI result primitives.   The AI algorithm(s) on your Evidence Creator may not include all of the defined result primitives (e.g. you may not produce parametric maps.  For the Connectathon, you will only be required to perform the AIR_EC_Content* and AIR_Display* tests that are applicable to your system.  (This separation of capabilities into separate tests results in some redundant test steps, but one large test for all primitives would have been difficult for testers and monitors to manage.)

In each AIR_Content_* test, you will find test steps and evaluation criteria for specific encoding requirements for the different result primitives.  We recommend that you examine your AI result SR content using these test steps.    If you find discrepancies, you may need to update your software to be compliant with the AIR content requirements.   If you disagree with any of the tests or test steps, you should contact the IHE Radiology Domain Technical Project Manager to resolve your concern.

If you use the tests to review the SRs during the Prepatarory phase, you can be confident that the Connectathon monitor will find no errors when s/he evaluates your SRs during the Connectathon.

Evaluation

There is no result file to submit into Gazelle Test Management for this informational test.

Overview

The AI Results (AIR) Profile requires the Image Display to demonstrate specific display capabilities when rendering AI Result SRs.  These requirements are in Display Analysis Result [RAD-136].

At the Connectathon, a monitor will sit down at your AIR Image Display and run through a set of tests to evaluate the display requirements in [RAD-136].

In this preparatory test, we are providing you with some test data advance of the Connectathon that you will use to demonstrate AIR display requirements.   The test data includes:

• binary DICOM Structured Reports (SRs) that encode the AI result examples documented in RAD TF-3, Appendix A Example Analysis Result Encodings (currently in the AIR Trial Implementation Supplement).
• vendor samples from prior IHE Connectathons

NOTE:  During the Connectathon, the Image Display will be required to perform tests with with AI Result IODs from the Evidence Creator test partners at that Connectathon.  The Image Display may also be asked to use AI Result IODs in this test data, especially where this sample data contains DICOM object types or AIR primitives that the 'live' test partners do not produce.

Instructions

 For AIR IMAGE DISPLAY systems:

1. Access the test data and load the SRs, and accompanying images, onto your Image Display.  See: https://github.com/IHE/connectathon-artifacts/tree/main/profile_test_data/RAD/AIR
2. Review requirements in the Connectathon tests listed below
3. Use the test data in your own lab to prepare to demonstrate those display requirements to a monitor during Connectathon.

>> AIR_Display_Analysis_Result

>> AIR_Display_Parametric_Maps

>> AIR_Display_Segmentation_IOD

>> AIR_Display_*  (etc...)

 

For ALL OTHER AIR ACTORS:

It is OPTIONAL non-Image-Display actors to access the samples, but we recognize the value of test data to all developers, so you are welcome to access the samples.

1. To access the test data, see: https://github.com/IHE/connectathon-artifacts/tree/main/profile_test_data/RAD/AIR.  Samples are arranged in sub-directories by Connectathon and then by vendor
2. To download a file in one of the sub-directories, click on the individual file name, then use the links on the right side of the page to download the 'Raw' file.

Evaluation

IMAGE DISPLAY SYSTEMS:  Create a text file that briefly describes your progress in using the SRs with your Image Display. Upload that file into Gazelle Test Management as the result file for test. There is no pass/fail for this preparatory test . We want to make sure you're making progress toward what is expected during evaluation of your Image Display at the Connectathon.

Overview

The AI Workflow for Imaging (AIW-I) Profile specifies how to request, manage, perform, and monitor AI Inference on digital image data.  

Both the sequence of transactions in AIW-I and the content of the workitem(s) created by the Task Requester depend on the AI inferences and workflows implemented on the AIW-I Task Performer actor.  Therefore, the purpose of this Preparatory test is to gather information from the Task Performer which will influence how it will interact with its test partners during the Connectathon.   The Task Performer will describe:

• AIW-I workflows it supports. See AIW-I Section 50.1.1.3, Section 50.4.1.5, and Section 50.4.2 .  One or more of:
• Pull workflow
• Triggered pull workflow
• Push workflow
• the AI algorithms (inferences) it has implemented
• the inputs each algorithm needs when it is triggered.  See AIW-I Section 50.4.1.1 and 50.4.1.2.

This description will help the Task Requester ensure that the workitems it creates are adequately populated for you, and that you test the workflow(s) you support with your partners at the Connectathon.

Instructions for Task Performers

For this test you (the Task Performer) will produce a short document describing your implementation in the context of the AIW-I Profile specification.  According to AIW-I, Section 50.4.1.1, a DICOM Conformance Statement is the ideal home for these details.  If you have one, great!  But, for the purpose of this preparatory test, the format of the document is not important.  It may be a PDF, a Word or google doc, or some other narrative format.

Your document shall include the following content:

1. Your system name in Gazelle Test Management (eg. OTHER_XYZ-Medical)
2. Technical Contact name/email - this is someone who can be contacted if there are questions about what you provide below
3. The AIW-I Workflow(s) you support:   Pull Workflow,  Triggered-pull Workflow, and/or Push Workflow
4. AI Algorithm Description - this should be a sentence or two describing what your algorithm does (e.g. detect lung nodules)
5. The Workitem Code that will trigger this AI Algorithm - refer to AIW-I Section 4.1.2.   You may use a code in Table 50.4.1.2-1 if there is one that applies.  Otherwise, suggest a code that is appropriate for your AI algorithn
6. The Input Parameters  & Values required by your AI Algorithm - you will need to be very specific in answering this.  Please refer to AIW-I Section 50.4.1.1 and Table 50.4.1.1-1.  Identify the UPS attribute(s) your algorithm relies on, and the value(s) you expect for each.
7. The Input Information Sequence content your AI altorithm requires - Please refer to Section 50.4.1.3 and identify the DICOM images (if any) that your AI algorithm expects to see in the Input Information Sequence (0040,4021) of the UPS Workitem that triggers your AI algorithm.
8. Any other information that will help the reader understand your algorithm and how it is triggered.
9. REPEAT 3 - 8 for each AI Algorithm that can be triggered on your Task Performer
10. Finally, in order to share it with your test partners, upload your document as a Sample in Gazelle Test Management.  On the 'List of Samples' page, use the dropdowns to find your test system, and on the 'Samples to share' tab, find the "AIW-I_Performer_Capabilities" entry and upload your document there.   When you save your sample, it will be visible to your test partners.

 

Instructions for Task Requesters, Managers, Watchers

You will find and read the document provided by the Task Performer above.

1. In Gazelle Test Management, on the 'List of Samples' page, use the dropdowns to find your test system, and on the 'Samples available for rendering' tab, find the "AIW-I_Performer_Capabilities" entry with the document provided by your Task Performer partner(s) above.  
2. Download that document and use it to configure your system for items such as workitem codes, input parameters, etc, that you will need in order to create a UPS workitem [RAD-80] for that Performer

Evaluation

There is no "pass/fail" for this test.  However, you must complete it because it is a prerequisite for several Connectathon tests.  Your AIW-I test partners, plus the Connectathon monitor, will be looking for the document produced here.

Overview

The Image Display actor in the Basic Image Review (BIR) Profile is unlike other IHE actors in that its requirements are primarily functional and do not require exchange of messages with other actors.  

At the Connectathon, a monitor will sit down at your system and run through a set of tests to evaluate the requirements in the BIR profile. In this preparatory test, we are providing you with the test okab and the accompanying images in advance of the Connectathon.   To prepare, we expect you to load the test data 9images) run these tests in your lab in preparation for the Connectathon itself.

Instructions

1. Find the test plan and test data for BIR in Google Drive in IHE Documents >Connectathon > test_data > RAD-profiles > bir_data_sets .   From that folder download the following:

• The Connectathon Test Plan for BIR Image Display: BIR_Image_Display_Connectathon_Tests-2023*.pdf
• The BIR test images in file BIRTestData_2015.tar.bz
• The index to the BIR test images in _README_BIR_dataset_reference.xls

After loading the test images onto your Image Display, run the test in the BIR Test Plan document using your display application.

Evaluation

Create a text file that briefly describes your progress in running these tests. Upload that file into Gazelle Test Management as the result file for test. There is no pass/fail for this preparatory test . We want to make sure you're making progress toward what is expected during evaluation of your Image Display at the Connectathon. .

Overview

To enable Connectathon testing, the Image Display is required host studies on its Image Display.

There is one Connectathon test -- IID Invoke Display -- to exercise the Image Display and Image Display Invoker in the IID profile. The 'Special Instructions' for that test ask you to host a set of studies. This preparatory 'test' ensures you have the proper data loaded on your system prior to arriving at the Connectathon.

We do not provide specific studies for you, but rather define the characteristics of the studies you should bring

Instructions

Come to the Connectathon with:

• At least 3 studies for the same patient, ie will have the same value in patient ID, but the accession number and study dates will be different for each of these studies.
• At least one other study for a different patient
• A study containing a KOS object identify at least one image in the study as a 'key image'

Evaluation

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

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.

Special Instructions for Connectathon Online:

At a Connectathon Online, it is not possible for test partners to exchange physical PDI media.  In that case, we ask the Portable Media Creator (PMC) to:

1. create an ISO image of your CD media
2. upload that ISO file into the Sample area of Gazelle Test Management

• On the 'Samples to share' tab for your test system, find the 'PDI' entry
• Upload and save your ISO image on that sample page

Instructions for PDI Portable Media Creators (face-to-face Connectathon):

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-2: 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"

Evaluation

1. There is no file to upload to Gazelle Test Management for this test.
2. There is no specific evaluation for this test.  Feedback will come when your partners import the contents of your media during Connectathon week.
3. Make sure you pack up the media you created and bring it to Connectathon!

 

Instructions

There are no test steps to execute for this test.

Instead, create a text file which documents the type of DICOM images your modality creates and lists the DICOM Baseline Template your Acquisition Modality uses when creating Dose SRs for the REM profile.

CT modalitites which report on irradiation events shall be capable of producing an SR compliant with TID 10011.

Actors which support on irradiation events for Modalities of type XR, XA, RF, MG, CR, or DX shall be capable of producing an SR compliant with TID 10001

Your text file should have the following naming convention: CompanyName_SystemName_REM.txt.

Evaluation

Submit the text file into the Gazelle Test Management as the results this test.

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, find the test "EBIW_10_Read_This_First" on your main Test Execution 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 for EBIW tests during the Connectathon.

 

Evaluation

There is no file to upload to Gazelle Test Management for this preparatory 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 and PLT 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 result file to upload to Gazelle Test Management for this preparatory 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

This test is for Imaging Document Source actors in the XDS-I.b and XCA-I Profiles that support the "Set of DICOM Instances" option.  If your Imaging Document Source only supports PDF or Text Reports, then this test does not apply to you.

In Connectathons prior to 2019, Imaging Document Source actors created and submitted manifests for their own image set(s).   You will be able to do this for other XDS-I.b peer-to-peer tests during the Connectathon.  However, for this test, we ask you to create manifests for 3 studies that Connectathon Technical Managers provide.  This enables us to check both the metadata and manifest for expected values that match data in the images and in Connectathon affinity domain codes (i.e. codes.xml).

The manifests you create for these 3 studies will be used for some XDS-I/XCA-I tests during Connectathon week.

Location of the studies

There are three DICOM studies available.  The Imaging Document Source must load these three studies onto its system.  

• They are stored in a zip file here:  IHE Documents > Connectathon> test_data> RAD-profiles > XDS-I.b_test_data
• They may also be stored on the DICOM Central Archive during a Connectathon

Summary of the DICOM studies

For Connectathon testing purposes, we treat as individual imaging studies for one patient who has been imaged in three different affinity domains.  This helps facility cross-community testing in XCA-I.

The contents of the 3 studies are summarized in the "XDS-I,b XCA-I and WIA studies" google spreadsheet.  

Please review all 3 tabs:

1. Identifies values in key attributes in the DICOM header for each study.  
2. Identifies values in key attributes in the XDS-I Manifest (DICOM KOS) for each study
3. Identifies values in the key XDS Metadata attributes when the Imaging Document Source submits the manifest to an XDS-I Repository (using RAD-68)

Patient IDs to use in the XDS Metadata for the Manifests

The Patient ID in the DICOM headers for the images is considered the 'local' or 'departmental' Patient ID, (ie sourcePatientId in the documentEntry metadata for the manifest). When the Imaging Document Source submits a Manifest for these studies to an XDS Repository/Registry, documentEntry.patientId must contain the affinity domain ID for the patient.

For XDS/XCA testing, we use Patient IDs that are included in the Connectathon Patient Demographics pre-loaded onto each Registry and Gateway at Connectathon, and onto the NIST XDS Tools Registry, as follows:

For the DX study with "local" Patient ID C3L-00277, the affinity domain Patient IDs is:

• IHERED-2737^^^IHERED&1.3.6.1.4.1.21367.13.20.1000&ISO

For the CT study with "local" Patient ID C3N-00953, the affinity domain Patient IDs is:

• IHEGREEN-2737^^^IHEGREEN&1.3.6.1.4.1.21367.13.20.2000&ISO

For the CT study with "local" Patient ID TCGA-G4-6304, the affinity domain Patient IDs is:

• IHEBLUE-2737^^^IHEBLUE&1.3.6.1.4.1.21367.13.20.3000&ISO

 

Instructions

Prior to the Connectathon, the Imaging Document Source should:

1. Load the 3 DICOM studies onto its test system. They are stored in a zip file here:  IHE Documents > Connectathon> test_data> RAD-profiles > XDS-I.b_test_data
2. Construct 3 XDS-I Manifests, one for each of the studies identified above 
3. In the Samples area of Gazelle Test Management, for one of the DICOM Manifests:

• On the "Samples to share" tab, find the entry for "XDS-I_Manifest"
• Upload the .dcm file for your manifest
• Under "Actions", use the green triangle icon the validate your manifest using Gazelle EVSClient.  We expect a validation result with no errors.

 

Evaluation

Evaluation of the manifest will not be performed until Connectathon, but we encourage the Imaging Document Source to  read this evaluation now to ensure its manifest will pass verification during Connectathon.  There are two verifications that Connectathon Monitors will perform: (1) examine the DICOM Manifest for the study, and (2) examine the metadata for the submitted manifest

(1) MANIFEST CHECK:

The Connectathon Monitor will examine the XDS-I Manifest that the Imaging Document Source uploaded into Gazelle Test Management.    The evaluation of the manifest is based on the requirements in RAD TF-2: 4:68.4.1.1 "Manifest KOS Document"

Find the manifest:  Choose Gazelle Test Management menu Testing-->Sample Repository.  Then use the "Object Types" dropdown list to filter the entries for "XDS-I_Manifest".  Find an entry for the Imaging Document Source under test with an uploaded DICOM manifest. 

First:  Within the sample you can call the EVSClient (green triangle) and examine the attributes in the Manifest and perform validation.  We expect no errors.

Next:   Using the DICOM dump in EVSClient examine the attributes in the DICOM Manifest.  Verify the values in the attributes using Tab 2 of the "XDS-I.b XCA-I and WIA studies" sheet. 

• Column 1 identifies the attributes for the monitor to examine. 
• The remaining columns contain guidance on what is expected in each attribute.   Note that all 3 studies are in the spreadsheet, but the Monitor is only examining one Manifest created by the Imaging Document Source.

 

(2) METADATA CHECK:

TThe Connectathon Monitor will examine the XDS metadata for the DICOM Manifest submitted by the Imaging Document Source to the NIST XDS Tools (deployed at the Connectathon). Evaluation of the metadata is based on the requirements in RAD TF-2: 4:68.4.1.2.3.2 "DocumentEntry Metadata"

The monitor will examine the metadata using the NIST XDS Tools --> under "Connectathon Tools" and "XDS.b_Doc_Source_Stores_Document".  The SubmissionSet.uniqueId value (provided by the Imaging Document Source at Connectathon) will to help the monitor find the metadata in the tool.    

In this first version of the test, we manually examine attributes.  We anticipate a tool will do this in the future:

The monitor will examine the metadata in the NIST XDS Tool for both submitted manifests, using Tab 3 of the "XDS-I.b XCA-I and WIA studies" sheet to evaluate the metadata:

• Column 1 identifies (a subset of of the) metadata attributes to evaluate.  We focus on attributes that have 'special' requirements for XDS-I in [RAD-68].
• Column 2 documents where the values come from
• Column 3 identifies values we expect in the metadata for the manifest for the DX study
• Column 4 identifies values we expect in the metadata for the manifest for the CT study