Gdy administrator danych medycznych traci kontrolę: co incydent MyDr ujawnia o strukturze bezpieczeństwa danych medycznych w Polsce. Proponowane rozwiązania w modelu Polskiego Systemu Zdrowia (PSZ)®

Incydent MyDr: katastrofa, o której administrator nie wiedział

W sierpniu 2026 r. Ministerstwo Cyfryzacji potwierdziło: system dostawcy oprogramowania medycznego MyDr został zaatakowany. Wyciekło niemal 19 milionów rekordów polskich pacjentów z około 12 tysięcy placówek medycznych, a łączna objętość danych przekroczyła 2 TB. Wśród ujawnionych informacji znalazły się numery PESEL, historia wizyt, treści recept i notatki lekarskie.

Zasadniczy szczegół: wyciek dotyczył głównie informacji historycznych, sprzed 12 kwietnia 2024 r. To rodzi fundamentalne pytanie – dlaczego dostawca wciąż przechowywał kopie sprzed dwóch lat?

Stanowisko UODO jest jednoznaczne: MyDr był podmiotem przetwarzającym, a administratorem pozostaje placówka medyczna. Oznacza to, że przetwarzanie informacji przez MyDr było legalne wyłącznie w zakresie niezbędnym do świadczenia usługi. Gdy cel przestał wymagać przechowywania rekordów historycznych, dostawca nie miał prawa zachowywać ich kopii. A jednak pliki tam były – aż do momentu, gdy zostały skradzione.

Mechanizm ataku był prosty – jedna podatność w systemie zewnętrznego dostawcy ujawniła wrażliwe informacje całej populacji. Jedna nieszczelność oznacza naruszenie prywatności milionów obywateli. Centralizacja to nie kłopot administracyjny – to zagrożenie dla bezpieczeństwa narodowego.

Trzy rozdźwięki między prawem a rzeczywistością

• Pierwszy rozdźwięk: administrator ma obowiązki, ale brakuje mu kontroli.

W przypadku MyDr placówki medyczne znalazły się w sytuacji bez wyjścia. Do włamania doszło na serwerach dostawcy, a atakujący uzyskali dostęp do kopii zapasowych zarządzanych bezpośrednio przez tę firmę. Szpitale i przychodnie nie mogły samodzielnie wykryć włamania, odizolować systemu ani przeprowadzić własnego dochodzenia. Mogły jedynie czekać na komunikat, a następnie „zgodnie z procedurą” zgłosić incydent do UODO i powiadomić pacjentów.

Jak podkreśla adwokat Dominik Lubasz, analiza ryzyka to pierwszy etap działań administratora. Placówka musi ustalić z dostawcą, czy incydent dotknął powierzonych przez nią danych. Samo sformułowanie „ustalić z dostawcą” ujawnia odwrócenie ról: prawny dysponent musi pytać podmiot przetwarzający, czy jego własne zasoby są bezpieczne.

• Drugi rozdźwięk: obowiązek zgłoszenia w 72 godziny, ale odliczanie uruchamia dostawca.
  

RODO wymaga, aby administrator zgłosił naruszenie do UODO w ciągu 72 godzin od powzięcia informacji. Zgodnie z wytycznymi Naczelnej Izby Lekarskiej, „dzień powzięcia informacji” to moment, w którym placówka otrzymała zawiadomienie od dostawcy, a nie czas faktycznego zdarzenia.

Prowadzi to do sytuacji patowej: jeśli MyDr opóźnia powiadomienie lub przekazuje niepełne szczegóły, placówka nie może dokonać zgłoszenia w terminie (bo nie ma wiedzy), a jednocześnie już formalnie „powzięła informację” (bo wpłynęło jakiekolwiek zawiadomienie). Stanowisko UODO wskazuje, że podmiot medyczny nie może biernie czekać – musi aktywnie naciskać na operatora. Jak jednak administrator bez dostępu technicznego ma wywierać nacisk na firmę zarządzającą własną, zamkniętą serwerownią?

• Trzeci rozdźwięk: ryzyko systemowe jest strukturalnie ignorowane.
  

