This document provides an overview of an e-Hospital project that aims to automate hospital activities. The key points are: - The project will integrate the hospital management system (HMS) with the government's online registration system portal. This will allow for online patient registration, appointments, billing, staff management, and more. - The system is being developed as part of India's Digital India initiative to connect hospitals across the country. Patients will be able to use their Aadhaar ID to register online and access services at any government hospital. - The project manager is responsible for defining the scope, creating schedules, estimating costs, setting goals, managing time and budgets, and overseeing implementation and monitoring.

1. e-HOSPITAL
Group 4
MNG690 Software Project Management

2. TABLE OF CONTENTS
◉ Project Scope
◉ Usage for Digital India
◉ PM Responsibilities
◉ Identifying Life Cycle Model
◉ SDLC Phases (Testing, Implementation missing)
◉ Project Schedule & Milestones (missing)
◉ Cost Estimation (missing)
◉ Cost & Resource Optimization
◉ Identifying project risks

3. PROJECT DESCRIPTION

4. AIMS & OBJECTIVIES
Main aim designated for the project - Automation of all the activities of the hospital to make
them happen faster
PROJECT SCOPE
◉ Integrating HMS with govt.’s ORS portal
◉ Patient details & registration
◉ Appointment scheduling in advance
◉ Billing and payments (cash, CC, insurance)
◉ Pharmaceutical equipment Management
◉ Staff management (Work Roster,
Availability, Scheduling, etc.)
◉ Management functions (Report generation,
Accounting, etc.)
◉ System administration
◉ Resource allocation (booking rooms,
operating theatres, etc.)
◉ Comprehensive database with past
audio/visual consultations
◉ Web interface (proposed for future)

5. USAGE FOR DIGITAL INDIA PORTFOLIO
As part of Digital India movement, e-Hospital, which essentially is a framework which will
connect all hospitals across India, was launched.
Any person who wants an appointment with hospital will need to go through Online
Registration System (ORS) which is Aadhaar based.
 But in order to be a part of this movement, Hospitals need to have a very rigid Hospital
Management Information System (HMIS) in place
 This is where we believe our project can be of great use for any of the hospitals willing to
register for this great initiative
With e-Hospital, you can get an OPD appointment, lab reports and blood availability in any
government hospital and it can be done completely online.

6. PROJECT MANAGER - RESPONSIBILITIES
• Scope: Project manager must clearly define the scope of the project & answer questions like, who is the
customer? What need will the software satisfy? How will it be beneficial to others?
• Activity Schedules: He must first list out the jobs to be done and then allot specific jobs to team members.
Identifying and specifying the critical activities of the project and then equally delegating the roles to each
member of the team
• Gantt Chart: Once the activities and their different tasks have been outlined, he must list all the activities in a
Gantt chart and allot time frames for their completion. This always helps in deciding deadlines for the various
activities and also in refining the project plan as it moves along
• Setting Goals - He must set measurable goals that should define the overall project’s objective. SMART goals
• Time Management - Time estimation for the various activities is of major significance as it helps set the daily
priorities of each team member. A project manager has to properly time all the activities for the completion of
the project and also prepare for any delays in any of the activities
• Budget Allocation and Cost Estimates -Project manager must assign budgets to the various activities and
make any cost considerations that there might be
• Implementation and Monitoring - Executing the plan of action and ensuring that it is monitored along the way
is a key responsibility of his

7. SDLC – WATERFALL MODEL

8. JUSTIFICATION – USING WATERFALL MODEL
At every phase there is provision of verification & validation, correction of errors and
inconsistencies.
◉ All requirements are gathered only once as done in
this Hospital Management System (HMS)
◉ Every stage begins when previous phase is finished.
According to this model we have prepared all stages as
analysis, designing, coding, and then finally
development
◉ This project consists of a linear set of distinct phases
◉ Every phase has well defined entry and exit criteria,
which is available in our HMS
◉ Easy to understand and cheap
◉ It provides proper feedback, to minimize the work
again
◉ This is achieved through the process of review and
documentation
◉ It is simple, old and most widely used process model
for software development
◉ Easy to explain to the users
◉ Stages and activities are well defined
◉ Verification at each stages ensures early detection of
errors/misunderstandings

9. WATERFALL MODEL
For the development of any
System, we should have to
follow the well-scheduled
path, which is known as
model.
Although there are many life
cycle models nowadays, but
according to our project and
user convenience waterfall
Model has been selected.

10. SDLC PHASES

