Hospital System Management-2
Hospital System Management-2
Submitted by
BHAVANA.SR RA2311030020088
POOJYA SREE.V RA2311030020116
SHRUTI.K RA2311030020126
Ms. K. Srinarayani
(Assistant Professor, Department of Computer
Science and Engineering)
II SEMESTER/I YEAR
1
SRM INSTITUTE OF SCIENCE AND TECHNOLOGY
(Deemed to be University U/S 3 of UGC Act, 1956)
BONAFIDE CERTIFICATE
SIGNATURE:
2
SRM INSTITUTE OF SCIENCE AND
TECHNOLOGY
RAMAPURAM, CHENNAI
DECLARATION
We hereby declare that the entire work contained in this project report titled
“HOSPITAL MANAGEMENT SYSTEM” has been carried out by SR.
Bhavana (RA2311030020088), V. Poojya Sree (RA2310030020116), Shruti
Karthikeyan (RA2311030020126) at SRM Institute of Science and
Technology, Ramapuram, Chennai, under the guidance of Ms. K.
SRINARAYANI, Assistant professor, Department of Computer Science and
Engineering.
3
INDEX
1. Abstract 1
2. Introduction 2
3. Problem Statement 3
4. Objective 4
5. Scope of Project 5
6. Existing System 6
7. Proposed System 6
8. Models Description 6
4
LIST OF FIGURES
5
ABSTRACT
1
I. INTRODUCTION
2
II. PROBLEM STATEMENT
3
III. OBJECTIVE
4
IV. SCOPE OF THE PROJECT
The scope of this project encompasses various aspects of hospital and patient
data management. It includes the development of modules for hospital
registration, patient registration, data display, and bed management.
Additionally, the project involves implementing features for administrators to
oversee and manage the system effectively. While the initial focus may be on a
limited number of hospitals and patients, the scalability of the software allows
for future expansion to accommodate a larger network of healthcare facilities
and users. The project's scope extends beyond mere digitization to actively
improving processes and enhancing the overall quality of healthcare delivery.
5
V. EXISTING SYSTEM
In the existing system, hospital and patient data management often relies on
manual processes, paper-based records, and fragmented information systems.
Hospitals maintain records using spreadsheets, paper files, or legacy software
systems, leading to data duplication, inaccuracies, and delays in accessing
information. Patient admissions and bed management may be done manually,
making it challenging to track bed availability in real-time and optimize
resource allocation efficiently. Overall, the existing system lacks integration,
real-time updates, and user-friendly interfaces, resulting in inefficiencies and
suboptimal patient care.
The proposed system introduces automation and integration into hospital and
patient data management. It offers a centralized platform where hospitals can
input and update their information seamlessly. Patients can register online,
choose their preferred hospitals, and access real-time information on bed
availability.
6
VIII. UML DIAGRAMS
CLASS DIAGRAM
Fig: -1.1
NOTATIONS: -
➢ Classes: Rectangular boxes represent classes. The class name is shown at
the top of the box.
➢ Attributes: Attributes are listed below the class name and prefixed with
a visibility modifier (+ for public, - for private, # for protected).
➢ Operations: Operations (or methods) are listed below the attributes and
prefixed with a visibility modifier. They can also include parameters and
a return type.
➢ Relationships: Lines are used to show relationships between classes.
7
USE CASE DIAGRAM
Fig: -1.2
NOTATIONS: -
➢ Actors: Actors are represented by stick figures or small human icons.
They represent users of the system ,external systems that interact with it.
➢ Relationships: Lines are used to show relationships between actors and
use cases. There are three main types of relationships:
o Association: A solid line indicates a basic interaction between an
actor and a use case.
o Include: A dashed line with the label "include" indicates that one
use case includes the functionality of another use case.
o Extend: A dashed line with the label "extend" indicates that one
use case extends the functionality of another use case under
specific conditions
8
SEQUENCE DIAGRAM
Fig: -2.1
9
10
COLLABORATION DIAGRAM
Fig: -2.2
NOTATIONS: -
Classes:
➢ Patient Management: This class manages patients and has methods like
add Patient (), update Patient (), and delete Patient ().
➢ Billing System: Calculates payments and processes them.
➢ Medical Record: Represents patient medical records.
➢ Payment: Deals with payment-related information.
Entities:
➢ Patient: Has attributes like name and record.
➢ Doctor: Attributes include name and specialization.
➢ Service: Attributes are description and cost.
Associations:
➢ Relationships between classes/entities are represented by lines connecting
them:
➢ Patient Management manages Patient.
➢ Billing System processes payments.
➢ Patient has a Medical Record.
11
STATE CHART DIAGRAM
Fig: -3.1
NOTATIONS: -
Rectangles (representing processes or actions):
➢ “Create Issue”
➢ “Do the Work”
➢ “Code Review”
➢ “Test Issue”
Diamonds (decision points):
➢ “Issue Approved?”
➢ “Work Approved?”
➢ “Issue Completed?”
Oval shapes:
➢ “New Issue” (start of the process)
➢ “Close Issue” (conclusion of the process)
12
ACTIVITY DIAGRAM
Fig: -3.2
NOTATIONS: -
➢ Activities: Activities are represented by rectangles within the swim
lanes. They represent specific actions or tasks performed by the role
associated with the swim lane.
➢ Flow Arrows: Solid lines with arrowheads connect activities, showing
the sequential order of the workflow.
➢ Decisions: Diamonds represent decision points in the workflow. One or
more outgoing arrows branch from a decision diamond
13
PACKAGE DIAGRAM
Fig: -4.1
NOTATIONS:
➢ Package: Represented by a rectangle with a smaller tabbed folder icon at
the top. It is labeled with the name of the package.
➢ Dependency: Depicted with a dashed line and an open arrowhead
pointing towards the depended-upon package.
➢ Import: Shown with a dashed line and an open arrowhead, often
annotated with the «import» stereotype.
➢ Merge: Illustrated by a dashed line ending in a filled diamond at the
source package, with the «merge» stereotype.
➢ Public Elements: Denoted by a ‘+’ sign before the element’s name
(optional in package diagrams).
14
DEPLOYMENT DIAGRAM
Fig: -4.2
NOTATIONS:
➢ Node: Represented by a 3D box-like shape, labeled with the node's name.
Nodes symbolize physical entities such as servers, computers, or devices
where software components are deployed.
➢ Artifact: Shown as a rectangle with a document-like. Artifacts represent
tangible elements like software components, binaries, libraries, or
configuration files that are deployed on nodes.
➢ Association: A solid line between nodes indicating a physical connection
or network path through which the nodes can communicate.
➢ Dependency: Depicted with a dashed line and an arrow indicating a
directional relationship where one node or artifact relies on another.
➢ Deployment: Illustrated by a solid line with a closed arrowhead pointing
from an artifact to a node. This shows that an artifact is deployed on a
specific node.
➢ Communication Path: Represented by a dashed line, possibly with
labels to describe protocols or technologies used (e.g., HTTP, TCP/IP),
indicating the path along which nodes communicate.
15
COMPONENT DIAGRAM
Fig: -4.3
NOTATIONS:
➢ Component: Represented by a rectangle with two smaller rectangles
protruding from its left side, symbolizing the component's interface.
Components are modular parts of a system.
➢ Interface: Shown as a small circle or a half-circle attached to the
component. This represents a defined point of interaction through which
the component provides or consumes services (e.g., APIs).
➢ Aggregation: Represented by a solid line with an empty diamond at the
end that points to the whole, symbolizing a "whole-part" relationship
where components are made up of smaller components.
➢ Composition: This stronger form of the relationship suggests that the
lifetime of the contained components is bound to the lifetime of the
container component.
➢ Port: Shown as a small square on the boundary of the component. Ports
define the interaction points allowing the component to communicate
with its environment or other components.
16
IX. IMPLEMENTATION & CODING
Source Code: -
#include <iostream>
#include <vector>
#include <string>
using namespace std;
class Person {
protected:
string name;
int age;
char gender;
public:
Person(string _name, int _age, char _gender) : name(_name), age(_age),
gender(_gender) {}
virtual ~Person() {}
};
17
vector<string> patients;
public:
Doctor(string _name, int _age, char _gender, string _specialization)
: Person(_name, _age, _gender), specialization(_specialization) {}
class Appointment {
private:
string doctorName;
string patientName;
string date;
string time;
public:
18
Appointment(string _doctorName, string _patientName, string _date, string
_time)
: doctorName(_doctorName), patientName(_patientName), date(_date),
time(_time) {}
class Hospital {
public: // Making member variables public for simplicity in this example
string name;
vector<Doctor> doctors;
vector<Patient> patients;
vector<Appointment> appointments;
19
Hospital(string _name) : name(_name) {} // Constructor for Hospital
};
int main() {
Hospital hospital("General Hospital");
20
Doctor doctor2("Dr. Johnson", 35, 'F', "Pediatrics");
hospital.doctors.push_back(doctor1);
hospital.doctors.push_back(doctor2);
21
vector<Patient> patients = {
{"Patient X", 101, "Hospital A"},
{"Patient Y", 102, "Hospital B"}
// Add more patients...
};
return 0;
}
22
X. SCREENSHOTS OF OUTPUTS
23
XI. CONCLUSION
administrators alike. With its scalability and adaptability, the system has the
reducing costs, and improving patient care quality. The proposed system will
automate critical processes, ensuring that they are error-free, faster, and more
the successful implementation of this HMS will lead not only to enhanced
healthcare outcomes.
24