Интеграция Битрикс24 и «Медкассы»: как мы автоматизируем путь пациента от обращения до оплаты

Интеграция Битрикс24 с «Медкассой» позволяет связать обращения пациентов, запись, визиты, оказанные услуги и оплаты в единый процесс. При этом сотрудники регистратуры и кассы продолжают работать в привычной медицинской системе, а CRM автоматически получает данные, необходимые для контроля обращений, аналитики и повторной работы с пациентами.

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

Именно по такому принципу Profi Soft / Marketing Gid проектирует интеграцию Битрикс24 и «Медкассы» для Национального центра детской реабилитации.

Что было не так с текущим процессом

Во многих медицинских организациях автоматизация уже есть.

Есть медицинская информационная система.
Есть кассовая программа.
Есть телефония.
Есть сайт.
Есть WhatsApp.
Иногда есть CRM.

Но проблема заключается в другом: эти системы не образуют единый процесс.

В рассматриваемом проекте одновременно используются:

Из-за этого возникает главный информационный разрыв.

В «Медкассе» появляется пациент, который уже записался.

Но до этого момента организация практически не видит его путь:

откуда человек пришёл → кто с ним разговаривал → получил ли он консультацию → почему не записался → почему отменил запись → почему не пришёл.

Именно эту часть процесса должна закрыть CRM.

Что мы хотим получить в результате

Целевая схема выглядит достаточно просто:

Обращение → консультация → запись → подтверждение → визит → оказанная услуга → оплата → повторный контакт

При этом каждая система выполняет только свою функцию.

Битрикс24 отвечает за:

• звонки;
• WhatsApp и другие каналы обращений;
• заявки с сайта;
• историю коммуникаций;
• источник клиента;
• работу администратора;
• напоминания;
• возврат клиентов;
• контроль неприходов;
• маркетинговую и управленческую аналитику.

«Медкасса» отвечает за:

• пациентов;
• расписание специалистов;
• запись на приём;
• фактический визит;
• оказанные услуги;
• стоимость;
• оплаты;
• кассовые операции;
• возвраты.

Это принципиальный момент.

Мы не пытаемся заменить «Медкассу» Битрикс24.

Мы соединяем специализированную медицинскую систему с CRM.

Такой подход зафиксирован и в технической архитектуре проекта: для каждой сущности определяется одна мастер-система, а вторая система получает только необходимые данные.

Главный принцип проекта: сотрудник не должен быть «интеграцией»

Одна из самых распространённых ошибок автоматизации выглядит так:

1. сотрудник получает звонок;
2. записывает данные в CRM;
3. открывает медицинскую систему;
4. повторно вводит пациента;
5. создаёт запись;
6. после оплаты снова открывает CRM;
7. вручную меняет статус сделки;
8. переносит сумму оплаты.

Технически CRM внедрена.

Но бизнес-процесс стал сложнее.

Мы считаем такую автоматизацию неправильной.

Как должно быть

Регистратор создаёт запись в «Медкассе».

После этого система сама сообщает Битрикс24:

пациент записан.

CRM автоматически:

• находит соответствующее обращение;
• связывает его с пациентом;
• переводит сделку на стадию «Записан»;
• запускает напоминания;
• контролирует дальнейший путь пациента.

Когда пациент пришёл, CRM получает новый статус.

Когда услуга оказана — получает информацию об услуге.

Когда кассир принимает оплату — сумма появляется в CRM автоматически.

Человек выполняет свою работу один раз. Остальное делают системы.

Именно поэтому в техническом задании отдельно зафиксировано требование: кассир и регистратор не должны получать дополнительное рабочее окно и повторно вводить данные.

Почему для детского реабилитационного центра нужна особая архитектура CRM

Интеграция медицинского центра отличается от стандартного проекта CRM.

В данном случае есть ещё одна важная особенность — организация работает с детьми.

Пациент и клиент — не всегда один человек

Пациентом является ребёнок.

Но:

• звонит родитель;
• пишет в WhatsApp родитель;
• подтверждает запись родитель;
• оплачивает услугу родитель;
• получает напоминание также родитель или опекун.

Поэтому нельзя хранить всё в одной карточке «Клиент».

Необходимо разделить две сущности:

Пациент — ребёнок.
Представитель — родитель или опекун.

