ASSOSA UNIVERSITY

SCHOOL OF TECHNOLOGY AND INFORMATICS

DEPARTMENT OF INFORMATION TECHNOLOGY

ONLINE WEB BASED HEALTH INSURANCE MANAGEMENT
SYSTEM IN ASSOSA BRANCH
NAME ID

1.Natnael Tewodros………………………………………2458/12

2.Temesgen Molla ……………………………………….0694/12

3.Daniel Dessalew……………………………………….0258/12

4.Abush Kasa…………………………………………….1485/12

My Advisor: -MS Moti Girmaw

Submit to: IT department

ASSOSA, ETHIOPIA
Approval Sheet

This is certified that the Project Entitled on Web based Ethiopian Health Insurance Information
Management System for Assosa City Submitted by:

Natnael Tewodros

Temesgen Molla

Daniel Dessalew

Abush Kasa

Project proposal Submitted to the Department of information technology of Assosa University

in a Partial Fulfillment of Requirement for Bachelor Degree in information technology

Science Advisor’ Name Signature Date

1.Moti Girmaw ______________ ______________

2. ___________________ ________________ _____________

APPROVED BY

Examining Board Signature Date

1. _____________________ ___________ ________

2. _____________________ ___________ _________

3. _____________________ ___________ _________

i
Acknowledgement

We wish to express our sincerely gratitude to the department of Information Technology, for
providing opportunity to do Final year project on “online Health Insurance information
management system in Assosa branch”. We sincerely thank our advisor Mr. Moti for their
diligence in advising and guiding us through the right path and give necessary comments until
the completion of the documentation.

Also, thanks to the Assosa health insurance agency for giving us the correct requirement for the
system developed by our group members. Lastly, we would like to acknowledge all our friends
for their morals, idea, materials and financial support.

ii
Table of Contents
Approval Sheet.................................................................................................................................i

Acknowledgement...........................................................................................................................ii

List of figures..................................................................................................................................vi

Abbreviations..................................................................................................................................ix

Chapter 1..........................................................................................................................................1

1. 1 Introduction...........................................................................................................................1

1.2 Background of the Project......................................................................................................1

1.3 Statement of the problem.......................................................................................................1

1.4 Proposed System Description................................................................................................2

1.5 Objective of the Project..........................................................................................................3

1.5.1 General Objective............................................................................................................3

1.5.2 Specific Objectives..........................................................................................................3

1.6 Scope and Delimitation..........................................................................................................3

1.6.1 Scope...............................................................................................................................3

1.6.2 Limitations.......................................................................................................................4

1.7 Methodology..........................................................................................................................4

1.7.1 Data Collection Method..................................................................................................4

1.7.2 By using different search engine.....................................................................................5

1.7.3 System Development Approach......................................................................................5

1.7.4 System development model.............................................................................................5

1.7.5 Implementation Tools......................................................................................................6

1.8 Feasibility analysis.................................................................................................................7

1.8.1 Technical feasibility........................................................................................................7

1.8.2 Operational feasibility.....................................................................................................7

iii
 1.8.3 Economic feasibility........................................................................................................7

1.8.4 Schedule feasibility.........................................................................................................7

1.8.5 Legal feasibility...............................................................................................................8

1.8.6 Political feasibility...........................................................................................................8

1.9 Significance and Beneficiary of the project...........................................................................8

1.10 Schedule and Budget............................................................................................................9

1.10.1 Schedule........................................................................................................................9

1.10.2 Budget.........................................................................................................................10

Chapter two: System Analysis.......................................................................................................11

2.1 Introduction..........................................................................................................................11

2.2 Analysis of the existing system............................................................................................11

2.2.1 Existing system description...........................................................................................12

2.2.2 Essential use case and documentation...........................................................................13

2.2.3 Essential interface prototyping......................................................................................14

2.2.4 Domain modeling with CRC.........................................................................................15

2.2.5 Business rule..................................................................................................................18

2.3 Analysis of the new system..................................................................................................19

2.3.1 Functional requirement..................................................................................................19

2.3.2 Non-functional requirement..........................................................................................34

2.3.3 Analysis Mode...............................................................................................................35

Chapter three: System Design.......................................................................................................55

3.1 Introduction..........................................................................................................................55

3.2 Purpose and goal of the design............................................................................................55

3.3 Deployment Diagram...........................................................................................................56

3.4 Architectural design.............................................................................................................57

iv
 3.4.1. Subsystem decomposition............................................................................................58

3.4.2. State machine diagram.................................................................................................61

3.4.3. Communication modeling /collaboration diagram.......................................................62

3.4.4. Component modeling...................................................................................................63

3.4.6. Entity relationship diagram/database design................................................................65

3.4.7. Access control and security..........................................................................................66

3.5 User interface design............................................................................................................67

3.6 Algorithm design..................................................................................................................68

Chapter-Four..................................................................................................................................70

4.Implementation and Testing.......................................................................................................70

4.1 Implementation....................................................................................................................70

Sample code...........................................................................................................................74

4.2 Testing..................................................................................................................................82

4.2.1 Unit Testing...................................................................................................................82

4.2.2 Integration Testing........................................................................................................82

4.2.3 Test cases.......................................................................................................................83

4.2.4 Sample test scripts.........................................................................................................85

Chapter-Five..................................................................................................................................86

5.Conclusion and Recommendation..............................................................................................86

5.1 Conclusion...........................................................................................................................86

5.2 Recommendation.................................................................................................................86

Reference and Appendices............................................................................................................88

Reference.......................................................................................................................................88

Appendix........................................................................................................................................88

v
 List of tables
Table 1 Schedule..............................................................................................................................9
Table 2 Budget...............................................................................................................................10
Table 3 CRC diagram for customer...............................................................................................16
Table 4 CRC diagram for certificate ID........................................................................................16
Table 5 CRC diagram for user account.........................................................................................16
Table 6 CRC diagram for request pay...........................................................................................17
Table 7 CRC diagram for complain...............................................................................................17
Table 8 CRC diagram for payment................................................................................................17
Table 9 use case identification.......................................................................................................21
Table 10 Use case description for Registration.............................................................................23
Table 11 Use case description for Login.......................................................................................24
Table 12 Payment use case description.........................................................................................25
Table 13 Generating certificate use case description....................................................................26
Table 14 Manage account use case description.............................................................................26
Table 15 Send notification use case description............................................................................27
Table 16 Send Complaint use case description.............................................................................28
Table 17 View notification use case description...........................................................................29
Table 18 View compliant use case description..............................................................................30
Table 19 View payment use case description................................................................................30
Table 20 Edit profile use case description.....................................................................................31
Table 21 View customer information use case description...........................................................32
Table 22 Approve certificate use case description........................................................................32
Table 23 View certificate use case description..............................................................................33
Table 24 Request payment use case description............................................................................34
Table 25 Access control and security............................................................................................66
Table 26 Test case for login...........................................................................................................83
Table 27 Test case for create account............................................................................................83

List of figures

vi
Figure 1 use case diagram..............................................................................................................14
Figure 2 Customer registration......................................................................................................15
Figure 3 Use Case modeling..........................................................................................................22
Figure 4 Sequence diagram for registration form..........................................................................36
Figure 5 Sequence diagram for login form....................................................................................37
Figure 6 Sequence diagram for payment form..............................................................................38
Figure 7 Sequence diagram for manage account...........................................................................39
Figure 8 Sequence diagram for generate certificate......................................................................40
Figure 9 Sequence diagram for send notification..........................................................................41
Figure 10 Sequence diagram for send complaint..........................................................................42
Figure 11 Sequence diagram for view notification........................................................................43
Figure 12 Activity diagram for customer registration...................................................................45
Figure 13 Activity diagram for customer Login............................................................................46
Figure 14 Activity diagram for customer payment........................................................................47
Figure 15 Activity diagram for send complain..............................................................................48
Figure 16 Activity diagram for request payment...........................................................................49
Figure 17 Class diagram................................................................................................................51
Figure 18 User interface................................................................................................................53
Figure 19 Deployment Diagram....................................................................................................57
Figure 20 Subsystem decomposition.............................................................................................60
Figure 21 State diagrams for registration......................................................................................61
Figure 22 Collaboration diagram for login....................................................................................62
Figure 23 Collaboration diagram for payment..............................................................................63
Figure 24 Component diagram......................................................................................................64
Figure 25 Database design.............................................................................................................65
Figure 26 Login form page............................................................................................................67
Figure 27 Registration page form..................................................................................................68
Figure 28 Home page.....................................................................................................................71
Figure 29 Login page.....................................................................................................................72
Figure 30 Admin Display account page........................................................................................73
Figure 31 Test case for payment handling.....................................................................................84

