DeviceUsage

Introduction

Scope and Usage

This resource records the use of a healthcare-related device by the patient, a provider or a related person, and is primarily used for patient-reported or second-hand reporting. The resource can be used to note the use of an assistive device such as a wheelchair or hearing aid, a contraceptive, or an implanted device such as a pacemaker. It may also be used, for example, to capture an approximate assertion that the patient used the device over a six month period.

This resource is an event resource from a FHIR workflow perspective - see Workflow.

Boundaries and Relationships

There are several resources that can be used to represent device use events or requests. The following Resources should be used in the following manner:

DeviceRequest - records a request to use the device.

Procedure- records the implant or explant event of a device in a patient.

DeviceAssociation - If precise information (e.g., from the assigning system) about the association of the device with the patient is known, DeviceAssociation is the typical mechanism to record the information.

Notes

Notes to reviewers:

At this time, the code bindings are placeholders to be fleshed out upon further review by the community.

StructureDefinition

Elements (Simplified)

• DeviceUsage [0..*]: - Record of use of a device
• DeviceUsage.identifier [0..*]: Identifier External identifier for this record
• DeviceUsage.basedOn [0..*]: Reference(ServiceRequest) Fulfills plan, proposal or order
• DeviceUsage.partOf [0..*]: Reference(DeviceUsage) Part of referenced device usage
• DeviceUsage.status [1..1]: code required:deviceusage-status preparation | active | completed | not-done | entered-in-error +
• DeviceUsage.category [0..*]: CodeableConcept The category of the statement - classifying how the statement is made
• DeviceUsage.subject [1..1]: [Reference(Patient](/Reference(Patient), Group)) Individuals(s) who used the device
• DeviceUsage.derivedFrom [0..*]: [Reference(ServiceRequest](/Reference(ServiceRequest), Procedure, Claim, Observation, QuestionnaireResponse, DocumentReference)) Supporting information
• DeviceUsage.context [0..1]: [Reference(Encounter](/Reference(Encounter), EpisodeOfCare)) The encounter or episode of care that establishes the context for this device use statement
• DeviceUsage.timing[x] [0..1]: Timing, Period, dateTime How often the device was used
• DeviceUsage.dateAsserted [0..1]: dateTime When the statement was made (and recorded)
• DeviceUsage.usageStatus [0..1]: CodeableConcept required:deviceusage-status The status of the device usage, for example always, sometimes, never. This is not the same as the status of the statement
• DeviceUsage.usageReason [0..*]: CodeableConcept The reason for asserting the usage status - for example forgot, lost, stolen, broken
• DeviceUsage.adherence [0..1]: BackboneElement How device is being used
• DeviceUsage.adherence.code [1..1]: CodeableConcept example:deviceusage-adherence-code always | never | sometimes
• DeviceUsage.adherence.reason [1..*]: CodeableConcept example:deviceusage-adherence-reason lost | stolen | prescribed | broken | burned | forgot
• DeviceUsage.informationSource [0..1]: [Reference(Patient](/Reference(Patient), Practitioner, PractitionerRole, RelatedPerson, Organization, Group)) Who made the statement
• DeviceUsage.device [1..1]: CodeableReference Code or Reference to device used
• DeviceUsage.reason [0..*]: CodeableReference Why device was used
• DeviceUsage.bodyStructure [0..1]: CodeableReference example:body-site Target body structure
• DeviceUsage.note [0..*]: Annotation Addition details (comments, instructions)

Mappings

• DeviceUsage Mappings — 40 mapping entries

Resource Packs

list-DeviceUsage-packs.xml

<?xml version="1.0" encoding="UTF-8"?>

<List xmlns="http://hl7.org/fhir" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://hl7.org/fhir ../../publish/List.xsd">
  <id value="DeviceUsage-packs"/>
  <status value="current"/>
  <mode value="working"/>
</List>

Search Parameters

• device — token — Search by device — DeviceUsage.device.concept
• identifier — token — Search by identifier — DeviceUsage.identifier
• patient — reference — Search by patient who used the device — DeviceUsage.subject.where(resolve() is Patient)
• subject — reference — The individual(s) who used the device — DeviceUsage.subject
• status — token — The status of the device usage — DeviceUsage.status
• reference — reference — Target body structure (reference) — DeviceUsage.bodyStructure.reference
• body-structure-code — token — Code for target body structure — DeviceUsage.bodyStructure.concept

Full Search Parameters

Examples

• deviceusage-example — deviceusage-example
• deviceusage-examples-header — deviceusage-examples-header
• example — deviceusage-example — The provision of a wheelchair to a patient

Full Examples

Mapping Exceptions

deviceusage-event-mapping-exceptions.xml

Divergent Elements

