MINISTRY OF EDUCATION AND SCIENCE OF UKRAINE

CHERKASY THE BOHDAN KHMELNYTSKY NATIONAL

UNIVERSITY
Faculty of Computer Science, Intelligent Systems and Control Department
of Automated Systems Software
Major - Computer Science
(Software Engineering)

Head of the department

Vitalii Veretelnyk
(name and surname)

____________________
(signature)

«___» __________2021

DEGREE: BACHELOR
HEALTHCARE CENTER MANAGEMENT SYSTEM

Cherkasy-2021

1
 TABLE CONTENTS

Content…………............................................................................................2
INTRODUCTION..........................................................................................4
1REVIEW AND COMPARATIVE ANALYSIS…………….………….....5
1.1 OpenClinic GA ..........................................................................................5
1.2 HospitalRun offline EHS..................................................................7
1.3 Bahmni ……………………………………………………………8
1.4 Summary Of The Analysis ..............................................................9
1.5 Outline of the development stages...................................................9
1.5.1 The Main App’s Functions ..........................................................10
Conclusion of the first section..………………………………………….…10
2 2. ANALYSIS OF THE HEALTHCARE MANAGEMENT SYSTEM
……………………………………...………………………………………11
2.1 The Use Case UML Diagram........................................................11
2.2 Breaking down the system requirement for each actor……….….14
2.3 The Activity Diagram………………………………….………..16
2.4 The State Diagram…….……………………………....…………21
2.5 The Architectural Design…………………………………….….22
2.5.1 The Package Diagram………………………….……….22
2.6 The Communication Diagram…………………………………..23

2.7 The Sequence Diagram………………………………………....23

2.8 The Architecture Of Our HealthCare System…………………..26
2.8.1 The component Diagram……………………………...27
2.9 The Class Diagram…………………………………………..…28
2.9.1 The Deployment Diagram…………………………………....29
2.10 The database or SQL…………………………………………..31
2.11 Entity Framework……………………………………………...31
Conclusion of the second section ………………………………………....32
3 DEVELOPMENT AND TESTING…………………………………...33

2
 3.1 The Login and Registration Page…....……………………….....33
3.2 The Patient’s Home Page....……………………………………..34
3.3 The Patient’s Appointment Page;………………………………..34
3.4 The Patient billing Page………………………………………....35
3.5 The List Of the Departments…………………………………....36
3. 6 The List Of the Doctors and Online appointment……………...37
3. 6 The List Of the Doctors and Online appointment……………...37
3.8 The Doctor’s Home Page……………………………………….39
3.9 The Admin graphical Interface………………………………....40
3.10 Admin Adding Users…………………………………………..41
3.10.1 Showing the selected user and their Detail………………….42
3.11 Testing results’ table………………………………………….43
Conclusion of the third section……..……………………………………..45
CONCLUSION……....…………...……………………………………....45
LIST OF SOURCES USED…………..….………………………………47
APPENDIX A - Conceptual data model of Healthcare………………..48

3
 INTRODUCTION

The main objective is to build an application that can effectively help

manage health care centres, clinics or hospitals by reducing medical errors, time
consumption, cost and improving the quality of medical services.
Relevance Of The Theme - Many health care providers around the world and
especially in less developed countries still use traditional means of managing
their patients' data. Patients' information is saved in registries which are nothing
but books that are kept in cupboards. Any time an old client comes back to the
hospital, nurses or doctors have to go through the cupboard and find the book
in which this particular patient’s previous medical prescription was saved to
understand more about their health condition. This method of saving and
retrieving patients’ data is tiring and time-consuming. Consequently, if the
number of patients increases, medical services would be delivered poorly and
some patients who need urgent treatment might not be attended to immediately.
Having a system that stores every patient’s data in a database instead of a
registry will greatly save the hospital personnel a huge amount of time and
increase productivity. A patent's data that could have taken more than 20
minutes to get, would now with the help of this computer application take less
than a minute. The purpose of this thesis is to develop a web-based application
that will revolutionize health care management on many levels. For example,
Doctors should be able to use the application to stay in touch or keep track of
their previously consulted patients. Since the data is saved online on a server,
patients should also have the opportunity to get in touch with doctors right from
the comfort of their home. Additionally, patients who already attended the
hospital once should not have to go back to the hospital if they have another
appointment; they should directly be able to check from the hospital database
the availability of a doctor and make an appointment with them. To achieve this
goal, the following task must be performed:

