Це кейс про систему управління мережею багатопрофільних медичних центрів. За домовленістю із замовником ми не називаємо компанію і не публікуємо екрани, на яких видно персональні дані пацієнтів, співробітників чи звернень: ні телефонів, ні адрес електронної пошти. Усе описане нижче: архітектура та механіка, а не чужі дані.
Задача
У мережі медичних центрів одночасно живуть чотири різні світи: залучення і запис пацієнтів, клінічне ведення, кадри та фінанси. Зазвичай вони роз'їжджаються по трьох таблицях і месенджері. Маркетолог не знає, чи дійшло звернення до прийому. Завідувач філії не бачить завантаження середнього персоналу. Лікар веде призначення у власному файлі. А власник дізнається про збитковий місяць постфактум.
Багатопрофільність посилює кожен із цих розривів. Терапія, реабілітація, діагностика, психологія та дієтологія працюють за різними протоколами, з різною тривалістю прийому і різною вартістю години фахівця. Один загальний запис на прийом такої різниці не описує.
Що покриває перша фаза
- Центри та місця: філії, кабінети, місця денного і цілодобового перебування, розміщення пацієнта;
- CRM і прийом: звернення, події, статуси, перехід звернення в пацієнта;
- HRM: кандидати, співробітники, кваліфікації, графік змін і навантаження;
- Індивідуальний план ведення: потреби, ступені, призначення і породжувані ними задачі персоналу;
- Договори: договір, додаток, тип платника та друковані документи;
- Управління і P&L: dashboard, план і факт, доходи та витрати.
Ядро системи: як оцінка перетворюється на розклад робіт
Найзмістовніша частина проєкту це не картка пацієнта і не календар, а ланцюг, що пов'язує стан людини з конкретними задачами конкретних фахівців.
Клінічний стан описують таблиці потреб. У бойовій конфігурації їх шістнадцять, а всередині дев'яносто шість окремих потреб: рухливість, харчування, когнітивний статус, ризик падінь, больовий синдром тощо.
У кожної потреби є ступені вираженості: усього в довіднику їх двісті сімнадцять. Ступінь несе бал і належить групі рівня: низький, помірний, високий, критичний. Це дає не суб'єктивне «пацієнт важкий», а відтворювану шкалу.
Далі працює шар рекомендацій: триста сорок дев'ять правил вигляду «такий ступінь такої потреби потребує такого призначення». Саме він перетворює оцінку на план: система пропонує призначення з пріоритетом і ознакою обов'язковості, а лікар приймає або відхиляє.
Призначення беруться з каталогу медичних і сервісних дій: сто сімдесят чотири позиції, у кожної своя тривалість у хвилинах, вартість, ознака індивідуального чи групового виконання і правило частоти.
Хто має право виконати призначення
Каталог дій пов'язаний із довідником кваліфікацій: їх двадцять одна, від молодшої медичної сестри до лікаря. Зв'язків «дія-кваліфікація» у системі сто чотири, і у зв'язку два параметри: чи обов'язкова кваліфікація і який мінімальний стаж у місяцях потрібен.
Система не поставить процедуру у зміну людині, яка не має права її виконувати. У задачі, що потрапила в розклад, зберігається причина призначення: через півроку ніхто не гадає, чому пацієнту призначили саме цю процедуру.
План ведення як документ, а не як список задач
Індивідуальний план це версіонований документ. У нього є номер версії, строк дії, мета й очікуваний результат, дата обов'язкового перегляду, сумарний бал оцінки і дві відмітки підпису: з боку отримувача послуги та з боку закладу, з долученим файлом.
Де в цьому гроші
У кожної задачі в розкладі є планова і фактична вартість, планова і фактична тривалість. У співробітника: ставка і тип зайнятості. У філії: місткість і додаткові витрати. З цих полів збирається P&L, який рахується безперервно за фактично виконаними роботами, а не наприкінці місяця.
У договорі є тип платника, ціна за добу і ціна за договір, передоплата, відсоток знижки та відмітки про підписання й оплату. Самоплатник, страхова компанія і корпоративний клієнт обслуговуються однією моделлю.
Рольова модель як продукт, а не як галочка
У системі дванадцять ролей: суперадміністратор, директор, системний адміністратор, власник, адміністратор центру, HR-менеджер, маркетолог, лікар, середній медперсонал, бухгалтер, інвестор і кандидат.
Роль обмежує сторінки та дії, а прив'язка до філії обмежує видимі бізнес-об'єкти. Лікар бачить клініку і не бачить P&L, HR бачить персонал і не бачить пацієнтів. Єдине джерело правди про те, що бачить кожна роль, закрите автотестом.
Шлях кандидата у співробітника
Анкета працевлаштування відкрита гостю. Далі кандидат проходить співбесіду, і при наймі одна транзакція активує профіль співробітника, фіксує дату прийому, прив'язує його до філії та замінює роль доступу. Окремо зберігається кваліфікація, та сама, за якою система вирішує, які призначення можна поставити у зміну.
Вбудоване навчання
У кожного залогіненого користувача в шапці є кнопка навчання. Вона відкриває інструкцію саме для його ролі. Тест перевіряє, що в кожної ролі є інструкція і що кожен її крок веде лише на доступний цій ролі екран.
Безпека бойового контуру
Сервісний шлюз віддає назовні лише дії з явного реєстру, кожну зі своїм списком ролей і допустимих HTTP-методів; змінювальні дії приймаються лише POST-ом із CSRF-токеном. Інструменти розробника на бою вимкнені та закриті в robots.txt. База входить в обов'язковий список резервного копіювання і знімається кожні три години.
Наступний крок
Така архітектура переноситься на будь-яку мережу з об'єктами, персоналом і підопічними: багатопрофільні клініки, реабілітаційні та діагностичні центри, санаторії, мережі стоматологій. Починаємо з карти ролей і одного наскрізного сценарію: від звернення до закритої зміни.
Де подивитися
У проєкту немає публічної адреси: він працює локально або на закритому контурі. Показуємо його на демонстрації, за записом.
Схоже рішення: platFORMA - просунута система для відділів Вашої компанії.
