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

Draft Website - For Review Purposes Only

Scheduling

Chapter Chair:

Alexander de Leon
Kaiser Permanente

Editor:

Alexander de Leon
Kaiser Permanente

Sponsoring TC:

Patient Administration

List Server:

sched@lists.hl7.org


PURPOSE

This chapter defines abstract messages for the purpose of communicating various events related to the scheduling of appointments for services or for the use of resources. There are three basic types of messages defined in this transaction set: request transactions and their responses, query transactions and their responses, and unsolicited transactions and their responses. Request transactions communicate requests for the scheduling of appointments for services or for the use of resources. These transactions occur between placer (requesting) applications and filler (processing) applications. The query and unsolicited transaction sets provide for the exchange of scheduling information between systems. The exchange of this information is achieved either actively or passively. The active gathering of scheduling information is performed by issuing query transactions to a filler application from a querying application. The passive gathering of this information is performed by accepting unsolicited transactions issued by a filler application.

This chapter describes various roles under which applications might operate. The roles discussed in this chapter illustrate the underlying model used to develop this specification. They do not imply the need for a particular application model or method of implementation.

This chapter defines the transactions at the seventh level, that is, the abstract message. Various schemes are used to generate the actual characters that comprise the messages according to the communication 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.

Schedules, Appointments, Services, and Resources

The goal of this specification is to facilitate the communication of scheduling requests and information between applications. Such communication involves three main subjects: schedules, appointments, and services and resources. Schedules control the occurrence of certain services and the use of particular resources. They consist of a set of open, booked and blocked slots for one particular service or resource. Open slots are periods of time on a schedule during which a service may occur, and/or a resource is available for use. Booked slots are periods of time on a schedule that have already been reserved. Appointments occupy sets of one or more booked slots on a schedule. They describe the nature of the service and/or the use of the resource, the person or persons responsible for the appointment's booking, and other information relevant to the booking and execution of an appointment. Blocked slots on a schedule are periods of time during which a service or resource is unavailable for reasons other than booked appointments (for example, a piece of equipment might be unavailable for maintenance reasons).

In the context of this chapter, services and resources are those things that are controlled by schedules. Services are real-world events, such as clinic appointments, the performance of which is controlled by a schedule. Often, these kinds of activities relate to the care of a patient. In other words, appointments for services often schedule a service for one or more patients. Resources are tangible items whose use is controlled by a schedule. These "items" are often people, locations, or things low in supply but high in demand.

Schedules

A schedule controls the dates and times available for the performance of a service and/or the use of a resource. One schedule applies to one service or resource, since each service or resource can be reserved independently of the others. (If two or more services, people, locations, or things cannot be reserved independently of one another, they are considered to be one activity or resource.) A schedule consists of slots of time during which the controlled service or resource is potentially available for performance or use. Slots are categorized as open, booked, or blocked. An open slot on a schedule indicates that the service or resource is available for performance or use during that period of time. A booked slot indicates that the service or resource is not available during the time period, because an appointment has been scheduled. A blocked slot indicates that a service or resource is unavailable for reasons other than a scheduled appointment.

The real-world, non-automated analog of the schedule described above is a standard appointment book. These books are generally organized with rows of time slots, during which a service or resource is available. The following figure illustrates an excerpt from such an appointment book.

Figure 10-1. An example excerpt from an appointment book

Date:

May 17, 1994

Room A

Room B

Room C

Room D

8:00 am

Pat: A Everyman

:15   

Dr.: Specialize

Closed for

:30   

Physical

Pat: A Everyman

Remodeling

:45   

Exam

Dr.: Stretcher

9:00 am

Pat: E Everywoman

Allergy

Pat: A Everyman

:15   

Dr.: Specialize

Scratch Test

Dr.: Stretcher

:30   

Follow-up


Each cell in the figure above represents a slot on a schedule. Different shading patterns represent booked and blocked slots. Information identifying the appointments scheduled in booked slots is written in the appointment book. Similarly, explanations are written into the book when resources are blocked. Those cells with no shading and comments represent open slots.

As in the figure above, appointment books commonly contain more than one column. This format allows the scheduling of more than one resource or activity within the same book. This chapter defines a schedule as an entity controlling the availability of only one resource or service for a given period of time. Given that definition, each column in the above excerpt from the appointment book represents a separate schedule for a separate resource.

Services and Resources

Services and resources are the "what" in any communication of scheduling transactions, that is, they are things—either tangible or intangible—that the transaction is attempting to affect or describe. The services and resources that are controlled by schedules are typically in high demand. In any case, their use or performance is managed through the process of reserving blocks of time.

