Автоматизация 14 медцентров: план лечения, схема тела и платёжная система FINIK

Кейс: Автоматизация сети клиник лечения позвоночника — план лечения, схема тела и платёжная система в Битрикс24

О клиенте

Клиника Ратинова — сеть из 14 медицинских центров в России, Казахстане и Кыргызстане, специализирующаяся на безоперационном лечении межпозвоночной грыжи методом модулируемой резорбции. Основатель — Андрей Сергеевич Ратинов, невролог-вертебролог с многолетней практикой. Клиника принимает более 175 пациентов в день, за всё время помогла более 90 000 человек. С 2025 года — официальный медицинский партнёр национального олимпийского комитета Киргизии.

Особенность бизнес-процессов: пациент проходит курс из 10–14 процедур, каждая услуга привязана к конкретной зоне тела и дню лечения. Услуги продаются пакетами — 5, 7 или 10 сеансов. Оплата принимается в Кыргызстане через местную платёжную систему FINIK (AversPay), встроенные решения Битрикс24 для этого региона не работают.

С чем пришли: 5 болевых точек

1. Ручное планирование лечения. Врач на приёме записывал план на бумаге: список процедур, дни, зоны воздействия. Медсестра потом вручную сверяла график. При изменении плана (замена услуги, перенос дня) бумажка переписывалась, старая версия терялась.

2. Разрозненный учёт оплат и выполненных процедур. Оплата фиксировалась в счетах, выполнение — в отдельной таблице. Не было связи «оплатил 7 сеансов — посетил 3 — осталось 4». Медсестра не видела, какие услуги оплачены, а какие нет. При возврате одного сеанса из пакета ломалась вся арифметика.

3. Отсутствие привязки процедуры к зоне тела. Врач указывал зоны воздействия текстом в комментарии. Медсестра могла перепутать «плечевой сустав левый» с «плечевой сустав правый». Не было визуального контроля: ни врач при назначении, ни медсестра при выполнении не видели схему тела с отмеченными зонами.

4. Платёжная система не работает в Кыргызстане. Встроенные платёжные решения Битрикс24 не поддерживают кыргызстанские эквайринги. Клиника не могла отправлять пациентам ссылки на оплату через FINIK — местную систему QR-платежей. Приходилось выставлять счета вручную и ждать подтверждения из банка.

5. Высокие требования к скорости. В карточке сделки нужно показывать десятки сущностей одновременно: счета, коммерческие предложения, строки товаров, планы лечения. Без продуманной архитектуры загрузка такого объёма данных заняла бы около минуты — недопустимо для врача, который ведёт приём в реальном времени. При открытии вкладки «План лечения» в карточке сделки загрузка данных занимала 53 секунды. Причины: последовательные REST-запросы к Битрикс24 API (каждый счёт, каждое КП, каждая строка товара запрашивались отдельно), отсутствие кэширования справочников.

Решение 1. Редактор плана лечения: от бумажки к интерактивной сетке

В карточку сделки воронки «Приём врача» добавлена вкладка «Лечение». Врач выбирает услуги из каталога товаров, указывает дни выполнения в 14-дневной сетке и настраивает зоны воздействия.

Механика: услуги подгружаются из каталога товаров Битрикс24 — всегда актуальный список, деактивированные позиции скрыты. Для каждой услуги врач проставляет дни: нажатие «+» в ячейке добавляет сеанс, «−» убирает. План сохраняется единым JSON-объектом в пользовательское поле сделки. При сохранении автоматически синхронизируются товары сделки — вкладка «Товары» заполняется по стандартной схеме Битрикс24 (номенклатура + количество).

Результат: врач формирует план лечения за 2–3 минуты вместо заполнения бумажного бланка и отдельного внесения товаров в сделку. Все версии плана хранятся в истории поля сделки

, а не на глаз — погрешность позиционирования менее 3% от размера схемы. При выборе зоны врачом на схеме загорается кружок с номером зоны. Список из 43 чекбоксов дублируется слева от схемы — можно выбрать как кликом по телу, так и отметкой в списке.

