What a GDPR-Compliant CMS for Medical Practices Actually Needs

Most CMS platforms are built to publish pages, not to hold patient data. WordPress, Webflow, even headless tools like Sanity are optimized for content: articles, images, marketing copy. A polyclinic or private practice site needs that layer too — but the moment it adds online booking, doctor profiles tied to real calendars, or any patient information, the project stops being a content site and becomes a system processing special category personal data under GDPR Article 9.

Treating that system like a marketing CMS with a booking plugin bolted on is where most clinic sites run into trouble later — usually when a data protection officer, an insurer, or a patient complaint forces a rebuild. Here's what actually needs to be different.

Two kinds of data, two access models

A clinic site has two very different kinds of content living side by side: public marketing content — services, specialties, doctor bios — and operational data tied to real people — appointments, medical history references, consent records. These shouldn't share a schema, an access layer, or a backup policy.

Public content can be cached aggressively and edited by non-technical staff. Patient data needs row-level access control, audit logging, and a retention policy independent of how long a blog post stays live. In practice that means a Postgres backend — Supabase, in our stack — with row-level security scoped per practitioner, sitting behind a separate application layer from whatever renders the public site, even inside the same Next.js app. A doctor shouldn't be able to query another doctor's patient list just because the API route exists. RLS enforces that at the database, not in application code someone will eventually forget to check.

Booking is a concurrency problem, not a form problem

Most booking widgets treat scheduling as a form submission: pick a time, submit, done. In production, double-booking is a race condition — two patients confirming the same slot within the same second, especially for a high-demand specialist.

Handling it correctly means treating a booking as a transaction with a database-level constraint — a unique index on practitioner and timeslot, or an explicit row lock during the write — not an optimistic UI update that assumes the slot is still free. Cancellation and rescheduling need the same guarantee: a canceled slot has to become bookable again atomically, with no window where it's neither held nor available. It's a solved problem in database design. Most no-code booking tools skip it because it only shows up under real traffic, not in a demo.

Consent and audit trails aren't optional

Processing special category health data requires an explicit legal basis, and practices need to be able to show — not just claim — who accessed which patient record, and when. That means an audit log at the data layer: every read and write tagged with the acting user, timestamp, and reason, stored separately from the record itself so it can't be edited after the fact.

Consent needs to be a first-class data type too, not a checkbox that fires an email. If a patient withdraws marketing consent but keeps their appointment history, the system has to model those as separate, independently revocable permissions — not one flag governing everything.

Structure the practitioners and services — don't blog them

A clinic's public content is structured data, not prose. Every doctor needs a consistent content type: name, specialty, qualifications, languages spoken, which locations and services they're tied to. Every service needs its own type: description, duration, which practitioners offer it, which insurance or self-pay terms apply. Modeling this properly in a headless CMS — instead of as free-text pages — is what lets a practice add a doctor or open a location without a developer touching code, while keeping the booking system's data consistent with what's shown publicly.

Where custom is worth it — and where it isn't

Generic clinic management software — patient records, billing, e-referrals — is a mature, regulated category. In Croatia, CEZIH already handles national e-health integration, and a practice shouldn't try to replace that. The case for a custom-built system is narrower: the public site, the booking experience, and the content layer tying practitioners, services, and locations together in a way generic templates don't model well.

The mistake runs in both directions — building a full medical records system from scratch is unnecessary and a compliance risk without dedicated legal and security review, and bolting a public booking form onto a system never designed to hold personal data is worse. The right scope sits in between: a properly modeled content and booking layer, built on infrastructure that can actually meet the data protection bar the marketing content itself doesn't need.

If you're evaluating a rebuild for a clinic or practice, the questions worth asking a vendor aren't about templates or design — they're about row-level access control, booking concurrency, and audit logging. If you want a second opinion on an existing setup, or a scoped proposal for a new one, get in touch.