JIMMA UNIVERSITY

JIMMA INSTITUTE OF TECHNOLOGY

DEPARTMENT OF COMPUTER SCIENCE

SOFTWARE REQUIREMENT SPECIFICATION DOCUMENT REPORT

ON

MOBILE ASSISTANT AND PATIENT RECORD MANAGEMENT SYSTEM FOR

FAMILY DOCTORS

BY

1. WESAGN DAWIT
2. YONAS ADENAGIR

ADVISORS SIGNATURE

1. Ms. L. MELITA --------------------------------

2. Mr. MIKIAS AFEWORK -----------------------------------

JANUARY 2013

i
 JIMMA UNIVERSITY
JIMMA INSTITUTE OF TECHNOLOGY
DEPARTMENT OF COMPUTER SCIENCE

SOFTWARE REQUIREMENT SPECIFICATION DOCUMENT REPORT

ON

MOBILE ASSISTANT AND PATIENT RECORD MANAGEMENT SYSTEM FOR

FAMILY DOCTORS

BY

WESAGN DAWIT & YONAS ADENAGIR

NAME AND SIGNATURE OF THE EXAMINING BOARD

Name signature

1. ----------------------- ---------------------------

2. ----------------------- ---------------------------

3. ----------------------- ----------------------------

JANUARY 2013

ii
 Acknowledgment

First of all we would like to thank Almighty GOD for the strength, he has given us throughout
our life and this project; nothing could happen without the help of GOD. Secondly, we would
like to express our gratitude to our advisors Ms.L.Melita and Mr.Mikias Afework for their
help, willingness and commitment in giving their precious time to help us accomplish this work
and great thanks to Dr.Tsegaye who helped us by giving important information on patient record
management system. We are also very grateful and would like to extend our sincere thanks to
our staff members and students of our Department of Computer Science for sharing their ideas,
suggestions, and support and especially for their commitment. We really give a great respect and
credit to everyone who involved in our project tasks.

Abstract

This project is a mobile assistant and a patient recording management system specially designed
for family doctors. The application will be installed on mobile phones. The application provides
user friendly GUI in order to make it easy and efficient for the doctors to use the application. In
this application, physicians can register families along with their address, patients in the family,
keep track of appointments. The system also provides automatic drug taking time reminder for
the patients. In general, it enables physicians to have their patients on their finger print, by
installing this application on their mobiles.

iii
 List of tables
Table 2.1 Description for register account use case.

Table 2.2 Description for login use case.

Table 2.3 Description for Register family use case.

Table 2.4 Description for Register patient use case.

Table 2.5 Description for Set appointment use case.

Table 2.6 Description for write and modify patient history use case.

Table 2.7 Description for search patient use case.

Table 2.8 Description for view appointment use case.

Table 2.9 Description for set reminder use case.

Table 2.10 Description for Refer hand book use case.

iv
 List of figures

Figure 1.1 Gantt chart.

Figure 2.1 use case diagram for MAPRMSFD.
Figure 2.2 Sequence diagram for Login.
Figure 2.3 Sequence diagram for Register patient.
Figure 2.4 Sequence diagram for write and modify patient history.
Figure 2.5 Sequence diagram for search patient.
Figure 2.6 Sequence diagram for appointment setting.
Figure 2.7 Sequence diagram for Refer hand book.
Figure 2.8 Sequence diagram for view appointment.
Figure 2.9 State chart diagram for login.
Figure 2.10 State chart diagram for sett appointment.
Figure 2.11 State chart diagram for search patient.
Figure 2.12 State chart diagram for refer hand book.
Figure 2.13 Activity diagram for account registration.
Figure 2.14 Activity diagram for login.
Figure 2.15 Activity diagram for family registration.
Figure 2.16 Activity diagram for register patient.
Figure 2.17 Activity diagram for appointment setting.
Figure 2.18 Activity diagram for write and modify patient history.
Figure 2.19 Activity diagram for search patient.
Figure 2.20 Activity diagram for view appointment.
Figure 2.21 Activity diagram for set appointment.
Figure 2.22 Activity diagram for Refer hand book.
Figure 2.23 Class diagram.
Figure 2.24 Login user interface.
Figure 2.25 Main menu user interface.

v
Figure 2.26 Register family user interface.

Figure 2.27 Add patient user interface.

Figure 2.28 Search patient user interface.
Figure 2.29 Set appointment user interface.
Figure 2.30 View appointment user interface.
Figure 2.31 Set reminder user interface.
Figure 2.32 Medical handbook user interface.
Figure 2.33 Edit medical handbook user interface.
Figure 3.1 Proposed software architecture for MAPRMSFD.
Figure 3.2 Layered representation of the system.
Figure 3.3 Component diagram for MAPRMSFD.
Figure 3.4 Deployment diagram for MAPRMSFD.
Figure 3.5 Mapping of objects in to tables.
Figure 3.6 Relationships between tables.

