CASE STUDY · HEALTHCARE PLATFORM · 2024
PatientBook
A connected healthcare system that gives each role the tools it needs while keeping the patient history at the centre.
XAPPRIKA SCOPE
- Product design
- Web application
- Mobile application
- Backend architecture
INTERFACE RECONSTRUCTION BASED ON THE DELIVERED PRODUCT.
THE CONTEXT
Patient information is often split across clinic software, paper records, prescriptions, reports, and conversations. PatientBook brings those moments into one role-aware system centred on a continuing patient record.
THE SYSTEM MODEL
One record. Different workspaces.
PatientBook does not make every role use the same screen. It keeps the continuing record at the centre, then shapes each workspace around the decisions that role needs to make.
THE CARE JOURNEY
The same history, in the right shape for each moment.
A consultation begins in the doctor workspace, is prepared through the front desk, stays visible to the patient, and continues into diagnostic and prescription workflows.
01 / POINT OF CARE
02 / PREPARATION + CONTINUITY
03 / CLINICAL HANDOFF
SYNTHETIC DISPLAY DATA · INTERFACE RECONSTRUCTIONS
THE PRODUCT RESPONSE
Built around the work people actually do.
- 01
One continuing record
Visits, consultations, prescriptions, reports, and clinical context remain associated with the patient instead of being rebuilt at every encounter.
- 02
Role-specific workspaces
Doctors, assistants, patients, laboratories, pharmacies, and polyclinic teams see workflows shaped around their responsibilities rather than one shared interface.
- 03
A path from paper to digital
Archive and document workflows acknowledge the records clinics already have, making digitisation part of day-to-day operations.
- 04
Care beyond one clinic
Booking, queues, laboratory results, prescriptions, and controlled record access connect the moments around a consultation.
IMPORTANT JOURNEYS
From appointment to clinical history
NEED — A doctor needs the relevant patient context before starting a new consultation.
The doctor workspace connects the patient profile, timeline, prior visits, reports, diagnoses, and prescriptions to the active visit.
WHY IT MATTERS — The consultation begins with continuity instead of another disconnected record.
Bringing older records forward
NEED — A clinic needs useful digital history without pretending its existing paper archive does not exist.
Assistant and archive-import workflows bring historical files and report documents into the patient record with operational status and traceability.
WHY IT MATTERS — Migration becomes a practical clinic workflow rather than an all-or-nothing prerequisite.
Coordinating a polyclinic visit
NEED — Reception and clinical teams need to manage bookings, queues, doctors, and patient access in one location context.
Dedicated polyclinic administration and reception views organise schedules, services, queue states, memberships, and patient files.
WHY IT MATTERS — Different teams can coordinate the same visit without receiving identical permissions.
DESIGN / ENGINEERING
The patient record is the shared object
The product is organised around the patient history and the controlled actions different roles can perform around it.
Explicit roles and access boundaries
Doctor, assistant, laboratory, pharmacy, administrator, and polyclinic access is represented in routes, profiles, memberships, and database policies.
Migration without abandoning the product
The repository preserves the Firebase product history while the active V2 architecture moves authentication, data, and server workflows to Supabase.
THE RESULT
A role-aware product foundation now connects patient history, consultations, records, and supporting clinic workflows in one system designed to keep evolving.
VIEW THE PRODUCT
CONTINUE EXPLORING