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

Draft Website - For Review Purposes Only

SCH - Schedule Activity Information Segment

The SCH segment contains general information about the scheduled appointment.

HL7 Attribute Table - SCH - Schedule Activity Information Segment
Seq# DataElement Description Must Implement Flags Cardinality Length C.LEN Vocabulary DataType
SCH
1

00860 Placer Appointment ID MAY
True:
False:
C
[1..1]
[0..1]
EI
2

00861 Filler Appointment ID MAY
True:
False:
C
[1..1]
[0..1]
EI
3

00862 Occurrence Number MAY
True:
False:
C=
[1..1]
[0..1]
5 NM
4 00218 Placer Order Group Number [0..1] EI
5 00864 Schedule ID [0..1] CWE
6 00883 Event Reason SHALL [1..1] CWE
7 00866 Appointment Reason [0..1] CWE
8 00867 Appointment Type [0..1] CWE
9 00868 Appointment Duration SHALL NOT W= [0..0] 5 NM
10 00869 Appointment Duration Units B [0..1] CNE
11 00884 Appointment Timing Quantity SHALL NOT W [0..0]
12 00874 Placer Contact Person [0..*] XCN
13 00875 Placer Contact Phone Number [0..1] XTN
14 00876 Placer Contact Address [0..*] XAD
15 00877 Placer Contact Location [0..1] PL
16 00885 Filler Contact Person SHALL [1..*] XCN
17 00886 Filler Contact Phone Number [0..1] XTN
18 00887 Filler Contact Address [0..*] XAD
19 00888 Filler Contact Location [0..1] PL
20 00878 Entered By Person SHALL [1..*] XCN
21 00879 Entered By Phone Number [0..*] XTN
22 00880 Entered By Location [0..1] PL
23 00881 Parent Placer Appointment ID [0..1] EI
24

00882 Parent Filler Appointment ID MAY
True:
False:
C
[1..1]
[0..1]
EI
25 00889 Filler Status Code [0..1] CWE
26

00216 Placer Order Number MAY
True:
False:
C
[1..1]
[0..1]
EI
27

00217 Filler Order Number MAY
True:
False:
C
[1..1]
[0..1]
EI
28 03547 Alternate Placer Order Group Number [0..1] EIP

SCH-1: Placer Appointment ID (EI) 00860

(Definition from ARQ.1 in Ch. 10)

Definition: This field contains placer application's permanent identifier for the appointment request (and the scheduled appointment itself, when confirmed as booked by the filler application). This is a composite field. The first component is a string that identifies an individual appointment request, or booked appointment. It is assigned by the placer application, and it identifies an appointment request, and the subsequent scheduled appointment, uniquely among all such requests and/or booked appointments from a particular requesting application. If the placer appointment ID identifies a parent of a repeating schedule request, then the individual scheduled child appointments can be uniquely identified either by a new placer appointment ID or the parent's placer appointment ID plus an occurrence number, specified in ARQ-3-Occurrence number.

The second through fourth components contain the assigning authority identifying information.

(Definition from SCH.1 in Ch. 10)

Definition: This field contains the placer application's permanent identifier for the appointment request (and the scheduled appointment itself, when it has been confirmed as a booked slot by the filler application). This is a composite field.

The first component is a string that identifies an individual appointment request, or a booked appointment. It is assigned by the placer application, and identifies an appointment request, and the subsequent scheduled appointment, uniquely among all such requests and/or booked appointments from a particular requesting application. If SCH-1-Placer Appointment ID identifies a parent of a repeating schedule request, then the individual child scheduled appointments can be uniquely identified either by a new SCH-1-Placer Appointment ID or by SCH-23-Parent Placer Appointment ID plus an SCH-3-Occurrence Number.

If a schedule request originates from a placer it MUST have a placer appointment ID. If the filler sends responses, it may use the placer appointment ID and/or assign a filler appointment ID (which it would echo back to the placer to enable the placer application to associate the two). If the placer appointment ID is not present, the filler appointment ID must be present and vice versa.

SCH-2: Filler Appointment ID (EI) 00861

(Definition from ARQ.2 in Ch. 10)

