Прибыль:
- Способность объяснить вклад искусственного интеллекта в требования, архитектуру и этапы тестирования при разработке медицинского оборудования и программного обеспечения.
- Понимание роли контроля проектирования и управления рисками в случае, если само программное обеспечение является медицинским изделием (SaMD).
- Способность понимать, что результаты проектирования, поддерживаемые искусственным интеллектом, должны быть проверены компетентными инженерами, а также стандартными и проверочными тестами.
Одной из основных профессий биомедицинского инженера является проектирование медицинского оборудования: от инфузионного насоса до монитора пациента, от протеза до диагностического программного обеспечения. Поскольку эти устройства вступают в прямой контакт с пациентом, их конструкция отличается от конструкции обычных продуктов; Контроль проектирования (дисциплинированный процесс, в котором документируется каждый шаг от требования до проверки) и управление рисками являются юридическими обязательствами. Искусственный интеллект вносит свой вклад в эти процессы посредством написания требований, составления архитектурных проектов, проектирования тестов и документации. В этом модуле мы увидим, как ИИ вписывается в конструкцию устройства, как само программное обеспечение становится устройством (SaMD) и почему результаты ИИ не заменяют одобрение компетентного инженера.
Скажем с самого начала: в разработке устройств, критически важных для безопасности, ИИ — это помощник по проектированию и управлению. Если требование отсутствует, пропущен режим отказа, тест выходит за рамки, ответственность лежит на подписывающем инженере. ИИ не проверяет конструкцию; Инженер подтверждает.
Проектирование цепочки контроля и место ИИ
Потребности пользователя → Входные данные для проектирования (требования) → Выходные данные для проектирования → Верификация → Валидация → Передача проекта. Эта цепочка является основой приборостроения. Роль ИИ в каждом кольце различна:
- Потребности пользователей: ИИ может обобщать и тематизировать интервью с заинтересованными сторонами и заметки на местах. Валидация: подтверждение заинтересованной стороны.
- Требования: ИИ сканирует требования, чтобы увидеть, являются ли они «проверяемыми, единичными, противоречивыми», и предлагает недостающие сценарии (краевые случаи). Валидация: проверка инженера.
- Архитектура/дизайн: ИИ перечисляет альтернативные архитектурные подходы и известные шаблоны проектирования. Проверка: инженерное заключение и расчет.
- Тестирование: ИИ генерирует тестовый пример и тест точки останова на основе требований. Валидация: матрица тестового покрытия.
- Документация: файлы истории проектов и отчеты проектов 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 обновила базовую модель, добавив «лучшую» версию. Хотя новая версия улучшила общую точность, ее производительность на устройствах определенного типа снизилась. Без контроля изменений и повторной проверки эта регрессия достигла бы практического применения. Каждое обновление модели представляет собой изменение конструкции и должно быть проверено.
Слабая подсказка/Сильная подсказка
Слабая подсказка:
Напишите требования к этому устройству.[идея]
Мощная подсказка:
Ваша роль: вы являетесь помощником по разработке требований к медицинскому оборудованию (ВЫ НЕ ЯВЛЯЕТЕСЬ УТВЕРЖДАЮЩИМ ОРГАНОМ). Подготовьте черновой вариант требований для следующей концепции устройства: - Сохраняйте уникальность, возможность тестирования и проверки каждого требования. - Сделайте отдельный раздел для безопасности/сигнализации и крайних случаев. - Отмечайте расплывчатые/неизмеримые утверждения («легкие», «быстрые») и делайте их измеримыми. — В конце дайте список «открытых вопросов, по которым инженеру необходимо решить». - Ссылки на стандарты/разделы как знак «подлежит проверке», определенное указание. Концепция: [описание]
Четыре копируемых шаблона
1) Требование к проверке качества:
Классифицируйте следующие требования как «проверяемые/неопределенные/противоречивые/повторяющиеся» и предложите сделать все неоднозначные измеримыми. Список: [требования]
2) Мозговой штурм FMEA:
Перечислите возможные режимы отказа для этой подсистемы; Предложите последствия и возможные причины для каждого из них. Укажите, что инженер выполнит оценку и смягчение последствий. Подсистема: [описание]
3) Генерация тестового сценария:
Сгенерируйте сценарии тестирования нормального, граничного и ошибочного ввода для следующего требования; пронумеруйте каждый сценарий, соответствующий требованию. Требование: [текст]
4) Анализ воздействия изменений в программном обеспечении медицинского назначения:
Напишите черновой контрольный список анализа воздействия для обновления выпуска модели: затронутые требования, объем повторной проверки, сравнение производительности подгрупп.
Роль модели: в зависимости от этапа проектирования.
Этап
Вклад ИИ
критичность
проверка
Резюме потребностей/заинтересованных сторон
высокий
низкий
Подтверждение заинтересованной стороны
Проект требований/аудит
высокий
средний
Обзор инженера
Архитектура/исчисление
ограниченный
высокий
Инженерное заключение + расчет
FMEA/мозговой штурм рисков
высокий
высокий
Оценка/утверждение инженера
Генерация тестового сценария
высокий
средний
Матрица покрытия
Одобрение безопасности
Нет
очень высокий
Подпись уполномоченного инженера
Совет: используйте ИИ в качестве «напоминания о забытом сценарии» в FMEA и аудите требований, а не в качестве «лица, принимающего решения». Его величайшая ценность заключается в том, что он выдвигает на передний план маргинальные ситуации, которые можно упустить; Но каждое предложение должно пройти через фильтр инженера.
Внимание: в SaMD каждое обновление модели представляет собой изменение конструкции. «Лучшая» модель может улучшить общий средний показатель и ухудшиться в подгруппе; Никакие обновления не должны поступать в эксплуатацию без контроля изменений и повторной проверки.
Распространенные ошибки
- Принятие рекомендации AI без подтверждения. Требование подгонки может привести к недопустимому режиму отказа или бесполезному смягчению последствий.
- Думая, что SaMD — это «просто программное обеспечение». Контроль проектирования, управление рисками и V&V являются обязательными.
- Не проверяется обновление модели. Каждый выпуск представляет собой изменение конструкции и требует повторной проверки.
- Выполнение расплывчатого требования. Неизмеримые утверждения типа «легко/быстро» не могут быть проверены.
- Обход одобрения инженера. Решение по безопасности и подпись принадлежат уполномоченному инженеру; ИИ не является органом утверждения.
В итоге
- Проектирование медицинского оборудования, контроль проектирования и управление рисками являются обязательными документированными процессами.
- ИИ участвует в разработке требований, архитектуры, FMEA и этапах тестирования с помощью черновиков и напоминаний.
- Если само программное обеспечение является устройством (SaMD), требуется полный контроль проектирования, проверка и верификация и соответствие нормативным требованиям.
- Каждое обновление модели представляет собой изменение конструкции и требует повторной проверки.
- Выходные данные AI не заменяют одобрение квалифицированного инженера; Решение безопасности и подпись принадлежат инженеру.
Задача приложения
Выберите простую концепцию медицинского устройства (например, портативный монитор SpO2). Составьте пять требований, используя мощную подсказку; за которым следует вопрос каждого: «Можно ли это проверить?» Проверьте вручную и сделайте расплывчатые измеримыми. Наконец, запишите три режима отказа для этого устройства и способы устранения для каждого и отметьте, какие из них вы исключили из того, что предложил ИИ.
контрольный список
- [ ] Я знаю цепочку контроля проектирования и роль ИИ в каждом звене.
- [ ] Я понял цель управления рисками ISO 14971 и FMEA.
- [ ] Я понимаю концепцию программного обеспечения медицинского назначения и его обязательства.
- [ ] Я понимаю, что обновление модели представляет собой изменение конструкции и требует повторной проверки.
- [ ] Я усвоил, что решение о безопасности и подпись остаются у уполномоченного инженера.