PCD Brief Profile Proposal 2008 DPI WP

1. Proposed Workitem: White Paper - Device Point-of-care Integration (DPI)

• Proposal Editor: Todd Cooper
• Editor: <Name of candidate Lead Editor for the Profile, if known>
• Date: N/A (Wiki keeps history)
• Version: N/A (Wiki keeps history)
• Domain: PCD

2. The Problem

Though the IHE PCD scope has included both point-of-care and enterprise integration of medical devices and medical device information, the group's primary focus up to this point has been on the enterprise and end-to-end semantic interoperability. When discussing integration of medical devices around the point-of-care as the next major area of PCD focus, many questions arise ranging from what exactly is meant by "point-of- care" to the use cases, potential topologies and technologies that should be addressed by this profile. Indeed, given the breadth of the problem space, it has become clear that multiple profiles will be required to address the proposed subject areas.

This Device Point-of-care Integration (DPI) white paper is intended to provide an overview of the use cases and integration problems to be addressed by the IHE PCD's future profile development activities. It will include an exemplary set of use cases, care context topological models, integration problem and technology specific discussions, and a road map of PCD profiles and white papers that should be developed to support DPI.

In previous development cycles (through 2007.06), the PCD was developing a "Plug-and-Play" (PnP) profile; however, in discussions for this Cycle 4 activity, it was determined that PnP was too narrow and should be extended to DPI, which also balances well with Device to Enterprise Communication (DEC). Thus, the DPI work is intended to include and go beyond previous PCD PnP profile development.

3. Key Use Cases

The potential use cases to be considered within the scope of DPI are numerous; however, the examples listed below are exemplary (not exhaustive) of those to be considered as part of the white paper and the DPI profile set. When reviewing the proposed topics & outline below, many other use cases might be suggested.

Additionally, the IHE PCD DPI WG is coordinating with the "ICE" (Integrated Clinical Environment) team (ASTM F29.21) to analyze how its cases and conceptual model might be supported by DPI profiles and existing medical device informatics standards.

Basic PnP Connectivity & Device Reporting

A patient is admitted to a bed, and requires physiological monitoring and a number of I.V. administered medications. The patient is also on mechanical ventilation. All the equipment is connected to a local network, uniquely associated with the patient and care context, time and date synchronized, and configured to report comprehensive device information to both local and remote systems (e.g., for clinician review). Collected information includes:

• Operational configuration parameters (or local controls)
• Operational status / monitored parameters (including physiologic measurements)
• Alarm status information
• Waveform streams

Symmetric / Bi-Directional Communication

An infusion pump is delivering a medication that affects the patient's respiration. When the pump connects to the local network, it issues a request for "monitored respiration rate". Connected systems that provide this information respond to the infusion pump, which then selects one or more of the data sources and issues a request to periodically receive the information. Each time the respiration rate information is received, the pump compares it to the clinician-set limit, and if the threshold is exceeded, an alarm condition is indicated by the pump to notify the clinician of the patient's condition.

Open Loop Control

A device is connected to a local network and is reporting its operational settings and alarm conditions. A clinician remotely monitoring the device determines that one of the alarm limit settings is too narrow and should be adjusted. The clinician remotely adjusts the alarm limit setting, which is then sent to the device, verified and updated, and then communicated back to the clinician for remote confirmation.

Closed Loop Control

The unique attribute of a closed-loop control system that classifies the system as a Physiologic Closed-Loop Control System (PCLCS), is the measurement of a physiological variable to adjust the delivery of energy or substance (via an actuator) to control or maintain the physiological variable to a target. In this sense, the clinician that would be present in an open loop system, is "proxied" by one of the participating devices.

Some examples of these systems include: blood glucose control, blood pressure control, muscle relaxant infusion control, and heart rate control.

Wireless / Mobile Integration

This use case covers those applications where a patient is in a hospital bed with multiple connected devices all providing information to a data acquisition system, who is then transferred to a different part of the healthcare facility (e.g., radiology), perhaps transmitting wirelessly during transport, and reconnected at a later time. In other words, it examines the wired-to-wireless transition as well as data acquisition while a patient is mobile.