При сохранении плана список зон записывается в тот же JSON вместе с днями. На вкладке «Лечение» медсестра видит общую схему тела: все зоны из всех услуг плана наложены на одно изображение. Одинаковые зоны разных услуг показываются одним кружком. При наведении на кружок — подсказка: название зоны и список услуг, которые на неё назначены. Под названием услуги в таблице выводятся компактные бейджи с номерами зон.

Результат: врач видит зоны воздействия в момент назначения, медсестра — перед выполнением. Исключена путаница «левое/правое», «латеральная/медиальная».

. Ячейки окрашены по статусу:

• Синий — «Оплачен» (услуга куплена, ожидает выполнения)
• Зелёный — «Выдан» (процедура выполнена, отмечена медсестрой)
• Оранжевый — «Возврат» (оплата отменена, процедура не оказывается)
• Серый — «Не оплачен» (услуга в плане, но не куплена)

Медсестра нажимает на синюю ячейку оплаченного дня — открывается попап «Отметить выдачу». В нём уже подставлен врач из основной сделки (поле UF_CRM_1730267788), указана текущая дата. Если нужно — дату можно изменить: процедуру, выполненную вчера, медсестра отмечает задним числом (актуально при сбоях интернета или портала). При подтверждении создаётся смарт-процесс (entityTypeId=1122), в который записываются:

• Услуга
• Врач (из основной сделки)
• Медсестра (текущий пользователь, нажавший кнопку)
• Счёт, с которого списана оплата
• Медцентр, оказавший услугу
• Медцентр, продавший услугу
• Дата плановая и дата фактическая

Повторное нажатие на уже выданную ячейку невозможно — она заблокирована. Неоплаченные и возвратные ячейки также неактивны.

Результат: медсестра видит полную картину по пациенту за 2–3 секунды после открытия вкладки. Никаких отдельных таблиц и сверок.

ранее возникала ошибка: возврат обнулял все оплаченные услуги до статуса «Не оплачен». Например: куплено 5 сеансов, 1 выполнен, сделан возврат 1 сеанса — система показывала 0 оплаченных вместо 4.

Исправленная логика: возврат гасит оплаченные единицы с конца списка. Выданные (уже оказанные) процедуры возврат не трогает. Если возврат больше остатка оплаченных — излишек идёт на неоплаченные с конца. В интерфейсе возвратные дни отмечены оранжевым цветом и заблокированы для выдачи.

Результат: арифметика всегда сходится. Куплено 5, возврат 1, выполнено 2 → 2 оплаченных ждут выдачи, 1 возврат.

Решение 5. Платёжная система FINIK через AversPay

Для приёма оплат в Кыргызстане разработан модуль интеграции с AversPay — местным эквайрингом, поддерживающим QR-платежи через систему FINIK.

Схема работы: при выставлении счёта в Битрикс24 формируется запрос к API AversPay. Платёж подписывается RSA-ключом (приватный ключ хранится на сервере). В запросе передаются: сумма, ID сделки, название медицинского центра, ФИО пациента, список услуг. После оплаты AversPay отправляет вебхук на endpoint приложения — оплата автоматически проводится в Битрикс24.

Результат: клиника получила ссылки на оплату, которые можно отправлять пациентам по SMS. Оплата проводится за 2–3 минуты вместо ручного подтверждения из банка.

Решение 6. SMS-уведомления

Настроена отправка SMS со ссылками на оплату. Пациент получает сообщение, переходит по ссылке, оплачивает QR-кодом через FINIK. После оплаты статус счёта в Битрикс24 обновляется автоматически.

Решение 7. Производительность: архитектура быстрой загрузки с первого дня

С самого начала мы заложили архитектуру, исключающую долгую загрузку. В карточке сделки одновременно отображаются счета, коммерческие предложения, строки товаров и план лечения — при 5 КП и 10 счетах это десятки сущностей, которые нужно показать мгновенно.

