HL7 AIS Appointment Information
HL7 field reference AIS 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 |
|---|---|---|---|---|---|
| AIS.1 | Set ID - AIS | Yes | No | SI | |
| AIS.2 | Segment Action Code | No | No | ID | 0206 |
| AIS.3 | Universal Service Identifier | Yes | No | CE | |
| AIS.4 | Start Date/Time | No | No | TS | |
| AIS.5 | Start Date/Time Offset | No | No | NM | |
| AIS.6 | Start Date/Time Offset Units | No | No | CE | |
| AIS.7 | Duration | No | No | NM | |
| AIS.8 | Duration Units | No | No | CE | |
| AIS.9 | Allow Substitution Code | No | No | IS | 0279 |
| AIS.10 | Filler Status Code | No | No | CE | 0278 |
| AIS.11 | Placer Supplemental Service Information | No | Yes | CE | 0411 |
| AIS.12 | Filler Supplemental Service Information | No | Yes | CE | 0411 |
AIS is the HL7 Appointment Information 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.
Scheduling segments carry the appointment story in pieces: request, service, resource group, location, personnel, preferences, and timing.
The v2.5.1 structures show AIS in SIU_S12 (Notification of new appointment booking), SQM_S25 (Schedule query message and response), SQR_S25 (Schedule query message and response), SRM_S01 (Request new appointment booking), and 1 other message structure. That tells you where it can appear, but the local implementation guide still decides which optional fields are meaningful.
Scheduling flows are easier to reason about when the request, resource, and appointment fields are visible together. HL7 Soup Web is helpful for inspection, and Integration Soup can keep resource mapping and routing rules explicit.
So this page stays intentionally practical: what each field is for, what shape the generated v2.5.1 data gives it, and where I would be careful before mapping it.
AIS-1 is the sequence number for this service line in the appointment detail. It lets the message distinguish one scheduled service from another, such as consultation plus imaging, without pretending to be the appointment ID or order number.
AIS-2 is used when a service line is being added, changed, deleted, cancelled, or otherwise acted on in a scheduling update. It should describe the action on this AIS line, not the overall appointment status. If the request is really replacing one service with another, make that explicit in the trigger and segment actions.
AIS-3 is the service being scheduled: the clinic visit, test, procedure, therapy session, imaging activity, or other scheduled service. It is similar in spirit to an OBR universal service identifier, so the code system matters. "XRAY" from one scheduler and "XRAY" from another may not mean the same thing.
Do not use AIS-3 as the appointment reason. The service is what is being booked; the reason belongs in ARQ-7 or the surrounding order/referral context. When a service has both a local scheduling code and a clinical code, decide which one the receiver expects and keep the mapping visible.
The service may start at the appointment start, or it may be offset from it. AIS-4 gives an explicit service start date/time. AIS-5 and AIS-6 describe an offset and units relative to the appointment start.
For a simple appointment these fields may feel redundant, but they become useful when a visit has multiple services in a sequence. If the appointment starts at 09:00 and the imaging service starts 20 minutes later, the receiver needs to know whether that is an absolute service time or an offset from the overall appointment.
AIS-7 and AIS-8 describe the duration of this service line, not necessarily the full appointment. That distinction matters when a visit includes several booked activities, or when resources are reserved longer than the patient-facing service.
Send a positive duration with the units the receiver expects. If the duration is omitted, the filler may assume the service runs from its start point to the end of the appointment, which can quietly overbook or underbook capacity.
AIS-9 says whether the filler may substitute an equivalent service. That needs a real business rule: substituting a standard follow-up clinic may be acceptable, while substituting a different procedure code is not.
AIS-10 is the filler-side status for this service. It is useful in confirmations and notifications, but it should not be confused with the service code, appointment reason, or overall appointment status.
AIS-11 carries extra service details from the placer to the filler when the service code alone is not enough. AIS-12 lets the filler report the corresponding details it accepted, modified, or actually scheduled.
These fields are coded supplemental details, not a junk drawer. Use them for profile-defined logistics such as preparation, special handling, or service-specific constraints. If a receiver is expected to drive workflow from the value, make the allowed codes explicit.
Related links
- SCH - Scheduling Activity Information
- ARQ - Appointment Request
- RGS - Resource Group
- AIG - Appointment Information - General Resource
- AIL - Appointment Information - Location Resource
- AIP - Appointment Information - Personnel Resource
- APR - Appointment Preferences
- TQ1 - Timing/Quantity
- SIU_S12 - Notification of new appointment booking
- SQM_S25 - Schedule query message and response
- SQR_S25 - Schedule query message and response