hamed
2f030edef1
- Introduced phase 4 documentation detailing treatment estimates, data models, state machines, API endpoints, and new dashboard metrics. - Added phase 5 documentation covering consumables, lab operations, periodontal charts, sterilization cycles, clinical images, and a checklist for professional review. - Created a preset content document outlining default dental service packages and protocols for clinics.
16 lines
917 B
Markdown
16 lines
917 B
Markdown
# Teeth are not Treatment Areas
|
|
|
|
A Treatment Area is a `CatalogCategory` snapshotted onto a case, which made "one category per tooth"
|
|
look like a free way to get dental charting. It was rejected: FDI tooth numbering is a universal fact,
|
|
not a per-clinic taxonomy, so it would duplicate 32 to 52 identical rows into every clinic's service
|
|
tree, surfaces would need a further level below that, and the persistent condition of a tooth — missing,
|
|
crowned, implanted years before the patient ever arrived — has nowhere to live on a settings row.
|
|
A tooth is instead an FDI `smallint` on the record that targets it, and tooth condition is its own
|
|
snapshot table in the Dental context.
|
|
|
|
## Consequences
|
|
|
|
Tooth condition must be updated after each visit, and that projection lives in exactly one class rather
|
|
than being spread across controllers. In exchange, rendering a chart is one query and never a replay of
|
|
history.
|