Abbreviations

MAPRMSFD: Mobile Assistant And Patient Record Management System For Family Doctors.
GUI: Graphical user interface.
JDBC: Java database connectivity.
J2ME: Java 2 Micro Edition.
UML: Unified modeling language.
MHealth: Mobile health.

vi
Contents
CHAPTER ONE........................................................................................................1
1. INTRODUCTION..............................................................................................1
1.1 Background...................................................................................................1
1.2 Statement of the problem..............................................................................2
1.3 Objectives......................................................................................................3
1.4 Methodology.................................................................................................3
1.5 Feasibility......................................................................................................4
1.6 Project scope and limitation..........................................................................5
1.7 Significance of the project............................................................................6
1.8 Time schedule...............................................................................................7
1.9 Organization of the document.......................................................................9
CHAPTER TWO.....................................................................................................10
2. Requirement Analysis......................................................................................10
2.1 Existing system...........................................................................................10
2.2 New system.................................................................................................10
CHAPTER THREE.................................................................................................56
3. System Design..................................................................................................56
3.1 Introduction.................................................................................................56
3.2 Purpose and goals of design........................................................................56
3.3 Proposed software architecture...................................................................57
3.3 Persistent modeling for object oriented database........................................61
3.4 Access control and security.........................................................................66
References.........................................................................................................67

vi
 CHAPTER ONE
1. INTRODUCTION

1.1Background

Today, mobile phones are such a familiar part of our lives that we don’t only use them for
simply talking or texting others but in many other aspects. MHealth (using mobile devices in
health sector) is a young and dynamic field that could improve the well-being of all human
beings around the world. This document is a report or a software requirement specification for
MOBILE ASSISTANT SYSTEM FOR FAMILY PHYSICIAN. Actually having a family physician is not
that much in practice in countries like Ethiopia, only those higher class families engage
themselves in this kind of scenarios, but with the growth in economy families will be able to
have their own family physician, and also increase in the number of professionals (Doctors) on
health sector will have direct impact on the need to possess a family doctor or a physician.

MOBILE ASSISTANT SYSTEM FOR FAMILY PHYSICIAN is simply a mobile application that
helps family physician or family doctor to keep record of medical history(which includes
information about past illnesses of each and everyone in the families, information about blood
relatives (for example: parents, grandparents, children, and brothers or sisters)) of the intended
families. Typically, this application is exceedingly useful by better recordkeeping for a doctor or
physician when they have too many families that they are sighting into them.

In most of the areas across all over Ethiopia, since there is no such a flexible application
it’s not familiar that the family doctors or family physicians use their cell phone to record
patient’s information. They use papers to record patient information. The aim of this application
is to explore the incentives and barriers to recording and adopting information about patients in
the families.

1
1.2 Statement of the problem

In some places over Ethiopia, the most presently existing system is that an intended
family doctors or family physicians sees people in the families for all of their health problems,
they record the necessary information in the paper-based form. As the number of families the
doctor is sighting increases, recording in paper based format will become problematic.

The usage of traditional paper-based forms to record information has several drawbacks,
since it is erroneous, insecure, unorganized and also less flexible. The following list shows the
problems that a family doctor or physicians face if he is going to record the families medical
information that he is going to sight.

 Paper-based recording system is not secure which means patient’s

information can be visible for others, it can also get damaged.
 Patients in the intended family may forget to take drugs on the prescribed
time (for that reason, this application provides remainder settings to remind
the patients drug taking time).
 It is difficult to whirl through papers to check the health mark of individuals
in the intended family (medical history, appointment, etc...).
 The doctor or physician may need additional facility to remember the
medical notes (for which this application provides an advanced medical
notebook or a guide).
 It is difficult for the doctor to remember every appointment he has with his
patients.

2
1.3 Objectives
The general and specific objective of the project is described below.

1.3.1General Objective
The general objective of our project is to develop a mobile application to help family
doctors or physicians to keep record of patients and to help them in other related services.

1.3.2Specific objective
As described above the goal of this project is to develop a mobile application to help
family doctors or physicians to keep record of patients and in other related services. We listed
the following aspects as specific objective.
 To understand the problems in the current system.
 To plan the solution for the problems identified.
 To plan the design and development of our system.
 To plan the way to ensure the integrity of data in our proposed system.
 To determine how data will be entered into our system.
 To develop procedures for appropriate recording of patient details.

