Почему AI EHR разваливается на живых клинических данных
На тестовом наборе система ведёт себя предсказуемо: поля заполнены, справочники совпадают, модель уверенно размечает диагнозы. На живом потоке это ломается в первые сутки. Внедрение AI EHR упирается не в выбор модели, а в качество клинических данных, которые приходят из десятка источников в разном виде.
Лаборатория отдаёт структурированный ответ по своему каналу, а заключение инструментального исследования приходит сканом с косой строкой и печатью. Распознавание текста заключений на таких сканах путает дозировки, единицы измерения и даты — и дальше это уходит в карту как факт. Свободный текст врача добавляет своё: сокращения, локальные шаблоны отделения, формулировки без даты отсчёта.
Сверху ложатся ошибки ручного ввода на регистратуре: полис, дата рождения, дубли пациентов. Ошибка не остаётся локальной — она рвёт связку эпизодов, история болезни собирается неполно, а правила клинических проверок срабатывают не на тех данных.
Узкое место обработки карт чаще всего не в модели, а на стыках: обрыв интеграции с лабораторией, зависшая очередь сообщений, расхождение справочников услуг. Пока стык не закрыт, качество клинических данных не поднимается никакой дообученной моделью — врачу снова приходится сверять всё руками. Разбираем, как это закрывается.
Что даёт AI EHR в ежедневной практике клиники
В основе AI EHR — распознавание речи и структурирование сказанного по заданному шаблону приёма: жалобы, анамнез, осмотр, назначения. Врач говорит, система раскладывает текст по полям, а не пишет сплошным потоком. Формат хранения выбираем не на глаз: записи ложатся в модель HL7 FHIR — международный стандарт обмена медицинскими данными, поэтому карта стыкуется с лабораторией, аптекой и внешними системами без ручного переноса.
Эффекты снимаем замерами до и после. Доля карт, закрытых без ручного набора, на потоковых приёмах доходит до 70–80%, подготовка записи приёма сокращается с 6–8 минут до 1–2. Возвраты карт на доработку падают в разы — чаще всего их вызывали пропущенные обязательные поля, а не суть записи.
Уходит отдельный класс ошибок ввода: опечатки в дозировках, расхождения между назначением и текстом карты, потерянные строки при копировании прошлого приёма. Целостность держится на проверках при сохранении: доза сверяется с весом, возрастом и сопутствующими назначениями, несовместимые позиции помечаются. Полнота клинической карты перестаёт зависеть от того, насколько уставшим был врач к концу смены.
Нагрузка на врача смещается: он проверяет и подтверждает, а не набирает. Финальное слово остаётся за человеком, любая правка фиксируется в журнале с автором и временем. Дальше разбираем, из чего складывается такая система и как встроить её в текущий контур клиники.
Способы подключения: облако, контур клиники, гибрид
Выбор схемы развёртывания диктует не удобство инфраструктуры, а политика клиники: где разрешена обработка персональных данных и какие каналы наружу вообще открыты. Мы ведём такие согласования вместе с ИТ-службой заказчика, потому что от ответа зависит и архитектура, и регламент эксплуатации.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Облако | Сеть клиник с высокой и неравномерной нагрузкой, нужны внешние расчёты | Медданные вне контура: обязательны договор обработки, шифрование при передаче и хранении, отдельный контроль доступа |
| Контур клиники | Жёсткие требования к хранению персональных данных, изолированная сеть | Нужны собственные вычислительные мощности под модель; обновления ставим в согласованное окно, внешние интеграции — только через согласованный шлюз |
| Гибрид | Обработка текстов внутри клиники, а обмен с лабораторией и тяжёлые расчёты — наружу | Два контура: требуются синхронизация справочников, разграничение ролей и сквозное журналирование запросов |
В гибридной схеме граница проходит по конкретному полю, а не по системе целиком: всё, что содержит идентификаторы пациента, остаётся в контуре, наружу уходит обезличенная задача, а ответ возвращается с привязкой к карте уже на стороне клиники. Обмен с лабораторией строится так же — по результатам и заявкам, без выгрузки полной истории.
Что одинаково важно во всех трёх вариантах: неизменяемый журнал доступа к картам, ключи шифрования остаются у заказчика, а при потере связи система переходит в режим чтения и не теряет уже введённое. Эти проверки мы прогоняем до передачи и фиксируем в регламенте.
Как мы внедряем систему: этапы инженерной работы
Внедрение начинается не с модели, а с данных: пока неясно, как устроены текущие карты и кто их заполняет, автоматизация даёт убедительную демонстрацию и мусор в реальной работе. Поэтому мы идём фиксированной последовательностью, где каждый этап опирается на результат предыдущего и может быть остановлен без потери уже сделанного.
- Аудит медицинских данных — обезличенный срез карт: полнота полей, доля свободного текста, разброс формулировок между врачами и отделениями.
- Схема данных — согласуем структуру записей, справочники и правила нормализации, а также что система заполняет сама, а что остаётся за врачом.
- Схема интеграции — точки обмена с медицинской информационной системой и лабораторией, направление потоков, поведение при недоступности внешнего сервиса.
- Прототип на архиве — прогоняем распознавание и извлечение сущностей на исторических записях, чтобы увидеть ошибки до клиники, а не внутри неё.
- Пилот на отделении — система идёт «в тени»: врачи ведут карты как обычно, её подсказки сверяются с итоговыми записями.
- Проверка качества распознавания — точность и полнота по размеченной выборке, отдельно критичные классы ошибок: дозировки, аллергии, диагнозы.
- Передача в эксплуатацию — регламенты, роли и права доступа, журналирование действий, инструкции для врачей и службы поддержки.
Критерии приёмки и набор размеченных примеров фиксируем до старта пилота — иначе спор о качестве сводится к вкусовым оценкам и проект уходит в бесконечную доработку.
Что передаём клинике: конфигурации, схемы, регламенты
Проект считается сданным не тогда, когда модель уверенно отвечает на демонстрационном запросе, а когда клиника эксплуатирует систему без нас. Поэтому в приёмку входит пакет артефактов, по которым дежурный инженер и заведующий отделением сами разворачивают, проверяют и сопровождают решение.
- Конфигурации развёртывания — декларативные манифесты для тестового и рабочего контуров: параметры подключения к хранилищу карт, лимиты нагрузки, политика повторных попыток при сбое внешнего сервиса. Контур поднимается одной командой, расхождение между средами исключено.
- Схема потоков данных — путь записи от рабочего места врача через слой интеграции к модели и обратно, с явной отметкой, где обезличиваются персональные данные, что оседает в журнале аудита и какие поля наружу не уходят.
- Матрица доступа к данным — таблица «роль / набор полей / допустимое действие» для врача, медсестры, регистратуры, администратора и сервисного инженера. Отдельно зафиксированы запреты на массовую выгрузку и порядок выдачи временных доступов.
- Документация по внедрению — пошаговый порядок развёртывания, миграции справочников и контрольные проверки после каждого шага: как убедиться, что справочник сошёлся, а старые записи читаются корректно.
- Инструкции для персонала — сценарии на одну-две страницы: как принять подсказку, как отклонить, как сообщить об ошибке. Для врачей и для службы поддержки — разные версии, без технических подробностей.
- Регламент сопровождения — какие метрики качества и задержек смотрят ежедневно, при каких порогах срабатывает оповещение, кто и в какой срок реагирует, как откатывается обновление модели.
- Набор приёмочных сценариев — фиксированный список проверок на реальных обезличенных картах, по которому клиника сама подтверждает работоспособность после каждого обновления.
Кейс: как сократили ручной ввод в приёмном отделении
Приёмное отделение клиники работало в привычном режиме: врач надиктовывал или печатал карту после осмотра, регистратура вносила данные повторно, часть сведений оседала в текстовых заметках. На оформление одной карты уходило 11–13 минут, обязательные поля были заполнены в 68% карт, и только 62% из них закрывались в день приёма.
Что перестроили в потоке данных
Мы поставили распознавание речи с медицинским словарём и привязкой к структуре карты: сказанное на приёме раскладывается по полям — жалобы, анамнез, осмотр, назначения. Справочник препаратов подсказывает формулировки дозировок, а проверка на противоречия не даёт подписать карту, если назначение конфликтует с аллергиями. Черновик готов к концу осмотра, врачу остаётся подтвердить и поправить. Обмен с медицинской системой идёт через HL7 FHIR — данные ложатся в те же поля, что и раньше, без ручного переноса.
Результат пилота
Пилот шёл шесть недель на двух сменах приёмного отделения и охватил около 1 400 приёмов. Источник замеров — журналы медицинской системы и хронометраж на 120 приёмах, сверенные со старшими врачами смены. Время оформления карты сократилось с 11–13 минут до 3–4, заполненность обязательных полей выросла с 68% до 97%, доля карт, закрытых в день приёма, — с 62% до 94%. Спорные назначения отсекает проверка до подписания, а не выдача.
Цифры сняты на живой смене, а не в тестовом контуре: поток приёмов не останавливали, врачи работали как обычно. Дальше распространяем автоматическое заполнение на стационар и выписки — те же поля и те же проверки.
Чем отличается внедрение с нуля от доработки готовой системы
Развилку решает не размер клиники, а состояние учётного ядра. Если записи структурированы, есть единый идентификатор пациента и рабочие справочники, доработка существующей системы быстрее и предсказуемее: AI-слой наращивается поверх, не ломая привычную врачам логику приёма. Если же учёт держится на текстовых файлах, сканах и ручных журналах, внедрение с нуля окажется честнее — иначе разбор источников растянется на весь проект.
Доработка начинается с аудита хранилища: смотрим, какие поля реально заполняются на приёме, где дубли пациентов, как устроена выгрузка. Дальше контур подключается к существующей базе в режиме чтения и постепенно берёт на себя извлечение сущностей из записей, подсказки кодов и сводку анамнеза. Миграция без остановки строится на теневом сравнении: новая логика считает параллельно, расхождения разбираем на живых картах, переключение идёт по отделениям, а не по всей клинике разом.
Внедрение с нуля оправдано, когда источники разрозненны и нет согласованной терминологии: тогда модель данных, справочники и правила кодирования проектируются до первой записи. Это снимает главные риски замены системы — потерю связности истории, дубли и разрыв между приёмом, лабораторией и расчётами. Откат продумываем заранее: старый контур остаётся доступным для чтения, пока новый не подтвердит полноту переноса на сверке.
План перехода собираем этапами: аудит источников, прототип на выборке карт, пилот на одном отделении, сверка полноты, обучение, поэтапное включение. Критерий выхода с пилота — не общее впечатление, а доля корректно кодированных записей и время на закрытие приёма. Опишите, как устроен ваш учёт сегодня, — вернёмся с планом перехода и оценкой.
Технические сомнения перед стартом: отвечаем по пунктам
Перед стартом технические команды задают один и тот же набор вопросов: где лежат медицинские данные, кто отвечает за ошибку модели, как разграничить доступ и сколько займёт проверка на реальных записях. Отвечаем по пунктам.
Где хранятся карты и кто к ним обращается?
Данные не покидают контур заказчика или выделенный частный сегмент. Каждое обращение к карте пишется в неизменяемый журнал, передача и хранение шифруются, а на обучение уходят обезличенные выборки с сохранением связности истории болезни.
Кто отвечает за ошибку модели?
Модель формулирует предложение, решение принимает врач. Каждый вывод сопровождается ссылкой на исходные записи и оценкой уверенности: ниже порога система не подставляет значение, а подсвечивает поле. Правки врача логируются и уходят в дообучение — ответственность остаётся в клиническом процессе, а не переносится на алгоритм.
Как разграничивается доступ между сотрудниками?
Роли разводятся по принципу минимально необходимого доступа: врач видит своих пациентов, ординатор — закреплённое отделение, администратор — только метаданные. Массовая выгрузка требует отдельного подтверждения, все действия попадают в аудит.
Сколько длится пилот и по каким метрикам его оценивают?
Пилот держим в границах одного отделения или профиля: 6–10 недель, заранее зафиксированные метрики — доля полей, заполненных автоматически, время на оформление приёма, полнота извлечённых сущностей. По итогам видно, где точности достаточно для повседневной работы, а где нужен контроль человека.
Что делать с разнородными записями?
Сканы, свободный текст, разные форматы выгрузок проходят слой нормализации: распознавание, приведение к единой схеме, разметка неоднозначных случаев на ручную проверку. Так история пациента собирается в целостную картину, а не остаётся набором вложений.
Обсудим задачу и вернёмся с оценкой и планом работ
Чтобы перейти к оценке, нам нужен один предметный разговор: какие процессы уже оцифрованы, кто из специалистов работает с картами ежедневно и какие операции отнимают у них больше всего времени. Достаточно описания типового приёма и обезличенного среза записей — этого хватает, чтобы понять объём и не строить план на предположениях.
В ответ присылаем пакет, по которому можно принимать решение, а не обсуждать намерения:
- Порядок этапов: разбор процесса и данных → прототип на вашем срезе карт → пилот на ограниченной группе → расширение на остальные подразделения.
- Состав пилота: одно отделение и 8-15 пользователей, фиксированный перечень сценариев (черновик записи, структурирование полей, поиск по истории, подготовка выписок) и понятный набор исключений, которые система не берёт на себя.
- Точки контроля: после разбора данных, после прототипа и на середине пилота — с метриками по каждому сценарию, а не с демонстрацией интерфейса.
- Критерии приёмки: доля полей, заполняемых без правки врачом, время на подготовку записи приёма, число обращений к истории пациента за один визит.
- Формат передачи: описание интеграции с вашей системой ведения карт, схема ролей и доступов, регламент проверки ответов модели специалистом, инструкции для персонала.
- Ответственные с обеих сторон: кто подтверждает сценарии, кто даёт доступ к срезу данных, кто принимает результат на каждой точке.
План собирается под ваш контур, а не под типовой шаблон: если внешняя система не отдаёт данные в нужном виде, это выясняется на первом этапе и меняет объём работ, а не сроки сдачи. Опишите задачу и текущий процесс — вернёмся с оценкой, порядком этапов и планом пилота.
