LAB No.

- 01

Objective:
Prepare a detailed problem statement for the selected project.

Problem Statement:
Develop and implement a hospital management system that efficiently manages hospital
resources, facilitates user interactions, and enhances hospital operations. The system should
automate various tasks such as patient admission, discharge, and appointment scheduling
while providing a seamless experience for both hospital staff and patients.

Challenges:
The challenges in preparing a hospital management system project include:

1. Data Collection and Quality:

 Acquiring comprehensive and accurate data about hospital resources, including

patient records, medical equipment, and staff details, presents a challenge.

2. Data Preprocessing:

 Cleaning and standardizing hospital datasets from diverse sources, including medical
records, billing systems, and inventory databases, requires careful preprocessing.
 Handling inconsistencies in data formats, duplicate entries, and missing information
is essential for efficient hospital operations.

3. Algorithm Selection and Optimization:

 Choosing and optimizing algorithms for patient diagnosis, treatment planning, and
resource allocation for accuracy and scalability.

4. Security and Access Control:

 Implementing robust security measures to protect sensitive hospital data and ensure
patient privacy is crucial.
 Enforcing access control policies to restrict unauthorized access to patient records and
sensitive information adds complexity to system development.

5. Reporting and Analytics:

 Implementing reporting and analytics functionalities to track hospital utilization,

inventory status, and patient demographics is important for informed decision-
making.
 Developing mechanisms for generating custom reports and extracting meaningful
insights from hospital data is challenging.
Project Goals:

1. System Design:

 Develop a comprehensive architectural overview of the hospital management system,

outlining data flow, module interactions, and system components.

2. Data Processing:

 Collect, clean, and preprocess hospital data, including patient details, medical
records, and inventory records, for efficient system operation and analysis.

3. Module Implementation:

 Implement and integrate various modules such as patient management, inventory

management, staff management, and reporting, ensuring seamless interaction and data
flow between components.

4. User Interface Development:

 Design and develop an intuitive and user-friendly interface for hospital staff,
incorporating features for easy navigation, patient management, and resource
allocation.

5. Security Implementation:

 Implement robust security measures, including authentication, authorization, and

encryption, to protect hospital data and ensure compliance with data privacy
regulations.

6. Documentation:

 Create comprehensive documentation covering system design, data processing

workflows, module implementation details, user interface specifications, security
measures, and reporting functionalities for future reference and enhancement
strategies.
 LAB No. - 02

Objective:
Identify suitable process models for the mini project with justification.

Spiral Model:
Description:

The Spiral Model is a risk-driven software development process model that combines
iterative development and prototyping. It involves cycles of planning, risk analysis,
prototyping, development, and evaluation.

Justification:

The Spiral Model is favorable due to its risk-focused approach, iterative development
capabilities, flexibility in accommodating changing requirements, and systematic handling of
complex system functionalities. These characteristics align well with the needs of the
Hospital Management System project, ensuring effective risk management and stakeholder
involvement throughout the development lifecycle.

Selected Process Model:

After careful consideration, the Spiral model has been chosen as the process model for
developing the Hospital Management System.

Justification for Choosing the Spiral Model:

1. Risk Management:
  The Spiral model's iterative nature allows for systematic risk identification, analysis,
and mitigation throughout the project lifecycle.
 Risks associated with technology, requirements, and user expectations in the Hospital
Management System project can be addressed proactively.

2. Iterative Development:

 The system's functionalities, including patient management, appointment scheduling,

and inventory management, can be developed incrementally and refined based on
stakeholder feedback.
 Iterative development facilitates early validation of system components and ensures
alignment with evolving requirements.

3. Flexibility:

 The Spiral model offers flexibility to accommodate changing requirements and

incorporate enhancements during the development process.
 It enables stakeholders to participate in regular reviews and validations, ensuring that
the final system meets user expectations.

Spiral Model Phases:

1. Planning Phase:

 Define project objectives, constraints, and initial requirements.

 Identify key stakeholders and establish communication channels.

2. Risk Analysis Phase:

 Identify potential risks related to technology, requirements, resources, and user

expectations.
 Prioritize risks based on severity and develop mitigation strategies.

3. Prototyping Phase:

 Develop prototypes or proof-of-concepts for critical system functionalities.

 Gather feedback from stakeholders and users to refine requirements.

4. Engineering Phase:

 Detailed system design, architecture planning, and database schema design.

 Incremental development and integration of system components.

5. Evaluation Phase:

 Regular reviews, testing, and evaluations against predefined criteria.

 Incorporate feedback, make enhancements, and plan for the next iteration.
 LAB No. - 03
