Co-Chair: |
Hans Buitendijk |
Co-Chair: |
David Burgess |
Co-Chair: |
Lorraine Constable |
Co-Chair: |
Robert Hausam MD |
Co-Chair: |
Patrick Loyd |
Co-Chair: |
Ken McCaslin |
Chapter Co-Chair: |
Riki Merrick |
Co-Chair: |
J.D. Nolen |
Editor |
Hans Buitendijk |
Sponsoring Committee: |
Orders & Observations |
List Server: |
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.
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.
The application responding to, i.e., performing, a request for services (orders) or producing an observation. The filler can also originate requests for services (new orders), add additional services to existing orders, replace existing orders, put an order on hold, discontinue an order, release a held order, or cancel existing orders
An OBX segment defined in Chapter 7.
A request for a service from one application to a second application. The second application may in some cases be the same, i.e., an application is allowed to place orders with itself. 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.
One of several segments that can carry order information. Examples are OBR and RXO. Future ancillary-specific segments may be defined in subsequent releases of the Standard if they become necessary.
The application or individual originating a request for services (order).
A list of associated orders coming from a single location regarding a single patient.
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:
Order Number |
Group Number |
Parent |
|
Parent Order |
111 |
||
Bag One |
123 |
1 |
111 |
Bag Two |
234 |
1 |
111 |
Bag Three |
345 |
1 |
111 |
Order Number |
Group Number |
|
Med One |
123 |
99 (script number) |
Med Two |
456 |
99 (script number) |
Order Number |
Group Number |
|
CBC |
987 |
88 (requisition number) |
Glucose |
654 |
88 (requisition number) |
Electrolytes |
321 |
88 (requisition number) |
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.
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."
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.
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.
Attention: Retained for backwards compatibility only as of v2.4.and withdrawn as of v2.7. Refer to Chapter 5.
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).
Send Application Ack: ORG^O20^ORG_O20
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, 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, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^O19^ACK |
NE | (none) | |
MSH-16 | AL, ER, SU | application ack: ORG^O20^ORG_O20 or OSU^O52^OSU_O52 |
NE | (none) |
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.)
Send Immediate Ack: ACK^O20^ACK
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, an immediate ack SHALL NOT be sent.
Never send an application ack in enhanced mode.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^O20^ACK |
NE | (none) | |
MSH-16 | NE | (none) |
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).
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).
Send Application Ack: ORL^O22^ORL_O22
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, 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, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^O21^ACK |
NE | (none) | |
MSH-16 | AL, ER, SU | application ack: ORL^O22^ORL_O22 or ORL^O53^ORL_O53 or OSU^O52^OSU_O52 |
NE | (none) |
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
Send Immediate Ack: ACK^O22^ACK
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, an immediate ack SHALL NOT be sent.
Never send an application ack in enhanced mode.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^O22^ACK |
NE | (none) | |
MSH-16 | NE | (none) |
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).
Send Immediate Ack: ACK^O53^ACK
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, an immediate ack SHALL NOT be sent.
Never send an application ack in enhanced mode.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^O53^ACK |
NE | (none) | |
MSH-16 | NE | (none) |
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).
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).
Send Application Ack: ORL^O34^ORL_O34
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, 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, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^O33^ACK |
NE | (none) | |
MSH-16 | AL, ER, SU | application ack: ORL^O34^ORL_O34 or ORL^O54^ORL_O54 or OSU^O52^OSU_O52 |
NE | (none) |
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
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).
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).
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).
Send Application Ack: ORL^O36^ORL_O36
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, 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, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^O35^ACK |
NE | (none) | |
MSH-16 | AL, ER, SU | application ack: ORL^O36^ORL_O36 or ORL^O55^ORL_O55 or OSU^O52^OSU_O52 |
NE | (none) |
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
Send Immediate Ack: ACK^O36^ACK
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, an immediate ack SHALL NOT be sent.
Never send an application ack in enhanced mode.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^O36^ACK |
NE | (none) | |
MSH-16 | NE | (none) |
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).
Send Immediate Ack: ACK^O55^ACK
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, an immediate ack SHALL NOT be sent.
Never send an application ack in enhanced mode.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^O55^ACK |
NE | (none) | |
MSH-16 | NE | (none) |
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).
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).
Send Application Ack: ORL^O40^ORL_O40
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, 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, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^O39^ACK |
NE | (none) | |
MSH-16 | AL, ER, SU | application ack: ORL^O40^ORL_O40 or ORL^O56^ORL_O56 or OSU^O52^OSU_O52 |
NE | (none) |
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
Send Immediate Ack: ACK^O40^ACK
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, an immediate ack SHALL NOT be sent.
Never send an application ack in enhanced mode.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^O40^ACK |
NE | (none) | |
MSH-16 | NE | (none) |
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).
Send Immediate Ack: ACK^O56^ACK
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, an immediate ack SHALL NOT be sent.
Never send an application ack in enhanced mode.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^O56^ACK |
NE | (none) | |
MSH-16 | NE | (none) |
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).
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).
Send Application Ack: ORI^O24^ORI_O24
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, 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, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^O23^ACK |
NE | (none) | |
MSH-16 | AL, ER, SU | application ack: ORI^O24^ORI_O24 or OSU^O52^OSU_O52 |
NE | (none) |
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.
Send Immediate Ack: ACK^O24^ACK
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, an immediate ack SHALL NOT be sent.
Never send an application ack in enhanced mode.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^O24^ACK |
NE | (none) | |
MSH-16 | NE | (none) |
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).
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"."
Send Application Ack: OPR^O38^OPR_O38
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, 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, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^O37^ACK |
NE | (none) | |
MSH-16 | AL, ER, SU | application ack: OPR^O38^OPR_O38 or OSU^O52^OSU_O52 |
NE | (none) |
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.
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.
Send Immediate Ack: ACK^O38^ACK
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, an immediate ack SHALL NOT be sent.
Never send an application ack in enhanced mode.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^O38^ACK |
NE | (none) | |
MSH-16 | NE | (none) |
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).
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.
Send Application Ack: OSU^O52^OSU_O52
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, 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, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^O51^ACK |
NE | (none) | |
MSH-16 | AL, ER, SU | application ack: OSU^O52^OSU_O52 |
NE | (none) |
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.
Send Immediate Ack: ACK^O52^ACK
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, an immediate ack SHALL NOT be sent.
Never send an application ack in enhanced mode.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^O52^ACK |
NE | (none) | |
MSH-16 | NE | (none) |
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).
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".
Send Application Ack: ORX^O58^ORX_O58
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, 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, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^O57^ACK |
NE | (none) | |
MSH-16 | AL, ER, SU | application ack: ORX^O58^ORX_O58 or OSU^O52^OSU_O52 |
NE | (none) |
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.)
Send Immediate Ack: ACK^O58^ACK
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, an immediate ack SHALL NOT be sent.
Never send an application ack in enhanced mode.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^O58^ACK |
NE | (none) | |
MSH-16 | NE | (none) |
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.
Send Application Ack: ORL^O22^ORL_O22
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, 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, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^O59^ACK |
NE | (none) | |
MSH-16 | AL, ER, SU | application ack: ORL^O22^ORL_O22 or ORL^O53^ORL_O53 or OSU^O52^OSU_O52 |
NE | (none) |
The following segments (ORC and BLG) are common to many order messages.
The Common Order segment (ORC) is used to transmit fields that are common to all orders (all types of services that are requested).
There is some overlap between fields of the ORC and those in the order detail segments. These are described in the succeeding sections.
Seq# | DataElement | Description | Must Implement | Flags | Cardinality | Length | C.LEN | Vocabulary | DataType |
---|---|---|---|---|---|---|---|---|---|
ORC | |||||||||
1 | 00215 | Order Control | SHALL | [1..1] | [2..2] | ID | |||
2
|
00216 | Placer Order Number |
MAY
True: False: |
C |
[1..1] [0..1] |
EI | |||
3
|
00217 | Filler Order Number |
MAY
True: False: |
C |
[1..1] [0..1] |
EI | |||
4 | 00218 | Placer Order Group Number | [0..1] | EI | |||||
5 | 00219 | Order Status | [0..1] | [1..2] | ID | ||||
6 | 00220 | Response Flag | [0..1] | [1..1] | ID | ||||
7 | 00221 | Quantity/Timing | SHALL NOT | W | [0..0] | ||||
8 | 00222 | Parent Order | [0..*] | EIP | |||||
9 | 00223 | Date/Time of Order Event | [0..1] | DTM | |||||
10 | 00224 | Entered By | SHALL NOT | W | [0..0] | XCN | |||
11 | 00225 | Verified By | SHALL NOT | W | [0..0] | ||||
12 | 00226 | Ordering Provider | SHALL NOT | W | [0..0] | ||||
13 | 00227 | Enterer's Location | [0..1] | PL | |||||
14 | 00228 | Call Back Phone Number | [0..2] | XTN | |||||
15 | 00229 | Order Effective Date/Time | [0..1] | DTM | |||||
16 | 00230 | Order Control Code Reason | [0..1] | CWE | |||||
17 | 00231 | Entering Organization | SHALL NOT | W | [0..0] | ||||
18 | 00232 | Entering Device | SHALL NOT | W | [0..0] | ||||
19 | 00233 | Action By | SHALL NOT | W | [0..0] | ||||
20 | 01310 | Advanced Beneficiary Notice Code | [0..1] | CWE | |||||
21 | 01311 | Ordering Facility Name | SHALL NOT | W | [0..0] | ||||
22 | 01312 | Ordering Facility Address | SHALL NOT | W | [0..0] | ||||
23 | 01313 | Ordering Facility Phone Number | SHALL NOT | W | [0..0] | ||||
24 | 01314 | Ordering Provider Address | SHALL NOT | W | [0..0] | ||||
25 | 01473 | Order Status Modifier | [0..1] | CWE | |||||
26
|
01641 | Advanced Beneficiary Notice Override Reason |
MAY
True: False: |
C |
[1..1] [0..1] |
CWE | |||
27 | 01642 | Filler's Expected Availability Date/Time | [0..1] | DTM | |||||
28 | 00615 | Confidentiality Code | [0..1] | CWE | |||||
29 | 01643 | Order Type | [0..1] | CWE | |||||
30 | 01644 | Enterer Authorization Mode | [0..1] | CNE | |||||
31 | 02287 | Parent Universal Service Identifier | SHALL NOT | W | [0..0] | ||||
32 | 02301 | Advanced Beneficiary Notice Date | [0..1] | DT | |||||
33 | 03300 | Alternate Placer Order Number | [0..*] | CX | |||||
34 | 03387 | Order Workflow Profile | [0..*] | CWE | |||||
35 | 00816 | Action Code | [0..1] | [2..2] | ID | ||||
36 | 03509 | Order Status Date Range | [0..1] | DR | |||||
37 | 03515 | Order Creation Date/Time | [0..1] | DTM | |||||
38 | 02482 | Filler Order Group Number | [0..1] | EI |
ORC use notes
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.
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.
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:
An EKG application receives an order for three EKGs on successive mornings.
The EKG application creates three child orders, one for each requested EKG..
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.)
The remaining, unperformed, children are canceled as a result of the request.
Date/Time Use Notes:
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.
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..
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.
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.
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.)
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.
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.)
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.)
Definition: Determines the function of the order segment. Refer to HL7 Table 0119 – Order Control Codes in Chapter 2C, Code Tables, for valid entries. Depending on the message, the action of the control code may refer to an order or an individual service. For example, the code CA in an OMP message cancels the order. The same code in an RDS message, cancels the dispense. Very detailed explanatory notes are given at the end of this section.
This field may be considered the "trigger event" identifier for orders. The codes fall roughly into the following three categories:
event request – Codes like "NW" (new order) and "CA" (cancel order request) are used to initiate an event .
event acknowledgment – Codes like "OK" (order accepted) and "CR" (canceled as requested) are used to reply to the event request .
event notification – Codes like "OC" (order canceled) and "OD" (order discontinued) are used to notify other applications that an event has occurred. No application reply is necessary.
Event request codes are intended to initiate an event. Event acknowledgment codes are intended to reply to an application that requested an event. Event notification codes are intended to notify another application that, e.g., the filler has performed some action on an order that the other application, e.g., the placer, needs to know.
Fillers, placers, and other applications can use event requests, event acknowledgments, and event – notification-type trigger events interchangeably. However, certain order control codes can originate only from the filler (e.g., CR) and others can only originate from the placer (e.g., CA).
Refer HL7 Table 0119 – Order Control Codes in Chapter 2C, Code Tables.
(Definition from ORC.2 in Ch. 4)
Definition: This field is the placer application's order number.
This field is a case of the Entity Identifier data type (See Section 2.A.28, "EI – Entity Identifier"). The first component is a string that identifies an individual order (i.e., ORC segment and associated order detail segment). It is assigned by the placer (ordering application). It identifies an order uniquely among all orders from a particular ordering application. The second through fourth components contain the application ID of the placing application in the same form as the HD data type (Section 2.A.36, "HD – Hierarchic designator"). The second component, namespace ID, is a user-defined coded value that will be uniquely associated with an application. A limit of six (6) characters is suggested but not required. A given institution or group of intercommunicating institutions should establish a unique list of applications that may be potential placers and fillers and assign unique application IDs. The components are separated by component delimiters.
There are three situations in which the true placer is somewhat arbitrary (and thus not unique):
in ORC-1-order control value of RO, following an RU replacement;
in ORC-1-order control value of CH (child orders); and
in ORC-1-order control value of SN (send number).
See the Table Notes under ORC-1-order control for the details of how the ORC-2-placer order number is assigned in these cases.
The application ID list becomes one of the institution's master dictionary lists that is documented in Chapter 8. Since third-party applications (those other than the placer and filler of an order) can send and receive ORM and ORR messages, the placer application ID in this field may not be the same as any sending and receiving application on the network (as identified in the MSH segment).
The conditions which make this field required are divided into two main issues. The data in ORC-2 and OBR-2 are logically the same thing: a placer id. The data in ORC-3 and OBR-3 are logically the same thing: the filler id.
From that perspective each message must have either a placer or a filler id with an exception for the case of a "Send Number" control code since its purpose is to request a placer id.
If both ORC and OBR are present in a message, then only one of the Segments must contain the value(s). Note that if both ORC-2 and OBR-2 are valued then they must be valued the same; as well, if both ORC-3 and OBR-3 are valued, then they must be valued the same. The sending system can include both the filler and the placer number in both the ORC and OBR segments as long as the data is the same between the two segments.
It is recommended that the initiating system should provide a unique number for the placer order number when a new order is placed or a unique number for the filler order number when an unsolicited result is initially communicated.
These rules apply to the few other fields that are present in both ORC and OBR for upward compatibility (e.g., quantity/timing, parent numbers, ordering provider, and ordering call back numbers).
(Definition from OBR.2 in Ch. 4)
Definition: This field is identical to ORC-2-Placer Order Number.
This field is a special case of the Entity Identifier data type (Chapter 2A, section 2.A.28). The first component is a string that identifies an individual order (i.e., ORC segment and associated order detail segment). A limit of fifteen (15) characters is suggested but not required. It is assigned by the placer (ordering application). An implementation is HL7 compliant when the number of characters for this field is increased to accommodate applications that require a greater number of characters for the Placer order number. It identifies an order uniquely among all orders from a particular ordering application. The second through fourth components contain the application ID of the placing application in the same form as the HD data type (section 2.A.36, "HD – Hierarchic designator"). The second component, namespace ID, is a user-defined coded value that will be uniquely associated with an application. A limit of six (6) characters is suggested but not required. A given institution or group of intercommunicating institutions should establish a unique list of applications that may be potential placers and fillers and assign unique application IDs. The components are separated by component delimiters.
See ORC-2-placer order number (section 4.5.1.2) for information on when this field must be valued.
A given institution or group of intercommunicating institutions should establish a list of applications that may be potential placers and fillers of orders and assign each a unique application ID. The application ID list becomes one of the institution's master dictionary lists that is documented in Chapter 8. Since third-party applications (those other than the placer and filler of an order) can send and receive ORM and ORR messages, the placer application ID in this field may not be the same as any sending and receiving application on the network (as identified in the MSH segment).
The conditions which make this field required are divided into two main issues. The data in ORC-2 and OBR-2 are logically the same thing: a placer id. The data in ORC-3 and OBR-3 are logically the same thing: the filler id.
From that perspective, each message must have either a placer or a filler id with an exception for the case of a "Send Number" control code since its purpose is to request a placer id.
If both ORC and OBR are present in a message, then only one of the Segments must contain the value(s). If both segments contain either ORC-2/OBR-2 or ORC-3/OBR-3, then each pair must be a matching pair. The sending system can include both the filler and the placer number in both the ORC and OBR segments as long as the data is the same between the two segments.
It is recommended that the initiating system should provide a unique number when a new order or unsolicited result is initially communicated.
These rules apply to the few other fields that are present in both ORC and OBR for upward compatibility (e.g., quantity/timing, parent numbers, ordering provider, and ordering call back numbers).
(Definition from OBR.2 in Ch. 7)
Definition: This field is identical to ORC-2-Placer Order Number.
This field is a special case of the Entity Identifier data type (Chapter 2A, section 2.A.28). The first component is a string that identifies an individual order (i.e., ORC segment and associated order detail segment). A limit of fifteen (15) characters is suggested but not required. It is assigned by the placer (ordering application). An implementation is HL7 compliant when the number of characters for this field is increased to accommodate applications that require a greater number of characters for the Placer order number. It identifies an order uniquely among all orders from a particular ordering application. The second through fourth components contain the application ID of the placing application in the same form as the HD data type (section 2.A.36, "HD – Hierarchic designator"). The second component, namespace ID, is a user-defined coded value that will be uniquely associated with an application. A limit of six (6) characters is suggested but not required. A given institution or group of intercommunicating institutions should establish a unique list of applications that may be potential placers and fillers and assign unique application IDs. The components are separated by component delimiters.
See ORC-2-placer order number (section 4.5.1.2) for information on when this field must be valued.
A given institution or group of intercommunicating institutions should establish a list of applications that may be potential placers and fillers of orders and assign each a unique application ID. The application ID list becomes one of the institution's master dictionary lists that is documented in Chapter 8. Since third-party applications (those other than the placer and filler of an order) can send and receive ORM and ORR messages, the placer application ID in this field may not be the same as any sending and receiving application on the network (as identified in the MSH segment).
The conditions which make this field required are divided into two main issues. The data in ORC-2 and OBR-2 are logically the same thing: a placer id. The data in ORC-3 and OBR-3 are logically the same thing: the filler id.
From that perspective, each message must have either a placer or a filler id with an exception for the case of a "Send Number" control code since its purpose is to request a placer id.
If both ORC and OBR are present in a message, then only one of the Segments must contain the value(s). If both segments contain either ORC-2/OBR-2 or ORC-3/OBR-3, then each pair must be a matching pair. The sending system can include both the filler and the placer number in both the ORC and OBR segments as long as the data is the same between the two segments.
It is recommended that the initiating system should provide a unique number when a new order or unsolicited result is initially communicated.
These rules apply to the few other fields that are present in both ORC and OBR for upward compatibility (e.g., quantity/timing, parent numbers, ordering provider, and ordering call back numbers).
(Definition from TXA.14 in Ch. 9)
Definition: This field is the placer application's order number.
This is a composite field. The first component is a string of characters that identifies an individual order (i.e., OBR). It is assigned by the placer (ordering application). It identifies an order uniquely among all orders from a particular ordering application. The second through fourth components contain the (filler) assigning authority of the placing application. The (filler) assigning authority is a string of characters that will be uniquely associated with an application. A given institution or group of intercommunicating institutions should establish a unique list of applications that may be potential placers and fillers and assign unique entity identifiers. The components are separated by component delimiters.
TXA-14 - Condition: If corresponding ORC and/or OBR segments are present in the message and ORC-2 or OBR-2 is valued, this field must be blank. If TXA-14 is valued while ORC-2 or OBR-2 is valued it shall be ignored. See message definitions including TXA for further guidance on which ORC/OBR pairs to consider.
(Definition from ARQ.24 in Ch. 10)
Definition: This field is the placer application's order number for the order associated with this scheduling request.
This field is described in detail in Chapter 4, section 4.5.1.2, "ORC-2 – Placer Order Number." It is an optional field, but if a Placer order number is present, then a Filler order number (ARQ-25 – Filler Order Number) must also be present.
(Definition from SCH.26 in Ch. 10)
Definition: This field is the placer application's order number for the order associated with this scheduling filler application response.
This field is described in detail in Section 4.5.1.2. It is an optional field, but if a Placer order number is present, then a Filler order number (Section 10.6.2.27) must also be present. Both this field and the Filler order number below may have been sent as part of the appointment request in the ARQ segment or they may be assigned by the scheduling filler application only.
(Definition from ORC.3 in Ch. 4)
Definition: This field is the order number associated with the filling application. It is a case of the Entity Identifier data type (Section 2.A.28). Its first component is a string that identifies an order detail segment (i.e., ORC segment and associated order detail segment). It is assigned by the order filler (receiving) application. This string must uniquely identify the order (as specified in the order detail segment) from other orders in a particular filling application (e.g., clinical laboratory). This uniqueness must persist over time.
The second through fourth components contain the filler application ID, in the form of the HD data type (see Section 2.A.36, "HD – hierarchic designator"). The second component is a user-defined coded value that uniquely defines the application from other applications on the network. A limit of six (6) characters is suggested but not required. The second component of the filler order number always identifies the actual filler of an order.
A given institution or group of intercommunicating institutions should establish a list of applications that may be potential placers and fillers of orders and assign each a unique application ID. The application ID list becomes one of the institution's master dictionary lists that is documented in Chapter 8. Since third- party applications (those other than the placer and filler of an order) can send and receive ORM and ORR messages, the filler application ID in this field may not be the same as any sending and receiving application on the network (as identified in the MSH segment).
The conditions which make this field required are divided into two main issues. The data in ORC-2 and OBR-2 are logically the same thing: a placer id. The data in ORC-3 and OBR-3 are logically the same thing: the filler id.
From that perspective each message must have either a placer or a filler id with an exception for the case of a "Send Number" control code since its purpose is to request a placer id.
If both ORC and OBR are present in a message, then only one of the Segments must contain the value(s). Note that if both ORC-2 and OBR-2 are valued, then they must be valued the same; as well, if both ORC-3 and OBR-3 are valued, then they must be valued the same. The sending system can include both the filler and the placer number in both the ORC and OBR segments as long as the data is the same between the two segments. It is recommended that the initiating system should provide a unique number for the placer order number when a new order is placed or a unique number for the filler order number when an unsolicited result is initially communicated.
The filler order number (OBR-3 or ORC-3) also uniquely identifies an order and its associated observations. For example, suppose that an institution collects observations from several ancillary applications into a common database and this common database is queried by yet another application for observations. In this case, the filler order number and placer order number transmitted by the common database application would be that of the original filler and placer, respectively, rather than a new one assigned by the common database application.
Similarly, if a third-party application, not the filler or placer, of an order were authorized to modify the status of an order (say, cancel it), the third-party application would send the filler an ORM message containing an ORC segment with ORC-1-order control equal to "CA" and containing the original placer order number and filler order number, rather than assign either itself.
(Definition from OBR.3 in Ch. 4)
Definition: This field is the order number associated with the filling application. This is a permanent identifier for an order and its associated observations. It is a special case of the Entity Identifier data type (see Chapter 2, section 2.A.28, "EI – entity identifier").
The first component is a string that identifies an individual order segment (i.e., ORC segment and associated order detail segment). It is assigned by the order filling (receiving) application. It identifies an order uniquely among all orders from a particular filling application (e.g., clinical laboratory). This uniqueness must persist over time.
The second through fourth components contain the filler application ID, in the form of the HD data type (see section 2.A.36, "HD – hierarchic designator"). The second component is a user-defined coded value that uniquely defines the application from other applications on the network. A limit of six (6) characters is suggested but not required. The second component of the filler order number always identifies the actual filler of an order.
See ORC-3-filler order number for information on when this field must be valued.
The conditions which make this field required are divided into two main issues. The data in ORC-2 and OBR-2 are logically the same thing: a placer id. The data in ORC-3 and OBR-3 are logically the same thing: the filler id.
From that perspective, each message must have either a placer or a filler id with an exception for the case of a "Send Number" control code since its purpose is to request a placer id.
If both ORC and OBR are present in a message, then only one of the Segments must contain the value(s). If both segments contain either ORC-2/OBR-2 or ORC-3/OBR-3, then each pair must be a matching pair. The sending system can include both the filler and the placer number in both the ORC and OBR segments as long as the data is the same between the two segments.
It is recommended that the initiating system should provide a unique number when a new order or unsolicited result is initially communicated.
The filler order number (OBR-3 or ORC-3) also uniquely identifies an order and its associated observations. For example, suppose that an institution collects observations from several ancillary applications into a common database and this common database is queried by yet another application for observations. In this case, the filler order number and placer order number transmitted by the common database application would be that of the original filler and placer, respectively, rather than a new one assigned by the common database application.
Similarly, if a third-party application, not the filler or placer, of an order were authorized to modify the status of an order (say, cancel it), the third-party application would send the filler an ORM message containing an ORC segment with ORC-1-order control equal to "CA" and containing the original placer order number and filler order number, rather than assign either itself.
(Definition from FT1.23 in Ch. 6)
Definition: This field is used when the billing system is requesting observational reporting justification for a charge. This is the number used by a filler to uniquely identify a result. See Chapter 4 for a complete description.
(Definition from OBR.3 in Ch. 7)
Definition: This field is the order number associated with the filling application. This is a permanent identifier for an order and its associated observations. It is a special case of the Entity Identifier data type (see Chapter 2, section 2.A.28, "EI – entity identifier").
The first component is a string that identifies an individual order segment (i.e., ORC segment and associated order detail segment). It is assigned by the order filling (receiving) application. It identifies an order uniquely among all orders from a particular filling application (e.g., clinical laboratory). This uniqueness must persist over time.
The second through fourth components contain the filler application ID, in the form of the HD data type (see section 2.A.36, "HD – hierarchic designator"). The second component is a user-defined coded value that uniquely defines the application from other applications on the network. A limit of six (6) characters is suggested but not required. The second component of the filler order number always identifies the actual filler of an order.
See ORC-3-filler order number for information on when this field must be valued.
The conditions which make this field required are divided into two main issues. The data in ORC-2 and OBR-2 are logically the same thing: a placer id. The data in ORC-3 and OBR-3 are logically the same thing: the filler id.
From that perspective, each message must have either a placer or a filler id with an exception for the case of a "Send Number" control code since its purpose is to request a placer id.
If both ORC and OBR are present in a message, then only one of the Segments must contain the value(s). If both segments contain either ORC-2/OBR-2 or ORC-3/OBR-3, then each pair must be a matching pair. The sending system can include both the filler and the placer number in both the ORC and OBR segments as long as the data is the same between the two segments.
It is recommended that the initiating system should provide a unique number when a new order or unsolicited result is initially communicated.
The filler order number (OBR-3 or ORC-3) also uniquely identifies an order and its associated observations. For example, suppose that an institution collects observations from several ancillary applications into a common database and this common database is queried by yet another application for observations. In this case, the filler order number and placer order number transmitted by the common database application would be that of the original filler and placer, respectively, rather than a new one assigned by the common database application.
Similarly, if a third-party application, not the filler or placer, of an order were authorized to modify the status of an order (say, cancel it), the third-party application would send the filler an ORM message containing an ORC segment with ORC-1-order control equal to "CA" and containing the original placer order number and filler order number, rather than assign either itself.
(Definition from TXA.15 in Ch. 9)
Definition: This field is the order number associated with the filling application. Where a transcription service or similar organization creates the document and uses an internally unique identifier, that number should be inserted in this field. Its first component is a string of characters that identifies an order detail segment (i.e., OBR). This string must uniquely identify the order (as specified in the order detail segment) from other orders in a particular filling application (i.e., transcription service). This uniqueness must persist over time. Where a number is reused over time, a date can be affixed to the non-unique number to make it unique.
The second through fourth components contains the (filler) assigning authority. The (filler) assigning authority is a string of characters that uniquely defines the application from other applications on the network. The second through fourth components of the filler order number always identify the actual filler of an order.
TXA-15 - Condition: If corresponding ORC and/or OBR segments are present in the message and ORC-3 or OBR-3 is valued, this field must be blank. If TXA-14 is valued while ORC-3 or OBR-3 is valued it shall be ignored. See message definitions including TXA for further guidanceon which ORC/OBR pairs to consider.
For further details, please see the definitions provided in Chapter 4, "Orders".
(Definition from ARQ.25 in Ch. 10)
Definition: This field is the order number assigned by the filler application for the order associated with this scheduling request.
This field is described in detail in Chapter 4, section 4.5.1.3, "ORC-3 – Filler Order Number.” It is conditionally mandatory depending on the presence of the Placer order number (ARQ-24 – Placer Order Number). This conditionally mandatory requirement addresses the concern that a Scheduling system cannot and should not create or fill an order. Therefore, an order must have been accepted by the filler application before scheduling the resources associated with that order.
(Definition from SCH.27 in Ch. 10)
Definition: This field is the order number assigned by the filler application for the order associated with this scheduling filler response.
This field is described in detail in Chapter 4, Orders, section 4.5.1.3. It is conditionally mandatory depending on the presence of the placer order number (section 10.6.2.26). This conditionally mandatory requirement addresses the concern that a Scheduling system cannot and should not create or fill an order. Therefore, an order must have been accepted by the order filler application before scheduling the resources associated with that order.
(Definition from ORC.4 in Ch. 4)
Definition: This field contains a unique identifier for an Order Group as referenced by the Placer application. An Order Group is a set of orders grouped together by the placer application.
The first component is a string that uniquely identifies all order groups from the placer application. A limit of fifteen (15) characters is suggested but not required.
The second through fourth components constitute a placer or filler application ID identical to the analogous components of ORC-3-filler order number . Order groups and how to use them are described in detail in Section 4.5.1, "ORC – Common Order Segment."
(Definition from ARQ.4 in Ch. 10)
Definition: This field contains a unique identifier for the Placer Group as referenced by the Placer application. A Placer Order Group is a set of appointments grouped together by the placer application, and subsequently identified by the placer application.
The second through fourth components contain the assigning authority identifying information.
(Definition from SCH.4 in Ch. 10)
Definition: This field contains a unique identifier for the Placer Group as referenced by the Placer application, the Filler application, or both. A Placer Group is a set of appointments grouped together by the placer application, and subsequently identified by the placer application and/or by the filler application.
Within each of the two subcomponents, the first component is a string that identifies a group of appointment requests. It is assigned by the Placer or Filler application, and it identifies an appointment group uniquely among all such groups of requests from a particular requesting application.
Definition: This field specifies the status of an order. Refer to HL7 Table 0038 – Order status in Chapter 2C, Code Tables, for valid entries. The purpose of this field is to report the status of an order either upon request (solicited), or when the status changes (unsolicited). It does not initiate action. It is assumed that the order status always reflects the status as it is known to the sending application at the time that the message is sent. Only the filler can originate the value of this field.
Although HL7 Table 0038 – Order status contains many of the same values contained in HL7 Table 0119 – Order control codes and their meaning, its purpose is different. Order status may typically be used in a message with an ORC-1-order control value of SR or SC to report the status of the order on request or to any interested party at any time.
Definition: This field allows the placer (sending) application to determine the amount of information to be returned from the filler. Sometimes the requested level of response may not be possible immediately, but when it is possible, the filler (receiving) application must send the information. When the field is null, D is the default value of the field. Refer to HL7 Table 0121 – Response flag in Chapter 2C, Code Tables, for valid entries.
(Definition from ORC.7 in Ch. 4)
Attention: The ORC-7 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 and TQ2 segments described in sections 4.5.4 and 4.5.5, respectively.
(Definition from OBR.27 in Ch. 4)
Attention: The OBR-27 element 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.
(Definition from RXE.1 in Ch. 4A)
Attention: The RXE-1 field was retained for backward compatibilty only as of v 2.5 and the detail was withdrawn and removed from the standard as of v 2.7.
(Definition from RXG.3 in Ch. 4A)
Attention: The RXG-3 field was retained for backward compatibilty only as of v 2.5 and the detail was withdrawn and removed from the standard as of v 2.7.
Note: The contents of fields 3-8 should be identical to the comparable fields in the RXE (RXE-2 thru 5).
(Definition from OBR.27 in Ch. 7)
Attention: The OBR-27 element 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.
(Definition from ORC.8 in Ch. 4)
Definition: This field relates a child order to its parent order when a parent child order relationship exists. The parent child order mechanism is described in HL7 Table 0119 under order control code PA. This field uniquely identifies the parent order; no other information is required to link the child order with its parent order. It can be used to link the order to the results that triggered this order (e.g., a reflex order) or other order it relates to as an occurrence. This field repeats to allow linking to more than one parent, if necessary.
The first component has the same format as ORC-2-Placer Order Number (Section 4.5.3.2, "Placer Order Number (EI) 00216"). The second component has the same format as ORC-3-Filler Order Number (Section 4.5.3.3, "Filler Order Number (EI) 00217"). The components of the placer order number and the filler order number are transmitted in sub-components of the two components of this field.
Note that ORC-8 – Parent Order is equivalent to OBR-54 – Parent Order, but neither one is the same as OBR-29 – Result Observation Identifier.
Condition: Where the message has matching ORC/OBR pairs, ORC-8 and OBR-54 Must carry the same value.
(Definition from OBR.54 in Ch. 4)
Definition: This field relates a child order to its parent order when a parent child order relationship exists. The parent child order mechanism is described in HL7 Table 0119 – Order Control Codes in Chapter 2C, Code Tables, under order control code PA. This field uniquely identifies the parent orders; no other information is required to link the child order with its parent orders. It can be used to express that this order is a reflex being a consequence of original results referred here.
The first component has the same format as ORC-2-placer order number (Section 4.5.3.2, "Placer Order Number (EI) 00216"). The second component has the same format as ORC-3-filler order number (Section 4.5.3.3, "Filler Order Number (EI) 00217"). The components of the placer order number and the filler order number are transmitted in sub-components of the two components of this field.
Note that ORC-8 – Parent Order is equivalent to OBR-54-Parent Order, but neither one is the same as OBR-29-Parent Result Obersvation Identifier .
Condition: Where the message has matching ORC/OBR pairs, ORC-8 and OBR-54 must carry the same value.
(Definition from OBR.54 in Ch. 7)
Definition: This field relates a child order to its parent order when a parent child order relationship exists. The parent child order mechanism is described in HL7 Table 0119 – Order Control Codes in Chapter 2C, Code Tables, under order control code PA. This field uniquely identifies the parent orders; no other information is required to link the child order with its parent orders. It can be used to express that this order is a reflex being a consequence of original results referred here.
The first component has the same format as ORC-2-placer order number (Section 4.5.3.2, "Placer Order Number (EI) 00216"). The second component has the same format as ORC-3-filler order number (Section 4.5.3.3, "Filler Order Number (EI) 00217"). The components of the placer order number and the filler order number are transmitted in sub-components of the two components of this field.
Note that ORC-8 – Parent Order is equivalent to OBR-54-Parent Order, but neither one is the same as OBR-29-Parent Result Obersvation Identifier .
Condition: Where the message has matching ORC/OBR pairs, ORC-8 and OBR-54 must carry the same value.
Definition: This field contains the date and time of the event that initiated the current transaction as reflected in ORC-1 Order Control Code. This field is not equivalent to MSH-7 Date and Time of Message, which reflects the date/time of message generation.
Examples: When ORC-1 is “NW” this date represents the date/time when the order was placed by the ordering provider; when ORC-1 is "CA" this date represents the date/time when request for a cancellation was made by the placer, while for a "CR" this date represents the date/time when the cancellation was accepted by the filler (e.g., the change request was applied). When an ORC is included in an ORU message and ORC-1 is "RE", then the date represents the date/time when the observation(s) on the transaction were made available by the source system.
(Definition from NTE.5 in Ch. 2)
Definition: This field contains the identity of the person who actually keyed the comment into the application. It provides an audit trail in case the comment is entered incorrectly and the ancillary department needs to clarify the comment. By local agreement, either the ID number or name component MAY be omitted.
(Definition from ORC.10 in Ch. 4)
Definition: This field was retained for backward compatibility only as of v 2.7 and the detail was withdrawn and removed from the standard as of v 2.9. The reader is referred to the PRT segment described in Chapter 7.
(Definition from ACC.7 in Ch. 6)
Definition: This field identifies the person entering the accident information.
(Definition from MFE.7 in Ch. 8)
Definition: This field contains the identity of the person who actually keyed the master file entry into the application. It provides an audit trail in case the request is entered incorrectly and the ancillary department needs to clarify the request.
(Definition from OM7.20 in Ch. 8)
Note: This field is deprecated and retained for backward compatibility as of v 2.8.
Definition: This field contains the identity of the person who actually keyed the service item into the application. It provides an audit trail in case the request is entered incorrectly and the ancillary department needs to clarify the request.
Definition: This field was retained for backward compatibility only as of v 2.7 and the detail was withdrawn and removed from the standard as of v 2.9. The reader is referred to the PRT segment described in Chapter 7.
(Definition from ORC.12 in Ch. 4)
Definition: This field was retained for backward compatibility only as of v 2.7 and the detail was withdrawn and removed from the standard as of v 2.9. The reader is referred to the PRT segment described in Chapter 7.
(Definition from OBR.16 in Ch. 4)
Definition: This field was retained for backward compatibility only as of v 2.7 and the detail was withdrawn and removed from the standard as of v 2.9. The reader is referred ot the PRT segment as described in Chapter 7.
(Definition from OBR.16 in Ch. 7)
Definition: This field was retained for backward compatibility only as of v 2.7 and the detail was withdrawn and removed from the standard as of v 2.9. The reader is referred ot the PRT segment as described in Chapter 7.
Definition: This field specifies the location (e.g., nurse station, ancillary service location, clinic, floor) where the person who entered the request was physically located when the order was entered. Note that this refers to the current transaction as reflected in ORC-1 Order Control Code. Only those subcomponents relevant to enterer's location should be valued (commonly, nursing unit; facility; building; floor). The person who entered the request is defined in ORC-10-entered by.
Definition: This field contains the telephone number to call for clarification of a request or other information regarding the order. ORC-14-call back phone number is the same as OBR-17-order callback phone number.
Definition: This field 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. If the order identified in the ORC has children, the children which have not started should be canceled; if there is a child in process, it should be discontinued; if a child has progressed beyond the point where it can be discontinued, its status is unaffected.
Definition: This field contains the explanation (either in coded or text form) of the reason for the order event described by the order control code (HL7 Table 0119 - Order control codes). Whereas an NTE after the order-specific segment (e.g., RXO, ORO, OBR) would provide a comment for that specific segment, the purpose of the order control code reason is only to expand on the reason for the order event.
ORC-16-order control code reason is typically not valued when ORC-1-order control is NW, although it could be. In the case of a canceled order, for example, this field is commonly used to explain the cancellation. A Pharmacy system that canceled a drug order from a physician because of a well-documented allergy would likely report the fact of the allergy in this field.
If it canceled the order because of a drug interaction this field might contain at least the names (and codes, if needed) of the interacting substances, the text describing the interaction, and the level of severity of the interaction.
Refer HL7 Table 0949 – Order Control Code Reason in Chapter 2C, Code Tables.
Definition: This field was retained for backward compatibility only as of v 2.7 and the detail was withdrawn and removed from the standard as of v 2.9. The reader is referred to the PRT segment described in Chapter 7. Refer to Table 0666 - Entering Organization in Chapter 2C for valid values.
Definition: This field was retained for backward compatibility only as of v 2.7 and the detail was withdrawn and removed from the standard as of v 2.9. The reader is referred to the PRT segment described in Chapter 7. Refer to Table 0668 - Entering Device in Chapter 2C for valid values.
Definition: This field was retained for backward compatibility only as of v 2.7 and the detail was withdrawn and removed from the standard as of v 2.9. The reader is referred to the PRT segment described in Chapter 7.
(Definition from ORC.20 in Ch. 4)
Definition: This field indicates the status of the patient's or the patient's representative's consent for responsibility to pay for potentially uninsured services. This element is introduced to satisfy CMS Medical Necessity requirements for outpatient services. This element indicates (a) whether the associated diagnosis codes for the service are subject to medical necessity procedures, (b) whether, for this type of service, the patient has been informed that they may be responsible for payment for the service, and (c) whether the patient agrees to be billed for this service. The values for this field are drawn from User-Defined Table 0339 – Advanced Beneficiary Notice Code in Chapter 2C, Code Tables.
(Definition from FT1.27 in Ch. 6)
Definition: This field indicates the status of the patient's or the patient's representative's consent for responsibility to pay for potentially uninsured services. This element is introduced to satisfy CMS Medical Necessity requirements for outpatient services. This element indicates (a) whether the associated diagnosis codes for the service are subject to medical necessity procedures, (b) whether, for this type of service, the patient has been informed that they may be responsible for payment for the service, and (c) whether the patient agrees to be billed for this service. Refer to User-defined Table 0339 - Advanced Beneficiary Notice Code in Chapter 2C, Code Tables, for suggested values.
Definition: This field was retained for backward compatibility only as of v 2.7 and the detail was withdrawn and removed from the standard as of v 2.9. The reader is referred to the PRT segment described in Chapter 7.
Definition: This field was retained for backward compatibility only as of v 2.7 and the detail was withdrawn and removed from the standard as of v 2.9. The reader is referred to the PRT segment described in Chapter 7.
Definition: This field was retained for backward compatibility only as of v 2.7 and the detail was withdrawn and removed from the standard as of v 2.9. The reader is referred to the PRT segment described in Chapter 7.
Definition: This field was retained for backward compatibility only as of v 2.7 and the detail was withdrawn and removed from the standard as of v 2.9. The reader is referred to the PRT segment described in Chapter 7.
Definition: This field is a modifier or refiner of the ORC-5-Order status field. This field may be used to provide additional levels of specificity or additional information for the defined order status codes. Unlike the Order Status field, which is controlled by an HL7 defined table, this field is a CE data type allowing applications to support an unlimited library of Order Status Modifier codes.
Usage Rule: This field may only be populated if the ORC-5-Order Status field is valued.
Examples: An LIS processing an order with an order status of IP may send an update using the order status modifier to indicate the progress of the order through the laboratory or to indicate that the order has been sent to an external laboratory. Another example using the non-medical orders would be a case in which a phone has been ordered delivered to a patient's room but has been disconnected temporarily. The ORC-5-Order status indicates IP and the ORC-25-Order status modifier would indicate a disconnected status. A third example involves pharmacy dispenses. It is sometimes not enough to know that a prescription is being dispensed. The ORC-25-Order status modifier would indicate if a label had been printed, the prescription filled, or the prescription sold.
Refer HL7 Table 0950 – Order Status Modifier in Chapter 2C, Code Tables.
Definition: This field contains the reason why the patient did not sign an Advanced Beneficiary Notice. The reason may be coded or it may be a free text entry. Refer to HL7 Table 0552 – Advanced beneficiary notice override reason in Chapter 2C, Code Tables.
Condition: This field is required if the value of ORC-20 Advanced Beneficiary Notice Code indicates that the notice was not signed. For example, additional qualifying or explanatory information would be justified if ORC-20 was populated with the values "3" or "4" in User-defined Table 0339 – Advanced Beneficiary Notice Code, or similar values in related external code tables.
Definition: This field specifies the date/time 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 message, but would have little relevance at that time.)
(Definition from ORC.28 in Ch. 4)
Definition: This field contains information about the level of security and/or sensitivity surrounding the order (e.g., highly sensitive, not sensitive, sensitive, etc.). Refer to HL7 Table 0177 – Confidentiality Code in Chapter 2C, Code Tables, for allowed values. The specific treatment of data with a particular confidentiality level is subject to site-specific negotiation.
(Definition from OM1.30 in Ch. 8)
Definition: This field contains the degree to which special confidentiality protection should be applied to the observation. For example, a tighter control may be applied to an HIV test than to a CBC. Refer to User-defined Table 0177 - Confidentiality Code in Chapter 2C, Code Tables, for suggested values.
Definition: This field indicates whether the order is to be executed in an inpatient setting or an outpatient setting. If this field is not valued, the system default is assumed. Refer to HL7 Table 0482 – Order Type in Chapter 2C, Code Tables, for suggested values.
Examples: Before discharge an order is placed for follow-up physical therapy, or to pick up a prescription at a community pharmacy. The patient is an inpatient according to PV1, but the order is an outpatient order.
Definition: This field indicates the form of authorization a recorder had from the responsible practitioner to create or change an order. Refer to HL7 Table 0483 - Authorization Mode in Chapter 2C, Code Tables, for suggested values.
To be harmonized to Participation.mode_cd in version 3.
Definition: This field was retained for backward compatibility only as of v 2.7 and the detail was withdrawn and removed from the standard as of v 2.9.
Definition: 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.
Definition: This field enables a shorter number to be communicated that is unique within other identifiers.
The Order Workflow Profile references/represents the information necessary to define the workflow variant when that is not fully described through the use of ORC-1 Order Control and MSH-21 Message Profile. This enables contributing systems to apply locally agreed to rules. See User-defined Table 0934 - Order Workflow Profile for a list of suggested values.
(Definition from OH1.2 in Ch. 3)
Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from OH2.2 in Ch. 3)
Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from OH3.2 in Ch. 3)
Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from OH4.2 in Ch. 3)
Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from ORC.35 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when either ORC-2 and/or ORC 3 is valued with a unique identifier in accordance with Chapter 2, Section 2.10.4.2.
(Definition from OBR.55 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when either an OBR-2 and/or OBR-3 is valued with unique identifier in accordance with Chapter 2, Section 2.10.4.2.
(Definition from IPC.10 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when the combination of IPC-1, IPC-2, IPC-3, and IPC-4 represents a unique identifier according to Chapter 2, Section 2.10.4.2.
(Definition from BPX.22 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an BPX is uniquely identified sufficiently within the specific implementation using BPX-17 or BPX-6 as agreed to by the trading partners and in accordance with Chapter 2, Section 2.10.4.2.
(Definition from BTX.21 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an BTX is uniquely identified sufficiently within the specific implementation using BTX-20 or BTX-3 as agreed to by the trading partners in accordance with Chapter 2, Section 2.10.4.2.
(Definition from DON.34 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an DON is uniquely identified sufficiently within the specific implementation using DON-1 in accordance with Chapter 2, Section 2.10.4.2.
(Definition from BUI.13 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an BUI is uniquely identified sufficiently within the specific implementation using BUI-2 in accordance with Chapter 2, Section 2.10.4.2
(Definition from RXV.22 in Ch. 4A)
Definition: The intended handling by the receiver of the infusion order is represented by this segment. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from CDO.2 in Ch. 4A)
Definition: The Action Code indicates whether the cumulative dosage segment is intended to be added, deleted, updated, or did not change. If the field is not valued in any CDO segments for the order, the segments are considered to have been sent in snapshot mode. If some but not all CDO segments for the order do not have the action code valued, the default value is Add. Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from OBR.55 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an either OBR-2 and/or OBR-3 is valued with unique identifier in accordance with Chapter 2, Section 2.10.4.2.
(Definition from OBX.31 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an OBX-21 is valued in accordance with guidance in Chapter 2, Section 2.10.4.2.
(Definition from SPM.35 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an SPM-2 or SPM-31 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.
(Definition from PRT.2 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0287 – Problem/goal action code for valid values.
(Definition from CSR.17 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when CSR-1 and CSR-4, or CSR-2 and CSR-5 are valued as agreed to by the trading partners in accordance with the guidance in Chapter 2, Section 2.10.4.2.
(Definition from CTI.4 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when CTI-1 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.
(Definition from SHP.12 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when SHP-1 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.
(Definition from PAC.9 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when PAC-2 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.
(Definition from GOL.1 in Ch. 12)
Definition: The action code field gives the intent of the problem or goal. Refer to HL7 Table 0287 – Problem/Goal Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from PRB.1 in Ch. 12)
Definition: This field contains the intent of the message. Refer to HL7 Table 0287 – Problem/Goal Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from PTH.1 in Ch. 12)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0287 – Problem/Goal Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from DEV.1 in Ch. 17)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0287 – Problem/goal action code for valid values.
Definition: 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.) When the date is outside the specified order status date range, ORC-5 (Order Status) should be considered an unspecified status, i.e., the status represented in ORC-5 would not necessarily be reflective of the actual status anymore.
Definition: This field represents the official date/time when the order was originally created; whether as an electronic order or as an initial paper requisition. This may also be known as Prescription Date/Time. 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, Results etc.). When ORC-1 Order Control Code is “NW” for a new order, this date/time, if valued, is typically expected to be the same as ORC-9 Date/Time of Order Event. An example where the ORC-37, Order Creation Date/Time, is not the same as ORC-9, Date/Time of Order Event, while ORC-1, Order Control Code, is “NW” is when the order originally was recorded and signed by a physician on paper (ORC-37), but not entered in a system until some time (ORC-9) thereafter.
As different date/times can be considered the initiation of the order (the first person entering it or a subsequent step), or data is not available (e.g., a paper request without a date/time when it was created), the system where the order was first documented determines which date/time it reflects according to the organization's policies and would represent that in ORC-37.
When an order is resulted (ORC-1 = “RE”) the value in ORC-37 does not change from the value supplied in the original order.
Definition: This field contains a unique identifier for the Order Group as referenced by the Filler application. An Order Group is a set of orders grouped together by the placer application.
The first component is a string that uniquely identifies all order groups from the filler application. A limit of fifteen (15) characters is suggested but not required.
The second through fourth components constitute a filler application ID identical to the analogous components of ORC-3-filler order number . Order groups and how to use them are described in detail in Section 4.5.1, "ORC – Common Order Segment."
The BLG segment is used to provide billing information, on the ordered service, to the filling application.
Seq# | DataElement | Description | Must Implement | Flags | Cardinality | Length | C.LEN | Vocabulary | DataType |
---|---|---|---|---|---|---|---|---|---|
BLG | |||||||||
1 | 00234 | When to Charge | [0..1] | CCD | |||||
2 | 00235 | Charge Type | [0..1] | [2..2] | ID | ||||
3 | 00236 | Account ID | [0..1] | CX | |||||
4 | 01645 | Charge Type Reason | [0..1] | CWE |
Definition: This field specifies when to charge for the ordered service. Refer to HL7 Table 0100 – Invocation event in Chapter 2C, Code Tables, for valid values.
Definition: This field identifies someone or something other than the patient to be billed for this service. It is used in conjunction with BLG-3-account ID. Refer to HL7 Table 0122 – Charge Type in Chapter 2C, Code Tables, for valid values.
Definition: This field identifies the account to be billed. It is used in conjunction with BLG-2-charge type. Refer to HL7 Table 0061 – Check digit scheme in Chapter 2C, Code Tables.
Definition: This field explains the choice of and provides the clinical rationale for the selected charge type identified in BLG-2. Refer to User-defined Table 0475 – Charge Type Reason in Chapter 2C, code Tables, for suggested values.
General (taken from ASTM E1238)
The Observation Request (OBR) segment is used to transmit information specific to an order for a diagnostic study or observation, physical exam, or assessment.
The Observation Request segment defines the attributes of a particular request for diagnostic services (e.g., laboratory, EKG) or clinical observations (e.g., vital signs or physical exam). When a placer requests a given set of observations, always include an order segment. For lab tests, the information in the order segment usually applies to a single specimen. However, there is not a one-to-one relationship between specimen and tests ordered. Different test batteries will usually require their own order segments even when they can be performed on a single specimen. In this case, the specimen information must be duplicated in each of the order segments that employ that specimen. For other diagnostic studies, e.g., chest X-ray, a separate order segment will usually be generated for each diagnostic study.
Though multiple observation batteries can be ordered on a single order segment, the observation filler shall generate a separate order segment for each battery that it processes independently, e.g., electrolyte, CBC, vital signs. When reporting the observations, the filling service shall copy the appropriate order (specimen) information from the original order segment into each of the new order segments so that a separate "order" segment is returned to the placer as a "header" for each separate battery of observations.
In the event that an ordered battery of observations cannot be performed, e.g., because of hemolysis on a blood sample, an order segment will be returned to the placer with OBR-25-result status equal to X (to indicate that the study was not performed). In this case, no observation segments will be transmitted.
When observations are successfully completed, the message returned to the placer will include the order segment (OBR) followed by observation (OBX) segments for each distinct observation generated by the order (see Chapter 7). The number of such observation segments will depend upon the number of individual measurements performed in the process.
OBX segments can be sent by the placer along with an order to provide the filling service with clinical data needed to interpret the results. (See Chapter 7 for OBX details.)
Seq# | DataElement | Description | Must Implement | Flags | Cardinality | Length | C.LEN | Vocabulary | DataType |
---|---|---|---|---|---|---|---|---|---|
OBR | |||||||||
1 | 00237 | Set ID – OBR | [0..1] | [1..4] | SI | ||||
2
|
00216 | Placer Order Number |
MAY
True: False: |
C |
[1..1] [0..1] |
EI | |||
3
|
00217 | Filler Order Number |
MAY
True: False: |
C |
[1..1] [0..1] |
EI | |||
4 | 00238 | Universal Service Identifier | SHALL | [1..1] | CWE | ||||
5 | 00239 | Priority | SHALL NOT | W | [0..0] | ||||
6 | 00240 | Requested Date/Time | SHALL NOT | W | [0..0] | ||||
7
|
00241 | Observation Date/Time # |
MAY
True: False: |
C |
[1..1] [0..1] |
DTM | |||
8 | 00242 | Observation End Date/Time # | [0..1] | DTM | |||||
9 | 00243 | Collection Volume * | B | [0..1] | CQ | ||||
10 | 00244 | Collector Identifier * | B | [0..*] | XCN | ||||
11 | 00245 | Specimen Action Code * | [0..1] | [1..1] | ID | ||||
12 | 00246 | Danger Code | [0..1] | CWE | |||||
13 | 00247 | Relevant Clinical Information | = | [0..*] | 300 | CWE | |||
14 | 00248 | Specimen Received Date/Time * | SHALL NOT | W | [0..0] | DTM | |||
15 | 00249 | Specimen Source | SHALL NOT | W | [0..0] | ||||
16 | 00226 | Ordering Provider | SHALL NOT | W | [0..0] | ||||
17 | 00250 | Order Callback Phone Number | [0..2] | XTN | |||||
18 | 00251 | Placer Field 1 | = | [0..1] | 199 | ST | |||
19 | 00252 | Placer Field 2 | = | [0..1] | 199 | ST | |||
20 | 00253 | Filler Field 1 + | = | [0..1] | 199 | ST | |||
21 | 00254 | Filler Field 2 + | = | [0..1] | 199 | ST | |||
22
|
00255 | Results Rpt/Status Chng – Date/Time + |
MAY
True: False: |
C |
[1..1] [0..1] |
DTM | |||
23 | 00256 | Charge to Practice + | [0..1] | MOC | |||||
24 | 00257 | Diagnostic Serv Sect ID | [0..1] | [2..3] | ID | ||||
25
|
00258 | Result Status + |
MAY
True: False: |
C |
[1..1] [0..1] |
[1..1] | ID | ||
26 | 00259 | Parent Result + | [0..1] | PRL | |||||
27 | 00221 | Quantity/Timing | SHALL NOT | W | [0..0] | ||||
28 | 00260 | Result Copies To | SHALL NOT | W | [0..0] | ||||
29 | 00261 | Parent Results Observation Identifier | [0..1] | EIP | |||||
30 | 00262 | Transportation Mode | [0..1] | [4..4] | ID | ||||
31 | 00263 | Reason for Study | [0..*] | CWE | |||||
32 | 00264 | Principal Result Interpreter + | SHALL NOT | W | [0..0] | ||||
33 | 00265 | Assistant Result Interpreter + | SHALL NOT | W | [0..0] | ||||
34 | 00266 | Technician + | SHALL NOT | W | [0..0] | ||||
35 | 00267 | Transcriptionist + | SHALL NOT | W | [0..0] | ||||
36 | 00268 | Scheduled Date/Time + | [0..1] | DTM | |||||
37 | 01028 | Number of Sample Containers * | = | [0..1] | 16 | NM | |||
38 | 01029 | Transport Logistics of Collected Sample * | [0..*] | CWE | |||||
39 | 01030 | Collector's Comment * | [0..*] | CWE | |||||
40 | 01031 | Transport Arrangement Responsibility | [0..1] | CWE | |||||
41 | 01032 | Transport Arranged | [0..1] | [1..1] | ID | ||||
42 | 01033 | Escort Required | [0..1] | [1..1] | ID | ||||
43 | 01034 | Planned Patient Transport Comment | [0..*] | CWE | |||||
44 | 00393 | Procedure Code | [0..1] | CNE | |||||
45 | 01316 | Procedure Code Modifier | [0..*] | CNE | |||||
46 | 01474 | Placer Supplemental Service Information | [0..*] | CWE | |||||
47 | 01475 | Filler Supplemental Service Information | [0..*] | CWE | |||||
48
|
01646 | Medically Necessary Duplicate Procedure Reason |
MAY
True: False: |
C |
[1..1] [0..1] |
CWE | |||
49 | 01647 | Result Handling | [0..1] | CWE | |||||
50 | 02286 | Parent Universal Service Identifier | SHALL NOT | W | [0..0] | ||||
51 | 02307 | Observation Group ID | [0..1] | EI | |||||
52 | 02308 | Parent Observation Group ID | [0..1] | EI | |||||
53 | 03303 | Alternate Placer Order Number | [0..*] | CX | |||||
54 | 00222 | Parent Order | [0..*] | EIP | |||||
55 | 00816 | Action Code | [0..1] | [2..2] | ID |
(Definition from OBR.1 in Ch. 4)
Definition: For the first order transmitted, the sequence number shall be 1; for the second order, it shall be 2; and so on.
(Definition from OBR.1 in Ch. 7)
Definition: For the first order transmitted, the sequence number shall be 1; for the second order, it shall be 2; and so on.
(Definition from ORC.2 in Ch. 4)
Definition: This field is the placer application's order number.
This field is a case of the Entity Identifier data type (See Section 2.A.28, "EI – Entity Identifier"). The first component is a string that identifies an individual order (i.e., ORC segment and associated order detail segment). It is assigned by the placer (ordering application). It identifies an order uniquely among all orders from a particular ordering application. The second through fourth components contain the application ID of the placing application in the same form as the HD data type (Section 2.A.36, "HD – Hierarchic designator"). The second component, namespace ID, is a user-defined coded value that will be uniquely associated with an application. A limit of six (6) characters is suggested but not required. A given institution or group of intercommunicating institutions should establish a unique list of applications that may be potential placers and fillers and assign unique application IDs. The components are separated by component delimiters.
There are three situations in which the true placer is somewhat arbitrary (and thus not unique):
in ORC-1-order control value of RO, following an RU replacement;
in ORC-1-order control value of CH (child orders); and
in ORC-1-order control value of SN (send number).
See the Table Notes under ORC-1-order control for the details of how the ORC-2-placer order number is assigned in these cases.
The application ID list becomes one of the institution's master dictionary lists that is documented in Chapter 8. Since third-party applications (those other than the placer and filler of an order) can send and receive ORM and ORR messages, the placer application ID in this field may not be the same as any sending and receiving application on the network (as identified in the MSH segment).
The conditions which make this field required are divided into two main issues. The data in ORC-2 and OBR-2 are logically the same thing: a placer id. The data in ORC-3 and OBR-3 are logically the same thing: the filler id.
From that perspective each message must have either a placer or a filler id with an exception for the case of a "Send Number" control code since its purpose is to request a placer id.
If both ORC and OBR are present in a message, then only one of the Segments must contain the value(s). Note that if both ORC-2 and OBR-2 are valued then they must be valued the same; as well, if both ORC-3 and OBR-3 are valued, then they must be valued the same. The sending system can include both the filler and the placer number in both the ORC and OBR segments as long as the data is the same between the two segments.
It is recommended that the initiating system should provide a unique number for the placer order number when a new order is placed or a unique number for the filler order number when an unsolicited result is initially communicated.
These rules apply to the few other fields that are present in both ORC and OBR for upward compatibility (e.g., quantity/timing, parent numbers, ordering provider, and ordering call back numbers).
(Definition from OBR.2 in Ch. 4)
Definition: This field is identical to ORC-2-Placer Order Number.
This field is a special case of the Entity Identifier data type (Chapter 2A, section 2.A.28). The first component is a string that identifies an individual order (i.e., ORC segment and associated order detail segment). A limit of fifteen (15) characters is suggested but not required. It is assigned by the placer (ordering application). An implementation is HL7 compliant when the number of characters for this field is increased to accommodate applications that require a greater number of characters for the Placer order number. It identifies an order uniquely among all orders from a particular ordering application. The second through fourth components contain the application ID of the placing application in the same form as the HD data type (section 2.A.36, "HD – Hierarchic designator"). The second component, namespace ID, is a user-defined coded value that will be uniquely associated with an application. A limit of six (6) characters is suggested but not required. A given institution or group of intercommunicating institutions should establish a unique list of applications that may be potential placers and fillers and assign unique application IDs. The components are separated by component delimiters.
See ORC-2-placer order number (section 4.5.1.2) for information on when this field must be valued.
A given institution or group of intercommunicating institutions should establish a list of applications that may be potential placers and fillers of orders and assign each a unique application ID. The application ID list becomes one of the institution's master dictionary lists that is documented in Chapter 8. Since third-party applications (those other than the placer and filler of an order) can send and receive ORM and ORR messages, the placer application ID in this field may not be the same as any sending and receiving application on the network (as identified in the MSH segment).
The conditions which make this field required are divided into two main issues. The data in ORC-2 and OBR-2 are logically the same thing: a placer id. The data in ORC-3 and OBR-3 are logically the same thing: the filler id.
From that perspective, each message must have either a placer or a filler id with an exception for the case of a "Send Number" control code since its purpose is to request a placer id.
If both ORC and OBR are present in a message, then only one of the Segments must contain the value(s). If both segments contain either ORC-2/OBR-2 or ORC-3/OBR-3, then each pair must be a matching pair. The sending system can include both the filler and the placer number in both the ORC and OBR segments as long as the data is the same between the two segments.
It is recommended that the initiating system should provide a unique number when a new order or unsolicited result is initially communicated.
These rules apply to the few other fields that are present in both ORC and OBR for upward compatibility (e.g., quantity/timing, parent numbers, ordering provider, and ordering call back numbers).
(Definition from OBR.2 in Ch. 7)
Definition: This field is identical to ORC-2-Placer Order Number.
This field is a special case of the Entity Identifier data type (Chapter 2A, section 2.A.28). The first component is a string that identifies an individual order (i.e., ORC segment and associated order detail segment). A limit of fifteen (15) characters is suggested but not required. It is assigned by the placer (ordering application). An implementation is HL7 compliant when the number of characters for this field is increased to accommodate applications that require a greater number of characters for the Placer order number. It identifies an order uniquely among all orders from a particular ordering application. The second through fourth components contain the application ID of the placing application in the same form as the HD data type (section 2.A.36, "HD – Hierarchic designator"). The second component, namespace ID, is a user-defined coded value that will be uniquely associated with an application. A limit of six (6) characters is suggested but not required. A given institution or group of intercommunicating institutions should establish a unique list of applications that may be potential placers and fillers and assign unique application IDs. The components are separated by component delimiters.
See ORC-2-placer order number (section 4.5.1.2) for information on when this field must be valued.
A given institution or group of intercommunicating institutions should establish a list of applications that may be potential placers and fillers of orders and assign each a unique application ID. The application ID list becomes one of the institution's master dictionary lists that is documented in Chapter 8. Since third-party applications (those other than the placer and filler of an order) can send and receive ORM and ORR messages, the placer application ID in this field may not be the same as any sending and receiving application on the network (as identified in the MSH segment).
The conditions which make this field required are divided into two main issues. The data in ORC-2 and OBR-2 are logically the same thing: a placer id. The data in ORC-3 and OBR-3 are logically the same thing: the filler id.
From that perspective, each message must have either a placer or a filler id with an exception for the case of a "Send Number" control code since its purpose is to request a placer id.
If both ORC and OBR are present in a message, then only one of the Segments must contain the value(s). If both segments contain either ORC-2/OBR-2 or ORC-3/OBR-3, then each pair must be a matching pair. The sending system can include both the filler and the placer number in both the ORC and OBR segments as long as the data is the same between the two segments.
It is recommended that the initiating system should provide a unique number when a new order or unsolicited result is initially communicated.
These rules apply to the few other fields that are present in both ORC and OBR for upward compatibility (e.g., quantity/timing, parent numbers, ordering provider, and ordering call back numbers).
(Definition from TXA.14 in Ch. 9)
Definition: This field is the placer application's order number.
This is a composite field. The first component is a string of characters that identifies an individual order (i.e., OBR). It is assigned by the placer (ordering application). It identifies an order uniquely among all orders from a particular ordering application. The second through fourth components contain the (filler) assigning authority of the placing application. The (filler) assigning authority is a string of characters that will be uniquely associated with an application. A given institution or group of intercommunicating institutions should establish a unique list of applications that may be potential placers and fillers and assign unique entity identifiers. The components are separated by component delimiters.
TXA-14 - Condition: If corresponding ORC and/or OBR segments are present in the message and ORC-2 or OBR-2 is valued, this field must be blank. If TXA-14 is valued while ORC-2 or OBR-2 is valued it shall be ignored. See message definitions including TXA for further guidance on which ORC/OBR pairs to consider.
(Definition from ARQ.24 in Ch. 10)
Definition: This field is the placer application's order number for the order associated with this scheduling request.
This field is described in detail in Chapter 4, section 4.5.1.2, "ORC-2 – Placer Order Number." It is an optional field, but if a Placer order number is present, then a Filler order number (ARQ-25 – Filler Order Number) must also be present.
(Definition from SCH.26 in Ch. 10)
Definition: This field is the placer application's order number for the order associated with this scheduling filler application response.
This field is described in detail in Section 4.5.1.2. It is an optional field, but if a Placer order number is present, then a Filler order number (Section 10.6.2.27) must also be present. Both this field and the Filler order number below may have been sent as part of the appointment request in the ARQ segment or they may be assigned by the scheduling filler application only.
(Definition from ORC.3 in Ch. 4)
Definition: This field is the order number associated with the filling application. It is a case of the Entity Identifier data type (Section 2.A.28). Its first component is a string that identifies an order detail segment (i.e., ORC segment and associated order detail segment). It is assigned by the order filler (receiving) application. This string must uniquely identify the order (as specified in the order detail segment) from other orders in a particular filling application (e.g., clinical laboratory). This uniqueness must persist over time.
The second through fourth components contain the filler application ID, in the form of the HD data type (see Section 2.A.36, "HD – hierarchic designator"). The second component is a user-defined coded value that uniquely defines the application from other applications on the network. A limit of six (6) characters is suggested but not required. The second component of the filler order number always identifies the actual filler of an order.
A given institution or group of intercommunicating institutions should establish a list of applications that may be potential placers and fillers of orders and assign each a unique application ID. The application ID list becomes one of the institution's master dictionary lists that is documented in Chapter 8. Since third- party applications (those other than the placer and filler of an order) can send and receive ORM and ORR messages, the filler application ID in this field may not be the same as any sending and receiving application on the network (as identified in the MSH segment).
The conditions which make this field required are divided into two main issues. The data in ORC-2 and OBR-2 are logically the same thing: a placer id. The data in ORC-3 and OBR-3 are logically the same thing: the filler id.
From that perspective each message must have either a placer or a filler id with an exception for the case of a "Send Number" control code since its purpose is to request a placer id.
If both ORC and OBR are present in a message, then only one of the Segments must contain the value(s). Note that if both ORC-2 and OBR-2 are valued, then they must be valued the same; as well, if both ORC-3 and OBR-3 are valued, then they must be valued the same. The sending system can include both the filler and the placer number in both the ORC and OBR segments as long as the data is the same between the two segments. It is recommended that the initiating system should provide a unique number for the placer order number when a new order is placed or a unique number for the filler order number when an unsolicited result is initially communicated.
The filler order number (OBR-3 or ORC-3) also uniquely identifies an order and its associated observations. For example, suppose that an institution collects observations from several ancillary applications into a common database and this common database is queried by yet another application for observations. In this case, the filler order number and placer order number transmitted by the common database application would be that of the original filler and placer, respectively, rather than a new one assigned by the common database application.
Similarly, if a third-party application, not the filler or placer, of an order were authorized to modify the status of an order (say, cancel it), the third-party application would send the filler an ORM message containing an ORC segment with ORC-1-order control equal to "CA" and containing the original placer order number and filler order number, rather than assign either itself.
(Definition from OBR.3 in Ch. 4)
Definition: This field is the order number associated with the filling application. This is a permanent identifier for an order and its associated observations. It is a special case of the Entity Identifier data type (see Chapter 2, section 2.A.28, "EI – entity identifier").
The first component is a string that identifies an individual order segment (i.e., ORC segment and associated order detail segment). It is assigned by the order filling (receiving) application. It identifies an order uniquely among all orders from a particular filling application (e.g., clinical laboratory). This uniqueness must persist over time.
The second through fourth components contain the filler application ID, in the form of the HD data type (see section 2.A.36, "HD – hierarchic designator"). The second component is a user-defined coded value that uniquely defines the application from other applications on the network. A limit of six (6) characters is suggested but not required. The second component of the filler order number always identifies the actual filler of an order.
See ORC-3-filler order number for information on when this field must be valued.
The conditions which make this field required are divided into two main issues. The data in ORC-2 and OBR-2 are logically the same thing: a placer id. The data in ORC-3 and OBR-3 are logically the same thing: the filler id.
From that perspective, each message must have either a placer or a filler id with an exception for the case of a "Send Number" control code since its purpose is to request a placer id.
If both ORC and OBR are present in a message, then only one of the Segments must contain the value(s). If both segments contain either ORC-2/OBR-2 or ORC-3/OBR-3, then each pair must be a matching pair. The sending system can include both the filler and the placer number in both the ORC and OBR segments as long as the data is the same between the two segments.
It is recommended that the initiating system should provide a unique number when a new order or unsolicited result is initially communicated.
The filler order number (OBR-3 or ORC-3) also uniquely identifies an order and its associated observations. For example, suppose that an institution collects observations from several ancillary applications into a common database and this common database is queried by yet another application for observations. In this case, the filler order number and placer order number transmitted by the common database application would be that of the original filler and placer, respectively, rather than a new one assigned by the common database application.
Similarly, if a third-party application, not the filler or placer, of an order were authorized to modify the status of an order (say, cancel it), the third-party application would send the filler an ORM message containing an ORC segment with ORC-1-order control equal to "CA" and containing the original placer order number and filler order number, rather than assign either itself.
(Definition from FT1.23 in Ch. 6)
Definition: This field is used when the billing system is requesting observational reporting justification for a charge. This is the number used by a filler to uniquely identify a result. See Chapter 4 for a complete description.
(Definition from OBR.3 in Ch. 7)
Definition: This field is the order number associated with the filling application. This is a permanent identifier for an order and its associated observations. It is a special case of the Entity Identifier data type (see Chapter 2, section 2.A.28, "EI – entity identifier").
The first component is a string that identifies an individual order segment (i.e., ORC segment and associated order detail segment). It is assigned by the order filling (receiving) application. It identifies an order uniquely among all orders from a particular filling application (e.g., clinical laboratory). This uniqueness must persist over time.
The second through fourth components contain the filler application ID, in the form of the HD data type (see section 2.A.36, "HD – hierarchic designator"). The second component is a user-defined coded value that uniquely defines the application from other applications on the network. A limit of six (6) characters is suggested but not required. The second component of the filler order number always identifies the actual filler of an order.
See ORC-3-filler order number for information on when this field must be valued.
The conditions which make this field required are divided into two main issues. The data in ORC-2 and OBR-2 are logically the same thing: a placer id. The data in ORC-3 and OBR-3 are logically the same thing: the filler id.
From that perspective, each message must have either a placer or a filler id with an exception for the case of a "Send Number" control code since its purpose is to request a placer id.
If both ORC and OBR are present in a message, then only one of the Segments must contain the value(s). If both segments contain either ORC-2/OBR-2 or ORC-3/OBR-3, then each pair must be a matching pair. The sending system can include both the filler and the placer number in both the ORC and OBR segments as long as the data is the same between the two segments.
It is recommended that the initiating system should provide a unique number when a new order or unsolicited result is initially communicated.
The filler order number (OBR-3 or ORC-3) also uniquely identifies an order and its associated observations. For example, suppose that an institution collects observations from several ancillary applications into a common database and this common database is queried by yet another application for observations. In this case, the filler order number and placer order number transmitted by the common database application would be that of the original filler and placer, respectively, rather than a new one assigned by the common database application.
Similarly, if a third-party application, not the filler or placer, of an order were authorized to modify the status of an order (say, cancel it), the third-party application would send the filler an ORM message containing an ORC segment with ORC-1-order control equal to "CA" and containing the original placer order number and filler order number, rather than assign either itself.
(Definition from TXA.15 in Ch. 9)
Definition: This field is the order number associated with the filling application. Where a transcription service or similar organization creates the document and uses an internally unique identifier, that number should be inserted in this field. Its first component is a string of characters that identifies an order detail segment (i.e., OBR). This string must uniquely identify the order (as specified in the order detail segment) from other orders in a particular filling application (i.e., transcription service). This uniqueness must persist over time. Where a number is reused over time, a date can be affixed to the non-unique number to make it unique.
The second through fourth components contains the (filler) assigning authority. The (filler) assigning authority is a string of characters that uniquely defines the application from other applications on the network. The second through fourth components of the filler order number always identify the actual filler of an order.
TXA-15 - Condition: If corresponding ORC and/or OBR segments are present in the message and ORC-3 or OBR-3 is valued, this field must be blank. If TXA-14 is valued while ORC-3 or OBR-3 is valued it shall be ignored. See message definitions including TXA for further guidanceon which ORC/OBR pairs to consider.
For further details, please see the definitions provided in Chapter 4, "Orders".
(Definition from ARQ.25 in Ch. 10)
Definition: This field is the order number assigned by the filler application for the order associated with this scheduling request.
This field is described in detail in Chapter 4, section 4.5.1.3, "ORC-3 – Filler Order Number.” It is conditionally mandatory depending on the presence of the Placer order number (ARQ-24 – Placer Order Number). This conditionally mandatory requirement addresses the concern that a Scheduling system cannot and should not create or fill an order. Therefore, an order must have been accepted by the filler application before scheduling the resources associated with that order.
(Definition from SCH.27 in Ch. 10)
Definition: This field is the order number assigned by the filler application for the order associated with this scheduling filler response.
This field is described in detail in Chapter 4, Orders, section 4.5.1.3. It is conditionally mandatory depending on the presence of the placer order number (section 10.6.2.26). This conditionally mandatory requirement addresses the concern that a Scheduling system cannot and should not create or fill an order. Therefore, an order must have been accepted by the order filler application before scheduling the resources associated with that order.
(Definition from OBR.4 in Ch. 4)
Definition: This field contains the identifier code for the requested observation/test/battery. The identifier can come from either a local coding system or industry standards. Examples may be LOINC (emerging as the global standard for observation identifiers), JLAC10, or SNOMED CT. Refer to Table 0612 - Universal Service Identifier in Chapter 2C for valid values.
(Definition from OBR.4 in Ch. 7)
Definition: This field contains the identifier code for the requested observation/test/battery. The identifier can come from either a local coding system or industry standards. Examples may be LOINC (emerging as the global standard for observation identifiers), JLAC10, or SNOMED CT. Refer to Table 0612 - Universal Service Identifier in Chapter 2C for valid values.
(Definition from OM7.2 in Ch. 8)
Definition: This field contains the producer's usual or preferred identification of the test or service.
(Definition from AIS.3 in Ch. 10)
Definition: This field contains an identifier code for a service to be scheduled. This field may contain a universal service identifier describing the observation/test/battery/procedure or other activity that is to be performed during the requested appointment, similar to the universal service identifier defined for the OBR segment in the Order Entry chapter (Chapter 4). This code can be based on local and/or universal codes. The use of universal codes is recommended.
(Definition from TCC.1 in Ch. 13)
Definition: This field identifies the test code that information is being transmitted about. The alternate elements represent the test code identifier that has been assigned by the manufacturer to this particular test code. Refer to Table 0787 - Universal Service Identifier in Chapter 2C for valid values.
(Definition from TCD.1 in Ch. 13)
Definition: This field identifies the test code that information is being transmitted about. Refer to Table 0789 - Universal Service Identifier in Chapter 2C for valid values.
(Definition from OBR.5 in Ch. 4)
Attention: The OBR-5 element was retained for backward compatibility only as of v 2.4 and the detail was withdrawn and removed from the standard as of v 2.7.
(Definition from OBR.5 in Ch. 7)
Attention: The OBR-5 element was retained for backward compatibility only as of v 2.4 and the detail was withdrawn and removed from the standard as of v 2.7.
(Definition from OBR.6 in Ch. 4)
Attention: The OBR-6 element was retained for backward compatibility only as of v 2.4 and the detail was withdrawn and removed from the standard as of v 2.7.
(Definition from OBR.6 in Ch. 7)
Attention: The OBR-6 element was retained for backward compatibility only as of v 2.4 and the detail was withdrawn and removed from the standard as of v 2.7.
(Definition from OBR.7 in Ch. 4)
Definition: This field is the clinically relevant date/time of the observation. In the case of observations taken directly from a subject, it is the actual date and time the observation was obtained. In the case of a specimen-associated study, this field shall represent the date and time the specimen was collected or obtained. (This is a results-only field except when the placer or a third party has already drawn the specimen.) This field is conditionally required. When the OBR is transmitted as part of a report message, the field must be filled in. If it is transmitted as part of a request and a sample has been sent along as part of the request, this field must be filled in because this specimen time is the physiologically relevant date/time of the observation.
(Definition from OBR.7 in Ch. 7)
Definition: This field is the clinically relevant date/time of the observation. In the case of observations taken directly from a subject, it is the actual date and time the observation was obtained. In the case of a specimen-associated study, this field shall represent the date and time the specimen was collected or obtained. (This is a results-only field except when the placer or a third party has already drawn the specimen.) This field is conditionally required. When the OBR is transmitted as part of a report message, the field must be filled in. If it is transmitted as part of a request and a sample has been sent along as part of the request, this field must be filled in because this specimen time is the physiologically relevant date/time of the observation.
(Definition from OBR.8 in Ch. 4)
Definition: This field contains the end date and time of a study or timed specimen collection. If an observation takes place over a substantial period of time, it will indicate when the observation period ended. For observations made at a point in time, it will be null. This is a results field except when the placer or a party other than the filler has already drawn the specimen.
(Definition from OBR.8 in Ch. 7)
Definition: This field contains the end date and time of a study or timed specimen collection. If an observation takes place over a substantial period of time, it will indicate when the observation period ended. For observations made at a point in time, it will be null. This is a results field except when the placer or a party other than the filler has already drawn the specimen.
(Definition from OBR.9 in Ch. 4)
Definition: Deprecated in version 2.9 in favor of SPM-12.
(Definition from OBR.9 in Ch. 7)
Definition: Deprecated in version 2.9 in favor of SPM-12.
(Definition from OBR.10 in Ch. 4)
Definition: This field is retained for backward compatibility only as of v 2.7. The reader is referred to the PRT segment described in Chapter 7.
When a specimen is required for the study, this field will identify the person, department, or facility that collected the specimen. Either name or ID code, or both, may be present. If the person referenced in this field is also referenced in PRT segment, they must contain the same information. However, if there is a difference, then PRT segment takes precedence.
(Definition from OBR.10 in Ch. 7)
Definition: This field is retained for backward compatibility only as of v 2.7. The reader is referred to the PRT segment described in Chapter 7.
When a specimen is required for the study, this field will identify the person, department, or facility that collected the specimen. Either name or ID code, or both, may be present. If the person referenced in this field is also referenced in PRT segment, they must contain the same information. However, if there is a difference, then PRT segment takes precedence.
(Definition from OBR.11 in Ch. 4)
Definition: This field identifies the action to be taken with respect to the specimens that accompany or precede this order. The purpose of this field is to further qualify (when appropriate) the general action indicated by the order control code contained in the accompanying ORC segment. For example, when a new order (ORC – "NW") is sent to the lab, this field would be used to tell the lab whether or not to collect the specimen ("L" or "O"). Refer to HL7 Table 0065 – Specimen Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from OBR.11 in Ch. 7)
Definition: This field identifies the action to be taken with respect to the specimens that accompany or precede this order. The purpose of this field is to further qualify (when appropriate) the general action indicated by the order control code contained in the accompanying ORC segment. For example, when a new order (ORC – "NW") is sent to the lab, this field would be used to tell the lab whether or not to collect the specimen ("L" or "O"). Refer to HL7 Table 0065 – Specimen Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from OBR.12 in Ch. 4)
Definition: This field contains the code and/or text indicating any known or suspected patient or specimen hazards, e.g., patient with active tuberculosis or blood from a hepatitis patient. Either code and/or text may be absent. However, the code is always placed in the first component position and any free text in the second component. Thus, free text without a code must be preceded by a component delimiter. Refer to Table 0613 - Danger Code in Chapter 2C for valid values.
(Definition from OBR.12 in Ch. 7)
Definition: This field contains the code and/or text indicating any known or suspected patient or specimen hazards, e.g., patient with active tuberculosis or blood from a hepatitis patient. Either code and/or text may be absent. However, the code is always placed in the first component position and any free text in the second component. Thus, free text without a code must be preceded by a component delimiter. Refer to Table 0613 - Danger Code in Chapter 2C for valid values.
(Definition from OBR.13 in Ch. 4)
Definition: This field contains additional clinical information about the patient or specimen. This field is used to report the supporting and/or suspected diagnosis and clinical findings on requests for interpreted diagnostic studies where a simple text string or code is sufficient. This field could use all appropriate code sets including SNOMED to message Relevant Clinical Information. If more information is needed, such as date/time of the observation, who observed it, abnormal ranges, etc., or must be provided in further structured format, e.g., structured numeric with units of measure encoded, the Observation/Result group following the OBR should be used. Examples include reporting the amount of inspired carbon dioxide for blood gasses, the point in the menstrual cycle for cervical pap tests, and other conditions that influence test interpretations. Refer to HL7 Table 0916 – Relevant Clinical Information in Chapter 2C, Code Tables, for valid values.
(Definition from OBR.13 in Ch. 7)
Definition: This field contains additional clinical information about the patient or specimen. This field is used to report the supporting and/or suspected diagnosis and clinical findings on requests for interpreted diagnostic studies where a simple text string or code is sufficient. This field could use all appropriate code sets including SNOMED to message Relevant Clinical Information. If more information is needed, such as date/time of the observation, who observed it, abnormal ranges, etc., or must be provided in further structured format, e.g., structured numeric with units of measure encoded, the Observation/Result group following the OBR should be used. Examples include reporting the amount of inspired carbon dioxide for blood gasses, the point in the menstrual cycle for cervical pap tests, and other conditions that influence test interpretations. Refer to HL7 Table 0916 – Relevant Clinical Information in Chapter 2C, Code Tables, for valid values.
(Definition from OBR.14 in Ch. 4)
Attention: The OBR-14 element 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. See SPM in Chapter 7.
(Definition from OBR.14 in Ch. 7)
Attention: The OBR-14 element 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. See SPM in Chapter 7.
(Definition from SPM.18 in Ch. 7)
Definition: The specimen received date/time is the time that the specimen is received at the diagnostic service facility. The actual time that is recorded is based on how specimen receipt is managed and may correspond to the time the sample is logged in. This is fundamentally different from SPM-17 Specimen Collection date/time.
(Definition from OBR.15 in Ch. 4)
Attention: The OBR-15 element 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. See SPM in Chapter 7.
(Definition from OBR.15 in Ch. 7)
Attention: The OBR-15 element 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. See SPM in Chapter 7.
(Definition from SAC.6 in Ch. 13)
Attention: This field was deprecated and retained for backward compatibilityonly as of v2.5 and withdrawn and removed as of v2.7.
(Definition from TCC.3 in Ch. 13)
Attention: As of version 2.5 this field was deprecated and retained for backward compatibility only and withdrawn as of v2.7.
(Definition from ORC.12 in Ch. 4)
Definition: This field was retained for backward compatibility only as of v 2.7 and the detail was withdrawn and removed from the standard as of v 2.9. The reader is referred to the PRT segment described in Chapter 7.
(Definition from OBR.16 in Ch. 4)
Definition: This field was retained for backward compatibility only as of v 2.7 and the detail was withdrawn and removed from the standard as of v 2.9. The reader is referred ot the PRT segment as described in Chapter 7.
(Definition from OBR.16 in Ch. 7)
Definition: This field was retained for backward compatibility only as of v 2.7 and the detail was withdrawn and removed from the standard as of v 2.9. The reader is referred ot the PRT segment as described in Chapter 7.
(Definition from OBR.17 in Ch. 4)
Definition: This field contains the telephone number for reporting a status or a result using the standard format with extension and/or beeper number when applicable.
(Definition from OBR.17 in Ch. 7)
Definition: This field contains the telephone number for reporting a status or a result using the standard format with extension and/or beeper number when applicable.
(Definition from OBR.18 in Ch. 4)
Definition: This field is user field #1. Text sent by the placer will be returned with the results.
(Definition from OBR.18 in Ch. 7)
Definition: This field is user field #1. Text sent by the placer will be returned with the results.
(Definition from OBR.19 in Ch. 4)
Definition: This field is similar to placer field #1.
(Definition from OBR.19 in Ch. 7)
Definition: This field is similar to placer field #1.
(Definition from OBR.20 in Ch. 4)
Definition: This field is definable for any use by the filler (diagnostic service).
(Definition from OBR.20 in Ch. 7)
Definition: This field is definable for any use by the filler (diagnostic service).
(Definition from OBR.21 in Ch. 4)
Definition: This field is similar to filler field #1.
(Definition from OBR.21 in Ch. 7)
Definition: This field is similar to filler field #1.
(Definition from OBR.22 in Ch. 4)
Definition: This field specifies the date/time when the results were reported or status changed. This conditional field is required whenever the OBR-25 is valued. This field is used to indicate the date and time that the results are composed into a report and released, or that a status, as defined in ORC-5 order status, is entered or changed. (This is a results field only.) When other applications (such as office or clinical database applications) query the laboratory application for un-transmitted results, the information in this field may be used to control processing on the communications link. Usually, the ordering service would want only those results for which the reporting date/time is greater than the date/time the inquiring application last received results.
(Definition from OBR.22 in Ch. 7)
Definition: This field specifies the date/time when the results were reported or status changed. This conditional field is required whenever the OBR-25 is valued. This field is used to indicate the date and time that the results are composed into a report and released, or that a status, as defined in ORC-5 order status, is entered or changed. (This is a results field only.) When other applications (such as office or clinical database applications) query the laboratory application for un-transmitted results, the information in this field may be used to control processing on the communications link. Usually, the ordering service would want only those results for which the reporting date/time is greater than the date/time the inquiring application last received results.
(Definition from OBR.23 in Ch. 4)
Definition: This field is the charge to the ordering entity for the studies performed when applicable. The first component is a dollar amount when known by the filler. The second is a charge code when known by the filler (results only).
(Definition from OBR.23 in Ch. 7)
Definition: This field is the charge to the ordering entity for the studies performed when applicable. The first component is a dollar amount when known by the filler. The second is a charge code when known by the filler (results only).
(Definition from OBR.24 in Ch. 4)
Definition: This field is the section of the diagnostic service where the observation was performed. If the study was performed by an outside service, the identification of that service should be recorded here. Refer to HL7 Table 0074 – Diagnostic Service Section ID in Chapter 2C, Code Tables, for valid entries.
(Definition from OBR.24 in Ch. 7)
Definition: This field is the section of the diagnostic service where the observation was performed. If the study was performed by an outside service, the identification of that service should be recorded here. Refer to HL7 Table 0074 – Diagnostic Service Section ID in Chapter 2C, Code Tables, for valid entries.
(Definition from OM1.49 in Ch. 8)
Definition: This field is the section of the diagnostic service where the observation was performed. If the study was performed by an outside service, the identification of that service should be recorded here. Refer to HL7 Table 0074 – Diagnostic Service Section ID in Chapter 2C, Code Tables, for valid entries. Same as OBR-24.
(Definition from OBR.25 in Ch. 4)
Definition: This field contains the status of results for this order. This conditional field is required whenever the OBR is contained in a report message. It is not required as part of an initial order.
There are two methods of sending status information. If the status is that of the entire order, use ORC-15-order effective date/time and ORC-5-order status. If the status pertains to the order detail segment, use OBR-25-result status and OBR-22-results rpt/status chng – date/time. If both are present, the OBR values override the ORC values.
This field would typically be used in a response to an order status query where the level of detail requested does not include the OBX segments. When the individual status of each result is necessary, OBX-11-observ result status may be used. Refer to HL7 Table 0123 – Result Status in Chapter 2C, Code Tables, for valid entries.
(Definition from OBR.25 in Ch. 7)
Definition: This field contains the status of results for this order. This conditional field is required whenever the OBR is contained in a report message. It is not required as part of an initial order.
There are two methods of sending status information. If the status is that of the entire order, use ORC-15-order effective date/time and ORC-5-order status. If the status pertains to the order detail segment, use OBR-25-result status and OBR-22-results rpt/status chng – date/time. If both are present, the OBR values override the ORC values.
This field would typically be used in a response to an order status query where the level of detail requested does not include the OBX segments. When the individual status of each result is necessary, OBX-11-observ result status may be used. Refer to HL7 Table 0123 – Result Status in Chapter 2C, Code Tables, for valid entries.
(Definition from OBR.26 in Ch. 4)
Definition: This field is defined to make it available for other types of linkages (e.g., toxicology). This important information, together with the information in OBR-29-Parent Result Obersvation Identifier and OBR-54 Parent Order, uniquely identifies the parent result's OBX segment related to this order. The value of this OBX segment in the parent result is the organism or chemical species about which this battery reports, or the specific result for which this order or observation is a reflex. For example, if the current battery is an antimicrobial susceptibility, the parent results identified OBX contains a result which identifies the organism on which the susceptibility was run. This indirect linkage is preferred because the name of the organism in the parent result may undergo several preliminary values prior to finalization. In the case of a reflex order, if it is necessary to point to the specific result value for which it is in response, OBR-26 enables pointing to that specific OBX segment.
The third component may be used to record the name of the microorganism identified by the parent result directly. The organism in this case should be identified exactly as it is in the parent culture.
We emphasize that this field does not take the entire result field from the parent. It is meant only for the text name of the organism or chemical subspecies identified. This field is included only to provide a method for linking back to the parent result for those systems that could not generate unambiguous Observation IDs and sub-IDs.
This field is present only when the parent result is identified by OBR-29- Result Observation Identifieror OBR-54, Parent Order, and the parent spawns child orders or results for each of many results. (See Chapter 7 for more details about this linkage.)
A second mode of conveying this information is to use a standard observation result segment (OBX). If more than one organism is present, OBX-4-observation sub-ID is used to distinguish them. In this case, the first OBX with subID N will contain a value identifying the Nth microorganism, and each additional OBX with subID N will contain susceptibility values for a given antimicrobial test on this organism.
(Definition from OBR.26 in Ch. 7)
Definition: This field is defined to make it available for other types of linkages (e.g., toxicology). This important information, together with the information in OBR-29-Parent Result Obersvation Identifier and OBR-54 Parent Order, uniquely identifies the parent result's OBX segment related to this order. The value of this OBX segment in the parent result is the organism or chemical species about which this battery reports, or the specific result for which this order or observation is a reflex. For example, if the current battery is an antimicrobial susceptibility, the parent results identified OBX contains a result which identifies the organism on which the susceptibility was run. This indirect linkage is preferred because the name of the organism in the parent result may undergo several preliminary values prior to finalization. In the case of a reflex order, if it is necessary to point to the specific result value for which it is in response, OBR-26 enables pointing to that specific OBX segment.
The third component may be used to record the name of the microorganism identified by the parent result directly. The organism in this case should be identified exactly as it is in the parent culture.
We emphasize that this field does not take the entire result field from the parent. It is meant only for the text name of the organism or chemical subspecies identified. This field is included only to provide a method for linking back to the parent result for those systems that could not generate unambiguous Observation IDs and sub-IDs.
This field is present only when the parent result is identified by OBR-29- Result Observation Identifieror OBR-54, Parent Order, and the parent spawns child orders or results for each of many results. (See Chapter 7 for more details about this linkage.)
A second mode of conveying this information is to use a standard observation result segment (OBX). If more than one organism is present, OBX-4-observation sub-ID is used to distinguish them. In this case, the first OBX with subID N will contain a value identifying the Nth microorganism, and each additional OBX with subID N will contain susceptibility values for a given antimicrobial test on this organism.
(Definition from ORC.7 in Ch. 4)
Attention: The ORC-7 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 and TQ2 segments described in sections 4.5.4 and 4.5.5, respectively.
(Definition from OBR.27 in Ch. 4)
Attention: The OBR-27 element 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.
(Definition from RXE.1 in Ch. 4A)
Attention: The RXE-1 field was retained for backward compatibilty only as of v 2.5 and the detail was withdrawn and removed from the standard as of v 2.7.
(Definition from RXG.3 in Ch. 4A)
Attention: The RXG-3 field was retained for backward compatibilty only as of v 2.5 and the detail was withdrawn and removed from the standard as of v 2.7.
Note: The contents of fields 3-8 should be identical to the comparable fields in the RXE (RXE-2 thru 5).
(Definition from OBR.27 in Ch. 7)
Attention: The OBR-27 element 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.
(Definition from OBR.28 in Ch. 4)
Definition: This field was retained for backward compatibility only as of v 2.7 and the detail was withdrawn and removed from the standard as of v 2.9. Additional capabilities are now available through thePRT segment following the OBR using the "RCT" (Results Copy To) value in PRT-4 (Participation) from HL7 Table 912 - Participation in Chapter 2C, Code Tables, and referencing the appropriate participant information using other PRT Fields. The PRT segment is further described in Chapter 7 Section 7.3.4 "PRT – Participation Information Segment".
(Definition from OBR.28 in Ch. 7)
Definition: This field was retained for backward compatibility only as of v 2.7 and the detail was withdrawn and removed from the standard as of v 2.9. Additional capabilities are now available through thePRT segment following the OBR using the "RCT" (Results Copy To) value in PRT-4 (Participation) from HL7 Table 912 - Participation in Chapter 2C, Code Tables, and referencing the appropriate participant information using other PRT Fields. The PRT segment is further described in Chapter 7 Section 7.3.4 "PRT – Participation Information Segment".
(Definition from OBR.29 in Ch. 4)
Definition: This field relates a child result to its parent result when a parent child result relationship exists. This field uniquely identifies the order number of the parent result; no other information is required to link the child result with its parent result.
(Definition from OBR.29 in Ch. 7)
Definition: This field relates a child result to its parent result when a parent child result relationship exists. This field uniquely identifies the order number of the parent result; no other information is required to link the child result with its parent result.
(Definition from OBR.30 in Ch. 4)
Definition: This field identifies how (or whether) to transport a patient, when applicable. Refer to HL7 Table 0124 – Transportation Mode in Chapter 2C, Code Tables, for valid codes.
(Definition from OBR.30 in Ch. 7)
Definition: This field identifies how (or whether) to transport a patient, when applicable. Refer to HL7 Table 0124 – Transportation Mode in Chapter 2C, Code Tables, for valid codes.
(Definition from OBR.31 in Ch. 4)
Definition: This field is the code or text using the conventions for coded fields given in the Control chapter (Chapter 2). This is required for some studies to obtain proper reimbursement.
Refer HL7 Table 0951 – Reason for Study in Chapter 2C, Code Tables.
(Definition from OBR.31 in Ch. 7)
Definition: This field is the code or text using the conventions for coded fields given in the Control chapter (Chapter 2). This is required for some studies to obtain proper reimbursement.
Refer HL7 Table 0951 – Reason for Study in Chapter 2C, Code Tables.
(Definition from OBR.32 in Ch. 4)
Definition: This field is retained for backward compatibility only as of v 2.6 and the detail was withdrawn and removed from the standard as of v 2.9.. The reader is referred to the PRT segment described in Chapter 7.
(Definition from OBR.32 in Ch. 7)
Definition: This field is retained for backward compatibility only as of v 2.6 and the detail was withdrawn and removed from the standard as of v 2.9.. The reader is referred to the PRT segment described in Chapter 7.
(Definition from OBR.33 in Ch. 4)
Definition: This field was retained for backward compatibility only as of v 2.6 and the detail was withdrawn and removed from the standard as of v 2.9.. The reader is referred to the PRTsegment used relative to OBR as described in section 4.5.3.32, "Principal Result Interpreter."
(Definition from OBR.33 in Ch. 7)
Definition: This field was retained for backward compatibility only as of v 2.6 and the detail was withdrawn and removed from the standard as of v 2.9.. The reader is referred to the PRTsegment used relative to OBR as described in section 4.5.3.32, "Principal Result Interpreter."
(Definition from OBR.34 in Ch. 4)
Definition: This field was retained for backward compatibility only as of v 2.6 and the detail was withdrawn and removed from the standard as of v 2.9. The reader is referred to the PRTsegment used relative to OBR as described in section 4.5.3.32, "Principal Result Interpreter."
(Definition from OBR.34 in Ch. 7)
Definition: This field was retained for backward compatibility only as of v 2.6 and the detail was withdrawn and removed from the standard as of v 2.9. The reader is referred to the PRTsegment used relative to OBR as described in section 4.5.3.32, "Principal Result Interpreter."
(Definition from OBR.35 in Ch. 4)
Definition: This field was retained for backward compatibility only as of v 2.6 and the detail was withdrawn and removed from the standard as of v 2.9. The reader is referred to the PRTsegment used relative to OBR as described in section 4.5.3.32, "Principal Result Interpreter."
(Definition from OBR.35 in Ch. 7)
Definition: This field was retained for backward compatibility only as of v 2.6 and the detail was withdrawn and removed from the standard as of v 2.9. The reader is referred to the PRTsegment used relative to OBR as described in section 4.5.3.32, "Principal Result Interpreter."
(Definition from OBR.36 in Ch. 4)
Definition: This field is the date/time the filler scheduled an observation, when applicable (e.g., action code in OBR-11-specimen action code = "S"). This is a result of a request to schedule a particular test and provides a way to inform the placer of the date/time a study is scheduled (result only).
(Definition from OBR.36 in Ch. 7)
Definition: This field is the date/time the filler scheduled an observation, when applicable (e.g., action code in OBR-11-specimen action code = "S"). This is a result of a request to schedule a particular test and provides a way to inform the placer of the date/time a study is scheduled (result only).
(Definition from OBR.37 in Ch. 4)
Definition: This field identifies the number of containers for a given sample. For sample receipt verification purposes; may be different from the total number of samples which accompany the order.
(Definition from OBR.37 in Ch. 7)
Definition: This field identifies the number of containers for a given sample. For sample receipt verification purposes; may be different from the total number of samples which accompany the order.
(Definition from OBR.38 in Ch. 4)
Definition: This field is the means by which a sample reaches the diagnostic service provider. This information is to aid the lab in scheduling or interpretation of results. Possible answers: routine transport van, public postal service, etc. If coded, requires a user-defined table. Refer to Table 0614 - Transport Logistics of Collected Sample in Chapter 2C for valid values.
(Definition from OBR.38 in Ch. 7)
Definition: This field is the means by which a sample reaches the diagnostic service provider. This information is to aid the lab in scheduling or interpretation of results. Possible answers: routine transport van, public postal service, etc. If coded, requires a user-defined table. Refer to Table 0614 - Transport Logistics of Collected Sample in Chapter 2C for valid values.
(Definition from OBR.39 in Ch. 4)
Definition: This field is for reporting additional comments related to the sample. If coded, requires a user-defined table. If only free text is reported, it is placed in the second component with a null in the first component, e.g., ^difficulty clotting after venipuncture and ecchymosis. Refer to Table 0619 - Collector's Comment in Chapter 2C for valid values.
(Definition from OBR.39 in Ch. 7)
Definition: This field is for reporting additional comments related to the sample. If coded, requires a user-defined table. If only free text is reported, it is placed in the second component with a null in the first component, e.g., ^difficulty clotting after venipuncture and ecchymosis. Refer to Table 0619 - Collector's Comment in Chapter 2C for valid values.
(Definition from OBR.40 in Ch. 4)
Definition: This field is an indicator of who is responsible for arranging transport to the planned diagnostic service. Examples: Requester, Provider, Patient. If coded, requires a user-defined table. Refer to Table 0620 - Transport Arrangement Responsibility in Chapter 2C for valid values.
(Definition from OBR.40 in Ch. 7)
Definition: This field is an indicator of who is responsible for arranging transport to the planned diagnostic service. Examples: Requester, Provider, Patient. If coded, requires a user-defined table. Refer to Table 0620 - Transport Arrangement Responsibility in Chapter 2C for valid values.
(Definition from OBR.41 in Ch. 4)
Definition: This field is an indicator of whether transport arrangements are known to have been made. Refer to HL7 Table 0224 – Transport Arranged in Chapter 2C, Code Tables, for valid codes.
(Definition from OBR.41 in Ch. 7)
Definition: This field is an indicator of whether transport arrangements are known to have been made. Refer to HL7 Table 0224 – Transport Arranged in Chapter 2C, Code Tables, for valid codes.
(Definition from OBR.42 in Ch. 4)
Definition: This field is an indicator that the patient needs to be escorted to the diagnostic service department. Note: The nature of the escort requirements should be stated in OBR-43-planned patient transport comment. See HL7 Table 0225 – Escort Required in Chapter 2C, Code Tables, for valid values.
(Definition from OBR.42 in Ch. 7)
Definition: This field is an indicator that the patient needs to be escorted to the diagnostic service department. Note: The nature of the escort requirements should be stated in OBR-43-planned patient transport comment. See HL7 Table 0225 – Escort Required in Chapter 2C, Code Tables, for valid values.
(Definition from OBR.43 in Ch. 4)
Definition: This field is the code or free text comments on special requirements for the transport of the patient to the diagnostic service department. If coded, requires a user-defined table. Refer to Table 0621 - Planned Patient Transport Comment in Chapter 2C for valid values.
(Definition from OBR.43 in Ch. 7)
Definition: This field is the code or free text comments on special requirements for the transport of the patient to the diagnostic service department. If coded, requires a user-defined table. Refer to Table 0621 - Planned Patient Transport Comment in Chapter 2C for valid values.
(Definition from OBR.44 in Ch. 4)
Definition: This field contains a unique identifier assigned to the procedure, if any, associated with the charge. Refer to Externally-defined table 0088 – Procedure code in Chapter 2C, Code Tables, for suggested values. This field is a coded data type for compatibility with clinical and ancillary systems.
As of version 2.6, applicable external coding systems include those in the referenced table. If the code set used is in the referenced table, then the coding scheme designation in the table shall be used.
(Definition from FT1.25 in Ch. 6)
Definition: This field contains a unique identifier assigned to the procedure, if any, associated with the charge. Refer to Externally-defined Table 0088 - Procedure Code in Chapter 2C, Code Tables, for suggested values. This field is a coded data type for compatibility with clinical and ancillary systems.
As of v 2.6, the known applicable external coding systems include those in the table below. If the code set you are using is in this table, then you must use that designation.
Code |
Description |
Comment / Source |
C4 |
CPT-4 |
American Medical Association, P.O. Box 10946, Chicago IL 60610. |
C5 |
CPT-5 |
(under development – same contact as above) |
HCPCS |
CMS (formerly HCFA) Common Procedure Coding System |
HCPCS: contains codes for medical equipment, injectable drugs, transportation services, and other services not found in CPT4. |
HPC |
CMS (formerly HCFA )Procedure Codes (HCPCS) |
Health Care Financing Administration (HCFA) Common Procedure Coding System (HCPCS) including modifiers. |
I10P |
ICD-10 Procedure Codes |
Procedure Coding System (ICD-10-PCS.) See http://www/hcfa.gov/stats/icd10.icd10.htm for more information. |
(Definition from PR1.3 in Ch. 6)
Definition: This field contains a unique identifier assigned to the procedure. Refer to Externally-defined Table 0088 - Procedure Code in Chapter 2C, Code Tables, for suggested values. This field is a CNE data type for compatibility with clinical and ancillary systems.
(Definition from OBR.44 in Ch. 7)
Definition: This field contains a unique identifier assigned to the procedure, if any, associated with the charge. Refer to Externally-defined table 0088 – Procedure code in Chapter 2C, Code Tables, for suggested values. This field is a coded data type for compatibility with clinical and ancillary systems.
As of version 2.6, applicable external coding systems include those in the referenced table. If the code set used is in the referenced table, then the coding scheme designation in the table shall be used.
(Definition from CDM.7 in Ch. 8)
Definition: This field contains the procedure code for procedure, if any, associated with this charge description. Repeating field allows for different procedure coding systems such as CPT4, ICD9. Coded entry made up of code plus coding schema. Refer to Externally-defined Table 0088 - Procedure Code in Chapter 2C, Code Tables, for suggested values.
(Definition from IIM.14 in Ch. 17)
Definition: This field contains a unique identifier assigned to the service item, if any, associated with the charge. In the United States this is often the HCPCS code. Refer to Externally Defined Table 0088 - Procedure Code in Chapter 2C, Code Tables, for suggested values. This field is a CNE data type for compatibility with clinical and ancillary systems.
As of v2.6, the known applicable external coding systems include those in the table below. If the code set you are using is in this table, then you must use that designation.
Coding System |
Description |
Comment |
C4 |
CPT-4 |
American Medical Association, P.O. Box 10946, Chicago IL 60610. |
C5 |
CPT-5 |
(under development – same contact as above) |
HCPCS |
CMS (formerly HCFA) Common Procedure Coding System |
HCPCS: contains codes for medical equipment, injectable drugs, transportation services, and other services not found in CPT4. |
HPC |
CMS (formerly HCFA) Procedure Codes (HCPCS) |
Health Care Financing Administration (HCFA) Common Procedure Coding System (HCPCS) including modifiers. |
(Definition from ITM.27 in Ch. 17)
Definition: This field contains a unique identifier assigned to the service item, if any, associated with the charge. In the United States this is often the HCPCS code. Refer to Externally defined Table 0088 - Procedure code for suggested values. This field is a CNE data type for compatibility with clinical and ancillary systems. Refer to HL7 Table 0088 – Procedure Coding Systems in Chapter 2C, Code Tables, for valid values.
As of v2.6, the known applicable external coding systems include those in the table below. If the code set you are using is in this table, then you must use that designation.
(Definition from SCD.32 in Ch. 17)
Definition: The unique identifier indicating the type of procedure performed on the patient with the supplies being sterilized.
Refer to HL7 Table 0088 – Procedure Code in Chapter 2C, Code Tables, for suggested values.
As of v2.6, the known applicable external coding systems include those in the referenced table. If the code set you are using is in this table, then you must use that designation.
(Definition from OBR.45 in Ch. 4)
Definition: This field contains the procedure code modifier to the procedure code reported in OBR-44-procedure code, when applicable. Procedure code modifiers are defined by regulatory agencies such as CMS and the AMA. Multiple modifiers may be reported. The modifiers are sequenced in priority according to user entry. In the USA, this is a requirement of the UB and the 1500 claim forms. Multiple modifiers are allowed and the order placed on the form affects reimbursement. Refer to Externally- defined table 0340 – Procedure code modifier in Chapter 2C, Code Tables, for suggested values.
Usage Rule: This field can only be used if OBR-44 – procedure code contains certain procedure codes that require a modifier in order to be billed or performed. For example, HCPCS codes that require a modifier to be precise.
As of version 2.6, applicable external coding systems include those in the referenced table. If the code set used is in the referenced table, then the coding scheme designation in the table shall be used.
(Definition from FT1.26 in Ch. 6)
Definition: This field contains the procedure code modifier to the procedure code reported in FT1-25 - Procedure Code, when applicable. Procedure code modifiers are defined by regulatory agencies such as CMS and the AMA. Multiple modifiers may be reported. The modifiers are sequenced in priority according to user entry. This is a requirement of the UB and the 1500 claim forms. Multiple modifiers are allowed and the order placed on the form affects reimbursement. Refer to Externally-defined Table 0340 - Procedure Code Modifier in Chapter 2C, Code Tables, for suggested values.
Usage Rule: This field can only be used if FT1-25 - Procedure Code contains certain procedure codes that require a modifier in order to be billed or performed. For example, HCPCS codes that require a modifier to be precise.
As of v 2.6, the known applicable external coding systems include those in the table below. If the code set you are using is in this table, then you must use that designation.
Code |
Description |
Comment / Source |
CPTM |
CPT Modifier Code |
Available for the AMA at the address listed for CPT above. These codes are found in Appendix A of CPT 2000 Standard Edition. (CPT 2000 Standard Edition, American Medical Association, Chicago, IL). |
HPC |
CMS (formerly HCFA )Procedure Codes (HCPCS) |
Health Care Financing Administration (HCFA) Common Procedure Coding System (HCPCS) including modifiers. |
I10P |
ICD-10 Procedure Codes |
Procedure Coding System (ICD-10-PCS.) See http://www/hcfa.gov/stats/icd10.icd10.htm for more information. |
I9C |
ICD-9CM |
Commission on Professional and Hospital Activities, 1968 Green Road, Ann Arbor, MI 48105 (includes all procedures and diagnostic tests). |
ICD10AM |
ICD-10 Australian modification |
|
ICD10CA |
ICD-10 Canada |
(Definition from PR1.16 in Ch. 6)
Definition: This field contains the procedure code modifier to the procedure code reported in field 3, when applicable. Procedure code modifiers are defined by regulatory agencies such as CMS and the AMA. Multiple modifiers may be reported. Refer to Externally-defined Table 0340 - Procedure Code Modifier in Chapter 2C, Code Tables, for suggested values.
(Definition from OBR.45 in Ch. 7)
Definition: This field contains the procedure code modifier to the procedure code reported in OBR-44-procedure code, when applicable. Procedure code modifiers are defined by regulatory agencies such as CMS and the AMA. Multiple modifiers may be reported. The modifiers are sequenced in priority according to user entry. In the USA, this is a requirement of the UB and the 1500 claim forms. Multiple modifiers are allowed and the order placed on the form affects reimbursement. Refer to Externally- defined table 0340 – Procedure code modifier in Chapter 2C, Code Tables, for suggested values.
Usage Rule: This field can only be used if OBR-44 – procedure code contains certain procedure codes that require a modifier in order to be billed or performed. For example, HCPCS codes that require a modifier to be precise.
As of version 2.6, applicable external coding systems include those in the referenced table. If the code set used is in the referenced table, then the coding scheme designation in the table shall be used.
(Definition from IIM.15 in Ch. 17)
Definition: This field contains the procedure code modifier to the procedure code reported in IIM-14 Procedure Code, when applicable. Procedure code modifiers are defined by USA regulatory agencies such as CMS and the AMA. Multiple modifiers may be reported. Refer to Externally defined Table 0340 - Procedure Code Modifier in Chapter 2C, Code Tables, for suggested values.
As of v2.6, the known applicable external coding systems include those in the table below. If the code set you are using is in this table, then you must use that designation.
(Definition from ITM.28 in Ch. 17)
Definition: This field contains the procedure code modifier to the procedure code reported in ITM-27, Procedure Code, when applicable. Procedure code modifiers are defined by USA regulatory agencies such as CMS and the AMA. Multiple modifiers may be reported. Refer to Externally-defined Table 0340 - Procedure Code Modifier in Chapter 2C, Code Tables, for suggested values.
(Definition from OBR.46 in Ch. 4)
Definition: This field contains supplemental service information sent from the placer system to the filler system for the universal procedure code reported in OBR-4 Universal Service ID. This field will be used to provide ordering information detail that is not available in other specific fields in the OBR segment. Multiple supplemental service information elements may be reported. Refer to User-defined Table 0411 - Supplemental service information values in Chapter 2C, Code Tables.
This field can be used to describe details such as whether study is to be done on the right or left, for example, where the study is of the arm and the order master file does not distinguish right from left, or whether the study is to be done with or without contrast (when the order master file does not make such distinctions).
(Definition from OBR.46 in Ch. 7)
Definition: This field contains supplemental service information sent from the placer system to the filler system for the universal procedure code reported in OBR-4 Universal Service ID. This field will be used to provide ordering information detail that is not available in other specific fields in the OBR segment. Multiple supplemental service information elements may be reported. Refer to User-defined Table 0411 - Supplemental service information values in Chapter 2C, Code Tables.
This field can be used to describe details such as whether study is to be done on the right or left, for example, where the study is of the arm and the order master file does not distinguish right from left, or whether the study is to be done with or without contrast (when the order master file does not make such distinctions).
(Definition from AIS.11 in Ch. 10)
Definition: This field contains supplemental service and/or logistical information sent from the placer system to the filler system for the universal procedure code reported in field AIS-3. This field will be used to provide scheduling information detail that is not available in other, specific fields in the AIS segment. Multiple supplemental service information elements may be reported. Refer to User-defined Table 0411 – Supplemental Service Information Values in Chapter 2C, Code Tables, for valid values.
(Definition from OBR.47 in Ch. 4)
Definition: This field contains supplemental service information sent from the filler system to the placer system for the procedure code reported in OBR-4 Universal Service ID. This field will be used to report ordering information detail that is not available in other specific fields in the OBR segment. Typically it will reflect the same information as was sent to the filler system in OBR-46-Placer supplemental service information unless the order was modified, in which case the filler system will report what was actually performed using this field. Multiple supplemental service information elements may be reported. Refer to User-Defined Table 0411 - Supplemental Service Information Values in Chapter 2C, Code Tables.
This field can be used to describe details such as whether study is to be done on the right or left, for example, where the study is of the arm and the order master file does not distinguish right from left, or whether the study is to be done with or without contrast (when the order master file does not make such distinctions).
(Definition from OBR.47 in Ch. 7)
Definition: This field contains supplemental service information sent from the filler system to the placer system for the procedure code reported in OBR-4 Universal Service ID. This field will be used to report ordering information detail that is not available in other specific fields in the OBR segment. Typically it will reflect the same information as was sent to the filler system in OBR-46-Placer supplemental service information unless the order was modified, in which case the filler system will report what was actually performed using this field. Multiple supplemental service information elements may be reported. Refer to User-Defined Table 0411 - Supplemental Service Information Values in Chapter 2C, Code Tables.
This field can be used to describe details such as whether study is to be done on the right or left, for example, where the study is of the arm and the order master file does not distinguish right from left, or whether the study is to be done with or without contrast (when the order master file does not make such distinctions).
(Definition from AIS.12 in Ch. 10)
Definition: This field contains supplemental service and/or logistical information sent from the filler system to the placer system for the procedure code reported in field AIS-3. This field will be used to report scheduling information details that is not available in other, specific fields in the AIS segment. Typically it will reflect the same information as was sent to the filler system in AIS-11-Placer Supplemental information unless the scheduling was modified in which case the filler system will report what was actually performed using this field. Multiple supplemental service information elements may be reported. Refer to User-defined Table 0411 - Supplemental service information values in Chapter 2C, Code Tables, for valid values..
(Definition from OBR.48 in Ch. 4)
Definition: This field is used to document why the procedure found in OBR-44 - Procedure Code is a duplicate of one ordered/charged previously for the same patient within the same date of service and has been determined to be medically necessary. The reason may be coded or it may be a free text entry.
This field is intended to provide financial systems information on who to bill for duplicate procedures.
Refer to User-Defined Table 0476 – Medically Necessary Duplicate Procedure Reason in Chapter 2C, Code Tables, for suggested values.
(Definition from FT1.28 in Ch. 6)
Definition: This field is used to document why the procedure found in FT1-25 - Procedure Code is a duplicate of one ordered/charged previously for the same patient within the same date of service and has been determined to be medically necessary. The reason may be coded or it may be a free text entry. This field is intended to provide financial systems information on who to bill for duplicate procedures. Refer to User-Defined Table 0476 – Medically Necessary Duplicate Procedure Reason in Chapter 2C, Code Tables, for suggested values.
(Definition from OBR.48 in Ch. 7)
Definition: This field is used to document why the procedure found in OBR-44 - Procedure Code is a duplicate of one ordered/charged previously for the same patient within the same date of service and has been determined to be medically necessary. The reason may be coded or it may be a free text entry.
This field is intended to provide financial systems information on who to bill for duplicate procedures.
Refer to User-Defined Table 0476 – Medically Necessary Duplicate Procedure Reason in Chapter 2C, Code Tables, for suggested values.
(Definition from OBR.49 in Ch. 4)
Definition: Transmits information regarding the handling of the result. For example, an order may specify that the result (e.g., an x-ray film) should be given to the patient for return to the requestor. Refer to HL7 Table 0507 - Observation Result Handling in Chapter 2C, Code Tables, for values. If this field is not populated or if it includes value "CC^Copies Requested", then routine handling is implied and PRT segments assocatied with this OBR with PRT-4 value of "RCT^Result Copies To" identify additional recipients for the results. When this field includes the value "BCC^Blind Copy", those PRT segments, which are included in the order message and in the observation result message sent to the requestor, shall not be included in the observation result messages sent to the copied recipients.
(Definition from OBR.49 in Ch. 7)
Definition: Transmits information regarding the handling of the result. For example, an order may specify that the result (e.g., an x-ray film) should be given to the patient for return to the requestor. Refer to HL7 Table 0507 - Observation Result Handling in Chapter 2C, Code Tables, for values. If this field is not populated or if it includes value "CC^Copies Requested", then routine handling is implied and PRT segments assocatied with this OBR with PRT-4 value of "RCT^Result Copies To" identify additional recipients for the results. When this field includes the value "BCC^Blind Copy", those PRT segments, which are included in the order message and in the observation result message sent to the requestor, shall not be included in the observation result messages sent to the copied recipients.
(Definition from OBR.50 in Ch. 4)
Definition: This field is retained for backward compatibility only as of v 2.7 and withdrawn as of v2.9.
(Definition from OBR.50 in Ch. 7)
Definition: This field is retained for backward compatibility only as of v 2.7 and withdrawn as of v2.9.
(Definition from OBR.51 in Ch. 4)
Definition: The Observation Group ID is the identifier assigned by the producer of a result to uniquely identify the results associated with this OBR segment. The Observation Group ID is intended to remain the same regardless of the change in status to the result (i.e., it is not a snapshot ID). This field is intended to promote forward compatibility with HL7 V3.
(Definition from OBR.51 in Ch. 7)
Definition: The Observation Group ID is the identifier assigned by the producer of a result to uniquely identify the results associated with this OBR segment. The Observation Group ID is intended to remain the same regardless of the change in status to the result (i.e., it is not a snapshot ID). This field is intended to promote forward compatibility with HL7 V3.
(Definition from OBR.52 in Ch. 4)
Definition: The Parent Observation Group ID field relates this child OBR to its parent OBR segment using the Observation Group ID of the parent result.
(Definition from OBR.52 in Ch. 7)
Definition: The Parent Observation Group ID field relates this child OBR to its parent OBR segment using the Observation Group ID of the parent result.
(Definition from OBR.53 in Ch. 4)
Definition: This field enables a shorter number to be communicated that is unique within other identifiers.
(Definition from OBR.53 in Ch. 7)
Definition: This field enables a shorter number to be communicated that is unique within other identifiers.
(Definition from ORC.8 in Ch. 4)
Definition: This field relates a child order to its parent order when a parent child order relationship exists. The parent child order mechanism is described in HL7 Table 0119 under order control code PA. This field uniquely identifies the parent order; no other information is required to link the child order with its parent order. It can be used to link the order to the results that triggered this order (e.g., a reflex order) or other order it relates to as an occurrence. This field repeats to allow linking to more than one parent, if necessary.
The first component has the same format as ORC-2-Placer Order Number (Section 4.5.3.2, "Placer Order Number (EI) 00216"). The second component has the same format as ORC-3-Filler Order Number (Section 4.5.3.3, "Filler Order Number (EI) 00217"). The components of the placer order number and the filler order number are transmitted in sub-components of the two components of this field.
Note that ORC-8 – Parent Order is equivalent to OBR-54 – Parent Order, but neither one is the same as OBR-29 – Result Observation Identifier.
Condition: Where the message has matching ORC/OBR pairs, ORC-8 and OBR-54 Must carry the same value.
(Definition from OBR.54 in Ch. 4)
Definition: This field relates a child order to its parent order when a parent child order relationship exists. The parent child order mechanism is described in HL7 Table 0119 – Order Control Codes in Chapter 2C, Code Tables, under order control code PA. This field uniquely identifies the parent orders; no other information is required to link the child order with its parent orders. It can be used to express that this order is a reflex being a consequence of original results referred here.
The first component has the same format as ORC-2-placer order number (Section 4.5.3.2, "Placer Order Number (EI) 00216"). The second component has the same format as ORC-3-filler order number (Section 4.5.3.3, "Filler Order Number (EI) 00217"). The components of the placer order number and the filler order number are transmitted in sub-components of the two components of this field.
Note that ORC-8 – Parent Order is equivalent to OBR-54-Parent Order, but neither one is the same as OBR-29-Parent Result Obersvation Identifier .
Condition: Where the message has matching ORC/OBR pairs, ORC-8 and OBR-54 must carry the same value.
(Definition from OBR.54 in Ch. 7)
Definition: This field relates a child order to its parent order when a parent child order relationship exists. The parent child order mechanism is described in HL7 Table 0119 – Order Control Codes in Chapter 2C, Code Tables, under order control code PA. This field uniquely identifies the parent orders; no other information is required to link the child order with its parent orders. It can be used to express that this order is a reflex being a consequence of original results referred here.
The first component has the same format as ORC-2-placer order number (Section 4.5.3.2, "Placer Order Number (EI) 00216"). The second component has the same format as ORC-3-filler order number (Section 4.5.3.3, "Filler Order Number (EI) 00217"). The components of the placer order number and the filler order number are transmitted in sub-components of the two components of this field.
Note that ORC-8 – Parent Order is equivalent to OBR-54-Parent Order, but neither one is the same as OBR-29-Parent Result Obersvation Identifier .
Condition: Where the message has matching ORC/OBR pairs, ORC-8 and OBR-54 must carry the same value.
(Definition from OH1.2 in Ch. 3)
Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from OH2.2 in Ch. 3)
Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from OH3.2 in Ch. 3)
Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from OH4.2 in Ch. 3)
Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from ORC.35 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when either ORC-2 and/or ORC 3 is valued with a unique identifier in accordance with Chapter 2, Section 2.10.4.2.
(Definition from OBR.55 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when either an OBR-2 and/or OBR-3 is valued with unique identifier in accordance with Chapter 2, Section 2.10.4.2.
(Definition from IPC.10 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when the combination of IPC-1, IPC-2, IPC-3, and IPC-4 represents a unique identifier according to Chapter 2, Section 2.10.4.2.
(Definition from BPX.22 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an BPX is uniquely identified sufficiently within the specific implementation using BPX-17 or BPX-6 as agreed to by the trading partners and in accordance with Chapter 2, Section 2.10.4.2.
(Definition from BTX.21 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an BTX is uniquely identified sufficiently within the specific implementation using BTX-20 or BTX-3 as agreed to by the trading partners in accordance with Chapter 2, Section 2.10.4.2.
(Definition from DON.34 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an DON is uniquely identified sufficiently within the specific implementation using DON-1 in accordance with Chapter 2, Section 2.10.4.2.
(Definition from BUI.13 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an BUI is uniquely identified sufficiently within the specific implementation using BUI-2 in accordance with Chapter 2, Section 2.10.4.2
(Definition from RXV.22 in Ch. 4A)
Definition: The intended handling by the receiver of the infusion order is represented by this segment. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from CDO.2 in Ch. 4A)
Definition: The Action Code indicates whether the cumulative dosage segment is intended to be added, deleted, updated, or did not change. If the field is not valued in any CDO segments for the order, the segments are considered to have been sent in snapshot mode. If some but not all CDO segments for the order do not have the action code valued, the default value is Add. Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from OBR.55 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an either OBR-2 and/or OBR-3 is valued with unique identifier in accordance with Chapter 2, Section 2.10.4.2.
(Definition from OBX.31 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an OBX-21 is valued in accordance with guidance in Chapter 2, Section 2.10.4.2.
(Definition from SPM.35 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an SPM-2 or SPM-31 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.
(Definition from PRT.2 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0287 – Problem/goal action code for valid values.
(Definition from CSR.17 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when CSR-1 and CSR-4, or CSR-2 and CSR-5 are valued as agreed to by the trading partners in accordance with the guidance in Chapter 2, Section 2.10.4.2.
(Definition from CTI.4 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when CTI-1 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.
(Definition from SHP.12 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when SHP-1 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.
(Definition from PAC.9 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when PAC-2 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.
(Definition from GOL.1 in Ch. 12)
Definition: The action code field gives the intent of the problem or goal. Refer to HL7 Table 0287 – Problem/Goal Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from PRB.1 in Ch. 12)
Definition: This field contains the intent of the message. Refer to HL7 Table 0287 – Problem/Goal Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from PTH.1 in Ch. 12)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0287 – Problem/Goal Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from DEV.1 in Ch. 17)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0287 – Problem/goal action code for valid values.
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:
Cardiac enzymes STAT and then q 4 hours.
Streptokinase studies, draw 1st Stat and run Stat, then draw q 4 hours and run Stat.
Gentamicin 100mg Now and 80mg q12h second dose (First 80mg dose) given exactly 12 hours after the 100mg dose. (Might be 2 service requests.)
Activase 15mg bolus Stat then 50mg over 30 minutes, then 35mg over the next 60 minutes. (Might be 2 service requests.)
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.)
Zithromax 500mg (2tabs) po on the first day then 250mg (1tab) po qd for 5 days. (Might be 2 service requests.)
Zyban (Bupropion) Start 150mg po qam x 3 days, then increase to 150mg po bid for 7 to 12 weeks.
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.)
doxycylcine 100mg po bid on the first day then 100mg po qd.
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).
Seq# | DataElement | Description | Must Implement | Flags | Cardinality | Length | C.LEN | Vocabulary | DataType |
---|---|---|---|---|---|---|---|---|---|
TQ1 | |||||||||
1 | 01627 | Set ID - TQ1 | [0..1] | [1..4] | SI | ||||
2 | 01628 | Quantity | [0..1] | CQ | |||||
3 | 01629 | Repeat Pattern | [0..*] | RPT | |||||
4 | 01630 | Explicit Time | [0..*] | TM | |||||
5 | 01631 | Relative Time and Units | [0..*] | CQ | |||||
6 | 01632 | Service Duration | [0..1] | CQ | |||||
7 | 01633 | Start date/time | [0..1] | DTM | |||||
8 | 01634 | End date/time | [0..1] | DTM | |||||
9 | 01635 | Priority | [0..*] | CWE | |||||
10 | 01636 | Condition text | = | [0..1] | 250 | TX | |||
11 | 01637 | Text instruction | = | [0..1] | 250 | TX | |||
12
|
01638 | Conjunction |
MAY
True: False: |
C |
[1..1] [0..1] |
[1..1] | ID | ||
13 | 01639 | Occurrence duration | [0..1] | CQ | |||||
14 | 01640 | Total occurrences | = | [0..1] | 10 | NM |
Definition: For the first timing specification transmitted, the sequence number shall be 1; for the second timing specification, it shall be 2; and so on.
Definition: This field specifies the numeric quantity of the service that should be provided at each service interval. For example, if two blood cultures are to be obtained every 4 hours, the quantity would be '2', or if three units of blood are to be typed and cross-matched, the quantity would be '3'. The default value for this field is '1'.
If multiple identical services are to be requested, it is strongly recommended that multiple service requests be placed, giving each service request its own unique placer/filler number.
Definition: The repeating frequency with which the treatment is to be administered. It is similar to the frequency and SIG code tables used in order entry systems.
This field may be repeated to build up more complex repeat patterns. For example, daily at bedtime can be represent as "|QD~HS|".
When the quantity timing specification must change to a different repeat pattern after some period of time, a new TQ1 segment must be used to show the new repeat pattern. Note that the end date of the current TQ1 will show when the current timing specification ends, and the start date of the next TQ1 shows when the new timing specification begins. The Conjunction field, TQ1-12 determines if the next TQ1 segment is to be performed sequentially or in parallel.
Definition: This field explicitly lists the actual times referenced by the code in TQ1-3. This field will be used to clarify the TQ1-3 in cases where the actual administration times vary within an institution. If the time of the service request spans more than a single day, this field is only practical if the same times of administration occur for each day of the service request. If the actual start time of the service request (as given by TQ1-7) is after the first explicit time, the first administration is taken to be the first explicit time after the start time. In the case where the patient moves to a location having a different set of explicit times, the existing service request may be updated with a new quantity/timing segment showing the changed explicit times.
Usage Note: This field is not valued if a Repeat Pattern is not present.
Definition: This field is used to define the interval between schedules for service request or bottle records. If this field contains a value, it overrides any value in the explicit time interval field. The units component of the CQ data type is constrained to units of time.
Examples:
TQ1|1|1|Q1H||60^min&&ANS+ - Q1H is defined with an interval between services of 60 minutes
TQ1|1|1|Q6H||6^hr&&ANS+ - Q6H is defined with an interval between services of 6 hours
TQ1|1|1|QD||1^d&&ANS+ - QD is defined with an interval between services of 1 day
Definition: This field contains the duration for which the service is requested.
The quantity component of this field must be a positive, non-zero number. The unit's portion of this field is constrained to units of time.
Example: Whirlpool twenty minutes three times per day for 3 days. Three days is the service duration.
TQ1|1||TID|||3^d&&ANS+||||||20^min&&ANS+|9<cr>
Definition: This field may be specified by the requester, in which case it indicates the earliest date/time at which the services should be started. In many cases, however, the start date/time will be implied or will be defined by other fields in the service request record (e.g., urgency - STAT). In such a case, this field will be empty.
The filling service will often record a value in this field after receipt of the service request, however, and compute an end time on the basis of the start date/time for the filling service's internal use.
Definition: When filled in by the requester of the service, this field should contain the latest date/time that the service should be performed. If it has not been performed by the specified time, it should not be performed at all. The requester may not always fill in this value, yet the filling service may fill it in on the basis of the instruction it receives and the actual start time.
Regardless of the value of the end date/time, the service should be stopped at the earliest of the date/times specified by either the duration or the end date/time.
Definition: This field describes the urgency of the request. If this field is blank, the default is R. Refer to User-Defined Table 0485 – Extended Priority Codes in Chapter 2C, Code Tables, for suggested values.
Definition: This is a free text field that describes the conditions under which the drug is to be given. For example, "PRN pain," or "to keep blood pressure below 110."
The presence of text in this field should be taken to mean that human review is needed to determine the how and/or when this drug should be given.
For complex codified conditions see the TQ2 segment below.
Definition: This field is a full text version of the instruction (optional).
Definition: This field indicates that a second TQ1 segment is to follow. Refer To HL7 Table 0472 – TQ Conjunction ID in Chapter 2C, Code Tables, for allowed values.
For continuous or periodic services, the point at which the service is actually stopped is determined by the field TQ1-8 end date/time and TQ1-6 duration, whichever indicates an earlier stopping time. Ordinarily, only one of these fields would be present.
Condition Rule: If the TQ1 segment is repeated in the message, this field must be populated with the appropriate Conjunction code indicating the sequencing of the following TQ1 segment.
Definition: This field contains the duration for which a single performance of a service is requested. The quantity component of this field must be a positive, non-zero number when populated. The units component is constrained to be units of time.
Example: Whirlpool twenty minutes three times per day for three days. Twenty minutes is the occurrence duration.
TQ1|1||TID|||3^d&&ANS+||||||20^min&&ANS+|9<cr>
Definition: This field contains the total number of occurrences of a service that should result from this service request. If both the end date/time (TQ1-8) and the total occurrences are valued and the occurrences would extend beyond the end date/time, then the end date/time takes precedence. Otherwise the number of occurrences takes precedence.
Example: Whirlpool twenty minutes three times per day for three days. The total occurrences would be 9.
TQ1|1||TID|||3^d&&ANS+||||||20^min&&ANS+|9<cr>
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.
Seq# | DataElement | Description | Must Implement | Flags | Cardinality | Length | C.LEN | Vocabulary | DataType |
---|---|---|---|---|---|---|---|---|---|
TQ2 | |||||||||
1 | 01648 | Set ID - TQ2 | [0..1] | [1..4] | SI | ||||
2 | 01649 | Sequence/Results Flag | [0..1] | [1..1] | ID | ||||
3
|
01650 | Related Placer Number |
MAY
True: False: |
C |
[1..1] [0..1] |
EI | |||
4
|
01651 | Related Filler Number |
MAY
True: False: |
C |
[1..1] [0..1] |
EI | |||
5
|
01652 | Related Placer Group Number |
MAY
True: False: |
C |
[1..1] [0..1] |
EI | |||
6
|
01653 | Sequence Condition Code |
MAY
True: False: |
C |
[1..1] [0..1] |
[2..*] | ID | ||
7
|
01654 | Cyclic Entry/Exit Indicator |
MAY
True: False: |
C |
[1..1] [0..1] |
[1..1] | ID | ||
8 | 01655 | Sequence Condition Time Interval | [0..1] | CQ | |||||
9 | 01656 | Cyclic Group Maximum Number of Repeats | = | [0..1] | 10 | NM | |||
10 | 01657 | Special Service Request Relationship |
MAY
True: False: |
C |
[1..1] [0..1] |
[1..1] | ID |
TQ2 Usage notes:
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).
Definition: For the first timing specification transmitted, the sequence number shall be 1; for the second timing specification, it shall be 2; and so on.
Definition: This flag defines the sequencing relationship between the current service request, and the related service request(s) specified in this TQ2 segment. See HL7 Table 0503 – Sequence/Results Flag in Chapter 2C, Code Tables, for values. If not value is present, the S - Sequential is the default value.
Definition: The placer numbers of the service request(s) to which this TQ2 segment links the current service request. This field should be populated with the appropriate "Placer number" from the current service request. For orders, the Placer Order Number from ORC-2 is the appropriate "Placer number". Repeats of this field indicate the current service request is related to multiple service requests.
Conditional Rule: At least one of TQ2-3, TQ2-4, TQ2-5 must contain a value.
Definition: The filler numbers of the service request(s) to which this TQ2 segment links the current service request. This field should be populated with the appropriate "Filler number" from the current service request. For orders, the Filler Order Number from ORC-3 is the appropriate "Filler number". Repeats of this field indicate the current service request is related to multiple service requests.
Conditional Rule: At least one of TQ2-3, TQ2-4, TQ2-5 must contain a value.
Definition: The placer group numbers of the service request(s) to which this TQ2 segment links the current service request. This field should be populated with the appropriate "Placer group number" from the current service request. For orders, the Placer Group Number from ORC-4 is the appropriate "Placer group number". Repeats of this field indicate that the current service request is related to multiple groups of service requests.
Conditional Rule: At least one of TQ2-3, TQ2-4, TQ2-5 must contain a value.
Definition: Defines the relationship between the start/end of the related service request(s) (from TQ2-3, TQ2-4, or TQ2-5) and the current service request from ORC-2, 3 or 4. See HL7 Table 0504 – Sequence Condition Code in Chapter 2C Code Tables, for allowed values.
Conditional Rule: Either this field or TQ2-10 must be present.
Definition: Indicates if this service request is the first, last, service request in a cyclic series of service requests. If null or not present, this field indicates that the current service request is neither the first or last service request in a cyclic series of service requests. Refer to HL7 Table 0505 – Cyclic Entry/Exit Indicator in Chapter 2C, Code Tables, for allowed values.
Conditional Rule: Should not be populated when TQ2-2 (Sequence/Results Flag) is not equal to a 'C' (cyclic service request).
Example of TQ2 - 6, 7, & 8 Usage:
Example |
Translation |
...|ES|*|+10^min|... |
translates to: execute this service request the first time without evaluating the condition specified in the TQ2 segment; but repeat only its execution when the specified external service request's start or finish date/time has met this condition. This specification generates a repetition of the service request for each iteration of the cycle. |
Note: This requires that the requesting application be able to specify the placer/filler/placer group number of the last service request in the cycle in the first service request's quantity/timing specification.
Definition: Defines the interval of time between the start/end of the related service request(s) and the start/end of the current service request. The unit's component is constrained to units of time. If this field is not populated, then there should be no interruption between start/ending the current service request, and the related service request(s).
Definition: The maximum number of repeats for a cyclic group.
The total number of repeats is constrained by the end date/time of the last repeat or the end date/time of the parent, whichever is first. For example, if the total number or repeats is valued at 10 and the group has already repeated 5 times, the current order will not be repeated again if either the current order, or the prior order in the cycle, has reached its end date/time.
This field is meaningful only when TQ2-2 Sequence/Results Flag is valued with 'C'. However, even in this case this field is optional.
Definition: This defines an additional or alternate relationship between this service request and other service requests. Its primary intended use is for Pharmacy administration service requests, but it may be useful for other domains. See HL7 Table 0506 – Service Request Relationship in Chapter 2C, Code Tables, for allowed values.
Conditional Rule: Either this field or TQ2-6 must be present.
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.
Seq# | DataElement | Description | Must Implement | Flags | Cardinality | Length | C.LEN | Vocabulary | DataType |
---|---|---|---|---|---|---|---|---|---|
IPC | |||||||||
1 | 01330 | Accession Identifier | SHALL | [1..1] | EI | ||||
2 | 01658 | Requested Procedure ID | SHALL | [1..1] | EI | ||||
3 | 01659 | Study Instance UID | SHALL | [1..1] | EI | ||||
4 | 01660 | Scheduled Procedure Step ID | SHALL | [1..1] | EI | ||||
5 | 01661 | Modality | [0..1] | CWE | |||||
6 | 01662 | Protocol Code | [0..*] | CWE | |||||
7 | 01663 | Scheduled Station Name | [0..1] | EI | |||||
8 | 01664 | Scheduled Procedure Step Location | [0..*] | CWE | |||||
9 | 01665 | Scheduled Station AE Title | = | [0..1] | 16 | ST | |||
10 | 00816 | Action Code | [0..1] | [2..2] | ID |
(Definition from IPC.1 in Ch. 4)
Definition: A workflow-management IDIS generated number that identifies the Filler Order for an Imaging Service (Imaging Service Request). This identifier corresponds one-to-one to the Order Filler number but is used in internal tracking of the work by the IDIS and in communication between IDIS within the department. It also has specific requirements to assure its compatibility with DICOM. It is a case of the Entity Identifier data type (section 2.A.28). Its first component is a string that identifies the Imaging Service Request. A limit of sixteen (16) characters is required to allow compatibility with DICOM. See DICOM Standard Part 3 for further details on DICOM Attribute (0008,0050) that conveys information identical to the component one of this field.
An IDIS that performs functions of the workflow management for a department may accept a single Placer Order that gives rise to one or more Filler Orders-Imaging Service Requests. For example, an IDIS may receive an order for an X-ray examination of the patient daily at 8 am for the next three days. For the purposes of fulfilling the Placer Order, it will identify each of the daily exams either as a separate Filler Order or parts of a single Filler Order. Correspondingly, it will assign one or more Filler Order numbers associated with the order. For each of the Filler Order numbers, it will assign a unique Accession Number.
Each of the Imaging Service Requests may contain one or more Requested Procedures that it will identify with the Requested Procedure ID. The Requested Procedure is the most granular unit of work that may lead to the creation of the procedure report. Each procedure report contributes to the results for the order. In the example mentioned above, each of the daily examinations will require a separate diagnostic report, hence each of them will be treated as a separate Requested Procedure. Depending on the treatment of the order by the IDIS, it will either link all Requested Procedures to a single Filler Order-Imaging Service Request, or link each Requested Procedure to its own Imaging Service Request. Exact type of requested procedure is conveyed by the coded values in OBR-44 Procedure Code and OBR-45 Procedure Code modifier for each procedure. Note that in case of multiple Requested Procedures corresponding to one order, each procedure may have different code.
To support communication with the instances of equipment in a department (acquisition modalities), IDIS will also generate the Study Instance UID, a globally unique identifier for each Requested Procedure. This identifier will be used by acquisition modalities to identify all generated images and other DICOM objects related to this Requested Procedure. Note that, unlike the Study Instance UID, the Requested Procedure ID must only be unique within the scope of the encompassing Imaging Service Request identified by an Accession Number.
Each of the Requested Procedures may be further broken down by the IDIS into the Scheduled Procedure Steps based on the timing and equipment requirements. Each step is identified with the Scheduled Procedure Step ID. A single Procedure Step may only be performed on a single type and instance of the equipment. Thus, while the Requested Procedure may identify multi-modality examination (such as ones common in Nuclear Medicine), a single Procedure Step shall correspond to the operations performed on a single modality.
The example of the hierarchy of Imaging Service Request, Requested Procedure and Scheduled Procedure Step is depicted in a figure 4-6. Identifiers of the entities are represented by the field names stated in square brackets.
The full hierarchy constitutes the context that will be shared between all IDIS within a department in a course of order fulfillment.
Each OMI message shall convey information about Requested Procedure(s) pertaining to one order. A pair of Segments ORC/OBR shall correspond to each requested procedure. If the Requested Procedure is comprised of multiple Procedure Steps, multiple IPC segments shall be included for each ORC/OBR pair in the message. Value of the IPC-1 field shall be identical in all IPC segments.
Considering the preceding example of X-ray examinations on subsequent days with two different steps identified for the last Requested Procedure and examinations to be performed at the site, "RADIOLOGY", the communication of the information using OMI message may look like the following:
MSH|...<cr>
PID|...<cr>
ORC|NW|...<cr>
OBR|1|X1234^HIS|R578^RIS|56782^X-Ray Chest|...|XPA^X-Ray Chest PA|...<cr>
IPC|A345^RIS|P1234^RIS|1.2.840.1234567890.3456786.1^RIS|SPS1^RIS|CR|SXPA^Chest PA||RADIOLOGY|<cr>
ORC|NW|...<cr>
OBR|2|X1234^HIS|R578^RIS|56782^X-Ray Chest|...|XPA^X-Ray Chest PA|...<cr>
IPC|A345^RIS|P1235^RIS|1.2.840.1234567890.3456786.2^RIS|SPS1^RIS|CR|SXPA^Chest PA||RADIOLOGY|<cr>
ORC|NW|...<cr>
OBR|3|X1234^HIS|R578^RIS|56782^X-Ray Chest|...|XPALAT^X-Ray Chest PA and Lateral|...<cr>
IPC|A345^RIS|P1236^RIS|1.2.840.1234567890.3456786.3^RIS|SPS1^RIS|CR|SXPA^Chest PA||RADIOLOGY|<cr>
IPC|A345^RIS|P1236^RIS|1.2.840.1234567890.3456786.3^RIS|SPS2^RIS|CR|SXLAT^Chest Lat||RADIOLOGY|<cr>
(Definition from SAC.2 in Ch. 13)
Definition: This field identifies the laboratory accession (see section 13.2.3, "Glossary"). This identifier is assigned by the information system of the laboratory performing the tests.
An accession identifier can refer to more than one container. A Container Identifier (see below) is a Unique Identifier for that container.
Definition: This field is the identifier of the Requested Procedure that the workflow management IDIS selected to perform as a part of the order for the imaging service. It is a case of the Entity Identifier data type (section 2.A.28). The first component of this field is a string that identifies the Requested Procedure. A limit of sixteen (16) characters is required to allow compatibility with DICOM. This string must uniquely identify the Requested Procedure within the scope of the order (as specified by accession number). This uniqueness must persist over time. See DICOM Standard Part 3 for further details on DICOM Attribute (0040,0001) that conveys information identical to the component one of this field.
The second through fourth components contain the ID of the workflow management IDIS, in the form of the HD data type (see section 2.A.36, "HD - hierarchic designator"). The second component is a user-defined coded value that uniquely defines the application from other applications on the network. A limit of five (5) characters is suggested but not required. The second component of the Requested Procedure number always identifies the actual filler of an order.
A Requested Procedure is an instance of a Procedure of a given Procedure Type. An instance of a Requested Procedure includes all of the items of information that are specified by an instance of a Procedure Plan that is selected for the Requested Procedure by the imaging service provider. This Procedure Plan is defined by the imaging service provider on the basis of the Procedure Plan templates associated with the considered Procedure Type. An Imaging Service Request may include requests for several different Requested Procedures. The purpose of this entity is to establish the association between Imaging Service Requests and Procedure Types, to convey the information that belongs to this association and to establish the relationships between Requested Procedures and the other entities that are needed to describe them. A single Requested Procedure of one Procedure Type is the smallest unit of service that can be requested, reported, coded and billed. Performance of one instance of a Requested Procedure is specified by exactly one Procedure Plan. A Requested Procedure leads to one or more Scheduled Procedure Steps involving Protocols as specified by a Procedure Plan. A Requested Procedure may involve one or more pieces of equipment.
Each OMI message shall convey information about Requested Procedure(s) pertaining to one order. Pair of Segments ORC/OBR shall correspond to each requested procedure. If the Requested Procedure is comprised of multiple Procedure Steps, multiple IPC segments shall be included for each ORC/OBR pair in the message. In this case, the value of the IPC-2 field shall be identical in all IPC segments related to the same Requested Procedure.
Definition: Globally unique identifier assigned by the workflow management IDIS to the Imaging Study under which all images and other DICOM objects produced in the course of the Requested Procedure shall be collected. It is a case of the Entity Identifier data type (section 2.A.28). Its first component is a string that identifies the Study. A limit of sixty-four (64) characters is required to allow compatibility with DICOM. See DICOM Standard Part 3 for further details on DICOM Attribute (0020,000D) that conveys information identical to component one of this field. The second through fourth components contain the ID of the workflow management IDIS, in the form of the HD data type (see section 2.A.36, "HD - hierarchic designator"). The second component is a user-defined coded value that uniquely defines the application from other applications on the network. A limit of five (5) characters is suggested but not required. The second component of the Study Instance UID always identifies the actual filler of an order.
Each OMI message shall convey information about Requested Procedure(s) pertaining to one order. Pair of Segments ORC/OBR shall correspond to each requested procedure. If the Requested Procedure is comprised of multiple Procedure Steps, multiple IPC segments shall be included for each ORC/OBR pair in the message. In this case, the value of the IPC-3 field shall be identical in all IPC segments related to the same Requested Procedure.
Definition: This field is the identifier of a particular Procedure Step (sub-procedure) of the Requested Procedure that the workflow management IDIS selected to perform as a part of the order for imaging service. It is a case of the Entity Identifier data type (section 2.A.28). Its first component is a string that identifies the Procedure Step. A limit of sixteen (16) characters is required to allow compatibility with DICOM. This string must uniquely identify the Procedure Step within the scope of the Requested Procedure. This uniqueness must persist over time. See DICOM Standard Part 3 for further details on DICOM Attribute (0040,0009) that conveys information identical to the component one of this field.
The second through fourth components contain the ID of the workflow management IDIS, in the form of the HD data type (see section 2.A.36, "HD - hierarchic designator"). The second component is a user-defined coded value that uniquely defines the application from other applications on the network. A limit of five (5) characters is suggested but not required. The second component of the Requested Procedure number always identifies the actual filler of an order.
A Procedure Step is an arbitrarily defined scheduled unit of service, which is specified by the Procedure Plan for a Requested Procedure. A Procedure Step prescribes Protocol that may be identified by one or more protocol codes. A Procedure Step involves equipment (e.g., imaging Modality equipment, anesthesia equipment, surgical equipment, transportation equipment), human resources, consumable supplies, location, and time (e.g., start time, stop time, duration). While in the context of Imaging Service request the scheduling of a Procedure Step might include only a general designation of imaging Modality that could be satisfied by multiple pieces of the same equipment type, the performance of one instance of a Procedure Step involves one and only one piece of imaging Modality equipment.
Definition: The type of equipment requested to acquire data during performance of a Procedure Step. The acquired data will be used to create the images for the Imaging Study corresponding to the Requested Procedure.
This field is a case of the CE data type. Refer to External Table 0910 – Acquisition Modality in Chapter 2C, Code Tables, for valid values, and to DICOM Standard Part 3 for further details on DICOM Attribute (0008,0060) that conveys information identical to component one of this field.
A limit of sixteen (16) characters for the first component is required to allow compatibility with DICOM. The third component of this field, if present, shall have the value of "DCM" (see HL7 Table 0396 – Coding Systems in Chapter 2C, Code Tables).
Definition: One or more coded entries identifying the protocol according to which the Scheduled Procedure Step shall be performed. Protocol Code(s) may identify particular equipment settings as well as operator's manipulations. Refer to Table 0605 - Protocol Code in Chapter 2C for valid values.
A Protocol is a specification of actions prescribed by a Procedure Plan to perform a specific Procedure Step. A Scheduled Procedure Step contains only one Protocol that may be conveyed by one or more Protocol Codes. Typically, the code or codes identifying Protocol instance would be selected from a catalog of protocols established locally or provided by equipment manufacturers or professional organizations. Multiple Protocols may not exist in one Scheduled Procedure Step. See DICOM Standard Part 3 for further details on DICOM Attribute (0040,0008) that conveys information identical to components one through three of this field.
A limit of sixteen (16) characters for the first component and sixty-four (64) characters for the second component is required to allow compatibility with DICOM.
Definition: This field identifies the instance of the modality resource being requested for the performance of a particular Scheduled Procedure Step. It is a case of the Entity Identifier data type (section 2.A.28). The first component of this field is a string that identifies the particular piece of equipment. A limit of sixteen (16) characters is required to allow compatibility with DICOM. See DICOM Standard Part 3 for further details on DICOM Attribute (0040,0010) that conveys information identical to the component one of this field.
The second through fourth components identify the organization, in the form of the HD data type (see section 2.A.36, "HD - hierarchic designator").
If the Scheduled Procedure Step is to be performed by an unspecified member of a pool of resources, this field shall be empty and IPC-8 Scheduled Procedure Step Location is used to identify the site-specific resource pool. See section 4.5.6.8, "IPC-8 Scheduled Procedure Step Location (CWE) 01664," for explanation of the resource pool.
Definition: This field specifies a locally defined physical location of the modality resource being requested for performance of particular Scheduled Procedure Step. Although location is usually defined geographically (such as identification of a campus, building, floor, etc.) it may be used for identification of a pool of equipment (resources) formed by any other means. Values for the field shall be drawn from a locally defined coding scheme. Refer to Table 0606 - Scheduled Procedure Step Location in Chapter 2C for valid values.
For example, the pool may be defined as a set of three CT scanners belonging to an imaging center within a hospital. Two of these scanners may also be grouped into another pool based on their location at a building A, whereas the third scanner may be in a pool by itself due to its location in a building B.
If this field contains more than one location code, the equipment may be drawn from several resource pools.
If this field is empty and the fields IPC-7 and IPC-9 are also empty, it is assumed that a particular Procedure Step may be performed by any instance of equipment of a particular type within an organization.
See DICOM Standard Part 3 for further details on DICOM Attribute (0040,0011) that conveys information identical to component one of this field. A limit of sixteen (16) characters for the first component is required to allow compatibility with DICOM.
Definition: This field contains the Application Entity Title of the modality resource being requested for performance of a particular Scheduled Procedure Step. Application Entity Title is the identifier that identifies an instance of DICOM-compatible equipment for the purpose of addressing during communication. See DICOM Standard, Part 3 for further details on the DICOM Attribute (0040,0001) that conveys equivalent information. A limit of sixteen (16) characters is required to allow compatibility with DICOM.
If the Scheduled Procedure Step is to be performed by an unspecified member of a pool of resources, this field shall be empty and IPC-8 Scheduled Procedure Step Location is used to identify the site-specific resource pool. See section 4.5.6.8 for explanation of the resource pool.
(Definition from OH1.2 in Ch. 3)
Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from OH2.2 in Ch. 3)
Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from OH3.2 in Ch. 3)
Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from OH4.2 in Ch. 3)
Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from ORC.35 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when either ORC-2 and/or ORC 3 is valued with a unique identifier in accordance with Chapter 2, Section 2.10.4.2.
(Definition from OBR.55 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when either an OBR-2 and/or OBR-3 is valued with unique identifier in accordance with Chapter 2, Section 2.10.4.2.
(Definition from IPC.10 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when the combination of IPC-1, IPC-2, IPC-3, and IPC-4 represents a unique identifier according to Chapter 2, Section 2.10.4.2.
(Definition from BPX.22 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an BPX is uniquely identified sufficiently within the specific implementation using BPX-17 or BPX-6 as agreed to by the trading partners and in accordance with Chapter 2, Section 2.10.4.2.
(Definition from BTX.21 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an BTX is uniquely identified sufficiently within the specific implementation using BTX-20 or BTX-3 as agreed to by the trading partners in accordance with Chapter 2, Section 2.10.4.2.
(Definition from DON.34 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an DON is uniquely identified sufficiently within the specific implementation using DON-1 in accordance with Chapter 2, Section 2.10.4.2.
(Definition from BUI.13 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an BUI is uniquely identified sufficiently within the specific implementation using BUI-2 in accordance with Chapter 2, Section 2.10.4.2
(Definition from RXV.22 in Ch. 4A)
Definition: The intended handling by the receiver of the infusion order is represented by this segment. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from CDO.2 in Ch. 4A)
Definition: The Action Code indicates whether the cumulative dosage segment is intended to be added, deleted, updated, or did not change. If the field is not valued in any CDO segments for the order, the segments are considered to have been sent in snapshot mode. If some but not all CDO segments for the order do not have the action code valued, the default value is Add. Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from OBR.55 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an either OBR-2 and/or OBR-3 is valued with unique identifier in accordance with Chapter 2, Section 2.10.4.2.
(Definition from OBX.31 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an OBX-21 is valued in accordance with guidance in Chapter 2, Section 2.10.4.2.
(Definition from SPM.35 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an SPM-2 or SPM-31 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.
(Definition from PRT.2 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0287 – Problem/goal action code for valid values.
(Definition from CSR.17 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when CSR-1 and CSR-4, or CSR-2 and CSR-5 are valued as agreed to by the trading partners in accordance with the guidance in Chapter 2, Section 2.10.4.2.
(Definition from CTI.4 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when CTI-1 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.
(Definition from SHP.12 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when SHP-1 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.
(Definition from PAC.9 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when PAC-2 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.
(Definition from GOL.1 in Ch. 12)
Definition: The action code field gives the intent of the problem or goal. Refer to HL7 Table 0287 – Problem/Goal Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from PRB.1 in Ch. 12)
Definition: This field contains the intent of the message. Refer to HL7 Table 0287 – Problem/Goal Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from PTH.1 in Ch. 12)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0287 – Problem/Goal Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from DEV.1 in Ch. 17)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0287 – Problem/goal action code for valid values.
The purpose of this section is to show how certain specific situations would be handled using the order entry protocol. The ellipses represent uncompleted details. The symbol // precedes comments for clarification.
Suppose that an application called "PC" is sending an order to the EKG application for three EKGs to be done on successive days.
The order might be placed as follows:
ORM message:
MSH|...<cr>
PID|...<cr>
ORC|NW|A226677^PC||946281^PC||N|3^QAM||200601121132|444-44-4444^HIPPOCRATES^HAROLD^^^^MD|||4EAST|...<cr>
// EKG order
OBR|1|||8601-7^EKG IMPRESSION^LN||||||||||||222-33-4444^PUMP^PATRICK^^^^MD|||||||||||3^QAM|...<cr>
BLG|...<cr>
ORC|NW|...<cr>
// Another order yet others may follow
There is a group number first component indicating that an order group is being created.
Responses: Because the EKG application must turn the single order above into three orders for three separate EKGs (services), the results of each will be reported under its own OBR segment. Several response levels are possible depending on the Response Flag:
If the Response Flag is N (as it is), then the filler EKG application only responds "I got the order."
MSH|...<cr>
MSA|...<cr>
The only implication of this response is that the order was received.
If the Response Flag had been E, then the response would have been the same, but its implication would have been that the EKG application had processed all the orders and they were acceptable.
If the Response Flag were R, then the filler EKG application must communicate to the PC the fact of the creation of child orders, but with no details:
MSH|...<cr>
MSA|...<cr>
ORC|PA|A226677^PC|89-458^EKG|946281^PC<cr>
ORC|CH|A226677^PC|89-551^EKG|946281...<cr> // 1ST child ORC.
ORC|CH|A226677^PC|89-552^EKG|946281...<cr> // 2ND child ORC.
ORC|CH|A226677^PC|89-553^EKG|946281...<cr> // 3RD child ORC.
... // Other parts of follow.
What has been said here is "Your A226767 has spun out three children named 89-551, 89-552, and 89-553." Notice that the placer order numbers are identical in the children's ORCs.
If the Response Flag were D, then the filler EKG application must communicate to the PC application the fact of the replacement and also the exact replacement order segments:
MSH|...<cr>
MSA|...<cr>
ORC|PA|A226677^PC|89-458^EKG<cr>
ORC|CH|A226677^PC|89-551^EKG|946281^PC|SC|||A226677&PC^89-458&EKG|
... ^^^^198901130500^...<cr>
// 1ST child ORC
OBR|1||89-551^EKG|8601-7^EKG IMPRESSION^LN|...<cr>
// 1ST child OBR
ORC|CH|A226677^PC|89-522^EKG|946281^PC|SC|||A226677&PC^89-458&EKG|
... ^^^^198901140500^...<cr>
// 2ND child ORC
OBR|2||89-552^EKG|8601-7^EKG IMPRESSION^LN|...<cr>
// 2ND child OBR
ORC|CH|A226677^PC|89-553^EKG|946281^PC|SC|||A226677&PC^89-458&EKG|
...^^^^198901150500^...<cr>
// 3RD child ORC
OBR|3||89-553^EKG|8601-7^EKG IMPRESSION^LN|... <cr>
// 3RD child OBR
// Other parts might follow
Here the actual OBR segments have been added.
The status of the child orders is being reported as SC (scheduled).
ORC-7-quantity/timing shows that the EKGs are requested after 0500 on successive days.
The 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 |
|
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):
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).
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 = <placer order number>, and OBR-4 = "Phone".
The ORR^O02 message is used to acknowledge the order and communicate the filler order number and order status. Then, when the phone number is available, 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 = <placer order number>, ORC-3 = <filler order number>, ORC-5 = <order status>, OBR-4 = "Phone", and OBX-5 = <Phone Number of Patient>. The status change is acknowledged with the ORR^O02 message.
Next, the location master files are updated. The phone number assigning application may send a MFN^M05 message to have the location master file reflect the phone number assignment as well. The fields on the message are valued as follows:
After processing the order: MFI-1 = "LOC", MFI-3 = "UPD", MFI-5 = <effective date/time>, MFE-1 = "MUP", LOC-1 = <patient location>, LOC-3 = "B" (bed), LOC-6 = <Phone Number of Patient>. This message is acknowledged using the MFK^M05 message.
Transfer a patient (A02)
If a patient keeps the same phone number during the whole visit the assigned phone number must be mapped to a different phone outlet whenever a patient is transferred to a new location. In that case, the ADT^A02 message is sent to the phone number assigning application. That application not only acknowledges the message, but also sends an ORM^O01 message with ORC-1 = "SC" and the other fields the same as described in the Phone Number Assignment section. Additionally, it sends a MFN^M05 message to change the location master file accordingly for the old location and another MFN^M05 to synchronize the phones for the new location.
Leave of absence (A21/A22)
When the patient leaves the hospital or the bed is vacated for a significant amount of time, the phone needs to be de-activated and re-activated appropriately. The same ORM^O01 and MFN^M05 messages are used as described above following the ADT^A21 and ADT^22 messages.
Patient makes calls or (de-)activates his phone.
The patient can use the phone whenever he wants to. This implies that his balance does not exceed the limit. Otherwise the phone is deactivated automatically. Furthermore the patient can activate or deactivate the phone by entering the authorization key for his own. In these scenarios the phone number assigning application sends and ORM^O01 message with ORC-1 = "OD" and the appropriate order status. The status update is necessary to provide a call switching system with the actual information.
Discharge a patient (A03)
When the patient is discharged, the ADT^A03 message is sent to indicate a discharge. The phone number assigning application sends an ORM^O01 message with a change of status to indicate completion of the order, as well as an MFN^M05 message to synchronize the location master file.
After discharging a patient his final charges must be billed. Using the query P04 returns the data in a display oriented format which can be used for printing. Alternatively a print request can be used. The billing system issues a QRY^P04 message where the fields are valued as follows: QRD-2 = "R" (record oriented format), QRD-3 = "I" (immediate response), QRD-8.1 = <Patient ID>, QRF-2 = <start date/time>, and QRF-3 = <end date/time>. The phone number assigning applications responds with a DSR^P04 message with the data in DSP-3.
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. |
Send Application Ack: RTB^Z74^RTB_Z74
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, an immediate ack SHALL NOT be sent.
Never send an application ack in enhanced mode.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^Z73^ACK |
NE | (none) | |
MSH-16 | NE | (none) |
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:
Send Immediate Ack: ACK^Z73^ACK
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, an immediate ack SHALL NOT be sent.
Never send an application ack in enhanced mode.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^Z73^ACK |
NE | (none) | |
MSH-16 | NE | (none) |
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 |
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 = <additional fee>.
Request a new Chip card for a defective one
Sometimes a chip card is defective. Then the patient needs a new one. This situation requires an order using the XO control code in the ORM^O01 message. The chip card dispensing system returns the new chip card number using the ORU^RO1. The ORC-16-Order Control Code Reason is used to clarify the request.
Return a chip card
When the patient returns the chip card, a discontinue message is send with ORC-1 = "DC". This message is acknowledged accordingly by the chip card dispensing system.
Printing a form
When form needs printing, the ORM^O01 could also be used. The OBR segment would contain the print form service and the OBX would contain the specific print form. A notification when completing the printing is feasible as well using the ORM^O01 with a status update associated to the appropriate placer/filler order number.
A diet office needs to receive specific information, the most important being the diet order itself. Diet restrictions (often called diet codes) are the basic building blocks of a diet order. The diet order segments may be sent as part of the ORM and ORR message structure to support backwards compatibility, or may be sent as part of the following dedicated message structures.
Send Application Ack: ORD^O04^ORD_O04
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, 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, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^O03^ACK |
NE | (none) | |
MSH-16 | AL, ER, SU | application ack: ORD^O04^ORD_O04 or OSU^O52^OSU_O52 |
NE | (none) |
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.
Send Immediate Ack: ACK^O04^ACK
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, an immediate ack SHALL NOT be sent.
Never send an application ack in enhanced mode.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^O04^ACK |
NE | (none) | |
MSH-16 | NE | (none) |
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).
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|.
Seq# | DataElement | Description | Must Implement | Flags | Cardinality | Length | C.LEN | Vocabulary | DataType |
---|---|---|---|---|---|---|---|---|---|
ODS | |||||||||
1 | 00269 | Type | SHALL | [1..1] | [1..1] | ID | |||
2 | 00270 | Service Period | [0..10] | CWE | |||||
3 | 00271 | Diet, Supplement, or Preference Code | SHALL | [1..20] | CWE | ||||
4 | 00272 | Text Instruction | # | [0..2] | 80 | ST |
Definition: This field specifies type of diet. Refer To HL7 Table 0159 - Diet Code Specification Type in Chapter 2C, Code Tables, for valid entries.
(Definition from ODS.2 in Ch. 4)
Definition: When blank, the modifier applies to all service periods. Diet orders, for example, typically apply to all service periods. This field usually specifies supplements. This field allows you to designate a modification for one or more of the service periods during a day by combining service specifications as needed. The service periods will be local CEs, normally numbers. Suggested are:
service 1 |
is |
breakfast |
service 2 |
is |
mid-morning snack |
service 3 |
is |
lunch |
service 4 |
is |
mid-afternoon snack |
service 5 |
is |
dinner |
service 6 |
is |
bedtime snack |
Ex: |1~5| means service 1 and service 5, whatever these are locally defined to be.
Refer to Table 0627 - Service Period in Chapter 2C for valid values.
(Definition from ODT.2 in Ch. 4)
Definition: When blank, the modifier applies to all service periods. This field allows you to designate one or more of the feeding periods during a day by combining the codes as needed. It can also combine with quantity/timing to give such information as which service period the order belongs with. This field is identical in meaning with ODS-2-service period. See section 4.8.1.2, "ODS-2 Service Period (CWE) 00270," for further details. Refer to Table 0629 - Service Period in Chapter 2C for valid values.
Definition: This field is the identifier of the ordered item for a patient; it is equivalent to OBR-4-universal service ID in function. Since ODS is a repeating segment, multiple entities get multiple segments. Refer to Table 0628 - Diet, Supplement, or Preference Code in Chapter 2C for valid values.
Example:
|^REG|, |023^^99FD6|, |^NOLACT|, |^TUBEFD|, and |011^HIPRO100^99FD1~123^LOFAT20^99FD1|
In the case where this segment requests a diet supplement, i.e., ODS-1-type = S, this attribute specifies a particular item or class of items. If institutional codes for patient food preferences (P) have been codified, they are also expressed as coded segments; otherwise, the information is passed as a text string in the fourth component of the ODS segment, described below.
(Definition from ODS.4 in Ch. 4)
Definition: This field defines the specific instructions for dietary. These instructions may address specific patient needs, such as isolation. This field provides the ordering provider's dietary instructions as free text. It can represent the full dietary instruction or indicate supplemental information.
(Definition from ODT.3 in Ch. 4)
Definition: This field defines instructions associated with the tray. Example:
|PLASTIC SILVERWARE|.
This segment addresses tray instructions. These are independent of diet codes, supplements, and preferences and therefore get separate order numbers.
Seq# | DataElement | Description | Must Implement | Flags | Cardinality | Length | C.LEN | Vocabulary | DataType |
---|---|---|---|---|---|---|---|---|---|
ODT | |||||||||
1 | 00273 | Tray Type | SHALL | [1..1] | CWE | ||||
2 | 00270 | Service Period | [0..10] | CWE | |||||
3 | 00272 | Text Instruction | # | [0..1] | 80 | ST |
Definition: This field defines the type of dietary tray. Refer To HL7 Table 0160 - Tray Type in Chapter 2C, Code Tables, for valid entries.
Tray specifications are useful for early and late tray delivery in cases where a patient undergoes a procedure during normal feeding times. Tray specifications can also be used for guest trays, no trays, and messages. The value MSG means the ODT segment does not specify the type of tray but provides additional information about an existing tray. This information is found in ODT-3-text instruction.
(Definition from ODS.2 in Ch. 4)
Definition: When blank, the modifier applies to all service periods. Diet orders, for example, typically apply to all service periods. This field usually specifies supplements. This field allows you to designate a modification for one or more of the service periods during a day by combining service specifications as needed. The service periods will be local CEs, normally numbers. Suggested are:
service 1 |
is |
breakfast |
service 2 |
is |
mid-morning snack |
service 3 |
is |
lunch |
service 4 |
is |
mid-afternoon snack |
service 5 |
is |
dinner |
service 6 |
is |
bedtime snack |
Ex: |1~5| means service 1 and service 5, whatever these are locally defined to be.
Refer to Table 0627 - Service Period in Chapter 2C for valid values.
(Definition from ODT.2 in Ch. 4)
Definition: When blank, the modifier applies to all service periods. This field allows you to designate one or more of the feeding periods during a day by combining the codes as needed. It can also combine with quantity/timing to give such information as which service period the order belongs with. This field is identical in meaning with ODS-2-service period. See section 4.8.1.2, "ODS-2 Service Period (CWE) 00270," for further details. Refer to Table 0629 - Service Period in Chapter 2C for valid values.
(Definition from ODS.4 in Ch. 4)
Definition: This field defines the specific instructions for dietary. These instructions may address specific patient needs, such as isolation. This field provides the ordering provider's dietary instructions as free text. It can represent the full dietary instruction or indicate supplemental information.
(Definition from ODT.3 in Ch. 4)
Definition: This field defines instructions associated with the tray. Example:
|PLASTIC SILVERWARE|.
First order:
MSH|...<cr>
PID|...<cr>
ORC|NW|1235^NURS|||||^^^199108021700||200608021200|333-77-7777^COMRAD^CONNOR^C|999-99-9999^VERIFY^VIRGIL^V|...<cr>
ODS|D||321^DB15^99DO3|...<cr>
ODS|D||322^NA2GM^99DO3|<cr>
Hold first order:
MSH|...<cr>
PID|...<cr>
ORC|HD|1235^NURS|||||^^^200608031700||200608031200|333-77-7777^COMRAD^CONNOR^C|999-99-9999^VERIFY^VIRGIL^V|...<cr>
NPO order with guest tray:
MSH|...<cr>
PID|...<cr>
ORC|NW|1236^NURS|||||^^^200608031700||200608031200|333-77-7777^COMRAD^CONNOR^C|999-99-9999^VERIFY^VIRGIL^V|...<cr>
ODS|D||323^NPO^99DO3|...<cr>
ORC|NW|1244^NURS|||||^^^200608031700||200608031200|333-77-7777^COMRAD^CONNOR^C|999-99-9999^VERIFY^VIRGIL^V|...<cr>
ODT|GUEST^Guest tray^HL70160|5^^99CBD|...<cr>
Clear liquid with guest tray:
MSH|...<cr>
PID|...<cr>
ORC|DC|1236^NURS|||||^^^200608041700||200608041200|333-77-7777^COMRAD^CONNOR^C|999-99-9999^VERIFY^VIRGIL^V|...<cr>
ORC|NW|1237^NURS|||||^^^200608041700||200608041200|333-77-7777^COMRAD^CONNOR^C|999-99-9999^VERIFY^VIRGIL^V|...<cr>
ODS|D||321^DB15^99DO3|...<cr>
ODS|D||322^NA2GM^99DO3|...<cr>
ODS|D||324^CLRLIQ^99DO3|...<cr>
ORC|NW|1245^NURS|||||^^^200608041700||200608041200|333-77-7777^COMRAD^CONNOR^C|999-99-9999^VERIFY^VIRGIL^V|...<cr>
ODT|GUEST^Guest tray^HL70160|5^^99CBD|...<cr>
Full liquid with guest tray:
MSH|...<cr>
PID|...<cr>
ORC|DC|1237^NURS|||||^^^200608051700||200608051200|333-77-7777^COMRAD^CONNOR^C|999-99-9999^VERIFY^VIRGIL^V|...<cr>
ORC|NW|1238^NURS|||||^^^200608051700||200608051200|333-77-7777^COMRAD^CONNOR^C|999-99-9999^VERIFY^VIRGIL^V|...<cr>
ODS|D||321^DB15^99DO3|...<cr>
ODS|D||322^NA2GM^99DO3|...<cr>
ODS|D||325^FULLIQ^99DO3|...<cr>
ORC|NW|1246^NURS|||||^^^200608051700||200608051200|333-77-7777^COMRAD^CONNOR^C|999-99-9999^VERIFY^VIRGIL^V|...<cr>
ODT|GUEST^Guest tray^HL70160|3^^99CBD|...<cr>
Release hold on previous order and give discharge message:
MSH|...<cr>
PID|...<cr>
ORC|DC|1238^NURS|||||^^^200608061700||200608061200|333-77-7777^COMRAD^CONNOR^C|999-99-9999^VERIFY^VIRGIL^V|...<cr>
ORC|RL|1235^NURS|||||^^^200608061700||200608061200|333-77-7777^COMRAD^CONNOR^C|999-99-9999^VERIFY^VIRGIL^V|...<cr>
ORC|NW|1247^NURS|||||^^^200608061700||200608061200|333-77-7777^COMRAD^CONNOR^C|999-99-9999^VERIFY^VIRGIL^V|...<cr>
ODT|MSG^Tray message only^HL70160|5^^99CBD|You Will Be Leaving Tomorrow|...<cr>
Basic diet: high protein, low fat. Supplements are ice cream at service period 4 and a half ham sandwich at service period 6. There are also tray orders for early service period 1, late service period 3, and guest tray at dinner.
MSH|...<cr>
PID|...<cr>
ORC|NW|1234^NURS|||||^^^200608021700||200608021200|333-77-7777^COMRAD^CONNOR^C|999-99-9999^VERIFY^VIRGIL^V|...<cr>
ODS|D||011^HIPRO100^99FD1|...<cr>
ODS|D||123^LOFAT20^99FD1|...<cr>
ODS|S|4|119^ICE CREAM^99FD8|...<cr>
ODS|S|6|320^1/2 HAM SANDWICH^99FD8|...<cr>
ORC|NW|1244^NURS|||||^^^200608031700||200608031200|333-77-7777^COMRAD^CONNOR^C|999-99-9999^VERIFY^VIRGIL^V|...<cr>
ODT|EARLY^Early tray^HL70160|1^^99CBD|...<cr>
ORC|NW|1245^NURS|||||^^^200608031700||200608031200|333-77-7777^COMRAD^CONNOR^C|999-99-9999^VERIFY^VIRGIL^V|...<cr>
ODT|LATE^Late tray^HL70160|3^^99CBD|...<cr>
ORC|NW|1246^NURS|||||^^^200608031700||200608031200|333-77-7777^COMRAD^CONNOR^C|999-99-9999^VERIFY^VIRGIL^V|...<cr>
ODT|GUEST^Guest tray^HL70160|5^DINNER^99CBD|...<cr>
This order specifies Similac with MCT oil and polycose additives.
MSH|...<cr>
PID|...<cr>
ORC|NW|1232^NURS|||||60^Q3H^^200608021700||200608021200|333-77-7777^COMRAD^CONNOR^C|999-99-9999^VERIFY^VIRGIL^V|...<cr>
ODS|D||010^SIMILAC^99DO1|...<cr>
ODS|D||011^MCT^99DO1|...<cr>
ODS|D||012^POLYCOSE^99DO1|...<cr>
This order specifies that the patient is a vegetarian.
MSH|...<cr>
PID|...<cr>
ORC|NW|1232^NURS|||||60^Q3H^^200608021700||200608021200|333-77-7777^COMRAD^CONNOR^C|999-99-9999^VERIFY^VIRGIL^V|...<cr>
ODS|D||123^LOFAT20^99FD1|...<cr>
ODS|S|4|119^ICE CREAM^99FD8|...<cr>
ODS|P||^VEGETARIAN|...<cr>
The Requisition Detail segment (RQD) is used for ordering medical, surgical, and patient care supplies. It is assumed that these supplies are managed by a materials management application, which contains a master list of all items the hospital uses.
There are basically two types of supplies, commonly referred to as stock and non-stock.
Stock supplies are, as the name suggests, stocked in the hospital in designated areas, such as the warehouse, Central Supply, Nursing floors, or Operating Room. When requisitioning stock supplies, the requesting application need only specify the information in the RQD segment. It is assumed that this is enough information for the application receiving to identify the item. If the sending application is not aware whether the supply is stock, it may optionally send an RQ1 along with the RQD. Typically in that case, the item is requested with a free text description.
Non-stock supplies are not stocked anywhere in the hospital and must be ordered from an industry distributor or manufacturer. When the requesting application knows that it is requisitioning non-stock supplies, it may also send an RQ1 segment with the RQD if at least one field in RQ1 is known to the sending application. This may be necessary in order for the receiving application to properly determine where to get these supplies. This depends on the sophistication of the database of the receiving application, which may contain a history of requisitions from the sending application.
Stock requisition orders use the ORM where RQD is the detail segment for backward compatibility or can use the OMS and ORS messages described below.
Send Application Ack: ORS^O06^ORS_O06
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, 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, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^O05^ACK |
NE | (none) | |
MSH-16 | AL, ER, SU | application ack: ORS^O06^ORS_O06 or OSU^O52^OSU_O52 |
NE | (none) |
Send Immediate Ack: ACK^O06^ACK
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, an immediate ack SHALL NOT be sent.
Never send an application ack in enhanced mode.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^O06^ACK |
NE | (none) | |
MSH-16 | NE | (none) |
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).
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.
Send Application Ack: ORN^O08^ORN_O08
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, 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, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^O07^ACK |
NE | (none) | |
MSH-16 | AL, ER, SU | application ack: ORN^O08^ORN_O08 or OSU^O52^OSU_O52 |
NE | (none) |
Send Immediate Ack: ACK^O08^ACK
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, an immediate ack SHALL NOT be sent.
Never send an application ack in enhanced mode.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^O08^ACK |
NE | (none) | |
MSH-16 | NE | (none) |
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).
RQD contains the detail for each requisitioned item. See assumptions above.
Seq# | DataElement | Description | Must Implement | Flags | Cardinality | Length | C.LEN | Vocabulary | DataType |
---|---|---|---|---|---|---|---|---|---|
RQD | |||||||||
1 | 00275 | Requisition Line Number | [0..1] | [1..4] | SI | ||||
2
|
00276 | Item Code - Internal |
MAY
True: False: |
C |
[1..1] [0..1] |
CWE | |||
3
|
00277 | Item Code - External |
MAY
True: False: |
C |
[1..1] [0..1] |
CWE | |||
4
|
00278 | Hospital Item Code |
MAY
True: False: |
C |
[1..1] [0..1] |
CWE | |||
5 | 00279 | Requisition Quantity | # | [0..1] | 6 | NM | |||
6 | 00280 | Requisition Unit of Measure | [0..1] | CWE | |||||
7 | 00281 | Cost Center Account Number | [0..1] | CX | |||||
8 | 00282 | Item Natural Account Code | [0..1] | CWE | |||||
9 | 00283 | Deliver To ID | [0..1] | CWE | |||||
10 | 00284 | Date Needed | [0..1] | DT |
Definition: This field contains the number that identifies this line in the requisition.
Definition: This field contains the identifier and description that uniquely identify the item on the application sending the requisition. This field is conditional because at least one of the three fields – RQD-2-item code- internal, RQD-3-item code-external, or RQD-4-hospital item code – must be valued. Refer to Table 0684 - Item Code - Internal in Chapter 2C for valid values.
Definition: This field contains the identifier and description that uniquely identify the item on the application receiving the requisition. This field is conditional because at least one of the three fields – RQD-2-item code-internal, RQD-3-item code-external or RQD-4-hospital item code – must be valued. Refer to Table 0685 - Item Code - External in Chapter 2C for valid values.
Definition: This field contains the identifier and description that uniquely identify the item on all applications in the hospital. The identifier is usually controlled by the hospital financial application in the charge description master file. This field is conditional because at least one of the three fields – RQD-2-item code-internal, RQD-3-item code-external or RQD-4-hospital item code -- must be valued. Refer to Table 0686 - Hospital Item Code in Chapter 2C for valid values.
Note: At least one of the three fields 4.11.1.2 through 4.11.1.4 must be non-null.
Definition: This field contains the quantity requisitioned for this item.
Definition: This field contains the unit of measure for this item. Refer to Table 0687 - Requisition Unit of Measure in Chapter 2C for valid values.
(Definition from RQD.7 in Ch. 4)
Definition: This field contains the general ledger cost center account number associated with a department that may issue or charge for this item. Refer to HL7 Table 0319 – Department Cost Centerin Chapter 2C, Code Tables, for valid values.
(Definition from PCE.2 in Ch. 17)
Definition: This field would contain the specific general ledger cost center account number associated with a department that may issue or charge for this item. Refer to HL7 Table 0319 – Department Cost Center in Chapter 2C, Code Tables, for valid values.
(Definition from RQD.8 in Ch. 4)
Definition: This field contains the accounting code that identifies this item in order to charge for this item. User-Defined Table 0320 - Item Natural Account Code in Chapter 2C, Code Tables, is used as the HL7 identifier for the user-defined table of values for this field.
(Definition from ITM.19 in Ch. 17)
Definition: This field contains the expense/natural account number from the general ledger chart of accounts associated with the item. Refer to HL7 Table 0320 – Item Natural Account Code in Chapter 4, Orders, for valid values.
Definition: This field contains the unique identifier and descriptive name of the department/location where the item should be delivered. Refer to Table 0688 - Deliver To ID in Chapter 2C for valid values.
Definition: This field contains the date this item is required.
Note: Although none of the fields are required, one of the three identifying codes—RQD-2-item code-internal, RQD-3-item code-external, or RQD-4-hospital item code—must be specified in order for the receiving application to process the request.
It is left to the vendors to determine which will be used as the common link between the two applications. HL7 recommends using the RQD-4-Hospital Item Code.
Hospital accounting requires an identifier to charge a particular cost center or patient for a requisitioned supply. If the supply is for a patient, then this identifier comes from the PID segment; otherwise, from RQD-7-Dept. Cost Center and RQD-8-Item Natural Account Code must be used. It is recommended that the "final" cost center responsible for providing the supply to the patient be included, even when the patient ID is provided.
Hospital accounting applications use RQD-7-Dept. Cost Center concatenated with RQD-8-Item Natural Account Code in order to post this transaction to the General Ledger. This concatenated value should correspond to a valid entry in the accounting applications "Chart of Accounts."
RQ1 contains additional detail for each non-stock requisitioned item. This segment definition is paired with a preceding RQD segment.
Seq# | DataElement | Description | Must Implement | Flags | Cardinality | Length | C.LEN | Vocabulary | DataType |
---|---|---|---|---|---|---|---|---|---|
RQ1 | |||||||||
1 | 00285 | Anticipated Price | = | [0..1] | 10 | ST | |||
2
|
00286 | Manufacturer Identifier |
MAY
True: False: |
C |
[1..1] [0..1] |
CWE | |||
3
|
00287 | Manufacturer's Catalog |
MAY
True: False: |
C= |
[1..1] [0..1] |
16 | ST | ||
4
|
00288 | Vendor ID |
MAY
True: False: |
C |
[1..1] [0..1] |
CWE | |||
5
|
00289 | Vendor Catalog |
MAY
True: False: |
C= |
[1..1] [0..1] |
16 | ST | ||
6 | 00290 | Taxable | [0..1] | [1..1] | ID | ||||
7 | 00291 | Substitute Allowed | [0..1] | [1..1] | ID |
Definition: This field contains the reference price for the requisition unit of measure that is known to the requisition application. It may or may not be the actual cost of acquiring the item from a supplier. It is also not the price charged to the patient.
(Definition from RQ1.2 in Ch. 4)
Definition: This field contains the unique code that identifies the manufacturer on the application receiving the requisition. This field is conditional because either RQ1-2-manufacturer ID and RQ1-3-manufacturer's catalog or RQ1-4-vendor ID and RQ1-5-vendor catalog must be valued.
Refer to User-defined Table 0385 – Manufacturer identifier in Chapter 2C, Code Tables, for suggested values, or relevant external code sets may be used (e.g., HIBCC Manufacturers Labeler ID Code (LIC), UPC, NDC).
(Definition from INV.17 in Ch. 13)
Definition: This field identifies the manufacturer of this substance. Refer to User-defined Table 0385 – Manufacturer Identifier in Chapter 2C, Code Tables, for suggested values. Relevant external code systems may be used, e.g., HIBCC Manufacturers Labeler ID Code (LIC), UPC, NDC, etc.
Definition: This field is the manufacturer's catalog number or code for this item. This field is conditional because either RQ1-2-manufacturer ID and RQ1-3-manufacturer's catalog or RQ1-4-vendor ID and RQ1-5-vendor catalog must be valued.
Definition: This field is the unique code that identifies the vendor on the application receiving the requisition. This field is conditional because either RQ1-2-manufacturer ID and RQ1-3-manufacturer's catalog or RQ1-4-vendor ID and RQ1-5-vendor catalog must be valued. Refer to Table 0683 - Vendor ID in Chapter 2C for valid values.
Because of this, it is recommended that each non-stock item have RQ1-2-manufacturers ID and RQ1-3-manufacturer's catalog, or RQ1-4-vendor ID and RQ1-5-vendor catalog. It is also possible that the requisitioning application will not know the identifier, as listed in the Manufacturer's or Vendor's catalog. In this case, it is important to include the name portion of this coded element field.
Definition: This field is the vendor's catalog number, name, or code for this item. This field is conditional because either RQ1-2-manufacturer ID and RQ1-3-manufacturer's catalog or RQ1-4-vendor ID and RQ1-5-vendor catalog must be valued.
Definition: This field indicates whether this item is subject to tax.
In general, non-stock requisitioned items will be printed by the receiving application and then processed by a human. In other words, the human will use the information to call the vendor or manufacturer to get pricing and other related purchasing information before placing the order with an outside vendor. Refer to HL7 Table 0136 -Yes/No Indicator as defined in Chapter 2C, Code Tables.
Definition: This field indicates whether the ancillary department may substitute an equivalent version of the item(s) ordered. Refer to HL7 Table 0136 - Yes/No Indicator as defined in Chapter 2C, Code Tables.
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| ...<cr>
PID|... <cr>
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|...<cr>
RQD|1|1234^Solution, 2.25% Saline||S1786^Saline Solution|1|BT^Bottle|1234-5678||ORSUP^Main OR Supply Room|20061123|...<cr>
MSH|^~VALUEamp;|ORSUPPLY|ORSYS|MMSUPPLY|MMSYS|19911105131523||OMN^O07^OMN_O07|...<cr>
PID|... <cr>
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<cr>
RQD|1|23455^Implant, Special Hip||I45323^Implant|1|EA^ Each|1234-5678||ORSUP^Main OR Supply Room|20061123|...<cr>
RQ1|123.45|DET^Detter, Inc.|444456|DST^Local Distributors, Inc.|333-456|N|...<cr>
This example is a requisition from the ORSUPPLY application to the MMSUPPLY application for five stock items to replenish a supply closet. The requisition numbers used by the ORSUPPLY application is RQ103 - RQ1037.
MSH|^~VALUEamp;|ORSUPPLY|ORSYS|MMSUPPLY|MMSYS|20061105131523||OMS^O05^OMS_O05|...<cr>
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|...<cr>
RQD|1|1232^Solution, 1% Saline||S1784^Saline Solution|5|BT^Bottle|1234-5678||ORSUP^Main OR Supply Room|20061105|...<cr>
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|...<cr>
RQD|2|1231^Solution, 0.2% Saline||S1781^Saline Solution|2|BT^Bottle|1234-5678||ORSUP^Main OR Supply Room|20061105|...<cr>
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|...<cr>
RQD|3|2342^Suture, Black Silk||SU123^Suture|2|DZ^Dozen|1234-5678||ORSUP^Main OR Supply Room|20061105|...<cr>
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|...<cr>
RQD|4|2344^Suture, Black Silk 3-0||SU124^Suture|1|DZ^Dozen|1234-5678||ORSUP^Main OR Supply Room|20061105|...<cr>
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|...<cr>
RQD|5|4565^Bandage Pad, 4x4||B6345^Bandage Pad|3|BX^Box|1234-5678||ORSUP^Main OR Supply Room|20061105|...<cr>
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.
Send Application Ack: ORB^O28^ORB_O28
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, 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, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^O27^ACK |
NE | (none) | |
MSH-16 | AL, ER, SU | application ack: ORB^O28^ORB_O28 or OSU^O52^OSU_O52 |
NE | (none) |
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.
Send Immediate Ack: ACK^O28^ACK
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, an immediate ack SHALL NOT be sent.
Never send an application ack in enhanced mode.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^O28^ACK |
NE | (none) | |
MSH-16 | NE | (none) |
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).
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.
Send Application Ack: BRP^O30^BRP_O30
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, 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, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^O29^ACK |
NE | (none) | |
MSH-16 | AL, ER, SU | application ack: BRP^O30^BRP_O30 |
NE | (none) |
Send Immediate Ack: ACK^O30^ACK
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, an immediate ack SHALL NOT be sent.
Never send an application ack in enhanced mode.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^O30^ACK |
NE | (none) | |
MSH-16 | NE | (none) |
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).
Blood product transfusion/disposition messages use the BTS and BRT messages as described below.
Send Application Ack: BRT^O32^BRT_O32
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, 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, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^O31^ACK |
NE | (none) | |
MSH-16 | AL, ER, SU | application ack: BRT^O32^BRT_O32 |
NE | (none) |
Send Immediate Ack: ACK^O32^ACK
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, an immediate ack SHALL NOT be sent.
Never send an application ack in enhanced mode.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^O32^ACK |
NE | (none) | |
MSH-16 | NE | (none) |
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).
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 |
Seq# | DataElement | Description | Must Implement | Flags | Cardinality | Length | C.LEN | Vocabulary | DataType |
---|---|---|---|---|---|---|---|---|---|
BPO | |||||||||
1 | 01700 | Set ID – BPO | SHALL | [1..1] | [1..4] | SI | |||
2 | 01701 | BP Universal Service Identifier | SHALL | [1..1] | CWE | ||||
3 | 01702 | BP Processing Requirements | [0..*] | CWE | |||||
4 | 01703 | BP Quantity | SHALL | = | [1..1] | 5 | NM | ||
5 | 01704 | BP Amount | = | [0..1] | 5 | NM | |||
6 | 01705 | BP Units | [0..1] | CWE | |||||
7 | 01706 | BP Intended Use Date/Time | [0..1] | DTM | |||||
8 | 01707 | BP Intended Dispense From Location | [0..1] | PL | |||||
9 | 01708 | BP Intended Dispense From Address | [0..1] | XAD | |||||
10 | 01709 | BP Requested Dispense Date/Time | [0..1] | DTM | |||||
11 | 01710 | BP Requested Dispense To Location | [0..1] | PL | |||||
12 | 01711 | BP Requested Dispense To Address | [0..1] | XAD | |||||
13 | 01712 | BP Indication for Use | [0..*] | CWE | |||||
14 | 01713 | BP Informed Consent Indicator | [0..1] | [1..1] | ID |
Definition: This field contains the sequence number for the BPO segment within the message. For the first order transmitted, the sequence number shall be 1; for the second order, it shall be 2; and so on.
Definition: This field contains the identifier code for the requested blood product. This can be based on local and/or "universal" codes. We recommend the "universal" procedure identifier. The structure of this CWE data type is described in the control section. The preferred coding system is the ISBT 128 Product Code. Refer to Table 0575 - BP Universal Service Identifier in Chapter 2C for valid values.
Blood Product Orders for commercial products, such as Rh Immune Globulin or Factor VIII concentrate, are not at this time defined in an international or national coding system as are blood products. Therefore, locally defined codes can be used for the Universal Service Identifier for commercial products.
Definition: This field contains additional information about the blood component class associated with the Universal Service ID. The placer of the order can specify any required processing of the blood product that must be completed prior to transfusion to the intended recipient. Refer to User-Defined Table 0508 - Blood Product Processing Requirements in Chapter 2C, Code Tables, for suggested values.
Definition: This field contains the number of blood products ordered.
Definition: This field contains the ordered amount (volume) associated with each quantity of blood product.
Definition: This field contains the units of measure for the blood product amount. (See Chapter 7 for more details about reporting units.) This field specifies the units of measure for volume of a blood component (i.e., 50 ml) or the units of measure or dosage of a commercial product (i.e., 910 I.U. - International Units - of Factor VIII Concentrate). Use of UCUM is strongly recommended as one of the delivered units (could be in addition to the local units). Refer to Table 0576 - BP Units in Chapter 2C for valid values.
Definition: This field specifies the date/time that the placer intends to use the blood product that is being ordered.
This is the time when the placer expects the product to be available within the transfusion service. For example, the product should be available for use, but not dispensed, on this date/time.
Definition: This field contains the location from which the blood component is to be dispensed.
Definition: This field contains the actual address of the location from which the blood component is to be dispensed.
Definition: This field specifies the date/time that the requested blood products must be ready to dispense. This date/time may be different from the intended use date/time. For example, the patient may be scheduled to come in for a transfusion at a specified time. However, the placer would request that the blood product be ready to dispense prior to that time in order to have the blood component ready for transfusion at the scheduled time. The field may also be used to indicate that the placer is now ready to pick up the ordered blood product and is requesting the blood product be ready to dispense at that time.
Definition: This field contains the inpatient or outpatient location to which the blood component is to be dispensed. The default dispense to location is the current census location for the patient.
Definition: This field contains the actual address of the location to which the blood component is to be dispensed. The default dispense to location is the current census location for the patient.
Definition: This is a coded optional field. The value indicates the reason that the blood product was ordered. This information is helpful for prospective review or retrospective studies of blood product ordering practices of the ordering provider by the Quality Assurance Department and/or Transfusion Committee. Refer to User-Defined Table 0509 - Indication for Use in Chapter 2C, Code Tables, for suggested values.
This field indicates whether consent for the transfusion has been obtained. Refer to HL7 table 0136 -Yes/No indicator as defined in Chapter 2C, Code Tables.
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.
Seq# | DataElement | Description | Must Implement | Flags | Cardinality | Length | C.LEN | Vocabulary | DataType |
---|---|---|---|---|---|---|---|---|---|
BPX | |||||||||
1 | 01714 | Set ID – BPX | SHALL | [1..1] | [1..4] | SI | |||
2 | 01715 | BP Dispense Status | SHALL | [1..1] | CWE | ||||
3 | 01716 | BP Status | SHALL | [1..1] | [1..1] | ID | |||
4 | 01717 | BP Date/Time of Status | SHALL | [1..1] | DTM | ||||
5
|
01718 | BC Donation ID |
MAY
True: False: |
C |
[1..1] [0..1] |
EI | |||
6
|
01719 | BC Component |
MAY
True: False: |
C |
[1..1] [0..1] |
CNE | |||
7 | 01720 | BC Donation Type / Intended Use | [0..1] | CNE | |||||
8
|
01721 | CP Commercial Product |
MAY
True: False: |
C |
[1..1] [0..1] |
CWE | |||
9
|
01722 | CP Manufacturer |
MAY
True: False: |
C |
[1..1] [0..1] |
XON | |||
10
|
01723 | CP Lot Number |
MAY
True: False: |
C |
[1..1] [0..1] |
EI | |||
11 | 01724 | BP Blood Group | [0..1] | CNE | |||||
12 | 01725 | BC Special Testing | [0..*] | CNE | |||||
13 | 01726 | BP Expiration Date/Time | [0..1] | DTM | |||||
14 | 01727 | BP Quantity | SHALL | = | [1..1] | 5 | NM | ||
15 | 01728 | BP Amount | = | [0..1] | 5 | NM | |||
16 | 01729 | BP Units | [0..1] | CWE | |||||
17 | 01730 | BP Unique ID | [0..1] | EI | |||||
18 | 01731 | BP Actual Dispensed To Location | [0..1] | PL | |||||
19 | 01732 | BP Actual Dispensed To Address | [0..1] | XAD | |||||
20 | 01733 | BP Dispensed to Receiver | [0..1] | XCN | |||||
21 | 01734 | BP Dispensing Individual | [0..1] | XCN | |||||
22 | 00816 | Action Code | [0..1] | [2..2] | ID |
Definition: This field contains the sequence number for the BPX segment under the related BPO segment. For the first blood product dispense status transmitted, the sequence number shall be 1; for the second product dispense status, it shall be 2; and so on.
Definition: This field indicates the current status of the specified blood product as indicated by the filler or placer. For example, the first status change of a product that may trigger a Blood Product Dispense Status Message occurs when it first becomes linked to a patient and is ready to dispense. The placer system may use the Blood Product Dispense Status Message to request the transfusion service to dispense the product. When the blood product is delivered or issued to a patient, the status of the blood product would be changed to indicate that it has now been "dispensed." Refer to HL7 Table 0510 - Blood Product Dispense Status in Chapter 2C, Code Tables, for valid entries.
Definition: The most commonly used message status values in a BPX will be preliminary and final. A status is considered preliminary until a blood product has reached a final disposition for the patient. For example, when the product is first cross-matched and a status message is sent, it would be considered preliminary. When the product is dispensed to the patient, that status would also be considered preliminary. However, once the product is transfused, the status would be considered final. The status of a blood product (BPX-2) can continue to change and the previous status should be overwritten until it reaches a final status (BPX-3). Refer to HL7 Table 0511 - BP Observation Status Codes Interpretation in Chapter 2C, Code Tables, for valid entries.
Definition: This field indicates the date and time that the status of the blood component was changed. For example, if the blood component had a status, of "RD" (Ready to Dispense), the date and time in this field would indicate the date and time that component was made ready to dispense by the filler system.
Definition: The Donation ID is the unique identification number assigned to a blood donation. The Donation ID depends upon the bar code labeling system used for the component. There are currently two blood component labeling standards: ABC CODABAR and ISBT 128. The preferred labeling system is ISBT 128. If using ISBT 128, the Donation ID is an internationally unique identifier consisting of the following 13 characters:
Country Code & Collection Facility - 5 characters
Donation Year - 2 characters
Serial Number - 6 characters
This field is required for blood components and is not applicable for commercial product messages.
Definition: The Component field includes an identifier and description of the specific blood component. Refer to Table 0577 - BC Component in Chapter 2C for valid values.
The identifier consists of a numeric or alphanumeric product code that represents the type of blood component. The coding system will be determined by the bar code labeling system on the particular component of blood. The preferred coding system is ISBT 128.
If using ISBT 128 labeling standard, the product code will consist of an 8-character alphanumeric code, starting with an alpha character and including the component class, donation type/intended use and division indicator.
If using CODABAR product labeling standard, the product code is a 5-digit number.
This field is required for blood components and is not applicable for commercial product messages.
Definition: This field indicates the type of donation or collection/intended use. This value is populated from Table 5 -Type of Donation in the ISBT 128 Application Specification. The default value is "0", meaning "Not specified." Other values indicate whether the blood product (1) is an allogeneic unit from a volunteer donor, (2) is intended for a specific recipient but may be crossed over and used for another recipient, or (3) is an autologous donation intended only for that particular recipient. Refer to Table 0578 - BC Donation Type / Intended Use in Chapter 2C for valid values.
This field is optional for blood component messages and is not applicable for commercial product messages.
Definition: This field contains the code and/or text to identify a commercial product. Examples of commercial products are blood derivatives such as Rh Immune Globulin and Factor VIII concentrate, Leukoreduction filters, and blood administration sets. Refer to Table 0579 - BP Blood Group in Chapter 2C for valid values.
Either code and/or text may be absent. However, the code is always placed in the first component position and any free text in the second component. Thus, a component delimiter must precede free text without a code. Free text can be utilized if no update is to occur. Refer To User-Defined Table 0512 - Commercial Product in Chapter 2C, Code Tables, for suggested values.
This field is required for commercial blood products and is not applicable for blood component messages.
Definition: This field identifies the manufacturer of the commercial product. The manufacturer may be different from the supplier of the commercial product.
This field is required for commercial blood products and is not applicable for blood component messages.
Definition: This field identifies the lot number for blood derivatives or commercially supplied items used as accessories to transfusion.
This field is required for commercial blood products and is not applicable for blood component messages.
Definition: This field indicates the ABO/Rh blood group of the blood component. The preferred values for the blood group are the specified values in Table 3A - Encodation of ABO/Rh Blood Group in the ISBT 128 Application Specification. Refer to Table 0579 - BP Blood Group in Chapter 2C for valid values.
This field is required for blood components and certain commercial products (such as solvent detergent plasma).
Definition: This is a repeating field to allow multiple entries for special testing that was performed on the blood component. The preferred coding system for Special Testing is defined in the ISBT 128 Application Specification. Proposals have been developed and will soon be published by ICCBBA, Inc. for the encodation of other antigen and antibody specificities, including HLA, platelet, red cell and other types of markers. Refer to Table 0580 - BC Special Testing in Chapter 2C for valid values.
This field is optional for blood component messages. It is not applicable for non-commercial product messages.
Refer to Table I3 - Special Testing Codes of the ISBT 128 Application Specification.
Definition: This field specifies the date and time that the blood product expires. The blood product is no longer considered acceptable once the expiration date has been reached unless cleared by the transfusion service medical staff.
This field applies to blood components as well as commercial products. There are a few commercial products that have no expiration date. Therefore, the field is not required for those specific products.
Definition: This field indicates the number of blood components or commercial products to which this message refers.
Definition: This field contains the ordered amount (volume) associated with each quantity of a blood component or commercial product to which this message refers.
Definition: This field contains the units of measure for the blood product amount. (See Chapter 7 for more details about reporting units.) This field specifies the units of measure for volume of a blood component (i.e., 50 ml) or the units of measure or dosage of a commercial product (i.e., 910 I.U. - International Units - of Factor VIII Concentrate). Refer to Table 0581 - BP Units in Chapter 2C for valid values.
Definition: This field is a unique system-generated number assigned to the blood product to which the message is referring. Each time the status is updated, the new message should replace the previous message if the Blood Product Unique ID is the same. If the Blood Product Unique ID is different, it indicates that the status applies to a different blood product.
The sending and receiving systems must agree upon the use of this field.
Definition: This field contains the inpatient or outpatient location to which the blood product was actually dispensed. The default value is the current census location for the patient.
Definition: This field contains the actual address of the location to which the blood product was actually dispensed.
Definition: This is the person who picked up and transported the blood component(s) or commercial product(s). The code for the receiver is recorded as a XCN data type. This field can be free text. In this case, the receiver's name must be recorded as the second through fourth components of the field.
Definition: This field identifies the individual who is dispensing the blood component or commercial product.
(Definition from OH1.2 in Ch. 3)
Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from OH2.2 in Ch. 3)
Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from OH3.2 in Ch. 3)
Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from OH4.2 in Ch. 3)
Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from ORC.35 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when either ORC-2 and/or ORC 3 is valued with a unique identifier in accordance with Chapter 2, Section 2.10.4.2.
(Definition from OBR.55 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when either an OBR-2 and/or OBR-3 is valued with unique identifier in accordance with Chapter 2, Section 2.10.4.2.
(Definition from IPC.10 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when the combination of IPC-1, IPC-2, IPC-3, and IPC-4 represents a unique identifier according to Chapter 2, Section 2.10.4.2.
(Definition from BPX.22 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an BPX is uniquely identified sufficiently within the specific implementation using BPX-17 or BPX-6 as agreed to by the trading partners and in accordance with Chapter 2, Section 2.10.4.2.
(Definition from BTX.21 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an BTX is uniquely identified sufficiently within the specific implementation using BTX-20 or BTX-3 as agreed to by the trading partners in accordance with Chapter 2, Section 2.10.4.2.
(Definition from DON.34 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an DON is uniquely identified sufficiently within the specific implementation using DON-1 in accordance with Chapter 2, Section 2.10.4.2.
(Definition from BUI.13 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an BUI is uniquely identified sufficiently within the specific implementation using BUI-2 in accordance with Chapter 2, Section 2.10.4.2
(Definition from RXV.22 in Ch. 4A)
Definition: The intended handling by the receiver of the infusion order is represented by this segment. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from CDO.2 in Ch. 4A)
Definition: The Action Code indicates whether the cumulative dosage segment is intended to be added, deleted, updated, or did not change. If the field is not valued in any CDO segments for the order, the segments are considered to have been sent in snapshot mode. If some but not all CDO segments for the order do not have the action code valued, the default value is Add. Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from OBR.55 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an either OBR-2 and/or OBR-3 is valued with unique identifier in accordance with Chapter 2, Section 2.10.4.2.
(Definition from OBX.31 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an OBX-21 is valued in accordance with guidance in Chapter 2, Section 2.10.4.2.
(Definition from SPM.35 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an SPM-2 or SPM-31 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.
(Definition from PRT.2 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0287 – Problem/goal action code for valid values.
(Definition from CSR.17 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when CSR-1 and CSR-4, or CSR-2 and CSR-5 are valued as agreed to by the trading partners in accordance with the guidance in Chapter 2, Section 2.10.4.2.
(Definition from CTI.4 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when CTI-1 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.
(Definition from SHP.12 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when SHP-1 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.
(Definition from PAC.9 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when PAC-2 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.
(Definition from GOL.1 in Ch. 12)
Definition: The action code field gives the intent of the problem or goal. Refer to HL7 Table 0287 – Problem/Goal Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from PRB.1 in Ch. 12)
Definition: This field contains the intent of the message. Refer to HL7 Table 0287 – Problem/Goal Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from PTH.1 in Ch. 12)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0287 – Problem/Goal Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from DEV.1 in Ch. 17)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0287 – Problem/goal action code for valid values.
Seq# | DataElement | Description | Must Implement | Flags | Cardinality | Length | C.LEN | Vocabulary | DataType |
---|---|---|---|---|---|---|---|---|---|
BTX | |||||||||
1 | 01735 | Set ID – BTX | SHALL | [1..1] | [1..4] | SI | |||
2
|
01736 | BC Donation ID |
MAY
True: False: |
C |
[1..1] [0..1] |
EI | |||
3
|
01737 | BC Component |
MAY
True: False: |
C |
[1..1] [0..1] |
CNE | |||
4
|
01738 | BC Blood Group |
MAY
True: False: |
C |
[1..1] [0..1] |
CNE | |||
5
|
01739 | CP Commercial Product |
MAY
True: False: |
C |
[1..1] [0..1] |
CWE | |||
6
|
01740 | CP Manufacturer |
MAY
True: False: |
C |
[1..1] [0..1] |
XON | |||
7
|
01741 | CP Lot Number |
MAY
True: False: |
C |
[1..1] [0..1] |
EI | |||
8 | 01742 | BP Quantity | SHALL | = | [1..1] | 5 | NM | ||
9 | 01743 | BP Amount | = | [0..1] | 5 | NM | |||
10 | 01744 | BP Units | [0..1] | CWE | |||||
11 | 01745 | BP Transfusion/Disposition Status | SHALL | [1..1] | CWE | ||||
12 | 01746 | BP Message Status | SHALL | [1..1] | [1..1] | ID | |||
13 | 01747 | BP Date/Time of Status | SHALL | [1..1] | DTM | ||||
14 | 01748 | BP Transfusion Administrator | [0..1] | XCN | |||||
15 | 01749 | BP Transfusion Verifier | [0..1] | XCN | |||||
16 | 01750 | BP Transfusion Start Date/Time of Status | [0..1] | DTM | |||||
17 | 01751 | BP Transfusion End Date/Time of Status | [0..1] | DTM | |||||
18 | 01752 | BP Adverse Reaction Type | [0..*] | CWE | |||||
19 | 01753 | BP Transfusion Interrupted Reason | [0..1] | CWE | |||||
20 | 03391 | BP Unique ID | [0..1] | EI | |||||
21 | 00816 | Action Code | [0..1] | [2..2] | ID |
Definition: This field contains the sequence number for the BTX segment under the related BPO segment. For the first product transfusion/disposition transmitted, the sequence number shall be 1; for the second product transfusion/disposition, it shall be 2; and so on.
Definition: The donation ID is the unique identification number assigned to a blood donation. The Donation ID depends upon the bar code labeling system used for the component. There are currently two blood component labeling standards: ABC CODABAR and ISBT 128. The preferred labeling system is ISBT 128. If using ISBT 128, the Donation ID is an internationally unique identifier consisting of the following 13 characters:
Country Code & Collection Facility - 5 characters
Donation Year - 2 characters
Serial Number - 6 characters
This is required for blood components and is not applicable for commercial product messages.
Definition: The Blood Component field includes an identifier and description of the specific blood component. Refer to Table 0582 - BC Component in Chapter 2C for valid values.
The identifier consists of a numeric or alphanumeric product code that represents the type of blood component. The coding system will be determined by the bar code labeling system on the particular component of blood. The preferred coding system is ISBT 128.
If using ISBT 128 labeling standard, the product code will consist of an 8-character alphanumeric code, starting with an alpha character and including the component class, donation type/intended use and division indicator.
If using CODABAR product labeling standard, the product code is a 5-digit number.
This field is required for blood components and is not applicable for commercial product messages.
Definition: This field indicates the ABO/Rh blood group of the blood component. The preferred values for the blood group are the specified values in Table 3A - Encodation of ABO/Rh Blood Group in the ISBT 128 Application Specification. Refer to Table 0583 - BC Blood Group in Chapter 2C for valid values.
This field is required for blood components and certain commercial products (such as solvent detergent plasma).
Definition: This field contains the code and/or text to identify a commercial product. Examples of commercial products are blood derivatives such as Rh Immune Globulin and Factor VIII concentrate, Leukoreduction filters, and blood administration sets.
Either code and/or text may be absent. However, the code is always placed in the first component position and any free text in the second component. Thus, free text without a code must be preceded by a component delimiter. Free text can be utilized if no update is to occur. Refer to User-Defined Table 0512 - Commercial Product in Chapter 2C, Code Tables, for suggested values.
This field is required for commercial blood products and is not applicable to blood component messages.
Definition: This field identifies the manufacturer of the commercial product. The manufacturer may not be the same as the supplier of the commercial product.
This field is required for commercial blood products and is not applicable for blood component messages.
Definition: This field identifies the lot number for blood derivatives or commercially supplied items used as accessories to transfusion.
This field is required for commercial blood products and is not applicable for blood component messages.
Definition: This field indicates the number of blood components or commercial products to which the message refers.
Definition: This field contains the amount (volume) associated with each blood component or commercial product. When included in this segment, it may be used to indicate the volume of the blood component or product that was actually transfused.
Definition: This field contains the units of measure for the blood component or commercial product amount. (See Chapter 7 for more details about reporting units.) This specifies the units of measure for volume of a blood component (i.e., 50 ml) or the units of measure or dosage of a commercial product (i.e., 910 I.U. - International Units - of Factor VIII Concentrate). Refer to Table 0584 - BP Units in Chapter 2C for valid values.
Definition: This field indicates the current status of the specified blood product as indicated by the placer. For example, the placer may return the blood product to the transfusion service unused because an IV could not be started. The blood component may have been entered, but the line was clogged and could not be used, in which case the component must be wasted. A final status would indicate that the product has actually been "transfused." Refer to HL7 Table 0513 - Blood Product Transfusion/Disposition Status in Chapter 2C, Code Tables, for suggested values.
Definition: The most commonly used message status values in a BTX will be preliminary and final. A status is considered preliminary until a blood product has reached a final disposition for the patient. For example, when the product is first cross-matched and a status message is sent, it would be considered preliminary. When the product is dispensed to the patient, that status would also be considered preliminary. However, once the product is transfused, the status would be considered final. The status of a blood product (BTX-11) can continue to change and the previous result should be overwritten until it reaches a final status (BTX-12). Refer to HL7 Table 0511 – BP Observation Status Codes Interpretation in Chapter 2C, Code Tables, for valid entries.
Definition: This field indicates the date and time that the status of the blood component was changed. For example, if the blood component had a status of "TX" (Transfused), the date and time in this field would indicate the date and time the component was transfused by the placer system.
Definition: This field contains the identity of the individual who administers the transfusion of the blood product. If the code is sent as a local code, it should be unique and unambiguous. This field can be free text to permit capture without table update. In this case, the administrator's name must be recorded as the second through fourth components of the field.
Definition: This field contains the identity of the individual who assists in the identification of the patient and verification of the product information prior to transfusion of the blood product. If the ID Number is sent as a local code, it should be unique and unambiguous. This field can be free text to permit capture without table update. In this case, the verifier's name must be recorded as the second through fourth components of the field.
Definition: This field indicates the date and time that the administrator started the transfusion of the blood component or commercial product.
Definition: This field indicates the date and time that the transfusion of the blood component or commercial product was completed or stopped.
Definition: This field contains the type of adverse reaction that the recipient of the blood product experienced. Refer to User-Defined Table 0514 - Transfusion Adverse Reaction in Chapter 2C, Code Tables, for suggested values.
Definition: This field contains the reason that the transfusion of the blood product was interrupted. Refer to User-Defined Table 0515 - Transfusion Interrupted Reason in Chapter 2C, Code Tables, for suggested values.
Definition: This field is a unique system-generated number assigned to the blood product to which the message is referring. Each time the status is updated, the new message should replace the previous message if the Blood Product Unique ID is the same. If the Blood Product Unique ID is different, it indicates that the status applies to a different blood product.
(Definition from OH1.2 in Ch. 3)
Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from OH2.2 in Ch. 3)
Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from OH3.2 in Ch. 3)
Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from OH4.2 in Ch. 3)
Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from ORC.35 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when either ORC-2 and/or ORC 3 is valued with a unique identifier in accordance with Chapter 2, Section 2.10.4.2.
(Definition from OBR.55 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when either an OBR-2 and/or OBR-3 is valued with unique identifier in accordance with Chapter 2, Section 2.10.4.2.
(Definition from IPC.10 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when the combination of IPC-1, IPC-2, IPC-3, and IPC-4 represents a unique identifier according to Chapter 2, Section 2.10.4.2.
(Definition from BPX.22 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an BPX is uniquely identified sufficiently within the specific implementation using BPX-17 or BPX-6 as agreed to by the trading partners and in accordance with Chapter 2, Section 2.10.4.2.
(Definition from BTX.21 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an BTX is uniquely identified sufficiently within the specific implementation using BTX-20 or BTX-3 as agreed to by the trading partners in accordance with Chapter 2, Section 2.10.4.2.
(Definition from DON.34 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an DON is uniquely identified sufficiently within the specific implementation using DON-1 in accordance with Chapter 2, Section 2.10.4.2.
(Definition from BUI.13 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an BUI is uniquely identified sufficiently within the specific implementation using BUI-2 in accordance with Chapter 2, Section 2.10.4.2
(Definition from RXV.22 in Ch. 4A)
Definition: The intended handling by the receiver of the infusion order is represented by this segment. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from CDO.2 in Ch. 4A)
Definition: The Action Code indicates whether the cumulative dosage segment is intended to be added, deleted, updated, or did not change. If the field is not valued in any CDO segments for the order, the segments are considered to have been sent in snapshot mode. If some but not all CDO segments for the order do not have the action code valued, the default value is Add. Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from OBR.55 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an either OBR-2 and/or OBR-3 is valued with unique identifier in accordance with Chapter 2, Section 2.10.4.2.
(Definition from OBX.31 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an OBX-21 is valued in accordance with guidance in Chapter 2, Section 2.10.4.2.
(Definition from SPM.35 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an SPM-2 or SPM-31 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.
(Definition from PRT.2 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0287 – Problem/goal action code for valid values.
(Definition from CSR.17 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when CSR-1 and CSR-4, or CSR-2 and CSR-5 are valued as agreed to by the trading partners in accordance with the guidance in Chapter 2, Section 2.10.4.2.
(Definition from CTI.4 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when CTI-1 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.
(Definition from SHP.12 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when SHP-1 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.
(Definition from PAC.9 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when PAC-2 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.
(Definition from GOL.1 in Ch. 12)
Definition: The action code field gives the intent of the problem or goal. Refer to HL7 Table 0287 – Problem/Goal Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from PRB.1 in Ch. 12)
Definition: This field contains the intent of the message. Refer to HL7 Table 0287 – Problem/Goal Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from PTH.1 in Ch. 12)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0287 – Problem/Goal Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from DEV.1 in Ch. 17)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0287 – Problem/goal action code for valid values.
The following diagram depicts the message flow of the blood product messages.
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.
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.
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.
For Directed and Autologous Donations, this is the Healthcare Provider requesting a blood donation.
All donors are registered in this system.
This is the source-of-truth for every donor, whether evaluated and deferred, rejected, or not deferred.
The mini-physical examination conducted on all potential donors is documented using this system.
Each potential donor must fill out a questionnaire which asks about previous medical history and risk factors using this documentation system.
The phlebotomists and other healthcare professionals use this system to document the blood donation procedure.
Interface to devices used during the mini-physical, donation, and shipping systems.
This system keeps the master list of providers.
This system is used to document the shipping manifest from information received from the actual donations.
The Create Donor Record messages contain information to create a new donor book of record.
Send Application Ack: ACK^O41^ACK
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, 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, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^O41^ACK |
NE | (none) | |
MSH-16 | AL, ER, SU | application ack: ACK^O41^ACK |
NE | (none) |
The Update Donor Record messages contain information to update an existing donor book of record.
Send Application Ack: ACK^O42^ACK
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, 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, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^O42^ACK |
NE | (none) | |
MSH-16 | AL, ER, SU | application ack: ACK^O42^ACK |
NE | (none) |
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 |
Send Application Ack: RSP^K33^RSP_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, 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, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: RSP^K33^RSP_O33 |
NE | (none) | |
MSH-16 | AL, ER, SU | application ack: RSP^K33^RSP_O33 |
NE | (none) |
Send Immediate Ack: ACK^K33^ACK
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, an immediate ack SHALL NOT be sent.
Never send an application ack in enhanced mode.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^K33^ACK |
NE | (none) | |
MSH-16 | NE | (none) |
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).
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 |
Send Application Ack: RSP^K34^RSP_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, 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, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: RSP^K34^RSP_O34 |
NE | (none) | |
MSH-16 | AL, ER, SU | application ack: RSP^K34^RSP_O34 |
NE | (none) |
Send Immediate Ack: ACK^K34^ACK
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, an immediate ack SHALL NOT be sent.
Never send an application ack in enhanced mode.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^K34^ACK |
NE | (none) | |
MSH-16 | NE | (none) |
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).
The Donor Registration messages contain information to register a donor for a donation.
Send Application Ack: ACK^O43^ACK
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, 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, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^O43^ACK |
NE | (none) | |
MSH-16 | AL, ER, SU | application ack: ACK^O43^ACK |
NE | (none) |
The Donor Registration messages contain minimal information about a donor registration.
Send Application Ack: ACK^O44^ACK
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, 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, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^O44^ACK |
NE | (none) | |
MSH-16 | AL, ER, SU | application ack: ACK^O44^ACK |
NE | (none) |
Communicate both mini-physical observations and questions and answers from a donor questionnaire.
Send Application Ack: ACK^O45^ACK
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, 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, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^O45^ACK |
NE | (none) | |
MSH-16 | AL, ER, SU | application ack: ACK^O45^ACK |
NE | (none) |
Use this message to communicate a donor’s eligibility to donate.
Send Application Ack: ACK^O46^ACK
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, 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, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^O46^ACK |
NE | (none) | |
MSH-16 | AL, ER, SU | application ack: ACK^O46^ACK |
NE | (none) |
Used to communicate to a collection system that the donor is eligible and collection can begin.
Send Application Ack: ACK^O47^ACK
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, 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, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^O47^ACK |
NE | (none) | |
MSH-16 | AL, ER, SU | application ack: ACK^O47^ACK |
NE | (none) |
This message contains information from the blood unit collection procedure from the donor.
Send Application Ack: ACK^O48^ACK
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, 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, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^O48^ACK |
NE | (none) | |
MSH-16 | AL, ER, SU | application ack: ACK^O48^ACK |
NE | (none) |
The intent of this segment is to describe the actual donation procedure.
Seq# | DataElement | Description | Must Implement | Flags | Cardinality | Length | C.LEN | Vocabulary | DataType |
---|---|---|---|---|---|---|---|---|---|
DON | |||||||||
1
|
03340 | Donation Identification Number - DIN |
MAY
True: False: |
C |
[1..1] [0..1] |
EI | |||
2
|
03341 | Donation Type |
MAY
True: False: |
C |
[1..1] [0..1] |
CNE | |||
3 | 03342 | Phlebotomy Start Date/Time | SHALL | [1..1] | DTM | ||||
4 | 03343 | Phlebotomy End Date/Time | SHALL | [1..1] | DTM | ||||
5 | 03344 | Donation Duration | SHALL | [1..1] | NM | ||||
6 | 03345 | Donation Duration Units | SHALL | [1..1] | CNE | ||||
7 | 03346 | Intended Procedure Type | SHALL | [1..*] | CNE | ||||
8 | 03347 | Actual Procedure Type | SHALL | [1..*] | CNE | ||||
9 | 03348 | Donor Eligibility Flag | SHALL | [1..1] | ID | ||||
10 | 03349 | Donor Eligibility Procedure Type | SHALL | [1..*] | CNE | ||||
11 | 03350 | Donor Eligibility Date | SHALL | [1..1] | DTM | ||||
12 | 03351 | Process Interruption | SHALL | [1..1] | CNE | ||||
13 | 03352 | Process Interruption Reason | SHALL | [1..1] | CNE | ||||
14 | 03353 | Phlebotomy Issue | SHALL | [1..*] | CNE | ||||
15 | 03354 | Intended Recipient Blood Relative | SHALL | [1..1] | ID | ||||
16 | 03355 | Intended Recipient Name | SHALL | [1..1] | XPN | ||||
17 | 03356 | Intended Recipient DOB | SHALL | [1..1] | DTM | ||||
18 | 03357 | Intended Recipient Facility | SHALL | [1..1] | XON | ||||
19 | 03358 | Intended Recipient Procedure Date | SHALL | [1..1] | DTM | ||||
20 | 03359 | Intended Recipient Ordering Provider | SHALL | [1..1] | XPN | ||||
21 | 03360 | Phlebotomy Status | SHALL | [1..1] | CNE | ||||
22 | 03361 | Arm Stick | SHALL | [1..1] | CNE | ||||
23 | 03362 | Bleed Start Phlebotomist | SHALL | [1..1] | XPN | ||||
24 | 03363 | Bleed End Phlebotomist | SHALL | [1..1] | XPN | ||||
25 | 03364 | Aphaeresis Type Machine | SHALL | # | [1..1] | 75 | ST | ||
26 | 03365 | Aphaeresis Machine Serial Number | SHALL | # | [1..1] | 25 | ST | ||
27 | 03366 | Donor Reaction | SHALL | [1..1] | ID | ||||
28 | 03367 | Final Review Staff ID | SHALL | [1..1] | XPN | ||||
29 | 03368 | Final Review Date/Time | SHALL | [1..1] | DTM | ||||
30 | 03369 | Number of Tubes Collected | SHALL | [1..1] | NM | ||||
31 | 03370 | Donation Sample Identifier | SHALL | [1..*] | EI | ||||
32 | 03371 | Donation Accept Staff | SHALL | [1..1] | XCN | ||||
33 | 03372 | Donation Material Review Staff | SHALL | [1..*] | XCN | ||||
34 | 00816 | Action Code | [0..1] | [2..2] | ID |
Definition: This field contains a unique identifier, Donation Identification Number (DIN), for the specific donation and is therefore mandatory except when using an eligibility message type in which only DON-9, DON-10, and DON-11 are populated. DON-2 Donation Type (CNE) 03341
Definition: The type of donation. This element is mandatory except when using an eligibility message type in which only DON-9, DON-10, and DON-11 are populated. The values for this field are defined in Table RT008 - Type of Donation or Collection in 6th Position of Product Code in the ISBT 128 Standard Technical Specification, which is maintained by ICCBBA. Link: http://iccbba.org/technicalspecification.pdf. Table 5 Data Structure 002.
Definition: The start date and time of the phlebotomy.
Definition: The end date and time of the phlebotomy.
Definition: The duration of the phlebotomy or the length of time that elapsed between the phlebotomy start date and time and the phlebotomy end date and time.
Definition: The duration units. The duration units and duration are restricted to minutes and seconds. Concepts are pulled from the UCUM code system (www.unitsofmeasure.org). Refer to HL7-Defined Table 0932 – Donation Duration Units in Chapter 2C, Code Tables, for valid entries.
Definition: The procedure(s) intended to be performed on the donor. Refer to HL7-Defined Table 0933 – Intended Procedure Type in Chapter 2C, Code Tables, for valid entries.
Definition: The actual procedure(s) performed on the donor. Refer to HL7-Defined Table 0933 – Intended Procedure Type in Chapter 2C, Code Tables, for valid entries.
Definition: Is the Donor eligible for donation? Yes or No. Refer to HL7 Table 0136 -Yes/No Indicator as defined in Chapter 2C, Code Tables.
Definition: The procedure(s) for which the donor is eligible. Refer to HL7-Defined Table 0933 – Intended Procedure Type in Chapter 2C, Code Tables, for valid entries.
Definition: The date and time on which the donor is eligible to donate.
Definition: Was the donation process interrupted after it began? Refer to HL7-Defined Table 0923 – Process Interruption in Chapter 2C, Code Tables, for valid entries.
Definition: Reason that the donation process was interrupted. Refer to HL7-Defined Table 0935 – Process Interruption Reason in Chapter 2C, Code Tables, for valid entries.
Definition: Indicates whether there is a problem or issue with the phlebotomy itself. This may be due to an incorrect needle procedure, needle defect, tube blockage, problem with the apheresis machine, or improper action by the phlebotomist. Refer to HL7-Defined Table 0925 – Phlebotomy Issue in Chapter 2C, Code Tables, for valid entries.
Definition: If this donation has an intended recipient (directed, dedicated, designated), is the intended recipient a blood relative of the donor? Yes or No. Refer to HL7 Table 0136 -Yes/No Indicator as defined in Chapter 2C, Code Tables.
Definition: If this is donation has an intended recipient (autologous, directed, dedicated, designated), the intended recipient’s name.
Definition: If this donation has an intended recipient (autologous, directed, dedicated, designated), the intended recipient’s date of birth.
Definition: If this donation has an intended recipient (autologous, directed, dedicated, designated), the facility where the intended recipient is expected to receive the transfusion.
Definition: If this donation has an intended recipient (autologous, directed, dedicated, designated), the date the intended recipient is expected to receive the transfusion.
Definition: If this is donation has an intended recipient (autologous, directed, dedicated, designated), the provider who ordered the directed donation for the intended recipient.
Definition: Whether the phlebotomy was successful, not drawn, or unsuccessful, and if unsuccessful, the extent to which it was unsuccessful. Refer to HL7-Defined Table 0926 – Phlebotomy Status in Chapter 2C, Code Tables, for valid entries.
Definition: The arm(s) stuck for the donation. Refer to HL7-Defined Table 0927 – Arm Stick in Chapter 2C, Code Tables, for valid entries.
Definition: The Phlebotomist who starts the blood flow into the container.
Definition: The Phlebotomist who ends the blood flow into the container.
Definition: The type of aphaeresis machine, if used, for the donation. It will be the specific product name of the machine (e.g. Trima, Amicus, Alyx, Symal, etc.).
Definition: The serial number of the aphaeresis machine, if used, for the donation.
Definition: Did the donor have any adverse reaction during the donation procedure? Yes or No. Refer to HL7 Table 0136 -Yes/No Indicator as defined in Chapter 2C, Code Tables. If this element is valued "Y"es, there should be OBX segments following the Donation segment which details the adverse reactions.
Definition: The Staff member conducting the final review and reconciliation of all documentation created during the collection process.
Definition: The date and time a final review of all documentation and labeling of the blood material is completed.
Definition: The number of samples collected during the donation which will be used for subsequent testing.
Definition: The sample identifier for the sample collected during a donation for the purpose of testing. This is a field for sample or specimen identifiers.
Definition: The staff member who reviewed all the intake materials, assessments and determined the donor can undergo a donation procedure at this time.
Definition: The staff member who performs review on all documentation subsequent to donation procedure.
(Definition from OH1.2 in Ch. 3)
Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from OH2.2 in Ch. 3)
Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from OH3.2 in Ch. 3)
Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from OH4.2 in Ch. 3)
Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from ORC.35 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when either ORC-2 and/or ORC 3 is valued with a unique identifier in accordance with Chapter 2, Section 2.10.4.2.
(Definition from OBR.55 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when either an OBR-2 and/or OBR-3 is valued with unique identifier in accordance with Chapter 2, Section 2.10.4.2.
(Definition from IPC.10 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when the combination of IPC-1, IPC-2, IPC-3, and IPC-4 represents a unique identifier according to Chapter 2, Section 2.10.4.2.
(Definition from BPX.22 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an BPX is uniquely identified sufficiently within the specific implementation using BPX-17 or BPX-6 as agreed to by the trading partners and in accordance with Chapter 2, Section 2.10.4.2.
(Definition from BTX.21 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an BTX is uniquely identified sufficiently within the specific implementation using BTX-20 or BTX-3 as agreed to by the trading partners in accordance with Chapter 2, Section 2.10.4.2.
(Definition from DON.34 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an DON is uniquely identified sufficiently within the specific implementation using DON-1 in accordance with Chapter 2, Section 2.10.4.2.
(Definition from BUI.13 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an BUI is uniquely identified sufficiently within the specific implementation using BUI-2 in accordance with Chapter 2, Section 2.10.4.2
(Definition from RXV.22 in Ch. 4A)
Definition: The intended handling by the receiver of the infusion order is represented by this segment. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from CDO.2 in Ch. 4A)
Definition: The Action Code indicates whether the cumulative dosage segment is intended to be added, deleted, updated, or did not change. If the field is not valued in any CDO segments for the order, the segments are considered to have been sent in snapshot mode. If some but not all CDO segments for the order do not have the action code valued, the default value is Add. Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from OBR.55 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an either OBR-2 and/or OBR-3 is valued with unique identifier in accordance with Chapter 2, Section 2.10.4.2.
(Definition from OBX.31 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an OBX-21 is valued in accordance with guidance in Chapter 2, Section 2.10.4.2.
(Definition from SPM.35 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an SPM-2 or SPM-31 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.
(Definition from PRT.2 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0287 – Problem/goal action code for valid values.
(Definition from CSR.17 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when CSR-1 and CSR-4, or CSR-2 and CSR-5 are valued as agreed to by the trading partners in accordance with the guidance in Chapter 2, Section 2.10.4.2.
(Definition from CTI.4 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when CTI-1 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.
(Definition from SHP.12 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when SHP-1 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.
(Definition from PAC.9 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when PAC-2 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.
(Definition from GOL.1 in Ch. 12)
Definition: The action code field gives the intent of the problem or goal. Refer to HL7 Table 0287 – Problem/Goal Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from PRB.1 in Ch. 12)
Definition: This field contains the intent of the message. Refer to HL7 Table 0287 – Problem/Goal Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from PTH.1 in Ch. 12)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0287 – Problem/Goal Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from DEV.1 in Ch. 17)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0287 – Problem/goal action code for valid values.
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.
Seq# | DataElement | Description | Must Implement | Flags | Cardinality | Length | C.LEN | Vocabulary | DataType |
---|---|---|---|---|---|---|---|---|---|
BUI | |||||||||
1 | 03373 | Set ID – BUI | [0..1] | [1..4] | SI | ||||
2 | 03374 | Blood Unit Identifier | SHALL | [1..1] | EI | ||||
3 | 03375 | Blood Unit Type | SHALL | [1..1] | CWE | ||||
4 | 03376 | Blood Unit Weight | SHALL | [1..1] | NM | ||||
5 | 03377 | Weight Units | SHALL | [1..1] | CNE | ||||
6 | 03378 | Blood Unit Volume | SHALL | [1..1] | NM | ||||
7 | 03379 | Volume Units | SHALL | [1..1] | CNE | ||||
8 | 03380 | Container Catalog Number | SHALL | [1..1] | ST | ||||
9 | 03381 | Container Lot Number | SHALL | [1..1] | ST | ||||
10 | 03382 | Container Manufacturer | SHALL | [1..1] | XON | ||||
11 | 03383 | Transport Temperature | SHALL | [1..1] | NR | ||||
12 | 03384 | Transport Temperature Units | SHALL | [1..*] | CNE | ||||
13 | 00816 | Action Code | [0..1] | [2..2] | ID |
Definition: This field contains a sequence number. When multiple BUI segments are included in the same segment group, this number differentiates between them.
Definition: The blood unit identifier is a unique identifier assigned to the particular blood unit in a container.
Definition: The type of blood unit. For donations, this is the type blood unit being described. This element defines which of the types from the referenced table are being described. Refer to HL7-Defined Table 0566 – Blood Unit Type in Chapter 2C, Code Tables, for valid entries.
Definition: The weight of the blood unit collected, not including the weight of the container.
Definition: The unit of measure for the weight of the blood unit. Concepts are pulled from the UCUM code system (www.unitsofmeasure.org). Refer to HL7-Defined Table 0929 – Weight Units in Chapter 2C, Code Tables, for valid entries.
Definition: The volume of the blood unit collected.
Definition: The unit of measure for the volume of the blood unit. Concepts are pulled from the UCUM code system (www.unitsofmeasure.org). Refer to HL7-Defined Table 0930 – Volume Units in Chapter 2C, Code Tables, for valid entries.
Definition: The string catalog number of the blood unit container, which includes a specific container code to identify a collection bag.
Definition: The lot number for the collection bag container as assigned by the container manufacturer.
Definition: The organization which manufactured the collection bag container.
Definition: The temperature range between which the blood unit must be kept during transport.
Definition: The unit of measure of the transport temperature range. Concepts are pulled from the UCUM code system (www.unitsofmeasure.org). Refer to HL7-Defined Table 0931 – Temperature Units in Chapter 2C, Code Tables, for valid entries.
(Definition from OH1.2 in Ch. 3)
Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from OH2.2 in Ch. 3)
Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from OH3.2 in Ch. 3)
Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from OH4.2 in Ch. 3)
Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from ORC.35 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when either ORC-2 and/or ORC 3 is valued with a unique identifier in accordance with Chapter 2, Section 2.10.4.2.
(Definition from OBR.55 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when either an OBR-2 and/or OBR-3 is valued with unique identifier in accordance with Chapter 2, Section 2.10.4.2.
(Definition from IPC.10 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when the combination of IPC-1, IPC-2, IPC-3, and IPC-4 represents a unique identifier according to Chapter 2, Section 2.10.4.2.
(Definition from BPX.22 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an BPX is uniquely identified sufficiently within the specific implementation using BPX-17 or BPX-6 as agreed to by the trading partners and in accordance with Chapter 2, Section 2.10.4.2.
(Definition from BTX.21 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an BTX is uniquely identified sufficiently within the specific implementation using BTX-20 or BTX-3 as agreed to by the trading partners in accordance with Chapter 2, Section 2.10.4.2.
(Definition from DON.34 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an DON is uniquely identified sufficiently within the specific implementation using DON-1 in accordance with Chapter 2, Section 2.10.4.2.
(Definition from BUI.13 in Ch. 4)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an BUI is uniquely identified sufficiently within the specific implementation using BUI-2 in accordance with Chapter 2, Section 2.10.4.2
(Definition from RXV.22 in Ch. 4A)
Definition: The intended handling by the receiver of the infusion order is represented by this segment. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from CDO.2 in Ch. 4A)
Definition: The Action Code indicates whether the cumulative dosage segment is intended to be added, deleted, updated, or did not change. If the field is not valued in any CDO segments for the order, the segments are considered to have been sent in snapshot mode. If some but not all CDO segments for the order do not have the action code valued, the default value is Add. Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from OBR.55 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an either OBR-2 and/or OBR-3 is valued with unique identifier in accordance with Chapter 2, Section 2.10.4.2.
(Definition from OBX.31 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an OBX-21 is valued in accordance with guidance in Chapter 2, Section 2.10.4.2.
(Definition from SPM.35 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when an SPM-2 or SPM-31 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.
(Definition from PRT.2 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0287 – Problem/goal action code for valid values.
(Definition from CSR.17 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when CSR-1 and CSR-4, or CSR-2 and CSR-5 are valued as agreed to by the trading partners in accordance with the guidance in Chapter 2, Section 2.10.4.2.
(Definition from CTI.4 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when CTI-1 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.
(Definition from SHP.12 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when SHP-1 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.
(Definition from PAC.9 in Ch. 7)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.
The action code can only be used when PAC-2 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.
(Definition from GOL.1 in Ch. 12)
Definition: The action code field gives the intent of the problem or goal. Refer to HL7 Table 0287 – Problem/Goal Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from PRB.1 in Ch. 12)
Definition: This field contains the intent of the message. Refer to HL7 Table 0287 – Problem/Goal Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from PTH.1 in Ch. 12)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0287 – Problem/Goal Action Code in Chapter 2C, Code Tables, for valid values.
(Definition from DEV.1 in Ch. 17)
Definition: This field reveals the intent of the message. Refer to HL7 Table 0287 – Problem/goal action code for valid values.
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.
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.
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.