Badanie Polskiego Towarzystwa Koordynowanej Ochrony Zdrowia z 2025 r. pokazało, że 78 proc. dyrektorów szpitali nie wie, co oznacza wdrożenie NIS2, a tylko 31 proc. z nich regularnie przeprowadza analizę ryzyka cyberbezpieczeństwa. To nie jest wyłącznie kwestia świadomości. Przyczyna ma charakter strukturalny: jeśli pliki nie znajdują się na twoich serwerach, twoja analiza ryzyka nie obejmuje miejsca, w którym fizycznie się one znajdują.

MyDr to wierzchołek góry lodowej: systemowa wada architektury

Opisywany przypadek nie jest odosobniony. Ujawnia wadę strukturalną: polski system ochrony zdrowia nakłada obowiązki prawne na administratora, ale władzę techniczną pozostawia w rękach komercyjnych operatorów.

Rzecznik praw pacjenta Bartłomiej Chmielowiec w analizie dotyczącej wdrożenia EHDS wymienił „cyberbezpieczeństwo” jako jedno z czterech głównych ryzyk dla praw pacjentów, stwierdzając wprost, że im większy przepływ danych, tym większa powierzchnia ataku. Niedawny wyciek stanowi tego empiryczne potwierdzenie.

Co gorsza, opisywana architektura jest instytucjonalizowana. Wdrożenie NIS2 będzie wymagało od placówek medycznych stworzenia formalnego Systemu Zarządzania Bezpieczeństwem Informacji (SZBI), obejmującego ocenę ryzyka, raportowanie incydentów i bezpieczeństwo łańcucha dostaw. Skoro jednak pliki nadal spoczywają na prywatnych serwerach zewnętrznych podmiotów – w jaki sposób wymagania te mają zostać spełnione? Jak przeprowadzić „ocenę bezpieczeństwa” infrastruktury, nad którą nie sprawuje się nadzoru?

Dlaczego model dostawcy EDM jest gorszy niż chmura publiczna – i dlaczego to wciąż za mało

Obecny model, w którym cyfrowe kartoteki spoczywają na serwerach dostawców Elektronicznej Dokumentacji Medycznej (EDM), jest rozwiązaniem najgorszym z możliwych – ustępującym nawet chmurze publicznej. Twórca EDM łączy w sobie rolę podmiotu przetwarzającego z fizycznym posiadaniem sprzętu, pozbawionym przejrzystości i rygorystycznych standardów, jakie oferują giganci technologiczni. W przeciwieństwie do AWS czy Microsoft Azure, operatorzy EDM rzadko publikują niezależne audyty, nie oferują mechanizmów ścisłej kontroli kluczy szyfrujących i nie podlegają równie surowym wymogom zgodności. Ich umowy powierzenia często nie precyzują, przez jaki czas pliki mogą być przetrzymywane po zakończeniu świadczenia usługi – czego dowodem są skradzione zasoby archiwalne.

Chmura publiczna oferuje co najmniej umowne zobowiązania dotyczące nieprzetwarzania powierzonych zasobów do celów własnych oraz mechanizmy szyfrowania po stronie klienta. AWS w swoim dodatku dotyczącym informacji zdrowotnych (HDS Addendum) gwarantuje, że nie będzie uzyskiwać do nich dostępu ani ich wykorzystywać. Microsoft Azure w dokumentacji usługi Azure AI Health Insights podaje, że parametry wejściowe i odpowiedzi są przechowywane tymczasowo do 24 godzin, a następnie bezpowrotnie usuwane.

To jednak nie eliminuje fundamentalnej wady: zarówno dostawca EDM, jak i chmura publiczna działają w modelu, w którym administrator dysponuje wyłącznie nadzorem umownym, a nie architektonicznym. Analiza rynku wskazuje na wyraźne rozróżnienie: umowy AWS i Microsoft dają „umowne ogrodzenie” (contractual perimeter), co nie jest tożsame z fizyczną władzą nad infrastrukturą.

Twoje polityki kluczy i reguły sieciowe ograniczają dostęp, ale są egzekwowane przez tego samego operatora, od którego próbujesz się odizolować.