• Event.identifier → DeviceUsage.identifier
  • shortUnmatched | reason=Unknown | pattern=Business identifier for device usage | resource=External identifier for this record
  • definitionUnmatched | reason=Unknown | pattern=Business identifiers assigned to this device usage by the performer and/or other systems. These identifiers remain constant as the resource is updated and propagates from server to server. | resource=An external identifier for this statement such as an IRI.
  • commentsUnmatched | reason=Unknown | pattern=Note: This is a business identifier, not a resource identifier (see discussion). It is best practice for the identifier to only appear on a single resource instance, however business practices may occasionally dictate that multiple resource instances with the same identifier can exist - possibly even with different resource types. For example, multiple Patient and a Person resource instance might share the same social insurance number.
  • requirementsUnmatched | reason=Unknown | pattern=Allows identification of the device usage as it is known by various participating systems and in a way that remains consistent across servers.
• Event.basedOn → DeviceUsage.basedOn
  • missingTypes | reason=Unknown | pattern=Reference(Request)
  • extraTypes | reason=Unknown
  • definitionUnmatched | reason=Unknown | pattern=A plan, proposal or order that is fulfilled in whole or in part by this device usage. | resource=A plan, proposal or order that is fulfilled in whole or in part by this DeviceUsage.
  • requirementsUnmatched | reason=Unknown | pattern=Allows tracing of authorization for the device usage and tracking whether proposals/recommendations were acted upon. | resource=Allows tracing of authorization for the DeviceUsage and tracking whether proposals/recommendations were acted upon.
• Event.partOf → DeviceUsage.partOf
  • missingTypes | reason=Unknown | pattern=Reference(Event)
  • extraTypes | reason=Unknown
  • shortUnmatched | reason=Unknown | pattern=Part of referenced event | resource=Part of referenced device usage
  • definitionUnmatched | reason=Unknown | pattern=A larger event of which this particular device usage is a component or step. | resource=A larger event of which this particular device usage is one part the usage.
  • commentsUnmatched | reason=Unknown | pattern=Not to be used to link an device usage to an Encounter - use 'context' for that.
