PCD Detailed Profile Proposal 2009 DPI-DR

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

The Problem

As a result of the lack of implementation of existing standards for point-of-care (“PoC”) medical device communication, either the information is not automatically captured and integrated into a patient’s overall health care informatics context or doing so requires custom adaptors, translators and other intermediate systems, often resulting in information loss and a lack of timely and semantically consistent device data. This profile focuses on interoperation of point-of-care medical devices, primarily used in acute health care contexts and typically patient connected, including physiological monitors, infusion pumps and ventilators. The scope is limited to multiple devices connected to a single patient (not multiple patient contexts).

Since many of these devices are regulated by national agencies (e.g., the Food and Drug Administration in the U.S.A.), the profile shall support devices and systems that are required to comply to such approval and oversight processes. This support shall involve both trying to ensure that no profile content unnecessarily hinders the regulatory process, as well as providing for systems that must meet safety and efficacy requirements (e.g., the timely and reliable annunciation of certain life critical alarms). Whether or not a given device is considered a “regulated medical device”, is not addressed by this profile. Note: this profile could support integration of both regulated and non-regulated devices into a single functional environment.

Within the framework of Device Point-of-Care Integration (DPI) profiles, a basic function is for one device to report patient physiological data and supporting information concerning the technical functioning of the device to one or more data receiving endpoints. These may be other DPI patient care devices or, through a gateway, a non-DPI information systems. This is the scope of this Device Point-of-Care Data Reporting (DPI-DR) proposal. Device network discovery and association falls in the scope of the related Device Point-of-Care Discovery and Association (DPI-DnA) proposal. Use cases which involve a patient care device discovering, connecting to and retrieving information from external sources are the scope of the related Device Point-of-Care Symmetric Communication proposal.

Real-time information communication shall also be supported by this profile, including waveforms and guaranteed communication of high-priority medical alarms. Real-time in this context shall conform to the definition used by the PCD domain, namely that the actors are able to exchange data in a time frame appropriate to the physiologic function being measured, displayed or affected (controlled), typically milliseconds to seconds. This shall include multiple waveform feeds (e.g., 12-leads of ECG sampled at 10ms) that are streamed across a link to one or more systems for analysis and display. In addition to waveform data, annotation and derived values may also be communicated in real-time. In the case of alarms, not only must reliable delivery be provided, but also standardized semantics that support “smart” alarm and alarm management algorithms and meet best practices guidelines and specific regulatory requirements, both in terms of information content and timeliness of delivery. Semantic interoperability is also paramount, requiring the use of an open standards-based terminology for medical device informatics. Concepts should include both medical or patient information (e.g., monitored expiratory airway pressure or rectal body temperature), as well as technical device information (e.g., low battery level or air-in-line alarm condition). As a general objective, all information that is presented on a device’s user interface, should be supportable using this profile, though given the uniqueness of some semantics, the communicated terms may be extensions to those provided in a controlled, standardized vocabulary.

This profile is also related to the Patient Identification profile, in that there must be a consistent way of uniquely identifying each instance of a device and the patient with which it is associated, as well as how to manage that binding when PnP devices are brought into and taken out of the PoC context. This identification must be “globally unique” – it must apply no matter where it is used in the world. Applications such as telemedicine necessitate this requirement.

To summarize, this profile supports real-time, plug-and-play connectivity between medical devices and other devices and systems, from the connector to the communication services to the abstract semantics, in a manner that enables multi-vendor multi-modality interoperation.

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

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 on device network discovery and association, 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.

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

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

Patient Care Device – This actor represents a generic point-of-care medical device and includes a unique device identifier, device modality identification, generic status information (e.g., operational and power status).

Non-Regulated [Patient Care] Device – This is a device that can connect to the same PnP network but is not a regulated medical device.

Patient Care Device Client – This is a device or system that acquires information from one or more devices.

PCD Data Broker – This is an agent that can act as a medical device proxy, providing information to one or more PCD Clients.

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

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.

Institutions that have been participating in the IHE DPI groups include ...

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.

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.

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