The Demo site for our new HL7 Version 2+ (plus) Standard
visit the hl7 website

Draft Website - For Review Purposes Only

Order Entry: General, Laboratory, Dietary, Supply, Blood Transfusion

Co-Chair:

Hans Buitendijk

Cerner Corporation

Co-Chair:

David Burgess

LabCorp

Co-Chair:

Lorraine Constable

HL7 Canada

Co-Chair:

Robert Hausam MD

Hausam Consulting

Co-Chair:

Patrick Loyd

ICode Solutions

Co-Chair:

Ken McCaslin

Accenture Federal

Chapter Co-Chair:

Riki Merrick

Vernetzt, LLC

Co-Chair:

J.D. Nolen

Children’s Mercy Hospital

Editor

Hans Buitendijk

Cerner Corporation

Sponsoring Committee:

Orders & Observations

List Server:

ord@lists.hl7.org



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.

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.

Glossary

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

Observation segment:

An OBX segment defined in Chapter 7.

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. In HL7 terms, an order is defined as an ORC segment in conjunction with a single order detail segment such as OBR, RXO or RXE.

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.

Placer:

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

Placer order group:

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

Order Number:

An identifier that uniquely identifies an order as represented by an ORC segment and its matching order detail segment. Although traditionally called an order number, the identifier is not required to be all digits, it may contain alpha as well as numeric characters.

Examples:

Example 1

Order Number

Group Number

Parent

Parent Order

111

Bag One

123

1

111

Bag Two

234

1

111

Bag Three

345

1

111


Example 2

Order Number

Group Number

Med One

123

99 (script number)

Med Two

456

99 (script number)


Example 3

Order Number

Group Number

CBC

987

88 (requisition number)

Glucose

654

88 (requisition number)

Electrolytes

321

88 (requisition number)


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.6 and later to maintain consistent section numbering for reference from other chapters.



General Trigger Events & Message Definitions

The triggering events that follow are all served by the OMG (General Clinical Order Message), OML (Laboratory Order Message, Laboratory Order for Multiple Orders Related to a Single Specimen, Laboratory Order for Multiple Orders Related to a Single Container of a Specimen, Specimen Shipment Centric Laboratory Order), OMI (Imaging Order Message), OPL (Population/Location-Based Laboratory Order Message), OSU (Order Status Update) and OMQ (General Order Message with Document Payload) message definitions along with the following acknowledgment messages served by the ORG (General Clinical Order Acknowledgement Message), ORL (General Laboratory Order Response Message to any OML message, Laboratory Order Response Message To A Multiple Order Related To Single Specimen OML message, Laboratory Order Response Message to a Single Container of a Specimen OML message, Specimen Shipment Centric Laboratory Order Response Message to Specimen Shipment OML message), ORI (Imaging Order Response Message to Any OMI message), OPR (Population/Location-Based Laboratory Order Acknowledgment Message) and ORX (General Order Message with Document Payload Acknowledgement Message) message definitions.

Each triggering event is listed below, along with the segments that comprise the messages. The notation used to describe the sequence, optionality, and repeating of segments is described in Chapter 2, "Format for defining abstract messages."

ORM – general order message

Attention: Retained for backwards compatibility only as of v2.4.and withdrawn as of v2.7. Refer to OMG, OML, OMD, OMS, OMN, OMI, and OMP instead.

ORR – general order response message response to any ORM

Attention: Retained for backwards compatibility only as of v2.5 and withdrawn as of v2.7. Refer to ORG, ORL, ORD, ORS, ORN, ORI, and ORP instead.

OSQ/OSR- query response for order

Attention: Retained for backwards compatibility only as of v2.4.and withdrawn as of v2.7. Refer to Chapter 5.

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. OMG messages can originate also with a placer, filler, or an interested third party.

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

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

For example:

  • Diagnostic laboratories referring tests to another lab for either confirmation of results (HIV, etc.) or due to not being equipped to do the tests (genetic testing, etc.).

  • Diagnostic laboratories sending test results to Knowledge Bases for the automated generation of diagnostic comments for inclusion into the lab report.

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

When one wants to convey with the detailed order message a supporting document, such as a CDA, one can transmit that document using the OBX associated with the ORC/OBR(s) using OBX-11 = "O" Order Detail Description Only, using either OBX-2 = "ED" or "RP".

The Device segment (DEV) provides additional device information for a device referenced in one or more of the PRT segments in the message (using PRT-10 Participation Device to match DEV-2 Unique Device Identifier or PRT-22 Participation Device Type using DEV-3 Device Type).

OMG^O19^OMG_O19: General Clinical Order Message
HL7 MessageStructure Table - OMG_O19
Segment Cardinality Must Implement Status
OMG_O19
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
NTE 0..* additional
PATIENT 0..1 additional
PID 1..1 Yes additional
PD1 0..1 additional
PRT 0..* additional
NTE 0..* additional
ARV 0..* B
GT1 0..1 additional
AL1 0..* additional
OCCUPATIONAL_DATA_FOR_HEALTH 0..1 additional
OH1 0..* additional
OH2 0..* additional
OH3 0..1 additional
OH4 0..* additional
NEXT_OF_KIN 0..* additional
NK1 1..1 Yes additional
OH2 0..* additional
OH3 0..1 additional
PATIENT_VISIT 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
PRT 0..* additional
INSURANCE 0..* additional
IN1 1..1 Yes additional
IN2 0..1 additional
IN3 0..1 additional
ORDER 1..* Yes additional
ORC 1..1 Yes additional
NTE 0..* additional
PRT 0..* additional
OBR 1..1 Yes additional
NTE 0..* additional
PRT 0..* additional
CTD 0..1 additional
DG1 0..* additional
REL 0..1 additional
SGH 0..1 additional
SGT 0..1 additional
FT1 0..* additional
CTI 0..* additional
BLG 0..1 additional
TIMING 0..* additional
TQ1 1..1 Yes additional
TQ2 0..* additional
OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
NTE 0..* additional
SPECIMEN 0..* additional
SPM 1..1 Yes additional
NTE 0..* additional
SPECIMEN_OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
CONTAINER 0..* additional
SAC 1..1 Yes additional
NTE 0..* additional
CONTAINER_OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
PRIOR_RESULT 0..* additional
AL1 0..* additional
PATIENT_PRIOR 0..1 additional
PID 1..1 Yes additional
PD1 0..1 additional
ARV 0..* B
PRT 0..* additional
PATIENT_VISIT_PRIOR 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
PRT 0..* additional
ORDER_PRIOR 1..* Yes additional
ORC 1..1 Yes additional
PRT 0..* additional
OBR 1..1 Yes additional
NTE 0..* additional
CTD 0..1 additional
TIMING_PRIOR 0..* additional
TQ1 1..1 Yes additional
TQ2 0..* additional
ORDER_DETAIL_PARTICIPATION_PRIOR 0..* additional
PRT 1..1 Yes additional
DEV 0..* additional
OBSERVATION_PRIOR 1..* Yes additional
OBX 1..1 Yes additional
PRT 0..* additional
NTE 0..* additional
DEVICE 0..* additional
DEV 1..1 Yes additional
OBX 0..* additional

Original Mode Acknowledgement Choreography for OMG^O19^OMG_O19

Send Application Ack: ORG^O20^ORG_O20

Enhanced Mode Acknowledgement Choreography for OMG^O19^OMG_O19

When the MSH-15 value of an OMG^O19^OMG_O19 message is AL or ER or SU, an ACK^O19^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an OMG^O19^OMG_O19 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an OMG^O19^OMG_O19 message is AL or ER or SU, an ORG^O20^ORG_O20 or OSU^O52^OSU_O52 message SHALL be sent as an application ack.

When the MSH-16 value of an OMG^O19^OMG_O19 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^O19^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ORG^O20^ORG_O20 or OSU^O52^OSU_O52
NE, AL, ER, SU (none)

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

There is not supposed to be an Application Level acknowledgement to an Application Level Acknowledgement message. In Enhanced Mode, MSH-16 SHALL always be set to NE (Never).

ORG^O20^ORG_O20: General Clinical Order Acknowledgment Message
HL7 MessageStructure Table - ORG_O20
Segment Cardinality Must Implement Status
ORG_O20
MSH 1..1 Yes additional
MSA 1..1 Yes additional
ARV 0..* additional
ERR 0..* additional
SFT 0..* additional
UAC 0..1 additional
NTE 0..* additional
RESPONSE 0..1 additional
PATIENT 0..1 additional
PID 1..1 Yes additional
NTE 0..* additional
PRT 0..* additional
ARV 0..* B
ORDER 1..* Yes additional
ORC 1..1 Yes additional
PRT 0..* additional
CTI 0..* additional
TIMING 0..* additional
TQ1 1..1 Yes additional
TQ2 0..* additional
OBSERVATION_GROUP 0..1 additional
OBR 1..1 Yes additional
PRT 0..* additional
NTE 0..* additional
SPECIMEN 0..* additional
SPM 1..1 Yes additional
SAC 0..* additional

Original Mode Acknowledgement Choreography for ORG^O20^ORG_O20

Send Immediate Ack: ACK^O20^ACK

Enhanced Mode Acknowledgement Choreography for ORG^O20^ORG_O20

When the MSH-15 value of an ORG^O20^ORG_O20 message is AL or ER or SU, an ACK^O20^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ORG^O20^ORG_O20 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ORG^O20^ORG_O20 message is AL or ER or SU, a message SHALL be sent as an application ack.

