Difference between revisions of "PCD Profile DEC Overview"

From IHE Wiki
Jump to navigation Jump to search
m
(30 intermediate revisions by 7 users not shown)
Line 1: Line 1:
Device Enterprise Communication
+
'''Device Enterprise Communication (DEC)''' communicates device data to Enterprise applications (CDS, CDRs, EMRs, etc.).
  
 
__TOC__
 
__TOC__
  
 
==Summary==
 
==Summary==
{{{2|''<Describe the profile in about a paragraph using user-oriented language.>''}}}
 
  
''<Include a simple graphic that, at a glance, gives an impression of what the profile doesSee [[Help:Contents#Tips_.26_Tricks| Help - Tips and Tricks]] for details on including an image/graphic.>''
+
This profile addresses the need for consistent communication of PCD data to the enterprise. Recipients of enterprise PCD data include, but are not limited to, Clinical Decision Support applications, Clinical Data Repositories (CDRs), Electronic Medical Record applications (EMRs), and Electronic Health Records (EHRs).  Examples of patient care devices included in this profile include, but are not limited to, vital signs monitors, point of care blood analyzers, infusion pumps, point of care glucometers, anesthesia systems, ventilators, and dialysis systems.
 +
 
 +
The Device Enterprise Communication profile provides an optional "Publish/Subscribe" mechanism for applications to negotiate which PCD messages are communicated to a given application based on negotiated predicatesPublish and subscribe refers to the ability of one system, the publisher, to offer a data stream that can be sent to recipient systems upon subscription.
 +
 
 +
This profile also provides an option to address the binding of the patient identification with the data from a PCD.
  
 
==Benefits==
 
==Benefits==
  
 +
 +
In a recent HIMSS survey of requirements for Patient Care Device (PCD) the respondents identified Enterprise Sharing of PCD data as their highest priority. Benefits of DEC include shortening decision time, increasing productivity, minimizing transcription errors, and obtaining increased contextual information regarding the data.
 +
 +
Consuming all of the data from a collection of point-of-care devices (PCDs) at the rates at which meaningful parametric PCD data can be produced has been described as “drinking from a fire hose”.  The Device Enterprise Communication (DEC) profile provides an optional publish/subscribe mechanism for applications to negotiate which PCD messages are communicated to a given application based on negotiated predicates.
 +
 +
With regard to the Patient Identity Binding option, automation of the entry of patient identification to patient care devices has the potential for improving throughput, reducing errors, increasing safety and efficiency and increasing the effectiveness of devices and drugs.  The current Profile, by grouping the DOR Actor with the ITI-Patient Demographics Consumer Actor, provides for pick-list selection of patient identity based on known demographic information.
  
 
==Details==
 
==Details==
 +
The Device Enterprise Communication (DEC) Integration Profile supports communication of vendor independent, multi-modality Patient Care Device data to Enterprise Applications using consistent semantics. It accomplishes this by mapping PCD data from proprietary syntax and semantics into a single syntactic and semantic representation for communication to the enterprise The PCD data is time stamped with a consistent enterprise time. Options are provided to allow applications to filter particular PCD data of interest.  DEC functions by passing transactions between actors that fulfill the following roles:
 +
 +
[[Image:PCD_DEC_Actors_Diag_r1.png|thumb|DEC (basic) Actors]]
 +
 +
'''The Device Observation Reporter''' (DOR) actor receives data from PCDs, including those based on proprietary formats, and maps the received data to transactions providing consistent syntax and semantics.
 +
 +
'''The Device Observation Consumer''' (DOC) is the actor responsible for receiving PCD data from the Device Observation Reporter, the Device Observation Filter, or both.
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
[[Image:PCD_DEC_SPD_Actors_Diag_r2.png|thumb| DEC-SPD Actors]]
 +
 +
'''The Device Observation Filter''' (DOF) actor is responsible for providing optional PCD data filtering services based on publish/subscribe predicates negotiated with client applications implementing the Device Observation Consumer.
 +
 +
 +
 +
 +
[[Image:PCD_DEC_PIB_Actors_Diag_r1.png|thumb| DEC-PIB Actors]]
 +
 +
'''Patient Demographics Consumer''' – (PDC) For implementations using ITI Patient Demographics Query (ITI-21), the Patient Demographics Consumer is defined under ITI TF-2:3.21.2 as  an Actor that requests a list of patients matching a minimal set of demographic data from the Patient Demographics Supplier Actor and populates its attributes with the information received.  For implementations using ITI Patient Administration Management / Patient Identity Feed (ITI-30), the Patient Demographics Consumer is defined under ITI PAM Supplement: 14.2 as an Actor that receives patient demographics from a broadcast Patient Demographics Supplier Actor.  Full details on the use of these actors are found in the [[Frameworks#IHE_IT_Infrastructure_Technical_Framework | ITI Technical Framework]].
  
''<Detailed discussion of what the profile does and how it works>''
 
  
 
==Systems Affected==
 
==Systems Affected==
''<List (in user terms) systems that would be likely candidates for implementing this profile, e.g. RIS, PACS, HIS, CAD Workstation, etc. >''
 
  
==References==
+
Patient care device data includes periodic physiologic data (heart rate, invasive blood pressure, respiration rate, etc.), aperiodic physiologic data (non-invasive blood pressure, patient weight, cardiac output, etc.), CLIA waived (or equivalent international waiver) point-of-care laboratory tests (i.e. home blood glucose, etc.), and continuous data (ECG and invasive blood pressure waveforms).  It must include patient identity data and may include contextual data such as caregiver identification, and patient care device configuration information.
 +
 
 +
The Device Enterprise Communication (DEC) profile addresses the need for consistent communication of periodic, aperiodic, and CLIA waived patient care device data to the enterprise. Enterprise recipients of patient care device data include, but are not limited to, Clinical Decision Support applications, Clinical Data Repositories (CDRs), Electronic Medical Record (EMRs) applications, and Electronic Health Records (EHRs).
  
''<List References (good and bad) (with link if possible) to Journal Articles that mention IHE's work (and hopefully include some analysis) >''
+
The following examples describe which actors typical systems might be expected to support. This is not intended to define requirements, but rather to provide illustrative examples.
 +
* A general purpose observation reporting gateway which combines the Device Observation Reporter and the Device Observation Filter.
 +
* A clinical decision support application which combines the Device Observation Consumer and Device Observation Filter.
 +
* A patient care device which bundles the Device Observation Reporter and the Device Observation Filter.
  
 
==See Also==
 
==See Also==
Profile Status: [[Comments| Final Text]] ''<Replace Final Text with Trial Implementation or Public Comment as appropriate.>''
+
Profile Status: [[Comments| Final Text]]  
  
The [[Frameworks#IHE {{{4|Radiology}}} Technical Framework| {{{4|Radiology}}} Technical Framework]] is the official master document for this Profile.  
+
The [[Frameworks#IHE {{{4|Patient Care Devices}}} Technical Framework| {{{4|Patient Care Devices}}} Technical Framework]] is the official master document for this Profile.  
  
''<Replace Radiology Technical Framework with the Trial Implementation Supplement or Public Comment Supplement as appropriate.>''
+
<!--
  
 
''<Replace the Template links below with links to the actual pages for the Profile>''
 
''<Replace the Template links below with links to the actual pages for the Profile>''
Line 36: Line 78:
  
 
The [[{{{3|Profile Implementation Template}}}]] provides additional information about implementing this Profile in software.
 
The [[{{{3|Profile Implementation Template}}}]] provides additional information about implementing this Profile in software.
 +
 +
-->
 +
 +
===References===
 +
Medical device interoperability and the Integrating the Healthcare Enterprise (IHE) initiative
 +
JG Rhoads, T Cooper, F Fuchs, P Schluter… - AAMI IT Horiz, 2010, Pp. 22-27 -
 +
[http://www.aami.org/publications/ITHorizons/2010/21-27_MDI_Rhoads.pdf PDF]
 +
  
 
This page is based on the [[Profile Template]]
 
This page is based on the [[Profile Template]]
  
''<Delete this Category Templates line since your Profile page is no longer a template.>'' [[Category:{{{3|Templates}}}]]
+
 
  
 
[[Category:Profiles]]
 
[[Category:Profiles]]
 +
[[Category:PCD]]
 +
[[Category:PCD Profile]]
 +
[[Category:HL7v2]]

Revision as of 13:33, 24 July 2017

Device Enterprise Communication (DEC) communicates device data to Enterprise applications (CDS, CDRs, EMRs, etc.).

Summary

This profile addresses the need for consistent communication of PCD data to the enterprise. Recipients of enterprise PCD data include, but are not limited to, Clinical Decision Support applications, Clinical Data Repositories (CDRs), Electronic Medical Record applications (EMRs), and Electronic Health Records (EHRs). Examples of patient care devices included in this profile include, but are not limited to, vital signs monitors, point of care blood analyzers, infusion pumps, point of care glucometers, anesthesia systems, ventilators, and dialysis systems.

The Device Enterprise Communication profile provides an optional "Publish/Subscribe" mechanism for applications to negotiate which PCD messages are communicated to a given application based on negotiated predicates. Publish and subscribe refers to the ability of one system, the publisher, to offer a data stream that can be sent to recipient systems upon subscription.

This profile also provides an option to address the binding of the patient identification with the data from a PCD.

Benefits

In a recent HIMSS survey of requirements for Patient Care Device (PCD) the respondents identified Enterprise Sharing of PCD data as their highest priority. Benefits of DEC include shortening decision time, increasing productivity, minimizing transcription errors, and obtaining increased contextual information regarding the data.

Consuming all of the data from a collection of point-of-care devices (PCDs) at the rates at which meaningful parametric PCD data can be produced has been described as “drinking from a fire hose”. The Device Enterprise Communication (DEC) profile provides an optional publish/subscribe mechanism for applications to negotiate which PCD messages are communicated to a given application based on negotiated predicates.

With regard to the Patient Identity Binding option, automation of the entry of patient identification to patient care devices has the potential for improving throughput, reducing errors, increasing safety and efficiency and increasing the effectiveness of devices and drugs. The current Profile, by grouping the DOR Actor with the ITI-Patient Demographics Consumer Actor, provides for pick-list selection of patient identity based on known demographic information.

Details

The Device Enterprise Communication (DEC) Integration Profile supports communication of vendor independent, multi-modality Patient Care Device data to Enterprise Applications using consistent semantics. It accomplishes this by mapping PCD data from proprietary syntax and semantics into a single syntactic and semantic representation for communication to the enterprise The PCD data is time stamped with a consistent enterprise time. Options are provided to allow applications to filter particular PCD data of interest. DEC functions by passing transactions between actors that fulfill the following roles:

DEC (basic) Actors

The Device Observation Reporter (DOR) actor receives data from PCDs, including those based on proprietary formats, and maps the received data to transactions providing consistent syntax and semantics.

The Device Observation Consumer (DOC) is the actor responsible for receiving PCD data from the Device Observation Reporter, the Device Observation Filter, or both.







DEC-SPD Actors

The Device Observation Filter (DOF) actor is responsible for providing optional PCD data filtering services based on publish/subscribe predicates negotiated with client applications implementing the Device Observation Consumer.



DEC-PIB Actors

Patient Demographics Consumer – (PDC) For implementations using ITI Patient Demographics Query (ITI-21), the Patient Demographics Consumer is defined under ITI TF-2:3.21.2 as an Actor that requests a list of patients matching a minimal set of demographic data from the Patient Demographics Supplier Actor and populates its attributes with the information received. For implementations using ITI Patient Administration Management / Patient Identity Feed (ITI-30), the Patient Demographics Consumer is defined under ITI PAM Supplement: 14.2 as an Actor that receives patient demographics from a broadcast Patient Demographics Supplier Actor. Full details on the use of these actors are found in the ITI Technical Framework.


Systems Affected

Patient care device data includes periodic physiologic data (heart rate, invasive blood pressure, respiration rate, etc.), aperiodic physiologic data (non-invasive blood pressure, patient weight, cardiac output, etc.), CLIA waived (or equivalent international waiver) point-of-care laboratory tests (i.e. home blood glucose, etc.), and continuous data (ECG and invasive blood pressure waveforms). It must include patient identity data and may include contextual data such as caregiver identification, and patient care device configuration information.

The Device Enterprise Communication (DEC) profile addresses the need for consistent communication of periodic, aperiodic, and CLIA waived patient care device data to the enterprise. Enterprise recipients of patient care device data include, but are not limited to, Clinical Decision Support applications, Clinical Data Repositories (CDRs), Electronic Medical Record (EMRs) applications, and Electronic Health Records (EHRs).

The following examples describe which actors typical systems might be expected to support. This is not intended to define requirements, but rather to provide illustrative examples.

  • A general purpose observation reporting gateway which combines the Device Observation Reporter and the Device Observation Filter.
  • A clinical decision support application which combines the Device Observation Consumer and Device Observation Filter.
  • A patient care device which bundles the Device Observation Reporter and the Device Observation Filter.

See Also

Profile Status: Final Text

The Patient Care Devices Technical Framework is the official master document for this Profile.


References

Medical device interoperability and the Integrating the Healthcare Enterprise (IHE) initiative JG Rhoads, T Cooper, F Fuchs, P Schluter… - AAMI IT Horiz, 2010, Pp. 22-27 - PDF


This page is based on the Profile Template