Между ними создаётся связь.

Один родитель может представлять нескольких детей

Это ещё одна важная особенность.

Например:

Ахметова Гульмира Сериковна

может быть представителем:

• Алихана;
• Аружан;
• другого ребёнка.

Поэтому модель CRM должна поддерживать связь:

один представитель → несколько пациентов

а не создавать независимый контакт при каждом новом обращении.

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

Курсовое лечение: почему обычной сделки недостаточно

В реабилитационной медицине пациент часто покупает не одну услугу.

Назначается курс.

Например:

10 занятий с логопедом.

Если рассматривать каждое посещение как отдельную сделку, аналитика становится неточной.

CRM будет считать:

10 посещений = 10 независимых продаж.

Хотя фактически это один курс.

Поэтому при проектировании интеграции мы предусматриваем возможность связать посещения с курсом лечения.

Тогда CRM может понимать:

Это позволяет использовать CRM не только для первой записи, но и для повторных курсов и удержания пациентов.

Как будет работать путь пациента после интеграции

Рассмотрим процесс последовательно.

Шаг 1. Человек обращается в медицинский центр

Источник может быть практически любым:

• телефон;
• WhatsApp;
• Instagram;
• сайт;
• CRM-форма;
• e-mail.

Битрикс24 фиксирует обращение.

В CRM появляется информация:

кто обратился, откуда пришёл, когда обратился и кто отвечает за дальнейшую работу.

Шаг 2. Администратор консультирует пациента

Администратор уточняет:

• какая услуга нужна;
• к какому направлению относится обращение;
• нужен ли конкретный специалист;
• когда человеку удобно приехать.

При необходимости CRM получает справочник услуг и стоимость из «Медкассы».

Таким образом, сотрудники работают с актуальным прайсом.

Шаг 3. Проверяем, существует ли пациент

Перед созданием новой карточки необходимо проверить пациента.

В проекте предусматривается поиск по нескольким признакам.

Наиболее надёжный вариант — идентификатор пациента или ИИН.

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

Задача здесь простая:

не создавать дубликаты.

Два сценария записи пациента

При проектировании мы сознательно разделили запуск интеграции на два уровня.

Это позволяет не пытаться сразу автоматизировать самую сложную часть.

Сценарий А. Регистратор продолжает записывать пациента в «Медкассе»

Это самый безопасный вариант запуска.

Сотрудник принимает обращение.

Регистратор создаёт запись привычным способом.

Но дальше начинает работать интеграция.

«Медкасса» сообщает Битрикс24:

запись создана.

CRM автоматически переводит сделку в соответствующую стадию.

Что меняется для регистратора?

Практически ничего.

Он работает так же, как работал раньше.

Что меняется для руководителя?

Появляется сквозной контроль:

обращение → запись → посещение → оплата.

Именно этот сценарий техническое задание рекомендует в качестве первого этапа проекта.

Сценарий Б. Запись пациента прямо из Битрикс24

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

Администратор открывает карточку CRM.

Выбирает:

услугу → специалиста → филиал → дату.

CRM запрашивает у «Медкассы» свободное время.

Например:

Администратор выбирает 12:00.

Нажимает:

«Записать».

CRM отправляет данные в «Медкассу».

Запись появляется там автоматически.

Регистратору вообще ничего делать не нужно.

В коммерческом предложении по проекту именно двусторонняя интеграция рассматривается как целевая модель: данные пациента и записи передаются из Битрикс24 в «Медкассу», а результаты визита и оплаты возвращаются обратно в CRM.

Почему запись из CRM лучше запускать вторым этапом

На первый взгляд кажется, что запись непосредственно из Битрикс24 нужно реализовать сразу.

Но технически это одна из самых чувствительных частей проекта.

Рассмотрим простой пример.

Два администратора одновременно видят один свободный слот.

Оба нажимают:

«Записать на 15:00».

Если правильно не реализовать проверку занятости, в системе могут появиться два пациента у одного специалиста на одно время.

Поэтому окончательное подтверждение свободного слота всегда должна выполнять «Медкасса».

CRM только отправляет запрос.

Медицинская система отвечает:

запись создана

или:

слот уже занят.

Такой подход снижает вероятность ошибок.