vii
Abbreviations

BGRS……………………………. Benishangul Gumuz regional State

viii
ETB………………… …………. Ethiopian Birr

E.C……………...........................Ethiopian Calendar

G.C……………………………. Gregorian Calendar.

GB………………………………Gigabyte

HTTP …………………………. Hipper Text Transfer Protocol.

HTML……………… …………. Hypertext Markup Language

ID ……………………………. …Identification Number

MYSQL…………………………My Structural Query Language

OOSAD…………………….......Object Oriented System Analysis and Design

PC……………………………. …Personal Computer

PHP…………………………. …. Hypertext Preprocessor

ix
Chapter 1
1. 1 Introduction
Health insurance 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. Under the health insurance system, each district will
have a collective health fund to which participants will contribute to. Enrollment is done in a
household rather than individual basis. The poor are eligible for membership in health funds that
is subsidized by the Woreda and regions.

1.2 Background of the Project

Health insurance information management system to developed stores customer’s information in

a database, so information manageability is better. After their information is stored and if they
pay the initial payment and make the ID card renewed in proper time, they get treatment. The
hospital card officer gives service card by checking whether the customer is a participant or not
from a database. Also, the system used to search customer’s information from the database
easily.

Health insurance is insurance against the risk of incurring medical expenses among individuals.
By estimating the overall risk of health care and health system expenses, among a targeted group,
an insurer can develop a routine finance structure, to ensure that money is available to pay for the
health care benefits specified in the insurance agreement. The benefit is administered by a central
agency such as a government agency, private business, or not for profit entity.

Health insurance agency is an insurance where peoples are recorded as a customer of the health
insurance agency and they can get health treatment. It gives support for different types of
treatments for so many diseases.

1.3 Statement of the problem

The existing health insurance agency records the customers’ information in a paper-based
manner. If there is need of updating information such as if, there is increase or decrease in family
member, updating is performing in a paper this leads difficult to update quickly. Finding list of a
customers’ information is difficult. Lack of immediate information retrieval is difficult; this
1|Page
takes a lot of time to perform task. Lack of immediate information storage since it is paper based
manner. Difficult to count number of members that are registered in this insurance and no fast
communication between employees and customers during recorrect the customers file. The
agency has traditional payment system, this results time and energy consumption to customers.
Therefore, our system can solve the problem that influence the agency.

This process of working procedure of the existing system creates many problems that are not
solved by now. Some of those are: -

 Losing of Customers files.

 Lack of file security
 Requires more labor to manage the data
 The files are not accurate and cannot be updated easily and immediately since it is paper
based.
 Lack of data integrity that leads to the redundancy of data.
 Physical damage of file due to dust, moisture and other cause.
 No fast communication between different employees in health insurance agency.
 Lack of reliability because of manual work.

1.4 Proposed System Description

The existing system has many problems and drawbacks. So, the project team will try to develop
a system which is better than the existing system in terms of time and cost efficiency and
improve system performance. The proposed system will be capable of providing high security of
data, capability of organizing all information in a single client server system, easy way of
recording and accessing items information by its well-organized user-friendly interface.
Generally, the proposed System will improve the performance of the existing system and reduce
the problems of, time wastage, data security, data inconsistency, Poor quality service delivery,
and reduces wastage of paper. And customers can forward their compliant to the health insurance
agency easily if they do not get efficient treatment from the hospital and they can get certificate
easily to pay health insurance payment online without going to the health insurance agency

2|Page
1.5 Objective of the Project

1.5.1 General Objective

The general objective of our project is to develop Web Based Health Insurance Information
Management System.

1.5.2 Specific Objectives

To achieve the general objective mentioned above, the following are specific objective: -

 To identify functional and nonfunctional requirements.

 To design new systems.
 To develop a user-friendly system
 To make suitable back end and front end.
 To implement the proposed system.
 To test and evaluate the proposed system.

1.6 Scope and Delimitation

1.6.1 Scope
This project is to develop an online health insurance information management system for health
insurance agency. Thus, the system boundary includes the following: -

 The system allows online registration of customers and able to manage the customers’
information without any failures.
 The system helps to activate or deactivate customers’ account.
 The system has ability to send request, feedback and give response online.
 The system supports to generate different report.
 The back side of the system has ability to store customer’s information.
 The system able to introducing new information for customers, users should be having
awareness for the notification.
 The system able to check the user in case of either authorized user or unauthorized user.
 The system able to perform transaction means that deducts from user account and adds in
institute account.

3|Page
 The system able to count number of customers registered in to the system.
 The system able to share data for all users without any biased.
 The system support Amharic and English languages.
1.6.2 Limitations
Due to the performance of the system and software applicability, the following activities are not
including in the developing system.

 The system does not support Oromo, Gumz and other languages because it is not
international languages.

1.7 Methodology

1.7.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 data collection methods include, interview, questionnaires’,
document analysis, practical observation etc. Those methods, which help us to gather the
required data to analyze our project, and those methods selected due to the time and the
organization’s willingness.

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.
 Questionnaires: -In order to get information about the existing system of health
insurance agency, we prepare questionnaires for analyzing the process of health
insurance workflow to understand the current system process. Some of the
questionnaires are the following:
 When Health Insurance Agency was established?

4|Page
  What problem occurs during finding of customer’s information?
 What problem occurs during updating of customer’s information?
 How customers can replace their ID card if their id is stolen or misplaced?
 What is the main goal to establish this agency?
We distribute the above question for organization director in the agency.

 Document Analysis: -To understand the existing system, we collect more information
by referring different manuals about the general information about the health insurance
agency.
1.7.2 By using different search engine

Google, YouTube, and Bing search engines are reliable, available and honest to help everyone at
any time with in connection forever due to this we have got some idea from those search engines
we have understand the meaning and advantage of waterfall model, differences’ b/n general and
specific objective and other concepts we conceptualize from the above search engines.

1.7.3 System Development Approach

Object-oriented programming: This approach preferable for speeds up the development of new
programs, improves the maintenance, reusability, and modifiability of software.

Advantages of OOP these are.

 Re-usability: objects can be reused in different programs.

 Simplicity: software objects model real world objects, so the complexity is reduced and
the program structure is very clear.
 Extensibility: adding new features or responding to changing operating environments can
be solved by introducing a few new objects and modifying some existing ones.
 Maintainability: objects can be maintained separately, making locating and fixing
problems easier.

5|Page
1.7.4 System development model

Iterative model: -this model starts from simple implementation of a small set of the software
requirements and iteratively enhances the evolving versions until the complete system is applied
and ready to be deployed.

It goes to forward and backward. Used to add new feature on the system. Reuse concepts of
inheritance.

1.7.5 Implementation Tools

Hardware requirements

 CPU (Intel/Pentium).
 System disk.
 RAM.
 Desktop computer (Dell).
 Flash disk: for data storage and transferring.
Software requirements

 Uniform server (any versions).

 Windows operating system.
 Browser
 Editor (Notepad++ or HTML builder): for writing PHP code and html code
 MS-word for writing documentation.
 Microsoft power point: for presentation.
 Photo editor (any type) for editing image that will be incorporated into the page
 HTML (hypertext markup language): used to write code in client side
 CSS (cascading style sheet): used to add style to html element
 JS (Java scripts): used for form validation
 PHP (is a server scripting language, and a powerful tool for making dynamic and
interactive Web pages.)
 XAMP: To integrate the HTML with database server

6|Page
  Edraw Max 7.9: is an open source software modeling tool that supports UML model
diagram.
 MySQL (is a standard language for accessing databases).

1.8 Feasibility analysis

A feasibility study, also known as feasibility analysis, is an analysis of the viability of an idea. It
describes a preliminary study undertaken to determine and document a project’s viability. The
results of this analysis are used in making the decision whether to proceed with the project or
not.

1.8.1 Technical feasibility

Project team use hardware device, software devices and script language (PHP, HTML, Java
Script, CSS, bootstrap and others) for development and implementation of the proposed system.
Therefore, our project is technically feasible.

1.8.2 Operational feasibility

The system able to work and operates minimize and compactable with any devices such like,
laptop, desktop, and any other devices which are near for user. Due to this, the project will be
operationally feasible.

1.8.3 Economic feasibility

This project requires minimum amount of cost for development process when it compared to the
existing system. Project team cannot need much money to do it. The expense that we have
finished until now is: for print 300 birrs, for gathering information 150birr, for hardware dive
including pc and 8 GB flash 15250 birr and 150 birrs for pen and paper, while the existing
system requires 15850 per year. Therefore, our project is economically feasible.

1.8.4 Schedule feasibility

