Scheduling

In Version 3, Scheduling is both a domain and a process. As a domain, Scheduling offers a generic set of messages and behavior to implement any number of Scheduling scenarios. As a process, Scheduling offers an abstract data model and a set of operations to any domain within HL7 that utilizes scheduling concepts. We can consider Scheduling as a service and the use of that service as an interface. This release of V3 contains generic scheduling messages that can be implemented by themselves or they can be used as a pattern for domain-specific messages.

The scheduling messages in this section are designed to communicate various events related to the scheduling of generic appointments for healthcare services. There are three basic types of interactions defined in the scheduling domain:

• Request messages and their responses

• Query messages and their responses, and

• Unsolicited notifications

Request transactions communicate requests for the scheduling of appointments for healthcare services or for the booking of resource slots. These transactions occur between placer (requesting) applications and fulfiller (scheduling) applications. The query transactions allow any application to query the current schedule of booked and available slots or booked appointments. Unsolicited transactions provide for the notification of scheduling information between systems.

For this publication of the HL7 Scheduling standard, we are limiting the scope to four basic appointment notification interactions: New Appointment, Revise Appointment, Cancel Appointment. and Reschedule Appointment Future releases will expand the scope to include additional scenarios, including requests, queries and slot management.

Scheduling as an Interface to Services

To understand Scheduling as a service, consider the Unified Modeling Language (UML) concept of an interface in the graphic below. In object terminology, an interface is a collection of operations that are used to specify a service of a class or component. In HL7 Version 3, the ActAppointment class is the focus class for all scheduling notification messages. The initial operations offered by the ActAppointment class are the four interactions listed above. The domain classes that might interface to Scheduling are Encounter, Procedure, Observation, etc. as listed along the right-hand side of the graphic.

The interface concept defines a service that is realized by an object through its operations. These operations are the interactions listed inside the interface object in the graphic.

Definitions and Relationships

In this section, a generic scheduling service is defined using abstract concepts that apply equally well to any scheduling activity. While some of the following concepts are not supported in this first release, it is important to understand the entire Scheduling domain first by reviewing the definitions. In addition to the Patient, which is defined as elsewhere in this standard, the following terms have a special meaning within the context of HL7 V3 Scheduling:

• Schedules control the allocation of slots to certain services and the use of particular resources. They consist of a set of open, booked, reserved, and blocked slots for one particular service or resource.

• Slots are identifiable periods of time that can be scheduled.

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

  • Reserved slots are periods of time on a schedule that have been tentatively or generally reserved (for example, a block of time set aside for new patients)

  • 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 may be unavailable for maintenance reasons).

• Appointments occupy sets of one or more booked slots on a schedule.

• Repeating appointments are repetitions of the same appointment occurring at later slots but sharing the same patient, service and resource characteristics as the first appointment in the repeating series.

• Services are real-world events, such as clinic appointments, the performance of which is controlled by a schedule.

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

This Scheduling standard supports both closely and loosely-coupled systems. In general, closely-coupled systems will need to exchange slot information frequently in order to stay synchronized, while more loosely-coupled systems can exchange appointment information without needing to be constantly synchronized. The Patient can be identified with an ID or by name and the resources can be specified by ID or by type.

Application Roles

Many application roles have been identified within the scheduling process. Shown below are the definitions of these application roles. For this publication of the HL7 Scheduling standard, all application roles are not supported due to the limited scope. It is important to note that a scheduling application can fulfill multiple roles. For example, the application can be both an informer of an appointment as well as a requestor for an appointment from another application. .

• Appointment Informer - In this role, the application notifies a tracking system that an appointment has been booked or modified in some way.

• Appointment Tracker - In this role the application is only a receiver of scheduling information. In other words, the application does not generate any messages, but receives notifications.

The following application roles are planned for future releases:

• Slot Requester - In a tightly-coupled environment where applications share knowledge about slots, the requesting application can request booking by slots. In this application role, a system can request a new appointment, modify an appointment, or request slot status changes.

• Slot Request Responder - In this role, the owner of the schedule or an intermediary responds to a request to book an appointment by specific slots.

• Slot Informer - In the role of Slot Notifier, the owner of the schedule or an intermediary sends out unsolicited notifications about changes in slot status information.

• Slot Tracker - In this role, the application is receiviing unsolicited information about slots.

• Appointment Requestor - In this role, the application requests a new appointment or modifications to an existing appointment from the request responder. Usually, the request responder is the owner of the schedule.

• Appointment Request Responder - The schedule owner or an intermediary responds to a request from another application. For example, another application sends an appointment request and the request responder returns with a confirmed appointment or a denial.

• Appointment Inquirer - In this role, the application makes inquires to the schedule owner application. For example, it inquires for a list of all patients booked from 8 AM till 5 PM, for hearing examinations.

• Appointment Query Responder - In this role, the schedule owner or intermediary responds to a query submitted by an Appointment Inquirer role. An example of the inquiry responder role is the case where an application requests a list of all booked slots for Dr. Miller and the Appointment Query Responder responds with that information.

Types of Interactions

There are three basic types of interactions in the Scheduling domain:

• Notifications are unsolicited messages from an Informer application notifying a Tracking application of changes in the owner's schedule. In the case of notifications, the only obligation of the tracker is to acknowledge receipt of the message.

• Requests/responses are the messages and trigger events used between requesting applications and the schedule owner. The requesting application initiates a message requesting that the schedule owner modify its schedule with the given trigger event and information. The schedule owner responds to these requests to either grant or deny the request and to supply additional details about the confirmed request.

• Queries/responses are the messages and trigger events used between querying applications and schedule owner applications. Querying applications initiate the interaction by sending a query transaction. The owner or an intermediary then responds to the query with the appropriate appointment ot slot information.

As mentioned above, this first release only supports Notifications for New, Revised, Cancelled, and Rescheduled Appointments..

Relationship Between Order, Appointment and Encounter or Service

An order is what begins the entire scheduling process. An order may cause one or more requests for the booking of resources. When the scheduling application receives the request(s), it creates the appointment by booking slot(s) in the schedule associated with the particular resource. Now the appointment has been booked.

In an outpatient scenario, when the patient arrives for an appointment with the physician, the outpatient encounter starts and the appointment is complete. If the patient does not arrive, the appointment is marked as a no show. When the visit is complete, the encounter is completed.

In the case of an inpatient visit, where multiple services are required, when the patient arrives at the hospital, the inpatient encounter is started, but the encounter is not complete until all necessary services have been rendered and the patient is discharged from the hospital.

Procedures and observations, as well as other clinical and non-clinical activities may be controlled by a schedule. In cases where the target of the scheduling process is a clinical activity, it may be preceded by an order or it may be part of a larger ordered service. In either case, the order would precede the appointment request, which in turn, would precede the appointment. When the service begins, the appointment is complete.

Scheduling Status Codes Mapped to V3 Act Status Codes

The prototypical status codes for Act.status_cd in the RIM may be interpreted as shown in the following tables:

Appointment Status Code RIM Status Codes

Complete	Complete
Delete	Nullify
Discontinue	Abort
Cancelled	Abort
Booked	Active
To Be Rescheduled	Hold
No Show	Complete

In V2, two additional status codes exist: Pending and Waitlist. The corresponding V3 messages are not included in the scope of this publication, but will be included in a future V3 release. The V2 'Pending' filler status code will be equivalent to the V3 Appointment Request status code of 'Active'. The V2 Waitlist filler status code will be equivalent to the V3 Appointment Request status of 'Suspend'.

Go To Top