- Study And examine other existing Healthcare Management Systems.

Consider possible future requirements for the system.
- Design a software architecture that implements the three-tier
Architecture pattern.
- Looking into other possible ways of implementing a Healthcare
Management system.
- Build a health care management system that will enhance. healthcare
providers' productivity.
- Finally, test the finished software and write the documentation.

4
Object Of Development: healthcare system management for hospitals
and healthcare centres.
The subject of development: A Software to improve and automate a
healthcare centre’s daily tasks.

1. REVIEW AND COMPARATIVE ANALYSIS

Analysing and studying already existing and selling software will give us
a better understanding of how enterprise applications are designed, it will help
us point out some key features and possibly some features that could be
improved or added. By the end of this analysis, we will understand how
real-world applications work and try to develop our software by considering the
main design patterns and adding the missing features of the below software to
ours.

1.1 OpenClinic GA
This application is open source and therefore free to use. Not only
is it extensible but it also offers almost all the functionalities that are
needed to better operate any kind of health-related organisation.
Moreover, patients themselves can log into their profiles and either view
their past medical history or update the information they are allowed to
update about themselves (Fig 1.1).

5
 Fig 1.1 - Open Clinic

Open Clinic’s advantages:

- wide range of features
- Ability to use fingerprint
- A cross-platform application which means it can be used on Windows
Linux and Mac
- Ability to create client’s reports
- Ability to add drug prescriptions given to patients
- Patient cards can be added right to the application so that they can pay for
their treatment.

Open Clinic’s Disadvantages:

- Every Member of the hospital personnel can access any client’s sensitive
diagnostic information.
- The application is web-based so the hospital needs to have stable
access to the internet.

6
1.2 HospitalRun offline EHS

This application might not have as many features as the above one
but it is suitable for places where having access to the internet is a
challenge. It has an easy-to-use interface and offers most of the
functionality that a small-scaled hospital will need. The demo application
can be tried on their official website after registration.

Fig 1. 2 - HospitalRun offline

HospitalRun Offline’s advantages:

- The application is web-based so the hospital needs to have stable access

to the internet
- Can be used offline Ideal for both developed and developing countries
- User friendly and self-explanatory and do not require special training to
use the application.
- Ability to deploy the software either on a desktop computer or online
using cloud provider services.
- Integrated client control and billing system
- An option to manage doctors’ schedules and appointments

7
HospitalRun Offline’s disadvantages:

- Only support Linux as of this writing.

- Currently in a beta version
- Paid after free trial

1.3 Bahmni
The software is a combination of three open-source applications:
OpenEMR which focuses on Medical records and management of patients,
OpenERP to handle financial accounting and billing and finally OpenELIS
which helps with laboratory management. This software primarily targets
organisations that operate on a low resource.

Fig 1. 3 - Bahmni

The Bahmni’s advantages:

- Accessible on mobile phone, tablet, and computers

8
 - Possibility to send medical prescriptions to patients or pharmacies
through the software easy and simple to use; no need for prior training
- A wide range of functionality
- Also has an integrated client control and billing system
- An option to manage Doctors schedules and appointments

The Bahmni’s disadvantages:

- Only cloud-based so no version for desktops and mobile phones
- The web-based and so users must be conscious about security issues.

1.4 Summary Of The Analysis

After trying the demo versions of the three software above, we can
conclude that they all have a user-friendly interface and greatly serve the
purpose they were designed for. Since this software are meant for clinics or any
kind of health related organisation, there should be an option to toggle the
interface colour from the initial colour to an inverted or dark one as this will
reduce eye strain and help users with poor vision to effectively use the
application.

1.5 Outline of the development stages

Healthcare management is an ever-relevant topic especially in a

world that is stuck by new types of diseases or viruses. Today, many hospitals
are overcrowded due to the coronavirus pandemic and many countries imposed
lockdown periods to avoid spreading the virus.
This situation is putting a strain on the healthcare system as managing an
increasing number of patients becomes difficult and there is no better option
than to use software that will help speed up the workflow. For more efficiency,
the software must offer the ability to toggle its themes from brightness to
inverted or darkness to reduce eye strain and allow users with eyes issues to use
it for a longer time. This is a feature that the three software we studied lack.

