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

Розробка порталу ветеринарної клініки: де ламається запис

У ветеринарній клініці вузьке місце — не лікування, а вхід до нього. У ранковий і вечірній пік реєстратура приймає дзвінки по одній лінії: частина викликів не дочікується відповіді, і власник або йде в іншу клініку, або відкладає візит.

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

Друга точка відмови — дані про тварину. Картка улюбленця живе одразу в трьох місцях: паперовий журнал на стійці, таблиця реєстратури й листування лікаря з власником.

Анамнез доводиться збирати заново, а дату наступної вакцинації не піднімає ніхто — нагадування не надходить, тварина приходить із простроченим щепленням.

Картка улюбленця онлайн знімає це: прийоми, призначення та щеплення прив'язані до одного профілю тварини й власника, і лікар бачить історію до початку огляду.

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

Навантаження на реєстратуру зростає з кожною новою адресою, бо філія додає ще одну неузгоджену таблицю, а не спільний календар.

Портал перевертає схему: запис на прийом через сайт потрапляє в ті самі вікна, які бачить лікар, правила доступності відсікають конфлікти, а нагадування про повторний візит і вакцинацію надходять самі — власнику в Telegram або коротким повідомленням.

Далі розбираємо, як це закривається частинами: модель розкладу, картка улюбленця, права співробітників і філій.

Що змінюється після запуску: запис, картки улюбленців, нагадування

Запуск порталу змінює щоденну механіку клініки: частина роботи реєстратури переходить у самообслуговування власників, а дані про прийом накопичуються в одному місці.

Ефект перевіряють за вимірюваними показниками, а не за загальним враженням — нижче перелік, за яким видно, що система справді працює.

• Цілодобовий запис. Власник сам обирає лікаря, філію та час. Метрика — час від відкриття форми до підтвердженого запису: за живої сітки це хвилини, а не цикл «передзвонимо в робочі години».
• Частка записів без дзвінка. Відношення самостійних бронювань до загальної кількості. Зростання показника знімає навантаження з адміністраторів у пікові ранкові години.
• Нагадування про вакцинацію та повторний візит. Надходять за розкладом у месенджер (Telegram) і на пошту. Метрика — частка доставлених і підтверджених нагадувань; за нею видно, скількох власників доводиться наздоганяти дзвінком.
• Історія лікування улюбленця. Картка прив'язана до власника, а не до окремого візиту. Метрика — частка прийомів, де лікар відкрив повну історію до огляду: вакцинації, призначення, минулі аналізи.
• Повторні візити. Метрика — частка власників, які повернулися в призначений лікарем строк. Нагадування з картки перетворює це з побажання на відстежуваний показник.
• Завантаження адміністраторів. Відношення числа дзвінків до числа прийомів. Зниження означає, що реєстратура займається складними випадками, а не перенесенням слотів.

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

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

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

Етапи робіт: від розбору процесів до передачі порталу

Портал ветеринарної клініки тримається не на інтерфейсі, а на зв'язці розкладу лікарів, карток тварин, складу та лабораторії.

Якщо схему даних проєктують після малювання екранів, спливають подвійне введення власника й тварини під час повторного прийому, розбіжність залишків препаратів із реальним складом і загублені курси лікування. Тому ми йдемо зворотним порядком: спочатку процеси й дані, потім форми та повідомлення.

1. Аудит процесів клініки. Проходимо прийом, стаціонар, вакцинацію, лабораторію та склад; фіксуємо ролі — адміністратор, лікар, асистент, власник тварини — і точки, де ті самі відомості вводять двічі або переносять з паперу.

2. Проєктування схеми даних. Описуємо картку власника, тварини, прийому, призначення та партії препарату, зв'язки між ними й правила доступу.

   На цьому етапі видно, які довідники потрібно звести до одного, щоб звіт із навантаження лікаря та витрати препаратів рахувався з одних джерел.

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

4. Приймальна перевірка на сценаріях. Прогоняємо те, що відбувається в клініці щодня: запис і перенесення, повторний прийом із курсом лікування, вакцинація з нагадуванням, списання препарату. Перевіряємо не кнопки, а результат у картці та на складі.

