18.18.5 Order Entry: General, Laboratory, Dietary, Supply, Blood Transfusion (99.1.3)

18.19 Chapter 4 Contents (4.1)

18.20 Purpose (4.2)

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.

18.20.1 Preface (organization of this chapter) (4.2.1)

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

18.20.2 Glossary (4.2.2)

18.20.2.1 hiddentext (4.2.2.0)

18.20.2.2 Filler: (4.2.2.1)

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

18.20.2.3 Observation segment: (4.2.2.2)

An OBX segment defined in Chapter 7.

18.20.2.4 Order: (4.2.2.3)

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.

18.20.2.5 Order detail segment: (4.2.2.4)

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.

18.20.2.6 Placer: (4.2.2.5)

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

18.20.2.7 Placer order group: (4.2.2.6)

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

18.20.2.8 Order Number: (4.2.2.7)

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)

18.21 Quantity/Timing (TQ) Data Type Definition (4.3)

18.22 General Trigger Events & Message Definitions (4.4)

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

18.22.1 ORM - general order message (4.4.1)

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.

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

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.

18.22.3 OSQ/OSR- query response for order (4.4.3)

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

18.22.4 OMG - general clinical order message (event O19) (4.4.4)

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

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

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

18.22.6 OML - laboratory order message (event O21) (4.4.6)

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

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

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

18.22.7.1 Patient Segments Required (4.4.7.0)

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

18.22.7.2 Patient Segments Optional (4.4.7.1)

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

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

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

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

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

18.22.9.1 Patient Segments Required (4.4.9.0)

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

18.22.9.2 Patient Segments Optional (4.4.9.1)

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

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

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

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

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

18.22.11.1 Patient Segments Required (4.4.11.0)

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

18.22.11.2 Patient Segments Optional (4.4.11.1)

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

18.22.12 OML - Specimen shipment centric laboratory order (event O39) (4.4.12)

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

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

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

18.22.13.1 Patient Segments Required (4.4.13.0)

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

18.22.13.2 Patient Segments Optional (4.4.13.1)

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

18.22.14 OMI - Imaging Order Message (Event O23) (4.4.14)

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.

Figure 4-1 - Use of OMI message

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

18.22.15 ORI - Imaging Order Response Message to Any OMI (Event O24) (4.4.15)

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

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

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.

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

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

18.22.18 Order Status Update (Event O51) (4.4.18)

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.

18.22.19 OSU - Order Status Update Acknowledgement (Event O52) (4.4.19)

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

18.22.20 OMQ - General Order Message with Document Payload (Event O57) (4.4.20)

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

18.22.21 ORX - General Order Message with Document Payload Acknowledgement Message (Event O58) (4.4.21)

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

18.22.22 OML - Laboratory Result Interpretation Request Message (Event O59) (4.4.22)

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.

18.23 Diet Trigger Events & Message Definitions (4.7)

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.

18.23.1 OMD - Dietary Order (Event O03) (4.7.1)

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.

18.23.2 ORD - dietary order acknowledgment (Event O04) (4.7.2)

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

18.24 Supply Trigger Events & Messages (4.10)

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.

18.24.1 OMS - stock requisition order message (event O05) (4.10.1)

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.

18.24.2 ORS - stock requisition order acknowledgment message (event O06) (4.10.2)

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

18.24.3 OMN - non-stock requisition order message (event O07) (4.10.3)

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.

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

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

18.25 Transfusion Service (Blood Bank) Trigger Events & Messages (4.13)

18.25.1 Usage notes for transfusion service messages (4.13.1)

18.25.2 OMB - Blood Product Order Message (Event O27) (4.13.2)

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.

18.25.2.1 OMB use notes (4.13.2.0)

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.

18.25.3 ORB - Blood Product Order Acknowledgment (Event O28) (4.13.3)

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

18.25.4 BPS - Blood Product Dispense Status Message (Event O29) (4.13.4)

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.

18.25.5 BRP - Blood Product Dispense Status Acknowledgment (Event O30) (4.13.5)

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

18.25.6 BTS - Blood Product Transfusion/Disposition Message (Event O31) (4.13.6)

Blood product transfusion/disposition messages use the BTS and BRT messages as described below.

18.25.7 BRT - Blood Product Transfusion/Disposition Acknowledgment (Event O32) (4.13.7)

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

18.26 Transfusion Service (Blood Bank) Transaction Flow Diagram (4.15)

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

18.27 Donation Service (Blood Bank) Trigger Events and Messages (4.16)

18.27.1 Usage Notes for Donation Service (Blood Bank) (4.16.1)

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.

18.27.2 Activity Diagram (4.16.2)

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.

18.27.3 Actors (4.16.3)

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.

18.27.3.1 Ordering Provider (4.16.3.0)

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

18.27.3.2 Registration System (4.16.3.1)

All donors are registered in this system.

18.27.3.3 Donor book of record System (4.16.3.2)

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

18.27.3.4 Mini-physical System (4.16.3.3)

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

18.27.3.5 Questionnaire System (4.16.3.4)

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

18.27.3.6 Donation System (4.16.3.5)

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

18.27.3.7 Device Interfaces (4.16.3.6)

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

18.27.3.8 Provider Master (4.16.3.7)

This system keeps the master list of providers.

18.27.3.9 Shipping System (4.16.3.8)

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

18.27.4 DBC - Create Donor Record Message (Event O41 ) (4.16.4)

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

18.27.5 DBU - Update Donor Record Message (Event O42) (4.16.5)

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

18.27.6 QBP - Get Donor Record Candidates (Event Q33) (4.16.6)

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.

18.27.7 RSP - Get Donor Record Candidates Response (K33) (4.16.7)

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

18.27.8 QBP - Get Donor Record (Event Q34) (4.16.8)

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.

18.27.9 RSP - Get Donor Record Response (K34) (4.16.9)

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

18.27.10 DRG - Donor Registration (Event O43) (4.16.10)

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

18.27.11 DER - Donor Eligibility Request (Event O44) (4.16.11)

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

18.27.12 DEO - Donor Eligibility Observations (Event O45) (4.16.12)

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

18.27.13 DEL - Donor Eligibility (Event O46) (4.16.13)

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

18.27.14 DRC - Donor Request to Collect (Event O47) (4.16.14)

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

18.27.15 DPR - Donation Procedure (Event O48) (4.16.15)

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

18.28 Tables Listings (4.18)

18.28.1 Figure 4-8 Associations between Order Control Codes and Trigger Events (4.18.1)

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

18.29 Outstanding Issues (4.19)

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.