Логика ТРИАЖ¶

Ядро подсистемы. [ТЗ] Оценка выполняется алгоритмами на основе правил в соответствии с клиническим протоколом оказания скорой (неотложной) медицинской помощи взрослому населению (приказ МЗ РБ № 1030 от 30.09.2010), с учётом жизненно важных показателей, возраста и сопутствующих заболеваний. Результат — рекомендация приоритета медицинскому персоналу.

Конкретные пороги в этом документе — не медицинский стандарт

Всё, что ниже отмечено [?], — иллюстрация формы правила, а не утверждённые клинические критерии. Пороговые значения витальных показателей, нормативы времени и правило нумерации талонов обязаны быть утверждены медицинским персоналом УЗ до ввода в эксплуатацию. Это не инженерное решение и не может быть принято разработчиком. См. R-2.

Три цвета¶

[ОП] По оценке состояния пациенты делятся на три группы; для каждого цвета свой приоритет обслуживания.

Цвет	Талон	Приоритет	Смысл
🔴 Красный	К43	Высший	Критическое состояние. Проходит мимо приёмника сразу в отделение
🟡 Жёлтый	В34	Средний	Требует помощи, проходит обычную сортировку и очередь
🟢 Зелёный	П45	Плановый	Может подождать

flowchart TB
  IN["Пациент в приёмнике"] --> SRC{"Источник<br/>поступления"}
  SRC -->|"доставлен СМП"| SMP["Данные ЭКВ:<br/>витальные показатели,<br/>диагноз, помощь в пути"]
  SRC -->|"самообращение"| SELF["Оценка на месте:<br/>пол, температура, состояние,<br/>вес, дыхание"]

  SMP --> RULES["rules-engine"]
  SELF --> RULES
  RULES --> COLOR{"Цвет"}

  COLOR -->|"🔴 К43"| RED["Мимо приёмника<br/>сразу в отделение"]
  COLOR -->|"🟡 В34"| YEL["Очередь, приоритет средний"]
  COLOR -->|"🟢 П45"| GRN["Очередь, приоритет плановый"]

  SMP -.->|"ЗАПРЕЩЕНО"| GRN

  style RED fill:#fdd,stroke:#c00,stroke-width:2px
  style YEL fill:#ffd,stroke:#cc0,stroke-width:2px
  style GRN fill:#dfd,stroke:#0a0,stroke-width:2px

Пациенты СМП не бывают зелёными

[ОП] Прямое правило: доставленный бригадой пациент — либо красный, либо жёлтый. Логика в том, что решение бригады о госпитализации само по себе означает, что случай не плановый.

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

Форма правила¶

[ADR-7] Правила — версионируемые записи в БД, не код.

Пример структуры (иллюстрация формы, не клинический стандарт)

{
  "rule_code": "R-RED-RESP",
  "name": "Критическое нарушение дыхания",
  "priority": 10,
  "result_color": "red",
  "conditions": {
    "any_of": [
      { "loinc": "9279-1",  "op": ">=", "value": 30, "unit": "/min" },
      { "loinc": "9279-1",  "op": "<=", "value": 8,  "unit": "/min" },
      { "loinc": "2708-6",  "op": "<",  "value": 90, "unit": "%" }
    ]
  }
}

Правило с несколькими условиями

{
  "rule_code": "R-RED-CONSCIOUSNESS",
  "name": "Нарушение сознания",
  "priority": 5,
  "result_color": "red",
  "conditions": {
    "all_of": [
      { "loinc": "9269-2", "op": "<=", "value": 12 }
    ]
  }
}

Порядок применения¶

flowchart TB
  START["Входные значения"] --> SORT["Правила по priority ASC"]
  SORT --> EVAL["Проверка первого правила"]
  EVAL --> MATCH{"Сработало?"}
  MATCH -->|"да"| RES["Цвет правила<br/>+ фиксация rule_version_id"]
  MATCH -->|"нет"| NEXT{"Есть ещё<br/>правила?"}
  NEXT -->|"да"| EVAL
  NEXT -->|"нет"| DEFAULT["Цвет по умолчанию<br/>+ пометка «не покрыто правилами»"]
  RES --> LOG["triage_assessment_inputs:<br/>какие значения были на входе"]
  DEFAULT --> LOG
  LOG --> OP["Показ оператору<br/>с обоснованием"]

«Не покрыто правилами» — не то же, что «зелёный»

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

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

Недостающие данные¶

[ПР] Правило не может быть оценено, если нужного показателя нет.

Ситуация	Поведение
Показатель отсутствует	Правило не срабатывает и не блокирует остальные; факт нехватки фиксируется
Показатель есть, но не нормализован (неизвестная единица)	Правило не применяется; обращение помечается «требует внимания»
Отсутствуют все ключевые показатели	Результат «не покрыто правилами», обязательная оценка человеком

Шесть ключевых показателей¶

Из набора данных СМП движок использует прежде всего:

Показатель	LOINC	Роль
Шкала ком Глазго	`9269-2`	Уровень сознания — сильнейший предиктор тяжести
Артериальное давление	`85354-9` (`8480-6`/`8462-4`)	Гемодинамика
Пульс	`8867-4`	Гемодинамика
Частота дыхания	`9279-1`	Дыхательная недостаточность
Сатурация	`2708-6`	Дыхательная недостаточность
Гликемия	`2339-0`	Метаболические состояния

Дополнительно учитываются: возраст, травма (п. 15), предварительный диагноз СМП (п. 22), приоритет вызова (п. 6).

Расхождение по температуре

