Бот для записи к врачу: ссылка, администратор или API

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

Маршрут можно закончить тремя способами: открыть готовую форму, отправить запрос администратору или обратиться к системе через API. Ниже описана схема проектирования, а не кейс DevLab. Возможность интеграции всегда проверяют по документации и доступам конкретной клиники.

Общий сценарий без медицинской специфики разобран в статье «Telegram-бот для записи клиентов».

Три способа закончить маршрут записи

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

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

Уведомление администратору. Бот запрашивает только необходимые для связи данные и передаёт запрос сотруднику клиники. Пока сотрудник не ответил, запись не подтверждена. Выбрать свободное время мгновенно не получится, зато рядом с основной системой не появится второе расписание.

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

Что бот может показать до подтверждения

Telegram Bot API поддерживает сообщения и интерактивные кнопки. Mini Apps позволяют открыть внутри Telegram интерфейс для выбора услуги, специалиста и времени. У MAX тоже есть официальный API для сообщений, webhooks, кнопок и мини-приложений.

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

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

Почему API ещё не означает готовую интеграцию

При оценке важна не сама пометка «API», а операции, которые нужны для выбранного сценария:

• Можно ли получить услуги, сотрудников, филиалы и доступные окна.
• Можно ли создать, перенести и отменить запись.
• Как работает авторизация и какие права доступны аккаунту клиники.
• Есть ли webhooks или придётся опрашивать систему.
• Какие действуют лимиты и тарифные ограничения.
• Как система сообщает о повторной заявке и конфликте слота.
• Есть ли тестовый режим и способ безопасно восстановить ошибочную операцию.

YCLIENTS отдельно документирует ссылки, виджеты и формы онлайн-записи. Если бот просто открывает такую форму, это переход, а не API-интеграция. В открытой базе знаний DIKIDI нет подтверждения конкретных API-операций. Возможность автоматически создавать визиты нужно проверять по документации и доступам, которые DIKIDI предоставляет конкретной клинике.

Какие данные не стоит собирать в мессенджере

Даже выбор направления, врача и времени может раскрыть факт обращения за медицинской помощью. Для каждого сценария нужно отдельно определить состав данных и оставить только необходимый минимум. Диагноз, симптомы, результаты обследований и другие сведения о здоровье относятся к особо чувствительным данным. Их нельзя добавлять в обычный маршрут записи без отдельно проверенных оснований и мер защиты. Нужно учитывать специальные категории персональных данных по статье 10 152-ФЗ и врачебную тайну по статье 13 323-ФЗ.

Клиника как оператор персональных данных должна описать весь путь данных. В него входят мессенджер, система записи, разработчик, хостинг, уведомления, журналы, резервные копии, права доступа, сроки хранения и удаление. Поручение подрядчику проверяют по части 3 статьи 6 152-ФЗ. Первичную локализацию баз при сборе данных граждан РФ через интернет проверяют по части 5 статьи 18, а возможную трансграничную передачу отдельно по статье 12. Меры безопасности персональных данных описаны в статье 19.

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

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

Как проверить надёжность записи

До запуска каждый сценарий проверяют на синтетических данных. В тестах стоит воспроизвести такие ситуации:

• Два пользователя выбирают последний свободный слот одновременно.
• Внешняя система отвечает медленно или возвращает ошибку.
• Пользователь повторно нажимает кнопку подтверждения.
• Отмена прошла в боте, но не дошла до системы записи.
• Webhook пришёл дважды.
• Токен доступа истёк.
• Администратору нужно вручную повторить неудачную операцию.

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

Что подготовить клинике

• Систему, в которой хранится действующее расписание.
• Публичную ссылку на форму записи и описание текущего маршрута.
• Список услуг, филиалов и специалистов.
• Правила переноса и отмены.
• Минимальный состав данных пользователя.
• Контакт сотрудника для нестандартных и медицинских вопросов.
• Документацию API и тестовый доступ, если требуется интеграция.