Пять распространенных ошибок команд SaMD при работе с ИИ

Регулярные беседы с разработчиками программного обеспечения как медицинского устройства (SaMD) выявляют одни и те же трудности. Хотя команды прекрасно разбираются в технологиях ИИ, их моделях, обучении и принципах работы, основные проблемы возникают в сфере нормативного соответствия. Камень преткновения — это архитектура соответствия: планы по управлению изменениями, подтверждение качества данных и системы мониторинга алгоритмов после их выпуска. Именно здесь кроются причины претензий со стороны FDA, поэтому важно сосредоточиться на конкретных ошибках, а не на абстрактном регулировании ИИ.

В предыдущих материалах уже рассматривалась регуляторная база FDA для ИИ в медицинских устройствах, включая определение SaMD, разницу между фиксированными и адаптивными алгоритмами, а также основные требования. Данная статья дополняет ту информацию, фокусируясь на практических ошибках, которые часто допускают команды SaMD при применении этих правил к реальным устройствам.

Ошибка первая: отношение к плану управления изменениями как к простому документу для подачи

Предварительно определенный план контроля изменений (PCCP) информирует FDA о предполагаемых изменениях в алгоритме после получения разрешения, методах их валидации и оценке производительности. Многие команды составляют его незадолго до подачи заявки, представляя его как описание желаемого процесса. Однако эксперты легко отличают PCCP, отражающий реальный процесс разработки, от документа, "подстроенного" под нормативные требования. Если ваш порядок контроля изменений, протокол валидации и сам PCCP не являются взаимосвязанными частями единого реального процесса, вы, по сути, предоставляете недостоверную информацию регулятору, чья задача — выявлять такие расхождения.

Ошибка вторая: игнорирование демографического анализа обучающих данных

FDA требует информацию об источниках ваших данных для обучения, валидации и тестирования, а также о том, насколько они репрезентативны для целевой группы пациентов. Это не формальная проверка. Алгоритм, демонстрирующий хорошие общие показатели, может давать сбои в определенных подгруппах, что чревато проблемами безопасности. Команды, сосредоточенные исключительно на общей точности, сталкиваются с этим либо при проверке, либо, что хуже, после получения жалоб.

Ошибка третья: внедрение ИИ в систему качества, разработанную для аппаратных средств

Большинство систем менеджмента качества (СМК) создавались для контроля физических компонентов и документов, которые не меняются после утверждения. Адаптивные алгоритмы по своей природе нарушают этот принцип. Если ваша СМК не предусматривает специфические категории рисков для алгоритмов согласно ISO 14971 и AAMI TIR34971, вы пытаетесь управлять изменениями программного обеспечения с помощью системы, предназначенной для ревизий спецификаций материалов. Решение не в добавлении новых папок, а в разработке механизмов контроля проектирования и управления рисками, учитывающих динамичный характер контролируемого продукта.

Ошибка четвертая: считать получение разрешения конечной целью

Разрешение FDA для устройства с ИИ — это важный этап, но не финиш. Команды, которые строят свою систему качества исключительно вокруг получения этого разрешения и останавливаются на достигнутом, ориентируются на неверную цель. Модель жизненного цикла продукта предполагает множество контрольных точек по мере эволюции алгоритма, а система качества, не способная демонстрировать постоянный мониторинг, разработана для статичного продукта.

Ошибка пятая: ожидание жалоб вместо отслеживания дрейфа

Традиционный пострыночный надзор носит реактивный характер: что-то идет не так, клиент сообщает, компания расследует. Эта модель неприменима для адаптивных алгоритмов, поскольку к моменту появления серии жалоб алгоритм уже может существенно отклониться от валидированных границ. Активный мониторинг, отслеживающий производительность в реальных условиях относительно утвержденного базового уровня и выявляющий дрейф до того, как он станет угрозой безопасности, — это стандарт, к которому стремится FDA. Компании, не внедрившие такую практику, с наибольшей вероятностью получат письмо с запросом описать их процесс мониторинга.

Ничего из этого не является экзотикой

Эти ошибки являются предсказуемым результатом применения 'аппаратного' мышления к продукту, который по своей сути предназначен для изменений. Команды, которые действуют правильно, строят свою инфраструктуру качества с учетом изменений с самого начала: это версионированная история проектирования, отслеживающая итерации алгоритма так же, как команда разработчиков ПО отслеживает выпуски; файлы рисков, рассматривающие ложноотрицательный результат в отдельной подгруппе как отдельный вид сбоя; и системы наблюдения, автоматически собирающие данные о производительности в реальных условиях, вместо того чтобы ждать жалобы. Подход к компетентному использованию ИИ в медицинских устройствах подразумевает ежедневное следование этим принципам.

Например, компания Spark Biomedical, внедряя новое нейростимулирующее устройство, сократила общие сроки разработки продукта на 50% после того, как ее система качества стала соответствовать инженерным процессам, а не противоречить им. В этом и заключается разница между СМК, рассматривающей каждое изменение как исключение, и той, что изначально разработана с учетом изменений.

Если ваша команда разрабатывает устройство с поддержкой ИИ, и ваша система менеджмента качества до сих пор предполагает, что после получения разрешения никаких изменений не будет, этот пробел необходимо устранить до того, как его обнаружит регулятор.