Services are typically activities that occur in a certain location, where specific people and equipment exist to carry out the activity. The activity must be scheduled prior to its occurrence. The schedule that controls the activity may not be the same schedule that controls the location, people, and equipment. For example, patient visits to a clinic are typically controlled through scheduling. Patients receive an appointment at the clinic, and at the appointed time are seen by a member of the clinic staff. From the point of view of the person or application requesting the appointment for the patient, the "thing" being scheduled is a service (e.g., a doctor's consult, an X-ray, etc.). The assignment of an exam room and (in this example) a physician, nurse practitioner, or other staff member is incidental to the actual appointment.

Resources are tangible things that must be reserved prior to their use. Examples might include MRI equipment, portable X-ray machines, or rooms. People are also tangible resources that are often scheduled. Typically these people controlled by schedules have special roles, perform special activities, and are in high demand.

The following are the primary attributes that describe a resource:

  • A unique identification code

    The unique identification code for a service or resource describes a specific instance of that service or resource. For tangible resources, this may be a serial number, a location, an employee number, or another unique designation. For services, the identification of a slot on the schedule is usually sufficient for unique identification.

  • A code describing the type of class of service or resource

    This code describes a type or class of service, or resource groups like services or resources together. For services, this is typically a universal service ID similar to the field used in the OBR segment defined in the Order Entry chapter (Chapter 4). This Universal Service ID uniquely identifies clinical services performed in a healthcare provider organization.

    For tangible resources, this code may be a model number, a staff classification (such as physician, nurse, physical therapist, etc.), or a kind of room. This kind of information can be used to request a resource from a pool, where a specific instance of the resource scheduled is unknown and unimportant (as long as it is of the specified type or class).

  • A name or text description of the resource

    The name or text description of the resource provides a human-readable identification of the service or resource.

  • When a resource is associated with an appointment, or is requested for an appointment, the following attributes describe the relationship (or requested relationship):

  • The start date and time the service or resource is required for the appointment.

    The start date and time the service or resource is required for the appointment describes the point at which the service or resource should be made available to the activity. In this specification, this is represented as a positive or negative time offset from the start date and time of the appointment.

  • The duration for which the service or resource is needed for the appointment.

    The duration for which the service or resource is required for the appointment describes how long the service or resource is needed to complete the appointment. By adding the duration to the start date and time, the end date and time can be calculated for the required resource or service within the activity.

  • Other attributes further describe services and resources. These attributes are communicated, as necessary, in transactions between applications.

Appointments

Appointments are instances of the performance of a service or the use of a resource. They describe the "why," the "who" and the "when" in any communication of scheduling transactions. These appointments occupy one or more slots on a service or resource schedule, causing those slots to become unavailable or "booked." Appointments can describe scheduled activities related to patients in a healthcare setting, or they can describe scheduled activities wholly unrelated to patients.

In its simplest form, an appointment consists of one service or resource reserved for a period of time, for a specific reason. More complex activities involve multiple services or resources, or parent-child relationships to other appointments.

The primary attributes for the appointment which describes a scheduled activity include the following:

  • A unique placer appointment identification code

    The placer appointment identification code uniquely describes an instance of an appointment. It is used in communications between placer and filler applications to identify a particular appointment (or a request for an appointment booking) on the placer application. Except in special circumstances, the code is assigned by the placer application upon making an initial scheduling request. This concept is similar in practice to the placer order number found in Chapter 4, Order Entry.

  • A unique filler appointment identification code

    The filler appointment identification code uniquely describes an instance of an appointment. It is the filler application's counter-part to the placer appointment identification code. It is used in communications between placer and filler applications to identify a particular appointment (or request for an appointment booking) on the filler application. Except under special circumstances, it is assigned by the filler application when an appointment (or a request for an appointment booking) is created by the filler application. This concept is similar in practice to the filler order number found in Chapter 4, Order Entry.

  • An appointment start date and time

    The appointment start date and time describe the beginning of the appointment. In request transactions, the appointment start date and time are expressed as a preference or list of preferences. The filler application uses this expression of preference to book the appointment. Once an appointment has been booked, the start date and time are expressed in the actual scheduled start date and time.

  • An appointment duration

    The appointment duration describes how long the appointment will last, and consequently, the end date and time of the appointment.

Supporting information about service and resource activities includes the following:

  • Reason codes to describe the reason that the service is occurring or the resource is being used;

  • Patient information to describe for whom the appointment is taking place, whether the appointment or scheduled activity is for, or related to, a patient;

  • Requestor information to describe the person responsible for initiating and executing the appointment;

  • Location information to describe where the appointment is scheduled to occur.

Other attributes further describe appointments. These attributes are communicated as necessary in transactions between applications.

Parent and Child Appointments

Parent appointments are those appointments that embody one or more child appointments. For example, a request for a repeating appointment results in a logical parent (the original scheduled appointment request), and one or more children (each individual occurrence of the appointment). This specification provides no information about how individual applications store or handle parent and child appointments, but it does provide a mechanism for identifying individual occurrences (children) within transactions.

Either the placing application or the filling application can specify child appointments—and in one of two ways. If each individual child appointment is assigned a separate and unique Placer Appointment ID and/or Filler Appointment ID, then that unique identifier may be used in transactions to specify an individual child. If, however, neither the placer nor filler application assigns a unique identifier separately, an occurrence number can be used. Both the ARQ and SCH segments allow for an occurrence number, which is a unique serial number assigned to each child within a parent appointment.

Application Roles

In this specification, there are four roles that an application can assume: a filler application role, a placer application role, a querying application role, and an auxiliary application role. These application roles define the interaction that an application will have with other applications in the messaging environment. In many environments, any one application may take on more than one application role.

In this specification, the definition of application roles is not intended to define or limit the functionality of specific products developed by vendors of such applications. Instead, this information is provided to help define the model used to develop this specification, and to provide an unambiguous way for applications to communicate with each other.

The Filler Application Role

The filler application role in the scheduling model is very similar to the filler application concept presented in Chapter 4, Order Entry. A filler application, in the scheduling model, is one that "owns" one or more schedules for one or more services or resources. In other words, a filler application exerts control over a certain set of services or resources and the schedules that define the availability of those services or resources. Because of this control, no other application has the ability to reserve, or to otherwise modify, the schedules controlled by a particular filler application.

Other applications can, on the other hand, make requests to modify the schedules owned by the filler application. The filler application either fulfills or denies requests to book slots, or to otherwise modify the schedules for the services and resources over which it exerts control.

Finally, the filler application also provides information about scheduled activities to other applications. The reasons that an application may be interested in receiving such information are varied. An application may have previously requested bookings or modifications on the schedule, or may simply be interested in the information for its own reporting or statistical purposes. There are two methods whereby filler applications disseminate this information: by issuing unsolicited information messages, or by responding to queries.

The analog of a filler application in a non-automated environment might be an appointment book and the person in charge of maintaining that book. The appointment book describes when the resources are available and when they are booked. This appointment book is the only official record of this information, and controls the availability of the resources to any user. The person in charge of this appointment book takes requests to book the resources, and decides whether to accept or reject the requests based on the information recorded in the appointment book. Anyone needing information from the appointment book either consults the book directly, or contacts the person in charge of the book.

The Placer Application Role

The placer application role in the scheduling model is also very similar to its counterpart in the Order Entry chapter. A placer application requests the booking, modification, cancellation, etc., of a scheduled activity for a service or resource. Because it cannot exert any control over the schedule for that resource, it must send its requests to modify the schedule to the filler application. In requesting that these appointments be booked or modified in some way, the placer application is asking the filler application to exert its control over the schedule on the placer application's behalf.

The analog of a placer application in a non-automated environment might be any person needing a particular resource or appointment for a service. A person needing to book an appointment would contact the person in charge of the appointment book for that resource or service, and request a reservation. Often, there is negotiation between the person requesting the reservation or appointment and the person who maintains the appointment book. The requesting person will indicate requirements and preferences, and the person controlling the appointment book will indicate whether the request can be fulfilled as specified.

The Querying Application Role

A querying application neither exerts control over, nor requests changes to a schedule. Rather than accepting unsolicited information about schedules, as does an auxiliary application, the querying application actively solicits this information using a query mechanism. It will, in general, be driven by a person wanting information about schedules, and may be part of an application filling the placer application role as defined in this chapter. The information that the querying application receives is valid only at the exact time that the query results are generated by the filler application. Changes made to the schedule after the query results have been returned are not communicated to the querying application until it issues another query transaction.

The analog of a querying application in a non-automated environment might be any person needing information about a specific portion of a schedule. For example, a facilities manager may need to know whether a specific room has been scheduled during a specific period of time. This person might ask the person controlling the appointment book about the specific room and period of time in question.

Often, a placer application will also act as a querying application. The ability to send queries and receive lists of open slots is built in to some implementations of placer applications. These placer applications use this information to select open slots for subsequent booking requests. The current specification does not imply that placer applications should or should not also be able to fulfill the role of a querying application. Instead, the model defines these roles separately. Applications that support this functionality may take advantage of this application role in the model. Applications that do not support the querying application role are not limited in their support of the placer application role.

The Auxiliary Application Role

Like querying applications, an auxiliary application neither exerts control over, nor requests changes to a schedule. It, too, is only concerned with gathering information about a particular schedule. It is considered an "interested third-party," in that it is interested in any changes to a particular schedule, but has no interest in changing it or controlling it in any way. An auxiliary application passively collects information by receiving unsolicited updates from a filler application.

The analog of an auxiliary application in a non-automated environment might be any person receiving reports containing schedule information. For example, a facilities manager may need to know what rooms are booked for activity during specific periods of time. This person might ask the person controlling the appointment book for a periodic listing of activity, which may be something as simple as copies of pages from the appointment book.

Often, a placer application will also act as an auxiliary application. A placer application may have the capacity to store information about the scheduled activity that it requested. In such cases, the placer application is also an "interested" application in that it wishes to receive any messages describing changes to the content or status of the scheduled activity it initiated.

Application Roles in a Messaging Environment

In a messaging environment, these four application roles communicate using specific types of messages and trigger events. The following figure illustrates the relationships between these application roles in a messaging environment:

The relationship between placer and filler applications revolves around request messages and response messages to those requests. Placer applications trigger request messages to filler applications, which respond to those requests with request response messages.

The relationship between querying and filler applications focuses on query messages and responses. Querying applications trigger query messages to filler applications, which respond with query response messages.

The relationship between auxiliary and filler applications centers on unsolicited informational messages. Filler applications trigger unsolicited informational messages to auxiliary applications whenever changes in the schedule occur. Auxiliary applications do not respond with any messages other than general acknowledgments. Filler applications triggering unsolicited informational messages do not expect further information from auxiliary applications.

Trigger Events, Status, Reasons, and Types

This chapter defines several trigger events used to communicate scheduling information between applications. In addition, it also defines, suggests, or allows for several statuses that scheduled activities may hold, several reasons a scheduled activity may occur, and several types of scheduled activities. The distinction between these four concepts is important for understanding the information in this chapter.

Trigger Events

The trigger events for this chapter are defined in Section 10.3, "PLACER APPLICATION REQUESTS AND TRIGGER EVENTS,” 10.4, "FILLER APPLICATION MESSAGES AND TRIGGER EVENTS UNSOLICITED," and 10.5, "QUERY TRANSACTIONS AND TRIGGER EVENTS." Traditionally, trigger events define the transition of some entity from one state to another.1 Typical trigger events may be listed as follows: new, cancel, modify, discontinue, reschedule, and delete.

[1]     HL7 trigger events are not strictly limited to this definition; however, most trigger events do define state transitions.

Status

The status of a scheduled activity describes where that activity is in its life cycle. A status differs from a trigger event in an important way: a status describes the current condition of an entity, whereas a trigger event is generated to "move" the entity from one state to another. All status fields in this chapter are defined with respect to the application acting in the role of a filler, unless otherwise (and specifically) indicated. Therefore, a status in a scheduling interface transaction is only truly meaningful if the transaction was generated by the application assigning or maintaining that status.

Typical statuses for a schedule transaction might include the following: pending, wait-listed, confirmed, canceled, discontinued, deleted, started, completed, overbooked (booked for a resource along with another conflicting appointment), blocked, etc.

Reasons

This chapter defines two kinds of reasons used with transactions. The first is an appointment reason that indicates why the appointment is being booked – and ultimately why the activity is going to occur. The second is an event reason that describes why a particular trigger event has been generated. Reasons tend to be static, whereas statuses tend to change. In contrast, trigger events describe an action to be performed.

Appointment reasons tend to be relatively static for the life of the scheduled activity. Typical examples of appointment reasons include the following: routine, walk-in, check-up, follow-up, emergency, etc.

Event reasons are static as well, but only for the life of a particular trigger event. Typical examples of event reasons include the following: no-show (e.g., when an appointment is canceled), at patient request, at caregiver request, etc.

Types

Rather than describing why an appointment has been scheduled – as the appointment reason does – the appointment type describes the kind of appointment recorded in the schedule. This information tends to be administrative in nature. Typical appointment types might include: normal, tentative (or "penciled in"), STAT, etc.

Appointments, Orders, and Referrals

A schedule request or appointment should not be confused, in any way, with orders for services, or for patient referrals. The trigger events and messages defined in this chapter are meant to operate within the realm of scheduling activities, and not to imply that any other trigger event or real-world event has or should occur. It should not be construed from this chapter that any schedule request transaction can be used instead of an order transaction, in which a service or other activity must be specifically ordered. In such cases, a specific order transaction should occur (either electronically or otherwise). If subsequent scheduling transactions are then required to carry out the order, the trigger events and messages defined in this chapter may be used.

Glossary

Appointment

An appointment represents a booked slot or group of slots on a schedule, relating to one or more services or resources. Two examples might include a patient visit scheduled at a clinic, and a reservation for a piece of equipment.

Auxiliary Application

An auxiliary application neither exerts control over, nor requests changes to a schedule. It is only concerned with gathering information about a particular schedule. It can be considered an "interested third-party," in that it is interested in any changes to a particular schedule, but has no interest in changing it or controlling it in any way. It may gather information passively or actively. An auxiliary application passively collects information by receiving unsolicited updates from a filler application.

Block

An indication that a slot or a set of slots is unavailable for reasons other than booking an appointment.

Book

The act of reserving a slot or set of slots on a schedule for a service or resource.

Child Appointment

A child appointment is an appointment subordinate to another appointment (called a parent appointment). For example, a single instance of an appointment in a group of recurring appointments is a child to the group. Child appointments can themselves be parent appointments. For example, if a battery of appointments is scheduled, then the atomic units of the battery are children to the battery request. If the battery is scheduled as a repeating appointment, then each instance of the battery of appointments (parent to each of the atomic units) is a child to the original repeating request.

Filler Application

The filler application role in the scheduling model is very similar to the filler application concept presented in Chapter 4, Order Entry. A filler application, in the scheduling model, is one that "owns" one or more schedules for one or more services or resources. It fulfills requests to book slots for the services or resources over which it exerts control. It also notifies other applications of activity related to appointments, such as new bookings, modifications, cancellations, etc.

Parent Appointment

A parent appointment is an appointment that consists of one or more subordinate appointments (called child appointments). A parent appointment is used to relate or group multiple appointments together in various ways. Examples of kinds of parent-scheduled activities include, but are not limited to, the following.

  • Recurring (repeating) appointments. For example, a physical therapy appointment may be scheduled every Tuesday at 4:00 PM for three months.

  • Batteries of appointments. For example, an activity consisting of an appointment with Radiology, an appointment with a specialist, and an appointment with a primary care physician might be scheduled.

  • Complex appointments. For example, recurring batteries of appointments, or batteries of battery appointments.

Parent appointments can themselves be children to other appointments.

Placer Application

The role of the placer application in the scheduling model is also very similar to its counterpart in the Order Entry chapter. A placer application must request the booking, modification, cancellation, etc., of an appointment for a service or resource because it cannot exert any control over that service or resource on the schedule. In requesting that these appointments be booked or modified in some way, the placer application is asking the filler application to exert its control over the schedule on the placer application's behalf.

Querying Application

A querying application neither exerts control over nor requests changes to a schedule. Rather than accepting unsolicited information about schedules, as does an auxiliary application, the querying application actively solicits this information using a query mechanism. It will be driven by a person wanting information about schedules, and may be part of an application filling the placer application role as defined in this chapter. The information that the querying application receives is valid only at the exact time that the query results are generated by the filler application. Changes made to the schedule after the query results have been returned are not communicated to the querying application until it issues another query transaction.

Resource

A resource is any person, place or thing that must be reserved prior to its use.

Schedule

A schedule is the sum of all of the slots related to a service or resource.

Service

A service is any activity that must be scheduled prior to its performance.

Slot

A slot is one unit on a schedule. A slot represents the smallest unit of time or quantity that a service or resource may be booked. Depending on the nature of the service or resource, there may be more than one defined slot at a given instant of time. For example, if a service is an open group therapy session with twelve available seats, then there are twelve slots for the given block of time.

Organization of This Chapter: Trigger Events and Message Definitions

This specification contains three functional groupings of trigger events and message definitions. The trigger events within each of the three functional groupings share the same or similar message definitions. For clarity, message definitions shared by multiple trigger events are presented only once.

The first functional grouping of trigger events and message definitions describes placer request transactions. This grouping defines the trigger events and message definitions for transactions from applications acting in a placer application role, and also defines the related filler application response messages. These messages are described in Section 10.3, "PLACER APPLICATION REQUESTS AND TRIGGER EVENTS."

The second functional grouping describes trigger events and message definitions for unsolicited transactions from applications acting in the filler application role. This grouping describes the unsolicited messages originating from an application fulfilling the filler role, and the response messages sent back by applications fulfilling the auxiliary role. These messages are described in Section 10.4, "FILLER APPLICATION MESSAGES AND TRIGGER EVENTS UNSOLICITED."

The final grouping describes query transactions from applications acting in the querying application role, and also defines the related filler application messages used to respond to these queries. These messages are described in section 10.5, "QUERY TRANSACTIONS AND TRIGGER EVENTS."

The notation used to describe the sequence, optionality, and repetition of segments is described in Chapter 2, "Format for defining abstract messages."

Update mode

This chapter uses the "Action code/unique identifier" mode for updating via repeating segments. For more information on updating via repeating segments, please see section 2.10.4, "Protocol for interpreting repeating segments or segment groups in an update Message," in Chapter 2. The definition of the "Action code/unique identifier" update mode can be found in Chapter 2, Section 2.10.4.2, "Action code/unique identifier mode update definition."

PLACER APPLICATION REQUESTS AND TRIGGER EVENTS

Placer request and filler response transactions are the messages and trigger events used between placer applications and filler applications. The placer application initiates transactions using the SRM message, requesting that the filler application modify its schedule(s) with the given trigger event and information. The filler application responds to these requests, using the SRR message, to either grant or deny the requests from the placer application.

When initiating a request, the placer application will generate and send an SRM message containing all of the information necessary to communicate the desired action to the filler application. All required segments and fields (both explicitly required and conditionally required) should be provided to the filler application, as defined in this chapter. When the filler application receives the transaction, it acknowledges it with the appropriate accept acknowledgment using an ACK message (assuming that the enhanced acknowledgment mode is in use). After processing the request at the application level, the filler acknowledges the transaction with the appropriate application acknowledgment in an SRR message (again assuming that an application acknowledgment was requested under the enhanced acknowledgment mode, or that the original acknowledgment mode is in use). Applying the explanations of the various application acknowledgment codes in the context of this chapter, an application accept from the filler means that the request was processed and accepted by the filler. An application error from the filler means that the request was processed and denied. An application reject from the filler means that the request was not, and could not, be processed due to one or more reasons unrelated to its content (for example: it fails the basic application protocol validation, the filler system is down, or there was an internal error). When appropriate, an SRR message with an application accept acknowledgment will contain further information on the request that was processed.

There are no unsolicited messages initiated from a filler application defined in this set of trigger events. Those messages and trigger events are defined below, in Section 10.4, "FILLER APPLICATION MESSAGES AND TRIGGER EVENTS UNSOLICITED."

All of the trigger events associated with placer request and filler response transactions use a common message definition that follows:

SRM^S01^SRM_S01: Schedule Request Message
HL7 MessageStructure Table - SRM_S01
Segment Cardinality Must Implement Status
SRM_S01
MSH 1..1 Yes
ARQ 1..1 Yes
APR 0..1
NTE 0..*
PATIENT 0..*
PID 1..1 Yes
PRT 0..*
PV1 0..1
PV2 0..1
PRT 0..*
DG1 0..*
0..*
OBX 1..1 Yes
PRT 0..*
RESOURCES 1..* Yes
RGS 1..1 Yes
SERVICE 0..*
AIS 1..1 Yes
APR 0..1
NTE 0..*
GENERAL_RESOURCE 0..*
AIG 1..1 Yes
APR 0..1
NTE 0..*
LOCATION_RESOURCE 0..*
AIL 1..1 Yes
APR 0..1
NTE 0..*
PERSONNEL_RESOURCE 0..*
AIP 1..1 Yes
APR 0..1
NTE 0..*

Original Mode Acknowledgement Choreography for SRM^S01^SRM_S01

Send Application Ack: SRR^S01^SRR_S01

Enhanced Mode Acknowledgement Choreography for SRM^S01^SRM_S01

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

When the MSH-15 value of a SRM^S01^SRM_S01 message is NE, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a SRM^S01^SRM_S01 message is AL or ER or SU, a SRR^S01^SRR_S01 message SHALL be sent as an application ack.

When the MSH-16 value of a SRM^S01^SRM_S01 message is NE, an application ack SHALL NOT be sent.

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

SRM^S02^SRM_S01: Schedule Request Message
HL7 MessageStructure Table - SRM_S01
Segment Cardinality Must Implement Status
SRM_S01
MSH 1..1 Yes
ARQ 1..1 Yes
APR 0..1
NTE 0..*
PATIENT 0..*
PID 1..1 Yes
PRT 0..*
PV1 0..1
PV2 0..1
PRT 0..*
DG1 0..*
0..*
OBX 1..1 Yes
PRT 0..*
RESOURCES 1..* Yes
RGS 1..1 Yes
SERVICE 0..*
AIS 1..1 Yes
APR 0..1
NTE 0..*
GENERAL_RESOURCE 0..*
AIG 1..1 Yes
APR 0..1
NTE 0..*
LOCATION_RESOURCE 0..*
AIL 1..1 Yes
APR 0..1
NTE 0..*
PERSONNEL_RESOURCE 0..*
AIP 1..1 Yes
APR 0..1
NTE 0..*

Original Mode Acknowledgement Choreography for SRM^S02^SRM_S01

Send Application Ack: SRR^S02^SRR_S01

Enhanced Mode Acknowledgement Choreography for SRM^S02^SRM_S01

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

When the MSH-15 value of a SRM^S02^SRM_S01 message is NE, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a SRM^S02^SRM_S01 message is AL or ER or SU, a SRR^S02^SRR_S01 message SHALL be sent as an application ack.

When the MSH-16 value of a SRM^S02^SRM_S01 message is NE, an application ack SHALL NOT be sent.

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

SRM^S03^SRM_S01: Schedule Request Message
HL7 MessageStructure Table - SRM_S01
Segment Cardinality Must Implement Status
SRM_S01
MSH 1..1 Yes
ARQ 1..1 Yes
APR 0..1
NTE 0..*
PATIENT 0..*
PID 1..1 Yes
PRT 0..*
PV1 0..1
PV2 0..1
PRT 0..*
DG1 0..*
0..*
OBX 1..1 Yes
PRT 0..*
RESOURCES 1..* Yes
RGS 1..1 Yes
SERVICE 0..*
AIS 1..1 Yes
APR 0..1
NTE 0..*
GENERAL_RESOURCE 0..*
AIG 1..1 Yes
APR 0..1
NTE 0..*
LOCATION_RESOURCE 0..*
AIL 1..1 Yes
APR 0..1
NTE 0..*
PERSONNEL_RESOURCE 0..*
AIP 1..1 Yes
APR 0..1
NTE 0..*

Original Mode Acknowledgement Choreography for SRM^S03^SRM_S01

Send Application Ack: SRR^S03^SRR_S01

Enhanced Mode Acknowledgement Choreography for SRM^S03^SRM_S01

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

When the MSH-15 value of a SRM^S03^SRM_S01 message is NE, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a SRM^S03^SRM_S01 message is AL or ER or SU, a SRR^S03^SRR_S01 message SHALL be sent as an application ack.

When the MSH-16 value of a SRM^S03^SRM_S01 message is NE, an application ack SHALL NOT be sent.

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

SRM^S04^SRM_S01: Schedule Request Message
HL7 MessageStructure Table - SRM_S01
Segment Cardinality Must Implement Status
SRM_S01
MSH 1..1 Yes
ARQ 1..1 Yes
APR 0..1
NTE 0..*
PATIENT 0..*
PID 1..1 Yes
PRT 0..*
PV1 0..1
PV2 0..1
PRT 0..*
DG1 0..*
0..*
OBX 1..1 Yes
PRT 0..*
RESOURCES 1..* Yes
RGS 1..1 Yes
SERVICE 0..*
AIS 1..1 Yes
APR 0..1
NTE 0..*
GENERAL_RESOURCE 0..*
AIG 1..1 Yes
APR 0..1
NTE 0..*
LOCATION_RESOURCE 0..*
AIL 1..1 Yes
APR 0..1
NTE 0..*
PERSONNEL_RESOURCE 0..*
AIP 1..1 Yes
APR 0..1
NTE 0..*

Original Mode Acknowledgement Choreography for SRM^S04^SRM_S01

Send Application Ack: SRR^S04^SRR_S01

Enhanced Mode Acknowledgement Choreography for SRM^S04^SRM_S01

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

When the MSH-15 value of a SRM^S04^SRM_S01 message is NE, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a SRM^S04^SRM_S01 message is AL or ER or SU, a SRR^S04^SRR_S01 message SHALL be sent as an application ack.

When the MSH-16 value of a SRM^S04^SRM_S01 message is NE, an application ack SHALL NOT be sent.

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

SRM^S05^SRM_S01: Schedule Request Message
HL7 MessageStructure Table - SRM_S01
Segment Cardinality Must Implement Status
SRM_S01
MSH 1..1 Yes
ARQ 1..1 Yes
APR 0..1
NTE 0..*
PATIENT 0..*
PID 1..1 Yes
PRT 0..*
PV1 0..1
PV2 0..1
PRT 0..*
DG1 0..*
0..*
OBX 1..1 Yes
PRT 0..*
RESOURCES 1..* Yes
RGS 1..1 Yes
SERVICE 0..*
AIS 1..1 Yes
APR 0..1
NTE 0..*
GENERAL_RESOURCE 0..*
AIG 1..1 Yes
APR 0..1
NTE 0..*
LOCATION_RESOURCE 0..*
AIL 1..1 Yes
APR 0..1
NTE 0..*
PERSONNEL_RESOURCE 0..*
AIP 1..1 Yes
APR 0..1
NTE 0..*

Original Mode Acknowledgement Choreography for SRM^S05^SRM_S01

Send Application Ack: SRR^S05^SRR_S01

Enhanced Mode Acknowledgement Choreography for SRM^S05^SRM_S01

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

When the MSH-15 value of a SRM^S05^SRM_S01 message is NE, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a SRM^S05^SRM_S01 message is AL or ER or SU, a SRR^S05^SRR_S01 message SHALL be sent as an application ack.

When the MSH-16 value of a SRM^S05^SRM_S01 message is NE, an application ack SHALL NOT be sent.

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

SRM^S06^SRM_S01: Schedule Request Message
HL7 MessageStructure Table - SRM_S01
Segment Cardinality Must Implement Status
SRM_S01
MSH 1..1 Yes
ARQ 1..1 Yes
APR 0..1
NTE 0..*
PATIENT 0..*
PID 1..1 Yes
PRT 0..*
PV1 0..1
PV2 0..1
PRT 0..*
DG1 0..*
0..*
OBX 1..1 Yes
PRT 0..*
RESOURCES 1..* Yes
RGS 1..1 Yes
SERVICE 0..*
AIS 1..1 Yes
APR 0..1
NTE 0..*
GENERAL_RESOURCE 0..*
AIG 1..1 Yes
APR 0..1
NTE 0..*
LOCATION_RESOURCE 0..*
AIL 1..1 Yes
APR 0..1
NTE 0..*
PERSONNEL_RESOURCE 0..*
AIP 1..1 Yes
APR 0..1
NTE 0..*

Original Mode Acknowledgement Choreography for SRM^S06^SRM_S01

Send Application Ack: SRR^S06^SRR_S01

Enhanced Mode Acknowledgement Choreography for SRM^S06^SRM_S01

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

When the MSH-15 value of a SRM^S06^SRM_S01 message is NE, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a SRM^S06^SRM_S01 message is AL or ER or SU, a SRR^S06^SRR_S01 message SHALL be sent as an application ack.

When the MSH-16 value of a SRM^S06^SRM_S01 message is NE, an application ack SHALL NOT be sent.

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

SRM^S07^SRM_S01: Schedule Request Message
HL7 MessageStructure Table - SRM_S01
Segment Cardinality Must Implement Status
SRM_S01
MSH 1..1 Yes
ARQ 1..1 Yes
APR 0..1
NTE 0..*
PATIENT 0..*
PID 1..1 Yes
PRT 0..*
PV1 0..1
PV2 0..1
PRT 0..*
DG1 0..*
0..*
OBX 1..1 Yes
PRT 0..*
RESOURCES 1..* Yes
RGS 1..1 Yes
SERVICE 0..*
AIS 1..1 Yes
APR 0..1
NTE 0..*
GENERAL_RESOURCE 0..*
AIG 1..1 Yes
APR 0..1
NTE 0..*
LOCATION_RESOURCE 0..*
AIL 1..1 Yes
APR 0..1
NTE 0..*
PERSONNEL_RESOURCE 0..*
AIP 1..1 Yes
APR 0..1
NTE 0..*

Original Mode Acknowledgement Choreography for SRM^S07^SRM_S01

Send Application Ack: SRR^S07^SRR_S01

Enhanced Mode Acknowledgement Choreography for SRM^S07^SRM_S01

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

When the MSH-15 value of a SRM^S07^SRM_S01 message is NE, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a SRM^S07^SRM_S01 message is AL or ER or SU, a SRR^S07^SRR_S01 message SHALL be sent as an application ack.

When the MSH-16 value of a SRM^S07^SRM_S01 message is NE, an application ack SHALL NOT be sent.

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

SRM^S08^SRM_S01: Schedule Request Message
HL7 MessageStructure Table - SRM_S01
Segment Cardinality Must Implement Status
SRM_S01
MSH 1..1 Yes
ARQ 1..1 Yes
APR 0..1
NTE 0..*
PATIENT 0..*
PID 1..1 Yes
PRT 0..*
PV1 0..1
PV2 0..1
PRT 0..*
DG1 0..*
0..*
OBX 1..1 Yes
PRT 0..*
RESOURCES 1..* Yes
RGS 1..1 Yes
SERVICE 0..*
AIS 1..1 Yes
APR 0..1
NTE 0..*
GENERAL_RESOURCE 0..*
AIG 1..1 Yes
APR 0..1
NTE 0..*
LOCATION_RESOURCE 0..*
AIL 1..1 Yes
APR 0..1
NTE 0..*
PERSONNEL_RESOURCE 0..*
AIP 1..1 Yes
APR 0..1
NTE 0..*

Original Mode Acknowledgement Choreography for SRM^S08^SRM_S01

Send Application Ack: SRR^S08^SRR_S01

Enhanced Mode Acknowledgement Choreography for SRM^S08^SRM_S01

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

When the MSH-15 value of a SRM^S08^SRM_S01 message is NE, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a SRM^S08^SRM_S01 message is AL or ER or SU, a SRR^S08^SRR_S01 message SHALL be sent as an application ack.

When the MSH-16 value of a SRM^S08^SRM_S01 message is NE, an application ack SHALL NOT be sent.

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

SRM^S09^SRM_S01: Schedule Request Message
HL7 MessageStructure Table - SRM_S01
Segment Cardinality Must Implement Status
SRM_S01
MSH 1..1 Yes
ARQ 1..1 Yes
APR 0..1
NTE 0..*
PATIENT 0..*
PID 1..1 Yes
PRT 0..*
PV1 0..1
PV2 0..1
PRT 0..*
DG1 0..*
0..*
OBX 1..1 Yes
PRT 0..*
RESOURCES 1..* Yes
RGS 1..1 Yes
SERVICE 0..*
AIS 1..1 Yes
APR 0..1
NTE 0..*
GENERAL_RESOURCE 0..*
AIG 1..1 Yes
APR 0..1
NTE 0..*
LOCATION_RESOURCE 0..*
AIL 1..1 Yes
APR 0..1
NTE 0..*
PERSONNEL_RESOURCE 0..*
AIP 1..1 Yes
APR 0..1
NTE 0..*

Original Mode Acknowledgement Choreography for SRM^S09^SRM_S01

Send Application Ack: SRR^S09^SRR_S01

Enhanced Mode Acknowledgement Choreography for SRM^S09^SRM_S01

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

When the MSH-15 value of a SRM^S09^SRM_S01 message is NE, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a SRM^S09^SRM_S01 message is AL or ER or SU, a SRR^S09^SRR_S01 message SHALL be sent as an application ack.

When the MSH-16 value of a SRM^S09^SRM_S01 message is NE, an application ack SHALL NOT be sent.

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

SRM^S10^SRM_S01: Schedule Request Message
HL7 MessageStructure Table - SRM_S01
Segment Cardinality Must Implement Status
SRM_S01
MSH 1..1 Yes
ARQ 1..1 Yes
APR 0..1
NTE 0..*
PATIENT 0..*
PID 1..1 Yes
PRT 0..*
PV1 0..1
PV2 0..1
PRT 0..*
DG1 0..*
0..*
OBX 1..1 Yes
PRT 0..*
RESOURCES 1..* Yes
RGS 1..1 Yes
SERVICE 0..*
AIS 1..1 Yes
APR 0..1
NTE 0..*
GENERAL_RESOURCE 0..*
AIG 1..1 Yes
APR 0..1
NTE 0..*
LOCATION_RESOURCE 0..*
AIL 1..1 Yes
APR 0..1
NTE 0..*
PERSONNEL_RESOURCE 0..*
AIP 1..1 Yes
APR 0..1
NTE 0..*

Original Mode Acknowledgement Choreography for SRM^S10^SRM_S01

Send Application Ack: SRR^S10^SRR_S01

Enhanced Mode Acknowledgement Choreography for SRM^S10^SRM_S01

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

When the MSH-15 value of a SRM^S10^SRM_S01 message is NE, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a SRM^S10^SRM_S01 message is AL or ER or SU, a SRR^S10^SRR_S01 message SHALL be sent as an application ack.

When the MSH-16 value of a SRM^S10^SRM_S01 message is NE, an application ack SHALL NOT be sent.

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

SRM^S11^SRM_S01: Schedule Request Message
HL7 MessageStructure Table - SRM_S01
Segment Cardinality Must Implement Status
SRM_S01
MSH 1..1 Yes
ARQ 1..1 Yes
APR 0..1
NTE 0..*
PATIENT 0..*
PID 1..1 Yes
PRT 0..*
PV1 0..1
PV2 0..1
PRT 0..*
DG1 0..*
0..*
OBX 1..1 Yes
PRT 0..*
RESOURCES 1..* Yes
RGS 1..1 Yes
SERVICE 0..*
AIS 1..1 Yes
APR 0..1
NTE 0..*
GENERAL_RESOURCE 0..*
AIG 1..1 Yes
APR 0..1
NTE 0..*
LOCATION_RESOURCE 0..*
AIL 1..1 Yes
APR 0..1
NTE 0..*
PERSONNEL_RESOURCE 0..*
AIP 1..1 Yes
APR 0..1
NTE 0..*

Original Mode Acknowledgement Choreography for SRM^S11^SRM_S01

Send Application Ack: SRR^S11^SRR_S01

Enhanced Mode Acknowledgement Choreography for SRM^S11^SRM_S01

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

When the MSH-15 value of a SRM^S11^SRM_S01 message is NE, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a SRM^S11^SRM_S01 message is AL or ER or SU, a SRR^S11^SRR_S01 message SHALL be sent as an application ack.

When the MSH-16 value of a SRM^S11^SRM_S01 message is NE, an application ack SHALL NOT be sent.

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

SRR^S01^SRR_S01: Scheduled Request Response
HL7 MessageStructure Table - SRR_S01
Segment Cardinality Must Implement Status
SRR_S01
MSH 1..1 Yes
MSA 1..1 Yes
ERR 0..*
SCHEDULE 0..1
SCH 1..1 Yes
TQ1 0..*
NTE 0..*
PATIENT 0..*
PID 1..1 Yes
PRT 0..*
PV1 0..1
PV2 0..1
PRT 0..*
DG1 0..*
RESOURCES 1..* Yes
RGS 1..1 Yes
SERVICE 0..*
AIS 1..1 Yes
NTE 0..*
GENERAL_RESOURCE 0..*
AIG 1..1 Yes
NTE 0..*
LOCATION_RESOURCE 0..*
AIL 1..1 Yes
NTE 0..*
PERSONNEL_RESOURCE 0..*
AIP 1..1 Yes
NTE 0..*

Original Mode Acknowledgement Choreography for SRR^S01^SRR_S01

Send An Acknowlegment is never sent in original mode.

Enhanced Mode Acknowledgement Choreography for SRR^S01^SRR_S01

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

When the MSH-15 value of a SRR^S01^SRR_S01 message is NE, an immediate ack SHALL NOT be sent.

Never send an application ack in enhanced mode.

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

SRR^S02^SRR_S01: Scheduled Request Response
HL7 MessageStructure Table - SRR_S01
Segment Cardinality Must Implement Status
SRR_S01
MSH 1..1 Yes
MSA 1..1 Yes
ERR 0..*
SCHEDULE 0..1
SCH 1..1 Yes
TQ1 0..*
NTE 0..*
PATIENT 0..*
PID 1..1 Yes
PRT 0..*
PV1 0..1
PV2 0..1
PRT 0..*
DG1 0..*
RESOURCES 1..* Yes
RGS 1..1 Yes
SERVICE 0..*
AIS 1..1 Yes
NTE 0..*
GENERAL_RESOURCE 0..*
AIG 1..1 Yes
NTE 0..*
LOCATION_RESOURCE 0..*
AIL 1..1 Yes
NTE 0..*
PERSONNEL_RESOURCE 0..*
AIP 1..1 Yes
NTE 0..*

Original Mode Acknowledgement Choreography for SRR^S02^SRR_S01

Send An Acknowlegment is never sent in original mode.

Enhanced Mode Acknowledgement Choreography for SRR^S02^SRR_S01

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

When the MSH-15 value of a SRR^S02^SRR_S01 message is NE, an immediate ack SHALL NOT be sent.

Never send an application ack in enhanced mode.

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

SRR^S03^SRR_S01: Scheduled Request Response
HL7 MessageStructure Table - SRR_S01
Segment Cardinality Must Implement Status
SRR_S01
MSH 1..1 Yes
MSA 1..1 Yes
ERR 0..*
SCHEDULE 0..1
SCH 1..1 Yes
TQ1 0..*
NTE 0..*
PATIENT 0..*
PID 1..1 Yes
PRT 0..*
PV1 0..1
PV2 0..1
PRT 0..*
DG1 0..*
RESOURCES 1..* Yes
RGS 1..1 Yes
SERVICE 0..*
AIS 1..1 Yes
NTE 0..*
GENERAL_RESOURCE 0..*
AIG 1..1 Yes
NTE 0..*
LOCATION_RESOURCE 0..*
AIL 1..1 Yes
NTE 0..*
PERSONNEL_RESOURCE 0..*
AIP 1..1 Yes
NTE 0..*

Original Mode Acknowledgement Choreography for SRR^S03^SRR_S01

Send An Acknowlegment is never sent in original mode.

Enhanced Mode Acknowledgement Choreography for SRR^S03^SRR_S01

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

When the MSH-15 value of a SRR^S03^SRR_S01 message is NE, an immediate ack SHALL NOT be sent.

Never send an application ack in enhanced mode.

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

SRR^S04^SRR_S01: Scheduled Request Response
HL7 MessageStructure Table - SRR_S01
Segment Cardinality Must Implement Status
SRR_S01
MSH 1..1 Yes
MSA 1..1 Yes
ERR 0..*
SCHEDULE 0..1
SCH 1..1 Yes
TQ1 0..*
NTE 0..*
PATIENT 0..*
PID 1..1 Yes
PRT 0..*
PV1 0..1
PV2 0..1
PRT 0..*
DG1 0..*
RESOURCES 1..* Yes
RGS 1..1 Yes
SERVICE 0..*
AIS 1..1 Yes
NTE 0..*
GENERAL_RESOURCE 0..*
AIG 1..1 Yes
NTE 0..*
LOCATION_RESOURCE 0..*
AIL 1..1 Yes
NTE 0..*
PERSONNEL_RESOURCE 0..*
AIP 1..1 Yes
NTE 0..*

Original Mode Acknowledgement Choreography for SRR^S04^SRR_S01

Send An Acknowlegment is never sent in original mode.

Enhanced Mode Acknowledgement Choreography for SRR^S04^SRR_S01

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

When the MSH-15 value of a SRR^S04^SRR_S01 message is NE, an immediate ack SHALL NOT be sent.

Never send an application ack in enhanced mode.

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

SRR^S05^SRR_S01: Scheduled Request Response
HL7 MessageStructure Table - SRR_S01
Segment Cardinality Must Implement Status
SRR_S01
MSH 1..1 Yes
MSA 1..1 Yes
ERR 0..*
SCHEDULE 0..1
SCH 1..1 Yes
TQ1 0..*
NTE 0..*
PATIENT 0..*
PID 1..1 Yes
PRT 0..*
PV1 0..1
PV2 0..1
PRT 0..*
DG1 0..*
RESOURCES 1..* Yes
RGS 1..1 Yes
SERVICE 0..*
AIS 1..1 Yes
NTE 0..*
GENERAL_RESOURCE 0..*
AIG 1..1 Yes
NTE 0..*
LOCATION_RESOURCE 0..*
AIL 1..1 Yes
NTE 0..*
PERSONNEL_RESOURCE 0..*
AIP 1..1 Yes
NTE 0..*

Original Mode Acknowledgement Choreography for SRR^S05^SRR_S01

Send An Acknowlegment is never sent in original mode.

Enhanced Mode Acknowledgement Choreography for SRR^S05^SRR_S01

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

When the MSH-15 value of a SRR^S05^SRR_S01 message is NE, an immediate ack SHALL NOT be sent.

Never send an application ack in enhanced mode.

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

SRR^S06^SRR_S01: Scheduled Request Response
HL7 MessageStructure Table - SRR_S01
Segment Cardinality Must Implement Status
SRR_S01
MSH 1..1 Yes
MSA 1..1 Yes
ERR 0..*
SCHEDULE 0..1
SCH 1..1 Yes
TQ1 0..*
NTE 0..*
PATIENT 0..*
PID 1..1 Yes
PRT 0..*
PV1 0..1
PV2 0..1
PRT 0..*
DG1 0..*
RESOURCES 1..* Yes
RGS 1..1 Yes
SERVICE 0..*
AIS 1..1 Yes
NTE 0..*
GENERAL_RESOURCE 0..*
AIG 1..1 Yes
NTE 0..*
LOCATION_RESOURCE 0..*
AIL 1..1 Yes
NTE 0..*
PERSONNEL_RESOURCE 0..*
AIP 1..1 Yes
NTE 0..*

Original Mode Acknowledgement Choreography for SRR^S06^SRR_S01

Send An Acknowlegment is never sent in original mode.

Enhanced Mode Acknowledgement Choreography for SRR^S06^SRR_S01

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

When the MSH-15 value of a SRR^S06^SRR_S01 message is NE, an immediate ack SHALL NOT be sent.

Never send an application ack in enhanced mode.

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

SRR^S07^SRR_S01: Scheduled Request Response
HL7 MessageStructure Table - SRR_S01
Segment Cardinality Must Implement Status
SRR_S01
MSH 1..1 Yes
MSA 1..1 Yes
ERR 0..*
SCHEDULE 0..1
SCH 1..1 Yes
TQ1 0..*
NTE 0..*
PATIENT 0..*
PID 1..1 Yes
PRT 0..*
PV1 0..1
PV2 0..1
PRT 0..*
DG1 0..*
RESOURCES 1..* Yes
RGS 1..1 Yes
SERVICE 0..*
AIS 1..1 Yes
NTE 0..*
GENERAL_RESOURCE 0..*
AIG 1..1 Yes
NTE 0..*
LOCATION_RESOURCE 0..*
AIL 1..1 Yes
NTE 0..*
PERSONNEL_RESOURCE 0..*
AIP 1..1 Yes
NTE 0..*

Original Mode Acknowledgement Choreography for SRR^S07^SRR_S01

Send An Acknowlegment is never sent in original mode.

Enhanced Mode Acknowledgement Choreography for SRR^S07^SRR_S01

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

When the MSH-15 value of a SRR^S07^SRR_S01 message is NE, an immediate ack SHALL NOT be sent.

Never send an application ack in enhanced mode.

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

SRR^S08^SRR_S01: Scheduled Request Response
HL7 MessageStructure Table - SRR_S01
Segment Cardinality Must Implement Status
SRR_S01
MSH 1..1 Yes
MSA 1..1 Yes
ERR 0..*
SCHEDULE 0..1
SCH 1..1 Yes
TQ1 0..*
NTE 0..*
PATIENT 0..*
PID 1..1 Yes
PRT 0..*
PV1 0..1
PV2 0..1
PRT 0..*
DG1 0..*
RESOURCES 1..* Yes
RGS 1..1 Yes
SERVICE 0..*
AIS 1..1 Yes
NTE 0..*
GENERAL_RESOURCE 0..*
AIG 1..1 Yes
NTE 0..*
LOCATION_RESOURCE 0..*
AIL 1..1 Yes
NTE 0..*
PERSONNEL_RESOURCE 0..*
AIP 1..1 Yes
NTE 0..*

Original Mode Acknowledgement Choreography for SRR^S08^SRR_S01

Send An Acknowlegment is never sent in original mode.

Enhanced Mode Acknowledgement Choreography for SRR^S08^SRR_S01

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

When the MSH-15 value of a SRR^S08^SRR_S01 message is NE, an immediate ack SHALL NOT be sent.

Never send an application ack in enhanced mode.

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

SRR^S09^SRR_S01: Scheduled Request Response
HL7 MessageStructure Table - SRR_S01
Segment Cardinality Must Implement Status
SRR_S01
MSH 1..1 Yes
MSA 1..1 Yes
ERR 0..*
SCHEDULE 0..1
SCH 1..1 Yes
TQ1 0..*
NTE 0..*
PATIENT 0..*
PID 1..1 Yes
PRT 0..*
PV1 0..1
PV2 0..1
PRT 0..*
DG1 0..*
RESOURCES 1..* Yes
RGS 1..1 Yes
SERVICE 0..*
AIS 1..1 Yes
NTE 0..*
GENERAL_RESOURCE 0..*
AIG 1..1 Yes
NTE 0..*
LOCATION_RESOURCE 0..*
AIL 1..1 Yes
NTE 0..*
PERSONNEL_RESOURCE 0..*
AIP 1..1 Yes
NTE 0..*

Original Mode Acknowledgement Choreography for SRR^S09^SRR_S01

Send An Acknowlegment is never sent in original mode.

Enhanced Mode Acknowledgement Choreography for SRR^S09^SRR_S01

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

When the MSH-15 value of a SRR^S09^SRR_S01 message is NE, an immediate ack SHALL NOT be sent.

Never send an application ack in enhanced mode.

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

SRR^S10^SRR_S01: Scheduled Request Response
HL7 MessageStructure Table - SRR_S01
Segment Cardinality Must Implement Status
SRR_S01
MSH 1..1 Yes
MSA 1..1 Yes
ERR 0..*
SCHEDULE 0..1
SCH 1..1 Yes
TQ1 0..*
NTE 0..*
PATIENT 0..*
PID 1..1 Yes
PRT 0..*
PV1 0..1
PV2 0..1
PRT 0..*
DG1 0..*
RESOURCES 1..* Yes
RGS 1..1 Yes
SERVICE 0..*
AIS 1..1 Yes
NTE 0..*
GENERAL_RESOURCE 0..*
AIG 1..1 Yes
NTE 0..*
LOCATION_RESOURCE 0..*
AIL 1..1 Yes
NTE 0..*
PERSONNEL_RESOURCE 0..*
AIP 1..1 Yes
NTE 0..*

Original Mode Acknowledgement Choreography for SRR^S10^SRR_S01

Send An Acknowlegment is never sent in original mode.

Enhanced Mode Acknowledgement Choreography for SRR^S10^SRR_S01

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

When the MSH-15 value of a SRR^S10^SRR_S01 message is NE, an immediate ack SHALL NOT be sent.

Never send an application ack in enhanced mode.

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

SRR^S11^SRR_S01: Scheduled Request Response
HL7 MessageStructure Table - SRR_S01
Segment Cardinality Must Implement Status
SRR_S01
MSH 1..1 Yes
MSA 1..1 Yes
ERR 0..*
SCHEDULE 0..1
SCH 1..1 Yes
TQ1 0..*
NTE 0..*
PATIENT 0..*
PID 1..1 Yes
PRT 0..*
PV1 0..1
PV2 0..1
PRT 0..*
DG1 0..*
RESOURCES 1..* Yes
RGS 1..1 Yes
SERVICE 0..*
AIS 1..1 Yes
NTE 0..*
GENERAL_RESOURCE 0..*
AIG 1..1 Yes
NTE 0..*
LOCATION_RESOURCE 0..*
AIL 1..1 Yes
NTE 0..*
PERSONNEL_RESOURCE 0..*
AIP 1..1 Yes
NTE 0..*

Original Mode Acknowledgement Choreography for SRR^S11^SRR_S01

Send An Acknowlegment is never sent in original mode.

Enhanced Mode Acknowledgement Choreography for SRR^S11^SRR_S01

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

When the MSH-15 value of a SRR^S11^SRR_S01 message is NE, an immediate ack SHALL NOT be sent.

Never send an application ack in enhanced mode.

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

Note that in the abstract message definitions for both the SRM and SRR, the patient information segments (segments PID through DG1) are both optional as a group, and repeating as a group. The optionality allows for transactions that relate to a patient, and for those that do not. The ability to repeat the patient information allows for those transactions in which one activity must be scheduled for multiple patients (e.g., for family or group therapy).

In contrast, a transaction may specify no more than (and no less than) one activity. Note that neither the ARQ segment (in the SRM message) nor the SCH segment (in the SRR message) are allowed to repeat, and that they are required. Neither the optionality nor the ability to repeat patient information allows a transaction to specify more than one activity.

The trigger events that use this message definition are listed below.

Request New Appointment Booking (Event S01)

A placer application sends a transaction with this trigger event to a filler application to request that a new appointment be booked. If it is successful, the filler application returns an application acknowledgment (if requested under the enhanced acknowledgment mode, or if the original acknowledgment mode is in use). The acknowledgment may optionally contain an SCH segment and related detail segments describing the actual appointment that was booked.

Request Appointment Rescheduling (Event S02)

A placer application uses this trigger event to request that an existing appointment be rescheduled. The new Requested Start Date and Time, Appointment Duration, Repeating Interval, Repeating Interval Duration, and/or Priority are provided in the ARQ segment, along with the existing placer and filler identification numbers. If it is successful, an application acknowledgment is returned, optionally containing an SCH segment and related detail segments describing the new information for the rescheduled appointment.

This transaction should not be used to reschedule an appointment that has begun but has not been completed. In such cases, and only if it is logical to do so, the appointment should be discontinued and a new schedule request should be submitted. Likewise, this transaction should not be used to reschedule a parent appointment, in which one or more children have begun or have already occurred. Again, the parent appointment should be discontinued, and a new schedule request should be made. This procedure removes any ambiguity between applications that may arise with an attempt to modify an appointment that is in progress.

Request Appointment Modification (Event S03)

This message transmits a request for modification of an existing appointment to a filler application. This trigger event is used to request the modification of information on an existing appointment, outside of the need to reschedule, cancel, discontinue or delete the appointment, or to add, modify, cancel, discontinue, or delete services and/or resources on the appointment. This trigger event should only be used for appointments that have not been completed, or for parent appointments whose children have not been completed. If it is successful, an application acknowledgment is returned, optionally containing an SCH segment and related detail segments describing the new information for the modified appointment.

Request Appointment Cancellation (Event S04)

The request appointment cancellation trigger event is sent by the placer application to the filler application to request that an existing appointment be canceled. A cancel event is used to stop a valid appointment from occurring. For example, if a patient scheduled for an exam cancels his/her appointment, then a request to cancel the appointment is sent. If it is successful, an application acknowledgment is returned, optionally containing an SCH segment and related detail segments describing the canceled appointment.

This trigger event can be used to cancel a parent appointment, in which none of the children of the appointment have either begun or have been completed. Any child appointments that exist on the filler and placer applications should be considered canceled. If one or more child appointments have begun or have been completed, then this trigger event should not be used. Instead, the S05 (request appointment discontinuation) event should be used.

Request Appointment Discontinuation (Event S05)

The request appointment discontinuation is sent by the placer application to the filler application to request that an appointment in progress be stopped, or that the remaining occurrences of a parent appointment not occur as scheduled. If none of the child appointments of a parent appointment have occurred, then a cancel trigger event should be sent instead. If it is successful, an application acknowledgment is returned, optionally containing an SCH segment and related detail segments describing the discontinued appointment.

Request Appointment Deletion (Event S06)

A request appointment deletion is sent by the placer application to the filler application to request that an appointment that had been entered in error be removed from the system. A delete trigger event should only be used when an appointment has been erroneously requested, and must be removed from the schedule so that it does not affect any statistical processing. A delete trigger event differs from a cancel trigger event in that a delete acts to remove an error, whereas a cancel acts to prevent a valid request from occurring. This trigger event should not be used for any appointment that has already begun, or has already been completed. Likewise, it should not be used on any parent appointment if any child appointments have either begun or been completed. If it is successful, an application acknowledgment is returned, optionally containing an SCH segment and related detail segments describing the deleted appointment.

The delete trigger event should be implemented with careful forethought, as it typically has different effects and repercussions in various applications. In some applications, a delete event cannot be undone. This means that if a delete transaction was sent erroneously, recovery will be difficult or impossible. In other applications, a delete transaction will not result in the physical deletion of the record(s), but will set a status or a flag. In these cases, the filler and/or placer appointment identifiers (the numbers or codes that uniquely identify the scheduled appointment or request to the placer and filler applications) probably cannot be reused. Since these applications maintain a record of deleted appointments, the reuse of an identifier will likely cause a conflict in the applications' processing of transactions.

Request Addition of Service/Resource on Appointment (Event S07)

The request addition of service/resource is triggered by the placer application to request that a new service or resource be added to an existing appointment. Services and resources are represented by the AIS, AIG, AIL, and AIP segments on an HL7 scheduling interface transaction. This trigger event should only be used for appointments that have not been completed, or for parent appointments whose children have not been completed. If it is successful, an application acknowledgment is returned, optionally containing an SCH segment and related detail segments describing the modified appointment.

Request Modification of Service/Resource on Appointment (Event S08)

The request modification of service/resource is triggered on the placer application to request that information pertaining to an existing service or resource be changed for an existing appointment. Services and resources are represented by the AIS, AIG, AIL, and AIP segments on an HL7 scheduling interface transaction. This trigger event should only be used for appointments that have not been completed, or for parent appointments whose children have not been completed. If it is successful, an application acknowledgment is returned, optionally containing an SCH segment and related detail segments describing the modified appointment.

This trigger event should not be used when an existing resource or service must be replaced or rescheduled for an existing appointment. The following fields on the indicated segments should not be changed by this trigger event: the first three fields of the AIS, the first four fields of the AIG, the first four fields of the AIL, and the first four fields of the AIP. Instead, use two trigger events to accomplish the replacement or rescheduling of a service or resource: S09 (request cancellation of service/resource on appointment), as well as S07 (request addition of service/resource on appointment).

Request Cancellation of Service/Resource on Appointment (Event S09)

This trigger event requests that a service or resource be removed from an existing scheduled appointment that has not yet begun. A cancel event is used to stop a valid service or resource from participating in the appointment. For example, if a portable X-ray machine scheduled for an exam is no longer needed, then the placer application requests that the resource be canceled on the filler application. This trigger event should only be used for appointments that have not been completed, or for parent appointments whose children have not been completed. If it is successful, an application acknowledgment is returned, optionally containing an SCH segment and related detail segments describing the modified appointment.

Request Discontinuation of Service/Resource on Appointment (Event S10)

A request discontinuation of service/resource is sent by the placer application to the filler application when the remaining occurrences of a recurring appointment no longer require a particular service or resource. In other words, this trigger event is sent to request that the performance of a service or resource in a recurring appointment that has already begun be stopped. If the first appointment in a set of recurring appointments has not yet occurred, then a cancel trigger event should be sent instead. This trigger event should only be used on appointments that have not been completed, or on parent appointments whose children have not been completed. If it is successful, an application acknowledgment is returned, optionally containing an SCH segment and related detail segments describing the modified appointment.

Request Deletion of Service/Resource on Appointment (Event S11)

A request deletion of service/resource is sent by the placer application to the filler application to request that a scheduled appointment requiring a service or resource entered in error be removed from the system. A delete trigger event should only be used when a service or resource has been erroneously attached to an appointment, and must be removed from the schedule so that it does not affect any statistical processing. A delete trigger event differs from a cancel trigger event in that a delete acts to remove an error, whereas a cancel acts to prevent a valid request from occurring. This trigger event should only be used on appointments that have not been completed, or on parent appointments whose children have not been completed. If it is successful, an application acknowledgment is returned, optionally containing an SCH segment and related detail segments describing the modified appointment.

FILLER APPLICATION MESSAGES AND TRIGGER EVENTS UNSOLICITED

Unsolicited transactions from filler applications are the messages and trigger events used between filler applications and auxiliary applications. Transactions are initiated by the filler application, using the SIU message to notify auxiliary applications of modifications in a filler application's schedule(s). The auxiliary application responds to these notifications, using the ACK message, either to acknowledge receipt of the transaction, or to signal that an interfacing error of some kind has occurred.

This set of trigger events is also used to notify applications fulfilling the placer application role of changes in the filler application's schedule(s), if the application is configured to accept these messages and trigger events as an auxiliary application would. As the discussion of application roles has indicated above, any one application can have more than one application role. If it is important that the application acting in the placer application role in your messaging environment be notified of unsolicited changes to a filler application's schedule(s), then it must also support the role of an auxiliary application.

When initiating a notification transaction, the filler application will generate and send an SIU message containing all of the information necessary to communicate the desired information to the auxiliary application. All required segments and fields (both explicitly required and conditionally required) should be provided by the filler application, as defined in this chapter. When the auxiliary application receives the transaction, it acknowledges with the appropriate accept acknowledgment using an ACK message (assuming that the enhanced acknowledgment mode is in use). After processing the notification at the application level, the auxiliary application acknowledges the transaction with the appropriate application acknowledgment in an ACK message (assuming that an application acknowledgment was requested under the enhanced acknowledgment mode, or that the original acknowledgment mode is in use). Applying the explanations of the various application acknowledgment codes (detailed in Chapter 2) in the context of this chapter, an application accept from the auxiliary application means that the notification was processed and accepted. An application error from the auxiliary application means that the auxiliary application was unable to process the notification at the application level. An application reject from the auxiliary application means that the request was not, and could not, be processed due to one or more reasons unrelated to its content (for example: it fails the basic application protocol validation, the system is down, or there was an internal error).

All of the trigger events associated with unsolicited transactions from filler applications use a common message definition that follows:

SIU^S12^SIU_S12: Schedule Information Unsolicited
HL7 MessageStructure Table - SIU_S12
Segment Cardinality Must Implement Status
SIU_S12
MSH 1..1 Yes
SCH 1..1 Yes
TQ1 0..*
NTE 0..*
PATIENT 0..*
PID 1..1 Yes
PD1 0..1
PRT 0..*
PV1 0..1
PV2 0..1
PRT 0..*
OBX 0..*
PRT 0..*
DG1 0..*
RESOURCES 1..* Yes
RGS 1..1 Yes
SERVICE 0..*
AIS 1..1 Yes
NTE 0..*
GENERAL_RESOURCE 0..*
AIG 1..1 Yes
NTE 0..*
LOCATION_RESOURCE 0..*
AIL 1..1 Yes
NTE 0..*
PERSONNEL_RESOURCE 0..*
AIP 1..1 Yes
NTE 0..*

Original Mode Acknowledgement Choreography for SIU^S12^SIU_S12

Send Application Ack: ACK^S12^ACK

Enhanced Mode Acknowledgement Choreography for SIU^S12^SIU_S12

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

When the MSH-15 value of a SIU^S12^SIU_S12 message is NE, an immediate ack SHALL NOT be sent.

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

When the MSH-16 value of a SIU^S12^SIU_S12 message is NE, an application ack SHALL NOT be sent.

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

SIU^S13^SIU_S12: Schedule Information Unsolicited
HL7 MessageStructure Table - SIU_S12
Segment Cardinality Must Implement Status
SIU_S12
MSH 1..1 Yes
SCH 1..1 Yes
TQ1 0..*
NTE 0..*
PATIENT 0..*
PID 1..1 Yes
PD1 0..1
PRT 0..*
PV1 0..1
PV2 0..1
PRT 0..*
OBX 0..*
PRT 0..*
DG1 0..*
RESOURCES 1..* Yes
RGS 1..1 Yes
SERVICE 0..*
AIS 1..1 Yes
NTE 0..*
GENERAL_RESOURCE 0..*
AIG 1..1 Yes
NTE 0..*
LOCATION_RESOURCE 0..*
AIL 1..1 Yes
NTE 0..*
PERSONNEL_RESOURCE 0..*
AIP 1..1 Yes
NTE 0..*

Original Mode Acknowledgement Choreography for SIU^S13^SIU_S12

Send Application Ack: ACK^S13^ACK

Enhanced Mode Acknowledgement Choreography for SIU^S13^SIU_S12

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

When the MSH-15 value of a SIU^S13^SIU_S12 message is NE, an immediate ack SHALL NOT be sent.

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

When the MSH-16 value of a SIU^S13^SIU_S12 message is NE, an application ack SHALL NOT be sent.

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

SIU^S14^SIU_S12: Schedule Information Unsolicited
HL7 MessageStructure Table - SIU_S12
Segment Cardinality Must Implement Status
SIU_S12
MSH 1..1 Yes
SCH 1..1 Yes
TQ1 0..*
NTE 0..*
PATIENT 0..*
PID 1..1 Yes
PD1 0..1
PRT 0..*
PV1 0..1
PV2 0..1
PRT 0..*
OBX 0..*
PRT 0..*
DG1 0..*
RESOURCES 1..* Yes
RGS 1..1 Yes
SERVICE 0..*
AIS 1..1 Yes
NTE 0..*
GENERAL_RESOURCE 0..*
AIG 1..1 Yes
NTE 0..*
LOCATION_RESOURCE 0..*
AIL 1..1 Yes
NTE 0..*
PERSONNEL_RESOURCE 0..*
AIP 1..1 Yes
NTE 0..*

Original Mode Acknowledgement Choreography for SIU^S14^SIU_S12

Send Application Ack: ACK^S14^ACK

Enhanced Mode Acknowledgement Choreography for SIU^S14^SIU_S12

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

When the MSH-15 value of a SIU^S14^SIU_S12 message is NE, an immediate ack SHALL NOT be sent.

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

When the MSH-16 value of a SIU^S14^SIU_S12 message is NE, an application ack SHALL NOT be sent.

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

SIU^S15^SIU_S12: Schedule Information Unsolicited
HL7 MessageStructure Table - SIU_S12
Segment Cardinality Must Implement Status
SIU_S12
MSH 1..1 Yes
SCH 1..1 Yes
TQ1 0..*
NTE 0..*
PATIENT 0..*
PID 1..1 Yes
PD1 0..1
PRT 0..*
PV1 0..1
PV2 0..1
PRT 0..*
OBX 0..*
PRT 0..*
DG1 0..*
RESOURCES 1..* Yes
RGS 1..1 Yes
SERVICE 0..*
AIS 1..1 Yes
NTE 0..*
GENERAL_RESOURCE 0..*
AIG 1..1 Yes
NTE 0..*
LOCATION_RESOURCE 0..*
AIL 1..1 Yes
NTE 0..*
PERSONNEL_RESOURCE 0..*
AIP 1..1 Yes
NTE 0..*

Original Mode Acknowledgement Choreography for SIU^S15^SIU_S12

Send Application Ack: ACK^S15^ACK

Enhanced Mode Acknowledgement Choreography for SIU^S15^SIU_S12

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

When the MSH-15 value of a SIU^S15^SIU_S12 message is NE, an immediate ack SHALL NOT be sent.

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

When the MSH-16 value of a SIU^S15^SIU_S12 message is NE, an application ack SHALL NOT be sent.

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

SIU^S16^SIU_S12: Schedule Information Unsolicited
HL7 MessageStructure Table - SIU_S12
Segment Cardinality Must Implement Status
SIU_S12
MSH 1..1 Yes
SCH 1..1 Yes
TQ1 0..*
NTE 0..*
PATIENT 0..*
PID 1..1 Yes
PD1 0..1
PRT 0..*
PV1 0..1
PV2 0..1
PRT 0..*
OBX 0..*
PRT 0..*
DG1 0..*
RESOURCES 1..* Yes
RGS 1..1 Yes
SERVICE 0..*
AIS 1..1 Yes
NTE 0..*
GENERAL_RESOURCE 0..*
AIG 1..1 Yes
NTE 0..*
LOCATION_RESOURCE 0..*
AIL 1..1 Yes
NTE 0..*
PERSONNEL_RESOURCE 0..*
AIP 1..1 Yes
NTE 0..*

Original Mode Acknowledgement Choreography for SIU^S16^SIU_S12

Send Application Ack: ACK^S16^ACK

Enhanced Mode Acknowledgement Choreography for SIU^S16^SIU_S12

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

When the MSH-15 value of a SIU^S16^SIU_S12 message is NE, an immediate ack SHALL NOT be sent.

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

When the MSH-16 value of a SIU^S16^SIU_S12 message is NE, an application ack SHALL NOT be sent.

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

SIU^S17^SIU_S12: Schedule Information Unsolicited
HL7 MessageStructure Table - SIU_S12
Segment Cardinality Must Implement Status
SIU_S12
MSH 1..1 Yes
SCH 1..1 Yes
TQ1 0..*
NTE 0..*
PATIENT 0..*
PID 1..1 Yes
PD1 0..1
PRT 0..*
PV1 0..1
PV2 0..1
PRT 0..*
OBX 0..*
PRT 0..*
DG1 0..*
RESOURCES 1..* Yes
RGS 1..1 Yes
SERVICE 0..*
AIS 1..1 Yes
NTE 0..*
GENERAL_RESOURCE 0..*
AIG 1..1 Yes
NTE 0..*
LOCATION_RESOURCE 0..*
AIL 1..1 Yes
NTE 0..*
PERSONNEL_RESOURCE 0..*
AIP 1..1 Yes
NTE 0..*

Original Mode Acknowledgement Choreography for SIU^S17^SIU_S12

Send Application Ack: ACK^S17^ACK

Enhanced Mode Acknowledgement Choreography for SIU^S17^SIU_S12

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

When the MSH-15 value of a SIU^S17^SIU_S12 message is NE, an immediate ack SHALL NOT be sent.

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

When the MSH-16 value of a SIU^S17^SIU_S12 message is NE, an application ack SHALL NOT be sent.

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

SIU^S18^SIU_S12: Schedule Information Unsolicited
HL7 MessageStructure Table - SIU_S12
Segment Cardinality Must Implement Status
SIU_S12
MSH 1..1 Yes
SCH 1..1 Yes
TQ1 0..*
NTE 0..*
PATIENT 0..*
PID 1..1 Yes
PD1 0..1
PRT 0..*
PV1 0..1
PV2 0..1
PRT 0..*
OBX 0..*
PRT 0..*
DG1 0..*
RESOURCES 1..* Yes
RGS 1..1 Yes
SERVICE 0..*
AIS 1..1 Yes
NTE 0..*
GENERAL_RESOURCE 0..*
AIG 1..1 Yes
NTE 0..*
LOCATION_RESOURCE 0..*
AIL 1..1 Yes
NTE 0..*
PERSONNEL_RESOURCE 0..*
AIP 1..1 Yes
NTE 0..*

Original Mode Acknowledgement Choreography for SIU^S18^SIU_S12

Send Application Ack: ACK^S18^ACK

Enhanced Mode Acknowledgement Choreography for SIU^S18^SIU_S12

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

When the MSH-15 value of a SIU^S18^SIU_S12 message is NE, an immediate ack SHALL NOT be sent.

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

When the MSH-16 value of a SIU^S18^SIU_S12 message is NE, an application ack SHALL NOT be sent.

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

SIU^S19^SIU_S12: Schedule Information Unsolicited
HL7 MessageStructure Table - SIU_S12
Segment Cardinality Must Implement Status
SIU_S12
MSH 1..1 Yes
SCH 1..1 Yes
TQ1 0..*
NTE 0..*
PATIENT 0..*
PID 1..1 Yes
PD1 0..1
PRT 0..*
PV1 0..1
PV2 0..1
PRT 0..*
OBX 0..*
PRT 0..*
DG1 0..*
RESOURCES 1..* Yes
RGS 1..1 Yes
SERVICE 0..*
AIS 1..1 Yes
NTE 0..*
GENERAL_RESOURCE 0..*
AIG 1..1 Yes
NTE 0..*
LOCATION_RESOURCE 0..*
AIL 1..1 Yes
NTE 0..*
PERSONNEL_RESOURCE 0..*
AIP 1..1 Yes
NTE 0..*

Original Mode Acknowledgement Choreography for SIU^S19^SIU_S12

Send Application Ack: ACK^S19^ACK

Enhanced Mode Acknowledgement Choreography for SIU^S19^SIU_S12

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

When the MSH-15 value of a SIU^S19^SIU_S12 message is NE, an immediate ack SHALL NOT be sent.

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

When the MSH-16 value of a SIU^S19^SIU_S12 message is NE, an application ack SHALL NOT be sent.

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

SIU^S20^SIU_S12: Schedule Information Unsolicited
HL7 MessageStructure Table - SIU_S12
Segment Cardinality Must Implement Status
SIU_S12
MSH 1..1 Yes
SCH 1..1 Yes
TQ1 0..*
NTE 0..*
PATIENT 0..*
PID 1..1 Yes
PD1 0..1
PRT 0..*
PV1 0..1
PV2 0..1
PRT 0..*
OBX 0..*
PRT 0..*
DG1 0..*
RESOURCES 1..* Yes
RGS 1..1 Yes
SERVICE 0..*
AIS 1..1 Yes
NTE 0..*
GENERAL_RESOURCE 0..*
AIG 1..1 Yes
NTE 0..*
LOCATION_RESOURCE 0..*
AIL 1..1 Yes
NTE 0..*
PERSONNEL_RESOURCE 0..*
AIP 1..1 Yes
NTE 0..*

Original Mode Acknowledgement Choreography for SIU^S20^SIU_S12

Send Application Ack: ACK^S20^ACK

Enhanced Mode Acknowledgement Choreography for SIU^S20^SIU_S12

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

When the MSH-15 value of a SIU^S20^SIU_S12 message is NE, an immediate ack SHALL NOT be sent.

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

When the MSH-16 value of a SIU^S20^SIU_S12 message is NE, an application ack SHALL NOT be sent.

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

SIU^S21^SIU_S12: Schedule Information Unsolicited
HL7 MessageStructure Table - SIU_S12
Segment Cardinality Must Implement Status
SIU_S12
MSH 1..1 Yes
SCH 1..1 Yes
TQ1 0..*
NTE 0..*
PATIENT 0..*
PID 1..1 Yes
PD1 0..1
PRT 0..*
PV1 0..1
PV2 0..1
PRT 0..*
OBX 0..*
PRT 0..*
DG1 0..*
RESOURCES 1..* Yes
RGS 1..1 Yes
SERVICE 0..*
AIS 1..1 Yes
NTE 0..*
GENERAL_RESOURCE 0..*
AIG 1..1 Yes
NTE 0..*
LOCATION_RESOURCE 0..*
AIL 1..1 Yes
NTE 0..*
PERSONNEL_RESOURCE 0..*
AIP 1..1 Yes
NTE 0..*

Original Mode Acknowledgement Choreography for SIU^S21^SIU_S12

Send Application Ack: ACK^S21^ACK

Enhanced Mode Acknowledgement Choreography for SIU^S21^SIU_S12

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

When the MSH-15 value of a SIU^S21^SIU_S12 message is NE, an immediate ack SHALL NOT be sent.

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

When the MSH-16 value of a SIU^S21^SIU_S12 message is NE, an application ack SHALL NOT be sent.

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

SIU^S22^SIU_S12: Schedule Information Unsolicited
HL7 MessageStructure Table - SIU_S12
Segment Cardinality Must Implement Status
SIU_S12
MSH 1..1 Yes
SCH 1..1 Yes
TQ1 0..*
NTE 0..*
PATIENT 0..*
PID 1..1 Yes
PD1 0..1
PRT 0..*
PV1 0..1
PV2 0..1
PRT 0..*
OBX 0..*
PRT 0..*
DG1 0..*
RESOURCES 1..* Yes
RGS 1..1 Yes
SERVICE 0..*
AIS 1..1 Yes
NTE 0..*
GENERAL_RESOURCE 0..*
AIG 1..1 Yes
NTE 0..*
LOCATION_RESOURCE 0..*
AIL 1..1 Yes
NTE 0..*
PERSONNEL_RESOURCE 0..*
AIP 1..1 Yes
NTE 0..*

Original Mode Acknowledgement Choreography for SIU^S22^SIU_S12

Send Application Ack: ACK^S22^ACK

Enhanced Mode Acknowledgement Choreography for SIU^S22^SIU_S12

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

When the MSH-15 value of a SIU^S22^SIU_S12 message is NE, an immediate ack SHALL NOT be sent.

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

When the MSH-16 value of a SIU^S22^SIU_S12 message is NE, an application ack SHALL NOT be sent.

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

SIU^S23^SIU_S12: Schedule Information Unsolicited
HL7 MessageStructure Table - SIU_S12
Segment Cardinality Must Implement Status
SIU_S12
MSH 1..1 Yes
SCH 1..1 Yes
TQ1 0..*
NTE 0..*
PATIENT 0..*
PID 1..1 Yes
PD1 0..1
PRT 0..*
PV1 0..1
PV2 0..1
PRT 0..*
OBX 0..*
PRT 0..*
DG1 0..*
RESOURCES 1..* Yes
RGS 1..1 Yes
SERVICE 0..*
AIS 1..1 Yes
NTE 0..*
GENERAL_RESOURCE 0..*
AIG 1..1 Yes
NTE 0..*
LOCATION_RESOURCE 0..*
AIL 1..1 Yes
NTE 0..*
PERSONNEL_RESOURCE 0..*
AIP 1..1 Yes
NTE 0..*

Original Mode Acknowledgement Choreography for SIU^S23^SIU_S12

Send Application Ack: ACK^S23^ACK

Enhanced Mode Acknowledgement Choreography for SIU^S23^SIU_S12

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

When the MSH-15 value of a SIU^S23^SIU_S12 message is NE, an immediate ack SHALL NOT be sent.

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

When the MSH-16 value of a SIU^S23^SIU_S12 message is NE, an application ack SHALL NOT be sent.

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

SIU^S24^SIU_S12: Schedule Information Unsolicited
HL7 MessageStructure Table - SIU_S12
Segment Cardinality Must Implement Status
SIU_S12
MSH 1..1 Yes
SCH 1..1 Yes
TQ1 0..*
NTE 0..*
PATIENT 0..*
PID 1..1 Yes
PD1 0..1
PRT 0..*
PV1 0..1
PV2 0..1
PRT 0..*
OBX 0..*
PRT 0..*
DG1 0..*
RESOURCES 1..* Yes
RGS 1..1 Yes
SERVICE 0..*
AIS 1..1 Yes
NTE 0..*
GENERAL_RESOURCE 0..*
AIG 1..1 Yes
NTE 0..*
LOCATION_RESOURCE 0..*
AIL 1..1 Yes
NTE 0..*
PERSONNEL_RESOURCE 0..*
AIP 1..1 Yes
NTE 0..*

Original Mode Acknowledgement Choreography for SIU^S24^SIU_S12

Send Application Ack: ACK^S24^ACK

Enhanced Mode Acknowledgement Choreography for SIU^S24^SIU_S12

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

When the MSH-15 value of a SIU^S24^SIU_S12 message is NE, an immediate ack SHALL NOT be sent.

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

When the MSH-16 value of a SIU^S24^SIU_S12 message is NE, an application ack SHALL NOT be sent.

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

SIU^S26^SIU_S12: Schedule Information Unsolicited
HL7 MessageStructure Table - SIU_S12
Segment Cardinality Must Implement Status
SIU_S12
MSH 1..1 Yes
SCH 1..1 Yes
TQ1 0..*
NTE 0..*
PATIENT 0..*
PID 1..1 Yes
PD1 0..1
PRT 0..*
PV1 0..1
PV2 0..1
PRT 0..*
OBX 0..*
PRT 0..*
DG1 0..*
RESOURCES 1..* Yes
RGS 1..1 Yes
SERVICE 0..*
AIS 1..1 Yes
NTE 0..*
GENERAL_RESOURCE 0..*
AIG 1..1 Yes
NTE 0..*
LOCATION_RESOURCE 0..*
AIL 1..1 Yes
NTE 0..*
PERSONNEL_RESOURCE 0..*
AIP 1..1 Yes
NTE 0..*

Original Mode Acknowledgement Choreography for SIU^S26^SIU_S12

Send Application Ack: ACK^S26^ACK

Enhanced Mode Acknowledgement Choreography for SIU^S26^SIU_S12

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

When the MSH-15 value of a SIU^S26^SIU_S12 message is NE, an immediate ack SHALL NOT be sent.

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

When the MSH-16 value of a SIU^S26^SIU_S12 message is NE, an application ack SHALL NOT be sent.

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

SIU^S27^SIU_S12: Schedule Information Unsolicited
HL7 MessageStructure Table - SIU_S12
Segment Cardinality Must Implement Status
SIU_S12
MSH 1..1 Yes
SCH 1..1 Yes
TQ1 0..*
NTE 0..*
PATIENT 0..*
PID 1..1 Yes
PD1 0..1
PRT 0..*
PV1 0..1
PV2 0..1
PRT 0..*
OBX 0..*
PRT 0..*
DG1 0..*
RESOURCES 1..* Yes
RGS 1..1 Yes
SERVICE 0..*
AIS 1..1 Yes
NTE 0..*
GENERAL_RESOURCE 0..*
AIG 1..1 Yes
NTE 0..*
LOCATION_RESOURCE 0..*
AIL 1..1 Yes
NTE 0..*
PERSONNEL_RESOURCE 0..*
AIP 1..1 Yes
NTE 0..*

Original Mode Acknowledgement Choreography for SIU^S27^SIU_S12

Send Application Ack: ACK^S27^ACK

Enhanced Mode Acknowledgement Choreography for SIU^S27^SIU_S12

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

When the MSH-15 value of a SIU^S27^SIU_S12 message is NE, an immediate ack SHALL NOT be sent.

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

When the MSH-16 value of a SIU^S27^SIU_S12 message is NE, an application ack SHALL NOT be sent.

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

ACK^S12^ACK: General Acknowledgment
HL7 MessageStructure Table - ACK
Segment Cardinality Must Implement Status
ACK
MSH 1..1 Yes
SFT 0..*
UAC 0..1
MSA 1..1 Yes
ERR 0..*

Original Mode Acknowledgement Choreography for ACK^S12^ACK

Send An Acknowlegment is never sent in original mode.

Enhanced Mode Acknowledgement Choreography for ACK^S12^ACK

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

When the MSH-15 value of an ACK^S12^ACK message is NE, an immediate ack SHALL NOT be sent.

Never send an application ack in enhanced mode.

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

ACK^S13^ACK: General Acknowledgment
HL7 MessageStructure Table - ACK
Segment Cardinality Must Implement Status
ACK
MSH 1..1 Yes
SFT 0..*
UAC 0..1
MSA 1..1 Yes
ERR 0..*

Original Mode Acknowledgement Choreography for ACK^S13^ACK

Send An Acknowlegment is never sent in original mode.

Enhanced Mode Acknowledgement Choreography for ACK^S13^ACK

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

When the MSH-15 value of an ACK^S13^ACK message is NE, an immediate ack SHALL NOT be sent.

Never send an application ack in enhanced mode.

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

ACK^S14^ACK: General Acknowledgment
HL7 MessageStructure Table - ACK
Segment Cardinality Must Implement Status
ACK
MSH 1..1 Yes
SFT 0..*
UAC 0..1
MSA 1..1 Yes
ERR 0..*

Original Mode Acknowledgement Choreography for ACK^S14^ACK

Send An Acknowlegment is never sent in original mode.

Enhanced Mode Acknowledgement Choreography for ACK^S14^ACK

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

When the MSH-15 value of an ACK^S14^ACK message is NE, an immediate ack SHALL NOT be sent.

Never send an application ack in enhanced mode.

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

ACK^S15^ACK: General Acknowledgment
HL7 MessageStructure Table - ACK
Segment Cardinality Must Implement Status
ACK
MSH 1..1 Yes
SFT 0..*
UAC 0..1
MSA 1..1 Yes
ERR 0..*

Original Mode Acknowledgement Choreography for ACK^S15^ACK

Send An Acknowlegment is never sent in original mode.

Enhanced Mode Acknowledgement Choreography for ACK^S15^ACK

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

When the MSH-15 value of an ACK^S15^ACK message is NE, an immediate ack SHALL NOT be sent.

Never send an application ack in enhanced mode.

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

ACK^S16^ACK: General Acknowledgment
HL7 MessageStructure Table - ACK
Segment Cardinality Must Implement Status
ACK
MSH 1..1 Yes
SFT 0..*
UAC 0..1
MSA 1..1 Yes
ERR 0..*

Original Mode Acknowledgement Choreography for ACK^S16^ACK

Send An Acknowlegment is never sent in original mode.

Enhanced Mode Acknowledgement Choreography for ACK^S16^ACK

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

When the MSH-15 value of an ACK^S16^ACK message is NE, an immediate ack SHALL NOT be sent.

Never send an application ack in enhanced mode.

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

ACK^S17^ACK: General Acknowledgment
HL7 MessageStructure Table - ACK
Segment Cardinality Must Implement Status
ACK
MSH 1..1 Yes
SFT 0..*
UAC 0..1
MSA 1..1 Yes
ERR 0..*

Original Mode Acknowledgement Choreography for ACK^S17^ACK

Send An Acknowlegment is never sent in original mode.

Enhanced Mode Acknowledgement Choreography for ACK^S17^ACK

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

When the MSH-15 value of an ACK^S17^ACK message is NE, an immediate ack SHALL NOT be sent.

Never send an application ack in enhanced mode.

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

ACK^S18^ACK: General Acknowledgment
HL7 MessageStructure Table - ACK
Segment Cardinality Must Implement Status
ACK
MSH 1..1 Yes
SFT 0..*
UAC 0..1
MSA 1..1 Yes
ERR 0..*

Original Mode Acknowledgement Choreography for ACK^S18^ACK

Send An Acknowlegment is never sent in original mode.

Enhanced Mode Acknowledgement Choreography for ACK^S18^ACK

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

When the MSH-15 value of an ACK^S18^ACK message is NE, an immediate ack SHALL NOT be sent.

Never send an application ack in enhanced mode.

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

ACK^S19^ACK: General Acknowledgment
HL7 MessageStructure Table - ACK
Segment Cardinality Must Implement Status
ACK
MSH 1..1 Yes
SFT 0..*
UAC 0..1
MSA 1..1 Yes
ERR 0..*

Original Mode Acknowledgement Choreography for ACK^S19^ACK

Send An Acknowlegment is never sent in original mode.

Enhanced Mode Acknowledgement Choreography for ACK^S19^ACK

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

When the MSH-15 value of an ACK^S19^ACK message is NE, an immediate ack SHALL NOT be sent.

Never send an application ack in enhanced mode.

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

ACK^S20^ACK: General Acknowledgment
HL7 MessageStructure Table - ACK
Segment Cardinality Must Implement Status
ACK
MSH 1..1 Yes
SFT 0..*
UAC 0..1
MSA 1..1 Yes
ERR 0..*

Original Mode Acknowledgement Choreography for ACK^S20^ACK

Send An Acknowlegment is never sent in original mode.

Enhanced Mode Acknowledgement Choreography for ACK^S20^ACK

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

When the MSH-15 value of an ACK^S20^ACK message is NE, an immediate ack SHALL NOT be sent.

Never send an application ack in enhanced mode.

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

ACK^S21^ACK: General Acknowledgment
HL7 MessageStructure Table - ACK
Segment Cardinality Must Implement Status
ACK
MSH 1..1 Yes
SFT 0..*
UAC 0..1
MSA 1..1 Yes
ERR 0..*

Original Mode Acknowledgement Choreography for ACK^S21^ACK

Send An Acknowlegment is never sent in original mode.

Enhanced Mode Acknowledgement Choreography for ACK^S21^ACK

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

When the MSH-15 value of an ACK^S21^ACK message is NE, an immediate ack SHALL NOT be sent.

Never send an application ack in enhanced mode.

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

ACK^S22^ACK: General Acknowledgment
HL7 MessageStructure Table - ACK
Segment Cardinality Must Implement Status
ACK
MSH 1..1 Yes
SFT 0..*
UAC 0..1
MSA 1..1 Yes
ERR 0..*

Original Mode Acknowledgement Choreography for ACK^S22^ACK

Send An Acknowlegment is never sent in original mode.

Enhanced Mode Acknowledgement Choreography for ACK^S22^ACK

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

When the MSH-15 value of an ACK^S22^ACK message is NE, an immediate ack SHALL NOT be sent.

Never send an application ack in enhanced mode.

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

ACK^S23^ACK: General Acknowledgment
HL7 MessageStructure Table - ACK
Segment Cardinality Must Implement Status
ACK
MSH 1..1 Yes
SFT 0..*
UAC 0..1
MSA 1..1 Yes
ERR 0..*

Original Mode Acknowledgement Choreography for ACK^S23^ACK

Send An Acknowlegment is never sent in original mode.

Enhanced Mode Acknowledgement Choreography for ACK^S23^ACK

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

When the MSH-15 value of an ACK^S23^ACK message is NE, an immediate ack SHALL NOT be sent.

Never send an application ack in enhanced mode.

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

ACK^S24^ACK: General Acknowledgment
HL7 MessageStructure Table - ACK
Segment Cardinality Must Implement Status
ACK
MSH 1..1 Yes
SFT 0..*
UAC 0..1
MSA 1..1 Yes
ERR 0..*

Original Mode Acknowledgement Choreography for ACK^S24^ACK

Send An Acknowlegment is never sent in original mode.

Enhanced Mode Acknowledgement Choreography for ACK^S24^ACK

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

When the MSH-15 value of an ACK^S24^ACK message is NE, an immediate ack SHALL NOT be sent.

Never send an application ack in enhanced mode.

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

ACK^S26^ACK: General Acknowledgment
HL7 MessageStructure Table - ACK
Segment Cardinality Must Implement Status
ACK
MSH 1..1 Yes
SFT 0..*
UAC 0..1
MSA 1..1 Yes
ERR 0..*

Original Mode Acknowledgement Choreography for ACK^S26^ACK

Send An Acknowlegment is never sent in original mode.

Enhanced Mode Acknowledgement Choreography for ACK^S26^ACK

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

When the MSH-15 value of an ACK^S26^ACK message is NE, an immediate ack SHALL NOT be sent.

Never send an application ack in enhanced mode.

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

ACK^S27^ACK: General Acknowledgment
HL7 MessageStructure Table - ACK
Segment Cardinality Must Implement Status
ACK
MSH 1..1 Yes
SFT 0..*
UAC 0..1
MSA 1..1 Yes
ERR 0..*

Original Mode Acknowledgement Choreography for ACK^S27^ACK

Send An Acknowlegment is never sent in original mode.

Enhanced Mode Acknowledgement Choreography for ACK^S27^ACK

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

When the MSH-15 value of an ACK^S27^ACK message is NE, an immediate ack SHALL NOT be sent.

Never send an application ack in enhanced mode.

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

The trigger events that use this message definition are listed below.

Notification of New Appointment Booking (Event S12)

This message is sent from a filler application to notify other applications that a new appointment has been booked. The information provided in the SCH segment and the other detail segments as appropriate describe the appointment that has been booked by the filler application.

Notification of Appointment Rescheduling (Event S13)

This message is sent from a filler application to notify other applications that an existing appointment has been rescheduled. The information in the SCH segment and the other detail segments as appropriate describe the new date(s) and time(s) to which the previously booked appointment has been moved. Additionally, it describes the unchanged information in the previously booked appointment.

This transaction should not be used to reschedule an appointment that has begun but has not been completed. In such cases, and only if it logical to do so, the appointment should be discontinued and a new schedule request should be submitted. Likewise, this transaction should not be used to reschedule a parent appointment, in which one or more children have begun or have already taken place. Again, the parent appointment should be discontinued, and a new schedule request should be made. This procedure removes any ambiguity between applications that may arise with an attempt to modify an appointment that is in progress.

Notification of Appointment Modification (Event S14)

This message notifies other applications that an existing appointment has been modified on the filler application. This trigger event should only be used for appointments that have not been completed, or for parent appointments whose children have not been completed.

Notification of Appointment Cancellation (Event S15)

A notification of appointment cancellation is sent by the filler application to other applications when an existing appointment has been canceled. A cancel event is used to stop a valid appointment from taking place. For example, if a patient scheduled for an exam cancels his/her appointment, then the appointment is canceled on the filler application.

This trigger event can be used to cancel a parent appointment, in which none of the children of the appointment have either begun or been completed. Any child appointments that exist on the filler and placer applications should be considered canceled. If one or more child appointments have begun or have been completed, then this trigger event should not be used. Instead, the S16 (notification of appointment discontinuation) event should be used.

Notification of Appointment Discontinuation (Event S16)

A notification of appointment discontinuation is sent by the filler application to notify other applications that an appointment in progress has been stopped, or that the remaining occurrences of a parent appointment will not occur. If none of the child appointments of a parent appointment have taken place, then a cancel trigger event should be sent instead.

Notification of Appointment Deletion (Event S17)

A notification of appointment deletion is sent by the filler application to other applications when an appointment that had been entered in error has been removed from the system. A delete trigger event should only be used when an appointment has been erroneously scheduled. It must be removed from the schedule so that it does not affect any statistical processing. A delete trigger event differs from a cancel trigger event in that a delete acts to remove an error, whereas a cancel acts to prevent a valid request from occurring. This trigger event should not be used for any appointment that has already begun, or that has already been completed. Likewise, it should not be used for any parent appointment if any child appointments have either begun or been completed.

The delete trigger event should be implemented with careful forethought, as it typically has different effects and repercussions in various applications. In some applications, a delete event cannot be undone. This means that if a delete transaction was sent erroneously, recovery will be difficult or impossible. In other applications, a delete transaction will not result in the physical deletion of the record(s), but will set a status or a flag. In these cases, the filler and/or placer appointment identifiers (the numbers or codes that uniquely identify the scheduled appointment or request to the placer and filler applications) probably cannot be reused. Since these applications maintain a record of deleted appointments, the reuse of an identifier will likely cause a conflict in the applications' processing of transactions.

Notification of Addition of Service/Resource on Appointment (Event S18)

The notification of addition of service/resource is triggered on the filler application when a new service or resource has been added to an existing appointment. Services and resources are represented by the AIS, AIG, AIL, and AIP segments on an HL7 scheduling interface transaction. This trigger event should only be used for appointments that have not been completed, or for parent appointments whose children have not been completed.

Notification of Modification of Service/Resource on Appointment (Event S19)

The notification of modification of service/resource is triggered on the filler application when the information pertaining to an existing service or resource has been changed for an existing appointment. Services and resources are represented by the AIS, AIG, AIL, and AIP segments on an HL7 scheduling interface transaction. This trigger event should only be used for appointments that have not been completed, or for parent appointments whose children have not been completed.

This trigger event should not be used when an existing resource or service has been replaced in relation to an existing appointment. Instead, use two other trigger events: S20 (notification of cancellation of service/ resource on appointment), as well as S18 (notification of addition of service/resource on appointment).

Notification of Cancellation of Service/Resource on Appointment (Event S20)

This trigger event notifies other applications that a service or resource has been removed from an existing scheduled appointment that has not yet begun. A cancel event is used to stop a valid service or resource from participating in the appointment. For example, if a portable X-ray machine scheduled for an exam is no longer needed, then the resource is canceled on the filler application. This trigger event should only be used for appointments that have not been completed, or for parent appointments whose children have not been completed.

Notification of Discontinuation of Service/Resource on Appointment (Event S21)

A notification of discontinuation of service/resource is sent by the filler application to other applications when the remaining children of a parent appointment no longer require a particular service or resource. In other words, this trigger event is sent to discontinue the performance of a service or resource in a parent appointment that has already begun. If the first appointment in a set of recurring appointments has not yet taken place, then a cancel trigger event should be sent instead. This trigger event should only be used for appointments that have not been completed, or for parent appointments whose children have not been completed.

Notification of Deletion of Service/Resource on Appointment (Event S22)

A notification of deletion of service/resource is sent by the filler application to other applications when a scheduled appointment requiring a service or resource entered in error has been removed from the system. A delete trigger event should only be used in those circumstances when a service or resource has been erroneously attached to an appointment, and must be removed from the schedule so that it does not affect any statistical processing. A delete trigger event differs from a cancel trigger event in that a delete acts to remove an error, whereas a cancel acts to prevent a valid request from taking place.

Notification of Blocked Schedule Time Slot(S) (Event S23)

A notification of blocked schedule time slots is sent by the filler application to other applications when a schedule has had one or more time slots blocked and made unavailable for reasons other than the scheduling of an appointment. For example, if an exam room is unavailable for several hours because of maintenance needs or contamination, a user may block off those several hours on the exam room's schedule. Similarly, if a physician is unavailable because he or she has taken vacation time, his or her schedule may be blocked off for the duration of the vacation. When these types of conditions exist, the filler application may use this transaction to notify other applications that the resources controlled by schedules are unavailable.

Notification of Opened ("un-blocked") Schedule Time Slot(s) (Event S24)

A notification of blocked schedule time slots is sent by the filler application to other applications when a schedule has one or more time slots open up ("un-blocked") and become available for use. Typically, the blocked period of time on a schedule is simply allowed to expire, because the blocked amount of time is generally used for non-appointment activities. This transaction can be used either to discontinue the blocked status on the schedule, or to reverse a previous block made in error. For the purposes of this transaction, discontinuing a block currently in progress (the blocked period has started, but not yet completed) and canceling a blocked period in the future are not significantly different. Therefore, a separate discontinue block transaction is not necessary. If this transaction is received prior to the inception of a blocked period, then the entire block period is simply canceled according to the data provided in the transaction. If the transaction is received after the blocked period has begun, but prior to the end of the blocked period, then the blocked period is discontinued according to the data provided in the transactions. Applications may decide how to handle transactions that attempt to open a blocked period that has both started and ended in the past; however, these transactions can generally be ignored.

For example, if an exam room has been blocked for several hours because of maintenance activities or contamination, and if the work has been completed ahead of schedule, a user may open those several hours on the exam room's schedule. When such a situation occurs, the filler application may use this transaction to notify other applications that the room is available.

Notification That Patient Did Not Show Up for Scheduled Appointment (Event S26)

A notification that a patient did not show up for an appointment. For example, if a patient was scheduled for a clinic visit, and never arrived for that appointment, this trigger event can be used to set a status on the appointment record for statistical purposes, as well as to free resources assigned to the appointment (or any other application level actions that must be taken in the event a patient does not appear for an appointment).

Patient Administration events defined in Chapter 3 can be used to indicate that a patient has arrived for an appointment, e.g., A01 (admit/visit notification), A04 (register a patient), A05 (pre-admit a patient), or A10 (patient arriving - tracking) as possible examples. Similarly, Patient Administration transactions can be used to identify the end of an appointment, e.g., A03 (discharge/end visit) or A09 (patient departing - tracking) as possible examples.

Broadcast Notification of Scheduled Appointments (Event S27)

The broadcast notification of scheduled appointments event is triggered on the filler application in advance of upcoming, active, scheduled appointments according to preset time considerations (i.e., a batch interface in which both the time the messages are to be sent and/or the time/date range of the upcoming appointments-to-be-sent could be configured). Given those configured time considerations, the trigger event includes information for any/all scheduled appointments for the preset event processing period without regard for any new, modified or rescheduled appointment information. Receiving systems should then plan to interchangeably accept and process inbound messages as either new or updated appointment messages. Also, since cancelled or deleted appointments that may have been scheduled for a given processing period are no longer a part of an active, upcoming schedule, information for such appointments should not be included in this event’s processing (other events like the S15 or S17 should still be used for this purpose). This trigger event should only be used for appointments that have not been completed, or for parent appointments whose children have not been completed.

QUERY TRANSACTIONS AND TRIGGER EVENTS

Query transactions are the messages and trigger events used between querying applications and filler applications. In Version 2.4 of the Standard, there are several types of queries available. Original mode display-oriented and record-oriented queries are compatible with the queries defined in previous versions of the Standard. New enhanced mode queries include an Embedded Query Language (EQQ), a Virtual Table Query (VQQ), a Stored Procedure Request (SPQ), and an Event Replay Query. Original mode display-oriented queries now have an Enhanced Display Response (EDR) available in Version 2.3. Descriptions and definitions of these query types are found in Chapter 5, section 5.10.4, "Query Trigger Events and Message Definitions."

As the discussion of application roles has indicated above, any one application can have more than one application role. If it is important that applications in your messaging environment that fulfill either the placer or auxiliary application roles be able to query information actively from a filler application's schedule(s), then they must also support the role of a querying application.

Original Mode Queries - Display Oriented

Retained for backwards compatibility only in version 2.4 and withdrawn as of v2.7; refer to Chapter 5, section 5.4. The original mode query and the QRD/QRF segments have been replaced.

Original Mode Queries - Record Oriented

Retained for backwards compatibility only in version 2.4 and withdraw as of v2.7; refer to Chapter 5 section 5.4. The original mode query and the QRD/QRF segments have been replaced.

SQM/SQR - Schedule Query Message and Response (Event S25)

Retained for backwards compatibility only in version 2.4 and withdrawn as of v2.7; refer to Chapter 5 section 5.4. The original mode query and the QRD/QRF segments have been replaced.

Enhanced Mode Queries

Retained for backwards compatibility only in version 2.4 and withdrawn as of v2.7; refer to Chapter 5, section 5.4. The original mode query and the QRD/QRF segments have been replaced.

MESSAGE SEGMENTS

ARQ - Appointment Request Segment

The ARQ segment defines a request for the booking of an appointment. It is used in transactions sent from an application acting in the role of a placer.

HL7 Attribute Table - ARQ - Appointment Request Segment
Seq# DataElement Description Must Implement Flags Cardinality Length C.LEN Vocabulary DataType
ARQ
1 00860 Placer Appointment ID SHALL [1..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 00865 Request Event Reason [0..1] CWE
7 00866 Appointment Reason [0..1] CWE
8 00867 Appointment Type [0..1] CWE
9 00868 Appointment Duration = [0..1] 5 NM
10 00869 Appointment Duration Units [0..1] CNE
11 00870 Requested Start Date/Time Range [0..*] DR
12 00871 Priority-ARQ = [0..1] 5 ST
13 00872 Repeating Interval [0..1] RI
14 00873 Repeating Interval Duration = [0..1] 5 ST
15 00874 Placer Contact Person SHALL [1..*] XCN
16 00875 Placer Contact Phone Number [0..*] XTN
17 00876 Placer Contact Address [0..*] XAD
18 00877 Placer Contact Location [0..1] PL
19 00878 Entered By Person SHALL [1..*] XCN
20 00879 Entered By Phone Number [0..*] XTN
21 00880 Entered By Location [0..1] PL
22 00881 Parent Placer Appointment ID [0..1] EI
23 00882 Parent Filler Appointment ID [0..1] EI
24

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

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

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

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

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

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

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

ARQ-6: Request Event Reason (CWE) 00865

Definition: This field contains the identifier code for the reason that the request event is being triggered. This field may contain a code describing the cancel reason, the delete reason, the discontinue reason, the add reason, or any other code describing the reason that a specific event is occurring.

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

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

ARQ-9: Appointment Duration (NM) 00868

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

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


ARQ-11: Requested Start Date/Time Range (DR) 00870

Definition: This field contains the date and time that the appointment is requested to begin, in the form of a date/time range. The first component contains the earliest date and time that the appointment may be scheduled to begin. The second component contains the latest date and time that the appointment may be scheduled to begin.

The DTM (time stamp) data type allows for two components: the time stamp, and a degree of precision. If used, the degree of precision should be separated from the time stamp by a subcomponent delimiter.

If only the range start date/time has been provided, then the range end date/time is assumed to be infinity. Using this scenario is equivalent to requesting the next available slot on/after a particular date and time. If only the range end date/time has been provided, then the range start date/time is assumed to be immediate. Using this scenario is equivalent to requesting the appointment start some time between the current date and time, and the specified range end date/time. Requesting an appointment when the range start and range end date/time are the same is equivalent to requesting a specific slot on a schedule. If this field is unvalued, then the filler application will assume that the next available slot should be scheduled, using the institution's processing rules for scheduling appointments.

This field may repeat. Repetitions of this field are used to construct a list of acceptable ranges. Repetitions of this field are connected with a logical OR to construct this list. This procedure allows applications to provide multiple preferences for the scheduling of appointments. Applications should take steps to ensure that nonsensical ranges are not indicated in this field (for example, redundant ranges).

Examples:

Schedule the appointment to begin at some time between 8:00AM on Tuesday, May 17th, 1994 and 12:00PM on Friday, May 20th, 1994 local time:

...|199405170800^199405201200|...

Schedule the appointment in the next available slot on/after 6:00AM on Monday, April 25th, 1994 local time:

...|199405250600^|...

Note: The field value ...|199405250600|... is equivalent to making the above request, according to the HL7 rules for processing fields.


Schedule the appointment in the next available slot on/before 6:00AM on Monday, April 25th, 1994 local time:

...|^199405250600|...

Schedule the appointment in the next available slot:

...||...

Schedule the appointment to begin on any weekday during the two weeks beginning Monday, April 4th, 1994. In this example, the degree of precision (sub)component of the time stamp is used to indicate that the date/time ranges refer to the institution's standard operating day:

...|199404040000&D^199404080000&D~199404110000&D^199404150000&D|...

Schedule the appointment in the next available slot that does not occur during the May 1994 HL7 Working Group Meeting:

...|^199405161600~199405230800^|...

Schedule the appointment to begin on/before 4:00PM on Thursday, December 23rd, 1993, or any weekday between Monday, December 27th, and Thursday, December 30th, or on/after 8:00AM on Monday, January 3rd, 1994:

...|^199312231600~199312270000&D^199312300000&D~199401030800^|...

ARQ-12: Priority-ARQ (ST) 00871

Definition: This field contains the urgency of the request. The definition of this field is equivalent to the definition of TQ1-9 in the Order Entry chapter (Chapter 4), "Priority" component."

ARQ-13: Repeating Interval (RI) 00872

Definition: This field contains the interval between repeating appointments. The default setting indicates that the appointment should occur once, if the component is not valued. If an explicit time interval is specified for the repeat pattern, then it specifies the actual time(s) at which the appointment should be scheduled. The ARQ-11-Requested Start Date/Time Range ought to indicate the first repetition that should occur.

Note: The subcomponent delimiter defined for the Interval component of the Quantity/Timing field definition has been replaced by a component delimiter for this field.


ARQ-14: Repeating Interval Duration (ST) 00873

Definition: This field indicates how long the appointment repetitions should continue, once they have begun. The default setting indicates that the appointment should occur once. If the Interval Duration is defined as indefinitely repeating, the repetition of this appointment can only be stopped by using a discontinue event.

ARQ-15: 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.

ARQ-16: 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.

ARQ-17: 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.

ARQ-18: 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.

ARQ-19: 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.

ARQ-20: 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.

ARQ-21: 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.

ARQ-22: 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.

ARQ-23: 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.

ARQ-24: 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.

ARQ-25: 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.

ARQ-26: 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.

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.

RGS - Resource Group Segment

The RGS segment is used to identify relationships between resources identified for a scheduled event. This segment can be used, on a site specified basis, to identify groups of resources that are used together within a scheduled event, or to describe some other relationship between resources. To specify related groups of resources within a message, begin each group with an RGS segment, and then follow that RGS with one or more of the Appointment Information segments (AIG, AIL, AIS, or AIP).

If a message does not require any grouping of resources, then specify a single RGS in the message, and follow it with all of the Appointment Information segments for the scheduled event. (At least one RGS segment is required in each message – even if no grouping of resources is required – to allow parsers to properly understand the message.)

HL7 Attribute Table - RGS - Resource Group Segment
Seq# DataElement Description Must Implement Flags Cardinality Length C.LEN Vocabulary DataType
RGS
1 01203 Set ID - RGS SHALL [1..1] [1..4] SI
2

00763 Segment Action Code MAY
True:
False:
C
[1..1]
[0..1]
[1..1] ID
3 01204 Resource Group ID [0..1] CWE

RGS-1: Set ID - RGS (SI) 01203

Definition: This field contains a number that uniquely identifies the information represented by this segment in this transaction for the purposes of addition, change or deletion.

RGS-2: Segment Action Code (ID) 00763

(Definition from OMC.2 in Ch. 8)

Definition:  This field indicates whether this repetition of the segment is being added, changed or deleted.  When using dynamic update mode (See Chapter 2, Section 2.23.4.2, "Action code/unique identifier mode update definition.")  OMC-2 and OMC-3 Segment Unique Key are used to establish the "unique key" and to determine the data subject to the action. Refer to HL7 Table 0206 – Segment action code for valid values.

If the transaction uses dynamic/action code messaging, the field must be valued. 

Condition Predicate: Required if OMC-3 is valued.

(Definition from LCH.2 in Ch. 8)

Definition: This field indicates whether this repetition of the segment is being added, changed or deleted. The action code adds a validation check to indicate, from the point of view of the sending system, whether this repetition of a segment is being added, changed or deleted. This and the following field are used to implement the "unique key" mode of updating repeating segments. (See Chapter 2, section 2.10.4.2, "Action code/unique identifier mode update definition.") Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from LRL.2 in Ch. 8)

Definition: This field indicates whether this repetition of the segment is being added, changed or deleted. The action code adds a validation check to indicate, from the point of view of the sending system, whether this repetition of a segment is being added, changed or deleted. This and the following field are used to implement the "unique key" mode of updating repeating segments. (See Chapter 2, section 2.10.4.2, "Action code/unique identifier mode update definition.") Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from RGS.2 in Ch. 10)

