Appointment and Workload Management

System
by

CS 18-11

Department of Computer Science

School of Computing & Informatics Technology

A Project Report Submitted to the

School of Computing and Informatics Technology for the Study Leading to
a Project Report in Partial Fulfilment of the requirements for the
Award of the Degree of Bachelor of Science in
Computer Science of Makerere University

Supervisor:
Dr. John Ngubiri

Department of Computer Science

School of Computing & Informatics Technology
[email protected] Tel: +256414540628

June, 2018
Dedication

We dedicate this report to the Almighty God who gave us the knowledge and
ability to continue with our project successfully. We further dedicate it to
our parents and guardians for their unceasing and selfless support throughout
our stay in this university.

iii
Acknowledgement

We are deeply indebted to our project supervisor Dr. Ngubiri John whose un-
limited steadfast support, guidance and inspirations have made this project
a great success. In a very special way, we thank him for all the knowledge
and support he rendered unto us to see that we succeed in this challenging
study.

Special thanks goes to our friends and families who bared with us during
the hectic moments and stress we went through during the course of our
Final Year Project.

We thank the school for giving us the grand opportunity to work as a team
which has indeed promoted our team work spirit, interpersonal and commu-
nication skills. We also thank the individual group members for the unending
team spirit, will and solidarity that was exhibited during the course of the
project.

iv
Abstract

The health sector is among the most important sectors in the Republic of
Uganda. The rate at which health facilities such as hospitals, pharmacies
and medical laboratories are established and/or revamped increases annu-
ally. These facilities must provide spot-on services for their clients, as well
as acceptable working conditions for their medical personnel. This report
describes the development of an appointment and workload management
system designed to provide support to health facilities in terms of service
delivery for clients coupled with creation of equally favorable conditions for
all personnel. It describes the problem being addressed, objectives intended
for the project, and a review on the functionality of existing related systems.
The report also provides a full description of the development cycle (design
and implementation) of the system.

v
Contents

Declaration i

Approval ii

Dedication iii

Acknowledgement iv

Abstract v

Abbreviations/Acronyms xi

1 Introduction 1
1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Main Objective . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.1 Specific objectives . . . . . . . . . . . . . . . . . . . . . 3
1.4 Scope of the Project . . . . . . . . . . . . . . . . . . . . . . . 3
1.5 Significance of the Project . . . . . . . . . . . . . . . . . . . . 3

2 Literature Review 5
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Related Systems . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1 Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1.1 Strengths . . . . . . . . . . . . . . . . . . . . 5
2.2.1.2 Weaknesses . . . . . . . . . . . . . . . . . . . 6
2.2.2 AppointMate . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.2.1 Strengths . . . . . . . . . . . . . . . . . . . . 6
2.2.2.2 Weaknesses . . . . . . . . . . . . . . . . . . . 6
2.2.3 Jituzu . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.3.1 Strengths . . . . . . . . . . . . . . . . . . . . 7
2.2.3.2 Weaknesses . . . . . . . . . . . . . . . . . . . 7

vi
 2.3 Comparison of the Systems . . . . . . . . . . . . . . . . . . . . 7
2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Methodology 9
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Data Collection . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1 Oral interviews . . . . . . . . . . . . . . . . . . . . . . 9
3.2.2 Internet research . . . . . . . . . . . . . . . . . . . . . 10
3.3 Tools Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4 Data Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.5 System Design and Implementation . . . . . . . . . . . . . . . 11
3.6 Testing and Validation . . . . . . . . . . . . . . . . . . . . . . 11

4 System Analysis and Design 12

4.1 System Study . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2 System Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.1 Data analysis . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.2 Requirements specifications . . . . . . . . . . . . . . . 15
4.2.2.1 User requirements . . . . . . . . . . . . . . . 15
4.2.2.2 System requirements . . . . . . . . . . . . . . 16
4.3 System Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3.1 Use case diagram . . . . . . . . . . . . . . . . . . . . . 17
4.3.2 Context diagram . . . . . . . . . . . . . . . . . . . . . 18
4.3.3 Data flow diagram . . . . . . . . . . . . . . . . . . . . 19
4.3.4 Database design . . . . . . . . . . . . . . . . . . . . . . 21
4.3.5 Design methodology . . . . . . . . . . . . . . . . . . . 22

