Bezpieczeństwo systemu medycznego - jak sprawdzić dostawcę

Bezpieczeństwo systemu medycznego sprawdza się pytaniami, na które odpowiedzią jest data, liczba, nazwa albo dokument. Nie potrzeba do tego własnego informatyka ani audytu, bo nie oceniasz technologii, tylko to, czy dostawca w ogóle potrafi na te pytania odpowiedzieć. Poniżej komplet takich pytań, ułożony od tego, co ma być zabezpieczone, przez budowę systemu i wybór między chmurą a instalacją u siebie, aż po warunki wyjścia z umowy.

Dlaczego to Twój obowiązek, a nie uprzejmość dostawcy

Weryfikacja dostawcy przed podpisaniem umowy powierzenia wynika wprost z przepisu i podlega kontroli organu nadzorczego. Art. 28 ust. 1 RODO nie zostawia tu wyboru: administrator korzysta wyłącznie z podmiotów zapewniających wystarczające gwarancje. Przepis nie opisuje jednak procedury, więc placówki często zakładają, że chodzi o audyt bezpieczeństwa, na który nie mają zasobów, i przez to nie robią nic.

Wymagane jest coś znacznie prostszego. Ocena ma się odbyć przed zawarciem umowy i ma dać się później wykazać, co wynika z zasady rozliczalności z art. 5 ust. 2 RODO. Zachowana korespondencja z dostawcą, wypełniona przez niego ankieta i krótka notatka z wnioskami wystarczą, pod warunkiem że powstały przed podpisaniem. Dokument sporządzony po incydencie nie dowodzi już niczego.

Skutki widać w sprawie, w której Prezes UODO ukarał jednocześnie administratora i jego dostawcę. Dostawca zapłacił ponad 250 tys. zł za brak testowania zabezpieczeń, użycie danych rzeczywistych do testów bez pseudonimizacji i niepełną konfigurację zabezpieczeń. Administrator zapłacił blisko 5 mln zł, a wśród zarzutów znalazły się dwa dotyczące wyłącznie jego relacji z dostawcą: brak weryfikacji gwarancji przed zawarciem umowy i nieskorzystanie z przysługującego mu prawa kontroli.

Co właściwie ma być zabezpieczone

Art. 32 ust. 1 RODO wymienia cztery grupy środków i każda z nich przekłada się na jedno konkretne pytanie. Przepis celowo nie narzuca rozwiązań, bo dobór zależy od stanu wiedzy technicznej, kosztu wdrożenia, charakteru przetwarzania i ryzyka. Placówka nie ma więc sprawdzać, czy dostawca ma konkretną technologię, tylko czy potrafi uzasadnić swoje wybory.

Pierwsza grupa to pseudonimizacja i szyfrowanie. Pytanie brzmi: czy dokumentacja medyczna jest zaszyfrowana w spoczynku i kto ma dostęp do kluczy. To pytanie wraca później przy każdym incydencie, bo szyfrowanie uniemożliwiające odczyt jest jedynym wyłączeniem z obowiązku zawiadamiania pacjentów, które zależy wyłącznie od dostawcy.

Druga i trzecia grupa dotyczą ciągłości: zdolności do zapewnienia poufności, integralności, dostępności i odporności systemów oraz zdolności do szybkiego przywrócenia dostępu do danych po incydencie. Zamiast pytać o kopie zapasowe, zapytaj o datę ostatniego odtworzenia z kopii i o to, ile trwało. Dostawca, który testuje odtwarzanie, poda datę bez zastanowienia.

Czwarta grupa to regularne testowanie, mierzenie i ocenianie skuteczności środków. Tu odpowiedzią jest data ostatniego testu bezpieczeństwa, informacja, kto go przeprowadził, oraz ile ustaleń jest już zamkniętych. W sprawie opisanej wyżej brak testów na etapie prac rozwojowych był jednym z zarzutów postawionych dostawcy, a organ powołał się przy tym na normy ISO/IEC 27001 i 27002.