Нужна интеграция Битрикс24 с медицинской, бухгалтерской или отраслевой системой?
Profi Soft может начать с обследования процесса и подготовки архитектуры обмена. Сначала мы определяем, какие данные действительно должны передаваться, и только затем переходим к разработке.

Почему API — это только половина интеграции

Часто заказчик спрашивает:

«У нашей программы есть API. Значит, её можно интегрировать?»

Не всегда.

Само наличие API ещё ничего не гарантирует.

Важно, какие операции через него доступны.

Для рассматриваемого проекта нужны несколько групп данных.

Техническое задание предусматривает REST API, JSON, HTTPS, постоянные идентификаторы, постраничную выборку, тестовый контур и механизм получения изменённых данных.

Зачем нужен external_id

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

какой объект в одной системе соответствует объекту в другой.

Представим:

в Битрикс24 есть сделка №14567.

В «Медкассе» эта же запись имеет ID 771203.

Интеграция должна знать, что это одна и та же запись.

Для этого используется внешний идентификатор:

external_id

В него можно записать ID объекта Битрикс24.

Тогда системы точно понимают, какие данные связаны друг с другом.

Как мы защищаемся от двойного создания записей

Представим другую ситуацию.

CRM отправляет запрос:

создать запись пациента.

«Медкасса» создаёт её.

Но интернет-соединение на секунду пропадает.

Битрикс24 не получает ответ.

Что делать?

CRM повторяет запрос.

Без специальной защиты может появиться вторая запись.

Поэтому в архитектуре используется идемпотентность.

Для каждой операции формируется уникальный ключ.

Если одинаковый запрос приходит второй раз, система понимает:

эта операция уже выполнялась.

И возвращает существующий результат вместо создания дубля.

Почему нам нужны вебхуки

Системы могут обмениваться информацией двумя способами.

Вариант 1. CRM постоянно спрашивает

Например, раз в несколько минут:

«Появились новые записи?»

«Пациент пришёл?»

«Есть новая оплата?»

Такой подход называется polling.

Он может использоваться как резерв.

Но для основного обмена лучше применять события.

Вариант 2. «Медкасса» сама сообщает об изменениях

Произошло событие:

пациент пришёл.

«Медкасса» отправляет CRM вебхук:

visit.arrived

Произошла оплата:

payment.registered

Пациент не пришёл:

visit.no_show

Так CRM может реагировать практически сразу.

Какие события мы используем

Такой состав событий подробно описан в техническом задании интеграции.

Что происходит при сбое интеграции

Интеграция должна проектироваться с пониманием простой вещи:

сеть иногда недоступна.

API иногда не отвечает.

Сервер может временно перезапускаться.

Поэтому нельзя строить архитектуру по принципу:

не доставили событие один раз — данные потерялись.

Мы предусматриваем несколько уровней защиты.

Повторная отправка

Если Битрикс24 не принял событие, оно отправляется повторно.

Уникальный номер события

Каждый вебхук получает event_id.

Это позволяет CRM понять, что одно и то же событие пришло повторно, и не обработать его дважды.

Резервная синхронизация

Если событие всё же не дошло, Битрикс24 может запросить все изменения после определённой даты.

Например:

показать все записи, которые изменились после 14:00.

Таким образом система способна восстановить пропущенную информацию.

Что делаем с неявками пациентов

Неявка — это не просто статус.

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

Но для аналитики недостаточно знать:

«пациент не пришёл».

Нужно понимать причину.

Например:

• заболел;
• отменил заранее;
• забыл;
• не удалось дозвониться;
• не устроила стоимость;
• выбрал другую организацию;
• другая причина.

В проекте поэтому предусмотрена структурированная причина неявки.

После получения статуса visit.no_show CRM может автоматически:

создать задачу → назначить ответственного → поставить дату звонка → вернуть пациента в работу.

Неявка перестаёт быть конечной точкой.

Она становится отдельным бизнес-процессом.

Как появляется настоящая сквозная аналитика

До интеграции системы обычно показывают разные части бизнеса.

Маркетинг видит:

100 обращений.

«Медкасса» видит:

65 посещений.

Касса видит:

1 500 000 ₸ оплаты.

Но руководителю нужно другое.

Ему необходимо связать эти цифры.

