Oprogramowanie jako wyrób medyczny – MDR, klasyfikacja i dokumentacja techniczna

Oprogramowanie jako wyrób medyczny to między innymi aplikacje analizujące zdjęcia znamion w celu oceny ryzyka nowotworu czy programy przetwarzające zapis EKG, aby wykrywać zaburzenia rytmu serca. Takie rozwiązania mogą wspierać decyzje kliniczne, ale ich producent musi najpierw ustalić, czy oprogramowanie spełnia definicję wyrobu medycznego i podlega wymaganiom rozporządzenia MDR.

O statusie regulacyjnym programu nie decyduje jego zaawansowanie technologiczne ani możliwość uruchomienia na smartfonie. Kluczowe znaczenie ma przeznaczenie nadane przez producenta. Jeżeli oprogramowanie służy m.in. diagnozowaniu, monitorowaniu, przewidywaniu lub leczeniu chorób, może zostać zakwalifikowane jako wyrób medyczny.

Prawidłowa kwalifikacja oprogramowania jako wyrobu medycznego stanowi punkt wyjścia do określenia klasy ryzyka, przygotowania dokumentacji technicznej, przeprowadzenia oceny zgodności oraz zaplanowania nadzoru nad produktem po wprowadzeniu go do obrotu.

Oprogramowanie jako wyrób medyczny – definicja i przykłady

Oprogramowanie jako wyrób medyczny, określane jako Software as a Medical Device (SaMD), to oprogramowanie przeznaczone przez producenta do realizacji celów medycznych, które działa samodzielnie, a nie jako część sprzętowego wyrobu medycznego.

W praktyce oznacza to, że program może działać na standardowym komputerze, tablecie lub smartfonie, a jego funkcje mogą obejmować analizę danych pacjenta, wspomaganie decyzji klinicznych czy dostarczanie informacji wykorzystywanych do oceny stanu zdrowia.

Aplikacja zdrowotna a oprogramowanie medyczne

Warto rozróżnić dwa przykłady:

• Aplikacja licząca kroki i spalone kalorie – może wspierać użytkownika w monitorowaniu aktywności, ale sama taka funkcja nie przesądza o uznaniu programu za wyrób medyczny.
• Aplikacja analizująca zdjęcia znamion lub zapis EKG w celu wykrywania nieprawidłowości – może spełniać definicję oprogramowania jako wyrobu medycznego, ponieważ realizuje określony cel medyczny.

Decydujące znaczenie ma więc deklarowane przeznaczenie programu i jego funkcja, a nie to, czy wykorzystuje zaawansowane algorytmy.

Oprogramowanie musi również spełniać pozostałe warunki wynikające z definicji wyrobu medycznego. Nie działa na zasadzie mechanizmu farmakologicznego, immunologicznego ani metabolicznego, lecz przetwarza dane i wykonuje operacje zgodnie z zaprojektowanymi algorytmami.

Jakie przepisy regulują oprogramowanie jako wyrób medyczny?

Podstawowym unijnym aktem prawnym jest rozporządzenie Parlamentu Europejskiego i Rady (UE) 2017/745, czyli MDR (Medical Device Regulation).

W Polsce stosuje się również ustawę z 7 kwietnia 2022 r. o wyrobach medycznych. Uzupełnia ona ramy regulacyjne w zakresie krajowych kompetencji i procedur, w tym nadzoru nad rynkiem, reklamy wyrobów medycznych oraz odpowiedzialności administracyjnej za naruszenia przepisów.

Producent oprogramowania musi zatem uwzględnić zarówno wymagania unijne, jak i właściwe regulacje krajowe.

MDCG 2019-11 – praktyczne wsparcie przy kwalifikacji oprogramowania

W interpretacji wymagań MDR istotną rolę odgrywają dokumenty MDCG (Medical Device Coordination Group), czyli grupy ekspertów powołanej przez Komisję Europejską.

