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

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

Ниже схема выбора, а не кейс DevLab. Интеграцию всегда сверяют с документацией и доступами конкретной клиники. Общий сценарий без медицинской специфики есть в статье «Telegram-бот для записи клиентов».

Дерево решения: три маршрута

Ответьте по порядку. На первом «да» остановитесь.

1. Форма клиники удобна с телефона, расписание в ней актуально,
   и пациенту не нужно заново вводить уже известные данные?
   → Маршрут A: ссылка на форму

2. Нужен только запрос на связь, мгновенный слот не обязателен,
   а второе расписание рядом с основной системой нежелательно?
   → Маршрут B: уведомление администратору

3. Нужны свободные окна из системы записи и создание/перенос/отмена
   визита без ручной работы?
   → Маршрут C: API, но только после чеклиста ниже

Если ни один маршрут не подходит, сначала почините форму и процесс
в клинике. Бот не заменяет сломанную запись.

Маршрут A. Ссылка на действующую форму

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

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

Маршрут B. Запрос администратору

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

Подходит, когда поток небольшой, слоты часто двигают вручную или API недоступен. Важно сразу писать пациенту статус: «заявка принята, ждёт ответа», а не «вы записаны».

Маршрут C. API-интеграция

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

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

Чеклист до API

Пометка «есть API» сама по себе ничего не доказывает. Перед разработкой закройте каждый пункт:

• Есть операции: услуги, сотрудники, филиалы, доступные окна.
• Есть создание, перенос и отмена записи (или понятный отказ без них).
• Понятна авторизация и права аккаунта клиники на нужные действия.
• Известно, есть webhooks или нужен опрос системы.
• Известны лимиты запросов и тарифные ограничения.
• Система умеет сообщать о дубле заявки и конфликте слота.
• Есть тестовый режим и способ безопасно откатить ошибочную операцию.
• Решено, где единый источник расписания. Отдельная база бота без синхронизации повышает риск двойной записи.
• YCLIENTS: ссылка, виджет и форма это переход, а не API-интеграция. DIKIDI: конкретные операции сверяют по доступам клиники, а не по общим обещаниям.

Данные и границы бота простыми пунктами

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

• Собирайте только то, без чего нельзя связаться и поставить визит: имя, телефон, услуга, филиал, желаемое время.
• Не просите в обычном чате диагноз, симптомы, результаты обследований и другие сведения о здоровье.
• Даже выбор врача и направления может раскрыть факт обращения. Держите минимум полей.
• Опишите путь данных: мессенджер, система записи, разработчик, хостинг, уведомления, журналы, резервные копии, права, сроки хранения и удаление.
• Если данные обрабатывает подрядчик, зафиксируйте поручение, цели, меры защиты и порядок инцидентов (152-ФЗ, ч. 3 ст. 6).
• При сборе данных граждан РФ через интернет проверьте первичную локализацию баз (152-ФЗ, ч. 5 ст. 18) и отдельно любую передачу за рубеж (ст. 12).
• Бот не ставит диагноз, не выбирает лечение, не оценивает срочность и не говорит ждать ответа при признаках неотложного состояния. Для этого нужна отдельная инструкция клиники с путём к экстренной помощи.
• Учитывайте специальные категории персональных данных (152-ФЗ, ст. 10) и врачебную тайну (323-ФЗ, ст. 13).

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

Как проверить, что запись не врёт

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

На каждый шаг нужен журнал с техническим идентификатором без лишних персональных данных. Повторный запрос не создаёт второй визит. Статус «подтверждено» только после успешного ответа системы записи.

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

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

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