После интеграции можно построить путь:

Instagram → обращение → запись → визит → логопед → 8 000 ₸

или:

Google → обращение → отказ → причина «стоимость».

И только тогда появляется настоящая сквозная аналитика.

Какие показатели можно анализировать

Руководитель получает возможность видеть:

Это принципиально отличается от обычного отчёта по лидам.

CRM начинает показывать не количество заявок, а коммерческий результат обращения.

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

Что нельзя передавать в CRM

Для медицинского проекта этот раздел особенно важен.

CRM не должна превращаться в медицинскую информационную систему.

В рамках разработанной архитектуры в Битрикс24 не передаются медицинские сведения.

К ним относятся, например:

• диагноз;
• анамнез;
• медицинские протоколы;
• результаты обследований;
• врачебные заключения;
• назначения;
• медицинские документы и вложения.

Для управления коммерческим процессом эта информация не нужна.

CRM достаточно знать:

кто обратился → на какую услугу записан → пришёл ли → какая услуга оказана → сколько оплачено.

Почему мы предусматриваем псевдонимизацию

Организация работает с несовершеннолетними.

Поэтому состав данных должен отдельно проходить юридическую оценку.

Если передача полного ФИО или ИИН ребёнка в CRM будет признана нежелательной или недопустимой, техническое задание предусматривает альтернативный режим.

Например, CRM получает:

ID пациента в «Медкассе» + ограниченный набор информации.

А персональные медицинские данные продолжают храниться только в профильной системе.

Кроме того, вместо конкретного наименования чувствительной услуги может использоваться более общая группа услуг.

Такой подход также предусмотрен в проектной документации.

Как мы реализуем проект по этапам

Мы не начинаем программирование сразу после фразы:

«Нам нужно соединить две системы».

Сначала необходимо разобраться в процессе.

Этап 1. Обследование

Определяем:

• как сейчас приходит обращение;
• кто его обрабатывает;
• где создаётся пациент;
• кто записывает на приём;
• где фиксируется посещение;
• где проходит оплата;
• какие отчёты нужны руководителю.

Этап 2. Проектирование CRM

Создаём структуру Битрикс24:

воронки → стадии → карточки → поля → роли → права → роботы → триггеры.

Отдельно проектируем карточки пациента и его представителя.

Этап 3. Проектирование интеграции

Определяем:

• API-методы;
• направления обмена;
• идентификаторы;
• правила поиска дублей;
• состав вебхуков;
• обработку ошибок;
• правила повторных запросов.

Фактически создаётся контракт между двумя системами.

Этап 4. Разработка коннектора

Разрабатывается промежуточный механизм обмена.

Он:

• обращается к API;
• принимает вебхуки;
• связывает сущности;
• журналирует операции;
• фиксирует ошибки;
• контролирует повторную обработку.

Этап 5. Тестирование

Проверяются реальные бизнес-сценарии.

Например:

создали запись → появилась сделка.

перенесли запись → изменилась дата.

пациент не пришёл → появилась задача.

прошла оплата → сумма появилась в CRM.

пришёл повторный вебхук → дубль не возник.

Этап 6. Опытная эксплуатация

После тестового контура интеграция запускается на реальных процессах.

И только после подтверждения стабильности переводится в промышленную эксплуатацию.

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

Почему мы рекомендуем начинать с MVP

В интеграционных проектах почти всегда возникает желание:

«Давайте автоматизируем сразу всё».

Но это увеличивает срок, бюджет и количество потенциальных ошибок.

Поэтому техническое задание предусматривает поэтапную модель.

Первый этап

Основной поток:

«Медкасса» → Битрикс24.

CRM получает:

• записи;
• статусы;
• визиты;
• неявки;
• услуги;
• оплаты.

Это уже позволяет создать значительную часть сквозной аналитики и автоматизации.

Второй этап

Подключается обратный поток:

Битрикс24 → «Медкасса».

CRM получает возможность:

• создавать пациента;
• создавать запись;
• выбирать свободный слот;
• передавать источник обращения;
• переносить или отменять запись.

Третий этап

При необходимости развиваются дополнительные сценарии:

• курсовое лечение;
• дополнительные финансовые контуры;
• псевдонимизация;
• расширенная аналитика.

