Прибуток:
- Здатність пояснити внесок штучного інтелекту у вимоги, архітектуру та етапи тестування в дизайні медичного обладнання та програмного забезпечення.
- Розуміння ролі контролю дизайну та управління ризиками у випадку, якщо саме програмне забезпечення є медичним пристроєм (SaMD)
- Здатність розуміти, що результати проектування, які підтримують ШІ, повинні бути перевірені за допомогою схвалення компетентних інженерів, стандартних і перевірочних тестів.
Однією з основних робіт біомедичного інженера є проектування медичних пристроїв: від інфузійного насоса до монітора пацієнта, від протеза до діагностичного програмного забезпечення. Оскільки ці пристрої безпосередньо контактують з пацієнтом, їх конструкція відрізняється від розробки звичайного продукту; Контроль проектування (дисциплінований процес, у якому кожен крок від вимоги до перевірки документується) та управління ризиками є юридичними зобов’язаннями. Штучний інтелект сприяє цим процесам, створюючи вимоги, проектуючи архітектурні проекти, проектуючи тести та документуючи. У цьому розділі ми побачимо, як штучний інтелект вписується в дизайн пристрою, як саме програмне забезпечення стає пристроєм (SaMD) і чому результати штучного інтелекту не замінюють схвалення компетентного інженера.
Давайте скажемо з самого початку: у розробці критично важливих для безпеки пристроїв штучний інтелект є проектом і помічником у управлінні. Якщо вимога відсутня, режим несправності пропущений, тест виходить за рамки, відповідальність лежить на інженері, який виписав. AI не перевіряє дизайн; Інженер підтверджує.
Проектування ланцюжка управління та місце ШІ
Потреби користувача → Вхідні дані проекту (вимоги) → Виходи проекту → Верифікація → Перевірка → Передача дизайну. Цей ланцюжок є основою розробки пристроїв. Роль ШІ в кожному кільці різна:
- Потреби користувачів: штучний інтелект може підсумовувати та тематизувати інтерв’ю із зацікавленими сторонами та польові нотатки. Перевірка: підтвердження зацікавленої сторони.
- Вимоги: штучний інтелект сканує вимоги, щоб перевірити, чи є вони «перевіреними, одиничними, суперечливими» та пропонує відсутні сценарії (граничні випадки). Перевірка: огляд інженера.
- Архітектура/дизайн: AI перераховує альтернативні архітектурні підходи та відомі шаблони проектування. Перевірка: інженерна оцінка та розрахунок.
- Тестування: штучний інтелект генерує тестовий приклад і тест контрольної точки на основі вимоги. Перевірка: матриця тестового покриття.
- Документація: штучний інтелект створює файл історії дизайну та звіти. Перевірка: перевірка технічного вмісту.
Управління ризиками: ISO 14971 та FMEA
Стандартом управління ризиками в медичних пристроях є ISO 14971; Він описує процес виявлення небезпек, оцінки ризику, його пом’якшення та обґрунтування залишкового ризику. Загальним інструментом є FMEA (Аналіз режиму та наслідків відмови; систематично перераховує можливі режими відмови, їхні наслідки та показники серйозності/ймовірності/виявленості). ШІ дуже ефективний у мозковому штурмі режимів несправностей для діаграми FMEA — нагадування про режими, які людина може пропустити. Але правдивість кожної лінії, її оцінка та міра пом'якшення повинні бути підтверджені судженням інженера; «Пом’якшення», запропоноване штучним інтелектом, може насправді не спрацювати або створити новий ризик.
Якщо саме програмне забезпечення є пристроєм: SaMD
Іноді саме програмне забезпечення є медичним пристроєм: SaMD (Програмне забезпечення як медичний пристрій; програмне забезпечення, яке працює для цілей діагностики/лікування/моніторингу без вбудованого апаратного забезпечення). Прикладом є програма, яка створює оцінку ризику на основі зображення або алгоритму, який інтерпретує сигнал. З SaMD програмне забезпечення не можна розглядати як «просто програмне забезпечення»: контроль дизайну, управління ризиками, перевірка/валідація, контроль версій і відповідність нормативним вимогам є обов’язковими. Стандарт IEC 62304 визначає процеси для життєвого циклу програмного забезпечення. Особливою проблемою в розробці за допомогою ШІ є те, що поведінка моделі змінюється в міру її оновлення; ось чому контроль змін і повторна перевірка є критичними.
Три міні-кейси: у цифрах
Випадок 1 — Виявлення розриву вимог. Написано 140 проектів вимог до монітора пацієнта. Сканування узгодженості за допомогою штучного інтелекту позначило 12 вимог як такі, що не підлягають тестуванню (наприклад, «має бути зручним для користувача»), а 3 сценарії тривоги — як відсутні. Команда інженерів виправила їх; але дві «нові вимоги», запропоновані ШІ, насправді були дублюванням існуючих і повинні були бути усунені. Чистий прибуток визначається людиною.
Випадок 2 — прискорення FMEA. У дослідженні FMEA для інфузійного насоса команда перерахувала 60 режимів відмови; ШІ мозковий штурм створив 18 додаткових кандидатів. Інженери виявили, що 9 з них були справжніми та були пропущені раніше, і вилучили 9 як недійсні або дублікати. Економія часу була справжньою, але фільтрація була виключно роботою інженера.
Випадок 3 — ризик оновлення моделі. Команда SaMD оновила базову модель за допомогою «кращої» версії. Хоча нова версія покращила загальну точність, її продуктивність знизилася на певних типах пристроїв. Без контролю змін і повторної перевірки ця регресія досягла б поля. Кожне оновлення моделі є зміною дизайну та має бути перевірено.
Слабка підказка / Сильна підказка
Слабка підказка:
Напишіть вимоги до цього пристрою.[idea]
Потужна підказка:
Ваша роль: Ви асистент з розробки вимог до медичних пристроїв (ВИ НЕ ОРГАН ЗАТВЕРДЖЕННЯ). Створіть проект вимог до такої концепції пристрою: - Зберігайте кожну вимогу унікальною, придатною для тестування та перевірки. - Зробіть окремий розділ для безпеки/сигналізації та крайових випадків. - Позначте розпливчасті/невимірні твердження («легкий», «швидкий») і зробіть їх вимірними. - Наприкінці наведіть список «відкритих питань, де інженер повинен вирішити». - Посилання на стандарти/пункти як знак "підлягає перевірці", точна вказівка. Концепція: [опис]
Чотири шаблони, які можна копіювати
1) Перевірка якості вимог:
Класифікуйте наступні вимоги як «перевірені/розпливчасті/суперечливі/дублікати» та запропонуйте зробити будь-яку неоднозначність вимірюваною. Список: [вимоги]
2) Мозковий штурм FMEA:
Перерахувати можливі режими відмови для цієї підсистеми; Запропонуйте наслідки та можливі причини для кожного. Зазначте, що інженер зробить оцінку та пом’якшення. Підсистема: [опис]
3) Генерація тестового сценарію:
Створити звичайні, граничні сценарії та сценарії тестування з помилковим введенням для наступної вимоги; пронумеруйте кожен сценарій, що відповідає вимогам. Вимога: [текст]
4) Аналіз впливу змін SaMD:
Напишіть чернетку контрольного списку аналізу впливу для оновлення випуску моделі: вимоги, на які впливає, обсяг повторної перевірки, порівняння продуктивності підгрупи.
Роль моделі: відповідно до фази проектування
етап
внесок ШІ
критичність
перевірка
Резюме потреб/зацікавлених сторін
висока
низький
Підтвердження зацікавленої сторони
Проект вимог/аудит
висока
середній
Інженерний огляд
Архітектура/обчислення
обмежений
висока
Інженерна оцінка + розрахунок
FMEA/ризик мозковий штурм
висока
висока
Оцінка/затвердження інженера
Генерація тестового сценарію
висока
середній
Матриця покриття
Схвалення безпеки
Жодного
дуже високий
Підпис уповноваженого інженера
Порада: використовуйте AI як «нагадування про забутий сценарій» у FMEA та аудиті вимог, а не як «особу, яка приймає рішення». Його найбільша цінність полягає у висуненні на перший план маргінальних ситуацій, які можна було б упустити; Але кожна пропозиція повинна проходити через фільтр інженера.
Увага: у SaMD кожне оновлення моделі є зміною дизайну. «Краща» модель може підвищуватися в загальному середньому і регресувати в підгрупі; Жодні оновлення не повинні надходити в поле без контролю змін і повторної перевірки.
Поширені помилки
- Прийняття рекомендацій ШІ без підтвердження. Вимога підгонки може спричинити недійсний режим відмови або марне пом’якшення.
- Думаючи, що SaMD — це «просто програмне забезпечення». Контроль проектування, управління ризиками та перевірка та перевірка є обов’язковими.
- Не перевіряється оновлення моделі. Кожен випуск є зміною дизайну та має бути перевірений повторно.
- Передача розпливчастої вимоги. Невимірні твердження на кшталт «легко/швидко» не можна перевірити.
- В обхід дозволу інженера. Рішення з безпеки та підпис належать уповноваженому інженеру; AI не є органом, що займається затвердженням.
Підсумовуючи
- Розробка медичного обладнання, контроль дизайну та управління ризиками є обов’язковим, задокументованим процесом.
- AI сприяє вимогам, архітектурі, FMEA та етапам тестування за допомогою чернеток і нагадувань.
- Якщо пристроєм є саме програмне забезпечення (SaMD), потрібен повний контроль дизайну, перевірка та перевірка та відповідність нормативним вимогам.
- Кожне оновлення моделі є зміною дизайну та потребує повторної перевірки.
- Результати ШІ не замінюють схвалення кваліфікованого інженера; Рішення безпеки та підпис належать інженеру.
Аплікаційне завдання
Виберіть просту концепцію медичного пристрою (наприклад, портативний монітор SpO2). Створіть п’ять вимог за допомогою потужної підказки; із наступним запитом кожного: «чи можна це перевірити?» Перевірте вручну та зробіть невизначені вимірюваними. Нарешті, запишіть три режими збою для цього пристрою та пом’якшення для кожного з них, а також запишіть, які з них ви виключили з того, що запропонував AI.
контрольний список
- [ ] Я знаю ланцюг контролю дизайну та роль ШІ в кожній ланці.
- [ ] Я зрозумів мету управління ризиками ISO 14971 і FMEA.
- [ ] Я розумію концепцію SaMD та її зобов’язання.
- [ ] Я розумію, що оновлення моделі є зміною дизайну та потребує повторної перевірки.
- [ ] Я переконався, що рішення щодо безпеки та підпис залишаються за авторизованим інженером.