4 minuty czytania
Wraz z rozwojem technologii branża opieki zdrowotnej zaczęła coraz bardziej interesować się integracją oprogramowania z wyroby medyczne w celu zapewnienia automatyzacji i dokładności w zakresie prognozowania, diagnozowania, profilaktyki, leczenia i zarządzania schorzeniami. Amerykański Urząd ds. Opieki Zdrowotnej ( US )FDA już dawno dostrzegł rolę, jaką oprogramowanie może odegrać na rzecz poprawy funkcjonowania wyroby medyczne , jednak nie opracował jeszcze żadnych konkretnych wytycznych ani zasad, które mogłyby ułatwić badaczom z tej branży osiąganie postępów w dziedzinie cyfrowego zdrowia.
W dniu 4 listopada 2021 r. Urząd ds. Żywności i Leków ( US )FDA opublikował projekt wytycznych dotyczących„zawartości wniosków przed wprowadzeniem do obrotu w odniesieniu do funkcji oprogramowania wyrobów medycznych”, dając wnioskodawcom odpowiedzialnym za przygotowanie dokumentacji jasne wytyczne co do tego, jakie informacje należy w niej zawrzeć. Informacje te, dostarczane przez wnioskodawców, mają istotne znaczenie dla Agencji ds. Urządzeń Medycznych ( FDA ) przy ocenie oprogramowania wyrobów medycznych realizującego jedną lub więcej funkcji oraz przy zapewnieniu bezpieczeństwa i skuteczności przez cały cykl życia wyrobu. Nowe wytyczne mają charakter zalecenia i są wersją roboczą dotyczącą funkcji oprogramowania wyrobów medycznych, którą Agencja ds. Żywności i Leków ( FDA ) zobowiązała się opublikować w celu zastąpienia 15-letniego dokumentu „Wytyczne dotyczące treści wniosków przed wprowadzeniem do obrotu w odniesieniu do oprogramowania zawartego w wyrobach medycznych”, opublikowanego w maju 2005 r. Ustalono termin na zgłaszanie uwag, a wszelkie dyskusje na ten temat są otwarte do 2 lutego 2022 r.
W tej nowej wersji „ FDA ” uwzględniono sposób powiązania oprogramowania z wyrobem medycznym i wprowadzono dalsze rozróżnienie na: „ SaMD ” – oprogramowanie jako wyrób medyczny oraz „SiMD” – oprogramowanie w wyrobie medycznym, jako podkategorie funkcji oprogramowania wyrobu. Oprogramowanie jako wyrób medyczny ( SaMD ) to oprogramowanie, które samo w sobie realizuje zadania wyrobu medycznego zgodnie z definicją wyrobu medycznego zawartą w sekcji 201 (h) ustawy FD&C Act, ale nie stanowi części składowej tego wyrobu. Z kolei oprogramowanie w ramach kategorii SiMD, jak sama nazwa wskazuje, stanowi część komponentu wyrobu medycznego lub sprzętu służącego do rejestrowania, kontrolowania lub wyświetlania informacji medycznych lub niemedycznych.
Projekt skupia się w większym stopniu na oczekiwaniach Agencji ds. Żywności i Leków ( FDA ) dotyczących przygotowania dokumentacji wymaganej przy składaniu wniosków przed wprowadzeniem na rynek w odniesieniu do funkcji oprogramowania urządzeń medycznych. Agencja jasno określiła, czego oczekuje w dokumentach, które w sposób rzetelny określają specyfikację wymagań oprogramowania (SRS) oraz specyfikacje oprogramowania lub projektu systemu (SDS). W dokumencie „ FDA ” podkreśla się podejście oparte na ryzyku przy sporządzaniu dokumentacji do wniosków przed wprowadzeniem na rynek dotyczących funkcji oprogramowania urządzeń. W zależności od poziomu ryzyka związanego z przeznaczeniem urządzenia poziom dokumentacji powinien się różnić, dzieląc się na dokumentację podstawową i rozszerzoną. Kluczowe punkty, które należy podkreślić na każdym poziomie dokumentacji w celu określenia poziomu ryzyka związanego z oprogramowaniem urządzenia medycznego, to:
- Przegląd oprogramowania przedstawiający dane wejściowe i wyjściowe
- Specyfikacja wymagań oprogramowania (SRS), zawierająca szczegółowe informacje na temat architektury oprogramowania wraz ze schematycznym przedstawieniem wszystkich modułów, urządzeń peryferyjnych, języków programowania, systemu operacyjnego, wersji kompilatora, wykorzystania oprogramowania powłoki oraz wszelkich szczegółów dotyczących interfejsu użytkownika (UI) i doświadczenia użytkownika (UX)
- W przypadku zleceniodawców składających rozszerzoną dokumentację wymagane są specyfikacje projektowe oprogramowania lub systemu (SDS), zawierające informacje dotyczące oprogramowania już od etapu projektowania. Podczas gdy SRS opisuje zamierzoną funkcjonalność oprogramowania, SDS zawiera szczegółowe informacje na temat metodologii wdrażania wymagań wymienionych w SRS. SDS musi zawierać kompleksowy opis techniczny projektu wraz z odpowiednimi informacjami na temat przeznaczenia i działania oprogramowania, które odnoszą się do SRS, a także informacją, czy do obsługi oprogramowania wymagana jest pomoc, czy też jest to zaawansowany system CAD oparty na modelach sztucznej inteligencji (AI) lub sieci neuronowej (ML ).
- Zgodnie z tym nowym projektem wytycznych przestrzeganie uznanych w branży dobrowolnych standardów konsensusowych dotyczących wniosków regulacyjnych stałoby się łatwiejsze i bardziej zgodne z aktualnymi trendami, praktykami i innowacjami na rynku cyfrowych rozwiązań medycznych. Urządzenia wymagające zarówno podstawowej, jak i rozszerzonej dokumentacji muszą być zgodne z uznaną przez Komisję ds. Urządzeń Medycznych ( FDA) wersją normy ANSI/AAMI IEC 62304 „Oprogramowanie urządzeń medycznych – Proces cyklu życia oprogramowania”. Dokumentacja rozszerzona wymaga dodatkowego opisu pełnej konfiguracji wraz ze jeszcze bardziej szczegółowymi informacjami na temat planu opracowania projektu i utrzymania w ramach cyklu życia oprogramowania, co ma na celu zapewnienie większej przejrzystości podczas przeglądu
- W oparciu o analizę ryzyka przeprowadzoną zgodnie z wymogami rozporządzenia w sprawie systemu jakości (21 CFR 820) należy również uwzględnić informacje dotyczące bezpieczeństwa, takie jak środowisko pracy, skuteczność, dokładność, czas reakcji, czas opóźnienia, spójność, granice i zakres działania oraz wszelkie wartości bazowe lub progowe, których oprogramowanie wymaga do działania. Należy wspomnieć o zapewnieniu systemu nadzoru służącego do śledzenia danych rejestrowanych za pomocą pamięci urządzenia lub systemu przechowywania danych.
- W ramach cyklu życia oprogramowania niezbędne są weryfikacja i walidacja oprogramowania, które polegają na testowaniu jego elementów na poziomie systemu lub integracji. Jest to obowiązkowe w celu zapewnienia lepszej dokumentacji. Ponadto należy omówić opis protokołów testowych wraz z oczekiwanymi lub zaobserwowanymi wynikami, które pozwalają ustalić, czy system przeszedł test pomyślnie, czy nie.
- Wszelkie przypadki nierozwiązanych nieprawidłowości, takich jak błędy i usterki, które mogą wpływać na działanie oprogramowania, należy zidentyfikować i sklasyfikować zgodnie z taksonomią usterek określoną w normie ANSI/AAMI SW91 „Klasyfikacja usterek w oprogramowaniu medycznym”.
W przypadku wyrobów stanowiących produkt złożony lub sklasyfikowanych jako wyroby klasy III wysokiego ryzyka, a także w przypadku funkcji oprogramowania przeznaczonych do stosowania w ramach procedur oddawania i transfuzji krwi, które służą do oceny zgodności dawcy i biorcy, należy przedłożyć rozszerzoną dokumentację. W przypadku wyrobów wymagających specjalnej dokumentacji należy przestrzegać wymogów dotyczących rozszerzonej dokumentacji. Dokumentacja podstawowa powinna zawierać zwięzłe raporty dotyczące analizy zagrożeń, środków ograniczających zagrożenia oraz uzasadnienia ryzyka.
Zgodnie z zobowiązaniami wynikającymi z ustawy MDUFA IV Agencja ma opublikować ostateczną wersję wytycznych w ciągu 12 miesięcy od zakończenia okresu zgłaszania uwag do projektu. Fundacja na rzecz Rozwoju Technologii Medycznych ( FDA ) ogłosiła, że 16 grudnia 2021 r. zorganizuje seminarium internetowe dla producentów wyrobów medycznych, badaczy z branży cyfrowego zdrowia oraz specjalistów w celu omówienia tego projektu wytycznych.
Aby dowiedzieć się więcej na temat przed wprowadzeniem do obrotu zgłaszania funkcji oprogramowania urządzeń, reach skontaktuj sięz regionalnym ekspertem ds. regulacji, takim jak Freyr. Bądź na bieżąco. Dbaj o zgodność z przepisami.
