# Domain 13 — Partner Centers (launch) & Future

← Database Model

Related: business requirements — Tax, invoicing & legal.

### `partner_centers` [MVP] — NEW #

Role: A licensed home-nursing center (مرکز مشاوره و ارائه مراقبت‌های پرستاری در منزل) that sponsors nurses and is plausibly the merchant-of-record and invoice issuer at launch. Why this is the single most launch-critical addition: the research's #1 go-to-market recommendation is to operate by subcontracting to an already-licensed center (the Asanism model) while Balinyaar's own MoH permit is pending — the center is what makes the operation legal, may be who the IPG settles to, and clears the BNPL onboarding gate (which needs a جواز کسب + eNamad the company/center holds, not each nurse). Distinct from the future `organizations` (employer) table — this is the licensing/launch sponsor.

Field | Type | Notes
--- | --- | ---
`id` | BIGINT PK |
`name` | NVARCHAR(300) |
`legal_entity_type` | NVARCHAR(30) |
`moh_establishment_permit_no` | NVARCHAR(100) | پروانه تأسیس
`technical_director_nurse_user_id` | BIGINT FK → users NULL | مسئول فنی
`technical_director_license_no` | NVARCHAR(100) NULL |
`enamad_code` | NVARCHAR(100) NULL |
`settlement_iban` | NVARCHAR(34) (enc) NULL | If merchant-of-record
`is_merchant_of_record` | BIT |
`commission_rate` | DECIMAL(5,4) NULL | Center's cut, if any
`admin_user_id` | BIGINT FK → users | Center's dashboard account
`is_active`, `verified_at`, timestamps | … |

Relations: 1:N → `nurse_profiles` (sponsors), `bookings` (legally covered by), `invoices` (issuer).

### `organizations` / `organization_nurses` [DEFERRED] #

Role/Why: The future employer model (nursing companies adding their employed nurses). Modeled-but-inactive — no launch table references them, so adding them later is a pure additive migration. Kept distinct from `partner_centers` (launch licensing) to avoid conflating "sponsor for legality" with "employer."

### `fraud_flags` [DEFERRED] #

Role/Why: Output of a future ML fraud service. Premature for a no-traffic MVP; `support_alerts` (`fraud_signal` type) covers rule-based signals manually. Inactive stub.

### `recurring_booking_schedules` [DEFERRED] #

Role/Why: RFC-5545 recurrence for repeating care patterns. Note: the concrete multi-day need is now met by `booking_sessions`; this remains deferred for true open-ended recurrence. Inactive stub.

↑ Back to top