Difference between revisions of "PCD Brief Profile Proposal 2008 DPI WP"
Stevemerritt (talk | contribs) |
Stevemerritt (talk | contribs) |
||
Line 51: | Line 51: | ||
=== Rapid Room Reconfiguration === | === Rapid Room Reconfiguration === | ||
− | A high incidence of influenza is straining hospital bed capacity. Beds tpyically reserved for low-acuity care must be quickly converted to high-acuity care. The workflow should accomodate the ability for Patient Care Devices to be quickly aware of their new setting without the need for service personnel intervention. | + | A high incidence of influenza is straining hospital bed capacity. Beds tpyically reserved for low-acuity care must be quickly converted to high-acuity care. The workflow should accomodate the ability for Patient Care Devices to be quickly aware of their new setting and use context without the need for service personnel intervention. |
==4. Proposed Topics & Outline== | ==4. Proposed Topics & Outline== |
Revision as of 08:55, 11 November 2008
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.
[Note: How much clinical information should be included in these use cases?]
Basic PnP Connectivity & Device Reporting
<parameters> <alarms> <waveforms>
Symmetric / Bi-Directional Communication
<device is both reporter & consumer>
Open Loop Control (local & remote)
<reporting of local controls> <limited parameter configuration - clinician activated>
Closed Loop Control
<infusion pump example> <clinician proxied>
Wireless / Mobile Integration
A colonoscopy is ordered for a patient who is currently attached to <maintain connection>
Parallel PoC & Enterprise Integration
Hot-swapping Failed Devices
During performance of a <X> procedure, an infusion fails and needs to be replaced...
Rapid Room Reconfiguration
A high incidence of influenza is straining hospital bed capacity. Beds tpyically reserved for low-acuity care must be quickly converted to high-acuity care. The workflow should accomodate the ability for Patient Care Devices to be quickly 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
- Overview
5. Discussion
1. RISK: ... 2. IHE Coordination: 3. PCD Coordination