Jednej rzeczy nie żądaj, choć wygląda na najmocniejszy dowód z możliwych. Pełny raport z testu bezpieczeństwa jest mapą podatności systemu, więc dostawca, który rozsyła go każdemu klientowi, tworzy tym samym nowe ryzyko dla wszystkich pozostałych. Odmowa pokazania pełnego raportu jest uzasadniona i sama w sobie jest dobrym sygnałem, natomiast odmowa podania daty, wykonawcy i liczby zamkniętych ustaleń już nie.

Jak zbudowany jest system

Cztery pytania o samą konstrukcję, bo to ona przesądza, jak daleko sięgnie pojedynczy błąd. Żadne nie wymaga wiedzy technicznej po Twojej stronie.

Czy dane placówek leżą w jednej bazie, czy każda ma własną. To jest pytanie o promień rażenia i najważniejsze z całej listy. Przy jednej wspólnej bazie z rozdzieleniem na poziomie rekordu każde miejsce, w którym to rozdzielenie zostanie obejście, otwiera dane wszystkich klientów naraz. Przy osobnych bazach błąd zatrzymuje się na jednej placówce. Wspólna baza nie jest sama w sobie wadą, bo tak działa większość systemów, ale wtedy tym bardziej ma znaczenie, jak dostawca ją testuje.

Kto po stronie dostawcy widzi dane produkcyjne. Zapytaj, czy wsparcie techniczne ma stały dostęp do bazy, czy dostęp nadawany na czas zgłoszenia, z zapisem i za wiedzą placówki. Odpowiedź „nasi ludzie mają dostęp, bo inaczej nie pomogą” jest szczera, ale oznacza, że każde konto pracownika dostawcy jest drzwiami do Twojej dokumentacji.

Gdzie leżą hasła i klucze do systemów. W incydencie, który latem 2026 r. dotknął polski rynek medyczny, sprawcy opisali łańcuch, w którym pojedyncza podatność dała dostęp do serwera, a znaleziony tam klucz do repozytorium kodu otworzył resztę infrastruktury. Pytanie brzmi więc, czy dostawca trzyma klucze w menedżerze sekretów, czy w kodzie i w plikach konfiguracyjnych.

Gdzie fizycznie są dane i kopie zapasowe. Chodzi o kraj oraz o to, czy kopia leży w innej lokalizacji niż system produkcyjny, bo kopia w tej samej infrastrukturze ginie razem z nią przy ataku szyfrującym. Jeżeli dane trafiają poza Europejski Obszar Gospodarczy, wchodzą dodatkowe warunki z rozdziału V RODO, a art. 44 wymaga ich spełnienia przez obie strony umowy.

Chmura czy system zainstalowany u siebie

To pytanie wraca po każdym głośnym wycieku i zwykle pada w formie „może lepiej trzymać dane u siebie”. Na wstępie jedno sprostowanie, bo pokutuje tu nieporozumienie: własny serwer nie jest konieczny. Popularne polskie systemy mają wariant instalacji jednostanowiskowej, czyli na jednym komputerze, a przy kilku stanowiskach jedna z maszyn trzyma bazę danych dla pozostałych.

Żaden z tych modeli nie jest bezpieczniejszy z definicji. Różnią się tym, kto ponosi ryzyko operacyjne i jak duży jest promień rażenia, a to są dwie osobne rzeczy, które łatwo pomylić.

Wniosek jest mniej wygodny, niż obie strony sporu chciałyby usłyszeć. System u siebie zmniejsza promień rażenia i jednocześnie przenosi na placówkę całe ryzyko operacyjne, czyli aktualizacje, kopie i monitoring. Chmura robi odwrotnie: oddaje to ryzyko komuś, kto zajmuje się tym zawodowo, w zamian za to, że jeden jego błąd dotyka wszystkich klientów.

