Dostawca aktualizuje technologię, producent odpowiada za wyrób. Kiedy zmiana software’u lub modelu AI staje się problemem regulacyjnym?

Aktualizacja oprogramowania i modelu AI w wyrobie medycznym - ocena zgodności MDR

Zmiana technologiczna może wymagać ponownej oceny wpływu na bezpieczeństwo i zgodność wyrobu. Grafika wygenerowana przez AI.

Wprowadzenie wyrobu medycznego do obrotu nie oznacza, że jego technologiczny rozwój się kończy. W przypadku wyrobów wykorzystujących oprogramowanie jest często dokładnie odwrotnie. Software jest aktualizowany, usuwane są błędy, zmieniają się biblioteki, infrastruktura chmurowa czy komponenty pochodzące od zewnętrznych dostawców. W systemach wykorzystujących sztuczną inteligencję dochodzą do tego kolejne elementy: aktualizacja modelu, zmiana danych, modyfikacja algorytmu czy dodawanie nowych funkcjonalności.

Z biznesowego punktu widzenia to naturalny cykl rozwoju produktu. Z perspektywy regulacyjnej pojawia się jednak zasadnicze pytanie: czy po każdej takiej zmianie producent nadal może zakładać, że ma do czynienia z tym samym wyrobem, którego zgodność została wcześniej oceniona? Problem staje się szczególnie istotny, gdy zmiany nie są dokonywane bezpośrednio przez producenta wyrobu.

Współczesny wyrób medyczny może wykorzystywać oprogramowanie, modele AI, biblioteki, usługi chmurowe i inne komponenty dostarczane przez wiele niezależnych podmiotów. Dostawca technologii aktualizuje swój produkt zgodnie z własnym harmonogramem rozwoju. Dla niego jest to kolejna wersja oprogramowania. Dla producenta wyrobu medycznego ta sama aktualizacja może mieć znaczenie dla bezpieczeństwa, działania lub zgodności całego wyrobu. To zasadnicza różnica perspektyw.

Na gruncie rozporządzenia 2017/745 w sprawie wyrobów medycznych producent odpowiada za zgodność wyrobu z wymaganiami MDR. Obowiązek ten nie znika dlatego, że określony element rozwiązania został dostarczony przez zewnętrznego kontrahenta. Producent powinien więc posiadać mechanizm pozwalający ocenić wpływ zmian technologicznych na wyrób.

Nie każda aktualizacja będzie miała takie samo znaczenie. Poprawienie błędu interfejsu, aktualizacja zabezpieczeń czy modyfikacja funkcji administracyjnej może mieć zupełnie inny wpływ niż zmiana algorytmu uczestniczącego w analizie danych medycznych albo modyfikacja modelu AI wpływającego na rezultat przedstawiany użytkownikowi. Kluczowe jest zatem nie samo pytanie, czy software został zmieniony, ale czy zmiana może wpływać na przewidziane zastosowanie, bezpieczeństwo, działanie lub profil ryzyka wyrobu.

Jeżeli odpowiedź jest twierdząca, aktualizacja przestaje być wyłącznie kwestią techniczną. Producent powinien ocenić jej wpływ na zarządzanie ryzykiem, dokumentację techniczną, weryfikację i walidację oprogramowania, ocenę kliniczną oraz inne elementy systemu zgodności. W zależności od charakteru zmiany może powstać również konieczność zaangażowania jednostki notyfikowanej zgodnie z procedurą właściwą dla danego wyrobu.

W przypadku AI problem staje się jeszcze bardziej złożony. Klasyczne oprogramowanie jest co do zasady projektowane tak, aby po aktualizacji wykonywało określone przez producenta operacje według przewidzianych reguł. System AI może być w większym stopniu zależny od modelu, danych oraz sposobu jego dostosowania. Zmiana jednego z tych elementów może wpływać na jakość i charakter generowanych wyników, nawet jeśli z punktu widzenia użytkownika interfejs produktu pozostaje praktycznie identyczny.