Project team has been enough time to finish all tasks including project proposal and web-based
system. Schedule feasibility ensures that the project completing within given time constraint or

7|Page
schedule and also verifies and validates whether the deadlines of project are reasonable or not.
Therefore, our system is scheduler feasible.

1.8.5 Legal feasibility

The system is legally feasible mean that the system is free from any illegal activities and
unauthorized users have not access the system. The system is clearly work for the society and
benefits them; therefore, the system will be legally feasible.

1.8.6 Political feasibility

The proposed system will implement, as one of governmental institutions, the system to be
developed is not conflict with any government directives, rules and regulations. Therefore, the
government is profitable and the system will be politically feasible.

1.9 Significance and Beneficiary of the project

After successfully implementing, the proposed system is expected to be reliable, easy, fast and
consistent and plays a crucial role for the agency and its customers. Therefore, both agency and
its customer share the significance of the system in such a way: -

For the customers: -

 To minimize time needed to register and update their information.

 Customer’s information is managed properly.
 Customers can send their complaint freely.
For the agency: -

 To increase the number of customers.

 To minimize time needed to perform tasks.
 To manage the customers' information honestly.
 It reduces work load at the customer’s record pace.
 To save time it needs to deal with customer information.
 To decrease the workload of both employees and customers.
The beneficiaries of proposed system will be the following: -

8|Page
  Agency:
 It can help the manager for easily manage the employee and customer’s
information.
 It can help Customers; give the answer for customers’ request.
 maintains the system when failure is occurred and control over all performance of
the system.
 Customer: Since the system is computerized then it can help the customer easily retrieve
or get information from the agency.

1.10 Schedule and Budget

1.10.1 Schedule

Schedule

Table 1 Schedule

Activity Jan (05-15) Jan (15) Feb (23) Mar (11) May (01- May (21)
Feb (22) marc (10) April (30) 20) June (15)

Prepare
proposal
Data collect
Data Elicitation
Data Analysis

Data designing
Prepare
implementation
Test
We will try to finish according to this schedule.

9|Page
1.10.2 Budget

Table 2 Budget

Item Quantity Unit cost per item Total in birr

(in birr)

Mobile card 6 25 150:00

Flash 1 500 500:00

Printing 150 paper 4.00 600:00
pen 5 100 50:00
Paper 100 1:00 100
Laptop 1 25000:00 25,000:00
Total cost 26.400:00

10 | P a g e
Chapter two: System Analysis

2.1 Introduction

System analysis is an essential activity that must be undertaken in any project to have a clear
idea of the proposed system. The requirement of the proposed system will be explained on the
form of functional and non-functional requirements are modeled by the essential use case. The
important goal of system analysis is to overcome the business problem that our system is to
address in order to understand its usage requirements. 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 Analysis of the existing system

It is necessary to know the existing system of a given organization to develop a better system.
Health insurance is a mechanism by which a person protects himself from financial loss and
expense related with money when they seek or ill. The great goal to establish the health
insurance is to help the people who have not ability to pay high fee when they ill. As we observe
and ask the manager of Assosa city health insurance agency Ato Netsanet Ymer

, he tells us “currently there is no fully computerized system for Health Insurance information
management system in Assosa, to record customer’s information. Sharing of information
between administrator, employee and customer and other actors is manual. The current health
insurance information management system in Assosa city uses some strategies to minimize the
mistakes. It uses document system to store data locally and to handle the problems carefully. To
minimize the problem of resource loosing from each related office, they work honestly

11 | P a g e
depending on the rules and regulations. The employees are responsible and transparent for their
actions. The activities in which the existing system perform are count the number of members
who are registered, collect and count the total money paid by members, calculate the total
income & outcome of the agency and other tasks are performed by manually, due the manual
working of the existing system, problems may be occurred at each stage since no one is perfect
and error reports can be generated.

The existing system has the following drawbacks

 Occur mistake during recording large data and this may disrupt important day-to-day
activities.
 Security is big problem.
 The office needs many places to store the customers’ file.
 Cost in terms of time is high.
 Customer does not get better service.
 Increasing expenditure for papers shuffling and storage.
 Increasing labors and hence errors.
 Difficult to know numbers of members.
 Time delay between the payment and its receipt.
 It is very difficult to generate the report.
 The existing system Consumes large volume of paper work.
 Retrieval of data in a desired way is difficult.
 In the existing system, calculating the income and outcome is enervating.
 There is no means of keeping back up.

2.2.1 Existing system description

The existing system at woreda follows 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: -

 Customer: members of health insurance.

 Manager (General Assembly): approve payment letter of hospital.
 Accountant: Summarizes current financial status

12 | P a g e
  Information specialist: manage and organize health data done for the purposes of
insurance reimbursement, and to maintain patient histories of treatment. It reviews
records for completeness and accuracy (by working with registered nurses),
organizing and maintaining data for clinical databases and registries,
electronically recording data for storage and analysis, using classification
software to assign clinical codes for reimbursement and analysis, tracking medical
outcomes to assess quality, and always maintaining confidentiality.
 Hospital HI officer: request payment from woredas for the hospital.

2.2.2 Essential use case and documentation

The general idea of use case is to represent the intended sequence of the interaction between the
system and the world outside the system a description of a set or sequence of the actions,
including variants, which a system performs, yields an observable result of value to actor. Some
of the use cases are listed below: -

 Uc#1 Register customers

 Uc#2 Verify customer ID
 Uc#3 Request Payment
 Uc#4 Give certificate ID
 Uc#5 Receive annual payment
 Uc#6 Deposit Money
 Uc#7 Payment

13 | P a g e
Figure 1 use case diagram

2.2.3 Essential interface prototyping

An essential interface prototype, also known as an abstract prototype or paper prototype, is a

low-fidelity model, or prototype, of the UI for our system. It represents the general ideas behind
the UI, but not the exact details. Essential UI prototypes represent user interface requirements in
a technology independent manner, just as essential use case models do for behavioral
requirements. An essential user interface prototype is effectively the initial state-the beginning
point-of the user interface prototype for our system. It models user interface requirements,
requirements that are evolved through analysis and design to result in the final user interface for
our system, enabling us to explore usability aspects of our system.

14 | P a g e
Figure 2 Customer registration

2.2.4 Domain modeling with CRC

CRC model is a collection of CRC cards that represent whole or parts of the application or
problem domain. The most common use for CRC models, the one that is white paper address, is
to gather and to define the user requirements for object-oriented applications.

15 | P a g e
Table 3 CRC diagram for customer

Customer
First name Customer registration form
Middle name
Last name
Age
Sex
Address
Phone no
Email
Image
Register
Pay
View certificate ID
Send complain

Table 4 CRC diagram for certificate ID

Certificated ID
First name Customer
Middle name Manager
Last name
Address
Certificate IDNo
Issue date
View
Generate

Table 5 CRC diagram for user account

16 | P a g e
 User account
User name Customer
Password Manager
User type Administrator
Create HHI officer
Deactivate
Update
Delete

Table 6 CRC diagram for request pay

Request pay
Hospital name Hospital health insurance officer
Hospital account number
Health service
Send

Table 7 CRC diagram for complain

Complain
Complain id Customer
Date Manager
Content
Send

Table 8 CRC diagram for payment

17 | P a g e
 Payment
User name Customer
Date Manager
Amount
Number of family
Pay

2.2.5 Business rule

The business rule is a principle or a policy in which the system operates accordingly. It deals
with access control issues, operating policies and principles of the organization. Business rules
are statements about the agency’s way of doing business. It is also defined as effective
operating principle or polices that must be fulfilled and Obligated in order to the system will
function properly and effectively. 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 and get their own ID card.

BR2: The customer must pay the payment on time (October to January) and renew their ID
card.

BR3: The hospital that have contract with the health insurance must treat the members of the
insurance properly.

BR4: The insurance should also pay for the hospital according to the number of threated
customers.

BR5: The organization prepares reports to the higher officials weekly, monthly,
and yearly.

BR6: The organization employee must have companies ID.

BR7: The organization must announce payment and ID renewal date to the customer. BR7:
The organization employee should be punctual.

18 | P a g e
BR8: The organization employee must give service properly.

BR9: The organization employee should be transparent and accountable.

BR10: The organization employee must give full information to the customer.

2.3 Analysis of the new system

Even though there are many solutions are existing to solve existing system problem like android,
desktop based, we select to develop a system by web based for Assosa health insurance. The
completed project solves the problems that had affects the current system. Since it is web based,
it reduces a lot of costs released for paper, time to travel to the organization, work over load and
minimizes the space used to store the data.
The newly proposed system is web based that users can access the webpage through using global
network, local area network to register online, to send request, to get information about
organization in detail and access required information through organization’s database

