HOSPITAL MANAGEMENT SYSTEM - PROJECT REPORT

Name: Arush Dixit

Roll Number: 23f3002638
Email: 23f3002638@[Link]
Level: Diploma
Institution: Indian Institute of Technology, Madras
NOTE

To run the application:

1. Install dependencies: pip install flask flask_sqlalchemy flask_login werkzeug pytz

2. Run the application: flask --app app --debug run
3. Open Browser at: [Link]
4. Default admin credentials: username= admin, password=admin123
The SQLite database ([Link]) is created automatically on first run in the instance folder.
DESCRIPTION
The objective was to build a Hospital Management System (HMS) web application using
Flask as the backend framework. The system provides role-based access for three user types:
Admin, Doctor, and Patient, each with dedicated dashboards and functionalities to manage
hospital operations including appointments, patient records, and treatment history. The system
solves scheduling conflicts and maintains organized medical records through centralized
database management.
TECHNOLOGIES USED

1. Flask: Request handling, routing, and application views.

2. Flask-SQLAlchemy: Database ORM for model definitions and query operations.
3. Flask-Login: User authentication, session management, and role-based access control.
4. Werkzeug: Secure password hashing (PBKDF2-SHA256)
5. Jinja2: Template engine for dynamic HTML rendering.
6. SQLite: Relational database for data persistence.
7. Bootstrap 5: Frontend styling and responsive design.
8. pytz: Timezone handling for accurate timestamps.
DATABASE SCHEMA DESIGN

All tables have an id field as primary key.

1. User Table
• id: Integer, Primary Key
 • username: String, Unique, Not Null
• password_hash: String, Not Null (hashed using Werkzeug)
• role: String, Not Null (values: 'admin', 'doctor', 'patient')
2. Doctor Table
• id: Integer, Primary Key
• name: String, Not Null
• specialization: String, Not Null
• user_id: Integer, Foreign Key → [Link] (CASCADE DELETE)
Relationship: One-to-One with User. When doctor is deleted, associated user account is also
removed.

3. Patient Table
• id: Integer, Primary Key
• name: String, Not Null
• contact: String, Not Null (10- digit validation)
• user_id: Integer, Foreign Key → [Link] (CASCADE DELETE)
Relationship: One-to-One with User. Patient deletion cascades to user account.

4. Appointment Table
• id: Integer, Primary Key
• date: Date, Not Null
• time: Time, Not Null
• status: String, Default='Booked' (values: 'Booked', 'Completed', 'Cancelled')
• doctor_id; Integer, Foreign Key → [Link] (CASCADE DELETE)
• patient_id: Integer, Foreign Key → [Link] (CASCADE DELETE)
Relationships: Many-to-One with Doctor and Patient. Appointment deletion occurs when either
doctor or patient is removed.

5. Treatment Table
• id: Integer, Primary Key
• diagnosis: Text, Not Null
• prescription: Text
• notes: Text
• created_at: DateTime, Default=UTC timestamp
• appointment_id: Integer, Foreign Key → [Link], Unique
Relationship: One-to-One with Appointment. Each completed appointment can have exactly one
treatment record.
 6. DoctorAvailability Table
• id: Integer, Primary Key
• date: Date, Not Null
• start_time: Time, Not Null
• end_time: Time, Not Null
• doctor_id: Integer, Foreign Key → [Link]
Relationship: Many-to-One with Doctor. Stores working schedules for appointment validation.
This schedule is displayed to patients on the booking screen, allowing only appointment requests
within available time slots.

ER Diagram

ARCHITECTURE & CORE FEATURES

The application follows MVC principles with [Link] defining ORM classes,
[Link] containing routes and logic, templates/ for views, and static/ for assets.
Admin: Upon login, the admin dashboard displays totals for doctors, patients, and appointments.
Admins perform full CRUD on doctors and patients; deleting profiles cascades to remove related
records. A global appointment view supports status filtering (Booked, Completed, Cancelled)
and modal pop-ups for treatment details.
Doctor: Doctors see only their appointments on a personalized dashboard and update statuses to
Completed or Cancelled. Completing an appointment prompts a treatment form for symptoms,
diagnosis, prescription, and notes; records are timestamped. Doctors view patient histories and
manage their availability schedules to validate bookings. Now, patients can view each doctor's
upcoming availability (date and time slots) while booking an appointment, ensuring bookings
strictly follow the doctor's defined working hours.
Patient: Patients register with validation (unique username, 10-digit contact). The patient
dashboard shows profile info, a searchable doctor list, and tables for upcoming and past
appointments. Booking validates the doctor’s availability and prevents double-booking or past-
date selection. Patients may cancel or safely reschedule appointments and view treatment
records via modal pop-ups.
SECURITY & VALIDATION
Authentication: Passwords hashed with PBKDF2-SHA256. Flask-Login secures sessions and
enforces role checks, returning 403 for unauthorized access.
Validation: Backend enforces unique usernames, contact format, date/time checks, and conflict
prevention. Frontend HTML5 and JavaScript provide immediate feedback.
SQL Injection: Prevented by SQLAlchemy ORM.
Cascading Deletes: Maintain referential integrity.

UI/UX HIGHLIGHTS

The UI uses Bootstrap 5 with a “frosted glass” theme, a responsive navbar for role-specific
menus, and auto-dismissing flash messages. Modal dialogs improve workflows and cache
control headers prevent back-button re-access after logout.

AI/LLM USAGE DECLARATION

The development of this project was primarily guided by the official documentation for the
frameworks used, such as Flask, SQLAlchemy, and Flask-Login. For learning new concepts and
resolving common issues that weren't immediately clear from the documentation, educational
resources such as YouTube tutorials were a helpful reference.
During the project, errors encountered in the terminal were typically resolved by researching the
specific error messages and consulting community forums like Stack Overflow to understand
the solutions provided by other developers.
The use of AI tools was negligible and was limited to occasional syntax clarification and
suggesting alternative approaches for minor code refactoring. The core logic, application
structure, and final implementation of all features are my own work, based on the
knowledge acquired from the course materials and the resources mentioned above.

API RESOURCE ENDPOINTS

Not Applicable. This optional milestone was not implemented as the focus was on completing
the core requirements.

VIDEO DEMONSTRATION