Auth and access
Role-aware authorisation spans doctor, reception, testlab, patient, and admin paths.
- Scope-specific portal access
- Invalid token cleanup
- Cross-surface role boundaries
- Home
- Platform Engine
Shared rules and infrastructure
The logic every surface agrees to obey
Access control, feature toggles, slot generation, payment validation, and the notification loop live in one place — which is why the apps and the portals behave the same way.
- Auth and role access
- Scheduling and slot rules
- Payments, alerts, rollout controls
Core system layers
Six layers behind the visible product
Feature toggles
Toggle-based rollout and packaging for web capabilities.
- Prescription print
- Lab request creation
- Reception next-patient alerts
Scheduling rules
Slot generation and validation are treated as critical platform behaviour.
- UTC-safe slot resolution
- Fallback availability windows
- Future booking window limits
Payments and charges
Booking and change flows respect pricing policy before mutating anything.
- Payment-before-booking guard
- Quote-based cancel and reschedule
- Verification-first paid actions
Notifications and results
Status changes, lab progress, and results all feed the messaging layer.
- Appointment change notifications
- Doctor-ready alerts
- Unread result signals
Media and lookup
Imagery and lookup efficiency are part of the platform quality story.
- Hospital image galleries
- Provider summary embedding
- Remote media caching
Guarantees
Three things the engine will not let slip
These are the failure modes that make multi-surface healthcare products drift, so they are enforced centrally rather than per client.
Nobody books unpaid
The payment guard runs before appointment creation, on every surface.
Slots mean one thing
UTC-safe resolution and shared duration across web and mobile.
Roles stay in their lane
Scope-checked access on every portal and API path.
Review the engine with your technical team
Bring your integration questions — auth, payments, notifications, or rollout toggles.