Опыт внедрения ISO 13485 с учетом изменений в процессах разработки
Недавно мы успешно прошли аудит по «ISO 13485–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 13485 — это не единоразовая процедура, а продолжающийся процесс по улучшению процессов в организации. Наша следующая цель — подробно описать и формализовать процедуру мониторинга работы наших систем — как техническую, так и с точки зрения клинического качества.
