Query for Existing Data for Mobile (QEDm)
3.0.0-comment1 - ballot
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
IHE welcomes New Issues from the GitHub community. For those without GitHub access, issues can be submitted to the PCC Public Comment form.
As issues are submitted they will be managed on the QEDm GitHub Issues, where discussion and workarounds can be found. These issues, when critical, will be processed using the normal IHE Change Proposal management and balloting. It is important to note that as soon as a Change Proposal is approved, it carries the same weight as a published Implementation Guide (i.e., it is testable at an IHE Connectathon from the time it is approved, even if it will not be integrated until several months later).
These issues were known as part of the publication and IHE invites comments.
QEDm_012:
Currently QEDm does not constrain the FHIR Resources. This has been deliberately done due to the limited experience (Trial Implementation) with these FHIR Resources. There will be an effort during the spring and summer of 2019 to add constraints on the FHIR Resources. These constraints will be international, with support for Volume 4 regional constraints. These constraints will be based on original QED use-cases, original QED constraints, HL7 Implementation Guide for US-Core, and regional experience. All are encouraged to participate in this effort. Participate by joining the PCC technical workgroup, and by interacting with the GitHub https://github.com/IHE/QEDm.
Should we align with HL7 IPA? At this point the IPA is not yet published in a form that we can profile?
These issues have been resolved and documented in the publication.
QEDm_011: For the Medications Option, should we add split in two distinct options and add a specific query to the Medication Resource?
QEDm_001: Agree on the list of requirements for QEDm by comparing with QED.
→ Resolution:
Requirements | QED | QEDm | |
---|---|---|---|
1 | Support listing of Problems, Medications, Allergies, Med-Allergies | Yes | Yes, by using the FHIR Condition Resource |
2 | Supports listing of rest of DE (Data-element) per full QED List | Yes | Yes |
3 | Supports listing of additional DE per DAF (Access Framework) resources | No | Yes, almost |
4 | Supports access to DE across DAF/US Core defined resource | No | To be decided |
5 | Identifies source documents from where DE was extracted, if any. | Yes, but not clearly | Yes |
6 | Selects source documents for scope of query | No | Yes |
7 | Flag in response that auto de-duplication has happen by clinical DE source | No | No (Closed Issue) |
8 | Shows specific DEs that have been auto de-duplicated | No? (not with RECON) | No, too complex |
QEDm_002: Scope Listing of Data Elements Which is the best approach in specifying the QEDm query transaction and complementary provenance information? FHIR allows essentially two approaches (querying strategies in FHIR STU3):
Considerations:
→ Resolution: Basic remains the goal and Argonauts doesn’t consider ‘curated lists’ (aka ‘named’ Lists of resources) as a basic function start consider querying directly the underlying resources
QEDm_003: Which are the QEDm query parameters to consider for accessing Data Elements (Resources)?
→ Resolution: try to replicate QED functionalities according to the query strategy adopted.
QEDm_004: To define the core set of FHIR resources that align with QED and related QEDm’s options
Resolution strategy:
Comments:
Below is a comparison table between the current clinical information classification/options from QED, QEDm and FHIR Resources.
Alternative classifications from Argonauts and US Core projects/initiatives have been considered and discussed.
QED Option | QEDm Option | FHIR Resource/Profile |
---|---|---|
Vital Signs | Simple Observation | Observation (Vital Signs are profiled Observations) |
Diagnostic Results | Diagnostic Results Option | DiagnosticReport |
Problems and Allergies | Allergy and Intolerances | AllergyIntolerance |
Medications | Conditions | Condition |
Immunizations | Medications | Medication; MedicationStatement; MedicationRequest |
Professional Services | Immunizations | Immunization |
Procedures | Procedures | |
Encounters | Encounter | |
Provenance | Provenance | |
Goals → not considered | ||
Assessment and Plan → not considered | ||
CareTeam → not considered | ||
Practitioner → not considered | ||
Organization → not considered | ||
Location → not considered |
→ Resolution: Only a core-set of FHIR resources will be considered, consequently only a limited number of options are going to be specified. See the table above.
QEDm_005: Managing reconciliation of Data Elements
How to record reconciliation performed on the FHIR resources returned by the QEDm query transaction?
Considerations:
Consequences:
Reconciliation/deduplication specific content is already defined by RECON. The results of reconciliation are noted in the FHIR List resource by using the FHIR Provenance resource. See the following two sections:
BUT:
RECON specifications must be updated to FHIR STU3
See also considerations about multi-stage import/reconciliation supported by the Provenance Resource: http://hl7.org/fhir/2017Jan/provenance.html#6.2.4.6
→ Resolution: too complex, no reconciliation and no deduplication will be considered by QEDm (no automatic operations specified by RECON Profile)
QEDm_006: New name for the [PCC-44] transaction: “Mobile Query Existing Data”?
In order to appear more generic, it’s proposed to use the name “Mobile Query Existing Data” for the transaction [PCC-44] to be aligned with the QED [PCC-2] “Query Existing Data” transaction, just like done with PIX/PIXm and PDQ/PDQm.>
→ Resolution: ok to rename.
QEDm_007:How to consider the “Multi-Patient Query Option” in the query transaction?
→ Resolution: ok to remove this option from this year scope
QEDm_008: Consistency – How to identify Document Sources of Data Elements
Strategy: Consider the FHIR Provenance resource as used in PCC-RECON: “When the Data Element comes from a Document, the ID of the document is used as the source. When the Data Element is the result of a query (such as QED), the query ID is the source.
When the data comes directly from a system, provenance may not exist because there is not a document source ID from the system. The solution is to start broad and add the “provenance” Option (source of the data). …”
→ Resolution:
The original Document(s) reference(s) can be supported by the Provenance.entity: http://hl7.org/fhir/STU3/provenance.html (in general each Provenance object can link N ‘target’ Resources to M ‘entity’ Documents)
To consider also the available FHIR specifications on FHIR & XDS Documents https://www.hl7.org/FHIR/STU3/usecases.html#xds
Additional considerations on query for including Provenance:
FHIR query on “resource” (e.g., medication), add “_revinclude” with “Provenance”. GET [base]/MedicationRequest?_revinclude=Provenance:target&criteria…Always on the GET by client and server must support.
For list FHIR is an “operation” (not RESTful GET). Is it worth exposing “list operations” because may be perfectly reconciled.
Use Doc Resource versus and/or provenance resource.
QEDm_009: QED retirement
→ Resolution: it may be considered, but the timing is independent of QEDm completion
QEDm_010: Which is the best FHIR Implementation Guide to refer?
Should we move to US-Core? Are they other countries/international efforts?
Alternative is Argonaut (modified, by removing a few US specific).
Considerations:
→ Resolution: No need to base the whole profile on US Core specific constrains. US Core resource specific profiling or other profiling can be referenced only if/when necessary.
QEDm_13 ODH
Should future releases of the HL7 FHIR profile for ODH be modified as International Realm, this profile will be updated to point to those updated profiles. The scope of the modifications in the IHE ODH profiles is to reference ‘Patient’ instead of US Core Patient, and to reference the 3 US-Centric value sets with binding of ‘example’ rather than ‘required’:
Occupation, Industry, and Work Classification value sets may vary by jurisdiction. The US CDC census valuesets are provided as an ‘example binding’. There is no apparent specification for an expression of ‘concept domain’, which is leveraged by multiple IHE QRPH and PCC profiles as a method to allow for jurisdictions to specify other value sets.