Zarządzanie ryzykiem w systemach oprogramowania dla Urządzeń Medycznych. Dowiedz się, jak eksperci Sii Polska pomagają klientom wdrażać skuteczną kontrolę ryzyka

Sektor medyczny jest wysoce regulowanym środowiskiem, w którym kluczowe działania muszą być odpowiednio udokumentowane, aby zminimalizować ryzyko błędu i potencjalnej szkody dla użytkowników końcowych – zarówno pacjentów, jak i podmiotów świadczących opiekę. Takie podejście nakłada określone ograniczenia i wymagania na sposób prowadzenia projektów związanych z rozwojem oprogramowania. Eksperci Sii Polska wspierają klientów w rozwoju Urządzeń Medycznych i pomagają im stosować podobne zasady w projektach typu Software as a Medical Device (SaMD).

Ze względu na specyfikę projektów z zakresu produkcji Urządzeń Medycznych, organizacje na całym świecie dostrzegły potrzebę stworzenia jednolitych zasad i standardów koniecznych do realizacji takich przedsięwzięć. Dzięki stosowaniu regulacji wszystkie zaangażowane strony są zobowiązane do ochrony bezpieczeństwa pacjentów, przy jednoczesnym promowaniu innowacji w obszarze medycyny.

— Sii Polska jest firmą konsultingową, która pracuje z systemami zarządzania jakością i ryzykiem klienta — mówi Wojciech Drescher, Senior Head of Healthcare w Sii Polska. — Firmy muszą obecnie posiadać środowisko pracy, w którym wdrożono normy ISO 13485 (System Zarządzania Jakością) i ISO 14971 (Zarządzanie Ryzykiem), a tworzenie oprogramowania dla Urządzeń Medycznych odbywa się zgodnie z normą IEC 62304. Jeśli tak nie jest, specjaliści Sii mogą pomóc klientowi we wdrożeniu wymaganej konfiguracji — dodaje.

Klasyfikacja bezpieczeństwa oprogramowania – podstawa systemów w urządzeniach medycznych

W przypadku systemów oprogramowania w Urządzeniach Medycznych, jednym z pierwszych kroków wymaganych przez IEC 62304, normę funkcjonalną obejmującą projektowanie i utrzymanie oprogramowania, jest ustanowienie klasyfikacji bezpieczeństwa oprogramowania (ang. Software Safety Classification, SSC). Jest ona określana na podstawie podejścia opartego na ryzyku i definiuje trzy klasy bezpieczeństwa rozwiązań:

• A: nie jest możliwy uraz lub uszczerbek na zdrowiu,
• B: obrażenia są możliwe, ale nie są poważne (są odwracalne),
• C: możliwa jest śmierć lub poważne obrażenia.

Klasyfikacja ta różni się od rozporządzenia UE w sprawie Urządzeń Medycznych (ang. Medical Device Regulation, MDR) lub Klasyfikacji Urządzeń Medycznych amerykańskiej Agencji Żywności i Leków (ang. Federal Drug Agency Medical Device Classification, FDA MDC). Możliwe jest posiadanie wyrobu medycznego klasy III przy jednoczesnym posiadaniu SSC klasy A.

Określanie ryzyka związanego z oprogramowaniem – jak zapewnić efektywność procesu

Złożone oprogramowanie może zwiększać ryzyko wystąpienia sekwencji zdarzeń prowadzących do sytuacji  niebezpiecznych. Zarządzanie ryzykiem w kontekście firm z branży medycznej polega na skutecznej identyfikacji takich zdarzeń, a także na zmniejszeniu prawdopodobieństwa ich wystąpienia i zapobieganiu szkodom.

— Zespół specjalistów Sii przeprowadza kompleksowy proces w zakresie zarządzania ryzykiem związanym z oprogramowaniem — mówi Marek Matuszak, Senior Software Engineer w Sii Polska. — Analiza przeprowadzana jest na poziomie systemu, biorąc pod uwagę nie tylko samo oprogramowanie i jego przeznaczenie, ale także istniejący sprzęt i mechanikę Urządzenia Medycznego, akcesoria oraz możliwe do przewidzenia niewłaściwe użycie — wyjaśnia.

Eksperci Sii najpierw oceniają ryzyko pojedynczej usterki według najgorszego scenariusza. Następnie reguły zdefiniowane przez IEC/TR 80002-1 wykorzystywane są do wyboru typowych scenariuszy błędów oprogramowania. Jeśli chodzi o urządzenia podłączone do sieci, kwestie cyberbezpieczeństwa są również rozpatrywane.

— Jako przykład rozważmy oprogramowanie odpowiedzialne za sterowanie siłownikiem — mówi Marcin Lis, Compliance and Medical Software Validation Specialist w Sii Polska. — Należy odpowiedzieć na pytanie: co mogłoby się stać, gdyby oprogramowanie uruchomiło siłownik w najmniej oczekiwanym momencie i położeniu? Albo, zamiast się zatrzymać, przemieściło siłownik dalej niż zakładano? Jakie szkody mogłyby wyniknąć z takiego zdarzenia? — kontynuuje.

Po szczegółowej analizie tworzona jest lista ryzyk, która następnie porównywana jest z Analizą Ryzyka klienta w celu określenia czy ryzyko jest akceptowalne czy nie.

Wpływ na rozwój Urządzeń Medycznych

W wyniku realizacji procesu możliwe są trzy rezultaty:

• Wszystkie czynniki ryzyka są akceptowalne i systemowi przypisywana jest klasa A.
• Niektóre z czynników ryzyka są nieakceptowalne, ale możliwe jest wdrożenie zewnętrznych środków kontroli ryzyka. Dotyczy to między innymi zaprojektowania środków łagodzących odnoszących się do sprzętu lub opracowania innych sposobów na zmniejszenie skutków błędu w oprogramowaniu.
• Niektóre z czynników ryzyka są nieakceptowalne, systemowi przypisywana jest klasa B lub C, w zależności od stopnia potencjalnej szkodliwości. Można wprowadzić dodatkowe wymagania dotyczące oprogramowania, które stają się Środkami Kontroli Ryzyka. Wyższe SSC, wymagania dotyczące oprogramowania oraz wyniki testów mogą być wykorzystane jako argument za zmniejszeniem częstości występowania w analizie ISO 14971.

Ponieważ norma IEC 62304 wymaga, aby wszystkie czynniki ryzyka związane z oprogramowaniem były rozważane z prawdopodobieństwem wystąpienia „1”, ocena ryzyka pomiędzy IEC 62304 a ISO 14971 ma pewne punkty wspólne, ale powinna być traktowana jako dwie różne domeny.

— Bezpieczeństwo i jakość są na pierwszym miejscu, nie ma tu przestrzeni na kompromis — mówi Piotr Mazurski, Lead Auditor/Cybersecurity Consultant w Sii Polska. — Im wyższe SSC, tym większy rygor powinien być nałożony na projekt w procesie rozwoju oprogramowania zgodnie z IEC 62304. Rozwój oprogramowania klasy C wymaga znacznie więcej zasobów niż oprogramowania klasy A. Wynika to z wymagań, które są opcjonalne dla klasy A — dodaje.

Dowiedz się więcej o wdrożeniach Sii Polska realizowanych dla sektora opieki zdrowotnej. Skontaktuj się z naszymi ekspertami, aby usprawnić system kontroli ryzyka w Twojej organizacji.