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)