Szczególnie ważnym materiałem jest MDCG 2019-11, Guidance on Qualification and Classification of Software. Dokument zawiera wskazówki dotyczące kwalifikacji oprogramowania, interpretacji definicji wyrobu medycznego oraz klasyfikacji. Przedstawia również schematy decyzyjne i przykłady pomagające przeanalizować konkretne zastosowania.

W praktyce warto korzystać z tego przewodnika podczas oceny, czy dane oprogramowanie podlega MDR i jak określić jego klasę ryzyka. Dokument należy jednak traktować jako wytyczne interpretacyjne, a nie zamiennik samego rozporządzenia.

Klasyfikacja oprogramowania medycznego – reguła 11 MDR

Po ustaleniu, że oprogramowanie spełnia definicję wyrobu medycznego, producent musi określić jego klasę ryzyka. Ma ona wpływ na dalszą ścieżkę oceny zgodności, zakres wymaganej dokumentacji oraz udział jednostki notyfikowanej.

W przypadku oprogramowania szczególne znaczenie ma reguła 11 z załącznika VIII MDR.

Reguła ta odnosi się do oprogramowania dostarczającego informacje wykorzystywane do podejmowania decyzji diagnostycznych lub terapeutycznych, a także do oprogramowania przeznaczonego do monitorowania procesów fizjologicznych. Odpowiednia klasyfikacja zależy od przeznaczenia i możliwych konsekwencji działania programu.

Co wpływa na klasę ryzyka oprogramowania?

Podczas klasyfikacji należy przeanalizować przede wszystkim:

• Przeznaczenie medyczne – do jakiego zastosowania producent przewidział oprogramowanie.
• Znaczenie generowanych informacji – w jaki sposób wyniki programu wpływają na decyzje diagnostyczne lub terapeutyczne.
• Możliwe konsekwencje błędnego działania – jakie skutki dla pacjenta może mieć nieprawidłowy wynik albo brak właściwej informacji.
• Reguły MDR – która z reguł klasyfikacyjnych ma zastosowanie do danego rozwiązania.

Reguła 11 przewiduje różne klasy, w tym IIa, IIb i III dla określonych zastosowań związanych z decyzjami diagnostycznymi lub terapeutycznymi. Oprogramowanie do monitorowania procesów fizjologicznych również może podlegać różnym klasom, zależnie od charakteru monitorowanych parametrów i ryzyka. Pozostałe oprogramowanie objęte tą regułą może zostać zaklasyfikowane do klasy I, jeżeli spełnia warunki przewidziane w przepisach.

Nie należy więc automatycznie przypisywać klasy na podstawie nazwy produktu czy samej funkcji technicznej. Dwie aplikacje analizujące podobne dane mogą mieć inne klasy, jeżeli różnią się przeznaczeniem i potencjalnymi konsekwencjami błędnych wyników.

Wytyczne MDCG 2019-11 pomagają uporządkować tę ocenę, ale ostateczna klasyfikacja musi wynikać z analizy konkretnego wyrobu i właściwych przepisów MDR.

Dokumentacja techniczna oprogramowania medycznego – co powinna obejmować?

Dokumentacja techniczna jest jednym z podstawowych elementów wykazywania zgodności oprogramowania z wymaganiami MDR. Powinna opisywać produkt w sposób pozwalający ocenić jego przeznaczenie, działanie, bezpieczeństwo i skuteczność.

Nie ogranicza się do opisu funkcji aplikacji. Obejmuje cykl życia wyrobu: od projektowania i rozwoju, przez weryfikację i walidację, aż po monitorowanie po wprowadzeniu do obrotu.

1. Architektura oprogramowania i wymagania

Dokumentacja powinna przedstawiać architekturę rozwiązania, jego moduły, zależności i sposób współpracy poszczególnych elementów.