Objective:
Develop a Software Requirement Specifications (SRS) document for the Hospital
Management System.

SOFTWARE REQUIREMENT SPECIFICATIONS (SRS) DOCUMENT

1. Introduction
1.1 Purpose

The purpose of this document is to define the functional and non-functional requirements for
the development of a Hospital Management System (HMS) to efficiently manage hospital
operations, including patient admission, discharge, appointment scheduling, and
administrative tasks.

1.2 Scope

The Hospital Management System aims to streamline hospital processes, enhance user
experience, and improve administrative efficiency. It includes features for both hospital staff
and patients, covering patient registration, appointment scheduling, medical record
management, inventory control, and reporting functionalities.

1.3 Acronyms and Abbreviations

 HMS: Hospital Management System

 SRS: Software Requirements Specification
 UI: User Interface
 API: Application Programming Interface

1.4 Overview

The Hospital Management System will comprise frontend interfaces for user interaction,
backend databases for storing hospital data, and administrative tools for system management.

2. The Overall Description

2.1 Product Perspective

The system will interact with users through UI interfaces for patient registration, appointment
scheduling, and medical record management. It will integrate with backend databases for
storing patient records, medical information, and inventory details. Additionally, it may
integrate with external systems for billing, insurance processing, and medical record
exchange.

2.2 Product Functions

  Patient Registration: Allows hospital staff to register new patients and maintain their
records.
 Appointment Scheduling: Enables staff to schedule appointments for patients with doctors
and other hospital services.
 Medical Record Management: Facilitates the management and updating of patient medical
records, including diagnosis, treatment, and medication details.
 Inventory Management: Manages hospital inventory, including medical supplies,
equipment, and pharmaceuticals.
 Administrative Functions: Includes system configuration, report generation, and analytics
tools for administrators.

2.3 User Characteristics

The system will cater to hospital staff, including doctors, nurses, administrative personnel,
and support staff, who are responsible for managing hospital resources and providing patient
care.

2.4 Constraints

 Data Security: Compliance with data protection regulations and secure handling of patient
and hospital information.
 System Performance: Meeting defined performance benchmarks for transaction processing
and response times.
 Accessibility: Support for users with disabilities and compatibility with assistive
technologies.

2.5 Assumptions and Dependencies

The system assumes the availability of a comprehensive patient database, stable internet
connectivity for user interactions, and integration with existing hospital systems for data
exchange and authentication.

2.6 Apportioning of Requirements

Requirements are apportioned based on user roles, system modules (frontend, backend), and
administrative functionalities to ensure a well-structured and scalable system architecture.

3. Specific Requirements
3.1 External Interfaces

 UI Interfaces: Patient registration, appointment scheduling, medical record management,

inventory management.
 API Integration: Integration with external systems for billing, insurance processing, and
medical record exchange.

3.2 Functions

 Patient Registration: Register new patients, maintain patient records, assign patient
identifiers.
 Appointment Scheduling: Schedule appointments, manage appointment calendars, send
appointment reminders.
  Medical Record Management: Update medical records, track patient diagnoses, treatments,
and medications.
 Inventory Management: Manage inventory levels, track inventory usage, generate inventory
reports.

3.3 Performance Requirements

 Response Time: User actions (registration, scheduling) within 2 seconds.

 Concurrent Users: Support up to 500 concurrent users.
 Data Processing: Handle simultaneous patient registrations, appointments, and medical
record updates efficiently.

3.4 Logical Database Requirements

 Data Storage: Secure storage of patient records, medical information, inventory details.
 Scalability: Database scalability to accommodate growing patient records and hospital
resources.

3.5 Design Constraints

 UI/UX Design: Intuitive interfaces, accessible design compliant with web standards.
 Backend Scalability: Scalable architecture to handle increased data volumes and user
interactions.

3.6 Software System Attributes

 Reliability: System uptime of 99.5%.

 Availability: 24/7 access with scheduled maintenance windows.
 Security: Data encryption, user authentication mechanisms.
 Maintainability: Modular code structure, version control using Git.
 Portability: Compatibility with major web browsers and devices.

3.7 Organizing the Specific Requirements

 System Modes: Staff mode, Administrative mode.

 User Classes: Doctors, Nurses, Administrative Staff, Support Staff.
 Objects: Patients, Medical Records, Inventory Items.
 Features: Registration, Scheduling, Record Management.
 Stimulus: User actions (register, schedule), System responses (record update, inventory
tracking).
 Functional Hierarchy: User interaction flow, transaction processing sequence.

