What online appointment booking really needs

What does online appointment booking really need?

Five things, and most of them you never see. It has to calculate free slots correctly. It has to check every booking on submission. Cancelling has to be easy. Messages to patients should contain as little health data as possible. And each practice’s data has to be kept separate from that of other practices.

We are writing from our own work here. For CuraNexus, our product for medical practices, we built a practice website, online appointment booking, a patient portal and a practice portal in one system. The website and demo are online; the demo practice shows fictitious data. The decisions below come from that work.

Where do free slots come from?

From four factors. The first is duration: each appointment type has its own length. A preventive check-up takes longer than a short appointment to discuss test results.

The second is rooms and equipment. A booked room or a booked device rules out an appointment, even if the doctor has time. The third is shifts: appointments can only be booked when someone is there. The fourth is holidays: they stay free of bookings.

Only when all four line up is there a free slot. For example, a 30-minute appointment on Wednesday at 10 am can only be booked if three things are true: the room is free, the shift covers the whole half hour, and no holiday has been entered. A fixed grid, say every 15 minutes, is not enough for this. Appointments of different lengths fit into it poorly, and without rooms and equipment, double bookings become a risk.

That is why we separated this calculation rule from the user interface. It sits in a function of its own that does nothing but calculate, and it is covered by automated tests. That way, every new rule can be checked without clicking through the form.

One trap comes up twice a year: when the clocks go forward or back. Appointments are clock times at the practice, which means German local time. Anyone who calculates internally in UTC and converts incorrectly on those days shifts appointments by an hour. So we explicitly calculate every appointment time in German local time.

Why does the server have to check every booking again?

Because two people can see the same slot at the same time. Both choose 10 am, both submit. The form showed both of them the truth, just at an earlier moment.

In CuraNexus, the server recalculates the free slots when a booking is submitted. If the slot has been taken in the meantime, the second patient gets a clear message instead of a silent double booking. In addition, the database itself prevents the same slot from being given out twice.

Public forms also need a limit on how many bookings can arrive within a short time. Otherwise a script could fill the calendar with fake bookings. In CuraNexus, we therefore limit the number of requests per time period.

Should patients be able to reschedule appointments themselves?

With CuraNexus, we decided against it. Patients can cancel appointments but not reschedule them. Anyone who wants a different time cancels and books again. Online cancellation is possible up to a set time before the appointment; after that, through the practice.

That costs patients one extra step. In return, every booking goes through the same check, and there is no second route with its own special cases. A cancelled appointment becomes free again immediately. The waiting list can then offer it to other patients automatically.

Easy cancelling matters more than rescheduling. An appointment that is not cancelled because cancelling is too much hassle ends up as an empty slot. That is why patients see their appointments in the patient portal and can cancel them there if necessary.

Do patients need an account with a password?

For the patient portal, we did without passwords. Patients sign in with a link they receive by email. The link is only valid for a short time and can only be used once.

A password you need for just a few doctor’s visits a year is often forgotten by the time you need it. A sign-in link only requires access to your own inbox. In the portal, patients see their appointments, cancel if necessary and fill in medical history forms online beforehand.

For the practice team, the opposite applies: the practice portal has roles, permissions and two-factor login. Anyone who sees the data of many patients needs stronger protection than someone looking at their own appointments.

What information belongs in messages to patients?

As little as possible. Under Art. 9 GDPR, data concerning health is one of the special categories of personal data. Every email passes through other services and ends up in inboxes that are not always read by the patient alone.

That is why, in CuraNexus, the confirmation to patients gives the date and time, but not the reason for the visit that patients enter when booking. The appointment is still clearly identifiable.

The notification to the practice, on the other hand, deliberately includes the reason. The practice needs it to prepare for the appointment. So the question is not whether data flows. The question is which information each recipient really needs.

Where is the data kept?

In CuraNexus, every practice has a separate installation in a German data centre, with a dedicated database per practice. Only licence and status data come to us.

Separate installations mean more work to run than a shared one. In return, the question of where a practice’s data is kept has a simple answer.

What needs to be settled before launch?

First, the relationship with the practice’s existing management software, the program it uses for records and billing. CuraNexus runs alongside it. So before launch, it has to be clear which appointments can be booked online and how they find their way into the daily routine at reception.

Then the basic data: appointment types with their lengths, rooms and equipment, shifts and holidays. Setting these up is the real work. If they are wrong, even the best logic will calculate incorrectly.

And finally, the form itself. It has to work on a phone, be usable with a keyboard and explain errors right next to the field. The Web Content Accessibility Guidelines, WCAG 2.2, provide a good benchmark for this.