Definition: This field contains the action to be taken when updating or modifying information in this segment from previously sent interface transactions. Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values.

This field is conditionally required. It is required for all updating or modifying trigger events.

(Definition from AIS.2 in Ch. 10)

Definition: This field contains the action to be taken when updating or modifying information in this segment from previously sent interface transactions. Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values.

This field is conditionally required. It is required for all updating or modifying trigger events.

(Definition from AIG.2 in Ch. 10)

Definition: This field contains the action to be taken when updating or modifying information in this segment from previously sent interface transactions. Refer to HL7 Table 0206 - Segment Action Code in Chapter 2, Code Tables, for valid values.

This field is conditionally required. It is required for all updating or modifying trigger events.

(Definition from AIL.2 in Ch. 10)

Definition: This field contains the action to be taken when updating or modifying information in this segment from previously sent interface transactions. Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values

This field is conditionally required. It is required for all updating or modifying trigger events.

(Definition from AIP.2 in Ch. 10)

Definition: This field contains the action to be taken when updating or modifying information in this segment from previously sent interface transactions. Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values.

This field is conditionally required. It is required for all updating or modifying trigger events.

RGS-3: Resource Group ID (CWE) 01204

Definition: This field contains an identifier code describing the group of resources following this RGS segment.

AIS - Appointment Information - Service Segment