9
1.5.1 The Main App’s Functions

From the Study we carried out earlier, we now have an idea of the
functionality our application must-have, so as to be complete and efficient. The
application should have a good and user-friendly interface A patient registration
form. It should also be able to manage patients’ orders, maintain an accurate
record of the bills and financial transactions. In order to achieve this we will
have to:

1. Get familiar with the basic needs of the healthcare centre

2. Get familiar with the main hospitals or healthcare departments.
3. Create an extensible database for the healthcare centre
4. Create Doctors, Departments and Patients’ table
5. Get familiar with how electronic prescription works and implement it.
6. Design the User Interface for users to select their preferable theme colour.

Before the actual development of the software, we will consider taking

the following approach:
1. Analyse the requirements of the project to identify the main
properties of our application
2. Set up the software skeleton by determining the structure of the
application and its database.
3. Draw a chart or a diagram that shows and explains the mains use
cases of every step taken.
4. Start developing every section of healthcare management.
system
5. Make sure the software complies with the requirements and
perform a number of tests to check it is free of eros.

Conclusion of the first section

In summary, during this section we were able to research and
describe the basic needs of a healthcare center, we also analysed three of
the best healthcare management systems on the market as of this writing.
We compared their main characteristics, their interfaces and
functionalities and even though they were developed by groups of
experts, we were still able to point out a number of features that, if added,
could make the software perfect. We noticed that most of the best existing
applications currently on the market do not provide the ability to save
users’ data when offline. Additionally, they don’t allow the user to select
their preferred interface theme based on the visual acuity. These missing

10
features are what we will take advantage of while developing our
application.

2. ANALYSIS OF THE HEALTHCARE MANAGEMENT SYSTEM

2.1 The Use Case UML Diagram
A better way to build the application is to break it down into
small sections. At this stage of development we are going to describe the
actors (the main users of the application). An Actor of this application
can be divided into three: The patients, the doctors and the
Administrators. Each of these actors can log in the same way but are
registered differently. For example, Doctors and the hospital personnel
can’t register themselves; they are registered by an administrator who
gives them their login details which they can change later. On the other
hand , patients can register themselves or get registered by a member of
the hospital.
During the login process, users only have to enter the
username and password.
The Patient can log into their account and see their personal details such
as their names, age, profile picture and more. Patients can book
appointments, pay for their consultation fees, check their treatment
histories, reset their login details and send feedback after they have been
treated. The patient can also receive a response from doctors they sent a
request to in a form of notification and also receive a payment receipt
from the system.
The UML diagram below represents the main patients' behaviours (Fig 2.1).

11
 Fig 2.1 - Patient’s UML Diagram
Compared to Doctors, Patients have a lot more functions. Doctors can
only log into the system, check their current appointments, accept or
reject patients’ appointment requests based on their schedule. In case an
appointment is accepted, a Doctor can do an online consultation and send
the consultation bills to patients. Doctors can also reset or change the
login password and see their old client treatment history. After a patient
has paid for their consultation, Doctors can receive a notification from the

12
server that the payment was made. The Doctor's interaction with the
system is represented below in the following image (Fig 2. 2 )

Fig 2. 2 - Doctor’s UML Diagram

The third and last actor of our application is the

administrator. Any user with the administrator’s privileges has full control
over the application; they can add new patients, and staff members such
as doctors, nurses, laboratory personnel, cleaners and anybody working or
having a role in the hospital. In the same way, the administrator can
manage the member's account, in other words the administrator can delete
or edit all members' data. Administrators can also lock some users and
unlock them and finally reset their own passwords. They can see all the
statistics and the number of registered patients and the total income
generated over a given period of time. The diagram below is the main
illustration of the administrator’s interaction with the application. (Fig
2.3)

13
 Fig 2.3 Doctor’s UML Diagram

2.2 Breaking down the system requirement for each actor

As we have seen above, our application has three main
actors: The Patients, The Doctors and the Administrators. Our main goal
at this stage is to break down or summarise all the functions attributed to
each actor in the application.
The Patients plays the following roles in the application; they can:

14
 - Register
