Chapter Chair/Editor: |
Clement
J. McDonald, MD |
Chapter Chair/Editor: |
Hans
Buitendijk |
Chapter Chair/Editor: |
Gunther
Schadow |
Chapter Chair/Editor: |
Helen
Stevens |
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.
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.11, "Message construction rules."
The examples included in this chapter were constructed according to the HL7
Encoding Rules.
This
chapter has been organized into five major sections, General, Diet, Supply,
Pharmacy and Vaccine. Each section contains the trigger events, message
definitions, segments and examples for the specific type of order messages.
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 list of allowable values for a field is included in the body of the
text, along with the field definition for easier reference.
Section 4.2 outlines the Quantity Timing (TQ) Data Type Definition as
this data type is not defined in chapter 2.
Sections 4.3 to 4.5 `General' includes the triggers and segments for
the clinical observations and diagnostic studies as well as the triggers
and message segments that are common to all of the order entry messages. Orders
for laboratory tests, bedside monitoring, diagnostic imaging,
electrocardiograms, vital signs, etc., are subsumed under this order message
set.
Sections 4.6 to 4.8 `Diet' include all of the usual diet specifications
including snacks and guest trays
Sections 4.9 to 4.11 `Supply' includes order messages for both Stock and
No-stock orders. Supply orders are different in that they often are not
patient-centered (e.g., requests to stock the ward supply room).
Sections 4.12 to 4.15 `Pharmacy / Treatment' includes all pharmacy and
treatment related order messages. These section additionally includes triggers
related to the dispensing, giving and administration of orders. In the
development of the treatment order transaction set , 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.
Sections 4.16 to 4.18 `Vaccine' includes triggers and segments specific
to vaccination order messages. These sections also include RXA definitions
specific to vaccination messages.
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
An OBX segment defined in Chapter 7.
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.
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.
The application or individual originating a request for services (order).
A list of associated orders coming from a single location regarding a single patient.
Components:
<quantity (CQ)> ^ <interval (CM)> ^ <duration (ST)> ^
<start date/time (TS)> ^ <end date/time (TS)> ^ <priority
(ST)> ^ <condition (ST)> ^ <text (TX)> ^ <conjunction
(ID)> ^ <order sequencing (CM)> ^ <occurrence duration (CE)> ^
<total occurrences (NM)>
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.8.41, "TQ -
timing quantity"). The components of a single quantity/timing specification
are described in Sections 4.3.1, "Quantity component (CQ)," through 4.3.12,
"Total occurrences component (NM)."
Subcomponents:
<quantity (NM) & units (CE)>
Definition: This field specifies the quantity of the service that should be
provided at each service interval. For example, if two blood cultures are 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 (IS)> & <explicit time interval (ST)>
Definition: This field 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.
Note: The component delimiter in this CQ is demoted to a subcomponent
delimiter.
Definition:
The repeating frequency with which the treatment is to be administered. It is
similar to the frequency and SIG code tables used in order entry systems. The
following is preferred syntax for repeat patterns:
Value |
Description |
|---|---|
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) |
xID |
"X" times per day at institution-specified times, where X is a numeral 5 or greater. E.g., 5ID=five times per day; 8ID=8 times per day |
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. |
Meal Related Timings |
<timing>C ("cum")<meal> |
A |
Ante (before) |
P |
Post (after) |
I |
Inter (e.g., between this meal and the next, between dinner and sleep |
M |
Cibus Matutinus (breakfast) |
D |
Cibus Diurnus (lunch) |
V |
Cibus Vespertinus (dinner) |
The
first subcomponent may repeat, with repeat values separated by a space. The
repeats are interpreted as connected by logical ANDs. E.g.,
Twice per day, every other day: BID QOD
Three times per day, Monday Wednesday and Friday: TID QJ135
Because of this syntax, repeat values should never contain blanks. If a free
text frequency, such as "Twice a day, every other day" is to be sent, use the
text component (component 8).
Definition:
This field 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:
This field 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:
This field 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 contain 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:
This field 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 |
|
C |
= |
Callback |
|
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 antimicrobial level. |
PRN |
= |
As needed |
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.
The priority component may repeat; separate repeating values with a space.
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: This field is a full text version of the instruction (optional).
Definition:
This non-null component indicates that a second timing specification is to
follow using the repeat delimiter. This field can take three values as shown
in HL7 table 0472
-
TQ Conjunction ID.
Value |
Description |
|---|---|
S |
Synchronous.
Do the next specification after this one (unless otherwise constrained by the
following components: ORC-7^4-start date/time and ORC-7^5-end
date/time). |
A |
Asynchronous
|
C |
This
is an actuation time |
Definition:
There are many situations, such as the creation of an order for a group of
intravenous (IV) solutions, where the sequence of the individual intravenous
solutions (each a service in itself) needs to be specified, e.g.,
hyperalimentation with multi-vitamins in every third bottle.
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-7-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-7-quantity/timing.
The sequencing conditions supported by this 10th component are based on the
completion of a predecessor service.
To
define a sequence condition, the 10th component of the quantity/timing field
component is divided into the subcomponents described in Figure 4-1.
Subcomponent |
Contains |
Notes |
|---|---|---|
1 |
Sequence/Results Flag |
S for sequence conditions; C for cyclical; R is reserved for possible future use. The C will be used for indicating a repeating cycle of orders; for example, individual intravenous solutions used in a cyclical sequence (a.k.a. "Alternating IVs"). This value would be compatible with linking separate orders or with having all cyclical order components in a single order. Likewise, the value would be compatible with either Parent-Child messages or a single order message to communicate the orders' sequencing |
2, 3 |
Placer
Order Number, |
Required/Optional: Contains the first two components of the placer order number: entity identifier (ST) and namespace ID (IS) (respectively). Uses two subcomponents since the placer order number is an EI data type. We have not defined sub-subcomponents in HL7. |
4, 5 |
Filler
Order Number, |
Required/Optional: Contains the first two components of the filler order number: entity identifier (ST) and namespace ID (IS) (respectively). Uses two subcomponents since the filler order number is an EI data type. 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: |
<one of "SS", "EE", "SE", or "ES"> +/- <time> |
||
The first letter stands for start (S) or end (E) of predecessor order, where the predecessor is defined by the placer or filler order number in subcomponents 1,2 or subcomponents 3,4. |
||
The second letter stands for the start (S) or end (E) of the successor order, where the successor order is the order containing this quantity/timing specification. |
||
The time specifies the interval between the predecessor and successor starts or ends (see following examples). |
||
Where
<time> is defined as: |
||
7 |
Maximum Number of Repeats |
The maximum number of repeats to be used only on cyclic groups. The total number of repeats is constrained by the end date/time of the last repeat or the end date/time of the parent, whichever is first. |
8, 9 |
Placer
Order Number, |
Required/Optional: Contains the last two components of the placer order number: universal ID (ST) and universal ID type (ID) (respectively). Uses two subcomponents since the placer order number is an EI data type. We have not defined sub-subcomponents in HL7. |
10, 11 |
Filler
Order Number, |
Required/Optional: Contains the last two components of the filler order number: universal ID (ST) and universal ID type (ID) (respectively). Uses two subcomponents since the filler order number is an EI data type. We have not defined sub-subcomponents in HL7. |
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-7-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 must be an asterisk (*). The last order to be executed may have a
"sequence condition value" whose first character must be a pound sign (#).
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-7-quantity/timing of the second child order specifies that it
follows the first child order.
ORC-7-quantity/timing of the third child order specifies that it follows
the second child order.
ORC-7-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-7-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.15.2, "RXO segment field examples
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).
Subcomponents:
<identifier (ST)> & <text (ST)> & <name of coding system
(IS)> & <alternate identifier (ST)> & <alternate text
(ST)> & <name of alternate coding system>
Definition: This field contains the duration for a single performance of a
service, e.g., whirlpool twenty minutes three times per day for three days. It
is optional within TQ and does not repeat.
Note: The component delimiter in this CQ is demoted to a subcomponent
delimiter.
Definition: This field contains the total number of occurrences of a service that should result from this order. It is optional within TQ and does not repeat. If both the end date/time and the total occurrences are valued and the occurrences would extend beyond the end date/time, then the end date/time takes precedence. Otherwise the number of occurrences takes precedence.
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^D3
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^Q1J2^^200005231432
Perform a service every Tuesday at 2:32 p.m. starting on 05/23/2000.
1^^^^198911210800
Perform a test before 11/21/89 0800, e.g., some preop laboratory tests.
1^Q1H^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^D4^^^^if K+>5.5
Perform a service every morning for 3 days and then do it every other day for 4
days (i.e., max twice) if the serum potassium is greater than 5.5.
^^^198812120800^^T^^Trough specimen for MIC^C~^^^^^R
The first repeat instructs to draw a blood specimen exactly at 8:00 a.m. on
12/12/1988. The second repeat specifies to report results routinely.
1^QD^D7^^^^^^^^M20
Whirlpool ankle for twenty minutes once a day for one week.
1^^^19990301^19990331^^^^^^H1^3
Three one hour home health nursing visits within the next month.
This section includes trigger events and message definitions that are general to all orders in addition to the Observation and Diagnostic Study.
Left
for backward compatibility only. It is recommended that the trigger
events OMG, OML, OMD, OMS OMN and OMP be used instead when communicating orders
and order related events.
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
non-patient specific orders, etc.
The CTD segment in this trigger is used to transmit temporary patient contact
details specific to this order.
ORM^O01^ORM_O01 |
General Order Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
[{NTE}] |
Notes and Comments (for Header) |
2 |
[ |
||
PID |
Patient Identification |
3 |
[PD1] |
Additional Demographics |
3 |
[{NTE}] |
Notes and Comments (for Patient ID) |
2 |
[ |
||
PV1 |
Patient Visit |
3 |
[PV2]] |
Patient Visit- Additional Info |
3 |
[{IN1 |
Insurance |
6 |
[IN2] |
Insurance Additional Info |
6 |
[IN3] |
Insurance Add'l Info - Cert. |
6 |
}] |
||
[GT1] |
Guarantor |
6 |
[{AL1}] |
Allergy Information |
3 |
] |
||
{ |
||
ORC |
Common Order |
4 |
[ |
||
<OBR| |
Order Detail Segment OBR, etc. |
4 |
RQD| |
||
RQ1| |
||
RXO| |
||
ODS| |
||
ODT> |
||
[{NTE}] |
Notes and Comments (for Detail) |
2 |
[CTD] |
Contact Data |
11 |
[{DG1}] |
Diagnosis |
6 |
[{ |
||
OBX |
Observation/Result |
7 |
[{NTE}] |
Notes and Comments (for Results) |
2 |
}] |
||
] |
||
[{FT1}] |
Financial Transaction |
6 |
[{CTI}] |
Clinical Trial Identification |
7 |
[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.10
"Supply Trigger Events & Messages" for pharmacy, see Section 4.13
"Pharmacy/Treatment Trigger Events & Messages"; and for dietary orders, see
Section 4.7, "Diet Trigger Events & Message Definitions".
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. 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.
j) The insurance segments (IN1, IN2, and GT1) are typically used for external
fillers, e.g., reference labs, where formal ADT transactions are overly complex
or not needed.
The
function of this message is to respond to an ORM message. An ORR message is
the application acknowledgment to an ORM message. See Chapter 2 for a
description of the acknowledgment paradigm.
In ORR the PID and ORC segments are optional, particularly in case of an error
response. However, ORC segments are always required in ORR when an order
detail segment is present. For example, a response ORR might include only the
MSH and MSA, but if a 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^O02^ORR_O02 |
General Order Acknowledgment Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ERR] |
Error |
2 |
[{NTE}] |
Notes and Comments (for Header) |
2 |
[ |
||
[PID |
Patient Identification |
3 |
[{NTE}]] |
Notes and Comments (for Patient ID) |
2 |
{ |
||
O RC |
Common Order |
4 |
<OBR| |
[Order Detail Segment] OBR, etc. |
4 |
RQD| |
||
RQ1| |
||
RXO| |
||
ODS| |
||
ODT> |
||
[{NTE}] |
Notes and Comments (for Detail) |
2 |
[{CTI}] |
Clinical Trial Identification |
7 |
} |
||
] |
OSQ^Q06 |
Order Status Query |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
QRD |
Query Definition |
2 |
[ QRF ] |
Query Filter |
2 |
[ DSC ] |
Continuation Pointer |
2 |
OSR^Q06 |
Order Status Response |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ERR] |
Error |
2 |
[{NTE}] |
Notes and Comments (for Header) |
2 |
QRD |
Query Definition |
2 |
[QRF] |
Query Filter |
2 |
[ |
||
[PID |
Patient Identification |
3 |
[{NTE}] |
Notes and Comments (for Patient ID) |
2 |
] |
||
{ |
||
ORC |
Common Order |
4 |
<OBR|RQD|RQ1| RXO|ODS|ODT> |
[Order Detail Segment] OBR, etc. |
4 |
[{NTE}] |
Notes and Comments (for Detail) |
2 |
[{CTI}] |
Clinical Trial Identification |
7 |
} |
||
] |
||
[DSC] |
Continuation Pointer |
2 |
The
QRD and QRF segments are defined in Chapter 2, Section 2.16, "Message Control
Segments."
The subject filters contained in the QRD and QRF segments describe the kind of
information that is required to satisfy the request. They are defined by local
agreement between the inquiring system and the ancillary system. See the
Implementation Guide for detailed examples of the use of query filter
fields.
The Set ID fields in the various segments (including PID) are used to count the
number of segments of one kind transmitted at one level of the hierarchy.
The Query Result Level field of the QRD determines the amount of data
requested. See Chapter 5, Section 5.10.5.3, "QRD - original style query
definition segment."
The OSQ message is a record-oriented query that has the structure as the
regular QRY message. OSQ is included here for the convenience of implementers.
The
function of this message is to initiate the transmission of information about a
general clinical order that uses the OBR segment. Messages using the ORM
message with the OBR segment are supported for backward compatibility. This
includes placing new orders, cancellation of existing orders, discontinuation,
holding, etc. OMG messages can originate also with a placer, filler, or an
interested third party.
The trigger event for this message is any change to a general clinical order.
Such changes include submission of new orders, cancellations, updates, patient
and non-patient-specific orders, etc.
This trigger includes segments identified as being for `previous results'.
These segments allow the sending system to include demographic and/or result
information from previous result reports when they are related to the current
order.
For example:
* Diagnostic laboratories referring tests to another lab for either
confirmation of results (HIV, etc.) or due to not being equipped to do the
tests (genetic testing, etc.).
* Diagnostic laboratories sending test results to Knowledge Bases for the
automated generation of diagnostic comments for inclusion into the lab
report.
The CTD segment in this trigger is used to transmit temporary patient contact
details specific to this order.
OMG^O19^OMG_O19 |
General Clinical Order Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
[{NTE}] |
Notes and Comments (for Header) |
2 |
[ |
||
PID |
Patient Identification |
3 |
[PD1] |
Additional Demographics |
3 |
[{NTE}] |
Notes and Comments (for Patient ID) |
2 |
[ |
||
PV1 |
Patient Visit |
3 |
[PV2] |
Patient Visit- Additional Info |
3 |
] |
|
|
[{IN1 |
Insurance |
6 |
[IN2] |
Insurance Additional Info |
6 |
[IN3] |
Insurance Add'l Info - Cert. |
6 |
}] |
||
[GT1] |
Guarantor |
6 |
[{AL1}] |
Allergy Information |
3 |
] |
||
{ |
||
ORC |
Common Order |
4 |
OBR |
Observation |
4 |
[{NTE}] |
Notes and Comments (for Detail) |
2 |
[CTD] |
Contact Data |
11 |
[{DG1}] |
Diagnosis |
6 |
[{ |
||
OBX |
Observation/Result |
7 |
[{NTE}] |
Notes and Comments (for Results) |
2 |
}] |
||
{[ |
||
[ |
||
PID |
Patient Identification - previous result |
3 |
[PD1] |
Additional Demographics - previous result |
3 |
] |
||
[ |
||
PV1 |
Patient Visit - previous result |
3 |
[PV2] |
Patient Visit Add. Info - previous result |
3 |
] |
||
[{AL1}] |
Allergy Information - previous result |
3 |
{ |
||
[ORC] |
Common Order - previous result |
4 |
OBR |
Order Detail - previous result |
4 |
{[NTE]} |
Notes and Comments - previous result |
2 |
[CTD] |
Contact Data - previous result |
10 |
{ |
||
OBX |
Observation/Result - previous result |
7 |
[{NTE}] |
Notes and Comments - previous result |
2 |
} |
||
} |
||
}] |
||
[{FT1}] |
Financial Transaction |
6 |
[{CTI}] |
Clinical Trial Identification |
7 |
[BLG] |
Billing Segment |
4 |
} |
The
function of this message is to respond to an OMG message. An ORG message is
the application acknowledgment to an OMG message. See Chapter 2 for a
description of the acknowledgment paradigm.
In ORG the PID and ORC segments are optional, particularly in case of an error
response. However, ORC segments are always required in ORG when the OBR is
present. For example, a response ORG might include only the MSH and MSA.
The function (e.g., cancel, new order) of both OMG and ORG messages is
determined by the value in ORC-1-order control. (See the table of order
control values for a complete list.)
ORG^O20^ORG_O20 |
General Clinical Order Acknowledgment Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
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 |
[OBR] |
Observation |
4 |
[{NTE}] |
Notes and Comments (for Detail) |
2 |
[{CTI}] |
Clinical Trial Identification |
7 |
} |
||
] |
The
following message structure may be used for the communication of laboratory and
other order messages and must be used for lab automation messages. While the
ORM message with the OBR segment can be used for backwards compatibility for
general lab messages, only the OML message should be used to take advantage of
the specimen and container extensions required in laboratory automation.
Note: The additional patient information (the segments PID, PD1, PV1, PV2, etc,
which are sent after the OBR with the current order - indicated below with
words "previous result"), could have been transferred with the previous result,
because the patient demographics related to the previous result can differ from
the demographics related to the current order. The current intent is to only
allow references to the same patient as in the header PID.
The SAC segments included in the message allow the transfer of, e.g.: a
laboratory order with multiple containers and multiple test orders related to
each container, or laboratory orders with test order requiring multiple
containers.
Refer to Chapter 13 Laboratory Automation for examples of usage,
particularly to clarify the use of two references to SAC segments in this one
message.
The CTD segment in this trigger is used to transmit temporary patient contact
details specific to this order.
OML^O21^OML_O21 |
Laboratory Order Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
[{NTE}] |
Notes and Comments (for Header) |
2 |
[ |
||
PID |
Patient Identification |
3 |
[PD1] |
Additional Demographics |
3 |
[{NTE}] |
Notes and Comments (for Patient ID) |
2 |
[PV1 |
Patient Visit |
3 |
[PV2]] |
Patient Visit- Additional Info |
3 |
[{IN1 |
Insurance |
6 |
[IN2] |
Insurance Additional Info |
6 |
[IN3] |
Insurance Add'l Info - Cert. |
6 |
}] |
||
[GT1] |
Guarantor |
6 |
[{AL1}] |
Allergy Information |
3 |
] |
||
{ |
||
[ |
||
SAC |
Specimen Container Details |
13 |
[{OBX}] |
Additional Specimen Characteristics |
7 |
] |
||
{ |
||
ORC |
Common Order |
4 |
[ |
||
OBR |
Observation Request |
4 |
[{ |
||
SAC |
Specimen Container Details |
13 |
[{OBX}] |
Additional Specimen Characteristics |
7 |
}] |
||
[TCD] |
Test Code Details |
13 |
[{NTE}] |
Notes and Comments (for Detail) |
2 |
[{DG1}] |
Diagnosis |
6 |
[{ |
||
OBX |
Observation/Result |
7 |
[TCD] |
Test Code Detail |
13 |
[{NTE}] |
Notes and Comments (for Results) |
2 |
}] |
||
[{ |
||
[PID |
Patient Identification - previous result |
3 |
[PD1]] |
Additional Demographics - previous result |
3 |
[PV1 |
Patient Visit - previous result |
3 |
[PV2]] |
Patient Visit Add. Info - previous result |
3 |
[{AL1}] |
Allergy Information - previous result |
3 |
{ |
||
[ORC] |
Common Order - previous result |
4 |
OBR |
Order Detail - previous result |
4 |
{[NTE]} |
Notes and Comments - previous result |
2 |
{ |
||
OBX |
Observation/Result - previous result |
7 |
[{NTE}] |
Notes and Comments - previous result |
2 |
} |
||
} |
||
}] |
||
] |
||
[{FT1}] |
Financial Transaction |
6 |
[{CTI}] |
Clinical Trial Identification |
7 |
[BLG] |
Billing Segment |
4 |
} |
||
] |
The
function of this message is to respond to an OML message. An ORL message is
the application acknowledgment to an OML message. See Chapter 2 for a
description of the acknowledgment paradigm.
ORL^O22^ORL_O22 |
General Laboratory Order Acknowledgment Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ERR] |
Error |
2 |
[{NTE}] |
Notes and Comments (for Header) |
2 |
[ |
||
[PID |
Patient Identification |
3 |
{ |
||
[SAC |
Specimen Container Details |
13 |
[{OBX}] |
Additional Specimen Characteristics |
7 |
] |
||
[{ |
||
ORC |
Common Order |
4 |
[OBR |
Observation Request |
4 |
[{SAC}] |
Specimen Container Details |
13 |
] |
||
}] |
||
} |
||
] |
||
] |
The following segments (ORC and BLG) are common to many order messages.
The
Common Order segment (ORC) is used to transmit fields that are common to all
orders (all types of services that are requested). The ORC segment is required
in the Order (ORM) message. ORC is mandatory in Order Acknowledgment (ORR)
messages if an order detail segment is present, but is not required
otherwise.
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 |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
2 |
ID |
R |
N |
0119 |
00215 |
Order Control |
2 |
22 |
EI |
C |
00216 |
Placer Order Number |
||
3 |
22 |
EI |
C |
00217 |
Filler Order Number |
||
4 |
22 |
EI |
O |
00218 |
Placer Group Number |
||
5 |
2 |
ID |
O |
N |
0038 |
00219 |
Order Status |
6 |
1 |
ID |
O |
0121 |
00220 |
Response Flag |
|
7 |
200 |
TQ |
O |
Y |
00221 |
Quantity/Timing |
|
8 |
200 |
CM |
O |
00222 |
Parent |
||
9 |
26 |
TS |
O |
00223 |
Date/Time of Transaction |
||
10 |
250 |
XCN |
O |
Y |
00224 |
Entered By |
|
11 |
250 |
XCN |
O |
Y |
00225 |
Verified By |
|
12 |
250 |
XCN |
O |
Y |
00226 |
Ordering Provider |
|
13 |
80 |
PL |
O |
00227 |
Enterer's Location |
||
14 |
250 |
XTN |
O |
Y/2 |
00228 |
Call Back Phone Number |
|
15 |
26 |
TS |
O |
00229 |
Order Effective Date/Time |
||
16 |
250 |
CE |
O |
00230 |
Order Control Code Reason |
||
17 |
250 |
CE |
O |
00231 |
Entering Organization |
||
18 |
250 |
CE |
O |
00232 |
Entering Device |
||
19 |
250 |
XCN |
O |
Y |
00233 |
Action By |
|
20 |
250 |
CE |
O |
0339 |
01310 |
Advanced Beneficiary Notice Code |
|
21 |
250 |
XON |
O |
Y |
01311 |
Ordering Facility Name |
|
22 |
250 |
XAD |
O |
Y |
01312 |
Ordering Facility Address |
|
23 |
250 |
XTN |
O |
Y |
01313 |
Ordering Facility Phone Number |
|
24 |
250 |
XAD |
O |
Y |
01314 |
Ordering Provider Address |
|
25 |
250 |
CWE |
O |
N |
01473 |
Order Status Modifier |
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 an 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 has already been 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.
Definition:
Determines the function of the order segment. Refer to
HL7
Table
0119 - O
rder
co
ntrol
codes and their meaning for valid entries. Depending on the message,
the action of the control code may refer to an order or an individual service.
For example, the code CA in an OMP message cancels the order. The same code in
an RDS message, cancels the dispense. 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).
Refer to section 4.19.1 for the contents of HL7
Table
0119
- Order control 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, RQ, RU, RO
A replacement is the substitution of one or more orders for one or more
previously ordered services.
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:
Segment |
Order Control |
Comment |
|---|---|---|
ORC |
RU |
1st replaced ORC |
OBR |
1st replaced order's detail segment |
|
ORC |
RU |
2nd replaced ORC |
OBR |
2nd replaced order's detail segment |
|
ORC |
RO |
1st replacement ORC |
OBR |
1st replacement order's detail segment |
|
ORC |
RO |
2nd replacement ORC |
OBR |
2nd replacement order's detail segment |
|
ORC |
RO |
3rd replacement ORC |
OBR |
3rd replacement order's detail segment |
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).
Segment |
Order Control |
Comment |
|---|---|---|
ORC |
RQ |
1st replaced ORC |
OBR |
1st replaced order's detail segment |
|
ORC |
RQ |
2nd replaced ORC |
OBR |
2nd replaced order's detail segment |
|
ORC |
RO |
1st replacement ORC |
OBR |
1st replacement order's detail segment |
|
ORC |
RO |
2nd replacement ORC |
OBR |
2nd replacement order's detail segment |
|
ORC |
RO |
3rd replacement ORC |
OBR |
3rd replacement order's detail segment |
e)
RP, RQ
The order replace request code permits the order filler to replace one or more
new 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, RQ
The replacement order code is sent by the filler application to another
application indicating the exact replacement ordered service. It is used with
the RP and RU order control codes as described above.
h) RP, RQ, RU, RO
The rules for the order numbers in ORC segments with an order control value of
RO are determined by the replacement type (RP or RU).
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, CH
The parent (PA) and child (CH) order control codes allow the spawning of
"child" 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 susceptibility reports. Then the sequence of segments would be
as follows:
Segment |
Order Control |
Comment |
|---|---|---|
ORC |
PA |
1st parent ORC |
ORC |
CH |
1st child ORC |
OBR |
1st child order |
|
ORC |
CH |
2nd child ORC |
OBR |
2nd child order |
The
assignment of placer order numbers in the parent-child paradigm depends on
whether the placer or 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 order numbers according to its usual
procedures. If the filler creates the child orders there are two possibilities:
each child will inherit the placer order number of its parent, or the filler
will use the SN/NA transaction to request that the placer assign a placer order
number. In either case, the filler application creates the filler order
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 order number (if
originating from the filler) and with the parent's placer order 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. An 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:
Segment |
Order Control |
Comment |
|---|---|---|
MSH |
||
PID |
||
ORC |
NW |
First new order |
RXO |
First order segment |
|
ORC |
NW |
2nd new order |
RXO |
2nd order segment |
|
[ORC |
RE |
Patient-specific observation, optional in V 2.2 |
OBR] |
Observation OBR, optional in V 2.2 |
|
OBX |
An observation segment |
|
OBX |
Another observation segment |
|
OBX |
Another observation segment |
|
OBX |
Another observation segment |
|
ORC |
NW |
3rd order |
RXO |
3rd order segment |
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 backward compatibility. In the current version it is
equivalent to an accept acknowledgment. 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, NA, NW
There are three circumstances that involve requesting an order number
(ORC-2-placer order number or ORC-3-filler order
number):
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
1) 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 |
NA |
other application |
placer order number^filler application ID |
filler order number^filler application ID |
2)
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 |
NA |
other application |
placer order number^placer application ID |
filler order number^filler application ID |
3) 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|...<cr>
PID|...<cr>
ORC|CN|...<cr>
OBR|1|A4461XA^HIS|81641^RAD|73666^Bilateral Feet|...<cr>
ORC|CN|...<cr>
OBR|2|A4461XB^HIS|81642^RAD|73642^Bilateral Hand PA|...<cr>
ORC|RE|...<cr>
OBR|3|A4461XC^HIS|81643^RAD|73916^Bilateral Knees|...<cr>
OBX|1|CE|73916&IMP|1|Radiologist's Impression|...<cr>
OBX|2|CE|73642&IMP|1|Radiologist's Impression|...<cr>
OBX|3|FT|73642&GDT|1|Description|...<cr>
n) UA
An unable-to-accept code is used when a new order cannot be accepted by the
filler. Possible reasons include requesting a prescription for a drug which
the patient is allergic to or for an order which requires certain equipment
resources which are not available such that the order cannot be filled. Note
that this is different from the communication level acceptance as defined
within the MSA segment.
o) RF
RF accommodates requests by both the filler or the placer. The filler may be
requesting refill authorization from the placer. A placer system may be
requesting a refill to be done by the filler system.
p) AF
AF is a response back from the placer authorizing a refill or quantity of
refills.
q) DF
DF indicates that the placer will not authorize refills for the order. The
order control code reason may be used to indicate the reason for the request
denial. Some suggested values include:
AA |
Patient unknown to the provider |
AB |
Patient never under provider care |
AC |
Patient no longer under provider care |
AD |
Patient has requested refill too soon |
AE |
Medication never prescribed for the patient |
AF |
Patient should contact provider first |
AG |
Refill not appropriate |
Note
that these values originate from the NCPDP SCRIPT Response Segment Code List
Qualifiers.
r) FU
FU notifies the placer that the filler issued a refill for the order at the
patient's request.
s) OF
OF directly responds to the placer system's request for a refill
t) UF
UF indicates an application level denial by the filler system to an authorized
refill request.
u) LI, UN
Use only with Patient Care problems or goals, Chapter 12.
v) PR
PR indicates that this ORC is part of an ORU structure containing previous
observation, which is embedded in the order.
At least two main use cases require that the complete results of the
previous observations be transmitted with the order.
* Diagnostic laboratories referring tests to another lab for either
confirmation of results (HIV, etc.) or due to not being equipped to do the
tests (genetic testing, etc.).
* Diagnostic laboratories sending test results to Knowledge Bases for the
automated generation of diagnostic comments for inclusion into the lab report.
Components:
<entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID
(ST)> ^ <universal ID type (ID)>
Definition: This field is the placer application's order number.
This field is a case of the Entity Identifier data type (See Section 2.8.13,
"EI - Entity Identifier"). The first component is a string that identifies an
individual order (e.g., OBR). A limit of fifteen (15) characters is suggested
but not required. An implementation is HL7 compliant when the number of
characters for this field is increased to accommodate applications that require
a greater number of characters for the Placer order number. It is assigned by
the placer (ordering application). It identifies an order uniquely among all
orders from a particular ordering application. The second through fourth
components contain the application ID of the placing application in the same
form as the HD data type (Section 2.8.18, "HD - Hierarchic designator"). The
second component, namespace ID, is a user-defined coded value that will be
uniquely associated with an application. A limit of six (6) characters is
suggested but not required. A given institution or group of intercommunicating
institutions should establish a unique list of applications that may be
potential placers and fillers and assign unique application IDs. The
components are separated by component delimiters.
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.
The application ID list becomes one of the institution's master dictionary
lists that is documented in Chapter 8. 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:
<entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID
(ST)> ^ <universal ID type (ID)>
Definition: This field is the order number associated with the filling
application. It is a case of the Entity Identifier data type (Section 2.8.13).
Its first component is a string that identifies an order detail segment (e.g.,
OBR). A limit of fifteen (15) characters is suggested but not required. An
implementation is HL7 compliant when the number of characters for this field is
increased to accommodate applications that require a greater number of
characters for the Filler order number. 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 through fourth components contain the filler application ID, in the
form of the HD data type (see Section 2.8.18, "HD - hierarchic designator").
The second component is a user-defined coded value that uniquely defines the
application from other applications on the network. A limit of six (6)
characters is suggested but not required. 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 is documented in
Chapter 8. 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:
<entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID
(ST)> ^ <universal ID type (ID)>
Definition: This field allows an order placing application to group sets of
orders together and subsequently identify them. It is a case of an Entity
Identifier data type (2.8.13).
The first component is a string that uniquely identifies all order groups from
the given placer application. A limit of fifteen (15) characters is suggested
but not required. 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 through fourth components constitute a placer application ID
identical to the analogous components of ORC-2-placer order number.
Order groups and how to use them are described in detail in Section 4.5.1, "PRC
- common order segment."
Definition:
This field specifies the status of an order. Refer to HL7 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 HL7 Table 0038 - Order status contains many of the same
values contained in HL7 Table 0119 - Order control codes and their
meaning, 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.
Value |
Description |
|---|---|
A |
Some, but not all, results available |
CA |
Order was canceled |
CM |
Order is completed |
DC |
Order was discontinued |
ER |
Error, order not found |
HD |
Order is on hold |
IP |
In process, unspecified |
RP |
Order has been replaced |
SC |
In process, scheduled |
Definition:
This field 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 HL7 Table 0121 - Response
flag for valid entries.
Value |
Description |
|---|---|
E |
Report exceptions only |
R |
Same as E, also Replacement and Parent-Child |
D |
Same as R, also other associated segments |
F |
Same as D, plus confirmations explicitly |
N |
Only the MSA segment is returned |
Components:
<quantity (CQ)> ^ <interval (CM)> ^ <duration (ST)> ^
<start date/time (TS)> ^ <end date/time (TS)> ^ <priority
(ST)> ^ <condition (ST)> ^ <text (TX)> ^ <conjunction
(ID)> ^ <order sequencing (CM)> ^ <occurrence duration (CE)> ^
<total occurrences (NM)>
Definition: This field 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.3, "Quantity/Timing (TQ) Definition."
For example, if an OBR segment describes a unit of blood, this field might
request that three (3) such units be given on successive mornings. In this
case ORC-7-quantity/timing would be "1^QAM^X3".
ORC-7-quantity/timing is the same as OBR-27-quantity/timing.
To send information about "collection time", use the `text' component of the TQ
data type in either the ORC-7 or OBR-27.
ORC-7-quantity/timing is the same as OBR-27-quantity/timing. If
the ORC-7 and OBR-27 are both valued, then both should be valued exactly the
same. If the quantity/timing 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.
Components:
<parent's placer order number (EI)> ^ <parent's filler order number
(EI)>
Subcomponents of parent's placer order number: <entity identifier
(ST)> & <namespace ID (IS) & <universal ID (ST)> &
<universal ID type (IS)>
Subcomponents of parent's filler order number: <entity identifier
(ST)> & <namespace ID (IS)> & <universal ID (ST)> &
<universal ID type (IS)>
Definition: This field 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 has the same format as ORC-2-placer order number
(Section 4.5.1.2, "Placer order number (EI) 00216)." The second component
has the same format as ORC-3-filler order number (Section 4.5.1.3,
"Filler order number (EI) 00217)" . 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. If the parent is not
present in the ORC, it must be present in the associated OBR. (This rule is
the same for other identical fields in the ORC and OBR and promotes upward and
ASTM compatibility.) This is particularly important when results are
transmitted in an ORU message. In this case, the ORC is not required and the
identifying filler order number must be present in the OBR segments.
Definition: This field contains the date and time of the event that initiated the current transaction as reflected in ORC-1 Order Control Code. This field is not equivalent to MSH-7 Date and Time of Message which reflects the date/time of the physical message.
Components:
In Version 2.3 and later, use instead of the CN data type. <ID number
(ST)> ^ <family name (FN)> ^ <given name (ST)> ^ <second or
further given names or initials thereof (ST)> ^ <suffix (e.g., JR or III)
(ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (IS)> ^
<source table (IS)> ^ <assigning authority (HD)> ^ <name type
code (ID)> ^ <identifier check digit (ST)> ^ <code identifying the
check digit scheme employed (ID)> ^ <identifier type code (IS)> ^
<assigning facility (HD)> ^ <name representation code (ID)> ^
<name context (CE)> ^ <name validity range (DR)> ^ < name
assembly order (ID)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)
Subcomponents of assigning facility: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)
Definition: This field contains the identity of the person who actually keyed
the request into the application. Note that this refers to the current
transaction as reflected in ORC-1 Order Control Code. 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:
In Version 2.3 and later, use instead of the CN data type. <ID number
(ST)> ^ <family name (FN)> ^ <given name (ST)> ^ <second or
further given names or initials thereof (ST)> ^ <suffix (e.g., JR or III)
(ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (IS)> ^
<source table (IS)> ^ <assigning authority (HD)> ^ <name type
code (ID)> ^ <identifier check digit (ST)> ^ <code identifying the
check digit scheme employed (ID)> ^ <identifier type code (IS)> ^
<assigning facility (HD)> ^ <name representation code (ID)> ^
<name context (CE)> ^ <name validity range (DR)> ^ < name
assembly order (ID)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)
Subcomponents of assigning facility: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)
Definition: This field contains the identity of the person who verified the
accuracy of the entered request. Note that this refers to the current
transaction as reflected in ORC-1 Order Control Code. 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:
In Version 2.3 and later, use instead of the CN data type. <ID number
(ST)> ^ <family name (FN)> ^ <given name (ST)> ^ <second or
further given names or initials thereof (ST)> ^ <suffix (e.g., JR or III)
(ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (IS)> ^
<source table (IS)> ^ <assigning authority (HD)> ^ <name type
code (ID)> ^ <identifier check digit (ST)> ^ <code identifying the
check digit scheme employed (ID)> ^ <identifier type code (IS)> ^
<assigning facility (HD)> ^ <name representation code (ID)> ^
<name context (CE)> ^ <name validity range (DR)> ^ < name
assembly order (ID)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)
Subcomponents of assigning facility: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)
Definition: This field contains the 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.
If the ordering provider 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.
Components:
<point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^
<facility (HD)> ^ <location status (IS)> ^ <person location
type (IS)> ^ <building (IS)> ^ <floor (IS)> ^ <location
description (ST)>
Subcomponents of facility: <namespace ID (IS)> & <universal
ID (ST)> & <universal ID type (ID)
Definition: This field specifies the location (e.g., nurse station, ancillary
service location, clinic, floor) where the person who entered the request was
physically located when the order was entered. Note that this refers to the
current transaction as reflected in ORC-1 Order Control Code. Only
those subcomponents relevant to enterer's location should be valued (commonly
nursing unit; facility; building; floor). The person who entered the request is
defined in ORC-10-entered by.
Components:
[NNN] [(999)]999-9999 [X99999] [B99999] [C any text] ^
<telecommunication use code (ID)> ^ <telecommunication equipment type
(ID)> ^ <email address (ST)> ^ <country code (NM)> ^
<area/city code (NM)> ^ <phone number (NM)> ^ <extension
(NM)> ^ <any text (ST)>
Definition: This field contains the telephone number to call for clarification
of a request or other information regarding the order. ORC-14-call back
phone number is the same as OBR-17-order callback phone number.
Definition:
This field contains the date/time that the changes to the request took effect
or are supposed to take effect.
If ORC-9-date/time of transaction is after or equal to ORC-15-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-date/time of transaction 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-date/time of transaction or
MSH-7-date/time of message if the transaction date/time is blank.
In the case where the time specified in ORC-15-order 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 (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the explanation (either in coded or text form)
of the reason for the order event described by the order control code
(HL7 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 (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field identifies the organization that the enterer belonged
to at the time he/she enters/maintains the order, such as medical group or
department. The person who entered the request is defined in ORC-10
-entered by.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field identifies the physical device (terminal, PC) used to
enter the order.
Components:
In Version 2.3 and later, use instead of the CN data type. <ID number
(ST)> ^ <family name (FN)> ^ <given name (ST)> ^ <second or
further given names or initials thereof (ST)> ^ <suffix (e.g., JR or III)
(ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (IS)> ^
<source table (IS)> ^ <assigning authority (HD)> ^ <name type
code (ID)> ^ <identifier check digit (ST)> ^ <code identifying the
check digit scheme employed (ID)> ^ <identifier type code (IS)> ^
<assigning facility (HD)> ^ <name representation code (ID)> ^
<name context (CE)> ^ <name validity range (DR)> ^ < name
assembly order (ID)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)
Subcomponents of assigning facility: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)
Definition: This field contains the 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. This person is typically a care
provider but may not always be the same as ORC-12 ordering provider.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field indicates the status of the patient's or the patient's
representative's consent for responsibility to pay for potentially uninsured
services. This element is introduced to satisfy HCFA Medical Necessity
requirements for outpatient services. This element indicates (a) whether the
associated diagnosis codes for the service are subject to medical necessity
procedures, (b) whether, for this type of service, the patient has been
informed that they may be responsible for payment for the service, and (c)
whether the patient agrees to be billed for this service. The values for this
field are drawn from User-defined Table 0339 - Advanced
beneficiary notice code.
Value |
Description |
|---|---|
1 |
Service is subject to medical necessity procedures |
2 |
Patient has been informed of responsibility, and agrees to pay for service |
3 |
Patient has been informed of responsibility, and asks that the payer be billed |
4 |
Advanced Beneficiary Notice has not been signed |
Components:
<organization name (ST)> ^ <organization name type code (IS)> ^
<ID Number (NM)> ^ <check digit (NM)> ^ <code identifying the
check digit scheme employed (ID)> ^ <assigning authority (HD)> ^
<identifier type code (IS)> ^ <assigning facility ID (HD)> ^
<name representation code (ID)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Definition: This field contains the name of the facility placing the order.
Components:
In Version 2.3 and later, replaces the AD data type. <street address
(SAD)> ^ <other designation (ST)> ^ <city (ST)> ^ <state or
province (ST)> ^ <zip or postal code (ST)> ^ <country (ID)> ^
< address type (ID)> ^ <other geographic designation (ST)>
^ <county/parish code (IS)> ^ <census tract (IS)> ^
<address representation code (ID)> ^ <address validity range
(DR)>
Definition: This field contains the address of the facility placing the order.
Components:
[NNN] [(999)]999-9999 [X99999] [B99999] [C any text] ^
<telecommunication use code (ID)> ^ <telecommunication equipment type
(ID)> ^ <email address (ST)> ^ <country code (NM)> ^
<area/city code (NM)> ^ <phone number (NM)> ^ <extension
(NM)> ^ <any text (ST)>
Definition: This field contains the telephone number of the facility placing
the order.
Components:
In Version 2.3 and later, replaces the AD data type. <street address
(SAD)> ^ <other designation (ST)> ^ <city (ST)> ^ <state or
province (ST)> ^ <zip or postal code (ST)> ^ <country (ID)> ^
< address type (ID)> ^ <other geographic designation (ST)>
^ <county/parish code (IS)> ^ <census tract (IS)> ^
<address representation code (ID)> ^ <address validity range
(DR)>
Definition: This field contains the address of the care provider requesting
the order.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)> ^ <coding system version ID
(ST)> ^ alternate coding system version ID (ST)> ^ <original text
(ST)>
Definition: This field is a modifier or refiner of the ORC-5-Order status
field. This field may be used to provide additional levels of specificity
or additional information for the defined order status codes. Unlike the Order
Status field, which is controlled by an HL7 defined table, this field is a CE
data type allowing applications to support an unlimited library of Order Status
Modifier codes.
Usage Rule: This field may only be populated if the ORC-5-Order Status field is
valued.
Examples: An LIS is processing an order with an order status of IP may send an
update using the order status modifier to indicate the progress of the order
through the laboratory or to indicate that the order has been sent to an
external laboratory. Another example using the non-medical orders would be
where a phone has been ordered delivered to a patient's room, but has been
disconnected temporarily. The ORC-5-Order status indicates IP and the
ORC-25-Order status modifier would indicate a disconnected status. A
third example involves pharmacy dispenses. It is sometimes not enough to know
the prescription is being dispensed. The ORC-25-Order status modifier
would indicate if a label had been printed, the prescription filled, or the
prescription sold.
The
BLG segment is used to provide billing information, on the ordered service, to
the filling application.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
40 |
CM |
O |
0100 |
00234 |
When to Charge |
|
2 |
50 |
ID |
O |
0122 |
00235 |
Charge Type |
|
3 |
100 |
CX |
O |
00236 |
Account ID |
Components:
<when to charge code (ID)> ^ <date/time (TS)>
Definition: This field specifies when to charge for the ordered service. The
first component contains a value defined in HL7 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 |
O |
On receipt of order |
R |
At time service is completed |
S |
At time service is started |
T |
At a designated date/time |
Definition:
This field identifies someone or something other than the patient to be billed
for this service. It is used in conjunction with BLG-3-account ID.
Refer to HL7 Table 0122 - Charge type for valid values.
Value |
Description |
|---|---|
CH |
Charge |
CO |
Contract |
CR |
Credit |
DP |
Department |
GR |
Grant |
NC |
No Charge |
PC |
Professional |
RS |
Research |
Components:
<ID (ST)> ^ <check digit (ST)> ^ <code identifying the check
digit scheme employed (ID)> ^ < assigning authority (HD)> ^
<identifier type code (ID)> ^ < assigning facility (HD) ^
<effective date (DT)> ^ <expiration date (DT)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)
Subcomponents of assigning facility: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)
Definition: This field identifies the account to be billed. It is used in
conjunction with BLG-2-charge type. Refer to HL7 table 0061 -
Check digit scheme in Chapter 2.
General
(taken from ASTM E1238)
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 X-ray, 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 |
OPT |
RP/# |
TBL# |
ITEM # |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
4 |
SI |
O |
00237 |
Set ID - OBR |
||
2 |
22 |
EI |
C |
00216 |
Placer Order Number |
||
3 |
22 |
EI |
C |
00217 |
Filler Order Number |
||
4 |
250 |
CE |
R |
00238 |
Universal Service Identifier |
||
5 |
2 |
ID |
B |
00239 |
Priority - OBR |
||
6 |
26 |
TS |
B |
00240 |
Requested Date/Time |
||
7 |
26 |
TS |
C |
00241 |
Observation Date/Time # |
||
8 |
26 |
TS |
O |
00242 |
Observation End Date/Time # |
||
9 |
20 |
CQ |
O |
00243 |
Collection Volume * |
||
10 |
250 |
XCN |
O |
Y |
00244 |
Collector Identifier * |
|
11 |
1 |
ID |
O |
0065 |
00245 |
Specimen Action Code * |
|
12 |
250 |
CE |
O |
00246 |
Danger Code |
||
13 |
300 |
ST |
O |
00247 |
Relevant Clinical Information |
||
14 |
26 |
TS |
C |
00248 |
Specimen Received Date/Time * |
||
15 |
300 |
CM |
O |
0070/ 0163/ 0 369 |
00249 |
Specimen Source |
|
16 |
250 |
XCN |
O |
Y |
00226 |
Ordering Provider |
|
17 |
250 |
XTN |
O |
Y/2 |
00250 |
Order Callback Phone Number |
|
18 |
60 |
ST |
O |
00251 |
Placer Field 1 |
||
19 |
60 |
ST |
O |
00252 |
Placer Field 2 |
||
20 |
60 |
ST |
O |
00253 |
Filler Field 1 + |
||
21 |
60 |
ST |
O |
00254 |
Filler Field 2 + |
||
22 |
26 |
TS |
C |
00255 |
Results Rpt/Status Chng - Date/Time + |
||
23 |
40 |
CM |
O |
00256 |
Charge to Practice + |
||
24 |
10 |
ID |
O |
0074 |
00257 |
Diagnostic Serv Sect ID |
|
25 |
1 |
ID |
C |
0123 |
00258 |
Result Status + |
|
26 |
400 |
CM |
O |
00259 |
Parent Result + |
||
27 |
200 |
TQ |
O |
Y |
00221 |
Quantity/Timing |
|
28 |
250 |
XCN |
O |
Y/5 |
00260 |
Result Copies To |
|
29 |
200 |
CM |
O |
00222 |
Parent |
||
30 |
20 |
ID |
O |
0124 |
00262 |
Transportation Mode |
|
31 |
250 |
CE |
O |
Y |
00263 |
Reason for Study |
|
32 |
200 |
CM |
O |
00264 |
Principal Result Interpreter + |
||
33 |
200 |
CM |
O |
Y |
00265 |
Assistant Result Interpreter + |
|
34 |
200 |
CM |
O |
Y |
00266 |
Technician + |
|
35 |
200 |
CM |
O |
Y |
00267 |
Transcriptionist + |
|
36 |
26 |
TS |
O |
00268 |
Scheduled Date/Time + |
||
37 |
4 |
NM |
O |
01028 |
Number of Sample Containers * |
||
38 |
250 |
CE |
O |
Y |
01029 |
Transport Logistics of Collected Sample * |
|
39 |
250 |
CE |
O |
Y |
01030 |
Collector's Comment * |
|
40 |
250 |
CE |
O |
01031 |
Transport Arrangement Responsibility |
||
41 |
30 |
ID |
O |
0224 |
01032 |
Transport Arranged |
|
42 |
1 |
ID |
O |
0225 |
01033 |
Escort Required |
|
43 |
250 |
CE |
O |
Y |
01034 |
Planned Patient Transport Comment |
|
44 |
250 |
CE |
O |
0088 |
00393 |
Procedure Code |
|
45 |
250 |
CE |
O |
Y |
0340 |
01316 |
Procedure Code Modifier |
46 |
250 |
CE |
O |
Y |
0411 |
01474 |
Placer Supplemental Service Information |
47 |
250 |
CE |
O |
Y |
0411 |
01475 |
Filler Supplemental Service Information |
The
daggered (+) items in this segment are known to the filler, not the placer.
They are valued by the filler as needed when the OBR segment is returned as
part of a report.
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
(e.g., BP, Chest X-ray), 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:
<entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID
(ST)> ^ <universal ID type (ID)>
Definition: This field is identical to ORC-2-placer order number.
This field is a special case of the Entity Identifier data type (Section
2.8.13). The first component is a string that identifies an individual order
(e.g., OBR). A limit of fifteen (15) characters is suggested but not required.
It is assigned by the placer (ordering application). An implementation is HL7
compliant when the number of characters for this field is increased to
accommodate applications that require a greater number of characters for the
Placer order number. It identifies an order uniquely among all orders from a
particular ordering application. The second through fourth components contain
the application ID of the placing application in the same form as the HD data
type (Section 2.8.18, "HD - Hierarchic designator"). The second component,
namespace ID, is a user-defined coded value that will be uniquely associated
with an application. A limit of six (6) characters is suggested but not
required. A given institution or group of intercommunicating institutions
should establish a unique list of applications that may be potential placers
and fillers and assign unique application IDs. The components are separated by
component delimiters.
See ORC-2-placer order number (Section 4.5.1.2) for information on when
this field must be valued.
Components:
<entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID
(ST)> ^ <universal ID type (ID)>
Definition: This is a permanent identifier for an order and its associated
observations. It is a special case of the Entity Identifier data type (see
Chapter 2, Section 2.9.17, "EI - entity identifier").
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). A limit of fifteen (15) characters is
suggested but not required.
The second through fourth components contain the filler application ID, in the
form of the HD data type (see Section 2.8.18, "HD - hierarchic designator").
The second component is a user-defined coded value that uniquely defines the
application from other applications on the network. A limit of six (6)
characters is suggested but not required. The second component of the filler
order number always identifies the actual filler of an order.
A limit of fifteen (15) characters is suggested but not required. An
implementation is HL7 compliant when the number of characters for this field is
increased to accommodate applications that require a greater number of
characters for the Filler order number.
See ORC-3-filler order number for information on when this field must be
valued.
OBR-3-filler order number is identical to ORC-3-filler order
number.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the 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: This field has been retained for backward compatibility only. It is not used. Previously priority (e.g., STAT, ASAP), but this information is carried as the sixth component of OBR-27-quantity/timing.
Definition: This field has been retained for backward compatibility only. It is not used. Previously requested date/time. This information is now carried in the fourth component of the OBR-27-quantity/timing.
Definition: This field is the 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.) This field is conditionally required. When the OBR is transmitted as part of a report message, the field must be filled in. If it is transmitted as part of a request and a sample has been sent along as part of the request, this field must be filled in because this specimen time is the physiologically relevant date/time of the observation.
Definition: This field contains the 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 (NM)> ^ <units (CE)>
Subcomponents of units: <identifier (ST)> & <text (ST)>
& <name of coding system (IS)> & <alternate identifier
(ST)> & <alternate text (ST)> & <name of alternate coding
system (IS)>
Definition: For laboratory tests, the collection volume is 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:
In Version 2.3 and later, use instead of the CN data type. <ID number
(ST)> ^ <family name (FN)> ^ <given name (ST)> ^ <second or
further given names or initials thereof (ST)> ^ <suffix (e.g., JR or III)
(ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (IS)> ^
<source table (IS)> ^ <assigning authority (HD)> ^ <name type
code (ID)> ^ <identifier check digit (ST)> ^ <code identifying the
check digit scheme employed (ID)> ^ <identifier type code (IS)> ^
<assigning facility (HD)> ^ <name representation code (ID)> ^
<name context (CE)> ^ <name validity range (DR)> ^ < name
assembly order (ID)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)
Subcomponents of assigning facility: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)
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:
This field identifies the 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 HL7 Table
0065 - Specimen action code for valid values.
Value |
Description |
|---|---|
A |
Add ordered tests to the existing specimen |
G |
Generated order; reflex order |
L |
Lab to obtain specimen from patient |
O |
Specimen obtained by service other than Lab |
P |
Pending specimen; Order sent prior to delivery |
R |
Revised order |
S |
Schedule the tests specified below |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the 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: This field contains the additional clinical information about the patient or specimen. 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 specimen received date/time is the actual login time at the diagnostic service. This field must contain a value when the order is accompanied by a specimen, or when the observation required a specimen and the message is a report.
Components:
<specimen source name or code (CE)> ^ <additives (TX)> ^
<freetext (TX)> ^ <body site (CE)> ^ <site modifier (CE)> ^
<collection method modifier code (CE)> ^ <specimen role
(CE)>
Subcomponents of specimen source name or role: <identifier (ST)>
& <test (ST)> & <name of coding system (IS)> &
<alternate identifier (ST)> & <alternate text (ST)> &
<name of alternate coding system (ST)>
Subcomponents of body site: <identifier (ST)> & <test (ST)>
& <name of coding system (IS)> & <alternate identifier
(ST)> & <alternate text (ST)> & <name of alternate coding
system (ST)>
Subcomponents of site modifier: <identifier (ST)> & <test
(ST)> & <name of coding system (IS)> & <alternate
identifier (ST)> & <alternate text (ST)> & <name of
alternate coding system (ST)>
Subcomponents of collection method modifier code: <identifier (ST)>
& <test (ST)> & <name of coding system (IS)> &
<alternate identifier (ST)> & <alternate text (ST)> &
<name of alternate coding system (ST)>
Subcomponents of specimen role: <identifier (ST)> & <test
(ST)> & <name of coding system (IS)> & <alternate
identifier (ST)> & <alternate text (ST)> & <name of
alternate coding system (ST)>
Definition: This field identifies the 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.) Refer
to HL7 Table 0070 - Specimen source codes for valid
entries.
The second component should include free text 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
antecubital fossa, and the site modifier "right." The components of the CE
fields become subcomponents. Refer to HL7 Table 0163 - Body site
for valid entries.
Value |
Description |
|---|---|
BE |
Bilateral Ears |
OU |
Bilateral Eyes |
BN |
Bilateral Nares |
BU |
Buttock |
CT |
Chest Tube |
LA |
Left Arm |
LAC |
Left Anterior Chest |
LACF |
Left Antecubital Fossa |
LD |
Left Deltoid |
LE |
Left Ear |
LEJ |
Left External Jugular |
OS |
Left Eye |
LF |
Left Foot |
LG |
Left Gluteus Medius |
LH |
Left Hand |
LIJ |
Left Internal Jugular |
LLAQ |
Left Lower Abd Quadrant |
LLFA |
Left Lower Forearm |
LMFA |
Left Mid Forearm |
LN |
Left Naris |
LPC |
Left Posterior Chest |
LSC |
Left Subclavian |
LT |
Left Thigh |
LUA |
Left Upper Arm |
LUAQ |
Left Upper Abd Quadrant |
LUFA |
Left Upper Forearm |
LVG |
Left Ventragluteal |
LVL |
Left Vastus Lateralis |
NB |
Nebulized |
PA |
Perianal |
PERIN |
Perineal |
RA |
Right Arm |
RAC |
Right Anterior Chest |
RACF |
Right Antecubital Fossa |
RD |
Right Deltoid |
RE |
Right Ear |
REJ |
Right External Jugular |
OD |
Right Eye |
RF |
Right Foot |
RG |
Right Gluteus Medius |
RH |
Right Hand |
RIJ |
Right Internal Jugular |
RLAQ |
Rt Lower Abd Quadrant |
RLFA |
Right Lower Forearm |
RMFA |
Right Mid Forearm |
RN |
Right Naris |
RPC |
Right Posterior Chest |
RSC |
Right Subclavian |
RT |
Right Thigh |
RUA |
Right Upper Arm |
RUAQ |
Right Upper Abd Quadrant |
RUFA |
Right Upper Forearm |
RVL |
Right Vastus Lateralis |
RVG |
Right Ventragluteal |
The
fifth component indicates whether the specimen is frozen as part of the
collection method. Suggested values are F (Frozen); R (Refrigerated). If the
component is blank, the specimen is assumed to be at room temperature.
Refer to section 4.19.2 for the contents of the HL7 Table 0070 Specimen
source codes
The 7th component indicates the role of the sample. Refer to
User-defined Table
0369
- Specime
n
Role for suggested values. Each of these values is normally
identifiable by the systems and its components and can influence processing and
data management related to the specimen.
This is a user-defined table with following recommended values. If the value
is blank, it is assumed to be a patient specimen.
Value |
Description |
P |
Patient (default if blank component value) |
Q |
Control specimen |
C |
Calibrator |
B |
Blind Sample |
R |
Replicate (of patient sample as a control) |
Components:
In Version 2.3 and later, use instead of the CN data type. <ID number
(ST)> ^ <family name (FN)> ^ <given name (ST)> ^ <second or
further given names or initials thereof (ST)> ^ <suffix (e.g., JR or III)
(ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (IS)> ^
<source table (IS)> ^ <assigning authority (HD)> ^ <name type
code (ID)> ^ <identifier check digit (ST)> ^ <code identifying the
check digit scheme employed (ID)> ^ <identifier type code (IS)> ^
<assigning facility (HD)> ^ <name representation code (ID)> ^
<name context (CE)> ^ <name validity range (DR)> ^ < name
assembly order (ID)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)
Subcomponents of assigning facility: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)
Definition: This field identifies 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.
Components:
[NNN] [(999)]999-9999 [X99999] [B99999] [C any text] ^
<telecommunication use code (ID)> ^ <telecommunication equipment type
(ID)> ^ <email address (ST)> ^ <country code (NM)> ^
<area/city code (NM)> ^ <phone number (NM)> ^ <extension
(NM)> ^ <any text (ST)>
Definition: This field contains the telephone number for reporting a status or
a result using the standard format with extension and/or beeper number when
applicable.
Definition: This field is user field #1. Text sent by the placer will be returned with the results.
Definition: This field is similar to placer field #1.
Definition: This field is definable for any use by the filler (diagnostic service).
Definition: This field is similar to filler field #1.
Definition: This field specifies the date/time when the results were 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 ORC-5 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 (MO)> ^ <charge code (CE)>
Subcomponents of dollar amount: <quantity (NM)> &
<denomination (ID)>
Subcomponents of charge code: <identifier (ST)> & <test
(ST)> & <name of coding system (IS)> & <alternate
identifier (ST)> & <alternate text (ST)> & <name of
alternate coding system (ST)>
Definition: This field is the 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:
This field is the 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
HL7
Table 0074 - Diagnostic service section ID for valid entries.
Value |
Description |
Value |
Description |
|---|---|---|---|
AU |
Audiology |
OUS |
OB Ultrasound |
BG |
Blood Gases |
OT |
Occupational Therapy |
BLB |
Blood Bank |
OTH |
Other |
CUS |
Cardiac Ultrasound |
OSL |
Outside Lab |
CTH |
Cardiac Catheterization |
PHR |
Pharmacy |
CT |
CAT Scan |
PT |
Physical Therapy |
CH |
Chemistry |
PHY |
Physician (Hx. Dx, admission note, etc.) |
CP |
Cytopathology |
PF |
Pulmonary Function |
EC |
Electrocardiac (e.g., EKG, EEC, Holter) |
RAD |
Radiology |
EN |
Electroneuro (EEG, EMG,EP,PSG) |
RX |
Radiograph |
HM |
Hematology |
RUS |
Radiology Ultrasound |
ICU |
Bedside ICU Monitoring |
RC |
Respiratory Care (therapy) |
IMM |
Immunology |
RT |
Radiation Therapy |
LAB |
Laboratory |
SR |
Serology |
MB |
Microbiology |
SP |
Surgical Pathology |
MCB |
Mycobacteriology |
TX |
Toxicology |
MYC |
Mycology |
VUS |
Vascular Ultrasound |
NMS |
Nuclear Medicine Scan |
VR |
Virology |
NMR |
Nuclear Magnetic Resonance |
XRC |
Cineradiograph |
NRS |
Nursing Service Measures |
Definition:
This field contains the status of results for this order. This conditional
field is required whenever the OBR is contained in a report message. It is not
required as part of an initial order.
There are two methods of sending status information. If the status is that of
the entire order, use ORC-15-order effective date/time and
ORC-5-order status. If the status pertains to the order detail segment,
use OBR-25-result status and OBR-22-results rpt/status chng -
date/time. If both are present, the OBR values override the ORC values.
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. When the
individual status of each result is necessary, OBX-11-observ result
status may be used. Refer to HL7 table 0123 - Result status
for valid entries.
Value |
Description |
Value |
Description |
|---|---|---|---|
O |
Order received; specimen not yet received |
R |
Results stored; not yet verified |
I |
No results available; specimen received, procedure incomplete |
F |
Final results; results stored and verified. Can only be changed with a corrected result. |
S |
No results available; procedure scheduled, but not done |
X |
No results available; Order canceled. |
A |
Some, but not all, results available |
Y |
No order on record for this test. (Used only on queries) |
P |
Preliminary: A verified early result is available, final results not yet obtained |
Z |
No record of this patient. (Used only on queries) |
C |
Correction to results |
Components:
<OBX-3-observation identifier of parent result (CE)> ^ <OBX-4-sub-ID
of parent result (ST)> ^ <part of OBX-5 observation result from parent
(TX)see discussion>
Subcomponents of OBX-3-observation identifier of parent result:
<identifier (ST)> & <test (ST)> & <name of coding system
(IS)> & <alternate identifier (ST)> & <alternate text
(ST)> & <name of alternate coding system (ST)>
Definition: This field is defined to make it available for other types of
linkages (e.g., toxicology). This important information, together with the
information in OBR-29-parent, 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.
For example, if the current battery is an antimicrobial susceptibility, the
parent results identified OBX contains a result which identifies the organism
on which the susceptibility was 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.
We emphasize that this field does not take the entire result field from the
parent. It is meant only for the text name of the organism or chemical
subspecies identified. This field is included only to provide a method for
linking back to the parent result for those systems that could not generate
unambiguous Observation IDs and sub-IDs.
This field is present only when the parent result is identified by
OBR-29-parent and the parent spawns child orders for each of many
results. (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-observation sub-ID 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 susceptibility values for a
given antimicrobial test on this organism.
Components:
<quantity (CQ)> ^ <interval (CM)> ^ <duration (ST)> ^
<start date/time (TS)> ^ <end date/time (TS)> ^ <priority
(ST)> ^ <condition (ST)> ^ <text (TX)> ^ <conjunction
(ID)> ^ <order sequencing (CM)> ^ <occurrence duration (CE)> ^
<total occurrences(NM)>
Definition: This field contains 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.3, "Quantity/Timing (TQ) Data Type D."
Components:
In Version 2.3 and later, use instead of the CN data type. <ID number
(ST)> ^ <family name (FN)> ^ <given name (ST)> ^ <second or
further given names or initials thereof (ST)> ^ <suffix (e.g., JR or III)
(ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (IS)> ^
<source table (IS)> ^ <assigning authority (HD)> ^ <name type
code (ID)> ^ <identifier check digit (ST)> ^ <code identifying the
check digit scheme employed (ID)> ^ <identifier type code (IS)> ^
<assigning facility (HD)> ^ <name representation code (ID)> ^
<name context (CE)> ^ <name validity range (DR)> ^ < name
assembly order (ID)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)
Subcomponents of assigning facility: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)
Definition: This field identifies the 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 (EI)> ^ <parent's filler order number
(EI)>
Subcomponents of parent's placer order number: <entity identifier
(ST)> & <namespace ID (IS)> & <universal ID (ST)> &
<universal ID type (IS)>
Subcomponents of parent's filler order number: <entity identifier
(ST)> & <namespace ID (IS)> & <universal ID (ST)> &
<universal ID type (IS)>
Definition: This field is 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.,
antimicrobial 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 Section 4.5.1.1.1, "Table
notes for order control codes of ORC"). It is required when the order is a
child.
Parent is a two-component field. The components of the placer order number and
the filler order number are transmitted in subcomponents of the two components
of this field.
Definition:
This field identifies how (or whether) to transport a patient, when
applicable. Refer to HL7 Table 0124 - Transportation mode for
valid codes.
Value |
Description |
|---|---|
CART |
Cart - patient travels on cart or gurney |
PORT |
The examining device goes to patient's location |
WALK |
Patient walks to diagnostic service |
WHLC |
Wheelchair |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field is the code or text using the conventions for coded
fields given in the Control chapter (Chapter 2). This is required for some
studies to obtain proper reimbursement.
Components:
<name (CN)> ^ <start date/time (TS)> ^ <end date/time (TS)> ^
<point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^
<facility (HD)> ^ <location status (IS)> ^ <patient location
type (IS)> ^ <building (IS)> ^ <floor (IS)>
Subcomponents of name: <ID number (ST)> & <family name
(ST)> & <given name (ST)> & <middle initial or name
(ST)> & <suffix (e.g., JR or III) (ST)> & <prefix (e.g.,
DR) (ST)> & <degree (e.g., MD (ST)> & <source table
(IS)> & <assigning authority (HD)>
Subcomponents of facility: <namespace ID (IS)> & <universal
ID (ST)> & <universal ID type (ID)>
Definition: This field identifies the physician or other clinician who
interpreted the observation and is responsible for the report content.
Components:
<name (CN)> ^ <start date/time (TS)> ^ <end date/time (TS)> ^
<point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^
<facility (HD)> ^ <location status (IS)> ^ <patient location
type (IS)> ^ <building (IS)> ^ <floor (IS)>
Subcomponents of name: <identifier(ST)> & <test (ST)>
& <name of coding system (IS)> & <alternate identifier
(ST)> & <alternate text (ST)> & <name of alternate coding
system (ST)>
Subcomponents of facility: <namespace ID (IS)> & <universal
ID (ST)> & <universal ID type (ID)>
Definition: This field identifies the clinical observer who assisted with the
interpretation of this study.
Components:
<name (CN)> ^ <start date/time (TS)> ^ <end date/time (TS)> ^
<point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^
<facility (HD)> ^ <location status (IS)> ^ <patient location
type (IS)> ^ <building (IS)> ^ <floor (IS)>
Subcomponents of name: <identifier(ST)> & <test (ST)>
& <name of coding system (IS)> & <alternate identifier
(ST)> & <alternate text (ST)> & <name of alternate coding
system (ST)>
Subcomponents of facility: <namespace ID (IS)> & <universal
ID (ST)> & <universal ID type (ID)>
Definition: This field identifies the performing technician.
Components:
<name (CN)> ^ <start date/time (TS)> ^ <end date/time (TS)> ^
<point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^
<facility (HD)> ^ <location status (IS)> ^ <patient location
type (IS)> ^ <building (IS)> ^ <floor (IS)>
Subcomponents of name: <identifier(ST)> & <test (ST)>
& <name of coding system (IS)> & <alternate identifier
(ST)> & <alternate text (ST)> & <name of alternate coding
system (ST)>
Subcomponents of facility: <namespace ID (IS)> & <universal
ID (ST)> & <universal ID type (ID)>
Definition: This field identifies the report transcriber.
Definition: This field is the 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).
Definition: This field identifies the number of containers for a given sample. For sample receipt verification purposes; may be different from the total number of samples which accompany the order.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field is the means by which a sample reaches the diagnostic
service provider. This information is to aid the lab in scheduling or
interpretation of results. Possible answers: routine transport van, public
postal service, etc. If coded, requires a user-defined table.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field is for reporting additional comments related to the
sample. If coded, requires a user-defined table. If only free text is
reported, it is placed in the second component with a null in the first
component, e.g., ""^difficult clotting after venipuncture and
ecchymosis.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field is an indicator of who is responsible for arranging
transport to the planned diagnostic service. Examples: Requester, Provider,
Patient. If coded, requires a user-defined table.
Definition:
This field is an indicator of whether transport arrangements are known to have
been made. Refer to HL7 Table 0224 - Transport arranged
for valid codes.
Value |
Description |
|---|---|
A |
Arranged |
N |
Not Arranged |
U |
Unknown |
Definition:
This field is an indicator that the patient needs to be escorted to the
diagnostic service department. Note: The nature of the escort requirements
should be stated in OBR-43-planned patient transport
comment. See HL7 Table 0225 - Escort required for valid values.
Value |
Description |
|---|---|
R |
Required |
N |
Not Required |
U |
Unknown |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field is the code or free text comments on special
requirements for the transport of the patient to the diagnostic service
department. If coded, requires a user-defined table.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains a unique identifier assigned to the procedure,
if any, associated with the Universal Service ID reported in field 4.
User-defined table 0088 - Procedure code is used as the HL7 identifier for
the user-defined table of values for this field. This field is a CE data
type for compatibility with clinical and ancillary systems. This field will
contain the HCPCS code associated with the order.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the procedure code modifier to the procedure
code reported in field 44, when applicable. Procedure code modifiers are
defined by regulatory agencies such as HCFA and the AMA. Multiple modifiers
may be reported. Refer to user-defined table 0340 - Procedure code
modifier for suggested values.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains supplemental service information sent from the
placer system to the filler system for the universal procedure code reported in
OBR-4 Universal Service ID. This field will be used to provide ordering
information detail that is not available in other, specific fields in the OBR
segment. Multiple supplemental service information elements may be reported.
Refer to User-defined Table 0411 - Supplemental service information
values.
This field can be used to describe details such as whether study is to be done
on the right or left, for example where the study is of the arm and the order
master file does not distinguish right from left or whether the study is to be
done with or without contrast (when the order master file does not make such
distinctions).
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains supplemental service information sent from the
filler system to the placer system for the procedure code reported in OBR-4
Universal Service ID. This field will be used to report ordering
information details that is not available in other, specific fields in the OBR
segment. Typically it will reflect the same information as was sent to the
filler system in OBR-46-Placer supplemental information unless the
order was modified in which case the filler system will report what was
actually performed using this field. Multiple supplemental service information
elements may be reported. Refer to User-defined Table 0411 -
Supplemental service information values.
This field can be used to describe details such as whether study is to be done
on the right or left, for example where the study is of the arm and the order
master file does not distinguish right from left or whether the study is to be
done with or without contrast (when the order master file does not make such
distinctions).
Value |
Description |
|---|---|
No
suggested values |
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|...<cr>
PID|...<cr>
ORC|NW|A226677^PC||946281^PC||N|3^QAM||198801121132|P123^AQITANE^ELLINORE^""^""^""^MD|||4EAST|...<cr>
// EKG order
OBR|1|||8601-7^EKG
IMPRESSION^LN||||||||||||P030^SMITH^MARTIN^""^""^""^MD|||||||||||3^QAM|...<cr>
BLG|...<cr>
ORC|NW|...<cr>
// 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|...<cr>
MSA|...<cr>
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|...<cr>
MSA|...<cr>
ORC|PA|A226677^PC|89-458^EKG|946281^PC<cr>
ORC|CH|A226677^PC|89-551^EKG|946281...<cr> // 1ST child ORC.
ORC|CH|A226677^PC|89-552^EKG|946281...<cr> // 2ND child ORC.
ORC|CH|A226677^PC|89-553^EKG|946281...<cr> // 3RD child ORC.
... // Other parts of 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 order 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|...<cr>
MSA|...<cr>
ORC|PA|A226677^PC|89-458^EKG<cr>
ORC|CH|A226677^PC|89-551^EKG|946281^PC|SC|||A226677&PC^89-458&EKG|
... ^^^^198901130500^...<cr>
// 1ST child ORC
OBR|1||89-551^EKG|8601-7^EKG IMPRESSION^LN|...<cr>
// 1ST child OBR
ORC|CH|A226677^PC|89-522^EKG|946281^PC|SC|||A226677&PC^89-458&EKG|
... ^^^^198901140500^...<cr>
// 2ND child ORC
OBR|2||89-552^EKG|8601-7^EKG IMPRESSION^LN|...<cr>
// 2ND child OBR
ORC|CH|A226677^PC|89-553^EKG|946281^PC|SC|||A226677&PC^89-458&EKG|
...^^^^198901150500^...<cr>
// 3RD child ORC
OBR|3||89-553^EKG|8601-7^EKG IMPRESSION^LN|... <cr>
// 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-7-quantity/timing shows that the EKGs are requested after 0500 on
successive days.
The
ORM message can be used for various types of orders. The following examples
show how the ORM/ORR messages can be used to order non-medical services. The
patient requests hospital specific services for a certain period of time. This
can be a phone, fax, or TV in the room, or the delivery of a newspaper every
day. Another example may be the use of specialized chip cards that give access
to hospital specific services. Typically, a request for these services is made
at the time of admission. Another example may be the printing of a form (e.g.
the receipt for a payment). In case of using phones it might be a detailed
list of calls for a patient or for a special extension.
To support these scenarios, the following fields are used to communicate the
appropriate message:
Segment/ Field |
Definition |
ORC-1 |
Order Control |
ORC-2 |
Placer Order Number |
ORC-5 |
Order Status |
ORC-7.4 |
Start Date/Time |
ORC-7.5 |
End Date/Time |
ORC-16 |
Order Control Code Reason |
ORC-25 |
Order Status Modifier |
OBR-4 |
Universal Service ID |
OBX-5 |
Observation Value |
FT1-17 |
Fee Schedule |
FT1-11 |
Transaction amount - extended |
BLG |
Billing segment |
*
ORC-1, ORC-2, OBR-4, OBX-5
These services can be started, discontinued,
canceled, locked etc. according to the ORC-1- Order control code. The
order is identified through ORC-2- Placer order number. The service
itself is specified in the field OBR-4- Universal service ID. User
defined codes are used to identify the specific services. The identification
of the object of the service, e.g., phone number or card number, is done using
the OBX-5- Observation value. The ORC-25-Order Status Modifier is used
to refine the status of the universal service ID. For example, in the case of
issuing chip cards, these fields would be valued as follows:
ORC-1 |
OBR-4 (in textual form) |
ORC-16.1 Code |
Description |
NW |
chip card |
Issue a chip card the first time |
|
XO |
chip card |
defective |
Change the previous order. Issue a new chip card for a defective one. |
XO |
chip card |
lost |
Change the previous order. Issue a new chip card for a defective one. |
DC |
Return chip card |
Cancel the chip card order |
|
DC |
Return chip card |
lost |
Cancel the chip card order because lost. |
DC |
Return chip card |
defective |
Cancel the chip card order because defective. |
Use of different universal service IDs allows for the ability to charge
an additional fee.
* ORC-7
The field ORC-7-: Quantity/timing describe time periods
during which the requested service is valid. The components 4 and 5 denote the
start and end date/time.
* ORC-5
In this field information on the status of the service can be
transmitted. This field can be used in particular in response to a query
message.
* ORC-25
This field allows for refining the status of the requested
universal service, e.g. to change an order for a chip card in order to
distribute a new card for a lost one.
* BLG-1,2,3
These fields indicate to the financial system that charges are
to be invoiced for this service.
* FT1-17
In some cases it is necessary that the placer defines a special
tariff the filler has to use for computing the final balance.
* FT1-11
In combination with the tariff the patient can prepay the ordered
service. This may be helpful when the patient uses services provided by the
hospital in order to use the service from the beginning. FT1-6 must be valued
at "PY".
If no amount is prepaid a limit can be established according to a
special tariff. This depends on the setup of the filling system. In such a case
the hospital grants a credit to the patient.
Phone Number Assignment
In case the patient requests a bedside phone and the number of this phone is
assigned to him personally, a number of messages are transmitted. The
objective is to connect a phone number to a patient and a room.
The update of the location master file depends on the setup of the private
branch exchange system (PABX):
a) Variable Numbering System
On admission the patient is assigned his
personal call number, which he retains throughout his stay, including if he is
transferred. The patient can always be reached under the same call
number.
To understand the mechanism for M05 events it is important to know
that two different sets of phone numbers exist: One is a pool to be used when
querying for a phone number for a patient, the other one is used for temporary
assignments when no patient is lying in the bed (i.e. the bed is free).
b) Fixed Numbering System
On admission the system issues the patient
with a telephone and/or TV authorization. This authorization key must be
entered into the phone to activate it.
No M05 messages are necessary if a
fixed numbering system is used: Each telephone connection is assigned a
permanent call number when the system is set up.
When the patient is admitted, a ADT^A01 message is sent to create a patient
record in the phone number assigning application. Typically, the patient ID
(PID-3), patient location (PV1-3), and visit number (PV1-19) are at least
required. This message is acknowledged accordingly with an ACK. Then, the
order for the phone number to the phone number assigning application is placed
with the ORM^O01 message where the essential fields are ORC-1 = "NW", ORC-2 =
<placer order number>, and OBR-4 = "Phone".
The ORR^O02 message is used to acknowledge the order and communicate the filler
order number and order status. Then, when the phone number is available, a
ORU^R01 message is used to communicate the phone number using OBX-5 for the
phone number.
Any status changes to the order are communicated with the ORM^O01 message where
ORC-1 = "SC", ORC-2 = <placer order number>, ORC-3 = <filler order
number>, ORC-5 = <order status>, OBR-4 = "Phone", and OBX-5 =
<Phone Number of Patient>. The status change is acknowledged with the
ORR^O02 message.
Next, the location master files are updated. The phone number assigning
application may send a MFN^M05 message to have the location master file reflect
the phone number assignment as well. The fields on the message are valued as
follows:
After processing the order: MFI-1 = "LOC", MFI-3 = "UPD", MFI-5 =
<effective date/time>, MFE-1 = "MUP", LOC-1 = <patient location>,
LOC-3 = "B" (bed), LOC-6 = <Phone Number of Patient>. This message is
acknowledged using the MFK^M05 message.
Transfer a patient (A02)
If a patient keeps the same phone number during the whole visit the assigned
phone number must be mapped to a different phone outlet whenever a patient is
transferred to a new location. In that case, the ADT^A02 message is sent to
the phone number assigning application. That application not only acknowledges
the message, but also sends an ORM^O01 message with ORC-1 = "SC and the other
fields the same as described in the Phone Number Assignment section.
Additionally, it sends a MFN^M05 message to change the location master file
accordingly for the old location and another MFN^M05 to synchronize the phones
for the new location.
Leave of absence (A21/A22)
When the patient leaves the hospital or the bed is vacated for a significant
amount of time, the phone needs to be de-activated and re-activated
appropriately. The same ORM^O01 and MFN^M05 messages are used as described
above following the ADT^A21 and ADT^22 messages.
Patient makes calls or (de-)activates his phone
The patient can use the phone whenever he wants to. This implies that his
balance does not exceed the limit. Otherwise the phone is deactivated
automatically. Furthermore the patient can activate or deactivate the phone by
entering the authorization key for his own. In these scenarios the phone
number assigning application sends and ORM^O01 message with ORC-1 = "OD" and
the appropriate order status. The status update is necessary to provide a call
switching syst
em
with the actual information.
Discharge a patient (A03)
When the patient is discharged, the ADT^A03 message is sent to indicate a
discharge. The phone number assigning application sends an ORM^O01 message
with a change of status to indicate completion of the order, as well as an
MFN^M05 message to synchronize the location master file.
After discharging a patient his final charges must be billed. Using the query
P04 returns the data in a display oriented format which can be used for
printing. Alternatively a print request can be used. The billing system issues
a QRY^P04 message where the fields are valued as follows: QRD-2 = "R" (record
oriented format), QRD-3 = "I" (immediate response), QRD-8.1 = <Patient
ID>, QRF-2 = <start date/time>, and QRF-3 = <end date/time>.
The phone number assigning applications responds with a DSR^P04 message with
the data in DSP-3.
Phone Call Queries (Q??)
The new query modes using a query by parameter query with a virtual table
response allows for obtaining call information from the phone system to be used
for charging. The query can be for accumulated data or detailed data. Both
requests use this conformance statement:
Query ID: |
Z73 |
Query Name: |
Information about Phone Calls |
Query Type: |
Query |
Query Trigger: |
QBP^Z73^QBP_Z73 |
Query Mode: |
Both |
Response Trigger: |
RTB^Z74^RTB_Z74 |
Query Priority: |
Immediate |
Query Characteristics: |
Returns response sorted by Phone Number |
Purpose: |
Retrieve all information about phone calls made during a defined interval either in a detailed or an accumulative format. The identifier for the patient must be given. |
QBP^Z73^QBP_Z73 |
QBP Message |
Section Reference |
MSH |
Message Header Segment |
2.15.9 |
QPD |
Query Parameter Definition |
5.4.4 |
RCP |
Response Control Parameter |
5.4.6 |
QPD
Input Parameter Specification:
Field Seq. (Query ID=Z73) |
Name |
Key/ Search |
Sort |
LEN |
TYPE |
Opt |
Rep |
Match Op |
TBL |
Segment Field Name |
Service Identifier Code |
ElementName |
1 |
Patient ID |
K |
Y |
80 |
CX |
R |
= |
PID.3 |
PID.3 Patient ID |
|||
2 |
Date Range |
53 |
DR |
O |
contains= |
|||||||
3 |
Detailed |
2 |
ID |
O |
= |
0136 Yes/No |
Input
Parameter Field Description and Commentary:
Field |
Component |
DT |
Description |
Patient ID |
CX |
Components: <ID (ST)> ^ <check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <assigning authority (HD)> ^ <identifier type code (IS)> ^ <assigning facility (HD)> |
|
This field contains a patient identification code to identify the requested person. |
|||
If this field is not valued, no values for this field are considered to be a match. |
|||
Date Range |
DR |
This field specifies the range of time, the requested records should match. |
|
If this field is not valued, all values for this field are considered to be a match. |
|||
Detailed |
ID |
This field specifies whether the output should be detailed. (no cumulative records). |
|
If this field is not valued, a detailed result is returned. |
|||
When Detailed=Y is requested, one record for each call is returned. Each detailed record will contain columns 1, 2, 3, 4, 5, 7, 8, and 9 (Providor,Region,Extension,Destination,Date/Time,Duration,Units,Amount) for each call. |
|||
When detailed=N, the query is for accumulated data. In this case, one row record per extension is returned,. |
|||
Each row will return columns 1, 2, 6,7, 8, and 9 (Provider,Region,Quantity,Units,Amount) from the output virtual table. |
Response
Grammar:
RTB^Z74^RTB_Z74 |
Personnel Information Message |
Group Control |
Comment |
Support Indicator |
Sec Ref |
MSH |
Message Header |
2.16.9 |
|||
MSA |
Message Acknowledgement |
2.16.8 |
|||
[ERR] |
Error |
2.16.5 |
|||
QAK |
Query Acknowledgement |
5.5.2 |
|||
QPD |
Query Parameter Definition |
5.5.4 |
|||
[ |
|||||
RDF |
Table Row Definition Segment |
5.5.7 |
|||
{ [ RDT ] } |
Table Row Data Segment |
5.5.8 |
|||
] |
|||||
[ DSC ] |
Continuation Pointer |
2.16.4 |
Virtual
Table:
ColName (Z74) |
Key/ |
Sort |
LEN |
TYPE |
Opt |
Rep |
Match Op |
TBL |
Segment Field Name |
LOINC or HL7 code |
ElementName |
Provider |
40 |
ST |
R |
||||||||
Region |
40 |
ST |
R |
||||||||
Extension |
250 |
XTN |
O |
||||||||
Destination number |
250 |
XTN |
O |
||||||||
Date/Time |
Y |
26 |
TS |
O |
|||||||
Quantity |
4 |
NM |
O |
||||||||
Duration |
4 |
NM |
O |
||||||||
Units |
4 |
NM |
O |
||||||||
Amount |
8 |
MO |
O |
Example
1:
Query the accumulated list for patient 12345 from 3/2/00 till 3/3/00. Transfer
the first 20 records.
Query:
MSH|^&~\|PCR|Gen
Hosp|PIMS||20000303201400-0800||QBP^Z89^QBP_Z89|9901|P|2.4||||||||
QPD|Z89^Query Phone Calls^HL7nnn|Q010|12345|2000030100000^20000302235959|Y
RCP|I|20^RD|
Answer:
MSH|^&~\|PIMS|Gen
Hosp|PCR||1998112014010800||RTB^X89^RTB_X89|8858|P|2.4||||||||
MSA|AA|9901|
QAK|Q010|OK|Z89^Query Phone Calls^HL7nnn|4
QPD|Z89^Query Phone Calls^HL7nnn|Q010|12345|2000030100000^20000302235959|Y|
RDF|9|Provider^ST^20|Region^ST^40|Extension^XTN^40|Destination^XTN^40|Date/Time^TS^26|Quantity^NM^4|Duration^NM^4|Units^NM^4|Amount^MO^8|
RDT|DTAG|CITY||||5|20|3|3.25|
RDT|DTAG|R50||||1|10|2|1.00|
RDT|DTAG|R200||||0|0|0|0|
RDT|DTAG|NAT||||0|0|0|0|
RDT|DTAG|INT||||0|0|0|0|
Example 2:
Query the detailed information for patient 12345 from 3/1/00 till 3/3/00.
Transfer the first 10 records.
Query:
MSH|^&~\|PCR|Gen
Hosp|PIMS||199811201400-0800||QBP^Z89^QBP_Z89|ACK9901|P|2.4||||||||
QPD|Z89^Query Phone
Calls^HL7nnn|Q010|12345|2000030100000^20000302235959|Y||||
RCP|I|10^RD|
Answer:
MSH|^&~\|PIMS|Gen
Hosp|PCR||199811201401-0800||RTB^X89^RTB_X89|8858|P|2.4||||||||
MSA|AA|8858 QAK|Q010|OK|Z89^Query Phone Calls^HL7nnn|4
QPD|Z89^Query Phone
Calls^HL7nnn|Q010|12345|2000030100000^20000302235959|Y||||
RDF|9|Provider^ST^20|Region^ST^40|Extension^XTN^40|Destination^XTN^40|Date/Time^TS^26|Quantity^NM^4|Duration^NM^4|Units^NM^4|Amount^MO^8|
RDT|DTAG|CITY|12345|555-1234|200003021715||20|12|2.25|
RDT|DTAG|CITY|12345|555-4569|200003011252||21|3|0.48|
Requesting a Chip card
In case the hospital provides additional services that can be accessed through
chip cards, this card has to be issued to the patient. At the end of the visit
this chip card is returned. Distributing a chip card to a patient is a service
which must be ordered from the chip card dispensing system, too. When
discharging the patient the service (= order) is complete.
The messages are essentially the same as for issuing a phone number. The
filler for the chip card order is a chip card dispensing application and
instead of returning a phone number, it returns a chip card number. The
following scenarios have slight variations.
New Chip Card requested due to, e.g., loss
When a card is lost, or a new chip card must be requested, an additional fee
can be communicated by including the FT1 segment in the ORM^O01 message and
valuing FT1-11 = <additional fee>.
Request a new Chip card for a defective one
Sometimes a chip card is defective. Then the patient needs a new one. This
situation requires an order using the XO control code in the ORM^O01 message.
The chip card dispensing system returns the new chip card number using the
ORU^RO1. The ORC-16-Order Control Code Reason is used to clarify the request
Return a chip card
When the patient returns the chip card, a discontinue message is send with
ORC-1 = "DC". This message is acknowledged accordingly by the chip card
dispensing system.
Printing a form
When form needs printing, the ORM^O01 could also be used. The OBR segment
would contain the print form service and the OBX would contain the specific
print form. A notification when completing the printing is feasible as well
using the ORM^O01 with a status update associated to the appropriate
placer/filler order number.
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. The diet order segments may be sent as part of the ORM and ORR message structure to support backwards compatibility, or may be sent as part of the following dedicated message structures.
OMD^O03^OMD_O03 |
Dietary Order |
Chapter |
MSH |
Message Header |
2 |
[{NTE}] |
Notes and Comments (for Header) |
2 |
[ |
||
PID |
Patient Identification |
3 |
[PD1] |
Additional Demographics |
3 |
[{NTE}] |
Notes and Comments (for Patient ID) |
2 |
[ |
||
PV1 |
Patient Visit |
3 |
[PV2] |
Patient Visit - Additional Info |
3 |
] |
||
[{ |
||
IN1 |
Insurance |
6 |
[IN2] |
Insurance Additional Info |
6 |
[IN3] |
Insurance Add'l Info - Cert. |
6 |
}] |
||
[GT1] |
Guarantor |
6 |
[{AL1}] |
Allergy 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 |
] |
||
} |
ORD^O04^ORD_O04 |
Dietary Order Acknowledgment Message |
Chapter |
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
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-7-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 |
OPT |
RP/ # |
TBL # |
ITEM # |
ELEMENT NAME |
1 |
1 |
ID |
R |
0159 |
00269 |
Type |
|
2 |
250 |
CE |
O |
Y/10 |
00270 |
Service Period |
|
3 |
250 |
CE |
R |
Y/20 |
00271 |
Diet, Supplement, or Preference Code |
|
4 |
80 |
ST |
O |
Y/2 |
00272 |
Text Instruction |
Definition:
This field specifies type of diet. Refer to HL7 Table 0159 - Diet code
specification type for valid entries.
Value |
Description |
D |
Diet |
S |
Supplement |
P |
Preference |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
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-morning 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 (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field is the 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|, |023^^99FD6|, |^NOLACT|, |^TUBEFD|, and
|011^HIPRO100^99FD1~123^LOFAT20^99FD1|
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: This field defines the 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 |
OPT |
RP/ # |
TBL # |
ITEM # |
ELEMENT NAME |
1 |
250 |
CE |
R |
0160 |
00273 |
Tray Type |
|
2 |
250 |
CE |
O |
Y/10 |
00270 |
Service Period |
|
3 |
80 |
ST |
O |
00272 |
Text Instruction |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field defines the type of dietary tray. Refer to HL7
Table 0160 - Tray type for valid entries.
Value |
Description |
EARLY |
Early tray |
LATE |
Late tray |
GUEST |
Guest tray |
NO |
No tray |
MSG |
Tray message only |
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 instruction.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
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.8.1.2, "ODS-2 Service period (CE) 00270," for further details.
Definition:
This field defines instructions associated with the tray. Example:
|PLASTIC SILVERWARE|.
First
order:
MSH|...<cr>
PID|...<cr>
ORC|NW|1235^NURS|||||^^^199108021700||199108021200|123^Smith^Bryan^Michael|456^Web^F.^Mary|...<cr>
ODS|D||321^DB15^99DO3|...<cr>
ODS|D||322^NA2GM^99DO3|<cr>
Hold first order:
MSH|...<cr>
PID|...<cr>
ORC|HD|1235^NURS|||||^^^199108031700||199108031200|123^Smith^Bryan^Michael|456^Web^F.^Mary
|...<cr>
NPO order with guest tray:
MSH|...<cr>
PID|...<cr>
ORC|NW|1236^NURS|||||^^^199108031700||199108031200|123^Smith^Bryan^Michael|456^456^Web^Mary|...<cr>
ODS|D||323^NPO^99DO3|...<cr>
ORC|NW|1244^NURS|||||^^^199108031700||199108031200|123^Smith^Bryan^Michael|456^Web^Mary|...<cr>
ODT|GUEST^Guest tray^HL70160|5^^99CBD|...<cr>
Clear liquid with guest tray:
MSH|...<cr>
PID|...<cr>
ORC|DC|1236^NURS|||||^^^199108041700||199108041200|123^Smith^Bryan^Michael|456^Web^Mary|...<cr>
ORC|NW|1237^NURS|||||^^^199108041700||199108041200|123^Smith^Bryan^Michael|456^Web^Mary|...<cr>
ODS|D||321^DB15^99DO3|...<cr>
ODS|D||322^NA2GM^99DO3|...<cr>
ODS|D||324^CLRLIQ^99DO3|...<cr>
ORC|NW|1245^NURS|||||^^^199108041700||199108041200|123^Smith^Bryan^Michael|456^Web^Mary|...<cr>
ODT|GUEST^Guest tray^HL70160|5^^99CBD|...<cr>
Full liquid with guest tray:
MSH|...<cr>
PID|...<cr>
ORC|DC|1237^NURS|||||^^^199108051700||199108051200|123^Smith^Bryan^Michael|456^Web^Mary|...<cr>
ORC|NW|1238^NURS|||||^^^199108051700||199108051200|123^Smith^Bryan^Michael|456^Web^Mary|...<cr>
ODS|D||321^DB15^99DO3|...<cr>
ODS|D||322^NA2GM^99DO3|...<cr>
ODS|D||325^FULLIQ^99DO3|...<cr>
ORC|NW|1246^NURS|||||^^^199108051700||199108051200|123^Smith^Bryan^Michael|456^Web^Mary|...<cr>
ODT|GUEST^Guest tray^HL70160|3^^99CBD|...<cr>
Release hold on previous order and give discharge message:
MSH|...<cr>
PID|...<cr>
ORC|DC|1238^NURS|||||^^^199108061700||199108061200|123^Smith^Bryan^Michael|456^Web^Mary|...<cr>
ORC|RL|1235^NURS|||||^^^199108061700||199108061200|123^Smith^Bryan^Michael|456^Web^Mary
|...<cr>
ORC|NW|1247^NURS|||||^^^199108061700||199108061200|123^Smith^Bryan^Michael|456^Web^Mary|...<cr>
ODT|MSG^Tray message only^HL70160|5^^99CBD|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|123^Smith^Bryan^Michael|456^Web^Mary|...<cr>
ODS|D||011^HIPRO100^99FD1|...<cr>
ODS|D||123^LOFAT20^99FD1|...<cr>
ODS|S|4|119^ICE CREAM^99FD8|...<cr>
ODS|S|6|320^1/2 HAM SANDWICH^99FD8|...<cr>
ORC|NW|1244^NURS|||||^^^199108031700||199108031200|123^Smith^Bryan^Michael|456^Web^Mary|...<cr>
ODT|EARLY^Early tray^HL70160|1^^99CBD|...<cr>
ORC|NW|1245^NURS|||||^^^199108031700||199108031200|123^Smith^Bryan^Michael|456^Web^Mary|...<cr>
ODT|LATE^Late tray^HL70160|3^^99CBD|...<cr>
ORC|NW|1246^NURS|||||^^^199108031700||199108031200|123^Smith^Bryan^Michael|456^Web^Mary|...<cr>
ODT|GUEST^Guest tray^HL70160|5^DINNER^99CBD|...<cr>
This
order specifies Similac with MCT oil and polycose additives.
MSH|...<cr>
PID|...<cr>
ORC|NW|1232^NURS|||||60^Q3H^^199108021700||199108021200|123^Smith^Bryan^Michael|456^Web^Mary|...<cr>
ODS|D||010^SIMILAC^99DO1|...<cr>
ODS|D||011^MCT^99DO1|...<cr>
ODS|D||012^POLYCOSE^99DO1|...<cr>
This
order specifies that the patient is a vegetarian.
MSH|...<cr>
PID|...<cr>
ORC|NW|1232^NURS|||||60^Q3H^^199108021700||199108021200|123^Smith^Bryan^Michael|456^Web^Mary|...<cr>
ODS|D||123^LOFAT20^99FD1|...<cr>
ODS|S|4|119^ICE CREAM^99FD8|...<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
non-stock.
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.
Non-stock 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 non-stock 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 where RQD is the detail segment for backward
compatibility or can use the OMS and ORS messages described below.
OMS^O05^OMS_O05 |
Stock Requisition Order Message |
Chapter |
MSH |
Message Header |
2 |
[{NTE}] |
Notes and Comments (for Header) |
2 |
[ |
||
PID |
Patient Identification |
3 |
[PD1] |
Additional Demographics |
3 |
[{NTE}] |
Notes and Comments (for Patient ID) |
2 |
[PV1 |
Patient Visit |
3 |
[PV2]] |
Patient Visit - Additional Info |
3 |
[{IN1 |
Insurance |
6 |
[IN2] |
Insurance Additional Info |
6 |
[IN3] |
Insurance Add'l Info - Cert. |
6 |
}] |
||
[GT1] |
Guarantor |
6 |
[{AL1}] |
Allergy Information |
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 |
} |
ORS^O06^ORS_O06 |
Stock Order Acknowledgment Message |
Chapter |
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
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 |
} |
||
] |
Non-stock
requisitions can use the ORM message with the RQD and RQ1 segments as the
detail segment, or use the OMN and ORN messages described below:
OMN^O07^OMN_O07 |
Nonstock Requisition Order Message |
Chapter |
MSH |
Message Header |
2 |
[{NTE}] |
Notes and Comments (for Header) |
2 |
[ |
||
PID |
Patient Identification |
3 |
[PD1] |
Additional Demographics |
3 |
[{NTE}] |
Notes and Comments (for Patient ID) |
2 |
[PV1 |
Patient Visit |
3 |
[PV2]] |
Patient Visit - Additional Info |
3 |
[{IN1 |
Insurance |
6 |
[IN2] |
Insurance Additional Info |
6 |
[IN3] |
Insurance Add'l Info - Cert. |
6 |
}] |
||
[GT1] |
Guarantor |
6 |
[{AL1}] |
Allergy Information |
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 |
} |
ORN^O08^ORN_O08 |
General Order Acknowledgment Message |
Chapter |
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
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 |
OPT |
RP/# |
TBL# |
ITEM # |
ELEMENT NAME |
1 |
4 |
SI |
O |
00275 |
Requisition Line Number |
||
2 |
250 |
CE |
C |
00276 |
Item Code - Internal |
||
3 |
250 |
CE |
C |
00277 |
Item Code - External |
||
4 |
250 |
CE |
C |
00278 |
Hospital Item Code |
||
5 |
6 |
NM |
O |
00279 |
Requisition Quantity |
||
6 |
250 |
CE |
O |
00280 |
Requisition Unit of Measure |
||
7 |
30 |
IS |
O |
0319 |
00281 |
Dept. Cost Center |
|
8 |
30 |
IS |
O |
0320 |
00282 |
Item Natural Account Code |
|
9 |
250 |
CE |
O |
00283 |
Deliver To ID |
||
10 |
8 |
DT |
O |
00284 |
Date Needed |
Definition: This field contains the number that identifies this line in the requisition.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the identifier and description that uniquely
identify the item on the application sending the requisition. This field is
conditional because at least one of the three fields RQD-2-item code-
internal, RQD-3-item code-external, or RQD-4-hospital item code must
be valued.
Components<identifier
(ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^
<alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of
alternate coding system (IS)>
Definition: This field contains the identifier and description that uniquely
identify the item on the application receiving the requisition. This field is
conditional because at least one of the three fields -- RQD-2-item
code-internal, RQD-3-item code-external or RQD-4-hospital item
code -- must be valued.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the 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. This field is conditional because at least one of the
three fields-- RQD-2-item code-internal, RQD-3-item code-external
or RQD-4-hospital item code-- must be valued.
Note: At least one of the three fields 4.11.1.2 through 4.11.1.4must be
non-null.
Definition: This field contains the quantity requisitioned for this item.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the unit of measure for this item.
Definition:
This field contains the accounting code that identifies this department in
order to charge for this item. User-defined table 0319 -
Department cost center is used as the HL7 identifier for the
user-defined table of values for this field.
Value |
Description |
|---|---|
No suggested values |
Definition:
This field contains the accounting code that identifies this item in order to
charge for this item. User-defined table 0320 - Item natural acco
unt
code is used as the HL7 identifier for the user-defined table of values
for this field.
Value |
Description |
|---|---|
No suggested values |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the unique identifier and descriptive name of
the department/location where the item should be delivered.
Definition:
This field contains the date this item is required.
Note: Although none of the fields are required, one of the three
identifying codes--RQD-2-item code-internal, RQD-3-item
code-external, or RQD-4-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 preceding RQD segment.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM # |
ELEMENT NAME |
1 |
10 |
ST |
O |
00285 |
Anticipated Price |
||
2 |
250 |
CE |
C |
00286 |
Manufacturer Identifier |
||
3 |
16 |
ST |
C |
00287 |
Manufacturer's Catalog |
||
4 |
250 |
CE |
C |
00288 |
Vendor ID |
||
5 |
16 |
ST |
C |
00289 |
Vendor Catalog |
||
6 |
1 |
ID |
O |
0136 |
00290 |
Taxable |
|
7 |
1 |
ID |
O |
0136 |
00291 |
Substitute Allowed |
Definition: This field contains the 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 (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the unique code that identifies the
manufacturer on the application receiving the requisition. This field is
conditional because either RQ1-2-manufacturer ID and
RQ1-3-manufacturer's catalog or RQ1-4-vendor ID and
RQ1-5-vendor catalog must be valued.
Codes may be selected from HIBCC Manufacturers 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 7-3.
Definition: This field is the manufacturer's catalog number or code for this item. This field is conditional because either RQ1-2-manufacturer ID and RQ1-3-manufacturer's catalog or RQ1-4-vendor ID and RQ1-5-vendor catalog must be valued.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field is the unique code that identifies the vendor on the
application receiving the requisition. This field is conditional because
either RQ1-2-manufacturer ID and RQ1-3-manufacturer's catalog or
RQ1-4-vendor ID and RQ1-5-vendor catalog must be valued.
Because of this, it is recommended that each nonstock item have
RQ1-2-manufacturers 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: This field is the vendor's catalog number, name, or code for this item. This field is conditional because either RQ1-2-manufacturer ID and RQ1-3-manufacturer's catalog or RQ1-4-vendor ID and RQ1-5-vendor catalog must be valued.
Definition:
This field indicates whether this item is 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 HL7 table 0136 -Yes/no indicator as defined in Chapter 2.
Definition: This field indicates whether the ancillary department may substitute an equivalent version of the item(s) ordered. Refer to HL7 table 0136 - Yes/no indicator as defined in Chapter 2.
This
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 numbers used by the ORSUPPLY application are RQ101
& RQ102.
MSH|^~\&|ORSUPPLY|ORSYS|MMSUPPLY|MMSYS|19911105131523||OMS^O05|
...<cr>
PID|... <cr>
ORC|NW|RQ101^ORSUPPLY||||N|||19911105130000|jjones^Jones^Jean|sgomez^Gomez^Susan|MAINOR^2W|321-1234
X2304^^^^^^3211234^2304|...<cr>
RQD|1|1234^Solution, 2.25% Saline||S1786^Saline
Solution|1|BT^Bottle|1234-5678||ORSUP^Main OR Supply
Room|19901123|...<cr>
MSH|^~\&|ORSUPPLY|ORSYS|MMSUPPLY|MMSYS|19911105131523||OMN^O07|...<cr>
PID|... <cr>
ORC|NW|RQ102^ORSUPPLY||||N|||19911105130000|jjones^Jones^Jean|sgomez^Gomez^Susan|MAINOR^2W|321-1234
X2304^^^^^^3211234^2304<cr>
RQD|1|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>
This
example is a requisition from the ORSUPPLY application to the MMSUPPLY
application for five stock items to replenish a supply closet. The requisition
numbers used by the ORSUPPLY application is RQ103 - RQ1037.
MSH|^~\&|ORSUPPLY|ORSYS|MMSUPPLY|MMSYS|19911105131523||OMS^O05|...<cr>
ORC|NW|RQ103^ORSUPPLY||||N|||19911105130000|jjones^Jones^Jean|sgomez^Gomez^Susan|MAINOR^2W|321-1234
X2304^^^^^^3211234^2304|...<cr>
RQD|1|1232^Solution, 1% Saline||S1784^Saline
Solution|5|BT^Bottle|1234-5678||ORSUP^Main OR Supply
Room|19901105|...<cr>
ORC|NW|RQ104^ORSUPPLY||||N|||19911105130000|jjones^Jones^Jean|sgomez^Gomez^Susan|MAINOR^2W|321-1234
X2304^^^^^^3211234^2304|...<cr>
RQD|2|1231^Solution, 0.2% Saline||S1781^Saline
Solution|2|BT^Bottle|1234-5678||ORSUP^Main OR Supply
Room|19901105|...<cr>
ORC|NW|RQ105^ORSUPPLY||||N|||19911105130000|jjones^Jones^Jean|sgomez^Gomez^Susan|MAINOR^2W|321-1234
X2304^^^^^^3211234^2304|...<cr>
RQD|3|2342^Suture, Black Silk||SU123^Suture|2|DZ^Dozen|1234-5678||ORSUP^Main OR
Supply Room|19901105|...<cr>
ORC|NW|RQ106^ORSUPPLY||||N|||19911105130000|jjones^Jones^Jean|sgomez^Gomez^Susan|MAINOR^2W|321-1234
X2304^^^^^^3211234^2304|...<cr>
RQD|4|2344^Suture, Black Silk
3-0||SU124^Suture|1|DZ^Dozen|1234-5678||ORSUP^Main OR Supply
Room|19901105|...<cr>
ORC|NW|RQ107^ORSUPPLY||||N|||19911105130000|jjones^Jones^Jean|sgomez^Gomez^Susan|MAINOR^2W|321-1234
X2304^^^^^^3211234^2304|...<cr>
RQD|5|4565^Bandage Pad, 4x4||B6345^Bandage Pad|3|BX^Box|1234-5678||ORSUP^Main
OR Supply Room|19901105|...<cr>
For
the RDS (pharmacy/treatment dispense), RGV (pharmacy/treatment give) and RAS
(pharmacy/treatment administration) messages, the placer and filler order
numbers are those of the parent RDE (pharmacy/treatment encoded order) message.
In these messages, the filler order number does not provide a unique
identification of the instance of the pharmacy/treatment 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 order number (including its application ID component) and the
appropriate sub-ID counter uniquely identifies the instance of the
pharmacy/treatment 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 or treatment system and the
receiving system must communicate changes in state. Depending on whether the
pharmacy or treatment supplier'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 or treatment system.
For example, suppose that a pharmacy or treatment system is sending RGV
messages to a nursing system which will administer the medication and that the
pharmacy or treatment 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 or treatment supplier 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.
An 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.3.10.2, "Cyclic placer order groups," for further details.
Pharmacy/Treatment
Orders can use the ORM message with the RXO, RXC, and RXR segments for the
detail segment, or use the OMP and ORP messages as described below.
OMP^O09^OMP_O09 |
Pharmacy/treatment Order Message |
Chapter |
MSH |
Message Header |
2 |
[{NTE}] |
Notes and Comments (for Header) |
2 |
[ |
||
PID |
Patient Identification |
3 |
[PD1] |
Additional Demographics |
3 |
[{NTE}] |
Notes and Comments (for Patient ID) |
2 |
[PV1 |
Patient Visit |
3 |
[PV2]] |
Patient Visit - Additional Info |
3 |
[{IN1 |
Insurance |
6 |
[IN2] |
Insurance Additional Info |
6 |
[IN3] |
Insurance Add'l Info - Cert. |
6 |
}] |
||
[GT1] |
Guarantor |
6 |
[{AL1}] |
Allergy Information |
3 |
] |
||
{ |
||
ORC |
Common Order |
4 |
RXO |
Pharmacy/Treatment Order |
4 |
[{NTE}] |
Notes and Comments (for RXO) |
2 |
{RXR} |
Pharmacy/Treatment Route |
4 |
[ |
||
{RXC} |
Pharmacy/Treatment Component |
4 |
[{NTE}] |
Notes and Comments (for RXC) |
2 |
] |
||
[ |
||
{ |
||
OBX |
Observation/Result |
7 |
[{NTE}] |
Notes and Comments (for OBX) |
2 |
} |
||
] |
||
[{FT1}] |
Financial Transaction |
6 |
[BLG] |
Billing Segment |
6 |
} |
ORP^O10^ORP_O10 |
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/Treatment Order |
4 |
[{NTE}] |
Notes and Comments (for RXO) |
2 |
{RXR} |
Pharmacy/Treatment Route |
4 |
[{RXC}] |
Pharmacy/Treatment Component |
4 |
[{NTE}] |
Notes and Comments (for RXC) |
2 |
] |
||
} |
||
] |
This
message communicates the pharmacy or treatment application's encoding of the
pharmacy/treatment 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/treatment orders for a patient.
The RDE/RRE is also used to communicate a refill authorization request
originating with the pharmacy.
As a site-specific variant, the original order segments (RXO, RXRs, associated
RXCs, and any NTEs) may be sent optionally (for comparison).
RDE^O11^RDE_O11 |
Pharmacy/Treatment Encoded Order Message |
Chapter |
MSH |
Message Header |
2 |
[{NTE}] |
Notes and Comments (for Header) |
2 |
[ |
||
PID |
Patient Identification |
3 |
[PD1] |
Additional Demographics |
3 |
[{NTE}] |
Notes and Comments (for Patient ID) |
2 |
[PV1 |
Patient Visit |
3 |
[PV2]] |
Patient Visit - Additional Info |
3 |
[{IN1 |
Insurance |
|
[IN2] |
Insurance Additional Info |
6 |
[IN3] |
Insurance Add'l Info - Cert. |
6 |
}] |
||
[GT1] |
Guarantor |
6 |
[{AL1}] |
Allergy Information |
3 |
] |
||
{ |
||
ORC |
Common Order |
4 |
[ |
||
RXO |
Pharmacy/Treatment Prescription Order |
4 |
[{NTE}] |
Notes and Comments (for RXO) |
2 |
{RXR} |
Pharmacy/Treatment Route |
4 |
[ |
||
{RXC} |
Pharmacy/Treatment Component (for RXO) |
4 |
[{NTE}] |
Notes and Comments (for RXC) |
2 |
] |
||
] |
||
RXE |
Pharmacy/Treatment Encoded Order |
4 |
{RXR} |
Pharmacy/Treatment Route |
4 |
[{RXC}] |
Pharmacy/Treatment Component (for RXE) |
4 |
[{ |
||
OBX |
Results |
7 |
[{NTE}] |
Notes and Comments (for OBX) |
2 |
}] |
||
{[CTI]} |
Clinical Trial Identification |
7 |
} |
Note: The RXCs which follow the RXO may not be fully encoded, but those that follow the RXE must be fully encoded.
RRE^O12^RRE_O12 |
Pharmacy/Treatment Encoded Order Acknowledgment Message |
Chapter |
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
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/Treatment Encoded Order |
4 |
{RXR} |
Pharmacy/Treatment Route |
4 |
[{RXC}] |
Pharmacy/Treatment Component |
4 |
] |
||
} |
||
] |
The use of RDE with the trigger of O01 and RRE with the trigger O02 is maintained for backward compatibility.
The
RDS message may be created by the pharmacy/treatment application for each
instance of dispensing a drug or treatment 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 or treatments given. As a site-specific variant, the original order
segments (RXO, RXE and their associated RXR/RXCs) may be sent optionally (for
comparison).
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 or treatment supplier to the Nursing application (or other)
with drug/treatment dispense and administration instructions.
The FT1 segment is optional and repeating in order to accommodate multiple
charge, benefit and pricing situations. Example use cases demonstrating zero,
one and two FT1 segments follow:
In the case where the RDS message represents a dispense event that is in
process (i.e., has not been received by the patient), the financial
transactions associated with the dispense do not yet exist. Until the
financial transactions associated with the dispense event have been completed,
no FT1 segment may exist in the message.
In the case where the RDS message represents a dispense event that has been
received by the patient, and thus all financial transactions have been
completed, the RDS message may contain one or more FT1 segments. Examples of
single and multiple FT1 segments follow.
Payment for the dispense event completed by a single payor:
MSH|^&~\|Pharm|GenHosp|CIS|GenHosp|1998052911150700||RDS^O13^RDS_O13|...<cr>
PID|...<cr>
ORC|RE|...<cr>
RXD|1|00310-0131-10^LISINOPRIL 10MG
TABLET^NDC|199907150830|100|TAB|...<cr>
FT1|1|||199907151035||PY|00310-0131-10^LISINOPRIL 10MG
TABLET^NDC|||100|125.43&USD|...<cr>
Payment for the dispense event involves multiple payment sources:
MSH|^&~\|Pharm|GenHosp|CIS|GenHosp|1998052213000700||RDS^O13^RDS_O13|...<cr>
PID|...<cr>
ORC|RE|...<cr>
RXD|1|00340-0241-10^VERAPAMIL 120MG
TABLET^NDC|199907200940|100|TAB|...<cr>
FT1|1|||199907211055||CD|00340024110^VERAPAMIL 120MG TABLET
^NDC|||100|55.43&USD|...<cr> (amount paid by insurance)
FT1|2|||199907211055||CP|00340024110^VERAPAMIL 120MG TABLET
^NDC|||100|5.00&USD|...<cr> (copay paid by patient)
The use of RDS with the trigger of O01 and RRD with the trigger O02 is
maintained for backward compatibility.
RDS^O13^RDS_O13 |
Pharmacy/Treatment Dispense Message |
Chapter |
MSH |
Message Header |
2 |
[{NTE}] |
Notes and Comments (for Header) |
2 |
[ |
||
PID |
Patient Identification |
3 |
[PD1] |
Additional Demographics |
3 |
[{NTE}] |
Notes and Comments (for PID) |
2 |
[{AL1}] |
Allergy Information |
2 |
[ |
||
PV1 |
Patient Visit |
3 |
[PV2] |
Patient Visit - Additional Info |
3 |
] |
||
] |
||
{ |
||
ORC |
Common Order |
4 |
[ |
||
RXO |
Pharmacy /Treatment Order |
4 |
[ |
||
{NTE} |
Notes and Comments (for RXO) |
2 |
{RXR} |
Pharmacy/Treatment Route |
4 |
[ |
||
{RXC} |
Pharmacy/Treatment Component |
4 |
[{NTE}] |
Notes and Comments (for RXC) |
2 |
] |
||
] |
||
] |
||
[ |
||
RXE |
Pharmacy/Treatment Encoded Order |
4 |
{RXR} |
Pharmacy/Treatment Route |
4 |
[{RXC}] |
Pharmacy/Treatment Component |
4 |
] |
||
RXD |
Pharmacy/Treatment Dispense |
4 |
{RXR} |
Pharmacy/Treatment Route |
4 |
[{RXC}] |
Pharmacy/Treatment Component |
4 |
[{ |
||
OBX |
Results |
7 |
[{NTE}] |
Notes and Comments (for OBX) |
2 |
}] |
||
[{FT1}] |
Financial Transaction segment |
6 |
} |
RRD^O14^RRD_O14 |
Pharmacy/Treatment Dispense Acknowledgment Message |
Chapter |
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
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/Treatment Dispense |
4 |
{RXR} |
Pharmacy/Treatment Route |
4 |
[{RXC}] |
Pharmacy/Treatment Component |
4 |
] |
||
} |
||
] |
The
RDS message's RXD segment 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. It does not contain the given instructions or
scheduling information. When this "give" (i.e., administration) information
needs to be transmitted from the pharmacy or treatment application to another
application, it is done with the RGV message.
The RGV message uses the RXG segment to record drug or treatment administration
instructions. It may carry information about a single scheduled administration
on a drug or treatment, or it may carry information about multiple
administrations. If the pharmacy or treatment application (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/treatment
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
or treatment application to the Nursing application (or other) with
drug/treatment administration instructions.
RGV^O15^RGV_O15 |
Pharmacy/Treatment 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 Information |
2 |
[PV1 |
Patient Visit |
3 |
[PV2]] |
Patient Visit - Additional Info |
3 |
] |
||
{ |
||
ORC |
Common Order |
4 |
[ |
||
RXO |
Pharmacy /Treatment Order |
4 |
[ |
||
{NTE} |
Notes and Comments (for RXO) |
2 |
{RXR} |
Pharmacy/Treatment Route |
4 |
[ |
||
{RXC} |
Pharmacy/Treatment Component |
4 |
[{NTE}] |
Notes and Comments (for RXC) |
2 |
] |
||
] |
||
] |
||
[ |
||
RXE |
Pharmacy/Treatment Encoded Order |
4 |
{RXR} |
Pharmacy/Treatment Route |
4 |
[{RXC}] |
Pharmacy/Treatment Component |
4 |
] |
||
{ |
||
RXG |
Pharmacy/Treatment Give |
4 |
{RXR} |
Pharmacy/Treatment Route |
4 |
[{RXC}] |
Pharmacy/Treatment Component |
4 |
{ |
||
[OBX] |
Observation/Results |
7 |
[{NTE}] |
Notes and Comments (for OBX) |
2 |
} |
||
} |
||
} |
RRG^O16^RRG_O16 |
Pharmacy/Treatment Give Acknowledgment Message |
Chapter |
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
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/Treatment Give |
4 |
{RXR} |
Pharmacy/Treatment Route |
4 |
[{RXC}] |
Pharmacy/Treatment Component |
4 |
] |
||
} |
||
] |
The use of RGV with the trigger of O01 and RRG with the trigger O02 is maintained for backward compatibility.
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/treatment 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 or treatment 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^O17^RAS_O17 |
Pharmacy/Treatment Administration |
Chapter |
MSH |
Message Header |
2 |
[{NTE}] |
Notes and Comments (for Header) |
2 |
[ |
||
PID |
Patient Identification |
3 |
[PD1] |
Additional Demographics |
3 |
[{NTE}] |
Notes and Comments (for PID) |
2 |
[{AL1}] |
Allergy Information |
2 |
[PV1 |
Patient Visit |
3 |
[PV2]] |
Patient Visit - Additional Info |
3 |
] |
||
{ |
||
ORC |
Common Order |
4 |
[ |
||
RXO |
Pharmacy /Treatment Order |
4 |
[ |
||
{NTE} |
Notes and Comments (for RXO) |
2 |
{RXR} |
Pharmacy/Treatment Route |
4 |
[ |
||
{RXC} |
Pharmacy/Treatment Component |
4 |
[{NTE}] |
Notes and Comments (for RXC) |
2 |
] |
||
] |
||
] |
||
[ |
||
RXE |
Pharmacy/Treatment Encoded Order |
4 |
{RXR} |
Pharmacy/Treatment Route |
4 |
[{RXC}] |
Pharmacy/Treatment Component |
4 |
] |
||
{{RXA} |
Pharmacy/Treatment Administration |
4 |
RXR |
Pharmacy/Treatment Route |
4 |
{[OBX |
Observation/Result |
7 |
{[NTE]} |
Notes and Comments (for OBX) |
2 |
]}} |
||
{[CTI]} |
Clinical Trial Identification |
7 |
} |
RRA^O18^RRA_O18 |
Pharmacy/Treatment Administration Acknowledgment Message |
Chapter |
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
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/Treatment Administration |
4 |
RXR |
Pharmacy/Treatment Route |
4 |
] |
||
} |
||
] |
The use of RAS with the trigger of O01 and RRA with the trigger O02 is maintained for backward compatibility.
This
query/response pair is retained for backward compatibility only.
Please refer to Chapter 5 for detailed coverage of query/response methodology
to be employed in Versions 2.4 and later.
QRY^Q26^QRY_Q01 |
Query Message |
Chapter |
MSH |
Message Header |
2 |
QRD |
Query Definition |
5 |
[QRF] |
Query Filler |
5 |
[DSC] |
Continuation Pointer |
2 |
ROR^ROR^ROR_ROR |
Pharmacy /Treatment Order Response |
Chapter |
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ERR] |
Error |
2 |
{ |
||
QRD |
Query Definition |
5 |
[QRF] |
Query Filter |
5 |
[PID |
Patient Identification |
3 |
{[NTE]}] |
Notes and Comments (for PID) |
2 |
{ |
||
ORC |
Common Order |
4 |
RXO |
Pharmacy/Treatment Order |
4 |
{RXR} |
Pharmacy/Treatment Route |
4 |
{[RXC]} |
Pharmacy/Treatment Component |
4 |
} |
||
} |
||
[DSC] |
Continuation Pointer |
2 |
This
query/response pair is retained for backward compatibility only.
Please refer to Chapter 5 for detailed coverage of query/response methodology
to be employed in Versions 2.4 and later.
QRY^Q27^QRY_Q01 |
Query Message |
Chapter |
MSH |
Message Header |
2 |
QRD |
Query Definition |
5 |
[QRF] |
Query Filler |
5 |
[DSC] |
Continuation Pointer |
2 |
RAR^RAR^RAR_RAR |
Pharmacy/treatment Administration Information |
Chapter |
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ERR] |
Error |
2 |
{ |
||
QRD |
Query Definition |
5 |
[QRF] |
Query Filter |
5 |
[PID |
Patient Identification |
3 |
{[NTE]}] |
Notes and Comments (for PID) |
2 |
{ |
||
ORC |
Common Order |
4 |
[ |
||
RXE |
Pharmacy/Treatment Encoded Order |
4 |
{RXR} |
Pharmacy/Treatment Route |
4 |
{[RXC]} |
Pharmacy/Treatment Component |
4 |
] |
||
{RXA} |
Pharmacy/Treatment Administration |
4 |
RXR |
Pharmacy/Treatment Route |
4 |
} |
||
} |
||
[DSC] |
Continuation Pointer |
2 |
This
query/response pair is retained for backward compatibility only.
Please refer to Chapter 5 for detailed coverage of query/response methodology
to be employed in Versions 2.4 and later.
QRY^Q28^QRY_Q01 |
Query Message |
Chapter |
MSH |
Message Header |
2 |
QRD |
Query Definition |
5 |
[QRF] |
Query Filler |
5 |
[DSC] |
Continuation Pointer |
2 |
RDR^RDR^RDR_RDR |
Pharmacy/treatment Dispense Information |
Chapter |
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ERR] |
Error |
2 |
{ |
||
QRD |
Query Definition |
5 |
[QRF] |
Query Filter |
5 |
[PID |
Patient Identification |
3 |
{[NTE]}] |
Notes and Comments (for PID) |
2 |
{ |
||
ORC |
Common Order |
4 |
[ |
||
RXE |
Pharmacy/Treatment Encoded Order |
4 |
{RXR} |
Pharmacy/Treatment Route |
4 |
{[RXC]} |
Pharmacy/Treatment Component |
4 |
] |
||
{RXD |
Pharmacy/Treatment Dispense |
4 |
{RXR} |
Pharmacy/Treatment Route |
4 |
[{RXC}] |
Pharmacy/Treatment Component |
4 |
} |
||
} |
||
} |
||
[DSC] |
Continuation Pointer |
2 |
This
query/response pair is retained for backward compatibility only.
Please refer to Chapter 5 for detailed coverage of query/response methodology
to be employed in Versions 2.4 and later.
QRY^Q29^QRY_Q01 |
Query Message |
Chapter |
MSH |
Message Header |
2 |
QRD |
Query Definition |
5 |
[QRF] |
Query Filler |
5 |
[DSC] |
Continuation Pointer |
2 |
RER^RER^RER_RER |
Pharmacy/treatment Encoded Order Information |
Chapter |
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ERR] |
Error |
2 |
{ |
||
QRD |
Query Definition |
5 |
[QRF] |
Query Filter |
5 |
[PID |
Patient Identification |
3 |
{[NTE]}] |
Notes and Comments (for PID) |
2 |
{ |
||
ORC |
Common Order |
4 |
RXE |
Pharmacy/Treatment Encoded Order |
4 |
{RXR} |
Pharmacy/Treatment Route |
4 |
{[RXC]} |
Pharmacy/Treatment Component |
4 |
} |
||
} |
||
[DSC] |
Continuation Pointer |
2 |
This
query/response pair is retained for backward compatibility only.
Please refer to Chapter 5 for detailed coverage of query/response methodology
to be employed in Versions 2.4 and later.
QRY^Q30^QRY_Q01 |
Query Message |
Chapter |
MSH |
Message Header |
2 |
QRD |
Query Definition |
5 |
[QRF] |
Query Filler |
5 |
[DSC] |
Continuation Pointer |
2 |
RGR^RGR^RGR_RGR |
Pharmacy/treatment Dose Information |
Chapter |
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ERR] |
Error |
2 |
{ |
||
QRD |
Query Definition |
5 |
[QRF] |
Query Filter |
5 |
[PID |
Patient Identification |
3 |
{[NTE]}] |
Notes and Comments (for PID) |
2 |
{ |
||
ORC |
Common Order |
4 |
[ |
||
RXE |
Pharmacy/Treatment Encoded Order |
4 |
{RXR} |
Pharmacy/Treatment Route |
4 |
{[RXC]} |
Pharmacy/treatment Component |
4 |
] |
||
{RXG} |
Pharmacy/Treatment Give |
4 |
{RXR} |
Pharmacy/Treatment Route |
4 |
{[RXC]} |
Pharmacy/Treatment Component |
4 |
} |
||
} |
||
[DSC] |
Continuation Pointer |
2 |
This
is the "master" pharmacy/treatment 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), as well as other nonpharmacy treatments, e.g., respiratory
therapy, oxygen, and many nursing treatments.
In addition to the pharmaceutical/treatment 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 |
OPT |
RP/# |
TBL# |
ITEM # |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
250 |
CE |
C |
00292 |
Requested Give Code |
||
2 |
20 |
NM |
C |
00293 |
Requested Give Amount - Minimum |
||
3 |
20 |
NM |
O |
00294 |
Requested Give Amount - Maximum |
||
4 |
250 |
CE |
C |
00295 |
Requested Give Units |
||
5 |
250 |
CE |
C |
00296 |
Requested Dosage Form |
||
6 |
250 |
CE |
O |
Y |
00297 |
Provider's Pharmacy/Treatment Instructions |
|
7 |
250 |
CE |
O |
Y |
00298 |
Provider's Administration Instructions |
|
8 |
200 |
CM |
O |
00299 |
Deliver-To Location |
||
9 |
1 |
ID |
O |
0161 |
00300 |
Allow Substitutions |
|
10 |
250 |
CE |
O |
00301 |
Requested Dispense Code |
||
11 |
20 |
NM |
O |
00302 |
Requested Dispense Amount |
||
12 |
250 |
CE |
O |
00303 |
Requested Dispense Units |
||
13 |
3 |
NM |
O |
00304 |
Number Of Refills |
||
14 |
250 |
XCN |
C |
Y |
00305 |
Ordering Provider's DEA Number |
|
15 |
250 |
XCN |
C |
Y |
00306 |
Pharmacist/Treatment Supplier's Verifier ID |
|
16 |
1 |
ID |
O |
0136 |
00307 |
Needs Human Review |
|
17 |
20 |
ST |
C |
00308 |
Requested Give Per (Time Unit) |
||
18 |
20 |
NM |
O |
01121 |
Requested Give Strength |
||
19 |
250 |
CE |
O |
01122 |
Requested Give Strength Units |
||
20 |
250 |
CE |
O |
Y |
01123 |
Indication |
|
21 |
6 |
ST |
O |
01218 |
Requested Give Rate Amount |
||
22 |
250 |
CE |
O |
01219 |
Requested Give Rate Units |
||
23 |
10 |
CQ |
O |
00329 |
Total Daily Dose |
||
24 |
250 |
CE |
O |
Y |
01476 |
Supplementary Code |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field identifies the treatment product or treatment ordered
to be given to the patient; it is analogous to OBR-4-universal service ID
in function. Examples of treatments products include medications and
certain devices or supplies, e.g., inhaler spacers, blood glucose monitors,
syringes, infusion sets, which might require prescription.
Often the coded entry implies dosage form and a dosage form is required in
addition to the product name. When the give code does not include the dosage
form, use RXO-5-requested dosage form. When the give code does not
include the strength, use RXO-18-requested give strength and the
RXO-19-requested give units Realize that strengths do not apply to some such
orders.
The RXO-1, RXO-2 and RXO-4 are mandatory unless the prescription/treatment is
transmitted as free text using RXO-6, then RXO-1, RXO-2, and RXO-4 may be blank
and the first subcomponent of RXO-6 must be blank.
Use of the RXO-6.2 versus the RXO-1.2 for a free text order is dependent on
whether or not the free text describes a product or if it is more commentary in
nature.
Please refer to the request -to-dispense fields RXO-10, RXO-11, and RXO-12 for
a discussion of the interrelationship with the request-to-give fields.
Definition:
This field is the ordered amount. In a variable dose order, this is the
minimum ordered amount. In a non-varying dose order, this is the exact amount
of the order.
The RXO-1, RXO-2 and RXO-4 are mandatory unless the prescription/treatment is
transmitted as free text using RXO-6, then RXO-1, RXO-2, and RXO-4 may be blank
and the first subcomponent of RXO-6 must be blank.
Note: This field is not a duplication of the first component of the
quantity/timing field, since in non-pharmacy/treatment orders, that component
can be used to specify multiples of an ordered amount.
Another way to
say this is that, for pharmacy/treatment orders, the quantity component of the
quantity/timing field refers to what is to be given out at each service
interval; thus, in terms of the RX order, that first component always defaults
to 1. Hence, in the actual execution of the order, the value of 1 in the first
component of the quantity/timing field always refers to one administration of
the amount specified in this field (the Requested Give Amount field).
Definition: In a variable dose order, this is the maximum ordered amount. In a non-varying dose order, this field is not used.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field indicates the units for the give amount.
The RXO-1, RXO-2 and RXO-4 are mandatory unless the prescription is transmitted
as free text using RXO-6, then RXO-1, RXO-2, and RXO-4 may be blank and the
first subcomponent of RXO-6 must be blank.
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 (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field indicates the manner in which the treatment is
aggregated for dispensing, e.g., tablets, capsules suppositories. In some
cases, this information is implied by the dispense/give code in
RXO-1-requested give code or RXO-10-Requested dispense code.
Required when both RXO-1-Requested give code and RXO-10-Requested
dispense code do not specify the drug/treatment form. Optionally included
otherwise.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field identifies the ordering provider's instructions to the
pharmacy or the non-pharmacy treatment provider (e.g., respiratory therapy).
If coded, a user-defined table must be used. If transmitted as a free text
field, place a null in the first component and the text in the second, e.g.,
|^this is a free text treatment instruction|.
If the prescription is transmitted as free text using RXO-6, then RXO-1, RXO-2,
and RXO-4 may be blank and the first subcomponent of RXO-6 must be blank.
Otherwise, RXO-1, RXO-2 and RXO-4 are mandatory.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field identifies the ordering provider's instructions to the
patient or to the provider administering the drug or treatment. If coded, a
user-defined table must be used. If transmitted as free text, place a null in
the first component and the text in the second, e.g., |^this is a free text
administration instruction|.
Components:
<point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^
<facility (HD)> ^ <location status (IS)> ^ <patient location
type (IS)> ^ <building (IS)> ^ <floor (IS)> ^ <address
(AD)>
Subcomponents of facility (HD): <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Subcomponents of address (AD): <street address (ST)> & <
other designation (ST)> & <city (ST)> & <state or province
(ST)> & <zip or postal code (ST)> & <country (ID)> &
<address type (ID)> & <other geographic designation
(ST)>
Definition: The first components, modeled after the PL data type, contain the
inpatient or outpatient location to which the pharmacy provider or treatment
supplier is to deliver the drug or treatment device (if applicable). The
default (null) value is the current census location for the patient. This
component has the same form as PV1-3-assigned patient location. The
last 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:
Following are the values:
Value |
Description |
N |
Substitutions are NOT authorized. (This is the default - null.) |
G |
Allow generic substitutions. |
T |
Allow therapeutic substitutions |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field indicates what is to be/was dispensed; it is analogous
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, then
RXO-5-requested dosage form is required
Note on request-to-dispense fields:
Sometimes an order will be written in which the total amount of the drug or
treatment requested to be dispensed has no direct relationship with the give
amounts and schedule. For example, an outpatient pharmacy/treatment order
might be take four tablets 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.
Definition: This field specifies the amount to be dispensed. See above note.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field identifies the 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. See above note.
Definition: This field defines the number of times the requested dispense amount can be given to the patient, subject to local regulation. Refers to outpatient only.
Components:
In Version 2.3 and later, use instead of the CN data type. <ID number
(ST)> ^ <family name (FN)> ^ <given name (ST)> ^ <second or
further given names or initials thereof (ST)> ^ <suffix (e.g., JR or III)
(ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (IS)> ^
<source table (IS)> ^ <assigning authority (HD)> ^ <name type
code (ID)> ^ <identifier check digit (ST)> ^ <code identifying the
check digit scheme employed (ID)> ^ <identifier type code (IS)> ^
<assigning facility (HD)> ^ <name representation code (ID)> ^
<name context (CE)> ^ <name validity range (DR)> ^ < name
assembly order (ID)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)
Subcomponents of assigning facility: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)
Definition: This field identifies the provider's controlled substance number,
if required, by site. It is defined as conditional because it is required when
the substance being requested is a controlled substance (e.g., a narcotic).
Components:
In Version 2.3 and later, use instead of the CN data type. <ID number
(ST)> ^ <family name (FN)> ^ <given name (ST)> ^ <second or
further given names or initials thereof (ST)> ^ <suffix (e.g., JR or III)
(ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (IS)> ^
<source table (IS)> ^ <assigning authority (HD)> ^ <name type
code (ID)> ^ <identifier check digit (ST)> ^ <code identifying the
check digit scheme employed (ID)> ^ <identifier type code (IS)> ^
<assigning facility (HD)> ^ <name representation code (ID)> ^
<name context (CE)> ^ <name validity range (DR)> ^ < name
assembly order (ID)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)
Subcomponents of assigning facility: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)
Definition: This field is the provider ID of the pharmacist/treatment supplier
verifier. Use if required by the pharmacy or treatment 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/treatment supplier" on the order. In this case the first field,
ORC-11-verified by, is already present; but the second field,
RXO-15-pharmacist/treatment supplier's verifier ID, is needed.
Definition:
This field uses HL7 table 0136 - Yes/no indicator. The values
have the following meaning for this field:
Y Yes - Indicates that the pharmacist or non-pharmacist treatment supplier
filling the order needs to pay special attention to the text in the
RXO-6-provider's pharmacy/treatment instructions. A warning is
present.
N No - No warning is present. This is the equivalent default (null) value.
An example of the use of this field is given by the following case:
A smart Order Entry application knows of a possible drug or treatment
interaction on a certain order, but the provider issuing the order wants to
override the condition. In this case, the pharmacy or treatment application
receiving the order will want to have a staff pharmacist or non-pharmacist
treatment supplier review the interaction and contact the ordering physician.
Definition:
This field identifies the 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 defined as conditional because it is required when the ordered
substance is to be administered continuously at a prescribed rate (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.
Definition:
Required when RXO-1-requested give code does not specify the strength.
Optionally included otherwise. This is the numeric part of the strength, used
in combination with RXO-19-requested give strength units.
The need for strength and strength unit fields in addition to the amount and
amount units fields included in various RX_ segments requires explanation.
Physicians can write a prescription for a drug such as Ampicillin in two ways.
One way would be: "Ampicillin 250 mg capsules, 2 capsules four times a day."
In this case the give amount would be 2, the give units would be capsules, the
strength would be 250 and the strength units would milligrams.
However, the provider could also write the pharmaceutical treatment as
"Ampicillin 500 mg four times a day." In this case the give amount would be
500 and the give units would be milligrams. The strength would not be reported
in the RXO segment because it is not specified; the drug could be given in two
250 mg caps or one 500 mg cap. But the pharmacist would dispense a specific
capsule size and would record the strength in the RXE segment as 250 or 500,
depending upon which capsule size was dispensed.
Some coding systems imply the strength, units, route of administration, and
manufacturer of substances within a single instructional code. NDC codes, for
example, usually imply not only the medical substance, but also the strength,
the units, and the form, e.g., 0047-0402-30^Ampicillin 250 MG CAPS^NDC. So all
of this information can also be completely specified in RXO-1-requested give
code and in the analogous CE fields in other pharmacy/treatment segments.
In this case, it is not necessary to use the strength and strength units fields
to specify this information.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: Required when both RXO-1-requested give code and
RXO-10-requested dispense code do not specify the strength. Optionally
included otherwise. This is the unit of the strength, used in combination with
RXO-18-requested give strength.
Note: These units can be a "compound quantity;" i.e., the units may
express a quantity per unit of time. For example, micrograms per hour (mg/h)
is an acceptable value. These compound units are contained in the ISO+ table.
See Chapter 7 for full definition of ISO+ units.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field identifies the condition or problem for which the
drug/treatment was prescribed. May repeat if multiple indications are relevant.
Definition: This field contains the rate at which to administer a treatment, e.g., 150 ml/hr (for an IV) or 4 liters/min for nasal oxygen.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the units in which RXO-21-requested give
rate amount is denominated.
Components:
<quantity (NM)> ^ <units (CE)>
Subcomponents of units: <identifier (ST)> & <text (ST)>
& <name of coding system (IS)> & <alternate identifier
(ST)> & <alternate text (ST)> & <name of alternate coding
system (IS)>
Definition: This field contains the total daily dose for this particular
pharmaceutical as expressed in terms of actual dispense units.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
This field accommodates the identification of any codes that might be
associated with the pharmaceutical substance. Common codes include: the Generic
Product Identifier (GPI), Generic Code Number_Sequence Number (GCN_SEQNO),
National Drug Code (NDC).
The
Pharmacy/Treatment Route segment contains the alternative combination of route,
site, administration device, and administration method that are prescribed as
they apply to a particular order. The pharmacy, treatment staff 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 |
OPT |
RP/# |
TBL# |
ITEM # |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
250 |
CE |
R |
0162 |
00309 |
Route |
|
2 |
250 |
CE |
O |
0163 |
00310 |
Administration Site |
|
3 |
250 |
CE |
O |
0164 |
00311 |
Administration Device |
|
4 |
250 |
CE |
O |
0165 |
00312 |
Administration Method |
|
5 |
250 |
CE |
O |
01315 |
Routing Instruction |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field is the 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 HL7 Table 0162 -
Route of administration for valid values.
Value |
Description |
Value |
Description |
AP |
Apply Externally |
MM |
Mucous Membrane |
B |
Buccal |
NS |
Nasal |
DT |
Dental |
NG |
Nasogastric |
EP |
Epidural |
NP |
Nasal Prongs* |
ET |
Endotrachial Tube* |
NT |
Nasotrachial Tube |
GTT |
Gastrostomy Tube |
OP |
Ophthalmic |
GU |
GU Irrigant |
OT |
Otic |
IMR |
Immerse (Soak) Body Part |
OTH |
Other/Miscellaneous |
IA |
Intra-arterial |
PF |
Perfusion |
IB |
Intrabursal |
PO |
Oral |
IC |
Intracardiac |
PR |
Rectal |
ICV |
Intracervical (uterus) |
RM |
Rebreather Mask* |
ID |
Intradermal |
SD |
Soaked Dressing |
IH |
Inhalation |
SC |
Subcutaneous |
IHA |
Intrahepatic Artery |
SL |
Sublingual |
IM |
Intramuscular |
TP |
Topical |
IN |
Intranasal |
TRA |
Tracheostomy* |
IO |
Intraocular |
TD |
Transdermal |
IP |
Intraperitoneal |
TL |
Translingual |
IS |
Intrasynovial |
UR |
Urethral |
IT |
Intrathecal |
VG |
Vaginal |
IU |
Intrauterine |
VM |
Ventimask |
IV |
Intravenous |
WND |
Wound |
MTH |
Mouth/Throat |
*used primarily for respiratory therapy and anesthesia delivery
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the site of the administration route. Refer
to HL7 Table 0163 - Body Site for valid values.
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 (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the mechanical device used to aid in the
administration of the drug or other treatment. Common examples are IV-sets of
different types. Refer to HL7 Table 0164 - Administration device
for valid entries.
Value |
Description |
Value |
Description |
AP |
Applicator |
IVS |
IV Soluset |
BT |
Buretrol |
MI |
Metered Inhaler |
HL |
Heparin Lock |
NEB |
Nebulizer |
IPPB |
IPPB |
PCA |
PCA Pump |
IVP |
IV Pump |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field identifies the specific method requested for the
administration of the drug or treatment to the patient. Refer to HL7
Table 0165 - Administration method for valid values.
Value |
Description |
Value |
Description |
CH |
Chew |
NB |
Nebulized |
DI |
Dissolve |
PT |
Pain |
DU |
Dust |
PF |
Perfuse |
IF |
Infiltrate |
SH |
Shampoo |
IS |
Insert |
SO |
Soak |
IR |
Irrigate |
WA |
Wash |
IVPB |
IV Piggyback |
WI |
Wipe |
IVP |
IV Push |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field provides instruction on administration routing,
especially in cases where more than one route of administration is possible. A
typical case would be designating which IV line should be used when more than
one IV line is a possible route for injection.
If
the drug or treatment ordered with the RXO segment is a compound drug OR an IV
solution, AND there is not a coded value for OBR-4-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 or treatment application on substitutions at the RXC level is
identical to that for the RXO level.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM # |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
1 |
ID |
R |
0166 |
00313 |
RX Component Type |
|
2 |
250 |
CE |
R |
00314 |
Component Code |
||
3 |
20 |
NM |
R |
00315 |
Component Amount |
||
4 |
250 |
CE |
R |
00316 |
Component Units |
||
5 |
20 |
NM |
O |
01124 |
Component Strength |
||
6 |
250 |
CE |
O |
01125 |
Component Strength Units |
||
7 |
250 |
CE |
O |
Y |
01476 |
Supplementary Code |
Definition:
Following are the values for this field:
Value |
Description |
B |
Base |
A |
Additive |
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 antimicrobial, 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 (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field is 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
or treatment application must include a manual review or reentering of the
component drug or treatment.
Definition: This field identifies the amount of this component to be added to the specified amount of the base.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field identifies the 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.
Definition: Use when RXC-2-component code does not specify the strength. This is the numeric part of the strength, used in combination with RXC-6-component strength units.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: Use when RXC-2-component code does not specify the
strength. This is the unit of the strength, used in combination with
RXC-5-component strength.
Note: These units can be a "compound quantity;" i.e., the units may
express a quantity per unit of time. For example, micrograms per hour (ug/h)
is an acceptable value. These compound units are contained in the ISO+ table.
See Chapter 7 for full definition of ISO+ units.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
This field accommodates the identification of any codes that might be
associated with the pharmaceutical or other treatment substance. Common codes
include: the Generic Product Identifier (GPI), Generic Code Number_Sequence
Number (GCN_SEQNO), National Drug Code (NDC).
The
RXE segment details the pharmacy or treatment 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-D/T of most recent refill or dose dispensed, 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 or
treatment department has the "authority" (and/or necessity) to schedule
dispense/give events. Hence, the pharmacy or treatment 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 |
OPT |
RP/# |
TBL# |
ITEM # |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
200 |
TQ |
R |
00221 |
Quantity/Timing |
||
2 |
250 |
CE |
R |
0292 |
00317 |
Give Code |
|
3 |
20 |
NM |
R |
00318 |
Give Amount - Minimum |
||
4 |
20 |
NM |
O |
00319 |
Give Amount - Maximum |
||
5 |
250 |
CE |
R |
00320 |
Give Units |
||
6 |
250 |
CE |
O |
00321 |
Give Dosage Form |
||
7 |
250 |
CE |
O |
Y |
00298 |
Provider's Administration Instructions |
|
8 |
200 |
CM |
C |
00299 |
Deliver-to Location |
||
9 |
1 |
ID |
O |
0167 |
00322 |
Substitution Status |
|
10 |
20 |
NM |
C |
00323 |
Dispense Amount |
||
11 |
250 |
CE |
C |
00324 |
Dispense Units |
||
12 |
3 |
NM |
O |
00304 |
Number of Refills |
||
13 |
250 |
XCN |
C |
Y |
00305 |
Ordering Provider's DEA Number |
|
14 |
250 |
XCN |
O |
Y |
00306 |
Pharmacist/Treatment Supplier's Verifier ID |
|
15 |
20 |
ST |
C |
00325 |
Prescription Number |
||
16 |
20 |
NM |
C |
00326 |
Number of Refills Remaining |
||
17 |
20 |
NM |
C |
00327 |
Number of Refills/Doses Dispensed |
||
18 |
26 |
TS |
C |
00328 |
D/T of Most Recent Refill or Dose Dispensed |
||
19 |
10 |
CQ |
C |
00329 |
Total Daily Dose |
||
20 |
1 |
ID |
O |
0136 |
00307 |
Needs Human Review |
|
21 |
250 |
CE |
O |
Y |
00330 |
Pharmacy/Treatment Supplier's Special Dispensing Instructions |
|
22 |
20 |
ST |
C |
00331 |
Give Per (Time Unit) |
||
23 |
6 |
ST |
O |
00332 |
Give Rate Amount |
||
24 |
250 |
CE |
O |
00333 |
Give Rate Units |
||
25 |
20 |
NM |
O |
01126 |
Give Strength |
||
26 |
250 |
CE |
O |
01127 |
Give Strength Units |
||
27 |
250 |
CE |
O |
Y |
01128 |
Give Indication |
|
28 |
20 |
NM |
O |
01220 |
Dispense Package Size |
||
29 |
250 |
CE |
O |
01221 |
Dispense Package Size Unit |
||
30 |
2 |
ID |
O |
0321 |
01222 |
Dispense Package Method |
|
31 |
250 |
CE |
O |
Y |
01476 |
Supplementary Code |
Components:
<quantity (CQ)> ^ <interval (CM)> ^ <duration (ST)> ^
<start date/time (TS)> ^ <end date/time (TS)> ^ <priority
(ST)> ^ <condition (ST)> ^ <text (TX)> ^ <conjunction
(ID)> ^ <order sequencing (CM)> ^ <occurrence duration (CE)> ^
<total occurrences(NM)>
Definition: See Section 4.14.4, "RXE - pharmacy/treatment encoded order
segment," for necessary modification for this field's definition to cover
interorder dependencies needed by pharmacy/treatment orders. This field is used
by the pharmacy or non-pharmacy treatment supplier to express the fully-coded
version of the drug or treatment timing. It may differ from
ORC-7-quantity/timing, which contains the requested quantity/timing of
the original order.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field identifies the medical substance or treatment that has
been ordered to be given to the patient, as encoded by the pharmacy or
treatment supplier; 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. Refer to HL7 Table 0292 - Vaccines
administered for valid values.
Definition:
This field contains the ordered amount as encoded by the pharmacy or treatment
supplier. 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/treatment orders, that component
can be used to specify multiples of an ordered amount.
Another way to
say this is that, for pharmacy/treatment orders, the quantity component of the
quantity/timing field refers to what is to be given out at each service
interval; thus, in terms of the RX order, that first component always defaults
to 1. Hence, in the actual execution of the order, the value of 1 in the first
component of the quantity/timing field always refers to one administration of
the amount specified in this field (the requested Give Amount field).
Definition: In a variable dose order, this is the maximum ordered amount. In a nonvarying dose, this field is not used.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the units for the give amount as encoded by
the pharmacy or treatment (e.g., respiratory therapy) 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 (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: The dosage form indicates the manner in which the medication or
treatment is aggregated for dispensing, e.g., tablets, capsules, suppositories.
In some cases, this information is implied by the give code in RXE-2-give
code. Use the RXE-6-give dosage form when the give code does not
specify the dosage form.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the ordering provider's instructions to the
patient or the provider administering the drug or treatment. If coded, a
user-defined table must be used; if free text (describing a custom IV, mixture,
or salve, for example), place the text in the second component, e.g.,
|^this is a free text administration instruction|.
Components:
<point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^
<facility (HD)> ^ <location status (IS)> ^ <patient location
type (IS)> ^ <building (IS)> ^ <floor (IS)>
<address(AD)>
Subcomponents of facility: <namespace ID (IS)> & <universal
ID (ST)> & <universal ID type (ID)>
Subcomponents of address (AD): <street address (ST)> & <
other designation (ST)> & <city (ST)> & <state or province
(ST)> & <zip or postal code (ST)> & <country (ID)> &
<address type (ID)> & <other geographic designation
(ST)>
Definition: The first component contains the inpatient or outpatient location
to which the pharmacy or treatment supplier is to deliver the drug or treatment
(if applicable). The default (null) value is the current census location for
the patient. Site-specific table. The first eight components have the same
form as the first eight components of PV1-3-assigned patient location.
The final eight components replace the ninth component of PV1-3-assigned
patient location and represent the full address specification.
Definition:
Refer to HL7 Table 0167 - Substitution status for valid values.
If a substitution has been made, and a record of the original requested give
code (RXO-1-requested give code) 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. |
G |
A generic substitution was dispensed. |
T |
A therapeutic substitution was dispensed. |
0 |
No product selection indicated |
1 |
Substitution not allowed by prescriber |
2 |
Substitution allowed - patient requested product dispensed |
3 |
Substitution allowed - pharmacist selected product dispensed |
4 |
Substitution allowed - generic drug not in stock |
5 |
Substitution allowed - brand drug dispensed as a generic |
7 |
Substitution not allowed - brand drug mandated by law |
8 |
Substitution allowed - generic drug not available in marketplace |
Definition: This field contains the amount dispensed as encoded by the pharmacy or treatment supplier.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the units for the dispense amount as encoded
by the pharmacy or treatment supplier. This field is required if the units are
not 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.
Definition: This field contains the total original number of refills. Outpatient only.
Components:
In Version 2.3 and later, use instead of the CN data type. <ID number
(ST)> ^ <family name (FN)> ^ <given name (ST)> ^ <second or
further given names or initials thereof (ST)> ^ <suffix (e.g., JR or III)
(ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (IS)> ^
<source table (IS)> ^ <assigning authority (HD)> ^ <name type
code (ID)> ^ <identifier check digit (ST)> ^ <code identifying the
check digit scheme employed (ID)> ^ <identifier type code (IS)> ^
<assigning facility (HD)> ^ <name representation code (ID)> ^
<name context (CE)> ^ <name validity range (DR)> ^ < name
assembly order (ID)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)
Subcomponents of assigning facility: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)
Definition: This field is defined as conditional because it is required when
the substance requested is a controlled substance (e.g., a narcotic).
Components:
In Version 2.3 and later, use instead of the CN data type. <ID number
(ST)> ^ <family name (FN)> ^ <given name (ST)> ^ <second or
further given names or initials thereof (ST)> ^ <suffix (e.g., JR or III)
(ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (IS)> ^
<source table (IS)> ^ <assigning authority (HD)> ^ <name type
code (ID)> ^ <identifier check digit (ST)> ^ <code identifying the
check digit scheme employed (ID)> ^ <identifier type code (IS)> ^
<assigning facility (HD)> ^ <name representation code (ID)> ^
<name context (CE)> ^ <name validity range (DR)> ^ < name
assembly order (ID)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)
Subcomponents of assigning facility: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)
Definition: This field contains the provider ID of Pharmacist/treatment
supplier's verifier. Use if required by the pharmacy or treatment application
or site on orders (or some subgroup of orders).
Definition: This field contains the prescription number as assigned by the pharmacy or treatment application. Equivalent in uniqueness to the pharmacy/treatment filler order number. At some sites, this may be the pharmacy or treatment system (internal) sequential form. At other sites, this may be an external form. This is a required field in RXE when used in pharmacy/treatment messages, but it is not required when used in product experience messages (see Chapter 7).
Definition: Number of refills remaining. This field is conditional because it is required when a prescription is dispensed to an outpatient. It is not relevant to inpatient treatment orders.
Definition: Number of refills remaining. This field is conditional because it is required when a prescription is dispensed to an outpatient. It is not relevant to inpatient treatment orders.
Definition: Date/time of the most recent refill or dose dispensed.
Components:
<quantity (NM)> ^ <units (CE)>
Subcomponents of units: <identifier (ST)> & <text (ST)>
& <name of coding system (IS)> & <alternate identifier
(ST)> & <alternate text (ST)> & <name of alternate coding
system (IS)>
Definition: This field contains the total daily dose for this particular
pharmaceutical as expressed in terms of actual dispense units.
Definition:
This field uses HL7 table 0136 - Yes/no indicator. The values
have the following meaning for this field:
Y Yes - Indicates that a warning is present. The application receiving the
encoded order needs to warn the person administering the drug or treatment to
pay attention to the text in RXE-21-pharmacy/treatment special dispensing
instructions.
N No - Indicates no warning is present. This is the equivalent default (null)
value.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the pharmacy or treatment supplier's
provider-generated special instructions to the provider
dispensing/administering the order.
Definition:
This field contains the 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 |
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 |
This
is the same as the format specified for the DURATION component of the
quantity/timing field, excluding the "X" specification.
This field is defined as conditional because it is required when the ordered
substance is to be administered continuously at a prescribed rate (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: This field contains the rate at which the substance should be administered.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the units for RXE-23-give rate amount.
May be composite. The ratio of the RXE-23-give rate amount and
RXE-24-give rate units defines the actual rate of administration. Thus,
if RXE-23-give rate amount = 100 and RXE-24-give rate units =
ml/hr, the requested rate of administration is 100 ml/hr. (See ISO+ Figure 7-13
in Chapter 7 for possible compound units codes.)
Definition: Use when RXE-2-give code does not specify the strength. This is the numeric part of the strength, used in combination with RXE-26-give strength units.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: Use when RXE-2-give code does not specify the strength.
This is the unit of the strength, used in combination with RXE-25-give
strength.
Note: These units can be a "compound quantity"; i.e., the units may
express a quantity per unit of time. For example, micrograms per hour (ug/h)
is an acceptable value. These compound units are contained in the ISO+ table.
See Chapter 7 for full definition of ISO+ units.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field identifies the condition or problem for which the
drug/treatment was prescribed. May repeat if multiple indications are relevant.
Definition: This field contains the size of package to be dispensed. Units are transmitted in RXE-29-dispense package size unit.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the units in which RXE-28-dispense package
size is denominated.
Definition:
This field contains the method by which treatment is dispensed. Refer to
HL7 Table 0321 - Dispense method for valid values.
Value |
Description |
TR |
Traditional |
UD |
Unit Dose |
F |
Floor Stock |
AD |
Automatic Dispensing |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field accommodates the identification of any codes that might
be associated with the pharmaceutical substance. Common codes include: the
Generic Product Identifier (GPI), Generic Code Number_Sequence Number
(GCN_SEQNO), National Drug Code (NDC).
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM # |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
4 |
NM |
R |
00334 |
Dispense Sub-ID Counter |
||
2 |
250 |
CE |
R |
0292 |
00335 |
Dispense/Give Code |
|
3 |
26 |
TS |
R |
00336 |
Date/Time Dispensed |
||
4 |
20 |
NM |
R |
00337 |
Actual Dispense Amount |
||
5 |
250 |
CE |
C |
00338 |
Actual Dispense Units |
||
6 |
250 |
CE |
O |
00339 |
Actual Dosage Form |
||
7 |
20 |
ST |
R |
00325 |
Prescription Number |
||
8 |
20 |
NM |
C |
00326 |
Number of Refills Remaining |
||
9 |
200 |
ST |
O |
Y |
00340 |
Dispense Notes |
|
10 |
200 |
XCN |
O |
Y |
00341 |
Dispensing Provider |
|
11 |
1 |
ID |
O |
0167 |
00322 |
Substitution Status |
|
12 |
10 |
CQ |
O |
00329 |
Total Daily Dose |
||
13 |
200 |
CM |
C |
01303 |
Dispense-to Location |
||
14 |
1 |
ID |
O |
0136 |
00307 |
Needs Human Review |
|
15 |
250 |
CE |
O |
Y |
00330 |
Pharmacy/Treatment Supplier's Special Dispensing Instructions |
|
16 |
20 |
NM |
O |
01132 |
Actual Strength |
||
17 |
250 |
CE |
O |
01133 |
Actual Strength Unit |
||
18 |
20 |
ST |
O |
Y |
01129 |
Substance Lot Number |
|
19 |
26 |
TS |
O |
Y |
01130 |
Substance Expiration Date |
|
20 |
250 |
CE |
O |
Y |
0227 |
01131 |
Substance Manufacturer Name |
21 |
250 |
CE |
O |
Y |
01123 |
Indication |
|
22 |
20 |
NM |
O |
01220 |
Dispense Package Size |
||
23 |
250 |
CE |
O |
01221 |
Dispense Package Size Unit |
||
24 |
2 |
ID |
O |
0321 |
01222 |
Dispense Package Method |
|
25 |
250 |
CE |
O |
Y |
01476 |
Supplementary Code |
|
26 |
250 |
CE |
O |
01477 |
Initiating Location |
||
27 |
250 |
CE |
O |
01478 |
Packaging/Assembly Location |
Definition: This field starts with 1 the first time that medication/treatment is delivered/dispensed for this order. Increments by one with each additional issuance.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field identifies the medical substance or treatment ordered
to be given to the patient; it is equivalent to OBR-4-universal service
ID. See the RXE segment for a complete definition of the RXE-2-give
code. If the substance dispensed is a vaccine, CVX codes may be used to
code this field (see HL7 table 0292 - Vaccines administered).
Note: The contents of RXD-2-dispense/give code should be
compatible with the comparable field in the RXE (RXE-2-give code). The
RDS message refers ONLY to the dispensing of the drug or treatment by the
pharmacy or treatment supplier.
Definition: This field indicates when the pharmaceutical/treatment is dispensed from the pharmacy or treatment supplier. Use the time stamp format.
Definition: This field indicates the amount dispensed.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field indicates the units dispensed. Site-defined table.
This field is required if the units are not implied by the actual dispense
code. 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 (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: The dosage form indicates the manner in which the
medication/treatment is aggregated for dispensing, e.g., tablets, capsules,
suppositories. In some cases, this information is implied by the dispense/give
code in RXD-2-dispense/give code. Use this field when the give code and
the dispense code do not specify the dosage form.
Definition: This field is equivalent in uniqueness to the pharmacy/treatment supplier filler order number. At some sites, this may be the pharmacy/treatment supplier (internal) sequential form. At other sites, this may be an external number.
Definition: This field is conditional because it is required when a prescription is dispensed to an outpatient. It is not relevant to inpatient treatment orders.
Definition: This field contains free text notes to the person dispensing the medication/treatment (may include the ordering provider's original notes, as well as any notes from the formulary or the pharmacy or treatment supplier). This may contain free text describing a custom IV, mixture, or salve for example.
Components:
In Version 2.3 and later, use instead of the CN data type. <ID number
(ST)> ^ <family name (FN)> ^ <given name (ST)> ^ <second or
further given names or initials thereof (ST)> ^ <suffix (e.g., JR or III)
(ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (IS)> ^
<source table (IS)> ^ <assigning authority (HD)> ^ <name type
code (ID)> ^ <identifier check digit (ST)> ^ <code identifying the
check digit scheme employed (ID)> ^ <identifier type code (IS)> ^
<assigning facility (HD)> ^ <name representation code (ID)> ^
<name context (CE)> ^ <name validity range (DR)> ^ < name
assembly order (ID)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)
Subcomponents of assigning facility: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)
Definition: This field contains the provider ID of the person dispensing the
pharmaceutical.
Definition: Refer to HL7 Table 0167 - Substitution status for suggested values.
Components:
<quantity (CQ)> ^ <interval (CM)> ^ <duration> ^ <start
date/time (TS)> ^ <end date/time (TS)> ^ <priority (ID)> ^
<condition (ST)> ^ <rtext (TX)> ^ <conjunction (ID)> ^
<order sequencing>
Definition: This field contains the 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:
<point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^
<facility (HD)> ^ <location status (IS)> ^ <patient location
type (IS)> ^ <building (IS)> ^ <floor (IS)> ^ <street
address (ST)> ^ <other designation (ST)> ^ <city (ST)> ^
<state or province (ST)> ^ <zip or postal code (ST)> ^ <country
(ID)> ^ <address type (ID)> ^ <other geographic designation
(ST)>
Subcomponents of facility(HD): <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Definition: The first component (which is of PL data type with the component
delimiters demoted to subcomponents) contains the inpatient or outpatient
location where the drug or treatment was dispensed (if applicable). The
default (null) value is the current census location for the patient.
Site-specific table. The first eight components have the same form as the
first eight components of PV1-3-assigned patient location. The final
eight components replace the ninth component of PV1-3-assigned patient
location and represent the full address specification.
Definition:
Refer to HL7 table 0136 - Yes/no indicator for valid values. The
values have the following meaning for this field:
Y Yes - Indicates that a warning is present. The application receiving the
dispense order needs to warn the person dispensing/administering the drug or
treatment to pay attention to the text in RXD-15-pharmacy/treatment
supplier's special dispensing instructions.
N No - Indicates no warning is present. This is the equivalent default (null)
value.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains pharmacy or treatment supplier-generated
special instructions to the provider dispensing/administering the order.
Definition: Use when RXD-2-dispense/give code does not specify the strength. This is the numeric part of the strength, of a single dosage unit of the dispensed product, used in combination with RXD-17-actual strength unit.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: Use when RXD-2-dispense/give code does not specify the
strength. This is the unit of the strength, of a single dosage unit of the
dispensed product, used in combination with RXD-16-actual strength.
Note: These units can be a "compound quantity;" i.e., the units may
express a quantity per unit of time. For example, micrograms per hour (ug/h)
is an acceptable value. These compound units are contained in the ISO+ table.
See Chapter 7 for full definition of ISO+ units.
Definition:
This field contains the lot number of the medical substance administered.
Note: The lot number is the number printed on the label attached to the
container holding the substance and on the packaging which houses the
container. If the substance is a vaccine, for example, and a diluent is
required, a lot number may appear on the vial containing the diluent; however,
any such identifier associated with a diluent is not the identifier of
interest. The substance lot number should be reported, not that of the diluent.
Definition:
This field contains the expiration date of the medical substance
administered.
Note: Vaccine expiration date does not always have a "day" component;
therefore, such a date may be transmitted as YYYYMM^L.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the manufacturer of the medical substance
administered when it is a manufactured substance.
Note: For vaccines, code system MVX may be used to code this field. See
Section 4.17.1. This field may be used if the manufacturer of the substance is
not identified by the code used in RXA-5-Administered code.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the identifier of the condition or problem for
which the drug/treatment was prescribed. May repeat if multiple indications
are relevant.
Definition: This field contains the size of package to be dispensed. Units are transmitted in RXD-23-dispense package size unit.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the units in which RXE-28-dispense package
size is denominated. The advertised number of units in the manufacturers
package i.e., the package as it comes from the supplier
Definition: This field contains the method by which treatment is dispensed. Refer to HL7 Table 0321 - Dispense method for valid values.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field accommodates the identification of any codes that might
be associated with the pharmaceutical substance. Common codes include: the
Generic Product Identifier (GPI), Generic Code Number_Sequence Number
(GCN_SEQNO), National Drug Code (NDC).
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field identifies the pharmacy or other treatment dispensing
service (e.g., respiratory) that received the initial request.
Example: Pharmacy A (the Intake/Receiving) receives a phone call from the
patient requesting a medication refill, but stipulates that the prescription
will be picked up in pharmacy B. In accordance with the business process the
prescription will be packaged/assembled in Pharmacy C.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field identifies the pharmacy which packaged/assembled request.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM # |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
4 |
NM |
R |
00342 |
Give Sub-ID Counter |
||
2 |
4 |
NM |
O |
00334 |
Dispense Sub-ID Counter |
||
3 |
200 |
TQ |
R |
00221 |
Quantity/Timing |
||
4 |
250 |
CE |
R |
0292 |
00317 |
Give Code |
|
5 |
20 |
NM |
R |
00318 |
Give Amount - Minimum |
||
6 |
20 |
NM |
O |
00319 |
Give Amount - Maximum |
||
7 |
250 |
CE |
R |
00320 |
Give Units |
||
8 |
250 |
CE |
O |
00321 |
Give Dosage Form |
||
9 |
250 |
CE |
O |
Y |
00351 |
Administration Notes |
|
10 |
1 |
ID |
O |
0167 |
00322 |
Substitution Status |
|
11 |
200 |
CM |
O |
01303 |
Dispense-To Location |
||
12 |
1 |
ID |
O |
0136 |
00307 |
Needs Human Review |
|
13 |
250 |
CE |
O |
Y |
00343 |
Pharmacy/Treatment Supplier's Special Administration Instructions |
|
14 |
20 |
ST |
C |
00331 |
Give Per (Time Unit) |
||
15 |
6 |
ST |
O |
00332 |
Give Rate Amount |
||
16 |
250 |
CE |
O |
00333 |
Give Rate Units |
||
17 |
20 |
NM |
O |
01126 |
Give Strength |
||
18 |
250 |
CE |
O |
01127 |
Give Strength Units |
||
19 |
20 |
ST |
O |
Y |
01129 |
Substance Lot Number |
|
20 |
26 |
TS |
O |
Y |
01130 |
Substance Expiration Date |
|
21 |
250 |
CE |
O |
Y |
0227 |
01131 |
Substance Manufacturer Name |
22 |
250 |
CE |
O |
Y |
01123 |
Indication |
Definition:
Use if this RXG segment carries information about a single administration.
Starts with 1 for the first scheduled give date/time transmitted by the
pharmacy/treatment supplier for this order. Increments by one with each
additional scheduled give date/time for this order.
If the RXG segment carries information about multiple administrations, this
field's value is zero (0), since in this case a one-to-one matching with the
RXA segment is ambiguous.
Definition: This is the dispense sub-ID to which this give message is related.
Components:
<quantity (CQ)> ^ <interval (CM)> ^ <duration (ST)> ^
<start date/time (TS)> ^ <end date/time (TS)> ^ <priority
(ST)> ^ <condition (ST)> ^ <text (TX)> ^ <conjunction
(ID)> ^ <order sequencing (CM)> ^ <occurrence duration (CE)> ^
<total occurrences(NM)>
Definition: This field contains the 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 (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field is the identifier of the medical substance/treatment
ordered to be given to the patient; it is equivalent to OBR-4-Universal
service ID in function. See the RXE segment for a complete definition of
the RXE-2-Give code. If the substance given is a vaccine, CVX codes may
be used to code this field (see HL7 table 0292 - Vaccines administered).
Definition:
This field contains the ordered amount as encoded by the pharmacy/treatment
supplier. 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/treatment orders, that component
can be used to specify multiples of an ordered amount.
Another way to
say this is that, for pharmacy/treatment orders, the quantity component of the
quantity/timing field refers to what is to be given out at each service
interval; and thus, in terms of the RX order, that first component always
defaults to 1. Hence, in the actual execution of the order, the value of 1 in
the first component of the quantity/timing field always refers to one
administration of the amount specified in this field (the requested Give Amount
field).
Definition: In a variable dose order, this is the maximum ordered amount. In a nonvarying dose order, this field is not used.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the 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 (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: The dosage form indicates the manner in which the
medication/treatment is aggregated for dispensing, e.g., tablets, capsules,
suppositories. In some cases, this information is implied by the give code
in RXG-4-give code. Use this field when the give code does not specify
the dosage form.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains notes to the person administering the
medication/treatment (may include the ordering provider's original notes, as
well as any notes from the formulary or the pharmacy or treatment supplier).
If coded, a user-defined table must be used. If free text, place a null in the
first component and the text in the second, e.g., |^this is a free text
administration note|.
Definition:
Refer to HL7 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:
<point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^
<facility (HD)> ^ <location status (IS)> ^ <patient location
type (IS)> ^ <building (IS)> ^ <floor (IS)> ^ <street
address (ST)> ^ <other designation (ST)> ^ <city (ST)> ^
<state or province (ST)> ^ <zip or postal code (ST)> ^ <country
(ID)> ^ <address type (ID)> ^ <other geographic designation
(ST)>
Subcomponents of facility(HD): <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Definition: The first component contains the inpatient or outpatient location
where the drug or treatment was dispensed (if applicable). The default (null)
value is the current census location for the patient. Site-specific table.
The first eight components have the same form as the first eight components of
PV1-3-assigned patient location. The final eight components replace the
ninth component of PV1-3-assigned patient location and represent the
full address specification.
Definition:
Refer to HL7 table 0136 - Yes/no indicator for valid values.
The values have the following meaning for this field:
Y Yes - Indicates that a warning is present. The application receiving the
dispense order needs to warn the person dispensing/administering the drug or
treatment to pay attention to the text in
RXG-13-pharmacy/treatment supplier's special administration
instructions.
N No - Indicates no warning is present. This is the equivalent default (null)
value.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains pharmacy/treatment supplier-generated special
instructions to the provider administering the order.
Definition:
This field contains the time unit to use to calculate the rate at which the
pharmaceutical/treatment 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 |
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 |
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: This field contains the amount (number) of substance/treatment to be administered.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the units for RXG-15-give rate amount.
May be composite. The ratio of the RXG-15-give rate amount and
RXG-16-give rate units fields define the actual rate of administration.
Thus, if RXG-15-give rate amount = 100 and RXG-16-give rate units
= ml/hr, the requested rate of administration is 100 ml/hr.
Definition: Use when RXG-4-Give code does not specify the strength. This is the numeric part of the strength, used in combination with RXG-18-Give strength units.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: Use when RXG-4-Give code does not specify the strength.
This is the unit of the strength, used in combination with RXG-17-Give
strength.
Note: These units can be a "compound quantity"; i.e., the units may
express a quantity per unit of time. For example, micrograms per hour (ug/h)
is an acceptable value. These compound units are contained in the ISO+ table.
See Chapter 7 for full definition of ISO+ units.
Definition:
This field contains the lot number of the medical substance administered.
Note: The lot number is the number printed on the label attached to the
container holding the substance and on the packaging which houses the
container. If the substance is a vaccine, for example, and a diluent is
required, a lot number may appear on the vial containing the diluent; however,
any such identifier associated with a diluent is not the identifier of
interest. The substance lot number should be reported, not that of the diluent.
Definition:
This field contains the expiration date of the medical substance
administered.
Note: Vaccine expiration date does not always have a "day" component;
therefore, such a date may be transmitted as YYYYMM.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the manufacturer of the medical substance
administered.
Note: For vaccines, code system MVX may be used to code this field (see
Section 4.17.1, "Vaccine administration data"). This field may be used if the
manufacturer of the substance is not identified by the code used
in RXA-5-administered code.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the identifier of the condition or problem for
which the drug/treatment was prescribed. May repeat if multiple indications
are relevant.
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 |
OPT |
RP/# |
TBL# |
ITEM # |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
4 |
NM |
R |
00342 |
Give Sub-ID Counter |
||
2 |
4 |
NM |
R |
00344 |
Administration Sub-ID Counter |
||
3 |
26 |
TS |
R |
00345 |
Date/Time Start of Administration |
||
4 |
26 |
TS |
R |
00346 |
Date/Time End of Administration |
||
5 |
250 |
CE |
R |
0292 |
00347 |
Administered Code |
|
6 |
20 |
NM |
R |
00348 |
Administered Amount |
||
7 |
250 |
CE |
C |
00349 |
Administered Units |
||
8 |
250 |
CE |
O |
00350 |
Administered Dosage Form |
||
9 |
250 |
CE |
O |
Y |
00351 |
Administration Notes |
|
10 |
250 |
XCN |
O |
Y |
00352 |
Administering Provider |
|
11 |
200 |
CM |
C |
00353 |
Administered-at Location |
||
12 |
20 |
ST |
C |
00354 |
Administered Per (Time Unit) |
||
13 |
20 |
NM |
O |
01134 |
Administered Strength |
||
14 |
250 |
CE |
O |
01135 |
Administered Strength Units |
||
15 |
20 |
ST |
O |
Y |
01129 |
Substance Lot Number |
|
16 |
26 |
TS |
O |
Y |
01130 |
Substance Expiration Date |
|
17 |
250 |
CE |
O |
Y |
0227 |
01131 |
Substance Manufacturer Name |
18 |
250 |
CE |
O |
Y |
01136 |
Substance/Treatment Refusal Reason |
|
19 |
250 |
CE |
O |
Y |
01123 |
Indication |
|
20 |
2 |
ID |
O |
0322 |
01223 |
Completion Status |
|
21 |
2 |
ID |
O |
0323 |
01224 |
Action Code-RXA |
|
22 |
26 |
TS |
O |
01225 |
System Entry Date/Time |
Definition: Use this field 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 (0).
Definition:
This field starts with 1 the first time that medication/treatment is
administered for this order. Increments by one with each additional
administration the medication/treatment.
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 administration
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 RXA-12-administered per (time unit) of the same message.
Definition: If null, the date/time of RXA-3-date/time start of administration is assumed.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the identifier of the medical
substance/treatment administered. It is equivalent to OBR-4-universal
service ID in function. If the substance administered is a vaccine, CVX
codes may be used to code this field (see HL7 Table 0292 - Vaccines
administered).
Definition: This field contains the amount administered.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field is conditional because it is required if the
administered amount code does not imply units. This field must be in simple
units that reflect the actual quantity of the substance administered. It does
not include compound units.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: The dosage form indicates the manner in which the
medication/treatment is aggregated for dispensing, e.g., tablets, capsules,
suppositories. In some cases, this information is implied by the dispense/give
code in RXA-5-Administered code. Use this field when the administered
code does not specify the dosage form.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains notes from the provider administering the
medication/treatment. If coded, requires a user-defined table. If free text
(describing a custom IV, mixture, or salve, for example) place a null in the
first component and the text in the second, e.g., |^this is a free text
administration note|.
Components:
In Version 2.3 and later, use instead of the CN data type. <ID number
(ST)> ^ <family name (FN)> ^ <given name (ST)> ^ <second or
further given names or initials thereof (ST)> ^ <suffix (e.g., JR or III)
(ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (IS)> ^
<source table (IS)> ^ <assigning authority (HD)> ^ <name type
code (ID)> ^ <identifier check digit (ST)> ^ <code identifying the
check digit scheme employed (ID)> ^ <identifier type code (IS)> ^
<assigning facility (HD)> ^ <name representation code (ID)> ^
<name context (CE)> ^ <name validity range (DR)> ^ < name
assembly order (ID)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)
Subcomponents of assigning facility: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)
Definition: This field contains the provider ID of the person administering
the pharmaceutical/treatment.
Components:
<point of care (IS)> ^ <room (IS) ^ <bed (IS)> ^ <facility
(HD) ^ <location status (IS) ^ <patient location type (IS)> ^
<building (IS)> ^ <floor (IS)> ^ < street address (ST)> ^
<other designation (ST)> ^ <city (ST)> ^ <state or province
(ST)> ^ <zip or postal code (ST)> ^ <country (ID)> ^ <address
type (ID)> ^ <other geographic designation (ST)>
Subcomponents of facility (HD): <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Definition: The first component contains the inpatient or outpatient location
at which the drug or treatment was administered (if applicable). The default
(null) value is the current census location for the patient. Site-specific
table. The first eight components have the same form as the first eight
components of PV1-3-assigned patient location. The final eight
components replace the ninth component of PV1-3-assigned patient location
and represent the full address specification.
Definition: This field contains the rate at which this medication/treatment was administered as calculated by using RXA-6-administered amount and RXA-7-administered units. This field is conditional because it is required when a treatment is administered continuously at a prescribed rate, e.g., certain IV solutions.
Definition: Use when RXA-5-Administered code does not specify the strength. This is the numeric part of the strength, used in combination with RXA-14-Administered strength units.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: Use when RXA-5-Administered code does not specify the
strength. This is the unit of the strength, used in combination with
RXA-13-Administered strength.
Note: These units can be a "compound quantity;" i.e., the units may
express a quantity per unit of time. For example, micrograms per hour (ug/h)
is an acceptable value. These compound units are contained in the ISO+ table.
See Chapter 7 for full definition of ISO+ units.
Definition:
This field contains the lot number of the medical substance administered.
Note: The lot number is the number printed on the label attached to the
container holding the substance and on the packaging which houses the
container. If the substance is a vaccine, for example, and a diluent is
required, a lot number may appear on the vial containing the diluent; however,
any such identifier associated with a diluent is not the identifier of
interest. The substance lot number should be reported, not that of the diluent.
Definition:
This field contains the expiration date of the medical substance
administered.
Note: Vaccine expiration date does not always have a "day" component;
therefore, such a date may be transmitted as YYYYMM.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the manufacturer of the medical substance
administered.
Note: For vaccines, code system MVX may be used to code this field).
See Section 4.17.1. This field may be used if the manufacturer of the substance
is not identified by the code used in RXA-5- administered code.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the reason the patient refused the medical
substance/treatment. Any entry in the field indicates that the patient did not
take the substance.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the identifier of the condition or problem for
which the drug/treatment was prescribed. May repeat if multiple indications
are relevant.
Value |
Description |
CP |
Complete |
RE |
Refused |
NA |
Not Administered |
PA |
Partially Administered |
Definition:
Status of record. The information in this field enables the use of the RXA in
the vaccine messages (see Section 4.18, "Vaccine Segments"), where a method of
correcting vaccination information transmitted with incorrect patient
identifying information is needed. Refer to HL7 Table 0323 - Action
code for valid values.
Value |
Description |
A |
Add |
D |
Delete |
U |
Update |
Definition: Date/time the administration information was entered into the source system. This field is used to detect instances where treatment administration information is inadvertently entered multiple times by providing a unique identification field. Under usual circumstances, this field would be provided automatically by the computer system rather than being entered by a person.
The purpose of this section is to show how certain specific situations would be handled using the pharmacy/treatment 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/treatment instructions or RXO-7-provider's administration
instructions only); fully encoded version must be re-entered or verified
manually by the pharmacy or treatment 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 override 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|^&~\|Pharm|GenHosp|CIS|GenHosp|1998052911150700||OMP^O09|...<cr>
PID|...<cr>
ORC|NW|1000^OE||||E|...<cr>
RXO||||||500 mg Polycillin Q6H for 10 days, dispense 40
Tablets|...<cr>
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|^&~\|Pharm|GenHosp|CIS|GenHosp|1998052911150700||OMP^O09|...<cr>
PID|...<cr>
ORC|NW|1000^OE||||E|^Q6H^D10^^^R|...<cr>
RXO|^Polycillin 500 mg TAB^|500||MG|||||Y||40|...<cr>
RXR|PO|...<cr>
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|^&~\|Pharm|GenHosp|CIS|GenHosp|1998052911150700||OMP^O09|...<cr>
PID|...<cr>
ORC|NW|1000^OE||||E|^Q6H^D10^^^R|...<cr>
RXO|RX1001^Polycillin^L|500||MG|||||Y||40|...<cr>
RXR|PO|...<cr>
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|^&~\|Pharm|GenHosp|CIS|GenHosp|1998052911150700||OMP^O09|...<cr>
PID|...<cr>
ORC|NW|1000^OE||||E|^Q6H^D10^^^R|...<cr>
RXO|RX1001^Polycillin 500 mg TAB^L|500||MG|||||G||40|...<cr>
RXR|PO|...<cr>
e) Pharmacy or treatment supplier's encoded version (RDE message) sent to
nursing application (a generic substitution).
MSH|^&~\|Pharm|GenHosp|CIS|GenHosp|1998052911150700||RDE^O11|...<cr>
PID|...<cr>
ORC|RE|1000^OE|9999999^RX|||E|^Q6H^D10^^^R|...<cr>
RXE|^^^199012100600^^R|0047-0402-30^Ampicillin 250 MG
TAB^NDC|2||TAB|||||G|80||||123456|rx#1001|...<cr>
RXR|PO|...<cr>
f) Pharmacy or treatment supplier's dispense results (RDS message).
MSH|...<cr>
PID|...<cr>
ORC|RE|1000^OE|9999999^RX|||E|^Q6H^D10^^^R|...<cr>
RXD|1|0047-0402-30^Ampicillin 250 MG TAB^NDC|199012100400|8|TAB||RX#1001|||
123456|G|8|...<cr>
g) Pharmacy or treatment supplier's give results (RGV message).
MSH|^&~\|Pharm|GenHosp|CIS|GenHosp|1998052911150700||RGV^O15|...<cr>
PID|...<cr>
ORC|RE|1000^OE|9999999^RX|||E|^Q6H^D10^^^R|...<cr>
RXG|1|1|^^199012100600^^R|0047-0402-30^Ampicillin 250 MG
TAB^NDC|500||MG|||G|...<cr>
RXR|PO|...<cr>
h) Nursing application Medications Administration results to pharmacy,
treatment, or Order Entry application.
MSH|^&~\|Pharm|GenHosp|CIS|GenHosp|1998052911150700||RAS^O17|...<cr>
PID|...<cr>
ORC|RE|1000^OE|9999999^RX|||E|^Q6H^D10^^^R|...<cr>
RXA|1|1|199012100615||0047-0402-30^Ampicillin 250 MG
TAB^NDC|2|TAB|...<cr>
RXR|PO|...<cr>
a)
RXO-1 Requested Give code example
RXO|58160040000110^Fluoxetine HCL 10mg Capsule^GPI^00777310402^Prozac 10 mg
caps^NDC|...<cr>
b) RXO-18 and RXO-19 Requested Strength and Strength Unit examples
The need for strength and strength unit fields in addition to the amount and
amount units fields included in various RX_ segments requires explanation.
Physicians can write a prescription for a drug such as Ampicillin in two ways.
One way would be: "Ampicillin 250 mg capsules, 2 capsules four times a day."
In this case the give amount would be 2, the give units would be capsules, the
strength would be 250 and the strength units would milligrams.
ORC|||||||1^QID|...<cr>
RXO|01200020200105^Ampicillin 250 mg capsule^GPI^00047040230^Ampicillin 250 mg
caps^NDC|2||caps^capsule^FDB||||||||||||||250|mg|...<cr>
However, the provider could also write the prescription as "Ampicillin 500 mg
four times a day." In this case the give amount would be 500 and the give
units would be milligrams. The strength would not be reported in the RXO
segment because it is not specified; the drug could be given in two 250 mg caps
or one 500 mg cap. But the pharmacist would dispense a specific capsule size
and would record the strength in the RXE segment as 250 or 500, depending upon
which pill size was dispensed.
ORC|||||||1^QID|...<cr>
RXO|012000202001^Ampicillin capsule^GPI |500||mg^milligram^ISO||...<cr>
a)
RXD-4 and RXD-5 Dispense amount and Actual dispense units
The RXD-4 and RXD-5 together might say
100 tabs:
RXD||||100|TAB^tablet^FDB|...<cr>
Or, 100 each
RXD||||100|EA^each^FDB|...<cr>
Or, perhaps a volume, 3 liters
RXD||||3|L^liter^ISO|...<cr>
b) Actual dispense amount, Actual dispense units, Actual strength, Actual
strength units
For example, the RXD-4 , RXD-5, RXD-16 and RXD-17 together might say
100 tabs of 240 mg strength:
RXD||||100|tab^tablet^FDB|||||||||||240|mg|...<cr>
Or, 100 each of 60 units per cc
RXD||||100|EA||||||||||||60|iu/ml^^ISO+|...<cr>
Or, perhaps a volume, 3 liters with 60 grams per liter
RXD||||3|L^liter^ISO|||||||||||60|g/L^^ISO+|...<cr>
c) Valuing the Dispense Package Size Unit
If the package given to the patient is 2, 4 ounce bottles with a strength of
100/5ml, but the cough suppressant is stocked in 1 gallon bottles, then the
field contains 1 gallon.
RXD||||8|ounce^^ISO|||||||||||20|mg/ml|||||1|gal^gallon^ISO|...<cr>
If one were to dispense Mevacor 100 tablets with a strength of 20 mg/tablet,
and the package from the manufacturer is a 60 tablet package, then the fields
reflect 60 tablets (the size of the package stocked by the pharmacy).
RXD||||100|tab^^FDB|||||||||||20|mg|||||60|tab|...<cr>
Example:
Adam Everyman appears in the Pharmacy with a prescription for Veramil 120 mgm
B.I.D. The prescription is filled and the $5 co-pay is collected. The
following RDS message is generated:
MSH|^&~\|PIMS|GenHosp|IE||1998052911150700||RDS^O13^RDS_O13||...<cr>
PID|||555444222111^^^MPI&GenHosp&L^MR||Everyman^Adam||19600614|M||C|99
Oakland #
106^^Pasadena^CA^91131||^^^^^626^5641111|^^^^^626^5647654|||||343132266|||N|...<cr>
ORC|RE||89968665||||||1998052910300700|||77^Hippocrates^Harold^H^III^DR^MD||^^^^^510^
2673600|...<cr>
RXE|1^BID^^19980529|^Verapamil|120||mg^milligram^FDB.MDDB||...<cr>
RXD|1|00378112001^Verapamil Hydrochloride 120 mg TAB^NDC
|199805291115-0700|100|||1331665|3|...<cr>
RXR|PO|...<cr>
FT1|1|||199805291115-0700||CO^Co-Pay^HL70017 |00378112001^Verapamil
Hydrochloride 120 mg TAB^NDC |||1|5&USD^TP|...<cr>
FT1|2|||199805291115-0700||PY^Payment^HL70017 |00378112001^Verapamil
Hydrochloride 120 mg TAB^NDC |||1|5&USD|...<cr>
HL7
Delimiters: <cr> = segment terminator; | = field separator; ^ =
component separator; & = subcomponent separator; ~ = repetition
indicator; \ = escape character
Encoding Note: For readability, these examples do not show encoding of the
subcomponents of the Give Codes (CE data type) in the RXC and RXO segments. In
practice, the subcomponents should be encoded as described in the HL7
specification.
a) Example #1
D5/0.45NaCl 1000mL with 20mEq KCl in every 3rd bottle. Start the KCl in the
3rd bottle of this order. Run in at a rate of 100mL/hr.
(Other message data: placer order #123, placer application ID=SMS,
interval=continuous, start date/time=11/28/94 0900, no stop date/time,
priority=Routine, order sequencing=Cyclical)
This order may be expressed using a parent/child relationship. The parent
order consists of an ORC (and a RXO, incompletely elaborated in this example)
that contains order level information. The repeating bottle cycle of
D5/0.45NaCl 1000mL followed by D5/0.45NaCl 1000mL followed by D5/0.45NaCl +
20mEq KCL 1000mL is represented by three child segments. The placer system may
be treating this as a single order with two bottles, A (D5/0.45NaCl 1000mL @
100mL/hr) and B (D5/0.45NaCl + 20mEq KCL 1000mL @ 100mL/hr), repeating in the
cycle of A-A-B.
The parent:
ORC|NW|123^SMS|||||1^C^^199411280900^^R^^^^C|...<cr>
RXO|Cyclic IV|...<cr>
The first child:
ORC|CH|123A1^SMS|||||1^C^^^^^^^^C&123B&SMS&&&*ES+0M|123|...<cr>
RXO Segment, Requested Give Amount-Minimum: ...|100||ML|...
Requested Give Per (Time Unit): ...|H1|...<cr>
RXR|IV|...<cr>
RXC|B|D5/.45NACL|1000|ML|...<cr>
The second child:
ORC|CH|123A2^SMS|||||1^C^^^^^^^^C&123A1&SMS&&&ES+0M|123|...<cr>
RXO Segment, Requested Give Amount-Minimum: ...|100||ML|...
Requested Give Per (Time Unit): ...|H1|...<cr>
RXR|IV|...<cr>
RXC|B|D5/.45NACL|1000|ML|...<cr>
The third child:
ORC|CH|123B^SMS|||||1^C^^^^^^^^C&123A2&SMS&&&#ES+0M|123|...<cr>
RXO Segment, Requested Give Amount-Minimum: ...|100||ML|...
Requested Give Per (Time Unit): ...|H1|...<cr>
RXR|IV|...<cr>
RXC|B|D5/.45NACL|1000|ML|...<cr>
RXC|A|KCL|20|MEQ|...<cr>
Discussion points:
Placer Order Number - Three alternatives must be discussed for placer order
number.
1. Each child could have its own placer order number.
2. Each child could have the order number of the parent plus some appended
identifier (for examples, 123A or 123.A or 123.1 etc.) that labels each child
or each unique combination of ingredients.
3. In addition to the appended identifier discussed in `B' above, a further
suffix could be attached to uniquely identify each repetition of a particular
member of the sequence. The example (a cycle of bottles `A' and `B' in the
sequence A-A-B) identified the order numbers of the children as 123A1, 123A2,
and 123B, thereby enabling the quantity/timing to be completely unambiguous.
This could be expressed many other ways, such as 123A.1 or 123.A.1 or 123.A#1
etc. HL7 does not specify a format for the expression of order number
suffixes, nor does it specify a delimiter to use for such a purpose.
Sequence Condition Value - In this example, the first child contains an
asterisk (*) as the first character of the Sequence Condition Value and the
third (last) child contains a pound sign (#).
The asterisk and pound sign are important for designating the first and last
bottles especially when children are sent in separate messages, although this
example is not constructed that way.
Note that computing the duration of the bottle is dependent upon the presence
of all of the following fields:
* RXO-2-requested give amount-minimum
* RXO-4-requested give units
* RXC-3-component amount
* RXC-4-component units
For cyclic IV orders, these fields are all required in order to determine how
long each occurrence of a child will last.
While HL7 allows either sending the parent and children in one message or
sending the parent and children in separate messages, it appears simpler and
therefore recommended to have the parent and all children included in a single
message. The example is constructed that way.
b) Example #2
D5W + 40mEq KCl 1000mL alternating with D5/LR + 20mEq KCl 1000mL at 125mL/hr
(Other message data: placer order #124, placer application ID=SMS,
interval=continuous, start date/time=11/28/94 0900, no stop date/time,
priority=Routine, order sequencing=Cyclical)
This example is a variation on the first example where two different base
solutions are used. In this example, the placer system deals with this as one
order with two alternating bottles, A (D5W + 40mEq KCl 1000mL @ 125mL/hr) and B
(D5/LR + 20mEq KCl 1000mL @ 125mL/hr) in the cycle A-B. The principles
discussed in Example #1 apply equally to this example.
The parent:
ORC|NW|124^SMS|||||1^C^^199411280900^^R^^^^C|...<cr>
RXO|Cyclic IV|...<cr>
The first child:
ORC|CH|124A^SMS|||||1^C^^^^^^^^C&124B&SMS&&&*ES+0M|124|...<cr>
RXO Segment, Requested Give Amount-Minimum: ...|125||ML|...
Requested Give Per (Time Unit): ...|H1|...<cr>
RXR|IV|...<cr>
RXC|B|D5W|1000|ML|...<cr>
RXC|A|KCL|40|MEQ|...<cr>
The second child:
ORC|CH|124B^SMS|||||1^C^^^^^^^^C&124A&SMS&&&#ES+0M|124|...<cr>
RXO Segment, Requested Give Amount-Minimum: ...|125||ML|...
Requested Give Per (Time Unit): ...|H1|...<cr>
RXR|IV|...<cr>
RXC|B|D5/LR|1000|ML|...<cr>
RXC|A|KCL|20|MEQ|...<cr>
c) Example #3
D5/0.45NaCl 1000mL with 20mEq KCl in every 3rd bottle. Start the KCl in the
3rd bottle of this order. Add 10mL of multi-vitamins to the one bag daily.
Run in at a rate of 100mL/hr.
(Other message data: placer order #134, placer application ID=SMS,
interval=continuous, start date/time=11/28/94 0900, no stop date/time,
priority=Routine, order sequencing=Cyclical. Note that the encoding of the
multi-vitamins statement in the above order, adding multi-vitamins to one IV
bag each day, may vary by institution to put it into the first or last bottle
of the day.)
This order may be expressed using a parent/child relationship. The parent
order consists of an ORC (and a RXO, although I did not completely elaborate
one in this example) that contains order level information. The repeating
bottle cycle of D5/0.45NaCl 1000mL followed by D5/0.45NaCl 1000mL followed by
D5/0.45NaCl + 20mEq KCL 1000mL is represented by three child segments. This
order is complicated by the request to add one component into any one of the
three repeating bottles, depending upon which of the bottles will occur first
on any particular day. Further complicating this order is a rate of infusion
(10 hours for a 1000mL bottle) which results in a fractional number of daily
administrations. Most legacy systems have a great deal of trouble
accommodating orders like this within their existing database structures;
however there a few vendors who now are able to handle the situation. The
placer system may be treating this as a single order with two bottles, A
(D5/0.45NaCl 1000mL @ 100mL/hr) and B (D5/0.45NaCl + 20mEq KCL 1000mL @
100mL/hr), repeating in the cycle of A-A-B with a cyclical component
(multi-vitamins).
The parent:
ORC|NW|134^SMS|||||1^C^^199411280900^^R^^^^C|...<cr>
RXO|Cyclic IV|...<cr>
The first child:
ORC|CH|134A1^SMS|||||1^C^^^^^^^^C&134B&SMS&&&*ES+0M|134|...<cr>
RXO Segment, Requested Give Amount-Minimum: ...|100||ML|...
Requested Give Per (Time Unit): ...|H1|...<cr>
RXR|IV|...<cr>
RXC|B|D5/.45NACL|1000|ML|...<cr>
The second child:
ORC|CH|134A2^SMS|||||1^C^^^^^^^^C&134A1&SMS&&&ES+0M|134|...<cr>
RXO Segment, Requested Give Amount-Minimum: ...|100||ML|...
Requested Give Per (Time Unit): ...|H1|...<cr>
RXR|IV|...<cr>
RXC|B|D5/.45NACL|1000|ML|...<cr>
The third child:
ORC|CH|134B^SMS|||||1^C^^^^^^^^C&134A2&SMS&&&#ES+0M|134|...<cr>
RXO Segment, Requested Give Amount-Minimum: ...|100||ML|...
Requested Give Per (Time Unit): ...|H1|...<cr>
RXR|IV|...<cr>
RXC|B|D5/.45NACL|1000|ML|...<cr>
RXC|A|KCL|20|MEQ|...<cr>
The fourth child:
ORC|CH|134X^SMS|||||1^Q1D^^^^^^^^|134|...<cr>
RXO|MULTIVITAMINS|10||ML|INJECTABLE|...<cr>
Discussion points:
This method for accommodating the Multi-vitamins Daily scenario does not
pretend to be the best or only way to express the message, but simply
demonstrates adapting the current specification to a highly complex order
without adding new components.
The Multi-vitamins component may be sent as a fourth child.
In this example, its ORC-7-quantity/timing includes an interval of "Q1D"
(every 1 days).
Its order number consists of the placer's parent order number plus an appended
identifier (`X' in the above example) that labels this child as a special case.
This convention would need to be agreed upon by sending and receiving
applications.
d) Example #4
D5W + 40mEq KCl 1000mL alternating with D5/LR + 20mEq KCl 1000mL alternating
with D5/0.45NaCl 1000mL. Infuse the D5W and D5/0.45 at 125mL/hr, and the D5/LR
at 100mL/hr.
(Other message data: placer order #177, placer application ID=SMS,
interval=continuous, start date/time=11/28/94 0900, no stop date/time,
priority=Routine, order sequencing=Cyclical)
This example is another variation of Example 1 where the rate for each bottle
is different, and this can be expressed within the RX segments of the children
using current components. In this example, the placer system deals with this
as one order with three alternating bottles, A (D5W + 40mEq KCl 1000mL @
125mL/hr) , B (D5/LR + 20mEq KCl 1000mL @ 100mL/hr) , and C (D5/0.45NaCl 1000mL
@ 125mL/hr) in the cycle A-B-C. The principles discussed in Example #1 apply
equally to this example.
The parent:
ORC|NW|177^SMS|||||1^C^^199411280900^^R^^^^C|...<cr>
RXO|Cyclic IV|...<cr>
The first child:
ORC|CH|177A^SMS|||||1^C^^^^^^^^C&177C&SMS&&&*ES+0M|177|...<cr>
RXO Segment, Requested Give Amount-Minimum: ...|125||ML|...
Requested Give Per (Time Unit): ...|H1|...<cr>
RXR|IV|...<cr>
RXC|B|D5W|1000|ML|...<cr>
RXC|A|KCL|40|MEQ|...<cr>
The second child:
ORC|CH|177B^SMS|||||1^C^^^^^^^^C&177A&SMS&&&ES+0M|177|...<cr>
RXO Segment, Requested Give Amount-Minimum: ...|100||ML|...
Requested Give Per (Time Unit): ...|H1|...<cr>
RXR|IV|...<cr>
RXC|B|D5/LR|1000|ML|...<cr>
RXC|A|KCL|20|MEQ|...<cr>
The third child:
ORC|CH|177C^SMS|||||1^C^^^^^^^^C&177B&SMS&&&#ES+0M|177|...<cr>
RXO Segment, Requested Give Amount-Minimum: ...|125||ML|...
Requested Give Per (Time Unit): ...|H1|...<cr>
RXR|IV|...<cr>
RXC|B|D5/0.45NACL|1000|ML|...<cr>
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/treatment queries
returning the current profile of pharmacy or treatment orders (RDE type), the
current dispense history (RDS type), the current dose history (RGV type), or
the current administration record (RAS type)..."
The order entry application requests pharmacy/treatment order information for
patient 12345, from 8/12/92 through 8/13/92.
MSH|^&~\|||||199208201200||QRY^Onn^QRY_Q01|...<cr>
QRD|19920814181254|R|D|9200785|||45^RD|12345|RER|...<cr>
QRF|PHM|19920812000000|19920813235959|...<cr>
DSC|...<cr>
MSH|^&~\|||||199208201201||RER^RER^RER_RER|...<cr>
MSA|AA|1001|...<cr>
QRD|...<cr>
QRF|...<cr>
ORC|RE|3346^OE|R23^RX|...<cr>
RXE|^BID^D5^199208120800^199208162000|10986^AMPICILLIN|250||MG|...<cr>
RXR|PO|...<cr>
ORC|RE|3987^OE|R76^RX|...<cr>
RXE|^TID^D7^199208120600^199208182200|12796^ASPIRIN|325||MG|...<cr>
RXR|PO|...<cr>
DSC|...<cr>
The lab application requests pharmacy/treatment administration information for
patient 12345, from 8/12/92 through 8/13/92.
MSH|^&~\|||||199208201200||QRY^Onn^QRY_Q01|...<cr>
QRD|19920814165645|R|D|9200231|||30^RD|12345|RAR|...<cr>
QRF|PHM|19920812000000|19920813235959|...<cr>
DSC|...<cr>
MSH|^&~\|||||199208201201||RAR^RAR^RAR_RAR|...<cr>
MSA|AA|1002|...<cr>
QRD|...<cr>
QRF|...<cr>
ORC|RE||R23^RX|...<cr>
RXE|^BID^D5^199208120800^199208162000|10986^AMPICILLIN|250||MG|...<cr>
RXR|PO|...<cr>
RXA|1|1|199208120800|199208120800|10986^AMPICILLIN|250|...<cr>
RXA|2|2|199208122000|199208122000|10986^AMPICILLIN|250|...<cr>
RXA|3|3|199208130800|199208130800|10986^AMPICILLIN|250|...<cr>
RXA|4|4|199208132000|199208132000|10986^AMPICILLIN|250|...<cr>
ORC|RE||R76^RX|...<cr>
RXE|^TID^D7^199208120600^199208182200|12796^ASPIRIN|325||MG|...<cr>
RXR|PO|...<cr>RXA|1|1|199208120600|199208120600|12796^ASPIRIN|325|...<cr>
RXA|2|2|199208121400|199208121400|12796^ASPIRIN|325|...<cr>
RXA|3|3|199208122200|199208122200|12796^ASPIRIN|325|...<cr>
RXA|4|4|199208130600|199208130600|12796^ASPIRIN|325|...<cr>
RXA|5|5|199208131400|199208131400|12796^ASPIRIN|325|...<cr>
RXA|6|6|199208132200|199208132200|12796^ASPIRIN|325|...<cr>
DSC|...<cr>
The nursing system requests pharmacy/treatment dose information for patient
12345, from 8/12/92 through 8/13/92.
MSH|^&~\|||||199208201200||QRY^Onn^QRY_Q01|...<cr>
QRD|19920814172309|R|D|9200543|||100^RD|12345|RGR|...<cr>
QRF|PHM|19920812000000|19920813235959|...<cr>
DSC|...<cr>
MSH|^&~\|||||199208201201||RGR^RGR^RGR_RGR|...<cr>
MSA|AA|1003|...<cr>
QRD|...<cr>
QRF|...<cr>
ORC|RE||R23^RX|...<cr>
RXE|^BID^D5^199208120800^199208162000|10986^AMPICILLIN|250||MG|...<cr>
RXR|PO|...<cr>
RXG|1||^^^199208120701|10986^AMPICILLIN|250|...<cr>
RXG|2||^^^199208121923|10986^AMPICILLIN|250|...<cr>
RXG|3||^^^199208130702|10986^AMPICILLIN|250|...<cr>
RXA|4||^^^199208131912|10986^AMPICILLIN|250|...<cr>
ORC|RE||R76^RX|...<cr>
RXE|^TID^D7^199208120600^199208182200|12796^ASPIRIN|325||MG|...<cr>
RXR|PO|...<cr>
RXG|1||^^^199208120459|12796^ASPIRIN|325|...<cr>
RXG|2||^^^199208121328|12796^ASPIRIN|325|...<cr>
RXG|3||^^^199208122101|12796^ASPIRIN|325|...<cr>
RXG|4||^^^199208130503|12796^ASPIRIN|325|...<cr>
RXG|5||^^^199208131311|12796^ASPIRIN|325|...<cr>
RXG|6||^^^199208132145|12796^ASPIRIN|325|...<cr>
DSC|...<cr>
The following are possible routes at a generic site.
1. ORM/RXO |
||||
1. ORM/RXO |
2. RDE/RXE |
|||
Ordering System |
2. RDE/RXE |
Pharmacy/ Treatment Supplier |
3. RDS/RXD |
Nursing |
4. RGV/RXG |
||||
5. RAS/RXA |
||||
5. RAS/RXA |
The Ordering application generates a pharmacy/treatment order (ORM with RXO and possibly additional RXC segments) and sends it to the pharmacy or treatment application, Nursing application, and/or other applications as appropriate at the site.
The pharmacy/treatment application may send the RDE, the Pharmacy/Treatment Encoded Order message, a fully encoded order to the Nursing application, Ordering application, and/or other system applications as appropriate at the site.
The pharmacy/treatment application may send the RDS, the Pharmacy/Treatment 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.
The pharmacy application may send the RGV, the Pharmacy/Treatment 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.
The
Nursing application (and other applications) can generate the RAS, the
pharmacy/treatment Administration Results message, whenever a medication is
given to the patient. This message may occur multiple times for each order.
Note: Sites having a long term clinical data repository may wish to
route data to the data repository from copies of all or any of the five messages.
The
message header segment will carry one of four event types at MSH-9-message
type:
Event |
Description |
V01 |
Query for Vaccination Record |
V02 |
Response to Vaccination Query (V01) Returning Multiple PID Matches |
V03 |
Response to Query (V01) Returning Vaccination Record |
V04 |
Unsolicited Update to Vaccination Record |
Immunization
registries that maintain vaccination records need to be able to transmit
patient-specific records of vaccines administered to other registries to
provide access to the record at the time healthcare is given and to allow
tracking of progress in reaching age-appropriate immunization coverage. The
transmissions will occur as the result of four activities: (1) a query from
one system for a patient's vaccination record that is held in another system,
(2) a response to a query containing multiple patient matches to the query, (3)
a response to a query containing the vaccination record, and (4) an unsolicited
update to an immunization registry
These messages permit the transmission of immunization records from care
providers to immunization registries, queries of these registries for
immunization records, and the return of these immunization records to care
providers. Messages containing immunization records carry patient identifying
information in the PID segment. They may also carry parent or guardian
information in the NK1 segments to help identify a child. The RXA segment is
used to report the details of the immunization event: the type of vaccine
(e.g., DPT, polio, MMR), the date administered, the sequence (1st, 2nd, etc.),
the amount (e.g., 0.5 ml), and location and provider of the immunization. In
addition, the RXA provides a place to record the lot number, manufacturer and
date of expiration of the immunization. The RXA can also be used to report the
fact that a specified immunization was refused. This section includes two
tables (0292 and 0227) maintained by the U.S. Centers for Disease Control and
Prevention (CDC). These tables are recommended in the U.S. for identifying the
immunization in field RXA-5-administered code and the vaccine
manufacturer in field RXA-17-substance manufacturer name.
The
VXQ, VXX, and VXR messages defined below incorporate the QRF segment defined at
2.24.5, "QRF - original style query filter segment." QRF-5-other query
subject filter is a locally defined filter for use between two systems
which mutually agree on a definition. For transferring vaccination
administration data, QRF-5-other QRY subject filter should be structured
as shown in Figure 4-20 to transmit up to ten separate search "keys." These
search keys are only used to identify one patient's immunization record. The
message provides for a wide variety of "identifying" keys including mother's
and/or father's name and other identifiers; in some cases such information will
be needed to identify a specific patient in the immunization database.
The format of each of the possible "search keys" is given below, and listed in
a more structured form in Figure 4-20. These keys are transmitted as
strings separated by repeat delimiters. The position of the components within
QRF-5-other QRY subject filter is significant. The requester sends
values for all the components that are known.
Components: <patient social security number> ~ <patient birth
date> ~ <patient birth state> ~ <patient birth registration
number> ~ <patient medicaid number> ~ <mother's name
last^first^middle> ~ <mother's maiden name> ~ <mother's Social
Security number> ~ <father's name last^first^middle> ~ <father's
Social Security number>
Pos |
Component |
Data Type |
Description/Examples |
1 |
Patient Social Security Number~ |
ST |
In U.S., use SSN, without hyphens between 3rd and 4th digits and 5th and 6th digits, e.g., 123456789. In other countries, universal patient ID such as National Health Service number may be used. |
2 |
Patient Birth Date~ |
DT |
July 4, 1976 = 19760704 |
3 |
Patient Birth State~ |
ID |
In U.S., use 2-letter postal code, e.g., IN, NY, CA. In other countries, locally applicable postal table may be used. |
4 |
Patient Birth Registration Number~ |
ST |
State birth certificate number |
5 |
Patient Medicaid Number~ |
ST |
When relevant |
6 |
Mother's Name Last^First^Middle~ |
PN |
<family
name> ^ <given name> ^ <middle name or initial> ^ <suffix>
|
7 |
Mother's Maiden Name~ |
ST |
Family name of mother before marriage. E.g., Jones |
8 |
Mother's Social Security Number~ |
ST |
In U.S., use SSN, without hyphens between 3rd and 4th digits and 5th and 6th digits, e.g., 123456789. In other countries, universal patient ID such as National Health Service number may be used. |
9 |
Father's Name Last^First^Middle~ |
PN |
<family
name> ^ <given name> ^ <middle name or initial> ^
<suffix> |
10 |
Father's Social Security Number |
ST |
In U.S., use SSN, without hyphens between 3rd and 4th digits and 5th and 6th digits, e.g., 123456789. In other countries, universal patient ID such as National Health Service number may be used. |
For
instance, if the requestor knew only the patient's Social Security number and
birthdate, this QRF-5-other QRY subject filter would be sent:
|908723461~19941005|
If, in addition, the patient's birth state and mother's current and maiden name
were known, this QRF-5-other QRY subject filter would be sent:
|908723461~19941005~IN~~~HUTCHINS^KATHY^ANN~HARKNESS|
Definition:
When an immunization registry does not already have the complete patient
vaccination record, it will send a query (with a V01 event) for the definitive
(last updated) record. Within the definitions for QRD and QRF, certain
components are defined according to position in the field, as detailed in
Section 4.17.2, "Queries for immunization records (QRF Segments)." The
three-letter code in the leftmost column indicates the segment that is
included; the column on the right specifies the chapter in which that segment
is fully defined.
The query will follow this format:
VXQ^V01 |
Vaccination Query |
Chapter |
MSH |
Message Header Segment |
2 |
QRD |
Query Definition Segment |
2 |
[QRF] |
Query Filter Segment |
2 |
Definition:
In response to a query for the definitive patient vaccination record, the
registry holding the record will return it to the registry originating the
query.
If the query results in multiple "matches," i.e., more than one patient record
matches the identifiers in the query so that there is no unique identification,
the response to the query (with a V02 event) will follow this format. Within
the definitions for QRD and QRF, certain components are defined according to
position in the field, as detailed in Section 4.17.2, "Queries for immunization
records (QRF Segments)." The three-letter code in the leftmost column
indicates the segment that is included; the column on the right specifies the
chapter in which that segment is fully defined.
VXX^V02 |
Returning Multiple PID Matches |
Chapter |
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
QRD |
Query Definition |
2 |
[QRF] |
Query Filter |
2 |
{PID |
Patient Identification |
3 |
[{NK1}] |
Next of Kin/Associated Parties |
3 |
} |
Definition:
When the patient has been uniquely identified (there is only one "match" to
the query), the response to the query (with a V03 event) will follow this
format. Within the definitions for QRD and QRF, certain components are defined
according to position in the field, as detailed in Section 4.17.2, "Queries for
immunization records (QRF Segments)." The three-letter code in the leftmost
column indicates the segment that is included; the column on the right
specifies the chapter in which that segment is fully defined.
VXR^V03 |
Vaccination Response |
Chapter |
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
QRD |
Query Definition |
2 |
[QRF] |
Query Filter |
2 |
PID |
Patient Identification |
3 |
[PD1] |
Additional Demographics |
3 |
[{NK1}] |
Next of Kin/Associated Parties |
3 |
[PV1 |
Patient Visit |
3 |
[PV2]] |
Patient Visit - Additional Info |
3 |
[{GT1}] |
Guarantor |
6 |
[{IN1 |
Insurance |
6 |
[IN2] |
Insurance Additional Info |
6 |
[IN3] |
Insurance Add'l Info - Cert. |
6 |
}] |
||
[{ |
||
[ORC] |
Common Order |
4 |
RXA |
Pharmacy Administration |
4 |
[RXR] |
Pharmacy Route |
4 |
[{OBX |
Observation/Result |
7 |
[{NTE}] |
Notes (Regarding Immunization) |
2 |
}] |
||
}] |
Definition:
When a provider wishes to update the patient's vaccination record being held
in a registry, he will transmit an unsolicited update of the record (a V04
trigger event).
An unsolicited update will follow this format. The three-letter code in the
leftmost column indicates the segment that is included; the column on the right
specifies the chapter in which that segment is fully defined.
VXU^V04 |
Unsolicited Vaccination Update |
Chapter |
MSH |
Message Header Segment |
2 |
PID |
Patient Identification Segment |
3 |
[PD1] |
Additional Demographics |
3 |
[{NK1}] |
Next of Kin/Associated Parties |
3 |
[PV1 |
Patient Visit |
3 |
[PV2]] |
Patient Visit - Additional Info |
3 |
[{GT1}] |
Guarantor |
6 |
[{IN1 |
Insurance |
6 |
[IN2] |
Insurance Additional Info |
6 |
[IN3] |
Insurance Add'l Info - Cert. |
6 |
}] |
||
[{ |
||
[ORC] |
Common Order Segment |
4 |
RXA |
Pharmacy Administration Segment |
4 |
[RXR] |
Pharmacy Route |
4 |
{[ OBX |
Observation/Result |
7 |
[{NTE}] |
Notes (Regarding Immunization) |
2 |
]} |
||
}] |
With
the exception of RXA-5-Administered code and RXA-17-Substance
manufacturer name, the structure for the RXA segment below is identical to
that documented in section 4.14.7. When using the RXA segment for vaccine
messages, H
L7
Table 0292- V
accines
Administered, should be used for RXA-5- Administered code, as noted in
Section 4.18.1.1. HL7 Table 0227- Manufacturers of Vaccines,
should be used for RXA-17- Substance manufacturer name, as noted in
Section 4.18.1.2
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM # |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
4 |
NM |
R |
00342 |
Give Sub-ID Counter |
||
2 |
4 |
NM |
R |
00344 |
Administration Sub-ID Counter |
||
3 |
26 |
TS |
R |
00345 |
Date/Time Start of Administration |
||
4 |
26 |
TS |
R |
00346 |
Date/Time End of Administration |
||
5 |
250 |
CE |
R |
0292 |
00347 |
Administered Code |
|
6 |
20 |
NM |
R |
00348 |
Administered Amount |
||
7 |
250 |
CE |
C |
00349 |
Administered Units |
||
8 |
250 |
CE |
O |
00350 |
Administered Dosage Form |
||
9 |
250 |
CE |
O |
Y |
00351 |
Administration Notes |
|
10 |
250 |
XCN |
O |
Y |
00352 |
Administering Provider |
|
11 |
200 |
CM |
C |
00353 |
Administered-at Location |
||
12 |
20 |
ST |
C |
00354 |
Administered Per (Time Unit) |
||
13 |
20 |
NM |
O |
01134 |
Administered Strength |
||
14 |
250 |
CE |
O |
01135 |
Administered Strength Units |
||
15 |
20 |
ST |
O |
Y |
01129 |
Substance Lot Number |
|
16 |
26 |
TS |
O |
Y |
01130 |
Substance Expiration Date |
|
17 |
250 |
CE |
O |
Y |
0227 |
01131 |
Substance Manufacturer Name |
18 |
250 |
CE |
O |
Y |
01136 |
Substance/Treatment Refusal Reason |
|
19 |
250 |
CE |
O |
Y |
01123 |
Indication |
|
20 |
2 |
ID |
O |
0322 |
01223 |
Completion Status |
|
21 |
2 |
ID |
O |
0323 |
01224 |
Action Code - RXA |
|
22 |
26 |
TS |
O |
01225 |
System Entry Date/Time |
Use
in RXA-5- administered code to identify the particular vaccine
administered. The codes listed are used by immunization by immunization
registries in the U.S. Entries will be added as needed to accommodate
international requirements.
Code |
Short Description |
Full Vaccine Name |
|---|---|---|
54 |
adenovirus, type 4 |
adenovirus vaccine, type 4, live, oral |
55 |
adenovirus, type 7 |
adenovirus vaccine, type 7, live, oral |
82 |
adenovirus, NOS1 |
adenovirus vaccine, NOS |
24 |
anthrax |
anthrax vaccine |
19 |
BCG |
Bacillus Calmette-Guerin vaccine |
27 |
botulinum antitoxin |
botulinum antitoxin |
26 |
cholera |
cholera vaccine |
29 |
CMVIG |
cytomegalovirus immune globulin, intravenous |
56 |
dengue fever |
dengue fever vaccine |
12 |
diphtheria antitoxin |
diphtheria antitoxin |
28 |
DT (pediatric) |
diphtheria and tetanus toxoids, adsorbed for pediatric use |
20 |
DTaP |
diphtheria, tetanus toxoids and acellular pertussis vaccine |
50 |
DTaP-Hib |
DTaP-Haemophilus influenzae type b conjugate vaccine |
01 |
DTP |
diphtheria, tetanus toxoids and pertussis vaccine |
22 |
DTP-Hib |
DTP-Haemophilus influenzae type b conjugate vaccine |
57 |
hantavirus |
hantavirus vaccine |
52 |
Hep A, adult |
hepatitis A vaccine, adult dosage |
83 |
Hep A, ped/adol, 2 dose |
hepatitis A vaccine, pediatric/adolescent dosage, 2 dose schedule |
84 |
Hep A, ped/adol, 3 dose |
hepatitis A vaccine, pediatric/adolescent dosage, 3 dose schedule |
31 |
Hep A, pediatric, NOS |
hepatitis A vaccine, pediatric dosage, NOS |
85 |
Hep A, NOS |
hepatitis A vaccine, NOS |
30 |
HBIG |
hepatitis B immune globulin |
08 |
Hep B, adolescent or pediatric |
hepatitis B vaccine, pediatric or pediatric/adolescent dosage |
42 |
Hep B, adolescent/high risk infant2 |
hepatitis B vaccine, adolescent/high risk infant dosage |
43 |
Hep B, adult4 |
hepatitis B vaccine, adult dosage |
44 |
Hep B, dialysis |
hepatitis B vaccine, dialysis patient dosage |
45 |
Hep B, NOS |
hepatitis B vaccine, NOS |
58 |
Hep C |
hepatitis C vaccine |
59 |
Hep E |
hepatitis E vaccine |
60 |
herpes simplex 2 |
herpes simplex virus, type 2 vaccine |
46 |
Hib (PRP-D) |
Haemophilus influenzae type b vaccine, PRP-D conjugate |
47 |
Hib (HbOC) |
Haemophilus influenzae type b vaccine, HbOC conjugate |
48 |
Hib (PRP-T) |
Haemophilus influenzae type b vaccine, PRP-T conjugate |
49 |
Hib (PRP-OMP) |
Haemophilus influenzae type b vaccine, PRP-OMP conjugate |
17 |
Hib, NOS |
Haemophilus influenzae type b vaccine, conjugate NOS |
51 |
Hib-Hep B |
Haemophilus influenzae type b conjugate and Hepatitis B vaccine |
61 |
HIV |
human immunodeficiency virus vaccine |
62 |
HPV |
human papilloma virus vaccine |
86 |
IG |
immune globulin, intramuscular |
87 |
IGIV |
immune globulin, intravenous |
14 |
IG, NOS |
immune globulin, NOS |
15 |
influenza, split (incl. purified surface antigen) |
influenza virus vaccine, split virus (incl. purified surface antigen) |
16 |
influenza, whole |
influenza virus vaccine, whole virus |
88 |
influenza, NOS |
influenza virus vaccine, NOS |
10 |
IPV |
poliovirus vaccine, inactivated |
02 |
OPV |
poliovirus vaccine, live, oral |
89 |
polio, NOS |
poliovirus vaccine, NOS |
39 |
Japanese encephalitis |
Japanese encephalitis vaccine |
63 |
Junin virus |
Junin virus vaccine |
64 |
leishmaniasis |
leishmaniasis vaccine |
65 |
leprosy |
leprosy vaccine |
66 |
Lyme disease |
Lyme disease vaccine |
03 |
MMR |
measles, mumps and rubella virus vaccine |
04 |
M/R |
measles and rubella virus vaccine |
94 |
MMRV |
measles, mumps, rubella, and varicella virus vaccine |
67 |
malaria |
malaria vaccine |
05 |
measles |
measles virus vaccine |
68 |
melanoma |
melanoma vaccine |
32 |
meningococcal |
meningococcal polysaccharide vaccine |
07 |
mumps |
mumps virus vaccine |
69 |
parainfluenza-3 |
parainfluenza-3 virus vaccine |
11 |
pertussis |
pertussis vaccine |
23 |
plague |
plague vaccine |
33 |
pneumococcal |
pneumococcal polysaccharide vaccine |
100 |
pneumococcal conjugate |
pneumococcal conjugate vaccine, polyvalent |
70 |
Q fever |
Q fever vaccine |
18 |
rabies, intramuscular injection |
rabies vaccine, for intramuscular injection |
40 |
rabies, intradermal injection |
rabies vaccine, for intradermal injection |
90 |
rabies, NOS |
rabies vaccine, NOS |
72 |
rheumatic fever |
rheumatic fever vaccine |
73 |
Rift Valley fever |
Rift Valley fever vaccine |
34 |
RIG |
rabies immune globulin |
74 |
rotavirus |
rotavirus vaccine, tetravalent, live, oral |
71 |
RSV-IGIV |
respiratory syncytial virus immune globulin, intravenous |
93 |
RSV-Mab |
respiratory syncytial virus monoclonal antibody (palivizumab), intramuscular |
06 |
rubella |
rubella virus vaccine |
38 |
rubella/mumps |
rubella and mumps virus vaccine |
75 |
smallpox |
smallpox vaccine |
76 |
Staphylococcus bacterio lysate |
Staphylococcus bacteriophage lysate |
09 |
Td (adult) |
tetanus and diphtheria toxoids, adsorbed for adult use |
35 |
tetanus toxoid |
tetanus toxoid |
77 |
tick-borne encephalitis |
tick-borne encephalitis vaccine |
13 |
TIG |
tetanus immune globulin |
95 |
TST-OT tine test |
tuberculin skin test; old tuberculin, multipuncture device |
96 |
TST-PPD intradermal |
tuberculin skin test; purified protein derivative solution, intradermal |
97 |
TST-PPD tine test |
tuberculin skin test; purified protein derivative, multipuncture device |
98 |
TST, NOS |
tuberculin skin test; NOS |
78 |
tularemia vaccine |
tularemia vaccine |
25 |
typhoid, oral |
typhoid vaccine, live, oral |
41 |
typhoid, parenteral |
typhoid vaccine, parenteral, other than acetone-killed, dried |
53 |
typhoid, parenteral, AKD (U.S. military) |
typhoid vaccine, parenteral, acetone-killed, dried (U.S. military) |
101 |
typhoid, ViCPs |
Typhoid Vi capsular polysaccharide vaccine |
91 |
typhoid, NOS |
typhoid vaccine, NOS |
79 |
vaccinia immune globulin |
vaccinia immune globulin |
21 |
varicella |
varicella virus vaccine |
81 |
VEE, inactivated |
Venezuelan equine encephalitis, inactivated |
80 |
VEE, live |
Venezuelan equine encephalitis, live, attenuated |
92 |
VEE, NOS |
Venezuelan equine encephalitis vaccine, NOS |
36 |
VZIG |
varicella zoster immune globulin |
37 |
yellow fever |
yellow fever vaccine |
999 |
unknown |
unknown vaccine or immune globulin |
99 |
RESERVED - do not use3 |
RESERVED - do not use |
Usage
Notes:
NOS=not otherwise specified; avoid using NOS codes except to record historical
records that lack the indicated specificity
As of August 27, 1998, Merck ceased distribution of their adolescent/high risk
infant hepatitis B vaccine dosage. Code 42 should only be used to record
historical records. For current administration of hepatitis B vaccine,
pediatric/adolescent dosage, use code 08.
Code 99 will not be used in this table to avoid confusion with code 999.
As of September 1999, a 2-dose hepatitis B schedule for adolescents (11-15 year
olds) was FDA approved for Merck's Recombivax HB® adult formulation. Use
code 43 for both the 2-dose and the 3-dose schedules.
The codes in HL7 Table 0292 represent the first revision (January 14,
1998) of the initial content of the external code set CVX. Since vaccines may
have to be added to this table more quickly than new versions of HL7 are
released, this code system will be maintained by the Centers for Disease
Control and Prevention. (Contact the Chief, Systems Development Branch,
National Immunization Program, Centers for Disease Control and Prevention, 1600
Clifton Road, MS E-62, Atlanta, GA 30333; 1-800-799-7062,
http://www.cdc.gov/nip/registry.) When using this code system to identify
vaccines, the coding system component of the CE field should be valued as
"CVX", not as "
HL70292."
Use
in RXA-17-substance manufacturer name to identify the manufacturer or
distributor of the particular vaccine administered. The codes listed are used
by immunization registries in the U.S. Entries will be added as needed to
accommodate international requirements.
Code |
Vaccine Manufacturer/Distributor |
|---|---|
AB |
Abbott Laboratories (includes Ross Products Division) |
AD |
Adams Laboratories |
ALP |
Alpha Therapeutic Corporation |
AR |
Armour [Inactive-use CEN] |
AVI |
Aviron |
BA |
Baxter Healthcare Corporation |
BAY |
Bayer Corporation(includes Miles, Inc. and Cutter Laboratories) |
BP |
Berna Products [Inactive-use BPC] |
BPC |
Berna Products Corporation (includes Swiss Serum and Vaccine Institute Berne) |
CEN |
Centeon L.L.C. (includes Armour Pharmaceutical Company) |
CHI |
Chiron Corporation |
CON |
Connaught [Inactive-use PMC] |
EVN |
Evans Medical Limited (an affiliate of Medeva Pharmaceuticals, Inc.) |
GRE |
Greer Laboratories, Inc. |
IAG |
Immuno International AG |
IM |
Merieux [Inactive-use PMC] |
IUS |
Immuno-U.S., Inc. |
JPN |
The Research Foundation for Microbial Diseases of Osaka University (BIKEN) |
KGC |
Korea Green Cross Corporation |
LED |
Lederle [Inactive-use WAL] |
MA |
Massachusetts Public Health Biologic Laboratories |
MED |
MedImmune, Inc. |
MIL |
Miles [Inactive-use BAY] |
MIP |
Bioport Corporation (formerly Michigan Biologic Products Institute) |
MSD |
Merck & Co., Inc. |
NAB |
NABI (formerly North American Biologicals, Inc.) |
NYB |
New York Blood Center |
NAV |
North American Vaccine, Inc. |
NOV |
Novartis Pharmaceutical Corporation (includes Ciba-Geigy Limited and Sandoz Limited) |
OTC |
Organon Teknika Corporation |
ORT |
Ortho Diagnostic Systems, Inc. |
PD |
Parkedale Pharmaceuticals (formerly Parke-Davis) |
PMC |
Aventis Pasteur Inc. (formerly Pasteur Merieux Connaught; includes Connaught Laboratories and Pasteur Merieux) |
PRX |
Praxis Biologics [Inactive-use WAL] |
SCL |
Sclavo, Inc. |
SI |
Swiss Serum and Vaccine Inst. [Inactive-use BPC] |
SKB |
SmithKline Beecham |
USA |
United States Army Medical Research and Materiel Command |
WA |
Wyeth-Ayerst [Inactive-use WAL] |
WAL |
Wyeth-Ayerst (includes Wyeth-Lederle Vaccines and Pediatrics, Wyeth Laboratories, Lederle Laboratories, and Praxis Biologics) |
OTH |
Other manufacturer |
UNK |
Unknown manufacturer |
The codes in HL7 Table 0227 represent the first revision (January 14, 1998) of the initial content of the external code set MVX. Since vaccine manufacturers may have to be added to this table more quickly than new versions of HL7 are released, this code system will be maintained by the Centers for Disease Control and Prevention. (Contact the CDC, as noted in Section 4.18.1.0 "RXA field definitions"). When using this code system to identify vaccines, the coding system component of the CE field should be valued as "MVX", not as "HL70227."
MSH|^~\&||GAVACREC||AZVACREC|199505221605||VXQ^V01|
...<cr>
QRD|199505221605|R|I|950522GA40|||1000^RD|^JONES^JOHN^RICHARD|VXI|SIIS|...<cr>
QRF|AZVACREC||||256946789~19900607~CA~CA99999999~88888888~JONES^MARY^SUE~SMITH~898666725~JONES^MATHEW^LEE~822546618|...<cr>
In this query, Georgia Vaccine Records is sending a request to Arizona Vaccine
Records for an immunization record. The request is being sent on May 22, 1995,
at 4:05 p.m. Identifiers other than patient name are defined in the query by
giving positional meaning to the repeat delimiters in the QRF-5-other query
subject filter field, as specified in 4.17.2, "Queries for immunization
records (QRF Segments)." The responding system is expected to return all query
items in their response. The QRD segment, at QRD-8-who subject filter,
identifies the patient name. QRD-9-what subject filter reflects the new
VXI category of Vaccination Information. QRD-10-what department data
code shows SIIS.
In our example, we are sending a query for the record of John Richard Jones.
The patient's Social Security number is 256-94-6789; the patient birth date is
June 7, 1990; the patient birth state is CA; the patient birth registration
number is CA99999999; and the patient Medicaid number is 88888888. The
patient's mother is Mary Sue Jones, whose maiden name is Smith. Her Social
Security number is 898-66-6725. The patient's father is Mathew Lee Jones, and
the father's Social Security number is 822-54-6618.
MSH|^~\&||AZVACREC||GAVACREC|199505221606||VXX^V02|...<cr>
MSA|...<cr>
QRD|199505221605|R|I|950522GA40|||1000^RD|^JONES^RICHARD|VXI|SIIS|...<cr>
QRF|AZVACREC||||~~~~~JONES^MARY|...<cr>
PID|1||123456789^^^AZ||^JONES^RICHARD^ROBERT||19910607|M^MALE^HL70001|...<cr>
NK1|1|JONES^MARY^SUE|MTH^MOTHER^HL70063||||||||||||||||||||||||||||||265909900^^^^SS|...<cr>
PID|2||987654321^^^AZ||^JONES^JOHN^RICHARD||19900607|M^MALE^HL70001|...<cr>
NK1|1|JONES^MARY|MTH^MOTHER^HL70063||||||||||||||||||||||||||||||898666725^^^^SS|...<cr>
NK1|2|JONES^MATHEW^LEE|FTH^FATHER^HL70063||||||||||||||||||||||||||||||822546618^^^^SS|...<cr>
PID|3||231453675^^^AZ||^JONES^RICHARD^CURTIS||19901225|M^MALE^HL70001|...<cr>
NK1|1|JONES^MARY^ANN|MTH^MOTHER^HL70063||||||||||||||||||||||||||||||288763102^^^^SS|...<cr>
PID|4||908786564^^^AZ||^JONES^RICHARD^ALAN||19870205|M^MALE^HL70001|...<cr>
NK1|1|JONES^MARY^SUE|MTH^MOTHER^HL70063||||||||||||||||||||||||||||||190966725^^^^SS|...<cr>
NK1|2|JONES^CHRISTOPHER|FTH^FATHER^HL70063||||||||||||||||||||||||||||||786118768^^^^SS|...<cr>
The example shows the response when multiple PIDs match a query. In the QRD,
the sender is querying Arizona Vaccine Records for information on Richard
Jones; the only further identifying information supplied in the QRF is that the
mother's name is Mary Jones. For each record which matches this information, a
PID is returned along with its associated NK1. The system initiating the query
may then re-send a more precise query.
MSH|^~\&||AZVACREC||GAVACREC|199505221606||VXR^V03|...<cr>
MSA|...<cr>
QRD|...<cr>
QRF|...<cr>
PID|...<cr>
NK1|1|JONES^MARY^SUE|MTH^MOTHER^HL70063||||||||||||||||||||||||||||||898666725^^^^SS|...<cr>
NK1|2|JONES^MATHEW^LEE|FTH^FATHER^HL70063||||||||||||||||||||||||||||||822546618^^^^SS|...<cr>
ORC|RE||V43^AZVAC|...<cr>
RXA|0|4|19910607|19910607|01^DTP^CVX|.5|MG^^ISO+|||1234567891^GOLDSTEIN^HAROLD^A^^DR|
^^^CHILD HEALTHCARE CLINIC^^^^^101 MAIN
STREET^^METROPOLIS^AZ||||W46932777|19910813|
SKB^SmithKline Beecham^MVX|...<cr>ORC|RE||V44^AZVAC|...<cr>
RXA|0|1|19910607|19910607|03^MMR^CVX|.5|MG^^ISO+|||1234567891^GOLDSTEIN^HAROLD^A^^DR|
^^^CHILD HEALTHCARE CLINIC^^^^^101 MAIN
STREET^^METROPOLIS^AZ||||W23487909876456|
19910725|MSD^Merck \T\ Co., Inc.^MVX|...<cr>
ORC|RE||V87^AZVAC|...<cr>
RXA|0|5|19950520|19950520|01^DTP^CVX|.5|MG^^ISO+|||1234567891^GOLDSTEIN^HAROLD^A^^DR|
^^^CHILD HEALTHCARE CLINIC^^^^^101 MAIN
STREET^^METROPOLIS^AZ||||W22532806|19950705|
SKB^SmithKline Beecham^MVX|...<cr>
ORC|RE||V88^AZVAC|...<cr>
RXA|0|2|19950520|19950520|03^MMR^CVX|.5|MG^^ISO+|||1234567891^GOLDSTEIN^HAROLD^A^^DR|
^^^CHILD HEALTHCARE CLINIC^^^^^101 MAIN
STREET^^METROPOLIS^AZ||||W2341234567|19950630|
MSD^Merck \T\ Co., Inc.^MVX|...<cr>
The example reflects a vaccination record return as might be expected by a
public health agency reporting from one immunization registry to another. It
shows repeating RXA segments reporting the first and second doses of MMR and
the fourth and fifth doses of DTP, including the manufacturer, lot number, and
expiration date. If the vaccination had been refused by the patient or
guardian, RXA-18-substance refusal reason would record the vaccine
refusal reason, utilizing a user-defined table.
MSH|^~\&||AZVACREC||GAVACREC|199505221606||VXU^V04|...<cr>
PID|...<cr>
NK1|...<cr>
NK1|...<cr>
PV1|...<cr>
PV2|...<cr>
IN1|...<cr>
IN2|||||||JONES^ALICE^P|909686637A|...<cr>
ORC|...<cr>
RXA|0|1|19950901115500|19950901115500|03^MMR^CVX|.5|MG^^ISO+|||
1234567891^GOLDSTEIN^HAROLD^A^^DR| ^^^ CHILD HEALTHCARE CLINIC^^^^^101 MAIN
STREET^ ^METROPOLIS^AZ||||W23487909876456|19951125|MSD^Merck \T\ Co.,
Inc.^MVX|...<cr>
RXR|IM^INTRAMUSCULAR^HL70162|LG^LEFT GLUTEUS MEDIUS^HL70163|...<cr>
OBX|1|NM|1000.3^TEMP.RECTAL^AS4||102.9|DEGF^^ANSI+|||||F|||19950901153000|...<cr>
NTE|||PATIENT DEVELOPED HIGH FEVER APPROX 3 HRS AFTER VACCINE INJECTION.
PROBABLE ADVERSE REACTION|...<cr>
This message shows an unsolicited update of a vaccination record. The message
type is VXU--Unsolicited Vaccination Record Update, with event code V04
(unsolicited vaccination record update). This example is given to show
possible uses for some of the optional segments in the message.
MSH|^~\&||AZVACREC||GAVACREC|19950522130550^S||DSR^Q01|...<cr>
MSA|AA|950522GA40|...<cr>
QAK||NF|...<cr>
QRD|...<cr>
The example shows the response to a query which was successfully processed, but
no qualifying data were found.
Referenced
in 4
.4.1.1
-
Order
Control
Codes
Value1 |
Event/Message Type |
Description |
Originator2 |
Field Note3 |
|---|---|---|---|---|
NW |
ORM^O01 |
New order/service |
P |
l |
OML^O21 |
||||
OMD^O03 |
||||
OMS^O05 |
||||
OMN^O07 |
||||
OMP^O09 |
||||
OK |
ORR^O02 |
Order/service accepted & OK |
F |
l |
ORG^O20 |
||||
ORD^O04 |
||||
ORS^O06 |
||||
ORN^O08 |
||||
ORP^O10 |
||||
RRE^O12 |
||||
RRD^O14 |
||||
RRG^O16 |
||||
RRA^O18 |
||||
UA |
ORR^O02 |
Unable to accept order/service |
F |
n |
ORG^O20 |
||||
ORD^O04 |
||||
ORS^O06 |
||||
ORN^O08 |
||||
ORP^O10 |
||||
RRE^O12 |
||||
RRD^O14 |
||||
UA |
RRG^O16 |
Unable to accept order/service |
F |
n |
RRA^O18 |
||||
PR |
ORM^O01 |
Previous Results with new order/service |
P |
v |
OML^O21 |
||||
CA |
ORM^O01 |
Cancel order/service request |
P |
a |
OML^O21 |
||||
OMD^O03 |
||||
OMS^O05 |
||||
OMN^O07 |
||||
OMP^O09 |
||||
OC |
ORM^O01 |
Order/service canceled |
F |
|
OML^O21 |
||||
OMS^O05 |
||||
OMN^O07 |
||||
RDE^O11 |
||||
RDS^O13 |
||||
RGV^O15 |
||||
RAS^O01 |
||||
CR |
ORR^O02 |
Canceled as requested |
F |
|
ORG^O20 |
||||
ORD^O04 |
||||
ORS^O06 |
||||
ORN^O08 |
||||
ORP^O10 |
||||
UC |
ORR^O02 |
Unable to cancel |
F |
b |
ORG^O20 |
||||
UC |
ORD^O04 |
Unable to cancel |
F |
b |
ORS^O06 |
||||
ORN^O08 |
||||
ORP^O10 |
||||
DC |
ORM^O01 |
Discontinue order/service request |
P |
c |
OML^O21 |
||||
OMD^O03 |
||||
OMS^O05 |
||||
OMN^O07 |
||||
OMP^O09 |
||||
OD |
ORM^O01 |
Order/service discontinued |
F |
|
OML^O21 |
||||
OMS^O05 |
||||
OMN^O07 |
||||
RDE^O11 |
||||
RDS^O13 |
||||
RGV^O15 |
||||
RAS^O01 |
||||
DR |
ORR^O02 |
Discontinued as requested |
F |
|
ORG^O20 |
||||
ORD^O04 |
||||
ORS^O06 |
||||
ORN^O08 |
||||
ORP^O10 |
||||
UD |
ORR^O02 |
Unable to discontinue |
F |
|
ORG^O20 |
||||
UD |
ORD^O04 |
Unable to discontinue |
F |
|
ORS^O06 |
||||
ORN^O08 |
||||
ORP^O10 |
||||
HD |
ORM^O01 |
Hold order request |
P |
|
OML^O21 |
||||
OMD^O03 |
||||
OMP^O09 |
||||
OH |
ORM^O01 |
Order/service held |
F |
|
OML^O21 |
||||
OMS^O05 |
||||
OMS^O05 |
||||
OMN^O07 |
||||
OMN^O07 |
||||
RDE^O11 |
||||
RDS^O13 |
||||
RGV^O15 |
||||
RAS^O01 |
||||
UH |
ORR^O02 |
Unable to put on hold |
F |
|
ORG^O20 |
||||
ORD^O04 |
||||
ORS^O06 |
||||
ORN^O08 |
||||
ORP^O10 |
||||
HR |
ORR^O02 |
On hold as requested |
F |
|
ORG^O20 |
||||
HR |
ORD^O04 |
On hold as requested |
F |
|
ORS^O06 |
||||
ORN^O08 |
||||
ORP^O10 |
||||
RL |
ORM^O01 |
Release previous hold |
P |
|
OML^O21 |
||||
OMD^O03 |
||||
OMS^O05 |
||||
OMN^O07 |
||||
OMP^O09 |
||||
OE |
ORM^O01 |
Order/service released |
F |
|
OML^O21 |
||||
OMS^O05 |
||||
OMN^O07 |
||||
RDE^O11 |
||||
RDS^O13 |
||||
RGV^O15 |
||||
RAS^O01 |
||||
OR |
ORR^O02 |
Released as requested |
F |
|
ORG^O20 |
||||
ORD^O04 |
||||
ORS^O06 |
||||
ORN^O08 |
||||
ORP^O10 |
||||
UR |
ORR^O02 |
Unable to release |
F |
|
ORG^O20 |
||||
UR |
ORD^O04 |
Unable to release |
F |
|
ORS^O06 |
||||
ORN^O08 |
||||
ORP^O10 |
||||
RP |
ORM^O01 |
Order/service replace request |
P |
"e,d" |
OML^O21 |
||||
OMS^O05 |
||||
OMN^O07 |
||||
OMP^O09 |
||||
RU |
ORM^O01 |
Replaced unsolicited |
F |
"f,d" |
OML^O21 |
||||
OMS^O05 |
||||
OMN^O07 |
||||
RDE^O11 |
||||
RO |
ORM^O01 |
Replacement order |
"P,F" |
"g,d" |
OML^O21 |
||||
OMS^O05 |
||||
OMN^O07 |
||||
OMP^O09 |
||||
RDE^O11 |
||||
RQ |
ORR^O02 |
Replaced as requested |
F |
"d,e" |
ORG^O20 |
||||
ORS^O06 |
||||
ORN^O08 |
||||
ORP^O10 |
||||
UM |
ORR^O02 |
Unable to replace |
F |
|
UM |
ORG^O20 |
Unable to replace |
F |
|
ORS^O06 |
||||
ORN^O08 |
||||
ORP^O10 |
||||
PA |
ORM^O01 |
Parent order/service |
F |
I |
OML^O21 |
||||
OMS^O05 |
||||
OMS^O05 |
||||
OMP^O09 |
||||
RDE^O11 |
||||
RGV^O15 |
||||
RAS^O01 |
||||
ORU^R01 |
||||
CH |
ORM^O01 |
Child order/service |
"F,P" |
I |
OML^O21 |
||||
OMS^O05 |
||||
OMS^O05 |
||||
RDE^O11 |
||||
RGV^O15 |
||||
RAS^O01 |
||||
ORU^R01 |
||||
XO |
ORM^O01 |
Change order/service request |
P |
|
OML^O21 |
||||
OMD^O03 |
||||
OMS^O05 |
||||
OMS^O05 |
||||
XO |
OMP^O09 |
Change order/service request |
P |
|
XX |
ORM^O01 |
"Order/service changed, unsol." |
F |
|
OML^O21 |
||||
OMS^O05 |
||||
OMS^O05 |
||||
RDE^O11 |
||||
RDS^O13 |
||||
RDS^O13 |
||||
RGV^O15 |
||||
RAS^O01 |
||||
RAS^O01 |
||||
UX |
ORR^O02 |
Unable to change |
F |
|
ORG^O20 |
||||
ORD^O04 |
||||
ORS^O06 |
||||
ORN^O08 |
||||
ORP^O10 |
||||
XR |
ORR^O02 |
Changed as requested |
F |
|
ORG^O20 |
||||
ORD^O04 |
||||
ORS^O06 |
||||
ORN^O08 |
||||
ORP^O10 |
||||
DE |
ORM^O01 |
Data errors |
"P,F" |
|
ORR^O02 |
||||
ORG^O20 |
||||
DE |
ORS^O06 |
Data errors |
"P,F" |
|
ORN^O08 |
||||
ORP^O10 |
||||
RRE^O12 |
||||
RRD^O14 |
||||
RRG^O16 |
||||
RRA^O18 |
||||
RE |
ORM^O01 |
Observations/Performed Service to follow |
"P,F" |
j |
OML^O21 |
||||
RDE^O11 |
||||
RDS^O13 |
||||
RGV^O15 |
||||
RAS^O01 |
||||
ORU^R01 |
||||
RR |
ORR^O02 |
Request received |
"P,F" |
k |
SR |
ORR^O02 |
Response to send order/service status request |
F |
|
OSR^Q06 |
||||
SS |
ORM^O01 |
Send order/service status request |
P |
|
OML^O21 |
||||
SC |
ORM^O01 |
Status changed |
"F,P" |
|
OML^O21 |
||||
SN |
ORM^O01 |
Send order/service number |
F |
l |
OML^O21 |
||||
OMS^O05 |
||||
OMS^O05 |
||||
RDE^O11 |
||||
NA |
ORR^O02 |
Number assigned |
P |
l |
ORG^O20 |
||||
ORS^O06 |
||||
ORN^O08 |
||||
RRE^O12 |
||||
CN |
ORU^R01 |
Combined result |
F |
m |
RF |
ORM^O01 |
Refill order/service request |
"F, " |
o |
OMP^O09 |
||||
RDE^O11 |
||||
AF |
ORR^O02 |
Order/service refill request approval |
P |
p |
RRE^O12 |
||||
DF |
ORR^O02 |
Order/service refill request denied |
P |
q |
ORP^O10 |
||||
RRE^O12 |
||||
FU |
ORM^O01 |
"Order/service refilled, unsolicited" |
F |
r |
RDE^O11 |
||||
OF |
ORR^O02 |
Order/service refilled as requested |
F |
s |
ORP^O10 |
||||
UF |
ORR^O02 |
Unable to refill |
F |
t |
ORP^O10 |
||||
LI |
ORM^O01 |
Link order/service to patient care problem or goal |
u |
|
OML^O21 |
||||
OMS^O05 |
||||
OMS^O05 |
||||
LI |
OMP^O09 |
Link order/service to patient care problem or goal |
u |
|
RDE^O11 |
||||
RDS^O13 |
||||
RAS^O01 |
||||
UN |
ORM^O01 |
Unlink order/service from patient care problem or goal |
u |
|
OML^O21 |
||||
OMS^O05 |
||||
OMN^O07 |
||||
OMP^O09 |
||||
RDE^O11 |
||||
RDS^O13 |
||||
RAS^O01 |
Notes:
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.
Referenced
in 4.4.3.15 OBR-15 Specimen source
Value |
Description |
|---|---|
ABS |
Abscess |
AMN |
Amniotic fluid |
ASP |
Aspirate |
BPH |
Basophils |
BIFL |
Bile fluid |
BLDA |
Blood arterial |
BBL |
Blood bag |
BLDC |
Blood capillary |
BPU |
Blood product unit |
BLDV |
Blood venous |
BON |
Bone |
BRTH |
Breath (use EXHLD) |
BRO |
Bronchial |
BRN |
Burn |
CALC |
Calculus (=Stone) |
CDM |
Cardiac muscle |
CNL |
Cannula |
CTP |
Catheter tip |
CSF |
Cerebral spinal fluid |
CVM |
Cervical mucus |
CVX |
Cervix |
COL |
Colostrum |
CBLD |
Cord blood |
CNJT |
Conjunctiva |
CUR |
Curettage |
CYST |
Cyst |
DIAF |
Dialysis fluid |
DOSE |
Dose med or substance |
DRN |
Drain |
DUFL |
Duodenal fluid |
EAR |
Ear |
EARW |
Ear wax (cerumen) |
ELT |
Electrode |
ENDC |
Endocardium |
ENDM |
Endometrium |
EOS |
Eosinophils |
RBC |
Erythrocytes |
EYE |
Eye |
EXHLD |
Exhaled gas (=breath) |
FIB |
Fibroblasts |
FLT |
Filter |
FIST |
Fistula |
FLU |
Body fluid, unsp |
GAS |
Gas |
GAST |
Gastric fluid/contents |
GEN |
Genital |
GENC |
Genital cervix |
GENL |
Genital lochia |
GENV |
Genital vaginal |
HAR |
Hair |
IHG |
Inhaled Gas |
IT |
Intubation tube |
ISLT |
Isolate |
LAM |
Lamella |
WBC |
Leukocytes |
LN |
Line |
LNA |
Line arterial |
LNV |
Line venous |
LIQ |
Liquid NOS |
LYM |
Lymphocytes |
MAC |
Macrophages |
MAR |
Marrow |
MEC |
Meconium |
MBLD |
Menstrual blood |
MLK |
Milk |
MILK |
Breast milk |
NAIL |
Nail |
NOS |
Nose (nasal passage) |
ORH |
Other |
PAFL |
Pancreatic fluid |
PAT |
Patient |
PRT |
Peritoneal fluid /ascites |
PLC |
Placenta |
PLAS |
Plasma |
PLB |
Plasma bag |
PLR |
Pleural fluid (thoracentesis fld) |
PMN |
Polymorphonuclear neutrophils |
PPP |
Platelet poor plasma |
PRP |
Platelet rich plasma |
PUS |
Pus |
RT |
Route of medicine |
SAL |
Saliva |
SEM |
Seminal fluid |
SER |
Serum |
SKN |
Skin |
SKM |
Skeletal muscle |
SPRM |
Spermatozoa |
SPT |
Sputum |
SPTC |
Sputum - coughed |
SPTT |
Sputum - tracheal aspirate |
STON |
Stone (use CALC) |
STL |
Stool = Fecal |
SWT |
Sweat |
SNV |
Synovial fluid (Joint fluid) |
TEAR |
Tears |
THRT |
Throat |
THRB |
Thrombocyte (platelet) |
TISS |
Tissue |
TISG |
Tissue gall bladder |
TLGI |
Tissue large intestine |
TLNG |
Tissue lung |
TISPL |
Tissue placenta |
TSMI |
Tissue small intestine |
TISU |
Tissue ulcer |
TUB |
Tube NOS |
ULC |
Ulcer |
UMB |
Umbilical blood |
UMED |
Unknown medicine |
URTH |
Urethra |
UR |
Urine |
URC |
Urine clean catch |
URT |
Urine catheter |
URNS |
Urine sediment |
USUB |
Unknown substance |
VOM |
Vomitus |
BLD |
Whole blood |
BDY |
Whole body |
WAT |
Water |
WICK |
Wick |
WND |
Wound |
WNDA |
Wound abscess |
WNDE |
Wound exudate |
WNDD |
Wound drainage |
XXX |
To be specified in another part of the message |
None.