# Model: BariatricAssessment

**Table**: `clinic_bariatric_assessments` (new, Phase 7)

## Purpose

Structured pre-surgical workup for an obesity/bariatric-surgery candidate — comorbidities,
psychological readiness, and the proposed procedure — feeding both the Phase 10 surgery
scheduling flow and the Phase 13 "average weight loss" outcomes report (via `Vital.bmi` at
assessment time vs. later encounters). Optional 1:1 extension of `Encounter`.

## Fields

| Column | Type | Constraints | Notes |
|---|---|---|---|
| `id` | bigint | PK | |
| `encounter_id` | bigint | `foreignId('encounter_id')->constrained('clinic_encounters')->cascadeOnDelete()` unique | |
| `bmi_at_assessment` | decimal(4,1) | | denormalized copy of `Vital.bmi` for this encounter, kept even if the vitals row is later corrected, since eligibility decisions were made against this exact value |
| `comorbidities` | json | nullable | checklist: e.g. `{"type2_diabetes": true, "hypertension": true, "osa": false, "dyslipidemia": true}` — same "small JSON checklist" pattern already used by `clinic_patient_profiles.medical_history` |
| `psych_evaluation_done` | boolean | default `false` | |
| `psych_evaluation_notes` | text | nullable | |
| `proposed_procedure` | string | nullable | e.g. `sleeve_gastrectomy` / `gastric_bypass` / `gastric_band` — a short controlled list, seeded via `clinic_medical_history_options` (`type = 'surgery_procedure'`) per `06-overview-medical-center-expansion.md`'s reuse decision, or a plain enum if the list stays this short |
| `surgical_readiness` | string | default `'pending'` | `pending` / `ready` / `not_recommended` |
| `readiness_notes` | text | nullable | |
| `created_at` / `updated_at` | timestamp | | |

## Relationships

| Relation | Type | Target |
|---|---|---|
| `encounter()` | `belongsTo` | `Encounter` |

## Decisions

- `bmi_at_assessment` is deliberately duplicated from `Vital.bmi` rather than always joined live —
  eligibility/readiness decisions are made against the value recorded at assessment time, and that
  historical fact must stay stable even if a later data-entry correction changes the linked
  `Vital` row.
- `comorbidities` as JSON follows the exact precedent already set by
  `clinic_patient_profiles.medical_history`/`surgical_history`/`medication_history` — no new
  pattern introduced, same reasoning (a small, evolving checklist that doesn't need its own
  relational table).
- No FK to `SurgeryCase` here — that link is the other direction (`SurgeryCase` doesn't need to
  reference the assessment; the assessment record is looked up via the patient's encounter
  history when a surgeon reviews readiness before scheduling in Phase 10).