Как НМИЦК им. Е.И. Чазова отслеживает риски сердечно‑сосудистых заболеваний: от ручной работы к инструменту на базе ИИ

Острый коронарный синдром (ОКС) — наиболее рисковая форма ишемической болезни сердца. Пациенты, которые перенесли ОКС, попадают в группу крайне высокого риска последующих сердечно‑сосудистых осложнений. Смертность в этой категории больных составляет до 20% в течение 4 лет.

НМИЦ кардиологии им. ак. Е. И. Чазова Минздрава России при поддержке Центра технологий для общества Yandex Cloud запустил цифровой регистр пациентов, перенёсших ОКС. Для решения этой задачи мы обеспечили безопасную обработку более 13 тыс. медицинских документов с помощью больших языковых моделей и дали кардиологам максимум информации для исследований, мониторинга и предотвращения риска. 

Меня зовут Евгений Попов, в Yandex Cloud я руковожу проектами по направлению «Медицина». Сегодня я расскажу об этапах разработки решения и остановлюсь подробнее на нетривиальной задаче обезличивания данных.

В чём проблема и как она решалась раньше

Идея решения родилась во время совместной работы команды Центра технологий для общества со специалистами ФГБУ «НМИЦК им. Ак. Е. И. Чазова» Минздрава России и Мастерской Яндекс Практикума. Кардиологи обратились к нам за помощью с созданием прогнозной модели для предсказания рисков ОКС. А для решения этой задачи с помощью ИИ нам было важно понять, как устроены сбор и аналитика данных, и что представляют из себя сами данные.

К началу проекта большинство информации о пациентах с ОКС хранилось в сыром неструктурированном виде в медицинских документах. В частности, большое количество важных для прогноза данных можно найти в выписном эпикризе — это неструктурированный документ на 3–6 страниц текста. В нём содержится как анамнез жизни, так и специфическая медицинская информация: данные общего осмотра, результаты инструментальных и лабораторных обследований, сведения об оперативном и фармакологическом лечении.

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

В каких сценариях используется регистр: 

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

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

3. Сбор медицинской статистики и исследование лечения ОКС. Как правило, исследователи используют методы регрессионного анализа, где в качестве независимых переменных могут выступать факт отправки в диспансер, или льготное лекарственное обеспечение, его продолжительность. Эта информация помогает специалистам НМИЦК им. Ак. Е. И. Чазова сравнивать регионы и выстраивать всю стратегию работы с кардиологическими заболеваниями в каждом регионе и по всей России.

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

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

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

Соответственно, мы переформулировали задачу: первоочередным стало создание цифрового регистра пациентов с автоматическим заполнением данных. А в качестве пилотного региона для первого этапа проекта выбрали Тульскую область, где есть хорошо подготовленная региональная кардиологическая служба и накоплен большой объём данных по ОКС — более 13 тыс. документов из сосудистых центров за 2021–2025 годы. 

Что нужно для автоматической обработки данных с учётом разных сценариев

Для создания цифрового регистра нужно было реализовать три шага: 

1. Обезличивание. Поскольку первичные документы содержат множество чувствительных данных, перед машинной обработкой их важно обезличить: сделать невозможным определение, кому именно они принадлежат.

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

3. Сборка регистра, доступ к которому предоставляется гранулярно:

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

• Агрегированная статистика для исследований очищена от ПДн. В ней специалисты НМИЦК им. Ак. Е. И. Чазова решают исследовательские задачи и проводят дальнейший анализ. 

Обезличивание данных требует особого внимания с точки зрения ИБ, поэтому сегодня остановлюсь на нём подробнее.

Как можно обезличить данные 

Методы обезличивания перечислены в приказе РКН № 140, всего есть пять методов. Их можно использовать как отдельно, так и в комбинации.

1. Введение идентификаторов вместо исходных сведений. 

2. Изменение состава или семантики данных (удаление, искажение, изменение).

3. Перемешивание данных. 

4. Декомпозиция массива данных на части. 

5. Обобщение атрибутов.

