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.
1002 B
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.