Веб-приложение для частной лаборатории: как организовать заявки, регистрацию образцов, статусы, печать этикеток, PDF-результаты и аудит-лог.
Даже небольшая частная лаборатория быстро обрастает ручными операциями. Заявки приходят из разных каналов, данные переписывают из бумаги в таблицы, этикетки печатают «на глаз», а результаты собирают из шаблонов в Word. Ошибки обычно не «громкие», но дорогие: перепутали пробирку, неверно указали дату, забыли комментарий врача, распечатали не тот бланк.
В одном процессе участвуют разные люди, и у каждого свои боли. Администратору важно быстро оформить пациента и оплату, не задерживая очередь. Лаборанту нужны понятные задания по образцам, штрихкод и статус, чтобы не гадать, что уже сделано. Врачу важны корректные референсы, удобная проверка и подпись, а также уверенность, что итоговый документ не изменят «после».
Чаще всего путаница возникает в трех местах: при регистрации образца и привязке к пациенту и заявке, при печати этикеток со штрихкодом и контроле «ту ли наклеили», и при передаче результатов между исполнителями с финальной выдачей.
Без статусов и истории изменений спорные случаи разбираются неделями: кто поменял показатель, когда образец ушел в работу, почему распечатали другой бланк. Поэтому будущему приложению почти сразу нужны статусы и аудит-лог действий, пусть даже в простом виде.
Хорошая новость - внедрять можно поэтапно, не останавливая работу. Часто начинают с регистрации и штрихкодов, затем добавляют шаблоны результатов и выпуск PDF, а уже потом углубляют роли и контроль прав.
Начните не с экранов, а с того, что именно вы учитываете. Самая частая ошибка - смешать в одну запись заявку, пробирку и анализ. Потом это ломает печать этикеток, повторные заборы и отчеты.
Минимальный набор сущностей обычно такой: клиент (плательщик), пациент, заявка, образец, исследование и результат. Клиент и пациент часто совпадают, но лучше разделить: клиентом может быть человек, страховая или корпоративный договор, а пациентом - конкретный человек, у которого берут материал.
Сразу договоритесь об идентификаторах и где они «живут».
Со статусами важно не переборщить, но и не потерять смысл. Хороший старт - разделить статусы заявки и статусы образца. Например, базовая цепочка: «создано» (еще не принято в работу), «принято» (материал получен), «в работе», «готово», «выдано».
Отмены и возвраты лучше хранить не одним флажком, а как причину и комментарий: кто отменил, когда, код причины (ошибка данных, некачественный материал, отказ пациента, дубль) и свободный текст. Для возврата на доработку используйте отдельное событие или статус, чтобы было видно, что уже было «готово», но позже потребовалась правка.
И отдельно определите единицу учета.
Правильная модель связывает все три: одна заявка содержит несколько образцов, каждый образец может включать несколько исследований, а результат фиксируется на уровне исследования и затем собирается в итоговый документ.
Понятный поток снижает ошибки и споры: видно, где сейчас образец, кто его принял и что уже готово. Договоритесь о простых шагах и точках подтверждения.
На старте важно отделить то, что вводят руками, от того, что выбирают из справочников. Тогда администратор не печатает одно и то же разными словами, а отчеты сходятся.
На ресепшене обычно фиксируют пациента и контакт для уведомления, заказанные исследования (из каталога услуг), плательщика и способ оплаты (если нужно), врача или источник направления (из справочника), а также комментарий: срочность и особые условия.
Когда материал взят, создается карточка образца: тип материала, контейнер, время взятия, условия хранения. В этот момент печатают этикетку со штрихкодом, чтобы дальше работать сканером, а не «по глазам».
Дальше образец передают в лабораторию. Важно, чтобы лаборант подтверждал прием: комплектность (крышка, объем, правильный контейнер), соответствие заявке, отсутствие проблем (например, гемолиз). Без этого статус не должен двигаться дальше.
Результаты вводят вручную или по шаблону. Шаблон помогает не забыть поля, а контроль диапазонов подсвечивает значения вне референса, чтобы их перепроверили до выдачи.
Финальный этап лучше разделить на два действия: формирование документа и факт выдачи. Для бумажной выдачи это печать, для электронного формата - выпуск PDF и сохранение в архив. Повторную выдачу лучше отмечать отдельно, чтобы было видно, что это копия.
Пример: администратор создал заявку на общий анализ крови, взятие оформлено в 10:12, этикетка напечатана и наклеена, лаборант подтвердил прием, внес результат по шаблону, система подсветила один показатель, его перепроверили, затем сформировали PDF и отметили выдачу.
Не пытайтесь сразу охватить все. MVP должен закрывать один простой цикл: заявка - образец - статус - результат - печать.
Сфокусируйтесь на том, что должно работать с первого дня.
Пример: утром пришли 30 пробирок. Оператор заводит заявки «пачкой», регистрирует образцы, печатает этикетки, а лаборант видит статус каждого образца и вводит результаты по шаблону.
Этикетка - главный якорь в учете образцов. Если она плохо читается или печатается не тем форматом, дальше ломается прием, производство и выдача результатов.
На этикетке стоит закрепить минимум, который не вызывает споров: номер образца (человеко-читаемый), штрихкод с тем же идентификатором, материал (кровь, моча, мазок), дата и время регистрации. Если у вас несколько пробирок на одну заявку, добавьте суффикс (например, A/B) или отдельный номер алииквоты, чтобы не путать пересбор и разделение.
Чаще всего встречаются форматы 58x30 мм и 58x40 мм (термопринтеры) и офисные наклейки на листах A4. Ошибки обычно две: текст «уползает» к краю, а штрихкод попадает на сгиб или шов. Оставляйте поля, не делайте шрифт меньше 7-8 pt, а штрихкод печатайте с запасом по высоте.
Перед запуском проверьте:
Печать лучше делать через очередь: оператор отправляет задание, а система хранит статус (в очереди, напечатано, отменено) и фиксирует, кто печатал. Тогда легко повторить печать при замятии и так же легко отменить ошибочную отправку.
Пересбор пробы и перепечатку этикетки оформляйте как событие: старая этикетка помечается «аннулирована», создается новая (с новым ID или суффиксом), а в аудит-логе остается причина. Так вы не теряете историю и можете объяснить, почему у одного пациента две наклейки на похожие пробирки.
Чтобы результаты были понятными и одинаковыми из раза в раз, шаблон лучше описывать не как «красивый бланк», а как набор данных и правил. Тогда система сможет и печатать, и выпускать PDF без ручной правки.
Основа - список показателей. У каждого обычно есть название, единицы, референсные значения и автоматический флаг «ниже/выше нормы». Референсы лучше хранить не одной строкой, а структурой: диапазон, тип сравнения, подпись для печати.
Часто полезно держать в шаблоне:
Тексты врача и авто-комментарии важно хранить так, чтобы их можно было воспроизвести через год. Практика: сохранять «снимок» текста и правил, которые сработали, прямо в результате конкретного исследования, а не только ссылкой на текущий шаблон.
Референсы почти всегда зависят от методики и материала. Например, «глюкоза» для плазмы и для сыворотки может иметь разные границы, а для детей диапазоны меняются по возрастным группам.
Задайте валидацию сразу: обязательные поля, формат дат, разделитель дробной части, допустимые диапазоны и запрет на «пустой результат» без причины. И обязательно версионируйте шаблоны: если форма изменилась, новые исследования используют новую версию, а старые результаты остаются привязаны к своей.
Практический сценарий: лаборатория обновила методику HbA1c. В системе появляется версия 2 с новыми референсами и текстом интерпретации, но все PDF, выданные раньше, при повторной печати должны выглядеть так же, как в день выдачи.
PDF - это то, что пациент и врач пересылают друг другу и хранят годами. Поэтому лучше заранее зафиксировать стандарт: что входит в документ, когда он считается «официальным», и как отличить переиздание от оригинала.
Состав держите стабильным, чтобы администратору не приходилось каждый раз «додумывать» оформление.
Обычно PDF создают в момент финального статуса результата (например, «Подписан» или «Готов к выдаче»). Для редких случаев можно оставить кнопку «Сформировать по запросу», но фиксировать, на основе какой версии результата сделан файл.
Храните не только сам файл, но и метаданные: ID заявки, ID версии результата, дату формирования, кто сформировал, хэш файла (для контроля изменений), язык/шаблон, статус (оригинал или переиздание). На практике удобно хранить PDF как отдельную сущность «Документ» с привязкой к заявке и версии.
Если документ приходится выпускать повторно (ошибка в ФИО, дополнительный комментарий, замена референсов), не затирайте старый. Пометьте новый как «Переиздание №2», укажите причину и оставьте историю.
Отдельно продумайте аудит: что логировать при скачивании и отправке (например, в печать или в email). Обычно достаточно: кто, когда, какой документ, каким способом, и с какого рабочего места. Содержимое письма или внешние адреса лучше не записывать, если так требует ваша политика.
Аудит-лог - страховка, когда нужно быстро понять, почему образец оказался в неправильном статусе, кто перепечатал этикетку или откуда взялся новый PDF. Это базовая часть качества и доверия.
Смысл не в том, чтобы записывать все подряд, а в том, чтобы каждый важный шаг был воспроизводим. Обычно достаточно фиксировать: создание заявки и регистрацию образца, смены статусов (например, «принят», «в работе», «готов»), любые действия с печатью этикеток, правки результатов и выпуск PDF.
Чтобы лог реально помогал, в записи должны быть минимальные поля: кто сделал действие (пользователь и его роль), когда (точное время), что изменилось (объект и поле), старое и новое значение. Для статусов это особенно важно: тогда видно не просто «перевели в готов», а из какого статуса и кем.
Для критичных зон полезно завести отдельные журналы: печать этикеток и выдачу результатов. У печати есть свои детали: принтер, шаблон, размер, количество копий, повторная печать и причина. У выдачи важно фиксировать, какой именно документ отдали: номер версии, кто утвердил и когда сформировали PDF.
Исправления результатов оформляйте как событие с обязательной причиной и комментарием. Хорошая практика - хранить ссылку на версию (например, «версия 3») и не затирать прошлые значения, а сохранять историю.
Когда начинается разбор инцидента, спасают быстрые фильтры. Обычно хватает пяти: по заявке, по образцу, по пользователю, по типу события и по периоду.
Пример: администратор получает жалобу «не тот результат в PDF». По заявке он находит событие «изменение поля Hb» с 128 на 182, автора, комментарий «внесено по уточнению прибора», затем событие «сформирован PDF версия 2» и понимает, где именно произошла ошибка.
Пациент приходит в приемный пункт, администратор открывает систему и создает заявку: ФИО, дата рождения, тип исследования, врач (если нужно), контакт для уведомления. Система присваивает номер заявки.
Дальше регистрируют образцы: в заявке добавляют 2 пробирки (например, кровь и сыворотка). Каждой присваивается свой идентификатор и статус, например «зарегистрирован».
Администратор нажимает «Печать этикеток». В очередь печати уходят 2 этикетки со штрихкодом, номером заявки, типом материала и датой/временем взятия. Одна этикетка печатается с браком (смазался штрихкод), ее перепечатывают с пометкой «перепечатка».
Когда пробирки попадают в лабораторию, лаборант сканирует штрихкод и меняет статус: сначала «в работе», затем «готово». Если есть контроль качества, между ними может быть еще статус вроде «проверка».
Результаты вносят по шаблону: значения, единицы измерения, референсы, комментарий (например, «гемолиз, возможна погрешность»). После сохранения система формирует PDF, подписывает его служебными данными (номер заявки, дата, исполнитель) и кладет в архив.
Через день пациент просит выдать результат повторно. Администратор открывает заявку и нажимает «Выдать повторно». PDF не меняется, но фиксируется факт повторной выдачи.
По аудит-логу легко восстановить картину:
Даже простая система быстро превращается в продукт с рисками: один неверный клик может отменить регистрацию образца, изменить результат или распечатать не ту этикетку. Поэтому роли и права лучше определить до того, как вы начнете добавлять новые формы и отчеты.
Начните с набора ролей, но думайте не названиями, а задачами. Обычно хватает администратора, ресепшена, лаборанта, врача, руководителя и бухгалтерии. Ресепшен создает заявки и печатает этикетки, лаборант заносит фактические значения, врач утверждает и выпускает результат, бухгалтерия видит оплату и закрывающие документы, руководитель смотрит сводки, а администратор настраивает справочники и пользователей.
Критичные действия должны быть ограничены и подтверждаться. Чаще всего это отмена заявки или образца после печати этикетки, правка результата после утверждения, повторная выдача и повторная печать PDF, изменение референсов/единиц/шаблонов, правка платежей и возвраты.
Продумайте совместную работу на одном анализе. Реалистичный сценарий: лаборант сохраняет результат как черновик, врач видит его, но не может редактировать исходные измерения, только добавить комментарий и нажать «утвердить». После утверждения правки запрещены всем, кроме администратора по отдельному праву, и только с обязательной причиной.
Если у вас несколько филиалов, добавьте границы доступа. Пользователь должен видеть заявки только своего филиала, а иногда - даже конкретного рабочего места (например, стойка ресепшена в одном кабинете не должна видеть внутренние тесты другого).
Минимальная защита данных выглядит просто:
Проблемы часто начинаются с благих намерений: сделать «идеальную» заявку. В итоге в форме появляются десятки полей, операторы тратят время, заполняют «как получится» или обходят систему через заметки и мессенджеры. Лучше стартовать с минимума, без которого образец нельзя идентифицировать и провести по процессу.
Не менее болезненно отсутствие четких статусов и правил переходов. Когда один сотрудник ставит «готово», другой пишет «на проверке», а третий возвращает «в работу» без причин, учет начинает противоречить сам себе. Статусы должны быть понятными, а переходы - ограниченными: кто и когда может менять этап.
Отдельная ловушка - печать этикеток. Если разрешить перепечатку без контроля, этикетка легко «уедет» на другой образец, особенно в час пик. Нужны причины перепечатки, связь старой и новой этикетки и отметка в журнале.
С результатами и PDF все упирается в доверие. Если результат можно тихо исправить, потом невозможно доказать, что именно изменили и почему. То же самое с PDF: документ без версии превращается в спор, какой файл выдали пациенту.
Быстрая проверка, что у вас закрыто в MVP:
Пример из практики: лаборант обновил референсные значения после калибровки, а пациент принес старый PDF. Если версия результата и документа не сохранены, вы не сможете быстро показать, что было выдано и на основании чего.
Перед запуском даже небольшого MVP проверьте базовые вещи. Именно они чаще всего ломают работу на смене, а не «красивые отчеты».
Чтобы быстро поймать проблемы, прогоните «путь одного образца» как мини-тест: зарегистрируйте образец, распечатайте этикетку, проведите его до готовности, внесите результат, сформируйте PDF, затем попробуйте исправить значение и выпустить новую версию. Если в этот момент не видно версии, причины правки или автора в аудите, это стоит исправить до запуска.
Дальше удобно собрать прототип по этим правилам и постепенно наращивать функциональность. Если вы делаете это в TakProsto (takprosto.ai), можно начать с planning mode: описать сущности, статусы, шаблоны и версии, а затем через чат добавлять экраны и проверки. Когда логика стабилизируется, на платформе поддерживается экспорт исходного кода и развертывание, что помогает сохранить контроль над данными и доступами.
Начните с описания сущностей и статусов, а не с экранов. Минимально достаточно завести заявку, образец и результат, чтобы пройти цикл «создали → зарегистрировали образец → напечатали этикетку → внесли результат → выдали PDF». Потом уже добавляйте роли, справочники и контроль прав.
Чаще всего путают заявку, пробирку и анализ, а затем ломается печать этикеток и повторные заборы. Базовый набор — клиент (плательщик), пациент, заявка, образец, исследование и результат. Тогда можно связать деньги с заявкой, производство с образцом, а качество и сроки — с исследованиями.
Договоритесь, где используются разные номера. Номер заявки удобен для ресепшена и оплаты, а номер образца — для лаборатории и логистики; именно он должен быть на этикетке и в штрихкоде. Если один материал делится на несколько емкостей, сразу добавьте понятное разделение по алииквотам или суффиксам, чтобы не путать пробирки.
Сделайте отдельные статусы для заявки и для образца, чтобы не смешивать «оплачено» и «в работе». Для старта достаточно цепочки вроде «создано → принято → в работе → готово → выдано», но важно зафиксировать, кто и когда перевел статус. Возвраты и отмены лучше оформлять с причиной и комментарием, иначе потом невозможно объяснить спорные случаи.
Печатайте минимум, который однозначно идентифицирует образец: человеко-читаемый номер и штрихкод с тем же ID, материал, дата и время регистрации. Перед запуском проверьте читаемость вашим сканером и оставьте поля вокруг штрихкода, иначе он будет плохо считываться. Ошибки с этикеткой почти всегда приводят к самым дорогим пересортам.
Используйте очередь печати, где фиксируется, что отправлено на принтер и чем завершилось задание. Перепечатку оформляйте как отдельное событие с причиной, а старую этикетку помечайте как аннулированную, чтобы сохранить историю. Так вы сможете быстро понять, почему у одного образца появилось несколько наклеек.
Шаблон результата лучше хранить как структуру данных: показатели, единицы, правила округления, референсы и комментарии. Тогда вы сможете автоматически подсвечивать выход за пределы нормы и формировать одинаковый документ без ручной правки. Обязательно версионируйте шаблоны, чтобы старые исследования печатались так же, как в день выдачи.
PDF лучше считать «официальным» в момент финального подтверждения результата, а не при первом просмотре. Храните не только файл, но и метаданные: к какой версии результата он относится, кто сформировал, когда, и признак «оригинал/переиздание». Если нужно исправление, не затирайте старый файл — выпускайте новую версию с причиной.
Логируйте все критичные действия: создание заявки, регистрацию образца, смену статусов, печать и перепечатку этикеток, правки результатов и выпуск PDF. В записи должны быть автор, точное время, объект, поле, старое и новое значение, иначе лог будет бесполезен. Исправления результата делайте только с обязательной причиной, чтобы доверие к документам не рушилось.
Разделите права по задачам: ресепшен оформляет и печатает, лаборант вносит измерения, врач утверждает и подписывает, а администратор управляет справочниками и исключениями. После утверждения результата запретите тихие правки всем, кроме ограниченного права с обязательным комментарием. Если вы собираете прототип в TakProsto, удобно начать с planning mode и описать сущности, статусы и версии, а затем через чат постепенно добавлять экраны и проверки.
