Cep Tiles Documentation

HAWASSA UNIVERSITY INSTUTE OF TECHNOLOGY
FACULITY OF INFORMATICS DEPARTMENT OF COMPUTER SCIENCE
PROJECT TITLE:- MOBILE BASED PATIENT FOLLOWUP SYSTEM
Group members
1. Tilahun Solomon Evcs/158/09

2. Tadessa Gezehagn Evcs/144/09
3. Erdaw Girma Evcs/184/09
PROJECT ADVISOR: Getabalew Amtate
A senior project (Final document)
Project papar Submitted to Department of Computer Science Hawassa University, in Partial ful-
fillment for the requirement of the Degree of Bachelor Science in computer science.
Hawassa Sidama ,Ethiopia

May 18,2021
Mobile based patient followup system 2021
ADVISER APPROVAL
I approve that this industrial project report entitled “MOBILE BASED PATIENT FOLLOWUP
SYSTEM!” by:
Name Signature
1.Tilahun solomon
2.Tedasse Gezahegn
3.Erdaw Girma
is approved by me for submission. I certify further that, to the best of my knowledge, the report
represents work carried out by the students.
__________________ _________________________ Getabalew Amtate(MSc)
Date Signature Name of Adviser
Examining committee members’ Signature
1.
2.
3.
4.
It is approved that this project has been written in compliance with the formatting rules laid
down by the university
ii
Acknowledgments
We would like to thank GOD for giving strength to complete this project .we are also grateful
to my advisor Mr. Getabalew Amtate for his motivative and constructive guidance as of the be-
ginning of problem formulation to the completion of the documentation. Also we sincere grati-
tude also goes to Computer Science department staff and my classmates for their cooperation
and encouragement in the course of our graduate study. Our special thanks for different healthy
profitionals that they gives direction to collect data for our project and to conduct open interview.
Finally, we would like to extend our thanks to our parents for their encouragement, motivation
and support throughout my study.
iii
Contents
CHAPTER ONE: INTRODUCTION..............................................................................................1
1.1. BACKGROUND..............................................................................................................1
1.2. STATEMENT OF THE PROBLEM................................................................................2
1.3. Objective of the project.....................................................................................................3
1.3.1. . GENERAL OBJECTIVE........................................................................................3
1.3.2. SPECIFIC OBJECTIVES..........................................................................................3
1.4. SCOPE..............................................................................................................................3
1.5. Limitation of the study......................................................................................................4
1.6. METHODOLOGY............................................................................................................4
1.6.1. Data Collection Methodology....................................................................................4
1.6.2. System Analysis and Design Mythology...................................................................5
1.6.3. System Implementation.............................................................................................5
1.6.4. Testing and Deploying Methodology........................................................................5
1.6.5. Development Environment........................................................................................5
1.6.6. System Requirements................................................................................................6
CHAPTER TWO: DESCRIPTION OF EXISTING SYSTEM.....Error! Bookmark not defined.
2.1. Introduction of the existing systemS....................................................................................7
iv
2.2. Proposed system description................................................................................................7
2.3. Strength of existing system..................................................................................................8
2.4. Weakness of existing system...............................................................................................8
CHAPTER THREE: SYSTEM FEATURES................................................................................10
3.1. Introduction.....................................................................................................................10
3.2. Functional Requirements................................................................................................10
3.3. Non-Functional Requirements........................................................................................11
3.4. Analysis Models..............................................................................................................12
3.4.1. Use Case Diagrams..................................................................................................12
3.4.2. Sequence Diagram...................................................................................................31
3.4.3. Activity Diagram.....................................................................................................43
3.4.4. Class Diagram..........................................................................................................44
3.4.5. User Interface Design..............................................................................................45
CHAPTER FOUR: SYSTEM DESIGN...................................................................................46
4.1. Introduction........................................................................................................................47
4.2. Purpose of the System Design Document..........................................................................47
4.3. Scope of the project...........................................................................................................47
4.4. Architectural Design..........................................................................................................48
v
4.4.1. Logical View of the Architecture.................................................................................48
4.4.2. Process View................................................................................................................49
4.4.3. Deployment View.........................................................................................................49
4.4.4. Database Design...........................................................................................................50
LIST OF TABLES USED IN THE DATABASE.........................................................................51
CHAPTER FIVE : CONCLUSION AND RECOMMANDATION.............................................54
5.1. CONCLUSION..................................................................................................................54
5.2. Recommendation...............................................................................................................55
References......................................................................................................................................56
vi
List of figure
FIGURE 3-0-1 :USE CASE DIAGRAM FOR PATIENT FOLLPOW UP SYSTEM.......................................................................14
FIGURE 0-2: ACTORS LOGIN SEQUENCE DIAGRAM........................................................................................................32
FIGURE 0-3: ADMIN ADD NEW USER.............................................................................................................................32
FIGURE 0-4: ADMIN DELETE USER..............................................................................................................................33
FIGURE 0-5: EDIT USER SEQUENCE DIAGRAM ..............................................................................................................33
FIGURE 0-6: ADMIN CHANGE PASSWORD......................................................................................................................34
FIGURE 0-7: PATIENT DOWNLOAD FORM SEQUENCE DIAGRAM.....................................................................................34
FIGURE 0-8: PATIENT READ FORM SEQUENCE DIAGRAM...............................................................................................35
FIGURE 0-9: PATIENT REGISTER FORM SEQUENCE DIAGRAM........................................................................................35
FIGURE 0-10: PATIENT EDIT FORM FORM SEQUENCE DIAGRAM....................................................................................36
FIGURE 0-11: PATIENT UPLOAD FORM SEQUENCE DIAGRAM.........................................................................................36
FIGURE 0-12: PATIENT APPOINTMENT VIEW FORM SEQUENCE DIAGRAM......................................................................37
FIGURE 0-13: DOCTOR PENDING FORM SEQUENCE DIAGRAM.......................................................................................37
FIGURE 0-14: DOCTOR SEND RESULT SEQUENCE DIAGRAM.........................................................................................38
FIGURE 0-15: DOCTOR DELETE RESULT FORM SEQUENCE DIAGRAM.............................................................................38
FIGURE 0-16: DOCTOR PATIENT APPOINTMENT SEQUENCE DIAGRAM..........................................................................39
FIGURE 0-17: DOCTOR PRESCRIPTION SEQUENCE DIAGRAM........................................................................................39
FIGURE 0-18: PATIENT REGISTRATION SEQUENCE DIAGRAM.......................................................................................40
FIGURE 0-19: RECEPTION SERVICE PAYMENT SEQUENCE DIAGRAM..............................................................................40
vii
FIGURE 0-20: PHARMACIST ADD DRUG SEQUENCE DIAGRAM......................................................................................41
FIGURE 0-21: PHARMACISTSALE DRUG SEQUENCE DIAGRAM.....................................................................................41
FIGURE 0-22: PHARMACIST REMOVE DRUG SEQUENCE DIAGRAM................................................................................42
FIGURE 0-23: ACTORS LOGOUT SEQUENCE DIAGRAM...................................................................................................42
FIGURE 0-24: ACTIVITY DIAGRAM PATIENT FOLLOW UP SYSTEM.................................................................................43
FIGURE 0-25: CLASS DIAGRAM FOR PATIENT FOLLOW UP SYSTEM...............................................................................44
FIGURE 0-26: WEB USER INTERFACE DIAGRAM FOR PATIENT FOLLOW UP SYSTEM.................................................45
FIGURE 0-27: MOBILE USER INTERFACE DIAGRAM FOR PATIENT FOLLOW UP SYSTEM.............................................46
FIGURE 0-19: DEPLOYMENT DESIGN DIAGRAM..........................................................................................................49
FIGURE 0-20: ENTITY RELATIONSHIP DIAGRAM OF DATABASE FOR MOBILE BASED PATIENT FOLLOW UP...................50
viii
List of table
TABLE 1. SOFTWARE REQUIRMMENT..............................................................................................................................5
TABLE 2.HARDWARE REQUIRMENT.................................................................................................................................6
TABLE 3:ACTORS AND WITH THEIR DESCRIPTION.........................................................................................................13
TABLE 4: LOGIN TABLE FOR ACTORS’ DESCRIPTION TABLE..........................................................................................15
TABLE 5: PATIENT DOWNLOAD FORM DESCRIPTION TABLE..........................................................................................16
TABLE 6: PATIENT REGISTER FORM DESCRIPTION TABLE............................................................................................17
TABLE 7: PATIENT EDIT FORM DESCRIPTION TABLE....................................................................................................18
TABLE 8: PATIENT UPLOAD FORM DESCRIPTION TABLE...............................................................................................19
TABLE 9: PATIENT APPOINTMENT VIEW FORM DESCRIPTION TABLE............................................................................20
TABLE 10: PATIENT READ RESULT FORM DESCRIPTION TABLE.....................................................................................21
TABLE 11: PATIENT DELETE FORM DESCRIPTION TABLE...............................................................................................22
TABLE 12: HEALTH PROFESSIONAL READ PENDING FORM DESCRIPTION TABLE.........................................................23
TABLE 13: HEALTH PROFESSIONAL SEND RESULT FROM DESCRIPTION TABLE..............................................................24
TABLE 14: HEALTH PROFESSIONAL SEND RESULT FROM DESCRIPTION TABLE..............................................................25
TABLE 15: SYSTEM ADMIN ADD USER FORM DESCRIPTION TABLE................................................................................26
TABLE 16:SYSTEM ADMIN EDIT USER FORM DESCRIPTION TABLE................................................................................27
TABLE 17: SYSTEM ADMIN DELETE USER FORM DESCRIPTION TABLE...........................................................................28
i
TABLE 18:SYSTEM ADMIN CHANGE PASSWORD DESCRIPTION TABLE...........................................................................28
TABLE 19:PHARMACIST ADD DRUG DESCRIPTION TABLE.............................................................................................29
TABLE 20: PHARMACIST SALE DRUG DESCRIPTION TABLE............................................................................................29
TABLE 21: PHARMACIST REMOVE DRUG DESCRIPTION TABLE......................................................................................30
TABLE 22: PERCEPTION PATIENT REGISTRATION DESCRIPTION TABLE..........................................................................30
TABLE 23:PERCEPTION PATIENT SERVICE PAYMENT DESCRIPTION TABLE...................................................................30
TABLET 24 ADMIN........................................................................................................................................................51
TABLE 25. DOCTOR.......................................................................................................................................................52
TABLE 26. PATIENT.......................................................................................................................................................52
TABLE 27. RECIPITIONIST..............................................................................................................................................53
ii
List of Acronyms
AIDS -Acquired Immune Deficiency Syndrome
ARV -Antiretroviral
BPR- business processes reengineering
ER- entity relationship
GIS -graphic Information System
GSM -Global System for Mobile Communication
GPS -Global Positioning System
HIV -Human Immunodeficiency Virus
M-Health -Mobile Health
SQL – Structured Query Language
TB- Tuberculosis
UML- unified modelling language
Wi-F-i Wireless Fidelity
iii
CHAPTER ONE: INTRODUCTION
1.1. BACKGROUND
Healthcare quality, cost and patient safety are adversely affected and compromised by the current
largely paper-based system in Ethiopia. It is necessary to advice a solution that helps solve such
demoralizing problem. Mobile technology has been proposed in this regards as an essential tool
for addressing the problem of fragmented and inaccessible healthy center information. Electronic
health records, prescribing, clinical decision support systems, electronic management of trans-
mitted and chronic disease have been proposed to be employed as workable means to reduce
health care costs and improve patient safety by using mobie .
Nowadays, efficiency, cost-effectiveness, quality, and safety of medical care delivery in the
healthcare system are improved through mobile application and promises. Representatives of or-
ganizations and leaders at the federal and state levels have emphasized the need for healthcare to
follow the example of many non-healthcare industries, in which the implementation of computer
technology has been critical and employed for increasing accessibility of mission-critical infor-
mation, automating labor-intensive and inefficient processes, and minimizing human error.
Mobile phone usage and service coverage improve healthcare services even in remote and less
resourced settings. Mobile communication offers an effective means of bringing healthcare ser-
vices to developing countries. The penetration of mobile phone networks globally enables thou-
sands and millions of citizens, who never had regular access to fixed-line telephone, use mobile
devices as daily tools for communication and data transfer. Fifty two percent (52%) of all indi-
viduals in remote areas of the world will have mobile phones . This growing ubiquity of mobile
phones is a central element in the promise of mobile technologies for health. Current mobile
technology promise shows that mobile health technology will have demonstrable and signifi-
cantly positive impact on clinical outcomes such as reduced infant mortality, longer life spans
and decreased contraction of disease . In Ethiopia, fixed-line Internet connections are rare. But
1
GSM mobile signal coverage has reached to sixty-four percent (64%) of the total land area of the
country. This would enhance the possibility of increasing the efficiency and effectiveness of de-
livery of outpatient healthcare and decrease the substantial financial losses for healthcare sys-
tems. Moreover, it precisely uses clinical and administrative staff and results in reducing waiting
times for other patients. Here, managing long-term chronic condition and transmission diseases
by using mobile phone health system is the best solution. That is, treating chronic and transmis-
sion diseases needs a long-term communication with the patient and imposes additional burden
on the health system specifically as it needs to maintain a patient’s history and monitor his/her
progress. Particular at-risk groups are patients with covid -19, HIV, partially treated tuberculosis
(TB), or other chronic diseases and transmission diseases who are asymptomatic and may not
have the capacity to fulfill these requirements. This approach put strong challenge for chronic
and transmission diseases condition patients . This system is proposed to give solution and sup -
port for such patients.
1.2. STATEMENT OF THE PROBLEM
As there are more senior citizens and patients with chronic diseases in Ethiopia, the number of
people who need constant assistance increases. Also, patients that are being discharged from hos-
pitals and often require additional healthcare services including health status follow-up. Never-
theless, the current scenery depicts the long patient and operation waiting lists, shortages of hos-
pital beds, community care and inadequate medical facilities and professionals to provide pa-
tients with intensive care in emergency units and other healthcare departments. This leads to:
 A healthcare system that doesn’t support the monitoring and close watch of patient Care
 put the burden on patients to make their treatment and to return for follow-up visits
 find and pay for transport
 high costs involving the conventional internment
 Proposed system gives solution to these problems and to follow-up patients using mobile
