1

Ex .No: 1 IDENTIFY A SOFTWARE SYSTEM THAT NEEDS TO BE

DEVELOPED

HTML (HyperText Markup Language)

HTML is the standard markup language for creating the structure and content of web pages.

a. Page Structure: HTML defines the layout of all pages in the HMS, such as login pages,
appointment forms, patient dashboards, doctor schedules, billing forms, etc.

b. Form Creation: It is used to build forms for tasks like patient registration, appointment
booking, adding medical records, and generating reports.

c. Content Display: HTML tags are used to display text, tables (e.g., lab reports, prescriptions),
images (e.g., scanned documents), and links.

d. Navigation: HTML is used to create navigation menus, sidebars, and internal linking between
pages (e.g., from patient dashboard to appointment history).

e. Media Embedding: Supports embedding instructional videos or diagrams for patient care and
education.

CSS (Cascading Style Sheets)

CSS is used to design and style the HTML content, making the HMS user-friendly and visually
appealing.

a. Responsive Design: Ensures the system is accessible on various devices like desktops, tablets,
and smartphones (important for doctors on the go).

b. Consistent UI: Provides a consistent look across all pages—colors for different roles (e.g.,
admin, doctor, patient), standardized fonts, and spacing.

c. Enhanced Usability: Highlights errors (e.g., incomplete form fields), status indicators (e.g.,
patient admitted or discharged), and feedback messages (e.g., “Appointment Confirmed”).

d. Animations and Transitions: CSS can add subtle transitions for smoother user experiences—
for example, page loaders, dropdown menus, or alert fade-ins.

e. Dark/Light Mode Support: Allows easy switching between light and dark modes for better
user comfort, especially in low-light hospital environments.
 2

PHP (Hypertext Preprocessor)

PHP is a server-side scripting language used to handle the logic, data processing, and database
interaction in a Hospital Management System.

a. Form Handling: Processes submitted data from HTML forms—like registering new patients,
booking appointments, updating medical records, or billing.

b. Database Communication: PHP connects to a MySQL or MariaDB database to fetch, insert,

update, or delete data such as user details, appointments, lab reports, prescriptions, etc.

c. Session Management: Manages login sessions and user authentication for different roles
(admin, doctor, nurse, patient), ensuring secure access.

d. Role-Based Access: Implements different views and actions based on user roles (e.g., doctors
can write prescriptions; patients can only view them).

e. Security Features:

 Data validation and sanitization to prevent SQL injection or XSS attacks.

 Password encryption using functions like password_hash() and
password_verify().
 Token-based CSRF protection for secure form submission.

f. API Integration: Can be used to connect with external services like SMS gateways (for
appointment reminders), labs (for real-time test reports), or insurance systems.

g. Generating Reports: Automatically generates printable reports or PDFs for patient history,
prescriptions, discharge summaries, or financial records.

h. Email and Notification: Sends confirmation or notification emails/SMS for new appointments,
lab reports availability, billing updates, etc.

PROBLEM STATEMENT:

The current process of managing hospital operations such as patient registration, appointment
scheduling, doctor assignments, billing, and medical records is largely manual or scattered across
disconnected systems. This can result in delays, errors, and inefficiencies that affect both patients
and healthcare providers.The Hospital Management System (HMS) aims to address these issues
by providing a centralized web-based solution using HTML, CSS, and PHP. The system will
streamline hospital operations by allowing administrators to manage patient records, appointments,
staff, billing, and reports in an organized and secure manner. Patients can also register online,
book appointments, and view their reports through a user-friendly interface.
 3

Ex. No: 2 Document the Software Requirements Specification (SRS) for the
identified system

1. Table of Contents

Section Page
1. Introduction 4
1.1 Purpose 4
1.2 Definitions, Acronyms, Abbreviations 5
1.3 References 5
1.4 Overview 5
2. Overall Description 6
2.1 Product Perspective 6
2.2 Product Functions 7
2.3 User Classes and Characteristics 8
2.4 Constraints 8
2.5 Assumptions and Dependencies 8
3. Special Requirements 9
3.1 User Interfaces 9
3.2 Hardware Interfaces 10
3.3 Software Interfaces 10
3.4 Communications Interfaces 10
4. Other Nonfunctional Requirements 11
4.1 Server Requirements 11
4.2 Client Requirements 11
4.3 Hospital Management System Requirements 12
4.4 Performance Requirements 12
4.5 Decision Constraints 12
4.6 Software System Attributes 12
5. Other Requirements 14
5.1 Risk Management 14
5.2 Gantt Chart 14
 4

1.Introduction

1.1 Purpose

The purpose of this SRS (Software Requirements Specification) document is to provide a

detailed description of our software project, specifications, and goals. This document describes the
features included that are included in our project, its user interface, and its functionality. The
document describes hour our team sees and understands the requirements of the software.

1.1 Definitions, Description, Abbreviations

Term
Description
HMS Hospital Management System – A system
designed to automate and manage hospital
operations digitally.
C-Requirements Customer Requirements – Requirements
specified and easily understood by the
customer.
sD-Requirements Developer Requirements – Detailed product
requirements as provided to developers.
Data-flow Diagram showing the flow of data between
processing elements in the hospital system.
Hospital XYZ Name placeholder for the client hospital
(replace "XYZ" with the actual hospital name if
needed).
GUI Graphical User Interface – Visual interface for
user interaction with the system.
SRS Software Requirements Specification –
Document that defines the system's complete
functional and non-functional requirements.
State-Transition Diagram that shows the transition of the system
from one state to another (e.g., appointment
booked → consultation completed).
Use-case Diagram describing how a user (doctor, patient,
admin) interacts with the Hospital Management
System.
 5

1.2 References

 IEEE Software Requirements Specification Standard (IEEE 830-1998) – Guidelines

for writing clear and complete SRS documents.

 JavaFX Documentation – Official guide for designing and developing graphical user
interfaces (GUI) in Java.

 Hospital Management System Research Papers – Studies and articles describing best
practices for hospital automation.

 API Integration Standards – Standards for integrating external laboratory, pharmacy, and
billing systems.

1.4Overview