Ponadto US CLOUD Act pozwala amerykańskim organom wymusić na korporacji z siedzibą w USA wydanie posiadanych zasobów, niezależnie od tego, gdzie fizycznie zlokalizowano dyski. Dla najbardziej wrażliwych rekordów medycznych w UE ten czynnik jurysdykcyjny bywa nieakceptowalny.

Historia uczy, że żadna umowa nie powstrzyma atakującego ani operatora decydującego się na zbyt długie przetrzymywanie kopii. Prawdziwym rozwiązaniem jest repozytorium kontrolowane przez podmiot publiczny – samorząd wojewódzki, Ośrodek Diagnostyki, Profilaktyki i Terapii (ODPiT) lub krajową chmurę medyczną – w którym dysponent ma bezpośredni dostęp do infrastruktury, audytuje logi i weryfikuje, czy nikt nie przetwarza informacji za jego plecami.

Ostrzeżenie: Pacjent pominięty w cyfrowej rewolucji

Obecny kierunek cyfryzacji ochrony zdrowia w Polsce systematycznie pomija właściciela informacji – samego pacjenta. Centralizacja bez narzędzi autoryzacji tworzy środowisko, w którym instytucje mają wgląd we wszystko, a obywatel traci sprawczość. To odwrócenie logiki prawnej.

Chaos w systemie: od teczki do rozproszenia

Pacjent nie posiada jednego, spójnego profilu zdrowotnego. Jego wyniki są rozproszone po setkach silosowych baz – szpitalnych, przychodniowych i komercyjnych. Brak Master Patient Index (MPI) uniemożliwia zarządzanie własną historią w jednym miejscu. Zamiast centralnej ewidencji pod kontrolą obywatela, tworzy się „teczkę w chmurze” bez zamka – informacje gromadzone są masowo, ale chory nie dysponuje narzędziami do decydowania o ich udostępnianiu.

Voicebot i PUI: dostęp dla AI bez zgody pacjenta

Powstają nowe projekty pogłębiające ten stan rzeczy:

• Platforma Usług Inteligentnych (PUI) – modele AI do analizy badań obrazowych i głosu. Podstawowy problem: pacjent nie ma możliwości wyrażenia lub odmowy zgody. To podmioty lecznicze decydują o transferze do analizy, a PUI „nie przechowuje ani nie przetwarza zgód pacjentów”.
• Centralna e-rejestracja z voicebotem – prezes UODO Mirosław Wróblewski wskazał wprost, że przetwarzanie głosu przez sztuczną inteligencję prowadzi do identyfikacji, określenia stanu emocjonalnego, chorób, wieku i płci. To dane biometryczne – jedna z najbardziej chronionych kategorii w RODO. Projekt nie precyzuje, jaki dokładnie zakres będzie przetwarzany, co stwarza ryzyko nadmiarowości.

Kontrola dla instytucji, brak narzędzi dla pacjenta

Sektor bankowy wymaga autoryzacji klienta przy każdej operacji. Zapytania w bazach PESEL pozostawiają ślad. Każdy przedsiębiorca ma program do wystawiania faktur. Dlaczego pominięto właściciela tak newralgicznych informacji, jakimi są dane o zdrowiu?

Nowe plany MC – czy uwzględnią pacjenta?

Ministerstwo Cyfryzacji zapowiada zmiany: certyfikację podmiotów przetwarzających, obowiązek informowania o świadczeniach przez mObywatela i mojeIKP, szybsze powiadamianie o wyciekach. To wciąż udogodnienia dla instytucji. W planach nadal brakuje:

• Master Patient Index – spójnego profilu chorego.
• Rzeczywistej autoryzacji – decydowania o każdym wglądzie.
• Mechanizmów cofania zgód i pełnego wglądu w historię zapytań.

Odpowiedź Polskiego Systemu Zdrowia (PSZ): od „nominalnego zarządzania” do „rzeczywistej kontroli” – i pacjent w centrum