phone.
2
1.3. Objective of the project
1.3.1. . GENERAL OBJECTIVE
The general objective of this project is to design and implement a mobile based patient follow up
system.
1.3.2. SPECIFIC OBJECTIVES
Specific objectives of the project include:
 Review related systems and conduct literature review.

 Identify the data which needs to be collected and identify the functional and non-
functional requirements of the system.
 Design the system based on the identified requirements.
 Develop a prototype to demonstrate the validity of the proposed design
 Test the developed prototype against its requirements
 Database management of the system and integrates the interaction
between client and server.
1.4. SCOPE
The system to be developed considers the patients that are discharged from hospitals and to fol-
low up their daily healthy status ,decreasing the transimmion of diseases in hospital and to moni -
tor them through their mobile phone with their respective location (including GPS coordinates).
On the server side, the system manages any communication between health worker and patients,
and gives privilege to diagnosis and access followed-up information. However, the system to be
developed:
 Doesn’t consider in-patient follow-up and treatment activities.
3
 Only works for android mobile phoneand Only considers English Language
 Only uses GPRS and Wi-Fi network.
1.5. Limitation of the study
The major limitation of this project was time and financial constraints. Because of this it was dif-
ficult to develop the system in including laboratory result and any activity in healthy center and
patient assigned before doctor.The system developed considering chronic and transmission dis-
eases and does not hold other non-chronic disease.
1.6. METHODOLOGY
1.6.1. Data Collection Methodology
. In this project different data collection methods were used to collect requirements from the
healthy centers. The data collection focused on the topics of service of outpatient follow up sys-
tem . In order to collect such data structured interviews, direct observation, written documents
that were available in the healthy center and from other literatures were used.
Interview: Interview is a more flexible data collection method than questionnaire if wisely used.
It can generally be used to collect information of better depth and can be more sensitive to con-
textual changes in meaning. Interviewing also permits things to be explained more face to face
than questionnaire . The interview was also used to know the personal interaction with the
healthy center process. The structured interviews were done with different respondents including
the medical director,doctor, other health professionals and plan and program officer.
Observation : was used to gather information which could not be collected by other data collec-
tion methods. Respondents may not be willing to express some sensitive information about their
organization such as deterioration of services quality because of fear of their supervisors. It is
also good to gather information about user interaction on the task and flow of information
among.different units of the organization.The observation was conducted in registration, TB
Clinic, Pharmacy,HIV ward. During observation the investigator recognized different types of
practice that was done in the healthy center .
4
Review of documents :is such as business processes reengineering (BPR) documents, annual
plan, patient registration books, outpatient and inpatient disease report, different records, reports
and tally sheet of patient documents of halaba primary hospital and to know the service and care
of patients so that the design of the framework could depend on these different documents. Dif-
ferent literatures were reviewed to understand the experience and practice of enterprise architec-
ture in health care organizations in different countries.
1.6.2. System Analysis and Design Mythology
Here for the analysis of our project we have selected system analysis and design method specifi-
cally WhiteStarUml and UML (Unified Modeling Language) model. We have selected this be-
cause of the following advantages: increased consistency among analysis, design and program-
ming activities. Improved communication among users, analysis, design and programming. To
simplify the design and implementation of complex program.To make it easier for teams of de-
signers and programmers to work in a single software project. To develop efficient mobile based
patient follow up system. To enable a high degree of reusability of designs and of software
codes. To decrease the cost of software maintenance and Increase reusability.
1.6.3. System Implementation
A tool in system development is system support that helps create models or other components
required in the project. The tools used for analysis and design in this project were. WhiteStarUml
and star Uml for drawing various modeling diagrams.
END :MYSQL Database Applications to store information .
FRONT:Development environment for this project is html , css, javascript used to design user
interface ,Java programming language in visual studio .
1.6.4. Testing and Deploying Methodology
The system is tested with different real data to meet the functional requirements which are iden-
tified in the requirement analysis. Moreover, this testing is used to find any kind of error that ex-
isted in the entire system development and to correct them. Individual testing is used to test the
functionality of each component (like Phone module, Diagnose Module and Dispatch Module).
After this test, integration test is used to ensure the various components of the system that work-
ing together. The Phone module is tested using android mobile phone. Where as, the Diagnose
and Dispatch Module are tested using web browsers (Firefox 3.5, Google Chrome 4.1, and In-
ternet Explorer 7) The communication between the mobile phone application and the server has a
fair response time even under slower Internet connection.
5
1.6.5. Development Environment
Table 1. Software requirmment
Name of component Specification