This document provides a complete description of the software requirements for the
Hospital Management System (HMS). It explains the overall functionalities, features, and
operations of the system, including patient management, appointment scheduling, doctor and staff
management, billing, pharmacy integration, laboratory management, and report generation. The
HMS aims to improve hospital efficiency by automating administrative tasks, securing patient
data, and ensuring real-time access to critical information. This Software Requirements
Specification (SRS) will guide the development team, testers, and stakeholders throughout the
design, development, and implementation phases. The document is structured to first describe the
system’s overall functionality, then provide detailed functional and non-functional requirements,
followed by system interfaces, constraints, and other important considerations.

2. Overall description

The Hospital Management System (HMS) is designed to automate and streamline the daily
operations of hospitals and healthcare facilities. It provides an integrated platform for managing
patient information, doctor schedules, medical records, billing, pharmacy, laboratory results, and
administrative activities. The system supports multiple user types including patients, doctors,
nurses, laboratory technicians, pharmacists, and hospital administrators. It ensures secure access to
medical data, fast processing of patient services, and efficient handling of hospital workflows. The
HMS will operate in a networked environment, supporting both centralized and distributed
hospital branches if required. It will also integrate with external systems like insurance
verification, diagnostic equipment, and government health databases where needed. The goal is to
enhance patient care, reduce manual work, improve resource utilization, and enable real-time
access to information across all departments of the hospital.
 6

2.1 Product Perspective

The Hospital Management System (HMS) is a standalone, integrated solution that can operate
independently or be linked with existing hospital infrastructure such as diagnostic machines,
pharmacy systems, and laboratory equipment. It is modular in design, allowing hospitals to
implement core functionalities first (like patient registration and appointment scheduling) and later
extend to other modules such as pharmacy, laboratory, or billing management. The HMS replaces
traditional paper-based management systems and manual record-keeping with a digital platform
that ensures accuracy, accessibility, and security. It will interact with backend databases through
Java Database Connectivity (JDBC) and present user-friendly interfaces via JavaFX. The system is
designed for scalability, ensuring that small clinics as well as large hospitals with multiple
branches can adopt it easily, with minimal customizations to suit specific operational needs.

2.1.1 Concept of Operations

The Hospital Management System (HMS) will allow for two different methods of operation.The
first method of operation will be through a patient portal. This interface will be operated by
patients, allowing them to register, book appointments, view prescriptions, access test reports, and
manage billing information. All actions will be carried out through a simple, easy-to-use graphical
user interface (GUI) designed for minimal technical knowledge. It will implement standard
navigation buttons, input forms, and action tabs to assist users in completing their tasks
smoothly.The second part of the system is the hospital administration portal. This software will
run on hospital computers and will be operated by doctors, nurses, lab technicians, pharmacists,
and administrative staff using a keyboard and mouse. The interface will revolve around a
centralized dashboard and menu bar, providing quick access to functions such as patient
registration, appointment management, doctor scheduling, test result uploads, billing, pharmacy
inventory management, and report generation. User roles and login authentication will control
access privileges, ensuring that each staff member can only access the modules relevant to their
responsibilities.

2.1.2 Major User Interfaces

A screen-flow diagram will illustrate how users interact with the system, starting from the login
screen to dashboards, patient details forms, appointment booking screens, medical record views,
billing modules, laboratory result forms, and pharmacy order screens. Navigation will be intuitive,
and users will be able to move between modules based on their assigned roles and tasks.

2.1.3 Hardware Interfaces

The Hospital Management System will operate using standard desktop and laptop hardware
available within hospitals. This includes monitors, keyboards, mice, barcode scanners (for patient
IDs or lab samples), printers (for prescriptions and billing receipts), and optional touchscreen
kiosks for patient self-service. The system will also support integration with medical devices for
automatic data recording where needed (e.g., lab equipment or diagnostic machines).
 7

2.1.4 Software Interfaces

The Hospital Management System will connect to a relational database (e.g., MySQL) using
JDBC. JavaFX will be used for the user interface. APIs will integrate with external systems such
as laboratory and pharmacy software.

2.1.5 Communication Interfaces

The Hospital Management System will use HTTP/HTTPS protocols for secure communication.
RESTful APIs will connect with external services like insurance systems and labs. Internal
communication will occur over the hospital’s LAN network, secured using SSL/TLS encryption.

2.1.6 Memory Constraints

The system will require a minimum of 8 GB RAM for server operations and 4 GB RAM for client
machines. Sufficient storage (at least 500 GB) must be available for storing patient records,
reports, and system backups.

2.1.7 Operations

The Hospital Management System must operate continuously with minimal downtime. Regular
backups, system monitoring, and maintenance activities like database optimization and security
updates will be performed to ensure smooth operation.

2.1.8 Site Adaptation Requirements

The system must support multiple languages (e.g., English, Spanish) and be adaptable to different
regional healthcare standards, such as data privacy regulations and insurance protocols.
2.2 Product Functions

The Hospital Management System (HMS) will provide the following key functions:

 Patient Registration and Management: Allows new patients to register, update personal
information, and view their medical records.
 Appointment Scheduling: Enables patients to book, reschedule, or cancel appointments
with doctors.
 Medical Record Management: Allows doctors and medical staff to record, update, and
access patient medical histories.
 Billing and Payment: Facilitates payment processing for hospital services, including
consultations, treatments, and tests.
 Inventory and Pharmacy Management: Tracks medication stock levels, prescription
fulfillment, and inventory management.
 Reporting: Generates reports on patient care, treatment, billing, and hospital performance.
 8

2.3 User Characteristics

The typical patient user will range from 10 years old and up, with a fairly equal distribution of
males and females. Most patients will likely use the system occasionally, such as to book
appointments, view test results, or manage their medical records. Since some patients may not be
familiar with technology, the system needs to be intuitive and easy to navigate. Given that patients
are often busy, it is crucial that they can complete their tasks quickly and efficiently.

The typical hospital staff user (doctor, nurse, etc.) will be more educated and experienced in
using software systems. They will use the HMS on a daily basis, handling various tasks such as
updating patient records, managing appointments, prescribing medications, and processing test
results. Functionality and efficiency are key for these users, as they interact with the system
frequently throughout the day. Given the high volume of patient data being processed, system
stability, speed, and reliability are essential.