- Login
- Search the list of Departments
- Select a Doctor based on their Profile(qualification and experience)
- Book an appointment with their selected Doctor
- Receive Medical bills
- Pay for their Consultation or Medical fees
- Reset their Login details
- Check their treatment history
- Send feedback to the doctor who consulted them

The Doctors, who represent the second main actors in the application play
the following roles :
- Login
- Check current appointments
- Accept Appointments
- Reject Appointments
- Send consultation Bills
- Reset Login Credentials
- Check Old patients treatment history
- Receive payment receipt

Finally, as of now, the last actor of our application is the administrator whose
role is to:
- Login
- Add staff members
- Edit staff members’ details
- Delete staff members
- Reset their login Credentials
- See all department information
- Lock and unlock users

Now that we have successfully analysed each actor and their

specific roles, let's take a look at the actual interaction between them and the
system. To achieve this we will make use of an Activity Diagram.

15
2.3 The Activity Diagram
The first activity we are going to start with is user
registration as it represents the door to the system. Without registering it
is impossible to have access to the healthcare system. By default, any user
is registered as a patient since the hospital members are being registered
by the administrator.
Once on the application home page, users will have an
option to either log in or register. To register, new patients have to fill in
their personal details such as full name, email address, phone number,
address, date of birth and type their password and reconfirm it. When all
inputs are filled, the user can click on the register button and their
registration information will be saved into the hospital database.
However, a number of mistakes from the users that can prevent them from
registering successfully as the system will automatically ask them to
correct those.
Users can’t be trusted and can type numbers into inputs that
are meant for letter vise-versa. If a user types in the name input a name
that is less than three letters a warning message will automatically appear
telling them that the minimum number of characters allowed should be
three. In the same way, if they type in a wrong email address (an email
that does not have the sign “@” in it and does not end with “.com”) a red
line will appear around the input with a message telling them how to
correct the error. Users can also make a mistake while re-typing the
passwords. On the registration form there is one input for the password,
and another one to confirm the same password and it is likely that users
write the wrong password. If that is the case again, an error message will
display to help them correct the mistake.
To sum up, while registering, users must fill the Surname
name input with at least a word that has three or more letters. Then fill in
with their date of birth and to help them a date picker API will be
integrated to avoid them making mistakes. The next step will be to fill in
the input for the email correctly as mentioned earlier. Since the email
address will be used to log the user in later , the system will check if the
email already exists and display an error message if so. Then, the user
must provide their phone number in numbers and finally type and
confirm their password. When they click on the register, their details will
be saved in the database and they will be redirected to their profile which
can be updated later on with their profile picture more other information
they will be allowed to add. The images below illustrate the activity
diagram for the registration form. (Fig 2.4)

16
 Fig 2.4 - User’s Registration Activity Diagram

The Login activity is quite similar to the registration

activity. While logging in, the user will have to fill the input with their
username and password. Once they click on the Login button, the system
will check if the provided username exists in the database and if it does
not exist, an immediate response will be sent from the server with an
‘unauthorised’ error message. On the other hand, if the provided
username exists in the database, the system will move on to compare the

17
provided password to the one in the database. If the provided password
does not match the one in the database, the system will respond back
with an ‘unauthorised’ error message. By not telling the user the exact
nature of the error, we can prevent potential hackers from knowing where
the problem comes from to deter any further hack attempt. Finally , if the
username and password provided are correct, the user will be redirected to
their homepage or profile page . The Image below (Fig 2.5) shows the
user’s login Activity.

Fig 2.5 - User’s Login Activity Diagram

18
 Another important activity in the program is the searching
activity. Here we decided to combine the searching and editing activities
while drawing as these two activities can happen one after the other.
Searching should be possible for patients. However, they should not have
the ability to edit unless it is their own details. Doctors should also be
able to search and should but would not have the possibility to edit.
Therefore, the right to edit is reserved only to the administrator. Since the
Health Center has many departments, the search user must select the
department they would like to search and the list of members of that
department will be populated from the server. They can either scroll
through the populated list or simply start typing the user’s name they are
looking for in the search bar. As they type, all names in the database
which contains the typed letters will be displayed so that they can choose
the name they are looking for. If there is no match, the server will display
a notification message that no user was found. On the other hand, the
matching name will be displayed.
The next set of actions to take will be to delete or edit the
user’s details and since the delete action is pretty elementary, we will not
include it in the diagram. To edit, the user will click on the edit button
and the editing form will be displayed. After editing , the user will just
have to click on the save button and the new details will be saved in the
database. The server will then return the edited data to the user and that
will mark the end of the editing activity. The search and editing activities
are represented on the below diagram(Fig 2.6 Search and Edit Diagram)

