Szeroko rozumiana branża zdrowotna to potężny rynek dla innowacji. Jednocześnie jednak jest to rynek mocno regulowany, na którym trzeba działać z konkretnym planem. Kiedy tworzysz innowacje medyczne, musisz uwzględnić wiele aspektów, od których będą zależeć Twoje obowiązki wynikające z różnych aktów prawnych.
Często scenariusz wygląda tak, że najpierw pojawia się pomysł, potem powstaje produkt (np. aplikacja), a dopiero na końcu przychodzi refleksja dotycząca tego, w jakich ramach prawnych trzeba będzie działać. Naprawdę warto zaplanować cały proces inaczej i o potencjalnych obowiązkach pomyśleć zanim jeszcze powstaną pierwsze linijki kodu.
Niezależnie od tego, czy tworzysz innowacyjne rozwiązanie dla pacjentów, czy produkt, który będzie wspierał lekarzy, musisz zadać sobie kilka kluczowych pytań prawnych. To właśnie je znajdziesz w tym tekście.
1. Czy moje innowacje medyczne to jednocześnie wyroby medyczne?
Kiedy pojawia się genialny pomysł na wsparcie lekarzy lub pacjentów nowoczesnym oprogramowaniem, określenie „wyrób medyczny” często w ogóle nie pada. Twórca takiego innowacyjnego rozwiązania jest przekonany, że będzie jedynie dostarczał narzędzie pomocnicze. Nie produkuje przecież nowego leku czy robota, który asystuje przy operacji. Tymczasem sprawa może nie być taka prosta.
Załóżmy, że tworzysz samodzielnie działającą aplikację, która nie jest częścią żadnego urządzenia medycznego. Wiesz już, że także oprogramowanie może zostać zakwalifikowane jako wyrób medyczny. I wpadasz na pomysł, że być może Twoje oprogramowanie też.
Jak sprawdzić, czy faktycznie jest taka możliwość?
Najważniejszym aktem prawnym regulującym kwestie wyrobów medycznych jest Rozporządzenie 2017/745. Komisja Europejska wydała też wytyczne, które pomagają twórcom oprogramowania stwierdzić, czy powinno ono być klasyfikowane jako wyrób medyczny. Żeby to ustalić trzeba przeanalizować kilka kwestii.
Krok 1: Czy Twoja aplikacja aktywnie przetwarza dane?
Oprogramowanie nie jest wyrobem medycznym, jeśli jego jedynym zadaniem jest:
- przechowywanie danych (archiwizacja),
- przesyłanie informacji z punktu A do punktu B (komunikacja),
- proste wyszukiwanie wpisanych wcześniej informacji,
- bezstratna kompresja plików.
Jeżeli więc stworzona przez Ciebie aplikacja służy tylko jako magazyn danych, nie będzie ona wyrobem medycznym. Jeżeli jednak wykonuje też dodatkowe operacje, np. analizuje dane, interpretuje wyniki czy wylicza jakieś prawdopodobieństwo, musisz przejść do kolejnego kroku.
Krok 2: Czy działanie aplikacji służy konkretnemu pacjentowi?
Nawet jeśli aplikacja dokonuje skomplikowanych obliczeń, musi to robić w odniesieniu do indywidualnej osoby. Oprogramowanie nie jest wyrobem medycznym, jeśli służy jedynie do:
- agregacji i analizy ogólnych danych statystycznych o populacji,
- badań epidemiologicznych (np. śledzenie rozprzestrzeniania się wirusa bez dawania rekomendacji jednostkom),
- udostępniania wiedzy (np. cyfrowe atlasy medyczne, zbiory literatury naukowej, ogólne ścieżki leczenia bez personalizacji).
Program musi przetwarzać dane po to, aby pomóc w diagnozie, monitorowaniu lub leczeniu konkretnego pacjenta.
Krok 3: Czy aplikacja ma cel medyczny?
Jeśli dotarłeś tutaj, to znaczy, że masz samodzielny program, który aktywnie przetwarza dane z korzyścią dla indywidualnego pacjenta.
Ostatnim krokiem jest ustalenie czy aplikacja ma cel medyczny. Chodzi m.in. o: diagnozowanie, profilaktykę, monitorowanie, przewidywanie, prognozowanie, leczenie lub łagodzenie przebiegu choroby.
Ten krok bywa w praktyce najtrudniejszy. Często np. trudno ustalić, gdzie kończy się edukowanie, a zaczyna profilaktyka lub nawet diagnoza.
Innowacje w medycynie i działanie dwuetapowe
Częstą strategią, jeśli chodzi o innowacje w medycynie, jest działanie dwuetapowe. Pierwszy krok to stworzenie aplikacji lifestylowej (wellness), której celem nie jest leczenie, a jedynie dbanie o szeroko rozumiany dobrostan i kondycję. Jeżeli ten pomysł „chwyci”, a twórcy zbiorą bazę użytkowników i finansowanie, stopniowo dodawane są kolejne funkcje, które przesuwają aplikację w stronę wyrobu medycznego.
PRZYKŁAD 1: Tworzysz aplikację do analizy snu. W wersji pierwszej (wellness) aplikacja mierzy czas snu i budzi użytkownika w fazie płytkiej. To funkcja lifestylowa. W wersji drugiej producent dodaje algorytm analizujący dźwięki chrapania pod kątem wykrywania bezdechu sennego i sugeruje wizytę u pulmonologa. W tym momencie aplikacja staje się wyrobem medycznym.
PRZYKŁAD 2: Tworzysz aplikację, która przypomina jej użytkownikowi, że musi wziąć konkretny lek. Aplikacja wysyła dane do kalendarza, dodatkowo można ustawić alarm z przypomnieniem. To funkcja lifestylowa. Jeżeli jednak do aplikacji dodasz funkcję kalkulatora, który na podstawie wagi użytkownika i wyników jego badań będzie precyzyjnie wyliczał dawkę leku, aplikacja stanie się wyrobem medycznym.
Masz innowacje w medycynie jako wyroby medyczne – co dalej?
Jeżeli już wiesz, że Twój program to wyrób medyczny, masz w związku z tym określone obowiązki.
Przede wszystkim musisz ustalić klasę ryzyka swojego wyrobu (Klasa I, IIa, IIb lub III). Niewiele aplikacji medycznych można zaliczyć do najniższej Klasy I. Większość rozwiązań trafia do Klasy IIa lub wyższej.
W takim przypadku nie możesz się certyfikować sam, potrzebny będzie udział Jednostki Notyfikowanej. Jako producent wyrobu medycznego powinieneś wdrożyć formalny system zarządzania jakością, który obejmuje całą Twoją firmę. Standardem rynkowym jest norma ISO 13485. Wymaga ona udokumentowania wszystkich procesów w firmie – od rekrutacji programistów, przez pisanie kodu, aż po obsługę reklamacji.
Żeby uzyskać certyfikację musisz też udowodnić, że Twoja aplikacja faktycznie działa i robi to bezpiecznie. Wymaga to sporządzenia Raportu z Oceny Klinicznej (CER). Może to wymagać dogłębnego przeglądu literatury naukowej, ale często też przeprowadzenia badań klinicznych z udziałem pacjentów. Przed wypuszczeniem aplikacji konieczne jest stworzenie obszernej dokumentacji technicznej.
2. Czy będę stawiać diagnozy i wydawać zalecenia?
To drugie fundamentalne pytanie. Dotyczy ono modelu biznesowego i tego, jak bardzo „wchodzisz” w buty lekarza lub przychodni.
Scenariusz, gdzie Ty udzielasz świadczenia zdrowotnego
PRZYKŁAD 1: Tworzysz platformę, na której pacjent opisuje swoje objawy. Na podstawie informacji od pacjenta Twój system paruje go z lekarzem. Ty odpowiadasz za umówienie wizyty i pobierasz opłatę we własnym imieniu. Lekarz prowadzi dokumentację medyczną w dostarczonym przez Ciebie systemie, w tym systemie wystawia też e-receptę.
W tym scenariuszu Ty organizujesz udzielanie świadczenia zdrowotnego i Ty ponosisz za nie odpowiedzialność. Jesteś też administratorem danych pacjentów. Nawet, jeżeli formalnie nie zarejestrowałeś się jako podmiot wykonujący działalność leczniczą, to w praktyce właśnie jako taki podmiot działasz.
Scenariusz, gdzie za świadczenie zdrowotne odpowiada lekarz
PRZYKŁAD 2: Tworzysz platformę, na której pacjent opisuje swoje objawy. Objawy te są analizowane przez algorytm (wyrób medyczny) dostarczony przez podmiot trzeci. Ty dajesz tylko przestrzeń, gdzie pacjent może skorzystać z tego algorytmu. Dodatkowo dajesz pacjentowi możliwość umówienia się z lekarzem, z którym może skonsultować wynik wygenerowany przez algorytm. I tu znowu – Ty dostarczasz tylko narzędzie (kalendarz rezerwacji). Za samo udzielenia świadczenia odpowiada konkretny lekarz.
W tym scenariusz Twoja rola ogranicza się do udostępniania platformy cyfrowej dla niezależnych praktyk lekarskich lub placówek medycznych. Nie jesteś odpowiedzialny za proces leczenia, archiwizację dokumentacji czy zgłoszenia rejestrowe. Działalność leczniczą prowadzi konkretny lekarz czy podmiot leczniczy i to na nim spoczywają związane z tym obowiązki.
W Polsce działalność lecznicza jest regulowana – jeżeli prowadzisz ją bez wpisu do odpowiedniego rejestru, narażasz się na konkretne kary finansowe. Zdecydowanie warto przeanalizować, w jakich rolach występujesz i podjąć odpowiednie działania, aby robić to zgodnie z prawem.
Rejestracja podmiotu leczniczego nie jest ani skomplikowana, ani kosztowna. Wniosek składany jest elektronicznie, a po jego pozytywnym rozpatrzeniu wnioskodawca wpisywany jest do Rejestru Podmiotów Wykonujących Działalność Leczniczą. Podmioty takie mają określone obowiązki, np. związane z prowadzeniem dokumentacji medycznej, przestrzeganiem praw pacjenta czy posiadaniem ubezpieczenia OC.
3. Kto będzie ponosił odpowiedzialność za błędne działanie mojego rozwiązania?
Co się stanie, jeśli system zawiedzie i pacjent ucierpi? Te pytania spędzają sen z powiek zarówno twórcom innowacji w medycynie, jak i korzystającym z nich lekarzom. W dużym uproszczeniu odpowiedź brzmi: to zależy, kto zawinił – technologia czy człowiek.
Kiedy odpowiada producent?
Jeśli błąd w Twoim oprogramowaniu wyrządzi szkodę pacjentowi (np. doprowadzi do uszczerbku na zdrowiu lub śmierci), poniesiesz odpowiedzialność za produkt niebezpieczny. Odpowiadasz na zasadzie ryzyka. Pacjent nie musi udowadniać Twojej winy. Wystarczy, że wykaże trzy rzeczy: że poniósł szkodę, że wyrób (oprogramowanie) był wadliwy oraz że istnieje bezpośredni związek przyczynowy między tym błędem a jego szkodą.
Jeżeli Twoja aplikacja to wyrób medyczny, każdy taki błąd musisz zgłosić i natychmiast usunąć. Za ukrywanie błędów grożą naprawdę surowe kary.
Kiedy odpowiada lekarz?
Lekarz ma obowiązek krytycznego myślenia. Narzędzia IT mają dla niego charakter pomocniczy. Jeżeli innowacyjny algorytm AI wygeneruje fałszywie ujemny wynik (np. nie zauważy guza), a lekarz bezkrytycznie podpisze ten opis jako własny, nie zważając na wywiady chorobowe i objawy kliniczne wskazujące na błąd, odpowiedzialność spada w pierwszej kolejności na niego. Może on odpowiadać cywilnie oraz ponieść odpowiedzialność karną, a także dyscyplinarną.
W przypadku sporu o to, kto zawinił, w pierwszej kolejności trzeba będzie ustalić, czy lekarz miał możliwość wykrycia błędu. I nie chodzi tylko o tego konkretnego lekarza, ale o przeciętnego, starannego lekarza tej samej specjalizacji, mającego te same dane.
Jeżeli błąd był „do wykrycia” odpowiedzialny będzie lekarz. Ale jeżeli okaże się, że system „zwariował” i lekarz nie miał, jak ustalić, że coś działa nieprawidłowo, odpowiedzialność spadnie prawdopodobnie na producenta.
4. Jak przetwarzam dane osobowe, jeśli chodzi o innowacje w medycynie?
W medycynie nie przetwarzasz tylko „zwykłych” danych. Najczęściej przetwarzasz też dane o zdrowiu, a to są tzw. dane szczególnej kategorii. Żeby przetwarzać takie dane, musisz mieć którąś z podstaw określonych w art. 9 RODO.
Jeśli działasz jako podmiot leczniczy, Twoją podstawą będzie najczęściej art. 9 ust. 2 lit. h RODO, a więc profilaktyka zdrowotna lub diagnoza medyczna. W takim przypadku pacjenci nie muszą wyrażać dodatkowej zgody na przetwarzanie ich danych.
Jeśli jednak oferujesz aplikację wellness (i nie chcesz wpaść w reżim wyrobów medycznych), musisz zadbać o odpowiednie zgody. Zgoda musi być wyraźna, świadoma i dobrowolna.
Niezależnie od podstawy przetwarzania musisz poinformować użytkownika, kto będzie przetwarzał jego dane i w jaki sposób.
Musisz też pamiętać, aby rzeczywiście zadbać o bezpieczeństwo przetwarzanych danych. Powinieneś przeprowadzić ocenę skutków dla ochrony danych (DPIA), wdrożyć odpowiednie zabezpieczenia, zadbać o przeszkolenie personelu itp.
5. Innowacyjne technologie w medycynie, czyli jak wykorzystuję sztuczną inteligencję?
Jeżeli Twoja aplikacja wykorzystuje sztuczną inteligencję, musisz uwzględnić też postanowienia rozporządzenia o sztucznej inteligencji (AI Act).
AI Act dzieli wszystkie systemy AI na cztery klasy, w zależności od tego, jak duże ryzyko stwarzają. Jeżeli Twoje innowacje medyczne są wyrobami medycznymi sytuacja jest prosta – tworzysz system AI wysokiego ryzyka. Masz w związku z tym szereg obowiązków.
Musisz przede wszystkim:
- wdrożyć system zarządzania ryzykiem i utrzymywać go przez cały cykl życia systemu AI,
- przygotować odpowiednią dokumentację techniczną,
- zapewnić transparentność dla użytkowników,
- zapewnić nadzór nad systemem AI ze strony człowieka.
Co ważne – projektowanie architektury systemu musi od początku uwzględniać te wymogi.
W tym miejscu warto wrócić do pierwszego pytania, gdzie ustalaliśmy, kiedy program jest wyrobem medycznym. Podkreślałam tam, że warto od początku wiedzieć, czy tworzone rozwiązanie będzie (lub może być) uznane za wyrób medyczny, bo to rzutuje na zakres obowiązków producenta. Oprócz obowiązków wynikających z regulacji dotyczących stricte wyrobów medycznych musisz pamiętać też o wymaganiach, które nakłada AI Act. Jeśli Twoja aplikacja nie będzie wyrobem medycznym, a jedynie doradcą z wbudowanym agentem AI, też musisz sprawdzić, czy nie pojawią się jakieś obowiązki z AI Act, np. dotyczące przejrzystości (użytkownik musi wiedzieć, że wchodzi w interakcję z AI) lub czy system nie profiluje użytkowników w sposób niedozwolony.
Podsumowanie – innowacje medyczne a prawo
Ryzyko związane z wdrażaniem innowacji w branży medycznej to nie tylko ryzyko braku sukcesu, to też potencjalnie zagrożenie zdrowia, a nawet życia, konkretnych ludzi. Dlatego tak wiele aktów prawnych reguluje właśnie tę branżę.
Jednocześnie nie da się wszystkiego uregulować jednoznacznie – żeby medycyna mogła się rozwijać, potrzebna jest elastyczność. To z kolei powoduje, że każdy projekt trzeba analizować indywidualnie, uwzględniając konkretne okoliczności.
Wnioski? Lepiej zapobiegać niż leczyć. Im wcześniej przeanalizujesz swoje innowacyjne rozwiązanie w medycynie od strony potencjalnych regulacji prawnych, tym większa szansa, że dostosujesz je do tych regulacji, a w efekcie będziesz działać i skutecznie, i legalnie.
W sytuacjach granicznych bardzo ważne jest jednak także budowanie spójnego wizerunku. W praktyce każde słowo użyte w interfejsie, w regulaminie, polityce prywatności czy materiałach marketingowych może mieć znaczenie.
Zdecydowanie warto zderzyć swój pomysł z obowiązującym przepisami, wytycznymi oraz z konkretnymi przykładami z rynku. Konsultacja z prawnikiem na początkowym etapie prac deweloperskich to nie koszt, ale inwestycja. Wtedy jeszcze można coś bezboleśnie dostosować, usunąć lub dodać. Im bardziej zaawansowany produkt, tym trudniej wprowadzać zmiany. Wtedy nawet najlepsze disclaimery w regulaminie mogą nie wystarczyć.