Należy uwzględnić wymagania funkcjonalne, określające, co program ma wykonywać, oraz niefunkcjonalne, odnoszące się między innymi do wydajności, niezawodności i bezpieczeństwa.

Opis powinien pozwalać powiązać wymagania z zaprojektowanymi funkcjami oraz sposobem ich sprawdzenia.

2. Analiza ryzyka

Producent powinien identyfikować zagrożenia związane z użytkowaniem oprogramowania, oceniać ryzyko i dokumentować zastosowane środki kontroli.

W przypadku rozwiązania wspierającego decyzje kliniczne istotne jest uwzględnienie potencjalnych skutków błędnych, niekompletnych lub niedostępnych informacji. Analiza ryzyka powinna być powiązana z projektowaniem, weryfikacją i walidacją produktu.

3. Weryfikacja i walidacja oprogramowania

Weryfikacja i walidacja pozwalają wykazać, że oprogramowanie spełnia określone wymagania i realizuje zamierzone przeznaczenie.

Dokumentacja powinna zawierać odpowiednie dowody potwierdzające wyniki tych działań. Sam fakt, że aplikacja uruchamia się i wykonuje zaprogramowane operacje, nie wystarcza do wykazania, że spełnia wszystkie wymagania dotyczące wyrobu medycznego.

4. Ocena kliniczna

Ocena kliniczna ma wykazać, że oprogramowanie osiąga zamierzony cel medyczny oraz jest bezpieczne i skuteczne w przewidzianym zastosowaniu.

Jej zakres powinien odpowiadać charakterowi i przeznaczeniu wyrobu. Wnioski muszą odnosić się do konkretnego zastosowania medycznego, a nie wyłącznie do technicznej poprawności działania programu.

5. Cyberbezpieczeństwo

Dokumentacja powinna obejmować zagrożenia związane z cyberbezpieczeństwem oraz rozwiązania zastosowane w celu ograniczenia ryzyka.

Ważne obszary to ochrona przed nieuprawnionym dostępem, zarządzanie podatnościami, bezpieczna komunikacja i aktualizacje. Zabezpieczenia powinny być uwzględniane już na etapie projektowania.

6. Nadzór po wprowadzeniu do obrotu

Producent powinien zaplanować monitorowanie działania wyrobu po udostępnieniu go użytkownikom. Obejmuje ono zbieranie i analizowanie informacji dotyczących bezpieczeństwa i skuteczności oraz reagowanie na wykryte problemy.

Plan i wyniki nadzoru muszą być odpowiednio udokumentowane. W praktyce jest to istotne również dlatego, że oprogramowanie może wymagać aktualizacji, a jego otoczenie technologiczne i profil zagrożeń mogą się zmieniać.

Cyberbezpieczeństwo oprogramowania medycznego – wymagania producenta

Cyberbezpieczeństwo bezpośrednio wiąże się z bezpieczeństwem wyrobu medycznego. Incydent może doprowadzić do utraty danych, zakłócenia działania programu lub ograniczenia dostępności informacji potrzebnych do podejmowania decyzji medycznych. W konsekwencji może wpłynąć na zdrowie, a w skrajnych przypadkach także na życie pacjenta.

Dlatego producent powinien zarządzać ryzykiem cyberbezpieczeństwa przez cały cykl życia wyrobu, a nie wyłącznie przed jego wprowadzeniem do obrotu.

W praktyce należy uwzględnić kilka obszarów:

• Ochrona danych – zapewnienie poufności, integralności i dostępności danych pacjentów oraz ograniczenie nieuprawnionego dostępu.
• Odporność na cyberataki – zastosowanie adekwatnych mechanizmów, takich jak uwierzytelnianie użytkowników, kontrola dostępu, szyfrowanie i bezpieczna komunikacja.
• Bezpieczne aktualizacje – usuwanie błędów i podatności bez powodowania nowych zagrożeń lub negatywnego wpływu na działanie wyrobu.
• Zarządzanie podatnościami – identyfikowanie nowych zagrożeń, ocena ich wpływu i wdrażanie odpowiednich działań naprawczych.
• Monitorowanie incydentów – zbieranie informacji o zdarzeniach związanych z bezpieczeństwem, analizowanie ich przyczyn i podejmowanie działań zapobiegających ich ponownemu wystąpieniu.

