The Hospital Management System in PHP and MySQL is a web application that helps a small hospital or clinic manage patients, doctors, appointments and prescriptions in one place, instead of paper files and registers. It is made for BCA, MCA, B.Tech and M.Tech final-year students who want a serious, real-world project with three user roles. On this page you get the complete project synopsis, the full module list for admin, doctors and patients, the database tables with SQL, and the exact steps to run the project on XAMPP.
Project Synopsis
Visit any small clinic or nursing home and watch the front desk for ten minutes. A receptionist is writing patient names in a thick register, OPD slips are getting printed and then lost, and someone is shouting, "Who has the Sharma file?" Patient history lives in paper folders stacked in a store room, so when a patient returns after six months, the doctor starts from zero. Appointment queues are managed by memory and goodwill, which works fine until fifteen patients arrive for the same doctor at the same time.
The Hospital Management System moves this daily chaos into a browser. The receptionist registers a patient once, books an appointment with an available doctor, and the doctor sees the patient's complete visit history before writing a new prescription. Every appointment, prescription and bill is stored safely in a MySQL database, so records can be searched in seconds instead of being hunted through a cupboard. It is the same problem — solved properly, with software.
Why This Project Scores Well in Final Year
This project has a big, believable real-world scope without needing any fancy technology. Hospitals are easy for examiners to understand, and the workflow — patient arrives, appointment is booked, doctor consults, prescription is written — demos beautifully in two or three minutes. Unlike a single-role project, this one has three roles: admin or receptionist, doctor and patient. Showing that each role sees a different dashboard proves design maturity, and examiners notice that.
The viva is rich but predictable. Expect questions about role-based access, database normalisation, how you stop double-booking of a doctor, and how patient data stays private. If you can explain your tables and your login system calmly, this project comfortably earns top marks. It also leaves honest future scope — wards, pharmacy and lab modules — which gives you a confident answer to the classic last question, "What will you add next?"
Modules of the Project
Admin / Receptionist Module
- Dashboard: today's total patients, appointments, doctors on duty and pending bills at a glance.
- Register Patients: add new patients with name, age, gender, phone, address and blood group.
- Manage Doctors and Departments: add doctors, assign departments like General, Dental or Eye, and set consultation fees.
- Book and Cancel Appointments: book an OPD appointment against a doctor's available slots, reschedule or cancel when needed.
- Billing Summary: view consultation charges per patient and daily collection totals.
- Reports: daily appointment report, doctor-wise patient count and department-wise visits.
Doctor Module
- Today's Appointments: a clean list of the day's patients in time order, with token numbers.
- Patient History: previous visits, past complaints and old prescriptions before starting a consultation.
- Add Prescription and Notes: record diagnosis, medicines with dosage, tests advised and the next visit date.
The patient side is kept simple on purpose. Patients can book an appointment by choosing a department and doctor, and later log in to view their prescriptions and complete visit history — very useful when the paper prescription inevitably goes missing. The patient registration and login flow follows the same proven pattern as our student registration and login project, so if you have built that mini project, this module will feel familiar.
Main Features
| Feature | What It Does |
|---|---|
| Appointment Scheduling | Books OPD appointments only in a doctor's available slots, so two patients never clash at the same time. |
| Complete Patient Visit History | Every visit, complaint and prescription of a patient is stored and shown in date order to the doctor. |
| Prescription Records | Doctors save medicines, dosage and advice digitally; patients can view and print them any time. |
| Department-Wise Doctor Search | Patients and receptionists find the right doctor by department, specialisation or name. |
| Role-Based Dashboards | Admin, doctor and patient each get a separate login and see only their own screens and data. |
| Billing Summary | Consultation fees are recorded per appointment with a daily collection view for the front desk. |
| Quick Reports | Appointment, doctor-wise and department-wise reports for hospital management in one click. |
Technology Stack
| Layer | Technology |
|---|---|
| Frontend | HTML, CSS and JavaScript |
| UI Framework | Bootstrap |
| Backend | PHP 8.x |
| Database | MySQL |
| Local Server | XAMPP (Apache + MySQL) |
| Database Tool | phpMyAdmin |
The stack is free and runs on any college lab computer. Because patient records are sensitive, security matters more in this project than in most. Store passwords properly — learn to hash passwords in PHP instead of saving them as plain text — and run database queries through PHP Data Objects (PDO) with prepared statements, so the login and search forms stay safe from SQL injection.
Database Tables
Four main tables carry the whole system. Patients and doctors are the master records, appointments connect them, and prescriptions store what happened in each visit.
| Table | Purpose |
|---|---|
| patients | Stores patient profile: name, age, gender, phone, address and blood group. |
| doctors | Stores doctor details: name, department, specialisation, fee and available days. |
| appointments | Links a patient and a doctor with date, time and status of the visit. |
| prescriptions | Stores diagnosis, medicines, dosage and notes written against an appointment. |
Here is the SQL for the appointments table, the heart of the system. The official MySQL CREATE TABLE documentation explains every column option used here.
CREATE TABLE appointments (
id INT AUTO_INCREMENT PRIMARY KEY,
patient_id INT NOT NULL,
doctor_id INT NOT NULL,
appointment_date DATE NOT NULL,
appointment_time TIME NOT NULL,
status ENUM('Booked','Completed','Cancelled') DEFAULT 'Booked',
FOREIGN KEY (patient_id) REFERENCES patients(id),
FOREIGN KEY (doctor_id) REFERENCES doctors(id)
);How to Run This Project on XAMPP
- Download and install XAMPP, then open the XAMPP Control Panel and start the Apache and MySQL services.
- Extract the project files and copy the project folder into the htdocs folder inside your XAMPP installation directory.
- Open your browser and go to localhost/phpmyadmin, then create a new database for the project.
- Select the new database, open the Import tab, choose the provided .sql file and import it to create all the tables.
- Check the database connection settings in the project's config file so the database name and username match your setup.
- Now open localhost followed by your project folder name, and log in with the admin, doctor and patient demo accounts given in the project readme file.
What You Get in the Complete Project
The complete package gives you the full source code with the database file, ready to run on XAMPP and customise with your own hospital name, departments and doctors. It also includes a ready project report with the synopsis, system requirements, DFD, ER diagram, table structures and screenshots of every screen, plus a clean PPT for your final presentation and viva. You can get the complete package from the Coding Cush shop. Run all three logins yourself before demo day — the viva becomes much easier when you have clicked every button at least once.
FAQ
Patient data is sensitive — how is it secured in this project?
Three layers protect the data. Role-based login means a patient can never open admin or doctor screens. Passwords are stored as strong hashes, never as plain text. And all database queries use PDO prepared statements, which blocks SQL injection attacks on the login and search forms.
Can this system scale to wards and rooms later?
Yes. You can add a wards table and a room_allotments table on the same pattern as appointments, then extend the patient module with admission and discharge. It is a safe, honest future-scope point for your report and viva.
Which viva questions are asked on this project?
Common ones include: "How do you prevent two patients from booking the same doctor at the same time?" — answered by checking the doctor's booked slots before confirming — and "Why does the prescription table link to the appointment and not only to the patient?" — because one patient visits many times, and each prescription belongs to one specific visit.
Is this project too big for one semester?
It can be, if you try to build everything. Scope it smartly: finish patient registration, doctor management, appointment booking and prescriptions first — that is a complete, demo-ready system. Keep billing simple and treat wards, pharmacy and lab reports as future scope.
Conclusion
The Hospital Management System is a mature, marks-friendly final-year project: a real problem, three clean user roles and a database design you can defend with confidence. Build the core modules well, run it on XAMPP, and practise the three logins before demo day — you will present like someone who has actually worked in a hospital, not just read about one.
Leave a Comment