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

Difference between revisions of "Device (QDM)"

From HL7Wiki
Jump to navigation Jump to search
 
(12 intermediate revisions by 2 users not shown)
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]
 
__FORCETOC__
 
__FORCETOC__
 +
 +
This QDM to QI Core Mapping for the QDM Datatype "Device" was reviewed by the CQI WG on April 6, 2018 for QDM version 5.3. The content presented here is based on QDM version 5.4 and removes the QDM 5.3 attribute "anatomical approach site" as there was no existing use or clear use case to retain it. <br>
 +
QDM defines Device as an instrument, apparatus, implement, machine, contrivance, implant, in-vitro reagent, or other similar or related article, including a component part or accessory, intended for use in the diagnosis, cure, mitigation, treatment, or prevention of disease and not dependent on being metabolized to achieve any of its primary intended purposes.  QDM provides three contexts for expressing devices: Device, Applied; Device, Order; and Device, Recommended.
 +
# Note that the current use of the QDM datatype “Device, Applied” usually references the procedure to “apply” the device (i.e., to use for the patient, to use on the patient’s body, or to implant in the patient’s body). Each of these current uses should address the concept using the QDM datatypes, Intervention, Performed, or Procedure, Performed. 
 +
# The original intent of the QDM datatype “Device, Applied” was to reference the specific device or type of device of concern to the measure. And that reference might be as detailed a providing a device class as referenced in a Unique Device Identifier (UDI). The FHIR Device resource (http://hl7.org/fhir/device.html) does have a metadata element for UDI (http://hl7.org/fhir/device-definitions.html#Device.udi). All device metadata reference inherent qualities of the device. And timing addresses Device.manufactureDate and Device.expirationDate. Therefore, a direct map to the Device resource may not be sufficient or appropriate for the QDM Device, Applied datatype.
 +
# The FHIR Resource DeviceUseStatement (http://hl7.org/fhir/deviceusestatement.html) is a more appropriate resource to map QDM Device, Applied. The DeviceUseStatement has a maturity level of 0, so the mapping will need to be updated as the resource is updated. Note: this mapping will need to be reviewed with the QI Core DeviceUseStatement to assure alignment since the current QI Core content does not seem to address the most recent version of DeviceUseStatement.
 +
 
==Device, Applied==
 
==Device, Applied==
  
Line 9: Line 17:
  
 
| row1cell1 | Device Applied
 
| row1cell1 | Device Applied
| row1cell2 | Procedure (the .status metadata allows conformance to the specific QDM datatype context)
+
| row1cell2 | DeviceUseStatement
| row1cell3 | Device.status allows active | inactive | entered-in-error | unknown as a required value set; Procedure.status seems more appropriate - constrain the event code to "Completed"
+
| row1cell3 | A record of a device being used by a patient where the record is the result of a report from the patient or another clinician.
|-
 
| row2cell1 | Anatomical Approach Site
 
