Стоматология: онлайн-запись на сайте, которая не отдаёт данные пациентов третьим лицам

MAATRIX

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

Что на самом деле происходит при нажатии «Записаться»

Типичная схема, которую ставят большинству клиник за один вечер: на сайт вставляется <script> или <iframe>, который подгружает форму записи с домена стороннего сервиса. Внешне это выглядит как часть вашего сайта — тот же шрифт, тот же цвет кнопок, — но технически это чужая страница внутри вашей. Когда пациент заполняет поля и жмёт «Отправить», данные уходят не на ваш сервер, а на API этого сервиса:

Браузер пациента
   │  POST /api/booking
   ▼
booking-widget-vendor.example  ← чужой домен, чужая база данных
   │  (иногда) webhook / API-синхронизация
   ▼
Ваша CRM или Google-таблица администратора

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

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

Почему для стоматологии это особенно чувствительно

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

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

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

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

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

Технически это выглядит так:

• собственный VPS или выделенный сервер клиники;
• на нём — веб-приложение для онлайн-записи (готовое open-source решение или лёгкая форма собственной разработки);
• база данных (PostgreSQL или MySQL) на том же сервере, без внешних зависимостей;
• собственный домен или поддомен с TLS-сертификатом;
• бэкапы, которые лежат там, где скажете вы, а не там, где решил вендор.

Для небольшой клиники (1–5 кресел) с такой задачей уверенно справляется VPS с 2 vCPU и 4 ГБ памяти — нагрузка на систему записи минимальна, это далеко не интернет-магазин с тысячами одновременных посетителей. Из готовых open-source систем записи, которые можно развернуть на своём сервере, стоит посмотреть в сторону инструментов класса Cal.com или Easy!Appointments — оба распространяются с открытым кодом и рассчитаны на self-hosted установку, но перед выбором обязательно проверьте актуальную документацию конкретной версии: возможности и требования к серверу у таких проектов меняются от релиза к релизу.

Как это разворачивается: минимальная рабочая схема

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

1. Арендуйте VPS под задачу (2 vCPU / 4 ГБ RAM / 40+ ГБ SSD с запасом на рост базы записей — этого достаточно на старте, при необходимости диск и память масштабируются).
2. Настройте поддомен клиники и направьте его на IP сервера через A-запись в DNS.
3. Поднимите reverse-proxy с автоматическим TLS — это закроет и шифрование, и вопрос сертификата одним движением. Подробный пошаговый разбор есть в статье про установку и настройку Let's Encrypt на VPS.
4. Разверните само приложение записи и базу данных — проще всего через Docker Compose, чтобы не тянуть зависимости на голый сервер вручную.

Пример минимального docker-compose.yml для связки приложения записи и базы (названия сервисов и образ приложения замените на выбранное вами решение — здесь показана только структура):

version: "3.8"
services:
  booking-app:
    image: your-booking-app:latest
    restart: unless-stopped
    environment:
      - DATABASE_URL=postgres://booking:changeme@db:5432/booking
      - APP_URL=https://zapis.клиника.ru
    depends_on:
      - db
    networks:
      - internal

  db:
    image: postgres:16
    restart: unless-stopped
    environment:
      - POSTGRES_USER=booking
      - POSTGRES_PASSWORD=changeme
      - POSTGRES_DB=booking
    volumes:
      - ./pgdata:/var/lib/postgresql/data
    networks:
      - internal

networks:
  internal:
    driver: bridge

Обратите внимание: база данных не публикуется наружу (нет ports для db), доступ к ней есть только у приложения внутри той же docker-сети. Наружу через reverse-proxy отдаётся только сам веб-интерфейс записи.

Пример блока конфигурации nginx как reverse-proxy перед приложением:

server {
    listen 443 ssl http2;
    server_name zapis.клиника.ru;

    ssl_certificate     /etc/letsencrypt/live/zapis.клиника.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/zapis.клиника.ru/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8080;
        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;
    }
}

После этого форма записи открывается по вашему домену, а весь трафик — от первого символа в поле «Имя» до подтверждения записи — не покидает ваш сервер.

Что делать со старыми данными и переходным периодом

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

• выгрузите историю записей из старого сервиса, пока доступ к нему ещё есть (обычно это экспорт в CSV или доступ через API вендора — уточните в документации конкретного сервиса, которым вы пользовались);
• перенесите актуальную базу пациентов и предстоящих записей в новую систему;
• какое-то время подержите обе формы параллельно, если боитесь потерять записи в переходный период, но постепенно снижайте видимость старого виджета на сайте;
• после полного перехода — закройте аккаунт в стороннем сервисе и удалите оттуда данные, если функция удаления предусмотрена (запросите это отдельно, если в интерфейсе такой возможности нет);
• уберите со страницы записи все скрипты старого виджета целиком, а не только визуальную форму — иногда код аналитики вендора остаётся висеть на странице ещё долго после того, как саму форму заменили.

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

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

Дополнительные меры: не только форма записи

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

• онлайн-чаты и кнопки мессенджеров — часто тоже подгружают код с чужого домена и логируют переписку на серверах провайдера чата;
• карты (встроенная карта проезда) — как правило, безобидны, но тоже технически загружают скрипт с внешнего домена и передают ему данные о посетителе;
• системы аналитики и рекламные пиксели — не собирают напрямую медицинские данные, но вместе с формой записи на одной странице создают более полную картину поведения конкретного посетителя, если объединить данные разных сервисов.

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

На собственном сервере стоит сразу настроить и организационную сторону вопроса:

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

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