Tamas Ioana Florina Licenta Fara Semnaturi (2) [605364]
FACULTY OF AUTOMATION AND COMPUTER SCIENCE
COMPUTER SCIENCE DEPARTMENT
HOSPITAL MANAGEMENT SYSTEM
LICENSE THESIS
Graduate : Ioana Florina T ĂMAȘ
Supervisor : Assoc . Prof. Eng. , PhD. Delia MITREA
2020
FACULTY OF AUTOMATION AND COMPUTER SCIENCE
COMPUTER SCIENCE DEPARTMENT
i
Table of Contents
Chapter 1. Introduction ………………………….. ………………………….. …………. 4
1.1. Project context ………………………….. ………………………….. ………………………….. … 4
1.2. Project content ………………………….. ………………………….. ………………………….. … 4
1.3. Project structure on chapters ………………………….. ………………………….. ………….. 5
Chapter 2. Project Objectives ………………………….. ………………………….. … 6
2.1. Main objective ………………………….. ………………………….. ………………………….. … 6
2.2. Secondary Objectives ………………………….. ………………………….. …………………… 6
2.3. Problem statement ………………………….. ………………………….. ……………………….. 7
2.4. Product position statement ………………………….. ………………………….. …………… 7
Chapter 3. Bibliographic Research ………………………….. ……………………… 8
3.1. JSON Web Tokens ………………………….. ………………………….. ………………………. 8
3.1.1. What ar e JWT ………………………….. ………………………….. ……………………….. 8
3.1.2. JWT Anatomy ………………………….. ………………………….. ………………………. 9
3.1.3. JWT Benefits and authentication flow ………………………….. ……………………. 9
3.2. Similar applications ………………………….. ………………………….. ……………………. 10
3.2.1. SoftClinic ………………………….. ………………………….. ………………………….. . 10
3.2.2. mClinic ………………………….. ………………………….. ………………………….. ….. 10
Chapter 4. Analysis and Theoretical Foundation ………………………….. …11
4.1. Development ………………………….. ………………………….. ………………………….. … 11
4.2. Conceptual architecture ………………………….. ………………………….. ………………. 12
4.2.1. Client -Server architecture ………………………….. ………………………….. ……… 12
4.2.2. Layered architecture ………………………….. ………………………….. ……………… 13
4.3. Technologies used ………………………….. ………………………….. ……………………… 15
4.3.1. Spring ………………………….. ………………………….. ………………………….. ……. 15
4.3.2. MySQL ………………………….. ………………………….. ………………………….. ….. 15
4.3.3. Node.js ………………………….. ………………………….. ………………………….. ….. 16
4.3.4. Angular ………………………….. ………………………….. ………………………….. ….. 17
4.3.5. Selenium ………………………….. ………………………….. ………………………….. … 19
4.4. Functional Requirements ………………………….. ………………………….. …………….. 20
4.4.1. FEAT HMS01: Register and login ………………………….. ………………………. 20
4.4.2. FEAT HMS03: Appointment making ………………………….. …………………… 20
4.4.3. FEAT HMS02: Patient examination management ………………………….. ….. 20
ii
4.4.4. FEAT HMS03: Patient admission management ………………………….. ……… 20
4.4.5. FEA T HMS04: Blood test report ………………………….. …………………………. 21
4.4.6. FEAT HMS05: LiveChat ………………………….. ………………………….. ………. 21
4.5. Non-functional requirements ………………………….. ………………………….. ………… 21
4.5.1. Usability ………………………….. ………………………….. ………………………….. … 21
4.5.2. Security ………………………….. ………………………….. ………………………….. …. 21
4.5.3. Availability ………………………….. ………………………….. …………………………. 21
4.5.4. Portabi lity ………………………….. ………………………….. ………………………….. . 21
4.6. Stakeholder and User Description ………………………….. ………………………….. …. 22
4.6.1. Stakeholder Summary ………………………….. ………………………….. …………… 22
4.6.2. User Summary ………………………….. ………………………….. …………………….. 22
Chapter 5. Det ailed Design and Implementation ………………………….. ….23
5.1. Application use cases ………………………….. ………………………….. ………………….. 23
5.1.1. Flow of events of the activity diagram ………………………….. …………………. 24
5.1.2. Use-cases ………………………….. ………………………….. ………………………….. .. 25
5.2. System architecture ………………………….. ………………………….. …………………….. 30
5.3. Admin Backend architecture ………………………….. ………………………….. ………… 31
5.4. Frontend architecture ………………………….. ………………………….. ………………….. 35
5.5. Database structure ………………………….. ………………………….. ………………………. 38
5.6. Main components and modules ………………………….. ………………………….. …….. 40
5.7. Sequence diagram ………………………….. ………………………….. ………………………. 41
5.8. Deploym ent diagram ………………………….. ………………………….. …………………… 43
Chapter 6. Testing and Validation ………………………….. ……………………… 44
6.1. API Testing with Postman ………………………….. ………………………….. …………… 44
6.2. Manual testing on the frontend ………………………….. ………………………….. ……… 46
6.3. Automated testing ………………………….. ………………………….. ………………………. 47
Chapter 7. User’s manual ………………………….. ………………………….. ……… 50
7.1. Installation steps ………………………….. ………………………….. ………………………… 50
7.1.1. Required resources ………………………….. ………………………….. ……………….. 50
7.1.2. Running the project ………………………….. ………………………….. ………………. 50
7.2. User manual ………………………….. ………………………….. ………………………….. ….. 50
7.2.1. Authentication ………………………….. ………………………….. …………………….. 50
7.2.2. Patient dashboard ………………………….. ………………………….. …………………. 52
7.2.3. Doctor dashboard ………………………….. ………………………….. …………………. 53
iii
7.2.4. Nurse dashboard ………………………….. ………………………….. ………………….. 54
Chapter 8. Conclusions ………………………….. ………………………….. …………. 55
8.1. Current functionality of the application ………………………….. ………………………. 55
8.2. Further improvements ………………………….. ………………………….. …………………. 56
Bibliography ………………………….. ………………………….. ………………………… 57
Chapter 9. Bibliogra phy ………………………….. ………………………….. ……….. 57
Appendix 1 (only if needed) ………………………….. ………………………….. ……58
Chapter 2
4
Chapter 1. Introduction
1.1. Project context
Technology has a really big role in our lives nowadays , from the simplest of apps
to the most revolutionary inventions . In almost every task we perform, we use the
internet. Ordering dinner, buying furniture, sharing moments with friends . Before this, if
you wanted to find out the latest news, you h ad to buy the local newspaper early in the
morning , but today you are just a click away from finding everything that is happening
anywhere in the world.
As the Electronic Commence is evolving, multiple studies have been developed in
the area of usability and what are the key factors of website design. A website must have
elements that a consumer can manage easily , basic functions that can be memorized
quickly and a great degree if error avoidance.
Web application development needs to include s ome really important steps in
order for the goal to be achieved. Short development life -cycle times, different business
models, small development teams working on similar tasks, business analysis and
evaluation with end -users are just some of them.
Simply put, web apps a re software products that have a client side , which is the
code that is executed or interpreted by the browsers and a server side programming which
is the code that is executed or interpreted by the web server. Each side works with some
technologies. For the client side some really popular ones are : HTML (HyperText
Markup Language), CSS(Cascading Style Sheets), Javascript, Ajax and for the server
side we have the coding languages like PHP, ASP, Ruby on Rails or Java.
1.2. Project content
A healthy life is an important aspect for everybody. Being able to quickly make
an appointment or connect to a doctor is a great blessing for people that suffer from
health problems or that have concer ns which do not necessary need a face to face
consultat ion. Clinics, hospitals or pharmacies have started to build their professional
online presence, giving many patients peace of mind and creating a too l for the most
comfortable and timely services. Using both website and mobile functional apps is
mutually b eneficial for medical organizations and patients as they allow healthcare
workers and patients to stay in touch for the sake of their health and business.
The healthcare system is one of the socio -economic activities and it requires well
made and effectiv e management tools. For this, it is necessar y to have a software that
allows adequate control of the data generated in the health institutions. Hospitals are that
main actor of the health system as they generate a large volume of information which is
dispe rsed in different departments or not available in the necessary time .
Records m aintained on paper have a high risk of being lost or destroyed, therefore
in the recent years health information systems have helped improve the quality of life of
the people w orking in all departments of a hospital. Clinical and administrative
management of hospitals and other health centers is possible through a single platfo rm
with the support of technology developed to optimize the processes that allow the
operation of organizations dedicated to treating patients in any branch of medicine.
Chapter 2
5
Although the implementation of electronic medical records is still underway ,
there is st ill an impressive amount of functionality that’s already available. Hospital
management systems allow us the ability to digitize processes which will contribute to
improving the customer service, reduce the cost of some processes, streamline the search
of medical record, bills, patients, doctors, nurses , etc., each module kept in a database.
Web applications can help medicine get better. From a technology point of view,
browser -based healthcare apps offer greater accessibility for desktop, laptop or mobile
devices users . From a clinical point of view, there are many beneficial aspects that a web
based technology supports: decisions based on up to date information, more engaged and
empowered patients and a better communication between patients and health wor kers. At
the same time this type of web development requires some attention to regulatory
requirements. HIPAA (Health Insurance Portability and Accountability Act) must be
taken into account in terms of technical, physical, network and process security.
Therefore, the proposed solution is trying to gather and implement the most
important aspects mentioned above. The main operations that will be made by the patient
are registration, login, appointment making, viewing appointments and removing
appointments. Patients will also be able to make a profile with information and chat with
a healthcare worker. Doctors will be able to view their appointments, view thei r profile,
generate reports , view each patient’s admission data info, examination report or
laboratory report. The nurse will be able to add in the database examination report s
based on the patient social security number, as well as blood test reports and admission
reports. The nurse can also register treatments when they are applied to a specific patient.
1.3. Project structure on chapters
Introduction – it describes the project context and the justification behind
developing a web application and the project content which motivates the decision of
having a website in the healthcare system.
Project objectives – presents the main goal of the project as well as the
secondary objectives that need to be reached in the process of developing the web
application.
Bibliographic research – it presents similar systems like the one proposed but
also an more in depth description of some of the technologies used like JSON Web
Tokens authentication, socket.io , Spring Boot.
Analysis and theoretical foundation – it presents the use cases, functional
requirements, non -functional requirements and the in depth description of other resources
that have been used during the development of the project.
Detailed design and implementation – it presents the conceptual architecture of
the system , APIs used, data base diagram, deployment diagram, and some sequence
diagrams of the more complex operations. It will offer an overview of how all the
components of the web application are linked together .
Testing and validation – it presents the process of testing the application and the
tools involved as well as test scenarios.
User’s manual – it presents the steps to setup the project and the necessary
resources, with screenshots included.
Conclusions – it presents the final conclusions that can be drawn from the
development of the projects , as well as future improvements that can be done.
Chapter 2
6
Chapter 2. Project Objectives
During this chapter it will be presented the main objective of the proposed project,
followed by several secondary objectives that need to be achieved.
2.1. Main objective
Face to face visits to the doctor and diagnosis are strongly recommended , but it is
also important for a patient to have the possibility to contact a healthcare worker by other
means. An online platform for both the patients and the doctor is a good solution for such
a problem and it is also a way of having data a click away. This also offer s the healthcare
workers a solution to keeping important information in a database, which is a more safe
way of storing data rather than keeping it on paper which can be lost or get damaged , but
also sharing some of the data with the patient, which can be up to date with its health
problems.
The main goal of this project is to offer a simple solution to ease the patient –
doctor relation , data management and examinations or laboratory reports , as well as
offering the nurse a platform to keep track of examina tion reports, blood test reports or
treatments for the patient. It will offer an intuitive graphica l user interface that can be
easily used by all the users , for this project there will be three types of users: doctor,
nurse and patients . In order to make the management of information easier , every patient
will have a unique identifier (in the case of this project it will be the social security
number) and username . This will allow all information related to patient s to be included
in the se rver database according to thei r username and social security number . Once the
patient will update its user profile which contains some basi c information , the doctor can
log in the system and view that patient information , as well as the nurse that can add
different data reports regarding that specific patient.
2.2. Secondary Objective s
The first secondary objective is to have an easy to use platform by both the patient
and health workers, take n into consideration their level of knowledge. Therefore, this
appli cation will be developed in order to avoid an abundance of design elements which
can give the impression of being a hard to use and complex website. Thus, the aim will
be to achieve a pleasant design where the user can access data easily and quick, having
operations that can be done in a relatively small number of steps . By accomplishing this
objective the users will a have a great experience using this application whenever needed.
Another secondary objective which is accessibility and minimal system
requirements. Web -based programs do not require installed software on the user’s
computer. They can be accessed on any device that has internet connection. As almost
everyone owns a smartphone these days, web based programs and platforms could also
be accessed through any phone . One of the main advantages of web apps is that there is a
lot of time saved, as all web -based software is delivered directly to anyone’s device
which has an internet browser. Moreover, there is no ne ed to be up to date with the
newest hardware if you are a user of a web based application. This type of software
Chapter 2
7
minimizes the requirements of the user’s system configuration, as all the processes are
handled by the service provider. To put it another way, when someone uses a web -based
software it can be sure that it is using the latest version which is always updated
automatically.
2.3. Problem statement
Keeping track of all the information about a patient on paper involves a lot of
well-organized paperwork and is quite time consuming and in case of damage, the loss
will be high. The hospital management system will provide features that will facilitate the
communication between a patient and the hospital health workers , as well as
communication between doctor and nurses.
Table 2. 1- Problem statement
2.4. Product position statement
The hospital management system project is a software developed to offer a user friendly
and c ost efficient way of collecting patient information, admissions and laboratory
reports information , as well as appointment details .
Table 2. 2- Product position statement
Chapt er 4
8
Chapter 3. Bibliographic Research
3.1. JSON Web Tokens
The definition from the official documentation [] states tha t:
JSON Web Token (JWT ) is an open standard (RFC 7 519) that defines a compact and
self contained way for securely transmitting information between parties as a JSON
object. This information can be verified and trusted because it is digitally signed. JWTs
can be signed using a secret or a public/private key pair using RSA or ECDSA
3.1.1. What are JWT
JWT are a secure way to transfer information between parties as a JSON object .
They are tokens that are used to authenticate users on applications. It enables backends to
accept requests just by validating the contents of jwts, therefore apps no longer have to
hold cookies or other session data about their users.
Authentic ation : when a clien t sends a login request , the server checks the
incoming credentials and if the credentials are valid it created a JWT and sends this token
as a response to the client. The client will use this JWT for all the requests it will make to
the server . When the s erver receives the requests, it first checks that there is a JWT in that
request and then validates it . If the token is valid, it responds to the client appropriately.
The diagram below shows the process:
Figure 3.1 – JWT Authenti cation process [2]
Chapt er 4
9
3.1.2. JWT Anatomy
The JWT has 3 sections: header, payload and signature. Each section is base64 URL –
encoded. This ensures that it can be used safely in a URL .
The header consists of two parts: the type of token, which is JWT and the hashing
algorithm being used (in the below example we have HS256 )
Figure 3.2 – JWT header [2]
The payload contains the claims . Claims are statements about an entity and additional
metadata . There are three types of claims: reserved, public and private claims. An
example of payload could be:
Figure 3.3 – JWT payload [2]
The signature part has a different way of being created. You have to take the encoded
header, encoded payload, a secret, the algorithm specified in the header and sign that. The
signature is used to verify that the sender of the JWT is who it says it is and to ensure that
the mess age wasn’t changed along the way.
An example of a signature that uses the HMAC SHA256 algorithm is shown below:
Figure 3.4 – JWT signature [2]
3.1.3. JWT Benefi ts and authentication flow
Some benefits of JWT Authentication:
-Better integration with mobile
-Reduced load on authorization server
-No need for distributed session store
Chapt er 4
10
JWT Authentication flow
1. User obtains access tokens by providing credentials to the server
2. User send access token with each requests it ma kes to access protected resour ce
3. Access token is signed and contains user identi ty and authorization claims.
3.2. Similar applications
During several last years, the emerging tech industry has brough growth,
development and new faci lities to the medical health center, and the health industry in
general. There are multiple ways how software development in the medical area can help
medical workers like doctor and nurses, but also administrators of healthcare institutions.
Depending on the purpose, these type of apps are also refer red to as: electronic health
record(EHR) solutions, hospital management softw are, patient management systems,
healthcare CRMs. The idea behind those software solutions is the same. HER
applications help to deal with everyday operations and clinical work, manage patient
records and also process financial information.
3.2.1. SoftClinic
SoftClinis is a healthcare software designed to help hospitals and clinicians with
transformative digital solutions. The app was develo ped in 2002 and has now become a
popular telehealth solution that serves more than 4.5 million patients worlwide .
SoftClinic offers physicians an easy way to manage their patients’ data while saving time
which can be spent talking with patients. Some of t he key features that it delivers: online
appointment system, mobile app acces for physicians, HIPAA compliant cloud backup,
fingerprint scan identification system, barcoded reporting system, auto notifications and
sms alers .
The electronic health record software helps physcians to digitize patients’ record
and manage their health care practice. Patients will have a portal where they can store
their health records and share with their physicians. Therefore, the SoftClinic information
system is design ed to cover hospital management without any paperwork involved.
3.2.2. mClinic
mClinic App promises to offer complete digitalization solutions for all type of
clinics, hospital or medical centers. The clinic management system has integrated simple
UI interface application and it provides various unique features that makes a user’s work
easy and fast. The most difficult and headache part of any health center is waiting for
appointment making in a long queue. mClinic app provides a system that reduces the
time of paper that old systems takes. The user can check the available time slots of the
day and book an appointment even with your phone. It also offers a prescription
management system, a payment system and reception management system with real time
status updat e that will make it easy to identify daily appointments details.
Chapt er 4
11
Chapter 4. Analysis and Theoretical Foundation
In this chapter it will be presented the conceptual architecture of the system and
information about the other technologies used in development , as well as the steps
involved in order to create a web application
Besides that, the functional and non -functional requirements will be analysed as
they are the starting point for delivering a high quality product. Unclear requirements
lead to poorly defined scope that creates a lot of obstacles along the way to developing
any application.
4.1. Development
Development phase for creating web apps can be broken down into three parts to
eliminate time consuming procedures and to fasten up the web development process.
A. Designing
In the designing phase should be taken into account the web application’s
appearance based on the functionalities that will be built . This involves ch oosing
colors, fonts, images or other themes.
B. Back end development
Back end development includes managing services on the ser ver, database
handling which involves database design, session management, creating security
for web application, API development . It contains servers where the web pages
are loca ted and the underlying logic that governs the website’s functions and
processes.
C. Front end development
Front end web development includes designing, session management,
implementing front end security and user authentic ation, front end functionalities
creation, API calls, routing to different pages , handling the responsiveness of the
web app. There are plenty of options to create the user interface with JavaScript
using frameworks. Web apps are mostly developed using MVC based
architectu re.
To create the front end, a combination of HTML(for basic structure and content) ,
CSS(for visual editing) and JavaScript(for making website s more interactive)
D. Testing
Software testing is a really important part of web applications development and
softw are development in general as every software system has bugs even after it
is fully developed. Software testing of web apps can be done from multiple
perspectives but all of them can be split into two categories: automated testing
which uses automated test ing tools and manual testin g.
Chapt er 4
12
4.2. Conceptual architecture
4.2.1. Client -Server architecture
The motivation behin d using the client -server communication is in order to keep
(most of ) the logic in a central place, to have a better control over the logic and to allow
several external clients to access the logic. The typical respons ibilities of the ser ver are to
access the data, perform most business logic and expose APIs for clients to consume ,
while the client respons ibilities are to communicate with the server, handle user
interactions and display data retrieved from the server . Client -server communication is
always used whenever someone requests something from the internet.
4.2.1.1. HTTP and RESTful Web Services
When a user browses the internet, there are a lot of things happening behind the
scenes. Modern web services are often based on the REST architecture which relies on
the HTTP protocol and returns data in the JSON format. REST is a client -server
architecture. The server stores and/or manipulates information and makes it available to
the user in an efficient manner while the client takes that information and displays it to
the user or it uses it to perform other requests for i nformation.
REST works over the Hypertext Transfer Protocol(HTTP), which is the main
protocol used for internet based applications. It is a request -reply protocol: a client must
make a request to a server and the server must give a response for that reque st. It is a
style of building web services . The way it works is the following: there are defined a set
of resource types and operations then they are mapped to paths and HTTP methods.
Resources should have a predefined data model, such that the request and response
payloads use a predefined structure. [1]
Figure 4. 1- HTTP request -reply
HTTP Requests have a well defined structure:
1. HTTP method:
• GET: it is used to request data from an identified resource
• POST: it is used to forward data to a server to create a new
resource
• PUT: it is mainly used to send data to a server to update a certain
resource
• DELETE: it is used to remove a specified resource
Chapt er 4
13
2. Request target: usually the path on the server
3. HTTP version
4. Request headers
5. Request body : which is informally called “payload”
HTTP Responses have a well defined structure:
1. HTTP version
2. Status code: 200, 201, 400, etc.
3. Status text: Ok, Bad Request, etc.
4. Response headers
5. Response body: informally called “payload”
4.2.2. Layered architecture
In a Layered architecture the layers are a collection of modules(or classes) with
common functionality. In this type of architecture, layers are stacked on top of one
another . Components form one layer are only allowed to communicate with the
components fr om the layer one level below. The goals of the layerd architecture are to
separate concers as well as possible, to allow the replacement of some parts without
affecting the whole system.
Figure 4.2 .- Component communication [5]
Chapt er 4
14
The most widespread use of multilayered architecture is the three -tier
architectur e, which consists of Presentation layer, Application layer and Data
layer.
The presentation layer ,the user interface , the top -most level of the app is
where there are handled all the incoming requests to the application and return a
response. Its main function is to translate tasks and results to something the user
can understand . The presentation layer is the layer which the users can access
directl y and it communicates with other tiers by which it puts out the results to the
browser/client.
The application layer is where all the functions that the application should
provide will be developed . It contains th e business logic that supports the app’s
core functions. Application layer returns the result of its calculations back to the
presentation layer and it relies on the data layer to save all the data for later use or
fetch previously -saved data.
The data layer handles the persisting of our data. It communicates with the
database , managing reading and writing operations and has no further
dependencies . Popular database systems for managing read/write access include
MySQL, PostgreSQL , Microsoft SQL Server and MongoDB.
The pros of using this type of architecture include the fact that the layers
are isolated (changes to one layer don’t affect the other layers), separation of
concerns (each layer takes care of one aspect of the application and this makes th
code more manageable) , it can ease down the process of testing the app as the
layers can be tested independently and it is a quick way of getting an application
running without much complexity .
The down side, on the other hand, if the goal is only to develop a sim ple
CRUD app, going through 3 layers only to create one database record might be a
bit too much. As every layer has a direct dependency on a layer before , it means
that we have a tightly coupled system.
Figure 4. 3.- 3-Tier Application Arch itecture
Chapt er 4
15
4.3. Technologies used
The methods by which computers communicate with each other through the use of
markup languages and multimedia packages is know as web technology . In the past few
years, web technology has undergone a dramatic transition, from a few marked up web
pages to the ability to do very specific work on a network without interruption.
Creating a complex web application involves technologies both server side and client
side.
4.3.1. Sprin g
Spring is one of the most popular framework for developing applications for
enterprise Java, as it is known to create high performing, easily testable and reusable
code. Spring framework target s to make development easier to us e and promotes good
programming practices by enabling a POJO -based programming model.
The technology that Spring is most popular for is Dependency Injection (DI) .
When writing complex Java applications, the java classes should be as independent as
possible of other classes to increase reusability and make testing easier, especially unit
testing which involves testing them independently. Dependency Injection helps in gluing
these classes together and at the sa me time keeping them independent.
4.3.2. MySQL
MySQL is an open -source relational database system that was first launched in
1995 [5]. A relational database stores data in tables made up of rows and columns and
sorts it based on how it relates to similar data in the set. Relational databses are written
in SQL, which stands for “structured query language”. This standard language is u sed by
MySQL to find and add new data to a relational database system . Besides the fact that is
a free -to-use, open -source database , it facilitates effectie management of databases by
connecting them to the software and it stable and reliable.
Some of the advantages of using MySQL:
• Easy to use: MySQL is easy to use, it requires to get only the basic
knowledge of SQL .
• Data Security : it is kno wn for being the most secure and reliable database
management system used in popular web applications. The data security
and support for transactional processing that accompany MySQ L can
greatly benefit a hospital management system as patient private
information needs to be securely stored in the database.
• On demand scalability: it offers unmatched scalability to fa cilitate the
management of deeply embedded apps using a smaller footprint even in
mass ive warehoyses that stack terabytes of data.
• High performance: it features a distinct storage -engine framework that
facilitates system administrators to configure the MyS QL database server
for a great performance. Whether it receives a million queries every single
day or requires to do high speed transactional processing, it is designed to
Chapt er 4
16
meet even the most demanding applications while ensuring optimum
speed , full -text in dexes and unique memory caches for enhanced
performance.
• Platform independent: it can download , install and execute on most of the
available operating systems.
• Memory efficiency : its efficiency is high because it has a very low
memory leakage problem.
4.3.3. Node .js
As Wikipedia states: ”Node.js is a packaged compilation of Google’s V8
JavaScript engine, the libuv platform abstraction layer, and a core library , which is itself
primarly written in JavaScript .” What i t does is that it helps run Ja vaScript outside the
browser. NodeJS uses the chrome JavaScript engine to execute outside the browser so
that desktop and server based applications can be created using JavaScript. It also acts as
a central repository from where we can get any JavaScript f ramework usin NPM(Node
Package Manager).
Node was built to handle asynchronous JavaScript code to perform many
asynchronous activities such as reading and writing to the file system, handling
connections to database servers or handling requests as a web se rver. Node uses the
”Single Threaded Event Loop” architecture to handle multiple concurrent clients. The
processing model is based on the JavaScript event -based model along with the JavaScript
callback mechanism. To handle asynchronous code, Node uses a callback -based system.
Node functions and methods that will implement some asynchronous activity take a
callback function. This callback will be called whenever the asynchronous operation has
resolved.
Node packages are a convenient way to share modules between Node developers.
The service npm is the default package manager for Node, and it ships with an
installation of Node . This service allows access to the hundreds of thousands of open –
source packages available .
Chapt er 4
17
Figure 4. 4. -Node.js architecture [1]
Some of the advantages of Node. js architecture include the handling multiple concurrent
client requests fast and easy, not needing to create multiple threads , a single thread is
sufficient to handle a blocking incoming request, and last but no least, as memory is
always a problem in the nowadays softwares, Node.js requires fewers resources and
memory.
4.3.4. Angula r
Angular is a framework developed with the purpose of building single -page client
applications using HTML and TypeScript. , as Angular is written in TypeScript , an open –
source langua ge which builds on JavaScript by adding static type definitions . It
implements core and optional functionality as a set of TypeScript libraries that are
imported into the apps.
An Angular application has a specific architecture which relies on certain
fundamental concepts. Angular has some basic building blocks that are called
NgModules, which provide s a compilation context for components . NgModules collect
related code into functional sets .
Components define views, which are sets of screen elements that Angular can
choose among and modify according to the program logic and data. Components provide
specific functionality using services, not directly related to views. For data or logic that is
not associated with a specific view, and it is meant to be shared across components , a
service class is created. Service providers can be injected into components as
dependencies, which helps the code be modular, reusable and more efficient.
Routing is ma de possible through the Angular Router NgModule which provides
a service that gives the permission to define a path among the different application states
and view hierarchies in the app. It is modeled on the browser navigation conventions. The
router maps URL -like paths to views. When a user performs an action, such as clicking a
link, the router intercepts the browser’s behaviour and shows or hides view hierarchies.
Chapt er 4
18
Figure 4. 5.- Angular main building blocks [7]
A component and a template together form an Angular view , while the
dependency injector provides services to a component, such as router service that lets the
navigation among views be defined.
Organizing the code into distinct functional modules helps in m anaging
development of complex applications and also supports reusability. Moreover, this
technique minimizez the amount of code that needs to be loaded at startup , loading
modules on demand, also known as lazy -loading.
Advantages of Angular framework:
1. Functionality: the default setup of Angular gives everything it is needed. This
includes tools to manage routing, so data that is wanted can be easily fetched .
Angular’s pre configured environmnet facilitates testing and helps with
development . For a basic functionality application there is no need for a third –
party library as it has everything needed for a quick start in development which
offers better security and higher code quality.
2. TypeScript: as Angular is built with TypeScript, the main adva ntage of such a
strongly typed language is that it helps to keep the code clean and understandable .
This , again, is a good point in the testing process because bugs are easier to spot
and eliminate , supported by the ability to see common errors as they are typ ed as
they are more likely to happen during compilation. This makes the debugging
process quicker and also it makes it easier to mantain a larger codebase,
something that is particularly beneficial in large scale projects.
3. Consistency: a key feature is that there is o ne suggested way to create a
component, service or module. As opposed to React, Angular is a fully responsive
web design framework. This has the effect of creating great consistency
throughout the code base, an important aspect to strive for. A further enhancement
Chapt er 4
19
is the developed CLI tool that can be used to create certain repeata ble blocks of
code from the command line. Consistency is an advantage in terms of
understanding the structure of an app and easi ly maintained large code base, both
of which reduce cost and improve efficiency.
4. Simplified MVC Pattern: Angular framework is embedded with the original
MVC(Mode View Controller) software architectural pattern. Howe ver, it is not
according to the established standards. Angular does not require to split an
applicatio n into different MVC components and build code that could unite them.
Rather it only asks to divide the application and takes care of everything else.
Therefore, Angular has a simil ar MVVM(Model -View -View -Model) design
structure. All in all, it ensures easy development and eliminates the need for
unnecessary code. And ensures lighet and faster apps.
4.3.5. Selenium
Today’s development strategies work in shorter time frames of two to four weeks.
Delivering new, bug -free releases in that time require s deterministic, repeatable testing
procedures that provide near -instant feedback. Tha t is why Selenium testing is a n
important step in development of any web application project today.
Selenium as an open -source framework that is used for automating tests that are
carried out on the web browsers , web application s being tested using any web browser. It
offers compatibility with multiple programming languages such as Java, JavaScript,
Python and more .
The way Selenium works is that it allows to directly interact with web browsers
through the automation test scrips with the help of the Selenium WebDriver . Based on
the specifi cations that are declared through Selenium scripts, the WebDriver can open up
different browsers. JSON Wire Protocol is responsible for communicating with the
browser drivers through their HTTP server. It fetches the information from Selenium
Client Libraries and then relays it to the respective Browser Driver. Each browser has a
driver which is responsible for controlling the actions performed within that browser.
Some of the advantages of using Selenium testing tool are the following: open
source ava ilability, it i s a publicly accessible automation framework and it is free, with no
upfront costs . It can be integrated with tools such as TestNG or Junit for managing test
cases and generating reports and with Maven, Jenkins or Docker to achieve Continuou s
Testing. Another advantage is that test can be carried out in multiple operating system
like Windows, Mac or Linux , the testing suite can be created over any platform and then
executed on another one.
Chapt er 4
20
4.3.5.1. TestNG
The definition of TestNG as stated in its documentation is as follows „TestNG is a
testing framework inspired from JUnit and N Unit, but introducing some new
functionalities that make it more powerful and easier to use.” [9]
TestNG is an open source automated testing framework similar to JUnit . It is
designed to be better than JUnit , eliminating most of its limitations and giving the
developer the ability to write more flexible and powerful tests .
TestNG features:
• Supports annotations
• Uses more Java and OO features
• Supports testing integrated classes
• Separates compile -time test code from run -time configuration
4.4. Functional Requirements
Functional requiremens are product features or functions that must be
implemented to enable the user to accomplish tasks. Generally, functional requirements
describe system behavior and capabilities under specific conditions.
4.4.1. FEAT HMS01: Register and login
This is the first step the user has to make in order to then use the application.
Based on the data given at registration, when the user logs in it will be redirected to the
correct page (patient, doctor, nurse)
4.4.2. FEAT HMS03: Appointment making
This feature will offer patients the ability to make an appointment and also the
ability to delete an appointment. Doctors will be able to see all the appointments.
4.4.3. FEAT HMS02 : Patient examination management
This feature will offer doctors and nurses easy access to patient data and
examination information like the date of the examination , blood pressure and blood
sugar levels, temperature at that date and the weight of the patient. All this is searched in
the database by the patient’s social security numbe r.
4.4.4. FEAT HMS03: Patient admission management
This feature will offer doctors and nurses easy access to patient data and
admission information like the admission date and release_date, hospital room number,
diagnostic and the department where the patient is admited.
Chapt er 4
21
4.4.5. FEAT HMS04: Blood test report
This feature will offer doctors and nurses access to the blood test results from the
laboratory.
4.4.6. FEAT HMS05: LiveChat
This feature will be available for doctors and nurses.
4.5. Non-functional requirements
Non-functional requirements describe how a system must behave and establish
constraints of its functionality . This type of requirements are also known as the quality
attributes of a system.
4.5.1. Usability
The web application’s user interface shall be very simple to understand with
buttons that are intuitive and clearly written text. And in order for the user to accomplish
a particular task there will be a small number of steps involved.
4.5.2. Security
Security requirements ensure that the software is protected from unauthorized
access to the system stored data. As there is stored personal data, security is an important
aspect in the development of the application. To aquire this, data will be encrypted using
JWT , the user will be assigned a token to prove its identity. Tokens are designed to be
compact, URL -safe and usable.
4.5.3. Availability
Availability describes how likely the system is accessible for a user at a given
point in time. The application should be available for any type of user at any hour and
any day.
4.5.4. Portability
The software web application should be portable. Therefore, moving from one
operating system to another does not create any problems.
Chapt er 4
22
4.6. Stakeholder and User Description
4.6.1. Stakeholder Summary
Figure 4.6.- Stakeholder summary
4.6.2. User Summary
The primary users of the hospital management system web application are the
following:
• Doctor user: primary user of the application with the following
responsabilities: display appointments, view user profile information and
update user profile information and operations regarding patients
admissions, examinations, blood test results and generating reports based
on different parameters.
• Nurse user: primary user of the application with the following
responsabilities: mak ing admissions and making blood test lab reports for
patients.
• Patie nt user: primary user of the application with the following
responsabilities: add new appointment , display all the appointments , view
user profile and edit user profile information.
Chapter 5
23
Chapter 5. Detailed Design and Implementation
In this chapter it will be discussed in more detail some aspects regarding the
design and implementation of the developed web application. It will be presented some of
the important diagrams of the syste m and application use cases , as well as aspects
regarding components and important sequences of code for each part of the application:
backend layer, frontend layer and the data storage layer which is represented by the
database of the system.
5.1. Application use cases
Figure 5.2- Main activity diagram of the application
Above, in figure 5.2, there is a capture of a diagram with the flow of events that an actor
must follow in order to make an appointment in a custom scenario. The primary actors of
this event are the doctor and the patient. The stakeholders and interests are as follow:
doctor is interested in having a user friendly web application that will make it easier to
Chapter 5
24
manage all the operations that involve a hospital, while the patient is interes ted in being
able to make an appointment quickly and check its user information report.
5.1.1. Flow of events of the activity diagram
Basic Flow:
User -case Start
This use case starts when the actor wants to make an appointment:
BF01.The system displays the main available operations.
BF02.The actor chooses the operation: make new appointment.
BF03.The actor provides information regarding the title, the symptoms it
currently experiences and the suspected disease, as well as the date and doctor name.
BF04.The systems checks the availability of the date and the actor does one of the
steps: BF04.1 or BF04.2
BF04.1.In case the date chosen is not available, the actor does one of the
steps: BF04.1.1 (Reschedule appointment) or BF04.1.2(end appointment making
operati on).
BF04.1.1.Reschedule appointment.
BF04.1.2.The actor cancels the operation.
BF04.2.The actor sends the appointment request.
Use -case end
Appointment is accepted and can be seen in the appointment list.
Alternative Flows:
AF01.Abort Appointment
This flow can ocurr at step BF04.
AF01.1.The actor selects the Cancel operation and leaves the appointment
making page.
AF01.2.The system remains unchanged.
AF02.The actor deletes the appointment
This flow can occur after the use case ends.
AF03.The actor reschedules the appointment
AF03.1.The actor starts Reschedule Appointment
AF03.2.The actor goes back to BF04.
Preconditions:
1.The actor must have internet access.
2.The actor must have an account.
Postconditions:
1.The database is changed and new data appears in the corresponding table.
2.The doctor’s appointment list is changed and has added a new appointment.
Chapter 5
25
5.1.2. Use-cases
Figure 5.2- Use case diagram for Doctor user
Figure 5.3- Use-case diagram for Patient user
Chapter 5
26
Figure 5.4- Use-case diagram for Nurse user
UC1
Use case name: Login
Primary actor: Registered user
Description: This use case will allow the user to access all the specific operations
based on the user type.
Basic Flow:
Use-case start
BF1. The user enters the credentials: username and password
BF2. The user presses the ”Login” button.
BF3. The login operation is successful and the user has now acces to all the
features of the application based on its type.
Use-case End
The Doctor end the login operation.
Alternative Flows:
1.Incorrect email or password
This flow could occur at step BF2
1.1. The email or password cannot be found in the database
1.2. The user gets an error notification that his email or password do
not exist in the database
1.3. The flow will on from step BF1
Preconditions:
The user must have internet access.
Postconditions:
The user will be able to see all the operations of the application based on
its user type and access them.
Chapter 5
27
UC2
Use case name: Logout
Primary actor: Registered user
Description : This use case will permit the user to log out of the web application
when needed.
Basic Flow:
Use-case start:
BF1. The user desires to log out of the web application and presses the
„Logout” button.
BF2.The logout operation is performed successfully and the user is logged
out of the web application.
Use-case end:
The user ends the logout operation.
Alternative flows:
1.Logout failed
This f low could occur at step BF2.
1.1. The logout failed from various reasons.
1.2. The system will show an informative message to signal the
error.
Preconditions:
1.The user must have internet access.
2.The user must be logged into the web application.
Postconditions:
1.The user will be logged out of the web application.
UC3
Use case name: Search patient info
Primary actor: The primary actor is the one that has doctor role
Description : This use case will permit the doctor to different patient information
based on the social secturity number of the patient.
Basic Flow:
Use-case start:
BF1. The system will display the doctor operations dashboard
BF2. The doctor user will choose the „Search patient info” operation
BF3. The doctor will enter the social security nu mber of the patient.
BF4. The doctor will choose the type of information it wants displayed.
BF5. The doctor will close the search operation after the completion.
Use-case end:
The doctor ends the search patient information operation.
Alternative flows:
1.The social security number is incorrect
Chapter 5
28
This flow could occur at step BF4.
1.1. The system cannot find any information in the database
about the social security number entered.
1.2. The flow will carry on from step BF3
Preconditions:
1.The d octor must have internet access.
2.The doctor must be logged into the web application.
Postconditions:
1.The doctor will be able to see information regarding the patient that has the
social security number entered.
UC4
Use case name: View Profile
Primary actor: Registered user
Description : This use case will permit the user to take a look at the personal
information it has as its profile.
Basic Flow:
Use-case start:
BF1. The user clicks on the ”View profile” button.
BF2.The operation p erforms successfully and the user is able to see its
profile.
Use-case end:
The user ends the view profile operation.
Alternative flows:
1.No personal information to show
This flow could occur at step BF2.
1.3. The system cannot find personal information about the
current user in the database.
1.4. The flow will carry on from step BF1
Preconditions:
1.The user must have internet access.
2.The user must be logged into the web application.
Postconditions:
1.The user will be able to see its personal in formation listed.
UC5
Use case name: Update profile
Primary actor: Registered user
Description : This use case will permit the user to edit its personal information
when needed.
Chapter 5
29
Basic Flow:
Use-case start:
BF1. The user enters the ”View profile” page by clicking the button with
the same name.
BF2. The user clicks on the ”Update” button.
BF3. The user enters new personal information.
BF4. The user clicks on the submit button.
Use-case end:
The user ends the update profile informatio n.
Alternative flows:
1.Update failed
This flow could occur at step BF4.
1.1. The update operation failed from various reasons.
1.2. The system will show an informative message to signal the
error.
Preconditions:
1.The user must have internet access.
2.The user must be logged into the web application.
Postconditions:
1.The user will visualize update profi
UC6
Use case name: Delete appointment
Primary actor: Registered user that has the role of the patient
Description : This use case will permit the user to delete an existent appointment
from the database
Basic Flow:
Use-case start:
BF1. The user clicks on the ”View appointments” button.
BF2. The user clicks on the „Delete” button from the desired appointment
BF3. The user successfully erases the chosen appointment from the
database.
Use-case end:
The user ends the delete appointment operation.
Alternative flows:
1.Appointment not deleted
This flow could occur at step BF2.
1.1. The system was not able to delete the chosen appointment
from the d atabase due to various reasons.
1.2. The flow will carry on from step BF1.
Preconditions:
1.The user must have internet access.
Chapter 5
30
2.The user must be logged into the web application.
Postconditions:
1.The user was able to delete the selected appointment from the d atabase.
5.2. System architecture
Figure 5. 5- System architecture
For this hospital management system web application the chosen system
architecture is the 3 -tier architecture, which is a modular client -server architecture in
which presentation, application processing and data management functions are physically
separated.
The first layer, client or presentation layer is managed by the Angular TypeScrip t-
based web application framework , the second layer is man aged by the Spring framework
built on and the third layer, the data layer is implemented with the help of MySQL .
The front end, the client, makes requests to the server for services that it has to
offer , while on the backend, the server component listens for requests from the client.
When a request is received, the server processes the request and then sends a response
back to the client. The communication between the two components is made possible
through REST .
REST helps with a good separation of concerns. The implementation of the client
and the implementation of the server can be done independently without each knowing
about the other. What this means is that the code on the client side can be change d at any
time without affecting the opera tion of the server, and the code on the server side can also
be modified or upgraded without affecting the client side. Being built on top of HTTP,
REST APIs pr ovide the means to build flexible APIs. The interchange d data on the web
uses the JSON (JavaScript Object Notation) data format .
The backend was built using the Spring Framework , together with a layered
architecture which consists of multiple modules . The developer can choose from multiple
architectural styles. For this application it will be used the most known and greatly used
type, the one on 4 layers: presentation, business logic, persistence and database. Each of
the layers in the architecture is marked as being closed. A closed layer means that as a
reques t moves from layer to layer, it must go through the layer right below it to get to the
Chapter 5
31
next layer below that one. The layers of isolation concept means that changes made in
one layer of the architecture generally don’t impact or affect components in other layers.
The frontend was built using Angular 10 , a fully featured JavaScript framework
that helps developing dynamic, single page web apps . Angular is more of a component
based architecture, as it can be assumed that everything is a component. A base
component contains dependencies, a view details and class declaration which can be
considered as a controller, therefore a well defined component consists of an individual
set of MVC architecture.
5.3. Admin Backend architecture
The admin will have comple te control and access to all of the capabilities and
functionalities that the web application . As mentioned before, the backend is
implemented following the layered architecture with 4 layers: presentation, business
logic, persistence and database. The fir st layer, presentation layer, is the level that
exposes the functionalities of the application as an API capable of managing the REST
HTTP requests. This layer retrieves the received data and transmits it to the next level
layer, the business logic layer, from which it gets a response that will be sent to the client.
The controller classes are at this level, placed in the “controller” package , which can be
seen in the figure below, and annotated with the @RestController annotation from
Spring . For example in the ExaminationController there is the “listExamination” method
which takes a string as a parameters because it returns and examination based on the
social security number, and can be accesed at the following url: “ listExamination/{cnp}”.
For the mapping of web requests to the methods from the controller there is a Spring
annotation : @RequestMapping used together with the specialized versions:
@GetMapping, @PostMapping, @PutMapping and @DeleteMapping. In the methods, as
a parameter, parts of the mapping URI can be bound to variables via @PathVariable and
the DTO(Data Transfer Object) which is received from the client is annotated with the
@RequestBody annotation.
Figure 5. 6 – Classes in the controller package
The next layer, the Business logic layer, represents the layer which translates the
CRUD methods into actual business operations. The DTOs of the web application are
Chapter 5
32
transformed into entities and entities into DTOs, d epending on the operation , like creating
a new appointment in the database or editing some patient information from the database.
All these classes are in the “service” package and is illustrated in figure 5 .7.
Figure 5. 7- Classes in the service packag e.
The DTOs in the “dto” package are objects used to encapsulate data and send it
from one subsystem of an application to another. The DTOs from this project can be
viewed in the figure below. Data Transfer Objects are commonly used by the business
logic layer in the n -tier application architecture to transfer data between backend and the
frontend. One of the benefits of using a DTO is that it reduces the amount of data that
needs to be sent ac ross th e distributed applications, when there is no need to expose the
whole entity to the client , as it only needs only some data regarding one entity. Therefore,
for each entity or model there is a corresponding dto class. The conversion from dto to
mode l and model to dto is done in the management classes in each method that needs it.
Figure 5. 8- Classes in the dto package.
Still in this layer , there is also the “config” packet which contains the security
configuration class , as it can be seen in the figure 5. 9, and it extends the
WebSecurityConfigurerAdapter from Spring Security , overriding the configure method
Chapter 5
33
that defines the mapping of secu red URLs or paths that will determine if the user can
access specific pages.
Figure 5. 9- Classes in the config package
The persistence layer includes the “api” package which contains repository
interfaces that extend JPA, Java Persistance API, mapping Java objects to database t ables
and vice versa, called Object -relational mapping(ORM). Through JPA the developer can
map, store, update and retrieve data from relational databases, in this case MySQL, to
Java object and vice versa. JPA permit s to work directly with objects rather than with
SQL statements.
Figure 5. 10- Classes in the api package
Chapter 5
34
The last layer, the database layer , can only be acces sed by the persistence layer
and it contains tables and the relationships between them. In figure 5.1 1 it is illustrated an
example of class dependency for the User.
Figure 5.1 1- An example of class dependency
Spring fram ework off ers a wide variety of annotations that make the development
process much easier. Spring has @Autowired annotation that is used for automatic
dependency injection . Assuming each class that has to become a bean , the objects that
form the backbone of the appl ication and that are managed by the Spring IoC container ,
is annotated with the correct annotation like @Component, for simple bean, @Controller,
for a servlet control or @Service and @Repository, for repository classes, Spring will
find all of these and create a bean for each one. Another t hree really important and handy
annotations are the @Data , @NoArgConstruct or and @AllArgsConstructor annotations.
They are Lombok annotations, a tool that makes it easy to manage common tasks by
plugging into the buil t process and autogenerating Java bytecode. Many classes need
getters, setters and constructor methods, which in large projects will take a lot of time
plus it makes the class look com plicated and hard to read , this is where these three
methods come to the rescue.
The backend has been created with the help of Spring Boot which is basically an
extension of the Spring framework which eliminates the boilerplate configurations
required for getting started with a Spring web application. One of the benefits of using
Chapter 5
35
Spring Boot is that it provides a number of starter dependencies for different Spring
modules. Some of the ones used in this project are: spring -boot-starter -data-jpa, spring –
boot-starter -security or spring -boot-starter -web.
5.4. Frontend architecture
For the frontend devel opment part of the hospital manage ment system the
framework that has been used is Angular, the Google -developed web framework version
10. As opposed to AngularJ S which supports the MVC(Model View Controller)
architecture where the business logic is put in the model, the desired output in the
controll er, Angular’s building blocks are formed by components and directives.
Components are actually directives with a predefined template. They provide a modern
structure to the applications, making it easier to create and maintain larger applications.
One main advantage of the component based architecture of Angular is that the
components of the application are quite independent and self -sufficient, which makes
them reusable and test friendly and they are easier to replace when needed and
maintained. The model part is represented by model classes which correspond to the
DTOs from the backend and which is used for sending and receiving data from the
backend. The view part is represented by the CSS and HTML files which gets data from
the user and displays data for the user.
Each component defines a class that contains application data and logic and is
associated with an HTML template that defines a view to be displayed in a target
environment. The @Component () decorato r identifies the class immediately below it as a
component and provides the template and related component -specific metadata.
Decorators are functions that modify JavaScript classes and Angular offers a wide variety
of decorators to attach specific kinds of metadata to classes. For this project, the s pecified
metadata is the following: selector, templateUrl and syle Urls. Selector is a CSS selector
that tells Angular to create and insert an instance of this component wherever it finds the
corresponding tag in template HTML. For example, in the app.compo nent.html there is
<app -header></app -header> therefore Angular will insert an instance of
HeaderComponent view between those tags. TemplateUrl is the module -relative address
of this component’s HTML template. Providers is an array of providers for services that
the component requires.
For this project, all the files are stored in the “src” folder, more precise in the
“app” folder. Each page of t he web application has been created using the “ng g c
name_of_component” command which creates a folder for each component which
contains four files: the ts file where the component is defined, the two files where are the
styling part goes, CSS and HTML and the testing file of the component with the
extension .”spec.ts” . This file contains unit tests for the main Component . When running
tests using the Angular CLI, all unit tests in files with the “.spec.ts” extension will be run .
An advantage of using Angu lar CLI to create an Angular project is that it comes with
Karma and Jasmine to make testing simple by automating the process. Jasmine is a
Chapter 5
36
behavior development testing framework. Unit tests are written using Jasmine and run to
see if in dividual parts of a n application are working correctly.
For a better management of the project there have been created the following
folders: header, home, model, services and user -ops.
The “header” com ponent is visible in any view of the application as it contains the
“Register” and “Login” and “Home” links , before the user is authenticated and the
“Home”, “Chat” and “Logout” links after the user is logged in the application.
The “model” folder contains only model classes for each type of DAO that the
backend contains . They also have “payload” in the name structure as they are contained
in the body of the requests made to the server , for example , the “register -payload.ts”
contains string fields for username, password, email and role.
The “services” folder cont ains all the service classes which communicate with
backend services using HTTP , the “auth” service class which contains authentication
methods and “patient” service class which contains patient related methods . Angular
distinguishes components from servic es to increase modularity and reusability. By
separating a component’s view -related functional ity from other kinds of processing it can
make component classes lean and efficient. Each service class has been marked with the
@Injectable() decorator which makes that class as available to be provided and injected
as a dependency . The injector is responsible for creating ser vice instances and injecting
them into classes.
The “user -ops” folder contains the operations dashboard component for each type
of user of the application: patient, doctor and nurse.
Modern frontend frameworks package themselves with a variety of lifecycle
hooks and Angular is one of them. Lifecycle hooks are timed methods, they differ in
when and why they execute. These type of methods are triggered by the detection of
change. Angular runs change detection constantly on its data. All lifecycle methods are
available from “@angular/core” . While creating a new component in Angular there is a
special method that appears below the constructor, “ngOnInit()” , that cand be used to do
some operations like fetching data or something we want to see immediately on page
load, as these kind of operations are not recommended to be done inside the constructor.
In Angular, the constructor should only be responsible for dependency injection.
Another Angular lifecycle method that can be hooked into on component is the
“OnDestroy()” method whose primary purpose is to perform cleanup just before the
component is destroyed. It helps to avoid memory leaks that come from Observables. An
example present in the project i s on the login page component, when the button is clicked
a call to “login()” method on AuthService that return an Observable containin g the role of
the user in order to route it to the correct page. To fix the memory leak there is a need to
augment the component class with an implementation of “OnDestroy()” and unsubscribe
from the subs cription.
The main component that gets created after we make a new project in Angular is
the AppComponent, in the app.component.ts file. Every Angular app has a root module
where there are defined the main components to load. In the default Angular app th e root
module is defined inside the app.module.ts. When the AppModule loads, it checks which
component is boot strapped and loads that module, which in this case is the
AppComponent.
Chapter 5
37
In a single -page app it can be changed what the user sees by showing or hiding
some parts of the display that correspond to different components , instead of going out to
the server to get a new page. As users perform various tasks and operations, they are
moved betwe en different views that have been defined. To handle the navigation from
one view to another , Angular’s Router can be used. The Router enables easy navigation
by interpreting a browser URL as an instruction to change the view. The routes are
defined in the app.module.ts file as an array. Each route in this array is a JavaScript
object that contains two properties. The first property, path, defines the URL path for the
route, while the second property, component, defines the component that should be used
for the corresponding path. The routes are then added to the application .
Another important file of the project is the “package.json” file, which holds
various metadata relevant for the project. This file is used to give information to npm that
allows it to identify the project, as well as handle the project’s dependencies. It can also
contain other information, such as project description, the version of the project in a
particular distribution or license information.
Temporary data storage
Some data regarding the user is often used in different circumstances, on different pages.
On the client side of the application user data which is used during the time that the web
application is up and running can be stored using cookies, localStorage and
sessionStorage. The last two are part of the web storage API and are two great tools to
save ke y/value pairs locally. Both localStorage and sessionStorage offer some advantages
compared to using cookies: the data is saved locally only and can’t be read by the server,
which eliminates the security issue that cookies present, it allows for much more data to
be saved and it’s simpler to use and the syntax is very straightforward. It is also
supported in all modern browsers, so you can use it today without an issue.
For this project the sessionStorage has been used . Even though localStorage and
sessionStorage accomplish the exact same thing and have the same API , with
session Storage data is persisted only until the window or tab is closed . With localStorage
the data is persisted until the user manually clears the browser cache or until the web app
clears the data. It assures that the data cannot be accessed by a malicious user as the data
access is limited to a single page because when the tab is closed , the d ata is also erased
and the user has to login again.
Although sessionStorage, unlike localStorage, is not designed for long -term persistence
of values in the user ’s browser, there is an exception. When a browser provides a
“Restore Session” feature, usually designed to help users quickly recover from a browser
or computer crash, values in sessionStorage will be restored too. Therefore, while it’s a
new session on t he server, from the browser’s perspective it is a continuation of a single
session across a browser restart. This makes sessionStorage an ideal storage technique for
things like temporary “backup” of user form values, saving input to storageSession as it
is entered and restoring on page load to further help the user recover from a crash or
accidental page refresh.
Chapter 5
38
Email validation
Email validation has been done using the interfaces and classes f rom Java mail support in
the Spring framework and Mailtr ap API which simulates the work of a real
SMTP (Simple Mail Transfer Protocol) server .
5.5. Database structure
This project uses the MySQL database , a leading open source database
management system, It is a multi -user, multithreaded database management sys tem. In
order for the Spring application to connect to the database there a few steps that need to
be taken. Spring Boot tries to auto -configure a DataSource if “spring -data-jpa” is in the
classpath by reading the database configuration from application.properties file. The
configuration data that needs to be included is the data source url, username and password
and the properties for hibernate. One advantage for using Spring Boot is that it uses
Hibernate as the default JPA implementation , so there is no need to define the
entityManagerFactory bean unless we want to customize it . Spring Data JPA greatly
simplifies the way code is written for the data access layer , there have been written
repository i nterfaces that extend the JpaRepository. The domain model classes have been
annotated with the @Enitity annotation , which specifies that the class is an entity and is
mapped to a database table , the class name and its attribute names are identical to table
name and field names which makes the mapping simple. The primary key of an entity is
specified with the @Id annotation. The @GeneratedValue gives a strategy for generating
the values of primary keys.
Each table in the database is uniquely identified thro ugh a numeric primary key
named “id”. The “Date” is of type Timestamp while the other attributes are String types,
as this type is easy to work with from the frontend.
The “user” table contains user related information, password which is encoded
using the “BCryptPasswordEncoder() ” method, username, role_id, which is a foreign key
and identifies the role of the user and a verified attribute which changes its value from 0
to 1 when the user verifies its account using the link received via email. The table has a
One-to-One relationship with the “ role” table, as one user can only have one user role.
The “role” table contain s only the “role_name” attribute which has the following
three values in the database: “ROLE_PATIENT”, “ROLE_DOCTOR” and
“ROLE_NURSE” .
The “appointment” table contains attributes that describe an appointment made by
the patient, “date” attribute, “suspected_disease”, “symptoms” that the patient is
experiencing , the “title” of the appointment in order for the doctor to identify the problem
quicker and “user_id” which is a foreign key. There is a One -To-Many relationship
between the “user” table and “appointment” table, as one user can have many
appointm ents associated with it.
Chapter 5
39
The “verification_token” table stores attributes about each to ken that is associated
with each user.
The “blood_test_report” table store s attributes associated to a blood test lab result
like Hemoglobin (hgb), red blood cell count (rbc), chloride test(cl), potassium test (k) and
sodium test (na) .
The “examination” ta ble stores information related to a patient examination , like
the blood pressure and blood sugar levels, the date when the examination took place, the
temperature and weight of the patient as well as the foreign keys “patient_info_id” and
“blood_test_report_id” because part of the examination is also a blood test.
Figure 5.1 2 – Database Diagram
The “patient_info” table contains information related to a patient, which is also a
user of the application so there is a One -To-One relationships with the “user” table. Some
of the attributes related to a patient that are relevant for the doctor are the patient name
and surname, its address and telephone number, its height and weight , any other chronic
illness problems, its occupation, the physical activity level which can be important for
Chapter 5
40
some health issues, as well as the fact if the patient is a smoker or not. The last attribute,
but also the most important is the social security number, which will be used by the
doctor to search information about a patient, because each patient has a unique social
security number.
Some of the annotations used in order to map the entities are the following:
• @Entit y- specifies that the class is an entity
• @Column – specifies th e table’s column names
• @Id- specifies the primary key of the entity
• @GeneratedValue – specifies the generation strategies for the values of primary
keys
• @OneToOn e- specifies th at one instance of the current entity refers to one
instance of the reffered entity
• @JoinColumn – used for One -To-One associations when foreign key is held by
one of the entities
• @ManyToOne – specifies the many instances of the current entity refers to one
instance of the reffered entity
5.6. Main components and modules
In this subchapter it will be presented into more detail the main components of the
web application and also describing the way they are connected together. In figure 5.14 it
is illustrated the package organization of the backend and in figure 5.15 the package
organization of the frontend.
Chapter 5
41
Figure 5.1 3- Pack age diagram of the backed
Figure 5.1 4- Package diagram of the frontend
5.7. Sequence diagram
UML Sequ ence diagrams are interaction diagrams that detail ho w operations are
carried out in the application. Their main objective is to capture the interaction between
objects in the context of a collaboration.
Figure 5.1 5 – Auth entication Sequence Diagram
Chapter 5
42
Figure 5.1 6 – Get treatment sequence diagram
5.8. Class diagram
Figure 5.17 – Representative class diagram for the Treatment model
Chapter 5
43
5.9. Deployment diagram
Figure 5.17 – Deployment diagram
Chapter 6
44
Chapter 6. Testing and Validation
Softwa re testing is defined as an activity to check whether the actual results match
the expected results and to ensure that is not missing any requirements . Software testing
domain can be broadly categorized into two areas: manual testing and automated testing.
In manual testing, test cas es are executed manually without any support from tools or
scripts , while with automated testing, test cases are executed with the assistance of tools,
scripts and software.
6.1. API Testing with Postman
Postman is a Google Chrome app which is mostly used to t est APIs to see the
returned result. It is a powerful HTTP client for testing web services and has a friendly
and easy to use GUI which allows users to quickly put together simple or complex HTTP
requests.
In order to test a GET request the first step is to write the route in the address bar ,
select the type of request on the dropdown box , in out case it is a GET response method ,
specify that the response is in JSON format and then press send. In the below example,
figure 6.14 , the response is an easy-to-read JSON with a status code of 200, which
confirms that the GET request of patient info with the social security number “2345” was
successful.
Figure 6.1 – GET request example
Chapter 6
45
In order to test a POST request, select from the dropdown box the POST method,
enter the route in the address bar , click on the “Body” tab , select “raw” and then JSON,
and ent er the request body in the text area. In figure 6.15 there is an example of a login
request , which returns a response body that contains some d ata and a status code of 200
that confirms a successful request
Figure 6. 2- POST request example
In order to test a DELETE reques t, the route has to contain the id of the item that
will be deleted. In figure 6.16 is an example of a DELET E method.
Figure 6. 3- DELETE request example
Chapter 6
46
6.2. Manual testing on the frontend
Test
case
nr Test case description Test steps Test data Expected
results Actual
results
1 Check response when
valid credentials are
entered 1.Go to site
2.Enter username
3.Enter password
4.Click login Email: test1
Password:test1 Login should
be successful Login was
successful
2 Check response when
invalid credentials are
entered 1.Go to site
2.Enter username
3.Enter password
4.Click login Email: test
Password: test User should
not Login into
the
application Login was
unsucce ssful
3 Check response with
empty field 1.Go to site
2.Leave username
blank
3.Enter password Email: blank
Password:
test1 User should
not Login and
should receive
message Login was
unsuccessful
Figure 6. 4- Test case with empty field
Chapter 6
47
Figure 6.5- Test case with invalid credentials
6.3. Automated testing
When one is planning to automate the testing of a web application, Selenium
should be the first that comes to mind. Besides the fact that it is a open source tool it is
also a portable software for web applications that supports multiple programming
langua ges.
In order to get started with Selenium , it is needed to bring some components
together before the coding part. Selenium is compatible with multiple operating systems
and also supports multiple browsers. Its main purpose is to automate functional test s.
The prerequisites for the setup are the following: Java JDK, the preferred IDE,
which in the case of this project is IntelliJ, Chrome driver , configuring Selenium
WebDriver with IntelliJ and the last step is creating and running the first test.
The structure of the testing project will be the following: in the package there will
be created the tests, there will be a package called “base” that will have the “BaseTest ”
and a package for each specific test we want to do, in the example below there i s a
package “login” which contains the test s needed for the login functionality. The
“BaseTest” class will contain t wo annotated classes, “setUp()” method annotated with
“@BeforeClass” which means that it will run before each of the test classes and a
“tearDown()” method annotated with “@AfterClass” which will be called after the tests
have run . All the test classes will inherit from the BaseTests class , as it is the class where
the driver is created and all the setup is done .
A pattern used in this projec t is the Page Object Model design patter, one of the
most popular design patterns in test automation . The way that this pattern works is that in
the framework section of the project a class is created to represent each page in the
applicatio n. Under the ja va folder in the src will be created a “pages” package that will
represent the page object classes. In th ese classes the elements that will be needed will be
identified and the methods for the interaction with these elements will be created, for
Chapter 6
48
example, for the login page the login button will be identified and a method to click on
the button will be created.
The actual testing part will be done using TestNG , which helps to define the
execution approach of the test cases and the different features associated with it. For
example, the “@Test” annotation is the root of TestNG test cases, in order to use TestNG
all methods should be annotated with this annotation.
TestNG makes automated t ests more structured, readable, maintainable and use –
friendly. It provides powerful features and reporting. Its high -end annotations makes it
easier to scale up , as you perform cross browser testing across multiple devices, browsers
and their versions.
Figure 6. 6- Automation project setup
Chapter 6
49
Figure 6. 7- Output from running tests for login operation
Chapter 7
50
Chapter 7. User’s manual
7.1. Installation steps
7.1.1. Required resources
In order for the application to run correctly, the following resources are necessary:
• JDK: development environmnet for building applications using the Java
programming language. After downloading and installing the JDK, the last
step is to edit the PATH environment variable
• IntelliJ IDEA
• Tomcat server
Automatically configured by Spring Boot
• MySQL
• NodeJS
It can be downloaded from the official site a t
https://nodejs.org/en/download
• Angular 10
It can be installed by running in the NodeJS terminal the following
command: „npm install -g @angular/cli”
7.1.2. Running the project
The backend project can be started by running the „ProjectApplication” main
class, while on the front end , the project can be run by writting the „npm start” command
in the angular terminal.
In order for the user to use the chat features , the file server.js needs to be up and
running, located in the „chat -app-server” folder.
7.2. User manual
7.2.1. Authentication
The user can register and make a new account by clicking the „Register” button
that can be seen on the home page , as illustrated in figure . The user will be redirected to
the register page where some fields need to be filled with the follo wing information:
username, password, email address and also the type of user , which can be patient, doctor
or nurse , process illustrated in figure 7.20 . The user will receive an email notification on
the email specified at registratio, which contains a li nk to activate the new account. Next,
the user can click on the Login button and provide the credentials from the registration
process to log in , as it can be seen in figure 7.21 . Depending on the type of user, the
Dashboard page will contain the operation s that can be made. After registration and
successful login, the new user can provide information in its profile page.
Chapter 7
51
Figure 7.1 – Home page of the web application
Figure 7.2 – Registration page
Chapter 7
52
Figure 7. 3- Login page
7.2.2. Patient dashboard
After the user that has the role of „patient” has successfully logged in , he will be
able to see the dashboard illustrated in figute 7.22 with the possibility to log out by
clicking „Logout” button.
Figure 7. 4- Patient dashboard operations
Chapter 7
53
7.2.3. Doctor dashboard
After the user that has the role of „doctor” has successfully logged in, he will be
able to see the dashboard illustrated in figute 7.23 with the possibility to log out by
clicking „Logout” button.
Figure 7. 5- Doctor dashboard operations
When the doctor clicks on the „Patients” button , a new page containing patient
related operations will be shown. The doctor needs to enter a patient social security
number and it can search for different information like an examination report, admission
report or blood test report. All this is illustrated in figure 7.24
Figure 7. 6- Patient related operations
Chapter 7
54
7.2.4. Nurse dashboard
After the user that has the role of „nurse” has successfully logged in, he will be
able to see the dashboard illustrated in figute 7.2 5 with the possibility to log out by
clicking „Logout” button.
Figure 7. 7- Nurse dashboard operations
After the doctor will enter the treatment for a patient, the nurse can register the
date and time of when the treatment was last administrated.
Figure 7. 8- Register treatment operation
Chapter 8
55
Chapter 8. Conclusions
This last chapter will present the current functionality of the web application
compared to the objectives that were defined at the starting point of the project
development and the future improvements that can be added to the application.
8.1. Current functionality of the application
The fini shed product mostly has accomplished the sets of objectives that were
defined at the beginning of the development process.
The primary goal of the web application was to have a hospital management
system that is easy to use and contains only the relevant operations needed for a medical
unit, that can be used by both the doctors and the nurse, but also by the patient.
This goal has certainly been accomplished, as there have bee n separated all the
roles in the application: patient, doctor and nurse , each of them having a dashboard with
different operations.
All the users of the application can do the following:
• Register
All the doctor users of the application can do the followi ng:
• Login
• Logout
• Chat with nurse
• Add treatment
• Display appointments
• View profile
• Update profile
• View examination report
• View patient info
• View admission report
• View blood test report
All the nurse users of the application can do the following:
• Login
• Logout
• Register treatment
• Add examination report
• Add blood test report
• Add admission report
• Chat with doctor
All the patient users of the application can do the following:
• Add new appointment
• Display appointments
• Delete appointment
• View profile
• Update profile
Chapter 8
56
8.2. Further improvements
One improvement that could be really useful in the case of a hospital management
system would be to have an accounting module which organizes the financial affairs of
both customers and the medical institution . It stores and presents all the patient payment
details, hospital financial records on expenses and overall profit .
Second improvement that could be made is a radiology management module
where the hospital management system manages all radiolog y services provided by the
hospital. As the radiology tests are booked by the doctor for a patient, the request is
automatically sent to the radiology department . Some of the operations can include:
centralized reporting tool for CT, MRI, Ultrasound or X -rays, completel y compatible
with all radiological imaging technologies, offers smart methodologies for interpretation,
radiology reports available via patient portal enabling complete paperless solution,
SMS/Email sent to the patient when r esults are available.
Another relevant enhancemen t would be a dietary module which lets the dietician
prescribe the most suitable diet to any given patient, based on his/her medical condition,
as instructed by the physician. It could also allow the mainte nance of meal scheduling,
customizing meals as per patient meals and recording individual meal orders.
Lastly, a really important and useful improvement would be to make the
application also available on mobile devices, both An sdroid and IOS.
Bibliography
57
Bibliography
Chapter 9. Bibliography
[1] https://jwt.io/introduction/.
[2] https://medium.com/@xoor/jwt -authentication -service -44658409e12c.
[3] https://medium.com/java -vault/layered -architecture -b2f4ebe8d587.
[4] https://code.tutsplus.com/tutorials/a -beginners -guide -to-http-and-rest–net-16340.
[5] https://www.simplilearn.com/understanding -node -js-architecture -article.
[6] https://angular.io/guide/architecture.
[7] https://www.baeldung.com/spring -email.
[8] https://testng.org/doc/documentation -main.html.
[9] Thuan D. NGUYEN, „A Web -Based Electronic Medical Records and Hospital Information
System for Developing Countries,” 19 February 2010.
Appendix 1
58
Appendix 1 (only if needed )
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Tamas Ioana Florina Licenta Fara Semnaturi (2) [605364] (ID: 605364)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.