1.4 Methodology

1.4.1 Requirement gathering methods

For the purpose of gathering requirement from users we are going to have frequent interviews
with users who are expected to be users of the system that we are going to develop, and internet
is also main source for gathering information.

The other method is document analysis; we reviewed documents such as books, e-books and
some previously done project reports which are used as a reference to design the system we are
going to develop.

1.4.2 Requirement modeling methods

We are going to model the requirements that we gather using object oriented approach
because object oriented technology is of broad means used to handle highly structured

3
applications. Object oriented technology provides numerous advantages in applications by
making them easy to use and maintain.

1.4.3 Tools used (System development methodologies and tools)

As described above in the requirement modeling it’s expected to use Object Oriented
approach will be used for developing MOBILE ASSISTANT SYSTEM FOR FAMILY PHYSICIAN .

Object oriented technology is of broad means used to handle highly structured application
systems. Object oriented technology provides numerous advantages in applications by making
them easy to use and maintain, it is plat form independent, portable and reliable by itself.

Tools and techniques:-

 J2ME is used for developing mobile assistant system for family physician.
 Operating system Windows 7 is used.
 Microsoft office Word 2007 is use for writing proposals and reports
 Microsoft office Excel 2007 is used for Gantt chart (work break down chart)
and other definite diagrams.
 Visio 2010, visual paradigm, UMLet, Edrawmax and some other tools used to
design the uml diagrams.

1.5 Feasibility
Since MOBILE ASSISTANT SYSTEM FOR FAMILY PHYSICIAN is very useful for the
doctors and physicians in that it provides the prevailing betterments in their work, it is expected
that this application system will also grow faster and more productively if family doctors or
physicians (including any family physicians) recognize the role of strategic financing from the
system and interventions in to using it. This application simplifies their work by providing much
functionality by overcoming the described drawbacks in section 1.2.

1.5.1 Economical feasibility

The proposed system is going to be economically feasible in such a way that, since the system
will be developed for medical doctors so that doctors can afford to have smart phones and also to
install this system and can benefit from it.

4
1.5.2 Technical feasibility
The technical issues that are involved in the system such as the normality and strength of
the doctors mobile from the hardware part, the software should work properly in the proper
inputs from its users from both user and the software point of view should be considered to
determine the feasibility. There are also other services provided from the mobile for which we
don’t need to rebuild it again. Additionally, in simple terms long range portable mobile device
required for the betterment of the application usage.

1.5.3 Time feasibility

Time feasibility is the most important and superior thing to be considered. The period of time
considered as a resource under user control and sufficient to accomplish some work and it is an
instance or single occasion for some work. This system provides much faster and easy way of
recording options and other various functionalities as mentioned above in objective section. This
system is feasible by time since it reduces the time required to work through with paper-based
operational approach.

1.5.4 Operational feasibility

The user should not misuse the system. To determine the operational feasibility of the
system we should take into consideration the knowledge level of the users. Initially this system is
proposed to be designed to professional user. This system is operational feasible since the users
are professional and known with the technologies and hence there is no need to cog up the user
specially doctors or physicians too much to use system. The application is expected to be very
flexible for its users. And this is also one of the factors that make it operationally feasible.

1.6 Project scope and limitation

1.6.1 Scope
The scope of this project is developing the mobile assisted patient record management
system for family doctors or family physicians, which gives fast service for the users of this
application such as, easy patient record management system, automatic reminder for patients to
make them able to take their drugs in the prescribed time. The system can be used by doctors to
track their appointments with their patients, and this system incorporate medical handbook or
guide as its additional module which can be used as reference by the doctor.

5
1.6.2 Limitation
The following list shows some of the limitations of the project:

 The system is not going to be used to record some complex information

about patients like X-RAY results, ultrasound results and also some
complex diagrams, long text responses.
 The application is required to run only on android tools (like smart
phones, and the like).
The key challenging task for generating this mobile application is due to the limitations and
numerous variations inherent to standard mobile devices.

1.7 Significance of the project

As the consequence of the proposed system, there are inevitable connotations as outcome
from this application. The significance of our system includes the following:

 Mobile assistant patient record management system enables family

physicians or family doctors in improved patient records.
 Mobile assistant patient record management system provides better record
keeping mechanism for doctors or physicians.
 Mobile assistant patient record management system fastens and accelerates
the work of doctors or physicians by saving working time and power.
 Mobile assistant patient record management system provides medical notes
that is somewhat advanced medical notebook to enable physicians or
doctors resume and check medical notes when needed.
 Providing remainder for physicians or doctors and remainder settings to
