Poświęciłeś miesiące na rozwój oprogramowania swojego wyrobu medycznego, zatrudnienie najlepszych inżynierów i stworzenie – jak sądzisz – innowacyjnego produktu. Następnie nadchodzi przegląd regulacyjny i okazuje się, że Twoja dokumentacja IEC 62304 jest niekompletna.
Brzmi znajomo?
Nie jesteś w tym osamotniony. Ta sytuacja powtarza się niezliczoną ilość razy w branży wyrobów medycznych, kosztując firmy miesiące opóźnień i tysiące dolarów na poprawki. Większość firm produkujących wyroby medyczne popełnia błąd, traktując zgodność z normą IEC 62304 jako problem z dokumentacją, a nie jako kompletne ramy bezpieczeństwa.
Wynik?
Nieudane audyty, odrzucenia przez urzędy regulacyjne i zagrożenie bezpieczeństwa pacjentów.
Ten blog obejmuje: Czym jest IEC 62304? Zdefiniowane w nim klasy bezpieczeństwa oprogramowania oraz drogę do zgodności z przepisami.
Czym jest IEC 62304 i dlaczego ma znaczenie dla Twojego wyrobu?
IEC 62304 to międzynarodowa norma dotycząca procesów cyklu życia oprogramowania wyrobów medycznych, uznawana przez US FDA i inne agencje regulacyjne na całym świecie. Norma to nie tylko kolejna pozycja do odhaczenia na liście wymagań – to Twój plan działania pozwalający stworzyć bezpieczne, skuteczne oprogramowanie dla wyrobów medycznych, które chroni pacjentów i szybciej trafia na rynek.
Norma ma zastosowanie w każdym przypadku, gdy oprogramowanie jest ważnym elementem produkcji wyrobów medycznych – niezależnie od tego, czy Twoje oprogramowanie działa samodzielnie jako wyrób medyczny (Software as a Medical Device lub SaMD), jest wbudowane w wyrób (Software in a Medical Device lub SiMD), czy jest używane w procesie produkcyjnym. Pomyśl o wszystkim, od mobilnych aplikacji zdrowotnych po złożone roboty chirurgiczne. Jeśli Twoje oprogramowanie mieści się w tym zakresie, potrzebujesz certyfikacji IEC 62304.
Dlaczego zgodność z normą IEC 62304 jest ważna?
- Wymagana do uzyskania zgody US FDA i oznakowania CE dla oprogramowania typu SaMD
- Systematyczne podejście do identyfikacji i ograniczania ryzyka związanego z oprogramowaniem
- Zharmonizowana norma akceptowana na całym świecie
- Udokumentowany dowód należytej staranności w tworzeniu oprogramowania
- Szybsze wprowadzanie na rynek dzięki odpowiedniemu planowaniu
Nasze doświadczenie we współpracy z firmami medycznymi na całym świecie pokazuje, że organizacje wdrażające normę IEC 62304 na wczesnym etapie procesu rozwoju osiągają zatwierdzenie wniosków za pierwszym razem i skracają czas wprowadzania produktu na rynek średnio o 4 do 6 miesięcy.
Zrozumienie klas bezpieczeństwa oprogramowania według normy IEC 62304
Zgodność z normą IEC 62304 zaczyna się od prawidłowego określenia klasy ryzyka związanego z bezpieczeństwem oprogramowania. Jeśli zrobisz to źle, albo przygotujesz zbyt złożoną dokumentację, albo pominiesz kluczowe wymagania bezpieczeństwa.
IEC 62304 Klasa A: Brak możliwości obrażeń
- Brak wpływu na sytuacje niebezpieczne
- Minimalne wymagania dotyczące dokumentacji
- Brak wymogu weryfikacji jednostki
- Przykład: Oprogramowanie administracyjne do planowania wizyt
IEC 62304 Klasa B: Możliwość wystąpienia obrażeń innych niż poważne
- Może przyczynić się do sytuacji niebezpiecznych skutkujących obrażeniami innymi niż poważne
- Umiarkowane wymagania dotyczące dokumentacji i testowania
- Wymagana weryfikacja jednostki
- Przykład: Oprogramowanie monitorujące parametry życiowe, ale posiadające systemy zapasowe
IEC 62304 Klasa C: Możliwość śmierci lub poważnych obrażeń
- Może przyczynić się do sytuacji niebezpiecznych skutkujących śmiercią lub poważnymi obrażeniami
- Wymagany najwyższy poziom dokumentacji i weryfikacji
- Szczegółowa dokumentacja projektowa jest obowiązkowa
- Przykład: Oprogramowanie sterujące podawaniem insuliny lub systemami podtrzymywania życia
Klasyfikacja ryzyka nie dotyczy wyłącznie tego, do czego przeznaczone jest oprogramowanie – chodzi o to, co dzieje się w przypadku jego awarii. Prosta aplikacja wykonująca obliczenia dawek może zostać zaklasyfikowana do Klasy C, jeśli nieprawidłowe obliczenia mogłyby doprowadzić do poważnej szkody.
5 niezbędnych procesów według normy IEC 62304, które musisz wdrożyć:
Norma IEC 62304 ustanawia wymagania dotyczące pięciu głównych procesów (punkty 5-9) wraz z przewodnikiem wdrażania krok po kroku.
Proces 1: Planowanie rozwoju oprogramowania (Punkt 5.1)
Co musisz zrobić?

