Как ИИ проверяет более 400 медицинских карт в день и снижает риски для клиники

ИИ на страже медицинской документации

Текущий статус проекта

Прототипирование, архитектура и выбор модели

Что такое ЭМК

РУБЛЕЙ

156

Почему ручная проверка неэффективна

Проверка электронных медицинских карт перед отправкой в ЕГИСЗ

Сбор требований и формирование критериев проверки

Первый прототип и выбор модели: проверка на базе знаний LLM

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

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

Медицинские карты в JSON-формате поступали из 1С и передавались модели со сложным системным промптом. Модель должна была оценить карту по нескольким критериям: ошибки заполнения, согласованность данных с диагнозом, качество рекомендаций по лечению и общая логика врачебной записи. Оценка выставлялась по шкале от 0 до 5.

На этом этапе также сравнивались разные модели по качеству ответов на медицинские вопросы и способности анализировать структуру карты.

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

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

Разделение проверки на этапы

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

1. Формальная проверка
На первом этапе LLM получает инструкцию проверить карту на соответствие установленным правилам.
Массив правил подготовлен на основе нормативных документов, включая 274н, 203н, 211н и Федеральный закон № 323-ФЗ. При этом правила фильтруются в зависимости от типа приёма: первичный, вторичный, профилактический или универсальный.
Такой подход позволяет учитывать контекст медицинской карты. Например, требования к первичному приёму и повторному визиту могут различаться, и система должна оценивать карту с учётом этого различия.

2. Проверка по клиническим рекомендациям
Если для указанного кода МКБ-10 доступны клинические рекомендации, система запускает дополнительный этап содержательной проверки.

Он включает несколько направлений:
2.1. Проверка анамнеза
Система анализирует, насколько полно и логично описан анамнез, соответствует ли он диагнозу и содержит ли данные, необходимые для клинического обоснования.
2.2. Проверка осмотра
На этом этапе оценивается наличие и полнота данных объективного осмотра. Система сопоставляет описание осмотра с требованиями и рекомендациями, релевантными конкретному заболеванию.
2.3. Проверка лечения
Система анализирует назначения и рекомендации врача, сопоставляя их с клиническими рекомендациями и выявляя возможные несоответствия.

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

На данный момент проект находится на этапе тестирования и доработки.

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

Уже на текущем этапе система демонстрирует потенциал как инструмент внутреннего контроля качества медицинской документации. Она позволяет регулярно анализировать большой объём ЭМК, выявлять типовые ошибки, снижать нагрузку на экспертов и повышать прозрачность процесса.

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

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

Отдельное внимание было уделено безопасности данных. Медицинские карты передаются на проверку без персональных данных пациентов. ИИ анализирует только медицинское содержание документации, необходимое для оценки качества заполнения ЭМК. Такой подход позволяет соблюдать требования по защите персональных данных и одновременно выполнять содержательную проверку карт.

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

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

На первом этапе необходимо было определить:

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

РУБЛЕЙ

20

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

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

Ручной контроль в такой ситуации сталкивается с несколькими ограничениями:

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

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

Корректное ведение электронной медицинской карты является обязанностью медицинской организации. Это следует из Федерального закона № 323-ФЗ «Об основах охраны здоровья граждан в Российской Федерации», а также из профильных приказов Минздрава, регулирующих ведение медицинской документации в электронном виде.

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

Ошибки в карте могут проявляться по-разному. Врач может некорректно указать код МКБ-10, неполно описать анамнез, сформулировать диагноз без достаточного обоснования или не отразить важные элементы осмотра. Формально карта может быть заполнена, но с медицинской, юридической и управленческой точки зрения содержать существенные пробелы.
Именно поэтому автоматизация проверки ЭМК становится для клиники не дополнительной опцией, а элементом системы внутреннего контроля качества.

ЭМК — это официальный медицинский документ. В ней фиксируется ход лечения, жалобы пациента, анамнез, диагноз, назначения, рекомендации врача и другая значимая информация. Именно на основании медицинской карты можно подтвердить действия специалиста, обеспечить преемственность между врачами и передать необходимые сведения в ЕГИСЗ.

В одном из крупных медицинских центров возникла задача, напрямую связанная с выполнением требований Минздрава: обеспечить ежедневную проверку более 200 электронных медицинских карт (ЭМК) перед передачей данных в ЕГИСЗ.

Для медицинской организации ЭМК — это не просто внутренняя запись врача, а официальный документ, который участвует в государственном медицинском документообороте. При большом потоке пациентов клиника ежедневно формирует сотни карт, и вручную проверить каждую из них до отправки невозможно. В результате часть данных передаётся в ЕГИСЗ без полноценной предварительной валидации — фактически «вслепую».

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

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

Текущая архитектура и новая модель

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

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

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

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

Reverse HyDE и гибридный поиск

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

• фактический запрос;
• запрос на ограничения;
• запрос на рекомендации.

Это позволяет искать информацию с разных смысловых ракурсов и повышает вероятность нахождения релевантного фрагмента при анализе медицинской карты.

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

Второй прототип: подключение RAG-системы

Во втором прототипе была внедрена RAG-система с клиническими рекомендациями Минздрава РФ.
По коду МКБ-10, указанному в диагнозе, система выбирала соответствующий документ из подготовленной базы и передавала релевантные фрагменты модели.
Этот подход повысил качество проверки: модель начала опираться не только на внутренние знания, но и на документы, релевантные конкретному диагнозу.

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

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

ЭКНОНОМИЯ

8х

МИНУТ

10

ЭМК

1000

ТЫСЯЧ РУБЛЕЙ

156

Оставьте заявку на интеграцию, и мы свяжемся с вами в ближайшее время