The hospital administrator will manage the overall operations of the system, ensuring proper
functioning and compliance. They will use the system daily to manage users, generate reports, and
handle sensitive patient data. Administrators are highly knowledgeable and will require advanced
system features, with an emphasis on security and data integrity.

2.4 Constraints

Sources of other constraints on requirements

 Hardware Requirements

 Software Compatibility

 Security and Compliance

 Performance

 User Access and Training

 Data Migration

2.5 Assumption and Dependencies

 Hardware Reliability: It is assumed that the hospital’s hardware (servers, workstations,

medical devices) will function reliably without frequent failures or breakdowns.

 Data Accuracy: The system assumes that patient data entered by hospital staff (e.g.,
medical history, test results) will be accurate and up-to-date, with minimal errors in data
entry.
 9

 Internet Connectivity: The system assumes that there will be stable internet connectivity
for real-time data access and cloud-based services, such as backups and updates.

 Sufficient Resources: The system assumes that there will always be adequate resources
(e.g., paper for patient records, ink for printers) to support the daily operations of the
hospital, ensuring no interruption in service.

 Compliance with Healthcare Regulations: The system assumes that the hospital will
maintain up-to-date compliance with healthcare regulations (e.g., HIPAA) to ensure proper
data security and patient privacy.

 Hardware Failures: Breakdown of critical hardware such as servers, medical devices, or

workstations could disrupt system operations and data access.

 Data Integrity Issues: Incorrect or missing data due to manual entry errors, poor data
management practices, or corrupted databases could lead to operational failures and
misdiagnoses.

 Network Disruptions: Internet connectivity issues, such as network outages or

interruptions, could affect real-time access to patient data, cloud storage, or communication
between systems.

3. Special Requirements
3.1 User Interface

3.1.1 Server

The server will be a command-line application with a simple set of commands. Upon initialization,
it will prompt the user for the port number and the name of the hospital. The server will run
continuously until the user enters 'Q' to quit. All objects will be saved when the application exits.
Upon restart, the server will load patient and record data if the same hospital name is used. The
server will spawn separate threads to handle each incoming request.

3.1.2 Hospital Management System (HMS)

The system will feature a graphical user interface (GUI) for ease of use. The first screen will be a
login screen, where users will enter their credentials (such as a username and password). After
successful login, the user will be presented with different options such as creating a new patient
record, viewing patient history, scheduling appointments, etc.

 Patient Information: After login, users can access and update patient records, medical
history, and treatment plans.
 Appointment Management: Patients and medical staff can manage appointments,
including scheduling, rescheduling, and canceling appointments.
 Prescription and Billing: Users can manage prescriptions and process billing.
 10

The system will handle transactions like adding new patients or updating patient records. Any
errors, such as insufficient information or incorrect data entry, will be displayed for the user.
Additionally, there will be a help section to guide users through the processes.

1. Teller Software

The teller software, used by hospital staff for administration, will also have a login prompt for
authentication. The login information will be authenticated through the server. The main screen
will feature a toolbar with options for various functions such as managing patient records, billing,
and authorizing new appointments.

 Customer Management: Hospital staff can add new patients, search for patients, and
delete records as needed.
 Transaction Processing: Staff can process patient transactions such as updating payment
statuses, creating new patient accounts, and authorizing appointments or treatments.

All requests from the teller software are sent to the server for processing, and any errors or
successful actions will be displayed to the user.

3.2 Hardware Interfaces

The system will require standard PC hardware, including:

 Desktop or Laptop Computers: At least 256MB of RAM and 80GB of hard disk space.
 Input Devices: Keyboards, mice, and touchscreen devices as needed.
 Printers: For printing patient records, prescriptions, and billing invoices.
 Medical Equipment: Integration with medical devices such as EHR systems, diagnostic
tools, and laboratory devices.

3.3 Software Interfaces

 Visual Basic: For development and user interface components.

 SQL Database: To handle patient data, appointment records, billing, and inventory
management.

3.4 Communications Interfaces

The client and server will communicate using the TCP/IP protocol, a reliable connection-oriented
protocol ideal for hospital management systems. This will ensure ordered delivery of data packets,
which is crucial for accurate and secure patient information handling.

 Communication between client and server will take place over the internet using
TCP/IP, ensuring reliability in transmitting sensitive data such as patient records and
billing information.
 11

4. Other Functional Requirements

4.1 Server Requirements

 Performance: The server must be able to handle multiple user requests concurrently. It
should support simultaneous access by multiple hospital staff, patients, and external
systems without experiencing significant delays.

 Reliability: The server should be highly available with minimal downtime. It should
include failover mechanisms and automatic recovery in case of server failures to ensure
continuous operations.

 Scalability: The system must be scalable to accommodate growing patient data and user
base. As the hospital expands, the server should be able to handle increased data storage
and transaction volume without performance degradation.

 Backup and Recovery: The server must have a reliable backup and recovery system in
place to protect patient data, transaction history, and other critical information in the event
of system failure or data corruption.

4.2 Client Requirements

 Ease of Use: The client software (used by hospital staff) must have an intuitive interface,
even for users with limited technical expertise. It should facilitate easy navigation between
features such as patient records, appointments, and billing.

 Compatibility: The client software should be compatible with multiple operating systems
such as Windows, macOS, and Linux, and should be able to integrate seamlessly with
existing hardware and hospital systems.

 Security: The client application should implement strong user authentication and
authorization mechanisms to prevent unauthorized access to sensitive patient data.

4.3 Hospital Management System Requirements

 Data Integrity: The system must ensure the integrity and consistency of data. This
includes validation checks when entering patient data and transaction records to prevent
errors or inconsistencies.

 Data Security: The system should comply with healthcare data protection regulations
(e.g., HIPAA) to ensure the confidentiality, integrity, and availability of patient
information. All sensitive data should be encrypted both in transit and at rest.
 12

 Audit Trail: The system should maintain an audit trail of all activities performed within
the software, such as patient record updates, billing transactions, and user access events.
This is critical for compliance and tracking system usage.

 Interoperability: The system must be capable of integrating with other medical systems
(e.g., EHR, lab management software, insurance systems) to provide a comprehensive view
of patient information and streamline workflow.

4.4 Performance Requirements

 Response Time: The system must provide real-time or near real-time responses to user
