Experiment - 1

Problem Statement for Hospital Management System.

Objective:
Design and implement a Hospital Management System (HMS) that allows for the efficient management of
hospital operations, including patient management, doctor management, appointment scheduling, and billing.

Requirements:
1. Patient Management:

o Add new patients to the system with details such as name, age, gender, contact information,
and medical history.

o Update patient details.

o View a list of all patients.

o Search for a patient by name or ID.

o Delete a patient record from the system.

2. Doctor Management:

o Add new doctors with details like name, specialization, experience, and contact information.

o Update doctor details.

o View a list of all doctors.

o Search for a doctor by name or specialization.

o Delete a doctor record from the system.

3. Appointment Scheduling:

o Schedule appointments for patients with doctors, specifying the date, time, and reason for the
visit.

o Update appointment details.

o View a list of all appointments.

o Search for appointments by patient name, doctor name, or date.

o Cancel an appointment.

4. Billing System:

o Generate bills for patients based on services rendered, including consultation fees, medical
tests, and treatments.

o View and update billing information.

o Print bills or save them to a file.

 5. Reports:

o List of all patients treated by a specific doctor.

o Daily/weekly/monthly appointment schedules.

o Financial reports summarizing billing information.

6. User Authentication:

o Implement basic user authentication to ensure that only authorized personnel can access
certain features of the system.

o User roles such as Admin, Doctor, and Receptionist should have different access levels.

7. Data Persistence:

o Store data (patients, doctors, appointments, billing) in files or a database so that it is preserved
between sessions.

o Load data from files or a database when the system starts.

8. Error Handling:

o Ensure that the system gracefully handles errors, such as invalid input or failed database
connections.

9. User Interface:

o Create a simple command-line interface (CLI) for interacting with the system.

o Ensure that the system is user-friendly and provides clear instructions.

Other Features :

● Integration with external systems for lab results or pharmacy management.

● Graphical User Interface (GUI) instead of CLI.

● SMS or email notifications for appointment reminders.

Deliverables:

● Source code of the C++ program.

● A brief documentation explaining how to set up and run the system.

● A sample data file for testing the system.

 Experiment - 2

Objective: To create Initial Requirements Document (IRD) for a Hospital Management

System

Title of the project Hospital Management System

Stakeholders involved in capturing Doctors, Nurses, Hospital Administrators, Patients, IT Staff

requirements

Techniques used for requirement Interviews, Surveys, Workshops, Document Analysis

capturing (existing systems)

Name of the persons along with Rikky

designations

Date Feb 2025

Version 1.0

Consolidated list of initial requirements:

1. The system shall manage patient demographics (name, address, DOB, etc.).
2. The system shall track patient medical history (allergies, past illnesses, etc.).
3. The system shall manage patient appointments and scheduling.
4. The system shall generate unique patient identifiers.
5. The system shall allow patients to book appointments online or via phone.
6. The system shall send appointment reminders to patients.
7. The system shall allow staff to manage doctor schedules and availability.
8. The system shall manage doctor profiles (specialization, qualifications, etc.).
9. The system shall manage staff roles and permissions.
10. The system shall store patient medical records securely and confidentially.
11. The system shall allow authorized personnel to access and update medical records.
12. The system shall support electronic signatures for medical documents.
13. The system shall generate invoices for services rendered.
14. The system shall process payments (cash, card, insurance).
15. The system shall generate financial reports.
16. The system shall track medical supplies and equipment inventory.
17. The system shall generate alerts for low stock levels.
18. The system shall manage purchase orders and vendor information.
19. The system shall generate reports on patient demographics, treatments, and outcomes.
20. The system shall provide analytics on hospital performance metrics.
21. The system shall ensure data security and patient privacy.
22. The system shall implement role-based access control.
23. The system shall comply with relevant healthcare regulations (e.g., HIPAA).
24. The system shall integrate with laboratory information systems (LIS).
25. The system shall integrate with radiology information systems (RIS).
26. The system shall have a user-friendly interface.
27. The system shall be accessible on different devices (desktops, tablets).
28. The system shall allow administrators to manage users, permissions, and system settings.
29. The system shall provide audit trails for system activity.
 Experiment - 3

