Difference between revisions of "PCD Detailed Profile Proposal 2009 DPI-SYM"
ToddCooper (talk | contribs) m (PCD Detailed Profile Proposal 2008 DPI-SYM moved to PCD Detailed Profile Proposal 2009 DPI-SYM: Correct year) |
ToddCooper (talk | contribs) m (Removed section #'s and added ToC back) |
||
Line 1: | Line 1: | ||
− | + | {{TOCright}} | |
− | == | + | ==Proposed Workitem: Device Point-of-care Integration - Symmetric Communication (DPI-SYM) == |
* Proposal Editor: Todd Cooper | * Proposal Editor: Todd Cooper | ||
Line 10: | Line 10: | ||
* Domain: PCD | * 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. | 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: | ||
− | == | + | ==Key Use Case== |
'''<use case with a physiological monitor, ventilator and infusion pump>''' | '''<use case with a physiological monitor, ventilator and infusion pump>''' | ||
Line 23: | Line 23: | ||
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. | ||
− | == | + | ==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 30: | ||
− | == | + | ==Discussion== |
:1. This profile is one of the set of DPI profiles. It is dependent on the (proposed) DPI-DnA and DPI-DR profiles. | :1. This profile is one of the set of DPI profiles. It is dependent on the (proposed) DPI-DnA and DPI-DR profiles. | ||
Line 38: | Line 38: | ||
:3. The draft 11073-20302 standard could be seen as overly heavy for applications where a device needs a simple parameter for display. | :3. The draft 11073-20302 standard could be seen as overly heavy for applications where a device needs a simple parameter for display. | ||
− | == | + | ==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.>'' | ''<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.>'' | ||
Line 70: | Line 70: | ||
''<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.>'' | ||
− | == | + | ==Support & Resources== |
''<List groups that have expressed support for the proposal and resources that would be available to accomplish the tasks listed above.>'' | ''<List groups that have expressed support for the proposal and resources that would be available to accomplish the tasks listed above.>'' | ||
− | == | + | ==Risks== |
''<List technical or political risks that could impede successfully fielding the profile.>'' | ''<List technical or political risks that could impede successfully fielding the profile.>'' | ||
− | == | + | ==Open Issues== |
''<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.>'' | ''<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.>'' | ''<If there are no Open Issues at Evaluation Time, it is usually a sign that the proposal analysis and discussion has been incomplete.>'' | ||
− | == | + | ==Tech Cmte Evaluation== |
''<The technical committee will use this area to record details of the effort estimation, etc.>'' | ''<The technical committee will use this area to record details of the effort estimation, etc.>'' |
Revision as of 13:38, 29 January 2009
Proposed Workitem: Device Point-of-care Integration - Symmetric Communication (DPI-SYM)
- Proposal Editor: Todd Cooper
- Editor: <Name of candidate Lead Editor for the Profile, if known>
- 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
<use case with a physiological monitor, ventilator and infusion pump>
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
Discussion
- 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.
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
<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
<List groups that have expressed support for the proposal and resources that would be available to accomplish the tasks listed above.>
Risks
<List technical or political risks that could impede successfully fielding the profile.>
Open Issues
<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.>
Tech Cmte Evaluation
<The technical committee will use this area to record details of the effort estimation, etc.>
Effort Evaluation (as a % of Tech Cmte Bandwidth):
- 35% for ...
Responses to Issues:
- See italics in Risk and Open Issue sections
Candidate Editor:
- TBA