CHAPTER 2:

ASSESSMENT OF ON JOB TRAINING - 1

1
2
 ASSESSMENT OF ON JOB TRAINING – 1

1.1 Introduction:
The Hospital Management System is a web-based platform designed to streamline
patient appointments, doctor management, and hospital administration. This system
ensures efficient handling of patient records, appointment scheduling, and doctor
assignments.
The project is built using the MERN stack (MongoDB, Express.js, React.js,
Node.js) and consists of three main components:
 Frontend (http://localhost:5173/): Patient-facing interface.
 Dashboard (http://localhost:5174/): Admin interface.
 Backend (http://localhost:4000/): Manages database and authentication.
This project enhances healthcare services by enabling quick patient management,
reducing paperwork, and ensuring data security. The system can be further extended
to support telemedicine, remote patient monitoring, and AI-based diagnostics.
Additionally, it provides real-time appointment tracking, ensuring a seamless
experience for patients and healthcare professionals. The integration of secure
authentication mechanisms ensures that patient records remain confidential and
accessible only to authorized personnel. The system also improves operational
efficiency by automating repetitive tasks, allowing hospital staff to focus on critical
patient care. Furthermore, data analytics tools integrated into the system provide
hospital administrators with actionable insights to enhance overall service delivery.
Future developments may include AI-driven patient assistance, enhancing the user
experience through automated recommendations and diagnostics.

1.2 Objectives:
 To provide a digital solution for hospital management.
 To automate appointment scheduling.
 To improve patient record management.
 To enable secure authentication for patients, doctors, and admins.
 To reduce manual errors and improve data accuracy.
 To integrate advanced reporting and analytics for better decision-making.
 To enhance patient experience with an easy-to-use interface.
 To ensure scalability for future integration with emerging technologies.

3
4
1.3 TOOLS/PLATFORM, HARDWARE AND SOFTWARE
SPECIFICATION

1.3.1 HARDWARE REQUIREMENTS:

 Processor: Intel i3 or higher
 RAM: 8 GB
 Hard Disk: 500 GB
 Monitor: VGA Color
 Reliable internet connection for real-time data synchronization
 Secure hosting environment for deployment
 Scalable cloud-based servers for handling high patient loads

1.3.2 Software Requirements:

 Operating System: Windows 10 or higher
 Frontend: React.js, Material UI
 Backend: Node.js, Express.js
 Database: MongoDB Atlas
 Authentication: JWT
 Hosting: Localhost during development
 API Testing: Postman for backend request validation
 Version Control: GitHub for collaborative development
 Deployment: AWS, Firebase, or DigitalOcean
 Security Tools: SSL encryption, OAuth 2.0 authentication

5
6
1.4 SYSTEM ANALYSIS :

1.4.1 ADVANTAGES:
 Enhances hospital management efficiency by automating processes.

 Reduces paperwork and manual data entry, minimizing errors.

 Provides secure access to patient records with authentication.

 Streamlines appointment scheduling and doctor allocation.

 Offers a user-friendly interface for both patients and administrators.

 Supports real-time updates and notifications for better

communication.

 Allows scalability for future integrations with advanced medical

technologies.

 Improves decision-making with data analytics and reporting.

 Facilitates remote access for telemedicine and online consultations.
 Ensures compliance with healthcare regulations and standards.

1.4.2 Disadvantages:
 Requires a stable internet connection for optimal functionality.
 Initial implementation and maintenance costs may be high.
 Security risks if proper authentication and encryption are not maintained.
 Users may require training to fully understand and use the system efficiently.
 Potential downtime due to server issues or database failures.
 Integration with legacy hospital systems may be complex.
 Data migration from old records to the new system can be time-consuming.
 Data migration from old systems may be time-consuming and expensive.
 Resistance to change from hospital staff accustomed to manual systems.
 Ongoing software updates and technical support are necessary for smooth
operation.

7
8
1.5 SOFTWARE USED IN THE PROJECT
Software is a set of instructions, data, or programs used to operate computers and
execute specific tasks. It is the opposite of hardware, which describes the physical
aspects of a computer. Software is a generic term used to refer to applications, scripts,
and programs that run on a device. It can be thought of as the variable part of a
computer, while hardware is the invariable part.
Some of the main software used in this project are:
 React.js
 Node.js
 Express.js
 MongoDB Atlas
 Material UI

1.5.1 LANGUAGES USED:

 HTML: The HyperText Markup Language (HTML) is the standard language for
creating web pages. It structures content using elements like headings, paragraphs,
images, and links. It works alongside CSS and JavaScript to build fully functional
web applications.

 CSS: Cascading Style Sheets (CSS) is a stylesheet language used for describing the
presentation of web pages. It enables the separation of content and design, improving
accessibility, flexibility, and consistency in styling. CSS reduces complexity and
repetition by allowing multiple web pages to share formatting from a single file.

 JavaScript: JavaScript is a core technology of the web, enabling interactive behavior

on websites. Over 97% of websites use JavaScript for client-side scripting. It is a
multi-paradigm language that supports event-driven, functional, and imperative
programming styles. JavaScript APIs allow working with text, dates, and the
Document Object Model (DOM).

9
10
1.5.2 MERN Stack Architecture:
The MERN stack is a JavaScript-based full-stack development
framework consisting of MongoDB, Express.js, React.js, and
Node.js. It enables developers to build robust web applications with a
three-tier architecture: frontend, backend, and database.

 React.js (Frontend): The top tier of the MERN stack, React.js, is a

declarative JavaScript framework for building dynamic user
interfaces. It allows the creation of reusable components, enabling
efficient UI development. React uses a virtual DOM, optimizing
rendering performance.

 Express.js and Node.js (Backend): Express.js is a lightweight

Node.js framework designed for handling server-side logic. It
provides robust routing, middleware support, and API request
handling. Node.js, running on the V8 JavaScript engine, powers the
backend with an event-driven architecture for high-performance
applications.

 MongoDB Atlas (Database): A NoSQL database that stores

application data in a flexible JSON-like format. MongoDB allows
seamless integration with Node.js applications and supports real-
time data processing.

1.5.3 LIBRARIES USED:

 Material UI: Material UI is an open-source React component library
that implements Google’s Material Design principles. It provides
prebuilt UI components, ensuring consistent and responsive designs.
Material UI allows easy customization, making it suitable for
production-ready applications.

 Axios: Axios is a promise-based HTTP client for making API requests

from the frontend to the backend. It simplifies handling GET, POST,
PUT, and DELETE requests.

 JWT (JSON Web Token): Used for authentication, ensuring secure

user login and authorization across the application.

 Mongoose: An Object Data Modeling (ODM) library for MongoDB,

providing schema validation and database interaction.

11
12
1.6 STRUCTURE OF THE PROJECT
The Hospital Management System is organized into multiple modules,
each serving a specific purpose within the system. These modules are
designed to improve functionality, promote code reusability, and facilitate
easier maintenance. Below is an overview of the key modules:

1.6.1 MODULES
1.6.1.1 USER MODULE:
 Register: A simple registration process for users to create accounts.

(Fig 1: User Register)

 Login: Secure login for registered users to access the system.

(Fig 2: User Login)

13
14
 Book Appointment: Users can book appointments by selecting a doctor, department,
and available time slots.

(Fig 3: Appointment Booking)

15
16
 CHAPTER -3
DISCUSSION ON JOB TRAINING CASE-2

17
18
 CASE-2: IMPLEMENTATION
3.1 INTERNS ROLES AND RESPONSIBILITY :
As an intern in Hospital Management System Development, my primary responsibility was to
assist in designing and implementing the system while understanding the development
processes effectively. The key tasks included:
 Front-end Development: Implemented the UI using React.js and Material UI for a
seamless user experience.
 Back-end Development: Integrated Node.js and Express.js to handle server-side logic
and database connections.
 Database Management: Utilized MongoDB Atlas to store and retrieve patient, doctor,
and appointment data.
 Authentication & Security: Implemented JWT-based authentication for secure login
and access control.
 API Integration: Developed REST APIs for communication between the front-end and
back-end.
 Debugging & Optimization: Identified and resolved system issues, improving overall
performance.
 Documentation: Maintained records of project progress, including system workflow
and module descriptions.

3.2 DATA FLOW DIAGRAM:

A Data Flow Diagram (DFD) visually represents how data moves through the system. It
illustrates interactions between different components, data flow paths, and storage elements.
DFDs are widely used in system modeling to provide a clear understanding of the data
processes.
Key Points about DFD:
1. Graphical Representation – DFD is a diagrammatic representation that shows how
data flows through a system.
2. Depicts System Components – It illustrates processes, data sources, data stores, and
external entities.
3. Uses Simple Symbols – DFD uses circles (processes), arrows (data flows), rectangles
(external entities), and open-ended rectangles (data stores).

19
20
 3.2.1 DFD Symbols :

Name Notation Description

Represents system functions transforming

Process Circle
input into output.

Stores data within the system (e.g., Patient

Datastore Rectangle
Records).

Data Flow Arrow Shows the direction of data movement.

External Represents external users (e.g., Patients,

Square
Entity Doctors, Admins).

3.3 DATABASE:
A database is an organized collection of structured data, allowing efficient storage, retrieval,
and manipulation. In this project, MongoDB was used as the backend database due to its
flexibility, scalability, and seamless integration with JavaScript-based applications.
 MongoDB is a NoSQL Database – Unlike traditional relational databases,
MongoDB uses a document-based model for storing data.
 Stores Data in JSON-like Format – The data is stored as BSON (Binary JSON),
which is lightweight and efficient for web applications.
 Schema-less Structure – MongoDB does not enforce a fixed schema, making it
highly flexible for evolving project requirements.
 Collections and Documents – Data is stored in collections (similar to tables in SQL),
and each collection contains multiple documents (similar to rows).
 Scalability – MongoDB supports horizontal scaling, distributing data across multiple
servers for better performance.
 Indexing for Fast Retrieval – It allows indexing on fields, significantly improving
data query performance.
 Supports CRUD Operations – MongoDB provides powerful Create, Read, Update,
and Delete (CRUD) operations for managing data.
 High Performance – Optimized for handling large volumes of data with minimal
latency.

21
3.3.1 TABLE DESCRIPTIONS:
Below are the main collections (tables) used in the Hospital Management System:
Table Name: Admin
Description: This table stores login credentials for hospital administrators.

Column Name Data Type Description

email_id Varchar(60) Admin email for authentication.

password Varchar(250) Hashed password for security.

Re-entered password for

confirm_password Varchar(250)
verification.

Table Name: Users

Description: Stores user details, including patients and general users.

Column Name Data Type Description

id Int(10) Unique User ID.

name Varchar(50) Full Name of the user.

email Varchar(50) User Email ID.

phone Int(10) Contact Number.

NIC Int(13) National Identity Card Number.

gender Varchar(10) Male / Female / Other.

dob Date Date of Birth.

22
23
Table Name: User_Login
Description: Stores login details for registered users.

Column Name Data Type Description

Registered user
email_id Varchar(60)
email.

password Varchar(250) User password.

Re-entered password
confirm_password Varchar(250)
for verification.

Table Name: Doctors

Description: Stores doctor information, specialization, and availability.

Column Name Data Type Description

id Int(10) Unique Doctor ID.

first_name Varchar(50) First Name of the doctor.

last_name Varchar(50) Last Name of the doctor.

email Varchar(50) Doctor’s Email ID.

phone Int(10) Contact Number.

NIC Int(13) National Identity Card Number.

gender Varchar(10) Male / Female / Other.

dob Date Date of Birth.

Specialization (e.g., Cardiology,

department Varchar(50)
Neurology).

Days Available for

available_days Varchar(50)
Appointments.

password Varchar(250) Doctor’s Login Password.

24
Table Name: Appointments
Description: Manages patient appointment bookings.

Column Name Data Type Description

appointment_id Int(10) Unique Appointment ID.

patient_id Int(10) Reference to User ID.

doctor_id Int(10) Assigned Doctor’s ID.

date Date Scheduled Date of Appointment.

time_slot Varchar(20) Morning/Afternoon/Evening.

status Varchar(20) Pending/Confirmed/Cancelled.

Table Name: Messages

Description: Stores messages sent by users to the admin panel.

Column Name Data Type Description

message_id Int(10) Unique Message ID.

user_id Int(10) Reference to User ID.

message Varchar(500) User Inquiry or Complaint.

timestamp Timestamp Time of Message Submission.

Table Name: Add_Admin

25
Description: Stores admin registration details.

Column Name Data Type Description

id Int(10) Unique Admin ID.

first_name Varchar(50) First Name of the admin.

last_name Varchar(50) Last Name of the admin.

email Varchar(50) Admin’s Email ID.

phone Int(10) Contact Number.

NIC Int(13) National Identity Card Number.

gender Varchar(10) Male / Female / Other.

dob Date Date of Birth.

password Varchar(250) Admin’s Login Password.

Re-entered password for

confirm_password Varchar(250)
verification.

26
27
3.4 STRUCTURE OF THE PROJECT
1.6.1.4 DATABASE MODULE:
 Patient Records: Stores patient details, appointment history, and treatment records.
 Doctor Records: Stores information about doctors, their specializations, and
availability.
 Appointment Records: Manages scheduling, cancellations, and confirmations.
 Message Records: Stores messages sent by patients or users to the hospital
administration. This module enables secure communication between users and
admins.
 User Records: Stores registered user details, authentication credentials, and profile
information.


1.6.1.2 ADMIN MODULE

 Admin Login: Secure login for hospital administrators.

(Fig 4: Admin Login)

 Manage Doctors: Admins can add, update, or remove doctor records.

28
 (Fig 5: Doctor Register)

 Manage Appointments: Admins can view and approve/reject patient appointment

requests.

(Fig 6: Appointment Management)

 Message System: Admins can receive and respond to patient inquiries.

29
 (Fig 7: Messages Section)

 Doctor Records: Stores information about doctors, their specializations, and

availability.

(Fig 8: Doctor Management)

30
31
 CHAPTER–4
USE CASE DIAGRAMS

32
4.1 INTRODUCTION OF USE CASE
Use-case diagrams describe the high-level functions and scope of a system. These diagrams
also identify the interactions between the system and its actors. The use cases and actors in
use-case diagrams describe what the system does and how the actors use it, but not how the
system operates internally.
Use-case diagrams are helpful in the following situations:
 Before starting a project, you can create use-case diagrams to model a business so that
all participants in the project share an understanding of the workers, customers, and
activities of the business.
 While gathering requirements, you can create use-case diagrams to capture the system
requirements and to present to others what the system should do.
 During the analysis and design phases, you can use the use cases and actors from your
use-case diagrams to identify the classes that the system requires.
 During the testing phase, you can use use-case diagrams to identify tests for the
system.
The four elements of a use-case diagram are:
 System
 Actors
 Use Cases
 Relationships
A use-case diagram should visualize a reason (use case) why an individual (actor) would
interact with your organization (system) and the relationships between the business and the
individuals.
Use-case diagrams also help in defining the scope and boundaries of the system by
highlighting what features are included and what is beyond the system’s control.

They provide a clear communication tool for both technical and non-technical stakeholders,
making it easier to discuss and refine system functionalities.

By understanding different use cases, developers can structure the software design more
effectively, ensuring that the system meets user needs.

33
34
4.1.1 USE CASE DIAGRAM FOR OJT–1 & OJT–2

35