Query for Existing Data for Mobile (QEDm)
3.0.1-current - ci-build
Query for Existing Data for Mobile (QEDm)
3.0.1-current - ci-build
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.1-current built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/IHE/PCC.QEDm/ and changes regularly. See the Directory of published versions
| Official URL: https://profiles.ihe.net/PCC/QEDm/CapabilityStatement/IHE.QEDm.Clinical-Data-Consumer | Version: 3.0.1-current | |||
| Active as of 2024-07-17 | Computable Name: IHE_QEDm_Clinical_Data_Consumer | |||
CapabilityStatement for Clinical Data Consumer Actor
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 8.2 QEDm Actor Options. Rendering or further processing of the data is not defined by this profile.
Raw OpenAPI-Swagger Definition file | Download
Generated Narrative: CapabilityStatement IHE.QEDm.Clinical-Data-Consumer
application/fhir+json, MAY support application/fhir+xmlapplication/json-patch+jsonNote to Implementers: FHIR Capabilities
Any FHIR capability may be 'allowed' by the system unless explicitly marked as 'SHALL NOT'. A few items are marked as MAY in the Implementation Guide to highlight their potential relevance to the use case.
serverThe 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 8.2 QEDm Actor Options.
Recommend ATNA, encouraged IHE-IUA or SMART-app-launch
The summary table lists the resources that are part of this configuration, and for each resource it lists:
_include_revinclude| Resource Type | Profile | R | S | U | C | Searches | _include | _revinclude | Operations |
|---|---|---|---|---|---|---|---|---|---|
| AllergyIntolerance | y | y | patient | Provenance:target | |||||
| Condition | y | y | category, clinical-status, patient, patient+clinical-status, patient+category | Provenance:target | |||||
| Immunization | y | y | patient | Provenance:target | |||||
| Medication | y | y | patient | Provenance:target | |||||
| MedicationRequest | y | y | patient | MedicationRequest:medication | Provenance:target | ||||
| MedicationStatement | y | y | patient | MedicationStatement:medication | Provenance:target | ||||
| Observation | Supported Profiles Vital Signs Profile Combat Zone Period Employment Status Occupational Data For Health Past Or Present Job Retirement Date Usual Work | y | y | category, code, date, status, patient, patient+category, patient+code, patient+category+date, patient+code+date | Provenance:target | ||||
| DiagnosticReport | y | y | category, code, date, patient, patient+category, patient+category+code, patient+category+date, patient+category+code+date | Provenance:target | |||||
| Procedure | y | y | date, patient, patient+date | Provenance:target | |||||
| Encounter | y | y | date, patient, patient+date | Provenance:target | |||||
| Provenance | Supported Profiles mXDE Provenance | y | y | target |
resolvesread, search-type.| Conformance | Parameter | Type | Documentation |
|---|---|---|---|
| SHOULD | patient | reference |
resolvesread, search-type.Client applications should be prepared to encounter codes they do not recognize and handle the records accordingly. Servers SHOULD populate Condition.code.coding.display and/or Condition.code.text so that clients can always at least display the condition even if they do not know the codes that are used. Clients should be careful making use of the
codesearch parameter given that the codes used vary so much.Safety Issues:
- Clients SHALL not treat all conditions as if they are part of the patient's current problem list
- Note that some Condition resources may not have these status codes - this is usually due to poor record keeping reflected in legacy data
- Servers SHOULD avoid leaving these status codes missing
- Clients SHALL pay attention to the
clinicalStatusandverificationStatusand display and process them correctly- Clients SHALL still work safely when the server does not support all the search parameters listed here.
| Conformance | Parameter | Type | Documentation |
|---|---|---|---|
| SHOULD | patient | reference | |
| MAY | category | token | The category of the condition |
| MAY | clinical-status | token | The clinical status of the condition |
| Conformance | Parameters | Types |
|---|---|---|
| MAY | patient+clinical-status | reference+token |
| MAY | patient+category | reference+token |
resolvesread, search-type.| Conformance | Parameter | Type | Documentation |
|---|---|---|---|
| SHOULD | patient | reference |
resolvesread, search-type.The MedicationStatement and MedicationRequest resources can represent a medication, using an external reference to a Medication resource. If an external Medication Resource is used in a MedicationStatement or a MedicationRequest, then the READ and SEARCH Criteria SHALL be supported.
| Conformance | Parameter | Type | Documentation |
|---|---|---|---|
| SHOULD | patient | reference |
resolvesread, search-type.Clients SHALL query for both MedicationStatement and MedicationRequest when fetching patient Medication information.
The MedicationRequest resources can represent a medication using either a code or refer to the Medication resource. When referencing Medication, the resource may be contained or an external resource. The server application MAY choose any one way or more than one method, but if an external reference to Medication is used, the server SHALL support the
_includeparameter for searching this element. The client application SHALL support all methods. For example, A server SHALL be capable of returning all medications for a patient using one of or both:
GET /MedicationStatement?patient=[id]
GET /MedicationStatement?patient=[id]&_include=MedicationStatement:medicationWhen representing a prescribed medication, servers SHOULD use codings at the level of a clinical drug rather than ingredient or dose form (e.g. "loratadine 10mg oral tablet", rather than a bare ingredient like "loratadine" or a dose form like "loratadine oral tablet").
| Conformance | Parameter | Type | Documentation |
|---|---|---|---|
| SHOULD | patient | reference |
resolvesread, search-type.Clients SHALL query for both MedicationStatement and MedicationRequest when fetching patient Medication information.
The MedicationRequest resources can represent a medication using either a code or refer to the Medication resource. When referencing Medication, the resource may be contained or an external resource. The server application MAY choose any one way or more than one method, but if an external reference to Medication is used, the server SHALL support the
_includeparameter for searching this element. The client application SHALL support all methods.
| Conformance | Parameter | Type | Documentation |
|---|---|---|---|
| SHOULD | patient | reference |
resolvesread, search-type.| Conformance | Parameter | Type | Documentation |
|---|---|---|---|
| MAY | category | token | The classification of the type of observation |
| MAY | code | token | The code of the observation type |
| MAY | date | date | Obtained date/time. If the obtained element is a period, a date that falls in the period. The date modifiers |
| MAY | status | token | The status of the observation |
| MAY | patient | reference | The Clinical Data Consumer SHALL support at least one of the search parameters combinations. |
resolvesread, search-type.| Conformance | Parameter | Type | Documentation |
|---|---|---|---|
| SHOULD | category | token | The classification of the type of observation |
| SHOULD | code | token | The code of the observation type |
| SHOULD | date | date | Obtained date/time. If the obtained element is a period, a date that falls in the period. The date modifiers |
| SHOULD | patient | reference |
resolvesread, search-type.resolvesread, search-type.resolvesread, search-type.| Conformance | Parameter | Type | Documentation |
|---|---|---|---|
| SHOULD | target | reference |
IG © 2023+ IHE Patient Care Coordination Technical Committee. Package ihe.pcc.qedm#3.0.1-current based on FHIR 4.0.1. Generated 2024-12-05
Links: Table of Contents |
QA Report
| New Issue | Issues
Version History |
|
Propose a change