Document the specialty module design standard for Care.
Deploy Ladill Care / deploy (push) Successful in 1m5s

Capture the unified workflow, UI, queue, and billing blueprint, and add a Cursor rule so specialty work follows the shared shell instead of one-off apps.

Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
isaacclad
2026-07-18 09:40:39 +00:00
co-authored by Cursor
parent e9a76fec80
commit ad04f0cec8
2 changed files with 253 additions and 0 deletions
+31
View File
@@ -0,0 +1,31 @@
---
description: Ladill Care specialty module architecture and UX standard
globs: config/care_specialty_modules.php,app/Services/Care/SpecialtyModule*.php,app/Http/Controllers/Care/Specialty*.php,resources/views/care/specialty/**,resources/views/care/settings/modules.blade.php
alwaysApply: false
---
# Specialty modules — Care design standard
Full standard: `docs/specialty-module-design-standard.md`.
## Non-negotiables
- Specialty modules are **native Care extensions**, not standalone apps.
- Design **workflow first** (stages, queues, payment checkpoints, completion), then screens.
- Reuse Care engines: Workflow, Queue, Billing, Appointments, Documents, Permissions, Reports.
- Use **identical primary actions** (Call Next, Start Consultation, Order Test, Prescribe, Generate Invoice, Discharge, …).
- Prefer extending **`Visit`** as the clinical episode unit before inventing a separate Episode model.
- Contribute to one **patient timeline** — do not create parallel charts.
- Prefer **structured clinical data** over free-text-only fields (AI-ready).
## Current reality
Today specialties are a thin layer: catalog activate → departments/queue stubs → generic `specialty/show` waiting list. Do **not** build deep per-specialty UIs until the shared specialty shell exists (KPI dashboard, patient header, left nav Overview/Visits/History/Module Tabs, billing catalog hooks).
## When adding or deepening a module
1. Add/update catalog entry in `config/care_specialty_modules.php` (and department type if needed).
2. Define specialty workflow stages + queue map in docs or config — not only a nav label.
3. Wire through the **shared specialty shell**, not a one-off Blade page.
4. Seed billable services into Billing — never hardcode invoice lines in the specialty UI.
5. Gate with role allowlists + practitioner department assignment (existing `SpecialtyModuleService` patterns); Emergency/Blood Bank stay `default_on_paid_plans`.