Szczególnego znaczenia nabiera utrzymywanie bezpieczeństwa po aktualizacjach i zmianach w środowisku, w którym działa program. Producent powinien monitorować pojawiające się podatności i zagrożenia, a w razie potrzeby udostępniać poprawki bezpieczeństwa.

ISO 13485 a oprogramowanie jako wyrób medyczny

Norma ISO 13485 określa wymagania dotyczące systemu zarządzania jakością w organizacjach związanych z wyrobami medycznymi. Pomaga uporządkować procesy, odpowiedzialności i dokumentację potrzebną do wykazywania zgodności regulacyjnej.

W kontekście oprogramowania medycznego istotne są przede wszystkim projektowanie i rozwój, nadzór nad dokumentacją, zarządzanie ryzykiem oraz kontrola procesów. System zarządzania jakością powinien wspierać spójne prowadzenie prac od etapu projektowania aż po nadzór nad wyrobem po wprowadzeniu do obrotu.

Samo wdrożenie ISO 13485 nie zastępuje jednak oceny zgodności z MDR. Norma pomaga uporządkować działania producenta, natomiast spełnienie wymagań rozporządzenia trzeba wykazać w odniesieniu do konkretnego wyrobu i jego przeznaczenia.

O 13485 Szkolenie Pełnomocnik Systemu – Szkolenie

Jeżeli interesuje Cię ten temat i chcesz zdobyć praktyczną i użyteczną wiedzę od wieloletnich ekspertów, to mamy dla Ciebie idealne rozwiązanie.

Wybierz szkolenie w Szkole Jakości:

• dostępne jest natychmiast,
• w najlepszej rynkowej cenie,
• przygotowane przez ekspertów,
• możesz konsultować się w grupie przez 365 dni od dnia zakupu
• oraz zyskujesz Certyfikaty w dwóch językach wydawane przez instytucję szkoleniową o numerze 2.18/00117/2020.

Dzięki nam nie tylko poszerzysz swoją wiedzę, ale także zyskasz pewność siebie i motywację do dalszego rozwoju.

Nie ograniczaj się do tego, co już wiesz – zacznij budować swoją przyszłość już dziś i poznaj swój pełen potencjał.
🚨 Sprawdź szczegóły na stronie ➡️ ISO 13485 Szkolenie Pełnomocnik Systemu

Podsumowanie

W przypadku oprogramowania medycznego kluczowe decyzje dotyczą kwalifikacji produktu, jego klasy ryzyka oraz zakresu dokumentacji wymaganej do wykazania zgodności z MDR.

W praktyce producent powinien:

1. Określić przeznaczenie oprogramowania i ocenić, czy spełnia definicję wyrobu medycznego.
2. Skorzystać z MDR i wytycznych MDCG 2019-11 przy analizie kwalifikacji i klasyfikacji.
3. Ustalić klasę ryzyka zgodnie z właściwymi regułami załącznika VIII MDR.
4. Przygotować dokumentację techniczną obejmującą projektowanie, analizę ryzyka, weryfikację i walidację, ocenę kliniczną oraz cyberbezpieczeństwo.
5. Zaplanować nadzór po wprowadzeniu wyrobu do obrotu i zarządzanie aktualizacjami oraz podatnościami.

O statusie oprogramowania jako wyrobu medycznego decyduje przede wszystkim jego przeznaczenie. Prawidłowa klasyfikacja, kompletna dokumentacja i działający system zarządzania jakością stanowią podstawę przygotowania produktu do wykazania zgodności regulacyjnej.