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.