Final Project Documentation

ARBA MINCH UNIVERSITY
ARBA MINCH INSTITUTE OF TECHNOLOGY

FACULTY OF COMPUTING AND SOFTWARE ENGINEERING
Title: - Online Health Insurance Information Management
System in Arba Minch Branch
Prepared by:-
Name ID No_
ASHENAFI ENDALE RAMIT/1582/10
CHERA FIRISA RAMIT/1613/10
SOLOMON BELEW RAMIT/1833/10
ABDURAMAN MOHAMED RAMIT/1549/10
Under supervision of: Mr. Debebe.

This project is submitted to department of computer science, faculty of computing and software
engineering, AMIT, Arba Minch University, in Partial fulfilment for the requirement of the
Degree of Bachelor Science in (Computer Science).
Acknowledgement
First of all we would like to thank the almighty God helped us in doing our project by giving
his peace for us and for the campus. Next we would like to express our deepest gratitude to our
advisor Debebe who supported us in different activities by contributing in the work of project
by advising the best way to do our project documentation to make the project best as much as
they can.
II | P a g e
Abstract
The health insurance service system is one of the widely used and highly known service system
in the world that provide health service in low cost or no cost. Now a days technologies are
highly accelerating throughout the world and have shown significant and inevitable revolution
or change in different sectors. However, in current circumstances, the Ethiopian health
insurance service system is facing numerous problems like the redundancy of data, losing
customer information and time wastage generally this happens when managing data’s
manually. The ultimate aim of this project (online health insurance information management
system) is to automate and advance the Ethiopian health insurance service system by
developing a state of the art e- health insurance system. The proposed system is dedicated to
advance the health insurance service by providing integrated, enhanced, and supplementary
services through the virtue of the technologies. Under this system customers can gain health
insurance information and services via online quickly and comfortably. The proposed system
has the capabilities to store information about the customer and their transaction made. The
main benefits of this project is for making the health insurance information management to
access more easily, faster systematic as comparing to a manual system that is being used now
because it takes longer time to access and it will be user friendly. In order to prepare this project
different method of data collection such as observation, interview and document analysis we
will use for gathering data. The System will be created by combination of server side script
such as PHP with Apache HTTP Server, user side script such as HTML, CSS. JS and Database
build using MYSQ
III | P a g e
Table of Contents
Contents
Acknowledgement ................................................................................................................................. II
Table of Contents .................................................................................................................................. IV
List of Figures ....................................................................................................................................... VI
List of Tables .......................................................................................................................................VII
Abbreviations ..................................................................................................................................... VIII
Chapter One ............................................................................................................................................ 1
1. Introduction ......................................................................................................................................... 1
1.1. Introduction .................................................................................................................................. 1
1.2. Background of the Organization .................................................................................................. 1
1.2.1. Vision of Organization .......................................................................................................... 1
1.2.2. Mission of Organization: ...................................................................................................... 1
1.4. Team Composition ....................................................................................................................... 3
1.5. Schedule (Work Plan) .................................................................................................................. 3
1.6. Statement of the Problem ............................................................................................................. 4
1.7. Objectives .................................................................................................................................... 4
1.7.1. General Objectives ................................................................................................................ 4
1.7.2. Specific Objectives ............................................................................................................... 4
1.8. Scope of the Project ..................................................................................................................... 5
1.9. Feasibility of the Project .............................................................................................................. 5
1.9.1. Technical Feasibility ............................................................................................................. 5
1.9.2. Economic Feasibility............................................................................................................. 5
1.9.3. Operational Feasibility .......................................................................................................... 5
1.10. Significance of the Project ......................................................................................................... 5
1.11. Methodology .............................................................................................................................. 6
1.11.1 Data Collection Method ....................................................................................................... 6
1.11.2. Analysis and Design Approach ........................................................................................... 7
1.11.3. Development Tools ............................................................................................................. 8
1.11.4. Testing Procedure ............................................................................................................... 8
1.11.5. Budget ................................................................................................................................. 9
1.12. Constraints and Assumption .................................................................................................... 10
1.12.1. Constraints ........................................................................................................................ 10
1.12.2. Assumption ....................................................................................................................... 10
Chapter Two.......................................................................................................................................... 11
2. Description of the Existing System ................................................................................................... 11
2.1. Introductions of the Existing System ......................................................................................... 11
2.2. Players in the Existing System ................................................................................................... 11
2.3. Major Activities in Existing System .......................................................................................... 11
2.4. Business Rules ........................................................................................................................... 12
2.5. Report Generated in the Existing System .................................................................................. 12
IV | P a g e
2.6. Forms and Other Documents of the Existing Systems ............................................................... 12
2.7. Bottlenecks of the Existing System ........................................................................................... 15
2.8. Practices to be Preserved ........................................................................................................... 15
2.9. Proposed Solution ...................................................................................................................... 15
2.10. Requirements of the Proposed System..................................................................................... 15
2.10.1. Functional Requirements .................................................................................................. 15
2.10.2. Nonfunctional Requirements ............................................................................................ 17
Chapter Three........................................................................................................................................ 19
3. System Analysis ................................................................................................................................ 19
3.1. Introduction .................................................................................................................................... 19
3.2. System Requirement Specifications (SRS) .................................................................................... 19
3.2.1 Use Case Diagrams .............................................................................................................. 19
3.2.2. Use Case Description .......................................................................................................... 24
3.2.3. Sequence Diagrams ............................................................................................................. 32
3.2.4. Activity Diagram................................................................................................................. 39
3.2.5. Analysis Level Class Diagram ............................................................................................ 44
3.2.6. User Interface Prototyping .................................................................................................. 47
3.2.7. Supplementary Specification .............................................................................................. 47
References ............................................................................................................................................. 49
V|Page
List of Figures
Figure 2. 1: Customer registration forms of existing system ................................................... 12
Figure 2. 2: Report generating forms of the existing system ................................................... 13
Figure 2. 3: Report generating forms of the existing system ................................................... 14
Figure 3. 1: Use case diagram for customer ............................................................................ 20
Figure 3. 2: Use case diagram for hospital health insurance officer ........................................ 20
Figure 3. 3: Use case for administrator .................................................................................... 21
Figure 3. 4: Use case diagram for hospital card officer ........................................................... 21
Figure 3. 5: Use case for manager ........................................................................................... 22
Figure 3. 6: Use case for the system ........................................................................................ 23
Figure 3. 7: Sequence diagram for user registration ................................................................ 33
Figure 3. 8: Sequence diagram for login .................................................................................. 34
Figure 3. 9: Sequence diagram for update information ........................................................... 35
Figure 3. 10: Sequence diagram for payment .......................................................................... 36
Figure 3. 11: Sequence diagram for managing account ........................................................... 37
Figure 3. 12: Sequence diagram for sending notification ........................................................ 38
Figure 3. 13: Sequence diagram for complaint ........................................................................ 39
Figure 3. 14: Activity diagram for customer registration ........................................................ 40
Figure 3. 15: Activity diagram for customer payment ............................................................. 41
Figure 3. 16: Activity diagram for manage user account......................................................... 42
Figure 3. 17: Activity diagram for send complaint .................................................................. 43
Figure 3. 18: Activity diagram for update customer information ............................................ 44
Figure 3. 19: Analysis level class diagram .............................................................................. 46
Figure 3. 20: User interface prototype diagram ....................................................................... 47
VI | P a g e
List of Tables
Table 1. 1: Team composition ................................................................................................... 3
Table 1. 2: Work break down .................................................................................................... 3
Table 1. 3: Hardware tools ......................................................................................................... 8
Table 1. 4: Software tools .......................................................................................................... 8
Table 1. 5: Cost estimation ........................................................................................................ 9
Table 3. 1: Registration use case description ........................................................................... 24
Table 3. 2: User login use case description.............................................................................. 24
Table 3. 3: Payment use case description ................................................................................ 25
Table 3. 4: Generating certificate use case description............................................................ 26
Table 3. 5: Manage account use case description .................................................................... 26
Table 3. 6: Send notification use case description ................................................................... 27
Table 3. 7: Send Complaint use case description .................................................................... 27
Table 3. 8: View notification use case description .................................................................. 28
Table 3. 9: View compliant use case description ..................................................................... 28
Table 3. 10: View payment use case description ..................................................................... 29
Table 3. 11: Edit profile use case description .......................................................................... 29
Table 3. 12: View customer information use case description ................................................ 29
Table 3. 13: Approve certificate use case description ............................................................. 30
Table 3. 14: View certificate use case description ................................................................... 31
Table 3. 15: Request payment use case description ................................................................. 31
VII | P a g e
Abbreviations
Business Rule………………………………………………….BR
Cascading Style Sheet…………………………………………CSS
Central processing unit……….……………………………….CPU
Compact Disk......................................………………………..CD
Identification…………………………………………….…….ID
Hard Drive Disk……………………………………...….....…HDD
Health Insurance………………………………………………HI
Hospital Health Insurance Officer…………………………….HHIO
Hypertext Markup Language……………………….…………HTML
Hypertext Transfer Protocol………………………….……….HTTP
Message Digest Algorithm Five……………………….…….. MD5
My Structured Query Language………………………..……..MySQL
Preprocessor Hypertext ……………………………….………PHP
System Requirement Specifications……………………………SRS
Use Case………………………………………………..……..UC
User Interface………….………………………………………UI
Unified Modeling Language ……………………………..………UML
VIII | P a g e
Chapter One
1. Introduction
1.1. Introduction
Insurance agency is one of the well-known agency in Ethiopia that provide different services
for communities. As we know there are different types of insurance agency in Ethiopia from
those types health insurance is the one that’s well known. Health insurance is the organization
that’s founded for the aim of providing health services at the time of peoples get health
problem. It is a type of insurance coverage that covers the cost of an insured individual's
medical and surgical expenses. The "insured" is the owner of the health insurance policy; the
person with the health insurance coverage. Enrolment is done in a household rather than
individual basis. Health insurance is the system where individuals or households pay small
contributions or prepayments to get health services at the time of illness and to protect them
from catastrophic health expenditures. In other words, health insurance is a prepayment system
where small contributions are pooled together to insure citizens’ access to health services by
avoiding financial barrier. (አቶ አሰፋ ይርጋለም, 2009)
1.2. Background of the Organization
As we know health insurance is one of new established institute in Ethiopia. It was established
its branch in to different regional state of Ethiopia from those Arba Minch health insurance
agency branch, is one of branch which is established in 2007 E.C. It is found in Arba Minch
city around gimash siecha in front of mosque. The establishment of these institutes is expected
to give opportunity for the poor people to get equal health treatment with other people and give
much to the ongoing development of country in general. This system is still operates all
functions manually like registering, searching, payment, editing, adding details of information
of the insured members of the institution. So this manual operation face different types of
problems like it takes time for the operation, ineffective file, data inconsistent, data not secure,
etc. This is the general idea current health insurance agency operation and information
management.
1.2.1. Vision of Organization: To see all citizens of the country are beneficiaries of an equitable
and sustainable health insurance system by 2025.
1.2.2. Mission of Organization: Establish an efficient and effective health insurance system
that collect and administer contributions from members, and ensure provision (supplying) of
quality health services to all citizens in a sustainable way.
Online health insurance information management system 1

