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

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

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

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

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

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

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

Обсудим:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Плюсы:

Минусы:

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

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

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

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

Плюсы:

Минусы:

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

Плюсы:

Минусы:

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

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

Плюсы:

Минусы:

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

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

Плюсы:

Минусы:

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

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

Плюсы:

Минусы:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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