19
Fig 2.6 - Search and Edit Activity Diagram

20
 In order to better understand the behaviours of our patient object, we
need to use a state machine diagram and the image below (image 2.7)
shows the state the ‘appointment’ object takes over its life cycle.

2.4 The State Diagram

Fig 2.7 - State Diagram For The Patient Appointment Request

As we can see, an appointment request is first made (by the

patient) which changes the state of the ‘appointment’ object to ‘pending’.
After the request has been made, a notification will be sent to the selected
Doctor who in turn will either accept the request or reject it. In this case,
the request is accepted so the ‘appointment’ class takes the ‘booked’ state.
In addition to this, whenever the patient wants to request for another
appointment, the ‘booked’ state of the class will obviously change to
pending. If there is already a pending appointment and the patient
attempts to make a new request,
A guard condition will prevent that unless there is no pending request. In
summary, for the patient to book an appointment, a request will be

21
initiated and the ‘appointment’ class will take a pending state. Once the
confirmation response is returned from the doctor, the ‘appointment’
class’ status will change to booked and only new appointments will be
initiated if there is no pending appointment.

2.5 The Architectural Design

An architectural design of the system can help us have a
picture or an idea of what the finished project will look like. So in order to
design the structure of the system, we will make you a package diagram.

2.5.1 The Package Diagram

Fig 2.8 - The health care package diagram

The above Package diagram shows the main packages in the

healthcare system and their interactions between one another. This
Diagram contains the User’s functions or attributes package, the Patient’s
functions package, the doctor’s behaviour package and the administrator’s
functions’ package. As we can see, all the three actors (patient, doctor
and administrators) can access, import or inherit from all members within
the user’s package. This is possible because Admin, Doctor and Patient
are extended types of the User. The Doctor on the other hand only has

22
access to the public members of the Billing package because a Doctor
may send bills to clients. Therefore, The Doctor package could use the
Billing Package public members. In the same way, The Billing Package
could use the User or specifically the Patient Package since only patients
will be issued bills in the system.

2.6 The Communication Diagram

Having a picture of how our objects or classes interact with
one another is very important and will help us build the software
efficiently. The main interaction or communication happens between
patients and doctors. In the first phase, patients will initiate the action by
selecting the doctor through the appointment user interface and then send
a request for an appointment. The appointment class will then record the
request and send a notification to the selected doctor. On reception of the
notification, the doctor can then reply by sending a confirmation message
which will then be displayed on the patient-user interface through the
‘appointment’ class. The next action a patient can take after booking an
appointment is to pay for the insulation fees. To do this we will have to
add a billing class that will take care of all transactions happening in the
system. The billing class will take care of the translation made by the
patient and notify the doctor that a transaction was made. The doctor can
then send an acknowledgement of reception to the patient which will be
displayed as a notification on the user interface. The image below shows
the interactions between our system object, namely, the patient and the
doctor.

23
 Fig 2.9 - The health care communication diagram

2.7 The Sequence Diagram

Now that we know how our objects interact with one
another, let’s look at how the interaction is actually done; since we want
to emphasize on the order of the interaction between our classes, the best
way to illustrate this interaction is the use of a sequence diagram.

24
 Fig 2.10 - Patient-Doctor Sequence Diagram

The above sequence shows the order of actions in a given

time. Each action is made one after the other, the first action (1) initiated
by the patient happens through the patient UI (user interface). The second

25
action in our sequence (2) is fired by the appointment class which at this
stage will first record the patient’s message and notify the doctor (3).
After this will have a response from the doctor’s class which response to
the appointment class by sending a confirmation. Stage (3) and (4)
represent the period of time during which the doctor’s first activity
happened in the system. On reception of the confirmation, the
appointment class will then send a notification to the patent and therefore
close its line of activities. The period starting from (2) to (5) is the period
of time that was taken for the appointment class to complete its activity.
Next, the patient will then proceed with the payment (6) and
consequently create an action from the billing class to notify the doctor.
The second sequence of activity for the doctor starts at that moment (7).
This time the doctor class will respond to the billing class with a
confirmation of receipt and thus finish its second sequence of activity (8).
The billing sequence of activities end at (9) when a notification message
is sent to the patient, which is then displayed on the patient UI (user
interface)