Który wybrać, rozstrzyga zwykle jedna okoliczność. Jeżeli placówka nie ma kogoś, kto realnie odpowiada za tę maszynę, czyli pilnuje kopii, siada do niej przy każdej aktualizacji i sprawdza logi, to model lokalny wygląda bezpiecznie tylko na papierze. Wymóg uruchomienia aktualizacji z konsoli komputera jest tu istotny, bo oznacza, że nikt nie zrobi tego za placówkę zdalnie. Warto przy tym pamiętać, że z trzech polskich decyzji przywoływanych w tym cyklu dwie dotyczą zdarzeń po stronie placówki, nie dostawcy: ataku szyfrującego w przychodni oraz błędu lekarza przy wystawianiu skierowania.

Chmura wygrywa natomiast wyłącznie wtedy, gdy dostawca faktycznie robi to, o co pytasz. Bez tego jest po prostu cudzym serwerem, na którym leżą dane Twoich pacjentów.

Co się stanie, gdy dojdzie do naruszenia

Najważniejsze pytanie w tej grupie dotyczy liczby godzin, w których dostawca powiadomi placówkę. Art. 33 ust. 2 RODO każe podmiotowi przetwarzającemu zgłosić naruszenie administratorowi bez zbędnej zwłoki i nie podaje żadnego terminu. Wytyczne Europejskiej Rady Ochrony Danych zalecają, żeby to umowa określała wczesne powiadomienie, wspierające termin 72 godzin po stronie placówki. Zwrot „bez zbędnej zwłoki” przepisany do umowy z rozporządzenia niczego nie dodaje, bo nie ma czym zmierzyć zwłoki. Liczba godzin daje. Co się dzieje po zgłoszeniu, opisuje osobno wpis wyciek danych u dostawcy oprogramowania.

Drugie pytanie dotyczy logów. Zapytaj, czy system zapisuje, kto i kiedy otwierał dokumentację konkretnego pacjenta, oraz czy placówka dostanie te zapisy na żądanie. Bez nich nie da się odpowiedzieć na pytanie, czyich pacjentów dotyczy zdarzenie, a właśnie tego wymaga formularz zgłoszenia do UODO.

Trzecie pytanie idzie o krok dalej i brzmi: czy ktokolwiek te logi przegląda. Chodzi o to, czy system alarmuje, gdy jedno konto pobiera nietypowo dużo kart pacjentów. Warto zadać je świadomie, bo pokazuje różnicę między zapisywaniem zdarzeń a ich zauważaniem. W żadnej z przywoływanych spraw sygnał nie przyszedł z monitoringu. W przypadku szpitala klinicznego naruszenie wyszło na jaw dopiero wtedy, gdy pacjent poskarżył się Rzecznikowi Praw Pacjenta, a w przychodni w Pajęcznie wtedy, gdy dane przestały być dostępne.

Czwarte pytanie brzmi: czy dostawca użyje danych Twoich pacjentów do czegokolwiek poza świadczeniem usługi. Art. 28 ust. 3 lit. a dopuszcza przetwarzanie wyłącznie na udokumentowane polecenie administratora, a art. 28 ust. 10 dodaje sankcję: podmiot przetwarzający, który sam określa cele i sposoby przetwarzania, jest w tym zakresie uznawany za administratora ze wszystkimi tego konsekwencjami. Pytanie ma dziś praktyczny sens przy statystykach, materiałach marketingowych i uczeniu modeli.

Kto jeszcze widzi dane Twoich pacjentów

Dostawca prawie zawsze ma podwykonawców i przepis wymaga, żeby placówka o nich wiedziała. Art. 28 ust. 2 RODO zakazuje korzystania z dalszego podmiotu przetwarzającego bez uprzedniej pisemnej zgody administratora, szczegółowej albo ogólnej. Przy zgodzie ogólnej dostawca ma informować o zamierzonym dodaniu lub zastąpieniu podwykonawcy i dać możliwość wyrażenia sprzeciwu.

