PCD Detailed Profile Proposal 2009 DPI-SYM

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

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

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

4. Standards & Systems

1. ISO/IEEE 11073 standards, including draft 11073-20302 Optional Package - Symmetric Communication

2. HL7 and IHE Publish & Subscribe Standards / Profiles

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

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

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

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

<List technical or political risks that could impede successfully fielding the profile.>

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

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