Kiedy oprogramowanie jest wyrobem medycznym?

Z końcem marca Ministerstwo Zdrowia rozpoczęło certyfikację mobilnych aplikacji zdrowotnych.
Aby aplikacja trafiła do „Portfela Aplikacji MZ”, musi być wyrobem medycznym. I tu pojawia się pytanie: w jakich przypadkach system IT lub aplikacja są objęte przepisami o wyrobach medycznych? Tłumaczymy obowiązujące przepisy, klasy bezpieczeństwa i kruczki prawne.

Joanna Wajdzik i Zuzanna Nowak-Wróbel, Kancelaria Wolf Theiss

Wyroby medyczne na gruncie europejskiego i polskiego prawa są bardzo szeroką grupą produktów. Są to nie tylko rzeczy fizyczne, czyli tradycyjnie rozumiane wyroby medyczne, takie jak aparaty słuchowe czy wózki inwalidzkie, ale także oprogramowanie.

Może to być zarówno specjalistyczny program komputerowy stosowany w praktyce klinicznej do diagnostyki obrazowej (np. oceny badań urazowych klatki piersiowej) jak i aplikacja, którą każdy z nas może ściągnąć na swój telefon. Pojęcia oprogramowania i aplikacji często używane są zamiennie, chociaż termin „oprogramowanie” co do zasady interpretujemy szerzej: każda aplikacja korzysta bowiem z oprogramowania, ale nie każde oprogramowanie jest aplikacją. Obecnie nie ulega wątpliwości, że nie tylko oprogramowanie wspierające wyrób medyczny (np. monitorujące poziom glukozy we krwi na podstawie danych wysyłanych przez pompę insulinową), ale również samo oprogramowanie jako takie może być uznane za wyrób medyczny.

TSUE: Kluczowe jest przeznaczenie oprogramowania

Na gruncie stosunkowo nowych regulacji unijnych wprowadzonych Rozporządzeniem Parlamentu Europejskiego i Rady (UE) 2017/745 w sprawie wyrobów medycznych („Rozporządzenie MDR”) samodzielnym wyrobem medycznym może być nie tylko sam sprzęt (hardware), lecz także to, co nim steruje, czyli oprogramowanie (software).

Możliwość takiej kwalifikacji jest jednak obwarowana pewnymi wymogami. Po pierwsze, oprogramowanie kwalifikuje się jako samodzielny wyrób medyczny w przypadku, gdy producent przewidział jego zastosowanie u ludzi do co najmniej jednego z zastosowań medycznych wyszczególnionych w definicji wyrobu medycznego zawartej w Rozporządzeniu MDR. Takimi zastosowaniami medycznymi jest głównie diagnozowanie, profilaktyka, monitorowanie, przewidywanie, prognozowanie, leczenie lub łagodzenie choroby, ale również np. diagnozowanie, monitorowanie, leczenie, łagodzenie lub kompensowanie urazu, lub niepełnosprawności.

Na gruncie tej definicji, Trybunał Sprawiedliwości Unii Europejskiej (TSUE) w wyroku z 7 grudnia 2017 roku w sprawie C-329/16 określił kryteria rozgraniczenia pomiędzy oprogramowaniem do celów medycznych i oprogramowaniem ogólnego zastosowania używanego w ochronie zdrowia (np. programem wspomagającym proces rejestracji pacjentów w przychodni).

Zgodnie z wyrokiem TSUE, decydujące dla zakwalifikowania oprogramowania jako wyrobu medycznego jest przeznaczenie wyrobu przewidziane przez producenta – jeśli oprogramowanie jest przeznaczone do stosowania u ludzi w celu np. diagnozowania chorób, ich monitorowania, zapobiegania im, leczenia lub łagodzenia ich przebiegu, określonych w definicji wyrobu medycznego (zgodnie z ww. definicją wyrobu medycznego), do produktu mają zastosowanie przepisy dotyczące wyrobów medycznych. Wyrok został wprawdzie wydany na podstawie poprzednio obowiązującej dyrektywy Rady 93/42/EWG („Dyrektywa MDD”), ale pozostał aktualny i wiążący także po rozpoczęciu stosowania Rozporządzenia MDR.

Reguła 11 i podział na klasy III, II i I

