Znaczenie identyfikowalności z perspektywy projektowania oprogramowania wyrobu medycznego

Wypuszczenie nowego produktu na rynek nadzorowany prawnie wiąże się z wyzwaniem zapewnienia zgodności z wieloma normami i przepisami. Producent takiego wyrobu musi zadbać o to, aby urządzenie było bezpieczne i działało zgodnie z przeznaczeniem. Doświadczenie podpowiada, że kluczowym w uzyskaniu odpowiedniej certyfikacji z danego obszaru regulowanego jest dostarczenie danej jednostce notyfikowanej dobrze przygotowanej dokumentacji.

W procesie projektowania produktu należy stworzyć ścieżkę dokumentacji, która na każdym podetapie prowadzi od parametrów wejściowych do konkretnych decyzji projektowych. Tego rodzaju proces to nic innego jak podstawa utrzymania identyfikowalności produktu.

Poznając jakikolwiek proces projektowania, można usłyszeć o identyfikowalności i jej znaczeniu w Systemie Zarządzania Jakością (QMS). W artykule opisano użycie tego terminu w jednym z najbardziej regulowanych środowisk – projektowaniu oprogramowania wyrobu medycznego.

Co to jest identyfikowalność?

W literaturze pojawia się wiele definicji identyfikowalności (ang. traceability). Jedna z nich:

Requirements traceability refers to the ability to describe and follow the life of a requirement, in both a forward and backwards direction (i.e., from its origins through its development and specification to its subsequent deployment and use, and through all periods of on-going refinement and iteration in any of these phases) [1]

precyzyjnie określa identyfikowalność w kontekście opisu wymagań projektowych. Oznacza możliwość dokładnego opisania tych wymagań oraz śledzenia ich realizacji na każdym etapie, począwszy od ich powstania, przez rozwijanie i specyfikowanie, aż po finalne wdrożenie i użytkowanie, niezależnie od etapów bieżącej optymalizacji i iteracji w jakimkolwiek z tych procesów.

Pojęcie „Traceability” opiera się na dwóch prostych słowach: „trace” – ślad oraz „ability” – zdolność. Łącząc te dwie idee, możemy zrozumieć identyfikowalność jako zdolność produktu do śledzenia historii wymagań stworzonych dla tego produktu.

Identyfikowalność w dziedzinie wyrobów medycznych

Normą szczegółowo określającą wymagania dotyczące identyfikowalności wyrobów medycznych jest ISO 13485.

Organizacja powinna dokumentować procedury identyfikowalności. Procedury te określają zakres identyfikowalności zgodnie z obowiązującymi wymogami regulacyjnymi i rejestrami, które należy prowadzić [2]

– opisuje rozdział tego standardu dotyczący realizacji produktu.

Identyfikowalność towarzyszy głównym etapom realizacji wyrobu medycznego, w szczególności planowi wdrożenia produktu oraz planowi projektowania i rozwoju. Warto jednak wspomnieć, że ISO 13485 nie opisuje konkretnych metod lub technologii, które należy zastosować, ale określa ogólne wymagania dotyczące identyfikowalności. Sposób śledzenia urządzenia medycznego może się różnić w zależności od wielu czynników, takich jak typ urządzenia, jego przeznaczenie czy jurysdykcja regulacyjna.

Normy, wytyczne, regulacje

ISO 13485 to nie jedyny dokument odnoszący się do identyfikowalności dla wyrobów medycznych. Istnieje wiele norm, wytycznych i regulacji np.:

• standard ISO 14971,
• amerykańskie wytyczne FDA “General Principles of Software Validation”,
• europejskie rozporządzenie w sprawie wyrobów medycznych (MDR),

które opisują to zagadnienie z różnych perspektyw. Trudno byłoby uwzględnić każdą z nich w tym artykule.

Reasumując – aby zachować zgodność z wymogami i zaleceniami dotyczącymi identyfikowalności, producent musi przestrzegać obowiązujących norm i przepisów, specyficznych dla regionu i typu produkowanego urządzenia.

Norma IEC 62304, o której pisano już na blogu, definiuje proces cyklu życia oprogramowania urządzenia medycznego. Określa wymagania dotyczące jego rozwoju i konserwacji. Część rozwojowa składa się z kilku etapów, opisanych szerzej na Ryc. 1 (oprogramowanie nosi nazwę „SW”, ang. software). W połączeniu z innymi normami, w szczególności ISO 13485 i ISO 14971, porusza kwestie bezpieczeństwa i efektywności. Identyfikowalność w kontekście tego standardu stanowi serce niniejszego artykułu.

