Difference between revisions of "PCD DPI 2008-10-23 to 24 F2F"

From IHE Wiki
Jump to navigation Jump to search
m
 
(48 intermediate revisions by 3 users not shown)
Line 28: Line 28:
 
| '''<see below>'''
 
| '''<see below>'''
 
|}
 
|}
 +
 +
  
  
Line 49: Line 51:
  
 
:::There is also [ftp://ftp.ihe.net/Patient_Care_Devices/Profiles/DPI/20081023F2F/CIMIT_Hotels_Near_CIMIT_65Landsdowne_CIMIT.doc a document with hotels near CIMIT Landsdowne].
 
:::There is also [ftp://ftp.ihe.net/Patient_Care_Devices/Profiles/DPI/20081023F2F/CIMIT_Hotels_Near_CIMIT_65Landsdowne_CIMIT.doc a document with hotels near CIMIT Landsdowne].
 +
 +
 +
:'''NOTE:''' ''The morning commute from Holliston to Cambridge (if you are spending the night in a hotel near Technology in Medicine), can run 75 - 90 minutes ... !!!''
  
 
== Preliminary Agenda Topics ==
 
== Preliminary Agenda Topics ==
Line 56: Line 61:
  
 
'''Thursday Afternoon'''
 
'''Thursday Afternoon'''
 +
:* Review Agenda & Participation
 +
:* DEC & DPI (deferred from A.M. sessions)
 +
:::- Enterprise vs. PoC Architectural Definitions
 +
:::- Query Bulk Data (a.k.a. Archival...)
 +
:* Review minutes from [[PCD_DPI_2008-10-17_WebEx | 2008.10.17]]
 +
:* PnP => DPI Profile History
 +
:::- Review of 2007 PnP Detailed Profile Proposal / Supplement Review
 +
:::- Review [[PCD_Profile_Device_Point-of-Care_Integration_%28DPI%29 | current DPI activities]]
 
:* Review DPI Scope
 
:* Review DPI Scope
 
:::- Are all DPI interfaces PnP - with a single mechanism?
 
:::- Are all DPI interfaces PnP - with a single mechanism?
 
:::- Does this include / exclude WAN connections (such as HITSP RMON)?
 
:::- Does this include / exclude WAN connections (such as HITSP RMON)?
 +
:* Review DPI Decisions List
 +
:* Review Current Use Cases
 +
:::- From 2007 PnP Supplement
 +
:::- Infusion Pump Symmetric Comm
 +
:::- Infusion Pump Wireless
 +
:::- Additional Proposals
 +
:* ASTM "ICE" Review (prep for Friday)
 +
:::- Use Cases
 +
:::- Conceptual Model
 +
:::- Requirements
  
 
'''Friday @ CIMIT'''
 
'''Friday @ CIMIT'''
 
:* Introductions & Organizational Representation
 
:* Introductions & Organizational Representation
 
:* Agenda Review
 
:* Agenda Review
 +
:* IHE PCD Update (current & next cycle activities)
 
:* Coordination with "ICE" use cases & conceptual architecture & requirements
 
:* Coordination with "ICE" use cases & conceptual architecture & requirements
 +
:::- Overview of current ICE ballot document & related activities (Goldman)
 +
:::- Use Case Mapping to Conceptual Model Examples (Rausch)
 +
:* [ftp://ftp.ihe.net/Patient_Care_Devices/Profiles/DPI/ICE/ICE-Use_Case_Modeling_2_Wittenber_2008-05.ppt.pdf ICE Use Case Modeling - Wittenber] Review (action item from FDA 2008.03.25 meeting)
 +
:* Business Value Propositions & Planning
 +
:::- MD FIRE Update
 +
:::- Vendor Propositions
 +
:* DPI White Paper - Outline & Profile Proposal
 +
:* DPI Multi-Cycle Roadmap / Milestones Planning
 +
:::- Profile Roadmap
 +
:::- Cycle Proposals
 +
:::- Related Workproducts (incl. open source, tooling, ...)
 +
:* Review profiling proposals for the HIMSS '09 IHE Showcase "New Directions" Section
 +
:* State-aware Transaction Profiles Update
 +
:* Control Semantics Model (Wittenber)
 +
:* Meeting Scheduling (WebEx, F2F, ...)
 +
:* Adjourn
  
 
== Attachments / Materials ==
 
== Attachments / Materials ==
  
'''<Placeholder>'''
+
:* [ftp://ftp.ihe.net/Patient_Care_Devices/Profiles/DPI/20081023F2F/PCD_Domain_Architecture_Overview_Fuchs.ppt IHE PCD Domain Architecture Model (Fuchs)]
  
 +
:* [ftp://ftp.ihe.net/Patient_Care_Devices/Profiles/DPI/20081023F2F/IHE_PCD_Work_Program_Overview_at_CIMIT_2008-10-24.pdf IHE PCD 2008-2010 Work Program Overview]
  
 
== Minutes ==
 
== Minutes ==
  
 +
=== Participants ===
 +
 +
:'''Chair/Host:'''  Todd Cooper (BSF)
 +
 +
 +
: '''Thursday afternoon, 2008.10.23'''
 +
:: Jon Blasingame (Philips), Steve Borchers (Spacelabs), Ken Fuchs (Draeger), Julian Goldman (MDPnP), Kai Hassing (Philips), John Hotchkiss (LiveData), Monroe Patillo (Philips/Emergin), Tracy Rausch (DocBox), John Rhoads (Philips), Jeff Rinda (Hospira), Paul Schluter (GE), Jan Wittenber (Philips)
 +
 +
 +
 +
: '''Friday, 2008.10.24'''
 +
::: Jon Blasingame (Philips), Steve Borchers (Spacelabs), Emily Braunstein (Draper), Ken Fuchs (Draeger), Julian Goldman (MDPnP), Jack Harrington (ACCE), Kai Hassing (Philips), John Hotchkiss (LiveData), Tracy Rausch (DocBox), John Rhoads (Philips), Rick Schrenker (Partners), Jan Wittenber (Philips)
 +
 +
=== Discussion ===
 +
 +
:{|border="2"
 +
|-
 +
! width="5%"  align="center" |Item
 +
! width="25%"  align="left"  |Topic
 +
!              align="left"  |Discussion
 +
|-
 +
| align="center" | 1
 +
| '''Introductions & Agenda Review''' <br>- Chair
 +
| '''Status/Discussion:'''
 +
'''Decisions/Issues:'''
 +
:* Agenda reviewed & approved
 +
 +
'''Action(s):'''
 +
|-
 +
| align="center" | 2
 +
| '''Approval of Minutes''' <br>- Chair
 +
| '''Status/Discussion:'''
 +
 +
'''Decisions/Issues:'''
 +
:* Minutes from 2008.10.17 reviewed & approved
 +
 +
'''Action(s):'''
 +
|-
 +
| align="center" | 3
 +
| '''PCD Application vs. Deployment Arch (w/QBD Profile)''' <br>- Group
 +
| '''Status/Discussion:'''
 +
:* The discussion of the [[PCD_Brief_Profile_Proposal_2008_QBD | Query Bulk Data (QBD) profile proposal]] was deferred from the morning session, and set the stage for a general discussion on PCD profiles & deployment vs. application archictures.
 +
:* Ken Fuchs presented a diagram for the [ftp://ftp.ihe.net/Patient_Care_Devices/Profiles/DPI/20081023F2F/PCD_Domain_Architecture_Overview_Fuchs.ppt PCD Domain Enterprise vs. Point-of-Care Deployment Architecture.]
 +
:* When considering DPI profiles, a key question for the PCD is the definition of point-of-care vs. enterprise level systems ... and systems that are a hybrid of both.
 +
:* Todd presented [ftp://ftp.ihe.net//Patient_Care_Devices/Profiles/DPI/20081023F2F/DPI_InfusionPump_UseCases_r2.pdf two infusion pump scenarios] that were developed with Jeff Rinda.  These underscore the need for ''symmetric communication'' and the need for ''both local and remote communication services.''
 +
:* General Discussion:
 +
::- Jan:  A different perspective (horizontal) needed to see the actual connections
 +
::- Jan:  What are the end-points; how many "hops" are needed?  The focus of DPI profiles is the first link from a device to a ''local'' network controller.  Application end points could result in many communication "hops" and may be local or remote.
 +
::- Ken: What is a "spot check" monitor?
 +
::- Todd: Consider the BCMA system & PIV profile, where the clinician enters the data at the PoC, but the processing is handled by a "5 rights" typically running on a remote application server, and then sends the PCD-03 transaction to an infusion pump server that sends the data to the pump ... next to the clinician who just scanned the bar codes and now can verify the
 +
::- Ken/Jan:  Device may have multiple simultaneous conversations
 +
::- Does DPI include use cases / deployment architectures where the data leaves the point-of-care and then comes back in, or does it need to remain "local" in systems around the PoC?
 +
 +
:* Definition of Enterprise?
 +
::- Not 1:1 device to application
 +
::- Application 1:n patients / care contexts
 +
::- Application 1:n devices
 +
::- Not 1st device link
 +
 +
'''Decisions/Issues:'''
 +
 +
'''Action(s):'''
 +
|-
 +
| align="center" | 4
 +
| '''DPI Scope Review''' <br>- Group
 +
| '''Status/Discussion:'''
 +
:* Current statement:
 +
:: ''Device Point-of-care Integration (DPI) is concerned with use cases that include care contexts that fall  within the stated charter of the IHE PCD, namely where "at least one actor is a regulated patient centric  point-of-care medical device," and that require device-to-device communication.''
 +
:* This scope may be further refined as:
 +
:: Primary context is acute/critical care; however, other points of care may also be considered  including remote clinics and the medical home. In other words, the "point-of-care" is where  the patient is located when at least one regulated medical device is connected to them.
 +
:* NOTE: This scope includes the exclusions previously defined for PCD, namely medical imaging  (addressed within Radiology, Cardiology & Laboratory).
 +
::- Devices may include traditional critical care equipment such as physiological monitors,  ventilators, infusion pumps, pulse- oximeters, etc., or other equipment located at the point-of-care  that may also provide information and services needed for care delivery.
 +
::- Integration shall support not only plug-and-play connectivity for device reporting, but bi-  directional & symmetric communication, and device-external control (ranging from basic  configuration such as adjustment of alarm limits to full closed- loop control).
 +
::- For the purposes of IHE PCD & specifically DPI, PoC shall be defined as where the patient is  located. Use cases with remote clinicians may also be considered; however, DPI will focus on a  patient-centric PoC.
 +
::- Must be patient connected / centric
 +
::- Focused on FIRST (device-external) <interoperability> communication link
 +
:::: e.g., device to concentrator to flow sheet application; DPI focus is the link to the  concentrator.
 +
:::: concentrator = w/ PoC or to PoC subnet
 +
::- Support strong QoS monitoring / management
 +
 +
'''Decisions/Issues:'''
 +
 +
 +
'''Action(s):'''
 +
 +
|-
 +
| align="center" | 5
 +
| '''Device Control''' <br>- Group
 +
| '''Status/Discussion:'''
 +
:* A key DPI issue is the perspective that should be taken on device control.  The range of use cases is from temporarily silencing an alarm to setting an alarm limit to full device external control.
 +
:* Jan discussed the problem that much of the terminology is overloaded - people using the same terms but with strikingly different meanings.  He suggested the following paradigm might help:
 +
 +
::::{|border="2"
 +
|-
 +
! align="left"  |
 +
! colspan="2" align="center" |Open
 +
! colspan="2" align="center" |Closed
 +
|-
 +
| &nbsp;
 +
| align="center" |'''Afferent'''
 +
| align="center" |'''Efferent'''
 +
| align="center" |'''Afferent'''
 +
| align="center" |'''Efferent'''
 +
|-
 +
| '''Local'''
 +
| Clinician changes alarm limit via device console
 +
| Clinician changes infusion rate via device console
 +
| Device-internal algorithm changes alarm limit
 +
| Device-internal algorithm changes infusion rate
 +
|-
 +
| '''Remote'''
 +
| Clinician changes alarm limit via comm link
 +
| Clinician changes infusion rate via comm link
 +
| Device-external algorithm changes alarm limit via comm link
 +
| Device-external algorithm changes infusion rate via comm link
 +
|}
 +
 +
::::Notes:
 +
:::::- '''"Open"''' means human (clinician or patient) is in the loop (a.k.a. "manual")
 +
:::::- '''"Closed"''' means that the human is "proxied" / not in the loop (a.k.a. "auto")
 +
:::::- '''"Local"''' means at the medical device, not through the communication channel
 +
::::::: '''(It is assumed that all device configuration/control changes are reported through the communication channel, including those effected locally.)'''
 +
:::::- '''"Remote"''' means that the communication channel is used
 +
:::::- '''"Efferent"''' indicates that the control effectuates energy change between the device & patient (e.g., infusion rate, vent mode, start/stop NIBP, etc.)
 +
:::::- '''"Afferent"''' indicates that the control does not directly affect the patient (e.g., alarm limit setting)
 +
 +
:* PCLC - When discussing physiologic closed loop control algorithms, it was also noted that often a PCLC algorithm will operate within boundaries set by a POLC (open loop control) - one contained within the other.  Thus the clinician would set the boundaries within which the system could operate in a closed system (including PCA programming), but when key PCLC parameters hit a limit, the POLC would alarm for clinician review and intervention.
 +
 +
'''Decisions/Issues:'''
 +
 +
'''Action(s):'''
 +
 +
|-
 +
| align="center" | 6
 +
| '''CIMIT Discussion''' <br>- Group
 +
| '''Status/Discussion:'''
 +
:* Dr. Goldman provided a general update on the "ICE" Part I draft standard submitted for ballot in ASTM F29.21.
 +
:* Additionally, Julian discussed the [http://mdpnp.org/MD_FIRE.php MD FIRE] initiative that was announced a few days before at the ASA meetings.
 +
:* Todd provided an overview of the IHE PCD work program, esp. the proposed Cycle 4 activities.
 +
:* Dr. Goldman questioned whether this (i.e., the IHE PCD DPI activity) was the appropriate forum for these discussions, especially in regard to the scope of IHE PCD profiling vs. the ICE program.
 +
:* It was decided that the DPI WG and ICE WG should form a "tiger team" (or Joint Working Group) to address coordination between the two groups and identify how DPI can provide support (in the future) for ICE-based integrated networks.  This will include a "map & gap" exercise between ICE requirements, existing / emerging standards, and IHE profiles.  This should directly influence the emerging IHE PCD DPI profile roadmap.
 +
 +
'''Decisions/Issues:'''
 +
 +
'''Action(s):'''
 +
 +
|-
 +
| align="center" | 7
 +
| '''DPI White Paper Discussion''' <br>- Group
 +
| '''Status/Discussion:'''
 +
:* Various sections of the proposed DPI White Paper were discussed
 +
:* The content from this discussion will be captured in the outline for the [[PCD_Brief_Profile_Proposal_2008_DPI_WP | DPI White Paper proposal]].
 +
 +
'''Decisions/Issues:'''
 +
 +
'''Action(s):'''
 +
 +
|-
 +
| align="center" | 8
 +
| '''DPI Roadmap''' <br>- Group
 +
| '''Status/Discussion:'''
 +
:* There was a general discussion about the best way to move forward on the DPI work program.
 +
:* Ken asked a fundamental question whether the IHE PCD could incrementally evolve a set of DPI profiles to address point-of-care connectivity, or whether a major effort needs to be launched (and funding acquired) to complete requirements, design and technology development. 
 +
:* At the end of the day, the group decided the following course of action:
 +
::- A DPI White Paper should be developed as soon as possible to provide an overview of the topic within the context of the IHE PCD.
 +
::- A number of profile proposals should be pursued to enable DPI connectathon testing in 2010.  The proposals discussed were:
 +
:::* [[PCD Brief Profile Proposal 2008 DPI-DnA | (DPI-DnA) DPI/Discovery and Association]]
 +
:::* [[PCD Brief Profile Proposal 2008 DPI-DR | (DPI-DR) DPI/Data Reporting]]
 +
:::* [[PCD Brief Profile Proposal 2008 DPI-SYC | (DPI-SYC) DPI/Symmetric Communication]]
 +
::- The DPI group should pursue a prototyping activity in the near term to try and show something at the 2009 IHE PCD Showcase New Directions section.  This would be based on the White Paper and the three profiles being proposed.
 +
 +
'''Decisions/Issues:'''
 +
 +
'''Action(s):'''
 +
 +
|-
 +
| align="center" | 9
 +
| '''Next Meeting''' <br>- Chair
 +
| '''Status/Discussion:'''
 +
'''Decisions/Issues:'''
 +
:* Next meeting is [[PCD_DPI_2008-11-11_WebEx | 2008.11.11]]
 +
 +
'''Action(s):'''
 +
|}
 +
 +
 +
::'''''(Meeting minutes reviewed and approved at [[PCD_DPI_2008-11-11_WebEx | DPI WebEx session 2008.11.11)'''''
  
  
 
[[Patient Care Device | PCD Home]]
 
[[Patient Care Device | PCD Home]]
[[Category:PCD Meeting]]
+
 
 +
[[Category:PCD Meeting Archive]]

Latest revision as of 12:41, 24 January 2009

Meeting Objectives

Immediately following the IHE PCD Planning & Technical F2F meetings in Boston, the Device Point-of-care Integration (DPI) WG will aim to:
  • Finalize the core content of the DPI White Paper
  • Finalize the DPI profiles to be pursued during the PCD Cycle 4 Development
  • Coordinate with the CIMIT/MDPnP & ASTM "ICE" project teams.


Preliminary Schedule

Date Hours Committees Topics
2008.10.23 13:00 - 17:00 PCD DPI WG <see below>
2008.10.24 08:00 - 17:00 DPI WG & CIMIT/MDPnP + ASTM "ICE" Teams <see below>



Location Information

  • Thursday afternoon (immediately following the IHE PCD TC F2F):
Technology in Medicine, Inc.
325 Hopping Brook Road
Holliston, MA 01746
(508) 893-9500
More detailed location information is available on the TiM web site.
  • Friday (all day)
Center for Integration of Medicine & Innovative Technology (CIMIT)
Partners Research Building
65 Landsdowne Street
Cambridge, MA 02139
More detailed directions to CIMIT Landsdowne are on the IHE PCD ftp site.
There is also a document with hotels near CIMIT Landsdowne.


NOTE: The morning commute from Holliston to Cambridge (if you are spending the night in a hotel near Technology in Medicine), can run 75 - 90 minutes ... !!!

Preliminary Agenda Topics

Agenda Suggestions Welcome; please add them here... The following are not in schedule order

Thursday Afternoon

  • Review Agenda & Participation
  • DEC & DPI (deferred from A.M. sessions)
- Enterprise vs. PoC Architectural Definitions
- Query Bulk Data (a.k.a. Archival...)
  • Review minutes from 2008.10.17
  • PnP => DPI Profile History
- Review of 2007 PnP Detailed Profile Proposal / Supplement Review
- Review current DPI activities
  • Review DPI Scope
- Are all DPI interfaces PnP - with a single mechanism?
- Does this include / exclude WAN connections (such as HITSP RMON)?
  • Review DPI Decisions List
  • Review Current Use Cases
- From 2007 PnP Supplement
- Infusion Pump Symmetric Comm
- Infusion Pump Wireless
- Additional Proposals
  • ASTM "ICE" Review (prep for Friday)
- Use Cases
- Conceptual Model
- Requirements

Friday @ CIMIT

  • Introductions & Organizational Representation
  • Agenda Review
  • IHE PCD Update (current & next cycle activities)
  • Coordination with "ICE" use cases & conceptual architecture & requirements
- Overview of current ICE ballot document & related activities (Goldman)
- Use Case Mapping to Conceptual Model Examples (Rausch)
- MD FIRE Update
- Vendor Propositions
  • DPI White Paper - Outline & Profile Proposal
  • DPI Multi-Cycle Roadmap / Milestones Planning
- Profile Roadmap
- Cycle Proposals
- Related Workproducts (incl. open source, tooling, ...)
  • Review profiling proposals for the HIMSS '09 IHE Showcase "New Directions" Section
  • State-aware Transaction Profiles Update
  • Control Semantics Model (Wittenber)
  • Meeting Scheduling (WebEx, F2F, ...)
  • Adjourn

Attachments / Materials

Minutes

Participants

Chair/Host: Todd Cooper (BSF)


Thursday afternoon, 2008.10.23
Jon Blasingame (Philips), Steve Borchers (Spacelabs), Ken Fuchs (Draeger), Julian Goldman (MDPnP), Kai Hassing (Philips), John Hotchkiss (LiveData), Monroe Patillo (Philips/Emergin), Tracy Rausch (DocBox), John Rhoads (Philips), Jeff Rinda (Hospira), Paul Schluter (GE), Jan Wittenber (Philips)


Friday, 2008.10.24
Jon Blasingame (Philips), Steve Borchers (Spacelabs), Emily Braunstein (Draper), Ken Fuchs (Draeger), Julian Goldman (MDPnP), Jack Harrington (ACCE), Kai Hassing (Philips), John Hotchkiss (LiveData), Tracy Rausch (DocBox), John Rhoads (Philips), Rick Schrenker (Partners), 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.17 reviewed & approved

Action(s):

3 PCD Application vs. Deployment Arch (w/QBD Profile)
- Group
Status/Discussion:
  • The discussion of the Query Bulk Data (QBD) profile proposal was deferred from the morning session, and set the stage for a general discussion on PCD profiles & deployment vs. application archictures.
  • Ken Fuchs presented a diagram for the PCD Domain Enterprise vs. Point-of-Care Deployment Architecture.
  • When considering DPI profiles, a key question for the PCD is the definition of point-of-care vs. enterprise level systems ... and systems that are a hybrid of both.
  • Todd presented two infusion pump scenarios that were developed with Jeff Rinda. These underscore the need for symmetric communication and the need for both local and remote communication services.
  • General Discussion:
- Jan: A different perspective (horizontal) needed to see the actual connections
- Jan: What are the end-points; how many "hops" are needed? The focus of DPI profiles is the first link from a device to a local network controller. Application end points could result in many communication "hops" and may be local or remote.
- Ken: What is a "spot check" monitor?
- Todd: Consider the BCMA system & PIV profile, where the clinician enters the data at the PoC, but the processing is handled by a "5 rights" typically running on a remote application server, and then sends the PCD-03 transaction to an infusion pump server that sends the data to the pump ... next to the clinician who just scanned the bar codes and now can verify the
- Ken/Jan: Device may have multiple simultaneous conversations
- Does DPI include use cases / deployment architectures where the data leaves the point-of-care and then comes back in, or does it need to remain "local" in systems around the PoC?
  • Definition of Enterprise?
- Not 1:1 device to application
- Application 1:n patients / care contexts
- Application 1:n devices
- Not 1st device link

Decisions/Issues:

Action(s):

4 DPI Scope Review
- Group
Status/Discussion:
  • Current statement:
Device Point-of-care Integration (DPI) is concerned with use cases that include care contexts that fall within the stated charter of the IHE PCD, namely where "at least one actor is a regulated patient centric point-of-care medical device," and that require device-to-device communication.
  • This scope may be further refined as:
Primary context is acute/critical care; however, other points of care may also be considered including remote clinics and the medical home. In other words, the "point-of-care" is where the patient is located when at least one regulated medical device is connected to them.
  • NOTE: This scope includes the exclusions previously defined for PCD, namely medical imaging (addressed within Radiology, Cardiology & Laboratory).
- Devices may include traditional critical care equipment such as physiological monitors, ventilators, infusion pumps, pulse- oximeters, etc., or other equipment located at the point-of-care that may also provide information and services needed for care delivery.
- Integration shall support not only plug-and-play connectivity for device reporting, but bi- directional & symmetric communication, and device-external control (ranging from basic configuration such as adjustment of alarm limits to full closed- loop control).
- For the purposes of IHE PCD & specifically DPI, PoC shall be defined as where the patient is located. Use cases with remote clinicians may also be considered; however, DPI will focus on a patient-centric PoC.
- Must be patient connected / centric
- Focused on FIRST (device-external) <interoperability> communication link
e.g., device to concentrator to flow sheet application; DPI focus is the link to the concentrator.
concentrator = w/ PoC or to PoC subnet
- Support strong QoS monitoring / management

Decisions/Issues:


Action(s):

5 Device Control
- Group
Status/Discussion:
  • A key DPI issue is the perspective that should be taken on device control. The range of use cases is from temporarily silencing an alarm to setting an alarm limit to full device external control.
  • Jan discussed the problem that much of the terminology is overloaded - people using the same terms but with strikingly different meanings. He suggested the following paradigm might help:
Open Closed
  Afferent Efferent Afferent Efferent
Local Clinician changes alarm limit via device console Clinician changes infusion rate via device console Device-internal algorithm changes alarm limit Device-internal algorithm changes infusion rate
Remote Clinician changes alarm limit via comm link Clinician changes infusion rate via comm link Device-external algorithm changes alarm limit via comm link Device-external algorithm changes infusion rate via comm link
Notes:
- "Open" means human (clinician or patient) is in the loop (a.k.a. "manual")
- "Closed" means that the human is "proxied" / not in the loop (a.k.a. "auto")
- "Local" means at the medical device, not through the communication channel
(It is assumed that all device configuration/control changes are reported through the communication channel, including those effected locally.)
- "Remote" means that the communication channel is used
- "Efferent" indicates that the control effectuates energy change between the device & patient (e.g., infusion rate, vent mode, start/stop NIBP, etc.)
- "Afferent" indicates that the control does not directly affect the patient (e.g., alarm limit setting)
  • PCLC - When discussing physiologic closed loop control algorithms, it was also noted that often a PCLC algorithm will operate within boundaries set by a POLC (open loop control) - one contained within the other. Thus the clinician would set the boundaries within which the system could operate in a closed system (including PCA programming), but when key PCLC parameters hit a limit, the POLC would alarm for clinician review and intervention.

Decisions/Issues:

Action(s):

6 CIMIT Discussion
- Group
Status/Discussion:
  • Dr. Goldman provided a general update on the "ICE" Part I draft standard submitted for ballot in ASTM F29.21.
  • Additionally, Julian discussed the MD FIRE initiative that was announced a few days before at the ASA meetings.
  • Todd provided an overview of the IHE PCD work program, esp. the proposed Cycle 4 activities.
  • Dr. Goldman questioned whether this (i.e., the IHE PCD DPI activity) was the appropriate forum for these discussions, especially in regard to the scope of IHE PCD profiling vs. the ICE program.
  • It was decided that the DPI WG and ICE WG should form a "tiger team" (or Joint Working Group) to address coordination between the two groups and identify how DPI can provide support (in the future) for ICE-based integrated networks. This will include a "map & gap" exercise between ICE requirements, existing / emerging standards, and IHE profiles. This should directly influence the emerging IHE PCD DPI profile roadmap.

Decisions/Issues:

Action(s):

7 DPI White Paper Discussion
- Group
Status/Discussion:
  • Various sections of the proposed DPI White Paper were discussed
  • The content from this discussion will be captured in the outline for the DPI White Paper proposal.

Decisions/Issues:

Action(s):

8 DPI Roadmap
- Group
Status/Discussion:
  • There was a general discussion about the best way to move forward on the DPI work program.
  • Ken asked a fundamental question whether the IHE PCD could incrementally evolve a set of DPI profiles to address point-of-care connectivity, or whether a major effort needs to be launched (and funding acquired) to complete requirements, design and technology development.
  • At the end of the day, the group decided the following course of action:
- A DPI White Paper should be developed as soon as possible to provide an overview of the topic within the context of the IHE PCD.
- A number of profile proposals should be pursued to enable DPI connectathon testing in 2010. The proposals discussed were:
- The DPI group should pursue a prototyping activity in the near term to try and show something at the 2009 IHE PCD Showcase New Directions section. This would be based on the White Paper and the three profiles being proposed.

Decisions/Issues:

Action(s):

9 Next Meeting
- Chair
Status/Discussion:

Decisions/Issues:

Action(s):


(Meeting minutes reviewed and approved at [[PCD_DPI_2008-11-11_WebEx | DPI WebEx session 2008.11.11)


PCD Home