1.3. Background of the Project
Currently, most people are having familiarity with information technology products which are
computer and computer based applications. Many organizations and individuals have their own
computer to facilitate day to day activity. These computers are functional when they corporate
with software and they make life to be easy. Technology leads to the organizations and people
to start their own contribution in hardware and software development. After the development
of the computer people needs to make a link for those computers in order to communicate. [
(bethsda, 2017)] The same that our university include industrial project in the curriculum in
order to the students implement and develop a project that to be a solution for the community
problem and organization related to their knowledge and skill they get during their study.
Information technology is very important for the health center. For example reduce cost that is
lost in paper. Due to this we agree to develop an online Health insurance information
management system for Arba Minch branch. Health insurance is online system where
individuals or households pay small contributions or prepayments to get health services at the
time of illness and to protect them from catastrophic health expenditures. In other words, health
insurance is a prepayment system where small contributions are pooled together to insure
citizens’ access to health services by avoiding financial barrier. (kaplan, 2016) Online health
insurance information management System will be developed to enhance the operation of
health insurance system. It is a type of insurance coverage that covers the cost of an insured
individual's medical and surgical expenses. The "insured" is the owner of the health insurance
policy; the person with the health insurance coverage. In health insurance agency, the
customers who want member in health insurance will be registered and pay insurance payment
manually by going to the health insurance office. It is so difficult to search and update the
customer’s information from the paper document. Due to these problems we are initiated to do
on health insurance information management system for Arba Minch city and the main reason
that we are going to do is solve the problems of health insurance by changing those problems
in to computerized task.

