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