26
2.8 The Architecture Of HealthCare System

2.8.1 The Component Diagram

Fig 2.11 - The Healthcare System Component Diagram

As we can see on the component diagram, our system uses

an MVC model architecture so all the view components can get data from
the modules’ components and the database through the controller. The

27
MVC (model-view-controller) architecture allows us to separate our
backend models (database classes) from our frontend models (view
models) and use a controller as a middleware to allow communication
between them.

2.9 The Class Diagram

Our system as of now contains an Application User class,
an Admin class, a Billing class, a Health centre class, a Department class,
a Patient class, a Doctor class and a Staff class. All classes Patient,
Doctor, Staff and Admin inherit from the superclass Application User and
the Healthcare class is composed of the Department class and the Billing
class uses the Application User class. The Department class is composed
of the Staff class. These classes use dependency injection to interact with
one another and with the implementation interfaces in our system, we
create loosely coupled classes which means that our application can be
extended in the future without having to break or change the content of
our classes. The image below (image 2. 12) shows the different classes in
our application that were used to create the database.

28
 Fig 2.12 - The Healthcare System Class Diagram

2.9.1 The Deployment Diagram

The deployment diagram is the last diagram that we will
examine before getting to the next stage of our system. As the image
shows our deployment diagram is made of two parts: The packages and
the Server.
The module system is made of the patient, admin, doctor billing and user
and it connects to the server in this case SQL server which in turn will
connect to the web server and display the data to the user via the user
client (a web browser)

29
Fig 2.12 - The Healthcare System Class Diagram

30
2.10 The database or SQL Server
For this application, we are making use of SQL Server as our database
and a better or more productive way to design the application will be to
use a package such as Entity Framework.

2.11 Entity Framework

Entity Framework is a tool or precisely an Object Relational
Mapping tool (ORM) that allows us to write SQL queries
programmatically. Since we are using Visual Studio 2019 to develop our
application, every SQL query will be auto-generated based on our classes
if we use Entity Framework. In this application, we will use version 6 of
Entity Framework to help generate the SQL queries fast. The image
below taken from ‘tutorialspoint’ illustrates better how Entity Framework
simplifies query writing for us. However, for maintainability purposes, if
in the future we have to extend our application and for any reason, we
would like to change the Object-relational mapping technology used here
we may end up with many broken parts in our application. To solve this
impending issue, we have implemented the ‘Open Closed principle’
through the use of interfaces.

31
[Figure 2.13 image downloaded from Entity Framework - Architecture -
Tutorialspoint]

Conclusion of the second section

To sum up, during the second section of this project, we
have drawn the main important behavioural and structural diagrams for
our system which has helped us identify and create the main components
and classes needed to build the backend of our system. Now that we have
all the classes and have structured them, the next step to take will be to
design the frontend of the system and later perform a test to check if all
components work properly.

3 DEVELOPMENT AND TESTING

32
 Since our healthcare system has three main actors, each
actor has a model and consequently a View that represents the frontend or
graphical aspect of the system. No homepage is shared by patients,
doctors or administrators. The front end of every actor is based on the
model classes and therefore unique. However, a user must log in first
before accessing their homepage so the login page remains the same for
the three actors of the application.

3.1 The Login and Registration Page

This page contains both the login and registration forms. So the user can
either log in or register if they are not registered already.

Description:

To open an account users have to enter their login information.

Response

Users must enter a valid user id and password to open the user page. If the login
details are valid, then the user will be redirected to their account page. A new
user to the HealthCare system must register in order to create an account.

Basic data flow

- Here first the user enters their login id and password.

- After entering the login information the system checks whether the
entered login id and password are valid or not.
- If valid then the user account is redirected to their account. If not valid
an error message is displayed.
- A user with no account must register to create a new account

33
3.2 The Patient’s Home Page

3.3 The Patient’s Appointment Page

34
3.4 The Patient billing Page
Description:
On this page, the patient can see the consultancy fee, laboratory charges
and any other related fee.

