Integrating the Healthcare Enterprise

5 IHE Patient Care Device (PCD)

Technical Framework

Volume 2
10 IHE PCD TF-2
Transactions

15

20 Revision 9.0 - Final Text

December 12, 2019

25 Please verify you have the most recent version of this document, which is published here.

Copyright © 2019: IHE International, Inc.

 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

CONTENTS

1 Introduction ................................................................................................................................ 8
30 1.1 Introduction to IHE ............................................................................................................. 8
1.2 Intended Audience .............................................................................................................. 8
1.3 Overview of Technical Framework Volume 2 ................................................................... 8
1.4 Comment Process................................................................................................................ 9
1.5 Copyright Licenses ............................................................................................................. 9
35 1.5.1 Copyright of Base Standards ....................................................................................... 9
1.6 Trademark ........................................................................................................................... 9
1.7 Disclaimer Regarding Patent Rights ................................................................................... 9
1.8 History of Document Changes .......................................................................................... 10
2 Conventions ............................................................................................................................. 11
40 2.1 Transaction Modeling and Profiling Conventions ............................................................ 11
2.2 Additional Standards Profiling Conventions .................................................................... 11
2.3 Use of Coded Entities and Coding Schemes..................................................................... 11
3 IHE PCD Transactions ............................................................................................................. 12
3.1 Communicate PCD Data [PCD-01] .................................................................................. 12
45 3.1.1 Scope.......................................................................................................................... 12
3.1.2 Use Case Roles .......................................................................................................... 12
3.1.3 Referenced Standards ................................................................................................ 13
3.1.4 Messages .................................................................................................................... 13
3.1.4.1 DOR communicates with DOC .......................................................................... 13
50 3.1.4.1.1 PCD-01 Communicate PCD Data (ORU^R01^ORU_R01) static definition
................................................................................................................... 14
3.1.4.1.2 Trigger events ............................................................................................. 15
3.1.4.1.3 Message Semantics ..................................................................................... 16
3.1.4.1.4 Expected Actions ........................................................................................ 16
55 3.1.5 Security Considerations ............................................................................................. 16
3.2 [PCD-02] Reserved ........................................................................................................... 17
3.3 Communicate Infusion Order [PCD-03] ........................................................................... 17
3.3.1 Scope.......................................................................................................................... 17
3.3.2 Use Case Roles .......................................................................................................... 17
60 3.3.3 Referenced Standards ................................................................................................ 17
3.3.4 Messages .................................................................................................................... 17
3.3.4.1 PCD-03 Communicate Infusion Order (RGV^O15^RGV_O15) static definition
............................................................................................................................ 18
3.3.4.2 RGV^O15^RGV_O15 Pharmacy/Treatment Give Message ............................. 18
65 3.3.4.3 Trigger Events .................................................................................................... 20
3.3.4.4 Message Semantics ............................................................................................. 20
3.3.4.4.1 MSH – Message Header Segment .............................................................. 20
3.3.4.4.2 PID - Patient Identification Segment .......................................................... 22
3.3.4.4.3 PV1 Patient Visit Segment ......................................................................... 22
70 3.3.4.4.4 ORC - Common Order Segment................................................................. 22

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 2 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

3.3.4.4.5 RXG - Pharmacy/Treatment Give Segment ............................................... 23

3.3.4.4.6 Usage notes for RXG 17, 18, 23, and 24 .................................................... 28
3.3.4.4.7 TQ1 Timing Quantity Segment .................................................................. 29
3.3.4.4.8 RXR - Pharmacy/Treatment Route Segment .............................................. 31
75 3.3.4.4.9 OBX - Observation/Result segment ........................................................... 33
3.3.4.4.10 Rate change, titration, Bolus from existing infusion, and Multistep ........ 37
3.3.4.4.10.1 Rate change or titration ..................................................................... 37
3.3.4.4.10.2 Bolus from existing infusion............................................................. 37
3.3.4.4.10.3 Multistep ........................................................................................... 39
80 3.3.4.4.11 Expected Actions ...................................................................................... 40
3.3.5 RRG^O16^RRG_O16 Pharmacy/Treatment Give Acknowledgement Message ...... 41
3.3.5.1 MSH – Message Header Segment ...................................................................... 42
3.3.5.2 MSA - Message Acknowledgement segment..................................................... 42
3.3.5.3 ERR - Error segment .......................................................................................... 42
85 3.4 Report Alert [PCD-04] ...................................................................................................... 42
3.4.1 Scope.......................................................................................................................... 43
3.4.2 Use Case Roles .......................................................................................................... 43
3.4.3 Referenced Standards ................................................................................................ 43
3.4.4 Messages .................................................................................................................... 44
90 3.4.4.1 Alert Reporter reports to Alert Manager/Alert Consumer ................................. 44
3.4.4.1.1 HL7 Conformance Statement ..................................................................... 44
3.4.4.1.2 PCD-04 Report Alert (ORU^R40^ORU_R40) static definition ................ 44
3.4.4.1.3 Trigger Events ............................................................................................ 46
3.4.4.1.4 Message Semantics ..................................................................................... 46
95 3.4.4.1.5 Expected Actions ........................................................................................ 47
3.4.4.1.6 Security Considerations .............................................................................. 47
3.5 Report Alert Status [PCD-05] ........................................................................................... 47
3.5.1 Scope.......................................................................................................................... 48
3.5.2 Use Case Roles .......................................................................................................... 48
100 3.5.3 Referenced Standard .................................................................................................. 48
3.5.4 Messages .................................................................................................................... 48
3.5.4.1 Alert Manager status updates to Alert Reporter ................................................. 49
3.5.4.1.1 Trigger Events ............................................................................................ 49
3.5.4.1.2 Message Semantics ..................................................................................... 49
105 3.5.4.1.3 HL7 Conformance Statement ..................................................................... 50
3.5.4.1.4 PCD-05 Report Alert Status (ORA^R41^ORA_R41) static definition ...... 50
3.5.4.1.5 Expected Actions ........................................................................................ 51
3.5.4.1.6 Security Considerations .............................................................................. 53
3.6 Disseminate Alert [PCD-06] ............................................................................................. 53
110 3.6.1 Scope.......................................................................................................................... 53
3.6.2 Use Case Roles .......................................................................................................... 53
3.6.3 Referenced Standard .................................................................................................. 54
3.6.4 Messages .................................................................................................................... 54
3.6.4.1 Alert Manager disseminate alert to Alert Communicator .................................. 54

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 3 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

115 3.6.4.1.1 HL7 Conformance Statement ..................................................................... 54

3.6.4.1.2 PCD-06 Disseminate Alert static definition ............................................... 54
3.6.4.1.3 Trigger Events ............................................................................................ 55
3.6.4.1.4 Message Semantics ..................................................................................... 55
3.6.4.1.5 Expected Actions ........................................................................................ 55
120 3.6.4.1.6 Security Considerations .............................................................................. 56
3.7 Report Dissemination Alert Status [PCD-07] ................................................................... 56
3.7.1 Scope.......................................................................................................................... 56
3.7.2 Use Case Roles .......................................................................................................... 56
3.7.3 Referenced Standards ................................................................................................ 57
125 3.7.4 Messages .................................................................................................................... 57
3.7.4.1 Alert Communicator status updates to Alert Manager ....................................... 57
3.7.4.2 Trigger Events .................................................................................................... 57
3.7.4.2.1 Message Semantics ..................................................................................... 58
3.7.4.2.2 HL7 Conformance Statement ..................................................................... 58
130 3.7.4.2.3 PCD-07 Report Dissemination Alert Status static definition ..................... 59
3.7.4.2.4 Expected Actions ........................................................................................ 59
3.7.4.2.5 Security Considerations .............................................................................. 59
3.8 [PCD-08] Reserved ........................................................................................................... 60
3.9 Communicate IDC Observations [PCD-09] ..................................................................... 60
135 3.9.1 Scope.......................................................................................................................... 60
3.9.2 Use Case Roles .......................................................................................................... 60
3.9.3 Referenced Standard .................................................................................................. 61
3.9.4 Messages .................................................................................................................... 61
3.9.4.1 HL7 ORU Observation ....................................................................................... 61
140 3.9.4.1.1 Trigger Events ............................................................................................ 61
3.9.4.1.2 Message Semantics ..................................................................................... 62
3.9.4.1.2.1 MSH Segment – Message Header ...................................................... 63
3.9.4.1.2.2 PID Segment – Patient Identification ................................................. 64
3.9.4.1.2.3 PV1 Segment – Patient Visit (Optional) ............................................. 65
145 3.9.4.1.2.4 OBR Segment – Observation Request ................................................ 66
3.9.4.1.2.5 OBX Segments – Pulse Generator and Lead Observation Results ..... 68
3.9.4.1.2.6 IEEE 1073.1.1.3 IDC term mapping to OBX segment ....................... 71
3.9.4.1.2.7 OBX Segment with Encapsulated PDF or Reference Pointer to
External Report [Optional] ................................................................ 71
150 3.9.4.1.2.8 NTE Segment – Notes and Comments [Optional] .............................. 72
3.9.4.1.3 Expected Actions ........................................................................................ 73
3.9.4.1.3.1 Implantable Device – Cardiac – Consumer ........................................ 73
3.9.5 Security Considerations ............................................................................................. 73
3.10 Communicate Infusion Event Data [PCD-10] ................................................................. 73
155 3.10.1 Scope ........................................................................................................................ 73
3.10.2 Use Case Roles ......................................................................................................... 73
3.10.3 Referenced Standard ................................................................................................ 74
3.10.4 Messages .................................................................................................................. 75

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 4 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

3.10.4.1 Communicate Infusion Event Data .................................................................. 75

160 3.10.4.1.1 Trigger Events .......................................................................................... 75
3.10.4.1.2 Message Semantics ................................................................................... 75
3.10.4.1.3 Expected Actions ...................................................................................... 76
Appendices .................................................................................................................................... 77
Appendix A Mapping ISO/IEEE 11073 Domain Information Model to HL7 ............................. 78
165 A.1 ISO/IEEE Nomenclature mapping to HL7 OBX-3 ........................................................... 81
Appendix B Common Segment Descriptions ............................................................................... 83
B.1 MSH – Message Header Segment ..................................................................................... 83
B.2 MSA – Message Acknowledgement Segment .................................................................. 89
B.3 ERR – Error Segment ........................................................................................................ 90
170 B.4 NTE - Notes and Comment Segment ................................................................................ 93
B.5 PID - Patient Identification segment ................................................................................. 94
B.5.1 PID Segment requirements for ACM Transaction PCD-04 .................................... 101
B.6 PV1 - Patient Visit Segment ............................................................................................ 102
B.6.1 PV1 Patient Visit Segment in ACM Transaction PCD-04 ...................................... 105
175 B.7 OBR – Observation Request segment ............................................................................. 106
B.7.1 OBR Observation Request Segment in ACM Transaction [PCD-04] ..................... 111
B.7.1.1 PRT Participation Information Segment in ACM Transaction [PCD-04] ....... 112
B.8 OBX - Observation/Result segment ................................................................................ 114
B.8.1 OBX-4 in a 'flattened' representation of a device .................................................... 117
180 B.8.2 OBX-4 in a hierarchical representation of a device ................................................ 117
B.8.3 'Device-related' and 'metric-related' OBX segments in hierarchy are tied together by
their OBX-4 values .................................................................................................. 117
B.8.4 Dictionary ordering of 'device-related' and 'metric-related' OBX segments ........... 119
B.8.5 OBX-4 Sub-id in Alert Communication Management transactions ([PCD-04], [PCD-
185 06], [PCD-07]) ......................................................................................................... 120
B.8.6 OBX-11 Observation Result Status in Report Alert [PCD-04] ............................... 133
B.8.7 Time Stamps and Time Synchronization................................................................. 137
B.8.8 Device Time Synchronization Capabilities ............................................................. 139
B.8.9 Device and/or DOR Synchronization Protocol ....................................................... 139
190 B.9 ORC – Common Order Segment ..................................................................................... 140
B.9.1 ORC Observation Control Segment in ACM Transaction [PCD-04] ..................... 145
B.9.2 ORC Observation Control Segment in PIV Application Acknowledgment
(RRG^O16^RRG_O16 Pharmacy/Treatment Give Acknowledgement) ................ 146
B.10 PRT Participation Information Segment ....................................................................... 147
195 B.10.1 Current PRT Segment use in ACM Profile transactions ....................................... 147
B.10.2 Future PRT segment use to support Unique Device Identifiers in the PCD Profiles
................................................................................................................................. 147
B.10.3 PRT Participation Information Segment in ACM Transactions [PCD-04] and [PCD-
05] ............................................................................................................................ 162
200 Appendix C Common Data Types .............................................................................................. 164
C.1 CNE Data Type – coded with no exceptions................................................................... 164
C.2 CWE Data Type – coded with exceptions ....................................................................... 165

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 5 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

C.3 CX Data Type .................................................................................................................. 166

C.4 DTM – date/time ............................................................................................................. 166
205 C.5 Entity Identifier (EI) Data Type ...................................................................................... 167
C.6 Hierarchic Designator (HD) Data Type .......................................................................... 169
C.7 PL Data Type................................................................................................................... 170
C.8 XPN Data Type ............................................................................................................... 172
C.9 XTN Data Type ............................................................................................................... 174
210 Appendix D Reserved ................................................................................................................. 175
Appendix E Examples of messages ............................................................................................ 176
E.1 PCD-01 Case C1: Communicate periodic data to Clinical Information System (CIS) ... 176
E.1.1 Example of PCD-01 Observation Report (Physiological Monitor) ......................... 176
E.1.2 Example of PCD-01 Episodic Observation Report ................................................. 177
215 E.2 Examples of transaction [PCD-03]: Communicate Infusion Order................................. 178
E.2.1 Storyboard ................................................................................................................ 178
E.2.2 Interaction Diagram ................................................................................................. 179
E.2.3 Messages .................................................................................................................. 181
E.3 ACM [PCD-04] Example Messages ................................................................................ 182
220 E.3.1 Alert - Numeric Limit Alarm ................................................................................... 182
E.3.2 Alert - Qualitative (non-numeric) Alarm ................................................................. 183
Appendix F HL7 Message Profiling Convention ....................................................................... 185
Appendix G – HL7 Implementation Notes ................................................................................. 186
G.1 Acknowledgment Modes................................................................................................. 186
225 G.2 Use of OSI Object Identifier (OID)................................................................................. 186
Appendix H – IHE Integration Statements ................................................................................. 187
Appendix I – Message Transport using MLLP........................................................................... 188
Appendix J – Message Transport using WS* ............................................................................. 189
J.1 Sample WSDL file and schema ........................................................................................ 189
230 J.2 Sample PCD-01 message and response ............................................................................ 191
Appendix K – Message Transport Using WCTP (ACM Transactions [PCD-06] and PCD-07) 194
K.1 Abbreviations and definitions ......................................................................................... 194
K.2 Pre-Configuration ............................................................................................................ 194
K.3 Endpoint Device Addressing........................................................................................... 194
235 K.4 Polling Versus Push Responses ...................................................................................... 194
K.5 Constraints....................................................................................................................... 195
K.6 Transactions .................................................................................................................... 195
K.7 WCTP XML Element Common Data Items ................................................................... 195
K.8 WCTP client–server messages and responses ................................................................. 201
240 K.8.1 Administrative – wctp-VersionQuery ..................................................................... 201
K.8.2 Administrative – wctp-VersionResponse ................................................................ 201
K.8.3 Administrative – wctp-VersionResponse ................................................................ 202
K.8.4 IHE PCD-06 – wctp-SubmitRequest – no MCR .................................................... 202
K.8.5 IHE PCD-06 – wctp-SubmitRequest – Unpaired MCR ......................................... 203
245 K.8.6 IHE PCD-06 – wctp-SubmitRequest – Paired MCR............................................... 203
K.8.7 IHE PCD-06 – wctp-SubmitRequest – Call Back Phone Number .......................... 204

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 6 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

K.8.8 IHE PCD-07 – Synchronous response to wctp-SubmitRequest – Received by

communications status update ................................................................................. 205
K.8.9 wctp-PollForMessages – general poll (for Pre-Connectathon/Virtual Connectathon
250 testing) ..................................................................................................................... 206
K.8.10 wctp-PollResponse – general poll (for Pre-Connectathon/Virtual Connectathon
testing) ..................................................................................................................... 206
K.8.11 wctp-PollResponse message status update (for Pre-Connectathon/Virtual
Connectathon testing) .............................................................................................. 207
255 K.8.12 wctp-PollResponse message status update acknowledgement (for Pre-
Connectathon/Virtual Connectathon testing) .......................................................... 207
K.8.13 wctp-PollResponse (message reply, not in response to an MCR based wctp-
SubmitRequest) (for Pre-Connectathon/Virtual Connectathon testing) .................. 208
K.8.14 IHE PCD-07 asynchronous status update (DELIVERED - delivery confirmation)
260 ................................................................................................................................. 208
K.8.14 IHE PCD-07 asynchronous status update (READ - read receipt) ......................... 208
K.8.15 IHE PCD-07 asynchronous reply message with MCR and URI response ............ 209
K.8.16 IHE PCD specific WCTP extensions to PCD-06 wctp-SubmitRequest for WCM
attachments .............................................................................................................. 209
265 K.8.17 IHE PCD specific WCTP extensions to wctp-SubmitRequest for alert information
................................................................................................................................. 211
K.8.18 IHE PCD specific WCTP extensions to PCD-07 transactions for alerts............... 213
K.8.19 IHE PCD-06 wctp-IHEPCDSubmitRequestUpdate .............................................. 214
Appendix L - Alert (Alarm) Fatigue ........................................................................................... 216
270 Appendix M Infusion Pump Events ............................................................................................ 218
M.1 Basic Infusion Events ..................................................................................................... 218
M.1.1 Event Message – PCD-10 Communicate Infusion Event Data .............................. 220
M.1.2 Infusion Pump Events ............................................................................................. 220
M.1.2.1 Infusion Event Parameters .............................................................................. 220
275 M.1.2.2 Infusion Event Sample Message ..................................................................... 253
Glossary ...................................................................................................................................... 254

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 7 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

1 Introduction
280 This document, Volume 2 of the IHE Patient Care Device (PCD) Technical Framework, defines
transactions used in IHE Patient Care Device profiles.

1.1 Introduction to IHE

Integrating the Healthcare Enterprise (IHE) is an international initiative to promote the use of
standards to achieve interoperability among health information technology (HIT) systems and
285 effective use of electronic health records (EHRs). IHE provides a forum for care providers, HIT
experts and other stakeholders in several clinical and operational domains to reach consensus on
standards-based solutions to critical interoperability issues.
The primary output of IHE is system implementation guides, called IHE Profiles. IHE publishes
each profile through a well-defined process of public review and trial implementation and
290 gathers profiles that have reached final text status into an IHE Technical Framework, of which
this volume is a part.
For more general information regarding IHE, refer to www.ihe.net. It is strongly recommended
that, prior to reading this volume, the reader familiarizes themselves with the concepts defined in
the IHE Technical Frameworks General Introduction.

295 1.2 Intended Audience

The intended audience of IHE Technical Frameworks Volume 2 is:
• IT departments of healthcare institutions
• Technical staff of vendors participating in the IHE initiative
• Experts involved in standards development

300 1.3 Overview of Technical Framework Volume 2

Volume 2 is comprised of several distinct sections:
• Section 1 provides background and reference material.
• Section 2 presents the conventions used in this volume to define the transactions.
• Section 3 defines Patient Care Device domain transactions in detail, specifying the roles
305 for each actor, the standards employed, the information exchanged, and in some cases,
implementation options for the transaction.
The appendices in Volume 2 provide clarification of technical details of the IHE data model and
transactions. A glossary of terms and acronyms used in the IHE Technical Framework, including
those from relevant standards, is provided in the IHE Technical Frameworks General
310 Introduction. Due to the length of the document, some domains may divide Volume 2 into
smaller volumes labeled 2a, 2b, etc. In this case, the Volume 2 appendices are gathered in
Volume 2x. Code and message samples may also be stored on the IHE ftp server. In this case,
explicit links to the ftp server will be provided in the transaction text.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 8 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

1.4 Comment Process

315 IHE International welcomes comments on this document and the IHE initiative. They can be
submitted by sending an email to the co-chairs and secretary of the Patient Care Device domain
committees at [email protected].

1.5 Copyright Licenses

IHE International hereby grants to each Member Organization, and to any other user of these
320 documents, an irrevocable, worldwide, perpetual, royalty-free, nontransferable, nonexclusive,
non-sublicensable license under its copyrights in any IHE profiles and Technical Framework
documents, as well as any additional copyrighted materials that will be owned by IHE
International and will be made available for use by Member Organizations, to reproduce and
distribute (in any and all print, electronic or other means of reproduction, storage or
325 transmission) such IHE Technical Documents.
The licenses covered by this Copyright License are only to those copyrights owned or controlled
by IHE International itself. If parts of the Technical Framework are included in products that also
include materials owned or controlled by other parties, licenses to use those products are beyond
the scope of this IHE document and would have to be obtained from that other party.

330 1.5.1 Copyright of Base Standards

IHE technical documents refer to and make use of a number of standards developed and
published by several standards development organizations. All rights for their respective base
standards are reserved by these organizations. This agreement does not supersede any copyright
provisions applicable to such base standards.
335 Health Level Seven has granted permission to IHE to reproduce tables from the HL7®1 standard.
The HL7 tables in this document are copyrighted by Health Level Seven. All rights reserved.
Material drawn from these documents is credited where used.

1.6 Trademark
IHE® and the IHE logo are trademarks of the Healthcare Information Management Systems
340 Society in the United States and trademarks of IHE Europe in the European Community. They
may only be used with the written consent of the IHE International Board Operations
Committee, which may be given to a Member Organization in broad terms for any use that is
consistent with the IHE mission and operating principles.

1.7 Disclaimer Regarding Patent Rights

345 Attention is called to the possibility that implementation of the specifications in this document
may require use of subject matter covered by patent rights. By publication of this document, no
position is taken with respect to the existence or validity of any patent rights in connection
therewith. IHE International is not responsible for identifying Necessary Patent Claims for which

1
HL7 is the registered trademark of Health Level Seven International.
______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 9 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

a license may be required, for conducting inquiries into the legal validity or scope of Patents
350 Claims or determining whether any licensing terms or conditions provided in connection with
submission of a Letter of Assurance, if any, or in any licensing agreements are reasonable or
non-discriminatory. Users of the specifications in this document are expressly advised that
determination of the validity of any patent rights, and the risk of infringement of such rights, is
entirely their own responsibility. Further information about the IHE International patent
355 disclosure process including links to forms for making disclosures is available at
http://www.ihe.net/Patent_Disclosure_Process. Please address questions about the patent
disclosure process to the secretary of the IHE International Board: [email protected].

1.8 History of Document Changes

This section provides a brief summary of changes and additions to this document.
360
Date Document Change Summary
Revision
2014-11-04 4.0 Incorporated approved Change Proposals Nos. 86-106 excluding withdrawn proposals.
Integrated Sections 1 and 2 from 2014 Technical Framework Vol. 2 Templates and deleted
material from Appendices which are now included by reference from the General
Introduction. IHE Glossary is now included by reference.
2015-10-14 5.0 Updated ACM Profile to include all approved CPs and for housekeeping. Incorporated other
applicable CPs through CP 121.
2016-11-09 6.0 Incorporated applicable CPs through CP 128
2017-11-09 7.0 Incorporated ACM Profile CP 129 to add additional attributes from [PCD-04] to [PCD-06]
and [PCD-07] messages, CP 130 to add table of minimally required attributes, CP 131 for
[PCD-06] update messages, and to add a mapping table of ISO 60601-1-8 alarm signal states
to ACM [PCD-04] attribute values.
2018-10-23 8.0 Incorporated into ACM Profile approved CPs
135 – Change [PCD-05] to use R41 instead of R42
136 – Add URI action to paired and unpaired MCR choices
137 – Add Presentation ID to [PCD-06]
And to correct incorrect statement regarding ACM Profile not using OBX-7 in [PCD-04]
transactions.
2019-12-12 9.0 Infusion Pump Event Communications approved by IHE PCD Technical and Planning
Committees as Final Text, so transaction detail from Profile Supplement added to this
Technical Framework volume and Appendix M with additional transaction details
Incorporated approved Change Proposals
139 and 140 – PIV Adding detail about supported use cases including bolus from existing
infusion (see CP-PCD-141) and (see CP-PCD-142) multistep.
143 – ACM use optional OBX instance for display text
144 – PIV – additional values for route of administration in RXR segment
145 – ACM add timing diagram (informative)
146 – add Appendix discussing Alarm Fatigue in relation to ACM Profile

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 10 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

2 Conventions
365 This document has adopted the following conventions for representing the framework concepts
and specifying how the standards upon which the IHE PCD Technical Framework is based
should be applied.

2.1 Transaction Modeling and Profiling Conventions

In order to maintain consistent documentation methods, modeling methods for IHE transactions
370 and profiling conventions for frequently used standards are maintained as Appendix E to the IHE
Technical Frameworks General Introduction. Methods described include the Unified Modeling
Language (UML) and standards conventions include DICOM®2, HL7 v2.x, HL7 Clinical
Document Architecture (CDA®3) Documents, etc. These conventions are critical to
understanding this volume and should be reviewed prior to reading this text.

375 2.2 Additional Standards Profiling Conventions

If applicable, this section defines profiling conventions for standards which are not described in
the IHE Technical Frameworks General Introduction.

None.

380 2.3 Use of Coded Entities and Coding Schemes

Where applicable, coding schemes required by the DICOM, HL7, LOINC®4, and SNOMED
CT®5 standards are used in IHE Profiles. In the cases where such resources are not explicitly
identified by standards, implementations may utilize any resource (including proprietary or local)
provided any licensing/copyright requirements are satisfied.
385 IHE does produce and maintain certain terminology. OIDs and URNs have been assigned for
specific uses. The IHE process for managing OIDs and URNs is described at
http://wiki.ihe.net/index.php/OID_Registration.

2
DICOM is the registered trademark of the National Electrical Manufacturers Association for its standards
publications relating to digital communications of medical information.
3
CDA is the registered trademark of Health Level Seven International.
4
LOINC® is registered United States trademarks of Regenstrief Institute, Inc.
5
SNOMED CT is a registered trademark of the International Health Terminology Standards Development
Organisation, all rights reserved.
______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 11 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

3 IHE PCD Transactions

This section defines each IHE Patient Care Device transaction in detail, specifying the standards
390 used and the information transferred.

3.1 Communicate PCD Data [PCD-01]

This section specifies transaction [PCD-01] of the IHE Patient Care Device Technical
Framework, which is used to transmit patient care device data between systems. Transaction
[PCD-01] is used by the Device Observation Reporter and Device Observation Consumer
395 Actors. Note that these actor names are linked to abstract functions rather than to physical
devices; a Device Observation Reporter may be implemented in a freestanding system or it may
be implemented in the Patient Care Device itself.

3.1.1 Scope
This transaction is used to communicate PCD Data from:
400 • A Device Observation Reporter (DOR) to a Device Observation Consumer (DOC).

3.1.2 Use Case Roles

405 Figure 3.1.2-1: Communicate PCD Data

Actor Device Observation Reporter (DOR)

Role Sends PCD Data to DOC
Actor Device Observation Consumer (DOC)
Role Receives PCD Data from DOR

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 12 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

3.1.3 Referenced Standards

• HL7 - HL7 Version 2.6 Chapter 7 Observation Reporting
• HL7 – HL7 Version 2.7 Chapter 7 Observation Reporting – PRT Participation Segment
with added fields for Unique Device Identification (UDI)
410 • ISO/IEEE 11073-10201 Domain Information Model
• ISO/IEEE 11073-10101 Nomenclature
• ISO/IEEE 11073-10102-2012 Nomenclature - Annotated ECG defines additional ECG
lead identifiers and code offsets > 65 that shall be used as needed by sending systems and
shall be understood by receiving systems.
415 Note: The code offsets 0 to 65 originally defined by ISO/IEEE 11073-10101:2004 Annex A
are identical to those defined by ISO/IEEE 11073-10102-2012 and can convey the ECG
leads typically reported by a traditional 12-lead resting, stress or Holter ECG in a compatible
manner without precoordination.
The IHE Patient Care Device Technical Framework uses an information model and a
420 nomenclature from the IEEE 11073. The information model is defined in ISO/IEEE 11073-
10201 Health Informatics – Point-of-care medical device communication – Part 10201: Domain
Information Model. The nomenclature is defined in ISO/IEEE 11073-10101 Health Informatics –
Point -of-care medical device communication – Part 10101: Nomenclature. Familiarity with
these standards is necessary for implementers of the Device Observation Reporter and Device
425 Observation Consumer Actors.
HL7 V2.6 Chapter 7 Observation Reporting defines the general HL7 syntax and coding
requirements related to observation reporting, used for PCD data communications in the PCD
TF. Familiarity with HL7 Chapter 7 is necessary for implementers of the PCD TF transactions.
This Technical Framework specifies conventions that are used to represent the information
430 model hierarchy for medical devices embodied in the IEEE 11073 Domain Information Model
within the syntactic and semantic conventions of HL7 v. 2.6
Definitions of HL7 Data Types used in PCD transactions, with comments on any specializations
for PCD, are given in Appendix C, Common Data Types in this volume.

3.1.4 Messages
435 The following interaction diagrams illustrate potential implementations.

3.1.4.1 DOR communicates with DOC

The [PCD-01] transaction is used to communicate PCD data from: Device Observation Reporter
(DOR) to a Device Observation Consumer (DOC).

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 13 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

440 Figure 3.1.4.1-1: Communicate PCD Data Interaction Diagram

3.1.4.1.1 PCD-01 Communicate PCD Data (ORU^R01^ORU_R01) static definition

The PCD-01 Communicate PCD Data message is used to communicate PCD data
• From a Device Observation Reporter (DOR) to a Device Observation Consumer (DOC)
Common HL7 segments (MSH, MSA, ERR, NTE, PID, PV1, OBR, OBX, ORC, PRT) and data
445 types (CWE, CNE, CX, EI, HD, PL, DTM, XPN, XTN) used in IHE PCD transactions are
defined in Appendix B, “Common Segment Descriptions”, and Appendix C, "Common Data
Types". Note that this 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. This is
to allow for the need for new participation data needed in transactions added to the ACM Profile
450 in this Technical Framework revision, and for planned future extensions to support FDA Unique
Device Identifiers. See Section B.10 for details on the PRT segment.
The static message is defined with the repeating segment group called "Order Observation". This
group can repeat within the message so that a device needs to send only one message with
multiple orders.
455
Segment Meaning Usage Card HL7 chapter
MSH Message Header R [1..1] 2
[{SFT}] Software Segment X [0..0] 2
[UAC] User Authentication Credential O [0..1]
{ --- PATIENT_RESULT begin
[ --- PATIENT begin
PID Patient Identification R [1..1] 3
[PD1] Additional Demographics X [0..0] 3
[{PRT}]

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 14 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Segment Meaning Usage Card HL7 chapter

[{NTE}] Notes and Comments X [0 0] 2
[{NK1}] Next of Kin/Associated Parties O [0..3] 3
[ --- VISIT begin
PV1 Patient Visit R [1..1] 3
[PV2] Patient Visit – Additional Info X [0..0] 3
[{PRT}]
] --- VISIT end
] --- PATIENT end
{ ---ORDER_OBSERVATION begin
[ORC] Order Common X [0..0] 4
OBR Observation Request R [1..1] 7
[{NTE}] Notes and Comments O [0..1] 2
[{PRT}]
[{ --- TIMING_QTY begin
TQ1 Timing/Quantity R [1..1] 4
[{TQ2}] Timing/Quantity Order Sequence X [0..0] 4
}] --- TIMING_QTY end
[CTD] Contact Data X [0..0] 11
[{ --- OBSERVATION begin
OBX Observation Result R [1..1] 7
[{PRT}]
[{NTE}] Notes and comments O [0..1] 2
}] --- OBSERVATION end
[{FT1}] Financial Transaction X [0..0] 6
[{CTI}] Clinical Trial Identification X [0..0] 7
[{ --- SPECIMEN begin
SPM Specimen X [0..0] 7
[{OBX}] Observation related to Specimen X [0..0] 7
}] --- SPECIMEN end
} --- ORDER_OBSERVATION end
} --- PATIENT_RESULT end
[DSC] Continuation Pointer X [0..0] 2

3.1.4.1.2 Trigger events

The ORU^R01^ORU_R01 message is an unsolicited update initiated by the Device Observation
Reporter. The ORU^R01 can be sent with or without a preceding order, since it is common in a
460 clinical setting for device data to be reported without a specific order having been transacted in
the information system (that is, the reporting is the result of a "standing order" for monitoring in
a particular clinical situation).

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 15 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

While a DOR may be implemented directly on a medical device, it is more often implemented on
a gateway or intermediary device as an application which implements the DOR, receiving data
465 from one or more patient care devices using either standards-based or proprietary protocols
which are outside the current scope of the IHE PCD TF.
In general, the DOR sends periodic reports at an interval of between several times per minute
(high acuity) and a maximum interval of 24 hours (chronic, home health) with a typical interval
of 1 minute. The minimum and maximum intervals are configured at implementation. The DOR
470 may also send aperiodic reports for "event type" information. The DOR shall not do interpolation
of data received from the PCD source.

3.1.4.1.3 Message Semantics

Refer to the HL7 standard for the ORU message of HL7 2.6 Chapter 7 and the general message
semantics.
475 The ORU^OR1^ORU_R01 message structure provides the mechanisms for mapping the
hierarchical structure of an IEEE 11073 containment tree to a series of OBX messages each of
which is optionally qualified by a note which immediately follows the respective OBX. See the
discussion of how the containment is represented using a "dotted notation" in field OBX-4
Observation Sub-ID in Appendix B, Section B.8.
480 See Appendix A.1 ISO/IEEE Nomenclature mapping to HL7 OBX-3 for further information on
the mapping rules.
Examples of ORU^R01^ORU_R01 messages implemented in HL7 Encoding Rules (ER7) are
provided in Appendix E.

3.1.4.1.4 Expected Actions

485 The ORU^R01^ORU_R01 message is sent from the DOR to the DOC. Upon receipt, the DOC
validates the message and responds with an acknowledgement as defined in Appendix G.1.1
Acknowledgment Modes.

3.1.5 Security Considerations

During the profile development there were no unusual security or privacy concerns identified.
490 There are no mandatory security controls but the implementer is encouraged to use the
underlying security and privacy profiles from ITI that are appropriate to the transports such as
the Audit Trail and Node Authentication (ATNA) Profile. The operational environment risk
assessment, following ISO 80001, will determine the actual security and safety controls
employed.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 16 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

495 3.2 [PCD-02] Reserved

3.3 Communicate Infusion Order [PCD-03]

This section specifies transaction [PCD-03] of the IHE Patient Care Device Technical
Framework. Transaction [PCD-03] is used by the Infusion Order Programmer and Infusion
Order Consumer.
500 Since the IOC is typically a gateway rather than an infusion pump, all of the information
specified in the Communicate Infusion Order [PCD-03] transaction is not necessarily provided to
or used to program the device.
Note: See related detail on infusion pump device models and data models in the Device Specialization – Infusion Pump PCD
profiles for large volume, syringe, and patient controlled analgesia (PCA) pumps.

505 3.3.1 Scope

This transaction is used to communicate Infusion Order parameters from an Infusion Order
Programmer (IOP) to an Infusion Order Consumer (IOC).

3.3.2 Use Case Roles

Actor Infusion Order Programmer
Role Sends Infusion Order parameters to IOC
Actor Infusion Order Consumer
Role Receives Infusion Order parameters from IOP and in turn programs the pump

510 3.3.3 Referenced Standards

• HL7 - HL7 Version 2.6 Ch4 Order Entry
• ISO/IEEE 11073-10101 Nomenclature
• ISO/IEEE 11073-10201 Domain Information Model

3.3.4 Messages
515 The following interaction diagram illustrates the implementation.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 17 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Figure 3.3.4-1: Communicate Infusion Order

520 3.3.4.1 PCD-03 Communicate Infusion Order (RGV^O15^RGV_O15) static

definition
The PCD-03 Communicate Infusion Order message is used to communicate infusion data from
an Infusion Order Programmer (IOP) to an Infusion Order Consumer (IOC).
Since the IOC is typically a gateway rather than an infusion pump, all of the information
525 specified in the Communicate Infusion Order [PCD-03] transaction is not necessarily provided to
or used to program the device.
All HL7 segments used in the [PCD-03] transaction are defined within this document.

3.3.4.2 RGV^O15^RGV_O15 Pharmacy/Treatment Give Message

Table 3.3.4.2-1: RGV^O15^RGV_O15 Pharmacy/Treatment Give Message

Segment Meaning Usage Card HL7 Chapter
MSH Message Header R [1..1] 2
[{ SFT }] Software X 2
[{ NTE }] Notes and Comments (for Header) X 2
[ --- PATIENT begin
PID Patient Identification R [1..1] 3
[{ NTE }] Notes and Comments (for PID) X 2
[{ AL1 }] Allergy Information X 2
[ --- PATIENT_VISIT begin
PV1 Patient Visit O [0..1] 3
[ PV2 ] Patient Visit – Additional Info X 3
] --- PATIENT_VISIT end
] --- PATIENT end

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 18 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Segment Meaning Usage Card HL7 Chapter

{ --- ORDER begin
ORC Common Order R [1..1] 4
[{ --- TIMING begin
TQ1 Timing/Quantity X 4
[{ TQ2 }] Timing/Quantity Order Sequence X 4
}] --- TIMING end
[ --- ORDER_DETAIL begin
RXO Pharmacy /Treatment Order X 4
[ ---
ORDER_DETAIL_SUPPLEMENT
begin
{ NTE } Notes and Comments (for RXO) X 2
{ RXR } Pharmacy/Treatment Route X 4
[{ --- COMPONENTS begin
RXC Pharmacy/Treatment Component X 4
[{ NTE }] Notes and Comments (for each X 2
RXC)
}] --- COMPONENTS end
] ---
ORDER_DETAIL_SUPPLEMENT
end
] --- ORDER_DETAIL end
[ --- ENCODING begin
RXE Pharmacy/Treatment Encoded X 4
Order
{ --- TIMING_ENCODED begin
TQ1 Timing/Quantity X 4
[{ TQ2 }] Timing/Quantity Order Sequence X 4
} --- TIMING_ENCODED end
{ RXR } Pharmacy/Treatment Route X 4
[{ RXC }] Pharmacy/Treatment Component X 4
] --- ENCODING end
{ --- GIVE begin
RXG Pharmacy/Treatment Give R [1..1] 4
{ --- TIMING_GIVE begin
TQ1 Timing/Quantity O [0..1] 4
[{ TQ2 }] Timing/Quantity Order Sequence X 4
} --- TIMING_GIVE end
{ RXR } Pharmacy/Treatment Route R [1..1] 4
[{ RXC }] Pharmacy/Treatment Component X 4
{ --- OBSERVATION begin
[ OBX ] Observation/Results R [1..n] 7

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 19 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Segment Meaning Usage Card HL7 Chapter

[{ NTE }] Notes and Comments (for OBX) X 2
} --- OBSERVATION end
} --- GIVE end
} --- ORDER end

530

3.3.4.3 Trigger Events

The RGV^O15^RGV_O15 message is generated by the Infusion Order Programmer when the
caregiver initiates an action to administer a medication using an IV pump.

3.3.4.4 Message Semantics

535 Refer to the HL7 standard for the RGV message in HL7 2.6 Chapter 4 for the general message
semantics.

3.3.4.4.1 MSH – Message Header Segment

This segment defines the intent, source, destination, and some specifics of the syntax of a
message. See HL7 v2.6: chapter 2 Message control. For MSH usage in IHE PCD Technical
540 Framework profiles, refer to Appendix B.1 of this volume. MSH-15 and MSH-16 fields have
special considerations in PCD 03:
MSH-15 Accept Acknowledgement Type (ID), required:
This is required for all messages. The Accept Acknowledgement Type field will be
valued with “AL” (always) by the IOP in a RGV^O15 message and by the IOC in a
545 RRG^O16 message.
The receiving application must transmit the accept acknowledgement on the same
network connection as the initiating RGV^015 or RRG^O16 message
MSH-16 Application Acknowledgement Type (ID), required:
This is required for all messages. The application acknowledgement field informs the
550 receiver whether the sender can process application acknowledgements and under what
conditions to send the additional acknowledgement. The receiving system must send (or
not send) acknowledgements as specified by this field.
When the sending application requests an application acknowledgement, the receiving
application must initiate a new network connection for the transaction. Here is an
555 example of an IOP to IOC transaction:

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 20 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

IOP IOC

1. IOP opens a
RGV^O15 Message
Network Connection
on the IOC’s port

2. IOC responds on ACK^O15 CA Message

the same Network
Connection

1. The IOP sends a RGV^O15 message on the IOC’s port 3000 with MSH-15=”AL” and
MSH-16=”AL”.
2. The IOC receives the message on port 3000 and transmits an ACK^O15 to the IOP on the
560 same network connection.

IOP IOC

3. Then, the IOC opens RRG^O16 AR Message

a separate Network (MSH-15 as AL)
Connection on the
IOP’s separate port

4. IOP responds on ACK^O16 CA Message

the same Network
Connection

3. After completing application processing, the IOC transmits a RRG^016 on a different

network connection (e.g., the IOP’s port 3001) with MSH-15=”AL” and MSH-16=”NE”.
565 4. The IOP receives the message on port 3001 and sends an ACK^016 to the IOC on the
same network connection.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 21 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

After completing application processing, the IOP does not transmit an application
acknowledgement.
If the IOP wants to always receive an application acknowledgement (RRG) message in addition
570 to the accept acknowledgement, the IOP must populate MSH-16 with “AL” (always). If the IOP
cannot process application acknowledgement messages, the IOP must populate MSH-16 with
“NE” (never). The IOP must populate MSH-16 with “ER” (error) when the system only wants to
receive an application acknowledgement message when the IOC detects an error.
The table below identifies the possible values for MSH-16:

575 Table 3.3.4.4.1-1: Possible Values for MSH-16 in PCD-03 Message

Value Description Comments
AL Always The sender always wants to receive an application
acknowledgement in addition to the accept
acknowledgement.
NE Never The sender cannot process application acknowledgements
ER Error/reject The sender only wants to be notified if there is a message
error detected

This profile recommends “AL” (always) to receive complete messaging processing confirmation.
If this support is not feasible, this profile recommends that the IOP value the application
acknowledgement field with “ER” (error/reject), so that the IOC will only send an application
580 error when it is unable to process the requested order.
This profile recommends that the IOC value the application acknowledgement field with “NE”
on a RRG^O16, so that the IOP will only send an accept acknowledgement and not an
application acknowledgement. Note that the IOP is responsible for sending (or not sending) an
acknowledgement as specified by the IOC.

585 3.3.4.4.2 PID - Patient Identification Segment

The PID segment is used by all applications as the primary means of communicating patient
identification information. This segment contains permanent patient identifying and demographic
information that, for the most part, is not likely to change frequently. See HL7 v2.6: chapter 3
(3.4.2). For PID usage in IHE PCD Technical Framework profiles, refer to Appendix B.5 of this
590 volume.

3.3.4.4.3 PV1 Patient Visit Segment

The PV1 segment is used by Registration/Patient Administration applications to communicate
information on an account or visit-specific basis. See Appendix B.6 for details.

3.3.4.4.4 ORC - Common Order Segment

595 The Common Order segment (ORC) is used to transmit fields that are common to all orders (all
types of services that are requested). See Appendix B.9 for details of usage in IHE PCD profiles.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 22 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

3.3.4.4.5 RXG - Pharmacy/Treatment Give Segment

Table 3.3.4.4.5-1: HL7 Attribute Table – RXG – Pharmacy/Treatment Give

SEQ LEN DT Usage Card. TBL# ITEM # ELEMENT NAME
1 4 NM R [1..1] 00342 Give Sub-ID Counter
2 4 NM RE [0..1] 00334 Dispense Sub-ID Counter
3 705 TQ X [0..0] 00221 Quantity/Timing
4 705 CWE R [1..1] 0292 00317 Give Code
5 20 NM CE [0..1] 00318 Give Amount - Minimum
6 20 NM RE [0..1] 00319 Give Amount - Maximum
7 705 CWE CE [0..1] 00320 Give Units
8 705 CWE RE [0..1] 00321 Give Dosage Form
9 705 CWE RE [0..*] 00351 Administration Notes
10 1 ID RE [0..1] 0167 00322 Substitution Status
11 200 LA2 RE [0..1] 01303 Dispense-To Location
12 1 ID RE [0..1] 0136 00307 Needs Human Review
13 705 CWE RE [0..*] 00343 Pharmacy/Treatment Supplier's
Special Administration
Instructions
14 20 ST RE [0..1] 00331 Give Per (Time Unit)
15 6 ST CE [0..1] 00332 Give Rate Amount
16 705 CWE CE [0..1] 00333 Give Rate Units
17 20 NM RE [0..1] 01126 Give Strength
18 705 CWE RE [0..1] 01127 Give Strength Units
19 20 ST RE [0..*] 01129 Substance Lot Number
20 24 DTM RE [0..*] 01130 Substance Expiration Date
21 705 CWE RE [0..*] 0227 01131 Substance Manufacturer Name
22 705 CWE RE [0..*] 01123 Indication
23 5 NM RE [0..1] 01692 Give Drug Strength Volume
24 705 CWE RE [0..1] 01693 Give Drug Strength Volume Units
25 60 CWE RE [0..1] 01694 Give Barcode Identifier
26 1 ID RE [0..1] 0480 01695 Pharmacy Order Type
27 705 CWE X [0..0] 01688 Dispense to Pharmacy
28 106 XAD X [0..0] 01689 Dispense to Pharmacy Address
29 80 PL X [0..0] 01683 Deliver-to Patient Location
30 250 XAD X [0..0] 01684 Deliver-to Address

600 The following describes the IHE PCD usage of those fields which have a usage other than X in
the above table.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 23 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

RXG-1 Give Sub-ID Counter

When used for a multistep infusion this field contains the step number (1..n).
For other uses see HL7 V2.6 Section 4.14.6.1 for details. The PCD TF does not further
605 constrain this field.
RXG-2 Dispense Sub-ID Counter
See HL7 V2.6 Section 4.14.6.2 for details. The PCD TF does not further constrain this
field.
RXG-4 Give Code
610 Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^
<Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate
Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding
System Version ID (ST)> ^ <Original Text (ST)>

Definition: This field is the identifier of the primary additive or principal ingredient of the
615 IV medication to be administered to the patient.
Subfields CWE-1 "Identifier" and CWE-2 "Text" are required for each identifier.
Typically, "Identifier" would be populated with a value such as an NDC or another value
known to both the Infusion Order Programmer and the Infusion Order Consumer. "Text"
would typically be populated with the generic name of the medication. The information
620 provided in either Identifier or Text is used to match the ordered medication to the
onboard drug library.
RXG-5 Give Amount – Minimum
Definition: This field contains the volume of fluid to be administered (VTBI). This
volume is the actual fluid volume that the clinician intends to administer (not necessarily
625 the volume contained in the bag, bottle, syringe, or other fluid container).
Required for LVP when TQ1 segment is not present. Optional for PCA and Syringe.
Must be empty when ORC-1 = “XO”.
When this field is empty, there should be no implication made about the volume of fluid
to be administered.
630 RXG-6 Give Amount - Maximum
See HL7 V2.6 Section 4.14.6.6 for details. The PCD TF does not further constrain this
field.
RXG-7 Give Units
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^
635 <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate
Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding
System Version ID (ST)> ^ <Original Text (ST)>

Definition: This field contains the coded units for the Give Amount. The preferred format
is an MDC value; UCUM values are also acceptable.
640 Required for LVP when TQ1 segment is not present; Optional for PCA and Syringe.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 24 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Must be empty when ORC-1 = “XO”.

The PCD TF requires that the first three components of RXG-7 contain one of the
following sets of values:
• 263762^MDC_DIM_MILLI_L^MDC
645 • mL^mL^UCUM

RXG-8 Give Dosage Form

See HL7 V2.6 Section 4.14.6.8 for details. The PCD TF does not further constrain this
field.
RXG-9 Administration Notes
650 See HL7 V2.6 Section 4.14.6.9 for details. The PCD TF does not further constrain this
field.
RXG-10 Substitution Status
See HL7 V2.6 Section 4.14.6.10 for details. The PCD TF does not further constrain this
field.
655 RXG-11 Dispense-to Location
See HL7 V2.6 Section 4.14.6.11 for details. The PCD TF does not further constrain this
field.
RXG-12 Needs Human Review
See HL7 V2.6 Section 4.14.6.12 for details. The PCD TF does not further constrain this
660 field.
RXG-13 Pharmacy/Treatment Supplier's Special Administration Instructions
See HL7 V2.6 Section 4.14.6.13 for details. The PCD TF does not further constrain this
field.
RXG-14 Give Per (Time Unit)
665 See HL7 V2.6 Section 4.14.6.14 for details. The PCD TF does not further constrain this
field.
RXG-15 Give Rate Amount
Definition: This field contains the numeric portion of the rate, dose rate, or dose amount
to be administered.
670 If the infusion order specifies a rate, such as normal saline at 75 mL/hr, then this field
contains the rate value amount (e.g., "75").
If the infusion order specifies a dose rate, such as dopamine at 5 mcg/kg/min, this field
contains the dose rate value amount (e.g., “5").
If the infusion order specifies a dose amount, such as 2 g, this field contains the dose
675 value amount (e.g., “2”).

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 25 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Required for LVP and Syringe; Optional for PCA. If present for PCA, contains the basal
or continuous rate value.
RXG-16 Give Rate Units
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^
680 <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate
Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding
System Version ID (ST)> ^ <Original Text (ST)>

Definition: This field contains the coded version of the units portion of the rate, dose rate,
or dose to be administered.
685 If the infusion order specifies a rate, such as normal saline to infuse at 75 mL/hr, this
field represents the rate units (e.g., "mL/hr").
If the infusion order specifies a dose rate, such as dopamine to infuse at 5 mcg/kg/min,
this field represents the dose rate units (e.g., "mcg/kg/min").
If the infusion order specifies a dose, such as ceftriaxone 2 g, this field represents the
690 dose units (e.g., “g”).
When a dose is specified the TQ1 segment must be present to indicate the time period
that the dose is to be infused over.
The preferred format is an MDC value; UCUM values are also acceptable.
Required for LVP and Syringe; Optional for PCA. If present for PCA, contains the basal
695 or continuous rate units value.
Examples:

265266^MDC_DIM_MILLI_L_PER_HR^MDC
265619^MDC_DIM_MICRO_G_PER_KG_PER_MIN^MDC
700 263872^MDC_DIM_X_G^MDC
ml/h^ml/h^UCUM
ug/kg/min^ug/kg/min^UCUM
g^g^UCUM

705 RXG-17 Give Strength

Definition: This field contains the quantity of the main ingredient in the infusion; e.g., for
dopamine 800 mg in 250 mL D5W, the field would contain the value "800".
RXG-18 Give Strength Units
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^
710 <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate
Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding
System Version ID (ST)> ^ <Original Text (ST)>

This field contains the coded version of the units portion of the main ingredient in the
infusion; e.g., for dopamine 800 mg in 250 mL D5W, the field would represent ‘mg".
715 The preferred format is an MDC value; UCUM values are also acceptable:
Examples:
______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 26 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

263890^MDC_DIM_MILLI_G^MDC
mg^mg^UCUM

RXG-19 Substance Lot Number

720 See HL7 V2.6 Section 4.14.6.19 for details. The PCD TF does not further constrain this
field.
RXG-20 Substance Expiration Date
See HL7 V2.6 Section 4.14.6.20 for details. The PCD TF does not further constrain this
field.
725 RXG-21 Substance Manufacturer Name
See HL7 V2.6 Section 4.14.6.21 for details. The PCD TF does not further constrain this
field.
RXG-22 Indication
See HL7 V2.6 Section 4.14.6.22 for details. The PCD TF does not further constrain this
730 field.
RXG-23 Give Drug Strength Volume
Definition: This field contains the quantity of the diluent or base fluid ingredient(s) in the
infusion; e.g., for dopamine 800 mg in 250 mL D5W, the field would contain the value
"250".
735 RXG-24 Give Drug Strength Volume Units
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^
<Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate
Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding
System Version ID (ST)> ^ <Original Text (ST)>

740 Definition: This field contains the coded units for the Give Drug Strength Volume. The
preferred format is an MDC value; UCUM values are also acceptable.
The PCD TF requires that the first three components of RXG-24 contain one of the
following sets of values:

745 • 263762^MDC_DIM_MILLI_L^MDC
• mL^mL^UCUM

RXG-25 Give Barcode Identifier

See HL7 V2.6 Section 4.14.6.25 for details. The PCD TF does not further constrain this
750 field.
RXG-26 Pharmacy Order Type
See HL7 V2.6 Section 4.14.6.26 for details. The PCD TF does not further constrain this
field.
______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 27 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

RXG-27 to 30
755 These fields are not supported by the PCD TF.

3.3.4.4.6 Usage notes for RXG 17, 18, 23, and 24

These fields are used by the pump or gateway to determine the concentration of the main
ingredient in the infusion. Concentration is defined as:
[Medication amount][units] / [Diluent amount][units]
760 Example: 800 mg / 250 mL
The pump’s onboard drug library may require this information in order to apply dosing limits to
ensure the safe administration of a particular infusion. The "rules" contained in the drug library
may be different for different concentrations of the same drug. For example, there may be two
different rules for the medication "dopamine"; one specific for dopamine 800 mg in 250 mL, and
765 another for any other concentration.
The BCMA system cannot know when the information is required since the drug library
definition is internal to the pump system. BCMA systems may extract the information needed
from the underlying order, from their formulary, or both. Basically, if the BCMA is able to
determine these values, they should be supplied in the [PCD-03] transaction.
770 An analogy to a pharmacy order for an IV fluid containing multiple components (RXC
segments) may be helpful in determining how to populate these values. In [PCD-03], RXG-17
and 18 (Give Strength/Units) are analogous to the Component Strength and Units (RXC-5 and 6)
for the additive component (i.e., RXC-1 = "A"). Similarly, RXG-23 and 24 (Give Drug Strength
Volume/Units) are similar to Component Drug Strength Volume and Units (RXC-8 and 9) for
775 the base component (RXC-1 = "B").
Example:
Ampicillin 1 g/Sodium chloride 50 mL
RXC segments for Ampicillin (pharmacy order message):

Component RXC-1 RXC-5 RXC-6 RXC-8 RXC-9

Ampicillin A 1 G
Sodium chloride B 50 ML

780
RXG segment population for Ampicillin:

RXG-17 RXG-18 RXG-23 RXG-24

1 263872^MDC_DIM_X_G^MDC 50 263762^MDC_DIM_MILLI_L^MDC

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 28 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Premixed medication orders

785 Certain marketed medication products are "premixed", containing both the additive and the base
mixed together and sold as a single item.
Examples:
Dopamine 800 mg / Dextrose 5% 250 mL
Cefazolin 1 g / Dextrose 5% 50 mL
790 RXG segment population for Dopamine:

RXG-17 RXG-18 RXG-23 RXG-24

800 263890^MDC_DIM_MILLI_G^MDC 250 263762^MDC_DIM_MILLI_L^MDC

Fluid orders
"Plain" IV fluids do not contain an additive. The BCMA is not required to populate RXG-17, 18,
795 23, and 24 for these orders.
Examples:
Dextrose 5% 1000 mL
Sodium Chloride 0.9% 250 mL
Orders with multiple additives
800 Some infusion orders may contain multiple additives, for example, total parenteral nutrition
(TPN) solutions are made up of one or more base solutions and as many as 10 or 12 additives.
The BCMA is not required to populate RXG-17, 18, 23, and 24 for these orders.

3.3.4.4.7 TQ1 Timing Quantity Segment

This segment is an optional segment which allows the IOP to specify the duration of the infusion
805 order. Along with the ordered dose (RXG.18) the infuser can then calculate the rate at which the
infusion should be run. Not all IOCs will be able to support duration based infusions, and even
vendors that do support will have limits on the types of infusions which support duration. See
each vendor’s implementation guide for further details.

Table 3.3.4.4.6-1: TQ1 Timing Quantity Segment Attributes

SEQ LEN DT Usage Card. TBL# ITEM # ELEMENT NAME
1 4 SI O [0..1] 01627 Set ID - TQ1
2 20 CQ X [0..0] 01628 Quantity
3 540 RPT X [0..0] 0335 01629 Repeat Pattern
4 20 TM X [0..0] 01630 Explicit Time
5 20 CQ X [0..0] 01631 Relative Time and Units
6 20 CQ X [0..0] 01632 Service Duration

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 29 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

SEQ LEN DT Usage Card. TBL# ITEM # ELEMENT NAME

7 26 TS X [0..0] 01633 Start date/time
8 26 TS X [0..0] 01634 End date/time
9 705 CW X [0..0] 0485 01635 Priority
E
10 250 TX X [0..0] 01636 Condition text
11 250 TX X [0..0] 01637 Text instruction
12 10 ID X [0..0] 0427 01638 Conjunction
13 20 CQ R [1..3] 01639 Occurrence duration
14 10 NM X [0..1] 01640 Total occurrence’s

810
TQ1-1 Set ID
See HL7 v2.6 Section 4.5.4.1 for details. The PCD TF does not further constrain this
field.
TQ1-2 Quantity
815 See HL7 v2.6 Section 4.5.4.2 for details. The PCD TF does not further constrain this
field.
TQ1-3 Repeat Pattern
See HL7 v2.6 Section 4.5.4.3 for details. The PCD TF does not further constrain this
field.
820 TQ1-4 Explicit Time
See HL7 v2.6 Section 4.5.4.4 for details. The PCD TF does not further constrain this
field.
TQ1-5 Relative Time and Units
See HL7 v2.6 Section 4.5.4.5 for details. The PCD TF does not further constrain this
825 field.
TQ1-6 Service Duration
See HL7 v2.6 Section 4.5.4.6 for details. The PCD TF does not further constrain this
field.
TQ1-7 Start date/time
830 See HL7 v2.6 Section 4.5.4.7 for details. The PCD TF does not further constrain this
field.
TQ1-8 End date/time
See HL7 v2.6 Section 4.5.4.8 for details. The PCD TF does not further constrain this
field.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 30 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

835 TQ1-9 Priority

See HL7 v2.6 Section 4.5.4.9 for details. The PCD TF does not further constrain this
field.
TQ1-10 Condition text
See HL7 v2.6 Section 4.5.4.10 for details. The PCD TF does not further constrain this
840 field.
TQ1-11 Text instruction
See HL7 v2.6 Section 4.5.4.11 for details. The PCD TF does not further constrain this
field.
TQ1-12 Conjunction
845 See HL7 v2.6 Section 4.5.4.12 for details. The PCD TF does not further constrain this
field.
TQ1-13 Occurrence duration
Components: <Quantity (NM)> ^ <Units (CE)> Subcomponents for Units (CE): <Identifier
(ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier
850 (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>

This field specifies the duration of the infusion. Along with the dose or the volume to be
administered the rate can be calculated by the infuser.
The only acceptable time values for this field are seconds, minutes, and hours. To specify
multiple components of time, this field can be repeated two additional times.
855
Unit of Time MDC Code
Hour 264384&MDC_DIM_HR&MDC
Minute 264352&MDC_DIM_MIN&MDC
Second 264320&MDC_DIM_X_SEC&MDC

Examples:
90 Seconds:
90^264320&MDC_DIM_X_SEC&MDC
860
2 Hours 45 Minutes:
2^264384&MDC_DIM_HR&MDC~45^264352&MDC_DIM_MIN&MDC

TQ1-14 Total occurrences

See HL7 v2.6 Section 4.5.4.14 for details. The PCD TF does not further constrain this
865 field.

3.3.4.4.8 RXR - Pharmacy/Treatment Route Segment

The Pharmacy/Treatment Route segment contains the alternative combination of route, site,
administration device, and administration method that are prescribed.
______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 31 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Table 3.3.4.4.8-1: HL7 Attribute Table – RXR – Pharmacy/Treatment Route

SEQ LEN DT Usage Card. TBL# ITEM # ELEMENT NAME
1 705 CWE R [1..1] 0162 00309 Route
2 705 CWE RE [0..1] 0550 00310 Administration Site
3 705 CWE RE [0..1] 0164 00311 Administration Device
4 705 CWE CE [0..1] 0165 00312 Administration Method
5 705 CWE RE [0..1] 01315 Routing Instruction
6 705 CWE RE [0..1] 0495 01670 Administration Site Modifier

870
The following describes the IHE PCD usage of the fields in the above table.
RXR-1 Route
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^
<Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate
875 Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding
System Version ID (ST)> ^ <Original Text (ST)>

Definition: This field is the route of administration. The PCD TF requires that this field be
valued as one of the following: ^IV^HL70162 for Intravenous, ^EP^HL70162 for Epidural,
^SC^HL70162 for Subcutaneous, ^NG^HL70162 for Nasogastric, ^GTT^HL70162 for
880 Gastrostomy Tube or ^IT^HL70162 for Intrathecal.
RXR-2 Administration Site
See HL7 V2.6 Section 4.14.2.2 for details. The PCD TF does not further constrain this
field.
RXR-3 Administration Device
885 Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^
<Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate
Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding
System Version ID (ST)> ^ <Original Text (ST)>

Definition: This field contains the type of pump used to administer the drug, if known by
890 the BCMA system. The PCD TF requires that this field be valued as ^IVP^HL70164 for
LVP pumps, ^PCA^HL70164 for PCA pumps, or ^SYR^HL70164 for Syringe pumps.
The following entry should be added to HL7 user-defined table #0164:

Value Description
SYR Syringe Pump

895 RXR-4 Administration Method

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^
<Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate
Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding
System Version ID (ST)> ^ <Original Text (ST)>

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 32 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

900 Definition: This field identifies whether the infusion is to be administered as a primary
infusion or as an IV piggyback or secondary infusion. The TF requires that this field be
valued as ^IV^HL70165 for a primary infusion or ^IVPB^HL70165 for an IV piggyback
or secondary infusion. This field is optional for PCA.
The following entry should be added to HL7 user-defined table #0165:
905
Value Description
IV IV Primary

RXR-5 Routing Instruction

See HL7 V2.6 Section 4.14.2.5 for details. The PCD TF does not further constrain this
field.
910 RXR-6 Administration Site Modifier
See HL7 V2.6 Section 4.14.2.6 for details. The PCD TF does not further constrain this
field.

3.3.4.4.9 OBX - Observation/Result segment

Refer to HL7 v2.6: Section 7.4.2x
915 The HL7 OBX segment is used to transmit a single observation or observation fragment. In the
Point-of-Care Infusion Verification Profile the usage is limited to providing:
1. pump ID
2. patient parameters such as height, weight, or body surface area (BSA)
3. infusion order step type
920 4. other parameters used to program the pump.
Note that the definition of the OBX segment in this profile is constrained from the definition
used in the PCD Observation/Result Message to reflect this limited usage. The broader definition
can be found in OBX - Observation/Result segment, Appendix Section B-8.
One OBX segment containing the pump ID must always be present. Additional OBX segments
925 containing patient parameters, infusion order step type, or pump programming parameters may
optionally follow.

Table 3.3.4.4.9-1: OBX segment

SEQ LEN DT Usage Card. TBL# Element name

1 4 SI R [1..1] Set ID – OBX

2 3 ID CE [0..1] 0125 Value Type

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 33 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

SEQ LEN DT Usage Card. TBL# Element name

3 705 CWE R [1..1] Observation Identifier

4 20 ST RE [0..1] Observation Sub-ID

5 99999 Varies CE [0..1] Observation Value

6 705 CWE CE [0..1] Units

7 60 ST RE [0..1] References Range

8 5 IS RE [0..1] 0078 Abnormal Flags

9 5 NM X [0..0] Probability

10 2 ID RE [0..1] 0080 Nature of Abnormal Test

11 1 ID RE [0..1] 0085 Observation Result Status

12 24 DTM X [0..0] Effective Date of Reference

Range

13 20 ST X [0..0] User Defined Access Checks

14 24 DTM RE [0..1] Date/Time of the Observation

15 705 CWE RE [0..1] Producer's ID

16 3220 XCN RE [0..1] Responsible Observer

17 705 CWE RE [0..1] Observation Method

18 427 EI CE [0..1] Equipment Instance Identifier

19 24 DTM RE [0..1] Date/Time of the Analysis

20 705 CWE RE [0..*] 0163 Observation Site

The following describes the IHE PCD PIV Profile’s usage of those fields which have a usage
930 other than X in the above table.
OBX-1 Set ID
This field contains the sequence number of the OBX in this message; i.e., 1st OBX Set
ID = 1, 2nd OBX set ID = 2, etc., regardless of whether the OBX refers to a device or a
metric value.
935 OBX-2 Value Type
The PCD PIV Profile constrains this field as follows:
If OBX-3 refers to a pump ID this field must be empty.
If OBX-3 refers to a patient parameter that conveys a numeric quantity (e.g., patient
weight), this value is restricted to NM.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 34 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

940 If OBX-3 refers to an infusion order step type this field must be “ST”..
If OBX-3 refers to a pump programming parameter, this value should identify the data
type of the value in OBX-5 Observation Value.
OBX-3 Observation Identifier
The PCD PIV Profile constrains the value of this field to one of the following:
945 Pump ID
69986^MDC_DEV_PUMP_INFUS_VMD^MDC

Patient parameter
68063^MDC_ATTR_PT_WEIGHT^MDC
950 68060^MDC_ATTR_PT_HEIGHT^MDC
188744^MDC_AREA_BODY_SURF_ACTUAL^MDC

Pump programming parameter

157985^MDC_DOSE_PCA_LIMIT^MDC
955 157986^MDC_VOL_PCA_DOSE_LIMIT^MDC
157987^MDC_TIME_PD_PCA_DOSE_LIMIT^MDC
157988^MDC_RATE_PCA_MAX_DOSES_PER_HOUR^MDC
157989^MDC_TIME_PCA_LOCKOUT^MDC
157994^MDC_VOL_FLUID_CONTAINER_START^MDC
960 158017^MDC_DOSE_PCA_PATIENT^MDC
158019^MDC_DOSE_CLINICIAN^MDC
158018^MDC_DOSE_LOADING^MDC
0^MDCX_INFUS_ORDER_STEP_TYPE^MDC
(Note: Code assignment pending as of publication date)

965
OBX-4 Observation Sub-ID
The PC PIV Profile does not further constrain this field.
OBX-5 Observation Value
If OBX-3 refers to a pump ID, this field must be empty.
970 If OBX-3 refers to a patient parameter, this field contains the parameter value.
If OBX-3 refers to an infusion order step type, the field contains the enumerated value
If OBX-3 refers to a pump programming parameter, this field contains the parameter
value.
OBX-6 Units
975 The PCD PIV Profile constrains the value of this field based on the value in OBX-3.
If OBX-3 refers to a pump ID, this field must be empty.
If OBX-3 refers to a patient parameter, this field contains the coded units for the
parameter. The preferred format is an MDC value; UCUM values are also acceptable.
______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 35 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

When OBX-3 refers to weight, the first three components of OBX-6 must contain one of
980 the following sets of values:
263872^MDC_DIM_X_G^MDC
263875^MDC_DIM_KILO_G^MDC
g^g^UCUM
kg^kg^UCUM

985 When OBX-3 refers to height, the first three components of OBX-6 must contain one of
the following sets of values:
263441^MDC_DIM_CENTI_M^MDC
cm^cm^UCUM

When OBX-3 refers to BSA, the first three components of OBX-6 must contain one of
990 the following sets of values:
263616^ MDC_DIM_SQ_X_M^MDC
m2^m2^UCUM

If OBX-3 refers to an infusion order step type, this field must be empty.
If OBX-3 refers to a pump programming parameter, this field contains the units for the
995 value in OBX-5 Observation Value.
OBX-7 References Range:
The PCD PIV Profile does not further constrain this field.
OBX-8 Abnormal Flags
The PCD PIV Profile does not further constrain this field.
1000 OBX-10 Nature of Abnormal Test
The PCD PIV Profile does not further constrain this field.
OBX-11 Observation Result Status
The PCD PIV Profile does not further constrain this field.
OBX-14 Date/Time of the Observation
1005 The PCD PIV Profile does not further constrain this field.
OBX-15 Producer’s ID
The PCD PIV Profile does not further constrain this field.
OBX-16 Responsible Observer (XCN)
The PCD PIV Profile does not further constrain this field.
1010 OBX-17 Observation Method
The PCD PIV Profile does not further constrain this field.
OBX-18 Equipment Instance Identifier
See Appendix B.8 for description of usage of OBX-18.
If OBX-3 refers to a pump ID, the following applies.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 36 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

1015 o For backward compatibility, when used to contain a pump ID, the OBX-18
convention used in previous Trial Implementation versions of the Point-of-Care
Infusion Verification Supplement may be used by agreement between sending and
receiving systems, but this usage is deprecated and should not be used in new
systems. The former language is reproduced here: "If OBX-3 refers to the pump ID,
1020 the ID is placed in the ‘Universal ID’ component (EI-3), and the device or
manufacturer name is placed in the ‘Universal ID Type’ component (EI-4). The pump
ID is a unique alphanumeric identifier and may optionally include the pump channel.
The format of the identifier is vendor-specific. A typical value could be a serial
number for a single-channel pump, or a serial number followed by the channel
1025 number or letter for a multi-channel pump. Note that this specification differs from
the usage of OBX-18 in IHE PCD DEC Profile."
o New applications should conform to the general specification for OBX-18 (Appendix
B.8). The pump ID (vendor-specific format, which may optionally include the pump
channel as before) should be placed in EI-1, and EI-3 and EI-4 should identify the
1030 manufacturer of the pump according to an accepted Universal ID system.
o If OBX-3 refers to a patient parameter this field must be empty.
If OBX-3 refers to a pump programming parameter this field must be empty.
OBX-19 Date/Time of the Analysis
The PCD PIV Profile does not further constrain this field.
1035 OBX-20 Observation Site
The PCD PIV Profile does not further constrain this field.
OBX-21 to 25
OBX fields 21 to 25 are not supported by PCD PIV.

3.3.4.4.10 Rate change, titration, Bolus from existing infusion, and Multistep

1040 3.3.4.4.10.1 Rate change or titration

ORC-1 Order Control = “XO”.
RXG-5 Give Amount-Minimum and RXG-7 Give Units must be empty.
RXG-15, 16 must contain a rate or dose rate and cannot contain a dose.

3.3.4.4.10.2 Bolus from existing infusion

1045 Considerations:
• An infusion is currently programmed on the pump.
• A bolus of the same medication is ordered (i.e., there is a new order in the EHR).

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 37 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

• The EHR workflow provides the nurse the capability to administer the bolus from the
same bag or syringe using the PIV [PCD-03] transaction to send the bolus order to the
1050 pump.
• No assumption is made about the behavior of the pump once the bolus has been
delivered. Depending on the pump type or model it may stop, alarm, or resume delivering
the underlying infusion.

1055 ORC segment

• ORC-1 Order Control = “CH” (change)
• ORC-2 Placer Order Number = bolus order ID (child order ID)
• ORC-8 Parent = parent order ID

1060 A bolus order may be specified in 3 ways:

• Dose or Volume + Rate
• Dose or Volume + Duration
• Rate + Duration
The following table outlines the required and optional data for each type of bolus order.
1065
Bolus ORC-1 ORC-2 ORC-8 RXG- TQ1 OBX segment with OBX
order 15/16 segment OBX-5 = segment with
type MDCX_INFUSION_ OBX-5 =
PROGRAM_TYPE MDC_FLOW_
= clinician-dose FLUID_PUMP
Dose or “CH” Bolus Parent Dose or O R R
volume + (child) order ID volume
rate order ID amount
Dose or “CH” Bolus Parent Dose or R R O
volume + (child) order ID volume
duration order ID amount
Rate + “CH” Bolus Parent Rate R R O
duration (child) order ID
order ID

OBX segment
• Include an OBX segment specifying the order type of bolus (clinician dose) where
• OBX-5 = MDCX_INFUSION_ORDER_TYPE. This term has enumerations “clinician-
1070 dose”, “loading-dose”, and “continuous”.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 38 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

• When RXG-15 and RXG-16 specify a dose, include an OBX segment specifying the rate
where OBX-5 = MDC_FLOW_FLUID_PUMP.

When the IPEC or DEC profiles contain information about a bolus from an existing infusion,
1075 note that the PCD-01 and PCD-10 messages contain bolus information in the Clinician Dose Info
section.
In the OBR segment, OBR-2 Placer Order Number contains the order ID of the bolus as a
“child” order ID. OBR-29 Parent is used to contain the order ID for the parent (i.e., the existing
infusion).

1080 3.3.4.4.10.3 Multistep

The ordered medication and concentration must be identical in all steps.
All steps are represented in the BCMA by a single order and a single order ID.
Some pump models may support different dosing units (RXG-15 and 16) among steps (see
Example 2 in the PCD TF vol 1, Section 4.4).
1085 PCD-03 message structure
When used for multistep the HL7 RGV message structure used by PIV will require repetition of
certain segments resulting in some duplication.
The simplified message structure for multistep is shown below.
{} indicates repetition, [] indicates optionality.
1090
MSH
PID
[PV1]
ORC
1095 {
RXG
[TQ1]
RXR
OBX (multiple)
1100 }

Each step must contain:

• Step number in RXG-1 (values are 1...n)

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 39 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

• An OBX segment to indicate the type of the current step

1105 o OBX-3 = MDCX_INFUS_ORDER_STEP_TYPE
o enumerations are "loading dose" or "continuous"
o “loading dose” is optional and supported in step 1 only
• An OBX segment to indicate the total number of steps in the program
o OBX-3 = MDCX_INFUS_TOTAL_NUM_STEPS
1110 • Additional OBX segments containing the pump ID or patient parameters (e.g., height,
weight, BSA) as required
The following table applies to how data is provided in PCD-01 and PCD-10 messages when the
IPEC or DEC Profiles are used for a multistep infusion.

Data Term Location within [PCD-01] Required

or [PCD-10] message
Current step number MDCX_INFUS_ORDER_STEP_NUM INFUSATE_SOURCE_* Yes
Total number of steps MDCX_INFUS_TOTAL_NUM_STEPS INFUSATE_SOURCE_* Yes
Current step volume to MDCX_VOL_STEP_TBI INFUSATE_SOURCE_*
be infused
Current step volume MDCX_VOL_STEP_DELIV INFUSATE_SOURCE_* Yes
delivered
Current step volume MDCX_VOL_STEP_REMAIN INFUSATE_SOURCE_*
remaining
Total volume infused MDC_VOL_FLUID_DELIV_TOTAL INFUSATE_SOURCE_* Yes
for all steps
* indicates the appropriate source

1115

3.3.4.4.11 Expected Actions

The Pharmacy/Treatment Give Message (RGV^O15^RGV_O15) is sent from the Infusion Order
Programmer to the Infusion Order Consumer.
The receiving system validates the message and responds with an accept acknowledgment
1120 message (ACK^O15^ACK). If an error condition is detected and if MSH-16 (Application
Acknowledgement Type) in the RGV^O15^RGV_O15 message is valued as "ER" or "AL", the
IOC responds with a Pharmacy/Treatment Give Acknowledgment Message
(RRG^O16^RRG_O16).
If the message is accepted by the IOC, the accept acknowledgment will contain the value CA in
1125 MSA-1. If not, the accept acknowledgment will contain either CR or CE, based upon HL7
enhanced acknowledgment rules (see HL7 v2.6, Section 2.9.3.2).
Message acceptance is based on:
• All required segments and fields are present
______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 40 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

• No incorrect data types are present.

1130 • Validation of fields that must contain specific values as defined in the Technical
Framework (e.g., MSH-21 must be "1.3.6.1.4.1.19376.1.6.1.3.1").
If MSH-16 (Application Acknowledgement Type) is valued as "ER" or "AL", the IOC may
report an application acknowledgement error using the Pharmacy/Treatment Give
Acknowledgement Message (RRG^O16^RRG_O16) for errors such as:
1135 • Unknown device
• Dose/rate and volume are not within vendor parameters for the device type.
• Drug is not present in onboard library.
If the message from the Infusion Order Programmer is rejected, the acknowledgement will
contain the value AR or AE in MSA-1, based upon HL7 enhanced acknowledgment rules (see
1140 HL7 v2.6, Section 2.9.2.2). The reason for rejection is provided in the ERR segment.
Once the programming information is received by the pump, the clinician may choose to do one
of the following: (1) confirm the settings on the pump and then start the infusion, (2) enter or
modify one or more settings and then start the infusion, or (3) reject the program before it is
started.
1145 Once the infusion is started, the settings actually programmed as well as the current state of the
infusion can be obtained using the Communicate PCD Data [PCD-01] transaction.

3.3.5 RRG^O16^RRG_O16 Pharmacy/Treatment Give Acknowledgement

Message

Table 3.3.5-1: RRG^O16^RRG_O16 Pharmacy/Treatment Give Acknowledgement

1150 Message
Segment Meaning Usage Card HL7 Chapter
MSH Message Header R [1..1] 2

MSA Message Acknowledgment R [1..1] 2

[{ ERR }] Error C [0..1] 2

[{ SFT }] Software X 2

[{ NTE }] Notes and Comments (for X 2

Header)

[ --- RESPONSE begin

[ --- PATIENT begin

PID Patient Identification O 3

[{ NTE }] Notes and Comments (for X 2

PID)

] --- PATIENT end

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 41 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Segment Meaning Usage Card HL7 Chapter

{ --- ORDER begin

ORC Common Order O 4

[{ --- TIMING begin

TQ1 Timing/Quantity X 4

[{ TQ2 }] Timing/Quantity Order X 4

Sequence
}] --- TIMING end

[ --- GIVE begin

RXG Pharmacy/Treatment Give X 4

{ --- TIMING_GIVE begin

TQ1 Timing/Quantity X 4

[{ TQ2 }] Timing/Quantity Order X 4

Sequence
} --- TIMING_GIVE end

{ RXR } Pharmacy/Treatment Route X 4

[{ RXC }] Pharmacy/Treatment X 4
Component
] --- GIVE end

} --- ORDER end

] --- RESPONSE end

3.3.5.1 MSH – Message Header Segment

The MSH segment is defined in Appendix B.1

3.3.5.2 MSA - Message Acknowledgement segment

1155 The MSA segment is defined in Appendix B.2.

3.3.5.3 ERR - Error segment

The ERR Error segment is defined in Appendix B.3.

3.4 Report Alert [PCD-04]

In anticipation of HL7 2.8 item 625, Add Alert Trigger Event, this profile is making forward
1160 looking use of the triggers and events from that item, specifically the use of ORU^R40 for [PCD-
04].

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 42 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

This section corresponds to transaction [PCD-04] of the IHE Technical Framework. Transaction
[PCD-04] is used by the Alert Reporter (AR), Alert Consumer (ACON) and the Alert Manager
(AM) Actors.

1165 3.4.1 Scope

This transaction is used by the Alert Reporter to report alerts to the Alert Manager (AM) and/or
Alert Consumer (ACON). The Alert Reporter (AR) sends alerts to the Alert Manager (AM)
and/or Alert Consumer (ACON) in an unsolicited manner.

Alert Reporter
(AR)

Report Alert

Alert Manager Alert Consumer

(AM) (ACON)
1170

3.4.2 Use Case Roles

Actor Alert Reporter

Role Sends Report Alert to the Alert Manager (AM)
Actor Alert Manager (AM)
Role Receives Report Alert from Alert Reporter for transmission to a person
Actor Alert Consumer (ACON)
Role Receives Report Alert from Alert Reporter with no expectation of transmission to
a person

1175 3.4.3 Referenced Standards

HL7 - HL7 Version 2.6 Ch7 Observation Reporting
______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 43 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

ISO/IEEE 11073-10201 Domain Information Model

ISO/IEEE 11073-10101 Nomenclature
IEC 60601-1-8 Medical electrical equipment -- Part 1-8: General requirements for basic safety
1180 and essential performance -- Collateral standard: General requirements, tests and guidance for
alarm systems in medical electrical equipment and medical electrical systems

3.4.4 Messages

3.4.4.1 Alert Reporter reports to Alert Manager/Alert Consumer

AR AM/ACON

PCD-04 Report Alert

1185 Alert Reporter sends Report Alert to Alert Manager and/or Alert Consumer as an HL7 ORU
message.

3.4.4.1.1 HL7 Conformance Statement

The conformance statement for this interaction described below is adapted from HL7 2.6.

Table 3.4.4.1.1-1: PCD-04 Transaction Conformance

Publication ID: R40

Type: Unsolicited
Publication Name: IHEPCD-04ReportAlert
Trigger: None
Mode: Immediate
Response: ORU^R40^ORU_R40
Characteristics: Sends defined alert data
Report Alert from Alert Reporter to Alert Manager
Purpose:
and/or Alert Consumer
Based on Segment Pattern: R40

1190

3.4.4.1.2 PCD-04 Report Alert (ORU^R40^ORU_R40) static definition

The Report Alert [PCD-04] message is used to communicate ACM data from an Alert Reporter
(AR) to Alert Manager (AM) and/or Alert Consumer (ACON)

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 44 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Common HL7 segments are defined in Appendix B Common Message Segments. There are
1195 sections discussing considerations specific to [PCD-04] where applicable.

AR ACON AM

Report Alert [PCD-04]

Report Alert [PCD-04

Table 3.4.4.1.2-1: ORU^R40^ORU_R40 HL7 Attribute Table

Segment ORU Message Usage Card. HL7 Ref
MSH Message Header Segment R [1..1] 2.15.9
PID Patient Identification Segment CE [0..1] 3.4.2
PV1 Patient Visit Segment CE [0..1] 3.4.3
[ORC] Common Order Segment O [0..1] 4.5.1
OBR Observation Request Segment R [1..n] 7.4.1
[PRT] Participation Segment O [0..n] 8.4.4 (V2.7)
OBX Observation Result Segment R [1..n] 7.4.2
[NTE] Notes and Comments Segment O [0..1] 2.5.10

While there can be multiple OBR segments per [PCD-04] transaction (in support of inclusion of
1200 alert common containment and evidentiary data) there is at most one alert per [PCD-04]
transaction.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 45 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Table 3.4.4.1.2-2: ORU^R40^ORU_R40 Static Definition

ORU^R40^ORU_R40 Report Alert Message

MSH Message Header
[{SFT}] Software Segment
{ --- ALERT begin
[ --- PATIENT begin
PID Patient Identification
[ --- LOCATION begin
PV1 Alert Location
] --- LOCATION end
] --- PATIENT end
{ --- ALERT_IDENTIFICATION begin
[ORC] Alert Order Common
{OBR} Alert Identification
[{ --- ALERT_OBSERVATION begin
{OBX} Alert observations relative to OBR
[PRT] Participation identifies additional notification
recipients
{ [NTE] } Notes and Comments
}] --- ALERT OBSERVATION end
} --- ALERT_IDENTIFICATION end
} --- ALERT end

A single Report Alert [PCD-04] transaction contains at most one alert for a given patient and
1205 there must be an OBR preceding each group of OBX segments.
See Appendix B for details of the contents of each segment in the [PCD-04] transaction.

3.4.4.1.3 Trigger Events

The trigger event for a [PCD-04] transaction is that the Alert Reporter has detected the presence,
onset, continuation of, or conclusion an event which may be an alert and sends it to the Alert
1210 Manager and/or Alert Consumer.

3.4.4.1.4 Message Semantics

This message is meant to convey from the Alert Reporter to the Alert Manager and/or the Alert
Consumer, the fact that an alert is present, occurring, is still occurring, or has ended along with
the data related to the alert to identify the patient and/or location, the alerting condition, and any
1215 observations associated with the alert.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 46 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

3.4.4.1.5 Expected Actions

HL7 ACK from the Alert Manager (AM) and/or the Alert Consumer (ACON) back to the Alert
Reporter (AR) is used to communicate that the Alert Manager (AM) and/or the Alert Consumer
has received the Report Alert [PCD-04] message from the Alert Reporter (AR). Report
1220 Dissemination Alert Status [PCD-07] transactions that are responses to a particular Report Alert
[PCD-04] are not rapid synchronous responses to it; since they depend on events that may take
an indeterminate amount of time, including in some cases responses by a person receiving the
alert. That is the reason that an HL7 ACK is not used to report dissemination status of the alert as
this procedure would leave the Alert Reporter (AR) awaiting HL7 ACK receipt for an
1225 indeterminate amount of time.
Status updates as to the dissemination of the alert are optional and are communicated using the
Report Alarm Status [PCD-05] transaction from the Alert Manager (AM) to the Alert Reporter
(AR).
While the Alert Reporter to Alert Manager and/or Alert Consumer PCD-04 is one message it is
1230 likely to result in many PCD-06 messages from Alert Manager to Alert Communicator and many
PCD-07 messages from Alert Communicator back to Alert Manager and many PCD-05
messages from Alert Manager back to Alert Reporter.
If the Alert Manager implements escalation to additional recipients based upon internally defined
lack of delivery status updates or lack of operator responses then those additional [PCD-06]
1235 transactions from the Alert Manager to the Alert Communicator are likely to result in additional
PCD-05 messages from the Alert Manager back to the Alert Reporter.
Communication device operator response delays may result in delays of Alert Communicator to
Alert Manager and Alert Manager back to Alert Reporter messages.
Instances of the Participation Information Segment (PRT) are optionally used by the Alert
1240 Reporter (AR) in the PCD-04 message to indicate alert notification recipients which are in
addition to any alert notification recipients identified internally by the Alert Manager (AM).

3.4.4.1.6 Security Considerations

During the profile development there were no unusual security/privacy concerns identified.
There are no mandatory security controls but the implementer is encouraged to use the
1245 underlying security and privacy profiles from ITI that are appropriate to the transports such as
the Audit Trail and Node Authentication (ATNA) Profile. The operational environment risk
assessment, following ISO 80001, will determine the actual security and safety controls
employed.

3.5 Report Alert Status [PCD-05]

1250 This section corresponds to transaction [PCD-05] of the IHE Technical Framework. Transaction
[PCD-05] is used by the Alert Manager (AM) to report alert communication, status updates, and
operator responses to the Alert Reporter (AR).

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 47 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

3.5.1 Scope
This transaction is used by the Alert Manager (AM) to report one or more dissemination status
1255 updates back to the Alert Reporter.

3.5.2 Use Case Roles

Alert Manager Alert Reporter

(AM) (AR)

Report
Alert Status

1260 Actor: Alert Manager (AM)

Role: Sends Report Alert Status to Alert Reporter (AR)
Actor: Alert Reporter (AR)
Role: Receives Report Alert Status from the Alert Manager (AM)

3.5.3 Referenced Standard

1265 HL7 - HL7 Version 2.6 Ch7 Observation Reporting
ISO/IEEE 11073-10201 Domain Information Model
ISO/IEEE 11073-10101 Nomenclature

3.5.4 Messages

1270

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 48 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

AR AM AC

PCD-04 Report Alert

PCD-06 Disseminate Alarm

PCD-07 Report Dissemination

Alert Status

Opt
PCD-05 Report Alert
Status

Figure 3.5.4-1: ACM Interaction Diagram

3.5.4.1 Alert Manager status updates to Alert Reporter

The Alert Manager sends Report Alert Status transactions to the Alert Reporter as an HL7
1275 message.

3.5.4.1.1 Trigger Events

The Alert Manager has determined either through configuration and contextual data driven
decision rules or through receipt of Report Dissemination Alert Status from the Alert
Communicator that an alert status update needs to be sent to the Alert Reporter.
1280 Alert Manager internal trigger events include the following:
• Accept (not specified, correct)
• Reject (not specified, nuisance but correct, false positive)
• Deliverable, had a mapped destination
• Undeliverable, couldn’t communicate message to endpoint device
1285 • Queued to communications

3.5.4.1.2 Message Semantics

This message is meant to convey from the Alert Manager to the Alert Reporter the dissemination
and response status of the alert message back for the Alert Reporter.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 49 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

3.5.4.1.3 HL7 Conformance Statement

1290 The conformance statement for the interaction described below is adapted from HL7 2.6 with the
addition of the PRT segment from 2.7
In conformance with the released version of HL7 2.8 the ACM Profile Report Alert Status [PCD-
05] transaction which reports alert notification delivery and response status from the Alert
Communicator back through the Alert Manager (AM) to the Alert Report (AR) uses trigger R41
1295 with message type ORA and a message template of ORA_R1 for an effective MSH-9 field value
of ORA^R41^ORA_R41.
A template of R41 is required as the R01 template is not sufficiently flexible in communicating
the multiple patient, location, device and logging stimulus use cases of the ACM Profile.
In an R41 the Participation Information (PRT) segment PRT-4 field AAP (Alert Acknowledging
1300 Provider) is used to indicate the identity of the person to which the alert has been delivered
and/or acknowledged. The information source for delivery confirmation and response
information for the potentially multiple [PCD-05] transactions content are the potentially
multiple [PCD-07] transactions from the Alert Communicator (AC) to the Alert Manager (AM).

Table 3.5.4.1.3-1: Transaction Conformance

Publication ID: R41
Type: Unsolicited
Publication Name: IHEPCD-05ReportAlarmStatus
Trigger: None
Mode: Immediate
Response: ORA^R41^ORA_R41
Characteristics: Sends alarm status data
Purpose: Provide alarm status from Alert Manager to Alert Reporter
Based on Segment Pattern: R41

1305

3.5.4.1.4 PCD-05 Report Alert Status (ORA^R41^ORA_R41) static definition

The PCD-05 Report Alert Status message is used to communicate ACM messaging status from
an Alert Manager (AM) to an Alert Reporter (AR)
Common HL7 segments are defined in Appendix B Common Message Segments.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 50 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

1310 Table 3.5.4.1.4.-1: ORA^R41^ORA_R41 static definition

ORA^R41^ORA_R41 ORU Message Usage Card. Section Ref
MSH Message Header R [1..1] 2.15.9
Segment
PID Patient Identification CE [1..1] 3.4.2
Segment
PV1 Patient Visit Segment CD [1..1] 3.4.3
[ORC] Common Order O [0..1] 4.5.1
Segment
OBR Observation Request R [1..n] 7.4.1
Segment
[PRT] Participation O [0..n] HL7 2.7 7.4.4
Information Segment
OBX Observation Result O [0..n] 7.4.1
Segment
[NTE] Notes and Comments O [0..1] 2.5.10
Segment

While there can be multiple OBR segments per transaction there is at most one alert on which
status is reported per transaction.

3.5.4.1.5 Expected Actions

1315 Alert Reporter takes appropriate action based upon alert status update. At a minimum, this shall
include the Alert Reporter logging receipt of the PCD-05 message.
Actions by the Alert Reporter to indicate whether or not the alert notification text message was
successfully disseminated (not possible with one-way pager devices), the identification of the
recipients (not possible if notification assignments are by device identification and not by person
1320 identification), and how they responded (not possible with one-way pager devices) would be
informative, but is not a requirement of this profile.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 51 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Quiet Hospital ACM Alert Timing Diagram

(actors left to right, time top to bottom)

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 52 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

3.5.4.1.6 Security Considerations

This profile while utilizing communication capabilities supportive of authentication, encryption,
1325 or auditing, does not impose specific requirements leaving these matters to site-specific policy or
agreement. The IHE PCD Technical Framework identifies security requirements across all PCD
profiles. During the Profile development there were no unusual security/privacy concerns
identified. There are no mandatory security controls but the implementer is encouraged to use the
underlying security and privacy profiles from ITI that are appropriate to the transports such as
1330 the Audit Trail and Node Authentication (ATNA) Profile. The operational environment risk
assessment, following ISO 80001, will determine the actual security and safety controls
employed.

3.6 Disseminate Alert [PCD-06]

This section corresponds to transaction [PCD-06] of the IHE Technical Framework. Transaction
1335 [PCD-06] is used by the Alert Manager (AM) to disseminate alerts to the Alert Communicator
(AC).

3.6.1 Scope
This transaction is used by Alert Manager (AM) to disseminate the alert to the Alert
Communicator (AC).

1340 3.6.2 Use Case Roles

Alert Manager Alert

(AM) Communicator
(AR)

Disseminate
Alert

Actor Alert Manager (AM)

Role Sends Disseminate Alert to Alert Communicator (AC)
Actor Alert Communicator (AC)
Role Receives Disseminate Alert from the Alert Manager (AM)

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 53 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

3.6.3 Referenced Standard

1345 The communication protocol between the Alert Manager and Alert Communicator Actors shall
be WCTP. The communicated data items are in scope for this profile (for details see Appendix K
Message Transport Using WCTP (ACM Transactions [PCD-06] and [PCD-07])). See the current
version of IHE PCD Rosetta Terminology Mapping (RTM) for the list of standardized alert
terms that may be used within PCD-04 messages (see the NIST Rosetta Terminology Mapping
1350 Management Service websites, http://rtmms.nist.gov).
While alert related data items available to the Alert Manager are specified in this profile, the
ability of individual communication devices to communicate, display, or respond to those data
items is dependent upon the product capabilities and site specific configuration of the Alert
Communicator, the communication device, and the available communication infrastructure.
1355 The base standard for Alert Manager to Alert Communicator communication is Wireless
Communications Transfer Protocol (WCTP) Protocol Specification version 1.3 update 1
(http://www.wctp.org/release/wctp-v1r3_update1.pdf)
ISO/IEEE 11073-10201 Domain Information Model
ISO/IEEE 11073-10101 Nomenclature

1360 3.6.4 Messages

3.6.4.1 Alert Manager disseminate alert to Alert Communicator

Alert Manager sends Disseminate Alert to Alert Communicator. The protocol between the Alert
Manager and Alert Communicator Actors shall be WCTP.

3.6.4.1.1 HL7 Conformance Statement

1365 The communication protocol shall be WCTP. There is therefore no specified HL7 conformance.

3.6.4.1.2 PCD-06 Disseminate Alert static definition

The PCD-06 Disseminate Alert message is used to communicate ACM data from an Alert
Manager (AM) to the Alert Communicator (AC).
The text message within the [PCD-06] transaction is meant to be readily recognized and acted
1370 upon by people. Accordingly, it should be as short as they can be made while still conveying the
important information, and easily understood by the intended recipients. Most communication
device displays are limited in size; so long messages are undesirable as they require scrolling to
review the entire message before acting upon it to make sure that no pertinent information is
overlooked.
1375 If the [PCD-06] includes a human readable text description of the alert indication, that is the
preferred description to be presented on the wireless endpoint communication device. In the
absence of such information, the Alert Manager should produce the human readable text
description from other information present in the transaction.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 54 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

In planning the use of this transaction, implementers should assure that regulatory requirements
1380 and institutional policy regarding the protection of personal health information are properly
accounted for including any need for authentication or encryption of the communications.

3.6.4.1.3 Trigger Events

The Alert Manager has determined that an alert needs to be disseminated and so sends it to each
Alert Communicator endpoint device associated with the mapping of the alert source to the alert
1385 notification destination.

3.6.4.1.4 Message Semantics

This message communicates alerts to communication endpoint devices.
The table below lists the data items and their optionality. All of these data items are within the
WCTP message text.

1390 Table 3.6.4.1.4-1: PCD-06 static definition

PCD-06 Fields Usage Card.
Alert_Location Alert associated location based upon CE [0..1]
information from PV1-3
Alert_Patient Patient Identification CE [0..1]
Alert_Text Textual alert identification R [1..1]
Alert_Identifier Alert unique identifier O [0..1]
Alert_Callback Call back connection information O [0..1]
Alert_Reference URL or application link potentially O [0..1]
containing alert or patient contextual
information
Alert_Comment Notes and Comments associated with O [0..1]
alert
Alert_Evidentiary_Data Evidentiary data (WCM) associated with O [0..1]
alert content
See Appendix K for WCTP messaging
information
Alert_Graphical_Snippet Graphical snippet associated with Alert O [0..n]
(WCM) content
See Appendix K for WCTP messaging
information
Alert_Information Information associated with alert O [0..1]
content, See Appendix K for WCTP
messaging information

3.6.4.1.5 Expected Actions

Alert Communicator sends alert to endpoint. If the endpoint is a group then the Alert
Communicator is expected to send the alert notification to all members of the group.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 55 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

1395 3.6.4.1.6 Security Considerations

This profile while utilizing communication capabilities supportive of authentication, encryption,
or auditing, does not impose specific requirements leaving these matters to site-specific policy or
agreement. During the Profile development there were no unusual security/privacy concerns
identified. There are no mandatory security controls but the implementer is encouraged to use the
1400 underlying security and privacy profiles from ITI that are appropriate to the transports such as
the Audit Trail and Node Authentication (ATNA) Profile. The operational environment risk
assessment, following ISO 80001, will determine the actual security and safety controls
employed.

3.7 Report Dissemination Alert Status [PCD-07]

1405 This section corresponds to transaction [PCD-07] of the IHE Technical Framework. Transaction
[PCD-07] is used by the Alert Communicator to signal dissemination status updates and replies
to the Alert Manager (AM).

3.7.1 Scope
This transaction is used by Alert Communicator to report one or more dissemination status
1410 updates and/or replies to the Alert Manager (AM). A single [PCD-06] transaction from the Alert
Manager to the Alert Communicator can result in numerous [PCD-07] transactions from the
Alert Communicator back to the Alert Manager.

Alert Alert Manager

Communicator (AM)
(AC)

Report
Dissemination Alert
Status

1415

3.7.2 Use Case Roles

Actor Alert Communicator (AC)

Role Sends Dissemination Status to the Alert Manager (AM)

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 56 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Actor Alert Manager (AM)

Role Receives Dissemination Status from the Alert Communicator (AC)

3.7.3 Referenced Standards

1420 WCTP version 1.3 update 1
ISO/IEEE 11073-10201 Domain Information Model
ISO/IEEE 11073-10101 Nomenclature
IEC 60601-1-8 Medical electrical equipment -- Part 1-8: General requirements for basic safety
and essential performance -- Collateral standard: General requirements, tests and guidance for
1425 alarm systems in medical electrical equipment and medical electrical systems
The communication protocol is WCTP, the same as for the Disseminate Alert [PCD-06]
transaction. See Appendix K, Message Transport Using WCTP (ACM Transactions [PCD-06]
and [PCD-07]) for details.

3.7.4 Messages

1430 3.7.4.1 Alert Communicator status updates to Alert Manager

The Alert Communicator sends Dissemination Status to the Alert Manager. The protocol utilized
is WCTP.

3.7.4.2 Trigger Events

The Alert Communicator has determined a dissemination status update needs to be sent to the
1435 Alert Manager.
The following table lists the results of the dissemination from the Alert Communicator back to
the Alert Manager. The required Communication Status Enumerations are indicated.

Table 3.7.4.2-1: Status Enumerations

Usage Communication Status Enumeration
R Received by communications (accepted by WCTP gateway)
O Undeliverable to endpoint
Optional in support of one-way devices, such as pagers.
O Delivered to endpoint
Optional in support of one-way devices, such as pagers.
O Read at endpoint
Optional in support of one-way devices, such as pagers.
O Accepted by endpoint
Optional in support of one-way devices, such as pagers.
O Accepted by endpoint as true positive

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 57 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Usage Communication Status Enumeration

O Accepted by endpoint as true positive however not clinically relevant
O Accepted by endpoint as false positive
O Rejected by endpoint
Optional in support of one-way devices, such as pagers.
O Cancelled by endpoint
O Cancelled by other than endpoint
O Callback start at endpoint
See Appendix K for WCTP messaging details.
Optional as not supported by all notification devices.
O Callback end at endpoint
See Appendix K for WCTP messaging details.
Optional as not supported by all notification devices.
O Completed by endpoint operator
Optional in support of one-way devices, such as pagers.

1440 A single [PCD-04] to [PCD-06] transaction may go through multiple communications status
updates as the alert is communicated to the endpoint user or application. Which of the status
updates are possible depend on the capabilities of the Alert Communicator and endpoint. Some
endpoint devices are output only and do not support two-way capabilities, while other devices
and services offer transmission confirmation. More advanced communications endpoints offer
1445 two-way capabilities allowing the operator of the endpoint to accept or cancel the alert.
An Alert Communicator actor might maintain internal alert dissemination recipient lists in
additional to the dissemination recipient mappings of the Alert Manager. This might be the case
if the Alert Communicator is a commercial message dissemination service provider. The Alert
Manager actor might not be aware of all of the individual recipients in such lists. This may result
1450 in additional PCD-07 Report Dissemination Alert Status transactions being sent by the Alert
Communicator to the Alert Manager for which there was no recipient specific PCD-06
transaction from the Alert Manager to the Alert Communicator. These additional PCD-07
transactions may result in additional PCD-05 Report Alert Status transactions being sent from
the Alert Manager to the Alert Reporter.
1455 Detailed reason for status can optionally be included in the WCTP errorText element to account
for messages not reaching the endpoint, or being rejected by the endpoint, because the device is
known to be offline or in a busy or do not disturb state. See details in WCTP interface
specification.

3.7.4.2.1 Message Semantics

1460 This message is used to communicate status updates on the communication of an alert to
endpoints. See Appendix K for WCTP messaging specifics.

3.7.4.2.2 HL7 Conformance Statement

The communication protocol is WCTP; therefore, there is no specified HL7 conformance.
______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 58 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

3.7.4.2.3 PCD-07 Report Dissemination Alert Status static definition

1465 The PCD-07 Dissemination Status message is used to communicate ACM messaging status and
replies from an Alert Communicator (AC) to Alert Manager (AM)
The Alert Communicator (AC) is not responsible for indicating that the endpoint operator has
received but not responded to the notification – as in sending “delivered to device” status,
automatically displayed, which may or may not send back read indication, but no operator
1470 interaction. Actions for non-response by the Alert Communicator (AC) endpoint operator
(clinical user) (escalation or sending to alternate devices) is within the scope of the Alert
Manager (AM). Such actions have been identified within the ACM Profile as out of scope.
The endpoint device message communication protocol between the Alert Communicator and the
endpoint device is outside the scope of the profile. The data presentation by the endpoint device
1475 is outside the scope of the profile.
The table below lists the data items and their optionality.

Table 3.7.4.2.3-1: PCD-07 static definition

PCD-07 ORU Message Usage Card.
Alert _Identifier Alert unique identifier R [1..1]
(see [PCD-06])
Alert _Status Communication Status Enumeration item R [1..1]
Alert_Information Information associated with alert content, see O [0..1]
Appendix K for WCTP messaging
information

3.7.4.2.4 Expected Actions

1480 Based upon the status of the delivery or the operator response the Alert Manager may effect
changes in its own internal escalation process to select and send the message to a different device
associated with the same user or a device associated with a different user.
If the Alert Manager supports the PCD-05 message then in response to each PCD-07 message a
PCD-05 message is sent from the Alert Manager to the Alert Reporter to update the Alert
1485 Reporter as to alert dissemination status updates and operator responses to the alert PCD-06
message.

3.7.4.2.5 Security Considerations

This profile while utilizing communication capabilities supportive of authentication, encryption,
or auditing, does not impose specific requirements leaving these matters to site-specific policy or
1490 agreement. The IHE PCD Technical Framework identifies security requirements across all PCD
profiles. During the profile development there were no unusual security/privacy concerns
identified. There are no mandatory security controls but the implementer is encouraged to use the
underlying security and privacy profiles from ITI that are appropriate to the transports such as
the Audit Trail and Node Authentication (ATNA) Profile. The operational environment risk

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 59 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

1495 assessment, following ISO 80001, will determine the actual security and safety controls
employed.

3.8 [PCD-08] Reserved

3.9 Communicate IDC Observations [PCD-09]

This section corresponds to transaction [PCD-09] of the IHE Technical Framework. Transaction
1500 [PCD-09] is used by the Implantable Device – Cardiac – Reporter and Implantable Device –
Cardiac – Consumer Actors.

3.9.1 Scope
In the Communicate IDC Observation transaction, the Implantable Device – Cardiac – Reporter
sends the observation as an unsolicited HL7 ORU message to the Implantable Device – Cardiac
1505 – Consumer.

3.9.2 Use Case Roles

Implantable Device Implantable Device

– Cardiac – – Cardiac –
Reporter Consumer

Communicate IDC
Observation

Figure 3.9.2-1: Communicate IDC Observation

Actor Implantable Device – Cardiac – Reporter

Role Outputs the Observation as an HL7 ORU message upon completion of the
observation. This message contains the discrete data for the observation and/or a
PDF document containing displayable data relating to the observation.
Actor Implantable Device – Cardiac – Consumer

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 60 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Role Receives the HL7 ORU message and provides some implementation-specific
processing. This may include creation of reports, integration of information into
electronic health records, or creation of derived data (trends, analyses,
reformatted data, population statistics, etc.). If needed, it will reconcile patient
identification using an implementation-specific mapping function.
1510

3.9.3 Referenced Standard

HL7 Messaging Standard v2.6
Note: The IDCO is functional with HL7 Messaging Standard v2.5. The only change required is
when specifying in the message header which version is being used.
1515 ISO 19005-1. Document management – Electronic document file format for long-term
preservation – Part 1: Use of PDF (PDF/A)
UCUM: Unified Code for Units of Measure, Regenstrief Institute for Health Care, Indianapolis
2005. Version 1.6
IEEE 11073_10103 MDC_IDC Nomenclature

1520 3.9.4 Messages

3.9.4.1 HL7 ORU Observation

This is a standard HL7 v2.6 unsolicited orders and observation message containing the
observations taken by the implanted device. Information is coded using the IEEE 11073-10103
1525 IDC Nomenclature.

3.9.4.1.1 Trigger Events

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 61 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

ORU Observation Results Usage Card HL7 Spec

Message Chapter
MSH Message Header [1..1] 2
[{ SFT }] Software Segment [0..1] 2
PID Patient Identification Demographics for id [1..1] 3
matching
[ PV1 ] Patient Visit [0..1] 3
{ Order Observation Repeat [1..*]
Grouping BEGIN
OBR Observations Request Clinical context [1..1] 7
{[NTE]} Notes Section Notes related to OBR [0..*]
{OBX} Observation results Observations related to [0..*] 7
the pulse generator
{[NTE]} Notes Section Notes Related to OBX [0..*]
} Order Observation Repeat
Grouping END
[DSC] Continuation Pointer [0..0] 2

The Implantable Device – Cardiac – Reporter initiates the HL7 ORU message to the Implantable
1530 Device – Cardiac – Consumer following an implanted cardiac device interrogation.

3.9.4.1.2 Message Semantics

The message is an unsolicited v2.6 ORU message from the Implantable Device – Cardiac –
Reporter to the Implantable Device – Cardiac – Consumer with a corresponding ACK message
back to the Implantable Device – Cardiac – Reporter. The contents of the message (in OBX
1535 segments) are a required set of individual observations or measurements trans-coded into
separate HL7 v2.6 OBX segments and an optional encapsulated PDF document.
Refer to the HL7 v2.6 Standard, Chapter 7 ORU Message for general message semantics.
The constrained message structure is given in Table 3.9.4.1.2-1, with additional details provided
in sections below.

1540 Table 3.9.4.1.2-1: ORU Message Structure

ORU Observation Results Usage Card HL7 Spec
Message Chapter
MSH Message Header [1..1] 2
[{ SFT Software Segment [0..1] 2
}]
PID Patient Identification Demographics for id matching [1..1] 3
[ PV1 ] Patient Visit [0..1] 3
{ Order Observation Repeat [1..*]
Grouping BEGIN
OBR Observations Request Clinical context [1..1] 7

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 62 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

ORU Observation Results Usage Card HL7 Spec

Message Chapter
[NTE]} Notes Section Notes related to OBR [0..*]
{OBX} Observation results Observations related to the pulse [0..*] 7
generator
[NTE]} Notes Section Notes Related to OBX [0..*]
} Order Observation Repeat
Grouping END
[DSC] Continuation Pointer [0..0] 2

3.9.4.1.2.1 MSH Segment – Message Header

Table 3.9.4.1.2.1-1: MSH Segment

Seq DT Len Opt Rep Min Max Tbl Fixed Ex Val
Field Separator 1 ST 1 R False 1 1 Y |
Encoding 2 ST 4 R False 1 1 Y ^~\&
Characters
Sending 3 HD 227 RE False 0 1 0361
Application
namespace ID 1 IS 20 O 0 1 0300 APP
NAME
Sending Facility 4 HD 227 RE False 0 1 0362
namespace ID 1 IS 20 O 0 1 0300 VENDOR
NAME
Receiving 5 HD 227 RE False 0 1 0361
Application
namespace ID 1 IS 20 O 0 1 0300 CLINIC
APPLICA
TION
Receiving 6 HD 227 RE False 0 1 0362
Facility
namespace ID 1 IS 20 O 0 1 0300 CLINIC
ID
Date/Time Of 7 TS 26 R False 1 1
Message
time 1 DT 24 R 1 1 200403281
M 34623.123
4+0300
Message Type 9 MS 15 R False 1 1
G
message code 1 ID 3 R 1 1 0076 Y ORU
trigger event 2 ID 3 R 1 1 0003 Y R01
message 3 ID 3 R 1 1 0003 Y ORU_R01
structure id
Message Control 10 ST 20 R False 1 1 123456789
ID 0

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 63 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Seq DT Len Opt Rep Min Max Tbl Fixed Ex Val

Processing ID 11 PT 3 R False 1 1
processing ID 1 ID 1 R 1 1 0103 Y P
Version ID 12 VI 971 R False 1 1
D
version ID 1 ID 5 R 1 1 0104 Y 2.6

Note: Field names are in Roman type, relevant component names within a field are listed underneath in italic type.

1545 3.9.4.1.2.2 PID Segment – Patient Identification

Table 3.9.4.1.2.2-1: PID Segment

Name Seq DT Len Opt Rep Mi Max Tbl Fixed Ex Val
n Val
Set ID - PID 1 SI 4 O 0 1
Patient 3 CX 250 R True 1 *
Identifier List
ID number 1 ST 199 R 1 1 MODEL:X
XX/SERIA
L:XXX
Assigning 4 HD 227 R 1 1 0363 BSC
authority
identifier type 5 ID 5 O 0 1 0203 U
code
Patient Name 5 XPN 294 RE True 1 *
family name 1 FN 194 O 0 1 DOE
given name 2 ST 30 O 0 1 JOHN
second and 3 ST 30 O 0 1 S
further given
names or
initials
thereof
suffix (e.g., 4 ST 20 O 0 1 JR
JR or III)
Date/Time of 7 TS 26 RE False 0 1
Birth
time 1 DTM 24 RE 1 1 19600328
Administrative 8 IS 1 RE False 0 1 0001 M
Sex
Patient Address 11 XAD 513 RE True 0 *
street address 1 SAD 184 O 0 1 12345
Some
Street
other 2 ST 120 O 0 1 Apartment
designation 123
city 3 ST 50 O 0 1 Town

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 64 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Name Seq DT Len Opt Rep Mi Max Tbl Fixed Ex Val

n Val
state or 4 ST 50 O 0 1 MN
province
zip or postal 5 ST 12 O 0 1 12345
code
country 6 ID 3 O 0 1 0399 USA

Note: Field names are in Roman type, relevant component names within a field are listed underneath in italic type.

PID-3.1 Patient Identifier List

1550 ID Number contains a unique identifier for the patient assigned by the Implantable
Device – Cardiac – Reporter. Identifier Type Code is constrained by Table 0203 listed
below (others can be included as defined in the 2.6 standard). The first identifier will
always be the unique model/serial number of the implanted device with an identifier of
type U (see table following). This will be used by the Implantable Device – Cardiac –
1555 Consumer / Repository to match the device interrogations with the patient accounts.
Assigning Authority will be a unique name of the Implantable Device – Cardiac –
Reporter system or owning organization that creates the observation and will be coded
using the MDC_IDC Nomenclature, MDC_IDC_DEV_MFG term.

Table 3.9.4.1.2.2-2: HL7 Table 0203

Code Description Notes Usage
U Model and Serial Number of Device Model and Serial number will be concatenated R
IEEE 11073_10103 together and will be unique within an Assigning
MDC_IDC_DEV_MODEL and Authority.
MDC_IDC_DEV_SERIAL The format of the ID will be following:
"model:xxx/serial:yyy"
Example: model:XZY987/serial:abc123
SS Patient Social Security Number Social Security number will be included if known. RE

1560

3.9.4.1.2.3 PV1 Segment – Patient Visit (Optional)

Table 3.9.4.1.2.3-1: PV1 Segment

Name Seq DT Len Opt Rep Min Max Tbl Fixed Ex Val
Value
Set ID - PV1 1 SI 4 O False 0 1 1
Patient Class 2 IS 1 R False 1 1 0004 R
Attending 7 XCN 309 O True 0 * 0010
Doctor
ID number 1 ST 15 O 0 1 MWEL
BY
family name 2 FN 194 O 0 1 Welby

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 65 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Name Seq DT Len Opt Rep Min Max Tbl Fixed Ex Val
Value
given name 3 ST 30 O 0 1 Marcus
second and 4 ST 30 O 0 1 A
further given
names or
initials
thereof
suffix (e.g., 5 ST 20 O 0 1 III
JR or III)
prefix (e.g., 6 ST 20 O 0 1 DR
DR)
Visit Number 19 CX 250 O False 0 1
ID number 1 ST 15 O 0 1 123456

Note: Field names are in Roman type, relevant component names within a field are listed underneath in italic type.

1565 Because this is an unsolicited observation and the Implantable Device – Cardiac – Reporter will
not be aware of an associated order, this segment is optional. The Implantable Device – Cardiac
– Reporter may want to track the interrogation as a visit using this segment. If information is
provided here it will match corresponding information provided in the OBX segments.
PV1-7 Attending Doctor will optionally be captured by the Implantable Device – Cardiac –
1570 Reporter. If present, PV1-7.1 Attending Doctor ID Number will be a unique identifier for each
doctor in the context of the Implantable Device – Cardiac – Reporter, not the Implantable Device
– Cardiac – Consumer.
PV1-19 Visit Number, ID Number will be a unique identifier generated by the Implantable
Device – Cardiac – Reporter for each visit.

1575 3.9.4.1.2.4 OBR Segment – Observation Request

The ORU message may include discrete OBX segments for individual observations reported. An
OBR Segment will be used for each set of such OBX segments to establish the equipment
context for the observations (i.e., whether the interrogation was done in-clinic or remote). All
observation dates and times reported here should match OBX segments that report the same
1580 information.

Table 3.9.4.1.2.4-1: OBR Segment

Name Seq DT Len Opt Rep Min Max Tbl Fixed Ex Val
Val
Set ID – OBR 1 SI 4 O False 0 1 1
Placer Order 2 EI 424 O False 0 1
Number
entity 1 ST 199 O 0 1
identifier

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 66 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Name Seq DT Len Opt Rep Min Max Tbl Fixed Ex Val
Val
Filler Order 3 EI 424 R False 1 1
Number
entity identifier 1 ST 199 O 0 1 123456
Universal 4 CWE 478 R False 1 1
Service
Identifier
identifier 1 ST 20 R 1 1 Remote
text 2 ST 199 O 0 1
Observation 7 TS 26 C False 0 1
Date/Time
time 1 DTM 24 R 1 1 20040328
134623.1
234+0300
Observation 8 TS 26 O False 0 1
End Date/Time
time 1 DTM 24 R 1 1 20040328
134623.1
234+0300
Results 22 TS 26 C False 0 1
Rpt/Status
Chng -
Date/Time
Time 1 DTM 24 R 1 1 20040328
134623.1
234+0300
Result Status 25 ID 1 C False 0 1 0123 F

Note: Field names are in Roman type, relevant component names within a field are listed underneath in italic type.

OBR-2 Placer Order Number will usually be empty given that this is an unsolicited order.
1585 OBR-3 Filler Order Number will contain a unique identifier for the observation / interrogation
session generated by the Implantable Device – Cardiac – Reporter.
OBR-4.1-2 Universal Service ID, Identifier and Text can identify unique OBR segments that
partition observations. The values for this field will be taken from the 11073_10103
MDC_IDC_SESS_TYPE enumerator MDC_IDC_ENUM_SESS_TYPE.
1590 OBR-25 Result Status values will be one of the values in Table 3.9.4.1.2.4-2.

Table 3.9.4.1.2.4-2: Result Status

Value Description
R Results stored; not yet verified
P Preliminary: A verified early result is available, final results not yet obtained
F Final results; results stored and verified. Can only be changed with a corrected result.
C Correction to results

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 67 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

3.9.4.1.2.5 OBX Segments – Pulse Generator and Lead Observation Results

Discrete OBX segments for individual observations will be encoded into separate OBX segments
as individual observations or measurements. These OBX segments will be preceded by an
1595 appropriate OBR segment (see Section 3.9.4.1.2.4) to set the context for observations dealing
with the implantable devices or leads.

Table 3.9.4.1.2.5-1: OBX Segment

Name Se DT Len Opt Rep Mi Ma Tbl Fixed Ex Val
q n x Value
Set ID - 1 SI 4 R False 1 1 1
OBX
Value Type 2 ID 3 R False 1 1 0125 CWE
Observation 3 CWE 478 R False 1 1
Identifier
identifier 1 ST 20 R 1 1 720897
text 2 ST 199 O 0 1 MDC_IDC_D
EV_TYPE
name of 3 ID 20 R 1 1 0396 MDC
coding
system
Observati 4 ST 20 RE False 0 1 1
on Sub-ID
Observati 5 varies 9999 RE True 0 * ICD
on Value 9
source ST 10 RE 0 1 Y
application 1
type of data
Units 6 CWE 478 RE False 0 1
identifier 1 ST 20 RE 0 1
text 2 ST 199 O 0 1
Abnormal 8 IS 5 O True 0 * 0078
Flags
Observation 11 ID 1 R False 1 1 0085
Result
Status
Date/Time 14 TS 26 RE False 0 1
of the
Observation
time 1 DTM 24 RE 0 0 1 200704221701
25
Observation 17 CWE 478 O True 0 *
Method
identifier 1 ST 20 R 1 1
text 2 ST 199 R 1 1

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 68 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Name Se DT Len Opt Rep Mi Ma Tbl Fixed Ex Val

q n x Value
Equipment 18 EI 424 O True 0 *
Instance
Identifier
entity 1 ST 199 O 0 1
identifier

Note: Field names are in Roman type, relevant component names within a field are listed underneath in italic type.

1600 OBX-1 Set ID – This field contains the sequence number.

OBX-2 Value Type – The HL7 data type of the Observation Value will depend on the
P11073_10103 term data type, as shown in Table 3.9.4.1.2.5-2.

Table 3.9.4.1.2.5-2: IEEE to HL7 Data Type Matching

Applicable IEEE 11073 MDC_IDC types HL7 v2 data type
String ST
Enumerated CWE or CNE
Date Time DTM
Numeric NM
Structured Numeric SN (see Note)

Note: The Structured Numeric type (SN) is used for numeric terms that require qualifications. SN types may be qualified as
1605 >Num1 or <Num1 to express a ‘greater than’ or ‘less than’ relationship using the ‘comparator’ character > or <
respectively. Alternatively, a numeric ratio between two values Num1 and Num2 may be expressed using the
Separator/Suffix characters ‘/’ (solidus) or ‘:’ (either character may be used).

OBX-3.1 Observation Identifier, Identifier shall be <Code> [numeric] as defined in Annex C.3
1610 ‘Expanded Terms’ of IEEE 11073-10103 (see 3.9.3 Referenced Standards).
OBX-3.2 Observation Identifier, shall be <Reference ID> as defined in Annex C.3 ‘Expanded
Terms’ in IEEE 11073-10103 (see 3.9.3 Referenced Standards)
OBX-3.3 Observation Identifier, Name of Coding System shall be MDC to reference the group
of medical device communication standards (IEEE 11073-1010x)
1615 OBX-4 Observation Sub-ID – If a value is provided here the embedded PDF will contain data
related to a specific episode or EGM being referenced via grouping to other episode related data
elements having the same Sub-ID in OBX-4 inside this message.
OBX-5 Observation Value – This is the actual value of the observation.
If OBX-2 is of type CWE then
1620 OBX-5.1 shall be <Code> [numeric] as defined in Annex D.3 ‘enumerations’ or Annex E.3
‘vendor enumerations’ of IEEE 11073-10103 (see 3.9.3 Referenced Standards) .

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 69 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

OBX-5.2 shall be <Enumerator Identifier>_<EnumerationCode [mnemonic]> as defined in

Annex D.3 ‘enumerations’ or Annex E.3 ‘vendor enumerations’ in IEEE 11073-10103 (see 3.9.3
Referenced Standards)
1625 OBX-5.3 shall be MDC to reference the group of medical device communication standards
(IEEE 11073-1010x)
OBX-5.9 may contain the according Display Name as defined in Annex D.3 ‘enumerations’ or
Annex E.3 ‘vendor enumerations’ of IEEE 11073-10103 (see 3.9.3 Referenced Standard) or an
equivalent (maybe more compact) localized display name. If the vendor has implemented
1630 vendor-specific extensions (per IEEE 11073-10103 Sections 8 and A.4) than OBX-5.9 is
required. This display name should only be used by the receiving system as a reference or if the
Identifier in OBX-5.1 is unknown to the receiver (e.g., for proprietary vendor content).
Generation and localization of display in the receiving system shall always be preferred.
OBX-6 Unit – Will be coded with the MDC_IDC Nomenclature (based on UCUM) Unit for
1635 associated observation.
OBX-8 Abnormal Flags – This field will contain a code from the extended User-defined Table
0078 – Abnormal Flags as specified below.

Table 3.9.4.1.2.5-3: User-defined Table – 078 Abnormal Flags

Value Extended Description Comment
Value?
NI Yes No information. There is no No value is provided in OBX-5.
information which can be inferred
from this exceptional value.
NAV Yes Temporarily not available. No value is provided in OBX-5.
Information is not available at this
time but it is expected that it will
be available later.
OFF Yes Numeric measurement function is No value is provided in OBX-5.
available but has been deactivated
by user.
> N Above absolute high-off Provide the high-off instrument scale
instrument scale. number in OBX-5 if available.
< N Below absolute low-off Provide the low-off instrument scale
instrument scale. number in OBX-5 if available.

1640 OBX-11 Observation Result Status – This field holds the value from the table HL7 Table 0085 -
Observation result status codes interpretation. Valid values are following: F, P, R, S, & X. The
value N or X denotes a missing or null value, and in this case the OBX-5 will be empty.
OBX-14 Date/Time of Observation – This field is required when the observation reported is
different from the OBR report header. If an observation method is reported in OBX-17 the date
1645 will represent end date/time of the reported time interval.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 70 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

OBX-18 Equipment Instance Identifier – A unique identifier for the equipment or software that
was responsible for the production of the observation

3.9.4.1.2.6 IEEE 1073.1.1.3 IDC term mapping to OBX segment

In the IEEE 11073_10103 MDC_IDC nomenclature for Observation Identifiers (OBX-3) each
1650 term is discrete, self-descriptive and maps to one OBX segment. Refer to the IEEE 11073_10103
MDC_IDC standard for information concerning the IDC nomenclature.

3.9.4.1.2.7 OBX Segment with Encapsulated PDF or Reference Pointer to External

Report [Optional]
Optionally, observations or additional analyses may be provided in an encapsulated PDF
1655 containing displayable information or as a reference pointer to an external report.

Table 3.9.4.1.2.7-1: OBX Segment

Name Seq DT Len Opt Rep Min Max Tbl Fixed Ex Val
Value
Set ID - OBX 1 SI 4 R False 1 1
Value Type 2 ID 2 R False 1 0125 Y ED
Observation 3 CWE 478 R False 1 1
Identifier
identifier 1 ST 20 R 1 1 Y 18750-0
Text 2 ST 199 R 1 1 Y Cardiac
Electrophy
siology
Report
name of 3 ID 20 R 0 1 0396 Y LN
coding system
Observation 4 ST 20 RE False 0 1 1
Sub-ID
Observation 5 ED 999 R True 1 * Encapsulat
Value 99 ed PDF
source 1 ST 10 RE 0 1 Y Applicatio
application n
type of data 2 ST 10 RE 0 1 Y PDF
Encoding 4 ST 10 RE 0 1 Y Base64
Data 5 ED * RE 0 1 Y Encapsulat
ed and
Base64
binary
encoded
PDF File
Observation 11 ID 1 R False 1 1 0085
Result Status
Date/Time of 14 TS 26 RE False 0 1
the
Observation

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 71 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Name Seq DT Len Opt Rep Min Max Tbl Fixed Ex Val
Value
Time 1 DTM 24 R 1 1 200403281
34623.123
4+0300

Note: Field names are in Roman type, relevant component names within a field are listed underneath in italic type.

OBX-2 If sending an encapsulated PDF the value will be ED. If referencing an external report
1660 the value will be RP.
OBX-3 Value is a report ID from the LOINC coding system, and will be set to 18750-
0^Cardiac Electrophysiology Report^LN.

OBX-4 If a value is provided here the embedded PDF will contain data related to a specific
episode or EGM being referenced via grouping to other episode related data elements having the
1665 same Sub-ID in OBX-4 inside this message.
OBX-5 If referencing an external document the Observation Value will contain a reference
pointer to the external document.
OBX-5.1 If sending an encapsulated PDF the Type of Data component will have the value
"Application"
1670 OBX-5.2 If sending an encapsulated PDF the Data Subtype component will have the value
"PDF".
OBX-5.3 Will be empty
OBX-5.4 If sending an encapsulated PDF the Encoding component will have the value
"Base64".
1675 OBX-5.5 If sending an encapsulated PDF the Data component contains the encapsulated Base64-
encoded PDF/A document in accordance with ISO 19005-1.
Notes: 1. An actor participating in this transaction must support encapsulated data with a length beyond the nominal 65536
byte limit of the OBX-5.
2. The base64 encoded stream must not include CR/LF characters, which are forbidden within HL7 field text streams.
1680 Breaking a base64 encoded stream into lines of 76 characters or less is used for email in accordance with RFC822, but
is not applicable to encapsulated data in HL7.
The attached PDF or externally referenced report will contain in its content the device ID, patient ID and name if
known, and the dates of the procedure and document.

1685 3.9.4.1.2.8 NTE Segment – Notes and Comments [Optional]

Table 3.9.4.1.2.8-1: NTE Segment – Notes and Comments

ELEMENT SEQ COMP DT LEN USAGE CARD TBL# Fixed Ex.
NAME Values
Set ID - NTE 1 SI 4 O [0..1] 1

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 72 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

ELEMENT SEQ COMP DT LEN USAGE CARD TBL# Fixed Ex.

NAME Values
Source of 2 CX 20 O [0..1] Y L
comment
Comment 3 FT 65536 O [0..*]

NTE-3 Comments – Contains any notes, comments needed that are not included as part of an
observation.

1690 3.9.4.1.3 Expected Actions

3.9.4.1.3.1 Implantable Device – Cardiac – Consumer

The Implantable Device – Cardiac – Consumer will return the standard HL7 acknowledgement
message to the Device Observation Creator.

3.9.5 Security Considerations

1695 This profile does not require the use of ATNA. There are several implementation models for this
profile that do not require transmission of data over public networks including intra-institutional,
VPN, etc. However, when public networks are used, ATNA is one option for secure transport
over those networks. It is recommended that the Implantable Device – Cardiac – Reporter be
grouped with the Secure Node of the ATNA Profile to secure communications for remote
1700 follow-ups if data is sent across an un-trusted network.

3.10 Communicate Infusion Event Data [PCD-10]

This section corresponds to the Communicate Infusion Event Data (PCD-10) transaction of the
IHE Technical Framework. Communicate Infusion Event Data is used by the DOR and DOC
Actors.

1705 3.10.1 Scope

This transaction is used to communicate infusion event data from:
• A Device Observation Reporter (DOR) to a Device Observation Consumer (DOC).

3.10.2 Use Case Roles

Device Observation Reporter Device Observation Consumer
(DOR) (DOC)

Communicate Infusion
Event Data
1710
______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 73 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Actor: Device Observation Reporter

Role: Sends infusion event data to DOC
Actor: Device Observation Consumer
Role: Receives infusion event data from DOR

1715 3.10.3 Referenced Standard

• HL7® - Health Level 7 Version 2.6 Ch7 Observation Reporting
• ISO/IEEE 11073-10101 Nomenclature
• IEEE P11073-10101a Nomenclature

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 74 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

1720 3.10.4 Messages

Device Device
Observation Observation
Reporter Consumer
(DOR) (DOC)

1725

PCD-10 Communicate Infusion Event Data

1730

3.10.4.1 Communicate Infusion Event Data

1735 Event messages are generated by the infusion pump or Gateway during normal execution of an
infusion therapy. Example of such events are start of infusion delivery, rate change or transition
from piggyback to primary or transition to KVO. This information is sent from a DOR to a DOC.
Note that while a system is off-line, all events should be buffered and then communicated when
communication is established again. Event time stamps should indicate when the event occurred,
1740 not when it was communicated.

3.10.4.1.1 Trigger Events

The ORU^R42^ORU_R01 message is an unsolicited update initiated by the Device Observation
Reporter. The ORU^R42 can be sent with or without a preceding order, since it is common in a
clinical setting for device data to be reported without a specific order having been transacted in
1745 the information system (that is, the reporting is the result of a "standing order" for monitoring in
a particular clinical situation).

3.10.4.1.2 Message Semantics

Refer to the HL7® standard for the ORU message of HL7 2.6 Chapter 7 and the general message
semantics.
1750 The ORU^R42^ORU_R01 message structure provides the mechanism for mapping the
hierarchical structure of an IEEE 11073 containment tree to a series of OBX segments. See the
discussion of how the containment is represented using a "dotted notation" in field OBX-4
Observation Sub-ID in the PCD TF-2: Appendix B.8.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 75 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

See “ISO/IEEE Nomenclature mapping to HL7 OBX-3” in the PCD TF-2: Appendix A.1 for
1755 further information on the mapping rules.

3.10.4.1.3 Expected Actions

The ORU^R42^ORU_R01 message is sent from the DOR to the DOC. Upon receipt the DOC
validates the message and responds with an acknowledgement as defined in PCD TF-2:
Appendix G.1, Acknowledgment Modes.
1760

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 76 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Appendices

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 77 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Appendix A Mapping ISO/IEEE 11073 Domain Information Model to

HL7
Figure A-1: System Package Model represents the system level containment of the 11073 DIM.
1765

Figure A-1: System Package Model

The mapping from 11073 to HL7 will be described by focusing on the Medical Package defined
by the Medical Device System shown in Figure A-1: System Package Model and elaborated in
1770 Figure A-2: Medical Package Model.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 78 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Figure A-2: Medical Package Model

The HL7 OBX segment provides two fields which are used in mapping the objects shown in
Figure A-2: Medical Package Model; these are OBX-3 Observation Identifier and OBX-4
1775 Observation Sub-Id.
OBX-3 is expressed as an HL7 Coded Element With Exceptions (CWE) data type and the details
of mapping the 11073 MDC to the HL7 CWE datatype are described in Appendix A.1 ISO/IEEE
Nomenclature mapping to HL7 OBX-3.
OBX-4 is used to express the containment level of a particular item expressed in OBX-3. This is
1780 done by defining the nodes of the <MDS> <VMD> <CHAN> <METRIC> hierarchy of the
containment tree as a set of ordinal numbers expressed in a dotted notation such that each OBX-3
is expressed unambiguously in terms of its containment as defined by OBX-4. This may be
supplemented by a further level or levels to distinguish attributes or other subordinate structures
as may be specified in particular PCD profiles. See under OBX-4 in Appendix B for the details
1785 of the "dotted notation" used to express this containment.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 79 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Figure A-3: Example of Mapping Containment to OBX-4

For example the OBX-4 for the <VS Mon> <ECG> <Ctach> <HR> would be expressed as
1.2.1.3.
1790 NOTE: The ordinal numbers in an OBX-4 are not normative for a given parameter (identified in
OBX-3) and may vary between implementations. Each OBX-4 Sub-Id must be unique within a
given containment and message but the numbers and mappings may change between messages.
In OBX-2 the valid HL7 types for the mapping are NM, ST, SN, CWE, CF (String may have
some implied structure)
1795 The specification of the containment tree provides a mechanism to address dynamic
configuration of a PCD. For example, a patient monitor may have one or more "plug-ins" which
may be added to and removed from the patient monitor as the patient’s clinical condition
changes. These should be individually identifiable by a unique device instance identifier. When a
plug-in is removed, the ordinal numbers previously assigned to that plug-in should be reserved.
1800 Addition of a new plug-in with a different unique device instance identifier shall result in the
assignment of ordinal numbers which have not been reserved. Replacement of the "known" plug-
in after its removal shall result in the re-assignment of the same reserved ordinal number to the
plug-in that it formerly had. If the DOR system cannot distinguish individual instances of a
module, it may treat modules that are functionally equivalent as though they were the same
1805 module for the purposes of the above scheme.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 80 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

A.1 ISO/IEEE Nomenclature mapping to HL7 OBX-3

The ISO/IEEE Nomenclature provides an unambiguous coding which is mapped to HL7 OBX-3
as follows:
HL7 OBX-3 is of type CWE consisting of:

1810 Table A.1-1: HL7 Component Table - CWE - Coded With Exceptions
SEQ LEN DT Usage Card. TBL# Component Comments Sec Ref
Name
1 20 ST R [1..1] Identifier Nomenclature 2.A.74
Code
2 199 ST R [1..1] Text Reference ID 2.A.74
3 20 ID R [1..1] 0396 Name of "MDC" 2.A.35
Coding System
4 20 ST RE [0..1] Alternate 2.A.74
Identifier
5 199 ST RE [0..1] Alternate Text 2.A.74
6 20 ID RE [0..1] 0396 Name of 2.A.35
Alternate
Coding System
7 10 ST X [0..0] Coding System 2.A.74
Version ID
8 10 ST X [0..0] Alternate 2.A.74
Coding System
Version ID
9 199 ST X [0..0] Original Text 2.A.74

Definition: This data type transmits codes and the text associated with the code.

Maximum Length: 705

Where:
Nomenclature Code is the string representation of the decimal value corresponding to the context free 32 bit representation of
the Nomenclature Code
1815 [context-free] Nomenclature Code = (Code Block number * 2**16) + [context-sensitive], where [context-sensitive] is an
offset, reflecting a particular variant of an associated "discriminator". The Reference ID is also modified to reflect the
variant.
For example, for the "Device Type" Nomenclature, the Device Type discriminator is as follows:

Ref ID variant Description Term Code Offset

DEV Not otherwise specified 0
MDS Medical Device System 1
VMD Virtual Medical Device 2
CHAN Channel 3

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 81 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

1820 Nomenclature codes are obtained from IEEE-11073-10101 Medical Device Communications –
Nomenclature where available. Additional codes that are not yet standardized are contained in
the Rosetta Terminology Mapping (see IHE PCD Technical Framework Volume 3).
The context-free nomenclature code for a term in code block number 1 whose term code=4104 is
equal to ((1 * 2**16) + 4104) = 1*65536 + 4104 = 69640 (which uniquely identifies the SpO2
1825 monitor term) with a Reference ID of MDC_DEV_ANALY_SAT_O2. The context-sensitive
form for the variant "MDS” is “MDC_DEV_ANALY_SAT_O2_MDS (appending the suffix
"MDS"), and the Term Code is 69640+1 = 69641 (adding the Term Code Offset to the base
Term Code).
The OBX-3 representation is “69641^MDC_DEV_ANALY_SAT_O2_MDS^MDC"
1830 The Virtual Medical Device variants are: MDC_DEV_ANALY_SAT_O2_VMD 69642, and
"69642^ MDC_DEV_ANALY_SAT_O2_VMD^MDC" in OBX-3 representation.
To distinguish between periodic and aperiodic data, map from the IEEE 11073 Metric Access to
HL7 and code in OBX-17. This is used where you want to distinguish periodic, aperiodic etc.
Metric Category also provides distinction between manual and automatic.
1835 Examples of device data (as opposed to patient data) that may be included to allow a receiving
system to have a better record of the nature and status of a device are:
MDC_ATTR_SYS_TYPE is used to describe the type of the PCD such as monitor, ventilator,
infusion pump, and shall be mapped at the MDS level in the OBX with the value described by
OBX-3.
1840 MDC_ATTR_ID_MODEL is used to provide device vendor/model and shall be mapped at the
MDS level in the OBX with the value described by OBX-3.
The unique identification of the particular instance of the device is put in OBX-18.
MDC_ATTR_VMS_MDS_STAT describes states - disconnected, configuring, operating,
terminating, disassociated, reconfiguring.
1845 For PCDs with complex operation states such as an infusion pump with a set of states like
"Stopped", "Infusing Primary", "Infusing Secondary", "Bolus", etc., or a ventilator with states
"Standby", "Ventilating", etc., the Device Operational Status Enumeration Object is mapped to
OBX-3.
See the Rosetta Terminology Mapping documents referenced in IHE PCD Technical Framework
1850 Vol. 3 for further examples of device data.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 82 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Appendix B Common Segment Descriptions

B.1 MSH – Message Header Segment

See HL7 v2.6: chapter 2 (2.14.9)
1855 This segment defines the intent, source, destination, and some specifics of the syntax of a
message.

Table B.1-1: MSH - Message Header

SEQ LEN DT Usage Card. TBL# Element name
1 1 ST R [1..1] Field Separator
2 4 ST R [1..1] Encoding Characters
3 227 HD R [1..1] 0361 Sending Application
4 227 HD RE [0..1] 0362 Sending Facility
5 227 HD RE [0..1] 0361 Receiving Application
6 227 HD RE [0..1] 0362 Receiving Facility
7 24 DTM R [1..1] Date/Time of Message
8 40 ST X [0..0] Security
9 15 MSG R [1..1] Message Type
10 199 ST R [1..1] Message Control Id
11 3 PT R [1..1] Processing Id
12 60 VID R [1..1] Version ID
13 15 NM RE [0..1] Sequence Number
14 180 ST X [0..0] Continuation Pointer
15 2 ID R [1..1] 0155 Accept Acknowledgement Type
16 2 ID R [1..1] 0155 Application Acknowledgement Type
17 3 ID RE [0..1] 0399 Country Code
18 16 ID RE [0..1] 0211 Character Set
19 705 CWE RE [0..1] Principal Language of Message
20 20 ID X [0..0] 0356 Alternate Character Set Handling
Scheme
21 427 EI O [0..1] Message Profile Identifier
22 567 XON X [0..0] Sending Responsible Organization
23 567 XON X [0..0] Receiving Responsible Organization
24 227 HD X [0..0] Sending Network Address
25 227 HD X [0..0] Receiving Network Address

MSH-1 Field Separator

1860 The IHE PCD Technical Framework requires that applications support HL7-
recommended value that is | (ASCII 124).

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 83 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

MSH-2 Encoding Characters

This field contains the four characters in the following order: the component separator,
repetition separator, escape character, and subcomponent separator. The IHE PCD
1865 Technical Framework requires that applications support HL7-recommended values ^~\&
(ASCII 94, 126, 92, and 38, respectively).
MSH-3 Sending Application (HD)
Components: <Namespace ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID Type (ID)>

The intention of this field is to uniquely identify the software application implementing
1870 the PCD actor sending this message. For valid methods of accomplishing this, see
Hierarchic Designator (HD) Data Type, Appendix Section C.6.
MSH-4 Sending Facility
Components: <Namespace ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID Type (ID)>

For the IHE PCD Technical Framework, when populated, this field shall be implemented
1875 as:
First component (required): Namespace ID. The name of the organizational entity
responsible for the DOR, typically the provider institution or department operating the
DOR.
Second component (optional): The Universal ID (see HL7 v. 2.7 Ch. 2) of the
1880 organizational entity responsible for the DOR.
Third component (optional): The Universal ID Type. The codification of these three
components is entirely site-defined. It may be detailed in the national extensions of this
framework.
MSH-5 Receiving Application (HD)
1885 Components: <Namespace ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID Type (ID)>

For the IHE PCD Technical Framework, when populated, this field shall be implemented
as:
First component (required): Namespace ID. The name of the organizational entity
responsible for the receiving application.
1890 Second component (optional): The Universal ID (see HL7 v. 2.7 Ch. 2) of the
organizational entity responsible for the receiving application.
Third component (optional): The Universal ID Type. The codification of these three
components is entirely site-defined. It may be detailed in the national extensions of this
framework.
1895 This field is not required for IHE PCD compliance, but should be populated at the option
of the organization operating the system if the field serves a desired function, such as
facilitating the routing of messages.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 84 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

MSH-6 Receiving Facility

Components: <Namespace ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID Type (ID)>

1900 For the IHE PCD Technical Framework, when populated, this field shall be implemented
as:
First component (required): Namespace ID. The name of the organizational entity
responsible for the receiving facility.
Second component (optional): The Universal ID (see HL7 v. 2.7 Ch. 2) of the
1905 organizational entity responsible for the receiving facility.
Third component (optional): The Universal ID Type. The codification of these three
components is entirely site-defined. It may be detailed in the national extensions of this
framework.
MSH-7 Date/Time of Message:
1910 The IHE PCD TF requires this field be populated with:
Format: YYYY[MM[DD[HH[MM[SS[.S[S[S[S]]]]]]]]][+/-ZZZZ]
Time zone qualification of the date/time is required. The IHE PCD TF uses the IETF
RFC3339 “Unknown Local Offset Convention” to make it possible to distinguish
between the case where UTC is the preferred reference point for the specified, denoted
1915 with +0000, and the case where the UTC time is known, but the offset to local time is
unknown, denoted with -0000. This distinction is sometimes important in devices.
MSH-7 shall be used only to provide time a message is created by the sending system,
which is different from, and not be interpreted as, the time an observation is taken. See
Section B.8.7 Time Stamps and Time Synchronization for a discussion of general
1920 considerations on time stamps in IHE PCD messages.
MSH-9 Message Type
Components: <Message Code (ID)> ^ <Trigger Event (ID)> ^ <Message Structure (ID)>

Definition: This field contains the message type, trigger event, and the message structure
ID for the message. All three components are required.
1925 Its content is defined within each transaction-specific section of this document.
For [PCD-01], this field must contain ORU^R01^ORU_R01.
The PCD PIV Profile requires that this field be valued as follows:
• RGV^O15^RGV_O15 for the IOP to IOC message that initiates the [PCD-03]
transaction
1930 • ACK^O15^ACK for the IOC to IOP accept acknowledgment message
• RRG^O16^RRG_O16 for the IOC to IOP application acknowledgment message
• ACK^O16^ACK for the IOP to IOC acknowledgment of the IOC to IOP
application acknowledgment message

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 85 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

• For [PCD-04], this field must contain ORU^R40^ORU_R40.

1935 • For [PCD-05], this field must contain ORU^R41^ORU_R41.
MSH-10 Message Control Id
Definition: This field contains a number or other identifier that uniquely identifies the
message. Each message should be given a unique identifier by the sending system. The
receiving system shall echo this ID back to the sending system in the Message
1940 Acknowledgment segment (MSA). The combination of this identifier and the name of the
sending application (MSH-3) shall be unique across the Healthcare Enterprise.
MSH-11 Processing ID:
Components: <Processing ID (ID)> ^ <Processing Mode (ID)>

Definition: This data type indicates whether to process a message as defined in HL7
1945 Application (level 7) processing rules.
The IHE PCD Technical Framework requires the first component Processing ID be
valued based on HL7 Table 0103. Use of the second component Processing Mode is
optional but if used is based on HL7 Table 0207.
The value in production systems should be P (Production). When it is desired to
1950 recognize and isolate test data, the value D (Debugging) may be used.
MSH-12 Version ID
Components: <Version ID (ID)> ^ <Internationalization Code (CWE)> ^ <International
Version ID (CWE)>

Definition: This field is matched by the receiving system to its own version to be sure the
1955 message will be interpreted correctly.
The PCD TF is based on HL7 V2.6. Where specific elements of later versions are
required, they have been used and their usage flagged.
Although HL7 allows international affiliate versions to be specified the IHE PCD
Technical Framework uses only the core version (first component of the field).
1960 MSH-13 Sequence Number (ID), required but may be empty:
Definition: A non-null value in this field implies that the sequence number protocol is in
use. The sequence number protocol is not used in IHE PCD.
MSH-15 Accept Acknowledgement Type
Definition: This field identifies the conditions under which accept acknowledgments are
1965 required to be returned in response to this message. Required. Refer to HL7 Table 0155 -
Accept/application acknowledgment conditions for valid values. The receiving system
must send (or not send) acknowledgements as specified by this field.
In [PCD-01], [PCD-04], and [PCD-05] transactions, this field shall be valued as AL.
In [PCD-03] transactions, see Section 3.3.4.4.1

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 86 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

1970 MSH-16 Application Acknowledgement Type

Definition: This field identifies the conditions under which application acknowledgments
are required to be returned in response to this message. Required for enhanced
acknowledgment mode. Refer to HL7 Table 0155 - Accept/application acknowledgment
conditions for valid values. The PCD TF requires that this field be valued as NE for
1975 [PCD-01], [PCD-04], and [PCD-05] transactions. The receiving system must send (or not
send) acknowledgements as specified by this field.
For [PCD-03] transactions, see Section 3.3.4.4.1
MSH-17 Country Code
Definition: This field contains the country of origin for the message. It will be used
1980 primarily to specify default elements, such as currency denominations. The values to be
used are those of ISO 3166. The ISO 3166 table has three separate forms of the country
code: HL7 specifies that the 3-character (alphabetic) form be used for the country code.
MSH-18 Character Set (ID)
Definition: This field contains the character set for the entire message. Refer to HL7
1985 Table 0211 - Alternate character sets for valid values.
An HL7 message uses field MSH-18-character set to specify the character set(s) in use.
Valid values for this field are specified in HL7 Table 0211, "Alternate Character Sets".
MSH-18-character set may be left blank, or may contain a single value. If the field is left
blank, the character set in use is understood to be the 7-bit ASCII set, decimal 0 through
1990 decimal 127 (hex 00 through hex 7F). This default value may also be explicitly specified
as ASCII.
Any encoding system, single-byte or multi-byte, may be specified as the default character
encoding in MSH-18-character set. If the default encoding is other than 7-bit ASCII, sites
shall document this usage in the dynamic conformance profile or other implementation
1995 agreement. This is particularly effective in promoting interoperability between nations
belonging to different HL7 Affiliates, while limiting the amount of testing required to
determine the encoding of a message.
See HL7 V2.6 for the semantics for alphabetic languages other than English (2.15.9.18.1)
and for non-alphabetic languages (2.15.9.18.2)
2000 The PCD TF requires this field to be valued if the character set is other than ASCII. If the
character set is ASCII the field may be null or have the value of ASCII. A single
character set is required for a given message.
MSH-19 Principal Language of Message
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^<Alternate
2005 Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding
System (ID)>

Definition: This field contains the principal language of the message. Codes come from
ISO 639.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 87 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

The PCD uses a default of en^English^ISO639 if the field is empty.

2010 MSH-21 Message Profile Identifier
Components: <Entity Identifier (ST)> ^ <Namespace ID (IS)> ^ <Universal ID (ST)>
^<Universal ID Type (ID)>

For PCD TF, this field is required in non-ACK messages to allow identification of a
specific message profile, particularly for testing purposes (it is superfluous and therefore
2015 not required in ACK messages). PCD message profiles are assigned ISO OIDs by the
PCD Technical Committee and the appropriate Message Profile Identifiers are to be used
here in conformant messages. When multiple message profiles are listed in this field they
should be (vendor specific, country specific) constraints of the PCD profile. Note that the
overriding of PCD profile constraints is only allowed in national extensions to this
2020 framework.
Assigned OIDs for PCD messages (note that for convenience of reference this table
includes OIDs for some messages that are not yet in Final Text status and are therefore
not described in this Final Text Technical Framework document):

Assigned OID PCD Message

1.3.6.1.4.1.19376.1.6.1.1.1 Device to Enterprise Communications PCD-01 Communicate PCD Data
message (also used for observations in response to a PCD-02 PCD Data Query)
1.3.6.1.4.1.19376.1.6.1.2.1 Device to Enterprise Communications PCD-02 PCD Data Query
1.3.6.1.4.1.19376.1.6.1.3.1 Point-of-care Infusion Verification PCD-03 Communicate Infusion Order
message
1.3.6.1.4.1.19376.1.6.1.3.2 Point-of-care Infusion Verification RRG^O16^RRG_O16 Pharmacy/Treatment
Give Acknowledgment Message
1.3.6.1.4.1.19376.1.6.1.9.1 Implantable Device - Cardiac Communicate IDC Observations
1.3.6.1.4.1.19376.1.6.1.4.1 Alert Communication Management PCD-04 Report Alert message
1.3.6.1.4.1.19376.1.6.1.5.1 Alert Communication Management PCD-05 Report Alert Status message
1.3.6.1.4.1.19376.1.6.1.6.1 Alert Communication Management PCD-06 Disseminate Alert
1.3.6.1.4.1.19376.1.6.1.7.1 Alert Communication Management PCD-07 Report Alert Dissemination Status

2025
The ISO OID in the table should be used as the universal ID (EI-3). The Universal ID
Type (EI-4) for ISO OIDs is “ISO”. In IHE PCD profiles, the Entity Identifier (EI-1) is
optional and may contain a human-readable name for the profile in the form
“IHE_PCD_XXX” where XXX identifies the IHE PCD transaction, for example,
2030 IHE_PCD_001 for [PCD-01]. Namespace Identifier (EI-2) is also optional, but may
contain “IHE PCD” to identify the source of the profile for a human reader. It is
emphasized that these suggested values are only for human readability and shall play no
role in processing. Processing which depends on the Message profile identifier in the
receiving application or in a test system shall base its recognition of the profile solely on
2035 the ISO OID (Universal ID, EI-3).
Example: IHE_PCD_001^IHE PCD^1.3.6.1.4.1.19376.1.6.4.4.1^ISO

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 88 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

B.2 MSA – Message Acknowledgement Segment

See HL7 v2.6: chapter 2 (2.14.8)
This segment contains information sent while acknowledging another message.

2040 Table B.2-1: MSA - Message Acknowledgement

SEQ LEN DT Usage Card. TBL# Element name
1 2 ID R [1..1] 0008 Acknowledgement code
2 20 ST R [1..1] Message Control Id
3 80 ST X [0..0] Text Message
5 1 ID X [0..0] Delayed Acknowledgment Type
6 705 CWE X [0..0] 0357 Error Condition

MSA-1 Acknowledgment Code

This field indicates the result of the processing of the message it is acknowledging.

Table B.2-2: HL7 table 0008 - Acknowledgement code

Value Description Comment
CA Enhanced mode: Accept acknowledgment: The message has been reviewed and accepted.
Commit Accept
CE Enhanced mode: Accept acknowledgment: The message has been rejected for an error.
Error
CR Enhanced mode: Accept acknowledgment: The message has been rejected by the receiving
Commit Reject system
AA Original mode Application The receiving system accepted and integrated
Acknowledgment:Accept. Enhanced mode: the message.
Application acknowledgement: Accept
AR Original mode Application The receiving system rejected the message
Acknowledgment:Reject. Enhanced mode:
Application acknowledgement: Reject
AE Original mode Application Acknowledgment: The receiving system rejected the message for
Error. Enhanced mode: Application an error.
acknowledgement: Error

2045
MSA-2 Message Control ID
Definition: This field contains the message control ID from the MSH-10 - Message
Control ID of the incoming message for which the acknowledgement is sent.
MSA-3 Text Message
2050 See the ERR segment.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 89 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

B.3 ERR – Error Segment

HL7 v2.6, Chapter 2 (2.14.5)
This segment is used to add error comments to acknowledgment messages.

Table B.3-1: ERR - Error segment

SEQ LEN DT Usage Card. TBL# Element name
1 493 ELD B [0..1] Error Code and Location
3 705 CWE R [1..1] 0357 HL7 Error Code
4 2 ID R [1..1] 0516 Severity
5 705 CWE RE [0..1] 0533 Application Error Code
6 80 ST C 0..1 Application Error Parameter

2055 Notes: ERR-1 is included in HL7 v2.6 for backward compatibility only. Within the context of IHE PCD, this field shall not be
used.
ERR-3 and ERR-4 are required by HL7 v2.6

Use of Error Segment in the PIV Profile. This list of error codes that can occur during the
2060 processing of a PCD-03 message is consolidated from participating pump vendors. The
application acknowledgment from the IOC should contain the Code and Text in ERR-5.1 and
ERR-5.2 respectively. ERR-5.9 can also be used to contain additional text related to the error.
Note that there should be no expectation that each pump vendor or pump model will support all
of the codes in this list.
2065
Code Text Example

9001 Unknown infuser or channel e.g., incorrect infuser or channel ID

9002 Infuser/channel is currently infusing

9003 Missing required program parameter(s) e.g., Give Amount Minimum (RXG-5) - volume
(ParameterName1, ParameterName2, ...) to be infused - is missing

9004 Invalid program parameter(s) e.g., volume units are not mL

(ParameterName1, ParameterName2, ...)

9005 Parameter (ParameterName) outside of e.g., ordered rate greater than pump maximum
allowable range (MinValue to MaxValue)

9006 Infuser is powered off

9007 Infuser is offline or unable to connect to infuser e.g., infuser not on network or weak wireless
signal

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 90 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Code Text Example

9008 Invalid units for parameter (ParameterName) e.g., Give Strength Volume Units (RXG-24)
contains a medication unit value instead of
volume units

9009 Dose/Rate Units do not match drug library e.g., ordered units = mL/hr; drug library units
=mcg/kg/min

9010 Unable to match medication to drug library e.g., Medication does not exist in drug library

9011 Patient weight mismatch e.g., patient weight known by pump differs from
weight sent in [PCD-03]

9012 Patient ID mismatch e.g., patient ID known by pump differs from ID

sent in [PCD-03]

9013 Unable to program medication as piggyback e.g., medication not configured for piggyback
administration in drug library

9014 Dose rate or VTBI exceeds maximum e.g., greater than pump maximum

9015 Request timed out

9016 Other error Used when other errors are not applicable

9017 Infuser cannot accept program Infuser is in a state where it cannot accept
program; e.g., alarming or in standby

9018 Parameter (ParameterName) does not match e.g., Give Strength Units (RXG-18) = mg, drug
drug library library = mEq

9019 Patient weight missing Drug is weight-based or BSA-based, but patient

weight OBX is missing

9020 Patient height missing Drug is BSA-based, but patient height OBX is
missing

9021 Care area or profile mismatch Care area or profile not cleared on pump; or
pump is set to a different care area

9022 Requested infusion program is stale The value of ORC.9 is older than what the IOC
will allow to program the pump

9023 Program rejected by user Program rejected by user prior to starting

infusion

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 91 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Code Text Example

9024 Drug library hard limit exceeded e.g., dose exceeds maximum allowable for
medication

9025 Lockout interval missing Lockout Interval is required when Patient Dose is
present

9026 Dose limit missing PCA dose limit is required but missing

9027 Patient BSA missing Drug is BSA-based but BSA OBX is missing

9028 Tubing, cassette, or syringe not installed on Used when required by pump
pump

9029 Care area or profile not selected Used when required by pump

9030 Current medication cannot be interrupted Medication on primary cannot be interrupted by

a piggyback

9031 Patient ID missing or invalid

9032 Pump is in delayed start

9033 Pump is alarming

9034 Not enough fluid or medication in container to Applies to bolus from existing infusion only
deliver bolus

9035 Parent order ID does not match the currently Applies to bolus from existing infusion only
programmed order

9036 Medication does not match the currently Applies to bolus from existing infusion only
programmed order

9037 Medication concentration does not match the Applies to bolus from existing infusion only
currently programmed order

9038 Bolus order type is not supported ORC-1 = “CH” not supported by pump

9039 Medication does not support bolus Medication in drug library not configured for
bolus

9040 Bolus dose units do not match the currently e.g., “mg” instead of “mL”
programmed order

9041 Unable to parse multistep program Applies to multistep infusion only

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 92 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Code Text Example

9042 Medication is not configured for loading dose Applies to multistep infusion only

9043 Medication does not support multistep Applies to multistep infusion only

9044 Multistep order type is not supported Applies to multistep infusion only

ERR-5 Application Error Code

Application specific codes for infusion-related errors resulting from a [PCD-03]
transaction, identifying the specific error that occurred, are given in the IHE PCD
2070 Application Error Table. New codes may be added from time to time through the IHE
Change Proposal Process. The IHE PCD website should be consulted for the latest
approved table (http://wiki.ihe.net/index.php?title=PumpErrorCodes).
ERR-6 Application Error Parameter
Additional information to be used with application specific codes calling for the input of
2075 Parameter names or values as called for in the IHE PCD Application Error Table.

B.4 NTE - Notes and Comment Segment

HL7 v2.6 : chapter 2 (2.4.10)
This segment is used for sending notes and comments.
The IHE PCD Technical Framework limits the use of this segment to only one purpose: to
2080 comment the observations and the orders. Therefore, in the messages of this Integration Profile,
NTE segments appear only following either OBR or OBX segments.
Information that can be coded in OBX segments or OBR segments shall not be sent in a NTE
segment.
Detail of the fields used by the NTE segment in the PCD Observation Message is given below.

2085 Table B.4-1: NTE - Notes and Comment segment

SEQ LEN DT Usage Card. TBL# Element name
1 4 SI R [1..1] Set ID – NTE
2 8 ID X [0..0] Source of Comment
3 65536 FT RE [0..1] Comment
4 705 CWE X [0..0] Comment Type
5 3220 XCN X [0..0] Entered by
6 24 DTM X [0..0] Entered Date/Time
7 24 DTM X [0..0] Expiration Date

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 93 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

NTE-1 Set ID
This field may be used where multiple NTE segments are used in a message. Their
numbering must be described in the application message definition.
2090 NTE-3 Comment
This field contains the text of the comment. This text may be formatted. In order to delete
an existing comment, the field shall contain empty quotation marks: "“.
Comment text of identical type and source shall be included in the same occurrence of an
NTE segment, and not be split over multiple segments.
2095 NTE Notes and Comment Segment in PCD-04 Message
By site-specific agreement between implementers of the Alert Reporter and Alert
Manager Actors, additional information not provided for in other segments may be
included in the NTE Notes and Comment segments. Site or system specific indications
are optionally passed in this manner to the Alert Manager for us by its message
2100 dispatching logic, or to pass additional information through the Alert Manager to the
Alert Communicator to communications endpoints.
Optional ad-hoc annotation text to be included in the alert notification text message sent
from the ACM Alert Manager to the ACM Alert Communicator is to be included in an
occurrence of an NTE segment in association with the OBX segment which identifies the
2105 alert indication. This text doesn’t replace any alert notification text synthesized by the
ACM AM from alert data provided to the ACM Alert Manager by the Report Alert PCD-
04 message.

Table B.4-2: HL7 Attribute Table – NTE – Notes and Comment

SEQ LEN DT OPT RP/# TBL# ELEMENT NAME
3 65536 FT O Y Comment

2110 NTE-3 Comment (FT)

This field contains the comment conveyed by the segment.

B.5 PID - Patient Identification segment

HL7 v2.6: chapter 3 (3.4.2)
The PID segment is used by all applications as the primary means of communicating patient
2115 identification information. This segment contains permanent patient identifying and demographic
information that, for the most part, is not likely to change frequently.
Patient Care Devices or gateway systems providing PCD observation reports are not ordinarily
primary interfaces for detailed patient demographic information. Another information system
such as a master patient index will generally be the source of authoritative information sent in the
2120 PID segment. Getting this data is out of scope for this IHE PCD Technical Framework: IHE

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 94 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Information Technology Infrastructure Technical Framework should be consulted for standards-

based means for tracing a feed of ADT events (Patient Identify Feed) or querying this
information based on information available at the point of care such as a bar-code scan of a
patient identity wristband (Patient Data Query). In the context of the IHE Patient Care domain,
2125 this general problem is referred to as Patient Identity Binding and has been the subject of a
Technical Framework Supplement in the past. At present, this data requirement is delegated to
IHE Information Technology Infrastructure profiles.
Reliable patient identity information is essential for correctly associating Patient Care Device
data with the patient, which is obviously critical for safe and effective treatment. Consequently,
2130 unique identifiers and additional confirmatory factors such as patient name are listed as required
by this profile.

Table B.5-1: PID - Patient Identification segment

SEQ LEN DT Usage Card. TBL# Element name
1 4 SI X [0..0] Set ID - PID
2 20 CX X [0..0] Patient ID
3 250 CX C [0..6] Patient Identifier List
4 20 CX X [0..0] Alternate Patient ID - PID
5 250 XPN C [0..6] Patient Name
6 250 XPN RE [0..1] Mother’s Maiden Name
7 24 DTM RE [0..1] Date/Time of Birth
8 1 IS RE [0..1] 0001 Administrative Sex
9 250 XPN X [0..0] Patient Alias
10 705 CWE RE [0..1] 0005 Race
11 250 XAD RE [0..1] Patient Address
12 4 IS RE [0..1] 0289 County Code
13 250 XTN RE [0..2] Phone Number - Home
14 250 XTN X [0..1] Phone Number - Business
15 705 CWE RE [0..1] 0296 Primary Language
16 705 CWE RE [0..1] 0002 Marital Status
17 705 CWE RE [0..1] 0006 Religion
18 705 CX RE [0..1] Patient Account Number
19 16 ST X [0..0] SSN Number - Patient
20 25 DLN RE [0..1] Driver's License Number - Patient
21 705 CX RE [0..1] Mother's Identifier
22 705 CWE RE [0..1] 0189 Ethnic Group
23 705 ST RE [0..1] Birth Place
24 1 ID RE [0..1] 0136 Multiple Birth Indicator
25 2 NM RE [0..1] Birth Order
26 705 CWE RE [0..1] 0171 Citizenship
27 705 CWE RE [0..1] 0172 Veterans Military Status

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 95 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

SEQ LEN DT Usage Card. TBL# Element name

28 705 CWE RE [0..1] 0212 Nationality
29 24 DTM RE [0..1] Patient Death Date and Time
30 1 ID RE [0..1] 0136 Patient Death Indicator
31 1 ID RE [0..1] 0136 Identity Unknown Indicator
32 20 IS RE [0..1] 0445 Identity Reliability Code
33 24 DTM RE [0..1] Last Update Date/Time
34 241 HD RE [0..1] Last Update Facility
35 705 CWE RE [0..1] 0446 Species Code
36 250 CWE C [0..1] 0447 Breed Code
37 80 ST C [0..1] Strain
38 705 CWE RE [0..2] 0429 Production Class Code
39 705 CWE RE [0..1] 0171 Tribal Citizenship

The following describes the IHE PCD usage of those fields which have a usage other than X in
2135 the above table and have IHE PCD usage notes added to the general definitions in the HL7 2.6
standard.
PID-3 Patient Identifier List
Definition: This field contains the list of identifiers (one or more) used by the healthcare
facility to uniquely identify a patient (e.g., medical record number, billing number, birth
2140 registry, national unique individual identifier, etc.). In Canada, the Canadian Provincial
Healthcare Number is used in this field.
Component PID-3.1 (in terms of the CX data type, CX-1) "ID number", is required
except where noted under particular transactions. PID-3.4 (CX-4) "Assigning authority",
and PID-3.5 (CX-5) "Identifier Type Code" are required for each identifier if they are
2145 known (for example if they are ordinarily included in ADT messages at the institution),
but may be empty if they are not known. See Appendix CX Data Type. Note that PID-3.4
is an Entity Identifier data type, so it may have subcomponents.
The workflow and mechanism by which patient identification is bound to the data from a
particular PCD device is outside of the scope of the IHE PCD Framework. Common
2150 implementations employ either automated or manual entry based on information provided
by an authoritative source of patient identity.
The IHE PCD recognizes that it is critical for data to be associated with the correct
patient, thus the general rule that at least PID-3 and PID-5 be available for at least two-
factor patient identification, but that there are also situations like emergency admissions
2155 where it may be desirable to collect data before an authoritative patient identification is
available, for later association with the patient’s other data. Only after appropriate study,
risk analysis, and defined risk mitigation measures determined by the provider institution
in consultation with the manufacturers of the systems involved, a defined method for
deferred association of patient data could be designed. In such a case, these fields, instead

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 96 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

2160 of being populated with authoritative patient identity information, could be populated
with agreed-on special values (like an automatically generated “stat admit” patient
identifier and a well-known special value in PID-5 indicating the temporary situation)
pending the later human-validated merging of the data.
The IHE PCD recognizes that for some use cases, such as medication administration,
2165 additional identification information or other patient demographic information is required
in addition to an organizationally assigned unique identifier. Patient name, date of birth,
gender, and other information are commonly used to provide the additional patient
identification context for these use cases. Additional patient demographic information is
provided by the fields of the PID segment and the patient location, which is often a key
2170 element in PCD communications, is provided in the PV1-3 element.
PID-5 Patient Name
Definition: This field contains the names of the patient; the primary or legal name of the
patient is reported first. Therefore, the name type code in this field should be "L - Legal"
if such a name is available. If no name is available, the name type code should be "U –
2175 unspecified", and the other components should be empty. All other codes in HL7 Table
0200 – Name Type are also acceptable. Note that "last name prefix" is synonymous to
"own family name prefix" of previous versions of HL7, as is "second and further given
names or initials thereof" to "middle initial or name". Multiple given names and/or
initials are separated by spaces.
2180 The workflow and mechanism by which patient name is bound to the data from a
particular PCD device is outside of the scope of this version of the IHE PCD Framework.
Common implementations employ either automated or manual entry based on
information provided by an authoritative source of patient identity. The workflow and
transactions to bind patient name are included on the IHE PCD Roadmap for
2185 consideration in future versions of the IHE PCD Framework.
See Appendix C.8 XPN Type for further information.
PID-6 Mother’s Maiden Name
Definition: This field contains the family name under which the mother was born (i.e.,
before marriage). It is used to distinguish between patients with the same last name.
2190 See Appendix C.8 XPN Type for further information.
PID-7 Date/Time of Birth
See Appendix C.4, DTM – date/time for further information on how the specification of
times in IHE PCD differs from the HL7 v. 2.6 representation
PID-8 Administrative Sex
2195 Definition: This field contains the patient’s sex. Refer to HL7 User-defined Table 0001 -
Administrative Sex for suggested values.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 97 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Table B.5-2: HL7 User-defined Table 0001 - Administrative Sex

Value Description Comment
F Female
M Male
O Other
A Ambiguous
N Not applicable

PID-10 Race (CWE)

2200 Definition: This field refers to the patient’s race. Refer to User-defined Table 0005 - Race
for suggested values. The second triplet of the CWE data type for race (alternate
identifier, alternate text, and name of alternate coding system) is reserved for
governmentally assigned codes.

Table B.5-3: HL7 User-defined Table 0005 - Race

Value Description Comment
1002-5 American Indian of Alaska Native
2028-9 Asian
2054-5 Black or African American
2076-8 Native Hawaiian of Other Pacific Islander
2106-3 White
2131-1 Other Race

2205
PID-11 Patient Address
Components: <Street Address (SAD)> ^ <Other Designation (ST)> ^ <City (ST)> ^ <State
or Province (ST)> ^ <Zip or Postal Code (ST)> ^ <Country (ID)> ^ <Address
Type (ID)> ^ <Other Geographic Designation (ST)> ^ <County/Parish Code
2210 (IS)> ^ <Census Tract (IS)> ^ <Address Representation Code (ID)> ^
<Address Validity Range (DR)> ^ <Effective Date (DTM)> ^ <Expiration Date
(DTM)>
Subcomponents for Street Address (SAD): <Street or Mailing Address (ST)> & <Street
Name (ST)> & <Dwelling Number (ST)>
2215 Subcomponents for Address Validity Range (DR): <Range Start Date/Time (DTM)> & <Range
End Date/Time (DTM)>
Subcomponents for Range Start Date/Time (DTM): <Time (DTM)> & <Degree of Precision
(ID)>
Subcomponents for Range End Date/Time (DTM): <Time (DTM)> & <Degree of Precision (ID)>
2220 Subcomponents for Effective Date (DTM): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Expiration Date (DTM): <Time (DTM)> & <Degree of Precision (ID)>

Definition: This field contains the mailing address of the patient. Address type codes are
defined by HL7 Table 0190 - Address Type. The PCD only requires the first, third,

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 98 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

fourth, and fifth components to be valued with the mailing address and the Address Type
2225 to be valued as M.
PID-13 Phone Number – Home
Definition: This field contains the patient’s personal phone numbers. This data type is
usually in a repeatable field, to allow a list of numbers. The PCD requires the sequence to
be the primary number (for backward compatibility). The PCD constrains this field to 2
2230 repetitions to allow for a phone number and an email address.
See Appendix C.9 XTN Data Type for further information.
PID-15 Primary Language
See HL7 V2.6 Section 3.4.2.15 for details. The PCD TF requires the use of ISO639 for
the codes.
2235 PID-16 Marital Status
See HL7 V2.6 Section 3.4.2.16 for details. The PCD TF does not further constrain this
field.
PID-17 Religion
See HL7 V2.6 Section 3.4.2.17 for details. The PCD TF does not further constrain this
2240 field.
PID-18 Patient Account Number
See HL7 V2.6 Section 3.4.2.18 for details. The PCD TF does not further constrain this
field. Additional requirements may be documented in Regional or National appendices to
the IHE PCD Technical Framework.
2245 PID-20 Driver’s License Number – Patient
See HL7 V2.6 Section 3.4.2.20 for details. The PCD TF does not further constrain this
field.
PID-21 Mother’s Identifier
See HL7 V2.6 Section 3.4.2.21 for details. The PCD TF does not further constrain this
2250 field.
PID-22 Ethnic Group:
See HL7 V2.6 Section 3.4.2.22 for details. The PCD TF does not further constrain this
field.
PID-23 Birth Place
2255 See HL7 V2.6 Section 3.4.2.23 for details. The PCD TF does not further constrain this
field.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 99 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

PID-24 Multiple Birth Indicator

See HL7 V2.6 Section 3.4.2.24 for details. The PCD TF does not further constrain this
field.
2260 PID-25 Birth Order
See HL7 V2.6 Section 3.4.2.25 for details. The PCD TF does not further constrain this
field.
PID-26 Citizenship
See HL7 V2.6 Section 3.4.2.26 for details. The PCD TF does not further constrain this
2265 field.
PID-27 Veterans Military Status
See HL7 V2.6 Section 3.4.2.27 for details. The PCD TF does not further constrain this
field.
PID-28 Nationality
2270 See HL7 V2.6 Section 3.4.2.28 for details. The PCD TF does not further constrain this
field.
PID-29 Patient Death Date and Time
Definition: This field contains the date and time at which the patient death occurred.
See Appendix C.4 DTM – date/time for PCD constraints.
2275 PID-30 Patient Death Indicator
See HL7 V2.6 Section 3.4.2.30 for details. The PCD TF does not further constrain this
field.
PID-31 Identity Unknown Indicator
Definition: This field indicates whether or not the patient's/person's identity is known.
2280 Refer to HL7 Table 0136 - Yes/No Indicator for valid values.
o Y the patient's/person's identity is unknown
o N the patient's/person's identity is known
See HL7 V2.6 Section 3.4.2.31 for details. The PCD TF does not further constrain this
field.
2285 PID-32 Identity Reliability Code
See HL7 V2.6 Section 3.4.2.32 for details. The PCD TF does not further constrain this
field.
PID-33 Last Update Date/Time
Definition: This field contains the last update date and time for the patient’s/person’s
2290 identifying and demographic data, as defined in the PID segment. Receiving systems will

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 100 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

use this field to determine how to apply the transaction to their systems. If the receiving
system (such as an enterprise master patient index) already has a record for the person
with a later last update date/time, then the EMPI receiving system could decide not to
apply the patient’s/person’s demographic and identifying data from this transaction.
2295 See Appendix C.4 DTM – date/time for PCD constraints.
PID-34 Last Update Facility
See HL7 V2.6 Section 3.4.2.34 for details. The PCD TF does not further constrain this
field.
PID-35 Species Code
2300 See HL7 V2.6 Section 3.4.2.35 for details. The PCD TF does not further constrain this
field.
PID-36 Breed Code
See HL7 V2.6 Section 3.4.2.36 for details. The PCD TF does not further constrain this
field.
2305 PID-37 Strain
See HL7 V2.6 Section 3.4.2.37 for details. The PCD TF does not further constrain this
field.
PID-38 Production Class Code
See HL7 V2.6 Section 3.4.2.38 for details. The PCD TF does not further constrain this
2310 field.
PID-39 Tribal Citizenship (CWE)
See HL7 V2.6 Section 3.4.2.39 for details. The PCD TF does not further constrain this
field.

B.5.1 PID Segment requirements for ACM Transaction PCD-04

2315 This segment is required to be present and is populated with data used to identify the patient
associated with the alert in the case where the identity is available from the Alert Source system.
If the patient identification is not available from the Alert Source system, the alert may be
location source based per ACM use case A1 in which case the PV1 segment identifies the
location associated with the alert. Additional information may be present to more unambiguously
2320 identify the patient.

Table B.5.1-1: HL7 Attribute Table – PID – Patient Identification

SEQ LEN DT OPT RP/# TBL# ELEMENT NAME
3 250 CX O Y Patient Identifier List
5 250 XPN O Y Patient name
7 26 TSO O Date/Time of Birth
8 1 IS O Administrative Sex

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 101 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

PID-3 Patient Identifier List (CX)

This information may be used by the Alert Manager in the message sent to the Alert
Communicator to identify the patient associated with the alert within site specific HIPAA
2325 and electronic patient healthcare information policies.
PID-5 Patient Name (XPN)
This information may be used by the Alert Manager in the message sent to the Alert
Communicator to identify the patient associated with the alert within site specific HIPAA
and electronic patient healthcare information policies. Refer to PID-31 Identity Unknown
2330 Indicator for the means to identify that while a PID segment is provided the identity of
the patient is unknown.
PID-7 Date/Time of Birth (TSO)
This information may be used by the Alert Manager in the message sent to the Alert
Communicator to identify the patient associated with the alert within site specific HIPAA
2335 and electronic patient healthcare information policies.
PID-8 Administrative Sex (IS)
This information may be used by the Alert Manager in the message sent to the Alert
Communicator to identify the patient associated with the alert within site specific HIPAA
and electronic patient healthcare information policies.
2340 PID-31 Identity Unknown Indicator (ID)
Definition: This field indicates whether or not the patient's/person's identity is known.
Refer to HL7 Table 0136 - Yes/No Indicator for valid values.
o Y the patient's/person's identity is unknown
o N the patient's/person's identity is known

2345 B.6 PV1 - Patient Visit Segment

See HL7 V2.6 Section 3.4.3 for details.
The PV1 segment is used by Registration/Patient Administration applications to communicate
information on an account or visit-specific basis. The default is to send account level data. To
use this segment for visit level data PV1-51 - Visit Indicator must be valued to ‘V’. The value of
2350 PV-51 affects the level of data being sent on the PV1, PV2, and any other segments that are part
of the associated PV1 hierarchy (e.g., ROL, DG1, or OBX).
The facility ID, the optional fourth component of each patient location field, is a HD data type
that is uniquely associated with the healthcare facility containing the location. A given
institution, or group of intercommunicating institutions, should establish a list of facilities that
2355 may be potential assignors of patient locations. The list will be one of the institution’s master
dictionary lists. Since third parties other than the assignors of patient locations may send or
receive HL7 messages containing patient locations, the facility ID in the patient location may not
be the same as that implied by the sending and receiving systems identified in the MSH. The

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 102 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

facility ID must be unique across facilities at a given site. This field is required for HL7
2360 implementations that have more than a single healthcare facility with bed locations, since the
same <point of care> ^ <room> ^ <bed> combination may exist at more than one facility.
Details of the PV1 segment as used in the IHE PCD Technical Framework are given in Table
B.6-1: HL7 Attribute Table - PV1 - Patient Visit.

Table B.6-1: HL7 Attribute Table - PV1 - Patient Visit

SEQ LEN DT Usage Card. TBL# Element name
1 4 SI X [0..0] Set ID - PV1
2 1 IS R [1..1] 0004 Patient Class
3 80 PL RE [0..1] Assigned Patient Location
4 2 IS X [0..0] 0007 Admission Type
5 250 CX X [0..0] Preadmit Number
6 80 PL X [0..0] Prior Patient Location
7 250 XCN X [0..0] 0010 Attending Doctor
8 250 XCN X [0..0] 0010 Referring Doctor
9 250 XCN X [0..0] 0010 Consulting Doctor
10 3 IS X [0..0] 0069 Hospital Service
11 80 PL X [0..0] Temporary Location
12 2 IS X [0..0] 0087 Preadmit Test Indicator
13 2 IS X [0..0] 0092 Re-admission Indicator
14 6 IS X [0..0] 0007 Admit Source
15 2 IS X [0..0] 0009 Ambulatory Status
16 2 IS X [0..0] 0099 VIP Indicator
17 250 XCN X [0..0] 0010 Admitting Doctor
18 2 IS X [0..0] 0018 Patient Type
19 250 CX RE [0..1] Visit Number
20 50 FC X [0..0] 0064 Financial Class
21 2 IS X [0..0] 0032 Charge Price Indicator
22 2 IS X [0..0] 0045 Courtesy Code
23 2 IS X [0..0] 0046 Credit Rating
24 2 IS X [0..0] 0044 Contract Code
25 8 DT X [0..0] Contract Effective Date
26 12 NM X [0..0] Contract Amount
27 3 NM X [0..0] Contract Period
28 2 IS X [0..0] 0073 Interest Code
29 4 IS X [0..0] 0110 Transfer to Bad Debt Code
30 8 DT X [0..0] Transfer to Bad Debt Date
31 10 IS X [0..0] 0021 Bad Debt Agency Code
32 12 NM X [0..0] Bad Debt Transfer Amount
33 12 NM X [0..0] Bad Debt Recovery Amount

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 103 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

SEQ LEN DT Usage Card. TBL# Element name

34 1 IS X [0..0] 0111 Delete Account Indicator
35 8 DT X [0..0] Delete Account Date
36 3 IS X [0..0] Discharge Disposition
37 47 DLD X [0..0] 0113 Discharged to Location
38 705 CWE X [0..0] 0114 Diet Type
39 2 IS X [0..0] 0115 Servicing Facility
40 1 IS X [0..0] 0116 Bed Status
41 2 IS X [0..0] 0117 Account Status
42 80 PL X [0..0] Pending Location
43 80 PL X [0..0] Prior Temporary Location
44 24 DTM RE [0..1] Admit Date/Time
45 24 DTM X [0..0] Discharge Date/Time
46 12 NM X [0..0] Current Patient Balance
47 12 NM X [0..0] Total Charges
48 12 NM X [0..0] Total Adjustments
49 12 NM X [0..0] Total Payments
50 250 CX X [0..0] 0203 Alternate Visit ID
51 1 IS RE [0..1] 0326 Visit Indicator

2365
PV1-2 Patient Class
Definition: This field is used by systems to categorize patients by site. It does not have a
consistent industry-wide definition. It is subject to site-specific variations. Refer to Table
B.6-2 HL7 User-defined Table 0004 - Patient Class for IHE PCD suggested values.

2370 Table B.6-2: HL7 User-defined Table 0004 - Patient Class

Value Description Comment
E Emergency
I Inpatient
O Outpatient
P Preadmit
R Recurring patient
B Obstetrics
U Unknown

PV1-3 Assigned Location

IHE PCD definition: This field contains the patient’s initial assigned location or the
location to which the patient is being moved, if known. The first component may be the

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 104 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

2375 nursing station for inpatient locations, or clinic or department, for locations other than
inpatient.
For IHE PCD usage, see Appendix C.7 PL Data Type.
PV1-19 Visit Number
IHE PCD definition: This field contains the unique number assigned to each patient visit.
2380 PV1-44 Admit Time / Date
HL7 Definition: This field contains the admit date/time. It is to be used if the event
date/time is different than the admit date and time, i.e., a retroactive update. This field is
also used to reflect the date/time of an outpatient/emergency patient registration. IHE
PCD does not further constrain this field.
2385 PV1-51 Visit Indicator
HL7 definition: This field specifies the level on which data are being sent. It is the
indicator used to send data at two levels, visit and account. IHE PCD implementations
shall send an ‘A’ or no value when the data in the message are at the account level, or ‘V’
to indicate that the data sent in the message are at the visit level.
2390 The value of this element affects the context of data sent in PV1, PV2 and any associated
hierarchical segments (e.g., DB1, AL1, DG1, etc.).

B.6.1 PV1 Patient Visit Segment in ACM Transaction PCD-04

This segment is used to identify a patient location associated with the alert. Real Time Location
Services (RTLS) or GPS equipment or personnel location information is not passed in this
2395 segment. It is passed from the Alert Reporter to the Alert Manager via an OBX segment.
If the Patient Identification (PID) segment is present in the alert data and it contains an identified
patient as in ACM use case A2, use a more reliable source of current information, rather than this
segment, where possible.

Table B.6.1-1: HL7 Attribute Table – PV1 – Patient Visit

SEQ LEN DT OPT RP/# TBL# ELEMENT NAME
3 80 PL O Assigned Patient Location

2400
PV1-3 Assigned Patient Location (PL)
This field contains the location associated with the alert. It is typically a location
established by an external system such as ADT, as in the patient assigned bed location as
used in association with a patient station of a nurse call system. This may not be the
2405 current location of the relevant patient.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 105 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

B.7 OBR – Observation Request segment

In the reporting of clinical data, the Observation Request Segment (OBR) serves as the 'report
header' for the ORDER_OBSERVATION segment group, which in its simplest form is an OBR
segment followed by a set of OBX segments which represent observations associated with the
2410 'order' represented by the OBR segment. It identifies the observation set represented by the
following atomic observations. It includes the relevant ordering information when that applies
and many of the attributes that apply to all of the following observations.
A Report Alert [PCD-04] transaction contains at most one alert indication.
The OBR segment is used to uniquely identify the alert indication and the descendent alert status
2415 update indications.

Table B.7-1: OBR segment

SEQ LEN DT Usage Card. TBL# Element name
1 4 SI R [1..1] Set ID OBR
2 427 EI C [0..1] Placer Order Number
3 427 EI R [1..1] Filler Order Number
4 705 CWE R [1..1] Universal Service Identifier
5 2 ID X [0..0] Priority - OBR
6 24 DTM X [0..0] Requested Date/Time
7 24 DTM RE [0..1] Observation Date/Time
8 24 DTM RE [0..1] Observation End Date / Time
9 722 CQ X [0..0] Collection Volume
10 3220 XCN R2 [0..1] Collection Identifier

OBR-1 Set ID OBR

Definition: For the first order transmitted in each message, the sequence number shall be
2420 1; for the second order, it shall be 2; and so on.
OBR-2 Placer Order Number
Definition: This field has the Entity Identifier data type. The first component (EI-1,
Entity Identifier) is a string that identifies an individual order (e.g., OBR). It is assigned
by the placer (ordering application). It identifies an order uniquely among all orders from
2425 a particular ordering application. The second through fourth components contain the
application ID of the placing application in the same form as the HD data type. The
second component, Namespace ID, is a user-defined coded value that will be uniquely
associated with an application. A given institution or group of intercommunicating
institutions should establish a unique list of applications that may be potential placers and
2430 fillers and assign unique application IDs. The components are separated by component
delimiters.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 106 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

This field is conditionally required as described in HL7, where the placer id may be sent
in either the ORC or the OBR segment. If the observation is in response to an order, then
the ordering application’s placer number and naming system should be returned here. If
2435 there is no placer number, for example in a "standing" order that is documented as a
hospital specific protocol, then the Device Observation Reporter may assign one and send
it here as specified in HL7.
The PCD TF requires at a minimum that Entity Identifier (EI-1) and Namespace ID (EI-
2) be valued and recommends that the Namespace Id (EI-2) shall refer to the locally
2440 unique application identifier assigned to the Device Observation Reporter application
implementing IHE PCD actors which fill the role of an ordering application such as the
DOR. In order to avoid conflicting Ids in any context, it is desirable, though not required,
that the assigning application be identified according to a Universal ID system by giving
a value for Universal ID (EI-3) and Universal ID type (EI-4). If EI-3 and EI-4 are valued,
2445 then EI-2 (Namespace ID) is not required.
See Appendix C.5 EI Data Type for further information.
See HL7 V2.6 Section 7.4.1.2 for details. The PCD TF does not further constrain this
field.
OBR-3 Filler Order Number
2450 Definition: This field is the order number associated with the filling application. This is a
permanent identifier for an order and its associated observations. It is a special case of the
Entity Identifier data type. The first component (EI-1, Entity Identifier) is a string that
identifies an order detail segment (e.g., OBR). It is assigned by the order filler (receiving)
application. This string must uniquely identify the order (as specified in the order detail
2455 segment) from other orders in a particular filling application (e.g., patient monitoring
gateway). This uniqueness must persist over time. The second through fourth components
contain the filler application ID, in the form of the HD data type. The second component
(Namespace ID, EI-2) is a user-defined coded value that uniquely defines the application
from other applications on the network. The Namespace ID of the filler order number
2460 always identifies the actual filler of an order.
The PCD TF requires that the Universal ID (EI-3) be valued with a Unique ID for the
application identifier assigned to the application implementing IHE actors supporting the
role of an order filler such as the DOR (Device Observation Reporter). The Universal ID
Type (EI-4) shall be valued with the appropriate type notation corresponding to the
2465 Unique ID. The preferred Universal ID type for IHE PCD is the EUI-64 code. The
Universal ID type (EI-4) is then "EUI-64". In cases where an EUI-64 is not available, less
preferred Universal IDs for the application may be used as detailed in Appendix C.5 EI
Data Type. For compatibility with older receiving systems, the PCD TF recommends that
the Entity Identifier (EI-1) be valued with a duplicate of the Universal ID as in EI-3. The
2470 Namespace ID (EI-2) is not required but for backward compatibility may be valued with
a "legacy" locally unique identifier for the filler application.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 107 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

In the transactions of the Alert Communication Management Profile ([PCD-04], [PCD-

06], [PCD-07]), this field serves as the unique identifier for status updates to an alert
indication identified in OBR-29 Parent. This value is assigned by the Alert Source and is
2475 used by system actors to associate updates to a particular alert identified in OBR-29
Parent. For the initial indication message of an alert OBR-29 Parent is required to be
empty in order to indicate that it is the initial indication for that alert. For all subsequent
indications related to the same alert OBR-3 Filler Order Number identifies the unique
indication and OBR-29 Parent contains the value from OBR-3 Filler Order Number of
2480 the initial alert indication. This permits the Alert Manager (AM) and Alert Consumer
(ACON) Actors to associate all subsequent indications, such alert phase updates, with the
original alert.
OBR-4 Universal Service ID
Definition: This field shall contain the identifier code for the requested
2485 observation/test/battery. This can refer to specific existing orders, or nonspecific
“standing” orders. “Universal” procedure codes from a code set recognized by HL7
should be used when available. Locally defined codes may be used by agreement where
standardized codes are not available. Check descriptions of particular PCD transactions
for other requirements or recommendations.
2490 When reporting events related to "standing" orders, as is common in patient monitoring,
these codes may describe a generic service, for example:
Examples of SNOMED CT (HL7 Universal ID Type SCT) terms appropriate for use in
this field:

2495 266706003^Continuous ECG monitoring^SCT

359772000^glucose monitoring at home^SCT
182777000^monitoring of patient ^SCT

In some contexts, the service identifier used in this field may usefully contain information
on which the receiving system can base decisions about further processing for the
2500 message, including not processing the message if the content is not wanted (e.g.,
waveform information that the receiving system is not able to use).
Local codes are permissible if no appropriate SNOMED CT term can be used, but users
of this Technical Framework who encounter a situation where a new type of service
related to patient care devices is identified should submit a description of the service to
2505 the PCD Technical Committee so that provisional codes can be defined, and permanent
codes requested from an appropriate standards development organization.
An accepted "legacy" usage is for OBR-4 to contain an EUI-64 identification for the
sending system. This was required in previous versions of this Technical Framework.
This is acceptable as a local code for a "service" that consists of sending the PCD data
2510 that the particular system is configured to send and which is understood by the receiving
system, by local agreement.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 108 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

In communications related to infusion orders, the “service” identified in OBR-4 is the

substance to be administered: when a device generates a PCD-01 message as a result of a
PCD-03 request/order, then the requested Give Code from that order should be reflected
2515 back in the OBR-4 field. The sender may use an equivalent code for the same requested
item. The sender may not use a code that equates to a different item than what was
requested. When the [PCD-01] is not related to a [PCD-03] order, this code should reflect
the service being rendered for the patient (i.e., the medication), when known. If a
medication has been selected on the pump, the value of the code will relate to the
2520 medication as it is defined in the pump’s drug library. As long as the pump drug library is
in synch with the receiving system, the value will match the receiving system’s code for
the substance being administered. If no medication has been selected on the pump, this
field can be populated with a local “unknown medication” identifier and description.
Alternatively, “999999” can be used as the identifier and “Medication Unknown” can be
2525 used as the description.
In the transactions of the Alert Communication Management Profile, this field contains
the identifier code for the packaged message content type, such as ALARM,
WAVEFORM, EVENT, PROCEDURE, TREND, etc.
See Appendix A ISO/IEEE 11073 Mapping to HL7 for further details.
2530 See HL7 V2.6 Section 7.4.1.4 for details related to OBR-4
OBR-7 Observation Date/Time
Specifies the time point or start of time interval for all OBX segments within the scope of
this OBR segment, that is, OBX segments that are part of the ORDER_OBSERVATION
segment group, that do not specify an overriding time point in OBX-14. (The presence of
2535 an overriding time point in OBX-14 signals an episodic measurement such as
noninvasive blood pressure. The absence of an overriding time point in OBX-14 implies
that this is an instance of a periodically sampled observation with a time stamp given by
OBR-7. This distinction can also be made explicitly in OBX-17 Observation Method (see
entry for that field, below). See also Appendix B.8.7 for a discussion of general
2540 considerations concerning time stamps in IHE PCD messages, and Appendix C.4 for
details on the time zone offset in the DTM data type in IHE PCD Technical Framework.
OBR-8 Observation End Date/Time
If OBR-8 is not specified, OBR-7 specifies the default time point for all OBX segments
within its scope that do not specify an overriding time point in OBX-14. See also
2545 Appendix B.8.7 for a discussion of general considerations concerning time stamps in IHE
PCD messages.
If OBR-7 and OBR-8 are both specified, OBR-7 specifies the mathematically ‘closed’
interval boundary at the start of the time interval and OBR-8 specifies the mathematically
‘open’ end of the time interval. The interval [OBR-7, OBR-8) serves as the default time
2550 interval for all OBX segments within its scope that do not specify an overriding time
point in OBX-14.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 109 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

A single-valued OBX-5 is assumed to occur at time OBR-7 by default, and a multi-

valued OBX-5 containing N values is assumed to be divided into N equal time sub-
intervals, with the Nth value occurring at the beginning of each time sub-interval.
2555 The default time interval [OBR-7, OBR-8) is equivalent the HL7 V3 representation
where inclusive="true" specifies a ‘closed’ boundary and inclusive="false" specifies an
‘open’ boundary for the ten second interval shown below.

<effectiveTime>
2560 <low value="20100101091820.000+0000" inclusive="true" />
<high value="20100101091830.000+0000" inclusive="false" />
</effectiveTime>

OBR-10 Collector Identifier

2565 When a specimen is required for the study, this field is available to identify the person,
department, or facility that collected the specimen. Refer to the HL7 v2.6 specification
for details of the XCN data type. IHE PCD does not further constrain this field.
OBR-17 Order Callback Phone Number (XTN) 00250
This field is the telephone number for reporting a status or a result using the standard
2570 format with extension and/or beeper number when applicable. This can be used to pass
the nurse call system patient station telephony call back information to the caregiver. If
the structure of the telephony dial string is not known then the call back number should
be in the Unformatted Telephone number (ST) component of the field.
OBR-28 Result Copies To (XCN) 00260
2575 This field should not be used in Report Alert [PCD-04] transactions to indicate
PIN/Carrier or other recipients for alert dissemination. Instead, the Participant
Information (PRT) segment introduced in HL7 v. 2.7 may be used in accordance with its
definition in the base standard.
OBR-29 Parent (EIP) 00261
2580 This field serves as the unique identifier for the alert indication in ACM transactions. It is
assigned by the Alert Source and is used by system actors to associate all messages from
all actors that pertain to a particular alert throughout the history of the alert. So the same
value of OBR-29 will be sent by the Alert Source in the messages concerning the start,
end, continuation of the alert, and will also be used in status messages from other actors
2585 concerning that alert. It may consist of a unique identifier of the device such as an EUI-
64 and a serial number or time stamp for the alert, but other forms that are unique among
alerts sourced by a particular Alert Reporter are acceptable. An order number sourced by
the filling application may be used in the case of an order (Pharmacy or Laboratory) and
in this case must also serve to uniquely identify the related alert events. For identification
2590 of status updates to an alert indication see OBR-3 Filler order Number.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 110 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

B.7.1 OBR Observation Request Segment in ACM Transaction [PCD-04]

A Report Alert [PCD-04] transaction contains at most one alert indication.
Additional OBR/OBX segment groupings may appear in the Report Alert [PCD-04] transaction
as the inclusion of a Waveform Content Module (WCM) to communicate waveform evidentiary
2595 data. See the Waveform Content Module (WCM) document for segment and field details.
The OBR segment is used to uniquely identify the alert indication and the descendent alert status
update indications.

Table B.7.1-1: HL7 Attribute Table – OBR – Observation Result

SEQ LEN DT OPT RP/# TBL# ELEMENT NAME
2 22 EI O Placer Order Number
3 22 EI R Filler Order Number
4 705 CWE R Universal Service Identifier
7 24 DTM RE Observation Date/Time
16 3220 XCN O Y Ordering Provider
17 250 XTN O Y/2 Order Callback Phone Number
28 3220 XCN O Y Result Copies To
29 855 EIP R Parent

2600 OBR-2 Placer Order Number (EI) 00216

This field identifies an individual order (e.g., OBR) and is the same as ORC-2.
OBR-3 Filler Order Number (EI) 00217
This field serves as the unique identifier for status updates to an alert indication identified
in OBR-29 Parent. This value is assigned by the Alert Source and is used by system
2605 actors to associate updates to a particular alert identified in OBR-29 Parent.
OBR-4 Universal Service Identifier (CWE) 00238
This field contains the identification of the packaged message content,
196616^MDC_EVT_ALARM^MDC
The original value of ALARM^ALARM is deprecated in favor of the assigned code.
2610 OBR-7 Observation Date/Time (DTM) 00241
This field identifies the point in time at which the Alert Reporter committed itself to
packaging up the Report Alert transaction information to be sent to the Alert Manager.
The alert date and time for initial indications, updates, and endings shall be in the OBX-
14 Observation Date/Time field of the OBX segment associated with the Event
2615 Identification observation. OBR-8 Observation End Date/Time is not used to indicate the
end of an alert since the Alert Report transaction itself is a point in time with zero
duration.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 111 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

OBR-17 Order Callback Phone Number (XTN) 00250

This field is the telephone number for reporting a status or a result using the standard
2620 format with extension and/or beeper number when applicable. This can be used to pass
the nurse call system patient station telephony call back information to the caregiver. If
the structure of the telephony dial string is not known then the call back number should
be in the Unformatted Telephone number (ST) component of the field.
OBR-28 Result Copies To (XCN) 00260
2625 This field should not be used in Report Alert [PCD-04] transactions to indicate
PIN/Carrier or other recipients for alert dissemination. Instead use the Participant
Information (PRT) segment.
OBR-29 Parent (EIP) 00261
This field serves as the unique identifier for the alert indication. It is assigned by the Alert
2630 Source and is used by system actors to associate all messages from all actors that pertain
to a particular alert throughout the history of the alert. So the same value of OBR-29 will
be sent by the Alert Source in the messages concerning the start, end, continuation of the
alert, and will also be used in status messages from other actors concerning that alert. It
may consist of a unique identifier of the device such as an EUI-64 and a serial number or
2635 time stamp for the alert, but other forms that are unique among alerts sourced by a
particular Alert Reporter are acceptable. An order number sourced by the filling
application may be used in the case of an order (Pharmacy or Laboratory) and in this case
must also serve to uniquely identify the related alerts. For identification of status updates
to an alert indication, see OBR-3 Filler order Number.

2640 B.7.1.1 PRT Participation Information Segment in ACM Transaction [PCD-04]

A Report Alert [PCD-04] transaction can optionally contain multiple occurrences of the
Participation Information (PRT) segment to indicate additional alert notification
recipients in addition to any alert notification recipients identified internally by the Alert
Manager (AM). Use of the PRT segment is an extraction from HL7 v2.8. However,
2645 segment optionality and repeat indications are specific to the PCD-04 message. There is
one recipient per PRT segment occurrence. The group of PRT segments optionally
identifying the additional recipients is in the PCD-04 message after the OBR segment
identifying the alert and before any OBX observation segments associated with the alert.
The content of a PRT segment shall resolve to an unambiguous single recipient, be it an
2650 identified person in PRT-5 or a communication endpoint device destination identified by
its telecommunication address in PRT-15. If both PRT-5 and PRT-15 are populated the
Alert Manager may send the alert notification to additional endpoint communication
devices associated with the person identified in PRT-5.

Table B.7.1.1-1: HL7 Attribute Table – PRT – Participation Information

SEQ LEN DT OPT RP/# TBL# ELEMENT NAME
1 1..4 EI R N Participation Instance ID

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 112 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

SEQ LEN DT OPT RP/# TBL# ELEMENT NAME

2 2..2 ID R 0287 Action Code
3 CWE O Action Reason
4 CEW R 0912 Participation
5 XCN C N Participation Person
6 CWE O Participation Person Provider Type
7 CWE O 0406 Participation Organization Unit Type
8 XON O N Participation Organization
9 PL O N Participation Location
10 EI O N Participation Device
Participation Begin Date/Time (arrival
11 DTM O
Time)
Participation End Date/Time (departure
12 DTM O
time)
13 CWE O Participation Qualitative Duration
14 XAD O N Participation Address
15 XTN C N Participation Telecommunication Address

2655
PRT-1 Participation Instance ID (EI) 02379
This field contains a unique identifier of the specific participation record.
PRT-2 Action Code (ID) 00816
For the PCD-04 message this field shall contain the value AD indicating Add.
2660 PRT-3 Action Reason (CWE) 02380
For the PCD-04 message this field is optional.
PRT-4 Participation (CWE) 02381
For [PCD-04] this field shall contain Alert Reporter indicating Alert Recipient. This is an
addition to HL7 v2.8 Table 0912 specifically for the PCD-04 message such that PRT
2665 segment occurrences identifying alert recipients can be unambiguously identified for
processing, independent of unrelated to alert processing PRT segments containing RCT
(indicating Result Copies To).
PRT-5 Participation Person (XCN) 02382
This is the identification of the person that is the recipient of the alert notification. If this
2670 field is populated it shall unambiguously resolve to one person. If this field is populated
and PRT-15 is not populated it presumes the Alert Manager will internally resolve the
person to their currently assigned endpoint communication device or devices.
PRT-6 Participation Person Provider Type (CWE) 02383
For the PCD-04 message this field is optional.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 113 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

2675 PRT-7 Participation Organization Unit Type (CWE) 02384

For the PCD-04 message this field is optional.
PRT-8 Participation Organization (XON) 02385
For the PCD-04 message this field is optional.
PRT-9 Participation Location (PL) 02386
2680 For the PCD-04 message this field is not used.
PRT-10 Participation Device (EI) 02348
For the PCD-04 message this field is not used.
PRT-11 Participation Begin Date/Time (DTM) 02387
For the PCD-04 message this field is not used.
2685 PRT-12 Participation End Date/Time (DTM) 02388
For the PCD-04 message this field is not used.
PRT-13 Participation Qualitative Duration (CWE) 02389
For the PCD-04 message this field is not used.
PRT-14 Participation Address (XAD) 02390
2690 For the PCD-04 message this field is not used.
PRT-15 Participation Telecommunication Address (XTN) 02391
This field optionally contains the telecommunication identification of the alert
notification recipient’s telecommunication device (phone #, carrier and PIN, etc.). If this
field is populated it shall unambiguously resolve to one endpoint communication device.
2695 If this field is not populated then PRT-5 Participation Person shall be populated and it is
presumed the Alert Manager will internally resolve the person to their currently assigned
endpoint communication device or devices.
If the field value represents a telecommunications carrier identification and PIN
reference, the carrier identification string goes in the fourth component Communication
2700 Address and the PIN string goes in the seventh component Local Number. If the field
value represents a telephony dial string it can either be split into its XTN data type
components or it can be a dial string in the twelfth component Unformatted Telephone
number.

B.8 OBX - Observation/Result segment

2705 Refer to HL7 v2.6: Section 7.4.2
The HL7 OBX segment is used to transmit a single observation or observation fragment. For
special considerations concerning OBX field usage in [PCD-03] transactions, see Section
3.3.4.4.8.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 114 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

It is important to note that the values used for the OBX fields depend upon whether the OBX is
2710 being used to provide information about the device(s) from which measurements are derived or
to provide information related to the measurement metrics and related information. The IHE
PCD TF defines the appropriate coding for usage in a device related or metric related context.
Each OBX shall be coded for a specific context – device related or metric related.

Table B.8-1: OBX segment

SEQ LEN DT Usage Card. TBL# Element name
1 4 SI R [1..1] Set ID – OBX
2 3 ID C [0..1] 0125 Value Type
3 705 CWE R [1..1] Observation Identifier
4 20 ST R [1..1] Observation Sub-ID
5 9999 Varies C [0..1] Observation Value
9
6 705 CWE C [0..1] Units
7 60 ST CE [0..1] References Range
8 5 IS CE [0..1] 0078 Abnormal Flags
9 5 NM X [0..0] Probability
10 2 ID CE [0..1] 0080 Nature of Abnormal Test
11 1 ID R [1..1] 0085 Observation Result Status
12 24 DTM X [0..0] Effective Date of Reference
Range
13 20 ST X [0..0] User Defined Access Checks
14 24 DTM RE [0..1] Date/Time of the Observation
15 705 CWE RE [0..1] Producer's ID
16 3220 XCN RE [0..1] Responsible Observer
17 705 CWE RE [0..n] Observation Method
18 427 EI RE [0..1] Equipment Instance Identifier
19 24 DTM CE [0..1] Date/Time of the Analysis
20 705 CWE RE [0..*] 0163 Observation Site

2715
OBX-1 Set ID - OBX
This field contains the sequence number of the OBX in this message; i.e., 1st OBX Set
ID = 1, 2nd OBX set ID = 2, etc., regardless of whether the OBX refers to a device or a
metric value.
2720 OBX-2 Value Type
Condition Predicate: must be valued if the value of OBX-11 is not X.
The Value Type field shall be filled according to HL7 Version 2.6 standard (table 0125).
For example, if the result is ">300" the Value Type "SN" (Structured Numeric) SHALL
be used instead of the "ST" (String) value type that was used in previous versions of

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 115 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

2725 HL7. For example, if reporting a displayed I:E ratio of 1:2, the Value Type "SN"
(Structured Numeric) MAY be used in lieu of the "NM" (Numeric) datatype, e.g.,
|^1^:^2|, to express the ratio in a clinically familiar format (the "ST" value type SHALL
NOT be used in this case). See the details and the examples in the HL7 V2.6 (7.4.2). For
an observation that consists of a time measurement (e.g., bleeding time) the TM Value
2730 Type is preferred to NM but this is not made mandatory.
Refer to TF-3 for details of the data types used in the mappings.
OBX-3 Observation Identifier
Identifies the type of device providing the related values. This is required if structured
device (and if relevant, subdevice) identification is provided in the message. For the PCD
2735 TF, this shall be used for all devices capable of providing structured device information.
For the IHE PCD transactions, implementations shall use the terms defined in the current
version of the Harmonized Rosetta Terminology (Volume 3 of the Technical Framework
contains further details and references on the Rosetta Terminology Mapping as well as
important information on system responsibilities regarding terminology). The Rosetta
2740 codes are based on terms from the ISO/IEEE 11073 Nomenclature where available, and
where the Nomenclature does not currently contain a matching term, gives provisional
vendor-neutral terms to be submitted to the IEEE 11073 Upper Layers Committee as
suggestions for adoption into the Nomenclature. If term cannot be found in this way and a
matching term is available in LOINC, then the next preference is to use the LOINC term.
2745 If LOINC also does not support a term then SNOMED CT or another coding scheme
recognized by the HL7 standard takes precedence if a matching term is available. In the
cases where such resources are not explicitly identified by standards, implementations
may, by local arrangement, utilize any resource (including proprietary or local) to achieve
compatibility among the systems involved, provided also that any licensing/copyright
2750 requirements are satisfied
In the case where the nomenclature term does not convey the distinction between an
observation measurement and a setting for a quantity that may be either, see OBX-17
Observation Method for a way of encoding the distinction.
In the case where the nomenclature item does not distinguish between a manually
2755 initiated (episodic) measurement and one that is automatically initiated on a schedule
(periodic measurement), the OBX-17 Observation Method may also be used to add this
information.
OBX-4 Observation Sub-ID
This field shall be used to distinguish between multiple OBX segments and represent the
2760 hierarchical (containment) relations among the segments. It does so by providing an
unambiguous mapping from observation contained in the OBX segment to the IEEE
11073 containment tree for the Medical Device System sourcing the observation (see
Appendix A Mapping ISO/IEEE 11073 Domain Information Model to HL7).

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 116 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

B.8.1 OBX-4 in a 'flattened' representation of a device

2765 A 'map' of the hierarchical structure of the device representation, in other words the
device's containment tree can be constructed from the set of OBX-4 values in a full
observation report of all metrics the device produces. The highest (most inclusive)
hierarchical level is the Medical Device System (MDS), representing the whole device. In
the simplest, "flattened", representation of a device, it is the only level that is present. In
2770 the flattened representation, no Virtual Medical Devices (VMD) and no channels are
identified in the hierarchy. Every metric is treated as contained only by the MDS, and it
has an OBX-4 value of <n>.0.0.<m>, where <n> is the unsigned number chosen to
identify the MDS (for simplicity, our examples will use 1 to identify the first or sole
MDS, but other numbers may be applied), and the unsigned number <m>identifies the
2775 particular metric, and must be different for each metric. The flattened representation has
only one device-related OBX segment, the one representing the MDS.

B.8.2 OBX-4 in a hierarchical representation of a device

Examples of the disadvantages of the flattened representation are that:
It doesn't allow making the sometimes vital distinction between channels in an infusion pump.
2780 • It doesn't allow distinguishing two measurements with the same OBX-3 Observation
Identifier coming from the same MDS, which is possible in a complex monitoring
situation, so that one of them is typically dropped.
• It doesn't allow for the logical representation of VMDs for a subsystem module of a
modular device, which in turn allows for the traceability of a measurement to a particular
2785 module. It also allows giving information about the module itself such as its serial
number.
In a full hierarchical representation these limitations are removed because the metrics are
represented as belonging not only to a particular MDS, but also to a particular VMD, and, when
desired, as belonging to a particular channel, and each one of higher-level entities has a device-
2790 related OBX segment identifying it, which can be correlated with the OBX-4 values in the OBX
segments of the metrics it produces.
The implementer of a Device Observation Reporter may choose the hierarchical representation
for a particular device, simplifying to a flattened representation if it meets the needs of the use
case. When a content model is specified for the class of device in Volume 3 of the IHE PCD
2795 Technical Framework, the model should be used as the basis for the representation.

B.8.3 'Device-related' and 'metric-related' OBX segments in hierarchy are tied

together by their OBX-4 values
The MDS, and any VMD and channels included in the models, shall each be represented by a
'device-related' OBX which gives in OBX-3 the MDC code for the kind of MDS, VMD, or
2800 channel that it is. The set of device-related OBX segments show the hierarchical structure or
containment tree of the device. For metric related data, this field is used to associate metrics to
MDS and potentially VMD and channel hierarchically, and to each other. The dotted notation

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 117 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

provided for in HL7 Ch7, 7.4.2.4, Fig 4 shall be used as follows:

<MDS>.<VMD>.<Channel>.<Metric> [.FACET [.SUBFACET]], where the optional facet and
2805 subfacet entries are used only when specified for a particular profile, and distinguish multiple
information items related to the same metric according to a specific scheme documented with the
particular profile.
For device related OBX segments that convey information about hierarchical levels higher than
METRIC (that is, information about an MDS, VMD, or Channel), the entries in the dotted
2810 notation concerning the lower dot-levels (that is, VMD, Channel or metric levels for an MDS,
channel and METRIC for a VMD, and so forth) have no meaning and this should be signified by
setting them to zero. So, for information relating to the first MDS, OBX-4 should be 1.0.0.0.
Receiving systems shall recognize from such trailing zeros in OBX-4 that the segment is device-
related and the information applies to an MDS, VMD, or channel rather than a metric.
2815 This scheme allows the VMD, CHAN, METRIC and FACET information to be associated with
‘ancestor’ information higher up in the observation hierarchy. This is especially critical for
devices like infusion pumps that have multiple channels with the same METRIC level identifiers.
The scheme uses simple dotted decimal numeric identifiers where each number is a nonnegative
integer. These must create unique n-tuples for each OBX. (That is, each OBX in a set grouped
2820 within the scope of an OBR segment must have a distinct value of OBX-4).
The OBX-4 Sub-ID is not normative for a given metric (identified in OBX-3). For example, an
OBX-4 of 1.2.3.4 is not fixed to “heart rate.” If a parameter is included in multiple places within
a containment (i.e., OBX-3 has the same value), the OBX-4 Sub-ID for each place will be
unique, distinguishing each instance. Different systems may generate different OBX-4 identifiers
2825 for the same metric – the only requirement is that the OBX-4 uniquely identifies each instance of
a metric within a containment.
In the OBX-4 field of a metric OBX, the special value ‘0’ implies an ‘anonymous’ placeholder
for the corresponding position in the containment hierarchy. This would be used for an
unspecified VMD and/or CHAN (but note that when the '0' is part of a sequence of trailing '0'
2830 entries signifying that the dotted notation identifies data related to an MDS, VMD, or channel
rather than a metric as described above).
IEEE 11073-20601 for Personal Health Devices uses a 'flattened' device representation and thus
does not use the VMD or CHAN levels, so these levels will be '0', consistent with the rule just
given. For example, an OBX-4 value of 1.0.0.1 could be used, for the observation hierarchy
2835 MDC_DEV_SPEC_PROFILE_ PULS_OXIM/<no VMD>/<No
channel>/MDC_PULS_OXIM_PULS_RATE.
The values of the 'dotted notations' of the OBX segments associated with a particular OBR
(forming an ORDER_OBSERVATION segment group) establish a nested hierarchical
arrangement representing the containment of lower-level within higher-level constructs (for
2840 example, all metric OBXs with a dotted notation beginning with '1.2' belong to the second VMD
of the first MDS). This is exploited to support a form of inheritance for time stamps (see Section
B.7.2 Time Stamps and Time Synchronization) so that, for example, a time stamp given in OBX-
14 at the channel level applies to all metrics contained within that channel unless overridden by a
time stamp in OBX-14 in the metric itself.
______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 118 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

2845 Expected future usage, not supported in current version of the Technical Framework: If it
is desired to add OBX segments giving values for attributes of an MDS, VMD, or channel, that
is, information about the MDS, VMD or channel itself rather than a contained metric (for
example, the battery state of a portable monitor which applies to the whole device rather than to
a particular metric, or the off-on state of a module corresponding to a VMD), the OBX segments
2850 giving the information should immediately follow the relevant 'device-related' OBX segment,
and should have as its OBX-4 value the OBX-4 value of the relevant MDS, VMD, or channel,
followed by a non-zero facet number. Multiple attributes of this kind shall have distinct facet
numbers.

B.8.4 Dictionary ordering of 'device-related' and 'metric-related' OBX segments

2855 To facilitate processing and use of this containment hierarchy, OBX segments should be
arranged in "dictionary order" of dotted notations. This implies that, although numbers assigned
to MDS, VMD, and channels need not constrained to start at one and step upward by one
(although for simplicity the examples in this document will usually do so), the magnitude of the
numbers are significant as they will be used as the basis of sorting. Dictionary order means for
2860 example that all metrics belonging to the second channel should appear together in order of their
metric-level element of the dotted notation (x.y.2.1, x.y.2.2, etc.) after any metrics belonging to
the first channel (x.y.1.z) and before any metrics belonging to the third channel (x.y.3.z).
Similarly, all OBX segments belonging to the first VMD should be placed before those
belonging to the second, and so on. This scheme may be used for '0' values in any position
2865 simply by inserting them in the sort order before '1' values (simple numeric sort within dot
position). Note that this is not a simple string sort, because of the possibility that the numbers in
a particular level may be more than a single digit long (e.g., 1.11.2.3).
This ‘dictionary order’ should also be applied to device-related as well as to metric OBX
segments: all MDS device-related segments for the first device should precede all VMD device-
2870 related segments for the first VMD of the first device, which in turn should precede any channel
device-related segment(s) for the first channel, if any, of the first device (recall that channels are
optional), and any channel segments should precede all the metric OBX segments of the first
VMD and channel of the first device. The order goes to the second channel of the first VMD if
any, and so on until the contents of all the channels of the first VMD have been given, then
2875 device-related segments for the second VMD, and so on in a similar fashion. (In programming
terms, this is a depth-first traversal of the 11073 “containment tree” of the objects in the device).
The following illustration shows the OBX-4 values in a legal "dictionary order" message. It is
merely one illustration and not normative. For example, the numbers don't need to start at one
and increase by one at each level. The aspects that are required are:
2880 1. Each OBX segment has a distinct OBX-4 value and no device or metric OBX segment is
repeated within an ORDER_OBSERVATION segment group (that is, under one OBR
segment).
2. A distinct value for an OBX-4 component of an OBX-4 value implies that the
corresponding element (MDS, VMD, Channel, Metric) is distinct, and the same value of
2885 a component always implies the same corresponding entity in all OBX segments.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 119 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

3. The sequences of MDS, VMD, Channel, and Metric numbers in the OBX-4 value shall
be in dictionary (lexicographic) order following the usual mathematical definition (see,
for example, https://en.wikipedia.org/wiki/Lexicographical_order). An acceptable
variation is to include all device-related OBX segments with their OBX-4 values in
2890 dictionary order, followed by all metric OBX segments in lexicographic order – this also
achieves the design goal of having all references from metric OBX segments to device-
related segments be references to information sent earlier in the data stream.
4. If follows from this and the structure and rules already given for OBX-4 components, that
the metric OBX segments follow their corresponding device-related OBX segments.

2895 "Dictionary order" illustration

OBX-4 value Comment
1.0.0.0 MDS 'device-related' OBX
1.1.0.0 VMD 1 within MDS 1 'device-related' OBX
1.1.1.0 Channel 1 within VMD 1 within MDS 1 'device-related' OBX
1.1.1.1 Metric 1 within Channel 1 within VMD 1 within MDS 1 metric OBX
1.1.1.2 Metric 2 within Channel 1 within VMD 1 within MDS 1 metric OBX
1.1.2.0 Channel 2 within VMD 1 within MDS 1 'device-related' OBX
1.1.2.1 Metric 1 within Channel 2 within VMD 1 within MDS 1 metric OBX
1.2.0.0 VMD 2 within MDS 1 'device-related' OBX
1.2.0.1 Metric 1 within VMD 2 within MDS 1 metric OBX (Note: this VMD has no channels, so
channel entry in OBX-4 is zero and no device-related OBX segment for channel is included)
2.0.0.0 MDS 2 'device-related' OBX
(and so on)

B.8.5 OBX-4 Sub-id in Alert Communication Management transactions ([PCD-04],

[PCD-06], [PCD-07])
The 11073 MDS indication is in the OBX-5 Observation Value field of the observation segment
2900 occurrence whose OBX-4 Sub-ID field dot notation element 1 maps to the 11073 MDS value.
The 11073 VMD indication is in the OBX-5 Observation Value field of the observation segment
occurrence whose OBX-4 Sub-ID field dot notation element 2 maps to the 11073 VMD value.
The 11073 CHANNEL indication is in the OBX-5 Observation Value field of the observation
segment occurrence whose OBX-4 Sub-ID field dot notation element 3 maps to the 11073
2905 CHANNEL value.
The 11073 NU indication is in the OBX-5 Observation Value field of the observation segment
occurrence whose OBX-4 Sub-ID field dot notation element 4 (METRIC) maps to the 11073 NU
value.
In the Alert Communications Management Profile, a fifth element, <FACET>, was originally
2910 added to distinguish the additional attributes of an alert, such as Alert State, Phase, Inactivation

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 120 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

State, and Evidentiary Data that must be conveyed in associated additional OBX segments
beyond the first. They shall be in Facet value sequential ascending order.
As of IEEE 11073-10101a the ACM Profile now has official MDC codes and REFIDs for the
alert basic containment observations. Use of these official values is required for implementations
2915 going forward. Use of <FACET> is retained for backward compatibility for existing
implementations.
The FACET are identified by their associated OBX-3 Observation Identifier. Refer to the OBX-3
Value column in Table B.8.5-1 for the value of OBX-3. For identification of physiological
(numeric) alarms versus technical (non-numeric) alarms refer to the value of OBX-8 Abnormal
2920 Flags for the Event Identification Facet.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 121 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Table B.8.5-1: Observation Sub-ID Facets

Facet Facet name OBX-3 Value Comments
value
1 Event identification In the case of physiologic alarm, type of alerts this is the This facet specifies the
associated MDC value for the alert. In the case of MDC event code for
technical alarm type alerts and advisory type alerts this is the alert
196616^MDC_EVT_ALARM^MDC and OBX-5
contains the specific identification of the alert.
2 Source identification For numeric alarms = MDC nomenclature for the source Identifies the
of the alarm, for technical alarms = physiological
68480^MDC_ATTR_ALERT_SOURCE^MDC measurement or
technical source
responsible for the
alert.
3 Event phase 68481^MDC_ATTR_EVENT_PHASE^MDC Whether the stimulus
for the message is the
beginning, end, or some
other state or state
transition of the alert.
4 Alert state 68482^MDC_ATTR_ALARM_STATE^MDC Indicates the state of
the underlying alert
condition at the patient
care device:
inactive |
active |
latched (no longer
active but persisted to
allow caregivers to be
notified of transient but
significant events)
5 Inactivation State 68483^MDC_ATTR_ALARM_INACTIVATION_STA Indicates whether
TE^MDC visual or aural
indications at the
patient care device are
inactivated.
6 Alarm Priority* 68484^MDC_ATTR_ALARM_PRIORITY^MDC Shall be a separate
OBX segment
occurrence if not a
component OBX-8
Abnormal Flags:
This specifies the alarm
priority, with possible
values of
PN = not indicated
PL = Low
PM = Medium
PH = High
7 Alert Type* 68485^MDC_ATTR_ALERT_TYPE^MDC Shall be a separate
OBX segment
occurrence if not a
component of OBX-8
Abnormal Flags: This
specifies the alert type,
with possible values of

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 122 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Facet Facet name OBX-3 Value Comments

value
SP = Alert is Alarm –
Physiological
ST = Alert is Alarm –
Technical
SA = Alert is Advisory

*Alarm Priority and Alert Type inclusion location is either-or. Either both are indicated in components of the same OBX-8
Abnormal Flags field of the OBX segment occurrence associated with the alert indication or both as separate OBX
2925 segment occurrences, one for MDC_ATTR_ALERT_TYPE and one for MDC_ATTR_ALARM_PRIORITY. The
OBX-8 components approach is deprecated. All new implementations are to use the separate OBX segments approach.
The effectivity is such that the Alert Manager shall implement the new approach in addition to the original approach.
The new approach takes precedent over the original approach. If both approaches are present, the Alert Manager shall
ignore the original approach.

2930 Table B.8.5-2: Report Alert PCD-04 Facet Usage by Alert Type
Facet Usage by Alert Type
Facet Name
Alarm Alarm
Advisory
Physiologic Technical
Event Identification R R R
Source Identification R R R
Event Phase R R R
Alert State R R R
Inactivation State R R R
Alarm Priority* R R R
Alert Type* R R R

Where O = optional and R = required.

*Originally contained in OBX-8 Abnormal Flags, implementations going forward should include
as separate OBX segments.
The following table maps ISO 60601-1-8 alarm signal states to IHE ACM PCD-04 attributes and
2935 values.

Table B.8.5-3: ISO 60601-1-8 Alarm condition and alarm signal states mapping to IHE
ACM PCD-04 attributes
ISO 60601-1-8 ISO Value IHE ACM PCD-04 IEEE 11073-10101a attribute and value
Alarm Condition 68482^MDC_ATTR_ALARM_STATE^MDC (multiple is ok)
State
Off (off – need to CP ACM/PCD TF to add value)
Inactive Inactive
Active Active
Latched Latched (may be indicated with other enumeration values)
Alarm condition 8485^MDC_ATTR_ALERT_TYPE^MDC
type

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 123 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

ISO 60601-1-8 ISO Value IHE ACM PCD-04 IEEE 11073-10101a attribute and value
Physiological SP – Physiological
Technical ST – Technical
(Information?) SA – Advisory [alert, but not an alarm]
Alarm type class Indicated in alert indication MDC/REFID
Threshold
Event
Alarm Limit Indicated in the alert indication MDC/REFID
Violation
High
Low
event description
Alarm Condition 68484^MDC_ATTR_ALARM_PRIORITY^MDC
Priority
High PH – High
Medium PM – Medium
Low PL – Low
Information (PI – need to CP ACM/PCD TF to add value)
(not-indicated) PN – Not Indicated
(not-known) (PU – need to CP ACM/PCD TF to add value)
Alarm signal 68483^MDC_ATTR_ALARM_INACTIVATION_STATE^MDC
inactivation state
none (enable?) enabled (note the “d” on the end)
audio-paused audio-paused
audio-off audio-off
alarm-paused alarm-paused
alarm-off alarm-off
acknowledged alert-acknowledged – per ACM/PCD TF CP #126
Phase is not an 68481^MDC_ATTR_EVENT_PHASE^MDC
attribute
tpoint, start, start_only, continue, end, present, update, escalate, inactivate,
acknowledged – per ACM/PCD TF CP #126, deescalate, reset, stop,
(ACM/PCD TF CP to add information or maybe no_alert phase indication
for signaling of AIS updates not in the presence of active alerts)
Source is an 68480^MDC_ATTR_ALERT_SOURCE^MDC
implied attribute
VMD, plus preferably CHAN

OBX-5 Observation Value

2940 Definition: This field contains the value observed by the observation producer. OBX-2-
value type contains the data type for this field according to which observation value is
formatted. It is not a required field because some systems will report only the normality
or abnormality (OBX-8), especially in product experience reporting. The length of the
______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 124 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

observation field is variable, depending upon OBX-3-value type. This field may repeat
2945 for multipart, single answer results with appropriate data types, e.g., CWE, TX, and FT
data types.
When the Observation Value is numeric, IHE PCD adopts the convention that the number
of digits to the right of the decimal point shall reflect the precision ascribed by the device
to the measurement and such digits shall not be arbitrarily dropped from string
2950 representations of the value. So if the measurement has, say, two significant digits after
the decimal point and happens to include one or more trailing zeros, the string
representing the measurement shall include the trailing zeros to reflect precision, even
though they do not change the numeric value.
For the PCD TF this field is required for metric related segments and is null for device
2955 related segments.
OBX-5 Observation Value in PCD-04 and other Alert Communications transactions
This field contains the value observed by the Alert Reporter. Its meaning differs
according to the facet identified in OBX-4 Sub-ID (see above). The following sections
give the details for each facet.
2960 In all cases, OBX-2-value type contains the data type for this field according to which
observation value is formatted. It is not a required field because some systems will report
only the abnormal flags for the observation (OBX-8). The length of the observation field
is variable, depending upon OBX-3-value type. This field may repeat for multipart, single
answer results with appropriate data types, e.g., CWE, TX, and FT data types.
2965 Event Identification Facet
The identity of alerts is represented by event codes from ISO/IEEE 11073-10101
nomenclature for alerts (Block E).
For the ACM Profile in the PCD-04 message, the OBX instance associated with the
Event Identification Facet (where OBX-5 is equal to
2970 196616^MDC_EVT_ALARM^MDC or the identification of the physiologic limit exceed
for physiologic alarms), can be followed by an optional OBX instance to communicate
Alert Reporter Actor originated display text/print text. The MDC and REFID are defined
in IEEE 11073-10101B [Editor’s note: preliminary MDC is 0, preliminary REFID is
MDCX_ATTR_ALERT_ANNOTATION]. The data type for the OBX-5 value shall be
2975 either string (ST) or formatted text (FT). The permits inclusion of text formatting
indications or the inclusion of characters from international character sets. The Alert
Manager will optionally use the Alert Reporter provided text as a suffix to the Alert
Manager synthesized alert text to be included in the alert text to be communicated to the
Alert Communicator alert notification recipients. The Alert Manager (AM) shall include
2980 a separator character (commonly space) or character sequence (commonly space dash
space) between the Alert Manager (AM) synthesized text and the Alert Reporter (AR)
provided annotation text.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 125 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

This capability permits the Alert Reporter to contribute text specifically for inclusion into
the Alert Manager synthesized alert notification text. This can be useful in the case of
2985 textual information not well integrated into an HL7 standard data item. It can also be used
as a foreign language mapping of the alert reason for which the Alert Manager requires
abstraction. This abstraction is meaningful in scenarios where the Alert Reporter, the
alerting medical device, and the alert notification recipients are in one country, and the
Alert Manager is centralized in a different country.
2990 The alert notification text is expected to be rapidly actionable. To that end the additional
text supplied by the AR should be relatively short.
The AR provided additional text is not expected to be utilized for communicating alert
remedies. Remedies would be expected to utilize a distinctly different MDC and REFID.

2995 Figure B.8.5-1: Event Identification Facet (Informative)

Source identification Facet

For an event code corresponding with a metric alarm, this segment identifies the particular
measurement that is the source of the alarm by its MDC nomenclature code in OBX-3
Observation Identifier. If it has a numeric value, it shall be in OBX-5 Observation Value, and if
3000 available the alarm range set in the device will be encoded in OBX-7 Reference Range.
For a technical alert, this facet specifies the subsystem that is the source of the event by its MDC
object code in OBX-5 Observation Value, and by its dotted sub-ID notation according to the
DEC specification for OBX-4 Observation Sub-ID.
Event Phase Facet
3005 Each occurrence contains one of the following phase indications of the alert from the
EventCurrentPhase enumeration:

Table B.8.5-4: Event Phase Coordinated Definitions

future assigned definition
assignment
tpoint time-point

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 126 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

future assigned definition

assignment
start _START start (of an interval event/alert) – an end is expected
start_only start – continue and end are not to be expected
continue continuation (of an ongoing interval event/alert)
end _END end (of an interval event/alert)
present event/alert is active at this time
update Update
escalate escalation of an ongoing alert/alarm
inactivate Inactivation (e.g., silence)
acknowledged Alert acknowledged at the source device
deescalate de-escalation of an ongoing alert/alarm
reset clear latched alarm
stop _STOP pause an event/alert; could restart with same ID later
update _CHANGE similar to CHANGED
update _CHANGED similar to CHANGE
update _CLEARED similar to _CHANGED, except implication that some aspect of
the device has been cleared
stop _COMPL last phase of a START_, (_STOP, _START)*, _COMPL
sequence

Values in the “Assigned” column are in the 11073 standard. “Future assignments” indicates
3010 values in common use not yet in the 11073 standard.

Figure B.8.5-2: Event Phase

The EventCurrentPhase identifies the state transition or state that the current alert message is
indicating: a tpoint event is a time point event with no duration, a continue event indicates that
3015 this message does not represent a state transition but rather reports the continuation of an event
that started at some previous time. An update indicates a change other than a state transition in a
previously reported alert, such as a further change in an out-of-limit metric. The phases escalate
and de-escalate represent changes in alert priority as assessed by the patient care device.
______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 127 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

State transitions
3020 A message representing an alert is sent aperiodically, when the alert undergoes a state transition
that may be significant for notification (alert start, alert end, escalation or de-escalation of
priority as evaluated by the alert source).
By site agreement, messages representing current state of alerts may optionally also be sent at
other times, as for example on a periodic timed basis, or when systems are restarted and a list of
3025 currently active alerts is sent out by the Alert Reporter to refresh the Alert Manager.
Alert current state facet
The value of the AlertState facet reflects whether the alert condition currently exists (inactive or
active) or if the alert condition formerly existed, does not now exist, but is “latched” or held by
the alert source so that caregivers may be notified of transient but significant conditions.
3030
class ACM V6.0 - 2016

«enumeration»
«enumeration» «enumeration»
Ev entCurrentPhase
AlarmState AlarmInactiv ationStateIEEE
tpoint
inactive enabled
start
active audio-paused
continue
latched audio-off
end
alarm-paused
notes update
alarm-off
Sent as OBX-5 escalate
Observation Value of a notes de-escalate
child OBX segment of the Pertains to a set of device alarms - reset
alarm bundle individual, group, system notes
Sent as OBX-5 Observation Value of a Sent as OBX-5 Observation Value of a
child OBX segment of the alarm bundle child OBX segment of the alarm bundle

Figure B.8.5-3: Alert Current State

Inactivation state facet

The AlertInactivationState reflects the current state of the visual and aural alert indications at the
3035 alert source.
This may be empty. May contain the value 'enabled', meaning that both visual and aural alert
indications are enabled at the device. May be repeated, to indicate separately the state of visual
indications at the device by including zero or one of the values:
• alarm-paused
3040 • alarm-off
and zero or one of the values:
• audio-paused

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 128 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

• audio-off
If neither 'alarm-paused' nor 'alarm-off' is included, the visual alarm indication is assumed to be
3045 enabled regardless of whether 'enabled' is also present.
If neither 'audio-paused' nor 'audio-off' is included, the aural alert indication is assumed to be
enabled regardless of whether 'enabled' is also present.
If the optional state indication ‘acknowledged’ is included, it indicates that the alert has been
acknowledged at the alert source device. This indication offers no assurance of a resolution time
3050 for the active alert. This is independent of ‘audio-paused’ and ‘audio-off’ and is a latched status
indication until the alert ends.
OBX-6 Units
See HL7 2.6 Section 7.4.2.6 for further information.
For the PCD TF:
3055 Condition predicate: If OBX-5 is populated with a numeric value then OBX-6 must
contain an appropriate value. For Device Related if OBX-7 is being used for operating
range then populate.
The units used should be in conformance with the Rosetta Terminology (see PCD TF-3
for further details and references). The preferred format is an MDC value, secondly a
3060 UCUM value.
OBX-7 Reference Range
For metric related segments, this should be used to provide the value ‘alarm’ ranges set
with respect to the observed value metric in this OBX, although this is not strictly a
reference range in the sense of the examples given in HL7.
3065 For device related segments this may be used to provide the device measurement range
capability – NOT the metric value ‘alarm’ ranges which shall be in the appropriate
observed value metric OBX, as indicated above.

OBX-8 Abnormal Flags

3070 This field can be used to provide zero or more codes (IS data type) to augment the
interpretation of the observation. Codes beyond the first are included as repetitions (using
the repetition separator character, the tilde ("~").
The following abbreviations in the OBX-8 Abnormality Flags field can be used to
indicate the type of abnormality, its priority as indicated by the source patient care
3075 device, and whether it is a physiological alarm based on monitoring observations from
the patient, or a technical alert indicating a condition of the patient care device and not
the patient which nonetheless requires caregiver action.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 129 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Table B.8.5-5: Abnormal Flags, Abnormality Types

Abnormality Type Abbreviation
Normal, not abnormal N
Below low normal L
Below lower panic limits LL
Above high normal H
Above higher panic limits HH
Abnormal (for non-numeric results) A

Correspondence between IEEE 11073-10201 MeasurementStatus and representation in

3080 Abnormal Flags Field

Table B.8.5-6: Measurement Status

MeasurementStatus ::= BITS-16 { ... } OBX-8 6 OBX-11
No bits set ? raw device measurement; measurement okay, has not been R
reviewed nor validated
invalid(0), INV X
questionable(1), QUES R
not-available(2), NAV X
calibration-ongoing(3), CAL R
test-data(4), TEST R
demo-data(5), DEMO R
validated-data(8), -- relevant, e.g., in an archive F
early-indication(9), -- early estimate of value EARLY R
msmt-ongoing(10), -- indicates that a new measurement is just being taken -- BUSY X
(episodic)
msmt-state-in-alarm(14), -- indicates that the metric has an active alarm ALACT R
condition
msmt-state-al-inhibited(15) -- metric supports alarming and alarms are turned ALINH R
off -- (optional)

Further details of missing or invalid data can be given with codes based on nullFlavors:

Table B.8.5-7: Missing or Invalid Data Codes for OBX-8

Missing or Invalid Data Type Code
No information NI
Not applicable, no proper value NA

6
The HL7 V2.6 IS data type is limited to 5 chars and so these mnemonics cannot be used. Although HL7 V2.7
replaces the IS datatype with the CWE datatype and longer mnemonics we need to restrict this to be compatible with
HL7 V2.6 for now. OBX-8 can be a repeated field with ~ separators.
______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 130 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Missing or Invalid Data Type Code

Temporarily not available. Information is not NAV
available at this time but it is expected that it
will be available later.
Numeric measurement function is available but OFF
has been deactivated by user.
Masked (as for security) MSK
value not in domain OTH
Not a number NAN
Positive infinity PINF
Negative infinity NINF

3085
This is a repeatable field and values from the above tables may be combined by entering them as
repetitions of the field, for example, a field value of 'H~PH~SP' would signify a physiological
measurement with an abnormally high value, constituting a high priority alert condition.
OBX-8 Abnormal Flags in PCD-04 and other Alert Communications transactions
3090 The following abbreviations in the OBX-8 Abnormality Flags field can be used to indicate the
type of abnormality, its priority as indicated by the alert source, and whether the alert is a
physiological alarm based on monitoring observations from the patient, or a technical alarm
indicating a condition of the patient care device and not the patient which nonetheless requires
caregiver action, an advisory, or a combination if simultaneous.
3095

Alarm Priority and Type (Informative)

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 131 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Table B.8.5-8: Abnormal Flags, Alert Priority

Alert Priority Abbreviation
no-alarm PN
low priority PL
medium priority PM
high priority PH

Table B.8.5-9: Abnormal Flags, Alert Source

Alert Source Abbreviation
alarm – physiological SP
alarm – technical ST
advisory SA

3100
This is a repeatable field and values from the above table may be combined by entering them as
repetitions of the field, for example, a field value of 'H~PH~SP' would signify a physiological
measurement with an abnormally high value, constituting an alert that is a high priority
physiological alarm condition. These values shall be recorded in the OBX-8 field of the OBX
3105 segment occurrence associated with the OBX segment identified by the Facet value (1)
associated with Event Identification.

Table B.8.5-10: 11073-10201 AlertType to OBX-8 Abnormal Flags mappings

AlertType OBX-8 Value
no-alert PN
low-pri-t-al PL~ST
med-pri-t-al PM~ST
hi-pri-t-al PH~ST
low-pri-p-al PL~SP
med-pri-p-al PM~SP
hi-pri-p-al PH~SP

OBX-11 Observation Result Status

3110 This field should be filled according to HL7 Table 0085 described in Chapter 7 of HL7.
For the IHE PCD TF, the possible values for this field for this profile are shown in Table
B.8-7: HL7 Table 0085 selected values. The value of X is used for device related
segments where OBX-7 is not used to express the device measurement range capability.
Certain values of OBX-8 Abnormal Flags are semantically linked to OBX-11
3115 Observation Results Status; see the table under OBX-8 for these cases.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 132 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Table B.8.5-11: HL7 Table 0085 selected values

Value Description Comment
C Record coming over is a
correction and thus
replaces a final result
D Deletes the OBX record
F Final results; Can only be
changed with a corrected
result.
P Preliminary results
R Results entered -- not
verified
S Partial results
U Results status change to
final without
retransmitting results
already sent as
‘preliminary.’
W Post original as wrong,
e.g., transmitted for wrong
patient
X Results cannot be obtained
for this observation

B.8.6 OBX-11 Observation Result Status in Report Alert [PCD-04]

The field shall be populated with the result status of the Report Alert transaction. Once a Report
3120 Alert transaction is sent it is by definition final, not held for later revision, and given that state
and status of indications are updated through additional Report Alert transactions specific to the
ACM Profile the only possible value is “F” indicating final.
OBX-14 Date/Time of the Observation:
If this field is present in a 'metric' observation, its value overrides the time stamp in OBR-
3125 7. This should only be populated to signal an episodic observation such as noninvasive
blood pressure. For periodically sampled observations where the time stamp for all
observations in the message is the same and is given in OBR-7, OBX-14 should not be
populated. See also Appendix Section B.8.7 Time Stamps and Time Synchronization for
a general discussion of time stamps in IHE PCD messages.
3130 This implies that time stamp may be 'inherited' from the OBR, which is in effect a higher-
level grouping element for the OBX segments it contains (i.e., that form part of the same
ORDER_OBSERVATION segment group), unless the time stamp is overridden. In a
similar way, an OBX segment applying to a higher level in the MDS-VMD-channel-
metric hierarchy establishes a default time stamp for its contained lower-level elements
3135 unless overridden by associating a time stamp with the lower-level element. So metric
observations get their time stamps from their nearest 'ancestor' which has a time stamp in

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 133 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

OBX-14 unless they have a time stamp of their own in OBX-14. Channel-level OBXs
with filled OBX-14 fields establish a default time stamp for their contained metric
observations.
3140 For the PCD TF the value is the same as OBX-19 Date/Time of the Analysis, but should
be used in preference to OBX-19 if time of the particular observation is relevant and is
different than OBR-7 (that is, in the case of an episodic observation). The OBX-14 time
stamp may be duplicated in OBX-19 if local needs dictate.
OBX-16 Responsible Observer
3145 For the PCD TF:
The identifier values for the Operator ID field may null, if unknown or unspecified at the
sending device.

Table B.8.6-1: Extended composite ID number and name for persons

SEQ LEN DT Usage Card. TBL# Component name
1 15 ST R [1.1] ID Number
2 194 FN RE [0..1] Family Name
3 30 ST RE [0..1] Given Name

3150 OBX-17 Observation Method

For metric related segments observation methods are in many cases implicit in device
related MDC Ref_ID/codes; use of OBX17 is superfluous if given there. However, if
observation method is needed and no device detail is shown then the method shall be
given here.
3155 The preferred format is an MDC value, secondly a LOINC value.
This field is repeatable, and may be used with multiple coded elements to reflect different
aspects of the methods used to make an observation (for example, an episodic as opposed
to continuous, periodic measurement for, say, cardiac output).
The observation may be identified as to whether it is measured, calculated, or a setting,
3160 using these codes based on IEEE 11073 MetricCategory:

Table B.8.6-2: MetricCategory Codes

MetricCategory ::= BITS-16 { ... } OBX-17
mcat-unspec(0), UNSPEC^mcat-unspec^MDC
auto-measurement(1), AMEAS^auto-measurement^MDC
manual-measurement(2), MMEAS^manual-measurement^MDC
auto-setting(3), ASET^auto-setting^MDC
manual-setting(4), MSET^manual-setting^MDC
auto-calculation(5), ACALC^auto-calculation^MDC

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 134 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

MetricCategory ::= BITS-16 { ... } OBX-17

manual-calculation(6), -- relevant, e.g., in an archive MCALC^manual-calculation^MDC

This field can convey the distinction between measurements (AMEAS or MMEAS)
settings (MMEAS or MSET), as well as whether the measurement or setting was initiated
3165 by an operator (MMEAS, as in an episodic measurement, MSET, as in a manual setting)
or automatically, as in a periodic measurement (AMEAS).
If omitted, the default value is AMEAS.
OBX-18 Equipment Instance Identifier
This field identifies the Equipment Instance (e.g., infusion pump, physiological monitor)
3170 responsible for the production of the observation. This is to provide specific traceability
for the source of the observation, and so identification should identify the equipment at
the lowest practical subsystem level where this applies: for example, the individual
removable module in a physiological monitor. This allows an observation or a trouble
indication to be traced to its source as specifically as possible.
3175 Future implementation note: as of HL7 V2.7, this field is retained for backward
compatibility only. This field will be represented through the PRT segment. Future
versions of the IHE PCD Technical Framework will require the use of this segment,
which will also provide for including the Unique Device Identification adopted by the
U.S. F.D.A. and being considered by regulatory agencies in other jurisdictions.
3180 For the PCD TF:
The preferred format is an EUI-64 Device ID. The Device Identifier should be globally
unique.
Every device be should be identified by a universally unique identifier in the format
specified by IEEE for the EUI-64 identifier (e.g., "1234567890ABCDEF"). To allow the
3185 Observation Reporting interface to be employed with ‘legacy’ Devices, this field may
also be populated by a combination of serial number, model, and manufacturer (see
Section C.5 EI Data Type for details of how this may be done). If the EUI-64 identifier is
available, it should be recorded in the ‘universal ID’ component of this field. If it is not
available, the manufacturer’s unique device identifier (e.g., serial number) should be
3190 recorded in ‘Entity Identifier’ component (EI-1), with the model identification in the
Namespace ID (EI-2), and the manufacturers identity in the universal ID (EI-3) using an
OID or URI scheme (which should be identified in the universal ID type, EI-4).
Note that OBX-18 is repeatable, and HL7 suggests that where a hierarchical
identification of the equipment is desired (e.g., module or VMD within Medical Device
3195 System) that the lowest-level equipment be sent first, followed by higher levels in
succession.
A permissible optimization is to not send the full hierarchy with every observation, but
rather the identification should be sent at the highest level of device related OBX

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 135 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

possible: i.e., MDS, then VMD, and then Channel. Inheritance should be assumed; i.e.,
3200 for multivalued results from the same Device, this field is required only in the first OBX
segment.
For metric related data this field is not required – unless no device hierarchy, and
therefore related OBXs, is being declared; in which case the device ID should be
provided here if available. Inheritance should be assumed; i.e., for multivalued results
3205 from the same Device, this field is required only in the first OBX segment.
Device identifiers shall be reported in OBX-18, data type ‘EI’ (Entity Identifier), for the
MDS level for PCD devices and DEV_SPEC_PROFILE for PHD devices.

Table B.8.6-3: HL7 Component Table - EI – Entity Identifier

SEQ LEN DT OPT TBL# COMPONENT NAME
1 199 ST R Entity Identifier
2 20 IS RE 0363 Namespace ID
3 199 ST C Universal ID
4 6 ID C 0301 Universal ID Type

3210 Example 1: EUI-64

This is the preferred and most concise representation of an EUI-64.

|0123456789ABCDEF^^0123456789ABCDEF^EUI-64|

Example 2: Vendor-specific identifier string in OBX-18.1

3215 The EUI-64 form of identifier discussed above is required in production environments. In
debug and test environments the following form of identifier is acceptable, and it may
also be used if desired in addition to EUI-64 as a repeat of this field since OBX-18 is
repeatable. All four OBX-18 components may be used to indicate a vendor-specific
identifier string plus an identifier from HL7 Table 0301 - Universal ID type. Here EI-1
3220 (Entity Identifier is the serial number of the equipment, EI-2 (Namespace ID) identifies
the equipment model, EI-3 (Universal ID) identifies the manufacturer using a DNS
domain name under the control of the manufacturer, and EI-4 (Universal ID Type)
identifies the type of Universal ID contained in EI-3.
3225 |123456^ICU_MONITOR^megacorp.com^DNS|.

See the discussion of the EI data type in Appendix C.5 for further details and examples.
OBX-19 Date/Time of the Analysis
Conditional Predicate: May be used if duplicate of OBX-14 is needed in this field by
3230 receiving system.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 136 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

For the PCD TF use OBX-14 preferentially if device time is relevant. Information in
OBX-14 may be duplicated here if local needs dictate.
OBX-20 Observation Site
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^
3235 <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate
Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding
System Version ID (ST)> ^ <Original Text (ST)>

Definition: This field typically contains the body site(s) where the measurement being
reported was obtained. This field should not be used for a specimen source or specimen
3240 collection site.
This information is of particular importance if the clinical meaning of a value is modified
either directly by the site (for example, is the temperature central or peripheral?) or if the
site of one measurement impacts the value of another measurement (for example, is the
finger SpO2 probe on the same arm as the NIBP cuff?). In most cases these observations
3245 are performed directly upon the patient and do not involve a specimen.
Any nationally recognized coding system might be used for this field including
SNOMED or MDC; alternatively, the HL7 Table 0163 may be used. Veterinary medicine
may choose the tables supported for the components of this field as decided by their
industry.

3250 B.8.7 Time Stamps and Time Synchronization

Medical device data observations conveyed by the IHE PCD DEC Technical Frameworks should
where feasible use ‘consistent time’ for MSH-7, OBR-7, OBR-8 and OBX-14, where ‘consistent
time’ is based on a known reference time source such as NTP or similar service. Since medical
devices may use local clocks that are not synchronized to ‘consistent time’, a standardized
3255 representation for disclosing how the device time(s) were mapped to ‘consistent time’ is required
to provide traceability between the two.
In order to facilitate the correlation of transmitted observations, each observation should contain
a time stamp from a consistent, isochronous time-base, either by default reference to [OBR-7,
OBR-8) or by an overriding value in OBX-14. Since many medical devices have only a sense of
3260 local time, and this local time may not be equivalent to the local time of the DOR, it is a
responsibility of the DOR to ensure the reported times within an Observation Result message are
consistent. This means that all observation times reported SHOULD be UTC, as indicated by
including a time zone offset of +0000, but it is permissible to use local time with the required
correct time zone offset included in the timestamp representation since this can readily be
3265 converted to UTC whatever the time zone of the receiving system. In order to preserve the
original time marking provided by the device, the Observation Result message SHALL contain a
synchronization time element such as MDC_ATTR_TIME_ABS at the Medical Device System
level which discloses the device’s notion of time, as described in the following table. The DOR
SHALL use this device time as the basis for correcting the timestamps from the device (for
3270 example, for OBX-14) to the DOR’s ‘consistent time’.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 137 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Msg Segment Description and comments Status

MSH...... MSH-7 Date/Time of Message created/sent (DTMDOR) M
PID...... M
OBR...... [OBR-7, OBR-8) Default time interval for child OBXs (DTMDOR) M
OBX.. 0.0.0.1 MDC_TIME_SYNC_PROTOCOL (time sync protocol used by the DOR) O
OBX.. 0.0.0.2 MDC_TIME_ACCURACY (known or estimated accuracy of DOR time) O
OBX.. 1 MDS for device #1 M
OBX.. 1.0.0.1 MDC_TIME_CAP_STATE (BITS-16, using MdsTimeCapState) O
OBX.. 1.0.0.2 MDC_TIME_SYNC_PROTOCOL (from nom-part-infrastructure) O
OBX.. 1.0.0.3 MDC_TIME_SYNC_ACCURACY (device absolute time accuracy) O
OBX.. 1.0.0.4 MDC_ATTR_TIME_ABS (displayed time) and OBX-14 (DTMDOR) C7
OBX.. 1.0.0.5 MDC_ATTR_TIME_REL (relative time) and OBX-14 (DTMDOR) C
OBX.. 1.0.0.6 MDC_ATTR_TIME_HI_RES (hi-res rel time) and OBX-14 (DTMDOR) C
OBX.. 1.0.0.7 OBX-14 (DTMDOR, optional, overrides default (OBR-7, OBR-8] time interval
OBX.. 1.0.0.7.1 OBX-14
OBR...... [OBR-7, OBR-8) Default time interval for child OBXs (DTMDOR) M
OBX.. 2 MDS for device #2 M

Notes:
Status column gives Presence Qualifier, M: mandatory, O: option, C: conditional.
The dotted numbers represent the object hierarchy value of OBX-4 and are provided as example values only.
3275 a. DTMDOR is the datetime of the DOR, reported with an IHE PCD modification of the HL7 V2.6 ‘date/time’ data type
differing in the specification of the time zone offset. See Appendix C.4 for details. A time stamp resolution of at least
one second and a time zone offset are required, e.g., YYYYMMDDHHMMSS[.S[S[S[S]]]]+/-ZZZZ (required items
shown in bold font).
b. Within the time scope of each OBR and the time interval expressed in [OBR-7, OBR-8), time discontinuities in the
3280 MDC_ATTR_TIME_ABS displayed time are prohibited. Discontinuities due to daylight savings or other clock
adjustments require that data on the new displayed timeline shall be sent as a separate OBR.
c. The OBR establishes the default time context for all its child OBXs, but can be overridden by a time stamp in OBX-14.
d. The time interval specified by [OBR-7, OBR-8) is a mathematically ‘closed’ interval for OBR-7 and ‘open’ for OBR-8.
A datum that occurs exactly at the time specified by OBR-8 would be sent in the next time epoch. This allows
3285 subsequent OBR segments to represent a continuous sequence of time. For encoding a simple set of episodic
measurement, if there is no logical "end" of the observation period, OBR-8 may be set to the message creation time to
indicate the logical upper limit for the contained observations.

HL7 time stamps sent in MSH-7, OBR-7, OBR-8 and OBX-14 should in most situations be
3290 ‘consistent time’ based on NTP or any other reference time source that provides traceability to
NTP when this is feasible. As a consequence, it is strongly encouraged that the gateway or
application device (AHD) support synchronized time as an NTP or SNTP (or other time service)
client so that it can (1) apply consistent time stamps to the data reported over the WAN interface
and (2) provide a time synchronization service to the agents connected to it.
3295 The MDC_ATTR_TIME_ABS (in OBX-3) observation provides traceability between the
displayed time shown on the device, as a DTM datatype in OBX-5, and the corresponding
gateway or AHD time reported in OBX-14.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 138 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

The MDC_ATTR_TIME_REL and MDC_ATTR_TIME_HI_RES (in OBX-3) observations

provide traceability between the relative or hi-resolution relative values, reported as an integer
3300 value in OBX-5, and the corresponding AHD time reported in OBX-14. The units-of-measure
are s or ms, expressed as MDC units.

B.8.8 Device Time Synchronization Capabilities

OBX-2: CWE
OBX-3: 68219^MDC_TIME_CAP_STATE^MDC
3305 OBX-5: Valid device time capabilities include (one or more):

Table B.8.8-1: OBX-5 Values for Device Time Synchronization Capabilities

OBX-5 values (one or more ...) Description
<0 or 1>^mds-time-capab-real-time-clock(0), device supports an internal RTC
<0 or 1>^mds-time-capab-set-clock(1), device supports Set Time Action
<0 or 1>^mds-time-capab-relative-time(2), device supports RelativeTime
<0 or 1>^mds-time-capab-high-res-relative-time(3), device supports HighResRelativeTime
<0 or 1>^mds-time-capab-sync-abs-time(4), device syncs AbsoluteTime
<0 or 1>^mds-time-capab-sync-rel-time(5), device syncs RelativeTime
<0 or 1>^mds-time-capab-sync-hi-res-relative- device syncs HiResRelativeTime
time(6),
<0 or 1>^mds-time-state-abs-time-synced(8), AbsoluteTime is synced
<0 or 1>^mds-time-state-rel-time-synced(9), RelativeTime is synced
<0 or 1>^mds-time-state-hi-res-relative-time- HiResRelativeTime is synced
synced(10),
<0 or 1>^mds-time-mgr-set-time(11) manager is encouraged to set the time

B.8.9 Device and/or DOR Synchronization Protocol

Beyond the use of the MDC_ATTR_TIME_ABS, MDC_ATTR_TIME_REL, and
3310 MDC_ATTR_TIME_HI_RES time code observations, a DOR Device Observation Report MAY
provide additional information about the device clocks, or its own clock, by communicating the
MDC_TIME_SYNC_PROTOCOL of a given device.
OBX-2: CWE
OBX-3: 68220^MDC_TIME_SYNC_PROTOCOL^MDC
3315 OBX-5: Valid synchronization profiles include (choice of one):

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 139 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Table B.8.9-1: OBX-5 Values for Device and/or DOR Synchronization Protocol
OBX-5 values (choice of one) Synchronization Protocol Part::Co Default
de
532224^MDC_TIME_SYNC_NONE^MDC An uncalibrated and unsynchronized local 8::7936 ± 300 s (5 min)
clock source
––––––^MDC_TIME_SYNC_EBWW^MDC A manually set time, by ‘eyeball and –:–––– ± 120 s (2 min)
wristwatch’8
532225^MDC_TIME_SYNC_NTPV3^MDC Network Time Protocol Version 3.0 8::7937 calculate
(RFC1305)
532226^MDC_TIME_SYNC_NTPV4^MDC Network Time Protocol Version 4.0 (under 8::7938 calculate
dev)
532227^MDC_TIME_SYNC_SNTPV4^MDC Simple Network Time Protocol v4 8::7939 estimate
(RFC2030)
532228^MDC_TIME_SYNC_SNTPV4330^M Simple Network Time Protocol v4 8::7940 estimate
DC (RFC4330)
532229^MDC_TIME_SYNC_BTV1^MDC Bluetooth Medical Device Profile 8::7941 not absolute9
––––––^MDC_TIME_SYNC_NCK^MDC HL7 V2 ‘NCK’ System Clock Segment in –:–––– + 5 s, - 0 s
NMD msg
––––––^MDC_TIME_SYNC_GPS^MDC Global Positioning Service (GPS) –:–––– calculate

B.9 ORC – Common Order Segment

3320 In [PCD-03], the Common Order segment (ORC) is used to transmit fields that are common to
all orders (all types of services that are requested). In [PCD-01], ORC segments are not sent.

Table B.9-1: HL7 Attribute Table – ORC – Common Order

SEQ LEN DT Usage Card. TBL ELEMENT NAME
#
1 2 ID R [1..1] 0119 Order Control
2 427 EI R [1..1] Placer Order Number
3 427 EI X [0..0] Filler Order Number
4 22 EI RE [0..1] Placer Group Number
5 2 ID RE [0..1] 0038 Order Status
6 1 ID RE [0..1] 0121 Response Flag
7 705 TQ X [0..0] Quantity/Timing
8 200 EIP RE [0..1] Parent
9 24 DTM R [1..1] Date/Time of Transaction
10 3220 XCN RE [0..*] Entered By
11 250 XCN RE [0..*] Verified By

8
The ‘EBWW’ code was defined in ISO/IEEE 11073-30200, indicating a local time-of-day clock that was manually
set by the ‘eyeball and wristwatch’ method.
9
The synchronization accuracy of the Bluetooth BTV1 clock to an absolute time reference should be reported using
MDC_ATTR_TIME_HI_RES, and OBX-5 should contain the value of the BTV1 clock.
______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 140 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

SEQ LEN DT Usage Card. TBL ELEMENT NAME

#
12 3220 XCN RE [0..*] Ordering Provider
13 80 PL RE [0..1] Enterer's Location
14 250 XTN RE [0..2] Call Back Phone Number
15 24 DTM RE [0..1] Order Effective Date/Time
16 705 CWE RE [0..1] Order Control Code Reason
17 705 CWE RE [0..1] Entering Organization
18 705 CWE RE [0..1] Entering Device
19 705 XCN R [1..1] Action By
20 705 CWE RE [0..1] 0339 Advanced Beneficiary Notice
Code
21 250 XON RE [0..*] Ordering Facility Name
22 250 XAD RE [0..*] Ordering Facility Address
23 250 XTN RE [0..*] Ordering Facility Phone Number
24 250 XAD RE [0..*] Ordering Provider Address
25 705 CWE RE [0..1] Order Status Modifier
26 60 CWE RE [0..1] 0552 Advanced Beneficiary Notice
Override Reason
27 24 DTM RE [0..1] Filler's Expected Availability
Date/Time
28 705 CWE RE [0..1] 0177 Confidentiality Code
29 705 CWE RE [0..1] 0482 Order Type
30 705 CNE RE [0..1] 0483 Enterer Authorization Mode

The following describes the IHE PCD usage of those fields which have a usage other than X in
3325 the above table.
ORC-1 Order Control
Definition: Determines the function of the order segment. The PCD TF requires that this
field be valued as RE, XO, or CH according to the table below when the
RGV^O15^RGV_O15 Pharmacy/Treatment Give Message is used to send information
3330 from the Infusion Order Programmer (IOP) to the Infusion Order Consumer (IOC).

ORC-1 Value Use

RE Start of a new bag, bottle, or container
XO Change of dose or rate on a currently programmed infusion (not valid
for PCA)
CH Program a bolus from an existing infusion

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 141 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

ORC-2 Placer Order Number

Definition: This field contains either the pharmacy system order number, the BPOC
3335 system order ID, or the BPOC administration event ID. This field is a case of the Entity
Identifier data type. The first component required is a string that identifies an individual
order (e.g., OBR). It is assigned by the placer (ordering application). It identifies an order
uniquely among all orders from a particular ordering application. The second through
fourth components contain the application ID of the placing application in the same form
3340 as the HD data type. The second component, namespace ID, is a user-defined coded
value that will be uniquely associated with an application. A given institution or group of
intercommunicating institutions should establish a unique list of applications that may be
potential placers and fillers and assign unique application IDs. The components are
separated by component delimiters.
3345 See Appendix C.5, "EI Data Type" for further information.
See HL7 V2.6 Section 7.4.1.2 for details. This field is required for [PCD-03].
ORC-3 Filler Order Number
Components: <Entity Identifier (ST)> ^ <Namespace ID (IS)> ^ <Universal ID (ST)> ^
<Universal ID Type (ID)>

3350 See HL7 V2.6 Section 4.5.1.3 for details. The PCD TF does not further constrain this
field.
ORC-4 Placer Group Number
See HL7 V2.6 Section 4.5.1.4 for details. The PCD TF does not further constrain this
field.
3355 ORC-5 Order Status
See HL7 V2.6 Section 4.5.1.5 for details. The PCD TF does not further constrain this
field.
ORC-6 Response Flag
See HL7 V2.6 Section 4.5.1.6 for details. The PCD TF does not further constrain this
3360 field.

ORC-8 Parent (EIP) 00222

Components: <Placer Assigned Identifier (EI)> ^ <Filler Assigned Identifier (EI)>
Subcomponents for Placer Assigned Identifier (EI): <Entity Identifier (ST)> & <Namespace ID (IS)> & <Universal
3365 ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Filler Assigned Identifier (EI): <Entity Identifier (ST)> & <Namespace ID (IS)> & <Universal
ID (ST)> & <Universal ID Type (ID)>

Definition: This field relates a child to its parent when a parent-child relationship exists.
The parent-child mechanism is described under HL7 Table 0119 - Order control codes .
3370 The first component has the same format as ORC-2-placer order number (Section 4.5.1.2,
"Placer Order Number (EI) 00216"). The second component has the same format as
ORC-3-filler order number 4.5.1.3Filler Order Number (Section , "(EI) 00217"). The

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 142 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

components of the placer order number and the filler order number are transmitted in sub-
components of the two components of this field.
3375 ORC-8-parent is the same as OBR-29-parent. If the parent is not present in the ORC, it
must be present in the associated OBR. (This rule is the same for other identical fields in
the ORC and OBR and promotes upward and ASTM compatibility.) This is particularly
important when results are transmitted in an ORU message. In this case, the ORC is not
required and the identifying filler order number must be present in the OBR segments.
3380 ORC-9 Date/Time of Transaction
The time in this field should be the time the clinician initiated the program request, not
the time the IOP generated the message. The IOC may use this field to determine if the
request is stale or too old.
See HL7 V2.6 Section 4.5.1.9 for details. The PCD TF does not further constrain this
3385 field.
ORC-10 Entered By
See HL7 V2.6 Section 4.5.1.10 for details. The PCD TF does not further constrain this
field
ORC-11 Verified By
3390 See HL7 V2.6 Section 4.5.1.11 for details. The PCD TF does not further constrain this
field.
ORC-12 Ordering Provider
See HL7 V2.6 Section 4.5.1.12 for details. The PCD TF does not further constrain this
field.
3395 ORC-13 Enterer's Location
See HL7 V2.6 Section 4.5.1.13 for details. The PCD TF does not further constrain this
field.
ORC-14 Call Back Phone Number
See HL7 V2.6 Section 4.5.1.14 for details. The PCD TF does not further constrain this
3400 field.
ORC-15 Order Effective Date/Time
See HL7 V2.6 Section 4.5.1.15 for details. The PCD TF does not further constrain this
field.
ORC-16 Order Control Code Reason
3405 See HL7 V2.6 Section 4.5.1.16 for details. The PCD TF does not further constrain this
field.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 143 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

ORC-17 Entering Organization

See HL7 V2.6 Section 4.5.1.17 for details. The PCD TF does not further constrain this
field.
3410 ORC-18 Entering Device
See HL7 V2.6 Section 4.5.1.18 for details. The PCD TF does not further constrain this
field.
ORC-19 Action By
Components: <ID Number (ST)> ^ <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and
3415 Further Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III)
(ST)> ^ <Prefix (e.g., DR) (ST)> ^ <DEPRECATED-Degree (e.g., MD) (IS)> ^
<Source Table (IS)> ^ <Assigning Authority (HD)> ^ <Name Type Code (ID)> ^
<Identifier Check Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Identifier
Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name Representation Code
3420 (ID)> ^ <Name Context (CWE)> ^ <DEPRECATED-Name Validity Range (DR)> ^
<Name Assembly Order (ID)> ^ <Effective Date (DTM)> ^ <Expiration Date
(DTM)> ^ <Professional Suffix (ST)> ^ <Assigning Jurisdiction (CWE)> ^
<Assigning Agency or Department (CWE)>

Definition: This field contains the identity of the caregiver who initiated the event.
3425 Subfield XCN-1 "ID number" is required for each identifier.
ORC-20 Advanced Beneficiary Notice Code
See HL7 V2.6 Section 4.5.1.20 for details. The PCD TF does not further constrain this
field.
ORC-21 Ordering Facility Name
3430 See HL7 V2.6 Section 4.5.1.21 for details. The PCD TF does not further constrain this
field.
ORC-22 Ordering Facility Address
See HL7 V2.6 Section 4.5.1.22 for details. The PCD TF does not further constrain this
field.
3435 ORC-23 Ordering Facility Phone Number
See HL7 V2.6 Section 4.5.1.23 for details. The PCD TF does not further constrain this
field.
ORC-24 Ordering Provider Address
See HL7 V2.6 Section 4.5.1.24 for details. The PCD TF does not further constrain this
3440 field.
ORC-25 Order Status Modifier
See HL7 V2.6 Section 4.5.1.25 for details. The PCD TF does not further constrain this
field.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 144 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

ORC-26 Advanced Beneficiary Notice Override Reason

3445 See HL7 V2.6 Section 4.5.1.26 for details. The PCD TF does not further constrain this
field.
ORC-27 Filler's Expected Availability Date/Time
See HL7 V2.6 Section 4.5.1.27 for details. The PCD TF does not further constrain this
field.
3450 ORC–28 Confidentiality Code
See HL7 V2.6 Section 4.5.1.28 for details. The PCD TF does not further constrain this
field.
ORC–29 Order Type
See HL7 V2.6 Section 4.5.1.29 for details. The PCD TF does not further constrain this
3455 field.
ORC–30 Enterer Authorization Mode
See HL7 V2.6 Section 4.5.1.30 for details. The PCD TF does not further constrain this
field.

B.9.1 ORC Observation Control Segment in ACM Transaction [PCD-04]

3460 This segment is optionally used to convey order request information for alerts involving
notification of order request or order result. In addition, this segment may allow the association
of the completed observation results reported in OBX segments with a particular previous order
request.

Table B.9.1-1: HL7 Attribute Table – ORC – Observation Control

SEQ LEN DT OPT RP/# TBL# ELEMENT NAME
2 22 EI O Placer Order Number
12 250 XCN O Y Ordering Provider
14 250 XTN O Y/2 Call Back Phone Number

3465
ORC-2 Placer Order Number (EI) 00216
This field is the placer application's order number.
ORC-12 Ordering Provider (XCN) 00226
This field contains the identity of the person who is responsible for creating the request
3470 (i.e., ordering physician). ORC-12-ordering provider is the same as OBR-16-ordering
provider. If the ordering provider is not present in the ORC, it may be present in the
associated OBR. This is particularly important when results are transmitted in an ORU
message. In this case, the ORC is not required and the identifying filler order number
may be present in the OBR segment.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 145 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

3475 ORC-14 Call Back Phone Number (XTN) 00228

This field contains the telephone number to call for clarification of a request or other
information regarding the order. ORC-14-call back phone number is the same as OBR-
17-order callback phone number. If the structure of the telephony dial string is not known
then the call back number should be in the Unformatted Telephone number (ST)
3480 component of the field.

B.9.2 ORC Observation Control Segment in PIV Application Acknowledgment

(RRG^O16^RRG_O16 Pharmacy/Treatment Give Acknowledgement)
In the PIV application acknowledgement, this segment is optionally used by the IOC to contain
the order number and other information that is provided in the PCD-03 message.

3485 Table B.9.2-1: HL7 Attribute Table – ORC – Observation Control

SEQ LEN DT OPT RP/# TBL# ELEMENT NAME
2 22 EI R [1..1] Placer Order Number
9 24 DTM O [0..1] Date/Time of Transaction
19 705 XCN O [0..1] Action By

ORC-2 Placer Order Number (EI) 00216

This field is the placer application's order number.
ORC-9 Date/Time of Transaction
The time in this field should be the time the clinician initiated the program request, not
3490 the time the IOP generated the message. The IOC may use this field to determine if the
request is stale or too old.
See HL7 V2.6 Section 4.5.1.9 for details. The PCD TF does not further constrain this
field.
ORC-19 Action By
3495 Components: <ID Number (ST)> ^ <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and
Further Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III)
(ST)> ^ <Prefix (e.g., DR) (ST)> ^ <DEPRECATED-Degree (e.g., MD) (IS)> ^
<Source Table (IS)> ^ <Assigning Authority (HD)> ^ <Name Type Code (ID)> ^
<Identifier Check Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Identifier
3500 Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name Representation Code
(ID)> ^ <Name Context (CWE)> ^ <DEPRECATED-Name Validity Range (DR)> ^
<Name Assembly Order (ID)> ^ <Effective Date (DTM)> ^ <Expiration Date
(DTM)> ^ <Professional Suffix (ST)> ^ <Assigning Jurisdiction (CWE)> ^
<Assigning Agency or Department (CWE)>

3505 Definition: This field contains the identity of the caregiver who initiated the event.
Subfield XCN-1 "ID number" is required for each identifier.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 146 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

B.10 PRT Participation Information Segment

The Participation Information segment contains the data necessary to add, update, correct, and
delete from the record persons, organizations, or locations (participants) participating in the
3510 activity being transmitted.
The hierarchical positional location of the PRT segment within the HL7 message indicates the
relationship. When the segment is used following the OBR segment, then the participations
relate to the relevant participations in the observation.
The base version of HL7 for IHE PCD transactions is version 2.6. The PRT segment was not
3515 included in version 2.6, but rather was newly added in version 2.7. To avoid unnecessary
changes to other profiles, the IHE PCD Technical Committee determined that the base version
would continue to be 2.6 for the present, but the PRT segment would draw on balloted later
versions for needed semantics.

B.10.1 Current PRT Segment use in ACM Profile transactions

3520 Certain IHE PCD transactions in the ACM Profile new to this version of the Framework require
the new semantics provided in HL7 version 2.7 for the PRT segment which are not available in
version 2.6. These usages are detailed in the discussion below.
In general, the PRT segment is used to describe a participant playing a particular role within the
context of the message. In the ACM Profile, the role being played is that of an alert
3525 dissemination requested or actual recipient.

B.10.2 Future PRT segment use to support Unique Device Identifiers in the PCD
Profiles
Because of the importance of the recently defined Unique Device Identifier from the US FDA,
which was developed with extensive international consultation and is thus likely to be of
3530 international importance as well, the IHE PCD Technical Committee is preparing to enable the
use of this device identification in addition to the IEEE EUI-64 it has previously prescribed for
device identification. This relies on changes and additions to the PRT segment added in HL7
version 2.8.2.
In future versions of this Technical Framework, the PRT segment will be used to convey device
3535 identification information formerly in the OBX-18 field of the OBX segment, which from V2.7
of HL7 is retained for backward compatibility only. The material discussed under PRT-10 and
PRT-16-20 below covers semantics to support inclusion of the FDA Universal Device Identifier
(UDI). The use of UDI is not yet required in this version of the Technical Framework but are
expected to be required when the requirement is considered timely by the IHE PCD Technical
3540 and Planning Committees. In this revision, this information is informative only and this use of
the PRI segment is not required in order to make a valid message in the current version of this
Technical Framework. Implementers should take note and prepare to support this segment.
Implementers should consider supporting this optional usage as soon as is practicable for them,
to prepare for early testing. For a Device Observation Consumer, it is advisable as a first step to

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 147 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

3545 check at a minimum that the PRT segments are accepted without causing unexpected behavior or
error messages even if they are not yet semantically processed.

Table B.10.2-1: HL7 Attribute Table - PRT – Participation Information

SEQ LEN DT OPT RP/# TBL# ELEMENT NAME
1 1..4 EI C N Participation Instance ID
2 2..2 ID R 0287 Action Code
3 CWE O Action Reason
4 CWE R 0912 Participation
5 XCN C Y Participation Person
6 CWE C Participation Person Provider Type
7 CWE C 0406 Participant Organization Unit
Type
8 XON C Y Participation Organization
9 PL C Y Participant Location
10 EI C Y Participation Device
11 DTM O Participation Begin Date/Time
(arrival time)
12 DTM O Participation End Date/Time
(departure time)
13 CWE O Participation Qualitative Duration
14 XAD C Y Participation Address
15 XTN O Y Participant Telecommunication
Address
16 EI O Participant Device Identifier
17 DTM O Participant Device Manufacture
Date
18 DTM O Participant Device Expiry Date
19 ST O Participant Device Lot Number
20 ST O Participant Device Serial Number
21 EI O Participant Device Donation
Identification
22 CNE C Participation Device Type

3550 PRT-1 Participation Instance ID (EI) 02379

Components:<Entity Identifier (ST)> ^ <Namespace ID (IS)> ^ <Universal ID (ST)> ^
<Universal ID Type (ID)>

Definition: This field contains a unique identifier of the specific participation record.
In the case of waypoints tracked for a shipment, it identifies the waypoint.
3555 Condition: The identifier is required for traceability

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 148 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

For the Report Alert Status [PCD-05] transaction this is the unique ID of the
disseminated message and all status updates on the dissemination should use the same ID
value.
PRT-2 Action code (ID) 00816
3560 Definition: This field reveals the intent of the message. Refer to HL7 Table 0287 –
Problem/goal action code HL7 Table 0287 – Problem/goal action code for valid values.
For the Report Alert [PCD-04] transaction the PRT-2 Action code is always AD
indicating Add.
For the Report Alert Status [PCD-05] transaction the PRT-2 Action Code is AD
3565 indicating Add for the first status update and UP indicating Update for all others.
PRT-3 Action Reason (CWE) 02380
Components:<Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate
Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding
System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System
3570 Version ID (ST)> ^ <Original Text (ST)> ^ <Second Alternate Identifier
(ST)> ^ <Second Alternate Text (ST)> ^ <Name of Second Alternate Coding
System (ID)> ^ <Second Alternate Coding System Version ID (ST)> ^ <Coding
System OID (ST)> ^ <Value Set OID (ST)> ^ <Value Set Version ID (DTM)> ^
<Alternate Coding System OID (ST)> ^ <Alternate Value Set OID (ST)> ^
3575 <Alternate Value Set Version ID (DTM)> ^ <Second Alternate Coding System
OID (ST)> ^ <Second Alternate Value Set OID (ST)> ^ <Second Alternate
Value Set Version ID (DTM)>

Definition: This field indicates the reason why the person, organization, location, or
device is assuming (or changing) the role (e.g., shift change, new primary nurse, etc.).
3580 For the Report Alert [PCD-04] transaction the PRT-3 Action Reason, Text, is not
populated.
For the Report Alert Status [PCD-05] transaction the PRT-3 Action Reason, Text, is the
Report Dissemination Alert Status [PCD-07] status text value, and the Coding System is
IHE_PCD_ACM.
3585 Alert Communicator (AC) status values correlated from the Report Dissemination Alert
Status [PCD-07] status values to be returned to the Alert Manager (AM) resulting from
Disseminate Alert [PCD-06] from Alert Manager (AM) to Alert Communicator (AC) and
transcribed into PRT-3-2 Text.

Table B.10.2-2: Communication Status Enumeration from Report Dissemination Alert

3590 Status PCD-07
Req. Value for PRT-3-2 Description
R Received Received by Alert Communicator (AC)
R Undeliverable Undeliverable to endpoint
R Delivered Delivered to endpoint
R Read Read at endpoint
R Accepted Accepted by endpoint
O AcceptedPositive Accepted by endpoint as true positive

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 149 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Req. Value for PRT-3-2 Description

O AcceptedNotRelevant Accepted by endpoint as true positive however not clinically relevant
O AcceptedFalse Accepted by endpoint as false positive
R Rejected Rejected by endpoint
O Cancelled Cancelled by endpoint (does not cancel at alert source)
O CancelledOther Cancelled by other than endpoint (does not cancel alert at source)
O CallbackStart Callback start at endpoint (start of telephony call to alert indicated
destination)
O CallbackEnd Callback end at endpoint (end of telephony call to alert indicated
destination)

PRT-4 Participation (CWE) 02381

Components:<Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate
Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding
3595 System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System
Version ID (ST)> ^ <Original Text (ST)> ^ <Second Alternate Identifier
(ST)> ^ <Second Alternate Text (ST)> ^ <Name of Second Alternate Coding
System (ID)> ^ <Second Alternate Coding System Version ID (ST)> ^ <Coding
System OID (ST)> ^ <Value Set OID (ST)> ^ <Value Set Version ID (DTM)> ^
3600 <Alternate Coding System OID (ST)> ^ <Alternate Value Set OID (ST)> ^
<Alternate Value Set Version ID (DTM)> ^ <Second Alternate Coding System
OID (ST)> ^ <Second Alternate Value Set OID (ST)> ^ <Second Alternate
Value Set Version ID (DTM)>

Definition: This field indicates the functional involvement with the activity being
3605 transmitted (e.g., Case Manager, Evaluator, Transcriber, Nurse Care Practitioner,
Midwife, Physician Assistant, etc.). Refer toHL7 Table 917 for valid values.
For the Report Alert [PCD-04] transaction the presence of one or more PRT segments
containing PRT-4 Participation Identifier, Text is RCT (indicating Result Copies To)
indicates Alert Reporter direct indication of additional recipients.
3610 For the Report Alert [PCD-04] transaction the PRT-4 Participation Identifier, Text is RO
(indicating Responsible Observer).
For the Report Alert Status [PCD-05] transaction the PRT-4 Participation Identifier, Text
is RO (indicating Responsible Observer), and Alternative Identifier is AAP for Alert
Acknowledging Provider.

3615 Table B.10.2-3: HL7 Table 0912 - Participation

Value Description Used with
AD Admitting Provider PV1-17 Admitting doctor
AI Assistant/Alternate Interpreter
AAP Alert Acknowledging Provider PCD ACM Report Alert Status [PCD-05]
AP Administering Provider RXA-10 Administering Provider
ARI Assistant Result Interpreter
AT Attending Provider PV1-7 Attending doctor
AUT AUT Author/Event Initiator ORC-19 Action By

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 150 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Value Description Used with

CP Consulting Provider
DP Dispensing Provider RXD-10 Dispensing Provider
EP Entering Provider (probably not the ORC-10 Entered By
same as transcriptionist?)
EQUIP Equipment
FHCP Family Health Care Professional
MDIR Medical Director OBX-25 Performing Organization
Medical Director
OP Ordering Provider ORC-12 Ordering Provider, OBR-16
Ordering Provider, RXO-14 Ordering
Provider's DEA Number, RXE-13
Ordering Provider's DEA Number, ORC-
24 Ordering Provider Address
PB Packed by
PH Pharmacist (not sure how to dissect RXE-14 Pharmacist/Treatment Supplier's
Pharmacist/Treatment Supplier's Verifier ID
Verifier ID)
PI Primary Interpreter
PO Performing Organization
POMD Performing Organization Medical
Director
PP Primary Care Provider
PRI Principal Result Interpreter
RCT Results Copies To
RO Responsible Observer OBX-16 Responsible Observer
RP Referring Provider PV1-8 Referring doctor
RT Referred to Provider
SB Send by
SC Specimen Collector OBR-10 Collector Identifier
TN Technician
TR Transcriptionist
VP Verifying Provider ORC-11 Verified By
VPS Verifying Pharmaceutical Supplier RXE-14 Pharmacist/Treatment Supplier's
(not sure how to dissect Verifier ID
Pharmacist/Treatment Supplier's
Verifier ID)
VTS Verifying Treatment Supplier (not RXE-14 Pharmacist/Treatment Supplier's
sure how to dissect Verifier ID
Pharmacist/Treatment Supplier's
Verifier ID)
WAY Waypoint
WAYR Waypoint Recipient

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 151 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

PRT-5 Participation Person (XCN) 02382

Components:<Person Identifier (ST)> ^ <Family Name (FN)> ^ <Given Name (ST)> ^ <Second
and Further Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or
3620 III) (ST)> ^ <Prefix (e.g., DR) (ST)> ^ <WITHDRAWN Constituent> ^
<DEPRECATED-Source Table (CWE)> ^ <Assigning Authority (HD)> ^ <Name Type
Code (ID)> ^ <Identifier Check Digit (ST)> ^ <Check Digit Scheme (ID)> ^
<Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name
Representation Code (ID)> ^ <Name Context (CWE)> ^ <WITHDRAWN Constituent>
3625 ^ <Name Assembly Order (ID)> ^ <Effective Date (DTM)> ^ <Expiration Date
(DTM)> ^ <Professional Suffix (ST)> ^ <Assigning Jurisdiction (CWE)> ^
<Assigning Agency or Department (CWE)> ^ <Security Check (ST)> ^
<Security Check Scheme (ID)>
Subcomponents for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own
3630 Surname (ST)> & <Surname Prefix from Partner/Spouse (ST)> & <Surname from
Partner/Spouse (ST)>
Subcomponents for Source Table (CWE): <Identifier (ST)> & <Text (ST)> & <Name of
Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)>
& <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)>
3635 & <Alternate Coding System Version ID (ST)> & <Original Text (ST)> &
<Second Alternate Identifier (ST)> & <Second Alternate Text (ST)> & <Name
of Second Alternate Coding System (ID)> & <Second Alternate Coding System
Version ID (ST)> & <Coding System OID (ST)> & <Value Set OID (ST)> &
<Value Set Version ID (DTM)> & <Alternate Coding System OID (ST)> &
3640 <Alternate Value Set OID (ST)> & <Alternate Value Set Version ID (DTM)> &
<Second Alternate Coding System OID (ST)> & <Second Alternate Value Set
OID (ST)> & <Second Alternate Value Set Version ID (DTM)>
Subcomponents for Assigning Authority (HD): <Namespace ID (CWE)> & <Universal ID
(ST)> & <Universal ID Type (ID)>
3645 Subcomponents for Namespace ID (CWE): <Identifier (ST)> & <Text (ST)> & <Name of
Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)>
& <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)>
& <Alternate Coding System Version ID (ST)> & <Original Text (ST)> &
<Second Alternate Identifier (ST)> & <Second Alternate Text (ST)> & <Name
3650 of Second Alternate Coding System (ID)> & <Second Alternate Coding System
Version ID (ST)> & <Coding System OID (ST)> & <Value Set OID (ST)> &
<Value Set Version ID (DTM)> & <Alternate Coding System OID (ST)> &
<Alternate Value Set OID (ST)> & <Alternate Value Set Version ID (DTM)> &
<Second Alternate Coding System OID (ST)> & <Second Alternate Value Set
3655 OID (ST)> & <Second Alternate Value Set Version ID (DTM)>
Subcomponents for Assigning Facility (HD): <Namespace ID (CWE)> & <Universal ID (ST)>
& <Universal ID Type (ID)>
Subcomponents for Namespace ID (CWE): <Identifier (ST)> & <Text (ST)> & <Name of
Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)>
3660 & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)>
& <Alternate Coding System Version ID (ST)> & <Original Text (ST)> &
<Second Alternate Identifier (ST)> & <Second Alternate Text (ST)> & <Name
of Second Alternate Coding System (ID)> & <Second Alternate Coding System
Version ID (ST)> & <Coding System OID (ST)> & <Value Set OID (ST)> &
3665 <Value Set Version ID (DTM)> & <Alternate Coding System OID (ST)> &
<Alternate Value Set OID (ST)> & <Alternate Value Set Version ID (DTM)> &
<Second Alternate Coding System OID (ST)> & <Second Alternate Value Set
OID (ST)> & <Second Alternate Value Set Version ID (DTM)>
Subcomponents for Name Context (CWE): <Identifier (ST)> & <Text (ST)> & <Name of
3670 Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)>
& <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)>
& <Alternate Coding System Version ID (ST)> & <Original Text (ST)> &
<Second Alternate Identifier (ST)> & <Second Alternate Text (ST)> & <Name
of Second Alternate Coding System (ID)> & <Second Alternate Coding System
3675 Version ID (ST)> & <Coding System OID (ST)> & <Value Set OID (ST)> &
<Value Set Version ID (DTM)> & <Alternate Coding System OID (ST)> &
<Alternate Value Set OID (ST)> & <Alternate Value Set Version ID (DTM)> &

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 152 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

<Second Alternate Coding System OID (ST)> & <Second Alternate Value Set
OID (ST)> & <Second Alternate Value Set Version ID (DTM)>
3680 Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> &
<Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate
Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System
Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original
Text (ST)> & <Second Alternate Identifier (ST)> & <Second Alternate Text
3685 (ST)> & <Name of Second Alternate Coding System (ID)> & <Second Alternate
Coding System Version ID (ST)> & <Coding System OID (ST)> & <Value Set OID
(ST)> & <Value Set Version ID (DTM)> & <Alternate Coding System OID (ST)>
& <Alternate Value Set OID (ST)> & <Alternate Value Set Version ID (DTM)>
& <Second Alternate Coding System OID (ST)> & <Second Alternate Value Set
3690 OID (ST)> & <Second Alternate Value Set Version ID (DTM)>
Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text
(ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> &
<Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding
System Version ID (ST)> & <Alternate Coding System Version ID (ST)> &
3695 <Original Text (ST)> & <Second Alternate Identifier (ST)> & <Second
Alternate Text (ST)> & <Name of Second Alternate Coding System (ID)> &
<Second Alternate Coding System Version ID (ST)> & <Coding System OID
(ST)> & <Value Set OID (ST)> & <Value Set Version ID (DTM)> & <Alternate
Coding System OID (ST)> & <Alternate Value Set OID (ST)> & <Alternate
3700 Value Set Version ID (DTM)> & <Second Alternate Coding System OID (ST)> &
<Second Alternate Value Set OID (ST)> & <Second Alternate Value Set
Version ID (DTM)>

Definition: This field contains the identity of the person who is represented in the
participation that is being transmitted.
3705 If this attribute repeats, all instances must represent the same person.
Condition: At least one of the Participation Person, Participation Organization,
Participation Location, or Participation Device fields must be valued.
For the Report Alert [PCD-04] transaction the PRT-5 participation Person is the
identification of an additional recipient of the dissemination of the alert. The PRT-15
3710 Participation Telecommunication Address may also be used if only a PIN/Carrier
destination is known.
For the Report Alert Status [PCD-05] transaction the PRT-5 Participation Person is the
identification of the person that was the participating recipient of the message.

3715 PRT-6 Participation Person Provider Type (CWE) 02383

Components:<Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate
Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding
System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System
Version ID (ST)> ^ <Original Text (ST)> ^ <Second Alternate Identifier
3720 (ST)> ^ <Second Alternate Text (ST)> ^ <Name of Second Alternate Coding
System (ID)> ^ <Second Alternate Coding System Version ID (ST)> ^ <Coding
System OID (ST)> ^ <Value Set OID (ST)> ^ <Value Set Version ID (DTM)> ^
<Alternate Coding System OID (ST)> ^ <Alternate Value Set OID (ST)> ^
<Alternate Value Set Version ID (DTM)> ^ <Second Alternate Coding System
3725 OID (ST)> ^ <Second Alternate Value Set OID (ST)> ^ <Second Alternate
Value Set Version ID (DTM)>

Definition: This field contains a code identifying the provider type for the participating
person. This attribute correlates to the following master file attribute: STF-4 Staff Type.
Coded values from the correlated master file table are used; the user defined master file

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 153 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

3730 table is used as the coding system for this attribute. For example, if you are using values
from STF-2 Staff Type, the coding system would be HL70182 which is the table number
for the user defined Staff Type table. This field is included in this segment to support
international requirements. When ROL is used in an encounter message, it is not intended
as a master file update.
3735 Condition: This field may only be valued if PRT-5 Participation Person is valued.
For the Report Alert Status [PCD-05] transaction this field is not populated.
PRT-7 Participation Organization Unit Type (CWE) 02384
Components:<Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate
Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding
3740 System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System
Version ID (ST)> ^ <Original Text (ST)> ^ <Second Alternate Identifier
(ST)> ^ <Second Alternate Text (ST)> ^ <Name of Second Alternate Coding
System (ID)> ^ <Second Alternate Coding System Version ID (ST)> ^ <Coding
System OID (ST)> ^ <Value Set OID (ST)> ^ <Value Set Version ID (DTM)> ^
3745 <Alternate Coding System OID (ST)> ^ <Alternate Value Set OID (ST)> ^
<Alternate Value Set Version ID (DTM)> ^ <Second Alternate Coding System
OID (ST)> ^ <Second Alternate Value Set OID (ST)> ^ <Second Alternate
Value Set Version ID (DTM)>

Definition: This field identifies the environment in which the participant acts in the role
3750 specified in PRT-3 Action Reason. In the case of a person, the environment is not the
specialty for the provider. The specialty information for the provider is defined in the
PRA segment.
This attribute is included in the PRT segment to allow communication of this data when
the participant information may not have been communicated previously in a master file
3755 or to provide better context. Refer to User-defined table 0406 - Organization unit type.
This field is included in this segment to support international requirements, and is not
intended as a master file update.
Condition: This field may only be valued if PRT-5 Participation Person is valued.
For the Report Alert Status [PCD-05] transaction this field is not populated.
3760 PRT-8 Participation Organization (XON) 02385
Components:<Organization Name (ST)> ^ <Organization Name Type Code (CWE)> ^ <WITHDRAWN
Constituent> ^ <Identifier Check Digit (NM)> ^ <Check Digit Scheme (ID)>
^ <Assigning Authority (HD)> ^ <Identifier Type Code (ID)> ^ <Assigning
Facility (HD)> ^ <Name Representation Code (ID)> ^ <Organization
3765 Identifier (ST)>
Subcomponents for Organization Name Type Code (CWE): <Identifier (ST)> & <Text (ST)>
& <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate
Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System
Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original
3770 Text (ST)> & <Second Alternate Identifier (ST)> & <Second Alternate Text
(ST)> & <Name of Second Alternate Coding System (ID)> & <Second Alternate
Coding System Version ID (ST)> & <Coding System OID (ST)> & <Value Set OID
(ST)> & <Value Set Version ID (DTM)> & <Alternate Coding System OID (ST)>
& <Alternate Value Set OID (ST)> & <Alternate Value Set Version ID (DTM)>
3775 & <Second Alternate Coding System OID (ST)> & <Second Alternate Value Set
OID (ST)> & <Second Alternate Value Set Version ID (DTM)>
Subcomponents for Assigning Authority (HD): <Namespace ID (CWE)> & <Universal ID
(ST)> & <Universal ID Type (ID)>

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 154 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Subcomponents for Namespace ID (CWE): <Identifier (ST)> & <Text (ST)> & <Name of
3780 Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)>
& <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)>
& <Alternate Coding System Version ID (ST)> & <Original Text (ST)> &
<Second Alternate Identifier (ST)> & <Second Alternate Text (ST)> & <Name
of Second Alternate Coding System (ID)> & <Second Alternate Coding System
3785 Version ID (ST)> & <Coding System OID (ST)> & <Value Set OID (ST)> &
<Value Set Version ID (DTM)> & <Alternate Coding System OID (ST)> &
<Alternate Value Set OID (ST)> & <Alternate Value Set Version ID (DTM)> &
<Second Alternate Coding System OID (ST)> & <Second Alternate Value Set
OID (ST)> & <Second Alternate Value Set Version ID (DTM)>
3790 Subcomponents for Assigning Facility (HD): <Namespace ID (CWE)> & <Universal ID (ST)>
& <Universal ID Type (ID)>
Subcomponents for Namespace ID (CWE): <Identifier (ST)> & <Text (ST)> & <Name of
Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)>
& <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)>
3795 & <Alternate Coding System Version ID (ST)> & <Original Text (ST)> &
<Second Alternate Identifier (ST)> & <Second Alternate Text (ST)> & <Name
of Second Alternate Coding System (ID)> & <Second Alternate Coding System
Version ID (ST)> & <Coding System OID (ST)> & <Value Set OID (ST)> &
<Value Set Version ID (DTM)> & <Alternate Coding System OID (ST)> &
3800 <Alternate Value Set OID (ST)> & <Alternate Value Set Version ID (DTM)> &
<Second Alternate Coding System OID (ST)> & <Second Alternate Value Set
OID (ST)> & <Second Alternate Value Set Version ID (DTM)>

Definition: The organization that is involved in the participation. If PRT-5 Participation

Person is valued, it reflects the affiliation of the individual participating as identified in
3805 PRT-4 Participation. Otherwise, the organization is directly participating as identified in
PRT-4 Participation.
If this attribute repeats, all instances must represent the same organization.
Condition: At least one of the Participation Person, Participation Organization,
Participation Location, or Participation Device fields must be valued.
3810 For the Report Alert Status [PCD-05] transaction this field is not populated.
PRT-9 Participation Location (PL) 02386
Components:<Point of Care (HD)> ^ <Room (HD)> ^ <Bed (HD)> ^ <Facility (HD)> ^
<Location Status (IS)> ^ <Person Location Type (IS)> ^ <Building (HD)> ^
<Floor (HD)> ^ <Location Description (ST)> ^ <Comprehensive Location
3815 Identifier (EI)> ^ <Assigning Authority for Location (HD)>
Subcomponents for Point of Care (HD): <Namespace ID (CWE)> & <Universal ID (ST)> &
<Universal ID Type (ID)>
Subcomponents for Namespace ID (CWE): <Identifier (ST)> & <Text (ST)> & <Name of
Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)>
3820 & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)>
& <Alternate Coding System Version ID (ST)> & <Original Text (ST)> &
<Second Alternate Identifier (ST)> & <Second Alternate Text (ST)> & <Name
of Second Alternate Coding System (ID)> & <Second Alternate Coding System
Version ID (ST)> & <Coding System OID (ST)> & <Value Set OID (ST)> &
3825 <Value Set Version ID (DTM)> & <Alternate Coding System OID (ST)> &
<Alternate Value Set OID (ST)> & <Alternate Value Set Version ID (DTM)> &
<Second Alternate Coding System OID (ST)> & <Second Alternate Value Set
OID (ST)> & <Second Alternate Value Set Version ID (DTM)>
Subcomponents for Room (HD): <Namespace ID (CWE)> & <Universal ID (ST)> & <Universal
3830 ID Type (ID)>
Subcomponents for Namespace ID (CWE): <Identifier (ST)> & <Text (ST)> & <Name of
Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)>
& <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)>

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 155 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

& <Alternate Coding System Version ID (ST)> & <Original Text (ST)> &
3835 <Second Alternate Identifier (ST)> & <Second Alternate Text (ST)> & <Name
of Second Alternate Coding System (ID)> & <Second Alternate Coding System
Version ID (ST)> & <Coding System OID (ST)> & <Value Set OID (ST)> &
<Value Set Version ID (DTM)> & <Alternate Coding System OID (ST)> &
<Alternate Value Set OID (ST)> & <Alternate Value Set Version ID (DTM)> &
3840 <Second Alternate Coding System OID (ST)> & <Second Alternate Value Set
OID (ST)> & <Second Alternate Value Set Version ID (DTM)>
Subcomponents for Bed (HD): <Namespace ID (CWE)> & <Universal ID (ST)> & <Universal
ID Type (ID)>
Subcomponents for Namespace ID (CWE): <Identifier (ST)> & <Text (ST)> & <Name of
3845 Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)>
& <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)>
& <Alternate Coding System Version ID (ST)> & <Original Text (ST)> &
<Second Alternate Identifier (ST)> & <Second Alternate Text (ST)> & <Name
of Second Alternate Coding System (ID)> & <Second Alternate Coding System
3850 Version ID (ST)> & <Coding System OID (ST)> & <Value Set OID (ST)> &
<Value Set Version ID (DTM)> & <Alternate Coding System OID (ST)> &
<Alternate Value Set OID (ST)> & <Alternate Value Set Version ID (DTM)> &
<Second Alternate Coding System OID (ST)> & <Second Alternate Value Set
OID (ST)> & <Second Alternate Value Set Version ID (DTM)>
3855 Subcomponents for Facility (HD): <Namespace ID (CWE)> & <Universal ID (ST)> &
<Universal ID Type (ID)>
Subcomponents for Namespace ID (CWE): <Identifier (ST)> & <Text (ST)> & <Name of
Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)>
& <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)>
3860 & <Alternate Coding System Version ID (ST)> & <Original Text (ST)> &
<Second Alternate Identifier (ST)> & <Second Alternate Text (ST)> & <Name
of Second Alternate Coding System (ID)> & <Second Alternate Coding System
Version ID (ST)> & <Coding System OID (ST)> & <Value Set OID (ST)> &
<Value Set Version ID (DTM)> & <Alternate Coding System OID (ST)> &
3865 <Alternate Value Set OID (ST)> & <Alternate Value Set Version ID (DTM)> &
<Second Alternate Coding System OID (ST)> & <Second Alternate Value Set
OID (ST)> & <Second Alternate Value Set Version ID (DTM)>
Subcomponents for Building (HD): <Namespace ID (CWE)> & <Universal ID (ST)> &
<Universal ID Type (ID)>
3870 Subcomponents for Namespace ID (CWE): <Identifier (ST)> & <Text (ST)> & <Name of
Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)>
& <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)>
& <Alternate Coding System Version ID (ST)> & <Original Text (ST)> &
<Second Alternate Identifier (ST)> & <Second Alternate Text (ST)> & <Name
3875 of Second Alternate Coding System (ID)> & <Second Alternate Coding System
Version ID (ST)> & <Coding System OID (ST)> & <Value Set OID (ST)> &
<Value Set Version ID (DTM)> & <Alternate Coding System OID (ST)> &
<Alternate Value Set OID (ST)> & <Alternate Value Set Version ID (DTM)> &
<Second Alternate Coding System OID (ST)> & <Second Alternate Value Set
3880 OID (ST)> & <Second Alternate Value Set Version ID (DTM)>
Subcomponents for Floor (HD): <Namespace ID (CWE)> & <Universal ID (ST)> & <Universal
ID Type (ID)>
Subcomponents for Namespace ID (CWE): <Identifier (ST)> & <Text (ST)> & <Name of
Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)>
3885 & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)>
& <Alternate Coding System Version ID (ST)> & <Original Text (ST)> &
<Second Alternate Identifier (ST)> & <Second Alternate Text (ST)> & <Name
of Second Alternate Coding System (ID)> & <Second Alternate Coding System
Version ID (ST)> & <Coding System OID (ST)> & <Value Set OID (ST)> &
3890 <Value Set Version ID (DTM)> & <Alternate Coding System OID (ST)> &
<Alternate Value Set OID (ST)> & <Alternate Value Set Version ID (DTM)> &
<Second Alternate Coding System OID (ST)> & <Second Alternate Value Set
OID (ST)> & <Second Alternate Value Set Version ID (DTM)>
Subcomponents for Comprehensive Location Identifier (EI): <Entity Identifier (ST)> &
3895 <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 156 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Subcomponents for Assigning Authority for Location (HD): <Namespace ID (CWE)> &
<Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Namespace ID (CWE): <Identifier (ST)> & <Text (ST)> & <Name of
Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)>
3900 & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)>
& <Alternate Coding System Version ID (ST)> & <Original Text (ST)> &
<Second Alternate Identifier (ST)> & <Second Alternate Text (ST)> & <Name
of Second Alternate Coding System (ID)> & <Second Alternate Coding System
Version ID (ST)> & <Coding System OID (ST)> & <Value Set OID (ST)> &
3905 <Value Set Version ID (DTM)> & <Alternate Coding System OID (ST)> &
<Alternate Value Set OID (ST)> & <Alternate Value Set Version ID (DTM)> &
<Second Alternate Coding System OID (ST)> & <Second Alternate Value Set
OID (ST)> & <Second Alternate Value Set Version ID (DTM)>

Definition: This field specifies the physical location (e.g., nurse station, ancillary service
3910 location, clinic, or floor) that is participating. If either PRT-5 Participation Person or
PRT-8 Participation Organization is valued, it reflects the location of the individual or
organization participating as identified in PRT-4 Participation. Otherwise, the location is
directly participating as identified in PRT-4 Participation.
If this attribute repeats, all instances must represent the same organization.
3915 Condition: At least one of the Participation Person, Participation Organization,
Participation Location, or Participation Device fields must be valued.
For the Report Alert Status [PCD-05] transaction this field is optional.
PRT-10 Participation Device (EI) 02348
Components:<Entity Identifier (ST)> ^ <Namespace ID (IS)> ^ <Universal ID (ST)> ^
3920 <Universal ID Type (ID)>

Definition: Identifier for the device participating. This may reflect an unstructured or a
structured identifier such as FDA UDI, RFID, IEEE EUI-64 identifiers, or bar codes.
If this attribute repeats, all instances must represent the same device.
Condition: At least one of the Participation Person, Participation Organization,
3925 Participation Location, or Participation Device fields must be valued.
For the Report Alert Status [PCD-05] transaction the Entity Identifier is the PIN/Carrier
or device communication ID and namespace ID is the Alert Communicator (AC) or Alert
Manager (AM) ID.
Future implementation notes: as of HL7 V2.7, identifying devices in the OBX-18 field of
3930 the OBX segment is retained for backward compatibility only. This field will be
represented through the PRT segment. Future versions of the IHE PCD Technical
Framework will require the use of this segment, which will also provide for including the
Unique Device Identification adopted by the U.S. F.D.A. and being considered by
regulatory agencies in other jurisdictions.
3935 If this field contains an FDA UDI, it shall contain the entire Human Readable Form of
the UDI. For example, a GS1-based UDI would be represented as follows:
|(01)00643169001763(17)160712(21)21A11F4855^^2.16.840.1.113883.3.3719^ISO|
A HIBCC-based example would be represented as follows:

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 157 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

|+H123PARTNO1234567890120/$$420020216LOT123456789012345/SXYZ45678901
3940 23 45678/16D20130202C^^2.16.840.1.113883.3.3719^ISO
An ICCBBA-based example would be represented as follows:
|=/A9999XYZ100T0944=,000025=A99971312345600=>014032=}013032\T\,10000000
00000XYZ123^^2.16.840.1.113883.3.3719^ISO|
Or for ICCBBA for blood bags only an example would be represented as follows:
3945 |=)1TE123456A\T\)RZ12345678^^2.16.840.1.113883.3.3719^ISO|
The identifier root shall be the OID assigned to UDI. For example, for FDA UDIs the
root shall be 2.16.840.1.113883.3.3719, and the extension shall be the Human Readable
Form appropriate for the style of content. When captured as a simple string, the string
shall be the Human Readable Form appropriate for the style of content. The content style
3950 can be determined from the leading characters of the content:
UDIs beginning with:
‘(‘ are in the GS1 Human Readable style;
‘0-9’ are a GS1 DI (containing only the DI value, no PI or GS1 AI);
‘+‘ are in the HIBCC Human Readable style;
3955 ‘=‘ or ‘&’ are in the ICCBBA Human Readable style.
Note: If “&” is used in the UDI while one of the delimiters in MSH.2 includes “&” as
well, it must be properly escaped per Chapter 2.7.
The exchange of UDI sub-elements in PRT-16 through PRT-21 is not required when the
full UDI string is provided in PRT.10. Whether to include some or all these fields as well
3960 when PRT-10 is present with a UDI that the rules are subject to specific implementation
guides that will have to consider the patient safety implications of potentially conflicting
data.
When a UDI is provided and sub-elements are also provided, then for those sub-elements
that are valued, the content must match the content encoded in the UDI if it is encoded
3965 within the UDI.
Caution: The UDI may contain personally identifying information in the form of the
device serial number which may be used to link to other information on a patient.
Standard practice for exchanging potentially identifying content should be exercised
when exchanging UDIs which contain a serial number.
3970 Note: PRT.10 is a repeating field. Additional device identifiers, such as an IEEE EUI-64
may also be contained in this field.
PRT-11 Participation Begin Date/Time (DTM) 02387
Definition: This field contains the date/time when the participation began.
In the case of waypoints, this reflects the time a shipment arrives at the waypoint.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 158 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

3975 For the Report Alert Status [PCD-05] transaction this field contains the time of the
dissemination status or response update.
PRT-12 Participation End Date/Time (DTM) 02388
Definition: This field contains the date/time when the participation ended.
In the case of waypoints, this reflects the time a shipment departs from the waypoint.
3980 For the Report Alert Status [PCD-05] transaction this field is not populated.
PRT-13 Participation Qualitative Duration (CWE) 02389
Components:<Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate
Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding
System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System
3985 Version ID (ST)> ^ <Original Text (ST)> ^ <Second Alternate Identifier
(ST)> ^ <Second Alternate Text (ST)> ^ <Name of Second Alternate Coding
System (ID)> ^ <Second Alternate Coding System Version ID (ST)> ^ <Coding
System OID (ST)> ^ <Value Set OID (ST)> ^ <Value Set Version ID (DTM)> ^
<Alternate Coding System OID (ST)> ^ <Alternate Value Set OID (ST)> ^
3990 <Alternate Value Set Version ID (DTM)> ^ <Second Alternate Coding System
OID (ST)> ^ <Second Alternate Value Set OID (ST)> ^ <Second Alternate
Value Set Version ID (DTM)>

Definition: This field contains the qualitative length of time for participation (e.g., until
the next assessment, four days, until discharge, etc.).
3995 For the Report Alert Status [PCD-05] transaction this field is not populated.
PRT-14 Participation Address (XAD) 02390
Components:<Street Address (SAD)> ^ <Other Designation (ST)> ^ <City (ST)> ^ <State or
Province (ST)> ^ <Zip or Postal Code (ST)> ^ <Country (ID)> ^ <Address
Type (ID)> ^ <Other Geographic Designation (ST)> ^ <County/Parish Code
4000 (CWE)> ^ <Census Tract (CWE)> ^ <Address Representation Code (ID)> ^
<WITHDRAWN Constituent> ^ <Effective Date (DTM)> ^ <Expiration Date (DTM)>
^ <Expiration Reason (CWE)> ^ <Temporary Indicator (ID)> ^ <Bad Address
Indicator (ID)> ^ <Address Usage (ID)> ^ <Addressee (ST)> ^ <Comment (ST)>
^ <Preference Order (NM)> ^ <Protection Code (CWE)> ^ <Address Identifier
4005 (EI)>
Subcomponents for Street Address (SAD): <Street or Mailing Address (ST)> & <Street
Name (ST)> & <Dwelling Number (ST)>
Subcomponents for County/Parish Code (CWE): <Identifier (ST)> & <Text (ST)> & <Name
of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text
4010 (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID
(ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)> &
<Second Alternate Identifier (ST)> & <Second Alternate Text (ST)> & <Name
of Second Alternate Coding System (ID)> & <Second Alternate Coding System
Version ID (ST)> & <Coding System OID (ST)> & <Value Set OID (ST)> &
4015 <Value Set Version ID (DTM)> & <Alternate Coding System OID (ST)> &
<Alternate Value Set OID (ST)> & <Alternate Value Set Version ID (DTM)> &
<Second Alternate Coding System OID (ST)> & <Second Alternate Value Set
OID (ST)> & <Second Alternate Value Set Version ID (DTM)>
Subcomponents for Census Tract (CWE): <Identifier (ST)> & <Text (ST)> & <Name of
4020 Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)>
& <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)>
& <Alternate Coding System Version ID (ST)> & <Original Text (ST)> &
<Second Alternate Identifier (ST)> & <Second Alternate Text (ST)> & <Name
of Second Alternate Coding System (ID)> & <Second Alternate Coding System
4025 Version ID (ST)> & <Coding System OID (ST)> & <Value Set OID (ST)> &
<Value Set Version ID (DTM)> & <Alternate Coding System OID (ST)> &
<Alternate Value Set OID (ST)> & <Alternate Value Set Version ID (DTM)> &

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 159 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

<Second Alternate Coding System OID (ST)> & <Second Alternate Value Set
OID (ST)> & <Second Alternate Value Set Version ID (DTM)>
4030 Subcomponents for Expiration Reason (CWE): <Identifier (ST)> & <Text (ST)> & <Name of
Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)>
& <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)>
& <Alternate Coding System Version ID (ST)> & <Original Text (ST)> &
<Second Alternate Identifier (ST)> & <Second Alternate Text (ST)> & <Name
4035 of Second Alternate Coding System (ID)> & <Second Alternate Coding System
Version ID (ST)> & <Coding System OID (ST)> & <Value Set OID (ST)> &
<Value Set Version ID (DTM)> & <Alternate Coding System OID (ST)> &
<Alternate Value Set OID (ST)> & <Alternate Value Set Version ID (DTM)> &
<Second Alternate Coding System OID (ST)> & <Second Alternate Value Set
4040 OID (ST)> & <Second Alternate Value Set Version ID (DTM)>
Subcomponents for Protection Code (CWE): <Identifier (ST)> & <Text (ST)> & <Name of
Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)>
& <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)>
& <Alternate Coding System Version ID (ST)> & <Original Text (ST)> &
4045 <Second Alternate Identifier (ST)> & <Second Alternate Text (ST)> & <Name
of Second Alternate Coding System (ID)> & <Second Alternate Coding System
Version ID (ST)> & <Coding System OID (ST)> & <Value Set OID (ST)> &
<Value Set Version ID (DTM)> & <Alternate Coding System OID (ST)> &
<Alternate Value Set OID (ST)> & <Alternate Value Set Version ID (DTM)> &
4050 <Second Alternate Coding System OID (ST)> & <Second Alternate Value Set
OID (ST)> & <Second Alternate Value Set Version ID (DTM)>
Subcomponents for Address Identifier (EI): <Entity Identifier (ST)> & <Namespace ID
(IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Definition: This field contains addresses associated with the participation. The address
4055 can repeat to indicate alternate addresses or an alternate expression of the same address.
Condition: The address must be present if the Participation is Performing Organization
Medical Director.
For the Report Alert Status [PCD-05] transaction this field is not populated.
PRT-15 Participation Telecommunication Address (XTN) 02391
4060 Components:<WITHDRAWN Constituent> ^ <Telecommunication Use Code (ID)> ^
<Telecommunication Equipment Type (ID)> ^ <Communication Address (ST)> ^
<Country Code (SNM)> ^ <Area/City Code (SNM)> ^ <Local Number (SNM)> ^
<Extension (SNM)> ^ <Any Text (ST)> ^ <Extension Prefix (ST)> ^ <Speed
Dial Code (ST)> ^ <Unformatted Telephone number (ST)> ^ <Effective Start
4065 Date (DTM)> ^ <Expiration Date (DTM)> ^ <Expiration Reason (CWE)> ^
<Protection Code (CWE)> ^ <Shared Telecommunication Identifier (EI)> ^
<Preference Order (NM)>
Subcomponents for Expiration Reason (CWE): <Identifier (ST)> & <Text (ST)> & <Name of
Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)>
4070 & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)>
& <Alternate Coding System Version ID (ST)> & <Original Text (ST)> &
<Second Alternate Identifier (ST)> & <Second Alternate Text (ST)> & <Name
of Second Alternate Coding System (ID)> & <Second Alternate Coding System
Version ID (ST)> & <Coding System OID (ST)> & <Value Set OID (ST)> &
4075 <Value Set Version ID (DTM)> & <Alternate Coding System OID (ST)> &
<Alternate Value Set OID (ST)> & <Alternate Value Set Version ID (DTM)> &
<Second Alternate Coding System OID (ST)> & <Second Alternate Value Set
OID (ST)> & <Second Alternate Value Set Version ID (DTM)>
Subcomponents for Protection Code (CWE): <Identifier (ST)> & <Text (ST)> & <Name of
4080 Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)>
& <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)>
& <Alternate Coding System Version ID (ST)> & <Original Text (ST)> &
<Second Alternate Identifier (ST)> & <Second Alternate Text (ST)> & <Name
of Second Alternate Coding System (ID)> & <Second Alternate Coding System
4085 Version ID (ST)> & <Coding System OID (ST)> & <Value Set OID (ST)> &

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 160 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

<Value Set Version ID (DTM)> & <Alternate Coding System OID (ST)> &
<Alternate Value Set OID (ST)> & <Alternate Value Set Version ID (DTM)> &
<Second Alternate Coding System OID (ST)> & <Second Alternate Value Set
OID (ST)> & <Second Alternate Value Set Version ID (DTM)>
4090 Subcomponents for Shared Telecommunication Identifier (EI): <Entity Identifier (ST)>
& <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Definition: The waypoint telecommunication address field carries telecommunications

addresses for the waypoint. These telecommunications addresses are used to contact the
waypoint for additional information regarding the receipt of the shipment. The address
4095 can repeat to indicate alternate addresses or an alternate expression of the same address.
For the Report Alert [PCD-04] transaction this field may also be used if only a
PIN/Carrier destination is known, in which case the PIN is in the first sub-component of
the Communication Address component and the Carrier is in the second sub-component
of the Communication Address component.
4100 For the Report Alert Status [PCD-05] transaction, if the PIN/Carrier of the recipient is
known then this would contain that information just as it is passed in Report Alert [PCD-
04] so that the Alert Reporter could use this information to contact the recipient.
PRT-16 Participation Device Identifier (EI) 03476
Components: <Entity Identifier (ST)> ^ <Namespace ID (IS)> ^ <Universal ID (ST)> ^
4105 <Universal ID Type (ID)>
Definition: Provides the U.S. FDA UDI device identifier (DI) element.
This is the first component in the UDI and acts as the look up key for the Global Unique
Device Identification Database (GUDID ), and may be used for retrieving additional
attributes.
4110 When exchanging Device Identifiers (DI) the root shall be the OID, or standards’
appropriate corollary to the OID, assigned to DI and the extension shall be the Human
Readable Form of the content. For example, for DIs the root shall be:
GS1 DIs: 2.51.1.1
HIBCC DIs: 1.0.15961.10.816
4115 ICCBBA DIs: 2.16.840.1.113883.6.18.1.17 for Blood containers and
2.16.840.1.113883.6.18.1.34 otherwise.
Example: |00643169001763^^2.51.1.1^ISO|
PRT-17 Participation Device Manufacture Date (DTM) 03477
Definition: Date and time when the device was manufactured.
4120 Note: The user system may need to convert the date and optional hour from the UDI
Human Readable Form to a timestamp style data type, augmenting the date as required to
provide for a complete date and optionally the hour.
Example: |20140401|

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 161 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

PRT-18 Participation Device Expiry Date (DTM) 03478

4125 Definition: Date and time when the device is no longer approved for use. Not generally
applicable in IHE PCD transactions.
Note: The user system may need to convert the date and optional hour from the UDI
Human Readable Form to a timestamp style data type, augmenting the date as required to
provide for a complete date and optionally the hour.
4130 Example: |20160712|
PRT-19 Participation Device Lot Number (ST) 03479
Definition: Alphanumeric string that identifies the device’s production lot number.
Example: |123ABC|
PRT-20 Participation Device Serial Number (ST) 03480
4135 Definition: Manufacturer’s serial number for this device.
CAUTION: See the related privacy considerations discussion in PRT.10.
Example: |21A11F4855|

B.10.3 PRT Participation Information Segment in ACM Transactions [PCD-04] and

[PCD-05]
4140 A Report Alert [PCD-04] transaction can optionally contain multiple occurrences of the
Participation Information (PRT) segment to indicate additional alert notification recipients in
addition to any alert notification recipients identified internally by the Alert Manager (AM).
A Report Alert Status [PCD-05] transaction can contain multiple occurrences of the Participation
Information (PRT) segment to indicate the recipient person and/or endpoint communication
4145 device to which an alert was disseminated (successfully or unsuccessfully) and the endpoint
communication device operator response. PRT segment optionality and repeat indications are
specific to the PCD-04 and PCD-05 messages. There is one recipient person or device per PRT
segment occurrence. The group of PRT segments optionally identifying the additional recipients
is in the PCD-04 or PCD-05 message occur after the OBR segment identifying the alert or alert
4150 status and before any OBX observation segments associated with the alert in the case of the
[PCD-04] transaction.
The content of a PRT segment shall resolve to an unambiguous single recipient, be it an
identified person in PRT-5 or a communication endpoint device destination identified by its
telecommunication address in PRT-15. In the case of [PCD-04] if both PRT-5 and PRT-15 are
4155 populated the Alert Manager may send the alert notification to additional endpoint
communication devices associated with the person identified in PRT-5. In the case of [PCD-05]
if both PRT-5 and PRT-15 are populated the focus shall be on PRT-5 as the person to which the
alert was addressed and the value in PRT-15 is additional information for retrospective analysis
indicating the endpoint communication device on which they successfully or unsuccessfully
4160 received or responded to the alert notification. If the person received or responded to the alert on
multiple endpoint communication devices that shall result in multiple PCD-05 messages rather
______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 162 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

than waiting to queue up multiple PRT segments into a single [PCD-05] transaction which might
delay providing alert status back to the Alert Reporter.
PRT-2 Action Code (ID) 00816
4165 For the PCD-04 and PCD-05 message this field shall contain the value AD indicating Add.
PRT-3 Action Reason (CWE) 02380
For the PCD-04 message this field is optional.
PRT-4 Participation (CWE) 02381
For [PCD-04] and [PCD-05] this field shall contain AR indicating Alert Recipient. This is an
4170 addition to HL7 v2.8 Table 0912 specifically for the PCD-04 message such that PRT segment
occurrences identifying alert recipients can be unambiguously identified for processing,
independent of unrelated to alert processing PRT segments containing RCT (indicating Result
Copies To).
PRT-5 Participation Person (XCN) 02382
4175 This is the identification of the person that is the recipient of the alert notification. If this field is
populated it shall unambiguously resolve to one person. If this field is populated and PRT-15 is
not populated it presumes the Alert Manager will (in the case of [PCD-04]) or has (in the case of
[PCD-05]) internally resolved the person to one or more of their currently assigned endpoint
communication devices.
4180 PRT-11 Participation Begin Date/Time (DTM) 02387
For the PCD-05 message this field contains the timestamp of the message dissemination status or
operator response.
PRT-15 Participation Telecommunication Address (XTN) 02391
This field optionally contains the telecommunication identification of the alert notification
4185 recipient’s telecommunication device (phone #, carrier and PIN, etc.). If this field is populated it
shall unambiguously resolve to one endpoint communication device. If this field is not populated
then PRT-5 Participation Person shall be populated and it is presumed the Alert Manager will
internally resolve the person to their currently assigned endpoint communication device or
devices.
4190 If the field value represents a telecommunications carrier identification and PIN reference the
carrier identification string goes in the fourth component Communication Address and the PIN
string goes in the seventh component Local Number. If the field value represents a telephony dial
string it can either be split into its XTN data type components or it can be a dial string in the
twelfth component Unformatted Telephone number.
4195 In the case of an outsourced Alert Communicator as a notification service (answering machine
service, help desk, etc.) the telecommunication carrier identification and PIN reference may not
be known by the Alert Manager in which case this field might not be populated.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 163 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Appendix C Common Data Types

4200 This section describes PCD constraints of commonly used HL7 data types.
HL7 OBX-2 defines the Value Type that is used to express the value in OBX-5 based on HL7
Table 0125.
The PCD Technical Framework constrains the allowable value type to those shown in Table C-1.

Table C-1: PCD Constrained HL7 Table 0125

Value Description Comment
CNE Coded with No Exceptions
CWE Coded with Exceptions
CF Coded Element with Formatted Values
DR Date Range
DTM Date/Time
ED Encapsulated Data
FT Formatted Text
NA Numeric Array
NM Numeric
PN Person Name
SN Structured Numeric
ST String Data
TM Time
XCN Extended Composite Name and Number for
Persons
XPN Extended Person Name

4205

C.1 CNE Data Type – coded with no exceptions

Used when a field must represent a distinct value (a code) from a closed set of acceptable values,
where all the values must be drawn from code sets accepted by HL7, where the authority
determining acceptance is the HL7 Vocabulary Work Group.
4210 Definition: Specifies a coded element and its associated detail. The CNE data type is used when
a required or mandatory coded field is needed. The specified HL7 table or imported or externally
defined coding system must be used and may not be extended with local values.

Table C.1-1: CNE-Coded Element

SEQ LEN DT Usage Card. TBL# Component name
1 20 ST R [1..1] Identifier
2 199 ST R [1..1] Text
3 20 ID RE [0..1] 0396 Name of Coding System

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 164 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

SEQ LEN DT Usage Card. TBL# Component name

4 20 ST RE [0..1] Alternate Identifier
5 199 ST RE [0..1] Alternate Text
6 20 ID RE [0..1] 0396 Name of Alternate Coding System
7 10 ST C [0..1] Coding System Version ID
8 10 ST O [0..1] Alternate Coding System Version ID
9 199 ST O [0..1] Original Text

4215 C.2 CWE Data Type – coded with exceptions

Used when a field must represent a distinct value (a code) from a closed set of acceptable values,
but where some values may be drawn from outside code sets accepted by HL7. In IHE PCD, to
promote interoperability, where possible such values should be submitted to, and sanctioned by,
the IHE PCD Technical Committee before use.
4220 Definition: Specifies a coded element and its associated detail. The CWE data type is used when
1) more than one table may be applicable or 2) the specified HL7 or externally defined table may
be extended with local values. See HL7 v2.6 2.A.13 for details.
Note that this data type allows for a primary and an alternate coding system. This can be used to
identify coded values from two value sets, such as measurement identifiers for the same
4225 measurement from both the MDC (ISO/IEEE 11073) and SNOMED CT systems, or units of
measure from both MDC and UCUM systems.

Table C.2-1: CWE-Coded Element

SEQ LEN DT Usage Card. TBL# Component name
1 40 (See ST RE [0..1] Identifier
Note)
2 199 ST R [1..1] Text
3 20 ID RE [0..1] 0396 Name of Coding System
4 20 ST RE [0..1] Alternate Identifier
5 199 ST RE [0..1] Alternate Text
6 20 ID RE [0..1] 0396 Name of Alternate Coding System
7 10 ST C [0..1] Coding System Version ID
8 10 ST O [0..1] Alternate Coding System Version
ID
9 199 ST O [0..1] Original Text

Note: HL7 Ch. 2A calls for a length limit of 20 on component 1 of CWE, but some codes required in this Technical
Framework are longer, hence this deviation.

4230

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 165 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

C.3 CX Data Type

Table C.3-1: CX-Extended Composite ID with check digit

SEQ LEN DT Usage Card. TBL# Component name
1 15 ST R [1..1] ID Number
2 4 ST RE [0..1] Identifier Check Digit
3 3 ID RE [0..1] 0061 Check Digit Scheme
4 227 HD RE [0..1] 0363 Assigning Authority
5 5 ID RE [0..1] 0203 Identifier Type Code
6 227 HD RE [0..1] Assigning Facility
7 8 DT RE [0..1] Effective Date
8 8 DT RE [0..1] Expiration Date
9 705 CWE RE [0..1] Assigning Jurisdiction
10 705 CWE RE [0..1] Assigning Agency or Department

The constraints above particularly apply to the Patient Identifiers carried in the PID segment.
4235 In the context of this PCD Framework, the Assigning Authority and the Identifier Type Code are
considered to be important components for disambiguating identifiers, so these should be
included whenever they are known.
A common value of the Identifier Type Code for a Patient Identifier assigned by the healthcare
organization (PID-5) is "PI". Other values are defined in Table 0203 of HL7 2.6 section 2.A.14.5
4240 Example: 12345^^^Saint-John Hospital^PI

C.4 DTM – date/time

Table C.4-1: HL7 Component Table - DTM – Date/Time

SEQ LEN DT OPT TBL# COMPONENT COMMENTS SEC.REF.
NAME
24 Date/Time 2.A.22

HL7 Format: YYYY[MM[DD[HH[MM[SS[.S[S[S[S]]]]]]]]][+/-ZZZZ]

4245 The time zone (+/-ZZZZ) is represented as +/-HHMM offset from Coordinated Universal Time
(UTC). Note that while the general HL7 V2.6 definition does not require the time zone
indication to be present in all cases, in all IHE PCD profiles, the time zone is required.
The IHE PCD TF uses the IETF RFC3339 “Unknown Local Offset Convention” to make it
possible to distinguish between the case where UTC is the preferred reference point for the
4250 specified time, denoted with +0000, and the case where the UTC time is known, but the offset to
local time is unknown, denoted with -0000. This distinction is in some cases important to
represent in device data.
______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 166 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

C.5 Entity Identifier (EI) Data Type

Table C.5-1: EI-Entity Identifier

SEQ LEN DT Usage Card. TBL# Component name
1 199 ST RE [1..1] Entity Identifier
2 20 IS RE [0..1] 0363 Namespace ID
3 199 ST RE [0..1] Universal ID
4 6 ID RE [0..1] 0301 Universal ID Type

4255
Definition: The Entity Identifier defines a given entity uniquely within a specified series of
identifiers. A piece of equipment or an information system would be an example of an entity to
be uniquely identified. In addition to the unique identifier in the first component, called
somewhat confusingly by the same name as the data type itself, the Entity Identifier, the EI data
4260 type has 3 additional components that identify the ‘assigning authority’ that assigned the Entity
Identifier. These function quite similarly to the three components of the Hierarchical Designator
data type (see Appendix C.6, HD Data Type).
Identifiers do not serve their purpose if they cannot be used to distinguish unambiguously all of
the entities of a particular kind in the context in which they are applied. The HL7 specification
4265 discusses two kinds of identifiers: local and universal. Local identifiers only need to be unique
within a limited scope agreed to by the sending and receiving systems, say, a particular hospital.
The limitations of such a scheme are obvious: once you try to use such an identifier outside of its
scope, another identifier in the wider scope may conflict with it (if, say, Alice Hospital and Barry
Hospital merge and both have a monitor identified as "Monitor101").
4270 A sort of intermediate but still local kind of identifier supplements the Entity Identifier with a
Namespace ID. So the merged hospital could use a Namespace ID of "AH" for equipment names
created in Alice Hospital and "BH" for ones from Barry Hospital. But as you go to wider scopes,
such as a statewide reporting system, this intermediate system could still result in identifier
clashes.
4275 Universal identifiers avoid this problem by always including a unique identifier for the 'assigning
authority' that created and manages the Entity Identifier. A Universal ID system must have a
foolproof method for unambiguously identifying the 'assigning authority' over a 'universal' scope.
Just allowing every assigning authority to name itself can still lead to name clashes. But there are
a number of well-defined identifier systems that are designed to always yield unique identifiers.
4280 One that is familiar to programmers is the GUID, which gives a long hexadecimal number that
can be generated on any suitably programmed computer with virtual certainty that the same
number will not have been, and will not in the future be, generated by that computer or any other
computer. EUI-64, ISO OIDs and URIs identifiers are other identifier schemes also are created
according to well-defined rules such that each identifier system is intended to avoid applying the
4285 same identifier to the more than one entity no matter how wide the scope of applicability is.
In other contexts in PCD profiles, the ‘assigning authority’, as identified by Namespace ID (EI-
2), Universal ID (EI-3), and Universal ID type (EI-4) is required. Assigning authorities in PCD
______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 167 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

profiles may, depending on context and need, be standards development organizations,

manufacturers, software systems, or provider institutions. See the descriptions of particular fields
4290 with a data type of EI elsewhere in the Technical Framework.
Either Namespace ID (EI-2), giving a local identifier namespace, or (preferably) both Universal
ID (EI-3), and Universal ID type (EI-4) are required.
When only Namespace ID (EI-2) is valued, the identification of the assigning authority is only
local. Particularly when there are several concurrent assigning authorities within the healthcare
4295 enterprise, this Namespace ID will indicate which assigning authority provided the Entity
Identifier (EI-1).
In preference to such a local ID, IHE PCD strongly recommends a Universal ID. In such a
Universal ID, IHE PCD recommends that Namespace ID (EI-2) always be populated, but it is
optional when both Universal ID (EI-3), and Universal ID type (EI-4) are given. When EI-3 and
4300 EI-4 identify the manufacturer, EI-2 may be used for the model identification, to further qualify
the Entity Identifier (EI-1) which shall contain a unique identifier for the instance of the device,
either an EUI-64 (in which case EI-1 will duplicate the information in EI-3) or a manufacturer’s
serial number.
In IHE PCD, the order of preference for systems of Universal ID is: EUI-64, OID and URI. In
4305 addition to this order of preference, it is noted that any IHE PCD system running in a production
environment shall only use an EUI-64 Universal ID. Systems running in test environments or
certification environments are allowed to use an OID or URI Universal ID
Identifying with an EUI-64. Namespace ID (EI-2) is optional in this case and may contain a
locally unique name for the application implementing PCD actor(s). Universal ID (EI-3) contains
4310 the EUI-64 identifier as a hexadecimal string. The IEEE defined 64-bit extended unique
identifier (EUI-64) is a concatenation of the 24-bit company_id value assigned by the IEEE
Registration Authority, and a 40-bit extension identifier assigned by the organization having that
company_id assignment. The Universal ID Type (EI-4) contains the value EUI-64.
Identifying with an ISO OID. When an ISO OID is used, "Namespace ID" (EI-2) contains
4315 either a local name of the assigning authority or the device model number when a patient care
device is being identified, "Universal ID" (EI-3) contains its universal OID, and "Universal ID
Type" (EI-4) containing the value ISO.
Identifying with a URI. The Universal Resource Identifier, defined in IETF RFC3306,
encompasses the familiar Uniform Resource Locator (the URL “internet address” of a website,
4320 for example), and the Universal Resource Name, which need not identify a web resource but
uniquely identifies an entity according to a number of unique identifier schemes, including some
of the others listed, such as ISO OIDs (which can be made into URIs simply by prefixing the
OID string with “urn:oid:”). The URI is placed in the Universal ID (EI-3) component and the
Universal ID type (EI-4) is "URN".
4325 When identifying a piece of equipment, an EUI-64 has the advantage of being inherently unique
to the piece of equipment, and containing the identity of the manufacturer.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 168 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Refer to discussion and examples of the use of Entity Identifiers to identify equipment sourcing
medical device data in the description of HL7 field OBX-18 in Appendix B.8.
IHE PCD constrains the length of the first component to 20 characters. National extensions can
4330 extend this length up to a maximum of 199.

C.6 Hierarchic Designator (HD) Data Type

Definition: The basic definition of the HD is that it identifies an (administrative or system or
application or other) entity that has responsibility for managing or assigning a defined set of
instance identifiers (such as placer or filler number, patient identifiers, provider identifiers, etc.).
4335 This entity could be a particular health care application such as a registration system that assigns
patient identifiers, a governmental entity such as a licensing authority that assigns professional
identifiers or drivers’ license numbers, or a facility where such identifiers are assigned.
In the context of IHE PCD profiles, the HD data type appears directly as the data type for
sending and receiving applications, and sending and receiving facilities, in the MSH segment
4340 (MSH fields MSH-3, MSH-4, MSH-5, and MSH-6).
The Hierarchic Designator (HD) data type also essentially forms part of the Entity Identifier (EI)
data type which has other important roles in IHE PCD profile such as giving a placer or filler
order number in OBR. The EI data type is made up of an Entity Identifier component (EI-1), plus
additional components in the same form as the HD data type (EI-2 Namespace ID, corresponding
4345 to HD-1, EI-3 Universal ID corresponding to HD-2, and EI-4 Universal ID Type corresponding
to HD-3). These additional components serve to identify the 'assigning authority' that is the
source of the Entity Identifier. The EI data type is important in this Technical Framework for
combining an identification of a particular entity (such as an information system) with the
identification of the 'assigning authority' which assigned that particular identifier. See Appendix
4350 Section C.5 for details of this usage.

Table C.6-1: HD-Hierarchic designator

SEQ LEN DT Usage Card. TBL# Component name
1 20 IS RE [0..1] 0300 Namespace ID
2 999 ST RE [0..1] Universal ID
3 6 ID RE [0..1] 0301 Universal ID Type

The Namespace ID (HD-1) in HL7 in general may be populated with a strictly local identifier,
which only needs to be understood in the same way by the individual sending and receiving
4355 applications. Where it is possible, IHE PCD discourages the use of such local identifiers and
instead encourages the use of "Universal" types of identifier, specified by Universal ID and
Universal ID Type, which carry a semantic context that can be understood widely in a context
not limited to a single institution, with no risk of conflicting duplicate identifiers if the Universal
ID system is used properly. The Universal ID (HD-2) should be a well-formed identifier
4360 according to a generally recognized system of identification such as the IEEE EUI-64 for

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 169 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

hardware or software systems, or an ISO OID. The Universal ID type (HD-3) specifies which
Universal ID system the Universal ID (HD-2) is drawn from.
The PCD TF requires that a field of Data Type HD be populated with:
• Either "Namespace ID" (HD-1) alone, which in this case contains a local identifier of the
4365 assigning entity.
• Or, preferably, with a recognized system of Universal IDs such as an EUI-64 or an ISO
OID as Universal IDs. See the discussion under EI data type, Appendix Section C.5 for
the application of Universal ID systems in IHE PCD profiles (note that the component
names Namespace ID, Universal ID, and Universal ID Type are the same in HD and EI
4370 data types, but since the EI data type has an extra component, Entity Identifier, at the
beginning, the component numbers are not the same between HD and EI).

C.7 PL Data Type

Table C.7-1: PL-Person Location

SEQ LEN DT Usage Card. TBL# Component name
1 20 IS RE [0..1] 0302 Point of Care
2 20 IS RE [0..1] 0303 Room
3 20 IS RE [0..1] 0304 Bed
4 227 HD RE [0..1] Facility
5 20 IS RE [0..1] 0306 Location Status
6 20 IS CE [0..1] 0305 Person Location Type
7 20 IS RE [0..1] 0307 Building
8 20 IS RE [0..1] 0308 Floor
9 199 ST RE [0..1] Location Description
10 427 EI RE [0..1] Comprehensive Location Identifier
11 227 HD RE [0..1] Assigning Authority for Location

4375 IHE PCD Definition: This data type is used to specify a patient location within a healthcare
institution, or other setting where healthcare is provided. Which components are valued depends
on the needs of the site. For example, for a patient treated at home, only the person location type
is valued.
Component 1: Point of Care (IS), required but may be empty:
4380 HL7 definition: This component specifies the code for the point where patient care is
administered. It is related to PL.6 Person Location Type (e.g., nursing unit or department
or clinic). After floor, it is the most general patient location designation.
HL7 user-defined table 0302 does not suggest any values. The codification of points of
care will be defined at the site level in acute care settings.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 170 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

4385 Component 2: Room (IS), required but may be empty:

HL7 definition: This component specifies the code for the patient's room. After point of
care, it is the most general person location designation.
HL7 user-defined table 0303 does not suggest any values. The codification of rooms shall
be defined at the site level in acute care settings.
4390 Component 3: Bed (IS), required but may be empty:
HL7 definition: This component specifies the code for the patient's bed. After room, it is
the most general person location designation.
HL7 user-defined table 0304 does not suggest any values. The codification of beds shall
be defined at the site level in acute care settings.
4395 Component 4: Facility (HD), required but may be empty:
HL7 definition: This component is subject to site interpretation but generally describes
the highest level physical designation of an institution, medical center or enterprise. It is
the most general person location designation.
The codification of facilities shall be defined at the highest level, according to the context
4400 of use of the PCD profile (acute care setting, ambulatory domain, etc.).
Component 6: Person Location Type (IS), conditional but may be empty:
IHE PCD condition: PL.6 is only populated if none of the other components of the PL
data type are populated.
HL7 definition: Person location type is the categorization of the person’s location defined
4405 by facility, building, floor, point of care, room or bed. Although not a required field,
when used, it may be the only populated field. It usually includes values such as nursing
unit, department, clinic, SNF, physician’s office. Refer to HL7 User-defined Table 0305 -
Person location type for suggested values.

Table C.7-2: HL7 User-defined Table 0305 - Person Location Type

Value Description Comment
C Clinic
D Department
H Home
N Nursing Unit
O Provider’s Office
P Phone
S SNF

4410 National extensions of this profile may further constrain on extend this table.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 171 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Component 7: Building (IS), required but may be empty:

HL7 definition: This component specifies the code for the building where the person is
located. After facility, it is the most general person location designation.
HL7 user-defined table 0307 does not suggest any values. The codification of buildings
4415 shall be defined at the site level in acute care settings.
Component 8: Floor (IS), required but may be empty:
HL7 definition: This component specifies the code for the floor where the person is
located. After building, it is the most general person location designation.
HL7 user-defined table 308 does not suggest any values. The codification of floors shall
4420 be defined at the site level in acute care settings.
Component 9: Location description (ST), required but may be empty:
HL7 definition: This component describes the location in free text.
Component 10: Comprehensive Location Identifier (EI), required but may be empty:
HL7 definition: The unique identifier that represents the physical location as a whole
4425 without regard for the individual components. This accommodates sites that may have a
different method of defining physical units or who may code at a less granular level. For
example, point of care, room, and bed may be 1 indivisible code.
Component 11: Assigning Authority for Location (HD), required but may be empty:
HL7 definition: The entity that creates the data for the individual physical location
4430 components. If populated, it should be the authority for all components populated. Refer
to HL7 User-defined Table 0363 - Assigning authority for suggested values for the first
sub-component of the HD component, <namespace ID>.
By site agreement, implementers may continue to use HL7 User-defined Table 0300 -
Namespace ID for the first sub-component.

4435 C.8 XPN Data Type

Table C.8-1: XPN-Extended Person Name

SEQ LEN DT Usage Card. TBL# Component name
1 194 FN RE [0..1] Family Name
2 30 ST RE [0..1] Given Name
3 30 ST RE [0..1] Second and Further Given Names
or Initials Thereof
4 20 ST RE [0..1] Suffix (e.g., JR or III)
5 20 ST RE [0..1] Prefix (e.g., DR)
6 6 IS X [0..0] 0360 Degree (e.g., MD)
7 1 ID R [1..1] 0200 Name Type Code
8 1 ID RE [0..1] 0465 Name Representation Code

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 172 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

SEQ LEN DT Usage Card. TBL# Component name

9 705 CWE RE [0..1] 0448 Name Context
10 49 DR X [0..0] Name Validity Range
11 1 ID RE [0..1] 0444 Name Assembly Order
12 24 DTM RE [0..1] Effective Date
13 24 DTM RE [0..1] Expiration Date
14 199 ST RE [0..1] Professional Suffix

This data type is usually in a repeatable field, to allow a list of names. Examples: Legal name,
display name.
4440 Subfield 1 "Family Name" is required if known to the sender.
Subfield 7 "Name Type Code" is required. The PAM Profile allows these values from HL7 Table
0200 – Name type:

Table C.8-2: HL7 Table 0200 - Name Type

Value Description Comment
A Alias Name
B Name at Birth
C Adopted Name
D Display Name
I Licensing Name
L Legal Name
M Maiden Name
N Nickname /"Call me" Name/Street Name
R Registered Name (animals only)
S Coded Pseudo-Name to ensure anonymity
T Indigenous/Tribal/Community Name
U Unspecified

4445 This table may be further defined and restrained in national extensions of this profile.
Subfields 6 (Degree) and 10 (Name Validity Range) are deprecated in HL7 v2.6, therefore not
supported by the PCD profile.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 173 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

C.9 XTN Data Type

Table C.9-1: XTN-Extended Telecommunication Number

SEQ LEN DT Usage Card. TBL# Component name
1 199 ST X Telephone Number
2 3 ID R [1..1] 0201 Telecommunication Use Code
3 8 ID R [1..1] 0202 Telecommunication Equipment
Type
4 199 ST RE [0..1] Email Address
5 3 NM RE [0..1] Country Code
6 5 NM RE [0..1] Area/City Code
7 9 NM RE [0..1] Local Number
8 5 NM RE [0..1] Extension
9 199 ST RE [0..1] Any Text
10 4 ST RE [0..1] Extension Prefix
11 6 ST X [0..0] Speed Dial Code
12 199 ST X [0..0] Unformatted Telephone number
13 24 DTM X [0..0] Effective Start Date
14 24 DTM X [0..0] Expiration Date
15 705 CWE X [0..0] 0868 Expiration Reason
16 705 CWE X [0..0] 0618 Protection Code
17 427 EI X [0..0] Shared Telecommunication
Identifier
18 2 NM X [0..0] Preference Order

4450
Subfield 2 "Telecommunication Use Code" is required and is valued as either PRN "Primary
Residence Number" or NET "Network (email) address. See HL7 Table 201.
Subfield 3 "Telecommunication Equipment Type" is required and is valued as PH "Telephone",
Internet "Internet Address: Use Only If Telecommunication Use Code Is NET", or X.400 "X.400
4455 email address: Use Only If Telecommunication Use Code Is NET". See HL7 Table 202.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 174 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Appendix D Reserved

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 175 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Appendix E Examples of messages

These message examples illustrate the uses cases defined in PCD TF-1. They are informative
only, not authoritative and not representative of messages in actual implementations but are only
4460 examples to illustrate general aspects of the use cases and the mapping of ISO/IEEE 11073 to
HL7. Implementers should test all messages against the NIST test tooling for IHE PCD.

E.1 PCD-01 Case C1: Communicate periodic data to Clinical

Information System (CIS)
Periodic and episodic data from all of the patient care devices associated with a particular patient
4465 are typically communicated to a CIS (Device Observation Consumer) by a monitoring gateway
server (the DOR). Examples include data from a bedside monitor, point of care lab devices,
ventilators, and infusion pumps. Discrete and data are communicated to the CIS. The primary
intent is communication of structured data; however, provisions are made for inclusion of
unstructured data. The patient associated with the data is identified and the data is time stamped
4470 with a consistent time across the respective patient care devices.

E.1.1 Example of PCD-01 Observation Report (Physiological Monitor)

An observation result from a physiological monitor.

4475

4480

4485

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 176 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

MSH|^~\&|PAT_DEVICE_PHILIPS_C|Philips|||20150122182658+0000||ORU^R01^ORU_R01|HP01221826
4490 58686QQ000CND119C0WS61|P|2.6|||AL|NE||8859/1|EN^English^ISO639||IHE_PCD_001^IHE
PCD^1.3.6.1.4.1.19376.1.6.1.1.1^ISO
PID|||HO2009001^^^^MR||Hon^Albert^""^^^^L||19610101|M
PV1||I|HO Surgery^OR^1
OBR|1||201512218265601|69965^MDC_DEV_MON_PHYSIO_MULTI_PARAM_MDS^MDC|||20150122182656
4495 OBX|1|ST|69965^MDC_DEV_MON_PHYSIO_MULTI_PARAM_MDS^MDC|1.0.0.0|||||||X|||||||e86c094f-
f751-4acf-92b2-38f11c1f6f57-Device
OBX|2|ST|70686^MDC_DEV_PRESS_BLD_NONINV_VMD^MDC|1.1.0.0|||||||X|||||||0600dc750001
OBX|3|ST|70675^MDC_DEV_PULS_CHAN^MDC|1.1.1.0|||||||X
OBX|4|NM|150021^MDC_PRESS_BLD_NONINV_SYS^MDC|1.1.1.5|117|266016^MDC_DIM_MMHG^MDC|90-
4500 160||||X|||20150122115000
OBX|5|NM|150022^MDC_PRESS_BLD_NONINV_DIA^MDC|1.1.1.6|82|266016^MDC_DIM_MMHG^MDC|||||X||
|20150122115000
OBX|6|NM|150023^MDC_PRESS_BLD_NONINV_MEAN^MDC|1.1.1.7|90|266016^MDC_DIM_MMHG^MDC|||||X|
||20150122115000
4505 OBX|7|ST|4262^MDC_DEV_ECG_VMD^MDC|1.2.0.0|||||||X|||||||0600dc750001
OBX|8|ST|4263^MDC_DEV_ECG_CHAN^MDC|1.2.1.0|||||||X
OBX|9|NM|147842^MDC_ECG_CARD_BEAT_RATE^MDC|1.2.1.1|80|264864^MDC_DIM_BEAT_PER_MIN^MDC|5
0-120||||X
OBX|10|NM|147232^MDC_ECG_TIME_PD_QT_GL^MDC|1.2.1.14|360|264338^MDC_DIM_MILLI_SEC^MDC|||
4510 ||X
OBX|11|NM|147236^MDC_ECG_TIME_PD_QTc^MDC|1.2.1.15|416|264338^MDC_DIM_MILLI_SEC^MDC|<500
||||X
OBX|12|NM|151562^MDC_RESP_RATE^MDC|1.2.1.19|30|264928^MDC_DIM_RESP_PER_MIN^MDC|8-
45||||X
4515 OBX|13|ST|184327^MDC_ECG_STAT_RHY^MDC|1.2.1.21|MDC_ECG_SINUS_RHY||||||X
OBX|14|ST|69642^MDC_DEV_ANALY_SAT_O2_VMD^MDC|1.3.0.0|||||||X|||||||0600dc750001
OBX|15|ST|70771^MDC_DEV_ANALY_PERF_REL_CHAN^MDC|1.3.1.0|||||||X
OBX|16|NM|150456^MDC_PULS_OXIM_SAT_O2^MDC|1.3.1.1|99|262688^MDC_DIM_PERCENT^MDC|90-
100||||X
4520 OBX|17|NM|150448^MDC_PULS_OXIM_PERF_REL^MDC|1.3.1.3|3.9|262656^MDC_DIM_DIMLESS^MDC|||||
X

E.1.2 Example of PCD-01 Episodic Observation Report

Note that time stamps are present in the metric OBX segments (OBX-14). These override the
timestamps at higher levels (here the channel level OBX and the containing OBR, which happen
4525 to be the same in this case but would be overridden by the lower-level time stamp if they were
not). Note also that the dotted notation in OBX-4 on the MDS, VMD, and channel device data
OBX segments have trailing zeroes below the hierarchical level they apply to (e.g., MDS has
nonzero MDS-level value, followed by zeroes at the VMD, channel, and metric level).

4530

4535

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 177 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

MSH|^~\&|ACME_Gateway^080019FFFE3ED02D^EUI-64|ACME
Healthcare|||20110602050000+0000||ORU^R01^ORU_R01|0104ef190d604db188c3|P|2.6|||AL|NE||U
NICODE UTF-8|||PCD_DEC_001^IHE PCD^1.3.6.1.4.1.19376.1.6.1.1.1^ISO
PID|||12345^^^A^MR||BEDS^TEDSONS^^^^^L
4540 PV1||U|COLWELL^^SOLAR
OBR|1|080019FFFE3ED02D20110602045842^ACME_Gateway^080019FFFE3ED02D^EUI-
64|080019FFFE3ED02D20110602045842^ACME_Gateway^080019FFFE3ED02D^EUI-
64|182777000^monitoring of patient^SCT|||20110602045842+0000
OBX|1||69965^MDC_DEV_MON_PHYSIO_MULTI_PARAM_MDS^MDC|1.0.0.0|||||||X
4545 OBX|2||70686^MDC_DEV_PRESS_BLD_NONINV_VMD^MDC|1.16.0.0|||||||X
OBX|3||70687^MDC_DEV_PRESS_BLD_NONINV_CHAN^MDC|1.16.1.0|||||||X|||20110602045842
OBX|4|NM|150021^MDC_PRESS_BLD_NONINV_SYS^MDC|1.16.1.1|111|mm[Hg]^mm[Hg]^UCUM|||||R|||20
110602045842||||080019FFFE3ED02D172.16.172.135^GATEWAY_ACME
OBX|5|NM|150022^MDC_PRESS_BLD_NONINV_DIA^MDC|1.16.1.2|60|mm[Hg]^mm[Hg]^UCUM|||||R|||201
4550 10602045842||||080019FFFE3ED02D172.16.172.135^GATEWAY_ACME
OBX|6|NM|150023^MDC_PRESS_BLD_NONINV_MEAN^MDC|1.16.1.3|80|mm[Hg]^mm[Hg]^UCUM|||||R|||20
110602045842||||080019FFFE3ED02D172.16.172.135^GATEWAY_ACME
OBX|7|NM|149546^MDC_PULS_RATE_NON_INV^MDC|1.16.1.4|63|{beat}/min^{beat}/min^UCUM|||||R|
||20110602045842||||080019FFFE3ED02D172.16.172.135^GATEWAY_ACME

4555

E.2 Examples of transaction [PCD-03]: Communicate Infusion Order

This example illustrates the use of [PCD-03].

E.2.1 Storyboard
Objects Attributes
Patient Legal Name: John Doe
ID: 98765
Sex: M
Date of birth: January 1, 1966
Weight: 85.0 kg
Nurse Jane Adams
ID: N0001
Medication Example 1 Example 2
ID: 1234 ID: 5678
Name: Dopamine Name: Normal Saline
Volume to be infused: 250 mL Volume to be infused: 500 mL
Concentration: 400 mg / 250 mL Rate: 13.3 mL/hr
Dose: 10 mcg/kg/min
Pump ID: A0001

4560

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 178 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

E.2.2 Interaction Diagram

Case 1: No errors detected, so Application Ack is not sent

RGV

Accept Ack (ACK)

IOP Order
IOC

Response/Ack
to Order Pump

4565

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 179 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Case 2: Application Error is detected before order is sent to the pump

RGV

Accept Ack (ACK)

IOP IOC
Application Ack (RRG)

Pump

4570

Case 3: Application Error is detected after order is sent to the pump

RGV

Accept Ack (ACK)

IOP Order
IOC

Response/Ack
to Order Pump

Application Ack (RRG)

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 180 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

E.2.3 Messages
Example 1
Order #12345 for Patient ID 98765 (John Doe), Dopamine, volume to be infused 250 ml at 10
4575 mcg/kg/min, concentration of 400 mg in 250 ml, patient weight 85.0 kg, Pump ID A0001,
administered by nurse N0001.
Communicate Infusion Order
MSH|^~\&|IOPVENDOR^1234560000000001^EUI-
64|IOPVENDOR|IOCVENDOR^6543210000000001^EUI-64|IOCVENDOR|20080101123456-
0600||RGV^O15^RGV_O15|1|P|2.5|||AL|ER||ASCII|EN^English^ISO659||IHE_PCD_PIV_001
PID|||98765^^^IHE^PI||Doe^John^^^^^L||19660101000000-0600|M
ORC|RE|12345|||||||||||||||||N0001
RXG|1|||1234^Dopamine|250||263762^MDC_DIM_MILLI_L^MDC^mL^mL^UCUM ||||||||10|3
475^ug/kg/min^UCUM^265619^MDC_DIM_MICRO_G_PER_KG_PER_MIN^MDC|400|1746^mg^UCUM
^263890^MDC_DIM_MILLI_G^MDC|||||250|263762^MDC_DIM_MILLI_L^MDC^mL^mL^UCUM
RXR|IV||IVP
OBX|1||69986^MDC_DEV_PUMP_INFUS_VMD^MDC||||||||X|||||||^^A0001^PUMPVENDOR
OBX|2|NM|68063^MDC_ATTR_PT_WEIGHT^MDC||85.0|kg^kg^UCUM^263875^MDC_DIM_KILO_G^MDC

Accept Acknowledgement
MSH|^~\&|IOCVENDOR^6543210000000001^EUI-64|IOCVENDOR|IOPVENDOR^1234560000000001^EUI-
64|IOPVENDOR|20080101123456-
0600||ACK^O15^ACK|1|P|2.5||||||ASCII|EN^English^ISO659||IHE_PCD_PIV_001
MSA|CA|1

4580
Example 2
Order #12345 for Patient ID 98765 (John Doe), Normal Saline, volume to be infused 500 ml at
rate of 13.3 ml/hr, Pump ID A0001, administered by nurse N0001.
Communicate Infusion Order
MSH|^~\&|IOPVENDOR^1234560000000001^EUI-64|IOPVENDOR|IOCVENDOR^6543210000000001^EUI-
64|IOCVENDOR|20080101123456-
0600||RGV^O15^RGV_O15|2|P|2.5|||AL|ER||ASCII|EN^English^ISO659||IHE_PCD_PIV_001
PID|||98765^^^IHE^PI||Doe^John^^^^^L||19660101000000-0600|M
ORC|RE|12345|||||||||||||||||N0001
RXG|1|||5678^Normal Saline|500||263762^MDC_DIM_MILLI_L^MDC^mL^mL^UCUM
||||||||13.3|3122^mL/h^UCUM^265266^MDC_DIM_MILLI_L_PER_HR^MDC
RXR|IV||IVP
OBX|1||69986^MDC_DEV_PUMP_INFUS_VMD^MDC||||||||X|||||||^^A0001^PUMPVENDOR
4585
Accept Acknowledgement
MSH|^~\&|IOCVENDOR^6543210000000001^EUI-64|IOCVENDOR|IOPVENDOR^1234560000000001^EUI-
64|IOPVENDOR|20080101123456-
0600||ACK^O15^ACK|102|P|2.5||||||ASCII|EN^English^ISO659||IHE_PCD_PIV_001
MSA|CA|

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 181 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

The infusion server cannot find the give code id in the infusion formulary. The infusion server
issues an application acknowledgment reject message to the IOP.
4590
Application Acknowledgment
MSH|^~\&|IOCVENDOR^6543210000000001^EUI-64|IOCVENDOR|IOPVENDOR^1234560000000001^EUI-
64|IOPVENDOR|20080101123456- 0600||
RRG^O16^RRG_O16|102|P|2.5||||||ASCII|EN^English^ISO659||IHE_PCD_PIV_001
MSA|AR|102
ERR|||207^ Application internal error|F|9010^Unable to match medication to drug library

E.3 ACM [PCD-04] Example Messages

E.3.1 Alert - Numeric Limit Alarm
4595
Patient Monitoring Device, Low SPO2 Alarm Indication, Start

MSH|^~\&|MINDRAY_EGATEWAY^00A037EB2175780F^EUI-
64|MINDRAY|AM_PHILIPS_IEM^00095CFFFE741952^EUI-64|PHILIPS|20120111150457-
0600||ORU^R40^ORU_R40|1|P|2.6|||AL|NE||UNICODE UTF-8|||IHE_PCD_ACM_001^IHE
PCD^1.3.6.1.4.1.19376.1.6.4.4.1^ISO
PID|||HO2009001^^^Hospital^PI||Hon^Albert^^^^^L||18991230|M
PV1||I|HO Surgery^OR^1
OBR|1|1^MINDRAY_EGATEWAY^00A037EB2175780F^EUI64|↵
1^MINDRAY_EGATEWAY^00A037EB2175780F^EUI64|
196616^MDC_EVT_ALARM^MDC|||20120111150457-
0600||||||||||||||||||||||^1&MINDRAY_EGATEWAY&00A037EB2175780F&EUI-64
OBX|1|ST|196670^MDC_EVT_LO^MDC|1.3.1.150456.1|Low
SpO2|||L~PM~SP|||F|||20120111150457-0600||||F1519EFX^SHENZHEN_DEVICE^mindray.com^DNS
OBX|2|NM|150456^MDC_PULS_OXIM_SAT_O2^MDC|1.3.1.150456.2|88|262688^MDC_DI
M_PERCENT^MDC|90-96||||F|||20120111150457-0600
OBX|3|ST|68481^MDC_ATTR_EVENT_PHASE^MDC|1.3.1.150456.3|start||||||F
OBX|4|ST|68482^MDC_ATTR_ALARM_STATE^MDC|1.3.1.150456.4|active||||||F
OBX|5|ST|68483^MDC_ATTR_ALARM_INACTIVATION_STATE|1.3.1.150456.5|enabled|||||F
Note: The use of DNS as the standards base indication for OBX-18 Equipment Instance Identifier is acceptable for
Connectathon use; however, in live deployments it would be expected to be a formally registered value, such as an
EUI-64.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 182 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

4600 E.3.2 Alert - Qualitative (non-numeric) Alarm

Infusion Pump, Fluid Line Occlusion, Technical Alarm Indication Start
MSH|^~\&|PAT_DEVICE_BBRAUN^0012211839000001^EUI-
64|BBRAUN|AM_Philips_IEM^ 00095CFFFE741952 ^EUI-64|Philips|20120109175417-
0600||ORU^R40^ORU_R40|6346172845752460251|P|2.6|||AL|NE||ASCII|EN^English^ISO639||
4605 IHE_PCD_ACM_001^IHE PCD^1.3.6.1.4.1.19376.1.6.4.4.1^ISO
PID|||HO2009003^^^AA1^PI||Hon^Amy^^^^^L|Coburn^^^^^^L|19610301000000-0600|F
PV1||I|HO 3 West ICU^10^1
OBR|1|634617284575713662^PAT_DEVICE_BBRAUN^0012211839000001^EUI-
64|P6013_4^PAT_DEVICE_BBRAUN^0012211839000001^EUI-
4610 64|196616^MDC_EVT_ALARM^MDC|||20120109175417-0600
||||||||||||||||||||||^E0001_27&PAT_DEVICE_BBRAUN&0012211839000001&EUI-64
OBX|1|CWE|196616^MDC_EVT_ALARM^MDC|1.0.0.0.1|196940^MDC_EVT_FLUID_LINE_OCCL^MDC^^^^^^O
cclusion|||ST|||F|||||||P6013^^0012210000000000^EUI-64
OBX|2|CWE|68480^MDC_ATTR_ALERT_SOURCE^MDC|1.0.0.0.2|
4615 69985^MDC_DEV_PUMP_INFUS_MDS^MDC||||||F|||20120109175417-0600
OBX|3|ST|68481^MDC_ATTR_EVENT_PHASE^MDC|1.0.0.0.3|start||||||F
OBX|4|ST|68482^MDC_ATTR_ALARM_STATE^MDC|1.0.0.0.4|active||||||F
OBX|5|ST|68483^MDC_ATTR_ALARM_INACTIVATION_STATE|1.0.0.0.5|enabled|||||F

4620 Infusion Pump, Fluid Line Occlusion, Technical Alarm Indication, End
MSH|^~\&|PAT_DEVICE_BBRAUN^0012211839000001^EUI-
64|BBRAUN|AM_Philips_IEM^00095CFFFE741952^EUI-64|Philips|20120109175426-
0600||ORU^R40^ORU_R40|6346172846620706282|P|2.6|||AL|NE||ASCII|EN^English^ISO639||
IHE_PCD_ACM_001^IHE PCD^1.3.6.1.4.1.19376.1.6.1.4.1^ISO
4625 PID|||HO2009003^^^AA1^PI||Hon^Amy^^^^^L|Coburn^^^^^^L|19610301000000-
0600|F
PV1||I|HO 3 West ICU^10^1
OBR|1|634617284662070628^PAT_DEVICE_BBRAUN^0012211839000001^EUI-
64|P6013_4^PAT_DEVICE_BBRAUN^0012211839000001^EUI-
4630 64|196616^MDC_EVT_ALARM^MDC|||20120109175426-
0600||||||||||||||||||||||^E0001_27&PAT_DEVICE_BBRAUN&0012211839000001&EUI-64
OBX|1|CWE|196616^MDC_EVT_ALARM^MDC|1.0.0.0.1|196940^MDC_EVT_FLUID_LINE_OCCL^MDC^^^^^^O
cclusion|||ST|||F|||||||P6013^^0012210000000000^EUI-64
OBX|2|CWE|68480^MDC_ATTR_ALERT_SOURCE^MDC|1.0.0.0.2|69985^MDC_DEV_PUMP_INFUS_MDS^MDC|||
4635 |||F|||20120109175426-0600

OBX|3|ST|68481^MDC_ATTR_EVENT_PHASE^MDC|1.0.0.0.3|end||||||F
OBX|4|ST|68482^MDC_ATTR_ALARM_STATE^MDC|1.0.0.0.4|inactive||||||F
OBX|5|ST|68483^MDC_ATTR_ALARM_INACTIVATION_STATE|1.0.0.0.5|enabled|||||F
4640

4645

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 183 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Alert – Advisory of undocumented timeout prior to surgical procedure

MSH|^~\&|CONTENT_CONSUMER_LIVEDATA|LIVEDATA|AM_Philips_IEM|Philips|20120109175426-
0600||ORU^R40^ORU_R40| 1233532926265-02|P|2.6|||NE|AL||ASCII|EN^English^ISO639||
4650 IHE_PCD_ACM_001^IHE PCD^1.3.6.1.4.1.19376.1.6.1.4.1^ISO
PID|||HO2009003^^^AA1^PI||Hon^Amy^^^^^L|Coburn^^^^^^L|19610301000000-
0600|F
PV1||I|HO 3 West ICU^10^1
OBR|1||12345-2^LIVEDATA|196616^MDC_EVT_ALARM^MDC|||20120109175426-
4655 0600||||||||||8664693239
OBX|1|CWE|0^MDCX_DOCUMENTATION_ERROR^MDC|2.1.2.1.1|Timeout not
documented|||SA~PM|||R||20120109175426-0600
OBX|2|CWE|684800^MDC_ATTR_ALERT_SOURCE^MDC |1.0.0.0.2|Procedure not documented on
time|||SA~PM|||R||20120109175426-0600
4660 OBX|3|ST|684810^MDC_ATTR_EVENT_PHASE^MDC |2.1.2.1.3|start||||||R
OBX|4|ST|684820^MDC_ATTR_ALARM_STATE^MDC |2.1.2.1.4|active||||||R

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 184 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Appendix F HL7 Message Profiling Convention

For the material formerly in this Appendix, readers should refer to IHE Technical Frameworks
General Introduction Appendix E.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 185 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

4665 Appendix G – HL7 Implementation Notes

For general HL7 Implementation Notes, it is important that the reader study IHE Technical
Frameworks General Introduction Appendix E. Only considerations specific to IHE PCD profiles
will be covered here.

G.1 Acknowledgment Modes

4670 ACKNOWLEDGMENT MESSAGES
Acknowledgment messages may be defined on an application basis. However, the simple general
acknowledgment message (ACK) may be used where the application does not define a special
message (application level acknowledgment) and in other cases as described in Section 2.9 of the
HL7 specification, "Message Processing Rules".
4675 The IHE PCD transaction [PCD-03] supports ‘enhanced mode’ acknowledgements. See
discussion under [PCD-03] transactions as well as in B.1 MSH – Message Header Segment and
B.2 MSA – Message Acknowledgement Segment

G.2 Use of OSI Object Identifier (OID)

OSI Object identifiers (OIDs) are universal identifiers used in HL7 in a number of contexts.
4680 Unlike GUIDs or UUIDs, which are generated by a completely uncentralized process (using an
algorithm that can run on any computer that is extremely unlikely to ever generate the same ID
twice), OIDs are generated by a hierarchical network of entities each of which is the ultimate
authority for its own part of the tree. See ITI TF-2x: Appendix B for general specifications for
OID syntax, and for obtaining an OID root for your organization.
4685 The IHE PCD Technical Committee may issue OIDs from its reserved OID arc for the
registration IHE PCD profiles, or for such other purposes as the Committee determines.
The following OID has been assigned to IHE PCD: 1.3.6.1.4.1.19376.1.6
ISO/IEEE 11073 nomenclature terms have OIDs from the arc 1.2.840.10004.1.1.1.0.0.1
HL7 allocates OIDs from the arc 2.16.840.1.113883 (joint-iso-itu-t.country.us.organization.hl7).
4690 HL7 maintains an OID registry at http://www.hl7.org/oid/index.cfm.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 186 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Appendix H – IHE Integration Statements

For material formerly in this Appendix, readers should now refer to IHE Technical Frameworks
General Introduction Appendix F.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 187 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

4695 Appendix I – Message Transport using MLLP

IHE PCD HL7 V2 messages may be sent using the HL7-defined "Minimal Lower Layer
Protocol" (MLLP). At the present time, MLLP is used by all IHE PCD actors operating behind a
hospital firewall, and the selection of MLLP versus other transport options is based on
implementation or one-time configuration.
4700 Guidance regarding MLLP is provided by the ITI TF-2x Section C.2.1 Network Guidelines,
which in turn reference the Minimal Lower Layer Protocol defined in Appendix C of the HL7
Implementation Guide.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 188 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Appendix J – Message Transport using WS*

4705 IHE PCD HL7 V2 messages may be sent over Web Services (WS*).
The IHE IT Infrastructure Technical Framework Volume 2x Appendix V provides guidance
regarding the appropriate WSDL files, schema and sample XML messages. The following
artifacts are provided here as informative implementations and should match the versions found
in the IHE ftp://ftp.ihe.net/TF_Implementation_Material/ for PCD. If a later version is available
4710 at the ftp site, it should be used.

J.1 Sample WSDL file and schema

The Web Services Description Language (WSDL) is a W3C standard designed to define a web
service through concrete endpoints and operations. The IHE IT Infrastructure Technical
Framework Volume 2x Appendix V provides guidance on deriving WSDL files from an IHE
4715 transaction.
Non-normative illustrative examples of a WSDL file «DeviceObservationConsumer.wsdl» and
schema «DeviceObservationConsumer.xsd» are shown below:

DeviceObservationConsumer.wsdl
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions name="DeviceObservationConsumer"
targetNamespace="urn:ihe:pcd:dec:2010"
xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl"
xmlns:tns="urn:ihe:pcd:dec:2010">
<wsdl:types>
<xsd:schema>
<xsd:import namespace="urn:ihe:pcd:dec:2010"
schemaLocation="DeviceObservationConsumer.xsd"/>
</xsd:schema>
</wsdl:types>
<wsdl:message name="CommunicatePCDData_Message">
<wsdl:documentation>Communicate PCD Data</wsdl:documentation>
<wsdl:part name="body" element="tns:CommunicatePCDData"/>
</wsdl:message>
<wsdl:message name="CommunicatePCDDataResponse_Message">
<wsdl:documentation>Communicate PCD Data Response</wsdl:documentation>
<wsdl:part name="body" element="tns:CommunicatePCDDataResponse"/>
</wsdl:message>
<wsdl:portType name="DeviceObservationConsumer_PortType">
<wsdl:operation name="CommunicatePCDData">
<wsdl:input message="tns:CommunicatePCDData_Message"
wsaw:Action="urn:ihe:pcd:2010:CommunicatePCDData"/>
<wsdl:output message="tns:CommunicatePCDDataResponse_Message"
wsaw:Action="urn:ihe:pcd:2010:CommunicatePCDDataResponse"/>

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 189 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="DeviceObservationConsumer_Binding_Soap12"
type="tns:DeviceObservationConsumer_PortType">
<soap12:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<wsaw:UsingAddressing wsdl:required="true"/>
<wsdl:operation name="CommunicatePCDData">
<soap12:operation soapAction="urn:ihe:pcd:2010:CommunicatePCDData"
soapActionRequired=""/>
<wsdl:input>
<soap12:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap12:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="DeviceObservationConsumer_Service">
<wsdl:port name="DeviceObservationConsumer_Port_Soap12"
binding="tns:DeviceObservationConsumer_Binding_Soap12">
<soap12:address location="http://www.example.org/"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>

4720 Note: the element <wsaw:UsingAddressing wsdl:required="true"/> is required for strict

conformance to IHE ITI Technical Framework Vol. 2x, Appendix V (and is required by IHE
testing tools), but readers are warned that some web services infrastructure implementation will
not use or recognize it, so it is well if feasible to be prepared to include it or not, to be prepared
to deal with both situations.
4725
DeviceObservationConsumer.xsd
<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema" xmlns:tns="urn:ihe:pcd:dec:2010"
targetNamespace="urn:ihe:pcd:dec:2010">
<element name="CommunicatePCDData" type="tns:UnsolicitedObservationResult"/>
<element name="CommunicatePCDDataResponse" type="tns:GeneralAckowledgement"/>
<simpleType name="UnsolicitedObservationResult">
<restriction base="string"/>
</simpleType>
<simpleType name="GeneralAckowledgement">
<restriction base="string"/>
</simpleType>
</schema>

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 190 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

J.2 Sample PCD-01 message and response

In addition to the WSDL-related rules found in Appendix V of the IHE ITI Technical
Framework Volume 2x, the framework contains a number of conformance constraints for web
service consumers and providers. These rules were developed to improve IHE-related web
4730 service interoperability and PCD implementations using web services are required to comply.
Note that the contents of the urn:ihe:pcd:dec:2010:CommunicatePCDData element must contain
the entire contents of a valid PCD-01 Observation Result message. However, based on the
character restrictions of XML and web services, there are a number of characters that cannot be
used in their literal form (see http://www.w3.org/International/questions/qa-controls#support for
4735 more information).
Restricted characters, such as "&” and "<cr>", must be escaped using XML predefined character
entity references wherever possible (e.g., &amp;). For restricted characters that have no
predefined character entity references, a numeric character references should be used instead
(e.g., &#d;). Messages containing characters which are prohibited from use in XML in both
4740 literal and escaped format are prohibited from being sent using the WS* transport profile.
For a complete list of excluded characters, please see the XML specification at
http://www.w3.org/TR/xml/#syntax

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 191 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Examples of a Communicate PCD Data message «CommunicatePCDData.xml» and a typical

4745 response «CommunicatePCDDataResponse.xml» are shown below (informative).

CommunicatePCDData.xml
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
<soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing">
<wsa:To soapenv:mustUnderstand="true">
http://localhost:9097/org.openhealthtools.stepstone.backend.gateway/DeviceObservationConsumer_Servi
ce
</wsa:To>
<wsa:From soapenv:mustUnderstand="true">
<wsa:Address>
http://www.w3.org/2005/08/addressing/anonymous
</wsa:Address>
</wsa:From>
<wsa:MessageID soapenv:mustUnderstand="true">
urn:uuid:A52590343911955D1A1251497585530
</wsa:MessageID>
<wsa:Action soapenv:mustUnderstand="true">
urn:ihe:pcd:2010:CommunicatePCDData
</wsa:Action>
</soapenv:Header>
<soapenv:Body>
<CommunicatePCDData xmlns="urn:ihe:pcd:dec:2010">
MSH|^~\&amp;|AcmeInc^ACDE48234567ABCD^EUI-
64||||20090713090030+0500||ORU^R01^ORU_R01|MSGID1234|P|2.6|||NE|AL|||||IHE PCD ORU-R01
2006^HL7^2.16.840.1.113883.9.n.m^HL7&#xD;
PID|||789567^^^Imaginary Hospital^PI||Doe^John^Joseph^^^^L^A|||M&#xD;
OBR|1|AB12345^AcmeAHDInc^ACDE48234567ABCD^EUI-64|CD12345^AcmeAHDInc^ACDE48234567ABCD^EUI-
64|528391^MDC_DEV_SPEC_PROFILE_BP^MDC|||20090813095715+0500&#xD;
OBX|1||528391^MDC_DEV_SPEC_PROFILE_BP^MDC|1|||||||R|||||||0123456789ABCDEF^EUI-64&#xD;
OBX|2||150020^MDC_PRESS_BLD_NONINV^MDC|1.0.1||||||R|||20090813095715+0500&#xD;
OBX|3|NM|150021^MDC_PRESS_BLD_NONINV_SYS^MDC|1.0.1.1|120|266016^MDC_DIM_MMHG^MDC||||R&#xD;
OBX|4|NM|150022^MDC_PRESS_BLD_NONINV_DIA^MDC|1.0.1.2|80|266016^MDC_DIM_MMHG^MDC||||R&#xD;
OBX|5|NM|150023^MDC_PRESS_BLD_NONINV_MEAN^MDC|1.0.1.3|100|266016^MDC_DIM_MMHG^MDC||||R&#xD;
</CommunicatePCDData>
</soapenv:Body>
</soapenv:Envelope>

4750

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 192 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

CommunicatePCDDataResponse.xml
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
<soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing">
<wsa:Action>
urn:ihe:pcd:2010:CommunicatePCDDataResponse
</wsa:Action>
<wsa:RelatesTo>
urn:uuid:F8C3FF2964F94E404E1251145112405
</wsa:RelatesTo>
</soapenv:Header>
<soapenv:Body>
<CommunicatePCDDataResponse xmlns="urn:ihe:pcd:dec:2010">
MSH|^~\&amp;|Stepstone||AcmeInc^ACDE48234567ABCD^EUI64||20090726095731+0500||ACK^A01^ACK|AMSGID1234|
P|2.6|&#xD;
MSA|AA|MSGID1234|Message Accepted|&#xD;
</CommunicatePCDDataResponse>
</soapenv:Body>
</soapenv:Envelope>

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 193 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Appendix K – Message Transport Using WCTP (ACM Transactions

[PCD-06] and PCD-07)
4755 The following appendix covers the messages exchanged between an IHE PCD ACM Alert
Manager and an Alert Communicator using the WCTP protocol

K.1 Abbreviations and definitions

HTTP – HyperText Transport Protocol
WCTP – Wireless Communications Transfer Protocol – the protocol between the ACM Alert
4760 Manager and the ACM Alert Communicator Actors.
MCR (Multiple Choice Response) – the means to pass a message with selectable responses from
the ACM Alert Manager to the ACM Alert Communicator.
XML – eXtensible Markup Language

4765 What is WCTP

WCTP is the protocol between the ACM Alert Manager and the ACM Alert Communicator
Actors. It makes use of an optionally securable (authentication and encryption) HTTP transport
layer to convey XML-based WCTP protocol exchanges between a WCTP client (the ACM Alert
Manager) and the WCTP server (the ACM Alert Communicator).

4770 K.2 Pre-Configuration

The HTTP source to destination is assumed to be resolved through pre-configuration.
Whether or not secure http (HTTPS) is used or not is resolved through pre-configuration
The WCTP PollerID and security password used to identify the message send requestor (not the
request itself) are assumed to be resolved through pre-configuration.
4775 The URI values for the WCTP senderID and sendResponseToID are assumed to be resolved
through pre-configuration.

K.3 Endpoint Device Addressing

Endpoint entity (wireless device) addressing can be per WCTP (often the phone number of the
endpoint device), but in any event it is presumed to be pre-configured so that there is a match
4780 from Alert Manager (AM) to Alert Communicator (AC).

K.4 Polling Versus Push Responses

The decision as to whether polling or push response is used for status updates is assumed to be
resolved through pre-configuration. WCTP would be best used in its web push response form
rather than polling for responses so as to maintain responsiveness of status updates and replies.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 194 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

4785 Some WCTP implementations have minimum tolerable poll intervals to reduce overall polling of
the WCTP gateway server, the Alert Communicator (AC).

K.5 Constraints
The use of WCTP for ACM does not require Message Response Redirection.
Sub-second timing is not expected to be needed by ACM use of WCTP.
4790 The WCTP messageID is used to track the status of a message that was sent from the Alert
Manager to the Alert Communicator.
The WCTP notifyWhen element should indicate notifyWhenDelivered (notify upon delivery to
device) and notify upon read receipt.
If WCTP version query is not supported then a request for version query must not be ignored. It
4795 must be responded to with a Not Supported WCTP confirmation response.

K.6 Transactions

Table K.6-1: WCTP requests and responses

Request Alert Alert Manager Needed
Communicator Actor
Actor (WCTP Client)
(WCTP Server)
Receives Submits
wctp-ClientQuery Yes No No (polling)
wctp-LookupSubscriber Yes No No
wctp-LookupResponse No Yes No
wctp-DeviceLocation Yes No No
wctp-DeviceLocationResponse No Yes No
wctp-MessageReply Yes Yes Yes
wctp-PollForMessages Yes No No
wctp-ReturnToSvc Yes No Yes
wctp-SendMsgMulti Yes No No
wctp-StatusInfo Yes Yes No
wctp-SubmitClientMessage Yes No Yes
wctp-SubmitRequest Yes Yes No
wctp-VersionQuery Yes Yes Yes

K.7 WCTP XML Element Common Data Items

4800 Some message exchanges are administrative in nature, similar to TCP open, accept, and
acknowledgement messages which are not documented as a part of HL7, while others have a
direct and obvious place in the ACM Profile as transactions, such as [PCD-06] and [PCD-07].

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 195 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Please note, XML constant strings are presented in normal text. XML data to be filled in during
implementation is presented in bold red text.
4805 The format of WCTP conformant timestamps (timestamp) is: yyyy-mm-ddThh:mm:ss.ttt
All times are UTC. WCTP does not support the ability to indicate a time zone offset.
Hours (hh) in 24-hour format, and .ttt is the optional number of milliseconds
Example: 2011-01-19T20:33:52
A push response URI is the URI (URL minus the HTTP://) used to identify the HTTP POST
4810 destination for WCTP replies and status updates.
The notification text value is the actual text message to be presented to the wireless device
operator.
The sender ID is the security identification of the IHE ACM to the WCTP receiver.
The security code is essentially the password to go with the security sender ID.
4815 The message ID is the identification of the overall message to the ACM Alert Communicator by
the Alert Manager.
The transaction ID is the lower level transaction identification making up the message.
The recipient PIN is the identification of the destination device as per the ACM Alert
Communicator.
4820 The e-mail address is the optional ACM Alert Manager contact information e-mail address.
The phone number is the optional ACM Alert Manager contact information voice telephony
phone number.
The web site is the optional ACM Alert Manager contact information web site.
The info string is the optional ACM Alert Manager contact information comment.
4825 The priority is any of HIGH, NORMAL, or LOW with a default of NORMAL.
The presentation ID is the optional alphanumeric field for coordinating presentation, behaviors,
sorting, etc. between the ACM Alert Communicator and ACM Alert Manager. The AC and AM
should coordinate expected values.
The sequence number is a sequential value used for tracking polling requests and responses
4830 used during Virtual Pre-Connectathon testing.
The batch size is the numeric maximum count of responses a WCTP client (ACM Alert
Manager) expects from a WCTP poll request to a WCTP server (ACM Alert Communicator). A
common value is 500.
The WCTP version indicates the expected version of WCTP XML message content supported.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 196 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

4835 Table K.7-1: WCTP version values

Value Indicating WCTP version MCR support
wctp-dtd-v1r1 1.1 None
wctp-dtd-v1r2 1.2 Unpaired
wctp-dtd-v1r3 1.3 Paired
wctp-dtd-ihepcd-pcd06-v1r1 IHEPCD-PCD06-V1R1 Paired
wctp-dtd-ihepcd-pcd06-v1r2 IHEPCD-PCD06-V1R2 Paired

The WCTP DTD identifies the URL of the DTD (Data Type Definition) for the indicated
version of WCTP supported.

Table K.7-2: WCTP DTD values

Value Indicating WCTP version MCR support
http://dtd.wctp.org/wctp-dtd-v1r1.dtd 1.1 None
http://dtd.wctp.org/wctp-dtd-v1r2.dtd 1.2 Unpaired
http://dtd.wctp.org/wctp-dtd-v1r3.dtd 1.3 Paired
ftp://ftp.ihe.net/Patient_Care_Devices/Profiles/ACM/wct IHEPCD-PCD06-V1R1 Paired
p-dtd-ihepcd-pcd06-v1r1.dtd
ftp://ftp.ihe.net/Patient_Care_Devices/Profiles/ACM/wct IHEPCD-PCD06-V1R2 Paired
p-dtd-ihepcd-pcd06-v1r2.dtd

4840
The IHEPCD-PCD06-V1R1 value is used to signal the willingness of the Alert Communicator to
the Alert Manager to support communication of waveform evidentiary data and/or waveform
graphical snippets sent from the Alert Manager to the Alert Communicator in the PCD-06
message.
4845 The Next Poll Interval is the number of seconds the ACM Alert Manager (WCTP client) should
wait before again polling the ACM Alert Communicator (WCTP server). The ACM Alert
Communicator (WCTP server) dictates this value to reduce the aggregate polling load on the
WCTP server by all WCTP polling clients. Given that there are typically not many ACM Alert
Manager instances per ACM Alert Communicator instance, this interval can be kept to a small
4850 single digit number of seconds. In typical WCTP wide area communication deployments, there
are often hundreds if not maybe thousands of WCTP clients per WCTP server.
The graphics format and graphical image attachments are IHE PCD domain specific extensions
to WCTP version 1.3 to convey waveform graphical snippets.
The graphics format indicates the format of the graphical image information, and the value can
4855 be any one of SVG, JPEG, PNG, or BMP as agreed between the ACM Alert Manager vendor
and the ACM Alert Communicator vendor.
The graphical image is a base-64 encoded string representing one of the evidentiary data static
graphical images represented by one of the sets of evidentiary data from the ACM PCD-04
message sent from the ACM Alert Reporter to the ACM Alert Manager.
______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 197 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

4860 The telephony dial string is an encoded telephony dial string, including any required prefixes,
area codes, PBX switch hops, or pauses needed to permit the ACM Alert Communicator
endpoint communication device operator to make a telephone call from that device back to a
patient’s room or to the observation producer/order filler.
The status update is the string indicating the type of status update that the ACM Alert
4865 Communicator is reporting back to the ACM Alert Manager in wctp-Notification. Possible
values are as QUEUED, DELIVERED, or READ. Additionally there are the optional IHE PCD
ACM Profile specific values for IHEPCDCALLBACKSTART and IHEPCDCALLBACKEND
in support of Call Back Number phone dialing by the operator of the ACM Alert Communicator
endpoint communication device and the resulting telephony call start and call end, the status of
4870 which are useful as logged items in alert response analysis.
The Send Choice n is the prompt component of an MCR request. This is the value used by the
ACM Alert Communicator to populate buttons, softkeys, or menu choices on the endpoint
communication device for selection by the device operator. There can be multiple.
The Reply Choice n is the response value component of an MCR request. This value is
4875 correlated with its same ordinal occurrence Send Choice n value.
The response text is the string sent by the endpoint communication device of the ACM Alert
Communicator back to the ACM Alert Manager as the response to a notification message sent
from the ACM Alert Manager to the ACM Alert Communicator. In the case of an MCR response
the text can be predefined. In the case of non-MCR responses the text can be an unexpected
4880 value.
The actionURI is the optional URI value which can be included in paired and unpaired MCR
options. The URI will be opened on the endpoint communication device when the relevant MCR
Option is selected. The AC and AM should coordinate expected values.
The actionURIPurpose is the optional URI description field which provides additional
4885 descriptions of what the actionURI is to be used for. The element is required if an actionURI
element is included. The AC and AM should coordinate expected values.
The participant ID is the unique identifier of a participant in this alert indication as per the Alert
Communicator. The participant name is the name of the participant. The participant classification
is the type of the participant so that the Alert Communicator knows how to process the
4890 participant ID. The available values for classification are DEVICE, PATIENT, or STAFF. There
can be multiple wctp-IHEPCDACMParticipant elements.
The responder ID is the unique identifier of the person who is assigned to respond to this alert as
per the Alert Communicator. It is up to the Alert Communicator whether it chooses to use the
recipient PIN, the responder ID, or a combination of both to route messages.
4895 The location of an alert is defined by one or more location elements. These location elements are
modeled off of the FHIR®10 Location resource. There are attributes for the identifier, description,
type, and physical type. Refer to the FHIR standard for descriptions and available values of these
attributes.
10
FHIR is the registered trademark of Health Level Seven International.
______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 198 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

The alert timestamp is the timestamp for an alert indication according to the Alert Manager. This
4900 corresponds to a value in a Report Alert [PCD-04] transaction, but it is in the format of a WCTP
conformant timestamp (yyyy-mm-ddThh:mm:ss.tt). For more information, see Section B.8.7 in
the IHE PCD TF Volume 2.
The filler order number is the unique identifier for status updates to an alert indication. This
corresponds to a value in a Report Alert [PCD-04] transaction. For more information, see Section
4905 B.7.1 in the IHE PCD TF Volume 2.
The parent filler order number is the unique identifier for the original alert indication. This
corresponds to a value in a Report Alert [PCD-04] transaction. For more information, see Section
B.7.1 in the IHE PCD TF Volume 2.
The value is the numeric result of an alert. This corresponds to an observation in a Report Alert
4910 [PCD-04] transaction. For more information, see Section B.8.5 in the IHE PCD TF Volume 2.
Units is the measurement type of the value of an alert. This corresponds to an observation in a
Report Alert [PCD-04] transaction. For more information, see Section B.8.5 in the IHE PCD TF
Volume 2.
The reference range is the alert range set in the device. This corresponds to a value in a Report
4915 Alert [PCD-04] transaction. For more information, see Section B.8.5 in the IHE PCD TF Volume
2.
The abnormality type indicates the type of abnormality described by this alert. This corresponds
to an observation in a Report Alert [PCD-04] transaction. For more information, see Section
B.8.5 in the IHE PCD TF Volume 2.
4920 The event identification is the MDC event code for the alert. This corresponds to an observation
in a Report Alert [PCD-04] transaction. For more information, see Table B.8.5-1.
The source identification is the physiological measurement or technical source responsible for
the alert. This corresponds to an observation in a Report Alert [PCD-04] transaction. For more
information, see Table B.8.5-1.
4925 The event phase is whether the stimulus for the message is the beginning, end, or some other
state or state transition of the alert. This corresponds to an observation in a Report Alert [PCD-
04] transaction. An Alert Manager can use this field to inform an Alert Communicator that a
PCD-06 message was sent as a result of an escalation or deescalation. For more information, see
Table B.8.5-1.
4930 The alert state is the state of the underlying alert condition at the patient care device. This
corresponds to an observation in a Report Alert [PCD-04] transaction. For more information, see
Table B.8.5-1.
The inactivation state is whether or not visual or aural indications at the patient care device are
inactivated. This corresponds to an observation in a Report Alert [PCD-04] transaction. For more
4935 information, see Table B.8.5-1.
The alarm priority is the priority of an alert. This corresponds to an observation in a Report Alert
[PCD-04] transaction. For more information, see Table B.8.5-1.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 199 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

The alert type is the type of alert. This corresponds to an observation in a Report Alert [PCD-04]
transaction. For more information, see Table B.8.5-1.

4940 Table K.7-3: Mapping alert data elements to [PCD-04] transactions

Data elements PCD-04 location
Alert timestamp Either:

1. OBR-7

2. OBX-14
Filler order number OBR-3
Parent filler order number OBR-29
Value OBX-5 of OBX segment with Source Identification facet for alerts with a
type of Physiological
Units OBX-6 of OBX segment with Source Identification facet for alerts with a
type of Physiological
Reference range OBX-7 of OBX segment with Source Identification facet for alerts with a
type of Physiological
Abnormality type Either:

1. OBX-5 of OBX segment with Abnormality Type facet

2. Component of OBX-8 Abnormal Flags field of OBX segment with

Event Identification facet
Event identification OBX-5 of OBX segment with Event Identification facet
Source identification Either:

1. OBX-3 of OBX segment with Source Identification facet for alerts

with a type of Physiological

2. OBX-5 of OBX segment with Source Identification facet for other

alert types
Event phase OBX-5 of OBX segment with Event Phase facet
Alert state OBX-5 of OBX segment with Alert State facet
Inactivation state OBX-5 of OBX segment with Inactivation State facet
Alarm priority Either:

1. OBX-5 of OBX segment with Alarm Priority facet

2. Component of OBX-8 Abnormal Flags field of OBX segment with

Event Identification facet
Alert type Either:

1. OBX-5 of OBX segment with Alert Type facet

2. Component of OBX-8 Abnormal Flags field of OBX segment with

Event Identification facet
Location – Point of Care PV1-3.1 maps to a wctp-IHEPCDACMLocation element with a type
attribute of “HU” as defined in the FHIR
ServiceDeliveryLocationRoleType.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 200 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Data elements PCD-04 location

Location – Room PV1-3.2 maps to a wctp-IHEPCDACMLocation element with a physical
type attribute of “ro” as defined in the FHIR Location Physical Type value
set.
Location – Bed PV1-3.3 maps to a wctp-IHEPCDACMLocation element with a physical
type attribute of “bd” as defined in the FHIR Location Physical Type value
set.

The update action is the action that an ACM AC should take for a previous wctp-SubmitRequest
message. It is sent by an ACM Alert Manager to an ACM Alert Communicator. The available
values are CANCEL, ESCALATE, and DEESCALATE.

4945 K.8 WCTP client–server messages and responses

Sections are indicated as message classification – message type – usage indication
The message classification is either Administrative or the IHE PCD ACM message (PCD-06,
PCD-07, etc.)
The messages type is the WCTP interface specification operation types.
4950 The usage indication is used to distinctively indicate different uses for the same IHE PCD ACM
message, like when MCR is not supported, supported but unpaired, or supported and paired, or to
convey ACM Profile proprietary extensions to WCTP like those needed to convey alert
associated evidentiary information from the ACM Alert Manager to the ACM Alert
Communicator.

4955 K.8.1 Administrative – wctp-VersionQuery

This message is used to determine whether or not the WCTP server, the ACM Alert
Communicator, supports Multiple Choice Response (MCR) pairs on SubmitRequest messages.
See WCTP version above.

4960 <?xml version="1.0"?>

<!DOCTYPE wctp-Operation SYSTEM “WCTP DTD” >
<wctp-Operation wctpVersion=“WCTP version”>
<wctp-VersionQuery inquirer="push response URI" listDTDs="yes"/>
</wctp-Operation>

4965 K.8.2 Administrative – wctp-VersionResponse

This message is used when VersionQuery operation is not supported.

<?xml version="1.0"?>
<!DOCTYPE wctp-Operation SYSTEM “WCTP DTD”>
4970 <wctp-Operation wctpVersion=“WCTP version” wctpToken="11AA">
<wctp-Confirmation>
<wctp-Failure errorCode="300" errorText="Operation not supported.">

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 201 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

</wctp-Failure>
</wctp-Confirmation>
4975 </wctp-Operation>

The assumption to this response is that the ACM Alert Manager is to use only WCTP 1.1 XML
messages and not later, e.g., is no support for MCR.

K.8.3 Administrative – wctp-VersionResponse

4980 This message is used when Version Query operation is supported.
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE wctp-Operation SYSTEM “WCTP DTD”>
<wctp-Operation wctpVersion=“WCTP version”>
<wctp-VersionResponse inquirer="push response URI" responder="responder name"
4985 dateTimeOfRsp="timestamp" dateTimeOfReq="timestamp" invalidAfter="timestamp">
<wctp-ContactInfo email="e-mail address" phone="phone number" www="web site"
info="info string" />
<wctp-DTDSupport supportType="Supported" dtdName=“WCTP version” verToken="11AA" />
</wctp-VersionResponse>
4990 </wctp-Operation>

A response dtdName of "wctp-dtd-v1r3" indicates support for ACM Profile conformant WCTP
version 1.3 which indicates support for Multiple Choice Response (MCR) pairs on WCTP
SubmitRequest messages. MCR pairs are used to populate soft keys on wireless device operator
4995 interfaces and so that the reply value can be vendor specific and still be presented in a vendor
agnostic manner. A response of dtdName of "wctp-dtd-v1r2" indicates support for WCTP 1.2
which supports non-paired MCR.

K.8.4 IHE PCD-06 – wctp-SubmitRequest – no MCR

This message is used to send a message from the ACM Alert Manager to the ACM Alert
5000 Communicator when MCR is not to be indicated because this is either a test message or the
ACM Alert Communicator does not support MCR.

<?xml version="1.0"?>
<!DOCTYPE wctp-Operation SYSTEM “WCTP DTD”>
5005 <wctp-Operation wctpVersion=“WCTP version”>
<wctp-SubmitRequest>
<wctp-SubmitHeader submitTimestamp="timestamp">
<wctp-Originator senderID="sender ID" securityCode="security code"/>
<wctp-MessageControl messageID="message ID" transactionID="transaction ID"
5010 allowResponse="true" deliveryPriority="priority" notifyWhenDelivered="true"
preformatted="true"/>
<wctp-Recipient recipientID="recipient PIN"/>
</wctp-SubmitHeader>
<wctp-Payload>
5015 <wctp-Alphanumeric>notification text</wctp-Alphanumeric>

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 202 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

</wctp-Payload>
</wctp-SubmitRequest>
</wctp-Operation>

K.8.5 IHE PCD-06 – wctp-SubmitRequest – Unpaired MCR

5020 This message is used when the ACM Alert Manager wants to send a message to the ACM Alert
Communicator and while MCR is to be indicated the ACM Alert Communicator does not
support paired MCR so unpaired MCR is used.

<?xml version="1.0"?>
5025 <!DOCTYPE wctp-Operation SYSTEM “WCTP DTD”>
<wctp-Operation wctpVersion=“WCTP version”>
<wctp-SubmitRequest>
<wctp-SubmitHeader submitTimestamp="timestamp">
<wctp-Originator senderID="sender ID" securityCode="security code"/>
5030 <wctp-MessageControl messageID="message ID" transactionID="transaction ID"
allowResponse="true" deliveryPriority="priority" notifyWhenDelivered="true"
preformatted="true" notifyWhenRead="true"/>
<wctp-Recipient recipientID="recipient PIN"/>
</wctp-SubmitHeader>
5035 <wctp-Payload>
<wctp-MCR>
<wctp-MessageText>notification text</wctp-MessageText>
<wctp-Choice>Accept</wctp-Choice>
<wctp-Choice>Reject</wctp-Choice>
5040 <wctp-Choice actionURI="uriPrefix://action?id=123" actionURIPurpose=”purpose”
>Accept</wctp-Choice>
</wctp-MCR>
</wctp-Payload>
</wctp-SubmitRequest>
5045 </wctp-Operation>

When using unpaired MCR the wctp-Choice value selected by the endpoint device operator is
the response data from the WCTP server (the ACM Alert Communicator) back to the WCTP
client (the ACM Alert Manager).
5050 Selecting the wctp-Choice with the optional actionURI parameter included will indicate this
response back to the AM Actor and open the URI on the device.

K.8.6 IHE PCD-06 – wctp-SubmitRequest – Paired MCR

This message is used to send a message from the ACM Alert Manager to the ACM Alert
Communicator when the ACM Alert Communicator supports paired MCR.
5055
<?xml version="1.0"?>
<!DOCTYPE wctp-Operation SYSTEM “WCTP DTD”>
<wctp-Operation wctpVersion=“WCTP version”>

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 203 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

<wctp-SubmitRequest>
5060 <wctp-SubmitHeader submitTimestamp="timestamp">
<wctp-Originator senderID="sender ID" securityCode="security code"/>
<wctp-MessageControl messageID="message ID" transactionID="transaction ID"
allowResponse="true" deliveryPriority="priority" notifyWhenDelivered="true"
preformatted="true" notifyWhenRead="true"/>
5065 <wctp-Recipient recipientID="recipient PIN"/>
</wctp-SubmitHeader>
<wctp-Payload>
<wctp-MCR>
<wctp-MessageText>notification text</wctp-MessageText>
5070 <wctp-ChoicePair>
<wctp-SendChoice>Send Choice 1</wctp-SendChoice>
<wctp-ReplyChoice>Reply Choice 1</wctp-ReplyChoice>
</wctp-ChoicePair>
<wctp-ChoicePair>
5075 <wctp-SendChoice> Send Choice 2</wctp-SendChoice>
<wctp-ReplyChoice Reply Choice 2</wctp-ReplyChoice>
</wctp-ChoicePair>
<wctp-ChoicePair>
<wctp-SendChoice> Send Choice 3</wctp-SendChoice>
5080 <wctp-ReplyChoice> Reply Choice 3</wctp-ReplyChoice>
</wctp-ChoicePair>
<wctp-SendChoice actionURI="uriPrefix://action?id=123"
actionURIPurpose=”purpose” >Send Choice 1</wctp-SendChoice>
</wctp-MCR>
5085 </wctp-Payload>
</wctp-SubmitRequest>
</wctp-Operation>

When using a paired MCR the selectable values presented to the endpoint device operator are in
5090 the wctp-SendChoice elements. Once selected the correlated reply value sent to the WCTP client
(the ACM Alert Manager) is in the wctp-ReplyChoice element.
Selecting the wctp-SendChoice with the optional actionURI parameter included will indicate this
response back to the AM Actor and open the URI on the device.

K.8.7 IHE PCD-06 – wctp-SubmitRequest – Call Back Phone Number

5095 The following ACM Profile proprietary extensions to the wctp-SubmitRequest are used to
convey the HL7 Call Back Phone Number from the ACM Alert Manager to the ACM Alert
Communicator.
The WCTP 1.3r1 interface specification that is the basis for ACM Alert Manager – Alert
Communicator communication does not support the ability to pass other than a client request
5100 contact phone number in association with a message submit request. For this reason the ACM
Profile is required to extend the WCTP 1.3r1 interface specification in a backward transparent
manner in order to convey the HL7 Call Back Phone Number (OBR-17) from the ACM PCD-04

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 204 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

HL7 message received by the ACM Alert Manager from the ACM Alert Reporter for sending to
the ACM Alert Communicator.
5105 In order for the WCTP server (the ACM Alert Communicator) to signal its willingness to receive
and potentially support IHE ACM Profile evidentiary data extensions to WCTP 1.3r1, per the
extensions mechanism defined in Section 3.6 Protocol Version of the WCTP 1.3r1 interface
specification, the DTD response value shall be “wctp-dtd-ihepcd-pcd06-v1r1” to indicate support
for reception of the Call Back Phone Number extension to WCTP 1.3r1. This version shall
5110 presume at a minimum WCTP version 1.3r1 capabilities, with primary emphasis on the ability of
the WCTP server (ACM Alert Communicator) to support paired MCR if sent in a wctp-
SubmitRequest message from the WCTP client (the ACM Alert Manager) to the WCTP server
(the ACM Alert Communicator).
On wctp-SubmitRequest messages the WCTP 1.3r1 interface specification supports a choice of
5115 one of wctp-Alphanumeric (simple text with no MCR), wctp-TransparentData (binary encoded
data), or wctp-MCR (simple text accompanied with either unpaired or paired MCR). Since only
smarter devices, associated with the newest WCTP implementations, are expected to make use of
the additional alert evidentiary information in the PCD-06 transaction and so as to offload simple
non-MCR message WCTP implementations from having to ignore the extensions, the wctp-
5120 MCR element tree has been selected as the extension point for the WCM related additional XML
elements.
In order to pass the Call Back Phone Number used for the ACM nurse call use case for telephony
call back to the patient in the room, or for the ACM laboratory results/observations use case for
telephony call back to the results provider/order filler for any required results/observation read
5125 back, the following additional WCTP XML element is defined specifically to pass the telephony
dial back string from the ACM Alert Manager to the ACM Alert Communicator by means able
to be more deterministically referenced than simply including the string in the message text sent
to the endpoint communication device operator.
Telephony call back functionality can also be implemented via the actionURI element.
5130
<wctp-IHEPCDDialback String=”telephony dial string” />

K.8.8 IHE PCD-07 – Synchronous response to wctp-SubmitRequest – Received by

communications status update
This message is used by the ACM Alert Communicator to convey immediate request status
5135 responses to the ACM Alert Manager while the submit request initiating TCP connection is still
open. This is the means by which the PCD-07 status indication of Received by communications
(accepted by WCTP gateway) is conveyed from the ACM Alert Communicator to the ACM
Alert Manager.
The following is an indication of the successful queuing of a message from the ACM Alert
5140 Manager to the ACM Alert Communicator.

<?xml version="1.0"?>

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 205 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

<!DOCTYPE wctp-Operation SYSTEM “WCTP DTD”>

<wctp-Operation wctpVersion=“WCTP version” wctpToken="11AA">
5145 <wctp-Confirmation>
<wctp-Success successCode="200" successText="Accepted">comment</wctp-Success>
</wctp-Confirmation>
</wctp-Operation>

5150 The following is an indication of the failed attempt to queue a message from the ACM Alert
Manager to the ACM Alert Communicator.

<?xml version="1.0"?>
<!DOCTYPE wctp-Operation SYSTEM “WCTP DTD”>
5155 <wctp-Operation wctpVersion=“WCTP version” wctpToken="11AA">
<wctp-Confirmation>
<wctp-Failure errorCode="500" errorText="Timeout">comment</wctp-Failure>
</wctp-Confirmation>
</wctp-Operation>

5160
Refer to the WCTP interface specification for all possible values for successCode and
successText as well as errorCode and errorText.

K.8.9 wctp-PollForMessages – general poll (for Pre-Connectathon/Virtual

Connectathon testing)
5165 In a Pre-Connectathon or Virtual Connectathon environment where firewalls may not permit the
ACM Alert Communicator to post asynchronous status updates and replies across the Internet
there is a WCTP polling capability. As polling adds a potentially non-determinant delay in the
ACM Alert Manager – Alert Communicator interaction times the use of polling is not for use
during IHE Connectathon testing nor should it be used in live deployments where the non-
5170 determinant delay could increase patient safety risk.
The following poll is a general poll and not a poll for status or replies for any specific messages.

<?xml version="1.0"?>
<!DOCTYPE wctp-Operation SYSTEM “WCTP DTD”>
5175 <wctp-Operation wctpVersion=“WCTP version”>
<wctp-PollForMessages pollerID="poller ID" securityCode="security code"
maxMessagesInBatch="batch size"/>
</wctp-Operation>

K.8.10 wctp-PollResponse – general poll (for Pre-Connectathon/Virtual

5180 Connectathon testing)
This is the general poll response sent by the ACM Alert Communicator to the ACM Alert
Manager when the poll response is that no messages have status updates or replies.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 206 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

<?xml version="1.0"?>
5185 <!DOCTYPE wctp-Operation SYSTEM “WCTP DTD”>
<wctp-Operation wctpVersion="1.0">
<wctp-PollResponse minNextPollInterval=“Next Poll Interval”>
<wctp-NoMessages/>
</wctp-PollResponse>
5190 </wctp-Operation>

K.8.11 wctp-PollResponse message status update (for Pre-Connectathon/Virtual

Connectathon testing)
This is the general poll response sent by the ACM Alert Communicator to the ACM Alert
Manager when the poll response is that a message has a status update. The value of status
5195 update can be any of “QUEUED”, “DELIVERED”, or “READ”.

<?xml version="1.0"?>
<!DOCTYPE wctp-Operation SYSTEM “WCTP DTD”>
<wctp-Operation wctpVersion="1.0">
5200 <wctp-PollResponse minNextPollInterval=“Next Poll Interval”>
<wctp-Message sequenceNo="sequence number">
<wctp-StatusInfo>
<wctp-ResponseHeader responseToMessageID="message ID"
responseTimestamp="timestamp">
5205 </wctp-ResponseHeader>
<wctp-Notification type="status update" />
</wctp-StatusInfo>
</wctp-Message>
</wctp-PollResponse>
5210 </wctp-Operation>

K.8.12 wctp-PollResponse message status update acknowledgement (for Pre-

Connectathon/Virtual Connectathon testing)
This is the poll response acknowledgement message sent from the ACM Alert Manager back to
the ACM Alert Communicator to let the Alert Communicator know that the message status
5215 update has been successfully conveyed from the Alert Communicator to the Alert Manager and
that the Alert Communicator can discard status updates for the messages.

<?xml version="1.0"?>
<!DOCTYPE wctp-Operation SYSTEM “WCTP DTD”>
5220 <wctp-Operation wctpVersion=“WCTP version”>
<wctp-PollForMessages pollerID="poller ID" securityCode="security code"
maxMessagesInBatch="batch size">
<wctp-MessageReceived sequenceNo="sequence number">
<wctp-Success successCode="200" successText="Message accepted">comment</wctp-
5225 Success>
</wctp-MessageReceived>

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 207 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

</wctp-PollForMessages>
</wctp-Operation>

K.8.13 wctp-PollResponse (message reply, not in response to an MCR based

5230 wctp-SubmitRequest) (for Pre-Connectathon/Virtual Connectathon testing)
<?xml version="1.0"?>
<!DOCTYPE wctp-Operation SYSTEM “WCTP DTD”>
<wctp-Operation wctpVersion="1.0">
<wctp-PollResponse minNextPollInterval=“Next Poll Interval”>
5235 <wctp-Message sequenceNo="sequence number">
<wctp-MessageReply>
<wctp-ResponseHeader responseToMessageID="message ID"
responseTimestamp="timestamp">
</wctp-ResponseHeader>
5240 <wctp-Payload>
<wctp-Alphanumeric>response text</wctp-Alphanumeric>
</wctp-Payload>
</wctp-MessageReply>
</wctp-Message>
5245 </wctp-PollResponse>
</wctp-Operation>

K.8.14 IHE PCD-07 asynchronous status update (DELIVERED - delivery

confirmation)
The value of status update would be “DELIVERED”.
5250
<?xml version="1.0" encoding="utf-16"?>
<!DOCTYPE wctp-Operation SYSTEM “WCTP DTD”>
<wctp-Operation wctpVersion=“WCTP version”>
<wctp-StatusInfo>
5255 <wctp-ResponseHeader responseTimestamp="timestamp" respondingToTimestamp="timestamp"
onBehalfOfRecipientID="recipient PIN">
<wctp-Originator senderID="sender ID" />
<wctp-MessageControl messageID="message ID" transactionID="transaction ID" />
<wctp-Recipient authorizationCode="" />
5260 </wctp-ResponseHeader>
<wctp-Notification type="status update" />
</wctp-StatusInfo>
</wctp-Operation>

K.8.14 IHE PCD-07 asynchronous status update (READ - read receipt)

5265 The value of status update would be “READ”.

<?xml version="1.0" encoding="utf-16"?>

<!DOCTYPE wctp-Operation SYSTEM “WCTP DTD”>
<wctp-Operation wctpVersion=“WCTP version”>

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 208 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

5270 <wctp-StatusInfo>
<wctp-ResponseHeader responseTimestamp="timestamp" respondingToTimestamp="timestamp"
onBehalfOfRecipientID="recipient PIN">
<wctp-Originator senderID="sender ID" />
<wctp-MessageControl messageID="message ID" transactionID="transaction ID" />
5275 <wctp-Recipient authorizationCode="" />
</wctp-ResponseHeader>
<wctp-Notification type="status update" />
</wctp-StatusInfo>
</wctp-Operation>

5280 K.8.15 IHE PCD-07 asynchronous reply message with MCR and URI response
<?xml version="1.0" encoding="utf-16"?>
<!DOCTYPE wctp-Operation SYSTEM “WCTP DTD”>
<wctp-Operation wctpVersion=“WCTP version”>
<wctp-MessageReply MCRMessageReply="true">
5285 <wctp-ResponseHeader responseToMessageID="message ID" responseTimestamp="timestamp"
respondingToTimestamp="timestamp" onBehalfOfRecipientID="recipient PIN">
<wctp-Originator senderID="sender ID" miscInfo="" />
<wctp-MessageControl messageID="message ID" transactionID="transaction ID" />
<wctp-Recipient recipientID="recipient PIN" />
5290 </wctp-ResponseHeader>
<wctp-Payload>

<wctp-Alphanumeric actionURIPurpose=”purpose”>response text</wctp-Alphanumeric>

</wctp-Payload>
5295 </wctp-MessageReply>
</wctp-Operation>

K.8.16 IHE PCD specific WCTP extensions to PCD-06 wctp-SubmitRequest for

WCM attachments
WCTP is a text messaging protocol which doesn’t support attachments or graphical images and
5300 whose maximum message length is restricted. The IHE PCD domain has extended WCTP 1.3 to
support optional attachments as either the ACM [PCD-04] transaction in its entirety and/or as
one or more graphical snippet attachments in support of the Waveform Content Module (WCM)
capability. This in turn presumes removal of the message length restriction.
The WCTP 1.3r1 interface specification that is the basis for ACM Alert Manager – Alert
5305 Communicator communication supports neither non-plain text messages (encoded attachments)
in addition to plain text messages or transmissions of graphical images in addition to plan text
messages. For this reason the ACM Profile is required to extend the WCTP 1.3r1 interface
specification in a backward transparent manner in order to convey the HL7 evidentiary data
associated with WCM (for ECG waveform graphic generation by the ACM Alert
5310 Communicator) or to convey a graphical image of the HL7 evidentiary data as produced by the
ACM Alert Manager for delivery to an ACM Alert Communicator that has not implemented the
algorithms for synthesis of the graphic from the evidentiary data.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 209 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

In order for the WCTP server (the ACM Alert Communicator) to signal its willingness to receive
and potentially support these IHE ACM Profile WCM specific extensions to WCTP 1.3r1, per
5315 the extensions mechanism defined in Section 3.6 Protocol Version of the WCTP 1.3r1 interface
specification, the DTD response value shall be “wctp-dtd-ihepcd-pcd06-v1r1” to indicate support
for reception of either or both of the PCD-04 (HL7 evidentiary data) or a graphical image
representative of the evidentiary data and for removal of the maximum message length
restriction. This version shall presume at a minimum WCTP version 1.3r1 capabilities, with
5320 primary emphasis on the ability of the WCTP server (ACM Alert Communicator) to support
paired MCR if sent in a wctp-SubmitRequest message from the WCTP client (the ACM Alert
Manager) to the WCTP server (the ACM Alert Communicator).
On wctp-SubmitRequest messages the WCTP 1.3r1 interface specification supports a choice of
one of wctp-Alphanumeric (simple text with no MCR), wctp-TransparentData (binary encoded
5325 data), or wctp-MCR (simple text accompanied with either unpaired or paired MCR). Since only
smarter devices, associated with the newest WCTP implementations, are expected to make use of
the additional WCM information in the [PCD-06] transaction and so as to offload simple non-
MCR message WCTP implementations from having to ignore the extensions, the wctp-MCR
element tree has been selected as the extension point for the WCM related additional XML
5330 elements.
<wctp-IHEPCD04 xmlns=”urn:ihe:pcd:acm:2015">
IHE PCD-04 HL7 message
</wctp-IHEPCD04>

5335 <wctp-IHEPCDWCMImages>
<wctp-IHEWCMImage Format=”graphics format” Encoding=”base64”>
graphical image
</wctp-IHEWCMImage>
</wctp-IHEPCDWCMImages >
5340
The IHE PCD-04 HL7 message may or may not contain WCM evidentiary data, but it is
expected to contain ACM alarm indication data.
Since a single PCD-04 WCM extension can result in more than a single graphics image the wctp-
IHEWCMImage can be repeated. Due to endpoint communication device display real estate
5345 limitations the ACM Alert Communicator may not be able to display all of the images presented
to it by the ACM Alert Manager, but shall present the images starting with the first for as many
as the ACM Alert Communicator supports for the given endpoint communication device.
Whether or not the ACM Alert Manager sends the rendered images to the ACM Alert
Communicator is ACM Alert Manager vendor specific.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 210 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

5350 The Format specification is required, indicates the format of the graphical image information,
and the value can be any one of SVG, JPEG, PNG, or BMP as agreed between the ACM Alert
Manager vendor and the ACM Alert Communicator vendor.
If the ACM Alert Communicator does not respond to the wctp-VersionQuery with the WCM
supportive DTD response indicating value then the Alert Manager shall not send these
5355 extensions to the Alert Communicator.

K.8.17 IHE PCD specific WCTP extensions to wctp-SubmitRequest for alert

information
The following ACM Profile proprietary extensions to the wctp-SubmitRequest are used to
convey alert information from the ACM AM to the ACM AC.
5360 The WCTP 1.3r1 interface specification that is the basis for ACM AM – AC communication
does not support the ability to pass alert information in association with a message submit
request. For this reason, the ACM Profile is required to extend the WCTP 1.3r1 interface
specification in a backward transparent manner in order to convey alert information from the
ACM AM to the ACM AC.
5365 In order for the WCTP server (the ACM AC) to signal its willingness to receive and potentially
support IHE ACM Profile evidentiary data extensions to WCTP 1.3r1, per the extensions
mechanism defined in Section 3.6 Protocol Version of the WCTP 1.3r1 interface specification,
the DTD response value shall be “wctp-dtd-ihepcd-pcd06-v1r2” to indicate support for reception
of the alert information extension to WCTP 1.3r1. This version shall presume at a minimum
5370 WCTP version 1.3r1 capabilities, with primary emphasis on the ability of the WCTP server
(ACM AC) to support paired MCR if sent in a wctp-SubmitRequest message from the WCTP
client (the ACM AM) to the WCTP server (the ACM AC). This version also includes all optional
features present in IHEPCD-PCD06-V1R1.
On wctp-SubmitRequest messages the WCTP 1.3r1 interface specification supports a choice of
5375 one of wctp-Alphanumeric (simple text with no MCR), wctp-TransparentData (binary encoded
data), or wctp-MCR (simple text accompanied with either unpaired or paired MCR). Since only
smarter devices, associated with the newest WCTP implementations, are expected to make use of
the additional alert evidentiary information in the [PCD-06] transaction and so as to offload
simple non-MCR message WCTP implementations from having to ignore the extensions, the
5380 wctp-MCR element tree has been selected as the extension point for additional XML elements.
<wctp-IHEPCDACM>
<wctp-IHEPCDACMParticipants>
<wctp-IHEPCDACMParticipant
participantID=“participantID”
5385 name=“participantName”
classification=“participantClassification” />
</wctp-IHEPCDACMParticipants>

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 211 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

<wctp-IHEPCDACMLocations>
<wctp-IHEPCDACMLocation
5390 identifier=“identifier”
description=“description”
type=“type”
physicalType=“physicalType” />
</wctp-IHEPCDACMLocations>
5395 <wctp-IHEPCDACMResponder
responderID=“responderID” />
<wctp-IHEPCDACMObservation
alertTimestamp=“alertTimestamp”
fillerOrderNumber=“fillerOrderNumber”
5400 parentFillerOrderNumber=“parentFillerOrderNumber”
value=“value”
units=“units”
referenceRange=“referenceRange”
abnormalityType=“abnormalityType”
5405 eventIdentification=“eventIdentification”
sourceIdentification=“sourceIdentification”
eventPhase=“eventPhase”
alertState=“alertState”
inactivationState=“inactivationState”
5410 alarmPriority=“alarmPriority”
alertType=“alertType” />
<wctp-IHEPCDACMPresentation presentationID=“presentationID” />
</wctp-IHEPCDACM>
This extension is optional. If it is present, then the ACM AC can use these values to present
5415 additional information to users or categorize PCD-06 messages more effectively.
All of the elements and attributes within this extension are optional. However, the ACM AC can
require elements and attributes in this extension if they are necessary to ensure complete
functionality. If these elements and attributes are not present, then the message will not be
queued.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 212 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

5420 These values are not required to be pulled directly from a PCD-04 message and can instead be
used by an Alert Manager to send additional information to an Alert Communicator.
If there is patient information sent in the PCD-06 message, Alert Managers and Alert
Communicators should take care to secure their communications using existing WCTP
methodologies.
5425 If the ACM AC does not respond to the wctp-VersionQuery with the supportive DTD response
indicating value then the AM shall not send these extensions to the AC.

K.8.18 IHE PCD specific WCTP extensions to PCD-07 transactions for alerts
The following ACM Profile proprietary extensions to wctp-StatusInfo and wctp-MessageReply
are used to convey alert information from the ACM AC to the ACM AM.
5430 The WCTP 1.3r1 interface specification that is the basis for ACM AM – AC communication
does not support the ability to pass alert information in association with a status info response or
message reply. For this reason, the ACM Profile is required to extend the WCTP 1.3r1 interface
specification in a backward transparent manner in order to convey alert information from the
ACM AC to the ACM AM.
5435 In order for the WCTP server (the ACM AC) to signal its willingness to send and potentially
support IHE ACM Profile evidentiary data extensions to WCTP 1.3r1, per the extensions
mechanism defined in Section 3.6 Protocol Version of the WCTP 1.3r1 interface specification,
the DTD response value shall be “wctp-dtd-ihepcd-pcd06-v1r2” to indicate support for sending
the alert information. This version shall presume at a minimum WCTP version 1.3r1 capabilities.
5440 The wctp-StatusInfo and wctp-MessageReply element trees have been selected as the extension
point for additional XML elements.
<wctp-IHEPCDACM>
<wctp-IHEPCDACMResponder
onBehalfOfResponderID=“responderID” />
5445 </wctp-IHEPCDACM>
This extension is optional and can be used to convey additional information from the ACM AC
to the ACM AM that is not in present in WCTP version 1.3r1.
All of the elements and attributes within this extension are optional. However, the ACM AM can
require elements and attributes in this extension if they are necessary to ensure complete
5450 functionality. If these elements and attributes are not present, then the message will not be
queued.
These values are not required to be pulled directly from a PCD-06 message and can instead be
used by an Alert Communicator to send additional information to an Alert Manager.
If the ACM AC does not respond to the wctp-VersionQuery with the supportive DTD response
5455 indicating value then the AC shall not send these extensions to the AM.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 213 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

K.8.19 IHE PCD-06 wctp-IHEPCDSubmitRequestUpdate

The following ACM Profile proprietary message type, wctp-IHEPCDSubmitRequestUpdate, is
used by the ACM AM to update prior PCD-06 wctp-SubmitRequest messages on the ACM AC.
The WCTP 1.3r1 interface specification that is the basis for ACM AM – AC communication
5460 does not support the ability for an AM to send the AC updates to previous wctp-SubmitRequest
messages. For this reason, the ACM Profile is required to extend the WCTP 1.3r1 interface
specification in a backward transparent manner in order for the AM to send updates to the AC.
In order for the WCTP server (the ACM AC) to signal its willingness to receive and potentially
support IHE ACM Profile evidentiary data extensions to WCTP 1.3r1, per the extensions
5465 mechanism defined in Section 3.6 Protocol Version of the WCTP 1.3r1 interface specification,
the DTD response value shall be “wctp-dtd-ihepcd-pcd06-v1r2” to indicate support for receiving
updates to previous wctp-SubmitRequest messages. This version shall presume at a minimum
WCTP version 1.3r1 capabilities.
This update functionality will be encapsulated in a new element under wctp-Operation.
5470 <?xml version=“1.0”?>
<!DOCTYPE wctp-Operation SYSTEM “WCTP DTD”>
<wctp-Operation wctpVersion=“WCTP version”>
<wctp-IHEPCDSubmitRequestUpdate>
<wctp-SubmitHeader submitTimestamp=“timestamp”>
5475 <wctp-Originator
senderID=“sender ID”
securityCode=“security code”/>
<wctp-MessageControl
messageID=“message ID”
5480 transactionID=“transaction ID”
allowResponse=“true”
deliveryPriority=“priority”
notifyWhenDelivered=“false”
preformatted=“true”
5485 notifyWhenRead=“false”/>
<wctp-Recipient recipientID=“recipient PIN”/>
</wctp-SubmitHeader>
<wctp-Payload>
<wctp-IHEPCDUpdate>

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 214 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

5490 <wctp-IHEPCDMessageToUpdate
messageToUpdate=“message ID”/>
<wctp-IHEPCDUpdateAction
action=“update action”/>
<wctp-IHEPCDACMResponder
5495 responderID=“responderID”/>
</wctp-IHEPCDUpdate>
</wctp-Payload>
</wctp-IHEPCDSubmitRequestUpdate>
</wctp-Operation>
5500 This extension is optional and can be used by the AM to send updates about prior PCD-06
SubmitRequest messages to the AC. The elements wctp-IHEPCDMessageToUpdate and wctp-
IHEPCDUpdateAction are required if this message type is used.
Each wctp-IHEPCDSubmitRequestUpdate message contains a unique message ID that is
different from the ID of the message that it intends to update. The previous wctp-SubmitRequest
5505 message is identified by its message ID, located in the wctp-IHEPCDMessageToUpdate element.
Each wctp-IHEPCDSubmitRequestUpdate message updates one previous wctp-SubmitRequest
message.
The kind of action that must be done by the ACM AC is specified by the value in the wctp-
IHEPCDUpdateAction element. It is up to the AC to determine what this action means in the
5510 context of their system.
In response to this message, the ACM AC is expected to send a synchronous PCD-07 response to
convey success or failure of message queueing as described in Section K.8.8. No asynchronous
responses will be sent because of this message.
If the ACM AC does not respond to the wctp-VersionQuery with the supportive DTD response
5515 indicating value then the AM shall not send this message type to the AC.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 215 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Appendix L - Alert (Alarm) Fatigue

Root causes of alert (alarm) fatigue are numerous. Many can be mitigated without automation,
such as ECG lead placement and maintenance management.
Even when ACM based automated alert notifications are deployed there can even be increased
5520 alert fatigue due to the dissemination of alerts to too many individuals or too many different
types of alerts to individuals. Assessment and reduction of over alerting typically requires a
hospital or care unit focused investigative team to gather evidentiary information to specifically
identify which alerts are to be disseminated and specifically to which job roles or individuals as
these change quite often with staff shift changes and dynamically with staff member breaks,
5525 tasking availability and communication accessibility.
Alert Source devices and gateways as ACM Alert Reporter (AR) actors can utilize the ACM
Report Alert (PCD-04) transaction that it sends to the Alert Manager (AM) as a means of
reducing alert audio in care units and across hospitals. The AR can maintain awareness of AR-
AM infrastructure usability by sending short duration periodic PCD-04 messages with minimal
5530 content which the AM can minimally process and acknowledge as successfully received back to
the AR. This forms an Alert Reporter to Alert Manager application level keep-alive mechanism.
This provides the AR with a degree of confidence that the AM can receive and can request
dissemination of alert notifications. This confidence can form the basis of temporarily holding
off on activating the Alert Source local alarm audio if the AM has received and acknowledged
5535 the Report Alert (PCD-04) transaction. The hold off delay period would be Alert Source
managed and would likely be alert type specific. If there is no active keep-alive or if the AM
responds with negative acknowledgement or if the AM doesn’t respond within a small single
digit number of seconds the alert source would activate its local alarm audio. Even if the AM
acknowledges receipt of the PCD-04 transaction the Alert Source can still maintain an
5540 expectation of timeliness of alert resolution at the source and if not resolved within the expected
period of time could activate its local alarm audio.
If the Alert Reporter (AR) and Alert Manager (AM) implement the optional Report Alert
Dissemination Status (PCD-05) transaction then additional information is available for the AR to
mitigate alert fatigue. When the AM sends the Disseminate Alert (PCD-06) transaction to the
5545 Alert Communicator (AC) there is a short turnaround acknowledgement by the AC back to the
AM that the alert dissemination request has been successfully received. A PCD-05 message
indicating this could be used, with appropriate watchdog timer, to hold off activation of source
local alert audio as confirmation that the alert has been forwarded to a dissemination solution.
This hold infraoff can be further extended if the AC implementation includes support for
5550 delivery confirmation, read receipt, and operator accept/reject signaling. If an alert notification
successfully makes it all the way to an assigned clinician and that clinician read the alert
notification and responds to it with accept that can further hold off activation of the local alarm
audio.
When ACM actors are used in conjunction with actors from other IHE profiles, such as Medical
5555 Equipment Management Location Services (MEMLS) alert dissemination can be further
managed in an automated manner. If the AM additionally implements a Location Observation
Consumer (LOC) then when location observations are reported for staff and equipment the AM

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 216 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

becomes aware of them. As alert dissemination destinations (clinicians) move out of and into
range of known wireless communication attenuation zones the AM could automatically adjust
5560 alert dissemination destinations. Through the above deployment efforts, alert (alarm) audio and
its associated fatigue can be significantly mitigated without new communication protocols or
profiles.
These are the key points.
1. The Alert Source always controls its own local alarm audio state, pause, end or extension
5565 of a pause.
2. The Alert Source and the Alert Reporter (AR) can use the available context and received
triggers to make decisions regarding the audio state.
3. In this scenario a local alarm is not cleared by a remote actor.
4. Only local resolution of the alerting condition can locally clear the alert.
5570 5. This scenario does not comment regarding the state of other cues (visual, haptic).

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 217 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Appendix M Infusion Pump Events

This appendix is intended to provide background information to support a mechanism for the
transmission of event information for infusion pumps. Common infusion modalities for infusion
5575 pumps may include continuous, piggyback, bolus, multi-step, and intermittent functionality. A
major challenge in reporting infusion pump events is that although pumps are able to report
programmed and operational parameters, they are typically not “aware” of how or why they are
being used clinically. In medical environments there are an enormous number of use cases for
administering an infusion using a pump. Even a routine delivery of an amount of fluid may
5580 involve several instances where the infusion is paused or stopped and then restarted (either
within seconds or after several hours or more). The infusion rate may be changed, or an alarm
may cause the infusion to stop until the alarm is addressed. For various practical and clinical
reasons, the values programmed on the pump by the clinician may not relate to the volume that
the physician ordered, the actual volume of the fluid container that was hung, or the rate at which
5585 the infusion was ordered.
All current pump systems do not report event information the same way. The same information
may be represented differently, or a different set of information may be reported. Information
may be reported periodically or episodically, but not in accordance with a common specification.
As a result, a decision has been made to standardize a small number of basic operational events.
5590 In combination with pump mode and status information, these can be used to express the various
key operational components of an infusion over time. Systems that receive event information,
such as EMR or BCMA systems, have the clinical/medication order information and will need to
reconcile the reported operational events with this information.

M.1 Basic Infusion Events

5595 It may be helpful to think of an infusion as a series of delivery segments, each of which is
bounded by one of the following events:
• Delivery Start
• Delivery Stop
• Delivery Complete
5600 There are also several other operational events not related to fluid delivery:
• Communication Status Change – communication between pump and gateway is lost or
resumed
• Program Cleared – pump settings are cleared (indicating that a new program will be
initiated)
5605 • Auto-Program Cleared – an auto-program was received on the pump but the programmed
settings were cleared on the pump prior to starting delivery
• Patient Change
• Patient ID Change

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 218 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

• Patient Parameter Change (e.g., weight, height, BSA)

5610 • Pump Volume Counters Cleared
• Device Time Changed
The following diagram illustrates a typical scenario where a bag of fluid is infused and a rate
change is made:
• An infusion is started at 75 mL/hr. A volume to be infused is programmed (not shown).
5615 • After a period of time the infusion is stopped (paused), perhaps in order to move the
patient.
• The infusion is resumed at 100 mL/hr.
• The programmed volume to be infused is met (delivery is complete).
• Pump switches to KVO (keep vein open) mode.
5620 • Pump is stopped.

Figure M.1-1: Infusion with a Rate Change

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 219 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

5625 M.1.1 Event Message – PCD-10 Communicate Infusion Event Data

The structure of the message differs from the PCD-01 message (ORU^R01) in the following
ways
• MSH-9.2 contains a new trigger event code (R42) assigned for infusion event data.
• MSH-21.3 contains the PCD-10 unique profile identifier. The OID identifier assigned to
5630 PCD-10 is “1.3.6.1.4.1.19376.1.6.4.10”.
Each PCD-10 message contains only information relevant to the specific device and fluid source
on which the event occurred. Each PCD-10 message contains a single event. Only information
pertinent to the event is included.

M.1.2 Infusion Pump Events

5635 Table M.1.2-1: Infusion Pump Events

Event MDC Code Required by Profile

Delivery Start MDC_EVT_PUMP_DELIV_START Yes

Delivery Stop MDC_EVT_PUMP_DELIV_STOP Yes

Delivery Complete MDC_EVT_PUMP_DELIV_COMP Yes

Communication Status
MDC_EVT_COMM_STATUS_CHANGE No
Change

Program Cleared MDC_EVT_PUMP_PROG_CLEARED No

Auto-Program Cleared MDC_EVT_PUMP_AUTO_PROG_CLEARED No

Patient Change MDC_EVT_PATIENT_CHANGE No

Patient ID Change MDC_EVT_PATIENT_ID_CHANGE No

Patient Parameter
MDC_EVT_PATIENT_PARAMETER_CHANGE No
Change
Pump Volume Counters
MDC_EVT_PUMP_VOL_COUNTERS_CLEARED No
Cleared

Device Time Changed MDC_EVT_DEVICE_TIME_CHANGED No

M.1.2.1 Infusion Event Parameters

Infusion Event Parameters are defined in separate Infusion Pump Model and Infusion Pump
Terms documents. Current versions of these documents can be found on the IHE Patient Care
______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 220 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

5640 Devices Wiki page entitled “PCD Reference Pages”

(http://wiki.ihe.net/index.php?title=Category:PCD_Reference_Pages).
The names of the infusion pump event parameters that are used in subsequent tables correspond
to MDC codes as shown in Table M.1.2.1-1 below:

Table M.1.2.1-1: Mapping of Infusion Pump Event Parameters to MDC Codes

Parameter MDC Code

Pump Delivery Info Parameters:

Infusing Status MDC_PUMP_INFUSING_STATUS

Current Pump Fluid Flow MDC_FLOW_FLUID_PUMP_CURRENT
Pump Active Sources MDC_DEV_PUMP_ACTIVE_SOURCES

Active Source Parameters:

Current Delivery Status MDC_DEV_PUMP_CURRENT_DELIVERY_STATUS

Program Delivery Mode MDC_DEV_PUMP_PROGRAM_DELIVERY_MODE
Pump Not Delivering Reason MDC_DEV_PUMP_NOT_DELIVERING_REASON
Source Channel Label MDC_DEV_PUMP_SOURCE_CHANNEL_LABEL
Rate MDC_FLOW_FLUID_PUMP
Dose Rate MDC_RATE_DOSE
Volume Programmed MDC_VOL_FLUID_TBI
Current Segment Volume Delivered MDC_VOL_FLUID_DELIV_SEGMENT
Cumulative Volume Delivered MDC_VOL_FLUID_DELIV_TOTAL
Volume Remaining MDC_VOL_FLUID_TBI_REMAIN
Time Remaining MDC_TIME_PD_REMAIN

5645
For IPEC delivery events, the DOR should send all parameters that are known for the infusion.
The following table outlines the parameters that are typically sent with each Delivery Start, Stop,
and Complete event, with additional constraints as noted. Refer to the Infusion Pump Model and
Infusion Pump Terms documents for the other parameters that may be reported with each event.

5650 Table M.1.2.1-2: Infusion Pump Delivery Event Parameters

PARAMETER NOTES
Pump Delivery Info Parameters:
Infusing Status Required for Delivery Start, Stop, and Complete.
Current Pump Fluid
Required for Delivery Start, Stop, and Complete.
Flow
Pump Active
Required for Delivery Start, Stop, and Complete.
Sources

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 221 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

PARAMETER NOTES
Active Source Parameters:
Current Delivery
Required for Delivery Start, Stop, and Complete.
Status
Program Delivery
Required for Delivery Start, Stop, and Complete.
Mode
Pump Not Required for Delivery Stop and Delivery Complete if Current Delivery Status =
Delivering Reason pump-delivery-status-not-delivering; not applicable for Delivery Start.
Source Channel
Required for Delivery Start, Stop, and Complete.
Label
Current Segment
For Delivery Stop and Delivery Complete, either this parameter or Cumulative
Volume Delivered
Note 1 Volume Delivered is required; optional for Delivery Start.

Cumulative Volume For Delivery Stop and Delivery Complete, either this parameter or Current
Delivered Note 1 Segment Volume Delivered is required; optional for Delivery Start.

Note 1: When Pump Active Sources is primary or secondary, this parameter is reported under the corresponding containment
group. When Pump Active Sources is PCA, loading, clinician, or intermittent, this parameter is reported under the
containment group for the fluid source (primary or secondary).

5655 The following table outlines the parameters that are sent with the Communication Status Change
event.

Table M.1.2.1-3: Infusion Pump Communication Status Change Event Parameters

PARAMETER NOTES
Communication Status Required.

Table M.1.2.1-4: Clinical Scenarios describes the mapping of clinical scenarios to pump events.
5660 Notes:
• The term “delivery segment” refers to the period between a
MDC_EVT_PUMP_DELIV_START event and the next
MDC_EVT_PUMP_DELIV_STOP or MDC_EVT_PUMP_DELIV_COMP event
• Although the Pump Active Sources parameters can identify multiple sources, there is
5665 only one active source at a given time in each of the scenarios in the table
• For Pump Active Sources, the value “pump-source-info-*” indicates that either pump-
source-info-primary or pump-source-info-secondary is a valid value for the event
• When Pump Active Sources is one of the following:
o pump-source-info-pca
5670 o pump-source-info-loading
o pump-source-info-clinician

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 222 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

o pump-source-info-intermittent
parameter values specific to that dose are reported within a corresponding containment
group (reflected in the scenarios as “Active Source Parameters (pump-source-info-...)".
5675 Parameters that apply to the overall delivery for the active fluid source (such as
Cumulative Volume Delivered) are reported within a separate containment group for that
source (reflected in the scenarios as “Source Parameters (primary or secondary)”).
• Source Channel Label is assigned a vendor-specific value (e.g., “primary” or
“secondary”, ‘A’ or ‘B’, etc.). This is especially useful when Pump Active Sources is not
5680 pump-source-info-primary or pump-source-info-secondary (e.g., during a bolus). In that
case, the source for the bolus can be identified via Source Channel Label.
• The value of pump-delivery-status-transitioning for Current Delivery Status is applicable
to transitional stop and complete events in cases where the medication or fluid associated
with the source will continue to be delivered after the transition (e.g., to/from bolus, to
5685 KVO, titration, etc.). It should not be used for transitions from piggyback to primary.
• For events where Current Delivery Status = pump-delivery-status-transitioning, the
values for Infusing Status and Current Pump Fluid Flow must be consistent; i.e., either:
o Infusing Status = pump-status-infusing and Current Pump Fluid Flow > 0, or
o Infusing Status = pump-status-not-infusing and Current Pump Fluid Flow = 0
5690 In the scenarios, the terms “pump reported status” and “pump reported rate” are used in
place of actual values to indicate that it is vendor-specific as to which of these two
combinations of values will be reported.
• Additional clinical scenarios will be added to this table as they are identified.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 223 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

5695 Table M.1.2.1-4: Clinical Scenarios

Clinical
PCD-10 Event Parameters Discussion
Scenario
New infusion MDC_EVT_PUMP_DELIV Pump Delivery Info Parameters: Depending on pump
start, followed _ START Infusing Status=pump-status-infusing make/model, Rate
by eventual Current Pump Fluid Flow=programmed may not be specific to
transition to rate KVO rate and
KVO, volume infused may
followed by Pump Active Sources=pump-source-info-* continue to increase
transition after the transition to
from KVO to Active Source Parameters: KVO even though the
paused Current Delivery Status=pump-delivery- VTBI has been met
status-delivering
Program Delivery Mode=pump-program-
delivery-mode-continuous
Source Channel Label=vendor-specific
Rate=programmed rate
Dose Rate=programmed dose rate
Volume Programmed=volume
programmed
Current Segment Volume Delivered=0
Cumulative Volume Delivered=0
Volume Remaining=volume programmed
Time Remaining=based upon Volume
Remaining and Rate
MDC_EVT_PUMP_DELIV Pump Delivery Info Parameters:
_ COMP Infusing Status=pump reported status
Current Pump Fluid Flow=pump reported
rate
Pump Active Sources=pump-source-info-*

Active Source Parameters:

Current Delivery Status=pump-delivery-
status-transitioning
Program Delivery Mode=pump-program-
delivery-mode-continuous
Source Channel Label=vendor-specific
Rate=programmed rate
Dose Rate=programmed dose rate
Volume Programmed=volume
programmed
Current Segment Volume Delivered=
volume programmed
Cumulative Volume Delivered=volume
programmed
Volume Remaining=0
Time Remaining=0

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 224 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Clinical
PCD-10 Event Parameters Discussion
Scenario
MDC_EVT_PUMP_DELIV Pump Delivery Info Parameters:
_ START Infusing Status=pump-status-infusing
Current Pump Fluid Flow=KVO rate
Pump Active Sources=pump-source-info-*

Active Source Parameters:

Current Delivery Status=pump-delivery-
status-kvo
Program Delivery Mode=pump-program-
delivery-mode-continuous
Source Channel Label=vendor-specific
Rate=KVO rate
Dose Rate=n/a
Volume Programmed=0
Current Segment Volume Delivered=0
Cumulative Volume Delivered=volume
programmed
Volume Remaining=0
Time Remaining=0
MDC_EVT_PUMP_DELIV Pump Delivery Info Parameters:
_ STOP Infusing Status=pump-status-not-infusing
Current Pump Fluid Flow=0
Pump Active Sources=pump-source-info-*

Active Source Parameters:

Current Delivery Status=pump-delivery-
status-not-delivering
Pump Not Delivering Reason=either pump-
stopped-by-clinician or pump-stopped-not-
specified
Program Delivery Mode=pump-program-
delivery-mode-continuous
Source Channel Label=vendor-specific
Rate=KVO rate
Dose Rate=n/a
Volume Programmed=0
Current Segment Volume Delivered=
volume delivered since last
DELIV_START
Cumulative Volume Delivered=volume
programmed plus the amount delivered
during KVO
Volume Remaining=0
Time Remaining=0

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 225 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Clinical
PCD-10 Event Parameters Discussion
Scenario
Start/restart an MDC_EVT_PUMP_DELIV Pump Delivery Info Parameters:
infusion, _ START Infusing Status=pump-status-infusing
followed by Current Pump Fluid Flow=programmed
pausing the rate
running
infusion Pump Active Sources=pump-source-info-*

Active Source Parameters:

Current Delivery Status=pump-delivery-
status-delivering
Program Delivery Mode=pump-program-
delivery-mode-*
Source Channel Label=vendor-specific
Rate=programmed rate
Dose Rate=programmed dose rate
Volume Programmed=volume
programmed
Current Segment Volume Delivered=0
Cumulative Volume Delivered=sum of
“Current Segment Volume Delivered”
values across all segments for the delivery
prior to this one
Volume Remaining=volume remaining
Time Remaining=based upon Volume
Remaining and Rate

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 226 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Clinical
PCD-10 Event Parameters Discussion
Scenario
MDC_EVT_PUMP_DELIV Pump Delivery Info Parameters:
_ STOP Infusing Status=pump-status-not-infusing
Current Pump Fluid Flow=0
Pump Active Sources=pump-source-info-*

Active Source Parameters:

Current Delivery Status=pump-delivery-
status-not-delivering
Pump Not Delivering Reason=either pump-
stopped-by-clinician or pump-stopped-not-
specified
Program Delivery Mode=pump-program-
delivery-mode-*
Source Channel Label=vendor-specific
Rate=programmed rate
Dose Rate=programmed dose rate
Volume Programmed=volume
programmed
Current Segment Volume
Delivered=volume delivered since last
DELIV_START
Cumulative Volume Delivered=sum of
“Current Segment Volume Delivered”
values across all segments for the delivery,
including the one just completed
Volume Remaining=volume remaining
Time Remaining=based upon Volume
Remaining and Rate

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 227 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Clinical
PCD-10 Event Parameters Discussion
Scenario
Rate Change MDC_EVT_PUMP_DELIV Pump Delivery Info Parameters:
(e.g., titration) _ STOP Infusing Status=pump reported status
while running Current Pump Fluid Flow=pump reported
(NOTE: rate
events
associated Pump Active Sources=pump-source-info-*
with the start
of the infusion Active Source Parameters:
at original rate Current Delivery Status=pump-delivery-
and pausing or status-transitioning
completion at Program Delivery Mode=pump-program-
the new rate delivery-mode-*
are not
Source Channel Label=vendor-specific
shown)
Rate=old programmed rate
Dose Rate=old programmed dose rate
Volume Programmed=volume
programmed
Current Segment Volume
Delivered=volume delivered since last
DELIV_START
Cumulative Volume Delivered=sum of
“Current Segment Volume Delivered”
values across all segments for the delivery,
including the one just completed
Volume Remaining=volume remaining
Time Remaining=based upon Volume
Remaining and Rate
MDC_EVT_PUMP_DELIV Pump Delivery Info Parameters:
_ START Infusing Status=pump-status-infusing
Current Pump Fluid Flow=new
programmed rate
Pump Active Sources=pump-source-info-*

Active Source Parameters:

Current Delivery Status=pump-delivery-
status-delivering
Program Delivery Mode=pump-program-
delivery-mode-*
Source Channel Label=vendor-specific
Rate=new programmed rate
Dose Rate=new programmed dose rate
Volume Programmed=volume
programmed
Current Segment Volume Delivered=0
Cumulative Volume Delivered=sum of
“Current Segment Volume Delivered”
values across all segments for the delivery
prior to this one
Volume Remaining=volume remaining
Time Remaining=based upon Volume
Remaining and Rate

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 228 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Clinical
PCD-10 Event Parameters Discussion
Scenario
Piggyback MDC_EVT_PUMP_DELIV Pump Delivery Info Parameters:
start, followed _ STOP Infusing Status=pump-status-not-infusing The first
by piggyback Current Pump Fluid Flow=0 DELIV_STOP
end, followed represents the stop of
by resumption Pump Active Sources=pump-source-info-
primary the primary infusion
of the primary that was running.
infusion (this
assumes the Active Source Parameters:
pump will If the pump supports
Current Delivery Status=pump-delivery- automatic transition
revert to the status-not-delivering
primary rate from primary to
Pump Not Delivering Reason=either pump- secondary (i.e.,
once stopped-by-clinician, pump-stopped-not-
piggyback without a manual
specified, or pump-stopped-switching- pause by the
VTBI is source
achieved) clinician), then the
Program Delivery Mode=pump-program- appropriate value for
delivery-mode-* Pump Not Delivering
(Note: events Source Channel Label=vendor-specific Reason on the first
associated DELIV_STOP event
Rate=primary rate
with the start in this scenario is
of the primary Dose Rate=primary dose rate
pump-stopped-
infusion prior Volume Programmed=primary volume switching-source. If
to the programmed not, then its value
piggyback and Current Segment Volume should be either
completion of Delivered=volume delivered since last pump-stopped-by-
the primary DELIV_START clinician or pump-
infusion after Cumulative Volume Delivered=sum of stopped-not-
the piggyback “Current Segment Volume Delivered” specified.
are not values across all segments for the primary
shown) delivery, including the one just completed
Volume Remaining=primary volume
remaining
Time Remaining=based upon Volume
Remaining and Rate

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 229 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Clinical
PCD-10 Event Parameters Discussion
Scenario
MDC_EVT_PUMP_DELIV Pump Delivery Info Parameters:
_ START Infusing Status=pump-status-infusing
Current Pump Fluid Flow=piggyback
programmed rate
Pump Active Sources=pump-source-info-
secondary

Active Source Parameters:

Current Delivery Status=pump-delivery-
status-delivering
Program Delivery Mode=pump-program-
delivery-mode-*
Source Channel Label=vendor-specific
Rate=piggyback programmed rate
Dose Rate=piggyback dose rate
Volume Programmed=piggyback volume
programmed
Current Segment Volume Delivered=0
Cumulative Volume Delivered=0
Volume Remaining=piggyback volume
programmed
Time Remaining=based upon Volume
Remaining and Rate

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 230 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Clinical
PCD-10 Event Parameters Discussion
Scenario
MDC_EVT_PUMP_DELIV Pump Delivery Info Parameters:
_ COMP Infusing Status=pump-status-not-infusing
Current Pump Fluid Flow=0
Pump Active Sources=pump-source-info-
secondary

Active Source Parameters:

Current Delivery Status=pump-delivery-
status-not-delivering
Pump Not Delivering Reason=pump-
stopped-switching-source
Program Delivery Mode=pump-program-
delivery-mode-*
Source Channel Label=vendor-specific
Rate=piggyback programmed rate
Dose Rate=piggyback dose rate
Volume Programmed=piggyback volume
programmed
Current Segment Volume Delivered=
volume delivered since last piggyback
DELIV_START
Cumulative Volume Delivered=sum of
“Current Segment Volume Delivered”
values across all segments for the
piggyback delivery, including the one just
completed
Volume Remaining=0
Time Remaining=0

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 231 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Clinical
PCD-10 Event Parameters Discussion
Scenario
MDC_EVT_PUMP_DELIV Pump Delivery Info Parameters:
_ START Infusing Status=pump-status-infusing
Current Pump Fluid Flow=primary rate
Pump Active Sources=pump-source-info-
primary

Active Source Parameters:

Current Delivery Status=pump-delivery-
status-delivering
Program Delivery Mode=pump-program-
delivery-mode-*
Source Channel Label=vendor-specific
Rate=primary rate
Dose Rate=primary dose rate
Volume Programmed=primary volume
programmed
Current Segment Volume Delivered=0
Cumulative Volume Delivered=sum of
“Current Segment Volume Delivered”
values across all segments for the primary
delivery
Volume Remaining=primary volume
remaining
Time Remaining=based upon Volume
Remaining and Rate

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 232 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Clinical
PCD-10 Event Parameters Discussion
Scenario
Bolus start, MDC_EVT_PUMP_DELIV Pump Delivery Info Parameters: DELIV_STOP –
followed by _ STOP Infusing Status=pump reported status Used if the pump is
bolus end, Current Pump Fluid Flow=pump reported switching from
followed by rate continuous to bolus.
resumption of Not needed if starting
continuous Pump Active Sources=pump-source-info-* bolus from a pause or
rate after the stop.
bolus (this Active Source Parameters (primary or
assumes the secondary):
pump will Current Delivery Status=pump-delivery-
revert to the status-transitioning
continuous Program Delivery Mode=pump-program-
rate once the delivery-mode-continuous
bolus VTBI is
Source Channel Label=vendor-specific
achieved)
Rate=continuous rate
Dose Rate=continuous dose rate
(NOTE:
events Volume Programmed=continuous volume
associated programmed
with the start Current Segment Volume
of the Delivered=continuous volume delivered
continuous since last DELIV_START
infusion prior Cumulative Volume Delivered=sum of
to the bolus “Current Segment Volume Delivered”
and values across all segments for the
completion of continuous delivery, including the one just
the continuous completed, and any previously completed
infusion after boluses
the bolus Volume Remaining=continuous volume
completes are remaining
not shown)
Time Remaining=based upon Volume
Remaining and Rate

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 233 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Clinical
PCD-10 Event Parameters Discussion
Scenario
MDC_EVT_PUMP_DELIV Pump Delivery Info Parameters:
_ START Infusing Status=pump-status-infusing
Current Pump Fluid Flow=bolus
programmed rate
Pump Active Sources=pump-source-info-
clinician

Source Parameters (primary or secondary):

Cumulative Volume Delivered=sum of
“Current Segment Volume Delivered”
values across all segments for the
continuous delivery and any previously
completed boluses

Active Source Parameters (clinician dose):

Current Delivery Status=pump-delivery-
status-delivering
Program Delivery Mode=pump-program-
delivery-mode-continuous
Source Channel Label=vendor-specific
Rate=bolus programmed rate
Dose Rate=bolus dose rate
Volume Programmed=bolus volume
programmed
Current Segment Volume Delivered=0
Cumulative Volume Delivered=0
Volume Remaining=bolus volume
programmed
Time Remaining=based upon Volume
Remaining and Rate

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 234 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Clinical
PCD-10 Event Parameters Discussion
Scenario
MDC_EVT_PUMP_DELIV Pump Delivery Info Parameters:
_ STOP Infusing Status=pump reported status
Current Pump Fluid Flow=pump reported
rate
Pump Active Sources=pump-source-info-
clinician

Source Parameters (primary or secondary):

Cumulative Volume Delivered=sum of
“Current Segment Volume Delivered”
values across all segments for the
continuous delivery and any boluses,
including the one just completed

Active Source Parameters (clinician dose):

Current Delivery Status=pump-delivery-
status-transitioning
Program Delivery Mode=pump-program-
delivery-mode-continuous
Source Channel Label=vendor-specific
Rate=bolus programmed rate
Dose Rate=bolus dose rate
Volume Programmed=bolus volume
programmed
Current Segment Volume Delivered=bolus
volume delivered since last
DELIV_START
Cumulative Volume Delivered=bolus
volume programmed
Volume Remaining=0
Time Remaining=0

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 235 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Clinical
PCD-10 Event Parameters Discussion
Scenario
MDC_EVT_PUMP_DELIV Pump Delivery Info Parameters:
_ START Infusing Status=pump-status-infusing
Current Pump Fluid Flow=continuous rate
Pump Active Sources=pump-source-info-*

Active Source Parameters (primary or

secondary:
Current Delivery Status=pump-delivery-
status-delivering
Program Delivery Mode=pump-program-
delivery-mode-continuous
Source Channel Label=vendor-specific
Rate=continuous rate
Dose Rate=continuous dose rate
Volume Programmed=continuous volume
programmed
Current Segment Volume Delivered=0
Cumulative Volume Delivered=sum of
“Current Segment Volume Delivered”
values across all segments for the
continuous delivery and any boluses
Volume Remaining=continuous volume
remaining
Time Remaining=based upon Volume
Remaining and Rate
Multi-step MDC_EVT_PUMP_DELIV Pump Delivery Info Parameters: The transition is
start, followed _ START Infusing Status=pump-status-infusing handled like a rate
by multi-step Current Pump Fluid Flow=programmed change
transition, rate for step 1
followed by
multi-step Pump Active Sources=pump-source-info-*
stop
Active Source Parameters:
Current Delivery Status=pump-delivery-
status-delivering
Program Delivery Mode=pump-program-
delivery-mode-multi-step
Source Channel Label=vendor-specific
Rate=programmed rate for step 1
Dose Rate=programmed dose rate for step
1
Volume Programmed=volume
programmed for step 1
Current Segment Volume Delivered=0
Cumulative Volume Delivered=0
Volume Remaining=volume programmed
for step 1
Time Remaining=based upon Volume
Remaining and Rate

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 236 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Clinical
PCD-10 Event Parameters Discussion
Scenario
MDC_EVT_PUMP_DELIV Pump Delivery Info Parameters:
_ STOP Infusing Status=pump reported status
Current Pump Fluid Flow=pump reported
rate for step 1
Pump Active Sources=pump-source-info-*

Active Source Parameters:

Current Delivery Status=pump-delivery-
status-transitioning
Program Delivery Mode=pump-program-
delivery-mode-multi-step
Source Channel Label=vendor-specific
Rate=programmed rate for step 1
Dose Rate=programmed dose rate for step
1
Volume Programmed=volume
programmed for step 1
Current Segment Volume
Delivered=volume delivered since last
DELIV_START
Cumulative Volume Delivered=sum of
“Current Segment Volume Delivered”
values across all segments for the delivery,
including the one just completed
Volume Remaining=0
Time Remaining=0

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 237 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Clinical
PCD-10 Event Parameters Discussion
Scenario
MDC_EVT_PUMP_DELIV Pump Delivery Info Parameters:
_ START Infusing Status=pump-status-infusing
Current Pump Fluid Flow=programmed
rate for step 2
Pump Active Sources=pump-source-info-*

Active Source Parameters:

Current Delivery Status=pump-delivery-
status-delivering
Program Delivery Mode=pump-program-
delivery-mode-multi-step
Source Channel Label=vendor-specific
Rate=programmed rate for step 2
Dose Rate=programmed dose rate for step
2
Volume Programmed=volume
programmed for step 2
Current Segment Volume Delivered=0
Cumulative Volume Delivered=sum of
“Current Segment Volume Delivered”
values across all segments for the delivery
prior to this one
Volume Remaining=volume programmed
for step 2
Time Remaining=based upon Volume
Remaining and Rate

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 238 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Clinical
PCD-10 Event Parameters Discussion
Scenario
MDC_EVT_PUMP_DELIV Pump Delivery Info Parameters:
_ STOP Infusing Status=pump-status-not-infusing
Current Pump Fluid Flow=0
Pump Active Sources=pump-source-info-*

Active Source Parameters:

Current Delivery Status=pump-delivery-
not-delivering
Pump Not Delivering Reason=either pump-
stopped-by-clinician or pump-stopped-not-
specified
Program Delivery Mode=pump-program-
delivery-mode-multi-step
Source Channel Label=vendor-specific
Rate=programmed rate for current step
Dose Rate=programmed dose rate for
current step
Volume Programmed=volume
programmed for current step
Current Segment Volume
Delivered=volume delivered since last
DELIV_START
Cumulative Volume Delivered=sum of
“Current Segment Volume Delivered”
values across all segments for the delivery,
including the one just completed
Volume Remaining=volume remaining
Time Remaining=based upon Volume
Remaining and Rate

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 239 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Clinical
PCD-10 Event Parameters Discussion
Scenario
Intermittent MDC_EVT_PUMP_DELIV Pump Delivery Info Parameters:
step start, _ START Infusing Status=pump-status-infusing
followed by Current Pump Fluid Flow=programmed
intermittent rate for step n
step stop
Pump Active Sources=pump-source-info-*

Active Source Parameters:

Current Delivery Status=pump-delivery-
status-delivering
Program Delivery Mode=pump-program-
delivery-mode-multi-dosing
Source Channel Label=vendor-specific
Rate=programmed rate for step n
Dose Rate=programmed dose rate for step
n
Volume Programmed=volume
programmed for step n
Current Segment Volume Delivered=0
Cumulative Volume Delivered=sum of
“Current Segment Volume Delivered”
values across all segments for the delivery
prior to this one
Volume Remaining=volume programmed
for step n
Time Remaining=based upon Volume
Remaining and Rate

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 240 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Clinical
PCD-10 Event Parameters Discussion
Scenario
MDC_EVT_PUMP_DELIV Pump Delivery Info Parameters:
_ STOP Infusing Status=pump-status-not-infusing
Current Pump Fluid Flow=0
Pump Active Sources=pump-source-info-*

Active Source Parameters:

Current Delivery Status=pump-delivery-
status-not-delivering
Pump Not Delivering Reason=either pump-
stopped-between-doses or pump-stopped-
not-specified
Program Delivery Mode=pump-program-
delivery-mode-multi-dosing
Source Channel Label=vendor-specific
Rate=programmed rate for current step
Dose Rate=programmed dose rate for
current step
Volume Programmed=volume
programmed for current step
Current Segment Volume
Delivered=volume delivered since last
DELIV_START
Cumulative Volume Delivered=sum of
“Current Segment Volume Delivered”
values across all segments for the delivery,
including the one just completed
Volume Remaining=0
Time Remaining=0

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 241 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Clinical
PCD-10 Event Parameters Discussion
Scenario
Loading dose MDC_EVT_PUMP_DELIV Pump Delivery Info Parameters:
start, followed _ START Infusing Status=pump-status-infusing
by loading Current Pump Fluid Flow=loading dose
dose end, programmed rate
followed by
start of Pump Active Sources=pump-source-info-
continuous loading
(this assumes
the pump will Source Parameters (primary or secondary):
start at the Cumulative Volume Delivered=0
continuous
rate once the
Active Source Parameters (Loading Dose):
loading dose
VTBI is Current Delivery Status=pump-delivery-
achieved) status-delivering
(NOTE: the Program Delivery Mode=pump-program-
event delivery-mode-continuous
associated Source Channel Label=vendor-specific
with the Rate= loading dose programmed rate
completion of Dose Rate= loading dose rate
the continuous
Volume Programmed= loading dose
infusion after
volume programmed
the bolus
completes is Current Segment Volume Delivered=0
not shown) Cumulative Volume Delivered=0
Volume Remaining= loading dose volume
programmed
Time Remaining=based upon Volume
Remaining and Rate

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 242 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Clinical
PCD-10 Event Parameters Discussion
Scenario
MDC_EVT_PUMP_DELIV Pump Delivery Info Parameters:
_ STOP Infusing Status=pump reported status
Current Pump Fluid Flow=pump reported
rate
Pump Active Sources=pump-source-info-
loading

Source Parameters (primary or secondary):

Cumulative Volume Delivered=sum of
“Current Segment Volume Delivered”
values across all segments for the loading
dose, including the one just completed

Active Source Parameters (Loading Dose):

Current Delivery Status=pump-delivery-
status-transitioning
Program Delivery Mode=pump-program-
delivery-mode-continuous
Source Channel Label=vendor-specific
Rate= loading dose programmed rate
Dose Rate= loading dose rate
Volume Programmed= loading dose
volume programmed
Current Segment Volume
Delivered=loading dose volume delivered
since last DELIV_START
Cumulative Volume Delivered=sum of
“Current Segment Volume Delivered”
values across all segments for the loading
dose, including the one just completed
Volume Remaining=0
Time Remaining=0

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 243 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Clinical
PCD-10 Event Parameters Discussion
Scenario
MDC_EVT_PUMP_DELIV Pump Delivery Info Parameters:
_ START Infusing Status=pump-status-infusing
Current Pump Fluid Flow=continuous rate
Pump Active Sources=pump-source-info-*

Active Source Parameters (primary or

secondary):
Current Delivery Status=pump-delivery-
status-delivering
Program Delivery Mode=pump-program-
delivery-mode-continuous
Source Channel Label=vendor-specific
Rate=continuous rate
Dose Rate=continuous dose rate
Volume Programmed=continuous volume
programmed
Current Segment Volume Delivered=0
Cumulative Volume Delivered=sum of
“Current Segment Volume Delivered”
values across all segments for the loading
dose
Volume Remaining=continuous volume
remaining
Time Remaining=based upon Volume
Remaining and Rate
Infusion Same as “Pause a
Stopped Due running infusion”
to Alarm scenario, except that
Pump Not Delivering
Reason=either pump-
stopped-alarming or
pump-stopped-not-
specified
Auto-restart e.g., occlusion
after alarm resolved or AIL
resolved Same as “Start/restart
an infusion” scenario
Nurse restart Same as “Start/restart
after alarm an infusion” scenario
resolved
Nurse changes e.g., bag change,
VTBI hourly check, etc.

Same as “Pause a
running infusion”
case followed by
“Start/restart an
infusion” case

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 244 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Clinical
PCD-10 Event Parameters Discussion
Scenario
Ramp/taper MDC_EVT_PUMP_DELIV Pump Delivery Info Parameters:
start, followed _ START Infusing Status=pump-status-infusing
by ramp/taper Current Pump Fluid Flow=programmed
rate change, rate for step 1
followed by
ramp/taper Pump Active Sources=pump-source-info-*
stop
Active Source Parameters:
Current Delivery Status=pump-delivery-
status-delivering
Program Delivery Mode=pump-program-
delivery-mode-ramp-taper
Source Channel Label=vendor-specific
Rate=programmed rate for step 1
Dose Rate=programmed dose rate for step
1
Volume Programmed=volume
programmed for entire ramp/taper delivery
Current Segment Volume Delivered=0
Cumulative Volume Delivered=0
Volume Remaining=volume programmed
for entire ramp/taper delivery
Time Remaining=based upon Volume
Remaining and Rate

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 245 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Clinical
PCD-10 Event Parameters Discussion
Scenario
MDC_EVT_PUMP_DELIV Pump Delivery Info Parameters:
_ STOP Infusing Status=pump reported status
Current Pump Fluid Flow=pump reported
rate for step 1
Pump Active Sources=pump-source-info-*

Active Source Parameters:

Current Delivery Status=pump-delivery-
status-transitioning
Program Delivery Mode=pump-program-
delivery-mode-ramp-taper
Source Channel Label=vendor-specific
Rate=programmed rate for step 1
Dose Rate=programmed dose rate for step
1
Volume Programmed=volume
programmed for entire ramp/taper delivery
Current Segment Volume
Delivered=volume delivered since last
DELIV_START
Cumulative Volume Delivered=sum of
“Current Segment Volume Delivered”
values across all segments for the delivery,
including the one just completed
Volume Remaining=volume remaining for
entire ramp/taper delivery
Time Remaining=based upon Volume
Remaining and Rate

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 246 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Clinical
PCD-10 Event Parameters Discussion
Scenario
MDC_EVT_PUMP_DELIV based uponPump Delivery Info Parameters:
_ START Infusing Status=pump-status-infusing
Current Pump Fluid Flow=programmed
rate for step 2
Pump Active Sources=pump-source-info-*

Active Source Parameters:

Current Delivery Status=pump-delivery-
status-delivering
Program Delivery Mode=pump-program-
delivery-mode-ramp-taper
Source Channel Label=vendor-specific
Rate=programmed rate for step 2
Dose Rate=programmed dose rate for step
2
Volume Programmed=volume
programmed for entire ramp/taper delivery
Current Segment Volume Delivered=0
Cumulative Volume Delivered=sum of
“Current Segment Volume Delivered”
values across all segments for the delivery
prior to this one
Volume Remaining=volume remaining for
entire ramp/taper delivery
Time Remaining=based upon Volume
Remaining and Rate

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 247 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Clinical
PCD-10 Event Parameters Discussion
Scenario
MDC_EVT_PUMP_DELIV Pump Delivery Info Parameters:
_ STOP Infusing Status=pump-status-not-infusing
Current Pump Fluid Flow=0
Pump Active Sources=pump-source-info-*

Active Source Parameters:

Current Delivery Status=pump-delivery-
status-not-delivering
Pump Not Delivering Reason=either pump-
stopped-by-clinician or pump-stopped-not-
specified
Program Delivery Mode=pump-program-
delivery-mode-ramp-taper
Source Channel Label=vendor-specific
Rate=programmed rate for step 2
Dose Rate=programmed dose rate for step
2
Volume Programmed=volume
programmed for entire ramp/taper delivery
Current Segment Volume
Delivered=volume delivered since last
DELIV_START
Cumulative Volume Delivered=sum of
“Current Segment Volume Delivered”
values across all segments for the delivery,
including the one just completed
Volume Remaining= volume remaining for
entire ramp/taper delivery
Time Remaining= based upon Volume
Remaining and Rate
Patient ID MDC_EVT_PATIENT_ID_ New Patient ID=PID.3
Change CHANGE
New Weight MDC_EVT_PATIENT_ Weight=New Patient Weight, or e.g., when weight
or New PARAMETER_CHANGE Body Surface Area=New Patient BSA, or changed during an
Height or Height=New Patient Height active weight-based
New BSA infusion
(same patient)

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 248 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Clinical
PCD-10 Event Parameters Discussion
Scenario
Switch to MDC_EVT_PUMP_DELIV Pump Delivery Info Parameters: The library-based
library-based _ STOP Infusing Status=pump-status-not-infusing infusion is considered
infusion Current Pump Fluid Flow=0 a new delivery
(NOTE: Pump Active Sources=pump-source-info-*
events
associated
with the start Active Source Parameters:
of the non- Current Delivery Status=pump-delivery-
library status-not-delivering
infusion and Pump Not Delivering Reason=either pump-
the stopped-by-clinician or pump-stopped-not-
completion of specified
the library- Program Delivery Mode=pump-program-
based delivery-mode-*
infusion are
Source Channel Label=vendor-specific
not shown)
Rate=rate of non-library infusion
Dose Rate= dose rate of non-library
infusion
Volume Programmed=volume
programmed for non-library infusion
Current Segment Volume
Delivered=volume delivered since last
DELIV_START
Cumulative Volume Delivered=sum of
“Current Segment Volume Delivered”
values across all segments for the non-
library delivery, including the one just
completed
Volume Remaining=volume remaining of
non-library infusion
Time Remaining=based upon Volume
Remaining and Rate

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 249 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Clinical
PCD-10 Event Parameters Discussion
Scenario
MDC_EVT_PUMP_DELIV Pump Delivery Info Parameters:
_ START Infusing Status=pump-status-infusing
Current Pump Fluid Flow=programmed
rate of library-based infusion
Pump Active Sources=pump-source-info-*

Active Source Parameters:

Current Delivery Status=pump-delivery-
status-delivering
Program Delivery Mode=pump-program-
delivery-mode-*
Source Channel Label=vendor-specific
Rate=rate of library-based infusion
Dose Rate=dose rate of library-based
infusion
Volume Programmed=volume
programmed for library-based infusion
Current Segment Volume Delivered=0
Cumulative Volume Delivered=0
Volume Remaining=volume programmed
for library-based infusion
Time Remaining=based upon Volume
Remaining and Rate

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 250 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Clinical
PCD-10 Event Parameters Discussion
Scenario
Switch from MDC_EVT_PUMP_DELIV Pump Delivery Info Parameters:
library-based _ STOP Infusing Status=pump-status-not-infusing
infusion Current Pump Fluid Flow=0
(NOTE: Pump Active Sources=pump-source-info-*
events
associated
with the start Active Source Parameters:
of the library- Current Delivery Status=pump-delivery-
based infusion status-not-delivering
and the Pump Not Delivering Reason=either pump-
completion of stopped-by-clinician or pump-stopped-not-
the non- specified
library-based Program Delivery Mode=pump-program-
infusion are delivery-mode-*
not shown)
Source Channel Label=vendor-specific
Rate=rate of library infusion
Dose Rate= dose rate of library infusion
Volume Programmed=volume
programmed for library infusion
Current Segment Volume
Delivered=volume delivered since last
DELIV_START
Cumulative Volume Delivered=sum of
“Current Segment Volume Delivered”
values across all segments for the library
delivery, including the one just completed
Volume Remaining=volume remaining of
library infusion
Time Remaining=based upon Volume
Remaining and Rate

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 251 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Clinical
PCD-10 Event Parameters Discussion
Scenario
MDC_EVT_PUMP_DELIV Pump Delivery Info Parameters:
_ START Infusing Status=pump-status-infusing
Current Pump Fluid Flow=programmed
rate of non-library-based infusion
Pump Active Sources=pump-source-info-*

Active Source Parameters:

Current Delivery Status=pump-delivery-
status-delivering
Program Delivery Mode=pump-program-
delivery-mode-*
Source Channel Label=vendor-specific
Rate=rate of non-library-based infusion
Dose Rate=dose rate of non-library-based
infusion
Volume Programmed=volume
programmed for non-library-based infusion
Current Segment Volume Delivered=0
Cumulative Volume Delivered=0
Volume Remaining=volume programmed
for non-library-based infusion
Time Remaining=based upon Volume
Remaining and Rate

5700

5705

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 252 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

5710 M.1.2.2 Infusion Event Sample Message

Delivery Start Event

MSH|^~\&|PAT_DEVICE_PUMPVENDOR^9999990000000000^EUI-
64|PUMPVENDOR|DOC_VENDOR|DOC_VENDOR|20151015132107-
5715 0500||ORU^R42^ORU_R01|6358051206735492253|P|2.6|||AL|NE||ASCII|en^English^ISO
639||IHE_PCD_010^IHE PCD^ 1.3.6.1.4.1.19376.1.6.4.10^ISO
PID|||HO2009002^^^IHE^PI||Hon^Charles^^^^^L|Brooks^^^^^^L|19610201000000-
0600|M|||||||||||||||||||||||N
PV1||I|3 West ICU^3002^1
5720 OBR|1|AB12345^PCD-03|CD12345^HL7^ACDE48234567ABCD^EUI-
64|2222^Dopamine|||20151015132106-0500
OBX|1||70049^MDC_DEV_PUMP_INFUS_LVP_MDS^MDC|1.0.0.0|||||||X|||||N0002||E0002^
^0012210000000000^EUI-64
OBX|2|ST|184517^MDC_PUMP_DRUG_LIBRARY_VERSION^MDC|1.0.0.1|DL1||||||R
5725 OBX|3|CWE|68487^MDC_ATTR_EVT_COND^MDC|1.0.0.2|197288^MDC_EVT_PUMP_DELIV_START
^MDC||||||R
OBX|4|ST|68488^MDC_ATTR_EVT_SOURCE^MDC|1.0.0.3|1.1.2.0||||||R
OBX|5||70050^MDC_DEV_PUMP_INFUS_LVP_VMD^MDC|1.1.0.0|||||||X
OBX|6||70067^MDC_DEV_PUMP_DELIVERY_INFO^MDC|1.1.1.0|||||||X
5730 OBX|7|CWE|184519^MDC_PUMP_INFUSING_STATUS^MDC|1.1.1.1|^pump-status-
infusing||||||R
OBX|8|NM|158014^MDC_FLOW_FLUID_PUMP_CURRENT^MDC|1.1.1.2|15.4|265266^MDC_DIM_M
ILLI_L_PER_HR^MDC^mL/h^mL/h^UCUM|||||R
OBX|9|CWE|158016^MDC_DEV_PUMP_ACTIVE_SOURCES^MDC|1.1.1.3|^pump-source-info-
5735 primary||||||R
OBX|10||70071^MDC_DEV_PUMP_INFUSATE_SOURCE_PRIMARY^MDC|1.1.2.0|||||||X
OBX|11|CWE|158005^MDC_DEV_PUMP_CURRENT_DELIVERY_STATUS^MDC|1.1.2.1|^pump-
delivery-status-delivering||||||R
OBX|12|CWE|158008^MDC_DEV_PUMP_PROGRAM_DELIVERY_MODE^MDC|1.1.2.2|^pump-
5740 program-delivery-mode-continuous||||||R
OBX|13|ST|158012^MDC_DEV_PUMP_SOURCE_CHANNEL_LABEL^MDC|1.1.2.3|Primary||||||R
OBX|14|NM|157784^MDC_FLOW_FLUID_PUMP^MDC|1.1.2.4|15.4|265266^MDC_DIM_MILLI_L_
PER_HR^MDC^mL/h^mL/h^UCUM|||||R
OBX|15|NM|157924^MDC_RATE_DOSE^MDC|1.1.2.5|5.00|265619^MDC_DIM_MICRO_G_PER_KG
5745 _PER_MIN^MDC^ug/kg/min^ug/kg/min^UCUM|||||R
OBX|16|NM|157884^MDC_VOL_FLUID_TBI^MDC|1.1.2.6|250.0|263762^MDC_DIM_MILLI_L^M
DC^mL^mL^UCUM|||||R
OBX|17|NM|157993^MDC_VOL_FLUID_DELIV_TOTAL^MDC|1.1.2.7|0.0|263762^MDC_DIM_MIL
LI_L^MDC^mL^mL^UCUM|||||R
5750 OBX|18|NM|157872^MDC_VOL_FLUID_TBI_REMAIN^MDC|1.1.2.8|250.0|263762^MDC_DIM_MI
LLI_L^MDC^mL^mL^UCUM|||||R
OBX|19|NM|157916^MDC_TIME_PD_REMAIN^MDC|1.1.2.9|974|264352^MDC_DIM_MIN^MDC^mi
n^min^UCUM|||||R
OBX|20|ST|184514^MDC_DRUG_NAME_LABEL^MDC|1.1.2.10|Dopamine||||||R
5755 OBX|21|NM|157760^MDC_CONC_DRUG^MDC|1.1.2.11|1.6|264306^MDC_DIM_MILLI_G_PER_ML
^MDC^mg/mL^mg/mL^UCUM|||||R
OBX|22|ST|184516^MDC_PUMP_DRUG_LIBRARY_CARE_AREA^MDC|1.1.2.12|Crit
Care||||||R
OBX|23|NM|68063^MDC_ATTR_PT_WEIGHT^MDC|1.1.2.13|82.0|263875^MDC_DIM_KILO_G^MD
5760 C^kg^kg^UCUM|||||R

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 253 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01
 IHE Patient Care Device Technical Framework, Vol. 2 (PCD TF-2): Transactions
______________________________________________________________________________

Glossary
The IHE Glossary, an appendix to the IHE Technical Frameworks General Introduction, can be
5765 found here.

______________________________________________________________________________
Rev. 9.0 – Final Text 2019-12-12 254 Copyright © 2019: IHE International, Inc.
Template Rev. 1.0 – 2014-07-01