1.4. Team Composition
Table 1. 1: Team composition
Project Online Health Insurance Information Management System

title
Prepared S.no Student name Id_ no Email/mobile Responsibility
by:- 1 Ashenafi Endale 1582/10 [email protected] Coder and
designer
2 Chera Firisa 1613/10 [email protected] Data collector
m and drawer of
diagrams
3 Solomon Belew 1833/10 [email protected] Editor and
drawer
4 Abdurhaman 1549/10 [email protected] Tester and
Adem drawer
Date Wednesday, July 28, 2021
Advisor Mr. Debebe .
1.5. Schedule (Work Plan)

The Proposed project study is assumed will be completed in three months (90 days) and will
be carried out according to the following time table.
Table 1. 2: Work break down
Activities Time
June July August
01- 16-30 01-10 11-15 16-25 26-06 07-20 21-30
15
Problem identification
and title selection
Proposal
Requirement analysis
Documentation
Design analysis
Implementation
Testing

1.6. Statement of the Problem
In currently health insurance agency record customers in a paper based manner. If there is need
of updating information such as if there is a new information updating is performed in a paper.
Finding list of a customer is difficult. When they want to get a treatment they must use their
ID card. The ID card is needed for every all treatments. The existing system has some problems
that are not solved by now some of those are:-
 Lack of immediate information retrievals: it is very difficult to retrieve and to find
particular information like to find out about the customer information. This result in
wastage of time.
 Lack of immediate information storage: the information generated by various
transaction time takes.
 Human energy loss.
 Lack of fast updating: various changes to information like customer information are
difficult to make as paper work is involved.
 No fast communication between different employees in health insurance agency.
 Lack of reliability because of manual work.
 There is redundancy of data.
1.7. Objectives
1.7.1. General Objectives
The general objective of this project is to develop online health insurance information management
system for Arba Minch city.
1.7.2. Specific Objectives
Specific objectives are objectives that used to achieve specified general objective. The
following are specific objectives.
 Requirement analysis of the existing system with respect to functional and
nonfunctional requirement.
 To develop a user-friendly system to manage customer’s information
 To design database to store the customers information.
 To design new system based on the requirement analysis of the existing system.
 To develop and implementing the new system.
 To develop flexible and easily accessible system.
 To deploy the system after the system is tested.

1.8. Scope of the Project
The scope this project is providing customers an online health insurance information and
service such as online registration, online payment, generate certificate and issue id cards for
customers and manage the customer information properly.
Feasibility study is used to investigate the proposed system in multiple dimensions. It is used
to indicate whether the system is feasible or not.
1.9. Feasibility of the Project

1.9.1. Technical Feasibility
The system performs all operations to achieve the specified objective, User friendly and
interactive with the environment and the system will perform all operation that the organization
runs. And it will not have any difficulty or procedures to perform the operation of the system.
So the project is operational feasible.
1.9.2. Economic Feasibility
Economic feasibility is the process of identifying the financial benefits and costs associated
with the project being developed. So the project is economically feasible because the project
reduce the cost of the resources. But Economic Feasibility is expressed as cost- benefit analysis.
Costs:-our system use new technology and have centralized database cannot need more
resources. It require minimum amount of cost.
1.9.3. Operational Feasibility
The system performs all operations to achieve the specified objective, User friendly and
interactive with the environment and the system will perform all operation that the organization
runs. And it will not have any difficulty or procedures to perform the operation of the system.
So the project is operational feasible.
1.9.4. Schedule Feasibility
The system after development may give efficient and effective services in short period of time.
And also the tasks may be scheduled for effective use of the system. The project will be finish
at the schedule time. So the project is Schedule feasible.
1.10. Significance of the Project
After successfully implementing, the proposed system will be expected reliable, easy, fast and
consistent and plays a crucial role for the agency and its customers. Some of significance of
proposed system is listed as follow:
 The system will speed up the task in the health insurance agency.
 The system will reduce time, cost and redundancy of information or data.

 Improving efficiency, control and security of existing system.
 Avoiding data loss.
 It will increase security of the system
Some Beneficiary’s that share the significance of the proposed system will be:-
For customers:-
 To minimize time needed to register and update their information.
 Customer’s information is managed properly.
 Customers can send complain freely.
 Save their time and Reduce workloads.
 Reduce complexity.
 Customer can perform online payment.
For the agency:-
 To reduce the wastage of time needed to perform different tasks.
 It reduces work load for the employees that work in the agency.
 Manage the customer information properly.
 Increase competency.
 To save time it needs to deal with customer information.
For Developer Team:-
 Add new knowledge.
 Get problem solving skill.
 Give great satisfaction
1.11. Methodology
To achieve the main functionality of the proposed system this project follows an object oriented
approach. Object oriented programming is a process of planning a system of interacting objects
for the purpose of solving a software problem. Use it since it is easy to maintain and modify,
uses the concept of classes, inheritance, methods and objects. It is also easy to map real
problems with the solution.
1.11.1. Data Collection Method
Data collection is the major activity to analyze the current system or to get information about
existing system and to develop the new or proposed system. Data for developing the new
system obtained from different sources. Such as from system users, from documents used in
the agency office and from manuals. The followings are data collection methods:

 Interview: -We are orally discussed and interview with some employees of the health
