Коротка відповідь: коли програмне забезпечення має медичне призначення (діагностика, профілактика, моніторинг, прогнозування, лікування), воно вважається медичним виробом згідно з Регламентом ЄС щодо медичних виробів (MDR, 2017/745) і отримує клас ризику: I, IIa, IIb або III, переважно за Правилом 11 Додатку VIII. Клас визначає, чи можете ви самостійно сертифікувати виріб (тільки клас I), чи потрібен уповноважений орган, наскільки глибокою має бути клінічна оцінка та як проводиться нагляд після виходу на ринок. Окремо інженерний стандарт IEC 62304 присвоює програмному забезпеченню клас безпеки: A (неможливе заподіяння шкоди), B (можливе заподіяння несерйозної шкоди) або C (можлива смерть або серйозна шкода), що визначає обсяг документації, проєктування та тестування протягом життєвого циклу. Ці дві класифікації пов'язані, але незалежні, і обидві визначаються шкодою, яку може завдати програмне забезпечення, а не його складністю.
Крок 1: Чи це взагалі виріб?
Програмне забезпечення вважається медичним виробом згідно з Регламентом ЄС щодо медичних виробів (MDR), коли його призначення є медичним: діагностика, профілактика, моніторинг, прогнозування, прогностика або лікування (Стаття 2(1)). Програмне забезпечення, яке лише зберігає, архівує, передає, відображає або шукає дані, не є виробом; програмне забезпечення, яке створює або змінює медичну інформацію для підтримки діагностичного або лікувального рішення, є таким, згідно з MDCG 2019-11.
Визначення MDR (Стаття 2(1)) залежить від призначення. Програмне забезпечення, яке зберігає, архівує, передає, відображає або виконує прості пошуки даних, не є виробом (MDCG 2019-11 вказує на це). Програмне забезпечення, яке створює або змінює медичну інформацію для підтримки діагностики або рішення щодо лікування, є. Запис, що показує лабораторне значення з референсним діапазоном лабораторії, не є виробом; програмне забезпечення, яке повідомляє користувачеві, що значення вказує на стан, або рекомендує дозу, є. Дивіться Чи є медичний додаток медичним виробом? для детального розгляду етапу кваліфікації.
Крок 2: Клас ризику MDR, Правило 11
Правило 11 MDR класифікує програмне забезпечення медичних виробів за шкодою, яку може спричинити неправильне рішення. Програмне забезпечення, що надає інформацію для діагностичних або терапевтичних рішень, за замовчуванням належить до класу IIa, до класу IIb, якщо такі рішення можуть призвести до серйозного погіршення стану або хірургічного втручання, і до класу III, якщо вони можуть призвести до смерті або незворотного погіршення стану. Програмне забезпечення для моніторингу належить до класу IIa, або до класу IIb для життєво важливих параметрів.
| Програмне забезпечення, призначене для… | Клас MDR |
|---|---|
| надання інформації, що використовується для прийняття рішень з діагностичною або терапевтичною метою (за замовчуванням) | IIa |
| …де такі рішення можуть призвести до смерті або незворотного погіршення здоров'я | III |
| …де такі рішення можуть призвести до серйозного погіршення здоров'я або хірургічного втручання | IIb |
| моніторингу фізіологічних процесів (за замовчуванням) | IIa |
| …моніторингу життєво важливих фізіологічних параметрів, де зміни можуть призвести до безпосередньої небезпеки для пацієнта | IIb |
| все інше (програмне забезпечення, яке є виробом, але не підпадає під жодне з вищезазначених) | I |
Правило 11 перевело більшість програмного забезпечення, яке раніше належало до класу I, до класу IIa або вище, що є основною причиною того, чому MDR сприймався як крок вперед для цифрового здоров'я. MDCG 2019-11 та рамкова структура ризиків IMDRF (значущість інформації × стан медичної ситуації) допомагають класифікувати граничні випадки. Програмне забезпечення, яке керує апаратним пристроєм або впливає на нього, набуває класу цього пристрою (Правило 3.3 виконавчих правил).
Наслідки за класами: клас I декларується самостійно з технічним файлом та реєстрацією, без уповноваженого органу (крім Im, Is, Ir); клас IIa потребує оцінки системи якості уповноваженим органом та зразка технічної документації; клас IIb – те саме, але з більш ретельним розглядом документації; клас III – повний огляд технічної документації та, де це доречно, консультації з групою експертів. Усі класи потребують системи управління якістю, клінічної оцінки, пропорційної класу, особи, відповідальної за дотримання нормативних вимог, UDI, реєстрації в EUDAMED, нагляду після виходу на ринок та пильності.
Крок 3: Клас безпеки програмного забезпечення IEC 62304
Клас безпеки програмного забезпечення IEC 62304 оцінює програмне забезпечення медичних виробів за найгіршою шкодою, до якої воно могло б призвести, після зовнішніх заходів контролю ризиків: клас A, коли травма неможлива; клас B, коли можлива несерйозна травма; клас C, коли можлива смерть або серйозна травма. Клас визначає, скільки проектування, верифікації та документації вимагає життєвий цикл програмного забезпечення.
IEC 62304 (2006, зі змінами 2015) – це гармонізований стандарт для процесів життєвого циклу програмного забезпечення медичних виробів. Його клас безпеки визначається найгіршою небезпечною ситуацією, до якої програмне забезпечення може призвести, після врахування заходів контролю ризиків, зовнішніх щодо програмного забезпечення:
| Клас | Небезпечна ситуація може призвести до… | Що вимагає життєвий цикл |
|---|---|---|
| A | відсутності травм або шкоди здоров'ю | План розробки програмного забезпечення, вимоги, випуск; вирішення проблем; управління конфігурацією |
| B | несерйозної травми | A: плюс архітектурне проєктування, верифікація інтеграції та системних тестів, документована верифікація модулів |
| C | смерті або серйозної травми | B: плюс детальне проєктування для кожного модуля, додаткова архітектурна сегрегація, більш сувора верифікація |
Класи призначаються для кожної програмної системи та можуть призначатися для кожного програмного елемента після декомпозиції, щоб лише ризиковані частини вимагали суворості класу C; стандарт пояснює аргументацію сегрегації, яка для цього потрібна. ISO 14971 (управління ризиками) впливає на класифікацію; IEC 82304-1 додає вимоги на рівні продукту для програмного забезпечення для здоров'я, яке працює на загальних платформах (телефони, хмара).
Як вони взаємодіють
Клас ризику MDR та клас безпеки IEC 62304 є незалежними: клас MDR (від I до III) визначає регуляторний шлях та залучення уповноваженого органу, тоді як клас IEC 62304 (від A до C) визначає суворість інженерного процесу. Додаток класу IIa може бути класом 62304 B або C залежно від шкоди, яку може спричинити неправильний вивід.
Клас MDR стосується регуляторного шляху; клас IEC 62304 стосується інженерного процесу. Додаток класу IIa за Правилом 11 може мати клас IEC 62304 B (неправильна інформація може призвести до несерйозної затримки в лікуванні) або C (якщо неправильна пропозиція дози може призвести до смерті). Пристрій класу I зазвичай має клас 62304 A, але не обов'язково. Уповноважені органи очікують, що технічний файл покаже клас 62304 з його обґрунтуванням, документи життєвого циклу на цьому рівні та зв'язок з файлом управління ризиками. Кібербезпека (MDCG 2019-16, IEC 81001-5-1) оцінюється паралельно.
Робочий приклад
Приклад програмного забезпечення як медичного виробу (SaMD): додаток для відстеження симптомів, який реєструє, відображає та ділиться симптомами, не є медичним виробом. Додавання функції, яка оцінює симптоми за валідованою шкалою та повідомляє користувачеві, коли слід звернутися за медичною допомогою, робить його виробом, що за замовчуванням належить до класу IIa за Правилом 11 MDR, з класом безпеки IEC 62304 B, або класом C для кардіологічного випадку використання.
Додаток для відстеження симптомів, який дозволяє користувачам реєструвати симптоми, переглядати тенденції та ділитися ними з лікарем: не є виробом (зберігання, відображення, комунікація). Той самий додаток додає функцію, яка оцінює зареєстровані симптоми за валідованою шкалою та повідомляє користувачеві, коли оцінка свідчить про необхідність звернутися за медичною допомогою: тепер є виробом, за замовчуванням за Правилом 11 клас IIa (інформація для діагностичного рішення; неправильне повідомлення "не потрібно звертатися за допомогою" може призвести до затримки лікування, серйозної, але зазвичай не незворотної, тому не IIb або III, якщо тільки цільовий стан не робить його таким). IEC 62304: помилкове заспокоєння може призвести до затримки лікування, від несерйозної до серйозної залежно від стану, тому клас B, можливо C для кардіологічного застосування. Шлях: ISO 13485 QMS, уповноважений орган, клінічна оцінка шкали, інженерія зручності використання (IEC 62366-1), нагляд після виходу на ринок.
Сполучені Штати, коротко
У Сполучених Штатах FDA регулює програмне забезпечення як медичний виріб за його призначенням, з класами I, II та III, а також шляхами 510(k), De Novo та PMA. Закон про століття вдосконалення (21st Century Cures Act) виключає адміністративне програмне забезпечення, продукти для загального оздоровлення, електронні медичні записи та певні інструменти підтримки клінічних рішень зі статусу виробу. FDA визнає IEC 62304 як узгоджений стандарт.
FDA регулює програмне забезпечення як медичний виріб за тією ж логікою призначення, з класами I, II та III та шляхами 510(k), De Novo та PMA. Закон про вдосконалення 21 століття (розділ 3060) виключив кілька категорій зі статусу виробів: адміністративне програмне забезпечення, загальне оздоровлення, електронні медичні записи та клінічна підтримка рішень, яка дозволяє клініцисту самостійно переглядати основу рекомендації (керівництво FDA 2022 щодо CDS інтерпретує це вузько). FDA визнає IEC 62304 як консенсусний стандарт і з 2023 року вимагає документації з кібербезпеки для "кібер-виробів". ISO 13485 стане основою американського регулювання системи якості (QMSR) у 2026 році.
В Anpheros
Anpheros Daily зберігає, відображає та ділиться; він не оцінює, не інтерпретує та не рекомендує, і його призначення це підтверджує. Тому він не є медичним виробом згідно з Правилом 11 або винятками Закону про вдосконалення, і команда застосовує безпеку в стилі ISO 27001 та документовану практику розробки програмного забезпечення без регуляторного шляху для виробів. Якби будь-яка функція з медичним призначенням була додана, вона була б класифікована за Правилом 11 та розроблена згідно з IEC 62304 перед випуском. Дивіться Прозорість охорони здоров'я.
Ця сторінка пояснює регулювання для команд з розробки продуктів та інженерії. Це не юридична консультація; тексти, посилання на які наведено в розділі "Джерела", є авторитетними, а ваш спеціаліст з питань захисту даних, уповноважений орган або юрист приймають рішення у вашому випадку. Останній перегляд: жовтень 2026 року.
Пов'язані сторінки
- Чи є медичний додаток медичним виробом? EU MDR Правило 11
- MDR проти IVDR
- CDS Hooks пояснено
- Карта регулювання медичних даних
- Закон ЄС про ШІ та ШІ в охороні здоров'я
Джерела
- Регламент (ЄС) 2017/745 (MDR), Додаток VIII, EUR-Lex
- MDCG 2019-11: Кваліфікація та класифікація програмного забезпечення
- IEC 62304:2006+AMD1:2015, Процеси життєвого циклу програмного забезпечення медичних виробів
- IEC 82304-1:2016, Безпека програмних продуктів для здоров'я
- FDA: Керівництво щодо програмного забезпечення для клінічної підтримки рішень (2022)
- FDA: Програмне забезпечення як медичний виріб
Поширені запитання
Чи може програмне забезпечення мати клас I за MDR?
Так, але рідко: лише програмне забезпечення з медичним призначенням, яке не інформує діагностичні чи терапевтичні рішення та не моніторить фізіологічні процеси. Більшість додатків, які кваліфікуються як вироби, потрапляють до класу IIa.
Чи потребує пристрій класу IIa клінічних випробувань?
Він потребує клінічної оцінки, яка може базуватися на літературі, еквівалентності та даних про ефективність; клінічне дослідження вимагається, коли наявних доказів недостатньо. Програмне забезпечення, яке заявляє про діагностичну ефективність, зазвичай потребує власного дослідження ефективності.
Чи є IEC 62304 обов'язковим?
Це гармонізований стандарт, тому його дотримання є припущенням відповідності вимогам MDR до програмного забезпечення (Додаток I, 17). Ви можете використовувати інший підхід, але тоді вам доведеться довести еквівалентність, що на практиці ніхто не робить.
А як щодо функцій ШІ?
Застосовуються ті самі правила, плюс Закон ЄС про ШІ: виріб з оцінкою уповноваженого органу є системою ШІ високого ризику згідно з Додатком I, з вимогами до даних, журналювання, прозорості та людського нагляду, що оцінюються разом з MDR.
Спробуйте безкоштовно в пісочниці
Перший запит FHIR за 5 хвилин. API стандарту HL7 FHIR R4 з вбудованою згодою пацієнта: спробуйте в пісочниці, а потім підключіть власну програму чи клінічну систему.
Безкоштовно · 30 синтетичних пацієнтів · без картки
Anpheros створює медичну карту, яку пацієнт контролює та може ділитися з будь-якою клінікою, на платформі HL7 FHIR R4, розташованій в ЄС. Ці посібники допоможуть вам зрозуміти та організувати своє здоров'я; вони не замінюють вашого лікаря.
Про Anpheros →