remind the patients about drug taking time.

Better recordkeeping is another widespread outcome of this technology. In addition, this

application can help patients obtain the right information quickly and better understand their
diagnoses and treatments through the SMS text provided by this application from the doctors or
physicians of themselves. Doing so allows them to have more say in their treatment and to take
more responsibility for complying with it.

6
1.8 Time schedule
The below figure 1.2 is Gantt chart that illustrates the word break down tentative initial
project schedule to be followed.

7
 16-Nov-2012 5-Jan-2013
1. Introduction
1.1 Background
1.2 Statement Of The Problem
1.3 Objective
1.3.1 General Objective
1.3.2 Specific Objective
1.4 Methodology
1.4.1 Data Collection Methodology
1.4.2 System Development Metholology
1.5 Feasibility
1.5.1 Techenical Fesibility
1.5.2 Economical Feasibility
1.5.3 Operational Feasibility
1.6 Significance of the project
1.7 Time Schedule
2.0 Analysis
2.1 Existing System
2.1.1 Existing System Description
2.1.2 Essential use case modeling
2.1.3 Essential User Interface Prototyping
2.1.4 Domain modeling with CRC
2.1.5 Business Rules
2.2 New System
2.2.1 Non-functional Requirements and Constraints
2.2.2 functional Requirement
2.2.3 Use Case Diagram
2.2.4 Use case documentation
2.2.5 Sequence diagram
2.2.6 Activity diagram
2.2.7 Conceptual modeling: Class diagram
2.2.8 User Interface Prototyping
2.2.9 Identifying change cases
3.0 Design
3.1 Class diagram
3.2 State chart diagram
3.3 Collaboration modeling
3.4 Component diagram
3.5 Deployment diagram
3.6 User Interface Design
3.7 Database design (E-R diagram)
3.8 Persistence Modeling for OODB
4.0 Implementation
4. Implementation

Fig 1.1 – Gantt chart

8
1.9 Organization of the document

This document has three chapters including this chapter which gives highlight about the project
we are going to develop. The second chapter is the requirement analysis where user requirements
are structured and modeled; the third chapter is about the design of the system which describes
the design of the proposed system.

9
 CHAPTER TWO
2. Requirement Analysis
2.1 Existing system

2.1.1 Existing system description

The existing system that the family doctors currently using is manual which means in paper
based manner , because of the absence of automated system like,” MOBILE ASSISTANT AND
PATIENT RECORD MANAGEMENT SYSTEM FOR FAMILY DOCTORS OR FAMILY
PHYSICIANS” , family physicians are forced to track their patients using traditional paper based
record method. The existing system or the manual system has drawbacks like, it takes time to
search a patient, it is not that much easy to remind every appointment that the doctor have if he is
sighting many families, there is no way to remind patient to take their medications in the
appropriate time, the paper based recording cannot be claimed as secure. Therefore developing
an automated mobile application for family physicians is found to be important since it allows
physicians to have their patient’s record on their fingerprint.

2.1.2 Business Rules

 Patient’s information should not be visible for others.

 Patients still need to carry out laboratory test if necessary.
 Patients should finish all the payments they are required to pay.

2.2. New system

2.2.1 Non-functional Requirements and Constraints

Non-functional requirement is a requirement that specifies criteria that can be used to judge the
operation of the system, rather than specific behaviors of the system which are specified under
functional requirements of the system. The following are considered as the non-functional
requirements for the project we are going to develop.

10
1. Security

Any information system must be secure to fulfill the three main components of system security
which are confidentiality, integrity and availability, therefore to make the system that we are
going to develop secure, we are going to employ authentication mechanism which is giving the
user username and password so that no one apart from the authenticated user can get access to
the system.

Since, this system is going to developed for mobile devices it considered to be physically secure
because the only person who is going to use the device is the one who is the owner of that
device.

2. Response time

The system should give the right response for the user as fast as possible, since the system we are
developing is on mobile it will not be sophisticated to use and it will not take much time to
handle responses.

3. Usability

After the proposed system is implemented it will be usable by family doctors, since it will be
easy and friendly to use it is believed to be usable.

4. Error Handling

When a user interacts with the system errors may occur. To control this kind of inaccuracies
system will generate different user friendly messages. To do this, most of the system execution
buttons will be controlled according to the sequence which the user is expected to follow, or this
can be done by generating different system responses to the input of the user.

5. User Interface

The system we are going to develop will have a user friendly graphical user interface (GUI)
which allows users to interact with the system easily. The user is expected to have knowledge of
using mobiles and also navigating through mobile interfaces.

11
2.2.2Functional requirements