interactions, including access to patient records, scheduling appointments, processing
transactions, and generating reports.

 Throughput: The system should handle a large number of simultaneous users and
requests, especially during peak hospital hours. It should support concurrent access by
medical staff, administrative personnel, and patients without noticeable slowdowns.

4.5 Design Constraints

 Budgetary Constraints: The system must be developed and deployed within the financial
constraints set by the hospital. This includes costs related to software development,
hardware, licensing, and maintenance.

 Time Constraints: The hospital management system should be implemented within a

specified timeline to ensure that the hospital can transition to the new system without
disrupting ongoing operations. Key milestones will need to be met to ensure timely
delivery.

4.6 Software System Attributes

4.6.1 Reliability

 The system shall save the data stored in the user data structures once every five minutes.
 The system shall save the data of an active user whenever that user has just completed a
funds transfer transaction.
 The system shall save the data of an active user whenever a new user is created.
 The system shall save the data of an active user whenever a new account is created.
 The system shall save the data of an active user whenever a user password is changed.
 The system shall not save on a check balance transaction.
 The system shall reboot itself automatically if there is a power failure and restore all saved
data to the user accounts.
 13

4.6.2 Availability

 The Passport system shall be available and running in a stable state at all times.

 The Pass Server shall be available and running in a stable state at all times.

 The Pass Officer Software shall be available at all times.

4.6.3 Security
 The system shall require a password to allow a user to log in.
 The system shall require the user to know their own password and account number to
authenticate their identity.
 The system shall use strong encryption for storing and transmitting sensitive data, such as
user passwords and financial information.
 The system shall implement role-based access control to ensure that only authorized users
can access specific features or perform certain actions.
 The system shall log all login attempts, including successful and failed attempts, along
with timestamps for auditing purposes.

4.6.4 Maintainability

 The system shall be designed with modularity, allowing for easy updates and maintenance.

 The source code shall be available to the developers and documented in a clear,
understandable format.

 The system shall include comprehensive logging to help diagnose and resolve any issues
quickly.

 The system shall allow for easy backup and restoration of data.

 The system shall include automated testing tools to verify the correctness of updates and
patches.

 The system shall include detailed error messages that help developers identify and
troubleshoot issues.
 14

4.6.5 Portability

 The system shall be designed to run on multiple operating systems including Windows,
macOS, and Linux.

 The system shall be platform-independent, allowing for minimal modification when

porting to different hardware or environments.

 The system shall be compatible with various screen sizes, including desktops, tablets, and
mobile devices.

 The system shall not rely on any proprietary hardware or software components that could
limit its portability.

 The system shall support cloud deployment, allowing for scalable infrastructure on cloud
platforms such as AWS, Google Cloud, or Azure.

5. Other Requirements

5.1 Risk Management

 Risk Identification: Risks should be identified based on potential impacts on the system’s
functionality, security, and user experience. These include data loss, unauthorized access,
system downtime, hardware failures, and software bugs.

 Risk Mitigation: The system should have mechanisms in place to mitigate these risks,
including regular backups, encryption, access controls, error-handling mechanisms, and a
reliable disaster recovery plan.

 Monitoring: Continuous monitoring of the system’s performance, security, and error logs
will help identify emerging risks early. Alerts and automated responses should be set up to
address certain risks before they escalate.

5.2 Gantt Chart

The Gantt chart is the standard format for displaying a schedule or project planning
graphically. It consists of a horizontal bar chart with time as the horizontal axis and either
resources, operations, or orders as the vertical axis. Individual operations are displayed as
horizontal bars in the chart, indicating the time at which the operation begins and ends. Many
variations on the Gantt chart exist to display additional kinds of information. Gantt charts can be
drawn physically on paper, but nowadays are usually implemented through computer software.
 15

Fig: Gantt Chart

RESULT:

Thus The Identifying A Software System That Needs To Be Developed Was Prepared
Successfully.
 16

Ex .No: 3 Identify Use Cases and develop the Use Case Model

AIM
To identify use cases and to develop the use case model using UML use case models.

DESCRIPTION
A Use Case is functionality provided by the system, typically described as verb + object
(e.g. Register Car, Delete User). Use Cases are depicted with an ellipse. The name of the use case
is written within the ellipse.

Use-case diagram is used to indicate the existence of use-cases, actors and their
relationships and the courses of actions that can be performed. It is used to illustrate the static use
case view of a system. Use-case diagram is a visual representation of what the customer wants the
system to do. It shows a sequence of actions a system performs that yields an observable result
and is of value to a particular actor.
Use-case:
A use-case is a relatively end-to-end process description that typically includes many steps
or transactions; it is not normally an individual step or activity in a process. Use-cases are
scenarios for understanding system requirements. Use-cases are described textually in a document
called a flow of events.
Actor:
An actor is a user playing a role with respect to the system. The actor is the key to finding
the correct use-cases. A single actor may perform many use-cases. An actor can be external
system that interacts with the system either by giving or receiving information or both.
Relationships:
There are 4 types of relationships. Communication, Uses, extends and generalization.

Elements of a Use Case Diagram

Actor Use Case

Relationship Extends
 17

Generalization

Usecase diagram for Hospital Management System

RESULT
Thus the Use Cases were identified and the Use Case model was developed
 18

Ex .No: 4 Identify the conceptual classes and develop a domain

model with UML Class diagram.

AIM
To identify the conceptual classes and to develop a domain model with UML class
diagram.

DESCRIPTION
The Class diagram captures the logical structure of the system - the classes and things that
make up the model. Class diagram shows the static view of the system and are modeled in the
Logical view under the appropriate use-case realization. It shows a set of classes, interfaces and
their relationships.
A Class diagram is made up of following basic elements
 Classes
 Relationships
 Associations
 Aggregations
 Generalizations
A Class is a set of objects that share the same attributes, operations, relationships, and
semantics. In the UML, a class is represented by a compartmentalized rectangle.
A relationship is a semantic connection among elements. A class diagram has above
mentioned three types of relationships.
An association is the most general relationship and indicates communication only. In the
UML, a solid line with or without an arrow represents an association.
An aggregate association is a type of association where a whole is related to its part(s). In
the UML, an aggregation is represented by a solid line with or without an arrow on one end and
hollow diamond at the end of the aggregate (Whole).
Associations in a class diagram can be further defined by
 Association Name
 Role Names
 Multiplicity
