Распознавание паспорта и СНИЛС в стоматологии: автозаполнение карты пациента и выгрузка в ЕГИСЗ

Почему заполнение паспорта и СНИЛС — критичный процесс, а не формальность

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

Эти поля — не просто карточка клиента в CRM. От их корректности зависит:

• формирование договора на оказание платных медицинских услуг и согласия на обработку персональных данных;
• идентификация пациента в единых государственных системах;
• сама возможность передать сведения об оказанной помощи в ЕГИСЗ.

Здесь СНИЛС играет особую роль: это сквозной идентификатор физлица в государственных системах, и без корректного СНИЛС регистрация пациента и выгрузка медицинских документов в федеральные подсистемы не проходят. Опечатка в одной цифре, допущенная администратором при ручном вводе, всплывает не сразу — а в момент, когда выгрузка в ЕГИСЗ падает с ошибкой.

Зачем клиника передаёт данные в ЕГИСЗ и можно ли этого не делать

ЕГИСЗ — Единая государственная информационная система в сфере здравоохранения. Через неё медицинские организации регистрируют оказанную помощь, формируют электронные медицинские документы и передают их в РЭМД (Реестр электронных медицинских документов).

Можно ли работать без выгрузки в ЕГИСЗ? Нет. Передача данных обязательна для всех лицензированных медучреждений любой формы собственности, включая частные клиники — это закреплено Указанием Правительства РФ № 555 от 5 мая 2018 года. Распространившийся в 2024 году слух об отсрочке до 2027 года — дезинформация: отсрочки нет, а контроль со стороны Росздравнадзора уже идёт. За непередачу данных предусмотрены штрафы по ч. 3 ст. 14.1 КоАП РФ как за нарушение лицензионных требований. То есть это не вопрос «подключаться или нет», а вопрос «как сделать так, чтобы выгрузка не ломалась».

Подключиться к ЕГИСЗ клиника может тремя способами: напрямую (трудозатратно и доступно в основном крупным сетям), через оператора сторонней информационной системы, или через оператора региональной МИС. На практике большинство частных клиник идут через своего МИС-вендора или оператора-посредника (например, N3.Health).

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

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

Узкое место во всей этой цепочке — самое начало: ручной ввод паспорта и СНИЛС в регистратуре. Это и медленно (3–5 минут на пациента, очереди), и источник тех самых опечаток, которые потом ломают выгрузку. Распознавание документов закрывает именно этот разрыв: администратор фотографирует паспорт и СНИЛС, а структурированные данные с проверенной контрольной суммой СНИЛС автоматически попадают в карту.

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

Две МИС для стоматологий — два разных способа интеграции

В сегменте стоматологий распространены две системы — IDENT и DentalPRO. И подход к интеграции распознавания у них принципиально разный, потому что различается сама техническая основа.

DentalPRO: интеграция через REST API

У DentalPRO есть REST API. Для подключения клиника запрашивает у разработчика три параметра: базовый URL, Token и API Secret для авторизации. Через REST-запросы можно как получать, так и передавать данные о пациенте и визите.

Поток автозаполнения:

Фото паспорта/СНИЛС
   → API распознавания (структурированный JSON)
   → REST-запрос в DentalPRO (создание/обновление карты пациента,
     авторизация Token + API Secret)

Конкретные эндпоинты и схему полей берут из базы знаний DentalPRO по актуальной версии системы (доступ по партнёрскому запросу). Для клиник без своей разработки возможен путь через low-code: webhook + коннектор (Make, Albato и аналоги), который сам формирует REST-запрос. Главное правило при синхронизации — использовать в качестве ключа уникальный ID пациента, а не ФИО, иначе появятся дубли карт.

IDENT: интеграция через программных роботов

IDENT построен на СУБД MSSQL, и публичного API для записи карты пациента у него нет — доступ к базе предоставляется по запросу к вендору. Это значит, что «чистый» способ «отправил REST-запрос — карта создалась» здесь недоступен. Прямая запись в таблицы MSSQL технически возможна, но неподдерживаема и опасна для медданных: схема меняется между версиями, прямые INSERT могут нарушить целостность и сломаться при обновлении.

Поэтому для IDENT рабочий подход — программные роботы (RPA). Робот воспроизводит действия администратора в интерфейсе IDENT: открывает форму создания карты пациента и подставляет в её поля данные, полученные от API распознавания.

Фото паспорта/СНИЛС
   → API распознавания (структурированный JSON)
   → программный робот заполняет поля формы карты пациента в IDENT

Этот способ обходит отсутствие write-API, работает на уровне UI и устойчив к изменениям схемы базы, потому что взаимодействует с теми же формами, что и человек, — только без опечаток и за секунды вместо минут.

Персональные данные: о чём помнить

Сведения о здоровье — специальная категория персональных данных (ст. 10 152-ФЗ), требования к их обработке повышенные. Распознавание паспорта и СНИЛС — это обработка ПДн, поэтому до съёмки нужно согласие пациента. Если распознавание выполняется в облаке стороннего сервиса, требуется договор поручения на обработку и соответствующая формулировка в согласии. Развёртывание распознавания внутри контура клиники (on-premise) снимает значительную часть этих вопросов, так как данные не покидают периметр организации.

На практике это удобно разделить на два этапа. Разработку и отладку автоматизированного решения распознавания паспортов и СНИЛС можно вести с помощью облачного сервиса documind.ru — на нём отрабатывается интеграция, маппинг полей и логика заполнения карты. А при переходе в эксплуатацию используется on-premise решение Textora, которое инсталлируется в контур предприятия: распознавание выполняется внутри периметра клиники, и персональные данные пациентов не покидают её инфраструктуру.