4. Change Management Process

4.1 Change Identification

 Changes can be identified through user feedback, system testing, or evolving hospital
requirements.
 A designated change control board (CCB) or team evaluates proposed changes based on their
impact, urgency, and alignment with hospital objectives.

4.2 Change Request Submission

  Stakeholders or project team members submit change requests detailing the proposed
modifications, rationale, and potential impact on project timelines, budget, or resources.
 Change requests are documented using a standardized form or tool to ensure clarity and
traceability.

4.3 Change Evaluation and Prioritization

 The CCB or designated team assesses change requests based on predefined criteria such as
impact analysis, risk assessment, and alignment with hospital priorities.
 Changes are prioritized based on their urgency, importance, and feasibility within project
constraints.

4.4 Change Approval

 Approved changes undergo formal approval by hospital management or the CCB based on
evaluation outcomes.
 Approved changes are documented, and relevant stakeholders are informed of the decision.

4.5 Change Implementation

 Changes approved for implementation are integrated into the project plan, schedule, and
development process as appropriate.
 Project teams responsible for implementation follow established procedures, update
documentation, and communicate changes to relevant stakeholders.

4.6 Change Verification and Validation

 Post-implementation, changes are verified to ensure they meet defined requirements and
expectations.
 Validation includes testing, user acceptance, and performance evaluation to confirm the
effectiveness of implemented changes.

4.7 Change Documentation and Communication

 Comprehensive documentation of approved changes, implementation details, and outcomes is

maintained for future reference and audit purposes.
 Clear and timely communication channels ensure that stakeholders are informed of change
outcomes, impacts, and any associated actions or follow-ups required.

4.8 Change Closure and Monitoring

 Successfully implemented changes are closed formally within the change management
system.
 Ongoing monitoring and evaluation assess the long-term impact of changes on hospital
performance, user satisfaction, and overall system functionality.

5. Document Approval
5.1 Stakeholder Review
  The SRS document is circulated among relevant stakeholders, including hospital
management, staff, and IT personnel.
 Stakeholders review the document to ensure that it accurately captures their requirements,
expectations, and system functionalities.

5.2 Feedback Consolidation

 Feedback and comments received from stakeholders during the review phase are consolidated
and documented.
 Identified issues, discrepancies, or suggestions for enhancements are categorized and
prioritized based on their impact on hospital objectives and deliverables.

5.3 Revision and Incorporation

 Based on consolidated feedback, necessary revisions, clarifications, or additions are made to

the SRS document.
 Changes are incorporated using version control mechanisms to track document evolution and
ensure transparency in updates.

5.4 Formal Approval Process

 The revised SRS document, along with a summary of incorporated changes and resolutions to
feedback, is presented to hospital management or the designated approval authority.
 Approval authority reviews the document for completeness, accuracy, alignment with hospital
goals, and compliance with organizational standards and policies.

5.5 Approval Signatures

 Upon satisfactory review and validation, approval signatures or endorsements are obtained
from the designated approval authority and relevant stakeholders.
 Approval signatures signify formal acceptance and commitment to the documented hospital
requirements and specifications.

5.6 Document Distribution

 Approved copies of the SRS document, including version control details and approval
signatures, are distributed to project team members, stakeholders, and relevant parties.
 Access controls and document repositories are managed to ensure authorized access and
visibility to approved versions of the document.

5.7 Document Retention and Updates

 Approved versions of the SRS document are retained securely as part of hospital
documentation and configuration management.
 Document updates or revisions during the project lifecycle follow established change
management procedures to maintain document accuracy and alignment with evolving hospital
requirements.
 LAB No.- 04
OBJECTIVE:

Construct ER diagram for the Hospital Management System project.

To construct an Entity-Relationship (ER) diagram for the Hospital Management System

project, we need to identify the main entities and their relationships. Based on the
requirements provided earlier and the ER diagram in the image, here’s a simplified ER
diagram:

Entities:

1. Patient
2. Doctor
3. Medical Record
4. Registration
5. Administration

Relationships:

1. Patient can have multiple Medical Records - one-to-many relationship.

2. Patient can have a Registration entry - one-to-one relationship.
3. Doctor can check multiple Patients - one-to-many relationship.
4. Doctor can fill in multiple Medical Records - one-to-many relationship.
5. Registration can set up multiple Medical Records - one-to-many relationship.
6. Medical Record can be recapped by Administration - one-to-one relationship.