W tym kontekście model Polskiego Systemu Zdrowia oferuję rozwiązanie strukturalne. Jego logika opiera się na fundamencie: dysponent musi mieć rzeczywistą kontrolę nad zawartością baz, a pacjent – realne możliwości zarządzania dostępem do nich.

Powyższa zasada została najmocniej zweryfikowana przez sierpniowy kryzys. Gdyby administrator (np. ZOZ) posiadał własne systemy archiwizacji i backupu (niezależnie od tego, czy lokalnie, czy w regionalnej chmurze publicznej):

• Zakres wycieku byłby zminimalizowany – włamanie do jednego węzła nie uderzyłoby w 12 000 placówek.
• Administrator zyskałby zdolność wykrywania – bezpośrednio monitorowałby logi, zamiast polegać na spóźnionych raportach z zewnątrz.
• Czas 72 godzin byłby w pełni kontrolowany – placówka wiedziałaby o incydencie w momencie jego wystąpienia.
• Rola twórcy oprogramowania stałaby się jasna – dostarcza on wyłącznie narzędzie, ale nie magazynuje kopii i nie pełni funkcji „opiekuna informacji”.

Token zdrowotny zintegrowany z aplikacją mObywatel dopełnia tę koncepcję. Wydawany przez administratora (a nie przez zewnętrzną spółkę IT) pozwala na dynamiczne zarządzanie uprawnieniami i pełne śledzenie ruchu. Pacjent autoryzuje każde żądanie, identycznie jak w bankowości. Token jest jednorazowy, ograniczony czasowo i zakresowo. Widoczny staje się pełny łańcuch: kto go wygenerował, kto użył, do czego uzgodniono wgląd i kiedy uprawnienie wygasło.

Logika PSZ zakłada jasno: właścicielem historii medycznej jest pacjent. Nadszedł czas na program #PacjentwCentrum i #PolskiSystemZdrowia, odwracający dotychczasowe zasady – najpierw zgoda pacjenta na dostęp, a nie wgląd dla instytucji bez pytania o zdanie.

Wnioski dla architektury PSZ

Sierpniowe wydarzenia dostarczają najważniejszych wniosków dla projektowania bezpiecznej infrastruktury w PSZ:

• Po pierwsze, zasoby muszą być deponowane w środowisku zarządzanym bezpośrednio przez administratora lub w architekturze publicznej (regionalna chmura medyczna) podlegającej ścisłemu nadzorowi. Nie na serwerach dostawcy EDM. Nie w globalnej chmurze, której jurysdykcja pozostaje poza zasięgiem krajowych organów.
• Po drugie, token zdrowotny musi być wystawiany przez dysponenta medycznego. Tylko wtedy ma on pełny obraz tego, kto i kiedy odczytuje rekordy, a obywatel zyskuje potężne narzędzie ochrony prywatności.
• Po trzecie, wymiana informacji między ODPiT, ZSMR i ZOZ musi przebiegać w ramach federacji placówek, a nie przez scentralizowany hub podmiotu komercyjnego. W przeciwnym razie odtworzymy schemat, który właśnie zawiódł.
• Po czwarte, województwa powinny budować własne, zintegrowane repozytoria dla podmiotów ze swojego terenu. To jedyny model łączący bezpieczeństwo, trwałość archiwizacji i koordynację regionalną, który skutecznie wypełnia przestrzeń między pojedynczym szpitalem a wielką korporacją IT.
  

Obecny ład funkcjonuje tak wadliwie, ponieważ prawodawca nakłada wymogi, nie dostarczając publicznej infrastruktury. Bez zmiany przepisów szpitale nadal będą zmuszone wybierać między zgodnością z systemem P1 a zachowaniem elementarnego panowania nad własnymi sieciami. Pacjenci pozostaną natomiast narażeni na niebezpieczeństwa, nad którymi nikt realnie nie panuje.

Private 5G i Digital Twin Hospital: izolacja sieciowa i widoczność operacyjna jako fundament bezpieczeństwa

Własne archiwum oraz token to wciąż za mało. Dwa dodatkowe elementy uzupełniają braki, których nie załatają przepisy ani umowy z korporacjami: sieć Private 5G oraz Digital Twin Hospital.

