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

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

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 p(DEC) 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.

Alarm Communication Management - Alarm Reporter

This actor could be appropriate for some alarm and technical alert export purposes. As with the DEC profile, this actor was purpose-built for export of device data, so should need little modification.

New actors

Device Point-of-Care Manager

An actor providing integration services including device discovery and association, data communications and control functions among patient care devices at the point-of-care, and brokering communications between the devices and external systems.

Device Point-of-Care Agent

An actor providing integration services in a an individual patient care device through communications with a Device Point-Of-Care Manager.

Existing transactions

See discussion under "Existing Actors".

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

Key members of the IEEE 11073 Medical Device Communications working group have been actively participating in IHE DPI and have stated they see useful synergy between a profiling and prototyping effort by IHE DPI and completing and filling gaps in the standards.

Representatives of Draeger and Philips have been investing resources in development in the IHE DPI working group.

7. Risks

The technical risks of this proposed project seem manageable as the standards proposed to be used are quite well-developed for the data reporting aspect of DPI.

As with all collaborative profiling projects, even where the long-term benefits of the proposed work are self-evident, as with an open standards-based patient care device integration, resource limitations and uncertainty about possible effects on proprietary interests make it challenging to move such projects forward.

To mitigate these risks, this profile should be divided into a progressive, phased series of useful subsets to be prototyped and demonstrated. As other parties see technical feasibility, and results indicating practical progress towards fulfilling the use cases, participation will increase.

An initial phases would be simple reporting of a fixed precoordinated set of discrete parameters.

8. Open Issues

Unlike the HL7-based approach taken in typical IHE profiles, this profile uses technology that typical IHE participants have little detailed technical knowledge of. This suggests that documentation, sample code and test tooling may be quite important in building participation.

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