Register family: a doctor or physician can register the family and family members he/she
regularly treats.

Register patient: the main function of the proposed or the new system is to develop a mobile
patient recording. There for the physician can record his/her patients using this system.

Write and modify patient history: while treating patients, physician’s record or write patient
history based on the information they get from the patient, and also record patients test report
and the prescription given based on the test. Therefore writing and modifying patient’s history is
a necessary part of our system.

Set Appointment: treating patients is not an easy task it takes much time and also a frequent
interaction between the doctor and the patient, for this reason doctors should fix an appointment
to treat their patients. By using this system a physician can keep a record of his/her appointments
on his/her mobile easily.

Search patient: whenever doctors need to check their patient’s information they can search for
patients who are being treated by them. The system we are developing facilitates easy and fast
searching of patients who are already recorded.

View appointment: the doctor or the physician can keep track of the appointments he/she has
with his/her patients on a particular date and time. The proposed system helps the doctor’s to set
their appointments and also keep track to it.

Set reminder: the doctor using our proposed system can set a reminder which will help the
doctor not to forget his/her activities like appointments.

Refer Hand book: the doctor using our system can update him/her self by using or referring the
medical hand book or guide which is available in our system.

2.2.3 Use case diagram

In software and system engineering, a use case is defined as a list of steps, typically defining
interaction between a role (known in UML as an “actor” ) and a system, to achieve a goal. The
actor can be a human or an external system. In system engineering, use cases are used at a higher
level than within software engineering, often representing missions or stakeholder goals.

12
Figure 2.1 use case diagram for MAPRMSFD

13
2.2.3.1 Use case documentation

Use case name 1 Register Account

14
Primary actor Physician
Precondition The physician must enter user name and
password to create account.
Basic Flow of event 1. Press create account button.
2. Account registration form will come.
3. Enter user name and password.
4. Press createAccount button.
Alternative action A1- if account is already created the system
will notify that the user can not create
additional account.
Post condition Account is successfully created.

Table 2.1: Description for register account use case

Use case name Login

Primary actor Physician
Precondition - A user must have an account to login
Basic flow of event 1. System displays login screen.
2. User enters username and password.
3. Press login button.
4. System acknowledges entry.
Alternative Action If username and password is wrong system will
display error message. then go to step 1.
Post condition System will display a main menu to proceed.

Table 2.2: Description for Login use case

15
Use case name Register family
Primary actor Physician
Precondition - A user must have logged in first
Basic flow of event 1. User enters necessary information of
the family.
2. User enters necessary information of
members of the family.
3. Press register button.
Alternative condition if there is redundancy in the data entered
system will notify that there is redundancy of
data being entered.
Post condition The family information is stored in database.

Table 2.3: Description for register family use case

Use case name Register patient

Primary user Physician
Precondition -The physician must login first to register
patient.
Basic flow of event 1. Physician enter necessary information
of a patient like name, phone number
etc.
2. Click register button.
Post condition System acknowledges successful registration.

Table 2.4: Description for register patient use case

16
Use case name Set appointment
Primary actor Physician
Precondition The patient with whom the physician will have
an appointment should have been registered
first.
Basic flow of event 1. System displays appointment setting
window.
2. Enter date.
3. Enter time.
4. Enter patient name with whom he/she has
appointment.
5. Press save button to save appointment.
Alternative action A1 – if the patient has not been registered
system display patient is not registered.

A2- if the date is less than the current date the

system will notify the physician to enter a valid
date.
A3- if the patient’s id or name is incorrect the
physician should re-enter the correct id or
name of the particular patient.
Post condition System will acknowledge successful saving of
appointment.

Table 2.5: Description for set appointment use case

17
Use case name Write and modify patient history
Primary actor Physician
Precondition The patient whose history is being written
should have been registered before.
Basic flow of event 1. Physician enters name or id of the
patient.
2. Physician records the patient’s word
about his illness.
3. Press save button.
Alternative condition A1- if the patient is not already in the database
physician should first register patient.
A2- if the patient’s id or name is incorrect the
physician should re-enter the correct id or
name of the particular patient.
Post condition System acknowledges successful saving of
patient history.

Table 2.6: Description for write and modify patient history use case

Use case name Search patient

Primary actor Physician
Precondition The patient to be searched should have been
registered before.

18
Basic flow of event 1. The physician enters the name or id of
the patient.
2. Press search button.
Alternative action A1- if the patient’s id or name is wrongly
entered systems notifies the physician to
reenter patient’s id or name and search again.
Post condition Patients details will be displayed.

Table 2.7: Description for search patient use case

Use case name View appointment

Primary actor Physician
Precondition - The appointment to view should have
been registered in database.