The AIS segment contains information about various kinds of services that can be scheduled. Services included in a transaction using this segment are assumed to be controlled by a schedule on a schedule filler application. Services not controlled by a schedule are not identified on a schedule request using this segment.

HL7 Attribute Table - AIS - Appointment Information - Service Segment
Seq# DataElement Description Must Implement Flags Cardinality Length C.LEN Vocabulary DataType
AIS
1 00890 Set ID - AIS SHALL [1..1] [1..4] SI
2

00763 Segment Action Code MAY
True:
False:
C
[1..1]
[0..1]
[1..1] ID
3 00238 Universal Service Identifier SHALL [1..1] CWE
4

01202 Start Date/Time MAY
True:
False:
C
[1..1]
[0..1]
DTM
5

00891 Start Date/Time Offset MAY
True:
False:
C
[1..1]
[0..1]
NM
6

00892 Start Date/Time Offset Units MAY
True:
False:
C
[1..1]
[0..1]
CNE
7 00893 Duration [0..1] NM
8 00894 Duration Units [0..1] CNE
9

00895 Allow Substitution Code MAY
True:
False:
C
[1..1]
[0..1]
CWE
10

00889 Filler Status Code MAY
True:
False:
C
[1..1]
[0..1]
CWE
11 01474 Placer Supplemental Service Information [0..*] CWE
12 01475 Filler Supplemental Service Information [0..*] CWE