insurance agency for necessary information’s. This information helps us to understand
the current system and also to identify the problems occur in the existing system. So,
we analyze information’s of the agency and obtain some basic concepts on how the
customers are becoming a member in the current system.
 Document Analysis:-To understand the existing system, we collect more information
by referring different manuals about the general information about the health insurance
agency.
 Observation: -We gather additional data by observing the actual work being done by
agency employees.
1.11.2. Analysis and Design Approach
Among the different available methods using object oriented methods for the analysis and
design of our system. It improves the communication among customers, analyzers, designers
and programmers. It increases consistency among analyzer, designer, implementation and
testing. It also allows the reusability of the code which will help to enhance the project in the
future. To develop this system Iterative model system development methodology is usable.
In the Iterative model, iterative process starts with a simple implementation of a small set of
the software requirements and iteratively enhances the evolving versions until the complete
system is implemented and ready to be deployed.
An iterative life cycle model does not attempt to start with a full specification of requirements.
Instead, development begins by specifying and implementing just part of the software, which
is then reviewed to identify further requirements. This process is then repeated, producing a
new version of the software at the end of each iteration of the model.
An iterative approach is preferred for the following advantages:
 Parallel development can be planned.
 Less costly to change the scope/requirements.
 Testing and debugging during smaller iteration is easy.
 Risks are identified and resolved during iteration; and each iteration is an easily
managed milestone.
 It supports changing requirements.
 During the life cycle, software is produced early which facilitates customer evaluation
and feedback.

1.11.3. Development Tools
 Hardware Tools
The hardware tools that we will use in our project are listed below the table with their
functionality.
Table 1. 3: Hardware tools
No Name Function of hardware

1 Personal Almost all tasks of our project are performed on
computer(pc) computer.
2 Flash disk Required for data movement to store & transfer data from
one PC to another PC.
3 Disks (CD,DVD) Necessary for the movement, backup and recovery
mechanism of relevant data.
4 Paper and pen For writing all necessary documentations associated with
the project.
 Software Tools
Table 1. 4: Software tools
No Name Function of software

1 Window 10 operating It is used for the system since it is readily
system available in laboratories.
2 MS word 2013 For documenting the corresponding deliverables
associated with the project.
3 Notepad++ Working area used for writing the code.
4 Edraw max 9.3 Software used for drawing UML diagrams.
5 PHP Language used for doing project.
6 MySQLI Software used for creating the project database.
7 Xampp Server Create a local web server for testing and
deployment purposes.
1.11.4. Testing Procedure

Basically there are many ways of testing methodology, that we have been use in our project
are the following.
 Unit testing: -Unit testing allows us to focus on smaller units of the system. It makes
easier to pinpoint and correct faults. Unit testing is important for maintaining
application quality assurance. The primary goal of unit testing is to take the smallest
piece of testable software in the application, isolate it from the remainder of the code,
and determine whether it behaves exactly as it is expected. In unit testing we try to

test every unit of the system as it is finished. This helps us to know the error before
going to integration testing.
 Integration Testing:-After testing two or more we try to test integration of those units
together. This will help us to know which unit is not well integrated. And also it is
useful to notice not jump to the next without correcting it. Finally, this helps in system
testing.
 System testing: -A system testing includes a full-fledged implementation scenario of
the software development. This is a phase, which highlights on the operational bugs
and the software checklist, which are removed through the process of debugging. The
final test we left after finishing unit and integration testing is system testing. It tends
to affirm the end-to-end quality of the entire system and conducted to check that the
system meets its functional and non-functional requirements.
1.11.5. Budget
Budget is the money required to complete the proposed project for different activities held in
the proposed study. So, for a time being the proposed project is requiring a total of fifteen
thousand and five hundred (15500 ETB) birr only to accomplish this proposed study and the
specific budget needed for each particular activity is mentioned in the table below.
Table 1. 5: Cost estimation
No Item to be budgeted Quantity Price in birr(ETB)

1 Computer 1 15000 birr
2 Flash (8 gb) 1 190 birr
3 Paper 1 packet 200 birr
4 Printing and binding 2 copies 100 birr
5 Ms word 2013 1 Free
6 Xamp server 1 Free
7 Notepad++ 1 Free
8 Window 10 1 free
9 Transportation 3 times 60 birr
Total 15550 birr

1.12. Constraints and Assumption
1.12.1. Constraints
This proposed online health insurance management system is fully dependent on electricity
because, it can’t perform any task (preparing bill to customer, register and searching customer
information) in the health insurance because the system is computerized. It cannot perform
online transaction; it needs internet connection in order to perform the online activity in the
system.
1.12.2. Assumption
In order to use this automated online health insurance management system, every user must
have basic skill to use computer and some knowledge on how to use the computer. Hospitals
should be honesty for the health insurance agency.

Chapter Two
2. Description of the Existing System
2.1. Introductions of the Existing System
The existing system of the health insurance is working manually. This approach is not precise,
unreliable and sometimes it is biased and also this service it can be provided manual based.
The current existing system generally work on manually this lead to some difficulty to get
reliable health insurance information and also some service. So we are initiated to develop the
new web based system, to solve the weakness of the current existing system. This document
will discuss details of the requirement analysis and overall description and Work flow of the
existing system. The requirement of the proposed system will be explained in functional and
non-functional requirements. In doing so, use case model will be used.
2.2. Players in the Existing System
The existing system follows a manual operation which is based on manual handling documents
and paper handling. That means a number of different actors can be incorporated in the existing
system. The actors involved in the existing system are: -
 Administrator: -controls the whole system and manage account.
 Customer: - are registered, send compliant, edit your profile, pay as your choice, view
certificate, view ID and print it, login and update information.
 Manager: - the manager task generates the certificate, view hospital HI officer's request,
notify, view for payment, view compliant, and view customer information.
 Hospital card officer: - verify customer certificate (Id).
 Hospital health insurance officer: - send request for payment to agency.
2.3. Major Activities in Existing System