Команда Центра технологий для общества использовала методы № 1 и 2, которые относятся к отдельным документам, а не массивам данных. Введение идентификаторов позволяет связывать документы, относящиеся к одному и тому же субъекту ПДн, и обеспечивает консистентность при повторной обработке документов. А вот что представляют собой разные способы изменения состава данных для обезличивания:

• Удаление — говорит само за себя. Подходит, когда информация не нужна для дальнейшей работы.

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

  Адрес: отбрасывание данных после региона или города. Так мы сможем анализировать информацию по региональной специфике какого‑либо заболевания.

  ФИО: сохранение только первых букв имени и фамилии.

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

  Возраст:

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

  • Добавление детерминированного шума на основе криптографических преобразований.

На основе этих способов можно также создавать и уникальные идентификаторы: УИН или UID — чуть ниже покажу, как именно.

Как это реализовано у нас 

Заранее определить, какой метод обезличивания подойдёт для разных случаев невозможно — всё зависит от контекста и решаемых задач. Поэтому в проекте было важно предоставить инструменты, которыми будет удобно пользоваться сотруднику медицинского учреждения без глубоких технических знаний, в режиме no‑code. 

В нашем решении конкретные реализации методов обезличивания нашли своё воплощение в виде преднастроенных базовых стратегий — технически это JSON‑ и Python‑файлы, реализующие определённую функцию преобразования. Разработали их на основе уже накопленного опыта работы с ПДн. Также сделали понятный гайд для разработчиков, чтобы можно было создавать новые стратегии.

Для пользователя сделали возможность создавать кастомные LLM‑стратегии, которые в целом неплохо справляются с несложными задачами, такими как «оставить только город из адреса» или «оставить из даты только год». Единственное важное замечание: такие стратегии нужно тщательно тестировать перед применением.

Затем это позволяет создать схему документа, где пользователь описывает тип документа, какие поля в нём есть, какие данные в них как искать, а также по какой стратегии и что обезличивать. Схема тоже представляет собой JSON‑файл, который затем подаётся на вход LLM для детализации промпта.

Помимо этого данные важно валидировать, то есть проверить на соответствие формату. Параметры валидации документа также представляют собой JSON‑ и Python‑файлы.

И уже затем для обработки данных на базе больших языковых моделей используются YandexGPT Lite и Alice AI LLM, доступные в рамках платформы Yandex AI Studio. 

Схема пайплайна обработки документов

Решение работает как конструктор и подходит для любых документов с данными: например, это может быть выписной эпикриз, протокол осмотра или вообще любой документ. Как строится обработка:

1. В конструкторе задаётся схема документа:

   

2. Файлы загружаются в систему и после загрузки конвертируются в Markdown, так как этот формат является нативным для LLM.

   

3. Для каждого файла выбирается схема и затем запускается обработка. 

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

   Также, если инсталляция LLM сильно нагружена, есть настройки ретраев и таймаутов. Чтобы LLM всегда выдавала предсказуемый результат используется structured outputs — модель вернёт ответ ровно в заданной схеме JSON. В результате система извлекает ПДн, генерирует UID, применяет стратегии обезличивания и сохраняет результаты:

   

Сам обезличенный документ выглядит так:

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

Допустим, возраст 63 года и стратегия «Удалить». Получается нужно удалить все вхождения цифры 63 из документа? А ведь она может встречаться в разных местах, например в лабораторных показателях.

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

Уже после обезличивания из очищенных текстов извлекается более 90 параметров, необходимых для наблюдения за пациентами с ОКС, в том числе диагноз, сопутствующие заболевания, результаты обследований, данные осмотров и информация об оперативном и фармакологическом лечении. Затем эти данные передаются в аналитическую систему для мониторинга и визуализации (но об этом подробнее в следующий раз).

По умолчанию решение работает как no‑code‑приложение, с которым могут работать специалисты в медицинских организациях. Однако при желании разработчики могут добавлять свои стратегии валидации и обезличивания документов: для этого необходимо создать дополнительные Python‑ и JSON‑файлы и разместить их в соответствующие папки.

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

Подробнее про использование секретного ингредиента — соли