Rola identyfikowalności

W IEC 62304 rola identyfikowalności (w polskim tłumaczeniu) to:

stopień, w jakim można ustalić związek pomiędzy dwoma lub większą liczbą produktów procesu rozwoju

i rozpoczyna się w rozdziale 5 standardu zatytułowanym „Software Development Process”. Kroki rozdziału od 5.1 do 5.8 pokazano na poniższym schemacie:

Poniższa tabela przedstawia obszary, w których identyfikowalność jest wskazana jako wymagana (narracja „należność/powinność”) lub zalecana (narracja „możliwość”). Opis kontekstu identyfikowalności określa, jaką ścieżkę należy prześledzić w świetle identyfikowalności dla konkretnego etapu procesu.

Model V

Rolę identyfikowalności w procesie cyklu życia oprogramowania można opisać za pomocą modelu V przedstawionego na Ryc 2. Umieszczona w centrum schematu, stanowi łącznik pomiędzy dekompozycją wymagań produktowych i analizą ryzyka (lewa gałąź modelu) a integracją i weryfikacją dekomponowanych wymagań oraz kontrolą ryzyka na poszczególnych etapach procesu (prawa gałąź modelu). W zakres normy IEC 62304 wchodzi zielony obszar rysunku.

Skąd pochodzi model V i co przedstawia? Oryginał znajduje się w normie IEC 60601-1. Schemat opisuje rozwój programowalnego elektrycznego systemu medycznego – PEMS (ang. Programmable Electrical Medical System) i jest powiązany z procesem cyklu życia oprogramowania.

W obrębie zielonego obszaru na Ryc. 2 wymagania normy IEC 62304 mają zastosowanie do normy IEC 60601-1 na poziomie komponentu PEMS. Od określenia wymagań programowych do integracji oprogramowania tworzony jest system oprogramowania. Idąc dalej, system oprogramowania należy do programowalnego podsystemu elektrycznego (PESS), który jest częścią PEMS.

Identyfikowalność w praktyce

Jak ze świadomości rejestrowania wszystkich danych wejściowych i wyjściowych projektu, które definiują produkt, przejść do stworzenia analizy identyfikowalności systemu oprogramowania sprzętu medycznego? Warto zacząć od zebrania jej elementów składowych.

Mogą to być:

• Wymagania interesariuszy – opisują, co system będzie robił dla konkretnego środowiska z punktu widzenia interesariuszy (pacjentów, lekarzy, służb, pracodawców, właścicieli firm itp.) i odwołują się do genezy wymagań, np.: przeglądu podobnych produktów, opinii o usługach, zamierzonego zastosowania lub rzeczywistego wkładu użytkowników (potrzeby użytkowników/wkład marketingowy).
• Wymagania systemowe – definiują cechy systemu, atrybuty, wymagania funkcjonalne i wydajnościowe w mierzalny sposób, aby spełnić wymagania interesariuszy, wymagania regulacyjne i analizę ryzyka (środki kontroli ryzyka – RCM-y). Dane wejściowe mogą również pochodzić m.in.: już z ustalonych wymagań dla podobnych produktów lub badań użyteczności.
• Wymagania podsystemowe – jeśli system jest podzielony na podsystemy, odnoszą się one do wymagań systemowych, architektury systemu, analizy ryzyka i innych źródeł, np.: badania użyteczności; można je nazwać wymaganiami systemowymi dla konkretnego podsystemu.
• Wymagania komponentowe – podobnie jak na poziomie podsystemu, można je nazwać wymaganiami systemowymi dla konkretnego komponentu podsystemu określonego przez architekturę podsystemu.

Na podstawie tych danych wejściowych tworzy się ścieżkę identyfikowalności wymagań od poziomu interesariuszy aż do komponentu.

Następnym krokiem jest podjęcie decyzji, ile poziomów chcemy utrzymać w jednej analizie identyfikowalności. To znaczy – czy wolimy zaprezentować pełen zakres tej ścieżki w jednym dokumencie, czy też podzielić ją na kilka rekordów. Nie ma konkretnych wymagań ani ograniczeń co do tego, ile powinniśmy zawrzeć w jednym dokumencie.