Association names
An association name is a label that clarifies the meaning of the association. This name is
placed along the middle of the association line. These names are usually verb phrases.
Role Names
A role name is a label that specifies the “face” the class plays in an association. This name
is placed along the association line nearest the class it modifies. These names are usually noun.
Multiplicity
Multiplicity is the number of instances a class relates to an instance of another class.
Multiplicity is defined at both ends of the association line.
 19

A generalization is a parent/child relationship where one class shares the structure and
behavior of one or more classes. In the UML, a solid line with a hollow arrow represents a
generalization relationship.

Class Notation: UML class is represented by the diagram shown below. The diagram is divided
into four parts.

 The top section is used to name the class.

 The second one is used to show the attributes of the class.
 The third section is used to describe the operations performed by the class.

The fourth section is optional to show any additional components

Classes are used to represent objects. Objects can be anything having properties and responsibility

Class Diagram for Hospital Management System

 20

RESULT
Thus the conceptual classes were identified and a domain model with UML class diagram
was developed.
 21

Ex .No: 5 Use case scenarios to find the interaction between objects

and represent them using UML Interaction diagrams
AIM
To find the interaction between objects and represent them using UML Interaction
diagrams.

DESCRIPTION
Introduction
An Interaction diagram models the dynamic aspects of the system by showing
relationships among objects and the messages they may dispatch. There are two types of
interaction diagrams
 Sequence diagram
 Collaboration diagram
Sequence Diagram
Sequence diagram is a structured representation of behavior as a series of sequential steps
over time. It is used to depict work flow, message passing and how elements in general cooperate
over time to achieve a result.
It shows the objects participating in the interaction by their “lifelines “and the messages
that they send to each other. A Sequence diagram made up of basic elements
 Actors
 Objects
 Messages
 Lifelines
 Activation Bar/Focus of Control
In a Sequence diagram, classes and actors are listed as columns, with vertical lifelines
indicating the lifetime of the object over time.
Actor
Represents an external person or entity that interacts with the system

Object

Represents an object in the system or one of its components

 22

Unit

Represents a subsystem, component, unit, or other logical entity in the system (may or may not be
implemented by objects)

Message

An asynchronous message between header elements

Block

A block representing a loop or conditional for a particular header element

Call Message

A call (procedure) message between header elements

Create Message

A "create" message that creates a header element (represented by lifeline going from dashed to
solid pattern)

Destroy Element

Represents the destruction of a header element

 23

Destroy Message

Represents the destruction of a header element as a result of a call from another element

Frame Operator Meaning

alt - Alternative fragment for mutual exclusion conditional logic expressed in the guards.
loop -Loop fragment while guard is true. Can also write loop(n) to indicate looping n times.
Opt- Optional fragment that executes if guard is true.
Par- Parallel fragments that execute in parallel.
Region- Critical region within which only one thread can run.
 24

Sequence Diagram for Hospital Management System:

Collaboration Diagram

A Collaboration diagram shows the interactions between elements at run-time in much the
same manner as a Sequence diagram. However, Collaboration diagrams are used to visualize
inter-object relationships, while Sequence diagrams are more effective at visualizing processing
over time.
A Collaboration diagram is made up of following basic elements.
 Actors
 Objects
 Links
 Messages
A link is the pathway of communication between objects on a collaboration diagram. In
the UML, a solid line between two objects represents an object link.
A message is the communication between two object that triggers an event. In the UML, a
labeled arrow above the link in a collaboration diagram represents an object message.
Steps to generate Collaboration Diagram
 25

Step1: Press F5 to auto generate the collaboration diagram and arrange the diagram elements.
Note
Since collaboration and sequence diagrams are semantically equivalent, we can automatically
generate one diagram from the other by pressing F5.
Collaboration Diagram For Hospital Management System:

RESULT
Thus the interactions between objects were identified and UML Interaction diagrams were
developed.
 26

Ex .No:6 a Draw the State Chart diagram and activity diagram

AIM
To study and draw the State chart Diagram and activity diagram.

DESCRIPTION

A State chart diagram is a view of a state machine that models the changing behavior of a
state. State chart diagrams show the various states that an object goes through, as well as the
events that cause a transition from one state to another.

State chart diagram model elements

The common model elements that State chart diagrams contain are
 States
 Start and end states
 Transitions
 Entry, do, and exit actions
State
A state represents a condition during the life of an object during which it satisfies some
condition or waits for some event.

Start and end states

Start and end states represent the beginning or ending of a process.

Start State End State

 27

Transitions

A state transition is a relationship between two states that indicates when an object can
move the focus of control on to another state once certain conditions are met. In a state chart
diagram, a transition to self element is similar to a state transition. However, it does not move
the focus of control. A state transition contains the same source and target state.

1.Transition to self

2.Transitions between the states

Actions in a State chart diagram

Each state on a state chart diagram can contain multiple internal actions. An action is best
described as a task that takes place within a state. There are four possible actions within a state

 On entry
 On exit
 Do
 On event

Steps to create the State Chart Diagram
A state chart diagram is usually placed under the Logical View package. Right-click on
the Logical View package and select New->State chart Diagram to create a State chart
Diagram. Name your diagram and then double-click on the name to open the diagram work
area.
An Activity diagram in the use-case model can be used to capture the activities in a use-
case. It is essentially a flowchart, showing flow of control from activity to activity. It represents
the dynamics of the system.
The workflow of a use-case describes that which needs to be done by the system to
provide the value the served actor is looking for. It consists of a sequence of activities that
together produce something for the actor. The workflow often consists of a basic flow and one or
several alternative flows.
Activity diagrams can also be used in business modeling and to model the workings of an
operation, an object, or anything that involves modeling the sequential steps in a computational
process.
 28

Elements of an Activity Diagram

State Activity

Start State Final state

State Transition Swim lane

Synchronization Bar

Flow/edge: The arrows on the diagram. Although there is a subtle difference between flows and
edges I have never seen a practical purpose for the difference although I have no doubt one
exists. I’ll use the term flow.

Fork: A black bar with one flow going into it and several leaving it. This denotes the beginning
of parallel activity.

