Visit type: the one field that decides duration, room, provider and prep

A visit type answers 4 questions at once: how long, with whom, where, and what has to be true first. It is the field the rest of the scheduling system joins to — slot length, provider eligibility, room and equipment, pre-visit forms, prep and any authorisation pre-condition are attributes of the type, not of the appointment. Model it properly and a clinic day assembles itself.

The distinction that matters is between a visit type and a reason for visit. "Knee pain" is a reason; "20-minute established-patient orthopaedic review, any consulting room, no prep" is a type. A schedule can be built from the second and not the first, and clinics with 200 entries on a booking menu have usually been recording reasons in a field the software treats as a type.

The downstream rules that read this one field

The last row is where the front desk meets the revenue side. A type flagged as needing authorisation lets the booking rule refuse a date that leaves no time to obtain it. What a coverage check does and does not confirm is covered in what an eligibility response tells the front desk.

One visit type, field by field

• Code and display name. A stable internal code that never changes, plus a patient-facing name that can be rewritten freely.
• Duration, with a permitted range. A default plus the minimum and maximum a scheduler may override to, so flexibility is bounded.
• Buffers before and after. Cleaning and documentation time modelled explicitly, because a buffer hidden inside the duration cannot be reported on.
• Eligible providers, by role where possible. A new clinician then inherits eligibility instead of needing 40 individual edits.
• Required resources. Room class and equipment, and whether the resource is held for the whole slot or part of it.
• Prep and pre-visit forms. What the patient must do, what they must complete, and when each is sent.
• Pre-conditions. Referral or authorisation required, minimum and maximum lead time, and whether it can be delivered remotely.
• Self-booking flag and follow-up rule. Whether a patient may book it unaided, and which type follows at what interval.

Where a visit produces imaging, the appointment is half the object: the study it generates has its own identity, described in patient, study, series and instance as a data model. The type should carry the order it creates, not just the room.

If the length of an appointment lives in a clinician's head rather than in a field, every booking is a negotiation no automation can join.

Why booking automation stalls when this is unmodelled

An agent asked for "an appointment on Tuesday" must resolve that into a duration, an eligible provider, a resource and a set of pre-conditions before it can offer anything. Where visit types are modelled that is a lookup; where they are not, the agent infers a consultation length from a sentence and every offer needs human confirmation. This is the concrete version of the argument in what it takes to get an agent into production: the model is rarely the constraint, the data model is.

It also decides whether an after-hours channel can do more than take a message, a trade-off worked through in answering service versus a voice agent that can book. On a clean visit-type model this is ordinary agent and automation work.

How many visit types a clinic should actually have

Granularity has a second cost. Every extra type fragments availability: 3 near-identical 20-minute types across 3 providers make a calendar look fuller than it is, because slots held for one cannot absorb demand for another. Laying out that capacity belongs to the provider schedule template.

This is unglamorous configuration that pays for itself across front desk, intake and patient access, and it is the first thing worth auditing in healthcare operations builds before anyone writes scheduling logic.

• scheduling
• patient access
• data modelling
• clinic operations