Š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.

Privola također mora biti zaseban tip podatka, ne kvačica koja pokreće e-mail. Ako pacijent povuče privolu za marketinšku komunikaciju, ali zadrži povijest termina, sustav to mora modelirati kao odvojena, neovisno opoziva ovlaštenja – ne kao jednu zastavicu koja upravlja svime.

Strukturirajte liječnike i usluge, ne pišite ih kao blog

Javni sadržaj ordinacije strukturirani su podaci, ne prozni tekst. Svaki liječnik treba dosljedan tip sadržaja: ime, specijalizacija, kvalifikacije, jezici koje govori, lokacije i usluge s kojima je povezan. Svaka usluga treba svoj tip: opis, trajanje, koji je liječnici nude, koji uvjeti osiguranja ili samoplaćanja vrijede. Ispravno modeliranje toga u headless CMS-u – umjesto kao slobodnog teksta na stranicama – omogućuje ordinaciji da doda liječnika ili otvori lokaciju bez da programer dira kod, uz zadržavanje dosljednosti podataka sustava za rezervacije s onim što je javno prikazano.

Kada se isplati rješenje po mjeri – a kada ne

Generički softver za upravljanje ordinacijom – kartoni pacijenata, naplata, e-uputnice – zrela je, regulirana kategorija. U Hrvatskoj CEZIH već pokriva nacionalnu e-zdravstvenu integraciju i ordinacija to ne bi trebala pokušavati zamijeniti. Slučaj za sustav po mjeri uži je: javna stranica, iskustvo rezervacije i sloj sadržaja koji povezuje liječnike, usluge i lokacije na način koji generičke predloške ne modeliraju dobro.

Pogreška ide u oba smjera – graditi kompletan sustav kartona pacijenata od nule nepotrebno je i predstavlja compliance rizik bez posvećene pravne i sigurnosne provjere, a lijepiti javni obrazac za rezervacije na sustav koji nikad nije bio dizajniran za osobne podatke je gore. Ispravan opseg leži između: uredno modeliran sloj sadržaja i rezervacija, izgrađen na infrastrukturi koja stvarno može zadovoljiti razinu zaštite podataka koju sam marketinški sadržaj ne treba.

Ako procjenjujete obnovu za ordinaciju ili polikliniku, pitanja vrijedna postavljanja dobavljaču nisu o predlošcima ili dizajnu – nego o kontroli pristupa na razini retka, konkurentnosti rezervacija i audit logiranju. Za drugo mišljenje o postojećem sustavu ili konkretnu ponudu za novi – javite se.