PCD DPI 2008-10-15 WebEx

(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: Wednesday, October 15, 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 Review 10/17 & F2F Agendas

4 Review Profile / White Paper Draft Proposals

- DPI White Paper

- DPI-PnP Profile

- ...

- DS White Paper

- DS-xyz

5 DPI White Paper Outline / Content

6 Open discussion

Attachments / Materials

Minutes for approval:

2008.10.13 WebEx Session

2008.09.22 WebEx Session - Item #5 example from Wittenber

Minutes

Participants

Chair/Host: Todd Cooper (BSF)

Steve Borchers (Spacelabs), Colin FX (Epic), John Garguilo (NIST), Kai Hassing (Philips), Steve Merritt (Baystate Health), John Rhoads (Philips), Jeff Rinda (Hospira), 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.13 discussion session reviewed, updated, and approved. Action(s):
3	Action Items Review - Chair	Status/Discussion: Briefly reviewed the action items list Reviewed changes to the primary DPI wiki page (including sections for: DPI Discussions & Background Documents Reviewed updated ICE documents (on FTP site ... linked from Background Documents NOTE: Thanks to John Rhoads for fixing these links after the discussion session. Decisions/Issues: Action(s):
4	DPI Scope Review - Todd	Status/Discussion: Jan engaged a discussion on the definition of "point-of-care" within the context of the DPI work NOTE: Ths discussion was kicked off during the review of the Scope in the 2008.10.13 Minutes Item #5 - Todd stated that within the IHE PCD, PoC is always patient centric - wherever the patient is located when care is delivered - This includes use cases where the patient is mobile and when clinicians may be remote - Use case example: Clinician is remote to the patient, using a PDA to do a drug calc and (potentially) directly adjust the device. In this case, some would consider where the clinician is to be the "point of care". - This distinction could be captured by discussing Physical PoC vs. Virtual PoC. Decisions/Issues: 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. Action(s):
5	DPI Roadmap Phasing - Group	Status/Discussion: The group discussed how to establish a road map for DPI, and the principles for phasing in various functions PCD domain scope bears a close affinity with the ITI domain, which is transitive across vertical clinically-oriented domains. Thus, initial profiling should support this "horizontal" integration. Given the focus of IHE and IHE PCD, initial focus should be on critical care use cases, though other scenarios shall be considered and the profile framework shall look forward to their support. Initial profiles should be easily achievable (similar to the strategy used in development of the DEC profile). Decisions/Issues: Initial priority should be on critical care contexts. Number of interface profiles / technologies should be minimized, if possible to (1), as appropriate. Action(s):
6	DPI Business Proposition - Group	Status/Discussion: In establishing the DPI roadmap and identifying those use cases and related DPI profiles that should be pursued first, it was stated that this should be based not only on technological feasibility, but also on what addresses the greatest business needs for the stake holders - both vendors and end users. What can provide the "biggest bang for the buck." For the provider perspective, Steve Merritt provided some key benefits that they see: - Increasing infusion pump safety (e.g., feedback control, eMAR / decision support system integration) - Ease of PoC reconfiguration (which is one of the DPI use cases); however, in this discussion - as to how much truly falls within the scope of DPI vs. other profiles such as Medical Equipment Management (MEM). - For example, if the devices or their systems used DNS, reconfiguration would be much easier - Steve indicated that the ICE use cases reflected provider needs - Bi-directional control was also mentioned, but this resulted in a discussion about hard regulatory blockers. For example, in the case of infusion pumps, in the end you need a clinician to actually press the Start button. The vendor business propositions were not discussed; however, in past PCD activities VP's have included heterogeneity (ease of system integration in multi-vendor multi-modality care contexts), and symmetric communication - bi-directionaly flow of information (including real-time waveforms) between devices at the point-of-care. Decisions/Issues: Development of the DPI roadmap should balance between technical feasibility and stakeholder business value propositions, maximizing the net benefit. DPI White Paper should include a section on business propositions - What can DPI provide over other solutions / technologies currently in the marketplace? Action(s):
7	DPI Prototyping Discussion - Group	Status/Discussion: Based on the DPI roadmap/phasing & business factors discussions above, the group spent some time looking at specific devices and technologies that might be considered for a DPI prototyping activity culminating in a demonstration at the 2009 IHE PCD New Directions Showcase. Devices: Key devices for this initial work should be physiological monitors, infusion pumps, and ventilators. Other devices could be added, especially depending on the scenario being demonstrated. Plug-and-play link should be... - Connection oriented (esp. based on lessons learned from the IEEE 11073 PHD WG activities over the last 2 years). - Needs to support a LAN architecture (recognizing the need to specify an initial connection strategy which has been a point of discussion in the 11073-20401 WG discussions). - Should be transport technology independent (as much as possible) - Does NOT need to support multi-point associations (i.e., a manager/proxy could be used), though this may be considered in subsequent DPI profiling. Device Reporting to a Manager agent should be the 1st goal (including parameters, alarms, alarm limits, waveforms, etc.) Symmetric Communication? - This has been identified as a key requirement / benefit for vendors who have looked at DPI participation - Kai indicated that there is no clear standardized approach that might be applied ... though the 11073-20302 symmetric communcation optional package draft standard did provide a design approach within the context of the 11073 PnP service profiles. This approach may be too "heavy" for many devices that, for example, simply want to issue a request for a specific parameter (with associated QoS requirements) and then link to a data source. - Based on this, Kai's recommendation was to wait until a future DPI development cycle. - Evaluation of specific use cases should help determine the priority and communication requirements for this function Open Loop Control? - Though control is another key DPI functionality often mentioned, it too may need to be delayed to a subsequent cycle, given the status of the underlying standards. - The white paper should make a clear distinction between open loop (e.g., clinician momentarily pausing a vent, changing an alarm limit or %02) vs. closed loop control (e.g., device receiving a feedback data stream from another system and automatically modifying its own therapeutic settings based on programmed targets). White paper should include a discussion & requirement regarding re-use of the same transport technologies for alternative functions such as device configuration or PM servicing functions. Decisions/Issues: DPI-PnP profiling & prototyping should focus initially on... - Physiological Monitors, Infusion Pumps & Ventilators - Should be connection oriented - Should support a LAN architecture (though transport independent) White Paper should include a use case and discussion regarding the re-use of a DPI PnP transport for non-DPI vendor-specific applications such as configuration or PM servicing and test. Action(s): (Cooper/Wittenber) Pull up previous use cases that motivated the need for symmetric communication.
10	Next Meeting - Chair	Status/Discussion: Decisions/Issues: Next meeting will be scheduled for Monday 2008.10.17 Action(s):

Next Meeting

Next meeting scheduled for Monday, 2008-10-17 @ 10:00 - 11:30 Eastern

(Reviewed & approved by PCD DPI TG 2008-10-17)

PCD Home