Patients
Patient registry with an interactive odontogram by tooth surfaces. This is production-grade UX scaffolding: the data model persists later without rewriting UI logic.
| Patient | ID | Age | Status | Notes |
|---|---|---|---|---|
| María González | PT-0001 | 34 | Active | Routine checkup |
| Carlos Méndez | PT-0002 | 41 | Follow-up | Post-surgery review |
Odontogram · María González
Click any surface to cycle: normal → alert → treated. Click the small dot on a tooth to reset that tooth.
Clinical detail
Select a tooth surface to see a clinical description (diagnosis + procedure + notes) for decision-making.
Treatment plan
Active patient · María González
This list is generated from surface-level clinical entries. Block 4 adds deterministic cost/time estimates per procedure with manual override.
| Tooth | Surface | Status | Diagnosis | Procedure | Est. time | Fee | Cost mode | Notes | Mode | Actions |
|---|---|---|---|---|---|---|---|---|---|---|
| No treatment plan items yet. Click a tooth surface above to create clinical entries. | ||||||||||
Demo note: costs are deterministic estimates for demo. In production, these come from fee schedules and provider rules.
Interaction model
Surface-level states (O/M/D/B/L) are stored per tooth and per patient.
Production path
Tomorrow’s demo uses this UI. Later we swap only the SVG shapes for realistic anatomy — same data model, same logic.
Clinical credibility
Decision-makers see a real odontogram workflow: not a toy grid, but tooth surfaces that behave like a serious system.
Demo mode: all odontogram data is in-memory (no backend, no persistence). This is intentional and aligns with the approved demo principles.