Веб-приложение для медосмотров сотрудников: маршрут и доступы

Что именно нужно автоматизировать в медосмотрах

Медосмотры чаще «ломаются» не из-за медицины, а из-за рутины: кто-то не получил направление, кто-то прошел, но результат «застрял», у кого-то истек срок допуска, а проверяющий узнает об этом слишком поздно. Веб-приложение для медосмотров сотрудников должно держать один понятный маршрут от старта до финального решения.

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

Участники процесса обычно такие:

• Сотрудник: видит направление, даты и статус, при необходимости загружает документы.
• HR или специалист по охране труда: планирует, запускает направления, следит за просрочками.
• Руководитель: проверяет допуски своей команды, подтверждает отстранение при недопуске.
• Медорганизация: передает результаты (через врача или оператора).

Успех автоматизации измеряется просто: нет просрочек, статусы однозначные, проверка допуска занимает секунды, отчеты собираются без ручных таблиц.

С самого начала отделите «рабочие» данные от чувствительных. К чувствительным относятся диагнозы, заключения врачей, анализы и детали обследований. Даже если компании достаточно знать только итог, система часто по привычке начинает хранить лишнее. Это прямой риск: лишние данные сложнее защищать, ограничивать доступ и объяснять, зачем они вообще нужны.

Данные, которые стоит заложить с самого начала

Хорошее веб-приложение для медосмотров сотрудников начинается не с экранов, а с простого набора сущностей. Если заложить их правильно, дальше проще собирать график, статусы и отчеты, и не запутаться в «кто куда направлен и почему не допущен».

Минимальный набор обычно такой:

• Сотрудник: кто проходит осмотр и к какому подразделению относится сейчас.
• Направление: факт выдачи направления (когда, кем, на какой вид осмотра).
• Визит (прохождение): конкретная попытка пройти осмотр (дата, место, этап).
• Результат: медицинский итог по визиту (годен/ограничения/не годен).
• Допуск: управленческое решение для работы (допуск/недопуск/временный допуск) с датами.

Для графика важно хранить не только «следующую дату», но и правило, по которому она считается: периодичность, привязку к должности и подразделению, а также «с какого события считать» (например, от даты приема или от последнего результата). Тогда при переводе сотрудника на новую должность график перестроится корректно.

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

Заранее заложите поля для причин и комментариев: недопуск (и причина), перенос (и причина), отказ сотрудника, «не явился». Эти значения быстро станут фильтрами и основаниями для служебных записок.

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

Права доступа к медданным: простые правила без лазеек

В медосмотрах чаще ломается не логика маршрута, а доступы. Если права заданы «на глаз», медданные начинают гулять по компании, а решения о допуске спорят неделями. Сначала зафиксируйте роли и то, какие факты каждой роли реально нужны.

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

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

Чтобы не было серых зон, заложите три механизма:

• Раздельные поля и экраны: «итог допуска» отдельно от «медданных».
• Журнал действий: кто открыл карточку, изменил статус, загрузил файл, принял решение.
• Согласие и основание доступа: при создании направления фиксируйте, что сотрудник ознакомлен и согласен на обработку, а доступ к документам выдавайте по роли и задаче.

Маршрут и статусы: как не запутаться в допусках

Чтобы учет не превратился в хаос, задайте один понятный маршрут и фиксированный набор статусов. Для веб-приложения для медосмотров сотрудников это критично: люди разные, клиники разные, а правила доступа к медданным жесткие.

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

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

Статусы прохождения и решения

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

Решение храните отдельным финальным статусом, чтобы не смешивать факт визита и итог.

Решение по допуску держите коротким:

• допущен
• не допущен
• допущен с ограничениями (только если реально используете ограничения в работе)

Сроки, просрочка и напоминания

У каждого направления должна быть дата, до которой нужно пройти осмотр. Если дата прошла, а прохождение не в статусе «пройдено», система помечает просрочку (отдельным статусом или флагом). Тогда руководитель видит риск, а сотруднику можно отправить напоминание.

Пример: сотруднику выдали направление до 15-го числа, визит назначен на 12-е, но он не пришел. Прохождение становится «неявка», а после 15-го система отмечает просрочку и блокирует продление допуска, пока не появится новое направление.

Какие экраны нужны, чтобы работать быстро

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

Что должно быть у HR и отдела кадров

HR нужен один рабочий экран на каждый день: календарь плюс список. Календарь показывает ближайшие даты, окна приемов и «красные» дедлайны. Список рядом нужен для быстрых действий: выдать направление, перенести, отметить, что сотрудник не вышел на связь, увидеть, кто просрочил.

Карточка сотрудника должна открываться из любого списка за 1 клик. В ней важны история осмотров, ближайшие даты, текущий допуск и срок действия. Медицинские детали в этой карточке лучше не показывать, если HR они не нужны.

Что нужно врачу/оператору и руководителю

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

Экран врача или оператора должен быть коротким: подтвердить факт прохождения, выбрать результат (допуск/недопуск/временно), указать срок действия и загрузить заключение. Без лишних полей, чтобы не тормозить поток.

