Интеграция CRM с МИС: как связать Битрикс24 с Инфоклиникой, IDENT, Renovatio и другими
Эта страница — техническая справка, а не коммерческое предложение. Ниже собрано то, что в подобных интеграциях всплывает уже по ходу работ и ломает сроки: у какой медицинской информационной системы API штатный, у какой платный, а у какой его нет вовсе; какие данные реально переносятся в CRM, а какие переносить нельзя по закону; что ломается в связке МИС и Битрикс24 и где поломку нельзя починить в принципе. Если вы выбираете подрядчика на интеграцию, читайте её как список вопросов, которые стоит задать до подписания договора. Фактура — по состоянию на июль 2026 года.
Какие МИС и как реально связываются с CRM
Первое, обо что разбивается проект интеграции, — доступ к данным на стороне МИС. Это не вопрос квалификации подрядчика: если у вендора нет метода записи в расписание, он не появится ни за какие деньги. Поэтому разговор начинается не с воронки и не с бюджета, а с таблицы ниже и с письменного ответа вендора вашей системы.
| МИС | Тип API | Направление обмена | Что реально переносится | Ограничения |
|---|---|---|---|---|
| Инфоклиника, Инфодент | Платный. Доступ открывает вендор по заявке, под конкретное приложение, с отдельной тарифной опцией и ежемесячной абонентской платой. | На практике односторонний: МИС → CRM. | Пациенты, приёмы, врачи, филиалы, коды и цены услуг, статусы приёмов, начисления и оплаты. | В одном аккаунте на один сайт настраивается один тип интеграции: Инфоклиника или Инфодент, не оба сразу. Типовой цикл обмена — 5–15 минут. |
| IDENT | Публичной документации нет. Условия и формат обсуждаются с вендором, интеграторы описывают работу как спецразработку. | Как правило односторонний. | ФИО, дата рождения, телефон, номер медкарты, баланс, комментарий администратора. | Сроки и стоимость нельзя оценить до ответа вендора. Готовые коннекторы на рынке есть, но набор полей у них фиксированный. |
| Renovatio (rnova) | Штатный, документация публичная: ключ api_key в каждом методе, ответ в JSON. | Двусторонний сценарий реалистичен: есть методы и чтения расписания, и записи пациента на приём. | Врачи, расписание, услуги, записи пациентов. | Права ключа определяет клиника. Всё, чего нет в списке методов, закрывается ручными операциями администратора. |
| Клиентикс | Штатный, открытый. Активируется в личном кабинете: ID аккаунта, ID пользователя и токен. | Двусторонний. | Пациенты, записи, услуги. | У системы есть собственный CRM-модуль. Прежде чем строить обмен, проверьте, не хватает ли его: на небольшом потоке чаще хватает. |
| MEDODS | Штатный (API 2.0). | Зависит от состава методов, чтение — уверенно. | Пациенты, записи, услуги. | Облачная и локальная установки отличаются способом доступа: для локальной нужен вход в сетевой контур клиники. |
| Medesk | На момент отраслевого обзора значился как «в разработке». | Уточняется у вендора. | — | Планировать проект стоит только после письменного подтверждения вендора, что API доступен именно вам. |
| MEDMIS (Гиасофт) | Штатный. | Чаще односторонний. | Пациенты, приёмы. | Есть облачная и серверная версии, способ доступа у них разный. |
| Медиалог | По запросу к вендору. | Уточняется. | — | Срок открытия доступа определяет вендор, и он не входит в наши сроки по проекту. |
| Медотрейд | Штатный. | Уточняется. | Пациенты, записи. | Разворачивается на стороне клиники, нужен доступ в её сеть. |
| MGERM | Ограниченный. | Односторонний. | Базовый набор по пациенту и записи. | Часть данных выгружается только вручную. Система работает на сервере клиники. |
| ArchiMed+ | Коннекторы к Битрикс24 существуют у интеграторов. | Обычно односторонний. | Пациенты, записи. | Есть встроенный CRM-модуль — та же оговорка, что и по Клиентиксу. |
| 1С:Медицина, 1С:Стоматология, линейка БИТ | Обмен штатными механизмами 1С. | Двусторонний технически достижим. | Пациенты, записи, услуги, оплаты. | Всё определяется конфигурацией и доработками конкретной клиники: две внешне одинаковые 1С интегрируются по-разному. |
| Самсон | Ограниченный. | Односторонний. | Выгрузка данных в CRM. | Записать данные обратно в МИС нельзя. Это ограничение системы, а не качества интеграции. |
| Остальные: МедАнгел, DentalPRO, EasyClinic, SQNS, 32top, Авиценна, УСУ, Doctor Soft, МЕДОХВАТ, UNIVERSE-Медицина, МедЛок | По-разному: от открытого API до полного его отсутствия. | — | — | Проверяем индивидуально. Первый шаг всегда один: письменный запрос вендору о доступе, составе методов и цене. |
Таблица отражает ситуацию на июль 2026 года и собрана по публичной документации вендоров и описаниям действующих интеграций. Лицензионная и тарифная политика меняется без предупреждения, поэтому доступность API мы подтверждаем письмом вендора до подписания договора, а не после. Прочерк означает, что публичных сведений недостаточно, а не то, что интеграция невозможна.
Четыре способа связать системы
1. Штатный API МИС
Вендор публикует методы, клиника выдаёт ключ, обмен идёт по документированному протоколу. Так устроены Renovatio, Клиентикс, MEDODS.
- Плюсы: обмен поддерживается вендором и переживает обновления МИС; ошибки диагностируются по кодам ответа; клиника в любой момент может отозвать ключ.
- Риски: сценарий целиком ограничен составом методов. Нет метода записи в расписание — не будет и двустороннего обмена, каким бы ни был бюджет.
Проверяется это в одно письмо: просите у вендора не подтверждение, что «API есть», а список методов с описанием параметров. Формулировка «интеграция возможна» ни к чему его не обязывает.
2. Платный API с выдачей доступа вендором
Отдельная тарифная опция плюс заявка на открытие доступа под конкретное приложение. Классический пример — Инфоклиника: доступ выдают разработчики МИС, и клиника платит за него ежемесячно.
- Плюсы: легальный и поддерживаемый канал. Вендор знает о вашей интеграции и не сломает её молча очередным обновлением.
- Риски: это постоянная строка в бюджете клиники, а не разовый платёж интегратору. Срок открытия доступа контролирует вендор. Ограничения вроде «один аккаунт — один тип интеграции» приходится обходить архитектурой, отменить их нельзя.
Деталь, которая всплывает поздно: доступ выдаётся под конкретное приложение. При смене подрядчика, переезде на другую CRM или запуске второго сервиса заявку подают заново, и клиника снова ждёт вендора.
3. Прямой доступ к базе данных
СУБД медицинской системы читают напрямую: учётной записью с урезанными правами, SQL-запросом, отдавая результат в JSON. У Инфоклиники это MySQL и Firebird, и на рынке есть готовые модули, которые именно так обходят абонентскую плату за API.
- Плюсы: дешевле и быстрее в моменте, доступны поля, которых в API нет.
- Риски: нарушение условий поддержки вендора. Схема базы не является публичным контрактом — её меняют в любом обновлении, и обмен встаёт без предупреждения. Запись напрямую в таблицы идёт мимо бизнес-логики МИС и способна испортить данные, за которые клиника отвечает перед регулятором.
По умолчанию мы этот способ не предлагаем. Если клиника выбирает его осознанно, он обсуждается отдельно и только на чтение — но честнее сначала посчитать абонентскую плату за легальный доступ и сравнить с ценой простоя, когда обмен развалится после обновления.
4. Промежуточная шина
Между МИС и CRM ставится платформа обмена — N3.Health, МедФлекс, ApiMonster и другие. Она берёт на себя коннекторы, повторные попытки и журнал операций.
- Плюсы: один канал вместо нескольких попарных связок, логи и повторы из коробки, часть платформ специализируется на медицинских данных и уже подключена к ЕГИСЗ.
- Риски: в контуре появляется третья сторона, через которую проходят данные пациентов, — нужен договор и понимание, где они физически хранятся и как долго. У шин есть ограничения по частоте вызовов и короткий срок хранения истории обмена, порядка одного–трёх дней, а тарификация обычно идёт по транзакциям и растёт вместе с потоком.
Для клиники это ещё один договор на обработку персональных данных — с оператором шины, а не только с интегратором. Считать шину невидимой инфраструктурой не получится: через неё идут те же данные пациентов.
Выбор способа — не вопрос вкуса, его почти полностью определяет ваша МИС. Со стороны CRM ограничения тоже есть: интеграции Битрикс24 с внешними системами живут в лимитах REST, и первичную загрузку десятков тысяч исторических записей приходится проектировать пакетами и ночными окнами, а не «включать синхронизацию».
Реестр синхронизируемых полей
Ниже — состав обмена, который мы берём за отправную точку. Это не перечень «что технически возможно», а рабочий минимум, из которого собирается воронка первичного пациента и отчётность по каналам. Итоговый реестр согласуется до начала работ и становится приложением к договору-поручению на обработку персональных данных.
Карточка пациента → Контакт
- ФИО, пол, дата рождения, возраст
- Телефон и адрес электронной почты
- Представитель — для несовершеннолетних и для случаев, когда обращается родственник
- Внутренний идентификатор пациента в МИС: ключ, по которому связываются записи в обеих системах
- Город или район проживания
- Статус пациента: первичный, в лечении, завершил, потерян
- Страховые данные и срок действия полиса — если клиника работает с ДМС
- Отметки об отказе от коммуникаций: обязательное поле, без него любая рассылка становится нарушением, и переноситься оно должно в обе стороны
- Комментарий администратора
Приём → Сделка
- Дата и время создания записи, дата и время самого приёма
- Врач и филиал
- Администратор, оформивший запись
- Статус приёма: запланирован, состоялся, отменён, неявка. Неявку выделяем отдельным статусом, иначе её нечем считать
- Коды услуг и категория приёма — именно коды: названия в прайсе меняются чаще, чем коды
- Цена услуги, начисленная сумма, скидка, оплачено
- Идентификаторы записи в МИС и сделки в CRM
- Комментарий к приёму — без клинического содержания
Обмен разбивается на три независимых потока: будущие приёмы, состоявшиеся и отменённые. Так отмена не растворяется в общей выгрузке и попадает в работу администратора в том же цикле, а не через сутки.
В рабочем документе у каждого поля стоят три пометки: направление обмена, обязательность и правило разрешения конфликта — какая система считается источником истины, если значения разошлись. Для данных пациента источником истины почти всегда остаётся МИС: там работает регистратура и там же данные закрыты подписанным согласием. Для данных о канале обращения и рекламной кампании — наоборот, CRM.
Что мы не передаём в CRM никогда
- Диагнозы и коды МКБ
- Результаты анализов и исследований, описания снимков
- Содержание назначений и планов лечения: сумму плана передаём, состав — нет
- Сканы медицинских документов и подписанных согласий — в CRM живёт только отметка, что согласие получено, и его дата
- Свободные комментарии врача из карты
Это не осторожность ради осторожности. Перечень выше — единственная часть проекта, где ошибка не чинится задним числом: выгруженные однажды данные нельзя выгрузить обратно.
Основание — две независимые нормы. По ст. 10 152-ФЗ сведения о состоянии здоровья отнесены к специальной категории персональных данных, и их обработка по общему правилу запрещена. По ч. 1 ст. 13 323-ФЗ врачебную тайну составляют не только диагноз и состояние здоровья, но и сам факт обращения человека за медицинской помощью. Часть 4 той же статьи содержит закрытый перечень случаев, когда сведения раскрываются без согласия, — маркетинга в этом перечне нет.
Отсюда следует неочевидное. Связка «номер телефона плюс факт записи», выгруженная в коллтрекинг или в систему сквозной аналитики, уже раскрывает факт обращения за медицинской помощью. Не диагноз — сам факт. Действующие на рынке интеграции нередко передают ФИО, телефон и почту пациента между системами, не описывая ни обезличивания, ни псевдонимизации. Проектировать стоит иначе: наружу, в рекламные кабинеты и сводные отчёты, уходят обезличенные категории услуг и суммы, а связка с конкретным человеком остаётся внутри контура клиники.
Правовую часть разбираем отдельно — CRM и персональные данные пациентов; здесь мы не даём юридических заключений. Техническое следствие короткое: состав обмена определяется не тем, что умеет API, а тем, что клиника имеет право отдать.
Что ломается в связке МИС и CRM
| Проблема | Почему возникает | Что делаем | Где решить нельзя |
|---|---|---|---|
| Дубли пациентов | Записаться можно по телефону, через сайт, в соседнем филиале и через агрегатор. Один человек попадает в базу несколько раз: с разным написанием ФИО, с рабочим и личным номером. | Правило «один пациент — одна карточка». Идентификация по номеру телефона, валидация телефона и почты на входе, связывание по внутреннему идентификатору МИС, регулярный отчёт по подозрительным парам. | Если пациент оставил другой номер и другое написание имени, автоматика записи не склеит. Останется ручная проверка, и её объём надо закладывать в работу администратора, а не надеяться, что дублей не будет. |
| Лаг синхронизации | Обмен идёт циклами по расписанию, а не в реальном времени: типовой интервал — 5–15 минут, а при работе через шину добавляются ограничения на частоту вызовов. | Разносим потоки: новая запись и отмена уходят в приоритетную очередь, история и справочники — фоновым пакетом ночью. Частоту согласуем с лимитами API обеих систем. | «В реальном времени» не бывает. Администратор, держащий открытыми обе системы, будет видеть расхождение в несколько минут. Это нормальное поведение, и объяснить его людям нужно до запуска, а не после первой жалобы. |
| Мэппинг прайса | В МИС услуги живут в собственном справочнике с кодами и меняются вместе с прайсом. В CRM это направления, товары или поля сделки. Названия не совпадают почти никогда. | Согласуем таблицу соответствий по кодам, а не по названиям, и правило для новых позиций: пока услуга не сопоставлена, сделка попадает в отдельную очередь на разбор, а не теряется. | Если услугу переименовали и выдали ей новый код, соответствие рвётся. Каждая ревизия прайса — это ручная сверка, автоматически догадаться о смене кода нельзя. |
| Пациента нельзя записать обратно в МИС | У части систем API одностороннее: данные читаются, но метода записи в расписание нет. Тогда запись, созданная в CRM, не занимает слот у врача. | Проверяем состав методов до договора и фиксируем в техническом задании, какой сценарий доступен: полноценная запись из CRM или заявка, которую администратор переносит в МИС руками. | Если у вендора нет метода записи, её не сделает ни один интегратор. Вариантов два: администратор вносит запись вручную либо клиника меняет МИС. Обещание «двусторонняя синхронизация с любой МИС» — маркетинг, а не техника. |
| Сопоставление звонка с приёмом | Коллтрекинг связывает звонок с записью по номеру телефона. Документация интеграций с Инфоклиникой и Инфодентом прямо требует, чтобы администратор фиксировал номер в обращении вручную. | Делаем поле обязательным, настраиваем автоподстановку из карточки звонка, добавляем отчёт по незаполненным обращениям и разбираем его на еженедельной встрече. | Если номер не зафиксирован, связь звонка и приёма задним числом не восстановить. По отраслевым оценкам ручная маркировка источника съедает до половины данных — цифра не наша, но порядок реалистичный. Это дисциплина администраторов, а не настройка системы. |
Последняя колонка здесь важнее остальных трёх. Подрядчик, который на этапе продажи говорит, что решаемо всё, просто переносит разговор на второй месяц проекта — когда клиника уже оплатила лицензии и перестроила работу регистратуры.
Границы ответственности
| Зона | Что в неё входит | Кто отвечает |
|---|---|---|
| МИС и её вендор | Электронная медицинская карта, расписание врачей и кабинетов, назначения, лаборатория, документы, касса. Отдельно — передача сведений в ЕГИСЗ и его подсистемы: ФРМО, ФРМР, РЭМД. С 1 сентября 2021 года взаимодействие с ЕГИСЗ является лицензионным требованием к медорганизации любой формы собственности, включая частную (ПП РФ № 852). | Клиника как лицензиат и вендор МИС как поставщик функциональности. Состав и работоспособность API — тоже здесь. |
| CRM | Всё, что происходит до записи и вокруг неё: обращения и недозвоны, воронка первичного пациента, задачи и напоминания, сегменты для повторных обращений, отчётность по каналам и филиалам. | Клиника как владелец процесса. Мы настраиваем, но исполняют регламент администраторы. |
| Интегратор | Проект обмена, реестр полей, разграничение доступа, обработка ошибок и повторные попытки, мониторинг расхождений, документация и передача доступов. | Мы. |
Мы не подключаем клинику к ЕГИСЗ, не работаем с электронной медицинской картой и не заменяем МИС: это зона вендора и лицензионные обязательства клиники. Если подрядчик обещает «сделаем и ЕГИСЗ заодно», стоит уточнить, что именно имеется в виду. При этом, получая доступ к данным пациентов, интегратор становится обработчиком по поручению: по ч. 3 ст. 6 152-ФЗ для этого нужен договор-поручение с перечнем данных и операций, а ответственность перед пациентом по ч. 5 остаётся на клинике. Поэтому реестр полей из раздела выше — не бумажная формальность, а приложение к этому договору.
Отдельно проговариваем срок. Открытие доступа к API на стороне вендора занимает от нескольких дней до нескольких недель, и усилиями интегратора это время не сокращается. Мы закладываем его в план как внешнюю зависимость и не считаем частью своих работ.
Как проходит работа
- Запрос вендору МИС. До коммерческого предложения выясняем письменно: есть ли API, входит ли он в ваш тариф, какие методы доступны и есть ли среди них запись в расписание. Ответ вендора — вход в проект: без него любая оценка сроков будет выдумкой.
- Реестр полей и правила обмена. Согласуем документ: какие поля, в какую сторону, с какой частотой, что не передаётся вообще. Он же становится приложением к договору-поручению.
- Настройка и тестовый контур. Запускаем обмен на ограниченной выборке: проверяем дубли, лаг, сопоставление прайса и поведение при отмене. Отдельно прогоняем самый хрупкий сценарий: пациент записался, отменил и записался снова к другому врачу.
- Запуск и наблюдение. Первые две недели смотрим расхождения ежедневно, дальше — по отчёту. На выходе клиника получает доступы, схему обмена и инструкцию для администратора.
Если CRM в клинике ещё нет, интеграция — не первый шаг, а четвёртый: сначала воронка, роли и регламент, иначе синхронизировать попросту нечего. Как это устроено, разобрано на странице CRM для медицинской клиники.
С чего начинается интеграция
Интеграцию нельзя оценить «на глаз» — стоимость определяется тем, что именно умеет ваша МИС. Поэтому первый этап всегда одинаковый: выясняем, какой доступ к данным у вас есть, какие поля реально нужны и что делать с расписанием.
По итогам этого разбора вы получаете реестр синхронизируемых полей и схему обмена. Даже если делать интеграцию вы будете не с нами, документ останется у вас и пригодится любому подрядчику.
