Query for Existing Data for Mobile (QEDm), published by IHE Patient Care Coordination Technical Committee. This guide is not an authorized publication; it is the continuous build for version 3.0.0-comment1 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/IHE/QEDm/ and changes regularly. See the Directory of published versions

Query for Existing Data for Mobile (QEDm) Home

Official URL: https://profiles.ihe.net/PCC/QEDm/ImplementationGuide/ihe.pcc.qedm				Version: 3.0.0-comment1
Active as of 2024-07-26				Computable Name: IHE_PCC_QEDm

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

QEDm is functionally equivalent to the QED Profile (based on HL7v3), but QEDm is better suited for implementation by application on mobile devices or where the http/REST technology is preferred. The term “mobile” must be understood in a wide sense: it refers not only to applications on devices used for mobility that are resource- and platform-constrained (e.g., tablets, smartphones, and embedded devices including home-health devices), but also to larger systems deployed in environments where interoperability requirements are simple, such as pulling the latest summary for display.

The Query for Existing Data for Mobile (QEDm) Profile defines a standardized interface to health (HTTP-based RESTful APIs) suited for deployment of mobile applications on resource-constrained devices with simple programming environment (e.g., JavaScript), simple protocol stack (e.g., HTTP), and simple display functionality (e.g., HTML browser). The goal is to limit required additional libraries that are often necessary to process SOAP, MIME-Multipart, and MTOM/XOP Web Services.

The Query for Existing Data for Mobile Profile (QEDm) Profile uses the already defined actors Clinical Data Consumer and Clinical Data Source, for which it specifies options and a transaction to be used for querying a list of specific data elements, persisted as FHIR resources. The current version of the supplement doesn’t consider the reconciliation of the fine-grained data elements gathered by the Clinical Data Source and/or Clinical Data Consumer Actors. In order to perform reconciliation, a grouping with RECON Reconciliation Agent SHOULD be considered.

The QEDm Profile MAY also be deployed in conjunction with document sharing profiles such as the MHD or XDS Profiles. The Provenance Option in QEDm is used in particular by the mXDE Profile to address the combined deployment of QEDm for access to fine-grained data elements with links to source documents accessible through the MHD or XDS Profiles.

Organization of This Guide

This guide is organized into the following sections:

1. Volume 1: Profiles
   1. Introduction
   2. Actors and Transactions
   3. Actor Options
   4. Actor Required Groupings
   5. Overview
   6. Security Considerations
   7. Cross Profile Considerations
2. Volume 2: Transaction Detail
   1. Mobile Query for Existing Data [PCC-44]

3. Volume 4: National Extensions

4. Other
   1. Changes to Other IHE Specification
   2. Downloads and Analysis
   3. Test Plan

See also the Table of Contents and the index of Artifacts defined as part of this implementation guide.

Conformance Expectations

IHE uses the normative words: SHALL, SHOULD, and MAY according to standards conventions.

Must Support

The use of mustSupport in StructureDefinition profiles equivalent to the IHE use of R2 as defined in Appendix Z.

mustSupport of true - only has a meaning on items that are minimal cardinality of zero (0), and applies only to the source actor populating the data. The source actor SHALL populate the elements marked with MustSupport, if the concept is supported by the actor, a value exists, and security and consent rules permit. The consuming actors SHOULD handle these elements being populated or being absent/empty. Note that sometimes mustSupport will appear on elements with a minimal cardinality greater than zero (0), this is due to inheritance from a less constrained profile.