Files
vigilcare-clinical/docs/decisions/clinical-refactor-sofa-gcs.md
T

21 lines
3.3 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
```markdown
# Clinical Refactor — SOFA / GCS Interview Questions
## Q1: Why did you replace SIRS with SOFA for sepsis detection?
SIRS (Systemic Inflammatory Response Syndrome) uses four criteria — temperature, heart rate, respiratory rate, white blood cell count — to screen for sepsis. The problem is non-specificity: a patient who just exercised, is anxious, or has a mild viral infection can meet ≥ 2 criteria. The Sepsis-3 consensus (2016) replaced SIRS with SOFA (Sequential Organ Failure Assessment) because SOFA measures actual organ dysfunction across six systems. A delta SOFA ≥ 2 from baseline in the presence of suspected infection is both more specific and more clinically actionable than SIRS. We kept qSOFA as a bedside screening tool that recommends ordering SOFA labs, matching the Sepsis-3 two-tier approach.
## Q2: How does your system handle the fact that SOFA requires lab values that aren't continuously available?
Three strategies: **carry-forward with staleness** — the most recent lab value is cached in Redis with a configurable TTL (default 24 hours) and classified as CURRENT (< 12h), STALE (1224h), or EXPIRED (> 24h). Stale values are still used for scoring but flagged in `sofa_scores.staleness_flags` JSON so clinicians know the score is based on older data. Second, **SpO₂/FiO₂ fallback** — when arterial blood gas isn't available (common on general wards), we use the SpO₂/FiO₂ ratio as a proxy for the respiratory component, per Rice et al. (2007). Third, **partial scoring** — SOFA baseline is only established when ≥ 4 of 6 organ systems have data, preventing false low baselines that would inflate the delta.
## Q3: Why did you keep qSOFA after removing SIRS, and how does the screening workflow differ from the old SIRS alert?
qSOFA is a validated bedside screening tool — three simple criteria (respiratory rate, blood pressure, mental status) that any nurse can assess without labs. The key change is clinical positioning: under SIRS, meeting ≥ 2 criteria immediately declared sepsis and triggered the treatment bundle. Under the new workflow, qSOFA ≥ 2 creates a WARNING-level screening alert (`QSOFA_SCREEN`) that recommends ordering SOFA labs (PaO₂/FiO₂, platelets, bilirubin, creatinine). Only when those labs confirm organ dysfunction — SOFA delta ≥ 2 — does the system declare sepsis (`SOFA_SEPSIS`) and trigger the bundle. This prevents false-positive bundle activations that occurred with SIRS.
## Q4: How did you handle the GCS → SOFA → NEWS2 → qSOFA dependency chain?
GCS feeds into three downstream systems: SOFA CNS scoring (GCS → 04 organ score), NEWS2 consciousness (GCS 15 = score 0, GCS < 15 = score 3), and qSOFA altered mentation (GCS < 15 = criterion met). Architecturally, the GCS Kafka consumer computes the total and caches it in Redis. Downstream consumers (SOFA, NEWS2, qSOFA) read GCS from Redis when triggered. The resolution order is **GCS-first with AVPU-fallback** — if GCS components exist, they take priority; if only AVPU is available (legacy data), the old mapping still works. This avoided a breaking migration while making GCS the preferred consciousness assessment going forward.
```
Also update `docs/clinical-scoring-refactor-summary.md` — add a "Phase 29 scenarios" section listing the three new scenario IDs and what each validates.