Operating system Windows 10
Language Php, html,css,javascrpit
Database MYSQL server
Browser Badu broser,opera,Mozilla Firefox
Scripting language Php
Table 2.Hardware requirment
Name of component Specification

Processer 2.50GHZ
RAM 4GB
Hard disk 32GB
Monitor 20GB
1.6.6. System Requirements.
I. System Requirement The system requirement includes the software and the hardware
that make the package being developed to run effectively. It also requires networking de-
vices that will enable connection within a Local Area Network (LAN).
II. Software Requirement
The software requirements are basically for both the server and clients. The server side requires
MySQL whereas the clients require only the android application. The following are the list:
III. Hardware Requirement This affects the usability and functionality of database on the pa-
tient follow system. The software runs on a standard hardware whether in time sharing
6
network, mainframe or minicomputers, thus the hardware requirements are: IBM Intel or
Microsoft compatible computers. A hard disk capacity of at least 2 GB, random access
Memory (RAM) size at least 64M.
CHAPTER TWO: DESCRIPTION OF EXISTING SYSTEM
2.1. Introduction of the existing system
Organizations which are in charge of facilitating condition to faster healthcare in Ethiopia could
be categorized either private or public. Public healthcare organizations operate in an environ-
ment, more bureaucratic and slower to change compared to private ones. They operate within
public service constraints, e.g. public and administrative laws, which have impacts on their plan-
ning, financing, and human resource management practices. Patients arrive physically in health
care organizations to start any kind of treatment. Even, they have to wait for hours, days, months
and years to get treatment after their first registration. There are different steps that patients fol-
low while they are in a Healthy center.
First, the patient should report to the receptionist to get registered and the receptionist assigns the
patient to specified doctors. Second, after they visit a doctor, patients follow either in-patient or
out-patient procedures. In-patients are expected to stay in the healthy center for days and get a
follow-up by their doctors until they recover from their problem. Whereas, out-patients, usually
get their treatment and stay in their home and be back to the healthy center on their appointment
schedule for further follow-up. Out-patients, especially patients coming from rural areas, need to
remember their schedule and travel long distance to arrive on time. Currently, public health care
organizations have employed manual and paper based system for patient registration and follow-
up. Moreover, they have no system to handle and follow-up out-patients since patients are in
their home and doctors in their office.
7
2.2. Proposed system description
The current system study shows that public healthcare organizations have a lot of problems. To
minimize the problems, the system to be developed (m-health) will support long term out-pa-
tients follow-up treatment activities and create remote reliable communication between health
workers and outpatients. System data health professionals can register patients and record any
type of patient treatment and diagnosis. Moreover, they can give follow-up and recommenda-
tions to their out patients in remote area chating with their mobile. This helps health profession -
als and organizations give quality of service on time, avoid patient crowding, and job dissatisfac-
tion and inefficient. Also, the system supports patients to communicate with their doctors while
they are at home using mobile phone. In so doing, patients can get follow-up services from their
home instead of returning to hospital. This helps patients avoid transportation cost, traveling long
distance and other related challenges. The proposed system is strongly believed to address the
very limited reach of specialists who are often confined within a few large cities in developing
countries. Follow-up of chronic conditions that may require technology not available in remote
areas will also be made easier with this system. It would also be instrumental in scaling up re-
mote real-time access to specialists. For example, follow-up of patients with multi-drug resistant
tuberculosis can be assisted by periodic chest x-rays and the system can assist the automatic up-
load of the x-ray into the electronic medical record for diagnosis.
2.3. Strength of existing system
Advantages of the existing System
The following are the out timed advantages of existing system:
1) .The patient take any treatment face to face with Doctor .
2). It offers the healthy center accurate laboratory results information on issues of patient and
provides suggestion to patient.
8
3) .Few healthy workers needed.
2.4. Weakness of existing system
Weakness of existing system Problems:-
The following are the weaknesses of the existing system at the healthy center for follow up pa-
tient system .The weakness is that it does not support the monitoring and close watch of patient
care. It puts the load on patients to take their treatment and to return for follow-up visits. Not
only, must the patient remember the date, find and pay for transport, and arrange child care, but
the patient must also understand the importance of the treatment and its plan .The problem ob -
served in the existing system has to do with cost, the startup costs are enormous. Patients can
wait for more than one hour to be attended to by a physician in a health care center, they also
can feel that they are being disregarded and treated unfairly. So when patients are given the
time of appointment in a health care center. The healthy center staff finds it tire some and time
consuming when computing patient data, drug supplier and staff Payment receipts and voucher
cards this leads to delay in medical reports. The healthy center Administration currently uses
health record files for storing patients and drug suppliers information. This system of informa -
tion storage is susceptible to security problems such as illegal modification and update of
records. The Staff usually waste a lot of time in retrieving data. The paper work red uce the
efficiency of the System
9
CHAPTER THREE: SYSTEM FEATURES
III.1. Introduction
A phased development methodology of object- oriented approach was applied to the study of the
design system. Interview and document analysis were used as the main tools to capture the busi-
ness system requirement along with observation. Unified modeling language (UML) develop-
ment techniques applied in the process of requirements capture, model organization business
system and design.whiteStarUml and starUML Software were employed in analysis and design
models diagramming. Besides, the study result disseminated to the responsible stakeholders by
considering ethical issues with the appropriate operational definition.
III.2. Functional Requirements
Functional requirements are the specific statement of service that defines how the system should
react to particular inputs and how it should behave in particular situations. In this section we
present these statements of service which correspond to the requirement analysis.
FR1 : ADMIN:-.Admin have the authorities to add new user, edit ,delete and change password.
He also provides username and password to the new registration except the patient. Furthermore
the user should change their previous password accordingly. Admin have some more authorities
to operate in the system.
FR2:DOCTOR:- Firstly doctor can be login to the system and perform tasks such as read pend-
ing from the patient ,send diagnose result,delete saved data,send prescription to the pharmacist
and manage patient appointment to follow up the patient.
10
FR3:PATIENT:-must be registered before you can access any service and after registration lo-
gin in to the system .the tasks performed by patient is download form ,read form ,register the ap -
proiprate data ,upload the form and view appointment appointed from doctor.
FR4: RECEPTION:- Once the reception module is login, Reception can do new registration and
taking all service payment from patients.
FR5: PHARMACIST:-: once the pharmacist can be login into the system it perform, add new
drug,sale drug for patient by taking paid receipt in receptionist and remove the exipired dia-
gram in the healthy center store.
III.3. Non-Functional Requirements
These requirements are not designed for the functional behavior of the system. They express how
well the system provides services to the users.User Interface and Human Issue . Patients
caneasily interact with the system using forms which run on mobile phone.Furthermore, health
professionals can access the system through web browsers on their personal computer. Both pa-
tients and health professionals can fill, save, edit, send and open forms and will have captions
both in English languages.
Performance :Different users can access the system for different or same issues. Unless there
are Internet connections, hardware and software requirement constraints, the system can support
many users and execute their queries at the same time.
Security : Mobile phone usually is owned by only one person. A privilege and password system
that is very flexible and secure, and that enables host-based verification. That is, patients must
enter their username and password to the system interface to access the system through their mo-
bile phone. Similarly, health professionals , system administrators,receptionistand pharmacist
can access the system through web browsers by using their username and password.
11
Maintainability; the system will be easily maintained by the developer as well as other autho-
rized trained person. The system will also be modifiable at any time to enhance features based on
the office needs. As needs change from time to time the original system will be made available to
fill the gap between the system and the newly emerging needs. The system could be enhanced by
adding new functionalities without necessarily changing the basics
User Interfaces; - This is basically concerned on what kind of Graphical User Interface (GUI)
the system should provide or what is the level of expertise of the user. Since the system is going
to be used by different user categories, it should have a very simple and user friendly interfaces
for everyone to understand the functionalities easily.
Privacy The privacy of patients’ data and information are secure through the system security. In
clear terms, any exchanged data between patients, health professionals , system administrators,
receptionist , pharmacist and health professionals are kept in system database and only autho-
rized person can access it.
Maintainability and Expandability :-Based on the system that advocates owner interest and ac-
tivities, the system will be maintained and expanded. In addition, the system designed using an
object oriented approach; any developer that is familiar with the code can maintain, expand and
modify it.
Error Handling: The system will help handle these errors through system exception handling
mechanisms and notify the appropriate solution. The error handling by provide error messages
to clients.
Usability: the mobile application for patient follow up system shall be easy to use and not re-
quire special computer skills. The system was designed in such way that it is easy to understand,
learn, remember and use its functions
12
III.4. Analysis Models
III.4.1.Use Case Diagrams
Use case diagram is a representation of a user`s interaction with the system and depicting the
specification of a use case. A use case diagram is helpful in visualizing the context of a system
and the boundaries of the system’s behavior.Its main purposes are used to gather requirements of
system; to get an outside view of a system; to identify external and internal factors influencing
the syste.To model the system using use case diagram, the following actors and use cases are
identified . An actor is idealization of an external person, process, or thing interacting with the
system and each actor can participate in one or more use cases. The researcher identified seven
actors in which each of them have their respective identified tasks in below table.
Table 3:Actors and with their description
No ACTORS DESCRIPTION
1 Patient A patient is an authorized user of the system through mobile
phone to get follow-up service at home and responsible for fill-
ing, saving, sending forms to the system and opening forms that
come from the system.
2 Health Professional This is a person who has an authorized access to the system and
responsible for patient follow-up by diagnosing patient’s request
and sending the result
3 System Administrator This is a person who is responsible for the function of the system
and to administer the system users.
4 Reception This is a person who is responsible for the function of the system
and to registering and taking service payment from patient.
5 Pharmacists This is a person who has an authorized access to the system and
responsible for add drug ,sale drug, remove drug and any activity
13
in pharmacy
Figure 3-0-1 :use case diagram for patient follpow up system
14
Table 4: Login table for actors’ description table
Use case name Login

Actor Patient, Health Professional, System Administrator ,pharmacist, recep-
tionist.
Description This allows to identify system users and to access system functionality.
Pre-condition The users must have username and password.

Flow of events 1. The system displays login form.
2. The user enters username and password.
3. The system validates users input.A1
4. The user logged in to the system.

AL 1. The system displays error message.
2. The user repeat step 2. Otherwise, the user terminates login form.
Post- condition Login will be done.
15
Table 5: patient download form description table
Use case Name Download form
Actors Patient
Description This allows patients to fill their follow-up status
Pre-condition The patient must be logged into the system
Flow of events 1. The patient selects the application to lunch it on the phone.
2. The system display user interface and menu.
3. The patient selects “Start New Encounter” to start filling.
4. The system displays all the available forms/procedures.
5. The patient Scroll through the list of available procedures and select one
procedure.
6. The patient fills his personal and follow-up case with different data format.
7. The patient selects “Save for Later Upload”A1
8. The system saves the filled form for future use.

A1 1. The patient selects “Upload” button to begin sending the illed form to the
server without saving.
Post-condition A form will be filled successfully.
16
Table 6: Patient register form description table
Use case Name Fill Form

Actors Patient
Description This allows patients to fill their follow-up status
3. The patient selects “Start New Encounter” to start filling.
4. The system displays all the available forms/procedures.
5. The patient Scroll through the list of available procedures and select one proce-
dure.
6. The patient fills his personal and follow-up case with different data format.
8. The system saves the filled form for future use.

A1 1. The patient selects “Upload” button to begin sending the illed form to the server
without saving.
Post-condition A form will be filled successfully.
17
Table 7: Patient edit form description table
Use case Name Edit Form

Actors Patient
Allow patient to edit the filled forms before sending it to the server.
Description The patient must be logged into the system
Pre-condition 1. The patient selects the application to lunch it on the phone.
3. The patient selects “View Saved Procedures”
4. The system display saved forms
. 5. The patient selects “View Page List” to go back to the beginning of the
procedure and edit all the answers entered.
7. The system saves the edited form for future use.

Flow of events 1. The patient selects “Upload to server” to begin sending it to the server
without saving.
A1 The system update/edit filed forms
Post-condition
18
Table 8: patient upload form description table.
Use case Name Upload Form

Actors Patient
Description Allow patient to edit the filled forms before sending it to the server.
3. The patient selects “View Saved Procedures”
4. The system display saved forms.
5. The patient selects “View Page List” to go back to the beginning of the
procedure and edit all the answers entered.
7. The system saves the edited form for future use.

A1 1. The patient selects “Upload to server” to begin sending it to the server
with out saving.
Post-condition The system update/edit filed forms
19
Table 9: patient appointment view form description table.
Use case Name Appointment view

Actors Patient
Description This allows patient to view appointment assigned from the doctor
Pre-condition 1. The patient must be logged into the system
2. The patient must fill the form.

3. The patient selects “View Saved Procedures” to view saved proce-

dures/forms.
5. The patient selects the filled form to be uploaded.
6. The patient select the menu to get upload button
7. The patient then hit “Upload” button to upload the form
8. The system sends the filled form to the server. Post

Post-condition The appointed appointment will be uploaded.
20
Table 10: patient read result form description table.
Use case Name Read Result

Actors Patient
Description Allows patient to read diagnose result message
which sent by his
doctor.
Flow of events 1. The patient selects the application to lunch it
on the phone.
3. The patient selects “View Notification” but-

ton to read the received messages.
4. The system displays the received messages

5. The patient selects “Save” button to after
reading the message.A1
6. The system save the message for future use

AL 1. The patient can discard the message after
reading by selecting “Discard” button
Post-condition Reading the received message
21
Table 11: Patient delete form description table.
Use case Name Delete Form

Actors Patient
Description This allows patient to send filled procedure to the server
3. The patient selects “View Saved Procedures” to view saved

procedures/forms
5. The patient selects the one of the saved forms to be delete 6. The patient
select menu.
7. The system display delete button.
8. The patient then hit “Delete” button
9. The system will delete the selected saved form.

Post-condition The saved form/procedures will be deleted.
22
Table 12: health professional read pending form description table.
Use case Name Read Pending

Actors Health Professional
Description This allows health professional to read pending diagnose which sent by
patients.
Pre-condition The health professional must be logged into the system.
Flow of events 1. The health professional selects Pending tab across the top menu bar
2. The system will display the pending cases.
3. The health professional selects one of the pending case
4. The system open the selected pending case
5. The health professional read and diagnose the case.A1

A1 1. The health professional selects “Retake” button to receive a
prompt to send a message to the patient who uploaded the case
Asking for more information before a diagnosis can be made.

Post-condition New pending case will be read.
23
Table 13: health professional send result from description table.
Use case Name Send Result

Description This allows health professional to send diagnosed result to patient.
Flow of events 1. The health professional selects Pending tab across the top menu
bar
2. The system displays all the pending cases.
3. The health professional selects one of the pending case
4. The system open the selected pending case
5. The health professional read and diagnose the case.
6. The health professional determine the urgency level of the

patient case as “emergency,” “urgent,” or “non-urgent.”
7. The health professional type diagnosis result and any other com-
ments.
8. The health professional selects “Send” button to send the result

to the patient
9. The system sends diagnosis result to the patient mobile phone

Post-condition The diagnosed result will be sent and the case status will be
24
changed into closed.
Table 14: health professional send result from description table.
Use case Name Delete Result

Description This allows health professional to delete closed cases.
Pre-condition The health professional must be logged into the system
Flow of events 1. The health professional selects Pending tab across the top menu bar
2. The system displays all the pending cases.
3. The health professional selects one of the closed cases.
4. The health professional selects “Delete” button to remove the selected

case.
5. The system deletes the case permanently.

Post-condition Delete the closed cases.
25
Table 15: system admin add user form description table.
Use case name Add User

Actors System Administrator
Description Allows system administrator to create new system users.
Pre- condition The system administrator must be logged in to the system.
Flow of events 1. The system administrator select “Administration” tab
2. The system display administration page.
3. The system administrator select “Add New User” button.
4. The system display new form
5. The system administrator fills new user profile and selects “Create”
button.
6. The system creates new system user.

Post- condition New system user will be added.
26
Table 16:system admin edit user form description table.
Use case name Edit user

Description Allows system administrator to edit registered system users.
Pre-condition The system administrator must be logged in to the system.
Flow of events 1. The system administrator select “Administration” tab
3. The system administrator identifies the user whose profile will be

edited.
4. The system administrator edits the user profile and clicks “Update”
button.
5. The system updates the user profile.

Post-condition System user’s profile will be edited.
27
Table 17: system admin delete user form description table.
Use case name Delete User

Description Allows system administrator to delete system users.
Flow of events 1. The system administrator select “Administration” tab 2. The system
display administration page.
3. The system administrator identifies the user who will be deleted. 4.

The system administrator selects the user and clicks delete button.
5. The system deletes the user profile

Post- condition The user will be deleted.
Table 18:system admin change password description table.
Use case Name Change Password

Description This allows Health professional to change his password
Flow of events 1. The health professional selects Administration tab across the top
menu.
2. The system display change password Manu.
3. The health professional enter this old and new password. 4. The
28
system change and stored the new password.

Post-condition Password is changed
Table 19:pharmacist add drug description table.
Use case name Add drug

Actors Pharmacist
Description Allows system pharmacists add new drug to store
Pre-condition The Pharmacist must be logged in to the system.
Flow of events 1. The Pharmacist select “Pharmacist” tab
2. The system display Pharmacist page.
3. The Pharmacist identifies the user who will be used drug.
4. The Pharmacist selects the user and clicks add button.

Post- condition The user will be add.
Table 20: pharmacist sale drug description table.
Use case name sale drug

Actors Pharmacist
Description Allows Pharmacist to sale drug.
Pre-condition The Pharmacist must be logged in to the system.
Flow of events 1. The Pharmacist select “Pharmacist” tab
2. The system display Pharmacist page.
3. The Pharmacist identifies the user who will be buy drug.
29
4. The Pharmacist selects the user and clicks sale button.
5. The system salad the saved drug

Table 21: pharmacist remove drug description table.
Use case name Remove drug

Actors Pharmacist
Description Allows system Pharmacist to remove the drug.
Pre-condition The Pharmacist r must be logged in to the system.
Flow of events 1. The system Pharmacist select “Pharmacist” tab
3. The system Pharmacist r identifies the user who will be removed

drug.
4. The system Pharmacist selects the user and clicks remove button.
5. The system removed the user drug profile
Table 22: perception patient registration description table.
Use case name Patient registration

Actors Perception
30


Table 23:perception patient service payment description table.
Use case name Service payment

Actors Perception


III.4.2. Sequence Diagram
A Sequence Diagram is an interaction diagram that emphasis the time ordering of messages; a
collaboration diagram is an interaction diagram that emphasizes the structural organization of the
objects that send and receive messages.
 Sequence diagrams and collaboration diagrams are isomorphic, meaning that you can
take one and transform it into the other.
 Sequence diagram are used to model the logic of usage action. A usage scenario is ex-
actly what its name indicate, the description of a potential way that the system is used.
31
 A sequence diagram is an easy and intuitive way of describing the behavior of a system
by viewing the interaction between the system and its environment.
 A sequence diagram shows an interaction arranged in a time sequence.
 It shows the objects participating in the interaction by their lifelines and the messages
they exchange, arranged in a time sequence.
Figure 0-2: Actors login sequence diagram.
32
Figure 0-3: Admin add new user.
Figure 0-4: Admin delete user
Figure 0-5: Edit user sequence diagram .
33
Figure 0-6: Admin change password.
Figure 0-7: patient download form sequence diagram
34
Figure 0-8: patient read form sequence diagram.
Figure 0-9: patient register form sequence diagram.
35
Figure 0-10: patient edit form form sequence diagram.
Figure 0-11: patient upload form sequence diagram.
36
Figure 0-12: patient appointment view form sequence diagram.
Figure 0-13: doctor pending form sequence diagram.
37
Figure 0-14: doctor send result sequence diagram.
Figure 0-15: doctor delete result form sequence diagram.
38
Figure 0-16: Doctor patient appointment sequence diagram.
Figure 0-17: Doctor prescription sequence diagram.
39
Figure 0-18: patient registration sequence diagram.
Figure 0-19: reception service payment sequence diagram.
40
Figure 0-20: pharmacist add drug sequence diagram.
Figure 0-21: pharmacistsale drug sequence diagram
41
Figure 0-22: pharmacist remove drug sequence diagram.
Figure 0-23: Actors logout sequence diagram.
42
III.4.3.Activity Diagram
Activity diagram Activity diagram is used to model consecutive steps in a computational

process. This diagram essentially a flow chart that emphasizes the activity that takes place over
time
Figure 0-24: activity diagram patient follow up system.
43
III.4.4.Class Diagram
class diagram of the system with their attributes,methods and relationships. Moreover, it shows
the overall structure of the system. Represents the static structure of the system. it show a collec-
tion of static model elements such as class and their relationship, connected as graph to each
other and to their content, their internal structure and their relationship to other class. In class di-
agram object in real world are represented by the actual object in the program . So a well-devel-
oped class diagram helps to effectively develop a model of the system and create ease of under-
standing.
Figure 0-25: class diagram for patient follow up system.
44
III.4.5. User Interface Design
This User Interface Design is mainly responsible to facilitate the interaction of the user with the
System. The services at this subsystem are accepting user inputs, shaping them in such way that
they can be used by the system, and displaying results processed by the system. This subsystem
has three smaller subsystems: Security User Interface,
Mobile User Interface and Web User Interface
Figure 0-26: Web User interface diagram for patient follow up system.
45
Figure 0-27: Mobile User Interface diagram for patient follow up system.
46
CHAPTER FOUR: SYSTEM DESIGN
4.1. Introduction
This section describes the proposed solution the system should have by transforming the func-
tional requirements into subsystem decomposition and the non-functional requirements into de-
sign goals.
4.2. Purpose of the System Design Document
Design process are recorded in the System design document. This document completely de-
scribes the system at the architecture level, including subsystems and their services, hardware
mapping, data management, access control, global software control structure, and boundary con-
ditions. It should include a high level description of why the System design document has been
created, provide what the new system is intended for or is intended to replace and contain de -
tailed descriptions of the architecture and system components. Its purpose is to provide a de -
scription for how the new mobile based atient follow up application will be constructed.
4.3. Scope of the project
When the completion of this project the system will have:
 Doctor can be commminicate with patient treat

 Patient can be get treatment in minimum cost.
 System can do minimization of waiting time and patient contact with healthy profetioals.
 Patient can be registered easily.
 Doctor follow up fixed patients.
47
4.4. Architectural Design
The system architecture transforms the logic design of information system in to physical struc-
ture. It describes the system’s hardware, software, and network support, processing method and
security. It is the plan for how the information system components will be distributed across mul-
tiple computers. The deliverables include the architecture design and the hardware and software
specification . Different system developers use different types of architecture in certain situa-
tions.
Figure 28 Architectural Design diagram patient follow up system.
4.4.1. Logical View of the Architecture
The logical architecture primarily supports the functional requirements what the system should
provide in terms of services to its user.The logical view provides a hierarchical view of a
project's structure. With the logical view, users can create and customize the diagrams in their
project with meaningful categorization by adding domain specific view.shown in figure
48
4.4.2. Process View
A process view model is a formal representation of how a given business process functioning or
operates. It depicts the various activities that are performed and how the data move among the
different activities. In addition, a process model can also be used to document the current prop -
erly functioning system or the new system being developed.28
4.4.3. Deployment View
Deployment diagram:is shows the configuration of run-time processing nodes and the compo-
nents that live on them. it address the static deployment view of architecture. They are related to
component diagrams in that a node typically encloses one or more components.Also shows how
a system will be physically deployed in the hardware environment. Its purpose is to show where
the different components of the system will physically run and how they will communicate with
each other.
Figure 0-289: Deployment Design diagram
49
4.4.4. Database Design
Most functionality in mobile based patient follow up system deals with data. Hence this section
discusses the data that is stored persistently. Persistent data about users themselves required to
be stored so that they can be authenticated and let them communicate each other
Figure 0-290: entity relationship diagram of database for mobile based patient follow up
50
Mapping Table create
ADMIN (admin_id,name,sex, address, email )

DOTOR(doctor_id,name,department,specialization,address,email,admin_id,pharmacist_i
d,receptionist_id )
PATIENT(ptient_id,name,age,sex,phone_no,dateof_birth,pharmacist_id,receptionist_id,
doctor _id )
PHARMACIST(pharmacist_id,name,phone,address,sex,email,admin_id ,doctor_id,re-
ceptionist)
RECEPTIONIST(receptionis_id,name,phone,address.sex,email,admin_id ,doctor_id,pha
rmacist_id)
DOTOR(doctor_id,name,department,specialization,address,email,admin_id,pharmacist_i
d,receptionist_id )
LIST OF TABLES USED IN THE DATABASE
TableT 24 .admin database table
Filed Name Data Type Size Key Value

Admin id Int 11 primary key
FirstName Char 25 -----------
LastName Char 25 -----------
Email Varchar 20
Sex Char 6 -----------
51
Table 25. Doctor database table.
Filed Name Data Type Size Key Value Description

Doctor id Int 11 primary key Doctor Id
FirstName Varchar 25 ----------- First Name
LastName Varchar 25 ----------- Last Name
Department Varchar 50 ----------- Department
Specialization Varchar 50 ----------- Specialization
Email Varchar 20 ----------- Email
Sex Char 6 ----------- Sex
Table 26. patient database table.

Patient id Int 11 primary key Nurse Id
FirstName Varchar 25 ----------- First Name
LastName Varchar 25 ----------- Last Name
Age Int 50 ----------- Department
Birth date Varchar 50 ----------- Specialization
Phone no Int 10 ----------- Phone no
Sex Char 6 ----------- Sex
52
Table 27. Recipitionist database table.

Receptionist id Int 11 primary key Nurse Id
FirstName Char 25 ----------- First Name
LastName Char 25 ----------- Last Name
Email Varchar 20 Email
Sex Char 6 ----------- Sex
Table 28.pharmacist database table.

Pharmacist id Int 11 primary key pharmacist Id
FirstName Char 25 ----------- First Name
LastName Char 25 ----------- Last Name
Email Varchar 20 Email
Sex Char 6 ----------- Sex
53
CHAPTER FIVE : CONCLUSION AND RECOMMANDATION
5.1. CONCLUSION
Nowadays, mobile technology is playing a pivotal role in improving provision of healthcare ser-
vices and it has a positive impact on clinical outcomes such as reduced infant mortality, longer
life spans and decreased contraction of disease. This would also enhance the possibility of in-
creasing the efficiency and effectiveness of delivery of outpatient healthcare and decrease the
substantial financial losses for healthcare systems.
In analyzing of the existing system, we found that healthcare organizations in Ethiopia are not
enough to serve and give follow up services for the current population. They are not well orga-
nized, poor infrastructure, inadequate number of health professionals and deprived in health in-
formation technology. These lead to service delay, patient crowding, job dissatisfaction and inef-
ficient, and patients need to travel a long distance for follow up. Using this work, health profes-
sionals can provide continual follow-up for out-patients and records of critical data such as labo-
ratory tests and medication. In addition, the system stops a patient from returning for follow-up
in resource-poor environments and the frequent need for migration due to poverty and social dis-
ruption. Moreover, the system helps find missing patients and provide treatment, and failure to
do so for COVID_19, HIV and TB is often a serious situation. Form this study we found
that in Ethiopia there is an opportunity to implement mobile health information technology using
the mobile phones distribution in the society.
Public and private health organization to follow and recommend their patients while doctors are
in office and patients stay in home. Patients to perform their follow-up activity and request
their doctors when they need urgent assistant . Health professionals who work in remote area to
get expert advice from specialists. This work is primarily focused on the offline follow up ser-
vices for the out patients.
54
5.2. Recommendation
Mobile technologies are proven in improving the health service and delivery process, mobile
technologies allow health managers to more quickly and reliably have access to data which can
help identify where there issues in the service delivery. Achieving a strong sense of ownership
and empowerment among health workers is a prerequisite for a successful introduction of any
mobile health program. The findings didn’t consider the following issues and it will be consid-
ered as a future work.
 Online follow up system using text, audio, and video data.

 Integrating the system with patient monitoring devices to collect biological data and
submit to the server without interference of a patient.
 Tracking patients online using their spatial data.
55
References
[1] . United Nations Department of Economic and Social Affairs, Division for Public Adminis-
tration and Development Management, Compendium of ICT Applications on Electronic Govern-
ment - Volume 1. Mobile Applications on Health and Learning (New York: United Nations,
2007).
[2] .Phoned pill reminders make inroads against TB. The Nation (Bangkok), January 28, 2007
[3] .The Role of Mobile Phones in Increasing Accessibility and Efficiency in Healthcare. Mov -
ing the debate forward. The Vodafone Policy Paper Series, Number 4 (Newbury: Vodafone
Group Plc, March 2006).
[4] . Wools-Kaloustian K, Kimaiyo S, Diero L, et al. Viability and effectiveness of large-scale

HIV treatment initiatives in sub-Saharan Africa: experience from western Kenya. AIDS Jan 2,
2006; 41-48.
[5]. Jones SA, Sherman GG, Varga CA. Exploring socio-economic conditions and poor follow-
up rates of HIV-exposed infants in Johannesburg, South Africa. AIDS Care May 17, 2005; 466-
470.
[6] .Haynes RB, McKibbon KA, Kanani R. Systematic review of randomised trials of interven -
tions to assist patients to follow prescriptions for medications. Lancet 1996; 348: 383-386.
[7] .Mahmud N, Rodriguez J, Nesbit J., A text message-based intervention to bridge the health-
care communication gap in the rural developing world, Technology Health Care. 2010;
18(2):137-144.
[8]. M. V. M. Figueredo, J. S. Dias “Mobile Telemedicine System for Home Care and Patient
Monitoring” the 26th Annual International Conference of the IEEE EMBS San Francisco, CA,
USA • September 1-5, 2004
56
[9]. “Smart Phones” for Older Chinese with Diabetes http://www.cadaproject.com_ /data/
Smart_Phones_ for_Older_Chinese_with_Diabetes.pdf, last Accessed: October 09, 2010.
[10]. ODK Clinic-view clinic data on a mobile phone: http://code.google.com/p/ opendatakit/

wiki/ODKClinic, last accessed February 23, 2011
57

Cep Tiles Documentation

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cep Tiles Documentation

Uploaded by

Copyright:

Available Formats

HAWASSA UNIVERSITY INSTUTE OF TECHNOLOGY

FACULITY OF INFORMATICS DEPARTMENT OF COMPUTER SCIENCE

PROJECT TITLE:- MOBILE BASED PATIENT FOLLOWUP SYSTEM

1. Tilahun Solomon Evcs/158/09

PROJECT ADVISOR: Getabalew Amtate

A senior project (Final document)

Hawassa Sidama ,Ethiopia

__________________ _________________________ Getabalew Amtate(MSc)

Date Signature Name of Adviser

Examining committee members’ Signature

CHAPTER ONE: INTRODUCTION..............................................................................................1

1.2. STATEMENT OF THE PROBLEM................................................................................2

1.3. Objective of the project.....................................................................................................3

1.3.1. . GENERAL OBJECTIVE........................................................................................3

1.3.2. SPECIFIC OBJECTIVES..........................................................................................3

1.5. Limitation of the study......................................................................................................4

1.6.1. Data Collection Methodology....................................................................................4

1.6.2. System Analysis and Design Mythology...................................................................5

1.6.3. System Implementation.............................................................................................5

1.6.4. Testing and Deploying Methodology........................................................................5

1.6.5. Development Environment........................................................................................5

1.6.6. System Requirements................................................................................................6

CHAPTER TWO: DESCRIPTION OF EXISTING SYSTEM.....Error! Bookmark not defined.

2.1. Introduction of the existing systemS....................................................................................7

2.2. Proposed system description................................................................................................7

2.3. Strength of existing system..................................................................................................8

2.4. Weakness of existing system...............................................................................................8

CHAPTER THREE: SYSTEM FEATURES................................................................................10

3.2. Functional Requirements................................................................................................10

3.3. Non-Functional Requirements........................................................................................11

3.4. Analysis Models..............................................................................................................12

3.4.1. Use Case Diagrams..................................................................................................12

3.4.2. Sequence Diagram...................................................................................................31

3.4.3. Activity Diagram.....................................................................................................43

3.4.4. Class Diagram..........................................................................................................44

3.4.5. User Interface Design..............................................................................................45

CHAPTER FOUR: SYSTEM DESIGN...................................................................................46

4.2. Purpose of the System Design Document..........................................................................47

4.3. Scope of the project...........................................................................................................47

4.4. Architectural Design..........................................................................................................48

4.4.1. Logical View of the Architecture.................................................................................48

4.4.2. Process View................................................................................................................49

4.4.3. Deployment View.........................................................................................................49

4.4.4. Database Design...........................................................................................................50

LIST OF TABLES USED IN THE DATABASE.........................................................................51

CHAPTER FIVE : CONCLUSION AND RECOMMANDATION.............................................54

FIGURE 3-0-1 :USE CASE DIAGRAM FOR PATIENT FOLLPOW UP SYSTEM.......................................................................14

FIGURE 0-2: ACTORS LOGIN SEQUENCE DIAGRAM........................................................................................................32

FIGURE 0-3: ADMIN ADD NEW USER.............................................................................................................................32

FIGURE 0-4: ADMIN DELETE USER..............................................................................................................................33

FIGURE 0-5: EDIT USER SEQUENCE DIAGRAM ..............................................................................................................33

FIGURE 0-6: ADMIN CHANGE PASSWORD......................................................................................................................34

FIGURE 0-7: PATIENT DOWNLOAD FORM SEQUENCE DIAGRAM.....................................................................................34

FIGURE 0-8: PATIENT READ FORM SEQUENCE DIAGRAM...............................................................................................35

FIGURE 0-9: PATIENT REGISTER FORM SEQUENCE DIAGRAM........................................................................................35

FIGURE 0-10: PATIENT EDIT FORM FORM SEQUENCE DIAGRAM....................................................................................36

FIGURE 0-11: PATIENT UPLOAD FORM SEQUENCE DIAGRAM.........................................................................................36

FIGURE 0-12: PATIENT APPOINTMENT VIEW FORM SEQUENCE DIAGRAM......................................................................37

FIGURE 0-13: DOCTOR PENDING FORM SEQUENCE DIAGRAM.......................................................................................37

FIGURE 0-14: DOCTOR SEND RESULT SEQUENCE DIAGRAM.........................................................................................38

FIGURE 0-15: DOCTOR DELETE RESULT FORM SEQUENCE DIAGRAM.............................................................................38

FIGURE 0-16: DOCTOR PATIENT APPOINTMENT SEQUENCE DIAGRAM..........................................................................39

_______ Getabalew Amtate(MSc)