Što CMS za poliklinike i ordinacije stvarno treba pod GDPR-om

Većina CMS platformi napravljena je za objavu stranica, ne za čuvanje podataka o pacijentima. WordPress, Webflow, čak i headless alati poput Sanityja optimizirani su za sadržaj: članke, slike, marketinške tekstove. Web stranica poliklinike ili privatne ordinacije treba i tu razinu – ali čim se doda online naručivanje termina, profili liječnika povezani sa stvarnim kalendarima ili bilo kakvi podaci o pacijentima, projekt prestaje biti obična sadržajna stranica i postaje sustav koji obrađuje posebnu kategoriju osobnih podataka prema članku 9. GDPR-a.

Tretirati takav sustav kao marketinški CMS s prilijepljenim dodatkom za rezervacije obično se osveti kasnije – najčešće u trenutku kad službenik za zaštitu podataka, osiguravajuće društvo ili pritužba pacijenta prisile na obnovu sustava. Evo što stvarno mora biti drukčije.

Dvije vrste podataka, dva modela pristupa

Web stranica ordinacije sadrži dvije vrlo različite vrste sadržaja jednu pored druge: javni marketinški sadržaj – usluge, specijalizacije, profili liječnika – i operativne podatke vezane uz stvarne osobe – termine, reference na medicinsku povijest, evidencije privole. Oni ne bi trebali dijeliti shemu, sloj pristupa ni politiku sigurnosnih kopija.

Javni sadržaj može se agresivno keširati i uređivati od strane netehničkog osoblja. Podaci o pacijentima trebaju kontrolu pristupa na razini retka, audit log i politiku zadržavanja neovisnu o tome koliko dugo blog objava ostaje aktivna. U praksi to znači Postgres backend – kod nas Supabase – s row-level security ograničenim po liječniku, iza zasebnog aplikacijskog sloja od onoga što prikazuje javnu stranicu, čak i unutar iste Next.js aplikacije. Liječnik ne bi smio moći dohvatiti popis pacijenata drugog liječnika samo zato što API ruta postoji. RLS to provodi na razini baze podataka, ne u aplikacijskom kodu koji će netko jednog dana zaboraviti provjeriti.

Naručivanje termina je problem konkurentnosti, ne problem obrasca

Većina widgeta za naručivanje tretira zakazivanje kao slanje obrasca: odaberi termin, pošalji, gotovo. U produkciji je dvostruko rezerviranje termina race condition – dva pacijenta potvrđuju isti termin unutar iste sekunde, osobito kod traženih specijalista.

Ispravno rješavanje znači tretirati rezervaciju kao transakciju s ograničenjem na razini baze podataka – jedinstveni indeks na liječnika i vremenski termin, ili eksplicitno zaključavanje retka pri pisanju – umjesto optimističnog ažuriranja sučelja koje pretpostavlja da je termin još slobodan. Otkazivanje i promjena termina trebaju istu garanciju: otkazani termin mora atomarno ponovno postati dostupan, bez prozora u kojem nije ni zauzet ni dostupan. To je riješen problem u dizajnu baza podataka. Većina no-code alata za rezervacije to preskače jer se problem pojavljuje tek pod stvarnim prometom, ne u demo verziji.

Privola i audit log nisu opcionalni

Obrada posebne kategorije zdravstvenih podataka zahtijeva izričitu pravnu osnovu, a ordinacije moraju moći dokazati – ne samo tvrditi – tko je, kada, pristupio kojem podatku o pacijentu. To znači audit log na razini podataka: svako čitanje i pisanje označeno korisnikom koji ga je izvršio, vremenskom oznakom i razlogom, pohranjeno odvojeno od samog zapisa kako se naknadno ne bi moglo izmijeniti.