E-Administration of Computer Labs.

A project report submitted

To

THAKUR COLLEGE OF SCIENCE AND COMMERECE

For the fulfilment of the requirement for
The Award of the Degree
Of
Bachelor of Science in Information Technology

Submitted by
Vibhuti Sharma-4166
Khushi Bagdi-4167
Sneha Gawas-4168
Viranshi Sanghavi-4169
Devanshi Joshi-4170

Under the guidance of

Mrs.Jyotsna Anthal

Lecturer, Department of IT, TCSC

Page | 1
 ACKNOWLEDGEMENT

Apart from the efforts of team, the success of any project depends largely on the
encouragement and guidelines of many others. We take this opportunity to express our
gratitude to the people who have been instrumental in the successful completion of this
project. The completion of any inter-disciplinary project depends upon cooperation, co-
ordination and combined efforts of several sources of knowledge. We are eternally grateful
to our teacher JYOTSNA MAM for her even willingness to give us valuable advice and
direction under which we executed this project. Her constant guidance and willingness to
share her vast knowledge made us understand this project and its manifestations in great
depths and helped us to complete the assigned tasks.

Page | 2
 ABSTRACT

The hospital has required a system that maintains its Hospital Management System as
well as keeps the records of the Hospital in database. This software manage all information
about patient name, patient address, doctor information, staff information etc. It also store
daily information of patient which is done by doctor. Also store information about billing,
finally it calculate total bill of patient.
It is having mainly two modules. One is at Administration Level and other one is of user I.e.
of patients and doctors. The Application maintains authentication in order to access the
application. Administrator task includes managing doctors information, patient’s
information. To achieve this aim a database was designed one for the patient and other for
the doctors which the admin can access. The complaints which are given by user will be
referred by authorities. The Patient modules include checking appointments, prescription.
User can also pay doctor’s Fee online.

Page | 3
 TABLE OF CONTENTS

Chapter Topic Page No.

1 INTRODUCTION 5
1.1 Purpose
1.2 Scope
1.3 Definitions, Acronyms, Abbreviation
1.4 Overview
2 GENERAL DESCRIPTION 8
2.1 Product features
2.2 Product features
3 SPECIFIC REQUIREMENTS 9
3.1 Functional Requirements
3.2 Non-Functional Requirements
3.3 Interface Requirements
4 FEASIBILITY STUDY
4.1 Economic Feasibility
4.2 Technical Feasibility
4.3 Operational Feasibility
5 DESIGN AND RESULTS 13
5.1 UML Diagram
52 Database Diagram
6 TESTING 17
6.1 Unit Testing
6.2 Black Box Testing
6.3 White Box Testing
6.4 Integration Testing
6.5 Validation Testing
6.6 Acceptance testing
7 CONCLUSION 19

CHAPTER 1
Page | 4
 INTRODUCTION
1.1 PURPOSE
1.2 SCOPE
1.3 DEFINITIONS, ACRONYMS and ABBREVIATIONS
1.4 REFERENCES
1.5 OVERVIEW

Page | 5
1.1 PURPOSE
The main purpose of our system is to make hospital task easy and is to develop software
that replaces the manual hospital system into automated hospital management system.
This document serves as the unambiguous guide for the developers of this software
system. This software is used to provide a comprehensive solution for managing hospital
operations, including patient management, appointment scheduling, doctor and staff
management, inventory control, billing, reporting and emergency handling.

1.2 SCOPE
The system will be used as the application that serves hospitals, clinic, dispensaries or
other health institutions. The intention of the system is to increase the number of patients
that can be treated and managed properly. If the hospital management system is file
based, management of the hospital has to put much effort on securing the files. They can
be easily damaged by fire, insects and natural disasters. Also could be misplaced by losing
data and information.

1.3 DEFINITIONS, ACRONYMS and ABBREVIATIONS

