Недавно мы успешно прошли аудит по «ISO 13 485–2017. Изделия медицинские. Системы менеджмента качества». Основная цель была очень простая — наличие этого сертификата теперь часто включают в требования при закупках медицинских ИИ‑систем. Я сам участвовал в аудите — меня расспрашивали про то, как мы тестируем наши системы и мониторим качество их работы на продакшне.Если вы хотите узнать ещё больше об организации процессов ML‑разработки, подписывайтесь на наш Телеграм‑канал Варим ML. Стандарт довольно общий — он распространяется на все медицинские изделия, не только на ПО и тем более не только на ПО на основе машинного обучения. Никаких конкретных указаний по поводу имплементации тех или иных требований там нет, а основная часть касается документирования всех процессов производства, тестирования и выпуска продукции. Когда мы начинали этот процесс, на меня легла задача — привести процессы в ML‑отделе в соответствие со стандартом. Мне захотелось не просто формально выполнить требования, но заодно и улучшить и унифицировать некоторые наши процессы. Быстрый анализ показал, что каждая ML‑команда и так плодила достаточное большое количество документации и данных в процессе своей деятельности: документация моделей в репозитории результаты метрик‑тестов в ClearML разнообразная документация в Notion — доски с задачами, описания датасетов, результаты медицинского мониторинга и многое другое алерты в Sentry данные о работе систем в Grafana логи в ELK ML‑дашборды на Streamlit Поэтому мне хотелось минимизировать дополнительную нагрузку на команды и лидов, поэтому в результате брейнсторма с ребятами родился план действий. Первым делом стало понятно, что релизы делятся на две большие группы. Несколько раз в год происходят большие изменения модели — дообучение на новых данных, изменения архитектуры нейронки, изменения препроцессинга. Короче, всё то, что влияет на итоговые метрики качества системы — ROC‑AUC, чувствительность, специфичность и точность локализации патологий. Эти релизы сопровождаются полными замерами всех метрик — как внутри компании, так и на внешнем тестировании. Между этими обновлениями происходят десятки небольших релизов — фиксы багов, небольшие добавления функциональности, модификации текстового отчёта и многое другое. Чтобы удостовериться, что ничего не сломалось, мы прогоняем тесты на неизменность ответа и небольшие метрик‑тесты. Организаторы Московского эксперимента учитывают эту разницу и используют процедуру, примерно описанную вот здесь. Для небольших изменений достаточно письменной заявки от компании‑разработчика и одобрения от организаторов. При изменении метрик требуется прохождение калибровочного тестирования, на котором проверяется соответствие новой версии модели требованиям по качеству. Увы, при промышленной эксплуатации такое пока не катит — при любом, самом незначительном, изменении разработчик формально должен подавать заявку в Росздравнадзор на изменение регистрационного удостоверения. Так или иначе внутренние процедуры отличаются в зависимости от типа релиза, поэтому первым делом мы разделили процессы документирования на две группы. Начнём с major‑релизов. Раз меняются метрики — нужен полный отчёт по тестированию ПО. Мы решили вести их в формате Markdown и добавлять прям в репозиторий для удобства версионирования. В момент релиза дополнительно выгружаем отчёт по релизу в виде PDF и вставляем ссылку в таблицу релизов. Имеет он примерно такую структуру: Основная информация — название и версия системы, дата утверждения, ответственное лицо Список основных изменений в текущей версии ПО — краткий список, полное описание содержится в карте модели Программа внутреннего предрелизного тестирования — это самый большой раздел, который содержит список автоматических тестов работоспособности ПО и внутренних метрик‑тестов, описание тестовых датасетов, описание метрик, результаты (включая ручное и визуальное тестирование) Чтобы избежать дублирования и лишней работы, в отчёт включаются основные метрики и выводы, а для более детального анализа можно перейти по ссылкам и провалиться в ClearML или отчёт врача‑консультанта в Notion. Внедрение такого шаблона отчёта не только дисциплинировало работу команд и упростило решение о релизе новой версии, но и сильно помогло в создании всяких маркетинговых материалов, в которые нужно включать актуальные метрики. Ещё одно требование стандарта — наличие технического задания, которое отвечает на вопросы зачем и как проводились работы по обновлению версии. Шаблон тоже сделали максимально простым: Основная информация — название и версия системы, дата утверждения Основные цели — зачем начинали работы по улучшению, достигнуты ли эти цели Ссылки на релевантные задачи — ссылки на фичи и задачи в таск‑трекере Пожалуй, это наиболее формальный документ из внедрённых, но и он в итоге оказался не совсем бесполезным — из таблицы релизов можно быстро перейти в этот документ, а оттуда на связанные с релизом задачи. Создание двух описанных документов для каждого мини‑релиза — явный оверкилл. Мы решили ограничиться кратким описанием изменений в таблице релизов и ссылкой на предрелизный чек‑лист, который создаётся перед релизом в стейдж‑среду и содержит следующие разделы: Preparation — что нужно сделать перед началом релизных процедур, например, убедиться, что в репозитории обновлена версия системы Build — как запустить сборку релизных образов Deploy — куда нажать, чтоб задеплоить релиз на стейдж Monitoring — как проверить, что нужная версия раскатилась и корректно работает Documentation — куда нужно пойти и что обновить в документации Testing — какие тесты нужно запустить для системы после её успешной выкатки в стейдж‑среду Такие чек‑листы значительно уменьшают когнитивные усилия, которые нужно приложить, чтобы удостовериться, что всё прошло без проблем. Первые новости о внедрении ISO вызвали немало сопротивления и скептицизма — в том числе и у меня. Результат, однако, меня порадовал. При минимальном изменении процессов и небольшом оверхеде мы смогли не только пройти аудит, но и улучшить собственные процессы. Когда мы всерьёз взялись за дело, я понял, что нельзя подходить к этому процессу формально — наши системы обрабатывают исследования реальных людей, и мы не можем позволить себе халатность и ошибки по невнимательности. Добавлю, что в этом посте я описал лишь те изменения, которые напрямую повлияли на процессе в ML‑отделе. Весь процесс также потребовал огромной работы со стороны менеджмента — финальная версия руководства по качеству включает в себя более 60 страниц текста и схем. Команда бэкенда тоже внедрила у себя релизные чек‑листы и довольна результатом. Внедрение ISO 13 485 — это не единоразовая процедура, а продолжающийся процесс по улучшению процессов в организации. Наша следующая цель — подробно описать и формализовать процедуру мониторинга работы наших систем — как техническую, так и с точки зрения клинического качества.  Head of AI