AIS-1: Set ID - AIS (SI) 00890

Definition: This field contains a number that uniquely identifies the information represented by this segment in this transaction for the purposes of addition, change or deletion.

AIS-2: Segment Action Code (ID) 00763

(Definition from OMC.2 in Ch. 8)

Definition:  This field indicates whether this repetition of the segment is being added, changed or deleted.  When using dynamic update mode (See Chapter 2, Section 2.23.4.2, "Action code/unique identifier mode update definition.")  OMC-2 and OMC-3 Segment Unique Key are used to establish the "unique key" and to determine the data subject to the action. Refer to HL7 Table 0206 – Segment action code for valid values.

If the transaction uses dynamic/action code messaging, the field must be valued. 

Condition Predicate: Required if OMC-3 is valued.

(Definition from LCH.2 in Ch. 8)

Definition: This field indicates whether this repetition of the segment is being added, changed or deleted. The action code adds a validation check to indicate, from the point of view of the sending system, whether this repetition of a segment is being added, changed or deleted. This and the following field are used to implement the "unique key" mode of updating repeating segments. (See Chapter 2, section 2.10.4.2, "Action code/unique identifier mode update definition.") Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from LRL.2 in Ch. 8)

Definition: This field indicates whether this repetition of the segment is being added, changed or deleted. The action code adds a validation check to indicate, from the point of view of the sending system, whether this repetition of a segment is being added, changed or deleted. This and the following field are used to implement the "unique key" mode of updating repeating segments. (See Chapter 2, section 2.10.4.2, "Action code/unique identifier mode update definition.") Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from RGS.2 in Ch. 10)

Definition: This field contains the action to be taken when updating or modifying information in this segment from previously sent interface transactions. Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values.

This field is conditionally required. It is required for all updating or modifying trigger events.

(Definition from AIS.2 in Ch. 10)

Definition: This field contains the action to be taken when updating or modifying information in this segment from previously sent interface transactions. Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values.

This field is conditionally required. It is required for all updating or modifying trigger events.

(Definition from AIG.2 in Ch. 10)

Definition: This field contains the action to be taken when updating or modifying information in this segment from previously sent interface transactions. Refer to HL7 Table 0206 - Segment Action Code in Chapter 2, Code Tables, for valid values.

This field is conditionally required. It is required for all updating or modifying trigger events.

(Definition from AIL.2 in Ch. 10)

Definition: This field contains the action to be taken when updating or modifying information in this segment from previously sent interface transactions. Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values

This field is conditionally required. It is required for all updating or modifying trigger events.

(Definition from AIP.2 in Ch. 10)

Definition: This field contains the action to be taken when updating or modifying information in this segment from previously sent interface transactions. Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values.

This field is conditionally required. It is required for all updating or modifying trigger events.

AIS-3: Universal Service Identifier (CWE) 00238

(Definition from OBR.4 in Ch. 4)

Definition: This field contains the identifier code for the requested observation/test/battery. The identifier can come from either a local coding system or industry standards. Examples may be LOINC (emerging as the global standard for observation identifiers), JLAC10, or SNOMED CT. Refer to Table 0612 - Universal Service Identifier in Chapter 2C for valid values.

(Definition from OBR.4 in Ch. 7)

Definition: This field contains the identifier code for the requested observation/test/battery. The identifier can come from either a local coding system or industry standards. Examples may be LOINC (emerging as the global standard for observation identifiers), JLAC10, or SNOMED CT. Refer to Table 0612 - Universal Service Identifier in Chapter 2C for valid values.

(Definition from OM7.2 in Ch. 8)

Definition: This field contains the producer's usual or preferred identification of the test or service.

(Definition from AIS.3 in Ch. 10)

Definition: This field contains an identifier code for a service to be scheduled. This field may contain a universal service identifier describing the observation/test/battery/procedure or other activity that is to be performed during the requested appointment, similar to the universal service identifier defined for the OBR segment in the Order Entry chapter (Chapter 4). This code can be based on local and/or universal codes. The use of universal codes is recommended.

(Definition from TCC.1 in Ch. 13)

Definition: This field identifies the test code that information is being transmitted about. The alternate elements represent the test code identifier that has been assigned by the manufacturer to this particular test code. Refer to Table 0787 - Universal Service Identifier in Chapter 2C for valid values.

(Definition from TCD.1 in Ch. 13)

Definition: This field identifies the test code that information is being transmitted about. Refer to Table 0789 - Universal Service Identifier in Chapter 2C for valid values.

AIS-4: Start Date/Time (DTM) 01202

(Definition from AIS.4 in Ch. 10)

Definition: This field contains the date and time this service needs for the appointment. This field allows the application to identify that the service is required for the appointment at a different time than the appointment's start date/time.

This field is conditionally required. If a value for AIS-5-Start Date/Time Offset is not provided, then a value is required for this field. To specify that there is no difference between the appointment's start date/time and the resource's start date/time either replicate the appointment's start date/time into this field, or specify an offset of zero (0) in AIS-5-Start Date/Time Offset and any valid time unit code in AIS-6-Start Date/Time Offset Units.

(Definition from AIG.8 in Ch. 10)

Definition: This field contains the date and time this service needs for the appointment. This field allows the application to identify that the service is required for the appointment at a different time than the appointment's start date/time

This field is conditionally required. If a value for AIG-9-Start Date/Time Offset is not provided, then a value is required for this field. To specify that there is no difference between the appointment's start date/time and the resource's start date/time either replicate the appointment's start date/time into this field, or specify an offset of zero (0) in AIG-9-Start Date/Time Offset and any valid time unit code in AIG-10-Start Date/Time Offset Units.

(Definition from AIL.6 in Ch. 10)

Definition: This field contains the date and time this service needs for the appointment. This field allows the application to identify that the service is required for the appointment at a different time than the appointment's start date/time

This field is conditionally required. If a value for AIL-7 Start Date/Time Offset is not provided, then a value is required for this field. To specify that there is no difference between the appointment's start date/time and the resource's start date/time either replicate the appointment's start date/time into this field, or specify an offset of zero (0) in AIL-7 Start Date/Time Offset and any valid time unit code in AIL-8-Start Date/Time Offset Units.

(Definition from AIP.6 in Ch. 10)

Definition: This field contains the date and time this service needs for the appointment. This field allows the application to identify that the service is required for the appointment at a different time than the appointment's start date/time.

This field is conditionally required. If a value for AIP-7 Start Date/Time Offset is not provided, then a value is required for this field. To specify that there is no difference between the appointment's start date/time and the resource's start date/time either replicate the appointment's start date/time into this field, or specify an offset of zero (0) in AIP-7 Start Date/Time Offset and any valid time unit code in AIP-8 Start Date/Time Offset Units.

(Definition from EQP.3 in Ch. 13)

Definition: This field is the date/time that the event started.

AIS-5: Start Date/Time Offset (NM) 00891

(Definition from AIS.5 in Ch. 10)

Definition: This field contains the offset this service needs for the appointment, expressed in units of time relative to the scheduled start date/time. This field allows the application to identify that the service is required for the appointment at a different time than the appointment's start date/time. The first component contains the offset amount. An offset of zero (0), or an unvalued field indicates that the service is required at the start date/time of the appointment.

A positive offset (an unsigned or positive number) indicates that the service is required after the appointment's start date/time. Specifying a negative offset indicates that the service is required prior to the specified start date/time of the appointment. Negative offsets are allowed, and sites should clearly define the effect of a negative offset on the appointment's start date/time.

This field is conditionally required. If a value for AIS-5-Start Date/Time Offset is not provided, then a value is required for this field. To specify that there is no difference between the appointment's start date/time and the resource's start date/time either replicate the appointment's start date/time into this field, or specify an offset of zero (0) in AIS-5-Start Date/Time Offset and any valid time unit code in AIS-6-Start Date/Time Offset Units.

(Definition from AIG.9 in Ch. 10)

Definition: This field contains the offset that this resource needs for the appointment, expressed in units of time relative to the scheduled start date/time. This field indicates to the application that the resource is required for the appointment at a different time than the appointment's start date/time. The first component indicates the offset amount. An offset of zero (0), or an unvalued field, indicates that the resource is required at the start date/time of the appointment.

A positive offset (an unsigned or positive number) indicates that the resource is required after the appointment's start date/time. Specifying a negative offset indicates that the resource is required prior to the specified start date/time of the appointment. Negative offsets are allowed, and sites should clearly define the effect of a negative offset on the appointment's start date/time.

This field is conditionally required. If a value for AIG-8-Start Date/Time is not provided, then a value is required for this field. To specify that there is no difference between the appointment's start date/time and the resource's start date/time either replicate the appointment's start date/time into this field, or specify an offset of zero (0) in AIG-9-Start Date/Time Offset and any valid time unit code in AIG10-Start Date/Time Offset Units.

(Definition from AIL.7 in Ch. 10)

Definition: This field contains the offset this resource needs for the appointment, expressed in units of time relative to the scheduled start date/time. This field indicates to the application that the resource is required for the appointment at a different time than the appointment's start date/time. The first component contains the offset amount. An offset of zero (0), or an unvalued field, indicates that the resource is required at the start date/time of the appointment.

A positive offset (an unsigned or positive number) indicates that the resource is required after the appointment's start date/time. Specifying a negative offset indicates that the resource is required prior to the specified start date/time of the appointment. Negative offsets are allowed, and sites should clearly define the effect of a negative offset on the appointment's start date/time.

This field is conditionally required. If a value for AIL-6 Start Date/Time is not provided, then a value is required for this field. To specify that there is no difference between the appointment's start date/time and the resource's start date/time either replicate the appointment's start date/time into this field, or specify an offset of zero (0) in AIL-7 Start Date/Time Offset and any valid time unit code in AIL-8 Start Date/Time Offset Units.

(Definition from AIP.7 in Ch. 10)

Definition: This field contains the offset this resource needs for the appointment, expressed in units of time relative to the scheduled start date/time. This field indicates to the application that the resource is required for the appointment at a different time than the appointment's start date/time. The first component contains the offset amount. An offset of zero (0), or an unvalued field, indicates that the resource is required at the start date/time of the appointment.

A positive offset (an unsigned or positive number) indicates that the resource is required after the appointment's start date/time. Specifying a negative offset indicates that the resource is required prior to the specified start date/time of the appointment. Negative offsets are allowed, and sites should clearly define the effect of a negative offset on the appointment's start date/time.

This field is conditionally required. If a value for AIP-6 Start Date/Time is not provided, then a value is required for this field. To specify that there is no difference between the appointment's start date/time and the resource's start date/time either replicate the appointment's start date/time into this field, or specify an offset of zero (0) in AIP-7 Start Date/Time Offset and any valid time unit code in AIP-8 Start Date/Time Offset Units.

AIS-6: Start Date/Time Offset Units (CNE) 00892

(Definition from AIS.6 in Ch. 10)

Definition: This field contains a code describing the units of time used for expressing the start date/time offset. This field should be valued according to the recommendations in Chapters 2 and 7. If this field 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.

This field is conditionally required. If a value for AIS-5-Start Date/Time Offset is provided, then a value is required for this field.

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 AIG.10 in Ch. 10)

Definition: This field contains a code describing the units of time used for expressing AIG-9-Start Date/Time Offset. This field should be valued according to the recommendations made in Chapters 2 and 7. If this field 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 ANS+ unit codes.

This field is conditionally required. If a value for AIG-9-Start Date/Time Offset is provided, then a value is required for this field.

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 AIL.8 in Ch. 10)

