View source for PCD Brief Profile Proposal 2008 DPI WP

{{TOCright}}

==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 & 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''

==5. Discussion==
1. RISK:  Need to scope the white paper content so as to ensure that it is an achievable activity.  WP may need to be phased.

2. Need to balance between completed standards / profiles vs. emerging standards that potentially represent schedule risk.


[[Category:PCD]][[Category:PCD DPI]]