STUDENT’S DECLARATION

We hereby declare that project report entitled “Hospital Appointment System ‘Butwal
Multiple Hospital ‘ : A Web Site “ submitted to the partial fulfillment of the requirement for
Bachelor’s Degree in Computer Science and Information Technology of Tribhuvan
University , is our original work and not submitted for the award of any other degree,
diploma, fellowship, or any other similar title or prize .

……………………………
Nakul Pandey (30184/078)

……………………………
Sajal Bir Bajracharya (30203/078)

…………………………….
Sangeet Shrestha (30207/078)

i
 Supervisor’s Recommendation

BUTWAL MULTIPLE CAMPUS

Tribhuvan University

I hereby recommend that this project report prepared under my supervision by NAKUL

PANDEY, SAJAL BIR BAJRACHARYA and SANGEET SHRESTHA

Entitled “HOSPITAL APPOINTMENT SYSTEM” in partial fulfillment of the
requirement for the degree of [Link]. in Computer Science and Information Technology of
Tribhuvan University be processed for evaluation.

…………………………….
Taranath Jaishy
Project Supervisor

ii
 Letter Of Approval
This is to notify that the project titled “Hospital Appointment System: Butwal

Multiple Hospital” prepared by Nakul Pandey (30184/078), Sajal Bir Bajracharya

(30203/078) and Sangeet Shrestha (30207/078) in a partial fulfillment of the project of
seventh semester of [Link]. Computer Science and Information Technology has been well
studied and approved for further development.

………………………………
Arun Kumar Kshetree
Campus Chief
Butwal Multiple Campus

……………………………… ………………………………
Gobinda Adhikari Taranath Jaishy
Program Coordinator Supervisor
Butwal Multiple Campus Butwal Multiple Campus

……………………………… ………………………………
Internal Examiner External Examiner
Butwal Multiple Campus IOST: Tribhuvan University

iii
 ACKNOWLEDGEMENT
Our forthright gratefulness to our supervisor Taranath Jaishy, Lecturer, Department of
Computer Science and Information Technology, Butwal Multiple Campus, for wholehearted
support and for providing us the opportunity to undertake this project. We would like to
extend our sincere gratitude to Mr. Bhuban Panthee, Mr. Mr. Abdul Hak Manihar, Mr.
Dinesh Neupane, Mr. Chiranjivi Regmi, Mr. Yuba Raj Khanal and Mr. Nirmal Thapa,
Lectures, Department of Computer Science and Information Technology, for their kind and
co-operative support, valuable time and guidance as well as suggestions. Their useful
suggestions for this whole work and co-operative behavior are sincerely acknowledged.
We are also thankful to Mr. Gobinda Adhikari , HOD, Department of Computer Science
and Information Technology, Butwal Multiple Campus for his support.
At the end we would like to express our sincere thanks to all our friends and others who
helped us directly or indirectly during the preparation of this project.

Thanking You,
Nakul Pandey (30184/078)
Sajal Bir Bajracharya (30203/078)
Sangeet Shrestha (30207/078)

iv
 ABSTRACT
Hospital Appointment System ‘Butwal Multiple Hospital’ is a web-based platform whose
purpose is to eradicate the manual system of hospital appointment. This platform is meant for
patient, doctor and admin to make, cancels and prescribe the appointment. Patient can create
their own account(id) providing their information like name, phone number, email. All the
information is stored in database. When the patient needs appointment then he/she can login
and make appointment or cancels it. Doctor also can login and prescribe for small talks also
can cancels the appointment if he/she have emergency and can’t attends patients for
treatment.

Keywords: hospital appointment, patient, doctor, admin(receptionist), HTML,

PHP,MySQl, CSS, Xampp

v
 List of Tables
1 Test case for Unit testing..................................................................................................................20
2 Test Case for Integration Testing.....................................................................................................21

vi
 List of Figures
Figure 1SDLC Model............................................................................................................................6
Figure 2: Work breakdown structure.....................................................................................................8
Figure 3 Schedule feasbility................................................................................................................11
Figure 4Use case diagram...................................................................................................................13
Figure 5System flowchart...................................................................................................................14
Figure 6 Activity diagram...................................................................................................................15

vii
 Abbreviations

API : Application Programming Interface

BMH : Butwal Multiple Hospital
HAS : Hospital Appointment System
RAM : Random Access Memory
SDLC : System Development Life Cycle
SDM : System Development Model
WBS : Work Breakdown Structure