5 System Implementation, Testing and Validation 23

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.2 System Implementation . . . . . . . . . . . . . . . . . . . . . . 23
5.2.1 User interface design . . . . . . . . . . . . . . . . . . . 23
5.3 System Testing and Validation . . . . . . . . . . . . . . . . . . 28
5.3.1 System testing . . . . . . . . . . . . . . . . . . . . . . 28
5.3.1.1 Unit testing . . . . . . . . . . . . . . . . . . . 29
5.3.1.2 Integration testing . . . . . . . . . . . . . . . 29
5.3.2 Validation . . . . . . . . . . . . . . . . . . . . . . . . . 29

6 Recommendations, Conclusion and Future Works 31

6.1 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.3 Future Works . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

vii
7 Appendices 35
7.1 Appendix A: Sample code . . . . . . . . . . . . . . . . . . . . 35
7.2 Appendix B: Interview questions . . . . . . . . . . . . . . . . 37
7.3 Appendix C: Work plan . . . . . . . . . . . . . . . . . . . . . 38

viii
List of Figures

2.1 A comparison of the system features. . . . . . . . . . . . . . . 8

4.1 A pie chart showing the percentage of patients with smart

devices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2 A pie chart rating appointment scheduling methods. . . . . . . 14
4.3 A bar graph showing doctors’ contentment towards workload
distribution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.4 Use case diagram/blueprint of the system. . . . . . . . . . . . 18
4.5 Context diagram of the system. . . . . . . . . . . . . . . . . . 19
4.6 Data flow diagram of the system. . . . . . . . . . . . . . . . . 20
4.7 Entity relationship diagram of the system. . . . . . . . . . . . 21

5.1 Interface for registering and creating doctor accounts. . . . . . 24

5.2 Account creation interface for patients. . . . . . . . . . . . . . 24
5.3 User login interface. . . . . . . . . . . . . . . . . . . . . . . . . 25
5.4 Appointment scheduling interface. . . . . . . . . . . . . . . . . 25
5.5 Location of the health facility. . . . . . . . . . . . . . . . . . . 26
5.6 View of the doctors available and their time for an appointment. 26
5.7 Appointment request viewed by a doctor. . . . . . . . . . . . . 27
5.8 Viewed appointment marked as seen. . . . . . . . . . . . . . . 27
5.9 Error message displayed by the system. . . . . . . . . . . . . . 28

7.1 Sample code for displaying error messages. . . . . . . . . . . . 35

7.2 Code for testing the user type. . . . . . . . . . . . . . . . . . . 36
7.3 Code for redirecting a user to their specific interface. . . . . . 36

ix
List of Tables

3.1 Main tools used during data collection. . . . . . . . . . . . . . 11

4.1 System hardware requirements. . . . . . . . . . . . . . . . . . 16

4.2 System software specifications. . . . . . . . . . . . . . . . . . . 17

7.1 Work plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

x
Abbreviations/Acronyms

App Application

AWMS Apppointment and Workload Management System

CSS Cascading Style Sheets

DBMS Database Management System

ERD Entity Relationship Diagram

HTML Hypertext Markup Language

IT Information Technology

MySQL Structured Query Language

OS Operating System

xi
Chapter 1

Introduction

Several University students in Uganda prefer hostels to halls of residence.

Students in hostels often rely on their smartphones to keep abreast of what
is happening on campus.

1.1 Background
Over the years, numerous health facilities such as hospitals and clinics have
been established in different locations of the country due to the enormously
high demand for their services.

For any patient or client of the health facility to access these services, an
appointment must be scheduled with a doctor at an agreed day nd time to
improve on service delivery. Some situations however, such as emergency
cases where immediate attention is required do not need appointments to be
scheduled. A patient must be attended to by an immediate doctor because
such cases do not provide room for wasted time. In some health facilities,
patients do not schedule appointments at all. Once one goes to the facility,
he is given any doctor available to work on him at that time, and if none is
available the patient is advised to either wait for some hours or come back
the next day.

With these services, many complaints arise from various patients when it
comes to lining up in long queues to be able to schedule appointments with
health specialists. Patients are told to first fill appointment forms after which
they have to wait for hours to get a response on whether their appointments
have been successfully scheduled or not. For cases of unsuccessful scheduling,
patients have to wait for days to be able to get their appointments confirmed.

