Планируем веб-приложение для медосмотров сотрудников: маршрут направление-прохождение-допуск, статусы, файлы и роли, чтобы медданные были под контролем.
Медосмотры чаще «ломаются» не из-за медицины, а из-за рутины: кто-то не получил направление, кто-то прошел, но результат «застрял», у кого-то истек срок допуска, а проверяющий узнает об этом слишком поздно. Веб-приложение для медосмотров сотрудников должно держать один понятный маршрут от старта до финального решения.
В базовом виде система закрывает четыре задачи: планирование графика, выдачу направления, контроль прохождения и итог (допуск или недопуск). В любой момент должно быть видно, на каком шаге находится сотрудник и что нужно сделать дальше.
Участники процесса обычно такие:
Успех автоматизации измеряется просто: нет просрочек, статусы однозначные, проверка допуска занимает секунды, отчеты собираются без ручных таблиц.
С самого начала отделите «рабочие» данные от чувствительных. К чувствительным относятся диагнозы, заключения врачей, анализы и детали обследований. Даже если компании достаточно знать только итог, система часто по привычке начинает хранить лишнее. Это прямой риск: лишние данные сложнее защищать, ограничивать доступ и объяснять, зачем они вообще нужны.
Хорошее веб-приложение для медосмотров сотрудников начинается не с экранов, а с простого набора сущностей. Если заложить их правильно, дальше проще собирать график, статусы и отчеты, и не запутаться в «кто куда направлен и почему не допущен».
Минимальный набор обычно такой:
Для графика важно хранить не только «следующую дату», но и правило, по которому она считается: периодичность, привязку к должности и подразделению, а также «с какого события считать» (например, от даты приема или от последнего результата). Тогда при переводе сотрудника на новую должность график перестроится корректно.
Отдельно решите, что хранится как документ, а что как реквизиты. Сканы заключений, направления и подписанные формы лучше хранить файлами, а в карточке держать реквизиты: номер, дата, срок действия, кем выдано. Так проще искать и строить отчеты.
Заранее заложите поля для причин и комментариев: недопуск (и причина), перенос (и причина), отказ сотрудника, «не явился». Эти значения быстро станут фильтрами и основаниями для служебных записок.
И еще одно: учитывайте изменения во времени. У сотрудника должна быть история должностей и подразделений, а направления и допуски должны ссылаться на «срез» на момент события. Пример: Иванова перевели в другой цех, и периодичность стала чаще. Старые допуски остаются в истории, а новый график строится по новой роли.
В медосмотрах чаще ломается не логика маршрута, а доступы. Если права заданы «на глаз», медданные начинают гулять по компании, а решения о допуске спорят неделями. Сначала зафиксируйте роли и то, какие факты каждой роли реально нужны.
Базовый набор ролей обычно такой: сотрудник, HR, руководитель, врач или оператор медцентра, админ системы. Дальше важно разделить «медрезультаты» и «управленческий итог». Большинству людей в компании нужен только факт: допуск или недопуск, срок действия и дата следующего медосмотра. Диагнозы, показатели и текст заключения остаются у медицинской роли и, при необходимости, у узкого круга уполномоченных.
Правило минимального доступа помогает не ошибиться: показывайте только то, без чего человек не сможет сделать свой шаг в процессе. Руководителю достаточно видеть, что сотрудник временно не допущен и до какой даты, чтобы перестроить смену. HR нужен статус прохождения и список «кто просрочил», но не детали заключения.
Чтобы не было серых зон, заложите три механизма:
Чтобы учет не превратился в хаос, задайте один понятный маршрут и фиксированный набор статусов. Для веб-приложения для медосмотров сотрудников это критично: люди разные, клиники разные, а правила доступа к медданным жесткие.
Маршрут лучше держать линейным: направление создается, сотрудник проходит обследования, затем появляется решение по допуску. Внутри каждого шага статусы должны отвечать на один вопрос: что делать дальше и кто отвечает.
Для направления обычно хватает таких состояний: создано, отправлено, подтверждено, отменено. Логика простая: пока не подтверждено, медорганизация может не ждать сотрудника. Если отменено, дальнейшие шаги блокируются.
Прохождение удобнее вести отдельно от направления, потому что реальные визиты часто сдвигаются. Базовый набор: назначено, в процессе, пройдено, неявка.
Решение храните отдельным финальным статусом, чтобы не смешивать факт визита и итог.
Решение по допуску держите коротким:
У каждого направления должна быть дата, до которой нужно пройти осмотр. Если дата прошла, а прохождение не в статусе «пройдено», система помечает просрочку (отдельным статусом или флагом). Тогда руководитель видит риск, а сотруднику можно отправить напоминание.
Пример: сотруднику выдали направление до 15-го числа, визит назначен на 12-е, но он не пришел. Прохождение становится «неявка», а после 15-го система отмечает просрочку и блокирует продление допуска, пока не появится новое направление.
Скорость в таких задачах дает не «больше функций», а правильные экраны для каждой роли. Обычно хватает пяти ключевых экранов, если статусы и права доступа продуманы заранее.
HR нужен один рабочий экран на каждый день: календарь плюс список. Календарь показывает ближайшие даты, окна приемов и «красные» дедлайны. Список рядом нужен для быстрых действий: выдать направление, перенести, отметить, что сотрудник не вышел на связь, увидеть, кто просрочил.
Карточка сотрудника должна открываться из любого списка за 1 клик. В ней важны история осмотров, ближайшие даты, текущий допуск и срок действия. Медицинские детали в этой карточке лучше не показывать, если HR они не нужны.
Карточка направления - центр маршрута: реквизиты (организация, подразделение, вид осмотра), даты, ответственные, прикрепленные файлы и статус. На этом же экране удобно видеть «что мешает допуску» простыми причинами: не явился, ожидает заключение, требуется дообследование.
Экран врача или оператора должен быть коротким: подтвердить факт прохождения, выбрать результат (допуск/недопуск/временно), указать срок действия и загрузить заключение. Без лишних полей, чтобы не тормозить поток.
Руководителю нужен экран, где видно только:
Начальнику смены обычно достаточно формулировки: «допуск до 30.06, дальше нужен повторный осмотр». Все остальное остается в закрытой части системы по ролям.
В учете медосмотров документы часто решают спорные моменты: почему сотрудника допустили, на каком основании, кто видел данные и когда. Поэтому работу с файлами стоит заложить так же строго, как и статусы.
Обычно нужны:
Чтобы не утонуть в хаосе, задайте правила хранения. Работает единый шаблон имени: «Сотрудник - Тип документа - Дата», ограничение форматов (например, PDF/JPG) и лимит размера. Сразу решите, какие документы обязательны, а какие - только по ситуации.
Отдельная тема - замена файла. Нежелательно делать «удалить и загрузить заново», потому что теряется история. Практичнее хранить версии: кто заменил, когда, по какой причине, и какая версия была активной на момент решения о допуске.
Доступ к документам задавайте по принципу «минимально нужно для работы». Например, HR видит факт прохождения и статус, а полный документ доступен только роли «медкоординатор» или «уполномоченный».
Проверьте контрольные точки:
Пример: сотрудник прошел осмотр, но заключение еще не загружено. Система держит статус «ожидает документы», не дает поставить «допуск» и показывает руководителю только «в процессе», без доступа к файлу.
Чтобы AI собрал прототип, ему нужна не «идеальная ТЗ», а ясная картинка: кто работает в системе, какой путь проходит сотрудник и где принимается решение о допуске. В медосмотрах это особенно важно из-за медданных и строгих статусов.
Сначала опишите участников простыми фразами, как в разговоре: «HR создает направления и следит за сроками», «врач/медцентр отмечает результаты», «руководитель видит только допуск», «сотрудник видит свои даты и документы».
Дальше зафиксируйте маршрут в одном месте, чтобы не было двойных трактовок. Статусы должны читаться как цепочка и не пересекаться.
Затем перечислите экраны и действия. Дизайн рисовать не обязательно, достаточно назвать, что пользователь делает на каждом экране:
Критичный шаг - заранее прописать доступы и то, что скрываем. Пример правила: руководитель видит только итог «допущен/не допущен» и дату, но не диагнозы и не сканы заключений.
Чтобы AI не гадал, добавьте 2-3 примера данных и проверьте, что все статусы достижимы без тупиков. Например: «Иванов: направление выдано 10.02, прошел 12.02, недопуск по причине X, повтор через 30 дней».
Удобный текстовый шаблон требований может выглядеть так:
Роли: HR, Медцентр, Руководитель, Сотрудник.
Маршрут: Черновик -> Направление выдано -> Записан -> Пройден -> Допуск или Недопуск -> Закрыт.
Экраны: список, карточка, форма статуса, документы, отчеты.
Доступы: руководитель не видит меддетали; HR видит даты и файлы; медцентр видит только своих сотрудников.
Примеры: 3 сотрудника с разными исходами.
Уведомления нужны не для «контроля ради контроля», а чтобы люди приходили вовремя, а руководители видели риски заранее. Правило простое: меньше сообщений, больше смысла. Сначала определите события, затем получателей, и только потом каналы.
Обычно хватает четырех типов событий:
Разделите, кому что отправлять. Сотруднику достаточно факта и сроков, без подробностей. HR важно видеть, кто «горит» по срокам. Руководителю нужна картинка по своей команде. Медоператору важны записи и статус прохождения.
Чтобы не нарушать правила работы с медданными, держите уведомления «сухими»: идентификатор направления, дата, место, статус и следующий шаг. Никаких диагнозов, показателей и текстов заключений в сообщениях.
С отчетами та же логика: они должны отвечать на частые вопросы и открываться быстро. Обычно достаточно:
Добавьте простые фильтры: подразделение, должность, площадка, подрядчик, период. Продумайте экспорт: HR и руководителям можно выгружать списки и статусы без медподробностей (ФИО, табельный номер, даты, статус, комментарий «нужны действия»). Медчасти можно дать расширенный экспорт, но только по ролям.
Пример: HR видит отчет «Просрочки по площадке Москва-Склад», а руководитель смены получает раз в неделю одно письмо с количеством недопусков и списком задач.
Самая частая проблема - путаница между тем, кому что реально нужно видеть. Когда HR или руководитель получает доступ к результатам и заключениям врача, это почти всегда лишнее. В итоге люди обсуждают медицинские детали, а не управляют допусками и графиком.
Вторая ловушка - перегруз статусами. Кажется логичным сделать 15-20 вариантов («в процессе», «частично прошел», «ожидает справку», «на согласовании»), но через месяц ими перестают пользоваться. Лучше держать короткий набор, который поддерживает маршрут «направление -> прохождение -> допуск/недопуск», и четко описать, кто переводит из статуса в статус.
Третья проблема проявляется не сразу: переносы, неявка, повторное прохождение. Если это не заложить, сотрудники начинают «зависать» в вечном процессе, а отчетность становится ручной. Пример: Иван записан на медосмотр, заболел и не пришел. Если система не умеет фиксировать причину и новую дату, у вас появляется и просрочка, и спор, кто виноват.
Еще одна ловушка - хранить только файлы. Скан заключения важен, но без реквизитов и срока действия допуска вы не ответите на простой вопрос: «кто допущен сегодня». Файл есть, а решение и дата окончания не зафиксированы как данные.
Проверьте, чтобы в веб-приложении для медосмотров сотрудников были закрыты эти моменты:
Перед стартом важно быстро понять: люди видят то, что им нужно, статусы не путаются, а медданные не утекают. Такой чек-лист лучше пройти вместе с кадровиком и тем, кто будет администратором системы.
Проверьте карточку сотрудника: на первом экране должен быть текущий статус и срок допуска. Пользователь не должен искать это по вкладкам или по файлам. Если этого нет, учет быстро превращается в ручной контроль.
Просрочки должны быть заметны и объяснимы. Не просто «красным», а с причиной: нет направления, не пройден этап, документ не загружен, срок допуска истек. Тогда кадровик понимает, что именно исправлять.
Пройдите путь «направление -> прохождение -> допуск/недопуск» на тестовом сотруднике и убедитесь, что документы привязаны к конкретному направлению. Важно, чтобы файл нельзя было «приклеить» не к тому случаю или оставить без владельца, иначе потом непонятно, к какому осмотру он относится.
Отдельно проверьте права: руководитель не должен видеть диагнозы, заключения и сканы, даже если «очень надо». Ему хватает итога (допуск/недопуск) и срока действия. А любые изменения статуса должны оставлять след в журнале: это защищает и компанию, и сотрудника, и администратора системы.
Компания на 120 сотрудников делится на 3 подразделения: офис, склад и выездные инженеры. Периодичность разная: офис проходит раз в 2 года, склад и выездные - ежегодно, а для части работ на высоте нужен внеплановый допуск при переводе на новую роль. Поэтому в системе сразу видно, что это не один общий список, а несколько потоков с разными датами.
HR в начале квартала открывает планирование и собирает график: выбирает подразделение, должности и правила периодичности, затем формирует направления. У каждого направления появляется статус «создано» и крайний срок прохождения. Сотруднику уходит уведомление, а в карточке появляются шаги маршрута.
Маршрут в системе выглядит одинаково для всех:
Сотрудник приходит на осмотр. Медоператор (или ответственный за ввод данных) открывает направление, ставит «осмотр пройден», вносит результат и прикрепляет файл заключения. Если результат «допуск», система считает дату окончания допуска и показывает ее руководителю. Руководитель видит только рабочий итог: допущен или нет, и до какой даты, без медицинских деталей.
Исключение случается часто: сотрудник не явился. Тогда HR меняет статус на «неявка», выбирает причину и ставит новую дату. Направление не закрывается, а остается активным до выполнения. После переноса сотрудник проходит осмотр, медоператор загружает новое заключение, и статус возвращается в обычную цепочку до «допуск».
Начните с одного короткого документа, который одинаково понимают HR, охрана труда и медслужба. Зафиксируйте роли (кто что видит), статусы маршрута (направление -> прохождение -> допуск/недопуск), набор экранов и какие файлы к чему прикрепляются. Если это не записать заранее, позже появятся «серые зоны», где медданные случайно увидит лишний человек.
Дальше соберите минимальную версию и покажите ее пользователям как можно раньше. В MVP обычно достаточно:
Когда прототип готов, проверьте права доступа не «в целом», а руками на тестовых пользователях. Создайте по одному аккаунту на каждую роль и пройдите один и тот же кейс: сотрудник смотрит свою запись, HR видит статусы, медработник видит медзаключение, руководитель видит только итог. Отдельно проверьте поиск и выгрузки: утечки чаще происходят именно там.
Продумайте, как вы будете вносить изменения. В медосмотрах они неизбежны: добавился новый документ, появился новый статус (например, «ожидает повторного анализа»), открылось подразделение в другом городе. Лучше заранее договориться, кто утверждает изменения и как они попадают в систему, чтобы не ломать старые записи и отчеты.
Если вы хотите собирать такой прототип через чат, это можно сделать в TakProsto (takprosto.ai): достаточно описать маршрут, роли и что считать медданными, а затем по шагам уточнить экраны, статусы и правила доступа на тестовых учетках.
Начните с линейного пути из трех крупных шагов: направление выдано, прохождение состоялось, принято решение о допуске. Внутри каждого шага оставьте минимум статусов, чтобы по одному взгляду было понятно, что делать дальше и кто отвечает.
По умолчанию компании достаточно хранить управленческий итог: допущен или не допущен, срок действия и дату следующего осмотра. Диагнозы, показатели анализов и тексты заключений лучше не складывать в корпоративную систему, если это не требуется по процессу и доступам.
Заложите пять сущностей: сотрудник, направление, визит (попытка пройти), результат и допуск. Этого обычно хватает, чтобы построить график, видеть статусы и собирать отчеты без ручных таблиц.
Периодичность лучше считать по правилу, а не хранить одной датой «следующий осмотр». Укажите, от какого события считать (прием на работу или последний результат), и привяжите правило к должности и подразделению, чтобы при переводах график перестраивался корректно.
Держите медицинские результаты и управленческий допуск в разных полях и экранах. Руководителю и HR обычно нужен только факт допуска, срок и статус прохождения, а доступ к документам и деталям оставляйте медицинской роли и узкому кругу уполномоченных.
Разделите «направление» и «прохождение»: направление может быть создано и отправлено, а визит может переноситься и иметь свою историю. Минимально добавьте состояния для визита вроде «назначено», «в процессе», «пройдено» и «неявка», чтобы переносы не ломали отчетность.
Сделайте просрочку отдельным признаком: если дедлайн прошел, а визит не завершен, система помечает риск и показывает следующий шаг. Практичный вариант — блокировать продление допуска до появления нового направления или закрытого прохождения, чтобы просрочки не копились незаметно.
Выигрыш дает один рабочий экран для HR с календарем и списком, плюс карточка сотрудника, которая открывается в один клик и показывает текущий допуск и ближайшие даты. Для медцентра нужен короткий экран ввода результата и загрузки документа, а для руководителя — только итог допуска и срок без деталей.
Храните сканы и подписанные формы как файлы, а в карточках держите реквизиты: номер, дата, срок действия и кем выдано, чтобы можно было искать и строить отчеты. Для замены файла используйте версионность, иначе пропадает история и становится сложно доказать, какая версия была основанием решения.
Сначала опишите роли, маршрут и что считается чувствительными медданными, затем перечислите экраны и действия на каждом шаге. Добавьте 2–3 примера сотрудников с разными исходами и заранее пропишите правила доступа, чтобы при сборке прототипа не появлялись «серые зоны» с лишним просмотром данных.