Управління ризиками в програмних системах для медичних пристроїв. Дізнайся, як фахівці Sii допомагають клієнтам впроваджувати ефективний контроль ризиків

Сектор охорони здоров’я – це суворо регульоване середовище, у якому ключові дії мають бути належним чином задокументовані, щоб мінімізувати ризик помилок і потенційної шкоди для кінцевих користувачів – як пацієнтів, так і постачальників послуг. Такий підхід накладає певні обмеження та вимоги на те, як проводити розробку проєктів. Фахівці Sii підтримують клієнтів у розробці медичних пристроїв і допомагають їм застосувати аналогічні принципи до програмного забезпечення, що і до проєктів медичних пристроїв (SaMD).

Через характер виробництва медичних пристроїв, організації по всьому світу визначили потребу у створенні єдиних правил і стандартів, необхідних для виконання таких проєктів. Застосовуючи правила, усі залучені сторони зобов’язуються захищати безпеку пацієнтів, одночасно сприяючи медичним інноваціям.

— Sii — це консалтингова компанія, яка працює з клієнтськими системами управління якістю та ризиками, — каже Wojciech Drescher, Senior Head of Healthcare у Sii. – Зараз компанії повинні мати робоче середовище, у якому впроваджено ISO 13485 (Система управління якістю) та ISO 14971 (Управління ризиками), а розробка програмного забезпечення для медичних пристроїв виконується відповідно до IEC 62304. Якщо це не так, Sii спеціалісти можуть допомогти клієнту реалізувати необхідні налаштування, — додає він.

Класифікація безпеки програмного забезпечення – обов’язкова умова для систем у медичних пристроях

Для систем програмного забезпечення в медичних пристроях одним із перших кроків, що вимагає IEC 62304, функціональний стандарт, який охоплює розробку та підтримку програмного забезпечення, є встановлення класифікації безпеки програмного забезпечення (SSC). Він визначається підходом, що ґрунтується на оцінці ризику, і визначає три класи безпеки для рішень:

• A: немає травм або можлива шкода здоров’ю,
• B: можлива травма, але не серйозна (реверсивна),
• C: можлива смерть або серйозна травма.

Ця класифікація відрізняється від Регламенту ЄС щодо медичних пристроїв (EU MDR) або Класифікації медичних виробів Управління з продовольства і медикаментів США(FDA MDC). Ви все ще можете мати медичне обладнання класу III, маючи SSC класу A.

Визначення програмного ризику – як забезпечити ефективність процесу

Складне програмне забезпечення може збільшити ризик виникнення небезпечних ситуацій. Управління ризиками в контексті медичних компаній передбачає ефективну ідентифікацію таких подій, а також зменшення їх ймовірності та запобігання шкоді.

— Команда спеціалістів Sii проводить комплексний процес управління ризиками програмного забезпечення, — каже Marek Matuszak, Senior Software Engineer у Sii. — Аналіз виконується на системному рівні, враховуючи не лише програмне забезпечення та цільове використання, а й наявне обладнання та механіку медичного пристрою, аксесуари та передбачуване неналежне використання, — пояснює він.

По-перше, фахівці Sii оцінюють ризик на основі єдиної несправності, найгіршого сценарію. Потім правила, визначені документом IEC/TR 80002-1, використовуються для вибору типових сценаріїв помилок програмного забезпечення. Що стосується пристроїв, підключених до мережі, питання кібербезпеки також беруться до уваги.

— Розглянемо, наприклад, програмне забезпечення, яке відповідає за керування приводом, — каже Marcin Lis, Compliance and Medical Software Validation Specialist у Sii. — Питання, на яке потрібно відповісти, що могло б статися, якби програмне забезпечення відігнало привід у найменш очікуваний час і позицію? Або замість того, щоб зупинитися, він загнав привід далі, ніж було заплановано? Яких збитків може завдати така подія? — продовжує він.

Після детального аналізу створюється список ризиків, який потім порівнюється з аналізом ризиків клієнта, щоб визначити, чи ризики є прийнятними.

Вплив на розвиток медичного обладнання

Наслідком процесу є три можливі результати:

• Усі ризики прийнятні, а програмна система належить до класу A.
• Деякі з ризиків є неприйнятними, але можливе впровадження зовнішніх заходів контролю ризиків. Це включає, але не обмежується розробкою апаратних методів пом’якшення, або розробкою інших заходів для зменшення наслідків програмної помилки.
• Деякі з ризиків є неприпустимими, їм присвоюється клас B або C, залежно від тяжкості можливого пошкодження. Можуть бути введені додаткові вимоги до програмного забезпечення, які стають заходами контролю ризиків. Вищі SSC, вимоги до програмного забезпечення та результати випробувань можуть бути використані як аргумент для зменшення частоти в аналізі ISO 14971.

Оскільки IEC 62304 вимагає, щоб усі фактори ризику програмного забезпечення розглядалися з імовірністю виникнення «1», оцінка ризику між IEC 62304 та ISO 14971 має деякі спільні моменти, але їх слід розглядати як дві різні області.

— Безпека та якість на першому місці, без компромісів, — каже Piotr Mazurski, Lead Auditor/Cybersecurity Consultant at Sii. — Чим вищий SSC, тим суворішою є процедура розробки програмного забезпечення згідно з IEC 62304. Розробка програмного забезпечення класу C вимагає значно більше ресурсів, ніж програмне забезпечення класу A. Це пов’язано з вимогами, які є необов’язковими для класу А.