Objective:
To create a detailed Use Case Diagram on the Hospital Management System.
 Experiment – 4
Objective:
To create detailed Use Case Descriptions on the Hospital Management System.

Theory:
Actors in a Use Case Description represent external entities interacting with the system. Each
actor performs specific actions, known as use cases, based on their role within the system. In
a Hospital Management System, the main actors—Patient, Doctor, and Admin—each have
different functionalities they interact with. The use case descriptions for actors provide a
breakdown of the processes they engage with and help clarify their roles.

Procedure:
1. Identification of Actors:
○ Patient: Requests services like scheduling appointments, paying bills, and
viewing records.
○ Doctor: Manages patient medical records, issues prescriptions, and handles
schedules.
○ Admin: Manages hospital staff, generates reports, and overseas operations.
2. List of Use Cases for Each Actor:
○ For Patient: Request Appointment, View/Pay Bill, View Medical Records.
○ For Doctor: Access Patient Medical Records, Issue Prescription, Manage
Schedule.
○ For Admin: Manage Hospital Staff, Generate Reports, Manage Schedules.
3. Writing Actor-Centric Use Case Descriptions:
○ For each actor, define the use cases they interact with, focusing on the steps
they follow and the system's responses.

Actor Use Case Descriptions:

Actor: Patient
Use Case 1: Request Appointment

● Preconditions:
○ The patient must be registered in the system.
○ The system must have available appointment slots.
● Postconditions:
○ The appointment is scheduled, and the patient receives a confirmation.
● Main Flow:

1. The patient logs into the system.

2. The patient selects "Request Appointment."

3. The system displays available doctors and time slots.

4. The patient chooses a time and doctor.

5. The system confirms the appointment and sends a notification.

Use Case 2: View/Pay Bill

● Preconditions:
○ The patient must have an outstanding bill in the system.
○ The patient must be logged in.
● Postconditions:
○ The bill is paid, and the patient receives a receipt.
● Main Flow:

1. The patient navigates to the "Billing" section.

2. The system shows any pending bills.

3. The patient selects a bill and proceeds to payment.

4. The system processes the payment and provides confirmation.

Use Case 3: View Medical Records

● Preconditions:
○ The patient must be registered in the system.
○ The patient must have medical records stored in the system.
● Postconditions:
○ The patient successfully views their medical records.
● Main Flow:

1. The patient logs into the system.

2. The patient navigates to "Medical Records."

3. The system retrieves and displays the patient's medical history.

Actor: Doctor
Use Case 1: Access Patient Medical Records

● Preconditions:
○ The doctor must be logged into the system and have access to patient data.
● Postconditions:
○ The doctor successfully views or updates the patient's records.
● Main Flow:

1. The doctor logs in and selects a patient from the system.

2. The system displays the patient's medical records.

3. The doctor reviews or updates the records.

Use Case 2: Issue Prescription

● Preconditions:
○ The doctor must have access to the patient's medical history.
○ The doctor must be authorized to issue prescriptions.
● Postconditions:
○ The prescription is sent to the pharmacy and logged in the patient’s records.
● Main Flow:

1. The doctor selects a patient's record.

2. The doctor enters the prescription details.

3. The system sends the prescription to the pharmacy and provides confirmation.

Use Case 3: Manage Schedule

● Preconditions:
○ The doctor must be logged into the system.
● Postconditions:
○ The schedule is updated, reflecting new appointments.
● Main Flow:

1. The doctor logs into the scheduling system.

2. The system shows the doctor’s current schedule.

3. The doctor makes any necessary changes to appointments.

4. The system updates the schedule.