The existing system has many different functions and the major activity are:
 Provide health service for their members
 Reachable for the society that has low income
 Support also society that are no chance to get health service, for example farmer and
rural area peoples.
 Also support society that are live in very poorest range of income.

2.4. Business Rules
Business rules are statements about the agency’s way of doing business. They reflect business
polices. The project is developed with the concept of consideration on basic policies, strategies,
guidelines of the system. The system has the following business rules: -
BR1: The customer must be registered as a member of the insurance.
BR2: The customer must pay according to his/her choice of categories.
BR3: After pay the required payment he/she would get card or certificate.
BR4: The customer must be renewed their ID card as your categories you choose year.
BR5: The insurance is also pay for the hospital according to threat individual customer.
2.5. Report Generated in the Existing System
In the existing system reports are generated in manual based such reports are number of
customer the agency has, number of customer get treatment by one year, number of customer
leave from the agency and number of customer join into the agency.
2.6. Forms and Other Documents of the Existing Systems
The existing system uses the following manual forms to make their activities such as customer
registration and to generate report
Figure 2. 1: Customer registration forms of existing system

Figure 2. 2: Report generating forms of the existing system

Figure 2. 3: Report generating forms of the existing system

2.7. Bottlenecks of the Existing System
In the health insurance information management system everything is done manually. So the
following problems exist in this manual system:
 Uses large number of manpower.
 Requires high cost and time, means all documents are put in paper so it is difficult
select information if need.
 Employees exchange information by face to face , meetings or by call
 Some manuals can be destroyed by some illegal actions and due to that data can lost.
 Difficult to search the required information.
2.8. Practices to be Preserved
The strengths of the current system, refer to the characteristics of the business or project that
give it an advantage over others. There is some main strength of the current health insurance
management system that makes it comfortable.
 It is functional even if the network is accessible or not.
 There is no need of power or electric to operate the tasks,
 No need of materials such as computer, operating system to install,
 No need to know how to use computer.
2.9. Proposed Solution
The new system that have been proposed is a Health Insurance information management
System, is to minimize the problems that faced in existing system. Therefore, the system is
easy and simple to use and it saves time, resource and human resource.
2.10. Requirements of the Proposed System

2.10.1. Functional Requirements
Functional requirements are fundamental building block requirements. It is a statement of
exactly what the system must do. The new system has the following functional requirements:
 Customer’s registration:-In this case the customer is registered online to be
member of the customers of the agency. This module takes be concerned of new
customer registration to create an account. During this registration, the customer
Identification Numbers (ID) will be taken to identify this customer. The system will
take this Identification Number. The system permits users to login according to their
privilege.
 View customer’s information: - manager of the agency is viewing customer
information to know how many customer are there or member of the agency.

 Create bank account: _ in this system there is a payment customer pay for the
agency for that purpose there is a need of bank account provided by virtual bank.
 Payment processing: -the customer makes payment from their account to the
agency account. The Agency gives certificate to the customer after they successfully
pay them to the agency and also agency are pay for hospital according to their
request.
 Generate certificate: - the agency provides certificate to the customer for the
payment that indicate the owner of the certificate.
 View certificate: customer is viewing your certificate or id and print it to use this
certificate when you went get treatment.
 Notification action: -in order to have accurate response and high speed circulation
the system should be supported by Gmail, example when the system accepts new
information then the manager sends notification to the customer.
 Categories of health insurance: -customers must choose health categories that you
want to be registered.
 Send compliant: -A customer sends compliance to the agency if you have not got
sufficient service from hospital or other service that related to health insurance
service.
 Support our project by Amharic and English language: - the system allows the
users to use the language he/she want from Amharic or English to access the system.
 Store customer’s information in databases: - customer information must store in
database.
 Renewal insurance:-customer should renew your insurance when the life of the
insurance is finished.
 Request payment:-hospital health insurance officer send request for payment to the
agency according to treat customer of the health insurance member.
 Update profile customer information: - customer can update your information
when new information occur.
 Performance requirements(user requirements): In order to perform the task on
the system the user have ability to perform:-
 Have some experience about the system
 Must have basic computer skill to use the system
 Customer must know what he/she want to do on the system
 Must have an account and permission to use the system

 Process requirements: The process of our project accept inputs from the user,
process that input according to the instruction, finally produces output and displays
it. To do those activities use CPU (Central Processing Unit) capacity of the system
for processing purpose, Hardware and Software devices, Light or power for
activating the system ,Client computer (desktop or laptop any type brand ) with full
accessories, Network cable, Server computer and Web browser such as Mozilla
Firefox, Google chrome, etc.
 Input related requirements: The proposed system can take input from the
authorized user and check the validation of the input. It also needs correct input to
display correct output to end user.
 Output related requirements: The proposed system can display the appropriate
output after the system accepting inputs from the authorized user and process it
according to the instruction.
 Storage related requirements: The system can store any data inserted in to the
system in appropriate manner. The stored data can be kept in database permanently
and can be retrieving easily when the user accesses it.
2.10.2. Nonfunctional Requirements
Nonfunctional requirement describes visible aspects of the system that are not directly related
to the system. Unlike functional requirement, non-functional requirement deals with the
additional quality of the system such as performance, cost benefits, information preserving,
and security matter.
 Performance requirements: To make our system efficient we make our records
inserted to the databases based on their order in which they are inserted. This make
our system fast to fetch information from the database.
 Reliability: The data or information which is retrieved from the system is accurate
in any needed time: Because accurate data is stored in database. And can retrieve
as users need.
 User interface requirements: The system user interface is interactive and easily
understandable since it is developed both in Amharic and English languages.
 Security and access permission requirements: In our proposed system adding,
deleting, retrieving and updating information of the customer’s information is not
allowed for unauthorized users. Only certain activities are permitted for authorized
once that is controlled by the system. Whenever modification is necessary the

system should support such process by authorized users. And sensitive information
is encrypted by using MD5 encryption technique.
 Backup and recovery: We will use removable flashes and disks such as CD-