viii
 Table of Content
STUDENT’S DECLARATION......................................................................................................................i
Supervisor’s Recommendation..............................................................................................................ii
Letter Of Approval.................................................................................................................................ii
ACKNOWLEDGEMENT...........................................................................................................................ii
ABSTRACT..............................................................................................................................................ii
List of Tables..........................................................................................................................................ii
List of Figures........................................................................................................................................ii
Abbreviations........................................................................................................................................ii
Chapter 1: Introduction.........................................................................................................................2
1.1 Introduction..........................................................................................................................2
1.2 Problem Statement.....................................................................................................................2
1.3 Objectives....................................................................................................................................2
1.4 Scopes.........................................................................................................................................2
1.5 Limitations...................................................................................................................................2
CHAPTER 2: Requirement and Feasibility Analysis................................................................................2
2.1 Literature Review........................................................................................................................2
2.1.1 Bir Hospital (NAMS)..............................................................................................................2
2.1.2 B.P. Koirala Institute of Health Sciences (BPKIHS)................................................................2
2.1.3 HamroDoctor........................................................................................................................2
2.2 System Development Model.......................................................................................................2
2.3 Work Breakdown Structure (WBS)..............................................................................................2
2.4 Requirement Analysis..................................................................................................................2
2.4.1 User Requirement................................................................................................................2
2.4.2 Functional Requirement.......................................................................................................2
2.4.3 Non-Functional Requirement...............................................................................................2
2.4.4 System Requirements..........................................................................................................2
2.5 Feasibility Analysis.......................................................................................................................2
2.5.1 Technical Feasibility..............................................................................................................2

ix
 2.5.2 Operational Feasibility..........................................................................................................2
2.5.3 Economic Feasibility.............................................................................................................2
2.5.4 Schedule feasibility...............................................................................................................2
Chapter 3: System Decision...................................................................................................................2
3.1 Design..........................................................................................................................................2
3.2 System Diagram..........................................................................................................................2
3.2.1 Use Case Diagram.................................................................................................................2
3.2.2 System Flowchart.................................................................................................................2
3.2.3 Activity diagram...................................................................................................................2
Chapter 4: System Implementation......................................................................................................2
4.1 Implementation...........................................................................................................................2
4.2 Implementation Environment.....................................................................................................2
4.3 Tools Used for Development.......................................................................................................2
Chapter 5: Testing and Result Analysis..................................................................................................2
5.1 Testing.........................................................................................................................................2
5.2 Testing Plan.................................................................................................................................2
5.3 Testing Strategy...........................................................................................................................2
5.4 Test Cases....................................................................................................................................2
5.4.1 Unit Testing..........................................................................................................................2
5.4.2 Integration testing................................................................................................................2
5.4.3 System testing......................................................................................................................2
Chapter 6: Conclusion...........................................................................................................................2
6.1 Conclusion...................................................................................................................................2
6.2 Recommendation........................................................................................................................2
References............................................................................................................................................2
Appendix...............................................................................................................................................2

x
xi
 Chapter 1: Introduction
1.1 Introduction
In many public and high-traffic hospitals, especially in developing countries like Nepal, the
appointment scheduling system is still heavily reliant on manual processes. Patients are often
required to physically visit hospitals early in the morning, stand in long queues, and wait for
hours just to book a routine appointment. This outdated method not only consumes time and
causes frustration but also leads to overcrowding in hospital premises, increasing the risk of
cross-infection—especially during times of public health crises such as pandemics.
Moreover, patients often face uncertainty about doctor availability or appointment slots.
Doctors, on the other hand, have limited tools to view, manage, or adjust their daily
schedules. Administrators in busy hospitals also struggle to track appointment records,
patient flow, and departmental workload without a structured digital system.
To address these growing challenges, there is a clear and urgent need for a robust, web-based
Hospital Appointment Management System. Such a system would empower patients to
register and book appointments online, allow doctors to manage or refer appointments
digitally, and enable administrators to oversee hospital operations through a centralized
platform. By streamlining appointment scheduling and communication between stakeholders,
the proposed system aims to reduce waiting times, prevent scheduling conflicts, and enhance
the overall quality of healthcare services.

1.2 Problem Statement

