theme-healthcare

name	theme-healthcare
description	Healthcare application palette: variants, pages, entities, and flows for building a varied health app. Use when theme_preset is healthcare.

Healthcare theme

Domain

Apps where patients and providers manage appointments, records, prescriptions, and messages. The sensitivity of PHI (protected health info) and the patient↔provider access boundary are what make the exploits feel consequential.

Application variants — pick ONE per lab

Honor any hint in theme_free_text / custom_prompt; otherwise pick one.

• Patient portal — appointments, records, messages, billing for the patient.
• Clinic admin — staff schedule patients, manage charts, billing.
• Telehealth — video visits, intake forms, e-prescriptions.
• Pharmacy — prescriptions, refills, pickup, insurance.
• Lab-results portal — orders, results delivery, provider notes.
• Mental-health / therapy — therapists, session booking, private notes, mood journals.
• Wellness / fitness coaching — programs, check-ins, plans, coach messaging, progress.

Roles — choose the set that fits the variant

• user (patient) — own records, appointments, messages, invoices.
• provider (clinician) — patients assigned to them, charts, prescriptions.
• admin (front desk / billing) — scheduling, all patients, billing.

Most exploits run as user (patient).

Candidate pages — select a coherent subset

Size the subset to endpoint_count. Candidates: dashboard, appointments list/booking, appointment detail, medical records, record/document viewer, prescriptions & refills, secure messages, lab results, billing/invoices, insurance, profile/settings, notifications, provider patient list, provider chart, admin scheduling, video visit room / intake forms (telehealth), refill queue / pickup / insurance claims (pharmacy), lab orders / results delivery / provider notes (lab-results).

Candidate entities (seed tables) — select what the variant needs

• users — id, email, password_hash, role
• patients — id, user_id, dob, mrn, primary_provider_id
• providers — id, user_id, specialty
• appointments — id, patient_id, provider_id, starts_at, status
• records — id, patient_id, kind, body, document_path?
• prescriptions — id, patient_id, provider_id, drug, dosage, refills_left
• messages — id, from_user_id, to_user_id, body, thread_id
• invoices — id, patient_id, amount_cents, status
• insurance_policies — id, patient_id, payer, member_id, group_number

Telehealth (variant):

• video_visits (variant) — id, appointment_id, room_token, started_at, ended_at
• intake_forms (variant) — id, patient_id, appointment_id, answers_json, status

Pharmacy (variant):

• refills (variant) — id, prescription_id, patient_id, status, requested_at, filled_at
• pickups (variant) — id, refill_id, location_id, ready_at, picked_up_at
• insurance_claims (variant) — id, patient_id, prescription_id, payer, amount_cents, status

Lab-results (variant):

• lab_orders (variant) — id, patient_id, provider_id, panel, status, ordered_at
• results (variant) — id, lab_order_id, patient_id, value, reference_range, released_at
• provider_notes (variant) — id, result_id, provider_id, body

Seed several patients across ≥2 providers so cross-patient access is testable.

Candidate user flows — select the ones matching chosen pages/features

1. Dashboard → book an appointment → confirmation.
2. View own medical records → open/download a document.
3. Message a provider → read replies in a thread.
4. Request a prescription refill → status updates.
5. View & pay an invoice → receipt.
6. (provider) Open a patient's chart → add a note / prescription.
7. (provider) Triage assigned patient list → open the next chart.
8. (telehealth) Complete an intake form → join the video visit room.
9. (pharmacy) Submit a refill → track it to the pickup queue → mark picked up.
10. (lab-results) Open a lab order → view released results → read the provider note.

Candidate endpoints — a feature may span several

Endpoints are a shared surface, not owned 1:1 by a feature (a single feature often spans several, and an endpoint can back multiple features). Pick a coherent subset alongside the pages above. Grouped by area:

• records / documents — GET /api/patients/{id}/records, GET /api/records/{id}, GET /api/records/{id}/document?file=
• appointments — GET/POST /api/appointments, GET /api/appointments/{id}
• messages — GET/POST /api/messages, GET /api/messages/{id}
• prescriptions — GET /api/prescriptions, POST /api/prescriptions/{id}/refill
• billing / insurance — GET /api/invoices/{id}, POST /api/invoices/{id}/pay, GET/POST /api/insurance
• telehealth (variant) — GET /api/video-visits/{id}, GET/POST /api/intake-forms
• pharmacy (variant) — GET/POST /api/refills, GET /api/pickups/{id}, GET/POST /api/insurance-claims
• lab-results (variant) — GET/POST /api/lab-orders, GET /api/results/{id}, GET/POST /api/results/{id}/notes
• provider / admin — GET /api/providers/{id}/patients, /api/admin/...

Where vulnerabilities fit naturally

• idor → GET /api/patients/{id}/records, /api/records/{id}, /api/messages/{id} — read another patient's PHI.
• privilege_escalation → patient acquiring provider/admin role to see all charts.
• path_traversal → record/document download via a file= parameter (?file=../../etc/passwd).
• business_logic → request refills beyond refills_left, book/cancel another patient's appointment.
• auth_bypass → reach a record viewer without an active session (where the spec gates it).
• xss → free-text message body or visit notes rendered to a provider.

Diversity guidance

Pick ONE variant and a coherent subset — a pharmacy and a telehealth app diverge sharply. Size to endpoint_count; let theme_free_text / custom_prompt bias the variant and naming. Vary specialties, record types, and provider counts so two healthcare labs feel like different organizations.