Join: A black bar with several flows entering it and one leaving it. All flows going into the join
must reach it before processing may continue. This denotes the end of parallel processing.

Condition: Text such as [Incorrect Form] on a flow, defining a guard which

must evaluate to true in order to traverse the node.

Decision: A diamond with one flow entering and several leaving. The
flows leaving include conditions although some modelers will not
indicate the conditions if it is obvious.
 29

Merge. A diamond with several flows entering and one leaving. The implication is that one or
more incoming flows must reach this point until processing continues, based on any guards on the
outgoing flow.

Activity Diagram for Hospital Management System

 30

State Chart Diagram for Hospital Management System

RESULT:
Thus the State chart Diagram and activity Diagram was studied and drawn.
 31

Ex .No: 6 b Implement the Component and Deployment diagrams

AIM
To study and draw the Component and Deployment Diagrams.
DESCRIPTION

Component Diagram:
A Component is a code module. Component diagrams are physical analogs of class
diagram. A Component diagram illustrates the pieces of software, embedded controllers, etc. that
will make up a system. A Component diagram has a higher level of abstraction than a Class
diagram - usually a component is implemented by one or more classes (or objects) at runtime.
They are building blocks, such that eventually a component can encompass a large portion of a
system.
Component diagrams fall under the category of an implementation diagram, a kind of
diagram that models the implementation and deployment of the system. A Component Diagram,
in particular, is used to describe the dependencies between various software components such as
the dependency between executable files and source files. This information is similar to that
within make files, which describe source code dependencies and can be used to properly compile
an application.

Elements of Component Diagram

Component
A component represents a software entity in a system. Examples include source code files,
programs, documents, and resource files. A component is represented using a rectangular box,
with two rectangles protruding from the left side, as seen in the image to the right.

Dependency
A Dependency is used to model the relationship between two components. The notation
for a dependency relationship is a dotted arrow, pointing from a component to the component it
depends on.
 32

Component Diagram

Deployment Diagram

Deployment diagrams show the physical configurations of software and hardware. A

Deployment diagram shows how and where the system will be deployed. Physical machines and
processors are reflected as nodes, and the internal construction can be depicted by embedding
nodes or artifacts. As artifacts are allocated to nodes to model the system's deployment, the
allocation is guided by the use of deployment specifications.
Deployment diagram
 33

RESULT:
Thus the component and deployment diagrams are studied and drawn successfully.
 34

Ex .No: 7 Implement the system as per the detailed design

AIM:
To implement the User Interface Layer for Hospital Management System.

Login Page:
 35

Patient Module:
 36

Doctor Module:
 37

Rooms Module:
 38

Service Module:
 39

PROBLEM DESCRIPTION

Managing a hospital’s day-to-day activities manually is time-consuming, prone to errors, and

inefficient. Hospitals deal with massive amounts of sensitive patient information, doctor
schedules, billing, inventory, and administrative tasks. The lack of a centralized, digital system
often leads to data loss, operational delays, miscommunication, and patient dissatisfaction.

The Hospital Management System (HMS) is proposed as an integrated software solution to

automate and streamline hospital operations. It will allow secure storage and retrieval of patient
records, manage appointments and doctor schedules, handle billing and payments, maintain
inventory (like medicines and equipment), and support administrative functions.

This system will ensure quick access to information, improve service quality, enhance operational
efficiency, ensure data security and compliance with healthcare standards, and provide a better
overall experience for both patients and hospital staff.

Coding:
SQL :
1.Create a database
create database hospital;
2. Select the database
use hospital;
3. Create an admin table
create table admin (
login_id varchar(25),
password varchar(25)
);
4. Create a Patients table
create table patients (
patient_id int primary key,
patient_name varchar(25),
fathers_name varchar(15),
address varchar(250),
contact_no varchar(10),
 40

age int
);
5. Create a doctor’s table
create table doctors (
doctor_id int primary key,
doctor_name varchar(25),
father_name varchar(25),
contact_no varchar(10),
address varchar(250)
date_joining date
);
6. Create a room table
create table room (
room_no int,
room_charges int
);
6. Insert some values in the admin table
insert into admin values
("admin","1234")

HTML:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Hospital Management System</title>
<style>
/* === Global Styles === */
body {
font-family: 'Segoe UI', sans-serif;
background-color: #e6f3ff;
margin: 0;
padding: 30px;
 41

}
h2 {
background-color: #008cba;
color: white;
padding: 10px;
border-radius: 6px;
text-align: center;
margin-bottom: 18px;
}
label {
font-weight: 600;
margin-bottom: 4px;
display: block;
font-size: 14px;
color: #2c3e50;
}
input, select, textarea {
width: 100%;
padding: 8px 10px;
margin-top: 4px;
border: 1px solid #cdd9e5;
border-radius: 5px;
font-size: 14px;
}
section {
background-color: #fff;
padding: 20px;
margin-bottom: 40px;
border-radius: 10px;
box-shadow: 0 4px 12px rgba(0, 0, 0, 0.1);
}
.form-row {
margin-bottom: 14px;
 42

}
.double {
display: flex;
gap: 10px;
}
.half {
flex: 1;
}
.button-row {
display: flex;
gap: 10px;
flex-wrap: wrap;
justify-content: center;
margin-top: 15px;
}
button {
background-color: #008cba;
color: white;
border: none;
padding: 10px 18px;
border-radius: 6px;
font-weight: bold;
cursor: pointer;
transition: background-color 0.3s;
}
button:hover:not(:disabled) {
background-color: #0075a9;
}
button:disabled {
background-color: #c3cdd5;
cursor: not-allowed;
}
table {
 43

width: 100%;
border-collapse: collapse;
margin-top: 15px;
background-color: white;
}
th, td {
border: 1px solid #b3c7e6;
padding: 8px;
text-align: left;
}
th {
background-color: #e3eaf4;
}
</style>
</head>
<body>

<!-- Room Details -->

<section id="room">
<h2>Room Info</h2>
<form>
<div class="form-row">
<label>Room No.</label>
<input type="text">
</div>
<div class="form-row">
<label>Room Type</label>
<select>
<option>General</option>
<option>Private</option>
<option>ICU</option>
</select>
</div>
 44

