Sztuczna inteligencja w medycynie

Zdjęcie: sztuczna inteligencja w medycynie

Polska AI dla zdrowia. Kto odpowiada za algorytm, który zaczyna uczestniczyć w leczeniu pacjenta? Sztuczna inteligencja w medycynie – kto ponosi odpowiedzialność za decyzje algorytmu? Polska rozwija własne rozwiązania sztucznej inteligencji przeznaczone dla ochrony zdrowia. Dolnośląskie Centrum Onkologii, Pulmonologii i Hematologii oraz Politechnika Wrocławska przedstawiły inicjatywę „Polska AI dla zdrowia”, której celem jest rozwój krajowych modeli AI wspierających personel medyczny i pacjentów. Wśród planowanych zastosowań wymienia się usprawnienie pracy z dokumentacją medyczną, koordynację leczenia, identyfikowanie brakujących wyników badań i sygnalizowanie ryzyka opóźnień w procesie terapeutycznym. Z perspektywy technologicznej to interesujący kierunek rozwoju. Z perspektywy prawnej rodzi jednak pytanie znacznie ważniejsze niż to, czy polska medycyna potrzebuje własnych modeli sztucznej inteligencji. Kto będzie odpowiadał za system, który zacznie wpływać na organizację leczenia, a potencjalnie również na decyzje podejmowane wobec pacjenta? Nie jest to pytanie dotyczące odległej przyszłości. Obowiązują już przepisy regulujące wyroby medyczne, przetwarzanie danych dotyczących zdrowia i wykorzystywanie sztucznej inteligencji. Trzeba jedynie prawidłowo ustalić, które z nich mają zastosowanie do konkretnego rozwiązania. Nie każda medyczna AI jest wyrobem medycznym. Pierwszym błędem byłoby założenie, iż każdy system sztucznej inteligencji wykorzystywany w szpitalu automatycznie podlega rozporządzeniu MDR. Zgodnie z art. 2 pkt 1 rozporządzenia (UE) 2017/745 wyrobem medycznym może być również oprogramowanie, o ile producent przewidział je do określonego zastosowania medycznego, m.in. diagnozowania, monitorowania, przewidywania lub leczenia chorób. Decydujące znaczenie ma zatem przewidziane zastosowanie produktu. System służący do organizowania terminarza wizyt, wyszukiwania dokumentów czy usprawniania administracyjnego obiegu informacji nie staje się wyrobem medycznym wyłącznie dlatego, iż korzysta z niego szpital. Inaczej należy oceniać oprogramowanie, które analizuje dane kliniczne pacjenta i dostarcza informacji wykorzystywanych do podejmowania decyzji diagnostycznych lub terapeutycznych. W takim przypadku konieczna może być kwalifikacja jako wyrobu medycznego, a następnie ustalenie jego klasy ryzyka zgodnie z art. 51 MDR i załącznikiem VIII, w szczególności regułą 11 dotyczącą oprogramowania. Nie oznacza to, iż każde narzędzie analizujące dane pacjenta automatycznie należy do najwyższej klasy ryzyka. Klasyfikacja zależy od funkcji produktu oraz możliwych konsekwencji wykorzystania dostarczanych informacji. Granica pomiędzy narzędziem administracyjnym a medycznym może jednak okazać się bardzo cienka. System, który jedynie porządkuje dokumentację, może pełnić funkcję pomocniczą. o ile jednak zaczyna wskazywać lekarzowi prawdopodobne rozpoznanie albo rekomendować sposób postępowania terapeutycznego, jego status prawny wymaga ponownej oceny. Dlatego kwalifikacja regulacyjna powinna nastąpić już na etapie projektowania produktu, a nie dopiero przed rozpoczęciem jego sprzedaży. Odpowiedzialności nie da się przenieść na algorytm. MDR nie zna konstrukcji odpowiedzialności samej sztucznej inteligencji. o ile system jest wyrobem medycznym, obowiązki producenta wynikają przede wszystkim z art. 10 rozporządzenia 2017/745. Obejmują one m.in. zapewnienie zgodności wyrobu z wymaganiami, zarządzanie ryzykiem, przygotowanie dokumentacji technicznej, przeprowadzenie wymaganej oceny klinicznej oraz ustanowienie systemu nadzoru po wprowadzeniu do obrotu. Z kolei art. 5 MDR uzależnia możliwość wprowadzenia wyrobu do obrotu lub używania od spełnienia odpowiednich wymagań regulacyjnych. Nie wystarczy zatem wyjaśnienie, iż nieprawidłowa rekomendacja została wygenerowana przez model, którego sposób działania jest trudny do odtworzenia. o ile producent zdecydował się wykorzystać określoną technologię w wyrobie medycznym, musi zapewnić spełnienie mających zastosowanie wymagań bezpieczeństwa i działania. Oczywiście odpowiedzialność producenta nie jest tożsama z odpowiedzialnością szpitala czy lekarza. Są to odrębne role prawne, a zakres odpowiedzialności zależy od okoliczności konkretnego zdarzenia. W szczególności należy odróżniać wadliwość produktu od nieprawidłowego sposobu jego używania oraz błędów organizacyjnych po stronie podmiotu leczniczego. Nie można jednak przyjąć, iż obecność człowieka w procesie automatycznie zwalnia producenta z obowiązków dotyczących bezpieczeństwa oprogramowania. AI Act nie zastępuje MDR. Kolejnym istotnym aktem jest rozporządzenie (UE) 2024/1689, czyli AI Act. Jego art. 6 określa zasady kwalifikowania systemów AI jako systemów wysokiego ryzyka. W odniesieniu do produktów objętych unijnym prawodawstwem harmonizacyjnym, wymienionym w załączniku I, istotny jest art. 6 ust. 1. Obejmuje on określone systemy AI będące produktami albo elementami bezpieczeństwa produktów, dla których adekwatne przepisy wymagają oceny zgodności przez stronę trzecią. W załączniku I wskazano również MDR i IVDR. Nie oznacza to jednak, iż każdy system AI używany w ochronie zdrowia automatycznie jest systemem wysokiego ryzyka. Konieczne jest ustalenie jego funkcji, przeznaczenia oraz adekwatnej podstawy kwalifikacji. Ważne jest również rozróżnienie terminów stosowania przepisów. Zgodnie z aktualnym art. 113 AI Act zasadnicza część rozporządzenia jest stosowana od 2 sierpnia 2026 r. Natomiast przepisy rozdziału III sekcji 1–3 dotyczące określonych systemów wysokiego ryzyka mają odrębne terminy stosowania: 2 grudnia 2027 r. dla systemów objętych art. 6 ust. 2 i załącznikiem III oraz 2 sierpnia 2028 r. dla systemów objętych art. 6 ust. 1 i załącznikiem I. Przyszły termin stosowania części wymagań AI Act nie oznacza jednak, iż producent medycznego systemu AI może w tej chwili ignorować obowiązki wynikające z MDR. Te obowiązki istnieją niezależnie od wskazanych przepisów przejściowych AI Act. W praktyce producent musi więc równolegle analizować dwa reżimy regulacyjne, a nie traktować jednego jako zastępstwa drugiego.Największym problemem mogą okazać się dane. Rozwój modeli medycznych wymaga dostępu do odpowiednich danych. Dane dotyczące zdrowia należą jednak do szczególnych kategorii danych osobowych, o których mowa w art. 9 ust. 1 RODO. Ich przetwarzanie jest co do zasady zabronione, chyba iż zachodzi jedna z przesłanek określonych w art. 9 ust. 2. Niezależnie od tego konieczne jest spełnienie odpowiedniej podstawy legalności przetwarzania wynikającej z art. 6 RODO. Nie można zatem zakładać, iż szpital, który legalnie zgromadził dokumentację medyczną na potrzeby leczenia, może automatycznie przekazać ją podmiotowi technologicznemu w celu trenowania dowolnego modelu AI. Trzeba odrębnie ustalić cel i podstawę przetwarzania, role uczestniczących podmiotów, zakres wykorzystywanych danych oraz wymagane zabezpieczenia. W zależności od konstrukcji projektu znaczenie mogą mieć przepisy dotyczące badań naukowych, w tym art. 9 ust. 2 lit. j oraz art. 89 RODO. Nie są one jednak generalnym zwolnieniem z obowiązków ochrony danych. Również pseudonimizacja nie oznacza automatycznie, iż dane przestają być danymi osobowymi. Wynika to z definicji zawartej w art. 4 pkt 5 RODO. Inaczej należy oceniać dane rzeczywiście anonimowe, których nie można przypisać zidentyfikowanej lub możliwej do zidentyfikowania osobie fizycznej przy uwzględnieniu adekwatnych kryteriów identyfikowalności. W projektach medycznej AI różnica ta ma znaczenie zasadnicze. Kto jest producentem, a kto jedynie dostawcą technologii? W projektach realizowanych wspólnie przez uczelnie, szpitale i przedsiębiorstwa technologiczne może pojawić się jeszcze jeden problem. Samo opracowanie modelu AI nie przesądza automatycznie, który podmiot będzie producentem konkretnego wyrobu medycznego.Zgodnie z