# Model: DoctorClinic (pivot)

**Table**: `clinic_doctor_branch` (new) · **Pivot model** for `Doctor` ↔ `Core\Branch`

## Purpose

The commercial facts of one doctor working at one branch: this is where the brief's "same doctor,
two branches, two different prices and schedules" rule lives. One row per (doctor, branch) pair.

## Fields

| Column | Type | Constraints | Notes |
|---|---|---|---|
| `id` | bigint | PK | using a real model (not an anonymous pivot) because it has its own child table (`clinic_doctor_schedules`) and its own business logic |
| `doctor_id` | bigint | `foreignId('doctor_id')->constrained('clinic_doctors')->cascadeOnDelete()` | |
| `branch_id` | bigint | `foreignId('branch_id')->constrained('branches')->cascadeOnDelete()` | |
| `visit_price` | decimal(10,2) | | in-clinic visit price, set by Clinic Admin |
| `consultation_price` | decimal(10,2) | | online consultation price, set by Clinic Admin |
| `slot_duration_minutes` | unsignedSmallInteger | default 15 | e.g. 15/20/30 |
| `is_active` | boolean | default true | lets a Clinic Admin temporarily hide a doctor from booking at this branch without removing the pairing/history |
| `created_at` / `updated_at` | timestamp | | |

Unique constraint: `(doctor_id, branch_id)` — a doctor has exactly one pricing/slot config per
branch (multiple schedule rows live in the child `DoctorSchedule` table, not here).

## Relationships

| Relation | Type | Target |
|---|---|---|
| `doctor()` | `belongsTo` | `Doctor` |
| `branch()` | `belongsTo` | `Core\Branch` |
| `schedules()` | `hasMany` | `DoctorSchedule` |
| `bookings()` | `hasMany` (via matching `doctor_id`+`branch_id` on `clinic_bookings`) | `Booking` |

## Decisions

- Modeled as a real Eloquent model with its own table (`Illuminate\Database\Eloquent\Model`, used
  as the pivot via `->using(DoctorClinic::class)` on the `Doctor::branches()` relation) rather
  than a plain array pivot, because it owns child records (`schedules()`) and has its own service
  (`DoctorScheduleService`) — matches how this ERP already prefers explicit pivot models with
  business logic over bare `belongsToMany` arrays (e.g. `JournalEntryLine`, `PayrollLine` are
  first-class models, not anonymous pivots).