1] Cardiologist – treats heart disease.
2] Pediatrician – treats infants, toddlers, children and teenagers.
3] Plastic Surgeon – restores, reconstructs, corrects or improves in the shape and
appearance of damaged body structures, especially the face.
4] Psychiatrist – treats patients with mental and emotional disorders.
5] Opthalmologist – treats eye defects, injuries and diseases.
6] ENT – Ear, Nose and Throat specialist.

• SRS: Software Requirement Specification.

• DFD: Data Flow Diagram.
• ENT- Ear, Nose and Throat Specialist.
• BG - Blood group
✓ Appt – Appointment.
✓ Sign up - Creating New User.
✓ Log in - Logging in Existing User.
✓ PhNo - Mobile number.
✓ Addr – Address.
✓ Expr – Experience.

1.4 REFERENCES
➢ https://www.officetimeline.com/make-gantt-chart/excel

Page | 6
➢ https://medium.com/@datamateuaecrescent/hospital-management-systemfeatures-
objectives-62eeb13f4fc4

1.5 OVERVIEW
The Software Requirement Specification (SRS) is the requirement work product that
formally specifies Hospital Management System.
It includes the result of both business analysis and systems analysis efforts various
techniques were used to click the requirements and we have identified your needs,
analyzed and refined them.
The objective of this document therefore is to formally describe the system’s high level
requirements including functional requirements, non-functional requirements and business
rules and constraints.
The user module can be accessed by both the doctors and the patients. The doctor can
confirm and/or cancel appointments. The doctors can even add prescriptions for their
patients using our application. The patients will be able to apply for the appointment and
make transaction for the same, and can even cancel appointments with the doctors. They
can track details about the previous transactions made by them.

Page | 7
 CHAPTER 2
GENERAL DESCRIPTION

2.1 PRODUCT PERSPECTIVE

2.2 PRODUCT FEATURES

2.1 PRODUCT PERSPECTIVE

This Hospital Patient Info Management System is a self-contained system that manages
activities of the hospital. Due to improperly accessing past data as well as managing
present data. The fully functional automated hospital management system which will be
developed through this project will eliminate the disadvantages caused by the manual
system by improving the reliability, efficiency and performance. The usage of a database to
store patient, employee, stock details etc. will accommodate easy access, retrieval, and
search and manipulation of data. The access limitations provided through access privilege
levels will enhance the security of the system. The system will facilitate concurrent access
and convenient management of activities of the medical center.

2.2 PRODUCT FEATURES

The system function can be described as follows:
REGISTRATION: When a patient is admitted, the front-desk staff checks to see if the
patient is already registered with the hospital.
If he or she is, his/her Personal Health Number (PHN) is entered into the computer,
otherwise a new Personal Health Number is given to this patient. The patient’s information
such as date of birth, address and telephone number is also entered into computer system.
PATIENT CHECK OUT: If a patient checks out, the administrative staff shall delete his
PHN from the system and the just evacuated bed is included in available beds list.
GENERATION: The system generates reports on the following information: list of detailed
information regarding the patient who has admitted in the hospital.

Page | 8
 CHAPTER 3
SPECIFIC REQUIREMENTS

3.1 FUNCTIONAL REQUIREMENTS

3.2 NON-FUNCTIONAL REQUIREMENTS
3.3 INTERFACE REQUIREMENTS

Page | 9
3.1 FUNCTIONAL REQUIREMENTS
1] PATIENT MANAGEMENT
> Register new patients with relevant demographic and medical information.
> Maintain electronic medical records (EMR) for each patient.
> Schedule appointments and manage patient queues.

2] APPOINTMENT SCHEDULING
>Enable patients to request appointments online or through hospital’s front desk.
> Allow staff or schedule, reschedule and cancel appointments based on availability.

3] DOCTOR AND STAFF MANAGEMENT

> Maintain a database of doctors and staff members, including their qualifications,
specialties and schedules.
> Assign doctors to specific departments and clinics.
> Manage staff shits and responsibilities.

4] INVENTORY MANAGEMENT
> Track inventory levels of medical supplies, drugs and equipment.
> Generate alerts for low stock levels and recorder supplies as needed.
> Manage suppliers and procurement processes.