Basic flow of event 1. Physician enters date on which he/she

has appointment.
2. Press view/ search button.
Alternative action A1 - if the date entered is not already
registered in the database along with a specific
appointment system will tell the physician that
there is no registered appointment on that
particular date.
Post condition List of appointments with their particular time
and patient will be displayed.

Table 2.8: Description for View appointment use case

Use case name Set reminder

Primary actor Physician
Precondition Physician should first login
Basic flow of event 1. Enter date.
2. Enter time.

19
 3. Enter description.
4. Press save.
Alternative action A1- if the date entered is less than the current
date the system will notify the physician to
enter a valid date.
Post condition The system acknowledges successful saving of
the reminder.

Table 2.9: Description for set reminder use case

Use case name Refer hand book

Primary actor Physician
Precondition The disease to be searched should have already
been registered in to database.
Basic flow of event 1. Enter the disease name.
2. Press enter or search button.
Alternative action A1- if the disease name is not found the system
will notify the physician that his/her search
doesn’t match.
Post condition The disease’s symptom and its medication will
be displayed.

20
Table 2.10: Description for refer hand book use case

2.2.4 Sequence diagrams

A sequence diagram in am unified modeling language (UML) is a kind of interaction
diagram that shows how processes operate with one another and in what order. It is a
construct of a message sequence chart. A sequence diagram shows object interactions
arranged in time sequence. It depicts the objects and classes involved in the scenario and
sequence of messages exchanged between the objects needed to carry out the functionality of
the scenario.

Figure 2.2 Sequence diagram for login.

21
Figure 2.3 Sequence diagram for register patient.

22
Figure 2.4 Sequence diagram for write and modify patient history

23
Figure 2.5 Sequence diagram for search patient

24
Figure 2.6 Sequence diagram for appointment setting.

25
Figure 2.7 Sequence diagram for refer handbook

26
Figure 2.8 sequence diagram for view appointment

27
2.2.5State chart diagram
State diagram or state chart diagram is a type of diagram used in computer science and related
fields to describe the behavior of systems. State diagrams require that the system described is
composed of states. Many forms of state diagrams exist which differ slightly and have different
semantics. State diagrams are used to give an abstract description of the behavior of a system.
This behavior is analyzed and represented in series of events that could occur in one or more
possible states.

28
 Figure 2.9 State chart diagram for login

Figure 2.10 State chart diagram for set appointment

29
Figure 2.11 State chart diagram of search patient

30
Figure 2.12 State chart diagram of refer hand book.

31
2.2.6Activity Diagram
Activity diagrams are graphical representations of workflows of stepwise activities and
actions with support for choice, iteration and concurrency. In the unified modeling
language, activity diagrams can be used to describe the business and operational step-by-
step workflows of components in a system. An activity diagram shows in overall flow of
control. In its basic form an activity diagram is a simple and intuitive illustration of what
happens in a workflow, what activities can be done in parallel, and whether there are
alternative paths through the workflow.

32
Figure 2.13 Activity diagram for account registration

33
34
Figure 2.14 Activity diagram for Login

35
Figure 2.15 Activity diagram for family registration

36
Figure 2.16 Activity diagram for register patient.

37
Figure 2.17 Activity diagram for appointment setting

38
39
Figure 2.18 Activity diagram for write and modify patient history.

40
Figure 2.19 Activity diagram for search patient

41
42
Figure 2.20 Activity diagram for view appointment

43
Figure 2.21 Activity diagram for set reminder

44
Figure 2.22 Activity diagram for refer hand book

45
2.2.7Class responsibility collaboration (CRC)

Family Detail
Responsibility Collaboration
- Family no - member detail
- Family name - patient detail
- appointment detail
- reminder detail

Member detail
Responsibility Collaboration
- full Name - Family detail
- birth Date - Patient detail
- Sex - Appointment detail
- age
- City
- Phone number
- member no

Illness Detail
Responsibility Collaboration
-Ill-id - patient detail
-ill-date - prescription detail
-illness-description

46
 Patient detail
Responsibility Collaboration
- Patient no - Family detail
- Patient name - Member detail
- History - Appointment detail
- Date - Reminder detail

Appointment details
Responsibility Collaboration
- Appointment no - Family detail
- Patient name - member detail
- date - Patient detail
- time

Reminder detail
Responsibility Collaboration
- Reminder no - Family detail
- subject - Patient detail
- Time
- Date

Prescription detail
Responsibility Collaboration
- Prescription_id - Patient details
- Prescription_date
- Drug name
- Quantity
- Time

47
 2.2.8 Class diagram

