Messaging System
CareTeam-based real-time messaging between patients and practitioners
Architecture
The system uses CareTeam-based messaging rather than 1:1 practitioner-patient messaging:
Why CareTeam-Based?
- A patient may have multiple providers (GP, specialist, nurse)
- All team members should see the same conversation
- Ensures continuity of care even when providers change
- Supports role-based participation (primary physician, nurse, etc.)
Room Identification
Each room is identified by:
Example: careteam:team-001:patient:ZCT_patient_001
Flow: Staff Sending a Message
- Staff opens patient's profile
- System finds CareTeams where staff is a participant AND patient is the subject
- Staff selects room (or default team is used)
- Message is sent with
sender_resource_id - All team members + patient see the message in real-time
Flow: Patient Sending a Message
- Patient opens conversations list
- System shows all rooms from patient's CareTeams
- Patient sends message
- All CareTeam practitioners receive it in real-time
Unread Tracking
- Each message read status is tracked per-user in
communication.message_read_status - Unread counts are returned with conversation listings
- Mark-read updates the status for the specific user
Real-Time Delivery
Uses Supabase Realtime subscriptions:
Message Types
| Type | Use Case |
|---|---|
text | Regular conversation |
medication_request | Patient requests medication |
medication_response | Provider responds to med request |
system_notification | Auto-generated alerts |
template | Pre-built message from template |
Sender Identity
The sender_resource_id field accepts both:
- FHIR resource_id (e.g.,
ZCT_doctor_001) - Internal UUID (e.g.,
7a2898cd-d088-...)
This dual-format support is needed because the staff GUI sends UUIDs while the token contains FHIR resource_ids.
API Reference
See Communication API for full endpoint documentation.