PCD Detailed Profile Proposal 2009 DPI WP

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

• Proposal Editor: Todd Cooper
• Editor: Todd Cooper
• Date: N/A (Wiki keeps history)
• Version: N/A (Wiki keeps history)
• Domain: PCD

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.

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.

Proposed Topics & Outline

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

NOTE: The DPI TG determined that the following outline is appropriate but ambitious for a Phase I activity. Some of the items below may be maintained as "place holder" sections for the initial phase or two of the white paper. Phase I core content may include:

- DnA with a pre-coordinated Ethernet-based point-to-point transport

- Basic Device Data Reporting

- Symmetric Communication (bi-directional)

Overview & Scope

Introduction

Scope

Issue Log

Open Issues

Closed Issues

Future development

Point-of-Care

• Patient Centric
• "First Link"

Device Identification & Association

Unique Device Identification

Device & Service Directories

Patient-Device Relationships

Clinician-Device Relationships

Association Lifecycle

Use Cases

• Detail the use cases that establish DPI scope and requirements
• Note: This may be in an Annex or distributed through the various WP sections.

Business Value Propositions

• Identify the VPs related to DPI
• VP's are general and then per key stakeholder (manufacturer, integrator, end user, regulator, ...)

"ICE" Coordination

• Overview of ICE (incl. conceptual model)
• Identification of DPI components that are needed to support ICE complian networks

Plug-and-Play Connectivity

General PnP State Model

Pre- vs. Dynamic Configuration

Device Control

Overview

Open Loop

Closed Loop

Automatic Closed Loop

Alarm Reporting & Management

• Addition of DPI components in support of the ACM profile
• PoC alarm management (coordinated annunciation/display, prioritization, etc.)
• "smart alarm" (ICE) support

Clinical Workflow Support

• ...

DPI & Other IHE Profiles

PCD Profiles

ITI Profiles

Clinical Speciality Profiles

Cardiology, Laboratory, ...

DPI-External Application Integration

• Use of DPI-connection for other applications, such as device PM or configuration
• Support for an "external portal" function for devices to establish (potentially concurrent) non-DPI connections, either inttermittent or persistent.

Quality of Service Management

Risk Management

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

Wireless Connectivity

Mobile PoC

Networking Architectures

Overview

• Applicable Architectures

- IHE Architectures (incl. PCD)

- Other industry architectures

• Standards Assessment

DPI Network Technical Framework

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

Profile Development Phasing

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

Technical Approach

Existing transactions

It is anticipated that the DPI white paper will indicate how the

New transactions (standards used)

<Describe possible new transactions (indicating what standards would likely be used for each. Transaction diagrams are very helpful here. Feel free to go into as much detail as seems useful.>

Impact on existing integration profiles

The following profiles may be impacted by the DPI WP and profile supplements:

• ACM: Transactions and content at the device "first link" level may be added to support the alarm communication management profiles.

• DEC(PIB): A method for capturing patient and other ID's may be indicated by the DPI WP. This would provide information that is needed by the DEC Patient Identity Binding option.

• DEC(SPD): DPI may provide constructs to support the configuration of information provided by one or more devices to support enterprise application needs (esp. based on analyzed clinical workflow support).

• PIV: The DPI WP will include use cases that capture the use of medication pumps that would actually be programmed directly as a result of PIV transactions.

• RTM: The DPI WP will indicate how abstrat device semantic content, as specified in the Rosetta tables, is utilized, transacted and managed at the point-of-care.

New integration profiles needed

The DPI WP will provide a road map for new profiles to be developed, including those currently being proposed (separately), namely DPI-DnA, DPI-DR, and DPI-SYM.

Breakdown of tasks that need to be accomplished

The following tasks have been identified:

• Develop editorial / discussion work plan for Phase I
• Schedule WebEx discussion Sessions + assignments per the work plan
• Analyze HITSP CDC requirements as they relate to DPI scope; ensure they are addressed in the WP
• Integrate (as appropriate) the analysis results of the ICE-PAC JWG, as it relates to the DPI scope
• Draft the Phase I WP
• Publish Public Comment Phase I WP by 2009.04.01
• Develop PowerPoint presentatio of this draft for use at HIMSS '09 and other promotional opportunities
• Resolve public comments at the IHE PCD spring F2F @ NIST the week of 2009.05.04.
• Publish final WP by 2009.05.15
• Assess need, content and schedule for Phase II paper by the fall 2009 IHE PCD meetings.

Support & Resources

The following organizations have either actively participated or indicated interest in DPI profile development activities:

• Baystate Health
• Breakthrough Solutions Foundry
• Cardinal/VIASYS
• Draeger
• FDA
• Hospira
• Improvement Technologies
• Kaiser Permanente
• LiveData
• NIST
• Philips Healthcare
• Respironics (Philips)

It is anticipated that these companies will support at some level the development of the white paper.

Risks

The following risks have been identified for development of the DPI white paper (not an exhaustive list!):

• Breadth of scope (especially for the first Phase development) expands in breadth and depth beyond what can be supported by the available resources and schedule.

• The Phase I content does not support a viable set of functions that can be quickly prototyped or that reflect a business model behind which companies can motivate participation. Note: this could be the result of scope/content that is too broad, too narrow, or simply off target.

• Gaps in core standards, requiring postponment of white paper (and especially supplement profile) development.

• Push back from other groups that may be moving toward the DPI use case space.

• Requirements arising from the HITSP Common Device Connectivity (CDC) use case may drive DPI-related development in a different direction than currently envisioned.

Open Issues

Besides the activities and risks identified elsewhere in this proposal, the following issues also need to be resolved:

• Balancing between WP development and other IHE PCD development activities, especially when they are related to DPI profiles and thus need to be coordinated, as well as standards development activities that may require some of the same resources that are currently committed for DPI development or that need to be addressed before DPI required components may be completed.

Tech Cmte Evaluation

Effort Evaluation (as a % of Tech Cmte Bandwidth):

• One 2-hour WebEx session per week
• Primary focus on Phase I content (related DPI profiles are of secondary priority)
• Target Phase I completion & publication for public comment by HIMSS '09, 2009.04.01.

Responses to Issues:

See italics in Risk and Open Issue sections

Candidate Editor:

Todd Cooper, Breakthrough Solutions Foundry, IHE PCD TC Co-Chair