Наталія Жалій, головний фахівець відділу оцінки відповідності

Роль програмного забезпечення у сучасній медицині

Сьогодні програмне забезпечення стало невід’ємною частиною багатьох сфер життя, і медицина не є винятком. Воно може використовуватися як складова медичного виробу (наприклад, програмне забезпечення кардіостимулятора) або функціонувати як окремий продукт. Саме остання категорія — самостійне програмне забезпечення як медичний виріб (Software as a Medical Device, SaMD) — викликає найбільше запитань у виробників під час виходу продукції на ринок.

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

Що таке самостійне програмне забезпечення як медичний виріб?

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

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

Як визначити, чи є програмне забезпечення медичним виробом?

Крок 1. Визначення статусу програмного забезпечення

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

Крок 2. Аналіз функцій програмного забезпечення

Далі оцінюється характер обробки даних.

Якщо програмне забезпечення виконує лише:

• зберігання інформації;
• архівування;
• передачу даних;
• простий пошук;
• стиснення без втрати інформації,

воно не вважається медичним виробом.

Прикладами можуть бути системи реєстрації пацієнтів або програмні рішення для передачі медичних даних між закладами охорони здоров’я.

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

Крок 3. Визначення медичного призначення

Програмне забезпечення може бути визнане медичним виробом, якщо воно призначене для:

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

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

Класифікація самостійного програмного забезпечення

Після підтвердження статусу медичного виробу необхідно визначити його клас ризику.

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

В Україні класифікація медичних виробів, включаючи програмне забезпечення, здійснюється відповідно до Технічного регламенту щодо медичних виробів, затвердженого постановою Кабінету Міністрів України № 753 від 02.10.2013 р. (далі – Технічний регламент). Оскільки самостійне програмне забезпечення відноситься до активних медичних виробів, до нього застосовуються правила класифікації, що враховують характер взаємодії виробу з пацієнтом та рівень потенційного ризику.

Загальний підхід до класифікації передбачає оцінку таких факторів:

• призначення програмного забезпечення (діагностика, моніторинг, лікування або підтримка клінічного рішення);
• ступінь впливу інформації, яку генерує система, на медичні рішення;
• потенційні наслідки помилкового результату для пацієнта.

Типові приклади класифікації SaMD

У практиці регуляторного аналізу SaMD (самостійного програмного забезпечення як медичного виробу) відповідно до підходів IMDRF, MEDDEV 2.1/6 та положень Технічного регламенту, можна виділити такі узагальнені підходи до класифікації:

• Програмне забезпечення для зберігання, передачі, архівації або простого пошуку медичних даних (Hospital Information Systems, інформаційні системи без аналітичної функції) — як правило, не є медичним виробом. Такі системи виконують лише адміністративні або комунікаційні функції (реєстрація пацієнтів, облік, передача даних) і не здійснюють інтерпретації або зміни медичної інформації з діагностичною чи терапевтичною метою. Відповідно до підходів MEDDEV 2.1/6, вони підпадають під концепцію “simple search” і не кваліфікуються як медичні вироби.
• Програмне забезпечення для обробки, трансформації або представлення медичних даних із медичною метою (зокрема обробка медичних зображень, реконструкція, сегментація, реєстрація, фільтрація, CAD-системи) — зазвичай відноситься до медичних виробів класу IIa. У межах Технічного регламенту це відповідає активним діагностичним виробам, які здійснюють обробку інформації для підтримки клінічного рішення.
• Системи підтримки клінічних рішень (CDSS), що формують рекомендації для діагностики, прогнозу або лікування індивідуального пацієнта — клас IIa або IIб залежно від рівня ризику. Якщо результат роботи програмного забезпечення впливає на критичні життєві функції пацієнта або може призвести до серйозного погіршення стану при помилці, воно відноситься до класу IIб. Якщо вплив є опосередкованим і не критичним — до класу IIa.
• Програмне забезпечення для розрахунку дозування лікарських засобів або терапії (інсулінові калькулятори, системи планування хіміо- або променевої терапії) — переважно клас IIб. Такі системи безпосередньо впливають на клінічне рішення щодо лікування пацієнта та розглядаються як програмне забезпечення, що визначає або суттєво впливає на терапевтичну дію, що узгоджується з правилами класифікації активних медичних виробів у межах Технічного регламенту.
• Системи інтенсивного моніторингу життєво важливих фізіологічних параметрів, де відхилення можуть становити негайну загрозу життю пацієнта (кардіомоніторинг, моніторинг у відділеннях інтенсивної терапії) — клас IIб, тоді як системи рутинного або неінвазивного моніторингу життєвих показників — клас IIa.

SaMD із використанням штучного інтелекту (AI/ML)

