Overview

The Hospital Management System is a completed desktop application created as the final project for a Diploma in IT at ESOFT Metro Campus. It models the day-to-day records of a fictional hospital through C#/.NET and Microsoft SQL Server.

The system covers patient information, appointments, staff records, billing, and inventory. Although it predates my newer web and cloud projects, it remains portfolio-worthy because it shows an earlier stage of my engineering progression: translating a broad institutional brief into a relational data model and a multi-screen operational application.

Product scope

The application brings several hospital responsibilities into one desktop interface:

patient registration and record management;
admission, discharge, and medical-history information;
doctor and appointment scheduling;
employee and staff records;
bill generation and payment-related records;
medicine and equipment inventory.

These areas are related rather than isolated. An appointment belongs to a patient and doctor, a bill reflects delivered services, and inventory records support hospital operations. Modeling those relationships was the central database challenge.

Architecture

The project uses a traditional desktop client connected to SQL Server.

C# desktop forms and custom UI controls
                  |
         application event handlers
                  |
       SQL queries and data mapping
                  |
        Microsoft SQL Server schema

The Visual Studio solution organizes forms and resources around hospital workflows. Custom interface components provide a consistent navigation and data-entry experience across modules.

This architecture differs from my current Next.js and API work, but it exposed the same underlying concerns: validation, record identity, relational integrity, permission-aware operations, and keeping multiple views synchronized with persisted state.

Relational thinking

A hospital system cannot treat every screen as a separate spreadsheet. Patient identity needs to remain consistent across appointments, admissions, billing, and history. Staff records need to connect with schedules. Inventory updates must refer to a stable item record rather than repeated free text.

The SQL Server database therefore acts as the shared source of truth behind the desktop interface. Designing primary keys and relationships made it possible to retrieve connected records and reduce inconsistent duplication.

The project was also an early lesson in separating display values from identifiers. A patient name may change or be duplicated; an internal patient ID should remain stable across every related table.

Interface design

The application uses a dashboard-style desktop interface with dedicated views for each operational area. Data-entry controls guide staff through record creation and updates, while tables present searchable operational information.

For an administrative system, predictability matters more than decoration. Common actions, field positions, navigation, and confirmation behavior need to stay consistent because users repeat the same workflows throughout the day.

The project included custom UI components to move beyond default desktop controls and create a clearer visual hierarchy.

Engineering challenges

Converting a broad brief into modules

“Manage a hospital” is too large to implement directly. The work had to be divided into bounded areas—patients, appointments, staff, billing, and inventory—then reconnected through shared identifiers.

Keeping interface state synchronized

After adding or editing a database record, lists and detail views must reflect the change. Desktop applications make stale in-memory state easy to introduce, so refresh and selection behavior need deliberate handling.

Designing for invalid data

Administrative users can submit incomplete forms, duplicate records, invalid dates, or inconsistent amounts. Input validation and database constraints are both necessary; neither layer is sufficient alone.

What I would improve today

With my current experience, I would evolve the project by:

separating data access and domain services from form event handlers;
using parameterized repository methods consistently;
adding migrations and repeatable seed data;
introducing role-based authentication and an audit log;
writing tests for billing, appointment conflicts, and inventory updates;
protecting sensitive patient data with stronger access and encryption controls;
exposing a documented API so desktop and web clients can share the same backend;
adding backup, restore, monitoring, and deployment documentation.

Healthcare data requires privacy and security controls beyond a classroom system. The project is an educational implementation, not production clinical software.

What I learned

This project was one of my first experiences building a system larger than a single page or script. It taught me to decompose a domain, design connected tables, build reusable interface patterns, and think about how one update affects several operational views.

It also provides a useful baseline for my later work. The same concerns—clear domain boundaries, trustworthy data, validation, authorization, and maintainable workflows—reappear in EITAMS and DayBoard at a more advanced architectural level.