W dzisiejszej erze zwinnego rozwoju, DevOps i szybkich cykli iteracji, wielu programistów postrzega normę IEC 62304 jako pozostałość po dawnych czasach. Jej klasyczny cykl życia oprogramowania i poleganie na modelu V często stoją w sprzeczności z elastycznymi, szybkimi praktykami programistycznymi.

Jednak norma IEC 62304 nigdy nie miała być sztywną receptą na to, jak należy tworzyć oprogramowanie. Zamiast tego oferuje ona solidne ramy dla wykazania kontroli, bezpieczeństwa i identyfikowalności - podstawowych elementów, które są krytyczne niezależnie od tego, czy zespół pracuje w dwutygodniowych sprintach, czy w dłuższych cyklach kaskadowych.

Identyfikowalność: Zasada niepodlegająca dyskusji

Sercem normy IEC 62304 jest koncepcja identyfikowalności. Obejmuje to:
- Zdefiniowane i testowalne wymagania dotyczące oprogramowania,
- Udokumentowane decyzje dotyczące architektury i projektu,
- Dostosowane i zarejestrowane działania weryfikacyjne,
- Zintegrowane środki kontroli ryzyka zgodnie z ISO 14971,
- Zarządzanie anomaliami oprogramowania i zmianami konfiguracji.
Zasady te mają uniwersalne zastosowanie - niezależnie od tego, czy Twój zespół używa Scrum, Kanban, czy dowolnej hybrydowej struktury zwinnej.

IEC 62304 i Agile: kompatybilne z założenia

Podczas gdy norma IEC 62304 promuje ustrukturyzowany cykl życia, jest ona zasadniczo niezależna od metodologii. Zwinny rozwój może być zgodny z jej oczekiwaniami, gdy jest interpretowany przez pryzmat wyników i artefaktów, a nie sztywnego sekwencjonowania.

Sprinty mogą dostarczać przyrostowo testowane komponenty; backlogi mogą mapować do specyfikacji wymagań. Kluczem jest to, że wszystkie działania w cyklu życia - od wymagań po weryfikację - są dokumentowane, przeglądane i kontrolowane.

Nie liczy się sposób tworzenia oprogramowania, ale to, jak dobrze można wykazać, że jest ono bezpieczne, skuteczne i spełnia oczekiwania prawne.

Ponowne przemyślenie modelu V jako rusztowania dla dokumentacji

Model V, często postrzegany jako synonim normy IEC 62304, nie powinien być traktowany jako instrukcja obsługi procesów rozwojowych. Zamiast tego najlepiej rozumieć go jako rusztowanie dokumentacyjne - wizualizację dopasowania między działaniami rozwojowymi a odpowiadającą im weryfikacją.
Zwinny rozwój pasuje do tego modelu, gdy:

- Wymagania śledzą przypadki testowe,

- Decyzje projektowe są weryfikowane,

- Zmiany kodu są kontrolowane i weryfikowane,

- wydania są dokumentowane wraz z odpowiednimi ocenami ryzyka.

Dostosowanie do oczekiwań organów regulacyjnych

Organy regulacyjne nadal uznają i polegają na normie IEC 62304, nie ze względu na jej strukturę cyklu życia, ale ze względu na jej spójne, możliwe do skontrolowania oczekiwania:

Wysokopoziomowe wymagania, jak wskazano w załączniku II do rozporządzenia w sprawie wyrobów medycznych (MDR 2017/745), można prześledzić do bardziej szczegółowych wymagań dotyczących oprogramowania wskazanych w normie IEC 62304, takich jak wymagania, zarządzanie ryzykiem i kontrola konfiguracji, historia wersji oprogramowania i weryfikacja oparta na ryzyku, które są naturalnie wspierane przez ramy IEC 62304. Nawet wytyczne FDA z 2023 r. dotyczące dokumentacji oprogramowania bezpośrednio odwołują się do koncepcji IEC 62304.

Organy regulacyjne chcą mieć pewność, że producenci rozumieją swoje oprogramowanie, mogą zweryfikować jego zachowanie i ograniczyć ryzyko. Norma IEC 62304 pozostaje najbardziej globalnie zharmonizowanym sposobem zapewnienia tej gwarancji.

Jako jednostka notyfikowana w ramach MDR, DQS-MED nadal uznaje IEC 62304 za najbardziej odpowiedni standard dla ustrukturyzowanej dokumentacji procesów cyklu życia oprogramowania urządzeń medycznych.

Wnioski: IEC 62304 jest normą wartą reinterpretacji

Norma IEC 62304 nie jest reliktem przeszłości - jest kotwicą regulacyjną dla nowoczesnego rozwoju oprogramowania.

Tak, norma IEC 62304 wymaga reinterpretacji, a nawet dostosowania do realiów współczesnych środowisk programistycznych. Jej model cyklu życia może wydawać się tradycyjny, ale jej zasady - identyfikowalność, weryfikacja i kontrola - są ponadczasowe.

W rzeczywistości, w miarę jak przyjmujemy bardziej zwinne, elastyczne strategie rozwoju, zasady te stają się jeszcze bardziej krytyczne dla twórców oprogramowania urządzeń medycznych, którzy chcą zapewnić nie tylko zgodność, ale także bezpieczeństwo pacjentów.

Zgodne oprogramowanie zaczyna się tutaj - MDR, ISO 13485, MDSAP i więcej od DQS!

Zgodne oprogramowanie zaczyna się tutaj - MDR, ISO 13485, MDSAP i więcej od DQS!

Skon­tak­tuj się z nami
Autor

Dr. Andrei Ninu

Loading...

Powiązane artykuły i wydarzenia

Możesz być również zainteresowany tym
Blog
Loading...

Ustawa o sztucznej inteligencji i urządzeniach medycznych wykorzystujących sztuczną inteligencję - aktualny stan prawny

Blog
Loading...

Aktualizacja dotycząca MDR UE: Nowe zharmonizowane normy opublikowane na mocy decyzji wykonawczej (UE) 2026/193

Blog
Loading...

Audyty wewnętrzne ISO 13485: Od obowiązku do wartości strategicznej