The structure of the classes in this application is as per the Java ME pages of the project as
shown in figure 1.1 below.

Fig. 2.23 – Class Diagram 48

2.2.9User Interface prototyping
User interface prototype for showing system works in Java ME pages for this application is
shown in the figures below.
Figure 1.2 below shows the interface screenshot for the Createuser|Login feature on the screen of
Java ME device (or emulator).

Fig. 2.24 – Create | Login

49
Figure 2.25 below shows the interface screenshot for the MainMenu feature after the successful
Login to use the features on the device. This feature shows all the possible proceedings a user
can act upon.

Fig. 2.25– Main Menu

A user can see this interface if account is initially created and both password and username
prompted by the user are correct.

50
Figure 2.26 below shows the interface screenshot for the RegisterFamily feature after the user
selects RegisterFamily icon of the MainMenu.

Fig. 2.26 – Register Family

The RegisterFamily interface contains some other features (Add member, Edit member, Remove
member, Remove family, and View member). Each of this features have their own interface for
the user.

51
Figure 2.27 below shows the interface screenshot for the AddPatient feature after the user selects
AddPatient icon of the MainMenu.

Fig. 2.27– Add Patient

The AddPatient interface provides the page to record the patient information and Edit option to
edit the prerecorded patient information. The Edit option displays the interface after populating
the information in the fields.

52
Figure 2.28 below shows the interface screenshot for the SearchPatient feature after the user
selects SearchPatient icon of the MainMenu.

Fig. 2.28 – Search Patient

The SearchPatient interface provides the page to see or view the list of all patients and Search
option to search for the patient with the specified name.

53
Figure 2.29 below shows the interface screenshot for the SetAppointment feature after the user
selects SetAppointment icon of the MainMenu.

Fig. 2.29 – Set Appointment

The SetAppointment interface provides the page to set and save appointments for the patients
and related tasks in the specified date and time.

54
Figure 2.30 below shows the interface screenshot for the ViewAppointment feature after the
user selects ViewAppointment icon of the MainMenu.

Fig. 2.30 – View Appointment

The ViewAppointment interface provides the page to see or view the list of all appointments and
view option to see the appointment on the specified date.

55
Figure 2.31 below shows the interface screenshot for the SetRemainder feature after the user
selects SetRemainder icon of the MainMenu.

Fig. 2.31 – Set Remainder

The SetRemainder interface provides the page to set and save remainders for both the patients
and the physicians, to set remainder for other related tasks in the specified date and time. Also
this interface provides option to see and edit remainders with descriptions.

56
Figure 2.32 below shows the interface screenshot for the MedicalHandBook feature after the
user selects MedicalHandBook icon of the MainMenu.

Fig. 2.32– Medical Hand Book

The MedicalHandBook interface provides the page to search and view the specified disease
along with its symptom and medication. This interface also provides AddNew feature in order to
add disease, its symptom and medication to the medical hand book.

57
Figure 2.33 below shows the interface screenshot for the EditMedicalHandBook feature after the
user selects EditMedicalHandBook icon of the MedicalHandBook.

Fig. 2.33 – Edit Medical Hand Book

The EditMedicalHandBook interface provides the page to set and save the disease along with its
symptom and medication after the user inserts information in the fields, and the edit option
which displays the interface after populating the information in the fields.

58
 CHAPTER THREE
3. System design
3.1 Introduction
The purpose of designing is to show the direction how the system is built and to obtain clear
and enough information needed to drive the actual implementation of the system. It is based on
understanding of the model the software built on. The objectives of design are to model the
system with high quality. Implementing of high quality system depend on the nature of design
created by the designer. If one want to changes to the system after it has been put in to operation
depends on the quality of the system design. So if the system is design effectively, it will be easy
to make changes to it.

3.2purpose and goals of design

The design goals represent the desired qualities the system should have and provide a consistent
set of criteria that would be taken into consideration when making design decisions. The
following are mentioned as the design goals of “mobile assistant and patient record management
system for family doctors “.

Security: the system should be secure to maintain data confidentiality. The system should
authenticate it’s users by prompting them to enter user name and password in order to get access
to the system.

Extensibility: the system should allow any additional services easily if needed, in other words it
should not be difficult to extend the system if additions are necessary.

Availability: the system should be available every time the user needs to access it.

Usability: the system should have user friendly user interface to allow the user to interact with
the system easily.

Portability: the system should be able to run on any mobile that supports j2me mobile
applications.

Performance: the main performance measure for a project is time, so the system should give fast
responses for user requests.

