Przejdź do treści
Umowa powierzenia z dostawcą systemu EDM: co musi zawierać

Poradnik

Umowa powierzenia z dostawcą systemu EDM: co musi zawierać

Placówka medyczna, która wdraża system elektronicznej dokumentacji medycznej (EDM), przekazuje dostawcy dane o zdrowiu wszystkich swoich pacjentów. Od umowy powierzenia zależy, czy po incydencie placówka szybko ustali fakty, zdąży zgłosić naruszenie do UODO w ciągu 72 godzin i odzyska od dostawcy koszty, za które on odpowiada. Wzór dostawcy zwykle spełnia minimum z art. 28 RODO, ale termin zgłoszenia incydentu, audyt, podprzetwarzających i limit odpowiedzialności można negocjować. Wyjaśniam, co musi się znaleźć w umowie i o co prosić przed podpisaniem.

Umowa powierzenia z dostawcą systemu EDM: co musi zawierać

Stan prawny na dzień 2 października 2026 r.

Placówka medyczna, która wdraża system elektronicznej dokumentacji medycznej (EDM), powierza dostawcy oprogramowania dane o stanie zdrowia wszystkich swoich pacjentów. To treść umowy powierzenia decyduje o tym, czy po ewentualnym incydencie bezpieczeństwa placówka sprawnie ustali stan faktyczny, zdąży zgłosić naruszenie do Prezesa UODO w wymaganym terminie 72 godzin i skutecznie odzyska od dostawcy koszty, za które ten ponosi odpowiedzialność. Standardowy wzór przedstawiany przez dostawcę z reguły realizuje jedynie formalne minimum z art. 28 RODO. Kluczowe kwestie, takie jak precyzyjny termin zawiadomienia o incydencie, zasady audytu, dobór podprzetwarzających czy granice odpowiedzialności odszkodowawczej, podlegają jednak negocjacjom. Poniżej wyjaśniam, co bezwzględnie musi znaleźć się w umowie i jak zabezpieczyć interesy placówki przed jej podpisaniem.

Dlaczego umowa powierzenia z dostawcą EDM nie jest formalnością?

Placówka medyczna zachowuje status administratora danych pacjentów. Dostawca oprogramowania EDM występuje co do zasady jako podmiot przetwarzający, czyli procesor, o ile sam nie ustala celów wykorzystania powierzonych mu danych, o czym piszę niżej w sekcji o statusie dostawcy. W taki sam sposób relację administrator-procesor ujmuje kodeks postępowania dla sektora ochrony zdrowia, opracowany pod auspicjami UODO. Zgodnie z art. 28 ust. 1 RODO administrator może korzystać wyłącznie z usług takich podmiotów przetwarzających, które zapewniają wystarczające gwarancje wdrożenia odpowiednich środków technicznych i organizacyjnych. Na placówce spoczywa więc ciężar wykazania, że dokonała świadomego i starannego wyboru kontrahenta oraz sprawuje nad nim realny nadzór.

Sam podpis złożony pod szablonową umową powierzenia nie zwalnia z odpowiedzialności. Trybunał Sprawiedliwości Unii Europejskiej w wyroku z 5 grudnia 2023 r. w sprawie C-683/21 potwierdził, że organ nadzorczy może nałożyć administracyjną karę pieniężną na administratora za operacje przetwarzania wykonane w jego imieniu przez procesora, na przykład za wyciek spowodowany błędem dostawcy. Kara wymaga jednak, by administrator dopuścił się tego naruszenia umyślnie lub nieumyślnie. Odpowiedzialności administratora za działania procesora nie można też rozciągać na sytuacje, w których procesor przetwarzał dane do własnych celów albo w sposób niezgodny z ustalonymi ramami, na co administrator nie mógł rozsądnie się zgodzić. Umowa z dostawcą nie tworzy więc tarczy chroniącej placówkę przed UODO. Zapewnia jej natomiast instrumenty bieżącego nadzoru w trakcie współpracy oraz stanowi formalną podstawę roszczeń regresowych, gdy dojdzie do naruszenia.

