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: John Rhoads
- Date: N/A (Wiki keeps history)
- Version: N/A (Wiki keeps history)
- Domain: PCD
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:
|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).
Refer to the DPI white paper and IHE PCD Technical Framework, Volume 2, [TBD] for a detailed description. The following diagram shows the relationships between actors in the PCD.
This profile forms part of a set of related profiles: it is dependent on Device Point-of-Care Discovery and Association (DPI-DnA) for the network discovery of, and association with, devices.
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.
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.
Maintain Time (IHE ITI-Consistent Time).
New transactions (standards used)
Retrieve Device Data – TBD.
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
Breakdown of tasks that need to be accomplished
- Determine detailed requirements for use cases, considering clinical needs and also technical characteristics of the medical devices to be used.
- Determine selection of standards and implementation options to be used, including connection, networking, semantics and information model, with reference to published and draft ISO/IEEE 11073 standards.
- Document the chosen technical approaches in a profile, to an implementable level of detail.
Support & Resources
The following organizations have either actively participated or indicated interest in DPI profile development activities:
- Baystate Health
- Breakthrough Solutions Foundry
- Improvement Technologies
- Kaiser Permanente
- Philips Healthcare
- Respironics (Philips)
It is anticipated that these companies will support at some level the development of the white paper.
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.
The IHE DPI groups have had active participation in preparing conformance and test tools from individuals at the National Institute for Standards and Technology, medical device vendors and independent consultants.
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.
A second phase would concentrate on dynamic configuration coordination between device and manager, increasing the parameter set, and supporting alarms.
The third phase would involve real-time waves.
Unlike the HL7-based approach taken in typical IHE profiles, this profile uses technology unfamiliar to many IHE participants. This suggests that detailed documentation, sample code and test tooling will be quite important in building participation.
Tech Cmte Evaluation
Effort Evaluation (as a % of Tech Cmte Bandwidth):
- Progress as appropriate based on DPI WP status and related output.
- One 2-hour WebEx session per week starting after HIMSS '09 ... 2009.04.13
- Primary focus on Phase I content (related DPI profiles are of secondary priority)
- Target Phase I completion & publication for public comment by 2009.05.15.
Responses to Issues:
- See italics in Risk and Open Issue sections
- John Rhoads