Polityka Prywatności i Ochrony Danych (RODO)
Ostatnia aktualizacja: 23 lipca 2026 r. · Wersja: 2.0
1. Dwie kategorie osób, których dane dotyczą
System przetwarza dane dwóch odrębnych kategorii osób, dla których role prawne i podstawy przetwarzania są różne:
2. Role prawne — kto jest administratorem danych pacjenta
Proponowany i wymagający potwierdzenia model ról:
- Dane Użytkowników (lekarzy): administratorem jest Serwis erecept.pl — przetwarza je we własnym celu (prowadzenie kont, bezpieczeństwo, audyt).
- Dane pacjentów: administratorem jest lekarz lub placówka medyczna, która wprowadza dane w ramach działalności leczniczej. Serwis erecept.pl występuje jako podmiot przetwarzający, działający na udokumentowane polecenie administratora.
Wymóg umowy powierzenia (art. 28 RODO). Powyższy model wymaga zawarcia z każdą placówką/lekarzem
umowy powierzenia przetwarzania danych. Bez takiej umowy przetwarzanie danych pacjentów przez erecept.pl
nie ma prawidłowej podstawy. Kwalifikacja ról (procesor vs. współadministrator) powinna zostać potwierdzona przez prawnika.
3. Podstawy prawne przetwarzania
Dane Użytkowników (erecept.pl jako ADO):
- Uwierzytelnianie i obsługa konta — art. 6 ust. 1 lit. b RODO (wykonanie umowy o świadczenie usługi).
- Weryfikacja uprawnień, bezpieczeństwo, dziennik audytowy — art. 6 ust. 1 lit. f RODO (prawnie uzasadniony interes).
Dane pacjentów (lekarz/placówka jako ADO, erecept.pl jako procesor):
- Dane zwykłe — art. 6 ust. 1 lit. c/e RODO (obowiązek prawny / wykonywanie zadań w obszarze ochrony zdrowia) po stronie administratora.
- Dane o zdrowiu (kategoria szczególna) — art. 9 ust. 2 lit. h RODO (przetwarzanie do celów profilaktyki zdrowotnej, diagnozy medycznej, zapewnienia opieki zdrowotnej), w związku z art. 9 ust. 3 (przetwarzanie przez osobę zobowiązaną do tajemnicy zawodowej — lekarza).
4. Ochrona numeru PESEL i danych pacjentów — stan faktyczny
System stosuje pseudonimizację numeru PESEL. W trosce o rzetelność opisujemy rzeczywisty mechanizm, bez przeceniania jego siły:
- Nie przechowujemy surowego numeru PESEL. Do bazy trafia jego skrót oraz maska. Funkcja
hashPesel() wyznacza skrót algorytmem SHA-256 na znormalizowanych cyfrach.
- Maska UI ujawnia wyłącznie ostatnie 4 cyfry, pozostałe zakrywając, np.
•••••••1234. Maska nie jest odtwarzalna ze skrótu.
- Skrót PESEL nie jest wystawiany klientowi — interfejs zwraca jedynie flagę „rekord ma PESEL".
Ograniczenie pseudonimizacji — istotne. Obecny skrót SHA-256 jest wyznaczany
bez soli i bez klucza (HMAC/pepper). Ponieważ PESEL ma tylko 11 cyfr o znanej strukturze
(data urodzenia, płeć, cyfra kontrolna), przestrzeń możliwych wartości jest na tyle mała, że niesolony skrót jest
w praktyce podatny na odwrócenie metodą siłową / tablicami tęczowymi w razie wycieku bazy. Dlatego
nie twierdzimy, że pseudonimizacja jest „nieodwracalna". Operator zidentyfikował to jako lukę o wysokim
priorytecie i planuje wdrożenie HMAC-SHA256 z tajnym kluczem serwerowym (pepper). Do czasu wdrożenia skrót należy
traktować jako słabą pseudonimizację, a nie anonimizację.
5. Architektura przetwarzania — inferencja lokalna, przechowywanie na VPS
Aby uniknąć nieścisłości obecnych we wcześniejszych wersjach dokumentu, opisujemy realną topologię:
- Inferencja (przetwarzanie w modelu AI) jest lokalna: odbywa się na stacji z GPU przy użyciu silnika llama.cpp i lokalnych modeli Gemma. Aplikacja łączy się z nią tunelem odwrotnym (WSS). W obecnej konfiguracji nie są używane żadne zewnętrzne modele chmurowe.
- Dane w spoczynku są przechowywane na VPS: baza danych (MariaDB) działa na serwerze VPS u zewnętrznego dostawcy hostingu. Przechowywane są tam m.in. treści rozmów, rekordy pacjentów, skróty PESEL, dane kont i dziennik audytowy.
Mechanizm routingu danych wrażliwych. Gdy w rozmowie zostanie wykryty poprawny numer PESEL,
funkcja detectSensitive() oznacza konwersację jako wrażliwą i kieruje ją wyłącznie na backendy oznaczone
jako lokalne (flaga local:true). Ponieważ obecnie wszystkie backendy są lokalne, jest to
zabezpieczenie architektoniczne „na przyszłość" (gdyby kiedykolwiek dodano backend nielokalny) — a nie
blokada istniejącej chmury, bo takiej chmury w systemie nie ma.
6. Powierzenie przetwarzania i łańcuch podprocesorów
Realizacja usługi wiąże się z korzystaniem z podmiotów przetwarzających (podprocesorów). Każdy z nich wymaga umowy powierzenia:
- Dostawca VPS (hosting bazy danych) — przechowuje dane w spoczynku; kluczowy podprocesor.
- Dostawca poczty (SMTP) — wysyłka wiadomości aktywacyjnych i systemowych.
- Zewnętrzne API dziedzinowe — Rejestr Produktów Leczniczych (RPL) / usługi e-recepty, wykorzystywane do weryfikacji informacji o lekach.
- Wyszukiwarka wiedzy / źródła piśmiennictwa (np. PubMed) — wykorzystywane w funkcjach wyszukiwania wiedzy.
Operator zobowiązuje się nie przekazywać do zewnętrznych API danych umożliwiających identyfikację pacjenta ponad zakres niezbędny dla realizacji zapytania oraz prowadzić aktualny wykaz podprocesorów.
7. Transfer poza EOG
Jeżeli którykolwiek z podprocesorów (w szczególności dostawca VPS lub usług pomocniczych) przetwarza dane poza Europejskim Obszarem Gospodarczym, transfer wymaga odpowiedniej podstawy (np. standardowych klauzul umownych) i oceny ryzyka. Operator jest zobowiązany zweryfikować lokalizację przetwarzania u każdego podprocesora.
8. Ocena skutków dla ochrony danych (DPIA)
Przetwarzanie danych o zdrowiu na dużą skalę oraz z użyciem nowej technologii (system AI) należy do przypadków, dla których ocena skutków dla ochrony danych (art. 35 RODO) jest wymagana. Operator wskazuje przeprowadzenie DPIA jako obowiązkowy element wdrożenia przed szerokim udostępnieniem usługi.
9. Bezpieczeństwo — zweryfikowane środki
- Hasła Użytkowników przechowywane jako skrót bcrypt.
- Sesje oparte na losowym tokenie (32 bajty). Ciasteczko:
HttpOnly, SameSite=Lax, oraz Secure na produkcji (za Caddy/TLS). Ważność do 7 dni; zmiana hasła unieważnia wszystkie sesje.
- Dwie bramki rejestracji: potwierdzenie e-mail oraz zatwierdzenie przez administratora; limit 10 wiadomości próbnych dla kont niezatwierdzonych.
- Ograniczanie prób logowania i rejestracji per adres IP (throttling).
- Dziennik audytowy (
audit_log): kto, co, kiedy, z jakiego IP.
- Walidacja domenowa odpowiedzi (weryfikacja leków w RPL, kontrola cyfry kontrolnej PESEL).
Środki do wdrożenia: szyfrowanie dysku VPS (dane w spoczynku), wzmocnienie pseudonimizacji PESEL (HMAC/pepper),
formalna polityka kopii zapasowych i ich szyfrowania. Szczegóły w wewnętrznym rejestrze luk.
10. Okresy retencji
- Konta i dane Użytkowników — przez czas korzystania z usługi oraz okres wymagany przepisami / dla obrony roszczeń.
- Rozmowy i rekordy pacjentów — przez okres wskazany przez administratora danych (lekarza/placówkę) w umowie powierzenia; usuwane lub zwracane na jego polecenie.
- Dziennik audytowy — przez okres uzasadniony celami bezpieczeństwa i rozliczalności.
- Kopie zapasowe na VPS — do czasu nadpisania w cyklu rotacji kopii.
Konkretne terminy retencji podlegają ustaleniu w umowie powierzenia i wewnętrznej polityce retencji.
11. Prawa osób, których dane dotyczą
Przysługuje prawo dostępu do danych, sprostowania, usunięcia, ograniczenia przetwarzania, przenoszenia (gdy dotyczy), sprzeciwu oraz wniesienia skargi do Prezesa Urzędu Ochrony Danych Osobowych (PUODO). W przypadku danych pacjentów żądania realizuje administrator (lekarz/placówka); erecept.pl jako procesor wspiera ich realizację. Zgłoszenia: iod@erecept.pl.
12. Zgłaszanie naruszeń ochrony danych
W razie naruszenia ochrony danych osobowych administrator jest zobowiązany zgłosić je organowi nadzorczemu (PUODO) bez zbędnej zwłoki, nie później niż w ciągu 72 godzin od stwierdzenia, oraz — gdy zachodzi wysokie ryzyko — zawiadomić osoby, których dane dotyczą. Jako procesor erecept.pl zobowiązuje się niezwłocznie informować administratora o wykrytym naruszeniu.