What it is, where the code lives, how a case flows, and the 5 rules you must not break. Two more boards cover the data model.

① What the module does

The anesthesia record (AIMS) for a procedure — the full clinical chart + the charge ticket, in one place.
Covers the whole case lifecycle: Pre-Op assessment → Intra-Op live charting (vitals/meds/events/gas/fluids) → PACU recovery → Billing.
Goal mirrors the platform: turn 15–20 min of documentation into 2–3 min, while capturing every billable item (blocks, lines, field-avoidance "found money") deterministically.

② ⚠️ The #1 fact that surprises everyone — where it RUNS

There is an aims-web app and an aims.synexar.net domain, but the live anesthesia UI does NOT run there.
The anesthesia frontend is a shared Angular library, packages/anesthesia, compiled INTO apps/gi-web (the GI app). It ships on staging.synexar.net / synexar.net via the gi-web pipeline.
So: frontend change → deploy gi-web, not aims-web. The aims-web CF deploy is orphaned. (If you "fix" anesthesia in aims-web, nothing changes on staging.)

③ Service topology (request path)

Browser

Angular 18 SPA

→

Azure Front Door

staging.synexar.net

→

SWA: gi-web

+ packages/anesthesia (UI)

→

clinical-api

proxies /api/anesthesia/*

→

aims-api

Synexar.AimsApi (.NET 8)

→

PostgreSQL

RLS by organization_id

clinical-api → aims-api hop is a proxy keyed off AimsApi:BaseUrl. 401 on the anesthesia API = it's up; a transient 403 only appears mid-deploy slot restart.
SynForm layouts (the form definitions) come from GET /api/synform/layouts/{key} as JSONB.

④ The case lifecycle = the phases you'll see in the UI

Pre-Op

airway · ASA · baseline · history
SynForm: pre-anesthesia-v1

▶

Intra-Op (Canvas)

live vitals · meds · events
gas · fluids · equipment

▶

Procedures

6 SynForms: blocks /
spinal / epidural / lines

▶

PACU

Aldrete scores · pain
disposition

▶

Billing

charge ticket: CPT · ICD-10
blocks · found-money

⑤ Frontend — packages/anesthesia/src/lib

Phase components (anesthesia-case-page/phases/): preop-phase, intraop-flow (Canvas/Grid/Graph), recovery-phase (PACU), billing-phase.
Panels/tabs: procedures-panel (the 6 SynForms), equipment-panel, charge-ticket-tab.
State: AnesthesiaCaseStateService (signals — active phase, caseId, case data).
HTTP: AnesthesiaService (chart CRUD) · ChargeTicketService (billing).
Angular rules: standalone + signals, separate .html/.scss, p-select not p-dropdown.

⑥ Backend — backend/aims-api/Synexar.AimsApi

Controllers (/api/anesthesia/*): AnesthesiaCaseController, …ChargeTicketController, vitals/events/equipment/gas/fluids/meds, …PdfController.
Services: AnesthesiaProcedureBillingBridge (procedure → charge), FieldAvoidanceDetectionService (found-money + 76942), ChargeTicketAutoPopulate / Validation.
Repos (Dapper): AnesthesiaCaseRepository, ChargeTicketRepository.
Stack: ASP.NET Core 8, Dapper, RLS via session-scoped organization_id.

⑦ The 5 rules you must not break

Rules beat AI for billing. CPT is deterministic + NCCI; the LLM never decides a code. (The billing bridge is a hardcoded resolver.)
RLS on every table by organization_id — writes must run inside the org session context. Never a wildcard org=0 for patient data.
PHI never client-cached, never logged (no names / MRN / DOB). HIPAA is non-deferrable.
aims-api migrations are MANUAL — they do NOT auto-apply to staging. Apply by hand to synexar_pulse_staging after merge. (clinical-api has a /migrate endpoint; aims-api does not.)
Verify on staging, not localhost — "done" = seen working on staging.synexar.net via the real authenticated API.

🧭 Where to start reading
1. Open a case → click through Pre-Op → Intra-Op → PACU to feel the flow.
2. procedures-panel + AnesthesiaProcedureBillingBridge — the newest, most self-contained slice (a clean "vertical" from form → DB → charge).
3. Then the data-model boards →

Sources: packages/anesthesia, backend/aims-api/Synexar.AimsApi, anesthesia migrations (clinical-api + aims-api). Routing/billing facts verified against source 2026-06-28.