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

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

Відстежуваність: принцип непереговорності

В основі IEC 62304 лежить концепція простежуваності. Це включає:
- Визначені та тестовані вимоги до програмного забезпечення,
- Документовані архітектурні та дизайнерські рішення,
- Узгоджені та зафіксовані дії з перевірки,
- Інтегровані заходи контролю ризиків згідно з ISO 14971 ,
- Управління аномаліями програмного забезпечення та змінами конфігурації.
Ці принципи застосовуються універсально — незалежно від того, чи використовує ваша команда Scrum, Kanban чи будь-який гібридний Agile-фреймворк.

IEC 62304 та Agile: сумісність за конструкцією

Хоча IEC 62304 пропагує структурований життєвий цикл, він принципово не залежить від методології. Гнучка розробка може відповідати очікуванням, якщо її інтерпретувати крізь призму результатів та артефактів, а не жорсткої послідовності.

Спринти можуть постачати компоненти, що поступово тестуються; журнали виконання можуть бути зіставлені зі специфікаціями вимог. Ключовим є те, що всі дії життєвого циклу (від вимог до веріфікації) документуються, перевіряються та контролюються.

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

Переосмислення V-моделі як основи документації

V-модель, яку часто розглядають як синонім IEC 62304, не слід сприймати як інструкцію з процесів розробки. Натомість її найкраще розуміти як документаційну основу – візуалізацію узгодженості між діяльністю розробки та її відповідною перевіркою.
Гнучка розробка відповідає цій моделі, коли:

  • Вимоги відслідковуються до тестових сценаріїв.
  • Проєктні рішення проходять валідацію.
  • Зміни в коді контролюються та перевіряються.
  • Релізи документуються із відповідними оцінками ризиків. 
     

Відповідність нормативним очікуванням

Регуляторні органи продовжують визнавати та використовувати IEC 62304 не через його життєвий цикл, а завдяки його послідовним, аудитованим вимогам:

Високорівневі вимоги, зазначені в Додатку II до Регламенту медичних виробів (MDR 2017/745), можуть бути пов’язані з більш специфічними вимогами до програмного забезпечення, визначеними IEC 62304, такими як:

  • Вимоги до програмного забезпечення
  • Управління ризиками
  • Контроль конфігурації
  • Історія версій програмного забезпечення
  • Верифікація на основі ризиків

Ці аспекти природно підтримуються структурою IEC 62304. Навіть Керівництво FDA 2023 року щодо документації програмного забезпечення безпосередньо співвідноситься з концепціями IEC 62304.

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

Як Нотифікований орган відповідно до MDR, DQS-MED продовжує визнавати IEC 62304 як найбільш відповідний стандарт для структурованої документації процесів життєвого циклу програмного забезпечення медичних виробів.

Висновок: IEC 62304 — стандарт, який варто переосмислити

IEC 62304 — це не пережиток минулого, а регуляторний фундамент сучасної розробки програмного забезпечення.

Так, IEC 62304 потребує нового трактування або навіть адаптації до реалій сьогоднішнього середовища розробки. Його модель життєвого циклу може здаватися традиційною, але його ключові принципи — відстежуваність, верифікація та контроль — залишаються актуальними завжди.

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

Відповідність програмного забезпечення починається тут — MDR, ISO 13485, MDSAP та інше від DQS!

Відповідність програмного забезпечення починається тут — MDR, ISO 13485, MDSAP та інше від DQS!

Зв'яжіться з нами!
Автор

Доктор Андрій Ніну

Доктор Андрій Ніну - досвідчений експерт з регуляторних питань, що спеціалізується на активних медичних пристроях, з особливим акцентом на функціональній та програмній безпеці, а також застосуванні штучного інтелекту (ШІ) в охороні здоров'я. Він має великий досвід у дотриманні нормативних вимог ЄС, зокрема, у процесах сертифікації та оцінки відповідності для виробників медичних виробів.

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

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

Loading...

Відповідні статті та події

Вас це також може зацікавити
Блог
Loading...

Закон про штучний інтелект і медичне обладнання на базі ШІ: сучасний стан регулювання

Блог
Loading...

Оновлення EU MDR: Опубліковано нові гармонізовані стандарти згідно з Імплементаційним рішенням (ЄС) 2026/193

Блог
Loading...

Внутрішні аудити ISO 13485: від зобов'язання до стратегічної цінності