Definition: This field contains the filler application's permanent identifier for the appointment request (and the scheduled appointment itself, when confirmed as a booked slot by the filler application). This is a composite field. The first component is a string that identifies an individual appointment request, or booked appointment. It is assigned by the filler application, and it identifies an appointment request and the subsequent scheduled appointment, uniquely among all such requests and/or booked appointments from a particular processing application. If the filler appointment ID identifies a parent of a repeating schedule request, then the individual scheduled child appointments can be uniquely identified either by a new filler appointment ID or the parent's filler appointment ID plus an occurrence number, specified in ARQ-3-Occurrence number.

The second through fourth components contain the assigning authority identifying information. This is a conditionally required field. On initial request messages and other messages where a filler has not yet assigned a filler appointment ID, this field should not contain a value. In all other subsequent messages, where a filler application has assigned a filler appointment ID and communicated it to other applications, this field is required.

(Definition from SCH.2 in Ch. 10)

Definition: This field contains the filler application's permanent identifier for the appointment request (and the scheduled appointment itself, when it has been confirmed as a booked slot by the filler application). This is a composite field.

The first component is a string of up to fifteen characters that identifies an individual appointment request, or a booked appointment. It is assigned by the filler application, and identifies an appointment request, and the subsequent scheduled appointment, uniquely among all such requests and/or booked appointments from a particular processing application. If SCH-2-Filler Appointment ID identifies a parent of a repeating schedule request, then the individual child scheduled appointments can be uniquely identified either by a new SCH-2-Filler Appointment ID or by SCH-25-Parent Filler Appointment ID plus an SCH-3-Occurrence Number.

SCH-3: Occurrence Number (NM) 00862

(Definition from ARQ.3 in Ch. 10)

Definition: This field is used in conjunction with the placer appointment ID and/or the filler appointment ID to uniquely identify an individual occurrence (a child) of a parent repeating schedule appointment.

This field is conditionally required. If the transaction using this segment is meant to apply only to one occurrence of a repeating appointment, and an occurrence number is required to uniquely identify the child appointment (that is, the child does not have a separate and unique placer appointment ID or filler appointment ID), then this field is required.

(Definition from SCH.3 in Ch. 10)

Definition: This field is used in conjunction with SCH-1-Placer Appointment ID and/or SCH-2-Filler Appointment ID to uniquely identify an individual occurrence (a child) of a parent repeating schedule appointment.

This field is conditionally required. If the transaction using this segment is intended to apply only to one occurrence of a repeating appointment, and an occurrence number is required to uniquely identify the child appointment (that is, the child does not have a separate and unique SCH-1-Placer Appointment ID or SCH-2-Filler Appointment ID), then this field is required.

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

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

SCH-5: Schedule ID (CWE) 00864

(Definition from ARQ.5 in Ch. 10)

Definition: This field contains an identifier code for the schedule in which this appointment should be (or is) booked. This field is provided for situations in which filler applications maintain multiple schedules, and in which a particular resource or set of resources is controlled by more than one of those schedules.

