Критерии выбора медицинских ИИ-систем

В этом году в России каждый субъект РФ закупил не менее одной ИИ-системы в здравоохранении.В следующем году - таких внедрений будет не менее 3 в каждом регионе Где-то выбрали предиктивную аналитику на основе данных электронных медицинских карт (ЭМК), где-то - системы для работы с медицинскими изображениями. Но даже внутри одного направления конкуренция часто очень высокая - например, только по направлению рентгена лёгких в каталоге Московского эксперимента числится семь сервисов. Как выбрать лучшее решение?

Критерии выбора медицинских ИИ-систем

Автор статьи: Евгений Никитин - технический директор Цельс

Фактически для ИИ в медицине сейчас не существует прозрачного процесса по выбору среди конкурирующих решений, и выбор происходит в лучшем случае по формальным критериям, в худшем - "по знакомству". Да, каждое решение должно соответствовать техническому заданию (ТЗ), но как и кем оно пишется, кто проверяет решения на соответствие, формально он это делает или с полным погружением - это всё как карта ляжет.

Есть ещё один понятный инструмент - это государственная сертификация. Регистрационное удостоверение на медицинское изделие Росздравнадзора в России, CE marking for medical devices в ЕС, UKCA marking в Британии и, конечно, же FDA Approval в США. Казалось бы, если ИИ-система прошла такую сертификацию, то это доказывает её безопасность, эффективность и заявленные в клинических испытаниях метрики качества. Бери любую с хорошими подтвёрждёнными метриками точности - не прогадаешь. Конечно же, это очень далеко от правды, причём это верно не только для России.

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

Полезные мысли на этот счёт можно почитать в гайде от британской NHS.

Обсудим:

  • Как проблема, которую должен решать ИИ, напрямую влияет на выбор критериев качества
  • Как обеспечить честное сравнение ИИ-систем по выбранным критериям
  • Что важно не забывать про особенности вашего медицинского учреждения или региона
  • Какие ещё факторы кроме метрик точности могут влиять на выбор
  • Как после покупки убедиться, что не купили шляпу

Сценарии применения

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

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

Категоризаций сценариев использования медицинских ИИ-систем существует великое множество. Достаточно простая и разумная приводится в статье Assessment of Radiology Artificial Intelligence Software: A Validation and Evaluation Framework. Все ИИ-системы в радиологии можно разбить на три группы по их роли:

  • Триаж. Классический триаж - это разбиение пациентов на несколько групп по срочности необходимых медицинских мероприятий. ML-модели позволяют делать это ещё детальнее - сортировать пациентов по вероятности патологии или другим признакам. Такая сортировка может потом использоваться для оптимизации рабочего процесса врача (срочных пациентов можно смотреть в первую очередь или автоматически отправлять на дополнительное обследование) или распределения пациентов по врачам разной квалификации и специализации.
  • Системы поддержки принятий решений. Сюда можно включить все вспомогательные сценарии применения, при которых врач пользуется результатами работы ИИ-системы, но самостоятельно принимает все решения. Это подсвечивание сложных областей интереса (например, микрокальцинатов на маммографии), чтобы врач не пропустил их при высокой загруженности; оценка дополнительных параметров (плотность молочной железы); автоматизация рутинных измерений (объём кровоизлияния) и других задач (распознавание голоса и автоматическое заполнение протокола).
  • Автоматизация. Самый страшный для всех врачей сценарий - частичная или полная замена человека ИИ-системой, в статье он так и называется - replacement. Это, например, автоматическое определение исследований, где с близкой к 100% вероятностью нет никаких патологий - и автоматическая генерация протоколов для таких исследований.

Есть ещё отдельная большая категория "менеджерских" ИИ-систем - например, прогнозирование объёма исследований на период и предсказание пропуска процедур пациентам.

Логично предположить, что важность разных критериев и метрик будет очень сильно отличаться для разных сценариев. К примеру:

  • Для триажа важнее всего будет возможность ML-системы корректно сортировать пациентов по степени риска (ROC-AUC для бинарных предсказаний, MA-MAE для ординальных шкал) и количество некорректных определений пациентов с высоким риском в низкие группы (чувствительность). При ретроспективном анализе (пересмотр большой выборки исследований) на первый план может выйти минимизация ложноположительных срабатываний.
  • В СППВР в зависимости от конкретного применения могут играть ключевую роль количество ложных срабатываний (FPR, FROC-AUC), качество локализации (mAP, DICE, OC-cost), корректность оценки размеров (MAE), скорость работы системы и многие другие показатели.
  • В сценарии автоматизации критическими становятся пропуски патологий системой, но важен и процент исследований, которые система может корректно отсеить как не содержащие патологию. Поэтому здесь может подойти метрика Specificity@(Recall = 1.0) - специфичность при фиксированной стопроцентной чувствительности.