2.3.1 Functional requirement

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 the customer. The system will take that
Identification Number. The system permits users to login according to their privilege.
 View customer’s information: - manager of the agency view customer information to
know how many customers are there or member of the agency.
 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 is pay for hospital according to their request.
 Generate certificate: - the agency provides certificate to the customer for the payment
that indicate the owner.

19 | P a g e
  View certificate: customer views their certificate or id and print it to use this certificate
when they want to 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.
 Send compliant: -A customer sends compliance to the agency if they have not got
sufficient service from hospital or other service that related to health insurance service.
 Support Amharic and English language: - the system allows the users to use the
language Amharic or English to access the system as they want.
 Store customer’s information in databases: - customer’s information must be stored in
database.
 Renewal insurance: -customer should renew their insurance when the life of the
insurance is finished.
 Request payment: -hospital health insurance officer send request for payment to the
agency according to the number of treated customers of the health insurance member.
 Update customer’s profile information: - customer can update their information when
new information occurs.

2.3.1.1 Use Case modeling

Use case modeling shows the interaction between the actors (customer, admin, manager, hospital
HI officer, hospital card officer and virtual bank) and the use cases which is found in our
proposed online health insurance management system. Our system is represented using a use
case modeling in the figure below:

Use Case modeling identify the functionality provided by the system (use cases), the users who
interact with the system (actors), and the association between the users and the functionality. Use
Cases are used in the Analysis phase of software development to articulate the high-level
requirements of the system and represent the functional requirements of the system
(nonfunctional requirements must be given elsewhere). The primary goals of Use Case modeling
include:

 Providing a high-level view of what the system does.

20 | P a g e
  Identifying the users or actors of the system.
 Determining areas needing human-computer interfaces.
 Validate a systems architecture
 Drive implementation and generate test cases

Use case is an activity that accomplished by actors. Use case describes a sequence of actions
that provide a measurable value to an actor. In the following table we try to list use case id, use
case name and its description.

Table 9 use case identification

Use case ID Use case name Uses /includes

UC-1 Registration
UC-2 Login
UC-3 Payment include
UC-4 Generate certificate include
UC-5 Manage account include
UC-6 Send notification include
UC-7 Send complaint Include
UC-8 View notification include
UC-9 View complaint include
UC-10 View payment include
UC-11 View customer information include

UC-12 Approve certificate include

UC-13 View certificate include

UC-14 Request payment include

21 | P a g e
Figure 3 Use Case modeling

22 | P a g e
 2.3.1.2 System Use case documentation

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 10 Use case description for Registration

Use case id UC-1

Use case Name Registration
Participating actors Customer
Description This use case describes the registration of customers.
Precondition The Customer should sing up to the system in order to register as the
customer of agency.
Basic course of action Actor action System response
step1: The Customer clicks on the Step2: The system initiates the
sing up link. registration form.
step4: Fills the required
Step3: The System displays the
information in the registration form
registration form.
and clicks Register button.
Step8: End of use case. Step 5: Transfer action.
Step6: Checks for the validity of the
registration form.
step7: Registers to the database.
Alternative course of If the registration of customer information is not valid then the display”
action error massage” and
Back to step 4
Post condition Registration is successful.

23 | P a g e
Table 11 Use case description for Login

Use case id UC-2

Use case Name Login
Participating actors Administrator, Manager, Hospital card officer, Hospital, HI officer,
Virtual Bank and customer
Description An administrator, Manager, Virtual Bank, Hospital card officer, Hospital,
HI officer and customer can 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.The user clicks on the login Step2: The system initiates the
link. login form.

step4. Enters username and Step3: The System display login

password and Click on Login form.
button.
step5: Transfer action
Step7: If the user ID and password
Step6: The system verifies User
are valid, they can will be logged in
Account.
to the system.
Step9: End of use case Step8: It redirects to the main page

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

action Back to step 4

24 | P a g e
 Post condition The user logged in to the login form

Table 12 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
Description account and agency to the hospital from their account.
The user should login to the system and should have an account. Besides the
Precondition agency should have an account.
Basic Course of
Action Actor Action System Response
step1: The user clicks on the payment Step2: The system initiates the
link payment form.
step4: The user fills the 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 Course If the account is not enough to pay displays the message “your account is not
of Action enough to pay”

Post condition Payment is already transferred from the customer account to the agency account
and agency account to hospital account.

25 | P a g e
 Table 13 Generating certificate use case description

Use case id UC-4

Use case name Generate certificate
Participating Actor Manager
Description The Manager 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 action User action System response

step1: The Manager clicks on the Step2: The system initiates the form.
certificate generating links. Step3. The system display certificate
Step4: Fills the required information generating form
on the certificate generating form Step5: Transfer action
and click submit button Step6: The system validates whether
Step7: Customer view the the generated data are found or no
certificate. found.
Step9: End of use case. Step8: The system generates a
certificate to the customer.
Post condition The customer receives the certificates.
Table 14 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 unauthorized access.
Precondition The users should log in to the system and administrator creates, update if
necessary, delete and restrict an authorized.
Basic course of action Actor action System response
Step1: The user clicks on the Step2: system initiates manage

26 | P a g e
 manage account link. account form.
Step4: The user selects a valid
Step3: The System displays
operational button value (create,
manage account form.
deactivate, activate or update)
account. Step5: transfer/send action
Step7: End of use case Step6: The system manages their
account.

An alternative course of action If the user did not select the needed operation
Back to step 4
Post condition “Account is managed successfully”
Table 15 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

Basic course of action Actor action System response

step1: The user clicks on the Step2: The system initiates notification
notification link. form.
step4: User fills the required Step3: The system displays the form.
information and click send button. Step 5: Transfer action.
Step7: end of use case
Step6: The system sent notification to
customers through their email.

27 | P a g e
An alternative course
of action If the time is too short” it is not the time for notification”.

Post condition
The notification message is sent to the customer.

Table 16 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 submit the complaint.
Basic course of action Actor action System response
Step1: The customer clicks on the Step2: The system initiates edit page.
complaint handling link. Step 3: The system displays the form.
Step4: The customer fills details Step5: Transfer action.
and click Step6: Checks the comment of the
Submit. customer.
Step8: End of use case. Step7: Save to database
An alternate course of If the input is invalid, the system displays” error message “and
action Returns back to basic flow of action 4
Post conditions User can successfully send their comments.

Table 17 View notification use case description

Use case Id UC-8

Use case name View notification

Participator Actor Customer

28 | P a g e
Description Customer can view notification that are notified from different staffs and also
can view new information sent to them by Chatting.

Precondition The Customer must login with its home pages.

Basic course of action Actor action System response

Steps1: Customer click on the view Step2: System initiates the form.
notification links in homepages button.
Step3: The system displays the
Step4: Check for notification if found or result.
not found.

Step5: Customer can see notification and

new information.

Step6: End of use case.

Post conditions The customer can successfully view notification and new information.

Table 18 View compliant use case description

Use case Id UC-9

Use case name View compliant

Participator Actor Manager

29 | P a g e
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.

Basic course of action Actor action System response

Steps1: The manager clicks on the view Step2: The system initiates the
massage button. form.

Step 3: check whether the complaint found or Step4: The system displays the
not found. result.

Step5: The manager can see the comment.

Step6: End of use case.

Post conditions Successfully viewed.

Table 19 View payment use case description

Use case Id UC-10

Use case name View payment
Participator Actor Manager, Hospital HI officer
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.
Basic course of action Actor action System response
Step1: The user clicks on the view payment Step2: The system initiates
button. the form.
Step 3: Check for weather found or not found. Step5: The system displays
Step4: If found the user can view for payment. the result.
Step6: End of use case.

30 | P a g e
Post conditions Payment can successfully view.

Table 20 Edit profile use case description

Use case Id UC-11

Use case name Edit profile
Participator Actor Customer
Description The customer can edit their profile photo.

Precondition Those Customer must login with its home pages.

Basic course of action
Actor action System response
Steps1: Customer click on the Step2: The system initiates the form.
edit profile link. Step3: The system displays the form
Step4: The Customer must fill Step5: Transfer action
the information they want to edit Step6: Check for validity while fill
and 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 21 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.

31 | P a g e
Precondition The Manager must login with its home pages.
Basic course of action Actor action System response
Step1: The manager clicks on view Step2: The system initiates the
customer information button. initiation form.
Step3: Check whether it’s found or not Step5: The system displays the
found result.
Step4: If found the manager can see the
customer information
Step6: End of use case
Post conditions Successfully viewed.

Table 22 Approve certificate use case description