<div class="form-row">
<label>Room Charges (Per Day)</label>
<input type="text">
</div>
<div class="button-row">
<button type="button">New</button>
<button type="button">Save</button>
<button type="button">Get Data</button>
</div>
</form>
<table>
<thead>
<tr>
<th>Room No.</th>
<th>Room Type</th>
<th>Room Charges</th>
<th>Room Status</th>
</tr>
</thead>
<tbody>
<!-- Sample row -->
<tr>
<td>101</td>
<td>ICU</td>
<td>₹5000</td>
<td>Available</td>
</tr>
</tbody>
</table>
</section>

<!-- Doctor Details -->

<section id="doctor">
 45

<h2>Doctor Details</h2>
<form>
<div class="form-row"><label>Doctor ID</label><input type="text"></div>
<div class="form-row"><label>Full Name</label><input type="text"></div>
<div class="form-row"><label>Email ID</label><input type="email"></div>
<div class="form-row"><label>Contact No.</label><input type="text"></div>
<div class="form-row"><label>Address</label><input type="text"></div>
<div class="form-row"><label>Qualifications</label><input type="text"></div>
<div class="double">
<div class="half">
<label>Gender</label>
<select>
<option>M</option><option>F</option><option>Other</option>
</select>
</div>
<div class="half">
<label>Blood Group</label>
<select>
<option>O+</option><option>A+</option><option>B+</option>
<option>AB+</option><option>O-</option><option>A-</option>
<option>B-</option><option>AB-</option>
</select>
</div>
</div>
<div class="form-row">
<label>Date of Joining</label>
<input type="date">
</div>
</form>
</section>

<!-- Patient Details -->

<section id="patient">
 46

<h2>Patient Details</h2>
<form>
<div class="form-row"><label>Patient ID</label><input type="text"></div>
<div class="form-row"><label>Name</label><input type="text"></div>
<div class="form-row"><label>Father's Name</label><input type="text"></div>
<div class="form-row"><label>Address</label><input type="text"></div>
<div class="form-row"><label>Contact No.</label><input type="text"></div>
<div class="form-row"><label>Email ID</label><input type="email"></div>
<div class="form-row"><label>Age</label><input type="number"></div>
<div class="double">
<div class="half">
<label>Gender</label>
<select><option>M</option><option>F</option><option>Other</option></select>
</div>
<div class="half">
<label>Blood Group</label>
<select>
<option>O+</option><option>A+</option><option>B+</option>
<option>AB+</option><option>O-</option><option>A-</option>
<option>B-</option><option>AB-</option>
</select>
</div>
</div>
<div class="form-row"><label>Information</label><textarea rows="4"></textarea></div>
<div class="button-row">
<button type="submit">Save</button>
<button type="reset">New</button>
<button disabled>Update</button>
<button disabled>Delete</button>
<button type="button" onclick="alert('Fetching patient data...')">Get Data</button>
</div>
</form>
</section>
 47

<!-- User Login -->

<section id="user">
<h2>User Login</h2>
<form>
<div class="form-row"><label>Name</label><input type="text" placeholder="Enter Name"
/></div>
<div class="form-row"><label>Username</label><input type="text" placeholder="Enter
Username" /></div>
<div class="form-row"><label>Password</label><input type="password" placeholder="Enter
Password" /></div>
<div class="form-row double">
<div class="half"><label>Email</label><input type="email" placeholder="Enter Email"
/></div>
<div class="half"><label>Contact No.</label><input type="text" placeholder="Enter
Contact No." /></div>
</div>
<div class="button-row">
<button type="submit">Login</button>
</div>
</form>
</section>

</body>
</html>

RESULT:
Thus the Hospital Management system was successfully implemented.
 48

Ex. No: 8 Test the software system for all the scenarios identified as
per the usecase diagram

Software Testing Tool: Selenium

Selenium is a widely used open-source framework for automating web applications. It enables
testers to simulate real user interactions with web browsers, helping ensure the system functions
correctly. In a Hospital Management System, Selenium is ideal for functional testing,
regression testing, and cross-browser testing. It supports languages such as Java, Python, C#,
and JavaScript, and works with major browsers like Chrome, Firefox, Edge, and Internet
Explorer.

Selenium helps verify that all modules of the hospital system—such as patient registration,
appointment booking, doctor login, diagnosis entry, billing, and discharge processes—work as
intended. These automated tests simulate end-to-end real-world user flows.

How Selenium Works:

a.Selenium WebDriver
Interacts with browsers by simulating user actions like filling forms, clicking buttons, and
navigating between pages.

b.Selenium IDE(Integrated Development Environment)

A browser plugin for recording and playing back test scenarios without writing complex code—
great for quick validations.

c.Selenium Grid
Allows parallel execution of tests on multiple browsers and machines, improving testing
efficiency across environments.

Testing the Hospital Management System with Selenium (Use Case Based)

a. Patient Registration Test

Test Scenario: Ensure that a new patient can register successfully.

Test Steps:

 Open the registration page.

 Enter valid details (name, age, contact, address, etc.).
 49

 Click the submit button.

 Verify that a success message or confirmation is shown.

b. Login Test

Test Scenario: Ensure that doctors, nurses, and admin staff can log in with valid credentials.

Test Steps:

 Open the login page.

 Enter valid username and password.
 Click the login button.
 Verify redirection to the appropriate dashboard (based on role).

c. Appointment Booking Test

Test Scenario: Verify that patients can book an appointment with a doctor.

Test Steps:

 Log in as a patient.
 Navigate to the "Book Appointment" page.
 Select a doctor, date, and time.
 Submit the booking form.
 Confirm that a success message or appointment ID is displayed.

d. Medical Record Entry Test

Test Scenario: Ensure that doctors can add diagnosis and prescription data.

Test Steps:

 Log in as a doctor.
 Navigate to a patient’s profile or visit list.
 Enter diagnosis details and prescriptions.
 Submit the form.
 Verify that the information is saved and visible.
 50

e. Bill Generation Test

Test Scenario: Ensure that billing staff can generate bills after treatment.

Test Steps:

 Log in as billing staff.

 Navigate to the billing section.
 Enter patient services, costs, and any discounts.
 Generate the bill.
 Verify that the final amount and details are correctly shown.

f. Patient Discharge Test

Test Scenario: Verify that a patient can be discharged after treatment completion.