In many hospitals, particularly public and high-volume institutions, the process of booking
appointments remains largely manual or semi-automated, leading to several inefficiencies
and challenges. Patients are often required to be physically present at the hospital to schedule
an appointment, which not only causes inconvenience but also contributes to overcrowding
and long waiting times. There is no provision for booking appointments remotely or outside
of standard hospital hours, limiting accessibility and flexibility for working individuals or
those from remote areas. Additionally, hospital administrators struggle to maintain accurate
records, monitor patient traffic, and generate reports due to the lack of centralized data

1
management. These issues collectively hinder the overall efficiency, responsiveness, and
quality of healthcare services provided.
A robust, multi-interface system is needed to automate appointment booking, enhance
doctor-patient coordination, and give administrators oversight.

1.3 Objectives
In many hospitals, particularly public and high-volume institutions, the process of booking
appointments remains largely manual or semi-automated, leading to several inefficiencies
and challenges. Some of the major objectives of our system are as follows: -
 To provide the online appointment system that eradicate the need to be present
physically
 To automate the process of the appointment and scheduling the appointment in the
case of cancellation of the appointment using observer pattern algorithm.
 To provide appointment management for doctor by providing different interface to
doctor.

1.4 Scopes
The scope of a web-based hospital appointment system dictates what the system will contain,
its functionality, and where it will be deployed. The following are the primary scopes:
1. Patient Management
User Registration & Login: Patients can register and login safely.
Profile Management: Patients can update personal details like name, contact, and address.
Appointment Booking: Patients can schedule appointments with doctors of their choice.
Cancellation & Rescheduling: Facility to reschedule or cancel the appointments.
View Appointment History: View future and historical appointments.
2. Doctor Management
Doctor Profiles: Doctors can register, update specialization and working hours.
Availability Management: Doctors can schedule their availability for appointments.
View Appointments: Doctors can view the patients' appointments list for consultation.

2
3. Appointment Scheduling
Real-time Slot Availability: System shows available time slots to avoid double booking.
One Patient per Slot: Prevent booking of the same slot by more than one patient.
Rescheduling after Cancellation: Release the next patient automatically or free the slot.
4. Notifications & Alerts
Email/SMS Notifications: Confirmation, reminder, or cancel notification to patients and
doctors.
In-app Notifications: Upcoming appointments notifications in the dashboard.
5. Administration
User Management: Admin can approve, block, or remove doctors and patients.
Appointment Management: Admin can see, edit, or cancel appointments.
Reports & Analytics: Offer appointments, availability of doctors, and patient visit reports.
6. Billing & Payments (Optional)
Online Payment Gateway Integration: For consultation fees or booking fees.
Invoice Generation: Generate bills and receipts in PDF.
7. Security & Privacy
Role-Based Access Control: Multiple levels of access for patients, doctors, and admin.
Data Encryption: Secure patient and appointment details.
Compliance: HIPAA or local health data privacy regulations.
8. Technology Scope
Web-Based Interface: Accessible via browsers (desktop & mobile).
Database Integration: Saving patient, doctor, and appointment data.
Responsive Design: Working on various screen sizes and devices.

1.5 Limitations
Here are some typical constraints of a hospital appointment system in web-based form:
1. Internet Dependence
The system relies on a stable internet connection for the doctor and patient.
Poor connectivity would lead to postponing booking or seeing appointments.
2. Digital Literacy Hurdle
Non-technology-educated patients may find it difficult to use the system.

3
Patients who are older or rural may prefer old ways.
3. Device Accessibility
Users need a device (computer, smartphone, tablet) to access the system.
Patients without devices are out.
4. Limited Physical Check-up
Purpose of the system is merely booking appointments; actual check-up still requires
physical visit (unless fully integrated with telemedicine).
5. Server Down
Server crashes, maintenance, or equipment breakdown renders the system inaccessible for a
brief duration.
6. Security Risks to Patient Data
Patient data is at risk if security measures (encryption, authentication) are not strong.
Subject to unauthorized access or hacking.
7. No Guarantee of Timely Service
Still subject to delays even after reservation, given physician availability or unexpected
emergencies.
System cannot control real-time delay in the hospital.
8. Limited Emergency Handling
Not ideal for emergency or urgent situations wherein immediate treatment is required.
Patients can rely on the system more than getting immediate care.
9. Setup & Maintenance Charge
Hospitals need to invest in servers, hosting, and IT staff.
It needs to be updated and serviced frequently so it keeps working and stays secure.
10. Limited Integration
Unless integrated with hospital ERP or lab systems, patients still need to come physically to
receive reports, billings, etc.

