Appendix D - TVH OMCL RX Interfaces

HL7 Pharmacy Interface
Specifications
67-3079 Rev G
About Omnicell
Omnicell, Inc. (NASDAQ: OMCL) is a leading provider of systems and software solutions targeting patient safety
and operational efficiency in healthcare facilities. Since 1992, Omnicell has worked with numerous healthcare
facilities to enhance patient safety and allow clinicians to spend more time with their patients. Omnicell’s
medication-use product line includes solutions for the central pharmacy, nursing unit, operating room, and
patient bedside. Solutions range from large central pharmacy “smart inventory” carousels to small handheld
devices. From the point at which a medication arrives at the receiving dock to the time it is administered,
Omnicell systems store it, package it, bar code it, order it, issue it, and provide information and controls on its use
and reorder.
Our supply product lines provide a healthcare institution with fast, effective control of costs, capture of charges
for payor reimbursement, and timely reorder of supplies. Products range from high-security closed-cabinet
systems and software to open-shelf and combination solutions in the nursing unit, cath lab, and operating room.
Omnicell’s mission is to provide the best customer experience in healthcare, helping hospitals reduce medication
errors, operate more efficiently, and decrease costs. For more information, visit www.omnicell.com.
This guide and accompanying software and/or hardware described in it are protected under copyright laws and
may not be copied, wholly or in part, without the express written consent of Omnicell, Inc. The same proprietary
and copyright notices must be attached to any permitted copies as were attached to the original documents.
Omnicell, Inc.
590 E. Middlefield Road
Mountain View, CA 94043
(650) 251-6100
www.omnicell.com
Omnicell and the Omnicell design mark, OmniBuyer, OmniCenter, OmniRx, OmniSupplier, Pandora, PandoraVIA,
SafetyMed, SafetyStock, and Sure-Med are registered trademarks. Anesthesia TT, Anesthesia Workstation,
Anywhere RN, Executive Advisor, FlexBin, Medication Surveillance, OmniDispenser, OmniLinkRx, OmniScanner,
OmniTrack, Omni TT, Open Touch, OptiFlex, OptiFlex MobileTrack, Point-to-Point Medication Safety, ProServ1,
SecureVault, See & Touch, SinglePointe, TempCheck, Touch & Go, vSuite, and WorkflowRx are trademarks of
Omnicell, Inc. in the United States and internationally. All other trademarks and trade names are the property of
their respective owners.
Copyright 2010-2015 Omnicell, Inc. All rights reserved.
HL7 Pharmacy Interface Specifications/67-3079 Rev G © 2015 Omnicell, Inc.

iii
Table of Contents
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
Intended Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
HL7 Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

HL7 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
Message Delimiters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
Field Use Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
Sequence Number Protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
Data Field Length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
ADT Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

General Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
Supported Message Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
Acknowledgment Message. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
Message Header Segment (MSH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
Acknowledgment Segment (MSA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4
ADT Message Segments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4
Message Header (MSH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5
Event Type (EVN). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5
Patient Identification (PID). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6
Patient Visit (PV1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7
Patient Allergy (AL1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8
Observation/Result Segment (OBX) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9
Merge Event Segment (MRG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10
Mapping Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10
Facility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10
Patient Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10
Patient Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10
Other Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10
Sample ADT Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11
RXP Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Supported Order Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
© 2015 Omnicell, Inc. HL7 Pharmacy Interface Specifications/67-3079 Rev G

iv Table of Contents
RDE Message Segments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2

Patient Identification (PID). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
Patient Visit (PV1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
Allergy Information (AL1). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
Common Order Segment (ORC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4
Pharmacy/Treatment Encoded Order Segment (RXE) . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5
RXE-1 Quantity/Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7
RXE-2 Give Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7
Pharmacy/Treatment Route Segment (RXR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8
Pharmacy/Treatment Component Order Segment (RXC). . . . . . . . . . . . . . . . . . . . . . . 4-8
Other Possible RDE Entries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9
Sample RDE Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10
RXC Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

Financial Transaction Message Segments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1
Event (EVN). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
Patient Demographics (PID) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
Patient Visit (PV1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
Financial Transaction (FT1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4
Pocket Activity (ZPM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5
Sample DFT Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5
ZPM Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

Pocket Maintenance Activity Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2
Pocket Activity (ZPM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
Sample ZPM Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
RXF Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

MFE Event Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1
RXF Message Segments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2
Master File Identification Segment (MFI). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3
Master File Entry Segment (MFE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3
Formulary Maintenance Segment (ZMI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4
Formulary Maintenance Segment (ZFM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5
Sample MFN Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5

Table of Contents v
Appendix A: Med Label Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1

Nurse-prepared IV Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-2
Appendix B: MCMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-1

Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-1
RXP /RXC Interface Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-1
Documentation Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . FB-1

1-1
Overview
Automatic information exchange with the other hospital systems is required for the Omnicell
system to be fully integrated. It is recommended that the exchange of information with the
Omnicell system be accomplished via an on-line, real time interface which complies with HL7
standards. Connections can either be a point-to-point with the vendor system or through an
interface engine such as eGate, Cloverleaf, etc.
The exchange of pharmacy information between the Omnicell system and other vendor products
falls into the following categories:
 Patient admission, discharge and transfer information passing from the ADT system to the
Omnicell system (ADT)
 Medication Order information passing from the pharmacy system to the Omnicell system
(RXP)
 Formulary item updates from the pharmacy system to the Omnicell system (RXF)
 Medication Usage information passing from the Omnicell system to either the pharmacy
system, or the billing system (RXC)
 Transmission of bin assignment or un-assignment information from the Omnicell system to
the pharmacy system (ZPM)
 Cart fill orders for SinglePointe (Patient Specific Bin) orders from the pharmacy system to
Omnicell (CRT)
 Patient administration activities carried out and documented by caregivers in the BPOC/
eMAR system (RAS)
 Patient scheduling information passing from the SIU system to the Omnicell system (SIU)
Intended Audience
The intended audience for this document is Omnicell field personnel, business partners, and
customers. This document is intended as a mechanism to document and approve customer
specific interface requirements and functionality. It should be shared with the customer and
business partners during specification analysis to obtain approval prior to development and
implementation. It should not be shared with anyone not involved with this specific
implementation project.

2-1
HL7 Messages
HL7 Implementation
The specification described in this chapter follows the HL7 (health level 7) standard to format
messages. The majority of the messages and segments in this specification are standard HL7
messages and segments.
HL7 Z segments are used where no HL7 segment has been defined for the necessary information.
They are also formatted to the HL7 standard. This chapter only covers segments used by
Omnicell. Detailed information about each field element can be found in the HL7 Implementation
Guide. Omnicell supports HL7 versions 2.1 thru 2.5.
The communications protocol is described in Appendix C of the HL7 Implementation Guide.
Omnicell can interface using either the Hybrid Lower Layer Protocol for a serial RS-232
connection (Section C.2) or the Minimal Lower Layer Protocol for a network environment
(Section C.4). Omnicell recommends the use of Minimal Lower Layer Protocol over a TCP-IP
socket connection.
Message Delimiters
Certain special characters are used to construct a message. They are the:
 Segment terminator
 Field separator
 Component separator
 Subcomponent separator
 Repetition separator
 Escape character
The segment terminator is always a carriage return (in ASCII, a hex 0D) for real-time interfaces.
The other delimiters are defined in the message segment header (MSH) segment. The delimiters
occur as specified in the Encoding Characters column of the message delimiter table (Table 2-1).
The delimiter values used in the MSH segment are the delimiter values used throughout the entire
message. In the absence of other considerations, HL7 recommends the suggested values found in
Delimiter Values column of the message delimiter table (Table 8-1).
At any given site, the subset of the possible delimiters may be limited by negotiations between
applications. This implies that the receiving applications will use the agreed upon delimiters, as
they appear in the MSH, to parse the message.

2-2 HL7 Messages
Field Use Type
Encoding
Suggested Character
Delimiter Value Position Usage
Segment Terminator <cr> (hex 0D) - Terminates a segment record.
Field Separator | - Separates two adjacent data fields within a segment. It also separates the segment ID from
the first data field in each segment.
Component Separator ^ 1 Separates adjacent components of data fields where allowed.
Subcomponent & 4 Separates adjacent subcomponents of data fields where allowed. If there are no
Separator subcomponents, this character may be omitted.
Repetition Separator ~ 2 Separates multiple occurrences of a field where allowed.
Escape Character \ 3 Escape character for use with any field represented by an ST, TX or FT data type, or for use
with the data (fourth) component of the ED data type. If no escape characters are used in a
message, this character may be omitted. However, it must be present if subcomponents are
used in the message.
Table 2-1. Message delimiters
Field Use Type

Fields are required, optional or conditional in a segment. In the segment attribute tables of the HL7
Implementation Guide, this information is provided in the column labeled R/O. The designations
are:
R: Required; must contain information to process data
O: Optional; supplies extra information that does not affect data processing
C: Conditional on the trigger event or on some other field(s); The field definitions following the
segment attribute table in the following chapters should specify the algorithm that defines the
conditionally for this field.
X: Not used with this trigger event (or) not used by the Omnicell interface at all
B: Left in for backward compatibility with previous versions of HL7; The field definitions
following the segment attribute table in the following chapters should denote the field use type for
prior versions.
Data fields with no designated use in the Required/Optional column indicate the data field is not
used by Omnicell.
Sequence Number Protocol

The sequence number protocol is turned off for these interfaces.
Data Field Length

Fields without a specified length have a variable length which can even be empty. Such fields are
not normally used by the Omnicell interface.

3-1
ADT Interface
Admission, Discharge, and Transfer (ADT) messages are sent from the ADT system to the
Omnicell system via the ADT interface. This allows each Omnicell cabinet to maintain an up-to-
date demographic and visit information about the patients. When any of the supported trigger
events occur on the ADT system, the corresponding HL7 interface message are translated and
transmitted to the Omnicell system. Once the interface message is sent to the Omnicell system, a
Message Acknowledgment (MSA) message is sent by the Omnicell system to the ADT system
confirming that the transmission was successful. The Omnicell system processes the message to
update Omnicell patient database.
Hospital
System
Application OmniCenter
Interface services
Application
Application
Messages sent over socket. ADT Messages sent over MSMQ

Interface
General Information
 The interface connections are TCP/IP Socket and MLLP.
 Interface services support HL7 v2.1 thru 2.5 formats.
 Omnicell is configured as socket server (listening socket).
 Interface services requires an IP address and a port number for connecting to Omnicell.
 The ADT interface may share a connection with the RXP interface.

3-2 ADT Interface
Supported Message Events
Supported Message Events

Message Code Message Type
A01 Admit
A02 Transfer
A03 Discharge
A04 Register
A05 Pre-admit
A06 Change an outpatient to inpatient
A07 Change an inpatient to outpatient
A08 Patient update
A11 Cancel Admit
A12 Cancel Transfer
A13 Cancel Discharge
A17 Swap Patients
A18 Merge Patient Information
A23 Delete Patient Visit
A31 Update Patient Information
A34 Merge Patient Information – Patient Id only
A38 Cancel Pre-admit
A40 Merge patient – Identifier list
A41 Merge Account – patient account number
A43 Move Patient Information - Identifier list
A47 Change Patient Identifier list
Table 3-1. Message events

ADT Interface 3-3
Acknowledgment Message
As inbound interface, ADT interface is able to generate the generic HL7 acknowledgment
message (acknowledgment code: AA). A negative acknowledgment (code: AE) is sent when the
ADT interface receives mis-formatted HL7 messages. Omnicell signals the ADT system to send
the next transaction because the current record is rejected. Content validation is performed
during the translation of the message. Content errors are not communicated back to the sending
system.
The acknowledgment message consists of a message header and an acknowledgment segment.
Note: The following tables have OmniCenter tokens in bold under Comments.
Message Header Segment (MSH)

Required/
Sequence Length Optional Element Name Comments
0 3 R Segment Name MSH
1 1 R Field Separator Use default of “|” (pipe character)
2 4 R Encoding Characters ^~\&
3 15 Sending Application OMNICELL
4 20 R Sending Facility Derived from input’s receiving facility
5 15 Receiving Application Derived from input’s receiving application
6 30 R Receiving Facility Derived from input’s sending facility
7 16 R Date/Time of Message Format: YYYYMMDDHHMMSS
8 40 Security Not used
9 7 R Message Type ACK
10 20 Message Control Type Unique identifier; same value as MSH.10 sent by ADT system; If the ADT system
requires Omnicell generated numbers, the RecordID is used with a prefix of the
interface name (ADT).
11 1 R Processing ID (P)roduction, (T)raining, (D)ebugging
12 8 R Version ID 2.4 (derived from input’s MSH.12)
13 15 Sequence Number Not used
14 varies Continuation Pointer (none)
15-17 varies (not used) Not used
Table 3-2. Message header (acknowledgment)

3-4 ADT Interface
ADT Message Segments
Acknowledgment Segment (MSA)

Required/
0 3 R Segment Name MSA
1 2 R acknowledgment Code AA, AR or AE
2 20 R Message Control ID Same as MSH.10 above
3 80 Text Message Description of error, if AR or AE
4 15 Expected Sequence Number Not used by Omnicell
5 1 O Delayed acknowledgment Type Used only for delayed acknowledgment handshaking
Table 3-3. acknowledgment segment

The following common HL7 segments are used for ADT messages:
Name Definition
MSH Message Header
EVN Event Type
PID Patient Identification
PV1 Patient Visit
[{AL1}] Allergy Information
[MRG] Merge Patient Information (merge events)
[{OBX}] Observation/Results
The segments listed under each message are the segments that the Omnicell system processes
unless specified otherwise. If additional segments (Z-segments or segments not in the HL7
specification) are sent within the messages, Omnicell ignores them. Fields within a segment are
ignored if the Omnicell system does not process them. Complete messages and segments may be
sent by the sending system. The Omnicell system handles the filtering of segments and fields that
it does not need.
The length of the data fields used by Omnicell is based upon the maximum length defined in the
Omnicell data dictionary. Length of the data fields not used by Omnicell follows the length as
defined in the HL7 standard document.

ADT Interface 3-5
Message Header (MSH)

Required/
3 15 Sending Application Vendor system
4 20 R Sending Facility Hospital facility; translation table is used to alias facility code to Omnicell site ID. See
PID.3.4.
5 15 Receiving Application OMNICELL
6 30 R Receiving Facility Hospital facility
8 40 Security Not used
9 7 R Message Type
9.1 3 Message Code ADT
9.2 3 Trigger Event Refer to Section 3.2 for supported events.
10 20 R Message Control ID Uniquely identifies message.
12 8 R Version ID 2.4
13 15 Sequence Number Not used
14 varies Continuation Pointer [none]
Table 3-4. Message header (ADT message)
Event Type (EVN)

Required/
1 3 B Event Type Code Refer to Section 3.2 for supported trigger events. Same as MSH.9.2; Ex: A01
2 26 R Recorded Date/Time Format: YYYYMMDDHHMMSS
3 26 Date/Time Planned Event Not used
4 3 Event Reason Code Not used
5 250 Operator ID Not used
6 26 Event Occurred Not used
7 241 Event Facility Not used
Table 3-5. Event types

3-6 ADT Interface
Patient Identification (PID)

Required/
1 4 O Set ID - PID
2.1 16 B Patient ID Same as PID.18.1 - account or visit number (pid)
3 varies R Patient Identifier List
3.1 16 R Medical Record Number mrn – Lifetime patient number
3.2 varies O (not used) Not used
3.3 varies O (not used) Not Used
3.4 16 R Facility code ID of hospital, clinic or location. Same as MSH.4. May need a
translation table to alias to Omnicell Site ID (site)
4 20 B Alternate Patient ID - PID
5 32 R Patient Name pna (formatted in Omnicell as Last, First Middle)
5.1 varies R Last Name
5.2 varies R First Name
5.3 varies O Middle Name
6 250 O Mother’s Maiden Name
7 16 O Date/Time of Birth dob
8 1 O Administrative Sex gen - patient gender
9 250 B Patient Alias
10 250 O Race
11 250 O Patient Address
12 4 B County Code
13 250 O Phone Number - Home
14 250 O Phone Number - Business
15 250 O Primary Language
16 250 O Marital Status
17 250 O Religion
18 varies R Patient Account Number
18.1 16 R Financial account or visit number pid
19 11 B SSN Number - Patient
Table 3-6. Patient ID

ADT Interface 3-7
Patient Visit (PV1)

Required/
1 4 O Set ID - PV1
2 1 R Patient Class Secondary criteria for setting patient type (ptyp): I, O, E, R
3 80 O Assigned Patient Location
3.1 8 R Nurse Station area – aliased using Area mapping table. Original value stored in
pm1(16 chars max)
3.2 8 O Room & bed (Room^bed) rm
4 2 O Admission Type
5 250 O Preadmit Number
6 80 O Prior Patient Location
7 32 O Attending Doctor Code^Last^First^Middle if using caret as subfield delimiter
8 32 O Referring Doctor Code^Last^First^Middle if using caret as subfield delimiter
9 32 B Consulting Doctor Code^Last^First^Middle if using caret as subfield delimiter
10 3 O Hospital Service Secondary criteria for setting patient type (ptyp)
11 80 O Temporary Location
12 2 O Preadmit Test Indicator
13 2 O Re-admission Indicator
14 6 O Admit Source
15 2 O Ambulatory Status
16 2 O VIP Indicator
17 32 O Admitting Doctor Code^Last^First^Middle if using caret as subfield delimiter
18 3 R Patient Type Primary criteria for determining patient type (ptyp). Aliased to valid
Omnicell patient type using mapping table. Original value is stored in
pm2 (16 chars max)
19 250 O Visit Number account number
44 16 O Admit Date/Time dam - Format: YYYYMMDDHHMMSS
45 16 O Discharge Date/Time dds - Format: YYYYMMDDHHMMSS
Table 3-7. Patient visit

3-8 ADT Interface
Patient Allergy (AL1)

Required/
1 4 R Set ID AL1
2 250 O Allergen Type Code
3 250 R Allergen Code/Mnemonic/Description Use either ali or alrgy data field, but not both!
3.1 varies R Allergy Code Use ali if using Allergy Alert feature, delimited by a caret (^)
3.2 varies R Allergy Description/Name Use alrgy if not using Allergy Alert feature. Concatenate
allergy description from all AL1 segments, delimited by a
semi-colon.
Table 3-8. Patient allergy
Allergy information can be updated during patient admission with the AL1 message (via ADT
interface). However, allergy information is usually recorded at the time doctors prescribe
medication. Thus, it is common practice to update allergy information from the RDE message
(via RXP interface). The allergy update (AL1) in the ADT interface is disabled by default.
Customers, pharmacy vendor, and the Omnicell installation team must agree on the allergy
update (interface) source.
If the allergy alert feature (AL1) is used, the ADT system is required to send valid allergy codes to
Omnicell. With this feature, allergies are referenced using allergy codes. In addition, this interface
is capable of dynamically updating Omnicenter Allergy database from patient’s allergy
information so users will not have to manually add codes to the database.

ADT Interface 3-9
Observation/Result Segment (OBX)

The OBX segment is a repeating segment used to transmit a single observation or observation
fragment. It represents the smallest indivisible unit of a report. For this interface, this segment is
specifically used to retrieve height and weight of a patient.
Required/
1 4 O Set ID - OBX
2 2 C Value Type
3 250 R Observation Identifier OBX.3.2=weight or height; updates pwt and pht data fields
respectively in Omnicell
4 20 C Observation Sub-ID
5 5 C Observation Value Value is associated with the value of OBX.3.2; pht for height or
pwt for weight
6 5 O Units Units of measures must be CM for height, and KG for weight
7 60 O References Range
8 5 O Abnormal Flags
9 5 O Probability
10 2 O Nature of Abnormal Test
11 1 O Observation Result Status
12 26 O Date Last Observation Normal Value
13 20 O User Defined Access Checks
14 26 O Date/Time of the Observation
15 250 O Producer's ID
16 250 O Responsible Observer
17 250 O Observation Method
18 22 O Equipment Instance Identifier
19 26 O Date/Time of the Analysis
Table 3-9. Observation/result

3-10 ADT Interface
Mapping Tables
Merge Event Segment (MRG)

This segment is used when merging old and new patient account/visit number or the medical
record number (MRN) is updated.
Required/
1.1 16 R Prior Patient Identifier List
2 16 B Prior Alternate Patient ID
3 16 R Prior Patient Account Number
4 16 B Prior Patient ID
5 16 R Prior Visit Number
6 16 O Prior Alternate Visit ID
7 32 R Prior Patient Name
Table 3-10. Merge event
Mapping Tables
Facility
The facility mapping table is used for accommodating multi-facility accounts. It is used for
distributing transactions to the appropriate OmniCenter server. The source of data may change
depending on the vendor system. The data usually originates from the Sending Facility field in the
MSH segment. That value is translated to its corresponding Site ID in Omnicenter.
Patient Area
This table is used for mapping vendor’s patient location to Omnicell areas. The source of data may
change depending on the vendor system.
Patient Type
This table maps the ADT system’s patient types to their corresponding types in Omnicell. The
following patient types are defined in Omnicell:
CF1 INP OP1

CF2 MS1 OPB
CF3 MS2 REC
CF4 MS3 SDS
ERM MS4 TMP
Other Entries
Other entries can be site specific. If they are part of the HL7 message, they can be saved in
Omnicell’s database.
EXAMPLE: Payer ID# (from insurance plan); ICD9 (diagnosis code)

ADT Interface 3-11
Sample ADT Message
Sample ADT Message

Some message lines are long and text wrapped in the sample below.
MSH|^~\&|HISA_8592|HISF_2603|||200706081131||ADTÂ04|HL7O.1.11379|D|2
.1
EVN|A04|200706081131|
PID|1||id_1896||lname_8159^fname_616^^^^||19231111|F|^^^^^||address_3
16||phone_4683|||S|BAP|id_9780|||^|
PV1|1|E|ER^^|||ER^^|code_2843^lname_9433^fname_5593|||||||ED||||ER||O
HI|||||||||||||||||||CVH5.5||REG|||20070608|
AL1|1|DA|ANTIHISTAMINE DRUGS|

4-1
RXP Interface
RXP is an inbound interface receiving medication orders from the hospital’s pharmacy system.
The pharmacy system sends a message to the Omnicell system via this interface whenever a
patient’s medication order is created, modified, or discontinued. By tracking the medication order
information, the Omnicell system can prevent users from removing medications from the cabinet
if the medications have not been authorized for a particular patient.
Support for multi-component medication orders (MCMO) came out in the OmniCenter 15.1
release. Refer to “Appendix B: MCMO” on page B-1 for details.
It is expected the pharmacy system will only send verified medication orders.
Hospital
System
Interface ser vices Application
Application
Messages sent over socket . RXP Messages sent over MSMQ

Interface
Note: The iv token must be set to Yes for the customer to control the iv flag at med order. This is an option and
conditional if the customer cannot correctly manage the med order route table data. The default value is No
for the token. The customer must be consulted before this change is made.
General Information
 Interface services support HL7 v2.1-5 formats.
 The RXP interface may share a connection with the ADT interface.
 If ADT and RXP interacts with the same vendor, it is recommended to turn off the PA or PI
command from RXP unless updating allergy from RXP. The PA option was provided in
case Omnicell received ADT information and med orders from two different vendors. It is
used as a back-up in case the ADT initially fails to send patient information.
 Populating Area and Room tokens should be avoided in RXP. Allow ADT to manage
patient movement.

4-2 RXP Interface
Supported Order Control
Supported Order Control

Code Description
NW New order
CA Cancel order
DC Discontinue order
HD Hold order
RL Release previous hold order
XO Change order request
XX Unsolicited change order
See “Acknowledgment Message” on page 3-3 for details.
RDE Message Segments

The RXP message contains the pharmacy encoded order message.
specification) are sent within the messages, Omnicell ignores them.
Fields within a segment are ignored if the Omnicell system does not process them. Complete
messages and segments may be sent by the sending system. The Omnicell system handles the
filtering of segments and fields that it does not need.
The RXP message uses the following RDE message segments:
Code Segment Definition

MSH Message Header
[PV1] Patient Visit Segment
[{AL1}] Allergy Information
ORC Common Order Segment
RXE Pharmacy Encoded Order Segment
{RXR} Pharmacy Route Segment
[{RXC}] Pharmacy Component Order Segment

RXP Interface 4-3

See “Message Header Segment (MSH)” on page 3-3 for details. The values for the RXP message
header are:
 MSH.9.1 = RDE
 MSH.9.2 = 001
Patient Identification (PID)

See “Patient Identification (PID)” on page 3-6 for details.
Patient Visit (PV1)

See “Patient Visit (PV1)” on page 3-7 for details.
Allergy Information (AL1)

See “Patient Allergy (AL1)” on page 3-8 for details.
Allergy information can be updated during patient admission with the AL1 message (via ADT
interface). However, allergy information is usually recorded at the time doctors prescribe
medication. Thus, it is common practice to update allergy information from the RDE message
(via RXP interface). The allergy update (AL1) in the ADT interface is disabled by default.
Customers, pharmacy vendor, and the Omnicell installation team must agree on the allergy
update (interface) source.

4-4 RXP Interface
Common Order Segment (ORC)

Required/
1 2 R Order Control Refer to “Supported Order Control” on page 4-2.
2.1 16 R Placer Order Number moid – med order id
3 22 C Filler Order Number
4 22 O Placer Group Number
5 2 O Order Status
6 1 O Response Flag
7 200 B Quantity/Timing
7.2 32 R Interval Frequency If field value = PRN, the prn token value is yes; otherwise = no
8 200 O Parent
9 26 O Date/Time of Transaction
10 250 O Entered By
11 250 O Verified By
12 250 R Ordering Provider Physician code (phyid) = ORC.12.1; 8 characters
Physician name (phynm) = ORC.12.2, 3, 4 [formatted in Omnicell
as Last, First, Middle]; 32 characters after concatenation
13 80 O Enterer's Location
14 250 O Call Back Phone Number
15 26 O Order Effective Date/Time
16 250 O Order Control Code Reason
17 250 O Entering Organization
18 250 O Entering Device
19 250 O Action By
20 250 O Advanced Beneficiary Notice Code
21 250 O Ordering Facility Name
22 250 O Ordering Facility Address
23 250 O Ordering Facility Phone Number
24 250 O Ordering Provider Address
25 250 O Order Status Modifier
26 60 C Advanced Beneficiary Notice Override
Reason
27 26 O Filler's Expected Availability Date/Time
28 250 O Confidentiality Code
29 250 O Order Type
30 250 O Enterer Authorization Mode
Table 4-1. Common order segment

RXP Interface 4-5
Pharmacy/Treatment Encoded Order Segment (RXE)

Required/
1 200 B Quantity/Timing See “RXE-1 Quantity/Timing” on page 4-7 for more details.
2 250 R Give Code See “RXE-2 Give Code” on page 4-7 for more details.
3 20 R Give Amount - Minimum Minimum dose
4 20 O Give Amount - Maximum Maximum dose (dmax)
5 250 R Give Units
5.1 5 R Units modsu
6.1 5 O Give Dosage Form dsf
7 250 O Provider's Administration Instructions
7.1 O ID
7.2 128 O Text admin:concatenated with RXE.21
8 200 B Deliver-to Location
9 1 O Substitution Status
10 20 C Dispense Amount
11 250 C Dispense Units
12 3 O Number of Refills
13 250 C Ordering Provider's DEA Number
14 250 R Pharmacist/Treatment Supplier’s Verifier ID
14.1 8 R ID phmid
15 20 C Prescription Number
16 20 C Number of Refills Remaining
17 20 C Number of Refills/Doses Dispensed
18 26 C D/T of Most Recent Refill or Dose Dispensed
19 10 C Total Daily Dose
20 1 O Needs Human Review
21 128 O Pharmacy/Treatment Supplier's Special admin: concatenated with RXE.7.2
Dispensing Instructions
22 20 C Give Per (Time Unit)
23 6 O Give Rate Amount
24 250 O Give Rate Units
25 20 O Give Strength
26 250 O Give Strength Units
27 250 O Give Indication
28 20 O Dispense Package Size
29 250 O Dispense Package Size Unit
30 2 O Dispense Package Method mixty - (P) Rx prepared; (N) Nurse prepared
31 250 O Supplementary Code
32 26 O Original Order Date/Time
Table 4-2. Pharmacy/treatment encoded order segment (1 of 2)

4-6 RXP Interface
Required/
33 5 O Give Drug Strength Volume
34 250 O Give Drug Strength Volume Units
35 60 O Controlled Substance Schedule
36 1 O Formulary Status
37 60 O Pharmaceutical Substance Alternative
38 250 O Pharmacy of Most Recent Fill
39 250 O Initial Dispense Amount
40 250 O Dispensing Pharmacy
41 250 O Dispensing Pharmacy Address
42 80 O Deliver-to Patient Location
43 250 O Deliver-to Address
44 1 O Pharmacy Order Type
Table 4-2. Pharmacy/treatment encoded order segment (2 of 2)

RXP Interface 4-7
RXE-1 Quantity/Timing
Fields of interest:
 Frequency/Sig (frq) – RXE.1.2.1
 Admin Times (admtm) – RXE.1.2.2
 PRN indicator (prn) – RXE.1.2.1 (if PRN exists), or RXE.1.6, if used
 Start date/time (srdt) – RXE.1.4
 Stop date/time (spdt) – RXE.1.5
(TQ) 00221
Components: <Quantity (CQ)> ^ <Interval (RI)> ^ <Duration (ST)> ^ <Start Date/Time (TS)> ^ <End Date/
Time (TS)> ^ <Priority (ST)> ^ <Condition (ST)> ^ <Text (TX)> ^ <Conjunction (ID)> ^ <Order
Sequencing (OSD)> ^ <Occurrence Duration (CE)> ^ <Total Occurrences (NM)>
Subcomponents for Quantity (CQ): <Quantity (NM)> & <Units (CE)>
Subcomponent contains sub-subcomponents:
Subcomponents for Interval (RI): <Repeat Pattern (IS)> & <Explicit Time Interval (ST)>
Subcomponents for Start Date/Time (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>
Subcomponents for End Date/Time (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>
Subcomponents for Order Sequencing (OSD): <Sequence/Results Flag (ID)> & <Placer Order Number: Entity
Identifier (ST)> & <Placer Order Number: Namespace ID (IS)> & <Filler Order Number: Entity
Identifier (ST)> & <Filler Order Number: Namespace ID (IS)> & <Sequence Condition Value (ST)>
& <Maximum Number of Repeats (NM)> & <Placer Order Number: Universal ID (ST)> & <Placer
Order Number: Universal ID Type (ID)> & <Filler Order Number: Universal ID (ST)> & <Filler
Order Number: Universal ID Type (ID)>
Subcomponents for Occurrence Duration (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System
(ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System
(ID)>
RXE-2 Give Code

Fields of interest:
 Drug ID: max length = 16, (item) – RXE.2.1
 Drug description: max length = 48, (ina) – RXE.2.2
(CE) 00317
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^
<Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

4-8 RXP Interface
Pharmacy/Treatment Route Segment (RXR)

Required/
1 250 R Route
1.1 10 R Identifier mrte
1.2 10 R Text mrte
2 250 O Administration Site
3 250 O Administration Device
4 250 O Administration Method
5 250 O Routing Instruction
6 250 O Administration Site Modifier
Table 4-3. Pharmacy/treatment route segment
Pharmacy/Treatment Component Order Segment (RXC)

Required/
1 1 R RX Component Type A = Additive, B = Base
2 250 R Component Code moc - see footnote for single additive order1
2.1 16 R Drug ID A = item, B = bitem
2.2 48 R Drug description A = ina, B = bina
3 14 R Component Amount A = dose, B = bdssa
4 5 R Component Units A = modsu, B = bdssu
5 20 O Component Strength
6 250 O Component Strength Units
7 250 O Supplementary Code
8 5 O Component Drug Strength Volume
9 250 O Component Drug Strength Volume Units
Table 4-4. Pharmacy/treatment component order segment
1
Single Additive Order:
* Will be pulled as either the item ID or the base item ID depending on value in RXC.1
* Will be pulled as either dose or base dose depending on value in RXC.1
* Will be pulled as either dose units or base dose units depending on value in RXC.1
For MCMO: Component drugs are parsed into moc token as XML stream.

RXP Interface 4-9
Other Possible RDE Entries

Omni Token Name Description
admd Admin Duration Duration of a single administration
adms Admin Site Site of Administration
bdsa Dosage Vol. Amt. Dosage Volume Amount (base)
bdsf Dosage Form Dosage Form (base)
bdsu Dosage Vol. Unit Dosage Volume Units (base)
bdsva Total Vol. Amt. Total Volume Amount (base)
bdsvu Total Vol. Units Total Volume Units (base)
dsa Dosage Vol. Amt. Dosage Volume Amount
dssa Strength Amount Strength Amount
dsu Dosage Vol. Unit Dosage Volume Units
dur Duration Schedule Duration
erwnd Early Window Early Window
gamt Give Amount Give Amount
gun Give Units Give Units
int Interval Schedule interval
ltwnd Late Window Late Window
mal MO Alert Medication Order Alert at the Cabinet (Y/N)
moc MO Components Med order components XML
moqty Quantity Quantity
od Only Days Schedule only these days of the week
qty Trans Quantity Quantity issued (+ qty = taken from Omni, - qty = put into Omni)
msit Site Site
slamt Sol Rate Amount Solution rate amount
sltm Sol Rate Tm Unts Solution rate time units
slunt Sol Rate Units Solution rate units
stat Stat Stat schedule (first dose at order start date/time)
dssu Strength Units Strength Units
dsva Total Vol. Amt. Total Volume Amount
dsvu Total Vol. Units Total Volume Units
uid User ID User ID within the system (must be unique)
una User Name User name (Last, First)
Table 4-5. Other RDE entries

4-10 RXP Interface
Sample RDE Message
Sample RDE Message

MSH|^~\&||HISF_2862|||200801141126||RDEÔ01|OMNI-OUT.2.2951269|P|2.2
PID|1||id_354||lname_7714^fname_4016^^^^||19180729|F|^^^^^|C|address_2552|||||W|C
|id_8638|ssn_3650
PV1|||||||code_992^lname_8906^fname_9365^mnane_3998^^^MD|||||||||||||||||||||||||
||||||||||||200712211356
AL1|1|DA|Clarithromycin
AL1|2|DA|CODEINE SULFATE
AL1|3|DA|Levofloxacin
AL1|4|DA|TETANUS TOXOID
ORC|NW|03174124|||||^Q24H&SCH^^200801141130^200801201800ÎV^
RXE|^Q24H&SCH^^200801141130^200801201800^^0^|CEFTRX1P^Ceftriaxone|0||GM|SDV||||0|
GM||BM3681500|SKM|7||||||UTI
RXC|B|DEX5W1PB^Dextrose 5%/Water 100ml Bag (Mini-Bag)|100|ML
RXC|A|CEFTRX1P^Ceftriaxone 1gm SDV|1|GM
RXR|Intravenous|||PIV

5-1
RXC Interface
When a drug or item is removed from the Omnicell cabinet, a charge or medication dispense
transaction is automatically generated for the patient for whom the item was selected. If an item is
returned to the cabinet, a credit transaction is automatically generated for the patient from whom
the item was returned. This charge/billing information is sent from the Omnicell system to the
hospital’s pharmacy or financial system in real time mode via the RXC interface. A DFT message
will be generated by the Omnicell system and sent immediately to the hospital’s pharmacy or
financial system whenever a chargeable transaction occurs on the Omnicell system. A site may
choose to use the Medication Dispense (DFT) or Charge for Medication Dispense (RDS) message.
Hospital
System
Application
Messages sent over socket . RXC Messages sent over MSMQ

Interface
General Information
 Omnicell is configured as socket client.
 The RXC interface may share a connection with the ZPM interface.
Financial Transaction Message Segments

The following DFT message segments are used:

MSH Message Header
EVN Event Type
[PV1] Patient Visit
{FT1} Financial Transaction
[ZPM] Pocket Activity

5-2 RXC Interface
it does not need.

Required/
3 15 Sending Application Used to support multi-facility accounts1
4 20 R Sending Facility Used to support multi-facility accounts2
5 15 Receiving Application Used to support multi-facility accounts3
6 30 R Receiving Facility Used to support multi-facility accounts4
8 40 Security Not used by Omnicell
9 varies Message Type
9.1 3 R Message Control ID DFT
9.2 3 R Trigger Event P03
10 20 R Message Control Type Uniquely identifies message
13 15 Sequence Number Not used by Omnicell
14 varies Continuation Pointer None
Table 5-1. Message header
1 Source of data may change depending on the vendor system. A Facility mapping table may be needed to accommodate multi-facility accounts. Otherwise, get value from Sending Application
in NODE.INI.
2 Source of data may change depending on the vendor system. A Facility mapping table may be needed to accommodate multi-facility accounts. Otherwise, get value from Sending Facility in
NODE.INI.
3 Source of data may change depending on the vendor system. A Facility mapping table may be needed to accommodate multi-facility accounts. Otherwise, get value from Receiving
Application in NODE.INI.
4 Source of data may change depending on the vendor system. A Facility mapping table may be needed to accommodate multi-facility accounts. Otherwise, get value from Receiving Facility in
NODE.INI.

RXC Interface 5-3
Event (EVN)
Required/
0 3 R Segment Name EVN
1 3 R Event Code P03
2 16 R Transaction Date and Time Format: YYYYMMDDHHMMS
Table 5-2. Events
Patient Demographics (PID)

Required/
0 3 R Segment Name PID
1 4 O Set ID
3.1 20 R Patient ID - Internal ID mrn – medical record number
4 20 R Patient Account Number pid – Patient ID
5 48 O Patient Name pna - Format Last^First^Middle assuming caret is the sub-field delimiter.
18.1 16 R Patient Account Number pid – Patient ID
Table 5-3. Patient demographics
Patient Visit (PV1)

Required/
0 3 R Segment Name PV1
3 80 O Patient Location See format note below*
7 60 O Attending Doctor Retrieve from phy token.
18 5 O Patient Type Not used
Table 5-4. Patient visit
* Format for patient location element = pm1^rm^bed (assuming caret is the sub-field delimiter); pm1
contains the original value captured from ADT interface. Room and bed are stored in rm token delimited by a
dash (-).

5-4 RXC Interface
Financial Transaction (FT1)

Required/
0 3 R Segment Name FT1
2 16 R Transaction ID moid - Pharmacy order number, or value of “OVERRIDE” if no moid exists.
4 14 R Transaction Date xdt - Format YYYYMMDDHHMMSS
5 14 O Posting Date xdt - Format YYYYMMDDHHMMSS
6 8 R Transaction Type Derived from xty – mapped through RXC Transaction Type table
7.1 16 R Transaction Code item – Item ID
7.2 48 R Transaction Description ina – Item Description
9 16 R Alternate Transaction moid - Pharmacy order number, or value of OVERRIDE if dispenses for
Description medication override.
10 8 R Transaction Quantity The absolute render of the qty – Quantity taken, return or wasted.
13 16 O Department Code cntr – cost center, null if empty
16 12 O Patient Location See format note below*
18 16 O Patient Type ptyp – mapped patient type from ADT interface; null if empty
20 60 O Performed By Code OMNICELL^ToHL7PersonName(una, “^”)
23 16 O Filler Order Number moid – same as field 2, if present. Or “OVERRIDE”
Table 5-5. Financial transaction
* Format for patient location element = pm1^rm^bed (assuming caret is the sub-field delimiter); pm1
contains the original value captured from ADT interface. Room and bed are stored in rm token delimited by a
dash (-).

RXC Interface 5-5
Sample DFT Message
Pocket Activity (ZPM)

Required/
0 3 R Segment Name ZPM
1 16 R Transaction Type L for bin load, U for unload. C for others.
2 10 R Dispensing System Defined in node.ini. Default is OMNIRX
3 10 R Dispensing Location osi – OmniSupplier ID. Use Floor Stock Mapping table.
5 5 O Pocket Descriptor omb – Internal Bin ID
6 16 R Medication/Drug ID item — Item ID
7 48 O Medication Name ina – Item Name
8 1 O Medication Class aclv – DEA Schedule Class (0-6)
10 8 O Actual Begin Count qt – Quantity On Hand (total qty for multi-bin items)
11 8 O Transaction Amount qty – quantity issued or returned.
12 12 O User ID xus
13 32 O User Name una
14 12 O Witness ID wtid
15 32 O Witness Name wtnm
16 8 R Total Count of Med on Unit qt – Quantity On Hand (total qty for multi-bin items)
20 16 O Nursing Unit pm1 – patient location as originally received from ADT interface.
22 8 O Par Level qpl
24 14 R Transaction Date xdt - Format YYYYMMDDHHMMSS
Table 5-6. Pocket activity
Sample DFT Message

MSH|^~\&|OMNIMEDS-IN|UTMH|HNAM|HNAM|20090807102204|SECURE|DFT^P03|RXC-
0008333849|P|2.3
EVN|P03|20090807102204
PID|1||441306|pid_9643|LastName^FirstName9317|||||||||||||pid_9643
PV1|||2ND^218-A||||phy_8678|||||||||||OP1
FT1||moid_9303||2007052909174600|2007052909174600|I|43428234^PROPOFOL||moid_9303|
1|||""|||2ND^218-A||OP1||LastName^FirstName6086|||moid_9303
ZPM|C|OMNIRX|GLANES2||49290|43428234|PROPOFOL|6||10|1|DFRANK|LastName,
FirstName6086|""|""|10||||2ND||12||2007052909174600

6-1
ZPM Interface
The ZPM interface handles bin load and unload activities.
Bin loading occurs when a new drug is needed for regular administration to a patient in a certain
area. The pharmacy adds the drug to the local formulary for the cabinet servicing that patient.
The initial supply of the drug is brought to the cabinet. A bin is selected, assigned, and stocked
with the new drug. An update message is then sent to the pharmacy system. The message
automatically updates the floor stock tables. This allows the system to always be aware of what is
available in each cabinet.
Bin unloading occurs when there is no longer a need for a drug in a specified area. The remaining
supply is sent back to the pharmacy. The bin is unassigned to make room for the next drug that is
needed locally.
The list of drugs available in each area of the hospital may be in a constant state of flux. The bin
load/unload messages allows the pharmacy system to determine when a drug needs to be sent
from the pharmacy to fill an order or allow the drug to be dispensed from the cabinet.
Hospital
System
Application
Messages sent over socket . ZPM Messages sent over MSMQ

Interface
General Information
 Omnicell is configured as socket client.
 The ZPM interface may share a connection with the RXC interface.

6-2 ZPM Interface
Pocket Maintenance Activity Message
Pocket Maintenance Activity Message

The following ZPM message segments are used:

MSH Message Header
ZPM Pocket Activities
it does not need.

Required/
3 15 Sending Application Used to support multi-facility accounts1
4 20 R Sending Facility Used to support multi-facility accounts2
5 15 Receiving Application Used to support multi-facility accounts
6 30 R Receiving Facility Used to support multi-facility accounts4
8 40 Security Not used by Omnicell
9.1 7 R Message Type ZPM
Table 6-1. Message header
1 Source of data may change depending on the vendor system. A Facility mapping table may be needed for multi-facility accounts. Otherwise, get value from Sending Application in NODE.INI.
2 Source of data may change depending on the vendor system. A Facility mapping table may be neededfor multi-facility accounts. Otherwise, get value from Sending Facility in NODE.INI.
3 Source of data may change depending on the vendor system. A Facility mapping table may be needed for multi-facility accounts. Otherwise, get value from Receiving Application in NODE.INI.
4 Source of data may change depending on the vendor system. A Facility mapping table may be needed tfor multi-facility accounts. Otherwise, get value from Receiving Facility in NODE.INI.

ZPM Interface 6-3
Sample ZPM Message
Pocket Activity (ZPM)

Required/
0 3 R Segment Name ZPM
1 16 R Transaction Type Possible values: L, U, C1
2 10 R Dispensing System Defined in node.ini. Default is OMNIRX
3 10 R Dispensing Location osi – OmniSupplier ID. Use Floor Stock ZPM OmniID Mapping table.2
5 5 O Pocket Descriptor omb – Internal Bin ID
6 16 R Medication/Drug ID item – Item ID
7 48 O Medication Name ina – Item Name
8 1 O Medication Class aclv – DEA Schedule Class (0-6)
9 8 O Expected Begin Count Not currently sent by Omnicell
10 8 O Actual Begin Count qt – Quantity On Hand (total qty for multi-bin items)
11 8 O Transaction Amount qty – quantity loaded, unloaded, counted.; L and U value is always 0
12 12 O User ID xus
13 32 O User Name una
14 12 O Witness ID wtid
15 32 O Witness Name wtnm
16 8 R Total Count of Med on Unit qt – Quantity On Hand (total qty for multi-bin items)
20 16 O Nursing Unit pm1 – patient location as originally received from ADT interface.
22 8 O Par Level qpl
24 14 R Transaction Date xdt - Format: YYYYMMDDHHMMSS
Table 6-2. Pocket activity
1 Derived from xty and xmi token. L (xty = M and xmi = Assign), U = (xty = M and xmi = Delete), C (xty = S, O, D or K)
2 The TO field in the mapping table may contain multiple Floor Stock locations. Use ^ to separate each floor stock location. When an OmniSupplier ID is mapped to multiple locations, generate
the same exact message and set ZPM.3 accordingly for each location.
Sample ZPM Message

MSH|^~\&|OMNICELL|OC|HIS|XX|20090508090955||ZPM||P|2.4
ZPM|L|OMNIRX|FMREHABEXT||38789|P1971|BACLOFEN|6|||1|000408639|una_4490|""|""|||||
REH||20||2005061823590500

7-1
RXF Interface
The formulary update interface (RXF) keeps pharmacy items in the Omnicell database in sync
with the formulary in the pharmacy system. RXF is used to populate a master item list which can
be copied when adding a new drug to a cabinet.
It is assumed that the pharmacy system is the owner of the pharmacy formulary file. Therefore,
any modifications, additions, or deletions, which are made to the formulary file, must be entered
into the pharmacy system. Whenever users at workstations on the pharmacy system modify, add,
or delete items, an interface message could be formatted and transmitted to the Omnicell system.
The Omnicell system processes the message to update Omnicell files. This application is typically
a real-time interface. Third-party vendors normally send formulary update messages with
medication orders on the same CP/IP socket feed. Transmission of data occurs as frequently as
necessary to keep the Omnicell items database in sync with the pharmacy system’s formulary.
Hospital
System
Inter face ser vices Application
Application
Messages sent over socket. RXF

Interface
General Information
 The RXF interface may share a connection with the ADT and RXP interfaces.
MFE Event Codes

Record level event codes supported by MFE.1.
Code Description
MAD Add record
MUP Update record
MDL Delete record – NOT SUPPORTED

7-2 RXF Interface
Refer to“Acknowledgment Message” on page 3-3 for details.
RXF Message Segments

This is the Master File Notification Message. It uses the following MFN message segments:

MSH Message Header
MFI Master File Identification
{
MFE Master File Entry
[ZFM] Formulary Maintenance
[ZMI] Formulary Maintenance
}
it does not need.

Refer to “Message Header Segment (MSH)” on page 3-3 for details.
 MSH.9.1 = MFN
 MSH.9.2 = CDM or INV

RXF Interface 7-3
Master File Identification Segment (MFI)

Required/
1 250 R Master File Identifier
2 180 O Master File Application Identifier
3 3 R File-Level Event Code
4 26 O Entered Date/Time
5 26 O Effective Date/Time
6 2 R Response Level Code
Table 7-1. Master file identification segment
Master File Entry Segment (MFE)

Required/
1 3 R Record-Level Event Code See “MFE Event Codes” on page 7-1 for possible values and descriptions.
2 20 C MFN Control ID
3 26 O Effective Date/Time
4 16 R Primary Key Value - MFE item - same as ZFM.2 or ZMI.1.1
5 3 R Primary Key Value Type
Table 7-2. Master file entry segment

7-4 RXF Interface
Formulary Maintenance Segment (ZMI)

Some vendors only support the ZMI segment. This segment does not co-exist with ZFM segment.
Required/
1 varies R Master Item File Table Entry
1.1 16 Drug ID item – same as MFE.4
1.2 48 Drug Description ina
2 10 R Location osi – mapped by RXF.FacilityMasterOmni
3 16 R Charge ID cid
4 48 R Brand Name of Drug Item alias
5 6 PAR Level Not updated unless requested (qpl)
6 6 Reorder Point Not updated unless requested (qmn)
7 6 Critically Low Level Not updated unless requested (qal)
8 6 Quantity on Hand Not updated unless requested (qoh)
9 4 Unit of order, Unit of Re-stock Uoo, Usk
10 4 Unit of Issue uoi
11 16 Normal Re-order Source mns
12 20 Normal Re-order Bin Location or Part # mnl
13 16 Critically Low Re-order Source als
14 20 Critically Low Re-order Bin Location or Part # all
15 1 Billable/Non-billable cty
16 16 Item Cost (per unit of issue) ucs
17 16 Item Price (per unit of issue) upr
18.1 14 R Unit Dose Strength of Drug dssa
18.2 14 R Unit Dose Strength unit of Drug dssu
19.1 14 R Unit Dose Volume dsa
19.2 14 R Unit Dose Volume unit dsu
20.1 14 R Total Volume dsva
20.2 14 R Total Volume unit dsvu
21 7 R Unit Dose Drug Form dsf
22 1 R DEA Schedule aclv
23.1 16 Manufacturer ID mfno
23.2 16 Manufacturer /Name mfna
Table 7-3. Formulary maintenance segment (ZMI)

RXF Interface 7-5
Sample MFN Messages
Formulary Maintenance Segment (ZFM)

Some vendors only support the ZFM segment. This segment does not co-exist with ZFM segment.
Required/
1 1 R Formulary Code A - add; C - Change, D- Delete
2 16 R Medication/Drug ID Medication identifier in external system; mapped in
application and is configurable
3 48 R Medication/Drug Name string format; contains generic name (ina)
4 1 R Medication Class DEA schedule based on the state where facility is located
(aciv)
5 16 O Alternate Med ID
6 16 R Facility Code Same as MSH-4
7 48 O Brand Name Item alias
8 7 O Dosage Form dsf
9 14 R Strength dssa
10 5 R Strength Units dssu
11 14 R Volume liquids only
12 5 R Volume Units liquids only
13 varies O Alternate Med 2 ID
14 varies O Therapeutic Class
15 16 O Cost ucs
16 16 O Charge cid
17 20 O Manufacturer Interface may send full description, abbreviated name, or
manufacturer code (mnfo)
Table 7-4. Formulary maintenance segment (ZFM)
Sample MFN Messages

INJ|301|0.490000|1.380000|CD:34762373||||||||||||||63323016501|00517490125
[Message with ZMI Segment]
MSH|^~\&||HISF_8449|||200709130826||MFN|OMNI-OUT.2.2192199|P|2.2
MFI|MIF^Master Item File||UPD|||NE
MFE|MAD|||12345ÂCETAMINOPHEN^99PSD^12345^DIGOXIN^99PSN|CE
ZMI|AXID150^NizatidineÂXID150|*|AXID150|aliasname|||||||||||Y|||150^MG|^|150^MG|
CAP

A-1
Appendix A: Med Label Data

Depending on the current state of the customer’s data and how they want to utilize medication
label printing, there may be some data preparation required. This appendix describes areas that
customers may need to consider before using the medication label printer.
Nurse-prepared IV Identification
Medication labels printed for nurse-prepared IV mixtures print component dose details.
Medication labels printed for non-IV nurse-prepared medication orders print total intended dose
for the order. The nurse-prepared med order must be properly identified for the system to make
the distinction and print the label appropriately. If the medication order is identified as IV and the
medication order is nurse-prepared, then component dose details are printed on the label. There
are two ways in which customers can identify a nurse-prepared order as IV or non-IV:
 Modifying the IV token name at the interface level. This option requires assistance from an
interface analyst. [Interface affected: RXP]
Note: The C++ version of the RXP interface must be upgraded to Omnicell Interface Services (OIS).
 Checking the Med Order Route IV check box at OmniCenter: Database tab > Medication Order
table > Routing/Scheduling
Either option is valid. Interface analysts must discuss the available options with the customer so
that the customer can determine the best course of action. If an interfaces change is desired, the
following table defines the settings.
Med Order Mix Type—mixty token N value = nurse-mix

Med Order IV Flag —iv token
Blank (default) The system defers to OmniCenter’s setting (Med Order Route IV check box).
 If Med Order Route IV is checked, then this med order is IV.
 If Med Order Route IV is unchecked, then this med order is non-IV.
Yes This medication order is IV.
No This medication order is non-IV.

A-2 Appendix A: Med Label Data
Nurse-prepared IV Identification
Example
Label for Nurse-prepared IV mixture
Nurse prepared – Components: 3

Washington, George
Pt ID: 1234567890123456 DOB: 02/22/1932
Component Dose: 400 mg
Medroxyprogesterone Acetate
(Depo-Provera) 400mg / 1 ml
(2.5 ml vial)
Med Order ID: 123456
Printed by: Jefferson, Thomas Prep by:
Issued: 09/20/2011 13:35 Beyond Use: 09/20/2011 15:35

B-1
Appendix B: MCMO
Support for multi-component medication order (MCMO) was introduced with the release of
OmniCenter 15.1. Only the OIS version of RXP interface is supported. Customers who want to
use this new feature may request an RXP upgrade at no charge.
For all med orders, multiple component or not, MCMO is now created by the OIS services
because it is now a part of the OmniCenter med order requirement.
Features
 Pharmacy prepared orders for patient specific bins
 Med orders pre-mixed at the Pharmacy
 Only SinglePointe cabinets supported
 Basic Complex Meds
 Med orders mixed at the nursing stations
 Drug components available in the cabinets as single item bins
 Each component drug sent as separate DFT or RDS messages via RXC interface
 Best guess logic used by OmniCenter to determine Med Order ID for returns and wastes
transactions
Note: Med Order IDs will be accurately reported when the PMA Plus feature is released in a future
version of OmniCenter.
RXP /RXC Interface Changes

The new med order dose token (modisp) is displayed on the Color T.ouch cabinet screen. This
token can be used to override the med order description that is displayed on the cabinet. The
pharmacy system may not have the MCMO description in the HL7 message. In such cases,
Omnicenter can be configured to display the first additive in the med order or concatenate
descriptions of component drugs included in the med order.
The med order type token (moity) in XI command may be used for filtering med dispense records
in the RXC interface. Possible values are listed below:
P - Primary drug component (actually the first additive in the med order)
A - The other additives in the multi-component order
M - Pharmacy mix MCMO
S - Single Item med order
B - Base component
N - Not against med order, i.e., NO med order id - override dispenses.

B-2 Appendix B: MCMO
RXP /RXC Interface Changes
The new, mix type token (mixty) is an optional field. Possible values are:
P - Pharmacy mix
N - Nurse prepared
MCMO - if type is not sent by RXP
Important: For new installs or upgrades, inquire if the pharmacy system can be identified as pharmacy
prepared or nurse prepared med order in the HL7 RDE message. This is very important if SinglePointe
feature is intended to be used by the hospital.
Component drugs are parsed into the moc token as XML strings.
The Single Additive feature (one additive/one base med order) is still supported using the bitem
token.
Note: Single Additive orders are nurse mix by default. However, setting the mixty token to P forces the
med order to be a pharmacy pre-mix order.

C-1
Appendix C: PK Command
This command allows a hospital to change its patient identification when migrating to a new
system. It is used with the ADT interface.
Patient ID Update Process

Modification to patient ID is initiated at the OmniCenter. Affected cabinets are sent the PK
command with the current patient ID to be modified and the new patient ID value. The old ID is
then updated to the new ID. This saves time from manually re-entering the new patient IDs and
eliminates user error.
All patient associated information stays intact: medication orders, patient specific bins, restock,
etc.
Historical data in transactions and waste tables are also updated. These tables include:
 CASE
 DAPATINFO
This table holds historical data relating to one-time dispensing alerts. If a one-time alert for a
patient has been triggered then a record for this event will be found in the table and
subsequent operations on the patient will not trigger the alert again.
 TEMBINS
 MEDITEM
 MORDER
 PATBINS
 PATIENT
The PAT_ID and TMPATID field will be updated.
 PCR
 PMACCT
 RESTOCK
 RMTREQ
 USERPATS
 WASTE
 XACTIONS
Patient Allergies are associated with the patient's Medical Record Number (MRN) and so are not
affected by the change of ID.
Data table updates will be restricted to when no user is logged in.
The feature does not need a GUI as all operations proceed without user interaction once the
command has been received at the cabinet.

C-2 Appendix C: PK Command
Configuration
Configuration
No configuration changes are required for this feature.
Database
No database table or field changes are required for this feature
Implementation
The existing command processing infrastructure will be used to handle this new command so no
additional error handling or error reporting function needs to be added.
The coding effort is essentially an extension to existing code.
Command Details
Token Description Rule Notes
pid Existing patient ID U16 Any value longer than 16 will be rejected
pidn New patient ID U16 Any value longer than 16 will be rejected; cannot be blank; cannot start with '*'; cannot be existing patient id
Code Changes
ff_process:get_obj Add command to patient group.
ff_patient:process input Add call to processing function.
ff_patient:pk() Author command processing function with business rules.
CPatient:Change Pat ID() Author DB access sub-function
Exceptions
The following tables are not updated by the PK command as specified by software version.
For 12.0 servers:

 Modified patient IDs will not be sent via command subscriptions.
 There will be no changes to PATAL (patient allergies) because it uses the MRN.
 The Waste table in Color Touch will not be updated.
 The XACTIONS table in Color Touch will not be updated.
 The DAPATINFO table in Color Touch will not be updated.
 No transaction will be generated when replacing Pat_id in the Pat_bin table.

Appendix C: PK Command C-3
Exceptions
For 16.5 servers:

 There will be no changes to PATAL (patient allergies) because it uses the MRN.
 UEVENTS and Audit tables will not be updated so that the history of patient ID changes can
be reserved.
 The Waste table in legacy Color Touch cabinets will not be updated.
 The XACTIONS table in legacy Color Touch cabinets will not be updated.
 The DAPATINFO table in Color Touch will not be updated.

D-1
Appendix D: Medicare Billing

Summary
The Centers for Medicare & Medicaid Services issued change request CR 6711. It updates the
policy in the Medicare Claims Processing Manual which describes the use of the JW modifier
(revenue code) for discarded drugs.
The hospital's Medicare contractor may require its providers to use the JW modifier. This
modifier would be used to identify unused drugs or biologicals from single use vials or single-use
packages that are appropriately discarded.
The JW modifier would apply when billing Medicare for all drugs except those provided under
the Competitive Acquisition Program for Part B drugs and biologicals. It is billed on a separate
line and provides payment for the discarded drug or biological.
Example: If 95 units of a single-use vial containing 100 units of a drug are used, the billing would
have the 95 units used on one line and the remaining 5 units on another line using the JW
modifier. The JW modifier is only applied to units not used.
Note: Multi-use vials are not subject to payment for discarded amounts of drug or biological.
The official instruction (CR6711) may be viewed on the CMS website at:
http://www.cms.gov/Transmittals/downloads/R1962CP.pdf
Medicare may require that all waste be billed separately. If so, the billing/dispense interface (RXC
and CHG) may need to be updated to process waste transactions.
OmniCenter Configuration
This sections provides a guideline for configuring Omnicenter. It also covers modification of the
billing/dispense interface so waste transactions are sent to the billing or PIS system.
Background
Interface modification on the Omnicell side is dependent upon the interface requirements from
the pharmacy vendor system. This is because the pharmacy system is the receiving application.
The medicine dispense interfaces (RXC) at all customer sites (with few exceptions) communicate
inventory quantity (EA, TAB, VIAL) to the pharmacy system. In the HL7 message, the unit of
measure is not even part of the message. With partial waste credit, the quantity will have a
fractional value. The pharmacy systems may not be able to accommodate the fractional value until
they are upgraded to support the new Medicare regulation. The third-party vendors may also
decide to require the ADC systems to communicate partial waste credit quantity in dose unit of
measure.
The customer must be requested to initiate a discovery meeting with PIS vendors to define
interface requirements as required by the PIS system.

D-2 Appendix D: Medicare Billing
Billable Upgrade
All Versions
[OmniCenter] Turn on Credit patient for waste.
[Administration tab] Select Patient Related Setup for Credit patient for waste.
Version 14.0+ Instructions
Valid items
1. Follow the rules of 2 and 6.
2. Retrieve dose amount from xaamt and dose unit from dssu.
3. If issue unit is requested, use qty. Otherwise, quantity can be calculated by dividing xaamt into
pkd. The result could be fractional.
4. Use uoi for UOM.
Invalid Items
Get waste data from the waste quantity token (wqty). The expected format of this field is: n uuu
where n = quantity and uuu = unit; (Example: 5 mg.)
Note: There is no guaranteed format as wqty is a free text field. As such, it cannot be calculated. Users
must be educated on how to enter waste on Color Touch cabinets.
In either scenario (valid/invalid items), the RXC interface should be able to calculate waste
quantity in inventory unit of measure if the pharmacy vendor system requires it.
Pre-14.0 Versions Instructions

1. Turn on Dose required flag.
Important: This may change the nurse workflow so discuss this with the customer before making
changes. This may be a normal setup at most hospitals.
a. [Items table] Check Dose required flag (token: dsrq).

b. [Color Touch cabinet] Enable Link Waste and Return to Issue.
c. Optional: [Color Touch cabinet] Enable Force Med order issue by dose.
2. Educate nurses to enter the waste amount in the proper format (n uuu). There is no coding
logic to enforce field entry format.
Note: Waste quantity is only available in the wqty token. It is a free-text field. (Example: 4 MG) Quantity
can be calculated if the XI transaction has the dxa token set to Y. This indicates the wqty token is
formatted as waste amount in dose unit of measure appended by dssu value.
Billable Upgrade
From the interface development perspective, this is a billable upgrade which should be quoted for
12 hours T&M (time and manpower).

IN-1
Index
A financial transaction (FT1) 5-4
acknowledgement formulary maintenance (ZFM) 7-5
message header 3-3 formulary maintenance (ZMI) 7-4
segment (MSA) 3-4 formulary update interface (RXF) 7-1
acknowledgement message 3-3
ADT G
interface 3-1 give code (RXE-2) 4-7
message header 3-5
message segments 3-4 H
sample message 3-11 HL7 10-1
system 3-1 HL7 standard 1-1, 2-1
Hybrid Lower Layer Protocol 2-1
B
backward compatibility 2-2 I
bin load 6-1 ICD9 3-10
bin unload 6-1 interface engine 1-1
BPOC 9-1 IV token A-1
C L
cart fill order 8-1 label printing A-1
charge for medication (RDS) 5-1
common order segment (ORC) 4-4 M
communications protocol 2-1
mapping table
component dose A-1
USR 10-3
component separator 2-1
mapping tables 3-10
CRT interface 8-1
facility 3-10
CRT message segments 8-2
other entries 3-10
patient area 3-10
D patient type 3-10
DFT message 5-5 master file entry (MFE) 7-3
DFT message segments 5-1 master file identification (MFI) 7-3
MCMO B-1
E interface changes B-1
Electronic Medical Records 9-1 Medicaid services D-1
eMAR 9-1 medical record number C-1
escape character 2-1 Medicare billing D-1
event (EVN) 5-3 Medication Administration 9-3
event types 3-5 medication dispense (DFT) 5-1
medication label printing A-1
F medication orders A-1
field mapping 8-2 merge event segment (MRG) 3-10
field separator 2-1 message events 3-2
field use 2-2 message header
USR 10-2

IN-2 Index
message header (MSH) 3-3, 5-2, 6-2 repetition separator 2-1

message segment header 2-1 RXA 9-3
message segments RXC interface 5-1
USR 10-2 RXF interface 7-1
messages 2-1 RXF message segments 7-2
MFE event codes 7-1 RXP interface 4-1
MFN messages 7-5
Minimal Lower Layer Protocol 2-1 S
MRN C-1 sample
multi-component medication order B-1 USR message 10-5
sample data 8-3, 9-5
N segment attribute 2-2
Notes 9-5 segment terminator 2-1
NTE 9-5 sequence number protocol 2-2
nurse-prepared IV A-1 single additive B-2
SinglePointe B-1
O SIU
observation/result segment (OBX) 3-9 appointment location 11-3
OmniCenter tokens 3-3, 4-2, 5-2, 6-2, 7-2 appointment notification 11-3
order control code (ORC.1) 8-1 sample message 11-5
SIU interface 11-1
P socket server 3-1
subcomponent separator 2-1
patient allergy (AL1) 3-8
patient demographics (PID) 5-3
patient ID C-1 T
patient ID (PID) 3-6 TCP/IP Socket 3-1, 10-1
patient visit (PV1) 3-7, 5-3 token 10-4
payer ID 3-10 nsa 10-4
pharmacy component order segment (RXC) 4-8 total intended dose A-1
pharmacy encoded order segment (RXE) 4-5 transactions tables C-1
pharmacy information 1-1 treatment component order segment (RXC) 4-8
pharmacy route segment (RXR) 4-8 treatment encoded order segment (RXE) 4-5
PK command C-1 treatment route segment (RXR) 4-8
code changes C-2 trigger event 2-2
exceptions C-2
pocket activity (ZPM) 5-5, 6-3 U
pocket maintenance 6-2 User Defined Segment 9-4
USR interface 10-1
Q
quantity/timing (RXE-1) 4-7 W
waste tables C-1
R
RAS 9-1 Z
specifications supplement 9-5 ZPM interface 6-1
RDE ZPM message 6-3
entries 4-9 ZPM message segments 6-2
message 4-10 ZRM 9-4
message segments 4-2 ZRX (custom segment) 8-1
record level event codes 10-1 ZU1 10-3

Documentation Feedback
This document is designed to provide relevant technical information to those responsible for the
implementation, service, and support of Omnicell products. The Documentation team needs your
input, so we can continue to improve our publications.
Sending Comments to the Technical Documentation Team

Did this document meet your needs? If so, please let us know what we’re doing right. If not, please
provide specific feedback. E-mail or fax your feedback as follows:
 E-mail: Documentation Requests e-mail group at documentationrequests@omnicell.com (specify the
document title or PN).
 Fax: Send this page, along with your feedback, to (650) 251-6266, attention: Documentation.
This document is designed to provide relevant technical information to Omnicell personnel
responsible for the implementation, service, and support of Omnicell Automation Systems.
Feedback Form
Name: E-mail:
Dept./Title: Phone:
Feedback:

Appendix D - TVH OMCL RX Interfaces

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Appendix D - TVH OMCL RX Interfaces

Uploaded by

Copyright:

Available Formats

HL7 Pharmacy Interface

HL7 Pharmacy Interface Specifications/67-3079 Rev G © 2015 Omnicell, Inc.

HL7 Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

ADT Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

RXP Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

© 2015 Omnicell, Inc. HL7 Pharmacy Interface Specifications/67-3079 Rev G

RDE Message Segments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2

RXC Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

ZPM Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

RXF Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

HL7 Pharmacy Interface Specifications/67-3079 Rev G © 2015 Omnicell, Inc.

Appendix A: Med Label Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1

Appendix B: MCMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-1

Documentation Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . FB-1

© 2015 Omnicell, Inc. HL7 Pharmacy Interface Specifications/67-3079 Rev G

© 2015 Omnicell, Inc. HL7 Pharmacy Interface Specifications/67-3079 Rev G

© 2015 Omnicell, Inc. HL7 Pharmacy Interface Specifications/67-3079 Rev G

Field Use Type

Sequence Number Protocol

Data Field Length

HL7 Pharmacy Interface Specifications/67-3079 Rev G © 2015 Omnicell, Inc.

Messages sent over socket. ADT Messages sent over MSMQ

© 2015 Omnicell, Inc. HL7 Pharmacy Interface Specifications/67-3079 Rev G

Supported Message Events

HL7 Pharmacy Interface Specifications/67-3079 Rev G © 2015 Omnicell, Inc.

Message Header Segment (MSH)

© 2015 Omnicell, Inc. HL7 Pharmacy Interface Specifications/67-3079 Rev G

Acknowledgment Segment (MSA)

ADT Message Segments

HL7 Pharmacy Interface Specifications/67-3079 Rev G © 2015 Omnicell, Inc.

Message Header (MSH)

Event Type (EVN)

© 2015 Omnicell, Inc. HL7 Pharmacy Interface Specifications/67-3079 Rev G

Patient Identification (PID)

HL7 Pharmacy Interface Specifications/67-3079 Rev G © 2015 Omnicell, Inc.

Patient Visit (PV1)

© 2015 Omnicell, Inc. HL7 Pharmacy Interface Specifications/67-3079 Rev G

Patient Allergy (AL1)

HL7 Pharmacy Interface Specifications/67-3079 Rev G © 2015 Omnicell, Inc.

Observation/Result Segment (OBX)

© 2015 Omnicell, Inc. HL7 Pharmacy Interface Specifications/67-3079 Rev G

Merge Event Segment (MRG)

CF1 INP OP1

HL7 Pharmacy Interface Specifications/67-3079 Rev G © 2015 Omnicell, Inc.

Sample ADT Message

© 2015 Omnicell, Inc. HL7 Pharmacy Interface Specifications/67-3079 Rev G

Messages sent over socket . RXP Messages sent over MSMQ

© 2015 Omnicell, Inc. HL7 Pharmacy Interface Specifications/67-3079 Rev G

Supported Order Control

RDE Message Segments

Code Segment Definition

HL7 Pharmacy Interface Specifications/67-3079 Rev G © 2015 Omnicell, Inc.

Message Header (MSH)

Patient Identification (PID)

Patient Visit (PV1)

Allergy Information (AL1)

© 2015 Omnicell, Inc. HL7 Pharmacy Interface Specifications/67-3079 Rev G

Common Order Segment (ORC)

HL7 Pharmacy Interface Specifications/67-3079 Rev G © 2015 Omnicell, Inc.

Pharmacy/Treatment Encoded Order Segment (RXE)

© 2015 Omnicell, Inc. HL7 Pharmacy Interface Specifications/67-3079 Rev G

HL7 Pharmacy Interface Specifications/67-3079 Rev G © 2015 Omnicell, Inc.

RXE-2 Give Code