Ключевые решения, заложенные в архитектуру:

• Пакетная загрузка данных — до 20 одновременных запросов к API Битрикс24
• Кэширование справочников и фильтров — повторные обращения не тратят время
• Переиспользование загруженных данных между разными этапами обработки
• Исключение дублирующих вызовов — строки счетов загружаются один раз для всей карточки
• Параллельная загрузка товарных позиций по разным коммерческим предложениям

Результат: frontend получает все данные одним контекстным запросом. Вкладка открывается быстро даже при большом количестве сущностей в сделке — врач не ждёт, а сразу работает.

Итоги проекта

Показатель	До	После
Формирование плана лечения	10–15 минут (бумажный бланк + ручной ввод товаров)	2–3 минуты (интерактивная сетка)
Сверка оплат и выполненных процедур	Медсестра вручную сверяла таблицы	Один экран с цветовой индикацией
Ошибки зон воздействия	Текстовое описание, риск перепутать сторону	Визуальная схема тела с 43 зонами
Приём оплат в Кыргызстане	Ручное подтверждение из банка	Автоматический вебхук за 2–3 минуты
Открытие вкладки «План лечения»	Была бы около минуты при последовательных запросах	Оптимизировано (батчинг + кэширование)
Возвраты	Ломали арифметику оплат	Корректный учёт с цветовой индикацией
История изменений плана	Терялась (бумажка переписывалась)	Полная история в JSON-поле сделки

Типичные ошибки в похожих проектах

1. План лечения = просто таблица в Excel. Самая частая ошибка — сделать красивую таблицу без связи с реальными сущностями CRM. Врач заполняет план, а товары в сделку не попадают. Медсестра отмечает выполнение, а смарт-процесс не создаётся. Каждый блок должен быть связан двусторонней синхронизацией: план → товары сделки, отметка факта → смарт-процесс с полным набором полей.

2. Возвраты без проверки уже выполненных процедур. Если система не различает «оплачено, но не сделано» и «оплачено и сделано», возврат сломает учёт. Нельзя просто уменьшать счётчик оплаченных услуг — надо знать, какие из них уже оказаны и не подлежат возврату.

3. Игнорирование региональных платёжных систем. Встроенные решения хороши для РФ, но как только клиника выходит за пределы России — нужна интеграция с местным эквайрингом. Причём не просто приём платежа, а полный цикл: ссылка на оплату → вебхук → проведение в CRM. Без этого клиника возвращается к ручному учёту.

4. Одинаковое визуальное отображение всех статусов. Когда «оплачено», «выдано», «возврат» и «план» выглядят одинаково, медсестра тратит время на чтение текста вместо мгновенного считывания цвета. Цветовое кодирование критично для медицины: оранжевый = не трогать, зелёный = сделано, синий = можно отмечать.

5. Последовательные REST-запросы без батчинга. Когда в карточке сделки нужно показать 5 КП, 10 счетов и 50 строк товаров, нельзя делать 65 последовательных запросов к Битрикс24 API. Батчевые запросы и кэширование — не «оптимизация на будущее», а обязательный этап проектирования.

Заключение

Проект для клиники Ратинова показал, что даже глубоко заточенное под медицину решение не требует разработки с нуля. Битрикс24 дал каркас: сделки, товары, счета, смарт-процессы, роботов. Поверх каркаса построен предметный слой: план лечения с сеткой дней, схема тела с 43 зонами, платёжная интеграция FINIK, SMS-уведомления.

Решающим обстоятельством стал не объём автоматизации, а точность стыковки блоков. План лечения синхронизирован с товарами сделки. Отметка медсестры создаёт смарт-процесс с полным набором полей. Возврат корректно гасит оплаченные единицы. Зоны тела выбраны врачом — и тут же видны медсестре. Каждый блок знает о соседнем, и ни один не живёт сам по себе.

Клиника получила систему, в которой врач, медсестра и администратор работают в единой среде. Пациент — от первого приёма до последней процедуры — проходит по цепочке, которую видно целиком.