Хабрахабр

Как мы искали признаки врачебных ошибок

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

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

Массачусетский Institute for Healthcare Improvement (IHI) разработал методику IHI Global Trigger Tool for Measuring Adverse Events, которую затем внедрили передовые клиники США и Европы. В США этим вопросом озадачились в начале 2000-х.

Расскажу, что из этого вышло.
В 2016 году мы (российский офис SAS) попытались создать систему анализа медицинских триггеров по методике IHI в России.

С чего начали

Первым делом мы стали искать врачей-единомышленников, разделяющих идею анализа качества медицинского обслуживания. Пригласили на SAS Forum Russia 2016 руководителей нескольких московских стационаров, коллег из нашего европейского офиса и представителей датской больницы Lillebaelt, создавшей на базе аналитической платформы SAS систему выявления триггеров по методике IHI в 2015 году.

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

Костяк команды со стороны SAS состоял из Александра Жукова (al_undefined) и Дмитрия Каютенко. В июне — июле 2016-го мы обсудили с руководством Клиники содержание и рамки проекта, в августе оформили техническое задание и с сентября приступили к работе.

Для проекта вместе с руководством Клиники мы отобрали следующие: Методика IHI содержит 51 триггер.

  • Лейкоциты крови < 3 000 x 10^6 / мкл (кроме пациентов на химиотерапии)
  • Тромбоциты крови < 50 000 × 10^6 / мкл (кроме пациентов на химиотерапии)
  • Внутрибольничный инсульт
  • Внутрибольничный инфаркт
  • Повторные незапланированные переводы в отделение реанимации и интенсивной терапии (ОРИТ) в течение 24 часов
  • Реанимационные мероприятия в течение 24 часов после операции
  • Реанимационные мероприятия в коечных отделениях

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

Как извлекали записи

Данные медицинской информационной системы (МИС) Клиники были размещены в оракловой базе с запутанной структурой. Описания схем найти не удалось, поэтому пришлось восстанавливать структуру данных и связи сущностей, сопоставляя сведения из БД с информацией из графического интерфейса МИС.

Для проекта нам понадобились следующие виды медицинских записей:

  • Данные осмотра врача приемного отделения
  • Таблица диагнозов
  • Дневниковые записи
  • Протоколы операций и предоперационные концепции
  • Назначения и сведения об исполнении назначений
  • Этапные и выписные эпикризы
  • Переводные эпикризы
  • Посмертные эпикризы

Эти данные (кроме таблицы диагнозов), лежали в XML в CLOB-ах. Описания структуры XML в Клинике не было, поэтому их содержание пришлось устанавливать опытным путём в ходе долгих дискуссий.

Например, в узле «Общее состояние» могла находиться информация о жалобах пациента, а сам узел «Жалобы» оставался пустым. Внутри XML-документов был бардак. Часто врачи записывали все данные о пациенте (жалобы, результаты осмотра, рекомендации к дальнейшему лечению и назначения лекарств и др.) в одно поле, например, в «Комментарий».

Наиболее сложные документы, у которых нужные сведения находились на разных уровнях вложенности, разбирали самописным парсером на Python. Развёртку XML в плоские таблицы делали штатным SAS XML Mapper. Он запускался из SAS и был интегрирован в единый исполняемый процесс SAS Enterprise Guide:

Они тоже были завёрнуты в XML, но простого вида — «анализ», «показатель», «значение». Чтобы не вытаскивать результаты лабораторных исследований из текста эпикризов (то ещё удовольствие, учитывая привычку некоторых врачей документировать на скорую руку), мы взяли данные по ним из лабораторной информационной системы (ЛИС).

Как исследовали данные

Когда мы привели медицинские записи в понятный и пригодный для обработки вид, оказалось, что формализованными были только 2 триггера из 7 — содержание «лейкоцитов» и «тромбоцитов». Они выражались числами, которые можно было сравнивать с пороговым значением.

Этот маркер опирается на отметки даты-времени, а их вносили в МИС Клиники как бог на душу положит — могли промахнуться на пару дней или даже поставить дату из будущего. Нам пришлось отказаться от анализа такого триггера, как «Повторные незапланированные переводы в ОРИТ в течение 24 часов».

Их следовало искать в эпикризах и дневниковых записях. Внутрибольничные инсульты, инфаркты и реанимационные мероприятия никак не кодировались и не фиксировались в таблице в привязке к ID пациента. Поэтому оставшиеся 4 триггера были неформализованными, то есть требовали разбора неструктурированного текста.

Это web-based решение с визуальным интерфейсом, позволяющее создавать модели обработки текста даже при отсутствии навыков программирования и познаний в лингвистике (впрочем, без знания предметной области и языка, на котором написан текст, все равно не обойтись). Для этого мы применили инструмент обработки естественного языка (natural language processing) — SAS Contextual Analysis.

Но мы сознательно от них ушли и применили механизм лингвистических правил, потому что: Сейчас подобные вопросы стало модно решать с помощью нейронных сетей.

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

