Cechy szczególne oprogramowania
Oprogramowanie różni się od tradycyjnych urządzeń medycznych pod jednym kluczowym względem: szybko się zmienia. Wydania, poprawki, środowiska chmurowe, interfejsy, funkcje AI i zagrożenia cyberbezpieczeństwa są naturalnymi elementami jego cyklu życia. Rozporządzenie MDR bierze to pod uwagę. W przypadku oprogramowania załącznik I wymaga m.in. najnowocześniejszego podejścia do cyklu rozwoju, zarządzania ryzykiem, weryfikacji i walidacji, a także minimalnych wymagań dotyczących sprzętu, sieci IT i ochrony przed nieautoryzowanym dostępem. Cyberbezpieczeństwo nie jest zatem drugorzędną kwestią IT, ale raczej częścią bezpieczeństwa i wydajności produktu.
Zwłaszcza w przypadku oprogramowania nie liczy się kod, ale cel medyczny. Aplikacja wellness nie kwalifikuje się jako oprogramowanie medyczne tylko dlatego, że jest technicznie złożona. I odwrotnie, pozornie prosta aplikacja może bardzo dobrze podlegać pod MDR, jeśli jej informacje są wykorzystywane do podejmowania decyzji diagnostycznych lub terapeutycznych. Aktualne wytyczne MDCG dotyczące kwalifikacji i klasyfikacji oprogramowania dokładnie wyjaśniają to rozróżnienie.
Wymagania MDR - gdzie można je znaleźć?
Każdy, kto chce wprowadzić oprogramowanie do obrotu zgodnie z MDR, powinien bardzo uważnie przeczytać odpowiednie sekcje rozporządzenia. Najważniejsze sekcje to:
Załącznik I, który określa ogólne wymagania dotyczące bezpieczeństwa i wydajności. W przypadku oprogramowania szczególnie istotne są wymagania dotyczące procesu rozwoju, zarządzania ryzykiem, bezpieczeństwa informacji, walidacji i środowiska IT.
Załączniki II i III regulują dokumentację techniczną, a także wymagania dotyczące nadzoru po wprowadzeniu do obrotu. W przypadku oprogramowania obejmuje to również dowody weryfikacji i walidacji oprogramowania jako część dokumentacji produktu.
Załącznik VIII, w szczególności zasada 11, ma kluczowe znaczenie dla klasyfikacji oprogramowania medycznego. MDCG 2019-11, zmienione w 2025 r., wyjaśnia trzy podstawowe zasady zasady 11: oprogramowanie, które dostarcza informacji do podejmowania decyzji diagnostycznych lub terapeutycznych; oprogramowanie, które monitoruje procesy fizjologiczne; oraz "wszelkie inne oprogramowanie". W zależności od znaczenia klinicznego, klasyfikacja może wahać się od klasy I do klasy III.
Artykuł 52 i załączniki IX-XI opisują ocenę zgodności. W przypadku urządzeń klasy I deklaracja zgodności jest zazwyczaj wystawiana przez samego producenta; w przypadku urządzeń klasy IIa i wyższych wymagane jest zaangażowanie jednostki notyfikowanej.
Załącznik XIV stanowi centralne odniesienie do oceny klinicznej i obserwacji klinicznych po wprowadzeniu do obrotu (PMCF). Szczególnie w przypadku oprogramowania jest to obszar, który często jest systematycznie ustanawiany zbyt późno.
Najważniejsze standardy dla oprogramowania medycznego
Rozporządzenie MDR określa wymogi regulacyjne. Jednak w praktyce niektóre normy są szczególnie ważne, ponieważ definiują "aktualny stan wiedzy".
NormaIEC 62304 to podstawowa norma dotycząca cyklu życia oprogramowania medycznego. Opisuje procesy rozwoju i utrzymania oprogramowania, gdy samo oprogramowanie jest urządzeniem medycznym lub integralną częścią urządzenia medycznego.
ISO 14971 to norma referencyjna dotycząca zarządzania ryzykiem związanym z wyrobami medycznymi, w tym oprogramowaniem jako wyrobem medycznym.
ISO 13485 to centralny standard zarządzania jakością dla urządzeń medycznych w całym cyklu życia produktu. Dla producentów pragnących ustanowić solidną organizację zgodną z MDR, służy ona jako praktyczna podstawa operacyjna.
NormaIEC 62366-1 obejmuje inżynierię użyteczności. Jest to szczególnie istotne w przypadku oprogramowania, ponieważ nieprawidłowe działanie, wprowadzające w błąd wskazówki dla użytkownika lub niejasne alarmy mogą mieć natychmiastowe konsekwencje dla bezpieczeństwa.
NormaIEC 82304-1 jest szczególnie istotna dla oprogramowania medycznego na ogólnych platformach IT, tj. dla produktów bez dedykowanego sprzętu. Norma odnosi się do bezpieczeństwa i ochrony na poziomie produktu i dlatego ma ogromne znaczenie dla wielu samodzielnych produktów oprogramowania lub oprogramowania jako urządzenia medycznego (SaMD). Na szczególną uwagę zasługuje fakt, że norma IEC 82304-1 definiuje konkretne wymagania dotyczące walidacji SaMD i jest jednocześnie przywoływana w normie IEC 62304, która jest zharmonizowana w ramach MDR.
Klasyfikacja: Kluczowy pierwszy krok
Najczęstszym i najważniejszym pytaniem początkowym jest: Do jakiej klasy należy moje oprogramowanie? To właśnie tutaj wiele projektów kończy się niepowodzeniem - nie z powodu technologii, ale z powodu niejasnego zamierzonego celu. Zgodnie z MDCG 2019-11 Rev.1 zasada 11 jest zasadniczo stosowana w oparciu o to, czy oprogramowanie dostarcza informacji do podejmowania decyzji diagnostycznych lub terapeutycznych, monitoruje procesy fizjologiczne, czy też należy do kategorii rezydualnej. Przykłady w wytycznych pokazują, że oprogramowanie diagnostyczne lub wspierające terapię może szybko zostać zaklasyfikowane do klasy IIa, IIb lub III, podczas gdy "całe inne oprogramowanie" należy do klasy I.
Z perspektywy jednostki notyfikowanej jest zatem jasne: klasyfikacja nie jest końcowym krokiem administracyjnym, ale podstawą całej strategii wydawania pozwoleń na dopuszczenie do obrotu. Wpływa ona na zakres dowodów klinicznych, szczegółowość dokumentacji technicznej, wymagania PMS/PMCF oraz, oczywiście, na kwestię tego, czy i w jakim stopniu jednostka notyfikowana musi być zaangażowana.
Dane kliniczne: Nie zadziała bez dowodów klinicznych
W przypadku oprogramowania medycznego dowody kliniczne nie są "miłym dodatkiem". MDCG 2020-1 wyraźnie stwierdza, że oprogramowanie medyczne o zamierzonym celu i deklarowanych korzyściach klinicznych wymaga dowodów klinicznych w ramach oceny zgodności. Celem jest wykazanie, że oprogramowanie jest bezpieczne, osiąga swoją wydajność i zapewnia deklarowane korzyści kliniczne.
W praktyce oznacza to, że w przypadku oprogramowania nie wystarczy po prostu wykazać, że algorytm działa technicznie. Należy również ocenić, czy oprogramowanie zapewnia prawidłowe informacje w kontekście klinicznym, w jaki sposób te informacje są wykorzystywane i czy faktycznie skutkuje to możliwymi do wykazania korzyściami. Ocena kliniczna nie jest jednorazowym dokumentem, ale ciągłym procesem.
Obserwacja kliniczna po wprowadzeniu produktu na rynek (PMCF)
PMCF jest często niedoceniany w kontekście oprogramowania. MDR definiuje PMCF jako ciągły proces, który aktualizuje ocenę kliniczną i musi być zakotwiczony w planie PMS producenta. Dokładnie to opisuje szablon PMCF MDCG.
PMCF jest szczególnie ważny w przypadku oprogramowania, ponieważ konteksty użytkowania, systemy operacyjne, interfejsy, zagrożenia cybernetyczne i wzorce użytkowania klinicznego stale się zmieniają. Producenci potrzebują zatem nie tylko solidnej strategii autoryzacji marketingowej, ale także solidnego systemu do gromadzenia i oceny rzeczywistych danych dotyczących wydajności i bezpieczeństwa po wprowadzeniu produktu na rynek oraz do przekazywania ich z powrotem w celu ulepszenia produktu.
Jak wygląda proces certyfikacji z perspektywy jednostki notyfikowanej?
Drogę do certyfikacji można podsumować w sześciu kluczowych krokach.
Po pierwsze: Należy precyzyjnie zdefiniować zamierzone zastosowanie. Jest to jedyny sposób, aby jasno określić, czy oprogramowanie podlega MDR.
Po drugie: oprogramowanie musi być prawidłowo sklasyfikowane - zazwyczaj w oparciu o załącznik VIII i zasadę 11.
Potrzecie: Firma musi posiadać odpowiedni system zarządzania jakością i weryfikowalny, najnowocześniejszy proces rozwoju, zazwyczaj oparty na normach ISO 13485, IEC 62304, ISO 14971 i innych normach w zależności od produktu.
Poczwarte: Dokumentacja techniczna musi być kompletna, ustrukturyzowana i identyfikowalna - w tym weryfikacja i walidacja oprogramowania.
Po piąte: Ocena kliniczna, PMS i PMCF muszą mieć strukturę odpowiednią dla produktu.
Poszóste: Jeśli klasyfikacja wymaga zaangażowania jednostki notyfikowanej, formalna ocena zgodności jest zgodna z procedurami określonymi w MDR.