Przedostatni aspekt – w jakiej formie chcemy przedstawić identyfikowalność. Najbardziej powszechną jest macierz identyfikowalności. Poniżej przedstawię przykładowy wzór macierzy wymagań na poziomie podsystemu:

Na koniec należy potwierdzić, że produkty wyjściowe spełniają określone wymagania poprzez działania V&V (ang. Verification and Validation – weryfikacja i walidacja). Wszystkie wymagania muszą zostać objęte weryfikacją i/lub walidacją, których wyniki trafiają do matrycy identyfikowalności.

Przykład poniżej (SRS – ang. Software Requirement Specification – specyfikacja wymagań oprogramowania, SR – ang. System Requirement – wymagania systemowe, STP – ang. System Test Protocol – protokół testu systemu, STR – ang. System Test Report – raport testu systemu, Ver – ang. Verification – weryfikacja, Val – ang. Validation – walidacja):

Powyższe rozwiązanie należy traktować jedynie jako przykład. Jego struktura i treść mogą się różnić w zależności od rodzaju i indywidualnych potrzeb projektu, np.: w niektórych przypadkach zasadnym może być całkowite pominięcie etapu walidacji.

Dlaczego identyfikowalność jest tak ważna?

Śledzenie listy wymagań w skompilowanej formie może pomóc zidentyfikować jeszcze nieodkryte, brakujące lub niekompletne wymagania, a także podkreślić, czy wszystkie wymagania zostały wystarczająco zweryfikowane.

Identyfikowalność może również przynieść korzyści w podejmowaniu decyzji podczas rozwoju produktu. Pozwala na szybką ocenę wpływu wymagań na przebieg projektu, a w przypadku jakiejkolwiek zmiany wymagań umożliwia przeanalizowanie jej wpływu na cały proces rozwoju.

Identyfikowalność okazuje się cenna w zarządzaniu projektami, ponieważ zapewnia jasną miarę postępu. Powiązanie wymagań z testami pozwala kontrolować zakres i realistycznie podejść do spełnienia tych wymagań, biorąc pod uwagę dostępne ramy czasowe.

Ostatecznie, wszystkie wspomniane atuty sprowadzają się do dwóch najważniejszych – zapewnienia wysokiej jakości i bezpieczeństwa wyrobu.

Praktycznie, większość działań i zadań w procesie wytwarzania oprogramowania ma na celu:

• ograniczyć ryzyka, do jakich potencjalnie może prowadzić korzystanie z oprogramowania oraz
• doskonalić i utrzymywać jakość oprogramowania.

Należy zauważyć, że w normie IEC 62304 zarządzanie ryzykiem i jakością są stałymi towarzyszami całego modelu cyklu życia (Ryc. 1 i Ryc. 2).

Identyfikowalność jawi się jako narzędzie, które:

• Może kontrolować to ryzyko poprzez śledzenie RCM-ów w stosunku do wymagań oprogramowania, wymagań oprogramowania do systemu oprogramowania, uzupełniając ten łańcuch aż do testów jednostkowych i integracyjnych.
• Jest strażnikiem kontroli jakości w obliczu wzrostu produktu, dbając o to, aby wymagania jakościowe systemu zostały spełnione poprzez fazę V&V, dokumentując prawidłowe wdrożenie i stopień, w jakim przypadki testowe testują te wymagania.

Podsumowanie

Wykazanie bezpieczeństwa i skuteczności produktu jest podstawą osiągnięcia zgodności z określonymi przepisami lub normami. Jeśli przekażemy dobrze prześledzone dokumenty jednostce notyfikującej, certyfikacja produktu jest niemal na wyciągnięcie ręki.

Tak jak nie ma jasnej ścieżki rozwoju każdego wyrobu medycznego, tak trudno znaleźć jedno rozwiązanie określające jego identyfikowalność. Czytelników, których nurtują podobne myśli i czują potrzebę pomocy w opisanych zagadnieniach, zapraszamy do kontaktu. Zespół doświadczonych inżynierów Sii wspiera nie tylko w tworzeniu tego typu dokumentacji, ale także w testowaniu, certyfikacji i nie tylko.

***

[1] O.C.Z. Gotel, C.W. Finkelstein, An analysis of the requirements traceability problem, in: Requirements Engineering, 1994., Proceedings of the First International Conference on Requirements Engineering, 1994, pp. 94-101

[2] ISO 13485:2016 – Medical devices — Quality management systems — Requirements for regulatory purposes