This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Assessment (QDM)"

From HL7Wiki
Jump to navigation Jump to search
Line 3: Line 3:
 
__FORCETOC__
 
__FORCETOC__
 
QDM defines Assessment as a resource used to define specific observations that clinicians use to guide treatment of the patient. An assessment can be a single question, or observable entity with an expected response, an organized collection of questions intended to solicit information from patients, providers or other individuals, or a single observable entity that is part of such a collection of questions. QDM further defines contexts for assessments: Assessment, Performed and Assessment, Recommended. Each context is mapped to QI Core elements in the following tables.
 
QDM defines Assessment as a resource used to define specific observations that clinicians use to guide treatment of the patient. An assessment can be a single question, or observable entity with an expected response, an organized collection of questions intended to solicit information from patients, providers or other individuals, or a single observable entity that is part of such a collection of questions. QDM further defines contexts for assessments: Assessment, Performed and Assessment, Recommended. Each context is mapped to QI Core elements in the following tables.
 +
==Assessment, Recommended==
  
 +
{|border="1" cellpadding="2" cellspacing="0"
 +
| align="center" style="background:#f0f0f0;"|'''QDM Attribute'''
 +
| align="center" style="background:#f0f0f0;"|'''QI Core Metadata Element'''
 +
| align="center" style="background:#f0f0f0;"|'''Comment'''
 +
|-valign="top"
 +
| row1cell1 | Assessment, Order
 +
| row1cell2 | ProcedureRequest.intent
 +
| row1cell3 | Procedure Request intent uses the concepts proposal, plan, order, original-order, reflex-order, filler-order, instance-order, option. "Proposal" is most consistent with the ProcedureRequest when applied to clinical decision support (CDS) in which the CDS proposes an action to a provider or to a patient. The QDM concept Order is consistent with the ProcedureRequest.intent concept "order".
 +
|-
 +
| row2cell1 | Negation Rationale
 +
| row2cell2 | ProcedureRequest.extension (http://hl7.org/fhir/StructureDefinition/procedurerequest-reasonRefused)
 +
| row2cell3 | QDM matched to QI Core / FHIR
 +
|-
 +
| row2cell1 | Reason
 +
| row2cell2 | ProcedureRequest.reasonCode
 +
| row2cell3 | QDM matched to QI Core / FHIR
 +
|-
 +
| row2cell1 | Author dateTime
 +
| row2cell2 | ProcedureRequest.AuthoredOn
 +
| row2cell3 | QDM matched to QI Core / FHIR<br>
 +
Note - ProcedureRequest.occurrence(x) defines a dateTime when the event should occur - not addressed in QDM
 +
|-
 +
| row2cell1 | Code
 +
| row2cell2 | ProcedureRequest.code
 +
| row2cell3 | QDM matched to QI Core / FHIR
 +
|-
 +
| row2cell1 | id
 +
| row2cell2 | ProcedureRequest.id
 +
| row2cell3 | QDM matched to QI Core / FHIR
 +
|-
 +
| row2cell1 | Source
 +
| row2cell2 | ProcedureRequest.requester
 +
| row2cell3 | Author, orderer - note also, ProcedureRequest.requester.agent for device, practitioner or organization who initiated the request; or ProcedureRequest.requester.onBehalfOf  - the organization the device or practitioner was acting on behalf of
 +
|-
 +
| row2cell1 | Recorder
 +
| row2cell2 | ProcedureRequest.requester.agent
 +
| row2cell3 | QDM matched to QI Core / FHIR
 +
|}
 
==Assessment, Recommended==
 
==Assessment, Recommended==
  

Revision as of 18:58, 7 June 2018

Back to Harmonization of Health Quality Information Models Page

This QDM to QI Core Mapping for the QDM Category "Assessment" was updated 16 March 2018 based on discussion in the CQI WG on March 9, 2018. Posted 9 April 2018

QDM defines Assessment as a resource used to define specific observations that clinicians use to guide treatment of the patient. An assessment can be a single question, or observable entity with an expected response, an organized collection of questions intended to solicit information from patients, providers or other individuals, or a single observable entity that is part of such a collection of questions. QDM further defines contexts for assessments: Assessment, Performed and Assessment, Recommended. Each context is mapped to QI Core elements in the following tables.

Assessment, Recommended

QDM Attribute QI Core Metadata Element Comment
Assessment, Order ProcedureRequest.intent Procedure Request intent uses the concepts proposal, plan, order, original-order, reflex-order, filler-order, instance-order, option. "Proposal" is most consistent with the ProcedureRequest when applied to clinical decision support (CDS) in which the CDS proposes an action to a provider or to a patient. The QDM concept Order is consistent with the ProcedureRequest.intent concept "order".
Negation Rationale ProcedureRequest.extension (http://hl7.org/fhir/StructureDefinition/procedurerequest-reasonRefused) QDM matched to QI Core / FHIR
Reason ProcedureRequest.reasonCode QDM matched to QI Core / FHIR
Author dateTime ProcedureRequest.AuthoredOn QDM matched to QI Core / FHIR

Note - ProcedureRequest.occurrence(x) defines a dateTime when the event should occur - not addressed in QDM

Code ProcedureRequest.code QDM matched to QI Core / FHIR
id ProcedureRequest.id QDM matched to QI Core / FHIR
Source ProcedureRequest.requester Author, orderer - note also, ProcedureRequest.requester.agent for device, practitioner or organization who initiated the request; or ProcedureRequest.requester.onBehalfOf - the organization the device or practitioner was acting on behalf of
Recorder ProcedureRequest.requester.agent QDM matched to QI Core / FHIR

Assessment, Recommended

QDM Attribute QI Core Metadata Element Comment
Assessment, Recommended ProcedureRequest.intent Procedure Request intent uses the concepts proposal, plan, order, original-order, reflex-order, filler-order, instance-order, option. "Proposal" is most consistent with the ProcedureRequest when applied to clinical decision support (CDS) in which the CDS proposes an action to a provider or to a patient. The QDM concept Recommended addresses expectations a provider gives to a patient. Such recommendations are most consistent with the ProcedureRequest.intent value of "plan" (an intension to ensure something occurs without providing an authorization to act).
Method Not addressed in QI Core
Negation Rationale ProcedureRequest.extension (http://hl7.org/fhir/StructureDefinition/procedurerequest-reasonRefused) QDM matched to QI Core / FHIR
Reason ProcedureRequest.reasonCode QDM matched to QI Core / FHIR
Author dateTime ProcedureRequest.AuthoredOn QDM matched to QI Core / FHIR

Note - ProcedureRequest.occurrence(x) defines a dateTime when the event should occur - not addressed in QDM

Code ProcedureRequest.code QDM matched to QI Core / FHIR
id ProcedureRequest.id QDM matched to QI Core / FHIR
Source ProcedureRequest.requester Author, orderer - note also, ProcedureRequest.requester.agent for device, practitioner or organization who initiated the request; or ProcedureRequest.requester.onBehalfOf - the organization the device or practitioner was acting on behalf of
Recorder ProcedureRequest.requester.agent QDM matched to QI Core / FHIR

Assessment, Performed

QDM Attribute QI Core Metadata Element Comment
Assessment, Performed Observation (the .status metadata allows conformance to the specific QDM datatype context) The context "performed" maps closest to the Observation.status final, amended, or corrected.
Method Observaton.method QDM matched to QI Core / FHIR
Negation Rationale Observation.dataAbsentReason QDM negation rationale addresses absence of the information for a known, and approved reason determined by the measure author. Thus eCQMs use a measure developer-specific value set for negation rationale. The value set for Observation.dataAbsentReason is required so QI Core would need to be an extension of the existing information. Note, the referenced value set is extensible.
Reason Observaton.basedOn QDM matched to QI Core / FHIR
Result Observation.value(x) QDM matched to QI Core / FHIR

Note - QI Core also includes Observation.interpretation and Observation.comment - eCQMs have addressed interpretation as an implementation issue.
Note that the QDM assessment result (or results for components of results can be numerical values, codes or dateTime entries.

Author dateTime FHIR.provenance.recorded FHIR references authorDatetime as part of the provenance resource for all resources.

QDM only addresses Author dateTime; QI Core allows a Period. Assessment generally addresses specific documentation of observations. Consider: Assessment to determine tobacco use history might ask for when tobacco use started and when it ended. The start time and stop time could be represented as answers to two different questions (i.e., when did the patient start and when did the patient end tobacco use). The observation.effective.x would apply more directly to a laboratory test the included collection of a specimen over a period of time. Consider authorDatetime for Assessment, Performed is the dateTime the assessment is captured. Note that the QDM assessment result (or results for components of results can be numerical values, codes or dateTime entries.
QDM might consider a Relevant Period consistent with observation.effective.x indicating the Relevant Period start and stop times are the same unless otherwise specified. Such practice would be consistent with other QDM datatypes that map to observation.

Related To Observation.basedOn QDM matched to QI Core / FHIR

Alternate name: fulfills

Code Observation.code QDM matched to QI Core / FHIR
Components Observation.component QDM uses components to combine related observations to each other, e.g., a set of independent observations performed within an admission assessment for an inpatient admission. Each observation is unique (e.g., questions about tobacco usage, other substance usage, blood pressure, pulse, skin turgor, etc., etc.) but they are captured during the same patient-provider interaction. Such QDM components should map directly to QI Core / FHIR observations that can be linked to other observations. Other QDM component examples include multiple questions that are part of a validated evaluation tool (e.g., a Braden skin assessment scale). This latter example indicates individual questions that are inherently tied to the Braden scale instrument and the questions and answers do not have inherent value without being part of the instrument. QI Core / FHIR considers each such question as an Observation.component. A general rule of thumb is QI Core / FHIR components apply only when the inherent value of the observation is defined by the parent observation. The result is that the content will determine if a QDM component maps to Observation.code or to Observation.component.code.
Component Code Observation.component.code See "Components" - The content will determine if a QDM component maps to Observation.code or to Observation.component.code
Component Result Observation.component.value(x) See "Components" - The content will determine if a QDM component maps to Observation.value(x) or to Observation.component.value(x)

Note that the QDM assessment result (or results for components of results can be numerical values, codes or dateTime entries.

id Observation.id QDM matched to QI Core / FHIR
Source Observation.performer QDM matched to QI Core / FHIR

Note - Observation.performer and Observation.device address the QDM concept of Source; use Observation.device if the observer is a device.