HL7 SCH Scheduling Activity Information
HL7 field reference SCH fields from HL7 v2.5.1 Show fields
These are the generated fields for the version selected at the top of the page. The document stays the same, but the reference panel follows that version.
Fields
| Field | Name | Required | Repeatable | Type | Table |
|---|---|---|---|---|---|
| SCH.1 | Placer Appointment ID | No | No | EI | |
| SCH.2 | Filler Appointment ID | No | No | EI | |
| SCH.3 | Occurrence Number | No | No | NM | |
| SCH.4 | Placer Group Number | No | No | EI | |
| SCH.5 | Schedule ID | No | No | CE | |
| SCH.6 | Event Reason | Yes | No | CE | |
| SCH.7 | Appointment Reason | No | No | CE | 0276 |
| SCH.8 | Appointment Type | No | No | CE | 0277 |
| SCH.9 | Appointment Duration | No | No | NM | |
| SCH.10 | Appointment Duration Units | No | No | CE | |
| SCH.11 | Appointment Timing Quantity | No | Yes | TQ | |
| SCH.12 | Placer Contact Person | No | Yes | XCN | |
| SCH.13 | Placer Contact Phone Number | No | No | XTN | |
| SCH.14 | Placer Contact Address | No | Yes | XAD | |
| SCH.15 | Placer Contact Location | No | No | PL | |
| SCH.16 | Filler Contact Person | Yes | Yes | XCN | |
| SCH.17 | Filler Contact Phone Number | No | No | XTN | |
| SCH.18 | Filler Contact Address | No | Yes | XAD | |
| SCH.19 | Filler Contact Location | No | No | PL | |
| SCH.20 | Entered By Person | Yes | Yes | XCN | |
| SCH.21 | Entered By Phone Number | No | Yes | XTN | |
| SCH.22 | Entered By Location | No | No | PL | |
| SCH.23 | Parent Placer Appointment ID | No | No | EI | |
| SCH.24 | Parent Filler Appointment ID | No | No | EI | |
| SCH.25 | Filler Status Code | No | No | CE | 0278 |
| SCH.26 | Placer Order Number | No | Yes | EI | |
| SCH.27 | Filler Order Number | No | Yes | EI |
If the MSH tells us what sort of message this is, and the PID tells us who the patient is, the SCH tells us what is happening to the appointment. It is the main scheduling segment in an SIU message, and it carries the appointment identifiers, reason, timing, contacts, and status that help the receiving system keep its calendar lined up with the sending system.
The SCH segment is not the entire appointment story. SIU messages usually spread the work across SCH, RGS, AIS, AIG, AIL, and AIP. SCH is the general appointment contract. The other scheduling segments tell you more about services, resource groups, equipment, locations, and people. This distinction matters, because I have seen plenty of interfaces try to make SCH do everything, then discover later that the provider or room was sitting in AIP or AIL all along. I cover that wider resource family in Scheduling over HL7.
Scheduling messages also have a slightly different personality from patient registration or results feeds. The same appointment can be requested, booked, rescheduled, cancelled, deleted, opened, blocked, completed, or marked as a no-show. So the important habit is to separate the message event from the appointment state. MSH-9 tells you what event triggered the message. SCH-25 tells you the filler system's view of the appointment status. They often point in the same direction, but they are not the same field. If you are testing SIU messages in HL7 Soup Web, put those two values next to each other before deciding whether the receiver should create, update, cancel, or no-show the booking.
As usual, optional does not mean useless, and required does not mean meaningful in every old feed you meet. The best SCH segment is the one that gives you stable appointment identifiers, clear timing, a useful status, and enough context to route the appointment without guessing. Filling every field because the standard lists it is rarely the path to happiness.
So let's go through each of the SCH fields and talk about how they tend to behave in real interfaces.
These are the two appointment identifiers that matter most. The placer appointment ID is the identifier from the system or person requesting the appointment. The filler appointment ID is the identifier from the scheduling system that actually owns the booked appointment. In a simple outpatient appointment feed, the filler ID is often the durable appointment number everyone ends up using. In a request/response style workflow, the placer ID is how the requester links the scheduler's reply back to the original request.
Do not treat these as patient IDs, visit numbers, or order numbers. They are appointment identifiers. The EI data type gives you a value, a namespace, and optional universal identifier components, so use them where you can. APT-2196178^^^SCHED is already better than 2196178, because the receiver can tell which system minted the value. If you are moving appointments between multiple clinics or scheduling systems, the namespace becomes less decoration and more survival gear.
In practice, one of these IDs should be present, and good interfaces store both when both are sent. If you are receiving SIU notifications from the appointment scheduler, I would usually key the downstream appointment on SCH-2 once it exists, and keep SCH-1 for correlation with the requesting system. If you receive a later reschedule or cancellation with the same filler appointment ID, update the appointment you already know about. Creating a new appointment every time an SIU arrives is how calendars quietly become fiction.
Occurrence number is mostly about repeating appointments. If a patient has a recurring series and a message is only talking about the third appointment in that series, this field can help identify the child occurrence. It is not a date, and it is not a sequence number for every SCH segment you have ever received.
When repeating appointments are involved, agree very clearly whether the interface updates the whole series or just one occurrence. Some systems assign every child appointment its own placer or filler appointment ID, which is nice and clean. Others rely on a parent appointment ID plus an occurrence number. Both patterns can work, but only if both sides know which one they are using.
The placer group number lets the requesting side group related appointments together. Think of a set of appointments that came from the same referral, the same multi-step booking request, or the same administrative action. It is useful context, but it is not the appointment ID.
If you are storing appointments in a database, this is usually a grouping or correlation column, not the primary key. The common mistake is to use it because it happens to look stable in the first few samples. Then the first patient with two appointments in the same group arrives, and the model stops being cute.
SCH-5 identifies the schedule or calendar in which the appointment is being booked. That might be a clinic schedule, department schedule, machine schedule, or some other local schedule maintained by the filler application. It is useful when the scheduling system has several calendars that are not obvious from the location or provider alone.
Do not assume SCH-5 is the room, provider, or service. Those are usually described more naturally in AIL, AIP, AIS, or AIG. SCH-5 answers the "which schedule is this appointment on?" question. If your receiving system only has one calendar, you may not need it. If it has multiple departments, resource pools, or diary views, this field can save you from a lot of local lookup logic.
This field is required in the base segment, but it is one of those required fields that often makes people squint. The event reason is the reason the scheduling event happened. For example, it might explain why an appointment was cancelled, why a slot was blocked, or why a booking was changed. That is different from the appointment reason, which is why the patient is coming in.
Do not confuse SCH-6 with MSH-9. SIU^S15 tells you that this message is a cancellation notification. SCH-6 can tell you the cancellation reason, such as patient request, provider unavailable, duplicate booking, or a local reason code. Use a coded CE value where possible. Free text can be readable, but it is not much fun when someone later asks you to report all appointments cancelled because the provider was away.
SCH-7 is the reason the appointment is to take place. It may be a simple local value like routine, follow-up, emergency, or walk-in. It may also be a service or procedure-style code in systems that use the appointment reason to describe what the patient is coming for. In some implementation guides this field is treated much like a universal service ID.
The best practice is to send a code and text that the receiver actually understands. FOLLOWUP^Follow-up appointment^HL70276 is more useful than a sentence fragment tucked into the field. Try not to put a diagnosis here unless the profile specifically says that is what the receiver expects. Diagnoses have better homes, and appointment reason is normally about scheduling intent rather than clinical truth.
Appointment type describes the kind of appointment from a scheduling point of view. Common values in the base table include normal, tentative, and complete. Local systems may extend this idea with things like virtual appointment, in-person appointment, nurse visit, specialist review, or other booking categories, although those may also appear in SCH-7, AIS, or local Z segments depending on the interface.
The useful distinction is that SCH-7 says why the appointment exists, while SCH-8 says what type of booking it is. If you need a receiver to display "tentative" differently from "normal", use SCH-8 or a clearly agreed local status/type field. Do not make the receiver infer that from a note, a reason code, or the fact that a staff member typed "maybe" somewhere amusingly unstructured.
SCH-9 is the numeric duration and SCH-10 gives the duration units. You will often see examples like 60|m or 30|min. For database work, I usually normalize this to minutes as early as possible, because reporting and conflict detection become much simpler when every appointment duration speaks the same language.
These fields are older scheduling fields and are often retained for backward compatibility. Later profiles may prefer timing information in TQ1, and many SIU messages give you a start and end time in SCH-11 or in the resource segments instead. If SCH-9 says 30 minutes and SCH-11 gives an explicit start and end that are 45 minutes apart, do not silently pick your favorite. Decide with the sender which value wins, log the mismatch, or reject the message if your workflow needs precise scheduling.
SCH-11 is where many real SIU feeds put the appointment timing. It uses the TQ data type, where component 4 is the start date/time and component 5 is the end date/time. In the sample above, ^^30^20260715103000^20260715110000 says the appointment starts at 10:30 and ends at 11:00. This is also the pattern used in the database tutorial on this site, where SCH-11.4 and SCH-11.5 are mapped into appointment start and end columns.
This is a field where you really do have to inspect the sender's actual message. Some feeds put the main appointment time in SCH-11. Some put resource-specific times in AIS, AIL, or AIP. Some newer or stricter profiles prefer TQ1. The safest implementation checks the segment layout you actually receive and documents which field is authoritative for the appointment start and end. Time zones are another local agreement issue. HL7 timestamps can carry offsets, but plenty of older systems send local wall-clock time and expect the receiver to already know the site.
SCH-11 can repeat, but many receiving systems only expect one repeat. If your sender uses repeats for complex schedules, make sure the receiver is not just taking the first repeat and smiling confidently at the wrong answer.
These fields describe the contact on the placer side. That is normally the person or system responsible for requesting the appointment, or at least someone the filler can contact if the request needs clarification. SCH-12 is the person, SCH-13 is the phone number, SCH-14 is the address, and SCH-15 is the location.
Use structured values where you can. SCH-12 is XCN, so send a real identifier and name components rather than a loose display name. SCH-13 is XTN, so distinguish phone, mobile, email, work, and other contact types using the telecommunication components instead of relying on formatting. The placer contact is not automatically the attending provider, referring provider, or patient contact. If your workflow needs those roles, do not blur them together just because the same human may be involved in a small clinic.
The filler contact is the person or team on the scheduling side. This might be the scheduling clerk, clinic diary owner, department booking office, or another contact point that can answer questions about the appointment held by the filler application. SCH-16 is required in the segment definition, while SCH-17, SCH-18, and SCH-19 add phone, address, and location.
In live systems, this is often more operational than clinical. If a booking goes wrong, this is the contact who can usually fix the appointment. It is not necessarily the provider who will see the patient. Use AIP for personnel resources and PV1 or other segments for provider roles when those are needed. A filler contact that is populated consistently is very handy for support workflows, but a filler contact filled with "UNKNOWN" because someone wanted to satisfy a validator is not much of a gift.
SCH-20 identifies the person who entered the appointment request or scheduling action. SCH-21 gives their phone number and SCH-22 gives their location. This is an audit trail idea, not a clinical provider idea. The entered-by person may be a receptionist, call centre staff member, scheduling clerk, or automated process user.
This field can be useful when a downstream system needs to show who made the booking or when support staff need to trace where a change came from. It should not be used as the appointment owner unless your local interface guide says exactly that. The minute you treat "entered by" as "responsible clinician", you have taught your interface to lie with a very straight face.
These fields link a child appointment back to a parent appointment. SCH-23 is the parent placer appointment ID and SCH-24 is the parent filler appointment ID. They are most useful for recurring appointments, child bookings, or workflows where one parent scheduling request creates several related appointment records.
If every appointment occurrence has its own unique SCH-1 or SCH-2, you may not need the parent IDs very often. If the sender uses a parent plus occurrence-number model, these fields become important. The practical rule is simple: do not invent a parent ID because the field exists. Use it when there is a real parent appointment relationship and both systems agree what that relationship means.
SCH-25 is one of the most important fields in the segment. It tells you the appointment status from the filler application's point of view. Common values include pending, booked, waitlisted, overbooked, cancelled, no-show, started, complete, blocked, deleted, and discontinued. This is the field that often drives what the receiving application displays to users.
Keep this separate from the trigger event in MSH-9. A cancellation notification should identify the same appointment and then show an appropriate cancelled status. A no-show notification is not the same as a cancellation. A deletion is not always the same as a cancellation either; in some workflows deleted means the booking was removed from the scheduler, while cancelled means the appointment remains visible with a cancelled state. If those differences matter to your system, agree the exact status codes with the sender before the feed goes live.
In modern mappings, this field lines up very naturally with an appointment status. That is a nice hint about how to model it in your own application too. Store the original code, map it to your internal status deliberately, and keep enough logging to explain why an appointment moved from booked to cancelled or no-show.
These fields connect the appointment to an order. SCH-26 is the placer order number and SCH-27 is the filler order number. They are useful when the appointment is for an ordered service, test, procedure, or referral workflow and the receiving system needs to link the booking back to the order that caused it.
This is another place where naming matters. An appointment ID is not an order number, and an order number is not a patient ID. If an appointment is for a radiology exam, for example, the SCH identifiers identify the appointment, while the order identifiers identify the requested service. Keep both if you receive both.
Be careful about letting scheduling messages create clinical orders by accident. The usual pattern is that the order already exists or has been accepted by the order filler, and the scheduling message links the appointment to it. If your interface creates appointments and orders together, document the ownership very clearly. Otherwise a scheduler can appear to have created an order that the ordering workflow never actually approved. In Integration Soup, I would make appointment routing and order-creation routing separate enough that a reschedule cannot accidentally become a new order.