When the MSH-16 value of an ORG^O20^ORG_O20 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^O20^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack:
NE, AL, ER, SU (none)

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.

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, which is sent after the OBR with the current order (the segments PID, PD1, PV1, PV2, etc, 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.

The IPC segment in this trigger is used to transmit imaging process identifiers for observations that will result in DICOM information objects (e.g., slide images). Note that the IPC-1 Accession Identifier is the identifier assigned by the Order Filler for associating the DICOM results with other laboratory information and processes; it may or may not be the same as the SPM-30 Accession ID or the SAC-2 Accession Identifier.

In relationship to triggers O21, O33, O35, and O39 this message/trigger (O21) should be used where an order with multiple samples and optionally multiple containers per order item are to be communicated, but not against a complete specimen shipment (O39)

When one wants to convey with the detailed order message a supporting document, such as a CDA, one can transmit that document using the OBX associated with the ORC/OBR(s) using OBX-11 = "O" Order Detail Description Only, using either OBX-2 = "ED" or "RP".

The Device segment (DEV) provides additional device information for a device referenced in one or more of the PRT segments in the message (using PRT-10 Participation Device to match DEV-2 Unique Device Identifier or PRT-22 Participation Device Type using DEV-3 Device Type).

OML^O21^OML_O21: Laboratory Order Message
HL7 MessageStructure Table - OML_O21
Segment Cardinality Must Implement Status
OML_O21
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
NTE 0..* additional
PATIENT 0..1 additional
PID 1..1 Yes additional
PD1 0..1 additional
PRT 0..* additional
NTE 0..* additional
ARV 0..* B
GT1 0..1 additional
AL1 0..* additional
OCCUPATIONAL_DATA_FOR_HEALTH 0..1 additional
OH1 0..* additional
OH2 0..* additional
OH3 0..1 additional
OH4 0..* additional
NEXT_OF_KIN 0..* additional
NK1 1..1 Yes additional
OH2 0..* additional
OH3 0..1 additional
PATIENT_VISIT 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
PRT 0..* additional
INSURANCE 0..* additional
IN1 1..1 Yes additional
IN2 0..1 additional
IN3 0..1 additional
ORDER 1..* Yes additional
ORC 1..1 Yes additional
NTE 0..* additional
PRT 0..* additional
FT1 0..* additional
CTI 0..* additional
BLG 0..1 additional
TIMING 0..* additional
TQ1 1..1 Yes additional
TQ2 0..* additional
OBSERVATION_REQUEST 0..1 additional
OBR 1..1 Yes additional
TCD 0..1 additional
NTE 0..* additional
PRT 0..* additional
CTD 0..1 additional
DG1 0..* additional
REL 0..1 additional
IPC 0..1 additional
SGH 0..1 additional
SGT 0..1 additional
OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
TCD 0..1 additional
NTE 0..* additional
SPECIMEN 0..* additional
SPM 1..1 Yes additional
NTE 0..* additional
SPECIMEN_OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
CONTAINER 0..* additional
SAC 1..1 Yes additional
NTE 0..1 additional
CONTAINER_OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
PRIOR_RESULT 0..* additional
AL1 0..* additional
PATIENT_PRIOR 0..1 additional
PID 1..1 Yes additional
PD1 0..1 additional
PRT 0..* additional
ARV 0..* B
PATIENT_VISIT_PRIOR 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
PRT 0..* additional
ORDER_PRIOR 1..* Yes additional
ORC 1..1 Yes additional
PRT 0..* additional
OBR 1..1 Yes additional
NTE 0..* additional
OBSERVATION_PARTICIPATION_PRIOR 0..* additional
PRT 1..1 Yes additional
DEV 0..*
TIMING_PRIOR 0..* additional
TQ1 1..1 Yes additional
TQ2 0..* additional
OBSERVATION_PRIOR 1..* Yes additional
OBX 1..1 Yes additional
PRT 0..* additional
NTE 0..* additional
DEVICE 0..* additional
DEV 1..1 Yes additional
OBX 0..* additional

Original Mode Acknowledgement Choreography for OML^O21^OML_O21

Send Application Ack: ORL^O22^ORL_O22

Enhanced Mode Acknowledgement Choreography for OML^O21^OML_O21

When the MSH-15 value of an OML^O21^OML_O21 message is AL or ER or SU, an ACK^O21^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an OML^O21^OML_O21 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an OML^O21^OML_O21 message is AL or ER or SU, an ORL^O22^ORL_O22 or ORL^O53^ORL_O53 or OSU^O52^OSU_O52 message SHALL be sent as an application ack.

When the MSH-16 value of an OML^O21^OML_O21 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^O21^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ORL^O22^ORL_O22 or ORL^O53^ORL_O53 or OSU^O52^OSU_O52
NE, AL, ER, SU (none)

ORL – general laboratory order response message to any OML

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.

Two message structures are available to acknowledge OML_O21:

  • With patient segments

  • Optionally without patient segments

Patient Segments Required

There is not supposed to be an Application Level acknowledgement to an Application Level Acknowledgement message. In Enhanced Mode, MSH-16 SHALL always be set to NE (Never).

ORL^O22^ORL_O22: General Laboratory Order Acknowledgment Message (Patient Required)
HL7 MessageStructure Table - ORL_O22
Segment Cardinality Must Implement Status
ORL_O22
MSH 1..1 Yes additional
MSA 1..1 Yes additional
ARV 0..* additional
ERR 0..* additional
SFT 0..* additional
UAC 0..1 additional
NTE 0..* additional
RESPONSE 0..1 additional
PID 1..1 Yes additional
PRT 0..* additional
ARV 0..* B
ORDER 0..* additional
ORC 1..1 Yes additional
PRT 0..* additional
TIMING 0..* additional
TQ1 1..1 Yes additional
TQ2 0..* additional
OBSERVATION_REQUEST 0..1 additional
OBR 1..1 Yes additional
PRT 0..* additional
SPECIMEN 0..* additional
SPM 1..1 Yes additional
SAC 0..* additional

Original Mode Acknowledgement Choreography for ORL^O22^ORL_O22

Send Immediate Ack: ACK^O22^ACK

Enhanced Mode Acknowledgement Choreography for ORL^O22^ORL_O22

When the MSH-15 value of an ORL^O22^ORL_O22 message is AL or ER or SU, an ACK^O22^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ORL^O22^ORL_O22 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ORL^O22^ORL_O22 message is AL or ER or SU, a message SHALL be sent as an application ack.

When the MSH-16 value of an ORL^O22^ORL_O22 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^O22^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack:
NE, AL, ER, SU (none)

Patient Segments Optional

There is not supposed to be an Application Level acknowledgement to an Application Level Acknowledgement message. In Enhanced Mode, MSH-16 SHALL always be set to NE (Never).

ORL^O53^ORL_O53: General Laboratory Order Acknowledgment Message (Patient Optional)
HL7 MessageStructure Table - ORL_O53
Segment Cardinality Must Implement Status
ORL_O53
MSH 1..1 Yes additional
MSA 1..1 Yes additional
ARV 0..1 additional
ERR 0..* additional
SFT 0..* additional
UAC 0..1 additional
NTE 0..* additional
RESPONSE 0..1 additional
PATIENT 0..1 additional
PID 1..1 Yes additional
PRT 0..* additional
ORDER 0..* additional
ORC 1..1 Yes additional
PRT 0..* additional
TIMING 0..* additional
TQ1 1..1 Yes additional
TQ2 0..* additional
OBSERVATION_REQUEST 0..1 additional
OBR 1..1 Yes additional
PRT 0..* additional
SPECIMEN 0..* additional
SPM 1..1 Yes additional
SAC 0..* additional

Original Mode Acknowledgement Choreography for ORL^O53^ORL_O53

Send Immediate Ack: ACK^O53^ACK

Enhanced Mode Acknowledgement Choreography for ORL^O53^ORL_O53

When the MSH-15 value of an ORL^O53^ORL_O53 message is AL or ER or SU, an ACK^O53^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ORL^O53^ORL_O53 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ORL^O53^ORL_O53 message is AL or ER or SU, a message SHALL be sent as an application ack.

When the MSH-16 value of an ORL^O53^ORL_O53 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^O53^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack:
NE, AL, ER, SU (none)

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.

The IPC segment in this trigger is used to transmit imaging process identifiers for observations that will result in DICOM information objects (e.g., slide images). Note that the IPC-1 Accession Identifier is the identifier assigned by the Order Filler for associating the DICOM results with other laboratory information and processes; it may or may not be the same as the SPM-30 Accession ID or the SAC-2 Accession Identifier.

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

When one wants to convey with the detailed order message a supporting document, such as a CDA, one can transmit that document using the OBX associated with the ORC/OBR(s) using OBX-11 = "O" Order Detail Description Only, using either OBX-2 = "ED" or "RP".

The Device segment (DEV) provides additional device information for a device referenced in one or more of the PRT segments in the message (using PRT-10 Participation Device to match DEV-2 Unique Device Identifier or PRT-22 Participation Device Type using DEV-3 Device Type).

OML^O33^OML_O33: Laboratory Order – Multiple Order Per Specimen Message
HL7 MessageStructure Table - OML_O33
Segment Cardinality Must Implement Status
OML_O33
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
NTE 0..* additional
PATIENT 0..1 additional
PID 1..1 Yes additional
PD1 0..1 additional
PRT 0..* additional
NTE 0..* additional
ARV 0..* B
GT1 0..1 additional
AL1 0..* additional
OCCUPATIONAL_DATA_FOR_HEALTH 0..1 additional
OH1 0..* additional
OH2 0..* additional
OH3 0..1 additional
OH4 0..* additional
NEXT_OF_KIN 0..* additional
NK1 1..1 Yes additional
OH2 0..* additional
OH3 0..1 additional
PATIENT_VISIT 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
PRT 0..* additional
INSURANCE 0..* additional
IN1 1..1 Yes additional
IN2 0..1 additional
IN3 0..1 additional
SPECIMEN 1..* Yes additional
SPM 1..1 Yes additional
NTE 0..* additional
SPECIMEN_OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
SPECIMEN_CONTAINER 0..* additional
SAC 1..1 Yes additional
NTE 0..* additional
ORDER 1..* Yes additional
ORC 1..1 Yes additional
NTE 0..* additional
PRT 0..* additional
FT1 0..* additional
CTI 0..* additional
BLG 0..1 additional
TIMING 0..* additional
TQ1 1..1 Yes additional
TQ2 0..* additional
OBSERVATION_REQUEST 0..1 additional
OBR 1..1 Yes additional
TCD 0..1 additional
NTE 0..* additional
PRT 0..* additional
DG1 0..* additional
REL 0..1 additional
IPC 0..1 additional
SGH 0..1 additional
SGT 0..1 additional
OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
TCD 0..1 additional
NTE 0..* additional
PRIOR_RESULT 0..* additional
AL1 0..* additional
PATIENT_PRIOR 0..1 additional
PID 1..1 Yes additional
PD1 0..1 additional
PRT 0..* additional
ARV 0..* B
PATIENT_VISIT_PRIOR 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
PRT 0..* additional
ORDER_PRIOR 1..* Yes additional
ORC 1..1 Yes additional
PRT 0..* additional
OBR 1..1 Yes additional
NTE 0..* additional
OBSERVATION_PARTICIPATION_PRIOR 0..* additional
PRT 1..1 Yes additional
DEV 0..* additional
TIMING_PRIOR 0..* additional
TQ1 1..1 Yes additional
TQ2 0..* additional
OBSERVATION_PRIOR 1..* Yes additional
OBX 1..1 Yes additional
PRT 0..* additional
NTE 0..* additional
DEVICE 0..* additional
DEV 1..1 Yes additional
OBX 0..* additional

Original Mode Acknowledgement Choreography for OML^O33^OML_O33

Send Application Ack: ORL^O34^ORL_O34

Enhanced Mode Acknowledgement Choreography for OML^O33^OML_O33

When the MSH-15 value of an OML^O33^OML_O33 message is AL or ER or SU, an ACK^O33^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an OML^O33^OML_O33 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an OML^O33^OML_O33 message is AL or ER or SU, an ORL^O34^ORL_O34 or ORL^O54^ORL_O54 or OSU^O52^OSU_O52 message SHALL be sent as an application ack.

When the MSH-16 value of an OML^O33^OML_O33 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^O33^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ORL^O34^ORL_O34 or ORL^O54^ORL_O54 or OSU^O52^OSU_O52
NE, AL, ER, SU (none)

ORL – Laboratory order response message to a multiple order related to single specimen OML (Event O34 and O54)

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.

Two message structures are available to acknowledge OML_O34:

  • With patient segments

  • Optionally without patient segments

Patient Segments Required

There is not supposed to be an Application Level acknowledgement to an Application Level Acknowledgement message. In Enhanced Mode, MSH-16 SHALL always be set to NE (Never).

ORL^O34^ORL_O34: Laboratory Order Acknowledgment Message – Multiple Order Per Specimen (Patient Required)
HL7 MessageStructure Table - ORL_O34
Segment Cardinality Must Implement Status
ORL_O34
MSH 1..1 Yes additional
MSA 1..1 Yes additional
ARV 0..* additional
ERR 0..* additional
SFT 0..* additional
UAC 0..1 additional
NTE 0..* additional
RESPONSE 0..1 additional
PID 1..1 Yes additional
PRT 0..* additional
ARV 0..* B
SPECIMEN 1..* Yes additional
SPM 1..1 Yes additional
SAC 0..* additional
SPECIMEN_OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
ORDER 0..* additional
ORC 1..1 Yes additional
PRT 0..* additional
TIMING 0..* additional
TQ1 1..1 Yes additional
TQ2 0..* additional
OBSERVATION_REQUEST 0..1 additional
OBR 1..1 Yes additional
PRT 0..* additional

Original Mode Acknowledgement Choreography for ORL^O34^ORL_O34

Send Immediate Ack: ACK^O34^ACK

Enhanced Mode Acknowledgement Choreography for ORL^O34^ORL_O34

When the MSH-15 value of an ORL^O34^ORL_O34 message is AL or ER or SU, an ACK^O34^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ORL^O34^ORL_O34 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ORL^O34^ORL_O34 message is AL or ER or SU, a message SHALL be sent as an application ack.

When the MSH-16 value of an ORL^O34^ORL_O34 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^O34^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack:
NE, AL, ER, SU (none)

Patient Segments Optional

There is not supposed to be an Application Level acknowledgement to an Application Level Acknowledgement message. In Enhanced Mode, MSH-16 SHALL always be set to NE (Never).

ORL^O54^ORL_O54: Laboratory Order Acknowledgment Message – Multiple Order Per Specimen (Patient Optional)
HL7 MessageStructure Table - ORL_O54
Segment Cardinality Must Implement Status
ORL_O54
MSH 1..1 Yes additional
MSA 1..1 Yes additional
ARV 0..* additional
ERR 0..* additional
SFT 0..* additional
UAC 0..1 additional
NTE 0..* additional
RESPONSE 0..1 additional
PATIENT 0..1 additional
PID 1..1 Yes additional
PRT 0..* additional
SPECIMEN 1..* Yes additional
SPM 1..1 Yes additional
SAC 0..* additional
SPECIMEN_OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
ORDER 0..* additional
ORC 1..1 Yes additional
PRT 0..* additional
TIMING 0..* additional
TQ1 1..1 Yes additional
TQ2 0..* additional
OBSERVATION_REQUEST 0..1 additional
OBR 1..1 Yes additional
PRT 0..* additional

Original Mode Acknowledgement Choreography for ORL^O54^ORL_O54

Send Immediate Ack: ACK^O54^ACK

Enhanced Mode Acknowledgement Choreography for ORL^O54^ORL_O54

When the MSH-15 value of an ORL^O54^ORL_O54 message is AL or ER or SU, an ACK^O54^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ORL^O54^ORL_O54 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ORL^O54^ORL_O54 message is AL or ER or SU, a message SHALL be sent as an application ack.

When the MSH-16 value of an ORL^O54^ORL_O54 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^O54^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack:
NE, AL, ER, SU (none)

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.

The IPC segment in this trigger is used to transmit imaging process identifiers for obsrevations that will result in DICOM information objects (e.g., slide images). Note that the IPC-1 Accession Identifier is the identifier assigned by the Order Filler for associating the DICOM results with other laboratory information and processes; it may or may not be the same as the SPM-30 Accession ID or the SAC-2 Accession Identifier.

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 and each container may have 1 to many orders with previous result(s) per container.

When one wants to convey with the detailed order message a supporting document, such as a CDA, one can transmit that document using the OBX associated with the ORC/OBR(s) using OBX-11 = "O" Order Detail Description Only, using either OBX-2 = "ED" or "RP".

The Device segment (DEV) provides additional device information for a device referenced in one or more of the PRT segments in the message (using PRT-10 Participation Device to match DEV-2 Unique Device Identifier or PRT-22 Participation Device Type using DEV-3 Device Type).

OML^O35^OML_O35: Laboratory Order – Multiple Order Per Container of Specimen Message
HL7 MessageStructure Table - OML_O35
Segment Cardinality Must Implement Status
OML_O35
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
NTE 0..* additional
PATIENT 0..1 additional
PID 1..1 Yes additional
PD1 0..1 additional
PRT 0..* additional
NTE 0..* additional
ARV 0..* B
GT1 0..1 additional
AL1 0..* additional
OCCUPATIONAL_DATA_FOR_HEALTH 0..1 additional
OH1 0..* additional
OH2 0..* additional
OH3 0..1 additional
OH4 0..* additional
NEXT_OF_KIN 0..* additional
NK1 1..1 Yes additional
OH2 0..* additional
OH3 0..1 additional
PATIENT_VISIT 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
PRT 0..* additional
INSURANCE 0..* additional
IN1 1..1 Yes additional
IN2 0..1 additional
IN3 0..1 additional
SPECIMEN 1..* Yes additional
SPM 1..1 Yes additional
NTE 0..* additional
SPECIMEN_OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
SPECIMEN_CONTAINER 1..* Yes additional
SAC 1..1 Yes additional
NTE 0..* additional
ORDER 1..* Yes additional
ORC 1..1 Yes additional
NTE 0..* additional
PRT 0..* additional
FT1 0..* additional
CTI 0..* additional
BLG 0..1 additional
TIMING 0..* additional
TQ1 1..1 Yes additional
TQ2 0..* additional
OBSERVATION_REQUEST 0..1 additional
OBR 1..1 Yes additional
TCD 0..1 additional
NTE 0..* additional
PRT 0..* additional
DG1 0..* additional
REL 1..1 Yes additional
IPC 0..1 additional
SGH 0..1 additional
SGT 0..1 additional
OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
TCD 0..1 additional
NTE 0..* additional
PRIOR_RESULT 0..* additional
AL1 0..* additional
PATIENT_PRIOR 0..1 additional
PID 1..1 Yes additional
PD1 0..1 additional
PRT 0..* additional
ARV 0..* B
PATIENT_VISIT_PRIOR 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
PRT 0..* additional
ORDER_PRIOR 1..* Yes additional
ORC 1..1 Yes additional
PRT 0..* additional
OBR 1..1 Yes additional
NTE 0..* additional
OBSERVATION_PARTICIPATION 0..* additional
PRT 1..1 Yes additional
DEV 0..* additional
TIMING_PRIOR 0..* additional
TQ1 1..1 Yes additional
TQ2 0..* additional
OBSERVATION_PRIOR 1..* Yes additional
OBX 1..1 Yes additional
PRT 0..* additional
NTE 0..* additional
DEVICE 0..* additional
DEV 1..1 Yes additional
OBX 0..* additional

Original Mode Acknowledgement Choreography for OML^O35^OML_O35

Send Application Ack: ORL^O36^ORL_O36

Enhanced Mode Acknowledgement Choreography for OML^O35^OML_O35

When the MSH-15 value of an OML^O35^OML_O35 message is AL or ER or SU, an ACK^O35^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an OML^O35^OML_O35 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an OML^O35^OML_O35 message is AL or ER or SU, an ORL^O36^ORL_O36 or ORL^O55^ORL_O55 or OSU^O52^OSU_O52 message SHALL be sent as an application ack.

When the MSH-16 value of an OML^O35^OML_O35 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^O35^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ORL^O36^ORL_O36 or ORL^O55^ORL_O55 or OSU^O52^OSU_O52
NE, AL, ER, SU (none)

ORL – Laboratory order response message to a single container of a specimen OML(Event O36 and O55)

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.

Two message structures are available to acknowledge OML_O36:

  • With patient segments

  • Optionally without patient segments

Patient Segments Required

There is not supposed to be an Application Level acknowledgement to an Application Level Acknowledgement message. In Enhanced Mode, MSH-16 SHALL always be set to NE (Never).

ORL^O36^ORL_O36: Laboratory Order Acknowledgment Message – Multiple Order Per Container of Specimen (Patient Required)
HL7 MessageStructure Table - ORL_O36
Segment Cardinality Must Implement Status
ORL_O36
MSH 1..1 Yes additional
MSA 1..1 Yes additional
ARV 0..* additional
ERR 0..* additional
SFT 0..* additional
UAC 0..1 additional
NTE 0..* additional
RESPONSE 0..1 additional
PID 1..1 Yes additional
PRT 0..* additional
ARV 0..* B
SPECIMEN 1..* Yes additional
SPM 1..1 Yes additional
NTE 0..* additional
SPECIMEN_OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
SPECIMEN_CONTAINER 1..* Yes additional
SAC 1..1 Yes additional
ORDER 0..* additional
ORC 1..1 Yes additional
PRT 0..* additional
TIMING 0..* additional
TQ1 1..1 Yes additional
TQ2 0..* additional
OBSERVATION_REQUEST 0..1 additional
OBR 1..1 Yes additional
PRT 0..* additional

Original Mode Acknowledgement Choreography for ORL^O36^ORL_O36

Send Immediate Ack: ACK^O36^ACK

Enhanced Mode Acknowledgement Choreography for ORL^O36^ORL_O36

When the MSH-15 value of an ORL^O36^ORL_O36 message is AL or ER or SU, an ACK^O36^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ORL^O36^ORL_O36 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ORL^O36^ORL_O36 message is AL or ER or SU, a message SHALL be sent as an application ack.

When the MSH-16 value of an ORL^O36^ORL_O36 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^O36^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack:
NE, AL, ER, SU (none)

Patient Segments Optional

There is not supposed to be an Application Level acknowledgement to an Application Level Acknowledgement message. In Enhanced Mode, MSH-16 SHALL always be set to NE (Never).

ORL^O55^ORL_O55: Laboratory Order Acknowledgment Message – Multiple Order Per Container of Specimen (Patient Optional)
HL7 MessageStructure Table - ORL_O55
Segment Cardinality Must Implement Status
ORL_O55
MSH 1..1 Yes additional
MSA 1..1 Yes additional
ARV 0..* additional
ERR 0..* additional
SFT 0..* additional
UAC 0..1 additional
NTE 0..* additional
RESPONSE 0..1 additional
PATIENT 0..1 additional
PID 1..1 Yes additional
PRT 0..* additional
SPECIMEN 1..* Yes additional
SPM 1..1 Yes additional
NTE 0..* additional
SPECIMEN_OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
SPECIMEN_CONTAINER 1..* Yes additional
SAC 1..1 Yes additional
ORDER 0..* additional
ORC 1..1 Yes additional
PRT 0..* additional
TIMING 0..* additional
TQ1 1..1 Yes additional
TQ2 0..* additional
OBSERVATION_REQUEST 0..1 additional
OBR 1..1 Yes additional
PRT 0..* additional

Original Mode Acknowledgement Choreography for ORL^O55^ORL_O55

Send Immediate Ack: ACK^O55^ACK

Enhanced Mode Acknowledgement Choreography for ORL^O55^ORL_O55

When the MSH-15 value of an ORL^O55^ORL_O55 message is AL or ER or SU, an ACK^O55^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ORL^O55^ORL_O55 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ORL^O55^ORL_O55 message is AL or ER or SU, a message SHALL be sent as an application ack.

When the MSH-16 value of an ORL^O55^ORL_O55 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^O55^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack:
NE, AL, ER, SU (none)

OML – Specimen shipment centric laboratory order (event O39)

The function of this message is to apply an order to all specimens in a shipment or a package within a shipment.

When one wants to convey with the detailed order message a supporting document, such as a CDA, one can transmit that document using the OBX associated with the ORC/OBR(s) using OBX-11 = "O" Order Detail Description Only, using either OBX-2 = "ED" or "RP".

The Device segment (DEV) provides additional device information for a device referenced in one or more of the PRT segments in the message (using PRT-10 Participation Device to match DEV-2 Unique Device Identifier or PRT-22 Participation Device Type using DEV-3 Device Type).

OML^O39^OML_O39: Specimen Shipment Centric Laboratory Order Message
HL7 MessageStructure Table - OML_O39
Segment Cardinality Must Implement Status
OML_O39
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
NTE 0..* additional
PATIENT 0..1 additional
PID 1..1 Yes additional
PD1 0..1 additional
PRT 0..* additional
NTE 0..* additional
ARV 0..* B
GT1 0..1 additional
AL1 0..* additional
OCCUPATIONAL_DATA_FOR_HEALTH 0..1 additional
OH1 0..* additional
OH2 0..* additional
OH3 0..1 additional
OH4 0..* additional
NEXT_OF_KIN 0..* additional
NK1 1..1 Yes additional
OH2 0..* additional
OH3 0..1 additional
PATIENT_VISIT 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
PRT 0..* additional
INSURANCE 0..* additional
IN1 1..1 Yes additional
IN2 0..1 additional
IN3 0..1 additional
ORDER 1..* Yes additional
ORC 1..1 Yes additional
NTE 0..* additional
PRT 0..* additional
FT1 0..* additional
CTI 0..* additional
BLG 0..1 additional
TIMING 0..* additional
TQ1 1..1 Yes additional
TQ2 0..* additional
OBSERVATION_REQUEST 0..1 additional
OBR 1..1 Yes additional
TCD 0..1 additional
NTE 0..* additional
PRT 0..* additional
CTD 0..1 additional
DG1 0..* additional
REL 1..1 Yes additional
OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
TCD 0..1 additional
NTE 0..* additional
SPECIMEN_SHIPMENT 0..* additional
SHP 1..1 Yes additional
SHIPMENT_OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
PACKAGE 1..* Yes additional
PAC 1..1 Yes additional
SPECIMEN_IN_PACKAGE 0..* additional
SPM 1..1 Yes additional
NTE 0..* additional
SPECIMEN_OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
SPECIMEN_CONTAINER_IN_PACKAGE 0..* additional
SAC 1..1 Yes additional
NTE 0..* additional
CONTAINER_OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
DEVICE 0..* additional
DEV 1..1 Yes additional
OBX 0..* additional

Original Mode Acknowledgement Choreography for OML^O39^OML_O39

Send Application Ack: ORL^O40^ORL_O40

Enhanced Mode Acknowledgement Choreography for OML^O39^OML_O39

When the MSH-15 value of an OML^O39^OML_O39 message is AL or ER or SU, an ACK^O39^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an OML^O39^OML_O39 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an OML^O39^OML_O39 message is AL or ER or SU, an ORL^O40^ORL_O40 or ORL^O56^ORL_O56 or OSU^O52^OSU_O52 message SHALL be sent as an application ack.

When the MSH-16 value of an OML^O39^OML_O39 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^O39^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ORL^O40^ORL_O40 or ORL^O56^ORL_O56 or OSU^O52^OSU_O52
NE, AL, ER, SU (none)

ORL – Specimen shipment centric laboratory order response message to specimen shipment OML(Event O40 and O56)

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.

Two message structures are available to acknowledge OML_O40:

  • With patient segments

  • Optionally without patient segments

Patient Segments Required

There is not supposed to be an Application Level acknowledgement to an Application Level Acknowledgement message. In Enhanced Mode, MSH-16 SHALL always be set to NE (Never).

ORL^O40^ORL_O40: Specimen Shipment Centric Laboratory Order Acknowledgment Message (Patient Required)
HL7 MessageStructure Table - ORL_O40
Segment Cardinality Must Implement Status
ORL_O40
MSH 1..1 Yes additional
MSA 1..1 Yes additional
ARV 0..* additional
ERR 0..* additional
SFT 0..* additional
UAC 0..1 additional
NTE 0..* additional
RESPONSE 0..1 additional
PATIENT 0..1 additional
PID 1..1 Yes additional
PRT 0..* additional
ARV 0..* B
ORDER 0..* additional
ORC 1..1 Yes additional
PRT 0..* additional
TIMING 0..* additional
TQ1 1..1 Yes additional
TQ2 0..* additional
OBSERVATION_REQUEST 0..1 additional
OBR 1..1 Yes additional
PRT 0..* additional
SPECIMEN_SHIPMENT 0..* additional
SHP 1..1 Yes additional
PACKAGE 1..* Yes additional
PAC 1..1 Yes additional
SPECIMEN_IN_PACKAGE 0..* additional
SPM 1..1 Yes additional
SPECIMEN_CONTAINER_IN_PACKAGE 0..* additional
SAC 1..1 Yes additional

Original Mode Acknowledgement Choreography for ORL^O40^ORL_O40

Send Immediate Ack: ACK^O40^ACK

Enhanced Mode Acknowledgement Choreography for ORL^O40^ORL_O40

When the MSH-15 value of an ORL^O40^ORL_O40 message is AL or ER or SU, an ACK^O40^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ORL^O40^ORL_O40 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ORL^O40^ORL_O40 message is AL or ER or SU, a message SHALL be sent as an application ack.

When the MSH-16 value of an ORL^O40^ORL_O40 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^O40^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack:
NE, AL, ER, SU (none)

Patient Segments Optional

There is not supposed to be an Application Level acknowledgement to an Application Level Acknowledgement message. In Enhanced Mode, MSH-16 SHALL always be set to NE (Never).

ORL^O56^ORL_O56: Specimen Shipment Centric Laboratory Order Acknowledgment Message (Patient Optional)
HL7 MessageStructure Table - ORL_O56
Segment Cardinality Must Implement Status
ORL_O56
MSH 1..1 Yes additional
MSA 1..1 Yes additional
ARV 0..* additional
ERR 0..* additional
SFT 0..* additional
UAC 0..1 additional
NTE 0..* additional
RESPONSE 0..1 additional
PATIENT 0..1 additional
PID 1..1 Yes additional
PRT 0..* additional
ORDER 0..* additional
ORC 1..1 Yes additional
PRT 0..* additional
TIMING 0..* additional
TQ1 1..1 Yes additional
TQ2 0..* additional
OBSERVATION_REQUEST 0..1 additional
OBR 1..1 Yes additional
PRT 0..* additional
SPECIMEN_SHIPMENT 0..* additional
SHP 1..1 Yes additional
PACKAGE 1..* Yes additional
PAC 1..1 Yes additional
SPECIMEN_IN_PACKAGE 0..* additional
SPM 1..1 Yes additional
SPECIMEN_CONTAINER_IN_PACKAGE 0..* additional
SAC 1..1 Yes additional

Original Mode Acknowledgement Choreography for ORL^O56^ORL_O56

Send Immediate Ack: ACK^O56^ACK

Enhanced Mode Acknowledgement Choreography for ORL^O56^ORL_O56

When the MSH-15 value of an ORL^O56^ORL_O56 message is AL or ER or SU, an ACK^O56^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ORL^O56^ORL_O56 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ORL^O56^ORL_O56 message is AL or ER or SU, a message SHALL be sent as an application ack.

When the MSH-16 value of an ORL^O56^ORL_O56 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^O56^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack:
NE, AL, ER, SU (none)

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.

When one wants to convey with the detailed order message a supporting document, such as a CDA, one can transmit that document using the OBX associated with the ORC/OBR(s) using OBX-11 = "O" Order Detail Description Only, using either OBX-2 = "ED" or "RP".

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

The Device segment (DEV) provides additional device information for a device referenced in one or more of the PRT segments in the message (using PRT-10 Participation Device to match DEV-2 Unique Device Identifier or PRT-22 Participation Device Type using DEV-3 Device Type).

OMI^O23^OMI_O23: Imaging Order Message
HL7 MessageStructure Table - OMI_O23
Segment Cardinality Must Implement Status
OMI_O23
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
NTE 0..* additional
PATIENT 0..1 additional
PID 1..1 Yes additional
PD1 0..1 additional
PRT 0..* additional
ARV 0..* B
NTE 0..* additional
GT1 0..1 additional
AL1 0..* additional
OCCUPATIONAL_DATA_FOR_HEALTH 0..1 additional
OH1 0..* additional
OH2 0..* additional
OH3 0..1 additional
OH4 0..* additional
PATIENT_VISIT 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
PRT 0..* additional
INSURANCE 0..* additional
IN1 1..1 Yes additional
IN2 0..1 additional
IN3 0..1 additional
ORDER 1..* Yes additional
ORC 1..1 Yes additional
PRT 0..* additional
OBR 1..1 Yes additional
NTE 0..* additional
PRT 0..* additional
CTD 0..1 additional
DG1 0..* additional
REL 1..1 Yes additional
IPC 1..* Yes additional
TIMING 0..* additional
TQ1 1..1 Yes additional
TQ2 0..* additional
OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
NTE 0..* additional
DEVICE 0..* additional
DEV 1..1 Yes additional
OBX 0..* additional

Original Mode Acknowledgement Choreography for OMI^O23^OMI_O23

Send Application Ack: ORI^O24^ORI_O24

Enhanced Mode Acknowledgement Choreography for OMI^O23^OMI_O23

When the MSH-15 value of an OMI^O23^OMI_O23 message is AL or ER or SU, an ACK^O23^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an OMI^O23^OMI_O23 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an OMI^O23^OMI_O23 message is AL or ER or SU, an ORI^O24^ORI_O24 or OSU^O52^OSU_O52 message SHALL be sent as an application ack.

When the MSH-16 value of an OMI^O23^OMI_O23 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^O23^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ORI^O24^ORI_O24 or OSU^O52^OSU_O52
NE, AL, ER, SU (none)

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.

There is not supposed to be an Application Level acknowledgement to an Application Level Acknowledgement message. In Enhanced Mode, MSH-16 SHALL always be set to NE (Never).

ORI^O24^ORI_O24: Imaging Order Acknowledgment Message
HL7 MessageStructure Table - ORI_O24
Segment Cardinality Must Implement Status
ORI_O24
MSH 1..1 Yes additional
MSA 1..1 Yes additional
ARV 0..* additional
ERR 0..* additional
SFT 0..* additional
UAC 0..1 additional
NTE 0..* additional
RESPONSE 0..1 additional
PATIENT 0..1 additional
PID 1..1 Yes additional
ARV 0..* B
NTE 0..* additional
PRT 0..* additional
ORDER 1..* Yes additional
ORC 1..1 Yes additional
PRT 0..* additional
OBR 1..1 Yes additional
NTE 0..* additional
PRT 0..* additional
IPC 1..* Yes additional
TIMING 0..* additional
TQ1 1..1 Yes additional
TQ2 0..* additional

Original Mode Acknowledgement Choreography for ORI^O24^ORI_O24

Send Immediate Ack: ACK^O24^ACK

Enhanced Mode Acknowledgement Choreography for ORI^O24^ORI_O24

When the MSH-15 value of an ORI^O24^ORI_O24 message is AL or ER or SU, an ACK^O24^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ORI^O24^ORI_O24 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ORI^O24^ORI_O24 message is AL or ER or SU, a message SHALL be sent as an application ack.

When the MSH-16 value of an ORI^O24^ORI_O24 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^O24^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack:
NE, AL, ER, SU (none)

OPL – Population/Location-Based Laboratory Order Message (Event O37)

This message supports the use-case for submission of field level specimen and order data to diagnostic laboratories

When one wants to convey with the detailed order message a supporting document, such as a CDA, one can transmit that document using the OBX associated with the ORC/OBR(s) using OBX-11 = "O" Order Detail Description Only, using either OBX-2 = "ED" or "RP"."

This structure represents the way that most orders to veterinary laboratories occur. There is a multi-tier hierarchy in which a single individual (usually a veterinarian or an owner of a production facility) submits one or more specimen samples from one or more animals or non-living entities, such as environmental specimens or feed, etc. There are often many interested participants referenced for each set of orders, which explains the need for the repeating PRT segment. These include individuals such as the government official that is responsible for monitoring the testing of an animal or animal group, the parent organization, etc. This grouped submission of specimens from multiple animal "patients" requires that orders pertaining to animal and non-animal specimens be accommodated. The primary structure of concern is the following:

{[PID]

{SPM

{ORC

OBR}

}

}

This allows for multiple specimens or animal or non-animal origin to have multiple requests associated with them. This is the usual process in field level sample collection from populations or environments.

OPL^O37^OPL_O37: Population/Location-Based Laboratory Order Message
HL7 MessageStructure Table - OPL_O37
Segment Cardinality Must Implement Status
OPL_O37
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
NTE 0..* additional
PRT 1..* Yes additional
GUARANTOR 0..1 additional
GT1 1..1 Yes additional
NTE 0..* additional
ORDER 1..* Yes additional
NK1 1..* Yes additional
SGH 0..1 additional
SGT 0..1 additional
FT1 0..* additional
CTI 0..* additional
BLG 0..1 additional
PATIENT 0..1 additional
PID 1..1 Yes additional
PD1 0..1 additional
PRT 0..* additional
ARV 0..* B
AL1 0..* additional
OBSERVATIONS_ON_PATIENT 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
INSURANCE 0..* additional
IN1 1..1 Yes additional
IN2 0..1 additional
IN3 0..1 additional
SPECIMEN 1..* Yes additional
SPM 1..1 Yes additional
SPECIMEN_OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
CONTAINER 0..* additional
SAC 1..1 Yes additional
CONTAINER_OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
OBSERVATION_REQUEST 1..* Yes additional
ORC 1..1 Yes additional
PRT 0..* additional
OBR 1..1 Yes additional
PRT 0..* additional
TCD 0..1 additional
DG1 0..* additional
TIMING 0..* additional
TQ1 1..1 Yes additional
TQ2 0..* additional
ORDER_RELATED_OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
PRIOR_RESULT 0..1 additional
NK1 1..* Yes additional
AL1 0..1 additional
PATIENT_PRIOR 0..1 additional
PID 1..1 Yes additional
PD1 0..1 additional
PRT 0..* additional
ARV 0..* B
PATIENT_VISIT_PRIOR 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
PRT 0..* additional
ORDER_PRIOR 1..* Yes additional
OBR 1..1 Yes additional
ORC 0..1 additional
OBSERVATION_PARTICIPATION_PRIOR 0..* additional
PRT 1..1 Yes additional
DEV 0..* additional
TIMING 0..1 additional
TQ1 1..1 Yes additional
TQ2 0..* additional
OBSERVATION_RESULT_GROUP 1..* Yes additional
OBX 1..1 Yes additional
PRT 0..* additional

Original Mode Acknowledgement Choreography for OPL^O37^OPL_O37

Send Application Ack: OPR^O38^OPR_O38

Enhanced Mode Acknowledgement Choreography for OPL^O37^OPL_O37

When the MSH-15 value of an OPL^O37^OPL_O37 message is AL or ER or SU, an ACK^O37^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an OPL^O37^OPL_O37 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an OPL^O37^OPL_O37 message is AL or ER or SU, an OPR^O38^OPR_O38 or OSU^O52^OSU_O52 message SHALL be sent as an application ack.

When the MSH-16 value of an OPL^O37^OPL_O37 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^O37^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: OPR^O38^OPR_O38 or OSU^O52^OSU_O52
NE, AL, ER, SU (none)

OPR – Population/Location-Based Laboratory Order Acknowledgment Message (Event O38)

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

Note: Based upon general message/acknowledgment patterns, it would be expected that this message type would be ORP. However, when this message type was introduced, ORP was already in use as Pharmacy/Treatment Order Acknowledgment.

There is not supposed to be an Application Level acknowledgement to an Application Level Acknowledgement message. In Enhanced Mode, MSH-16 SHALL always be set to NE (Never).

OPR^O38^OPR_O38: Population/Location-Based Laboratory Order Acknowledgment Message
HL7 MessageStructure Table - OPR_O38
Segment Cardinality Must Implement Status
OPR_O38
MSH 1..1 Yes additional
MSA 1..1 Yes additional
ARV 0..* additional
ERR 0..* additional
SFT 0..* additional
UAC 0..1 additional
NTE 0..* additional
RESPONSE 0..1 additional
ORDER 1..* Yes additional
NK1 1..* Yes additional
PATIENT 0..1 additional
PID 1..1 Yes additional
PRT 0..* additional
ARV 0..* B
SPECIMEN 0..* additional
SPM 1..1 Yes additional
SAC 0..* additional
SPECIMEN_OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
OBSERVATION_REQUEST 0..* additional
ORC 1..1 Yes additional
PRT 0..* additional
OBR 1..1 Yes additional
PRT 0..* additional
TIMING 0..* additional
TQ1 1..1 Yes additional
TQ2 0..* additional

Original Mode Acknowledgement Choreography for OPR^O38^OPR_O38

Send Immediate Ack: ACK^O38^ACK

Enhanced Mode Acknowledgement Choreography for OPR^O38^OPR_O38

When the MSH-15 value of an OPR^O38^OPR_O38 message is AL or ER or SU, an ACK^O38^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an OPR^O38^OPR_O38 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an OPR^O38^OPR_O38 message is AL or ER or SU, a message SHALL be sent as an application ack.

When the MSH-16 value of an OPR^O38^OPR_O38 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^O38^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack:
NE, AL, ER, SU (none)

OSU - Order Status Update (Event O51)

This message is used to create simple order status updates for any type of order where the ORC is sufficient to communicate the order identifier and no other data changes. This is particularly necessary when status updates are not part of order acknowledgement messages, e.g., a status message occurs 2 days later.

Note that one also could send a regular order message using order control code “SC” (Status Changed). The choice to use one or the other is dependent on whether any of the other segments in the original message structure is necessary or not.

OSU^O51^OSU_O51: Order Status Update Message
HL7 MessageStructure Table - OSU_O51
Segment Cardinality Must Implement Status
OSU_O51
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
NTE 0..* additional
PID 0..1 additional
PRT 0..* additional
ARV 0..* B
ORDER_STATUS 1..* Yes additional
ORC 1..1 Yes additional
PRT 0..* additional

Original Mode Acknowledgement Choreography for OSU^O51^OSU_O51

Send Application Ack: OSU^O52^OSU_O52

Enhanced Mode Acknowledgement Choreography for OSU^O51^OSU_O51

When the MSH-15 value of an OSU^O51^OSU_O51 message is AL or ER or SU, an ACK^O51^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an OSU^O51^OSU_O51 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an OSU^O51^OSU_O51 message is AL or ER or SU, an OSU^O52^OSU_O52 message SHALL be sent as an application ack.

When the MSH-16 value of an OSU^O51^OSU_O51 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^O51^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: OSU^O52^OSU_O52
NE, AL, ER, SU (none)

OSU – Order Status Update Acknowledgement (Event O52)

This message is used to create simple order status updates, through an acknowledgement, for any type of order where the ORC is sufficient to communicate the order identifier and no other data updates are necessary. This is particularly relevant when a status update occurred in response to a new or updated order. The OSU structure allows it to be used instead of, but equivalent to the application level acknowledgement message, e.g., ORG.

There is not supposed to be an Application Level acknowledgement to an Application Level Acknowledgement message. In Enhanced Mode, MSH-16 SHALL always be set to NE (Never).

OSU^O52^OSU_O52: Order Status Update Acknowledgement Message
HL7 MessageStructure Table - OSU_O52
Segment Cardinality Must Implement Status
OSU_O52
MSH 1..1 Yes additional
MSA 1..1 Yes additional
ARV 0..* additional
ERR 0..* additional
SFT 0..* additional
UAC 0..1 additional
NTE 0..* additional
PATIENT 0..1 additional
PID 1..1 Yes additional
PRT 0..* additional
ARV 0..* B
ORDER_STATUS 1..* Yes additional
ORC 1..1 Yes additional
PRT 0..* additional

Original Mode Acknowledgement Choreography for OSU^O52^OSU_O52

Send Immediate Ack: ACK^O52^ACK

Enhanced Mode Acknowledgement Choreography for OSU^O52^OSU_O52

When the MSH-15 value of an OSU^O52^OSU_O52 message is AL or ER or SU, an ACK^O52^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an OSU^O52^OSU_O52 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an OSU^O52^OSU_O52 message is AL or ER or SU, a message SHALL be sent as an application ack.

When the MSH-16 value of an OSU^O52^OSU_O52 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^O52^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack:
NE, AL, ER, SU (none)

OMQ – General Order Message with Document Payload (Event O57)

The purpose of this message is to enable communication of orders using a CDA document type to convey the content of the order (e.g., prescription, lab tests, etc.) while the message infrastructure enables appropriate state management.

It should be noted that, unless orders are communicated at the granular, fully decomposed test/medication/procedure/etc. level, state management can only happen at the group level, i.e., equal to all elements in the document. It also should be noted that identification of individual elements can only be achieved if the CDA document contains appropriate identification while the order numbers in ORC effectively act as a group number.

Once the order manager determines to initiate a new order using this message, then all subsequent state management messages must continue at the document level, forgoing detailed level state management.

When one wants to convey with the detailed order message a supporting document, such as a CDA, one can transmit that document using the OBX associated with the ORC/OBR(s) using OBX-11 = "O" Order Detail Description Only, using either OBX-2 = "ED" or "RP".

OMQ^O57^OMQ_O57: General Order Message with Document Payload
HL7 MessageStructure Table - OMQ_O57
Segment Cardinality Must Implement Status
OMQ_O57
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
NTE 0..* additional
PATIENT 0..1 additional
PID 1..1 Yes additional
PD1 0..1 additional
PRT 0..* additional
NTE 0..* additional
NK1 0..* additional
ARV 0..* B
GT1 0..1 additional
AL1 0..* additional
PATIENT_VISIT 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
PRT 0..* additional
INSURANCE 0..* additional
IN1 1..1 Yes additional
IN2 0..1 additional
IN3 0..1 additional
ORDER 1..* Yes additional
ORC 1..1 Yes additional
PRT 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
TXA 1..1 Yes additional
CTD 0..1 additional
DG1 0..* additional
FT1 0..* additional
CTI 0..* additional
BLG 0..1 additional
OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
NTE 0..* additional
PRIOR_RESULT 0..* additional
AL1 0..* additional
PATIENT_PRIOR 0..1 additional
PID 1..1 Yes additional
PD1 0..1 additional
PRT 0..* additional
ARV 0..* B
PATIENT_VISIT_PRIOR 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
PRT 0..* additional
ORDER_PRIOR 1..* Yes additional
ORC 1..1 Yes additional
PRT 0..* additional
OBR 1..1 Yes additional
NTE 0..* additional
CTD 0..1 additional
TIMING_PRIOR 0..* additional
TQ1 1..1 Yes additional
TQ2 0..* additional
OBSERVATION_PARTICIPATION_PRIOR 0..* additional
PRT 1..1 Yes additional
DEV 0..* additional
OBSERVATION_PRIOR 1..* Yes additional
OBX 1..1 Yes additional
PRT 0..* additional
NTE 0..* additional

Original Mode Acknowledgement Choreography for OMQ^O57^OMQ_O57

Send Application Ack: ORX^O58^ORX_O58

Enhanced Mode Acknowledgement Choreography for OMQ^O57^OMQ_O57

When the MSH-15 value of an OMQ^O57^OMQ_O57 message is AL or ER or SU, an ACK^O57^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an OMQ^O57^OMQ_O57 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an OMQ^O57^OMQ_O57 message is AL or ER or SU, an ORX^O58^ORX_O58 or OSU^O52^OSU_O52 message SHALL be sent as an application ack.

When the MSH-16 value of an OMQ^O57^OMQ_O57 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^O57^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ORX^O58^ORX_O58 or OSU^O52^OSU_O52
NE, AL, ER, SU (none)

ORX – General Order Message with Document Payload Acknowledgement Message (Event O58)

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

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

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

ORX^O58^ORX_O58: General Order Message with Document Payload Acknowledgement Message
HL7 MessageStructure Table - ORX_O58
Segment Cardinality Must Implement Status
ORX_O58
MSH 1..1 Yes additional
MSA 1..1 Yes additional
ARV 0..* additional
ERR 0..* additional
SFT 0..* additional
UAC 0..1 additional
NTE 0..* additional
RESPONSE 0..1 additional
PATIENT 0..1 additional
PID 1..1 Yes additional
NTE 0..* additional
PRT 0..* additional
ARV 0..* B
ORDER 1..* Yes additional
ORC 1..1 Yes additional
PRT 0..* additional
TXA 1..1 Yes
CTI 0..* additional

Original Mode Acknowledgement Choreography for ORX^O58^ORX_O58

Send Immediate Ack: ACK^O58^ACK

Enhanced Mode Acknowledgement Choreography for ORX^O58^ORX_O58

When the MSH-15 value of an ORX^O58^ORX_O58 message is AL or ER or SU, an ACK^O58^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ORX^O58^ORX_O58 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ORX^O58^ORX_O58 message is AL or ER or SU, a message SHALL be sent as an application ack.

When the MSH-16 value of an ORX^O58^ORX_O58 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^O58^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack:
NE, AL, ER, SU (none)

OML – Laboratory Result Interpretation Request Message (Event O59)

This is a simplified fulfillment order representing a request for interpretation of a pre-existing result. The ORC and OBR are the new fulfillment order requesting confirmation of a previous result.

The REL segment (Ch. 12) establishes a relationship between the new order (source) and a previous order/result (target) requiring additional action such as confirmation of that order or result, or interpretation of that result. The REL segment includes a variety of fields defining a clinical relationship and the identity of the asserting party. For this use, the required fields are the relationship type (REL-2), the source identifier (REL-4, new order number in this message), and the target identifier (REL-5, previous order group, order, or result identifier included in a previous message). Targets may be represented using order or order group identifiers, in which case the target encompasses the entire order or order group and all results, or may include results identifiers (OBX-21, Observation Instance Identifier), in which case the target is restricted to the specific result.

OML^O59^OML_O59: Laboratory Order Message
HL7 MessageStructure Table - OML_O59
Segment Cardinality Must Implement Status
OML_O59
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
NTE 0..* additional
PATIENT 0..1 additional
PID 1..1 Yes additional
PD1 0..1 additional
PRT 0..* additional
NTE 0..* additional
NK1 0..* additional
GT1 0..1 additional
AL1 0..* additional
PATIENT_VISIT 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
PRT 0..* additional
INSURANCE 0..* additional
IN1 1..1 Yes additional
IN2 0..1 additional
IN3 0..1 additional
ORDER 1..* Yes additional
ORC 1..1 Yes additional
NTE 0..* additional
PRT 0..* additional
FT1 0..* additional
CTI 0..* additional
BLG 0..1 additional
TIMING 0..* additional
TQ1 1..1 Yes additional
TQ2 0..* additional
OBSERVATION_REQUEST 0..1 additional
OBR 1..1 Yes additional
TCD 0..1 additional
NTE 0..* additional
PRT 0..* additional
CTD 0..1 additional
DG1 0..* additional
REL 0..1 additional
IPC 0..1 additional
SGH 0..1 additional
SGT 0..1 additional
OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
TCD 0..1 additional
NTE 0..* additional
SPECIMEN 0..* additional
SPM 1..1 Yes additional
NTE 0..* additional
SPECIMEN_OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
CONTAINER 0..* additional
SAC 1..1 Yes additional
NTE 0..1 additional
CONTAINER_OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
PRIOR_RESULT 0..* additional
AL1 0..* additional
PATIENT_PRIOR 0..1 additional
PID 1..1 Yes additional
PD1 0..1 additional
PRT 0..* additional
PATIENT_VISIT_PRIOR 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
PRT 0..* additional
ORDER_PRIOR 1..* Yes additional
ORC 1..1 Yes additional
PRT 0..* additional
OBR 1..1 Yes additional
NTE 0..* additional
OBSERVATION_PARTICIPATION_PRIOR 0..* additional
PRT 1..1 Yes additional
DEV 0..* additional
TIMING_PRIOR 0..* additional
TQ1 1..1 Yes additional
TQ2 0..* additional
OBSERVATION_PRIOR 1..* Yes additional
OBX 1..1 Yes additional
PRT 0..* additional
NTE 0..* additional

Original Mode Acknowledgement Choreography for OML^O59^OML_O59

Send Application Ack: ORL^O22^ORL_O22

Enhanced Mode Acknowledgement Choreography for OML^O59^OML_O59

When the MSH-15 value of an OML^O59^OML_O59 message is AL or ER or SU, an ACK^O59^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an OML^O59^OML_O59 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an OML^O59^OML_O59 message is AL or ER or SU, an ORL^O22^ORL_O22 or ORL^O53^ORL_O53 or OSU^O52^OSU_O52 message SHALL be sent as an application ack.

When the MSH-16 value of an OML^O59^OML_O59 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^O59^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ORL^O22^ORL_O22 or ORL^O53^ORL_O53 or OSU^O52^OSU_O52
NE, AL, ER, SU (none)

General Segments

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

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

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 Segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
ORC
1 Order Control ID R
0119(R) Order Control Codes(Required)
[1..1] 00215 [2..2]
2 Placer Order Number EI C
[0..1] 00216
3 Filler Order Number EI C
[0..1] 00217
4 Placer Order Group Number EI O
[0..1] 00218
5 Order Status ID O
0038(R) Order status(Required)
[0..1] 00219 [1..2]
6 Response Flag ID O
0121(R) Response Flag(Required)
[0..1] 00220 [1..1]
7 Quantity/Timing W
[0..0] 00221
8 Parent Order EIP O
0119(R) Order Control Codes(Required)
[0..*] 00222
9 Date/Time of Order Event DTM O
[0..1] 00223
10 Entered By XCN W
[0..1] 00224
11 Verified By W
[0..1] 00225
12 Ordering Provider W
[0..1] 00226
13 Enterer's Location PL O
[0..1] 00227
14 Call Back Phone Number XTN O
[0..2] 00228
15 Order Effective Date/Time DTM O
[0..1] 00229
16 Order Control Code Reason CWE O
0949 Order Control Code Reason
[0..1] 00230
17 Entering Organization W
0666
[0..1] 00231
18 Entering Device W
0668
[0..1] 00232
19 Action By W
[0..1] 00233
20 Advanced Beneficiary Notice Code CWE O
0339(S) Advanced Beneficiary Notice Code(Suggested)
[0..1] 01310
21 Ordering Facility Name W
[0..1] 01311
22 Ordering Facility Address W
[0..1] 01312
23 Ordering Facility Phone Number W
[0..1] 01313
24 Ordering Provider Address W
[0..1] 01314
25 Order Status Modifier CWE O
0950(S) Order Status Modifier(Suggested)
[0..1] 01473
26 Advanced Beneficiary Notice Override Reason CWE C
0552(R) Advanced Beneficiary Notice Override Reason(Required)
[0..1] 01641
27 Filler's Expected Availability Date/Time DTM O
[0..1] 01642
28 Confidentiality Code CWE O
0177 Confidentiality Code
[0..1] 00615
29 Order Type CWE O
0482(R) Order Type(Required)
[0..1] 01643
30 Enterer Authorization Mode CNE O
0483(R) Authorization Mode(Required)
[0..1] 01644
31 Parent Universal Service Identifier W
[0..1] 02287
32 Advanced Beneficiary Notice Date DT O
[0..1] 02301
33 Alternate Placer Order Number CX O
[0..*] 03300
34 Order Workflow Profile CWE O
0934 Order Workflow Profile
[0..*] 03387
35 Action Code ID O
0206(R) Segment Action Code(Required)
[0..1] 00816 [2..2]
36 Order Status Date Range DR O
[0..1] 03509
37 Order Creation Date/Time DTM O
[0..1] 03515
38 Filler Order Group Number EI O
[0..1] 02482

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. A common use case is the grouping of laboratory batteries and tests ordered together by a physician for a patient with a common diagnostic goal (e.g. preoperative blood testing, diabetes follow-up, …).

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 or when the filler accessions the order group and supplies a filler group number with the received order. The order group may be identified by the placer or by the filler or by both applications. The order group consists of all the ORCs and order detail segments that have the same placer group number, or using the assign number/number assigned mechanism. 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.

  5. Date/Time Use Notes:

  6. Various dates are available in ORC that seem overlapping, but serve distinct purposes. The following provides use notes on these relationships, while the individual field definitions provide further details.

  7. ORC-7 Quantity/Timing - This field was retained for backward compatibility only as of v 2.5 and the detail was withdrawn and removed from the standard as of v 2.7. The reader is referred to the TQ1 – Timing/Quantity and TQ2 – Timing/Quantity Relationship segments described in sections 4.5.4 and 4.5.5, respectively. The purpose of this field (and now these segments) is to capture Priority, Frequency, and Timing of the service being ordered. For example, an order for a unit of blood to be administered to a patient every morning for 3 days..

  8. ORC-9 Date/Time of Order Event – This field is the date/time when the action indicated in ORC-1 was initiated. Every time a new action, as indicated by ORC-1, occurs the date/time of that action should appear in ORC-9. This field is not equivalent to MSH-7 Date and Time of Message, which reflects the date/time of message generation.

  9. ORC-15 Order Effective Date/Time – The field focuses on when the information communicated is to take effect. It is most appropriate when used on an order that is by nature a “continuing” (or continuous) order. This field has a close relationship to ORC-9 and the TQ1, TQ2 segments in so much as the value in ORC-15 takes precedence over both. For example, an order is placed on June 1, for an activity that is to be performed over ten days as indicated in the TQ1 segment. The Filler then receives a cancel message on June 2 with the ORC-9 value of June 2, but the ORC-15 Order Effective Date/Time indicated the cancel is to be effective on June 7th. ORC-15 by taking precedence over TQ1 and ORC-9, would tell the Filler to continue to perform the order event until June 7, and cancel all remaining events (treatment, procedures etc.) after that time.

  10. ORC-27 Filler’s Expected Availability Date/Time – This field focuses on when the filler expects to complete the order, e.g., have the results available, the prescription ready, etc. This is a Filler assigned field and would typically only be sent from Filler to Placer on either application level acknowledgments or order status messages. (Could be delivered with result messag but would have little relevance at that time.)

  11. ORC-32 Advanced Beneficiary Notice Date – This field contains the date the patient gave consent to pay for potentially uninsured services or the date that the Advanced Beneficiary Notice Code (ORC-20) was collected.

  12. ORC-36 Order Status Range – This field is a Filler assigned date/time indicating a date range that the ORC-5 Order Status is intended to be effective. For example, if the Filler recommends an alternate test, and sets the ORC-5 status to “Hold”, this date/time reflects how long the Filler will keep the order in that status (barring additional communications from the Placer or Filler in regard to this order.)

  13. ORC-37 Order Creation Date/Time – focuses on the date that the order was originally created; whether as an electronic order or as an initial paper requisition. This date/time is designed to preserve the creation date/time from initial order to final result, and for all stages in-between. (Acknowledgments, Updates, Cancels, etc.)

ORC-1: Order Control (ID) 00215

FIXME

ORC-2: Placer Order Number (EI) 00216

FIXME

ORC-3: Filler Order Number (EI) 00217

FIXME

ORC-4: Placer Order Group Number (EI) 00218

FIXME

ORC-5: Order Status (ID) 00219

FIXME

ORC-6: Response Flag (ID) 00220

FIXME

ORC-7: Quantity/Timing () 00221

FIXME

ORC-8: Parent Order (EIP) 00222

FIXME

ORC-9: Date/Time of Order Event (DTM) 00223

FIXME

ORC-10: Entered By (XCN) 00224

FIXME

ORC-11: Verified By () 00225

FIXME

ORC-12: Ordering Provider () 00226

FIXME

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

FIXME

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

FIXME

ORC-15: Order Effective Date/Time (DTM) 00229

FIXME

ORC-16: Order Control Code Reason (CWE) 00230

FIXME

ORC-17: Entering Organization () 00231

FIXME

ORC-18: Entering Device () 00232

FIXME

ORC-19: Action By () 00233

FIXME

ORC-20: Advanced Beneficiary Notice Code (CWE) 01310

FIXME

ORC-21: Ordering Facility Name () 01311

FIXME

ORC-22: Ordering Facility Address () 01312

FIXME

ORC-23: Ordering Facility Phone Number () 01313

FIXME

ORC-24: Ordering Provider Address () 01314

FIXME

ORC-25: Order Status Modifier (CWE) 01473

FIXME

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

FIXME

ORC-27: Filler's Expected Availability Date/Time (DTM) 01642

FIXME

ORC-28: Confidentiality Code (CWE) 00615

FIXME

ORC-29: Order Type (CWE) 01643

FIXME

ORC-30: Enterer Authorization Mode (CNE) 01644

FIXME

ORC-31: Parent Universal Service Identifier () 02287

FIXME

ORC-32: Advanced Beneficiary Notice Date (DT) 02301

FIXME

ORC-33: Alternate Placer Order Number (CX) 03300

FIXME

ORC-34: Order Workflow Profile (CWE) 03387

FIXME

ORC-35: Action Code (ID) 00816

FIXME

ORC-36: Order Status Date Range (DR) 03509

FIXME

ORC-37: Order Creation Date/Time (DTM) 03515

FIXME

ORC-38: Filler Order Group Number (EI) 02482

FIXME

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 Segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
BLG
1 When to Charge CCD O
0100(R) Invocation event(Required)
[0..1] 00234
2 Charge Type ID O
0122(R) Charge Type(Required)
[0..1] 00235 [2..2]
3 Account ID CX O
[0..1] 00236
4 Charge Type Reason CWE O
0475(S) Charge Type Reason(Suggested)
[0..1] 01645

BLG-1: When to Charge (CCD) 00234

FIXME

BLG-2: Charge Type (ID) 00235

FIXME

BLG-3: Account ID (CX) 00236

FIXME

BLG-4: Charge Type Reason (CWE) 01645

FIXME

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 Segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
OBR
1 Set ID – OBR SI O
[0..1] 00237 [1..4]
2 Placer Order Number EI C
[0..1] 00216
3 Filler Order Number EI C
[0..1] 00217
4 Universal Service Identifier CWE R
0612
[1..1] 00238
5 Priority W
[0..1] 00239
6 Requested Date/Time W
[0..1] 00240
7 Observation Date/Time # DTM C
[0..1] 00241
8 Observation End Date/Time # DTM O
[0..1] 00242
9 Collection Volume * CQ B
[0..1] 00243
10 Collector Identifier * XCN B
[0..*] 00244
11 Specimen Action Code * ID O
0065(R) Specimen Action Code(Required)
[0..1] 00245 [1..1]
12 Danger Code CWE O
0613
[0..1] 00246
13 Relevant Clinical Information CWE O
0916 Relevant Clincial Information
[0..*] 00247 300 #
14 Specimen Received Date/Time * DTM W
[0..1] 00248
15 Specimen Source W
[0..1] 00249
16 Ordering Provider W
[0..1] 00226
17 Order Callback Phone Number XTN O
[0..2] 00250
18 Placer Field 1 ST O
[0..1] 00251 199 #
19 Placer Field 2 ST O
[0..1] 00252 199 #
20 Filler Field 1 + ST O
[0..1] 00253 199 #
21 Filler Field 2 + ST O
[0..1] 00254 199 #
22 Results Rpt/Status Chng – Date/Time + DTM C
[0..1] 00255
23 Charge to Practice + MOC O
[0..1] 00256
24 Diagnostic Serv Sect ID ID O
0074(R) Diagnostic Service Section ID(Required)
[0..1] 00257 [2..3]
25 Result Status + ID C
0123(R) Result Status(Required)
[0..1] 00258 [1..1]
26 Parent Result + PRL O
[0..1] 00259
27 Quantity/Timing W
[0..0] 00221
28 Result Copies To W
[0..1] 00260
29 Parent Results Observation Identifier EIP O
[0..1] 00261
30 Transportation Mode ID O
0124(R) Transportation Mode(Required)
[0..1] 00262 [4..4]
31 Reason for Study CWE O
0951(S) Reason for Study(Suggested)
[0..*] 00263
32 Principal Result Interpreter + W
[0..1] 00264
33 Assistant Result Interpreter + W
[0..1] 00265
34 Technician + W
[0..1] 00266
35 Transcriptionist + W
[0..1] 00267
36 Scheduled Date/Time + DTM O
[0..1] 00268
37 Number of Sample Containers * NM O
[0..1] 01028 16 #
38 Transport Logistics of Collected Sample * CWE O
0614
[0..*] 01029
39 Collector's Comment * CWE O
0619
[0..*] 01030
40 Transport Arrangement Responsibility CWE O
0620
[0..1] 01031
41 Transport Arranged ID O
0224(R) Transport Arranged(Required)
[0..1] 01032 [1..1]
42 Escort Required ID O
0225(R) Escort Required(Required)
[0..1] 01033 [1..1]
43 Planned Patient Transport Comment CWE O
0621
[0..*] 01034
44 Procedure Code CNE O
[0..1] 00393
45 Procedure Code Modifier CNE O
[0..*] 01316
46 Placer Supplemental Service Information CWE O
0411 Supplemental Service Information Values
[0..*] 01474
47 Filler Supplemental Service Information CWE O
0411 Supplemental Service Information Values
[0..*] 01475
48 Medically Necessary Duplicate Procedure Reason CWE C
0476 Medically Necessary Duplicate Procedure Reason
[0..1] 01646
49 Result Handling CWE O
0507 Observation Result Handling
[0..1] 01647
50 Parent Universal Service Identifier W
[0..1] 02286
51 Observation Group ID EI O
[0..1] 02307
52 Parent Observation Group ID EI O
[0..1] 02308
53 Alternate Placer Order Number CX O
[0..*] 03303
54 Parent Order EIP O
0119(R) Order Control Codes(Required)
[0..*] 00222
55 Action Code ID O
0206(R) Segment Action Code(Required)
[0..1] 00816 [2..2]

OBR-1: Set ID – OBR (SI) 00237

FIXME

OBR-2: Placer Order Number (EI) 00216

FIXME

OBR-3: Filler Order Number (EI) 00217

FIXME

OBR-4: Universal Service Identifier (CWE) 00238

FIXME

OBR-5: Priority () 00239

FIXME

OBR-6: Requested Date/Time () 00240

FIXME

OBR-7: Observation Date/Time # (DTM) 00241

FIXME

OBR-8: Observation End Date/Time # (DTM) 00242

FIXME

OBR-9: Collection Volume * (CQ) 00243

FIXME

OBR-10: Collector Identifier * (XCN) 00244

FIXME

OBR-11: Specimen Action Code * (ID) 00245

FIXME

OBR-12: Danger Code (CWE) 00246

FIXME

OBR-13: Relevant Clinical Information (CWE) 00247

FIXME

OBR-14: Specimen Received Date/Time * (DTM) 00248

FIXME

OBR-15: Specimen Source () 00249

FIXME

OBR-16: Ordering Provider () 00226

FIXME

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

FIXME

OBR-18: Placer Field 1 (ST) 00251

FIXME

OBR-19: Placer Field 2 (ST) 00252

FIXME

OBR-20: Filler Field 1 + (ST) 00253

FIXME

OBR-21: Filler Field 2 + (ST) 00254

FIXME

OBR-22: Results Rpt/Status Chng – Date/Time + (DTM) 00255

FIXME

OBR-23: Charge to Practice + (MOC) 00256

FIXME

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

FIXME

OBR-25: Result Status + (ID) 00258

FIXME

OBR-26: Parent Result + (PRL) 00259

FIXME

OBR-27: Quantity/Timing () 00221

FIXME

OBR-28: Result Copies To () 00260

FIXME

OBR-29: Parent Results Observation Identifier (EIP) 00261

FIXME

OBR-30: Transportation Mode (ID) 00262

FIXME

OBR-31: Reason for Study (CWE) 00263

FIXME

OBR-32: Principal Result Interpreter + () 00264

FIXME

OBR-33: Assistant Result Interpreter + () 00265

FIXME

OBR-34: Technician + () 00266

FIXME

OBR-35: Transcriptionist + () 00267

FIXME

OBR-36: Scheduled Date/Time + (DTM) 00268

FIXME

OBR-37: Number of Sample Containers * (NM) 01028

FIXME

OBR-38: Transport Logistics of Collected Sample * (CWE) 01029

FIXME

OBR-39: Collector's Comment * (CWE) 01030

FIXME

OBR-40: Transport Arrangement Responsibility (CWE) 01031

FIXME

OBR-41: Transport Arranged (ID) 01032

FIXME

OBR-42: Escort Required (ID) 01033

FIXME

OBR-43: Planned Patient Transport Comment (CWE) 01034

FIXME

OBR-44: Procedure Code (CNE) 00393

FIXME

OBR-45: Procedure Code Modifier (CNE) 01316

FIXME

OBR-46: Placer Supplemental Service Information (CWE) 01474

FIXME

OBR-47: Filler Supplemental Service Information (CWE) 01475

FIXME

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

FIXME

OBR-49: Result Handling (CWE) 01647

FIXME

OBR-50: Parent Universal Service Identifier () 02286

FIXME

OBR-51: Observation Group ID (EI) 02307

FIXME

OBR-52: Parent Observation Group ID (EI) 02308

FIXME

OBR-53: Alternate Placer Order Number (CX) 03303

FIXME

OBR-54: Parent Order (EIP) 00222

FIXME

OBR-55: Action Code (ID) 00816

FIXME

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 Segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
TQ1
1 Set ID - TQ1 SI O
[0..1] 01627 [1..4]
2 Quantity CQ O
[0..1] 01628
3 Repeat Pattern RPT O
[0..*] 01629
4 Explicit Time TM O
[0..*] 01630
5 Relative Time and Units CQ O
[0..*] 01631
6 Service Duration CQ O
[0..1] 01632
7 Start date/time DTM O
[0..1] 01633
8 End date/time DTM O
[0..1] 01634
9 Priority CWE O
0485 Extended Priority Codes
[0..*] 01635
10 Condition text TX O
[0..1] 01636 250 #
11 Text instruction TX O
[0..1] 01637 250 #
12 Conjunction ID C
0472(R) TQ Conjunction ID(Required)
[0..1] 01638 [1..1]
13 Occurrence duration CQ O
[0..1] 01639
14 Total occurrences NM O
[0..1] 01640 10 #

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

FIXME

TQ1-2: Quantity (CQ) 01628

FIXME

TQ1-3: Repeat Pattern (RPT) 01629

FIXME

TQ1-4: Explicit Time (TM) 01630

FIXME

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

FIXME

TQ1-6: Service Duration (CQ) 01632

FIXME

TQ1-7: Start date/time (DTM) 01633

FIXME

TQ1-8: End date/time (DTM) 01634

FIXME

TQ1-9: Priority (CWE) 01635

FIXME

TQ1-10: Condition text (TX) 01636

FIXME

TQ1-11: Text instruction (TX) 01637

FIXME

TQ1-12: Conjunction (ID) 01638

FIXME

TQ1-13: Occurrence duration (CQ) 01639

FIXME

TQ1-14: Total occurrences (NM) 01640

FIXME

TQ2 - Timing/Quantity Relationship Segment

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 Segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
TQ2
1 Set ID - TQ2 SI O
[0..1] 01648 [1..4]
2 Sequence/Results Flag ID O
0503(R) Sequence/Results Flag(Required)
[0..1] 01649 [1..1]
3 Related Placer Number EI C
[0..*] 01650
4 Related Filler Number EI C
[0..*] 01651
5 Related Placer Group Number EI C
[0..*] 01652
6 Sequence Condition Code ID C
0504(R) Sequence Condition Code(Required)
[0..1] 01653 [2..*]
7 Cyclic Entry/Exit Indicator ID C
[0..1] 01654 [1..1]
8 Sequence Condition Time Interval CQ O
[0..1] 01655
9 Cyclic Group Maximum Number of Repeats NM O
[0..1] 01656 10 #
10 Special Service Request Relationship ID C
0506(R) Service Request Relationship(Required)
[0..1] 01657 [1..1]

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:

      • TQ2 of the second child service request specifies that it follow the first child service request.

      • TQ2 of the third child service request specifies that it follow the second child service request.

      • TQ2 of the fourth child service request specifies that it follow the third service request.

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

      • TQ2 of the first child service request specifies that it is to be executed once without any dependence on the completion of other service requests. Its second execution follows the completion of the fourth service request. See example in Section 4A.5.2 RXO segment field examples.

This scheme allows the following to be tracked:

  • The status of the whole group of service requests to be reported back at the level of the parent service request.

  • The status for each individual IV service request by following the status of the corresponding child service request.

Separate Service requests example:

  • The same group of service requests can be sent as a group of four service requests (without a common parent), linked only by the data in their quantity/timing fields. In this case, there is no convenient HL7 method of transmitting the service request status of the group as a whole without transmitting the status of each of the four separate service requests.

  • Inheritance of service request status

Cancellation/discontinuation/hold service request control events:

      • This logic implies the normal execution of the referenced predecessor service request. Thus a cancel (or discontinuation or hold) of a predecessor service request implies the cancellation (or discontinuation or hold) of all subsequent service requests in the chain.

      • If the referenced service request has been canceled (or discontinued or held), the current service request inherits that same status.

      • In the case of hold, the removal of the hold of the predecessor implies a removal of the hold for the given service request (which can then be executed according to the specification in the TQ2 segment).

TQ2-1: Set ID - TQ2 (SI) 01648

FIXME

TQ2-2: Sequence/Results Flag (ID) 01649

FIXME

TQ2-3: Related Placer Number (EI) 01650

FIXME

TQ2-4: Related Filler Number (EI) 01651

FIXME

TQ2-5: Related Placer Group Number (EI) 01652

FIXME

TQ2-6: Sequence Condition Code (ID) 01653

FIXME

TQ2-7: Cyclic Entry/Exit Indicator (ID) 01654

FIXME

TQ2-8: Sequence Condition Time Interval (CQ) 01655

FIXME

TQ2-9: Cyclic Group Maximum Number of Repeats (NM) 01656

FIXME

TQ2-10: Special Service Request Relationship (ID) 01657

FIXME

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 at http://medical.nema.org.


HL7 Attribute Table - IPC - Imaging Procedure Control Segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
IPC
1 Accession Identifier EI R
[1..1] 01330
2 Requested Procedure ID EI R
[1..1] 01658
3 Study Instance UID EI R
[1..1] 01659
4 Scheduled Procedure Step ID EI R
[1..1] 01660
5 Modality CWE O
0604
[0..1] 01661
6 Protocol Code CWE O
0605
[0..*] 01662
7 Scheduled Station Name EI O
[0..1] 01663
8 Scheduled Procedure Step Location CWE O
0606
[0..*] 01664
9 Scheduled Station AE Title ST O
[0..1] 01665 16 #
10 Action Code ID O
0206(R) Segment Action Code(Required)
[0..1] 00816 [2..2]

IPC-1: Accession Identifier (EI) 01330

FIXME

IPC-2: Requested Procedure ID (EI) 01658

FIXME

IPC-3: Study Instance UID (EI) 01659

FIXME

IPC-4: Scheduled Procedure Step ID (EI) 01660

FIXME

IPC-5: Modality (CWE) 01661

FIXME

IPC-6: Protocol Code (CWE) 01662

FIXME

IPC-7: Scheduled Station Name (EI) 01663

FIXME

IPC-8: Scheduled Procedure Step Location (CWE) 01664

FIXME

IPC-9: Scheduled Station AE Title (ST) 01665

FIXME

IPC-10: Action Code (ID) 00816

FIXME

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.

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

PID|...

ORC|NW|A226677^PC||946281^PC||N|3^QAM||200601121132|444-44-4444^HIPPOCRATES^HAROLD^^^^MD|||4EAST|...

// EKG order

OBR|1|||8601-7^EKG IMPRESSION^LN||||||||||||222-33-4444^PUMP^PATRICK^^^^MD|||||||||||3^QAM|...

BLG|...

ORC|NW|...

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

MSA|...

The only implication of this response is that the order was received.

If the Response Flag had been E, then the response would have been the same, but its implication would have been that the EKG application had processed all the orders and they were acceptable.

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

MSA|...

ORC|PA|A226677^PC|89-458^EKG|946281^PC

ORC|CH|A226677^PC|89-551^EKG|946281... // 1ST child ORC.

ORC|CH|A226677^PC|89-552^EKG|946281... // 2ND child ORC.

ORC|CH|A226677^PC|89-553^EKG|946281... // 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|...

MSA|...

ORC|PA|A226677^PC|89-458^EKG

ORC|CH|A226677^PC|89-551^EKG|946281^PC|SC|||A226677&PC^89-458&EKG|

    ... ^^^^198901130500^...

// 1ST child ORC

OBR|1||89-551^EKG|8601-7^EKG IMPRESSION^LN|...

// 1ST child OBR

ORC|CH|A226677^PC|89-522^EKG|946281^PC|SC|||A226677&PC^89-458&EKG|

    ... ^^^^198901140500^...

// 2ND child ORC

OBR|2||89-552^EKG|8601-7^EKG IMPRESSION^LN|...

// 2ND child OBR

ORC|CH|A226677^PC|89-553^EKG|946281^PC|SC|||A226677&PC^89-458&EKG|

    ...^^^^198901150500^...

// 3RD child ORC

OBR|3||89-553^EKG|8601-7^EKG IMPRESSION^LN|...

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

Ordering 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

TQ1-7

Start Date/Time

TQ1-8

End Date/Time

ORC-16

Order Control Code Reason

ORC-25

Order Status Modifier

OBR-4

Universal Service ID

OBX-5

Observation Value

FT1-17

Fee Schedule

FT1-11

Transaction amount – extended

BLG

Billing segment


  • ORC-1, ORC-2, OBR-4, OBX-5

    These services can be started, discontinued, canceled, locked, etc., according to the ORC-1 Order control code. The order is identified through ORC-2 Placer order number. The service itself is specified in the field OBR-4 Universal service ID. User defined codes are used to identify the specific services. The identification of the object of the service, e.g., phone number or card number, is done using the OBX-5 Observation value. The ORC-25 Order Status Modifier is used to refine the status of the universal service ID. For example, in the case of issuing chip cards, these fields would be valued as follows:

ORC-1

OBR-4 (in textual form)

ORC-16.1 Code

Description

NW

chip card

Issue a chip card the first time

XO

chip card

defective

Change the previous order. Issue a new chip card for a defective one.

XO

chip card

lost

Change the previous order. Issue a new chip card for a defective one.

DC

Return chip card

Cancel the chip card order

DC

Return chip card

lost

Cancel the chip card order because lost.

DC

Return chip card

defective

Cancel the chip card order because defective.


Use of different universal service IDs allows for the ability to charge an additional fee.

  • TQ1-7/8

    The field TQ1 - Quantity/timing describes time periods during which the requested service is valid. The components 4 and 5 denote the start and end date/time.

  • ORC-5

    In this field information on the status of the service can be transmitted. This field can be used in particular in response to a query message.

  • ORC-25

    This field allows for refining the status of the requested universal service, e.g., to change an order for a chip card in order to distribute a new card for a lost one.

  • BLG-1,2,3

    These fields indicate to the financial system that charges are to be invoiced for this service.

  • FT1-17

    In some cases it is necessary that the placer defines a special tariff the filler has to use for computing the final balance.

  • FT1-11

    In combination with the tariff the patient can prepay the ordered service. This may be helpful when the patient uses services provided by the hospital in order to use the service from the beginning. FT1-6 must be valued at "PY".

    If no amount is prepaid a limit can be established according to a special tariff. This depends on the setup of the filling system. In such a case the hospital grants a credit to the patient.

Phone Number Assignment

In case the patient requests a bedside phone and the number of this phone is assigned to that patient 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 or her personal call number, which he or she retains throughout that patient's stay, including if the patient 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, an 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 = , 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, an 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 = , ORC-3 = , ORC-5 = , OBR-4 = "Phone", and OBX-5 = . 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 = , MFE-1 = "MUP", LOC-1 = , LOC-3 = "B" (bed), LOC-6 = . 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 = , QRF-2 = , and QRF-3 = . The phone number assigning applications responds with a DSR^P04 message with the data in DSP-3.

Note: The original mode query, including QRD and QRF segments were retained for backward compatibility only as of v 2.4. The reader is therefore referred to chapter 5, section 5.4, for the current query/response message structure.



Phone Call Queries (Z73)

The new query modes using a query by parameter query with a virtual table response allows for obtaining call information from the phone system to be used for charging. The query can be for accumulated data or detailed data. Both requests use this conformance statement:

Query ID:

Z73

Query Name:

Information about Phone Calls

Query Type:

Query

Query Trigger:

QBP^Z73^QBP_Z73

Query Mode:

Both

Response Trigger:

RTB^Z74^RTB_Z74

Query Priority:

Immediate

Query Characteristics:

Returns response sorted by Phone Number

Purpose:

Retrieve all information about phone calls made during a defined interval either in a detailed or an accumulative format. The identifier for the patient must be given.


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



Input Parameter Field Description and Commentary:

Field

Component

DT

Description

Patient ID

CX

Components: <ID (ST)> ^ <check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <assigning authority (HD)> ^ <identifier type code (IS)> ^ <assigning facility (HD)>

This field contains a patient identification code to identify the requested person.

If this field is not valued, no values for this field are considered to be a match.

Date Range

DR

This field specifies the range of time, the requested records should match.

If this field is not valued, all values for this field are considered to be a match.

Detailed

ID

This field specifies whether the output should be detailed. (no cumulative records).

If this field is not valued, a detailed result is returned.

When Detailed=Y is requested, one record for each call is returned. Each detailed record will contain columns 1, 2, 3, 4, 5, 7, 8, and 9 (Providor, Region, Extension, Destination, Date/Time, Duration, Units, Amount) for each call.

When detailed=N, the query is for accumulated data. In this case, one row record per extension is returned.

Each row will return columns 1, 2, 6, 7, 8, and 9 (Provider, Region, Quantity, Units, Amount) from the output virtual table.


Response Grammar:

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

24

DTM

O

Quantity

4

NM

O

Duration

4

NM

O

Units

4

NM

O

Amount

8

MO

O



QBP^Z73^QBP_Z73: QBP Message
HL7 MessageStructure Table - QBP_O33
Segment Cardinality Must Implement Status
QBP_O33
MSH 1..1 Yes additional
SFT 0..* additional
UAC 0..1 additional
QPD 1..1 Yes additional
RCP 1..1 Yes additional

Original Mode Acknowledgement Choreography for QBP^Z73^QBP_Z73

Send Application Ack: RTB^Z74^RTB_Z74

Enhanced Mode Acknowledgement Choreography for QBP^Z73^QBP_Z73

When the MSH-15 value of a QBP^Z73^QBP_Z73 message is AL or ER or SU, an ACK^Z73^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of a QBP^Z73^QBP_Z73 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a QBP^Z73^QBP_Z73 message is AL or ER or SU, a RTB^Z74^RTB_Z74 message SHALL be sent as an application ack.

When the MSH-16 value of a QBP^Z73^QBP_Z73 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^Z73^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: RTB^Z74^RTB_Z74
NE, AL, ER, SU (none)

RTB^Z74^RTB_Z74: Personnel Information Message
HL7 MessageStructure Table - RTB_Z74
Segment Cardinality Must Implement Status
RTB_Z74
MSH 1..1 Yes additional
MSA 1..1 Yes additional
ERR 0..* additional
SFT 0..* additional
UAC 0..1 additional
QAK 1..1 Yes additional
QPD 1..1 Yes additional
ROW_DEFINITION 0..1 additional
RDF 1..1 Yes additional
RDT 0..* additional
DSC 0..1 additional

Original Mode Acknowledgement Choreography for RTB^Z74^RTB_Z74

Send Immediate Ack: ACK^Z73^ACK

Enhanced Mode Acknowledgement Choreography for RTB^Z74^RTB_Z74

When the MSH-15 value of a RTB^Z74^RTB_Z74 message is AL or ER or SU, an ACK^Z73^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of a RTB^Z74^RTB_Z74 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a RTB^Z74^RTB_Z74 message is AL or ER or SU, a message SHALL be sent as an application ack.

When the MSH-16 value of a RTB^Z74^RTB_Z74 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^Z73^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack:
NE, AL, ER, SU (none)

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|Pharm||20000303201400-0800||QBP^Z73^QBP_Z73|9901|P|2.8|

QPD|Z89^Query Phone Calls^HL70471|Q010|12345|2000030100000^20000302235959|Y

RCP|I|20^RD|

Answer:

MSH|^&~\|Pharm|Gen Hosp|PCR||20000303201430-0800||RTB^Z74^RTB_Z74|8858|P|2.8|

MSA|AA|9901|

QAK|Q010|OK|Z89^Query Phone Calls^HL70471|4

QPD|Z89^Query Phone Calls^HL70471|Q010|12345|2000030100000^20000302235959|Y|

RDF|9|Provider^ST^20|Region^ST^40|Extension^XTN^40|Destination^XTN^40|Date/Time^DTM^24|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/06 till 3/3/06. Transfer the first 10 records.

Query:

MSH|^&~\|PCR|Gen Hosp|Pharm||200611201400-0800||QBP^Z73^QBP_Z73|ACK9901|P|2.8|

QPD|Z89^Query Phone Calls^HL70471|Q010|12345|2006030100000^20060302235959|Y|

RCP|I|10^RD|

Answer:

MSH|^&~\|Pharm|Gen Hosp|PCR||200611201401-0800||RTB^Z74^RTB_Z74|8858|P|2.8|

MSA|AA|8858 QAK|Q010|OK|Z89^Query Phone Calls^HL70471|4

QPD|Z89^Query Phone Calls^HL70471|Q010|12345|2006030100000^20060302235959|Y|

RDF|9|Provider^ST^20|Region^ST^40|Extension^XTN^40|Destination^XTN^40|Date/Time^DTM^24|Quantity^NM^4|Duration^NM^4|Units^NM^4|Amount^MO^8|

RDT|DTAG|CITY|12345|555-1234|200603021715||20|12|2.25|

RDT|DTAG|CITY|12345|555-4569|200603011252||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 = .

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.

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.

OMD - Dietary Order (Event O03)

The ODS segment is intended to cover the basic diet definition of one diet code. A diet can be ordered as a combination of one or more diet specifications, followed by any number of supplements and/or preferences. Many diets are common to all institutions, such as an ADA 1500 calorie diet, and may exist in a table. Each diet code is limited to a six-character abbreviation.

A dietary message never specifies more than one diet. However, a single diet order may be used to discontinue one diet and specify its replacement. In this instance, the dietary message will contain two ORCs. The first ORC will not contain an ODT. A tray specification order may follow the second ORC.

Often a complete diet order consists of a single diet code. The diet code defines which foods a patient may receive. In cases where a patient cannot make food selections, a diet code often causes service of a predefined set of foods. A patient must have at least one diet code to receive food.

Supplements provide a mechanism for giving any additional desired foods to a patient. Supplements are foods given to a patient regardless of their diet codes. These foods are part of the patient's diet without being restricted by any other part of the order. Therefore, supplement assignment needs to be a controlled and supervised process to ensure that a patient does not receive improper or potentially harmful foods.

Preferences consist of likes, dislikes, substitutions, and complementary foods. Preferences are diet orders, effectively from the patient, but transmitted from the ward. They are subject to change. A mechanism is included for defining patient preferences with this proposal. Preferences are independent of the diet order and do not change when the order changes. However, if a preference violates the conditions of the diet order, then that preference is not allowed.

There is additional information that the dietary service requires for proper operation, including tray delivery times, extra trays, and messages regarding tray delivery and handling.

A patient can have only one effective diet order at a time. A diet order consists of the diet codes, supplements, and preferences effective at a given time. These three specifications govern which foods a patient will receive. Diets generally do not have a stated ending time to ensure that the patient always receives food (unless an NPO order is received).

Diet codes govern foods in two ways. First, there are foods which are simply not allowed on a specified diet. Second, some diets imply a nutrient exchange pattern which controls the amounts of certain foods that a patient can receive. Some diet codes can combine to make a single diet order. An ADA 1500 and a 2 gram sodium (NA2GM) diet can coexist since they do not address the same exchanges. The patterns for these diets can combine without conflicting or overlapping. Certain kinds of diet codes cannot be combined, such as ADA 1500 and ADA 2000. It is impossible to feed a patient at two different calorie levels. These constraints are not defined in the table, but rather are implied by the semantics of the codes.

An order specifies the complete foods a patient can or should receive at a given meal. (Depending on the institution and diet order, a patient may or may not have a choice of foods. For example, a clear liquid diet often gives no choices since there are few clear liquid foods.) A modification to a diet, by adding a diet code or supplement, may have a drastic effect on foods the patient may eat. Due to this, any modification to the diet codes or supplements will be a new order. Therefore, one must send any information for diet codes or supplements from the previous order which is still applicable for the next order. For example, a patient has an ADA 1500 calorie diet and an evening snack of Skim Milk. If you wanted to add a 2 gram sodium restriction, you need to send both the ADA 1500 calorie and the 2 gram sodium diet codes along with the Skim Milk supplement. If you do not do this, the dietary application must presume the new order is merely for 2 grams of sodium. This method allows for a comprehensive audit trail of orders and prevents ambiguities in interpretation.

OMD^O03^OMD_O03: Dietary Order
HL7 MessageStructure Table - OMD_O03
Segment Cardinality Must Implement Status
OMD_O03
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
NTE 0..* additional
PATIENT 0..1 additional
PID 1..1 Yes additional
PD1 0..1 additional
PRT 0..* additional
ARV 0..* B
NTE 0..* additional
GT1 0..1 additional
AL1 0..* additional
PATIENT_VISIT 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
PRT 0..* additional
INSURANCE 0..* additional
IN1 1..1 Yes additional
IN2 0..1 additional
IN3 0..1 additional
ORDER_DIET 1..* Yes additional
ORC 1..1 Yes additional
PRT 0..* additional
TIMING_DIET 0..* additional
TQ1 1..1 Yes additional
TQ2 0..* additional
DIET 0..1 additional
ODS 1..* Yes additional
NTE 0..* additional
OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
NTE 0..* additional
ORDER_TRAY 0..* additional
ORC 1..1 Yes additional
PRT 0..* additional
ODT 1..* Yes additional
NTE 0..* additional
TIMING_TRAY 0..* additional
TQ1 1..1 Yes additional
TQ2 0..* additional

Original Mode Acknowledgement Choreography for OMD^O03^OMD_O03

Send Application Ack: ORD^O04^ORD_O04

Enhanced Mode Acknowledgement Choreography for OMD^O03^OMD_O03

When the MSH-15 value of an OMD^O03^OMD_O03 message is AL or ER or SU, an ACK^O03^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an OMD^O03^OMD_O03 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an OMD^O03^OMD_O03 message is AL or ER or SU, an ORD^O04^ORD_O04 or OSU^O52^OSU_O52 message SHALL be sent as an application ack.

When the MSH-16 value of an OMD^O03^OMD_O03 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^O03^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ORD^O04^ORD_O04 or OSU^O52^OSU_O52
NE, AL, ER, SU (none)

ORD - dietary order acknowledgment (Event O04)

There is not supposed to be an Application Level acknowledgement to an Application Level Acknowledgement message. In Enhanced Mode, MSH-16 SHALL always be set to NE (Never).

ORD^O04^ORD_O04: Dietary Order Acknowledgment Message
HL7 MessageStructure Table - ORD_O04
Segment Cardinality Must Implement Status
ORD_O04
MSH 1..1 Yes additional
MSA 1..1 Yes additional
ARV 0..* additional
ERR 0..* additional
SFT 0..* additional
UAC 0..1 additional
NTE 0..* additional
RESPONSE 0..1 additional
PATIENT 0..1 additional
PID 1..1 Yes additional
PRT 0..* additional
ARV 0..* B
NTE 0..* additional
ORDER_DIET 1..* Yes additional
ORC 1..1 Yes additional
PRT 0..* additional
ODS 0..* additional
NTE 0..* additional
TIMING_DIET 0..* additional
TQ1 1..1 Yes additional
TQ2 0..* additional
ORDER_TRAY 0..* additional
ORC 1..1 Yes additional
PRT 0..* additional
ODT 0..* additional
NTE 0..* additional
TIMING_TRAY 0..* additional
TQ1 1..1 Yes additional
TQ2 0..* additional

Original Mode Acknowledgement Choreography for ORD^O04^ORD_O04

Send Immediate Ack: ACK^O04^ACK

Enhanced Mode Acknowledgement Choreography for ORD^O04^ORD_O04

When the MSH-15 value of an ORD^O04^ORD_O04 message is AL or ER or SU, an ACK^O04^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ORD^O04^ORD_O04 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ORD^O04^ORD_O04 message is AL or ER or SU, a message SHALL be sent as an application ack.

When the MSH-16 value of an ORD^O04^ORD_O04 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^O04^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack:
NE, AL, ER, SU (none)

Diet Segments

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, TQ1-7/8-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. TQ1-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^^20010415|.

HL7 Attribute Table - ODS - dietary orders, supplements, and preferences segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
ODS
1 Type ID R
0159(R) Diet Code Specification Type(Required)
[1..1] 00269 [1..1]
2 Service Period CWE O
[0..10] 00270
3 Diet, Supplement, or Preference Code CWE R
0628
[1..20] 00271
4 Text Instruction ST O
[0..2] 00272 80 #

ODS-1: Type (ID) 00269

FIXME

ODS-2: Service Period (CWE) 00270

FIXME

ODS-3: Diet, Supplement, or Preference Code (CWE) 00271

FIXME

ODS-4: Text Instruction (ST) 00272

FIXME

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 segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
ODT
1 Tray Type CWE R
0160(R) Tray Type(Required)
[1..1] 00273
2 Service Period CWE O
[0..10] 00270
3 Text Instruction ST O
[0..1] 00272 80 #

ODT-1: Tray Type (CWE) 00273

FIXME

ODT-2: Service Period (CWE) 00270

FIXME

ODT-3: Text Instruction (ST) 00272

FIXME

Diet Message Examples

Typical progression of orders for a surgery patient

First order:

MSH|...

PID|...

ORC|NW|1235^NURS|||||^^^199108021700||200608021200|333-77-7777^COMRAD^CONNOR^C|999-99-9999^VERIFY^VIRGIL^V|...

ODS|D||321^DB15^99DO3|...

ODS|D||322^NA2GM^99DO3|

Hold first order:

MSH|...

PID|...

ORC|HD|1235^NURS|||||^^^200608031700||200608031200|333-77-7777^COMRAD^CONNOR^C|999-99-9999^VERIFY^VIRGIL^V|...

NPO order with guest tray:    

MSH|...

PID|...

ORC|NW|1236^NURS|||||^^^200608031700||200608031200|333-77-7777^COMRAD^CONNOR^C|999-99-9999^VERIFY^VIRGIL^V|...

ODS|D||323^NPO^99DO3|...

ORC|NW|1244^NURS|||||^^^200608031700||200608031200|333-77-7777^COMRAD^CONNOR^C|999-99-9999^VERIFY^VIRGIL^V|...

ODT|GUEST^Guest tray^HL70160|5^^99CBD|...

Clear liquid with guest tray:

MSH|...

PID|...

ORC|DC|1236^NURS|||||^^^200608041700||200608041200|333-77-7777^COMRAD^CONNOR^C|999-99-9999^VERIFY^VIRGIL^V|...

ORC|NW|1237^NURS|||||^^^200608041700||200608041200|333-77-7777^COMRAD^CONNOR^C|999-99-9999^VERIFY^VIRGIL^V|...

ODS|D||321^DB15^99DO3|...

ODS|D||322^NA2GM^99DO3|...

ODS|D||324^CLRLIQ^99DO3|...

ORC|NW|1245^NURS|||||^^^200608041700||200608041200|333-77-7777^COMRAD^CONNOR^C|999-99-9999^VERIFY^VIRGIL^V|...

ODT|GUEST^Guest tray^HL70160|5^^99CBD|...

Full liquid with guest tray:

MSH|...

PID|...

ORC|DC|1237^NURS|||||^^^200608051700||200608051200|333-77-7777^COMRAD^CONNOR^C|999-99-9999^VERIFY^VIRGIL^V|...

ORC|NW|1238^NURS|||||^^^200608051700||200608051200|333-77-7777^COMRAD^CONNOR^C|999-99-9999^VERIFY^VIRGIL^V|...

ODS|D||321^DB15^99DO3|...

ODS|D||322^NA2GM^99DO3|...

ODS|D||325^FULLIQ^99DO3|...

ORC|NW|1246^NURS|||||^^^200608051700||200608051200|333-77-7777^COMRAD^CONNOR^C|999-99-9999^VERIFY^VIRGIL^V|...

ODT|GUEST^Guest tray^HL70160|3^^99CBD|...

Release hold on previous order and give discharge message:

MSH|...

PID|...

ORC|DC|1238^NURS|||||^^^200608061700||200608061200|333-77-7777^COMRAD^CONNOR^C|999-99-9999^VERIFY^VIRGIL^V|...

ORC|RL|1235^NURS|||||^^^200608061700||200608061200|333-77-7777^COMRAD^CONNOR^C|999-99-9999^VERIFY^VIRGIL^V|...

ORC|NW|1247^NURS|||||^^^200608061700||200608061200|333-77-7777^COMRAD^CONNOR^C|999-99-9999^VERIFY^VIRGIL^V|...

ODT|MSG^Tray message only^HL70160|5^^99CBD|You Will Be Leaving Tomorrow|...

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

PID|...

ORC|NW|1234^NURS|||||^^^200608021700||200608021200|333-77-7777^COMRAD^CONNOR^C|999-99-9999^VERIFY^VIRGIL^V|...

ODS|D||011^HIPRO100^99FD1|...

ODS|D||123^LOFAT20^99FD1|...

ODS|S|4|119^ICE CREAM^99FD8|...

ODS|S|6|320^1/2 HAM SANDWICH^99FD8|...

ORC|NW|1244^NURS|||||^^^200608031700||200608031200|333-77-7777^COMRAD^CONNOR^C|999-99-9999^VERIFY^VIRGIL^V|...

ODT|EARLY^Early tray^HL70160|1^^99CBD|...

ORC|NW|1245^NURS|||||^^^200608031700||200608031200|333-77-7777^COMRAD^CONNOR^C|999-99-9999^VERIFY^VIRGIL^V|...

ODT|LATE^Late tray^HL70160|3^^99CBD|...

ORC|NW|1246^NURS|||||^^^200608031700||200608031200|333-77-7777^COMRAD^CONNOR^C|999-99-9999^VERIFY^VIRGIL^V|...

ODT|GUEST^Guest tray^HL70160|5^DINNER^99CBD|...

Tube feeding

This order specifies Similac with MCT oil and polycose additives.

MSH|...

PID|...

ORC|NW|1232^NURS|||||60^Q3H^^200608021700||200608021200|333-77-7777^COMRAD^CONNOR^C|999-99-9999^VERIFY^VIRGIL^V|...

ODS|D||010^SIMILAC^99DO1|...

ODS|D||011^MCT^99DO1|...

ODS|D||012^POLYCOSE^99DO1|...

Patient preference

This order specifies that the patient is a vegetarian.

MSH|...

PID|...

ORC|NW|1232^NURS|||||60^Q3H^^200608021700||200608021200|333-77-7777^COMRAD^CONNOR^C|999-99-9999^VERIFY^VIRGIL^V|...

ODS|D||123^LOFAT20^99FD1|...

ODS|S|4|119^ICE CREAM^99FD8|...

ODS|P||^VEGETARIAN|...

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.

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
HL7 MessageStructure Table - OMS_O05
Segment Cardinality Must Implement Status
OMS_O05
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
NTE 0..* additional
PATIENT 0..1 additional
PID 1..1 Yes additional
PD1 0..1 additional
PRT 0..* additional
ARV 0..* B
NTE 0..* additional
GT1 0..1 additional
AL1 0..* additional
PATIENT_VISIT 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
PRT 0..* additional
INSURANCE 0..* additional
IN1 1..1 Yes additional
IN2 0..1 additional
IN3 0..1 additional
ORDER 1..* Yes additional
ORC 1..1 Yes additional
PRT 0..* additional
RQD 1..1 Yes additional
RQ1 0..1 additional
NTE 0..* additional
BLG 0..1 additional
TIMING 0..* additional
TQ1 1..1 Yes additional
TQ2 0..* additional
OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
NTE 0..* additional

Original Mode Acknowledgement Choreography for OMS^O05^OMS_O05

Send Application Ack: ORS^O06^ORS_O06

Enhanced Mode Acknowledgement Choreography for OMS^O05^OMS_O05

When the MSH-15 value of an OMS^O05^OMS_O05 message is AL or ER or SU, an ACK^O05^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an OMS^O05^OMS_O05 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an OMS^O05^OMS_O05 message is AL or ER or SU, an ORS^O06^ORS_O06 or OSU^O52^OSU_O52 message SHALL be sent as an application ack.

When the MSH-16 value of an OMS^O05^OMS_O05 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^O05^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ORS^O06^ORS_O06 or OSU^O52^OSU_O52
NE, AL, ER, SU (none)

ORS - stock requisition order acknowledgment message (event O06)

There is not supposed to be an Application Level acknowledgement to an Application Level Acknowledgement message. In Enhanced Mode, MSH-16 SHALL always be set to NE (Never).

ORS^O06^ORS_O06: Stock Order Acknowledgment Message
HL7 MessageStructure Table - ORS_O06
Segment Cardinality Must Implement Status
ORS_O06
MSH 1..1 Yes additional
MSA 1..1 Yes additional
ARV 0..* additional
ERR 0..* additional
SFT 0..* additional
UAC 0..1 additional
NTE 0..* additional
RESPONSE 0..1 additional
PATIENT 0..1 additional
PID 1..1 Yes additional
PRT 0..* additional
ARV 0..* B
NTE 0..* additional
ORDER 1..* Yes additional
ORC 1..1 Yes additional
PRT 0..* additional
RQD 1..1 Yes additional
RQ1 0..1 additional
NTE 0..* additional
TIMING 0..* additional
TQ1 1..1 Yes additional
TQ2 0..* additional

Original Mode Acknowledgement Choreography for ORS^O06^ORS_O06

Send Immediate Ack: ACK^O06^ACK

Enhanced Mode Acknowledgement Choreography for ORS^O06^ORS_O06

When the MSH-15 value of an ORS^O06^ORS_O06 message is AL or ER or SU, an ACK^O06^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ORS^O06^ORS_O06 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ORS^O06^ORS_O06 message is AL or ER or SU, a message SHALL be sent as an application ack.

When the MSH-16 value of an ORS^O06^ORS_O06 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^O06^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack:
NE, AL, ER, SU (none)

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
HL7 MessageStructure Table - OMS_O05
Segment Cardinality Must Implement Status
OMS_O05
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
NTE 0..* additional
PATIENT 0..1 additional
PID 1..1 Yes additional
PD1 0..1 additional
PRT 0..* additional
ARV 0..* B
NTE 0..* additional
GT1 0..1 additional
AL1 0..* additional
PATIENT_VISIT 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
PRT 0..* additional
INSURANCE 0..* additional
IN1 1..1 Yes additional
IN2 0..1 additional
IN3 0..1 additional
ORDER 1..* Yes additional
ORC 1..1 Yes additional
PRT 0..* additional
RQD 1..1 Yes additional
RQ1 0..1 additional
NTE 0..* additional
BLG 0..1 additional
TIMING 0..* additional
TQ1 1..1 Yes additional
TQ2 0..* additional
OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
NTE 0..* additional

Original Mode Acknowledgement Choreography for OMN^O07^OMN_O07

Send Application Ack: ORN^O08^ORN_O08

Enhanced Mode Acknowledgement Choreography for OMN^O07^OMN_O07

When the MSH-15 value of an OMN^O07^OMN_O07 message is AL or ER or SU, an ACK^O07^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an OMN^O07^OMN_O07 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an OMN^O07^OMN_O07 message is AL or ER or SU, an ORN^O08^ORN_O08 or OSU^O52^OSU_O52 message SHALL be sent as an application ack.

When the MSH-16 value of an OMN^O07^OMN_O07 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^O07^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ORN^O08^ORN_O08 or OSU^O52^OSU_O52
NE, AL, ER, SU (none)

ORN - non-stock requisition order acknowledgment message (event O08)

There is not supposed to be an Application Level acknowledgement to an Application Level Acknowledgement message. In Enhanced Mode, MSH-16 SHALL always be set to NE (Never).

ORN^O08^ORN_O08: General Order Acknowledgment Message
HL7 MessageStructure Table - ORS_O06
Segment Cardinality Must Implement Status
ORS_O06
MSH 1..1 Yes additional
MSA 1..1 Yes additional
ARV 0..* additional
ERR 0..* additional
SFT 0..* additional
UAC 0..1 additional
NTE 0..* additional
RESPONSE 0..1 additional
PATIENT 0..1 additional
PID 1..1 Yes additional
PRT 0..* additional
ARV 0..* B
NTE 0..* additional
ORDER 1..* Yes additional
ORC 1..1 Yes additional
PRT 0..* additional
RQD 1..1 Yes additional
RQ1 0..1 additional
NTE 0..* additional
TIMING 0..* additional
TQ1 1..1 Yes additional
TQ2 0..* additional

Original Mode Acknowledgement Choreography for ORN^O08^ORN_O08

Send Immediate Ack: ACK^O08^ACK

Enhanced Mode Acknowledgement Choreography for ORN^O08^ORN_O08

When the MSH-15 value of an ORN^O08^ORN_O08 message is AL or ER or SU, an ACK^O08^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ORN^O08^ORN_O08 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ORN^O08^ORN_O08 message is AL or ER or SU, a message SHALL be sent as an application ack.

When the MSH-16 value of an ORN^O08^ORN_O08 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^O08^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack:
NE, AL, ER, SU (none)

Supply Segments

RQD - Requisition Detail Segment

RQD contains the detail for each requisitioned item. See assumptions above.

HL7 Attribute Table - RQD - Requisition Detail Segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
RQD
1 Requisition Line Number SI O
[0..1] 00275 [1..4]
2 Item Code - Internal CWE C
0684
[0..1] 00276
3 Item Code - External CWE C
0685
[0..1] 00277
4 Hospital Item Code CWE C
0686
[0..1] 00278
5 Requisition Quantity NM O
[0..1] 00279 6 #
6 Requisition Unit of Measure CWE O
0687
[0..1] 00280
7 Cost Center Account Number CX O
0319 Department Cost Center
[0..1] 00281
8 Item Natural Account Code CWE O
0320 Item Natural Account Code
[0..1] 00282
9 Deliver To ID CWE O
0688
[0..1] 00283
10 Date Needed DT O
[0..1] 00284

RQD-1: Requisition Line Number (SI) 00275

FIXME

RQD-2: Item Code - Internal (CWE) 00276

FIXME

RQD-3: Item Code - External (CWE) 00277

FIXME

RQD-4: Hospital Item Code (CWE) 00278

FIXME

RQD-5: Requisition Quantity (NM) 00279

FIXME

RQD-6: Requisition Unit of Measure (CWE) 00280

FIXME

RQD-7: Cost Center Account Number (CX) 00281

FIXME

RQD-8: Item Natural Account Code (CWE) 00282

FIXME

RQD-9: Deliver To ID (CWE) 00283

FIXME

RQD-10: Date Needed (DT) 00284

FIXME

RQ1 - Requisition Detail-1 Segment

RQ1 contains additional detail for each non-stock requisitioned item. This segment definition is paired with a preceding RQD segment.

HL7 Attribute Table - RQ1 - Requisition Detail-1 Segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
RQ1
1 Anticipated Price ST O
[0..1] 00285 10 #
2 Manufacturer Identifier CWE C
0385 Manufacturer Identifier
[0..1] 00286
3 Manufacturer's Catalog ST C
[0..1] 00287 16 #
4 Vendor ID CWE C
0683
[0..1] 00288
5 Vendor Catalog ST C
[0..1] 00289 16 #
6 Taxable ID O
0136(R) Yes/no Indicator(Required)
[0..1] 00290 [1..1]
7 Substitute Allowed ID O
0136(R) Yes/no Indicator(Required)
[0..1] 00291 [1..1]

RQ1-1: Anticipated Price (ST) 00285

FIXME

RQ1-2: Manufacturer Identifier (CWE) 00286

FIXME

RQ1-3: Manufacturer's Catalog (ST) 00287

FIXME

RQ1-4: Vendor ID (CWE) 00288

FIXME

RQ1-5: Vendor Catalog (ST) 00289

FIXME

RQ1-6: Taxable (ID) 00290

FIXME

RQ1-7: Substitute Allowed (ID) 00291

FIXME

Supply Message Examples

Patient order

This example is a requisition from the ORSUPPLY application to the MMSUPPLY application for two items for patient Adam A. Everyman. 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|^~VALUEamp;|ORSUPPLY|ORSYS|MMSUPPLY|MMSYS|20061105131523||OMS^O05^OMS_O05| ...

PID|...

ORC|NW|RQ101^ORSUPPLY||||N|||20061105130000||333-77-7777^COMRAD^CONNOR^C|999-99-9999^VERIFY^VIRGIL^V|MAINOR^2W|321-1234 X2304^^^^^^3211234^2304|...

RQD|1|1234^Solution, 2.25% Saline||S1786^Saline Solution|1|BT^Bottle|1234-5678||ORSUP^Main OR Supply Room|20061123|...

MSH|^~VALUEamp;|ORSUPPLY|ORSYS|MMSUPPLY|MMSYS|19911105131523||OMN^O07^OMN_O07|...

PID|...

ORC|NW|RQ102^ORSUPPLY||||N|||20061105130000||333-77-7777^COMRAD^CONNOR^C|999-99-9999^VERIFY^VIRGIL^V |MAINOR^2W|321-1234 X2304^^^^^^3211234^2304

RQD|1|23455^Implant, Special Hip||I45323^Implant|1|EA^ Each|1234-5678||ORSUP^Main OR Supply Room|20061123|...

RQ1|123.45|DET^Detter, Inc.|444456|DST^Local Distributors, Inc.|333-456|N|...

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|^~VALUEamp;|ORSUPPLY|ORSYS|MMSUPPLY|MMSYS|20061105131523||OMS^O05^OMS_O05|...

ORC|NW|RQ103^ORSUPPLY||||N|||20061105130000||333-77-7777^COMRAD^CONNOR^C|999-99-9999^VERIFY^VIRGIL^V |MAINOR^2W|321-1234 X2304^^^^^^3211234^2304|...

RQD|1|1232^Solution, 1% Saline||S1784^Saline Solution|5|BT^Bottle|1234-5678||ORSUP^Main OR Supply Room|20061105|...

ORC|NW|RQ104^ORSUPPLY||||N|||20061105130000||333-77-7777^COMRAD^CONNOR^C|999-99-9999^VERIFY^VIRGIL^V |MAINOR^2W|321-1234 X2304^^^^^^3211234^2304|...

RQD|2|1231^Solution, 0.2% Saline||S1781^Saline Solution|2|BT^Bottle|1234-5678||ORSUP^Main OR Supply Room|20061105|...

ORC|NW|RQ105^ORSUPPLY||||N|||20061105130000||333-77-7777^COMRAD^CONNOR^C|999-99-9999^VERIFY^VIRGIL^V |MAINOR^2W|321-1234 X2304^^^^^^3211234^2304|...

RQD|3|2342^Suture, Black Silk||SU123^Suture|2|DZ^Dozen|1234-5678||ORSUP^Main OR Supply Room|20061105|...

ORC|NW|RQ106^ORSUPPLY||||N|||20061105130000||333-77-7777^COMRAD^CONNOR^C|999-99-9999^VERIFY^VIRGIL^V |MAINOR^2W|321-1234 X2304^^^^^^3211234^2304|...

RQD|4|2344^Suture, Black Silk 3-0||SU124^Suture|1|DZ^Dozen|1234-5678||ORSUP^Main OR Supply Room|20061105|...

ORC|NW|RQ107^ORSUPPLY||||N|||20061105130000||333-77-7777^COMRAD^CONNOR^C|999-99-9999^VERIFY^VIRGIL^V |MAINOR^2W|321-1234 X2304^^^^^^3211234^2304|...

RQD|5|4565^Bandage Pad, 4x4||B6345^Bandage Pad|3|BX^Box|1234-5678||ORSUP^Main OR Supply Room|20061105|...

Transfusion Service (Blood Bank) Trigger Events & Messages

Usage notes for transfusion service messages

OMB – Blood Product Order Message (Event O27)

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
HL7 MessageStructure Table - OMB_O27
Segment Cardinality Must Implement Status
OMB_O27
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
NTE 0..* additional
PATIENT 0..1 additional
PID 1..1 Yes additional
PD1 0..1 additional
PRT 0..* additional
ARV 0..* B
NTE 0..* additional
GT1 0..1 additional
AL1 0..* additional
PATIENT_VISIT 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
PRT 0..* additional
INSURANCE 0..* additional
IN1 1..1 Yes additional
IN2 0..1 additional
IN3 0..1 additional
ORDER 1..* Yes additional
ORC 1..1 Yes additional
PRT 0..* additional
BPO 1..1 Yes additional
SPM 0..1 additional
NTE 0..* additional
DG1 0..* additional
FT1 0..* additional
BLG 0..1 additional
TIMING 0..* additional
TQ1 1..1 Yes additional
TQ2 0..* additional
OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
NTE 0..* additional

Original Mode Acknowledgement Choreography for OMB^O27^OMB_O27

Send Application Ack: ORB^O28^ORB_O28

Enhanced Mode Acknowledgement Choreography for OMB^O27^OMB_O27

When the MSH-15 value of an OMB^O27^OMB_O27 message is AL or ER or SU, an ACK^O27^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an OMB^O27^OMB_O27 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an OMB^O27^OMB_O27 message is AL or ER or SU, an ORB^O28^ORB_O28 or OSU^O52^OSU_O52 message SHALL be sent as an application ack.

When the MSH-16 value of an OMB^O27^OMB_O27 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^O27^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ORB^O28^ORB_O28 or OSU^O52^OSU_O52
NE, AL, ER, SU (none)

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.

ORB – Blood Product Order Acknowledgment (Event O28)

There is not supposed to be an Application Level acknowledgement to an Application Level Acknowledgement message. In Enhanced Mode, MSH-16 SHALL always be set to NE (Never).

ORB^O28^ORB_O28: Description
HL7 MessageStructure Table - ORB_O28
Segment Cardinality Must Implement Status
ORB_O28
MSH 1..1 Yes additional
MSA 1..1 Yes additional
ARV 0..* additional
ERR 0..* additional
SFT 0..* additional
UAC 0..1 additional
NTE 0..* additional
RESPONSE 0..1 additional
PATIENT 0..1 additional
PID 1..1 Yes additional
PRT 0..* additional
ARV 0..* B
ORDER 0..* additional
ORC 1..1 Yes additional
PRT 0..* additional
BPO 0..1 additional
TIMING 0..* additional
TQ1 1..1 Yes additional
TQ2 0..* additional

Original Mode Acknowledgement Choreography for ORB^O28^ORB_O28

Send Immediate Ack: ACK^O28^ACK

Enhanced Mode Acknowledgement Choreography for ORB^O28^ORB_O28

When the MSH-15 value of an ORB^O28^ORB_O28 message is AL or ER or SU, an ACK^O28^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ORB^O28^ORB_O28 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ORB^O28^ORB_O28 message is AL or ER or SU, a message SHALL be sent as an application ack.

When the MSH-16 value of an ORB^O28^ORB_O28 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^O28^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack:
NE, AL, ER, SU (none)

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
HL7 MessageStructure Table - BPS_O29
Segment Cardinality Must Implement Status
BPS_O29
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
NTE 0..* additional
PATIENT 0..1 additional
PID 1..1 Yes additional
PD1 0..1 additional
PRT 0..* additional
ARV 0..* B
NTE 0..* additional
PATIENT_VISIT 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
PRT 0..* additional
ORDER 1..* Yes additional
ORC 1..1 Yes additional
PRT 0..* additional
BPO 1..1 Yes additional
NTE 0..* additional
TIMING 0..* additional
TQ1 1..1 Yes additional
TQ2 0..* additional
PRODUCT 0..* additional
BPX 1..1 Yes additional
NTE 0..* additional

Original Mode Acknowledgement Choreography for BPS^O29^BPS_O29

Send Application Ack: BRP^O30^BRP_O30

Enhanced Mode Acknowledgement Choreography for BPS^O29^BPS_O29

When the MSH-15 value of a BPS^O29^BPS_O29 message is AL or ER or SU, an ACK^O29^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of a BPS^O29^BPS_O29 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a BPS^O29^BPS_O29 message is AL or ER or SU, a BRP^O30^BRP_O30 message SHALL be sent as an application ack.

When the MSH-16 value of a BPS^O29^BPS_O29 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^O29^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: BRP^O30^BRP_O30
NE, AL, ER, SU (none)

BRP – Blood Product Dispense Status Acknowledgment (Event O30)

There is not supposed to be an Application Level acknowledgement to an Application Level Acknowledgement message. In Enhanced Mode, MSH-16 SHALL always be set to NE (Never).

BRP^O30^BRP_O30: Description
HL7 MessageStructure Table - BRP_O30
Segment Cardinality Must Implement Status
BRP_O30
MSH 1..1 Yes additional
MSA 1..1 Yes additional
ARV 0..* additional
ERR 0..* additional
SFT 0..* additional
UAC 0..1 additional
NTE 0..* additional
RESPONSE 0..1 additional
PATIENT 0..1 additional
PID 1..1 Yes additional
PRT 0..* additional
ARV 0..* B
ORDER 0..* additional
ORC 1..1 Yes additional
PRT 0..* additional
BPO 0..1 additional
BPX 0..* additional
TIMING 0..* additional
TQ1 1..1 Yes additional
TQ2 0..* additional

Original Mode Acknowledgement Choreography for BRP^O30^BRP_O30

Send Immediate Ack: ACK^O30^ACK

Enhanced Mode Acknowledgement Choreography for BRP^O30^BRP_O30

When the MSH-15 value of a BRP^O30^BRP_O30 message is AL or ER or SU, an ACK^O30^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of a BRP^O30^BRP_O30 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a BRP^O30^BRP_O30 message is AL or ER or SU, a message SHALL be sent as an application ack.

When the MSH-16 value of a BRP^O30^BRP_O30 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^O30^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack:
NE, AL, ER, SU (none)

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
HL7 MessageStructure Table - BTS_O31
Segment Cardinality Must Implement Status
BTS_O31
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
NTE 0..* additional
PATIENT 0..1 additional
PID 1..1 Yes additional
PD1 0..1 additional
PRT 0..* additional
NTE 0..* additional
PATIENT_VISIT 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
PRT 0..* additional
ORDER 1..* Yes additional
ORC 1..1 Yes additional
PRT 0..* additional
BPO 1..1 Yes additional
NTE 0..* additional
TIMING 0..* additional
TQ1 1..1 Yes additional
TQ2 0..* additional
PRODUCT_STATUS 0..* additional
BTX 1..1 Yes additional
NTE 0..* additional

Original Mode Acknowledgement Choreography for BTS^O31^BTS_O31

Send Application Ack: BRT^O32^BRT_O32

Enhanced Mode Acknowledgement Choreography for BTS^O31^BTS_O31

When the MSH-15 value of a BTS^O31^BTS_O31 message is AL or ER or SU, an ACK^O31^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of a BTS^O31^BTS_O31 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a BTS^O31^BTS_O31 message is AL or ER or SU, a BRT^O32^BRT_O32 message SHALL be sent as an application ack.

When the MSH-16 value of a BTS^O31^BTS_O31 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^O31^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: BRT^O32^BRT_O32
NE, AL, ER, SU (none)

BRT – Blood Product Transfusion/Disposition Acknowledgment (Event O32)

There is not supposed to be an Application Level acknowledgement to an Application Level Acknowledgement message. In Enhanced Mode, MSH-16 SHALL always be set to NE (Never).

BRT^O32^BRT_O32: Description
HL7 MessageStructure Table - BRT_O32
Segment Cardinality Must Implement Status
BRT_O32
MSH 1..1 Yes additional
MSA 1..1 Yes additional
ARV 0..* additional
ERR 0..* additional
SFT 0..* additional
UAC 0..1 additional
NTE 0..* additional
RESPONSE 0..1 additional
PATIENT 0..1 additional
PID 1..1 Yes additional
PRT 0..* additional
ARV 0..* B
ORDER 0..* additional
ORC 1..1 Yes additional
PRT 0..* additional
BPO 0..1 additional
BTX 0..* additional
TIMING 0..* additional
TQ1 1..1 Yes additional
TQ2 0..* additional

Original Mode Acknowledgement Choreography for BRT^O32^BRT_O32

Send Immediate Ack: ACK^O32^ACK

Enhanced Mode Acknowledgement Choreography for BRT^O32^BRT_O32

When the MSH-15 value of a BRT^O32^BRT_O32 message is AL or ER or SU, an ACK^O32^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of a BRT^O32^BRT_O32 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a BRT^O32^BRT_O32 message is AL or ER or SU, a message SHALL be sent as an application ack.

When the MSH-16 value of a BRT^O32^BRT_O32 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^O32^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack:
NE, AL, ER, SU (none)

Transfusion Service (Blood Bank) Segments

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 Segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
BPO
1 Set ID – BPO SI R
[1..1] 01700 [1..4]
2 BP Universal Service Identifier CWE R
0575
[1..1] 01701
3 BP Processing Requirements CWE O
0508 Blood Product Processing Requirements
[0..*] 01702
4 BP Quantity NM R
[1..1] 01703 5 #
5 BP Amount NM O
[0..1] 01704 5 #
6 BP Units CWE O
0576
[0..1] 01705
7 BP Intended Use Date/Time DTM O
[0..1] 01706
8 BP Intended Dispense From Location PL O
[0..1] 01707
9 BP Intended Dispense From Address XAD O
[0..1] 01708
10 BP Requested Dispense Date/Time DTM O
[0..1] 01709
11 BP Requested Dispense To Location PL O
[0..1] 01710
12 BP Requested Dispense To Address XAD O
[0..1] 01711
13 BP Indication for Use CWE O
0509 Indication for Use
[0..*] 01712
14 BP Informed Consent Indicator ID O
0136(R) Yes/no Indicator(Required)
[0..1] 01713 [1..1]

BPO-1: Set ID – BPO (SI) 01700

FIXME

BPO-2: BP Universal Service Identifier (CWE) 01701

FIXME

BPO-3: BP Processing Requirements (CWE) 01702

FIXME

BPO-4: BP Quantity (NM) 01703

FIXME

BPO-5: BP Amount (NM) 01704

FIXME

BPO-6: BP Units (CWE) 01705

FIXME

BPO-7: BP Intended Use Date/Time (DTM) 01706

FIXME

BPO-8: BP Intended Dispense From Location (PL) 01707

FIXME

BPO-9: BP Intended Dispense From Address (XAD) 01708

FIXME

BPO-10: BP Requested Dispense Date/Time (DTM) 01709

FIXME

BPO-11: BP Requested Dispense To Location (PL) 01710

FIXME

BPO-12: BP Requested Dispense To Address (XAD) 01711

FIXME

BPO-13: BP Indication for Use (CWE) 01712

FIXME

BPO-14: BP Informed Consent Indicator (ID) 01713

FIXME

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 Segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
BPX
1 Set ID – BPX SI R
[1..1] 01714 [1..4]
2 BP Dispense Status CWE R
0510(R) Blood Product Dispense Status(Required)
[1..1] 01715
3 BP Status ID R
0511(R) BP Observation Status Codes Interpretation(Required)
[1..1] 01716 [1..1]
4 BP Date/Time of Status DTM R
[1..1] 01717
5 BC Donation ID EI C
[0..1] 01718
6 BC Component CNE C
0577
[0..1] 01719
7 BC Donation Type / Intended Use CNE O
0578
[0..1] 01720
8 CP Commercial Product CWE C
0512 Commercial Product
[0..1] 01721
9 CP Manufacturer XON C
[0..1] 01722
10 CP Lot Number EI C
[0..1] 01723
11 BP Blood Group CNE O
0579
[0..1] 01724
12 BC Special Testing CNE O
0580
[0..*] 01725
13 BP Expiration Date/Time DTM O
[0..1] 01726
14 BP Quantity NM R
[1..1] 01727 5 #
15 BP Amount NM O
[0..1] 01728 5 #
16 BP Units CWE O
0581
[0..1] 01729
17 BP Unique ID EI O
[0..1] 01730
18 BP Actual Dispensed To Location PL O
[0..1] 01731
19 BP Actual Dispensed To Address XAD O
[0..1] 01732
20 BP Dispensed to Receiver XCN O
[0..1] 01733
21 BP Dispensing Individual XCN O
[0..1] 01734
22 Action Code ID O
0206(R) Segment Action Code(Required)
[0..1] 00816 [2..2]

BPX-1: Set ID – BPX (SI) 01714

FIXME

BPX-2: BP Dispense Status (CWE) 01715

FIXME

BPX-3: BP Status (ID) 01716

FIXME

BPX-4: BP Date/Time of Status (DTM) 01717

FIXME

BPX-5: BC Donation ID (EI) 01718

FIXME

BPX-6: BC Component (CNE) 01719

FIXME

BPX-7: BC Donation Type / Intended Use (CNE) 01720

FIXME

BPX-8: CP Commercial Product (CWE) 01721

FIXME

BPX-9: CP Manufacturer (XON) 01722

FIXME

BPX-10: CP Lot Number (EI) 01723

FIXME

BPX-11: BP Blood Group (CNE) 01724

FIXME

BPX-12: BC Special Testing (CNE) 01725

FIXME

BPX-13: BP Expiration Date/Time (DTM) 01726

FIXME

BPX-14: BP Quantity (NM) 01727

FIXME

BPX-15: BP Amount (NM) 01728

FIXME

BPX-16: BP Units (CWE) 01729

FIXME

BPX-17: BP Unique ID (EI) 01730

FIXME

BPX-18: BP Actual Dispensed To Location (PL) 01731

FIXME

BPX-19: BP Actual Dispensed To Address (XAD) 01732

FIXME

BPX-20: BP Dispensed to Receiver (XCN) 01733

FIXME

BPX-21: BP Dispensing Individual (XCN) 01734

FIXME

BPX-22: Action Code (ID) 00816

FIXME

BTX - Blood Product Transfusion/Disposition Segment

HL7 Attribute Table - BTX - Blood Product Transfusion/Disposition Segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
BTX
1 Set ID – BTX SI R
[1..1] 01735 [1..4]
2 BC Donation ID EI C
[0..1] 01736
3 BC Component CNE C
0582
[0..1] 01737
4 BC Blood Group CNE C
0583
[0..1] 01738
5 CP Commercial Product CWE C
0512 Commercial Product
[0..1] 01739
6 CP Manufacturer XON C
[0..1] 01740
7 CP Lot Number EI C
[0..1] 01741
8 BP Quantity NM R
[1..1] 01742 5 #
9 BP Amount NM O
[0..1] 01743 5 #
10 BP Units CWE O
0584
[0..1] 01744
11 BP Transfusion/Disposition Status CWE R
0513(R) Blood Product Transfusion/Disposition Status(Required)
[1..1] 01745
12 BP Message Status ID R
0511(R) BP Observation Status Codes Interpretation(Required)
[1..1] 01746 [1..1]
13 BP Date/Time of Status DTM R
[1..1] 01747
14 BP Transfusion Administrator XCN O
[0..1] 01748
15 BP Transfusion Verifier XCN O
[0..1] 01749
16 BP Transfusion Start Date/Time of Status DTM O
[0..1] 01750
17 BP Transfusion End Date/Time of Status DTM O
[0..1] 01751
18 BP Adverse Reaction Type CWE O
0514 Transfusion Adverse Reaction
[0..*] 01752
19 BP Transfusion Interrupted Reason CWE O
0515 Transfusion Interrupted Reason
[0..1] 01753
20 BP Unique ID EI O
[0..1] 03391
21 Action Code ID O
0206(R) Segment Action Code(Required)
[0..1] 00816 [2..2]

BTX-1: Set ID – BTX (SI) 01735

FIXME

BTX-2: BC Donation ID (EI) 01736

FIXME

BTX-3: BC Component (CNE) 01737

FIXME

BTX-4: BC Blood Group (CNE) 01738

FIXME

BTX-5: CP Commercial Product (CWE) 01739

FIXME

BTX-6: CP Manufacturer (XON) 01740

FIXME

BTX-7: CP Lot Number (EI) 01741

FIXME

BTX-8: BP Quantity (NM) 01742

FIXME

BTX-9: BP Amount (NM) 01743

FIXME

BTX-10: BP Units (CWE) 01744

FIXME

BTX-11: BP Transfusion/Disposition Status (CWE) 01745

FIXME

BTX-12: BP Message Status (ID) 01746

FIXME

BTX-13: BP Date/Time of Status (DTM) 01747

FIXME

BTX-14: BP Transfusion Administrator (XCN) 01748

FIXME

BTX-15: BP Transfusion Verifier (XCN) 01749

FIXME

BTX-16: BP Transfusion Start Date/Time of Status (DTM) 01750

FIXME

BTX-17: BP Transfusion End Date/Time of Status (DTM) 01751

FIXME

BTX-18: BP Adverse Reaction Type (CWE) 01752

FIXME

BTX-19: BP Transfusion Interrupted Reason (CWE) 01753

FIXME

BTX-20: BP Unique ID (EI) 03391

FIXME

BTX-21: Action Code (ID) 00816

FIXME

Transfusion Service (Blood Bank) Transaction Flow Diagram

The following diagram depicts the message flow of the blood product messages.

Donation Service (Blood Bank) Trigger Events and Messages

Usage Notes for Donation Service (Blood Bank)

The Donation Service (BLOOD BANK) uses a different methodology than the similar Transfusion Service (BLOOD BANK) already present in this standard. Each of the segments defined for the Transfusion Service groups together all the 'transfusion' information in one segment, each. The Donation Service was developed breaking out the blood product 'donated' from the donation event itself. This is a more sustainable and interoperable approach. Future changes to the Transfusion Service should uptake this style.

Activity Diagram

The donation service messages facilitate communications between typical system components in a blood bank donation service facility. Frequently different components of blood banking systems (e.g. registration, questionnaire) are bundled together in one system produced by one vendor. However since there is no standard for that bundling, in any particular implementation any of the named system components can be implemented on another system and therefore communications to that component is necessary. The typical components are illustrated in the graphic below.

Additionally, the graphic also depicts a flow of information through those systems during a donation process.

Actors

As mentioned previously, many of the existing systems used in the collection process conduct all these actions in a single bundled system. Extension of the systems on this page is presented in this format because there is no standard for that bundling, in any particular implementation any of the named system components can be implemented on another system and therefore communications to that component is necessary.

Ordering Provider

For Directed and Autologous Donations, this is the Healthcare Provider requesting a blood donation.

Registration System

All donors are registered in this system.

Donor book of record System

This is the source-of-truth for every donor, whether evaluated and deferred, rejected, or not deferred.

Mini-physical System

The mini-physical examination conducted on all potential donors is documented using this system.

Questionnaire System

Each potential donor must fill out a questionnaire which asks about previous medical history and risk factors using this documentation system.

Donation System

The phlebotomists and other healthcare professionals use this system to document the blood donation procedure.

Device Interfaces

Interface to devices used during the mini-physical, donation, and shipping systems.

Provider Master

This system keeps the master list of providers.

Shipping System

This system is used to document the shipping manifest from information received from the actual donations.

DBC - Create Donor Record Message (Event O41 )

The Create Donor Record messages contain information to create a new donor book of record.

DBC^O41^DBC_O41: Create Donor Record Message
HL7 MessageStructure Table - DBC_O41
Segment Cardinality Must Implement Status
DBC_O41
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
DONOR 0..1 additional
PID 1..1 Yes additional
PD1 0..1 additional
PRT 0..* additional
NTE 0..* additional
ARV 0..* B
AL1 0..* additional
DONOR_OBSERVATIONS 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional

Original Mode Acknowledgement Choreography for DBC^O41^DBC_O41

Send Application Ack: ACK^O41^ACK

Enhanced Mode Acknowledgement Choreography for DBC^O41^DBC_O41

When the MSH-15 value of a DBC^O41^DBC_O41 message is AL or ER or SU, an ACK^O41^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of a DBC^O41^DBC_O41 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a DBC^O41^DBC_O41 message is AL or ER or SU, an ACK^O41^ACK message SHALL be sent as an application ack.

When the MSH-16 value of a DBC^O41^DBC_O41 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^O41^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^O41^ACK
NE, AL, ER, SU (none)

DBU - Update Donor Record Message (Event O42)

The Update Donor Record messages contain information to update an existing donor book of record.

DBU^O42^DBC_O42: Update Donor Record Message
HL7 MessageStructure Table - DBC_O42
Segment Cardinality Must Implement Status
DBC_O42
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
DONOR 0..1 additional
PID 1..1 Yes additional
PD1 0..1 additional
PRT 0..* additional
NTE 0..* additional
AL1 0..* additional
ARV 0..* B
DONOR_OBSERVATIONS 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional

Original Mode Acknowledgement Choreography for DBU^O42^DBC_O42

Send Application Ack: ACK^O42^ACK

Enhanced Mode Acknowledgement Choreography for DBU^O42^DBC_O42

When the MSH-15 value of a DBU^O42^DBC_O42 message is AL or ER or SU, an ACK^O42^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of a DBU^O42^DBC_O42 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a DBU^O42^DBC_O42 message is AL or ER or SU, an ACK^O42^ACK message SHALL be sent as an application ack.

When the MSH-16 value of a DBU^O42^DBC_O42 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^O42^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^O42^ACK
NE, AL, ER, SU (none)

QBP - Get Donor Record Candidates (Event Q33)

This query/response is designed for interaction between a registration system and the system which contains the Donor Book of Record. The query consists of query parameters which assist in determining if the Donor already has a record in the Donor Book or Record system. The query parameters are minimal and number of elements returned in the query response for each candidate is minimal.

Query Statement ID:

Q33

Query Type:

Query by Parameter/

Query Name:

Get Donor Record Candidates

Query Trigger:

QBP^Q33^QBP_Q33

Query Mode:

Immediate

Response Trigger:

RSP^K33^RSP_K33

Query Characteristics

Query is used to find if a donor record exists on the Donor Book of Record system. A few, basic, demographic paramters are provided. The return are a set of records which meet the parameter criteria. The intent is to ‘select’ one of the returned candidate records, then run the Get Donor Record query to return the detail for that specific donor.

Purpose:

Returns minimal information for set of donor records


QBP^Q33^QBP_O33: Get Donor Record Candidates Message
HL7 MessageStructure Table - QBP_O33
Segment Cardinality Must Implement Status
QBP_O33
MSH 1..1 Yes additional
SFT 0..* additional
UAC 0..1 additional
QPD 1..1 Yes additional
RCP 1..1 Yes additional

Original Mode Acknowledgement Choreography for QBP^Q33^QBP_O33

Send Application Ack: RSP^K33^RSP_O33

Enhanced Mode Acknowledgement Choreography for QBP^Q33^QBP_O33

When the MSH-15 value of a QBP^Q33^QBP_O33 message is AL or ER or SU, a RSP^K33^RSP_O33 message SHALL be sent as an immediate ack.

When the MSH-15 value of a QBP^Q33^QBP_O33 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a QBP^Q33^QBP_O33 message is AL or ER or SU, a RSP^K33^RSP_O33 message SHALL be sent as an application ack.

When the MSH-16 value of a QBP^Q33^QBP_O33 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: RSP^K33^RSP_O33
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: RSP^K33^RSP_O33
NE, AL, ER, SU (none)

RSP - Get Donor Record Candidates Response (Event K33)

There is not supposed to be an Application Level acknowledgement to an Application Level Acknowledgement message. In Enhanced Mode, MSH-16 SHALL always be set to NE (Never).

RSP^K33^RSP_O33: Get Donor Record Candidates Response Message
HL7 MessageStructure Table - RSP_O33
Segment Cardinality Must Implement Status
RSP_O33
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
MSA 1..1 Yes additional
ERR 0..1 additional
QAK 1..1 Yes additional
QPD 1..1 Yes additional
DONOR 0..1 additional
PID 1..1 Yes additional
PRT 0..* additional
ARV 0..* B

Original Mode Acknowledgement Choreography for RSP^K33^RSP_O33

Send Immediate Ack: ACK^K33^ACK

Enhanced Mode Acknowledgement Choreography for RSP^K33^RSP_O33

When the MSH-15 value of a RSP^K33^RSP_O33 message is AL or ER or SU, an ACK^K33^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of a RSP^K33^RSP_O33 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a RSP^K33^RSP_O33 message is AL or ER or SU, a message SHALL be sent as an application ack.

When the MSH-16 value of a RSP^K33^RSP_O33 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^K33^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack:
NE, AL, ER, SU (none)

QBP - Get Donor Record (Event Q34)

This query/response is designed for interaction between a viewing system and the system which contains the Donor Book of Record. The query consists of query parameters, and the response of the demographics for that donor.

Query Statement ID:

Q34

Query Type:

Query by Parameter

Query Name:

Get Donor Record

Query Trigger:

QBP^Q34^QBP_Q34

Query Mode:

Immediate

Response Trigger:

RSP^K34^RSP_K34

Query Characteristics

Uses donor id to find a specific donor record and return it.

Purpose:

Returns demographic information and donations for a donor


QBP^Q34^QBP_O34: Get Donor Record Message
HL7 MessageStructure Table - QBP_O33
Segment Cardinality Must Implement Status
QBP_O33
MSH 1..1 Yes additional
SFT 0..* additional
UAC 0..1 additional
QPD 1..1 Yes additional
RCP 1..1 Yes additional

Original Mode Acknowledgement Choreography for QBP^Q34^QBP_O34

Send Application Ack: RSP^K34^RSP_O34

Enhanced Mode Acknowledgement Choreography for QBP^Q34^QBP_O34

When the MSH-15 value of a QBP^Q34^QBP_O34 message is AL or ER or SU, a RSP^K34^RSP_O34 message SHALL be sent as an immediate ack.

When the MSH-15 value of a QBP^Q34^QBP_O34 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a QBP^Q34^QBP_O34 message is AL or ER or SU, a RSP^K34^RSP_O34 message SHALL be sent as an application ack.

When the MSH-16 value of a QBP^Q34^QBP_O34 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: RSP^K34^RSP_O34
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: RSP^K34^RSP_O34
NE, AL, ER, SU (none)

RSP - Get Donor Record Response (Event K34)

There is not supposed to be an Application Level acknowledgement to an Application Level Acknowledgement message. In Enhanced Mode, MSH-16 SHALL always be set to NE (Never).

RSP^K34^RSP_O34: Segment Pattern Response Message
HL7 MessageStructure Table - RSP_O34
Segment Cardinality Must Implement Status
RSP_O34
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
MSA 1..1 Yes additional
ERR 0..1 additional
QAK 1..1 Yes additional
QPD 1..1 Yes additional
DONOR 0..1 additional
PID 1..1 Yes additional
PD1 0..1 additional
PRT 0..* additional
NTE 0..* additional
AL1 0..* additional
ARV 0..* B
DONOR_OBSERVATIONS 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
DONOR_REGISTRATION 0..1 additional
PV1 1..1 Yes additional
PRT 0..* additional
NTE 0..* additional
DONATION 0..1 additional
DON 1..1 Yes additional
NTE 0..* additional
DONOR_OBSERVATIONS 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional

Original Mode Acknowledgement Choreography for RSP^K34^RSP_O34

Send Immediate Ack: ACK^K34^ACK

Enhanced Mode Acknowledgement Choreography for RSP^K34^RSP_O34

When the MSH-15 value of a RSP^K34^RSP_O34 message is AL or ER or SU, an ACK^K34^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of a RSP^K34^RSP_O34 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a RSP^K34^RSP_O34 message is AL or ER or SU, a message SHALL be sent as an application ack.

When the MSH-16 value of a RSP^K34^RSP_O34 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^K34^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack:
NE, AL, ER, SU (none)

DRG - Donor Registration (Event O43)

The Donor Registration messages contain information to register a donor for a donation.

DRG^O43^DRG_O43: Donor Registration Message
HL7 MessageStructure Table - DRG_O43
Segment Cardinality Must Implement Status
DRG_O43
MSH 1..1 Yes additional
SFT 0..* additional
UAC 0..1 additional
DONOR 0..1 additional
PID 1..1 Yes additional
PD1 0..1 additional
PRT 0..* additional
NTE 0..* additional
AL1 0..* additional
ARV 0..* B
DONOR_OBSERVATIONS 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
DONOR_REGISTRATION 0..1 additional
PV1 1..1 Yes additional
PRT 0..* additional
NTE 0..* additional

Original Mode Acknowledgement Choreography for DRG^O43^DRG_O43

Send Application Ack: ACK^O43^ACK

Enhanced Mode Acknowledgement Choreography for DRG^O43^DRG_O43

When the MSH-15 value of a DRG^O43^DRG_O43 message is AL or ER or SU, an ACK^O43^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of a DRG^O43^DRG_O43 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a DRG^O43^DRG_O43 message is AL or ER or SU, an ACK^O43^ACK message SHALL be sent as an application ack.

When the MSH-16 value of a DRG^O43^DRG_O43 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^O43^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^O43^ACK
NE, AL, ER, SU (none)

DER - Donor Eligibility Request (Event O44)

The Donor Registration messages contain minimal information about a donor registration.

DER^O44^DER_O44: Donor Registration - Minimal Message
HL7 MessageStructure Table - DER_O44
Segment Cardinality Must Implement Status
DER_O44
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
DONOR 0..1 additional
PID 1..1 Yes additional
PD1 0..1 additional
PRT 0..* additional
NTE 0..* additional
AL1 0..* additional
ARV 0..* B
DONOR_OBSERVATIONS 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
DONOR_REGISTRATION 0..1 additional
PV1 1..1 Yes additional
PRT 0..* additional
NTE 0..* additional
DONOR_ORDER 1..* Yes additional
OBR 1..1 Yes additional
PRT 0..* additional
NTE 0..* additional

Original Mode Acknowledgement Choreography for DER^O44^DER_O44

Send Application Ack: ACK^O44^ACK

Enhanced Mode Acknowledgement Choreography for DER^O44^DER_O44

When the MSH-15 value of a DER^O44^DER_O44 message is AL or ER or SU, an ACK^O44^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of a DER^O44^DER_O44 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a DER^O44^DER_O44 message is AL or ER or SU, an ACK^O44^ACK message SHALL be sent as an application ack.

When the MSH-16 value of a DER^O44^DER_O44 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^O44^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^O44^ACK
NE, AL, ER, SU (none)

DEO - Donor Eligibility Observations (Event O45)

Communicate both mini-physical observations and questions and answers from a donor questionnaire.

DEO^O45^DEO_O45: Donor Eligibility Observations Message
HL7 MessageStructure Table - DEO_O45
Segment Cardinality Must Implement Status
DEO_O45
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
Donor 0..1 additional
PID 1..1 Yes additional
PRT 0..* additional
ARV 0..* B
NTE 0..* additional
DONOR_OBSERVATIONS 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
DONOR_REGISTRATION 0..1 additional
PV1 1..1 Yes additional
PRT 0..* additional
NTE 0..* additional
DONATION_ORDER 1..* Yes additional
OBR 1..1 Yes additional
PRT 0..* additional
NTE 0..* additional
DONATION_OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
NTE 0..* additional

Original Mode Acknowledgement Choreography for DEO^O45^DEO_O45

Send Application Ack: ACK^O45^ACK

Enhanced Mode Acknowledgement Choreography for DEO^O45^DEO_O45

When the MSH-15 value of a DEO^O45^DEO_O45 message is AL or ER or SU, an ACK^O45^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of a DEO^O45^DEO_O45 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a DEO^O45^DEO_O45 message is AL or ER or SU, an ACK^O45^ACK message SHALL be sent as an application ack.

When the MSH-16 value of a DEO^O45^DEO_O45 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^O45^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^O45^ACK
NE, AL, ER, SU (none)

DEL - Donor Eligibility (Event O46)

Use this message to communicate a donor’s eligibility to donate.

DEL^O46^DEL_O46: Donor Eligibility Message
HL7 MessageStructure Table - DEL_O46
Segment Cardinality Must Implement Status
DEL_O46
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
DONOR 0..1 additional
PID 1..1 Yes additional
PD1 0..1 additional
PRT 0..* additional
NTE 0..* additional
AL1 0..* additional
ARV 0..* B
DONOR_OBSERVATIONS 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
DONOR_REGISTRATION 0..1 additional
PV1 1..1 Yes additional
PRT 0..* additional
NTE 0..* additional
DON 1..1 Yes additional
NTE 0..* additional

Original Mode Acknowledgement Choreography for DEL^O46^DEL_O46

Send Application Ack: ACK^O46^ACK

Enhanced Mode Acknowledgement Choreography for DEL^O46^DEL_O46

When the MSH-15 value of a DEL^O46^DEL_O46 message is AL or ER or SU, an ACK^O46^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of a DEL^O46^DEL_O46 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a DEL^O46^DEL_O46 message is AL or ER or SU, an ACK^O46^ACK message SHALL be sent as an application ack.

When the MSH-16 value of a DEL^O46^DEL_O46 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^O46^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^O46^ACK
NE, AL, ER, SU (none)

DRC - Donor Request to Collect (Event O47)

Used to communicate to a collection system that the donor is eligible and collection can begin.

DRC^O47^DRC_O47: Donor Request to Collect Message
HL7 MessageStructure Table - DER_O44
Segment Cardinality Must Implement Status
DER_O44
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
DONOR 0..1 additional
PID 1..1 Yes additional
PD1 0..1 additional
PRT 0..* additional
NTE 0..* additional
AL1 0..* additional
ARV 0..* B
DONOR_OBSERVATIONS 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
DONOR_REGISTRATION 0..1 additional
PV1 1..1 Yes additional
PRT 0..* additional
NTE 0..* additional
DONOR_ORDER 1..* Yes additional
OBR 1..1 Yes additional
PRT 0..* additional
NTE 0..* additional

Original Mode Acknowledgement Choreography for DRC^O47^DRC_O47

Send Application Ack: ACK^O47^ACK

Enhanced Mode Acknowledgement Choreography for DRC^O47^DRC_O47

When the MSH-15 value of a DRC^O47^DRC_O47 message is AL or ER or SU, an ACK^O47^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of a DRC^O47^DRC_O47 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a DRC^O47^DRC_O47 message is AL or ER or SU, an ACK^O47^ACK message SHALL be sent as an application ack.

When the MSH-16 value of a DRC^O47^DRC_O47 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^O47^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^O47^ACK
NE, AL, ER, SU (none)

DPR - Donation Procedure (Event O48)

This message contains information from the blood unit collection procedure from the donor.

DPR^O48^DPR_O48: Donation Procedure Message
HL7 MessageStructure Table - DPR_O48
Segment Cardinality Must Implement Status
DPR_O48
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
DONOR 0..1 additional
PID 1..1 Yes additional
PD1 0..1 additional
PRT 0..* additional
NTE 0..* additional
AL1 0..* additional
ARV 0..* B
DONOR_OBSERVATIONS 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
DONOR_REGISTRATION 0..1 additional
PV1 1..1 Yes additional
PRT 0..* additional
NTE 0..* additional
DONATION_ORDER 1..* Yes additional
OBR 1..1 Yes additional
PRT 0..* additional
NTE 0..* additional
DONATION 0..1 additional
DON 1..1 Yes additional
NTE 0..* additional
DONATION_OBSERVATIONS 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
BLOOD_UNIT 0..1 additional
BUI 0..* additional
NTE 0..* additional

Original Mode Acknowledgement Choreography for DPR^O48^DPR_O48

Send Application Ack: ACK^O48^ACK

Enhanced Mode Acknowledgement Choreography for DPR^O48^DPR_O48

When the MSH-15 value of a DPR^O48^DPR_O48 message is AL or ER or SU, an ACK^O48^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of a DPR^O48^DPR_O48 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a DPR^O48^DPR_O48 message is AL or ER or SU, an ACK^O48^ACK message SHALL be sent as an application ack.

When the MSH-16 value of a DPR^O48^DPR_O48 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^O48^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^O48^ACK
NE, AL, ER, SU (none)

Donation Service (Blood Bank) Segments

DON - Donation Segment

The intent of this segment is to describe the actual donation procedure.

HL7 Attribute Table - DON - Donation Segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
DON
1 Donation Identification Number - DIN EI C
[0..1] 03340
2 Donation Type CNE C
[0..1] 03341
3 Phlebotomy Start Date/Time DTM R
[1..1] 03342
4 Phlebotomy End Date/Time DTM R
[1..1] 03343
5 Donation Duration NM R
[1..1] 03344
6 Donation Duration Units CNE R
0932 Donation Duration Units
[1..1] 03345
7 Intended Procedure Type CNE R
0933(R) Intended Procedure Type(Required)
[1..*] 03346
8 Actual Procedure Type CNE R
0933(R) Intended Procedure Type(Required)
[1..*] 03347
9 Donor Eligibility Flag ID R
0136(R) Yes/no Indicator(Required)
[1..1] 03348
10 Donor Eligibility Procedure Type CNE R
0933(R) Intended Procedure Type(Required)
[1..*] 03349
11 Donor Eligibility Date DTM R
[1..1] 03350
12 Process Interruption CNE R
0923 Process Interruption
[1..1] 03351
13 Process Interruption Reason CNE R
0935 Process Interruption Reason
[1..1] 03352
14 Phlebotomy Issue CNE R
0925(R) Phlebotomy Issue(Required)
[1..*] 03353
15 Intended Recipient Blood Relative ID R
0136(R) Yes/no Indicator(Required)
[1..1] 03354
16 Intended Recipient Name XPN R
[1..1] 03355
17 Intended Recipient DOB DTM R
[1..1] 03356
18 Intended Recipient Facility XON R
[1..1] 03357
19 Intended Recipient Procedure Date DTM R
[1..1] 03358
20 Intended Recipient Ordering Provider XPN R
[1..1] 03359
21 Phlebotomy Status CNE R
0926(R) Phlebotomy Status(Required)
[1..1] 03360
22 Arm Stick CNE R
0927(R) Arm Stick(Required)
[1..1] 03361
23 Bleed Start Phlebotomist XPN R
[1..1] 03362
24 Bleed End Phlebotomist XPN R
[1..1] 03363
25 Aphaeresis Type Machine ST R
[1..1] 03364 75 #
26 Aphaeresis Machine Serial Number ST R
[1..1] 03365 25 #
27 Donor Reaction ID R
0136(R) Yes/no Indicator(Required)
[1..1] 03366
28 Final Review Staff ID XPN R
[1..1] 03367
29 Final Review Date/Time DTM R
[1..1] 03368
30 Number of Tubes Collected NM R
[1..1] 03369
31 Donation Sample Identifier EI R
[1..*] 03370
32 Donation Accept Staff XCN R
[1..1] 03371
33 Donation Material Review Staff XCN R
[1..*] 03372
34 Action Code ID O
0206(R) Segment Action Code(Required)
[0..1] 00816 [2..2]

DON-1: Donation Identification Number - DIN (EI) 03340

FIXME

DON-2: Donation Type (CNE) 03341

FIXME

DON-3: Phlebotomy Start Date/Time (DTM) 03342

FIXME

DON-4: Phlebotomy End Date/Time (DTM) 03343

FIXME

DON-5: Donation Duration (NM) 03344

FIXME

DON-6: Donation Duration Units (CNE) 03345

FIXME

DON-7: Intended Procedure Type (CNE) 03346

FIXME

DON-8: Actual Procedure Type (CNE) 03347

FIXME

DON-9: Donor Eligibility Flag (ID) 03348

FIXME

DON-10: Donor Eligibility Procedure Type (CNE) 03349

FIXME

DON-11: Donor Eligibility Date (DTM) 03350

FIXME

DON-12: Process Interruption (CNE) 03351

FIXME

DON-13: Process Interruption Reason (CNE) 03352

FIXME

DON-14: Phlebotomy Issue (CNE) 03353

FIXME

DON-15: Intended Recipient Blood Relative (ID) 03354

FIXME

DON-16: Intended Recipient Name (XPN) 03355

FIXME

DON-17: Intended Recipient DOB (DTM) 03356

FIXME

DON-18: Intended Recipient Facility (XON) 03357

FIXME

DON-19: Intended Recipient Procedure Date (DTM) 03358

FIXME

DON-20: Intended Recipient Ordering Provider (XPN) 03359

FIXME

DON-21: Phlebotomy Status (CNE) 03360

FIXME

DON-22: Arm Stick (CNE) 03361

FIXME

DON-23: Bleed Start Phlebotomist (XPN) 03362

FIXME

DON-24: Bleed End Phlebotomist (XPN) 03363

FIXME

DON-25: Aphaeresis Type Machine (ST) 03364

FIXME

DON-26: Aphaeresis Machine Serial Number (ST) 03365

FIXME

DON-27: Donor Reaction (ID) 03366

FIXME

DON-28: Final Review Staff ID (XPN) 03367

FIXME

DON-29: Final Review Date/Time (DTM) 03368

FIXME

DON-30: Number of Tubes Collected (NM) 03369

FIXME

DON-31: Donation Sample Identifier (EI) 03370

FIXME

DON-32: Donation Accept Staff (XCN) 03371

FIXME

DON-33: Donation Material Review Staff (XCN) 03372

FIXME

DON-34: Action Code (ID) 00816

FIXME

BUI - Blood Unit Information Segment

The intent of this segment is to describe the information associated with a blood unit, one example of which is one or more blood unit(s) resulting from a donation.

HL7 Attribute Table - BUI - Blood Unit information Segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
BUI
1 Set ID – BUI SI O
[0..1] 03373 [1..4]
2 Blood Unit Identifier EI R
[1..1] 03374
3 Blood Unit Type CWE R
0566(R) Blood Unit Type(Required)
[1..1] 03375
4 Blood Unit Weight NM R
[1..1] 03376
5 Weight Units CNE R
0929(R) Weight Units(Required)
[1..1] 03377
6 Blood Unit Volume NM R
[1..1] 03378
7 Volume Units CNE R
0930(R) Volume Units(Required)
[1..1] 03379
8 Container Catalog Number ST R
[1..1] 03380
9 Container Lot Number ST R
[1..1] 03381
10 Container Manufacturer XON R
[1..1] 03382
11 Transport Temperature NR R
[1..1] 03383
12 Transport Temperature Units CNE R
0931(R) Temperature Units(Required)
[1..*] 03384
13 Action Code ID O
0206(R) Segment Action Code(Required)
[0..1] 00816 [2..2]

BUI-1: Set ID – BUI (SI) 03373

FIXME

BUI-2: Blood Unit Identifier (EI) 03374

FIXME

BUI-3: Blood Unit Type (CWE) 03375

FIXME

BUI-4: Blood Unit Weight (NM) 03376

FIXME

BUI-5: Weight Units (CNE) 03377

FIXME

BUI-6: Blood Unit Volume (NM) 03378

FIXME

BUI-7: Volume Units (CNE) 03379

FIXME

BUI-8: Container Catalog Number (ST) 03380

FIXME

BUI-9: Container Lot Number (ST) 03381

FIXME

BUI-10: Container Manufacturer (XON) 03382

FIXME

BUI-11: Transport Temperature (NR) 03383

FIXME

BUI-12: Transport Temperature Units (CNE) 03384

FIXME

BUI-13: Action Code (ID) 00816

FIXME

TABLES LISTINGS

Figure 4-8 Associations between Order Control Codes and Trigger Events

Figure 4-8 defines the explicit relationships that exist between Order Control Codes and Trigger Events. A value of "Y" at the intersection of an Order Control Code and a Trigger Event indicates that is a valid combination that can be used in a message. A value of "N" indicates that combination is not valid in any message. No value at an intersection indicates that no business case has been brought forward for to justify or exclude that combination. Implementers are encouraged to bring business cases forward for currently undefined combinations of Order Control Codes and Trigger Events.

Figure 4-8 Order Control Codes / Trigger Event Matrix

O01

O02

O03

O04

O05

O06

O07

O08

O09

O10

O11

O12

O13

O14

O15

O16

O18

O19

O20

O21

P03

P11

Q06

R01

AF

Y

Y

CA

Y

Y

Y

Y

Y

Y

Y

CH

Y

Y

Y

Y

Y

Y

Y

CN

Y

CR

Y

Y

Y

Y

Y

Y

DC

Y

Y

Y

Y

Y

Y

Y

DE

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

DF

Y

Y

Y

DR

Y

Y

Y

Y

Y

Y

FU

Y

Y

HD

Y

Y

Y

Y

Y

HR

Y

Y

Y

Y

Y

Y

LI

Y

Y

Y

Y

Y

Y

Y

MC

Y

Y

NA

Y

Y

Y

Y

Y

NW

Y

Y

Y

Y

Y

Y

Y

OC

Y

Y

Y

Y

Y

Y

Y

Y

OD

Y

Y

Y

Y

Y

Y

Y

Y

OE

Y

Y

Y

Y

Y

Y

Y

Y

OF

Y

Y

OH

Y

Y

Y

Y

Y

Y

Y

Y

OK

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

OP

Y

OR

Y

Y

Y

Y

Y

Y

PA

Y

Y

Y

Y

Y

Y

Y

Y

PR

Y

Y

Y

PY

Y

RE

Y

Y

Y

Y

Y

Y

Y

RF

Y

Y

Y

RL

Y

Y

Y

Y

Y

Y

Y

RO

Y

Y

Y

Y

Y

Y

Y

RP

Y

Y

Y

Y

Y

Y

RQ

Y

Y

Y

Y

Y

RR

Y

RU

Y

Y

Y

Y

Y

Y

SC

Y

Y

Y

SN

Y

Y

Y

Y

Y

SR

Y

Y

SS

Y

Y

Y

UA

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

UC

Y

Y

Y

Y

Y

Y

UD

Y

Y

Y

Y

Y

Y

UF

Y

Y

UH

Y

Y

Y

Y

Y

Y

UM

Y

Y

Y

Y

Y

UN

Y

Y

Y

Y

Y

Y

Y

Y

UR

Y

Y

Y

Y

Y

Y

UX

Y

Y

Y

Y

Y

Y

XO

Y

Y

Y

Y

Y

Y

Y

XR

Y

Y

Y

Y

Y

Y

XX

Y

Y

Y

Y

Y

Y

Y

Y



Editor’s note: The order control codes need to be assessed for their application to these trigger events O22 through O48. The current table structure will not accommodate these additional columns; a new table structure needs to be considered.



OUTSTANDING ISSUES

                          • In approving the transfusion service messages and related segments for their initial inclusion in version 2.5, it was noted that the messages do not support information relative to DNA and/or RNA extracts of blood and/or blood products. Future consideration of this is dependent upon the development of related use cases to define requirements.