1
This means that a lot of time is wasted on patients’ side in making unnec-
essary movements to and from the facility to the final day of when they are
worked on. With such delays and disorganization with appointment sched-
ules, it raises a question of what would happen if an emergency occurred and
all doctors are occupied by other patients. Would a doctor have to tun off
from his patient to attend to the emergency cases or would the patient with
am emergency have to wait for a doctor to be available?

When it comes to workload distribution among doctors, it has been noted

that some doctors have been overwhelmed by the number of patients they
are supposed to work on whereas others are left free. This is because health
facilities do not specify shifts for each doctor nd how many patients one must
attend to per shift. This increases the possibility of one doctor being loaded
with many patients while there’s one that is completely free. Also relating to
the doctors’ workability, if prior appointments are not made, a doctor is not
given the ability to properly prepare the tools and equipment needed for his
meeting with a patient. This is time consuming because the doctor organizes
the equipment while a patient sits and waits for the doctor to be ready.

1.2 Problem Statement

The current process of queuing and filling of appointment forms used by
most health facilities within the country has proven to be tedious and time
consuming. Considering a big health facility (such as Mulago hospital) which
works on a large number of patients on a daily basis, one can spend almost
half a day just trying to set an appointment with a health specialist because
of the long queues.

In some hospitals, appointments are not even scheduled. Once a patient

walks in, he is assigned to any doctor available at that time. This however
can be risky in some situations such as emergency cases if all the doctors are
occupied. It can lead to disorganization in terms of choosing who to work on
the emergency patient which can lead to a stand-still on hospital operations.

Existing patient appointment scheduling system allow patients to select a

personally known doctor they want to schedule an appointment with. This
means that there are high chances of one doctor being selected by many pa-
tients depending on their level of preference for that particular doctor, leaving
most of the other doctors in the facility less occupied during their allocated
shifts. This leads to the uneven distribution of workload among doctors bas-

2
ing on the number of appointment requests received per day. The problem
this system addresses is the uneven distribution of workload among doctors
which always occurs during appointment scheduling.

1.3 Main Objective

To develop a system that allows patients to schedule appointments with doc-
tors, and provides even/uniform distribution of workload for doctors within
a particular health facility.

1.3.1 Specific objectives

The specific objectives of the study were:
i. To carry out a study on the literature of related and/or existing medical
appointment scheduling systems to identify the necessary requirements
for the system.
ii. To design the prototype that illustrates the main functionalities of the
system.
iii. To implement the designed system prototype.
iv. Finally, to carry out testing and validation of the implemented system.

1.4 Scope of the Project

The system aims at eliminating uneven distribution of workload among doc-
tors of the same specialty in a health facility during the process of scheduling
appointments by patients. The system ensures that each doctor receives one
appointment at a time depending on the workload of other doctors (with the
same specialty) in the system. This means that on a normal working day for
example, each doctor can have at most four patients attended to at the end
of a shift rather than one doctor having three while another has only one
The system supplements the automation of even workload distribution as
part of appointment scheduling in a health facility.

1.5 Significance of the Project

The Appointment and Workload Management System is significant in the
following ways:

3
 i. Once completed and fully functional, the system will greatly reduce on
the overall amount of time taken by patients to see health specialists
by providing on-line appointment scheduling. This is archived by elim-
inating the long queues and appointment forms that are currently used
by most health facilities.

ii. The system improves the effectiveness and workability of doctors in

a health facility through the uniform distribution of work-load. This
is attained by ensuring that all doctors are given an equal number of
patients to work on during their allocated shifts.

iii. The system also provides room for further study within this area by
creating a source of reference literature for students that would wish
to develop similar/related systems.

4
Chapter 2

Literature Review

2.1 Introduction
The main purpose of this chapter is to present a review of some of the re-
lated/existing appointment scheduling systems currently used by health fa-
cilities, together with their strengths and weaknesses.

2.2 Related Systems

2.2.1 Eclipse
This is a practice management software that was developed by the MPN
software systems company in the United States. It has been in daily use at
thousands of locations for over 20 years. Eclipse includes medical scheduling
features such as patient appointment scheduling and management, storage
and access for patients’ records.

2.2.1.1 Strengths
(i) Eclipse provides billing estimates for medical services required by pa-
tients as they request for appointment schedules. The software allows
processing of payments on-line and also provides patients with their
payment history for those that usethe system more than once.

(ii) Eclipse also provides patient management features such as location