11. PLANNING & REQUIREMENT
Requirement Analysis
In the current Hospital Management System the
person at the desk needs to keep a register to record
the details of each patient while admitting it in the
hospital
◉ Various problems related to the physical effort in
maintaining, deleting and updating the register
◉ Searching technique of any patient very poor as
manual linear search being used
◉ Admitting of patients was just admitting them in
the respective rooms without any logic or
categorization,
◉ Thus patients having similar diseases were being
admitted in different rooms
◉ Users – 3 kinds of users for proposed system
(Admin, Doctors & Nurses)
◉ Limitations – Risks applicable for billing
payment by cards through gateway of banks
◉ System should be compatible to different OS
and with variety of web browsers
◉ Assumptions: Patients provide insurance
details on registering
Patient medical history can be viewed by
doctors upon patient’s approval
Staff have basic computer operating skills
◉ Requirements – Intel processor or equivalent,
RAM 256 MB or higher, HDD 4gb, Win 7 or higher
Project Planning

12. PLANNING & REQUIREMENT
Feasibility Study
The objective of a feasibility study is not to solve the problem but To predict (on the basis of system analysis &
problem definition) that if it does the kind Of work expected on it, in a reasonable period of elapsed time, &
consistent with the financial and processing objective and needs of the organization
◉ Operational - Since, the System is highly user friendly, it is acceptable to the organization and other users as
well. So we can say it is operationally feasible
◉ Technical - This evaluation determines whether the technology needed for the proposed system is available
or not (Front end & Back end selection). Based on our requirement, we are able to choose VB6.0 & MS Access for
each of them respectively
◉ Economic - This HMS for management of Life Line Charitable Hospital is a simple project and requires the
software’s like Visual Basic and SQL. This does not require any extra costs other than the cost of the software
used for development and the charges of the developer. So we can say that it is economically feasible.
◉ Social - The determination typically examines the probability of the project being accepted by the group
directly affected by the proposed system change.

13. DESIGN
Design Objective
The term design describes a final System and the process by which it is developed .The first step is “to determine
how the output is to be produced and in what format”.
◉ Architecture – Makes use of Top-Down and Down-Top design for different activities
◉ Data Dictionary - A data dictionary is a structured repository of data about data. It is a set of rigorous
definitions of all DFD data elements and data structures. Different information to be stored in the database
(Aadhar ID, Name, Sex, Age, DOB, Address, etc)
During implementation, it serves as a common base against which programmers who are working on the
System compare their date descriptions. Also control information maintained for each data element is cross-
referenced in the data dictionary.
 Component Modules – There are 15 Major Modules (Reception Management, Patient Registration (OPD &
Indoor), Out Patient Management, OPD Billing, Investigations Reporting (Pathology &
Imaging), Indoor Patient Management, Indoor Billing Store, Pharmacy, Financial
Accounting, Payroll, MRD Management, Online Diagnostic Reporting,
HR Management)

14. DEVELOPMENT
Identify the requirements of each and every module. For example:
◉ Reception Management – Patient Related Enquires, Bed Allotment, Admission Details, Payment Details,
Discharge Details, Doctor Related Enquires, Availability Details, Appointment Schedules, Operation Schedules
Patient Appointment Registration - The following information is required for the registration of Patient:
◉ Patient Details like Name, Age, Sex, Address, Contact
◉ Number, Nationality, etc.
◉ Referring Source and Sponsorship / Penal Details
◉ Department & Consultant to be visited
Out Patient Management: After the registration the patient comes to the consultation chamber, where the
consultant records his history, diagnose and prescribe medicines & investigation. The Consultant note down
the following details on Patients OPD Card:
◉ Complaints
◉ History
◉ Diagnosis
◉ Investigation
◉ Medicines
◉ Advice
◉ Next Visit

15. DEVELOPMENT
Billing: Indoor billing module has a supervisory role.
The entries for billing are automatically transferred to the patient bill by the respective departments, which
provide the service. Salient Features:
◉ Collection of Payment by Cash/Credit Card/ DD or Cheque.
◉ Receipts, refunds, Credit Note Generation.
◉ Provisional & Final Bills.
◉ Department wise services availed.
◉ Scrutinizing the Deposit Exhaust list and sending requisition for deposit.
◉ Automatic scrutiny of the credit limit available to the patient.
◉ Provision to bill a patient against another account (LIC account/company account/Donors account etc.)
◉ Additional payment for Ambulance/attendants at discharge if required
Medical Record data (MRD) Management: Patient’s Medical record data is critical for the analysis and
research purposes. Salient Features of this Module are:
◉ Statistical reports based on diagnosis, age, sex, geographical areas and other parameters.
◉ Discharge Summary with details of test reports.
◉ Reports on departments, consultants, etc.
◉ Birth & Death Records with full details.

16. Cost and Resource Optimization
◉Why Cost Savings ?
 Competitiveness
 Profit
◉ Types of Cost Savings ?
 Cost Reduction
 Cost Avoidance
 Profit Improvement

