Система оповещения о сепсисе от Epic провалила валидацию в 2021 году в Michigan Medicine, пропустив две трети пациентов, у которых позже развился сепсис, и при этом подавая сигнал тревоги в 18% всех случаев госпитализации. Эта ошибка восходит к классической проблеме «утечки данных» (data leakage): модель учитывала назначение врачом антибиотиков — что само по себе является признаком подозрения на инфекцию — как предиктор, по сути, просто дублируя решение, которое клиницист уже принял.

Почему модель не справилась

Команда из Мичигана проанализировала 38 455 случаев госпитализации — объем, типичный для многолетнего проекта по повышению качества медицинской помощи. Внутренние тесты Epic обещали высокую точность, но независимая проверка показала обратное. Оповещения системы о «высоком риске» срабатывали почти у каждого пятого пациента, однако две трети реальных случаев сепсиса остались незамеченными. На практике система слишком часто кричала «внимание», пропуская именно те события, для обнаружения которых она и предназначалась.

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

Более широкая проблема больничного ИИ

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

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

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

Скрытая цена фрагментированных данных

Случай с сепсисом также показывает, как фрагментированные ИТ-экосистемы здравоохранения саботируют работу ИИ. К распространенным препятствиям относятся:

  • Записи пациентов, заблокированные в устаревших модулях EHR, которые не обмениваются данными автоматически.
  • Системы визуализации и лабораторные системы, которые не могут «общаться» друг с другом, что вынуждает переносить файлы вручную.
  • Дублирующиеся идентификаторы пациентов, из-за которых данные одного человека распределяются по нескольким картам.
  • Клинические заметки и показатели жизненно важных функций, хранящиеся в разрозненных сегментах и никогда не объединяемые для обучения моделей.

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

Четыре «скучных» столпа надежного ИИ

Функциональное внедрение ИИ опирается на четыре практические возможности, которые редко попадают в заголовки новостей:

  1. Интероперабельность — данные должны беспрепятственно передаваться между EHR, лабораториями, платформами визуализации и инструментами поддержки принятия решений без ручного экспорта и импорта.
  2. Управление (Governance) — ответственное лицо или команда должны отвечать за качество данных и отслеживать результаты работы модели с течением времени.
  3. Интеграция в рабочий процесс — оповещения должны появляться в существующей рабочей очереди врача; лишние клики или дополнительные экраны сводят на нет эффективность внедрения.
  4. Масштабируемые операции — автоматизированный мониторинг, анализ усталости от оповещений и конвейеры периодического переобучения модели необходимы еще до того, как модель будет запущена в промышленную эксплуатацию.

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

Вопросы, которые стоит задать перед покупкой ИИ-решения

Больницы могут избежать дорогостоящих ошибок, требуя конкретных ответов:

  • Можете ли вы отследить данные одного пациента во всех системах, которые будет использовать модель?
  • Кто именно (по имени) несет ответственность за поддержание качества данных и контроль работы модели?
  • Тестировались ли оповещения на врачах во время реальной смены, а не только в тестовой среде («песочнице»)?
  • Существует ли документированный план мониторинга, в котором указано, как будет выявляться и устраняться дрейф показателей эффективности?

Если поставщик не может указать на конкретного человека, процесс или панель мониторинга, организации следует сделать паузу и пересмотреть решение.

Основной вывод

Модель Epic для прогнозирования сепсиса потерпела неудачу не потому, что машинное обучение непригодно для больниц, а потому, что отсутствовали сопутствующие конвейеры данных и структуры управления ими. Модель, которая лишь предсказывает решения самого врача, служит предупреждением: доработки требует не алгоритм, а уровень инженерии данных. Создание надежного ИИ в здравоохранении требует той же «скучной» инфраструктуры, которая обеспечивает работу любой критически важной ИТ-системы: чистых и связанных данных, четкой подотчетности, интегрированных в рабочий процесс оповещений и проактивного мониторинга. Без этого даже самая совершенная модель в итоге будет посылать неверные предупреждения не тем людям.