Attributes:

 Patient: MR No (Primary Key), Name, Gender, Age, Notes

 Doctor: Employee ID (Primary Key), Name, Gender, Age, Specialist
 Medical Record: MR No (Foreign Key), Diagnosis, Drugs, Reference, ICD
 Registration: MR No (Primary Key), Date, Age, Poly, Assurance
 Administration: Letter No (Primary Key), Health Office, Report, Reception,
Delivery, Input, Endorsement

In this system:

 Patient contains details about the patients including their medical record number,
name, gender, age, and notes.
 Doctor holds the information about the doctors including their employee ID, name,
gender, age, and specialization.
 Medical Record includes details about patient diagnoses, prescribed drugs,
references, and ICD codes.
 Registration records the registration details of patients including the medical record
number, registration date, age, polyclinic information, and assurance details.
 Administration handles the administrative aspects like health office reporting,
reception, delivery, input, and endorsements.
 LAB No.- 05
OBJECTIVE:

Construct a use case diagram for the Hospital Management System project.

A Use Case Diagram for the Hospital Management System project can illustrate the various
interactions between actors (users) and the system. Based on the provided data flow diagram,
here’s how users interact with the Hospital Management System through various use cases:

Actors:

1. Receptionist
2. Staff/Clerk
3. In-house Doctors
4. Consultant Doctors
5. Patients
6. Finance Management System
7. Records System
8. Information System
Use Cases:

1. Admission:
o Receptionist handles patient admissions.
o Extends to bed allotment and undergoing operations.
2. Doctor Appointment:
o Patients can schedule appointments with doctors.
o Includes both in-house and consultant doctors.
3. Test Appointment:
o Patients can schedule medical tests.
4. Login:
o Staff, clerks, doctors, and consultants can log into the system.
5. Draw Salary:
o Staff and doctors can access their salary information.
6. Prescribed Test:
o Doctors can prescribe tests to patients.
7. Ward-wise Bed Status:
o Staff can check the status of beds in various wards.
8. Admission/Discharge Report:
o Generate reports on patient admissions and discharges.
9. Patient Payment Info:
o Manage patient payment information and processing.
10. Add Doctor/Staff:
o Administrative function to add new doctors and staff.
11. Delete Doctor/Staff:
o Administrative function to remove doctors and staff.
12. Edit Doctor/Staff:
o Administrative function to edit details of doctors and staff.
13. Bed Allotment:
o Assign beds to patients during admission.
14. Undergo Operation:
o Manage and schedule patient operations.

System Interactions:

1. Finance Management System:

o Handle income and expenditure related to patient payments and hospital
operations.
2. Records System:
o Maintain detailed patient records, including medical history and treatment
plans.
3. Information System:
o Provide detailed information on hospital resources, bed status, and generate
necessary reports.

This Use Case Diagram depicts how various actors, including patients, doctors, and
administrative staff, interact with the Hospital Management System through various use
cases. The system also interacts with external systems like the Finance Management System,
Records System, and Information System to ensure comprehensive management of hospital
operations.
 Lab No. - 06

Objective:
Draw Data Flow Diagram for Hospital Management project.

A Data Flow Diagram (DFD) illustrates the flow of data within a system, showing how data
is processed and transferred between different components. For the Hospital Management
System project, we can create a context-level DFD to represent the system at a high level. In
this diagram, we'll identify the main processes and data flows between them.

Hospital Management System - Level 1

The Level 1 DFD for the Hospital Management System demonstrates the primary processes
involved in the system and their interactions. The main entities include patients, staff/doctors,
and administrators, while the key processes are managing patients, assigning rooms/facilities,
assigning medicine, and managing staff/doctors. The system also interacts with various

databases such as patient database, staff database, and medicine database.

Main Components:
  Admin: Manages patient and staff/doctor information.
 Manage Patient: Handles patient information and diagnoses.
 Assign Room/Facility: Assigns facilities to patients based on their diagnosis.
 Assign Medicine: Manages the assignment of medicines to patients.
 Manage Staff/Doctor: Handles staff and doctor information and their assignments.

Databases:

 Patient Database: Stores patient information and diagnoses.

 Staff Database: Contains staff and doctor information.
 Medicine Database: Keeps track of available medicines and their assignments.

Hospital Management System - Level 2

The Level 2 DFD provides a more detailed view of the billing process within the Hospital
Management System. It includes in-patient and out-patient treatments, calculating billing,
generating reports, and cashier interactions.