17. Cost and Resource Optimization
◉Selection Criteria for Cost Savings ?
 Simplifying the software for reduced components
 A system has reached a level maturity where function partitioning can be reworked
 A program is experiencing operational, schedule, or safety issues
 There is a need to develop and/or optimize a process
◉ Process Based Criteria (Short Range Issues)
 Inadequate development staff
 Too many developers
 Uncontrolled and unmanageable process
 Unskilled project managers

18. Cost and Resource Optimization
◉ Cost Savings Approach
 Formulation
 Information
 Function Analysis
 Inspiration
 Evaluation
 Development
 Presentation
 Implementation
 Preparation phase

19. Risk Identification
Phase 1
Activity Risk Factors Description
Requirement
Validation
Inadequate estimation of project time,
cost, scope and resources
Managing project scope is the most
important task, without which the
subsequent tasks of allocation, cost
estimation etc ..fails
Requirement
Analysis &
Definition
Requirement
gathering
Unclear requirements, incomplete,
inaccurate, Gold plating
Requirements should be clear that all
stakeholders in developing & testing
have complete information. Otherwise
may lead to complete overhaul of
project and gold plating.
Requirement
Analysis
Non-verifiable requirements, Infeasible
requirements, Inconsistent
All requirements should be verified for
its origin of source, feasibility and
verified for its implementation.
Requirement
Validation &
Documentation
Misunderstanding domain specific
terminology, Inconsistent requirement
data
Validating requirements aims to
ensure that the stated requirements
actually define what the users want
and improper documentation may lead
to huge risks

20. Risk Identification
Phase 2
Activity Risk Factors Description
Examining
Requirement
document
Requirement document not clear for
developers
Developers should be involved in
requirement analysis and definition
phase, otherwise lead to gaps and
failure in developing.
Design Phase
Architectural
design method
Improper Architectural Design method
choice
If a wrong choice was made, then the
system implementation will not be
completed successfully and problems
in the integration may arise later
Programming
Language
Improper programming language The wrong choice of programming
language may not support the applied
architectural design method and
reduce profitability, affect
maintenance
Verifying &
Specifying
designing
Difficulties in verifying design
requirements, incorrect design,
Difficulties in allocating functions to
component
Design must be verified against
requirements and developer should be
not find it difficult in decomposing it
further
Documentation
Design
Incomplete design document,
Inconsistent documentation
Design document should be detailed
enough to allow programmers to work
independently and should be not have
duplication work

21. Risk Identification
Phase 3
Activity Risk Factors Description
Coding Programming language does not
support architectural design, Complex,
ambiguous, inconsistent code
If the programming language was not
selected early in the design phase,
then implementation will be blocked
Implementation
and Unit testing
Unit testing High fault rate in newly designed
components, testing is monotonous ,
Proper documentation of test cases
It is highly likely to find many errors
when component is newly developed
and tested for first time. Testing cases
have to be documented and
maintained

22. Phase 4 Activity Risk Description
Integration &
system
testing
Integration
Integrate wrong
component
Multiple versions for the same component may exist. Chances of
integrating wrong component.
Integration in wrong order Wrong ordering of integration will result in bugs and errors. If not
done sequentially, errors would be difficult to find.
Integration
Testing
Emergence of bugs Bugs generated due to improper integration
Desired functionality not
obtained
Mismatch generated while combining modules and components
System
Testing
Inexperienced team Unqualified testers might destroy the process and misuse the tools
and resources
Limited resources Limited time, budget and resource can hinder testing process
Unable to test in real
environment
Delivery, installation on time and budget constraints makes it
possible to test in real environment
Testing team cannot
cope with changes
Customer needs change continuously and testers cannot cope with
such changes in requirements
Risk Identification

23. Phase 5 Activity Risk Description
Operation
and
Maintenance
Acceptance
Testing
Missing capabilities End users might find some capabilities missing
Unable to handle data During real environment operation, the system might be
overloaded with large amounts of data which it cannot handle
Maintenanc
e
Budget constraint Most of the activities are repeating and hence it might exceed the
allocated budget.
Unable to reproduce
problem
End users report problems and software engineer have to
reproduce it in order to fix it.
Installation
Installation issues Inexperienced deployers, lack of adequate knowledge and complex
systems can lead to incorrect installation
Environment change Change in environment can hinder the installation process
Common to
all Phases
Continually changing
requirement
Requirements change over the SDLC and if this is not successfully
mitigated, then time and budget will overrun
Time contention In order to deliver on time some functionalities may be discarded
Team turnover Team members might leave the team in between thereby creating
resource crunch
Miscommunication Lack of proper communication between customer, managers and
developers result in budget and time overrun.
Risk Identification

24. THANKS!