tracking which allows the medical facility to identify he location of
its patients when required. This can be used to investigate the state of
a patient for cases of ’no-shows’ on the day an appointment was set.

5
2.2.1.2 Weaknesses
(i) The software does not cater for workload distribution among doctors
registered in the system. A patient can schedule an appointment with
any doctor displayed by the system during any time of their conve-
nience.

(ii) Eclipse does not have a functionality that considers cases of emergency
patients.

2.2.2 AppointMate
This is a medical appointment scheduling software that was developed by
Delta Health Technologies company in the United States. It provides patient
scheduling and record management features.

2.2.2.1 Strengths
(i) The software provides billing and invoicing information required by
patients while scheduling appointments, allowing them to be informed
about their pricing capabilities and affordability of the services to be
used.

(ii) AppointMate provides alerts for over-due appointments to doctors for

cases of patient ’no-shows’ providing room to perform follow-ups on
patients.

(iii) It records the shift availability of doctors in a health facility.

(iv) It also provides patients with a map and turn-by-turn directions o a

health facility for cases where the location is not known.

2.2.2.2 Weaknesses
(i) AppointMate does not support the even distribution of workload, re-
gardless of the fact that it provides records for the shift availability of
the different doctors in a facility.

(ii) It also has no functionality that provides support for emergencies.

6
2.2.3 Jituzu
This is a mobile phone application that enables service provider professionals
to better engage with their clients. Jituzu is used to allow easy communica-
tion between patients and health workers at all times.

2.2.3.1 Strengths
(i) Jituzu is similar to Eclipse in that it also provides on-line billing and
payment processing features which are used by patients to approximate
the charges required for medical services.

(ii) The App allows both patients and doctors to set appointment re-
minders. These are set before the appointment’s date to allow one
easily remember and prepare for the appointment.

(iii) The App has a no-show tracking functionality which allows a doctor to
identify which patient did not appear for an appointment, and whether
there is a reason given by that patient.

(iv) The App also provides on-call scheduling whereby patients log in to
the system, select a doctor to schedule an appointment with, and then
make a direct phone call to set a date. This is archived through a fast
response time which is suitable for real-time communication between
patients and health workers.

2.2.3.2 Weaknesses
(i) Similar to Eclipse, Jituzu does not support even/uniform workload dis-
tribution among similar doctors registered in the system.

(ii) The calendar used by the App for scheduling appointments does not
provide separability between valid and invalid dates for a patient to set
an appointment. This affects the level of visibility and clarity for users.
Patients also have trouble when tracking across from left where hours
are marked to select a day for setting the appointment.

2.3 Comparison of the Systems

The figure below shows a comparison of the three systems identified above
in terms of the key functionalities they provide for their users, together with
the key functions they do not implement.

7
 Figure 2.1: A comparison of the system features.

2.4 Conclusion
Current systems used by health facilities for patients to schedule appoint-
ments with doctors, as identified above, do not cater for the even distribution
of workload during the scheduling process. It is only AppointMate that puts
into consideration records concerning the shift allocation for each doctor
registered in the system but it does not use this information to ensure
uniformity in workload distribution.

The other main weakness that was identified with these existing systems is
that they do not consider emergency cases. a situation can occur whereby a
patient needs to be attended to urgently but when all doctors are occupied
by other patients. This can cause major alterations in operations.

The other procedure used in scheduling appointments by queuing and filling

appointment forms is very time consuming and exhausting according to the
comments given by a number of patients in different health facilities.

The proposed system will address these challenges/weaknesses by making

sure that workload is evenly distributed among doctors. This provides sup-
port for emergency situations whereby a minimal number of doctors is always
made available whenever an emergency occurs.

8
Chapter 3

Methodology

3.1 Introduction
This chapter highlights the different techniques that were used to successfully
complete the project. It provides a description of the development cycle, data
collection and analysis methods, system design and implementation methods,
together with the system testing and validation techniques that were applied
to make sure that the system satisfies and meets user requirements.

3.2 Data Collection

Below ae the methods that we used to gather relevant data that was used to
identify the core user needs and/or requirements for proper implementation
of the system.

3.2.1 Oral interviews

