Мария Зайцева
Рынок ДМС-интеграций заметно сдвинулся в сторону прямого обмена данными между клиникой и страховой. В 2025 году «Ингосстрах» и «МедРокет» запустили единую платформу согласования медуслуг по ДМС с открытым API — клиника подключается напрямую, без бумажных согласований по факсу или почте. Похожий вектор подтверждает и сервис обмена данными от «ЭлНетМед», который развивается именно как защищённый канал клиника-страховая, а не разовая интеграция под одного партнёра.
Для IT-директора клиники это означает, что рано или поздно вопрос «как подключиться к ДМС-платформе страховой» перестаёт быть гипотетическим. Разбираем техническую сторону: что именно передаётся по API, какие форматы встречаются на практике, где риски безопасности и почему интеграция, которая работала полгода, вдруг перестаёт отвечать.
Коротко: по API со страховой передаются прикрепление пациента, согласование услуги, акт оказанных услуг и статус оплаты — обычно через REST/JSON, реже через legacy SOAP. Подключение одной страховой занимает от нескольких недель до пары месяцев. Интеграция чаще ломается не на старте, а при изменении формата API страховой без уведомления клиники. Точечная интеграция с одной страховой и шлюз-агрегатор для нескольких — это разные архитектуры, и выбирать между ними нужно заранее.
Что передаётся по API между клиникой и страховой
По API между клиникой и страховой обычно передаются четыре типа сущностей: прикрепление пациента к программе ДМС, запрос на согласование услуги (авторизация), акт оказанных услуг и статус оплаты. Прикрепление подтверждает, что пациент действительно застрахован и услуга покрывается его полисом — это первый запрос перед приёмом. Согласование услуги — это, по сути, запрос разрешения: клиника отправляет код услуги и стоимость, страховая отвечает «одобрено», «одобрено частично» или «отказано» с кодом причины. Акт оказанных услуг формируется постфактум и фиксирует, что было сделано на самом деле — он может отличаться от первоначально согласованного объёма, если врач назначил дополнительные процедуры. Статус оплаты — это последний элемент цепочки, который клиника получает уже после отправки акта, и именно здесь чаще всего возникают расхождения, если на стороне клиники нет повторных запросов статуса.
Какие форматы и протоколы используются
Большинство современных ДМС-платформ страховых в России работают через REST с передачей данных в JSON — это касается и упомянутой платформы «Ингосстрах»/«МедРокет». У части крупных страховых с давней ИТ-инфраструктурой встречается legacy SOAP с XML-схемами, и клинике приходится поддерживать оба варианта, если она работает с несколькими партнёрами. Отдельно стоит тренд на FHIR-подобные профили данных — пока не как обязательный стандарт в РФ, а как ориентир структуры медицинских сущностей, к которому постепенно тяготеют новые интеграции.
На практике единого протокола «под все страховые» не существует: спецификацию почти всегда проектируют под конкретного партнёра, с учётом его формата ответов и кодов ошибок. Именно поэтому такие задачи редко решаются силами штатного администратора МИС — это работа для команды, которая проектирует и сопровождает API-интеграции клиники с внешними системами — от лаборатории до страховых платформ, и может спроектировать протокол под конкретную страховую с нуля, если готового стандарта нет.
Безопасность и 152-ФЗ в контуре клиника↔страховая
Данные, которые уходят по API в страховую, — это медицинские сведения о конкретном пациенте, и канал обмена обязан быть защищённым: шифрование трафика, взаимная аутентификация сторон (сертификаты или подписанные токены), разграничение доступа по ролям на стороне клиники. Отдельный момент — согласие пациента: в акте оказанных услуг обычно достаточно кода и стоимости процедуры, но если страховая запрашивает развёрнутое медицинское обоснование, для передачи таких данных нужно отдельное согласие пациента, а не общее согласие на обработку персональных данных при заключении договора ДМС. Смешивать эти два уровня согласия — частая ошибка, которая всплывает только при проверке.
Сколько времени занимает подключение клиники к ДМС-платформе страховой
Подключение клиники к ДМС-платформе одной страховой обычно занимает от трёх недель до двух месяцев, в зависимости от того, есть ли у страховой готовая документация API. Первый этап — получение технической спецификации и тестовых кредов от страховой, это может занять от нескольких дней до пары недель в зависимости от скорости ответа на стороне страховой. Второй этап — разработка и прогон через тестовый контур: клиника отправляет тестовые согласования и акты, страховая подтверждает корректность формата. Третий этап — продакшн с ограниченным объёмом пациентов в первую неделю, чтобы отловить расхождения на реальных кейсах, прежде чем переводить весь поток ДМС-пациентов на новую интеграцию.
Типичные причины, по которым интеграция ломается
Чаще всего интеграция перестаёт работать не из-за ошибки в коде на старте, а из-за изменений, о которых никто не предупредил вовремя. Три повторяющихся сценария: клиника обновляет МИС, и новая версия начинает отправлять запросы в чуть изменённом формате, который старая интеграция со страховой не учитывала; страховая меняет формат ответа или коды ошибок на своей стороне без уведомления партнёров — это происходит чаще, чем кажется, особенно у крупных страховых с несколькими ИТ-подрядчиками; и, пожалуй, самое частое — на стороне клиники нет логирования ошибок и retry-механизма, поэтому отказы страховой просто теряются, а администраторы узнают о проблеме только от недовольного пациента. Базовое правило: любая интеграция с внешней системой должна логировать каждый запрос и ответ, иначе диагностика сбоя занимает часы вместо минут.
Клиника → 1 страховая vs клиника → агрегатор нескольких страховых
Точечная интеграция с одной страховой — самый быстрый путь для старта: клиника пишет адаптер под конкретный формат API партнёра и ограничивается этим. Но если клиника работает (или планирует работать) с несколькими страховыми компаниями, тот же подход, повторённый N раз, превращается в N независимых интеграций, которые никто централизованно не мониторит. Альтернатива — единый шлюз-агрегатор внутри контура клиники: он нормализует входящие и исходящие данные в один внутренний формат, а адаптеры под конкретных страховых становятся тонким слоем поверх этого шлюза. Разница в архитектуре принципиальна: переделать точечную интеграцию в шлюз задним числом обычно дороже и дольше, чем заложить шлюз сразу, даже если на старте работает только одна страховая.
Частые вопросы
Нужна ли клинике отдельная команда разработки для интеграции с ДМС?
Не всегда отдельная команда, но нужен хотя бы один специалист или подрядчик, который понимает формат API конкретной страховой и может поддерживать интеграцию после запуска — большинство проблем возникает не на старте, а при последующих изменениях на стороне страховой.
Что произойдёт, если страховая сменит API без предупреждения?
Без логирования ошибок и алертов интеграция может молча отдавать отказы по согласованию услуг несколько дней, прежде чем это заметят в клинике. Поэтому мониторинг статусов ответов — обязательная часть интеграции, а не опция.
Можно ли подключить несколько страховых через одну интеграцию?
Да, если изначально проектировать интеграцию как шлюз с нормализацией форматов, а не как точечное подключение к одной страховой. Переделать точечную интеграцию под несколько партнёров позже обычно дороже, чем заложить это архитектурно сразу.
Сколько стоит такая интеграция в среднем?
Точную цифру без вводных не назвать — стоимость зависит от числа страховых-партнёров, наличия готового API у МИС клиники и того, нужен ли шлюз-агрегатор или достаточно одной точечной интеграции. Это стоит считать по конкретному техническому заданию, а не по среднерыночной оценке.