Окрема складність становить класифікація програмного забезпечення, що використовує технології штучного інтелекту (AI) або машинного навчання. Важливо підкреслити, що ані Технічний регламент, ані керівні документи MEDDEV 2.1/6 не містять окремих правил класифікації саме для AI-рішень.

Водночас підходи до регуляторної оцінки таких систем визначаються загальними принципами IMDRF та європейськими роз’ясненнями, зокрема MDCG 2019-11 Rev.1, з положень якого можна зробити висновок, що використання алгоритмів штучного інтелекту не змінює клас медичного виробу автоматично — визначальним є призначення виробу та його роль у клінічному процесі.

У межах регуляторної практики ключовими критеріями залишаються:

• медичне призначення програмного забезпечення;
• ступінь впливу результатів роботи системи на клінічне рішення;
• рівень автономності алгоритму та потенційний ризик для пацієнта.

Відповідно до логіки ризик-орієнтованої класифікації, що застосовується в межах Технічного регламенту (зокрема через застосування правил класифікації активних медичних виробів, таких як правило 10–12 Додатка 2), а також підходів, викладених у MDCG 2019-11 Rev.1, можна виділити такі практичні приклади:

• AI-система, що аналізує медичні зображення та надає лікарю допоміжну інформацію (наприклад, сегментація зображень, підсвічування підозрілих ділянок, виділення патернів) — зазвичай розглядається як виріб класу IIa, оскільки вона підтримує діагностичний процес, але не приймає остаточного клінічного рішення і не керує лікуванням;
• AI-рішення, що формує клінічні рекомендації або впливає на вибір лікування (наприклад, пропозиція терапевтичних протоколів, оцінка ризиків, стратифікація пацієнтів) — може бути віднесене до класу IIб, оскільки результати роботи системи безпосередньо впливають на клінічне рішення та можуть мати значний вплив на стан пацієнта у разі помилки або некоректного застосування;
• AI-системи підтримки прийняття рішень у критичних станах (наприклад, системи інтенсивного моніторингу, триаж у відділеннях невідкладної допомоги, автоматизовані попередження щодо життєво небезпечних станів) — як правило також відносяться до класу IIб, оскільки працюють із життєво важливими параметрами та характеризуються підвищеним клінічним ризиком.

У класифікації AI-рішень вирішальним є не технологія (AI/ML як така), а клінічне призначення та вплив інформації, яку генерує система на прийняття медичних рішень, що узгоджується з ризик-орієнтованим підходом Технічного регламенту та загальною логікою, викладеною в MDCG 2019-11 Rev.1.

Особливу увагу регуляторів викликають адаптивні (самонавчальні) алгоритми, які можуть змінювати свою поведінку після впровадження. У таких випадках виробник повинен забезпечити:

• контроль версій алгоритмів;
• повторну валідацію змін;
• документування впливу оновлень на безпеку та ефективність.

Типові помилки класифікації SaMD

На практиці найпоширенішими помилками є:

• віднесення систем підтримки клінічних рішень до класу I без урахування їх фактичного впливу на діагноз або лікування;
• недооцінка ризику AI-рішень, що фактично впливають на медичні рішення;
• ігнорування сценаріїв використання у критичних станах (ICU, невідкладна допомога);
• помилкове розмежування між “інформаційною системою” та медичним виробом.

Практичне значення правильної класифікації

Коректне визначення класу ризику безпосередньо впливає на:

• процедуру оцінки відповідності (самодекларування або залучення органу оцінки відповідності);
• обсяг технічної документації;
• вимоги до клінічних даних;
• глибину постмаркетингового нагляду.

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

Процедури оцінки відповідності

Вибір процедури оцінки відповідності залежить від визначеного класу ризику.

Клас I

Для більшості виробів класу I застосовується процедура самодекларування відповідності без залучення органу з оцінки відповідності.

Класи IIа та IIб

Для виробів цих класів необхідне залучення уповноваженого органу з оцінки відповідності. Найчастіше використовуються процедури відповідно до Додатків 3 або 6 Технічного регламенту.

Технічна документація та маркування

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

До складу документації зазвичай входять:

• опис виробу;
• аналіз ризиків;
• результати верифікації та валідації;
• інструкція користувача;
• інформація про маркування;
• підтвердження відповідності застосовним вимогам.

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

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

Для підтвердження відповідності та забезпечення належної якості виробникам рекомендується застосовувати гармонізовані стандарти, зокрема:

• ДСТУ EN 62304:2014 — процеси життєвого циклу програмного забезпечення медичних виробів;
• ДСТУ EN ISO 14971:2015 — управління ризиками медичних виробів;
• ДСТУ EN ISO 13485:2018 — система управління якістю для медичних виробів;
• ДСТУ EN 62366:2015 — ергономіка та зручність використання медичних виробів.

Застосування цих стандартів дозволяє систематизувати процес розробки, мінімізувати ризики та спростити процедуру оцінки відповідності.

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