Онлайн-запись к врачу без чужого сервиса: расписание на своём сервере

MAATRIX

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

Что на самом деле продаёт агрегатор записи

Модель большинства сервисов онлайн-записи к врачу простая: они берут комиссию с каждой подтверждённой записи, а на странице врача показывают карточки других специалистов той же специальности — «похожие врачи», «также доступны сегодня» и подобные блоки. Это логично с точки зрения агрегатора: он зарабатывает на потоке, и ему выгодно, чтобы пациент до последнего оставался внутри платформы и выбирал из списка, а не уходил к конкретному врачу.

Для врача частной практики это означает две вещи. Во-первых, вы платите за записи, которые случились бы и без агрегатора — например, если пациент искал именно вас по имени. Комиссия берётся с оборота, а не с привлечения. Во-вторых, ваша карточка — это не ваша витрина: агрегатор в любой момент может изменить алгоритм показа, поднять комиссию, добавить рекламный блок конкурента прямо над кнопкой «записаться». Вы не контролируете ни оформление, ни то, кто окажется в поле зрения пациента в решающий момент.

Отдельная проблема — данные. Пациент оставляет агрегатору телефон, имя, повод обращения — иногда достаточно, чтобы понять диагноз. Эти данные уходят на серверы третьей стороны, и вы как врач не управляете тем, как они там хранятся и кому доступны. Тема хранения персональных данных пациентов на своей стороне отдельно и подробно разобрана в статье про карты пациентов и требования 152-ФЗ — здесь же речь именно про расписание и запись, но данные там тоже персональные, и подход к ним должен быть тем же.

Альтернатива: своя запись на своём домене

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

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

Технически задача сводится к трём частям: инструмент для расписания и бронирования, сервер, где он будет работать, и домен с почтой для напоминаний. Дальше — по порядку.

Cal.com: open source инструмент для записи

Для self-hosted записи разумный выбор — Cal.com: открытый проект, который делает ровно то, что нужно врачу частной практики — публичную страницу с доступными слотами, форму записи, синхронизацию с личным календарём (Google Calendar, CalDAV), email-напоминания и защиту от двойного бронирования одного и того же времени. Проект активно развивается, есть облачная версия, но нас интересует self-hosted вариант — код открыт, и его можно развернуть на своём сервере.

Из практики: Cal.com — это Next.js-приложение с базой PostgreSQL, ощутимо более тяжёлое, чем просто статическая форма записи. Для одного врача или небольшой практики хватает скромного сервера, но не самого минимального тарифа — конкретные цифры по памяти и процессору для этого стека разобраны отдельно в статье сколько RAM нужно для Cal.com, там же — типичные проблемы под нагрузкой.

Если вы уже используете Google Calendar или другой календарь для личного расписания, Cal.com синхронизируется с ним в обе стороны: заблокированное время в личном календаре автоматически скрывает слот от пациентов, а новая запись через форму появляется в календаре как обычное событие.

Разворачиваем Cal.com на арендованном сервере

Разворачивать вручную из исходников имеет смысл, только если вы планируете дорабатывать код. Для практической задачи проще поднять Cal.com через Docker Compose — так проект запускается предсказуемо и обновляется без пересборки вручную. Подробный пошаговый разбор установки — в статье как установить и настроить Cal.com на VPS, а готовый файл конфигурации — в материале Cal.com в Docker Compose. Здесь — минимальный набросок, чтобы понять структуру.

Понадобится сервер с Docker и Docker Compose, минимум одна база PostgreSQL и сам образ приложения:

services:
  db:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_USER: calcom
      POSTGRES_PASSWORD: замените_на_свой_пароль
      POSTGRES_DB: calcom
    volumes:
      - calcom-db:/var/lib/postgresql/data

  calcom:
    image: calcom/cal.com:latest
    restart: unless-stopped
    depends_on:
      - db
    environment:
      DATABASE_URL: postgresql://calcom:замените_на_свой_пароль@db:5432/calcom
      NEXTAUTH_SECRET: сгенерируйте_случайную_строку
      CALENDSO_ENCRYPTION_KEY: сгенерируйте_ещё_одну_строку
      NEXT_PUBLIC_WEBAPP_URL: https://запись.вашдомен.ru
    ports:
      - "3000:3000"

volumes:
  calcom-db:

Секреты (NEXTAUTH_SECRET, CALENDSO_ENCRYPTION_KEY) генерируются один раз перед первым запуском, например через openssl rand -base64 32, и дальше не меняются — их смена инвалидирует существующие сессии и часть зашифрованных данных. Пароль базы храните в переменных окружения или отдельном .env-файле, а не в самом compose-файле, если планируете держать конфиг в системе контроля версий.

После docker compose up -d приложение поднимается на порту 3000 внутри сервера — наружу его нужно отдавать уже через обратный прокси с HTTPS, о чём дальше. Если при первом запуске или обновлении что-то падает — от ошибок миграции базы до проблем с переменными окружения — частые причины и решения собраны в статье Cal.com на сервере: частые ошибки и решения.

Свой домен, HTTPS и напоминания пациентам

Публичная страница записи должна жить на вашем домене — не на поддомене платформы, не на IP-адресе сервера. Это и вопрос доверия пациента (адрес вида запись.вашаклиника.ru выглядит солиднее сгенерированной ссылки), и вопрос контроля: домен принадлежит вам, и его никто не отберёт вместе с аккаунтом на чужой платформе.

Перед сервером с Cal.com обычно ставят nginx или Caddy как обратный прокси с автоматическим TLS-сертификатом. Пример минимального блока для nginx:

server {
    listen 443 ssl;
    server_name запись.вашдомен.ru;

    ssl_certificate     /etc/letsencrypt/live/запись.вашдомен.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/запись.вашдомен.ru/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Сертификат выпускается через Let's Encrypt и certbot за одну команду; без HTTPS браузер будет пугать пациента предупреждением о небезопасном соединении прямо на форме, где вводятся имя и телефон, — для медицинской практики это недопустимо вдвойне.

Для email-напоминаний Cal.com нужен рабочий SMTP — можно использовать собственный почтовый сервер на том же VPS или внешний транзакционный сервис, если не хочется поднимать почту с нуля и разбираться с репутацией IP. SMS- или мессенджер-напоминания «из коробки» self-hosted версия не всегда даёт — если это критично, разумно добавить отдельного Telegram-бота, который дублирует напоминание о записи за сутки и за пару часов: тема хостинга такого бота на том же или соседнем сервере подробно разобрана в статье лучший VPS для Telegram-бота. Это уже надстройка сверху базовой системы записи, но именно она чаще всего снижает число неявок.

Персональные данные пациентов и что с ними не так на чужой платформе

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

Когда вы разворачиваете Cal.com на собственном сервере, вопрос снимается сам по себе: данные лежат в базе PostgreSQL на сервере, локацию которого вы выбрали сами, и доступ к ней настраиваете вы. Если сервер арендован в России, требование о хранении персональных данных граждан РФ на территории страны выполняется естественным образом — без дополнительных договоров с третьей стороной. Разбор требований подробнее — в статье где законно хранить сервер с персональными данными по 152-ФЗ.

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

Частые вопросы