Co musi zawierać umowa powierzenia według art. 28 RODO?

Art. 28 ust. 3 RODO określa katalog elementów koniecznych, bez których umowa powierzenia pozostaje prawnie wadliwa. Zapisy te mogą przybrać postać odrębnego porozumienia (DPA), aneksu bądź stanowić część umowy wdrożeniowej czy licencyjnej. Zgodnie z art. 28 ust. 9 RODO umowa wymaga formy pisemnej, przy czym dopuszczalna jest również postać elektroniczna.

Elementy obowiązkowe z art. 28 ust. 3 RODO

  1. 1

    Przedmiot i czas trwania przetwarzania

  2. 2

    Charakter i cel przetwarzania

  3. 3

    Rodzaje danych i kategorie osób

    Opisane dla konkretnego systemu EDM, a nie ogólną formułą.

  4. 4

    Obowiązki i prawa administratora

  5. 5

    Działanie wyłącznie na udokumentowane polecenie

    Dotyczy także przekazywania danych do państw trzecich.

  6. 6

    Tajemnica osób upoważnionych do przetwarzania

  7. 7

    Środki bezpieczeństwa z art. 32 RODO

  8. 8

    Zasady korzystania z podprzetwarzających

  9. 9

    Pomoc przy prawach pacjentów, incydentach i ocenie skutków

    W zakresie obowiązków z art. 32-36 RODO.

  10. 10

    Zwrot albo usunięcie danych po zakończeniu usług

    Według decyzji administratora.

  11. 11

    Informacje i audyty potrzebne do wykazania zgodności

Głównym problemem w praktyce nie bywa całkowite pominięcie któregoś punktu, lecz jego nadmierna ogólnikowość. Klauzula o brzmieniu: „dostawca przetwarza dane osobowe użytkowników zgodnie z przepisami RODO” w żaden sposób nie charakteryzuje systemu, w którym gromadzi się dokumentację medyczną, dane o stanie zdrowia, e-recepty, skierowania, grafik wizyt czy dane opiekunów prawnych i personelu. Każda z tych kategorii powinna znaleźć odzwierciedlenie w załączniku, wraz z wyszczególnieniem grup osób, których dane dotyczą: pacjentów, ich przedstawicieli ustawowych oraz pracowników medycznych. Precyzja tego opisu bezpośrednio rzutuje na późniejszy zakres uprawnień audytowych, obowiązki informacyjne po incydencie oraz procedurę bezpiecznego usuwania danych.

W jakim terminie dostawca EDM musi zgłosić incydent?

W przepisach RODO nie określono sztywnego terminu godzinowego dla dostawcy. Zgodnie z art. 33 ust. 2 RODO podmiot przetwarzający ma obowiązek zawiadomić administratora o naruszeniu ochrony danych „bez zbędnej zwłoki”. Z perspektywy placówki to stanowczo zbyt mało: administrator musi zgłosić incydent organowi nadzorczemu, w miarę możliwości, w ciągu 72 godzin od jego stwierdzenia (art. 33 ust. 1 RODO), a po upływie tego czasu jest zobowiązany podać przyczyny zwłoki. Jeśli dostawca uzna, że dwie doby mieszczą się w pojęciu „bez zbędnej zwłoki”, placówce medycznej pozostanie zaledwie jeden dzień na weryfikację zdarzenia, ocenę ryzyka naruszenia praw pacjentów, przygotowanie zgłoszenia i formalne zawiadomienie UODO.

Z tego względu warto wprowadzić do umowy precyzyjny termin liczony w godzinach oraz podzielić proces raportowania na etapy. Ponieważ art. 33 ust. 4 RODO wprost zezwala na sukcesywne przekazywanie informacji organowi nadzorczemu, etapowy model współpracy z dostawcą w pełni odpowiada logice przepisów.

Procedura zgłaszania incydentu przez dostawcę EDM

