Skip to main content
Version: 1.0.0
Status: 📝 Planned
Last Updated: 2026-03-02
Spec: PM-28 PM System Configuration & Admin Settings
Constitution Reference: Section 1.2 (Core Independence), Section 1.3 (Integration Patterns)

​
Overview

PM-28 provides the single admin surface (“Practice Management Settings”) for all org-level pm_module_settings keys consumed by PM billing, payments, registration, and eligibility workflows. It does not introduce new tables or data flows; it is a UI aggregator over the existing pm_module_settings row (one per org). Key tables: pm_module_settings (existing; columns owned by consumer spec migrations)

​
Integration Points (from spec)

​
Platform Integration Layer Usage

  • PF-01: Organization context via pf_organizations; organization_id is the partition key for the pm_module_settings upsert.
  • PF-30: Permissions platform layer; useHasPermission('pm.settings.view') / useHasPermission('pm.settings.manage') gate page access and save action.

​
Event Contracts

No new events defined in PM-28. Settings changes do not publish domain events (settings are read by consumer hooks on demand). Future enhancement: pm_settings_updated event if consumers require reactive cache invalidation.

​
API Contracts

Internal PM only. usePmModuleSettings (read) and usePmModuleSettingsUpsert (write) in src/cores/pm/hooks/; no external API exposed. Consumer specs (PM-01, PM-08, PM-09) read pm_module_settings directly via their own hooks.

​
Integration Matrix

​
Security Notes

  • pm_module_settings RLS restricts all reads and writes to the user’s organization_id; no cross-org access is possible.
  • updated_by populated on every upsert by usePmModuleSettingsUpsert; provides audit trail per compliance requirement.
  • Permission keys added via migration to pf_module_permissions and pf_role_permissions; PF-30 enforces at hook level.