59
3.3Proposed software architecture
The architecture which will be used for the proposed system is a two tier architecture where the
client or the user side is a mobile phone containing user interfaces like data entry interfaces, it is
used to display information to the user. User directly interacts with the system through the
interfaces on this layer.

The data layer or the database is responsible for storing all information needed for the system to
function correctly. It is used to record or store information like, family information, patients’
information, appointments and other data needed to be stored.

Figure 3.1 proposed

software architecture for
MAPRMSFD.

60
3.2.1Subsystem decomposition

Subsystem decomposition will help reduce the complexity of the system. The subsystems can be
considered as packages holding related classes or objects. The MAPRMSFD is decomposed into
the following subsystems.

Figure 3.2: layered representation of the system

61
Login subsystem: authenticates user in order to check whether the user is the actual user or not.

Family registration subsystem: registers the families and the members in each family.

Patient registration: patient registration subsystem registers patients who are already registered
as a member of a particular family.

Send sms: the system automatically sends sms to the patient phone based the time and the
description set on the reminder.

Appointment subsystem: keep record of the appointments the physician has and allows him/her
to adjust appointments based on their schedule.

Reminder subsystem: allows the physician to set reminder for him/her self or for patients.

Invoke alarm: the system invokes an alarm to remind appointments and some other tasks for the
physician based the time and date given on the appointment setting.

Refer handbook: used as a reference used by physician.

3.2.2Component diagram

In the unified modeling language, a component diagram depicts how components are wired
together to form large components and or software systems. They are used to illustrate the
structure of arbitrarily complex systems. The component diagram for MAPRMSFD is showed
below.

62
63
Figure 3.3 component diagram for MAPRMSFD.

3.2.3Deployment diagram

A deployment diagram in unified modeling language models the physical deployment of artifacts
on nodes.

Figure 3.4 deployment diagram for MAPRMSFD.

3.3Persistent modeling for object oriented database

64
Persistent data management deals with how the persistent data is stored and managed and it
outlives a single execution of the system. Information related with families, patients,
appointments and other related information are persistent data and hence stored in a database.

3.3.1Mapping of objects into tables

In order to store information into database persistently we map objects into tables and attributes
to the specific table based on the object found on the system. The following figure shows the
mapping of objects into tables to be stored in to database.

member details member details –table

Member number Member number <<PK>>
Full Name Full name
Birth date Birth date
Sex Sex
City City
Phone number Phone number
Family no <<FK>>

FAMILY DETAIL FAMILY DETAIL -

Family no
<<TABLE>>
Family name Family no << PK>>
Family name

65
 patient detail
patient detail
<< table >>
Patient no
Patient no <<PK>>
Full name
Full name
Sex
Sex
Age
Age
Phone number
Phone number
History
History
Family no <<FK>>

Appointment Detail Appointment Detail-

Appointment no <<Table>>
Patient name Appointment no<<PK>>
Date Patient name
Time Date
Time
Patient no <<FK>>

Medical handbook Medical handbook -

Index no <<table>>
Disease name Index no <<PK>>
Symptom Disease name
Medication Symptom
Medication

User accounts
<<table>>
Account id << PK>>
66
User name
Password
Doctor name
Designation
User accounts
Account id
User name
Password
Doctor name
Designation

Reminder Details
Reminder Details <<table>>
Reminder no Reminder no <<PK>>
Subject Subject
Time Time
Date Date
Patient number << FK>>

67
Illness detail
Ill_id Illness detail <<table>>
Ill-Date Ill_id <<PK>>
Ill_description Ill_date
Ill_description
Patient _no<<FK>>
Prescription_no<<FK>>
Prescription _detail Prescription_detail
Pres-id <<table>>
Pres-date Pres_id <<PK>>
Drug_name
Pres_date
Quantity
drug name
Time
quantity
time
Paient_no <<FK>>

Figure 3.5 Mapping objects into table

68
3.3.2Relationship between tables
The following figure shows the relationship between the tables that are used to store data
persistently in the system.

Figure 3.6 Relationships between tables.

3.4Access control and security

The system we are developing will be deployed on mobile phones which are owned by a
particular doctor or physician, hence as long as the user is the actual user authenticated user can
access whatever the functions provided by the system.

69
References

[1] http://www.ibm.com/developerworks/rational/library/3101.html
[2] http://www.agilemodeling.com
[3] http://www.youtube.com/watch?v=18_kVlQMavE
[4] Degif Teka, Project report on school management system, 2008.
[5] Christine zhenwei Qiang, Masatake yamamichi, Vicky Hausman and Daniel Altman, Mobile
applications for the health sector, ICT sector unit World Bank, 2011.
[6] The object primer, Third edition, by Scott W.Ambler.

70