Операционные требования включают температуру в набор оценки самообращений (FR-T-15: «пол — температура — состояние — вес — дыхание»), но в обязательном перечне паспорта для данных СМП температура отсутствует.

Разрешение: температура — обязательный вход для самообращений (измеряется на месте) и необязательный для СМП-пациентов. Правила, использующие температуру, должны корректно работать при её отсутствии — см. таблицу недостающих данных выше.

Сортировка самообращений¶

[ОП] Анонимная очередь: на момент обращения паспортная часть не заполняется и документация не печатается — «как в живой очереди».

flowchart LR
  A["Кнопка на терминале<br/>«ЗАРЕГИСТРИРОВАТЬ ОБРАЩЕНИЕ<br/>В ПРИЕМНЫЙ ПОКОЙ»"] --> B["Номер в очереди<br/>на сортировку"]
  B --> C["Вызов на сортировку"]
  C --> D["Оценка состояния:<br/>обращение · пол · температура<br/>состояние · вес · дыхание"]
  D --> E["Присвоение цвета"]
  E --> F["Талон К43 / В34 / П45"]
  F --> G["Отсортированная очередь<br/>на оформление"]

[ОП] Предусмотрена также быстрая сортировка — простое присвоение цвета без заполнения формы («ты жёлтый», «ты красный»). Реализуется как triage_assessments.mode = 'manual' с обязательным указанием автора; rule_version_id при этом NULL.

Минимизация ПДн — не побочный эффект, а требование

Анонимная очередь означает, что до оформления система хранит только медицинские параметры оценки, без паспортной части. Это прямо соответствует требованию минимизации персональных данных и снижает объём ПДн, обрабатываемых системой. Реализация, требующая ФИО на входе, нарушает и операционное требование, и принцип минимизации. См. «Безопасность».

Приоритетная очередь на оформление¶

[ОП] Вызов идёт по номерам талонов: красные → жёлтые → зелёные.

flowchart TB
  Q["Очередь на оформление"] --> R["🔴 К43-xx<br/>вызываются первыми"]
  R --> Y["🟡 В34-xx<br/>после красных"]
  Y --> G["🟢 П45-xx<br/>последними"]

  R -.->|"внутри цвета"| RO["по времени постановки<br/>enqueued_at ASC"]
  Y -.-> YO["по времени постановки"]
  G -.-> GO["по времени постановки"]

Реализация: triage_queue.priority_rank вычисляется из цвета, внутри цвета — сортировка по enqueued_at.

Зелёные не должны ждать бесконечно

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

[ПР] Смягчение: норматив времени выбытия (FR-T-21) действует для каждого цвета. При приближении к sla_deadline обращение повышается в ранге независимо от цвета, а нарушение норматива фиксируется в sla_breached и попадает в отчётность. Конкретные нормативы в минутах — [?], требуют утверждения (R-2).

Нумерация талонов¶

[ОП] Формат кодов: К43 (красный), В34 (жёлтый), П45 (зелёный).

[?] Правило генерации номеров неизвестно. Буквы соответствуют цветам (Красный, ...жёлтый→В?, ...зелёный→П?), но происхождение чисел 43/34/45 из источников не выводится. Возможные трактовки: фиксированный префикс серии, номер кабинета, код отделения.

[ПР] До получения ответа реализуется конфигурируемая схема: {префикс_цвета}{серия}-{порядковый_номер}, где префикс и серия задаются настройками УЗ, а порядковый номер сбрасывается ежесуточно. Это позволяет воспроизвести любую из трактовок без изменения кода.

Режим массового поступления¶

[ТЗ] Постановление МЗ РБ № 62 от 30.06.2025 регламентирует цветовую систему «светофор» при массовом поступлении пациентов с травмами. Маркировка сейчас наносится на кожу или повязки вручную — автоматизация этой процедуры и есть целевой сценарий проекта.

flowchart TB
  ACT["Активация режима<br/>массового поступления"] --> UI["Упрощённый интерфейс:<br/>один экран, крупные кнопки"]
  UI --> FAST["Быстрое присвоение цвета<br/>без формы оценки"]
  FAST --> PRINT["Печать цветного браслета<br/>термотрансферный принтер"]
  PRINT --> QUEUE["Очередь по цветам"]
  QUEUE --> RESORT["Пересортировка<br/>по мере поступления ресурсов"]

Отличия от штатного режима:

Аспект	Штатный	Массовое поступление
Форма оценки	Полная	Минимальная: цвет одним касанием
Режим оценки	`rules`	`mass_casualty`
Паспортная часть	При оформлении	Откладывается полностью
Идентификация	Талон + браслет	Браслет обязателен — единственный идентификатор
Пересортировка	По ухудшению	Регулярная, по мере освобождения ресурсов

Совместимость со «светофором» — обязательна

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

Сверка цветовой модели с Постановлением № 62 — обязательная задача стадии проектирования, до реализации движка правил. Задача E6-1 в backlog.

Аудит решений сортировки¶

Каждая оценка сохраняет:

Что	Зачем
`color`, `ticket_code`	Результат
`mode`	Как получен: правилами, вручную, в режиме МП
`rule_version_id`	По какой редакции правил — правила меняются, разбор случая требует знать какие действовали
`assessed_by`	Кто
`override_reason`	Если человек изменил результат правил — почему
`triage_assessment_inputs`	Какие значения были на входе — показатели меняются, без снимка решение невоспроизводимо
`signature_ref`	ЭЦП результата (FR-C-3)

Без снимка входных значений разбор случая невозможен

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