Interviews were conducted to gather information about the current setting
as far as how appointments are scheduled and how the workload of doctors
is managed and distributed within a health facility. These interviews were
conducted on a few patients and medical workers we interacted with. We
also had interactions with fellow students regarding their visits to various
health facilities in the country.
Reasons for using this method:
(i) We found it much easier to start conversations with our subjects, which
then became our interview sessions without them feeling subjected to
random questions. This made it easy for us to gather as much infor-
mation as we needed for our developed system’s requirements.

9
 (ii) Oral interviews provide room for collecting more information through
use of open-end questions, and not limiting the answers/responses that
can be given by an interviewee.

(iii) Last but not least, oral interviews are also considered as one of the
cheapest method of data collection when looking at a minimal study
set. In this case we looked at the major health facilities in Kampala
such as Mulago and Nsambya hospital.

3.2.2 Internet research

Internet research was conducted to gather information on existing appoint-
ment scheduling systems currently in use. More research was carried out to
analyze how workload of doctors is managed, and whether there are any sys-
tems already developed. Through Internet research we highlighted the main
challenges users find with the existing systems by looking at different user
reviews posted on-line.
Reasons for using this method:

(i) Internet research allows the collection of data for systems not only in
Uganda but in different parts of the world.

(ii) More information could be obtained in a very short period of time

through looking at different on-line resources such as websites and blogs
with system reviews on various applications.

3.3 Tools Used

The table below shows the tools that were used during the two data collection
methods/techniques mentioned above.

10
 - Pens

- Paper
Oral interviews
- Mobile phones (when audio recording was re-
quired)

- Internet enable mobile phones

Internet research
- Laptops with WiFi connection

Table 3.1: Main tools used during data collection.

3.4 Data Analysis

The collected data was analyzed to be able to attain consistency and relia-
bility for proper modeling and implementation of the system. The data was
studied to identify key user and system requirements. These were classified
under functional and non-functional requirements.

3.5 System Design and Implementation

The functionalities of the system were implemented using C-Sharp for
the back-end code. User interfaces were designed using HTML, CSS and
JavaScript, while MySQL was used for creating and manipulating the re-
quired databases.

3.6 Testing and Validation

Once implementation of the system was completed, we performed testing
and validation of its functionalities by using sample data to evaluate how
fast user input is processed, and if the output is provided in the required
form by our target users. We were also able to identify the response time of
the system and whether all the system requirements are met.

11
Chapter 4

System Analysis and Design

This chapter describes the system study, analysis and design of the system. It
highlights the identified requirements and architectural design of the system.

4.1 System Study

This was carried out on some hospitals in Kampala, that is Mulago and
Nsambya hospital where the main purpose was to find out how appointments
are scheduled and how workload is distributed according to the number of
doctors available in the hospital per day. We were able to identify that the
system currently used in these health facilities is entirely manual. When
a patient wants to schedule an appointment, he is supposed to go to the
facility and physically contact the responsible personnel to schedule the ap-
pointment. In these hospitals, workload is hardly put into consideration. As
a result, any number of patients can be assigned to only one specific doctor
without considering the current workload of other doctors. We realized that
this greatly affects the workability of most doctors in the hospital.

4.2 System Analysis

4.2.1 Data analysis
During the oral interviews we conducted, 60% of patients owned smart
phones and hence would be able to easily access the system to sched-
ule appointments on-line with much ease. 27% owned smart phones but
also believed that accessing the system using a laptop would be more ef-
ficient for them as they already owned personal laptops/computers. The
remaining portion (13%) did not own smart phones, but they were open

12
to being helped by the personnel at a health facility with the on-line
process. This is why we recommend the facility to ensure that a sup-
port team is available to help such patients that are not well versed
with the on-line system. The pie chart below shows the above analysis.

Figure 4.1: A pie chart showing the percentage of patients with smart devices.

We asked patients to rate the currently used appointment scheduling meth-

ods, i.e. queuing and filling of appointment forms. 29% agreed that forms
were more efficient and easier to follow up on compared to making long
queues, 14% were fine with queuing and said they had gotten used to the
whole process. 57% of our interviewees agreed that having an on-line sys-
tem would make the whole appointment process much faster, easier and less
time consuming. This analysis is also described by the pie chart below.

13
 Figure 4.2: A pie chart rating appointment scheduling methods.

Looking at the workload of doctors in hospitals, over 69% of the doctors

