Особливості програмного забезпечення
Програмне забезпечення відрізняється від традиційних медичних виробів одним ключовим аспектом: воно швидко змінюється. Релізи, патчі, хмарні середовища, інтерфейси, функції штучного інтелекту та ризики кібербезпеки є природними частинами його життєвого циклу. MDR враховує це. Щодо програмного забезпечення Додаток I вимагає, серед іншого, сучасного підходу до життєвого циклу розробки, управління ризиками, верифікації та валідації, а також мінімальних вимог до апаратного забезпечення, ІТ-мереж та захисту від несанкціонованого доступу. Таким чином, кібербезпека не є другорядним ІТ-питанням, а радше частиною безпеки та ефективності продукту.
Особливо у випадку з програмним забезпеченням важливий не код, а медичне призначення. Додаток для здоров'я не кваліфікується як медичне програмне забезпечення лише тому, що він технічно складний. І навпаки, додаток, який здається простим, цілком може підпадати під дію MDR, якщо його інформація використовується для діагностичних або терапевтичних рішень. Поточні рекомендації Координаційної групи з медичних виробів (MDCG) щодо кваліфікації та класифікації програмного забезпечення саме уточнюють це розмежування.
Вимоги MDR – де їх можна знайти?
Будь-хто, хто бажає розмістити програмне забезпечення на ринку відповідно до MDR, слід дуже уважно прочитати відповідні розділи нормативного акта. Найважливіші розділи:
Додаток І, який визначає загальні вимоги до безпеки та ефективності. Для програмного забезпечення особливо актуальними є вимоги щодо процесу розробки, управління ризиками, інформаційної безпеки, валідації та ІТ-середовища.
Додатки II та III регулюють технічну документацію, а також вимоги до післяринкового нагляду. Для програмного забезпечення це також включає докази верифікації та валідації програмного забезпечення як частину документації на виріб.
Додаток VIII, зокрема Правило 11, є центральним у класифікації медичного програмного забезпечення. У Керівних принципах щодо медичного програмного забезпечення (MDCG 2019-11), переглянутих у 2025 році, пояснюються три основні принципи Правила 11: програмне забезпечення, яке надає інформацію для діагностичних або терапевтичних рішень; програмне забезпечення, яке контролює фізіологічні процеси; та «все інше програмне забезпечення». Залежно від клінічної значущості, класифікація може варіюватися від Класу I до Класу III.
Стаття 52 і Додатки IX–XI описують оцінку відповідності. Для виробів класу I декларацію про відповідність зазвичай видає сам виробник; для класу IIa і вище потрібна участь нотифікованого органу.
Додаток XIV, нарешті, є центральним орієнтиром для клінічної оцінки та післяринкового клінічного спостереження (PMCF). Особливо у випадку з програмним забезпеченням, ця сфера часто систематично встановлюється занадто пізно.
Найважливіші стандарти для медичного програмного забезпечення
MDR визначає нормативні вимоги. Однак на практиці деякі стандарти є особливо важливими, оскільки вони визначають «сучасний стан справ».
IEC 62304 є основним стандартом життєвого циклу медичного програмного забезпечення. Він описує процеси розробки та підтримки програмного забезпечення, коли саме програмне забезпечення є медичним виробом або невід'ємною частиною медичного виробу.
ISO 14971 є еталонним стандартом для управління ризиками медичних виробів, що безпосередньо включає програмне забезпечення як медичний виріб.
ISO 13485 є центральним стандартом управління якістю медичних виробів протягом усього життєвого циклу продукту. Для виробників, які прагнуть створити надійну організацію, що відповідає вимогам MDR, він слугує практичною операційною основою.
IEC 62366-1 охоплює інженерію експлуатаційної придатності. Це особливо актуально для програмного забезпечення, оскільки неправильна експлуатація, оманливі інструкції для користувача або нечіткі сигнали тривоги можуть мати негайні наслідки для безпеки.
IEC 82304-1 особливо актуальний для медичного програмного забезпечення на загальних ІТ-платформах, тобто для продуктів без спеціалізованого обладнання. Стандарт стосується безпеки та захисту на рівні продукту і тому має велике значення для багатьох окремих програмних продуктів або програмного забезпечення як медичного виробу (SaMD). Особливо варто зазначити, що IEC 82304-1 визначає конкретні вимоги до валідації SaMD і одночасно згадується в IEC 62304.
Класифікація: Вирішальний перший крок
Найпоширеніше та найважливіше початкове питання: до якого класу належить моє програмне забезпечення? Саме тут багато проектів зазнають невдачі — не через технологію, а через нечітке цільове призначення. Згідно з MDCG 2019-11 Rev.1, Правило 11 застосовується, по суті, на основі того, чи надає програмне забезпечення інформацію для діагностичних або терапевтичних рішень, чи контролює фізіологічні процеси, чи належить до залишкової категорії. Приклади в інструкціях показують, що діагностичне або терапевтичне програмне забезпечення може швидко потрапити до класу IIa, IIb або III, тоді як «все інше програмне забезпечення» — до класу I. З точки зору нотифікованого органу, таким чином, зрозуміло: класифікація — це не адміністративний крок наприкінці, а основа всієї стратегії отримання реєстраційного посвідчення. Вона впливає на обсяг клінічних доказів, глибину технічної документації, вимоги PMS/PMCF і, звичайно, на питання про те, чи повинен нотифікований орган брати участь і якою мірою.
Клінічні дані: без клінічних доказів це не спрацює
Для медичного програмного забезпечення клінічні докази не є «приємним доповненням». У MDCG 2020-1 чітко зазначено, що медичне програмне забезпечення з власним цільовим призначенням та заявленою клінічною користю потребує клінічних доказів як частини оцінки відповідності. Мета полягає в тому, щоб продемонструвати, що програмне забезпечення є безпечним, досягає своєї ефективності та забезпечує заявлену клінічну користь. На практиці це означає для програмного забезпечення: недостатньо просто показати, що алгоритм працює технічно. Також необхідно оцінити, чи надає програмне забезпечення правильну інформацію в клінічному контексті, як ця інформація використовується та чи дійсно це призводить до очевидної користі. Клінічна оцінка — це не одноразовий документ, а постійний процес.
Післяреєстраційне клінічне спостереження (PMCF)
PMCF часто недооцінюють у контексті програмного забезпечення. MDR визначає PMCF як безперервний процес, який оновлює клінічну оцінку та має бути закріплений у плані PMS виробника. Саме це шаблон PMCF MDCG чітко описує. PMCF особливо важлива для програмного забезпечення, оскільки контексти використання, операційні системи, інтерфейси, кіберзагрози та моделі клінічного використання постійно змінюються. Тому виробникам потрібна не лише обґрунтована стратегія отримання реєстраційних дозволів, але й надійна система для збору та оцінки реальних даних про ефективність та безпеку після виведення на ринок, а також для врахування цих даних у вдосконаленні продукту.
Як працює процес сертифікації з точки зору нотифікованого органу?
Шлях до сертифікації можна коротко описати шістьма ключовими кроками.
По-перше: Цільове використання має бути точно визначено. Це єдиний спосіб чітко визначити, чи підпадає програмне забезпечення під дію MDR.
По-друге: Програмне забезпечення має бути правильно класифіковане, зазвичай на основі Додатку VIII та Правила 11.
По-третє: Компанії потрібна відповідна система управління якістю та перевірений, сучасний процес розробки, заснований на ISO 13485, IEC 62304, ISO 14971 та інших стандартах залежно від продукту.
По-четверте: Технічна документація має бути повною, структурованою та простежуваною, включаючи верифікацію та валідацію програмного забезпечення.
По-п'яте: Клінічна оцінка, PMS та PMCF повинні бути структуровані належним чином для продукту.
По-шосте: Якщо класифікація вимагає залучення нотифікованого органу, офіційна оцінка відповідності проводиться за процедурами, викладеними в MDR.