W praktyce podwykonawców jest zwykle czterech i rzadko widać ich w ofercie: dostawca infrastruktury chmurowej, operator kopii zapasowych, brama SMS wysyłająca przypomnienia oraz firma wsparcia technicznego, która ma dostęp do bazy przy zgłoszeniach. Poproś o listę z nazwami i krajami przetwarzania. Dostawca prowadzący ten rejestr na bieżąco wysyła go w jeden dzień, a taki, który zaczyna go składać po Twoim mailu, właśnie odpowiedział na pytanie.

Art. 28 ust. 4 RODO domyka tę konstrukcję w sposób korzystny dla placówki. Na podwykonawcę trzeba nałożyć te same obowiązki ochrony danych, a jeśli ten się z nich nie wywiąże, pełna odpowiedzialność wobec administratora zostaje przy dostawcy pierwotnym. Adresat roszczeń jest więc jeden, niezależnie od tego, ile podmiotów stoi za usługą.

Jak wyjść z umowy

Pytanie o wyjście zadaje się przed wejściem, bo później nie ma już siły negocjacyjnej. Art. 28 ust. 3 lit. g RODO stanowi, że po zakończeniu świadczenia usług dostawca usuwa albo zwraca dane zależnie od decyzji administratora oraz usuwa wszelkie istniejące kopie. Wybór należy do placówki, ale wzory umów przygotowane przez dostawców często rozstrzygają go z góry i wskazują usunięcie po krótkim okresie.

Przy dokumentacji medycznej samo usunięcie zwykle odpada. Art. 29 ust. 1 ustawy o prawach pacjenta każe przechowywać dokumentację 20 lat od końca roku ostatniego wpisu, z wyjątkami dla niektórych rodzajów dokumentacji. Placówka, która zgodzi się na skasowanie danych po trzydziestu dniach od rozwiązania umowy, zostaje z obowiązkiem, którego nie ma jak wykonać.

Przepis milczy natomiast o tym, co przesądza o wartości zwrotu, czyli o formacie. Eksport w zamkniętym formacie spełnia literę obowiązku i jednocześnie nie nadaje się do wczytania w innym systemie. W umowie warto więc zapisać trzy rzeczy: format eksportu, termin jego wydania i to, czy jest odpłatny. Jak wygląda przeniesienie bazy w praktyce, opisuje strona migracja z innego systemu, a kryteria samego wyboru zebrane są we wpisie jak wybrać oprogramowanie dla gabinetu.

Jak ocenić odpowiedzi i co z nimi zrobić

Odpowiedzi ocenia się jednym kryterium, które nie wymaga wiedzy technicznej. Odpowiedź, w której jest data, liczba, nazwa albo dokument, da się zapisać w notatce z weryfikacji. Odpowiedź ogólna nie. To rozróżnienie wystarczy, żeby oddzielić dostawcę, który ma bezpieczeństwo poukładane, od takiego, który ma o nim slajd.

Poniżej komplet pytań z całego wpisu, do wysłania jednym mailem przed podpisaniem umowy.

1. Czy dane placówek leżą w jednej bazie, czy każda ma własną, i jak to rozdzielenie jest testowane?
2. Czy dokumentacja jest szyfrowana w spoczynku i kto ma dostęp do kluczy?
3. Kto po Waszej stronie widzi dane produkcyjne i czy dostęp jest stały, czy nadawany na czas zgłoszenia?
4. Gdzie trzymacie klucze i hasła do systemów?
5. W jakim kraju leżą dane i czy kopia zapasowa jest w innej lokalizacji niż produkcja?
6. Kiedy ostatnio odtwarzaliście dane z kopii zapasowej i ile to trwało?
7. Kiedy był ostatni test bezpieczeństwa, kto go przeprowadził, ile ustaleń jest zamkniętych?
8. W ilu godzinach powiadomicie nas o naruszeniu, liczbą, nie zwrotem z rozporządzenia?
9. Czy system zapisuje, kto i kiedy otwierał dokumentację konkretnego pacjenta, i czy dostaniemy te zapisy?
10. Czy alarmujecie, gdy jedno konto pobiera nietypowo dużo kart pacjentów?
11. Czy dane naszych pacjentów służą do czegokolwiek poza świadczeniem usługi?
12. Jaka jest lista podwykonawców z nazwami, rolami i krajami przetwarzania?
13. Jaki jest format eksportu danych przy wyjściu, termin wydania i czy jest odpłatny?

