Please use a compatible browser :Google Chrome or Mozilla Firefox
Page expired. Any change will be lost. Try to refresh the page.
Gazelle update scheduled, unsaved changes will be lost :
Your session will timeout :
Redeployed...
Logged out...
The server is restarting. Any change will be lost.
 

View Transaction

View Transaction Information

Id: 117

Keyword: PCD-1

Name: Communicate PCD Data

Description: Transmit PCD data to enterprise clients from a Device Observation Reporter or Observation Filter and Receive PCD data by a Device Observation Consumer.

TF Reference:

Status: Final Text

Referenced standards :

Document Section :

None

Id
Keyword
Name
Description
Action
27 DEC2009 DEPRECATED: 2009 Device Enterprise Communication This entry represents the DEC profile as it was documented in the PCD TF in 2009. In 2010, the PDC actor was removed from DEC and brought in through grouping. The new profile actor/option structure is entered under the DEC profile entry in gazelle.
84 PIV2009 DEPRECATED: 2009 Point-of-Care Infusion Verification This profile entry represents the structure of actors and options in the PIV profile as published in 2009 and tested at NA2010. The documentation was updated in 2010, and the new profile entry, PIV, represents the updated structure.
204 T73 HITSP Aggregate Device Information Communication US HITSP: T73. The Aggregate Device Information Communication Transaction allows a system serving as a device intermediary such as a home hub, a cell phone, a set top box, or a monitoring station to which one or more monitoring devices are connected to forward a set of observations through a local or remote connection to a remote monitoring management system where these device captured observations will be reviewed by a person managing the care of the patient under remote monitoring
230 DEC2010 DEPRECATED: 2010 Device Enterprise Communication This entry represents how the DEC profile was documented in 2010. In 2011, the DOF actor was removed, the PCD-02 transaction was removed, and all options were removed
276 DEC Device Enterprise Communication The Device Enterprise Communication Profile supports communication of vendor independent, multi-modality Patient Care Devices 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
345 EHDI Early Hearing Detection and Intervention The EHDI Profile describes the content needed to create a hearing plan of care for a newborn. The HPoC document supports communication and care planning with providers who are a part of the newborn’s care team. It helps to standardize care coordination for infants with suspected hearing loss. It also provides interoperability between clinical EMR systems and EHDI systems for increased efficiency and better data quality. The EHDI Profile also specifies the message content needed to constrain a message for transmitting device observations from hearing screening devices. The message is used to automate population of hearing screening results in the HPoC document. The EHDI Profile also specifies the data element mapping needed to populate a form designed to capture structured data for hearing screening results and risk indicators. The form is used to manually capture hearing screening results and risk indicators when that data in not available for automated population.
Id
Keyword
Name
Description
Action
77DEV_OBS_REPORTERDevice Observation ReporterThe 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.
78DEV_OBS_FILTERDevice Observation FilterThe Device Observation Filter (DOF) actor is responsible for providing PCD data filtering services based on publish/subscribe predicates negotiated with client applications implementing the Device Observation Consumer.
79DEV_OBS_CONSUMERDevice Observation ConsumerThe actor responsible for receiving PCD data from the Device Observation Reporter, the Device Observation Filter, or both.
80CONTENT_CREATORContent CreatorThe Content Creator creates content in a content integration profile
84FORM_MANAGERForm ManagerThe actor that supplies a form based upon a request that supplies a unique form identification.
Assertion Id
Description
DEC-Vol2-001 The Communicate PCD Data [PCD-01] transaction references the following chapters from the HL7 Version 2.6 standard: Chapter 7 Observation Reporting
DEC-Vol2-002 The Communicate PCD Data [PCD-01] transaction references the IEEE 11073-10201 Domain Information Model standard
DEC-Vol2-003 The Communicate PCD Data [PCD-01] transaction references the IEEE 11073-10101a Nomenclature standard
DEC-Vol2-004 The static definition for the PCD-01 Communicate PCD Data message is defined in the unnamed table in this section of the doument
DEC-Vol2-005 The PCD-01 message structure differs from the basic HL7 version 2.6 by allowing for the appearance of PRT segments, a segment new in HL7 version 2.7, in certain locations.
DEC-Vol2-006 The period for periodic reporting shall be several times a minute for high acuity reports and maximum interval of once every 24 hours, with a typical interval of 1 minute.
DEC-Vol2-007 Upon receipt of a PCD-01 message the DOC actor validates the message and shall respond with an acccept acknowledgement message as defined in Appendix G.11 Acknowledgement Modes.
DEC-Vol2-008 For PCD-01 messages MSH-9 Message Type shall contain ORU^R01^ORU_R01.
DEC-Vol2-009 Device to Enterprise Communications PCD-01 Communicate PCD Data message (also used for observations in response to a PCD-02 PCD Data Query) shall contain in MSH-21 Message Profile Identifier the value 1.3.6.1.4.1.19376.1.6.1.1.1
DEC-Vol2-010 For PCD-01 messages the ORC segment use is X, i.e. not sent.
DEC-Vol2-011 Pulse Oximetry Integration (POI) device observations shall include an observation of oxygen saturation of blood gas as a percentage numeric data type. Given the variety of available device designs (dedicated function SPO2 monitor or modular component to a physiologic monitor), the variety of sensor capabilities, and that the observation identification can include the sense point body part, i.e. left/right arm, etc. there is no single observation definition for all devices and all use cases. Any communicated SPO2 observation shall appear in RTMMS. A non-exclusive example is 150456^MDC_PULS_OXIM_SAT_O2^MDC.
PCD-Vol2-001 OBX-3 shall be expressed as an HL7 Coded Element With Exceptions (CWE) data type
PCD-Vol2-002 OBX-4 shall be expressed as the containment level of a particular item expressed in OBX-3
PCD-Vol2-003 Ordinal numbers in OBX-4 are not normative for a given parameter and may vary between implementations. They shall be unique within a given containment, however, numbers may change between messages.
PCD-Vol2-004 Source for nomenclature codes is IEEE 11073-10101 current version. Additional codes not yet standardized are contained in the RTMMS
PCD-Vol2-005 Periodic versus aperiodic data shall be distinguished by the IEEE 11073 Metric Access code in OBX-17
PCD-Vol2-006 The value in MSH-2 Encoding Characters shall be ^~\&
PCD-Vol2-007 MSH-3 Sending Application shall uniquely identify the software application implementing the actor sending the message
PCD-Vol2-008 If MSH-4 Sending Facility is populated, the first component shall identify the organizational entity responsible for sending the message, the second component if present shall identify the Universal ID of the organizational entity responsible for the sender of the message, the third component if present shall identify the Universal ID Type
PCD-Vol2-009 If MSH-5 Receiving Application is populated, the first component shall identify the organizational entity responsible for receiving the message, the second component if present shall identify the Universal ID of the organizational entity responsible for the sender of the message, the third component if present shall identify the Universal ID Type.

Tool index

  • Simulators

    Copyright IHE 2024
  • Gazelle 7.1.7
Back to top