Автоматизация стоматологии: план лечения без потерь

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

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

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

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

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

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

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

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

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

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

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

Что означает «архитектура, а не косметика»: разграничение доступа по ролям на уровне базы данных, а не галочкой в интерфейсе; журнал обращений к записям, по которому видно, кто и когда открывал карту; учёт согласий и сроков хранения; организационные и технические меры защиты по статье 19 закона 152-ФЗ; размещение баз с данными граждан РФ на серверах в России — это требование части 5 статьи 18 того же закона. Всё это закладывается на этапе проектирования, потому что дописать журнал доступа в готовую систему постфактум обычно дороже, чем спроектировать его сразу.

Похожую архитектуру мы прорабатывали в собственном проекте МИС — это смежный медицинский, а не стоматологический кейс, и он честно находится в статусе MVP, а не коробочного релиза. Цифры оттуда относятся именно к этому проекту: чтобы не изобретать предметную область заново, мы разобрали работающий аналог — 1613 таблиц базы и 1029 роботов — и собрали ТЗ воспроизведения на 1619 требований. Мультитенантность там сделана через PostgreSQL RLS (row-level security — изоляция данных на уровне самой СУБД, а не условием WHERE в коде), а контур 152-ФЗ заложен в архитектуру: согласия, аудит доступа, сроки хранения. В MVP есть медкарта врача с зубной формулой — то есть стоматологическая специфика в модели данных учтена, но выдавать это за внедрённый проект в стоматологии мы не будем.

Если вам нужен именно разбор выбора между CRM, МИС и их связкой — он уже есть в отдельной статье журнала про CRM для клиники и 152-ФЗ. Здесь мы сознательно не повторяем её и остаёмся в стоматологической специфике: этапность плана, точки отвала, загрузка кресел.

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

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

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

Отдельно про экономику: голосовой AI имеет смысл там, где есть поток пропущенных звонков и обзвонов. Если у вас два кресла и десять звонков в день, честнее начать с напоминаний в мессенджере и нормально настроенной онлайн-записи, а голосовой контур отложить. Мы говорим об этом на аудите прямо — в журнале есть отдельные разборы стоимости голосового робота и связки онлайн-записи с CRM.

Автоматизация в медицине упирается не только в технику, но и в границы допустимого. Ниже — вещи, которые мы не настраиваем клиникам, даже когда об этом просят, и объясняем почему.

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

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

Третье: диагноз или детали лечения в тексте напоминания. Сообщение видно на экране заблокированного телефона — иногда не только владельцу. «Напоминаем о визите 16 августа в 14:30» безопасно. Указание процедуры и тем более диагноза — уже нет.

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

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

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

Параллельно решается вопрос границы: что остаётся в коммерческом контуре, а что уходит в медицинскую систему. От этого зависит и архитектура, и бюджет, и то, насколько спокойно клиника проходит проверку. Мы делаем обе части — настройку Битрикс24 под процессы клиники и разработку отраслевых медицинских систем с контуром 152-ФЗ, — поэтому не заинтересованы продать вам ту половину, которая вам не нужна.

Стоимость называем после бесплатного экспресс-аудита на 30 минут: она зависит от числа кресел и врачей, набора каналов обращений, нужна ли интеграция с уже стоящей у вас программой, требуется ли голосовой контур и переносится ли база пациентов. На том же аудите честно скажем, если задача закрывается настройкой того, что у вас уже есть, и внедрение можно отложить.