4
 CHAPTER 2: Requirement and Feasibility Analysis
2.1 Literature Review
2.1.1 Bir Hospital (NAMS)
• Public hospital in Kathmandu using MeroDoctor as its online appointment portal
([Link]).
• Limitation: Third-party dependence and limited control over platform features. [1]
2.1.2 B.P. Koirala Institute of Health Sciences (BPKIHS)
• Online appointment system implemented post-COVID for general and paying OPD.
• Limitation: Limited visibility and awareness among patients outside Dharan. [2]
2.1.3 HamroDoctor
• Nepal’s first online healthcare platform allowing patients to book appointments at
hospitals and clinics without waiting in queues.
• Limitation: Availability depends on hospital tie-ups; some listings may be outdated.
[3]

2.2 System Development Model

System Development Models are systematic approaches used in software engineering
to plan, design, develop, and maintain software systems. Following are some of the popular
models with descriptions and images (diagrams). Since HAS of BMH is waterfall SDM so
describing waterfall model below:
1. Waterfall Model
Description: A sequential and linear process. The phases have to be completed one after the
other. The phases of the waterfall model are:
 Requirement Analysis
 System Design
 Implementation
 Testing
 Deployment
 Maintenance
Best for: Small projects with clear requirements.

5
 Figure 1SDLC Model

2.3 Work Breakdown Structure (WBS)

A work breakdown structure is a deliverable-oriented breakdown of a project into smaller
components. WBS for BMH HAS can be presented as hierarchical tree structured as shown
below. It is a key project deliverable that organizes the team’s work into manageable
sections.
HAS can be developed with the combined process of requirement collection, designing,
implementation, coding and testing. Different work are assigned to all three members. All
members focus on requirement gathering, research, design. Coding, implementation and
documentation of the project.
So, the work breakdown of this system is shown below:

6
 Hospital Appointment System

Requirement Design Coding Testing

Collection

Internet User Interface Error checking

Interface
research

Analysis Prototype Backend design Debugging

Documentation Documentation Documentation Documentation

Figure 2: Work breakdown structure

2.4 Requirement Analysis

Requirement analysis, also called requirement engineering is the process of determining user
expectation for new or modified product. This feature, called requirement must be
quantifiable, relevant and detailed. In software engineering such requirement are often called
functional specification. It is an important aspect of project management.
2.4.1 User Requirement
Based on research and analysis, the following are the core requirements for the system:
Client (Patient) Requirements:

7
 • Register and log in securely.
• Search for doctors by department/ward.
• View available doctors and select preferred time slots.
• Book, cancel, or reschedule appointments.
• Receive confirmation and reminders via email or SMS.
• Pay online via digital gateways.
Doctor Requirements:
• Secure login access to a personalized dashboard.
• View upcoming appointments by time and date.
• Cancel or refer appointments to other doctors.
• Access to patient information for better treatment planning.
Admin Requirements:
• Manage user accounts (clients and doctors).
• Monitor system activities and logs.
• View appointment analytics and generate reports.
• Update department and doctor data.

2.4.2 Functional Requirement

 Login Management (Role based login)
 Appointment Management
 Schedule Management (Real time reporting)

2.4.3 Non-Functional Requirement

 Security and privacy
 Maintainability
 Usability
 Reliability

2.4.4 System Requirements

Hardware Requirement
 Laptop, desktop

8
  Internet connection
 Minimum 4gb RAM
Software Requirement
 Web Browser: Google Chrome, Safari etc
 Xampp

2.5 Feasibility Analysis

The feasibility analysis assists to analyze whether the software meet required
requirements can be implemented using the current technology and within specified
budget and schedule. It guides the project team in determining whether to proceed
with the project and it identifies the important risks associated with the project that
must be managed if the project is approved.

2.5.1 Technical Feasibility

The system will be developed using widely available, open-source technologies:
• Frontend: HTML, CSS, JavaScript
• Backend: PHP
• Database: MySQL
• Web Server: Apache (via XAMPP or online hosting)
The project team has the required knowledge to implement and maintain this stack.
No proprietary software is needed, reducing cost and risk.

2.5.2 Operational Feasibility

