# Flow: e-Prescription

**Actors**: Doctor, Patient
**Phase**: 8

## Writing a prescription

1. From an encounter (draft or finalized), doctor opens the Prescription section →
   `PrescriptionService::create($encounter, $doctor)` creates the `Prescription` header row.
2. Doctor adds line items using the same cascading-picker AJAX pattern already established in
   `resources/views/dashboard/admin/clinic/schedules/index.blade.php`: type/select a medication
   from `clinic_medications` (autocomplete) → dose/frequency/duration/route/instructions fields
   appear → `PrescriptionService::addItem()`. If the drug isn't in the catalog, the doctor types
   `medication_name_freetext` directly instead of picking one — never blocked.
3. Doctor can reorder/remove items before finalizing the encounter (line items belong to the
   prescription, independent of the encounter's own `draft`/`finalized` status).

## No inventory interaction — explicit

4. At no point does this flow read from, write to, or reference any `Inventory\*` model or table.
   Writing/finalizing a prescription has zero effect on stock — confirmed scope per the user's
   decision (see `06-overview-medical-center-expansion.md`).

## Reading it back

5. Patient reads their structured prescription via the extended `Site\Clinic\MedicalRecordController`
   (or a dedicated `PrescriptionController` if the existing one gets too crowded — decide at build
   time).
6. Phase 12 (`plan_Clinics/09-roadmap-phase6-13.md` Phase 12) adds a print view rendering the
   prescription header + all line items on one printable page.

## Editing after issue

7. Same audit rule as every other clinical document: an edit after `issued_at` writes an
   `ActivityLog` entry and notifies the patient, matching `04-visit-consultation-flow.md` step 7.