Appointments in a clinic: three failures nobody plans for

A clinic's appointment book is the easiest part of its software and the smallest part of its problem. Any calendar holds a slot. The three things that wreck a day are a patient who does not come, a patient who arrives with no slot, and the moment reception hands the patient to the room and the information stops moving. A system that models only the appointment models the part that already works.

Is a slot a time or a resource?

A slot is a reservation, and the resource is almost never just the practitioner: one room, one couch, one ultrasound machine, one assistant. Booking that checks only the doctor will put two patients at 09:30 because two practitioners are free — and both need the same room.

So availability is the intersection of three calendars: practitioner, room, and any equipment the visit requires, each with its own busy periods. A booking then fails at the counter, in front of the person who can pick another time, instead of at 09:25 in a corridor.

The cost is that somebody keeps the room list true. A room marked free while it is being repainted is worse than no system, because reception trusts it.

Why do waiting lists fail, and what makes one work?

Most waiting lists are a notebook, and a notebook fails for one reason: it is not sorted by what a cancellation frees. A cancelled fifteen-minute follow-up is useless to the patient who needs forty minutes with a different practitioner.

A list that gets used is filtered by practitioner, duration and room; carries a contact verified when the note was written; orders by the practitioner's own priority, not by date of call; and surfaces the candidate the moment a slot frees, with one action that records the call and the answer.

Without that last part the list is consulted once, on a bad day, and abandoned.

What is the minimum patient record?

A name, one identifier, a contact, what was done, what happens next. A clinic that starts there gets something used; one that starts with a full medical file gets a screen everyone skips and a "seen" typed at closing.

The identifier must be unique, which is why a phone number is a poor choice: families share one, and then two patients share a history. A patient number issued by the system never collides. Date of birth is worth having because names repeat in any town.

The visit needs three fields: date and practitioner, the reason in the patient's words or a short code the clinic controls, and the outcome — seen, referred, follow-up in a stated period, did not attend. The next step is what reception acts on, so it has to be a field, not a sentence buried in a note.

Anything more — history, allergies, prescriptions, imaging — belongs to a clinical record the practitioner keeps, with its own rules. An appointment system that grows into a half-finished clinical file is the worst of both: sensitive data it cannot protect, and a form nobody completes.

Who may see what?

Health data is the most sensitive thing on the premises, and the counter is its least private point: a screen facing a waiting room, a call made in a full room. The default should be that the list shows a name, a time and a contact, and the reason sits one click away on a screen that does not face the queue.

That means roles, not one shared account: reception sees scheduling and contact details, the practitioner sees the visit, a manager sees counts and no clinical detail. Each role is a permission on a field. Shared logins undo all of it — the OWASP authentication cheat sheet sets out why attribution needs an account that identifies one person.

Access should also leave a trace, because "who opened this file" is the first question asked when an incident is suspected.

What reminder actually works?

A phone call, made by someone who can rebook on the spot. A message confirms a slot the patient already agreed to; a call is the only reminder that can end with a different time in the diary. The reminder's job is not to inform but to move a patient who is about to become a hole in the day.

Calls work when they are specific, early enough that a freed slot can be resold, and recorded — confirmed, asked to move, unreachable, cancelled. Without the record the call happens twice.

Bulk messages are cheap and easy to justify, and worth what they cost when the list behind them is wrong. Fix the list first.

Failure	What a calendar does	What the clinic needs
No-show	Leaves an empty slot	A call that can rebook, recorded
Walk-in	Has nowhere to put them	A queue beside the diary
Double booking	Two names, one time	Room and equipment checked
Reception to room	Nothing	A handover leaving a trace
Who saw what	One login	Roles per field, logged

What should be settled before you choose a system?

Order matters; each step makes the next testable.

1. List the resources a visit consumes — practitioner, room, machine, assistant — and mark which genuinely conflict.
2. Record one week of arrivals, walk-ins included, and count how many were fitted into a slot that did not exist.
3. Write the minimum record on one page, then delete every field reception would not fill with a patient waiting.
4. Decide the roles field by field, and check that reception's screen is unreadable from two metres away.
5. Draft the reminder script and the four outcomes it can end in.
6. Test a day offline: if the connection drops at 10:00, what does the desk do, and where does the record go afterwards?
7. Only then compare products. Ask each vendor to show the walk-in, not the booking.

Where this goes wrong

• The walk-in becomes a fake appointment. The day's numbers look complete and the waiting time is invisible.
• The record grows until it is skipped. Dozens of fields, none filled, and the real reason for the visit lives in a paper notebook.
• The room is never modelled. Two practitioners, one couch, and a corridor queue nobody can explain from the data.
• Everyone uses reception's login. The trace exists and points at one person, who is on leave.
• Reminders are a broadcast. Sent to unverified numbers from an unmaintained list, and the desk calls anyway.

What this does not cover

This is about the diary, the record around it and the people who touch both. It says nothing about what a patient record must contain, how long it is kept, or who may request a copy — that rule belongs to the practitioner's regulator and professional body, not to a software article. Nothing here is medical advice. Billing, insurance and multi-branch scheduling are separate problems with their own shapes.

We build clinic systems around the slot as a resource — room, practitioner, equipment — with a record short enough to fill and a handover that leaves a trace.