Разработка медицинского портала: запись, ЛК, МИС, телемедицина

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

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

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

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

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

Что меняется после запуска: время записи, нагрузка, число отказов

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

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

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

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

Способы реализации: с нуля, на готовой платформе, готовыми модулями

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

Главное узкое место у всех трёх путей одно — интеграция с МИС. Обмен расписанием, картами пациентов и статусами записей чувствителен к расхождениям форматов, поэтому схему обмена проектируем до первой строки кода. Разбираем ваши сценарии записи, отмечаем, что закрывается типовым, и только после этого называем подходящий вариант.

Этапы внедрения: от аудита процессов до передачи в эксплуатацию

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

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

1. Обследование: роли сотрудников, маршруты пациента, точки обмена с МИС и лабораторией, требования к хранению медданных.
2. Схема данных пациента: единый профиль, правила сопоставления дублей, разграничение доступа к чувствительным полям, журнал обращений.
3. Проектирование записи: сетка приёмов, правила отмены, лист ожидания, защита слота от двойного бронирования.
4. Сборка личного кабинета и телемедицины: результаты исследований, назначения, оплата, видеоприём с резервированием канала.
5. Проверка на реальных сценариях: конфликты расписания, обрыв связи на видеоприёме, недоступность МИС — портал ведёт себя предсказуемо.
6. Опытная эксплуатация на ограниченной группе пациентов и врачей: сверка данных с МИС, замер времени отклика на пиковой нагрузке.
7. Передача в поддержку: регламент обновлений, порядок отката, схема интеграций и инструкции для администраторов клиники.

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

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

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

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

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

Кейс: время записи сократилось втрое, нагрузка на регистратуру упала

Сеть из четырёх филиалов пришла с порталом, где запись шла через одну форму: пациент выбирал специальность и оставлял телефон, а распределяла обращения регистратура вручную. Замеры до работ: самостоятельно записывались 18% пациентов, остальные шли через звонок; на один первичный приём регистратор тратил в среднем 4 минуты, а в утренние пиковые часы доля отказов портала доходила до 11% — форма теряла обращения при всплеске трафика.

Что изменили

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

Что стало после

Время записи снизилось с 4 минут до 1 минуты 20 секунд — втрое. Доля самостоятельных записей выросла с 18% до 54%, доля отказов формы на пике упала до 1,5%, а звонки по типовым вопросам («есть ли окно», «перенесите приём») сократились примерно на 40%. Регистратура переключилась на сложные случаи и повторных пациентов — узкое место сместилось с приёма обращений на работу с записями, которые требуют разбора.

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

Чем отличается портал от сайта-визитки клиники и от МИС?

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

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

Поэтому сайт, запись и личный кабинет спокойно живут в одном контуре: общая база, единая авторизация, один домен. Портал и МИС так не совмещают — учётный контур изолируют, а связь идёт через слой интеграции. Иначе внешний трафик и медицинские данные оказываются в одной зоне риска, а это уже требования 152-ФЗ к спецкатегории персональных данных.

Частые технические сомнения: разбор перед стартом

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

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

Как разграничиваются права доступа?

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

Как переносятся данные пациентов?

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

Что будет с записью при сбое?

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