One system, three kinds of users.
A hospital runs on three groups of people who need very different things from the same system: patients, doctors, and administrators. This platform brings all three into one place — and the central challenge was giving each the right view and the right permissions without the system becoming a mess.
01One platform, three very different users
A patient wants to register and book appointments. A doctor wants their schedule and their patients' records. An admin runs the whole operation. The same underlying data — records, schedules, billing, prescriptions — has to serve all three, but each role should only ever see and touch what's appropriate to them. Designing that role separation cleanly was the heart of the project.
02Role-based access as the backbone
I used Spring Security to enforce role-based access across the platform. Rather than building three separate apps, there's one system where every protected action checks the user's role on the server. A patient simply cannot reach a doctor's full record view, because the boundary is enforced in the backend — not hidden in the interface and hoped for.
In a system holding medical records, access control isn't a feature — it's the foundation. Health data is sensitive and often regulated, so who can see what has to be decided server-side and enforced on every request, never left to the frontend.
03The modules, and how they fit
- Patient registration & scheduling — the front door: patients enrol and book appointments against real doctor availability.
- Electronic Health Records (EHR) — the clinical core, where patient history lives and doctors work.
- Billing & prescriptions — the operational layer tying care to records.
All of it sits on MySQL, which is the right call for hospital data: patients, doctors, appointments, and billing are deeply relational, and consistency across them is non-negotiable. An appointment that references a doctor who doesn't exist, or a prescription with no patient, should be impossible by design.
04Why Angular on the front
The frontend is built in Angular. For an application this structured — multiple roles, many forms, distinct dashboards — Angular's opinionated, component-driven structure helps keep a large UI organised rather than letting it sprawl. Each role's dashboard is its own coherent surface over the shared backend.
05What I took away
This project was a lesson in managing complexity through structure. The difficulty wasn't any single feature — it was keeping patients, doctors, and admins cleanly separated while they all draw on the same data. Role-based access, a relational core, and a component-structured frontend were the three pillars that kept it coherent. Designing the boundaries first, then the features, is what made it manageable.