QI-Core Implementation Guide: STU Ballot (v3.3.0 for FHIR 4.0.0)

Quality Improvement Core Framework (v3.3.0: STU 4 Ballot 1). The current version is 3.2.0 based on FHIR R4. See the Directory of published versions

7.8.0 Device

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.

FHIR defines the Device Resource as a type of a manufactured item that is used in the provision of healthcare without being substantially changed through that activity. The device may be a medical or non-medical device. Devices differ from medications because they are not "used up" - they remain active in a patient in an ongoing fashion. However, the specific boundary between medications and devices is defined at the implementation level and this standard does not enforce a boundary with the exception of devices that are implanted in a patient. The Medication resource should not be used to represent implanted devices.

Documented evidence of a device may exist in a clinical record in various ways:

  • A provider may document placement of a device as an intervention or procedure (e.g., the QDM datatypes Intervention, Performed, or Procedure, Performed).
    • QDM Example: Procedure, Performed: Pacemaker insertion.
  • The provider may document presence of the device as a finding, perhaps including the finding on the problem list. QDM Example: Diagnosis: Pacemaker present, or Assessment, Performed: Pacemaker present.
  • A provider may also document the device in a specific device use statement or assessment.
    • Example: QDM Device, Applied: Trans-telephonic monitoring of pacemaker assessment. Note that some current uses of the QDM datatype “Device, Applied” 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 actually reference a procedure to place the device which might more effectively reference the Procedure resource.

Thus, specific actions may reference the Device Resource, for example a Procedure, an Observation, a Condition, a DeviceUseStatement, a DeviceRequest, an AdverseEvent and others.

Given the variation in determining evidence of device usage, a measure developer may need to include multiple queries (or retrieves) to assure capture of all devices present in the measure population.

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.

  1. 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 US-Core Device resource (http://hl7.org/fhir/us/core/StructureDefinition-us-core-device.html) does have metadata elements for:
    1. full UDI carrier, Automatic Identification and Data Capture (AIDC) (http://hl7.org/fhir/us/core/StructureDefinition-us-core-device-definitions.html#Device.udiCarrier.carrierAIDC), and
    2. full UDI carrier as the human readable form (HRF) of the barcode string on the device packaging (http://hl7.org/fhir/us/core/StructureDefinition-us-core-device-definitions.html#Device.udiCarrier.carrierHRF).
  2. The FHIR Resource DeviceUseStatement (http://hl7.org/fhir/deviceusestatement.html) is available to map QDM Device, Applied. This resource has a maturity level of 0, so consideration regarding usage to request data retrieval from clinical software should be considered when using it in measure or clinical decision support (CDS) expressions.

7.8.1 Device, Applied

QDM Context QI-Core R4 Comments
Device Applied DeviceUseStatement
DeviceUseStatement.status Probably constrain to "active"
QDM Attributes
Code DeviceUseStatement.device
Device.udiCarrier.deviceIdentifier
Device.udiCarrier.carrierHRF
Device.udiCarrier.carrierAIDC
Device.type
Device.id
id DeviceUseStatement.id
Anatomical Location Site DeviceUseStatement.bodySite
Reason DeviceUseStatement.reasonCode
Negation Rationale Pending final modeling in QI Core DeviceUseStatementStatus does not include a reference to not-done and there is no reference to notDoneReason
Pending final modeling in QI Core for timing of negation rationale
Relevant dateTime DeviceUseStatement.timing[x] dateTime
Relevant Period DeviceUseStatement.timing[x] Period
Author dateTime DeviceUseStatement.recorded.On
Performer DeviceUseStatement.source DeviceUseStatement.source references who reported the device was being used by the patient. Thus the individual working with the device may be different as may the individual recording information about the device usage.

7.8.2 Device, Order

QDM Context FHIR R4 Comments
Device Request DeviceRequest
DeviceRequest.status Constrain to active, on-hold, completed
Device, Recommended DeviceRequest.intent Constrain to "plan"
Device, Order DeviceRequest.intent Constrain to "order" (include children)
QDM Attributes
Code DeviceRequest.code
id DeviceRequest.id
Reason DeviceRequest.reasonCode
Author dateTime DeviceRequest.authoredOn FHIR allows dateTime or Period for desired time or schedule for use.
Negation Rationale DeviceRequest.doNotPerform ServiceRequest includes a doNotPerform; DeviceRequest does not
DeviceRequest.doNotPerform.reason ServiceRequest includes a reason code, but not a doNotPerformReason
Requester DeviceRequest.performer