AI-система кодирования диагнозов МКБ-10: архитектура и точность 92-96%

Разбор медицинских записей вручную отнимает время и всё равно даёт расхождения в кодах. Мы разрабатываем и настраиваем под ключ систему автоматического кодирования диагнозов: правила, обучение на вашей разметке, контроль спорных записей. Решение сокращает время разбора и удерживает точность на уровне 92-96%.
Часто задаваемые вопросы

Автоматическое кодирование диагнозов: где теряется точность

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

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

Узкое место разметки — пропускная способность. Чтобы код стал воспроизводимым, запись нужно нормализовать: развернуть аббревиатуры, отделить контекст отрицания («исключён», «под вопросом», «в анамнезе») от утверждения, развести основное заболевание и фон. На потоке это часы монотонного чтения, и внимание проседает тем сильнее, чем ближе конец смены: расхождения растут, а вместе с ними растёт объём ручных возвратов на перекодировку.

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

Что даёт решение: скорость разбора, точность, спорные записи

Контур работает не как «угадай код по строке», а как конвейер: нормализация текста записи, выделение клинических сущностей, сопоставление с рубриками МКБ-10, ранжирование кодов-кандидатов по уверенности. Код выше порога уходит в автоподтверждение, ниже — в очередь на ручной разбор. На непрерывном потоке это даёт разбор записей в 4-6 раз быстрее ручного ввода.

Точность на автоподтверждённых кодах — 92-96% совпадений с заключением кодировщика на отложенной выборке. Остаток приходится в основном на составные диагнозы: основное заболевание плюс сопутствующие, коды с дополнительной характеризующей, случаи, где формулировка менялась по ходу лечения. Там одиночный код неполон, поэтому система возвращает набор кодов и указывает, какой фрагмент записи подтверждает каждый.

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

Режимы работы: правила, обучение на разметке, гибрид

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

Как выбирать режим

Режим Когда подходит Ограничения
Правила и словарь синонимов диагнозов Однородный поток, узкий профиль отделения, требование объяснить каждый код Не покрывает формулировки вне словаря, расширение словаря — ручная работа, ложные срабатывания на омонимах
Обучение на разметке Разные формулировки, есть архив с подтверждёнными кодами Нужен объём разметки, чувствительно к смене редакции классификатора, решение трудно объяснить врачу
Гибридный режим Смешанные источники, нужна высокая точность при умеренной ручной работе Два контура в сопровождении, расхождения между ними приходится разбирать отдельно

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

Этапы внедрения: от аудита записей до передачи

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

  1. Аудит медицинских записей. Берём обезличенный срез за период и смотрим, в каком виде приходит диагноз: свободный текст, сокращения, уже проставленные коды. На выходе — карта качества данных и перечень классов, которые система обязана различать.

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

  3. Настройка правил. Собираем справочники синонимов и сокращений, правила приоритета между близкими кодами, обязательные уточняющие признаки. Это фиксирует то, что врач применяет автоматически, и снимает часть расхождений до модели.

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

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

  6. Передача в эксплуатацию. Передаём регламент разбора ошибок, мониторинг качества и порядок дообучения, обучаем сотрудников, остаёмся на сопровождении.

Каждый этап закрывается артефактом — картой данных, схемой, набором правил, отчётом по метрикам, — который заказчик принимает и проверяет.

Комплект передачи: правила, справочники, регламенты контроля

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

  • Набор правил кодирования. Как выбирать основной диагноз, как кодировать сопутствующие состояния и осложнения, что делать с неуточнёнными формулировками. Правила задают порядок приоритетов и явно перечисляют случаи, где система обязана передать решение человеку.
  • Справочник соответствий. Таблица между формулировками врачей и кодами МКБ-10: синонимы, сокращения, типичные опечатки, примеры из вашей практики. Ведётся по версиям — видно, что и когда изменилось.
  • Регламент контроля качества. Какая доля случаев идёт на выборочную проверку, как разбираются расхождения, при каком падении точности запускается пересмотр правил.
  • Инструкции для кодировщиков. Что делать, когда система отдаёт два близких варианта, как оформлять спорный случай и куда его направлять.
  • Схема интеграции. Точки, где код попадает в учётную систему, где врач подтверждает или меняет результат, какие данные передаются и в каком виде.
  • Порядок обновления. Кто вносит новые формулировки в справочник, кто утверждает правки в правилах и как проверяется, что обновление не сломало уже работающие случаи.

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

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

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

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

Метрики до и после считали на одном и том же потоке. Точность выросла до 92–96% в зависимости от профиля отделения, доля ручных правок сократилась примерно втрое, класс ошибок «код не подтверждается текстом» практически ушёл. Контроль на отложенной выборке — записи, не участвовавшие ни в настройке правил, ни в правках справочника: разрыв с рабочей выборкой не превышает двух пунктов, значит рост не подгонка под конкретные примеры.

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

Что делать, если часть диагнозов уходит на ручную доработку?

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

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

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

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

Частые вопросы: данные, интеграция, контроль качества

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

Как это встроить в существующую медицинскую систему?

Ядро учётной системы не меняем: на вход подаётся текст заключения, на выход система возвращает код МКБ-10 с уверенностью и ссылкой на фрагмент, который на неё повлиял. Врач видит подсказку в рабочем окне и подтверждает или правит её — выкатывать можно постепенно, с одного отделения.

Как защищены персональные данные?

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

Что происходит при обновлении справочника МКБ?

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

Как проверяете качество разметки?

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

Обсудим задачу и вернёмся с оценкой и планом работ

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

Что прислать для старта:

  • 200–500 обезличенных записей с текстом диагноза — и, если есть, с уже проставленным кодом;
  • справочник кодов, по которому вы работаете: полный МКБ-10, региональный или внутренний;
  • 10–15 спорных случаев, где кодировщики расходились во мнениях;
  • структуру полей записи: что врач заполняет обязательно, а что свободным текстом;
  • требования к контуру обработки — можно ли выходить во внешнюю сеть и как хранятся данные;
  • целевой показатель: какую долю записей допустимо отправлять на ручную проверку.

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

Направления AI-разработки

Последние работы

  • Разработка сайта компании B2B ADVANCE
    Разработка сайта компании B2B ADVANCE
    1542
  • Разработка веб-приложения для компании FEEDME
    Разработка веб-приложения для компании FEEDME
    1394
  • Разработка веб-сайта для компании БЕЛФИНГРУПП
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    1081
  • Разработка интернет магазина для компании FURNORO
    Разработка интернет магазина для компании FURNORO
    1369
  • Разработка логотипа компании B2B Advance
    Разработка логотипа компании B2B Advance
    816
  • Разработка веб-приложения для компании Enviok
    Разработка веб-приложения для компании Enviok
    1142