1

Etap 1

Zawiadomienie alarmowe

Kanał dostępny całą dobę, wskazane osoby po obu stronach.

cel negocjacyjny do 12 godzin od wykrycia
2

Etap 2

Informacja wstępna

Rodzaj incydentu, dotknięte systemy, kategorie danych, placówki objęte zdarzeniem i działania ograniczające skutki.

3

Etap 3

Aktualizacje

Uzupełnienia w rytmie ustalonym w umowie, aż do zamknięcia incydentu.

4

Etap 4

Raport końcowy

Przyczyna źródłowa, zakres danych, ocena skutków i plan naprawczy.

Procedurą raportowania należy objąć nie tylko potwierdzony wyciek informacji, lecz także każdą nieplanowaną utratę dostępności systemu. Podmiot leczniczy, który przez kilkanaście godzin traci dostęp do historii chorób pacjentów, nie jest w stanie bezpiecznie udzielać świadczeń medycznych – nawet jeśli dane nie dostały się w niepowołane ręce.

Równie istotna jest organizacja procesu wewnątrz samej placówki. Zgłoszenie otrzymane od dostawcy nie zdejmuje z administratora obowiązku przeprowadzenia samodzielnej oceny ryzyka. W umowie należy jednoznacznie wskazać dedykowany adres e-mail i numer telefonu do zgłoszeń kryzysowych. Personel placówki musi z kolei dokładnie wiedzieć, kto po odebraniu alertu natychmiast zawiadamia inspektora ochrony danych, kadrę zarządzającą, administratorów IT oraz osoby koordynujące komunikację z pacjentami.

Jak zapisać prawo do audytu dostawcy?

Art. 28 ust. 3 lit. h RODO nakłada na podmiot przetwarzający obowiązek udostępnienia administratorowi wszelkich informacji niezbędnych do wykazania spełnienia obowiązków, a także umożliwienia przeprowadzania audytów, w tym inspekcji. W odpowiedzi dostawcy EDM często dążą do ograniczenia tych uprawnień, proponując w zamian przedstawienie certyfikatu branżowego, raportu niezależnego audytora czy wypełnienie kwestionariusza samooceny. W przypadku usług świadczonych w chmurze obliczeniowej bywa to racjonalny pierwszy krok, zwłaszcza że art. 28 ust. 5 RODO dopuszcza posługiwanie się certyfikacją lub zatwierdzonym kodeksem postępowania jako elementem wykazania gwarancji bezpieczeństwa. Nie należy jednak godzić się na klauzule, które całkowicie wyłączają prawo do audytu bądź sprowadzają je wyłącznie do weryfikacji ważności certyfikatu.

Prawidłowo skonstruowana klauzula audytowa przewiduje dwa niezależne tryby. Tryb zwyczajny dotyczy na przykład jednego planowego audytu w roku, prowadzonego zdalnie po odpowiednim uprzedzeniu dostawcy. Tryb nadzwyczajny uruchamia się bezpośrednio po wystąpieniu incydentu, przy uzasadnionym podejrzeniu naruszenia poufności danych lub na formalne żądanie UODO. W takich przypadkach umowa powinna dopuszczać możliwość kontroli na miejscu, o ile pozostaje ona proporcjonalna i konieczna wobec okoliczności, z zachowaniem zabezpieczeń informacji innych klientów dostawcy. Postanowienia umowne muszą również wyznaczać termin na usunięcie stwierdzonych uchybień oraz przyznawać placówce uprawnienie do weryfikacji wykonania zaleceń. Gdy dostawca kategorycznie odmawia jakiejkolwiek formy audytu, rozsądnym minimum jest wyegzekwowanie raportu niezależnego audytora oraz zagwarantowanego prawa do audytu na miejscu po każdym incydencie.

Placówka nie potrzebuje wglądu w całą infrastrukturę serwerową partnera. Zakres kontroli powinien koncentrować się na zasobach przetwarzających jej własne dane: mechanizmach uwierzytelniania, kontroli uprawnień, logach systemowych, kopiach zapasowych, ścieżkach obsługi awarii, doborze podwykonawców oraz ewentualnych transferach danych poza Europejski Obszar Gospodarczy. Wymogi techniczne najbezpieczniej ująć w dedykowanym załączniku bezpieczeństwa. Powinny się w nim znaleźć: uwierzytelnianie wieloskładnikowe (MFA), szyfrowanie danych w spoczynku i w transmisji, harmonogram testów odtworzeniowych, dopuszczalny czas przywrócenia działania systemu (RTO) i dopuszczalną utratę danych (RPO) oraz zasady dostępu serwisowego. Ten ostatni wymóg dotyczy w równej mierze samej placówki: udostępnienie dostawcy konta z uprawnieniami administratora bez MFA i bez rejestrowania zdarzeń przekreśla nawet najbardziej rygorystyczne zapisy umowne.

Jak kontrolować podprzetwarzających dostawcy EDM?

Dostawcy systemów EDM rzadko operują w całkowicie zamkniętej infrastrukturze. Niemal zawsze korzystają z usług podmiotów trzecich: operatorów chmury obliczeniowej, centrów kolokacyjnych, dostawców bram e-mail, zewnętrznych zespołów wsparcia technicznego czy narzędzi telemetrycznych. Art. 28 ust. 2 RODO zezwala na angażowanie innych podmiotów przetwarzających (tzw. podprzetwarzających) wyłącznie pod warunkiem uzyskania uprzedniej szczegółowej lub ogólnej pisemnej zgody administratora. Przy zgodzie ogólnej dostawca ma obowiązek powiadomić placówkę o wszelkich planowanych zmianach dotyczących dodania lub zastąpienia takich podmiotów, dając jej realną możliwość wyrażenia sprzeciwu.

W praktyce najlepiej sprawdza się model mieszany: szczegółowa zgoda na podmioty o znaczeniu krytycznym (w szczególności dostawcę infrastruktury chmurowej i centrum danych) oraz zgoda ogólna na pozostałych usługodawców, połączona z obowiązkiem każdorazowego, uprzedniego zawiadomienia. Placówka powinna dysponować jawnym, imiennym wykazem podwykonawców z określeniem ich roli, lokalizacji serwerów oraz wskazaniem, czy dochodzi do transferu danych poza EOG. Na wniesienie ewentualnego sprzeciwu dobrze jest zagwarantować sobie minimum 30 dni, choć to cel negocjacyjny, nie ustawowe minimum. Ponieważ art. 28 ust. 3 lit. a RODO wymaga udokumentowanego polecenia administratora także przy przekazywaniu danych do państw trzecich, świadczenie zdalnego serwisu technicznego spoza terenu EOG musi mieć bezpośrednie umocowanie w umowie. Sam transfer poza EOG wymaga dodatkowo podstawy z rozdziału V RODO, najczęściej standardowych klauzul umownych, rzadziej decyzji Komisji Europejskiej stwierdzającej odpowiedni stopień ochrony. Przy standardowych klauzulach umowa powinna zobowiązywać dostawcę do oceny faktycznego poziomu ochrony w państwie docelowym i do wdrożenia dodatkowych zabezpieczeń zgodnie z rekomendacjami EROD 01/2020.

Samo prawo sprzeciwu pozostaje iluzoryczne, jeżeli umowa milczy o jego konsekwencjach. Kontrakt powinien wprost przewidywać, że w razie uzasadnionego sprzeciwu placówka może zażądać utrzymania dotychczasowych warunków świadczenia usługi albo wypowiedzieć umowę z zachowaniem prawa do bezpiecznej migracji zasobów. Art. 28 ust. 4 RODO nakazuje nałożenie na podprzetwarzającego tych samych obowiązków ochrony danych, jakie spoczywają na głównym procesorze. Jeżeli podprzetwarzający nie wywiąże się z tych obowiązków, pełną odpowiedzialność wobec administratora za ich wypełnienie ponosi pierwotny dostawca. Zapis ten warto powtórzyć w umowie wprost, uzupełniając go o uprawnienie placówki do wglądu w treść porozumień powierzenia zawartych z kluczowymi podwykonawcami.

Co wynegocjować w umowie powierzenia EDM ponad minimum z RODO?

Poniższe zestawienie ilustruje granicę między literalnym brzmieniem przepisów a praktyczną przestrzenią do negocjacji biznesowych. Prawa kolumna wskazuje optymalne cele, z którymi placówka medyczna powinna przystępować do rozmów. Ostateczny kompromis zależy od skali podmiotu leczniczego, modelu architektury systemu oraz pozycji rynkowej dostawcy.

Minimum z RODO a cel negocjacyjny placówki
Minimum z RODO Cel negocjacyjny placówki
Incydent Zgłoszenie administratorowi bez zbędnej zwłoki Do 12 godzin od wykrycia, kanał alarmowy 24/7, informacja wstępna i aktualizacje
Audyt Informacje i audyty, w tym inspekcje Audyt roczny zdalny, audyt na miejscu po incydencie, termin usunięcia niezgodności
Podprzetwarzający Uprzednia zgoda szczegółowa albo ogólna z prawem sprzeciwu Imienna lista, lokalizacja danych, 30 dni na sprzeciw, prawo wypowiedzenia z migracją
Bezpieczeństwo Środki z art. 32 RODO Załącznik bezpieczeństwa z MFA, szyfrowaniem, logami, kopiami, RTO i RPO
Zakończenie współpracy Zwrot albo usunięcie danych według decyzji administratora Format eksportu, wsparcie migracyjne, termin, potwierdzenie usunięcia, zasady dla kopii zapasowych
Odpowiedzialność Odpowiedzialność wobec pacjenta z art. 82 RODO Regres wobec dostawcy, współpraca w sporach, roszczenia RODO poza ogólnym limitem

Kto zapłaci za incydent po stronie dostawcy?

Pacjent, który poniósł szkodę majątkową lub niemajątkową, może dochodzić odszkodowania bezpośrednio od administratora albo od procesora (art. 82 ust. 1 RODO). Samo naruszenie RODO nie wystarczy. Trybunał Sprawiedliwości UE w wyroku z 4 maja 2023 r. w sprawie C-300/21 potwierdził, że prawo do odszkodowania wymaga trzech łącznych warunków: naruszenia przepisów, rzeczywiście poniesionej szkody i związku przyczynowego między nimi. Odpowiedzialność procesora jest przy tym węższa niż administratora, ponieważ odpowiada on tylko za niedopełnienie obowiązków nałożonych wprost na procesorów albo za działanie poza instrukcjami administratora lub wbrew nim (art. 82 ust. 2 RODO). Każdy z nich, administrator i procesor, może się też w całości zwolnić z odpowiedzialności, jeżeli udowodni, że w żaden sposób nie ponosi winy za zdarzenie wywołujące szkodę (art. 82 ust. 3 RODO).

Jeżeli w tym samym przetwarzaniu uczestniczą oba podmioty i zgodnie z zasadami z ust. 2 i 3 odpowiadają za szkodę, ich odpowiedzialność wobec pacjenta jest solidarna: pacjent odbiera całość odszkodowania od tego podmiotu, do którego zgłosił żądanie, niezależnie od wewnętrznego podziału winy (art. 82 ust. 4 RODO). Dopiero ten, kto zapłacił pacjentowi w całości, może zażądać od drugiego podmiotu zwrotu części odpowiadającej jego udziałowi w odpowiedzialności (art. 82 ust. 5 RODO). Innymi słowy, to placówka płaci pacjentowi najpierw, jeżeli to ją pozwano, a dopiero potem odzyskuje od dostawcy jego część, o ile pozwala na to umowa i stan faktyczny.