Use case Id UC-13

Use case name Approve certificate

Participator Actor Hospital card officer

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 of action Actor action System response

Steps1: Hospital card officer click on Step2: The system displays the form.
the verify button.
step3: System displays verify form.
Step4: Fill information.
Step5: Transfer/send action.
Step8. End of use case.
Step6: Check if this customer is the
member of the agency.

Step7: Display required result.

32 | P a g e
An alternate course of If the customer is not a member of the agency then “display this customer is no
action membership”.

Post conditions Successfully approved.

Table 23 View certificate use case description

Use case Id UC-14

Use case name View certificate

Participator Actor Customer

Description Customer can view their certificate when you want.

Precondition That Customer must login with its home pages.

Basic course of action Actor action System response

Steps1: Customer click on the view Step2: The system initiates the form.
certificate link.
Step3: The system displays the result
Step4: The Customer can view their
certificate.

Step5: End of use case

Post conditions Successfully viewed.

Table 24 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
Description agency request payment for customer.

33 | P a g e
 Precondition The user must have full information about their expense.
Basic Course of Action Actor Action System Response
Step1: The user selects Step2: The system initiation the payment
request 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 of If invalid information were filled, the system displays error message to inform
Action the user to fill the correct value again.
Return back to step 4.
Post condition Success for request payment.

2.3.2 Non-functional requirement

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.

 Usability: -The system interface is interactive and easily understandable since it is

developed both in Amharic and English languages.
 Reliable: 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.
 Security: Adding, deleting, retrieving and updating of the customer’s information are not
allowed for unauthorized users. Only certain activities are permitted for authorized one
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.

34 | P a g e
  Error Handling: When a user interacts with the system errors may occur. To control this
kind of inaccuracies the application will generate different user-friendly message.
 User friendly- The system has an easily understandable design to satisfy the user.
 Scalability: The system must be compatible with environment.
 Reusability: Ability of an item that allows it to be used repeatedly.
 Performance: this system gives service 24 hours per day with maximum response time
so, it is easy to access data from the stored document.
 Accuracy: proposed system will be better due to reduction of error. All operation can be
done correctly and it ensures that whatever information is coming from the data base is
accurate.
 Availability: All data in the system will be available all the time.

2.3.3 Analysis Mode

2.3.3.1 System Sequence diagram modeling

UML Sequence Diagram is a type of Interaction Diagrams that describes the interaction between
objects and classes that are involved in the scenario and the sequence of messages exchanged
between them. It depicts the sequential flow of messages among objects and actors. It is used to
model one or more use cases and alternative course of events for a single use case.

Sequence diagrams are used to show how objects interact in a given situation. An important
characteristic of a sequence diagram is that time passes from top to bottom, the interaction starts
near the top of the diagram and ends at the bottom.

 Object: The boxes across top of the diagram represent classifiers or their instances;
typically use cases, objects, classes or actors.
 Lifeline: The Lifeline identifies the existence of the object over time. The notation for a
Lifeline is a vertical dotted line extending from an object.
 Activation: Activations, modeled as rectangular boxes on the lifeline, indicate when the
object is performing an action. 
 Message: M\messages, modeled as horizontal arrows between Activations, indicate the
communications between objects.

35 | P a g e
Generally, a sequence diagram shows object interactions arranged in time. It is an interaction
diagram that shows how processes operate with one another and in what order. It is a construct of
a Message Sequence Chart and shows object interactions arranged in time sequence. Sequence
diagrams are typically associated with use case realizations in the Logical View of the system
under development.

Figure 4 Sequence diagram for registration form

36 | P a g e
Figure 5 Sequence diagram for login form

37 | P a g e
Figure 6 Sequence diagram for payment form

38 | P a g e
Figure 7 Sequence diagram for manage account

39 | P a g e
Figure 8 Sequence diagram for generate certificate

40 | P a g e
Figure 9 Sequence diagram for send notification

41 | P a g e
Figure 10 Sequence diagram for send complaint

42 | P a g e
Figure 11 Sequence diagram for view notification

43 | P a g e
2.3.3.2 Activity diagram modeling

UML Activity Diagram is a type of Behavioral Diagrams that graphically describes

decomposition of some activity on the components. It provides a view of the behavior of a
system by describing the sequence of actions in a process. In UML, an activity diagram is used
to display the sequence of activities. Activity diagrams show the workflow from a start point to
the finish point detailing the many decision paths that exist in the progression of events
contained in the activity. They may be used to detail situations where parallel processing may
occur in the execution of some activities. Activity diagrams are useful for business modeling
where they are used for detailing the processes involved in business activities.

It illustrates the dynamic nature of a system by modeling the flow of control from activity to
activity. An activity represents an operation on some class in the system that results in a change
in the state of the system. Typically, activity diagrams are used to model workflow or business
processes and internal operation. Because an activity diagram is a special kind of state chart
diagram, it uses some of the same modeling conventions. Activity diagrams are mainly used as a
flow chart consists of activities performed by the system.

44 | P a g e
Figure 12 Activity diagram for customer registration

45 | P a g e
Figure 13 Activity diagram for customer Login

46 | P a g e
Figure 14 Activity diagram for customer payment

47 | P a g e
Figure 15 Activity diagram for send complain

48 | P a g e
Figure 16 Activity diagram for request payment

49 | P a g e
2.3.3.3 Conceptual modeling: class diagram

Class diagrams are refined by adding relationships between classes, attributes and methods.
Representing how objects of the static view are used to realize use cases in sequence diagrams.
Identify classes, attributes of each class, and operations of each class. It shows the static structure
of data and the operations that act on the system, i.e. it shows the static structure of an object-
oriented model the object class, their internal structure and the relationships in which they
participate. Class diagrams describe the structure of the system in terms of classes and objects.
Classes are abstractions that specify the attributes and behavior of a set of objects. Objects are
entities that encapsulate state and behavior. Each object has an identity. In the diagram, classes
are represented with boxes that contain three compartments:

1. Classes: The top compartment shows the class's name.

2. Attributes: The attribute section of a class (the middle compartment) lists each of the
class's attributes on a separate line. The attribute section is optional, but when used it
contains each attribute of the class displayed in a list format. The line uses the following
format.
3. Operations: The class's operations are documented in the third (lowest) compartment of
the class diagram's rectangle, which again is optional. Like the attributes, the operations
of a class are displayed in a list format, with each operation on its own line. 
4. Associations: An association relation is established when two classes are connected to
each other in any way. When you model a system, certain objects will be related to each
other, and these relationships themselves need to be modeled for clarity.

50 | P a g e
 Employee
Notification
+ID:varchar
+fname:varchar +message_Id:varchar
+mname:varchar +sender:varchar
+sender date:date time *
+lname:varchar
+status:varchar
+salary:currency +send()
+Email:varchar +view()
+get ID() 1
+get fname()
+get mname()
+get lname()
+get status()
Admin +get salary()
+get Email()
Name
Manager
1
+manage account() *
1 Customer
+view customer info()
1 +view payment() +CID No_: varchar
1 Account
1 +view complaint() +Fname: varchar
Certificate +Username: varchar +send notification() complaint +Mname: varchar
* -password: varchar +request payment() * +Lname: varchar
+Certificate_No_:varchar *
+role: varchar +generate certificate() 1 +comment_id:varchar +sex: varchar
+Issue date:datetime
+renewal insurance() +complaint date: date time +Address: varchar
+create () +content:varchar +Phoneno_: varchar
+update () 1 1 1 1
+view() 1 +Email: varchar
+deactivate () +send () +age:varchar+confirm
+generate()
+activate () +view() +image:image
+verify()
* 1 1
* +register()
1 +pay()
+view certificate()
+send compliant()
Hospital Employee 1 +view notification()
+Hos_ID:varchar +edit profile()
+Fullname:varchar 1
+Account no:varchar()
+Email:varchar
+get Hos_ID()
+get Fullname()
+get Account no()
Name 1
+get Email()
* * Virtual Bank
payment
1 1 1 Request pay account no_:varchar
1 1 +account no_:varchar
Hospital card officer Hospital HI officer 1 1
+Hospitalname:varchar +recive account:varchar 1 +bank name:varchar
+account no:varchar Balance:flaot
+paid:datetime *
+amount:float +amount:float +check account()
+withdraw()
+request payment() +send() +pay()
+verify certificate() +deposit()
View payment()

Figure 17 Class diagram

51 | P a g e
2.3.3.4 User interface prototyping

A user interface prototype for a health insurance management system could include the
following elements:

1. Login Screen: This would be the first screen that the user sees. The user would need to enter
their login credentials to access the system.

