Difference between revisions of "PCD Detailed Profile Proposal 2009 DPI-SYM"

From IHE Wiki
Jump to navigation Jump to search
m (Updated)
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
__NOTOC__
+
{{TOCright}}
  
  
==1. Proposed Workitem: Device Point-of-care Integration - Symmetric Communication (DPI-SYM) ==
+
==Proposed Workitem: Device Point-of-care Integration - Symmetric Communication (DPI-SYM) ==
  
 
* Proposal Editor: Todd Cooper
 
* Proposal Editor: Todd Cooper
* Editor: ''<Name of candidate Lead Editor for the Profile, if known>''
+
* Editor: Todd Cooper
 
* 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, many participating systems not only report their internal information but also have need for discovering, connecting to and retrieving information from external sources.  This discovery and retrieval may be a one time occurrance (e.g., current patient weight), or it may be a persistent connection with specific quality of service requirements needed to support internal algorithmic functions.  The information can be from other systems around the point-of-care or from a remote system that is brokered / proxied to the DPI network.
 
Within the framework of Device Point-of-Care Integration (DPI) profiles, many participating systems not only report their internal information but also have need for discovering, connecting to and retrieving information from external sources.  This discovery and retrieval may be a one time occurrance (e.g., current patient weight), or it may be a persistent connection with specific quality of service requirements needed to support internal algorithmic functions.  The information can be from other systems around the point-of-care or from a remote system that is brokered / proxied to the DPI network.
Line 17: Line 17:
  
  
==3. Key Use Case==
+
==Key Use Case==
  
'''<use case with a physiological monitor, ventilator and infusion pump>'''
+
'''''Example #1:'''''  Medication delivery using vital signs feedback from a physiological monitor or ventilator:
 +
::* Pump uses respiration and heart rate information to enable/disable delivery of a medication
 +
::* Pump identifies the source(s) of the needed information and configures a link to receive continuous periodic updates.
 +
::* When the vital signs exceed a clinician-specified limit, an alert is generated and medication delivery disallowed
 +
::* When the vital signs fall back within the specified limites, medication delivery is enabled
  
 
Additional use cases include acute care CRRT (Continuous Renal Replacement Therapy) dialysis systems that not only report their status but also need to collect patient "fluids" information (in & out flows; e.g., from infusion pumps) so as to properly drive their calculations.
 
Additional use cases include acute care CRRT (Continuous Renal Replacement Therapy) dialysis systems that not only report their status but also need to collect patient "fluids" information (in & out flows; e.g., from infusion pumps) so as to properly drive their calculations.
  
==4. Standards & Systems==
+
==Standards & Systems==
  
 
:1. ISO/IEEE 11073 standards, including draft 11073-20302 Optional Package - Symmetric Communication  
 
:1. ISO/IEEE 11073 standards, including draft 11073-20302 Optional Package - Symmetric Communication  
Line 30: Line 34:
  
  
==5. Discussion==
+
==Technical Approach==
 
 
:1. This profile is one of the set of DPI profiles.  It is dependent on the (proposed) DPI-DnA and DPI-DR profiles.
 
 
 
:2. The associated standards are either in draft form or need some development.  Completion of this profile is dependent on completion of those standards.
 
 
 
:3. The draft 11073-20302 standard could be seen as overly heavy for applications where a device needs a simple parameter for display.
 
 
 
==5. 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===
Line 70: Line 60:
 
''<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.>''
 
''<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.>''
  
==6. Support & Resources==
+
==Support & Resources==
''<List groups that have expressed support for the proposal and resources that would be available to accomplish the tasks listed above.>''
+
 
 +
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 white paper.
 +
 
 +
 
 +
==Risks==
 +
Primary risk is the potential lack of standards that may be profiled to provide the required services.
 +
 
 +
==Open Issues==
  
==7. Risks==
+
:1. This profile is one of the set of DPI profiles.  It is dependent on the (proposed) DPI-DnA and DPI-DR profiles.
''<List technical or political risks that could impede successfully fielding the profile.>''
 
  
==8. Open Issues==
+
:2. The associated standards are either in draft form or need some developmentCompletion of this profile is dependent on completion of those standards.
''<Point out any key issues or design problemsThis will be helpful for estimating the amount of work and demonstrates thought has already gone into the candidate profile.>''
+
 
 +
:3. The draft 11073-20302 standard could be seen as overly heavy for applications where a device needs a simple parameter for display.
  
''<If there are no Open Issues at Evaluation Time, it is usually a sign that the proposal analysis and discussion has been incomplete.>''
 
  
==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 92: Line 105:
  
 
Candidate Editor:
 
Candidate Editor:
: TBA
+
: Todd Cooper
  
  
 
[[Category:PCD]][[Category:PCD DPI]]
 
[[Category:PCD]][[Category:PCD DPI]]

Latest revision as of 10:56, 4 February 2009


Proposed Workitem: Device Point-of-care Integration - Symmetric Communication (DPI-SYM)

  • Proposal Editor: Todd Cooper
  • Editor: Todd Cooper
  • 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, many participating systems not only report their internal information but also have need for discovering, connecting to and retrieving information from external sources. This discovery and retrieval may be a one time occurrance (e.g., current patient weight), or it may be a persistent connection with specific quality of service requirements needed to support internal algorithmic functions. The information can be from other systems around the point-of-care or from a remote system that is brokered / proxied to the DPI network.

This profile shall support those functions needed to achieve this bi-directional or "symmetric" communication between devices and systems in a DPI network.


Key Use Case

Example #1: Medication delivery using vital signs feedback from a physiological monitor or ventilator:

  • Pump uses respiration and heart rate information to enable/disable delivery of a medication
  • Pump identifies the source(s) of the needed information and configures a link to receive continuous periodic updates.
  • When the vital signs exceed a clinician-specified limit, an alert is generated and medication delivery disallowed
  • When the vital signs fall back within the specified limites, medication delivery is enabled

Additional use cases include acute care CRRT (Continuous Renal Replacement Therapy) dialysis systems that not only report their status but also need to collect patient "fluids" information (in & out flows; e.g., from infusion pumps) so as to properly drive their calculations.

Standards & Systems

1. ISO/IEEE 11073 standards, including draft 11073-20302 Optional Package - Symmetric Communication
2. HL7 and IHE Publish & Subscribe Standards / Profiles


Technical Approach

Existing actors

<Indicate what existing actors could be used or might be affected by the profile.>

New actors

<List possible new actors>


Existing transactions

<Indicate how existing transactions might be used or might need to be extended.>

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.>


Impact on existing integration profiles

<Indicate how existing profiles might need to be modified.>

New integration profiles needed

<Indicate what new profile(s) might need to be created.>


Breakdown of tasks that need to be accomplished

<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.>

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 white paper.


Risks

Primary risk is the potential lack of standards that may be profiled to provide the required services.

Open Issues

1. This profile is one of the set of DPI profiles. It is dependent on the (proposed) DPI-DnA and DPI-DR profiles.
2. The associated standards are either in draft form or need some development. Completion of this profile is dependent on completion of those standards.
3. The draft 11073-20302 standard could be seen as overly heavy for applications where a device needs a simple parameter for display.


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:

Todd Cooper