QEDm: Read This First

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