5] BILLING AND INVOICING

>Generate invoices for services rendered, including consultations, procedures and
medications.
> Calculate and apply discounts, if applicable.
> Process payments and maintain payment records.

6] REPORTING
> Generate various reports, including financial reports, patient statistics and inventory
status.
>Provide customizable report templates and scheduling options.

3.2 NON-FUNCTIONAL REQUIREMENTS

1] PERFORMANCE REQUIREMENTS
> The system should be responsive and able to handle multiple concurrent users.
> Response times for critical functions should be within acceptable limits.

2] SECURITY REQUIREMENTS

Page | 10
> Implement user authentication and authorization mechanisms to control access to
sensitive data.
> Encrypt patient data to ensure confidentially and compliance with data protections
regulations.

3] USABILITY REQUIREMENTS
> The user interfaces should be intuitive and easy to navigate.
> Provide training and documentation to support users in learning and using the system
effectively.

4] RELIABILITY REQUIREMENTS
> Ensure system availability and uptime to minimize disruption to hospital operations.
> Implement backup and recovery mechanisms to product against data loss.

5] SCALABILITY REQUIREMENTS
> The system should be scalable to accommodate growth in patient volume and additional
functionality.
> Support integration with external systems and services as needed.

6] MAINTAINABILITY
> The system shall provide the capability to backup data
> The system shall keep a log of all the errors.

3.3 INTERFACE REQUIREMENTS

1] USER INTERFACES
> This section provides a detailed description of all inputs into and outputs from the
system. It also gives a description of the hardware, software and communication interfaces
and provides basic prototypes of the user interface.
> The user interface should be visually appealing and consistent across modules.
> Provide role-based access controls to customize the interface for different user roles.

2] HARDWARE INTERFACES
> Laptop /Desktop PC-Purpose of this is to give information when Patients ask information
about doctors, medicine available lab tests etc. To perform such Action it need very
efficient computer otherwise due to that reason patients have to wait for a long time to get
what they ask for. > Laser Printer (B/W) - This device is for printing patients’ info etc.
> Wi-Fi router - Wi-Fi router is used to for internetwork operations inside of a hospital and
simply data transmission from pc’s to sever.

3] SOFTWARE INTERFACES

Page | 11
> JDK 1.8 - Java is fast, secure, and reliable. From laptops to data centers, game consoles
to scientific supercomputers, cell phones to the Internet.
> Mysql server - Database connectivity and management
> OS Windows 7/8/8.1- Very user friendly and common OS
> JRE 1.8 – JAVA Runtime Environment for run Java Application and System

Page | 12
 CHAPTER 4
FEASIBILITY STUDY
4.1 ECONOMIC FEASIBILITY
4.2 TECHNICAL FEASIBILITY
4.3 OPERATIONAL FEASIBILITY

Page | 13
FEASIBILITY STUDY
A feasibility study on a hospital management system would involve assessing various aspects such
as technical feasibility (compatibility with existing infrastructure, scalability), economic feasibility
(cost-benefit analysis, ROI), operational feasibility (impact on workflow, user acceptance), and
legal/regulatory feasibility (compliance with healthcare regulations). This study would help
determine whether implementing such a system is viable and beneficial for the hospital.

4.1 ECONOMIC FEASIBILITY

Assessing the economic feasibility of a hospital management system involves conducting a cost-
benefit analysis to determine if the benefits of implementing the system outweigh the costs. This
analysis would include factors such as initial investment, ongoing maintenance and support costs,
potential cost savings from improved efficiency, reduced errors, and enhanced revenue generation.
It's crucial to consider both short-term and long-term financial implications to ensure the system's
economic viability.

4.2 TECHNICAL FEASIBILITY

Evaluating the technical feasibility of a hospital management system entails assessing whether the
proposed system can be successfully developed, implemented, and integrated with existing
infrastructure. This involves analyzing factors such as compatibility with current hardware and
software, scalability to accommodate future growth, availability of skilled personnel for
development and maintenance, and adherence to industry standards and best practices. Conducting
thorough technical assessments helps ensure the system's feasibility from a technical perspective.