we talked to had complaints on how uneven workload was distributed on
a daily basis. Some of them even complained that regardless of whether
shifts were allocated, they would find themselves working beyond the hours
of their shifts. 24% were however contented with the current workload eval-
uation methods used in their hospitals and had no major complaints. The
remaining 7% was not really sure if workload distribution was an issue to
them but were interested in the idea of having workload management system
in place. The graph below illustrates the above analysis when doctors were
asked if they were contented with their current workload distribution, or not.

14
Figure 4.3: A bar graph showing doctors’ contentment towards workload
distribution.

4.2.2 Requirements specifications

The requirements of AWMS were classified into user and system require-
ments.

4.2.2.1 User requirements

During data collection, we analyzed how current systems operate by looking
at their functionalities and associated weaknesses. We categorized user
requirements into functional and non-functional requirements.

Functional requirements specify what the system is expected to

do. These include:
(i) AWMS must accept submission of information for patients and medical
personnel.
(ii) The system should be able to assign patients to appropriate doctors
according to the current state of workload distribution at the time a
patient schedules an appointment.

15
(iii) The system must provide user authentication for its different user types.

iv. It should also be able to identify authorization levels for users.

Non-functional requirements describe the behavior of the system, and

these include:

(i) The system must verify and validate all user input. Error messages
must be displayed immediately once any invalid input is detected.

(ii) Any modifications that are made to the system’s database should be
updated to all users accessing the system within a maximum of one
minute.

iii. The system must also provide data security and integrity for the infor-
mation of its users.

iv. The system should be able to recover from any complications as quickly
as possible in oder to avoid interruptions of operations at the health
facility.

4.2.2.2 System requirements

These describe the hardware and software requirements needed for effective
and efficient running of the system.

Hardware requirements:
The table below shows the hardware components that a computer must
have for proper functioning of the system.
Hardware component Minimum requirement
Processor 2.4 Ghz processor speed
Memory 2 GB Ram
Disk space 500 GB including 20 GB for the DBMS
800 by 600 color, 1024 by 768 high color - 16
Display
bit recommended

Table 4.1: System hardware requirements.

Software requirements:
The table below shows the software specifications that a computer must have
for proper functioning of the system.

16
 Software component Minimum requirement
OS Windows 7 or later
DBMS MySQL server
Runtime environment WampServer

Table 4.2: System software specifications.

4.3 System Design

This section includes a detailed description of the system’s architecture. It
describes the design and development process of the application using a use
case diagram to explain how the actors will interact with the system and
data flow diagrams to show the flow of data in the system.

4.3.1 Use case diagram

This describes the different types of users of the system, and how they
independently interact with the system. The use case diagram is a blueprint
of the system, providing a simplified graphical representation of the systems
functionalities. The diagram shows the three key users (actors) of the
system, that is: the patients in the health facility, doctors that are part of
the personnel team, and members of the top management/administration of
the health facility such as human resource managers.

17
 Figure 4.4: Use case diagram/blueprint of the system.

4.3.2 Context diagram

This is a diagram that illustrates AWMS as a single process, showing
how external entities interact with the system together with an overview
of its main functionalities. The diagram shows a patient, doctor and
administration personnel as external entities.

18
 Figure 4.5: Context diagram of the system.

4.3.3 Data flow diagram

The DFD illustrated in figure 4.7 below shows the graphical representation
of the flow of data in the system. It describes the different processes involved
in the system and data that flows in and out of each process depending on

19
the interactions from the external entities.

Figure 4.6: Data flow diagram of the system.

20
4.3.4 Database design
The entity relationship diagram bellow illustrates te interrelationship
between the different entities that are used in the system database. The
DBMS that was used is MySQL server.

Figure 4.7: Entity relationship diagram of the system.

21
4.3.5 Design methodology
The methodology that we used is the agile development method. This is a
creative process that provides room for flexibility and applies a high level of
organization into the delivery of the final system. We were able to focus on
maintaining simple and organized code by performing regular testing, and
obtaining system functionalities as soon as they were ready. This enabled us
to eliminate risks such as code errors/bugs.

22
Chapter 5

System Implementation,
Testing and Validation

5.1 Introduction
This chapter describes how the system was implemented. The purpose of
implementation and validation was to make sure that the system meets its
set objectives and requirement specifications that were identified.

5.2 System Implementation

This section defines the user interfaces and activities that allow users to
interact with the system.

5.2.1 User interface design