• The system is designed to be user-friendly with role-based interfaces for clients,
doctors, and administrators. A web-based application ensures it can be accessed on
computers, tablets, or smartphones, requiring only a browser and internet connection.
It also supports digital payment gateways for convenience.

2.5.3 Economic Feasibility

• The costs involved include:

9
 • Domain registration and hosting
• Optional SMS/email gateway integration
• Time investment for development and testing
• Since the system uses open-source tools and local hosting, overall expenses are
minimal. In the long term, the system reduces manual work and operational costs for
hospitals

2.5.4 Schedule feasibility

• This project is feasible within academic period which makes it possible within the
given time frame. Scheduling of the project is shown in the Gantt chart.
• [Grab your reader’s attention with a great quote from the document or use this space to
emphasize a key point. To place this text box anywhere on the page, just drag it.]

Figure 3 Schedule feasbility

10
 Chapter 3: System Decision
3.1 Design
System design is a process of defining the architecture, modules, interfaces and the
data for the system to satisfy specified requirements. It is the process of defining,
developing and designing systems which satisfies the specific needs and requirements
of a business or organizations. Modeling language is used to express the information
and knowledge in a structure of system that is defined by consistent set of rules and
definitions.

3.2 System Diagram

A system diagram is a visual representation of a system, showing the relationships and
interactions between the components of the system. You can use this diagram to understand,
design, analyze, and document a process. System diagrams typically show the components of
a process, including the hardware, software, databases, and people involved, as well as the
communication pathways between them. They also show how information is exchanged
between the components and how they interact with each other. We can use a system
diagram for many different purposes, like understanding a system's architecture, creating
system designs, troubleshooting problems, and creating user documentation. During the
development of Hospital Appointment System, following diagrams were used for
understanding the requirements of the system.

3.2.1 Use Case Diagram

Use case diagram is a dynamic or behavioral diagram in UMl. Use case diagram
model the functionality of system using actors and use cases. Use cases are the set of
action, services, and functions that the systems need to perform. In this case the
system is HAS and the actors are patient, doctor and admin.

11
3.2.1 Use Case Diagram

Figure 4Use case diagram

12
3.2.2 System Flowchart

Figure 5System flowchart

13
3.2.3 Activity diagram

Figure 6 Activity diagram

14
 Chapter 4: System Implementation

4.1 Implementation
System implementation deals with development of the system and the tools that were used
for the development. The purpose of implementation phase of system development is to
translate the system design into source code. The primary goal of the implementation is to
write source code and internal documentation so that conformance of the code to its
specification can be easily verified, and so that debugging, testing and modification are
eased.

4.2 Implementation Environment

HAS is a web-based platform which can be accessed by any number of users at a time.
Different users from different places can register and use the system. There is no constraint
for the number of users accessing the system. It has easy user interface design and it is so
user friendly that easy unknown user can easily use it without any complexity.

4.3 Tools Used for Development

 Web Browser: Google Chrome, Safari etc
 Frontend: HTML, CSS, JavaScript
 Backend: PHP
 Database: MySQL
 Web Server: Apache (via XAMPP or online hosting)
 Documentation: MS-WORD
 Figure and diagrams: [Link]

HTML:
For the implementation in the front end HTML was used. It was indeed used for a better
looking and make user feel with the display of the contents of the design and the system.

15
Bootstrap for our responsive site was applied. Different mark-up tags are used like anchor tag
for link bold tag for making the font bold.
CSS:
For the style implementation CSS is used. CSS made our system more decorative which can
make the users feel good looking site. Taking margins, providing sizes, color filling for
various pages and contents and other several designs are implemented using the concept of
the CSS.
JavaScript:
JavaScript is most commonly used as a client-side scripting language. This means that
JavaScript code is written into an HTML page When a user requests an HTML page with
JavaScript in it, the script is sent to the browser and it’s up to the browser to do something
with it.
MySQL:
For the database connection MySQL, is used in this project. Various queries are used to
interact with the database. Insertion, edit, delete selection of the data are performed through
queries. Database have various tables like registration table, login table, book details table
etc. It is always written inside the PHP tag.
PHP:
Hypertext Pre-processor PHP is used to validate in the server side. Project was dynamically
implemented by using PHP. There is a dynamic page content in our site. User can
dynamically access the system and interact with facilities which they want, to make this
success and possible. PHP has been used in the system. Admin handle the site dynamically
only with the use of different php variables, functions and methods.

