Bezpieczeństwo systemu medycznego to nie pojedyncza funkcja, lecz właściwość całej architektury. Obejmuje uwierzytelnianie, zabezpieczenie API, podpis dokumentów w integracjach z P1 i ZUS, szyfrowanie dokumentacji, audyt zdarzeń i zgodność z RODO. Projektuje się je od pierwszego dnia, bo dołożone na końcu jest zwykle tylko listą haseł.
Nie jesteś techniczny? Najważniejsze w trzech zdaniach:
Za dane pacjentów odpowiada Twoja placówka, nie wykonawca systemu. Wyciek dokumentacji medycznej to zgłoszenie do UODO w 72 godziny, ryzyko kary i utrata zaufania pacjentów. Poniżej znajdziesz listę pytań, które warto zadać wykonawcy, zanim podpiszesz umowę.
Ten materiał opisuje doświadczenie wdrożeniowe, a nie poradę prawną ani audyt bezpieczeństwa. Konkretne decyzje warto skonsultować z IOD, prawnikiem lub specjalistą ds. bezpieczeństwa.
Dlaczego opisujemy właśnie ten temat
Bezpieczeństwo opisujemy na podstawie wdrożenia obejmującego około 150 placówek, 40 lekarzy, ponad 450 zadań projektowych oraz około 1,5 roku prac nad systemem medycznym. Dzięki temu pokazujemy rozwiązania zastosowane w praktyce, a nie teoretyczne listy kontrolne przepisane z dokumentacji.
Czego nauczyło nas wdrożenie
Przy portalu systemu dla sieci placówek medycznych bezpieczeństwo nie było jednym zadaniem, tylko wątkiem, który wracał w kolejnych obszarach: przy logowaniu, przy API, przy integracjach z P1 i ZUS, przy danych i przy audycie. Najwięcej nauczył nas jednak podpis dokumentów.
Założenie: podpis to formalność, „dołożymy podpisany plik".
Rzeczywistość: w komunikacji SOAP z P1 i ZUS podpis realizuje się przez WS-Security, na poziomie komunikatu, a nie gotowego pliku PDF. Do tego doszła obsługa certyfikatów. System otrzymywał je w kontenerze PKCS#12 (p12), a biblioteki po stronie serwera potrzebowały rozdzielonego klucza i certyfikatu w formacie PEM, więc konwersja stała się częścią wdrożenia. Najwięcej pracy kosztowało jednak rozdzielenie dwóch warstw, które na pierwszy rzut oka wyglądają jak jedna: certyfikatu, którym system uwierzytelnia się jako świadczeniodawca (WS-Security), oraz certyfikatu, którym konkretny lekarz podpisuje swój dokument. Przy 40 lekarzach oznaczało to, że architektura musiała trzymać podpis „per lekarz", a nie „per system".
Wniosek: to, co w ofercie mieści się w jednym słowie „podpis", w systemie medycznym rozkłada się na uwierzytelnianie komunikatu, obsługę certyfikatów, konwersję formatów i model wielolekarzowy. Jeśli wykonawca traktuje to jak formalność, zapłacisz za to na etapie integracji.
Dwa różne certyfikaty (lekarz i system) na jednej ścieżce — najczęstsze źródło nieporozumień przy wdrożeniu.
Ile kosztuje błąd
Bezpieczeństwo bywa traktowane jak koszt, dopóki nie policzy się kosztu jego braku. W systemie medycznym stawką są dane o zdrowiu, czyli najsilniej chroniona kategoria danych. Zaniedbanie może oznaczać:
- Obowiązek zgłoszenia naruszenia do UODO w 72 godziny (art. 33 RODO), a przy wysokim ryzyku także zawiadomienie pacjentów (art. 34).
- Kary finansowe sięgające w RODO do 20 mln euro lub 4% rocznego obrotu; UODO nakładał już kary na podmioty z sektora ochrony zdrowia.
- Przestój placówki i utratę dostępu do dokumentacji, jeśli incydent unieruchomi system.
- Utratę zaufania pacjentów, którą trudniej odbudować niż naprawić samą lukę.
Dlatego bezpieczeństwo najtaniej wychodzi wtedy, gdy jest wymaganiem architektonicznym od początku, a nie poprawką po incydencie.
Checklista: 12 pytań do wykonawcy (PDF)
Wydrukuj i zabierz na rozmowę z dostawcą. Im więcej pustych pól, tym większe ryzyko.
Co obejmuje bezpieczeństwo w praktyce
Poniżej warstwy, które w praktyce trzeba zaprojektować i utrzymać. Pominięcie jednej potrafi osłabić pozostałe, bo szyfrowanie danych nie pomoże, jeśli dostęp do nich jest źle uwierzytelniony.
Najłatwiej zrozumieć wartość każdej warstwy przez to, co dzieje się, gdy jej zabraknie:
| Warstwa | Co się stanie, jeśli jej zabraknie |
|---|---|
| Uwierzytelnianie (2FA) | przejęcie kont personelu i dostęp do dokumentacji |
| Ochrona API | możliwość nadużyć i nieuprawnionych operacji na danych |
| Szyfrowanie danych | czytelny wyciek dokumentacji i identyfikatorów przy naruszeniu |
| Podpis i certyfikaty | brak wiarygodności dokumentu i odrzucenie w integracji z P1/ZUS |
| Audyt zdarzeń | brak możliwości wykrycia i odtworzenia incydentu |
| Backup i retencja | utrata danych i naruszenie obowiązku ich przechowywania |
RODO, DPIA, NIS2 i retencja
Dokumentacja medyczna to szczególna kategoria danych osobowych (art. 9 RODO) — to jej dotyczy najsilniejsza ochrona, a identyfikatory jak PESEL są dodatkową warstwą. W praktyce oznacza to m.in.:
- Role — placówka jest administratorem. Jeśli wykonawca przetwarza dane pacjentów w jej imieniu (np. hosting lub utrzymanie), staje się podmiotem przetwarzającym, co wymaga umowy powierzenia (art. 28 RODO).
- DPIA — przetwarzanie danych o zdrowiu na dużą skalę zwykle wymaga oceny skutków dla ochrony danych (art. 35 RODO).
- NIS2 i cyberbezpieczeństwo — podmioty ochrony zdrowia są traktowane jako istotne dla cyberbezpieczeństwa, co niesie dodatkowe obowiązki w zakresie zarządzania ryzykiem i zgłaszania incydentów. Zakres obowiązków zależy jednak od rodzaju podmiotu oraz aktualnego stanu wdrożenia przepisów krajowych, dlatego warto potwierdzić go dla swojej placówki.
- Retencja dokumentacji medycznej — co do zasady 20 lat (art. 29 ustawy o prawach pacjenta), z wyjątkami (m.in. dłuższe okresy dla części przypadków, 10 lat dla zdjęć RTG, krótsze dla skierowań). Bezpieczeństwo obejmuje więc też trwałe, chronione przechowywanie.
- Retencja logów to osobny temat od retencji dokumentacji — i często umyka. Sama dokumentacja może leżeć 20 lat, ale jeśli rejestr dostępu do niej kasuje się po 90 dniach, nie odtworzysz, kto ją oglądał dwa lata temu. W naszych wdrożeniach przyjmujemy dla logów dostępu horyzont rzędu kilku lat (min. 5), dobrany do profilu placówki — konkretny okres warto ustalić z IOD, bo zależy od podstawy przetwarzania i rodzaju zdarzenia. To decyzja architektoniczna: przekłada się wprost na koszt storage'u i projekt backupów.
Zgodność z RODO widać nie w dokumencie, tylko w architekturze i w logach.
Red flags: kiedy uważać na wykonawcę
- mówi o bezpieczeństwie jako o jednej pozycji („dodamy szyfrowanie"),
- nie planuje uwierzytelniania dwuskładnikowego ani ochrony API,
- nie ma centralnego audytu zdarzeń ani retencji logów,
- nie potrafi wyjaśnić, jak przechowuje klucze i certyfikaty oraz jak rozdziela podpis systemu od podpisu lekarza,
- traktuje RODO jak dokument, a nie jak wymóg widoczny w systemie.
U nas każdy z tych punktów jest standardem wdrożenia, a nie opcją dodatkowo płatną.
Co dalej
Budujesz lub oceniasz system medyczny?
Przeszliśmy integracje z P1 i ZUS przy wdrożeniu dla ~150 placówek. Na bezpłatnej 30-minutowej konsultacji przejdziemy przez bezpieczeństwo i zgodność Twojego przypadku i wskażemy luki.
Umów bezpłatną konsultację →Warto też przeczytać:
- Integracja z P1 (e-Recepta, e-Skierowanie)
- Integracja z ZUS e-ZLA (e-zwolnienia)
- Migracja danych pacjentów ze starego systemu
FAQ
Co składa się na bezpieczeństwo systemu medycznego?
Kilka warstw naraz: uwierzytelnianie dwuskładnikowe, ochrona API, podpis dokumentów w integracjach, szyfrowanie dokumentacji i identyfikatorów, audyt zdarzeń oraz zgodność z RODO wraz z retencją.
Jak podpisuje się dokumenty w integracji z P1 i ZUS?
Komunikat SOAP zabezpiecza WS-Security certyfikatem systemu (świadczeniodawcy), a osobno dokument podpisuje certyfikat przypisany do konkretnego lekarza. Certyfikaty bywają dostarczane w kontenerze PKCS#12 (p12) i wymagają konwersji do PEM.
Które dane trzeba szyfrować?
Przede wszystkim dokumentację medyczną (dane o zdrowiu, art. 9 RODO), a także identyfikatory jak PESEL oraz klucze kryptograficzne. Szyfruje się dane w bazie i w transmisji.
Czy system medyczny wymaga DPIA?
Przetwarzanie danych o zdrowiu na dużą skalę zwykle wymaga oceny skutków (DPIA, art. 35 RODO). Gdy wykonawca przetwarza dane w imieniu placówki, potrzebna jest umowa powierzenia (art. 28).
Czy wszystkie dane medyczne muszą być szyfrowane?
Kluczowa jest ochrona danych o zdrowiu (art. 9 RODO), identyfikatorów jak PESEL i materiału kluczy. W praktyce szyfruje się dane wrażliwe w bazie i całą transmisję, a zakres dobiera do ryzyka. RODO nie narzuca jednej technologii, lecz wymaga adekwatnych środków.
Czy wystarczy hosting w Polsce?
Sama lokalizacja nie wystarcza. Ważne, by dane były przetwarzane w EOG, z umową powierzenia, kontrolą dostępu, szyfrowaniem i kopiami zapasowymi. Bardziej niż kraj liczy się to, kto ma dostęp do danych i jak są zabezpieczone.
Czy kopia zapasowa też musi być szyfrowana?
Tak. Backup zawiera te same dane wrażliwe co system produkcyjny, więc powinien być szyfrowany i chroniony dostępem. Niezaszyfrowana kopia bywa najsłabszym ogniwem, bo często leży poza główną infrastrukturą.
Czy 2FA jest wymagane przez prawo?
Przepisy zwykle nie wskazują wprost metody, lecz wymagają adekwatnych środków ochrony dostępu do danych o zdrowiu. Uwierzytelnianie dwuskładnikowe to uznana dobra praktyka — w systemach medycznych traktujemy je jako standard, nie opcję.
Na czym opiera się ten artykuł
Wdrożenie portalu systemu dla sieci placówek medycznych (~150 placówek, 40 lekarzy, ~1,5 roku): integracje z P1 i ZUS z podpisem WS-Security, obsługa certyfikatów p12 → PEM i podpis per lekarz, uwierzytelnianie dwuskładnikowe, szyfrowanie danych, ochrona API oraz centralny audyt zdarzeń.