If a new appointment must be booked, it may be necessary to provide a schedule ID to uniquely identify the intended slot(s) being requested in the transaction. After the request has been assigned to one or more slots; however, the filler application should assign a unique filler appointment ID (see sections 10.6.1.1, "ARQ-1 Placer Appointment ID (EI) 00860," and 10.6.1.2, "ARQ-2 Filler Appointment ID (EI) 00861)." This filler appointment ID, as its definition indicates, should uniquely identify the appointment among all such requests and appointments within the filler application. This means that, once assigned, the filler appointment ID should uniquely identify the appointment (either as a request or as a booked appointment) without a need to provide the schedule ID too. As a cautionary note regarding implementation, if the filler appointment ID would not otherwise be unique, it may be necessary to include the schedule ID as part of the filler appointment ID. This can be done either by prefixing the appointment ID with the schedule ID, or by appending the schedule ID to the appointment ID.

(Definition from SCH.5 in Ch. 10)

Definition: This field contains an identifier code for the schedule in which this appointment is (or will be) booked. This field is provided for instances in which filler applications maintain multiple schedules, and when a particular resource or set of resources is controlled by more than one of those schedules.

This field is provided on the SCH segment for informational purposes to applications fulfilling the placer, querying and auxiliary roles.

SCH-6: Event Reason (CWE) 00883

Definition: This field contains an identifier code for the reason that the notification event was triggered. This field may contain a code describing the cancel reason, the delete reason, the discontinue reason, the add reason, the block reason or any other code describing the reason that a specific event will occur.

This field should not have been made required but is retained as such for reasons of backwards compatibility.

SCH-7: Appointment Reason (CWE) 00866

(Definition from ARQ.7 in Ch. 10)

Definition: This field contains the identifier code for the reason that the appointment is to take place. This field may contain a Universal Service ID describing the observation/test/battery/procedure or other activity that is to be performed during the requested appointment, similar to the Universal Service ID defined for the OBR segment in Chapter 4 on Order Entry. It may also contain a site-specific code describing a pre-defined set of reasons that an appointment may be set to occur. This code can be based on local and/or universal codes. The use of universal codes is recommended. Refer to User-defined Table 0276 - Appointment reason codes in Chapter 2C, Code Tables, for suggested values. This table provides codes for appointment reasons such as routine appointment, previously unscheduled walk-in visit, etc.

(Definition from SCH.7 in Ch. 10)

Definition: This field contains an identifier code for the reason that the appointment is to take place. This field may contain a Universal Service ID describing the observation/test/battery/procedure or other activity that is to take place during the requested appointment, similar to the Universal Service ID defined for the OBR segment in the Order Entry chapter (Chapter 4). It may also contain a site-specific code describing a pre-defined set of reasons that an appointment may be set to occur. This code can be based on local and/or universal codes. The use of universal codes is recommended. Refer to User-Defined Table 0276 - Appointment Reason Codes in Chapter 2C, Code Tables, for suggested values.

SCH-8: Appointment Type (CWE) 00867

(Definition from ARQ.8 in Ch. 10)

Definition: This field contains an identifier code for the type of appointment being requested. Refer to User-Defined Table 0277 - Appointment Type Codes in Chapter 2C, Code Tables, for suggested values. This table provides codes for appointment types such as routine schedule request, request for a tentative appointment, etc.

(Definition from SCH.8 in Ch. 10)

Definition: This field contains the identifier code for the type of appointment. Refer to User-Defined Table 0277 - Appointment Type Codes in Chapter 2C, Code Tables, for suggested values.

SCH-9: Appointment Duration

(Definition from ARQ.9 in Ch. 10)

Definition: This field contains the amount of time being requested for the appointment. In cases of requests for repeating appointments, this field describes the duration of one instance of the appointment. If this field is unvalued, then the institution's standard duration for the type of appointment requested will be assumed.

The appointment duration field must contain a positive, non-zero number. A negative number or zero (0) is nonsensical in the context of a duration.

(Definition from SCH.9 in Ch. 10)

As of version 2.5, this field was retained for backward compatibility only and withdrawn and removed as of v2.7. Refer to the TQ1 segment described in Chapter 4.

SCH-10: Appointment Duration Units (CNE) 00869

(Definition from ARQ.10 in Ch. 10)

Definition: This field contains a code describing the units of time used in expressing the ARQ-9-Appointment duration field. This field should be valued according to the recommendations in Chapters 2 and 7. If this component is not valued, the ISO base unit of seconds (code "s") will be assumed. Refer to Chapter 7, Figures 7-6 through 7-9, for a list of ISO and ANSI+ unit codes.

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.

        Unit of Measure Coding Systems from HL7 Table 0396

Coding System

Description

Comment

ISO+

ISO 2955.83 (units of measure) with HL7 extensions

See chapter 7.

ANS+

HL7 set of units of measure

HL7 set of units of measure based upon ANSI X3.50 - 1986, ISO 2988-83, and US customary units / see chapter 7.


(Definition from SCH.10 in Ch. 10)

As of version 2.5, this field is retained for backward compatibility only. Refer to the TQ1 segment described in Chapter 4.

Definition: This field contains a code describing the units of time used for expressing the ARQ-9-Appointment Duration field. This field should be valued according to the recommendations in Chapters 2 and 7. If this component is not valued, the ISO base unit of seconds (code "s") is assumed. Refer to Chapter 7, Figures 7-6 through 7-9, for a list of ISO and ANSI+ unit codes.

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.

Unit of Measure Coding Systems from HL7 Table 0396

Coding System

Description

Comment

ISO+

ISO 2955.83 (units of measure) with HL7 extensions

See chapter 7.

ANS+

HL7 set of units of measure

HL7 set of units of measure based upon ANSI X3.50 - 1986, ISO 2988-83, and US customary units / see chapter 7.


SCH-11: Appointment Timing Quantity

As of version 2.5, this field was retained for backward compatibility only and withdrawn and removed as of v2.7. Refer to the TQ1 segment described in Chapter 4.

SCH-12: Placer Contact Person (XCN) 00874

(Definition from ARQ.15 in Ch. 10)

Definition: This field identifies the person responsible for requesting the scheduling of a requested appointment. This person could be the same person responsible for executing the actual appointment, or it could be the provider requesting that an appointment be made on behalf of the patient, with another provider.

(Definition from SCH.12 in Ch. 10)

Definition: This field identifies the person responsible for requesting the scheduling of a requested appointment. Most often, this person will be the same person responsible for executing the appointment.

SCH-13: Placer Contact Phone Number (XTN) 00875

(Definition from ARQ.16 in Ch. 10)

Definition: This field contains the phone number used to contact the placer contact person.

(Definition from SCH.13 in Ch. 10)

Definition: This field contains the phone number used to contact the SCH-12-Placer Contact Person.

SCH-14: Placer Contact Address (XAD) 00876

(Definition from ARQ.17 in Ch. 10)

Definition: This field contains the address used to contact the placer contact person.

(Definition from SCH.14 in Ch. 10)

Definition: This field contains the address used to contact the SCH-12-Placer Contact Person.

SCH-15: Placer Contact Location (PL) 00877

(Definition from ARQ.18 in Ch. 10)

Definition: This field contains a code that identifies the location of the placer contact person.

(Definition from SCH.15 in Ch. 10)

Definition: This field contains a code that identifies the location of the SCH-12-Placer Contact Person.

SCH-16: Filler Contact Person (XCN) 00885

Definition: This field identifies the person responsible for the scheduling of the requested appointment. Most often, this person will be the same person responsible for maintaining the schedule and for reviewing appointment requests.

This field should not have been made required but is retained as such for reasons of backward compatibility.

SCH-17: Filler Contact Phone Number (XTN) 00886

Definition: This field contains the phone number used to contact the SCH-16-Filler Contact Person.

SCH-18: Filler Contact Address (XAD) 00887

Definition: This field contains the address used to contact the SCH-16-Filler Contact Person.

SCH-19: Filler Contact Location (PL) 00888

Definition: This field contains a code that identifies the location of the SCH-16-Filler Contact Person.

SCH-20: Entered By Person (XCN) 00878

(Definition from ARQ.19 in Ch. 10)

Definition: This field identifies the person responsible for entering the request for the scheduling of an appointment. It is included to provide an audit trail of persons responsible for the request. This person may be someone other than the placer contact person, who is responsible for entering orders and requests.

(Definition from SCH.20 in Ch. 10)

Definition: This field identifies the person responsible for entering the request for the scheduling of an appointment. It is included to provide an audit trail of persons responsible for the request. This person may be someone other than the placer contact person, who is responsible for entering orders and requests.

This field should not have been made required but is retained as such for reasons of backwards compatibility.

SCH-21: Entered By Phone Number (XTN) 00879

(Definition from ARQ.20 in Ch. 10)

Definition: This field contains the phone number used to contact the ARQ-19-Entered by Person.

(Definition from SCH.21 in Ch. 10)

Definition: This field contains the phone number used to contact the ARQ-19-Entered by Person.

SCH-22: Entered By Location (PL) 00880

(Definition from ARQ.21 in Ch. 10)

Definition: This field contains a code that identifies the location of the entered by person.

(Definition from SCH.22 in Ch. 10)

Definition: This field contains a code that identifies the location of the entered by person.

SCH-23: Parent Placer Appointment ID (EI) 00881

(Definition from ARQ.22 in Ch. 10)

Definition: This field relates a child to its parent, when a parent-child relationship exists. It contains the placer application's permanent identifier for the parent of the appointment request. This is a composite field.

The first component is a string that identifies the parent appointment request. It is assigned by the placer application, and identifies an appointment request uniquely among all such requests from a particular requesting application.

(Definition from SCH.23 in Ch. 10)

Definition: This field relates a child to its parent, when a parent-child relationship exists. It contains the placer application's permanent identifier for the parent of the appointment request. This is a composite field.

The first component is a string that identifies the parent appointment request. It is assigned by the placer application, and identifies an appointment request uniquely among all such requests from a particular requesting application.

SCH-24: Parent Filler Appointment ID (EI) 00882

(Definition from ARQ.23 in Ch. 10)

Definition: This field relates a child to its parent, when a parent-child relationship exists. It contains the filler application's permanent identifier for the parent of the appointment request. This is a composite field.

The first component is a string that identifies the parent appointment request. It is assigned by the filler application, and identifies an appointment request uniquely among all such requests on a particular processing application.

(Definition from SCH.24 in Ch. 10)

Definition: This field relates a child to its parent, when a parent-child relationship exists. It contains the filler application's permanent identifier for the parent of the appointment request. This is a composite field.

The first component is a string that identifies the parent appointment request. It is assigned by the filler application, and it identifies an appointment request uniquely among all such requests on a particular processing application.

This is a conditionally required field. On initial messages where a filler has not yet assigned a filler appointment ID, this field should not contain a value. In all other subsequent messages, where a filler application has assigned a filler appointment ID, this field is required.

SCH-25: Filler Status Code (CWE) 00889

(Definition from SCH.25 in Ch. 10)

Definition: This field contains a code describing the status of the appointment with respect to the filler application. Refer to User-Defined Table 0278 - Filler Status Codes in Chapter 2C, Code Tables, for suggested values.

(Definition from AIS.10 in Ch. 10)

Definition: This field contains a code that describes the requested/scheduled status of the resource or activity, from the point of view of the filler application. Refer to User-Defined Table 0278 - Filler Status Codes in Chapter 2C, Code Tables, for suggested codes.

This is a conditionally required field. Because the information contained in this field is only appropriate in transactions originating from a filler application, it is required for those messages. This includes all unsolicited transactions originating from a filler application, as well as all response messages originating from a filler application. This field is optional for all transactions originating from placer, querying and auxiliary applications. It is recommended that this field be left unvalued in transactions originating from applications other than the filler application.

(Definition from AIG.14 in Ch. 10)

Definition: This field contains a code that describes the requested/scheduled status of scheduling resource or activity, from the point of view of the filler application. Refer to User-Defined Table 0278 - Filler Status Codes for suggested codes.

This is a conditionally required field. Because the information contained in this field is only appropriate in transactions originating from a filler application, it is required for those messages. This includes all unsolicited transactions originating from a filler application, as well as all response messages originating from a filler application. This field is optional for all transactions originating from placer, querying and auxiliary applications. It is recommended that this field be left unvalued in transactions originating from applications other than the filler application.

(Definition from AIL.12 in Ch. 10)

Definition: This field contains a code that describes the requested/scheduled status of the location, from the point of view of the filler application. Refer to User-Defined Table 0278 - Filler Status Codes in Chapter 2C, Code Tables, for suggested values.

This is a conditionally required field. Because the information contained in this field is only appropriate in transactions originating from a filler application, it is required for those messages. This includes all unsolicited transactions originating from a filler application, as well as all response messages originating from a filler application. This field is optional for all transactions originating from placer, querying and auxiliary applications. It is recommended that this field be left unvalued in transactions originating from applications other than the filler application.

(Definition from AIP.12 in Ch. 10)

Definition: This field contains a code that describes the requested/scheduled status of the personnel resource, from the point of view of the filler application. Refer to User-Defined Table 0278 - Filler Status Codes in Chapter 2C, Code Tables, for suggested codes.

This field is conditionally required. It should not be valued in any request transactions from the placer application to the filler application. It is required for all transactions from the filler application. It is optional for query transactions.

This is a conditionally required field. Because the information contained in this field is only appropriate in transactions originating from a filler application, it is required for those messages. This includes all unsolicited transactions originating from a filler application, as well as all response messages originating from a filler application. This field is optional for all transactions originating from placer, querying and auxiliary applications. It is recommended that this field be left unvalued in transactions originating from applications other than the filler application.

SCH-26: Placer Order Number (EI) 00216

(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):

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

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

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

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

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

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.

SCH-27: Filler Order Number (EI) 00217

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

SCH-28: Alternate Placer Order Group Number (EIP) 03547

(Definition from ARQ.26 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 from SCH.28 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.