This wiki has undergone a migration to Confluence found Here

Difference between revisions of "201609 Device Integration"

From HL7Wiki
Jump to navigation Jump to search
(→‎Expected participants: Updated participants / reorganized)
Line 11: Line 11:
  
 
NOTE:  Subsequent FHIR connectathon tracks will include more advanced scenarios and applications, such as medication administration or CDS utilization of real-time high granularity device acquired information.
 
NOTE:  Subsequent FHIR connectathon tracks will include more advanced scenarios and applications, such as medication administration or CDS utilization of real-time high granularity device acquired information.
 +
 +
Adding the patient-to-device-to-operator association could be supported by a FHIR Encounter instance - needs extensions to support a device as a participant to an encounter.
 +
[[File:Encounter and DevieMetricsObservation.png]]
  
 
==Submitting WG/Project/Implementer Group==
 
==Submitting WG/Project/Implementer Group==

Revision as of 15:39, 22 June 2016


Device Data Integration

The focus for this track is the exchange of information from a simple pulse oximeter to a physiological monitor to an infusion pump. Scenarios and test scripts will ensure that at least 80% of the core data elements for these device-related resources are leveraged. Data exchanged will be consistent (per resource mappings) with the ISO/IEEE 11073 standards for device semantic content. This will include integration of data that is sourced from an IEEE 11073-based Personal Health Device (PHD), as well as, communicated using the HL7 v2-based profiles supported by the IHE Patient Care Device (PCD) group.

For the 2016-09 track, device data will include physiological data ("observations"),both periodic and aperiodic, and device settings. Waveform data may be considered as a stretch goal; however, device alert information will be deferred to a subsequent FHIR connectathon.

NOTE: Subsequent FHIR connectathon tracks will include more advanced scenarios and applications, such as medication administration or CDS utilization of real-time high granularity device acquired information.

Adding the patient-to-device-to-operator association could be supported by a FHIR Encounter instance - needs extensions to support a device as a participant to an encounter. Encounter and DevieMetricsObservation.png

Submitting WG/Project/Implementer Group

"'Health Care Devices (DEV) WG"'

Justification

This track is intended to advance the maturity of device-related FHIR resources (i.e., Device, DeviceComponent and DeviceMetric) to FMM2 (see FHIR Maturity Model). It will test mappings for the ISO/IEEE 11073 information model, as well as the IHE Patient Care Device (PCD) profiles based on HL7 v2. This work will inform the potential development of an implementation guide for device information integration, as well as the possible definition of profiles for specific device modalities (e.g., an LVP Infusion Pump).

Proposed Track Lead

Todd Cooper
E-mail: Todd@TrustedSolutionsFoundry.com
Skype: ToddCooperAFC

Expected participants

The following organizations have indicated an interest in participating in this track:

Devices ...
Draeger (Stefan Schlicting)
Lampry Networks (Brian Reinhold)
Philips (John Rhoads)
EHR / CDS ...
Cognitive Medical & CDS Collaborators
Epic (Chris Courville)

NOTE: Other organizations are actively considering participation:

  • Pump Vendor(s)

Roles

Device Observation Reporter (DOR)

Send device acquired information to a FHIR server using the device-related resources (i.e., [Device], DeviceComponentDeviceMetric, Observation).

NOTE: This is analogous to the IHE PCD Device Enterprise Communication (DEC) profile DOR actor. Typically a device or a device "gateway" system.

Device Information Server (DIS)

Process updates from a DOR and respond to queries from a DOC.

Device Observation Consumer (DOC)

Retrieve and use device-acquired information from the DIS, e.g. for flow-charting or clinical decision support applications.

NOTE: This is analogous to the IHE PCD Device Enterprise Communication (DEC) profile DOC actor. Typically an EHR or similar information system.

Scenarios

Scenarios will leverage previous work, but will replace standardized FHIR interfaces where appropriate and feasible:

  • IHE PCD TF vol 1 / Connectathon Use Cases for DEC:
  • Case DEC-1: Communicate patient identified DEC data to EMR/EHR
  • Case DEC-2: Communicate validated periodic DEC data to EMR/EHR
  • NOTE: Additional use cases address person-device association
  • IHE PCD Showcase Examples
  • <list examples>
  • CDS Collaborative HIMSS'16 Demo
  • See demonstration overview
  • Intent in this track would be to replace the front end with a FHIR-compliant data source (including waveforms)
  • Integrate at HL7 EPS (Event Pub/Sub) Level
  • Can include security "wrappers" at this point too if needed


Devices (anticipated) include:

  1. Physiological Monitor (including waveform capability) - Acute Care
  2. Pulse oximeter (either from a physio monitor or a Personal Health Device (PHD))
  3. Personal Health Device (PHD) - specifically non-acute care settings; mobile / tele-care
  4. Infusion Pump - LVP or PCA for acute care
  5. Gateway - as an IHE PCD DOR or integrating a FHIR server
  6. Application Hosting Device (AHD) - Personal Health Device (PHD) gateway
  7. TBD DOR from the device interface

Specific areas of capability to be targeted include:

  • Periodic reporting (a la PCD DEC) - for example, 5 minute "snapshot" updates
  • Tuned (filtered) periodic reporting - for example, only vital signs parameters
  • Async reporting - for example, spot-check monitor used by a clinician hourly
  • Snapshot Pull - Retrieve last reported values
  • Trended Pull - Retrieve specified set of parameters over the last 24 hours
  • Waveform - Snippet + Streaming
  • Pub/Sub Reporting (may be addressed by one of the above)
  • Person-device association [There are a number scenarios related to this topic]
  • FDA UDI device identification [Need to synchronize with other connectathon tracks?]

Desired journey from "device specializations" (e.g., infusion pump) to FHIR resource profiles:

  1. Nomenclature / terminology in NIST RTMMS =>
  2. Information model / "containment tree") in NIST DIM Editor =>
  3. XML representation (exported from DIM Editor) =>
  4. ADL representation (transformed from XML; harmonized @ CIMI) =>
  5. FHIR Resource profiles & StructureDefinition [Alternatives?] (translated from ADL)

Additional areas of alignment / harmonization (stretch goals!):

  • ISO/IEEE 11073 Semantic Representation harmonized
  • MDIDS aligned (MDPnP / OpenICE / etc.)
  • CIMI aligned (ensure device-sourced data is aligned)
  • NIST tooling leveraged (esp. if target includes an IHE connectathon)

Devices on FHIR Roadmap (near term):

  • 2016-09 FHIR Connectathon - move toward FMM2 on device-related resources + validate approach
  • 2017-01 FHIR Connectathon - add more detailed use scenarios such as medication administration "closed loop" (from Physician to Pharmacy to Clinician to Patient ... and back)
  • This will include IHE PIV and IPEC profile usage
  • Future consideration:
  • Device alarm / alert reporting (per IHE PCD ACM or IEC 60601-1-8 / IEC 80001-2-5
  • Device control (from alarm limit setting to therapeutic control parameters)
  • ...


Scenario 1: <Acute Care Reporting Scenario>

<TBD>

Scenario 2: <PHD Reporting Scenario>

<TBD>

Scenario 3: <CDS Scenario>

<TBD>

Scenario 4: <Patient-Device Assoc. Management + FDA UDI Scenario>

<TBD>

TestScript(s)

TBD - Based on evaluation of what needs to be performed to ensure the requisite 80% + coverage.