Недавно мы успешно прошли аудит по «ISO 13 485–2017. Изделия медицинские. Системы менеджмента качества». Основная цель была очень простая — наличие этого сертификата теперь часто включают в требования при закупках медицинских ИИ‑систем. Я сам участвовал в аудите — меня расспрашивали про то, как мы тестируем наши системы и мониторим качество их работы на продакшне.Если вы хотите узнать ещё больше об организации процессов ML‑разработки, подписывайтесь на наш Телеграм‑канал Варим ML.

Стандарт довольно общий — он распространяется на все медицинские изделия, не только на ПО и тем более не только на ПО на основе машинного обучения. Никаких конкретных указаний по поводу имплементации тех или иных требований там нет, а основная часть касается документирования всех процессов производства, тестирования и выпуска продукции.

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

• документация моделей в репозитории

• результаты метрик‑тестов в ClearML

• разнообразная документация в Notion — доски с задачами, описания датасетов, результаты медицинского мониторинга и многое другое

• алерты в Sentry

• данные о работе систем в Grafana

• логи в ELK

• ML‑дашборды на Streamlit

Поэтому мне хотелось минимизировать дополнительную нагрузку на команды и лидов, поэтому в результате брейнсторма с ребятами родился план действий.

Разделение релизов на major и minor

Первым делом стало понятно, что релизы делятся на две большие группы. Несколько раз в год происходят большие изменения модели — дообучение на новых данных, изменения архитектуры нейронки, изменения препроцессинга. Короче, всё то, что влияет на итоговые метрики качества системы — ROC‑AUC, чувствительность, специфичность и точность локализации патологий. Эти релизы сопровождаются полными замерами всех метрик — как внутри компании, так и на внешнем тестировании. Между этими обновлениями происходят десятки небольших релизов — фиксы багов, небольшие добавления функциональности, модификации текстового отчёта и многое другое. Чтобы удостовериться, что ничего не сломалось, мы прогоняем тесты на неизменность ответа и небольшие метрик‑тесты.

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

Так или иначе внутренние процедуры отличаются в зависимости от типа релиза, поэтому первым делом мы разделили процессы документирования на две группы.

Отчёт о валидации ПО

Начнём с major‑релизов. Раз меняются метрики — нужен полный отчёт по тестированию ПО. Мы решили вести их в формате Markdown и добавлять прям в репозиторий для удобства версионирования. В момент релиза дополнительно выгружаем отчёт по релизу в виде PDF и вставляем ссылку в таблицу релизов. Имеет он примерно такую структуру:

• Основная информация — название и версия системы, дата утверждения, ответственное лицо

• Список основных изменений в текущей версии ПО — краткий список, полное описание содержится в карте модели

• Программа внутреннего предрелизного тестирования — это самый большой раздел, который содержит список автоматических тестов работоспособности ПО и внутренних метрик‑тестов, описание тестовых датасетов, описание метрик, результаты (включая ручное и визуальное тестирование)

Чтобы избежать дублирования и лишней работы, в отчёт включаются основные метрики и выводы, а для более детального анализа можно перейти по ссылкам и провалиться в ClearML или отчёт врача‑консультанта в Notion.

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

Техническое задание на релиз

Ещё одно требование стандарта — наличие технического задания, которое отвечает на вопросы зачем и как проводились работы по обновлению версии. Шаблон тоже сделали максимально простым:

• Основная информация — название и версия системы, дата утверждения

• Основные цели — зачем начинали работы по улучшению, достигнуты ли эти цели

• Ссылки на релевантные задачи — ссылки на фичи и задачи в таск‑трекере

Пожалуй, это наиболее формальный документ из внедрённых, но и он в итоге оказался не совсем бесполезным — из таблицы релизов можно быстро перейти в этот документ, а оттуда на связанные с релизом задачи.

Предрелизный чек-лист

Создание двух описанных документов для каждого мини‑релиза — явный оверкилл. Мы решили ограничиться кратким описанием изменений в таблице релизов и ссылкой на предрелизный чек‑лист, который создаётся перед релизом в стейдж‑среду и содержит следующие разделы:

• Preparation — что нужно сделать перед началом релизных процедур, например, убедиться, что в репозитории обновлена версия системы

• Build — как запустить сборку релизных образов

• Deploy — куда нажать, чтоб задеплоить релиз на стейдж

• Monitoring — как проверить, что нужная версия раскатилась и корректно работает

• Documentation — куда нужно пойти и что обновить в документации

• Testing — какие тесты нужно запустить для системы после её успешной выкатки в стейдж‑среду

Такие чек‑листы значительно уменьшают когнитивные усилия, которые нужно приложить, чтобы удостовериться, что всё прошло без проблем.

Заключительные мысли

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

Добавлю, что в этом посте я описал лишь те изменения, которые напрямую повлияли на процессе в ML‑отделе. Весь процесс также потребовал огромной работы со стороны менеджмента — финальная версия руководства по качеству включает в себя более 60 страниц текста и схем. Команда бэкенда тоже внедрила у себя релизные чек‑листы и довольна результатом.

Внедрение ISO 13 485 — это не единоразовая процедура, а продолжающийся процесс по улучшению процессов в организации. Наша следующая цель — подробно описать и формализовать процедуру мониторинга работы наших систем — как техническую, так и с точки зрения клинического качества.