Для искажения данных. Если сдвиг числовых диапазонов или процентное изменение — довольно простые механизмы обезличивания данных, то криптографические преобразования требуют отдельного пояснения. Неспециалистам мы обычно объясняем стратегию детерминированного шума через метафору особого рецепта от шеф‑повара: такая стратегия как рецепт с секретным ингредиентом (солью), которое делает блюдо уникальным, и его нельзя повторить без знания секрета.

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

Разберём устройство стратегии на конкретном примере: берём возраст пациента и добавляем в него шум, подсчитанный на основе соли (s). 

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

При необходимости параметры преобразования в такой стратегии можно редактировать: 

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

Для создания идентификаторов. Эта же стратегия полезна, если нам нужно, чтобы процесс расчёта идентификаторов для пациента был детерминирован. Это даёт возможность после анонимизации соотносить документы, относящиеся к одному субъекту, благодаря назначению уникального идентификатора (УИН или UID). Однако важно, чтобы методология расчёта UID не была получена хардкодингом, что, остаётся небезопасным. 

Предположим, что хеш‑функция считается по ФИО и дате рождения. Берутся две строки, на основе которых считается хеш. В хеш‑функции 256-битный ключ. Из хеша берем первые 16 значений, которые становятся идентификатором. 

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

В решении есть два уровня идентификаторов: А и Б. 

• Уровень А предназначен для случаев, когда в документе есть номера документов: например, СНИЛС, номер страхового полиса, номер паспорта. В этом случае при расчёте идентификатора используются эти номера. 

• Уровень Б рассчитывается, если в документе нет указаний на номера документов, а есть только ФИО и дата рождения. 

Оба идентификатора помогают сопоставить документы и объединять их в группы после обезличивания. Для записей уровня Б система дополнительно вычисляет список «похожих» UID — которые могут относиться к тому же субъекту, но с частичными данными. Это помогает находить дубли, например опечатки или ошибочно внесенные данные.

На основе UID создаётся база, которая позволяет склеить все данные в регистр на третьем этапе. Представление данных в базе UID возможно как в табличной форме, так и в виде графа:

В таком представлении тоже удобно видеть возможные дубли и количество документов по отдельному пациенту. Такие случаи сразу хорошо видны на графе по форме кластера, например одному UID А‑уровня соответствует 2 UID Б‑уровня.

Как измерить качество

Важный вопрос — как проверить качество обезличивания документов? В данном контексте нам не подойдут вероятностные метрики, которые покажут качество работы даже на уровне 99% — тогда у нас остаётся один процент вероятности, что есть неверно обработанные персональные данные. Чтобы получить 100%, мы действовали вместе с кардиологами в несколько этапов:

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

2. Затем мы отправились в регион и консультировали региональных специалистов, как донастраивать эту схему на десятках настоящих документов. Промпты дотюнивались, чтобы добиться качества 100% по выписному эпикризу.

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

Только на эти три пункта потребовалось несколько месяцев.

И уже затем эту схему протестировали на примерно 13 тыс. медицинских документов из сосудистых центров Тульской области. Случайную долю в 10% также валидировали глазами и убеждались в отсутствии пропусков. И только затем на этом массиве данных команда была готова сформировать первый регистр, с которым могут работать кардиологи‑исследователи.

Результаты проекта и дальнейшие планы

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

При обработке в несколько потоков обезличивание одного документа с 12 полями занимает примерно 1,5 сек. Для извлечения 93 полей, в среднем, уходит 7 секунд на документ. Человеку понадобилось бы минут 40. При этом LLM не устаёт и может обрабатывать неограниченное количество документов.

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

В долгосрочной перспективе это позволит делать обоснованные прогнозы, влиять на региональные и федеральные программы помощи при ОКС и в дальнейшем снижать риск неблагоприятных исходов: с текущих 20% до целевых 10%. Многие факторы требуют длительного наблюдения, например, количество лет без сердечно‑сосудистых заболеваний. Регулярное ведение регистра позволит увидеть, как на такие показатели влияют разные меры, скажем, программы льготного лекарственного обеспечения. 

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

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

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