Karę administracyjną UODO nakłada odrębnie, na zasadach z art. 83 RODO, zwykle na administratora, czyli na placówkę, w granicach, które wyznacza wyrok C-683/21 opisany wyżej. Kto ostatecznie poniesie ekonomiczny ciężar takiej kary, jeżeli jej przyczyną było zaniedbanie dostawcy, rozstrzyga umowa i ogólne zasady prawa cywilnego, a nie samo RODO.

Lakoniczny zapis: „dostawca ponosi odpowiedzialność na zasadach ogólnych kodeksu cywilnego” nie zapewnia placówce dostatecznej ochrony. Umowa powinna wprost rozstrzygać, kto pokrywa koszty obsługi technicznej i prawnej incydentu oraz wydatki związane z powiadomieniem poszkodowanych, gdy przyczyna zdarzenia leżała po stronie dostawcy. Powinna też zobowiązywać go do aktywnego współdziałania w sporach, w tym do niezwłocznego przekazywania logów, zrzutów pamięci i innych materiałów dowodowych. Skuteczność takich zapisów wobec kary UODO czy odszkodowania wypłaconego pacjentowi zależy każdorazowo od ich treści, przyczyny kary i ogólnych zasad prawa cywilnego, nie od samego faktu wpisania ich do umowy.

Kluczowym punktem spornym bywają umowne limity odpowiedzialności dostawcy. W standardowych wzorach ograniczają one odpowiedzialność do równowartości kilkumiesięcznego wynagrodzenia abonamentowego, co przy naruszeniu poufności całej bazy dokumentacji medycznej nie pokryje nawet ułamka kosztów zarządzania kryzysowego. Placówka powinna dążyć do wyłączenia spod tego limitu szkód wynikających z naruszenia zasad ochrony danych, rażącego niedbalstwa w obszarze bezpieczeństwa oraz zaangażowania nieautoryzowanych podwykonawców. Takiego limitu nie obejmie zresztą nigdy szkoda wyrządzona umyślnie: zastrzeżenie wyłączające odpowiedzialność za szkodę umyślną jest nieważne z mocy art. 473 § 2 kodeksu cywilnego. Gdy dostawca kategorycznie odrzuca odpowiedzialność pełną, dopuszczalnym kompromisem bywa osobny, odpowiednio wysoki limit dedykowany naruszeniom ochrony danych, połączony z obowiązkiem pokrycia udokumentowanych wydatków zewnętrznych.

Czego uczy incydent dotyczący systemu MyDr o umowie powierzenia?

Toczące się postępowanie w sprawie incydentu cyberbezpieczeństwa u dostawcy systemu MyDr pokazuje te ryzyka kontraktowe w praktyce, niezależnie od tego, jak zostanie ostatecznie rozstrzygnięta odpowiedzialność poszczególnych podmiotów. W związku ze zdarzeniem oficjalne komunikaty publikowało Ministerstwo Zdrowia, a Prokuratura Okręgowa w Warszawie informowała o prowadzeniu postępowań przygotowawczych w przedmiocie bezprawnego pozyskania danych z oprogramowania. Ocena odpowiedzialności karnej i cywilnej należy do organów ścigania oraz sądów, nie do komunikatów prasowych.

Sam mechanizm problemu pozostaje jednak uniwersalny. W sytuacji, gdy jeden system chmurowy obsługuje setki placówek medycznych, każdy administrator staje przed koniecznością natychmiastowego pozyskania zindywidualizowanych informacji: czy incydent objął jego pacjentów, jakich danych dotyczy wyciek, w jakim przedziale czasowym trwało naruszenie, jakie kroki mitygujące wdrożono oraz jakimi dowodami dysponuje dostawca. Jeśli umowa nie precyzuje ram czasowych ani szczegółowości takich raportów, placówka medyczna otrzymuje jedynie lakoniczne komunikaty prasowe, podczas gdy nieubłaganie upływa jej ustawowy, 72-godzinny termin na powiadomienie Prezesa UODO. Praktyczny wniosek na przyszłość brzmi: żądać od dostawcy odrębnego raportu incydentu dla każdej placówki z osobna oraz całodobowego kanału alarmowego, zanim dojdzie do zdarzenia, nie dopiero w jego trakcie.