Actor: Admin
Use Case 1: Manage Hospital Staff

● Preconditions:
○ The admin must have access to staff management tools.
● Postconditions:
○ The staff details are updated in the system.
● Main Flow:

1. The admin logs into the system and accesses the "Staff Management" section.

2. The system shows a list of hospital staff.

3. The admin adds, updates, or removes staff details.

4. The system saves the changes.

Use Case 2: Generate Reports

 ● Preconditions:
○ The admin must be logged into the system and have access to report
generation.
● Postconditions:
○ The requested report is generated and available for review.
● Main Flow:

1. The admin logs into the system and navigates to "Reports."

2. The system prompts the admin to select the report type (e.g., financial, staff).

3. The system generates the report and makes it available for download or printing.

Use Case 3: Manage Schedule

● Preconditions:
○ The admin must have the necessary privileges to manage schedules.
● Postconditions:
○ Hospital staff schedules are updated.
● Main Flow:

1. The admin accesses the "Scheduling" section.

2. The system displays the current schedule for staff.

3. The admin adds or modifies appointments for staff members.

4. The system updates the schedules and provides confirmation.

Conclusion:
The Use Case Descriptions for actors in the Hospital Management System provide clear
insights into how Patients, Doctors, and Admins interact with the system. Each actor
performs specific actions that contribute to the system’s functionality, including appointment
scheduling, medical record access, and administrative management. Understanding these
interactions helps define system requirements and user behaviour.
 Experiment - 5
Objective:
To create a SRS Document on the Hospital Management System.

1. Introduction

1.1 Purpose

This document provides the software requirements specification for the Hospital
Management System (HMS), which will manage various administrative and medical
functions of a hospital or healthcare institution.

1.2 Scope

The HMS will handle patient registration, appointment scheduling, billing, doctor and staff
management, pharmacy, laboratory results, and reporting. It aims to streamline the workflow
in hospitals, enhance efficiency, and improve patient care quality.

1.3 Definitions, acronyms and abbreviations

● HMS: Hospital Management System

● EHR: Electronic Health Record
● API: Application Programming Interface
● UI: User Interface
● DB: Database
● HIPAA: Health Insurance Portability and Accountability Act

1.4 References

● IEEE 830-1998 – Recommended Practice for Software Requirements Specifications

● HL7 Standards
● HIPAA Compliance Guidelines

1.5 Overview

This document outlines the overall structure, interfaces, user roles, system functionalities, and
other technical specifications of the HMS.

2. Overall Description

2.1 Product perspective

2.1.1 System interfaces

● Integration with pharmacy and laboratory systems via RESTful APIs

● Communication with insurance and government health portals
2.1.2 User interfaces

● Web-based dashboard for different roles (Admin, Doctor, Patient, etc.)

● Mobile responsiveness

2.1.3 Hardware interfaces

● Compatible with desktops, tablets, and mobile devices

2.1.4 Software interfaces

● Backend: Node.js/Django
● Frontend: React/Angular
● Database: PostgreSQL/MySQL

2.1.5 Communications interfaces

● HTTPS for secure communication

● Email and SMS gateways for notifications

2.1.6 Memory constraints

● Minimum 8 GB RAM on server

● Disk storage: 500 GB recommended for initial deployment

2.1.7 Operations

● 24/7 operation with daily backups and system health monitoring

2.1.8 Site adaptation requirements

● Custom branding and localization options for different hospitals

2.2 Product functions

● Patient record management

● Appointment scheduling
● Staff and doctor management
● Billing and payments
● Pharmacy and inventory control
● Lab test result management
● Reporting and analytics

2.3 User characteristics

● Basic digital literacy

● Different levels of access and capabilities based on roles

2.4 Constraints

● Compliance with HIPAA and HL7

● Browser compatibility (latest versions of Chrome, Firefox, Edge)
2.5 Assumptions and dependencies

● Stable internet connection

● Functional third-party APIs for lab and pharmacy

