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

Difference between revisions of "Laboratory Test (QDM)"

From HL7Wiki
Jump to navigation Jump to search
(Created page with "[http://wiki.hl7.org/index.php?title=Harmonization_of_Health_Quality_Information_models Back to Harmonization of Health Quality Information Models Page]<br>")
 
Line 1: Line 1:
 
[http://wiki.hl7.org/index.php?title=Harmonization_of_Health_Quality_Information_models Back to Harmonization of Health Quality Information Models Page]<br>
 
[http://wiki.hl7.org/index.php?title=Harmonization_of_Health_Quality_Information_models Back to Harmonization of Health Quality Information Models Page]<br>
 +
__FORCETOC__
 +
QDM defines Laboratory Test as a medical procedure that involves testing a sample of blood, urine, or other substance from the body. Tests can help determine a diagnosis, plan treatment, check to see if treatment is working, or monitor the disease over time.  This QDM data category for Laboratory Test is only used for information about the subject of record. QDM defines three contexts for Laboratory Test: Laboratory Test, Order; Laboratory Test, Performed; Laboratory Test, Recommended.
 +
 +
 +
==Laboratory Test, Order==
 +
 +
{|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 | Laboratory Test, Order
 +
| row1cell2 | ProcedureRequest.intent
 +
| row1cell3 | Procedure Request intent uses the concepts proposal, plan, order, original-order, reflex-order, filler-order, instance-order, option. Constrain to "order" from the intent value set for QDM datatypes with the order context.
 +
|-
 +
| row2cell1 | Method
 +
| row2cell2 |
 +
| row2cell3 | This item is not found in QI Core. In most instances, quality measure developers address procedure methods by using specific, pre-coordinated terminology (e.g., specific LOINC codes indicating the test and the method)
 +
|-
 +
| 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, Use http://hl7.org/fhir/us/qicore/qicore-procedurerequest-appropriatenessScore.html to address RAND criteria for appropriate imaging usage criteria.
 +
| row2cell3 | QDM matched to QI Core / FHIR
 +
|-
 +
| row2cell1 | Author dateTime
 +
| row2cell2 | ProcedureRequest.AuthoredOn
 +
| row2cell3 | QDM matched to QI Core/FHIR. Note - ProcedureRequest.occurrence(x) defines a dateTime when the event should occur - not addressed in QDM
 +
|-
 +
| row2cell1 | Code
 +
| row2cell2 | ProcedureRequest.code
 +
| row2cell3 | See also, Observation.category
 +
|-
 +
| 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 on whose behalf the device or practitioner was acting
 +
|}
 +
==Laboratory Test, 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 | Laboratory Test, Recommended
 +
| 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 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).
 +
|-
 +
| row2cell1 | Method
 +
| row2cell2 |
 +
| row2cell3 | This item is not found in QI Core. In most instances, quality measure developers address procedure methods by using specific, pre-coordinated terminology (e.g., specific LOINC codes indicating the test and the method)
 +
|-
 +
| 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, Use http://hl7.org/fhir/us/qicore/qicore-procedurerequest-appropriatenessScore.html to address RAND criteria for appropriate imaging usage criteria.
 +
| row2cell3 | QDM matched to QI Core / FHIR
 +
|-
 +
| row2cell1 | Author dateTime
 +
| row2cell2 | ProcedureRequest.AuthoredOn
 +
| row2cell3 | QDM matched to QI Core/FHIR. Note - ProcedureRequest.occurrence(x) defines a dateTime when the event should occur - not addressed in QDM
 +
|-
 +
| row2cell1 | Code
 +
| row2cell2 | ProcedureRequest.code
 +
| row2cell3 | See also, Observation.category
 +
|-
 +
| 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 on whose behalf the device or practitioner was acting
 +
|}
 +
