Difference between revisions of "PCD Brief Profile Proposal 2008 DPI WP"

From IHE Wiki
Jump to navigation Jump to search
m (Initial Version)
 
m (Expanded Version)
Line 1: Line 1:
−
__NOTOC__
+
{{TOCright}}
−
 
 
  
 
==1. Proposed Workitem: White Paper - Device Point-of-care Integration (DPI)==
 
==1. Proposed Workitem: White Paper - Device Point-of-care Integration (DPI)==
−
 
 
* Proposal Editor: Todd Cooper
 
* Proposal Editor: Todd Cooper
 
* Editor: ''<Name of candidate Lead Editor for the Profile, if known>''  
 
* Editor: ''<Name of candidate Lead Editor for the Profile, if known>''  
Line 11: Line 9:
  
  
 +
==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>
 +
<time synchronization>
  
−
==2. The Problem==
+
=== Symmetric / Bi-Directional Communication ===
 +
<device is both reporter & consumer>
  
−
''<Summarize the integration problem. What doesn’t work, or what needs to work.>''
+
=== Open Loop Control (local & remote) ===
 +
<reporting of local controls>
 +
<limited parameter configuration - clinician activated>
  
 +
=== Closed Loop Control  ===
 +
<infusion pump example>
 +
<clinician proxied>
  
−
==3. Key Use Case==
+
=== Wireless / Mobile Integration ===
 +
A colonoscopy is ordered for a patient who is currently attached to
 +
<maintain connection>
  
−
''<Describe a short use case scenario from the user perspective.  The use case should demonstrate the integration/workflow problem.>''
+
=== Parallel PoC & Enterprise Integration ===
  
−
''<Feel free to add a second use case scenario demonstrating how it “should” work. Try to indicate the people/systems, the tasks they are doing, the information they need, and hopefully where the information should come from.>''
+
=== Hot-swapping Failed Devices ===
 +
During performance of a <X> procedure, an infusion fails and needs to be replaced...
  
 +
=== Rapid Clinical Context Reconfiguration ===
 +
''[Confirm w/ Steve Merritt]''
 +
<Based on hospital sensus information, it is determined that a number step-down units should be reconfigured for higher acuity purposes...>
  
−
==4. Proposed Topics / Outline==
 
  
−
''<Provide the proposed topics / outline for the white paper>''
+
==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==
 
==5. Discussion==
−
 
+
1. RISK: ...
−
''<Include additional discussion or consider a few details which might be useful for the detailed proposal>''
+
2. IHE Coordination:
−
:''<Why IHE would be a good venue to solve the problem and what you think IHE should do to solve it.>''
+
3. PCD Coordination
−
:''<What might the IHE technical approach be? Existing Actors? New Transactions? Additional Profiles?>''
 
−
:''<What are some of the risks or open issues to be addressed?>''
 
  
  
 
[[Category:PCD]]
 
[[Category:PCD]]

Revision as of 20:15, 10 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 Clinical Context Reconfiguration

[Confirm w/ Steve Merritt] <Based on hospital sensus information, it is determined that a number step-down units should be reconfigured for higher acuity purposes...>


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

Retrieved from "http://wiki.ihe.net/index.php?title=PCD_Brief_Profile_Proposal_2008_DPI_WP&oldid=26278"