PCD Detailed Profile Proposal 2009 DPI-DnA

From IHE Wiki
Jump to navigation Jump to search


Proposed Workitem: Device Point-of-care Integration - Discovery and Association (DPI-DnA)

  • Proposal Editor: Todd Cooper, Jan Wittenber
  • Editor: Jan Wittenber
  • Date: N/A (Wiki keeps history)
  • Version: N/A (Wiki keeps history)
  • Domain: PCD

The Problem

Within the framework of Device Point-of-Care Integration (DPI) profiles, the first step of establishing communication between systems is for a device to announce its presence, discover the system(s) that are managing network communication, and establish an association that will determine how that device can participate in network communications.

This profile shall support those functions needed to support discovery and association of devices in a DPI network.


Key Use Case

A medical device (e.g., physiological monitor, infusion pump or ventilator) is connected to a patient-local point-of-care network. The device announces its presence, connects to a manager system, determines the type of connection(s) that can be established and establishes an association with the manager system. This association includes communication protocol selection and configuration, as well as quality of service support negotiation.


Standards & Systems

1. ISO/IEEE 11073 standards for medical device communication
2. CEN 13735 (currently being migrated to ISO/IEEE 11073 standards).


Discussion

1. This profile is part of a set of DPI profiles that support device conneectivity, especially plug-and-play communication.
2. Several profiles (A-D in the following Table) are defined to evolve over IHE PCD DPI, based on capabilities and vintage of interconnecting device, e.g. medical device or gateway. In general, the following functions are incorporated in the layered services (adapted from IEEE P11073-20401, Common IP Services):
  • Obtaining IP addresses,
  • Service advertisement & discovery,
  • Timely message delivery,
  • Network access control,
  • Network availability,
  • Quality of service,
  • Time services,
  • Network management services,
  • Security and authentication.
  • Also included is any appropriate Ethernet (layer 2) switching and VLAN functionality.


Profile Composition
  A B C D
Service Level/Layer1        
Application        
        • Time Service SNTP
        • TimelyMsgDelivery RTP
        • Net Mgmt SNMP
        • Medical Device Info Base (MDIB)   IEEE 11073-10101, -10201, -20101;
CEN 13735 		IEEE 11073-20601
        • Dynamic Host Discov. Non-DHCP/bootp DHCP/bootp  
        • Advert./Discovery   “CI” 2  
Transport  
        • Inter-Network Non-IP TCP-, UDP/IP
                ° Network Non-IEEE802 IEEE8023
        • Data/Physical Link  
                ° Mode Non-IEEE 11073-based IEEE 11073-30200 or -30300-based Wired Wireless
                ° MAC IEEE 802.3-based IEEE 802.11 based IEEE 802.15 based
                ° Security/Access Ctl 802.1x 802.11i  
                ° QoS   802.11e  
Key: Italicized elements are preferably dynamically coordinated but conditional pre-coordination properties may be specified in particular IHE PCD DPI profiles, esp. for initial deployment.
1 ISO OSI or Internet architectural layer hybridized for simplicity.
2 “Connection Indication (CI)” PDU required for dynamic MDIB initiation
3 Wired ↔ Wireless inter-mode may be deployed with suitable precoordination of switching method

Technical Approach

Existing actors

No existing actors will be affected by this profile.

New actors

Possible new actors include:

  • Medical Device Agent (connecting into the network)
  • Device Agent (non-medical device component connecting into the network_)
  • Device Manager (provides the services needed to support DnA)

Note: Depending on the selected architecture, actors such as the DM may be separated into multiple entities providing specific functionality (e.g., Network Configuration Manager)

Existing transactions

No existing transactions should be affected by this profile.

New transactions (standards used)

Based on previous prototyping activies for these kinds of systems, the following transactions may include:

  • Connect Indication to the Network
  • Association Request and Response
  • Retrieve Device Directory (e.g., to locate an appropriate manager)
  • ...

Note: The services supported by DnA are not single transaction oriented, like most other PCD profiles, but rather have a state model and numerous transactions depending on overall connection status.


Impact on existing integration profiles

No direct impact or scope overlap. They extend the functionality of existing profiles to the point-of-care.

Breakdown of tasks that need to be accomplished

NOTE: Depending on early discussions, especially during the development of the DPI White Paper, the DPI-DnA profile supplment may be broken into multiple phases (at least 2) depending on the transport technologies used and the level of pre-coordination (or PnP) that could be supported in the Phase I version.

Anticipated tasks for Phase I include:

  • Develop work plan
  • Evaluate target transports for Phase I
  • Evaluate Discovery mechanisms
  • Evaluate association methods
  • Draft supplement
  • Review at spring F2F
  • Publish for public comment 2009.05.15

Support & Resources

The following organizations have either actively participated or indicated interest in DPI profile development activities:

  • Baystate Health
  • Breakthrough Solutions Foundry
  • Cardinal/VIASYS
  • Draeger
  • FDA
  • Hospira
  • Improvement Technologies
  • Kaiser Permanente
  • LiveData
  • NIST
  • Philips Healthcare
  • Respironics (Philips)

It is anticipated that these companies will support at some level the development of the profile supplement.

Risks

The following risks have been identified for development of the DPI white paper (not an exhaustive list!):

  • Breadth of scope (especially for the first Phase development) expands in breadth and depth beyond what can be supported by the available resources and schedule.
  • The Phase I content does not support a viable set of functions that can be quickly prototyped or that reflect a business model behind which companies can motivate participation. Note: this could be the result of scope/content that is too broad, too narrow, or simply off target.
  • Gaps in core standards, requiring postponment of profile supplement development.
  • Push back from other groups that may be moving toward the DPI use case space.
  • Requirements arising from the HITSP Common Device Connectivity (CDC) use case may drive DPI-related development in a different direction than currently envisioned.


Open Issues

Besides the activities and risks identified elsewhere in this proposal, the following issues also need to be resolved:

  • Balancing between DPI development (multiple supplements) and other IHE PCD development activities, especially when they are related to DPI profiles and thus need to be coordinated, as well as standards development activities that may require some of the same resources that are currently committed for DPI development or that need to be addressed before DPI required components may be completed.


Tech Cmte Evaluation

Effort Evaluation (as a % of Tech Cmte Bandwidth):

  • Progress as appropriate based on DPI WP status and related output.
  • One 2-hour WebEx session per week starting after HIMSS '09 ... 2009.04.13
  • Primary focus on Phase I content (related DPI profiles are of secondary priority)
  • Target Phase I completion & publication for public comment by 2009.05.15.

Responses to Issues:

See italics in Risk and Open Issue sections

Candidate Editor:

Jan Wittenber
Retrieved from "http://wiki.ihe.net/index.php?title=PCD_Detailed_Profile_Proposal_2009_DPI-DnA&oldid=30035"