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
1002 B
Markdown
16 lines
1002 B
Markdown
# Dental attributes of a service live in an extension table, not on ServiceItem
|
|
|
|
Whether a service is priced per tooth, per surface or per canal — and whether booking it must ask for a
|
|
tooth at all — is dental-only knowledge, but `ServiceItem` is shared by every practice domain. Those
|
|
attributes therefore sit in a one-to-one `dental_service_profiles` row in the Dental context, keyed by
|
|
`service_item_id`, so a beauty clinic carries no dental columns and the next domain is not invited to add
|
|
its own set to the shared table. The cost is a join whenever the dental profile is needed, which is the
|
|
same pattern the codebase already uses elsewhere.
|
|
|
|
## Consequences
|
|
|
|
The reverse choice was made deliberately one level down: the tooth and surfaces a visit line was actually
|
|
billed for are columns on `SessionService` itself, because that row is the clinical and financial record
|
|
of the visit rather than shared configuration, and splitting it would allow a billed line to lose its
|
|
target unnoticed.
|