Co z danymi po zakończeniu umowy z dostawcą EDM?

Zgodnie z art. 28 ust. 3 lit. g RODO podmiot przetwarzający ma obowiązek, zależnie od decyzji administratora, usunąć lub zwrócić wszelkie dane osobowe po zakończeniu świadczenia usług, jak również usunąć ich istniejące kopie, chyba że prawo Unii lub prawo krajowe nakazuje ich dalsze przechowywanie. W sektorze ochrony zdrowia przepis ten ma kluczowe znaczenie: placówka medyczna jest ustawowo zobowiązana do wieloletniej, co do zasady dwudziestoletniej archiwizacji dokumentacji medycznej (art. 29 ust. 1 ustawy o prawach pacjenta i Rzeczniku Praw Pacjenta). Wypowiedzenie umowy przez dostawcę w żadnym stopniu nie uchyla tego wymogu prawnego.

Zapisy kontraktowe muszą zatem gwarantować, że pełne repozytorium danych zostanie bezpiecznie przekazane placówce lub wskazanemu nowemu dostawcy oprogramowania, zanim pierwotny kontrahent zainicjuje jakiekolwiek procedury kasowania. Przedmiotem precyzyjnych uzgodnień powinny być: otwarty, powszechnie stosowany format eksportu dokumentacji, ramy czasowe oraz cennik wsparcia migracyjnego, termin bezpowrotnego usunięcia danych z infrastruktury dostawcy potwierdzony pisemnym protokołem, a także zasady retencji i wymazywania kopii zapasowych, które z przyczyn technicznych funkcjonują dłużej niż środowisko produkcyjne. Brak tych postanowień ujawnia się zwykle w momencie zmiany oprogramowania, gdy pozycja przetargowa placówki jest najsłabsza.

Czy dostawca EDM zawsze jest tylko procesorem?

Nie w każdym przypadku. To jeden z częstszych błędów przy kwalifikacji prawnej współpracy z dostawcą. Europejska Rada Ochrony Danych w wytycznych 07/2020 podkreśla, że o statusie podmiotu decyduje nie nazwa umowy, lecz faktyczny wpływ na ustalanie celów i istotnych sposobów przetwarzania. Jeżeli dostawca systemu samodzielnie decyduje o wykorzystaniu danych pacjentów do własnych analiz statystycznych, ulepszania komercyjnych algorytmów czy trenowania modeli sztucznej inteligencji, w tym zakresie może zacząć działać jako samodzielny administrator danych, niezależnie od tego, jak strony nazwały go w umowie. Samo trenowanie modeli AI na powierzonych danych nie przesądza więc automatycznie o takim statusie: decyduje to, czy dostawca faktycznie i samodzielnie ustala cele oraz istotne sposoby tego konkretnego przetwarzania. Z art. 28 ust. 10 RODO wynika wprost, że procesor, który z naruszeniem przepisów sam decyduje o celach i sposobach operacji na danych, uzyskuje status administratora w odniesieniu do tego przetwarzania.

Sama standardowa umowa powierzenia nie sankcjonuje takiego stanu rzeczy. W dobie wdrażania rozwiązań EDM wspomaganych przez narzędzia AI rekomenduję wprowadzenie jednoznacznej klauzuli zakazującej dostawcy wykorzystywania danych powierzonych przez placówkę do trenowania modeli oraz rozwijania własnych produktów, chyba że strony wynegocjują odrębne porozumienie z precyzyjną podstawą prawną. Wszelkie dodatkowe funkcjonalności wykraczające poza bieżące prowadzenie dokumentacji medycznej wymagają indywidualnej analizy ryzyka przed ich uruchomieniem.

Pięć kroków przed podpisaniem umowy powierzenia