Response :
After accepting the patient’s appointment request, the doctor will send them an
electronic invoice or a quote for them to pay for the consultation fee.

Basic Data flow

- The doctor sends the billing info to the patient who gets notified

Functional Requirements

- Consultancy fee
- Laboratory fee

35
3.5 The List Of the Departments

The page below is part of the patient’s graphical interface

and displays the list of departments in the healthcare centre. On this page,
the patient can select the department they are interested in and see the list
of its doctors.

36
3. 6 The List Of the Doctors and Online appointment
Once a department is selected, all the doctors in it will be
displayed to the patient who can continue by selecting a doctor of his
choice. When the patient selects the doctor, they can see their
qualification, level of experience and age and book an appointment with
them.

Response

Now that the patient has booked an appointment, a notification will be

sent to the selected doctor who will, in turn, confirm the appointment.
Basic Flow:

- The Patient first logs into the system

- The patient Checks the List of departments
- The Patients Checks the number of doctors and their availability
- The patient sends an appointment request
- The patient received a confirmation from the doctor

37
 Functional Requirement:

- The patient can take an appointment online or through emails or phone

calls.
- The patient can view older appointment details and their records.

3.7 The Doctor’s Profile Page

38
3.8 The Doctor’s Home Page

Description:

Doctors can check appointments taken by patients. Doctors can view Patients
Test reports, older prescriptions’ details. Doctors can also check their billing and
monthly salary details.

Responses:

A doctor logs into their account, sees their profile and any update on their salary
or department. They can also see their pending and current appointments.

Basic data flow

- Doctors can log into the system.

- Doctors can check old records and appointment details.
- Doctors can send prescriptions and test reports.
- Doctors can view their salary and billing details.
- Doctors can see pending appointments and confirm them.

39
Functional requirements

- Doctors can view patient appointments, old records, prescriptions,

payment details. And also can view their monthly salary and any update
related to their departments.

3.9 The Admin graphical Interface

Description

The Admin is a super-user. He/she is able to control the whole system. The
Admin can add, delete, update and modify the system.

40
3.10 Admin Adding Users

41
Description

With the search functionality, the user can find the detail of either a patient of a
staff member in a second which allows them to save more time and be effective

3.10.1 Showing the selected user and their Detail

3.11 Testing results’ table

An important step to take after building the backend and frontend
is to test the system and make sure there are less bugs and everything works as
expected. After testing the system, we entered the results in the following table:

42
Function
1 2
Registration or Login or in the
system
Ability to book an appointment with
doctors
directly via the platform
Ability to search through for the list of
doctors
Ability to pay the bills
Ability to send feedback after
consultation
View treatment history
Table 3.1 - Test results of the patient’s activities
Function
1 2
Registration or Login into the
system
Ability to accept appointment
request
directly via the platform
Ability to search through for the list of
patient
Ability to create and send consultation
bills
Desired action Response received
3
Logging in to an account or
Click "Login" or “Register”
creating a new account
Click Send the appointment request
"Book" at the top of any page to the doctor
Click "Search" at the top of the
The request is sent and the
page
response displays on the
page.
Click “Pay bills” Redirection to the visa or
MasterCard form
Click the “Feedback” tab and Save the feedback into the
write feedback about a doctor database and notify the doctor
The treatment history page
Click the “treatment history “ displays
tab
Desired action Response received
3
Logging in to an account or
Click "Login" or “Register”
creating a new account
Click Send notification to the
"Notification" at the top of any patient that their request was
page and accept a request accepted
Click "Search" at the top of the
The request is sent and the
page
response displays on the
page.
Click “Send bills” Send the issued bill to the
patient as a notification
43
 Click the “Notification” tab Display feedback from patients
Can view feedback from patients
and select the feedback section

The treatment history page

View treatment history Click the “treatment history “ displays
tab
Table 3.2 - Test results of the doctor’s activities

Function Desired action Response received

1 2 3
Logging in to an account or
Login into the system Click "Login" or “Register”
creating a new account

Ability to add staff members
Ability to add edit users’ details
Click Save added data into the
"Add Staff" at the top of the database
page
Click “Edit” in the header of Save edited in the database
the page and update details

Ability to add delete users’ details Click “delete” in the header of Delete user’s data in the
the page and update the details database

Select the "Patient" radio button