16
 Chapter 5: Testing and Result Analysis

5.1 Testing
Testing is the process carried out on software to detect the difference between its behavior
and the desired behavior as stipulated by the requirements specifications. Testing is
advantageous in several ways. Firstly, the defects found helps in the process of making the
software reliable. Secondly, even if the defects found are not corrected, testing gives and idea
as to how reliable the software is. Thirdly, overtime, the records of defects found reveals the
most common type of defects, which can be used for developing appropriate preventive
measures such as training, proper design and reviewing.

5.2 Testing Plan

The testing sub-process includes the following activities in a phase dependent manner:
 Create test plans
 Create test specifications
 Review test plans and test specifications
 Conduct test according to the text specification, and the log defects.
 Fix defects, if any.
 When defects are fixed continue from activity.

5.3 Testing Strategy

The development process repeats this testing sub-processes a number of times for the
following phases:

17
  Unit testing
 Integration testing
 System testing
 Acceptance testing

5.4 Test Cases

5.4.1 Unit Testing
This test is done to determine the working of the individual modules The HAS includes the
various modules that are tested at the development processes.
Test Test Case Precondition Input data Expected Actual result Pass/Fail
No. test result
1 Test if user is User should Correct data User must User is pass
able to register not have this such as successfully successfully
account correct form register registered
of gmail,
password
2 Test if user is User should Incorrect User must User is not pass
not able to not have this data as not be able registered
register account incorrect to register and gets
form of and error error
gmail , message message
password should toast
3 Test if user is User should Correct data User must User is not pass
not able to have as correct not be able registered
register registered form of to register and gets
with this gmail, and get message
account password error
message
4 Test if user is User should Correct User must User is pass
able to login have email and be logged in
successfully successfully

18
 registered. password login and enters
into profile
page
5 Test if user is User should Incorrect User must User is not pass
not able to have email and be able to able to login
login registered. password login and gets
error
message
6 Test if user is User User must User is not pass
not able to shouldn’t not be able able to login
register have to login and gets
registered the error
account. message
7 Test if user is User should New updated User Users’ pass
able to edit have those information information information
information fields already must be is updated
updated

8 Test if user is Service Select the User must Patient sees pass
able to see provider service be able to the
service should have provider see the information
provider registered information about
about selected
selected doctor
doctor

1 Test case for Unit testing

5.4.2 Integration testing

Test Test Cases Expected Result Actual Result Pass/Fail

No

19
 1 Test if after registration After The user signs pass
the user can have logged registrations the up and login is
in successfully user must have successful
logged in
successfully
2 Test if after login the After login the The user login pass
user gets into own profile user must get and gets into its
page and can update into profile and profile activities
information can update and can easily
information update
information
3 Test if after editing the The change The new pass
information the change is must be information is
reflected in the database reflected in the saved in
database database

2 Test Case for Integration Testing

5.4.3 System testing

System testing is used to check the overall interaction of components. It involves the load,
performance, reliability and security testing. It tests a completely integrate system. It also
checks the logic changes made in it with the intention of finding error. This process helps in
validating the system by testing the system as a whole that covers each module of the
application, database specifications and underlying configuration. The HAS is tested by
using the technique to make it more reliable.

20
 Chapter 6: Conclusion
6.1 Conclusion
BMH HAS is web-based platform that works as a bridge between patient, doctor and admin.
As proposed this system will help patient to make schedule, cancel schedule. At first, user
needs to register and login on our HAS. After, login one can schedule the time based on their
comfort zone and after that doctor diagnose the patient. Here the patient can either take
appointment or cancel the appointment. It creates hospital appointment as business by
providing bigger platform and opportunity. HAS is a solution for doing scheduling virtually
and giving comfort time for both doctor and patient.

6.2 Recommendation
The HAS system has very simple feature at present. User can schedule at their desired time
and take appointment with doctor. On near future app will be developed along with APIs for
online payment. Similarly, system will be upgraded based on the responses and feedback
from the users.

21
 References
[1] “Bir Hospital” [Online]. Available: [Link]
[2] “BP Koirala Institute of Health Sciences” [Online]. Available:
[Link]
[3] “HamroDoctor” [Online]. Available: [Link]

22
Appendix

23
24
25
26
27
28
29
30
31
32
33