A multi-module EMR for a healthcare client

The problem

Clinics often run on a patchwork: a spreadsheet for appointments, a paper file for history, another tool for billing. Records exist, but nobody has the whole picture, and the person at the front desk can't see what the doctor wrote.

A multi-module electronic medical records (EMR) system replaces the patchwork with one system that each role uses differently.

What I built

I built a multi-module EMR as a web application. The idea behind the modules was that each part of a clinic's day gets its own screen, but all of them read from the same patient record.

Patient records and history. One record per patient, searchable, with an audit trail.
Scheduling. Appointments that account for who is free, so two people don't get the same slot.
Billing. Invoices tied to what actually happened during a visit.
Clinical workflows. The notes, results and prescriptions a doctor works with.
Role-based access. Doctors, nurses, reception and administrators see different things.

I'm describing the shape here, not the client or the data. Healthcare systems hold sensitive information, and a case study shouldn't leak it.

Decisions that mattered

Permissions at the API, as well as the screen. Hiding a button in the interface is not access control. Every request is checked on the server against the user's role.

Audit logging. In healthcare, "who looked at this record" is a normal question. Logging every read can slow a database down if you do it naively, so it deserves design time, not an afterthought.

A relational core. Billing and scheduling are about relationships and integrity, which is what a relational database is good at. Flexible clinical notes can sit beside that without bending the rest of the schema.

What I would simplify

I would ship fewer modules first. Clients ask for everything, and it's tempting to build it all in parallel. The better order is the smallest useful slice, usually scheduling and records, used by real staff for a few weeks, before billing and everything else. What staff actually do differs from what the requirements document says.

The problem

A multi-module electronic medical records (EMR) system replaces the patchwork with one system that each role uses differently.

What I built

I built a multi-module EMR as a web application. The idea behind the modules was that each part of a clinic's day gets its own screen, but all of them read from the same patient record.

Patient records and history. One record per patient, searchable, with an audit trail.

Scheduling. Appointments that account for who is free, so two people don't get the same slot.

Billing. Invoices tied to what actually happened during a visit.

Clinical workflows. The notes, results and prescriptions a doctor works with.

Role-based access. Doctors, nurses, reception and administrators see different things.

I'm describing the shape here, not the client or the data. Healthcare systems hold sensitive information, and a case study shouldn't leak it.

Decisions that mattered

Permissions at the API, as well as the screen. Hiding a button in the interface is not access control. Every request is checked on the server against the user's role.

Audit logging. In healthcare, "who looked at this record" is a normal question. Logging every read can slow a database down if you do it naively, so it deserves design time, not an afterthought.

What I would simplify