The Order Entry transaction set provides for the transmission of orders or
information about orders between applications that capture the order, by those
that fulfill the order, and other applications as needed. An order is a
request for material or services, usually for a specific patient. These
services include medications from the pharmacy, clinical observations (e.g.,
vitals, I&Os) from the nursing service, tests in the laboratory, food from
dietary, films from radiology, linens from housekeeping, supplies from central
supply, an order to give a medication (as opposed to delivering it to the
ward), etc.
Most orders are associated with a particular patient. However, the Standard
also allows a department to order from another ancillary department without
regard to a patient (e.g., floor stock), as well as orders originating in an
ancillary department (i.e., any application may be the placer of an order or
the filler of an order).
We refer to the person or entity who places the order as the placer. We refer
to the person or entity that carries out the order as the filler (producer in
ASTM terminology). In the case where the person or entity that carries out the
order also requests the order, this person or entity is referred to as the
filler and placer of the order. The filler may also request another
application to assign a filler or placer order number (see Notes I and L, for
order control codes).
This chapter defines the transactions at the seventh level, i.e., the abstract
messages. Various schemes may be used to generate the actual characters that
make up the messages according to the communications environment. The HL7
Encoding Rules will be used where there is not a complete Presentation Layer.
This is described in Chapter 2, Section 2.4.8. The examples included in this
chapter were constructed according to the HL7 Encoding Rules.
This chapter describes the messages used to generate orders. Specific
transaction sets have been defined for orders: a) clinical observations and
diagnostic studies, b) treatments, c) diets, d) supplies, and e) other orders.
This chapter is organized accordingly. The first sections (4.1 and 4.2)
present the overall structure and rationale for these messages. Section 4.3
presents the message segments that are common to all of the order entry
messages. Section 4.4 describes the quantity/timing (TQ) data type. Sections
4.5 to 4.8 describe the messages for each of the major categories of orders
listed above. Each section about a type of order is organized into background
and overview, message structure, and message segments (that are specific to the
order class in question). Special discussions of the use of fields, segments
or messages, and examples are included.
Segments are introduced in order of occurrence in a message. A
cross-reference list of segments to page numbers is included at the end of the
chapter. A list of legally defined values for a field is included in the body
of the text, along with the field definition for easier reference.
Orders for laboratory tests, bedside monitoring, diagnostic imaging,
electrocardiograms, vital signs, etc., are subsumed under the observation
message set (4.5). In the development of the treatment order transaction set
(4.8), the focus has been on medication treatments, but the same transaction
set works well for total parenteral nutrition (TPN). There is hope that it is
also sufficient for other kinds of treatment orders, such as those performed by
the nursing service. But it has not yet been exercised in that context and may
well need further development. The orders for dietary (4.6) include all of the
usual diet specifications including snacks and guest trays. Supply orders (4.7)
are different in that they often are not patient-centered (e.g., requests to
stock the ward supply room).
1 filler: the application responding to, i.e., performing, a request
for services (orders) or producing an observation. The filler can also
originate requests for services (new orders), add additional services to
existing orders, replace existing orders, put an order on hold, discontinue an
order, release a held order, or cancel existing orders.
2 observation segment: an OBX segment defined in Chapter 7.
3 order: a request for a service from one application to a second
application. The second application may in some cases be the same; i.e., an
application is allowed to place orders with itself.
4 order detail segment: one of several segments that can carry order
information. Examples are OBR and RXO. Future ancillary-specific segments may
be defined in subsequent releases of the standard if they become necessary.
5 placer: the application or individual originating a request for
services (order).
6 placer order group: a list of associated orders coming from a single
location regarding a single patient.
The function of this message is to initiate the transmission of information
about an order. This includes placing new orders, cancellation of existing
orders, discontinuation, holding, etc. ORM messages can originate also with a
placer, filler, or an interested third party.
The trigger event for this message is any change to an order. Such changes
include submission of new orders, cancellations, updates, patient and
nonpatient specific orders, etc.
ORM General Order Message Chapter
MSH Message Header 2
[{NTE}] Notes and Comments (for Header) 2
[
PID Patient Identification 3
[{NTE}] Notes and Comments (for Patient ID) 2
[{AL1}] Allergy 3
[PV1] Patient Visit 3
]
{
ORC Common Order 4
[
Order Detail Segment OBR, etc. 4
[{NTE}] Notes and Comments (for Detail) 2
[
{
OBX Observation/Result 7
[{NTE}] Notes and Comments (for Results) 2
}
]
]
[BLG] Billing segment 4
}
a) The abstract message syntax for some order segments vary slightly. Please
refer to the appropriate sections for specific examples: for supply orders
(RQ), see Section 4.7; for pharmacy, see Section 4.8; and for dietary orders,
see Section 4.7.
b) The segment named "Order Detail Segment" represents whichever of these
order detail segment(s) is appropriate to the message, currently OBR, RQD, RQ1,
RXO, ODS, ODT.
c) The NTE segment(s) can be included in the ORM message in four places; in
each place the NTE refers to the segment which it follows. In particular, the
NTEs following the MSH refer only to the message header, the NTEs following the
order detail segment apply to the service defined by that ORC and order detail
segment.
d) The PID segment is required if and only if new orders are being entered and
they are related to a particular patient. However, it may sometimes be sent
for convenience at local discretion, and for nonpatient-related orders the PID
segment is never included.
e) The optional PV1 segment is present mainly to permit transmission of
patient visit information such as current location with an order.
f) The order detail segments are not required when a simple control message is
being sent. For example, a hold message (ORC-1-order control = HD) does
not require that an order segment follow it.
g) ORC-1-order control is critical to the operation of both ORM and ORR
messages. For example, to request cancellation of an order, one would transmit
a CA in ORC-1-order control of the appropriate ORC. (See the definition
of ORC-1-order control.)
h) A method to inquire for order status in the display format is provided in
Chapter 2, and uses the record format provided in Chapter 7.
i) Each order message that defines any type of new order (ORC-1-order
control = NW, CH, RO or SN) requires an ORC/OBR pair to define each order
to the receiving application. This also applies to any other types of orders,
with the OBR being replaced by the appropriate order detail segment, as defined
below. Thus two consecutive ORCs could occur if a cancel order request
(needing only the order numbers) were followed by a second cancel order
request. Many other examples are possible.
The function of this message is to respond to an ORM message. An ORR message
is the application acknowledgement to an ORM message. See Chapter 2 for a
description of the acknowledgement paradigm.
ORC segments are always required in ORM and ORR when a order detail segment is
present, but otherwise not. For example, a response ORR might include only the
MSH and MSA, but if an RQ1 is present, it must be preceded by an ORC.
The function (e.g., cancel, new order) of both ORM and ORR messages is
determined by the value in ORC-1-order control. (See the table of order
control values for a complete list.)
ORR General Order Acknowledgement Message Chapter
MSH Message Header 2
MSA Message Acknowledgement 2
[ERR] Error 2
[{NTE}] Notes and Comments (for Header) 2
[
[PID Patient Identification 3
[{NTE}]] Notes and Comments (for Patient ID) 2
{
ORC Common Order 4
[Order Detail Segment] OBR, etc. 4
[{NTE}] Notes and Comments (for Detail) 2
}
]
Note: ORRs for supply, pharmacy, and dietary orders all have slightly different message syntax; refer to the appropriate sections as detailed in Section 4.2.1.1 for exact details. |
The following segments (ORC and BLG) are common to many order messages.
The Common Order segment (ORC) is used to transmit data elements that are
common to all orders (all types of services that are requested). The ORC
segment is required in both the Order (ORM) and Order Acknowledgement (ORR)
messages.
If details are needed for a particular type of order segment (e.g., Pharmacy,
Dietary), the ORC must precede any order detail segment (e.g., RXO, ODS). In
some cases, the ORC may be as simple as the string ORC|OK|<placer order
number>|<filler order number>|<CR>.
If details are not needed for the order, the order detail segment may be
omitted. For example, to place an order on hold, one would transmit an ORC
with the following fields completed: ORC-1-order control with a value of
HD, ORC-2-placer order number, and ORC-3-filler order number.
There is some overlap between fields of the ORC and those in the order detail
segments. These are described in the succeeding sections.
SEQ |
LEN |
DT |
R/O |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
2 |
ID |
R |
|
0119 |
00215 |
Order
Control |
ORC use notes
a) placer order groups
The Standard supports a mechanism to collect several orders together in a
group. Most often this is used to represent an "ordering session" for a single
patient.
An order group is a list of orders (ORCs) associated with a ORC-4-placer
group number. A group is established when the placer supplies a placer
group number with the original order. The order group consists of all the ORCs
and order detail segments that have the same placer group number. Orders can
be removed from the group using cancel, or added using the replacement or
parent-child mechanisms. New orders cannot otherwise be added to the group.
b) duplicate fields
The ORC is intended to uniformly define the fields that are common to all
orders (i.e., requested services). Some ORC fields are duplicated in some
order detail segments (e.g., OBR, RXO). For example, ORC-2-placer order
number has the same meaning and purpose as OBR-2-placer order number
field. This promotes upward compatibility with past versions and ASTM.
The rule for using these fields is that the value must appear in the order
detail segment if it does not appear in the ORC. However, it is recommended to
transmit the field value in both places to avoid confusion.
c) parent/child - cancel, hold, discontinue
During transmission of a request to cancel, hold, or discontinue a parent
order, the request is intended to apply recursively to the parent order and all
associated child orders.
For example:
1) An EKG application receives an order for three EKGs on successive
mornings.
2) The EKG application creates three child orders, one for each requested
EKG.
3) The first daily EKG is performed when a request is received to cancel the
original parent order. (The parent is beyond the point of cancellation.)
4) The remaining, unperformed, children are canceled as a result of the
request.
4.3.1.0 ORC field definitions
Definition: determines the function of the order segment. Refer to table
0119 - order control for valid entries. Very detailed explanatory notes
are given at the end of this section.
This field may be considered the "trigger event" identifier for orders. The
codes fall roughly into the following three categories:
a) event request
Codes like "NW" (new order) and "CA" (cancel order request) are used to
initiate an event.
b) event acknowledgment
Codes like "OK" (order accepted) and "CR" (canceled as requested) are used to
reply to the event request.
c) event notification
Codes like "OC" (order canceled) and "OD" (order discontinued) are used to
notify other applications that an event has occurred. No application reply is
necessary.
Event request codes are intended to initiate an event. Event acknowledgment
codes are intended to reply to an application that requested an event. Event
notification codes are intended to notify another application that, e.g., the
filler has performed some action on an order that the other application, e.g.,
the placer needs to know.
Fillers, placers, and other applications can use event requests, event
acknowledgments, and event - notification-type trigger events interchangeably.
However, certain order control codes can originate only from the filler (e.g.,
CR) and others can only originate from the placer (e.g., CA).
Table 0119 Order control codes and their meaning
Value1 |
Description |
Originator2 |
Field Note3 |
|---|---|---|---|
NW |
New
Order |
P |
l |
1 The order control value field
2 "F": Values originate from the filler and are not restricted to be sent only
to the placer.
"P": Values originate from the placer or other application with placer
privileges (as agreed in interface negotiation.
3 See table notes below for explanation of codes.
a) CA A cancellation is a request not to do a previously ordered service.
Confirmation of the cancellation request is provided by the filler, e.g., a
message with an ORC-1-order control value of CR.
b) UC An unable-to-cancel code is used when the ordered service is at a point
that it cannot be canceled by the filler or when local rules prevent
cancellation by the filler. The use of this code is dependent on the value of
ORC-6-response flag.
c) DC A discontinue request code is used to stop an ongoing ordered service.
It is not the same as a cancellation request, which is used in an attempt to
prevent an order from happening.
d) RP A replacement is the substitution of one or more orders for one or more
previously
RQ ordered services.
RU
RO The replaced orders are treated as though they were canceled. If and when
an ordered service can be replaced are local site-specific determinations.
Use the parent/child order control codes if the site specifies that the
original order must remain intact. Do not use the replacement codes under this
circumstance.
For each order to be replaced, use an ORC-1-order control value of RP
(request for a replacement going to a filler) or RU (an unsolicited replacement
created by the filler) used by the filler to notify the placer and/or other
systems). By local agreement, the ORC segment (with RP or RU) may be followed
by its original order detail segment. The ORC segments (with RP or RU) must be
followed by an ORC segment with an ORC-1-order control value of RO
(indicating the replacement order). By local agreement, the ORC with the RO
value may be followed by an order detail segment.
For example, suppose that an ancillary application were replacing two OBR
orders with three different orders. The sequence of segments would be as
follows:
Figure 4-2 RU and RO usage (example)
Segment |
Order Control |
Comment |
|---|---|---|
ORC |
RU |
1st
replaced ORC |
Whether the OBR segments must be present is determined by the value of
ORC-6-response flag.
The described replacement method will handle all possible cases of
replacement: one-into-one, many-into-one, one-into-many, and many-into-many.
If the placer sent this request to the filler with two RPs, and this was a
response back from the filler to the placer, the two RUs (replaced unsolicited)
would be two RQs (replaced as requested).
Figure 4-3 RQ and RO usage (example)
Segment |
Order Control |
Comment |
|---|---|---|
ORC |
RQ |
1st
replaced ORC |
e) RP The order replace request code permits the order filler to replace one
or more new
RQ orders with one or more new orders, at the request of the placer
application.
f) RU The unsolicited replacement code permits the filler application to
notify another application without being requested from the placer
application.
g) RO The replacement order code is sent by the filler application to another
application indicating
RQ the exact replacement ordered service. It is used with the RP and RU
order control codes as described above.
h) RP The rules for the order numbers in ORC segments with an order control
value of RO
RQ are determined by the replacement type (RP or RU).
RU
RO In the case of the RU type (i.e., unsolicited replacement by the filler),
the filler order number is generated as usual by the filler application. The
placer order number is identical to the placer order number of the first
transmitted ORC with an order control value of RU.
In the case of the RP type (i.e., a replacement request from another
application to the filler), the placer order number is generated by the placer
application using the procedure for new orders. The filler order number is
generated by the filler application using the procedure identical for new
orders.
If a replacement sequence is used in an ORU message (i.e., during results
reporting), the following are the recommended segments to be used for the
replacement orders:
1) ORC with an order control value of RO
2) Any OBR segments (can be replaced by any order detail segments)
3) Optionally followed by observation result segments (OBX)
4) NTE segments can appear after the OBR (or any order detail segment) or
after an OBX segment as in a regular ORU message
i) PA The parent (PA) and child (CH) order control codes allow the spawning of
"child"
CH orders from a "parent" order without changing the parent (original order).
One or more ORC segments with an ORC-1-order control value of PA are
followed by one or more ORC segments with an ORC-1-order control value
of CH. Whether OBR segments must be present is determined by the value of
ORC-6-response flag.
For example, suppose that a microbiology culture produced two organisms and
corresponding sensitivity reports. Then the sequence of segments would be as
follows:
Figure 4-4 Example of two child orders
Segment |
Order Control |
Comment |
|---|---|---|
ORC |
PA |
1st
parent ORC |
The assignment of placer numbers in the parent-child paradigm depends on
whether the placer of filler creates the child order and in the latter case, on
whether the placer supports the SN/NA transaction. If the placer creates the
child orders it will assign their placer numbers according to its usual
procedures. If the filler creates the child orders there are two possibilities:
each child will inherit the placer number of its parent, or the filler will use
the SN/NA transaction to request that the placer assign a placer number. In
either case, the filler application creates the filler numbers of the children
according to its usual procedures.
Whenever a child order is transmitted in a message the ORC segment's
ORC-8-parent is valued with the parent's filler number (if originating from the
filler) and with the parent's placer number (if originating from the filler or
if originating from the placer).
The parent-child mechanism can be used to "expand" a parent order (e.g., an
order for three EKGs on successive mornings).
j) RE The observations-to-follow code is used to transmit patient-specific
information with an order. A order detail segment (e.g., OBR) can be followed
by one or more observation segments (OBX). Any observation that can be
transmitted in an ORU message can be transmitted with this mechanism. When
results are transmitted with an order, the results should immediately follow
the order or orders that they support.
The following example shows the sequence of segments for three Pharmacy
orders. It illustrates the use of the RE code:
Figure 4-5 RE usage (example)
Segment |
Order Control |
Comment |
|---|---|---|
MSH |
|
|
In this version of HL7, results can be transmitted with an order as one or
more OBX segments without the necessity of including the ORC and OBR
segments.
Observations can be transmitted in an ORU message without using an ORC.
There are times when it is necessary to transmit information not included in
the OBR segments of the ORU message. In this case, it is recommended that the
ORC be included in the ORU message.
The order control value of RE is required only in ORM messages to indicate
that an order is followed by observation results (OBX). The RE code is not
necessary in the ORU message because it is expected that the OBR segments can
be followed by observation results (OBX).
k) RR Left in for backwards compatibility. In the current version it is
equivalent to an accept acknowledgement. The request-received code indicates
that an order message has been received and will be processed later. The order
has not yet undergone the processing that would permit a more exact
response.
l) SN There are three circumstances that involve requesting an order number
(ORC-2-placer
NA order number or ORC-3-filler order number):
NW
1) When the filler application needs to request an ORC-3-filler order
number from a centralized application (e.g., HIS)
2) When the filler application needs to request an ORC-2-placer order
number from some other application (e.g., Order Entry)
3) When an application (not the filler application) wants to assign an
ORC-3-filler order number for a new order
The filler application needs a centralized filler order number
SN The send order number code provides a mechanism for the filler to
request an ORC-3-filler order number from some centralized application
(called "other" in the table below), such as a central HIS, by sending an ORM
message containing an ORC-1-order control value of SN. This ORC has a
null ORC-3-filler order number and an ORC-2-placer order number
created by the filler application when the filler originates the order.
The ORM (SN type) message can be acknowledged by two methods:
i) By an ORR message containing an ORC-1-order control value of OK.
An unsolicited ORM message can be sent at a future time, containing an ORC with
ORC-1-order control value of NA.
ii) By an ORR message containing an ORC-1-order control value of NA
as described below.
NA The number assigned code allows the "other" application to notify
the filler application of the newly assigned filler order number.
ORC-1-order control contains value of NA, ORC-2-placer order
number (from the ORC with the SN value), and the newly assigned filler
order number.
Note: Both the placer order number and the filler order number have the filler's application ID. |
Code |
From |
ORC-2-Placer Order Number |
ORC-3-Filler Order Number |
SN |
filler
application |
placer
order number^filler application ID |
null |
The filler application needs a placer order number
SN The send order number code provides a mechanism for the filler
application to request an ORC-2-placer order number from another
application (called "other" in the table below) by sending an ORM message
containing an ORC-1-order control value of SN. This ORC has a null
ORC-2-placer order number and an ORC-3-filler order number
created by the filler application when the filler originates the order.
The ORM (SN type) message can be acknowledged by two methods:
i) By an ORR message containing an ORC-1-order control value of OK.
An unsolicited ORM message can be sent at a future time, containing an
ORC-1-order control value of NA.
ii) By an ORR message containing an ORC-1-order control value of NA
as described below.
NA The number assigned code allows the "other" application to notify
the filler application of the newly assigned ORC-2-placer order number.
The ORC contains an ORC-1-order control value of NA, the newly assigned
ORC-2-placer order number, and the ORC-3-filler order number
(from the ORC with the SN value).
Note: The new ORC-2-placer order number has the placer's application ID. |
Code |
From |
ORC-2-Placer Order Number |
ORC-3-Filler Order Number |
SN |
filler
application |
null |
filler
order number^filler application ID |
An application wants to assign a filler order number
NW When the application creating an order (not the filler application)
wants to assign a filler order number for a new order
or
RO (RO following an RP). In this case, the "other" application
completes ORC-3-filler order number, using the filler application ID as
the second component of the filler order number.
Code |
From |
ORC-2-Placer Order Number |
ORC-3-Filler Order Number |
NW or RO |
other application to the filler |
placer order number^placer application ID |
filler order number^filler application ID |
m) CN The combined result code provides a mechanism to transmit results that
are associated with two or more orders. This situation occurs commonly in
radiology reports when the radiologist dictates a single report for two or more
exams represented as two or more orders. For example, knee and hand films for
a rheumatoid arthritis patient might generate a single dictation on the part of
the radiologist.
When such results are reported the CN code replaces the RE code in all but
the last ORC, and the results follow the last ORC and its OBR. An example
follows of a single report following three ORCs:
MSH|...
PID|...
ORC|CN|...
OBR||A4461XA^HIS|81641^RAD|73666^Bilateral Feet|...
ORC|CN|...
OBR||A4461XB^HIS|81642^RAD|73642^Bilateral Hand PA|...
ORC|RE|...
OBR||A4461XC^HIS|81643^RAD|73916^Bilateral Knees|...
OBX||CE|73916&IMP||Radiologist's Impression|...
OBX||CE|73642&IMP||Radiologist's Impression|...
OBX||FT|73642&GDT||Description|...
Components: <unique placer ID> ^<placer application
ID>
Definition: placer application's order number.
This is a composite field. The first component is a string of up to 15
characters that identifies an individual order (e.g., OBR). It is assigned by
the placer (ordering application). It identifies an order uniquely among all
orders from a particular ordering application. The second component contains
the application ID of the placing application. The application ID is a string
of up to six (6) characters that will be uniquely associated with an
application. A given institution or group of intercommunicating institutions
should establish a unique list of applications that may be potential placers
and fillers and assign unique application ID's. The two components are
separated by a component delimiter.
There are three situations in which the true placer is somewhat arbitrary (and
thus not unique):
a) in ORC-1-order control value of RO, following an RU replacement;
b) in ORC-1-order control value of CH (child orders); and
c) in ORC-1-order control value of SN (send number).
See the Table Notes under ORC-1-order control for the details of how
the ORC-2-placer order number is assigned in these cases.
A given institution or group of intercommunicating institutions should
establish a list of applications that may be potential placers and fillers of
orders and assign each a unique application ID. The application ID list
becomes one of the institution's master dictionary lists that are documented
elsewhere in the HL7 2.2 Standard. Since third party applications (those other
than the placer and filler of an order) can send and receive ORM and ORR
messages, the placer application ID in this field may not be the same as any
sending and receiving application on the network (as identified in the MSH
segment).
ORC-2-placer order number is the same as OBR-2-placer order
number. If the placer order number is not present in the ORC, it must be
present in the associated OBR and vice versa. If both fields, ORC-2-placer
order number and OBR-2-placer order number are valued, they must
contain the same value. When results are transmitted in an ORU message, an ORC
is not required, and the identifying placer order number must be present
in the OBR segments.
These rules apply to the few other fields that are present in both ORC and OBR
for upward compatibility (e.g., quantity/timing, parent numbers, ordering
provider, and ordering call back numbers).
Components: <unique filler ID> ^ <filler application
ID>
Definition: order number associated with the filling application. Its first
component is a string of up to 15 characters that identifies an order detail
segment (e.g., OBR). It is assigned by the order filler (receiving)
application. This string must uniquely identify the order (as specified in the
order detail segment) from other orders in a particular filling application
(e.g., clinical laboratory). This uniqueness must persist over time.
The second component contains the filler application ID. The filler
application ID is a string of up to six characters that uniquely defines the
application from other applications on the network. The second component of
the filler order number always identifies the actual filler of an order.
A given institution or group of intercommunicating institutions should
establish a list of applications that may be potential placers and fillers of
orders and assign each a unique application ID. The application ID list
becomes one of the institution's master dictionary lists that are documented
elsewhere in the HL7 2.2 Standard. Since third-party applications (those other
than the placer and filler of an order) can send and receive ORM and ORR
messages, the filler application ID in this field may not be the same as any
sending and receiving application on the network (as identified in the MSH
segment).
ORC-3-filler order number is the same as OBR-3-filler order
number. If the filler order number is not present in the ORC, it must be
present in the associated OBR. (This rule is the same for other identical
fields in the ORC and OBR and promotes upward and ASTM compatibility.) This is
particularly important when results are transmitted in an ORU message. In this
case, the ORC is not required and the identifying filler order number must be
present in the OBR segments.
The filler order number (OBR-3 or ORC-3) also uniquely identifies an
order and its associated observations. For example, suppose that an
institution collects observations from several ancillary applications into a
common database and this common database is queried by yet another application
for observations. In this case, the filler order number and placer order
number transmitted by the common database application would be that of the
original filler and placer, respectively, rather than a new one assigned by the
common database application.
Similarly, if a third-party application, not the filler or placer, of an order
were authorized to modify the status of an order (say, cancel it), the
third-party application would send the filler an ORM message containing an ORC
segment with ORC-1-order control equal to "CA" and containing the
original placer order number and filler order number, rather than assign either
itself.
Components: <unique group ID> ^ <placer application
ID>
Definition: allows an order placing application to group sets of orders
together and subsequently identify them.
The first component is a string of up to 15 characters that uniquely
identifies all order groups from the given placer application. It is assigned
by the placer application and may come from the same series as the placer order
number of the ORC, but this is not required.
The second component is a placer application ID identical to the second
component of ORC-2-placer order number. Order groups and how to use
them are described in detail at the end of the ORC section under "Use Notes"
and in the Examples.
Definition: status of an order. Refer to table 0038 - order status
for valid entries. The purpose of this field is to report the status of an
order either upon request (solicited), or when the status changes
(unsolicited). It does not initiate action. It is assumed that the order
status always reflects the status as it is known to the sending application at
the time that the message is sent. Only the filler can originate the value of
this field.
Although table 0038 - order status contains many of the same values
contained in table 0119 - order control, the purpose is different.
Order status may typically be used in a message with an ORC-1-order
control value of SR or SC to report the status of the order on request or
to any interested party at any time.
Table 0038 Order status
Value |
Description |
|---|---|
CA |
Order was canceled |
Definition: allows the placer (sending) application to determine the amount
of information to be returned from the filler. Sometimes the requested level
of response may not be possible immediately, but when it is possible, the
filler (receiving) application must send the information. When the field is
null, D is the default value of the field. Refer to table 0121 - response
flag for valid entries.
Table 0121 Response flag
Value |
Description |
E |
Report
exceptions only |
Components: <quantity (CQ)> ^ <interval (CM)>
^<duration> ^ <start date/time (TS)> ^ <end date/time (TS)> ^
<priority (ID)> ^ <condition (ST)> ^ <text (TX)> ^
<conjunction (ID)> ^ <order sequencing>
Definition: determines the priority, quantity, frequency, and timing of an
atomic service. Order segments should be thought of as describing an atomic
service. It is a composite field that is defined in detail in Section 4.4.
For example, if an OBR segment describes a unit of blood, this field might
request that 3 such units be given on successive mornings. In this case
ORC-7-quantity/timing would be "1^XQAM^X3".
ORC-7-quantity/timing is the same as OBR-27-quantity/timing.
Components: <parent's placer order number> ^ <parent's filler
order number>
Definition: relates a child to its parent when a parent-child relationship
exists. The parent-child mechanism is described under ORC-1-order
control notes. The first component contains the placer order number of the
parent order. It is required when the order is a child.
The second component contains the filler order number of the parent order.
The components of the placer order number and the filler order number are
transmitted in sub-components of the two components of this field.
ORC-8-parent is the same as OBR-29-parent.
Definition: date and time the current transaction enters the ordering
application. For messages creating new orders, this is the date and time the
order was entered.
For other messages, this is the date and time the current transaction (e.g.,
cancellation) enters the sending application. This date and time is for the
current transaction and is not a "replacement" time for a correction to the
original order. Similarly, ORC-10-entered by, ORC-11-verified
by, and ORC-13-enterer's location of this segment relate to the
current transaction, not the original order.
Components: <ID number> ^ <family name> ^ <given name>
^ <middle initial or name> ^ <suffix (e.g., JR or III)> ^
<prefix (e.g., DR)> ^ <degree (e.g., MD)> ^ <source
table>
Definition: identity of the person who actually keyed the request into the
application. It provides an audit trail in case the request is entered
incorrectly and the ancillary department needs to clarify the request. By
local agreement, either the ID number or name component may be omitted.
Components: <ID number> ^ <family name> ^ <given name>
^ <middle initial or name> ^ <suffix (e.g., JR or III)> ^
<prefix (e.g., DR)> ^ <degree (e.g., MD)> ^ <source
table>
Definition: identity of the person who verified the accuracy of the entered
request. It is used in cases where the request is entered by a technician and
needs to be verified by a higher authority (e.g., a nurse). By local
agreement, either the ID number or name component may be omitted.
Components: <ID number> ^ <family name> ^ <given name>
^ <middle initial or name> ^ <suffix (e.g., JR or III)> ^
<prefix (e.g., DR)> ^ <degree (e.g., MD)> ^ <source
table>
Definition: identity of the person who is responsible for creating the
request (i.e., ordering physician). ORC-12-ordering provider is the
same as OBR-16-ordering provider.
Definition: location (e.g., department, floor) of the person who entered the
request. It is a composite field that may be used on a site-specific basis to
include some subcategory of department. For example, ICU4 might be the
designation for a fourth-floor ICU location.
Definition: telephone number to call for clarification of a request or other
information regarding the order. ORC-14-call back phone number is the
same as OBR-17-order call back phone number.
Definition: date/time that the changes to the request took effect or are
supposed to take effect.
If ORC-9-transaction date/time is after or equal to ORC-16-order
effective date/time, the data values in the ORC and its subordinate
segments took effect on the order effective date/time.
If ORC-9-transaction date/time is before the time specified in
ORC-15-order effective date/time, the data values in ORC and its
subordinate segments are planned to take effect on the order effective
date/time.
If ORC-15-order effective date/time is left blank, its value is assumed
to be equal to that specified in ORC-9-transaction date/time or
MSH-7-message date/time if the transaction date/time is blank.
In the case where the time specified in ORC-15-effective date/time (for
the order control code event in the same ORC segment) is different from the
corresponding date/time in ORC-7-quantity/timing, the time specified in
ORC-15-order effective date/time takes precedence. Thus if the ORC
event is a discontinue request to the filler for a continuing order, and the
order-effective date/time is prior to the end date/time of
ORC-7-quantity/timing, the order effective date/time should take
precedence. If the order identified in the ORC has children, the children
which have not started should be canceled; if there is a child in process, it
should be discontinued; if a child has progressed beyond the point where it can
be discontinued, its status is unaffected.
Components: <identifier> ^ <text> ^ <name of coding
system>^<alternate identifier> ^ <alternate text> ^ <name of
alternate coding system>
Definition: explanation (either in coded or text form) of the reason for the
order event described by the order control code (table 0119). Whereas
an NTE after the order specific segment (e.g., RXO, ORO, OBR) would provide a
comment for that specific segment, the purpose of the order control code reason
is only to expand on the reason for the order event.
ORC-16-order control code reason is typically not valued when
ORC-1-order control is NW, although it could be. In the case of a
canceled order, for example, this field is commonly used to explain the
cancellation. A Pharmacy system that canceled a drug order from a physician
because of a well documented allergy would likely report the fact of the
allergy in this field.
If it canceled the order because of a drug interaction this field might
contain at least the names (and codes, if needed) of the interacting
substances, the text describing the interaction, and the level of severity of
the interaction.
Components: <identifier> ^ <text> ^ <name of coding
system>^<alternate identifier> ^ <alternate text> ^ <name of
alternate coding system>
Definition: organization that the enterer represents at the time he/she
enters/maintains the order.
Components: <identifier> ^ <text> ^ <name of coding
system>^<alternate identifier> ^ <alternate text> ^ <name of
alternate coding system>
Definition: identifier of the physical device (terminal, PC) used to enter
the order.
Components: <ID number> ^ <family name> ^ <given name>
^ <middle initial or name> ^ <suffix (e.g., Jr or III)> ^
<prefix (e.g., Dr)> ^<degree (e.g., MD)> ^ <source
table>
Definition: Identity of the person who initiated the event represented by the
corresponding order control code. For example, if the order control code is CA
(cancel order request), this field represents the person who requested the
order cancellation.
The BLG segment is used to provide billing information, on the ordered
service, to the filling application.
SEQ |
LEN |
DT |
R/O |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
1 |
15 |
CM |
0100 |
00234 |
When
to Charge |
4.3.2.0 BLG field definitions
Components: <when to charge code (ID)> ^ <date/time
(TS)>
Definition: This field determines when to charge for the ordered service.
The first component contains a value defined in table 0100 - when to
charge. The second component is used to express the exact time to charge
for the ordered service; it is used only when the when to charge value
is T. When used, it is expressed as a TS data type.
Value |
Description |
|---|---|
D |
On
discharge |
Definition: identifies someone or something other than the patient to be
billed for this service. It is used in conjunction with BLG-3-account
ID.
Value |
Description |
|---|---|
CH |
Charge |
Components: <account number (NM)> ^ <check digit (NM)> ^
<check digit scheme (ID)> ^ <facility ID (ST)>
Definition: identifies the account to be billed. It is used in conjunction
with BLG-2-charge type. Refer to table 0061 - check digit scheme
in Chapter 2.
Components: <quantity> ^ <interval> ^ <duration> ^
<start date/time> ^ <end date/time> ^ <priority> ^
<condition> ^ <text> ^ <conjunction> ^ <order
sequencing>
Definition: Quantity/timing (ORC-7, OBR-27) provides a means of
specifying when the service described by the order segment is to be performed
and how frequently. It is a complex multicomponent field that can have
repeats; i.e., more than one quantity/timing specification, separated by repeat
delimiters, may appear. It is a distinct data type (see section 2.4.5.20).
The components of a single quantity/timing specification are described in the
subsections: 4.4.1 through 4.4.10.
Subcomponents: <quantity & units>
Definition: quantity of the service that should be provided at each service
interval. E.g, if two blood cultures to be obtained every 4 hours, the
quantity would be 2. If three units of blood are to be typed and
cross-matched, the quantity would be 3. The default value is 1. When units
are required, they can be added, specified by a subcomponent delimiter.
Note: The component delimiter in this CQ is demoted to a subcomponent delimiter. |
Subcomponents: <repeat pattern & explicit time
interval>
Definition: determines the interval between repeated services.
The default is one time only, the first subcomponent is the repeat pattern,
and the second subcomponent is the explicit time at which pattern is to be
executed.
Definition: some suggested codes:
Q<integer>S |
every <integer> seconds |
Q<integer>M |
every <integer> minutes |
Q<integer>H |
every <integer> hours |
Q<integer>D |
every <integer> days |
Q<integer>W |
every <integer> weeks |
Q<integer>L |
every <integer> months (Lunar cycle) |
Q<integer>J<day#> |
repeats on a particular day of the week, from the French jour (day). If <integer> is missing, the repeat rate is assumed to be 1. Day numbers are counted from 1=Monday to 7=Sunday. So Q2J2 means every second Tuesday; Q1J6 means every Saturday. |
BID |
twice a day at institution-specified times (e.g., 9AM-4PM) |
TID |
three times a day at institution-specified times (e.g., 9AM-4PM-9PM) |
QID |
four times a day at institution-specified times (e.g., 9AM-11AM-4PM-9PM) |
Note: None of the above three specifications are equivalent to their Q<integer>H counterpart. QID is not Q6H. The former is unequally spaced; the latter is equally spaced. |
|
QAM |
in the morning at institution-specified time |
QSHIFT |
during each of three eight-hour shifts at institution-specified times |
QOD |
every other day (same as Q2D) |
QHS |
every day before the hour of sleep |
QPM |
in the evening at institution-specified time |
C |
service is provided continuously between start time and stop time |
U <spec> |
for future use, where <spec> is an interval specification as defined by the UNIX cron specification. |
PRN |
given as needed |
PRNxxx |
where xxx is some frequency code (e.g., PRNQ6H); given as needed over the frequency period. |
Once |
one time only. This is also the default when this component is null. |
Definition: explicitly lists the actual times referenced by the code in the
first subcomponent, in the following format: HHMM,HHMM,HHMM,... This second
subcomponent will be used to clarify the first subcomponent in cases where the
actual administration times vary within an institution. If the time of the
order spans more than a single day, this new subcomponent is only practical if
the same times of administration occur for each day of the order. If the
actual start time of the order (as given by the fourth subcomponent of the
quantity/timing field) is after the first explicit time, the first
administration is taken to be the first explicit time after the start time. In
the case where the patient moves to a location having a different set of
explicit times, the existing order may be updated with a new quantity/timing
field showing the changed explicit times.
Ex: 2nd component of quantity/timing field:
...^QID&0230,0830,1430,2030^...
Definition: Indicates how long the service should continue after it is
started. The default is INDEF (do indefinitely). This component is coded as
follows:
S<integer> = <integer> seconds
M<integer> = <integer> minutes
H<integer> = <integer> hours
D<integer> = <integer> days
W<integer> = <integer> weeks
L<integer> = <integer> months
X<integer> = <integer> times at interval specified in the order.
A request for 2 blood cultures Q2H X3 would imply obtaining 2 blood cultures 3
different times at 2-hour intervals for a total of 6 blood cultures.
T<integer> = at the interval and amount stated until a total of
<integer> "DOSAGE" is accumulated. Units would be assumed to be the same
as in the QUANTITY field.
INDEF = do indefinitely - also the default
Definition: may be specified by the orderer, in which case it indicates the
earliest date/time at which the services should be started. In many cases,
however, the start date time will be implied or will be defined by other fields
in the order record (e.g., urgency - STAT). In such a case, this field will be
empty.
The filling service will often record a value in this field after receipt of
the order, however, and compute an end time on the basis of the start date/time
for the filling service's internal use.
Definition: when filled in by the requester of the service, this field should
be the latest date-time that the service should be performed. If it has not
been performed by the specified time, it should not be performed at all. The
requester may not always fill in this value, yet the filling service may fill
it in on the basis of the instruction it receives and the actual start time.
Regardless of the value of the end date/time, the service should be stopped at
the earliest of the date/times specified by either the duration or the end
date/time.
Definition: describes the urgency of the request. The following values are
suggested (the default for Priority is R):
S = Stat. With highest priority.
A = ASAP. Fill after S orders.
R = Routine. Default.
P = Preop
T = Timing critical. A request implying that it is critical to come as close
as possible to the requested time, e.g., for a trough antibiotic level.
If using the value "T" (timing critical), the degree of criticality can be
specified thus:
Format:
TS<integer> = timing critical within <integer> seconds
TM<integer> = timing critical within <integer> minutes
TH<integer> = timing critical within <integer> hours
TD<integer> = timing critical within <integer> days
TW<integer> = timing critical within <integer> weeks
TL<integer> = timing critical within <integer> months
For the sequential orders specification, these values specify the time
criticality with which the predecessor order must be followed by the given
order.
Definition: This is a free text field that describes the conditions under
which the drug is to be given. For example, PRN pain, or to keep
blood pressure below 110. The presence of text in this field should be
taken to mean that human review is needed to determine the how and/or when this
drug should be given.
Definition: full text version of the instruction (optional).
Definition: non-null component indicates that a second timing specification
is to follow using the repeat delimiter. This field can take three values:
a) S = Synchronous
Do the next specification after this one (unless otherwise constrained by the
following components: ORC-4^4-start date/time and ORC-4^5-end
date/time).
An "S" specification implies that the second timing sequence follows the
first, e.g., when an order is written to measure blood pressure Q15 minutes for
the 1st hour, then every 2 hours for the next day.
b) A = Asynchronous
Do the next specification in parallel with this one (unless otherwise
constrained by the following components: ORC-4^4-start date/time and
ORC-4^5-end date/time). The conjunction of "A" specifies two parallel
instructions, as are sometimes used in medication, e.g., prednisone given at 1
tab on Monday, Wednesday, Friday, and at 1/2 tab on Tuesday, Thursday,
Saturday, Sunday.
c) C = This is an actuation time
It will be followed by a completion time for the service. This code allows
one to distinguish between the time and priority at which a service should be
actuated (e.g., blood should be drawn) and the time and priority at which a
service should be completed (e.g., results should be reported).
For continuous or periodic services, the point at which the service is
actually stopped is determined by the components ORC-4^5-end date/time
and ORC-4^3-duration, whichever indicates an earlier stopping time.
Ordinarily, only one of these components would be present, but if one requested
an EKG with the specification
^1^QAM^X3^D10
then the EKG would be done for only three days since the number of repeats (3)
defined the earlier stopping time.
Definition: there are many situations, such as the creation of an order for a
group of intervenous (IV) solutions, where the sequence of the individual
intervenous solutions (each an order in itself) needs to be specified. There
are other situations, where part of the order's instructions contains a results
condition of some type, such as "PRN pain." There is currently a free text
"condition" component of ORC-4-quantity/timing which allows any
condition to be specified. However, to support a fully encoded version of
order sequencing, or results condition, we have defined in the following
paragraphs a 10th component of ORC-4-quantity/timing.
The sequencing conditions supported by this 10th component are based on the
completion of a certain order.
Components beyond the 10th are reserved for future use in specifying multiple
conditions to be evaluated before the execution of the order. Any such future
specifications will be upwardly compatible from the current quantity/timing
definitions.
Note: If the 10th component is present, the 7th component (condition) will be considered as a text "note" to be displayed on the order. That is, no attempt will be made to interpret it as part of the machine-readable sequencing specification. |
To define a sequence condition, the 10th component of the quantity/timing
field component is divided into the subcomponents described in figure 4-7.
Figure 4-7 Subcomponents of order sequences
Subcomponent |
Contains |
Notes |
|---|---|---|
1 |
Sequence/Results Flag |
S for sequence conditions; R is reserved for possible future use. |
2, 3 |
Placer Order Number |
Required/Optional: Uses two subcomponents since the placer order number has two components. We have not defined sub-subcomponents in HL7. |
4, 5 |
Filler Order Number |
Required/Optional: Uses two subcomponents since the filler order number has two components. We have not defined sub-subcomponents in HL7. |
6 |
Sequence Condition Value |
The
acceptable condition values have the form commonly used in project planning
methodologies: |
7 |
Maximum Number of Repeats |
|
Use notes:
Suppose the following:
The predecessor order is defined by the OE1000&OrdEnt as the placer order
number, in subcomponents 2 and 3 of component 10 of
ORC-4-quantity/timing.
The successor order, this order, has the placer order number OE1001^OrdEnt in
the ORC segment.
The following sequence condition values have the following meanings:
ES + 10M The finish time of OE1000&OrdEnt (predecessor) plus 10 minutes
defines the start time of the successor, OE1001^OrdEnt (this order); i.e.,
start this order 10 minutes after the completion of its predecessor.
SS - 10M The start time of the predecessor minus 10 minutes defines the start
time of this order; i.e., start this order 10 minutes before its predecessor.
For the special case where there is a cycle of orders that must be repeated,
the first order to be executed will have a "sequence condition value" whose
first character is an asterisk (*).
Example:
*FS+10M Translates to: execute this order the first time without evaluating
the condition specified in the 10th component; but repeat only its execution
when the specified external order's start or finish date/time has met this
condition. This specification generates a repetition of the order for each
iteration of the cycle.
Note: This requires that the ordering application be able to specify the placer order number of the last order in the cycle in the first order's quantity/timing specification. |
To implement a cyclic group of four IV orders, using the parent/child
paradigm, the parent specifies a custom group of IVs, and the following
occurs:
ORC-4-quantity/timing of the second child order specifies that it
follows the first child order.
ORC-4-quantity/timing of the third child order specifies that it
follows the second child order.
ORC-4-quantity/timing of the fourth child order specifies that it
follows the third order.
To repeat the group of four child orders in a cyclic manner, the following
occurs:
ORC-4-quantity/timing of the first child order specifies that it is to
be executed once without any dependence on the completion of other orders.
Its second execution follows the completion of the fourth order. See example
in Section 4.8.16.2.
This scheme allows the following to be tracked:
The status of the whole group of orders to be reported back at the level of
the parent order.
The status for each individual IV order by following the status of the
corresponding child order.
Separate Orders example:
The same group of orders can be sent as a group of four orders (without a
common parent), linked only by the data in their quantity/timing fields. In
this case, there is no convenient HL7 method of transmitting the order status
of the group as a whole without transmitting the status of each of the four
separate orders.
Cancellation/discontinuation/hold order control events:
This logic implies the normal execution of the referenced predecessor order.
Thus a cancel (or discontinuation or hold) of a predecessor order implies the
cancellation (or discontinuation or hold) of all subsequent orders in the
chain.
If the referenced order has been canceled (or discontinued or held), the
current order inherits that same status.
In the case of hold, the removal of the hold of the predecessor implies a
removal of the hold for the given order (which can then be executed according
to the specification in the 10th component).
3^once
Perform the service at one point in time, e.g., order 3 units of blood to be
given once.
1^QHS^X2
Perform the service twice at bedtime, e.g., give a unit of blood at bedtime on
two sequential nights.
1^C^3D
Do a service continuously for 3 days.
1^Q1H^X4^^^^PVCs>10/min
Perform an EKG every hour up to a maximum of 4 EKGs, if patient is having more
than 10 PVCs per minute.
1^Q2J^^1432
Perform a service every Tuesday at 2:32 p.m.
1^^^^198911210800
Perform a test before 11/21/89 0800, e.g., some preop laboratory tests.
1^Q3600S^X5^198911051030
Perform a service every hour for 5 hours starting at 10:30 a.m. 11/5/89, e.g.,
draw a blood glucose.
1^QAM^X3^^^^^S~1^QOD^4D^^^if K+>5.5.
Perform a service every morning for 3 days and then do it every other morning
for 4 days (i.e., max twice) if the serum potassium is greater than 5.5.
^^^198812120800^^T^^Trough specimen for MIC^C~^^^^^R
Draw a blood specimen exactly at 8:00 a.m. on 12/12/1988 and report results
routinely.
General (taken from ASTM 1238-91)
The Observation Request (OBR) segment is used to transmit information specific
to an order for a diagnostic study or observation, physical exam, or
assessment.
The Observation Request segment defines the attributes of a particular request
for diagnostic services (e.g., laboratory, EKG) or clinical observations, e.g.,
vital signs or physical exam. When a placer requests a given set of
observations, always include an order segment. For lab tests, the information
in the order segment usually applies to a single specimen. However, there is
not a one-to-one relationship between specimen and tests ordered. Different
test batteries will usually require their own order segments even when they can
be performed on a single specimen. In this case, the specimen information must
be duplicated in each of the order segments that employ that specimen. For
other diagnostic studies, e.g., chest xray, a separate order segment will
usually be generated for each diagnostic study.
Though multiple observation batteries can be ordered on a single order
segment, the observation filler shall generate a separate order segment for
each battery that it processes independently, e.g., electrolyte, CBC, vital
signs. When reporting the observations, the filling service shall copy the
appropriate order (specimen) information from the original order segment into
each of the new order segments so that a separate "order" segment is returned
to the placer as a "header" for each separate battery of observations.
In the event that an ordered battery of observations cannot be performed,
e.g., because of hemolysis on a blood sample, an order segment will be returned
to the placer with OBR-25-result status equal to X (to indicate that the
study was not performed). In this case, no observation segments will be
transmitted.
When observations are successfully completed, the message returned to the
placer will include the order segment (OBR) followed by observation (OBX)
segments for each distinct observation generated by the order (see Chapter 7).
The number of such observation segments will depend upon the number of
individual measurements performed in the process.
OBX segments can be sent by the placer along with an order to provide the
filling service with clinical data needed to interpret the results. (See
Chapter 7 for OBX details.)
SEQ |
LEN |
DT |
R/O |
RP/# |
TBL# |
Item# |
Element Name |
1 |
4 |
SI |
C |
|
|
00237 |
Set
ID - Observation Request |
4.5.1.0 OBR field definitions
The daggered (+) items in this segment are not created by the placer. They
are created by the filler and valued as needed when the OBR segment is returned
as part of a report. Hence on a new order sent to the filler, they are not
valued. There is an exception when the filler initiates the order. In that
case, the filler order number is valued and the placer order number may be
blank.
The starred (*) fields are only relevant when an observation is associated
with a specimen. These are completed by the placer when the placer obtains the
specimen. They are completed by the filler when the filler obtains the
specimen.
OBR-7-observation date/time and OBR-8-observation end date/time
(flagged with #) are the physiologically relevant times. In the case of an
observation on a specimen, they represent the start and end of the specimen
collector. In the case of an observation obtained directly from a subject
(eg., BP, Chest Xray), they represent the start and end time of the observation.
Definition: for the first order transmitted, the sequence number shall be 1;
for the second order, it shall be 2; and so on.
Components: <unique placer ID> ^ <placer application
ID>
Definition: identical to ORC-2-placer order number.
The first component is a string of up to 15 characters that identifies an
individual order segment (e.g., OBR). It is assigned by the placer (ordering
application). It identifies an order uniquely among all orders from a
particular ordering application. The application ID is a string of up to six
(6) characters that will be uniquely associated with an application. A given
institution or group of intercommunicating institutions should establish a
unique list of applications that may be potential placers and fillers and
assign unique application ID's.
The second component contains the application ID of the placing application.
The two components are separated by a component delimiter.
Components: <unique filler ID> ^ <filler application
ID>
Definition: a permanent identifier for an order and its associated
observations.
The first component is a string that identifies an individual order segment
(e.g., OBR). It is assigned by the order filling (receiving) application. It
identifies an order uniquely among all orders from a particular filling
application (e.g., clinical laboratory).
The second component is the filler application ID.
OBR-3-filler order number is identical to ORC-3-filler order
number.
Components: <identifier> ^ <text> ^ <name of coding
system>^<alternate identifier> ^ <alternate text> ^ <name of
alternate coding system>
Definition: identifier code for the requested observation/test/battery. This
can be based on local and/or "universal" codes. We recommend the "universal"
procedure identifier. The structure of this CE data type is described in the
control section.
Definition: not used. Previously priority (e.g., STAT, ASAP), but that
information is carried as the sixth component of OBR-27-quantity/timing.
Definition: not used. Previously requested date/time. That information is
now carried in the 4th component of the OBR-27-quantity/timing.
Definition: clinically relevant date/time of the observation. In the case of
observations taken directly from a subject, it is the actual date and time the
observation was obtained. In the case of a specimen-associated study, this
field shall represent the date and time the specimen was collected or obtained.
(This is a results-only field except when the placer or a third-party has
already drawn the specimen.)
Definition: end date and time of a study or timed specimen collection. If an
observation takes place over a substantial period of time, it will indicate
when the observation period ended. For observations made at a point in time,
it will be null. This is a results field except when the placer or a party
other than the filler has already drawn the specimen.
Components: <quantity> ^ <units>
Definition: for laboratory tests, the volume of a specimen. The default unit
is ML. Specifically, units should be expressed in the ISO Standard unit
abbreviations (ISO-2955,1977). This is a results-only field except when the
placer or a party has already drawn the specimen. (See Chapter 7 for full
details about units.)
Components: <ID number> ^ <family name> ^ <given name>
^ <middle initial or name> ^ <suffix (e.g., JR or III)> ^
<prefix (e.g., DR)> ^ <degree (e.g., MD)> ^ <source
table>
Definition: when a specimen is required for the study, this field will
identify the person, department, or facility that collected the specimen.
Either name or ID code, or both, may be present.
Definition: action to be taken with respect to the specimens that accompany
or precede this order. The purpose of this field is to further qualify (when
appropriate) the general action indicated by the order control code contained
in the accompanying ORC segment. For example, when a new order (ORC - "NW") is
sent to the lab, this field would be used to tell the lab whether or not to
collect the specimen ("L" or "O"). Refer to table 0065 - action code
for valid entries.
Table 0065 Specimen action code
Value |
Description |
|---|---|
A |
Add
ordered tests to the existing specimen |
Components: <identifier> ^ <text> ^ <name of coding
system>^<alternate identifier> ^ <alternate text> ^ <name of
alternate coding system>
Definition: code and/or text indicating any known or suspected patient or
specimen hazards, e.g., patient with active tuberculosis or blood from a
hepatitis patient. Either code and/or text may be absent. However, the code
is always placed in the first component position and any free text in the
second component. Thus, free text without a code must be preceded by a
component delimiter.
Definition: additional clinical information about the patient or specimen
will be provided here. This field is used to report the suspected diagnosis
and clinical findings on requests for interpreted diagnostic studies. Examples
include reporting the amount of inspired carbon dioxide for blood gasses, the
point in the menstrual cycle for cervical pap tests, and other conditions that
influence test interpretations. For some orders this information may be sent
on a more structured form as a series of OBX segments (see Chapter 7) that
immediately follow the order segment.
Definition: for observations requiring a specimen, the actual login time at
the diagnostic service.
Components: <specimen source name or code (CE)> ^ <additives
(TX)> ^ <freetext (TX)> ^ <body site (CE)> ^ <site modifier
(CE)>
Definition: site where the specimen should be obtained or where the service
should be performed.
The first component contains the specimen source name or code (as a CE data
type component). (Even in the case of observations whose name implies the
source, a source may be required, e.g., blood culture-heart blood.)
The second component should include additives to the specimen such as Heparin,
EDTA, or Oxlate, when applicable.
The third is a free text component describing the method of collection when
that information is a part of the order. When the method of collection is
logically an observation result, it should be included as a result segment.
The fourth component specifies the body site from which the specimen was
obtained, and the fifth is the site modifier. For example, the site could be
anticubital foss, and the site modifier "right." The components of the CE
data elements become subcomponents. Refer to table 0070 - source of
specimen for valid entries.
Code |
Name |
Code |
Name |
Code |
Name |
ABS |
Abcess |
IT |
Intubation
tube |
STON |
Stone
|
Components: <ID number> ^ <family name> ^ <given name>
^ <middle initial or name> ^ <suffix (e.g., JR or III)> ^
<prefix (e.g., DR)> ^ <degree (e.g., MD)> ^ <source
table>
Definition: identification of the provider who ordered the test. Either the
ID code or the name, or both, may be present. This is the same as
ORC-12-ordering provider.
Definition: telephone number for reporting a status or a result using the
Standard format with extension and/or beeper number when applicable.
Definition: user field #1. Text sent by the placer will be returned with the
results.
Definition: similar to placer field #1.
Definition: definable for any use by the filler (diagnostic service).
Definition: similar to filler field #1.
Definition: date/time results reported or status changed. This field is used
to indicate the date and time that the results are composed into a report and
released, or that a status, as defined in Order Status, is entered or changed.
(This is a results field only.) When other applications (such as office or
clinical database applications) query the laboratory application for
untransmitted results, the information in this field may be used to control
processing on the communications link. Usually, the ordering service would
want only those results for which the reporting date/time is greater than the
date/time the inquiring application last received results.
Components: <dollar amount> ^ <charge code>
Definition: charge to the ordering entity for the studies performed when
applicable. The first component is a dollar amount when known by the Filler.
The second is a charge code when known by the filler (results only).
Definition: section of the diagnostic service where the observation was
performed. If the study was performed by an outside service, the
identification of that service should be recorded here. Refer to table 0074
- diagnostic service section ID for valid entries.
Code |
Description |
Code |
Description |
AU |
Audiology |
OUS |
OB
Ultrasound |
Definition: status of results for this order. The status applies to ALL
results associated with the order. This field would typically be used in a
response to an order status query where the level of detail requested does not
include the OBX segments. This field can only be valued by the filler.
When the individual status of each result is necessary, OBX-11-observ
result status may be used. Refer to table 0123 - result status for
valid entries.
Value |
Description |
Value |
Description |
|---|---|---|---|
O |
Order
received; specimen not yet received |
R |
Results
stored; not yet verified |
Components: <OBX-3-observation identifier of parent result>
^ <OBX-4-sub-ID of parent result> ^ <OBX-5-observation
results from parent (CE)>
Definition: defined to make it available for other types of linkages (e.g.,
toxicology). This important information, together with the information in
OBR-29-parent number uniquely identifies the parent result's OBX segment
related to this order. The value of this OBX segment in the parent result is
the organism or chemical species about which this battery reports. E.g., if
the current battery is an antimicrobial sensitivity, the parent result's
identified OBX contains a result which identifies the organism on which the
sensitivities were run. This indirect linkage is preferred because the name of
the organism in the parent result may undergo several preliminary values prior
to finalization.
The third component may be used to record the name of the microorganism
identified by the parent result directly. The organism in this case should be
identified exactly as it is in the parent culture.
This field is present only when the parent result is identified by
OBR-29-parent number. (See Chapter 7 for more details about this
linkage.)
A second mode of conveying this information is to use a standard observation
result segment (OBX). If more than one organism is present, OBX-4-subID
is used to distinguish them. In this case, the first OBX with subID N will
contain a value identifying the Nth microorganism, and each additional OBX with
subID N will contain sensitivity values for a given antibiotic test on this
organism.
Components: <quantity> ^ <interval> ^ <duration> ^
<start date/time> ^ <end date/time> ^ <priority> ^
<condition> ^ <text> ^ <conjunction> ^ <order
sequencing>
Definition: information about how many services to perform at one service
time and how often the service times are repeated, and to fix duration of the
request. See Section 4.4.
Components: <ID number> ^ <family name> ^ <given name>
^ <middle initial or name> ^ <suffix (e.g., JR or III)> ^
<prefix (e.g., DR)> ^ <degree (e.g., MD)> ^ <source
table>
Definition: people who are to receive copies of the results. By local
convention, either the ID number or the name may be absent.
Components: <parent's placer order number> ^ <parent's filler
order number>
Definition: identical to ORC-8-parent. This field relates a child to
its parent when a parent-child relationship exists. For example, observations
that are spawned by previous observations, e.g., antibiotic susceptibilities
spawned by blood cultures, need to record the parent (blood culture) filler
order number here. The parent-child mechanism is described under the order
control field notes (see Segment ORC field notes in section 4.3.1.2.1). It is
required when the order is a child.
Parent is a two-component field. The first component contains the parent's
placer order number. The second component is optional and contains the
parent's filler order number. The components of the placer order number and
the filler order number are transmitted in subcomponents of the two components
of this field.
Definition: how (or whether) to transport a patient, when applicable. Refer
to table 0124 - transportation mode for valid codes.
Value |
Description |
|---|---|
CART |
Cart
- patient travels on cart or gurney |
Components: <identifier> ^ <text> ^ <name of coding
system>^<alternate identifier> ^ <alternate text> ^ <name of
alternate coding system>
Definition: code or text using the conventions for coded fields given in the
Control/Query Chapter (Chapter 2). This is required for some studies to obtain
proper reimbursement.
Components: <result interpreter (CN)> ^ <start date/time
(TS)> ^ <end date/time (TS)> ^ <location (CM)>
The first component is the result interpreter (CN): <ID number &
family name & given name & middle initial or name & suffix (e.g.,
JR or III) & prefix (e.g., DR) & degree (e.g., MD) & source
table>
Definition: identity of the physician or other clinician who interpreted the
observation and is responsible for the report content.
Components: <assistant result interpreter (CN)> ^ <start
date/time (TS)> ^ <end date/time (TS)> ^ <location (CM)>
The first component is the assistant result interpreter (CN): <ID number
& family name & given name & middle initial or name & suffix
(e.g., JR or III) & prefix (e.g., DR) & degree (e.g., MD) & source
table>
Definition: clinical observer who assisted with the interpretation of this
study.
Components: <technician (CN)> ^ <start date/time (TS)> ^
<end date/time (TS)> ^ <location (CM)>
The first component is the technician (CN): <ID number & family name
& given name & middle initial or name & suffix (e.g., JR or III)
& prefix (e.g., DR) & degree (e.g., MD) & source table>
Definition: performing technician.
Components: <transcriptionist (CN)> ^ <start date/time (TS)>
^ <end date/time (TS)> ^ <location (CM)>
The first component is the transcriptionist (CN): <ID number & family
name & given name & middle initial or name & suffix (e.g., JR or
III) & prefix (e.g., DR) & degree (e.g., MD) & source table>
Definition: report transcriber.
Definition: date/time the filler scheduled an observation, when applicable
(e.g., action code in OBR-11-specimen action code = "S"). This is a
result of a request to schedule a particular test and provides a way to inform
the Placer of the date/time a study is scheduled (result only).
The purpose of this section is to show how certain specific situations would
be handled using the order entry protocol. The ellipses represent uncompleted
details. The symbol // precedes comments for clarification.
Suppose that an application called "PC" is sending an order to the EKG
application for three EKGs to be done on successive days.
The order might be placed as follows:
ORM message:
MSH|...
PID|...
ORC|NW|A226677^PC||946281^PC|||N|3^QAM||198801121132|P123^AQITANE^ELLINORE^""^""^""^MD|||4EAST<CR>
// EKG order
OBR||||93000^EKG
REPORT||||||||||||P030^SMITH^MARTIN^""^""^""^MD|||||||||||3^QAM<CR>
BLG|...
ORC||... // Another order yet others may follow
There is a group number first component indicating that an order group is
being created.
Responses: Because the EKG application must turn the single order above into
three orders for three separate EKGs (services), the results of each will be
reported under its own OBR segment. Several response levels are possible
depending on the Response Flag:
a) If the Response Flag is N (as it is), then the filler EKG application only
responds "I got the order."
MSH|...
MSA|...
The only implication of this response is that the order was received.
If the Response Flag had been E, then the response would have been the same,
but its implication would have been that the EKG application had processed all
the orders and they were acceptable.
b) If the Response Flag were R, then the filler EKG application must
communicate to the PC the fact of the creation of child orders, but with no
details:
MSH|...
MSA|...
ORC|PA|A226677^PC|89-458^EKG|94628^PC<CR>
ORC|CH|A226677^PC|89-551^EKG|94628... // 1ST child ORC.
ORC|CH|A226677^PC|89-552^EKG|94628... // 2ND child ORC.
ORC|CH|A226677^PC|89-553^EKG|94628... // 3RD child ORC.
... // Other parts of response
might follow.
What has been said here is "Your A226767 has spun out three children named
89-551, 89-552, and 89-553." Notice that the placer Numbers are identical in
the children's ORCs.
c) If the Response Flag were D, then the filler EKG application must
communicate to the PC application the fact of the replacement and also the
exact replacement order segments:
MSH|...
MSA|...
ORC|PA|A226677^PC|89-458^EKG<CR>
ORC|CH|A226677^PC|89-551^EKG|946282^PC|SC|A226677&PC^89-458&EKG|
... ^^^^198901130500^<CR> // 1ST child
ORC
OBR|||89-551^EKG|93000^EKG REPORT|... //
1ST child OBR
ORC|CH|A226677^PC|89-522^EKG|946282^PC|SC|A226677&PC^89-458&EKG|
... ^^^^198901140500^<CR> // 2ND child
ORC
OBR|||89-552^EKG|93000^EKG REPORT|... //
2ND child OBR
ORC|CH|A226677^PC|89-553^EKG|946282^PC|SC|A226677&PC^89-458&EKG|
...^^^^198901150500^<CR>
// 3RD child ORC
OBR|||89-553^EKG|93000^EKG REPORT|... //
3RD child OBR
// Other parts
might follow
Here the actual OBR segments have been added.
The status of the child orders is being reported as SC (scheduled).
ORC-4-quantity/timing shows that the EKGs are requested after 0500 on
successive days.
A diet office needs to receive specific information, the most important being
the diet order itself. Diet restrictions (often called diet codes) are the
basic building blocks of a diet order.
ORM Dietary Order Chapter
MSH Message Header 2
[{NTE}] Notes and Comments (for Header) 2
[
PID Patient Identification 3
[{NTE}] Notes and Comments (for Patient ID) 2
[{AL1}] Allergy 3
[PV1] Patient Visit Information 3
]
{
ORC Common Order Segment 4
[
{ODS} Dietary Orders, Suppl., Prefer. 4
[{NTE}] Notes and Comments (for ODS) 2
{OBX Results 7
[{NTE}]} Notes and Comments (for OBX) 2
]
}
{
[
ORC Common Order Segment 4
{ODT} Diet Tray Instructions 4
[{NTE}] Notes and Comments (for ODT) 2
]
}
ORR General Order Acknowledgement Message Chapter
MSH Message Header 2
MSA Message Acknowledgement 2
[ERR] Error 2
[{NTE}] Notes and Comments (for MSA) 2
[
[PID Patient Identification 3
[{NTE}]] Notes and Comments (for Patient ID) 2
{
ORC Common Order 4
[{ODS}] Dietary orders, supplements, and preferences 4
[{NTE}] Notes and Comments (for ODS) 2
}
[
{
ORC Common Order 4
[{ODT}] Diet tray instructions 4
[{NTE}] Notes and Comments (for ODT) 2
}
]
]
The ODS segment is intended to cover the basic diet definition of one diet
code. A diet can be ordered as a combination of one or more diet
specifications, followed by any number of supplements and/or preferences. Many
diets are common to all institutions, such as an ADA 1500 calorie diet, and may
exist in a table. Each diet code is limited to a six-character
abbreviation.
A dietary message never specifies more than one diet. However, a single diet
order may be used to discontinue one diet and specify its replacement. In this
instance, the dietary message will contain two ORCs. The first ORC will not
contain an ODT. A tray specification order may follow the second ORC.
Often a complete diet order consists of a single diet code. The diet code
defines which foods a patient may receive. In cases where a patient cannot
make food selections, a diet code often causes service of a predefined set of
foods. A patient must have at least one diet code to receive food.
Supplements provide a mechanism for giving any additional desired foods to a
patient. Supplements are foods given to a patient regardless of their diet
codes. These foods are part of the patient's diet without being restricted by
any other part of the order. Therefore, supplement assignment needs to be a
controlled and supervised process to ensure that a patient does not receive
improper or potentially harmful foods.
Preferences consist of likes, dislikes, substitutions, and complementary
foods. Preferences are diet orders, effectively from the patient, but
transmitted from the ward. They are subject to change. A mechanism is
included for defining patient preferences with this proposal. Preferences are
independent of the diet order and do not change when the order changes.
However, if a preference violates the conditions of the diet order, then that
preference is not allowed.
There is additional information that the dietary service requires for proper
operation, including tray delivery times, extra trays, and messages regarding
tray delivery and handling.
A patient can have only one effective diet order at a time. A diet order
consists of the diet codes, supplements, and preferences effective at a given
time. These three specifications govern which foods a patient will receive.
Diets generally do not have a stated ending time to ensure that the patient
always receives food (unless an NPO order is received).
Diet codes govern foods in two ways. First, there are foods which are simply
not allowed on a specified diet. Second, some diets imply a nutrient exchange
pattern which controls the amounts of certain foods that a patient can receive.
Some diet codes can combine to make a single diet order. An ADA 1500 and a 2
gram sodium (NA2GM) diet can coexist since they do not address the same
exchanges. The patterns for these diets can combine without conflicting or
overlapping. Certain kinds of diet codes cannot be combined, such as ADA 1500
and ADA 2000. It is impossible to feed a patient at two different calorie
levels. These constraints are not defined in the table, but rather are implied
by the semantics of the codes.
An order specifies the complete foods a patient can or should receive at a
given meal. (Depending on the institution and diet order, a patient may or may
not have a choice of foods. For example, a clear liquid diet often gives no
choices since there are few clear liquid foods.) A modification to a diet, by
adding a diet code or supplement, may have a drastic effect on foods the
patient may eat. Due to this, any modification to the diet codes or
supplements will be a new order. Therefore, one must send any information for
diet codes or supplements from the previous order which is still applicable for
the next order. For example, a patient has an ADA 1500 calorie diet and an
evening snack of Skim Milk. If you wanted to add a 2 gram sodium restriction,
you need to send both the ADA 1500 calorie and the 2 gram sodium diet codes
along with the Skim Milk supplement. If you do not do this, the dietary
application must presume the new order is merely for 2 grams of sodium. This
method allows for a comprehensive audit trail of orders and prevents
ambiguities in interpretation.
The ORC sequence items of interest to ODS are ORC-1-order
control,ORC-2-placer order number, ORC-3-filler order number,
ORC-7-quantity/timing, ORC-9-date/time of transaction, ORC-10-entered by, and
ORC-11-verified by. For ORC-1-order control, the values may be New
(NW), Cancel (CA), Discontinue Order Request (DC), Change (XO), Hold Order
Request (HD), and Release Previous Hold (RL). The HD and RL codes could stop
service for a specified length of time. ORC-4-quantity/timing should be
used to specify whether an order is continuous or for one service period only.
It is also useful for supplements which are part of a diet but only delivered,
say, every day at night. Example:
|1^QPM^^19910415|.
SEQ |
LEN |
DT |
R/O |
RP/ # |
TBL # |
ITEM # |
ELEMENT NAME |
1 |
1 |
ID |
R |
|
0159 |
00269 |
Type
|
4.6.1.0 ODS field definitions
Definition: specifies type of diet. Refer to table 0159-diet type for
valid entries.
Value |
Description |
D |
Diet |
Components: <identifier> ^ <text> ^ <name of coding
system>^<alternate identifier> ^ <alternate text> ^ <name of
alternate coding system>
Definition: when blank, the modifier applies to all service periods. Diet
orders, for example, typically apply to all service periods. This field
usually specifies supplements. This field allows you to designate a
modification for one or more of the service periods during a day by combining
service specifications as needed. The service periods will be local CEs,
normally numbers. Suggested are:
service 1 is breakfast
service 2 is mid-a.m. snack
service 3 is lunch
service 4 is mid-afternoon snack
service 5 is dinner
service 6 is bedtime snack
Ex: |1~5| means service 1 and service 5, whatever these are locally defined to
be.
Components: <identifier> ^ <text> ^ <name of coding
system>^<alternate identifier> ^ <alternate text> ^ <name of
alternate coding system>
Definition: identifier of the ordered item for a patient; it is equivalent to
OBR-4-universal service ID in function. Since ODS is a repeating
segment, multiple entities get multiple segments. Example:
|^REG^L&FD7|, |023^^L&FD6|, |^NOLACT^L&FD5|,
|^TUBEFD^L&FD4|, and |011^HIPRO100^L&FD1~123^LOFAT20^L&FD1|
In the case where this segment requests a diet supplement, i.e.,
ODS-1-type = S, this attribute specifies a particular item or class of
items. If institutional codes for patient food preferences (P) have been
codified, they are also expressed as coded segments; otherwise, the information
is passed as a text string in the fourth component of the ODS segment,
described below.
Definition: specific instructions for dietary. These instructions may
address specific patient needs, such as isolation. This field provides the
ordering provider's dietary instructions as free text. It can represent the
full dietary instruction or indicate supplemental information.
This segment addresses tray instructions. These are independent of diet
codes, supplements, and preferences and therefore get separate order
numbers.
SEQ |
LEN |
DT |
R/O |
RP/ # |
TBL # |
ITEM # |
ELEMENT NAME |
1 |
60 |
CE |
R |
|
0160 |
00273 |
Tray
Type |
4.6.2.0 ODT field definitions
Components: <identifier> ^ <text> ^ <name of coding
system>^<alternate identifier> ^ <alternate text> ^ <name of
alternate coding system>
Definition: defines the type of dietary tray. Refer to table 0160 - tray
type for valid entries.
Table 0160 Tray type
Value |
Description |
EARLY |
Early
tray |
Tray specifications are useful for early and late tray delivery in cases where
a patient undergoes a procedure during normal feeding times. Tray
specifications can also be used for guest trays, no trays, and messages. The
value MSG means the ODT segment does not specify the type of tray but provides
additional information about an existing tray. This information is found in
ODT-3-text instructions.
Components: <identifier> ^ <text> ^ <name of coding
system>^<alternate identifier> ^ <alternate text> ^ <name of
alternate coding system>
Definition: when blank, the modifier applies to all service periods. This
field allows you to designate one or more of the feeding periods during a day
by combining the codes as needed. It can also combine with quantity/timing to
give such information as which service period the order belongs with. This
field is identical in meaning with ODS-2-service period. See section
4.6.1.2 for further details.
Definition: instructions associated with the tray. Example:
|PLASTIC SILVERWARE|.
First order:
MSH|...<cr>
PID|...<cr>
ORC|NW|1235^NURS|||||^^^199108021700||199108021200|^HRF|^MFW|<cr>
ODS|D||^DB15^L&DO3|<cr>
ODS|D||^NA2GM^L&DO3|<cr>
Hold first order:
MSH|...<cr>
PID|...<cr>
ORC|HL|1235^NURS|||||^^^199108031700||199108031200|^HRF|^MFW|<cr>
NPO order with guest tray:
MSH|...<cr>
PID|...<cr>
ORC|NW|1236^NURS|||||^^^199108031700||199108031200|^HRF|^MFW|<cr>
ODS|D||^NPO^L&DO3|<cr>
ORC|NW|1244^NURS|||||^^^199108031700||199108031200|^HRF|^MFW|<cr>
ODT|GUEST|5^^L&CBD|<cr>
Clear liquid with guest tray:
MSH|...<cr>
PID|...<cr>
ORC|DC|1236^NURS|||||^^^199108041700||199108041200|^HRF|^MFW|<cr>
ORC|NW|1237^NURS|||||^^^199108041700||199108041200|^HRF|^MFW|<cr>
ODS|D||^DB15^L&DO3|<cr>
ODS|D||^NA2GM^L&DO3|<cr>
ODS|D||^CLRLIQ^L&DO3|<cr>
ORC|NW|1245^NURS|||||^^^199108041700||199108041200|^HRF|^MFW|<cr>
ODT|GUEST|5^^L&CBD|<cr>
Full liquid with guest tray:
MSH|...<cr>
PID|...<cr>
ORC|DC|1237^NURS|||||^^^199108051700||199108051200|^HRF|^MFW|<cr>
ORC|NW|1238^NURS|||||^^^199108051700||199108051200|^HRF|^MFW|<cr>
ODS|D||^DB15^L&DO3|<cr>
ODS|D||^NA2GM^L&DO3|<cr>
ODS|D||^FULLIQ^L&DO3|<cr>
ORC|NW|1246^NURS|||||^^^199108051700||199108051200|^HRF|^MFW|<cr>
ODT|GUEST|3^^L&CBD|<cr>
Release hold on previous order and give discharge message:
MSH|...<cr>
PID|...<cr>
ORC|DC|1238^NURS|||||^^^199108061700||199108061200|^HRF|^MFW|<cr>
ORC|RL|1235^NURS|||||^^^199108061700||199108061200|^HRF|^MFW|<cr>
ORC|NW|1247^NURS|||||^^^199108061700||199108061200|^HRF|^MFW|<cr>
ODT|MSG|5^^L&CBD|You Will Be Leaving Tomorrow|<cr>
Basic diet: high protein, low fat. Supplements are ice cream at service
period 4 and a half ham sandwich at service period 6. There are also tray
orders for early service period 1, late service period 3, and guest tray at
dinner.
MSH|...<cr>
PID|...<cr>
ORC|NW|1234^NURS|||||^^^199108021700||199108021200|^HRF|^MFW|<cr>
ODS|D||011^HIPRO100^L&FD1|<cr>
ODS|D||123^LOFAT20^L&FD1|<cr>
ODS|S|4|119^ICE CREAM^L&FD8|<cr>
ODS|S|6|320^1/2 HAM SANDWICH^L&FD8|<cr>
ORC|NW|1244^NURS|||||^^^199108031700||199108031200|^HRF|^MFW|<cr>
ODT|EARLY|1^^L&CBD|<cr>
ORC|NW|1245^NURS|||||^^^199108031700||199108031200|^HRF|^MFW|<cr>
ODT|LATE|3^^L&CBD|<cr>
ORC|NW|1246^NURS|||||^^^199108031700||199108031200|^HRF|^MFW|<cr>
ODT|GUEST|^DINNER^L&CBD|<cr>
This order specifies Similac with MCT oil and polycose additives.
MSH|...<cr>
PID|...<cr>
ORC|NW|1232^NURS|||||60^Q3H^^199108021700||199108021200|^HRF|^MFW|<cr>
ODS|D||010^SIMILAC^L&DO1|<cr>
ODS|D||011^MCT^L&DO1|<cr>
ODS|D||012^POLYCOSE^L&DO1|<cr>
This order specifies that the patient is a vegetarian.
MSH|...<cr>
PID|...<cr>
ORC|NW|1232^NURS|||||60^Q3H^^199108021700||199108021200|^HRF|^MFW|<cr>
ODS|D||123^LOFAT20^L&FD1|<cr>
ODS|S|4|119^ICE CREAM^L&FD8|<cr>
ODS|P||^^^VEGETARIAN|<cr>
The Requisition Detail segment (RQD) is used for ordering medical, surgical ,
and patient care supplies. It is assumed that these supplies are managed by a
materials management application, which contains a Master List of all items the
hospital uses.
There are basically two types of supplies, commonly referred to as stock and
nonstock.
Stock supplies are, as the name suggests, stocked in the hospital in designated
areas, such as the warehouse, Central Supply, Nursing floors, or Operating
Room.
When requisitioning stock supplies, the requesting application need only
specify the information in the RQD segment. It is assumed that this is enough
information for the application receiving to identify the item. If the sending
application is not aware whether the supply is stock, it may optionally send an
RQ1 along with the RQD. Typically in that case, the item is requested with a
free text description.
Nonstock supplies are not stocked anywhere in the hospital and must be ordered
from an industry distributor or manufacturer.
When the requesting application knows that it is requisitioning nonstock
supplies, it may also send an RQ1 segment with the RQD if at least one field in
RQ1 is known to the sending application. This may be necessary in order for
the receiving application to properly determine where to get these supplies.
This depends on the sophistication of the database of the receiving
application, which may contain a history of requisitions from the sending
application.
Stock requisition orders use the ORM. RQD replaces the Order Detail Segment of
the ORM message as follows:
ORM Stock Requisition Order Message Chapter
MSH Message Header 2
[{NTE}] Notes and Comments (for Header) 2
[
PID Patient Identification 3
[{NTE}] Notes and Comments (for Patient ID) 2
[{AL1}] Allergy 3
[PV1] Patient Visit 3
]
{
ORC Common Order 4
[
RQD Requisition Detail 4
[{NTE}] Notes and Comments (for RQD) 2
[
{
OBX Observation/Result 7
[{NTE}] Notes and Comments (for OBX) 2
}
]
]
[BLG] Billing segment 4
}
ORR General Order Acknowledgement Message Chapter
MSH Message Header 2
MSA Message Acknowledgement 2
[ERR] Error 2
[{NTE}] Notes and Comments (for Header) 2
[
[PID Patient Identification 3
[{NTE}]] Notes and Comments (for Patient ID) 2
{
ORC Common Order 4
RQD Requisition Detail 4
[{NTE}] Notes and Comments (for RQD) 2
}
]
Nonstock requisitions use the ORM. RQD followed by RQ1 replaces the Order
Detail Segment of the ORM message as follows:
ORM Nonstock Requisition Order Message Chapter
MSH Message Header 2
[{NTE}] Notes and Comments (for Header) 2
[
PID Patient Identification 3
[{NTE}] Notes and Comments (for Patient ID) 2
[{AL1}] Allergy 3
[PV1] Patient Visit 3
]
{
ORC Common Order 4
[
RQD Requisition Detail 4
[RQ1] Requisition Detail-1 4
[{NTE}] Notes and Comments (for RQD) 2
[
{
OBX Observation/Result 7
[{NTE}] Notes and Comments (for OBX) 2
}
]
]
[BLG] Billing segment 4
ORR General Order Acknowledgement Message Chapter
MSH Message Header 2
MSA Message Acknowledgement 2
[ERR] Error 2
[{NTE}] Notes and Comments (for Header) 2
[
[PID Patient Identification 3
[{NTE}] Notes and Comments (for Patient ID) 2
]
{
ORC Common Order 4
RQD Requisition Detail 4
[RQ1] Requisition Detail-1 4
[{NTE}] Notes and Comments (for RQD) 2
}
]
RQD contains the detail for each requisitioned item. See assumptions
above.
SEQ |
LEN |
DT |
R/O |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
1 |
4 |
SI |
00275 |
Requisition
Line Number |
4.7.1.0 RQD field definitions
Definition: number that identifies this line in the requisition.
Components: <identifier> ^ <text> ^ <name of coding
system>^<alternate identifier> ^ <alternate text> ^ <name of
alternate coding system>
Definition: identifier and description that uniquely identify the item on the
application sending the requisition.
Components: <identifier> ^ <text> ^ <name of coding
system>^<alternate identifier> ^ <alternate text> ^ <name of
alternate coding system>
Definition: identifier and description that uniquely identify the item on the
application receiving the requisition.
Components: <identifier> ^ <text> ^ <name of coding
system>^<alternate identifier> ^ <alternate text> ^ <name of
alternate coding system>
Definition: identifier and description that uniquely identify the item on all
applications in the hospital. The identifier is usually controlled by the
hospital Financial application in the Charge Description Master file.
Note: at least one of the three fields 4.7.1.2 thru 4.7.1.4 must be non-null. |
Definition: quantity requisitioned for this item.
Components: <identifier> ^ <text> ^ <name of coding
system>^<alternate identifier> ^ <alternate text> ^ <name of
alternate coding system>
Definition: unit of measure for this item.
Definition: accounting code that identifies this department in order to
charge for this item.
Definition: accounting code that identifies this item in order to charge for
this item.
Components: <identifier> ^ <text> ^ <name of coding
system> ^ <alternate identifier> ^ <alternate text> ^ <name
of alternate coding system>
Definition: unique identifier and descriptive name of the department/location
where the item should be delivered.
Definition: date this item is required.
Note: Although none of the fields are required, one of the three identifying codes--Item Code - Internal, Item Code - External, or Hospital Item Code--must be specified in order for the receiving application to process the request. |
It is left to the vendors to determine which will be used as the common link
between the two applications. HL7 recommends using the RQD-4-hospital item
code.
Hospital accounting requires an identifier to charge a particular cost center
or patient for a requisitioned supply. If the supply is for a patient, then
this identifier comes from the PID segment; otherwise, from RQD-7-dept. cost
center and RQD-8-item natural account code must be used. It is
recommended that the "final" cost center responsible for providing the supply
to the patient be included, even when the patient ID is provided.
Hospital accounting applications use RQD-7-dept. cost center
concatenated with RQD-8-item natural account code in order to post this
transaction to the General Ledger. This concatenated value should correspond
to a valid entry in the accounting applications "Chart of Accounts."
RQ1 contains additional detail for each nonstock requisitioned item. This
segment definition is paired with a preceeding RQD segment.
SEQ |
LEN |
DT |
R/O |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
1 |
10 |
ST |
|
00285 |
Anticipated
Price |
4.7.2.0 RQ1 field definitions
Definition: reference price for the requisition unit of measure that is known
to the Requisition application. It may or may not be the actual cost of
acquiring the item from a supplier. It is also not the price charged to the
patient.
Components: <identifier> ^ <manufacturer's name (text)> ^
<name of coding system> ^ <alternate identifier> ^ <alternate
text> ^ <name of alternate coding system>
Definition: unique code that identifies the manufacturer on the application
receiving the requisition.
Codes may be selected from HIBCC Manufacturer's Labeler ID Code (LIC), the UPC
or the NDC. These code sets may be obtained from the appropriate organization
whose addresses are included in Figure 2-3 (Section 2.4.5.17).
Definition: manufacturer's catalog number or code for this item.
Components: <identifier> ^ <vendor name (text)> ^ <name of
coding system> ^ <alternate identifier> ^ <alternate text> ^
<name of alternate coding system>
Definition: unique code that identifies the vendor on the application
receiving the requisition.
Because of this, it is recommended that each nonstock item have
RQ1-2-manufacturer's ID and RQ1-3-manufacturer's catalog, or
RQ1-4-vendor ID and RQ1-5-vendor catalog. It is also possible
that the requisitioning application will not know the identifier, as listed in
the Manufacturer's or Vendor's catalog. In this case, it is important to
include the name portion of this coded element field.
Definition: vendor's catalog number, name, or code for this item.
Definition: is this item subject to tax?
In general, nonstock requisitioned items will be printed by the receiving
application and then processed by a human. In other words, the human will use
the information to call the vendor or manufacturer to get pricing and other
related purchasing information before placing the order with an outside vendor.
Refer to table 0136 - Y/N indicator as defined in Chapter 2.
Definition: indicates whether the ancillary department may substitute an
equivalent version of the item(s) ordered. Refer to table 0136 - Y/N
indicator as defined in Chapter 2.
a) The first example is a requisition from the ORSUPPLY application to the
MMSUPPLY application for two items for patient John J. Smith. One item is a
stock item for an IV Solution and the second item is a nonstock implant
manufactured by Detter. The requisition number used by the ORSUPPLY
application is RQ101.
MSH|^~\&|ORSUPPLY|ORSYS|MMSUPPLY|MMSYS|19911105131523||ORM|100|P|2.2||<cr>
PID|||100928782^9^MOD11|3781928|Smith^John^J||19690424|M|||||||||A|
...100928782^4^MOD11||<cr>
ORC|NW|RQ101^ORSUPPLY||||N|||19911105130000|jjones^Jones^Jean|sgomez^Gomez^Susan|
...|MAINOR^2W|X2304<cr>
RQD|1|1234^Solution, 2.25% Saline||S1786^Saline
Solution|1|BT^Bottle|1234-5678|
...ORSUP^Main OR Supply Room|19901123<cr>
RQD|2|23455^Implant, Special Hip||I45323^Implant|1|EA^
Each|1234-5678|
...ORSUP^Main OR Supply Room|19901123<cr>
RQ1|123.45|DET^Detter, Inc.|444456|DST^Local Distributors,
Inc.|333-456|N<cr>
b) The second example is a requisition from the ORSUPPLY application to the
MMSUPPLY application for five stock items to replenish a supply closet. The
requisition number used by the ORSUPPLY application is RQ102.
MSH|^~\&|ORSUPPLY|ORSYS|MMSUPPLY|MMSYS|19911105152034||ORM|100|P|2.2||<cr>
ORC|NW|RQ102^ORSUPPLY||||N|||19911105150100|jjones^Jones^Jean|sgomez^Gomez^Susan|
...|MAINOR^2W|X2304<cr>
RQD|1|1232^Solution, 1% Saline||S1784^Saline
Solution|5|BT^Bottle|1234-5678|
...ORSUP^Main OR Supply Room|19901105<cr>
RQD|2|1231^Solution, 0.2% Saline||S1781^Saline
Solution|2|BT^Bottle|1234-5678|
...ORSUP^Main OR Supply Room|19901105<cr>
RQD|3|2342^Suture, Black Silk||SU123^Suture|2|DZ^Dozen|1234-5678|
...ORSUP^Main OR Supply Room|19901105<cr>
RQD|4|2344^Suture, Black Silk
3-0||SU124^Suture|1|DZ^Dozen|1234-5678|
...ORSUP^Main OR Supply Room|19901105<cr>
RQD|5|4565^Bandage Pad, 4x4||B6345^Bandage Pad|3|BX^Box|1234-5678|
...ORSUP^Main
ORM Pharmacy Prescription Message Chapter
MSH Message Header 2
[{NTE}] Notes and Comments (for Header) 2
[
PID Patient Identification 3
[{NTE}] Notes and Comments (for Patient ID) 2
[{AL1}] Allergy 2
[PV1] Patient Visit 3
]
{
ORC Common Order 4
[
RXO Pharmacy Prescription 4
[{NTE}] Notes and Comments (for RXO) 2
{RXR} Pharmacy Route 4
[
{RXC} Pharmacy Component 4
[{NTE}] Notes and Comments (for RXC) 2
]
[
{
OBX Observation/Result 7
[{NTE}] Notes and Comments (for OBX) 2
}
]
]
[BLG] Billing Segment 6
}
ORR message for pharmacy:
ORR Description Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ERR] Error 2
[{NTE}] Notes and Comments (for Response Header) 2
[
[PID Patient Identification 3
[{NTE}]] Notes and Comments (for Patient ID) 2
{
ORC Common Order 4
[
RXO Pharmacy Prescription 4
[{NTE}] Notes and Comments (for RXO) 2
{RXR} Pharmacy Route 4
[{RXC}] Pharmacy Component 4
[{NTE}] Notes and Comments (for RXC) 2
]
}
]
This is the "master" pharmacy order segment. It contains order data not
specific to components or additives. Unlike the OBR, it does not contain
status fields or other data that are results-only.
It can be used for any type of pharmacy order, including inpatient (unit dose
and compound unit dose), outpatient, IVs, and hyperalimentation IVs
(nutritional IVs).
In addition to the pharmaceutical information, this segment contains
additional data such as provider and text comments.
A quantity/timing field is not needed in the RXO segment. The ORC segment
contains the requested ORC-7-quantity/timing of the original order which
does not change as the order is encoded, dispensed, or administered.
SEQ |
LEN |
DT |
R/O |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
1 |
100 |
CE |
R |
|
|
00292 |
Requested
Give Code |
4.8.2.0 RXO field definitions
Components: <identifier> ^ <text> ^ <name of coding
system> ^ <alternate identifier> ^ <alternate text> ^ <name
of alternate coding system>
Definition: identifier of the medical substance ordered to be given to the
patient; it is equivalent to OBR-4-universal service ID code in
function. The request-to-dispense fields, which define the type and amount of
what is to be issued to the patient (see RXO-10 requested dispense code,
RXO-11-requested dispense amount, and RXO-12-requested dispense
units) do not necessarily correlate with the instructions of what amount is
to be "given" or administered with each dose, and may or may not be specified
with the order. For example, the "give" part of the order may convey the
field-representation of give 15 mg of librium every 6 hours, while the
request to dispense part of the order may convey issue 30 tablets of 10 MG
generic equivalent for this outpatient prescription. When the give code
does not include the dosage form, use RXO-5-requested dosage form.
Definition: ordered amount. In a variable dose order, this is the minimum
ordered amount. In a nonvarying dose order, this is the exact amount of the
order.
Note:
This field is not a duplication of the first component of the quantity/timing
field, since in non-Pharmacy orders, that component can be used to specify
multiples of an ordered amount. |
Definition: in a variable dose order, this is the maximum ordered amount. In
a nonvarying dose order, this field is not used.
Components: <identifier> ^ <text> ^ <name of coding
system> ^ <alternate identifier> ^ <alternate text> ^ <name
of alternate coding system>
Definition: units for the give amount.
Note: These units can be a "compound quantity"; i.e., the units may contain the word "per." For example, micrograms per KG (micg/kg) is an acceptable value, which means that the units are micrograms per KG (of body weight). See Chapter 7 for full definition of ISO+ units. |
A table of standard units is needed to define standard abbreviations for
compound units. Until such a table is agreed on, a user-defined table is
needed for each site. If the interpretation of a compound unit requires
knowledge of some observation results (such as body weight or height), these
results can be sent in the same order message using the optional OBX segments.
Components: <identifier> ^ <text> ^ <name of coding
system> ^ <alternate identifier> ^ <alternate text> ^ <name
of alternate coding system>
Definition: use when both RXO-1-requested give code and
RXO-10-requested dispense code do not specify the drug form.
Definition: ordering provider's instructions to the pharmacy as a free text
field.
Definition: ordering provider's instructions to the patient or to the
provider administering the drug as a free text field.
Components: <nurse unit & room & bed & facility ID &
bed status> ^ <street address & other designation & city &
state or province & zip or postal code & country & type & other
geographic designation>
Definition: the first component contains the inpatient or outpatient location
to which the pharmacy is to deliver the drug (if applicable). The default
(null) value is the current census location for the patient. Site specific
table. This component has the same form as PV1-3-assigned patient
location.
The second component can be used to specify an address. This could be used to
fill mail orders to a patient or provider, or to account for home health care.
Definition: values are the following:
Value |
Description |
N |
Substitutions
are NOT authorized. (This is the default - null.) |
Note on request-to-dispense fields:
Sometimes an order will be written in which the total amount of the drug
requested to be dispensed has no direct relationship with the give amounts and
schedule. For example, an outpatient pharmacy order might be take four
pills a day of <drug name, value>, Q6H (every 6 hours) -- dispense 30
tablets. An inpatient order might be NS/D5W (normal saline with 5%
dextrose) at 1000cc/hour -- dispense 3 1-liter bottles of NSD5W solution.
The request-to-dispense fields support this common style of ordering.
Components: <identifier> ^ <text> ^ <name of coding
system>^<alternate identifier> ^ <alternate text> ^ <name of
alternate coding system>
Definition: what is to be/was dispensed; it is equivalent to
OBR-4-universal service ID in function. It may be present in the order
or not, depending on the application. If not present, and values are given for
RXO-11-requested dispense amount and RXO-12-requested dispense
units, the RXO-1-requested give code is assumed. If the requested
dispense code does not include the dosage form, use RXO-5-requested dosage
form.
Definition: amount to be dispensed.
Components: <identifier> ^ <text> ^ <name of coding
system> ^ <alternate identifier> ^ <alternate text> ^ <name
of alternate coding system>
Definition: units for the dispense amount. This must be in simple units that
reflect the actual quantity of the substance to be dispensed. It does not
include compound units.
Definition: outpatient only.
Components: <ID number> ^ <family name> ^ <given name>
^ <middle initial or name> ^ <suffix (e.g., JR or III)> ^
<prefix (e.g., DR)> ^ <degree (e.g., MD)> ^ <source
table>
Definition: if required by site.
Components: <ID number> ^ <family name> ^ <given name>
^ <middle initial or name> ^ <suffix (e.g., JR or III)> ^
<prefix (e.g., DR)> ^ <degree (e.g., MD)> ^ <source
table>
Definition: provider ID of pharmacist verifier. Use if required by the
Pharmacy application or site on orders (or some subgroup of orders), in
addition to ORC-11-verified by.
Example:
The site requires a "verified by" provider (such as a nurse) and a "verifying
pharmacist" on the order. In this case the first field, ORC-11-verified
by, is already present; but the second field, RXO-15-pharmacist verifier
ID, is needed.
Definition: uses table 0136 - Y/N indicator. The values have the
following meaning for this field:
Value |
Description |
Y |
Yes
- Indicates that the pharmacist filling the order needs to pay special
attention to the text in the RXO-6-provider's pharmacy instructions. A
warning is present. |
An example of the use of this field is given by the following case:
A smart Order Entry application knows of a possible drug interaction on
a certain order, but the provider issuing the order wants to override the
condition. In this case, the Pharmacy application receiving the order will
want to have a staff pharmacist review the interaction and contact the ordering
physician.
Definition: time unit to use to calculate the rate at which the
pharmaceutical is to be administered.
Format:
S<integer> = <integer> seconds
M<integer> = <integer> minutes
H<integer> = <integer> hours
D<integer> = <integer> days
W<integer> = <integer> weeks
L<integer> = <integer> months
Note: This is the same as the format specified for the DURATION component of the quantity/timing field, excluding the "X" specification. |
This field is required when relevant (e.g., certain IVs). For example, if the
"give amount/units" are 300 ml and the "give per" time unit is H1, the rate is
300ml/hr and the duration of this dose is 1 hour. Thus the give amount and
give per time unit define the duration of the service.
This field is distinct from the "interval" component of the quantity/timing
field, but it could be used in conjunction with it, as in give 300ml of NS
per hr for 1 hour, repeat twice a day.
The Pharmacy Route segment contains the alternative combination of route,
site, administration device, and administration method that are prescribed.
The pharmacy and/or nursing staff has a choice between the routes based on
either their professional judgment or administration instructions provided by
the physician.
SEQ |
LEN |
DT |
R/O |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
1 |
60 |
CE |
R |
0162 |
00309 |
Route |
4.8.3.0 RXR field definitions
Components: <identifier> ^ <text> ^ <name of coding system>
^ <alternate identifier> ^ <alternate text> ^ <name of alternate
coding system>
Definition: route of administration.
Some current "route codes," such as some of the NDC-derived codes include the
site already. In such cases, the entire code can be included in this field as
a "locally defined code" for the CE data type. Refer to table 0162 - route
of administration for valid entries.
Value |
Description |
Value |
Description |
AP |
Apply
Externally |
NS |
Nasal |
Components: <identifier> ^ <text> ^ <name of coding
system> ^ <alternate identifier> ^ <alternate text> ^ <name
of alternate coding system>
Definition: site of the administration route. Refer to table 0163 -
administrative site for valid entries.
Value |
Description |
Value |
Description |
BE |
Bilateral
Ears |
NB |
Nebulized |
As a CE data type, this field may be extended to cover a wide variety of body
site codes (e.g., when SNOMED is used as the table source).
Components: <identifier> ^ <text> ^ <name of coding
system>^<alternate identifier> ^ <alternate text> ^ <name of
alternate coding system>
Definition: mechanical device used to aid in the administration of the drug.
Common examples are IV-sets of different types. Refer to table 0164 -
administration device for valid entries.
Value |
Description |
Value |
Description |
AP |
Applicator |
IVS |
IV
Soluset |
Components: <identifier> ^ <text> ^ <name of coding system>
^ <alternate identifier> ^ <alternate text> ^ <name of alternate
coding system>
Definition: administration method identifies the specific method requested
for the administration of the drug to the patient. Refer to table 0165 -
administration method for valid entries.
Value |
Description |
Value |
Description |
CH |
Chew |
NB |
Nebulized |
If the drug ordered with the RXO segment is a compound drug OR an IV solution,
AND there is not a coded value for the Universal Service ID which specifies the
components (base and all additives), then the components (the base and
additives) are specified by two or more RXC segments. The policy of the
Pharmacy application on substitutions at the RXC level is identical to that for
the RXO level.
SEQ |
LEN |
DT |
R/O |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
1 |
1 |
ID |
R |
0166 |
00313 |
RX
Component Type |
4.8.4.0 RXC field definitions
Definition: values are the following:
Value |
Description |
B |
Base |
For the non-IV case, the "B" value may still apply. For example, if a custom
dermatologic salve is being prepared, the "B" item might be a standard base
ointment into which other components are mixed.
The amount of the "base" specified in the "B" segment(s) is defined to be the
quantity into which amounts specified in the "A" components are mixed. Thus
the RXC segments as a group define the "recipe" for a particular amount
(defined by the base segment(s)). The give amount, as defined in the RXO, does
not need to correspond to this base amount. For example, the RXC segments may
specify a recipe for a liter of a standard type of saline with 1 gram of a
particular antibiotic, while the give amount (from the RXO) may specify the
administration of 2 liters of this IV-solution every 24 hours.
The amount specified in each "A" segment is defined to be the quantity to be
added to the amount of the base as specified in its RXC segment.
If any "base" components are present then these should be transmitted first.
The first "base" component in the transmission should be considered the
"primary base" if such a distinction is necessary. Similarly, the first
"additive" in the transmission should be considered the "primary additive" if
such a distinction is necessary.
Components: <identifier> ^ <text> ^ <name of coding
system> ^ <alternate identifier> ^ <alternate text> ^ <name
of alternate coding system>
Definition: equivalent to OBR-4-universal service ID. It defines the
base or component in the same manner as the give and dispense codes. As with
the give and dispense codes, it may contain text only, code only, text + code,
or text + code + units (implied or explicit). As with the give and dispense
codes, if RXC-4-component units is present, this overrides the units
implied by the code. If only text is present, the Pharmacy application must
include a manual review or reentering of the component drug.
Definition: amount of this component to be added to the specified amount of
the base.
Components: <identifier> ^ <text> ^ <name of coding
system>^<alternate identifier> ^ <alternate text> ^ <name of
alternate coding system>
Definition: units for the component amount. If present, this overrides the
units implied by RXC-2-component code. This must be in simple units
that reflect the actual quantity of the component being added. It does not
include compound units.
In order for a group of IV solutions to be given sequentially can be supported
in two similar ways: Parent/Child and Separate Orders. This HL7 standard
supports both methods of ordering. The method used at a particular site must
be negotiated between the site institution and the various application vendors.
See section 4.4.10.2, cyclic placer order groups for further details.
This message communicates the Pharmacy application's encoding of the pharmacy
order (ORM message with RXO segment, see above). It may be sent as an
unsolicited message to report on either a single order or multiple pharmacy
orders for a patient.
As a site-specific variant, the original order segments (RXO, RXRs, associated
RXCs, and any NTEs) may be sent optionally (for comparison).
RDE Pharmacy Encoded Order Message
Chapter
MSH Message Header 2
[{NTE}] Notes and Comments (for Header) 2
[ PID Patient Identification 3
[{NTE}] Notes and Comments (for PID) 2
[{AL1}] Allergy 2
[PV1] Patient Visit 3
]
{
ORC Common Order 4
[
RXO Pharmacy Prescription 4
[{NTE}] Notes and Comments (for RXO) 2
{RXR} Pharmacy Route 4
[
{RXC} Pharmacy Component (for RXO) 4
[{NTE}] Notes and Comments (for RXC) 2
]
]
RXE Pharmacy Encoded Order 4
{RXR} Pharmacy Route 4
[{RXC}] Pharmacy Component (for RXE) 4
{
[OBX] Results 7
[{NTE}] Notes and Comments (for OBX) 2
}
}
Note: The RXCs which follow the RXO may not be fully encoded, but those that follow the RXE must be fully encoded. |
(acknowledged by)
RRE Pharmacy Encoded Order Acknowledgement Message
Chapter
MSH Message Header
2
MSA Message Acknowledgement
2
[ERR] Error
2
[{NTE}] Notes and Comments (for Header)
2
[
[PID Patient Identification
3
[{NTE}]] Notes and Comments (for PID)
2
{
ORC Common Order
4
[
RXE Pharmacy Encoded Order
4
{RXR} Pharmacy Route
4
[{RXC}] Pharmacy Component
4
]
}
]
The RXE segment details the pharmacy application's encoding of the order. It
also contains several pharmacy-specific order status fields, such as
RXE-16-number of refills remaining, RXE-17-number of refills/doses
dispensed, RXE-18-date/time of most recent refill/dose, and
RXE-19-total daily dose.
Note that ORC-7-quantity/timing has a different meaning from
RXE-1-quantity/timing and RXG-3-quantity/timing. The pharmacy
department has the "authority" (and/or necessity) to schedule dispense/give
events. Hence, the pharmacy department has the responsibility to encode this
scheduling information in RXE-1-quantity/timing and
RXG-3-quantity/timing. ORC-7-quantity/timing does not change: it
always specifies the requested give/dispense schedule of the original order.
SEQ |
LEN |
DT |
R/O |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
1 |
200 |
TQ |
R |
|
|
00221 |
Quantity/Timing |
4.8.7.0 RXE field definitions
Components: <quantity> ^ <interval> ^ <duration> ^
<start date/time> ^ <end date/time> ^ <priority> ^
<condition> ^ <text> ^ <conjunction> ^ <order
sequencing>
Definition: see Section 4.8.7 for necessary modification for this field's
definition to cover interorder dependencies needed by pharmacy orders. This
field is used by the Pharmacy to express the fully coded version of the drug
timing. It may differ from ORC-7-quantity/timing, which contains the
requested quantity/timing of the original order.
Components: <identifier> ^ <text> ^ <name of coding
system>^<alternate identifier> ^ <alternate text> ^ <name of
alternate coding system>
Definition: identifier of the medical substance ordered to be given to the
patient, as encoded by the Pharmacy; it is equivalent to OBR-4-universal
service ID in function. In the RXE segment, this give code must be fully
encoded. The dispense fields, which define the units and amount of what is to
be issued to the patient (see RXE-10-dispense amount and
RXE-11-dispense units below) do not necessarily correlate with the
instructions of what amount is to be "given" or administered with each dose,
and may or may not be specified with the order. For example, the "give" part
of the order may convey the field-representation of give 250 mg of
ampicillin, while the request to dispense part of the order may convey
issue 30 tablets of generic equivalent for this outpatient prescription.
Definition: ordered amount as encoded by the Pharmacy. In a variable dose
order, this is the minimum ordered amount. In a nonvarying dose order, this is
the exact amount of the order.
Note:
This field is not a duplication of the first component of the quantity/timing
field, since in non-Pharmacy orders, that component can be used to specify
multiples of an ordered amount. |
Definition: in a variable dose order, this is the maximum ordered amount. In
a nonvarying dose, this field is not used.
Components: <identifier> ^ <text> ^ <name of coding
system>^<alternate identifier> ^ <alternate text> ^ <name of
alternate coding system>
Definition: units for the give amount as encoded by the pharmacy application.
Note: These units can be a "compound quantity"; i.e., the units may contain the word "per." For example, micrograms per KG (micg/kg) is an acceptable value, which means that the units are micrograms per KG (of body weight). |
A table of standard units that contains compound units is needed. Until such
a table is agreed on, a user-defined table is needed for each site.
Components: <identifier> ^ <text> ^ <name of coding
system>^<alternate identifier> ^ <alternate text> ^ <name of
alternate coding system>
Definition: use the Give Dosage Form field when the give code does not
specifiy the dosage form.
Definition: ordering provider's instructions to the patient or the provider
administering the drug. This is a free text field; it may contain free text
describing a custom IV, mixture, or salve.
Components: <nurse unit & room & bed & facility ID & bed
status> ^ <street address & other designation & city & state
or province & zip or postal code & country & type & other
geographic designation>
Definition: the first component contains the inpatient or outpatient location
to which the pharmacy is to deliver the drug (if applicable). The default
(null) value is the current census location for the patient. Site specific
table. This component has the same form as PV1-3-assigned patient
location.
The second component can be used to specify an address. This could be used to
fill mail orders to a patient or provider, or to account for home health care.
Definition: refer to table 0167 - substitution status for valid
values. If a substitution has been made, and a record of the original
requested give code (RXO-1) is needed, the optional RXO segment can be
included in the RDE message.
Value |
Description |
N |
No
substitute was dispensed. This is equivalent to the default (null) value. |
Definition: amount dispensed as encoded by the pharmacy.
Components: <identifier> ^ <text> ^ <name of coding
system>^<alternate identifier> ^ <alternate text> ^ <name of
alternate coding system>
Definition: units for the dispense amount as encoded by the pharmacy. This
must be in simple units that reflect the actual quantity of the substance
dispensed. It does not include compound units.
Definition: total original number of refills. Outpatient only.
Components: <ID number> ^ <family name> ^ <given name>
^ <middle initial or name> ^ <suffix (e.g., JR or III)> ^
<prefix (e.g., DR)> ^ <degree (e.g., MD)> ^ <source
table>
Definition: if required by the site.
Components: <ID number> ^ <family name> ^ <given name>
^ <middle initial or name> ^ <suffix (e.g., JR or III)> ^
<prefix (e.g., DR)> ^ <degree (e.g., MD)> ^ <source
table>
Definition: provider ID of pharmacist verifier. Use if required by the
Pharmacy application or site on orders (or some subgroup of orders).
Definition: as assigned by the pharmacy application. Equivalent in
uniqueness to the Pharmacy filler order number. At some sites, this may be the
Pharmacy (internal) sequential form. At other sites, this may be an external
form.
Definition: outpatient only.
Definition: outpatient only.
Definition: date/time of the most recent refill or dose dispensed, use Time
Stamp format.
Components: <quantity> ^ <units>
Definition: total daily dose for this particular pharmaceutical as expressed
in terms of actual dispense units.
Definition: uses table 0136 - Y/N indicator. The values have the
following meaning for this field:
Value |
Description |
Y |
Yes
- Indicates that a warning is present. The application receiving the encoded
order needs to warn the person administering the drug to pay attention to the
text in RXE-22-pharmacy special dispensing instructions. |
Definition: pharmacy-generated special instructions to the provider
dispensing/administering the order.
Definition: time unit to use to calculate the rate at which the
pharmaceutical is to be administered.
Format:
S<integer> = <integer> seconds
M<integer> = <integer> minutes
H<integer> = <integer> hours
D<integer> = <integer> days
W<integer> = <integer> weeks
L<integer> = <integer> months
This is the same as the format specified for the DURATION component of the
quantity/timing field, excluding the "X" specification.
Required when relevant (e.g., certain IVs). For example, if the "give
amount/units" were 300 ml and the "give per" time unit were H1 (equivalent to
one hour), the rate is 300ml/hr.
Definition: amount (number) of substance to be administered.
Definition: units for Give Rate Amount. May be composite. The ratio of the
Give Rate Amount and Give Rate Units fields define the actual rate of
administration. Thus, if Give Rate Amount = 100 and Give Rate Units = ml/hr,
the requested rate of administration is 100 ml/hr.
For the RDS (pharmacy dispense), RGV (pharmacy give) and RAS (pharmacy
administration) messages, the placer and filler numbers are those of the parent
RDE (pharmacy encoded order) message. In these messages, the filler number does
not provide a unique identification of the instance of the pharmacy action
(dispense, give or administer). To correct this problem, each of the defining
segments (RXD, RXG, and RXA) has an appropriately named sub-ID field (dispense
sub-ID counter, give sub-ID counter, and administration sub-ID counter). The
combination of the filler number (including its application ID component) and
the appropriate sub-ID counter uniquely identifies the instance of the pharmacy
action(s) present in these messages.
Although the default order control code for the RDE, RDS, RGV and RAS messages
is "RE", there are cases in which the pharmacy system and the receiving system
must communicate changes in state (see appendix A of this chapter). Depending
on whether the pharmacy's relationship to the receiving system is that of
placer or filler, the appropriate order control code may be substituted for the
default value of "RE". The receiving system can also use an appropriate order
control code to report status back to the pharmacy system.
For example, suppose that a pharmacy system is sending RGV messages to a
nursing system which will administer the medication and that the pharmacy
system needs to request that several instances of a give order be discontinued.
To implement this request, the RGV message may be sent with a "DC" order
control code (discontinue request), and the appropriate RXG segments whose give
sub-ID fields identify the instances to be discontinued. If a notification back
to the pharmacy is needed, the nursing system can initiate an RGV message with
a "DR" order control code (discontinue as requested), and containing RXG
segments whose give sub-ID fields identify the discontinued instances.
The RDS message may be created by the Pharmacy application for each instance
of dispensing drugs to fill an existing order or orders. In the most common
case, the RDS messages would be routed to a Nursing application or to some
clinical application, which needs the data about drugs dispensed. As a
site-specific variant, the original order segments (RXO, RXE and their
associated RXR/RXCs) may be sent optionally (for comparison).
RDS Pharmacy Dispense Message Chapter
MSH Message Header 2
[{NTE}] Notes and Comments (for Header) 2
[
PID Patient Identification 3
[{NTE}] Notes and Comments (for PID) 2
[{AL1}] Allergy 2
[PV1] Patient Visit 3
]
{
ORC Common Order 4
[
RXO Pharmacy Prescription 4
[
{NTE} Notes and Comments (for RXO) 2
{RXR} Pharmacy Route 4
[
{RXC} Pharmacy Component 4
[{NTE}] Notes and Comments (for RXC) 2
]
]
]
[
RXE Pharmacy Encoded Order 4
{RXR} Pharmacy Route 4
[{RXC}] Pharmacy Component 4
]
RXD Pharmacy Dispense 4
{RXR} Pharmacy Route 4
[{RXC}] Pharmacy Component 4
{
OBX Results 7
[{NTE}] Notes and Comments (for OBX) 2
}
}
(acknowledged by)
RRD Pharmacy Dispense Acknowledgement Message
Chapter
MSH Message Header
2
MSA Message Acknowledgement
2
[ERR] Error
2
[{NTE}] Notes and Comments (for Header)
2
[
[PID Patient Identification
3
[{NTE}]] Notes and Comments (for Patient ID)
2
{
ORC Common Order
4
[
RXD Pharmacy Dispense
4
{RXR} Pharmacy Route
4
[{RXC}] Pharmacy Component
4
]
}
]
The ORC must have the filler order number and the order control code RE. The
RXE and associated RXCs may be present if the receiving application needs any
of their data. The RXD carries the dispense data for a given issuance of
medication: thus it may describe a single dose, a half-day dose, a daily dose,
a refill of a prescription, etc. The RXD is not a complete record of an order.
Use the RXO and RXE segments if a complete order is needed. It is a record
from the Pharmacy to the Nursing application (or other) with drug dispense and
administration instructions.
SEQ |
LEN |
DT |
R/O |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
1 |
4 |
NM |
R |
|
|
00334 |
Dispense
Sub-ID Counter |
4.8.10.0 RXD field definitions
Definition: starts with 1 the first time that medication is dispensed for
this order. Increments by one with each additional issuance of medication.
Components: <identifier> ^ <text> ^ <name of coding
system>^<alternate identifier> ^ <alternate text> ^ <name of
alternate coding system>
Definition: identifier of the medical substance ordered to be given to the
patient; it is equivalent to OBR-4-universal service ID code. See the
RXE segment for a complete definition of the RXE-2-give code.
Note: The contents of RXD-2-dispense/give code should be identical to the comparable field in the RXE (RXE-2-give code). The RDS message refers ONLY to the dispensing of the drug by the Pharmacy. |
Definition: when the pharmaceutical is dispensed from the Pharmacy. Use the
time-stamp format.
Definition: amount dispensed.
Components: <identifier> ^ <text> ^ <name of coding
system>^<alternate identifier> ^ <alternate text> ^ <name of
alternate coding system>
Definition: units dispensed. Site-defined table. As with Give units, if the
units are part of the actual dispense code this field is optional, but if
present, it overrides units implied by the actual dispense code. This must be
in simple units that reflect the actual quantity of the substance dispensed.
It does not include compound units.
Components: <identifier> ^ <text> ^ <name of coding
system>^
<alternate identifier> ^ <alternate text> ^ <name of
alternate coding system>
Definition: use this field when the give code and the dispense code do not
specify the dosage form.
Definition: equivalent in uniqueness to the Pharmacy filler order number. At
some sites, this may be the Pharmacy (internal) sequential form. At other
sites, this may be an external form.
Definition: outpatient only.
Definition: free text notes to the person dispensing the medication (may
include the ordering provider's original notes, as well as any notes from the
formulary or the pharmacy). This may contain free text describing a custom IV,
mixture, or salve.
Components: <ID number> ^ <family name> ^ <given name>
^ <middle initial or name> ^ <suffix (e.g., JR or III)> ^
<prefix (e.g., DR)> ^ <degree (e.g., MD)> ^ <source
table>
Definition: provider ID of the person dispensing the pharmaceutical.
Definition: refer to table 0167 - substitution status for suggested
values.
Definition: total daily dose being dispensed as expressed in terms of the
actual dispense units.
Note: The next two fields are equivalent to the corresponding fields of the RXE segment. They are included (optionally) in the RXD so that it may "stand alone" as a dispense result instruction segment. |
Components: <nurse unit & room & bed & facility ID &
bed status> ^ <street address & other designation & city &
state or province & zip or postal code & country & type & other
geographic designation>
Definition: the first component contains the inpatient or outpatient location
where the drug was dispensed (if applicable). The default (null) value is the
current census location for the patient. Site specific table. This component
has the same form as PV1-3-assigned patient location.
The second component can be used to specify an address. This could be used to
fill mail orders to a patient or provider.
Definition: refer to table 0136 - Y/N indicator for valid values. The
values have the following meaning for this field:
Value |
Description |
Y |
Yes
- Indicates that a warning is present. The application receiving the dispense
order needs to warn the person dispensing/administering the drug to pay
attention to the text in RXD-15-pharmacy special dispensing
instructions. |
Definition: pharmacy-generated special instructions to the provider
dispensing/administering the order.
The RDS message's RXD segment carries the dispense data for a given issuance
of medication: thus it may describe a single dose, an half-day dose, a daily
dose, a refill of a prescription, etc. It does not contain the given
instructions or scheduling information. When this "give" (i.e.,
administration) information needs to be transmitted from the Pharmacy
application to another application, it is done with the RGV message.
The RGV message uses the RXG segment to record drug administration
instructions. It may carry information about a single scheduled administration
on a drug, or it may carry information about multiple administrations of a
drug. If the pharmacy (or some other application) needs to create a
nonambiguous MAR report where each administration is matched to a particular
give date/time instruction, it may use the RGV message as described in the
following way:
For each scheduled administration of the medication, the pharmacy issues
either a single RGV message or a single RGV message with multiple RXG segments,
one for each scheduled administration. The actual administrations (transmitted
by one or more RAS messages) are matched against the scheduled ones by
recording in each RXA segment the Give Sub-ID of the corresponding RXG segment.
If more than one administration needs to be matched (as in the case of
recording a change or rate of an IV solution) the administering application
issues additional RXA segment(s) (corresponding to the same RXG segment). If
no matching is needed, the Give Sub-ID of the RXA segments has the value zero
(0).
The ORC must have the filler order number and the order control code RE. The
RXE and associated RXCs may be present if the receiving application needs any
of their data. The RXG carries the scheduled administration data for either a
single "give instruction" (single dose) of medication or for multiple "give
instructions." The RXG is not a complete record of an order. Use the RXO and
RXE segments if a complete order is needed. It is a record from the Pharmacy
to the Nursing application (or other) with drug administration instructions.
RGV Pharmacy Give
Chapter
MSH Message Header 2
[{NTE}] Notes and Comments (for Header) 2
[
PID Patient Identification 3
[{NTE}] Notes and Comments (for PID) 2
[{AL1}] Allergy 2
[ PV1 ] Patient Visit 3
]
{
ORC Common Order 4
[
RXO Pharmacy Prescription 4
[
{NTE} Notes and Comments (for RXO) 2
{RXR} Pharmacy Route 4
[
{RXC} Pharmacy Component 4
[{NTE}] Notes and Comments (for RXC) 2
]
]
]
[
RXE Pharmacy Encoded Order 4
{RXR} Pharmacy Route 4
[{RXC}] Pharmacy Component 4
]
{
RXG Pharmacy Give 4
{RXR} Pharmacy Route 4
[{RXC}] Pharmacy Component 4
{
[OBX] Observation/Results 7
[{NTE}] Notes and Comments (for OBX) 2
}
}
}
(acknowledged by)
RRG Pharmacy Give Acknowledgement Message
Chapter
MSH Message Header
2
MSA Message Acknowledgement
2
[ERR] Error
2
[{NTE}] Notes and Comments (for Header)
2
[
[PID Patient Identification
3
[{NTE}]] Notes and Comments (for PID)
2
{
ORC Common Order
4
[
RXG Pharmacy Give
4
{RXR} Pharmacy Route
4
[{RXC}] Pharmacy Component
4
]
}
]
SEQ |
LEN |
DT |
R/O |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
1 |
4 |
NM |
R |
|
|
00342 |
Give
Sub-ID Counter |
4.8.12.0 RXG field definitions
Definition: use if this RXG segment carries information about a single
adminstration. Starts with 1 for the first scheduled give date/time
transmitted by the pharmacy for this order. Increments by one with each
additional scheduled give date/time for this order.
If the RXG segment carries information about multiple adminstrations, this
field's value is zero, since in this case a one-to-one matching with the RAS
segment is ambiguous.
Definition: dispense sub-ID to which this give message is related.
Components: <quantity> ^ <interval> ^ <duration> ^
<start date/time> ^ <end date/time> ^ <priority> ^
<condition> ^ <text> ^ <conjunction> ^ <order
sequencing>
Definition: quantity/timing specification that refers to either a single
scheduled give instruction only or to multiple give instructions. In the
former case, RXG-1-give sub-ID counter is a positive integer greater
than or equal to one (1). In the latter case, RXG-1-give sub-ID counter
is zero (0). The quantity will always be 1. This quantity/timing field may
differ from the ORC quantity/timing field, which contains the requested
quantity/timing of the original order.
Note: The contents of fields 3-8 should be identical to the comparable fields in the RXE (RXE-2 thru 5). |
Components: <identifier> ^ <text> ^ <name of coding
system>^<alternate identifier> ^ <alternate text> ^ <name of
alternate coding system>
Definition: identifier of the medical substance ordered to be given to the
patient; it is equivalent to OBR-4-universal service ID code in
function. See the RXE segment for a complete definition of the RXE-2-give
code.
Definition: ordered amount as encoded by the Pharmacy. In a variable dose
order, this is the minimum ordered amount. In a nonvarying dose order, this is
the exact amount of the order.
Note:
This field is not a duplication of the first component of the quantity/timing
field, since in non-Pharmacy orders, that component can be used to specify
multiples of an ordered amount. |
Definition: in a variable dose order, this is the maximum ordered amount. In
a nonvarying dose order, this field is not used.
Components: <identifier> ^ <text> ^ <name of coding
system>^<alternate identifier> ^ <alternate text> ^ <name of
alternate coding system>
Definition: units for the give amount.
Note: These units can be a "compound quantity"; i.e., the units may contain the word "per." For example, micrograms per KG (micg/kg) is an acceptable value, which means that the units are micrograms per KG (of body weight). |
A table of standard units that contains compound units is needed. Until such
a table is agreed on, a user-defined table is needed for each site.
Components: <identifier> ^ <text> ^ <name of coding
system>^<alternate identifier> ^ <alternate text> ^ <name of
alternate coding system>
Definition: use this field when the give code does not specify the dosage form.
Definition: free text notes to the person administering the medication (may
include the ordering provider's original notes, as well as any notes from the
formulary or the pharmacy).
Definition: refer to table 0167 - substitution status for valid values.
Note: The next two fields are equivalent to the corresponding fields of the RXE segment. They are included (optionally) in the RXG so that it may "stand alone" as a "give" instruction segment. |
Components: <nurse unit & room & bed & facility ID & bed
status> ^ <street address & other designation & city & state
or province & zip or postal code & country & type & other
geographic designation>
Definition: the first component contains the inpatient or outpatient location
where the drug was dispensed (if applicable). The default (null) value is the
current census location for the patient. Site specific table. This component
has the same form as PV1-3-assigned patient location.
The second component can be used to specify an address. This could be used to
fill mail orders to a patient or provider.
Definition: refer to table 0136 - Y/N indicator for valid values. The
values have the following meaning for this field:
Value |
Description |
Y |
Yes
- Indicates that a warning is present. The application receiving the dispense
order needs to warn the person dispensing/administering the drug to pay
attention to the text in RXG-13-pharmacy special administration
instructions. |
Definition: pharmacy-generated special instructions to the provider
administering the order.
Definition: time unit to use to calculate the rate at which the
pharmaceutical is to be administered.
Format:
S<integer> = <integer> seconds
M<integer> = <integer> minutes
H<integer> = <integer> hours
D<integer> = <integer> days
W<integer> = <integer> weeks
L<integer> = <integer> months
This is the same as the format specified for the DURATION component of the
quantity/timing field, excluding the "X" specification.
Required when relevant (e.g., certain IVs). For example, if the "give
amount/units" were 300 ml and the "give per" time unit were H1 (equivalent to
one hour), the rate is 300ml/hr.
Definition: amount (number) of substance to be administered.
Components: <identifier> ^ <text> ^ <name of coding
system>^<alternate identifier> ^ <alternate text> ^ <name of
alternate coding system>
Definition: units for Give Rate Amount. May be composite. The ratio of the
Give Rate Amount and Give Rate Units fields define the actual rate of
administration. Thus, if Give Rate Amount = 100 and Give Rate Units = ml/hr,
the requested rate of administration is 100 ml/hr.
The RAS message may be created by the administering application (e.g., nursing
application) for each instance of administration for an existing order. If the
administering application wants to report several administrations of medication
for a given order with a single RAS message, each instance is reported by a
separate (repeating) RXA segment. In addition, the administration records for
a group of orders may be sent in a single message by creating repeating groups
of segments at the ORC level.
In the most common case, the RAS messages would be sent from a nursing
application to the pharmacy application (or to the ordering application or
another clinical application), which could use the data to generate the
medication administration reports. Multiple RXA segments, each corresponding
to a separate administration instance for a given order, may be sent with a
single ORC.
RAS Pharmacy Administration
Chapter
MSH Message Header 2
[{NTE}] Notes and Comments (for Header) 2
[
PID Patient Identification 3
[{NTE}] Notes and Comments (for PID) 2
[{AL1}] Allergy 2
[ PV1 ] Patient Visit 3
]
{
ORC Common Order 4
[
RXO Pharmacy Prescription 4
[
{NTE} Notes and Comments (for RXO) 2
{RXR} Pharmacy Route 4
[
{RXC} Pharmacy Component 4
[{NTE}] Notes and Comments (for RXC) 2
]
]
]
[
RXE Pharmacy Encoded Order 4
{RXR} Pharmacy Route 4
[{RXC}] Pharmacy Component 4
]
{RXA} Pharmacy Administration 4
RXR Pharmacy Route 4
{[OBX Observation/Result 7
{[NTE]} Notes and Comments (for OBX) 2
]}
}
(acknowledged by)
RRA Pharmacy Administration Acknowledgement Message
Chapter
MSH Message Header
2
MSA Message Acknowledgement
2
[ERR] Error
2
[{NTE}] Notes and Comments (for Header)
2
[
[PID Patient Identification
3
[{NTE}]] Notes and Comments (for PID)
2
{
ORC Common Order
4
[
{RXA} Pharmacy Administration
4
RXR Pharmacy Route
4
]
}
]
The ORC must have the filler order number and the order control code RE. As a
site-specific variant, the RXO and associated RXCs and/or the RXE (and
associated RXCs) may be present if the receiving application needs any of their
data. The RXA carries the administration data.
SEQ |
LEN |
DT |
R/O |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
1 |
4 |
NM |
R |
|
|
00342 |
Give
Sub-ID Counter |
4.8.14.0 RXA field definitions
Definition: use if matching this RXA segment to its corresponding RXG
segment. If the two applications are not matching RXG and RXA segments, this
field's value is zero.
Definition: starts with 1 the first time that medication is administered for
this order. Increments by one with each additional administration of
medication.
Note: More than one RXA segment can be "matched" to a single RXG segment, as is the case when recording a change of the rate of adminstration of an IV solution. |
Definition: if the order is for a continuous administration (such as an IV),
and the rate is changed at a certain time after the start, an RAS message can
be issued to record the change. For such an RAS message, this field records
the time the rate was changed to the new value recorded in the Administered
Per (Time Unit) field of the same message.
Definition: If null, the date/time of RXA-3-date/time start of
administration is assumed.
Components: <identifier> ^ <text> ^ <name of coding
system>^<alternate identifier> ^ <alternate text> ^ <name of
alternate coding system>
Definition: identifier of the medical substance administered. It is
equivalent to OBR-4-universal service ID code in function.
Definition: amount administered.
Components: <identifier> ^ <text> ^ <name of coding
system>^<alternate identifier> ^ <alternate text> ^ <name of
alternate coding system>
Definition: must be in simple units that reflect the actual quantity of the
substance administered. It does not include compound units.
Components: <identifier> ^ <text> ^ <name of coding
system>^<alternate identifier> ^ <alternate text> ^ <name of
alternate coding system>
Definition: use this field when the administered code does not specify the
dosage form.
Definition: free text notes from the provider administering the medication.
This may contain free text describing a custom IV, mixture, or salve.
Components: <ID number> ^ <family name> ^ <given name> ^
<middle initial or name> ^ <suffix (e.g., JR or III)> ^ <prefix
(e.g., DR)> ^ <degree (e.g., MD)> ^ <source table>
Definition: provider ID of the person administering the pharmaceutical.
Components: <nurse unit & room & bed & facility ID & bed
status> ^ <street address & other designation & city & state
or province & zip or postal code & country & type & other
geographic designation>
Definition: the first component contains the inpatient or outpatient location
at which the drug was administered (if applicable). The default (null) value
is the current census location for the patient. Site specific table. This
component has the same form as PV1-3-assigned patient location.
The second component can be used to specify an address. This could be used to
fill mail orders to a patient or provider, or to account for home health care.
Definition: rate at which this medication was administered as calculated by
using the Administered Amount and the Administered Units fields.
With appropriate definitions in the QRD and/or QRF segments, the RDE, RDS,
RGV, and RAS messages can serve as models for result-oriented Pharmacy queries
returning the current profile of Pharmacy orders (RDE type), the current
dispense history (RDS type), the current dose history (RGV type), or the
current administration record (RAS type). Examples are given in Section
4.8.16.3.
The purpose of this section is to show how certain specific situations would
be handled using the pharmacy protocol. The ellipses represent uncompleted
details. The symbol // precedes comments for clarification.
The order give 500 mg Ampicillin P.O. Q6H for 10 days for a total of 40
tablets is sent to the RX application from the OE application. This order
can be coded with various levels of precision by an ordering application:
a) E-mail only version (uses only free text, RXO-6-provider's pharmacy
instructions or RXO-7-provider's administration instructions only);
fully encoded version must be re-entered or verified manually by the pharmacy
application.
b) With RXO-2-requested give amount-minimum, RXO-4-requested give
units, and ORC-7-quantity/timing coded, and RXO-1-requested give
code as free text.
c) With RXO-1-requested give code, RXO-2-requested give
amount-minimum, RXO-4-requested give units, and
ORC-7-quantity/timing coded, but where RXO-1-requested give code
does not include units.
d) With RXO-1-requested give code, RXO-2-requested give
amount-minimum, RXO-4-requested give units, and
ORC-7-quantity/timing coded, and where RXO-1-requested give code
does include units.
In this case, the units are optional. The rule for this case (on orders,
dispense results, give results, and administration results) is as follows: if
units are coded, they over-ride or supersede the units value implied by the
give code.
a) The E-mail only version of the order: no coded fields exist in the RXO.
MSH|...
PID|...
ORC|NW|1000^OE||||E||||||||
RXO||||||500 mg Polycillin Q6H for 10 days, dispense 40 Tablets||
b) A partially coded version of the order. This version has the
RXO-2-requested give amount-minimum, RXO-4-requested give units,
and ORC-7-quantity/timing coded, but the RXO-1-requested give
code as free text.
MSH|...
PID|...
ORC|NW|1000^OE||||E|^Q6H^D10^^^R|||||||
RXO|^Polycillin 500 mg TAB^|500||MG|||||Y||40|
RXR|PO|
c) A more completely coded version of the order, with the RXO-1-requested
give code, RXO-2-requested give amount-minimum, RXO-4-requested
give units, and ORC-7-quantity/timing coded, but where
RXO-1-requested give code does not imply units.
MSH|...
PID|...
ORC|NW|1000^OE||||E|^Q6H^D10^^^R|||||||
RXO|RX1001^Polycillin^L|500||MG|||||Y||40|
RXR|PO|
d) A completely encoded version, with the RXO-1-requested give code,
RXO-2-requested give amount-minimum, RXO-4-requested give units,
and ORC-7-quantity/timing coded, and where RXO-1-requested give
code does imply units.
MSH|...
PID|...
ORC|NW|1000^OE||||E|^Q6H^D10^^^R|||||||
RXO|RX1001^Polycillin 500 mg TAB^L|500||MG|||||G||40|
RXR|PO|
e) Pharmacy's encoded version (RDE message) sent to nursing application (a
generic substitution).
MSH|...
PID|...
ORC|RE|1000^OE|9999999^RX|||E|^Q6H^D10^^^R|||||||
RXE|^^^199012100600^^R|0047-0402-30^Ampicillin 250 MG
...TAB^NDC|2||TAB|||||G|80||||123456|rx#1001|
RXR|PO|
f) Pharmacy's dispense results (RDS message).
MSH|...
PID|...
ORC|RE|1000^OE|9999999^RX|||E|^Q6H^D10^^^R|||||||
RXD|1|0047-0402-30^Ampicillin 250 MG
TAB^NDC|199012100400|8|TAB||RX#1001|||123456|G|8
g) Pharmacy's give results (RGV message).
MSH|...
PID|...
ORC|RE|1000^OE|9999999^RX|||E|^Q6H^D10^^^R|||||||
RXG|1|1|^^199012100600^^R|0047-0402-30^Ampicillin 250 MG
TAB^NDC|500||MG|||G|
RXR|PO|
h) Nursing application Medications Administration results to Pharmacy or Order
Entry application.
MSH|...
PID|...
ORC|RE|1000^OE|9999999^RX|||E|^Q6H^D10^^^R|||||||
RXA|1|1|199012100615||0047-0402-30^Ampicillin 250 MG
TAB^NDC|2|TAB||
RXR|PO|
The RXC segments are used when the RXO-level code does not fully describe the
ordered entity, and the description requires more than a single code. Such
"customized" orderable entities may use a "generic" code at the RXO level;
e.g., <generic code> means "custom IV solution, see RXC segments for
details." In general, a given pharmacy application will have CE-type RXO-level
codes equivalent to:
RXCUSIV^Custom IV^Local (for nonstandard IVs)
RXCUSMIX^Custom Mixture^Local (for dermatology and other specialties)
RXCUSSLV^Custom Salve^Local (for dermatology and other specialties)
An order is sent from an Order Entry application to a Pharmacy application as
follows:
* IV D5W < 1/2 NS 100 cc/hr with an additive of 20 meq KCl in every
third liter, starting with the first bottle
* Continuous for 2 days (December 10, 1993 8am to December 12, 1993 at
8am)
* With a timing critical factor of 30 minutes
a) The ORC/RXO for the custom IV mixture and the two liters of NSD5W as
entered on the Order Entry application
MSH|...
PID|...
ORC|NW|2045^OE||||E|^C^199312100800^199312120800^^TM30^^^^|
RXO|||3|L|IV|D5W WITH 1/2 NS WITH 20 MEQ KCL EVERY THIRD BOTTLE STARTING
WITH
... FIRST||W8&825&A^|N||||||||H30
RXR|IV|LA|IV-SET01^^L|
b) Pharmacy's Encoded Version sent to Nursing Unit West 8 Room 825 Bed A
The Pharmacy sends the order as a parent/child set. This spawns, from the
free text order 2045, two child orders with two precisely defined service
requests. ORC-4-quantity/timing represents the timing request of the
time of the order creation; i.e., ORC-4-quantity/timing represents the
requested time. RXE-1-quantity/timing represents the Pharmacy's
interpretation of the order.
MSH|...
PID|...
ORC|PA|2045^OE|123^PH||||E|^C^199312100800^199312120800^^TM30^^^^
The first fully encoded child order is the order for the custom IV. This is
a continuous, repeating order, the first of a cyclic group with a maximum
number of two repetitions. The first repeat starts at the start date/time of
199312100800. This order can itself be a parent order and spawn individual
give orders and/or it can be sent to an administering system (as in this
example) which will be responsible for handling the "give" parts of the
transactions.
ORC|CH|2045^OE|124^PH|||E||2045&OE^123&PH|
RXE|^C^H10^199312100800^199312120800^TM30^^^^S&&&125&PH&*ES+0M&2|RXCUSIV^Custom
...IV^L||1|L|IV||W8&825&A|N|||||||RX#1256|||||||H10|100|CC/HR
RXR|IV|LA|IV-SET01^^L|
RXC|B|IVDEX05^D5W WITH 1/2 NS^L|1|L
RXC|A|CHEM_KCL^KCL^L|20|MEQ
The second fully encoded child order is for the plain D5W solution. It is
the second part of a cyclic order group, and starts as soon as the first
repetition of order with filler order number 124^PH is done (end-to-start with
no intervening time increment). It has a maximum number of two repetitions.
This order can itself be a parent order and spawn individual give orders and/or
it can be sent to an administering system (as in this example) which will be
responsible for handling the "give" parts of the transactions.
ORC|CH|2045^OE|125^PH|||E||2045&OE^123&PH|
RXE|^C^H20^199312101800^199312120800^TM30^^^^S&&&124&PH&ES+0M&2|IVDEX05^D5W
WITH 1/2
...NS^L||2|L|IV||W8&825&A|N||||||RX#1256||||||||H20|100|CC/HR
RXR|IV|LA|IV-SET01^^L|
c) Pharmacy's Give Instructions (for the custom IV order only)
If the nursing system does not decode the RDE messages, but instead required
the individual give messages, the following message can be used. It carries
the instructions to the Nursing unit for administering the (first child) IV.
It is also the Pharmacy's (dispense audit) record. The optional RXC segments
are used to give a full description of the custom IV solution. In this
example, RXG-3-quantity/timing represents the actual time the Pharmacy
is requesting that the drug be given. The order sequencing component of
quantity/timing is not needed in this message.
MSH|...
PID|...
ORC|RE|2045^OE|124^PH|||E|^C^199312100800^199312120800^^TM30^^^^|2045&OE^123&PH|||||||
RXG|1||^C^H10^199312100800^199312101800^^TM30|RXCUSIV^Custom
IV^L|1||L|
...IV|||W8&825&A|||H10|100|CC/HR
RXR|IV|LA|IV-SET01^^L|
RXC|B|IVDEX05^D5W WITH 1/2 NS^L|1|L
RXC|A|CHEM_KCL^KCL^L|20|MEQ
d) Nursing application Medication Administration results to the Pharmacy or
Order Entry application
A message is sent from Nursing when the first bottle of Custom Mixture has
been administered. A second message would be sent from Nursing when the NS is
administered.
MSH|...
PID|...
ORC|RE|2045^OE|124^PH|||E|^C^199312100800^199312120800^^TM30^^^^||||||||
RXA|1|1|199312100800|199312101800|RXCUSIV^Custom
IV^L|1|L|IV|||W8&825&A|H10
RXR|IV|LA|IV-SET01^^L|
This completes the first series of messages for this drug administration.
R0R Pharmacy Prescription Order Response
MSH Message Header
MSA Message Acknowledgment
[ERR] Error
{
QRD Query Definition
[QRF] Query Filter
[PID Patient Identification
{[NTE]}] Notes and Comments (for PID)
{
ORC Common Order
RXO Pharmacy Order
{RXR} Pharmacy Route
{[RXC]} Pharmacy Component
}
}
DSC Continuation Pointer
RAR Pharmacy Administration Information
MSH Message Header
MSA Message Acknowledgment
[ERR] Error
{
QRD Query Definition
[QRF] Query Filter
[PID Patient Identification
{[NTE]}] Notes and Comments (for PID)
{
ORC Common Order
[
RXE Pharmacy Encoded Order
{RXR} Pharmacy Route
{[RXC]} Pharmacy Component
]
{RXA} Pharmacy Administration
RXR Pharmacy Route
}
}
DSC Continuation Pointer
RDR Pharmacy Dispense Information
MSH Message Header
MSA Message Acknowledgment
[ERR] Error
{
QRD Query Definition
[QRF] Query Filter
[PID Patient Identification
{[NTE]}] Notes and Comments (for PID)
{
ORC Common Order
[
RXE Pharmacy Encoded Order
{RXR} Pharmacy Route
{[RXC]} Pharmacy Component
]
{RXD} Pharmacy Dispense
{RXR} Pharmacy Route
}
}
DSC Continuation Pointer
RER Pharmacy Encoded Order Information
MSH Message Header
MSA Message Acknowledgment
[ERR] Error
{
QRD Query Definition
[QRF] Query Filter
[PID Patient Identification
{[NTE]}] Notes and Comments (for PID)
{
ORC Common Order
RXE Pharmacy Encoded Order
RXR Pharmacy Route
{[RXC]} Pharmacy Component
}
}
DSC Continuation Pointer
RGR Pharmacy Dose Information
MSH Message Header
MSA Message Acknowledgment
[ERR] Error
{
QRD Query Definition
[QRF] Query Filter
[PID Patient Identification
{[NTE]}] Notes and Comments (for PID)
{
ORC Common Order
[
RXE Pharmacy Encoded Order
{RXR} Pharmacy Route
{[RXC]} Pharmacy Component
]
{RXG} Pharmacy Give
{RXR} Pharmacy Route
}
}
DSC Continuation Pointer
The lab application requests pharmacy administration information for patient
12345, from 8/12/92 through 8/13/92.
MSH|...<CR>
QRD|19920814165645|R|D|9200231|||30^RD|12345|RAS<CR>
QRF|PHM|19920812000000|19920813235959<CR>
DSC<CR>
MSH|...<CR>
MSA|...<CR>
QRD|...<CR>
QRF|...<CR>
ORC|RE||R23<CR>
RXE|^BID^D5^199208120800^199208162000|10986^AMPICILLIN|250||MG<CR>
RXR|PO<CR>
RXA|1|1|199208120800|||250<CR>
RXA|2|2|199208122000|||250<CR>
RXA|3|3|199208130800|||250<CR>
RXA|4|4|199208132000|||250<CR>
ORC|RE||R76<CR>
RXE|^TID^D7^199208120600^199208182200|12796^ASPIRIN|325||MG<CR>
RXR|PO<CR>
RXA|1|1|199208120600|||325<CR>
RXA|2|2|199208121400|||325<CR>
RXA|3|3|199208122200|||325<CR>
RXA|4|4|199208130600|||325<CR>
RXA|5|5|199208131400|||325<CR>
RXA|6|6|199208132200|||325<CR>
DSC<CR>
The nursing sytem requests pharmacy dose information for patient 12345, from
8/12/92 through 8/13/92.
MSH|...<CR>
QRD|19920814172309|R|D|9200543|||100^RD|12345|RXG<CR>
QRF|PHM|19920812000000|19920813235959<CR>
DSC<CR>
MSH|...<CR>
MSA|...<CR>
QRD|...<CR>
QRF|...<CR>
ORC|RE||R23<CR>
RXE|^BID^D5^199208120800^199208162000|10986^AMPICILLIN|250||MG<CR>
RXR|PO<CR>
RXG|1||199208120701||250<CR>
RXG|2||199208121923||250<CR>
RXG|3||199208130702||250<CR>
RXA|4||199208131912||250<CR>
ORC|RE||R76<CR>
RXE|^TID^D7^199208120600^199208182200|12796^ASPIRIN|325||MG<CR>
RXR|PO<CR>
RXG|1||199208120459||325<CR>
RXG|2||199208121328||325<CR>
RXG|3||199208122101||325<CR>
RXG|4||199208130503||325<CR>
RXG|5||199208131311||325<CR>
RXG|6||199208132145||325<CR>
DSC<CR>
The order entry application requests pharmacy order information for patient
12345, from 8/12/92 through 8/13/92.
MSH|...<CR>
QRD|19920814181254|R|D|9200785|||45^RD|12345|RDE<CR>
QRF|PHM|19920812000000|19920813235959<CR>
DSC<CR>
MSH|...<CR>
MSA|...<CR>
QRD|...<CR>
QRF|...<CR>
ORC|RE|3346|R23<CR>
RXE|^BID^D5^199208120800^199208162000|10986^AMPICILLIN|250||MG<CR>
RXR|PO<CR>
ORC|RE|3987|R76<CR>
RXE|^TID^D7^199208120600^199208182200|12796^ASPIRIN|325||MG<CR>
RXR|PO<CR>
DSC<CR>
None.
The following are possible routes at a generic site.
+----------------------------------------------------+
? ?
+------------------+ +----------------+ 5
¦
¦ ORDERING SYSTEM ¦ +--? ¦ NURSING SYSTEM ¦
?--------¦
+------------------+ ¦ +----------------+ RAS/RXA
¦
? ? ¦ ? ? ?
¦ +---------------------?--¦ ¦
¦
1 +-------------------+ ¦ ¦ 4
¦
¦ ORM/RXO ¦ ¦ RGV/RXG
¦
¦ ¦ ¦
¦
¦ ¦2 ¦ 3
¦
¦ RDE/RXE ? ? RDS/RXD
¦
¦ +----------+
¦
+------------------------??¦ PHARMACY ¦
¦
+----------+
¦
?
¦
+-------------------+
1. ORM/RXO:
The Ordering application generates a pharmacy order (ORM with RXO and possibly
additional RXC segments) and sends it to the Pharmacy application, Nursing
application, and/or other applications as appropriate at the site.
2. RDE/RXE:
The Pharmacy application may send the RDE, the Pharmacy Encoded Order message,
a fully encoded order to the Nursing application, Ordering application, and/or
other systemapplications as appropriate at the site.
3. RDS/RXD:
The Pharmacy application may send the RDS, the Pharmacy Dispense message, to
the Nursing application or other applications as appropriate at the site, each
time a medication is dispensed for this order. This message may occur multiple
times for each order.
4. RGV/RXG:
The Pharmacy application may send the RGV, the Pharmacy Give message, to the
Nursing application or other applications as appropriate at the site, for each
scheduled date/time of administration of a medication for a given order. This
message may occur multiple times for each order.
5. RAS/RXA:
The Nursing application (and other applications) can generate the RAS, the
Pharmacy Administration Results message, whenever a medication is given to the
patient. This message may occur multiple times for each order.