Websites

Clinic website: appointments, patient data, trust

Online booking, personal data and trust — three tasks a clinic website solves in different ways. What to check before the work starts.

A clinic website differs from any other service website in three ways: it books people for a specific time with a specific person, it collects data that the law treats more strictly than an ordinary enquiry, and it deals with a decision made emotionally and with suspicion. Each of these tasks is solved separately, and trying to cover them all with one contact form usually ends with the receptionist calling back by hand anyway.

Online booking doesn't live on the website

The main mistake in setting the task sounds like this: "make an appointment form". The form is the last screen. Booking works when the site knows the schedule: which doctors are seeing patients, at what hours, in which room, which slots are already taken and how long a particular service takes. None of that is stored on the site; it lives in the clinic's medical information system.

Hence a fork to go through before design.

  • Integration with the medical system. The site requests free slots and creates the appointment directly in the system. The patient sees the real schedule, and the receptionist doesn't transfer anything by hand. This is the most useful option and the most demanding: it needs access to the system's API, and not every system has one.
  • A third-party booking widget. Quick to connect, but looks out of place, rarely allows styling and takes the patient into someone else's interface. Acceptable as a temporary solution.
  • An appointment request. The patient leaves the preferred doctor and a convenient time, and the receptionist calls back to confirm. This isn't a booking but a lead. It's more honest to say so on the button: "Leave a request", not "Book an appointment" — otherwise the person will wait for a confirmation that won't come.

If there's no integration and none is planned soon, the third option works. What's dangerous is calling a request a booking and giving the patient the feeling that the time has been reserved for them.

What breaks in practice

The schedule changes more often than it seems: a doctor is ill, an appointment is moved, an extra slot opens up. If the site keeps a copy of the schedule, that copy will go stale. So booking either reads data from the system in real time or doesn't show specific slots at all. The in-between option — "exported yesterday, shown today" — is the worst: it's guaranteed to produce patients arriving for appointments that don't exist.

Patient data is a separate perimeter

An ordinary website form collects a name and phone number. A clinic form almost always collects more: the doctor's specialty, the reason for the visit, sometimes a child's age or a description of the complaint. That's no longer contact data, and it has to be handled differently.

A practical minimum to build into the project:

  1. Collect only what's needed for booking. A "describe your problem" field on the booking page looks caring but in fact creates a store of medical information that will have to be protected. If the receptionist clarifies by phone anyway, the field is unnecessary.
  2. Explicit consent to processing. Not in small print under the button, but as a separate checkbox with a link to a policy that can actually be read. A pre-ticked box doesn't count as consent.
  3. An encrypted channel and limited retention. HTTPS is mandatory everywhere, and requests shouldn't sit in the receptionist's inbox for years. Decide where they go and after what period they're deleted.
  4. Role-based access. A content manager who edits texts shouldn't see the patient list. This separation is made when designing the admin panel, not after an incident.
  5. Analytics without leaks. Sending a "request submitted" event to analytics is fine. Sending the field contents isn't — not even by accident, through automatic collection of form values.

The general logic is simple: the less sensitive data passes through the site, the cheaper and safer the project. Anything that can stay inside the medical system is better left there. The technical perimeter — protection, access and updates — is covered separately in our security services.

Doctor and service pages

A patient chooses not a clinic but a person. So a doctor's page isn't a card in a common list but a full page with its own URL, one you can link to and that people find by name in search.

What it should include:

  • the specialty and what exactly the doctor treats;
  • education and professional development — as facts, without superlatives;
  • a photo taken in the clinic, not from a stock library;
  • the appointment schedule, or at least the days;
  • a booking button for this specific doctor, with the choice already filled in.

A service page is built similarly but answers different questions: what the procedure is, how it goes, how long it takes, whether preparation is needed, whether there are contraindications, which doctors perform it. The "service → doctors who perform it → booking" link is the main navigation of a medical website.

A note on prices. A price list on the site is almost always needed, but the cost of medical services depends on the scope of work, and that should be said directly in the price list, not in a footnote. "Consultation fee" and "treatment cost" are different things, and the patient should see which one is listed.

What must not be written

Medicine is an area where marketing copy creates not only reputational but also legal risk. There are phrasings that shouldn't appear on a clinic's website.

A clinic website can explain how treatment works, but it can't promise its outcome.

Specifically: promises of a guaranteed cure, claims of safety and no side effects, comparisons with other clinics in your favour, testimonials in which a patient thanks you for a specific medical outcome. The same goes for recommendations that read like a prescription: a website doesn't diagnose or select medication, even in the form of "take our test and find out what you have".

What works instead is describing the process: what equipment is used, how the appointment goes, what happens afterwards, who to contact with questions. It's duller, but it's exactly what relieves the anxiety for which a person reads the site in the first place.

Trust is a task, not a section

Trust in medicine is built on verifiable things, and almost all of them are content work, not design.

  • Licences and documents published so they can be opened and read, not as tiny images.
  • The legal name, address and company details — they're checked more often than it seems.
  • Real photos of the premises and equipment. A stock operating room is recognised instantly and damages the impression more than having no photos at all.
  • Reviews linked to an external source where they can be verified.
  • A clear answer to "what do I do if something goes wrong": a manager's contact, the procedure for raising a complaint.

The technical side plays a part too. A slow site, broken layout on a phone, a form that silently sent nothing — all of this reads as carelessness of the organisation as a whole. For a clinic that costs more than for an online store.

What to check before work starts

A short list worth going through before discussing mock-ups. How this fits into the site structure can be seen on the clinic websites page.

  1. Which system holds the schedule, and whether it can be accessed externally. This determines whether booking will be real or turn into a request.
  2. Who at the clinic confirms appointments and during what hours. If a request made at night will only be seen a day later, the patient should be warned on the confirmation screen.
  3. The minimum set of fields the receptionist needs. Remove everything else from the form.
  4. Where requests are stored, who has access to them and after what period they're deleted.
  5. Which staff member will keep doctor pages up to date. A doctor who has left still listed on the site is a common and noticeable problem.
  6. Who will proofread the texts for promises of outcomes. It's a separate review, and it should be done by someone with medical training.

If the answers to the first two points are unknown, it's too early to start on design: they determine what will be on the booking screen at all.