Query for Existing Data for Mobile

From IHE Wiki
Jump to: navigation, search

supports queries for clinical data elements, including observations, allergy and intolerances, conditions, diagnostic results, medications, immunizations, procedures, encounters and provenance by making the information widely available to other systems within and across enterprises.

Summary

The Query for Existing Data for Mobile Profile (QEDm) supports queries for clinical data elements, including observations, allergy and intolerances, conditions, diagnostic results, medications, immunizations, procedures, encounters and provenance by making the information widely available to other systems within and across enterprises. It defines a transaction used to query a list of specific data elements, persisted as FHIR resources.

It’s functionally equivalent to the QED Profile, but is conceived to be implemented by applications specific to mobile devices. The term “mobile” should be considered in a wider sense: it identifies not only mobile applications, but the whole class of systems that are resource- and platform-constrained. (e.g., tablets, smartphones, and embedded devices including home-health devices, but also larger systems where needs are simple, such as pulling the latest summary for display).


Benefits

MXDE Picture.jpg

The QEMm Profile has been designed to be used in conjunction with the Mobile Cross-Enterprise Document Data Element Extraction (mXDE) Profile. Combining these two profiles provides the means to access data elements extracted from shared structured documents. They enable the deployment of health data exchange infrastructures where fine-grained access to health data coexists and complements the sharing of coarse-grained documents and the fine-grained data elements they contain.

These two profiles are based on the reality that health information sharing relies on different granularities of exchange:

  • Document-Level Granularity: share and access documents as a composition of various data elements to reflect the information known and produced during a care or administrative workflow step. This level of granularity is optimum to ensure that contained data has clarity of context in care delivery and reflects source attestation (responsibility) of clinical data shared.
  • Data Element-Level Granularity: access a specific type of data element (e.g., vital signs, medications, etc.). This level of granularity is optimum when the list of data elements relevant to a “time span” or a set of encounters is of interest. Examples of situations where this level of granularity may be optimum include access to a list of allergies at the time of medication dispensation, or information reconciliation at the time of hospital admission.

Each granularity level delivers unique benefits and this profile provides efficient access to both levels.

QEDm with its Provenance Option and mXDE define rules to ensure consistency and traceability of information used for clinical decisions. When a data element is accessed by a Clinical Data Consumer, identifiers from that data element can be used to access one or more documents in which this data element was originally recorded, providing a valuable broader clinical context.

The flows of information are depicted in the figure on the right:

  1. - Specific data elements are extracted from the structured documents per mXDE Profile (Mobile Cross-Enterprise Document Data Element Extraction).
  2. - Data elements (e.g. allergies) queried using the FHIR based QEDm Profile.
  3. - Each data element is referenced to the document(s) from which it was extracted per mXDE Profile.
  4. - Clinician accesses context of any data element of interest using source documents (XDS, MHD Profiles) providing the clinical context in which the observation was recorded.

Details

MXDE-Figure-45-2.png

The access to health information across community, regional, or national health information exchange platforms is one of the fundamental paradigms of exchange of health records. Currently, these kinds of records are often shared using IHE profiles such as Cross-Enterprise Document Sharing (XDS), Cross-Community Access (XCA), and Mobile access to Health Documents (MHD).

However, many health information exchange platforms that support document sharing are considering extending their services by offering cross-document data aggregation. This can be addressed, in part, with the access to documents dynamically created with the On-Demand Document Source Actor in the XDS Profile, and, in part, with profiles such as PCC’s Query for Existing Data for Mobile (QEDm) Profile that supports the granular access to specific data elements (e.g., list of medications, list of allergies).

The QEDm and mXDE Profiles take it one step further. It allows an integrated approach to health records by using existing services from the IHE profiles mentioned above.

The mapping of the document to data elements is outside the scope of the mXDE Profile. It needs to be specified for each deployment based on the specific document content and data elements managed.

The Figure on the left conceptually depicts the sharing of health information supported by QEDm and mXDE, highlighting that health information could be shared at different levels of granularity: Document-Level Granularity (shown with the green documents) and the Data Element-Level Granularity (shown with orange hexagons). The health data exchange infrastructure depicted as a “hub” in the middle is providing a location service to access both document-level or data element-level health data in a patient-centric manner.

  • Document-Level Granularity “publication” is out of scope of the QEDm profile but may be performed using the XDS Provide and Register ITI-41 transaction, the MHD Provide Document Bundle ITI-65 transaction or other means.
  • Data Element-Level Granularity access is central to mXDE and is discussed in Section 45.1 of Volume 1 of the IT Infrastructure Technical Framework. The Provenance information, returned with each fine-grained data element in the QEDm Query responses, allows identification of the document from which the fine-grained data element was extracted and is described in the Provenance Option of the QEDm Profile.
  • Document-Level Granularity “consumption” is central to mXDE and is discussed in Section 45.1 of Volume 1 of the IT Infrastructure Technical Framework. Using the identification of the document from which a data element was extracted, it is possible to access the clinical context in which that data element was observed.

The mXDE profile combined with the QEDm profile support a variety of deployment models. Two of those are discussed in Section 45.7 of Volume 1 of the IT Infrastructure Technical Framework.

Systems Affected

  • systems needing data-elements
  • HIE Infrastructure that can extract data-elements from Documents in a Document Sharing infrastructure

Actors & Transactions:

  • The Clinical Data Source in this profile responds to FHIR-based queries for one or more fine-grained data elements (FHIR resources) defined by the options listed in Section X.2. The Clinical Data Source shall support at least one of those options and may support more than one option.
  • The Clinical Data Consumer in this profile sends FHIR-based queries to the Clinical Data Source for one or more fine-grained data elements (FHIR resources) defined by the options listed in Section X.2. Rendering or further processing of the data is not defined by this profile. The Clinical Data Consumer shall support querying for at least one of the data elements that are defined by this profile’s options.

Specification

Profile Status: Trial Implementation

Documents:

The supplement for Trial Implementation has been published in August 2017.

Additional Supplements: Appendix Z on HL7 FHIR

Underlying Standards:

  • HL7 FHIR STU3 http://hl7.org/fhir/STU3
    • Observation
    • AllergyIntolerance
    • Condition
    • DiagnosticReport
    • Medication
    • MedicationStatement
    • MedicationRequest
    • Immunization
    • Procedure
    • Encounter
    • Provenance
    • OperationOutcome
    • Bundle
  • RFC2616 IETF Hypertext Transfer Protocol – HTTP/1.1
  • RFC3986 IETF Uniform Resource Identifier (URI): Generic Syntax
  • RFC4627 The application/json Media Type for JavaScript Object Notation (JSON)
  • RFC6585 IETF Additional HTTP Status Codes

Document Sharing


This page is based on the Profile Overview Template