Ability to search through for the list of The request is sent and the
at the top of the
patient response displays on the
page
page.
Select the "Doctor" radio button
Ability to search through for the list of The request is sent and the
at the top of the
doctors response displays on the
page
page.
Click “Send bills” Send the issued bill to the
Ability to create and send consultation
patient as a notification
bills
Click the “Notification” tab Display feedback from patients
Can view feedback from patients
and select the feedback section

The treatment history page

View treatment history Click the “treatment history “ displays
tab
Table 3.3 - Test results of the doctor’s activities

44
Conclusion of the third section

While working on the third section of our thesis, we made use of the
JavaScript language to manipulate the DOM. The whole project was written in
the C# language and we were able to build our Healthcare system in the Dotnet
framework.
The client-side of our Healthcare system was designed using HTML 5,
CSS and Bootstrap 4. For the backend, we used C # and SQL server. Visual
Studio was used as our IDE because it is natively the best development
environment for .Net projects.
During the development process of the system, we designed the main
diagrams to help us organise and point out the part to focus on. We then created
all the necessary models for the system and made sure that interaction between
all the system’s components was effective and fluid. A user interface was then
designed for all the actors of the system and the system was finally tested to
make sure it works as expected and complies with the requirements.

CONCLUSION

In conclusion, the goal was achieved. We were able to develop a

healthcare system that fulfils the given requirements. We first started by
analysing similar existing applications and pointed out some missing important
features. We also presented the advantages and disadvantages of those
applications and started building the healthcare system based on the prior
analysis we made.
We then analysed the behaviour of the main actors in the healthcare system and
then focused on drawing the main diagrams such as the activity diagram and the
sequence diagram which highlighted the main behaviour or processes in the
system.
The next step was to build the architecture of the healthcare system using
the component diagram which is made of the main components and a database
to save the user’s data since the system is meant to handle very large data.
The selection of the technology or development language became then our next
focus. And our choice was influenced by the advantages offered by the
technology used to develop the healthcare system. This is the reason why C#,
The .NET framework and SQL server were used to develop this system.
A user interface was also designed for each main actor (Admin, Doctor
and Patient) and finally a number of tests were performed to make sure the
system works as expected. The healthcare system works properly; All patients,

45
doctors and Admins can so far effectively interact with it as long as they
exercise their attributed functions.
However, the healthcare system is open for extension and can be greatly
improved. More analytics tools could be added to keep track of the healthcare
centre’s data; a section for pharmacy management could also be added and a lot
more. In other words, the application can easily be upgraded according to the
needs of the healthcare system.

46
LIST OF SOURCES USED
1. Entity Framework 6: Get started with Entity Framework 6 - EF6 |
Microsoft Docs
2. Entity Framework: Entity Framework - Architecture -
Tutorialspoint
3. Sql Server: SQL Database – Managed Cloud Database Service |
Microsoft Azure
4. Sql server management Studio: SQL Server Management Studio
(SSMS) - SQL Server Management Studio (SSMS) | Microsoft Docs
5. Bootstrap: Introduction · Bootstrap v5.0 (getbootstrap.com)
6. JavasCript: JavaScript | MDN (mozilla.org)
7. The Three-tier Architecture: Three-tier architectures - IBM
Documentation
8. Html tutorials: HTML Tutorial (w3schools.com)
9. Html more link: HTML Tutorial - Tutorialspoint
10. Css: CSS Tutorial (w3schools.com)
11. Code First Migration: Entity Framework - Code First Migration -
Tutorialspoint
12. Getting started with font awesome: Get Started with Font Awesome
13. Font awesome CDN: FONT-AWESOME CDN links - CDNPKG
14. Visual Studio 2019: Visual Studio IDE, Code Editor, Azure
DevOps, & App Center - Visual Studio (microsoft.com)
15. Types of UML Diagrams: UML Diagram Types | Learn About All
14 Types of UML Diagrams (creately.com)
16. The Database Diagram: MySQL:: MySQL Workbench
17. Migrating SQL database to MySql: (1080) How to Convert MS
SQL Database to MySQL Database (Step by Step) - YouTube
18. Jquery: jQuery API Documentation

47
APPENDIX A - Conceptual database model of the Healthcare Center

The program code is available publicly on my github page:

SalomonFrux/Salomon-sHealthare-Management (github.com)

48