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
<IP_ADDRESS>, "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 <IP_ADDRESS> through <IP_ADDRESS>must 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 <IP_ADDRESS>, "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.

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.
 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.
 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,