Definition: This field contains a code describing the units of time used for expressing the AIL-7 Start Date/Time Offset field. This field should be valued according to the recommendations made in Chapters 2 and 7. If this field 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 ANS+ unit codes.

This field is conditionally required. If a value for AIL-7 Start Date/Time Offset is provided, then a value is required for this field.

(Definition from AIP.8 in Ch. 10)

Definition: This field contains a code describing the units of time used for expressing AIP-7 Start Date/Time Offset. This field should be valued according to the recommendations made in Chapters 2 and 7. If this field 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 ANS+ unit codes.

This field is conditionally required. If a value for AIP-7 Start Date/Time Offset is provided, then a value is required for this field.

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.


AIS-7: Duration (NM) 00893

(Definition from AIS.7 in Ch. 10)

Definition: This field contains the duration for which the resource is requested/scheduled for this appointment, if different from the overall duration of the requested/scheduled appointment. This field indicates to the application that a resource is required for a different amount of time than the appointment's overall duration. An unvalued duration indicates that the resource is required from its start date/time offset (specified in the previous two fields) until the end of the appointment. If no start date/time offset is specified, then the resource is required for the full duration of the appointment.

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

(Definition from AIG.11 in Ch. 10)

Definition: This field contains the duration for which the resource is requested/scheduled for this appointment, if it is different than the overall duration of the requested/scheduled appointment. This field indicates to the application that a resource is required for a different amount of time than the appointment's overall duration. An unvalued duration indicates that the resource is required from its start date/time offset (specified in the previous two fields) until the end of the appointment. If no start date/time offset is specified, then the resource is required for the full duration of the appointment.

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

(Definition from AIL.9 in Ch. 10)

Definition: This field contains the duration for which the resource is requested/scheduled for this appointment, if it is different than the overall duration of the requested/scheduled appointment. This field indicates to the application that a resource is required for a different amount of time than the appointment's overall duration. An unvalued duration indicates that the resource is required from its start date/time offset (specified in the previous two fields) until the end of the appointment. If no start date/time offset is specified, then the resource is required for the full duration of the appointment.

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

(Definition from AIP.9 in Ch. 10)

Definition: This field contains the duration for which the resource is requested/scheduled for an appointment, if different from the overall duration of the requested/scheduled appointment. This field indicates to the application that a resource is required for a different amount of time than the appointment's overall duration. An unvalued duration indicates that the resource is required from its start date/time offset (specified in the previous two fields) until the end of the appointment. If no start date/time offset is specified, then the resource is required for the full duration of the appointment.

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

AIS-8: Duration Units (CNE) 00894

(Definition from AIS.8 in Ch. 10)

Definition: This field contains a code describing the units of time used for expressing the duration. This field should be valued according to the recommendations in Chapters 2 and 7. If this field 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 AIG.12 in Ch. 10)

Definition: This field contains a code describing the units of time used for expressing the AIG-11-Duration field. This field should be valued according to the recommendations in Chapters 2 and 7. If this field 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 ANS+ 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 AIL.10 in Ch. 10)

Definition: This field contains a code describing the units of time used associated with AIL-9 Duration. This field should be valued according to the recommendations made in Chapters 2 and 7. If this field is not valued, the ISO base unit of seconds (code "s") will be assumed. Refer to Chapter 7 for a list of ISO+ and ANS+ 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 AIP.10 in Ch. 10)

Definition: This field contains a code describing the units of time used associated with AIP-9 Duration. This field should be valued according to the recommendations made in Chapters 2 and 7. If this field 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 ANS+ 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.


AIS-9: Allow Substitution Code (CWE) 00895

(Definition from AIS.9 in Ch. 10)

Definition: This field contains a code indicating whether the identified resource can be substituted with an equivalent resource by the filler application. This field is conditionally required. It is required for all request messages. It is optional for all unsolicited transactions, and for all query messages. Refer to User-Defined Table 0279 - Allow Substitution Codes in Chapter 2C, Code Tables, for suggested codes.

(Definition from AIG.13 in Ch. 10)

Definition: This field contains a code indicating whether the identified resource can be substituted with an equivalent resource by the filler application. Refer to User-Defined Table 0279 - Allow Substitution Codes for suggested codes.

This field is conditionally required. It is required for all request messages. It is optional for all unsolicited transactions, and for all query messages.

(Definition from AIL.11 in Ch. 10)

Definition: This field contains a code indicating whether the identified location can be replaced with an equivalent substitute location by the filler application. Refer to User-Defined Table 0279 - Allow Substitution Codes in Chapter 2C, Code Tables, for suggested values.

This field is conditionally required. It is required for all request messages. It is optional for all unsolicited transactions, and for all query messages.

(Definition from AIP.11 in Ch. 10)

Definition: This field contains a code indicating whether the identified personnel resource can be replaced with an equivalent substitute personnel resource by the filler application. Refer to User-Defined Table 0279 - Allow Substitution Codes in Chapter 2C, Code Tables, for suggested values.

This field is conditionally required. It is required for all request messages. It is optional for all unsolicited transactions, and for all query messages.

AIS-10: 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.

AIS-11: Placer Supplemental Service Information (CWE) 01474

(Definition from OBR.46 in Ch. 4)

Definition: This field contains supplemental service information sent from the placer system to the filler system for the universal procedure code reported in OBR-4 Universal Service ID. This field will be used to provide ordering information detail that is not available in other specific fields in the OBR segment. Multiple supplemental service information elements may be reported. Refer to User-defined Table 0411 - Supplemental service information values in Chapter 2C, Code Tables.

This field can be used to describe details such as whether study is to be done on the right or left, for example, where the study is of the arm and the order master file does not distinguish right from left, or whether the study is to be done with or without contrast (when the order master file does not make such distinctions).

(Definition from OBR.46 in Ch. 7)

Definition: This field contains supplemental service information sent from the placer system to the filler system for the universal procedure code reported in OBR-4 Universal Service ID. This field will be used to provide ordering information detail that is not available in other specific fields in the OBR segment. Multiple supplemental service information elements may be reported. Refer to User-defined Table 0411 - Supplemental service information values in Chapter 2C, Code Tables.

This field can be used to describe details such as whether study is to be done on the right or left, for example, where the study is of the arm and the order master file does not distinguish right from left, or whether the study is to be done with or without contrast (when the order master file does not make such distinctions).

(Definition from AIS.11 in Ch. 10)

Definition: This field contains supplemental service and/or logistical information sent from the placer system to the filler system for the universal procedure code reported in field AIS-3. This field will be used to provide scheduling information detail that is not available in other, specific fields in the AIS segment. Multiple supplemental service information elements may be reported. Refer to User-defined Table 0411 – Supplemental Service Information Values in Chapter 2C, Code Tables, for valid values.

AIS-12: Filler Supplemental Service Information (CWE) 01475

(Definition from OBR.47 in Ch. 4)

Definition: This field contains supplemental service information sent from the filler system to the placer system for the procedure code reported in OBR-4 Universal Service ID. This field will be used to report ordering information detail that is not available in other specific fields in the OBR segment. Typically it will reflect the same information as was sent to the filler system in OBR-46-Placer supplemental service information unless the order was modified, in which case the filler system will report what was actually performed using this field. Multiple supplemental service information elements may be reported. Refer to User-Defined Table 0411 - Supplemental Service Information Values in Chapter 2C, Code Tables.

This field can be used to describe details such as whether study is to be done on the right or left, for example, where the study is of the arm and the order master file does not distinguish right from left, or whether the study is to be done with or without contrast (when the order master file does not make such distinctions).

(Definition from OBR.47 in Ch. 7)

Definition: This field contains supplemental service information sent from the filler system to the placer system for the procedure code reported in OBR-4 Universal Service ID. This field will be used to report ordering information detail that is not available in other specific fields in the OBR segment. Typically it will reflect the same information as was sent to the filler system in OBR-46-Placer supplemental service information unless the order was modified, in which case the filler system will report what was actually performed using this field. Multiple supplemental service information elements may be reported. Refer to User-Defined Table 0411 - Supplemental Service Information Values in Chapter 2C, Code Tables.

This field can be used to describe details such as whether study is to be done on the right or left, for example, where the study is of the arm and the order master file does not distinguish right from left, or whether the study is to be done with or without contrast (when the order master file does not make such distinctions).

(Definition from AIS.12 in Ch. 10)

Definition: This field contains supplemental service and/or logistical information sent from the filler system to the placer system for the procedure code reported in field AIS-3. This field will be used to report scheduling information details that is not available in other, specific fields in the AIS segment. Typically it will reflect the same information as was sent to the filler system in AIS-11-Placer Supplemental information unless the scheduling was modified in which case the filler system will report what was actually performed using this field. Multiple supplemental service information elements may be reported. Refer to User-defined Table 0411 - Supplemental service information values in Chapter 2C, Code Tables, for valid values..

AIG - Appointment Information - General Resource Segment

The AIG segment contains information about various kinds of resources (other than those with specifically defined segments in this chapter) that can be scheduled. Resources included in a transaction using this segment are assumed to be controlled by a schedule on a schedule filler application. Resources not controlled by a schedule are not identified on a schedule request using this segment. Resources described by this segment are general kinds of resources, such as equipment, that are identified with a simple identification code.

HL7 Attribute Table - AIG - Appointment Information - General Resource Segment
Seq# DataElement Description Must Implement Flags Cardinality Length C.LEN Vocabulary DataType
AIG
1 00896 Set ID - AIG SHALL [1..1] [1..4] SI
2

00763 Segment Action Code MAY
True:
False:
C
[1..1]
[0..1]
[1..1] ID
3

00897 Resource ID MAY
True:
False:
C
[1..1]
[0..1]
CWE
4 00898 Resource Type SHALL [1..1] CWE
5 00899 Resource Group [0..*] CWE
6 00900 Resource Quantity # [0..1] 5 NM
7 00901 Resource Quantity Units [0..1] CNE
8

01202 Start Date/Time MAY
True:
False:
C
[1..1]
[0..1]
DTM
9

00891 Start Date/Time Offset MAY
True:
False:
C
[1..1]
[0..1]
NM
10

00892 Start Date/Time Offset Units MAY
True:
False:
C
[1..1]
[0..1]
CNE
11 00893 Duration [0..1] NM
12 00894 Duration Units [0..1] CNE
13

00895 Allow Substitution Code MAY
True:
False:
C
[1..1]
[0..1]
CWE
14 00889 Filler Status Code MAY
True:
False:
C
[1..1]
[0..1]
CWE

AIG-1: Set ID - AIG (SI) 00896

Definition: This field contains a number that uniquely identifies the information represented by this segment in this transaction for the purposes of addition, change or deletion.

AIG-2: Segment Action Code (ID) 00763

(Definition from OMC.2 in Ch. 8)

Definition:  This field indicates whether this repetition of the segment is being added, changed or deleted.  When using dynamic update mode (See Chapter 2, Section 2.23.4.2, "Action code/unique identifier mode update definition.")  OMC-2 and OMC-3 Segment Unique Key are used to establish the "unique key" and to determine the data subject to the action. Refer to HL7 Table 0206 – Segment action code for valid values.

If the transaction uses dynamic/action code messaging, the field must be valued. 

Condition Predicate: Required if OMC-3 is valued.

(Definition from LCH.2 in Ch. 8)

Definition: This field indicates whether this repetition of the segment is being added, changed or deleted. The action code adds a validation check to indicate, from the point of view of the sending system, whether this repetition of a segment is being added, changed or deleted. This and the following field are used to implement the "unique key" mode of updating repeating segments. (See Chapter 2, section 2.10.4.2, "Action code/unique identifier mode update definition.") Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from LRL.2 in Ch. 8)

Definition: This field indicates whether this repetition of the segment is being added, changed or deleted. The action code adds a validation check to indicate, from the point of view of the sending system, whether this repetition of a segment is being added, changed or deleted. This and the following field are used to implement the "unique key" mode of updating repeating segments. (See Chapter 2, section 2.10.4.2, "Action code/unique identifier mode update definition.") Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from RGS.2 in Ch. 10)

Definition: This field contains the action to be taken when updating or modifying information in this segment from previously sent interface transactions. Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values.

This field is conditionally required. It is required for all updating or modifying trigger events.

(Definition from AIS.2 in Ch. 10)

Definition: This field contains the action to be taken when updating or modifying information in this segment from previously sent interface transactions. Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values.

This field is conditionally required. It is required for all updating or modifying trigger events.

(Definition from AIG.2 in Ch. 10)

Definition: This field contains the action to be taken when updating or modifying information in this segment from previously sent interface transactions. Refer to HL7 Table 0206 - Segment Action Code in Chapter 2, Code Tables, for valid values.

This field is conditionally required. It is required for all updating or modifying trigger events.

(Definition from AIL.2 in Ch. 10)

Definition: This field contains the action to be taken when updating or modifying information in this segment from previously sent interface transactions. Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values

This field is conditionally required. It is required for all updating or modifying trigger events.

(Definition from AIP.2 in Ch. 10)

Definition: This field contains the action to be taken when updating or modifying information in this segment from previously sent interface transactions. Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values.

This field is conditionally required. It is required for all updating or modifying trigger events.

AIG-3: Resource ID (CWE) 00897

Definition: This field contains the ID number and name of the resource being requested or scheduled for an appointment. This field is used to identify a specific resource being requested, or a specific resource that has been scheduled for an appointment. If the specific resource is not known but the type of resource is, AIG-4 Resource Type is used to identify the type of resource required or scheduled.

At a minimum, the ID number component should be supplied to identify either the specific resource being requested or the specific resource that has been scheduled. For inter-enterprise communications, for which a shared ID number may not be available, the minimum components required to uniquely identify a resource may be defined by site-specific negotiations.

This field is conditionally required for this segment. In new schedule request messages, it is required if the request asks that a specific resource be scheduled. For all other request messages, the specific resource should be identified if the information is available (either because a specific resource was initially requested, or because the filler application returned the ID of the specific resource that has been scheduled).

This field is required for all unsolicited transactions from the filler application.

This field is optional for all query transactions.

AIG-4: Resource Type (CWE) 00898

Definition: This field identifies the role of the resource requested/scheduled for this appointment. For requests, if a specific resource is not identified in AIG-3-Resource ID, then this field identifies the type of resource that should be scheduled by the filler application. At a minimum, the type of the identifier component should be valued.

AIG-5: Resource Group (CWE) 00899

(Definition from AIG.5 in Ch. 10)

Definition: This field identifies the requested resource as a member of the indicated group. If, in a Schedule Request Message (SRM), no specific resource is requested, but a resource type is requested, this field can be used to further qualify the type of resource being requested.

(Definition from AIP.5 in Ch. 10)

Definition: This field identifies the requested resource as a member of the indicated group. If, in a Schedule Request Message (SRM), no specific resource is requested, but an AIP-4 Resource Type is requested, the AIP-5 Resource Group field can be used to further qualify the type of resource being requested.

AIG-6: Resource Quantity (NM) 00900

Definition: This field contains the quantity of the specified resource or resource type identified in either or both of the preceding two fields. If it is not valued, this field defaults to a value of one (1).

AIG-7: Resource Quantity Units (CNE) 00901

Definition: This field contains the units of the resource requested, whose quantity is given in the preceding field. This field should be valued according to the recommendations in Chapters 2 and 7. If this field is not valued, the unit of each (code "ea") will be assumed. Refer to Chapter 7, Figures 7-6 through 7-9, for a list of ISO+ and ANS+ 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.


AIG-8: Start Date/Time (DTM) 01202

(Definition from AIS.4 in Ch. 10)

Definition: This field contains the date and time this service needs for the appointment. This field allows the application to identify that the service is required for the appointment at a different time than the appointment's start date/time.

This field is conditionally required. If a value for AIS-5-Start Date/Time Offset is not provided, then a value is required for this field. To specify that there is no difference between the appointment's start date/time and the resource's start date/time either replicate the appointment's start date/time into this field, or specify an offset of zero (0) in AIS-5-Start Date/Time Offset and any valid time unit code in AIS-6-Start Date/Time Offset Units.

(Definition from AIG.8 in Ch. 10)

Definition: This field contains the date and time this service needs for the appointment. This field allows the application to identify that the service is required for the appointment at a different time than the appointment's start date/time

This field is conditionally required. If a value for AIG-9-Start Date/Time Offset is not provided, then a value is required for this field. To specify that there is no difference between the appointment's start date/time and the resource's start date/time either replicate the appointment's start date/time into this field, or specify an offset of zero (0) in AIG-9-Start Date/Time Offset and any valid time unit code in AIG-10-Start Date/Time Offset Units.

(Definition from AIL.6 in Ch. 10)

Definition: This field contains the date and time this service needs for the appointment. This field allows the application to identify that the service is required for the appointment at a different time than the appointment's start date/time

This field is conditionally required. If a value for AIL-7 Start Date/Time Offset is not provided, then a value is required for this field. To specify that there is no difference between the appointment's start date/time and the resource's start date/time either replicate the appointment's start date/time into this field, or specify an offset of zero (0) in AIL-7 Start Date/Time Offset and any valid time unit code in AIL-8-Start Date/Time Offset Units.

(Definition from AIP.6 in Ch. 10)

Definition: This field contains the date and time this service needs for the appointment. This field allows the application to identify that the service is required for the appointment at a different time than the appointment's start date/time.

This field is conditionally required. If a value for AIP-7 Start Date/Time Offset is not provided, then a value is required for this field. To specify that there is no difference between the appointment's start date/time and the resource's start date/time either replicate the appointment's start date/time into this field, or specify an offset of zero (0) in AIP-7 Start Date/Time Offset and any valid time unit code in AIP-8 Start Date/Time Offset Units.

(Definition from EQP.3 in Ch. 13)

Definition: This field is the date/time that the event started.

AIG-9: Start Date/Time Offset (NM) 00891

(Definition from AIS.5 in Ch. 10)

Definition: This field contains the offset this service needs for the appointment, expressed in units of time relative to the scheduled start date/time. This field allows the application to identify that the service is required for the appointment at a different time than the appointment's start date/time. The first component contains the offset amount. An offset of zero (0), or an unvalued field indicates that the service is required at the start date/time of the appointment.

A positive offset (an unsigned or positive number) indicates that the service is required after the appointment's start date/time. Specifying a negative offset indicates that the service is required prior to the specified start date/time of the appointment. Negative offsets are allowed, and sites should clearly define the effect of a negative offset on the appointment's start date/time.

This field is conditionally required. If a value for AIS-5-Start Date/Time Offset is not provided, then a value is required for this field. To specify that there is no difference between the appointment's start date/time and the resource's start date/time either replicate the appointment's start date/time into this field, or specify an offset of zero (0) in AIS-5-Start Date/Time Offset and any valid time unit code in AIS-6-Start Date/Time Offset Units.

(Definition from AIG.9 in Ch. 10)

Definition: This field contains the offset that this resource needs for the appointment, expressed in units of time relative to the scheduled start date/time. This field indicates to the application that the resource is required for the appointment at a different time than the appointment's start date/time. The first component indicates the offset amount. An offset of zero (0), or an unvalued field, indicates that the resource is required at the start date/time of the appointment.

A positive offset (an unsigned or positive number) indicates that the resource is required after the appointment's start date/time. Specifying a negative offset indicates that the resource is required prior to the specified start date/time of the appointment. Negative offsets are allowed, and sites should clearly define the effect of a negative offset on the appointment's start date/time.

This field is conditionally required. If a value for AIG-8-Start Date/Time is not provided, then a value is required for this field. To specify that there is no difference between the appointment's start date/time and the resource's start date/time either replicate the appointment's start date/time into this field, or specify an offset of zero (0) in AIG-9-Start Date/Time Offset and any valid time unit code in AIG10-Start Date/Time Offset Units.

(Definition from AIL.7 in Ch. 10)

Definition: This field contains the offset this resource needs for the appointment, expressed in units of time relative to the scheduled start date/time. This field indicates to the application that the resource is required for the appointment at a different time than the appointment's start date/time. The first component contains the offset amount. An offset of zero (0), or an unvalued field, indicates that the resource is required at the start date/time of the appointment.

A positive offset (an unsigned or positive number) indicates that the resource is required after the appointment's start date/time. Specifying a negative offset indicates that the resource is required prior to the specified start date/time of the appointment. Negative offsets are allowed, and sites should clearly define the effect of a negative offset on the appointment's start date/time.

This field is conditionally required. If a value for AIL-6 Start Date/Time is not provided, then a value is required for this field. To specify that there is no difference between the appointment's start date/time and the resource's start date/time either replicate the appointment's start date/time into this field, or specify an offset of zero (0) in AIL-7 Start Date/Time Offset and any valid time unit code in AIL-8 Start Date/Time Offset Units.

(Definition from AIP.7 in Ch. 10)

Definition: This field contains the offset this resource needs for the appointment, expressed in units of time relative to the scheduled start date/time. This field indicates to the application that the resource is required for the appointment at a different time than the appointment's start date/time. The first component contains the offset amount. An offset of zero (0), or an unvalued field, indicates that the resource is required at the start date/time of the appointment.

A positive offset (an unsigned or positive number) indicates that the resource is required after the appointment's start date/time. Specifying a negative offset indicates that the resource is required prior to the specified start date/time of the appointment. Negative offsets are allowed, and sites should clearly define the effect of a negative offset on the appointment's start date/time.

This field is conditionally required. If a value for AIP-6 Start Date/Time is not provided, then a value is required for this field. To specify that there is no difference between the appointment's start date/time and the resource's start date/time either replicate the appointment's start date/time into this field, or specify an offset of zero (0) in AIP-7 Start Date/Time Offset and any valid time unit code in AIP-8 Start Date/Time Offset Units.

AIG-10: Start Date/Time Offset Units (CNE) 00892

(Definition from AIS.6 in Ch. 10)

Definition: This field contains a code describing the units of time used for expressing the start date/time offset. This field should be valued according to the recommendations in Chapters 2 and 7. If this field 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.

This field is conditionally required. If a value for AIS-5-Start Date/Time Offset is provided, then a value is required for this field.

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 AIG.10 in Ch. 10)

Definition: This field contains a code describing the units of time used for expressing AIG-9-Start Date/Time Offset. This field should be valued according to the recommendations made in Chapters 2 and 7. If this field 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 ANS+ unit codes.

This field is conditionally required. If a value for AIG-9-Start Date/Time Offset is provided, then a value is required for this field.

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 AIL.8 in Ch. 10)

Definition: This field contains a code describing the units of time used for expressing the AIL-7 Start Date/Time Offset field. This field should be valued according to the recommendations made in Chapters 2 and 7. If this field 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 ANS+ unit codes.

This field is conditionally required. If a value for AIL-7 Start Date/Time Offset is provided, then a value is required for this field.

(Definition from AIP.8 in Ch. 10)

Definition: This field contains a code describing the units of time used for expressing AIP-7 Start Date/Time Offset. This field should be valued according to the recommendations made in Chapters 2 and 7. If this field 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 ANS+ unit codes.

This field is conditionally required. If a value for AIP-7 Start Date/Time Offset is provided, then a value is required for this field.

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.


AIG-11: Duration (NM) 00893

(Definition from AIS.7 in Ch. 10)

Definition: This field contains the duration for which the resource is requested/scheduled for this appointment, if different from the overall duration of the requested/scheduled appointment. This field indicates to the application that a resource is required for a different amount of time than the appointment's overall duration. An unvalued duration indicates that the resource is required from its start date/time offset (specified in the previous two fields) until the end of the appointment. If no start date/time offset is specified, then the resource is required for the full duration of the appointment.

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

(Definition from AIG.11 in Ch. 10)

Definition: This field contains the duration for which the resource is requested/scheduled for this appointment, if it is different than the overall duration of the requested/scheduled appointment. This field indicates to the application that a resource is required for a different amount of time than the appointment's overall duration. An unvalued duration indicates that the resource is required from its start date/time offset (specified in the previous two fields) until the end of the appointment. If no start date/time offset is specified, then the resource is required for the full duration of the appointment.

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

(Definition from AIL.9 in Ch. 10)

Definition: This field contains the duration for which the resource is requested/scheduled for this appointment, if it is different than the overall duration of the requested/scheduled appointment. This field indicates to the application that a resource is required for a different amount of time than the appointment's overall duration. An unvalued duration indicates that the resource is required from its start date/time offset (specified in the previous two fields) until the end of the appointment. If no start date/time offset is specified, then the resource is required for the full duration of the appointment.

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

(Definition from AIP.9 in Ch. 10)

Definition: This field contains the duration for which the resource is requested/scheduled for an appointment, if different from the overall duration of the requested/scheduled appointment. This field indicates to the application that a resource is required for a different amount of time than the appointment's overall duration. An unvalued duration indicates that the resource is required from its start date/time offset (specified in the previous two fields) until the end of the appointment. If no start date/time offset is specified, then the resource is required for the full duration of the appointment.

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

AIG-12: Duration Units (CNE) 00894

(Definition from AIS.8 in Ch. 10)

Definition: This field contains a code describing the units of time used for expressing the duration. This field should be valued according to the recommendations in Chapters 2 and 7. If this field 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 AIG.12 in Ch. 10)

Definition: This field contains a code describing the units of time used for expressing the AIG-11-Duration field. This field should be valued according to the recommendations in Chapters 2 and 7. If this field 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 ANS+ 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 AIL.10 in Ch. 10)