Proces 2: Analiza wymagań dotyczących oprogramowania (Punkt 5.2)
Co musisz zrobić?

Wskazówka: Wymagania, których nie można przetestować, to nie wymagania – to życzenia. Każde wymaganie musi mieć odpowiadającą mu metodę weryfikacji.
Proces 3: Architektura i projekt oprogramowania (Punkty 5.3-5.4)
Kluczowe rezultaty:
- Projekt architektoniczny oprogramowania
- Skrupulatny projekt oprogramowania klasy C
- Specyfikacje interfejsów
- Strategia segregacji w celu kontroli ryzyka
Weryfikacja rzeczywistości architektonicznej: Czy potrafisz wyjaśnić architekturę swojego oprogramowania regulatorowi w 10 minut? Jeśli nie, jest ona zbyt złożona lub słabo udokumentowana.
Proces 4: Wdrożenie i testowanie (klauzule 5.5-5.7)
Wymagane poziomy testów:
- Testy jednostkowe (klasa B i C)
- Testy integracyjne (klasa B i C)
- Testy systemowe (wszystkie klasy)
- Testy akceptacyjne
Prawda o testowaniu: Więcej testów nie oznacza lepszych testów. Należy położyć nacisk na testowanie oparte na ryzyku, które weryfikuje wymagania bezpieczeństwa.
Proces 5: Integracja zarządzania ryzykiem (klauzula 7)
W tym miejscu wiele firm popełnia błędy. Zarządzanie ryzykiem według normy IEC 62304 nie jest osobnym działaniem – jest zintegrowane z całym procesem rozwoju.
Wymagania dotyczące zarządzania ryzykiem oprogramowania:
- Dowiedz się, w jaki sposób oprogramowanie przyczynia się do sytuacji niebezpiecznych
- Określ środki kontroli ryzyka dla każdej potencjalnej przyczyny
- Potwierdź skuteczność środków kontroli ryzyka
- Zachowaj śledzenie od zagrożeń do środków kontroli
Radzenie sobie z SOUP: Oprogramowanie o nieznanym pochodzeniu w normie IEC 62304
Każdy system oprogramowania wyrobu medycznego wykorzystuje komponenty firm trzecich – systemy operacyjne, bazy danych, biblioteki i usługi w chmurze. Norma IEC 62304 nazywa je „Oprogramowaniem o nieznanym pochodzeniu” (SOUP), a prawidłowe zarządzanie nimi ma kluczowe znaczenie dla zgodności z przepisami (np. Windows, Linux, Android, MySQL, stosy TCP/IP, AWS, Azure, Google Cloud APIs, kryptografia, przetwarzanie obrazu).
Wymagania dotyczące identyfikacji SOUP:
- Udokumentuj nazwę, wersję i producenta każdego elementu SOUP
- Przeanalizuj potencjalne zagrożenia dla pacjentów, operatorów i osób trzecich
- Przeanalizuj opublikowane listy nieprawidłowości, takie jak błędy
- Zweryfikuj, dlaczego każdy element SOUP jest odpowiedni do zamierzonego zastosowania
Strategia zarządzania ryzykiem dla oprogramowania SOUP:
- Uwzględnij awarie SOUP, aby zapobiec skutkom obejmującym cały system
- Wdróż mechanizmy nadzorujące i kontrolę stanu
- Zapewnij funkcjonalność zapasową dla krytycznego oprogramowania SOUP
- Zweryfikuj działanie SOUP w swoim konkretnym zastosowaniu
Normy IEC 62304 i ISO 14971: Skuteczne połączenie zarządzania ryzykiem
Norma IEC 62304 nie zastępuje zarządzania ryzykiem wg ISO 14971 – rozszerza je o zagrożenia specyficzne dla oprogramowania.
Podejście integracyjne:
Rozpocznij od normy ISO 14971 i przeprowadź analizę zagrożeń na poziomie systemu
- Zidentyfikuj przyczyny programowe dla każdej sytuacji zagrożenia, oceń, czy oprogramowanie może być przyczyną współtowarzyszącą
- Zastosuj normę IEC 62304, dokumentując środki kontroli ryzyka specyficzne dla oprogramowania
- Zweryfikuj skuteczność, testując, czy zabezpieczenia oprogramowania rzeczywiście działają
Norma ISO 14971 bada prawdopodobieństwo wystąpienia szkody; IEC 62304 przyjmuje 100% prawdopodobieństwo awarii i skupia się na jej skutkach.
Częste błędy związane z normą IEC 62304 i sposoby ich unikania
Błąd 1: Niewłaściwa klasyfikacja bezpieczeństwa oprogramowania

