4. Order Entry


Contents



4 . Order Entry

Chapter Chair/Editor:

Clement J. McDonald, MD Regenstrief Institute and Indiana University School of Medicine

Chapter Chair/Editor:

Hans Buitendijk Siemens Medical Solutions Health Services

Chapter Chair/Editor:

Gunther Schadow The Regenstrief Institute for Health Care

Chapter Chair/Editor:

Helen Stevens McKesson Information Solutions

Chapter Chair/Editor:

Austin Kreisler McKesson Information Solutions

Editor

Scott Robertson Kaiser Permanente

4.1 CHAPTER 4 CONTENTS

4.2 PURPOSE

The Order Entry transaction set provides for the transmission of orders or information about orders between applications that capture the order, by those that fulfill the order, and other applications as needed. An order is a request for material or services, usually for a specific patient. These services include medications from the pharmacy, clinical observations (e.g., vitals, I&Os) from the nursing service, tests in the laboratory, food from dietary, films from radiology, linens from housekeeping, supplies from central supply, an order to give a medication (as opposed to delivering it to the ward), etc.

Most orders are associated with a particular patient. However, the Standard also allows a department to order from another ancillary department without regard to a patient (e.g., floor stock), as well as orders originating in an ancillary department (i.e., any application may be the placer of an order or the filler of an order).

We refer to the person or entity who places the order as the placer. We refer to the person or entity that carries out the order as the filler (producer in ASTM terminology). In the case where the person or entity that carries out the order also requests the order, this person or entity is referred to as the filler and placer of the order. The filler may also request another application to assign a filler or placer order number.

This chapter defines the transactions at the seventh level, i.e., the abstract messages. Various schemes may be used to generate the actual characters that make up the messages according to the communications environment. The HL7 Encoding Rules will be used where there is not a complete Presentation Layer. This is described in Chapter 2, Section 2.6, "Message construction rules." The examples included in this chapter were constructed according to the HL7 Encoding Rules.

4.2.1 Preface (organization of this chapter)

This chapter has been organized into six major sections, General, Diet, Supply, Pharmacy, Vaccine and Transfusion Services. Each section contains the trigger events, message definitions, segments and examples for the specific type of order messages. Each section about a type of order is organized into background and overview, message structure, and message segments (that are specific to the order class in question). Special discussions of the use of fields, segments or messages, and examples are included. Segments are introduced in order of occurrence in a message. A list of allowable values for a field is included in the body of the text, along with the field definition for easier reference.

Section 4.3 refers the reader to Chapter 2 for an outline of the Quantity Timing (TQ) Data Type Definition.

Sections 4.4 to 4.6 'General' includes the triggers and segments for the clinical observations and diagnostic studies as well as the triggers and message segments that are common to all of the order entry messages. Orders for laboratory tests, bedside monitoring, diagnostic imaging, electrocardiograms, vital signs, etc., are subsumed under this order message set.

Sections 4.7 to 4.9 'Diet' includes all of the usual diet specifications including snacks and guest trays

Sections 4.10 to 4.12 'Supply' includes order messages for both Stock and No-stock orders. Supply orders are different in that they often are not patient-centered (e.g., requests to stock the ward supply room).

Sections 4.13 to 4.16 'Pharmacy / Treatment' includes all pharmacy and treatment related order messages. These sections additionally include triggers related to the dispensing, giving and administration of orders. In the development of the treatment order transaction set, the focus has been on medication treatments, but the same transaction set works well for total parenteral nutrition (TPN). There is hope that it is also sufficient for other kinds of treatment orders, such as those performed by the nursing service. But it has not yet been exercised in that context and may well need further development.

Sections 4.17 to 4.19 'Vaccine' includes triggers and segments specific to vaccination order messages. These sections also include RXA definitions specific to vaccination messages.

Sections 4.20 to 4.22 _Transfusion Service (Blood Bank)_ includes triggers and segments specific to transfusion service messages.

4.2.2 Glossary

4.2.2.0

4.2.2.1 Filler:

The application responding to, i.e., performing, a request for services (orders) or producing an observation. The filler can also originate requests for services (new orders), add additional services to existing orders, replace existing orders, put an order on hold, discontinue an order, release a held order, or cancel existing orders

4.2.2.2 Observation segment:

An OBX segment defined in Chapter 7.

4.2.2.3 Order:

A request for a service from one application to a second application. The second application may in some cases be the same; i.e., an application is allowed to place orders with itself.

4.2.2.4 Order detail segment:

One of several segments that can carry order information. Examples are OBR and RXO. Future ancillary-specific segments may be defined in subsequent releases of the Standard if they become necessary.

4.2.2.5 Placer:

The application or individual originating a request for services (order).

4.2.2.6 Placer order group:

A list of associated orders coming from a single location regarding a single patient.

4.3 QUANTITY/TIMING (TQ) DATA TYPE DEFINITION

Note: With version 2.5, the definition and narrative for the TQ _ Quantity/Timing data type has been moved to Chapter 2, Section 2.A.81. This section retained in v2.5 to maintain consistent section numbering for reference from other chapters.

4.4 GENERAL TRIGGER EVENTS & MESSAGE DEFINITIONS

This section includes trigger events and message definitions that are general to all orders in addition to the Observation and Diagnostic Study.

4.4.1 ORM - general order message (event O01)

Left for backward compatibility only. It is recommended that the trigger events OMG, OML, OMD, OMS, OMN, OMI, and OMP be used instead when communicating orders and order related events.

The function of this message is to initiate the transmission of information about an order. This includes placing new orders, cancellation of existing orders, discontinuation, holding, etc. ORM messages can originate also with a placer, filler, or an interested third party.

The trigger event for this message is any change to an order. Such changes include submission of new orders, cancellations, updates, patient and non-patient specific orders, etc.

The CTD segment in this trigger is used to transmit temporary patient contact details specific to this order.

ORM^O01^ORM_O01 General Order Message Status Chapter DB Ref.
MSH Message Header
2 DB
[ { NTE } ] Notes and Comments (for Header)
2 DB
[ --- PATIENT begin


PID Patient Identification
3 DB
[ PD1 ] Additional Demographics
3 DB
[ { NTE } ] Notes and Comments (for Patient ID)
2 DB
[ --- PATIENT_VISIT begin


PV1 Patient Visit
3 DB
[ PV2 ] Patient Visit- Additional Info
3 DB
] --- PATIENT_VISIT end


[{ --- INSURANCE begin


IN1 Insurance
6 DB
[ IN2 ] Insurance Additional Info
6 DB
[ IN3 ] Insurance Add'l Info _ Cert.
6 DB
}] --- INSURANCE end


[ GT1 ] Guarantor
6 DB
[ { AL1 } ] Allergy Information
3 DB
] --- PATIENT end


{ --- ORDER begin


ORC Common Order
4 DB
[ --- ORDER_DETAIL begin


< OBR | Order Detail Segment OBR, etc.
4 DB
RQD |



RQ1 |



RXO |



ODS |



ODT >



[ { NTE } ] Notes and Comments (for Detail)
2 DB
[ CTD ] Contact Data
11 DB
[ { DG1 } ] Diagnosis
6 DB
[{ --- OBSERVATION begin


OBX Observation/Result
7 DB
[ { NTE } ] Notes and Comments (for Results)
2 DB
}] --- OBSERVATION end


] --- ORDER_DETAIL end


[ { FT1 } ] Financial Transaction
6 DB
[ { CTI } ] Clinical Trial Identification
7 DB
[ BLG ] Billing Segment
4 DB
} --- ORDER end


4.4.1.0

4.4.1.1 ORM use notes

  1. The abstract message syntax for some order segments vary slightly. Please refer to the appropriate sections for specific examples: for supply orders (RQ), see Section 4.10 "Supply Trigger Events & Messages" for pharmacy, see Section 4.13 "Pharmacy/Treatment Trigger Events & Messages"; and for dietary orders, see Section 4.7, "Diet Trigger Events & Message Definitions".

  2. The segment named "Order Detail Segment" represents whichever of these order detail segment(s) is appropriate to the message, currently OBR, RQD, RQ1, RXO, ODS, ODT.

  3. The NTE segment(s) can be included in the ORM message in four places; in each place the NTE refers to the segment which it follows. In particular, the NTEs following the MSH refer only to the message header, the NTEs following the order detail segment apply to the service defined by that ORC and order detail segment.

  4. The PID segment is required if and only if new orders are being entered and they are related to a particular patient. For nonpatient-related orders the PID segment is never included.

  5. The optional PV1 segment is present mainly to permit transmission of patient visit information such as current location with an order.

  6. The order detail segments are not required when a simple control message is being sent. For example, a hold message (ORC-1-order control = HD) does not require that an order segment follow it.

  7. ORC-1-order control is critical to the operation of both ORM and ORR messages. For example, to request cancellation of an order, one would transmit a CA in ORC-1-order control of the appropriate ORC. (See the definition of ORC-1-order control.)

  8. A method to inquire for order status in the display format is provided in Chapter 2, and uses the record format provided in Chapter 7.

  9. Each order message that defines any type of new order (ORC-1-order control = NW, CH, RO, or SN) requires an ORC/OBR pair to define each order to the receiving application. This also applies to any other types of orders, with the OBR being replaced by the appropriate order detail segment, as defined below. Thus two consecutive ORCs could occur if a cancel order request (needing only the order numbers) were followed by a second cancel order request. Many other examples are possible.

  10. The insurance segments (IN1, IN2, and GT1) are typically used for external fillers, e.g., reference labs, where formal ADT transactions are overly complex or not needed.

4.4.2 ORR - general order response message response to any ORM (event O02)

Left for backward compatibility only. It is recommended that the trigger events ORG, ORL, ORD, ORS, ORN, ORI, and ORP be used instead when communicating orders and order related events.

The function of this message is to respond to an ORM message. An ORR message is the application acknowledgment to an ORM message. See Chapter 2 for a description of the acknowledgment paradigm.

In ORR the PID and ORC segments are optional, particularly in case of an error response. However, ORC segments are always required in ORR when an order detail segment is present. For example, a response ORR might include only the MSH and MSA, but if a RQ1 is present, it must be preceded by an ORC.

The function (e.g., cancel, new order) of both ORM and ORR messages is determined by the value in ORC-1-order control. (See the table of order control values for a complete list.)

ORR^O02^ORR_O02 General Order Acknowledgment Message Status Chapter DB Ref.
MSH Message Header
2 DB
MSA Message Acknowledgment
2 DB
[ { ERR } ] Error
2 DB
[ { NTE } ] Notes and Comments (for Header)
2 DB
[ --- RESPONSE begin


[ --- PATIENT begin


PID Patient Identification
3 DB
[ { NTE } ] Notes and Comments (for Patient ID)
2 DB
] --- PATIENT end


{ --- ORDER begin


ORC Common Order
4 DB
< OBR | [Order Detail Segment] OBR, etc.
4 DB
RQD |



RQ1 |



RXO |



ODS |



ODT >



[ { NTE } ] Notes and Comments (for Detail)
2 DB
[ { CTI } ] Clinical Trial Identification
7 DB
} --- ORDER end


] --- RESPONSE end


Note: ORRs for supply, pharmacy, and dietary orders all have slightly different message syntax; refer to the appropriate sections as detailed in Section 4.4.1.1, ORM use notes, for exact details.

4.4.3 OSQ/OSR- query response for order status (event Q06)

OSQ^Q06^OSQ_Q06 Order Status Query Status Chapter DB Ref.
MSH Message Header
2 DB
[ { SFT } ] Software
2 DB
QRD Query Definition
2 DB
[ QRF ] Query Filter
2 DB
[ DSC ] Continuation Pointer
2 DB

OSR^Q06^OSR_Q06 Order Status Response Status Chapter DB Ref.
MSH Message Header
2 DB
MSA Message Acknowledgment
2 DB
[ { ERR } ] Error
2 DB
[ { SFT } ] Software
2 DB
[ { NTE } ] Notes and Comments (for Header)
2 DB
QRD Query Definition
2 DB
[ QRF ] Query Filter
2 DB
[ --- RESPONSE begin


[ --- PATIENT begin


PID Patient Identification
3 DB
[ { NTE } ] Notes and Comments (for Patient ID)
2 DB
] --- PATIENT end


{ --- ORDER begin


ORC Common Order
4 DB
[{ --- TIMING begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
}] --- TIMING end


< OBR | [Order Detail Segment] OBR, etc.
4 DB
RQD |



RQ1 |



RXO |



ODS |



ODT >



[ { NTE } ] Notes and Comments (for Detail)
2 DB
[ { CTI } ] Clinical Trial Identification
7 DB
} --- ORDER end


] --- RESPONSE end


[ DSC ] Continuation Pointer
2 DB

4.4.3.0

4.4.3.1 Query usage notes

The QRD and QRF segments are defined in Chapter 2, Section 2.15, "Message Control Segments."

The subject filters contained in the QRD and QRF segments describe the kind of information that is required to satisfy the request. They are defined by local agreement between the inquiring system and the ancillary system. See the Implementation Guide for detailed examples of the use of query filter fields.

The Set ID fields in the various segments (including PID) are used to count the number of segments of one kind transmitted at one level of the hierarchy.

The Query Result Level field of the QRD determines the amount of data requested. See Chapter 5, Section 5.10.5.3, "QRD - original style query definition segment."

The OSQ message is a record-oriented query that has the structure as the regular QRY message. OSQ is included here for the convenience of implementers.

4.4.4 OMG - general clinical order message (event O19)

The function of this message is to initiate the transmission of information about a general clinical order that uses the OBR segment. Messages using the ORM message with the OBR segment are supported for backward compatibility. This includes placing new orders, cancellation of existing orders, discontinuation, holding, etc. OMG messages can originate also with a placer, filler, or an interested third party.

The trigger event for this message is any change to a general clinical order. Such changes include submission of new orders, cancellations, updates, patient and non-patient-specific orders, etc.

This trigger includes segments identified as being for 'previous results'. These segments allow the sending system to include demographic and/or result information from previous result reports when they are related to the current order.

For example:

The CTD segment in this trigger is used to transmit temporary patient contact details specific to this order.

OMG^O19^OMG_O19 General Clinical Order Message Status Chapter DB Ref.
MSH Message Header
2 DB
[ { SFT } ] Software
2 DB
[ { NTE } ] Notes and Comments (for Header)
2 DB
[ --- PATIENT begin


PID Patient Identification
3 DB
[ PD1 ] Additional Demographics
3 DB
[ { NTE } ] Notes and Comments (for Patient ID)
2 DB
[ { NK1 } ] Next of Kin/Associated Parties
3 DB
[ --- PATIENT_VISIT begin


PV1 Patient Visit
3 DB
[ PV2 ] Patient Visit- Additional Info
3 DB
] --- PATIENT_VISIT end


[{ --- INSURANCE begin


IN1 Insurance
6 DB
[ IN2 ] Insurance Additional Info
6 DB
[ IN3 ] Insurance Add'l Info - Cert.
6 DB
}] --- INSURANCE end


[ GT1 ] Guarantor
6 DB
[ { AL1 } ] Allergy Information
3 DB
] --- PATIENT end


{ --- ORDER begin


ORC Common Order
4 DB
[{ --- TIMING begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
}] --- TIMING end


OBR Observation
4 DB
[ { NTE } ] Notes and Comments (for Detail)
2 DB
[ CTD ] Contact Data
11 DB
[ { DG1 } ] Diagnosis
6 DB
[{ --- OBSERVATION begin


OBX Observation/Result
7 DB
[ { NTE } ] Notes and Comments (for Results)
2 DB
}] --- OBSERVATION end


[{ --- SPECIMEN begin


SPM Specimen
7 DB
[ { OBX } ] Observation/Result
7 DB
[{ --- CONTAINER begin


SAC Specimen Container
13 DB
[ { OBX } ] Observation/Result
7 DB
}] --- CONTAINER end


}] --- SPECIMEN end


[{ --- PRIOR_RESULT begin


[ --- PATIENT_PRIOR begin


PID Patient Identification _ previous result
3 DB
[ PD1 ] Additional Demographics _ previous result
3 DB
] --- PATIENT_PRIOR end


[ --- PATIENT_VISIT_PRIOR begin


PV1 Patient Visit _ previous result
3 DB
[ PV2 ] Patient Visit Add. Info _ previous result
3 DB
] --- PATIENT_VISIT_PRIOR end


[ { AL1 } ] Allergy Information - previous result
3 DB
{ --- ORDER_PRIOR begin


[ ORC ] Common Order - previous result
4 DB
OBR Order Detail - previous result
4 DB
[{ --- TIMING_PRIOR begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
}] --- TIMING_PRIOR end


[ { NTE } ] Notes and Comments - previous result
2 DB
[ CTD ] Contact Data - previous result
10 DB
{ --- OBSERVATION_PRIOR begin


OBX Observation/Result - previous result
7 DB
[ { NTE } ] Notes and Comments - previous result
2 DB
} --- OBSERVATION_PRIOR end


} --- ORDER_PRIOR end


}] --- PRIOR_RESULT end


[ { FT1 } ] Financial Transaction
6 DB
[ { CTI } ] Clinical Trial Identification
7 DB
[ BLG ] Billing Segment
4 DB
} --- ORDER end


4.4.5 ORG - general clinical order acknowledgement message (event O20)

The function of this message is to respond to an OMG message. An ORG message is the application acknowledgment to an OMG message. See Chapter 2 for a description of the acknowledgment paradigm.

In ORG the PID and ORC segments are optional, particularly in case of an error response. However, ORC segments are always required in ORG when the OBR is present. For example, a response ORG might include only the MSH and MSA.

The function (e.g., cancel, new order) of both OMG and ORG messages is determined by the value in ORC-1-order control. (See the table of order control values for a complete list.)

ORG^O20^ORG_O20 General Clinical Order Acknowledgment Message Status Chapter DB Ref.
MSH Message Header
2 DB
MSA Message Acknowledgment
2 DB
[ { ERR } ] Error
2 DB
[ { SFT } ] Software
2 DB
[ { NTE } ] Notes and Comments (for Header)
2 DB
[ --- RESPONSE begin


[ --- PATIENT begin


PID Patient Identification
3 DB
[ { NTE } ] Notes and Comments (for Patient ID)
2 DB
] --- PATIENT end


{ --- ORDER begin


ORC Common Order
4 DB
[{ --- TIMING begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
}] --- TIMING end


[ OBR ] Observation
4 DB
[ { NTE } ] Notes and Comments (for Detail)
2 DB
[ { CTI } ] Clinical Trial Identification
7 DB
[{ --- SPECIMEN begin


SPM Specimen
7 DB
[ { SAC } ] Specimen Container Details
13 DB
}] --- SPECIMEN end


} --- ORDER end


] --- RESPONSE end


4.4.6 OML - laboratory order message (event O21)

The following message structure may be used for the communication of laboratory and other order messages and must be used for lab automation messages where it is required that the Specimen/Container information is within the ORC/OBR segment group. While the ORM message with the OBR segment can be used for backwards compatibility for general lab messages, only the OML message should be used to take advantage of the specimen and container extensions required in laboratory automation.

The trigger event for this message is any change to a laboratory order. Such changes include submission of new orders, cancellations, updates, etc. OML messages can originate also with a placer, filler, or an interested third party.

Note: The additional patient information (the segments PID, PD1, PV1, PV2, etc, which are sent after the OBR with the current order (indicated below with words "previous result"), could have been transferred with the previous result, because the patient demographics related to the previous result can differ from the demographics related to the current order. The current intent is to only allow references to the same patient as in the header PID.

The SAC segments included in the message allow the transfer of, e.g.: a laboratory order with multiple containers and multiple test orders related to each container, or laboratory orders with test order requiring multiple containers.

Refer to Chapter 13 Laboratory Automation for examples of usage, particularly to clarify the use of two references to SAC segments in this one message.

The CTD segment in this trigger is used to transmit temporary patient contact details specific to this order.

In relationship to triggers O21, O33, and O35, this message/trigger (O21) should be used where an order with multiple samples and optionally multiple containers per order item are to be communicated.

OML^O21^OML_O21 Laboratory Order Message Status Chapter DB Ref.
MSH Message Header
2 DB
[ { SFT } ] Software
2 DB
[ { NTE } ] Notes and Comments (for Header)
2 DB
[ --- PATIENT begin


PID Patient Identification
3 DB
[ PD1 ] Additional Demographics
3 DB
[ { NTE } ] Notes and Comments (for Patient ID)
2 DB
[ { NK1 } ] Next of Kin/Associated Parties
3 DB
[ --- PATIENT_VISIT begin


PV1 Patient Visit
3 DB
[ PV2 ] Patient Visit- Additional Info
3 DB
] --- PATIENT_VISIT end


[{ --- INSURANCE begin


IN1 Insurance
6 DB
[ IN2 ] Insurance Additional Info
6 DB
[ IN3 ] Insurance Add'l Info - Cert.
6 DB
}] --- INSURANCE end


[ GT1 ] Guarantor
6 DB
[ { AL1 } ] Allergy Information
3 DB
] --- PATIENT end


{ --- ORDER begin


ORC Common Order
4 DB
[{ --- TIIMING begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
}] --- TIMING end


[ --- OBSERVATION_REQUEST begin


OBR Observation Request
4 DB
[ TCD ] Test Code Details
13 DB
[ { NTE } ] Notes and Comments (for Detail)
2 DB
[ CTD ] Contact Data
11 DB
[ { DG1 } ] Diagnosis
6 DB
[{ --- OBSERVATION begin


OBX Observation/Result
7 DB
[ TCD ] Test Code Detail
13 DB
[ { NTE } ] Notes and Comments (for Results)
2 DB
}] --- OBSERVATION end


[{ --- SPECIMEN begin


SPM Specimen
7 DB
[ { OBX } ] Observation/Result related to specimen
7 DB
[{ --- CONTAINER begin


SAC Specimen Container
13 DB
[ { OBX } ] Observation/Result related to container
7 DB
}] --- CONTAINER end


}] --- SPECIMEN end


[{ --- PRIOR_RESULT begin


[ --- PATIENT_PRIOR begin


PID Patient Identification _ previous result
3 DB
[ PD1 ] Additional Demographics _ previous result
3 DB
] --- PATIENT_PRIOR end


[ --- PATIENT_VISIT_PRIOR begin


PV1 Patient Visit _ previous result
3 DB
[ PV2 ] Patient Visit Add. Info _ previous result
3 DB
] --- PATIENT_VISIT_PRIOR end


[ { AL1 } ] Allergy Information - previous result
3 DB
{ --- ORDER_PRIOR begin


[ ORC ] Common Order - previous result
4 DB
OBR Order Detail - previous result
4 DB
[ { NTE } ] Notes and Comments - previous result
2 DB
[{ --- TIMING_PRIOR begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
}] --- TIMING_PRIOR end


{ --- OBSERVATION_PRIOR begin


OBX Observation/Result - previous result
7 DB
[ { NTE } ] Notes and Comments - previous result
2 DB
} --- OBSERVATION_PRIOR end


} --- ORDER_PRIOR end


}] --- PRIOR_RESULT end


] --- OBSERVATION_REQUEST end


[ { FT1 } ] Financial Transaction
6 DB
[ { CTI } ] Clinical Trial Identification
7 DB
[ BLG ] Billing Segment
4 DB
} --- ORDER end







4.4.7 ORL - general laboratory order response message to any OML (event O22)

The function of this message is to respond to an OML message. An ORL message is the application acknowledgment to an OML message. See Chapter 2 for a description of the acknowledgment paradigm.

ORL^O22^ORL_O22 General Laboratory Order Acknowledgment Message Status Chapter DB Ref.
MSH Message Header
2 DB
MSA Message Acknowledgment
2 DB
[ { ERR } ] Error
2 DB
[ { SFT } ] Software
2 DB
[ { NTE } ] Notes and Comments (for Header)
2 DB
[ --- RESPONSE begin


[ --- PATIENT begin


PID Patient Identification
3 DB
[{ --- ORDER begin


ORC Common Order
4 DB
[{ --- TIMING begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
}] --- TIMING end


[ --- OBSERVATION_REQUEST begin


OBR Observation Request
4 DB
[{ --- SPECIMEN begin


SPM Specimen
7 DB
[ { SAC } ] Specimen Container Details
13 DB
}] --- SPECIMEN end


] --- OBSERVATION_REQUEST end


}] --- ORDER end







] --- PATIENT end


] --- RESPONSE end


4.4.8 OML _ Laboratory order for multiple orders related to a single specimen (event O33)

The trigger event for this message is any change to a laboratory order. Such changes include submission of new orders, cancellations, updates, etc where multiple orders are associated with a single sample which may be carried in multiple containers. OML messages can originate also with a placer, filler, or an interested third party.

This allows for a Specimen-centric message with multiple orders per specimen grouped by the specimen.

The following message structure may be used for the communication of laboratory and other order messages and must be used for lab automation messages where the message requires Specimen/container information to group a number of orders. While the ORM message with the OBR segment can be used for backwards compatibility for general lab messages, only the OML message should be used to take advantage of the specimen and container extensions required in laboratory automation.

In relationship to triggers O21, O33, and O35, this message/trigger (O33) should be used where an a specimen, with optional multiple containers, may have multiple orders are to be communicated.

OML^O33^OML_O33 Laboratory Order _ Multiple Order Per Specimen Message Status Chapter DB Ref.
MSH Message Header
2 DB
[ { SFT } ] Software
2 DB
[ { NTE } ] Notes and Comments (for Header)
2 DB
[ --- PATIENT begin


PID Patient Identification
3 DB
[ PD1 ] Additional Demographics
3 DB
[ { NTE } ] Notes and Comments (for Patient ID)
2 DB
[ { NK1 } ] Next of Kin/Associated Parties
3 DB
[ --- PATIENT_VISIT begin


PV1 Patient Visit
3 DB
[ PV2 ] Patient Visit- Additional Info
3 DB
] --- PATIENT_VISIT end


[{ --- INSURANCE begin


IN1 Insurance
6 DB
[ IN2 ] Insurance Additional Info
6 DB
[ IN3 ] Insurance Add'l Info - Cert.
6 DB
}] --- INSURANCE end


[ GT1 ] Guarantor
6 DB
[ { AL1 } ] Allergy Information
3 DB
] --- PATIENT end


{ --- SPECIMEN begin


SPM Specimen
7 DB
[ { OBX } ] Observations related to specimen
7 DB
[ { SAC } ] Specimen Container
13 DB
{ --- ORDER begin


ORC Common Order
4 DB
[{ --- TIIMING begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
}] --- TIMING end


[ --- OBSERVATION_REQUEST begin


OBR Observation Request
4 DB
[ TCD ] Test Code Details
13 DB
[ { NTE } ] Notes and Comments (for Detail)
2 DB
[ { DG1 } ] Diagnosis
6 DB
[{ --- OBSERVATION begin


OBX Observation/Result
7 DB
[ TCD ] Test Code Detail
13 DB
[ { NTE } ] Notes and Comments (for Results)
2 DB
}] --- OBSERVATION end


[{ --- PRIOR_RESULT begin


[ --- PATIENT_PRIOR begin


PID Patient Identification _ previous result
3 DB
[ PD1 ] Additional Demographics _ previous result
3 DB
] --- PATIENT_PRIOR end


[ --- PATIENT_VISIT_PRIOR begin


PV1 Patient Visit _ previous result
3 DB
[ PV2 ] Patient Visit Add. Info _ previous result
3 DB
] --- PATIENT_VISIT_PRIOR end


[ { AL1 } ] Allergy Information - previous result
3 DB
{ --- ORDER_PRIOR begin


[ ORC ] Common Order - previous result
4 DB
OBR Order Detail - previous result
4 DB
[ { NTE } ] Notes and Comments - previous result
2 DB
[{ --- TIMING_PRIOR begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
}] --- TIMING_PRIOR end


{ --- OBSERVATION_PRIOR begin


OBX Observation/Result - previous result
7 DB
[ { NTE } ] Notes and Comments - previous result
2 DB
} --- OBSERVATION_PRIOR end


} --- ORDER_PRIOR end


}] --- PRIOR_RESULT end


] --- OBSERVATION_REQUEST end


[ { FT1 } ] Financial Transaction
6 DB
[ { CTI } ] Clinical Trial Identification
7 DB
[ BLG ] Billing Segment
4 DB
} --- ORDER end


} --- SPECIMEN end


4.4.9 ORL _ Laboratory order response message to a multiple order related to single specimen OML (event O34)

The function of this message is to respond to an OML message where the original trigger event produced an OML with the Specimen Group segment above the ORC. An ORL message is the application acknowledgment to an OML message. See Chapter 2 for a description of the acknowledgment paradigm.

ORL^O34^ORL_O34 Laboratory Order Acknowledgment Message _ Multiple Order Per Specimen Status Chapter DB Ref.
MSH Message Header
2 DB
MSA Message Acknowledgment
2 DB
[ { ERR } ] Error
2 DB
[ { SFT } ] Software
2 DB
[ { NTE } ] Notes and Comments (for Header)
2 DB
[ --- RESPONSE begin


[ --- PATIENT begin


PID Patient Identification
3 DB
{ --- SPECIMEN begin


SPM Specimen
7 DB
[ { OBX } ] Observations related to specimen
7 DB
[ { SAC } ] Specimen Container

DB
[{ --- ORDER begin


ORC Common Order
4 DB
[{ --- TIMING begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
}] --- TIMING end


[ --- OBSERVATION_REQUEST begin


OBR Observation Request
4 DB
[{ --- SPECIMEN begin


SPM Specimen
7 DB
[ { SAC } ] Specimen Container Details
13 DB
}] --- SPECIMEN end


] --- OBSERVATION_REQUEST end


}] --- ORDER end


} --- SPECIMEN end


] --- PATIENT end


] --- RESPONSE end


4.4.10 OML _ Laboratory order for multiple orders related to a single container of a specimen (event O35)

The trigger event for this message is any change to a laboratory order. Such changes include submission of new orders, cancellations, updates, etc where multiple orders are associated with a single sample which may be carried in multiple containers. OML messages can originate also with a placer, filler, or an interested third party.

This allows for a Specimen-centric message with multiple orders per specimen grouped by the specimen.

The following message structure may be used for the communication of laboratory and other order messages and must be used for lab automation messages where the message requires Specimen/container information to group a number of orders. While the ORM message with the OBR segment can be used for backwards compatibility for general lab messages, only the OML message should be used to take advantage of the specimen and container extensions required in laboratory automation.

In relationship to triggers O21, O33, and O35, this message/trigger (O35) should be used for laboratory orders where there is 1 or more Specimens with 1 to many containers each container may have 1 to many orders with previous result(s) per container.

OML^O35^OML_O35 Laboratory Order _ Multiple Order Per Container of Specimen Message Status Chapter DB Ref.
MSH Message Header
2 DB
[ { SFT } ] Software
2 DB
[ { NTE } ] Notes and Comments (for Header)
2 DB
[ --- PATIENT begin


PID Patient Identification
3 DB
[ PD1 ] Additional Demographics
3 DB
[ { NTE } ] Notes and Comments (for Patient ID)
2 DB
[ { NK1 } ] Next of Kin/Associated Parties
3 DB
[ --- PATIENT_VISIT begin


PV1 Patient Visit
3 DB
[ PV2 ] Patient Visit- Additional Info
3 DB
] --- PATIENT_VISIT end


[{ --- INSURANCE begin


IN1 Insurance
6 DB
[ IN2 ] Insurance Additional Info
6 DB
[ IN3 ] Insurance Add'l Info - Cert.
6 DB
}] --- INSURANCE end


[ GT1 ] Guarantor
6 DB
[ { AL1 } ] Allergy Information
3 DB
] --- PATIENT end


{ --- SPECIMEN begin


SPM Specimen
7 DB
[ { OBX } ] Observations related to specimen
7 DB
{ --- SPECIMEN_CONTAINER begin


SAC Specimen Container
13 DB
{ --- ORDER begin


ORC Common Order
4 DB
[{ --- TIIMING begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
}] --- TIMING end


[ --- OBSERVATION_REQUEST begin


OBR Observation Request
4 DB
[ TCD ] Test Code Details
13 DB
[ { NTE } ] Notes and Comments (for Detail)
2 DB
[ { DG1 } ] Diagnosis
6 DB
[{ --- OBSERVATION begin


OBX Observation/Result
7 DB
[ TCD ] Test Code Detail
13 DB
[ { NTE } ] Notes and Comments (for Results)
2 DB
}] --- OBSERVATION end


[{ --- PRIOR_RESULT begin


[ --- PATIENT_PRIOR begin


PID Patient Identification _ previous result
3 DB
[ PD1 ] Additional Demographics _ previous result
3 DB
] --- PATIENT_PRIOR end


[ --- PATIENT_VISIT_PRIOR begin


PV1 Patient Visit _ previous result
3 DB
[ PV2 ] Patient Visit Add. Info _ previous result
3 DB
] --- PATIENT_VISIT_PRIOR end


[ { AL1 } ] Allergy Information - previous result
3 DB
{ --- ORDER_PRIOR begin


[ ORC ] Common Order - previous result
4 DB
OBR Order Detail - previous result
4 DB
[ { NTE } ] Notes and Comments - previous result
2 DB
[{ --- TIMING_PRIOR begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
}] --- TIMING_PRIOR end


{ --- OBSERVATION_PRIOR begin


OBX Observation/Result - previous result
7 DB
[ { NTE } ] Notes and Comments - previous result
2 DB
} --- OBSERVATION_PRIOR end


} --- ORDER_PRIOR end


}] --- PRIOR_RESULT end


] --- OBSERVATION_REQUEST end


[ { FT1 } ] Financial Transaction
6 DB
[ { CTI } ] Clinical Trial Identification
7 DB
[ BLG ] Billing Segment
4 DB
} --- ORDER end


} --- SPECIMEN_CONTAINER end


} --- SPECIMEN end


4.4.11 ORL _ Laboratory order response message to a single container of a specimen OML (event O36)

The function of this message is to respond to an OML message where the original trigger event produced an OML with the Specimen Group segment above the ORC. An ORL message is the application acknowledgment to an OML message. See Chapter 2 for a description of the acknowledgment paradigm.

ORL^O36^ORL_O36 Laboratory Order Acknowledgment Message _ Multiple Order Per Container of Specimen Status Chapter DB Ref.
MSH Message Header
2 DB
MSA Message Acknowledgment
2 DB
[ { ERR } ] Error
2 DB
[ { SFT } ] Software
2 DB
[ { NTE } ] Notes and Comments (for Header)
2 DB
[ --- RESPONSE begin


[ --- PATIENT begin


PID Patient Identification
3 DB
{ --- SPECIMEN begin


SPM Specimen
7 DB
[ { OBX } ] Observations related to specimen
7 DB
{ --- SPECIMEN_CONTAINER begin


SAC Specimen Container
13 DB
[{ --- ORDER begin


ORC Common Order
4 DB
[{ --- TIMING begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
}] --- TIMING end


[ --- OBSERVATION_REQUEST begin


OBR Observation Request
4 DB
] --- OBSERVATION_REQUEST end


}] --- ORDER end


} --- SPECIMEN_CONTAINER end


} --- SPECIMEN end


] --- PATIENT end


] --- RESPONSE end


4.4.12 OMI _ Imaging Order Message (Event O23)

This message is used in communication between the information systems involved in the fulfillment of the request directed to the imaging department, such as a Radiology Information System (RIS) and a Picture Archiving and Communication System (PACS). For the purpose of the following discussion these systems will be identified as Imaging Department Information Systems (IDIS). Information contained in the Imaging Procedure Control (IPC) segment allows multiple IDIS to share the context of Imaging Studies (collections of images acquired, processed, stored, and interpreted) in Image Management tasks.

The order for the imaging service is communicated between the Order Placer (such as an Order Entry system) and the Order Filler (such as an RIS). In the imaging department environment, the Order Filler also identifies the set of procedures (studies) and sub-procedures (procedure steps) that have to be performed in the process of fulfilling the order. Each sub-procedure is performed using a single device (station). The Order Filler identifies the type of device and either a specific device or group of devices (for example, by geographic location) one of which is to be used in performing the procedure step. Thus, the system performs an aspect of workflow management in the department.

Another information system in the department may be managing storage and distribution of the images within the department as well as providing them to the enterprise. This system will have to operate within the same context as the system managing the workflow. This context includes identifiers, content of the order, and details of procedures and procedure steps that have to be performed to fulfill that particular order.

It is expected that the OMI message will typically be used in communication between IDIS as depicted in figure 4-1.

Figure 4-1. Use of OMI message

OMI^O23^OMI_O23 Imaging Order Message Status Chapter DB Ref.
MSH Message Header
2 DB
[ { SFT } ] Software
2 DB
[ { NTE } ] Notes and Comments (for Header)
2 DB
[ --- PATIENT begin


PID Patient Identification
3 DB
[ PD1 ] Additional Demographics
3 DB
[ { NTE } ] Notes and Comments (for Patient ID)
2 DB
[ --- PATIENT_VISIT begin


PV1 Patient Visit
3 DB
[ PV2 ] Patient Visit- Additional Info
3 DB
] --- PATIENT_VISIT end


[{ --- INSURANCE begin


IN1 Insurance
6 DB
[ IN2 ] Insurance Additional Info
6 DB
[ IN3 ] Insurance Add'l Info _ Cert.
6 DB
}] --- INSURANCE end


[ GT1 ] Guarantor
6 DB
[ { AL1 } ] Allergy Information
3 DB
] --- PATIENT end


{ --- ORDER begin


ORC Common Order
4 DB
[{ --- TIMING begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
}] --- TIMING end


OBR Observation
4 DB
[ { NTE } ] Notes and Comments (for Detail)
2 DB
[ CTD ] Contact Data
11 DB
[ { DG1 } ] Diagnosis
6 DB
[{ --- OBSERVATION begin


OBX Observation/Result
7 DB
[ { NTE } ] Notes and Comments (for Results)
2 DB
}] --- OBSERVATION end


{ IPC } Imaging Procedure Control
4 DB
} --- ORDER end


4.4.13 ORI - Imaging Order Response Message To Any OMI (Event O24)

The function of this message is to respond to an OMI message. An ORI message is the application acknowledgment to an OMI message. See Chapter 2 for a description of the acknowledgment paradigm.

ORI^O24^ORI_O24 Imaging Order Acknowledgment Message Status Chapter DB Ref.
MSH Message Header
2 DB
MSA Message Acknowledgment
2 DB
[ { ERR } ] Error
2 DB
[ { SFT } ] Software
2 DB
[ { NTE } ] Notes and Comments (for Header)
2 DB
[ --- RESPONSE begin


[ --- PATIENT begin


PID Patient Identification
3 DB
[ { NTE } ] Notes and Comments (for Patient ID)
2 DB
] --- PATIENT end


{ --- ORDER begin


ORC Common Order
4 DB
[{ --- TIMING begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
}] --- TIMING end


OBR Observation
4 DB
[ { NTE } ] Notes and Comments (for Detail)
2 DB
{ IPC } Imaging Procedure Control
4 DB
} --- ORDER end


] --- RESPONSE end


4.5 GENERAL SEGMENTS

The following segments (ORC and BLG) are common to many order messages.

4.5.1 ORC - Common Order Segment

The Common Order segment (ORC) is used to transmit fields that are common to all orders (all types of services that are requested). The ORC segment is required in the Order (ORM) message. ORC is mandatory in Order Acknowledgment (ORR) messages if an order detail segment is present, but is not required otherwise.

If details are needed for a particular type of order segment (e.g., Pharmacy, Dietary), the ORC must precede any order detail segment (e.g., RXO, ODS). In some cases, the ORC may be as simple as the string ORC|OK|<placer order number>|<filler order number>|<cr>.

If details are not needed for the order, the order detail segment may be omitted. For example, to place an order on hold, one would transmit an ORC with the following fields completed: ORC-1-order control with a value of HD, ORC-2-placer order number, and ORC-3-filler order number.

There is some overlap between fields of the ORC and those in the order detail segments. These are described in the succeeding sections.

HL7 Attribute Table _ ORC _ Common Order

SEQ LEN DT OPT RP/# TBL# ITEM# ELEMENT NAME DB Ref.
1 2 ID R
0119 00215 Order Control DB
2 22 EI C

00216 Placer Order Number DB
3 22 EI C

00217 Filler Order Number DB
4 22 EI O

00218 Placer Group Number DB
5 2 ID O
0038 00219 Order Status DB
6 1 ID O
0121 00220 Response Flag DB
7 200 TQ B Y
00221 Quantity/Timing DB
8 200 EIP O

00222 Parent DB
9 26 TS O

00223 Date/Time of Transaction DB
10 250 XCN O Y
00224 Entered By DB
11 250 XCN O Y
00225 Verified By DB
12 250 XCN O Y
00226 Ordering Provider DB
13 80 PL O

00227 Enterer's Location DB
14 250 XTN O Y/2
00228 Call Back Phone Number DB
15 26 TS O

00229 Order Effective Date/Time DB
16 250 CE O

00230 Order Control Code Reason DB
17 250 CE O

00231 Entering Organization DB
18 250 CE O

00232 Entering Device DB
19 250 XCN O Y
00233 Action By DB
20 250 CE O
0339 01310 Advanced Beneficiary Notice Code DB
21 250 XON O Y
01311 Ordering Facility Name DB
22 250 XAD O Y
01312 Ordering Facility Address DB
23 250 XTN O Y
01313 Ordering Facility Phone Number DB
24 250 XAD O Y
01314 Ordering Provider Address DB
25 250 CWE O

01473 Order Status Modifier DB
26 60 CWE C
0552 01641 Advanced Beneficiary Notice Override Reason DB
27 26 TS O

01642 Filler's Expected Availability Date/Time DB
28 250 CWE O
0177 00615 Confidentiality Code DB
29 250 CWE O
0482 01643 Order Type DB
30 250 CNE O
0483 01644 Enterer Authorization Mode DB

ORC use notes

  1. placer order groups

The Standard supports a mechanism to collect several orders together in a group. Most often this is used to represent an "ordering session" for a single patient.

An order group is a list of orders (ORCs) associated with an ORC-4-placer group number. A group is established when the placer supplies a placer group number with the original order. The order group consists of all the ORCs and order detail segments that have the same placer group number. Orders can be removed from the group using cancel, or added using the replacement or parent-child mechanisms. New orders cannot otherwise be added to the group.

  1. duplicate fields

The ORC is intended to uniformly define the fields that are common to all orders (i.e., requested services). Some ORC fields are duplicated in some order detail segments (e.g., OBR, RXO). For example, ORC-2-placer order number has the same meaning and purpose as OBR-2-placer order number field. This promotes upward compatibility with past versions and ASTM.

The rule for using these fields is that the value must appear in the order detail segment if it does not appear in the ORC. However, it is recommended to transmit the field value in both places to avoid confusion.

  1. parent/child - cancel, hold, discontinue

During transmission of a request to cancel, hold, or discontinue a parent order, the request is intended to apply recursively to the parent order and all associated child orders.

For example:

  1. An EKG application receives an order for three EKGs on successive mornings.

  2. The EKG application creates three child orders, one for each requested EKG.

  3. The first daily EKG has already been performed when a request is received to cancel the original parent order. (The parent is beyond the point of cancellation.)

  4. The remaining, unperformed, children are canceled as a result of the request.

4.5.1.0 ORC field definitions

4.5.1.1 ORC-1 Order Control (ID) 00215

Definition: Determines the function of the order segment. Refer to HL7 Table 0119 - Order Control Codes And Their Meaning for valid entries. Depending on the message, the action of the control code may refer to an order or an individual service. For example, the code CA in an OMP message cancels the order. The same code in an RDS message, cancels the dispense. Very detailed explanatory notes are given at the end of this section.

This field may be considered the "trigger event" identifier for orders. The codes fall roughly into the following three categories:

  1. event request

Codes like "NW" (new order) and "CA" (cancel order request) are used to initiate an event.

  1. event acknowledgment

Codes like "OK" (order accepted) and "CR" (canceled as requested) are used to reply to the event request.

  1. event notification

Codes like "OC" (order canceled) and "OD" (order discontinued) are used to notify other applications that an event has occurred. No application reply is necessary.

Event request codes are intended to initiate an event. Event acknowledgment codes are intended to reply to an application that requested an event. Event notification codes are intended to notify another application that, e.g., the filler has performed some action on an order that the other application, e.g., the placer, needs to know.

Fillers, placers, and other applications can use event requests, event acknowledgments, and event - notification-type trigger events interchangeably. However, certain order control codes can originate only from the filler (e.g., CR) and others can only originate from the placer (e.g., CA).

Refer to section 4.19.1 for the contents of HL7 Table 0119 _ Order Control Codes.

4.5.1.1.1 Table notes for order control codes of ORC
  1. CA

A cancellation is a request not to do a previously ordered service. Confirmation of the cancellation request is provided by the filler, e.g., a message with an ORC-1-order control value of CR.

  1. UC

An unable-to-cancel code is used when the ordered service is at a point that it cannot be canceled by the filler or when local rules prevent cancellation by the filler. The use of this code is dependent on the value of ORC-6-response flag.

  1. DC

A discontinue request code is used to stop an ongoing ordered service. It is not the same as a cancellation request, which is used in an attempt to prevent an order from happening.

  1. RP, RQ, RU, RO

A replacement is the substitution of one or more orders for one or more previously ordered services.

The replaced orders are treated as though they were canceled. If and when an ordered service can be replaced are local site-specific determinations.

Use the parent/child order control codes if the site specifies that the original order must remain intact. Do not use the replacement codes under this circumstance.

For each order to be replaced, use an ORC-1-order control value of RP (request for a replacement going to a filler) or RU (an unsolicited replacement created by the filler) used by the filler to notify the placer and/or other systems). By local agreement, the ORC segment (with RP or RU) may be followed by its original order detail segment. The ORC segments (with RP or RU) must be followed by an ORC segment with an ORC-1-order control value of RO (indicating the replacement order). By local agreement, the ORC with the RO value may be followed by an order detail segment.

For example, suppose that an ancillary application were replacing two OBR orders with three different orders. The sequence of segments would be as follows:

Figure 4-2. RU and RO usage (example)

Segment Order Control Comment
ORC RU 1st replaced ORC
OBR
1st replaced order's detail segment



ORC RU 2nd replaced ORC
OBR
2nd replaced order's detail segment



ORC RO 1st replacement ORC
OBR
1st replacement order's detail segment



ORC RO 2nd replacement ORC
OBR
2nd replacement order's detail segment



ORC RO 3rd replacement ORC
OBR
3rd replacement order's detail segment

Whether the OBR segments must be present is determined by the value of ORC-6-response flag.

The described replacement method will handle all possible cases of replacement: one-into-one, many-into-one, one-into-many, and many-into-many. If the placer sent this request to the filler with two RPs, and this was a response back from the filler to the placer, the two RUs (replaced unsolicited) would be two RQs (replaced as requested).

Figure 4-3. RQ and RO usage (example)

Segment Order Control Comment
ORC RQ 1st replaced ORC
OBR
1st replaced order's detail segment



ORC RQ 2nd replaced ORC
OBR
2nd replaced order's detail segment



ORC RO 1st replacement ORC
OBR
1st replacement order's detail segment



ORC RO 2nd replacement ORC
OBR
2nd replacement order's detail segment



ORC RO 3rd replacement ORC
OBR
3rd replacement order's detail segment

  1. RP, RQ

The order replace request code permits the order filler to replace one or more new orders with one or more new orders, at the request of the placer application.

  1. RU

The unsolicited replacement code permits the filler application to notify another application without being requested from the placer application.

  1. RO, RQ

The replacement order code is sent by the filler application to another application indicating the exact replacement ordered service. It is used with the RP and RU order control codes as described above.

  1. RP, RQ, RU, RO

The rules for the order numbers in ORC segments with an order control value of RO are determined by the replacement type (RP or RU).

In the case of the RU type (i.e., unsolicited replacement by the filler), the filler order number is generated as usual by the filler application. The placer order number is identical to the placer order number of the first transmitted ORC with an order control value of RU.

In the case of the RP type (i.e., a replacement request from another application to the filler), the placer order number is generated by the placer application using the procedure for new orders. The filler order number is generated by the filler application using the procedure identical for new orders.

If a replacement sequence is used in an ORU message (i.e., during results reporting), the following are the recommended segments to be used for the replacement orders:

  1. ORC with an order control value of RO

  2. Any OBR segments (can be replaced by any order detail segments)

  3. Optionally followed by observation result segments (OBX)

  4. NTE segments can appear after the OBR (or any order detail segment) or after an OBX segment as in a regular ORU message

  1. PA, CH

The parent (PA) and child (CH) order control codes allow the spawning of "child" orders from a "parent" order without changing the parent (original order). One or more ORC segments with an ORC-1-order control value of PA are followed by one or more ORC segments with an ORC-1-order control value of CH. Whether OBR segments must be present is determined by the value of ORC-6-response flag.

For example, suppose that a microbiology culture produced two organisms and corresponding susceptibility reports. Then the sequence of segments would be as follows:

Figure 4-4. Example of two child orders

Segment Order Control Comment
ORC PA 1st parent ORC
ORC CH 1st child ORC
OBR
1st child order



ORC CH 2nd child ORC
OBR
2nd child order

The assignment of placer order numbers in the parent-child paradigm depends on whether the placer or filler creates the child order and in the latter case, on whether the placer supports the SN/NA transaction. If the placer creates the child orders it will assign their placer order numbers according to its usual procedures. If the filler creates the child orders there are two possibilities: each child will inherit the placer order number of its parent, or the filler will use the SN/NA transaction to request that the placer assign a placer order number. In either case, the filler application creates the filler order numbers of the children according to its usual procedures.

Whenever a child order is transmitted in a message the ORC segment's ORC-8-parent is valued with the parent's filler order number (if originating from the filler) and with the parent's placer order number (if originating from the filler or if originating from the placer).

The parent-child mechanism can be used to "expand" a parent order (e.g., an order for three EKGs on successive mornings).

  1. RE

The observations-to-follow code is used to transmit patient-specific information with an order. An order detail segment (e.g., OBR) can be followed by one or more observation segments (OBX). Any observation that can be transmitted in an ORU message can be transmitted with this mechanism. When results are transmitted with an order, the results should immediately follow the order or orders that they support.

The following example shows the sequence of segments for three Pharmacy orders. It illustrates the use of the RE code:

Figure 4-5. RE usage (example)

Segment Order Control Comment
MSH

PID

ORC NW First new order
RXO
First order segment



ORC NW 2nd new order
RXO
2nd order segment
[ORC RE Patient-specific observation, optional in V 2.2
OBR]
Observation OBR, optional in V 2.2
OBX
An observation segment
OBX
Another observation segment
OBX
Another observation segment
OBX
Another observation segment



ORC NW 3rd order
RXO
3rd order segment

In this version of HL7, results can be transmitted with an order as one or more OBX segments without the necessity of including the ORC and OBR segments.

Observations can be transmitted in an ORU message without using an ORC. There are times when it is necessary to transmit information not included in the OBR segments of the ORU message. In this case, it is recommended that the ORC be included in the ORU message.

The order control value of RE is required only in ORM messages to indicate that an order is followed by observation results (OBX). The RE code is not necessary in the ORU message because it is expected that the OBR segments can be followed by observation results (OBX).

  1. RR

Left in for backward compatibility. In the current version it is equivalent to an accept acknowledgment. The request-received code indicates that an order message has been received and will be processed later. The order has not yet undergone the processing that would permit a more exact response.

  1. SN, NA, NW

There are three circumstances that involve requesting an order number (ORC-2-placer order number or ORC-3-filler order number):

  1. When the filler application needs to request an ORC-3-filler order number from a centralized application (e.g., HIS)

  2. When the filler application needs to request an ORC-2-placer order number from some other application (e.g., Order Entry)

  3. When an application (not the filler application) wants to assign an ORC-3-filler order number for a new order

1) The filler application needs a centralized filler order number

SN - The send order number code provides a mechanism for the filler to request an ORC-3-filler order number from some centralized application (called "other" in the table below), such as a central HIS, by sending an ORM message containing an ORC-1-order control value of SN. This ORC has a null ORC-3-filler order number and an ORC-2-placer order number created by the filler application when the filler originates the order.

The ORM (SN type) message can be acknowledged by two methods:

By an ORR message containing an ORC-1-order control value of OK. An unsolicited ORM message can be sent at a future time, containing an ORC with ORC-1-order control value of NA.

By an ORR message containing an ORC-1-order control value of NA as described below.

NA - The number assigned code allows the "other" application to notify the filler application of the newly-assigned filler order number. ORC-1-order control contains value of NA, ORC-2-placer order number (from the ORC with the SN value), and the newly-assigned filler order number.

Note: Both the placer order number and the filler order number have the filler's application ID.

Code From ORC-2-Placer Order Number ORC-3-Filler Order Number
SN filler application placer order number^filler application ID null
NA other application placer order number^filler application ID filler order number^filler application ID

2) The filler application needs a placer order number

SN - The send order number code provides a mechanism for the filler application to request an ORC-2-placer order number from another application (called "other" in the table below) by sending an ORM message containing an ORC-1-order control value of SN. This ORC has a null ORC-2-placer order number and an ORC-3-filler order number created by the filler application when the filler originates the order.

The ORM (SN type) message can be acknowledged by two methods:

By an ORR message containing an ORC-1-order control value of OK. An unsolicited ORM message can be sent at a future time, containing an ORC-1-order control value of NA.

By an ORR message containing an ORC-1-order control value of NA as described below.

NA - The number assigned code allows the "other" application to notify the filler application of the newly-assigned ORC-2-placer order number. The ORC contains an ORC-1-order control value of NA, the newly-assigned ORC-2-placer order number, and the ORC-3-filler order number (from the ORC with the SN value).

Note: The new ORC-2-placer order number has the placer's application ID.

Code From ORC-2-Placer Order Number ORC-3-Filler Order Number
SN filler application null filler order number^filler application ID
NA other application Placer order number^placer application ID filler order number^filler application ID

3) An application wants to assign a filler order number

NW - When the application creating an order (not the filler application) wants to assign a filler order number for a new order

or

RO - (RO following an RP). In this case, the "other" application completes ORC-3-filler order number, using the filler application ID as the second component of the filler order number.

Code From ORC-2-Placer Order Number ORC-3-Filler Order Number
NW or RO other application to the filler placer order number^placer application ID filler order number^filler application ID

  1. CN

The combined result code provides a mechanism to transmit results that are associated with two or more orders. This situation occurs commonly in radiology reports when the radiologist dictates a single report for two or more exams represented as two or more orders. For example, knee and hand films for a rheumatoid arthritis patient might generate a single dictation on the part of the radiologist.

When such results are reported the CN code replaces the RE code in all but the last ORC, and the results follow the last ORC and its OBR. An example follows of a single report following three ORCs:

MSH|...<cr>

PID|...<cr>

ORC|CN|...<cr>

OBR|1|A4461XA^HIS|81641^RAD|73666^Bilateral Feet|...<cr>

ORC|CN|...<cr>

OBR|2|A4461XB^HIS|81642^RAD|73642^Bilateral Hand PA|...<cr>

ORC|RE|...<cr>

OBR|3|A4461XC^HIS|81643^RAD|73916^Bilateral Knees|...<cr>

OBX|1|CE|73916&IMP|1|Radiologist's Impression|...<cr>

OBX|2|CE|73642&IMP|1|Radiologist's Impression|...<cr>

OBX|3|FT|73642&GDT|1|Description|...<cr>

  1. UA

An unable-to-accept code is used when a new order cannot be accepted by the filler. Possible reasons include requesting a prescription for a drug which the patient is allergic to or for an order which requires certain equipment resources which are not available such that the order cannot be filled. Note that this is different from the communication level acceptance as defined within the MSA segment.

  1. RF

RF accommodates requests by both the filler or the placer. The filler may be requesting refill authorization from the placer. A placer system may be requesting a refill to be done by the filler system.

  1. AF

AF is a response back from the placer authorizing a refill or quantity of refills.

  1. DF

DF indicates that the placer will not authorize refills for the order. The order control code reason may be used to indicate the reason for the request denial. Some suggested values include:

AA Patient unknown to the provider
AB Patient never under provider care
AC Patient no longer under provider care
AD Patient has requested refill too soon
AE Medication never prescribed for the patient
AF Patient should contact provider first
AG Refill not appropriate

Note that these values originate from the NCPDP SCRIPT Response Segment Code List Qualifiers.

  1. FU

FU notifies the placer that the filler issued a refill for the order at the patient's request.

  1. OF

OF directly responds to the placer system's request for a refill

  1. UF

UF indicates an application level denial by the filler system to an authorized refill request.

  1. LI, UN

Use only with Patient Care problems or goals, Chapter 12.

  1. PR

PR indicates that this ORC is part of an ORU structure containing previous observation, which is embedded in the order.

At least two main use cases require that the complete results of the previous observations be transmitted with the order.

  1. OP, PY

These order control codes are used to communicate an order between systems where the order is intended for informational purposes. For example, an order that will be performed by a vendor outside the enterprise of communicating systems. The communicating systems may need to maintain information relative to the order for clinical continuity, but no actions to perform the ordered service are intended.

OP represents an informational version of NW, PY represents the informational-only version of RO. NW and RO table notes also apply to OP and PY, respectively.

4.5.1.2 ORC-2 Placer Order Number (EI) 00216

Components: <Entity Identifier (ST)> ^ <Namespace ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID Type (ID)>

Definition: This field is the placer application's order number.

This field is a case of the Entity Identifier data type (See Section 2.A.28, "EI - Entity Identifier"). The first component is a string that identifies an individual order (e.g., OBR). A limit of fifteen (15) characters is suggested but not required. An implementation is HL7 compliant when the number of characters for this field is increased to accommodate applications that require a greater number of characters for the Placer order number. It is assigned by the placer (ordering application). It identifies an order uniquely among all orders from a particular ordering application. The second through fourth components contain the application ID of the placing application in the same form as the HD data type (Section 2.A.36, "HD - Hierarchic designator"). The second component, namespace ID, is a user-defined coded value that will be uniquely associated with an application. A limit of six (6) characters is suggested but not required. A given institution or group of intercommunicating institutions should establish a unique list of applications that may be potential placers and fillers and assign unique application IDs. The components are separated by component delimiters.

There are three situations in which the true placer is somewhat arbitrary (and thus not unique):

  1. in ORC-1-order control value of RO, following an RU replacement;

  2. in ORC-1-order control value of CH (child orders); and

  3. in ORC-1-order control value of SN (send number).

See the Table Notes under ORC-1-order control for the details of how the ORC-2-placer order number is assigned in these cases.

The application ID list becomes one of the institution's master dictionary lists that is documented in Chapter 8. Since third-party applications (those other than the placer and filler of an order) can send and receive ORM and ORR messages, the placer application ID in this field may not be the same as any sending and receiving application on the network (as identified in the MSH segment).

ORC-2-placer order number is the same as OBR-2-placer order number. If the placer order number is not present in the ORC, it must be present in the associated OBR and vice versa. If both fields, ORC-2-placer order number and OBR-2-placer order number are valued, they must contain the same value. When results are transmitted in an ORU message, an ORC is not required, and the identifying placer order number must be present in the OBR segments.

These rules apply to the few other fields that are present in both ORC and OBR for upward compatibility (e.g., quantity/timing, parent numbers, ordering provider, and ordering call back numbers).

4.5.1.3 ORC-3 Filler Order Number (EI) 00217

Components: <Entity Identifier (ST)> ^ <Namespace ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID Type (ID)>

Definition: This field is the order number associated with the filling application. It is a case of the Entity Identifier data type (Section 2.A.28). Its first component is a string that identifies an order detail segment (e.g., OBR). A limit of fifteen (15) characters is suggested but not required. An implementation is HL7 compliant when the number of characters for this field is increased to accommodate applications that require a greater number of characters for the Filler order number. It is assigned by the order filler (receiving) application. This string must uniquely identify the order (as specified in the order detail segment) from other orders in a particular filling application (e.g., clinical laboratory). This uniqueness must persist over time.

The second through fourth components contain the filler application ID, in the form of the HD data type (see Section 2.A.36, "HD - hierarchic designator"). The second component is a user-defined coded value that uniquely defines the application from other applications on the network. A limit of six (6) characters is suggested but not required. The second component of the filler order number always identifies the actual filler of an order.

A given institution or group of intercommunicating institutions should establish a list of applications that may be potential placers and fillers of orders and assign each a unique application ID. The application ID list becomes one of the institution's master dictionary lists that is documented in Chapter 8. Since third- party applications (those other than the placer and filler of an order) can send and receive ORM and ORR messages, the filler application ID in this field may not be the same as any sending and receiving application on the network (as identified in the MSH segment).

ORC-3-filler order number is the same as OBR-3-filler order number. If the filler order number is not present in the ORC, it must be present in the associated OBR. (This rule is the same for other identical fields in the ORC and OBR and promotes upward and ASTM compatibility.) This is particularly important when results are transmitted in an ORU message. In this case, the ORC is not required and the identifying filler order number must be present in the OBR segments.

The filler order number (OBR-3 or ORC-3) also uniquely identifies an order and its associated observations. For example, suppose that an institution collects observations from several ancillary applications into a common database and this common database is queried by yet another application for observations. In this case, the filler order number and placer order number transmitted by the common database application would be that of the original filler and placer, respectively, rather than a new one assigned by the common database application.

Similarly, if a third-party application, not the filler or placer, of an order were authorized to modify the status of an order (say, cancel it), the third-party application would send the filler an ORM message containing an ORC segment with ORC-1-order control equal to "CA" and containing the original placer order number and filler order number, rather than assign either itself.

4.5.1.4 ORC-4 Placer Group Number (EI) 00218

Components: <Entity Identifier (ST)> ^ <Namespace ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID Type (ID)>

Definition: This field allows an order placing application to group sets of orders together and subsequently identify them. It is a case of an Entity Identifier data type (2.A.28).

The first component is a string that uniquely identifies all order groups from the given placer application. A limit of fifteen (15) characters is suggested but not required. It is assigned by the placer application and may come from the same series as the placer order number of the ORC, but this is not required.

The second through fourth components constitute a placer application ID identical to the analogous components of ORC-2-placer order number. Order groups and how to use them are described in detail in Section 4.5.1, "ORC - Common Order Segment."

4.5.1.5 ORC-5 Order Status (ID) 00219

Definition: This field specifies the status of an order. Refer to HL7 Table 0038 - Order status for valid entries. The purpose of this field is to report the status of an order either upon request (solicited), or when the status changes (unsolicited). It does not initiate action. It is assumed that the order status always reflects the status as it is known to the sending application at the time that the message is sent. Only the filler can originate the value of this field.

Although HL7 Table 0038 - Order status contains many of the same values contained in HL7 Table 0119 - Order control codes and their meaning, the purpose is different. Order status may typically be used in a message with an ORC-1-order control value of SR or SC to report the status of the order on request or to any interested party at any time.

HL7 Table 0038 - Order status

Value Description Comment
A Some, but not all, results available
CA Order was canceled
CM Order is completed
DC Order was discontinued
ER Error, order not found
HD Order is on hold
IP In process, unspecified
RP Order has been replaced
SC In process, scheduled

4.5.1.6 ORC-6 Response Flag (ID) 00220

Definition: This field allows the placer (sending) application to determine the amount of information to be returned from the filler. Sometimes the requested level of response may not be possible immediately, but when it is possible, the filler (receiving) application must send the information. When the field is null, D is the default value of the field. Refer to HL7 Table 0121 - Response flag for valid entries.

HL7 Table 0121 - Response flag

Value Description Comment
E Report exceptions only
R Same as E, also Replacement and Parent-Child
D Same as R, also other associated segments
F Same as D, plus confirmations explicitly
N Only the MSA segment is returned

4.5.1.7 ORC-7 Quantity/Timing (TQ) 00221

Components: <Quantity (CQ)> ^ <Interval (RI)> ^ <Duration (ST)> ^ <Start Date/Time (TS)> ^ <End Date/Time (TS)> ^ <Priority (ST)> ^ <Condition (ST)> ^ <Text (TX)> ^ <Conjunction (ID)> ^ <Order Sequencing (OSD)> ^ <Occurrence Duration (CE)> ^ <Total Occurrences (NM)>

Subcomponents for Quantity (CQ): <Quantity (NM)> & <Units (CE)>

Note subcomponent contains sub-subcomponents

Subcomponents for Interval (RI): <Repeat Pattern (IS)> & <Explicit Time Interval (ST)>

Subcomponents for Start Date/Time (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for End Date/Time (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Order Sequencing (OSD): <Sequence/Results Flag (ID)> & <Placer Order Number: Entity Identifier (ST)> & <Placer Order Number: Namespace ID (IS)> & <Filler Order Number: Entity Identifier (ST)> & <Filler Order Number: Namespace ID (IS)> & <Sequence Condition Value (ST)> & <Maximum Number of Repeats (NM)> & <Placer Order Number: Universal ID (ST)> & <Placer Order Number: Universal ID Type (ID)> & <Filler Order Number: Universal ID (ST)> & <Filler Order Number: Universal ID Type (ID)>

Subcomponents for Occurrence Duration (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>

Definition: This field is retained for backward compatibility only. The reader is referred to the TQ1 and TQ2 segments described in sections 4.5.4 and 4.5.5 respectively.

This field determines the priority, quantity, frequency, and timing of an atomic service. Order segments should be thought of as describing an atomic service. It is a composite field that is defined in detail in Section 4.3, "Quantity/Timing (TQ) Data Type Definition."

For example, if an OBR segment describes a unit of blood, this field might request that three (3) such units be given on successive mornings. In this case ORC-7-quantity/timing would be "1^QAM^X3". ORC-7-quantity/timing is the same as OBR-27-quantity/timing.

To send information about "collection time", use the 'text' component of the TQ data type in either the ORC-7 or OBR-27.

ORC-7-quantity/timing is the same as OBR-27-quantity/timing. If the ORC-7 and OBR-27 are both valued, then both should be valued exactly the same. If the quantity/timing is not present in the ORC, it must be present in the associated OBR. (This rule is the same for other identical fields in the ORC and OBR and promotes upward and ASTM compatibility.) This is particularly important when results are transmitted in an ORU message. In this case, the ORC is not required and the identifying filler order number must be present in the OBR segments.

4.5.1.8 ORC-8 Parent (EIP) 00222

Components: <Placer Assigned Identifier (EI)> ^ <Filler Assigned Identifier (EI)>

Subcomponents for Placer Assigned Identifier (EI): <Entity Identifier (ST)> & <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Filler Assigned Identifier (EI): <Entity Identifier (ST)> & <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Definition: This field relates a child to its parent when a parent-child relationship exists. The parent-child mechanism is described under ORC-1-order control notes.

The first component has the same format as ORC-2-placer order number (Section 4.5.1.2, "Placer Order Number (EI) 00216)." The second component has the same format as ORC-3-filler order number (Section 4.5.1.3, "Filler Order Number (EI) 00217)_. The components of the placer order number and the filler order number are transmitted in sub-components of the two components of this field.

ORC-8-parent is the same as OBR-29-parent. If the parent is not present in the ORC, it must be present in the associated OBR. (This rule is the same for other identical fields in the ORC and OBR and promotes upward and ASTM compatibility.) This is particularly important when results are transmitted in an ORU message. In this case, the ORC is not required and the identifying filler order number must be present in the OBR segments.

4.5.1.9 ORC-9 Date/Time of Transaction (TS) 00223

Components: <Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>

Definition: This field contains the date and time of the event that initiated the current transaction as reflected in ORC-1 Order Control Code. This field is not equivalent to MSH-7 Date and Time of Message which reflects the date/time of the physical message.

4.5.1.10 ORC-10 Entered By (XCN) 00224

Components: <ID Number (ST)> ^ <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR) (ST)> ^ <DEPRECATED-Degree (e.g., MD) (IS)> ^ <Source Table (IS)> ^ <Assigning Authority (HD)> ^ <Name Type Code (ID)> ^ <Identifier Check Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name Representation Code (ID)> ^ <Name Context (CE)> ^ <DEPRECATED-Name Validity Range (DR)> ^ <Name Assembly Order (ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^ <Professional Suffix (ST)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or Department (CWE)>

Subcomponents for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname (ST)> & <Surname Prefix From Partner/Spouse (ST)> & <Surname From Partner/Spouse (ST)>

Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Name Context (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>

Subcomponents for DEPRECATED-Name Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>

Note subcomponent contains sub-subcomponents

Subcomponents for Effective Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Expiration Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>

Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>

Definition: This field contains the identity of the person who actually keyed the request into the application. Note that this refers to the current transaction as reflected in ORC-1 Order Control Code. It provides an audit trail in case the request is entered incorrectly and the ancillary department needs to clarify the request. By local agreement, either the ID number or name component may be omitted.

4.5.1.11 ORC-11 Verified By (XCN) 00225

Components: <ID Number (ST)> ^ <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR) (ST)> ^ <DEPRECATED-Degree (e.g., MD) (IS)> ^ <Source Table (IS)> ^ <Assigning Authority (HD)> ^ <Name Type Code (ID)> ^ <Identifier Check Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name Representation Code (ID)> ^ <Name Context (CE)> ^ <DEPRECATED-Name Validity Range (DR)> ^ <Name Assembly Order (ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^ <Professional Suffix (ST)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or Department (CWE)>

Subcomponents for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname (ST)> & <Surname Prefix From Partner/Spouse (ST)> & <Surname From Partner/Spouse (ST)>

Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Name Context (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>

Subcomponents for DEPRECATED-Name Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>

Note subcomponent contains sub-subcomponents

Subcomponents for Effective Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Expiration Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>

Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>

Definition: This field contains the identity of the person who verified the accuracy of the entered request. Note that this refers to the current transaction as reflected in ORC-1 Order Control Code. It is used in cases where the request is entered by a technician and needs to be verified by a higher authority (e.g., a nurse). By local agreement, either the ID number or name component may be omitted.

4.5.1.12 ORC-12 Ordering Provider (XCN) 00226

Components: <ID Number (ST)> ^ <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR) (ST)> ^ <DEPRECATED-Degree (e.g., MD) (IS)> ^ <Source Table (IS)> ^ <Assigning Authority (HD)> ^ <Name Type Code (ID)> ^ <Identifier Check Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name Representation Code (ID)> ^ <Name Context (CE)> ^ <DEPRECATED-Name Validity Range (DR)> ^ <Name Assembly Order (ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^ <Professional Suffix (ST)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or Department (CWE)>

Subcomponents for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname (ST)> & <Surname Prefix From Partner/Spouse (ST)> & <Surname From Partner/Spouse (ST)>

Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Name Context (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>

Subcomponents for DEPRECATED-Name Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>

Note subcomponent contains sub-subcomponents

Subcomponents for Effective Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Expiration Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>

Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>

Definition: This field contains the identity of the person who is responsible for creating the request (i.e., ordering physician).

ORC-12-ordering provider is the same as OBR-16-ordering provider. If the ordering provider is not present in the ORC, it must be present in the associated OBR. (This rule is the same for other identical fields in the ORC and OBR and promotes upward and ASTM compatibility.) This is particularly important when results are transmitted in an ORU message. In this case, the ORC is not required and the identifying filler order number must be present in the OBR segments.

4.5.1.13 ORC-13 Enterer's Location (PL) 00227

Components: <Point of Care (IS)> ^ <Room (IS)> ^ <Bed (IS)> ^ <Facility (HD)> ^ <Location Status (IS)> ^ <Person Location Type (IS)> ^ <Building (IS)> ^ <Floor (IS)> ^ <Location Description (ST)> ^ <Comprehensive Location Identifier (EI)> ^ <Assigning Authority for Location (HD)>

Subcomponents for Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Comprehensive Location Identifier (EI): <Entity Identifier (ST)> & <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Assigning Authority for Location (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Definition: This field specifies the location (e.g., nurse station, ancillary service location, clinic, floor) where the person who entered the request was physically located when the order was entered. Note that this refers to the current transaction as reflected in ORC-1 Order Control Code. Only those subcomponents relevant to enterer's location should be valued (commonly nursing unit; facility; building; floor). The person who entered the request is defined in ORC-10-entered by.

4.5.1.14 ORC-14 Call Back Phone Number (XTN) 00228

Components: <DEPRECATED-Telephone Number (ST)> ^ <Telecommunication Use Code (ID)> ^ <Telecommunication Equipment Type (ID)> ^ <Email Address (ST)> ^ <Country Code (NM)> ^ <Area/City Code (NM)> ^ <Local Number (NM)> ^ <Extension (NM)> ^ <Any Text (ST)> ^ <Extension Prefix (ST)> ^ <Speed Dial Code (ST)> ^ <Unformatted Telephone number (ST)>

Definition: This field contains the telephone number to call for clarification of a request or other information regarding the order. ORC-14-call back phone number is the same as OBR-17-order callback phone number.

4.5.1.15 ORC-15 Order Effective Date/Time (TS) 00229

Components: <Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>

Definition: This field contains the date/time that the changes to the request took effect or are supposed to take effect.

If ORC-9-date/time of transaction is after or equal to ORC-15-order effective date/time, the data values in the ORC and its subordinate segments took effect on the order effective date/time.

If ORC-9-date/time of transaction is before the time specified in ORC-15-order effective date/time, the data values in ORC and its subordinate segments are planned to take effect on the order effective date/time.

If ORC-15-order effective date/time is left blank, its value is assumed to be equal to that specified in ORC-9-date/time of transaction or MSH-7-date/time of message if the transaction date/time is blank.

In the case where the time specified in ORC-15-order effective date/time (for the order control code event in the same ORC segment) is different from the corresponding date/time in ORC-7-quantity/timing, the time specified in ORC-15-order effective date/time takes precedence. Thus if the ORC event is a discontinue request to the filler for a continuing order, and the order-effective date/time is prior to the end date/time of ORC-7-quantity/timing, the order effective date/time should take precedence. If the order identified in the ORC has children, the children which have not started should be canceled; if there is a child in process, it should be discontinued; if a child has progressed beyond the point where it can be discontinued, its status is unaffected.

4.5.1.16 ORC-16 Order Control Code Reason (CE) 00230

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: This field contains the explanation (either in coded or text form) of the reason for the order event described by the order control code (HL7 Table 0119). Whereas an NTE after the order-specific segment (e.g., RXO, ORO, OBR) would provide a comment for that specific segment, the purpose of the order control code reason is only to expand on the reason for the order event.

ORC-16-order control code reason is typically not valued when ORC-1-order control is NW, although it could be. In the case of a canceled order, for example, this field is commonly used to explain the cancellation. A Pharmacy system that canceled a drug order from a physician because of a well documented allergy would likely report the fact of the allergy in this field.

If it canceled the order because of a drug interaction this field might contain at least the names (and codes, if needed) of the interacting substances, the text describing the interaction, and the level of severity of the interaction.

4.5.1.17 ORC-17 Entering Organization (CE) 00231

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: This field identifies the organization that the enterer belonged to at the time he/she enters/maintains the order, such as medical group or department. The person who entered the request is defined in ORC-10 -entered by.

4.5.1.18 ORC-18 Entering Device (CE) 00232

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: This field identifies the physical device (terminal, PC) used to enter the order.

4.5.1.19 ORC-19 Action By (XCN) 00233

Components: <ID Number (ST)> ^ <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR) (ST)> ^ <DEPRECATED-Degree (e.g., MD) (IS)> ^ <Source Table (IS)> ^ <Assigning Authority (HD)> ^ <Name Type Code (ID)> ^ <Identifier Check Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name Representation Code (ID)> ^ <Name Context (CE)> ^ <DEPRECATED-Name Validity Range (DR)> ^ <Name Assembly Order (ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^ <Professional Suffix (ST)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or Department (CWE)>

Subcomponents for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname (ST)> & <Surname Prefix From Partner/Spouse (ST)> & <Surname From Partner/Spouse (ST)>

Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Name Context (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>

Subcomponents for DEPRECATED-Name Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>

Note subcomponent contains sub-subcomponents

Subcomponents for Effective Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Expiration Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>

Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>

Definition: This field contains the identity of the person who initiated the event represented by the corresponding order control code. For example, if the order control code is CA (cancel order request), this field represents the person who requested the order cancellation. This person is typically a care provider but may not always be the same as ORC-12 ordering provider.

4.5.1.20 ORC-20 Advanced Beneficiary Notice Code (CE) 01310

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: This field indicates the status of the patient's or the patient's representative's consent for responsibility to pay for potentially uninsured services. This element is introduced to satisfy CMS Medical Necessity requirements for outpatient services. This element indicates (a) whether the associated diagnosis codes for the service are subject to medical necessity procedures, (b) whether, for this type of service, the patient has been informed that they may be responsible for payment for the service, and (c) whether the patient agrees to be billed for this service. The values for this field are drawn from User-Defined Table 0339 _ Advanced Beneficiary Notice Code.

User-defined Table 0339 _ Advanced Beneficiary Notice Code

Value Description Comment
1 Service is subject to medical necessity procedures
2 Patient has been informed of responsibility, and agrees to pay for service
3 Patient has been informed of responsibility, and asks that the payer be billed
4 Advanced Beneficiary Notice has not been signed

4.5.1.21 ORC-21 Ordering Facility Name (XON) 01311

Components: <Organization Name (ST)> ^ <Organization Name Type Code (IS)> ^ <DEPRECATED-ID Number (NM)> ^ <Check Digit (NM)> ^ <Check Digit Scheme (ID)> ^ <Assigning Authority (HD)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name Representation Code (ID)> ^ <Organization Identifier (ST)>

Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Definition: This field contains the name of the facility placing the order.

4.5.1.22 ORC-22 Ordering Facility Address (XAD) 01312

Components: <Street Address (SAD)> ^ <Other Designation (ST)> ^ <City (ST)> ^ <State or Province (ST)> ^ <Zip or Postal Code (ST)> ^ <Country (ID)> ^ <Address Type (ID)> ^ <Other Geographic Designation (ST)> ^ <County/Parish Code (IS)> ^ <Census Tract (IS)> ^ <Address Representation Code (ID)> ^ <DEPRECATED-Address Validity Range (DR)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)>

Subcomponents for Street Address (SAD): <Street or Mailing Address (ST)> & <Street Name (ST)> & <Dwelling Number (ST)>

Subcomponents for DEPRECATED-Address Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>

Note subcomponent contains sub-subcomponents

Subcomponents for Effective Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Expiration Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Definition: This field contains the address of the facility placing the order.

4.5.1.23 ORC-23 Ordering Facility Phone Number (XTN) 01313

Components: <DEPRECATED-Telephone Number (ST)> ^ <Telecommunication Use Code (ID)> ^ <Telecommunication Equipment Type (ID)> ^ <Email Address (ST)> ^ <Country Code (NM)> ^ <Area/City Code (NM)> ^ <Local Number (NM)> ^ <Extension (NM)> ^ <Any Text (ST)> ^ <Extension Prefix (ST)> ^ <Speed Dial Code (ST)> ^ <Unformatted Telephone number (ST)>

Definition: This field contains the telephone number of the facility placing the order.

4.5.1.24 ORC-24 Ordering Provider Address (XAD) 01314

Components: <Street Address (SAD)> ^ <Other Designation (ST)> ^ <City (ST)> ^ <State or Province (ST)> ^ <Zip or Postal Code (ST)> ^ <Country (ID)> ^ <Address Type (ID)> ^ <Other Geographic Designation (ST)> ^ <County/Parish Code (IS)> ^ <Census Tract (IS)> ^ <Address Representation Code (ID)> ^ <DEPRECATED-Address Validity Range (DR)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)>

Subcomponents for Street Address (SAD): <Street or Mailing Address (ST)> & <Street Name (ST)> & <Dwelling Number (ST)>

Subcomponents for DEPRECATED-Address Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>

Note subcomponent contains sub-subcomponents

Subcomponents for Effective Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Expiration Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Definition: This field contains the address of the care provider requesting the order.

4.5.1.25 ORC-25 Order Status Modifier (CWE) 01473

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

Definition: This field is a modifier or refiner of the ORC-5-Order status field. This field may be used to provide additional levels of specificity or additional information for the defined order status codes. Unlike the Order Status field, which is controlled by an HL7 defined table, this field is a CE data type allowing applications to support an unlimited library of Order Status Modifier codes.

Usage Rule: This field may only be populated if the ORC-5-Order Status field is valued.

Examples: An LIS is processing an order with an order status of IP may send an update using the order status modifier to indicate the progress of the order through the laboratory or to indicate that the order has been sent to an external laboratory. Another example using the non-medical orders would be where a phone has been ordered delivered to a patient's room, but has been disconnected temporarily. The ORC-5-Order status indicates IP and the ORC-25-Order status modifier would indicate a disconnected status. A third example involves pharmacy dispenses. It is sometimes not enough to know the prescription is being dispensed. The ORC-25-Order status modifier would indicate if a label had been printed, the prescription filled, or the prescription sold.

4.5.1.26 ORC-26 Advanced Beneficiary Notice Override Reason (CWE) 01641

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

Definition: This field contains the reason why the patient did not sign an Advanced Beneficiary Notice. The reason may be coded or it may be a free text entry. Refer to HL7 Table 0552 _ Advanced beneficiary notice override reason.

Condition: This field is required if the value of ORC-20 Advanced Beneficiary Notice Code indicates that the notice was not signed. For example, additional qualifying or explanatory information would be justified if ORC-20 was populated with the values "3" or "4" in User-defined Table 0339 _ Advanced Beneficiary Notice Code, or similar values in related external code tables.

HL7 Table 0552 - Advanced beneficiary notice override reason

Value Description Comment



4.5.1.27 ORC-27 Filler's Expected Availability Date/Time (TS) 01642

Components: <Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>

Definition: This field specifies the date/time the filler expects the services to be available. For example when a prescription is ready for pickup or when a supply will be sent or picked up, or for when a laboratory result is expected to be available.

4.5.1.28 ORC _28 Confidentiality Code (CWE) 00615

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

Definition: This field contains information about the level of security and/or sensitivity surrounding the order (e.g., highly sensitive, not sensitive, sensitive, etc.). Refer to HL7 Table 0177 _ Confidentiality Code for allowed values. The specific treatment of data with a particular confidentiality level is subject to site-specific negotiation.

4.5.1.29 ORC _ 29 Order Type (CWE) 01643

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

Definition: This field indicates whether the order is to be executed in an inpatient setting or an outpatient setting. If this field is not valued, the system default is assumed. Refer to HL7 Table 0482 _ Order Type for suggested values.

Examples: Before discharge an order is placed for follow-up physical therapy, or to pick up a prescription at a community pharmacy. The patient is an inpatient according to PV1, but the order is an outpatient order.

HL7 Table 0482 - Order Type

Value Description Comments
I Inpatient Order
O Outpatient Order

4.5.1.30 ORC _ 30 Enterer Authorization Mode (CNE) 01644

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

Definition: This field indicates the form of authorization a recorder had from the responsible practitioner to create or change an order. Refer to HL7 Table 0483 Authorization Mode for suggested values.

HL7 Table 0483 _ Authorization Mode

Value Description Comments
EL Electronic
EM E-mail
FX Fax
IP In Person
MA Mail
PA Paper
PH Phone
RE Reflexive (Automated system)
VC Video-conference
VO Voice

4.5.2 BLG - Billing Segment

The BLG segment is used to provide billing information, on the ordered service, to the filling application.

HL7 Attribute Table _ BLG _ Billing

SEQ LEN DT OPT RP/# TBL# ITEM# ELEMENT NAME DB Ref.
1 40 CCD O
0100 00234 When to Charge DB
2 50 ID O
0122 00235 Charge Type DB
3 100 CX O

00236 Account ID DB
4 60 CWE O
0475 01645 Charge Type Reason DB

4.5.2.0 BLG field definitions

4.5.2.1 BLG-1 When to charge (CCD) 00234

Components: <Invocation Event (ID)> ^ <Date/time (TS)>

Subcomponents for Date/time (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

4.5.2.2 Definition: This field specifies when to charge for the ordered service. BLG-2 Charge type (ID) 00235

Definition: This field identifies someone or something other than the patient to be billed for this service. It is used in conjunction with BLG-3-account ID. Refer to HL7 Table 0122 - Charge Type for valid values.

HL7 Table 0122 - Charge type

Value Description Comment
CH Charge
CO Contract
CR Credit
DP Department
GR Grant
NC No Charge
PC Professional
RS Research

4.5.2.3 BLG-3 Account ID (CX) 00236

Components: <ID Number (ST)> ^ <Check Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Assigning Authority (HD)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Effective Date (DT)> ^ <Expiration Date (DT)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or Department (CWE)>

Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>

Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>

Definition: This field identifies the account to be billed. It is used in conjunction with BLG-2-charge type. Refer to HL7 table 0061 - Check digit scheme in Chapter 2.

4.5.2.4 BLG-4 Charge type reason (CWE) 01645

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

''''

Definition: This field explains the choice of and provides the clinical rationale for the selected charge type identified in BLG-2. Refer to User Defined Table 0475 _ Charge Type Reason for suggested values.

User-defined Table 0475 _ Charge Type Reason

Value Description Comment
01 Allergy
02 Intolerance
03 Treatment Failure
04 Patient Request
05 No Exception

4.5.3 OBR - Observation Request Segment

General (taken from ASTM E1238)

The Observation Request (OBR) segment is used to transmit information specific to an order for a diagnostic study or observation, physical exam, or assessment.

The Observation Request segment defines the attributes of a particular request for diagnostic services (e.g., laboratory, EKG) or clinical observations (e.g., vital signs or physical exam). When a placer requests a given set of observations, always include an order segment. For lab tests, the information in the order segment usually applies to a single specimen. However, there is not a one-to-one relationship between specimen and tests ordered. Different test batteries will usually require their own order segments even when they can be performed on a single specimen. In this case, the specimen information must be duplicated in each of the order segments that employ that specimen. For other diagnostic studies, e.g., chest X-ray, a separate order segment will usually be generated for each diagnostic study.

Though multiple observation batteries can be ordered on a single order segment, the observation filler shall generate a separate order segment for each battery that it processes independently, e.g., electrolyte, CBC, vital signs. When reporting the observations, the filling service shall copy the appropriate order (specimen) information from the original order segment into each of the new order segments so that a separate "order" segment is returned to the placer as a "header" for each separate battery of observations.

In the event that an ordered battery of observations cannot be performed, e.g., because of hemolysis on a blood sample, an order segment will be returned to the placer with OBR-25-result status equal to X (to indicate that the study was not performed). In this case, no observation segments will be transmitted.

When observations are successfully completed, the message returned to the placer will include the order segment (OBR) followed by observation (OBX) segments for each distinct observation generated by the order (see Chapter 7). The number of such observation segments will depend upon the number of individual measurements performed in the process.

OBX segments can be sent by the placer along with an order to provide the filling service with clinical data needed to interpret the results. (See Chapter 7 for OBX details.)

HL7 Attribute Table _ OBR _ Observation Request

SEQ LEN DT OPT RP/# TBL# ITEM # ELEMENT NAME DB Ref.
1 4 SI O

00237 Set ID _ OBR DB
2 22 EI C

00216 Placer Order Number DB
3 22 EI C

00217 Filler Order Number DB
4 250 CE R

00238 Universal Service Identifier DB
5 2 ID B

00239 Priority _ OBR DB
6 26 TS B

00240 Requested Date/Time DB
7 26 TS C

00241 Observation Date/Time # DB
8 26 TS O

00242 Observation End Date/Time # DB
9 20 CQ O

00243 Collection Volume * DB
10 250 XCN O Y
00244 Collector Identifier * DB
11 1 ID O
0065 00245 Specimen Action Code * DB
12 250 CE O

00246 Danger Code DB
13 300 ST O

00247 Relevant Clinical Information DB
14 26 TS B

00248 Specimen Received Date/Time * DB
15 300 SPS B

00249 Specimen Source DB
16 250 XCN O Y
00226 Ordering Provider DB
17 250 XTN O Y/2
00250 Order Callback Phone Number DB
18 60 ST O

00251 Placer Field 1 DB
19 60 ST O

00252 Placer Field 2 DB
20 60 ST O

00253 Filler Field 1 + DB
21 60 ST O

00254 Filler Field 2 + DB
22 26 TS C

00255 Results Rpt/Status Chng - Date/Time + DB
23 40 MOC O

00256 Charge to Practice + DB
24 10 ID O
0074 00257 Diagnostic Serv Sect ID DB
25 1 ID C
0123 00258 Result Status + DB
26 400 PRL O

00259 Parent Result + DB
27 200 TQ B Y
00221 Quantity/Timing DB
28 250 XCN O Y
00260 Result Copies To DB
29 200 EIP O

00261 Parent DB
30 20 ID O
0124 00262 Transportation Mode DB
31 250 CE O Y
00263 Reason for Study DB
32 200 NDL O

00264 Principal Result Interpreter + DB
33 200 NDL O Y
00265 Assistant Result Interpreter + DB
34 200 NDL O Y
00266 Technician + DB
35 200 NDL O Y
00267 Transcriptionist + DB
36 26 TS O

00268 Scheduled Date/Time + DB
37 4 NM O

01028 Number of Sample Containers * DB
38 250 CE O Y
01029 Transport Logistics of Collected Sample * DB
39 250 CE O Y
01030 Collector's Comment * DB
40 250 CE O

01031 Transport Arrangement Responsibility DB
41 30 ID O
0224 01032 Transport Arranged DB
42 1 ID O
0225 01033 Escort Required DB
43 250 CE O Y
01034 Planned Patient Transport Comment DB
44 250 CE O
0088 00393 Procedure Code DB
45 250 CE O Y 0340 01316 Procedure Code Modifier DB
46 250 CE O Y 0411 01474 Placer Supplemental Service Information DB
47 250 CE O Y 0411 01475 Filler Supplemental Service Information DB
48 250 CWE C
0476 01646 Medically Necessary Duplicate Procedure Reason. DB
49 2 IS O
0507 01647 Result Handling DB

4.5.3.0 OBR field definitions

The daggered (+) items in this segment are created by the filler, not the placer. They are valued by the filler as needed when the OBR segment is returned as part of a report.

The starred (*) fields are only relevant when an observation is associated with a specimen. These are completed by the placer when the placer obtains the specimen. They are completed by the filler when the filler obtains the specimen.

OBR-7-observation date/time and OBR-8-observation end date/time (flagged with #) are the physiologically relevant times. In the case of an observation on a specimen, they represent the start and end of the specimen collection. In the case of an observation obtained directly from a subject (e.g., BP, Chest X-ray), they represent the start and end time of the observation.

4.5.3.1 OBR-1 Set ID _ OBR (SI) 00237

Definition: For the first order transmitted, the sequence number shall be 1; for the second order, it shall be 2; and so on.

4.5.3.2 OBR-2 Placer order number (EI) 00216

Components: <Entity Identifier (ST)> ^ <Namespace ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID Type (ID)>

Definition: This field is identical to ORC-2-Placer Order Number.

This field is a special case of the Entity Identifier data type (Section 2.A.28). The first component is a string that identifies an individual order (e.g., OBR). A limit of fifteen (15) characters is suggested but not required. It is assigned by the placer (ordering application). An implementation is HL7 compliant when the number of characters for this field is increased to accommodate applications that require a greater number of characters for the Placer order number. It identifies an order uniquely among all orders from a particular ordering application. The second through fourth components contain the application ID of the placing application in the same form as the HD data type (Section 2.A.36, "HD - Hierarchic designator"). The second component, namespace ID, is a user-defined coded value that will be uniquely associated with an application. A limit of six (6) characters is suggested but not required. A given institution or group of intercommunicating institutions should establish a unique list of applications that may be potential placers and fillers and assign unique application IDs. The components are separated by component delimiters.

See ORC-2-placer order number (Section 4.5.1.2) for information on when this field must be valued.

A given institution or group of intercommunicating institutions should establish a list of applications that may be potential placers and fillers of orders and assign each a unique application ID. The application ID list becomes one of the institution_s master dictionary lists that is documented in Chapter 8. Since third-party applications (those other than the placer and filler of an order) can send and receive ORM and ORR messages, the placer application ID in this field may not be the same as any sending and receiving application on the network (as identified in the MSH segment).

ORC-2-placer order number is the same as OBR-2-placer order number. If the placer order number is not present in the ORC, it must be present in the associated OBR and vice versa. If both fields, ORC-2-placer order number and OBR-2-placer order number, are valued, they must contain the same value. When results are transmitted in an ORU message, an ORC is not required, and the identifying placer order number must be present in the OBR segments.

These rules apply to the few other fields that are present in both ORC and OBR for upward compatibility (e.g., quantity/timing, parent numbers, ordering provider, and ordering call back numbers).

4.5.3.3 OBR-3 Filler Order Number (EI) 00217

Components: <Entity Identifier (ST)> ^ <Namespace ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID Type (ID)>

Definition: This field is the order number associated with the filling application. This is a permanent identifier for an order and its associated observations. It is a special case of the Entity Identifier data type (see Chapter 2, Section 2.A.28, "EI - entity identifier").

The first component is a string that identifies an individual order segment (e.g., OBR). It is assigned by the order filling (receiving) application. It identifies an order uniquely among all orders from a particular filling application (e.g., clinical laboratory). ). This uniqueness must persist over time.

The second through fourth components contain the filler application ID, in the form of the HD data type (see Section 2.A.36, "HD - hierarchic designator"). The second component is a user-defined coded value that uniquely defines the application from other applications on the network. A limit of six (6) characters is suggested but not required. The second component of the filler order number always identifies the actual filler of an order.

See ORC-3-filler order number for information on when this field must be valued.

OBR-3-filler order number is identical to ORC-3-filler order number. If the filler order number is not present in the ORC, it must be present in the associated OBR. (This rule is the same for other identical fields in the ORC and OBR and promotes upward and ASTM compatibility.) This is particularly important when results are transmitted in an ORU message. In this case, the ORC is not required and the identifying filler order number must be present in the OBR segments.

The filler order number (OBR-3 or ORC-3) also uniquely identifies an order and its associated observations. For example, suppose that an institution collects observations from several ancillary applications into a common database and this common database is queried by yet another application for observations. In this case, the filler order number and placer order number transmitted by the common database application would be that of the original filler and placer, respectively, rather than a new one assigned by the common database application.

Similarly, if a third-party application, not the filler or placer, of an order were authorized to modify the status of an order (say, cancel it), the third-party application would send the filler an ORM message containing an ORC segment with ORC-1-order control equal to _CA_ and containing the original placer order number and filler order number, rather than assign either itself.

4.5.3.4 OBR-4 Universal Service Identifier (CE) 00238

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: This field contains the identifier code for the requested observation/test/battery. This can be based on local and/or "universal" codes. We recommend the "universal" procedure identifier. The structure of this CE data type is described in the control section.

4.5.3.5 OBR-5 Priority - OBR (ID) 00239

Definition: This field has been retained for backward compatibility only. It is not used. Previously priority (e.g., STAT, ASAP), but this information is carried as the sixth component of OBR-27-quantity/timing.

4.5.3.6 OBR-6 Requested Date/Time (TS) 00240

Components: <Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>

Definition: This field has been retained for backward compatibility only. It is not used. Previously requested date/time. This information is now carried in the fourth component of the OBR-27-quantity/timing.

4.5.3.7 OBR-7 Observation Date/Time (TS) 00241

Components: <Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>

Definition: This field is the clinically relevant date/time of the observation. In the case of observations taken directly from a subject, it is the actual date and time the observation was obtained. In the case of a specimen-associated study, this field shall represent the date and time the specimen was collected or obtained. (This is a results-only field except when the placer or a third party has already drawn the specimen.) This field is conditionally required. When the OBR is transmitted as part of a report message, the field must be filled in. If it is transmitted as part of a request and a sample has been sent along as part of the request, this field must be filled in because this specimen time is the physiologically relevant date/time of the observation.

4.5.3.8 OBR-8 Observation End Date/Time (TS) 00242

Components: <Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>

Definition: This field contains the end date and time of a study or timed specimen collection. If an observation takes place over a substantial period of time, it will indicate when the observation period ended. For observations made at a point in time, it will be null. This is a results field except when the placer or a party other than the filler has already drawn the specimen.

4.5.3.9 OBR-9 Collection Volume (CQ) 00243

Components: <Quantity (NM)> ^ <Units (CE)>

Subcomponents for Units (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>

Definition: For laboratory tests, the collection volume is the volume of a specimen. The default unit is ML. Specifically, units should be expressed in the ISO Standard unit abbreviations (ISO-2955, 1977). This is a results-only field except when the placer or a party has already drawn the specimen. (See Chapter 7 Section 7.4.2.6 for a full discussion regarding units.)

4.5.3.10 OBR-10 Collector Identifier (XCN) 00244

Components: <ID Number (ST)> ^ <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR) (ST)> ^ <DEPRECATED-Degree (e.g., MD) (IS)> ^ <Source Table (IS)> ^ <Assigning Authority (HD)> ^ <Name Type Code (ID)> ^ <Identifier Check Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name Representation Code (ID)> ^ <Name Context (CE)> ^ <DEPRECATED-Name Validity Range (DR)> ^ <Name Assembly Order (ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^ <Professional Suffix (ST)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or Department (CWE)>

Subcomponents for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname (ST)> & <Surname Prefix From Partner/Spouse (ST)> & <Surname From Partner/Spouse (ST)>

Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Name Context (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>

Subcomponents for DEPRECATED-Name Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>

Note subcomponent contains sub-subcomponents

Subcomponents for Effective Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Expiration Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>

Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>

Definition: When a specimen is required for the study, this field will identify the person, department, or facility that collected the specimen. Either name or ID code, or both, may be present.

4.5.3.11 OBR-11 Specimen Action Code (ID) 00245

Definition: This field identifies the action to be taken with respect to the specimens that accompany or precede this order. The purpose of this field is to further qualify (when appropriate) the general action indicated by the order control code contained in the accompanying ORC segment. For example, when a new order (ORC - "NW") is sent to the lab, this field would be used to tell the lab whether or not to collect the specimen ("L" or "O"). Refer to HL7 Table 0065 - Specimen Action Code for valid values.

HL7 Table 0065 - Specimen Action Code

Value Description Comment
A Add ordered tests to the existing specimen
G Generated order; reflex order
L Lab to obtain specimen from patient
O Specimen obtained by service other than Lab
P Pending specimen; Order sent prior to delivery
R Revised order
S Schedule the tests specified below

4.5.3.12 OBR-12 Danger Code (CE) 00246

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: This field contains the code and/or text indicating any known or suspected patient or specimen hazards, e.g., patient with active tuberculosis or blood from a hepatitis patient. Either code and/or text may be absent. However, the code is always placed in the first component position and any free text in the second component. Thus, free text without a code must be preceded by a component delimiter.

4.5.3.13 OBR-13 Relevant Clinical Information (ST) 00247

Definition: This field contains the additional clinical information about the patient or specimen. This field is used to report the suspected diagnosis and clinical findings on requests for interpreted diagnostic studies. Examples include reporting the amount of inspired carbon dioxide for blood gasses, the point in the menstrual cycle for cervical pap tests, and other conditions that influence test interpretations. For some orders this information may be sent on a more structured form as a series of OBX segments (see Chapter 7) that immediately follow the order segment.

4.5.3.14 OBR-14 Specimen Received Date/Time (TS) 00248

Components: <Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>

Definition: This field has been retained for backward compatibility only. As of version 2.5, in messages where the SPM segment is present, the use of SPM-18 Specimen Received Date/Time is favored over this field

For observations requiring a specimen, the specimen received date/time is the actual login time at the diagnostic service. This field must contain a value when the order is accompanied by a specimen, or when the observation required a specimen and the message is a report.

4.5.3.15 OBR-15 Specimen Source (SPS) 00249

Components: <Specimen Source Name or Code (CWE)> ^ <Additives (CWE)> ^ <Specimen Collection Method (TX)> ^ <Body Site (CWE)> ^ <Site Modifier (CWE)> ^ <Collection Method Modifier Code (CWE)> ^ <Specimen Role (CWE)>

Subcomponents for Specimen Source Name or Code (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>

Subcomponents for Additives (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>

Subcomponents for Body Site (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>

Subcomponents for Site Modifier (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>

Subcomponents for Collection Method Modifier Code (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>

Subcomponents for Specimen Role (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>

Definition: This field has been retained for backward compatibility only. As of version 2.5, in messages where the SPM segment is present, the use of SPM Specimen segment is favored over this field

This field identifies the site where the specimen should be obtained or where the service should be performed.

Veterinary medicine may choose the tables supported for the components of this field as decided by their industry.

The first component contains the specimen source name or code (as a CE data type component). (Even in the case of observations whose name implies the source, a source may be required, e.g., blood culture-heart blood.) Refer to HL7 Table 0070 - Specimen Source Codes for valid entries.

The second component should include free text additives to the specimen such as Heparin, EDTA, or Oxlate, when applicable.

The third is a free text component describing the method of collection when that information is a part of the order. When the method of collection is logically an observation result, it should be included as a result segment.

The fourth component specifies the body site from which the specimen was obtained, and the fifth is the site modifier. For example, the site could be antecubital fossa, and the site modifier "right." The components of the CE fields become subcomponents. Refer to User-Defined Table 0163 - Body Site for valid entries.

The sixth component indicates whether the specimen is frozen as part of the collection method. Suggested values are F (Frozen); R (Refrigerated). If the component is blank, the specimen is assumed to be at room temperature.

Refer to HL7 Table 0070 Specimen Source Codes for valid values

The 7th component indicates the role of the sample. Refer to User-defined Table 0369 _ Specimen Role for suggested values. Each of these values is normally identifiable by the systems and its components and can influence processing and data management related to the specimen.

This is a user-defined table with following recommended values. If the value is blank, it is assumed to be a patient specimen.

User-defined Table 0369 - Specimen Role

Value Description Comment
P Patient (default if blank component value)
Q Control specimen
C Calibrator
B Blind Sample
R Replicate (of patient sample as a control)

4.5.3.16 OBR-16 Ordering Provider (XCN) 00226

Components: <ID Number (ST)> ^ <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR) (ST)> ^ <DEPRECATED-Degree (e.g., MD) (IS)> ^ <Source Table (IS)> ^ <Assigning Authority (HD)> ^ <Name Type Code (ID)> ^ <Identifier Check Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name Representation Code (ID)> ^ <Name Context (CE)> ^ <DEPRECATED-Name Validity Range (DR)> ^ <Name Assembly Order (ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^ <Professional Suffix (ST)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or Department (CWE)>

Subcomponents for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname (ST)> & <Surname Prefix From Partner/Spouse (ST)> & <Surname From Partner/Spouse (ST)>

Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Name Context (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>

Subcomponents for DEPRECATED-Name Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>

Note subcomponent contains sub-subcomponents

Subcomponents for Effective Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Expiration Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>

Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>

Definition: This field identifies the provider who ordered the test. Either the ID code or the name, or both, may be present. This is the same as ORC-12-ordering provider.

4.5.3.17 OBR-17 Order Callback Phone Number (XTN) 00250

Components: <DEPRECATED-Telephone Number (ST)> ^ <Telecommunication Use Code (ID)> ^ <Telecommunication Equipment Type (ID)> ^ <Email Address (ST)> ^ <Country Code (NM)> ^ <Area/City Code (NM)> ^ <Local Number (NM)> ^ <Extension (NM)> ^ <Any Text (ST)> ^ <Extension Prefix (ST)> ^ <Speed Dial Code (ST)> ^ <Unformatted Telephone number (ST)>

Definition: This field contains the telephone number for reporting a status or a result using the standard format with extension and/or beeper number when applicable.

4.5.3.18 OBR-18 Placer Field 1 (ST) 00251

Definition: This field is user field #1. Text sent by the placer will be returned with the results.

4.5.3.19 OBR-19 Placer Field 2 (ST) 00252

Definition: This field is similar to placer field #1.

4.5.3.20 OBR-20 Filler Field 1 (ST) 00253

Definition: This field is definable for any use by the filler (diagnostic service).

4.5.3.21 OBR-21 Filler Field 2 (ST) 00254

Definition: This field is similar to filler field #1.

4.5.3.22 OBR-22 Results Rpt/Status Chng - Date/Time (TS) 00255

Components: <Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>

Definition: This field specifies the date/time when the results were reported or status changed. This field is used to indicate the date and time that the results are composed into a report and released, or that a status, as defined in ORC-5 order status, is entered or changed. (This is a results field only.) When other applications (such as office or clinical database applications) query the laboratory application for untransmitted results, the information in this field may be used to control processing on the communications link. Usually, the ordering service would want only those results for which the reporting date/time is greater than the date/time the inquiring application last received results.

4.5.3.23 OBR-23 Charge to Practice (MOC) 00256

Components: <Monetary Amount (MO)> ^ <Charge Code (CE)>

Subcomponents for Monetary Amount (MO): <Quantity (NM)> & <Denomination (ID)>

Subcomponents for Charge Code (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>

Definition: This field is the charge to the ordering entity for the studies performed when applicable. The first component is a dollar amount when known by the filler. The second is a charge code when known by the filler (results only).

4.5.3.24 OBR-24 Diagnostic Serv Sect ID (ID) 00257

Definition: This field is the section of the diagnostic service where the observation was performed. If the study was performed by an outside service, the identification of that service should be recorded here. Refer to HL7 Table 0074 - Diagnostic Service Section ID for valid entries.

HL7 Table 0074 - Diagnostic Service Section ID

Value Description Comment
AU Audiology
BG Blood Gases
BLB Blood Bank
CUS Cardiac Ultrasound
CTH Cardiac Catheterization
CT CAT Scan
CH Chemistry
CP Cytopathology
EC Electrocardiac (e.g., EKG, EEC, Holter)
EN Electroneuro (EEG, EMG,EP,PSG)
HM Hematology
ICU Bedside ICU Monitoring
IMM Immunology
LAB Laboratory
MB Microbiology
MCB Mycobacteriology
MYC Mycology
NMS Nuclear Medicine Scan
NMR Nuclear Magnetic Resonance
NRS Nursing Service Measures
OUS OB Ultrasound
OT Occupational Therapy
OTH Other
OSL Outside Lab
PHR Pharmacy
PT Physical Therapy
PHY Physician (Hx. Dx, admission note, etc.)
PF Pulmonary Function
RAD Radiology
RX Radiograph
RUS Radiology Ultrasound
RC Respiratory Care (therapy)
RT Radiation Therapy
SR Serology
SP Surgical Pathology
TX Toxicology
VUS Vascular Ultrasound
VR Virology
XRC Cineradiograph

4.5.3.25 OBR-25 Result Status (ID) 00258

Definition: This field contains the status of results for this order. This conditional field is required whenever the OBR is contained in a report message. It is not required as part of an initial order.

There are two methods of sending status information. If the status is that of the entire order, use ORC-15-order effective date/time and ORC-5-order status. If the status pertains to the order detail segment, use OBR-25-result status and OBR-22-results rpt/status chng - date/time. If both are present, the OBR values override the ORC values.

This field would typically be used in a response to an order status query where the level of detail requested does not include the OBX segments. When the individual status of each result is necessary, OBX-11-observ result status may be used. Refer to HL7 Table 0123 - Result Status for valid entries.

HL7 Table 0123 - Result Status

Value Description Comment
O Order received; specimen not yet received
I No results available; specimen received, procedure incomplete
S No results available; procedure scheduled, but not done
A Some, but not all, results available
P Preliminary: A verified early result is available, final results not yet obtained
C Correction to results
R Results stored; not yet verified
F Final results; results stored and verified. Can only be changed with a corrected result.
X No results available; Order canceled.
Y No order on record for this test. (Used only on queries)
Z No record of this patient. (Used only on queries)

4.5.3.26 OBR-26 Parent Result (PRL) 00259

Components: <Parent Observation Identifier (CE)> ^ <Parent Observation Sub-identifier (ST)> ^ <Parent Observation Value Descriptor (TX)>

Subcomponents for Parent Observation Identifier (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>

Definition: This field is defined to make it available for other types of linkages (e.g., toxicology). This important information, together with the information in OBR-29-parent, uniquely identifies the parent result's OBX segment related to this order. The value of this OBX segment in the parent result is the organism or chemical species about which this battery reports. For example, if the current battery is an antimicrobial susceptibility, the parent results identified OBX contains a result which identifies the organism on which the susceptibility was run. This indirect linkage is preferred because the name of the organism in the parent result may undergo several preliminary values prior to finalization.

The third component may be used to record the name of the microorganism identified by the parent result directly. The organism in this case should be identified exactly as it is in the parent culture.

We emphasize that this field does not take the entire result field from the parent. It is meant only for the text name of the organism or chemical subspecies identified. This field is included only to provide a method for linking back to the parent result for those systems that could not generate unambiguous Observation IDs and sub-IDs.

This field is present only when the parent result is identified by OBR-29-parent and the parent spawns child orders for each of many results. (See Chapter 7 for more details about this linkage.)

A second mode of conveying this information is to use a standard observation result segment (OBX). If more than one organism is present, OBX-4-observation sub-ID is used to distinguish them. In this case, the first OBX with subID N will contain a value identifying the Nth microorganism, and each additional OBX with subID N will contain susceptibility values for a given antimicrobial test on this organism.

4.5.3.27 OBR-27 Quantity/timing (TQ) 00221

Components: <Quantity (CQ)> ^ <Interval (RI)> ^ <Duration (ST)> ^ <Start Date/Time (TS)> ^ <End Date/Time (TS)> ^ <Priority (ST)> ^ <Condition (ST)> ^ <Text (TX)> ^ <Conjunction (ID)> ^ <Order Sequencing (OSD)> ^ <Occurrence Duration (CE)> ^ <Total Occurrences (NM)>

Subcomponents for Quantity (CQ): <Quantity (NM)> & <Units (CE)>

Note subcomponent contains sub-subcomponents

Subcomponents for Interval (RI): <Repeat Pattern (IS)> & <Explicit Time Interval (ST)>

Subcomponents for Start Date/Time (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for End Date/Time (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Order Sequencing (OSD): <Sequence/Results Flag (ID)> & <Placer Order Number: Entity Identifier (ST)> & <Placer Order Number: Namespace ID (IS)> & <Filler Order Number: Entity Identifier (ST)> & <Filler Order Number: Namespace ID (IS)> & <Sequence Condition Value (ST)> & <Maximum Number of Repeats (NM)> & <Placer Order Number: Universal ID (ST)> & <Placer Order Number: Universal ID Type (ID)> & <Filler Order Number: Universal ID (ST)> & <Filler Order Number: Universal ID Type (ID)>

Subcomponents for Occurrence Duration (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>

Definition: This field is retained for backward compatibility only. The reader is referred to the TQ1 and TQ2 segments described in sections 4.5.4 and 4.5.5 respectively.

This field contains information about how many services to perform at one service time and how often the service times are repeated, and to fix duration of the request

4.5.3.28 OBR-28 Result Copies To (XCN) 00260

Components: <ID Number (ST)> ^ <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR) (ST)> ^ <DEPRECATED-Degree (e.g., MD) (IS)> ^ <Source Table (IS)> ^ <Assigning Authority (HD)> ^ <Name Type Code (ID)> ^ <Identifier Check Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name Representation Code (ID)> ^ <Name Context (CE)> ^ <DEPRECATED-Name Validity Range (DR)> ^ <Name Assembly Order (ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^ <Professional Suffix (ST)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or Department (CWE)>

Subcomponents for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname (ST)> & <Surname Prefix From Partner/Spouse (ST)> & <Surname From Partner/Spouse (ST)>

Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Name Context (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>

Subcomponents for DEPRECATED-Name Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>

Note subcomponent contains sub-subcomponents

Subcomponents for Effective Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Expiration Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>

Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>

Definition: This field identifies the people who are to receive copies of the results. By local convention, either the ID number or the name may be absent.

4.5.3.29 OBR-29 Parent (EIP) 00261

Components: <Placer Assigned Identifier (EI)> ^ <Filler Assigned Identifier (EI)>

Subcomponents for Placer Assigned Identifier (EI): <Entity Identifier (ST)> & <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Filler Assigned Identifier (EI): <Entity Identifier (ST)> & <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Definition: This field is identical to ORC-8-parent. This field relates a child to its parent when a parent-child relationship exists. For example, observations that are spawned by previous observations, e.g., antimicrobial susceptibilities spawned by blood cultures, need to record the parent (blood culture) filler order number here. The parent-child mechanism is described under the order control field notes (see Section 4.5.1.1.1, "Table notes for order control codes of ORC"). It is required when the order is a child.

4.5.3.30 OBR-30 Transportation Mode (ID) 00262

Definition: This field identifies how (or whether) to transport a patient, when applicable. Refer to HL7 Table 0124 - Transportation Mode for valid codes.

HL7 Table 0124 - Transportation Mode

Value Description Comment
CART Cart - patient travels on cart or gurney
PORT The examining device goes to patient's location
WALK Patient walks to diagnostic service
WHLC Wheelchair

4.5.3.31 OBR-31 Reason for Study (CE) 00263

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: This field is the code or text using the conventions for coded fields given in the Control chapter (Chapter 2). This is required for some studies to obtain proper reimbursement.

4.5.3.32 OBR-32 Principal Result Interpreter (NDL) 00264

Components: <Name (CNN)> ^ <Start Date/time (TS)> ^ <End Date/time (TS)> ^ <Point of Care (IS)> ^ <Room (IS)> ^ <Bed (IS)> ^ <Facility (HD)> ^ <Location Status (IS)> ^ <Patient Location Type (IS)> ^ <Building (IS)> ^ <Floor (IS)>

Subcomponents for Name (CNN): <ID Number (ST)> & <Family Name (ST)> & <Given Name (ST)> & <Second and 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 - Namespace ID (IS)> & <Assigning Authority - Universal ID (ST)> & <Assigning Authority - Universal ID Type (ID)>

Subcomponents for Start Date/time (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for End Date/time (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Definition: This field identifies the physician or other clinician who interpreted the observation and is responsible for the report content.

4.5.3.33 OBR-33 Assistant Result Interpreter (NDL) 00265

Components: <Name (CNN)> ^ <Start Date/time (TS)> ^ <End Date/time (TS)> ^ <Point of Care (IS)> ^ <Room (IS)> ^ <Bed (IS)> ^ <Facility (HD)> ^ <Location Status (IS)> ^ <Patient Location Type (IS)> ^ <Building (IS)> ^ <Floor (IS)>

Subcomponents for Name (CNN): <ID Number (ST)> & <Family Name (ST)> & <Given Name (ST)> & <Second and 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 - Namespace ID (IS)> & <Assigning Authority - Universal ID (ST)> & <Assigning Authority - Universal ID Type (ID)>

Subcomponents for Start Date/time (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for End Date/time (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Definition: This field identifies the clinical observer who assisted with the interpretation of this study.

4.5.3.34 OBR-34 Technician (NDL) 00266

Components: <Name (CNN)> ^ <Start Date/time (TS)> ^ <End Date/time (TS)> ^ <Point of Care (IS)> ^ <Room (IS)> ^ <Bed (IS)> ^ <Facility (HD)> ^ <Location Status (IS)> ^ <Patient Location Type (IS)> ^ <Building (IS)> ^ <Floor (IS)>

Subcomponents for Name (CNN): <ID Number (ST)> & <Family Name (ST)> & <Given Name (ST)> & <Second and 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 - Namespace ID (IS)> & <Assigning Authority - Universal ID (ST)> & <Assigning Authority - Universal ID Type (ID)>

Subcomponents for Start Date/time (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for End Date/time (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Definition: This field identifies the performing technician.

4.5.3.35 OBR-35 Transcriptionist (NDL) 00267

Components: <Name (CNN)> ^ <Start Date/time (TS)> ^ <End Date/time (TS)> ^ <Point of Care (IS)> ^ <Room (IS)> ^ <Bed (IS)> ^ <Facility (HD)> ^ <Location Status (IS)> ^ <Patient Location Type (IS)> ^ <Building (IS)> ^ <Floor (IS)>

Subcomponents for Name (CNN): <ID Number (ST)> & <Family Name (ST)> & <Given Name (ST)> & <Second and 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 - Namespace ID (IS)> & <Assigning Authority - Universal ID (ST)> & <Assigning Authority - Universal ID Type (ID)>

Subcomponents for Start Date/time (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for End Date/time (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Definition: This field identifies the report transcriber.

4.5.3.36 OBR-36 Scheduled Date/Time (TS) 00268

Components: <Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>

Definition: This field is the date/time the filler scheduled an observation, when applicable (e.g., action code in OBR-11-specimen action code = "S"). This is a result of a request to schedule a particular test and provides a way to inform the placer of the date/time a study is scheduled (result only).

4.5.3.37 OBR-37 Number of Sample Containers (NM) 01028

Definition: This field identifies the number of containers for a given sample. For sample receipt verification purposes; may be different from the total number of samples which accompany the order.

4.5.3.38 OBR-38 Transport Logistics of Collected Sample (CE) 01029

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: This field is the means by which a sample reaches the diagnostic service provider. This information is to aid the lab in scheduling or interpretation of results. Possible answers: routine transport van, public postal service, etc. If coded, requires a user-defined table.

4.5.3.39 OBR-39 Collector's Comment (CE) 01030

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: This field is for reporting additional comments related to the sample. If coded, requires a user-defined table. If only free text is reported, it is placed in the second component with a null in the first component, e.g., ^difficult clotting after venipuncture and ecchymosis.

4.5.3.40 OBR-40 Transport Arrangement Responsibility (CE) 01031

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: This field is an indicator of who is responsible for arranging transport to the planned diagnostic service. Examples: Requester, Provider, Patient. If coded, requires a user-defined table.

4.5.3.41 OBR-41 Transport Arranged (ID) 01032

Definition: This field is an indicator of whether transport arrangements are known to have been made. Refer to HL7 Table 0224 - Transport Arranged for valid codes.

HL7 Table 0224 - Transport Arranged

Value Description Comment
A Arranged
N Not Arranged
U Unknown

4.5.3.42 OBR-42 Escort Required (ID) 01033

Definition: This field is an indicator that the patient needs to be escorted to the diagnostic service department. Note: The nature of the escort requirements should be stated in OBR-43-planned patient transport comment. See HL7 Table 0225 - Escort Required for valid values.

HL7 Table 0225 - Escort Required

Value Description Comment
R Required
N Not Required
U Unknown

4.5.3.43 OBR-43 Planned Patient Transport Comment (CE) 01034

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: This field is the code or free text comments on special requirements for the transport of the patient to the diagnostic service department. If coded, requires a user-defined table.

4.5.3.44 OBR-44 Procedure Code (CE) 00393

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: This field contains a unique identifier assigned to the procedure, if any, associated with the charge. Refer to User-defined table 0088 - Procedure code for suggested values. This field is a CE data type for compatibility with clinical and ancillary systems.

4.5.3.45 OBR-45 Procedure Code Modifier (CE) 01316

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

Definition: This field contains the procedure code modifier to the procedure code reported in OBR-44-procedure code, when applicable. Procedure code modifiers are defined by regulatory agencies such as CMS and the AMA. Multiple modifiers may be reported. The modifiers are sequenced in priority according to user entry. In the USA, this is a requirement of the UB and the 1500 claim forms. Multiple modifiers are allowed and the order placed on the form affects reimbursement. Refer to user-defined table 0340 - Procedure code modifier for suggested values.

Usage Rule: This field can only be used if OBR-44-procedure code contains certain procedure codes that require a modifier in order to be billed or performed. For example, in the USA, HCPCS codes that require a modifier to be precise.

User-defined Table 0340 _ Procedure code modifier

Value Description Comment

No suggested values

4.5.3.46 OBR-46 Placer Supplemental Service Information (CE) 01474

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: This field contains supplemental service information sent from the placer system to the filler system for the universal procedure code reported in OBR-4 Universal Service ID. This field will be used to provide ordering information detail that is not available in other, specific fields in the OBR segment. Multiple supplemental service information elements may be reported. Refer to User-defined Table 0411 - Supplemental service information values.

This field can be used to describe details such as whether study is to be done on the right or left, for example where the study is of the arm and the order master file does not distinguish right from left or whether the study is to be done with or without contrast (when the order master file does not make such distinctions).

4.5.3.47 OBR-47 Filler Supplemental Service Information (CE) 01475

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: This field contains supplemental service information sent from the filler system to the placer system for the procedure code reported in OBR-4 Universal Service ID. This field will be used to report ordering information details that is not available in other, specific fields in the OBR segment. Typically it will reflect the same information as was sent to the filler system in OBR-46-Placer supplemental information unless the order was modified in which case the filler system will report what was actually performed using this field. Multiple supplemental service information elements may be reported. Refer to User-Defined Table 0411 - Supplemental Service Information Values.

This field can be used to describe details such as whether study is to be done on the right or left, for example where the study is of the arm and the order master file does not distinguish right from left or whether the study is to be done with or without contrast (when the order master file does not make such distinctions).

User-Defined Table 0411 - Supplemental Service Information Values

Value Description Comment

No suggested values

Individual implementations may use vocabularies such as the SNOMED DICOM Micro-glossary (SDM) or private (local) entries.


4.5.3.48 OBR-48 Medically Necessary Duplicate Procedure Reason (CWE) 01646

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

Definition: This field is used to document why the procedure found in OBR-44 - Procedure Code is a duplicate of one ordered/charged previously for the same patient within the same date of service and has been determined to be medically necessary. The reason may be coded or it may be a free text entry.

This field is intended to provide financial systems information on who to bill for duplicate procedures.

Refer to User-Defined Table 0476 _ Medically Necessary Duplicate Procedure Reason for suggested values. User-defined Table 0476 _ Medically Necessary Duplicate Procedure Reason

Value Description Comment

No suggested values

4.5.3.49 OBR-49 Result Handling (IS) 01647

Definition: Transmits information regarding the handling of the result. For example, an order may specify that the result (e.g., an x-ray film) should be given to the patient for return to the requestor. Refer to User-defined Table 0507 Observation Result Handling for suggested values. If this field is not populated then routine handling is implied.

User-defined Table 0507 _ Observation Result Handling

Value Description Comment
F Film-with-patient
N Notify provider when ready

4.5.4 TQ1 _ Timing/Quantity Segment

The TQ1 segment is used to specify the complex timing of events and actions such as those that occur in order management and scheduling systems. This segment determines the quantity, frequency, priority, and timing of a service. By allowing the segment to repeat, it is possible to have service requests that vary the quantity, frequency and priority of a service request over time.

Use cases showing when TQ1 may need to repeat:

  1. Cardiac enzymes STAT and then q 4 hours

  2. Streptokinase studies, draw 1st Stat and run Stat, then draw q 4 hours and run Stat

  3. Gentamicin 100mg Now and 80mg q12h second dose (First 80mg dose) given exactly 12 hours after the 100mg dose. (Might be 2 service requests)

  4. Activase 15mg bolus Stat then 50mg over 30 minutes, then 35mg over the next 60 minutes. (Might be 2 service requests)

  5. Imodium 4mg (2 caps) po initially, then 2mg (1cap) after each unformed stool to a maximum of 16 mg per day. (Might be 2 service requests)

  6. Zithromax 500mg (2tabs) po on the first day then 250mg (1tab) po qd for 5 days. (Might be 2 service requests)

  7. Zyban (Bupropion) Start 150mg po qam x 3 days, then increase to 150mg po bid for 7 to 12 weeks.

  8. Colchicine 1mg (2 tabs) po now then 1 tablet q1 to 2 hours until pain relief or undesirable side effects (Diarrhea, GI upset) (Might be 2 service requests)

  9. doxycylcine 100mg po bid on the first day then 100mg po qd.

  10. scopolamine, xxx mg, 1 hour before surgery. Relative time = -1^hour, priority = P (preop), or alternately repeat pattern = P1H^Preop, 1 Hour before Surgery^99LocalCode, Relative time would be empty and priority would be P (preop).

HL7 Attribute Table _ TQ1 _ Timing/Quantity

SEQ LEN DT OPT RP/# TBL# ITEM# ELEMENT NAME DB Ref.
1 4 SI O

01627 Set ID - TQ1 DB
2 20 CQ O

01628 Quantity DB
3 540 RPT O Y 0335 01629 Repeat Pattern DB
4 20 TM O Y
01630 Explicit Time DB
5 20 CQ O Y
01631 Relative Time and Units DB
6 20 CQ O

01632 Service Duration DB
7 26 TS O

01633 Start date/time DB
8 26 TS O

01634 End date/time DB
9 250 CWE O Y 0485 01635 Priority DB
10 250 TX O

01636 Condition text DB
11 250 TX O

01637 Text instruction DB
12 10 ID C
0427 01638 Conjunction DB
13 20 CQ O

01639 Occurrence duration DB
14 10 NM O

01640 Total occurrence's DB

4.5.4.0 TQ1 field definitions

4.5.4.1 TQ1-1 Set ID - TQ1 (SI) 01627

Definition: For the first timing specification transmitted, the sequence number shall be 1; for the second timing specification, it shall be 2; and so on.

4.5.4.2 TQ1-2 Quantity (CQ) 01628

Components: <Quantity (NM)> ^ <Units (CE)>

Subcomponents for Units (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>

Definition: This field specifies the numeric quantity of the service that should be provided at each service interval. For example, if two blood cultures are to be obtained every 4 hours, the quantity would be 2 or if three units of blood are to be typed and cross-matched, the quantity would be 3. The default value for this field is 1.

If multiple identical services are to be requested, it is strongly recommended that multiple service requests be placed; giving each service request its own unique placer/filler number.

4.5.4.3 TQ1-3 Repeat Pattern (RPT) 01629

Components: <Repeat Pattern Code (CWE)> ^ <Calendar Alignment (ID)> ^ <Phase Range Begin Value (NM)> ^ <Phase Range End Value (NM)> ^ <Period Quantity (NM)> ^ <Period Units (IS)> ^ <Institution Specified Time (ID)> ^ <Event (ID)> ^ <Event Offset Quantity (NM)> ^ <Event Offset Units (IS)> ^ <General Timing Specification (GTS)>

Subcomponents for Repeat Pattern Code (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>

Definition: The repeating frequency with which the treatment is to be administered. It is similar to the frequency and SIG code tables used in order entry systems.

This field may be repeated to build up more complex repeat patterns. For example, daily at bedtime can be represent as "|QD~HS|".

When the quantity timing specification must change to a different repeat pattern after some period of time, a new TQ1 segment must be used to show the new repeat pattern. Note that the end date of the current TQ1 will show when the current timing specification ends, and the start date of the next TQ1 shows when the new timing specification begins. The Conjunction field, TQ1-12 determines if the next TQ1 segment is to be performed sequentially or in parallel.

4.5.4.4 TQ1-4 Explicit Time (TM) 01630

Definition: This field explicitly lists the actual times referenced by the code in TQ1-3. This field will be used to clarify the TQ1-3 in cases where the actual administration times vary within an institution. If the time of the service request spans more than a single day, this field is only practical if the same times of administration occur for each day of the service request. If the actual start time of the service request (as given by TQ1-7 ) is after the first explicit time, the first administration is taken to be the first explicit time after the start time. In the case where the patient moves to a location having a different set of explicit times, the existing service request may be updated with a new quantity/timing segment showing the changed explicit times.

Usage Note: This field is not valued if a Repeat Pattern is not present.

4.5.4.5 TQ1-5 Relative Time and Units (CQ) 01631

Components: <Quantity (NM)> ^ <Units (CE)>

Subcomponents for Units (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>

Definition: This field is used to define the interval between schedules for service request or bottle records. If this field contains a value, it overrides any value in the explicit time interval field. The units component of the CQ data type is constrained to units of time.

Examples:

TQ1|1|1|Q1H||60^min&&ANS+ - Q1H is defined with an interval between services of 60 minutes

TQ1|1|1|Q6H||6^hr&&ANS+ - Q6H is defined with an interval between services of 6 hours

TQ1|1|1|QD||1^d&&ANS+ - QD is defined with an interval between services of 1 day

4.5.4.6 TQ1-6 Service Duration (CQ) 01632

Components: <Quantity (NM)> ^ <Units (CE)>

Subcomponents for Units (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>

Definition: This field contains the duration for which the service is requested.

The quantity component of this field must be a positive, non-zero number. The unit's portion of this field is constrained to units of time.

Example: Whirlpool twenty minutes three times per day for 3 days. Three days is the service duration.

TQ1|1||TID|||3^d&&ANS+||||||20^min&&ANS+|9<cr>

4.5.4.7 TQ1-7 Start Date/Time (TS) 01633

Components: <Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>

Definition: This field may be specified by the requester, in which case it indicates the earliest date/time at which the services should be started. In many cases, however, the start date/time will be implied or will be defined by other fields in the service request record (e.g., urgency - STAT). In such a case, this field will be empty.

The filling service will often record a value in this field after receipt of the service request, however, and compute an end time on the basis of the start date/time for the filling service's internal use.

4.5.4.8 TQ1-8 End Date/Time (TS) 01634

Components: <Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>

Definition: When filled in by the requester of the service, this field should contain the latest date/time that the service should be performed. If it has not been performed by the specified time, it should not be performed at all. The requester may not always fill in this value, yet the filling service may fill it in on the basis of the instruction it receives and the actual start time.

Regardless of the value of the end date/time, the service should be stopped at the earliest of the date/times specified by either the duration or the end date/time.

4.5.4.9 TQ1-9 Priority (CWE) 01635

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

Definition: This field describes the urgency of the request. If this field is blank, the default is R. Refer to User-Defined Table 0485 _ Extended Priority Codes for suggested values.

User-Defined Table 0485 _ Extended Priority Codes

Value Description Comment
S Stat With highest priority
A ASAP Fill after S orders
R Routine Default
P Preop
C Callback
T Timing critical A request implying that it is critical to come as close as possible to the requested time, e.g., for a trough anti-microbial level.
TS
Timing critical within seconds.
TM
Timing critical within minutes.
TH
Timing critical within hours.
TD
Timing critical within days.
TW
Timing critical within weeks.
TL
Timing critical within months.
PRN As needed

4.5.4.10 TQ1-10 Condition Text (TX) 01636

Definition: This is a free text field that describes the conditions under which the drug is to be given. For example, PRN pain, or to keep blood pressure below 110.

The presence of text in this field should be taken to mean that human review is needed to determine the how and/or when this drug should be given.

For complex codified conditions see the TQ2 segment below.

4.5.4.11 TQ1-11 Text Instruction (TX) 01637

Definition: This field is a full text version of the instruction (optional).

4.5.4.12 TQ1-12 Conjunction (ID) 01638

Definition: This field indicates that a second TQ1 segment is to follow. Refer To HL7 Table 0472 _ TQ Conjunction ID for allowed values.

HL7 Table 0472 - TQ Conjunction ID

Value Description Comment
S Synchronous Do the next specification after this one (unless otherwise constrained by the following fields: TQ1-7-start date/time and TQ1-8-end date/time). An "S" specification implies that the second timing sequence follows the first, e.g., when a service request is written to measure blood pressure Q15 minutes for the 1st hour, then every 2 hours for the next day.
A Asynchronous Do the next specification in parallel with this one (unless otherwise constrained by the following fields: TQ1-7-start date/time and TQ1-8-end date/time). The conjunction of "A" specifies two parallel instructions, as are sometimes used in medication, e.g., prednisone given at 1 tab on Monday, Wednesday, Friday, and at 1/2 tab on Tuesday, Thursday, Saturday, Sunday.
C Actuation Time It will be followed by a completion time for the service. This code allows one to distinguish between the time and priority at which a service should be actuated (e.g., blood should be drawn) and the time and priority at which a service should be completed (e.g., results should be reported).

For continuous or periodic services, the point at which the service is actually stopped is determined by the field TQ1-8 end date/time and TQ1-6 duration, whichever indicates an earlier stopping time. Ordinarily, only one of these fields would be present.

Condition Rule: If the TQ1 segment is repeated in the message, this field must be populated with the appropriate Conjunction code indicating the sequencing of the following TQ1 segment.

4.5.4.13 TQ1-13 Occurrence Duration (CQ) 01639

Components: <Quantity (NM)> ^ <Units (CE)>

Subcomponents for Units (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>

Definition: This field contains the duration for which a single performance of a service is requested. The quantity component of this field must be a positive, non-zero number when populated. The units component is constrained to be units of time.

Example: Whirlpool twenty minutes three times per day for three days. Twenty minutes is the occurrence duration.

TQ1|1||TID|||3^d&&ANS+||||||20^min&&ANS+|9<cr>

4.5.4.14 TQ1-14 Total Occurrences (NM) 01640

Definition: This field contains the total number of occurrences of a service that should result from this service request. If both the end date/time (TQ1-8) and the total occurrences are valued and the occurrences would extend beyond the end date/time, then the end date/time takes precedence. Otherwise the number of occurrences takes precedence.

Example: Whirlpool twenty minutes three times per day for three days. The total occurrences would be 9.

TQ1|1||TID|||3^d&&ANS+||||||20^min&&ANS+|9<cr>

4.5.5 TQ2 _ Timing/Quantity Relationship

The TQ2 segment is used to form a relationship between the service request the TQ1/TQ2 segments are associated with, and other service requests. The TQ2 segment will link the current service request with one or more other service requests.

There are many situations, such as the creation of a service request for a group of intravenous (IV) solutions, where the sequence of the individual intravenous solutions (each a service in itself) needs to be specified, e.g., hyperalimentation with multi-vitamins in every third bottle.

There are other situations where part of the service request's instructions contains a results condition of some type, such as "PRN pain." There is currently a free text "condition" field of TQ1-10 (Condition text) which allows any condition to be specified. However, to support a fully encoded version of service request sequencing, or results condition, the TQ2, Timing/Quantity Relationship segment has been defined.

HL7 Attribute Table _ TQ2 _ Timing/Quantity Relationship

SEQ LEN DT OPT RP/# TBL# ITEM# ELEMENT NAME DB Ref.
1 4 SI O

01648 Set ID - TQ2 DB
2 1 ID O
0503 01649 Sequence/Results Flag DB
3 22 EI C Y
01650 Related Placer Number DB
4 22 EI C Y
01651 Related Filler Number DB
5 22 EI C Y
01652 Related Placer Group Number DB
6 2 ID C
0504 01653 Sequence Condition Code DB
7 1 ID C
0505 01654 Cyclic Entry/Exit Indicator DB
8 20 CQ O

01655 Sequence Condition Time Interval DB
9 10 NM O

01656 Cyclic Group Maximum Number of Repeats DB
10 1 ID C
0506 01657 Special Service Request Relationship DB

TQ2 Usage notes

  1. Cyclic placer service request groups

To implement a cyclic group of four IV service requests using the parent/child paradigm, the parent specifies a custom group of IVs, and the following occurs:

To repeat the group of four child service requests in a cyclic manner, the following occurs:

This scheme allows the following to be tracked:

Separate Service requests example:

  1. Inheritance of service request status

Cancellation/discontinuation/hold service request control events:

4.5.5.0 TQ2 field definitions

4.5.5.1 TQ2-1 Set ID _ TQ2 (SI) 01648

Definition: For the first timing specification transmitted, the sequence number shall be 1; for the second timing specification, it shall be 2; and so on.

4.5.5.2 TQ2-2 Sequence/Results Flag (ID) 01649

Definition: This flag defines the sequencing relationship between the current service request, and the related service request(s) specified in this TQ2 segment. See HL7 Table 0503 _ Sequence/Results Flag for values. If not value is present, the S - Sequential is the default value.

HL7 Defined Table 0503 _ Sequence/Results Flag

Value Description Comment
S Sequential
C Cyclical Used for indicating a repeating cycle of service requests; for example, individual intravenous solutions used in a cyclical sequence (a.k.a. "Alternating IVs"). This value would be compatible with linking separate service requests or with having all cyclical service request components in a single service request. Likewise, the value would be compatible with either Parent-Child messages or a single service request message to communicate the service requests' sequencing
R Reserved for future use

4.5.5.3 TQ2-3 Related Placer Number (EI) 01650

Components: <Entity Identifier (ST)> ^ <Namespace ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID Type (ID)>

Definition: The placer numbers of the service request(s) to which this TQ2 segment links the current service request. This field should be populated with the appropriate "Placer number" from the current service request. For orders, the Placer Order Number from ORC-2 is the appropriate "Placer number". Repeats of this field indicate the current service request is related to multiple service requests.

Conditional Rule: At least one of TQ2-3, TQ2-4, TQ2-5 must contain a value.

4.5.5.4 TQ2-4 Related Filler Number (EI) 01651

Components: <Entity Identifier (ST)> ^ <Namespace ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID Type (ID)>

Definition: The filler numbers of the service request(s) to which this TQ2 segment links the current service request. This field should be populated with the appropriate "Filler number" from the current service request. For orders, the Filler Order Number from ORC-3 is the appropriate "Filler number". Repeats of this field indicate the current service request is related to multiple service requests.

Conditional Rule: At least one of TQ2-3, TQ2-4, TQ2-5 must contain a value.

4.5.5.5 TQ2-5 Related Placer Group Number (EI) 01652

Components: <Entity Identifier (ST)> ^ <Namespace ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID Type (ID)>

Definition: The placer group numbers of the service request(s) to which this TQ2 segment links the current service request. This field should be populated with the appropriate "Placer group number" from the current service request. For orders, the Placer Group Number from ORC-4 is the appropriate "Placer group number". Repeats of this field indicate that the current service request is related to multiple groups of service requests.

Conditional Rule: At least one of TQ2-3, TQ2-4, TQ2-5 must contain a value.

4.5.5.6 TQ2-6 Sequence Condition Code (ID) 01653

Definition: Defines the relationship between the start/end of the related service request(s) (from TQ2-3, TQ2-4, or TQ2-5) and the current service request from ORC-2,3 or 4. See HL7 Table 0504 _ Sequence Condition Code for allowed values.

Conditional Rule: Either this field or TQ2-10 must be present.

HL7 Table 0504 _ Sequence Condition Code

Value Description Comment
EE End related service request(s), end current service request.
ES End related service request(s), start current service request.
SS Start related service request(s), start current service request.
SE Start related service request(s), end current service request.

4.5.5.7 TQ2-7 Cyclic Entry/Exit Indicator (ID) 01654

Definition: Indicates if this service request is the first, last, service request in a cyclic series of service requests. If null or not present, this field indicates that the current service request is neither the first or last service request in a cyclic series of service requests. Refer to HL7 Table 0505 _ Cyclic Entry/Exit Indicator for allowed values.

Conditional Rule: Should not be populated when TQ2-2 (Sequence/Results Flag) is not equal to a 'C' (cyclic service request).

HL7 Table 0505 _ Cyclic Entry/Exit Indicator

Value Description
* The first service request in a cyclic group
# The last service request in a cyclic group.

Example of TQ2 - 6, 7, & 8 Usage:

Example Translation
...|ES|*|+10^min|... translates to: execute this service request the first time without evaluating the condition specified in the TQ2 segment; but repeat only its execution when the specified external service request's start or finish date/time has met this condition. This specification generates a repetition of the service request for each iteration of the cycle.

Note: This requires that the requesting application be able to specify the placer/filler/placer group number of the last service request in the cycle in the first service request's quantity/timing specification.

4.5.5.8 TQ2-8 Sequence Condition Time Interval (CQ) 01655

Components: <Quantity (NM)> ^ <Units (CE)>

Subcomponents for Units (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>

Definition: Defines the interval of time between the start/end of the related service request(s) and the start/end of the current service request. The unit's component is constrained to units of time. If this field is not populated, then there should be no interruption between start/ending the current service request, and the related service request(s).

4.5.5.9 TQ2-9 Cyclic Group Maximum Number of Repeats (NM) 01656

Definition: The maximum number of repeats for a cyclic group.

The total number of repeats is constrained by the end date/time of the last repeat or the end date/time of the parent, whichever is first. For example, if the total number or repeats is valued at 10 and the group has already repeated 5 times, the current order will not be repeated again if either the current order, or the prior order in the cycle, has reached its end date/time.

This field is meaningful only when TQ2-2 Sequence/Results Flag is valued with 'C'. However, even in this case this field is optional.

4.5.5.10 TQ2-10 Special Service Request Relationship (ID) 01657

Definition: This defines an additional or alternate relationship between this service request and other service requests. Its primary intended use is for Pharmacy administration service requests, but it may be useful for other domains. See HL7 Table 0506 _ Service Request Relationship for allowed values.

Conditional Rule: Either this field or TQ2-6 must be present.

HL7 Table 0506 _ Service Request Relationship

Value Description Comment
N Nurse prerogative Where a set of two or more orders exist and the Nurse, or other caregiver, has the prerogative to choose which order will be administered at a particular point in time. For example,

Milk of Magnesia PO 30 ml qhs (at bedtime)

Dulcolax Supp R @ hs prn

Colace 100 mg capsule PO bid

The nurse would be administering MOM, but may add the Colace and may also give the Dulcolax Supp as needed to promote and maintain regularity.

C Compound A compound is an extempo order which may be made up of multiple drugs. For example, many hospitals have a standard item called "Magic Mouthwash". The item is ordered that way by the physician. The extempo items will contain multiple products, such as Maalox, Benadryl, Xylocaine, etc. They will all be mixed together and will be dispensed in a single container.
T Tapering A tapering order is one in which the same drug is used, but it has a declining dosage over a number of days.

For example, Decadron 0.5 mg is often ordered this way. The order would look like this:

Decadron 0.5 mg qid (four times a day) for 2 days, then

Decadron 0.5 mg tid (three times a day) for 2 days, then

Decadron 0.5 mg bid (twice a day) for 2 days, then

Decadron 0.5 mg qd (daily) for 2 days, then stop.

E Exclusive An exclusive order is an order where only one of the multiple items should be administered at any one dosage time. The nurse may chose between the alternatives, but should only give ONE of them. An example would be: Phenergan 25 mg PO, IM or R q6h prn (orally, intramuscularly, or rectally every 6 hours as needed).
S Simultaneous A simultaneous order is 2 or more drugs which are ordered to be given at the same time. A common example of this would be Demerol and Phenergan (Phenergan is given with the Demerol to control the nausea that Demerol can cause). The order could be: Demerol 50 mg IM with Phenergan 25 mg IM q4h prn (every 4 hours as needed).

4.5.6 IPC _ Imaging Procedure Control Segment

The IPC segment contains information about tasks that need to be performed in order to fulfill the request for imaging service. The information includes location, type and instance identification of equipment (acquisition modality) and stages (procedure steps).

Note: References, field names and definitions in this section were developed in collaboration with DICOM with the goal of keeping HL7 transmission of imaging procedure control information consistent with the DICOM Standard available from NEMA (www.nema.org).

HL7 Attribute Table _ IPC _ Imaging Procedure Control Segment

SEQ LEN DT OPT RP/# TBL# ITEM # ELEMENT NAME DB Ref.
1 80 EI R

01330 Accession Identifier DB
2 22 EI R

01658 Requested Procedure ID DB
3 70 EI R

01659 Study Instance UID DB
4 22 EI R

01660 Scheduled Procedure Step ID DB
5 16 CE O

01661 Modality DB
6 250 CE O Y
01662 Protocol Code DB
7 22 EI O

01663 Scheduled Station Name DB
8 250 CE O Y
01664 Scheduled Procedure Step Location DB
9 16 ST O

01665 Scheduled AE Title DB

4.5.6.0 IPC field definitions

4.5.6.1 IPC-1 Accession Identifier (EI) 01330

Components: <Entity Identifier (ST)> ^ <Namespace ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID Type (ID)>

Definition: A workflow-management IDIS generated number that identifies the Filler Order for an Imaging Service (Imaging Service Request). This identifier corresponds one-to-one to the Order Filler number but is used in internal tracking of the work by the IDIS and in communication between IDIS within the department. It also has specific requirements to assure its compatibility with DICOM. It is a case of the Entity Identifier data type (Section 2.A.28). Its first component is a string that identifies the Imaging Service Request. A limit of sixteen (16) characters is required to allow compatibility with DICOM. See DICOM Standard Part 3 for further details on DICOM Attribute (0008,0050) that conveys information identical to the component one of this field.

An IDIS that performs functions of the workflow management for a department may accept a single Placer Order that gives rise to one or more Filler Orders-Imaging Service Requests. For example, an IDIS may receive an order for an X-ray examination of the patient daily at 8 am for the next three days. For the purposes of fulfilling the Placer Order, it will identify each of the daily exams either as a separate Filler Order or parts of a single Filler Order. Correspondingly, it will assign one or more Filler Order numbers associated with the order. For each of the Filler Order numbers, it will assign a unique Accession Number.

Each of the Imaging Service Requests may contain one or more Requested Procedures that it will identify with the Requested Procedure ID. The Requested Procedure is the most granular unit of work that may lead to the creation of the procedure report. Each procedure report contributes to the results for the order. In the example mentioned above, each of the daily examinations will require a separate diagnostic report, hence each of them will be treated as a separate Requested Procedure. Depending on the treatment of the order by the IDIS, it will either link all Requested Procedures to a single Filler Order-Imaging Service Request, or link each Requested Procedure to its own Imaging Service Request. Exact type of requested procedure is conveyed by the coded values in OBR-44 Procedure Code and OBR-45 Procedure Code modifier for each procedure. Note that in case of multiple Requested Procedures corresponding to one order, each procedure may have different code.

To support communication with the instances of equipment in a department (acquisition modalities), IDIS will also generate the Study Instance UID, a globally unique identifier for each Requested Procedure. This identifier will be used by acquisition modalities to identify all generated images and other DICOM objects related to this Requested Procedure. Note that, unlike the Study Instance UID, the Requested Procedure ID must only be unique within the scope of the encompassing Imaging Service Request identified by an Accession Number.

Each of the Requested Procedures may be further broken down by the IDIS into the Scheduled Procedure Steps based on the timing and equipment requirements. Each step is identified with the Scheduled Procedure Step ID. A single Procedure Step may only be performed on a single type and instance of the equipment. Thus, while the Requested Procedure may identify multi-modality examination (such as ones common in Nuclear Medicine), a single Procedure Step shall correspond to the operations performed on a single modality.

The example of the hierarchy of Imaging Service Request, Requested Procedure and Scheduled Procedure Step is depicted in a figure 4-6. Identifiers of the entities are represented by the field names stated in square brackets.

Figure 4-6. Hierarchy of Imaging Service Request, Requested Procedure and Scheduled Procedure Step

The full hierarchy constitutes the context that will be shared between all IDIS within a department in a course of order fulfillment.

Each OMI message shall convey information about Requested Procedure(s) pertaining to one order. A pair of Segments ORC/OBR shall correspond to each requested procedure. If the Requested Procedure is comprised of multiple Procedure Steps, multiple IPC segments shall be included for each ORC/OBR pair in the message. Value of the IPC-1 field shall be identical in all IPC segments.

Considering the preceding example of X-ray examinations on subsequent days with two different steps identified for the last Requested Procedure and examinations to be performed at the site, "RADIOLOGY", the communication of the information using OMI message may look like the following:

MSH|...<cr>

PID|...<cr>

ORC|NW|...<cr>

OBR|1|X1234^HIS|R578^RIS|56782^X-Ray Chest|...|XPA^X-Ray Chest PA|...<cr>

IPC|A345^RIS|P1234^RIS|1.2.840.1234567890.3456786.1^RIS|SPS1^RIS|CR|SXPA^Chest PA||RADIOLOGY|<cr>

ORC|NW|...<cr>

OBR|2|X1234^HIS|R578^RIS|56782^X-Ray Chest|...|XPA^X-Ray Chest PA|...<cr>

IPC|A345^RIS|P1235^RIS|1.2.840.1234567890.3456786.2^RIS|SPS1^RIS|CR|SXPA^Chest PA||RADIOLOGY|<cr>

ORC|NW|...<cr>

OBR|3|X1234^HIS|R578^RIS|56782^X-Ray Chest|...|XPALAT^X-Ray Chest PA and Lateral|...<cr>

IPC|A345^RIS|P1236^RIS|1.2.840.1234567890.3456786.3^RIS|SPS1^RIS|CR|SXPA^Chest PA||RADIOLOGY|<cr>

IPC|A345^RIS|P1236^RIS|1.2.840.1234567890.3456786.3^RIS|SPS2^RIS|CR|SXLAT^Chest Lat||RADIOLOGY|<cr>

4.5.6.2 IPC-2 Requested Procedure ID (EI) 01658

Components: <Entity Identifier (ST)> ^ <Namespace ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID Type (ID)>

Definition: This field is the identifier of the Requested Procedure that the workflow management IDIS selected to perform as a part of the order for the imaging service. It is a case of the Entity Identifier data type (Section 2.A.28). The first component of this field is a string that identifies the Requested Procedure. A limit of sixteen (16) characters is required to allow compatibility with DICOM. This string must uniquely identify the Requested Procedure within the scope of the order (as specified by accession number). This uniqueness must persist over time. See DICOM Standard Part 3 for further details on DICOM Attribute (0040,0001) that conveys information identical to the component one of this field.

The second through fourth components contain the ID of the workflow management IDIS, in the form of the HD data type (see Section 2.A.36, "HD - hierarchic designator"). The second component is a user-defined coded value that uniquely defines the application from other applications on the network. A limit of five (5) characters is suggested but not required. The second component of the Requested Procedure number always identifies the actual filler of an order.

A Requested Procedure is an instance of a Procedure of a given Procedure Type. An instance of a Requested Procedure includes all of the items of information that are specified by an instance of a Procedure Plan that is selected for the Requested Procedure by the imaging service provider. This Procedure Plan is defined by the imaging service provider on the basis of the Procedure Plan templates associated with the considered Procedure Type. An Imaging Service Request may include requests for several different Requested Procedures. The purpose of this entity is to establish the association between Imaging Service Requests and Procedure Types, to convey the information that belongs to this association and to establish the relationships between Requested Procedures and the other entities that are needed to describe them. A single Requested Procedure of one Procedure Type is the smallest unit of service that can be requested, reported, coded and billed. Performance of one instance of a Requested Procedure is specified by exactly one Procedure Plan. A Requested Procedure leads to one or more Scheduled Procedure Steps involving Protocols as specified by a Procedure Plan. A Requested Procedure may involve one or more pieces of equipment.

Each OMI message shall convey information about Requested Procedure(s) pertaining to one order. Pair of Segments ORC/OBR shall correspond to each requested procedure. If the Requested Procedure is comprised of multiple Procedure Steps, multiple IPC segments shall be included for each ORC/OBR pair in the message. In this case, the value of the IPC-2 field shall be identical in all IPC segments related to the same Requested Procedure.

4.5.6.3 IPC-3 Study Instance UID (EI) 01659

Components: <Entity Identifier (ST)> ^ <Namespace ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID Type (ID)>

Definition: Globally unique identifier assigned by the workflow management IDIS to the Imaging Study under which all images and other DICOM objects produced in the course of the Requested Procedure shall be collected. It is a case of the Entity Identifier data type (Section 2.A.28). Its first component is a string that identifies the Study. A limit of sixty-four (64) characters is required to allow compatibility with DICOM. See DICOM Standard Part 3 for further details on DICOM Attribute (0020,000D) that conveys information identical to component one of this field. The second through fourth components contain the ID of the workflow management IDIS, in the form of the HD data type (see Section 2.A.36, "HD - hierarchic designator"). The second component is a user-defined coded value that uniquely defines the application from other applications on the network. A limit of five (5) characters is suggested but not required. The second component of the Study Instance UID always identifies the actual filler of an order.

Each OMI message shall convey information about Requested Procedure(s) pertaining to one order. Pair of Segments ORC/OBR shall correspond to each requested procedure. If the Requested Procedure is comprised of multiple Procedure Steps, multiple IPC segments shall be included for each ORC/OBR pair in the message. In this case, the value of the IPC-3 field shall be identical in all IPC segments related to the same Requested Procedure.

4.5.6.4 IPC-4 Scheduled Procedure Step ID (EI) 01660

Components: <Entity Identifier (ST)> ^ <Namespace ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID Type (ID)>

Definition: This field is the identifier of a particular Procedure Step (sub-procedure) of the Requested Procedure that the workflow management IDIS selected to perform as a part of the order for imaging service. It is a case of the Entity Identifier data type (Section 2.A.28). Its first component is a string that identifies the Procedure Step. A limit of sixteen (16) characters is required to allow compatibility with DICOM. This string must uniquely identify the Procedure Step within the scope of the Requested Procedure. This uniqueness must persist over time. See DICOM Standard Part 3 for further details on DICOM Attribute (0040,0009) that conveys information identical to the component one of this field.

The second through fourth components contain the ID of the workflow management IDIS, in the form of the HD data type (see Section 2.A.36, "HD - hierarchic designator"). The second component is a user-defined coded value that uniquely defines the application from other applications on the network. A limit of five (5) characters is suggested but not required. The second component of the Requested Procedure number always identifies the actual filler of an order.

A Procedure Step is an arbitrarily defined scheduled unit of service, which is specified by the Procedure Plan for a Requested Procedure. A Procedure Step prescribes Protocol that may be identified by one or more protocol codes. A Procedure Step involves equipment (e.g. imaging Modality equipment, anesthesia equipment, surgical equipment, transportation equipment), human resources, consumable supplies, location, and time (e.g. start time, stop time, duration). While in the context of Imaging Service request the scheduling of a Procedure Step might include only a general designation of imaging Modality that could be satisfied by multiple pieces of the same equipment type, the performance of one instance of a Procedure Step involves one and only one piece of imaging Modality equipment.

4.5.6.5 IPC-5 Modality (CE) 01661

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: The type of equipment requested to acquire data during performance of a Procedure Step. The acquired data will be used to create the images for the Imaging Study corresponding to the Requested Procedure.

This field is a case of the CE data type. Refer to DICOM Standard Part 3 for valid values and further details on DICOM Attribute (0008,0060) that conveys information identical to component one of this field.

A limit of sixteen (16) characters for the first component is required to allow compatibility with DICOM. The third component of this field, if present, shall have the value of "DCM" (see HL7 table 0396).

4.5.6.6 IPC-6 Protocol Code (CE) 01662

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: One or more coded entries identifying the protocol according to which the Scheduled Procedure Step shall be performed. Protocol Code(s) may identify particular equipment settings as well as operator's manipulations.

A Protocol is a specification of actions prescribed by a Procedure Plan to perform a specific Procedure Step. A Scheduled Procedure Step contains only one Protocol that may be conveyed by one or more Protocol Codes. Typically, the code or codes identifying Protocol instance would be selected from a catalog of protocols established locally or provided by equipment manufacturers or professional organizations. Multiple Protocols may not exist in one Scheduled Procedure Step. See DICOM Standard Part 3 for further details on DICOM Attribute (0040,0008) that conveys information identical to components one through three of this field.

A limit of sixteen (16) characters for the first component and sixty-four (64) characters for the second component is required to allow compatibility with DICOM.

4.5.6.7 IPC-7 Scheduled Station Name (EI) 01663

Components: <Entity Identifier (ST)> ^ <Namespace ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID Type (ID)>

Definition: This field identifies the instance of the modality resource being requested for the performance of a particular Scheduled Procedure Step. It is a case of the Entity Identifier data type (Section 2.A.28). The first component of this field is a string that identifies the particular piece of equipment. A limit of sixteen (16) characters is required to allow compatibility with DICOM. See DICOM Standard Part 3 for further details on DICOM Attribute (0040,0010) that conveys information identical to the component one of this field.

The second through fourth components identify the organization, in the form of the HD data type (see Section 2.A.36, "HD - hierarchic designator").

If the Scheduled Procedure Step is to be performed by an unspecified member of a pool of resources, this field shall be empty and IPC-8 Scheduled Procedure Step Location is used to identify the site-specific resource pool. See section 4.4.8.8 for explanation of the resource pool.

4.5.6.8 IPC-8 Scheduled Procedure Step Location (CE) 01664

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: This field specifies a locally defined physical location of the modality resource being requested for performance of particular Scheduled Procedure Step. Although location is usually defined geographically (such as identification of a campus, building, floor, etc.) it may be used for identification of a pool of equipment (resources) formed by any other means. Values for the field shall be drawn from a locally defined coding scheme.

For example, the pool may be defined as a set of three CT scanners belonging to an imaging center within a hospital. Two of these scanners may also be grouped into another pool based on their location at a building A, whereas the third scanner may be in a pool by itself due to its location in a building B.

If this field contains more than one location code, the equipment may be drawn from several resource pools.

If this field is empty and the fields IPC-7 and IPC-9 are also empty, it is assumed that a particular Procedure Step may be performed by any instance of equipment of a particular type within an organization.

See DICOM Standard Part 3 for further details on DICOM Attribute (0040,0011) that conveys information identical to component one of this field. A limit of sixteen (16) characters for the first component is required to allow compatibility with DICOM.

4.5.6.9 IPC-9 Scheduled Station AE Title (ST) 01665

Definition: This field contains the Application Entity Title of the modality resource being requested for performance of a particular Scheduled Procedure Step. Application Entity Title is the identifier that identifies an instance of DICOM-compatible equipment for the purpose of addressing during communication. See DICOM Standard, Part 3 for further details on the DICOM Attribute (0040,0001) that conveys equivalent information. A limit of sixteen (16) characters is required to allow compatibility with DICOM.

If the Scheduled Procedure Step is to be performed by an unspecified member of a pool of resources, this field shall be empty and IPC-8 Scheduled Procedure Step Location is used to identify the site-specific resource pool. See section 4.4.8.8 for explanation of the resource pool.

4.6 GENERAL MESSAGE EXAMPLES

The purpose of this section is to show how certain specific situations would be handled using the order entry protocol. The ellipses represent uncompleted details. The symbol // precedes comments for clarification.

4.6.1 An order replaced by three orders

Suppose that an application called "PC" is sending an order to the EKG application for three EKGs to be done on successive days.

The order might be placed as follows:

ORM message:

MSH|...<cr>

PID|...<cr>

ORC|NW|A226677^PC||946281^PC||N|3^QAM||198801121132|P123^AQITANE^ELLINORE^""^""^""^MD|||4EAST|...<cr>

// EKG order

OBR|1|||8601-7^EKG IMPRESSION^LN||||||||||||P030^SMITH^MARTIN^""^""^""^MD|||||||||||3^QAM|...<cr>

BLG|...<cr>

ORC|NW|...<cr>

// Another order yet others may follow

There is a group number first component indicating that an order group is being created.

Responses: Because the EKG application must turn the single order above into three orders for three separate EKGs (services), the results of each will be reported under its own OBR segment. Several response levels are possible depending on the Response Flag:

  1. If the Response Flag is N (as it is), then the filler EKG application only responds "I got the order."

MSH|...<cr>

MSA|...<cr>

The only implication of this response is that the order was received.

If the Response Flag had been E, then the response would have been the same, but its implication would have been that the EKG application had processed all the orders and they were acceptable.

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

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

4.6.2 Ordering non-medical services

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

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):

  1. 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).

  2. 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 system 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
Both
Response Trigger RTB^Z74^RTB_Z74
Query Priority Immediate
Query Characteristics Returns response sorted by Phone Number
Query 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 Status Section Reference DB Ref.
MSH Message Header Segment
2.15.9 DB
[ { SFT } ] Software
2.15.12 DB
QPD Query Parameter Definition
5.5.4 DB
RCP Response Control Parameter
5.5.6 DB

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: ^ ^ ^ ^ ^



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 Status Chapter DB Ref.
MSH Message Header
2.15.9 DB
MSA Message Acknowledgement
2.15.8 DB
[ { ERR } ] Error
2.15.5 DB
[ { SFT } ] Software
2.15.12 DB
QAK Query Acknowledgement
5.5.2 DB
QPD Query Parameter Definition
5.5.4 DB
[ --- ROW_DEFINITION begin


RDF Table Row Definition Segment
5.5.7 DB
[ { RDT } ] Table Row Data Segment
5.5.8 DB
] --- ROW_DEFINITION end


[ DSC ] Continuation Pointer
2.15.4 DB

Virtual Table:

ColName (Z74) Key/

Search

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





4.6.2.0

4.6.2.1 Examples

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^Z73^QBP_Z73|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^Z74^RTB_Z74|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.

4.7 DIET TRIGGER EVENTS & MESSAGE DEFINITIONS

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.

4.7.1 OMD - Dietary Order (Event O03)

OMD^O03^OMD_O03 Dietary Order Status Chapter DB Ref.
MSH Message Header
2 DB
[ { SFT } ] Software
2 DB
[ { NTE } ] Notes and Comments (for Header)
2 DB
[ --- PATIENT begin


PID Patient Identification
3 DB
[ PD1 ] Additional Demographics
3 DB
[ { NTE } ] Notes and Comments (for Patient ID)
2 DB
[ --- PATIENT_VISIT begin


PV1 Patient Visit
3 DB
[ PV2 ] Patient Visit _ Additional Info
3 DB
] --- PATIENT_VISIT end


[{ --- INSURANCE begin


IN1 Insurance
6 DB
[ IN2 ] Insurance Additional Info
6 DB
[ IN3 ] Insurance Add'l Info - Cert.
6 DB
}] --- INSURANCE end


[ GT1 ] Guarantor
6 DB
[ { AL1 } ] Allergy Information
3 DB
] --- PATIENT end


{ --- ORDER_DIET begin


ORC Common Order Segment
4 DB
[{ --- TIMING_DIET begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
}] --- TIMING_DIET end


[ --- DIET begin


{ ODS } Dietary Orders, Suppl., Prefer.
4 DB
[ { NTE } ] Notes and Comments (for ODS)
2 DB
[{ --- OBSERVATION begin


OBX Results
7 DB
[ { NTE } ] Notes and Comments (for OBX)
2 DB
}] --- OBSERVATION end


] --- DIET end


} --- ORDER_DIET end


[{ --- ORDER_TRAY begin


ORC Common Order Segment
4 DB
[{ --- TIMING_TRAY begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
}] --- TIMING_TRAY end


{ ODT } Diet Tray Instructions
4 DB
[ { NTE } ] Notes and Comments (for ODT)
2 DB
}] --- ORDER_TRAY end


4.7.2 ORD - dietary order acknowledgment (Event O04)

ORD^O04^ORD_O04 Dietary Order Acknowledgment Message Status Chapter DB Ref.
MSH Message Header
2 DB
MSA Message Acknowledgment
2 DB
[ { ERR } ] Error
2 DB
[ { SFT } ] Software
2 DB
[ { NTE } ] Notes and Comments (for MSA)
2 DB
[ --- RESPONSE begin


[ --- PATIENT begin


PID Patient Identification
3 DB
[ { NTE } ] Notes and Comments (for Patient ID)
2 DB
] --- PATIENT end


{ --- ORDER_DIET begin


ORC Common Order
4 DB
[{ --- TIMING_DIET begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
}] --- TIMING_DIET end


[ { ODS } ] Dietary Orders, Supplements, and Preferences
4 DB
[ { NTE } ] Notes and Comments (for ODS)
2 DB
} --- ORDER_DIET end


[{ --- ORDER_TRAY begin


ORC Common Order
4 DB
[{ --- TIMING_TRAY begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
}] --- TIMING_TRAY end


[ { ODT } ] Diet Tray Instructions
4 DB
[ { NTE } ] Notes and Comments (for ODT)
2 DB
}] --- ORDER_TRAY end


] --- RESPONSE end


4.8 DIET SEGMENTS

4.8.1 ODS - dietary orders, supplements, and preferences segment

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

HL7 Attribute Table _ ODS _ Dietary Orders, Supplements, and Preferences

SEQ LEN DT OPT RP/ # TBL # ITEM # ELEMENT NAME DB Ref.
1 1 ID R
0159 00269 Type DB
2 250 CE O Y/10
00270 Service Period DB
3 250 CE R Y/20
00271 Diet, Supplement, or Preference Code DB
4 80 ST O Y/2
00272 Text Instruction DB

4.8.1.0 ODS field definitions

4.8.1.1 ODS-1 Type (ID) 00269

Definition: This field specifies type of diet. Refer To HL7 Table 0159 - Diet Code Specification Type for valid entries.

HL7 Table 0159 - Diet Code Specification Type

Value Description Comment
D Diet
S Supplement
P Preference

4.8.1.2 ODS-2 Service Period (CE) 00270

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

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.

4.8.1.3 ODS-3 Diet, Supplement, or Preference Code (CE) 00271

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

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.

4.8.1.4 ODS-4 Text instruction (ST) 00272

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.

4.8.2 ODT - diet tray instructions segment

This segment addresses tray instructions. These are independent of diet codes, supplements, and preferences and therefore get separate order numbers.

HL7 Attribute Table _ ODT _ Diet Tray Instructions

SEQ LEN DT OPT RP/ # TBL # ITEM # ELEMENT NAME DB Ref.
1 250 CE R
0160 00273 Tray Type DB
2 250 CE O Y/10
00270 Service Period DB
3 80 ST O

00272 Text Instruction DB

4.8.2.0 ODT field definitions

4.8.2.1 ODT-1 Tray Type (CE) 00273

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: This field defines the type of dietary tray. Refer To HL7 Table 0160 - Tray Type for valid entries.

HL7 Table 0160 - Tray Type

Value Description Comment
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.

4.8.2.2 ODT-2 Service period (CE) 00270

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: When blank, the modifier applies to all service periods. This field allows you to designate one or more of the feeding periods during a day by combining the codes as needed. It can also combine with quantity/timing to give such information as which service period the order belongs with. This field is identical in meaning with ODS-2-service period. See Section 4.8.1.2, "ODS-2 Service Period (CE) 00270," for further details.

4.8.2.3 ODT-3 Text Instruction (ST) 00272

Definition: This field defines instructions associated with the tray. Example:

|PLASTIC SILVERWARE|.

4.9 DIET MESSAGE EXAMPLES

4.9.1 Typical progression of orders for a surgery patient

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>

4.9.2 Complex order

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>

4.9.3 Tube feeding

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>

4.9.4 Patient preference

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>

4.10 SUPPLY TRIGGER EVENTS & MESSAGES

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.

4.10.1 OMS - stock requisition order message (event O05)

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 Status Chapter DB Ref.
MSH Message Header
2 DB
[ { SFT } ] Software
2 DB
[ { NTE } ] Notes and Comments (for Header)
2 DB
[ --- PATIENT begin


PID Patient Identification
3 DB
[ PD1 ] Additional Demographics
3 DB
[ { NTE } ] Notes and Comments (for Patient ID)
2 DB
[ --- PATIENT_VISIT begin


PV1 Patient Visit
3 DB
[ PV2 ] Patient Visit _ Additional Info
3 DB
] --- PATIENT_VISIT end


[{ --- INSURANCE begin


IN1 Insurance
6 DB
[ IN2 ] Insurance Additional Info
6 DB
[ IN3 ] Insurance Add'l Info - Cert.
6 DB
}] --- INSURANCE end


[ GT1 ] Guarantor
6 DB
[ { AL1 } ] Allergy Information
3 DB
] --- PATIENT end


{ --- ORDER begin


ORC Common Order
4 DB
[{ --- TIMING begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
}] --- TIMING end


RQD Requisition Detail
4 DB
[ RQ1 ] Requisition Detail-1
4 DB
[ { NTE } ] Notes and Comments (for RQD)
2 DB
[{ --- OBSERVATION begin


OBX Observation/Result
7 DB
[ { NTE } ] Notes and Comments (for OBX)
2 DB
}] --- OBSERVATION end


[ BLG ] Billing Segment
4 DB
} --- ORDER end


4.10.2 ORS - stock requisition order acknowledgment message (event O06)

ORS^O06^ORS_O06 Stock Order Acknowledgment Message Status Chapter DB Ref.
MSH Message Header
2 DB
MSA Message Acknowledgment
2 DB
[ { ERR } ] Error
2 DB
[ { SFT } ] Software
2 DB
[ { NTE } ] Notes and Comments (for Header)
2 DB
[ --- RESPONSE begin


[ --- PATIENT begin


PID Patient Identification
3 DB
[ { NTE } ] Notes and Comments (for Patient ID)
2 DB
] --- PATIENT end


{ --- ORDER begin


ORC Common Order
4 DB
[{ --- TIMING begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
}] --- TIMING end


RQD Requisition Detail
4 DB
[ RQ1 ] Requisition Detail-1
4 DB
[ { NTE } ] Notes and Comments (for RQD)
2 DB
} --- ORDER end


] --- RESPONSE end


4.10.3 OMN - non-stock requisition order message (event O07)

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 Status Chapter DB Ref.
MSH Message Header
2 DB
[ { SFT } ] Software
2 DB
[ { NTE } ] Notes and Comments (for Header)
2 DB
[ --- PATIENT begin


PID Patient Identification
3 DB
[ PD1 ] Additional Demographics
3 DB
[ { NTE } ] Notes and Comments (for Patient ID)
2 DB
[ --- PATIENT_VISIT begin


PV1 Patient Visit
3 DB
[ PV2 ] Patient Visit _ Additional Info
3 DB
] --- PATIENT_VISIT end


[{ --- INSURANCE begin


IN1 Insurance
6 DB
[ IN2 ] Insurance Additional Info
6 DB
[ IN3 ] Insurance Add'l Info - Cert.
6 DB
}] --- INSURANCE end


[ GT1 ] Guarantor
6 DB
[ { AL1 } ] Allergy Information
3 DB
] --- PATIENT end


{ --- ORDER begin


ORC Common Order
4 DB
[{ --- TIMING begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
}] --- TIMING end


RQD Requisition Detail
4 DB
[ RQ1 ] Requisition Detail-1
4 DB
[ { NTE } ] Notes and Comments (for RQD)
2 DB
[{ --- OBSERVATION begin


OBX Observation/Result
7 DB
[ { NTE } ] Notes and Comments (for OBX)
2 DB
}] --- OBSERVATION end


[ BLG ] Billing Segment
4 DB
} --- ORDER end


4.10.4 ORN - non-stock requisition order acknowledgment message (event O08)

ORN^O08^ORN_O08 General Order Acknowledgment Message Status Chapter DB Ref.
MSH Message Header
2 DB
MSA Message Acknowledgment
2 DB
[ { ERR } ] Error
2 DB
[ { SFT } ] Software
2 DB
[ { NTE } ] Notes and Comments (for Header)
2 DB
[ --- RESPONSE begin


[ --- PATIENT begin


PID Patient Identification
3 DB
[ { NTE } ] Notes and Comments (for Patient ID)
2 DB
] --- PATIENT end


{ --- ORDER begin


ORC Common Order
4 DB
[{ --- TIMING begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
}] --- TIMING end


RQD Requisition Detail
4 DB
[ RQ1 ] Requisition Detail-1
4 DB
[ { NTE } ] Notes and Comments (for RQD)
2 DB
} --- ORDER end


] --- RESPONSE end


4.11 SUPPLY SEGMENTS

4.11.1 RQD - Requisition Detail Segment

RQD contains the detail for each requisitioned item. See assumptions above.

HL7 Attribute Table _ RQD _ Requisition Detail

SEQ LEN DT OPT RP/# TBL# ITEM # ELEMENT NAME DB Ref.
1 4 SI O

00275 Requisition Line Number DB
2 250 CE C

00276 Item Code - Internal DB
3 250 CE C

00277 Item Code - External DB
4 250 CE C

00278 Hospital Item Code DB
5 6 NM O

00279 Requisition Quantity DB
6 250 CE O

00280 Requisition Unit of Measure DB
7 30 IS O
0319 00281 Dept. Cost Center DB
8 30 IS O
0320 00282 Item Natural Account Code DB
9 250 CE O

00283 Deliver To ID DB
10 8 DT O

00284 Date Needed DB

4.11.1.0 RQD field definitions

4.11.1.1 RQD-1 Requisition Line Number (SI) 00275

Definition: This field contains the number that identifies this line in the requisition.

4.11.1.2 RQD-2 Item Code - Internal (CE) 00276

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

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.

4.11.1.3 RQD-3 Item Code - External (CE) 00277

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

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.

4.11.1.4 RQD-4 Hospital Item Code (CE) 00278

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: This field contains the identifier and description that uniquely identify the item on all applications in the hospital. The identifier is usually controlled by the hospital financial application in the charge description master file. This field is conditional because at least one of the three fields-- RQD-2-item code-internal, RQD-3-item code-external or RQD-4-hospital item code-- must be valued.

Note: At least one of the three fields 4.11.1.2 through 4.11.1.4must be non-null.

4.11.1.5 RQD-5 Requisition Quantity (NM) 00279

Definition: This field contains the quantity requisitioned for this item.

4.11.1.6 RQD-6 Requisition Unit of Measure (CE) 00280

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: This field contains the unit of measure for this item.

4.11.1.7 RQD-7 Dept. Cost Center (IS) 00281

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.

User-Defined Table 0319 _ Department Cost Center

Value Description Comment

No suggested values

4.11.1.8 RQD-8 Item Natural Account Code (IS) 00282

Definition: This field contains the accounting code that identifies this item in order to charge for this item. User-Defined Table 0320 - Item Natural Account Code is used as the HL7 identifier for the user-defined table of values for this field.

User-defined Table 0320 _ Item Natural Account Code

Value Description Comment

No suggested values

4.11.1.9 RQD-9 Deliver to ID (CE) 00283

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: This field contains the unique identifier and descriptive name of the department/location where the item should be delivered.

4.11.1.10 RQD-10 Date Needed (DT) 00284

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

4.11.2 RQ1 - Requisition Detail-1 Segment

RQ1 contains additional detail for each nonstock requisitioned item. This segment definition is paired with a preceding RQD segment.

HL7 Attribute Table _ RQ1 _ Requisition Detail-1

SEQ LEN DT OPT RP/# TBL# ITEM # ELEMENT NAME DB Ref.
1 10 ST O

00285 Anticipated Price DB
2 250 CE C
0385 00286 Manufacturer Identifier DB
3 16 ST C

00287 Manufacturer's Catalog DB
4 250 CE C

00288 Vendor ID DB
5 16 ST C

00289 Vendor Catalog DB
6 1 ID O
0136 00290 Taxable DB
7 1 ID O
0136 00291 Substitute Allowed DB

4.11.2.0 RQ1 field definitions

4.11.2.1 RQ1-1 Anticipated Price (ST) 00285

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.

4.11.2.2 RQ1-2 Manufacturer Identifier (CE) 00286

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

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.

Refer to User-defined Table 0385 _ Manufacturer identifier for suggested values, or relevant external code sets may be used (e.g., HIBCC Manufacturers Labeler ID Code (LIC), UPC, NDC).

4.11.2.3 RQ1-3 Manufacturer's Catalog (ST) 00287

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.

4.11.2.4 RQ1-4 Vendor ID (CE) 00288

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

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.

4.11.2.5 RQ1-5 Vendor Catalog (ST) 00289

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.

4.11.2.6 RQ1-6 Taxable (ID) 00290

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.

4.11.2.7 RQ1-7 Substitute Allowed (ID) 00291

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.

4.12 SUPPLY MESSAGE EXAMPLES

4.12.1 Patient order

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^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^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>

4.12.2 Replenish Supply Closet

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^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>

4.13 PHARMACY/TREATMENT TRIGGER EVENTS & MESSAGES

4.13.1 Usage notes for pharmacy/treatment messages

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.

4.13.2 IV solution groups

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 Chapter 2, Section 2.A.53 OSD Order Sequence Definition, "Use Case 1 Cyclic placer order groups," for further details.

4.13.3 OMP - Pharmacy/Treatment Order Message (Event O09)

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 Status Chapter DB Ref.
MSH Message Header
2 DB
[ { SFT } ] Software
2 DB
[ { NTE } ] Notes and Comments (for Header)
2 DB
[ --- PATIENT begin


PID Patient Identification
3 DB
[ PD1 ] Additional Demographics
3 DB
[ { NTE } ] Notes and Comments (for Patient ID)
2 DB
[ --- PATIENT_VISIT begin


PV1 Patient Visit
3 DB
[ PV2 ] Patient Visit _ Additional Info
3 DB
] --- PATIENT_VISIT end


[{ --- INSURANCE begin


IN1 Insurance
6 DB
[ IN2 ] Insurance Additional Info
6 DB
[ IN3 ] Insurance Add'l Info - Cert.
6 DB
}] --- INSURANCE end


[ GT1 ] Guarantor
6 DB
[ { AL1 } ] Allergy Information
3 DB
] --- PATIENT end


{ --- ORDER begin


ORC Common Order
4 DB
[{ --- TIMING begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
}] --- TIMING end


RXO Pharmacy/Treatment Order
4 DB
[ { NTE } ] Notes and Comments (for RXO)
2 DB
{ RXR } Pharmacy/Treatment Route
4 DB
[{ --- COMPONENT begin


RXC Pharmacy/Treatment Component
4 DB
[ { NTE } ] Notes and Comments (for each RXC)
2 DB
}] --- COMPONENT end


[{ --- OBSERVATION begin


OBX Observation/Result
7 DB
[ { NTE } ] Notes and Comments (for OBX)
2 DB
}] --- OBSERVATION end


[ { FT1 } ] Financial Transaction
6 DB
[ BLG ] Billing Segment
6 DB
} --- ORDER end


4.13.4 ORP - Pharmacy/Treatment Order Acknowledgment (Event O10)

ORP^O10^ORP_O10 Description Status Chapter DB Ref.
MSH Message Header
2 DB
MSA Message Acknowledgment
2 DB
[ { ERR } ] Error
2 DB
[ { SFT } ] Software
2 DB
[ { NTE } ] Notes and Comments (for Response Header)
2 DB
[ --- RESPONSE begin


[ --- PATIENT begin


PID Patient Identification
3 DB
[ { NTE } ] Notes and Comments (for Patient ID)
2 DB
] --- PATIENT end


{ --- ORDER begin


ORC Common Order
4 DB
[{ --- TIMING begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
}] --- TIMING end


[ --- ORDER_DETAIL begin


RXO Pharmacy/Treatment Order
4 DB
[ { NTE } ] Notes and Comments (for RXO)
2 DB
{ RXR } Pharmacy/Treatment Route
4 DB
[{ --- COMPONENT begin


RXC Pharmacy/Treatment Component
4 DB
[ { NTE } ] Notes and Comments (for each RXC)
2 DB
}] --- COMPONENT end


] --- ORDER_DETAIL end


} --- ORDER end


] --- RESPONSE end


4.13.5 RDE - Pharmacy/Treatment Encoded Order Message (Event O11)

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 message pair can also be used to communicate a refill authorization request, however, a specific trigger event has been assigned. See Section 4.13.13 _RDE - Pharmacy/Treatment Refill Authorization Request Message (Event O25)._ 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 Status Chapter DB Ref.
MSH Message Header
2 DB
[ { SFT } ] Software
2 DB
[ { NTE } ] Notes and Comments (for Header)
2 DB
[ --- PATIENT begin


PID Patient Identification
3 DB
[ PD1 ] Additional Demographics
3 DB
[ { NTE } ] Notes and Comments (for Patient ID)
2 DB
[ --- PATIENT_VISIT begin


PV1 Patient Visit
3 DB
[ PV2 ] Patient Visit _ Additional Info
3 DB
] --- PATIENT_VISIT end


[{ --- INSURANCE begin


IN1 Insurance

DB
[ IN2 ] Insurance Additional Info
6 DB
[ IN3 ] Insurance Add'l Info - Cert.
6 DB
}] --- INSURANCE end


[ GT1 ] Guarantor
6 DB
[ { AL1 } ] Allergy Information
3 DB
] --- PATIENT end


{ --- ORDER begin


ORC Common Order
4 DB
[{ --- TIMING begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
}] --- TIMING end


[ --- ORDER_DETAIL begin


RXO Pharmacy/Treatment Prescription Order
4 DB
[ { NTE } ] Notes and Comments (for RXO)
2 DB
{ RXR } Pharmacy/Treatment Route
4 DB
[{ --- COMPONENT begin


RXC Pharmacy/Treatment Component (for RXO)
4 DB
[ { NTE } ] Notes and Comments (for each RXC)
2 DB
}] --- COMPONENT end


] --- ORDER_DETAIL end


RXE Pharmacy/Treatment Encoded Order
4 DB
[ { NTE } ] Notes and Comments (for RXE)
2 DB
{ --- TIMING_ENCODED begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
} --- TIMING_ENCODED end


{ RXR } Pharmacy/Treatment Route
4 DB
[ { RXC } ] Pharmacy/Treatment Component (for RXE)
4 DB
[{ --- OBSERVATION begin


OBX Results
7 DB
[ { NTE } ] Notes and Comments (for OBX)
2 DB
}] --- OBSERVATION end


[ { FT1 } ] Financial Detail
6 DB
[ BLG ] Billing Segment
4 DB
[ { CTI } ] Clinical Trial Identification
7 DB
} --- ORDER end


Note: The RXCs which follow the RXO may not be fully encoded, but those that follow the RXE must be fully encoded.

The NTE segment(s) following the PD1 segment are intended to communicate notes and comments relative to the patient.

The NTE segment(s) following the RXO segment are intended to communicate notes and comments relative to the pharmacy/treatment order.

The NTE segment(s) following the RXE segment are intended to communicate notes and comments relative to the encoded order.

The NTE segment(s) following the RXC segment are intended to communicate notes and comments relative to the component(s).

The NTE segment following the OBX segment is intended to communicate notes and comments relative to the results.

4.13.6 RRE - Pharmacy/Treatment Encoded Order Acknowledgment (Event O12)

RRE^O12^RRE_O12 Pharmacy/Treatment Encoded Order Acknowledgment Message Status Chapter DB Ref.
MSH Message Header
2 DB
MSA Message Acknowledgment
2 DB
[ { ERR } ] Error
2 DB
[ { SFT } ] Software
2 DB
[ { NTE } ] Notes and Comments (for Header)
2 DB
[ --- RESPONSE begin


[ --- PATIENT begin


PID Patient Identification
3 DB
[ { NTE } ] Notes and Comments (for PID)
2 DB
] --- PATIENT end


{ --- ORDER begin


ORC Common Order
4 DB
[{ --- TIMING begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
}] --- TIMING end


[ --- ENCODING begin


RXE Pharmacy/Treatment Encoded Order
4 DB
[ { NTE } ] Notes and Comments (for RXE)
2 DB
{ --- TIMING_ENCODED begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
} --- TIMING_ENCODED end


{ RXR } Pharmacy/Treatment Route
4 DB
[ { RXC } ] Pharmacy/Treatment Component
4 DB
] --- ENCODING end


} --- ORDER end


] --- RESPONSE end


The use of RDE with the trigger of O01 and RRE with the trigger O02 is maintained for backward compatibility.

4.13.7 RDS - Pharmacy/Treatment Dispense Message (Event O13)

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 Status Chapter DB Ref.
MSH Message Header
2 DB
[ { SFT } ] Software
2 DB
[ { NTE } ] Notes and Comments (for Header)
2 DB
[ --- PATIENT begin


PID Patient Identification
3 DB
[ PD1 ] Additional Demographics
3 DB
[ { NTE } ] Notes and Comments (for PID)
2 DB
[ { AL1 } ] Allergy Information
2 DB
[ --- PATIENT_VISIT begin


PV1 Patient Visit
3 DB
[ PV2 ] Patient Visit _ Additional Info
3 DB
] --- PATIENT_VISIT end


] --- PATIENT end


{ --- ORDER begin


ORC Common Order
4 DB
[{ --- TIMING begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
}] --- TIMING end


[ --- ORDER_DETAIL begin


RXO Pharmacy /Treatment Order
4 DB
[ --- ORDER_DETAIL_SUPPLEMENT begin


{ NTE } Notes and Comments (for RXO)
2 DB
{ RXR } Pharmacy/Treatment Route
4 DB
[{ --- COMPONENT begin


RXC Pharmacy/Treatment Component
4 DB
[ { NTE } ] Notes and Comments (for each RXC)
2 DB
}] --- COMPONENT end


] --- ORDER_DETAIL+SUPPLEMENT end


] --- ORDER_DETAIL end


[ --- ENCODING begin


RXE Pharmacy/Treatment Encoded Order
4 DB
[ { NTE } ] Notes and Comments (for RXE)
2 DB
{ --- TIMING_ENCODED begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
} --- TIMING_ENCODED end


{ RXR } Pharmacy/Treatment Route
4 DB
[ { RXC } ] Pharmacy/Treatment Component
4 DB
] --- ENCODING end


RXD Pharmacy/Treatment Dispense
4 DB
[ { NTE } ] Notes and Comments (for RXD)
2 DB
{ RXR } Pharmacy/Treatment Route
4 DB
[ { RXC } ] Pharmacy/Treatment Component
4 DB
[{ --- OBSERVATION begin


OBX Results
7 DB
[ { NTE } ] Notes and Comments (for OBX)
2 DB
}] --- OBSERVATION end


[ { FT1 } ] Financial Transaction segment
6 DB
} --- ORDER end


Note: The NTE segment(s) following the PD1 segment are intended to communicate notes and comments relative to the patient.

The NTE segment(s) following the RXO segment are intended to communicate notes and comments relative to the pharmacy/treatment order.

The NTE segment(s) following the RXE segment are intended to communicate notes and comments relative to the encoded order.

The NTE segment(s) following the RXD segment are intended to communicate notes and comments relative to the dispense event.

The NTE segment(s) following the RXC segment are intended to communicate notes and comments relative to the component(s).

The NTE segment following the OBX segment is intended to communicate notes and comments relative to the results.

4.13.8 RRD - Pharmacy/Treatment Dispense Acknowledgement Message (Event O14)

RRD^O14^RRD_O14 Pharmacy/Treatment Dispense Acknowledgment Message Status Chapter DB Ref.
MSH Message Header
2 DB
MSA Message Acknowledgment
2 DB
[ { ERR } ] Error
2 DB
[ { SFT } ] Software
2 DB
[ { NTE } ] Notes and Comments (for Header)
2 DB
[ --- RESPONSE begin


[ --- PATIENT begin


PID Patient Identification
3 DB
[ { NTE } ] Notes and Comments (for Patient ID)
2 DB
] --- PATIENT end


{ --- ORDER begin


ORC Common Order
4 DB
[{ --- TIMING begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
}] --- TIMING end


[ --- DISPENSE begin


RXD Pharmacy/Treatment Dispense
4 DB
[ { NTE } ] Notes and Comments (for RXD)
2 DB
{ RXR } Pharmacy/Treatment Route
4 DB
[ { RXC } ] Pharmacy/Treatment Component
4 DB
] --- DISPENSE end


} --- ORDER end


] --- RESPONSE end


4.13.9 RGV - Pharmacy/Treatment Give Message (Event O15)

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 Status Chapter DB Ref.
MSH Message Header
2 DB
[ { SFT } ] Software
2 DB
[ { NTE } ] Notes and Comments (for Header)
2 DB
[ --- PATIENT begin


PID Patient Identification
3 DB
[ { NTE } ] Notes and Comments (for PID)
2 DB
[ { AL1 } ] Allergy Information
2 DB
[ --- PATIENT_VISIT begin


PV1 Patient Visit
3 DB
[ PV2 ] Patient Visit _ Additional Info
3 DB
] --- PATIENT_VISIT end


] --- PATIENT end


{ --- ORDER begin


ORC Common Order
4 DB
[{ --- TIMING begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
}] --- TIMING end


[ --- ORDER_DETAIL begin


RXO Pharmacy /Treatment Order
4 DB
[ --- ORDER_DETAIL_SUPPLEMENT begin


{ NTE } Notes and Comments (for RXO)
2 DB
{ RXR } Pharmacy/Treatment Route
4 DB
[{ --- COMPONENTS begin


RXC Pharmacy/Treatment Component
4 DB
[ { NTE } ] Notes and Comments (for each RXC)
2 DB
}] --- COMPONENTS end


] --- ORDER_DETAIL_SUPPLEMENT end


] --- ORDER_DETAIL end


[ --- ENCODING begin


RXE Pharmacy/Treatment Encoded Order
4 DB
{ --- TIMING_ENCODED begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
} --- TIMING_ENCODED end


{ RXR } Pharmacy/Treatment Route
4 DB
[ { RXC } ] Pharmacy/Treatment Component
4 DB
] --- ENCODING end


{ --- GIVE begin


RXG Pharmacy/Treatment Give
4 DB
{ --- TIMING_GIVE begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
} --- TIMING_GIVE end


{ RXR } Pharmacy/Treatment Route
4 DB
[ { RXC } ] Pharmacy/Treatment Component
4 DB
{ --- OBSERVATION begin


[ OBX ] Observation/Results
7 DB
[ { NTE } ] Notes and Comments (for OBX)
2 DB
} --- OBSERVATION end


} --- GIVE end


} --- ORDER end


4.13.10 RRG - Pharmacy/Treatment Give Acknowledgment Message (Event O16)

RRG^O16^RRG_O16 Pharmacy/Treatment Give Acknowledgment Message Status Chapter DB Ref.
MSH Message Header
2 DB
MSA Message Acknowledgment
2 DB
[ { ERR } ] Error
2 DB
[ { SFT } ] Software
2 DB
[ { NTE } ] Notes and Comments (for Header)
2 DB
[ --- RESPONSE begin


[ --- PATIENT begin


PID Patient Identification
3 DB
[ { NTE } ] Notes and Comments (for PID)
2 DB
] --- PATIENT end


{ --- ORDER begin


ORC Common Order
4 DB
[{ --- TIMING begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
}] --- TIMING end


[ --- GIVE begin


RXG Pharmacy/Treatment Give
4 DB
{ --- TIMING_GIVE begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
} --- TIMING_GIVE end


{ RXR } Pharmacy/Treatment Route
4 DB
[ { RXC } ] Pharmacy/Treatment Component
4 DB
] --- GIVE end


} --- ORDER end


] --- RESPONSE end


The use of RGV with the trigger of O01 and RRG with the trigger O02 is maintained for backward compatibility.

4.13.11 RAS - Pharmacy/Treatment Administration Message (Event O17)

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 Status Chapter DB Ref.
MSH Message Header
2 DB
[ { SFT } ] Software
2 DB
[ { NTE } ] Notes and Comments (for Header)
2 DB
[ --- PATIENT begin


PID Patient Identification
3 DB
[ PD1 ] Additional Demographics
3 DB
[ { NTE } ] Notes and Comments (for PID)
2 DB
[ { AL1 } ] Allergy Information
2 DB
[ --- PATIENT_VISIT begin


PV1 Patient Visit
3 DB
[ PV2 ] Patient Visit _ Additional Info
3 DB
] --- PATIENT_VISIT end


] --- PATIENT end


{ --- ORDER begin


ORC Common Order
4 DB
[{ --- TIMING begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
}] --- TIMING end


[ --- ORDER_DETAIL begin


RXO Pharmacy /Treatment Order
4 DB
[ --- ORDER_DETAIL_SUPPLEMENT begin


{ NTE } Notes and Comments (for RXO)
2 DB
{ RXR } Pharmacy/Treatment Route
4 DB
[{ --- COMPONENTS begin


RXC Pharmacy/Treatment Component
4 DB
[ { NTE } ] Notes and Comments (for each RXC)
2 DB
}] --- COMPONENTS end


] --- ORDER_DETAIL_SUPPLEMENT end


] --- ORDER_DETAIL end


[ --- ENCODING begin


RXE Pharmacy/Treatment Encoded Order
4 DB
{ --- TIMING_ENCODED begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
} --- TIMING_ENCODED end


{ RXR } Pharmacy/Treatment Route
4 DB
[ { RXC } ] Pharmacy/Treatment Component
4 DB
] --- ENCODING end


{ --- ADMINISTRATION begin


{ RXA } Pharmacy/Treatment Administration
4 DB
RXR Pharmacy/Treatment Route
4 DB
[{ --- OBSERVATION begin


OBX Observation/Result
7 DB
[ { NTE } ] Notes and Comments (for OBX)
2 DB
}] --- OBSERVATION end


} --- ADMINISTRATION end


[ { CTI } ] Clinical Trial Identification
7 DB
} --- ORDER end


4.13.12 RRA - Pharmacy/Treatment Administration Acknowledgment Message (Event O18)

RRA^O18^RRA_O18 Pharmacy/Treatment Administration Acknowledgment Message Status Chapter DB Ref.
MSH Message Header
2 DB
MSA Message Acknowledgment
2 DB
[ { ERR } ] Error
2 DB
[ { SFT } ] Software
2 DB
[ { NTE } ] Notes and Comments (for Header)
2 DB
[ --- RESPONSE begin


[ --- PATIENT begin


PID Patient Identification
3 DB
[ { NTE } ] Notes and Comments (for PID)
2 DB
] --- PATIENT end


{ --- ORDER begin


ORC Common Order
4 DB
[{ --- TIMING begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
}] --- TIMING end


[ --- ADMINISTRATION begin


{ RXA } Pharmacy/Treatment Administration
4 DB
RXR Pharmacy/Treatment Route
4 DB
] --- ADMINISTRATION end


} --- ORDER end


] --- RESPONSE end


The use of RAS with the trigger of O01 and RRA with the trigger O02 is maintained for backward compatibility.

4.13.13 RDE - Pharmacy/Treatment Refill Authorization Request Message (Event O25)

The RDE/RRE is used to communicate a refill authorization request originating with the pharmacy. This message replicates the standard RDE message with a different trigger event code to indicate the specific use case of a refill authorization request.

RDE^O25^RDE_O11 Pharmacy/Treatment Refill Authorization Request Status Chapter DB Ref.
MSH Message Header
2 DB
[ { SFT } ] Software
2 DB
[ { NTE } ] Notes and Comments (for Header)
2 DB
[ --- PATIENT begin


PID Patient Identification
3 DB
[ PD1 ] Additional Demographics
3 DB
[ { NTE } ] Notes and Comments (for Patient ID)
2 DB
[ --- PATIENT_VISIT begin


PV1 Patient Visit
3 DB
[ PV2 ] Patient Visit _ Additional Info
3 DB
] --- PATIENT_VISIT end


[{ --- INSURANCE begin


IN1 Insurance

DB
[ IN2 ] Insurance Additional Info
6 DB
[ IN3 ] Insurance Add'l Info _ Cert.
6 DB
}] --- INSURANCE end


[ GT1 ] Guarantor
6 DB
[ { AL1 } ] Allergy Information
3 DB
] --- PATIENT end


{ --- ORDER begin


ORC Common Order
4 DB
[{ --- TIMING begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
}] --- TIMING end


[ --- ORDER_DETAIL begin


RXO Pharmacy/Treatment Prescription Order
4 DB
[ { NTE } ] Notes and Comments (for RXO)
2 DB
{ RXR } Pharmacy/Treatment Route
4 DB
[{ --- COMPONENTS begin


RXC Pharmacy/Treatment Component (for RXO)
4 DB
[ { NTE } ] Notes and Comments (for each RXC)
2 DB
}] --- COMPONENTS end


] --- ORDER_DETAIL end


RXE Pharmacy/Treatment Encoded Order
4 DB
[ { NTE } ] Notes and Comments (for RXE)
2 DB
{ --- TIMING_ENCODED begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
} --- TIMING_ENCODED end


{ RXR } Pharmacy/Treatment Route
4 DB
[ { RXC } ] Pharmacy/Treatment Component (for RXE)
4 DB
[{ --- OBSERVATION begin


[ OBX ] Results
7 DB
[ { NTE } ] Notes and Comments (for OBX)
2 DB
}] --- OBSERVATION end


[ { FT1 } ] Financial Detail
6 DB
[ BLG ] Billing Segment
4 DB
[ { CTI } ] Clinical Trial Identification
7 DB
} --- ORDER end


4.13.14 RRE - Pharmacy/Treatment Refill Authorization Request Acknowledgment (Event O26)

RRE^O26^RRE_O12 Pharmacy/Treatment Refill Authorization Request Acknowledgment Message Status Chapter DB Ref.
MSH Message Header
2 DB
MSA Message Acknowledgment
2 DB
[ { ERR } ] Error
2 DB
[ { SFT } ] Software
2 DB
[ { NTE } ] Notes and Comments (for Header)
2 DB
[ --- RESPONSE begin


[ --- PATIENT begin


PID Patient Identification
3 DB
[ { NTE } ] Notes and Comments (for PID)
2 DB
] --- PATIENT end


{ --- ORDER begin


ORC Common Order
4 DB
[{ --- TIMING begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
}] --- TIMING end


[ --- ENCODING begin


RXE Pharmacy/Treatment Encoded Order
4 DB
{ --- TIMING_ENCODED begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
} --- TIMING_ENCODED end


{ RXR } Pharmacy/Treatment Route
4 DB
[ { RXC } ] Pharmacy/Treatment Component
4 DB
] --- ENCODING end


} --- ORDER end


] --- RESPONSE end


4.13.15 ROR - Pharmacy/Treatment Order Response (Event Q26)

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 Status Chapter DB Ref.
MSH Message Header
2 DB
[ { SFT } ] Software
2 DB
QRD Query Definition
5 DB
[ QRF ] Query Filler
5 DB
[ DSC ] Continuation Pointer
2 DB

ROR^ROR^ROR_ROR Pharmacy /Treatment Order Response Status Chapter DB Ref.
MSH Message Header
2 DB
MSA Message Acknowledgment
2 DB
[ { ERR } ] Error
2 DB
[ { SFT } ] Software
2 DB
{ --- DEFINITION begin


QRD Query Definition
5 DB
[ QRF ] Query Filter
5 DB
[ --- PATIENT begin


PID Patient Identification
3 DB
[ { NTE] } ] Notes and Comments (for PID)
2 DB
] --- PATIENT end


{ --- ORDER begin


ORC Common Order
4 DB
RXO Pharmacy/Treatment Order
4 DB
{ RXR } Pharmacy/Treatment Route
4 DB
[ { RXC } ] Pharmacy/Treatment Component
4 DB
} --- ORDER end


} --- DEFINITION end


[ DSC ] Continuation Pointer
2 DB

4.13.16 RAR - Pharmacy/Treatment Administration Information (Event Q27)

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 Status Chapter DB Ref.
MSH Message Header
2 DB
[ { SFT } ] Software
2 DB
QRD Query Definition
5 DB
[ QRF ] Query Filler
5 DB
[ DSC ] Continuation Pointer
2 DB

RAR^RAR^RAR_RAR Pharmacy/treatment Administration Information Status Chapter DB Ref.
MSH Message Header
2 DB
MSA Message Acknowledgment
2 DB
[ { ERR } ] Error
2 DB
[ { SFT } ] Software
2 DB
{ --- DEFINITION begin


QRD Query Definition
5 DB
[ QRF ] Query Filter
5 DB
[ --- PATIENT begin


PID Patient Identification
3 DB
[ { NTE } ] Notes and Comments (for PID)
2 DB
] --- PATIENT end


{ --- ORDER begin


ORC Common Order
4 DB
[ --- ENCODING begin


RXE Pharmacy/Treatment Encoded Order
4 DB
{ RXR } Pharmacy/Treatment Route
4 DB
[ { RXC } ] Pharmacy/Treatment Component
4 DB
] --- ENCODING end


{ RXA } Pharmacy/Treatment Administration
4 DB
RXR Pharmacy/Treatment Route
4 DB
} --- ORDER end


} --- DEFINITION end


[ DSC ] Continuation Pointer
2 DB

4.13.17 RDR - Pharmacy/Treatment Dispense Information (Event Q28)

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 Status Chapter DB Ref.
MSH Message Header
2 DB
[ { SFT } ] Software
2 DB
QRD Query Definition
5 DB
[ QRF ] Query Filler
5 DB
[ DSC ] Continuation Pointer
2 DB

RDR^RDR^RDR_RDR Pharmacy/treatment Dispense Information Status Chapter DB Ref.
MSH Message Header
2 DB
MSA Message Acknowledgment
2 DB
[ { ERR } ] Error
2 DB
[ { SFT } ] Software
2 DB
{ --- DEFINITION begin


QRD Query Definition
5 DB
[ QRF ] Query Filter
5 DB
[ --- PATIENT begin


PID Patient Identification
3 DB
[ { NTE } ] Notes and Comments (for PID)
2 DB
] --- PATIENT end


{ --- ORDER begin


ORC Common Order
4 DB
[ --- ENCODING begin


RXE Pharmacy/Treatment Encoded Order
4 DB
{ RXR } Pharmacy/Treatment Route
4 DB
[ { RXC } ] Pharmacy/Treatment Component
4 DB
] --- ENCODING end


{ --- DISPENSE begin


RXD Pharmacy/Treatment Dispense
4 DB
{ RXR } Pharmacy/Treatment Route
4 DB
[ { RXC } ] Pharmacy/Treatment Component
4 DB
} --- DISPENSE end


} --- ORDER end


} --- DEFINITION end


[ DSC ] Continuation Pointer
2 DB

4.13.18 RER - Pharmacy/Treatment Encoded Order Information (Event Q29)

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 Status Chapter DB Ref.
MSH Message Header
2 DB
[ { SFT } ] Software
2 DB
QRD Query Definition
5 DB
[ QRF ] Query Filler
5 DB
[ DSC ] Continuation Pointer
2 DB

RER^RER^RER_RER Pharmacy/treatment Encoded Order Information Status Chapter DB Ref.
MSH Message Header
2 DB
MSA Message Acknowledgment
2 DB
[ { ERR } ] Error
2 DB
[ { SFT } ] Software
2 DB
{ --- DEFINITION begin


QRD Query Definition
5 DB
[ QRF ] Query Filter
5 DB
[ --- PATIENT begin


PID Patient Identification
3 DB
[ { NTE } ] Notes and Comments (for PID)
2 DB
] --- PATIENT end


{ --- ORDER begin


ORC Common Order
4 DB
RXE Pharmacy/Treatment Encoded Order
4 DB
{ RXR } Pharmacy/Treatment Route
4 DB
[ { RXC } ] Pharmacy/Treatment Component
4 DB
} --- ORDER end


} --- DEFINITION end


[ DSC ] Continuation Pointer
2 DB

4.13.19 RGR - Pharmacy/Treatment Dose Information (Event Q30)

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 Status Chapter DB Ref.
MSH Message Header
2 DB
[ { SFT } ] Software
2 DB
QRD Query Definition
5 DB
[ QRF ] Query Filler
5 DB
[ DSC ] Continuation Pointer
2 DB

RGR^RGR^RGR_RGR Pharmacy/treatment Dose Information Status Chapter DB Ref.
MSH Message Header
2 DB
MSA Message Acknowledgment
2 DB
[ { ERR } ] Error
2 DB
[ { SFT } ] Software
2 DB
{ --- DEFINITION begin


QRD Query Definition
5 DB
[ QRF ] Query Filter
5 DB
[ --- PATIENT begin


PID Patient Identification
3 DB
[ { NTE } ] Notes and Comments (for PID)
2 DB
] --- PATIENT end


{ --- ORDER begin


ORC Common Order
4 DB
[ --- ENCODING begin


RXE Pharmacy/Treatment Encoded Order
4 DB
{ RXR } Pharmacy/Treatment Route
4 DB
[ { RXC } ] Pharmacy/treatment Component
4 DB
] --- ENCODING end


{ RXG } Pharmacy/Treatment Give
4 DB
{ RXR } Pharmacy/Treatment Route
4 DB
[ { RXC } ] Pharmacy/Treatment Component
4 DB
} --- ORDER end


} --- DEFINITION end


[ DSC ] Continuation Pointer
2 DB

4.13.20 Pharmacy Query/Response Message Pair

Conformance Statement

Query ID Q31
Query Type Query
Query Name Dispense History
Query Trigger QBP^Q31^QBP_Q11
Both
Response Trigger RSP^K31^RSP_K31
Query Characteristics May specify patient, medication, a date range, and how the response is to be sorted.
Query Purpose To retrieve patient pharmacy dispense history information from the Server.
Response Characteristics Sorted by Medication Dispensed unless otherwise specified in SortControl.
Query Trigger QBP^Q31^QBP_Q11

QBP^Q31^QBP_Q11 Query Grammar: QBP Message Status Section Reference DB Ref.
MSH Message Header Segment
2.15.9 DB
[ { SFT } ] Software
2.15.12 DB
QPD Query Parameter Definition
5.5.3 DB
RCP Response Control Parameter
5.5.6 DB
[ DSC ] Continuation Pointer
2.15.4 DB

RSP^K31^RSP_K31 Response Grammar: Pharmacy Dispense Message Status Sec Ref DB Ref.
MSH Message Header
2.15.9 DB
MSA Message Acknowledgement
2.15.8 DB
[ { ERR } ] Error
2.15.5 DB
[ { SFT } ] Software
2.15.12 DB
QAK Query Acknowledgement
5.5.2 DB
QPD Query Parameter Definition
5.5.3 DB
RCP Response Control Parameter
5.5.6 DB
{ --- RESPONSE begin


[ --- PATIENT begin


PID Patient Identification
3.3.2 DB
[ PD1 ] Additional Demographics
3.3.9 DB
[ { NTE } ] Notes and Comments (for PID)
2.15.10 DB
[ { AL1 } ] Allergy Information
3.3.6 DB
[ --- PATIENT_VISIT begin


PV1 Patient Visit
3.3.3 DB
[ PV2 ] Patient Visit _ Additional Info
3.3.4 DB
] --- PATIENT_VISIT end


] --- PATIENT end


{ --- ORDER begin


ORC Common Order
4.5.1 DB
[{ --- TIMING begin


TQ1 Timing/Quantity
4.5.4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4.5.5 DB
}] --- TIMING end


[ --- ORDER_DETAIL begin


RXO Pharmacy/Treatment Order
4.14.1 DB
[ { NTE } ] Notes and Comments (for RXO)
2.15.10 DB
{ RXR } Pharmacy/Treatment Route
4.14.2 DB
[{ --- COMPONENTS begin


RXC Pharmacy/Treatment Component
4.14.3 DB
[ { NTE } ] Notes and Comments (for each RXC)
2.15.10 DB
}] --- COMPONENTS end


] --- ORDER_DETAIL end


[ --- ENCODING begin


RXE Pharmacy/Treatment Encoded Order
4.14.4 DB
{ --- TIMING_ENCODED begin


TQ1 Timing/Quantity
4.5.4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4.5.5 DB
} --- TIMING_ENCODED end


{ RXR } Pharmacy/Treatment Route
4.14.2 DB
[ { RXC } ] Pharmacy/Treatment Component
4.14.3 DB
] --- ENCODING end


RXD Pharmacy/Treatment Dispense
4.14.5 DB
{ RXR } Pharmacy/Treatment Route
4.14.2 DB
[ { RXC } ] Pharmacy/Treatment Component
4.14.3 DB
{ --- OBSERVATION begin


[ OBX ] Results
7.14.2 DB
[ { NTE } ] Notes and Comments (for OBX)
2.15.10 DB
} --- OBSERVATION end


} --- ORDER end


} --- RESPONSE end


[ DSC ] Continuation Pointer
2.15.4 DB

Field Seq (Query ID=Q31) Name Key/

Search

Sort LEN TYPE Opt Rep Match Op TBL Segment Field Name Service Identifier Code ElementName
1 MessageQueryName

60 CE R





2 QueryTag

32 ST R






PatientList S Y 20 CX O


PID.3
PID-3: Patient Identifier List

MedicationDispensed S Y 100 CE O
=
RXD.2
RXD-2: Dispense/Give Code

DispenseDate.LL S Y 26 TS O
> =
RXD.3
RXD-3: Date/Time Dispensed

DispenseDate.UL S Y 26 TS O
< =
RXD.3
RXD-3: Date/Time Dispensed

Input Parameter (Query ID=Q31) Comp. Name DT Description
MessageQueryName
CE Must be valued Q31^Dispense History^HL7nnnn.
QueryTag
ST Unique to each query message instance.
PatientList
CX The combination of values for PatientList.ID, and PatientList.AssigningAuthority, are intended to identify a unique entry on the PATIENT_MASTER table. The PatientList.IdentifierTypeCode is useful for further filtering or to supply uniqueness in the event that the assigning authority may have more than one coding system. (The PATIENT_MASTER table contains a constraint that prevents multiple patients from being identified by the same combination of field values.) This PATIENT_MASTER entry will be searched against on the PHARMACY_DISPENSE_TRANSACTION table to retrieve the rows fulfilling the query conditions. If this field is not valued, all values for this field are considered to be a match. If one PID.3 is specified, only 1 segment pattern will be returned.

ID ID If this field, PID.3.1, is not valued, all values for this field are considered to be a match.

Assigning Authority HD If this field, PID.3.4, is not valued, all values for this field are considered to be a match.

Identifier type code IS If this field, PID.3.5, is not valued, all values for this field are considered to be a match.
MedicationDispensed
CE If this field is not valued, all values for this field are considered to be a match.
DispenseDate.LL
TS This is the earliest value to be returned for Date/Time Dispensed. If this field is not valued, all values for this field are considered to be a match.
DispenseDate.UL
TS This is the latest value to be returned for Date/Time Dispensed. If this field is not valued, all values for this field are considered to be a match.

4.13.20.1 Example

Example: The user wishes to know all the medications dispensed for the patient whose medical record number is "555444222111" for the period beginning 5/31/98 and ending 5/31/99. The following QBP message is generated.

MSH|^&~\|PCR|Gen Hosp|PIMS||199811201400-0800||QBP^Q31^QBP_Q11|ACK9901|P|2.4||||||||

QPD|Q31^Dispense History^HL7nnnn|Q001|555444222111^^^MPI^MR||19980531|19990531|

RCP|I|999^RD|

The pharmacy system identifies medical record number "555444222111" as belonging to Adam Everyman and locates 4 prescription dispenses for the period beginning 5/31/98 and ending 5/31/99and returns the following RSP message:

MSH|^&~\|PIMS|Gen hosp|PCR||199811201400-0800||RSP^K31^RSP_K31|8858|P|2.4||||||||

MSA|AA|ACK9901|

QAK|Q001|OK|Q31^Dispense History^HL7nnnn|4|

QPD|Q31^Dispense History^HL7nnnn|Q001|555444222111^^^MPI^MR||19980531|19990531|

PID|||555444222111^^^MPI^MR||Everyman^Adam||19600614|M||C|2101 Webster # 106^^Oakland^CA^94612||^^^^^510^6271111|^^^^^510^6277654|||||343132266|||N|||||||||

ORC|RE||89968665||||||199805121345-0700|||77^Hippocrates^Harold^H^III^DR^MD||^^^^^510^ 2673600||||||

RXE|1^BID^^19980529|00378112001^Verapamil Hydrochloride 120 mg TAB^NDC |120||mgm||||||||||||||||||||||||||

RXD|1|00378112001^Verapamil Hydrochloride 120 mg TAB^NDC |199805291115-0700|100|||1331665|3|||||||||||||||||

RXR|PO||||

ORC|RE||89968665||||||199805291030-0700|||77^Hippocrates^Harold^H^III^DR^MD||^^^^^510^ 2673600||||||

RXE|1^^D100^^20020731^^^TAKE 1 TABLET DAILY --GENERIC FOR CALAN SR|00182196901^VERAPAMIL HCL ER TAB 180MG ER^NDC |100||180MG|TABLET SA|||G|||0|BC3126631^CHU^Y^L||213220929|0|0|19980821|||

RXD|1|00182196901^VERAPAMIL HCL ER TAB 180MG ER^NDC |19980821|100|||213220929|0|TAKE 1 TABLET DAILY --GENERIC FOR CALAN SR||||||||||||

RXR|PO||||

ORC|RE||235134037||||||199809221330-0700|||88^Semmelweis^Samuel^^^DR^MD||^^^^^510^ 2673900||||||

RXD|1|00172409660^BACLOFEN 10MG TABS^NDC|199809221415-0700|10|||235134037|5|AS DIRECTED||||||||||||

RXR|PO||||

ORC|RE||235134030||||||199810121030-0700|||99^Lister^Lenora^^^DR^MD||^^^^^510^ 2673700||||||

RXD|1|00054384163^THEOPHYLLINE 80MG/15ML SOLN^NDC|199810121145-0700|10|||235134030|5|AS DIRECTED||||||||||||

RXR|PO

4.14 PHARMACY/TREATMENT SEGMENTS

4.14.1 RXO - Pharmacy/Treatment Order Segment

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.

HL7 Attribute Table _ RXO _ Pharmacy/Treatment Order

SEQ LEN DT OPT RP/# TBL# ITEM # ELEMENT NAME DB Ref.
1 250 CE C

00292 Requested Give Code DB
2 20 NM C

00293 Requested Give Amount - Minimum DB
3 20 NM O

00294 Requested Give Amount - Maximum DB
4 250 CE C

00295 Requested Give Units DB
5 250 CE C

00296 Requested Dosage Form DB
6 250 CE O Y
00297 Provider's Pharmacy/Treatment Instructions DB
7 250 CE O Y
00298 Provider's Administration Instructions DB
8 200 LA1 O

00299 Deliver-To Location DB
9 1 ID O
0161 00300 Allow Substitutions DB
10 250 CE O

00301 Requested Dispense Code DB
11 20 NM O

00302 Requested Dispense Amount DB
12 250 CE O

00303 Requested Dispense Units DB
13 3 NM O

00304 Number Of Refills DB
14 250 XCN C Y
00305 Ordering Provider's DEA Number DB
15 250 XCN C Y
00306 Pharmacist/Treatment Supplier's Verifier ID DB
16 1 ID O
0136 00307 Needs Human Review DB
17 20 ST C

00308 Requested Give Per (Time Unit) DB
18 20 NM O

01121 Requested Give Strength DB
19 250 CE O

01122 Requested Give Strength Units DB
20 250 CE O Y
01123 Indication DB
21 6 ST O

01218 Requested Give Rate Amount DB
22 250 CE O

01219 Requested Give Rate Units DB
23 10 CQ O

00329 Total Daily Dose DB
24 250 CE O Y
01476 Supplementary Code DB
25 5 NM O

01666 Requested Drug Strength Volume DB
26 250 CWE O

01667 Requested Drug Strength Volume Units DB
27 1 ID O
0480 01668 Pharmacy Order Type DB
28 20 NM O

01669 Dispensing Interval DB

4.14.1.0 RXO field definitions

4.14.1.1 RXO-1 Requested Give Code (CE) 00292

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

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.

4.14.1.2 RXO-2 Requested Give Amount - Minimum (NM) 00293

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

4.14.1.3 RXO-3 Requested Give Amount - Maximum (NM) 00294

Definition: In a variable dose order, this is the maximum ordered amount. In a non-varying dose order, this field is not used.

4.14.1.4 RXO-4 Requested Give Units (CE) 00295

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

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.

4.14.1.5 RXO-5 Requested Dosage Form (CE) 00296

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

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.

4.14.1.6 RXO-6 Provider's Pharmacy/Treatment Instructions (CE) 00297

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

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.

4.14.1.7 RXO-7 Provider's Administration Instructions (CE) 00298

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

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

4.14.1.8 RXO-8 Deliver-to Location (LA1) 00299

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 for Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for 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.

4.14.1.9 RXO-9 Allow Substitutions (ID) 00300

Definition: Following are the values:

HL7 Table 0161 - Allow Substitution

Value Description Comment
N Substitutions are NOT authorized. (This is the default - null.)
G Allow generic substitutions.
T Allow therapeutic substitutions

4.14.1.10 RXO-10 Requested Dispense Code (CE) 00301

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

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.

4.14.1.11 RXO-11 Requested Dispense Amount (NM) 00302

Definition: This field specifies the amount to be dispensed. See above note.

4.14.1.12 RXO-12 Requested Dispense Units (CE) 00303

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

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.

4.14.1.13 RXO-13 Number of Refills (NM) 00304

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.

4.14.1.14 RXO-14 Ordering Provider's DEA Number (XCN) 00305

Components: <ID Number (ST)> ^ <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR) (ST)> ^ <DEPRECATED-Degree (e.g., MD) (IS)> ^ <Source Table (IS)> ^ <Assigning Authority (HD)> ^ <Name Type Code (ID)> ^ <Identifier Check Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name Representation Code (ID)> ^ <Name Context (CE)> ^ <DEPRECATED-Name Validity Range (DR)> ^ <Name Assembly Order (ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^ <Professional Suffix (ST)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or Department (CWE)>

Subcomponents for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname (ST)> & <Surname Prefix From Partner/Spouse (ST)> & <Surname From Partner/Spouse (ST)>

Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Name Context (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>

Subcomponents for DEPRECATED-Name Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>

Note subcomponent contains sub-subcomponents

Subcomponents for Effective Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Expiration Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>

Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>

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

4.14.1.15 RXO-15 Pharmacist/Treatment Supplier's Verifier ID (XCN) 00306

Components: <ID Number (ST)> ^ <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR) (ST)> ^ <DEPRECATED-Degree (e.g., MD) (IS)> ^ <Source Table (IS)> ^ <Assigning Authority (HD)> ^ <Name Type Code (ID)> ^ <Identifier Check Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name Representation Code (ID)> ^ <Name Context (CE)> ^ <DEPRECATED-Name Validity Range (DR)> ^ <Name Assembly Order (ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^ <Professional Suffix (ST)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or Department (CWE)>

Subcomponents for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname (ST)> & <Surname Prefix From Partner/Spouse (ST)> & <Surname From Partner/Spouse (ST)>

Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Name Context (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>

Subcomponents for DEPRECATED-Name Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>

Note subcomponent contains sub-subcomponents

Subcomponents for Effective Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Expiration Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>

Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>

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.

4.14.1.16 RXO-16 Needs Human Review (ID) 00307

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.

4.14.1.17 RXO-17 Requested Give Per (Time Unit) (ST) 00308

Definition: This field identifies the time unit to use to calculate the rate at which the pharmaceutical is to be administered.

Format:

S = seconds
M = minutes
H = hours
D = days
W = weeks
L = 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.

4.14.1.18 RXO-18 Requested Give Strength (NM) 01121

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.

4.14.1.19 RXO-19 Requested Give Strength Units (CE) 01122

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

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 (micg/h) is an acceptable value. These compound units are contained in the ISO+ table. See Chapter 7 for full definition of ISO+ units.

4.14.1.20 RXO-20 Indication (CE) 01123

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: This field identifies the condition or problem for which the drug/treatment was prescribed. May repeat if multiple indications are relevant.

4.14.1.21 RXO-21 Requested Give Rate Amount (ST) 01218

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.

4.14.1.22 RXO-22 Requested Give Rate Units (CE) 01219

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: This field contains the units in which RXO-21-requested give rate amount is denominated.

4.14.1.23 RXO-23 Total Daily Dose (CQ) 00329

Components: <Quantity (NM)> ^ <Units (CE)>

Subcomponents for Units (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>

Definition: This field contains the total daily dose for this particular pharmaceutical as expressed in terms of actual dispense units.

4.14.1.24 RXO-24 Supplementary Code (CE) 01476

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

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

4.14.1.25 RXO-25 Requested Drug Strength Volume (NM) 01666

Description: This numeric field defines the volume measurement in which the drug strength concentration is contained. For example, Acetaminophen 120 MG/5ML Elixir means that 120 MG of the drug is in a solution with a volume of 5 ML, which would be encoded in RXO-18, RXO-19, RXO-25 and RXO-26 as

RXO||||||||||||||||||120|mg^^ISO||||||5|ml^^ISO _<cr>

4.14.1.26 RXO-26 Requested Drug Strength Volume Units (CWE) 01667

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

Description: This field indicates the volumetric unit associated with RXO-25 Requested Drug Strength Volume. See example in RXO-25.

4.14.1.27 RXO-27 Pharmacy Order Type (ID) 01668

Definition: The Pharmacy Order Type field defines the general category of pharmacy order which may be used to determine the processing path the order will take. Refer to HL7 Table 0480 Pharmacy Order Types for valid values.

This field may also be used for grouping of related orders for processing and/or reports. For example, Medication Administration Records (MARs) often group large volume solutions, medications and small volume solutions differently based upon site-specific workflow.

Usage Rule: This field is optional for all Pharmacy transactions. When not populated, a default value of "M" is assumed.

HL7 Table 0480 _ Pharmacy Order Types

Value Description Comment
M Medication Default value. Includes, but is not limited to, tables, capsules, powders, puffs, and other non-injected/non-infused products.
S IV Large Volume Solutions Includes, but is not limited to, TPNs, admixtures, solutions and drips.
O Other solution as medication orders Includes, but is not limited to, piggybacks and syringes

4.14.1.28 RXO-28 Dispensing Interval (NM) 01669

Definition: This field specifies the minimum number of days that must occur between dispensing events

4.14.2 RXR - Pharmacy/Treatment Route Segment

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.

HL7 Attribute Table _ RXR _ Pharmacy/Treatment Route

SEQ LEN DT OPT RP/# TBL# ITEM # ELEMENT NAME DB Ref.
1 250 CE R
0162 00309 Route DB
2 250 CWE O
0163 00310 Administration Site DB
3 250 CE O
0164 00311 Administration Device DB
4 250 CWE O
0165 00312 Administration Method DB
5 250 CE O

01315 Routing Instruction DB
6 250 CWE O
0495 01670 Administration Site Modifier DB

4.14.2.0 RXR field definitions

4.14.2.1 RXR-1 Route (CE) 00309

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

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 User-Defined Table 0162 - Route Of Administration for valid values.

User-defined Table 0162 - Route of Administration

Value Description Comment
AP Apply Externally
B Buccal
DT Dental
EP Epidural
ET Endotrachial Tube* used primarily for respiratory therapy and anesthesia delivery
GTT Gastrostomy Tube
GU GU Irrigant
IMR Immerse (Soak) Body Part
IA Intra-arterial
IB Intrabursal
IC Intracardiac
ICV Intracervical (uterus)
ID Intradermal
IH Inhalation
IHA Intrahepatic Artery
IM Intramuscular
IN Intranasal
IO Intraocular
IP Intraperitoneal
IS Intrasynovial
IT Intrathecal
IU Intrauterine
IV Intravenous
MTH Mouth/Throat
MM Mucous Membrane
NS Nasal
NG Nasogastric
NP Nasal Prongs* used primarily for respiratory therapy and anesthesia delivery
NT Nasotrachial Tube
OP Ophthalmic
OT Otic
OTH Other/Miscellaneous
PF Perfusion
PO Oral
PR Rectal
RM Rebreather Mask* used primarily for respiratory therapy and anesthesia delivery
SD Soaked Dressing
SC Subcutaneous
SL Sublingual
TP Topical
TRA Tracheostomy* used primarily for respiratory therapy and anesthesia delivery
TD Transdermal
TL Translingual
UR Urethral
VG Vaginal
VM Ventimask
WND Wound

4.14.2.2 RXR-2 Administration Site (CWE) 00310

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

Definition: This field contains the site of the administration route. When using a post-coordinated code table in this field, RXR-6 Administration Site may be used to modify the meaning of this field.

Refer to HL7 Table 0550 _ Body Parts for valid values. For backward compatibility, HL7 Table 0163 _ Body Site may also be employed. Other appropriate external code sets (e.g., SNOMED) may also be employed.

4.14.2.3 RXR-3 Administration Device (CE) 00311

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

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 User-defined Table 0164 - Administration device for valid entries.

User-defined Table 0164 - Administration Device

Value Description Comment
AP Applicator
BT Buretrol
HL Heparin Lock
IPPB IPPB
IVP IV Pump
IVS IV Soluset
MI Metered Inhaler
NEB Nebulizer
PCA PCA Pump

4.14.2.4 RXR-4 Administration Method (CWE) 00312

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

Definition: This field identifies the specific method requested for the administration of the drug or treatment to the patient. Refer To User-defined Table 0165 _ Administration Method for valid values.

User-defined Table 0165 - Administration Method

Value Description Comment
CH Chew
DI Dissolve
DU Dust
IF Infiltrate
IS Insert
IR Irrigate
IVPB IV Piggyback
IVP IV Push
NB Nebulized
PT Pain
PF Perfuse
SH Shampoo
SO Soak
WA Wash
WI Wipe

4.14.2.5 RXR-5 Routing Instruction (CE) 01315

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

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.

4.14.2.6 RXR-6 Administration Site Modifier (CWE) 01670

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

Definition: This field contains a modifier which modifies the meaning of RXR-2 Administration Site.

The code table used in this field is dependent upon the code table used in RXR-2 Administration site. If RXR-2 employs HL7 Table 0550 _ Body Parts, then this field may only be populated with values from HL7 Table 0495 _ Body Parts Modifier. If RXR-2 employs HL7 Table 0163 _ Body Site, then RXR-6 should not be populated. In the case of other code sets (e.g., SNOMED) in RXR-2, RXR-6 may only be populated if modifiers are defined within, or related to, that code set.

Condition Rule: This field may only be populated if RXR-2 Administration Site is populated. This field is not required if RXR-2 is populated.

4.14.3 RXC - Pharmacy/Treatment Component Order Segment

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.

HL7 Attribute Table _ RXC _ Pharmacy/Treatment Component Order

SEQ LEN DT OPT RP/# TBL# ITEM # ELEMENT NAME DB Ref.
1 1 ID R
0166 00313 RX Component Type DB
2 250 CE R

00314 Component Code DB
3 20 NM R

00315 Component Amount DB
4 250 CE R

00316 Component Units DB
5 20 NM O

01124 Component Strength DB
6 250 CE O

01125 Component Strength Units DB
7 250 CE O Y
01476 Supplementary Code DB
8 5 NM O

01671 Component Drug Strength Volume DB
9 250 CWE O

01672 Component Drug Strength Volume Units DB

4.14.3.0 RXC field definitions

4.14.3.1 RXC-1 RX Component Type (ID) 00313

Definition: Following are the values for this field:

HL7 Table 0166 - RX Component Type

Value Description Comment
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.

4.14.3.2 RXC-2 Component Code (CE) 00314

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

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.

4.14.3.3 RXC-3 Component Amount (NM) 00315

Definition: This field identifies the amount of this component to be added to the specified amount of the base.

4.14.3.4 RXC-4 Component Units (CE) 00316

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

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.

4.14.3.5 RXC-5 Component Strength (NM) 01124

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.

4.14.3.6 RXC-6 Component Strength Units (CE) 01125

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

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 (micg/h) is an acceptable value. These compound units are contained in the ISO+ table. See Chapter 7 for full definition of ISO+ units.

4.14.3.7 RXC-7 Supplementary Code (CE) 01476

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

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

4.14.3.8 RXC-8 Component Drug Strength Volume (NM) 01671

Description: This numeric field defines the volume measurement in which the drug strength concentration is contained. For example, Acetaminophen 120 MG/5ML Elixir means that 120 MG of the drug is in a solution with a volume of 5 , which would be encoded in RXC-5, RXC-6, RXC-8 and RXC-9 as

RXC|||||120|mg^^ISO||5|ml^^ISO _<cr>

4.14.3.9 RXC-9 Component Drug Strength Volume Units (CWE) 01672

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

Description: This field indicates the volumetric unit associated with RXC-8 Component Drug Strength Volume. See example in RXC-8.

4.14.4 RXE - Pharmacy/Treatment Encoded Order Segment

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.

HL7 Attribute Table _ RXE _ Pharmacy/Treatment Encoded Order

SEQ LEN DT OPT RP/# TBL# ITEM # ELEMENT NAME DB Ref.
1 200 TQ B

00221 Quantity/Timing DB
2 250 CE R
0292 /

0479

00317 Give Code DB
3 20 NM R

00318 Give Amount - Minimum DB
4 20 NM O

00319 Give Amount - Maximum DB
5 250 CE R

00320 Give Units DB
6 250 CE O

00321 Give Dosage Form DB
7 250 CE O Y
00298 Provider's Administration Instructions DB
8 200 LA1 B

00299 Deliver-to Location DB
9 1 ID O
0167 00322 Substitution Status DB
10 20 NM C

00323 Dispense Amount DB
11 250 CE C

00324 Dispense Units DB
12 3 NM O

00304 Number of Refills DB
13 250 XCN C Y
00305 Ordering Provider's DEA Number DB
14 250 XCN O Y
00306 Pharmacist/Treatment Supplier's Verifier ID DB
15 20 ST C

00325 Prescription Number DB
16 20 NM C

00326 Number of Refills Remaining DB
17 20 NM C

00327 Number of Refills/Doses Dispensed DB
18 26 TS C

00328 D/T of Most Recent Refill or Dose Dispensed DB
19 10 CQ C

00329 Total Daily Dose DB
20 1 ID O
0136 00307 Needs Human Review DB
21 250 CE O Y
00330 Pharmacy/Treatment Supplier's Special Dispensing Instructions DB
22 20 ST C

00331 Give Per (Time Unit) DB
23 6 ST O

00332 Give Rate Amount DB
24 250 CE O

00333 Give Rate Units DB
25 20 NM O

01126 Give Strength DB
26 250 CE O

01127 Give Strength Units DB
27 250 CE O Y
01128 Give Indication DB
28 20 NM O

01220 Dispense Package Size DB
29 250 CE O

01221 Dispense Package Size Unit DB
30 2 ID O
0321 01222 Dispense Package Method DB
31 250 CE O Y
01476 Supplementary Code DB
32 26 TS O

01673 Original Order Date/Time DB
33 5 NM O

01674 Give Drug Strength Volume DB
34 250 CWE O

01675 Give Drug Strength Volume Units DB
35 60 CWE O
0477 01676 Controlled Substance Schedule DB
36 1 ID O
0478 01677 Formulary Status DB
37 60 CWE O Y
01678 Pharmaceutical Substance Alternative DB
38 250 CWE O

01679 Pharmacy of Most Recent Fill DB
39 250 NM O

01680 Initial Dispense Amount DB
40 250 CWE O

01681 Dispensing Pharmacy DB
41 250 XAD O

01682 Dispensing Pharmacy Address DB
42 80 PL O

01683 Deliver-to Patient Location DB
43 250 XAD O

01684 Deliver-to Address DB
44 1 ID O
0480 01685 Pharmacy Order Type DB

4.14.4.0 RXE field definitions

4.14.4.1 RXE-1 Quantity/Timing (TQ) 00221

Components: <Quantity (CQ)> ^ <Interval (RI)> ^ <Duration (ST)> ^ <Start Date/Time (TS)> ^ <End Date/Time (TS)> ^ <Priority (ST)> ^ <Condition (ST)> ^ <Text (TX)> ^ <Conjunction (ID)> ^ <Order Sequencing (OSD)> ^ <Occurrence Duration (CE)> ^ <Total Occurrences (NM)>

Subcomponents for Quantity (CQ): <Quantity (NM)> & <Units (CE)>

Note subcomponent contains sub-subcomponents

Subcomponents for Interval (RI): <Repeat Pattern (IS)> & <Explicit Time Interval (ST)>

Subcomponents for Start Date/Time (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for End Date/Time (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Order Sequencing (OSD): <Sequence/Results Flag (ID)> & <Placer Order Number: Entity Identifier (ST)> & <Placer Order Number: Namespace ID (IS)> & <Filler Order Number: Entity Identifier (ST)> & <Filler Order Number: Namespace ID (IS)> & <Sequence Condition Value (ST)> & <Maximum Number of Repeats (NM)> & <Placer Order Number: Universal ID (ST)> & <Placer Order Number: Universal ID Type (ID)> & <Filler Order Number: Universal ID (ST)> & <Filler Order Number: Universal ID Type (ID)>

Subcomponents for Occurrence Duration (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>

Definition: This field is retained for backward compatibility only. The reader is referred to the TQ1 and TQ2 segments described in sections 4.5.4 and 4.5.5 respectively.

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.

4.14.4.2 RXE-2 Give Code (CE) 00317

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

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.

The coding system used is conditional on both the nature of the medical substance or treatment ordered and site-specific implementation considerations. For vaccines, HL7 Table 0292 _ Vaccines Administered is the preferred coding system. For non-vaccine products, the coding system may be a local implementation of User-defined Table 0479 _ Pharmaceutical Substances or an external coding system. Examples of external coding systems include, but are not limited to, National Drug Codes (NDC), Medispan Generic Product Identifier (MGPI), Drug Descriptor Identifier (DDID), and other drug codes listed in HL7 Table 0396 _ Coding Systems. The following examples illustrate some code tables other than User-defined Table 0479:

NDC: 0006915404^Norvasc 10mg Tabs^NDC

DDID: 015189^Norvasc 10mg Tabs^DDID

CVX (HL70292): 30^HBIG^CVX

User-defined Table 0479 _ Pharmaceutical Substances

Value Description Comment

No suggested values

4.14.4.3 RXE-3 Give Amount - Minimum (NM) 00318

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

4.14.4.4 RXE-4 Give Amount - Maximum (NM) 00319

Definition: In a variable dose order, this is the maximum ordered amount. In a nonvarying dose, this field is not used.

4.14.4.5 RXE-5 Give Units (CE) 00320

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

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.

4.14.4.6 RXE-6 Give Dosage Form (CE) 00321

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

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.

4.14.4.7 RXE-7 Provider's Administration Instructions (CE) 00298

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

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

4.14.4.8 RXE-8 Deliver-to Location (LA1) 00299

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 for Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for 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: This field is retained for backward compatibility only. The reader is referred to RXE:40, RXE-41, RXE-42 and RXE-43. 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.

4.14.4.9 RXE-9 Substitution Status (ID) 00322

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.

HL7 Table 0167 - Substitution Status

Value Description Comment
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

4.14.4.10 RXE-10 Dispense Amount (NM) 00323

Definition: This field contains the amount to be dispensed as encoded by the pharmacy or treatment supplier.

4.14.4.11 RXE-11 Dispense Units (CE) 00324

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

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.

4.14.4.12 RXE-12 Number of Refills (NM) 00304

Definition: This field contains the total original number of refills. Outpatient only.

4.14.4.13 RXE-13 Ordering Provider's DEA Number (XCN) 00305

Components: <ID Number (ST)> ^ <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR) (ST)> ^ <DEPRECATED-Degree (e.g., MD) (IS)> ^ <Source Table (IS)> ^ <Assigning Authority (HD)> ^ <Name Type Code (ID)> ^ <Identifier Check Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name Representation Code (ID)> ^ <Name Context (CE)> ^ <DEPRECATED-Name Validity Range (DR)> ^ <Name Assembly Order (ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^ <Professional Suffix (ST)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or Department (CWE)>

Subcomponents for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname (ST)> & <Surname Prefix From Partner/Spouse (ST)> & <Surname From Partner/Spouse (ST)>

Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Name Context (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>

Subcomponents for DEPRECATED-Name Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>

Note subcomponent contains sub-subcomponents

Subcomponents for Effective Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Expiration Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>

Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>

Definition: This field is defined as conditional because it is required when the substance requested is a controlled substance (e.g., a narcotic).

4.14.4.14 RXE-14 Pharmacist/Treatment Supplier's Verifier ID (XCN) 00306

Components: <ID Number (ST)> ^ <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR) (ST)> ^ <DEPRECATED-Degree (e.g., MD) (IS)> ^ <Source Table (IS)> ^ <Assigning Authority (HD)> ^ <Name Type Code (ID)> ^ <Identifier Check Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name Representation Code (ID)> ^ <Name Context (CE)> ^ <DEPRECATED-Name Validity Range (DR)> ^ <Name Assembly Order (ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^ <Professional Suffix (ST)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or Department (CWE)>

Subcomponents for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname (ST)> & <Surname Prefix From Partner/Spouse (ST)> & <Surname From Partner/Spouse (ST)>

Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Name Context (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>

Subcomponents for DEPRECATED-Name Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>

Note subcomponent contains sub-subcomponents

Subcomponents for Effective Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Expiration Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>

Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>

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

4.14.4.15 RXE-15 Prescription Number (ST) 00325

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

4.14.4.16 RXE-16 Number of Refills Remaining (NM) 00326

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.

4.14.4.17 RXE-17 Number of Refills/Doses Dispensed (NM) 00327

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.

4.14.4.18 RXE-18 D/T of Most Recent Refill or Dose Dispensed (TS) 00328

Components: <Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>

Definition: Date/time of the most recent refill or dose dispensed.

4.14.4.19 RXE-19 Total Daily Dose (CQ) 00329

Components: <Quantity (NM)> ^ <Units (CE)>

Subcomponents for Units (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>

Definition: This field contains the total daily dose for this particular pharmaceutical as expressed in terms of actual dispense units.

4.14.4.20 RXE-20 Needs Human Review (ID) 00307

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.

4.14.4.21 RXE-21 Pharmacy/Treatment Supplier's Special Dispensing Instructions (CE) 00330

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: This field contains the pharmacy or treatment supplier's provider-generated special instructions to the provider dispensing/administering the order.

4.14.4.22 RXE-22 Give Per (Time Unit) (ST) 00331

Definition: This field contains the time unit to use to calculate the rate at which the pharmaceutical is to be administered.

Format:

S = seconds
M = minutes
H = hours
D = days
W = weeks
L = months
T = at the interval and amount stated until a total of "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.

4.14.4.23 RXE-23 Give Rate Amount (ST) 00332

Definition: This field contains the rate at which the substance should be administered.

4.14.4.24 RXE-24 Give Rate Units (CE) 00333

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

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-9 in Chapter 7 for possible compound units codes.)

4.14.4.25 RXE-25 Give Strength (NM) 01126

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.

4.14.4.26 RXE-26 Give Strength Units (CE) 01127

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

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 (micg/h) is an acceptable value. These compound units are contained in the ISO+ table. See Chapter 7 for full definition of ISO+ units.

4.14.4.27 RXE-27 Give Indication (CE) 01128

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: This field identifies the condition or problem for which the drug/treatment was prescribed. May repeat if multiple indications are relevant.

4.14.4.28 RXE-28 Dispense Package Size (NM) 01220

Definition: This field contains the size of package to be dispensed. Units are transmitted in RXE-29-dispense package size unit.

4.14.4.29 RXE-29 Dispense Package Size Unit (CE) 01221

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: This field contains the units in which RXE-28-dispense package size is denominated.

4.14.4.30 RXE-30 Dispense Package Method (ID) 01222

Definition: This field contains the method by which treatment is dispensed. Refer To HL7 Table 0321 - Dispense Method for valid values.

HL7 Table 0321 - Dispense Method

Value Description Comment
TR Traditional
UD Unit Dose
F Floor Stock
AD Automatic Dispensing

4.14.4.31 RXE-31 Supplementary Code (CE) 01476

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

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

4.14.4.32 RXE-32 Original Order Date/Time (TS) 01673

Components: <Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>

Definition: This field contains the date/time of the original order (ORC-9) when a refill authorization is being requested. This was represented in the ORC-9 of the original order transaction.

4.14.4.33 RXE-33 Give Drug Strength Volume (NM) 01674

Description: This numeric field defines the volume measurement in which the drug strength concentration is contained. For example, Acetaminophen 120 MG/5ML Elixir means that 120 MG of the drug is in a solution with a volume of 5 ML, which would be encoded in RXE-25, RXE-26, RXE-33 and RXE-34 as

RXE|||||||||||||||||||||||||120|mg^^ISO|||||||5|ml^^ISO _<cr>

4.14.4.34 RXE-34 Give Drug Strength Volume Units (CWE) 01675

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

Description: This field indicates the volumetric unit associated with RXE-33 Give Drug Strength Volume. See example in RXE-33.

4.14.4.35 RXE-35 Controlled Substance Schedule (CWE) 01676

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

Definition: This field specifies the class of the drug or other substance if its usage is controlled by legislation. In the USA, such legislation includes the federal Controlled Substance Act (CSA) or a State Uniform Controlled Substance Act. Refer to user-defined table 0477 _ Controlled Substance Schedule for valid values for USA usage. Other countries should create their own versions of this table.

Because some jurisdictions may extend the list of drugs in a particular class and may create an additional schedule, table 0477 is user-defined.

User-defined Table 0477 _ Controlled Substance Schedule*

Value Description Comment
I Schedule I Includes drugs that have a high potential for abuse, no currently accepted medical use in the United States and a lack of accepted safety for use under medical supervision.
II Schedule II Includes drugs having currently accepted medical use in the United States and a high abuse potential, with severe psychological or physical dependence liability.
III Schedule III Includes drugs having an abuse potential less than that of drugs listed in Schedules I and II. All CS III drugs have a currently accepted medical use in the United States.
IV Schedule IV Includes drugs having a lesser potential for abuse than those listed in Schedule III. CS IV drugs have a currently accepted medical use in the United States.
V Schedule V Includes drugs having low abuse potential and limited physical or psychological dependence relative to those listed in IV and have an accepted medical use in the United States.
VI Schedule VI State defined

*Pharmacy Law Digest July 1988

4.14.4.36 RXE-36 Formulary Status (ID) 01677

Definition: This field specifies whether or not the pharmaceutical substance is part of the local formulary. Refer to HL7 table 0478 - Formulary Status for valid values.

HL7 Table 0478 _ Formulary Status

Value Description Comment
Y Pharmaceutical substance is in the formulary
N Pharmaceutical substance is NOT in the formulary
R Pharmaceutical substance is in the formulary, but restrictions apply
G Pharmaceutical substance is in the formulary, but guidelines apply

4.14.4.37 RXE-37 Pharmaceutical Substance Alternative (CWE) 01678

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

Definition: This field specifies a pharmaceutical substance that is in the formulary that could be prescribed in lieu of the substance being prescribed. In the case where the specified medication is non-formulary this field would contain therapeutic alternatives that are on the formulary.

4.14.4.38 RXE-38 Pharmacy of Most Recent Fill (CWE) 01679

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

Definition: This field specifies the pharmacy that last filled the prescription.

4.14.4.39 RXE-39 Initial Dispense Amount (NM) 01680

Definition: This field specifies the quantity dispensed on the original fill (first fill) of a prescription when that amount is not the same as the quantity to be used in refills. One use case is when a new medication is being prescribed and the prescriber wants to determine if the patient will tolerate the medication. The prescriber indicates that the medication should be filled for an initial amount of 30 tablets and, if tolerated, refilled using a quantity of 100 tablets. In this case, RXE-39 would contain 30 and RXE-10 would contain 100.

If this field is not populated, then the initial dispense amount is the same as RXE-10.

The units are identified in RXE-11.

4.14.4.40 RXE-40 Dispensing Pharmacy (CWE) 01681

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

Definition: This field specifies the pharmacy that will dispense the prescription.

4.14.4.41 RXE-41 Dispensing Pharmacy Address (XAD) 01682

Components: <Street Address (SAD)> ^ <Other Designation (ST)> ^ <City (ST)> ^ <State or Province (ST)> ^ <Zip or Postal Code (ST)> ^ <Country (ID)> ^ <Address Type (ID)> ^ <Other Geographic Designation (ST)> ^ <County/Parish Code (IS)> ^ <Census Tract (IS)> ^ <Address Representation Code (ID)> ^ <DEPRECATED-Address Validity Range (DR)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)>

Subcomponents for Street Address (SAD): <Street or Mailing Address (ST)> & <Street Name (ST)> & <Dwelling Number (ST)>

Subcomponents for DEPRECATED-Address Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>

Note subcomponent contains sub-subcomponents

Subcomponents for Effective Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Expiration Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Definition: This field specifies the address of the dispensing facility.

4.14.4.42 RXE-42 Deliver-to patient location (PL) 01683

Components: <Point of Care (IS)> ^ <Room (IS)> ^ <Bed (IS)> ^ <Facility (HD)> ^ <Location Status (IS)> ^ <Person Location Type (IS)> ^ <Building (IS)> ^ <Floor (IS)> ^ <Location Description (ST)> ^ <Comprehensive Location Identifier (EI)> ^ <Assigning Authority for Location (HD)>

Subcomponents for Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Comprehensive Location Identifier (EI): <Entity Identifier (ST)> & <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Assigning Authority for Location (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Definition: This field specifies the location of the patient to whom the pharmaceutical substance is to be delivered.

4.14.4.43 RXE-43 Deliver-to Address (XAD) 01684

Components: <Street Address (SAD)> ^ <Other Designation (ST)> ^ <City (ST)> ^ <State or Province (ST)> ^ <Zip or Postal Code (ST)> ^ <Country (ID)> ^ <Address Type (ID)> ^ <Other Geographic Designation (ST)> ^ <County/Parish Code (IS)> ^ <Census Tract (IS)> ^ <Address Representation Code (ID)> ^ <DEPRECATED-Address Validity Range (DR)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)>

Subcomponents for Street Address (SAD): <Street or Mailing Address (ST)> & <Street Name (ST)> & <Dwelling Number (ST)>

Subcomponents for DEPRECATED-Address Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>

Note subcomponent contains sub-subcomponents

Subcomponents for Effective Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Expiration Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Definition: This field specifies the address, either mailing or physical, to which the prescription should be mailed or delivered.

4.14.4.44 RXE-44 Pharmacy Order Type (ID) 01685

Definition: The Pharmacy Order Type field defines the general category of pharmacy order which may be used to determine the processing path the order will take. Refer to HL7 Table 0480 Pharmacy Order Types for valid values.

This field may also be used for grouping of related orders for processing and/or reports. For example, Medication Administration Records (MARs) often group large volume solutions, medications and small volume solutions differently based upon site-specific workflow.

Usage Rule: This field is optional for all Pharmacy transactions. When not populated, a default value of "M" is assumed.

4.14.5 RXD - Pharmacy/Treatment Dispense Segment

HL7 Attribute Table _ RXD _ Pharmacy/Treatment Dispense

SEQ LEN DT OPT RP/# TBL# ITEM # ELEMENT NAME DB Ref.
1 4 NM R

00334 Dispense Sub-ID Counter DB
2 250 CE R
0292 00335 Dispense/Give Code DB
3 26 TS R

00336 Date/Time Dispensed DB
4 20 NM R

00337 Actual Dispense Amount DB
5 250 CE C

00338 Actual Dispense Units DB
6 250 CE O

00339 Actual Dosage Form DB
7 20 ST R

00325 Prescription Number DB
8 20 NM C

00326 Number of Refills Remaining DB
9 200 ST O Y
00340 Dispense Notes DB
10 200 XCN O Y
00341 Dispensing Provider DB
11 1 ID O
0167 00322 Substitution Status DB
12 10 CQ O

00329 Total Daily Dose DB
13 200 LA2 C

01303 Dispense-to Location DB
14 1 ID O
0136 00307 Needs Human Review DB
15 250 CE O Y
00330 Pharmacy/Treatment Supplier's Special Dispensing Instructions DB
16 20 NM O

01132 Actual Strength DB
17 250 CE O

01133 Actual Strength Unit DB
18 20 ST O Y
01129 Substance Lot Number DB
19 26 TS O Y
01130 Substance Expiration Date DB
20 250 CE O Y 0227 01131 Substance Manufacturer Name DB
21 250 CE O Y
01123 Indication DB
22 20 NM O

01220 Dispense Package Size DB
23 250 CE O

01221 Dispense Package Size Unit DB
24 2 ID O
0321 01222 Dispense Package Method DB
25 250 CE O Y
01476 Supplementary Code DB
26 250 CE O

01477 Initiating Location DB
27 250 CE O

01478 Packaging/Assembly Location DB
28 5 NM O

01686 Actual Drug Strength Volume DB
29 250 CWE O

01687 Actual Drug Strength Volume Units DB
30 180 CWE O

01688 Dispense to Pharmacy DB
31 106 XAD O

01689 Dispense to Pharmacy Address DB
32 1 ID O
0480 01690 Pharmacy Order Type DB
33 250 CWE O
0484 01691 Dispense Type DB

4.14.5.0 RXD field definitions

4.14.5.1 RXD-1 Dispense sub-ID counter (NM) 00334

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.

4.14.5.2 RXD-2 Dispense/Give Code (CE) 00335

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

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.

4.14.5.3 RXD-3 Date/Time Dispensed (TS) 00336

Components: <Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>

Definition: This field indicates when the pharmaceutical/treatment is dispensed from the pharmacy or treatment supplier. Use the time stamp format.

4.14.5.4 RXD-4 Actual Dispense Amount (NM) 00337

Definition: This field indicates the amount dispensed.

4.14.5.5 RXD-5 Actual Dispense Units (CE) 00338

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

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.

4.14.5.6 RXD-6 Actual Dosage Form (CE) 00339

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

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.

4.14.5.7 RXD-7 Prescription Number (ST) 00325

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.

4.14.5.8 RXD-8 Number of Refills Remaining (NM) 00326

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.

4.14.5.9 RXD-9 Dispense Notes (ST) 00340

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.

4.14.5.10 RXD-10 Dispensing Provider (XCN) 00341

Components: <ID Number (ST)> ^ <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR) (ST)> ^ <DEPRECATED-Degree (e.g., MD) (IS)> ^ <Source Table (IS)> ^ <Assigning Authority (HD)> ^ <Name Type Code (ID)> ^ <Identifier Check Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name Representation Code (ID)> ^ <Name Context (CE)> ^ <DEPRECATED-Name Validity Range (DR)> ^ <Name Assembly Order (ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^ <Professional Suffix (ST)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or Department (CWE)>

Subcomponents for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname (ST)> & <Surname Prefix From Partner/Spouse (ST)> & <Surname From Partner/Spouse (ST)>

Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Name Context (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>

Subcomponents for DEPRECATED-Name Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>

Note subcomponent contains sub-subcomponents

Subcomponents for Effective Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Expiration Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>

Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>

Definition: This field contains the provider ID of the person dispensing the pharmaceutical.

4.14.5.11 RXD-11 Substitution Status (ID) 00322

Definition: Refer to HL7 Table 0167 - Substitution Status for suggested values.

4.14.5.12 RXD-12 Total Daily Dose (CQ) 00329

Components: <Quantity (NM)> ^ <Units (CE)>

Subcomponents for Units (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>

Definition: This field contains the total daily dose being dispensed as expressed in terms of the actual dispense units.

Note: The next two fields are equivalent to the corresponding fields of the RXE segment. They are included (optionally) in the RXD so that it may "stand alone" as a dispense result instruction segment.

4.14.5.13 RXD-13 Dispense-to Location (LA2) 01303

Components: <Point of Care (IS)> ^ <Room (IS)> ^ <Bed (IS)> ^ <Facility (HD)> ^ <Location Status (IS)> ^ <Patient Location Type (IS)> ^ <Building (IS)> ^ <Floor (IS)> ^ <Street Address (ST)> ^ <Other Designation (ST)> ^ <City (ST)> ^ <State or Province (ST)> ^ <Zip or Postal Code (ST)> ^ <Country (ID)> ^ <Address Type (ID)> ^ <Other Geographic Designation (ST)>

Subcomponents for Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Definition: The first component (which is of PL data type with the component delimiters demoted to subcomponents) contains the inpatient or outpatient location where the drug or treatment was dispensed (if applicable). The default (null) value is the current census location for the patient. Site-specific table. The first eight components have the same form as the first eight components of PV1-3-Assigned Patient Location. The final eight components replace the ninth component of PV1-3-Assigned Patient Location and represent the full address specification.

4.14.5.14 RXD-14 Needs Human Review (ID) 00307

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.

4.14.5.15 RXD-15 Pharmacy/Treatment Supplier's Special Dispensing Instructions (CE) 00330

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: This field contains pharmacy or treatment supplier-generated special instructions to the provider dispensing/administering the order.

4.14.5.16 RXD-16 Actual Strength (NM) 01132

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.

4.14.5.17 RXD-17 Actual Strength Unit (CE) 01133

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

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 (micg/h) is an acceptable value. These compound units are contained in the ISO+ table. See Chapter 7 for full definition of ISO+ units.

4.14.5.18 RXD-18 Substance Lot Number (ST) 01129

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.

4.14.5.19 RXD-19 Substance Expiration Date (TS) 01130

Components: <Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>

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.

4.14.5.20 RXD-20 Substance Manufacturer Name (CE) 01131

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

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.

4.14.5.21 RXD-21 Indication (CE) 01123

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

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.

4.14.5.22 RXD-22 Dispense Package Size (NM) 01220

Definition: This field contains the size of package to be dispensed. Units are transmitted in RXD-23-dispense package size unit.

4.14.5.23 RXD-23 Dispense Package Size Unit (CE) 01221

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

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

4.14.5.24 RXD-24 Dispense Package Method (ID) 01222

Definition: This field contains the method by which treatment is dispensed. Refer To HL7 Table 0321 - Dispense Method for valid values.

4.14.5.25 RXD-25 Supplementary code (CE) 01476

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

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

4.14.5.26 RXD-26 Initiating Location (CE) 01477

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

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.

4.14.5.27 RXD-27 Packaging/Assembly Location (CE) 01478

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: This field identifies the pharmacy which packaged/assembled request.

4.14.5.28 RXD-28 Actual Drug Strength Volume (NM) 01686

Description: This numeric field defines the volume measurement in which the drug strength concentration is contained. For example, Acetaminophen 120 MG/5ML Elixir means that 120 MG of the drug is in a solution with a volume of 5 ML , which would be encoded in RXD-16, RXD-17, RXD-28 and RXD-29 as

RXD||||||||||||||||120|mg^^ISO|||||||||||5|ml^^ISO _<cr>

4.14.5.29 RXD-29 Actual Drug Strength Volume Units (CWE) 01687

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

Description: This field indicates the volumetric unit associated with RXD-28 Actual Drug Strength Volume. See example in RXD-28.

4.14.5.30 RXD-30 Dispense to Pharmacy (CWE) 01688

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

Definition: This field specifies the pharmacy that will dispense the prescription.

4.14.5.31 RXD-31 Dispense to Pharmacy Address (XAD) 01689

Components: <Street Address (SAD)> ^ <Other Designation (ST)> ^ <City (ST)> ^ <State or Province (ST)> ^ <Zip or Postal Code (ST)> ^ <Country (ID)> ^ <Address Type (ID)> ^ <Other Geographic Designation (ST)> ^ <County/Parish Code (IS)> ^ <Census Tract (IS)> ^ <Address Representation Code (ID)> ^ <DEPRECATED-Address Validity Range (DR)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)>

Subcomponents for Street Address (SAD): <Street or Mailing Address (ST)> & <Street Name (ST)> & <Dwelling Number (ST)>

Subcomponents for DEPRECATED-Address Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>

Note subcomponent contains sub-subcomponents

Subcomponents for Effective Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Expiration Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Definition: This field specifies the address of the dispensing facility or the patient's location where the dispensing will occur.

4.14.5.32 RXD-32 Pharmacy Order Type (ID) 01690

Definition: The Pharmacy Order Type field defines the general category of pharmacy order which may be used to determine the processing path the order will take. Refer to HL7 Table 0480 Pharmacy Order Types for valid values.

This field may also be used for grouping of related orders for processing and/or reports. For example, Medication Administration Records (MARs) often group large volume solutions, medications and small volume solutions differently based upon site-specific workflow.

Usage Rule: This field is optional for all Pharmacy transactions. When not populated, a default value of "M" is assumed.

4.14.5.33 RXD-33 Dispense Type (CWE) 01691

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

Definition: This is the type of dispensing event that occurred. Refer to User-defined Table 0484 _ Dispense Type for suggested values.

User-defined Table 0484 _ Dispense Type

Value Description Comment
B Trial Quantity Balance
C Compassionate Fill
N New/Renew - Full Fill
P New/Renew - Part Fill
Q Refill - Part Fill
R Refill - Full Fill
S Manufacturer Sample
T Trial Quantity
Z Non-Prescription Fill

4.14.6 RXG - Pharmacy/Treatment Give Segment

HL7 Attribute Table _ RXG _ Pharmacy/Treatment Give

SEQ LEN DT OPT RP/# TBL# ITEM # ELEMENT NAME DB Ref.
1 4 NM R

00342 Give Sub-ID Counter DB
2 4 NM O

00334 Dispense Sub-ID Counter DB
3 200 TQ B

00221 Quantity/Timing DB
4 250 CE R
0292 00317 Give Code DB
5 20 NM R

00318 Give Amount - Minimum DB
6 20 NM O

00319 Give Amount - Maximum DB
7 250 CE R

00320 Give Units DB
8 250 CE O

00321 Give Dosage Form DB
9 250 CE O Y
00351 Administration Notes DB
10 1 ID O
0167 00322 Substitution Status DB
11 200 LA2 O

01303 Dispense-To Location DB
12 1 ID O
0136 00307 Needs Human Review DB
13 250 CE O Y
00343 Pharmacy/Treatment Supplier's Special Administration Instructions DB
14 20 ST C

00331 Give Per (Time Unit) DB
15 6 ST O

00332 Give Rate Amount DB
16 250 CE O

00333 Give Rate Units DB
17 20 NM O

01126 Give Strength DB
18 250 CE O

01127 Give Strength Units DB
19 20 ST O Y
01129 Substance Lot Number DB
20 26 TS O Y
01130 Substance Expiration Date DB
21 250 CE O Y 0227 01131 Substance Manufacturer Name DB
22 250 CE O Y
01123 Indication DB
23 5 NM O

01692 Give Drug Strength Volume DB
24 250 CWE O

01693 Give Drug Strength Volume Units DB
25 60 CWE O

01694 Give Barcode Identifier DB
26 1 ID O
0480 01695 Pharmacy Order Type DB

4.14.6.0 RXG fields definitions

4.14.6.1 RXG-1 Give Sub-ID Counter (NM) 00342

Definition: Use if this RXG segment carries information about a single administration. This field must contain a unique number for the placer order number. This field along with the placer order number provides a unique reference to the specific scheduled give date/time transmitted by the pharmacy/treatment supplier 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.

4.14.6.2 RXG-2 Dispense Sub-ID Counter (NM) 00334

Definition: This is the dispense sub-ID to which this give message is related.

4.14.6.3 RXG-3 Quantity/Timing (TQ) 00221

Components: <Quantity (CQ)> ^ <Interval (RI)> ^ <Duration (ST)> ^ <Start Date/Time (TS)> ^ <End Date/Time (TS)> ^ <Priority (ST)> ^ <Condition (ST)> ^ <Text (TX)> ^ <Conjunction (ID)> ^ <Order Sequencing (OSD)> ^ <Occurrence Duration (CE)> ^ <Total Occurrences (NM)>

Subcomponents for Quantity (CQ): <Quantity (NM)> & <Units (CE)>

Note subcomponent contains sub-subcomponents

Subcomponents for Interval (RI): <Repeat Pattern (IS)> & <Explicit Time Interval (ST)>

Subcomponents for Start Date/Time (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for End Date/Time (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Order Sequencing (OSD): <Sequence/Results Flag (ID)> & <Placer Order Number: Entity Identifier (ST)> & <Placer Order Number: Namespace ID (IS)> & <Filler Order Number: Entity Identifier (ST)> & <Filler Order Number: Namespace ID (IS)> & <Sequence Condition Value (ST)> & <Maximum Number of Repeats (NM)> & <Placer Order Number: Universal ID (ST)> & <Placer Order Number: Universal ID Type (ID)> & <Filler Order Number: Universal ID (ST)> & <Filler Order Number: Universal ID Type (ID)>

Subcomponents for Occurrence Duration (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>

Definition: This field is retained for backward compatibility only. The reader is referred to the TQ1 and TQ2 segments described in sections 4.5.4 and 4.5.5 respectively.

This field contains the quantity/timing specification that refers to either a single scheduled give instruction only or to multiple give instructions. In the former case, RXG-1-give sub-ID counter is a positive integer greater than or equal to one (1). In the latter case, RXG-1-give sub-ID counter is zero (0). The quantity will always be 1. This quantity/timing field may differ from the ORC quantity/timing field, which contains the requested quantity/timing of the original order.

Note: The contents of fields 3-8 should be identical to the comparable fields in the RXE (RXE-2 thru 5).

4.14.6.4 RXG-4 Give Code (CE) 00317

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: This field is the identifier of the medical substance/treatment ordered to be given to the patient; it is equivalent to OBR-4-Universal service ID in function. See the RXE segment for a complete definition of the RXE-2-Give code. If the substance given is a vaccine, CVX codes may be used to code this field (see HL7 table 0292 - Vaccines administered).

4.14.6.5 RXG-5 Give Amount _ Minimum (NM) 00318

Definition: This field contains the ordered amount as encoded by the pharmacy/treatment supplier. In a variable dose order, this is the minimum ordered amount. In a nonvarying dose order, this is the exact amount of the order.

Note: This field is not a duplication of the first component of the quantity/timing field, since in non-pharmacy/treatment orders, that component can be used to specify multiples of an ordered amount.

Another way to say this is that, for pharmacy/treatment orders, the quantity component of the quantity/timing field refers to what is to be given out at each service interval; and thus, in terms of the RX order, that first component always defaults to 1. Hence, in the actual execution of the order, the value of 1 in the first component of the quantity/timing field always refers to one administration of the amount specified in this field (the requested Give Amount field).

4.14.6.6 RXG-6 Give Amount - Maximum (NM) 00319

Definition: In a variable dose order, this is the maximum ordered amount. In a nonvarying dose order, this field is not used.

4.14.6.7 RXG-7 Give Units (CE) 00320

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: This field contains the units for the give amount.

Note: These units can be a "compound quantity;" i.e., the units may contain the word "per." For example, micrograms per KG (micg/kg) is an acceptable value, which means that the units are micrograms per KG (of body weight).

A table of standard units that contains compound units is needed. Until such a table is agreed on, a user-defined table is needed for each site.

4.14.6.8 RXG-8 Give Dosage Form (CE) 00321

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: The dosage form indicates the manner in which the medication/treatment is aggregated for dispensing, e.g., tablets, capsules, suppositories. In some cases, this information is implied by the give code in RXG-4-Give Code. Use this field when the give code does not specify the dosage form.

4.14.6.9 RXG-9 Administration Notes (CE) 00351

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: This field contains notes to the person administering the medication/treatment (may include the ordering provider's original notes, as well as any notes from the formulary or the pharmacy or treatment supplier). If coded, a user-defined table must be used. If free text, place a null in the first component and the text in the second, e.g., |^this is a free text administration note|.

4.14.6.10 RXG-10 Substitution Status (ID) 00322

Definition: Refer to HL7 Table 0167 - Substitution Status for valid values.

Note: The next two fields are equivalent to the corresponding fields of the RXE segment. They are included (optionally) in the RXG so that it may "stand alone" as a "give" instruction segment.

4.14.6.11 RXG-11 Dispense-to Location (LA2) 01303

Components: <Point of Care (IS)> ^ <Room (IS)> ^ <Bed (IS)> ^ <Facility (HD)> ^ <Location Status (IS)> ^ <Patient Location Type (IS)> ^ <Building (IS)> ^ <Floor (IS)> ^ <Street Address (ST)> ^ <Other Designation (ST)> ^ <City (ST)> ^ <State or Province (ST)> ^ <Zip or Postal Code (ST)> ^ <Country (ID)> ^ <Address Type (ID)> ^ <Other Geographic Designation (ST)>

Subcomponents for Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Definition: The first component contains the inpatient or outpatient location where the drug or treatment was dispensed (if applicable). The default (null) value is the current census location for the patient. Site-specific table. The first eight components have the same form as the first eight components of PV1-3-assigned patient location. The final eight components replace the ninth component of PV1-3-assigned patient location and represent the full address specification.

4.14.6.12 RXG-12 Needs Human Review (ID) 00307

Definition: Refer to HL7 Table 0136 - Yes/No Indicator for valid values. The values have the following meaning for this field:

Y Yes - Indicates that a warning is present. The application receiving the dispense order needs to warn the person dispensing/administering the drug or treatment to pay attention to the text in RXG-13-pharmacy/treatment supplier's special administration instructions.

N No - Indicates no warning is present. This is the equivalent default (null) value.

4.14.6.13 RXG-13 Pharmacy/Treatment Supplier's Special Administration Instructions (CE) 00343

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: This field contains pharmacy/treatment supplier-generated special instructions to the provider administering the order.

4.14.6.14 RXG-14 Give Per (Time Unit) (ST) 00331

Definition: This field contains the time unit to use to calculate the rate at which the pharmaceutical/treatment is to be administered.

Format:

S = seconds
M = minutes
H = hours
D = days
W = weeks
L = months
T = at the interval and amount stated until a total of "DOSAGE" is accumulated. Units would be assumed to be the same as in the QUANTITY field.
INDEF = do indefinitely - also the default

This is the same as the format specified for the DURATION component of the quantity/timing field, excluding the "X" specification.

Required when relevant (e.g., certain IVs). For example, if the "give amount/units" were 300 ml and the "give per" time unit were H1 (equivalent to one hour), the rate is 300ml/hr.

4.14.6.15 RXG-15 Give Rate Amount (ST) 00332

Definition: This field contains the amount (number) of substance/treatment to be administered.

4.14.6.16 RXG-16 Give Rate Units (CE) 00333

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: This field contains the units for RXG-15-give rate amount. May be composite. The ratio of the RXG-15-give rate amount and RXG-16-give rate units fields define the actual rate of administration. Thus, if RXG-15-give rate amount = 100 and RXG-16-give rate units = ml/hr, the requested rate of administration is 100 ml/hr.

4.14.6.17 RXG-17 Give Strength (NM) 01126

Definition: Use when RXG-4-Give code does not specify the strength. This is the numeric part of the strength, used in combination with RXG-18-Give strength units.

4.14.6.18 RXG-18 Give Strength Units (CE) 01127

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: Use when RXG-4-Give Code does not specify the strength. This is the unit of the strength, used in combination with RXG-17-Give Strength.

Note: These units can be a "compound quantity"; i.e., the units may express a quantity per unit of time. For example, micrograms per hour (micg/h) is an acceptable value. These compound units are contained in the ISO+ table. See Chapter 7 for full definition of ISO+ units.

4.14.6.19 RXG-19 Substance Lot Number (ST) 01129

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.

4.14.6.20 RXG-20 Substance Expiration Date (TS) 01130

Components: <Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>

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.

4.14.6.21 RXG-21 Substance Manufacturer Name (CE) 01131

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: This field contains the manufacturer of the medical substance administered.

Note: For vaccines, code system MVX may be used to code this field (see Section 4.17.1, "Vaccine administration data"). This field may be used if the manufacturer of the substance is not identified by the code used in RXA-5-administered code.

4.14.6.22 RXG-22 Indication (CE) 01123

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

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.

4.14.6.23 RXG-23 Give Drug Strength Volume (NM) 01692

Description: This numeric field defines the volume measurement in which the drug strength concentration is contained. For example, Acetaminophen 120 MG/5ML Elixir means that 120 MG of the drug is in a solution with a volume of 5 ML, which would be encoded in RXG-17, RXG-18, RXG-23 and RXG-24 as

RXG|||||||||||||||||120|mg^^ISO|||||5|ml^^ISO _<cr>

4.14.6.24 RXG-24 Give Drug Strength Volume Units (CWE) 01693

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

Description: This field indicates the volumetric unit associated with RXG-23 Give Drug Strength Volume. See example in RXG-23.

4.14.6.25 RXG-25 Give Barcode Identifier (CWE) 01694

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

Definition: This field contains the pharmacy system's assigned barcode number for the give occurrence. For IV orders, many pharmacy systems generate a barcode number to identify a specific bag/bottle of the order. This number can be an instance identifier; unique for the patient, drug combination, and schedule instance or it may be just a drug identifier.

The composition and use of the barcode number is dependent on application negotiation. An example of this field follows: The barcode number is in the following format, 9XXXXXXX000. The number '9' is a constant, XXXXXXX is seven (7) characters for a unique identifier assigned or derived from the patient account and order ID and 000 is the zero-filled three (3) character IV bottle number.

The maximum length of the first component of this field is 40 characters to allow for the maximum existing barcode length in use today. The second component contains the description of the item being coded and the third component may define the barcode type.

12345678901^IV bottle^3X9

4.14.6.26 RXG-26 Pharmacy Order Type (ID) 01695

Definition: The Pharmacy Order Type field defines the general category of pharmacy order which may be used to determine the processing path the order will take. Refer to HL7 Table 0480 Pharmacy Order Types for valid values.

This field may also be used for grouping of related orders for processing and/or reports. For example, Medication Administration Records (MARs) often group large volume solutions, medications and small volume solutions differently based upon site-specific workflow.

Usage Rule: This field is optional for all Pharmacy transactions. When not populated, a default value of "M" is assumed.

4.14.7 RXA - Pharmacy/Treatment Administration Segment

The ORC must have the filler order number and the order control code RE. As a site-specific variant, the RXO and associated RXCs and/or the RXE (and associated RXCs) may be present if the receiving application needs any of their data. The RXA carries the administration data.

HL7 Attribute Table _ RXA _ Pharmacy/Treatment Administration

SEQ LEN DT OPT RP/# TBL# ITEM # ELEMENT NAME DB Ref.
1 4 NM R

00342 Give Sub-ID Counter DB
2 4 NM R

00344 Administration Sub-ID Counter DB
3 26 TS R

00345 Date/Time Start of Administration DB
4 26 TS R

00346 Date/Time End of Administration DB
5 250 CE R
0292 00347 Administered Code DB
6 20 NM R

00348 Administered Amount DB
7 250 CE C

00349 Administered Units DB
8 250 CE O

00350 Administered Dosage Form DB
9 250 CE O Y
00351 Administration Notes DB
10 250 XCN O Y
00352 Administering Provider DB
11 200 LA2 C

00353 Administered-at Location DB
12 20 ST C

00354 Administered Per (Time Unit) DB
13 20 NM O

01134 Administered Strength DB
14 250 CE O

01135 Administered Strength Units DB
15 20 ST O Y
01129 Substance Lot Number DB
16 26 TS O Y
01130 Substance Expiration Date DB
17 250 CE O Y 0227 01131 Substance Manufacturer Name DB
18 250 CE O Y
01136 Substance/Treatment Refusal Reason DB
19 250 CE O Y
01123 Indication DB
20 2 ID O
0322 01223 Completion Status DB
21 2 ID O
0323 01224 Action Code _ RXA DB
22 26 TS O

01225 System Entry Date/Time DB
23 5 NM O

01696 Administered Drug Strength Volume DB
24 250 CWE O

01697 Administered Drug Strength Volume Units DB
25 60 CWE O

01698 Administered Barcode Identifier DB
26 1 ID O
0480 01699 Pharmacy Order Type DB

4.14.7.0 RXA field definitions

4.14.7.1 RXA-1 Give Sub-ID Counter (NM) 00342

Definition: Use this field if matching this RXA segment to its corresponding RXG segment. If the two applications are not matching RXG and RXA segments, this field's value is zero (0).

4.14.7.2 RXA-2 Administration Sub-ID Counter (NM) 00344

Definition: This field starts with 1 the first time that medication/treatment is administered for this order. Increments by one with each additional administration the medication/treatment.

Note: More than one RXA segment can be "matched" to a single RXG segment, as is the case when recording a change of the rate of administration of an IV solution.

4.14.7.3 RXA-3 Date/Time Start of Administration (TS) 00345

Components: <Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>

Definition: If the order is for a continuous administration (such as an IV), and the rate is changed at a certain time after the start, an RAS message can be issued to record the change. For such an RAS message, this field records the time the rate was changed to the new value recorded in the RXA-12-administered per (time unit) of the same message.

4.14.7.4 RXA-4 Date/Time End of Administration (If Applies) (TS) 00346

Components: <Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>

Definition: If null, the date/time of RXA-3-Date/Time Start of Administration is assumed.

4.14.7.5 RXA-5 Administered Code (CE) 00347

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: This field contains the identifier of the medical substance/treatment administered. It is equivalent to OBR-4-universal service ID in function. If the substance administered is a vaccine, CVX codes may be used to code this field (see HL7 Table 0292 - Vaccines Administered).

4.14.7.6 RXA-6 Administered Amount (NM) 00348

Definition: This field contains the amount administered.

4.14.7.7 RXA-7 Administered units (CE) 00349

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: This field is conditional because it is required if the administered amount code does not imply units. This field must be in simple units that reflect the actual quantity of the substance administered. It does not include compound units.

4.14.7.8 RXA-8 Administered Dosage Form (CE) 00350

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: The dosage form indicates the manner in which the medication/treatment is aggregated for dispensing, e.g., tablets, capsules, suppositories. In some cases, this information is implied by the dispense/give code in RXA-5-Administered Code. Use this field when the administered code does not specify the dosage form.

4.14.7.9 RXA-9 Administration Notes (CE) 00351

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: This field contains notes from the provider administering the medication/treatment. If coded, requires a user-defined table. If free text (describing a custom IV, mixture, or salve, for example) place a null in the first component and the text in the second, e.g., |^this is a free text administration note|.

4.14.7.10 RXA-10 Administering Provider (XCN) 00352

Components: <ID Number (ST)> ^ <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR) (ST)> ^ <DEPRECATED-Degree (e.g., MD) (IS)> ^ <Source Table (IS)> ^ <Assigning Authority (HD)> ^ <Name Type Code (ID)> ^ <Identifier Check Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name Representation Code (ID)> ^ <Name Context (CE)> ^ <DEPRECATED-Name Validity Range (DR)> ^ <Name Assembly Order (ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^ <Professional Suffix (ST)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or Department (CWE)>

Subcomponents for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname (ST)> & <Surname Prefix From Partner/Spouse (ST)> & <Surname From Partner/Spouse (ST)>

Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Name Context (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>

Subcomponents for DEPRECATED-Name Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>

Note subcomponent contains sub-subcomponents

Subcomponents for Effective Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Expiration Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>

Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>

Definition: This field contains the provider ID of the person administering the pharmaceutical/treatment.

4.14.7.11 RXA-11 Administered-at Location (LA2) 00353

Components: <Point of Care (IS)> ^ <Room (IS)> ^ <Bed (IS)> ^ <Facility (HD)> ^ <Location Status (IS)> ^ <Patient Location Type (IS)> ^ <Building (IS)> ^ <Floor (IS)> ^ <Street Address (ST)> ^ <Other Designation (ST)> ^ <City (ST)> ^ <State or Province (ST)> ^ <Zip or Postal Code (ST)> ^ <Country (ID)> ^ <Address Type (ID)> ^ <Other Geographic Designation (ST)>

Subcomponents for Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Definition: The first component contains the inpatient or outpatient location at which the drug or treatment was administered (if applicable). The default (null) value is the current census location for the patient. Site-specific table. The first eight components have the same form as the first eight components of PV1-3-assigned patient location. The final eight components replace the ninth component of PV1-3-assigned patient location and represent the full address specification.

4.14.7.12 RXA-12 Administered Per (Time Unit) (ST) 00354

Definition: This field contains the rate at which this medication/treatment was administered as calculated by using RXA-6-administered amount and RXA-7-administered units. This field is conditional because it is required when a treatment is administered continuously at a prescribed rate, e.g., certain IV solutions.

4.14.7.13 RXA-13 Administered Strength (NM) 01134

Definition: Use when RXA-5-Administered Code does not specify the strength. This is the numeric part of the strength, used in combination with RXA-14-Administered Strength Units.

4.14.7.14 RXA-14 Administered Strength Units (CE) 01135

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: Use when RXA-5-Administered Code does not specify the strength. This is the unit of the strength, used in combination with RXA-13-Administered Strength.

Note: These units can be a "compound quantity;" i.e., the units may express a quantity per unit of time. For example, micrograms per hour (micg/h) is an acceptable value. These compound units are contained in the ISO+ table. See Chapter 7 for full definition of ISO+ units.

4.14.7.15 RXA-15 Substance Lot Number (ST) 01129

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.

4.14.7.16 RXA-16 Substance Expiration Date (TS) 01130

Components: <Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>

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.

4.14.7.17 RXA-17 Substance Manufacturer Name (CE) 01131

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: This field contains the manufacturer of the medical substance administered.

Note: For vaccines, code system MVX may be used to code this field). See Section 4.17.1. This field may be used if the manufacturer of the substance is not identified by the code used in RXA-5- administered code.

4.14.7.18 RXA-18 Substance/Treatment Refusal Reason (CE) 01136

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: This field contains the reason the patient refused the medical substance/treatment. Any entry in the field indicates that the patient did not take the substance.

4.14.7.19 RXA-19 Indication (CE) 01123

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

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.

4.14.7.20 RXA-20 Completion Status (ID) 01223

Definition: Status of treatment administration event. Refer to HL7 Table 0322 - Completion Status for valid values.

HL7 Table 0322 - Completion Status

Value Description Comment
CP Complete
RE Refused
NA Not Administered
PA Partially Administered

4.14.7.21 RXA-21 Action Code _ RXA (ID) 01224

Definition: Status of record. The information in this field enables the use of the RXA in the vaccine messages (see Section 4.18, "Vaccine Segments"), where a method of correcting vaccination information transmitted with incorrect patient identifying information is needed. Refer To HL7 Table 0323 - Action Code for valid values.

HL7 Table 0323 - Action Code

Value Description Comment
A Add
D Delete
U Update

4.14.7.22 RXA-22 System Entry Date/Time (TS) 01225

Components: <Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>

Definition: Date/time the administration information was entered into the source system. This field is used to detect instances where treatment administration information is inadvertently entered multiple times by providing a unique identification field. Under usual circumstances, this field would be provided automatically by the computer system rather than being entered by a person.

4.14.7.23 RXA-23 Administered Drug Strength Volume (NM) 01696

Description: This numeric field defines the volume measurement in which the drug strength concentration is contained. For example, Acetaminophen 120 MG/5ML Elixir means that 120 MG of the drug is in a solution with a volume of 5 ML , which would be encoded in RXA-13, RXA-14, RXA-23 and RXA-24 as

RXA|||||||||||||120|mg^^ISO|||||||||5|ml^^ISO _<cr>

4.14.7.24 RXA-24 Administered Drug Strength Volume Units (CWE) 01697

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

Description: This field indicates the volumetric unit associated with RXA-23 Administered Drug Strength Volume. See example in RXA-23.

4.14.7.25 RXA-25 Administered Barcode Identifier (CWE) 01698

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

Definition: This field contains the pharmacy system's assigned barcode number for the give occurrence. For IV orders, many pharmacy systems generate a barcode number to identify a specific bag/bottle of the order. This number can be an instance identifier; unique for the patient, drug combination, and schedule instance or it may be just a drug identifier.

The composition and use of the barcode number is dependent on application negotiation. An example of this field follows: The barcode number is in the following format, 9XXXXXXX000. The number '9' is a constant, XXXXXXX is seven (7) characters for a unique identifier assigned or derived from the patient account and order ID and 000 is the zero-filled three (3) character IV bottle number.

The maximum length of the first component of this field is 40 characters to allow for the maximum existing barcode length in use today. The second component contains the description of the item being coded and the third component may define the barcode type.

Example: 12345678901^IV bottle^3X9

4.14.7.26 RXA-26 Pharmacy Order Type (ID) 01699

Definition: The Pharmacy Order Type field defines the general category of pharmacy order which may be used to determine the processing path the order will take. Refer to HL7 Table 0480 Pharmacy Order Types for valid values.

This field may also be used for grouping of related orders for processing and/or reports. For example, Medication Administration Records (MARs) often group large volume solutions, medications and small volume solutions differently based upon site-specific workflow.

Usage Rule: This field is optional for all Pharmacy transactions. When not populated, a default value of "M" is assumed.

4.15 PHARMACY/TREATMENT MESSAGE EXAMPLES

The purpose of this section is to show how certain specific situations would be handled using the pharmacy/treatment protocol. The ellipses represent uncompleted details. The symbol // precedes comments for clarification.

4.15.1 Example of various levels of coding in an order

The order give 500 mg Ampicillin P.O. Q6H for 10 days for a total of 40 tablets is sent to the RX application from the OE application. This order can be coded with various levels of precision by an ordering application:

  1. E-mail only version (uses only free text, RXO-6-provider's pharmacy/treatment instructions or RXO-7-provider's administration instructions only); fully encoded version must be re-entered or verified manually by the pharmacy or treatment application.

  2. With RXO-2-requested give amount-minimum, RXO-4-requested give units, and ORC-7-quantity/timing coded, and RXO-1-requested give code as free text.

  3. With RXO-1-requested give code, RXO-2-requested give amount-minimum, RXO-4-requested give units, and ORC-7-quantity/timing coded, but where RXO-1-requested give code does not include units.

  4. With RXO-1-requested give code, RXO-2-requested give amount-minimum, RXO-4-requested give units, and ORC-7-quantity/timing coded, and where RXO-1-requested give code does include units.

In this case, the units are optional. The rule for this case (on orders, dispense results, give results, and administration results) is as follows: if units are coded, they override or supersede the units value implied by the give code.

  1. The E-mail only version of the order: no coded fields exist in the RXO.

MSH|^&~\|Pharm|GenHosp|CIS|GenHosp|1998052911150700||OMP^O09^OMP_O09|...<cr>

PID|...<cr>

ORC|NW|1000^OE||||E|...<cr>

RXO||||||500 mg Polycillin Q6H for 10 days, dispense 40 Tablets|...<cr>

  1. A partially coded version of the order. This version has the RXO-2-requested give amount-minimum, RXO-4-requested give units, and ORC-7-quantity/timing coded, but the RXO-1-requested give code as free text.

MSH|^&~\|Pharm|GenHosp|CIS|GenHosp|1998052911150700||OMP^O09^OMP_O09|...<cr>

PID|...<cr>

ORC|NW|1000^OE||||E|^Q6H^D10^^^R|...<cr>

RXO|^Polycillin 500 mg TAB^|500||MG|||||Y||40|...<cr>

RXR|PO|...<cr>

  1. A more completely coded version of the order, with the RXO-1-requested give code, RXO-2-requested give amount-minimum, RXO-4-requested give units, and ORC-7-quantity/timing coded, but where RXO-1-requested give code does not imply units.

MSH|^&~\|Pharm|GenHosp|CIS|GenHosp|1998052911150700||OMP^O09^OMP_O09|...<cr>

PID|...<cr>

ORC|NW|1000^OE||||E|^Q6H^D10^^^R|...<cr>

RXO|RX1001^Polycillin^L|500||MG|||||Y||40|...<cr>

RXR|PO|...<cr>

  1. A completely encoded version, with the RXO-1-requested give code, RXO-2-requested give amount-minimum, RXO-4-requested give units, and ORC-7-quantity/timing coded, and where RXO-1-requested give code does imply units.

MSH|^&~\|Pharm|GenHosp|CIS|GenHosp|1998052911150700||OMP^O09^OMP_O09|...<cr>

PID|...<cr>

ORC|NW|1000^OE||||E|^Q6H^D10^^^R|...<cr>

RXO|RX1001^Polycillin 500 mg TAB^L|500||MG|||||G||40|...<cr>

RXR|PO|...<cr>

  1. Pharmacy or treatment supplier's encoded version (RDE message) sent to nursing application (a generic substitution).

MSH|^&~\|Pharm|GenHosp|CIS|GenHosp|1998052911150700||RDE^O11^RDE_O11|...<cr>

PID|...<cr>

ORC|RE|1000^OE|9999999^RX|||E|^Q6H^D10^^^R|...<cr>

RXE|^^^199012100600^^R|0047-0402-30^Ampicillin 250 MG

TAB^NDC|2||TAB|||||G|80||||123456|rx#1001|...<cr>

RXR|PO|...<cr>

  1. Pharmacy or treatment supplier's dispense results (RDS message).

MSH|...<cr>

PID|...<cr>

ORC|RE|1000^OE|9999999^RX|||E|^Q6H^D10^^^R|...<cr>

RXD|1|0047-0402-30^Ampicillin 250 MG TAB^NDC|199012100400|8|TAB||RX#1001|||

123456|G|8|...<cr>

  1. Pharmacy or treatment supplier's give results (RGV message).

MSH|^&~\|Pharm|GenHosp|CIS|GenHosp|1998052911150700||RGV^O15^RGV_O15|...<cr>

PID|...<cr>

ORC|RE|1000^OE|9999999^RX|||E|^Q6H^D10^^^R|...<cr>

RXG|1|1|^^199012100600^^R|0047-0402-30^Ampicillin 250 MG TAB^NDC|500||MG|||G|...<cr>

RXR|PO|...<cr>

  1. Nursing application Medications Administration results to pharmacy, treatment, or Order Entry application.

MSH|^&~\|Pharm|GenHosp|CIS|GenHosp|1998052911150700||RAS^O17^RAS_O17|...<cr>

PID|...<cr>

ORC|RE|1000^OE|9999999^RX|||E|^Q6H^D10^^^R|...<cr>

RXA|1|1|199012100615||0047-0402-30^Ampicillin 250 MG TAB^NDC|2|TAB|...<cr>

RXR|PO|...<cr>

4.15.2 RXO segment field examples

4.15.2.1 RXO-1 Requested Give code example

RXO|58160040000110^Fluoxetine HCL 10mg Capsule^GPI^00777310402^Prozac 10 mg caps^NDC|...<cr>

4.15.2.2 RXO-18 and RXO-19 Requested Strength and Strength Unit examples

The need for strength and strength unit fields in addition to the amount and amount units fields included in various RX_ segments requires explanation. Physicians can write a prescription for a drug such as Ampicillin in two ways. One way would be: "Ampicillin 250 mg capsules, 2 capsules four times a day." In this case the give amount would be 2, the give units would be capsules, the strength would be 250 and the strength units would milligrams.

ORC|||||||1^QID|...<cr>

RXO|01200020200105^Ampicillin 250 mg capsule^GPI^00047040230^Ampicillin 250 mg caps^NDC|2||caps^capsule^FDB||||||||||||||250|mg|...<cr>

However, the provider could also write the prescription as "Ampicillin 500 mg four times a day." In this case the give amount would be 500 and the give units would be milligrams. The strength would not be reported in the RXO segment because it is not specified; the drug could be given in two 250 mg caps or one 500 mg cap. But the pharmacist would dispense a specific capsule size and would record the strength in the RXE segment as 250 or 500, depending upon which pill size was dispensed.

ORC|||||||1^QID|...<cr>

RXO|012000202001^Ampicillin capsule^GPI |500||mg^milligram^ISO||...<cr>

4.15.3 RXD segment field examples

4.15.3.1 RXD-4 and RXD-5 Dispense amount and Actual dispense units

The RXD-4 and RXD-5 together might say

100 tabs:

RXD||||100|TAB^tablet^FDB|...<cr>

Or, 100 each

RXD||||100|EA^each^FDB|...<cr>

Or, perhaps a volume, 3 liters

RXD||||3|L^liter^ISO|...<cr>

4.15.3.2 Actual dispense amount, Actual dispense units, Actual strength, Actual strength units

For example, the RXD-4, RXD-5, RXD-16 and RXD-17 together might say

100 tabs of 240 mg strength:

RXD||||100|tab^tablet^FDB|||||||||||240|mg|...<cr>

Or, 100 each of 60 units per cc

RXD||||100|EA||||||||||||60|iu/ml^^ISO+|...<cr>

Or, perhaps a volume, 3 liters with 60 grams per liter

RXD||||3|L^liter^ISO|||||||||||60|g/L^^ISO+|...<cr>

4.15.3.3 Valuing the Dispense Package Size Unit

If the package given to the patient is 2, 4 ounce bottles with a strength of 100/5ml, but the cough suppressant is stocked in 1 gallon bottles, then the field contains 1 gallon.

RXD||||8|ounce^^ISO|||||||||||20|mg/ml|||||1|gal^gallon^ISO|...<cr>

If one were to dispense Mevacor 100 tablets with a strength of 20 mg/tablet, and the package from the manufacturer is a 60 tablet package, then the fields reflect 60 tablets (the size of the package stocked by the pharmacy).

RXD||||100|tab^^FDB|||||||||||20|mg|||||60|tab|...<cr>

4.15.4 RDS with FT1 segments example

Example: Adam Everyman appears in the Pharmacy with a prescription for Veramil 120 mgm B.I.D. The prescription is filled and the $5 co-pay is collected. The following RDS message is generated:

MSH|^&~\|PIMS|GenHosp|IE||1998052911150700||RDS^O13^RDS_O13||...<cr>

PID|||555444222111^^^MPI&GenHosp&L^MR||Everyman^Adam||19600614|M||C|99 Oakland # 106^^Pasadena^CA^91131||^^^^^626^5641111|^^^^^626^5647654|||||343132266|||N|...<cr>

ORC|RE||89968665||||||1998052910300700|||77^Hippocrates^Harold^H^III^DR^MD||^^^^^510^ 2673600|...<cr>

RXE|1^BID^^19980529|^Verapamil|120||mg^milligram^FDB.MDDB||...<cr>

RXD|1|00378112001^Verapamil Hydrochloride 120 mg TAB^NDC |199805291115-0700|100|||1331665|3|...<cr>

RXR|PO|...<cr>

FT1|1|||199805291115-0700||CO^Co-Pay^HL70017 |00378112001^Verapamil Hydrochloride 120 mg TAB^NDC |||1|5&USD^TP|...<cr>

FT1|2|||199805291115-0700||PY^Payment^HL70017 |00378112001^Verapamil Hydrochloride 120 mg TAB^NDC |||1|5&USD|...<cr>

4.15.5 Alternating IV order messages

HL7 Delimiters: <cr> = segment terminator; | = field separator; ^ = component separator; & = subcomponent separator; ~ = repetition indicator; \ = escape character

Encoding Note: For readability, these examples do not show encoding of the subcomponents of the Give Codes (CE data type) in the RXC and RXO segments. In practice, the subcomponents should be encoded as described in the HL7 specification.

  1. Example #1

D5/0.45NaCl 1000mL with 20mEq KCl in every 3rd bottle. Start the KCl in the 3rd bottle of this order. Run in at a rate of 100mL/hr.

(Other message data: placer order #123, placer application ID=SMS, interval=continuous, start date/time=11/28/94 0900, no stop date/time, priority=Routine, order sequencing=Cyclical)

This order may be expressed using a parent/child relationship. The parent order consists of an ORC (and a RXO, incompletely elaborated in this example) that contains order level information. The repeating bottle cycle of D5/0.45NaCl 1000mL followed by D5/0.45NaCl 1000mL followed by D5/0.45NaCl + 20mEq KCL 1000mL is represented by three child segments. The placer system may be treating this as a single order with two bottles, A (D5/0.45NaCl 1000mL @ 100mL/hr) and B (D5/0.45NaCl + 20mEq KCL 1000mL @ 100mL/hr), repeating in the cycle of A-A-B.

The parent:

ORC|NW|123^SMS|||||1^C^^199411280900^^R^^^^C|...<cr>

RXO|Cyclic IV|...<cr>

The first child:

ORC|CH|123A1^SMS|||||1^C^^^^^^^^C&123B&SMS&&&*ES+0M|123|...<cr>

RXO Segment, Requested Give Amount-Minimum: ...|100||ML|...

Requested Give Per (Time Unit): ...|H1|...<cr>

RXR|IV|...<cr>

RXC|B|D5/.45NACL|1000|ML|...<cr>

The second child:

ORC|CH|123A2^SMS|||||1^C^^^^^^^^C&123A1&SMS&&&ES+0M|123|...<cr>

RXO Segment, Requested Give Amount-Minimum: ...|100||ML|...

Requested Give Per (Time Unit): ...|H1|...<cr>

RXR|IV|...<cr>

RXC|B|D5/.45NACL|1000|ML|...<cr>

The third child:

ORC|CH|123B^SMS|||||1^C^^^^^^^^C&123A2&SMS&&&#ES+0M|123|...<cr>

RXO Segment, Requested Give Amount-Minimum: ...|100||ML|...

Requested Give Per (Time Unit): ...|H1|...<cr>

RXR|IV|...<cr>

RXC|B|D5/.45NACL|1000|ML|...<cr>

RXC|A|KCL|20|MEQ|...<cr>

Discussion points:

Placer Order Number - Three alternatives must be discussed for placer order number.

  1. Each child could have its own placer order number.

  2. Each child could have the order number of the parent plus some appended identifier (for examples, 123A or 123.A or 123.1 etc.) that labels each child or each unique combination of ingredients.

  3. In addition to the appended identifier discussed in 'B' above, a further suffix could be attached to uniquely identify each repetition of a particular member of the sequence. The example (a cycle of bottles 'A' and 'B' in the sequence A-A-B) identified the order numbers of the children as 123A1, 123A2, and 123B, thereby enabling the quantity/timing to be completely unambiguous. This could be expressed many other ways, such as 123A.1 or 123.A.1 or 123.A#1 etc. HL7 does not specify a format for the expression of order number suffixes, nor does it specify a delimiter to use for such a purpose.

Sequence Condition Value - In this example, the first child contains an asterisk (*) as the first character of the Sequence Condition Value and the third (last) child contains a pound sign (#).

The asterisk and pound sign are important for designating the first and last bottles especially when children are sent in separate messages, although this example is not constructed that way.

Note that computing the duration of the bottle is dependent upon the presence of all of the following fields:

For cyclic IV orders, these fields are all required in order to determine how long each occurrence of a child will last.

While HL7 allows either sending the parent and children in one message or sending the parent and children in separate messages, it appears simpler and therefore recommended to have the parent and all children included in a single message. The example is constructed that way.

  1. Example #2

D5W + 40mEq KCl 1000mL alternating with D5/LR + 20mEq KCl 1000mL at 125mL/hr

(Other message data: placer order #124, placer application ID=SMS, interval=continuous, start date/time=11/28/94 0900, no stop date/time, priority=Routine, order sequencing=Cyclical)

This example is a variation on the first example where two different base solutions are used. In this example, the placer system deals with this as one order with two alternating bottles, A (D5W + 40mEq KCl 1000mL @ 125mL/hr) and B (D5/LR + 20mEq KCl 1000mL @ 125mL/hr) in the cycle A-B. The principles discussed in Example #1 apply equally to this example.

The parent:

ORC|NW|124^SMS|||||1^C^^199411280900^^R^^^^C|...<cr>

RXO|Cyclic IV|...<cr>

The first child:

ORC|CH|124A^SMS|||||1^C^^^^^^^^C&124B&SMS&&&*ES+0M|124|...<cr>

RXO Segment, Requested Give Amount-Minimum: ...|125||ML|...

Requested Give Per (Time Unit): ...|H1|...<cr>

RXR|IV|...<cr>

RXC|B|D5W|1000|ML|...<cr>

RXC|A|KCL|40|MEQ|...<cr>

The second child:

ORC|CH|124B^SMS|||||1^C^^^^^^^^C&124A&SMS&&&#ES+0M|124|...<cr>

RXO Segment, Requested Give Amount-Minimum: ...|125||ML|...

Requested Give Per (Time Unit): ...|H1|...<cr>

RXR|IV|...<cr>

RXC|B|D5/LR|1000|ML|...<cr>

RXC|A|KCL|20|MEQ|...<cr>

Example #3

D5/0.45NaCl 1000mL with 20mEq KCl in every 3rd bottle. Start the KCl in the 3rd bottle of this order. Add 10mL of multi-vitamins to the one bag daily. Run in at a rate of 100mL/hr.

(Other message data: placer order #134, placer application ID=SMS, interval=continuous, start date/time=11/28/94 0900, no stop date/time, priority=Routine, order sequencing=Cyclical. Note that the encoding of the multi-vitamins statement in the above order, adding multi-vitamins to one IV bag each day, may vary by institution to put it into the first or last bottle of the day.)

This order may be expressed using a parent/child relationship. The parent order consists of an ORC (and a RXO, although I did not completely elaborate one in this example) that contains order level information. The repeating bottle cycle of D5/0.45NaCl 1000mL followed by D5/0.45NaCl 1000mL followed by D5/0.45NaCl + 20mEq KCL 1000mL is represented by three child segments. This order is complicated by the request to add one component into any one of the three repeating bottles, depending upon which of the bottles will occur first on any particular day. Further complicating this order is a rate of infusion (10 hours for a 1000mL bottle) which results in a fractional number of daily administrations. Most legacy systems have a great deal of trouble accommodating orders like this within their existing database structures; however there a few vendors who now are able to handle the situation. The placer system may be treating this as a single order with two bottles, A (D5/0.45NaCl 1000mL @ 100mL/hr) and B (D5/0.45NaCl + 20mEq KCL 1000mL @ 100mL/hr), repeating in the cycle of A-A-B with a cyclical component (multi-vitamins).

The parent:

ORC|NW|134^SMS|||||1^C^^199411280900^^R^^^^C|...<cr>

RXO|Cyclic IV|...<cr>

The first child:

ORC|CH|134A1^SMS|||||1^C^^^^^^^^C&134B&SMS&&&*ES+0M|134|...<cr>

RXO Segment, Requested Give Amount-Minimum: ...|100||ML|...

Requested Give Per (Time Unit): ...|H1|...<cr>

RXR|IV|...<cr>

RXC|B|D5/.45NACL|1000|ML|...<cr>

The second child:

ORC|CH|134A2^SMS|||||1^C^^^^^^^^C&134A1&SMS&&&ES+0M|134|...<cr>

RXO Segment, Requested Give Amount-Minimum: ...|100||ML|...

Requested Give Per (Time Unit): ...|H1|...<cr>

RXR|IV|...<cr>

RXC|B|D5/.45NACL|1000|ML|...<cr>

The third child:

ORC|CH|134B^SMS|||||1^C^^^^^^^^C&134A2&SMS&&&#ES+0M|134|...<cr>

RXO Segment, Requested Give Amount-Minimum: ...|100||ML|...

Requested Give Per (Time Unit): ...|H1|...<cr>

RXR|IV|...<cr>

RXC|B|D5/.45NACL|1000|ML|...<cr>

RXC|A|KCL|20|MEQ|...<cr>

The fourth child:

ORC|CH|134X^SMS|||||1^Q1D^^^^^^^^|134|...<cr>

RXO|MULTIVITAMINS|10||ML|INJECTABLE|...<cr>

Discussion points:

This method for accommodating the Multi-vitamins Daily scenario does not pretend to be the best or only way to express the message, but simply demonstrates adapting the current specification to a highly complex order without adding new components.

The Multi-vitamins component may be sent as a fourth child.

In this example, its ORC-7-quantity/timing includes an interval of "Q1D" (every 1 days).

Its order number consists of the placer's parent order number plus an appended identifier ('X' in the above example) that labels this child as a special case. This convention would need to be agreed upon by sending and receiving applications.

  1. Example #4

D5W + 40mEq KCl 1000mL alternating with D5/LR + 20mEq KCl 1000mL alternating with D5/0.45NaCl 1000mL. Infuse the D5W and D5/0.45 at 125mL/hr, and the D5/LR at 100mL/hr.

(Other message data: placer order #177, placer application ID=SMS, interval=continuous, start date/time=11/28/94 0900, no stop date/time, priority=Routine, order sequencing=Cyclical)

This example is another variation of Example 1 where the rate for each bottle is different, and this can be expressed within the RX segments of the children using current components. In this example, the placer system deals with this as one order with three alternating bottles, A (D5W + 40mEq KCl 1000mL @ 125mL/hr) , B (D5/LR + 20mEq KCl 1000mL @ 100mL/hr) , and C (D5/0.45NaCl 1000mL @ 125mL/hr) in the cycle A-B-C. The principles discussed in Example #1 apply equally to this example.

The parent:

ORC|NW|177^SMS|||||1^C^^199411280900^^R^^^^C|...<cr>

RXO|Cyclic IV|...<cr>

The first child:

ORC|CH|177A^SMS|||||1^C^^^^^^^^C&177C&SMS&&&*ES+0M|177|...<cr>

RXO Segment, Requested Give Amount-Minimum: ...|125||ML|...

Requested Give Per (Time Unit): ...|H1|...<cr>

RXR|IV|...<cr>

RXC|B|D5W|1000|ML|...<cr>

RXC|A|KCL|40|MEQ|...<cr>

The second child:

ORC|CH|177B^SMS|||||1^C^^^^^^^^C&177A&SMS&&&ES+0M|177|...<cr>

RXO Segment, Requested Give Amount-Minimum: ...|100||ML|...

Requested Give Per (Time Unit): ...|H1|...<cr>

RXR|IV|...<cr>

RXC|B|D5/LR|1000|ML|...<cr>

RXC|A|KCL|20|MEQ|...<cr>

The third child:

ORC|CH|177C^SMS|||||1^C^^^^^^^^C&177B&SMS&&&#ES+0M|177|...<cr>

RXO Segment, Requested Give Amount-Minimum: ...|125||ML|...

Requested Give Per (Time Unit): ...|H1|...<cr>

RXR|IV|...<cr>

RXC|B|D5/0.45NACL|1000|ML|...<cr>

4.15.6 Query examples

With appropriate definitions in the QRD and/or QRF segments, the RDE, RDS, RGV, and RAS messages can serve as models for result-oriented pharmacy/treatment queries returning the current profile of pharmacy or treatment orders (RDE type), the current dispense history (RDS type), the current dose history (RGV type), or the current administration record (RAS type)_"

The order entry application requests pharmacy/treatment order information for patient 12345, from 8/12/92 through 8/13/92.

MSH|^&~\|||||199208201200||QRY^O29^QRY_Q01|...<cr>

QRD|19920814181254|R|D|9200785|||45^RD|12345|RER|...<cr>

QRF|PHM|19920812000000|19920813235959|...<cr>

DSC|...<cr>

MSH|^&~\|||||199208201201||RER^RER^RER_RER|...<cr>

MSA|AA|1001|...<cr>

QRD|...<cr>

QRF|...<cr>

ORC|RE|3346^OE|R23^RX|...<cr>

RXE|^BID^D5^199208120800^199208162000|10986^AMPICILLIN|250||MG|...<cr>

RXR|PO|...<cr>

ORC|RE|3987^OE|R76^RX|...<cr>

RXE|^TID^D7^199208120600^199208182200|12796^ASPIRIN|325||MG|...<cr>

RXR|PO|...<cr>

DSC|...<cr>

The lab application requests pharmacy/treatment administration information for patient 12345, from 8/12/92 through 8/13/92.

MSH|^&~\|||||199208201200||QRY^O27^QRY_Q01|...<cr>

QRD|19920814165645|R|D|9200231|||30^RD|12345|RAR|...<cr>

QRF|PHM|19920812000000|19920813235959|...<cr>

DSC|...<cr>

MSH|^&~\|||||199208201201||RAR^RAR^RAR_RAR|...<cr>

MSA|AA|1002|...<cr>

QRD|...<cr>

QRF|...<cr>

ORC|RE||R23^RX|...<cr>

RXE|^BID^D5^199208120800^199208162000|10986^AMPICILLIN|250||MG|...<cr>

RXR|PO|...<cr>

RXA|1|1|199208120800|199208120800|10986^AMPICILLIN|250|...<cr>

RXA|2|2|199208122000|199208122000|10986^AMPICILLIN|250|...<cr>

RXA|3|3|199208130800|199208130800|10986^AMPICILLIN|250|...<cr>

RXA|4|4|199208132000|199208132000|10986^AMPICILLIN|250|...<cr>

ORC|RE||R76^RX|...<cr>

RXE|^TID^D7^199208120600^199208182200|12796^ASPIRIN|325||MG|...<cr>

RXR|PO|...<cr>RXA|1|1|199208120600|199208120600|12796^ASPIRIN|325|...<cr>

RXA|2|2|199208121400|199208121400|12796^ASPIRIN|325|...<cr>

RXA|3|3|199208122200|199208122200|12796^ASPIRIN|325|...<cr>

RXA|4|4|199208130600|199208130600|12796^ASPIRIN|325|...<cr>

RXA|5|5|199208131400|199208131400|12796^ASPIRIN|325|...<cr>

RXA|6|6|199208132200|199208132200|12796^ASPIRIN|325|...<cr>

DSC|...<cr>

The nursing system requests pharmacy/treatment dose information for patient 12345, from 8/12/92 through 8/13/92.

MSH|^&~\|||||199208201200||QRY^Q30^QRY_Q01|...<cr>

QRD|19920814172309|R|D|9200543|||100^RD|12345|RGR|...<cr>

QRF|PHM|19920812000000|19920813235959|...<cr>

DSC|...<cr>

MSH|^&~\|||||199208201201||RGR^RGR^RGR_RGR|...<cr>

MSA|AA|1003|...<cr>

QRD|...<cr>

QRF|...<cr>

ORC|RE||R23^RX|...<cr>

RXE|^BID^D5^199208120800^199208162000|10986^AMPICILLIN|250||MG|...<cr>

RXR|PO|...<cr>

RXG|1||^^^199208120701|10986^AMPICILLIN|250|...<cr>

RXG|2||^^^199208121923|10986^AMPICILLIN|250|...<cr>

RXG|3||^^^199208130702|10986^AMPICILLIN|250|...<cr>

RXA|4||^^^199208131912|10986^AMPICILLIN|250|...<cr>

ORC|RE||R76^RX|...<cr>

RXE|^TID^D7^199208120600^199208182200|12796^ASPIRIN|325||MG|...<cr>

RXR|PO|...<cr>

RXG|1||^^^199208120459|12796^ASPIRIN|325|...<cr>

RXG|2||^^^199208121328|12796^ASPIRIN|325|...<cr>

RXG|3||^^^199208122101|12796^ASPIRIN|325|...<cr>

RXG|4||^^^199208130503|12796^ASPIRIN|325|...<cr>

RXG|5||^^^199208131311|12796^ASPIRIN|325|...<cr>

RXG|6||^^^199208132145|12796^ASPIRIN|325|...<cr>

DSC|...<cr>

4.16 PHARMACY/TREATMENT TRANSACTION FLOW DIAGRAM

The following are possible routes at a generic site.

4.16.1 OMP:

The Ordering application generates a pharmacy/treatment OMP) and sends it to the pharmacy or treatment application, Nursing application, and/or other applications as appropriate at the site.

4.16.2 RDE:

The pharmacy/treatment application may send the RDE, the Pharmacy/Treatment Encoded Order message, a fully encoded order to the Nursing application, Ordering application, and/or other system applications as appropriate at the site.

4.16.3 RDS:

The pharmacy/treatment application may send the RDS, the Pharmacy/Treatment Dispense message, to the Nursing application or other applications as appropriate at the site, each time a medication is dispensed for this order. This message may occur multiple times for each order.

4.16.4 RGV:

The pharmacy application may send the RGV, the Pharmacy/Treatment Give message, to the Nursing application or other applications as appropriate at the site, for each scheduled date/time of administration of a medication for a given order. This message may occur multiple times for each order.

4.16.5 RAS:

The Nursing application (and other applications) can generate the RAS, the pharmacy/treatment Administration Results message, whenever a medication is given to the patient. This message may occur multiple times for each order.

Note: Sites having a long term clinical data repository may wish to route data to the data repository from copies of all or any of the five messages.

4.17 VACCINE TRIGGER EVENTS & MESSAGE DEFINITIONS

The message header segment will carry one of four event types at MSH-9-Message Type:

Event Description
V01 Query for Vaccination Record
V02 Response to Vaccination Query (V01) Returning Multiple PID Matches
V03 Response to Query (V01) Returning Vaccination Record
V04 Unsolicited Update to Vaccination Record

4.17.1 Vaccine administration data

Immunization registries that maintain vaccination records need to be able to transmit patient-specific records of vaccines administered to other registries to provide access to the record at the time healthcare is given and to allow tracking of progress in reaching age-appropriate immunization coverage. The transmissions will occur as the result of four activities: (1) a query from one system for a patient's vaccination record that is held in another system, (2) a response to a query containing multiple patient matches to the query, (3) a response to a query containing the vaccination record, and (4) an unsolicited update to an immunization registry

These messages permit the transmission of immunization records from care providers to immunization registries, queries of these registries for immunization records, and the return of these immunization records to care providers. Messages containing immunization records carry patient identifying information in the PID segment. They may also carry parent or guardian information in the NK1 segments to help identify a child. The RXA segment is used to report the details of the immunization event: the type of vaccine (e.g., DPT, polio, MMR), the date administered, the sequence (1st, 2nd, etc.), the amount (e.g., 0.5 ml), and location and provider of the immunization. In addition, the RXA provides a place to record the lot number, manufacturer and date of expiration of the immunization. The RXA can also be used to report the fact that a specified immunization was refused. This section includes two tables (0292 and 0227) maintained by the U.S. Centers for Disease Control and Prevention (CDC). These tables are recommended in the U.S. for identifying the immunization in field RXA-5-Administered Code and the vaccine manufacturer in field RXA-17-substance manufacturer name.

4.17.2 Queries for immunization records (QRF Segments)

The VXQ, VXX, and VXR messages defined below incorporate the QRF segment defined at 5.10.5.4, "QRF - original style query filter segment." QRF-5-other query subject filter is a locally defined filter for use between two systems which mutually agree on a definition. For transferring vaccination administration data, QRF-5-other QRY subject filter should be structured as shown in Figure 4-7 to transmit up to ten separate search "keys." These search keys are only used to identify one patient's immunization record. The message provides for a wide variety of "identifying" keys including mother's and/or father's name and other identifiers; in some cases such information will be needed to identify a specific patient in the immunization database.

The format of each of the possible "search keys" is given below, and listed in a more structured form in Figure 4-7. These keys are transmitted as strings separated by repeat delimiters. The position of the components within QRF-5-other QRY subject filter is significant. The requester sends values for all the components that are known.

Components: <patient social security number> ~ <patient birth date> ~ <patient birth state> ~ <patient birth registration number> ~ <patient medicaid number> ~ <mother's name last^first^middle> ~ <mother's maiden name> ~ <mother's Social Security number> ~ <father's name last^first^middle> ~ <father's Social Security number>

Figure 4-7. QRF-5 usage in vaccination messages

Pos Component Data Type Description/Examples
1 Patient Social Security Number~ ST In U.S., use SSN, without hyphens between 3rd and 4th digits and 5th and 6th digits, e.g., 123456789. In other countries, universal patient ID such as National Health Service number may be used.
2 Patient Birth Date~ DT July 4, 1976 = 19760704
3 Patient Birth State~ ID In U.S., use 2-letter postal code, e.g., IN, NY, CA. In other countries, locally applicable postal table may be used.
4 Patient Birth Registration Number~ ST State birth certificate number
5 Patient Medicaid Number~ ST When relevant
6 Mother's Name Last^First^Middle~ PN ^ ^ ^

^ ^ . E.g., Smith^Mary^Elizabeth

7 Mother's Maiden Name~ ST Family name of mother before marriage. E.g., Jones
8 Mother's Social Security Number~ ST In U.S., use SSN, without hyphens between 3rd and 4th digits and 5th and 6th digits, e.g., 123456789. In other countries, universal patient ID such as National Health Service number may be used.
9 Father's Name Last^First^Middle~ PN ^ ^ ^

^ ^ . E.g.,Smith^Thomas^A^Jr

10 Father's Social Security Number ST In U.S., use SSN, without hyphens between 3rd and 4th digits and 5th and 6th digits, e.g., 123456789. In other countries, universal patient ID such as National Health Service number may be used.

|908723461~19941005|

If, in addition, the patient's birth state and mother's current and maiden name were known, this QRF-5-other QRY subject filter would be sent:

|908723461~19941005~IN~~~HUTCHINS^KATHY^ANN~HARKNESS|

4.17.3 VXQ - Query For Vaccination Record (Event V01)

Definition: When an immunization registry does not already have the complete patient vaccination record, it will send a query (with a V01 event) for the definitive (last updated) record. Within the definitions for QRD and QRF, certain components are defined according to position in the field, as detailed in Section 4.17.2, "Queries for immunization records (QRF Segments)." The three-letter code in the leftmost column indicates the segment that is included; the column on the right specifies the chapter in which that segment is fully defined.

The query will follow this format:

VXQ^V01^VXQ_V01 Vaccination Query Status Chapter DB Ref.
MSH Message Header Segment
2 DB
[ { SFT } ] Software
2 DB
QRD Query Definition Segment
2 DB
[ QRF ] Query Filter Segment
2 DB

4.17.4 VXX - RESPONSE TO VACCINATION QUERY RETURNING MULTIPLE PID MATCHES (EVENT V02)

Definition: In response to a query for the definitive patient vaccination record, the registry holding the record will return it to the registry originating the query.

If the query results in multiple "matches," i.e., more than one patient record matches the identifiers in the query so that there is no unique identification, the response to the query (with a V02 event) will follow this format. Within the definitions for QRD and QRF, certain components are defined according to position in the field, as detailed in Section 4.17.2, "Queries for immunization records (QRF Segments)." The three-letter code in the leftmost column indicates the segment that is included; the column on the right specifies the chapter in which that segment is fully defined.

VXX^V02^VXX_V02 Returning Multiple PID Matches Status Chapter DB Ref.
MSH Message Header
2 DB
MSA Message Acknowledgment
2 DB
[ { SFT } ] Software
2 DB
QRD Query Definition
2 DB
[ QRF ] Query Filter
2 DB
{ --- PATIENT begin


PID Patient Identification
3 DB
[ { NK1 } ] Next of Kin/Associated Parties
3 DB
} --- PATIENT end


4.17.5 VXR - Vaccination Record Response (Event V03)

Definition: When the patient has been uniquely identified (there is only one "match" to the query), the response to the query (with a V03 event) will follow this format. Within the definitions for QRD and QRF, certain components are defined according to position in the field, as detailed in Section 4.17.2, "Queries for immunization records (QRF Segments)." The three-letter code in the leftmost column indicates the segment that is included; the column on the right specifies the chapter in which that segment is fully defined.

VXR^V03^VXR_V03 Vaccination Response Status Chapter DB Ref.
MSH Message Header
2 DB
MSA Message Acknowledgment
2 DB
[ { SFT } ] Software
2 DB
QRD Query Definition
2 DB
[ QRF ] Query Filter
2 DB
PID Patient Identification
3 DB
[ PD1 ] Additional Demographics
3 DB
[ { NK1 } ] Next of Kin/Associated Parties
3 DB
[ --- PATIENT_VISIT begin


PV1 Patient Visit
3 DB
[ PV2 ] Patient Visit _ Additional Info
3 DB
] --- PATIENT_VISIT end


[ { GT1 } ] Guarantor
6 DB
[{ --- INSURANCE begin


IN1 Insurance
6 DB
[ IN2 ] Insurance Additional Info
6 DB
[ IN3 ] Insurance Add'l Info - Cert.
6 DB
}] --- INSURANCE end


[{ --- ORDER begin


ORC Common Order
4 DB
[{ --- TIMING begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
}] --- TIMING end


RXA Pharmacy Administration
4 DB
[ RXR ] Pharmacy Route
4 DB
[{ --- OBSERVATION begin


OBX Observation/Result
7 DB
[ { NTE } ] Notes (Regarding Immunization)
2 DB
}] --- OBSERVATION end


}] --- ORDER end


4.17.6 VXU - Unsolicited Vaccination Record Update (Event V04)

Definition: When a provider wishes to update the patient's vaccination record being held in a registry, he will transmit an unsolicited update of the record (a V04 trigger event).

An unsolicited update will follow this format. The three-letter code in the leftmost column indicates the segment that is included; the column on the right specifies the chapter in which that segment is fully defined.

VXU^V04^VXU_V04 Unsolicited Vaccination Update Status Chapter DB Ref.
MSH Message Header Segment
2 DB
[ { SFT } ] Software
2 DB
PID Patient Identification Segment
3 DB
[ PD1 ] Additional Demographics
3 DB
[ { NK1 } ] Next of Kin/Associated Parties
3 DB
[ --- PATIENT begin


PV1 Patient Visit
3 DB
[ PV2 ] Patient Visit _ Additional Info
3 DB
] --- PATIENT end


[ { GT1 } ] Guarantor
6 DB
[{ --- INSURANCE begin


IN1 Insurance
6 DB
[ IN2 ] Insurance Additional Info
6 DB
[ IN3 ] Insurance Add'l Info - Cert.
6 DB
}] --- INSURANCE end


[{ --- ORDER begin


ORC Common Order
4 DB
[{ --- TIMING begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
}] --- TIMING end


RXA Pharmacy Administration Segment
4 DB
[ RXR ] Pharmacy Route
4 DB
[{ --- OBSERVATION begin


OBX Observation/Result
7 DB
[ { NTE } ] Notes (Regarding Immunization)
2 DB
}] --- OBSERVATION end


}] --- ORDER end


4.18 VACCINE SEGMENTS

4.18.1 RXA - segment usage in vaccine messages

With the exception of RXA-5-Administered code and RXA-17-Substance manufacturer name, the structure for the RXA segment below is identical to that documented in section 4.14.7. When using the RXA segment for vaccine messages, HL7 Table 0292- Vaccines Administered, should be used for RXA-5- Administered code, as noted in Section 4.18.1.1. HL7 Table 0227- Manufacturers of Vaccines, should be used for RXA-17- Substance manufacturer name, as noted in Section 4.18.1.2

HL7 Attribute Table _ RXA _ Segment Uses in Vaccine Messages

SEQ LEN DT OPT RP/# TBL# ITEM # ELEMENT NAME DB Ref.
1 4 NM R

00342 Give Sub-ID Counter DB
2 4 NM R

00344 Administration Sub-ID Counter DB
3 26 TS R

00345 Date/Time Start of Administration DB
4 26 TS R

00346 Date/Time End of Administration DB
5 250 CE R
0292 00347 Administered Code DB
6 20 NM R

00348 Administered Amount DB
7 250 CE C

00349 Administered Units DB
8 250 CE O

00350 Administered Dosage Form DB
9 250 CE O Y
00351 Administration Notes DB
10 250 XCN O Y
00352 Administering Provider DB
11 200 LA2 C

00353 Administered-at Location DB
12 20 ST C

00354 Administered Per (Time Unit) DB
13 20 NM O

01134 Administered Strength DB
14 250 CE O

01135 Administered Strength Units DB
15 20 ST O Y
01129 Substance Lot Number DB
16 26 TS O Y
01130 Substance Expiration Date DB
17 250 CE O Y 0227 01131 Substance Manufacturer Name DB
18 250 CE O Y
01136 Substance/Treatment Refusal Reason DB
19 250 CE O Y
01123 Indication DB
20 2 ID O
0322 01223 Completion Status DB
21 2 ID O
0323 01224 Action Code - RXA DB
22 26 TS O

01225 System Entry Date/Time DB

4.18.1.0 RXA field definitions

4.18.1.1 Using RXA-5 in vaccine messages

Use in RXA-5- administered code to identify the particular vaccine administered. The codes listed are used by immunization by immunization registries in the U.S. Entries will be added as needed to accommodate international requirements. Refer to HL7 Table 0292 _ Vaccines administered for valid values.

4.18.1.2 Using RXA-17 in vaccine messages

Use in RXA-17-substance manufacturer name to identify the manufacturer or distributor of the particular vaccine administered. The codes listed are used by immunization registries in the U.S. Entries will be added as needed to accommodate international requirements. Refer to HL7 Table 0227 _ manufacturers of Vaccines for valid values.

4.19 VACCINATION MESSAGE EXAMPLES

4.19.1 VXQ - query for vaccination record

MSH|^~\&||GAVACREC||AZVACREC|199505221605||VXQ^V01^VXQ_V01| ...<cr>

QRD|199505221605|R|I|950522GA40|||1000^RD|^JONES^JOHN^RICHARD|VXI|SIIS|...<cr>

QRF|AZVACREC||||256946789~19900607~CA~CA99999999~88888888~JONES^MARY^SUE~SMITH~898666725~JONES^MATHEW^LEE~822546618|...<cr>

In this query, Georgia Vaccine Records is sending a request to Arizona Vaccine Records for an immunization record. The request is being sent on May 22, 1995, at 4:05 p.m. Identifiers other than patient name are defined in the query by giving positional meaning to the repeat delimiters in the QRF-5-other query subject filter field, as specified in Section 4.17.2, "Queries for immunization records (QRF Segments)." The responding system is expected to return all query items in their response. The QRD segment, at QRD-8-who subject filter, identifies the patient name. QRD-9-what subject filter reflects the new VXI category of Vaccination Information. QRD-10-what department data code shows SIIS.

In our example, we are sending a query for the record of John Richard Jones. The patient's Social Security number is 256-94-6789; the patient birth date is June 7, 1990; the patient birth state is CA; the patient birth registration number is CA99999999; and the patient Medicaid number is 88888888. The patient's mother is Mary Sue Jones, whose maiden name is Smith. Her Social Security number is 898-66-6725. The patient's father is Mathew Lee Jones, and the father's Social Security number is 822-54-6618.

4.19.2 VXX - response to vaccination query with multiple PID matches

MSH|^~\&||AZVACREC||GAVACREC|199505221606||VXX^V02^VXX_V02|...<cr>

MSA|...<cr>

QRD|199505221605|R|I|950522GA40|||1000^RD|^JONES^RICHARD|VXI|SIIS|...<cr>

QRF|AZVACREC||||~~~~~JONES^MARY|...<cr>

PID|1||123456789^^^AZ||^JONES^RICHARD^ROBERT||19910607|M^MALE^HL70001|...<cr>

NK1|1|JONES^MARY^SUE|MTH^MOTHER^HL70063||||||||||||||||||||||||||||||265909900^^^^SS|...<cr>

PID|2||987654321^^^AZ||^JONES^JOHN^RICHARD||19900607|M^MALE^HL70001|...<cr>

NK1|1|JONES^MARY|MTH^MOTHER^HL70063||||||||||||||||||||||||||||||898666725^^^^SS|...<cr>

NK1|2|JONES^MATHEW^LEE|FTH^FATHER^HL70063||||||||||||||||||||||||||||||822546618^^^^SS|...<cr>

PID|3||231453675^^^AZ||^JONES^RICHARD^CURTIS||19901225|M^MALE^HL70001|...<cr>

NK1|1|JONES^MARY^ANN|MTH^MOTHER^HL70063||||||||||||||||||||||||||||||288763102^^^^SS|...<cr>

PID|4||908786564^^^AZ||^JONES^RICHARD^ALAN||19870205|M^MALE^HL70001|...<cr>

NK1|1|JONES^MARY^SUE|MTH^MOTHER^HL70063||||||||||||||||||||||||||||||190966725^^^^SS|...<cr>

NK1|2|JONES^CHRISTOPHER|FTH^FATHER^HL70063||||||||||||||||||||||||||||||786118768^^^^SS|...<cr>

The example shows the response when multiple PIDs match a query. In the QRD, the sender is querying Arizona Vaccine Records for information on Richard Jones; the only further identifying information supplied in the QRF is that the mother's name is Mary Jones. For each record which matches this information, a PID is returned along with its associated NK1. The system initiating the query may then re-send a more precise query.

4.19.3 VXR - vaccination record response

MSH|^~\&||AZVACREC||GAVACREC|199505221606||VXR^V03^VXR_V03|...<cr>

MSA|...<cr>

QRD|...<cr>

QRF|...<cr>

PID|...<cr>

NK1|1|JONES^MARY^SUE|MTH^MOTHER^HL70063||||||||||||||||||||||||||||||898666725^^^^SS|...<cr>

NK1|2|JONES^MATHEW^LEE|FTH^FATHER^HL70063||||||||||||||||||||||||||||||822546618^^^^SS|...<cr>

ORC|RE||V43^AZVAC|...<cr>

RXA|0|4|19910607|19910607|01^DTP^CVX|.5|MG^^ISO+|||1234567891^GOLDSTEIN^HAROLD^A^^DR|

^^^CHILD HEALTHCARE CLINIC^^^^^101 MAIN STREET^^METROPOLIS^AZ||||W46932777|19910813|

SKB^SmithKline Beecham^MVX|...<cr>ORC|RE||V44^AZVAC|...<cr>

RXA|0|1|19910607|19910607|03^MMR^CVX|.5|MG^^ISO+|||1234567891^GOLDSTEIN^HAROLD^A^^DR|

^^^CHILD HEALTHCARE CLINIC^^^^^101 MAIN STREET^^METROPOLIS^AZ||||W23487909876456|

19910725|MSD^Merck \T\ Co., Inc.^MVX|...<cr>

ORC|RE||V87^AZVAC|...<cr>

RXA|0|5|19950520|19950520|01^DTP^CVX|.5|MG^^ISO+|||1234567891^GOLDSTEIN^HAROLD^A^^DR|

^^^CHILD HEALTHCARE CLINIC^^^^^101 MAIN STREET^^METROPOLIS^AZ||||W22532806|19950705|

SKB^SmithKline Beecham^MVX|...<cr>

ORC|RE||V88^AZVAC|...<cr>

RXA|0|2|19950520|19950520|03^MMR^CVX|.5|MG^^ISO+|||1234567891^GOLDSTEIN^HAROLD^A^^DR|

^^^CHILD HEALTHCARE CLINIC^^^^^101 MAIN STREET^^METROPOLIS^AZ||||W2341234567|19950630|

MSD^Merck \T\ Co., Inc.^MVX|...<cr>

The example reflects a vaccination record return as might be expected by a public health agency reporting from one immunization registry to another. It shows repeating RXA segments reporting the first and second doses of MMR and the fourth and fifth doses of DTP, including the manufacturer, lot number, and expiration date. If the vaccination had been refused by the patient or guardian, RXA-18-substance refusal reason would record the vaccine refusal reason, utilizing a user-defined table.

4.19.4 VXU - unsolicited vaccination record update

MSH|^~\&||AZVACREC||GAVACREC|199505221606||VXU^V04^VXU_V04|...<cr>

PID|...<cr>

NK1|...<cr>

NK1|...<cr>

PV1|...<cr>

PV2|...<cr>

IN1|...<cr>

IN2|||||||JONES^ALICE^P|909686637A|...<cr>

ORC|...<cr>

RXA|0|1|19950901115500|19950901115500|03^MMR^CVX|.5|MG^^ISO+|||

1234567891^GOLDSTEIN^HAROLD^A^^DR| ^^^ CHILD HEALTHCARE CLINIC^^^^^101 MAIN STREET^ ^METROPOLIS^AZ||||W23487909876456|19951125|MSD^Merck \T\ Co., Inc.^MVX|...<cr>

RXR|IM^INTRAMUSCULAR^HL70162|LG^LEFT GLUTEUS MEDIUS^HL70163|...<cr>

OBX|1|NM|1000.3^TEMP.RECTAL^AS4||102.9|DEGF^^ANSI+|||||F|||19950901153000|...<cr>

NTE|||PATIENT DEVELOPED HIGH FEVER APPROX 3 HRS AFTER VACCINE INJECTION. PROBABLE ADVERSE REACTION|...<cr>

This message shows an unsolicited update of a vaccination record. The message type is VXU--Unsolicited Vaccination Record Update, with event code V04 (unsolicited vaccination record update). This example is given to show possible uses for some of the optional segments in the message.

4.19.5 Query acknowledgment with no records found

MSH|^~\&||AZVACREC||GAVACREC|19950522130550^S||DSR^Q01^DSR_Q01|...<cr>

MSA|AA|950522GA40|...<cr>

QAK||NF|...<cr>

QRD|...<cr>

The example shows the response to a query which was successfully processed, but no qualifying data were found.

4.20 TRANSFUSION SERVICE (BLOOD BANK) TRIGGER EVENTS & MESSAGES

4.20.1 Usage notes for transfusion service messages

Blood product order messages present the need for additional information that is not included in standard HL7 order messages. Order messages must contain accompanying details regarding the blood product component, such as special processing requirements (e.g. irradiation and leukoreduction), and the amount of the blood product to be administered. Additionally, specific relevant clinical information can be included to allow the prospective review of the appropriateness of the blood product order

Blood product orders use the OMB message with the BPO segment for the detail segment and the acknowledgment message, ORB as described below.

OMB^O27^OMB_O27 Blood Product Order Message Status Chapter DB Ref.
MSH Message Header
2 DB
[ { SFT } ] Software
2 DB
[ { NTE } ] Notes and Comments (for Header)
2 DB
[ --- PATIENT begin


PID Patient Identification
3 DB
[ PD1 ] Additional Demographics
3 DB
[ { NTE } ] Notes and Comments (for Patient ID)
2 DB
[ --- PATIENT_VISIT begin


PV1 Patient Visit
3 DB
[ PV2 ] Patient Visit _ Additional Info
3 DB
] --- PATIENT_VISIT end


[{ --- INSURANCE begin


IN1 Insurance
6 DB
[ IN2 ] Insurance Additional Info
6 DB
[ IN3 ] Insurance Add'l Info - Cert.
6 DB
}] --- INSURANCE end


[ GT1 ] Guarantor
6 DB
[ { AL1 } ] Allergy Information
3 DB
] --- PATIENT end


{ --- ORDER begin


ORC Common Order
4 DB
[{ --- TIMING begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
}] --- TIMING end


BPO Blood Product Order
4 DB
[ SPM ] Specimen
7 DB
[ { NTE } ] Notes and Comments (for Order)
2 DB
[ { DG1 } ] Diagnosis
6 DB
[{ --- OBSERVATION begin


OBX Observation/Result
7 DB
[ { NTE } ] Notes and Comments (for Results)
2 DB
}] --- OMSERVATION end


[ { FT1 } ] Financial Transaction
6 DB
[ BLG ] Billing Segment
6 DB
} --- ORDER end


4.20.1.0 OMB use notes

The NTE segment(s) can be included in the OMB message in four places; in each place the NTE refers to the segment that it follows. In particular, the NTEs following the MSH refer only to the message header; the NTEs following the blood product order segment apply to the service defined by that ORC and blood product order segment.

The PID segment is required if and only if new orders are being entered and they are related to a particular patient. For non-patient-related orders the PID segment is never included.

The optional PV1 segment is present mainly to permit transmission of patient visit information such as current location with an order.

4.20.2 ORB _ Blood Product Order Acknowledgment (Event O28)

ORB^O28^ORB_O28 Description Status Chapter DB Ref.
MSH Message Header
2 DB
MSA Message Acknowledgment
2 DB
[ { ERR } ] Error
2 DB
[ { SFT } ] Software
2 DB
[ { NTE } ] Notes and Comments (for Response Header)
2 DB
[ --- RESPONSE begin


[ --- PATIENT begin


PID Patient Identification
3 DB
[{ --- ORDER begin


ORC Common Order
4 DB
[{ --- TIMING begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
}] --- TIMING end


[ BPO ] Blood Product Order
4 DB
}] --- ORDER end


] --- PATIENT end


] --- RESPONSE end


4.20.3 BPS _ Blood Product Dispense Status Message (Event O29)

In the pre-transfusion processing of blood products, it is necessary for the transfusion service and the placer system to communicate information that is not included in the current HL7 order/observation model. Examples of pre-transfusion processing include performing a crossmatch test to ensure compatibility with the patient, or irradiation of the blood product due to a special transfusion requirement for the patient. The blood product dispense status messages need to contain additional information regarding the blood products requested, such as the Donation ID, product code, blood type, expiration date/time and current status of the blood product.

In the processing of commercial blood products, such as Rh Immune Globulin, Factor Concentrate, or Albumin Products, the status messages need to contain additional information, such as the lot number and manufacturer, expiration date and status of the commercial product.

Blood product dispense status messages use the BPS and BRP messages as described below.

BPS^O29^BPS_O29 Blood Product dispense status Message Status Chapter DB Ref.
MSH Message Header
2 DB
[ { SFT } ] Software
2 DB
[ { NTE } ] Notes and Comments (for Header)
2 DB
[ --- PATIENT begin


PID Patient Identification
3 DB
[ PD1 ] Additional Demographics
3 DB
[ { NTE } ] Notes and Comments (for Patient ID)
2 DB
[ --- PATIENT_VISIT begin


PV1 Patient Visit
3 DB
[ PV2 ] Patient Visit _ Additional Info
3 DB
] --- PATIENT_VISIT end


] --- PATIENT end


{ --- ORDER begin


ORC Common Order
4 DB
[{ --- TIMING begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
}] --- TIMING end


BPO Blood Product Order
4 DB
[ { NTE } ] Notes and Comments (for BPO)
2 DB
[{ --- PRODUCT begin


BPX Blood Product Dispense Status
4 DB
[ { NTE } ] Notes and Comments (for BPX)
2 DB
}] --- PRODUCT end


} --- ORDER end


4.20.4 BRP _ Blood Product Dispense Status Acknowledgment (Event O30)

BRP^O30^BRP_O30 Description Status Chapter DB Ref.
MSH Message Header
2 DB
MSA Message Acknowledgment
2 DB
[ { ERR } ] Error
2 DB
[ { SFT } ] Software
2 DB
[ { NTE } ] Notes and Comments (for Response Header)
2 DB
[ --- RESPONSE begin


[ --- PATIENT begin


PID Patient Identification
3 DB
[{ --- ORDER begin


ORC Common Order
4 DB
[{ --- TIMING begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
}] --- TIMING end


[ BPO ] Blood Product Order
4 DB
[ { BPX } ] Blood Product dispense status

DB
}] --- ORDER end


] --- RESPONSE end







4.20.5 BTS _ Blood Product Transfusion/Disposition Message (Event O31)

Blood product transfusion/disposition messages use the BTS and BRT messages as described below.

BTS^O31^BTS_O31 Blood Product Transfusion/Disposition Message Status Chapter DB Ref.
MSH Message Header
2 DB
[ { SFT } ] Software
2 DB
[ { NTE } ] Notes and Comments (for Header)
2 DB
[ --- PATIENT begin


PID Patient Identification
3 DB
[ PD1 ] Additional Demographics
3 DB
[ { NTE } ] Notes and Comments (for Patient ID)
2 DB
[ --- PATIENT_VISIT begin


PV1 Patient Visit
3 DB
[ PV2 ] Patient Visit _ Additional Info
3 DB
] --- PATIENT_VISIT end


] --- PATIENT end


{ --- ORDER begin


ORC Common Order
4 DB
[{ --- TIMING begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
}] --- TIMING end


BPO Blood Product Order
4 DB
[ { NTE } ] Notes and Comments (for BPO)
2 DB
[{ --- PRODUCT_STATUS begin


BTX Blood Product Transfusion/Disposition Status
4 DB
[ { NTE } ] Notes and Comments (for BTX)
2 DB
}] --- PRODUCT_STATUS end


} --- ORDER end


4.20.6 BRT _ Blood Product Transfusion/Disposition Acknowledgment (Event O32)

BRT^O32^BRT_O32 Description Status Chapter DB Ref.
MSH Message Header
2 DB
MSA Message Acknowledgment
2 DB
[ { ERR } ] Error
2 DB
[ { SFT } ] Software
2 DB
[ { NTE } ] Notes and Comments (for Response Header)
2 DB
[ --- RESPONSE begin


[ PID ] Patient Identification
3 DB
[{ --- ORDER begin


ORC Common Order
4 DB
[{ --- TIMING begin


TQ1 Timing/Quantity
4 DB
[ { TQ2 } ] Timing/Quantity Order Sequence
4 DB
}] --- TIMING end


[ BPO ] Blood Product Order
4 DB
[ { BTX } ] Blood Product Transfusion/Disposition Status
4 DB
}] --- ORDER end


] --- RESPONSE end


4.21 TRANSFUSION SERVICE (BLOOD BANK) SEGMENTS

4.21.1 BPO _ Blood Product Order Segment

Blood product order messages require additional information that is not available in other standard HL7 order messages. Blood product order messages need to contain accompanying details regarding the blood product component, such as special processing requirements (e.g. irradiation and leukoreduction) and the amount of the blood product to be administered.

The following table presents various use cases surrounding blood product orders.

Universal Service ID [ISBT-128 Product Code] Blood Product Processing Requirements Quantity Blood Product Amount Units
002^Red Blood Cells Leukoreduced 2
Ml
002^Red Blood Cells Leukoreduced 1 60 Ml
002^Red Blood Cells Irradiated 2 15 Ml
002^Red Blood Cells Leukoreduced 1

020^Platelets Leukoreduced

Irradiated

6

024^ Apheresis Platelets Irradiated 1

002^Red Blood Cells
1

Factor VIII
2 910 IU

HL7 Attribute Table _ BPO _ Blood product order

SEQ LEN DT OPT RP/# TBL# ITEM # ELEMENT NAME DB Ref.
1 4 SI R

01700 Set ID _ BPO DB
2 250 CWE R

01701 BP Universal Service ID DB
3 250 CWE O Y 0508 01702 BP Processing Requirements DB
4 5 NM R

01703 BP Quantity DB
5 5 NM O

01704 BP Amount DB
6 250 CE O

01705 BP Units DB
7 26 TS O

01706 BP Intended Use Date/Time DB
8 80 PL O

01707 BP Intended Dispense From Location DB
9 250 XAD O

01708 BP Intended Dispense From Address DB
10 26 TS O

01709 BP Requested Dispense Date/Time DB
11 80 PL O

01710 BP Requested Dispense To Location DB
12 250 XAD O

01711 BP Requested Dispense To Address DB
13 250 CWE O Y 0509 01712 BP Indication for Use DB
14 1 ID O
0136 01713 BP Informed Consent Indicator DB

4.21.1.0 BPO field definitions

4.21.1.1 BPO-1 Set ID _ BPO (SI) 01700

Definition: This field contains the sequence number for the BPO segment within the message. For the first order transmitted, the sequence number shall be 1; for the second order, it shall be 2; and so on.

4.21.1.2 BPO-2 BP Universal Service Identifier (CWE) 01701

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

Definition: This field contains the identifier code for the requested blood product. This can be based on local and/or "universal" codes. We recommend the "universal" procedure identifier. The structure of this CWE data type is described in the control section. The preferred coding system is the ISBT 128 Product Code.

Blood Product Orders for commercial products, such as Rh Immune Globulin or Factor VIII concentrate, are not at this time defined in an international or national coding system as are blood products. Therefore, locally defined codes can be used for the Universal Service Identifier for commercial products.

4.21.1.3 BPO-3 BP Processing Requirements (CWE) 01702

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

Definition: This field contains additional information about the blood component class associated with the Universal Service ID. The placer of the order can specify any required processing of the blood product that must be completed prior to transfusion to the intended recipient. Refer to User-Defined Table 0508 - Blood Product Processing Requirements for suggested values.

User-defined Table 0508 - Blood Product Processing Requirements

Value Description Comment
LR Leukoreduced
IR Irradiated
CS CMV Safe
FR Fresh unit
AU Autologous Unit
DI Directed Unit
HL HLA Matched
CM CMV Negative
HB Hemoglobin S Negative
WA Washed
IG IgA Deficient

4.21.1.4 BPO-4 BP Quantity (NM) 01703

Definition: This field contains the number of blood products ordered.

4.21.1.5 BPO-5 BP Amount (NM) 01704

Definition: This field contains the ordered amount (volume) associated with each quantity of blood product.

4.21.1.6 BPO-6 BP Units (CE) 01705

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: This field contains the units of measure for the blood product amount. (See Chapter 7 for more details about reporting units.) This field specifies the units of measure for volume of a blood component (i.e. 50 ml) or the units of measure or dosage of a commercial product (i.e. 910 I.U. - International Units - of Factor VIII Concentrate).

4.21.1.7 BPO-7 BP Intended Use Date/Time (TS) 01706

Components: <Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>

Definition: This field specifies the date/time that the placer intends to use the blood product that is being ordered.

This is the time when the placer expects the product to be available within the transfusion service. For example, the product should be available for use, but not dispensed on this date/time.

4.21.1.8 BPO-8 BP Intended Dispense From Location (PL) 01707

Components: <Point of Care (IS)> ^ <Room (IS)> ^ <Bed (IS)> ^ <Facility (HD)> ^ <Location Status (IS)> ^ <Person Location Type (IS)> ^ <Building (IS)> ^ <Floor (IS)> ^ <Location Description (ST)> ^ <Comprehensive Location Identifier (EI)> ^ <Assigning Authority for Location (HD)>

Subcomponents for Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Comprehensive Location Identifier (EI): <Entity Identifier (ST)> & <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Assigning Authority for Location (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Definition: This field contains the location from which the blood component is to be dispensed.

4.21.1.9 BPO-9 BP Intended Dispense From Address (XAD) 01708

Components: <Street Address (SAD)> ^ <Other Designation (ST)> ^ <City (ST)> ^ <State or Province (ST)> ^ <Zip or Postal Code (ST)> ^ <Country (ID)> ^ <Address Type (ID)> ^ <Other Geographic Designation (ST)> ^ <County/Parish Code (IS)> ^ <Census Tract (IS)> ^ <Address Representation Code (ID)> ^ <DEPRECATED-Address Validity Range (DR)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)>

Subcomponents for Street Address (SAD): <Street or Mailing Address (ST)> & <Street Name (ST)> & <Dwelling Number (ST)>

Subcomponents for DEPRECATED-Address Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>

Note subcomponent contains sub-subcomponents

Subcomponents for Effective Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Expiration Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Definition: This field contains the actual address of the location from which the blood component is to be dispensed.

4.21.1.10 BPO-10 BP Requested Dispense Date/Time (TS) 01709

Components: <Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>

Definition: This field specifies the date/time that the requested blood products must be ready to dispense. This date/time may be different from the Intended use date/time. For example, the patient may be scheduled to come in for a transfusion at a specified time. However, the placer would request that the blood product be ready to dispense prior to that time in order to have the blood component ready for transfusion at the scheduled time. The field may also be used to indicate that the placer is now ready to pick up the ordered blood product and is requesting the blood product be ready to dispense at that time.

4.21.1.11 BPO-11 BP Requested Dispense to Location (PL) 01710

Components: <Point of Care (IS)> ^ <Room (IS)> ^ <Bed (IS)> ^ <Facility (HD)> ^ <Location Status (IS)> ^ <Person Location Type (IS)> ^ <Building (IS)> ^ <Floor (IS)> ^ <Location Description (ST)> ^ <Comprehensive Location Identifier (EI)> ^ <Assigning Authority for Location (HD)>

Subcomponents for Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Comprehensive Location Identifier (EI): <Entity Identifier (ST)> & <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Assigning Authority for Location (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Definition: This field contains the inpatient or outpatient location to which the blood component is to be dispensed. The default dispense to location is the current census location for the patient.

4.21.1.12 BPO-12 BP Requested Dispense to Address (XAD) 01711

Components: <Street Address (SAD)> ^ <Other Designation (ST)> ^ <City (ST)> ^ <State or Province (ST)> ^ <Zip or Postal Code (ST)> ^ <Country (ID)> ^ <Address Type (ID)> ^ <Other Geographic Designation (ST)> ^ <County/Parish Code (IS)> ^ <Census Tract (IS)> ^ <Address Representation Code (ID)> ^ <DEPRECATED-Address Validity Range (DR)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)>

Subcomponents for Street Address (SAD): <Street or Mailing Address (ST)> & <Street Name (ST)> & <Dwelling Number (ST)>

Subcomponents for DEPRECATED-Address Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>

Note subcomponent contains sub-subcomponents

Subcomponents for Effective Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Expiration Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Definition: This field contains the actual address of the location to which the blood component is to be dispensed. The default dispense to location is the current census location for the patient.

4.21.1.13 BPO-13 BP Indication for Use (CWE) 01712

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

Definition: This is a coded optional field. The value indicates the reason that the blood product was ordered. This information is helpful for prospective review or retrospective studies of blood product ordering practices of the ordering provider by the Quality Assurance Department and/ or Transfusion Committee. Refer to User-Defined Table 0509 - Indication For Use for suggested values.

User-defined Table 0509 _ Indication For Use

Value Description Comment

No suggested values

4.21.1.14 BPO-14 BP Informed Consent Indicator (ID) 01713

This field indicates whether consent for the transfusion has been obtained. Refer to HL7 table 0136 -Yes/no indicator as defined in Chapter 2.

4.21.2 BPX _ Blood Product Dispense Status Segment

In the processing of blood products, it is necessary for the transfusion service and the placer system to communicate information. The status messages need to contain additional information regarding the blood products requested, such as the unique donation ID, product code, blood type, expiration date/time of the blood product, and current status of the product. This segment is similar to an OBX segment, but contains additional attributes.

HL7 Attribute Table _ BPX _ Blood product dispense status

SEQ LEN DT OPT RP/# TBL# ITEM # ELEMENT NAME DB Ref.
1 4 SI R

01714 Set ID _ BPX DB
2 250 CWE R
0510 01715 BP Dispense Status DB
3 1 ID R
0511 01716 BP Status DB
4 26 TS R

01717 BP Date/Time of Status DB
5 22 EI C

01718 BC Donation ID DB
6 250 CNE C

01719 BC Component DB
7 250 CNE O

01720 BC Donation Type / Intended Use DB
8 250 CWE C
0512 01721 CP Commercial Product DB
9 250 XON C

01722 CP Manufacturer DB
10 22 EI C

01723 CP Lot Number DB
11 250 CNE O

01724 BP Blood Group DB
12 250 CNE O Y
01725 BC Special Testing DB
13 26 TS O

01726 BP Expiration Date/Time DB
14 5 NM R

01727 BP Quantity DB
15 5 NM O

01728 BP Amount DB
16 250 CE O

01729 BP Units DB
17 22 EI O

01730 BP Unique ID DB
18 80 PL O

01731 BP Actual Dispensed To Location DB
19 250 XAD O

01732 BP Actual Dispensed To Address DB
20 250 XCN O

01733 BP Dispensed to Receiver DB
21 250 XCN O

01734 BP Dispensing Individual DB

4.21.2.0 BPX field definitions

The BP prefix in the element name indicates that the attribute pertains to any type of blood product. A blood product is defined as any type of blood component or commercially prepared blood product that is prepared and dispensed from the transfusion service.

The BC prefix in the element name indicates that the attribute pertains only to blood components. A blood component is defined as the whole or any part of a blood donation. For example, from one whole blood donation, the unit of whole blood can be fractionated into red blood cells, plasma and platelets with each component contained in separate bags. These types of blood products are assigned a unique donation identification number as well as a product code that indicates the type of component contained in the bag.

The CP prefix in the element name indicates that the attribute pertains only to Commercial Products. A commercial product is defined as a commercially manufactured product, such as blood derivatives ( Rh Immune Globulin, Factor VIII Concentrate or Blood Recipient Sets or Filters). These types of products are tracked by manufacturer and lot number and are not necessarily assigned a unique donation number.

4.21.2.1 BPX-1 Set ID _ BPX (SI) 01714

Definition: This field contains the sequence number for the BPX segment under the related BPO segment. For the first blood product dispense status transmitted, the sequence number shall be 1; for the second product dispense status, it shall be 2; and so on.

4.21.2.2 BPX-2 BP Dispense Status (CWE) 01715

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

Definition: This field indicates the current status of the specified blood product as indicated by the filler or placer. For example, the first status change of a product that may trigger a Blood Product Dispense Status Message occurs when it first becomes linked to a patient and is ready to dispense. The placer system may use the Blood Product Dispense Status Message to request the transfusion service to dispense the product. When the blood product is delivered or issued to a patient, the status of the blood product would be changed to indicate that it has now been "dispensed." Refer to HL7 Table 0510 - Blood Product Dispense Status for valid entries.

HL7 Table 0510 - Blood Product Dispense Status

Value Description Comment
RI Received into inventory (for specified patient) Status determined by Filler
RD Reserved and ready to dispense Status determined by Filler
RS Reserved (ordered and product allocated for the patient) Status determined by Filler
RE Released (no longer allocated for the patient) Status determined by Placer or Filler
DS Dispensed to patient location Status determined by Filler
RA Returned unused/no longer needed Status determined by Filler
RL Returned unused/keep linked to patient for possible use later Status determined by Filler
WA Wasted (product no longer viable) Status determined by Filler
PT Presumed transfused (dispensed and not returned) Status determined by Filler
CR Released into inventory for general availability Status determined by Filler
RQ Request to dispense blood product Status determined by Placer

4.21.2.3 BPX-3 BP Status (ID) 01716

Definition: The most commonly used message status values in a BPX will be preliminary and final. A status is considered preliminary until a blood product has reached a final disposition for the patient. For example, when the product is first cross-matched and a status message is sent, it would be considered preliminary. When the product is dispensed to the patient, that status would also be considered preliminary. However, once the product is transfused, the status would be considered final. The status of a blood product (BPX-2) can continue to change and the previous status should be overwritten until it reaches a final status (BPX-3). Refer to HL7 Table 0511 - BP Observation Status Codes Interpretation for valid entries.

HL7 Table 0511 - BP Observation Status Codes Interpretation

Value Description Comment
C Record coming over is a correction and thus replaces a final status
D Deletes the BPX record
F Final status; Can only be changed with a corrected status
O Order detail description only (no status)
P Preliminary status
W Post original as wrong, e.g., transmitted for wrong patient

4.21.2.4 BPX-4 BP Date/Time of Status (TS) 01717

Components: <Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>

Definition: This field indicates the date and time that the status of the blood component was changed. For example, if the blood component had a status, of "RD" (Ready to Dispense), the date and time in this field would indicate the date and time that component was made ready to dispense by the filler system.

4.21.2.5 BPX-5 BC Donation ID (EI) 01718

Components: <Entity Identifier (ST)> ^ <Namespace ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID Type (ID)>

Definition: The Donation ID is the unique identification number assigned to a blood donation. The Donation ID depends upon the bar code labeling system used for the component. There are currently two blood component labeling standards: ABC CODABAR and ISBT 128. The preferred labeling system is ISBT 128. If using ISBT 128, the Donation ID is an internationally unique identifier consisting of the following 13 characters:

Country Code & Collection Facility - 5 characters

Donation Year - 2 characters

Serial Number - 6 characters

This field is required for blood components and is not applicable for commercial product messages.

4.21.2.6 BPX-6 BC Component (CNE) 01719

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

Definition: The Component field includes an identifier and description of the specific blood component.

The identifier consists of a numeric or alphanumeric product code that represents the type of blood component. The coding system will be determined by the bar code labeling system on the particular component of blood. The preferred coding system is ISBT 128.

If using ISBT 128 labeling standard, the product code will consist of an 8-character alphanumeric code, starting with an alpha character and including the component class, donation type/intended use and division indicator.

If using CODABAR product labeling standard, the product code is a 5-digit number.

This field is required for blood components and is not applicable for commercial product messages.

4.21.2.7 BPX-7 BC Donation Type / Intended Use (CNE) 01720

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

Definition: This field indicates the type of donation or collection/intended use. This value is populated from Table 5 -Type of Donation in the ISBT 128 Application Specification. The default value is "0", meaning "Not specified." Other values indicate whether the blood product (1) is an allogeneic unit from a volunteer donor, (2) is intended for a specific recipient but may be crossed over and used for another recipient, or (3) is an autologous donation intended only for that particular recipient.

This field is optional for blood component messages and is not applicable for commercial product messages.

4.21.2.8 BPX-8 CP Commercial Product (CWE) 01721

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

Definition: This field contains the code and/or text to identify a commercial product. Examples of commercial products are blood derivatives such as Rh Immune Globulin and Factor VIII concentrate, Leukoreduction filters, and blood administration sets.

Either code and/or text may be absent. However, the code is always placed in the first component position and any free text in the second component. Thus, a component delimiter must precede free text without a code. Free text can be utilized if no update is to occur. Refer To User-Defined Table 0512 - Commercial Product for suggested values.

User-defined Table 0512 _ Commercial Product

Value Description Comment

No suggested values

This field is required for commercial blood products and is not applicable for blood component messages.

4.21.2.9 BPX-9 CP Manufacturer (XON) 01722

Components: <Organization Name (ST)> ^ <Organization Name Type Code (IS)> ^ <DEPRECATED-ID Number (NM)> ^ <Check Digit (NM)> ^ <Check Digit Scheme (ID)> ^ <Assigning Authority (HD)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name Representation Code (ID)> ^ <Organization Identifier (ST)>

Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Definition: This field identifies the manufacturer of the commercial product. The manufacturer may be different from the supplier of the commercial product.

This field is required for commercial blood products and is not applicable for blood component messages.

4.21.2.10 BPX-10 CP Lot Number (EI) 01723

Components: <Entity Identifier (ST)> ^ <Namespace ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID Type (ID)>

Definition: This field identifies the lot number for blood derivatives or commercially supplied items used as accessories to transfusion.

This field is required for commercial blood products and is not applicable for blood component messages.

4.21.2.11 BPX-11 BP Blood Group (CNE) 01724

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

Definition: This field indicates the ABO/Rh blood group of the blood component. The preferred values for the blood group are the specified values in Table 3A - Encodation of ABO/Rh Blood Group in the ISBT 128 Application Specification.

This field is required for blood components and certain commercial products (such as solvent detergent plasma).

4.21.2.12 BPX-12 BC Special Testing (CNE) 01725

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

Definition: This is a repeating field to allow multiple entries for special testing that was performed on the blood component. The preferred coding system for Special Testing is defined in the ISBT 128 Application Specification. Proposals have been developed and will soon be published by ICCBBA, Inc. for the encodation of other antigen and antibody specificities, including HLA, platelet, red cell and other types of markers.

This field is optional for blood component messages. It is not applicable for non-commercial product messages.

Refer to Table I3 - Special Testing Codes of the ISBT 128 Application Specification.

4.21.2.13 BPX-13 BP Expiration Date/Time (TS) 01726

Components: <Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>

Definition: This field specifies the date and time that the blood product expires. The blood product is no longer considered acceptable once the expiration date has been reached unless cleared by the transfusion service medical staff.

This field applies to blood components as well as commercial products. There are a few commercial products that have no expiration date. Therefore, the field is not required for those specific products.

4.21.2.14 BPX-14 BP Quantity (NM) 01727

Definition: This field indicates the number of blood components or commercial products to which this message refers.

4.21.2.15 BPX-15 BP Amount (NM) 01728

Definition: This field contains the ordered amount (volume) associated with each quantity of a blood component or commercial product to which this message refers.

4.21.2.16 BPX-16 BP Units (CE) 01729

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: This field contains the units of measure for the blood product amount. (See Chapter 7 for more details about reporting units.) This field specifies the units of measure for volume of a blood component (i.e. 50 ml) or the units of measure or dosage of a commercial product (i.e. 910 I.U. - International Units - of Factor VIII Concentrate).

4.21.2.17 BPX-17 BP Unique ID (EI) 01730

Components: <Entity Identifier (ST)> ^ <Namespace ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID Type (ID)>

Definition: This field is a unique system-generated number assigned to the blood product to which the message is referring. Each time the status is updated, the new message should replace the previous message if the Blood Product Unique ID is the same. If the Blood Product Unique ID is different, it indicates that the status applies to a different blood product.

The sending and receiving systems must agree upon the use of this field.

4.21.2.18 BPX-18 BP Actual Dispensed to Location (PL) 01731

Components: <Point of Care (IS)> ^ <Room (IS)> ^ <Bed (IS)> ^ <Facility (HD)> ^ <Location Status (IS)> ^ <Person Location Type (IS)> ^ <Building (IS)> ^ <Floor (IS)> ^ <Location Description (ST)> ^ <Comprehensive Location Identifier (EI)> ^ <Assigning Authority for Location (HD)>

Subcomponents for Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Comprehensive Location Identifier (EI): <Entity Identifier (ST)> & <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Assigning Authority for Location (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Definition: This field contains the inpatient or outpatient location to which the blood product was actually dispensed. The default value is the current census location for the patient.

4.21.2.19 BPX-19 BP Actual Dispensed to Address (XAD) 01732

Components: <Street Address (SAD)> ^ <Other Designation (ST)> ^ <City (ST)> ^ <State or Province (ST)> ^ <Zip or Postal Code (ST)> ^ <Country (ID)> ^ <Address Type (ID)> ^ <Other Geographic Designation (ST)> ^ <County/Parish Code (IS)> ^ <Census Tract (IS)> ^ <Address Representation Code (ID)> ^ <DEPRECATED-Address Validity Range (DR)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)>

Subcomponents for Street Address (SAD): <Street or Mailing Address (ST)> & <Street Name (ST)> & <Dwelling Number (ST)>

Subcomponents for DEPRECATED-Address Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>

Note subcomponent contains sub-subcomponents

Subcomponents for Effective Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Expiration Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Definition: This field contains the actual address of the location to which the blood product was actually dispensed.

4.21.2.20 BPX-20 BP Dispensed to Receiver (XCN) 01733

Components: <ID Number (ST)> ^ <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR) (ST)> ^ <DEPRECATED-Degree (e.g., MD) (IS)> ^ <Source Table (IS)> ^ <Assigning Authority (HD)> ^ <Name Type Code (ID)> ^ <Identifier Check Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name Representation Code (ID)> ^ <Name Context (CE)> ^ <DEPRECATED-Name Validity Range (DR)> ^ <Name Assembly Order (ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^ <Professional Suffix (ST)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or Department (CWE)>

Subcomponents for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname (ST)> & <Surname Prefix From Partner/Spouse (ST)> & <Surname From Partner/Spouse (ST)>

Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Name Context (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>

Subcomponents for DEPRECATED-Name Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>

Note subcomponent contains sub-subcomponents

Subcomponents for Effective Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Expiration Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>

Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>

Definition: This is the person who picked up and transported the blood component(s) or commercial product(s). The code for the receiver is recorded as a XCN data type. This field can be free text. In this case, the receiver's name must be recorded as the second through fourth components of the field.

4.21.2.21 BPX-21 BP Dispensing Individual (XCN) 01734

Components: <ID Number (ST)> ^ <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR) (ST)> ^ <DEPRECATED-Degree (e.g., MD) (IS)> ^ <Source Table (IS)> ^ <Assigning Authority (HD)> ^ <Name Type Code (ID)> ^ <Identifier Check Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name Representation Code (ID)> ^ <Name Context (CE)> ^ <DEPRECATED-Name Validity Range (DR)> ^ <Name Assembly Order (ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^ <Professional Suffix (ST)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or Department (CWE)>

Subcomponents for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname (ST)> & <Surname Prefix From Partner/Spouse (ST)> & <Surname From Partner/Spouse (ST)>

Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Name Context (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>

Subcomponents for DEPRECATED-Name Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>

Note subcomponent contains sub-subcomponents

Subcomponents for Effective Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Expiration Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>

Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>

Definition: This field identifies the individual who is dispensing the blood component or commercial product.

4.21.3 BTX _ Blood Product Transfusion/Disposition Segment

HL7 Attribute Table _ BTX _ Blood Product Transfusion/Disposition

SEQ LEN DT OPT RP/# TBL# ITEM # ELEMENT NAME DB Ref.
1 4 SI R

01735 Set ID _ BTX DB
2 22 EI C

01736 BC Donation ID DB
3 250 CNE C

01737 BC Component DB
4 250 CNE C

01738 BC Blood Group DB
5 250 CWE C
0512 01739 CP Commercial Product DB
6 250 XON C

01740 CP Manufacturer DB
7 22 EI C

01741 CP Lot Number DB
8 5 NM R

01742 BP Quantity DB
9 5 NM O

01743 BP Amount DB
10 250 CE O

01744 BP Units DB
11 250 CWE R
0513 01745 BP Transfusion/Disposition Status DB
12 1 ID R
0511 01746 BP Message Status DB
13 26 TS R

01747 BP Date/Time of Status DB
14 250 XCN O

01748 BP Administrator DB
15 250 XCN O

01749 BP Verifier DB
16 26 TS O

01750 BP Transfusion Start Date/Time of Status DB
17 26 TS O

01751 BP Transfusion End Date/Time of Status DB
18 250 CWE O Y 0514 01752 BP Adverse Reaction Type DB
19 250 CWE O
0515 01753 BP Transfusion Interrupted Reason DB

4.21.3.0 BTX field definitions

The BP prefix in the element name indicates that the attribute pertains to any type of blood product. A blood product is defined as any type of blood component or commercially prepared blood product that is prepared and dispensed from the transfusion service.

The BC prefix in the element name indicates that the attribute pertains only to blood components. A blood component is defined as any part or all of a whole blood donation. For example, from one whole blood donation, the unit of whole blood can be fractionated into red blood cells, plasma and platelets with each component contained in separate bags. These types of blood products are always assigned a unique donation identification number as well as a product code that indicates the type of component contained in the bag.

The CP prefix in the element name indicates that the attribute pertains only to Commercial Products. A commercial product is defined as a commercially manufactured product, such as blood derivatives ( Rh Immune Globulin, Factor VIII Concentrate or Blood Recipient Sets or Filters). These types of products are tracked by manufacturer and lot number and are not necessarily assigned a unique donation number.

4.21.3.1 BTX-1 Set ID _ BTX (SI) 01735

Definition: This field contains the sequence number for the BTX segment under the related BPO segment. For the first product transfusion/disposition transmitted, the sequence number shall be 1; for the second product transfusion/disposition, it shall be 2; and so on.

4.21.3.2 BTX-2 BC Donation ID (EI) 01736

Components: <Entity Identifier (ST)> ^ <Namespace ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID Type (ID)>

Definition: The donation ID is the unique identification number assigned to a blood donation. The Donation ID depends upon the bar code labeling system used for the component. There are currently two blood component labeling standards: ABC CODABAR and ISBT 128. The preferred labeling system is ISBT 128. If using ISBT 128, the Donation ID is an internationally unique identifier consisting of the following 13 characters:

Country Code & Collection Facility - 5 characters

Donation Year - 2 characters

Serial Number - 6 characters

This is required for blood components and is not applicable for commercial product messages.

4.21.3.3 BTX-3 BC Component (CNE) 01737

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

Definition: The Blood Component field includes an identifier and description of the specific blood component.

The identifier consists of a numeric or alphanumeric product code that represents the type of blood component. The coding system will be determined by the bar code labeling system on the particular component of blood. The preferred coding system is ISBT 128.

If using ISBT 128 labeling standard, the product code will consist of an 8-character alphanumeric code, starting with an alpha character and including the component class, donation type/intended use and division indicator.

If using CODABAR product labeling standard, the product code is a 5-digit number.

This field is required for blood components and is not applicable for commercial product messages.

4.21.3.4 BTX-4 BC Blood Group (CNE) 01738

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

Definition: This field indicates the ABO/Rh blood group of the blood component. The preferred values for the blood group are the specified values in Table 3A - Encodation of ABO/Rh Blood Group in the ISBT 128 Application Specification.

This field is required for blood components and certain commercial products (such as solvent detergent plasma).

4.21.3.5 BTX-5 CP Commercial Product (CWE) 01739

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

Definition: This field contains the code and/or text to identify a commercial product. Examples of commercial products are blood derivatives such as Rh Immune Globulin and Factor VIII concentrate, Leukoreduction filters, and blood administration sets.

Either code and/or text may be absent. However, the code is always placed in the first component position and any free text in the second component. Thus, free text without a code must be preceded by a component delimiter. Free text can be utilized if no update is to occur. Refer to User-Defined Table 0512 - Commercial Product for suggested values.

This field is required for commercial blood products and is not applicable to blood component messages.

4.21.3.6 BTX-6 CP Manufacturer (XON) 01740

Components: <Organization Name (ST)> ^ <Organization Name Type Code (IS)> ^ <DEPRECATED-ID Number (NM)> ^ <Check Digit (NM)> ^ <Check Digit Scheme (ID)> ^ <Assigning Authority (HD)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name Representation Code (ID)> ^ <Organization Identifier (ST)>

Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Definition: This field identifies the manufacturer of the commercial product. The manufacturer may not be the same as the supplier of the commercial product.

This field is required for commercial blood products and is not applicable for blood component messages.

4.21.3.7 BTX-7 CP Lot Number (EI) 01741

Components: <Entity Identifier (ST)> ^ <Namespace ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID Type (ID)>

Definition: This field identifies the lot number for blood derivatives or commercially supplied items used as accessories to transfusion.

This field is required for commercial blood products and is not applicable for blood component messages.

4.21.3.8 BTX-8 BP Quantity (NM) 01742

Definition: This field indicates the number of blood components or commercial products to which the message refers.

4.21.3.9 BTX-9 BP Amount (NM) 01743

Definition: This field contains the amount (volume) associated with each blood component or commercial product. When included in this segment, it may be used to indicate the volume of the blood component or product that was actually transfused.

4.21.3.10 BTX-10 BP Units (CE) 01744

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

Definition: This field contains the units of measure for the blood component or commercial product amount. (See Chapter 7 for more details about reporting units.) This specifies the units of measure for volume of a blood component (i.e. 50 ml) or the units of measure or dosage of a commercial product (i.e. 910 I.U. - International Units - of Factor VIII Concentrate.

4.21.3.11 BTX-11 BP Transfusion/Disposition Status (CWE) 01745

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

Definition: This field indicates the current status of the specified blood product as indicated by the placer. For example, the placer may return the blood product to the transfusion service unused because an IV could not be started. The blood component may have been entered, but the line was clogged and could not be used, in which case the component must be wasted. A final status would indicate that the product has actually been "transfused." Refer to HL7 Table 0513 - Blood Product Transfusion/Disposition Status for suggested values.

HL7 Table 0513 - Blood Product Transfusion/Disposition Status

Value Description Comment
RA Returned unused/no longer needed
RL Returned unused/keep linked to patient for possible use later
WA Wasted (product no longer viable)
TX Transfused
TR Transfused with adverse reaction

4.21.3.12 BTX-12 BP Message Status (ID) 01746

Definition: The most commonly used message status values in a BTX will be preliminary and final. A status is considered preliminary until a blood product has reached a final disposition for the patient. For example, when the product is first cross-matched and a status message is sent, it would be considered preliminary. When the product is dispensed to the patient, that status would also be considered preliminary. However, once the product is transfused, the status would be considered final. The status of a blood product (BTX-11) can continue to change and the previous result should be overwritten until it reaches a final status (BTX-12). Refer to HL7 Table 0511 _ BP Observation Status Codes Interpretation for valid entries.

4.21.3.13 BTX-13 BP Date/Time of Status (TS) 01747

Components: <Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>

Definition: This field indicates the date and time that the status of the blood component was changed. For example, if the blood component had a status of "TX" (Transfused), the date and time in this field would indicate the date and time the component was transfused by the placer system.

4.21.3.14 BTX-14 BP Transfusion Administrator (XCN) 01748

Components: <ID Number (ST)> ^ <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR) (ST)> ^ <DEPRECATED-Degree (e.g., MD) (IS)> ^ <Source Table (IS)> ^ <Assigning Authority (HD)> ^ <Name Type Code (ID)> ^ <Identifier Check Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name Representation Code (ID)> ^ <Name Context (CE)> ^ <DEPRECATED-Name Validity Range (DR)> ^ <Name Assembly Order (ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^ <Professional Suffix (ST)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or Department (CWE)>

Subcomponents for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname (ST)> & <Surname Prefix From Partner/Spouse (ST)> & <Surname From Partner/Spouse (ST)>

Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Name Context (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>

Subcomponents for DEPRECATED-Name Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>

Note subcomponent contains sub-subcomponents

Subcomponents for Effective Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Expiration Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>

Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>

Definition: This field contains the identity of the individual who administers the transfusion of the blood product. If the code is sent as a local code, it should be unique and unambiguous. This field can be free text to permit capture without table update. In this case, the administrator's name must be recorded as the second through fourth components of the field.

4.21.3.15 BTX-15 BP Transfusion Verifier (XCN) 01749

Components: <ID Number (ST)> ^ <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR) (ST)> ^ <DEPRECATED-Degree (e.g., MD) (IS)> ^ <Source Table (IS)> ^ <Assigning Authority (HD)> ^ <Name Type Code (ID)> ^ <Identifier Check Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name Representation Code (ID)> ^ <Name Context (CE)> ^ <DEPRECATED-Name Validity Range (DR)> ^ <Name Assembly Order (ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^ <Professional Suffix (ST)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or Department (CWE)>

Subcomponents for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname (ST)> & <Surname Prefix From Partner/Spouse (ST)> & <Surname From Partner/Spouse (ST)>

Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Name Context (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>

Subcomponents for DEPRECATED-Name Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>

Note subcomponent contains sub-subcomponents

Subcomponents for Effective Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Expiration Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>

Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>

Definition: This field contains the identity of the individual who assists in the identification of the patient and verification of the product information prior to transfusion of the blood product. If the ID Number is sent as a local code, it should be unique and unambiguous. This field can be free text to permit capture without table update. In this case, the verifier's name must be recorded as the second through fourth components of the field.

4.21.3.16 BTX-16 BP Transfusion Start Date/Time of Status (TS) 01750

Components: <Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>

Definition: This field indicates the date and time that the administrator started the transfusion of the blood component or commercial product.

4.21.3.17 BTX-17 BP Transfusion End Date/Time of Status (TS) 01751

Components: <Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>

Definition: This field indicates the date and time that the transfusion of the blood component or commercial product was completed or stopped.

4.21.3.18 BTX-18 BP Adverse Reaction Type (CWE) 01752

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

Definition: This field contains the type of adverse reaction that the recipient of the blood product experienced. Refer to User-Defined Table 0514 - Transfusion Adverse Reaction for suggested values.

User-Defined Table 0514 _ Transfusion Adverse Reaction

Value Description Comment
ABOINC ABO Incompatible Transfusion Reaction
ACUTHEHTR Acute Hemolytic Transfusion Reaction
ALLERGIC1 Allergic Reaction _ First
ALLERGIC2 Allergic Reaction _ Recurrent
ALLERGICR Allergic Reaction _ Repeating
ANAPHYLAC Anaphylactic Reaction
BACTCONTAM Reaction to Bacterial Contamination
DELAYEDHTR Delayed Hemolytic Transfusion Reaction
DELAYEDSTR Delayed Serological Transfusion Reaction
GVHD Graft vs Host Disease _ Transfusion _ Associated
HYPOTENS Non-hemolytic Hypotensive Reaction
NONHTR1 Non-Hemolytic Fever Chill Transfusion Reaction _ First
NONHTR2 Non-Hemolytic Fever Chill Transfusion Reaction _ Recurrent
NONHTRREC Non-Hemolytic Fever Chill Transfusion Reaction _ Repeating
NONIMMUNE Non-Immune Hemolysis
NONSPEC Non-Specific, Non-Hemolytic Transfusion Reaction
NORXN No Evidence of Transfusion Reaction
PTP Posttransfusion Purpura
VOLOVER Symptoms most likely due to volume overload

4.21.3.19 BTX-19 BP Transfusion Interrupted Reason (CWE) 01753

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

Definition: This field contains the reason that the transfusion of the blood product was interrupted. Refer to User-Defined Table 0515 - Transfusion Interrupted Reason for suggested values.

User-defined Table 0515 _ Transfusion Interrupted Reason

Value Description Comment

No suggested values

4.22 TRANSFUSION SERVICE (BLOOD BANK) TRANSACTION FLOW DIAGRAM

The following diagram depicts the message flow of the blood product messages.

4.23 TABLES LISTINGS

4.23.1 HL7 Table 0119 - Order Control Codes

Referenced in 4.4.1.1 _ Order Control Codes

Notes:

1 The order control value field

2 "F": Values originate from the filler and are not restricted to be sent only to the placer. "P": Values originate from the placer or other application with placer privileges (as agreed in interface negotiation).

3 See table notes in section 4.5.1.1.1 for explanation of codes.

HL7 Table 0119 - Order control codes

Value1 Description Event/Message Type Originator2 Field Note3
NW New order/service
P l


ORM^O01^ORM_O01



OMG^O19^OMG_O19



OML^O21^OML_O21



OMD^O03^OMD_O03



OMS^O05^OMS_O05



OMN^O07^OMN_O07



OMP^O09^OMP_O09

OK Order/service accepted & OK
F l


ORR^O02^ORR_O02



ORG^O20^ORG_O20



ORD^O04^ORD_O04



ORS^O06^ORS_O06



ORN^O08^ORN_O08



ORP^O10^ORP_O10



RRE^O12^RRE_O12



RRD^O14^RRD_O14



RRG^O16^RRG_O16



RRA^O18^RRA_O18

UA Unable to accept order/service
F n


ORR^O02^ORR_O02



ORG^O20^ORG_O20



ORD^O04^ORD_O04



ORS^O06^ORS_O06



ORN^O08^ORN_O08



ORP^O10^ORP_O10



RRE^O12^RRE_O12



RRD^O14^RRD_O14

UA Unable to accept order/service
F n


RRG^O16^RRG_O16



RRA^O18^RRA_O18

PR Previous Results with new order/service
P v


ORM^O01^ORM_O01



OMG^O19^OMG_O19



OML^O21^OML_O21

CA Cancel order/service request
P a


ORM^O01^ORM_O01



OMG^O19^OMG_O19



OML^O21^OML_O21



OMD^O03^OMD_O03



OMS^O05^OMS_O05



OMN^O07^OMN_O07



OMP^O09^OMP_O09

OC Order/service canceled
F


ORM^O01^ORM_O01



OMG^O19^OMG_O19



OML^O21^OML_O21



OMS^O05^OMS_O05



OMN^O07^OMN_O07



RDE^O11^RDE_O11



RDS^O13^RDS_O13



RGV^O15^RGV_O15



RAS^O01^RAS_O01

CR Canceled as requested
F


ORR^O02^ORR_O02



ORG^O20^ORG_O20



ORD^O04^ORD_O04



ORS^O06^ORS_O06



ORN^O08^ORN_O08



ORP^O10^ORP_O10

UC Unable to cancel
F b


ORR^O02^ORR_O02



ORG^O20^ORG_O20



ORD^O04^ORD_O04



ORS^O06^ORS_O06



ORN^O08^ORN_O08



ORP^O10^ORP_O10

DC Discontinue order/service request
P c


ORM^O01^ORM_O01



OMG^O19^OMG_O19



OML^O21^OML_O21



OMD^O03^OMD_O03



OMS^O05^OMS_O05



OMN^O07^OMN_O07



OMP^O09^OMP_O09

OD Order/service discontinued
F


ORM^O01^ORM_O01



OMG^O19^OMG_O19



OML^O21^OML_O21



OMS^O05^OMS_O05



OMN^O07^OMN_O07



RDE^O11^RDE_O11



RDS^O13^RDS_O13



RGV^O15^RGV_O15



RAS^O01^RAS_O01

DR Discontinued as requested
F


ORR^O02^ORR_O02



ORG^O20^ORG_O20



ORD^O04^ORD_O04



ORS^O06^ORS_O06



ORN^O08^ORN_O08



ORP^O10^ORP_O10

UD Unable to discontinue
F


ORR^O02^ORR_O02



ORG^O20^ORG_O20



ORD^O04^ORD_O04



ORS^O06^ORS_O06



ORN^O08^ORN_O08



ORP^O10^ORP_O10

HD Hold order request
P


ORM^O01^ORM_O01



OMG^O19^OMG_O19



OML^O21^OML_O21



OMD^O03^OMD_O03



OMP^O09^OMP_O09

OH Order/service held
F


ORM^O01^ORM_O01



OMG^O19^OMG_O19



OML^O21^OML_O21



OMS^O05^OMS_O05








OMN^O07^OMN_O07








RDE^O11^RDE_O11



RDS^O13^RDS_O13



RGV^O15^RGV_O15



RAS^O01^RAS_O01

UH Unable to put on hold
F


ORR^O02^ORR_O02



ORG^O20^ORG_O20



ORD^O04^ORD_O04



ORS^O06^ORS_O06



ORN^O08^ORN_O08



ORP^O10^ORP_O10

HR On hold as requested
F


ORR^O02^ORR_O02



ORG^O20^ORG_O20



ORD^O04^ORD_O04



ORS^O06^ORS_O06



ORN^O08^ORN_O08



ORP^O10^ORP_O10

RL Release previous hold
P


ORM^O01^ORM_O01



OMG^O19^OMG_O19



OML^O21^OML_O21



OMD^O03^OMD_O03



OMS^O05^OMS_O05



OMN^O07^OMN_O07



OMP^O09^OMP_O09

OE Order/service released
F


ORM^O01^ORM_O01



OMG^O19^OMG_O19



OML^O21^OML_O21



OMS^O05^OMS_O05



OMN^O07^OMN_O07



RDE^O11^RDE_O11



RDS^O13^RDS_O13



RGV^O15^RGV_O15



RAS^O01^RAS_O01

OR Released as requested
F


ORR^O02^ORR_O02



ORG^O20^ORG_O20



ORD^O04^ORD_O04



ORS^O06^ORS_O06



ORN^O08^ORN_O08



ORP^O10^ORP_O10

UR Unable to release
F


ORR^O02^ORR_O02



ORG^O20^ORG_O20



ORD^O04^ORD_O04



ORS^O06^ORS_O06



ORN^O08^ORN_O08



ORP^O10^ORP_O10

RP Order/service replace request
P "e,d"


ORM^O01^ORM_O01



OMG^O19^OMG_O19



OML^O21^OML_O21



OMS^O05^OMS_O05



OMN^O07^OMN_O07



OMP^O09^OMP_O09

RU Replaced unsolicited
F "f,d"


ORM^O01^ORM_O01



OMG^O19^OMG_O19



OML^O21^OML_O21



OMS^O05^OMS_O05



OMN^O07^OMN_O07



RDE^O11^RDE_O11

RO Replacement order
"P,F" "g,d"


ORM^O01^ORM_O01



OMG^O19^OMG_O19



OML^O21^OML_O21



OMS^O05^OMS_O05



OMN^O07^OMN_O07



OMP^O09^OMP_O09



RDE^O11^RDE_O11

RQ Replaced as requested
F "d,e"


ORR^O02^ORR_O02



ORG^O20^ORG_O20



ORS^O06^ORS_O06



ORN^O08^ORN_O08



ORP^O10^ORP_O10

UM Unable to replace
F


ORR^O02^ORR_O02



ORG^O20^ORG_O20



ORS^O06^ORS_O06



ORN^O08^ORN_O08



ORP^O10^ORP_O10

PA Parent order/service
F I


ORM^O01^ORM_O01



OMG^O19^OMG_O19



OML^O21^OML_O21



OMS^O05^OMS_O05








OMP^O09^OMP_O09



RDE^O11^RDE_O11



RGV^O15^RGV_O15



RAS^O01^RAS_O01



ORU^R01^ORU_R01

CH Child order/service
"F,P" I


ORM^O01^ORM_O01



OMG^O19^OMG_O19



OML^O21^OML_O21



OMS^O05^OMS_O05








RDE^O11^RDE_O11



RGV^O15^RGV_O15



RAS^O01^RAS_O01



ORU^R01^ORU_R01

XO Change order/service request
P


ORM^O01^ORM_O01



OMG^O19^OMG_O19



OML^O21^OML_O21



OMD^O03^OMD_O03



OMS^O05^OMS_O05



OMN^O07^OMN_O07








OMP^O09^OMP_O09

XX Order/service changed, unsol.
F


ORM^O01^ORM_O01



OMG^O19^OMG_O19



OML^O21^OML_O21



OMS^O05^OMS_O05



OMN^O07^OMN_O07








RDE^O11^RDE_O11



RDS^O13^RDS_O13








RGV^O15^RGV_O15



RAS^O01^RAS_O01






UX Unable to change
F


ORR^O02^ORR_O02



ORG^O20^ORG_O20



ORD^O04^ORD_O04



ORS^O06^ORS_O06



ORN^O08^ORN_O08



ORP^O10^ORP_O10

XR Changed as requested
F


ORR^O02^ORR_O02



ORG^O20^ORG_O20



ORD^O04^ORD_O04



ORS^O06^ORS_O06



ORN^O08^ORN_O08



ORP^O10^ORP_O10

DE Data errors
"P,F"


ORM^O01^ORM_O01



OMG^O19^OMG_O19



ORR^O02^ORR_O02



ORG^O20^ORG_O20



ORS^O06^ORS_O06



ORN^O08^ORN_O08



ORP^O10^ORP_O10



RRE^O12^RRE_O12



RRD^O14^RRD_O14



RRG^O16^RRG_O16



RRA^O18^RRA_O18

RE Observations/Performed Service to follow
"P,F" j


ORM^O01^ORM_O01



OMG^O19^OMG_O19



OML^O21^OML_O21



RDE^O11^RDE_O11



RDS^O13^RDS_O13



RGV^O15^RGV_O15



RAS^O01^RAS_O01



ORU^R01^ORU_R01






RR Request received ORR^O02^ORR_O02 "P,F" k
SR Response to send order/service status request
F


ORR^O02^ORR_O02



OSR^Q06^OSR_Q06

SS Send order/service status request
P


ORM^O01^ORM_O01



OMG^O19^OMG_O19



OML^O21^OML_O21

SC Status changed
"F,P"


ORM^O01^ORM_O01



OMG^O19^OMG_O19



OML^O21^OML_O21

SN Send order/service number
F l


ORM^O01^ORM_O01



OMG^O19^OMG_O19



OML^O21^OML_O21



OMS^O05^OMS_O05








RDE^O11^RDE_O11

NA Number assigned
P l


ORR^O02^ORR_O02



ORG^O20^ORG_O20



ORS^O06^ORS_O06



ORN^O08^ORN_O08



RRE^O12^RRE_O12






CN Combined result ORU^R01^ORU_R01 F m
RF Refill order/service request
F o


ORM^O01^ORM_O01



OMP^O09^OMP_O09



RDE^O11^RDE_O11

AF Order/service refill request approval
P p


ORR^O02^ORR_O02



RRE^O12^RRE_O12

DF Order/service refill request denied
P q


ORR^O02^ORR_O02



ORP^O10^ORP_O10



RRE^O12^RRE_O12

FU Order/service refilled, unsolicited
F r


ORM^O01^ORM_O01



RDE^O11^RDE_O11

OF Order/service refilled as requested
F s


ORR^O02^ORR_O02



ORP^O10^ORP_O10

UF Unable to refill
F t


ORR^O02^ORR_O02



ORP^O10^ORP_O10

LI Link order/service to patient care problem or goal

u


ORM^O01^ORM_O01



OMG^O19^OMG_O19



OML^O21^OML_O21



OMS^O05^OMS_O05








OMP^O09^OMP_O09



RDE^O11^RDE_O11



RDS^O13^RDS_O13



RAS^O01^RAS_O01

UN Unlink order/service from patient care problem or goal

u


ORM^O01^ORM_O01



OMG^O19^OMG_O19



OML^O21^OML_O21



OMS^O05^OMS_O05



OMN^O07^OMN_O07



OMP^O09^OMP_O09



RDE^O11^RDE_O11



RDS^O13^RDS_O13



RAS^O01^RAS_O01






OP Notification of order for outside dispense OMP^O09^OMP_O09 P w





PY Notification of replacement order for outside dispense OMP^O09^OMP_O09 P,F w

4.23.2 HL7 Table 0292 _ Vaccines administered

Referenced in 4.18.1.1 Using RXA-5 in vaccine messages

HL7 Table 0292 - Vaccines administered (code = CVX)(parenteral, unless oral is noted)

Code Short Description Comment / Full Vaccine Name
54 adenovirus, type 4 adenovirus vaccine, type 4, live, oral
55 adenovirus, type 7 adenovirus vaccine, type 7, live, oral
82 adenovirus, NOS1 adenovirus vaccine, NOS
24 anthrax anthrax vaccine
19 BCG Bacillus Calmette-Guerin vaccine
27 botulinum antitoxin botulinum antitoxin