Клиника на 1С:Медицина держит в ней расписание врачей, карты пациентов и учёт услуг — и логично, чтобы голосовой робот писал запись сразу туда, а не в отдельную табличку. Тогда администратор видит новый визит в привычном интерфейсе, а данные не расходятся между системами. Разбираем, как устроен обмен робота с 1С:Медицина, что он читает, что записывает и что стоит проверить перед подключением.
Интеграция робота с 1С:Медицина означает, что голосовой оператор берёт свободные слоты из расписания врачей в 1С, а результат разговора — запись, перенос или отмену — пишет обратно в ту же базу. Администратор работает в привычном интерфейсе и видит визиты, созданные роботом, наравне со своими. Данные живут в одном месте.
Смысл связки в том, чтобы не плодить второй контур учёта. Когда бот пишет прямо в 1С, не нужно вручную переносить записи из мессенджера или CRM в медицинскую систему и сверять их по вечерам.
Разберём по шагам, что робот читает из 1С, что туда записывает и какие поля карты пациента затрагивает.
Из 1С:Медицина робот читает сетку приёма: какие врачи работают, в какие часы у них свободны слоты, какие услуги доступны и сколько длится приём. На основе этого он предлагает пациенту реальные окна, а не абстрактные «позвоним позже». Актуальность важна: расписание в клинике меняется каждый день.
Чтение идёт в момент звонка, поэтому бот не предложит слот, который заняли минуту назад у стойки. Это убирает двойные записи на одно время.
Если врач заболел или добавил приём, робот увидит изменение при следующем обращении — отдельно синхронизировать ничего не нужно.
По итогу разговора робот создаёт в 1С запись на приём и привязывает её к карте пациента: фамилия, телефон, выбранный врач, услуга, дата и время. Если пациент новый, робот заводит карточку по подтверждённым голосом данным. Так визит появляется в системе сразу, без ручного ввода администратором.
Точность здесь критична: имя и телефон робот переспрашивает и подтверждает по цифрам, если распознал неуверенно. Распознавание речи держится около 98%, а спорные поля бот уточняет отдельно.
Медицинскую информацию — диагнозы, назначения — робот не трогает: он работает только с записью и контактными данными, а лечение остаётся за врачом.
Перед созданием записи робот ищет пациента в базе 1С по номеру телефона. Если карта уже есть, он привязывает визит к ней, а не создаёт вторую. Новая карта заводится только для действительно новых номеров. Так медицинская база не обрастает дублями, которые потом сливает администратор вручную.
Дубли карт — типичная беда клиник: у одного человека набегает по три карточки с разной историей. Поиск по телефону перед записью держит одного пациента в одной карте.
Если по номеру находится несколько карт, робот уточняет данные голосом или передаёт случай администратору — чтобы не привязать визит к чужой истории.
Робот умеет не только записывать, но и переносить или отменять визит: пациент звонит, называет себя, а бот находит его запись в 1С и меняет её. Освободившийся слот сразу возвращается в расписание и доступен другим. Это снимает с администратора рутину переносов, которых в клинике десятки в день.
Отмена за сутки вместо неявки — прямая выгода: слот успевает занять другой пациент. Робот ещё и напоминанием снижает долю забытых визитов.
Как настроить двусторонний обмен, чтобы изменения ходили в обе стороны без рассинхрона, разобрано в гайде про двустороннюю синхронизацию записей.
Обмен между роботом и 1С:Медицина идёт через программный интерфейс: бот отправляет запрос на список слотов и получает ответ, затем шлёт команду создать запись. Всё происходит за доли секунды во время разговора. Прямого доступа к базе 1С у робота нет — только оговорённый набор операций.
Такой подход безопаснее: робот не может изменить в 1С ничего, кроме записей и контактов, для которых ему выданы права. Медицинская часть базы недоступна.
Персональные данные пациентов при обмене передаются по защищённому каналу и хранятся в России — это требование 152-ФЗ к голосовым ботам, которое стоит проверить при любой интеграции.
Не в каждой конфигурации 1С:Медицина программный интерфейс включён из коробки. Тогда обмен настраивают через промежуточный модуль или выгрузку-загрузку данных по расписанию. Это медленнее живого обмена, но позволяет связать робота даже со «старой» базой без доработок ядра 1С.
Вариант с периодической синхронизацией подходит клиникам, где слоты не меняются каждую минуту. Расписание подгружается раз в несколько минут, и робот работает с ним.
Какой режим выбрать, зависит от нагрузки: для потока звонков нужен живой обмен, для небольшой клиники хватит регулярной выгрузки.
Роботу в 1С выдают отдельную учётную запись с ограниченными правами: читать расписание, создавать и менять записи, заводить карты пациентов. Права на медицинскую документацию, финансы и настройки системы ему не нужны. Такой минимальный доступ снижает риск и упрощает аудит действий бота.
Отдельная учётка ещё и делает прозрачным, что именно сделал робот: все его записи видны под его именем, их легко отфильтровать и проверить.
Разграничение ролей между врачом, администратором и роботом — базовая гигиена: каждый видит и меняет только своё.
После интеграции администратор видит в 1С полную картину: визиты, созданные роботом ночью и в выходные, стоят в расписании рядом с дневными. Не нужно переносить записи из другого канала и сверять их. Освобождается время, которое раньше уходило на ручной ввод и перезвоны по пропущенным.
Ключевое — данные полные: в систему попадают все обращения, включая те, что раньше терялись в нерабочее время, когда стойка не отвечала.
Экономику этой разгрузки — во сколько обходится регистратура против робота — мы разбирали в материале про экономику регистратуры.
Частые ошибки — не выделить роботу отдельную учётку, не настроить поиск по телефону и оставить обязательные поля, которые бот не может заполнить из разговора. Из-за первого путается аудит, из-за второго растут дубли карт, из-за третьего запись не создаётся. Все три лечатся аккуратной подготовкой базы.
Ещё одна ошибка — забыть про часовой пояс филиалов: если он задан неверно, робот предложит слот не в то время. Это стоит проверить на первых тестовых звонках.
Общий обзор граблей внедрения собран в материале про ошибки при внедрении бота.
Если в 1С:Медицина включён программный интерфейс, базовую связку настраивают за один-два подхода: выдать права, сопоставить услуги и врачей, проверить создание записи на тесте. Первые визиты появляются в 1С сразу на пробных звонках. Сложные конфигурации с доработками занимают дольше, до нескольких дней.
Разумно запустить робота сначала на приём звонков и запись, убедиться в чистоте карт, а потом подключать перенос и отмену. Так проще контролировать качество данных.
Само по себе подключение бота к телефонии и запуск занимают около 15 минут — основное время уходит на согласование логики записи.
После интеграции в 1С:Медицина видно, сколько записей создал робот, в какое время и на каких врачей. Отчёты собираются штатными средствами 1С по автору записи. Руководитель видит долю визитов, пришедших через бота, и загрузку специалистов без ручного подсчёта. Данные всегда актуальны, потому что записи ложатся в ту же базу.
Полезно смотреть срез по часам: заметная доля записей робота приходится на вечер, ночь и выходные — время, когда регистратура не работает. Это те визиты, что раньше терялись из-за молчащего телефона.
На тех же данных удобно оценивать эффект внедрения: сравнить поток записей до и после подключения робота за один и тот же период месяца.
Связка с 1С:Медицина полезна клиникам, которые уже ведут в ней расписание и учёт: многопрофильным центрам, стоматологиям, диагностическим лабораториям. Чем больше поток звонков и врачей, тем сильнее эффект от автоматической записи прямо в базу. Небольшой клинике связка тоже снимает вечернюю сверку.
Для сети из нескольких филиалов робот держит расписание всех точек и записывает пациента в нужную, ориентируясь по услуге и удобству. Как масштабировать на второй филиал, описано в отдельном гайде.
Протестировать связку можно бесплатно 7 дней без карты и посмотреть, как записи сами появляются в 1С:Медицина.
7 дней бесплатно, без карты. Подключение к вашему номеру за 15 минут.