PCD Detailed Profile Proposal 2009 DPI-DnA: Difference between revisions

From IHE Wiki
Jump to navigation Jump to search
← Older edit
ToddCooper (talk | contribs)
1,843 edits
ToddCooper (talk | contribs)
1,843 edits
m Updated
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
__NOTOC__
{{TOCright}}




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


* Proposal Editor: Todd Cooper, Jan Wittenber
* Proposal Editor: Todd Cooper, Jan Wittenber
* Editor: ''<Name of candidate Lead Editor for the Profile, if known>''
* Editor: Jan Wittenber
* Date:    N/A (Wiki keeps history)
* Date:    N/A (Wiki keeps history)
* Version: N/A (Wiki keeps history)
* Version: N/A (Wiki keeps history)
* Domain: PCD
* Domain: PCD


==2. The Problem==
==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.  
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.  
Line 17: Line 17:




==3. Key Use Case==
==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.
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.




==4. Standards & Systems==
==Standards & Systems==


:1. ISO/IEEE 11073 standards for medical device communication
:1. ISO/IEEE 11073 standards for medical device communication
Line 29: Line 29:




==5. Discussion==
==Discussion==


:1. This profile is part of a set of DPI profiles that support device conneectivity, especially plug-and-play communication.
:1. This profile is part of a set of DPI profiles that support device conneectivity, especially plug-and-play communication.
Line 135: Line 135:
::'''<sup>3</sup>'''  Wired &harr; Wireless inter-mode may be deployed with suitable precoordination of switching method
::'''<sup>3</sup>'''  Wired &harr; Wireless inter-mode may be deployed with suitable precoordination of switching method


==5. Technical Approach==
==Technical Approach==
''<This section can be very short but include as much detail as you like.  The Technical Committee will flesh it out when doing the effort estimation.>''
 
''<Outline how the standards could be used/refined to solve the problems in the Use Cases.  The Technical Committee will be responsible for the full design and may choose to take a different approach, but a sample design is a good indication of feasibility.>''
 
''<If a phased approach would make sense indicate some logical phases.  This may be because standards are evolving, because the problem is too big to solve at once, or because there are unknowns that won’t be resolved soon.>''
 


===Existing actors===
===Existing actors===
''<Indicate what existing actors could be used or might be affected by the profile.>''
No existing actors will be affected by this profile.


===New actors===
===New actors===
''<List possible 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===
===Existing transactions===
''<Indicate how existing transactions might be used or might need to be extended.>''
No existing transactions should be affected by this profile.


===New transactions (standards used)===
===New transactions (standards used)===
''<Describe possible new transactions (indicating what standards would likely be used for each.  Transaction diagrams are very helpful here.  Feel free to go into as much detail as seems useful.>''
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===
===Impact on existing integration profiles===
''<Indicate how existing profiles might need to be modified.>''
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==


===New integration profiles needed===
The following organizations have either actively participated or indicated interest in DPI profile development activities:
''<Indicate what new profile(s) might need to be created.>''


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


===Breakdown of tasks that need to be accomplished===
It is anticipated that these companies will support at some level the development of the profile supplement.
''<A list of tasks would be helpful for the technical committee who will have to estimate the effort required to design, review and implement the profile.>''
 
==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.


==6. Support & Resources==
''<List groups that have expressed support for the proposal and resources that would be available to accomplish the tasks listed above.>''


==7. Risks==
==Open Issues==
''<List technical or political risks that could impede successfully fielding the profile.>''


==8. Open Issues==
Besides the activities and risks identified elsewhere in this proposal, the following issues also need to be resolved:
''<Point out any key issues or design problems.  This will be helpful for estimating the amount of work and demonstrates thought has already gone into the candidate profile.>''


''<If there are no Open Issues at Evaluation Time, it is usually a sign that the proposal analysis and discussion has been incomplete.>''
:* 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.


==9. Tech Cmte Evaluation==


''<The technical committee will use this area to record details of the effort estimation, etc.>''
==Tech Cmte Evaluation==


Effort Evaluation (as a % of Tech Cmte Bandwidth):
Effort Evaluation (as a % of Tech Cmte Bandwidth):
:* 35% for ...
:* 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:
Responses to Issues:
Line 189: Line 231:


Candidate Editor:
Candidate Editor:
: TBA
: Jan Wittenber




[[Category:PCD]][[Category:PCD DPI]]
[[Category:PCD]][[Category:PCD DPI]]

Latest revision as of 10:23, 4 February 2009


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"