Ещё одна вещь встречается постоянно и доводит лично меня до белого каления. Представьте, что заказчик хочет использовать ИИ-систему для минимизации пропусков случаев рака на скрининге, приходит к двум разработчикам, запрашивает демо-доступ без объяснения своего сценария применения и проводит на ИИ-системе с настройками "из коробки" мини-тест с такими результатами:

Критерии выбора медицинских ИИ-систем

Какая система лучше? Вопрос с подвохом, без знания сценария применения ответить сложно. Но кажется, что ИИ-2 как минимум не хуже - ROC-AUC повыше, высокая чувствительность, неплохая специфичность, F1-score выше. Но неискушённый в ИИ заказчик почти наверняка предпочтёт ИИ-1, потому что для его сценария он подходит лучше - ведь не пропускает рак! А вот если бы ИИ-2 быстро донастроили под сценарий заказчика - результаты могли бы быть совсем другими. Вывод - рекомендую в самом начале максимально подробно описать свой сценарий использования и поделиться им с ИИ-вендором до начала тестирования. Вот пример, как это можно делать.

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

У многих появится логичный вопрос: а почему речь идёт только об ML-метриках, если в итоге нам важно другое - сэкономленные деньги, спасённые жизни, снижение нагрузки на врачей? Всё так, только вот в рамках процедуры тестирования оценить эти показатели очень тяжело, по крайней мере на данный момент. О некоторых причинах я говорил вот в этом видео. Да, есть пилотные проекты, о их достоинствах и недостатках поговорим чуть позже.

Вывод: копировать вслепую ТЗ или выбирать систему по какой-нибудь общей метрике - не очень хорошая практика. Процедура оценки должна учитывать проблему, которую должна решить ИИ-система, и ключевые бизнес-показатели, по которым будут оцениваться результаты.

Базовые вопросы, которые помогут правильнее подобрать метрики и датасеты:

  • Какую бизнес-проблему должно решить внедрение ИИ-системы?
  • Кто является конечным пользователем - терапевт, рентгенолог, пациент, заведующий отделением, администратор?
  • Какие последствия будут при ошибках в работе ИИ-системы?

А в этой статье содержатся рекомендации по выбору конкретных ML-метрик для разных задач.

А у тебя точно АУК 0.99?

Окей, метрики выбраны и, может быть, даже собран размеченный набор данных. Как обеспечить честную процедуру тестирования? Рассмотрим разные варианты - в порядке возрастания сложности и временных и денежных затрат.

Выбор на основе данных производителя

Начнём с самого плохого, но существующего варианта - идём на сайты компаний, выбираем ту, у которой выбранная нами метрика максимальна, и пишем под них ТЗ. Думаю, не надо объяснять, что сайт компании - не очень хорошее место для получения такой информации. Даже если там удастся найти какие-то немаркетинговые числа, то справедливо сравнить таким образом разные системы - абсолютно невозможно. Разные датасеты, разные аутпуты системы - думаю, долго на этом останавливаться не надо.

Говорят, ИИ-системы с точностью ниже 90% сбрасывают в младенчестве со скалы
Говорят, ИИ-системы с точностью ниже 90% сбрасывают в младенчестве со скалы

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

Плюсы:

  • Очень дёшево и быстро

Минусы:

  • Очень слабо, а иногда даже отрицательно коррелирует с реальными результатами ИИ-системы в вашем учреждении

Независимая оценка

В этом случае мы опираемся на чужой опыт - смотрим, как ИИ-система проявила себя в схожих сценариях работы. Как это можно сделать?

В России есть очень неплохой вариант - изучить результаты работы ИИ-системы в рамках московского Эксперимента. Несмотря на экспериментальный статус в его рамках ИИ-сервисы обрабатывают реальные исследования, и результатам обработки пользуются реальные врачи. Организаторы регулярно публикуют так называемую "матрицу зрелости", которая даёт представление о качестве сервиса с трёх позиций:

  • Проспективный ROC-AUC (ось ординат) - рассчитывается на всём потоке обработанных исследований, за Ground Truth берётся мнение описывающего исследование врача (норма или патология).
  • Клиническая оценка (диаметр круга) - ежемесячная оценка на сбалансированной выборке из 80 исследованиях, оценивается качество классификации и локализации, производится врачом-экспертом.
  • Процент дефектов (ось абсцисс) - технический показатель, сколько исследований по формальным критериям ушли в брак обработки.
Курсор случайно упал на Цельс
Курсор случайно упал на Цельс

Насколько мне известно, в других странах пока экспериментов подобного масштаба нет, но в некоторых странах государственный регулятор ведёт общий каталог ИИ-сервисов с подробной информацией. А в США и Великобритании можно обратиться к ACR и NHS соответственно с целью получения независимого заключения о качестве работы сервиса (полагаю, что за отдельную плату).