Parallel PoC & Enterprise Integration

An infusion pump coordinates its operation with a remote server. It also participates in a local network with other devices connected to the same patient. Once the pump has established its local network connection, it requests a portal that it can use for communicating periodically with its remote server system.

Hot-swapping Failed Devices

During performance of a procedure, a ventilator fails and needs to be replaced. Since its local operational control settings have been reported and recorded by another system, when the new ventilator is brought in and connected to the patient, the failed device's settings are uploaded to the replacement device, which the clinician then confirms and starts device operation.

Rapid Room Reconfiguration

A high incidence of influenza is straining hospital bed capacity. Beds typically reserved for low-acuity care must be quickly converted to high-acuity care. The workflow should accommodate the ability for Patient Care Devices to be dynamically aware of their new setting and use context without the need for service personnel intervention.

4. Proposed Topics & Outline

In DPI Working Group discussions, the following topics and outline have been suggested (order is highly subject to change):

Overview & Scope

Introduction

Scope

Issue Log

Open Issues

Closed Issues

Future development

Point-of-Care

• Patient Centric
• "First Link"

Device Identification & Pairing

Unique Device Identification

Device & Service Directories

Patient-Device Relationships

Clinician-Device Relationships

Pairing Lifecycle

Use Cases

"ICE" Coordination

Plug-and-Play Connectivity

Pre- vs. Dynamic Configuration

PnP State Model

Device Control

Overview

Open Loop

Closed Loop

Automatic Closed Loop

Alarm Reporting & Management

Clinical Workflow Support

DPI & Other IHE Profiles

PCD Profiles

ITI Profiles

Clinical Speciality Profiles

Cardiology, Laboratory, ...

DPI-External Application Integration

Quality of Service Management

Risk Management

• Incl. application of IEC 80001 & ISO14971 to DPI-based systems.
• Incl. reference to Regulatory Considerations White Paper

Networking Architectures

Discovery & Directories

Client & Server

Manager & Agent

Master & Slave

Peer-to-Peer

Hybrid Architectures

* Fault tolerance considerations - e.g., strategy for when the master faults.

* How does the system operate with one or more systems in faults (e.g., shutting off a "chatter box")

Virtual LANs

Wireless Connectivity

Mobile PoC

Conformance

• Note: Devices do not need to support complete functionality.
• What are the requirements on a DPI Actor re. the information and services that need to be supported? How much of this is pre-coordinated? ::* What is dynamically coordinated (e.g., via a publish / subscribe mechanism, scanner configuration, filter configuration, etc.)
• Semantic content must conform to IHE PCD TF Vol 3.

System Testing

Conformance Testing

Interoperability Testing

PCD Profile Roadmap

Overview

• Coordination with MEM profiling
• Advance Prototyping Activities

Discovery & Association

• Discussion:

- Address Pre- & Dynamic coordination

- Discovery mechanism in a LAN arch.

- CCOM (11073-20103)

• Transport: could be serial, LAN, ... but will be "pre-coordinated"
• LAN

- Patient (local) LAN ... PAN

- Care Unit LAN (multi-patient)

- Is this network topology or Transport independent?

• NOTE: First pass could be point-to-point Ethernet connection

Data Reporting

Device ID Binding

• Binding equipment ID w/ clinical topology, that includes patient & PoC identities
• Note: Need to address Mobile PoC's
• Note: Address non-admitted patient associations
• Note: Patient binding is only needed if PoC data is going to be exported for inclusion in a multi-patient enterprise application

Bidirectional Information Exchange

• Peer-to-peer vs. Manager/proxy or brokered

External Control

Open Loop Control

Closed Loop Control

Hybrid Control

Safety Interlocks

Archival

Full Disclosure Archive

Forensic Data Logger

Application Server Platform

5. Discussion

1. RISK: ... 2. IHE Coordination: 3. PCD Coordination