Система сповіщення про сепсис від Epic провалила перевірку у 2021 році в Michigan Medicine, пропустивши дві третини пацієнтів, у яких згодом розвинувся сепсис, водночас активуючи тривогу для 18% усіх госпіталізацій. Ця помилка стала наслідком класичного витоку даних: модель врахувала призначення антибіотиків лікарем — що вже є ознакою підозри на інфекцію — як прогностичний фактор, фактично дублюючи рішення, яке клініцист уже прийняв.

Чому модель не спрацювала

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

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

Ширша проблема ШІ в лікарнях

Модель сепсису від Epic впроваджувалася в сотнях лікарень протягом років, проте помилка витоку даних залишалася прихованою, поки цілеспрямована перевірка не виявила її. Цей випадок ілюструє системну слабкість: більшості проєктів ШІ в системах охорони здоров'я бракує операційних перевірок, необхідних для раннього виявлення таких проблем.

  • Відсутність зовнішнього тестування – лікарні не проводили зовнішнього тестування.
  • Відсутність постійного моніторингу – вони не здійснювали моніторинг.
  • Відсутність чіткої відповідальності – без призначеної команди, відповідальної за якість даних і роботу моделі, проблеми залишаються без уваги.

Ці прогалини тримають багато ініціатив у сфері ШІ в «пастці пілотних проєктів», не дозволяючи їм вийти за межі етапу перевірки концепції.

Прихована ціна фрагментованих даних

Випадок із сепсисом також демонструє, як фрагментовані екосистеми медичних ІТ саботують роботу ШІ. Поширені перешкоди включають:

  • Медичні записи, заблоковані у застарілих модулях EHR, які не обмінюються даними автоматично.
  • Системи візуалізації та лабораторні системи, які не можуть взаємодіяти між собою, що змушує здійснювати ручне перенесення файлів.
  • Дубльовані ідентифікатори пацієнтів, які розділяють дані однієї людини між кількома картками.
  • Клінічні нотатки та життєво важливі показники, що зберігаються в ізольованих сховищах і ніколи не об'єднуються для навчання моделі.

Коли модель навчається на чистому, кураторському наборі даних, а потім отримує реальні, «брудні» дані, її продуктивність непомітно знижується. Клініцисти швидко втрачають довіру; медсестра, якій доводиться перевіряти сповіщення на кількох екранах, ігноруватиме їх, навіть якщо базовий алгоритм технічно правильний.

Чотири «нудні» основи для надійного ШІ

Функціональне впровадження ШІ тримається на чотирьох практичних можливостях, які рідко потрапляють у заголовки новин:

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

Пропуск будь-якого з цих кроків робить проєкт вразливим до такого типу прихованого збою, як у моделі сепсису від Epic.

Питання, які варто поставити перед купівлею ШІ-рішення

Лікарні можуть уникнути дорогих помилок, вимагаючи конкретних відповідей:

  • Чи можете ви відстежити дані одного пацієнта в кожній системі, яку використовуватиме модель?
  • Хто саме (ім'я) відповідає за підтримку якості даних і нагляд за роботою моделі?
  • Чи тестувалися сповіщення з клініцистами під час реальної зміни, а не лише в тестовому середовищі («пісочниці»)?
  • Чи існує задокументований план моніторингу, який визначає, як виявлятиметься та усуватиметься дрейф продуктивності?

Якщо постачальник не може вказати на конкретну особу, процес або панель моніторингу, організації варто зупинитися і переглянути рішення.

Висновок

Модель сепсису від Epic провалилася не тому, що машинне навчання непридатне для лікарень; вона провалилася через відсутність навколишніх конвеєрів даних та структур управління. Модель, яка передбачає рішення самого лікаря, слугує сигналом про те, що доопрацювання потребує саме рівень інженерії даних, а не алгоритм. Побудова надійного ШІ в охороні здоров'я потребує тієї самої «нудної» інфраструктури, яка забезпечує роботу будь-якої критично важливої ІТ-системи: чистих і пов'язаних даних, чіткої підзвітності, сповіщень, інтегрованих у робочий процес, та проактивного моніторингу. Без цього навіть найдосконаліша модель зрештою лише видаватиме хибні попередження не тим людям.