Producent powinien zatem ustalić, jakie modyfikacje systemu AI zostały przewidziane i ocenione już na etapie projektowania, a jakie mogą zmieniać właściwości rozwiązania w sposób wymagający ponownej oceny regulacyjnej. AI Act dodatkowo wzmacnia znaczenie zarządzania zmianą. W przypadku systemów AI wysokiego ryzyka dokumentacja, zarządzanie ryzykiem, dokładność, odporność, nadzór człowieka czy monitorowanie po wprowadzeniu do obrotu nie mogą być traktowane jako elementy statyczne. Muszą odpowiadać rzeczywistemu systemowi znajdującemu się na rynku. To oznacza, że producent powinien wiedzieć nie tylko, jak działała technologia w dniu przeprowadzania oceny zgodności, ale również co zmieniło się później.

W praktyce właśnie tutaj może pojawić się poważna luka. Producent może posiadać rozbudowany system kontroli zmian własnego produktu, ale jednocześnie korzystać z technologii zewnętrznego dostawcy, którego umowa przewiduje możliwość automatycznych aktualizacji. Dostawca zmienia wersję modelu, sposób przetwarzania danych albo określony komponent, a producent dowiaduje się o tym dopiero po wdrożeniu aktualizacji. W przypadku zwykłego produktu IT może to być przede wszystkim problem operacyjny. W przypadku wyrobu medycznego może stać się problemem regulacyjnym.

Dlatego zarządzanie zmianą powinno rozpoczynać się już na etapie konstruowania relacji z dostawcą technologii. Umowa powinna określać, jakie zmiany wymagają wcześniejszego poinformowania producenta, które wymagają jego zgody oraz jakie informacje dostawca musi przekazać, aby możliwa była ocena wpływu aktualizacji na wyrób. Istotne mogą być również obowiązki współpracy przy walidacji, analizie ryzyka, incydentach oraz postępowaniach prowadzonych przez organy lub jednostkę notyfikowaną.

Szczególnie ryzykowne jest pozostawienie dostawcy pełnej swobody w zakresie zmian komponentu, który ma znaczenie dla bezpieczeństwa lub działania wyrobu. Nie oznacza to oczywiście, że producent powinien blokować każdą aktualizację. W przypadku cyberbezpieczeństwa szybkie wdrażanie poprawek może być wręcz konieczne. Potrzebny jest jednak proces pozwalający rozróżnić zwykłą poprawkę techniczną od zmiany, która wpływa na charakterystykę regulacyjną produktu.

Problem nie kończy się również na samej umowie. Organizacja powinna określić, kto otrzymuje informację o zmianie i kto podejmuje decyzję o jej kwalifikacji. Dostawca może przesłać informację do działu IT, podczas gdy jej znaczenie powinno zostać ocenione również przez regulatory affairs, quality, osoby odpowiedzialne za bezpieczeństwo produktu czy dział prawny. Zarządzanie zmianą technologiczną staje się więc procesem interdyscyplinarnym.

Ma to szczególne znaczenie w przypadku producentów, którzy rozwijają produkt przez wiele lat. Po kilkunastu aktualizacjach wyrób znajdujący się na rynku może technologicznie znacząco różnić się od wersji pierwotnie poddanej ocenie. Każda pojedyncza zmiana może wydawać się niewielka, podczas gdy ich łączny wpływ na działanie produktu będzie już istotny. Dlatego analiza zmian nie powinna ograniczać się wyłącznie do oceny pojedynczego update’u. Potrzebna jest również kontrola ich efektu kumulatywnego.

Wraz z coraz szerszym wykorzystaniem AI znaczenie tego problemu będzie rosło. Producenci wyrobów medycznych będą w coraz większym stopniu zależni od technologii rozwijanych przez wyspecjalizowanych dostawców, nad którymi nie posiadają pełnej kontroli technicznej. Nie zmienia to podstawowej zasady: wobec rynku odpowiedzialność za zgodność wyrobu pozostaje przede wszystkim po stronie jego producenta.

Dlatego pytanie zadawane dostawcy nie powinno ograniczać się do: „czy aktualizacja działa?”. Producent musi również wiedzieć: „co zostało zmienione i czy ta zmiana wpływa na zgodność naszego wyrobu?”. W regulowanym świecie wyrobów medycznych aktualizacja software’u nie zawsze jest bowiem tylko aktualizacją. Czasami oznacza zmianę produktu, za którego bezpieczeństwo i zgodność nadal odpowiada producent.

Artykuł przygotowany przez: