Executive Summary

A Hospital online queue management system is specially designed for hospitals to facilitate
the booking of patient’s appointment in advance. As the number of seriously ill patients
visits or admitted continue to increase in hospitals, this results in overcrowding.
Overcrowding may even contribute to violence in hospitals and indirectly affect the number
of patients visiting the hospital. This in turn brings about the need for a Hospital queue
management system.

A Hospital queue management system is a computer or web based system that facilitates
managing the functioning of the hospital. It aims at digitalising the patient’s data which is a
need of an hour. As the hospitals are constantly crowded, it may affect the patient’s
symptoms, clinical outcome and satisfaction of the patient. This may also lead to the
physician becoming ineffective causing frustration among medical staff. The overcrowding
comes as a lack of effective queue management systems in hospitals, which is due time
required for each patient would be uneven based on how much time the doctor takes and
other tasks such as scanning, pharmacy, testing.

1
 Chapter One
Introduction

1.1 Background

A Hospital online queueing system can be used to optimise or reduce the total waiting cost.
The theory of a Hospital online queueing system is that it enables mathematical analysis of
several related processes, including arriving at the queue, waiting at the queue and being
served by the service providers (in this case doctors or other health personnel’s) at the front
of the queue. It permits the derivation and calculation of several performance measures
including the average waiting time in the queue or the system, the expected number waiting
or receiving services and the probability of encountering the system in certain states, such as
empty, full, having an available service or having to wait a certain time to be served.

1.2 Problem Statement

A queue is a line of customers waiting to be served. A hospital online queuing system is

developed with the aim of reducing on the waiting time of patients and those seeking medical
attention and other services, this in turn helps to reduce on overcrowding in hospitals and can
also improve on the efficiency of the delivery of services.

1.3 Project Justification

In Zambia, queueing in hospitals for medical services has been one of the major challenges
faced in the health sector. It has greatly compromised on the delivery of efficient services.
Therefore, the aim of this project is to minimise waiting in queues by proper queue
management and thereby maximising the quality of service delivery. Method is implemented
in the design to achieve an orderly service delivery; this also ensures that patients who have
successfully gotten the queue number are attended to first based on the first in first out
(FIFO) - queue model already programmed. The proposed system when implemented will
minimise the problem of congestion and better service will be achieved. In addition to the
FIFO queue model, the Priority queue model is used in the system to service customers
according to the severity of their problems.
The developed system allows multiple customer profiles to be handled impartially and in a
fair manner and also provides a way for patients to effortlessly and easily access services
without having to wait in line. The developed system also provides timely updates and

2
notifications alert patients and others seeking medical assistance as they move to the front of
the queue. Fast and efficient queue scheduling enables them feel empowered and in control of
their time. This in turn brings patient satisfaction as they won’t have to wait long in line.

1.4 Project Aims and Objectives

1.4.1 General Objectives

The key purpose of the system is to develop a cloud and mobile based system that addresses
the above mentioned problems and allow queue management to be provided as a service
thereby minimizing waiting lines in service-oriented environments.

1.4.2 Specific Objectives

 To develop a system that allows the use of virtual queues in web-based and
mobile platforms.
 Reduce the number of hours spent by patients in hospital queues.
 To reduce congestion/ overcrowding in hospitals
 To implement USSD and messaging services for notifications
 To provide security of the information gathered by the system.

1.4.3 Duration

The duration of this project is six (6) months according to the specifications and time bound
by the owners of the project, to be timely conscious. The critical path analysis will be used
for effective completion of the project.

1.5 Scope

The confinement of the project is to deliver a Hospital Online Queuing system which is
parallel to the existing system that offers a traditional way of queueing physically. The
project is aimed at developing a queueing system using available low power components and
developing a database to store all computerised services.

3
The scope of the developed system Project was planning, designing, developing, and
implementing a Restful API where all virtual queues would be managed and a mobile
application for booking tokens. The system would also provide access to an administrator
dashboard with key metrics for showing various reports and statistics on status of queues and
also permissions that would enable authorized users to update, manage, and view queues.
Administrative dashboards would also contain daily queue statistics, call centres, Department
data, counter and staff data and Reports view. The mobile app was to provide a list of service
centres and booking options.

1.6 LIMITATIONS

The project had the following projected limitations:

 Most features of the system will be available on smart devices, other devices will
have to rely on third party API.
 Less technologically savvy people may be overwhelmed with an advanced system.

4
 Chapter two

2.0 Project Planning and Schedule

Project planning is part of project management, which relates to the use of schedules such as
Grant charts and critical path analysis to plan and subsequently report progress within the
project environment. Initially, the project scope is defined and the appropriate methods for
completing the project are determined. Following this step, the durations for the various tasks
necessary to complete the work are listed and grouped into a work breakdown structure. The
logical dependencies between tasks are defined using an activity network diagram that
enables identification of the critical path.

Figure 1 Project Life Cycle

2.2 Algorithm for Proposed Queue System

In the course of investigation and data collection, the modus operand of Queue records was
learnt. In designing the new system, easy interactive users interface was designed to make it
easy for users to access. The designing of the new system was arranged as follows.

SAVINGS WEB FORM:

 Queue Number
 Date In
 Time In
 Process

CURRENT WEB FORM:

 Queue Number

5
  Date In
 Time In
 Process

FIXED DEPOSITE WEB FORM:

 Queue Number
 Date In
 Time In
 Process

2.3 Flow chart for the proposed system

6
 Figure 2 Flow chart for the proposed system

2.4 Project Appraisal

2.3.1 Meeting with Advisor

Proper meeting with advisor was held biweekly to discuss the issue that became halt in
the progress of the project. Advisor helped with the necessary solution for the\required
problem.

2.3.2 Team Meeting

All members discuss their respective progress in their part in daily meeting and prepare a
final sheet for the meeting with the advisor.

7
 2.3.3 Testing

After completion of each part mentioned in project plan, proofreading and testing was
done for successful verification of the part.

2.3.4 Progress Discussion Meeting

An overall progress discussion meeting was held once a month where current standing of
the project is presented to the advisor and everyone including members share their
opinion and discuss them, and what amendments are necessary to be added.

Project Manager

The project manager’s responsibilities will include:

 Arranging meetings with the client.

 Arranging meetings with other members.
 Supervising members of the project team.
 Monitoring progress of the project.

2.4 Methodology

The methodology adopted is the Waterfall approach. It is one of the most popular model in
Software engineering, it was in fact the very first SDLC model to be used. The approach
taken was to treat the whole process of modelling software in a sequential order, the outcome
or output of the previous step would serve as the input for the next step. This would enable
software developers to separate these steps into distinct stages, with each phase having
different requirements and activities. The illustration bellows shows a representation of the
stages found in the Waterfall Model.

8
 Figure 3 Waterfall Model

The sequential phases in Waterfall model are:

i. Requirement Gathering and analysis: This phase involved performing a feasibility

study and ascertaining all possible requirement of the system.
ii. System Design: This phase involves getting specifications, functional and non-
functional requirements of both software and hardware required to develop the
system. This step also involved defining the system architecture.
iii. Implementation: With outcome from system design of the developed system
prototype, the system was developed in small programs called units, which were
pushed to the next stage to be tested.
iv. Integration and Testing: All the units developed in the implementation were
integrated into the system, isolated and fully tested. Once verified to be working, the
entire system was tested to detect any undetected failures or faults.
v. Deployment of system: Once testing was done, the developed system was deployed
and tested with live customer data.

9
vi. Maintenance. Maintenance of the developed system was to be done in continuum to
ascertain that all functional and non-functional requirements were reached and any
changes to the software and hardware would not affect the customer environment.

Waterfall model is preferable as it has provision for changes and the changes can be
implemented in the maintenance phase. This is because the waterfall model is simple and
easy to understand and use for the developer and the other users. This model also allows for
early design changes and places emphasis on requirement and design before writing any
single line of code which ensures minimal time wastage and effort in design changes.

10
 Chapter Three