Te same pytania, razem z polami na odpowiedzi dostawcy, są w gotowym wzorze poniżej. Pobranie nie wymaga podania adresu e-mail.

Prawo daje przy tym narzędzie kontrolne, z którego prawie nikt nie korzysta. Art. 28 ust. 3 lit. h RODO zobowiązuje dostawcę do udostępnienia wszelkich informacji niezbędnych do wykazania spełnienia obowiązków oraz do umożliwienia audytów i inspekcji prowadzonych przez administratora albo upoważnionego przez niego audytora. Wykonanie tego prawa nie musi oznaczać audytu z zespołem bezpieczeństwa: wystarczy raz do roku wysłać ten sam zestaw pytań i porównać odpowiedzi z poprzednimi, bo rozjazd między nimi mówi więcej niż jednorazowa ankieta.

Na koniec sprawdź formę. Art. 28 ust. 9 RODO wymaga, żeby umowa powierzenia miała formę pisemną, przy czym dopuszcza formę elektroniczną. Regulamin usługi zaakceptowany kliknięciem nie zawsze ją spełnia, a przy dokumentacji medycznej to jest pierwsza rzecz, o którą zapyta kontrola.

Podsumowanie

• Weryfikacja dostawcy przed podpisaniem umowy jest obowiązkiem z art. 28 ust. 1 RODO, a jej brak bywa osobnym zarzutem w postępowaniu przed UODO.
• Cztery grupy środków z art. 32 ust. 1 przekładają się na cztery pytania. Najbardziej sprawdzalne są daty: ostatniego testu i ostatniego odtworzenia z kopii zapasowej.
• Najważniejsze pytanie o budowę systemu dotyczy izolacji danych, bo od niej zależy, czy błąd zatrzyma się na jednej placówce, czy obejmie wszystkie.
• Żaden model nie jest bezpieczniejszy z definicji. System u siebie zmniejsza promień rażenia i przenosi na placówkę całe ryzyko operacyjne, chmura robi odwrotnie.
• W umowie zamień „bez zbędnej zwłoki” na liczbę godzin, w których dostawca powiadomi placówkę o naruszeniu.
• Poproś o listę podwykonawców z nazwami i krajami. Art. 28 ust. 2 daje prawo do informacji o zmianach i do sprzeciwu.
• Wybór między usunięciem a zwrotem danych po zakończeniu umowy należy do placówki. Zapisz format eksportu, termin i odpłatność.
• Odpowiedź, w której nie ma daty, liczby, nazwy ani dokumentu, nie nadaje się do notatki z weryfikacji, a to ona jest dowodem, że obowiązek wykonałeś.

Źródła

• Rozporządzenie 2016/679 (RODO), tekst skonsolidowany, art. 5, 28, 32 i 44
• Wytyczne EROD 9/2022 w sprawie zgłaszania naruszeń ochrony danych osobowych, wersja 2.0
• UODO, Za proces przetwarzania danych odpowiada administrator oraz podmiot przetwarzający
• UODO, WSA ponownie potwierdził słuszność decyzji karowej, sygn. II SA/Wa 458/26
• UODO, 10 tys. zł kary za ujawnienie danych pacjenta, decyzja DKN.5131.34.2021
• UODO, Administracyjna kara pieniężna dla SPZOZ w Pajęcznie, decyzja DKN.5131.57.2022
• Asseco, instrukcja instalacji mMedica, warianty instalacji i wymóg lokalnej konsoli przy aktualizacji
• Dziennik Ustaw, ustawa o prawach pacjenta, tekst jednolity (Dz.U. 2024 poz. 581), art. 29