Aplikacja medyczna: RODO, MDR i certyfikacja — co musisz wiedzieć

Aplikacja medyczna to jeden z niewielu obszarów, w których „zbudujemy szybko MVP i zobaczymy" bywa złym pomysłem. Nie dlatego, że technologia jest trudniejsza — jest podobna. Dlatego, że od pierwszego dnia obowiązują Cię przepisy, których nie da się dołożyć później. Ten artykuł to praktyczna mapa: co realnie musisz spełnić, zanim wypuścisz produkt e-health w Polsce i UE.

1. Dane medyczne to dane szczególnej kategorii

RODO dzieli dane osobowe na zwykłe i te z art. 9 — szczególnej kategorii. Informacje o zdrowiu należą do tych drugich. W praktyce oznacza to, że nie wystarczy „zgoda w regulaminie": potrzebujesz wyraźnej podstawy prawnej, dokumentacji przetwarzania i wyższego standardu zabezpieczeń.

Minimalny zestaw, którego wymaga każdy audyt:

• Szyfrowanie danych w tranzycie (TLS) i w spoczynku (baza, kopie zapasowe).
• Kontrola dostępu i role — lekarz widzi swoich pacjentów, recepcja nie widzi diagnoz, administrator nie czyta danych medycznych bez uzasadnienia.
• Rejestr zdarzeń (audit log) — kto, kiedy i do jakich danych sięgnął. To jedno z pierwszych pytań kontroli.
• Minimalizacja — zbieraj tylko to, co naprawdę potrzebne. Każde dodatkowe pole to dodatkowe ryzyko.
• Umowy powierzenia (DPA) z każdym dostawcą, który dotyka danych: hosting, backup, monitoring, e-mail.

ZAŁOŻENIE, które oszczędza kłopotów: hostuj dane w UE. Chmura poza Europą jest możliwa, ale wymaga standardowych klauzul umownych i analizy transferu — dla małego produktu to niepotrzebna komplikacja.

2. Czy Twoja aplikacja jest wyrobem medycznym?

To pytanie za dziesiątki tysięcy złotych. Rozporządzenie MDR (2017/745) mówi, że oprogramowanie jest wyrobem medycznym, jeśli producent przeznaczył je m.in. do diagnozowania, monitorowania, leczenia lub łagodzenia choroby.

Praktycznie:

• Nie jest wyrobem: rejestracja wizyt, kalendarz gabinetu, przypomnienia SMS, prosty dziennik samopoczucia, portal informacyjny, rozliczenia.
• Jest wyrobem: aplikacja licząca dawkę leku, analizująca EKG lub zdjęcia, sugerująca diagnozę, klasyfikująca ryzyko choroby, sterująca urządzeniem medycznym.

Jeśli produkt jest wyrobem, czeka Cię klasyfikacja (najczęściej klasa IIa dla software'u), system zarządzania jakością (ISO 13485), analiza ryzyka (ISO 14971), ocena kliniczna i jednostka notyfikowana. To proces liczony w miesiącach i w budżecie porównywalnym z samą budową aplikacji — a czasem większym.

Wniosek praktyczny: granicę „wyrób / nie wyrób" ustala przede wszystkim deklarowane przeznaczenie. Dlatego przy pierwszej wersji produktu warto świadomie zostać po bezpiecznej stronie: aplikacja, która „pomaga zapisać pomiary i pokazuje je lekarzowi", to nie to samo, co aplikacja, która „ocenia ryzyko zawału".

3. Cyberbezpieczeństwo i normy techniczne

Nawet poza MDR warto trzymać się standardów, bo szpitale i przychodnie coraz częściej o nie pytają w przetargach:

• ISO 27001 — zarządzanie bezpieczeństwem informacji (formalna certyfikacja bywa wymagana przy większych klientach).
• HL7 / FHIR — standard wymiany danych medycznych; bez niego integracja z systemami szpitalnymi jest bolesna.
• e-recepta, e-skierowanie, P1 — jeśli produkt ma dotykać polskiego ekosystemu, integracja z platformą P1 to osobny, dobrze udokumentowany temat.

4. Ile to kosztuje?

Przy stawkach rynkowych (u nas: programowanie 200 zł/h, design 150 zł/h netto):

5. Od czego zacząć

Zanim napiszesz linijkę kodu, odpowiedz na trzy pytania: jakie dane naprawdę musisz zbierać, czy produkt stawia diagnozę lub podpowiada leczenie oraz kto będzie administratorem danych. Te trzy odpowiedzi decydują o architekturze, budżecie i o tym, czy wejdziesz w ścieżkę MDR.

W CodePort budujemy systemy dla medycyny i e-health właśnie w tej kolejności: najpierw ustalamy zakres regulacyjny, potem projektujemy. Odwrotna kolejność bywa kosztowna.

Ten artykuł ma charakter informacyjny i nie stanowi porady prawnej. Przy projektach objętych MDR współpracuj z konsultantem regulacyjnym.