Такой порядок этапов прямо рекомендуется в техническом задании проекта.

Как понять, что интеграция действительно работает

Главный показатель — не количество написанных API-методов.

И даже не отсутствие технических ошибок.

Успешная интеграция выглядит так:

Администратор

видит обращения и понимает, кому нужно перезвонить.

Регистратор

продолжает работать в привычной системе.

Кассир

принимает оплату как раньше.

CRM

автоматически знает, что произошло с пациентом.

Руководитель

видит всю цепочку:

обращение → запись → посещение → услуга → деньги.

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

Что получает медицинский центр после внедрения

В результате интеграции Битрикс24 и «Медкассы» организация получает не просто CRM.

Она получает единый коммерческий контур платных услуг.

До интеграции:

обращения находятся в одном месте, записи — в другом, деньги — в третьем.

После интеграции:

все этапы связаны между собой.

Результат:

• меньше потерянных обращений;
• контроль работы администраторов;
• прозрачная конверсия;
• автоматическая работа с неприходами;
• понимание эффективности рекламы;
• аналитика фактической выручки;
• автоматические напоминания;
• возможность возвращать пациентов на повторные услуги;
• меньше ручного ввода;
• меньше ошибок при переносе данных.

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

Об экспертах проекта

Profi Soft / Marketing Gid специализируется на внедрении CRM, интеграциях Битрикс24 с учётными и отраслевыми системами, автоматизации бизнес-процессов и разработке цифровых решений.

В документации данного проекта ТОО «Профи Софт» / Marketing GID выступает как Платиновый партнёр Битрикс24 в Республике Казахстан. Направление проекта включает внедрение CRM, интеграцию с «Медкассой», автоматизацию процессов и построение управленческой аналитики.

Подход Profi Soft строится вокруг цифровой трансформации бизнеса: CRM рассматривается не просто как база клиентов, а как центральная система управления процессами, продажами, коммуникациями и аналитикой. Такое позиционирование также отражено в корпоративных материалах компании.

Частые вопросы об интеграции Битрикс24 и «Медкассы»

Можно ли интегрировать Битрикс24 с «Медкассой»?

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

Нужно ли сотрудникам работать одновременно в двух программах?

В правильно спроектированном процессе — нет. Регистраторы и кассиры продолжают работать в «Медкассе», а необходимые статусы автоматически передаются в Битрикс24.

Можно ли записывать пациента прямо из CRM?

Да. Для этого «Медкасса» должна предоставить API свободных слотов и методы создания и изменения записи.

Что происходит после оплаты?

«Медкасса» передаёт в Битрикс24 информацию об оплате. CRM может автоматически обновить сумму сделки и завершить соответствующий бизнес-процесс.

Как система работает с неявками?

CRM получает событие о неявке, фиксирует её причину и может автоматически поставить сотруднику задачу связаться с пациентом.

Нужно ли переносить диагнозы в Битрикс24?

Нет. В проектируемой архитектуре медицинские сведения в CRM не передаются.

Можно ли начать только с части интеграции?

Да. Более безопасный подход — сначала настроить передачу данных из «Медкассы» в CRM, а после проверки стабильности подключать создание и изменение записей из Битрикс24.

Интеграция Битрикс24 и медицинской системы — это прежде всего бизнес-проект

Главная ошибка при подобных проектах — рассматривать интеграцию исключительно как работу программистов.

На самом деле всё начинается не с API.

Вопрос должен звучать иначе:

Что должно происходить с пациентом от момента первого обращения до оплаты и повторного визита?

После этого определяется роль каждой системы.

Битрикс24 управляет обращением, коммуникациями, напоминаниями, задачами и аналитикой.

«Медкасса» продолжает отвечать за профессиональный медицинский и кассовый контур.

Интеграция связывает эти два мира.

В результате сотрудники перестают вручную переносить информацию, руководитель получает прозрачную аналитику, а организация может управлять не отдельными звонками или посещениями, а полным жизненным циклом пациента.

Если вашей организации необходимо интегрировать Битрикс24 с медицинской, бухгалтерской, ERP- или другой отраслевой системой, Profi Soft / Marketing Gid может провести обследование бизнес-процессов, разработать архитектуру обмена и реализовать интеграцию под реальные рабочие сценарии компании.