Błąd 2: Nieodpowiednie zarządzanie oprogramowaniem SOUP
- Pomyłka: Traktowanie oprogramowania innych firm jako „problemu kogoś innego”
- Konsekwencja: Niekontrolowane ryzyko i niezgodności z przepisami
- Rozwiązanie: Prowadzenie kompletnego spisu SOUP wraz z oceną ryzyka
Błąd 3: Słaba integracja z systemem zarządzania jakością
- Pomyłka: Traktowanie normy IEC 62304 jako odrębnego standardu
- Konsekwencja: Niezwiązane ze sobą procesy i uwagi z audytu
- Rozwiązanie: Wkomponowanie wymagań normy IEC 62304 w system zarządzania jakością zgodny z ISO 13485
Błąd 4: Niedostateczna kontrola zmian
- Pomyłka: Nieformalne procesy utrzymania oprogramowania
- Skutek: Niekontrolowane zmiany, które wprowadzają nowe ryzyka
- Rozwiązanie: Wdrożenie skutecznych procesów zarządzania konfiguracją i rozwiązywania problemów
Pułapka 5: Nadmiar dokumentacji
- Błąd: Tworzenie dokumentacji, z której nikt nie korzysta
- Konsekwencja: negatywne wyniki audytów i opóźnienia w projektach
- Rozwiązanie: skupienie się na istotnej dokumentacji, która wspiera proces podejmowania decyzji
Lista kontrolna zgodności z normą IEC 62304
- Klasyfikacja bezpieczeństwa oprogramowania została przypisana i udokumentowana
- System zarządzania jakością został wdrożony (zgodnie z normą ISO 13485)
- Procesy zarządzania ryzykiem zostały zdefiniowane (zgodnie z normą ISO 14971)
- Role i obowiązki zostały przydzielone
- Plan rozwoju został utworzony i jest aktualizowany
- Wymagania dotyczące oprogramowania zostały udokumentowane i są śledzone
- Architektura została zaprojektowana i zweryfikowana
- Zakończono projekt szczegółowy (klasa C)
- Przeprowadzono weryfikację jednostkową (klasa B/C)
- Zakończono testy integracyjne (klasa B/C)
- Przeprowadzono testy systemu (wszystkie klasy)
- Oprogramowanie zostało wydane wraz z odpowiednią dokumentacją
- Udokumentowano plan utrzymania
- Ustanowiono procedury rozwiązywania problemów
- Określono proces oceny wpływu zmian
- Wdrożono plan nadzoru po wprowadzeniu do obrotu
- Zidentyfikowano elementy konfiguracji
- Wdrożono system kontroli wersji
- Ustanowiono procedury kontroli zmian
- Zaplanowano audyty konfiguracji
- Zakończono analizę zagrożeń dla oprogramowania
- Wdrożono środki kontroli ryzyka
- Przeprowadzono weryfikację kontroli ryzyka
- Utrzymywana jest macierz śledzenia
Najlepsze praktyki w zakresie ciągłej zgodności z normą IEC 62304
- Rozpocznij działania związane z normą IEC 62304 na etapie planowania projektu, a nie pod koniec prac rozwojowych. Działania w zakresie zgodności podejmowane na późnym etapie są kosztowne i często niewystarczające.
- Korzystaj z narzędzi do zarządzania konfiguracją, testowania i generowania dokumentacji. Procesy manualne nie skalują się i prowadzą do błędów.
- Zgodność z normą IEC 62304 to nie zadanie wyłącznie dla inżynierów ds. jakości. Programiści, testerzy i kierownicy projektów muszą rozumieć swoje role.
- Cykl życia oprogramowania nie kończy się z chwilą jego wydania. Zaplanuj bieżące utrzymanie, aktualizacje oraz poprawki bezpieczeństwa cybernetycznego już od pierwszego dnia.
- Przeprowadź audyty wewnętrzne, aby wykryć luki przed oceną zewnętrzną. Zapobieganie jest tańsze niż usuwanie skutków błędów.
Jak Freyr może przyspieszyć Twoją drogę do normy IEC 62304
Freyr przyspiesza wprowadzanie wyrobów medycznych na rynek.
Dzięki ponad 2200 ekspertom ds. regulacyjnych i ponad 1500 zatwierdzeniom wyrobów osiągamy 99% skuteczności składania wniosków za pierwszym razem.
W zakresie normy IEC 62304 firma Freyr zapewnia kompleksowe usługi w obszarze zgodności z przepisami. Nasza sprawdzona metodologia obejmuje analizę luk, dokumentację oraz zarządzanie cyklem życia, co ułatwia uzyskanie zgodności i pozwala szybciej wprowadzić wyrób na rynek. Zapoznaj się z naszymi usługami dotyczącymi normy IEC 62304 tutaj lub skontaktuj się z nami pod adresem sales@freyrsolutions.com.
