# 12. Messaging & On-Site Emergencies

← Business Requirements

## (a) Business requirements #

- There is no live chat and no direct nurse↔customer messaging. All post-booking communication runs through a structured ticket system that admin can read in full. This is a deliberate anti-disintermediation and patient-safety design: it protects vulnerable patients, creates a dispute paper trail, and prevents families and nurses pairing off-platform.
- A booking-scoped coordination ticket is auto-created so the nurse and customer can coordinate logistics (arrival time, room location) under admin visibility. Internal admin-only notes are supported and never shown to users.
- Tickets also carry refund conversations and any support request, and are the mandatory anchor for admin refunds (Section 7).
- On-site emergency playbook. The ticket system is async and has no real-time channel, so the operational playbook is explicit: in an emergency (no answer at the door, a medical emergency), the nurse calls the emergency-contact number surfaced in the app, then opens a ticket. The emergency contact number is surfaced prominently in the booking UI (drawn from encrypted care instructions), so a nurse never needs to find the family's number by other means (which would break the platform's communication control).

## (b) Iran-specific considerations #

- Disintermediation is the predictable failure mode of recurring, relationship-based care; the ticket-only model retains value (escrow, dispute protection, backup coverage, insurance that only applies on-platform) instead of relying on punitive lock-in.
- For unobserved in-home care of patients who cannot self-report, the controlled-but-auditable communication channel plus a clear emergency escalation path is a safety requirement.

## (c) MVP vs DEFERRED #

- MVP: ticket-only messaging (admin-readable); auto-created booking-coordination ticket; internal notes; prominent in-app emergency contact + documented playbook.
- DEFERRED: real-time chat; a first-class `incidents`/emergency-event entity with SLA; push/real-time alerting.

## (d) Supporting database entities #

`tickets`, `ticket_participants`, `ticket_messages`, `booking_care_instructions` (encrypted emergency contact), `support_alerts`.

> Related: Data model — Messaging.

↑ Back to top