Main Components:

 Staff/Doctor: Provides charges for in-patient and out-patient treatments and lab charges.
 In-Patient Treatment: Manages the treatment and billing for admitted patients.
 Out-Patient Treatment: Handles treatment and billing for non-admitted patients.
 Calculate Billing: Calculates the billing amounts based on treatments and lab charges.
 Generating Report: Prepares billing receipts and reports for patients.
 Cashier: Manages the final billing process and provides receipts to patients.

Databases:

 Billing Database: Stores all billing information, including health card amounts, and retrieves
data for generating reports.
 Lab No. - 07

Objective:
Draw a sequence diagram for the Hospital Management project.

A Sequence Diagram is a type of interaction diagram that illustrates the flow of messages or
interactions between objects or components within a system over time. It shows the sequence
of interactions between different components or objects in chronological order, allowing you
to visualize how they communicate with each other to achieve a particular functionality.

In software engineering, Sequence Diagrams are commonly used to:

1. Model the interactions between various components or objects in a system.

2. Visualize the order of messages exchanged between objects during the execution of a use case
or scenario.
3. Identify the dependencies and interactions between different parts of a system.
4. Aid in understanding the behavior and communication patterns within a system.
5. Design and document the system's architecture and functionality.

Hospital Management System - Sequence Diagram

The sequence diagram for the Hospital Management System shows the interactions between
an emergency patient, various departments, reception, doctors, nurses, and beds. It illustrates
the process of registering a patient, locating medical staff, and assigning a bed for treatment.
Sequence of Interactions:

1. Emergency Patient enters the emergency unit.

2. Department registers the patient and returns the patient's health number.
3. Department sends a message to Reception to locate a nurse.
4. Reception locates an available nurse and informs the department.
5. Department transforms and locates an available doctor.
6. Department locates an available nurse.
7. Department returns the result to Reception.
8. Reception proceeds to locate a bed.
9. Department manages the patient treatment or death.
10. Department handles cases where patients either recover or need to be transferred to another
hospital.
 Lab No. - 08

Objective:
Prepare a Gantt Chart for the Hospital Management project.

a Gantt chart for the Hospital Management System project, covering key phases and tasks.
The timeline is spread over several months to accommodate the complexity and iterative
nature of the Spiral Model.

Gantt Chart: Hospital Management System Project

Legend:

 W1, W2, ...: Week 1, Week 2, ...

Task/Phase Duration May Jun Jul Aug Sep Oct Nov Dec
Planning Phase 3 weeks W1 W2 W3
- Define project objectives 1 week W1
- Identify stakeholders 1 week W2
- Establish communication channels 1 week W3
Risk Analysis Phase 2 weeks W4 W5
- Identify potential risks 1 week W4
- Develop mitigation strategies 1 week W5
Prototyping Phase 4 weeks W6 W7 W8 W9
- Develop prototypes 2 weeks W6 W7
- Gather stakeholder feedback 2 weeks W8 W9
Engineering Phase 12 weeks W10 W11 W12 W13 W14 W15 W16 W17
- System design and architecture 2 weeks W10 W11
- Database schema design 2 weeks W12 W13
- Module development (patient management) 2 weeks W14 W15
- Module development (appointment scheduling) 2 weeks W16 W17
- Module development (medical record mgmt) 2 weeks W18 W19
- Module development (inventory mgmt) 2 weeks W20 W21
Evaluation Phase 8 weeks W22 W23 W24 W25 W26 W27 W28
- Testing and validation 4 weeks W22 W23 W24 W25
- User acceptance testing 2 weeks W26 W27
- Performance evaluation 2 weeks W28 W29
Deployment and Maintenance 4 weeks W30 W31 W32 W33
- Deployment to production environment 2 weeks W30 W31
- Training and support 2 weeks W32 W33
- Ongoing maintenance and updates Ongoing

Explanation:

1. Planning Phase (3 weeks):

  Define project objectives, identify stakeholders, and establish communication
channels.

2. Risk Analysis Phase (2 weeks):

 Identify potential risks and develop mitigation strategies.

3. Prototyping Phase (4 weeks):

 Develop initial prototypes and gather feedback from stakeholders.

4. Engineering Phase (12 weeks):

 System design, database schema design, and incremental development of

various modules.

5. Evaluation Phase (8 weeks):

 Conduct testing, validation, user acceptance testing, and performance

evaluation.

6. Deployment and Maintenance (4 weeks):

 Deploy the system to the production environment, provide training and

support, and start ongoing maintenance.

This Gantt chart provides a high-level view of the project timeline, with specific tasks and
durations mapped out over several months. Adjustments can be made based on project
progress and any unforeseen challenges.