(i) Account Creation:
For any patient or hospital personnel to use the system and/or access its
information and services, he/she is required to have a user account. Figure
5.1 shows the interface that allows a member of the administration to create
accounts and register doctors and other personnel in the hospital. Figure 5.2
shows the interface for patients to register their details (personal information)
into the system used to create their user accounts.

23
 Figure 5.1: Interface for registering and creating doctor accounts.

Figure 5.2: Account creation interface for patients.

(ii) Login activity:

Once a user creates an account, the login interface is used to sign into the
system and access his/her information. This activity is shown in figure 5.3.

24
 Figure 5.3: User login interface.

(iii) Appointment scheduling:

When a patient signs into the system, he/she can be able to
schedule an appointment by selecting a valid date and adding a
brief description or message for his appointment request, as seen
in figure 5.4. The patient can also view the location of the
hospital while scheduling his appointment (as seen in figure 5.5).

Figure 5.4: Appointment scheduling interface.

25
 Figure 5.5: Location of the health facility.

Once the appointment details are entered, the patient can then view and
select the preferred time for his appointment. This is shown in figure 5.6.

Figure 5.6: View of the doctors available and their time for an appointment.

(iv) Appointment requests:

Once patients request to schedule an appointment with a doctor, he can
be able to view all these requests which show the name and a brief de-
scription as input by the patient. The appointments viewed are also
marked as seen. Figures 5.7 and 5.8 illustrate this system feature.

26
 Figure 5.7: Appointment request viewed by a doctor.

Figure 5.8: Viewed appointment marked as seen.

(v) Error messages:

Error messages are displayed by the system whenever an invalid input is
detected. Figure 5.9 shows an error message that is displayed when a patient
selects an invalid date while scheduling an appointment. The message is
displayed as red text.

27
 Figure 5.9: Error message displayed by the system.

5.3 System Testing and Validation

Regular testing and validation of a system is required to ensure that the
quality and integrity of the system model is maintained throughout the de-
velopment process. Testing and validation was conducted to ensure that the
AWMS meets its specifications and fulfills its intended objectives.

5.3.1 System testing

Testing was performed throughout the development process to ensure that
we were developing the desired system in the right way. This was done in
two ways, that is: unit testing and integration testing.

Test Plan: The system was designed to prescribe the scope, approach,
resources, and schedule all testing activities. The plan identifies the items
and features tested, the types of testing that were performed, the personnel
responsible for testing, the resources and schedule required to complete the
testing process.
The purposes of a software test plan include:
(i) To achieve the correct code and ensure that all functional and design
requirements are implemented as specified in the systems documenta-
tion.

28
 (ii) To provide a procedure for unit and system testing.

(iii) To identify the test methods to be used.

Process of Test Plan:

(i) Identify the requirements to be tested. All test cases were derived using
the existing design specifications.

(ii) Specify the particular tests to use for each module.

(iii) Identify the expected results for each test.

(iv) Perform the test.

5.3.1.1 Unit testing

Unit testing was carried out on individual modules of the system to ensure
that they are fully functional units. We did this by examining each unit.
Looking at the appointment module, it was tested to ensure that it functions
as required and that it captures data and other details as input. We had to
ensure that all this data is stored within the systems database appropriately.
The success of each individual unit gave us the go ahead to carry-out inte-
gration testing. Any error conditions that were identified were handled as
well.

5.3.1.2 Integration testing

We carried out integration testing after different modules had been put to-
gether to make a complete system. Integration testing was aimed at ensuring
that modules are compatible and they can be integrated to form a complete
working system. For example we tested to ensure that when a user is logged
in, he/she is redirected to the appropriate page.

5.3.2 Validation
System validation was performed to ensure that the system meets its require-
ments. A combination of checks were evaluated to identify, fix and eliminate
any run-time errors users would encounter while using the system. Some of
the validation checks that were conducted include:

(i) Does the system only allow users to login with valid user-names and
passwords?

29
(ii) Does the system maintain its authorization levels for the different user
types?

(iii) Are doctors able to view all appointment requests sent in by patients?

(iv) Does the system display required error messages for any invalid input
detected?

30
Chapter 6

Recommendations, Conclusion
and Future Works

This chapter describes our recommendations for the different users of the
system, conclusions as well as future works/enhancements for the system.

