IntelliVue Information Center HL7 Programmer S Guide PDF
IntelliVue Information Center HL7 Programmer S Guide PDF
i
Notice
Proprietary Information
This document contains proprietary information, which is protected by copyright.
Copyright
Copyright © 2011 Koninklijke Philips Electronics N.V.
Manufacturer
Philips Medical Systems
3000 Minuteman Road
Andover, MA 01810
(978) 687-1501
Document Number
4535 642 64661
Warranty Disclaimer
The information contained in this document is subject to change without notice. Philips Medical Systems makes no
warranty of any kind with regard to this material, including, but not limited to, the implied warranties or merchantability
and fitness for a particular purpose. Philips Medical Systems shall not be liable for errors contained herein or for
incidental or consequential damages in connection with the furnishing, performance, or use of this material.
ii
Printing History
New editions of this document incorporate all material updated since the previous edition. Update packages may be
issued between editions and contain replacement and additional pages to be merged by a revision date at the bottom of
the page. Pages that are rearranged due to changes on a previous page are not considered revised.
The documentation printing date and part number indicate its current edition. The printing date changes when a new
edition is printed. (Minor corrections and updates that are incorporated at reprint do not cause the date to change.) The
document part number changes when extensive technical changes are incorporated.
Conventions
The manual uses the following conventions for Notes, Cautions, and Warnings.
Caution A Caution calls attention to a condition or possible situation that could damage or destroy the product or the
user’s work.
Warning A Warning calls attention to a condition or possible situation that could cause injury to the user and/or patient.
iii
iv
Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-1
Document Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-1
Intended Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-1
Scope and Exclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-1
Related Documents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-1
Terms and Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-2
Contents-1
Communicate Patient Demographics (CPD-2) Interaction Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11
Communicate Vital Signs (CVS-1) Interaction Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12
Communicate Vital Signs (CVS-2) Interaction Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13
Communicate Network Time (CNT-1) Interaction Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14
2
OBR Segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12
OBX Segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12
Acknowledgements and Business Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12
Acknowledgements Diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12
Sample Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13
Mapping Communicate Vital Signs (CVS-2) Transaction to HL7 Messages - Query Mode . . . . . . . . . . . . . . . . . . . . . . . 4-14
Overview History of Polling Interface (CVS-2 Transactions) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-14
HL7 Message Profile Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-16
Observation Reporting - HL7 ORU^R04 and QRD / QRF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-16
HL7 Segment Level Profile Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-18
MSH Segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-18
QRD Segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-18
Examples: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-20
QRF Segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-21
MSA Segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-22
Examples: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-23
PID Segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-23
PV1 Segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-23
OBR Segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-23
OBX Segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-23
Acknowledgements and Business Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-24
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-24
Error Handling (ACK message processing) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-24
Sample Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-25
QRY Message (using above segment definitions) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-25
Examples: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-25
ORF Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-26
MDIL Coding Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-27
SDN Coding Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-27
Sample ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-29
Time Sync Reporting (CNT-1 - Communicate Network Time Transaction) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-29
Mapping Communication Network Time Transaction (CNT-1) Transactions to HL7 Messages . . . . . . . . . . . . . . . . . . . . 4-30
HL7 Message Profile Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-30
Communicate Network Time HL7 NMD message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-30
HL7 Segment Level Profile Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-31
MSH Segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-31
NCK Segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-31
NMD Example: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-31
3
Shared Segment Profile Definitions (Across Integration Profiles) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-31
Common MSH Segment Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-32
Supporting Details for CVS-1 Transactions (Unsolicited Reporting) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-34
Example: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-34
Supporting Details for CVS-2 Transactions (Query Mode) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-35
Example: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-35
Common PID Segment Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-36
Supporting Details for CVS-1 Transactions (Unsolicited Reporting) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-39
Example: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-40
Supporting Details for CVS-2 Transactions (Query Mode) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-40
Common PV1 Segment Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-41
Supporting Details for CVS-1 Transactions (Unsolicited Reporting) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-43
Example: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-43
Supporting Details for CVS-2 Transactions (Query Mode) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-44
Common OBR Segment Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-45
Common OBX Segment Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-46
Overview History of OBX Segment Operation (CVS-1 and CVS-2 Transactions) . . . . . . . . . . . . . . . . . . . . . . . . . . 4-47
Observation Field Identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-49
Observation Sub-ID (Device Identifier) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-50
Parameter Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-51
OBX Field Message Type Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-52
Parameter Identifiers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-52
Coding Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-54
Parameter Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-55
Parameter List for Possible Coded Values for OBX.5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-56
MRx Device Parameter List for Possible Coded Values for OBX.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-116
Physiological Calculation Parameter Identifiers for Possible Coded Values for OBX.5 . . . . . . . . . . . . . . . . 4-119
Unit Code Identifiers for Possible Coded Values for OBX.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-123
OBX Segment Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-130
Supported Data Types (All Integration Profiles) - Non-Atomic Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-132
CE Data Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-132
CE Coded Element Data Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-133
CX Data Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-133
CX Extended Composite ID with Check Digit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-133
EI Data Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-134
EI Entity Identifier Data Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-134
HD Data Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-135
HD Hierarchic Designator Data Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-135
4
PL Data Type ................................................................................................................................................................... 4-135
PL Person Location Data Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-135
TS Data Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-137
TS Time Stamp Data Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-137
XPN Data Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-137
XPN Extended Person Name Data Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-137
XCN Data Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-138
XCN Extended Composite ID Number and Name for Persons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-138
MSG Data Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-139
MSG Message Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-139
PT Data Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-139
PT Processing Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-139
VID Data Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-140
VID Version Identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-140
Deviations in Messages from HL7 Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-141
International Characters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-141
5
Database / XML Table Column . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-14
Notes Reference Column . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-14
Field Profile Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-15
User-Defined and Suggested Field Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-15
Components and SubComponents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-15
6
Document Overview
1
Introduction
Document Overview
This document covers the Philips IntelliVue Information Center Release (PIIC) N HL7 interface documentation.
Intended Audience
Intended audience is, but are not limited to, individuals being involved in planning, designing and implementing an IntelliVue Information
Center interface integration amongst other Philips products integration profiles.
Related Documents
For additional information on how the PIIC processes ADT messages, refer to the CareVue Integration Engine (CIE) Release A.0 guide (part
number 4535 640 30181).
Introduction
1-1
Terms and Acronyms
Term Meaning
Integration Profile An integration Profile is a method of categorization and a representation of a real-world integration capabilities
that is supported by a set of actors that interact through transactions. See IHE for more details.
Actor Actors are functional integration components of information systems that produce, manage, or act on exchange
of information with other systems. See IHE for more details.
Transaction Transactions are interactions between Actors that exchange the required information through one or
more HL7 messages.
CIE The Clinical Integration Engine aka CareVue Integration Engine (CIE) is a clinical messaging and
interfacing integration engine that features Symphonia 3 from Orion Ltd., a highly flexible and
configurable 3rd party message mapping engine. It supports healthcare and IT interfacing and
messaging standards such as HL7, ASTM, LIS2, TCP/IP sockets, RS-232, and file sharing. CIE also
integrates Philips clinical information system products such as the Philips IntelliVue Information
Center (PIIC) system and the OB TraceVue system into an existing hospital IT infrastructure.
Introduction
1-2
Overview
26
HL7 Interface Connection Management and Processing
Overview
This chapter describes the connection management installation procedures and details.
• Handling of Vital Signs HL7 Patient Data Interface (PDI) unsolicited messages
– Support of RY, ORF, and ACK messages within the PDI messages.
• Handling of Admission/Discharge/Transfer (ADT) messages.
– Support of Admit, Discharge, Transfer, Update, and Patient ID (MRN) Change messages
Communication Layers
The following diagram shows the communication layers involved in the communication between the HL7 Parameter Data Interface and a client
computer.
TCP/IP TCP/IP
Socket Connection Socket Connection
IP Network
Each client uses a TCP/IP socket connection for PDI communication. PDI allows multiple connections, but only one connection at one time to
one particular client machine as identified by IP Address.
If a client machine not configured for any bed in the Config Wizard attempts to connect to an Unsolicited port, the connection will be shut
down immediately by the Parameter Data Interface. A client that is configured for a particular set of beds will receive data for those beds and
no others.
The hostname or IP address of the client systems are set in the Config Wizard (as described in the Information Center System Installation and
Service Guide).
The port number for the unsolicited messages interface as well as the polling interface is specified by a parameter set with the Information
Center configuration utility (Config Wizard). The default PDI port number for the unsolicited messages interface (UMI) is 8000. The default
port number for the polling interface is 9010. The port numbers can be modified in the IIC Config Wizard.
TCP/IP is a byte-stream protocol and does not provide messaging boundaries. HL7, which is the standard for the upper-level protocol, is based
on messages but does not provide a mechanism to detect message termination. To mark message boundaries, the Minimal Lower Layer
Protocol is used (as described in HL7 Interface Standards Version 2.x).
<VT>ddddd<FS><CR>
where:
ddddd is the HL7 message. Includes only ISO 8859-1 characters (hexadecimal values between 20 and FF, inclusive) and <CR>. Must not
contain other control/non-printable characters. It is the responsibility of the external system not to send any forbidden control characters. There
is no special treatment for forbidden control characters in PDI.
Description of HL7 message processing at the IIC is in the following table. DbServ is the process on the database server or standalone IIC that
sends data to the HL7 clients.
Startup Behavior:
DbServ starts and waits for connection for each
configured client. ExportLog.txt contains the
following message when client connects.
SDHL7SessMgr::processSocketEvent Connection
request from client 10.40.41.31 accepted
Shutdown Behavior:
HL7 output is discontinued and socket is closed.
Auto Unsolicited Client only has to open socket DbServ automatically sends HL7 data to The behavior described in this table assumes that
that is configured in CGS HL7 configured clients once client opens TCP connection is established and operating
to receive data. socket. properly.
Client only has to listen on socket for A description of the Auto Unsolicited sending
data/activity option behavior is Send.
• Client listens on socket.
• DbServ sends data to all
configured clients.
Shutdown Behavior:
DbServ closes the connection. The client socket
should remain open.
Shutdown Behavior:
HL7 output is discontinued and socket is closed.
Disconnect/Reconnect:
If connection is lost or broken on either the source
or client side the source will time-out and close
socket; data feed stops.
If problems are encountered HL7 Parameter Data Interface (PDI) on the Information Center system, there are tools and a log file that can be
used to identify the source of the problem. In addition, if the Information Center detects a failure in communication with one or more HL7
clients, a System Message is displayed on the Information Center main screen that states: HL7 Client Disconnected.
Refer to the troubleshooting chapter in the IntelliVue Information Center System Installation and Service Manual, located on the Information
Center documentation CDROM, for details on these tools.
Config Wizard is a series of screens that permit an IIC support user to configure the IIC System and associated devices. HL7 configuration and
message behavior is determined by various configuration settings that you make during system setup. A description of the required IIC HL7
configuration settings and subsequent processing behavior are included in this appendix.
The IIC Config Wizard Purchased Options and Support Information screen shows information identifying hardware, software, and purchased
options. In order to support HL7 information exchange you must have the HL7 Purchased Option.
Purchased Options
Changes in Purchased Options can only be made by an authorized Philips Representative
The Local General Configuration Settings Config Wizard screen permits HL7 Export Configuration settings that are applicable to
Information Centers.
The Network Configuration screen helps the Server identify devices on the LAN. You can add, edit, and remove HL7devices in the List of
Network Devices section of this screen.
The List of network devices section of the Network Configuration screen permits configuration of the network devices connected to the
system.
Edit 1. Select the device name you want to change in the List of Network
Changes the information for a device in Devices.
the List of network devices section of
the Network Configuration screen 2. Click Edit to open the device type Network Devices screen.
3. Edit/change the required information, then click OK.
Remove Removes a device from the List of 1. Click the device name you want to remove.
network devices section of the 2. Click Remove.
Network Configuration screen 3. Click OK
The Config Wizard Equipment Setup permits configuration of the HL7 messages.
Button/Selection Action/Steps
HL7 Target Client Permits selection of the target client from a drop-down list
Sending Options
Periodic Parameter Type • Current - sends the last actual parameter value received from the monitor.
• Averaged - sends the average of measurement since the last data time values were sent.
Button/Selection Action/Steps
Message Type Depending on the option, a numeric code is shown for parameter identification. Not all IntelliVue Clinical
Network numerics are supported with EMFC encoding.
• EMFC Coding (Default) - Extended Medical Function Codes
• MDIL Coding - Medical Device Interface Language
• PDS Compatible - Permits selection of Patient Data Server compatible output
Click the check box to select the option.
Send Time Messages Specifies whether a Network Management (NMD) message with the current date/time should be sent periodically
every 60 seconds
When the connection is established, the message is sent to the client.
Click the check box to select the option.
Send Facility ID Specifies whether the Facility ID should be sent with the data
Click the check box to select the option
Post HL7 Disconnect Message Determines if the HL7 Disconnect message appears on the Resting Display
Click the check box to suppress the HL7 Disconnect message on the Resting Display; clear the check box to
show the message when this client disconnects.
Unsolicited
Button/Selection Action/Steps
Auto Unsolicited Opens an HL7 Auto Unsolicited Setting dialog which permits automatic sending of HL7 unsolicited data
without a request from the client
By default this check box is clear (Off)
You must notify appropriate Hospital IT staff before you select the Set Auto Unsolicited On check box.
Sending Interval Permits selection of the interval that triggers the HL7 unsolicited data export for periodic parameter
Click the drop down arrow to show the available settings and click the desired selection.
5, 10, 30 (Default), 60
IP Port for Unsolicited Specifies the socket port number through which clients connect to the HL7 unsolicited message interface
This is the port the client connects to that determines whether it will be treated as an unsolicited or a query client.
• 1 to 65536
• 8000 (Default)
Solicited
IP Port for Query Specifies the socket port number through which clients connect to the HL7 polling message interface
• 1 to 65536
• 9010 (Default)
Bed Assignment
Button/Selection Action/Steps
Target Client Lists possible host names
If the Target Client is a CareVue server in duplex mode configuration, use the secondary server name as the
target client.
Click a bed in the Target Client(s) list to select it.
Assign • Select the host name from the Target Client(s) list.
• Select the beds from the Available Beds list.
Unassign
• Click Assign (or Unassign) button to associate (or disassociate) the client to the bed label.
Edit IDs
Opens an Edit IDs dialog box that permits configuring the SDN ID and the LBN ID.
If exporting HL7 output to CareVue, you must configure Network ID (Id/SDN) and Bed ID (Lbn) settings so
that they are an exact match to those of the CareVue system.
For existing CareVue systems with CMS beds upgrading to IntelliVue Monitors, document the existing CareVue
Unit SDN Bed Map page. Enter the documented settings for each bed label.
For new CareVue systems with IntelliVue Patient Monitors, continue to assign SDN settings for IPMs (id/SDN &
Lbn) in the Unit SDN Bed map page.
• Enter Network ID (Id/SDN) and Bed ID (Lbn) in adjacent text box.
• Click OK to save changes or Cancel.
Button/Selection Action/Steps
Network ID (id/SDN) Permits entering the target client bed Network ID value (either 1 or 2) or the target client bed ID from 0- 24. The
default for each is 0.
Bed ID (Lbn)
• Enter Network ID (Id/SDN) in adjacent text box.
• Enter Bed ID (Lbn) in adjacent text box.
• Click OK in the Edit IDs screen to save changes or Cancel.
• Click Apply in the HL7 Configuration screen to save changes without exiting the screen.
• Click OK in the HL7 Configuration screen to save changes and open the next screen, or Cancel.
3
System Integration Overview
Overview
This section focuses on the highest level functional view of integration capabilities. It is a description of each Integration Profile and its
associated transactions. In addition, it includes both the structural and dynamic aspects of the system-level integration. The structural
description is most typically represented as a system-level graphical block diagram showing each Philips and non-Philips systems within the
defined scope. The dynamic description is represented using a series of system interaction diagrams showing the HL7 messages being passed
to/from each system within the defined scope
The HL7 Interface of the PIIC allows PIIC to act as a sender and a receiver of HL7 messages (queries and unsolicited updates).
ADT communication is exclusively routed through the CareVue Integration Engine (CIE). The CIE is a separate product, which connects PIIC
to other external hospital information systems.
Integration Profiles
Each integration profile of this specification is a representation of a real-world capability that is supported by a set of actors that interact
through transactions. Actors are functional components of information systems that produce, manage, or act on categories of information
required for integration in the enterprise. Transactions are interactions between actors that transfer the required information through HL7
messages.
Table of Profiles
ADT
Admit Discharge Transfer This integration profile describes the mechanisms that enable this product to report ADT patient
identification data and/or demographics to the Hospital Patient Registration system or other
interested data consumer.
VSR
Vital Signs Reporting This integration profile describes mechanisms that enable this product to communicate
vital signs data to enterprise information systems and interested clients. The typical
data includes periodic physiological data (heart rate, invasive blood pressure,
respiration rate, etc.) for specified monitored patient.
TSR
Time Sync Reporting This integration profile describes mechanisms that enable this product to communicate
network time to enterprise information system and interested clients. The typical data is
a time message (NMD).
Actors
The section defines an interoperability Actor. Actors and their associated transactions are abstractions of real-world healthcare information
exchange functions. While some of the transactions are traditionally performed by specific product categories (e.g. HIS, EMR, RIS, PACS,
CIS, patient care devices or imaging modalities), we intentionally avoid associating functions or actors with such product categories. Each actor
defines only those functions associated with integrating information systems. The definition of an actor should therefore not be taken as the
complete definition of any product capabilities that might implement it, nor should this Integration Specification itself be taken to
comprehensively describe the architecture of a healthcare information system environment.
Actor Definitions
Actors are functional components of information systems that produce, manage, or act on information associated with operational activities in
the enterprise. Transactions are interactions between actors that transfer the required information through HL7 messages. The following are the
actors defined by this specification and referenced throughout the rest of this document.
ADT
Patient Demographics The Patient Demographics Supplier (PDS) actor is the functional role of the ADT system
Supplier (PDS) that supplies patient identification and/or demographics information from this product.
This includes such patient actions as admit, discharge, update, merge, etc.
Patient Demographics The Patient Demographics Client (PDC) actor is the functional role of the ADT
Client (PDC) system that accepts patient identification from a hospital ADT system, or other
product and in the case of this product is only the ICIP product.
Note — This is not done through an HL7 interface and is documented here for
completeness only. It is detailed here as an aid to system integrators so that
incoming patient data connection path can be fully understood.
VSR
Vital Signs Supplier The Vital Signs Supplier (VSS) receives data from medical devices, including
(VSS) those based on proprietary formats, and maps the received patient parameter
data to Vital Signs Client (VSC) providing consistent syntax and semantics.
This actor gathers and transmits patient vital signs data on a configured interval
basis.
Vital Signs Query (VSQ) The Vital Signs Query (VSQ) receives data from medical devices, including
those based on proprietary formats, and upon a query from a Vital Signs Client
(VSC) maps the received patient parameter data to the requesting Vital Signs
Client (VSC) providing consistent syntax and semantics. Proper patient
identification for the data is ensured. The data is sent only when proper queries
are received (e.g. no data is sent without a query received first).
Vital Signs Client (VSC) The Vital Signs Client (VSC) represents the Hospital Information system or any
other consumer of patient vital signs data.
Transactions
Transactions are interactions between actors that transfer the required information through one or more HL7 messages. The following are the
transactions defined by this specification and referenced throughout the rest of this document.
ADT
Communicate Patient The Communicate Patient Demographics Transaction (CPD-1) is used by the Patient
Demographics (CPD-1) Demographics Source actor for communicating Patient Identification and/or
Demographics to the Patient Demographics Client actor.
In a real life example, a PDS (Patient Monitoring) transmits Patient Demographics to a
PDC (ICIP or Hospital ADT system) via the following HL7 messages: ADT A01, A03,
A08, A47, and a combination of A03 / A01 to identify a patient transfer.
Communicate Patient The Communicate Patient Demographics Transaction (CPD-2) is used by the
Demographics (CPD-2) Patient Demographics Client to transmit patient demographics information to
the Patient Demographics Source actor.
For example, a PDC (ICIP) transmits patient demographic information to the
PDS (Patient Monitoring product) through direct login and solicitation of
database patient data in the ICIP.
Note — This is not a HL7 transaction. It is documented here, however, to help
system integrators implement the mechanism by which Patient Monitoring
retrieves patient information from another system. It only works with the ICIP
product.
Communicate Vital Signs The Communicate Vital Signs (CVS-1) transaction is used by Vital Signs
(CVS-1) Supplier actor to transmit patient vital signs data to enterprise clients on a
configured interval timeframe.
For example, this transaction communicates patient vital signs information
using HL7 ORU^R01 messages on a configured interval.
Query Vital Signs (CVS-2) The Query Vital Signs (CVS-1) transaction is used by Vital Signs Client (VSC)
actor to request patient vital signs data from the Vital Signs Query actor.
This transaction communicates a query request using the HL7 QRF message.
Response is one of 2 possibilities: HL7 ACK message (Acknowledgement
Query Response message) which includes requested vital signs data or HL7
ACK message noting
For example, this transaction communicates patient vital signs information for
the Patient Monitoring product using HL7 message ORU^R04 messages after
receiving a proper query as defined by the HL7 QRY message. A received
faulty HL7 QRY message is responded to with a HL7 ACK message with an
error message
Communicate Network The Communicate Network Time (CNT-1) transaction is used by the Vital
Time (CNT-1) Signs Supplier actor and Vital Signs Query actor to transmit current time to a
the Vital Signs Client actor.
For example, this transaction is accomplished by the Patient Monitoring
product HL7 NMD message sent once a minute (if configured) to transmit
current time to clients receiving vital signs data.
The following sections diagram the transactions for the actors within the HL7 system for this product.
This transaction is for demonstrating how this product transmits patient demographic data.
Patient Demographics
Patient Monitoring product
Supplier (PDS)
This transaction is for demonstrating how this product receives patient demographic data
Patient Demographics
Patient Monitoring product
Supplier (PDS)
This transaction diagram defines how patient vital signs information is transmitted on an interval basis; unsolicited.
This transaction diagram defines how patient vital signs information is transmitted on an interval basis on query.
Implementation Notes
System Integrators have a number of options in implementing actors and transactions in product implementations. The decisions cover four
levels:
This diagram shows the Patient Demographic information sequence. It occurs when there is an admit, update, transfer or discharge for a patient.
A merge message is sent when a retrieved patient (done by name) has a different MRN, resulting in a merge.
This diagram shows the transaction sequence for retrieving patient information from ICIP. This is the only outside source of patient
demographic data. It is not HL7 based but is shown here for system integration purposes only. It occurs upon a Retrieve action within the
Patient Monitoring Admit system.
This diagram shows the transaction sequence for sending patient vital signs (CVS-1). It occurs on configured intervals for clients; usually the
hospital EMR system.
• Unsolicited
• Auto Unsolicited.
Hospital System /
ICIP / EMR etc. VSC VSS This Product
This diagram shows the transaction sequence for querying for vital signs. A query message is sent and the response is either a HL7 ACK
message indicating a query error or alternatively the vital signs data is sent. Vital signs data is only sent upon a valid query.
ICIP System VSC Communicate Vital Signs (CVS-2) VSS This Product
This diagram shows the HL7 Network time (NMD) message transaction. It is communicated once a minute to each configured client.
Hospital EMR or
other configured VSC VSS This Product
vital signs client
4
HL7 Message Profile Definitions (Categorized by Integration Profile)
Overview
This section describes the detailed HL7 Message Profile Definitions for each of messages within the scope of this specification. The HL7
Message Profile Definitions are categorized by the Integration Profile categories outlined in the beginning of this document. Each Profile has
the Use Cases, Transactions and Actors that participate within the context of this integration profile scenario.
The following table enumerates the messages supporting the CPD-1 transaction.
PHC CPD-1
The following section summarizes the message profile definitions for the Communicate Patient Demographics profile.
Patient Register and Update - HL7 ADT A01, A03, A08 and A47
This sub-section describes the profile definition at the Segment level. More specifically, it describes the fields that are required (or optional) for
a particular HL7 Segment Profile. It uses the standard HL7 notations as outlined in HL7 Chapter 2B. In addition, a column is added to denote
additional information (possible values) for each element within the segment. This important for validation / testing purposes.
MSH Segment
See “Common MSH Segment Definition” on page 4-32 for additional details.
EVN Segment
PID Segment
See “Common PID Segment Definition” on page 4-36 for additional details.
PV1 Segment
See “Common PV1 Segment Definition” on page 4-41 for additional details.
MRG Segment
Merge Segment definitions are defined below. MRG segment appears only in A47 messages.
Acknowledgements
Not supported for CPD-1 transactions. ACK messages received are ignored.
Sample Messages
MSH|^~\&|Philips.PM.IIC.ADT^149.59.185.101^IP||||20031225113544||ADT^A01|
HP000000000006|P|2.3|1
EVN|A01|20031225113544
PID|||121314789^^^^MR~8FEAE741-950D-11d7-8AEE-0010A4037DE7^^^^JupiterID||Jones^Paula||19550310|F|
PV1||I|ICU-South^^Bed2
Sample ACK
Vital Signs Reporting Integration Profile (CVS - Communicate Vital Signs Transactions)
HL7 Parameter Data Interface (PDI) is a software option available for the Information Center (IIC) system. This interface provides a gateway
between a Philips CareNet™ (SDN) network/IntelliVue Clinical Network and a TCP/IP hospital network. Message transmission between PDI
and client systems can take place via the unsolicited messages interface (CVS-1 transactions) or the polling interface (CVS-2 transactions).
These two interfaces are completely independent from each other (although both can be used simultaneously). When working with the
unsolicited messages interface, patient data, bed labels, and vital sign parameter values are distributed to PDI client systems at a time interval
that can be configured (30 seconds is the default), with averaged or the latest (current) values of periodic parameters. When working with the
polling interface, specific patient data, bed labels and vital sign parameters can be requested at any time by PDI client systems. In both cases,
the data format is compliant with the HL7 (Health Level 7) standard version 2.x.
HL7 output for the M2/M3/M4 bedsides and the IntelliVue Patient Monitors (MP90, MP70, etc.) are available on alerts and INOPs originating
from these monitors, all monitors from M2/M3/M4 beds, monitoring parameters from IntelliVue Patient Monitors (including Vuelink), EEG
measurement and calculation parameters, Essential Gas Module (EGM) and Anesthesia Gas Module (AGM).
PDI uses numeric codes from the Medical Device Interface Language (MDIL) nomenclature to uniquely identify parameter and alert sources. If
EMFC coded parameters are required for HL7 output, there is a configuration option in the Information Center Configuration Wizard to map
the MDIL codes to EMFC codes wherever possible. See "Parameter List" on page 4-5. Refer to the Information Center System Installation and
Service Manual.
MRx
The number of alerts and parameters originating from MRx and available for HL7 export are listed in "MRx Device Parameter List" on page 4-
59.
CareNet/SDN Monitors
The CareNet/SDN monitors (CMS, V24, etc.) connected to an Information Center system have limitations with the HL7 export interface. All
SDN alerts and bed parameters displayed with the patient windows of the Information Center are supported and are sent via HL7. Parameters,
from VueLink modules that do not appear at the Information Center display, settings, blood analysis parameters, and physio-calculation
parameters are not available. These require the presence of an M2384 Clinical Data Server in the system in order to be available in HL7 output.
The Vital Signs Reporting Integration Profile consists of two (2) HL7 transactions:
The unsolicited message interface sends only ORU messages to external systems. Also, it does not react to any messages sent to it. Any
messages or data that are sent to the Unsolicited Message Interface are ignored.
HL7 Acknowledgements
The HL7 specification states that the receiving system must acknowledge each message by returning an acknowledgment message back to the
sending system
The returning of acknowledgments does not enhance the reliability of TCP/IP connections because TCP/IP provides error-free transmission.
HL7 PDI treats acknowledgements as optional. Although a receiving system may send acknowledgments, it is recommended that they not send
them. PDI disregards them because they are not required. PDI does not resend messages that have not been acknowledged.
Mapping Communicate Vital Signs (CVS-1) Transaction to HL7 Messages (Unsolicited Observation Reporting)
The following table enumerates the messages supporting the CVS-1 transaction which is Observation Reporting.
One set of messages for each bed is sent at the configured time interval. In the example below:
• PID segment contains patient name and identification number of the patient as entered at the IIC.
• PV1 segment contains bed label, clinical unit name, network ID, and the bed ID. Network ID and bed ID are configured values that have
to be set for each bed in the IIC Config Wizard.
• OBR segment and OBX segment contain observations (may also contain alert information if alert messages are sent). The OBX segment
contains the time stamp for aperiodic parameters.
{OBX} Result
When the Information Center system comes online, it waits for client systems to establish TCP/IP socket connections to PDI. Multiple clients
can be online at the same time and may use the unsolicited messages interface and the polling interface at the same time. Data for one bed can
be sent to up to 6 client destinations. The bed to client assignment is configured in the Config Wizard at the Information Center. Refer to the
Information Center System Installation and Service manual.
The unsolicited messages interface and the polling interface use configured TCP/IP port numbers in order to allow external systems to choose
the service they want. PDI receives and only sends current data. Data is not stored, therefore data that has been on the network at an earlier
point in time cannot be retrieved and sent.
After a connection through the unsolicited messages interface is established, the HL7 Parameter Data Interface performs the following
functions:
• At a configured interval (5, 10, 30 or 60 seconds), transmits periodic parameter data, updates to aperiodic parameters, monitoring status,
alert data from monitoring devices, and patient information to the clients.
The HL7 Parameter Data Interface handles each connection's data independently. As long as the connection exists, PDI sends data. If the
connection is broken or closed in unsolicited mode, the client must re-establish the connection.
Auto-Unsolicited On
If configured in the Information Center Config Wizard, PDI automatically sends HL7 unsolicited data without a request from the client. If the
connection is broken or closed, PDI starts to reestablish the connection and continues to do so until the connection is reestablished or the
system is shut down.
Aperiodic data arrives at the HL7 server at varying, unpredictable intervals. it is sent on change only. If new aperiodic data has arrived at the
end of a sending interval, a set of ORU messages (each of which contains all aperiodic parameters, settings, and configurations from one bed)
is sent.
Some parameters (SpO2 and pTemp) are not always periodic or aperiodic. For example, when a telemetry unit is in SpO2 spot check mode so
that measurements are initiated manually by a clinician rather than an automatic schedule, SpO2 is delivered as aperiodic. When the telemetry
unit is configured for a fixed measurement interval, SpO2 is delivered as a periodic parameter.
The following section summarizes the ORU^R01 message profile definition for the Communicate Vital Signs (CVS-1) profile. The message is
for interval based observation reporting.
Note — ORU^R01 messages can be of several configured modes. Normal mode (or default) is not separately noted as this output format is the
base definition. Vista is a 2nd mode of output and this mode requires specific values for fields within the message segments. Other
configured values (patient identifiers, etc) will appear as configured in the HL7 output. Individual segment definitions will note specific values
as necessary.
This sub-section describes the profile definition at the Segment level. More specifically, it describes the fields that are required (or optional) for
a particular HL7 Segment Profile. It uses the standard HL7 notations as outlined in HL7 Chapter 2B. In addition a column is added to denote
additional information (possible values) for each element within the segment. This important for validation / testing purposes.
MSH Segment
See “Common MSH Segment Definition” on page 4-32 for additional details.
PID Segment
See “Common PID Segment Definition” on page 4-36 for additional details.
PV1 Segment
See “Common PV1 Segment Definition” on page 4-41 for additional details.
OBR Segment
See “Common OBR Segment Definition” on page 4-45 for additional details.
OBX Segment
See “Common OBX Segment Definition” on page 4-46 for additional details.
Not supported for CVS-1 transactions. ACK messages received are ignored.
Acknowledgements Diagram
Sample Messages
Unsolicited Observation Reporting (ORU) - Patient data and vital sign parameters. Contains this information:
Mapping Communicate Vital Signs (CVS-2) Transaction to HL7 Messages - Query Mode
The following table enumerates the messages supporting the CVS-1 transaction which is Observation Reporting.
After a connection through the polling interface is established, PDI transmits data upon request, with every query message generating exactly
one response message.
The response message can only contain data for beds that were assigned to the client performing the query. The maximum query response time
is 20 seconds, assuming that the queries are executed one at a time. If more than one query is executed at a time, the queries will be serialized
and the query response time may increase accordingly. This performance is delivered in parallel to all other services running on the Information
Center.
This section describes the three types (QRY, ORF, and ACK) of HL7 (version 2.x) messages for use with PDI polling interface. The polling
interface is limited to processing these message types in the pattern shown below. Messages are processed one by one with every query
message generating exactly one response message. Periodic parameters are always sent with their current value. Averaged values are not
accessible via the polling interface.
Y)
R
(Q
ge
sa
es
M
ry
ue
Q
PDI polling interface External System
K)
t( r
en F) o
AC
em R
d g (O
le se
ow on
kn sp
ac e
e R
tiv ery
ga u
ne Q
The above picture illustrates how the polling interface operates. The HL7 standard supports many message types, but only three types of
messages are required to support the data sent through the polling interface. The message definitions for the messages used are less restrictive
compared to the original HL7 message definition. This allows the PDI to work even with systems that have a simplified HL7 interface.
Compatibility with HL7 is not reduced through this approach.
The polling interface serves external systems according to a query-response pattern. It processes only three types of messages:
If a query asks for data of multiple beds, then the response message contains all data in a single response message. This response message may
become larger than 1MByte in size if data from many beds is requested. Each query returns ALL parameters, settings and device data that is
available for the requested beds. This is due to the fact that the polling interface is not capable of knowing which data has been sent to the
requesting system before. In contrast to the unsolicited messages interface, the polling interface does not store information on which parameters
/ settings have been sent to the external system previously. It is the requesting system's responsibility to check whether any parameter value,
setting or device information has changed since the last query:
• The change of aperiodic parameters can be determined by looking at their time stamp. If the time stamp has changed compared to the last
query, this implies that a new measurement has taken place.
• The change of settings can be determined by looking at whether the settings value has changed. If a setting is not sent anymore, the
setting has disappeared (possibly due to the fact that the device it was generated by was turned off) and should be treated as discontinued.
• The existence of devices (coded as CONFIGURATION parameters) can be determined through the existence of this specific parameter
in the message. If a parameter for such a device is not sent anymore on a subsequent query, then the device must be treated as
disappeared.
• The method of sending a NULL value for disappeared settings / devices as with the unsolicited messages interface is not used anymore.
The following section summarizes the ORF^R04 message profile definition for the Communicate Vital Signs (CVS-2) profile. The message is
for interval based query mode for vital signs data.
Note — ORF^R04 messages can be of several configured modes. Normal mode (or default) is not separately noted as this output format is the
base definition. Vista is a second mode of output. This mode requires specific values for fields within the message segments. Other configured
values (patient identifiers, etc) will appear as configured in the HL7 output. Individual segment definitions will note specific values as
necessary.
Message
MSA RE [0..1]
Acknowledgement
[{OBR}] Observation Reporting R [1..n] 7 Where n = number of beds in the overall message
This sub-section describes the profile definition at the Segment level. More specifically, it describes the fields that are required (or optional) for
a particular HL7 Segment Profile. It uses the standard HL7 notations as outlined in HL7 Chapter 2B. In addition a column is added to denote
additional information (possible values) for each element within the segment. This important for validation / testing purposes.
MSH Segment
See “Common MSH Segment Definition” on page 4-32 for additional details.
QRD Segment
PDI uses the following fields within the QRD segment. The description field provides information as to how PDI implements the field.
8 60 XCN R [1..1] Who subject filter HL7PDI uses only the beginning 3 components of this field.
The format is:
<ID number>^<family name>^<given name>
9 60 CE R [1..1] What subject filter Must be RES for results in query and in response
Processing Rules:
• Query date/time is ignored by the PDI polling interface, but the given value is sent back to the sender of the query in the query response.
The external system should supply this value in order to be HL7 compliant.
• Queries must always have query format code "R" and query priority "I". If these fields are empty or have a different content this is
treated as an error condition.
• Query ID must be non-null and not empty. It is not processed but sent back to the query sender in the query response. PDI does not
control whether control IDs are unique.
• The quantity in Quantity limited requests is ignored
Examples:
This message requests data from the patient with the medical record number of MRN331:
MSH|^~\&|||||20041007135100||QRY^R02|HP8565435191|P|2.x.1
QRD|20041007135100|R|I|Q839572||||MRN331|RES
QRF|MON
This message requests data from the patient with the medical record number MRN331 and from the patient with the medical record number
R1443:
MSH|^~\&|||||20041007135100||QRY^R02|HP8565435191|P|2.x.1
QRD|20041007135100|R|I|Q839572||||MRN331~R1443|RES
QRF|MON
This message requests data from the patients Roberta Adams and Thomas Miller:
MSH|^~\&|||||20041007135100||QRY^R02|HP8565435191|P|2.x.1
QRD|20041007135100|R|I|Q839572||||^Adams^Roberta~^Miller^Thomas|RES
QRF|MON
QRF Segment
PDI uses the following fields within the QRF segment. The description field provides information as to how PDI implements the field.
Processing Rules:
• All qualifiers except for the Other query subject filter are ignored on input and left empty in the query response.
• The Other query subject filter consists of a list of repeated string fields, each of which represents a bed location. Bed locations may either
be specified by the bed label that is assigned to the bed or by a coding scheme that uses a bed ID and a network ID: *<network ID> -
<bed ID>
Specifications by bed label and by bed ID and network ID may be mixed in a single query. Bed ID and network ID uniquely identify the
bed connected. If the bed location list is empty, the query is for all locations. Alternatively, the whole QRF segment can be omitted in
this case. An example of such a bed list follows: *1-11~ICU 12~CCU 4~*2-6. If a bed matches multiple criteria it is included in the
response only once.
MSA Segment
The following defines the MSA Segment used in CVS-2 transactions. This segment is used only to respond to faulted query messages received.
Note — The (ERR) Segment (optional in an ACK message) is never sent by this product.
PDI uses the following fields within the QRF segment. The description field provides information as to how PDI implements the field.
2 20 ST R [1..1] Message Control ID Contains the message control ID that came with the requesting
QRY query message. This allows the client to map a response
message to the corresponding request.
3 80 ST R [1..1] Text Message In case of errors or rejects, the text message contains a textual
description of the reason for this event. Typical texts would be:
• “Message type not supported”
• “Incorrect message syntax”
Examples:
PID Segment
See “Common PID Segment Definition” on page 4-36 for additional details.
PV1 Segment
See “Common PV1 Segment Definition” on page 4-41 for additional details.
OBR Segment
See “Common OBR Segment Definition” on page 4-45 for additional details.
OBX Segment
See “Common OBX Segment Definition” on page 4-46 for additional details.
The acknowledgement message (ACK) is only used if the message received is incorrect or not supported and can therefore not be processed. It
has the following structure:
MSH Message Header
MSA Message Acknowledgement
where:
• The MSA segment contains an acknowledgement code and the corresponding message control ID along with an error string in case of an
error.
Example
MSH|^~\&|HP HL7-CE|BAYKPW|||198808181126||ACK^|MSG00002|P|2.x
MSA|AE|MSG00001|Incorrect Message Syntax
The PDI polling interface implements the following error handling rules.
External system sends HL7 message with incorrect low-level protocol Message is ignored - no further reaction
External system sends HL7 message with incorrect message syntax Message is either ignored (if it is not identifiable as anything like
HL7) or an ACK message with a negative acknowledgement is sent
back
External system sends HL7 message with unsupported message type ACK message with a negative acknowledgement is sent back that
contains description of the error
Sample Messages
The query message (QRY) is used to request current parameter data. It triggers the event R02 (query for results of an observation). QRY
messages have the following structure
MSH Message Header
QRD Query definition
[QRF] Query filter
where:
• The MSH segment contains an acknowledgement code and the corresponding message control ID along with an error string in case of an
error.
• The QRD segment specifies the data and time of the query, the format code, the priority and some query filter information. Most
important is the Who Subject, where data for specific patient information can be requested. See “QRD Segment” on page 4-18.
• The QRF segment specifies the current data from the requested beds.
Examples:
This message requests data from the patient James Miller who has a medical record number of MRN999:
MSH|^~\&|||||20041007135100||QRY^R02|HP8565435191|P|2.x.1
QRD|20041007135100|R|I|Q839572||||MRN999^Miller^James|RES
QRF|MON
ORF Message
The query response message (ORF) is used to report parameter data as a reply to a query. ORF messages have the following structure:
MSH Message Header
MSA Message Acknowledgement
QRD Query definition (from QRY message)
[QRF] Query filter (from QRY message)
{
PID Patient Identification
PV1 Patient Visit
{OBRObservations Report ID
{OBX} Result
}
}
}
where:
• The MSA segment contains an acknowledgement code and the corresponding message control ID along with an error string in case of an
error.
• The QRD segment repeats the corresponding query definition.
• The QRF segment repeats the corresponding query filter definition.
• The PID segment contains the patient ID and name.
• The PV1 segment specifies the bed to be accessed along with the patient class if the query refers to current data from the CareNet.
• The OBR segment contains the timestamp (in ISO format) of the OBX parameters that follow.
• The QBX segment contains the result for the timestamp specified in the preceding OBR segment.
MSH|^~\&|||||||ORF^R04|HP856522134|P|2.x
MSA|AA|HP8565435191
QRD|19970731145557|R|I|Q839572|||||RES
QRF|MON||||Bed1~Bed2~*1-12
PID|||37584-23||John Smith
PV1||I|^^Bed2&0&0
OBR|||||||19970731145558
OBX||ST|33040^Model^SDN|0|SDN Broadcast||||||F||CONFIGURATION
OBX||NM|96^AWRR^SDN|0|168||||||F
OBX||NM|208^PIP^SDN|0|38||||||F
OBX||ST|32920^sMode^SDN|0|MONITORING||||||F||SETTING
OBX||ST|33040^Model^SDN|1|Hamilton Veolar||||||F||CONFIGURATION
OBX||NM|132^Tblood^SDN|1|31.2|C|||||F
OBX||NM|116^IMCO2^SDN|1|10.0|%|||||F
OBX||NM|65^ABP S^SDN|1|103|mmHg|0^0||||F
OBX||NM|66^ABP D^SDN|1|50|mmHg|0^0||||F
OBX||NM|67^ABP M^SDN|1|103|mmHg|0^0||||F
OBX||NM|112^ETCO2^SDN|1|10.00|%|||||F
OBX||NM|1105^UVP S^SDN|1|100.0|mmHg|0.0^0.0||||F
OBX||NM|1106^UVP D^SDN|1|100.0|mmHg|0.0^0.0||||F
OBX||NM|1107^UVP M^SDN|1|100.0|mmHg|0.0^0.0||||F
OBX||NM|516^Tskin^SDN|1|34.5|C|||||F
OBX||NM|1025^P5 S^SDN|1|200.0|mmHg|100.0^180.0||||F||APERIODIC|19970731144605
OBX||NM|1026^P5 D^SDN|1|100.0|mmHg|20.0^95.0||||F||APERIODIC|19970731144605
OBX||NM|1027^P5 M^SDN|1|150.0|mmHg|100.0^170.0||||F||APERIODIC|19970731144605
OBX||NM|1728^Pmean^SDN|1|1.0|cmH2O|||||F
OBX||NM|1720^MV^SDN|1|18.80|l/min|||||F
OBX||ST|33216^sGasPr^SDN|1|Y-PIECE||||||F||SETTING
OBX||ST|33220^sO2Pr^SDN|1|Y-PIECE||||||F||SETTING
OBX||ST|33224^sCircl^SDN|1|NON REBR||||||F||SETTING
OBX||NM|32776^sTV^SDN|1|1.05|l|||||F||SETTING
OBX||ST|33040^Model^SDN|64|DAP Internal Source||||||F||CONFIGURATION
OBX||ST|136^VPB^SDN|64|Non-paced mode||||||F
PID|||37234-78||Peter Miller
PV1||I|^^&12&1
OBR|||||||19970731145558
OBX||ST|33040^Model^SDN|0|SDN Broadcast||||||F||CONFIGURATION
OBX||NM|96^AWRR^SDN|0|168||||||F
OBX||NM|208^PIP^SDN|0|38||||||F
OBX||ST|32920^sMode^SDN|0|MONITORING||||||F||SETTING
OBX||NM|89^NBP S^SDN|0|140||||||F||APERIODIC|19970731144607
OBX||NM|90^NBP D^SDN|0|80||||||F||APERIODIC|19970731144607
OBX||NM|91^NBP M^SDN|0|110||||||F||APERIODIC|19970731144607
OBX||ST|33040^Model^SDN|64|DAP Internal Source||||||F||CONFIGURATION
OBX||ST|136^VPB^SDN|64|Non-paced mode||||||F
The SDN Coding example message is a response to the previous QRY message example. In case data for a requested bed does not appear in the
ORF response message (i.e. Bed1 in the example) the bedside monitor might be switched off and not delivering data, or the bed might not be
assigned to the client that sent the query. The bed > client assignment is configured in the Information Center Configuration Wizard. Refer to
the IntelliVue Information Center Installation and Service Manual.
The inclusion of a PV1 segment in an ORF message does not conform to the HL7 definition. The inclusion of the PV1 is required as it contains
the identification of the bed. As there is no safe way to identify data through patient name or number, the bed identification is absolutely crucial
and cannot be omitted.
Sample ACK
The network management (NMD) message distributes the current date and time setting of the PDI system. Time information is obtained from
the IIC system.
Syntax:
MSH message header
NCK system clock
[NTE] note/comment
• The NCK segment specifies the time used by the PDI in ISO format (year month day hour minute second).
• The NTE segment is not used.
Time information is sent in network management messages immediately upon connection startup and every 60 seconds thereafter. The time
information used is configured at the IntelliVue Information Center (IIC); transmission of time information can be turned off by clearing the
Send time Messages checkbox.
Note — These are configuration parameters that are set in IIC Config Wizard. Refer to the IntelliVue Information Center Installation and
Service Guide for detailed information.
The following table enumerates the messages supporting the CNT-1 (Communicate Network Time) transaction which is available as an option
for all other transactions except CVS-2 (query mode).
CNT-1
The following section summarizes the Network Management (NMD) message profile definition for the Communicate Network Time (CNT-1)
transaction. The message is sent each minute for any configured client.
This sub-section describes the profile definition at the Segment level. More specifically, it describes the fields that are required (or optional) for
a particular HL7 Segment Profile. It uses the standard HL7 notations as outlined in HL7 Chapter 2B. In addition a column is added to denote
additional information (possible values) for each element within the segment. This important for validation / testing purposes.
MSH Segment
See “Common MSH Segment Definition” on page 4-32 for additional details.
NCK Segment
NMD Example:
The time is sent in ISO format (year month day hour minute second).
MSH|^~\&|||||||NMD|HP104220882017993|P|2.x||||||8859/1<CR>
NCK|20030110152700<CR>
The following MSH Segment definition is common across all integration profiles. Specific values for each integration profile are specified and
common values are also noted. Required values not mentioned are system-defined at run time.
SEQ LEN DT Usage Card. Item# Item # Element Name Message Profile: Values
1 1 ST R [1..1] 00001 Field Separator All: | (ASCII 124)
2 4 ST R [1..1] 00002 Encoding Chars All: ^~\& (ASCII 94, 126, 92,
and 38, respectively)
4 227 HD RE [0..1] 0362 00004 Sending Facility CVS-1, CVS-2 (Vista): Vista also
supports Institution ID set in
Config Wizard
5 227 HD RE [0..1] 0361 00005 Receiving App CVS-1, CVS-2 (Vista): MDHL-
OUT Not used otherwise
6 227 HD RE [0..1] 0362 00006 Receiving Facility CVS-1, CVS-2 (Vista): Vista
Not used otherwise
SEQ LEN DT Usage Card. Item# Item # Element Name Message Profile: Values
10 20 ST R [1..1] 00010 Message Control Id CPD-1 and CVS-1, CVS-2: HP
followed by unique alphanumeric
ID
PDI uses the following fields within the MSH segment. The description field provides information as to how PDI implements the field.
9 15 R [1..1] Message Type Either NMD for network time messages or ORU for
MSG parameter reporting messages.
12 60 VID R [1..1] Version ID Version of the HL7 protocol transmitted. Always set to
2.3 but the output is usable with systems expecting
versions 2.3 to 2.5. See “Deviations from HL7 Standard”,
page 1-4.
Example:
MSH|^~\&|||||||NMD|HP104220882017993|P|2.x||||||8859/1<CR>
PDI uses the following fields within the MSH segment. The description field provides information as to how PDI implements the field.
2 4 ST R [1..1] Encoding Characters Contains the component separator, repetition separator, escape
character, and subcomponent separator.
7 26 TS R [1..1] Date/Time of Message Ignored in incoming messages; sent with outgoing messages.
9 15 R [1..1] Message Type Either QRY for query messages or ORF for query response
MSG messages or ACK in case of an error.
12 60 VID R [1..1] Version ID Ignored in incoming messages. Version of the HL7 protocol
transmitted. Always set to 2.x for outgoing messages.
18 16 ID R [1..1] Character Set Ignored in incoming messages. For outgoing messages always
8859/1 (for the ISO 8859-1 character set)
Example:
MSH|^~\&|||||||ORF^R04|HP8565435191|P|2.x<CR>
The following PID Segment definition is common across all integration profiles. Specific values for each integration profile are specified and
common values are also noted.
SEQ LEN DT Usage Card. TBL# Item # Element Name Message Profile: Values
1 4 SI X [0..0] 00104 Set ID - PID
CVS-1, CVS-2:
MRNValue^^^^MR~VisitNumb
erValue^^^^VN~AlternateIDVa
lue^^^^U
SEQ LEN DT Usage Card. TBL# Item # Element Name Message Profile: Values
8 1 IS R [0..1] 01 00111 Administrative Sex
9 250 XPN X [0..0] 00112 Patient Alias
10 250 CE X [0..0] 0005 00113 Race
11 250 XAD X [0..0] 00114 Patient Address
12 4 IS X [0..0] 289 00115 County Code
13 250 XTN X [0..0] 00116 Phone Number - Home
14 250 XTN X [0..0] 00117 Phone Num - Business
15 250 CE X [0..0] 0296 00118 Primary Language
16 250 CE X [0..0] 0002 00119 Marital Status
17 250 CE X [0..0] 0006 00120 Religion
18 250 CX X [0..0] 00121 Patient Acct. Number
19 16 ST X [0..0] 00122 SSN Number - Patient
20 25 DLN X [0..0] 00123 Driver's License
Number
21 250 CX X [0..0] 00124 Mother's Identifier
22 250 CE X [0..0] 0189 00125 Ethnic Group
23 250 ST X [0..0] 00126 Birth Place
24 1 ID X [0..0] 0136 00127 Mult. Birth Indicator
25 2 NM X [0..0] 00128 Birth Order
26 250 CE X [0..0] 0171 00129 Citizenship
27 250 CE X [0..0] 0172 00130 Vet Military Status
28 250 CE X [0..0] 0212 00739 Nationality
SEQ LEN DT Usage Card. TBL# Item # Element Name Message Profile: Values
29 26 TS X [0..0] 00740 Patient Death Date/
Time
30 1 ID X [0..0] 0136 00741 Patient Death Indicator
31 1 ID X [0..0] 0136 01535 Identity Unknown
Indicator
32 20 IS X [0..0] 0445 01536 Identity Reliability
Code
33 26 TS X [0..0] 01537 Last Update Date/
Time
34 241 HD X [0..0] 01538 Last Update Facility
35 250 CE X [0..0] 0446 01539 Species Code
36 250 CE X [0..0] 0447 01540 Breed Code
37 80 ST X [0..0] 01541 Strain
38 250 CE X [0..0] 0429 01542 Production Class Code
39 250 CWE X [0..0] 0171 01840 Tribal Citizenship
PDI uses the following fields within the PID segment. The description field provides information as to how PDI implements the field.
5 250 XPN R [1..1] Patient Name Contains the patient name as entered at the Information Center.
Format depends on the configured Message Type. Refer to the
IIC Installation and Service Guide.
Config Wizard may optionally include Middle Name.
For example,
Lastname^FirstName^MiddleName
7 26 TS R [0..1] Date/Time Birth Contains the date of birth as entered at the Information Center.
The format is YYYYMMDD. If no data is entered at the IIC, the
field contains NULL value (“”).
This field is not used if configured Message Type is PDS
Compatible.
8 1 IS R [0..1] Sex Contains the sex of the patient as entered at the IIC
The format is:
Male: M
Female: F
Unknown: U
This field is not used if configured Message Type is PDS
Compatible.
With PDS (Patient Data Server) and the Clinical Data Server (CDS), the patient name are not sent in accordance with the HL7 standard. If the
Message Type configuration is not set to PDS Compatible, the HL7 Patient Data Interface uses the field components Family Name and Given
Name for the HL7 output which is in accordance to the HL7 standard.
Example:
PDS Compatible:
PID|||394865||Robert Miller<CR>
PID|||MRNXR||Johnson^Robert||19110508|M<CR>
The format of certain HL7 output fields depends on the message type setting configured in the Information Center Configuration Wizard (refer
to the Information Center System Installation and Configuration Manual.)
EMFC Coding/
EMFC Coding MDIL Coding
PDS Compatible
PDI uses the following fields within the PID segment. The description field provides information as to how PDI implements the field.
The following PV1 Segment definition is common across all integration profiles. Specific values for each integration profile are specified and
common values are also noted.
SEQ LEN DT Usage Card. HL7 TBL# Item # Element Name Message Profile: Values
1 4 SI X [0..0] 00131 Set ID - PV1
SEQ LEN DT Usage Card. HL7 TBL# Item # Element Name Message Profile: Values
6 80 PL X [0..0] 00136 Prior Patient
Location
PDI uses the following fields within the PV1 segment. The description field provides information as to how PDI implements the field.
The parameters network id and bed id refer to the SDN/Carenet network number and the branch number where a monitor is connected.
Example:
PV1||I|ICU^^Bed14&14&1<CR>
PDI uses the following fields within the PV1 segment. The description field provides information as to how PDI implements the field.
The following OBR Segment definition is common across all integration profiles. Specific values for each integration profile are specified and
common values are also noted. The OBR segment is sent in ORU messages to report parameter data. There is OBR for each time stamp (except
for the aperiodic data which has its own) in the message.
SEQ LEN DT Usage Card. HL7 TBL# Item # Element Name Message Profile: Values
1 4 SI X [0..0] 00237 Set ID OBR
The following OBX Segment definition is common across all integration profiles. Specific values for each integration profile are specified and
common values are also noted.
SEQ LEN DT Usage Card. HL7 TBL# Item # Element Name Message Profile: Values
1 4 SI X [0..0] 00569 Set ID – OBX
2 2 ID R [1..1] 0125 00570 Value Type CVS-1, CVS-2: NM, ST TX
3 250 CE R [1..1] 00571 Observation CVS-1, CVS-2 <MDIL
Identifier identifier>^<text>^<MDIL>
4 20 ST R [1..1] 00572 Observation Sub-ID “Overview History of OBX
Segment Operation (CVS-1 and
CVS-2 Transactions)” on
page 4-47
SEQ LEN DT Usage Card. HL7 TBL# Item # Element Name Message Profile: Values
13 20 ST RE [0..1] 00581 User Defined All: PERIODIC, APERIODIC,
Access Checks SETTING, CONFIGURATION
The OBX segment is sent in ORU messages to report parameter data, settings, and device configuration. It is also used for reporting alert states
if the interface has been configured for sending alert messages of the monitor. The format of certain HL7 output fields depends on the message
type setting configured in the Information Center Configuration Wizard (refer to the Information Center System Installation and Service
Manual.)
• OBX for periodic data is sent at 5, 10, 30 or 60 sec interval. An OBX for aperiodic data is sent only upon change.
• OBX for settings is sent only when connection is first established and when settings change. (The disappearance of a setting or a change
in the validity of a parameter is treated as a change.)
• OBX for alerts is sent only when the monitor currently is in alert state and the Information Center is configured to send alerts. Several
alerts can be present at the same time. In this case, all alerts which are present at a certain time stamp specified in the OBR segment are
sent with the following OBX segments. As soon as an alert is not displayed at the monitor anymore (either because it has been
acknowledged or no longer exists), the alert disappears in the corresponding OBX segment. The beginning and the end of an alert can be
determined by its appearance in an OBX segment.
PDI uses the following fields in the OBX segment:
3 250 CE R [1..1] Observation Identifier This field contains a unique identifier for the
observation. The format depends on the Message Type
configuration setting.
4 20 ST R [1..1] Observation Sub-ID Number between 0 and 67 that identifies the device that
provides the data
In case of a MDIL-alert observation, field contains a
sequence number. Alert observations of a certain alert
type will use a sequence number that starts with 1 and
will increase by 1 with each alert observation of the
same alert type.
14 26 TS RE [0..1] Date/Time of Observation Date and time of the measurement of the parameter in
ISO format (YYYYMMDDHHMMSS)
Only present with APERIODIC parameters
This field contains a unique identifier for the observation. The used format is:
The table below lists special device ID. The device name sent depends on the IIC HL7 Configuration Message Type setting.
Data
Device ID Device Name Device Name
Source
Note — EMFC Coding and EMFC with PDS Compatible codes are provided for backward compatibility only and may not be supported
in future releases of the Information Center. MDIL Coding is recommended because more parameters can be mapped. Parameter labels may
be different from original Philips CareNet labels.
Parameter Types
• If the User Defined Access Checks field is empty or contains, PERIODIC, the parameter is a periodic parameter sent at the
intervals specified in the configuration.
• A value of APERIODIC indicates an aperiodic parameter that is sent only when a new measurement is made. An aperiodic parameter
usually contains a time stamp.
• A value of SETTING indicates a setting at the monitor or at a device connected via VueLink. Settings are sent when a new connection to
the Unsolicited Message Interface is established and when a change occurs. Settings remain valid until they are explicitly changed or
explicitly disappear. The disappearance of a setting is indicated by the NULL value ("") in the parameter value field. Settings contain no
time stamp.
• If the value is CONFIGURATION, the value type is ST (string) and provides a description of the device from which the parameter
comes. Configuration values are sent only at connection startup or when a new device appears (is attached via VueLink). When a device
disappears, a NULL value (“”) is sent for the device.
Special Parameters:
Two EMFC parameters do not originate from a device, but are generated by the Patient Data Interface to provide additional information.
• sMode (EMFC 32920/MDIL 0402-f85f) - String value setting that provides information about the operating mode of the attached patient
monitor. Values are:
• MONITORING - Monitoring mode (provided data for this bed is real)
• DEMO - Demonstration mode (provided data for this bed is generated artificially by the monitor for demonstrations or training)
• CONFIGURATION - Configuration mode (not available if configured for PDS Compatible)
• SERVICING - Service mode (not available if configured for PDS Compatible)
• Model (EMFC 33040/MDIL 0002-f887) – String-valued configuration parameter that provides information about the device generating
the data (device name shown in Table 2-2). When a device disappears, this parameter is sent again with the same device ID and a NULL
(“”) value.
The following table shows the possible monitoring mode strings depending on the Message Type configuration option.
The following table summarizes all OBX fields that are dependent on the Message Type configuration option.
Parameter Results: OBX EMFC-Code ^ Label ^ SDN EMFC-Code ^ Label ^ SDN MDIL-Code ^ Label ^ MDIL
Segment, Observation ID field
Alert results: OBX Segment, Code ^ AlertLabel ^ SDN- Code ^ AlertLabel ^ MDIL- Code ^ AlertLabel ^ MDIL-
Observation ID ALARM ALARM ALARM
Parameter Identifiers
HL7 Parameter Data Interface (HL7PDI) uses numeric codes from the Medical Device Interface Language (MDIL) standard nomenclature to
uniquely identify parameter, alert, and unit sources. The identifiers are sent over HL7 with the following format:
<Partition>-<TermCode>
The values for the partition and TermCode are hexadecimal values between 0x0000 and 0xffff, which are separated in the output with a
hyphen.
If required HL7PDI can be configured to send EMFC (Extended Medical Function Codes) for the parameter identifiers, which are known from
the Philips CareNet monitoring system instead of MDIL. This is dependent on the Message Type that is configured in the Information Center
Configuration Wizard. (See Information Center System Installation and Service Guide.) If EMFC Coding or PDS Compatible settings are
configured, EMFC codes are used as the parameter identifiers for all parameters sent in the HL7 output.
The label strings in this chapter are valid only for installations with English language software. When used in other countries, the label strings
vary according to how they are translated into the respective language. Philips recommends that you use the numeric parameter identifiers
instead of parameter labels for parameter identification when using the Parameter Data Interface.
EMFC Coding and EMFC with PDS compatible codes are provided for backward compatibility only and may not be available in future
releases of the Information Center. It is recommended to use the MDIL codes as a limited number of parameters cannot be mapped to an
EMFC. Parameter labels might be different from the original Philips CareNet labels.
Coding Systems
The following table shows the different coding systems used by the HL7 Parameter Data Interface and the format of the according identifier
and text fields.
MDIL Contains a unique parameter/unit identifier that has the following Contains the parameter label string or the
format: <Partition>-<TermCode> unit string
The values for Partition and TermCode are hexadecimal values
between 0x0000 and 0xffff and follow the MDIL standard
nomenclature.
Partition may be one of the following values:
0x0002 - SCADA partition
0x0401 - EMFC partition
0x0004 - Dimension partition (for units)
0x0402 - Settings partition
MDIL-ALERT Contains the alert type (unique ID for the severity of the alert) Contains the alert message
8 - Yellow Inop
7 - Red Inop
6 - Soft Inop
5 - Hard Inop
4 - Severe Inop
3 - Short Yellow Alarm
2 - Yellow Alarm
1 - Red Alarm
SDN Contains the unique EMFC parameter identifier. Numeric decimal Contains the parameter label string
value between 0 and 65535
SDN-ALARM Contains the alert type (unique ID for the severity of the alert) Contains the alert message
1 - Red Alarm
2 - Yellow Alarm
3 - Green Alarm
Parameter Flow
Under unusual circumstances, when numerous modules and parameters are active at a particular bedside, there may be some parameters that do
not appear in the HL7 output. To understand these limits, parameters must be divided into two categories:
The first category includes certain high-parameter-count data sources from IntelliVue monitors that are handled specially for HL7 output
(complex parameters). These are VueLink modules, EEG modules, and the monitor’s Hemodynamic, Ventilation, and Oxygenation calculation
screens.
• All parameters from these sources are always present in HL7 output, no matter how many are coming from the bedside monitor and
connected modules.
• The special handling of this category of parameters is only available for IntelliVue monitors (i.e. not CareNet/SDN monitors).
• To collect HL7 data from VueLink, EEG and calculation parameters from CareNet/SDN monitors, it is necessary to use the M2384
Clinical Data Server.
• Parameters that come from VueLink modules have additional characteristics. New VueLink drivers are continuously added, which may
generate new data and parameters not included in the list below. In these cases:
– The label for these parameters can be found for a specific VueLink driver in the latest edition of the Philips M1032A VueLink
External Device Instructions for Use (part number M1032-9001x) or in the instructions provided with the VueLink driver.
– The codes for these parameters can be found by looking for the associated labels in a sample of the HL7 output from the
Information Center when the VueLink module is connected. Note that in a few cases (particularly for devices for which the driver
has not been developed by Philips) these new parameters may not yet have defined static codes. In this case the MDIL codes are
dynamically assigned in the range from 0002-ffc0 to 0002-fff8 (corresponding to 65472 to 65528 decimal). In the Parameter List
table, they are referred to as "Free Text". If the VueLink module is disconnected and then connected to another monitor, the same
parameter may have a different code in this range.
The second category of parameters includes all other parameters from monitors, modules, and measurement servers not mentioned above
(ordinary parameters). These are generally the parameters that can be seen in the Patient Window of the Information Center.
• There is a fixed limit (currently thirty) to the number of parameters in this category that can be processed at any one time from a
particular bed, and parameters beyond this limit will not appear in the HL7 output. The systolic, diastolic, and mean values associated
with a particular blood pressure measurement together count as only one parameter for this purpose. Similarly the inspired and end-tidal
values for a particular gas measured by the Anesthesia Gas Module together count as only one parameter.
• Measurement unit labels sent in the HL7 output for these parameters are controlled by the general configuration settings of the
Information Center, rather than by the settings of the module or monitor. If not configured correctly, it is possible for the monitors to be
measuring in one unit (bedside pressures in kPa), while the Information Center is configured for a different unit (pressures in mmHg). In
this case, the label mmHg is sent by the IIC in HL7 messages, along with numeric values from the monitors which are measured in kPa.
This can be avoided if unit configurations on the bedsides and on the IICs are consistent.
The following table lists all supported parameter identifier codes with their corresponding physiological source labels. This information
depends on the software revision on the monitor and the connected devices. Data transmitted by way of a VueLink or IntelliBridge device is
designated by a check in the VueLink/IntelliBridge column; the module depends on the version of the IntelliBridge and VueLink drivers and
the specification of the connected external device. With a particular software revision, the patient monitor may or may not export all of the
numerics specified in the table. The configuration of the patient monitor will also determine whether a numeric is exported. A numeric is only
available if the required measurement module is connected and if the specific measurement is activated. Some measurements require the
presence of more than one measurement module or may require special configuration steps to activate them.
Manually entered bedside data is exported as an aperiodic OBX with field 17 indicating the string MANUAL and field 14 contains the
timestamp that is generated by the bedside monitor when the clinical user confirmed the data.
The IIC Column, if checked, indicates support for parameters that do not come from the VueLink module.
Note — The following table e reflects all numerics that are sourced by IPM, Release H or earlier.
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
0002-4bc4 1960 ΔSpO2 Difference between two SpO2 Values (like numeric
Left - Right)
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
0002-f886 2908 Power Power required to the Air & Patient numeric
Temperature in incubator
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
0002-f8c7 2160 AGTLev Liquid Level in the anesthetic agent bottle numeric
0002-f8c8 2176 DESLev Liquid Level in the DESflurane bottle numeric
0002-f8c9 2168 ENFLev Liquid Level in the ENFlurane bottle numeric
0002-f8ca 2172 HALLev Liquid Level in the HALothane bottle numeric
0002-f8cb 2164 ISOLev Liquid Level in the ISOflurane bottle numeric
0002-f8cc 2180 SEVLev Liquid Level in the SEVoflurane bottle numeric
0002-f8cd 1752 HFMVin Inspired High Frequency Mandatory Minute numeric
Volume
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
0002-f975 4664 SlvPfl Slave Pump flow of Heart Lung Machine numeric
0002-f976 4668 SucPfl Suction Pump flow of Heart Lung Machine numeric
0002-f977 4672 AuxPfl Auxiliary Pump flow of Heart Lung Machine numeric
0002-f978 4676 PlePfl Main Cardioplegia Pump flow of Heart Lung numeric
Machine
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
0002-f97a 4696 AxOnTi Auxiliary Pump time since start of the numeric
ongoing plegia session
0002-f97b 4700 AxOffT Auxiliary Pump time since stop of the numeric
ongoing plegia session
0002-f980 4720 CpOffT Cardioplegia Main Pump time since stop of numeric
the ongoing plegia session
0002-f985 4740 CsOffT Cardioplegia Slave Pump time since stop of numeric
the ongoing plegia session
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
0002-f988 4752 CsPlTi Cardioplegia Slave Pump total plegia time numeric
0002-f989 4928 AVPU Alert, Voice, Pain, Unresponsive numeric
0002-f98a 4800 EWS Early Warning Score string
0002-f98b 4804 Concrn Determines if Caregiver should be concerned string
about patient status
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
0002-faf5 4956 STI Sharp Transient Intensity derived from EEG numeric
0402-4b48 33232 sTemp Setting: Desired Temperature for the setting
Incubator/Warmer
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
0402-68e0 33496 sKVO Setting: Keep Vein Open (KVO) Flow Rate setting
0402-68e4 33500 sDosRt Setting: Dose Rate setting
0402-7498 32784 sFIO2 Setting: Inspired Oxygen Concentration setting
0402-d00a 33504 sDrug Setting: Drug Name/Type setting
0402-d0b8 33508 sPuMod Setting: Pump Mode setting
0402-f0e0 33228 sTVin Setting: Inspired Tidal Volume setting
0402-f0ff 32792 sPltTi Setting: Plateau Time setting
0402-f103 33416 sHum Humidity from Incubator setting
0402-f876 33176 sAGT Setting: Vaporizer concentration setting
0402-f877 33200 sfgAir Setting: Total fresh gas air flow on the mixer setting
0402-f87e 33212 sfgN2O Setting: fresh gas N2O flow on the mixer setting
0402-f87f 33204 sfgO2 Setting: Fresh gas oxygen Flow on the mixer setting
0402-f881 33208 sfgFl Setting: Total fresh gas Flow on the mixer setting
0402-f8a6 33288 sRepTi Setting: Preset Train of Four repetition time setting
0402-f8af 33236 sUrTi Setting: Preset period of time for the UrVol setting
numeric
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
0402-f904 33160 sSens Setting: Assist Sensitivity. Used by the Bear setting
1000 Ventilator
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
0402-f919 40992 highO2 Alarm Limit: High Oxygen (O2) Alarm setting
Limit
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
0402-f91a 40988 lowO2 Alarm Limit: Low Oxygen (O2) Alarm Limit setting
0402-f91b 33016 sFlow Setting: Flow setting
0402-f91c 33272 sFlas Setting: Flow Assist level for the CPAP setting
mode
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
0402-f92e 33264 sPhigh Setting: part of the Evita 4 Airway Pressure setting
Release Ventilation Mode
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
0402-f94b 41004 highMV Alarm Limit: High Minute Volume Alarm setting
Limit
0402-f94c 40984 lowMV Alarm Limit: Low Minute Volume Alarm setting
Limit
0402-f94d 41012 highTV Alarm Limit: High Tidal Volume Alarm setting
Limit
0402-f94e 41008 lowTV Alarm Limit: Low Tidal Volume Alarm setting
Limit
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
0402-fa08 33468 sΔPEEP Setting: Delta pressure above Positive End- setting
Expiratory Pressure (PEEP)
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
VueLink
MDIL Code EMFC Code Parameter Label Description Type IIC
IntelliBridge
MRx Device Parameter List for Possible Coded Values for OBX.5
Physiological Calculation Parameter Identifiers for Possible Coded Values for OBX.5
Oxygenation Calculations
Hb 0002-7014 4128
PB 0002-f06b 4132
Ventilation Calculations
TV 0002-513c 4208
Vd 0002-51b0 4232
Hemodynamic Calculations
HR 0002-4182 4004
SV 0002-4b84 4032
SI 0002-f048 4068
0004-0000 No dimension
0004-0200 No dimension
0004-0220 % Percentage
0004-0500 m Meter
0004-0511 cm Centimeter
0004-0512 mm Millimeter
0004-0560 in Inch
0004-0640 l Liter
0004-0652 ml Milliliter
0004-06c0 g Gram
0004-06c3 kg Kilogram
0004-06e0 lb Pound
0004-0700 oz Ounce
0004-09c0 Hz Hertz
0004-0fd2 mW Milliwatt
0004-0fd4 nW Nanowatt
0004-0fd5 pW Picowatt
0004-1052 mA Milliampere
0004-1073 µC Microcoulomb
0004-10a0 V Volt
0004-10b2 mV Millivolt
0004-10b3 µV Microvolt
0004-1920 dB Decibel
Note — If Vista is enabled, field 1 is populated with a sequence number. This is shown below in the Single numeric periodic parameters
(MDIL coded) example only.
OBX||NM|0002-4a17^ABPm^MDIL|65|8|0004-0f20^mmHg^MDIL|||||F||APERIODIC|20030516150300<CR>
OBX||NM|0002-4b84^SV^MDIL|65|83.3|0004-0652^ml^MDIL|||||F||APERIODIC|20030516150300<CR>
OBX||NM|0002-4a1d^PAPs^MDIL|65|10|0004-0f20^mmHg^MDIL|||||F||APERIODIC|20030516150300<CR>
OBX||NM|0002-4a1e^PAPd^MDIL|65|55|0004-0f20^mmHg^MDIL|||||F||APERIODIC|20030516150300<CR>
OBX||NM|0002-4a1f^PAPm^MDIL|65|98|0004-0f20^mmHg^MDIL|||||F||APERIODIC|20030516150300<CR>
OBX||NM|0002-4b90^LCW^MDIL|65|-3.3|0004-0743^kg-m^MDIL|||||F||APERIODIC|20030516150300<CR>
OBX||NM|0002-4a24^PAWP^MDIL|65|56|0004-0f20^mmHg^MDIL|||||F||APERIODIC|20030516150300<CR>
OBX||NM|0002-4900^SVRI^MDIL|65|-151|0004-1780^DSm2/
cm5^MDIL|||||F||APERIODIC|20030516150300<CR>
OBX||NM|0002-4b94^RCW^MDIL|65|5.85|0004-0743^kg-m^MDIL|||||F||APERIODIC|20030516150300<CR>
OBX||NM|0002-f067^PVRI^MDIL|65|1585|0004-1780^DSm2/
cm5^MDIL|||||F||APERIODIC|20030516150300<CR>
OBX||NM|0002-4904^LVSWI^MDIL|65|-23.1|0004-0760^g-m/
m2^MDIL|||||F||APERIODIC|20030516150300<CR>
OBX||NM|0002-4b04^C.O.^MDIL|65|5.00|0004-0c00^l/min^MDIL|||||F||APERIODIC|20030516150300<CR>
OBX||NM|0002-f068^LCWI^MDIL|65|-1.4|0004-0763^kg-m/
m2^MDIL|||||F||APERIODIC|20030516150300<CR>
OBX||NM|0002-f069^RCWI^MDIL|65|2.48|0004-0763^kg-m/
m2^MDIL|||||F||APERIODIC|20030516150300<CR>
OBX||NM|0002-4908^RVSWI^MDIL|65|41.30|0004-0760^g-m/
m2^MDIL|||||F||APERIODIC|20030516150300<CR>
OBX||NM|0002-4b9c^LVSW^MDIL|65|-54.4|0004-0740^g-m^MDIL|||||F||APERIODIC|20030516150300<CR>
OBX||NM|0002-490c^C.I.^MDIL|65|2.12|0004-0b20^l/min/
m2^MDIL|||||F||APERIODIC|20030516150300<CR>
OBX||NM|0002-f071^BSA^MDIL|65|2.x6|0004-05c0^m2^MDIL|||||F||APERIODIC|20030516150300<CR>
OBX||NM|0002-4ba4^RVSW^MDIL|65|97.47|0004-0740^g-m^MDIL|||||F||APERIODIC|20030516150300<CR>
OBX||NM|0002-4a47^CVPm^MDIL|65|12|0004-0f20^mmHg^MDIL|||||F||APERIODIC|20030516150300<CR>
CE Data Type
CX Data Type
EI Data Type
HD Data Type
The PCD TF requires that a field of Data Type HD be populated with one of the following:
• The first component “Namespace ID” alone, which in this case contains a local identifier of the object
• All three components: “Namespace ID” containing the name of the object, “Universal ID” containing its universal OID, and “Universal
ID Type” containing the value ISO.
This data type is particularly used in this MessageSetting to identify facilities, applications and assigning authorities: sending and receiving
applications, sending and receiving facilities, last update facility, assigning authority of an identifier, etc.
PL Data Type
TS Data Type
PT Data Type
PT Processing Type
• When setting the Message Type configuration to PDS Compatible, the PID segment, Patient Name field contains the patient name in the
format FirstName LastName (separated by a space) which is not standard. If EMFC coding or MDIL coding is chosen, the patient name
format is LastName^FirstName which is standard.
• Polling Interface: The inclusion of a PV1 segment in the query response is not in conformance to the HL7 definition but required for PDI
as it contains the identification of the bed. As there is no safe way to identify data through patient name or number, the bed identification
is absolutely crucial and cannot be omitted.
• Polling Interface: Sending the sequence PID - PV1 - OBR - OBX multiple times for the same patient in a single query response is NOT
compliant to the HL7 specification but required in order to query the parameters of multiple beds in a single query.
International Characters
International characters are provided in the ISO 8859-1 character set, which covers most European languages. This character set is compatible
with the character set used in Microsoft® Windows® and contains equivalents for all characters that can be distributed on the network. East
European and Asian characters are not supported; for these countries, PDI uses the English language.
A
Standard HL7 Message Profile Definition Notation
Acknowledgements
The specific HL7 acknowledgements required and/or allowed for use with the specified static definition of the HL7 message profile shall be
defined. Specifically, the dynamic definition shall identify whether an accept and/or application level acknowledgement is allowed or required.
For any one static definition there may be one or more dynamic definition.
The dynamic definition shall define the conditions under which an accept and/or application level acknowledgement is expected.
• Always
• Never
• Only on success
• Only on error.
The Message Profile definition is a complete specification for an HL7 message. It is based on a message structure defined in the HL7 Standard.
The message code, trigger event, event description, role (Sender or Receiver) and, if applicable, the order control code will be provided. A
complete definition shall be defined at the message, segment, and field levels. A Message Profile definition is compliant in all aspects with the
HL7 defined standard message it profiles. However, the profile definition may define additional constraints on the standard HL7 message.
A message profile identifies only those specific elements of a standard HL7 message that are used in the exchange.
ADT^A01
MSH MS H
Segments/Segment Groups:
EVN EVN - Segment Usage
PID PID - Cardinality (min, max)
NK1 NK1 NK1 NK1 NK1 ... NK1 NK1 NK1 NK1 NK1 ...
PV1 P V1
... ...
Fields/Components:
- Field Usage (Optionality)
PV2 PV2 - Cardinality (min, max)
OBX
- Value Sets/Coding system
OBX
- Descriptions
AL1 AL1
... ...
Table definition
Table definitions will include statements of table conformance and, if available, the actual table elements supported.
This section discusses concepts common to each level of the message profile definition (message, segment and field). It uses the generic term
'element' to refer to segment groups, segments, fields, components and sub-components.
Cardinality
Cardinality identifies the minimum and maximum number of repetitions for a particular element (Segment Group, Segment or Field).
Cardinalities are expressed as a minimum-maximum pair of non-negative integers. A conformant application must always send at least the
minimum number of repetitions, and may never send more than the maximum number of repetitions.
There are two special values for cardinality. If the minimum number of repetitions is 0, the element may be omitted from a message. In certain
circumstances, the maximum number of repetitions may have no practical limit. In this case, it is identified as '*'. Examples of common
cardinality combinations are:
[0..1] Element may be omitted and it can have at most one Occurrence
[1..n] Element must appear at least once, and may repeat up to n times
[1..*] Element must appear at least once, and may repeat unlimited number of times
[m..n] Element must appear at least "m" and at most" n" times
Usage
Usage refers to the circumstances under which an element appears in a message. Some elements must always be present, others may never be
present, and others may only be present in certain circumstances. A set of codes has been defined to clearly identify the rules governing the
presence of a particular element.
The rules govern the expected behavior of the sending application and limited restrictions on the receiving application with respect to the
element. These usage codes expand/clarify the optionality codes defined in the HL7 standard.
RE Required but may be empty The element may be missing from the message, but must be sent by the sending application if there is
relevant data. A conforming sending application must be capable of providing all "RE" elements. If the
conforming sending application knows the required values for the element, then it must send that element.
If the conforming sending application does not know the required values, then that element will be omitted.
Receiving applications will be expected to process (save/print/archive/etc.) or ignore data contained in the
element, but must be able to successfully process the message if the element is omitted (no error message
should be generated because the element is missing).
O Optional This code indicates that the Usage for this element has not yet been defined. A usage of 'Optional' may not
be used in 'implementation' profiles (no-optionality profiles). Conformance may not be tested on an
Optional field. Narrower profiles may be defined based on this profile, and may assign any usage code to
the element.
CE Conditional but may be empty This usage has an associated condition predicate (See section 2.B.7.6, "Condition predicate").
If the predicate is satisfied:
If the conforming sending application knows the required values for the element, then the application must
send the element. If the conforming sending application does not know the values required for this element,
then the element shall be omitted. The conforming sending application must be capable of knowing the
element (when the predicate is true) for all 'CE' elements.
If the element is present, the conformant receiving application shall process (display/print/archive/etc.) or
ignore the values of that element. If the element is not present, the conformant receiving application shall
not raise an error due to the presence or absence of the element.
If the predicate is not satisfied:
The conformant sending application shall not populate the element.
The conformant receiving application may raise an application error if the element is present.
X Not supported For conformant sending applications, the element will not be sent. Conformant receiving applications may
ignore the element if it is sent, or may raise an application error.
Conformance usage codes are more specific than HL7 Optionality codes. Because of the requirement that message profile definition must be
compliant with the HL7 message definition it is derived from, there are restrictions on what usage codes may be assigned to an element based
on the HL7 Optionality.
C- Conditional C, CE, R
X - Not Supported X
Both usage and cardinality govern the appearance of a field and, therefore, a relationship exists between them. For purposes of message
profiles, the cardinality shall be constrained by the usage code. The constraints are:
• If the usage of an element is Required (R), the minimum cardinality for the element shall always be greater than or equal to 1.
• If the usage of an element is not Required (R) (i.e. any code other than 'R'), the minimum cardinality shall be 0 except in the following
condition:
If the profile author wishes to express a circumstance where an element will not always be present, but when present must have a minimum
number of repetitions greater than one, this may be indicated by specifying the non-required Usage code with the minimum cardinality
representing the minimum number of repetitions when the element is present. This would generally be expressed as (0,n..m), indicating that
permitted occurrences are either zero, or the range of n through m).
[0..1] RE The element must be supported, but may not always be present
[0..5] C If the condition predicate is true, there will be between 1 and 5 repetitions. If the predicate is
false, there will be 0 repetitions
[3..5] RE If any values for the element are sent, there must be at least 3 and no more than 5 repetitions.
However, the element may be absent (0 repetitions)
Condition Predicate
If the usage code of an element is C or CE, then a conditionality predicate must be associated with this element that identifies the conditions
under which the element must be or is allowed to be present. The predicate must be testable and based on other values within the message. This
predicate may be expressed as a mathematical expression or in text and may utilize operators such as equivalence, logical AND, logical OR and
NOT. The conforming sending and receiving applications shall both evaluate the predicate. When the Usage is not 'C' or 'CE', the conditionality
predicate will not be valued.
The message profile definition shall be documented using the HL7 abstract message syntax, with the addition of specifying cardinality and
usage for each of the segments contained within the message structure.The usage column shall be updated to reflect the usage of the segment or
group within this particular message profile definition.The cardinality column shall accurately reflect the minimum and maximum number of
repetitions of the field allowed for the segment or group within this particular message profile definition.
Database / XML
Segment ADT Message Usage Card Chapter Note Reference
Mapping
MSH Message Header R [1..1] 2 N/A
PV1 Patient Visit RE [0..1] 3 Visit, Location, The PV1 segment is only
Provider processed when PV1-19 is present.
Database / XML
Segment ADT Message Usage Card Chapter Note Reference
Mapping
[{DG1}] Diagnosis Information X [0..0] 6
[{ --PROCEDURE begin
}] --PROCEDURE end
[{ --INSURANCE begin
}] --INSURANCE end
Some segments and segment groups within the HL7 message are allowed to repeat. The cardinality of all the segments and groups within the
message shall be defined.
The segment level profile definition shall be documented using the HL7 segment attribute table format with the addition of specifying length,
usage and cardinality for each of the fields contained within the segment.
• The length column shall be updated to accurately reflect the maximum allowed length for the field within this segment definition.
• The usage column shall accurately reflect the usage of the field within this segment definition.
• The cardinality column shall accurately reflect the minimum and maximum number of repetitions of the field allowed for this segment
definition.
Element
SEQ LEN DT Usage Card. Note Reference
Name
1 4 SI X [0..0] 00104 Set ID not used
2 20 CX X [0..0] 00105
3 250 CX R [1..1] 00106
4 20 CX X [0..0] 00107
5 250 XPN R [1..1] 00108
6 250 XPN RE [0..1] 00109
Element
SEQ LEN DT Usage Card. Note Reference
Name
7 26 TS RE [0..1] 00110
8 1 IS RE [0..1] 0001 00111
9 250 XPN X [0..0] 00112
10 250 CE RE [0..*] 0005 00113
11 250 XAD RE [0..*] 00114
12 4 IS X [0..0] 0289 00115
19 16 ST RE [0..1] 00122
20 25 DLN RE [0..1] 00123
25 2 NM RE [0..1] 00128
26 250 CE X [0..0] 0171 00129
27 250 CE X [0..0] 0172 00130
Element
SEQ LEN DT Usage Card. Note Reference
Name
28 250 CE RE [0..1] 0212 00739
29 26 TS RE [0..1] 00740
30 1 ID X [0..0] 0136 00741
31 1 ID RE [0..1] 0136 01535
Field Definitions
The set of fields of each segment within the message profile definition shall be specified. If a segment occurs multiple times within a message
profile, it may be represented by different segment profiles. This shall be explicitly defined within the message level definition.
Field Cardinality
Some fields within a segment are allowed to repeat. The cardinality of all the fields within the segment shall be defined.
Field Usage
The usage of the field within a segment shall be defined consistent with the profile type, and using one of codes identified in the previously
defined Usage tables.
Data Type
The data type of the field within a segment shall be updated to accurately reflect the data type for the field within this segment definition.
Length
The length of the field within a segment shall be updated to accurately reflect the maximum allowed length for the field within this segment
definition.
Table Reference
The name of the table of the field within a segment shall be updated to accurately reflect the table used for the field within this segment
definition.
This column in the static definition specifies the database table where each segment, field, or component's data will be stored. In cases where a
segment is stored across multiple tables, a list of tables is provided. The value in this column serves as a general pointer to the location where
the data will be stored in the clinical database. This document is not intended to be a data dictionary.
This column includes a reference to a note about any conditions or logic that should be considered. This column also contains a reference to
any logic for conditional fields.
Each individual field within a segment shall be completely defined to eliminate any possible ambiguity. In cases where HL7 2.x field
descriptions are not sufficient, a precise semantic definition shall be specified.
The allowed code sets (table) for many fields within the HL7 Standard are specified as user-defined (data type IS) or HL7-defined (data type
ID) values. In these cases, the exact allowed code set shall be specified. These values shall be defined according to the specified scope of use.
Coded Entry (CE, CF, CWE, and CNE) type fields are specified as being populated based on coding systems. For each of these fields, the
specific coding system used shall be identified. Compliant applications are required to use the specified coding system, but may also use an
alternate coding system as supported by the data type (See the example within each data type definition).
Each component within composite fields shall be profiled. This requires defining the usage, length, data type, and data values of each of the
components. Where there are sub-components of a component, each of the sub-components shall also be profiled using the same method. With
the exception of cardinality, the rules for these definitions follow those for fields.
B
Parameter Data Interface vs. Clinical Data Server
Introduction
HL7 Parameter Data Interface (HL7PDI) is different from the Clinical Data Server HL7 interface in the following ways:
Sending Interval Unsolicited data export for periodic data can be configured Unsolicited data export for periodic data can be configured for
for 5, 10, 30 or 60 sec (default). every 15 sec up to every 3600 sec in 1 sec intervals (default is
30 sec)
Parameter Support See the list of parameters in “HL7 Data Output See the list of parameters in “HL7 Data Output
Considerations” on page B-8. Considerations” on page B-8.
Initial Aperiodic message Upon connection of a client to the unsolicited message Upon connection of a client to the unsolicited message
content interface, all current valid data in an initial aperiodic interface, only settings and configuration values is sent.
message (aperiodic parameters, settings, and configuration Aperiodic parameters are not sent in this initial message.
values) is sent
Alarm Limits Not supported Supported: Alarm limits for parameters received through the
DAP protocol
HL7 Data Output Control Allows data from one bed to be sent to one target client. List
of assigned beds is preconfigured
Bed ID/Network ID Not read from monitoring network, preconfigured values Read from monitoring network
Triple labels Uses the internal text resources to resolve parameter labels Generated by using the standard label and adding the
that contain triple values in a different format: extension for systolic, diastolic, and mean values:
LABELs LABEL S
LABELd LABEL D
LABELm LABEL M
NMD reply NMD messages are used to provide time information and
NOT to inform clients that they are not allowed to receive
data because they are not configured in the list of allowed
hosts. Connection refused socket message to the client is
sent.
DAP device No DAP Protocol support Shows data coming through the DAP protocol channel on a
separate device. Device name is DAP Internal Source, with the
device id of 64.
Monitoring data device Sends all data not coming from a VueLink device or Physio Sends parameters with EMFCs up to 255 (MFCs) on this
(or SDN Broadcast Calculation on the Monitoring Data Device (device ID 0) device 0, unit information non available on this device.
device) Parameter labels in english only
49 0002-f0a5 P1s P1 S
49 0401-0031 P_1s P1 S
50 0002-f0a6 P1d P1 D
50 0401-0032 P_1d P1 D
51 0002-f0a7 P1m P1 M
51 0401-0033 P_1m P1 M
53 0002-f0a9 P2s P2 S
53 0401-0035 P_2s P2 S
54 0002-f0aa P2d P2 D
54 0401-0036 P_2d P2 D
55 0002-f0ab P2m P2 M
55 0401-0037 P_2m P2 M
57 0002-f0ad P3s P3 S
57 0401-0039 P_3s P3 S
58 0002-f0ae P3d P3 D
58 0401-003a P_3d P3 D
59 0002-f0af P3m P3 M
59 0401-003b P_3m P3 M
61 0002-f0b1 P4s P4 S
61 0401-003d P_4s P4 S
62 0002-f0b2 P4d P4 D
62 0401-003e P_4d P4 D
63 0002-f0b3 P4m P4 M
63 0401-003f P_4m P4 M
Supported Supported
Parameter type
by HL7PDI on CDS HL7