• Event.status → DeviceUsage.status
  • shortUnmatched | reason=Unknown | pattern=preparation | in-progress | not-done | suspended | aborted | completed | entered-in-error | unknown | resource=preparation | active | completed | not-done | entered-in-error +
  • commentsUnmatched | reason=Unknown | pattern=A nominal state-transition diagram can be found in the (Event pattern documentation

Unknown does not represent "other" - one of the defined statuses must apply. Unknown is used when the authoring system is not sure what the current status is. | resource=DeviceUsage is a statement at a point in time. The status is only representative at the point when it was asserted. The value set for contains codes that assert the status of the use by the patient (for example, stopped or on hold) as well as codes that assert the status of the resource itself (for example, entered in error).

This element is labeled as a modifier because the status contains the codes that mark the statement as not currently valid. When the status is 'not-done', the event-statusReason extension should be used to indicate why the DeviceUsage was not done.

• Event.category → DeviceUsage.category
  • summary | reason=Unknown | pattern=true
  • shortUnmatched | reason=Unknown | pattern=High level categorization of device usage | resource=The category of the statement - classifying how the statement is made
  • definitionUnmatched | reason=Unknown | pattern=Partitions the device usage into one or more categories that can be used to filter searching, to govern access control and/or to guide system behavior. | resource=This attribute indicates a category for the statement - The device statement may be made in an inpatient or outpatient settting (inpatient | outpatient | community | patientspecified).
  • commentsUnmatched | reason=Unknown | pattern=Categorization might be done automatically (inferred by code) or manually by user assertion. The absence of a category may limit the ability to determine when the element should be handled, so strong consideration should be given to how systems will be able to determine category values for legacy data and how data that cannot be categorized will be handled. As well, some categories might not be mutually exclusive, so systems should prepare for multiple declared categories - even within a single category 'axis'. In general, there should not be a 'strong' binding ('required' or 'extensible') on the category element overall. Instead, the element can be sliced and bindings can be asserted that apply to particular repetitions.
• Event.product → DeviceUsage.device
  • shortUnmatched | reason=Unknown | pattern=Product used/provided | resource=Code or Reference to device used
  • definitionUnmatched | reason=Unknown | pattern=Indicates the product supplied or manipulated by this device usage. | resource=Code or Reference to device used.
• Event.subject → DeviceUsage.subject
  • shortUnmatched | reason=Unknown | pattern=Individual service was done for/to | resource=Individuals(s) who used the device
  • definitionUnmatched | reason=Unknown | pattern=The individual or set of individuals the action is being or was performed on. | resource=The individual(s) who used the device.
  • requirementsUnmatched | reason=Unknown | pattern=Links the device usage to the Patient context. May also affect access control.
• Event.encounter → DeviceUsage.context
  • extraTypes | reason=Unknown
  • shortUnmatched | reason=Unknown | pattern=Encounter the device usage is part of | resource=The encounter or episode of care that establishes the context for this device use statement
  • definitionUnmatched | reason=Unknown | pattern=The Encounter during which this device usage was created or to which the creation of this record is tightly associated. | resource=The encounter or episode of care that establishes the context for this device use statement.
  • commentsUnmatched | reason=Unknown | pattern=This will typically be the encounter the device usage was created during, but some device usages may be initiated prior to or after the official completion of an encounter but still be tied to the context of the encounter (e.g. pre-admission lab tests).
  • requirementsUnmatched | reason=Unknown | pattern=Links the device usage to the Encounter context. May also affect access control.
• Event.occurrence[x] → DeviceUsage.timing[x]
  • shortUnmatched | reason=Unknown | pattern=When device usage occurred/is occurring | resource=How often the device was used
  • definitionUnmatched | reason=Unknown | pattern=The date, period or timing when the device usage did occur or is occurring. | resource=How often the device was used.
  • commentsUnmatched | reason=Unknown | pattern=This indicates when the activity actually occurred or is occurring, not when it was asked/requested/ordered to occur. For the latter, look at the occurence element of the Request this {{event}} is "basedOn". The status code allows differentiation of whether the timing reflects a historic event or an ongoing event. Ongoing events should not include an upper bound in the Period or Timing.bounds. .
• Event.recorded → DeviceUsage.dateAsserted
  • shortUnmatched | reason=Unknown | pattern=When device usage was first captured in the subject's record | resource=When the statement was made (and recorded)
  • definitionUnmatched | reason=Unknown | pattern=The date the occurrence of the device usage was first captured in the record - potentially significantly after the occurrence of the event. | resource=The time at which the statement was recorded by informationSource.
  • commentsUnmatched | reason=Unknown | pattern=The recorded date indicates the date when the data was placed in the record maintained by the performing practitioner, or the date of disclosure by Patient or RelatedPerson, not a date of record transfer. If the record is transferred from one system to another (in paper or electronic form), it does not create a distinct recorded date. In most cases, performing practitioners will record on the same date the event occurred, but sometimes there are delays. If information is being relayed second-hand, the recorded date indicates when the system is first made aware of the data.

The recorded date is NOT intended to be the same as a database.createdTimestamp - that would be captured as part of resource.meta or possibly Provenance.

It is possible for the same event to be disclosed to different systems at different times. E.g. a patient might tell two different clinicians about a historical event at different visits. If the disclosure is from the patient rather than record transfer from clinician A to B, the recorded date would be the date each respective clinician put the data in their record. If the data flowed from clinician A to B, the recorded date would remain the recorded date as initially set in clinician A's system.

• Event.reported[x] → DeviceUsage.informationSource
  • missingTypes | reason=Unknown | pattern=boolean
  • extraTypes | reason=Unknown
  • shortUnmatched | reason=Unknown | pattern=Reported rather than primary record | resource=Who made the statement
  • definitionUnmatched | reason=Unknown | pattern=Indicates if this record was captured as a secondary 'reported' record rather than as an original primary source-of-truth record. It may also indicate the source of the report. | resource=Who reported the device was being used by the patient.
  • requirementsUnmatched | reason=Unknown | pattern=Reported data may have different rules on editing and may be visually distinguished from primary data.
• Event.reason → DeviceUsage.reason
  • shortUnmatched | reason=Unknown | pattern=Why was device usage performed? | resource=Why device was used
  • definitionUnmatched | reason=Unknown | pattern=Describes why the device usage occurred in coded or textual form or Indicates another resource whose existence justifies this device usage. | resource=Reason or justification for the use of the device. A coded concept, or another resource whose existence justifies this DeviceUsage.
  • commentsUnmatched | reason=Unknown | pattern=Textual reasons can be captured using reasonCode.text. | resource=When the status is not done, the reason code indicates why it was not done.
• Event.note → DeviceUsage.bodyStructure
  • missingTypes | reason=Unknown | pattern=Annotation
  • extraTypes | reason=Unknown
  • summary | reason=Unknown | pattern=false
  • shortUnmatched | reason=Unknown | pattern=Comments made about the event | resource=Target body structure
  • definitionUnmatched | reason=Unknown | pattern=Comments made about the device usage by the performer, subject or other participants. | resource=Indicates the anatomic location on the subject's body where the device was used (i.e. the target).
• Event.note → DeviceUsage.note
  • shortUnmatched | reason=Unknown | pattern=Comments made about the event | resource=Addition details (comments, instructions)
  • definitionUnmatched | reason=Unknown | pattern=Comments made about the device usage by the performer, subject or other participants. | resource=Details about the device statement that were not represented at all or sufficiently in one of the attributes provided in a class. These may include for example a comment, an instruction, or a note associated with the statement.

Unmapped Elements

• Event.relevantHistory — Unknown
• Event.code — Unknown
• Event.location — Unknown
• Event.performer.actor — Unknown
• Event.performer.function — Unknown
• Event.performer — Unknown

deviceusage-fivews-mapping-exceptions.xml

Unmapped Elements

• FiveWs.what — Unknown
• FiveWs.author — Unknown
• FiveWs.cause — Unknown
• FiveWs.version — Unknown
• FiveWs.witness — Unknown
• FiveWs.class — Unknown
• FiveWs.where — Unknown
• FiveWs.context — Unknown
• FiveWs.init — Unknown
• FiveWs.source — Unknown
• FiveWs.who — Unknown
• FiveWs.grade — Unknown
• FiveWs.planned — Unknown