Hospital CRM & Management System

Most hospital systems model an episode of care — admission, treatment, discharge, done. An aesthetic practice works differently. Someone arrives as an enquiry, becomes a patient, attends outpatient consultations, may be admitted for surgery, is discharged, then returns for follow-up over six months, and ideally stays a patient for years.

The system is built around that whole arc — lead, patient, OPD and IPD, surgery, discharge, follow-up, retention — as one continuous record rather than a series of disconnected visits.

The frontend and backend are fully decoupled. They share no runtime and no secrets, and communicate only over a REST API and a WebSocket connection.

The practical consequence is that the browser bundle carries nothing sensitive. Every credential — database, tokens, provider keys — lives server-side; the frontend gets only explicitly public configuration. For a system holding clinical records and patient photography, the boundary being architectural rather than a matter of discipline is the point.

The platform runs on infrastructure the hospital controls rather than in a vendor's multi-tenant cloud. Patient records and clinical photographs are about as sensitive as data gets, and aesthetic surgery photography especially so.

Rate limiting is backed by the primary database rather than a separate cache service — one less moving part to run, secure and keep patched on hospital infrastructure.

Alongside the REST API, a WebSocket channel pushes updates as they happen. Front-desk staff see a consultation finish without refreshing; the record a clinician is looking at reflects what another has just entered.