2. Dashboard: This screen would provide an overview of the user's health insurance policy,
including details such as coverage amount, deductibles, copayments, and claims history.

3. Claims Submission Form: This screen would allow the user to submit a new claim for
medical expenses. The form would include fields for entering the patient's name, date of birth,
medical provider, and a description of the services received.

4. Claims Status Tracker: This screen would allow the user to track the status of their claims,
including whether they have been approved or denied.

5. Provider Search: This screen would allow the user to search for medical providers in their
network based on location, specialty, and other criteria.

6. Policy Details: This screen would provide detailed information about the user's health
insurance policy, including coverage limits, benefits, and exclusions.

7. Billing and Payment: This screen would allow the user to view their billing statements, make
payments, and manage their payment preferences.

8. Account Settings: This screen would allow the user to update their personal information,
change their password, and manage their communication preferences.

Overall, the user interface should be intuitive, easy to navigate, and visually appealing, with clear
calls to action and consistent design elements throughout the system. The system should also be
optimized for mobile devices, as many users may prefer to access the system from their
smartphones or tablets.

52 | P a g e
2.3.3.5 User interface flow diagram

The user interface (UI) is the part of software which a user directly interacts with. In software
systems, user interface design represents user interface requirements. The user interface is the
visual image or form that contains data entry from the user to be executed in the database.

Figure 18 User interface

53 | P a g e
2.3.3.6 Identifying change cases

In order to identify change cases for a health insurance management system, you would need to
consider the different aspects of the system and the potential changes that could impact each
area. Some potential change cases for a health insurance management system could include:

1. Regulatory changes: Changes in government regulations could impact the way health
insurance companies operate. For example, changes to the Affordable Care Act or other
healthcare legislation could require changes to the way claims are processed, the types of
services covered, or the way premiums are calculated.

2. Insurance plan changes: Changes to insurance plans could impact the way claims are
processed or the types of services covered. For example, if a plan is changed to exclude coverage
for a certain type of procedure, the system would need to be updated to reflect that change.

3. Provider network changes: Changes to the network of healthcare providers that are covered by
insurance plans could impact the way claims are processed. If a provider is added or removed
from the network, the system would need to be updated accordingly.

4. Technology changes: Changes in technology could impact the way the system operates. For
example, if new software is introduced that would improve claims processing efficiency, the
system would need to be updated to integrate that software.

5. Customer service changes: Changes in customer service processes could impact the way the
system operates. For example, if there is a new process for handling customer complaints or
inquiries, the system would need to be updated to reflect that change.

6. Billing changes: Changes to the billing process could impact the way claims are processed or
the way premiums are calculated. For example, if there is a change in the way premiums are
calculated, the system would need to be updated to reflect that change.

By considering these potential change cases, you can identify the different areas of the health
insurance management system that may need to be updated or modified to keep the system
functioning effectively and efficiently.

54 | P a g e
Chapter three: System Design
3.1 Introduction

In this chapter we will deal with different design structures of the proposed system that indicate
how the system is designed, data is retrieved from the database, client and server are interacted
with the system and how deploying and decomposing is structured. The main idea of this system
design document is to describe the system design activities to be carried out during the design
phase of the System. It contains simultaneous sections the former section of the document
depicts the design to be considered in the implementation phase of the project that is the primary
design goal. The second section of the document describes the proposed system which is the
system to be developed. In this section there are a lot of structural issues to be talked about. It
describes the subsystems that will be combined to make the whole system. It depicts the
architecture of the database and the applications. It explains the persistent data management,
design of the system and how access is going to be controlled among the different users of the
system towards the operations. At the end of the chapter sample interface design will be
described.

3.2 Purpose and goal of the design

The purpose of designing is to show the direction how the web page is built and to obtain clear
and enough information needed to drive the actual implementation of web page. It is based on
understanding of the model the web page built on system design also focuses on decomposing
the system in to manageable parts.

The major design goals of the proposed online health insurance information management system
are Good response time, low cost, minimize error, flexibility, Maintenance criteria, security,
availability, simplicity, memory utilization and to handle redundancy.

Good response time: this health insurance management system will be implemented by PHP
programming language. The interfaces are designed such that information can be propagated

55 | P a g e
 efficiently. It avoids a user waiting time for wherever possible. It minimizes a lot of time for
doing all activates in health insurance management system.

Low cost: this proposed system will minimize cost, which is the cost, spent to the papers and
other materials which is used by the current manual system.

Minimize error: if the health insurance mangers as well as the customer person are using
manual system for managing health insurance, a lot of error will be occurred. But our system
will minimize error occurring.

Flexibility: the system should be flexible at any time.

Security: the system must be protected from an unauthorized access, threats, attacks and
vulnerabilities.

Availability: the system is available 24hour/7days.

Simplicity: the new system must be simpler to use and configure than the existing system.

Memory utilization: take less memory space.

Maintenance criteria: it can be maintained easily when changes arise from the user and
designer/developers it is not only when changes arise but also when we consider the non-
functional requirement

3.3 Deployment Diagram

Deployment diagram is used to visualize the topology of the physical components of a system
when the software components are deployed. The purpose of the deployment diagrams are used
for describing the hardware component where the software components are deployed. This
diagram shows the hardware system, the software that is installed on that hardware, and the
middleware used to connect the disparate machines to one another.

56 | P a g e
Figure 19 Deployment Diagram

3.4 Architectural design

The proposed system has connection stability, centralized database and client server architecture.
Software architecture intuitively denotes the high-level structures of the software system. The
architecture of the proposed project is the client–server. Clients initiate communication sessions
with server and request a server's content or service function. The client tier is the application
containing data entry forms and client-side applications. It interacts directly with the web server
to make requests and to retrieve data from the database of HIIMS. It displays data to the user
because Users interact directly with the application through the user interface.

There are so many architectures such as peer to peer architecture, MVC, two tier, three tire
architecture. two tier architecture has its own advantages in its easiness to maintain, easiness to
modify and also its communication is very fast. And in peer to peer individual components are
known as peers. Peers may function both as a client, requesting services from other peers, and as
57 | P a g e
a server, providing services to other peers. A peer may act as a client or as a server or as both,
and it can change its role dynamically with time. But we select 3 tier architecture because there 7
are several reasons that why we select three tier architecture than that of two-tier architecture
such as: - Offers higher flexibility as far as configuration and platform deployment is concerned
It offers higher level of security as client does not have access to the database directly and so on
are the reason why we chose three tier architecture. There is no performance degradation while a
number of users are going to access the system, Better reuse is possible

3.4.1. Subsystem decomposition

System decomposition is undertaken to reduce the complexity of the system and gaining insight
into the identity of the constituent components. The system is decomposed into sub-systems
which are a collection of classes, associations, operations, events and constraints that are closely
interrelated with each other. And the online health insurance management system contains the
following subsystems.

 Registration subsystem
 Manage account subsystem
 Payment subsystem
 Verify certificate subsystem
 Send notification subsystem
 Send compliant subsystem
 Generate certificate subsystem
 Renewal insurance subsystem
 Edit profile subsystem
 View subsystem
 Request payment subsystem

Registration subsystem: -in this case the customer is registered online to be a member of
the customers of the organization. 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.

58 | P a g e
Payment subsystem: - the customer makes payment from their account to the organization
account. The Agency gives certificate to the customer after they successfully pay them to the
organization. And also, organization is paid for hospital depend on to their request.

Generate Certificate subsystem: -The agency provides certificate to the customer for the
payment that indicate the owner of the certificate.

Verify subsystem: -If a customer goes to the hospital the hospital officer card checks the
customer Id or certificate weather it’s the customer is an insurer or not.

Send compliant subsystem: -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.

Send notification subsystem: - Send notification in order to have accurate response and
high-speed circulation the system should be supported with Gmail notification, example
when the system accepts new information then the manager sends notification to the
customer.

Manage account subsystem: system admin manages user account, create,

activate/deactivate and update user account.

Renewal Insurance subsystem: - customer should be renewed you insurance when the life
of insurance you choose finished.

Edit Profile subsystem: -customer can edit your profile picture when you went to change.

View subsystem: - Under this subsystem these view compliant, certificate, payment,
notification, and view customer information or operation are viewed

Request payment subsystem: - hospital sends request to agency for payment and agencies
are also sent a request to customer for payment.

59 | P a g e
 view Compaint
view certificate
Complaint
Register subsystem
subsystem Notification
subsystem
view payment

View subsystem
Verify certificate
subsystem
view customer
information
Edit profile
Online Health Insurance subsystem
Information Management System
View notification
Payment
subsystem
request payment
subsystem Manage account
subsystem
Certificate
renewal insurance subsystem
subsystem
Activate/Deactivate
Create