4.3 OPERATIONAL FEASIBILITY

Assessing the operational feasibility of a hospital management system involves evaluating its
potential impact on day-to-day operations. This includes analyzing how well the system aligns with
existing workflows and processes, the ease of use for end-users, the level of training required for
staff, and the system's ability to improve overall efficiency and productivity. Operational feasibility
also considers factors such as the system's reliability, performance, and its ability to adapt to
changing needs and circumstances within the hospital environment.

Page | 14
WATERFALL MODEL SOFTWARE DEVELOPMENT LIFECYCLE

WATERFALL MODEL

The waterfall model is a sequential software development process consisting of phases like
Analysis, Requirement Specification, Design, Implementation, Testing and Integration, and
Operation and Maintenance. Progress is perceived as flowing steadily downwards, akin to
a waterfall. It emphasizes proper sealing of phases before proceeding to the next, with a
focus on documentation. This method facilitates milestone-based progress monitoring and
is suitable for projects with clear and well-known requirements, like ours. All project
activities adhere to the phases outlined in the waterfall model.

Page | 15
 CHAPTER 5
DESIGN AND IMPLEMENTATION

5.1 UML DIAGRAM

> CLASS DIAGRAM

> USE CASE DIAGRAM

Page | 16
CLASS DIAGRAM

THE CLASS DIAGRAM CONSISTS OF SEVERAL MODULES:

1] PATIENT:

This class represents the patients in the system. It could include attributes like patient
name, address, contact information, gender etc.

2] HOSPITAL:

This class represents the association with departments, staff, patients and other entities
with the hospital. It could include attributes like hospital name, title, address, contact no etc.

3] DOCTOR:
This class represents the doctors or physicians working in the hospital. Attributes might
include doctor name, specialization, contact information, department etc.

4] APPOINTMENT:
This class represents appointments scheduled between patients and doctors. Attributes
might include appointment date, time, doctor name reason for the appointment, etc.

5] DEPARTMENT:
This class represents the different departments within the hospital. Attributes might include
department ID, name etc.

Page | 17
6] STAFF:
This class represents the hospital staff in general, including doctors. Attributes might
include staff name, joined date, languages, certification etc.

Page | 18
USE CASE DIAGRAM

*PATIENT
1] REGISTERATION
DESCRIPTION: The new patient can register themselves and add their details like name,
age , gender, blood group etc. The patient entry will be made in the hms database.
2] PRE-CONDITION: The patient must be a new patient, If necessary fields left by user
then prompt user to fill the necessary fields.
3] POST CONDITION: Patient record is added to hms database.

*UPDATION
1] DESCRIPTION: It shows users a list of available doctors, timings, dates and enables
patients to select the most suitable appointment date and doctor. The patient may also the
cancel the appointment.
2] PRE-CONDITION: The patient must be a registered patient, Patient can fix only one
appointment for a particular department.
3] POST CONDITION: The record of patient is updated in hms database.

*APPOINTMENT
1] DESCRIPTION: It shows users a list of available doctors, timings, dates and enables
patients to select the most suitable appointment date and doctor. The patient may also the
cancel the appointment.
2] PRE-CONDITION: The patient must be a registered patient, Patient can fix only one
appointment for a particular department.
Page | 19
3] POST CONDITION: patient details are displayed and a new appointment is fix or a
existing appointment is cancelled. The hms database is updated.

*PAYMENT
1] DESCRIPTION: It enables user to pay the consultant fee of Doctor online.
2] PRE-CONDITION - The patient must be a registered patient, If Patient don’t wants to
pay online he/she can pay by cash also.
3] POST CONDITIONS – A Reciept will be displayed. The hms database is updated.

