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

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

Что решает сайт для медицинской организации и где границы задачи

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

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

Ответственные. Со стороны клиники нужен один человек с правом решения — как правило, заместитель руководителя по лечебной работе или руководитель регистратуры. Он отвечает за содержание расписания и правила записи. ИТ-специалист клиники отвечает за доступы и связь с МИС. Подрядчик отвечает за реализацию сценариев и документацию. Без владельца содержания сайт быстро устаревает, и никакая разработка это не компенсирует. Владелец должен регулярно обновлять данные.

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

Карта сценариев пациента: с чего начать проектирование

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

Роли и входные точки

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

Что фиксировать по каждому сценарию

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

Карту согласуют с регистратурой и лечебной частью, а не только с руководителем. Именно регистратура знает реальные правила: кого записывают только по направлению, где нужен осмотр перед приёмом, какие услуги оказывают в конкретном подразделении.

Запись на приём: талоны, предварительная запись и живая очередь

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

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

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

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

Что должно быть в талоне

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

Отмена и перенос

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

Расписание врачей и услуги: как удерживать данные в актуальном состоянии

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

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

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

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

Ответственный за расписание — конкретный сотрудник, а не отдел. У него должен быть регламент: когда обновляет, кого предупреждает, что делает при сбое.

Информация о медицинской организации на сайте: обязательный минимум и структура

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

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

Карточка специалиста

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

Страницы подразделений

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

Обмен данными с МИС: что уточнить до старта

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

До старта нужно получить ответы на конкретные вопросы. Какая МИС используется и кто её владелец. Есть ли точка доступа и как она авторизуется. Есть ли тестовый контур, на котором можно проверить обмен без риска для рабочей базы. С какой периодичностью обновляются талоны и остальные данные. Что делает сайт, если МИС недоступна: показывает последнее известное расписание, закрывает запись или предупреждает пациента.

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

Если МИС нет или интеграция отложена, это не блокирует проект: расписание и записи можно вести вручную. Но тогда нужно честно оценить трудозатраты регистратуры и назначить ответственного.

Персональные данные, доступы и требования

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

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

Доступы администраторов описывают заранее: кто видит записи, кто меняет расписание, кто публикует документы. Права раздают по группам, а не всем сразу. Порядок работы с доступами и настройками разобран в материале Администрирование сайта на Битрикс — доступы, данные и настройки.

Отдельная тема — резервные копии. Расписание, записи и обращения — это данные, которые нельзя потерять. Перед любыми изменениями делают копию, проверяют восстановление и только потом работают. Как это устроено, описано в статье Резервное копирование сайта на Битрикс — хранение и восстановление.

Развилки, которые нужно закрыть до разработки

Пока эти решения не приняты, оценка и сроки будут приблизительными, а часть работы придётся переделывать.

Учебный пример: клиника с двумя подразделениями

Учебный пример. Данные условные, это не реальный проект.

Входные условия. Условная клиника с двумя подразделениями, восемнадцатью специалистами и каталогом из шестидесяти услуг. МИС есть, точка доступа предоставлена, тестовый контур выделен. Запись — по талонам, для двух специалистов дополнительно предварительная запись. Уведомления — на электронную почту. Ответственный за расписание — старший администратор.

Шаг 1. Собирают карту сценариев: новый пациент ищет специалиста и записывается; повторный записывается со страницы врача; пациент выбирает услугу без привязки к врачу; пациент отменяет запись; пациент проверяет талон по номеру.

Шаг 2. Согласуют состав полей формы. Из расширенного набора оставляют имя, телефон, дату рождения и адрес электронной почты. Остальное убирают, чтобы не удлинять путь.

Шаг 3. Настраивают обмен с МИС на тестовом контуре: сначала выгрузку справочников и расписания, затем передачу тестовых записей. Проверяют, что услуга, привязанная к специалисту, отображается в его карточке.

Шаг 4. Проверяют отклонения: отмена талона, изменение расписания, недоступность сервиса. Для каждого случая фиксируют ожидаемое поведение сайта и текст уведомления.

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

Как проверить результат и принять работу

Приёмка идёт по сценариям, а не по списку страниц. Ниже — рабочий чек-лист.

• Карта сценариев пациента согласована и подписана до начала разработки.
• Каждый сценарий пройден на тестовых данных от входа до результата.
• Отклонения проверены: нет свободных талонов, отмена, изменение расписания, недоступность МИС.
• Расписание на сайте совпадает с источником истины после обновления.
• Тестовая запись появляется в МИС в ожидаемом виде.
• Талон можно сохранить, распечатать и проверить по номеру.
• Уведомления приходят на указанный канал и содержат понятный текст.
• Форма записи не содержит лишних полей, согласованных как ненужные.
• Карточки специалистов и страницы подразделений заполнены и проверены владельцем содержания.
• Права доступа администраторов розданы по группам и проверены.
• Резервная копия сделана, восстановление проверено на копии.
• Инструкция для сотрудников передана и разобрана с регистратурой.

Типичные ошибки и ограничения

Первая ошибка — начинать с дизайна. Красивая главная не спасает, если запись обрывается на третьем шаге.

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

Третья — два источника расписания. Правки и в МИС, и вручную дают расхождения, которые видит пациент.

Четвёртая — отсутствие владельца содержания. Сайт запускают, и через месяц расписание устаревает.

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

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

Если сайт уже существует и вызывает вопросы, полезно начать с разбора текущего состояния — например, с материала Аудит сайта на Битрикс: как проходит и что вы получите.

Какие исходные данные подготовить для оценки

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

• Список подразделений с адресами, режимом работы и контактами.
• Список специалистов: специальность, подразделение, услуги, расписание.
• Каталог услуг с названиями и, если публикуются, ценами.
• Правила записи: режимы, ограничения, кто подтверждает.
• Сведения о МИС: какая система, есть ли точка доступа, тестовый контур, кто отвечает.
• Перечень обязательных к раскрытию сведений, согласованный с профильным специалистом.
• Требования к уведомлениям и их тексты.
• Список ответственных: за содержание, за доступы, за интеграцию.
• Сроки и порядок обновления расписания.

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