HospitalManagement
Scheduling, records and billing as one consistent model
- Role
- Developer: domain model, persistence, application logic
- Year
- 2023
- Discipline
- Object-Oriented Design · Databases · Systems
- Context
- An operations system for clinical workflows, built around an object-oriented domain model with relational persistence.
Hospital software fails in a specific way: each department gets its own tool, the same patient exists three times with three different identifiers, and reconciling them becomes somebody's full-time job.
This system models the domain once (patients, practitioners, appointments, admissions, billing) and treats the relationships between them as invariants the code is not permitted to violate, rather than conventions it is expected to respect.
What madethis hard.
- 01
Double-booking is a data integrity problem
A practitioner cannot be in two consultations at once, and a room cannot hold two procedures. Enforcing that in the UI alone guarantees it will eventually be violated by any other code path that writes an appointment.
- 02
Medical records are append-only in spirit
Clinical history must remain auditable. Destructive updates erase the reasoning behind past decisions, which is precisely the information that matters later.
- 03
Billing derives from clinical events, not from typing
If charges are entered by hand they will drift from what actually happened. The billing model has to be a projection of recorded consultations, procedures and admissions.
- 04
Role boundaries are strict in a clinical setting
Reception, clinical staff and administrators see genuinely different slices of the same record. Access control here is a domain rule, not a UI preference.
How Isolved it.
- 01
Model the domain, then the screens
Patient, Practitioner, Appointment, Admission and Invoice as first-class entities with encapsulated invariants, so an object cannot be constructed or mutated into an invalid state.
- 02
Scheduling conflicts caught at the source
Overlap detection sits in the scheduling service with a matching uniqueness constraint in the database, so the application rejects conflicts early and the schema refuses them absolutely.
- 03
Immutable clinical history
Record entries are appended and superseded rather than overwritten, so the current state and how it was reached are both recoverable.
- 04
Derive billing from events
Invoices are generated from recorded clinical activity, keeping the financial record structurally consistent with the medical one.
- 05
Layered separation
Presentation, service and persistence layers kept distinct, with data access behind an interface so storage concerns never leak into domain logic.
What itdoes now.
One authoritative patient identity shared across scheduling, clinical records and billing.
Scheduling conflicts prevented at both the service layer and the schema.
An append-only clinical history that preserves the audit trail.
Billing derived from recorded events, keeping financial and clinical records aligned.
Language
- Java
- OOP
- Collections
Persistence
- MySQL
- JDBC
- Transactions
Design
- Layered Architecture
- Domain Modelling
Practice
- Data Structures
- Algorithms
SmartParking
An embedded system that tracks bay occupancy in real time and automates barrier access, running a deterministic state machine on constrained hardware where the sensors are unreliable by nature.
Read case study