6.1 Recommendations
Training of staff members/medical personnel in the hospital with how
the system works is a major priority. Making sure that all doctors are
able to use the system with ease and confidence would increase n their
effectiveness during work shifts. We therefore recommend that the hospital’s
management ensures that all doctors responsible are trained and given all
the basic information on how to use the system.

The AWMS being a new system (with added technology) some mem-
bers of staff are most likely to get threaten that the computerized system
will replace their jobs. We recommend that the management of the
hospital educates their staff on how the system will operate and how it will
supplement their efforts, instead of replacing their job positions (because
the system would not operate itself without the personnel).

For efficiency of the hospital, all users of the system need to be thor-
oughly informed about the personal information/credentials that they
use to create their accounts. Users are advised to record their passwords
and email addresses safely for easy remembrance while logging in to the
system. We also recommend that the email addresses used are existing
addresses allowing users to receive notifications through email where possible.

31
The system has authorization levels for the different user types, whereby
patients and medical personnel can only view information made accessible
for them and a member of management has the right to access all informa-
tion of the system. We therefore recommend that the management must be
keen on whoever is to be identified as part of the management/admin team.

It is also known that some patients would be illiterate when it comes

to working with components of the system. We strongly recommend that
the hospital should be able to provide such patients with assistance as much
as possible.

6.2 Conclusion
The core reason for the development of a computerized system of scheduling
appointments and managing workload is to improve on how operations run
within the hospital on a daily basis. Therefore the I.T. used should sup-
port the core objective of the system if it is to remain relevant to the hospital.

A lot still needs to be done in the I.T. department in order to make

the available technology effective. This may involve training of staff on how
to operate the system and the management to keep updating hardware and
software requirements of the system. I.T. and computer systems must be
upgraded as more technology is introduced now and then.

6.3 Future Works

Certain elements in this project leave scope for further development. With
almost any project which includes a software component, a list of future
enhancements could be endless.
For purposes of further development, AWMS can be expanded or supple-
mented by adding a functionality of monitoring the use of medical logistics
(such as drugs) and hospital equipment. This would be used by a health fa-
cility to have an estimated period of using a specified amount of its logistics.

The system can also be implemented to support real-time interactions or

conversations between medical personnel and patients. This can help patients
make any inquiries about any medical situation and also send suggestions

32
without the need to be directly at the hospital. A hospital’s personnel can
also be able to send feedback and support more efficiently.

33
References

[1] Delta health technologies: Appointmate user reviews and functionali-

ties. [Online]. https://www.capterra.com/p/117161/AppointMate/,
[Accessed: Feb. 8, 2017].

[2] Jituzu software: User reviews. [Online]. https://www.capterra.com/

p/132355/Jituzu/, [Accessed: April. 05, 2017].

[3] Mpn software systems: Eclipse practice management software. [Online].

http://www.capterra.com/p/27349/ECLIPSE/, [Accessed: Nov. 07,
2017].

34
Chapter 7

Appendices

7.1 Appendix A: Sample code

Figure 7.1 shows the sample code for displaying the error messages for invalid
input.

Figure 7.1: Sample code for displaying error messages.

Figure 7.2 shows the sample code that checks for the user type (whether one
is a patient, doctor or management member) when one logs in.

35
 Figure 7.2: Code for testing the user type.

When the user type is identified, the system redirects the identified user to
their assigned interface view. Figure 7.3 shows the sample code for redirecting
a member of the management team to the management page/interface view.

Figure 7.3: Code for redirecting a user to their specific interface.

36
7.2 Appendix B: Interview questions
We were able to interact with a few people while conducting our oral inter-
views.
Below are a few interview questions we asked the patients we encountered:

a. How often do you make an appointment with a doctor?

b. How long does it take for you to receive a response after requesting for
an appointment?

c. What services do you think should be improved by this health facility?

Below are some interview questions we asked the health workers:

a. What procedure do patients follow to make an appointment with a

health specialist?

b. Is there a way or method currently used to distribute the workload

among doctors within the facility? If yes, please tell us about it.

37
7.3 Appendix C: Work plan
The anticipated time frame for implementing the Appointment and Workload
Management System was approximately six months, and this was followed
subject to our academic calendar for the year. Below was the anticipated
plan that we followed during the implementation process:

Activity Duration
Data collection through interviews and Internet research Two weeks
Data analysis One week
System design and implementation Twenty weeks
System testing and validation One week

Table 7.1: Work plan.

38