Test Steps:

 Log in as an admin or doctor.

 Open the patient’s treatment record.
 Click on “Discharge” and confirm.
 Ensure that the discharge summary is generated and saved.

g. Lab Report Upload Test

Test Scenario: Ensure lab technicians can upload reports to a patient’s profile.

Test Steps:

 Log in as a lab technician.

 Navigate to a patient’s record.
 Upload lab results or reports.
 Verify that the upload is successful and visible to doctors/patients.

h. Role-Based Access Test

Test Scenario: Ensure that different users can only access modules relevant to their role.

Test Steps:

 Log in with various roles (patient, doctor, admin).

 Attempt to access restricted pages
 51

SCREENSHOTS:
 52

RESULT:
Thus, Testing the software system for all the scenarios identified as per the usecase
diagram was executed successfully.
 53

Ex. No: 9 Improve the reusability and maintainability of the software

system by applying appropriate design patterns

Design patterns are standardized solutions to common software design problems. By applying the
right design patterns, the Hospital Management System can be made more modular, extensible,
and easier to maintain, especially as features grow over time.

a. Singleton Pattern – (For Shared Resources)

Purpose: Ensure only one instance of a class exists and provide a global access point.

Use Case in HMS:

 Database Connection Manager: A Singleton ensures that the system uses a single
database connection pool throughout, avoiding unnecessary reconnections and improving
performance.
 Logger/Activity Tracker: Useful for centralized logging of patient activities, doctor
actions, or admin operations.

b. Factory Pattern – (For Object Creation Based on Role or Type)

Purpose: Create objects without exposing the instantiation logic to the client.

Use Case in HMS:

 User Creation Factory: Depending on the user type (e.g., Patient, Doctor, Nurse,
Admin), the Factory can instantiate the appropriate class with specific properties and
access levels.
 Appointment Object Factory: Create different types of appointments—e.g., online, in-
person, or emergency—based on patient input.

c. Strategy Pattern – (For Dynamic Behavior Switching)

Purpose: Allow switching between algorithms or behaviors at runtime.

Use Case in HMS:

 Billing Strategy: Different billing methods (insurance-based, self-pay, corporate) can be

encapsulated in separate strategies and swapped based on patient type.
 54

 Diagnosis/Treatment Plan Generator: Select and apply different treatment strategies

depending on disease type or severity.

d. Observer Pattern – (For Real-Time Updates and Notifications)

Purpose: Notify dependent objects automatically when the subject’s state changes.

Use Case in HMS:

 Appointment Status Notifications: Notify patients and doctors when appointment

statuses change (e.g., scheduled, canceled, completed).
 Stock Alert System: Notify pharmacy and admin when medicine or supplies fall below
minimum threshold levels.

e. Command Pattern – (For Encapsulating User Actions)

Purpose: Encapsulate actions as objects to allow undo, redo, or queuing.

Use Case in HMS:

 Admin Approvals: Approve, reject, or defer new doctor registrations or staff changes
through encapsulated command objects.
 Patient Discharge Process: Commands can queue operations like final billing, summary
report generation, and feedback collection.

f. Decorator Pattern – (For Extending Functionality at Runtime)

Purpose: Add new responsibilities to an object dynamically without altering its structure.

Use Case in HMS:

 Medical Record Enhancements: Dynamically add extra fields such as additional test
results, second opinions, or follow-up instructions.
 Patient Profile Customization: Add modules like dietary preferences, allergy notes, or
vaccination history to a basic patient profile.

RESULT:
Thus, Improve the reusability and maintainability of the software system by applying
appropriate design patterns diagram was executed successfully.
 55

Ex. No: 10 Implement the modified system and test it for various
scenarios.

a. Reusability

Reusability means code components (classes, functions, modules) can be reused across different
parts of the system—or even in other systems—without rewriting logic.

Design Patterns That Improve Reusability:

Pattern Use Case in HMS How it Improves Reusability

Factory Creating different user types (e.g., Centralizes and standardizes object creation
Pattern Doctor, Nurse, Patient, Admin) across modules
Strategy Applying different billing strategies Allows dynamic behavior change without
Pattern (insurance, self-pay, corporate) altering calling code
Template Standard patient workflow (admit → Shares a common structure while allowing
Method diagnose → treat → discharge) customization for each department
Adapter Integrating third-party lab or Adapts existing classes to work with new
Pattern pharmacy systems interfaces without changing original code

b. Maintainability

Maintainability is how easily the system can be updated, debugged, or enhanced—essential in

systems expected to evolve with medical and administrative needs.

Design Patterns That Improve Maintainability:

Pattern Use Case in HMS How it Improves Maintainability

Observer Notify doctors/patients when lab Decouples the event trigger from how
Pattern results or appointment status changes notifications are handled
Singleton Ensures a single, controlled access point for
Central database or logging access
Pattern shared system resources
Facade Simplifying patient admission which Hides complex subsystems (billing, records,
Pattern involves several backend operations room allocation) behind a simplified interface
 56

Pattern Use Case in HMS How it Improves Maintainability

MVC Separates data (Model), UI (View), and logic
Patient or Admin dashboard UI
Pattern (Controller) for easier debugging and updates

Example: Without vs. With Design Patterns in Hospital Management System

Without Design Patterns:

 One massive class handling patient registration, diagnosis, billing, discharge, and
notifications.
 Every new department or change requires editing the core logic.
 Hard to debug, scale, or reuse.

With Design Patterns:

 Factory Pattern: Generates user roles (e.g., Patient, Nurse, Doctor) with specific
permissions.
 Strategy Pattern: Switches between billing types (insurance vs. cash) dynamically.
 Observer Pattern: Automatically sends emails/SMS when test results are updated.
 Facade Pattern: Simplifies complex hospital workflows (admit, test, treat, discharge) into
a single method call.

Benefits of Using Design Patterns in HMS

Benefit Explanation
Each component handles one specific responsibility, making it easier to
Modular Code
manage.
Code Reuse Common logic (e.g., user creation, notification) is centralized and reusable.
Easy Maintenance Isolated modules mean bugs and updates are localized and faster to resolve.
Scalability New departments or features can be added without affecting the core system.

RESULT:
Thus, Implementation for the modified system and test it for various scenarios was
executed successfully.