Private 5G – dedykowana sieć kampusowa – pozwala na fizyczne odcięcie krytycznych systemów szpitalnych od publicznego Internetu. Umożliwia tworzenie niezależnych „plastrów sieciowych” (network slicing). Sprzęt ratujący życie (respiratory, pompy infuzyjne, kardiomonitory) działa w całkowicie wyizolowanym segmencie, nieposiadającym żadnej ścieżki routingu do zewnętrznej sieci. Nawet po skutecznym ataku na infrastrukturę biurową szpitala, aparatura medyczna pozostaje dla hakera niewidoczna. Wbudowane mechanizmy uwierzytelniania na poziomie kart SIM eliminują ryzyko podszycia się pod stację roboczą. Dla ochrony prywatności oznacza to, że w razie przełamania zapór w warstwie aplikacji, skradzione pliki nie mogą zostać przetransferowane na zewnątrz.

Z kolei cyfrowy bliźniak szpitala (Digital Twin Hospital) pełni rolę systemu wczesnego ostrzegania. Mapuje lokalizację urządzeń IoT i sprzętu medycznego, ich status i zależności. Gdy jakikolwiek terminal zachowa się nietypowo – spróbuje nawiązać połączenie z nieznanym adresem IP lub zmieni wzorzec ruchu – oprogramowanie natychmiast precyzuje fizyczne położenie (piętro, sala) i szacuje skalę zagrożenia. Zanim dojdzie do transferu gigabajtów na zewnątrz, administrator widzi, skąd wychodzi atak. Bliźniak zapisuje pełną historię zdarzeń, stając się twardym dowodem podczas audytu NIS2 lub kontroli UODO. Musi być jednak rygorystycznie oparty na architekturze Zero Trust.

Zestawienie tych narzędzi tworzy środowisko odporne na działania, których nie powstrzymają żadne klauzule na papierze.

Nadzór nad AI: człowiek w pętli decyzyjnej jako warunek bezpieczeństwa

Izolacja sieciowa nie wystarczy, jeśli algorytmy przetwarzające historie chorób działają poza kontrolą. W koncepcji PSZ każdy agent AI musi funkcjonować w granicach trzech bezwzględnych reguł:

• Po pierwsze, zasada human-in-the-loop (człowiek w pętli decyzyjnej). Najważniejsze rozstrzygnięcia kliniczne pozostają wyłączną domeną personelu. Algorytmy mogą wykrywać anomalie i sugerować rozwiązania, ale nie zastępują lekarza. Odpowiada to wymogom unijnego AI Act. Każda rekomendacja sztucznej inteligencji musi zostać oznaczona komunikatem o konieczności potwierdzenia przez człowieka i trwale zapisana w logach z nazwiskiem weryfikatora.
• Po drugie, pełna przejrzystość. Każde wywołanie modelu AI (chmurowego czy lokalnego) trafia do rejestru AI Governance. Rejestr ten dokumentuje: kto użył narzędzia, co zostało przesłane, jaki otrzymano wynik i jaka była ostateczna decyzja pracownika. Zapobiega to zjawisku „shadow AI”.
• Po trzecie, minimalizacja i maskowanie. Do systemów analitycznych przekazuje się wyłącznie niezbędne minimum parametrów. Cechy identyfikujące (PESEL, personalia) są automatycznie maskowane, chyba że zachodzi wyraźna podstawa prawna i pacjent wyraził na to precyzyjną zgodę. W modelu PSZ proces maskowania przebiega po stronie nadawcy, a nie zewnętrznego dostawcy algorytmu.

Nadzór nad sztuczną inteligencją to integralna część bezpiecznej architektury. Projektowana Rada Strażników miałaby w tej strukturze dbać o to, by uczenie maszynowe nie wykraczało poza ramy etyczne i cel wdrożenia.

Ochrona przed udostępnianiem informacji do AI przez medyków i pacjentów

Najskuteczniejszym zabezpieczeniem jest uczynienie zweryfikowanego algorytmu łatwiejszym w obsłudze niż ogólnodostępnych, niezabezpieczonych aplikacji.