| row2cell2 | Procedure.extension (http://hl7.org/fhir/us/qicore/StructureDefinition/qicore-procedurerequest-approachBodySite)
 
| row2cell3 | QDM matched to QI Core / FHIR
 
 
|-
 
|-
 
| row2cell1 | Anatomical Location Site
 
| row2cell1 | Anatomical Location Site
| row2cell2 | Procedure.bodySite
+
| row2cell2 | DeviceUseStatement.bodySite
| row2cell3 | Device.location (QI Core only) can indicate where the resource is found, but Procedure seems a better fit for Device, Applied
+
| row2cell3 | Indicates the site on the subject's body where the device was used ( i.e. the target site).
 
|-
 
|-
 
| row2cell1 | Negation Rationale
 
| row2cell1 | Negation Rationale
| row2cell2 | Procedure.notDoneReason
+
| row2cell2 | None
| row2cell3 | QDM matched to QI Core / FHIR
+
| row2cell3 | A DeviceUseStatement does not address negation directly since there would be no statement if the device were absent. QDM usage is to indicate devices that have not been applied should address negation rationale for the order or the recommendation (i.e., ProcedureRequest.extension (reasonRefused)). One could address negation rationale by indicating DeviceUseStatement.status constrained to values stopped or on-hold and reference DeviceUseStatement.reason to indicate the reason (i.e., reason for not using the device).
 
|-
 
|-
 
| row2cell1 | Reason
 
| row2cell1 | Reason
| row2cell2 | Procedure.reasonCode
+
| row2cell2 | DeviceUseStatement.indication
| row2cell3 | QDM matched to QI Core / FHIR
+
| row2cell3 | Reason or justification for use of the device.
 
|-
 
|-
 
| row2cell1 | Relevant Period
 
| row2cell1 | Relevant Period
| row2cell2 | Procedure.performed[x]
+
| row2cell2 | DeviceUseStatement.whenUsed
| row2cell3 | QDM matched to QI Core / FHIR [Note that Procedure.performed generally refers to a point in time which implementers should map the the start of the relevant period. In most cases the start and end of the Relevant Period will be the same.
+
| row2cell3 | The time period over which the device was used.
 +
Note – the DeviceUseStatement resource also has a metadata element: DeviceUseStatement.timing(x) indicating how often the device was used (may be a period or dateTime).
 
|-
 
|-
 
| row2cell1 | Author dateTime
 
| row2cell1 | Author dateTime
| row2cell2 | part of FHIR Provenance Resource
+
| row2cell2 | DeviceUseStatement.recordedOn
| row2cell3 | FHIR references authorDatetime as part of the provenance resource for all resources. Is authorDatetime still appropriate for this QDM datatype?
+
| row2cell3 | The time at which the DeviceUseStatement was made/recorded.
 
|-
 
|-
 
| row2cell1 | Code
 
| row2cell1 | Code
| row2cell2 | Procedure.focalDevice
+
| row2cell2 | DeviceUseStatement.device <br>
| row2cell3 | QDM matched to QI Core / FHIR
+
Device.udi.deviceIdentifier
 +
| row2cell3 | DeviceUseStatemtn.device references Device for details of the device used. Device.udi.deviceIdentifier (DI) is a mandatory, fixed portion of a Unique Device Identified (UDI) that identifies the labeler and the specific version or model of a device.
 
|-
 
|-
 
| row2cell1 | id
 
| row2cell1 | id
| row2cell2 | Procedure.id
+
| row2cell2 | DeviceUseStatement.id
| row2cell3 | QDM matched to QI Core / FHIR
+
| row2cell3 | Logical id of this artifact
 
|-
 
|-
 
| row2cell1 | Source
 
| row2cell1 | Source
| row2cell2 | Procedure.performer
+
| row2cell2 | DeviceUseStatement.source
| row2cell3 | QDM matched to QI Core / FHIR
+
| row2cell3 | Who reported this device was being used by the patient.
 
|}
 
|}
 +
 
==Device, Order==
 
==Device, Order==
 
