Difference between revisions of "PCD Detailed Profile Proposal 2009 DPI-DR"

From IHE Wiki
Jump to navigation Jump to search
m (Updated)
 
(36 intermediate revisions by 2 users not shown)
Line 1: Line 1:
−
__NOTOC__
+
{{TOCright}}
  
  
−
==1. Proposed Workitem: Device Point-of-care Integration - Data Reporting (DPI-DR)==
+
==Proposed Workitem: Device Point-of-care Integration - Data Reporting (DPI-DR)==
  
 
* Proposal Editors: Todd Cooper, John Rhoads
 
* Proposal Editors: Todd Cooper, John Rhoads
−
* Editor: ''<Name of candidate Lead Editor for the Profile, if known>''
+
* Editor: John Rhoads
 
* Date:    N/A (Wiki keeps history)
 
* Date:    N/A (Wiki keeps history)
 
* Version: N/A (Wiki keeps history)
 
* Version: N/A (Wiki keeps history)
 
* Domain: PCD
 
* Domain: PCD
  
−
==2. The Problem==
+
==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.
+
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.
  
−
==3. Key Use Cases==
+
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 [[PCD_Detailed_Profile_Proposal_2009_DPI-DnA|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 [[PCD_Detailed_Profile_Proposal_2009_DPI-SYM|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 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.  
Line 21: Line 31:
 
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 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 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_Profile_Alarm_Communication_Management|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 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_Profile_Medical_Equipment_Management_(MEM)|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).
+
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 ([[PCD_Detailed_Profile_Proposal_2009_DPI-SYM|DPI-SYM]]).
  
−
==4. Basic Technical Requirements of Profile==
+
==Basic Technical Requirements of Profile==
 
=== Types of Information ===
 
=== Types of Information ===
 
The information reporting under DPI-DR may include:
 
The information reporting under DPI-DR may include:
Line 55: Line 65:
 
|}
 
|}
  
−
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).  
+
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, [[PCD_Detailed_Profile_Proposal_2009_DPI-DnA|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.
 
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.
Line 62: Line 72:
  
 
Since DPI-DR may be used to support providing PCD services outside the DPI environment, specifically  
 
Since DPI-DR may be used to support providing PCD services outside the DPI environment, specifically  
−
PCD Device Enterprise Communications for parameter data,
+
[[PCD_Profile_DEC_Overview|PCD Device Enterprise Communications]] for parameter data,
−
PCD Alarm Communications Management for alarm data,
+
[[PCD_Profile_Alarm_Communication_Management|PCD Alarm Communications Management]] for alarm data,
 
its design and capability must be congruent with the needs of these services.
 
its design and capability must be congruent with the needs of these services.
  
−
==5. Standards & Systems==
+
==Standards & Systems==
  
 
: Device Enterprise Communications. IHE PCD Technical Framework vols. 1 & 2.
 
: Device Enterprise Communications. IHE PCD Technical Framework vols. 1 & 2.
Line 82: Line 92:
 
: CEN 13735 (association control, currently being migrated to ISO/IEEE 11073-202xx standards).
 
: CEN 13735 (association control, currently being migrated to ISO/IEEE 11073-202xx standards).
  
 +
==Technical Approach==
 +
 +
Refer to the [[PCD_Detailed_Profile_Proposal_2009_DPI_WP|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 [[PCD_Detailed_Profile_Proposal_2009_DPI-DnA|Device Point-of-Care Discovery and Association (DPI-DnA)]] for the network discovery of, and association with, devices.
 +
 +
[[Image:PCD-DPI-DR.jpg]]
 +
 +
===Existing actors===
 +
 +
'''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.
  
−
==5. Technical Approach==
+
'''Patient Care Device Client'''  – This is a device or system that acquires information from one or more devices.   
−
''<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.>''
+
'''PCD Data Broker''' – This is an agent that can act as a medical device proxy, providing information to one or more PCD Clients.
  
−
''<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.>''
+
===Existing transactions===
−
: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.
+
'''Maintain Time''' (IHE ITI-Consistent Time).
  
 +
===New transactions (standards used)===
 +
'''Retrieve Device Data''' – TBD.
  
 +
===Impact on existing integration profiles===
  
−
===Existing actors===
+
For the reasons given above under "Existing Actors", little change is expected to be required in existing PCD integration profiles.
  
−
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.
+
===New integration profiles needed===
  
−
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 because
+
TBD
  
−
Device Enterprise Communications - Device Observation Consumer
+
===Breakdown of tasks that need to be accomplished===
  
−
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.
+
#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.
  
−
===New actors===
+
==Support & Resources==
−
''<List possible new actors>''
 
  
 +
The following organizations have either actively participated or indicated interest in DPI profile development activities:
  
−
===Existing transactions===
+
::* Baystate Health
−
''<Indicate how existing transactions might be used or might need to be extended.>''
+
::* Breakthrough Solutions Foundry
 +
::* Cardinal/VIASYS
 +
::* Draeger
 +
::* FDA
 +
::* Hospira
 +
::* Improvement Technologies
 +
::* Kaiser Permanente
 +
::* LiveData
 +
::* NIST
 +
::* Philips Healthcare
 +
::* Respironics (Philips)
  
−
===New transactions (standards used)===
+
It is anticipated that these companies will support at some level the development of the white paper.
−
''<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.>''
 
  
 +
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.
  
−
===Impact on existing integration profiles===
+
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.
  
−
For the reasons given above under "Existing Actors", little change is expected to be required in existing PCD integration profiles.
+
==Risks==
  
−
===New integration profiles needed===
+
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.
−
''<Indicate what new profile(s) might need to be created.>''
 
  
 +
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.
  
−
===Breakdown of tasks that need to be accomplished===
+
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.  
−
''<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==
+
An initial phases would be simple reporting of a fixed precoordinated set of discrete parameters.
−
''<List groups that have expressed support for the proposal and resources that would be available to accomplish the tasks listed above.>''
 
  
−
==7. Risks==
+
A second phase would concentrate on dynamic configuration coordination between device and manager, increasing the parameter set, and supporting alarms.
−
''<List technical or political risks that could impede successfully fielding the profile.>''
 
  
−
==8. Open Issues==
+
The third phase would involve real-time waves.
−
''<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.>''
+
==Open Issues==
  
−
==9. Tech Cmte Evaluation==
+
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.
  
−
''<The technical committee will use this area to record details of the effort estimation, etc.>''
+
==Tech Cmte Evaluation==
  
 
Effort Evaluation (as a % of Tech Cmte Bandwidth):
 
Effort Evaluation (as a % of Tech Cmte Bandwidth):
−
:* 35% for ...
+
:* 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:
 
Responses to Issues:
Line 154: Line 193:
  
 
Candidate Editor:
 
Candidate Editor:
−
: TBA
+
: John Rhoads
 +
 
 +
----
 +
 
 +
 
 +
See also:
 +
 
 +
[[PCD_Profile_Device_Point-of-Care_Integration_%28DPI%29|PCD DPI Home]] | [[Patient Care Devices|PCD Home]] | [[:Category: PCD Meeting|PCD Recent Meetings Page]] | [[:Category:PCD_Meeting_Archive|PCD Meeting Archive]]
  
  
−
[[Category:PCD]]
+
[[Category:PCD]] [[Category:PCD DPI]]

Latest revision as of 10:27, 4 February 2009


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

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

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.

PCD-DPI-DR.jpg

Existing actors

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

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

TBD

Breakdown of tasks that need to be accomplished

  1. Determine detailed requirements for use cases, considering clinical needs and also technical characteristics of the medical devices to be used.
  2. 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.
  3. 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
  • Cardinal/VIASYS
  • Draeger
  • FDA
  • Hospira
  • Improvement Technologies
  • Kaiser Permanente
  • LiveData
  • NIST
  • 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.

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.

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.

Open Issues

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

Candidate Editor:

John Rhoads


See also:

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

Retrieved from "http://wiki.ihe.net/index.php?title=PCD_Detailed_Profile_Proposal_2009_DPI-DR&oldid=30036"