Czym jest IEC 62304?
IEC 62304 została opublikowana przez Międzynarodową Komisję Elektrotechniczną w 2006 roku, a w 2015 roku uzupełniona poprawką Amd 1 (obowiązuje wydanie skonsolidowane IEC 62304:2006+AMD1:2015). Norma nie narzuca konkretnego modelu wytwarzania (można pracować zwinnie lub kaskadowo), ale wymaga, aby zdefiniowane procesy, czynności i zadania były zaplanowane, wykonane i udokumentowane.
Norma obejmuje pięć głównych procesów: rozwój oprogramowania (rozdział 5: od planowania, przez wymagania, architekturę, implementację, integrację i testy systemowe, po wydanie), utrzymanie (rozdział 6), zarządzanie ryzykiem oprogramowania (rozdział 7, powiązane z ISO 14971), zarządzanie konfiguracją (rozdział 8) oraz rozwiązywanie problemów (rozdział 9). Zakłada przy tym, że organizacja działa w ramach systemu zarządzania jakością (zwykle ISO 13485).
Kluczowym pojęciem normy jest SOUP (Software of Unknown Provenance), czyli oprogramowanie gotowe, którego nie opracowano zgodnie z IEC 62304: biblioteki, szkielety aplikacji, systemy operacyjne, komponenty open source. Norma wymaga określenia wymagań dla każdego komponentu SOUP, śledzenia jego wersji w konfiguracji, oceny znanych anomalii publikowanych przez dostawcę oraz analizy skutków jego awarii dla bezpieczeństwa wyrobu.
Klasy bezpieczeństwa A, B i C
Sercem normy jest klasyfikacja bezpieczeństwa, która wyznacza zakres wymaganych czynności i dokumentacji. Klasę przypisuje się każdemu systemowi oprogramowania (a po dekompozycji także jego elementom) na podstawie możliwych skutków awarii, z uwzględnieniem środków kontroli ryzyka zewnętrznych wobec oprogramowania.
Po poprawce Amd 1:2015 klasyfikacja uwzględnia także prawdopodobieństwo, że sytuacja niebezpieczna doprowadzi do szkody. Wyższa klasa oznacza więcej obowiązków: klasa C wymaga między innymi projektu szczegółowego każdej jednostki i uzasadnionej segregacji architektonicznej elementów krytycznych, klasa B pełnej ścieżki wymagań, architektury i testów, a klasa A najkrótszej ścieżki z planowaniem, wymaganiami, wydaniem, konfiguracją i rozwiązywaniem problemów. Poprawka wprowadziła też ścieżkę dla oprogramowania odziedziczonego (legacy, punkt 4.4), pozwalającą wykazać zgodność istniejącego oprogramowania bez odtwarzania pełnej dokumentacji rozwojowej.
- Klasa A: awaria oprogramowania nie może spowodować obrażeń ani uszczerbku na zdrowiu.
- Klasa B: awaria może przyczynić się do obrażeń, ale nie poważnych.
- Klasa C: awaria może przyczynić się do śmierci lub poważnych obrażeń.
Kogo dotyczy?
Norma dotyczy każdego, kto wytwarza oprogramowanie będące wyrobem medycznym lub jego częścią: producentów urządzeń z oprogramowaniem wbudowanym (na przykład pompy infuzyjne, respiratory, diagnostyka obrazowa), firm tworzących samodzielne oprogramowanie medyczne (SaMD: aplikacje diagnostyczne, algorytmy wspomagania decyzji, oprogramowanie planowania terapii) oraz wytwórców oprogramowania do diagnostyki in vitro.
W praktyce zgodność z IEC 62304 jest oczekiwana przez organy i jednostki oceniające na całym świecie: w Unii Europejskiej norma jest uznanym stanem techniki przy wykazywaniu zgodności oprogramowania z wymaganiami MDR i IVDR (jej europejska wersja EN 62304 była zharmonizowana z wcześniejszymi dyrektywami medycznymi), a amerykańska FDA uznaje ją za normę konsensusową (recognized consensus standard) i akceptuje deklarację zgodności z nią w zgłoszeniach przedrynkowych. Norma współdziała z ISO 13485 (QMS), ISO 14971 (zarządzanie ryzykiem), IEC 62366-1 (inżynieria użyteczności) i IEC 82304-1 (produkty zdrowotne czysto software'owe).
Jak wykazuje się zgodność?
IEC 62304 nie jest normą systemu zarządzania w rodzaju ISO 27001. Nie istnieje osobny, akredytowany „certyfikat IEC 62304" analogiczny do certyfikacji systemów zarządzania. Zgodność wykazuje się dokumentacją cyklu życia oprogramowania, która staje się częścią dokumentacji technicznej wyrobu: ocenia ją jednostka notyfikowana w ramach oceny zgodności z MDR/IVDR (albo organ regulacyjny innego rynku), a audytorzy ISO 13485 weryfikują, czy procesy programistyczne działają w ramach systemu jakości. Niezależne laboratoria i jednostki (na przykład TÜV) oferują dobrowolne oceny i raporty zgodności z normą, które ułatwiają rozmowy z jednostką notyfikowaną.
Typowy pakiet dowodów obejmuje: plan rozwoju oprogramowania, klasyfikację bezpieczeństwa z uzasadnieniem, specyfikację wymagań, dokumentację architektury, plany i raporty weryfikacji oraz testów, listę SOUP z wersjami i oceną anomalii, zapisy zarządzania konfiguracją i wydań, rejestr problemów oraz macierz identyfikowalności łączącą wymagania, ryzyka i testy. Przeglądający zwykle zaczyna od klasyfikacji i identyfikowalności, bo to tam najszybciej widać, czy proces jest realny.
Ile to trwa i kosztuje?
Nakład pracy zależy przede wszystkim od klasy bezpieczeństwa i dojrzałości istniejących praktyk inżynierskich. Zespół, który już pracuje z kontrolą wersji, przeglądami kodu, integracją ciągłą i testami automatycznymi, ma większość mechaniki gotową. Pozostaje ją sformalizować: plan rozwoju, klasyfikacja, identyfikowalność, lista SOUP i zapisy weryfikacji. Wdrożenie procesów dla nowego projektu zajmuje zwykle od 2 do 6 miesięcy; uzupełnianie dokumentacji dla istniejącego produktu (lub ścieżka legacy) bywa dłuższe.
Największe koszty to czas zespołu inżynierskiego i jakościowego oraz, dla wyrobów ocenianych przez jednostkę notyfikowaną, przegląd dokumentacji technicznej w ramach oceny zgodności. Dobrą praktyką jest wpięcie wymagań normy w codzienne narzędzia (system ticketowy, CI/CD, generowanie SBOM), żeby dowody powstawały automatycznie przy pracy, a nie były odtwarzane przed audytem. To właśnie tu automatyzacja daje największy zwrot.
Jak pomaga Guardiso?
Guardiso zamienia wymagania IEC 62304 w prowadzony krok po kroku program: od klasyfikacji bezpieczeństwa po dowody z codziennej pracy zespołu.
- Komplet 53 wymagań normy (rozdziały 4-9) tworzony automatycznie po włączeniu standardu, ze statusami wdrożenia i przypisanymi właścicielami.
- Struktura wymagań odwzorowująca procesy normy: rozwój, utrzymanie, zarządzanie ryzykiem, konfiguracja i rozwiązywanie problemów.
- Rejestr ryzyk wspierający łańcuch identyfikowalności: sytuacja niebezpieczna → środek kontroli → wymaganie → weryfikacja.
- Zbieranie dowodów w jednym miejscu (plany, raporty testów, zapisy wydań i listy SOUP), gotowych do przeglądu dokumentacji technicznej.
- Zadania cykliczne pilnujące obowiązków utrzymaniowych: przegląd anomalii SOUP, monitorowanie podatności, przeglądy rejestru problemów.
- Polityki i procedury (plan rozwoju, procedura kontroli zmian, procedura rozwiązywania problemów) generowane z szablonów, z wersjonowaniem i zatwierdzaniem.
- Mapowanie krzyżowe na ISO 13485, ISO 27001 i pokrewne ramy: procesy jakości i bezpieczeństwa zaliczasz raz, w jednym systemie.