Figure 20 Subsystem decomposition

60 | P a g e
3.4.2. State machine diagram

UML State chart Diagram is a type of Behavioral Diagrams that displays the finite state machine
with states and state transitions. It is a view of a state machine that models the changing behavior
of a state. State chart diagrams show the various states that an object goes through, as well as the
events that cause a transition from one state to another.

The common model elements that state chart diagrams contain are:

 States
 Start and end states
 Transitions
A state represents a condition during the life of an object during which it satisfies some condition
or waits for some event. Start and end states represent the beginning or ending of a process.

State diagrams for registration State diagrams for registration State diagrams for registration

Figure 21 State diagrams for registration

61 | P a g e
3.4.3. Communication modeling /collaboration diagram

Collaboration occurs between objects when one object asks another for information or to do
something. Objects collaborate with one another by sending message to each other. A message is
either a request to do something or a request for information. A collaboration diagram look like a
flowchart that represents the roles, functionality and behavior of individual objects as well as the
overall operation of the system in real time. Objects are shown as rectangles with naming labels
inside. These labels are preceded by colons and may be underlined.

Figure 22 Collaboration diagram for login

62 | P a g e
Figure 23 Collaboration diagram for payment

3.4.4. Component modeling

Component diagram is a diagram that represents components in the system, relationship between
components and provides an interface.
Systems may be built from components in component-based architecture. Component diagram
shows how objects (classes) in our system will grouped together and form components. The
components interact with each other either in giving service to other components or requesting
service from another component. Component diagrams are particularly useful with larger teams.

63 | P a g e
Figure 24 Component diagram

64 | P a g e
3.4.6. Entity relationship diagram/database design

3.4.6.1 Data Design

Database design is the process of producing a detailed data model of a database. This logical data
model contains all the needed logical and physical design choices and physical storage
parameters needed to generate a design in a data definition language, which can then be used to
create a database.