Wyroby medyczne, w tym oprogramowanie, są klasyfikowane do jednej z określonych klas (tj. I, IIa, IIb, III), głównie w zależności od przewidzianego zastosowania i stopnia inwazyjności, czyli w uproszczeniu – w zależności od tego, jak dużą – potencjalnie – szkodę mogą wyrządzić użytkownikom.

Przyjmując jako podstawę wysoki poziom ochrony zdrowia oraz norm jakości i bezpieczeństwa dla wyrobów medycznych, Rozporządzenie MDR wprowadziło nowe, bardziej wymagające reguły klasyfikacji wyrobów medycznych w porównaniu do poprzednio obowiązującej w tym zakresie Dyrektywy MDD. Co więcej, producenci mają obowiązek zweryfikować, czy na gruncie nowych zasad, ich wyroby nie wymagają przeklasyfikowania do wyższych klas. Klasyfikacji wyrobu dokonuje sam producent na podstawie reguł wymienionych w Załączniku VIII do Rozporządzenia MDR. Obecnie klasyfikacja oprogramowania opiera się na zawartej w Załączniku VIII tak zwanej „Regule 11”.

Zgodnie z nią, oprogramowanie co do zasady należy do klasy I, chyba że dostarcza informacji wykorzystywanych przy podejmowaniu decyzji do celów diagnostycznych lub terapeutycznych – wtedy należy do klasy IIa. W przypadku, gdy skutki takich decyzji diagnostycznych czy terapeutycznych mogą powodować:

• zgon danej osoby albo nieodwracalne pogorszenie stanu jej zdrowia – oprogramowanie należy do klasy III;
• poważne pogorszenie stanu zdrowia danej osoby lub konieczność interwencji chirurgicznej – oprogramowanie należy do klasy IIb.

Odrębnie ujęta w Regule 11 jest kwestia oprogramowania przeznaczonego do monitorowania procesów fizjologicznych. Co do zasady należy ono do klasy IIa, z wyjątkiem przypadków, gdy jest ono przeznaczone do monitorowania życiowych parametrów fizjologicznych, których zmiana może powodować bezpośrednie zagrożenie dla pacjenta – wtedy oprogramowanie należy do klasy IIb.

Na gruncie obecnie obowiązujących przepisów, zakwalifikowanie wyrobu medycznego do klasy wyższej niż I wiąże się z koniecznością zaangażowania jednostki notyfikowanej w proces oceny zgodności (są pewne wyjątki, tj. wyroby klasy I, które również wymagają udziału jednostki notyfikowanej w ocenie zgodności, niemniej, nie dotyczą one oprogramowania). Ocena zgodności jest procesem ewaluacji, dokonywanym na podstawie systemu zarządzania jakością i dokumentacji technicznej wyrobu. Po przeprowadzeniu właściwej według klasy wyrobu oceny zgodności, producent ma obowiązek oznakować wyrób znakiem CE, potwierdzając tym samym zgodność z wymogami określonymi w przepisach. Znamienne jest, że na gruncie Dyrektywy MDD, oprogramowanie było bardzo często klasyfikowane jako wyrób klasy I. Obecnie, oprogramowanie o tych samych cechach, w większości przypadków trafia do klasy IIa, czyli wyższej. To ogromna zmiana dla producentów oprogramowania medycznego, ponieważ proces certyfikacji opóźnia wejście na rynek nawet o rok i generuje niemałe dodatkowe koszty (już samo przygotowanie oferty z kosztorysem certyfikacji jest osobno wyceniane przez jednostki notyfikowane).

Oprogramowanie nie jest ostatecznym decydentem