==Laboratory Test, Performed==
 +
 +
{|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 | Laboratory Test, Performed
 +
| row1cell2 | Observation (the .status metadata allows conformance to the specific QDM datatype context)
 +
| row1cell3 | QDM matched to QI Core / FHIR
 +
|-
 +
| row2cell1 | Method
 +
| row2cell2 | Observaton.method
 +
| row2cell3 | QDM matched to QI Core / FHIR
 +
|-
 +
| row3cell1 | Negation Rationale
 +
| row3cell2 | Observation.dataAbsentReason
 +
| row3cell3 | The value set is required. Many eCQMs use a measure developer-specific value set. Note, component also has a Observation.component.dataAbsentReason in QI Core.
 +
|-
 +
| row4cell1 | Reason
 +
| row4cell2 | Observation.basedOn
 +
| row4cell3 | This is the best fit in QI Core
 +
|-
 +
| row4cell1 | Reference Range High
 +
| row4cell2 | Observation.referenceRange.high
 +
| row4cell3 | QI Core also references Observation.referenceRange.type - i.e. what part of the referenced target population it applies to (e.g., normal or therapeutic range); and Observation.referenceRange.appliesTo - i.e., the target population (normal population, or particular sex or race), and Observation.referenceRange.age. QI Core also addresses Observation.component.referenceRange. Should these options be considered for QDM?
 +
|-
 +
| row4cell1 | Reference Range Low
 +
| row4cell2 | Observation.referenceRange.low
 +
| row4cell3 | QI Core also references Observation.referenceRange.type - i.e. what part of the referenced target population it applies to (e.g., normal or therapeutic range); and Observation.referenceRange.appliesTo - i.e., the target population (normal population, or particular sex or race), and Observation.referenceRange.age. QI Core also addresses Observation.component.referenceRange. Should these options be considered for QDM?
 +
|-
 +
| row5cell1 | Result
 +
| row5cell2 | Observation.value(x)
 +
| row5cell3 | Observation.value(x) refers to QI Core Observation which is noted here. Note - QI Core also includes Observation.interpretation and Observation.comment - eCQMs have addressed interpretation as an implementation issue. Perhaps that approach should be reconsidered.
 +
|-
 +
| row6cell1 | Result dateTime
 +
| row6cell2 | Observation.issued
 +
| row6cell3 | QDM matched to QI Core / FHIR
 +
|-
 +
| row7cell1 | Relevant Period
 +
| row7cell2 | Observaton.effective[x]
 +
| row7cell3 | QDM matched to QI Core / FHIR
 +
|-
 +
| row8cell1 | Status
 +
| row8cell2 | Observation.status
 +
| row8cell3 | QDM matched to QI Core / FHIR
 +
|-
 +
| row8cell1 | Code
 +
| row8cell2 | Observation.code
 +
| row8cell3 | Note - QI Core includes Observation.specimen - eCQMs use the LOINC value set to determine the specimen source
 +
|-
 +
| row8cell1 | Author dateTime
 +
| row8cell2 | Observation.issued
 +
| row8cell3 | QDM matched to QI Core / FHIR
 +
|-
 +
| row8cell1 | Components
 +
| row8cell2 | Observation.component
 +
| row8cell3 | 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.
 +
|-
 +
| row8cell1 | Component Code
 +
| row8cell2 | Observation.component.code
 +
| row8cell3 | See "Component" - Content-specific
 +
|-
 +
| row8cell1 | Component Result
 +
| row8cell2 | Observation.component.value(x)
 +
| row8cell3 | See "Component" - Content-specific
 +
|-
 +
| row8cell1 | Component Reference Range High
 +
| row8cell2 | Observation.component.referenceRange
 +
| row8cell3 | Refers back to Component.referenceRange
 +
|-
 +
| row8cell1 | Component Reference Range Low
 +
| row8cell2 | Observation.component.referenceRange
 +
| row8cell3 | Refers back to Component.referenceRange
 +
|-
 +
| row14cell1 | id
 +
| row14cell2 | Observation.id
 +
| row14cell3 | QDM matched to QI Core / FHIR
 +
|-
 +
| row15cell1 | Source
 +
| row15cell2 | Observation.performer
 +
| row15cell3 | Note - QI Core includes Observation.subject - QDM should consider adding subject instead of health record field
 +
|}

Revision as of 14:19, 29 March 2018

Back to Harmonization of Health Quality Information Models Page

QDM defines Laboratory Test as a medical procedure that involves testing a sample of blood, urine, or other substance from the body. Tests can help determine a diagnosis, plan treatment, check to see if treatment is working, or monitor the disease over time. This QDM data category for Laboratory Test is only used for information about the subject of record. QDM defines three contexts for Laboratory Test: Laboratory Test, Order; Laboratory Test, Performed; Laboratory Test, Recommended.