5. Навчання співробітників. Розбираємо сценарії за ролями, віддаємо короткі інструкції та чек-лісти. Черговий період супроводу закриває питання перших тижнів, поки співробітники працюють у новій схемі.

6. Передача порталу. Віддаємо документацію, доступи, регламент оновлень і порядок відкатів — підтримка залишається керованою без постійної участі авторів.

Що передаємо клініці: доступи, схеми, регламенти, інструкції

Передаємо не лише працюючий портал, а й усе, що потрібно для його самостійної експлуатації. Комплект збирається так, щоб адміністратор клініки розібрався в системі без звернень до нас, а сторонній інтегратор — без читання вихідного коду.

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

Передача йде з прийманням: проходимо сценарії з інструкції разом із вашим адміністратором і фіксуємо, що кожен пункт відтворюється без нашої участі.

Кейс: як мережа клінік прибрала чергу до реєстратури

Мережа ветеринарних клінік ВетГрад приймала записи по телефону й у паперових журналах: шість майданчиків, одна реєстратура на всіх.

У години пік лінія була зайнята, власник тварини не додзвонювався й ішов туди, де відповіли швидше — втрати виникали не на послузі, а на вході до клініки.

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

Що показували метрики до

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

Запис перенесли в портал: вибір майданчика, слота й лікаря, автоматичне підтвердження, нагадування та перенесення візиту без дзвінка. Реєстратура отримала загальну чергу звернень — заявка не губиться під час передачі зміни, до візиту підтягується історія тварини.

Окремо описали відкат: якщо портал недоступний, запис іде по телефону в той самий журнал, без подвійних слотів.

Що стало

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

Наступний крок у таких проєктах — не новий екран, а перенесення до тієї самої черги інших процесів клініки.

Що робити, якщо дані вже живуть в іншій системі?

Портал не вимагає зносити систему обліку — питання в тому, хто залишається джерелом правди щодо пацієнта, власника й рахунку. На практиці працюють три схеми: повне перенесення, двосторонній обмін і поступовий перехід контурами.

Повне перенесення даних клініки виправдане, коли облікова система не розвивається й зовнішніх зв'язків у неї немає. Історію вивантажують, зіставляють довідники, звіряють число записів і контрольні суми до й після імпорту. Мінус — вікно, у яке прийом ведуть на папері, а створене вручну потім переносять руками.

Двосторонній обмін із системою обліку обирають частіше: облікова система залишається головною, портал читає й пише через програмний інтерфейс. Запис, зроблений власником, потрапляє в розклад, а історія прийомів і рахунки повертаються в особистий кабінет.

Критичні ідемпотентність операцій і журнал розбіжностей: повторна заявка не створює дубль, а розбіжність видно й можна розібрати.

Поступовий перехід — шлях для випадку, коли зупиняти прийом не можна. Контури переходять по одному: спочатку онлайн-запис і кабінет власника, потім зв'язок із лабораторією — результати аналізів надходять прямо до кабінету, оминаючи дзвінки адміністратора. Прийом, склад і каса живуть у поточній системі, поки новий контур не доведе стабільність.

Ламається це зазвичай не на інтеграції, а на довідниках: послуги, породи й лікарі в двох системах названі по-різному.

Потрібен ключ зіставлення пацієнта — номер картки або чип — і регулярна звірка, інакше один улюбленець перетворюється на дві картки, а результат аналізу потрапляє не тому власнику.

Ролі, доступи та дані улюбленців: питання перед стартом

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

Скільки зберігаємо історію прийомів і дані власників?

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

Що буде в години пік, коли запис іде потоком?

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

Як портал обмінюється даними з лабораторією та бухгалтерією?

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

Що входить у супровід після запуску?

Моніторинг доступності, регламент реакції на збій, оновлення залежностей, резервні копії з перевіркою відновлення. Навчання адміністраторів і документація — частина запуску.

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

Щоб повернутися з оцінкою порталу та планом робіт за етапами, не потрібна специфікація на сто сторінок — достатньо опису, як клініка працює зараз: де ведеться запис і що досі робиться вручну.

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

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