Розробка медичного порталу: де ламається запис і особистий кабінет
Розробка медичного порталу починається не з інтерфейсу, а з питання, хто володіє розкладом лікаря.
Якщо портал тримає власну копію сітки прийому, а облікова система клініки живе окремо, розбіжність видно вже першої доби: слот відкрили в реєстратурі, пацієнт зайняв його через запис до лікаря онлайн — і на ранок у кабінеті двоє людей на один час.
Причина зазвичай у способі синхронізації. Розклад лікарів підтягується пакетно раз на кілька хвилин, а бронювання йде напряму в базу порталу — вікно між оновленнями й створює подвійні записи.
На ранковому піку до цього додається авторизація пацієнта: якщо вхід, видача сітки й підтвердження броні ходять в один і той самий вузол, перший сплеск кладе і вхід, і запис одразу.
Далі вмикається людський контур. Пацієнти телефонують, навантаження на реєстратуру зростає, оператори переносять броні вручну — і породжують нові розбіжності, яких у системі не було.
Окрема причина — довідники, що розходяться: послуга, спеціальність, кабінет і тривалість прийому описані в двох місцях по-різному, і портал пропонує слот, який клініка не підтверджує.
Тому порядок робіт зворотний до звичного: спочатку єдине джерело істини щодо розкладу, потім розділення читання й запису, і лише потім особистий кабінет пацієнта.
Саме на цьому стику найчастіше ламається розробка медичного порталу — не у верстці, а в момент, коли ранковий потік сходиться з розкладом.
Що змінюється після запуску: час запису, навантаження, кількість відмов
До впровадження електронного запису шлях пацієнта до лікаря виглядав так: дзвінок у реєстратуру, пошук слота в розкладі, звірка з журналом, уточнювальні питання й зворотний дзвінок із підтвердженням — 6–8 дій і два-три дотики.
Після запуску той самий шлях стискається до трьох кроків: вибір спеціаліста, вибір вільного слота, підтвердження. Два з трьох кроків пацієнт робить сам, тому в пікові години, коли реєстратура фізично не встигає, запис продовжує йти.
Навантаження на реєстратуру знижується не «загалом», а за конкретним класом звернень: частка дзвінків саме про запис падає приблизно на дві третини. Залишаються перенесення, скасування й питання щодо документів — те, де потрібна людина, а не інтерфейс.
Диспетчер перестає бути вузьким місцем і перемикається на складні випадки замість механічного пошуку слотів.
Телемедичний прийом пишеться в той самий журнал візитів, що й офлайн-консультація: слот, статус, висновок.
Після прийому документи йдуть у медичну систему одним потоком — обмін побудований за FHIR, тому лікар не заповнює дві системи паралельно, а пацієнт бачить єдиний список своїх звернень незалежно від формату.
За доступністю сервісу запису зникає цілий клас відмов — втрата підтвердження. Слот резервується атомарно, повторне надсилання форми не створює другого запису, а за недоступності медичної системи заявка стає в чергу й дозаписується після відновлення.
Раніше на цьому місці стабільно з'являлися подвійні бронювання й відповіді «вас немає в розкладі» — тепер такі звернення просто не виникають.
Способи реалізації: з нуля, на готовій платформі, готовими модулями
Вибір шляху визначають не строки самі по собі, а те, скільки свободи залишиться після запуску. Якщо розклад прийомів, правила скасування й розподіл за квотами вкладаються в типову логіку, готова медична платформа закриває завдання швидше. Якщо сценарії запису нестандартні — власне ядро окупається вже на першій доробці.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Розробка з нуля | Нестандартні сценарії запису: мультифіліальність, квоти, власні правила перенесення й скасування, незвична логіка розкладу | Найдовше до першого релізу; інтеграцію з МІС, ролі лікарів і захищений документообіг проєктуємо й збираємо самі |
| Готова медична платформа | Потрібні запис, особистий кабінет і телемедицина в короткий строк за типових процесів клініки | Доробки впираються в можливості платформи: складний сценарій розкладу доводиться підганяти під її модель, а не навпаки |
| Збірка з модулів | Потрібен баланс: типове беремо готовим, унікальне — власним модулем | Основний ризик — на стиках: модулі запису, кабінету й МІС мають узгоджено трактувати слоти, статуси й дані пацієнта |
Головне вузьке місце в усіх трьох шляхах одне — інтеграція з МІС. Обмін розкладом, картками пацієнтів і статусами записів чутливий до розбіжностей форматів, тому схему обміну проєктуємо до першого рядка коду.
Розбираємо ваші сценарії запису, позначаємо, що закривається типовим, і лише після цього називаємо відповідний варіант.
Етапи впровадження: від аудиту процесів до передачі в експлуатацію
Впровадження починається не з макетів, а з розбору того, як запис іде зараз: скільки каналів прийому заявок, хто має право переносити й скасовувати візит, як ведуть розклад лікарі різних спеціальностей, у який момент дані зобов'язані потрапляти в МІС.
Аудит процесів запису розкриває вузькі місця — подвійне введення, загублені звернення, ручне підтвердження — і лише після нього з'являється техзавдання, а не навпаки.
Далі робота йде етапами, і кожен завершується артефактом, який можна перевірити до виходу на всіх пацієнтів.
- Обстеження: ролі співробітників, маршрути пацієнта, точки обміну з МІС і лабораторією, вимоги до зберігання медданих.
- Схема даних пацієнта: єдиний профіль, правила зіставлення дублів, розмежування доступу до чутливих полів, журнал звернень.
- Проєктування запису: сітка прийомів, правила скасування, лист очікування, захист слота від подвійного бронювання.
- Складання особистого кабінету й телемедицини: результати досліджень, призначення, оплата, відеоприйом із резервуванням каналу.
- Перевірка на реальних сценаріях: конфлікти розкладу, обрив зв'язку на відеоприйомі, недоступність МІС — портал поводиться передбачувано.
- Дослідна експлуатація на обмеженій групі пацієнтів і лікарів: звірка даних з МІС, замір часу відгуку за пікового навантаження.
- Передача в підтримку: регламент оновлень, порядок відкату, схема інтеграцій та інструкції для адміністраторів клініки.
Замовник на кожному кроці бачить не звіт про роботи, а перевірювану частину системи — до того, як вона торкнеться всіх пацієнтів.
Що залишається у замовника: схеми, регламенти, документація
Документація порталу ведеться не «до релізу», а паралельно з розробкою: кожен контур — запис на прийом, особистий кабінет пацієнта, обмін з МІС, телемедичні кімнати — отримує свою схему і свій регламент.
На виході замовник залишається з комплектом, за яким новий підрядник або штатний інженер може підняти систему, не розбираючи її на частини.
- Схема потоків даних: шлях заявки від форми на сайті до слота в розкладі, точки обміну з МІС, поведінка черги за недоступності зовнішньої системи й порядок повторного надсилання.
- Політики доступу лікарів: ролі й обсяг видимих карток, правило «свій пацієнт — чужа картка», журналювання кожного відкриття медкартки та строк зберігання цих журналів.
- Регламент резервного копіювання: що потрапляє в копію (база записів, вкладення досліджень, конфігурація сервісів), частота, глибина зберігання, відповідальний і підтверджений сценарій відновлення.
- Інструкції для реєстратури: подвійний запис, перенесення й скасування прийому, закриття зміни, що робити при втраті зв'язку з МІС і куди ескалювати.
- Інструкції для лікарів: робота з розкладом, вивантаження висновків, офлайн-порядок прийомів на випадок недоступності порталу.
- Конфігурації середовищ: склад сервісів, параметри обміну, змінні середовища, місця зберігання секретів і порядок їхньої ротації.
- Регламент оновлень і відкатів: вікна викочування, критерії повернення на попередню збірку та роль, що ухвалює це рішення.
Комплект живе поряд з кодом: правки до схеми та інструкцій вносяться в тих самих ітераціях, що й зміни в портал, тому документ не розходиться з реальністю через пів року.
Передаємо в читабельному вигляді — схеми, текстові регламенти, чек-листи приймання, — і проводимо навчання за ними.
Кейс: час запису скоротився втричі, навантаження на реєстратуру впало
Мережа з чотирьох філій прийшла з порталом, де запис ішов через одну форму: пацієнт вибирав спеціальність і залишав телефон, а розподіляла звернення реєстратура вручну.
Заміри до робіт: самостійно записувалися 18% пацієнтів, решта йшли через дзвінок; на один первинний прийом реєстратор витрачав у середньому 4 хвилини, а в ранкові пікові години частка відмов порталу сягала 11% — форма втрачала звернення при сплеску трафіку.
Що змінили
Розклад винесли в окремий сервіс із власним сховищем і чергою на запис, щоб сплески не блокували форму.
Зв'язали його з чинною МІС Инфоклиника двостороннім обміном: лікар закриває вікно прийому — воно одразу зникає з видачі порталу, а запис з особистого кабінету з'являється в розкладі лікаря без ручної звірки.
Вільні вікна почали показувати за філіями й конкретними лікарями, а не за спеціальністю загалом, додали перенесення й скасування без дзвінка.
Що стало після
Час запису знизився з 4 хвилин до 1 хвилини 20 секунд — втричі. Частка самостійних записів зросла з 18% до 54%, частка відмов форми на піку впала до 1,5%, а дзвінки з типових питань («чи є вікно», «перенесіть прийом») скоротилися приблизно на 40%.
Реєстратура перемкнулася на складні випадки й повторних пацієнтів — вузьке місце змістилося з прийому звернень на роботу із записами, які потребують розбору.
Заміри робили на зіставних вікнах спостереження — два тижні до запуску й два тижні після, щоб порівняння не змастила сезонність прийому.
Метрики збираються й зараз: час до підтвердження вікна й частка самостійних записів видні на загальній панелі, тому наступна ітерація порталу планується за даними, а не за відчуттями.
Чим портал відрізняється від сайту-візитівки клініки та від МІС?
Сайт-візитівка клініки — вітрина: напрями, лікарі, ліцензії, контакти. Запис тут зазвичай зведений до форми-заявки, яка йде адміністратору поштою або в таблицю, — розкладу й даних пацієнта в такій системі немає.
Портал — сервісний рівень над обліком: він показує реальні вікна прийому, дає особистий кабінет пацієнта з історією візитів, результатами, документами й оплатою.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Сайт-візитівка клініки | один кабінет, невеликий потік заявок | немає розкладу й особистого кабінету, усе тримається на адміністраторі |
| Сервіс запису | 1–3 філії, підбір «лікар і час» | немає історії прийомів, результатів і документів |
| Портал з особистим кабінетом пацієнта | мережа, повторні візити, телемедицина | потрібна інтеграція з обліковим контуром і захист даних |
| МІС | облік прийомів, медкартка, первинний документ | інтерфейс для співробітників, не розрахована на зовнішній потік |
Ключова різниця між цими наборами функціоналу — де лежить джерело істини. У МІС (наприклад, 1С:Медицина) фіксують прийом, призначення й підписані документи: це обліковий контур із юридичною значущістю та вузьким колом доступу. Портал до цих даних звертається, але не підміняє їх — віддає пацієнтові копію, а не оригінал.
Тому сайт, запис і особистий кабінет спокійно живуть в одному контурі: спільна база, єдина авторизація, один домен. Портал і МІС так не суміщають — обліковий контур ізолюють, а зв'язок іде через шар інтеграції.
Інакше зовнішній трафік і медичні дані опиняються в одній зоні ризику, а це вже вимоги 152-ФЗ до спецкатегорії персональних даних.
Часті технічні сумніви: розбір перед стартом
Технічна сторона клініки майже завжди приходить з одним набором питань: як портал сяде на чинну облікову систему, хто і що побачить у картці пацієнта, що станеться з базою під час переїзду і що відбудеться із записом, якщо частина інфраструктури випаде. Нижче — відповіді, які ми даємо до старту, щоб не з'ясовувати це на етапі запуску.
Це не обіцянки, а опис того, як влаштовані типові рішення. Якщо конфігурація відрізняється — розберемо ваш випадок окремо.
Як портал стикується з обліковою системою клініки?
Через окремий інтеграційний шар: ядро облікової системи не переписується. Вона залишається провідною, портал — вітриною розкладу й особистим кабінетом.
Вільні слоти, статуси прийомів і зміни карток ходять в обидва боки, а конфлікт за один слот гаситься на боці облікової системи, а не в інтерфейсі пацієнта.
Як розмежовуються права доступу?
Ролями з різним обсягом даних: пацієнт бачить лише свої документи, лікар — своїх пацієнтів у межах відділення, адміністратор — розклад без клінічних записів. Кожне відкриття картки потрапляє в журнал аудиту. Набір ролей змінюється налаштуванням, без доробки коду.
Як переносяться дані пацієнтів?
Вивантажуємо картки з поточної системи в структурованому вигляді, звіряємо кількість записів і ключові поля, переносимо в кілька проходів. Попередня система залишається доступною для читання, поки звірка не закриється, — тому відкат займає один крок.
Що буде із записом при збої?
Слот підтверджується з блокуванням, щоб одна комірка не пішла двом пацієнтам. За недоступності основного сегмента запис іде на резервний, а дія, яку не вдалося виконати одразу, стає в чергу. Поведінку перевіряємо навантажувальними прогонами, а не на словах.
Як захищені дані пацієнта?
Шифрування під час передавання й зберігання, доступ за короткоживучими токенами, обов'язковий другий фактор для співробітників. Персональні дані не йдуть в аналітику й зовнішні логи. Розмежування доступу та строки зберігання фіксуємо в політиці.
Обговоримо завдання: розберемо сценарії та повернемося з планом
Розмову починаємо з ваших сценаріїв, а не з шаблонної пропозиції: у медпорталі майже все визначається тим, як влаштовані потоки пацієнтів, розклад лікарів і правила доступу до медкарток.
- Ролі й сценарії: пацієнт, лікар, реєстратура, адміністратор клініки — хто які дії виконує і що бачить на екрані.
- Інтеграції: медична інформаційна система, лабораторія, платіжний сервіс, електронний підпис документів — що вже працює і в якому режимі доступний обмін.
- Дані й доступ: склад картки, права ролей, журнал дій, строки зберігання та вимоги до обробки персональних даних.
- Телемедицина: розклад консультацій, вікно скасування й перенесення, запис прийому, поведінка за слабкого каналу в пацієнта.
- Навантаження: пікові години запису, сезонні сплески, кількість одночасних консультацій і запас на зростання.
- Обмеження: що вже є на вашому боці, хто ухвалює рішення і які строки для вас критичні.
У відповідь надсилаємо план робіт за етапами з точками приймання, оцінку строків із запасом на інтеграції та погодження, склад команди й перелік ризиків, від яких залежить графік. Опишіть завдання — повернемося з оцінкою та планом.