Laboratory Test, Order

QDM Attribute QI Core Metadata Element Comment
Laboratory Test, Order ProcedureRequest.intent Procedure Request intent uses the concepts proposal, plan, order, original-order, reflex-order, filler-order, instance-order, option. Constrain to "order" from the intent value set for QDM datatypes with the order context.
Method This item is not found in QI Core. In most instances, quality measure developers address procedure methods by using specific, pre-coordinated terminology (e.g., specific LOINC codes indicating the test and the method)
Negation Rationale ProcedureRequest.extension (http://hl7.org/fhir/StructureDefinition/procedurerequest-reasonRefused) QDM matched to QI Core / FHIR
Reason ProcedureRequest.reasonCode, Use http://hl7.org/fhir/us/qicore/qicore-procedurerequest-appropriatenessScore.html to address RAND criteria for appropriate imaging usage criteria. 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 See also, Observation.category
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 on whose behalf the device or practitioner was acting

Laboratory Test, Recommended

QDM Attribute QI Core Metadata Element Comment
Laboratory Test, 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 This item is not found in QI Core. In most instances, quality measure developers address procedure methods by using specific, pre-coordinated terminology (e.g., specific LOINC codes indicating the test and the method)
Negation Rationale ProcedureRequest.extension (http://hl7.org/fhir/StructureDefinition/procedurerequest-reasonRefused) QDM matched to QI Core / FHIR
Reason ProcedureRequest.reasonCode, Use http://hl7.org/fhir/us/qicore/qicore-procedurerequest-appropriatenessScore.html to address RAND criteria for appropriate imaging usage criteria. 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 See also, Observation.category
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 on whose behalf the device or practitioner was acting

Laboratory Test, Performed

QDM Attribute QI Core Metadata Element Comment
Laboratory Test, Performed Observation (the .status metadata allows conformance to the specific QDM datatype context) QDM matched to QI Core / FHIR
Method Observaton.method QDM matched to QI Core / FHIR
Negation Rationale Observation.dataAbsentReason The value set is required. Many eCQMs use a measure developer-specific value set. Note, component also has a Observation.component.dataAbsentReason in QI Core.
Reason Observation.basedOn This is the best fit in QI Core
Reference Range High Observation.referenceRange.high QI Core also references Observation.referenceRange.type - i.e. what part of the referenced target population it applies to (e.g., normal or therapeutic range); and Observation.referenceRange.appliesTo - i.e., the target population (normal population, or particular sex or race), and Observation.referenceRange.age. QI Core also addresses Observation.component.referenceRange. Should these options be considered for QDM?
Reference Range Low Observation.referenceRange.low QI Core also references Observation.referenceRange.type - i.e. what part of the referenced target population it applies to (e.g., normal or therapeutic range); and Observation.referenceRange.appliesTo - i.e., the target population (normal population, or particular sex or race), and Observation.referenceRange.age. QI Core also addresses Observation.component.referenceRange. Should these options be considered for QDM?
Result Observation.value(x) Observation.value(x) refers to QI Core Observation which is noted here. Note - QI Core also includes Observation.interpretation and Observation.comment - eCQMs have addressed interpretation as an implementation issue. Perhaps that approach should be reconsidered.
Result dateTime Observation.issued QDM matched to QI Core / FHIR
Relevant Period Observaton.effective[x] QDM matched to QI Core / FHIR
Status Observation.status QDM matched to QI Core / FHIR
Code Observation.code Note - QI Core includes Observation.specimen - eCQMs use the LOINC value set to determine the specimen source
Author dateTime Observation.issued 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 "Component" - Content-specific
Component Result Observation.component.value(x) See "Component" - Content-specific
Component Reference Range High Observation.component.referenceRange Refers back to Component.referenceRange
Component Reference Range Low Observation.component.referenceRange Refers back to Component.referenceRange
id Observation.id QDM matched to QI Core / FHIR
Source Observation.performer Note - QI Core includes Observation.subject - QDM should consider adding subject instead of health record field
Retrieved from "https://wiki.hl7.org/w/index.php?title=Laboratory_Test_(QDM)&oldid=155169"