201705 Device Integration

Return to September 2017 Proposals

Device Data Integration

The focus for this track is the exchange of information from a variety of healthcare devices, such as a simple pulse oximeter, a physiological monitor or an infusion pump, to other applications and systems such as EHR flowsheets or electronic medication administration records (eMAR). 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 2017-05 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.

Submitting WG/Project/Implementer Group

Health Care Devices (DEV) WG

HL7 OO / UDI Project Team

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)

CDS / EHR / Infrastructure ...

Bernoulli / Nuvon (John Zaleski)

Cognitive Medical & CDS Collaborators

Epic (Chris Courville)

Department of Veterans Affairs - Medical Device Integration Adapter pilot (Ioana Singureanu)

NOTE: Other organizations are actively considering participation:

• Pump Vendor(s)

Roles

Point-of-care Device Manager- FHIR client

This is a new actor intended to track implantable devices, associate a patient to their monitoring devices, or help validate medication administration at the point of care using an infusion pump. This point-of-care Device Manager implements several FHIR resources (as a client) in order to:

1. start and end a monitoring session as a Procedure "in-progress" and updates the procedure at the end of the monitoring session (and set the status to "complete")
2. createa a Device resource corresponding to each device implanted during a surgical procedure and creates Procedure to document it.

NOTE: These interactions represent new capabilities to allow a Device Manager 
  to assign devices (implanted or used for treatment)   to a patient.  
  Currently integrator use an ad-hoc HL7 V2 visit or appointment notification to start and stop a device monitoring session.

Device Observation Reporter (DOR)

Send device acquired information to a FHIR server using the device-related resources (i.e., [Device], DeviceComponent, DeviceMetric, 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

• 2016 HIMSS Interop Showcase Use Case examples are (here)
• IHE PCD Profiles demonstrated included DEC, PIV, IPEC, ACM, MEMDMC, MEMLS
• Device modalities demonstrated included physiologic monitors, spot check monitors, infusion pumps (LVP, syringe, and PCA), surgical anesthesia system, Central Nervous System (CNS) surgical anesthesia monitor, a NICU infant warmer, and EMR systems (EHR for DEC and IPEC and orders for PIV).

• 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
• IHE mACM ver 2.0 for device alert reporting

• Sync'd with the IHE PCD ACM, IEC 60601-1-8 & IEC 80001-2-5
• From an Alert Manager (AM) to an Alert Communicator (AC) that interacts with the individual
• Not supported will be FHIR for reporting alerts directly from a healthcare device

• 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 ... see below]

• NOTE: 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.

• FDA UDI device identification [Need to synchronize with other connectathon tracks?]

• HL7 ICSR (Individual Case Safety Report) could be used in an FDA Reporting Scenario
• Also see Argonaut's IDC/UDI Project

• (from Eric Haas) "As far as the Argonaut work. Our goal was to establish the minimal requirements for meeting the MU 2015 CCDS requirements and hence only the carrier string is mandatory. However for the this track, I think there many use cases where the PI and DI would be present instead of or in addition to it."
• (from Hans B.) Per Eric's quote above: "As part of the use case outside of logistics I would suggest not to use 'instead of', rather address the UDI carrier in HRF plus one, some, or all of the UDI components."

• Also see HL7 OO UDI Project

• Location tracking

• Real-Time Location Services (RTLS) & RFID based [see IHE PCD MEM-LS profile for this]

• Document exchange with device-sourced content

• NOTE: This was proposed by HL7 / IHE Korea
• Use IHE Mobile access to Health Documents (MHD) profile FHIR-based profile
• For example, retrieve a Personal Healthcare Monitoring Report document

• Time Normalization -

• IHE CT is the foundation for all IHE Connectathon testing
• Address how to ensure time normalization / synchronization within a device informatics use context

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 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 and Device-Operator Associations and Management using FHIR Procedure, FHIR Device, and UDI

This scenario uses FHIR Procedure and Device to associate a patient to one or more device(s) and operator/nurse/physician who configured or implanted the device. The device will be identified using the UDI scanned at the point of care along the patient id wristband, and the provider's badge.

• Create a FHIR Procedure specifying the patient, the device or devices involved, and the operator (i.e. nurse, respiratory therapist, etc) or provider who configured the device, validated its configuration and initiated the procedure.

• If the device is implanted, a FHIR Device resource will associate the patient with the implanted device. The Patient Device List will be created by querying the EHR using a Device.search (by patient) operation.

• If the device is used monitor the patient or administer medication the procedure indicates duration, the associated medication order.

Implantable Devices

This scenario relies on scanning the UDI in order to convey information about devices implanted to during a procedure. The Medical Device Adapter (FHIR client) submits to the EHR (FHIR server):

• One Device record per implantable devices
• One Procedure referencing the devices implanted.

QUESTION: Should this be coordinated with the Argonaut Implantable / UDI Project?
ANSWER: Sure, this track will reuse the mandatory data elements specified by Argonaut.

Patient-to-implementable Association using FHIR Device resource and FHIR Procedure

Vital Sign Monitoring Procedure

The Medical Device Records (FHIR client) the following operations on the EHR/Clinical Information System (FHIR server):

• The Device Manager "create" a Procedure with status "in-progress" to associate/link the patient(patient MRN) to the device (UDI) and provider a the point-of-care
  • The Device Manager creates a Procedure when a patient starts to be monitored by a vital signs monitor ** The Procedure will reference a contained Device resource or externally referenced one.
  • The Device sets the Device.udiCarrier to the device UDI.
• The Device Manager updates the Procedure and sets Procedure.performed (Period) and Procedure.status to "complete". This update effectively "unlinks" the patient-device-provider.

Patient-to-device-to-operator Association using FHIR Encounter

Medication Administration BCMA Procedure

The 5+3 rights of of bedside computerized medication adminsitra Reference: See discussion @ www.SickKids.ca Nursing - Medication Administration

5+3 Rights of Medication Administration

TestScript(s)

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