Как обучали систему

Хотя мы занимались всеми триггерами из перечня, основные усилия были сосредоточены на выявлении внутрибольничных инсультов и инфарктов (и то, и другое для краткости будем именовать ВБИ). Это одни из самых опасных триггеров, которые, помимо ущерба здоровью пациентов, ужасны тем, что не афишируются медперсоналом. А если менеджмент не знает о проблеме, он не может с ней справиться.

Не существовало какого-то стандарта или регламента, который обязывал документировать факты инсультов или инфарктов в единообразной форме: одни врачи описывали инсульт как «острое нарушение мозгового кровообращения», другие — как (о, да!) «инсульт», третьи — как «ОНМК». С ВБИ всё было непросто. Иногда ВБИ было видно только по назначенному лечению.

В принципе, мы могли:

  1. Опросить всех врачей, как они описывают инсульты и инфаркты. Однако был риск что-то упустить — никто не держит в голове перечень сделанных когда-то записей и справочник сокращений. И говорить на эту тему было немного желающих.
  2. Вместе с врачами руками перебрать все эпикризы и проанализировать, есть ли в них признаки ВБИ или нет. Но такого количества времени не было ни у нас, ни у них.

Мы поступили иначе: загрузили коллекцию текстов в Contextual Analysis и построили тематические модели, которые для каждой записи выделяли ключевые идеи. Не залезая в текст документа (например, эпикриза), можно было отобрать только записи с темой «инсульт» или «НМК» и отдельно исследовать их на предмет того, как ВБИ описан в тексте: какие слова используются, на каком расстоянии друг от друга они находятся и т. д. Плюс модели сами предлагали возможные формулировки для описания ключевых идей.

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

Так мы искали реанимационные мероприятия:

А так — инсульты:

Вот пример, когда все нужные слова («острое», «нарушение», «мозговое», «кровообращение») во фразе есть, а внутрибольничного инсульта — нет: При анализе текста всегда нужно оценивать расстояние между ключевыми словами и их порядок, чтобы не захватить лишнего.

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

Исключаемое правило «Последствия инсульта» (выше в Remove_item):

Они выгружались из Contextual Analysis в виде скорингового кода, который подключался в исполняемый процесс оценки записей в SAS Enterprise Guide. Вместе с врачами мы разработали порядка 30 лингвистических правил, которые определяли, есть ли признаки триггеров в эпикризах.

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

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

Проверяем диагноз: если пациент поступил с ишемической болезнью сердца, то риск инфаркта миокарда и так был высоким. Допустим, Contextual Analysis присвоил метку «внутрибольничный инфаркт» какой-то записи. Признак триггер записи не присваиваем. Событие это хоть и не благоприятное, но, увы, ожидаемое.

Например, не уследили за давлением или спровоцировали его скачок какими-то препаратами или действиями. Если же пациент поступил с аппендицитом и у него в ходе лечения случился инсульт, то это могла быть врачебная ошибка. Записи присваиваем признак «триггер».

В итоге получился такой бизнес-процесс:

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

Как визуализировали данные

На последнем этапе мы настроили отчёт в SAS Visual Analytics — это наш web-based продукт для задач визуализации и BI. Он обновлялся каждые 5 минут и показывал статистику возникновения триггеров в разрезе отделений, врачей и пациентов. Ответственный врач (например, заведующий отделением кардиологии) заходил в отчёт и смотрел, какие триггеры выявлены за последний час, день, неделю. Мог «провалиться» в отделение, посмотреть динамику триггера за период и т. п.:

Чтобы не грузить статью скриншотами (тем более «замазанными»), мы записали небольшую демонстрацию на деперсонализированных данных:

Ещё мы хотели настроить автоматическую рассылку уведомлений о триггерах — это хороший тон для аналитических систем, отслеживающих критически важные показатели. Тем более что функционал почтовой рассылки встроен в SAS Visual Analytics. Но Клиника не захотела давать доступ к почтовому серверу, также как отказалась от организации СМС-рассылки через сопряжение с внешними сервисами.

Чем все закончилось

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

Важнее всего, что она позволяла: Но повышенная точность — не главное, что давала система выявления триггеров.

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

Важным для успеха проекта была полная поддержка администрации — Главврача, его заместителей и заведующих отделениями. Руководитель Клиники получил образование в США, поэтому идея управления на основе менеджмента качества и автоматизированного анализа данных ему оказалась близка и понятна

Его сменщик был откровенно консервативен и не любил выносить сор из избы. Увы, незадолго до полномасштабного внедрения аналитической системы, Главврач ушел с поста. Клиника списала результаты перспективного проекта «в стол» и вернулась к методам работы, проверенным годами практики.

Но об этом в другой раз. Хотя мало приятного в том, чтобы делать невостребованный продукт, наработки по эксперименту в Клинике нам очень пригодились в следующем проекте по аудиту медкарт в системе ОМС.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть