Hospital EMR System — Multi-Module Electronic Medical Records Platform

The problem

Hospitals run on paper. Even in 2024, most mid-size hospitals manage patient records, appointments, billing, and lab reports across disconnected systems — a Word document here, an Excel file there, a printed form filed in a cabinet.

The hospital chain I built for had three branches and zero shared data. A patient seen at branch A had no records visible at branch B. Critical information lived in individual doctors' offline notes.

What I built

A complete EMR (Electronic Medical Records) system covering the full patient journey.

Modules:

1. Patient registration and history Single source of truth across all branches. Patient demographics, medical history, allergies, medications, and clinical notes — all centralized, searchable, and auditable.

2. Appointment scheduling with conflict detection Multi-doctor, multi-room scheduling that automatically prevents double-bookings. Real-time updates via WebSockets so reception staff see new appointments instantly.

3. Billing and insurance integration Automatic generation of invoices from clinical encounters. Insurance claims with retry logic for rejected submissions. Multi-currency support for international patients.

4. Lab reports and prescriptions Lab results tied to patient records, with abnormal values flagged automatically. E-prescriptions printable as PDFs with pharmacy QR codes.

5. Role-based access control Doctors see clinical data. Nurses see scheduling and basic records. Admin sees everything but clinical notes. Patients see their own records via a portal. Strict RBAC enforced at the API layer, not the UI.

The stack and why

Frontend: React + TypeScript — large team, complex UI, type safety prevents 80% of bugs in healthcare data.

Backend: NestJS + TypeScript — strict module boundaries, dependency injection makes testing easier, decorators handle authorization elegantly.

Database: PostgreSQL — JSONB for clinical notes (flexible schema), strong relational integrity for billing/scheduling.

Cache: Redis — patient list lookups, session storage, real-time event pub/sub.

The hardest part

Audit logging without killing performance.

Healthcare data needs full audit trails — who viewed what, when, from where. The naive implementation (insert a log row on every read) tanked the database under realistic load.

Solution: I built a write-ahead log to Redis, with a background worker batching inserts to PostgreSQL every 5 seconds. Audit completeness preserved, read latency under 100ms.

What I'd do differently

In retrospect, I'd start with a simpler scheduling module and ship it as v1 — instead of trying to build all 5 modules in parallel. The "ship the smallest valuable thing first" rule applies even when the client wants everything.