*DOCTOR
1] DESCRIPTION: The doctor view patient record/ update his details and add description of
the treatment given to patient.
2] PRE-CONDITION – The doctor must be a registered doctor, System does not allow the
doctor to modify the qualification, hospital managed details.
3] POST CONDITION – The patient and doctor‘s database are updated.

*ADMIN
1] DESCRIPTION - The admin add doctor, update docotr details and verify payment and
generate Bill/Reciept for the same.
2] PRE -CONDITION - Admin must first log in with his/her credentials.
3] POST CONDITION - The hms database is updated.

Page | 20
 CHAPTER 6
TESTING AND RESULTS
6.1 UNIT TESTING
6.2 BLACK BOX TESTING
6.3 WHITE BOX TESTING
6.4 INTEGRATION TESTING
6.5 VALIDATION TESTING
6.6 ACCEPTANCE TESTING

Page | 21
TESTING
Testing is an essential in software development to uncover errors and ensure software
quality and reliability. It is conducted at various stages of system development, beginning
with requirement specification. Test cases, comprising sets of data, are devised to evaluate
the system’s functionality against normal input. The testing phase involves executing these
test cases to identify errors, providing a qualitative indication of software quality. Test
results inform design modifications if needed. Testing occurs parallel to development and
culminates before live operation.

6.1 UNIT TESTING

Unit testing was done after the coding phase. The purpose of the unit testing was to locate
errors in the current module, independent of the other modules. Some changes in the
coding were done during the testing phase. Finally, all the modules were individually tested
following bottom to top approach, starting with the smallest and lowest modules and then
testing one at a time.

6.2 BLACK BOX TESTING

Page | 22
This method of software testing tests the functionality of an application as opposed to its
internal structures or working (i.e. white box testing). Specific knowledge of the
application’s code/internal structure and programming knowledge, in general, is not
required. Test cases are built to specifications and requirements, i.e., what the application
is supposed to do. It uses external descriptions of the software, including specifications,
requirements, and design to derive test cases. These tests can be functional or non-
functional, though usually functional. The test designer selects valid and invalid inputs and
determines the correct output. There is no knowledge of the test object’s internal structure.

6.3 WHITE BOX TESTING

This method of software testing tests internal structures or workings of an application, as opposed
to its functionality (i.e. black-box testing). In white-box testing, an internal perspective of the
system, as well as programming skills, are required and used to design test cases. The tester
chooses inputs to exercise paths through the code and determine the appropriate outputs.

6.4 INTEGRATION TESTING

Once the unit was over, all the modules were integrated for integration testing. External and
internal interfaces are implemented and work as per design, the performance of the module is not
degraded.

6.5 VALIDATION TESTING

At the culmination of integration testing, the software is said to be completely assembled as a
package; interfacing errors have been uncovered and corrected. Then as a final series of software
test, validation tests were carried out.

6.6 ACCEPTANCE TESTING

This is the final stage in the testing process before the system is accepted for operational use. Any
requirement problem or requirement definition problem revealed from acceptance testing are
considered and made error free.

Page | 23
 CONCLUSION

Working on the project was an excellent experience. It helped us to understand the

importance of planning, designing and implementation so far we have learnt in our
theory books. It helped us unleashing our creativity while working in a team. It also
realized the importance of team working, communication as a part of this project. The
project was successfully completed after a lot of efforts and work hours. This project
underwent number of compiling, debugging, removing errors, making it bug free,
adding more facilities in Hospital Management System and interactivity making it more
reliable and useful. This project focused that scheduling a project and adhering to that
schedule creates a hard sense of time- management. It has also let us known that co-
operative teamwork always produce effective results. The entire project has been
developed and deployed as per the requirements stated by the user. It is found to be
bug free as per the testing standards that are implemented. There are also few
features which can be integrated with this system to make it more flexible.
Below list shows the future points to be consider as:
• Getting the current status of patient.
• Including a different module for pharmacy, LAB, Bed Allotment and many more.
• Including a Frequently Asked Questions Section.
Finally, we like to conclude that we put all our efforts throughout the development of
our project and tried to fulfill most of the requirements of the user.

Page | 24