3.0 Executions
System executions involves dividing software development work into distinct stages and
coming up with tasks or activities aimed at achieving better planning and time management.
It is considered a trivial part of the systems development life cycle.

3.1 Material

3.1.1 HARDWARE REQUIREMENTS

Consist of hardware requirements to be met in order to successfully run the system:

Desktop Computer to be used for design and development of the system. The computer had
these specifications:

i. Intel® Pentium® processor (or equivalent) with a speed of 2.50GHz or greater

ii. At least 2GB RAM iii. 30 GB (or larger) Hard Disk Drive

Tablet or Smart Phone It was to be used for registering and login in users on mobile,
joining nearby queues and sending text or push notifications in real time.

3.1.2 SOFTWARE REQUIREMENTS

To successfully run the system, there are a number of software requirements had to be met
which were:

i. Operating System: Windows 7 or higher versions of OS (either x86 or x64) or

Alternative Unix based systems like Ubuntu or Linux Mint.
ii. Database Management System: A database to store the details of various patients,
specialists and appointments. The following databased was to be used for the web
server and the mobile-based application.
iii. Firebase Cloud storage: This was to be for data exchange between the application and
the web server.
iv. MySQL Database: For the Web server running the application. v. WampServer 2.1:
Has been used as a web server.

11
v. Android Studio: At least API 7 or above. vii. Programming Languages: PHP, HTML,
JavaScript, CSS

3.1.3 FUNCTIONAL REQUIREMENTS

Functional requirements capture the intended behaviour of a system, and thus, a way of
providing a structured functional blueprint, useful for both developers and users. Having the
functional requirements in mind, we define use-cases for better guiding the interfaces
development from a user perspective and proceed with a general use-case diagram for the
overall picture.

High-Level Use Case Diagram

In modelling literature, use cases are described as “interactions with a specific goal between
actors and the system under consideration”. Actors are external parties to the system that
interact with it, possibly being classes of users or roles, a user can play. This system was to
be used mainly by two parties: the staff, and the customers. System actors and their goals,
that is, the actions they can perform in the system, are now listed.

12
 Figure 4 High Level Use Case Diagram

System actors and what they should be able to do with the system are now listed.

1) Staff
System admin
Login and logout to and from the system admin interface. Create/Modify/Delete
Services for a generic service provider entity. The admin can define service open-
hours (service management) and maximum number of queues for certain service
(service management). The Super Admin doubles as the technical administrator
and maintainer of the whole system. This means he was to have access to all the
created data and used technologies.
Queue Admin
He or she can login and logout to and from the service admin interface, this
allows him or her to give and remove service admin privileges to and from
operators, View and edit Service Settings, use Operation Mode and visualize
Statistics and access other setting.

13
 Queue Operator
Upon login, the operator is prompted to select a desk number, call a customer to
his desk, Open or Close the service, that is, stops tickets creation.
2) Customers
Queue client: Get a ticket for a queue that categorizes this customer’s issue. The
customer is identified by the ticket and gets called by the service to solve an
issue. Log in the appropriate service application, mobile or web, and get a virtual
ticket for a queue categorizing this customer’s issue. Get notifications about that
queue’s progress, until called by the service to solve the issue, given that the
customer used the given info to approach the service in time.
3.1.4 NON-FUNCTIONAL REQUIREMENTS
This system should be easy to work with for both customers and staff (user
friendly interfaces), customizable and deployable for different service provider
entities (e.g. other universities, hospitals, etc.) and achieve cost-effectiveness. It
should be server-based, easy to configure and scalable, ideally enabling the
remote deployment of client units that was to self-configure upon server
connection, making it easier to deploy in large organizations and extensible to
provide interfaces to devices external to this system.
PROCESS DESIGN: CONTEXT LEVEL DFD

Service
admin

Open/close service service details

requesting a token service details

Virtual queue Queue

customers Management admin
give a token system manage services

14
 Figure 5 Context Level DFD

3.1.5 Data base design

Tables

# Name Type Collation Attrib Null Default Extra

