Это кейс о системе управления сетью многопрофильных медицинских центров. По договорённости с заказчиком мы не называем компанию и не публикуем экраны, на которых видны персональные данные пациентов, сотрудников или обращений: ни телефонов, ни адресов электронной почты. Всё описанное ниже — архитектура и механика, а не чужие данные.
Задача
В сети медицинских центров одновременно живут четыре разных мира: привлечение и запись пациентов, клиническое ведение, кадры и финансы. Обычно они разъезжаются по трём таблицам и мессенджеру. Маркетолог не знает, дошло ли обращение до приёма. Заведующий филиалом не видит загрузку среднего персонала. Врач ведёт назначения в своём файле. А владелец узнаёт про убыточный месяц постфактум, когда закрыть его уже нечем.
Многопрофильность усиливает каждый из этих разрывов. Терапия, реабилитация, диагностика, психология и диетология работают по разным протоколам, с разной длительностью приёма и разной стоимостью часа специалиста. Одна общая запись на приём такую разницу не описывает.
Что покрывает первая фаза
- Центры и места — филиалы, кабинеты, места дневного и круглосуточного пребывания, размещение пациента;
- CRM и приём — обращения, события, статусы, переход обращения в пациента;
- HRM — кандидаты, сотрудники, квалификации, график смен и нагрузка;
- Индивидуальный план ведения — потребности, степени, назначения и порождаемые ими задачи персонала;
- Договоры — договор, приложение, тип плательщика и печатные документы;
- Управление и P&L — dashboard, план и факт, доходы и расходы.
Ядро системы: как оценка превращается в расписание работ
Самая содержательная часть проекта — не карточка пациента и не календарь, а цепочка, которая связывает состояние человека с конкретными задачами конкретных специалистов. Она устроена так.
Клиническое состояние описывается таблицами потребностей. В боевой конфигурации их шестнадцать, и внутри них — девяносто шесть отдельных потребностей: подвижность, питание, когнитивный статус, риск падений, болевой синдром и так далее. Каждая потребность принадлежит категории и может быть обязательной для заполнения.
У каждой потребности есть степени выраженности — всего в справочнике их двести семнадцать. Степень несёт балл и принадлежит группе уровня: низкий, умеренный, высокий, критический. Это даёт не субъективное «пациент тяжёлый», а воспроизводимую шкалу, по которой два разных специалиста придут к близкой оценке.
Дальше работает слой рекомендаций — триста сорок девять правил вида «такая степень такой потребности требует такого назначения». Именно он превращает оценку в план: система не ждёт, пока врач вспомнит весь протокол, а предлагает назначения с приоритетом и признаком обязательности. Врач принимает или отклоняет, но отправной точкой служит правило, а не память.
Назначения берутся из каталога медицинских и сервисных действий: сто семьдесят четыре позиции, у каждой своя длительность в минутах, стоимость, признак индивидуального или группового исполнения и правило частоты — сколько раз в день, с каким интервалом, в какие дни недели.
Кто имеет право выполнить назначение
Каталог действий связан со справочником квалификаций — их двадцать одна, от младшей медицинской сестры до врача, и у каждой есть уровень. Связей «действие — квалификация» в системе сто четыре, и у связи два параметра: обязательна ли квалификация и какой минимальный стаж в месяцах требуется.
Практический смысл простой: система не поставит процедуру в смену человеку, который не имеет права её выполнять. Это снимает целый класс управленческих ошибок, который в сети из нескольких филиалов обнаруживается обычно при проверке, а не при планировании.
У задачи, попавшей в расписание, хранится причина назначения. Когда её сгенерировало правило, в поле записывается, какое именно. Через полгода никто не гадает, почему пациенту назначили эту процедуру.
План ведения как документ, а не как список задач
Индивидуальный план — версионируемый документ. У него есть номер версии, срок действия, цель и ожидаемый результат в текстовом виде, дата обязательного пересмотра, суммарный балл оценки и две отметки подписи: со стороны получателя услуги и со стороны учреждения, с приложением файла.
Это принципиально для медицинского контура. План — это то, что предъявляется при проверке и в спорной ситуации. Версия и подпись отвечают на вопрос, какая редакция действовала в конкретный день, а срок пересмотра не даёт плану тихо устареть.
Где в этом деньги
У каждой задачи в расписании есть плановая и фактическая стоимость, плановая и фактическая длительность. У сотрудника — ставка и тип занятости. У филиала — вместимость и дополнительные расходы.
Из этих полей собирается P&L, который считается не в конце месяца по бухгалтерским проводкам, а непрерывно по фактически выполненным работам. Разрыв между плановой и фактической стоимостью назначения — это и есть операционная эффективность филиала, видимая до закрытия периода.
Коммерческий контур учитывает, что в медицине платит не всегда пациент. В договоре есть тип плательщика, цена за сутки и цена за договор, предоплата, процент скидки, условия оплаты и отметки о подписании и оплате. Самоплательщик, страховая компания и корпоративный клиент обслуживаются одной моделью.
Ролевая модель как продукт, а не как галочка
В системе двенадцать ролей: суперадминистратор, директор, системный администратор, владелец, администратор центра, HR-менеджер, маркетолог, врач, средний медперсонал, бухгалтер, инвестор и кандидат.
Роль ограничивает страницы и действия, а привязка к филиалу ограничивает видимые бизнес-объекты. Администратор центра работает со своим филиалом и кадрами, но не видит финансовую аналитику. HR видит персонал всей сети, но не видит пациентов и деньги. Врач видит клинику и не видит P&L.
Единый источник правды о том, что видит каждая роль, закрыт автотестом. Это единственный способ, чтобы доступ не «разъезжался» при доработках: список экранов роли проверяется машинально, а не на совести того, кто вносил правку.
Путь кандидата в сотрудника
Анкета трудоустройства открыта гостю: неавторизованный посетитель видит форму заявки вместо списка персонала. Дальше кандидат проходит собеседование, и при найме одна транзакция активирует профиль сотрудника, фиксирует дату приёма, привязывает его к филиалу и заменяет роль доступа. При увольнении рабочие роли отзываются, а дата увольнения сохраняется.
Отдельно у сотрудника хранится квалификация — та самая, по которой система решает, какие назначения ему вообще можно поставить в смену. Кадровый контур и клинический здесь не два разных модуля, а одна связь.
Встроенное обучение
У каждого залогиненного пользователя в шапке есть кнопка обучения. Она открывает инструкцию именно для его роли: кто он в системе, с чего начать, что делать по шагам и чего в его роли нет. Тест проверяет, что у каждой роли есть инструкция и что каждый её шаг ведёт только на доступный этой роли экран.
Для сети с текучкой среднего персонала это дешевле, чем повторять обучение вживую каждому новому человеку.
Безопасность боевого контура
Отдельная часть работы — приёмка. Сервисный шлюз отдаёт наружу только действия из явного реестра, каждое со своим списком ролей и допустимых HTTP-методов; изменяющие действия принимаются только POST-ом с CSRF-токеном. Инструменты разработчика на бою выключены и закрыты в robots.txt. База входит в обязательный список резервного копирования и снимается каждые три часа.
Для медицинских данных это не факультатив: доступ к карте пациента должен быть ограничен на сервере, а не спрятан в интерфейсе.
Что это даёт сети
- Единая шкала оценки состояния вместо субъективных формулировок в разных филиалах.
- План ведения, которыйпорождает задачи сам и объясняет, почему именно эти.
- Расписание, которое физически не может поставить процедуру неподходящему специалисту.
- P&L по факту выполненных работ, а не по итогам месяца.
- Договорный контур, одинаково работающий со страховой, корпоративным клиентом и самоплательщиком.
Следующий шаг
Такая архитектура переносится на любую сеть с объектами, персоналом и подопечными: многопрофильные клиники, реабилитационные и диагностические центры, санатории, сети стоматологий. Начинаем с карты ролей и одного сквозного сценария — от обращения до закрытой смены.
Где посмотреть
У проекта нет публичного адреса: он работает локально или на закрытом контуре и наружу не выкладывается. Показываем его на демонстрации, по записи.
Похожее решение: platFORMA - продвинутая система для отделов Вашей компании.
