Product architecture
How MediSlate works under the hood
A calm, deterministic system that turns front-desk actions into scheduled care — with rules for reminders, no-shows, and staff workload built in.
System layers
UI Layer
React 19, TanStack Router, design tokens, WCAG-AA.
Domain
Patients, Appointments, Practitioners, Rules.
Data
Encrypted store with append-only audit log.
Integrations
SMS, Email, Calendar, EHR (planned).
Appointment booking flow
STEP 1
Patient identified
Search or register.
STEP 2
Slot selected
Practitioner + time.
STEP 3
Rules engine
Conflict + eligibility checks.
STEP 4
Reminders queued
SMS/Email at T-24h.
STEP 5
Outcome logged
Completed / no-show.
Rules engine
IF appointment is within 24h AND status = booked
THEN send email + SMS reminder
IF practitioner has 6+ appointments in a day
THEN block additional bookings
IF patient has 2 consecutive no-shows
THEN require confirmation call before next booking
IF appointment reason = 'follow-up'
THEN suggest same practitioner as previous visit
IF slot conflicts with staff leave
THEN reject and propose next 3 slots
Access control matrix
| Capability | Staff | Practitioner | Admin |
|---|---|---|---|
| View patients | ✓ | ✓ | ✓ |
| Create / edit patients | ✓ | — | ✓ |
| Book appointments | ✓ | — | ✓ |
| Update appointment status | ✓ | ✓ | ✓ |
| Manage staff & roles | — | — | ✓ |
| Run backups | — | — | ✓ |
Core entities
Patient
- — id
- — name
- — phone
- — dob
- — gender
- — address
- — notes
- — allergies
- — bloodGroup
- — createdAt
Appointment
- — id
- — patientId →
- — practitionerId →
- — dateTime
- — duration
- — reason
- — status
- — notes
User (Staff)
- — id
- — name
- — role
- — specialty
- — phone
- — bio
- — avatar
Relationships: Appointment.patientId → Patient.id · Appointment.practitionerId → User.id
Non-functional guarantees
Encryption
AES-256 at rest, TLS 1.3 in transit.
Availability
99.95% uptime SLA target.
Latency
P95 page load under 800ms.
Backups
Hourly incremental, nightly full.