Aby ułatwić producentom prawidłową klasyfikację, Grupa Koordynacyjna ds. Wyrobów Medycznych (MDCG) przygotowała wytyczne (MDCG 2021–24). Największe wątpliwości interpretacyjne, może budzić klasyfikacja pomiędzy klasą I, a klasą IIa. Jedynym przykładem oprogramowania kwalifikującego się do klasy I opisanym w wytycznych jest aplikacja wspierająca poczęcia poprzez „naturalne rozpoznawanie płodności”. Użytkownik aplikacji na podstawie wprowadzanych danych zdrowotnych (temperatura, cykl menstruacyjny) może ustalić „status” płodności i monitorować termin przewidywanej owulacji. Truizm „ciąża to nie choroba” nabiera w tym kontekście praktycznego znaczenia, ponieważ w istocie, monitorowanie płodności nie prowadzi do podejmowania decyzji diagnostycznych lub terapeutycznych (Reguła 11). Przytaczając inny przykład umieszczony w wytycznych, MDCG rekomendowało kwalifikację oprogramowania „przeznaczonego do wykonywania obrazowej diagnostyki medycznej za pomocą analizy obrazu w celu podejmowania decyzji dotyczących leczenia u pacjentów z ostrym udarem mózgu” jako wyrobu medycznego klasy III.

Kwalifikacja tak scharakteryzowanego oprogramowania do najwyższej klasy wydaje się uzasadniona, chociażby z uwagi na niebagatelną jednostkę chorobową, jaką jest ostry udar mózgu. Mając na uwadze, że sposób leczenia udaru jest ściśle powiązany z oknem czasowym, który upłynął od zachorowania, błędna decyzja diagnostyczna czy terapeutyczna z pewnością może kosztować pacjenta życie lub nieodwracalnie pogorszyć stan jego zdrowia (Reguła 11).

Tutaj dotykamy nie mniej ciekawego aspektu, tj. autonomii decyzyjnej sztucznej inteligencji wykorzystywanej w oprogramowaniu i jej wpływu na zakwalifikowanie oprogramowania do określonej klasy wyrobów. Coraz więcej innowacyjnych wyrobów medycznych opartych na oprogramowaniu komputerowym wykorzystuje algorytmy uczenia maszynowego, potocznie nazywanego sztuczną inteligencją. Literalne brzmienie Reguły 11 zawartej w Rozporządzeniu MDR implikuje, że oprogramowanie nie podejmuje autonomicznych decyzji terapeutycznych, a jedynie dostarcza informacji wykorzystywanych w procesie ich podejmowania. Innymi słowy, konsekwencje decyzji diagnostycznych czy terapeutycznych oceniamy wyłącznie przez pryzmat ich skutku, a nie tego, kto je podejmuje (oprogramowanie czy lekarz), ponieważ oprogramowanie nigdy (przynajmniej zgodnie z Regułą 11), nie jest ostatecznym decydentem. Czy jednak rzeczywiście tak jest i czy sztuczna inteligencja stosowana w oprogramowaniu np. diagnostycznym, zawsze będzie podlegała weryfikacji lekarza?

Wiele wskazuje na to, że nie, zwłaszcza biorąc pod uwagę postęp technologiczny, rosnące braki kadrowe i przeciążenie służby zdrowia. Już teraz istnieją w rentgenologii algorytmy do opisywania badań, które mogą zostać zaprogramowane w taki sposób, aby badań zakwalifikowanych jako tzw. bezzmianowe nie przekazywać do oceny radiologa w ogóle. Wracając do powyższego przykładu, nawet intuicyjnie można dojść do wniosku, że oprogramowanie, które jedynie przekazuje obraz z komentarzem diagnostycznym do wglądu lekarza, nie powinno być klasyfikowane tak samo, jak oprogramowanie dokonujące samodzielnej analizy obrazu i jedynie dostarczające wynik (bez materiału źródłowego) do lekarza. Jednocześnie powstaje kolejne pytanie: czy w takim razie oprogramowanie „samodzielne” zasługuje na klasę wyższą, czy niższą względem oprogramowania wykorzystywanego w pracy lekarza jedynie pomocniczo?

To pytanie może wydawać się przewrotne, ponieważ wszystko poza kontrolą człowieka wydaje nam się bardziej niebezpiecznie, ale tylko pozornie. Pojawia się coraz więcej badań, które pokazują, że algorytmy głębokiego uczenia są w stanie dokonywać trafniejszej diagnozy, niż doświadczeni lekarze. Niezależnie od prawidłowej klasyfikacji takiego oprogramowania na gruncie regulacji dotyczących wyrobów medycznych, wkrótce niezbędne będzie spełnianie przez każdy produkt oparty o algorytm sztucznej inteligencji szeregu wymogów dedykowanych takim rozwiązaniom (nie tylko z obszaru zdrowia i medycyny). Obecnie na poziomie unijnym trwają prace nad całym pakietem regulacji poświęconym sztucznej inteligencji.