Employee
notification ID bank
message_id Fname [account number]
ID MName bankname
[content] LName balance
senddate Status
Salary
email
username
compliant [account number]
commet_id hospital employee
Hos_id
[comment date]
fullname
[content]
sex
CID
email
username
[account number]
certificate [certificate number]
customer [certificate numb...
CID
ID
fname
CID
mname
[hospital name]
lname
sex
request
age
Hos_Id
Address
account_no_
[phone number]
amount
email
image
Account
username
username
password
[account number]
role

Figure 25 Database design

65 | P a g e
3.4.7. Access control and security

In the system, different actors have access to different functionality and data. Therefore, these
privileges prevent unauthorized users from accessing data’s which they have not granted to
access. In the access of the system, our system needs to be secured that different users have
different privilege so that we give a specific permission for each user to access the system.

Table 25 Access control and security

Responsibility Actor
Admin Manager Customer Virtual Hospital Hospital
Bank card officer HI officer
Register 
Manage account 
Verify certificate 
Send compliant 
Send Notification 
Generate certificate 
Edit profile 
Payment   
Request payment 
View Certificate 
Renewal insurance 
Verify certificate 
View notification 
View payment  
View complaint 
View customer 
information

66 | P a g e
3.5 User interface design

User interface design (UI) or user interface engineering is the design of user interfaces for
machines and software, such as computers, home appliances, mobile devices, and other
electronic devices, with the focus on maximizing usability and the user experience. The goal of
user interface design is to make the user's interaction as simple and efficient as possible, in terms
of accomplishing user goals (user-centered design).

Figure 26 Login form page

67 | P a g e
Figure 27 Registration page form

3.6 Algorithm design

Pseudo code: is a detailed yet readable description of what a computer program or algorithm
must do, expressed in a formally-styled natural language rather than in a programming language.
Pseudo code is sometimes used as a detailed step in the process of developing a program. It
allows designers or lead programmers to express the design in great detail and provides
programmers a detailed template for the next step of writing code in a specific programming
language. The purpose of using pseudo code is that it is easier for people to understand than
conventional programming language code, and that it is an efficient and environment-
independent description of the key principles of an algorithm.

68 | P a g e
Pseud code for login

Fill the Login Form

Click the Login button

If (Form is filled)

If (valid)

Generate SQL select queries

Connect to database

Pass queries to database

If (any query fails)

Display error message

Else

Read session

If session exists on database, user is already logged in, Display the page

Else

If they're correct

Create session ID

Store session ID on database

Display the page

End if

Else

Display error message

Ask the user to refill the form

69 | P a g e
Chapter-Four

4.Implementation and Testing

4.1 Implementation

In this chapter we only focus on the implementation part. The implementation phase is the most
crucial phase in which it transforms the design and analysis of the System into a tangible System
by writing the code to the System to be developed and make it operational and applicable by
testing and debugging the functionalities that are done. It is a systematically structured approach
to effectively integrate software-based service or component into the workflow of an
organizational structure or an individual end-user. This makes the implementation stage more
essential step to develop the required System. So, it is the most vital and necessary in achieving a
successful System that will work and be effective by testing the System that is already
implemented.

70 | P a g e
Figure 28 Home page

71 | P a g e
Figure 29 Login page

72 | P a g e
Figure 30 Admin Display account page

73 | P a g e
Sample code
The following is Sample Code for Login:

<?php

session start ();

include once 'dbconnect.php';

if(isset($_SESSION['customer'])! ="")

header ("Location: customer_home.php");

else if(isset($_SESSION['admin'])! ="")

header ("Location: admin_home.php");

else if(isset($_SESSION['manager'])! ="")

header ("Location: manager_home.php");

else if(isset($_SESSION['hospital_hi_officer'])! ="")

header ("Location: hospital_hi_officer_home.php");

else if(isset($_SESSION['hospital_card_officer'])! ="")

74 | P a g e
 header ("Location: hospital_card_officer_home.php");

if(isset($_POST['btn-login']))

$username = mysql_real_escape_string($_POST['uname']);

$upass = mysql_real_escape_string($_POST['pass']);

$username = trim($username);

$upass = trim($upass);

$res=MySQL query ("SELECT User_ID, First Name, User type, Status, Password
FROM Users WHERE Username='$username'");

$row=mysql_fetch_array($res);

$count = mysql_num_rows($res); // if uname/pass correct it returns must be 1 row

$status=$row['Status'];

if ($count==1 && $status=="De-Active”) {

?>

<script>alert ('Sorry!!! Your account has been de-activated please contact your
Administrator!!’) ;</script>

<?php

else {

75 | P a g e
 //nested if

if ($count == 1 && $row['Password’] ==md5($upass) && $row ['User type’]

=='customer')

$_SESSION['customer'] = $row['User_ID'];

header ("Location: customer_home.php");

if ($count == 1 && $row['Password’] ==md5($upass) && $row ['User type’]

=='admin')

$_SESSION['admin'] = $row['User_ID'];

header ("Location: admin_home.php");

// if we register from backside or from database, password is not encrypted so we avoid

md5

if ($count == 1 && $row['Password’] ==$upass && $row ['User type’] =='admin')

$_SESSION['admin'] = $row['User_ID'];

header ("Location: admin_home.php");

if ($count == 1 && $row['Password’] ==md5($upass) && $row ['User type’]

=='manager')

76 | P a g e
 $_SESSION['manager'] = $row['User_ID'];

header ("Location: manager_home.php");

if ($count == 1 && $row['Password’] ==md5($upass) && $row ['User type’]

=='hospital_hi_officer')

$_SESSION['hospital_hi_officer'] = $row['User_ID'];

header ("Location: hospital_hi_officer_home.php");

if ($count == 1 && $row['Password’] ==md5($upass) && $row ['User type’]

=='hospital_card_officer')

$_SESSION['hospital_card_officer'] = $row['User_ID'];

header ("Location: hospital_card_officer_home.php");

else

?>

<script>alert ('Username / Password Seems Wrong!’) ;</script>

<?php

77 | P a g e
 }

?>

<!DOCTYPE html>

<html lang="en">

<head>

<! -- Required meta tags -->

<meta charset="utf-8">

<meta name="viewport" content="width=device-width, initial-scale=1">

<! -- Bootstrap CSS -->

<link href="bootstrap-5.0.0-beta1-dist/css/bootstrap.min.css" rel="stylesheet" >

<link href="bootstrap-5.0.0-beta1-dist/css/bootstrap.css" rel="stylesheet" >

<link href="bootstrap-5.0.0-beta1-dist/css/bootstrap.grid.css" rel="stylesheet"

integrity="sha384-
giJF6kkoqNQ00vy+HMDP7azOuL0xtbfIcaT9wjKHr8RbDVddVHyTfAAsrekwKmP1" cross
origin="anonymous">

<title>የኢትዮጵያ የጤና መድህን ድርጅት በአሶሳ ቅርንፍ</title>

</head>

<body style="background: #E5E4E2">

<div class="container mt-4 mb-4 bg-light">

<?PHP

include "header.php";

78 | P a g e
 ?>

<?PHP

include "navbar.php";

?>

<div class="container ">

<div class="row ">

<div class="col-7 ">

<?PHP

include "carousel.php";

?>

</div>

<div class="col-5 ronded border border-dark border-5"><html>

<head> </head>

<body>

<div id="login-form">

<form method="post">

<field set >

<div class="row g-4 p-4 mb-2 mr-4">

<div class="col-12">

<legend><center> Login Form </center></legend>

79 | P a g e
 </div>

<div class="col-3">

<label class="form-label h6"> Username: </label>

</div>

<div class="col-9">

<input type="text" name="uname" placeholder="Your uname" class="form-control"

required />

</div>

<div class="col-3">

<label class="form-label h6 "> Password </label>

</div>

<div class="col-9">

<input type="password" name="pass" placeholder="Your Password” class="form-control"

required />

</div>

<div class="col-3" ></div><div class="col-5 d-grid gap-2" >

<input type="submit" name="btn-login" value="Log In" class="btn btn-primary">

</div>

<div class="col-4 d-grid gap-2” >

<input type="reset” name="reset" value="Reset" class="btn btn-info" >

</div>

<div class="col-4" ></div> <div class="col-4 “>

<a href="forget_password.php">Forget Password? </a>

80 | P a g e
</div>

<div class="col-4" ></div><div class="col-3" ></div><div class="col-9” >

<a href="register_customer.php" class="btn btn-success d-grid gap-2" >Sign Me Up</a>

</div>

</div>

</fieldset>

</form >

</div>

</body>

</html>

</div>

</div>

<div class="col-12 “>

<?PHP

include "card.php";

?>

</div>

<?PHP

include"footer.php";

?>

</div>

<! -- Option 1: Bootstrap Bundle with Popper -->

81 | P a g e
 <script src="bootstrap-5.0.0-beta1-dist/js/bootstrap.bundle.min.js"

integrity="sha384-ygbV9kiqUc6oa4msXn9868pTtWMgiQaeYH7/t7LECLbyPA2x65Kgf80OJF
droafW" crossorigin="anonymous"></script>

</body>

</html>

4.2 Testing

The test design will be done by giving possible combinations of inputs in order to find out what
will be the system response for a particular input and compare the expected result with the actual
output.

4.2.1 Unit Testing

Unit test is a way of testing each of the system functionality independently. Accordingly, the
team has tested each one of the major activities and the rest accompanying activities
independently using different user input, different login mechanisms and any technique of fault
finding so that an incorrect functioning of the activities was corrected at the right time.

In the test-design specification, there are criterions for the tests to discover pass/fail. The
standard terminologies for pass/fail are:
• If the actual outcome and the expected result are the same, the pass/fail criteria are “pass”

• If the actual outcome and the expected result are different, the pass/fail criterion is “failing”.
4.2.2 Integration Testing

This section presents the integration testing where the units are tested together to see that they
interact correctly. And the linkage between the modules occurs through the usage of the database
and the interface subsystem.

Integration and system testing: one’s the modules of the software tested the overall system tested
and integrated with software and other system. While we test the system in particular module
(instructor evaluation) we insert inputs then the system responds us an output.

82 | P a g e
4.2.3 Test cases
Table 26 Test case for login
Test case:1
Test Case Name: Login
Purpose: To verify (authenticate) authorized users
Input
Valid user name and
password combination accept the user and
Valid user name and
invalid Password
Incorrect user name
and valid Password
Incorrect user name
and Incorrect
Password
Null user name and
Password
User name and null
Password
Table 27 Test case for create account
Test case 2:
Test Case Name: Create Account
Purpose: To create account
Input
Valid user name,
password, Name,
Expected result Output Pass/fail
The system Successfully The system successfully Pass
accepts the user and
display the user page display the user page
The system displays” The system displays” pass
Invalid User Name or Incorrect User Name
Password” and/or Password”
The system display” The system display” pass
Incorrect User Name or Incorrect User Name
Password” and/or Password”
The system display” The system display” pass
Incorrect User Name or Incorrect User Name and
Password” Password”
The system displays The system displays pass
“Please fill username” “Please fill username”
The system displays The system displays Pass
“Please fill password “ “Please fill password”
Expected result Output Pass/fail
The system Successfully The system Successfully Pass
accepts the detail data to accept the user and create
83 | P a g e
Email create account their account
Valid user name, The system displays” The system displays” Pass
password, name and Invalid Email Invalid Email”
invalid email
Valid user name, The system display” The system display” Pass
name and weak Password strength is weak” password strength is
password weak”
Null user name, The system display” All The system display” All Pass
password, Role and information is required” information are required”
email
Duplicate user name The system displays “the The system displays “the Pass
username is already username is already
available by someone” available by someone”
Input password as The system displays The system displays Pass
normal text. “encrypts the password to “encrypts the password to
database” database”

Figure 31 Test case for payment handling

Test case :3
Test Case Name: Payment handling
Purpose: To pay
Input Expected result Output Pass/fail
Valid account The system displays it “you The system displays it Pass
number, and invalid have no enough for “you have no enough for
amount. payment”. payment”.
Valid account The system displays” You The system displays” You Pass
number amount have entered invalid name have entered invalid name
“
invalid account The system displays” You The system displays” You Pass
number and amount have entered incorrect have entered incorrect

84 | P a g e
 account number” account number”
Duplicate payment The system display” You The system display” You Pass
are not allowed to pay. ” are not allowed to pay”
Valid account The system displays” You The system displays” You Pass
number, valid name have paid successfully.” have paid successfully.”
and valid amount

4.2.4 Sample test scripts

Login Page Script

Customer Payment Page Script

85 | P a g e
Chapter-Five

5.Conclusion and Recommendation

5.1 Conclusion

This project has given us vast knowledge on the different computing technologies. We have
learned a lot during the documentation of this system project.

Our system project enables the customer’s registering himself/herself for increasing member in
advance, fast to access, highly secure, easy to maintain all information of customers, highly
efficient and flexible. The use of online health insurance information management system has the
capability to reduce or remove unwanted human errors. In addition to its reliability, online health
insurance can handle multiple modalities, and provide better scalability for large elections.
Online health insurance management system is also an excellent mechanism that does not require
geographical proximity of the customers. We were also able to learn a lot of system analysis and
design of the project, and all about object-oriented concept with database. We came to know the
different issues that come in the way of the development of the online voting system. Security
was the main issue in the development of this project and we conclude that if these issues are
taken into consideration, online health insurance management system will become and real-life
system from just more a project.

5.2 Recommendation

In general, this project contributes an initial work on online health insurance management system
for Assosa branch. But, this work needs to mature in other similar projects in the future, to be
scaled up to the whole country. It is recommended also that the government will take this
opportunity to entertain such alternative health insurance management system with other security
methods.

Neatly, the team would recommend that further work should be done on the System in order to
make the System perform better.

86 | P a g e
 We recommend that the System have better performance, if some features like online
malfunctioned Material detection is added on it.
 We also recommend that the next developer who concerning on it should include all activities
which are performed on Health Insurance.

87 | P a g e
Reference and Appendices

Reference

1. M. Fowler, UML Distilled: A Brief Guide to the Standard Object Modeling Language,
3rd ed., Addison-Wesley, Reading, MA, 2003.
2. Ponniah P, “Database Design and Development: An Essential Guide for IT
Professionals”, ISBN 0-471-21877-4 Copyright © 2003 by John Wiley and Sons, Inc.,
(2003).
3. M. Jackson, Software Requirements & Specifications: A Lexicon of Practice,
Principles and Prejudices. Addison-Wesley, Reading, MA, 1995.
4. IEEE Standard for Developing Software Life Cycle Processes, IEEE Computer Society,
New York, 1995, in [IEEE 1997].

Appendix

Sample interview questions to elicit requirement for online health insurance information
management system.

1. When Health Insurance Agency was established?

2. How does the system actually work?
3. What is the main goal of the agency?
4. Who is the main user of the system?
5. Where customrs information is stored?
6. What is the responsibility of employees?
7. How much times the system work per day?
8. How many customers serve the system per day?
9. Is there any computerized system today?
10. What problem occurs during finding and updating of customer’s information?
11. How customers can replace their ID card if their id is stolen or misplaced?
We distribute the above question for organization director in the agency.

88 | P a g e