Руководителю нужен экран, где видно только:

• текущий допуск сотрудника
• срок действия допуска
• кто и когда вынес решение
• короткий комментарий в 1-2 строки (без диагнозов)

Начальнику смены обычно достаточно формулировки: «допуск до 30.06, дальше нужен повторный осмотр». Все остальное остается в закрытой части системы по ролям.

Файлы и документы: загрузка, хранение, доступ

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

Обычно нужны:

• направление на медосмотр
• заключение медорганизации
• справки и результаты (только если их разрешено хранить)
• согласия на обработку персональных данных
• дополнительные документы (например, для повторного осмотра)

Чтобы не утонуть в хаосе, задайте правила хранения. Работает единый шаблон имени: «Сотрудник - Тип документа - Дата», ограничение форматов (например, PDF/JPG) и лимит размера. Сразу решите, какие документы обязательны, а какие - только по ситуации.

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

Доступ к документам задавайте по принципу «минимально нужно для работы». Например, HR видит факт прохождения и статус, а полный документ доступен только роли «медкоординатор» или «уполномоченный».

Проверьте контрольные точки:

• кто может скачивать, а кто только просматривать в интерфейсе
• нужен ли файл, чтобы статус сменился на «допуск/недопуск»
• кто видит комментарии к документу и причины замены
• фиксируется ли просмотр и скачивание в журнале
• что происходит при истечении срока документа (напоминание, блокировка статуса)

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

Пошагово: как описать задачу, чтобы AI собрал экраны и логику

Чтобы AI собрал прототип, ему нужна не «идеальная ТЗ», а ясная картинка: кто работает в системе, какой путь проходит сотрудник и где принимается решение о допуске. В медосмотрах это особенно важно из-за медданных и строгих статусов.

Сначала опишите участников простыми фразами, как в разговоре: «HR создает направления и следит за сроками», «врач/медцентр отмечает результаты», «руководитель видит только допуск», «сотрудник видит свои даты и документы».

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

Затем перечислите экраны и действия. Дизайн рисовать не обязательно, достаточно назвать, что пользователь делает на каждом экране:

• список сотрудников (фильтр по срокам, кнопка «создать направление»)
• карточка медосмотра (статусы, даты, файлы, комментарий)
• экран медцентра («пройдено/не пройдено», «допуск/недопуск», причина)
• отчеты (кто просрочен, кто допущен, кто в процессе)

Критичный шаг - заранее прописать доступы и то, что скрываем. Пример правила: руководитель видит только итог «допущен/не допущен» и дату, но не диагнозы и не сканы заключений.

Чтобы AI не гадал, добавьте 2-3 примера данных и проверьте, что все статусы достижимы без тупиков. Например: «Иванов: направление выдано 10.02, прошел 12.02, недопуск по причине X, повтор через 30 дней».

Удобный текстовый шаблон требований может выглядеть так:

Роли: HR, Медцентр, Руководитель, Сотрудник.
Маршрут: Черновик -> Направление выдано -> Записан -> Пройден -> Допуск или Недопуск -> Закрыт.
Экраны: список, карточка, форма статуса, документы, отчеты.
Доступы: руководитель не видит меддетали; HR видит даты и файлы; медцентр видит только своих сотрудников.
Примеры: 3 сотрудника с разными исходами.

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

Уведомления нужны не для «контроля ради контроля», а чтобы люди приходили вовремя, а руководители видели риски заранее. Правило простое: меньше сообщений, больше смысла. Сначала определите события, затем получателей, и только потом каналы.

Обычно хватает четырех типов событий:

• Назначение: сотруднику пришло направление и окно дат для прохождения.
• Приближение даты: напоминание за 7 и за 1 день.
• Просрочка: сигнал на следующий день после дедлайна.
• Итог: допуск или недопуск, плюс что делать дальше.

Разделите, кому что отправлять. Сотруднику достаточно факта и сроков, без подробностей. HR важно видеть, кто «горит» по срокам. Руководителю нужна картинка по своей команде. Медоператору важны записи и статус прохождения.

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

С отчетами та же логика: они должны отвечать на частые вопросы и открываться быстро. Обычно достаточно:

• просрочки (кто и насколько задержал прохождение)
• план на месяц (сколько людей и по каким площадкам нужно провести)
• допуски по подразделениям (допущен, временно не допущен, ожидает итог)
• нагрузка по подрядчику (сколько направлений создано и закрыто)

Добавьте простые фильтры: подразделение, должность, площадка, подрядчик, период. Продумайте экспорт: HR и руководителям можно выгружать списки и статусы без медподробностей (ФИО, табельный номер, даты, статус, комментарий «нужны действия»). Медчасти можно дать расширенный экспорт, но только по ролям.

Пример: HR видит отчет «Просрочки по площадке Москва-Склад», а руководитель смены получает раз в неделю одно письмо с количеством недопусков и списком задач.

Частые ошибки и ловушки в учете медосмотров

