References to other Chapters

4

• 4
  Chapter 4
  • 4.1 PURPOSE
  • 4.2 TRIGGER EVENTS AND MESSAGE DEFINITIONS
  • 4.3 MESSAGE DEFINITIONS
    • 4.3.1 ORM -- Order message--
    • 4.3.2 ORR -- Response message (response to ORM)--
  • 4.4 SEGMENT DEFINITIONS
    • 4.4.1 Segment ID: ORC - COMMON ORDER/Allg. Anforderung-
    • 4.4.2 SEGMENT: BLG - BILLING/Abrechnung -
    • 4.4.3 SEGMENT: RX1 - PHARMACY ORDER /Arzneimittelanforderung
    • 4.4.4 SEGMENT: ORO - ORDER OTHER /Andere Anforderung
  • 4.5 EXAMPLES OF USE

4
Chapter 4

4.1 PURPOSE

The Order Entry transaction set provides for the transmission of orders or information about orders between systems where they are entered, those where they are processed, and other systems as needed. An order is a request for material or services from a department 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 system may be the placer of an order or the filler of an order).

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 comprise 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 1, "Relationship to Other Protocols." The examples included in this chapter were constructed using the HL7 Encoding Rules.

4.2 TRIGGER EVENTS AND MESSAGE DEFINITIONS

The conceptual basis for this specification is that an order is a request of one application called the "placer" for a service to be performed by another (usually, but not necessarily different) application called the "filler". An order thus defines a task to be done by the filler of the order at the request of the placer. Examples of such tasks are the placing of a clinical laboratory test request, a request for a radiology exam, a request for a medication to be sent to the floor, a request to administer a medication to a patient, a request to send a biopsy tray to a ward location, etc. Most orders are relative to a particular patient, but not all. Each order is associated with a Common Order segment (ORC) and multiple orders can be can be grouped together in an order group.

Two message types are defined below. The ORM message transmits order data. The ORR message is always a response to an ORM. Each message type is listed below, along with the applicable form of the message exchange.

The notation used to describe the sequence, optionality, and repeating of segments is described in Chapter II, "Format for Defining Abstract Messages."

An order for a patient is a message that usually takes three parts. First is the MSH segment. Following this is the information about the patient (PID and PV1). If three orders were written for the clinical laboratory and three for pharmacy, an ORM would be sent to the clinical laboratory with its three order segments for the clinical laboratory. Another ORM message would go to the pharmacy with the three pharmacy order segments.

The basic ORM message can be embellished in several ways. For example, one or more comment (NTE) segments can follow any of the records in the hierarchy. The comment segment applies to the immediately preceding non-comment segment. A comment about the patient would immediately follow the patient segment.

Observations are returned to the requesting system with a similar message structure (the ORU) that also includes a 4th message component -- the results themselves. See Chapter VII for the details of result reporting. In the previous version of the Standards, clinical information needed to interpret a diagnostic study could only be transmitted as free text in the Observation Request (OBR) segment (previously called LTS). It can now also be sent in a structured manner. See example, ORC field notes.

Thus, an original order may also have accompanying "results". These are not the results of the tests ordered. Rather, they are clinical observations needed to support an order being entered.

When an arterial blood gas is ordered, for example, the clinical services could indicate the amount of inspired O2 by sending this information as a "result record".

Similarly, when a cervical pap smear is ordered, the Cytology service needs information about the date of last menstrual period, the use of birth control pills, etc. Such information can also be sent as result segments that immediately follow the order segment to which it applies. When results are reported in an order message, they will be immediately preceded by their own ORC and order segment. The details of how to do this are presented below in the ORC field notes.

In this version, the earlier Patient Order Data (POD) segment (that contained a few items of patient-specific clinical data) has been eliminated. All such data can be transmitted with an order by including observation segments as described below.

The name of the order detail segment has been changed to Order Other to clarify its role. Thus, the Order Other segment (ORO) is for non-pharmacy, and non-observation producing services, e.g., dietary. It may also be used for non-patient orders.

In this version of the Standard, the Radiology Order segment has been eliminated. The appropriate fields (e.g., methods of transport) were added to the Observation Request segment OBR needed to satisfy informational needs of radiology ordering and reporting. (The OBR record is documented in detail in Chapter VII.)
Glossary
Order An order is 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.

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

Filler The application (system or individual) receiving and responding to a request for services (order).

Order Group A list of associated orders coming from a single location regarding a single patient.
Order Segment One of several segments that can carry order information. For example, OBR, ORO, and RX1. Future ancillary-specific segments may be defined in subsequent releases of the Specification if they become necessary.

Observation Segment An OBX segment defined in Chapter VII.