Definition: This field contains a code describing the units of time used associated with AIL-9 Duration. This field should be valued according to the recommendations made in Chapters 2 and 7. If this field is not valued, the ISO base unit of seconds (code "s") will be assumed. Refer to Chapter 7 for a list of ISO+ and ANS+ 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 AIP.10 in Ch. 10)

Definition: This field contains a code describing the units of time used associated with AIP-9 Duration. This field should be valued according to the recommendations made in Chapters 2 and 7. If this field 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 ANS+ 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.


AIG-13: Allow Substitution Code (CWE) 00895

(Definition from AIS.9 in Ch. 10)

Definition: This field contains a code indicating whether the identified resource can be substituted with an equivalent resource by the filler application. This field is conditionally required. It is required for all request messages. It is optional for all unsolicited transactions, and for all query messages. Refer to User-Defined Table 0279 - Allow Substitution Codes in Chapter 2C, Code Tables, for suggested codes.

(Definition from AIG.13 in Ch. 10)

Definition: This field contains a code indicating whether the identified resource can be substituted with an equivalent resource by the filler application. Refer to User-Defined Table 0279 - Allow Substitution Codes for suggested codes.

This field is conditionally required. It is required for all request messages. It is optional for all unsolicited transactions, and for all query messages.

(Definition from AIL.11 in Ch. 10)

Definition: This field contains a code indicating whether the identified location can be replaced with an equivalent substitute location by the filler application. Refer to User-Defined Table 0279 - Allow Substitution Codes in Chapter 2C, Code Tables, for suggested values.

This field is conditionally required. It is required for all request messages. It is optional for all unsolicited transactions, and for all query messages.

(Definition from AIP.11 in Ch. 10)

Definition: This field contains a code indicating whether the identified personnel resource can be replaced with an equivalent substitute personnel resource by the filler application. Refer to User-Defined Table 0279 - Allow Substitution Codes in Chapter 2C, Code Tables, for suggested values.

This field is conditionally required. It is required for all request messages. It is optional for all unsolicited transactions, and for all query messages.

AIG-14: 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.

AIL - Appointment Information - Location Resource Segment

The AIL segment contains information about location resources (meeting rooms, operating rooms, examination rooms, or other locations) that can be scheduled. Resources included in a transaction using this segment are assumed to be controlled by a schedule on a schedule filler application. Resources not controlled by a schedule are not identified on a schedule request using this segment. Location resources are identified with this specific segment because of the specific encoding of locations used by the HL7 specification.

HL7 Attribute Table - AIL - Appointment Information - Location Resource Segment
Seq# DataElement Description Must Implement Flags Cardinality Length C.LEN Vocabulary DataType
AIL
1 00902 Set ID - AIL SHALL [1..1] [1..4] SI
2

00763 Segment Action Code MAY
True:
False:
C
[1..1]
[0..1]
[1..1] ID
3

00903 Location Resource ID MAY
True:
False:
C
[1..1]
[0..1]
PL
4

00904 Location Type - AIL MAY
True:
False:
C
[1..1]
[0..1]
CWE
5 00905 Location Group [0..1] CWE
6

01202 Start Date/Time MAY
True:
False:
C
[1..1]
[0..1]
DTM
7

00891 Start Date/Time Offset MAY
True:
False:
C
[1..1]
[0..1]
NM
8

00892 Start Date/Time Offset Units MAY
True:
False:
C
[1..1]
[0..1]
CNE
9 00893 Duration [0..1] NM
10 00894 Duration Units [0..1] CNE
11

00895 Allow Substitution Code MAY
True:
False:
C
[1..1]
[0..1]
CWE
12 00889 Filler Status Code MAY
True:
False:
C
[1..1]
[0..1]
CWE

AIL-1: Set ID - AIL (SI) 00902

Definition: This field contains a number that uniquely identifies the information represented by this segment in this transaction for the purposes of addition, change or deletion.

AIL-2: Segment Action Code (ID) 00763

(Definition from OMC.2 in Ch. 8)

Definition:  This field indicates whether this repetition of the segment is being added, changed or deleted.  When using dynamic update mode (See Chapter 2, Section 2.23.4.2, "Action code/unique identifier mode update definition.")  OMC-2 and OMC-3 Segment Unique Key are used to establish the "unique key" and to determine the data subject to the action. Refer to HL7 Table 0206 – Segment action code for valid values.

If the transaction uses dynamic/action code messaging, the field must be valued. 

Condition Predicate: Required if OMC-3 is valued.

(Definition from LCH.2 in Ch. 8)

Definition: This field indicates whether this repetition of the segment is being added, changed or deleted. The action code adds a validation check to indicate, from the point of view of the sending system, whether this repetition of a segment is being added, changed or deleted. This and the following field are used to implement the "unique key" mode of updating repeating segments. (See Chapter 2, section 2.10.4.2, "Action code/unique identifier mode update definition.") Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from LRL.2 in Ch. 8)

Definition: This field indicates whether this repetition of the segment is being added, changed or deleted. The action code adds a validation check to indicate, from the point of view of the sending system, whether this repetition of a segment is being added, changed or deleted. This and the following field are used to implement the "unique key" mode of updating repeating segments. (See Chapter 2, section 2.10.4.2, "Action code/unique identifier mode update definition.") Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from RGS.2 in Ch. 10)

Definition: This field contains the action to be taken when updating or modifying information in this segment from previously sent interface transactions. Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values.

This field is conditionally required. It is required for all updating or modifying trigger events.

(Definition from AIS.2 in Ch. 10)

Definition: This field contains the action to be taken when updating or modifying information in this segment from previously sent interface transactions. Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values.

This field is conditionally required. It is required for all updating or modifying trigger events.

(Definition from AIG.2 in Ch. 10)

Definition: This field contains the action to be taken when updating or modifying information in this segment from previously sent interface transactions. Refer to HL7 Table 0206 - Segment Action Code in Chapter 2, Code Tables, for valid values.

This field is conditionally required. It is required for all updating or modifying trigger events.

(Definition from AIL.2 in Ch. 10)

Definition: This field contains the action to be taken when updating or modifying information in this segment from previously sent interface transactions. Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values

This field is conditionally required. It is required for all updating or modifying trigger events.

(Definition from AIP.2 in Ch. 10)

Definition: This field contains the action to be taken when updating or modifying information in this segment from previously sent interface transactions. Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values.

This field is conditionally required. It is required for all updating or modifying trigger events.

AIL-3: Location Resource ID (PL) 00903

Definition: This field contains a coded identification of the location being requested or scheduled for an appointment. This field is used to identify a specific location being requested, or a specific location that has been scheduled for an appointment. If the specific location is not known but the type of location is, AIL-4-Location Type-AIL is used to identify the type of location required or scheduled. This field is conditionally required for this segment. In new schedule request messages, it is required if the request asks that a specific location be scheduled. For all other request messages, the specific location should be identified if the information is available (either because a specific location was initially requested, or because the filler application returned the coded identification of the specific location that has been scheduled).

This field is repeating in order to accommodate both local and enterprise-wide identifiers.

This field is required for all unsolicited transactions from the filler application. It is optional for all query transactions.

AIL-4: Location Type - AIL (CWE) 00904

Definition: This field identifies the type of the location requested/scheduled for this appointment. For all messages, this field is conditionally required if a specific location is not identified in AIL-3-Location resource ID. Refer to HL7 Table 0305 – Person Location Type in Chapter 2C, Code Tables, for suggested values.

AIL-5: Location Group (CWE) 00905

Definition: This field identifies the requested resource as a member of the indicated group. If, in a Schedule Request Message (SRM), no specific location is requested, but a location type is requested, AIL-5 Location Group can be used to further qualify the type of resource being requested.

AIL-6: Start Date/Time (DTM) 01202

(Definition from AIS.4 in Ch. 10)

Definition: This field contains the date and time this service needs for the appointment. This field allows the application to identify that the service is required for the appointment at a different time than the appointment's start date/time.

This field is conditionally required. If a value for AIS-5-Start Date/Time Offset is not provided, then a value is required for this field. To specify that there is no difference between the appointment's start date/time and the resource's start date/time either replicate the appointment's start date/time into this field, or specify an offset of zero (0) in AIS-5-Start Date/Time Offset and any valid time unit code in AIS-6-Start Date/Time Offset Units.

(Definition from AIG.8 in Ch. 10)

Definition: This field contains the date and time this service needs for the appointment. This field allows the application to identify that the service is required for the appointment at a different time than the appointment's start date/time

This field is conditionally required. If a value for AIG-9-Start Date/Time Offset is not provided, then a value is required for this field. To specify that there is no difference between the appointment's start date/time and the resource's start date/time either replicate the appointment's start date/time into this field, or specify an offset of zero (0) in AIG-9-Start Date/Time Offset and any valid time unit code in AIG-10-Start Date/Time Offset Units.

(Definition from AIL.6 in Ch. 10)

Definition: This field contains the date and time this service needs for the appointment. This field allows the application to identify that the service is required for the appointment at a different time than the appointment's start date/time

This field is conditionally required. If a value for AIL-7 Start Date/Time Offset is not provided, then a value is required for this field. To specify that there is no difference between the appointment's start date/time and the resource's start date/time either replicate the appointment's start date/time into this field, or specify an offset of zero (0) in AIL-7 Start Date/Time Offset and any valid time unit code in AIL-8-Start Date/Time Offset Units.

(Definition from AIP.6 in Ch. 10)

Definition: This field contains the date and time this service needs for the appointment. This field allows the application to identify that the service is required for the appointment at a different time than the appointment's start date/time.

This field is conditionally required. If a value for AIP-7 Start Date/Time Offset is not provided, then a value is required for this field. To specify that there is no difference between the appointment's start date/time and the resource's start date/time either replicate the appointment's start date/time into this field, or specify an offset of zero (0) in AIP-7 Start Date/Time Offset and any valid time unit code in AIP-8 Start Date/Time Offset Units.

(Definition from EQP.3 in Ch. 13)

Definition: This field is the date/time that the event started.

AIL-7: Start Date/Time Offset (NM) 00891

(Definition from AIS.5 in Ch. 10)

Definition: This field contains the offset this service needs for the appointment, expressed in units of time relative to the scheduled start date/time. This field allows the application to identify that the service is required for the appointment at a different time than the appointment's start date/time. The first component contains the offset amount. An offset of zero (0), or an unvalued field indicates that the service is required at the start date/time of the appointment.

A positive offset (an unsigned or positive number) indicates that the service is required after the appointment's start date/time. Specifying a negative offset indicates that the service is required prior to the specified start date/time of the appointment. Negative offsets are allowed, and sites should clearly define the effect of a negative offset on the appointment's start date/time.

This field is conditionally required. If a value for AIS-5-Start Date/Time Offset is not provided, then a value is required for this field. To specify that there is no difference between the appointment's start date/time and the resource's start date/time either replicate the appointment's start date/time into this field, or specify an offset of zero (0) in AIS-5-Start Date/Time Offset and any valid time unit code in AIS-6-Start Date/Time Offset Units.

(Definition from AIG.9 in Ch. 10)

Definition: This field contains the offset that this resource needs for the appointment, expressed in units of time relative to the scheduled start date/time. This field indicates to the application that the resource is required for the appointment at a different time than the appointment's start date/time. The first component indicates the offset amount. An offset of zero (0), or an unvalued field, indicates that the resource is required at the start date/time of the appointment.

A positive offset (an unsigned or positive number) indicates that the resource is required after the appointment's start date/time. Specifying a negative offset indicates that the resource is required prior to the specified start date/time of the appointment. Negative offsets are allowed, and sites should clearly define the effect of a negative offset on the appointment's start date/time.

This field is conditionally required. If a value for AIG-8-Start Date/Time is not provided, then a value is required for this field. To specify that there is no difference between the appointment's start date/time and the resource's start date/time either replicate the appointment's start date/time into this field, or specify an offset of zero (0) in AIG-9-Start Date/Time Offset and any valid time unit code in AIG10-Start Date/Time Offset Units.

(Definition from AIL.7 in Ch. 10)

Definition: This field contains the offset this resource needs for the appointment, expressed in units of time relative to the scheduled start date/time. This field indicates to the application that the resource is required for the appointment at a different time than the appointment's start date/time. The first component contains the offset amount. An offset of zero (0), or an unvalued field, indicates that the resource is required at the start date/time of the appointment.

A positive offset (an unsigned or positive number) indicates that the resource is required after the appointment's start date/time. Specifying a negative offset indicates that the resource is required prior to the specified start date/time of the appointment. Negative offsets are allowed, and sites should clearly define the effect of a negative offset on the appointment's start date/time.

This field is conditionally required. If a value for AIL-6 Start Date/Time is not provided, then a value is required for this field. To specify that there is no difference between the appointment's start date/time and the resource's start date/time either replicate the appointment's start date/time into this field, or specify an offset of zero (0) in AIL-7 Start Date/Time Offset and any valid time unit code in AIL-8 Start Date/Time Offset Units.

(Definition from AIP.7 in Ch. 10)

Definition: This field contains the offset this resource needs for the appointment, expressed in units of time relative to the scheduled start date/time. This field indicates to the application that the resource is required for the appointment at a different time than the appointment's start date/time. The first component contains the offset amount. An offset of zero (0), or an unvalued field, indicates that the resource is required at the start date/time of the appointment.

A positive offset (an unsigned or positive number) indicates that the resource is required after the appointment's start date/time. Specifying a negative offset indicates that the resource is required prior to the specified start date/time of the appointment. Negative offsets are allowed, and sites should clearly define the effect of a negative offset on the appointment's start date/time.

This field is conditionally required. If a value for AIP-6 Start Date/Time is not provided, then a value is required for this field. To specify that there is no difference between the appointment's start date/time and the resource's start date/time either replicate the appointment's start date/time into this field, or specify an offset of zero (0) in AIP-7 Start Date/Time Offset and any valid time unit code in AIP-8 Start Date/Time Offset Units.

AIL-8: Start Date/Time Offset Units (CNE) 00892

(Definition from AIS.6 in Ch. 10)

Definition: This field contains a code describing the units of time used for expressing the start date/time offset. This field should be valued according to the recommendations in Chapters 2 and 7. If this field 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.

This field is conditionally required. If a value for AIS-5-Start Date/Time Offset is provided, then a value is required for this field.

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 AIG.10 in Ch. 10)

Definition: This field contains a code describing the units of time used for expressing AIG-9-Start Date/Time Offset. This field should be valued according to the recommendations made in Chapters 2 and 7. If this field 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 ANS+ unit codes.

This field is conditionally required. If a value for AIG-9-Start Date/Time Offset is provided, then a value is required for this field.

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 AIL.8 in Ch. 10)

Definition: This field contains a code describing the units of time used for expressing the AIL-7 Start Date/Time Offset field. This field should be valued according to the recommendations made in Chapters 2 and 7. If this field 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 ANS+ unit codes.

This field is conditionally required. If a value for AIL-7 Start Date/Time Offset is provided, then a value is required for this field.

(Definition from AIP.8 in Ch. 10)

Definition: This field contains a code describing the units of time used for expressing AIP-7 Start Date/Time Offset. This field should be valued according to the recommendations made in Chapters 2 and 7. If this field 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 ANS+ unit codes.

This field is conditionally required. If a value for AIP-7 Start Date/Time Offset is provided, then a value is required for this field.

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.


AIL-9: Duration (NM) 00893

(Definition from AIS.7 in Ch. 10)

Definition: This field contains the duration for which the resource is requested/scheduled for this appointment, if different from the overall duration of the requested/scheduled appointment. This field indicates to the application that a resource is required for a different amount of time than the appointment's overall duration. An unvalued duration indicates that the resource is required from its start date/time offset (specified in the previous two fields) until the end of the appointment. If no start date/time offset is specified, then the resource is required for the full duration of the appointment.

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

(Definition from AIG.11 in Ch. 10)

Definition: This field contains the duration for which the resource is requested/scheduled for this appointment, if it is different than the overall duration of the requested/scheduled appointment. This field indicates to the application that a resource is required for a different amount of time than the appointment's overall duration. An unvalued duration indicates that the resource is required from its start date/time offset (specified in the previous two fields) until the end of the appointment. If no start date/time offset is specified, then the resource is required for the full duration of the appointment.

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

(Definition from AIL.9 in Ch. 10)

Definition: This field contains the duration for which the resource is requested/scheduled for this appointment, if it is different than the overall duration of the requested/scheduled appointment. This field indicates to the application that a resource is required for a different amount of time than the appointment's overall duration. An unvalued duration indicates that the resource is required from its start date/time offset (specified in the previous two fields) until the end of the appointment. If no start date/time offset is specified, then the resource is required for the full duration of the appointment.

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

(Definition from AIP.9 in Ch. 10)

Definition: This field contains the duration for which the resource is requested/scheduled for an appointment, if different from the overall duration of the requested/scheduled appointment. This field indicates to the application that a resource is required for a different amount of time than the appointment's overall duration. An unvalued duration indicates that the resource is required from its start date/time offset (specified in the previous two fields) until the end of the appointment. If no start date/time offset is specified, then the resource is required for the full duration of the appointment.

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

AIL-10: Duration Units (CNE) 00894

(Definition from AIS.8 in Ch. 10)

Definition: This field contains a code describing the units of time used for expressing the duration. This field should be valued according to the recommendations in Chapters 2 and 7. If this field 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 AIG.12 in Ch. 10)

Definition: This field contains a code describing the units of time used for expressing the AIG-11-Duration field. This field should be valued according to the recommendations in Chapters 2 and 7. If this field 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 ANS+ 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 AIL.10 in Ch. 10)

Definition: This field contains a code describing the units of time used associated with AIL-9 Duration. This field should be valued according to the recommendations made in Chapters 2 and 7. If this field is not valued, the ISO base unit of seconds (code "s") will be assumed. Refer to Chapter 7 for a list of ISO+ and ANS+ 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 AIP.10 in Ch. 10)

Definition: This field contains a code describing the units of time used associated with AIP-9 Duration. This field should be valued according to the recommendations made in Chapters 2 and 7. If this field 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 ANS+ 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.


AIL-11: Allow Substitution Code (CWE) 00895

(Definition from AIS.9 in Ch. 10)

Definition: This field contains a code indicating whether the identified resource can be substituted with an equivalent resource by the filler application. This field is conditionally required. It is required for all request messages. It is optional for all unsolicited transactions, and for all query messages. Refer to User-Defined Table 0279 - Allow Substitution Codes in Chapter 2C, Code Tables, for suggested codes.

(Definition from AIG.13 in Ch. 10)

Definition: This field contains a code indicating whether the identified resource can be substituted with an equivalent resource by the filler application. Refer to User-Defined Table 0279 - Allow Substitution Codes for suggested codes.

This field is conditionally required. It is required for all request messages. It is optional for all unsolicited transactions, and for all query messages.

(Definition from AIL.11 in Ch. 10)

Definition: This field contains a code indicating whether the identified location can be replaced with an equivalent substitute location by the filler application. Refer to User-Defined Table 0279 - Allow Substitution Codes in Chapter 2C, Code Tables, for suggested values.

This field is conditionally required. It is required for all request messages. It is optional for all unsolicited transactions, and for all query messages.

(Definition from AIP.11 in Ch. 10)

Definition: This field contains a code indicating whether the identified personnel resource can be replaced with an equivalent substitute personnel resource by the filler application. Refer to User-Defined Table 0279 - Allow Substitution Codes in Chapter 2C, Code Tables, for suggested values.

This field is conditionally required. It is required for all request messages. It is optional for all unsolicited transactions, and for all query messages.

AIL-12: 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.

AIP - Appointment Information - Personnel Resource Segment

The AIP segment contains information about the personnel types that can be scheduled. Personnel included in a transaction using this segment are assumed to be controlled by a schedule on a schedule filler application. Personnel not controlled by a schedule are not identified on a schedule request using this segment. The kinds of personnel described on this segment include any healthcare provider in the institution controlled by a schedule (for example: technicians, physicians, nurses, surgeons, anesthesiologists, or CRNAs).

HL7 Attribute Table - AIP - Appointment Information - Personnel Resource Segment
Seq# DataElement Description Must Implement Flags Cardinality Length C.LEN Vocabulary DataType
AIP
1 00906 Set ID - AIP SHALL [1..1] [1..4] SI
2

00763 Segment Action Code MAY
True:
False:
C
[1..1]
[0..1]
[1..1] ID
3

00913 Personnel Resource ID MAY
True:
False:
C
[1..1]
[0..1]
XCN
4

00907 Resource Type MAY
True:
False:
C
[1..1]
[0..1]
CWE
5 00899 Resource Group [0..1] CWE
6

01202 Start Date/Time MAY
True:
False:
C
[1..1]
[0..1]
DTM
7

00891 Start Date/Time Offset MAY
True:
False:
C
[1..1]
[0..1]
NM
8

00892 Start Date/Time Offset Units MAY
True:
False:
C
[1..1]
[0..1]
CNE
9 00893 Duration [0..1] NM
10 00894 Duration Units [0..1] CNE
11

00895 Allow Substitution Code MAY
True:
False:
C
[1..1]
[0..1]
CWE
12 00889 Filler Status Code MAY
True:
False:
C
[1..1]
[0..1]
CWE

AIP-1: Set ID - AIP (SI) 00906

Definition: This field contains a number that uniquely identifies the information represented by this segment in this transaction for the purposes of addition, change or deletion.

AIP-2: Segment Action Code (ID) 00763

(Definition from OMC.2 in Ch. 8)

Definition:  This field indicates whether this repetition of the segment is being added, changed or deleted.  When using dynamic update mode (See Chapter 2, Section 2.23.4.2, "Action code/unique identifier mode update definition.")  OMC-2 and OMC-3 Segment Unique Key are used to establish the "unique key" and to determine the data subject to the action. Refer to HL7 Table 0206 – Segment action code for valid values.

If the transaction uses dynamic/action code messaging, the field must be valued. 

Condition Predicate: Required if OMC-3 is valued.

(Definition from LCH.2 in Ch. 8)

Definition: This field indicates whether this repetition of the segment is being added, changed or deleted. The action code adds a validation check to indicate, from the point of view of the sending system, whether this repetition of a segment is being added, changed or deleted. This and the following field are used to implement the "unique key" mode of updating repeating segments. (See Chapter 2, section 2.10.4.2, "Action code/unique identifier mode update definition.") Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from LRL.2 in Ch. 8)

Definition: This field indicates whether this repetition of the segment is being added, changed or deleted. The action code adds a validation check to indicate, from the point of view of the sending system, whether this repetition of a segment is being added, changed or deleted. This and the following field are used to implement the "unique key" mode of updating repeating segments. (See Chapter 2, section 2.10.4.2, "Action code/unique identifier mode update definition.") Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from RGS.2 in Ch. 10)

Definition: This field contains the action to be taken when updating or modifying information in this segment from previously sent interface transactions. Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values.

This field is conditionally required. It is required for all updating or modifying trigger events.

(Definition from AIS.2 in Ch. 10)

Definition: This field contains the action to be taken when updating or modifying information in this segment from previously sent interface transactions. Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values.

This field is conditionally required. It is required for all updating or modifying trigger events.

(Definition from AIG.2 in Ch. 10)

Definition: This field contains the action to be taken when updating or modifying information in this segment from previously sent interface transactions. Refer to HL7 Table 0206 - Segment Action Code in Chapter 2, Code Tables, for valid values.

This field is conditionally required. It is required for all updating or modifying trigger events.

(Definition from AIL.2 in Ch. 10)

Definition: This field contains the action to be taken when updating or modifying information in this segment from previously sent interface transactions. Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values

This field is conditionally required. It is required for all updating or modifying trigger events.

(Definition from AIP.2 in Ch. 10)

Definition: This field contains the action to be taken when updating or modifying information in this segment from previously sent interface transactions. Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values.

This field is conditionally required. It is required for all updating or modifying trigger events.

AIP-3: Personnel Resource ID (XCN) 00913

Definition: This field contains the ID number and name of the person being requested or scheduled for an appointment. This field is used to identify a specific person being requested, or a specific person who has been scheduled as a resource for an appointment. If the specific person is not known, but the type of resource is, AIP-4 Resource Type is used to identify the type of personnel resource required or scheduled. At a minimum, the ID number component should be supplied to identify either the specific person being requested or the specific person who has been scheduled. For inter-enterprise communications, for which a shared ID number may not be available, the minimum components needed to uniquely identify a person may be defined by site-specific negotiations.

This field is conditionally required for this segment. In new schedule request messages, it is required if the request asks that a specific person be scheduled. For all other request messages, the specific person should be identified if the information is available (either because a specific person was initially requested, or because the filler application returned the ID of the specific person who has been scheduled).

This field is required for all unsolicited transactions from the filler application. This field is optional for all query transactions.

AIP-4: Resource Type (CWE) 00907

Definition: This field identifies the type of the personnel requested/scheduled for an appointment. For all messages, this field is conditionally required if a specific location is not identified in AIP-3 Personnel Resource ID. Refer to HL7 Table 0182 - Staff Type in Chapter 2C, Code Tables, for suggested values.

AIP-5: Resource Group (CWE) 00899

(Definition from AIG.5 in Ch. 10)

Definition: This field identifies the requested resource as a member of the indicated group. If, in a Schedule Request Message (SRM), no specific resource is requested, but a resource type is requested, this field can be used to further qualify the type of resource being requested.