• Problem: wyciek przez czynnik ludzki

Badania Netskope Threat Labs dowodzą, że 81 proc. naruszeń polityk informacyjnych w ochronie zdrowia dotyczyło danych regulowanych, a 44 proc. incydentów związanych z generatywnym AI obejmowało dokładnie ten obszar. Ponad dwie trzecie personelu korzystającego ze sztucznej inteligencji przesyła wrażliwe parametry na prywatne, niekontrolowane konta. Według UODO, „shadow AI” dotyczy aż 54 proc. pracowników posiłkujących się tymi rozwiązaniami w pracy zawodowej. Gdy pliki trafią do otwartego modelu językowego, nie da się ich skutecznie usunąć – mogą posłużyć do trenowania sieci i wypłynąć w odpowiedziach generowanych dla osób trzecich.

• Warstwa techniczna: kontrola przepływu
  

• Filtrowanie wejścia i wyjścia: Systemy klasy DLP (Data Loss Prevention) powinny w czasie rzeczywistym blokować transfer numerów PESEL do otwartych chatbotów.
• Ostrzeżenia w czasie rzeczywistym: Gdy lekarz próbuje wkleić historię choroby do publicznego okna dialogowego, ekran powinien wyświetlić kategoryczne ostrzeżenie. Badania wskazują, że 73 proc. użytkowników po takim komunikacie anuluje operację.
• Zatwierdzone kanały: Placówka musi dostarczyć bezpieczne i monitorowane narzędzie zintegrowane np. z systemem HIS.
  

• Warstwa organizacyjna: procedury

• Rejestr AI Governance: UODO zwraca uwagę, że administratorzy często „nie wiedzą nawet, jakie dane trafiają do AI, nie prowadzą oceny skutków takiego przetwarzania”. Taki rejestr to podstawa wyjścia z chaosu.
• Szkolenia: Unijny AI Act wprowadza pojęcie „AI literacy” – obowiązek edukacji kadr w zakresie możliwości i niebezpieczeństw związanych z uczeniem maszynowym.

• Warstwa pacjenta: świadomość obywatelska
  

Rządowy portal pacjent.gov.pl ostrzega: „Nie przekazuj AI swoich danych”. Algorytmy nie przestrzegają tajemnicy lekarskiej i pozostają poza zasięgiem odpowiedzialności zawodowej. W portalu IKP obywatel powinien dysponować czytelnym rejestrem wglądów, pokazującym również dostęp w trybie ratunkowym, a zgodnie z unijnymi przepisami – mieć prawo do odmowy interwencji diagnostycznej z użyciem AI.

Najważniejszy wniosek dla PSZ

Kategoryczne zakazy korzystania ze sztucznej inteligencji mijają się z celem – medycy i tak użyją jej na prywatnych smartfonach. Trzeba wbudować w systemy kliniczne bezpieczne zamienniki, zautomatyzować maskowanie personaliów w ciągu minionych 12 miesięcy wdrażania standardów, oraz nieustannie przypominać, że otwarty model językowy nie ponosi żadnej odpowiedzialności za powierzone mu sekrety medyczne.

Właścicielem dokumentacji medycznej jest pacjent. Ekosystem pozwalający na jej bezkarne wynoszenie do zewnętrznych sieci odtwarza mechanizm, który właśnie doprowadził do najgłośniejszego wycieku w historii polskiego e-zdrowia. Czas na nowe ramy. Czas na Polski System Zdrowia (PSZ)®.

Składka i podatek na zdrowie – jak uczynić system finansowania ochrony zdrowia bardziej przejrzystym i przewidywalnym w modelu Polskiego Systemu Zdrowia (PSZ)®Polski system ochrony zdrowia boryka się nie tylko z niedoborem pieniędzy. Cierpi przede wszystkim na brak przejrzystości – 72 proc. obywateli odprowadza składkę, pozostałe 28 proc. jest z niej zwolnionych lub koszty ich opieki pokrywa państwo, a sami ubezpieczeni nie wiedzą, gdzie trafiają ich środki.