2.6 Apportioning of requirements

● Advanced analytics and AI-based diagnosis suggestions to be developed in future

versions

3. Specific Requirements

3.1 External interfaces

● REST APIs for third-party integration (lab, pharmacy, insurance)

● Secure login and user authentication mechanisms

3.2 Functions

● Patient registration and profile updates

● Appointment booking and tracking
● Medical history storage
● Billing generation and payment tracking
● Inventory management for medicines
● Lab test report uploads

3.3 Performance requirements

● System should support 100+ concurrent users

● Response time < 2 seconds for 95% of transactions

3.4 Logical database requirements

● Entity relationships: Patients, Doctors, Appointments, Bills, Medicines, Lab Reports

● Normalized schema with referential integrity

3.5 Design constraints

● Use of MVC architecture

● Secure password storage and user role validation

3.5.1 Standards compliance

● Must comply with HL7 and HIPAA standards

3.6 Software system attributes

3.6.1 Reliability

● 99.9% uptime with automated failover systems

3.6.2 Availability

● Accessible 24/7 with minimal downtime

3.6.3 Security

● Role-based access control, data encryption, regular audits

3.6.4 Maintainability

● Modular codebase, documented APIs, version control

3.6.5 Portability

● Browser-based application accessible from any device

3.7 Organizing the specific requirements

3.7.1 System mode

● Operational mode
● Maintenance mode

3.7.2 User class

● Admin, Doctor, Receptionist, Patient, Pharmacist, Lab Technician

3.7.3 Objects

● Patient, Appointment, Bill, Prescription, Lab Report

3.7.4 Feature

● Login, Register, Schedule, Upload, Generate Report

3.7.5 Stimulus

● User inputs, API calls, scheduled jobs

3.7.6 Response

● Confirmation messages, data storage, email/SMS notifications

3.7.7 Functional hierarchy

● HMS > Module > Feature > Sub-feature

3.8 Additional comments

● Future versions may incorporate AI-based patient diagnostics and remote monitoring
capabilities
4. Supporting Information

● Appendix A: Glossary
● Appendix B: Use Case Diagrams
● Appendix C: Data Flow Diagrams
● Appendix D: System Architecture Diagrams
 Experiment - 6
Objective:
To create a detailed Class Diagram on the Hospital Management System.
 Experiment - 7
Objective:
To create a detailed Sequence Diagram on the Hospital Management System.

Theory:

A Sequence Diagram is an interaction diagram that shows how objects operate with one
another and in what order. It depicts the sequence of messages exchanged between the
objects to carry out the functionality of a scenario.

In a Hospital Management System (HMS), different modules like Login, Patient

Registration, etc., involve interactions between actors (e.g., patient, receptionist, system) and
system components.

Flow Types :

1. Basic Flow – Normal/expected sequence of interactions.

2. Alternate Flow – Variations or exceptions in the process.

Sequence Diagrams:
1. Login Module:

Basic flow
 Alternate flow

2. Patient Registration:

Basic flow
 Alternate flow

3. Appointment

Basic Flow
 Alternate Flow

4.Billing

Basic Flow
 Alternate Flow

5. Pharmacy:

Basic Flow
Alternate Flow
 Experiment - 8
Objective:
To create an Activity Diagram on the Hospital Management System.
 Experiment - 9
Objective:
To create a detailed Collaboration Diagram on the Hospital Management System.
 Experiment - 10
Objective:
To create a Test case matrix on the Hospital Management System.

Theory:

A Hospital Management System (HMS) is software designed to manage all aspects of a

hospital's operations, such as medical, administrative, financial, and legal functions. The
system handles activities like patient registration, appointment scheduling, billing, pharmacy,
and report management.
Software testing ensures that each component of the HMS functions correctly under various
conditions. A test case matrix is used to organize test cases across different modules, helping
testers identify inputs, execution conditions, and expected results efficiently.