ROM, DVD for backup and recovery mechanism. Because the risks of data lost
might be happen due to a number of reasons such as computer viruses, sudden
accident on data storages, data theft or power fluctuation. Also when a user
interacts with the system errors may occur. To control this kind of inaccuracies the
system will generate different user friendly message.

Chapter Three
3. System Analysis
3.1. Introduction
The proposed system contains different functions performed in the health insurance
management system. This chapter describes the use case diagram, use case description and
sequence diagram for each use case, analysis class diagram, about the proposed system.
3.2. System Requirement Specifications (SRS)
SRS is a structured collection of information that embodies the requirement of the system.
Components and arrangements of the proposed system illustrated in the consecutive sub topics.
3.2.1 Use Case Diagrams
Use case diagram is a diagram we used to show the functionality of the system. And also we
show the external actors who interact with the system to perform their tasks. It is an interaction
between users, others system and a system. It captures the goal of the users and the
responsibility the system to its users. Use cases are described in the system boundary and actors
are described outside the system boundary.
 Actor: Is a person, or external system that plays a role in one or more interaction with
the system and represented with.
 Use case: Describes a sequence of actions that provides something of measurable
value to an actor and is drawn as a horizontal ellipse.
 System boundary: Indicates the scope of the system project. Anything within the
box represent functionalities in side in scope.
 Include relationship: A part of use case which appears in the same identical form in
other use cases may be transferred to its own use case and re-integrated universally
via an Include relationship in order to avoid the redundant specification of these
identical parts.
 Extend relationship: If a part of the tasks are transferred from one circumstance to
another, this is modeled in its own use case. The arrow is given the stereotype
"extend". The Extend relationship points to the use case to be extended, and starts
from that use case which describes the extension's behavior. This system is
represented using a use case diagram in the figure below:

Figure 3. 1: Use case diagram for customer
Figure 3. 2: Use case diagram for hospital health insurance officer

Figure 3. 3: Use case for administrator
Figure 3. 4: Use case diagram for hospital card officer

Figure 3. 5: Use case for manager

Figure 3. 6: Use case for the system

3.2.2. Use Case Description
Much of the use-case model is in fact, textual, with the text captured in the use-case
specifications that are associated with each use-case model element. These specifications
describe the flow of events of the use case.
Table 3. 1: Registration use case description
Use case id UC-1

Use case Name Registration
Participating Customer
actors
Description This use case describes the registration of customers.
Precondition The Customer should sign up to the system for register as the customer of agency.
Basic course of Actor action System response
action step1: the Customer person clicks on the Step2:System initiation, registration form
sing up link Step3: The System displays a Registration
step4:Fills the required information form.
Registration form and clicks Register Step 5: transfer action
button Step6: checks for the validity of the
Step8: end of use case registration form
step7: Registers to the database.
Alternative If the registered customer information is not valid then the display ” error massage” and
course of action Back to step 4
Post condition Registration is successful.
Table 3. 2: User login use case description
Use case id UC-2

Use case Name Login
Participating actors Administrator, Manager, Hospital card officer, Hospital, HI officer, and
customer
Description An administrator, Manager, Hospital card officer, Hospital, HI officer and

customer login or enter into the system through this form
Precondition The user should have an account in the Database.

Basic course of action Actor action System response

step1. A user clicks a login link Step2: system initiation login form
step4. Enters username and Step3: System display login form.
password and Click on Login button step5: transfer action
Step7: If the user ID and password Step6: The system verifies User
are valid, the actors will be logged Account.
on to the system. Step8:It redirects to the main page
Step9: end of use case
An alternative course of If the user name and password is not Correct.

action Back to step 4
Post condition The user logged in to the login form
Table 3. 3: Payment use case description
Use case id UC-3
Name Payment
Actors Customer, Manager
This use case describes the payment handling by the customer to the agency account
Description and agency to the hospital from their account.
The user should login to the system and should have an account. Besides the agency
Precondition should have an account.
Basic Course of
Action Actor Action System Response
step1:The user click on the payment link Step2: system initiation payment form
step4:The user full details and click Step3: The system displays the form.
submits step5: transfer action
step8: end of use case Step6: checks the accounts of the user
Step7: save to database
Alternative If the account is not enough to pay displays the message “your account is not enough
Course of to pay”
Action
Post condition Payment is already transferred from the customer to the agency account and agency
to hospital.

Table 3. 4: Generating certificate use case description
Use case id UC-4

Use case name Generate certificate
Participating Actor Manager
Description The Manager person generates a receipt immediately by a soft copy to the
customer when the customer's order to payment successfully.
Precondition The customer orders items.
Basic course of User action System response
action
step1: The Manager clicks on the Step2: the system initiation form.
certificate generating links. Step3. The system display certificate
Step4: Fills the required information generating form
certifies generating form and click Step5: transfer action
submit button Step6: The system validates whether
Step7: Customer view certificate. the generate data are found or no found.
Step9: end of use case. Step8: System generates a certificate to
the customer.
Post condition The customer receives generate certificates.
Table 3. 5: Manage account use case description
Use case id UC-5

Use case Name Manage account
Participating actors Administrator
Description This use case describes the authority of the administrator to create, update if
necessary, delete and restrict an authorized access
Precondition The users should log in to the system and administrator creates, update if
necessary, delete and restrict an authorized
Step1: the users click on the manage Step2: system initiation manages
account link account form
Step4: The users select a valid Step3: System displays Manage
operational button value (create, account form.
deactivate, activate or update) Step5: transfer or send action
account. Step6: the system manages their
Step7: end of use case account
An alternative course If the users did not select the needed operation
of action Back to step 4
Post condition “Account is managed successfully”

Table 3. 6: Send notification use case description
Use case id UC-6

Use case Name Send notification
Participating actors Manager
Description This use case describes the acknowledging of customer as they pay their some
percentage or total payment is transferred to the company account and this
use case describes notify either daily, weekly or yearly based on the functions
of the system
Precondition The Manager should login to the page