Przed podpisaniem umowy z dostawcą EDM

  1. 1

    Opisz rzeczywisty przepływ danych

    Kategorie danych i osób, moduły systemu, integracje i miejsca przetwarzania.

  2. 2

    Porównaj wzór dostawcy z art. 28 ust. 3 RODO

    Każdy element obowiązkowy musi mieć konkretną treść, a nie odesłanie do przepisów.

  3. 3

    Wpisz termin i etapy zgłaszania incydentu

    Liczba godzin, kanał alarmowy i zakres informacji wstępnej.

  4. 4

    Sprawdź listę podprzetwarzających i limit odpowiedzialności

    Imienna lista, termin sprzeciwu, roszczenia RODO poza ogólnym limitem.

  5. 5

    Powiąż dokumenty

    Umowa powierzenia, umowa wdrożeniowa, SLA, regulamin usługi i polityka kopii zapasowych muszą mówić to samo.

Przegląd umowy powierzenia przy wdrożeniu EDM

Jeżeli planujesz wdrożenie lub zmianę systemu EDM w swojej placówce, pomagam w kompleksowej weryfikacji umowy powierzenia przetwarzania danych wraz z umową wdrożeniową, porozumieniem SLA oraz warunkami migracji danych. Zwracam uwagę na to, by obowiązki nałożone na dostawcę były w pełni egzekwowalne również w sytuacji kryzysowej. Rekomendacje przygotowuję w formie konkretnych propozycji zmian redakcyjnych do wzoru przedstawionego przez dostawcę, bezpośrednio gotowych do podjęcia negocjacji. Wspieram podmioty lecznicze w całym obszarze compliance medycznego, ochrony danych osobowych, audytu procedur wewnętrznych oraz bezpiecznego wdrażania narzędzi opartych na AI. Skontaktuj się ze mną przez formularz kontaktowy.

Tekst ma charakter informacyjny i nie zastępuje indywidualnej porady prawnej.

Źródła

  • Rozporządzenie (UE) 2016/679 (RODO), tekst w EUR-Lex, w tym art. 28, 32, 33 i 82. link

  • Ustawa z dnia 6 listopada 2008 r. o prawach pacjenta i Rzeczniku Praw Pacjenta, art. 29, tekst jednolity Dz.U. 2024 poz. 581. link

  • Ustawa z dnia 28 kwietnia 2011 r. o systemie informacji w ochronie zdrowia, tekst jednolity Dz.U. 2026 poz. 208. link

  • Rozporządzenie Ministra Zdrowia w sprawie rodzajów, zakresu i wzorów dokumentacji medycznej oraz sposobu jej przetwarzania, tekst jednolity Dz.U. 2024 poz. 798. link

  • Ustawa z dnia 23 kwietnia 1964 r. Kodeks cywilny, art. 473 § 2 (nieważność wyłączenia odpowiedzialności za szkodę umyślną). link

  • UODO, kodeks postępowania dla sektora ochrony zdrowia, rola placówki jako administratora i dostawcy jako procesora. link

  • EROD, wytyczne 07/2020 w sprawie pojęć administratora i podmiotu przetwarzającego w RODO. link

  • EROD, rekomendacje 01/2020 w sprawie środków uzupełniających narzędzia transferu danych poza EOG. link

  • TSUE, wyrok w sprawie C-683/21, odpowiedzialność administratora za operacje procesora. link

  • TSUE, komunikat prasowy o wyroku w sprawie C-683/21. link

  • TSUE, wyrok w sprawie C-300/21 (Österreichische Post), przesłanki prawa do odszkodowania z art. 82 RODO. link

  • Ministerstwo Zdrowia, informacja w związku z incydentem dotyczącym firmy MyDr. link

  • Prokuratura Okręgowa w Warszawie, informacja o postępowaniach przygotowawczych w sprawie danych z systemu MyDr. link

Powiązane materiały

Dalsze lektury z podobnym kontekstem odbiorcy lub kategorii.