utes
1 1d Int (10) unsig No None AUTO_
ned INCREMENT
2 firstname Varchar (191 Utf8mb4_uni No None
code_ci
3 lastname Varchar (191 Utf8mb4_uni No None
code_ci
4 Company- Varchar (191 Utf8mb4_uni No None
id code_ci
5 role Varchar (191 Utf8mb4_uni No None
code_ci
6 country Varchar (191 Utf8mb4_uni No None
code_ci
7 email Varchar (191 Utf8mb4_uni No None
code_ci
8 passwords Varchar (191 Utf8mb4_uni No None
code_ci
9 remember- Varchar (191 Utf8mb4_uni Ye NULL
token code_ci
1 created-at Timestamp Yes NULL
0
1 updated-at Timestamp Yes NULL
1
Users Table

FIGURE 6 USER TABLE

Passwords Reset

# Name Type collation Null Default

1 email Varchar (191) Utf8mb4_unicode_ci No None
2 token Varchar (191) Utf8mb4_unicode_ci No None
3 created_at Varchar (191) Utf8mb4_unicode_ci Yes Null
Figure 7 password reset table

Hospital table

# Name Type Collation Attributes Null

1. id Int (10) No None

2. hospital_name Varchar Utf8mb4_unicode_ci No None

(191
3. hospital_county Varchar Utf8mb4_unicode_ci No None
(191
4. hospital_country Varchar Utf8mb4_unicode_ci No None
(191
5. hospital_open_time Varchar Utf8mb4_unicode_ci No None
(191

15
 6. hospital_description Varchar Utf8mb4_unicode_ci No None
(191
7. hospital_phone Varchar Utf8mb4_unicode_ci No None
(191
8. hospital_zip Varchar Utf8mb4_unicode_ci No None
(191
9. hospital_location Varchar Utf8mb4_unicode_ci No None
(191
10. created_at time_stamp Yes Null

11. updated_at time_stamp Yes Null

Figure 8 hospital table

Departments table

# Name Type Collation Attribu Null Default Extra

tes
1 id Int (10) unassigned No None AUTO_I
NCREM
ENT
2 department_na Varchar Utf8mb4_u No None
me (191) nicode
_ci
3 department_ho Varchar Utf8mb4_u No None
spital_id (191) nicode
_ci
4 department_sta Varchar Utf8mb4_u No None
tus (191) nicode
_ci
5 created_at time_stamp Yes Null
6 updated_at time_stamp Yes Null

Figure 9 department table

Services table

# Name Type Collation Attributes Nul Default Extra

l

1 id Int (10) unassigned No None AUTO_INCREME

NT
2 Service_name Varchar Utf8mb4_unicode No None
(191) _ci

3 service Varchar Utf8mb4_unicode No None

category (191) _ci

16
 4 service_dept_ta Varchar Utf8mb4_unicode No None
ble (191) _ci

5 created_at time_stam Yes Null

p

6 updated_at time_stam Yes Null

p

Figure 10 Services table

Counters table

# Name Type Collation Attributes Nul Defa Extra

l ult
1 Id Int (10) unassigned No None AUTO_INCRE
MENT
2 counter_name Varchar Utf8mb4_unico No None
(191) de_ci
3 counter_status Varchar Utf8mb4_unico No None
(191) de_ci
4 counter_averag Varchar Utf8mb4_unico No None
e_ (191) de_ci
wait_time
5 created_at time_stam Yes Null
p
6 updated_at time_stam Yes Null
p
Figure 11 counters table

# Name Type Collation Attributes Null Default Extra

1 Id Int (10) unassigned No None AUTO_INCRE
MENT
2 Queue_counter_ Varchar (191) Utf8mb4_unicode_ci No None
id
3 Queue_length Varchar (191) Utf8mb4_unicode_ci No None
4 Queue_next_tok Varchar (191) Utf8mb4_unicode_ci No None
en
5 Queue_prev_tok Varchar (191) Utf8mb4_unicode_ci No None
en
6 Queue_status Varchar (191) Utf8mb4_unicode_ci No None
7 Created_at time_stamp Yes Null
8 Updated_at time_stamp Yes Null
Queue Table

Figure 12 queue table

17
# Name Type Collation Attribut Null Default Extra
es
1 Int (10) unassign No None AUTO_INCRE
ed MENT
2 Varchar Utf8mb4_unicode_ci No None
(191
3 Varchar Utf8mb4_unicode_ci No None
(191
4 time_stamp Yes Null

5 time_stamp Yes Null

Tokens table

Figure 13 tokens table

18
 Relationships

Counters table

Queues table

Hospital table Token table

Patients
table

Password
reset Departments
table table
Services table

Figure 14 relationships

19
Input Design

Login page

Figure 15 login page

Dashboard

Figure 16 dashboard page

20
 Call next page

Figure 17 call next page

Manage counters page

Figure 18 manage counters page

TV screen or Monitor display/mobile display

21
Figure 19 TV screen or monitor display/ mobile display

Android Application Screens

Booking a token

Figure 20 booking a token page

Location page
22
Figure 21 locations page

23
 Chapter Four
4.0 Monitoring and Control
System testing involves checking each of the system modules to make sure that they are
functioning properly. System implementation is done after successful system testing to
incorporate the new system into an organization using any of the various changeover
methods.
DATABASE TESTING
The database systems used in this project are MySQL by Oracle Technologies and
firebase, a Real-time NoSQL database by Google. Database testing was done after system
development to check whether the database was able to store the desired data as well as
testing its integration with other components of the system. The developer used various
categories of data to test the integrity of the database. First normal range data was used
and the results were valid after processing. Extreme data was used to test whether the
system could accommodate the extreme ranges. Further, exceptional data was used to test
how the system would respond when subjected to invalid data. Consider the following
test data performed on the Users table. The two fields under test are Email and password.

FIELD DATA TEST DATA RESPONSE COMMENT

NAME TYPE

Email varchar [email protected] Accepted Valid

Email varchar Admin.com Rejected Invalid
Email Varchar [email protected] Rejected Valid
(email already exists)

Password Varchar Password01 Accepted Valid

Password Varchar #password Rejected Invalid
(Confirmation Error)

Figure 22 Database testing Table

24
UNIT TESTING

Unit involves testing software with a small piece of source code. VQMS is built on top of the
Laravel php framework, thus has access to a custom TDD library. When performing tests,
some assertions would be made, and the testing function would then assert if true or false.
Source code for unit testing were created by the developer as a part of software development.
The following unit tests were performed to ascertain functionality.

USABILITY TESTING

The table below summarized tests that were performed to ascertain the usability and
experience of users while interacting with the system.

Element Output

Flow from start to finish Yes

Feedback from Actions performed Instant Feedback

Tokens Received Received

Seamless Navigation Yes

Performance Optimal

Failure or crashes None

Runtime error messages None

Slow or delayed loading Acceptable

INTEGRATION TESTING

The purpose of this testing was to check whether the various modules of the system are well
integrated and working harmoniously. All the form modules were well connected with the
database and processing of data was successfully done. The reports generated outputs
successfully as expected from the database and in the correct formats.

25
 Chapter Five
Handover

Project handover is the point in the project management lifecycle when the completed tasks
are being transferred to the deliverable owner. It marks the completion of delivery and the
start of the closure stage of your project.
Basically, the project goes from the Project Manager to the Operational Manager (sometimes
referred to as an Integration Manager). Hence the description of project handover as
transition from design to use.

Therefore, the Online Hospital Queue management system was completed and the project
will be handed over to the operational manager on the 4th of November 2022. The project will
be handed over in the following steps:
Step 1: Conduct a handover meeting to discuss any necessary details and updates after the
first stage is completed. This is to define what is actually handed over.
Step 2: Have knowledge-sharing sessions. Knowledge shouldn’t be transferred during
lunch breaks, hence there’s need for pre-planned meetings to answer questions and provide
clarifications as needed.
Step 3: Transfer the ownership. Provide access to documentation and all information
needed, including accounts, credentials, requirements, as well as third-party services and
tools.
Step 4: Run a quality check before you say, “We’re done.”
Step 5: Project handover sign-off. Congratulations! It’s time for handshakes and signatures!

26