Difference between revisions of "PCD DPI 2008-10-17 WebEx"

From IHE Wiki
Jump to navigation Jump to search
m (→‎Discussion: Update)
m (→‎Discussion: Updated)
Line 97: Line 97:
 
'''Decisions/Issues:'''
 
'''Decisions/Issues:'''
 
:* Include wireless use case & related architecture discussion on Thursday afternoon @ F2F
 
:* Include wireless use case & related architecture discussion on Thursday afternoon @ F2F
 +
:* Wireless DPI connections will not be addressed in the first prototyping cycle.
  
 
'''Action(s):'''
 
'''Action(s):'''
 
|-
 
|-
 
| align="center" | 5
 
| align="center" | 5
| '''xyz''' <br>- Todd
+
| '''Enterprise Application vs. Deployment Architectures''' <br>- Group
 
| '''Status/Discussion:'''
 
| '''Status/Discussion:'''
:* ...
+
:* The discussion centered around the question, '''''What does "enterprise" mean?'''''
 +
:* The [ftp://ftp.ihe.net/Patient_Care_Devices//Patient_Care_Devices/Showcases/HIMSS2009April/Handouts/IHE_PCD_Showcase_Block_Diagram_2009_Latest.ppt IHE 2009 Showcase Systems diagram] was used for discussion purposes.
 +
:* PIV/BCMA can be
 +
::: Enterprise functions
 +
:: or
 +
::: VeriScan is a stand-alone system
 +
::* '''''What does DPI mean?'''''
 +
::: DPI "PoC":
 +
:::: Must be patient connected
 +
:::: Focused on FIRST communication hop...
 +
::: Enterprise
 +
:::: "full blown hospital information system"
 +
::: vs.
 +
:::: Speciality systems (e.g., infusion pump management systems / gateways)
 +
::::: NOTE: May have a single function BUT do so across all the enterprise
 +
 
 +
::* Question:  Where would Lab systems going in this paradigm?
  
 
'''Decisions/Issues:'''
 
'''Decisions/Issues:'''
 +
:* In the F2F, need to see if we can come up with a model that will clearly communicate the differences between these perspectives and the PCD TF (as well as other IHE TFs).
  
 
'''Action(s):'''
 
'''Action(s):'''
Enterprise Application vs. Deployment architectures
 
 
<used Ken's latest diagram to beg the question...>
 
 
        BCMA can be
 
                Enterprise functions or
 
                VeriScan is a stand-alone system
 
        What does "enterprise" mean?
 
        What does DPI mean?
 
                DPI "PoC"
 
                          Must be patient connected
 
                          DPI is focused on FIRST communication hop...
 
        Enterprise
 
                "full blown hospital information system"
 
        vs.
 
                Speciality systems (e.g., infusion pump management systems / gateways)
 
                          May have a single function BUT do so across all the enterprise
 
 
 
|-
 
|-
 
| align="center" | 6
 
| align="center" | 6
| '''xyz''' <br>- Todd
+
| '''Multiple Concurrent Connection Support''' <br>- Group
 
| '''Status/Discussion:'''
 
| '''Status/Discussion:'''
:* ...
+
::* Multiple concurrent connections must be supported, since some systems such as infusion pumps need to have both DPI connections as well as connections to their remote servers.
 +
::* DPI connections are typically "persistent"; whereas, the non-DPI connections may be either persistent or more typically intermittent.
 +
::* This implies that DPI must provide a method for opening a "portal" to non-DPI systems.
 +
::* Additionally, '''''there may be multiple paths for a device's data to the "enterprise"'''''.  For example, a general DPI gateway vs. published from a specialized (e.g., infusion pump) server.
  
 
'''Decisions/Issues:'''
 
'''Decisions/Issues:'''
 +
:* DPI should support an "external portal" function for devices to establish (potentially concurrent) non-DPI connections, either inttermittent or persistent.
  
 
'''Action(s):'''
 
'''Action(s):'''
DPI
 
        Multiple concurrent connections must be supported
 
                Device communication systems are not disconnected with each other
 
        Portal vs. local "persistent" connections
 
 
*** Need to address multiple paths to the "enterprise" for the same device info (specialized servers vs. general gateway)
 
 
        Where would a lab system go?
 
 
In the F2F, need to see if we can come up with a model that will clearly communicate the differences between these perspectives and the PCD TF (as well as other IHE TFs).
 
  
 
|-
 
|-
 
| align="center" | 7
 
| align="center" | 7
| '''xyz''' <br>- Todd
+
| '''Updated DPI Profile Names''' <br>- Group
 
| '''Status/Discussion:'''
 
| '''Status/Discussion:'''
:* ...
+
:* Given the discussion earlier in the day re. moving away from "plug-and-play" and "closed-loop control" ... there was a discussion about the potential profile names.
 +
:* DPI-Discovery & Association
 +
:::- Device connecting into a "PnP" network
 +
:::- Discovery of other patient connected devices (incl. Schluter's nurse PDA discovering & commuicating with connected devices)
 +
:* DPI-Data Reporting
 +
:::- DRPolled
 +
:::- DRAsynchronous
 +
:* DPI-Bi-directional Information Exchange
 +
:::- Device Pairing / discovery of devices & information with same patient
 +
:* DPI-PIB
 +
:::- Wired - port oriented / pairing operation
 +
:::- Wireless pairing
 +
:* DPI-External Control
 +
:::- Open Loop
 +
:::- Closed Loop
 +
::::: Device reporting local settings for display on a monitor or central station for clinician review (a la PIV "closing the loop")
 +
:::: vs.
 +
::::: Changes to controls w/o clinician intervention (algorithmic)
  
'''Decisions/Issues:'''
+
::::: Fully automated control communication
 +
:::: vs.
 +
::::: Semi-automated control communication (human in the loop to complete the process)
 +
:* Safety Interlocks
 +
::::: '''''??? Never involves clinician activation???'''''
 +
:* Alarm silence
 +
:::-Open loop control
 +
:* U/C Arith. algo on Central ... linked to bed ... comm is broken ...
 +
::::: Must be "closed loop"
  
'''Action(s):'''
+
                 
DPI-PnP =>
 
        DPI-Discovery & Association
 
                Device connecting into a "PnP" network
 
                Discovery of other patient connected devices (incl. Schluter's nurse PDA discovering & commuicating with connected devices)
 
        DPI-Data Reporting
 
                DRPolled
 
                DRAsynchronous
 
        DPI-Bi-directional Information Exchange
 
                Device Pairing / discovery of devices & information with same patient
 
               
 
        DPI-PIB
 
                Wired - port oriented / pairing operation
 
                Wireless pairing
 
        DPI-External Control
 
                Open Loop
 
                Closed Loop
 
                          Device reporting local settings for display on a monitor or central station for clinician review (a la PIV "closing the loop")
 
                          vs.
 
                          Changes to controls w/o clinician intervention (algorithmic)
 
 
 
                          Fully automated control communication
 
                          vs.
 
                          Semi-automated control communication (human in the loop to complete the process)
 
                Safety Interlocks
 
                          ??? Never involves clinician activation???
 
                Alarm silence
 
                          Open loop control
 
 
 
                U/C Arith. algo on Central ... linked to bed ... comm is broken ...
 
                          Must be "closed loop"
 
  
                TO DO: Flesh out attributes associated with external control ... drudge out of use cases ... 
+
:* DPI - Real-time Archival [and retrieval] Management    "flight recorder"
  
        DPI - Real-time Archival [and retrieval] Management    "flight recorder"
+
:* DPI - Application Server Platform ???
 
 
        DPI - Application Server Platform ???
 
 
                 Ability of a device to request / receive / be notification re. download of an algo / code to be run on device  
 
                 Ability of a device to request / receive / be notification re. download of an algo / code to be run on device  
 
                 *** Drudge out use cases for this
 
                 *** Drudge out use cases for this
  
        DPI-
+
:* DPI-
 
                 Put device in "standby" mode for communication purposes (e.g., to save battery)
 
                 Put device in "standby" mode for communication purposes (e.g., to save battery)
 
                 Poll for device asset management functions (a la MEM)
 
                 Poll for device asset management functions (a la MEM)
 
                 RTLS
 
                 RTLS
  
 +
'''Decisions/Issues:'''
 +
 +
'''Action(s):'''
 +
:* (Group) Flesh out attributes associated with external control ... drudge out of the use cases ...
 
|-
 
|-
 
| align="center" | 8
 
| align="center" | 8

Revision as of 13:59, 22 October 2008

(DPI Profile Main Page)

Meeting Purpose

IHE PCD Device Point-of-care Integration (DPI) profile development discussions.

WebEx Information

Topic: IHE PCD DPI Profile TG

Date: Friday, October 17, 2008

Time: 10:00, Eastern Daylight Time (GMT -04:00, New York)

Duration: 90 Minutes


Note: Specific web & phone informaiton will be provided via e-mail to group members.

Contact Manny Furst for more information.

Proposed Agenda

1 Approve Minutes from previous session
2 Review Action Items
3 Application vs. Deployment Archicture
4 Review Transport Issues & Architectures for PnP
5 Topological Models Review
x Open discussion

Attachments / Materials

Minutes for approval: <add minutes links here>

Minutes

Participants

Chair/Host: Todd Cooper (BSF)
Steve Borchers (Spacelabs), John Garguilo (NIST), Colin FX (Epic), Jeff Rinda (Hospira), John Rhoads (Philips), Ken Fuchs (Draeger), Phil Raymond (Philips), Steve Merritt (Baystate Health), Jan Wittenber (Philips)

Discussion

Item Topic Discussion
1 Introductions & Agenda Review
- Chair
Status/Discussion:

Decisions/Issues:

  • Agenda reviewed & approved

Action(s):

2 Approval of Minutes
- Chair
Status/Discussion:

Decisions/Issues:

  • Minutes from 2008.10.15 reviewed & approved

Action(s):

3 PnP, CLC & Supplement Names
- Group
Status/Discussion:
  • General discussion around the use of the terms "plug-and-play" and "closed-loop control".
  • Key problems are that their meanings are overloaded (imply different concepts to different people), and sometimes "politically" charged, both of which result more confusion than clarity.
  • Jan indicated that there is ALWAYS some level of configuration / pre-coordination necessary in PnP systems; in other words, OTS PnP may never be achievable. A related was the 11073-30300 standard and the pre-configuration of the access point mappings from IRDA ports to IP addresses.
  • Profile titles should be formalized as:
- Discovery & Association (incl. "self ID")
- Data Reporting (or Data Reporting Polled & Data Reporting Asynchronous
- Bi-directional Information Exchange
- External Control

Decisions/Issues:

  • White paper should clarify the description of PnP per the above discussion (esp. the need for pre-coordination).
  • Update DPI profile name proposals

Action(s):

4 Wireless & Device/Patient Pairing
- Group
Status/Discussion:
  • The group discussed point-of-care DPI wireless use cases & architectural issues, with the following identified:
- A device may need two radios (short & long range)
- Pairing may be accomplished manually ... though auto methods exist, they are still error prone
- Need to look at different layers of the problem ... technology dependent / independent
- ICE spec includes the need to add devices into the PoC context without disrupting any other device connections / communication.
- Must be secure and include contextual awareness
  • Given the issues, wireless should be discussed in the white paper but the profile may be delayed until the 2nd DPI cycle.

Decisions/Issues:

  • Include wireless use case & related architecture discussion on Thursday afternoon @ F2F
  • Wireless DPI connections will not be addressed in the first prototyping cycle.

Action(s):

5 Enterprise Application vs. Deployment Architectures
- Group
Status/Discussion:
Enterprise functions
or
VeriScan is a stand-alone system
  • What does DPI mean?
DPI "PoC":
Must be patient connected
Focused on FIRST communication hop...
Enterprise
"full blown hospital information system"
vs.
Speciality systems (e.g., infusion pump management systems / gateways)
NOTE: May have a single function BUT do so across all the enterprise
  • Question: Where would Lab systems going in this paradigm?

Decisions/Issues:

  • In the F2F, need to see if we can come up with a model that will clearly communicate the differences between these perspectives and the PCD TF (as well as other IHE TFs).

Action(s):

6 Multiple Concurrent Connection Support
- Group
Status/Discussion:
  • Multiple concurrent connections must be supported, since some systems such as infusion pumps need to have both DPI connections as well as connections to their remote servers.
  • DPI connections are typically "persistent"; whereas, the non-DPI connections may be either persistent or more typically intermittent.
  • This implies that DPI must provide a method for opening a "portal" to non-DPI systems.
  • Additionally, there may be multiple paths for a device's data to the "enterprise". For example, a general DPI gateway vs. published from a specialized (e.g., infusion pump) server.

Decisions/Issues:

  • DPI should support an "external portal" function for devices to establish (potentially concurrent) non-DPI connections, either inttermittent or persistent.

Action(s):

7 Updated DPI Profile Names
- Group
Status/Discussion:
  • Given the discussion earlier in the day re. moving away from "plug-and-play" and "closed-loop control" ... there was a discussion about the potential profile names.
  • DPI-Discovery & Association
- Device connecting into a "PnP" network
- Discovery of other patient connected devices (incl. Schluter's nurse PDA discovering & commuicating with connected devices)
  • DPI-Data Reporting
- DRPolled
- DRAsynchronous
  • DPI-Bi-directional Information Exchange
- Device Pairing / discovery of devices & information with same patient
  • DPI-PIB
- Wired - port oriented / pairing operation
- Wireless pairing
  • DPI-External Control
- Open Loop
- Closed Loop
Device reporting local settings for display on a monitor or central station for clinician review (a la PIV "closing the loop")
vs.
Changes to controls w/o clinician intervention (algorithmic)
Fully automated control communication
vs.
Semi-automated control communication (human in the loop to complete the process)
  • Safety Interlocks
??? Never involves clinician activation???
  • Alarm silence
-Open loop control
  • U/C Arith. algo on Central ... linked to bed ... comm is broken ...
Must be "closed loop"


  • DPI - Real-time Archival [and retrieval] Management "flight recorder"
  • DPI - Application Server Platform ???
                Ability of a device to request / receive / be notification re. download of an algo / code to be run on device 
                *** Drudge out use cases for this
  • DPI-
                Put device in "standby" mode for communication purposes (e.g., to save battery)
                Poll for device asset management functions (a la MEM)
                RTLS

Decisions/Issues:

Action(s):

  • (Group) Flesh out attributes associated with external control ... drudge out of the use cases ...
8 Next Meeting
- Chair
Status/Discussion:

Decisions/Issues:

  • Next meeting will be the Boston face-to-face scheduled for 2008.10.23 & 24

Action(s):

Next Meeting

Next meeting scheduled for Thursday & Friday, 2008-10-23 & 24 in Boston


<Add review line here when minutes are approved; e.g., "(Reviewed & approved by PCD RTM Vent TG 2008-04-16)">


PCD Home