Самая частая проблема - путаница между тем, кому что реально нужно видеть. Когда HR или руководитель получает доступ к результатам и заключениям врача, это почти всегда лишнее. В итоге люди обсуждают медицинские детали, а не управляют допусками и графиком.

Вторая ловушка - перегруз статусами. Кажется логичным сделать 15-20 вариантов («в процессе», «частично прошел», «ожидает справку», «на согласовании»), но через месяц ими перестают пользоваться. Лучше держать короткий набор, который поддерживает маршрут «направление -> прохождение -> допуск/недопуск», и четко описать, кто переводит из статуса в статус.

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

Еще одна ловушка - хранить только файлы. Скан заключения важен, но без реквизитов и срока действия допуска вы не ответите на простой вопрос: «кто допущен сегодня». Файл есть, а решение и дата окончания не зафиксированы как данные.

Проверьте, чтобы в веб-приложении для медосмотров сотрудников были закрыты эти моменты:

• права доступа соответствуют ролям (HR видит статус и сроки, медик - детали)
• статусов мало, и они соответствуют реальным шагам процесса
• есть сценарии: перенос, неявка, повторный осмотр
• допуск хранится как запись с датами и основаниями, а не только как файл
• есть история изменений: кто, когда и почему поменял статус или решение

Быстрая проверка перед запуском: чек-лист

Перед стартом важно быстро понять: люди видят то, что им нужно, статусы не путаются, а медданные не утекают. Такой чек-лист лучше пройти вместе с кадровиком и тем, кто будет администратором системы.

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

Просрочки должны быть заметны и объяснимы. Не просто «красным», а с причиной: нет направления, не пройден этап, документ не загружен, срок допуска истек. Тогда кадровик понимает, что именно исправлять.

Пройдите путь «направление -> прохождение -> допуск/недопуск» на тестовом сотруднике и убедитесь, что документы привязаны к конкретному направлению. Важно, чтобы файл нельзя было «приклеить» не к тому случаю или оставить без владельца, иначе потом непонятно, к какому осмотру он относится.

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

Отдельно проверьте права: руководитель не должен видеть диагнозы, заключения и сканы, даже если «очень надо». Ему хватает итога (допуск/недопуск) и срока действия. А любые изменения статуса должны оставлять след в журнале: это защищает и компанию, и сотрудника, и администратора системы.

Пример сценария: как это выглядит в реальной компании

Компания на 120 сотрудников делится на 3 подразделения: офис, склад и выездные инженеры. Периодичность разная: офис проходит раз в 2 года, склад и выездные - ежегодно, а для части работ на высоте нужен внеплановый допуск при переводе на новую роль. Поэтому в системе сразу видно, что это не один общий список, а несколько потоков с разными датами.

HR в начале квартала открывает планирование и собирает график: выбирает подразделение, должности и правила периодичности, затем формирует направления. У каждого направления появляется статус «создано» и крайний срок прохождения. Сотруднику уходит уведомление, а в карточке появляются шаги маршрута.

Маршрут в системе выглядит одинаково для всех:

• Направление создано и отправлено сотруднику
• Запись на прием подтверждена
• Осмотр пройден
• Заключение загружено
• Решение: допуск или недопуск

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

Исключение случается часто: сотрудник не явился. Тогда HR меняет статус на «неявка», выбирает причину и ставит новую дату. Направление не закрывается, а остается активным до выполнения. После переноса сотрудник проходит осмотр, медоператор загружает новое заключение, и статус возвращается в обычную цепочку до «допуск».

Следующие шаги: собрать прототип и проверить доступы на практике

Начните с одного короткого документа, который одинаково понимают HR, охрана труда и медслужба. Зафиксируйте роли (кто что видит), статусы маршрута (направление -> прохождение -> допуск/недопуск), набор экранов и какие файлы к чему прикрепляются. Если это не записать заранее, позже появятся «серые зоны», где медданные случайно увидит лишний человек.

Дальше соберите минимальную версию и покажите ее пользователям как можно раньше. В MVP обычно достаточно:

• графика медосмотров (кто, когда, какой тип)
• направлений и записей на прохождение
• итогового решения (допуск/недопуск) и срока действия
• журнала действий (кто создал, кто изменил, кто открыл документ)

Когда прототип готов, проверьте права доступа не «в целом», а руками на тестовых пользователях. Создайте по одному аккаунту на каждую роль и пройдите один и тот же кейс: сотрудник смотрит свою запись, HR видит статусы, медработник видит медзаключение, руководитель видит только итог. Отдельно проверьте поиск и выгрузки: утечки чаще происходят именно там.

Продумайте, как вы будете вносить изменения. В медосмотрах они неизбежны: добавился новый документ, появился новый статус (например, «ожидает повторного анализа»), открылось подразделение в другом городе. Лучше заранее договориться, кто утверждает изменения и как они попадают в систему, чтобы не ломать старые записи и отчеты.

Если вы хотите собирать такой прототип через чат, это можно сделать в TakProsto (takprosto.ai): достаточно описать маршрут, роли и что считать медданными, а затем по шагам уточнить экраны, статусы и правила доступа на тестовых учетках.