Разработка портала для ветеринарной клиники

Разработка портала ветеринарной клиники: где ломается запись

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

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

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

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

Что меняется после запуска: запись, карты питомцев, напоминания

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

• Круглосуточная запись. Владелец сам выбирает врача, филиал и время. Метрика — время от открытия формы до подтверждённой записи: при живой сетке это минуты, а не цикл «перезвоним в рабочие часы».
• Доля записей без звонка. Отношение самостоятельных бронирований к общему числу. Рост показателя снимает нагрузку с администраторов в пиковые утренние часы.
• Напоминания о вакцинации и повторном визите. Уходят по расписанию в мессенджер (Telegram) и на почту. Метрика — доля доставленных и подтверждённых напоминаний; по ней видно, сколько владельцев приходится догонять звонком.
• История лечения питомца. Карта привязана к владельцу, а не к отдельному визиту. Метрика — доля приёмов, где врач открыл полную историю до осмотра: вакцинации, назначения, прошлые анализы.
• Повторные визиты. Метрика — доля владельцев, вернувшихся в назначенный врачом срок. Напоминание из карты превращает это из пожелания в отслеживаемый показатель.
• Загрузка администраторов. Отношение числа звонков к числу приёмов. Снижение означает, что регистратура занимается сложными случаями, а не переносом слотов.

Варианты реализации портала: шаблон, модуль, своя разработка

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

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

Этапы работ: от разбора процессов до передачи портала

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

1. Аудит процессов клиники. Проходим приём, стационар, вакцинацию, лабораторию и склад; фиксируем роли — администратор, врач, ассистент, владелец животного — и точки, где одни и те же сведения вводят дважды или переносят с бумаги.

2. Проектирование схемы данных. Описываем карточку владельца, животного, приёма, назначения и партии препарата, связи между ними и правила доступа. На этом этапе видно, какие справочники нужно свести к одному, чтобы отчёт по нагрузке врача и расходу препаратов считался из одних источников.

3. Настройка обменов данными. Подключаем лабораторное оборудование, кассу, бухгалтерию и напоминания владельцам. Каждый обмен получает журнал и повтор при сбое, поэтому сбой на стороне внешней системы не блокирует приём.

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

5. Обучение сотрудников. Разбираем сценарии по ролям, отдаём короткие инструкции и чек-листы. Дежурный период сопровождения закрывает вопросы первых недель, пока сотрудники работают в новой схеме.

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

Что передаём клинике: доступы, схемы, регламенты, инструкции

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

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

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

Кейс: как сеть клиник убрала очередь в регистратуру

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

Разбираем кейс с метриками до и после: так видно, что именно меняет портал, а не общее «стало удобнее».

Что показывали метрики до

• без звонка оформлялось 27% записей, и те — без подтверждения слота и врача;
• 21% напоминаний о визите не доходило до владельца: часть отправляли вручную, часть терялась между сменами;
• медиана времени до ответа клинике — около пяти часов в рабочие дни и к следующему утру в выходные;
• отказы класса «не дозвонился, не дождался» — каждый восьмой входящий контакт.

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

Что стало

• записей без звонка — 74%, рутинные подтверждения ушли с регистратуры;
• медиана ответа клинике — минуты вместо часов, включая выходные;
• напоминания доходят в 97% случаев, пропущенных визитов и отказов «не дозвонился» стало в разы меньше.

Следующий шаг в таких проектах — не новый экран, а перенос в ту же очередь остальных процессов клиники.

Что делать, если данные уже живут в другой системе?

Портал не требует сносить систему учёта — вопрос в том, кто остаётся источником правды по пациенту, владельцу и счёту. На практике работают три схемы: полный перенос, двусторонний обмен и постепенный переход контурами.

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

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

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

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

Роли, доступы и данные питомцев: вопросы перед стартом

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

Сколько храним историю приёмов и данные владельцев?

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

Что будет в часы пик, когда запись идёт потоком?

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

Как портал обменивается данными с лабораторией и бухгалтерией?

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

Что входит в сопровождение после запуска?

Мониторинг доступности, регламент реакции на сбой, обновления зависимостей, резервные копии с проверкой восстановления. Обучение администраторов и документация — часть запуска.

Обсудим задачу: процессы, данные и точки интеграции

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

• Процессы. Запись на приём и вызов врача на дом, вакцинация, стационар, продажа препаратов и корма — что переносим в портал, а что оставляем на ресепшене.
• Системы и перечень интеграций. Учёт приёмов, лаборатория, склад, касса, телефония, мессенджеры — с чем портал должен обмениваться данными и в какую сторону.
• Роли и права. Администратор ресепшена, врач, ассистент, владелец животного, руководитель — кто что видит, меняет и подтверждает.
• Пиковая нагрузка. Сколько записей в час в сезон, сколько сотрудников работает одновременно, что происходит в день акции или вспышки заболевания.
• Требования к отчётности. Какие срезы нужны руководителю: загрузка врачей, отказы по записи, повторные визиты, остатки на складе.
• Данные. Персональные данные владельцев, история приёмов, справочник услуг и цен — что переносим из текущих таблиц, а что остаётся в учётной системе.
• Ограничения. Сроки запуска, кто согласует изменения, какие внешние подрядчики участвуют и куда у них есть доступ.

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