Domain 10 — Reviews & Patient Records
reviews [CORE]
Role: One customer review per completed booking; enters pending_moderation, published only after admin/AI approval; a low rating raises a support_alert. Why these guards: (a) review creation is allowed only for completed/closed bookings (a review for a cancelled booking is nonsense); (b) every status transition (publish/hide/reject/unpublish) recomputes nurse_profiles aggregates, fixing the inflated-rating-after-hide drift. Fields unchanged (rating 1–5 with CHECK, body, status, moderation fields). Relations: 1:1 → bookings; N:1 → customer_profiles, nurse_profiles; 1:N → review_tag_links.
review_tags_master [MVP] / review_tag_links [MVP]
Role: Standardized tags for quantitative aggregation of qualitative feedback (e.g. "% punctual"). Why MVP-not-core: free-text + rating is enough to launch; structured tags are a phase-2 analytics nicety (additive leaf tables). Relations: reviews N:N review_tags_master.
patient_care_records [MVP]
Role: Nurse-authored clinical notes after a visit, accumulating into a patient-scoped longitudinal history (not booking-scoped). Why patient-scoped: when a different nurse takes over, they read the history before accepting, enabling continuity of care without the family repeating everything. Strict access: owning customer, nurses with a confirmed booking for that patient, admin. All fields encrypted. Relations: N:1 → patients, bookings, nurse_profiles.