Capstone: PriorAuth

## Data hygiene (non-negotiable)
- All patient data in this project is SYNTHETIC.
- Requests reference patients by opaque patient_ref (e.g. "PT-3920") —
  never name, DOB, SSN, or address. No such fields may exist in any schema.
- Log lines and error messages NEVER include patient_ref or clinical flags;
  reference requests by request_id only.
- The engine (engine.py) is pure: no Flask, no SQL, no I/O, no logging.
- Decisions are deterministic: same request + same rules version = same
  outcome and same reason codes, always.

PS> pytest tests/test_engine.py -v
tests/test_engine.py::test_72148_approved_with_6_weeks_therapy PASSED
tests/test_engine.py::test_72148_denied_therapy_not_met PASSED
tests/test_engine.py::test_72148_waived_by_neuro_red_flag PASSED
tests/test_engine.py::test_icd_prefix_mismatch_denied PASSED
tests/test_engine.py::test_unknown_cpt_pending_review PASSED
tests/test_engine.py::test_97110_quantity_at_exact_limit PASSED
tests/test_engine.py::test_97110_quantity_exceeded_pends PASSED
...
24 passed in 0.34s

Audit this codebase against the "Data hygiene" section of GEMINI.md:
1. Does any log statement or error message include patient_ref or clinical flags?
2. Can any endpoint mutate or delete audit rows?
3. Is rules_version stored with every decision?
List violations with file:line, or confirm each rule passes.

# APPROVED (72148, ICD M54.50, 8 weeks therapy)
{"request_id":"REQ-0007","outcome":"APPROVED",
 "auth_number":"PA-2026-0007","valid_through":"2026-09-09",
 "reasons":[{"code":"ALL_CRITERIA_MET","detail":"icd allowed; therapy 8/6 weeks"}],
 "rules_version":"2026.06-v1"}                                 <-- 201

# DENIED (72148, only 4 weeks therapy, no red flags)
{"request_id":"REQ-0011","outcome":"DENIED",
 "reasons":[{"code":"CONSERVATIVE_THERAPY_NOT_MET",
             "detail":"4 weeks documented; 6 required"}],
 "rules_version":"2026.06-v1"}                                 <-- 201

# PENDING_REVIEW (unknown CPT 99999)
{"request_id":"REQ-0019","outcome":"PENDING_REVIEW",
 "reasons":[{"code":"UNKNOWN_CPT","detail":"99999 not in criteria set"}],
 "rules_version":"2026.06-v1"}                                 <-- 201

PS> curl http://localhost:5002/audit/REQ-0011
[{"event":"EVALUATED","rules_version":"2026.06-v1","at":"2026-06-11T10:42:18",
  "conditions":[{"check":"icd_prefix_allowed","result":"PASS"},
                {"check":"conservative_therapy_weeks>=6","result":"FAIL"}]}]
# note: request_id only — no patient_ref anywhere in audit or logs

Policy update effective 2026-07-01, ship as rules version "2026.07-v2"
in a NEW file rules/criteria_2026_07.json (v1 stays untouched):
1. 72148: conservative therapy requirement rises from 6 to 8 weeks.
2. New criterion: CPT 73721 (MRI knee), allowed ICD prefixes S83/M23/M25,
   requires conservative_therapy_weeks >= 4, waived by red_flag_locked_knee.
3. The service selects the rules file by decision date: requests on/after
   2026-07-01 use v2, earlier use v1. Decision date is injectable for tests.
4. Tests: the SAME request approved under v1 (7 weeks therapy) is DENIED
   under v2 — prove version selection works both ways.
Plan first. Do not modify engine.py unless something truly requires it.

PS> pytest tests/test_versioning.py -v
tests/test_versioning.py::test_7wk_request_approved_under_v1 PASSED
tests/test_versioning.py::test_7wk_request_denied_under_v2 PASSED
tests/test_versioning.py::test_decision_date_selects_rules_file PASSED
tests/test_versioning.py::test_73721_knee_mri_new_in_v2 PASSED
4 passed in 0.18s

# identical clinical facts, different decision dates:
decision date 2026-06-15  ->  APPROVED   (rules_version 2026.06-v1, 6 wks required)
decision date 2026-07-02  ->  DENIED     (rules_version 2026.07-v2, 8 wks required,
                                          reason CONSERVATIVE_THERAPY_NOT_MET)
# both decisions sit in the audit trail, each citing its own rules_version