step1: the user clicks on the Step2: system initiation notification form
notification link Step3: The system Displays the form.
step4: user fills required Step 5: transfer action
information and click send Step6: The system sent notification to
button customers through your email.
An alternative course
of action If the time is too short” it is not the time to notification”
Post condition
The notification message is sent to the customer
Table 3. 7: Send Complaint use case description

Use case Id UC-7
Use case name Send Complaint
Participator Actor Customer
Description A customer of a system may have some comment for the system at this time
they can send to the system.
Precondition The customer should login to the system and customer must be submitted the
complaint.
Step1: The customer click on the Step2: System initiates edit page
complaint handling link. Step 3: The system displays the form.
Step4: The customer fill details and Step5:transfer action
click Submit. Step6: Checks the comment of the
Step8: end of use case customer.
Step7: save to database
An alternate course of If the input is invalid, the system display ”error message “and
action Returns back to basic flow of action 4
Post conditions User can successfully send their comments.

Table 3. 8: View notification use case description
Use case Id UC-8

Use case name View notification
Description Customer can view notification that notified from different staffs and also can
view new information sent to customers by Chatting.
Precondition The Customer must login with its home pages.
action
Steps1: Customer click on the view Step2:Systeminitiation form

notification links in homepages button. Step3:The system displays the
Step4: check for notification is found or not result
found.
Step5: Customer can be seen notification
and new information.
Post conditions The customer can successfully view notification and new information
Table 3. 9: View compliant use case description
Use case Id UC-9

Use case name View compliant
Participator Manager
Actor
Description The manager can view, comment that commented from different staffs and also
give the response.
Precondition The Manager must login with its home pages.
action Steps1: manager click on the view, massage Step2:Systeminitiation form
links in button. Step4:The system displays the
Step 3: check for weather found or not found result
Step5: if the manager can see the comment
Post conditions Successfully viewed

Table 3. 10: View payment use case description
Use case Id UC-10

Use case name View payment
Participator Manager, Hospital HI officer
Actor
Description User can view payment that pays for the customer and the agency.
Precondition This User must login with its own individual privilege home pages.
action Step1: user click on the view payment links in Step2:Systeminitiation form
button. Step5:The system displays the
Step 3: check for weather found or not found result
Step4: if found the User can view for payment
Post conditions Payment can successfully viewed
Table 3. 11: Edit profile use case description
Use case Id UC-11

Use case name Edit profile
Description The customer can edit your profile photo.
Precondition Those Customer must login with its home pages.
Steps1:Customer click on the Step2: system initiation form
edit profile link Step3:The system displays the form
Step4: the Customer must be fill step5: transfer action
information you want to edit and Step6: check for validity while fill
click edit button. information format is correct or not.
Step6: end of use case Step7: save to database
Post conditions The profile can successfully Edited
Table 3. 12: View customer information use case description
Use case Id UC-12

Use case name View customer information
Participator Actor Manager
Description The manager can view customer information.
Precondition The Manager must login with its home pages.

Step1: Manager, click on the view Step2: initiation form
customer information links in button. Step5:The system displays the
Step3: check whether it’s found or not result
found
Step4: if found the manager can see the
customer information
Step6:End of use case
Table 3. 13: Approve certificate use case description
Use case Id UC-13

Use case name Approve certificate
Participator Hospital card officer
Actor
Description Hospital card officer approves or verify customer certificate to check whether the
customer is a member of health insurance agency.
Precondition The hospital card officer must login with its home pages.
Basic course Actor action System response
of action Steps1: Hospital card officer click on Step2:The system displays the form
the verify links in button. step3: system displays verify form
Step4: fill information Step5: transfer/send action
Step8. End of use case Step6: check is this customer of the agency
the member
Step7: display required result
An alternate If the customer is not member of the agency then “display this customer is no
course of membership”
action
Post Successfully approved
conditions

Table 3. 14: View certificate use case description
Use case Id UC-14
Use case name View certificate

Participator Customer
Actor
Description Customer can view your certificate when you want.
Precondition Those Customer must login with its home pages.
action Steps1:Customer click on the Step2: system initiation form
view certificate link Step3:The system displays the result
Step4: the Customer can view
your certificate and also your
certificate.
Table 3. 15: Request payment use case description
ID UC-15
Use case name Request payment

Actors Hospital HI officer, manager
The Hospital HI officer’s request payment of agency and also manager of agency
Description request payment for customer.
Precondition The user must have full information about their expense.
Basic Course of
Action Actor Action System Response

Step1: The user select request Step2: The system initiation the payment
payment link. request form
Step4: The user fill request Step3: The system displays request payment
payment form and click send form.
button. Step5: The system validates filled information.
Step7: end of use case Step6: The system displays a success message.
Alternative Course If invalid information filled the system displays error message to inform the user
of Action to fill the correct value again.
Return back to step 4.
Post condition Success for request payment
3.2.3. Sequence Diagrams

A sequence diagram shows an interaction arranged in time sequence. In particular, it shows the instances
participating in the interaction by their “lifelines” and the stimuli that they arranged in time sequence.
It does not show the associations among the objects. Sequence diagrams are used to model the logic of
usage scenarios or the description of the potential way the system used. Sequence diagrams are a great
way to validate and flesh out the logic of use case scenarios and to document design of the system. The
boxes across the top of the diagram represent classifiers or their instances, typically uses cases, objects,
classes or actors. Because you can send messages to both objects and classes, objects respond to
messages through the invocation of an operation, and classes do so through the invocation of static
operations, it makes sense to include both on sequence diagrams.

Figure 3. 7: Sequence diagram for user registration

Figure 3. 8: Sequence diagram for login

Figure 3. 9: Sequence diagram for update information

Figure 3. 10: Sequence diagram for payment

Figure 3. 11: Sequence diagram for managing account

Figure 3. 12: Sequence diagram for sending notification

Figure 3. 13: Sequence diagram for complaint
3.2.4. Activity Diagram
An activity diagram is a variation of a state machine in which the states represent the performance of
actions or sub activities and the transitions are triggered by the completion of the actions or sub
activities. It represents a state machine of a procedure itself. Activity diagrams model is a high level
business or processes or transitions between states of a class. Activity diagrams are graphical
representations of workflows of stepwise activities and actions with support for choice, iteration and
concurrency. The purpose of the activity diagram is to model the procedural flow of actions that are