Kłopotliwa dla producentów klasa III

Klasyfikacja oprogramowania jako wyrobu medycznego klasy III wiąże się dla producenta z obowiązkiem spełnienia dodatkowego wymogu – przeprowadzenia badań klinicznych. W tym miejscu należy natomiast odróżnić dwa występujące w Rozporządzeniu MDR pojęcia, które często są ze sobą mylone i stosowane zamiennie, tzn. ocenę kliniczną i badania kliniczne.

Do przeprowadzenia oceny klinicznej, która stanowi element dokumentacji technicznej, zobowiązany jest producent każdego wyrobu medycznego, bez względu na deklarowaną klasę wyrobu. Ocena kliniczna przeprowadzana jest na podstawie danych klinicznych, które mają dostarczyć wystarczających dowodów na okoliczność:

• spełniania przez dany wyrób ogólnych wymogów dotyczących bezpieczeństwa i działania wyrobu w normalnych warunkach przewidzianego używania,
• działań niepożądanych,
• akceptowalności stosunku korzyści do ryzyka stosowania danego wyrobu.

O ile ocena kliniczna przygotowywana jest na podstawie odpowiedniej dokumentacji, badanie kliniczne, podjęte w celu oceny bezpieczeństwa lub działania wyrobu klasy III, musi zostać przeprowadzone z udziałem co najmniej jednego uczestnika. Uzyskane w ramach badania dane kliniczne stanowią część i uzupełnienie oceny klinicznej. Co prawda celem badania klinicznego jest również potwierdzenie skuteczności i bezpieczeństwa stosowania danego wyrobu, ale jest to proces znacznie bardziej skomplikowany i podlegający odrębnym od oceny klinicznej regulacjom.

Z kwalifikacji oprogramowania użytkowego jako wyrobu medycznego, oprócz obowiązków wynikają również określone korzyści – użytkownik np. aplikacji mobilnej, która posiada status wyrobu medycznego, może mieć większą pewność, że aplikacja ta jest wiarygodna, bezpieczna i sprawdzona. Każdy wyrób medyczny jest bowiem oceniany formalnie i merytorycznie oraz weryfikowany pod kątem bezpieczeństwa, a producent jest zobowiązany do zapewnienia, że wszystkie wymogi prawne dotyczące wprowadzania do obrotu i oceny zgodności takiego oprogramowania zostały spełnione.

W efekcie sprostania wymogom regulacyjnym producent może przedstawiać zamierzone cele medyczne osiągalne za pomocą użytkowania danego produktu i w ten sposób poszerzać bazę użytkowników, a w konsekwencji także zyski. Ponadto oczywistym sposobem monetyzacji inwestycji jest potencjalna refundacja oprogramowania będącego wyrobem medycznym ze środków publicznych. Takie rozwiązania wdrożyło już kilka państw, w tym Niemcy, które jako pierwszy kraj w Unii Europejskiej wystandaryzowały proces oceny i refundowania cyfrowych aplikacji zdrowotnych (nazywanych „Digitale Gesundheitsanwendung” – DiGA) w ramach wprowadzonej w 2019 roku ustawy o cyfrowej opiece zdrowotnej („Digitale-Versorgung-Gesetz” – DVG). Jeśli aplikacja zdrowotna zostanie zweryfikowana pozytywnie, zostaje umieszczona w katalogu aplikacji zatwierdzonym przez niemiecki Federalny Instytut ds. Leków i Wyrobów Medycznych (BfArM). Recepta na stosowanie aplikacji może zostać przepisana przez lekarza spośród zatwierdzonych przez BfArM produktów znajdujących się w katalogu DiGA. Co istotne, na ten moment niemiecki płatnik refunduje wyłącznie aplikacje w klasie I lub IIa wyrobów medycznych.

Czy Polska ma szansę równać do najlepszych?

Czy istnieje szansa na podobne rozwiązanie w Polsce? Ministerstwo Zdrowia co prawda twierdzi, że nie planuje wdrożenia refundacji aplikacji medycznych (głównie z uwagi na czas potrzebny do wprowadzenia danego rozwiązania do koszyka świadczeń gwarantowanych), ale podjęło jednocześnie konkretne działania w celu stworzenia katalogu aplikacji zatwierdzonych przez Ministerstwo Zdrowia na podobieństwo katalogu DiGA.

