PCD Brief Profile Proposal 2008 DPI-DR

From IHE Wiki
Revision as of 19:18, 11 November 2008 by Jrhoads (talk | contribs)
Jump to navigation Jump to search


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

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.