part of a larger activity. In projects in which use cases are present, activity diagrams can model a specific
use case at a more detailed level. The activity diagram shows the various activities step by step with the
carrying for both parallel and conditional behavior. An activity diagram is a modification of state
diagram in which most of the states are activity state. The most important shape types are:
 Rounded rectangles represent activities.
 Diamonds represent decisions.
 Bars represent the start (split) or end (join) of concurrent activities.
 A green circle represents the start (initial state) of the work-flow.
 An encircled red circle represents the end (final state).
Activity diagram shows the work flow of the new system. In this activity diagram we tried to document
the flow of logic for the major business processes of this project. The activity diagram below shows the
users activity performed on the customer or other for health insurance information management system.
Figure 3. 14: Activity diagram for customer registration

Figure 3. 15: Activity diagram for customer payment

Figure 3. 16: Activity diagram for manage user account

Figure 3. 17: Activity diagram for send complaint

Figure 3. 18: Activity diagram for update customer information
3.2.5. Analysis Level Class Diagram
Class diagrams in the Unified Modeling Language is a type of static structure diagram that
describes the structure of a system by showing the system's classes, their attributes, operations
and the relationships among the classes. The class diagram with its corresponding objects will
be present in the following diagram. Our class diagram includes different class. Such as

customer, Manager, Administrator, Hospital health insurance officer, payment, account, and
virtual bank.
 Class diagram shows the classes of the system, their inter-relationships, and the
operations and attributes of the classes.
 Classes are shown as boxes with three sections – the top for the name of the class,
the middle for the attributes, and the bottom for the operations.
 Associations between classes are depicted as lines between classes.
 Associations should include multiplicity indicators at each end, for example 0...1
representing “zero or one” and 1.* Representing “one to many.
 This shows us all about aggregation, association, inheritance and dependency of the
class.

Figure 3. 19: Analysis level class diagram

3.2.6. User Interface Prototyping
User interface-flow diagram is called a navigation diagram boxes which represent major user
interface elements, modeled as instances/objects, and the line represent the possible flow
between them.
Figure 3. 20: User interface prototype diagram
3.2.7. Supplementary Specification

The supplementary specifications capture the system requirements that are not readily captured
in the use cases of the use-case model. Such requirements include:-

 Legal and regulatory requirements and application standards.
 Quality attributes of the system that are non-functional requirements of the system;
such as usability, reliability, performance, and supportability requirements as well
as functional requirements.
 Other requirements such as operating systems and environments, compatibility
requirements, and design constraints.
 The System will enable user to access health insurance information and to get health
insurance service.
 The System also allows the admin to control the database by adding, update or
delete the data and users.

References
Asfaw, A. V. (2017). Innovation in health care financing: New evedence on the prospect of community
health insurance schemes in the rural areas of Ethiopia. intternational journal of health care
finance and economics, 241-253.
bethsda. (2017). Africa health insurance handbook. hong kong: abt associate inc.
Green, M. (2018). understanding health insurance a guide to billing and reimbursement. canage
learning, 167-197.
kaplan. (2016). life and health insurance. united states of america: kaplan financial education.
Nageso, D. K. (2020). enrollemt in community based health insurance and the associated factors among
households in boricha district , sidama zone sothern ethiopia. a cross sectional study plos one ,
64-78.
Nageso, D. T. (2020). enrollement in community based health insurance program and the associated
factor among house holds in boricha district, sidama zone , southern ethiopia . a pios one cross
sectional study, , 65-78.
አቶ አሰፋ ይርጋለም, አ. ጌ. (2009). ethiopian health insurance. PSD Adverttisng & Print, 15-34.

Final Project Documentation

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Final Project Documentation

Uploaded by

Copyright:

Available Formats

ARBA MINCH UNIVERSITY

ARBA MINCH INSTITUTE OF TECHNOLOGY

Under supervision of: Mr. Debebe.

Online health insurance information management system 1

Online health insurance information management system 2

Project Online Health Insurance Information Management System

1.5. Schedule (Work Plan)

Online health insurance information management system 3

Online health insurance information management system 4

1.9. Feasibility of the Project

Online health insurance information management system 5

Online health insurance information management system 6

Online health insurance information management system 7

No Name Function of hardware

No Name Function of software

1.11.4. Testing Procedure

Online health insurance information management system 8

No Item to be budgeted Quantity Price in birr(ETB)

Total 15550 birr

Online health insurance information management system 9

Online health insurance information management system 10

2.3. Major Activities in Existing System

Online health insurance information management system 11

Figure 2. 1: Customer registration forms of existing system

Online health insurance information management system 12

Online health insurance information management system 13

Online health insurance information management system 14

2.10. Requirements of the Proposed System

Online health insurance information management system 15

Online health insurance information management system 16

Online health insurance information management system 17

Online health insurance information management system 18

Online health insurance information management system 19

Figure 3. 2: Use case diagram for hospital health insurance officer

Online health insurance information management system 20

Figure 3. 4: Use case diagram for hospital card officer

Online health insurance information management system 21

Online health insurance information management system 22

Online health insurance information management system 23

Use case id UC-1

Table 3. 2: User login use case description

Use case id UC-2

Description An administrator, Manager, Hospital card officer, Hospital, HI officer and

Precondition The user should have an account in the Database.

Online health insurance information management system 24

An alternative course of If the user name and password is not Correct.

Post condition The user logged in to the login form

Table 3. 3: Payment use case description

Use case id UC-3

Online health insurance information management system 25

Use case id UC-4

Post condition The customer receives generate certificates.

Table 3. 5: Manage account use case description

Use case id UC-5

Online health insurance information management system 26

Use case id UC-6

Participating actors Manager

Basic course of action Actor action System response

Table 3. 7: Send Complaint use case description

Online health insurance information management system 27

Use case Id UC-8

Steps1: Customer click on the view Step2:Systeminitiation form