Zgodnie z komunikatem w sprawie przyznawania aplikacji tytułu „Aplikacja Certyfikowana MZ” oraz włączania do tzw. Portfela Aplikacji Zdrowotnych (PAZ), tytuł „Aplikacji Certyfikowanej MZ” może uzyskać aplikacja, której oprogramowanie zostało zakwalifikowane jako wyrób medyczny.

Ponadto resort zdrowia przewiduje dodatkowe wymogi dla uzyskania certyfikacji, takie jak przydatność dla pacjenta i pracowników medycznych czy cyberbezpieczeństwo danych (również bezpieczeństwo przekazywania ich do głównego systemu prowadzonego przez Centrum e-Zdrowia).

Formularz do włączania aplikacji do Portfela Aplikacji Zdrowotnych (PAZ) za pośrednictwem Platformy Obsługi Projektów Inwestycyjnych (POPI) wraz z regulaminem są już dostępne online po zalogowaniu na platformie POPI (https://e-inwestycje.mz.gov.pl/).

Co ciekawe, resort zdecydował się na objęcie finansowaniem z budżetu państwa jednej, wybranej przez Ministerstwo Zdrowia aplikacji, ciężko jednak na podstawie obecnie dostępnych informacji stwierdzić, na jakich zasadach. Zgodnie z zadeklarowanymi potrzebami, w tym roku miałaby to być aplikacja psychiatryczna dla dzieci i dorosłych.

Wydaje się, że Ministerstwo Zdrowia transformację cyfrową preferuje wprowadzać stopniowo, na podobieństwo modelu wdrożonego w Belgii czy Wielkiej Brytanii, a nie naszych sąsiadów. W Belgii, aby uzyskać dofinansowanie ze środków publicznych, aplikacje przechodzą 3-poziomowy proces walidacji. W ramach pierwszego poziomu aplikacja musi być certyfikowana znakiem CE jako wyrób medyczny. W ramach drugiego producent musi zagwarantować cyberbezpieczeństwo aplikacji. Ostatni, trzeci poziom polega na złożeniu wniosku refundacyjnego, który ma na celu wykazać wartość kliniczną i społeczno-ekonomiczną zastosowania aplikacji. Na chwilę publikacji tego artykułu, tylko jedna aplikacja osiągnęła poziom trzeci.

Czy powyższe oznacza, że oprogramowanie jako wyrób medyczny, a w tym konkretnym przypadku, aplikacje zdrowotne, znalazły się w obszarze zainteresowania resortu zdrowia? Z pewnością tak.

Aplikacje zdrowotne stwarzają szanse na spersonalizowanie opieki zdrowotnej, na przejęcie przez pacjentów większej kontroli nad swoim zdrowiem za pomocą technologii. Niestety, tak jak w wielu innych państwach europejskich, również i w Polsce aplikacje zdrowotne nie pasują do istniejących ścieżek finansowania służby zdrowia, opartej na paradygmacie centralizacji, a nie personalizacji usług zdrowotnych.

W konsekwencji, obserwując trendy rynkowe i wypowiedzi płynące z samego Ministerstwa Zdrowia, nie należy spodziewać się w tym zakresie rewolucji, zwłaszcza w zakresie refundacji. Częściowo, innowacje w tym zakresie wprowadzane są w praktyce klinicznej, a więc pośrednio poprzez świadczeniodawców. Przykładowo, w ramach programu kompleksowej specjalistycznej opieki kardiologicznej „KOS-zawał”, pacjenci mają dostęp do dedykowanej aplikacji mobilnej. To nie zmienia jednak faktu, że bez refundacji, dostęp do innowacyjnych rozwiązań cyfrowych będzie dla pacjentów ograniczony. Brak zrozumiałego i przewidywalnego systemu ich finansowania przez płatnika publicznego na podobieństwo tego funkcjonującego w Niemczech, ogranicza producentom możliwości rozwoju na polskim rynku.

Czytaj także: MZ rozpoczęło certyfikację aplikacji zdrowotnych. Jak aplikować?