PCD Detailed Profile Proposal 2009 DPI-DR

1. Proposed Workitem: Device Point-of-care Integration - Data Reporting (DPI-DR)

• Proposal Editors: Todd Cooper, John Rhoads
• 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, a basic function is for one device to report its information to one or more data receiving endpoints. These may be other DPI patient care devices or, through a gateway, a non-DPI information systems.

3. Key Use Cases

A medical device is connected to a patient in ICU. It automatically connects to the point-of-care network and provides its information both for local and remote viewing.

A medical device connected to a patient provides information for a clinical information system, general electronic medical record system, or event recording system.

A medical device connected to a patient provides real-time notification of physiological alarm conditions with timestamps and full supporting detail for display by an acute-care dashboard display or dispatch through a paging system. In this case, DPI data reporting may be supporting a more extensive system using PCD Alarm Communication Management.

A medical device whether connected to a patient, or not, provides device identification, maintenance and calibration status to a system notifying hospital biomedical engineers of work needing to be done. In this case, DPI data reporting may be supporting a more extensive system using PCD Medical Equipment Management.

A medical device connected to a patient provides one or more physiological measurements to another medical device for inclusion in combined displays or calculations. This borders on the use cases and scope of DPI Symmetric Communication (DPI-SYM).

4. Basic Technical Requirements of Profile

Types of Information

The information reporting under DPI-DR may include:

Data Type	Examples
Parameters	heart rate (numeric), ECG rhythm type (enumeration)
Operational settings	Ventilator mode (enumeration), PEEP setting (numeric)
Alarm conditions	Heart rate high, ECG lead off
Waveforms	ECG lead II
Annotations	Normal beat, premature ventricular contraction
Device configuration	Unique device identifier, last calibration date for specific measurement

This profile shall support those functions needed to provide basic data reporting by systems in a DPI environment, including communications transport profiles (but for discovery and association see related DPI project DPI-DnA).

Physiological and technical information must be provided along with metadata needed for interpretation, including standard units of measure, data validity indication, unique identifiers for the source device and the specific component within the device that is the source of the particular parameter, available data concerning association of device with a location and a patient.

The profile must provide means for the receiving system to specify measurement interval and parameter selection.

Since DPI-DR may be used to support providing PCD services outside the DPI environment, specifically PCD Device Enterprise Communications for parameter data, PCD Alarm Communications Management for alarm data, its design and capability must be congruent with the needs of these services.

5. Standards & Systems

Device Enterprise Communications. IHE PCD Technical Framework vols. 1 & 2.

ISO/IEEE 11073-10201 Domain Information Model

ISO/IEEE 11073-10101 Nomenclature

ISO/IEEE 11073-20101 Application Profile - Base Standard

ISO/IEEE 11073-30200 Transport Profile - Cable Connected

ISO/IEEE 11073-30300 Transport Profile - Infrared

CEN 13735 (association control, currently being migrated to ISO/IEEE 11073-202xx standards).

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

1. This profile is one of a set of DPI profiles, some of which are mentioned in the above text. In particular, it is directly dependent on the DPI-DnA profile (proposed).

2. For prototyping and implementation purposes, this profile should be divided into a progressive, phased series of useful subsets. An initial set might be simple reporting of a fixed precoordinated set of discrete parameters.

Existing actors

It is expected that typical systems will include communications to external enterprise systems and so will implement existing actors in the Device Enterprise Communications profile for this purpose with little or no change in the profile because the profile is already well-matched to the requirement.

Device Enterprise Communications - Device Observation Reporter

The PCD Technical Framework defines this actor to report device data to the enterprise, relying heavily on IEEE 11073 semantics and information model. Consequently a device point-of-care integration system would logically implement this actor for transmitting device data to enterprise systems, with little or no impact on current definition of the actor.

Device Enterprise Communications - Device Observation Consumer

Some device point-of-care systems may use data received from enterprise systems such as demographic data or lab measurements. These systems would implement the Device Observation Consumer actor. Again, few or no changes in definition would be expected due to the interface being designed for the transmission of device data.

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

For the reasons given above under "Existing Actors", little change is expected to be required in existing PCD integration profiles.

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

---

See also:

PCD DPI Home | PCD Home | PCD Recent Meetings Page | PCD Meeting Archive