Ещё один вариант - обратиться за отзывами в другие медицинские организации, где использовалось или пилотировалось данное решение.

Плюсы:

  • Независимая оценка качества работы системы
  • Не нужно иметь опыта работы с ИИ-системами и экспертизы по их оценке

Минусы:

  • Не тестируемся на собственных данных

Передача датасета производителю

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

Плюсы:

  • Дёшево и сердито

Минусы:

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

Платформа для тестирования

Бурный рост количества производителей ИИ-систем, естественно, привёл к появлению различных платформ и маркетплейсов. Некоторые из них были созданы известными производителями PACSов, а другие были разработаны специально под ИИ в радиологии.

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

Плюсы:

  • Требуется интеграция только с платформой, а не с отдельными производителями
  • Очень быстро можно получить сводные результаты по россыпи производителей

Минусы:

  • Нужно создавать свои датасеты для тестирования
  • Если это коммерческая, а не государственная платформа, то нужно отвалить денежку
  • Не каждый потенциально интересный ИИ-вендор будет представлен на платформе

Интеграция и ретроспективная валидация

Если такой платформы в стране нет, то придётся интегрироваться отдельно с каждым потенциально интересным вендором. Именно так чаще всего поступают коммерческие клиники. На бумаге интеграция по DICOM-протоколу очень проста, но на практике часто возникают всякие сложности - инфобез, сетевые проблемы, пропадающие админы и так далее. Альтернативно - при наличии веб или десктоп-приложения производитель может передать доступы для проведения тестирования.

Важное замечание, которое относится не только к этой схеме тестирования - в сфере здравоохранения действительно очень разнообразные и неочевидные данные. Иногда даже качественная система может показать плохие результаты из-за непредвиденной глупой ошибки - например, на ваших данных некорректно сработал алгоритм выбора серии. Если есть время и возможность - лучше всего предоставить ИИ-вендору небольшой пак (3-7 исследований) с вашими данными, чтобы заранее проверить корректность обработки и не тратить время на полноценный тест в случае необходимости доработок.

Плюсы:

  • Нет ограничений по списку производителей

Минусы:

  • Нужно создавать свои датасеты для тестирования
  • Временные затраты на интеграцию или установку приложения
  • Тяжелее обеспечить честность и прозрачность - в зависимости от конкретного процесса тестирования производитель ИИ-системы может иметь больше или меньше возможностей для манипулирования результатом

Пилотные проекты

Наконец, самое тяжеловесное решение - полноценный пилот с тестовым внедрением ИИ-решения в бизнес-процессы организации. Ещё один вариант - shadow deployment с параллельной интерпретацией всех исследований врачом и ИИ-системой.

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

Плюсы:

  • При правильной организации можно замерить не только проспективные ML-метрики, но и что-то более близкое к бизнесу

Минусы:

  • Долго, дорого
  • Тяжело организовать правильно
  • Требуется заинтересованность и вовлечение персонала
  • На реальных проспективных данных сложно получить вменяемые результаты для очень редких патологий

Особенности национальных DICOM

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

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

Наши любимые индийские данные - шум на фоне, отсутствие тегов в DICOM, неверная метка проекции, огромные белые рамки из-за сканирования плёнки..
Наши любимые индийские данные - шум на фоне, отсутствие тегов в DICOM, неверная метка проекции, огромные белые рамки из-за сканирования плёнки..

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

Устойчивость к аугментациям (преобразованиям исследований)

Зачем - позволяет оценить общую устойчивость модели, коррелирует с робастностью моделям к доменным сдвигам.

Примеры - геометрические трансформации (флип, сдвиг, зум, поворот), пиксельные трансформации (яркость, контрастность, блюр, шумы).

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

Общая генерализуемость

Зачем - позволяет оценить генерализуемость модели на сценариях работы из реального мира и качество работы системы на важных частях выборок данных.

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

Как - расчёт метрик (общих и по подгруппам) на специально подобранных датасетах, статистические тесты разницы в метриках для разных подгрупп.

Устойчивость к протоколу сбора изображений

Зачем - позволяет оценить устойчивость модели к параметрам процесса получения медицинских изображений.

Примеры - пониженная радиационная доза, разная степень компрессии органа. Больше примеров - тут.

Как - расчёт статистической значимости разницы в метриках для разных категорий.

Устойчивость к артефактам

Зачем - позволяет оценить устойчивость модели к часто встречающимся для модальности артефактам.

Примеры - посторонние предметы на изображении, засветы, некорректная укладка.

Как - расчёт стандартных метрик и визуальный анализ результатов обработки.

Проверка возможности обработки исследований с неверной мета-информацией

Зачем - позволяет оценить возможность работы модели на исследованиях с пропущенными или неверно заполненными DICOM-тегами.

