CareBridge
Connected care, one record.
CareBridge is a clinic portal that links patients, doctors, front desk and administrators around appointments, medical records and prescriptions. Every screen, field and API route is governed by a role and permission model, and every access to a record leaves an audit trail.
- React.js
- Laravel
- PHP
- MySQL
- REST API
- Sanctum
- RBAC
Overview
- Business problem
- Small and mid-sized clinics usually juggle a booking spreadsheet, paper files and a messaging app. Front desk staff see more patient data than they need, doctors cannot see a patient's history in one place, and nobody can say who opened which record.
- Product objective
- Give each person in a clinic one portal that shows exactly what their role needs: booking for patients, a clear day for doctors, a fast desk for reception and oversight for administrators, with every sensitive action recorded.
- Target users
- Patients booking and following their care, doctors running consultations, receptionists managing the front desk, clinic admins running operations, and a super admin managing several clinics.
- Solution
- A React single-page app on a Laravel API. Permissions are enforced on the server with policies and gates, record sections are masked per role, slots are generated from doctor schedules, and reminders and audit entries run through queues and an append-only log.
Project classification
- Project type
- Web application · RBAC portal
- Industry
- Healthcare
- Frontend
- React SPA
- Backend
- Laravel modular monolith with policies and gates
- Database
- MySQL
- Architecture
- REST API behind auth and RBAC middleware, domain services, notification queue
User roles
- Patient
- Doctor
- Receptionist
- Clinic Admin
- Super Admin
My role
- Designed the role and permission model and implemented it with Laravel policies, gates and route middleware.
- Designed the MySQL schema for appointments, consultations, prescriptions, reports and the audit log, including migrations.
- Built the REST API and the service layer for appointments, records and prescriptions.
- Built the slot generation logic from doctor schedules, time off and existing bookings.
- Built the React interface: dashboards, calendar, record views and the prescription editor.
- Wired queued reminder jobs and the report storage flow.
Key features
Doctor day view. Interface designed and built by Vikrant A doctor's day at a glance
The doctor dashboard lists today's appointments with live status (scheduled, checked-in, in consultation, completed, no-show), the patient currently in the room with vitals, and the alerts that matter now: allergies and abnormal results. It reads only the doctor's own schedule, enforced by a policy on the appointments query rather than a filter in the UI.
Appointment calendar. Interface designed and built by Vikrant Scheduling across doctors
The front desk sees all doctors in one resource calendar. Slots come from each doctor's weekly schedule minus lunch blocks, time off and existing bookings, so the desk can only book what is actually free. Receptionists can book, move and cancel, but the calendar shows no clinical detail beyond the visit type.
Patient profile. Interface designed and built by Vikrant Patient profile with field-level privacy
One profile brings demographics, allergies, vitals, active problems and current medicines together. A panel shows which role may read each section, and the API strips restricted fields before the response is built, so a receptionist never receives diagnoses or counselling notes at all.
Medical history timeline. Interface designed and built by Vikrant Medical history as a timeline
Consultations, lab results, prescriptions and reports are merged into one chronological timeline with filters by type. Attached PDF reports are stored privately and served through short-lived signed URLs. A side panel shows who viewed the record, drawn from the audit log.
Prescription editor. Interface designed and built by Vikrant Prescription editor with safety checks
Doctors build a prescription item by item with strength, dose pattern, duration and instructions. The editor checks each item against the patient's recorded allergies and active medicines, shows a live preview of the printable slip, and locks the prescription on signing so later changes become a new version.
Clinic analytics. Interface designed and built by Vikrant Clinic analytics for administrators
Admins see appointment volume, new patients, no-show rate, waiting time, speciality mix and busiest hours, plus doctor utilisation and a live slice of the audit log. Aggregates are computed in SQL from de-identified counts, so analytics do not require opening individual records.
Also in the product
- Doctor and speciality search with slot booking
- Role-based access across five user types
- Field-level privacy for sensitive record sections
- Doctor day view with check-in and consultation states
- Medical history timeline with attached reports
- Prescription editor with allergy and interaction checks
- Queued SMS and email appointment reminders
- Append-only audit log of record access
- Clinic analytics: volume, no-shows, speciality mix
User flow
- Patient searches by speciality or doctor and picks a free slot
- Booking is confirmed; reminders are queued for 24 h and 2 h before
- Receptionist checks the patient in on arrival
- Doctor opens the profile and history; the access is logged
- Doctor records the consultation and issues a signed prescription
- Patient receives the prescription and any follow-up in the portal
- Admin reviews utilisation, no-shows and audit events
Technical architecture
- React SPA (patient, doctor, reception, admin views)
- REST API (Laravel routes, Sanctum token auth)
- Auth and RBAC middleware (policies, gates, field masks)
- Domain services (Appointments, Records, Prescriptions)
- MySQL (appointments, records, prescriptions, audit log)
- Notification queue (email, SMS reminders) and private report storage
Database and backend
Core tables
- users, roles, permissions, role_user, permission_role
- patients, doctors, specialities, clinics, doctor_schedules, time_off
- appointments (doctor, patient, slot, status) with a unique index on doctor and start time
- consultations, notes, prescriptions, prescription_items, reports, messages
- audit_logs: append-only, written by an observer and never updated or deleted by the app
RBAC permission matrix
- Patient: read own appointments, records and prescriptions; book and cancel own visits; message own doctors.
- Doctor: read own schedule; read and write records of patients with an appointment or consultation; write notes and prescriptions.
- Receptionist: book, move and cancel for all doctors; read demographics and insurance; no diagnoses, notes or prescriptions.
- Clinic Admin: manage staff, schedules and settings for one clinic; read aggregated analytics and the audit log; no clinical notes.
- Super Admin: manage clinics and admin accounts across the platform; no routine access to clinical records.
Authentication and access control
- Sanctum tokens with abilities per role, short expiry and revocation on logout.
- Laravel policies per model, gates for cross-cutting actions such as exporting records.
- Route middleware rejects missing roles before a controller runs; policies decide on the specific record.
- API resources whitelist fields per role so restricted data is never serialised.
Audit log
- Every read of a clinical record, prescription issue, role change and denied export writes an audit row.
- Row holds actor, role, action, subject type and id, request id and timestamp, with no clinical content copied in.
- Admins can filter by actor, patient or action; rows cannot be edited from the application.
Queues and storage
- Reminder jobs scheduled per appointment, cancelled or rescheduled with the booking.
- Reports stored on private disk, served by signed URL with a short expiry.
- Failed notifications retried with backoff and surfaced to admins.
Challenges and solutions
A permission matrix across five roles that does not drift
Permissions are data, seeded from one matrix and checked through policies, so controllers carry no role names. A test per role and endpoint asserts the allowed and denied outcomes, which makes accidental widening of access visible in review.
Field-level privacy of records
Record API resources take the viewer's role and omit restricted sections before serialisation. The UI hides the same sections, but the guarantee comes from the response itself, not the front end.
Overlapping slot generation from doctor schedules
Slots are computed from weekly schedule, minus lunch blocks, time off and existing appointments, in the clinic time zone. Booking re-checks inside a transaction and a unique index on doctor and start time rejects a race, returning a conflict the UI handles by offering the next slot.
A trustworthy audit trail
An observer writes audit rows in the same request as the action, storing identifiers rather than clinical text. The table is append-only at the application level and read through a restricted admin view.
Reliable reminders when bookings change
Each appointment owns its reminder jobs. Reschedule and cancel remove and recreate them, and jobs re-read the appointment status when they run so a stale reminder never goes out.
Keeping prescriptions safe and immutable
Items are checked against recorded allergies and active medicines at edit time, and signing locks the prescription. Corrections create a new version linked to the old one, so history is preserved.
Results
- One portal replaces separate booking, records and messaging tools for the five user types in the scenario.
- Role enforcement lives on the server, with matrix tests that make permission changes explicit.
- Every clinical record access is attributable to a person, role and time.
- The slot engine and unique index remove double-booking as a class of error.
- The architecture separates domain services from transport, so a mobile client could reuse the same API.
Qualitative outcomes only; no usage or revenue figures.
Visual identity
- Primary #0B6E6E
- Secondary #12263F
- Accent #E8685A
- Background #F4F8F8
IBM Plex Sans for UI, IBM Plex Mono for IDs, doses and times. Bridge-arch mark with a coral dot, paired with a clean sans wordmark. Clinical and dense: narrow icon rail, compact header with a role badge, tables first, clear alert colours.
Related projects
- Portfolio ProjectProfessional services (multi-vertical)
Slotwise
Scheduling SaaS for any business that sells time: calendars, availability rules and automated reminders.
- React.js
- Laravel
- PHP
- MySQL
- REST API
- Portfolio ProjectRestaurant operations
Seatly
Real-time floor management: live table status, reservation timeline and waitlist for restaurant teams.
- React.js
- TypeScript
- Laravel
- PHP
- MySQL
- WebSockets
- REST API