Hospital Management System

A hospital management application built as coursework for IIT Madras’ Modern Application Development II. It provides role-based workflows for administrators, doctors and patients: appointment scheduling, consultation records, availability management, search, and automated background tasks.

Context and problem#

Hospital administration ties together several workflows: managing doctors and patients, tracking availability, scheduling appointments, keeping consultation records and sending timely notifications. Each involves users with different permissions. I built the project to bring these into one system with a Flask backend and a Vue frontend, and to practise relational modeling, authentication, caching, asynchronous tasks and scheduled reporting.

What it does#

REST-style Flask APIs behind a Vue 3 single-page interface with separate administrator, doctor and patient workflows.
Session-based authentication with role-specific authorization, and patient registration.
Administrator management of doctors, patients, appointments and account access, including disabling and restoring accounts.
Department browsing and doctor discovery, with search and availability filtering.
Appointment booking, cancellation and rescheduling.
Doctor availability by date, in morning, afternoon and evening slots.
Consultation records (diagnosis, prescriptions, treatment notes, medicines) and a patient medical-history view.
Redis caching, Celery background jobs, Celery Beat schedules and SMTP email.
First-run database initialization and demo data: 1 administrator, 10 departments, 30 doctors and 100 patients, with generated availability, appointments and treatments.

Administrator dashboard showing doctor, patient and appointment counts, batch job tools, search and a list of doctors — The administrator dashboard: totals, batch-job tools, search and doctor management.

The patient dashboard: appointments, treatment export and departments.

The doctor dashboard: upcoming appointments and assigned patients.

Architecture overview#

flowchart LR Vue["Vue 3 SPA"] -->|Fetch / REST| Flask["Flask API<br/>sessions, role checks"] Flask --> ORM["SQLAlchemy"] --> DB[("SQLite")] Flask <-.-> Cache[("Redis cache<br/>TTL + invalidation")] Flask -.->|enqueue| Broker[("Redis broker")] Broker -.-> Worker["Celery workers"] Beat["Celery Beat"] -.-> Broker Worker --> DB Worker -.-> Mail["SMTP email"] Worker -.-> CSV["CSV exports"]

Conceptual overview of the main components. Redis and Celery are optional services.

Engineering challenge: role-based architecture#

Three roles needed different functionality and permissions. Rather than three applications, the frontend and backend share one architecture and distinguish the operations each role can perform. That uses separate SQLAlchemy models for administrator, doctor and patient accounts, Flask sessions, Werkzeug password hashing, reusable route decorators for authentication and role checks, ownership checks on selected appointment and patient-record endpoints, and role-specific dashboards.

Engineering challenge: relational design#

The data model covers department-to-doctor, doctor and patient to appointment, appointment-to-treatment and treatment-to-medicine relationships, plus per-date availability and persistent export-job records. It uses foreign keys with cascading deletes, a database-level uniqueness constraint on doctor availability slots, enum-based appointment status, and SQLite foreign-key enforcement turned on for each connection.

Engineering challenge: scheduling and availability#

Availability is stored per date and time-slot category, and doctors get a seven-day view. Patients search by doctor, department, date and availability, then book, reschedule or cancel through backend APIs. Appointments move through Booked, Completed and Cancelled, rescheduling keeps the original date and time, and treatment records attach to completed consultations.

Doctor's weekly availability table with morning, afternoon and evening slots for seven days — A doctor's seven-day availability by morning, afternoon and evening slot.

Update Patient History form with visit type, diagnosis, prescription, doctor notes and a medicine entry — Recording a consultation: diagnosis, notes and medicines.

Engineering challenge: caching and data freshness#

Redis stores JSON-serialized cached values with a configurable time-to-live. Selected reads check the cache first, and updates invalidate the application context, dashboard and search entries. If Redis is unavailable the application falls back to normal database reads. I have no verified hit-rate, latency or throughput figures, so I make no performance-improvement claim.

Engineering challenge: background tasks and scheduled reports#

Celery with Redis as broker and result backend runs work inside Flask’s application context, outside normal request handling:

Treatment-history CSV exports, with persisted job states (Queued, Processing, Completed, Failed), unique filenames, and endpoints to start a job, check its status and download the result.
A daily hospital summary and daily appointment reminders.
Monthly doctor activity reports summarizing completed consultations.
Celery Beat schedules with times set through environment variables, HTML and plain-text emails, and manually triggered batch-report endpoints.

Redis and Celery workers must be running for these features, and email is only sent when SMTP is configured. I have not verified delivery in production.

MailHog inbox showing an appointment reminder email to a patient — A daily appointment reminder, captured in MailHog during local development.

Engineering challenge: single-page frontend#

Flask serves one entry page and Vue 3 handles the interface: Vue loaded from a CDN, Jinja2 templates providing the shell and component markup, reusable components for dashboards, forms and navigation, client-side route matching, Fetch for API calls, role-dependent rendering, and feedback for API and background-task status. Gulp and BrowserSync give live reload in development, and a Linux script starts Flask, Redis, Celery workers, Celery Beat and MailHog together.

Limitations#

I have no measurements for production deployment, real users, API latency, query performance, cache hit rate or automated test coverage. The 1 / 10 / 30 / 100 figures above describe generated demonstration data only.