Примеры - пропущенные или неверно заполненные теги модальности, части тела, стороны, проекции, спейсинга.

Как - проверяем возможность и корректность обработки на исследованиях с разными проблемами. Можно взять имеющийся датасет и в нём затирать или изменять теги.

Проверка корректности работы алгоритма по выбору серии

Зачем - позволяет оценить корректность работы системы в случае наличия в исследовании нескольких снимков или серий.

Примеры - снимки разных проекций (прямая и боковая), серии с разным кернелом или спейсингом, снимки разных частей тела, бракованные снимки вместе с нормальными.

Как - посылаем архив с несколькими исследованиями в систему и смотрим, какое изображение или серия были выбраны. Также полезно проверить поведение системы, если в архиве содержится только "плохие" серии - в идеале модель должна вернуть ошибку.

Другие факторы

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

  • Наличие нужной сертификации - во многих сценариях использования ИИ-решение должно быть зарегистрировано как медицинское изделие с правильным классом риска. К сожалению, пока законодательство немного отстаёт от реальности, и поэтому ИИ-системы регистрируются по тому же процессу, что и другие медизделия. А это, например, значит, что на каждую новую версию модельки нужно получать новое РУ, что может занять 6-12 месяцев...
  • Сложность интеграции - в идеале процесс интеграции в IT-инфраструктуру медицинской организации должен быть максимально отточен и занимать минимальное время.
  • UX (визуализация находок и текстовый отчёт) - фактор, который легко недооценить. Какое-то время назад мы первые удовлетворили новым требованиям по метрикам в Эксперименте по направлению рентгена лёгких и остались единственной работающей системой. Некоторые врачи стали спрашивать, а когда вернутся системы других производителей. Оказалось, что по качеству работы к нам претензий нет никаких, но у конкурентов просто более удобная панель отображения результатов. Задумались.
  • Скорость работы - для сценариев экстренной медицины это вообще критический показатель, но и при обычном использовании в формате СППВР вряд ли врачам хочется ждать результатов обработки по 10-15 минут.
  • Варианты деплоя - для некоторых медицинских учреждений критична возможность on-premise деплоя. Хотя для разработчиков облако, конечно, в разы удобнее.
  • Интерпретируемость - в научных статьях часто пишут исключительно о классификационных метриках. Но в реальности системы без возможности локализации находок применяются разве что при ретроспективном анализе.
  • Обучение пользователей - для наиболее эффективного использования ИИ-систем может понадобиться дополнительное обучение персонала. Начиная от банального "куда нажимать", заканчивая демонстрацией проверенных вариантов использования и известных проблем.
  • Стоимость - даже в такой сфере как здравоохранение не уйти от экономики. Если одно решение лучше другого по какой-нибудь метрике на 5 пунктов, но дороже в 10 раз - что делать? Конечно же, зависит от сценария применения и от задач конкретного учреждения и сферы здравоохранения в целом.
  • Техподдержка, мониторинг ошибок и обновления - это тема для отдельного обсуждения, но ИИ-системы могут падать. Фейлятся громко (падают сервера, вылетают ошибки в API) и тихо (например, при изменениях данных или просто на сложных случаях). А это значит, что их нужно мониторить, чинить и по возможности обновлять. Как выстроена система мониторинга, входят ли в стоимость обновления? Всё это стоит узнать заранее.
  • Прозрачность - в России эта тема обсуждается разве что на заседаниях комитетов по этике, но вообще ИИ-системы действительно теоретически и практически способны дискриминировать разные группы населения. Особенно важно это для сценариев автоматизации и триажа.
  • Отношения с вендором - звучит не очень справедливо и монополистично, но если вы уже пользуетесь какой-то ИИ-системой одного производителя, то часто проще и дешевле для вас будет купить и другие системы у него же. Уже есть доверительные отношения, налажена коммуникация, отточено техническое взаимодействие.

Подведём итоги

Итак, что нужно сделать, чтобы не ошибиться при выборе ИИ-системы?

  • Ясно понимать, зачем мы хотим её купить и внедрить, а также как мы будем её использовать
  • Хорошей идеей будет обратиться к экспертам в отрасли или регуляторе, чтобы правильно организовать процесс тестирования и выбрать нужные критерии и данные
  • Брать чужое ТЗ и копировать все критерии - плохая идея. Проводить всевозможные тесты - плохая идея. Формировать набор критериев и тестов под свой случай - хорошая идея
  • Смотреть на чужой опыт - это полезно, но ИИ-система, умеренно себя показавшая в одном случае, может быть идеально подходящей для вашего случая. Но если ИИ-система где-то провалилась с треском - это обычно не очень хороший знак.
Евгений Никитин
Технический директор Цельс
22
Начать дискуссию