Query for Existing Data for Mobile (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.
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
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.
- 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
.
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 is not yet published
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
This page is based on the Profile Overview Template