Krótka odpowiedź: gdy oprogramowanie ma przeznaczenie medyczne (diagnoza, profilaktyka, monitorowanie, przewidywanie, prognozowanie, leczenie), jest ono wyrobem medycznym zgodnie z unijnym Rozporządzeniem o Wyrobach Medycznych (MDR, 2017/745) i otrzymuje klasę ryzyka: I, IIa, IIb lub III, głównie na podstawie Zasady 11 z Załącznika VIII. Klasa decyduje, czy można dokonać samooceny (tylko klasa I), czy potrzebny jest jednostka notyfikowana, jak głęboka musi być ocena kliniczna i jak przebiega nadzór po wprowadzeniu do obrotu. Oddzielnie, norma inżynieryjna IEC 62304 nadaje oprogramowaniu klasę bezpieczeństwa: A (nie ma możliwości obrażeń), B (możliwe niepoważne obrażenia) lub C (możliwa śmierć lub poważne obrażenia), która decyduje o tym, ile dokumentacji, projektowania i testowania wymaga cykl życia. Te dwie klasyfikacje są powiązane, ale niezależne, i obie są ustalane na podstawie szkody, jaką oprogramowanie może spowodować, a nie jego złożoności.
Krok 1: Czy to w ogóle wyrób?
Oprogramowanie jest wyrobem medycznym zgodnie z unijnym rozporządzeniem MDR, gdy jego zamierzone zastosowanie ma charakter medyczny: diagnoza, zapobieganie, monitorowanie, przewidywanie, prognozowanie lub leczenie (Artykuł 2(1)). Oprogramowanie, które jedynie przechowuje, archiwizuje, komunikuje, wyświetla lub wyszukuje dane, nie jest wyrobem; oprogramowanie, które tworzy lub modyfikuje informacje medyczne w celu wsparcia decyzji diagnostycznej lub terapeutycznej, jest wyrobem, zgodnie z wytycznymi MDCG 2019-11.
Definicja MDR (Artykuł 2(1)) opiera się na przeznaczeniu. Oprogramowanie, które przechowuje, archiwizuje, komunikuje, wyświetla lub wykonuje proste wyszukiwania danych, nie jest wyrobem (MDCG 2019-11 wymienia te przypadki). Oprogramowanie, które tworzy lub modyfikuje informacje medyczne w celu wsparcia diagnozy lub decyzji terapeutycznych, jest. Zapis pokazujący wartość laboratoryjną z zakresem referencyjnym laboratorium nie jest; oprogramowanie, które informuje użytkownika, że wartość wskazuje na schorzenie lub zaleca dawkę, jest. Zobacz Czy aplikacja zdrowotna jest wyrobem medycznym? po szczegółowe omówienie etapu kwalifikacji.
Krok 2: Klasa ryzyka MDR, Zasada 11
Zasada 11 MDR klasyfikuje oprogramowanie jako wyrób medyczny na podstawie szkody, jaką mogłaby spowodować błędna decyzja. Oprogramowanie dostarczające informacji do decyzji diagnostycznych lub terapeutycznych jest domyślnie klasą IIa, klasą IIb, jeśli takie decyzje mogą spowodować poważne pogorszenie stanu zdrowia lub konieczność przeprowadzenia operacji, a klasą III, jeśli mogą spowodować śmierć lub nieodwracalne pogorszenie stanu zdrowia. Oprogramowanie monitorujące jest klasy IIa lub IIb w przypadku parametrów życiowych.
| Oprogramowanie przeznaczone do… | Klasa MDR |
|---|---|
| dostarczania informacji wykorzystywanych do podejmowania decyzji o charakterze diagnostycznym lub terapeutycznym (domyślnie) | IIa |
| …gdzie takie decyzje mogą spowodować śmierć lub nieodwracalne pogorszenie stanu zdrowia | III |
| …gdzie takie decyzje mogą spowodować poważne pogorszenie stanu zdrowia lub interwencję chirurgiczną | IIb |
| monitorowania procesów fizjologicznych (domyślnie) | IIa |
| …monitorowania kluczowych parametrów fizjologicznych, gdzie ich zmiany mogą prowadzić do bezpośredniego zagrożenia pacjenta | IIb |
| wszystko inne (oprogramowanie będące wyrobem, ale nie należące do powyższych kategorii) | I |
Zasada 11 przeniosła większość wcześniej klasyfikowanego jako klasa I oprogramowania do klasy IIa lub wyższej, co jest głównym powodem, dla którego MDR został odczuwany jako znacząca zmiana dla cyfrowego zdrowia. MDCG 2019-11 i ramy ryzyka IMDRF (znaczenie informacji × stan sytuacji opieki zdrowotnej) pomagają w umieszczeniu przypadków granicznych. Oprogramowanie sterujące urządzeniem sprzętowym lub wpływające na nie przyjmuje klasę tego urządzenia (Zasada 3.3 przepisów wykonawczych).
Konsekwencje według klasy: klasa I jest deklarowana samodzielnie z dokumentacją techniczną i rejestracją, bez jednostki notyfikowanej (z wyjątkiem Im, Is, Ir); klasa IIa wymaga oceny systemu jakości przez jednostkę notyfikowaną i próbki dokumentacji technicznej; klasa IIb wymaga tego samego z większą analizą dokumentacji; klasa III wymaga pełnego przeglądu dokumentacji technicznej i, tam gdzie to stosowne, konsultacji z panelem ekspertów. Wszystkie klasy wymagają systemu zarządzania jakością, oceny klinicznej proporcjonalnej do klasy, osoby odpowiedzialnej za zgodność z przepisami, UDI, rejestracji w EUDAMED, nadzoru po wprowadzeniu do obrotu i systemu zgłaszania zdarzeń niepożądanych.
Krok 3: Klasa bezpieczeństwa oprogramowania IEC 62304
Klasa bezpieczeństwa oprogramowania IEC 62304 ocenia oprogramowanie jako wyrób medyczny na podstawie najgorszej szkody, do której mogłoby się przyczynić, po uwzględnieniu zewnętrznych środków kontroli ryzyka: klasa A, gdy nie jest możliwe żadne obrażenie; klasa B, gdy jest możliwe niepoważne obrażenie; klasa C, gdy jest możliwe śmierć lub poważne obrażenie. Klasa ta określa, jak wiele projektowania, weryfikacji i dokumentacji wymaga cykl życia oprogramowania.
IEC 62304 (2006, ze zmianami z 2015) to zharmonizowana norma dotycząca procesów cyklu życia oprogramowania wyrobów medycznych. Jej klasa bezpieczeństwa wynika z najgorszej sytuacji zagrożenia, do której oprogramowanie może się przyczynić, po uwzględnieniu środków kontroli ryzyka zewnętrznych wobec oprogramowania:
| Klasa | Sytuacja zagrożenia może prowadzić do… | Wymagania dotyczące cyklu życia |
|---|---|---|
| A | braku obrażeń lub uszczerbku na zdrowiu | Plan rozwoju oprogramowania, wymagania, wydanie; rozwiązywanie problemów; zarządzanie konfiguracją |
| B | niepoważnych obrażeń | A: plus projekt architektoniczny, weryfikacja integracji i testy systemowe, udokumentowana weryfikacja jednostek |
| C | śmierci lub poważnych obrażeń | B: plus szczegółowy projekt każdej jednostki, dodatkowa segregacja architektoniczna, bardziej rygorystyczna weryfikacja |
Klasy są przypisywane dla każdego systemu oprogramowania i mogą być przypisywane dla elementu oprogramowania po jego dekompozycji, tak aby tylko ryzykowne części podlegały rygorowi klasy C; norma wyjaśnia argumentację segregacji, której to wymaga. ISO 14971 (zarządzanie ryzykiem) zasila klasyfikację; IEC 82304-1 dodaje wymagania na poziomie produktu dla oprogramowania zdrowotnego działającego na platformach ogólnego przeznaczenia (telefony, chmura).
Jak te dwie klasyfikacje współdziałają
Klasa ryzyka MDR i klasa bezpieczeństwa IEC 62304 są niezależne: klasa MDR (od I do III) decyduje o ścieżce regulacyjnej i zaangażowaniu jednostki notyfikowanej, podczas gdy klasa IEC 62304 (od A do C) decyduje o rygorze procesu inżynieryjnego. Aplikacja klasy IIa może być klasy 62304 B lub C, w zależności od szkody, jaką mógłby spowodować błędny wynik.
Klasa MDR dotyczy ścieżki regulacyjnej; klasa IEC 62304 dotyczy procesu inżynieryjnego. Aplikacja klasy IIa zgodnie z Zasadą 11 może być klasy IEC 62304 B (nieprawidłowe informacje mogą prowadzić do niepoważnego opóźnienia w opiece) lub klasy C (jeśli błędna sugestia dawki może być śmiertelna). Urządzenie klasy I jest zazwyczaj klasy 62304 A, ale niekoniecznie. Jednostki notyfikowane oczekują, że dokumentacja techniczna wykaże klasę 62304 wraz z uzasadnieniem, dokumentację cyklu życia na tym poziomie oraz powiązanie z dokumentacją zarządzania ryzykiem. Bezpieczeństwo cybernetyczne (MDCG 2019-16, IEC 81001-5-1) jest oceniane równolegle.
Przykład praktyczny
Praktyczny przykład oprogramowania jako wyrobu medycznego (SaMD): aplikacja do śledzenia objawów, która rejestruje, wyświetla i udostępnia objawy, nie jest wyrobem medycznym. Dodanie funkcji, która ocenia objawy według zweryfikowanej skali i informuje użytkownika, kiedy powinien zasięgnąć porady medycznej, czyni ją wyrobem, domyślnie klasy IIa według zasady 11 MDR, z klasą IEC 62304 B, lub klasą C w przypadku zastosowania kardiologicznego.
Aplikacja do śledzenia objawów, która pozwala użytkownikom rejestrować objawy, przeglądać trendy i udostępniać je lekarzowi: nie jest wyrobem (przechowywanie, wyświetlanie, komunikacja). Ta sama aplikacja dodaje funkcję, która ocenia zarejestrowane objawy według zweryfikowanej skali i informuje użytkownika, kiedy wynik sugeruje konieczność zasięgnięcia porady lekarskiej: jest wyrobem, domyślnie klasa IIa zgodnie z Zasadą 11 (informacje do decyzji diagnostycznej; błędne stwierdzenie "nie ma potrzeby szukania pomocy" może opóźnić leczenie, co jest poważne, ale zazwyczaj nie nieodwracalne, więc nie IIb ani III, chyba że celowana choroba na to wskazuje). IEC 62304: fałszywe uspokojenie może prowadzić do opóźnienia w opiece, od niepoważnego do poważnego w zależności od schorzenia, więc klasa B, potencjalnie C w przypadku zastosowania kardiologicznego. Ścieżka: system zarządzania jakością ISO 13485, jednostka notyfikowana, ocena kliniczna skali, inżynieria użyteczności (IEC 62366-1), nadzór po wprowadzeniu do obrotu.
Stany Zjednoczone, krótko
W Stanach Zjednoczonych FDA reguluje oprogramowanie jako wyrób medyczny na podstawie zamierzonego zastosowania, z klasami I, II i III oraz ścieżkami 510(k), De Novo i PMA. Ustawa 21st Century Cures Act wyłącza z definicji wyrobu oprogramowanie administracyjne, produkty ogólnego przeznaczenia wellness, elektroniczną dokumentację medyczną i pewne narzędzia wspomagające decyzje kliniczne. FDA uznaje IEC 62304 za normę konsensusową.
FDA reguluje oprogramowanie jako wyrób medyczny na tej samej zasadzie przeznaczenia, z klasami I, II i III oraz ścieżkami 510(k), De Novo i PMA. Ustawa 21st Century Cures Act (sekcja 3060) wyłączyła kilka kategorii ze statusu wyrobu: oprogramowanie administracyjne, ogólne wellness, elektroniczna dokumentacja medyczna oraz systemy wsparcia decyzji klinicznych, które pozwalają lekarzowi na niezależne przeglądanie podstaw rekomendacji (wytyczne FDA z 2022 r. dotyczące CDS interpretują to wąsko). FDA uznaje IEC 62304 za normę konsensusową i od 2023 r. wymaga dokumentacji dotyczącej bezpieczeństwa cybernetycznego dla "urządzeń cybernetycznych". ISO 13485 stała się podstawą amerykańskiego rozporządzenia o systemie jakości (QMSR) w 2026 r.
W Anpheros
Anpheros Daily przechowuje, wyświetla i udostępnia; nie ocenia, nie interpretuje ani nie zaleca, a jego przeznaczenie to jasno określa. W związku z tym nie jest wyrobem medycznym zgodnie z Zasadą 11 ani wyłączeniami z ustawy Cures Act, a zespół stosuje bezpieczeństwo w stylu ISO 27001 i udokumentowane praktyki oprogramowania bez procedury dla wyrobów. Gdyby kiedykolwiek dodano funkcję o przeznaczeniu medycznym, zostałaby ona sklasyfikowana zgodnie z Zasadą 11 i opracowana zgodnie z IEC 62304 przed wydaniem. Zobacz Przejrzystość zdrowotna.
Ta strona wyjaśnia regulacje dla zespołów produktowych i inżynieryjnych. Nie stanowi porady prawnej; teksty podane w Źródłach są wiążące, a Twój inspektor ochrony danych, jednostka notyfikowana lub doradca podejmuje decyzje w Twojej sprawie. Ostatnia weryfikacja: październik 2026.
Powiązane strony
- Czy aplikacja zdrowotna jest wyrobem medycznym? EU MDR Zasada 11
- MDR vs IVDR
- Wyjaśnienie CDS Hooks
- Mapa regulacji danych zdrowotnych
- Unijny Akt o Sztucznej Inteligencji i AI w zdrowiu
Źródła
- Rozporządzenie (UE) 2017/745 (MDR), Załącznik VIII, EUR-Lex
- MDCG 2019-11: Kwalifikacja i klasyfikacja oprogramowania
- IEC 62304:2006+AMD1:2015, Procesy cyklu życia oprogramowania wyrobów medycznych
- IEC 82304-1:2016, Bezpieczeństwo produktów oprogramowania zdrowotnego
- FDA: Wytyczne dotyczące oprogramowania wspierającego decyzje kliniczne (2022)
- FDA: Oprogramowanie jako wyrób medyczny
Najczęstsze pytania
Czy oprogramowanie może być klasy I zgodnie z MDR?
Tak, ale rzadko: tylko oprogramowanie o przeznaczeniu medycznym, które ani nie dostarcza informacji do podejmowania decyzji diagnostycznych lub terapeutycznych, ani nie monitoruje procesów fizjologicznych. Większość aplikacji kwalifikujących się jako wyroby trafia do klasy IIa.
Czy urządzenie klasy IIa wymaga badań klinicznych?
Wymaga oceny klinicznej, która może opierać się na literaturze, danych o równoważności i danych dotyczących wydajności; badanie kliniczne jest wymagane, gdy istniejące dowody są niewystarczające. Oprogramowanie deklarujące wydajność diagnostyczną zazwyczaj wymaga własnego badania wydajności.
Czy IEC 62304 jest obowiązkowe?
Jest to norma zharmonizowana, więc jej przestrzeganie stanowi domniemanie zgodności z wymaganiami MDR dotyczącymi oprogramowania (Załącznik I, 17). Można zastosować inne podejście, ale wtedy trzeba udowodnić równoważność, czego w praktyce nikt nie robi.
A co z funkcjami AI?
Obowiązują te same zasady, a dodatkowo unijny Akt o Sztucznej Inteligencji: urządzenie z oceną jednostki notyfikowanej jest systemem AI wysokiego ryzyka zgodnie z Załącznikiem I, z wymaganiami dotyczącymi danych, logowania, przejrzystości i nadzoru ludzkiego ocenianymi razem z MDR.
Wypróbuj za darmo w sandboksie
Pierwsze wywołanie FHIR w 5 minut. API HL7 FHIR R4 z wbudowaną zgodą pacjenta: wypróbuj w piaskownicy, a następnie połącz własną aplikację lub system kliniczny.
Za darmo · 30 syntetycznych pacjentów · bez karty
Anpheros tworzy dokumentację medyczną, nad którą pacjent ma kontrolę i którą może udostępniać dowolnej klinice, na platformie HL7 FHIR R4, z siedzibą w UE. Te przewodniki pomogą Ci zrozumieć i uporządkować informacje o Twoim zdrowiu; nie zastępują one wizyty u lekarza.
O Anpheros →