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

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.

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