Testing types involved:

● Functional Testing: To check each function performs as expected.

● Boundary Testing: To evaluate limits of input fields.

● Validation Testing: Ensuring correct data entry and restrictions.

● Integration Testing: Checking interaction between modules.

A systematic approach to test case design ensures that defects are caught early, leading to a
robust and reliable software product.

Test Case Matrix

1. Login Module

Test Case ID Test Scenario Test Steps Expected Priority Status

Result
TC_LOGIN_00 Valid login Enter correct Redirected to High Pass/Fail
1 username and dashboard
password, click
Login
TC_LOGIN_00 Invalid Enter correct Show "Invalid High Pass/Fail
2 password username but credentials"
incorrect error
password
TC_LOGIN_00 Empty fields Click login Show Medium Pass/Fail
3 with empty validation
username/pass message
word
TC_LOGIN_00 Remember me Select User remains Low Pass/Fail
4 "Remember logged in
Me", login,
reopen browser

2. Patient Registration Module

Test Case ID Test Test Steps Expected Priority Status

Scenario Result

TC_PAT_00 New patient Fill in all Patient High Pass/Fail

1 registration mandatory record
fields and created
submit

TC_PAT_00 Missing Leave a Show High Pass/Fail

2 mandatory required field validation
field empty and error
submit

TC_PAT_00 Duplicate Register Show Medium Pass/Fail

3 entry same patient duplicate
ID again error

TC_PAT_00 Upload Attach image Image Low Pass/Fail

4 profile while uploaded
picture registering successfully
patient

3. Appointment Module

Test Case ID Test Test Steps Expected Priority Status

Scenario Result

TC_APPT_0 Book Select Appointment High Pass/Fail

01 appointment patient, confirmed
doctor, date
& time, then
submit

TC_APPT_0 Double Book same Show "Slot High Pass/Fail

02 booking time slot for unavailable"
check the same message
doctor again

TC_APPT_0 Cancel Click cancel Status Medium Pass/Fail

03 appointment on existing changes to
appointment "Cancelled"
 TC_APPT_0 View Go to Show all Medium Pass/Fail
04 upcoming appointments scheduled
appointments list appointments

4. Billing Module

Test Case ID Test Test Steps Expected Priority Status

Scenario Result

TC_BILL_0 Generate Add Correct bill High Pass/Fail

01 patient bill services, total
medications, displayed
click
generate

TC_BILL_0 Apply Apply Discount High Pass/Fail

02 discount percentage or reflected in
flat discount total

TC_BILL_0 Partial Enter partial Balance Medium Pass/Fail

03 payment amount and displayed
submit

TC_BILL_0 Print bill Click print Printable Low Pass/Fail

04 on bill page version
opens

5. Pharmacy Module

Test Case ID Test Test Steps Expected Priority Status

Scenario Result

TC_PHARM Dispense Select Inventory High Pass/Fail

_001 medication medicine and updated, bill
assign to generated
patient

TC_PHARM Out-of-stock Try Show "Out High Pass/Fail

_002 check dispensing of Stock"
unavailable error
medicine

TC_PHARM Add new Enter new Medicine Medium Pass/Fail

_003 medicine stock details added to
stock and submit inventory
 TC_PHARM Check expiry Attempt to Warning High Pass/Fail
_004 validation dispense shown and
expired batch action
blocked

Result and Observation:

Module Test Case Passed Test Cases Failed Remarks

Login 4 0 All scenarios passed

Patient Registration 4 0 No issues observed

Appointment 4 0 Shot conflict handled

correctly

Billing 4 0 Calculations and print

working

Pharmacy 4 0 Inventory and expiry

handled

Conclusion:

All functional modules of the Hospital Management System were tested successfully. The
test cases confirmed that the login, patient registration, appointment, billing, and pharmacy
features work as intended under valid and invalid scenarios. This ensures the HMS is reliable
and ready for production use or further integration testing.