Мобільні застосунки, хмарні платформи та алгоритми аналізу зображень дедалі частіше використовуються в діагностиці й лікуванні. Для розробника ключове питання звучить просто: чи є мій продукт медичним виробом. Від відповіді залежить, чи потрібна оцінка відповідності, які стандарти застосовувати і яку відповідальність несе компанія після виходу на ринок.
Програмне забезпечення як медичний виріб (Software as a Medical Device, SaMD) відрізняється від програмного забезпечення, вбудованого в обладнання. SaMD працює самостійно на смартфоні, комп'ютері чи сервері і сам по собі виконує медичне призначення.
Визначальним є призначення, заявлене виробником. Технічний регламент щодо медичних виробів, затверджений постановою КМУ №753, відносить до медичних виробів програмне забезпечення, призначене для діагностики, профілактики, моніторингу, лікування чи полегшення перебігу захворювання. Тобто важить не технологія, а те, що програма обіцяє користувачу в описі, інструкції, рекламі та інтерфейсі.
Українські правила класифікації побудовані на підході Директиви 93/42/ЄЕС, де автономне програмне забезпечення розглядається як активний медичний виріб. Залежно від того, чи керує програма іншим виробом, чи надає інформацію для діагностики життєво важливих параметрів, клас може бути від I до IIa або вище. Регламент ЄС MDR 2017/745 запровадив окреме правило 11, за яким більшість програм, що надають інформацію для прийняття діагностичних чи терапевтичних рішень, належать щонайменше до класу IIa. Розробникам, що орієнтуються на обидва ринки, варто враховувати цю різницю ще на етапі формулювання призначення.
| Функція програми | Орієнтовний рівень ризику | Що визначає клас |
|---|---|---|
| Зберігання і передача даних без обробки | Низький або не медвиріб | Відсутність медичного призначення |
| Моніторинг фізіологічних параметрів | Середній | Чи є параметри життєво важливими |
| Підтримка діагностичних рішень | Середній або високий | Наслідки хибного результату |
| Керування активним виробом, дозування | Високий | Пряма дія на пацієнта |
Для SaMD основними є кілька гармонізованих стандартів. ДСТУ EN 62304 встановлює вимоги до процесів життєвого циклу: планування, аналізу вимог, архітектури, верифікації, керування конфігурацією та вирішення проблем. Програму відносять до класу безпеки A, B або C залежно від можливої шкоди. EN 82304-1 охоплює безпеку медичного ПЗ як продукту. EN 62366-1 стосується інженерії юзабіліті, адже помилка інтерфейсу для програми часто важить більше, ніж апаратна відмова. Управління ризиками ведеться за ДСТУ EN ISO 14971 з урахуванням кібербезпеки та захисту даних.
Якщо програма належить до класу, що потребує участі третьої сторони, оцінку здійснює призначений орган з оцінки відповідності, який розглядає як документацію на продукт, так і процеси розробки.
Програмне забезпечення змінюється значно частіше, ніж апаратні вироби. Виробнику потрібна процедура, яка розмежовує виправлення помилок, що не впливають на безпеку, і зміни алгоритму чи призначення, що можуть вимагати повідомлення органу. Окрему увагу приділяють моніторингу кіберзагроз, аналізу журналів помилок і відгуків користувачів.
Чи є медичним виробом застосунок, що лише показує дані з глюкометра?
Якщо програма тільки відображає дані без обробки, інтерпретації чи рекомендацій, вона часто розглядається як аксесуар або не медвиріб. Додавання трендів, тривог чи порад змінює оцінку.
Чи потрібна окрема оцінка для кожної версії програми?
Ні, але кожну зміну аналізують за процедурою керування змінами. Суттєві зміни функцій чи призначення можуть потребувати повідомлення органу і додаткової оцінки.
Чи впливає хмарна архітектура на відповідність?
Так, виробник має оцінити ризики, пов'язані з доступністю сервісу, цілісністю даних і кібербезпекою, та контролювати постачальників хмарних послуг.
Правильно визначене призначення і клас SaMD заощаджують місяці роботи і знижують регуляторні ризики. Огляди вимог, навчальні програми та відомості про процедури оцінки розміщено на сайті improvemed.com.ua.