{|border="1" cellpadding="2" cellspacing="0"  
 
{|border="1" cellpadding="2" cellspacing="0"  
Line 56: Line 63:
  
 
| row1cell1 | Device Order
 
| row1cell1 | Device Order
| row1cell2 | ProcedureRequest.intent
+
| row1cell2 | DeviceRequest.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.
+
| row1cell3 | DeviceRequest.intent uses the concepts draft, active, on-hold, revoked, completed, entered-in-error, unkown. "Draft" is most consistent with the DeviceRequest when applied to clinical decision support (CDS) or expectations a provider gives to a patient. "active" or "completed" is consistent with the intent of the QDM Device, Order datatype.
 
|-
 
|-
 
| row2cell1 | Negation Rationale
 
| row2cell1 | Negation Rationale
| row2cell2 | ProcedureRequest.extension (http://hl7.org/fhir/StructureDefinition/procedurerequest-reasonRefused)
+
| row2cell2 | None
| row2cell3 | QDM matched to QI Core / FHIR
+
| row2cell3 | DeviceRequest resource does not include a reason the device request did not occur. QI Core does have a ProcedureRequest.extension (http://hl7.org/fhir/StructureDefinition/procedurerequest-reasonRefused). One could address negation rationale by indicating DeviceRequest.status constrained to values suspended or cancelled and reference DeviceRequest.reasonCode to indicate the reason (i.e., reason for not using the device).
 
|-
 
|-
 
| row2cell1 | Reason
 
| row2cell1 | Reason
| row2cell2 | ProcedureRequest.reasonCode
+
| row2cell2 | DeviceRequest.reasonCode
 
| row2cell3 | QDM matched to QI Core / FHIR
 
| row2cell3 | QDM matched to QI Core / FHIR
 
|-
 
|-
 
| row2cell1 | Author dateTime
 
| row2cell1 | Author dateTime
| row2cell2 | ProcedureRequest.AuthoredOn
+
| row2cell2 | DeviceRequest.AuthoredOn
| row2cell3 | Note - ProcedureRequest.occurrence(x) defines a dateTime when the event should occur - not addressed in QDM
+
| row2cell3 | Note - DeviceRequest.occurrence[x] defines a dateTime when the event should occur - not addressed in QDM<br>
 +
Note: FHIR Provenance generally addresses the author of the message; the identifier/source of the original resource element is defined by the resource. Individual resource element provenance is summarized in the FHIR W5 Report (http://hl7.org/fhir/w5.html).
 
|-
 
|-
 
| row2cell1 | Code
 
| row2cell1 | Code
| row2cell2 | ProcedureRequest.code
+
| row2cell2 | DeviceRequest.code
| row2cell3 | See also, Observation.category
+
| row2cell3 | Device requested
 
|-
 
|-
 
| row2cell1 | id
 
| row2cell1 | id
| row2cell2 | ProcedureRequest.id
+
| row2cell2 | DeviceRequest.id
 
| row2cell3 | QDM matched to QI Core / FHIR
 
| row2cell3 | QDM matched to QI Core / FHIR
 
|-
 
|-
 
| row2cell1 | Source
 
| row2cell1 | Source
| row2cell2 | ProcedureRequest.requester
+
| row2cell2 | DeviceRequest.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
+
| row2cell3 | Who, what is requesting the diagnositics - note also, DeviceRequest.performer to indicate the requested filler of the request.
 
|}
 
|}
 +
 
==Device, Recommended==
 
==Device, Recommended==
 
{|border="1" cellpadding="2" cellspacing="0"  
 
{|border="1" cellpadding="2" cellspacing="0"  
Line 91: Line 100:
  
 
| row1cell1 | Device Recommended
 
| row1cell1 | Device Recommended
| row1cell2 | ProcedureRequest.intent
+
| row1cell2 | DeviceRequest.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).
+
| row1cell3 | DeviceRequest.intent uses the concepts draft, active, on-hold, revoked, copmleted, enetered-in-error, unknown. "draft" is most consistent with the DeviceRequest when applied to clinical decision support (CDS) or expectations a provider gives to a patient. "active" or "completed" is consistent with the intent of the QDM Device, Order datatype.
 
|-
 
|-
 
| row2cell1 | Negation Rationale
 
| row2cell1 | Negation Rationale
| row2cell2 | ProcedureRequest.extension (http://hl7.org/fhir/StructureDefinition/procedurerequest-reasonRefused)
+
| row2cell2 | None
| row2cell3 | QDM matched to QI Core / FHIR
+
| row2cell3 | DeviceRequest resource does not include a reason the device request did not occur. QI Core does have a ProcedureRequest.extension (http://hl7.org/fhir/StructureDefinition/procedurerequest-reasonRefused).  See FHIR Tracker Item [https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=15939 15939].
 
|-
 
|-
 
| row2cell1 | Reason
 
| row2cell1 | Reason
| row2cell2 | ProcedureRequest.reasonCode
+
| row2cell2 | DeviceRequest.reasonCode
 
| row2cell3 | QDM matched to QI Core / FHIR
 
| row2cell3 | QDM matched to QI Core / FHIR
 
|-
 
|-
 
| row2cell1 | Author dateTime
 
| row2cell1 | Author dateTime
| row2cell2 | ProcedureRequest.AuthoredOn
+
| row2cell2 | DeviceRequest.AuthoredOn
| row2cell3 | Note - ProcedureRequest.occurrence(x) defines a dateTime when the event should occur - not addressed in QDM
+
| row2cell3 | Note - DeviceRequest.occurrence[x] defines a dateTime when the event should occur - not addressed in QDM<br>
 +
Note: FHIR Provenance generally addresses the author of the message; the identifier/source of the original resource element is defined by the resource. Individual resource element provenance is summarized in the FHIR W5 Report (http://hl7.org/fhir/w5.html).
 
|-
 
|-
 
| row2cell1 | Code
 
| row2cell1 | Code
| row2cell2 | ProcedureRequest.code
+
| row2cell2 | DeviceRequest.code
| row2cell3 | See also, Observation.category
+
| row2cell3 | Device requested
 
|-
 
|-
 
| row2cell1 | id
 
| row2cell1 | id
| row2cell2 | ProcedureRequest.id
+
| row2cell2 | DeviceRequest.id
 
| row2cell3 | QDM matched to QI Core / FHIR
 
| row2cell3 | QDM matched to QI Core / FHIR
 
|-
 
|-
 
| row2cell1 | Source
 
| row2cell1 | Source
| row2cell2 | ProcedureRequest.requester
+
| row2cell2 | DeviceRequest.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
+
| row2cell3 | Who, what is requesting the diagnositics - note also, DeviceRequest.performer to indicate the requested filler of the request.
 
|}
 
|}

Latest revision as of 04:03, 28 November 2018

Back to Harmonization of Health Quality Information Models Page


This QDM to QI Core Mapping for the QDM Datatype "Device" was reviewed by the CQI WG on April 6, 2018 for QDM version 5.3. The content presented here is based on QDM version 5.4 and removes the QDM 5.3 attribute "anatomical approach site" as there was no existing use or clear use case to retain it.
QDM defines Device as an instrument, apparatus, implement, machine, contrivance, implant, in-vitro reagent, or other similar or related article, including a component part or accessory, intended for use in the diagnosis, cure, mitigation, treatment, or prevention of disease and not dependent on being metabolized to achieve any of its primary intended purposes. QDM provides three contexts for expressing devices: Device, Applied; Device, Order; and Device, Recommended.

  1. Note that the current use of the QDM datatype “Device, Applied” usually references the procedure to “apply” the device (i.e., to use for the patient, to use on the patient’s body, or to implant in the patient’s body). Each of these current uses should address the concept using the QDM datatypes, Intervention, Performed, or Procedure, Performed.
  2. The original intent of the QDM datatype “Device, Applied” was to reference the specific device or type of device of concern to the measure. And that reference might be as detailed a providing a device class as referenced in a Unique Device Identifier (UDI). The FHIR Device resource (http://hl7.org/fhir/device.html) does have a metadata element for UDI (http://hl7.org/fhir/device-definitions.html#Device.udi). All device metadata reference inherent qualities of the device. And timing addresses Device.manufactureDate and Device.expirationDate. Therefore, a direct map to the Device resource may not be sufficient or appropriate for the QDM Device, Applied datatype.
  3. The FHIR Resource DeviceUseStatement (http://hl7.org/fhir/deviceusestatement.html) is a more appropriate resource to map QDM Device, Applied. The DeviceUseStatement has a maturity level of 0, so the mapping will need to be updated as the resource is updated. Note: this mapping will need to be reviewed with the QI Core DeviceUseStatement to assure alignment since the current QI Core content does not seem to address the most recent version of DeviceUseStatement.

Device, Applied

QDM Attribute QI Core Metadata Element Comment
Device Applied DeviceUseStatement A record of a device being used by a patient where the record is the result of a report from the patient or another clinician.
Anatomical Location Site DeviceUseStatement.bodySite Indicates the site on the subject's body where the device was used ( i.e. the target site).
Negation Rationale None A DeviceUseStatement does not address negation directly since there would be no statement if the device were absent. QDM usage is to indicate devices that have not been applied should address negation rationale for the order or the recommendation (i.e., ProcedureRequest.extension (reasonRefused)). One could address negation rationale by indicating DeviceUseStatement.status constrained to values stopped or on-hold and reference DeviceUseStatement.reason to indicate the reason (i.e., reason for not using the device).
Reason DeviceUseStatement.indication Reason or justification for use of the device.
Relevant Period DeviceUseStatement.whenUsed The time period over which the device was used.

Note – the DeviceUseStatement resource also has a metadata element: DeviceUseStatement.timing(x) indicating how often the device was used (may be a period or dateTime).

Author dateTime DeviceUseStatement.recordedOn The time at which the DeviceUseStatement was made/recorded.
Code DeviceUseStatement.device

Device.udi.deviceIdentifier

DeviceUseStatemtn.device references Device for details of the device used. Device.udi.deviceIdentifier (DI) is a mandatory, fixed portion of a Unique Device Identified (UDI) that identifies the labeler and the specific version or model of a device.
id DeviceUseStatement.id Logical id of this artifact
Source DeviceUseStatement.source Who reported this device was being used by the patient.

Device, Order

QDM Attribute QI Core Metadata Element Comment
Device Order DeviceRequest.intent DeviceRequest.intent uses the concepts draft, active, on-hold, revoked, completed, entered-in-error, unkown. "Draft" is most consistent with the DeviceRequest when applied to clinical decision support (CDS) or expectations a provider gives to a patient. "active" or "completed" is consistent with the intent of the QDM Device, Order datatype.
Negation Rationale None DeviceRequest resource does not include a reason the device request did not occur. QI Core does have a ProcedureRequest.extension (http://hl7.org/fhir/StructureDefinition/procedurerequest-reasonRefused). One could address negation rationale by indicating DeviceRequest.status constrained to values suspended or cancelled and reference DeviceRequest.reasonCode to indicate the reason (i.e., reason for not using the device).
Reason DeviceRequest.reasonCode QDM matched to QI Core / FHIR
Author dateTime DeviceRequest.AuthoredOn Note - DeviceRequest.occurrence[x] defines a dateTime when the event should occur - not addressed in QDM

Note: FHIR Provenance generally addresses the author of the message; the identifier/source of the original resource element is defined by the resource. Individual resource element provenance is summarized in the FHIR W5 Report (http://hl7.org/fhir/w5.html).

Code DeviceRequest.code Device requested
id DeviceRequest.id QDM matched to QI Core / FHIR
Source DeviceRequest.requester Who, what is requesting the diagnositics - note also, DeviceRequest.performer to indicate the requested filler of the request.

Device, Recommended

QDM Attribute QI Core Metadata Element Comment
Device Recommended DeviceRequest.intent DeviceRequest.intent uses the concepts draft, active, on-hold, revoked, copmleted, enetered-in-error, unknown. "draft" is most consistent with the DeviceRequest when applied to clinical decision support (CDS) or expectations a provider gives to a patient. "active" or "completed" is consistent with the intent of the QDM Device, Order datatype.
Negation Rationale None DeviceRequest resource does not include a reason the device request did not occur. QI Core does have a ProcedureRequest.extension (http://hl7.org/fhir/StructureDefinition/procedurerequest-reasonRefused). See FHIR Tracker Item 15939.
Reason DeviceRequest.reasonCode QDM matched to QI Core / FHIR
Author dateTime DeviceRequest.AuthoredOn Note - DeviceRequest.occurrence[x] defines a dateTime when the event should occur - not addressed in QDM

Note: FHIR Provenance generally addresses the author of the message; the identifier/source of the original resource element is defined by the resource. Individual resource element provenance is summarized in the FHIR W5 Report (http://hl7.org/fhir/w5.html).

Code DeviceRequest.code Device requested
id DeviceRequest.id QDM matched to QI Core / FHIR
Source DeviceRequest.requester Who, what is requesting the diagnositics - note also, DeviceRequest.performer to indicate the requested filler of the request.