Current JIRA Tickets

Main JIRA: 

FHIR-40288 - Getting issue details... STATUS

Additional:

FHIR-38712 - Getting issue details... STATUS

FHIR-38917 - Getting issue details... STATUS

FHIR-39046 - Getting issue details... STATUS

FHIR-39244 - Getting issue details... STATUS

FHIR-39369 - Getting issue details... STATUS

FHIR-39688 - Getting issue details... STATUS

FHIR-40290 - Getting issue details... STATUS

FHIR-40335 - Getting issue details... STATUS

FHIR-40384 - Getting issue details... STATUS

FHIR-40455 - Getting issue details... STATUS

FHIR-40568 - Getting issue details... STATUS

Discussion

IMPORTANT NOTE:  Need to address need, context and ownership of the DeviceMetricObservation Profile.

DRAFT Content

Introduction

[Describe how the various device-related resources work together.] 

<Detailed discussion notes moved to DEV/FHIR Device Module/Discussion Notes>

Current Module Location

FHIR will not address all of the needs within devices – but those that will are interoperability exchanges that would benefit from FHIR are outlined in this section.

Inclusions:

Exclusions:

Device Identification

1. UDI and associated issues
2. Use of .property
3. Kind (DeviceDefinition) and instance (Device) usage, relationships
4. Simple use cases (without DeviceMetric, without DeviceDefinition) and more complex ones
5. Observation, Procedure, DeviceUsage relationships in various use cases

Device-Related FHIR Resources:  The Big Picture

When considering the use of FHIR for the integration of device information and services, many resources may be involved in even the simplest application.  Additionally, given the robust nature of FHIR resources, a single basic capability will have many potential solutions all using valid FHIR resource configurations.  The following diagram captures the core device-related FHIR resources and representative relationships.  

HCP_Module 2023.05.06B.pdf (With Resource Hyperlinks)

Looking in to the details of each of the resources on this diagram, though, will reveal a significant amount of detail that can often lead to confusion as to the high-level purposes they are intended to address.  Only the most comprehensive applications will require integration of all the model components.  Most will require only a subset. To sort this out, the following examples are provided to help understand the key concepts and rationale for their implementation.  

<Wayfinding questions with detail discussion moved to DEV/FHIR Device Module/Navigating FHIR for Devices>

Device Acquisition

1. Supply chain ordering, fulfilling, ServiceRequest, DeviceDispense

Device Association

1. impact and possibilities from separation 

Device Settings

1. John Rhoads Suggest breakdown of subtopics - see references to previous discussions and relevant JIRAs

Device Metrics

1. Roles and Use Cases

Imaging Devices (how do we include)

• Includes device identification
• Any settings?? in or out???
• Exclude outputs for diagnostic reporting

Add use cases that need to be addressed:

1. Representation of a medical device such as heparin and its administration.
2. Link patient to implantable/attached device
3. Retrieve usage history of device used by multiple patients (e.g. ventilator, patient monitor, wheelchair, ...)
4. Representation of a web based application as a source of information (i.e. is the browser instance or the server the source, I expect the server).
5. Devices representing CDS algorithms.
6. Imaging equipment.

Device Settings

• There seems to be a range of opinions on how to associate clinical observations generated by devices with the settings in effect on the device at the time the clinical observation was made. Associating the device settings and clinical observations is important to provide context for the clinical observations, and to provide historical evidence. 
• Some have suggested that the clinical observation should use hasMember relationships to the settings observations (either directly or indirectly through a "settings set" observation). This has the advantage of unambiguously tying the clinical observation to the settings in effect.
• Others have suggested simply recording the settings observations either when they change, or at defined times (daily at noon, at the start of a procedure, etc.) and recording the clinical observations without regard for the settings; the settings in effect for any clinical observation can be determined by finding the most recent setting observations (for each of the device metrics) prior to the clinical observation. This approach doesn't laden the clinical observations with concern over the settings observations; but makes it more difficult to detect a missing/deleted setting.
• There is also some confusion about the difference between device settings (recorded as Observations linked to DeviceMetrics linked to Devices) and device properties, and in general how to record device settings.
• An example or guidance that ties these all together, perhaps starting with a clinical Observation linking to settings Observations, would help provide a common approach to these challenges. 
• Current guidance from Devices WG appears to be to use an Observation with subject= [the Patient], and device=[the Device] (or DeviceMetric) to record a device setting (or measurement) during a procedure.
• If we are recommending that .device be used to identify the device in the case where a patient is involved, how do we identify the device when the patient is not involved (is subject empty)? What is the use case where the device is the subject of the observation (and if so, is device empty)? It would be odd to search for the device in .subject some of the time, and in .device other times (although actually, we already may have to search in the observation or in the referenced DeviceMetric).
• Additional use cases to consider are calibration of the device outside a patient context, and observations about the device ("the stove was hot"), which are neither measurements nor settings of or about the device.
• Are there cases where the device is the focus of the observation?
• Please clarify (and ensure consistency between) the use cases for use of Device in each of the Observation elements.
• (I dislike that there is no single place to look for Observations involving a device. It looks like I'd need to query all of subject, focus, and device, and even then I wouldn't get devices that are only referenced by metric.)

Add a list of examples under each Resource

• Device Definition
  • Add Example
• Device

• DeviceAssociation
  • an implant device assigned to a patient with an open period and body site.
  • a wheelchair device assigned to a patient with a start, and end date in the "future" (i.e. the assignment is ongoing).
  • a tablet assigned to a provider
  • a surgical robot assigned to a patient during the period of an operation, with a practitioner operator during that same period.
  • a blood pressure monitor assigned to a patient during their in-patient stay, with operators of multiple nursing staff
  • a lab device with no patient. and repair staff operating it during calibration.
• DeviceUsage
• DeviceMetric
• Observation
• Data that we are looking for "CONTINUOUS CARDIAC OUTPUT", " ARTERIAL PRESSURE", " MEAN ARTERIAL PRESSURE", " BIS Monitor", " CONTINUOUS CARDIAC INDEX", "ESTIMATED BLOOD LOSS TOTALL", " ANESTHESIA BLOOD PRESSURE", "Peak Inspiratory Pressure Observed", "VENT PEEP", "STOKE VOLUME", "URINE OUTPUT", " SYSTEMIC VASCULAR RESISTANCE INDEX"
• Procedure
• DeviceRequest
• DeviceDispense
• ServiceRequest