Parameter triage codes

Доменный enum для action priority на параметре в V2.5 rich-output. Не FHIR-стандарт. Появился в session d9de9416 (BG-1323).

Status: exploratory; есть Python ↔ TS drift (см. ниже). Реализация в Postgres parameterAnalysis.triage column (V2.5 в worktrees), не в production deploy.

Production-canonical (Python)

fhir-services-v25/src/models/parameter_analysis.py:

TriageLevel = Literal[
    "urgent_doctor",      # immediate clinical attention required
    "routine_doctor",     # schedule a doctor visit
    "monitor",            # repeat / track over time
    "ok_in_context",      # abnormal in isolation but fine given related context
]

4 кода. Это source-of-truth.

Drift в TS port

packages/analysis-core/src/types/parameter-analysis.types.ts (worktrees v2-5-fhir, v2-5, ui-v2-5-migration):

export type V2TriageLevel =
  | "urgent_doctor"
  | "routine_doctor"
  | "monitor_patient"   // ← drift: extra _patient suffix vs Python "monitor"
  | "ok_in_context";

Bug: monitor_patient ≠ Python monitor. Если TS пишет в shared FHIR resource, downstream Python parsers не recognize. Portage gap не обнаруженный в snake_case ↔ camelCase boundary discussion (dd17b3fd).

Что чинить: align TS с Python (monitor, без _patient).

Plan-файл inconsistency

~/vault/plans/v2-5-rich-output-to-fhir.md имеет две разные taxonomies в разных строках:

Line 53 (extension definition): {urgent_doctor, routine_doctor, monitor_patient, ok_in_context} — matches TS drift
Line 170 (CodeSystem definition): {ok_in_context, routine_doctor, urgent_doctor, red_flag} — red_flag не существует ни в Python, ни в TS

red_flag — выдумка / опечатка. Plan-файл нужно поправить align с Python canonical.

Triage ≠ interpretation

Различать:

interpretation (H/L/N/A) — про clinical state значения (high/low/normal/abnormal). См. fhir-observation и parameter-range-type-prompt.
triage (ok_in_context/routine_doctor/monitor/urgent_doctor) — про action level для пациента/врача.

Параметр может иметь interpretation: H но triage: ok_in_context (если в контексте пациента это OK — например, у спортсмена повышенный креатинин ≠ urgent).

Namespace open

Plan-файл указывает https://bloodgpt.ai/fhir/CodeSystem/triage. Текущая production deploy bloodgpt-for-business использует http://bloodgpt.com/fhir/CodeSystem/... для остальных CodeSystems (e.g., panel-categories).

Open: bloodgpt.ai vs bloodgpt.com — какой namespace planning для V2.5 deploy. Возможно опечатка plan’а; possibly intentional move к .ai brand.

Открытые вопросы

Align TS с Python (monitor без _patient).
Поправить plan-файл — убрать red_flag (line 170 inconsistency).
Есть ли FHIR-стандарт для action priority?:
- Task.priority / ServiceRequest.priority — routine | urgent | asap | stat
- HL7 v3 ActPriority — R/UR/A/S
- Может покрыть наши уровни. Тогда custom CodeSystem не нужен.
ok_in_context — это inaction, не priority level. FHIR action-priority enums начинаются с “что-то делать” — нет “ничего не делать”. Использовать absence of priority (no Task created) vs explicit “no action needed” code?
Calibration с командой — Ильдар явно: нужно поговорить с коллегами, может ли меняться эта таксономия.

Связано

fhir-clinical-impression — где живёт triage extension (proposed для V2.5)
fhir-observation — interpretation (H/L/N/A) — другая ось classification
fhir-service-request — priority field (routine/urgent/asap/stat) — может пересекаться с triage
parameter-range-type-prompt — где interpretation генерируется (отдельно от triage; triage — отдельный шаг pipeline)
Python canonical: /home/i/JOBS/BloodGPT/fhir-services-v25/src/models/parameter_analysis.py
TS portage: bloodgpt-for-business/worktrees/v2-5-fhir/packages/analysis-core/src/types/parameter-analysis.types.ts

Источники

Источники: ¹ ².

Сноски

HL7 v3 ActPriority, accessed 2026-05-17, https://terminology.hl7.org/CodeSystem-v3-ActPriority.html. ↩
FHIR R4 RequestPriority, accessed 2026-05-17, https://hl7.org/fhir/R4/valueset-request-priority.html. ↩

Quartz 4

Explorer