Default ORC If the first component of FILLER ORDER # and PLACER ORDER # of the first ORC of an ORM or an ORR message is null, then that ORC is called a "Default ORC". (See the Use Notes under the ORC segment definition for details.)

4.3 MESSAGE DEFINITIONS

4.3.1 ORM -- Order message--

The function of this message is to initiate the transmission of information about an order. This includes placing new orders, cancellation of existing orders, discontinuation, holding, etc. ORM messages can originate also with a placer, filler or an interested third party.
The trigger event for this message is any change to an order. These include submission of new orders, cancellations, updates, patient and non-patient specific orders, etc.
Definition
ORM ORDER MESSAGE Chapter
MSH Message Header II
[ { NTE} ] Notes and Comments II
[ PID Patient Identification III
[{NTE}] Notes and Comments II
[ PV1 ] Patient Visit III
{
ORC Common Order IV
[
Any Order Segment E.g., ORO, OBR, RX1 IV
[ { NTE } ]
[ { OBX } Results Segment VII
[ { NTE} ]] Notes and Comments II
[ BLG ] Billing segment IV
}
Notes

- The segment named "Any Order Segment" represents whichever of these detail order segments is appropriate to the message, currently ORO, OBR, RX1.

- The NTE Segment(s) can be included in a message after the MSH. In this case it pertains to the entire order. It can also be present after an order detail segment. It then applies to that detail item in the order.

- The PID segment is required if and only if new orders are being entered and they are related to a particular patient. However, it may sometimes be sent for convenience at local discretion, and 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.
- ORC segments are always required in ORM and ORR when a detailed order segment is present, but otherwise not. For example, a response ORR might include only the MSH, and MSA, but if an RX1 is present, it must be preceded by an ORC.

The order segments are not required when a simple control message is being sent. For example, a hold message (ORDER CONTROL = "HD") does not require that an order segment follow it.

- The ORDER CONTROL field of the ORC segment is critical to the operation of both ORM and ORR messages. For example, to cancel an order one would transmit a "CA" in the ORDER CONTROL field of the appropriate ORC. (See the definition of the ORDER CONTROL field in the ORC segment definition.)

- A method to inquire for order status in the display format is provided in Chapter V, and in the record format is provided in Chapter VII.

4.3.2 ORR -- Response message (response to ORM)--

The function of this message is to respond to an ORM message.
Definition
ORR ORDER MESSAGE Chapter
MSH Message Header II
MSA Message Acknowledgement II
[ { NTE} ] Notes and Comments II
[
[ PID ] Patient Identification III
[ { NTE } ] Notes and Comments II
{
ORC Common Order IV
[Any order segment] E.g., ORO, OBR, RX1 IV
[ { NTE} ] Notes and Comments II
}
]
Notes

- An ORR message is always a response to an ORM message. Every ORM requires one and only one response ORR. A minimal response consists of MSH and MSA segments.

- The function (i.e., "cancel", "new order") of both ORM and ORR messages is determined by the ORDER CONTROL field of the ORC segments. (See the table of ORDER CONTROL values under the ORC Field Notes for a complete list.)

4.4 SEGMENT DEFINITIONS

4.4.1 Segment ID: ORC - COMMON ORDER/Allg. Anforderung-

Segment Notes:

- The COMMON ORDER segment is a mechanism for transmitting data common to all orders, i.e., common to all types of services that might be requested. When an order is placed it is followed by a particular order segment (e.g., OBR, ORO, or RX1) that gives details necessary for a particular type of order.

While this is the stated intention of the ORC, in some cases it is nonetheless difficult to decide whether a particular data field should be in the ORC or included in the individual order segments.

- All order segments in ORR and ORM messages must be preceded by an ORC segment (which may be as simple as the string "ORC|OK|<CR>", but ORC segments need not always be followed by order segments when the order segment information is not needed. For example, if one were placing a particular order on hold, it would be sufficient to transmit an ORC with "HD" in the ORDER CONTROL field and the identifier numbers in the two following fields.

- There is some overlap between the fields of the individual order segments and those of the ORC. This is explained in detail under Use Notes.
The ORC segment is a mechanism for transmitting data common to all orders, i.e., common to all types of services that might be requested. When an order is placed, it is followed by a particular order segment(e.g., OBR, ORO, or RX1) that gives details necessary for a particular type of order.

FIELD NOTES: ORC COMMON ORDER 1. 00714 ORDER CONTROL. This is a complicated field that determines the function of the order segment. Refer to table 0119 for valid entries.

Table Columns Legend:

CD The ORDER CONTROL field value.
NT Table notes (listed below).
TO/FROM F = From the FILLER
T = To the FILLER

Table notes:
A. A cancellation (CA) is a request not to do a previously ordered service. For each service there is a point after which a service can no longer be stopped. This is the point at which cancellation is no longer possible. When cancellation is not possible, either because the service is beyond the point of no return or because of local rules about cancellation, then a UC (unable to cancel) code can be returned depending on the RESPONSE FLAG. When and if an order can be canceled is determined by the filling application.

The DC (discontinue) code should be used to stop an on going order. It is distinct from a cancellation in that the cancellation implies an attempt to stop an order from ever happening, if its point-of-no-return has not been passed, whereas a discontinue relates to an ongoing order that should be stopped. The TIMING/QUANTITY field can be used to set the effective time of ORDER CONTROL codes.

B. The NC code is a "NO OP", meaning nothing is to be done. It provides a mechanism for overriding a default value established by a Default ORC thereby saying "this order is unchanged". For example, if one were to wish to cancel all but one order of an order group, one would make the ORDER CONTROL field of the first ORC of the message "CA" and the ORDER CONTROL field "NC" of the ORC of the order not to be canceled.

C. The purpose of this control code is to permit an order filler to replace one or more new orders with one or more new orders. A replacement involves the substitution of one or more orders for one or more previously existing orders. The replaced orders are treated as though they were canceled. When and whether replacement is permitted is a local site specific option. If it is desired that the original order remain in place, then the parent-child codes should be used, not the replacement codes. Replacement mechanism is most often used by the filler to make a substitution for a requested service.

Replacements are accomplished by transmitting a sequence of ORC segments and order segments. For each order to be replaced there is an ORC with the value "RP" or "RU" in its ORDER CONTROL field. The "RP" is a request for a replacement going to a filler, whereas the "RU" denotes an unsolicited replacement going from the filler to some other application to inform it of the fact of a replacement. Optionally, by local agreement, the RP or RU containing segment is followed by its order segment. The "RP" or "RU" containing sequence is immediately followed by at least one ORC with ORDER CONTROL field equal to "RO". Each of the "RO" segments may be followed by an order segment.

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

ORDER
Segment CONTROL Comment
ORC RU 1st replaced ORC.
OBR 1st replaced order.
ORC RU 2nd replaced ORC.
OBR 2nd replaced order.
ORC RO 1st replacement ORC.
OBR 1st replacement order.
ORC RO 2nd replacement ORC.
OBR 2nd replacement order.
ORC RO 3rd replacement ORC.
OBR 3rd replacement order.

Whether the OBR segments must be present is determined by the RESPONSE FLAG (see below).

The rules for the order numbers in the segments with "RO" ORDER CONTROL are determined by whether the replacement is an RP or an RU type. In the case of the RU type (i.e., unsolicited replacement by the filler), the FILLER ORDER # is generated as usual by the filler. The PLACER ORDER # is identical to the PLACER ORDER # of the first transmitted RU containing OBC.
In the case of the RP ORDER CONTROL (a replacement request from another system to the filler), the PLACER ORDER # is generated by the placer identically to the usual procedure for new orders. The FILLER ORDER # is generated by the filler using a procedure identical to that for new orders.

Notice that the above described method will handle all possible cases of replacement: one-into-one, many-into-one, one- into-many, and many-into-many.

If a replacement sequence is used in an ORU message (i.e., during results reporting), then the OBR segments following the "RO" OBC's can be followed by observation result segments.

D. The "RE" code are used to transmit patient specific information with an order. The order segment (e.g., OBR) can be followed by observation segments (OBX). Any observation that can be transmitted in an ORU message can be transmitted with this mechanism.

Here is an example sequence of segments submitting three pharmacy orders to illustrate the use of the "RE" code:
ORDER CONTROL Comment
MSH
PID
ORC NW First new order.
RX1 First order segment.
ORC NW 2nd new order.
RX1 2nd order segment.
ORC RE Patient specific observation.
OBR Observation OBR
OBX An observation segment.
OBX Another observation segment.
OBX Another observation segment.
OBX Another observation segment.
ORC NW 3rd order.
RX1 3rd order segment.

Results, when transmitted with an order, should immediately follow the order or orders that they are intended to support.

E. Although observations can be transmitted in ORU messages without ORC, there are times when it is necessary to transmit information not in the OBR segments. In this case, the ORC may be included in the ORU message.

Clearly, whenever a code is used in an ORU message, the OBR segments can be followed by observation results. Only in the ORM messages is the RE code required to indicate that the following OBR will be followed by observation results.

F. The "PA" and "CH" ORDER CONTROL codes allow one to spawn "child" orders from an original "parent" order without changing the parent. One or more "parent" ORC segments with ORDER CONTROL field equal to "PA" are followed by one or more ORC's with ORDER CONTROL field equal to "CH". Whether the OBR segments must be present is determined by the RESPONSE FLAG (see below).
For example, suppose that a microbiology culture produced two organisms and corresponding sensitivity reports. Then the sequence of segments would be as follows:

ORDER
Segment CONTROL Comment
ORC PA 1st parent ORC.
ORC CH 1st child ORC.
OBR 1st child order.
ORC CH 2nd child ORC.
OBR 2nd child order.

The FILLER ORDER #'s of all children orders are assigned by the filler according to its usual procedures and following the usual rules for uniqueness. The PLACER ORDER #'s of thechildren are identical to patient's PLACER ORDER #. The parent field of all child orders will contain the FILLER ORDER # of the parent. Thereby, the parent-child relationship is communicated whenever observations are reported.

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

G. The RR ORDER CONTROL code means that an order has been received and will be processed later. It has not undergone the processing that would permit a more exact response as yet.

I. Ordinarily, the filler is responsible for assigning the FILLER ORDER #. The FILLER ORDER # is the permanent unique identifier of an order. The SN code provides a mechanism for the filler to get the FILLER ORDER # from another system, such as a central HIS. This is done as follows.

For new orders (ORDER CONTROL = NW or ORDER CONTROL = RO following an RP), the placer can "suggest" a filler's number by placing that number in the first component of the FILLER ORDER # field and its own application identification in the second component. When this happens, the filler can use the first component as received as "its" FILLER ORDER #. In any situation in which the filler creates an order (e.g., de novo, parent/child mechanism, or replacement), the filler may request a number from the placer or another system (e.g., an HIS) using the SN ORDER CONTROL code in an ORC. At local option, any amount of data specific to the order, including order segments, may accompany this request for the convenience of the number assigning system. The number assigning system should then return an ORC with the SN ORDER CONTROL code and the FILLER ORDER # completed exactly as suggested for the NW case described above. Of prime importance is that the second component of the FILLER ORDER # should ultimately be the true filler's APPLICATION ID, not the APPLICATION ID of the number assigning system.

Notice that the above scheme allows for the possibility that the placer is a third party such as a bedside nursing system that sends its orders through an HIS that assigns the FILLER ORDER #.

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

When such results are reported the CN code replaces the RE code in all but the last ORC and the results follow last ORC and its OBR. Example:

MSH|...
PID|...
ORC|CN|...
OBR||A4461XA^HIS|81642^RAD|73666^Bilateral Feet|...
ORC|CN|...
OBR||A4461XA^HIS|81642^RAD|73642^Bilateral Hand PA|...
ORC|RE|...
OBR||RA4 461XB^HIS|81643^RAD|73916^Bilateral Knees|...
OBX||CE|73916&IMP||Radiologist's Impression|...
OBX||CE|73642&IMP||Radiologist's Impression|...
OBX||FT|73642&GDT||Description|...

In this example, a single report follows three ORC's.

2. 00715 PLACER ORDER #. This is a composite field. The first component is a string of up to 15 characters that identifies a individual order segment(e.g., OBR) it is assigned by the placer(ordering) system. It identifies an order uniquely among all orders from a particular ordering application. The second component contains the APPLICATION ID of the placing system. The APPLICATION ID is a string of up to six characters that will be uniquely associated with an application. A given institution or group of intercommunicating institutions should establish a list of applications that may be potential placers and fillers and assign their APPLICATION ID's. The list will be one of the institution's master dictionary lists that are documented elsewhere in the 2.1 specification. Since third parties other than the placer and filler of an order can send and receive ORM and ORR messages, the APPLICATION ID in this field may not be the same as the sending and receiving systems as identified in the MSH. The PLACER ORDER # field is the same as the field #2 of the OBR record. As with other identical fields, for upward and ASTM compatibility, the PLACER ORDER # must be present in the OBR if it is not present in the ORC. This is particularly important when results are being transmitted in an ORU message, in which case the ORC is not required and the identifying numbers must then be present in the OBR segments. The second component of the PLACER ORDER # always identifies the actual placer of an order. There are two situations in which the true placer is somewhat arbitrary: (1) in "RO" segments following an "RU" replacement ORC and (2) in child segments ("CH"). See the Table Notes under the Order Control field for the details of how PLACER ORDER #'s are assigned in these cases.
3. 00716 FILLER ORDER # This is a composite field. The first component is a string that identifies an individual order segment (e.g., OBR) it is assigned by the order filling (receiving) system. It identifies an order uniquely among all orders from a particular filling application(e.g., clinical laboratory). The second component is filler APPLICATION ID. Refer to PLACER ORDER # field note for definition of APPLICATION ID.It uniquely identifies the placing application within an institution or group of inter-communicating institutions. This component is up to 6 characters in length. The FILLER ORDER # field is the same as the field #3 of the OBR record. As with other identical fields, for upward and ASTM compatibility, the PLACER ORDER # must be present in the OBR if it is not present in the ORC. The FILLER ORDER #is also a unique identifier for an order and its associated observations. For example, suppose an institution collects observations from several ancillary systems into a common data base and this common data base is queried by yet another application for observations. In this case, the FILLER ORDER # and PLACER ORDER # transmitted by the common data base system would be that of the original filler and placer respectively, rather than a new one assigned by the common data base system. Similarly, if a "third party" system, not the filler or placer, of an order were authorized to modify the status of an order (say cancel it), then the third party system would send an ORM messagecontaining a ORC segment with ORDER CONTROL field equal to "CA" and the original PLACER ORDER # and FILLER ORDER #, rather than assigning either itself.

4. 00717 PLACER GROUP #. This is a two component field that allows an order placing system to group sets of orders together and subsequently identify them. The first component is a string of up to 15 characters that provides a unique identifier for all order groups from the given placing application. It is assigned by the placer and may come from the same series as the PLACER ORDER # of the ORC, but need not do so. The second component is an APPLICATION ID identical to the second component of the PLACER ORDER #. Order groups and how to use them are described in detail below under "Use Notes" and in the Examples.

5. 00718 ORDER STATUS. This field describes the status of an order. This field can only be defined in by the filler. Refer to table 0038 for valid entries.

6. 00719 RESPONSE FLAG. This field is defined by the sender of an ORM message. It determines the amount of information ultimately to be returned from the filler. If the field is null, it is treated the same as D. This field allows the placer system to determine the amount of response it wishes to receive in return. Sometimes the requested level of response may not be possible immediately, but when it is possible the filler is obliged to send the information. Refer to table 0121 for valid entries.

7. 00720 TIMING/QUANTITY. Order segments should be thought of as describing an atomic service. This composite field determines the priority, quantity, frequency, and timing of such a service. It is a composite field that is defined in detail in Chapter VII. For example, if an ORO segment describes a unit of blood, this field might request 3 such units be given on successive mornings. In this case the TIMING/QUANTITY field would be: "1^XQAM^X3". The TIMING field is the same as the field #27 of the OBR.

8. 00721 PARENT. This field relates a child back to its parent when a parent-child relationship exists. The parent-child mechanism is described under the ORDER CONTROL field notes. PARENT is a twocomponent field. The first component contains the PLACER ORDER # of the parent order. It is required when the order is a child. The second component the FILLER ORDER # of the parent. The components of the PLACER ORDER # and the FILLER ORDER # are transmitted in sub-components of the two components of this field. This field is the same as field #29 of the OBR.

9. 00722 DATE/TIME OF TRANSACTION. The date/time that the transaction was entered into the ordering system. For messages creating new orders, this meaning is clear: the date/time the order was entered. For other messages, this is the date/time the current transaction (e.g., cancellation) was entered into the system sending the transaction. This date/time is not a "replacement" time for a correction to the original order, rather, it is the date/time of the entry of the current transaction. Similarly, the ENTERED BY, VERIFIED BY, and ORDER'S LOCATION fields of this segment relate to the current transaction, not the original order.

10. 00723 ENTERED BY. The identity of the person who actually keyed the order into the system. Provides an audit trail in case the order is entered incorrectly and the ancillary department needs to clarify the request. The form is in(i.e., ID^NAME). By local agreement, either ID or NAME may not be present.

11. 00724 VERIFIED BY. The identity of the person who verified the accuracy of entered orders in case they were entered by a technician and needed to be verified by a higher authority, e.g., an RN. The form is CN(i.e., ID^NAME). By local agreement, either ID or NAME may not be present.

12. 00725 ORDERING PROVIDER. The identity of the person who was responsible for creating the order, often the ordering physician. This field is the same as field #16 of the OBR.

13. 00726 ENTERER'S LOCATION. Composite fields may be used on a site specific basis to include some subcategory of department where the order was entered. For example, ICU4 might be the designation for a forth floor ICU location.

14. 00727 CALL BACK PHONE NUMBER. The telephone number to call for clarification of an order or other information regarding the order. This field is the same as field #17 of the OBR.

Use notes

1. Default ORC.
The first ORC in an ORM or ORR message can be used to provide default values for all subsequent ORC's in that message. The concept is easier to understand and implement than to explain. The rule is simply this: if the first ORC of a message has null values in both the first component of FILLER ORDER # and the first component of PLACER ORDER #, then it is called a "Default ORC". Any other non-null field of a Default ORC is taken as the default for all other ORC segments that follow in the same message. If the Default ORC is in an ORR message, then the non-null values of the Default ORC are taken to apply to the orders of the previous ORM as well as any ORC's that follow in the current ORR message. So in a sense, the Default ORC of a ORR inherits the "scope" of the ORM to which it is a response.

When a field of the ORC is duplicated in the following order segment, the default values established by a Default ORC are valid for the duplicate fields of the order segment as well as the ORC.

2. Order Groups.

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

An order group is a list of orders (ORC's) associated with a GROUP #. A group is established when the placer supplies a GROUP # with the original order. The order group then consists of all the ORC's and order segments that have the same GROUP #. Subsequently, orders can be removed from the group using cancel, or added using the replacement or parent-child mechanism. However, new orders cannot otherwise be added to the group.

Notice that a convenient way to create an order group is to send a Default ORC with all the fields (including the GROUP # field) common to the order group transmitted in the Default ORC.

3. Duplicate fields.

The ORC is intended to define the fields that are common to all orders (i.e., requested services) and to make their meanings uniform. Some fields are duplicated between the ORC and some order segments. (For example, the PLACER ORDER # of the ORC is the same as the PLACER ORDER # of the OBR.) This is done for upward compatibility with past versions and ASTM. The rule for using these fields is that the value must appear in the order segment if it does not appear in the ORC. However, it is recommended that the fields be transmitted in both places to avoid confusion.

4. Whenever, a request to cancel, hold or discontinue is transmitted for a parent order, its meaning is applied recursively to all children as well as the parent. For example, suppose an EKG system has received an order for three EKG's on successive mornings, and suppose the EKG system had created three children orders, one for each requested EKG. Further, suppose that the first daily EKG has been done when a request was received to cancel the original parent. The parent is beyond the point of cancellation. However, the remaining, as yet not performed, children would be canceled as result of this request.

4.4.2 SEGMENT: BLG - BILLING/Abrechnung -

The BLG segment is to provide information to the filling system that may be needed for billing for the ordered service.

FIELD NOTES: BLG BILLING

1. 00066 WHEN TO CHARGE. This field determines the time when a charge is to take place. The first part of the composite value comes from table 0100. The second part is a TS (date/time) type that denotes an exact time when the first part is the code "T".

2. 00729 CHARGE TYPE. This field is used to direct billing to an entity other than the patient. Describes the nature of the entity. It is used in conjunction with the following field ACCOUNT ID to identify someone or something other than the patient to be billed for this service.

3. 00730 ACCOUNT ID. Identifies the account to be billed. See above in notes for CHARGE TYPE. The first component of this two component field contains an account number(really a sequence of characters). The second component field is used to identify the entity which holds the first component as an account number, often the paying entity.

4.4.3 SEGMENT: RX1 - PHARMACY ORDER /Arzneimittelanforderung

Notes:

- It is known that this segment is inadequate to the complete pharmacy task. It is not sufficient for many IV and inpatient orders. A fully functional pharmacy order segment, RX2, will be included in the 3.0 version of the Standard.

- Several fields that were previously in this segment are now covered by the ORC segment those fields have been removed from the current version.

The RX1 segment is used for pharmacy orders.

FIELD NOTES: RX1 PHARMACY ORDER

1. 00770 UNUSED. Formerly, FREQUENCY OF THE ORDER that has been replaced by the QUANTITY/TIMING field of the ORC.

2. 00771 UNUSED. Formerly, START DATE/TIME that has been replaced by the QUANTITY/TIMING field of the ORC.

3. 00129 ROUTE. Route indicates means of administrating the dose. Refer to table 0033 for valid entries.

4. 00130 SITE ADMINISTERED. Site refers to the location on the body where a dose is to be administered, e.g., IV, IM, Subcutaneous.

5. 00131 IV SOLUTION RATE. The rate will be expressed in a quantity per unit of measure. The unit of measure is provided as the second component of the field, e.g., 2.0^ML/HR.

6. 00133 DRUG STRENGTH. Strength per item ordered. The unit of measure is provided in the second component, e.g., 250^MG.

7. 00137 FINAL CONCENTRATION. Final concentration as a percent. When solutions are mixed, the order is often one, 100%mg IM 500ml. In this case, the final concentrate would be .2^mg/ml.

8. 00138 FINAL VOLUME IN ML.. If there are additives to a solution, the final volume may reflect additions to the solution's volume, or the final volume may indicate solution must be removed before the additives are added.

9. 00135 DRUG DOSE. Dose to be administered. Unit of measure is provided in the second component.

10. 00139 DRUG ROLE. The drug specified in the "ORD" segment is either: B = Base or A = Additive. E.g., orders for D5W plus 40 Mg of KCL would require 2 order records - one for D5W and another for the KCL additive. The first would contain the full instruction and details about the D5W. The second would contain information about the component KCL - and this field would contain an "A" for additive.

11. 00469 PRESCRIPTION SEQUENCE #. Prescription sequence number.

12. 00470 QUANTITY DISPENSED. The quantity of the units dispensed, e.g., 200^tabs-3.

13. 00772 UNUSED. Formerly, DURATION OF PRESCRIPTION that has been replaced by the QUANTITY/TIMING field of the ORC.

14. 00473 DRUG ID. Pharmacy-defined code for specifying drugs. The system of six part universal identifiers defined in the Chapter II, is used here to identify the medications.

15. 00474 COMPONENT DRUG IDS. Pharmacy-defined code for specifying drugs. Repeats up to 5 times.
(Verwendung wird nicht empfohlen. Sollte durch Wiederholung des RX1 Segmentes gelöst werden)

16. 00479 PRESCRIPTION TYPE

17. 00480 SUBSTITUTION STATUS. Y = generic substitution allowed. N = prescribed exactly as written within the contents of local formulary policy.

18. 00588 RX ORDER STATUS. An ID code for the current order status that is available in Order Confirmation, Query for Order Status, or Results (query and unsolicited update.)

19. 00481 NUMBER OF REFILLS. Number of refills initially prescribed for outpatient drug orders.

20. 00773 UNUSED.

21. 00482 REFILLS REMAINING.

22. 00619 DEA CLASS. Class (I, II, III, IV, or V) of the drug as defined by the Drug Enforcement Agency.

23. 00620 ORDERING MD'S DEA NUMBER. Unique number assigned by the Federal Drug Enforcement Agency for prescribing of controlled substance. Must be recorded on prescriptions re: drug ordered in Class II, III, or IV.

24. 00774 UNUSED.

25. 00483 LAST REFILL DATE/TIME. The date and time stamp for the most recent prescription refill.

26. 00596 RX NUMBER. Used for take-home prescriptions.

27. 00621 PRN STATUS. Indicator to identify drug that are prescribed as needed, rather than at a regular rate. Y = PRN; N = Regular Distribution.

28. 00484 PHARMACY INSTRUCTIONS. Repeats up to 5 times.

29. 00489 PATIENT INSTRUCTIONS. Repeats up to 5 times.

30. 00618 INSTRUCTIONS (SIG). Text of prescribing instructions as written by physician. The components of these instructions (e.g., frequency, amount) will also be carried by succeeding fields, but complex instruction will not be represented in the fields that follow.

4.4.4 SEGMENT: ORO - ORDER OTHER /Andere Anforderung

The ORO segment is the order record used for non-pharmacy, and non-observation producing services, e.g., dietary, etc. ORO may also be used for non patient ordering. A fully functional non-patient order segment will be available in release 3.0.

FIELD NOTES: ORO ORDER OTHER

1. 00731 ORDER ITEM ID. This field identifies the item or service being ordered. The structure of the field is the same as the UNIVERSAL SERVICE ID of the OBR, i.e., it is a coded entity. The structure is defined in the control section. Notice that the second component of the coded entry type can be used for a free text description, and when unaccompanied by a Standard code this will serve as a free text description for a non-Standard order.

2. 00120 SUBSTITUTE ALLOWED. Indicates whether the ancillary department may substitute an equivalent version of the item(s) ordered. NO TABLE CURRENTLY DEFINED.

3. 00586 RESULTS COPIES TO. A composite field that identifies the people that are to receive copies of the results. The format is id code^name. By local convention, either component may be not present. May be repeated.

4. 00068 STOCK LOCATION. This table entry describes whether an order is to be filled from ancillary or floor stock.

4.5 EXAMPLES OF USE

The purpose of this section is to show how certain specific situations would be handled using the order entry protocol. The ellipsis represent unfilled in details. The symbol "//" precedes comments for clarification.

An order replaced by three orders

Suppose that an application called "PC" is sending an order to the EKG system for three EKG's to be done on successive days.

The order might be placed as follows

ORM message:
MSH|...
PID|...
ORC|NW|^PC||946281^PC||||198801121132|
^ELLINORE OF AQUITAINE||4EAST<CR> // Default ORC
ORC||A226677||||N|3^QAM<CR> // EKG ORDER.
OBR||||93000^EKG REPORT||||||||||||P030^SMITH, MARTIN
|||||||||||3^QAM<CR>
BLG|...
ORC||... // Another order
... yet others
may follow

Notes:

- There is a GROUP # first component indicating that an order group is being created.

- The values for several fields of the ORC's are achieved by default from the Default ORC. In particular, that of the ORDER CONTROL field of the subsequent ORC's are absent and therefore defaults to "NW" (new order).

- The second component of the PLACER ORDER # is absent in the second ORC and therefore defaults to the value in the Default ORC ("PC").

Responses: Because the EKG system must turn the single order above into three orders for three separate EKG's (services) the results of each of which will be reported under its own OBR segment.

Several response levels are possible depending on the RESPONSE FLAG:

1. If the RESPONSE FLAG is N (as it is), then the filler EKG application only responds "I got the order."

MSH|...
MSA|...

Notes:

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

ORR message:

MSH|...
MSA|...
ORC|OK|^PC<CR> // Default ORC.
ORC|PA|A226677|89-458^EKG<CR>
ORC|CH|A226677|89-551^EKG... // 1ST child ORC.
ORC|CH|A226677|89-552^EKG... // 2ND child ORC.
ORC|CH|A226677|89-553^EKG... // 3RD child ORC.
... // Other parts of
response might follow.
Notes:
- What has been said here is: "Your A226767 has spun out three children named 89-551, 89-552, and 89-553. Notice that the FILLER and PLACER #'s are identical in the children's ORCs.
- The second component of the PLACER ORDER # field of the ORC's must be given explicitly since it was not provided in the Default ORC (like: ORC|OK|^PC|^EKG<CR>), which would have been more efficient eliminating 12 characters. This emphasizes the fact that the Default ORC is merely a notational convenience.
3. 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:

ORR message:
MSH|...
MSA|...
ORH|OK|^PC|^EKG<CR>
ORC|PA|A226677|89-458<CR>
ORC|CH|A226677|89-551|946282^PC|SC|A226677&PC^89-458&EKG|
^^^^198901130500^<CR> // 1ST child ORC.
OBR|||89-551^EKG|93000^EKG REPORT|... // 1ST child OBR.
ORC|CH|A226677|89-522|946282^PC|SC|A226677&PC^89-458&EKG|
^^^^198901140500^<CR> // 2ND child ORC.
OBR|||89-551^EKG|93000^EKG REPORT|...
// 2ND child OBR.
ORC|CH|A226677|89-553|946282^PC|SC|A226677&PC^89-458&EKG|
^^^^198901150500^<CR> // 3RD child ORC.
OBR|||89-551^EKG|93000^EKG REPORT|... // 3RD child OBR.
// Other parts of response might follow.

Notes:

- Here the actual OBR segments have been added.

- The status of the child orders is being reported as SC (scheduled).

- The QUANTITY/TIMING fields show that the EKG's are requested after 0500 on successive days.

- Notice that the FILLER ORDER # is reported in both the ORC and OBR. This is optional.

Results reporting

1. The EKG application needs to communicate to anyone the results of 1st EKG:

ORU message:
MSH|...
PID|...
OBR|||89-551^EKG|93000^EKG REPORT|...
// 1ST child OBR.
OBX||ST|93000.1^VENTRICULAR RATE (EKG)|...
OBX||ST|93000.2^...
...
...
OBX||FT|93000.14^EKG COMMENT|...
OBR|... // other observation segments to follow
Notes:

- Notice that this report is without reference to the original order.

- No ORC is required because the identifying FILLER'S ORDER # (and other ORC fields) are carried in the OBR segment.

2. The EKG application needs to communicate to anyone the original order information, the details of the child orders, the fact of the child spin off, and the results of all three EKG's:

ORU message:
MSH|...
PID|...
ORC|OK|^PC|^EKG<CR>
ORC|PA|A226677|89-458|...
// original order's ORC.
OBR||||93000^EKG REPORT|...
// original order segment
ORC|CH|A226677|89-451<CR>
// 1st child ORC.
OBR||||93000^EKG REPORT|...
// 1st EKG child OBR.
OBX||ST... // 1st EKG report
OBX||ST...
...
OBX||FT...
ORC|CH|A226677|89-452<CR>
// 2nd child ORC.
OBR||||93000^EKG REPORT|...
// 2nd EKG child OBR.
OBX||ST... // 2nd EKG report
OBX||ST...
...
OBX||FT...
ORC|CH|A226677|89-453<CR>
// 3rd child ORC.
OBR||||93000^EKG REPORT|...
// 3rd EKG child OBR.
OBX||ST... // 3rd EKG report
OBX||ST...
...
OBX||FT...
... // Other parts of message might follow.
Notes:

- In this case, we are transmitting the information about the fact of child spin off, the original order and the results all at the same time. Thus, this form of the ORU message reports not only the results of an order, but all of its associated ordering information including the original OBR for three EKG's that was replaced by three separate OBR EKG segments.
Patient-specific clinical data with an order

Reporting body weight and height with a creatinine clearance.

MSH|...
PID|...
ORC|NW|... // New order.
OBR||P42^PC||98142.1^Creatinine Clearance|...
ORC|RE|... // Result observations.
OBR|||PC432899^PC|3000.00^Physical Exam|...
OBX||ST1010.1^Body Weight|62|kg<CR>
OBX||ST1010.3^Height|190|cm<CR>
ORC|NW|... // Next order.
...