(Definition from AIP.5 in Ch. 10)

Definition: This field identifies the requested resource as a member of the indicated group. If, in a Schedule Request Message (SRM), no specific resource is requested, but an AIP-4 Resource Type is requested, the AIP-5 Resource Group field can be used to further qualify the type of resource being requested.

AIP-6: Start Date/Time (DTM) 01202

(Definition from AIS.4 in Ch. 10)

Definition: This field contains the date and time this service needs for the appointment. This field allows the application to identify that the service is required for the appointment at a different time than the appointment's start date/time.

This field is conditionally required. If a value for AIS-5-Start Date/Time Offset is not provided, then a value is required for this field. To specify that there is no difference between the appointment's start date/time and the resource's start date/time either replicate the appointment's start date/time into this field, or specify an offset of zero (0) in AIS-5-Start Date/Time Offset and any valid time unit code in AIS-6-Start Date/Time Offset Units.

(Definition from AIG.8 in Ch. 10)

Definition: This field contains the date and time this service needs for the appointment. This field allows the application to identify that the service is required for the appointment at a different time than the appointment's start date/time

This field is conditionally required. If a value for AIG-9-Start Date/Time Offset is not provided, then a value is required for this field. To specify that there is no difference between the appointment's start date/time and the resource's start date/time either replicate the appointment's start date/time into this field, or specify an offset of zero (0) in AIG-9-Start Date/Time Offset and any valid time unit code in AIG-10-Start Date/Time Offset Units.

(Definition from AIL.6 in Ch. 10)

Definition: This field contains the date and time this service needs for the appointment. This field allows the application to identify that the service is required for the appointment at a different time than the appointment's start date/time

This field is conditionally required. If a value for AIL-7 Start Date/Time Offset is not provided, then a value is required for this field. To specify that there is no difference between the appointment's start date/time and the resource's start date/time either replicate the appointment's start date/time into this field, or specify an offset of zero (0) in AIL-7 Start Date/Time Offset and any valid time unit code in AIL-8-Start Date/Time Offset Units.

(Definition from AIP.6 in Ch. 10)

Definition: This field contains the date and time this service needs for the appointment. This field allows the application to identify that the service is required for the appointment at a different time than the appointment's start date/time.

This field is conditionally required. If a value for AIP-7 Start Date/Time Offset is not provided, then a value is required for this field. To specify that there is no difference between the appointment's start date/time and the resource's start date/time either replicate the appointment's start date/time into this field, or specify an offset of zero (0) in AIP-7 Start Date/Time Offset and any valid time unit code in AIP-8 Start Date/Time Offset Units.

(Definition from EQP.3 in Ch. 13)

Definition: This field is the date/time that the event started.

AIP-7: Start Date/Time Offset (NM) 00891

(Definition from AIS.5 in Ch. 10)

Definition: This field contains the offset this service needs for the appointment, expressed in units of time relative to the scheduled start date/time. This field allows the application to identify that the service is required for the appointment at a different time than the appointment's start date/time. The first component contains the offset amount. An offset of zero (0), or an unvalued field indicates that the service is required at the start date/time of the appointment.

A positive offset (an unsigned or positive number) indicates that the service is required after the appointment's start date/time. Specifying a negative offset indicates that the service is required prior to the specified start date/time of the appointment. Negative offsets are allowed, and sites should clearly define the effect of a negative offset on the appointment's start date/time.

This field is conditionally required. If a value for AIS-5-Start Date/Time Offset is not provided, then a value is required for this field. To specify that there is no difference between the appointment's start date/time and the resource's start date/time either replicate the appointment's start date/time into this field, or specify an offset of zero (0) in AIS-5-Start Date/Time Offset and any valid time unit code in AIS-6-Start Date/Time Offset Units.

(Definition from AIG.9 in Ch. 10)

Definition: This field contains the offset that this resource needs for the appointment, expressed in units of time relative to the scheduled start date/time. This field indicates to the application that the resource is required for the appointment at a different time than the appointment's start date/time. The first component indicates the offset amount. An offset of zero (0), or an unvalued field, indicates that the resource is required at the start date/time of the appointment.

A positive offset (an unsigned or positive number) indicates that the resource is required after the appointment's start date/time. Specifying a negative offset indicates that the resource is required prior to the specified start date/time of the appointment. Negative offsets are allowed, and sites should clearly define the effect of a negative offset on the appointment's start date/time.

This field is conditionally required. If a value for AIG-8-Start Date/Time is not provided, then a value is required for this field. To specify that there is no difference between the appointment's start date/time and the resource's start date/time either replicate the appointment's start date/time into this field, or specify an offset of zero (0) in AIG-9-Start Date/Time Offset and any valid time unit code in AIG10-Start Date/Time Offset Units.

(Definition from AIL.7 in Ch. 10)

Definition: This field contains the offset this resource needs for the appointment, expressed in units of time relative to the scheduled start date/time. This field indicates to the application that the resource is required for the appointment at a different time than the appointment's start date/time. The first component contains the offset amount. An offset of zero (0), or an unvalued field, indicates that the resource is required at the start date/time of the appointment.

A positive offset (an unsigned or positive number) indicates that the resource is required after the appointment's start date/time. Specifying a negative offset indicates that the resource is required prior to the specified start date/time of the appointment. Negative offsets are allowed, and sites should clearly define the effect of a negative offset on the appointment's start date/time.

This field is conditionally required. If a value for AIL-6 Start Date/Time is not provided, then a value is required for this field. To specify that there is no difference between the appointment's start date/time and the resource's start date/time either replicate the appointment's start date/time into this field, or specify an offset of zero (0) in AIL-7 Start Date/Time Offset and any valid time unit code in AIL-8 Start Date/Time Offset Units.

(Definition from AIP.7 in Ch. 10)

Definition: This field contains the offset this resource needs for the appointment, expressed in units of time relative to the scheduled start date/time. This field indicates to the application that the resource is required for the appointment at a different time than the appointment's start date/time. The first component contains the offset amount. An offset of zero (0), or an unvalued field, indicates that the resource is required at the start date/time of the appointment.

A positive offset (an unsigned or positive number) indicates that the resource is required after the appointment's start date/time. Specifying a negative offset indicates that the resource is required prior to the specified start date/time of the appointment. Negative offsets are allowed, and sites should clearly define the effect of a negative offset on the appointment's start date/time.

This field is conditionally required. If a value for AIP-6 Start Date/Time is not provided, then a value is required for this field. To specify that there is no difference between the appointment's start date/time and the resource's start date/time either replicate the appointment's start date/time into this field, or specify an offset of zero (0) in AIP-7 Start Date/Time Offset and any valid time unit code in AIP-8 Start Date/Time Offset Units.

AIP-8: Start Date/Time Offset Units (CNE) 00892

(Definition from AIS.6 in Ch. 10)

Definition: This field contains a code describing the units of time used for expressing the start date/time offset. This field should be valued according to the recommendations in Chapters 2 and 7. If this field 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.

This field is conditionally required. If a value for AIS-5-Start Date/Time Offset is provided, then a value is required for this field.

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 AIG.10 in Ch. 10)

Definition: This field contains a code describing the units of time used for expressing AIG-9-Start Date/Time Offset. This field should be valued according to the recommendations made in Chapters 2 and 7. If this field 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 ANS+ unit codes.

This field is conditionally required. If a value for AIG-9-Start Date/Time Offset is provided, then a value is required for this field.

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 AIL.8 in Ch. 10)

Definition: This field contains a code describing the units of time used for expressing the AIL-7 Start Date/Time Offset field. This field should be valued according to the recommendations made in Chapters 2 and 7. If this field 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 ANS+ unit codes.

This field is conditionally required. If a value for AIL-7 Start Date/Time Offset is provided, then a value is required for this field.

(Definition from AIP.8 in Ch. 10)

Definition: This field contains a code describing the units of time used for expressing AIP-7 Start Date/Time Offset. This field should be valued according to the recommendations made in Chapters 2 and 7. If this field 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 ANS+ unit codes.

This field is conditionally required. If a value for AIP-7 Start Date/Time Offset is provided, then a value is required for this field.

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.


AIP-9: Duration (NM) 00893

(Definition from AIS.7 in Ch. 10)

Definition: This field contains the duration for which the resource is requested/scheduled for this appointment, if different from the overall duration of the requested/scheduled appointment. This field indicates to the application that a resource is required for a different amount of time than the appointment's overall duration. An unvalued duration indicates that the resource is required from its start date/time offset (specified in the previous two fields) until the end of the appointment. If no start date/time offset is specified, then the resource is required for the full duration of the appointment.

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

(Definition from AIG.11 in Ch. 10)

Definition: This field contains the duration for which the resource is requested/scheduled for this appointment, if it is different than the overall duration of the requested/scheduled appointment. This field indicates to the application that a resource is required for a different amount of time than the appointment's overall duration. An unvalued duration indicates that the resource is required from its start date/time offset (specified in the previous two fields) until the end of the appointment. If no start date/time offset is specified, then the resource is required for the full duration of the appointment.

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

(Definition from AIL.9 in Ch. 10)

Definition: This field contains the duration for which the resource is requested/scheduled for this appointment, if it is different than the overall duration of the requested/scheduled appointment. This field indicates to the application that a resource is required for a different amount of time than the appointment's overall duration. An unvalued duration indicates that the resource is required from its start date/time offset (specified in the previous two fields) until the end of the appointment. If no start date/time offset is specified, then the resource is required for the full duration of the appointment.

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

(Definition from AIP.9 in Ch. 10)

Definition: This field contains the duration for which the resource is requested/scheduled for an appointment, if different from the overall duration of the requested/scheduled appointment. This field indicates to the application that a resource is required for a different amount of time than the appointment's overall duration. An unvalued duration indicates that the resource is required from its start date/time offset (specified in the previous two fields) until the end of the appointment. If no start date/time offset is specified, then the resource is required for the full duration of the appointment.

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

AIP-10: Duration Units (CNE) 00894

(Definition from AIS.8 in Ch. 10)

Definition: This field contains a code describing the units of time used for expressing the duration. This field should be valued according to the recommendations in Chapters 2 and 7. If this field 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 AIG.12 in Ch. 10)

Definition: This field contains a code describing the units of time used for expressing the AIG-11-Duration field. This field should be valued according to the recommendations in Chapters 2 and 7. If this field 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 ANS+ 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 AIL.10 in Ch. 10)

Definition: This field contains a code describing the units of time used associated with AIL-9 Duration. This field should be valued according to the recommendations made in Chapters 2 and 7. If this field is not valued, the ISO base unit of seconds (code "s") will be assumed. Refer to Chapter 7 for a list of ISO+ and ANS+ 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 AIP.10 in Ch. 10)

Definition: This field contains a code describing the units of time used associated with AIP-9 Duration. This field should be valued according to the recommendations made in Chapters 2 and 7. If this field 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 ANS+ 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.


AIP-11: Allow Substitution Code (CWE) 00895

(Definition from AIS.9 in Ch. 10)

Definition: This field contains a code indicating whether the identified resource can be substituted with an equivalent resource by the filler application. This field is conditionally required. It is required for all request messages. It is optional for all unsolicited transactions, and for all query messages. Refer to User-Defined Table 0279 - Allow Substitution Codes in Chapter 2C, Code Tables, for suggested codes.

(Definition from AIG.13 in Ch. 10)

Definition: This field contains a code indicating whether the identified resource can be substituted with an equivalent resource by the filler application. Refer to User-Defined Table 0279 - Allow Substitution Codes for suggested codes.

This field is conditionally required. It is required for all request messages. It is optional for all unsolicited transactions, and for all query messages.

(Definition from AIL.11 in Ch. 10)

Definition: This field contains a code indicating whether the identified location can be replaced with an equivalent substitute location by the filler application. Refer to User-Defined Table 0279 - Allow Substitution Codes in Chapter 2C, Code Tables, for suggested values.

This field is conditionally required. It is required for all request messages. It is optional for all unsolicited transactions, and for all query messages.

(Definition from AIP.11 in Ch. 10)

Definition: This field contains a code indicating whether the identified personnel resource can be replaced with an equivalent substitute personnel resource by the filler application. Refer to User-Defined Table 0279 - Allow Substitution Codes in Chapter 2C, Code Tables, for suggested values.

This field is conditionally required. It is required for all request messages. It is optional for all unsolicited transactions, and for all query messages.

AIP-12: 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.

APR - Appointment Preferences Segment

The APR segment contains parameters and preference specifications used for requesting appointments in the SRM message. It allows placer applications to provide coded parameters and preference indicators to the filler application, to help determine when a requested appointment should be scheduled. An APR segment can be provided in conjunction with either the ARQ segment or any of the service and resource segments (AIG, AIS, AIP, and AIL). If an APR segment appears in conjunction with an ARQ segment, its parameters and preference indicators pertain to the schedule request as a whole. If the APR segment appears with any of the service and resource segments, then its parameters and preferences apply only to the immediately preceding service or resource.

HL7 Attribute Table - APR - Appointment Preferences Segment
Seq# DataElement Description Must Implement Flags Cardinality Length C.LEN Vocabulary DataType
APR
1 00908 Time Selection Criteria [0..*] SCV
2 00909 Resource Selection Criteria [0..*] SCV
3 00910 Location Selection Criteria [0..*] SCV
4 00911 Slot Spacing Criteria = [0..1] 5 NM
5 00912 Filler Override Criteria [0..*] SCV

APR-1: Time Selection Criteria (SCV) 00908

Definition: This field is used to communicate parameters and preferences to the filler application regarding the selection of an appropriate time slot for an appointment. The first component of this field is a code identifying the parameter or preference being passed to the filler application. The second component is the actual data value for that parameter.

For example, if a filler application allows preference parameters to be passed to specify a preferred start time, a preferred end time, and preferred days of the week for the appointment, it may define the parameter class codes and valid data sets based on suggested codes from User-defined Table 0294 - Time Selection Criteria Parameter Class Codes in Chapter 2C, Code Tables, for suggested values.

Given the set of parameter class codes and valid value sets from User-Defined table 0294, a placer may indicate a preferred start time of 8:00 AM on Monday, Wednesday or Friday by specifying the following in APR-1 Time Selection Criteria:

...|PREFSTART^0800~MON^OK~WED^OK~FRI^OK~TUE^NO~THU^NO~SAT^NO~SUN^NO|...

The valid set of preferences should be determined by the placer and filler applications during implementation of the interface.

APR-2: Resource Selection Criteria (SCV) 00909

Definition: This field is used to communicate parameters and preferences to the filler application regarding the selection of an appropriate resource for an appointment. The first component of this field is a code identifying the parameter or preference being passed to the filler application. The second component is the actual data value for that parameter.

Refer to Section 10.6.8.1, "APR-1 Time Selection Criteria (SCV) 00908," for an example illustrating how this mechanism works within an interface.

The valid set of preferences should be determined by the placer and filler applications during implementation of the interface. Refer to User-defined Table 0294 - Time Selection Criteria Parameter Class Codes in Chapter 2C, Code Tables, for suggested examples.

APR-3: Location Selection Criteria (SCV) 00910

Definition: This field is used to communicate parameters and preferences to the filler application regarding the selection of an appropriate location for the appointment. The first component of this field is a code identifying the parameter or preference being passed to the filler application. The second component is the actual data value for that parameter.

Refer to Section 10.6.8.1, "APR-1 Time Selection Criteria (SCV) 00908," for an example illustrating how this mechanism works within an interface.

The valid set of preferences should be determined by the placer and filler applications during implementation of the interface. Refer to User-defined Table 0294 - Time Selection Criteria Parameter Class Codes in Chapter 2C, Code Tables, for suggested examples.

APR-4: Slot Spacing Criteria (NM) 00911

Definition: This field is used in queries returning lists of possible appointment slots, or other lists of slots. If the filler application allows it, the querying application may indicate the spacing of the slots returned to the querying application, in relation to the requested start date/time in the ARQ segment. The value in this field should be a positive integer, representing the number of minutes between slot starting times that is returned in the query.

For example, if there is a request that an appointment with a duration of 1.5 hours be scheduled some time between 9:00 AM and 11:30 AM, and the APR-4 Slot Spacing Criteria field contains a value of 15, then the list of slots returned should read as follows:

9:00 - 10:30
9:15 - 10:45
9:30 - 11:00
9:45 - 11:15
10:00 - 11:30

APR-5: Filler Override Criteria (SCV) 00912

Definition: This field is used to communicate override parameters to the filler application. These override parameters allow placer applications to override specific features of filler applications such as conflict checking. It is assumed that the placer and filler applications will pass enough information to determine whether the requestor is allowed to override such features. This chapter does not provide any security or permission information.

The first component of this field is a code identifying the parameter being passed to the filler application. The second component is the actual data value for that parameter.

Refer to Section 10.6.8.1, "APR-1 Time Selection Criteria (SCV) 00908," for an example illustrating how this mechanism works within an interface.

The valid set of parameters should be determined by the placer and filler applications during implementation of the interface.

EXAMPLE TRANSACTIONS

Request and Receive New Appointment - Event S01

The patient has been seen by his primary care physician, Dr. Patricia Primary, and requires treatment by a cardiologist. The PCP requests a new appointment with Dr. Pump at the North Office. The patient has requested that the appointment be scheduled for a time between January 2nd and January 10th, 2007, and between 8:00 AM and 5:00 PM. Dr. Pump's office responds to the request with an appointment at the North Office at 9:30 AM on January 6, 2007.

MSH|^~VALUEamp;|PRIMARY|EWHIN|SPOCARD|EWHIN|200701010800||SRM^S01^SRM_S01|090849PRIMARY|P|2.8|||AL|AL|||<cr>

ARQ|19940047^SCH001|||||047^Referral||NORMAL|||199401020800^199401101700||||0045^Contact^Carrie^S^^^||||3372^Person^Entered||||<cr>

PID||4875439|484848||Everyman^Adam^A^^| |19401121|M|Alias||2222 Home Street^Jay^WA^99021||555-2003|||M|||444-33-3333|||||||||||<cr>

DG1|001|I9|786.5|CHEST PAINS|200701010730|W|||||||||||||<cr>

DG1|002|I9|412|OLD MYOCARDIAL INFARCTION|200701010730|W|||||||||||||<cr>

RGS|001|<cr>

AIP|001||032^Pump^Patrick|002^CARDIOLOGIST|||||||NO|<cr>

AIL|001|^NORTH OFFICE|002^CLINIC|||||||YES|<cr>

MSH|^~VALUEamp;|PRIMARY|EWHIN|JONES|EWHIN|200701010802||ACK|021244SPOCARD|P|2.8||||||<cr>

MSA|CA|090849JONES||||<cr>

MSH|^~VALUEamp;|PRIMARY|EWHIN|JONES|EWHIN|200701010810||SRR^S01^SRR_S01|0934849SPOCARD|P|2.8|||||||<cr>

MSA|AA|090849EVERYMAN||||<cr>

SCH|2007047^SCH001|2007567^SCH100|||||047^Referral|NORMAL||||0045^Contact^Carrie^C^^^|555-2010|||087^By^Entered^^^^|555-2011||||BOOKED<cr>

TQ1||||||30^M|200701060930|200701061000||||||<cr>

PID||4875439|484848||Everyman^Adam^A^^||19401121|M|Alias||2222 Home Street^Jay^WA^99021||555-2003|||M|||444-22-3333|||||||||||<cr>

RGS|001|<cr>

AIP|001|032^Pump^Patrick|002^CARDIOLOGIST|||||||NO|BOOKED<cr>

AIL|001|103^NORTH OFFICE|002^CLINIC|||||||NO|BOOKED<cr>

MSH|^~VALUEamp;|PRIMARY|EWHIN|SPOCARD|EWHIN|200701010812||ACK|434532JONES|P|2.8||||||<cr>

MSA|CA|0934849SPOCARD||||<cr>

Unsolicited Notification of Rescheduled Appointment - Event S13

The patient has asked Dr. Pump to reschedule his January 6th appointment. Dr. Primary’s scheduling application (the filler application) sends the PCP, Dr. Primary, a notification that the original appointment has been rescheduled, followed by a notification of the new appointment on January 9th at 1:00 PM.

MSH|^~VALUEamp;|PRIMARY|EWHIN|JONES|EWHIN|200701040800||SIU^S13^SIU_S12|021244SPOCARD|P|2.8|||AL|ER||<cr>

SCH|2007047^SCH001|2007567^SCH100|||||047^Referral|NORMAL||||0045^Contact^Carrie^C^^^|555-2010|||087^By^Entered^^^^|555-2011||||BOOKED<cr>

TQ1||||||30^M|200701091300|200701091330||||||<cr>

NTE||The patient is going to be on vacation so cannot make previous appointment scheduled on January 6.<cr>

PID||4875439|484848||Everyman^Adam^A^^||19401121|M|Alias||2222 Home Street^Jay^WA^99021||555-2003|||M|||444-22-3333|||||||||||<cr>

RGS|001|<cr>

AIP|001|032^Pump^Patrick|002^CARDIOLOGIST|||||||NO|BOOKED<cr>

AIL|001|103^NORTH OFFICE|002^CLINIC|||||||NO|BOOKED<cr>

MSH|^~VALUEamp;|PRIMARY|EWHIN|SPOCARD|EWHIN|200701010802||ACK|035324PRIMARY|P|2.8||||||<cr>

MSA|CA|021244SPOCARD||||<cr>

Request and Receive New Appointment with Repeating Interval - Event S01

The patient has been seen by his specialist, Dr. Specialize, and requires treatment by a physical therapist, Seth Stretcher. Dr. Specialize's office requests a one-hour appointment each day for the next five days. Mr. Stretcher's office responds to the request with an appointment at 9:30 AM on June 20th through June 24th, 2007.

MSH|^~VALUEamp;|SPECIALIZE|EWHIN|STRETCHER|EWHIN|200706190800||SRM^S01^SRM_S01|03432SPECIALIZE|P|2.8|||AL|AL||<cr>

ARQ|20070347^SCH001|||||047^Referral||NORMAL|060|min|200706200930||Q1D|D5|00335^Specialize^Sara^S^^^MD||||A3423^Person^Entered||||<cr>

PID||4875439|484848||Everyman^Adam^A^^| |19401121|M|Alias||2222 Home Street^Jay^WA^99021||555-2003|||M||444-33-3333||||||||||<cr>

DG1|001|I9|833.00|Closed dislocation wrist|200706190700|||||||||||||<cr>

RGS|001|<cr>

AIP|001|064^STRETCHER^SETH|097^PHYSICAL THERAPIST|||||||NO|<cr>

AIL|001|103^NORTH OFFICE|002^CLINIC|||||||NO|<cr>

MSH|^~VALUEamp;|SPECIALIZE|EWHIN|SMITH|EWHIN|200706190802||ACK|546644STRETCHER|P|2.8||||||<cr>

MSA|CA|03432SPECIALIZE||||<cr>

MSH|^~VALUEamp;|STRETCHER|EWHIN|SPECIALIZE|EWHIN|200706190810||SRR^S01^SRR_S01|0654544JONES|P|2.8||||||<cr>

MSA|AA|03432SSPECIALIZE||||<cr>

SCH|2007037^SCH001|2007297^SCH100|||||047^Referral|NORMAL|| ||0335^Contact^Carrie^C^^^||||064^By^Entered|||||BOOKED<cr>

TQ1|||Q1D||5^D|60^M|200706200930|200706240930||||||<cr>

PID||4875439|484848||Everyman^Adam^A^^||19401121|M|Alias||2222 Home Street^Jay^WA^99021||555-2003|||M|||444-33-3333|||||||||||<cr>

RGS|001|<cr>

AIP|001|064^STRETCHER^SETH|097^PHYSICAL THERAPIST|||||||NO|BOOKED<cr>

AIL|001|103^NORTH OFFICE|002^CLINIC|||||||NO|BOOKED<cr>

MSH|^~VALUEamp;|SPECIALIZE|EWHIN|STRETCHER|EWHIN|200706190800||ACK|045742SPECIALIZE|P|2.8||||||<cr>

MSA|CA|0654544JONES||||<cr>

IMPLEMENTATION CONSIDERATIONS

Logical Relationship of Resource and Service Segments

This chapter implies that the relationship of the repeating resource and service specific segments has a logical "and" relationship. In other words, if more than one AIP segment is sent in a transaction, it is logical to assume that both specified personnel resources are required for the appointment. Currently, there is no way to specify an "or" relationship between the resource and service segments. It is possible to specify a resource type and achieve a similar (but not equivalent) effect.

Multiple Placer Applications

When implementing the transactions defined in this chapter with multiple placer applications, one must consider the implications of a situation when more than one placer application asks to book, hold, lock, or otherwise reserve the same slot or set of slots on a particular schedule.

This chapter makes no attempt to define attribute ownership (e.g., based on application roles). Ownership is the right to create or update attribute content. If two or more applications attempt simultaneously to update the same attribute(s), deadly update collisions may occur, causing data corruption, unless robust mechanisms for bidding and locking such attributes are in place between applications. This chapter makes no attempt to address data ownership issues or to define attribute bidding and locking mechanisms.

This chapter assumes that the placer and filler applications have put such mechanisms into place, therefore resolving any contention or collision issues at the application level. Further, if such mechanisms have not been implemented by the applications, then this chapter assumes that procedural solutions have been implemented by the healthcare provider organization to resolve contention and collision issues.

ISSUES

None.