CHAPTER 1
Mobile Application for Medical
Diagnosis
ANDREI GABOR • MARIUS POPESCU • FLORIN POPA-IOVANUT •
ANTOANELA NAAJI
“Vasile Goldis” Western University of Arad, Arad, Romania
1 INTRODUCTION
Mobile applications continue to be a challenge for
software developers, although the first attempts yielded
results decades ago. Technological evolution has moved
this industry from an exclusive area to a purely commer-
cial one, which appeals to large hardware and software
companies in the field [1e3].
Digital pager technology dominated the market until
the early 1990s, when the emergence of mobile phones
dramatically reduced pager sales [4].
Today, the use of smart mobile devices such as
tablets and cell phones is steadily increasing. This is
why mobile device manufacturers are forced to improve
their hardware and come up with improved technolo-
gies [5,6]. It is also well-known that the volume of
hardware sales from giant companies such as Apple,
Samsung, BlackBerry or Nokia are mainly due to the
number and quality of software that each platform
offers to its users.
Mobile applications are divided into two main
categories: native applications and hybrid applications.
Native applications are those that are written in the
programming language specific to the platform for
which they are developed. This is because native appli-
cations must retain the behavior and the design of the
running operating system. They must integrate into
the platform chosen by the end user. For a “native”
product to run on multiple operating systems, it usually
requires a programmer for each platform based on
workload, deadlines, and other factors [7e9].
Hybrid applications are those that are typically
developed using WEB technologies (JavaScript, HTML,
CSS). Nowadays, hybrid applications are starting to
grow stronger because many development environments
Telemedicine Technologies. https://doi.org/10.1016/B978-0-12-816948-3.00001-5
Copyright © 2019 Elsevier Inc. All rights reserved.
are becoming more stable and provide access to more
and more hardware features of devices. Hybrids typically
consist of a native web browser component that can
access various features of the running platform (e.g.,
video camera, contact list, etc.). As a rule, hybrid applica-
tions have the same graphic design on all platforms that
have been published, regardless to the user interface
implementation guide of each platform running the
application [10e12].
In this chapter we present a mobile application
which was designed to diagnose users’ illnesses
following a set of questions. Any element in the appli-
cation can be modified by using Firebase. The software
is developed in the Xcode programming environment
using the Objective-C programming language.
The second section of the chapter contains the
description of the application (the structure, the archi-
tecture, the description of the modules, the structure
of the database, the features, etc.). The third section
describes how the application works. At the end of the
chapter some conclusions are drawn and future work
is identified.
2 DESCRIPTION OF THE APPLICATION
The application for medical diagnosis was designed to
help reluctant people who, because of being afraid of
going to a doctor when experiencing health problems,
prefer to look up on the internet for possible causes
and find a diagnosis.
To further simplify matters, MedicalDiag offers its
users, free of charge, a presumptive medical diagnosis
service guided by their answers to various questions.
The responses are “Yes” and “No”. Finally, to make
sure that the diagnosis is as accurate as possible, they
1
2 Telemedicine Technologies
FIG. 1.1 The MedicalDiag block diagram.
have the opportunity of contacting a specialist doctor
from a chosen city by phone.
The block diagram of the application is shown in
Fig. 1.1.
2.1 Application Features
The application has two modules: the administrative
one and the client one.
The administrator module has the following
features:
• Change any question for any illness;
• Change user data (name, email, PNC e personal
numeric code);
• Export/import the database;
• Statistics for any access;
• Setting permissions for users.
The client module has the following features:
• Account creation and authentication;
• Ability to change your password;
• Displaying the human body (male/female, front and
back) and choosing the main areas of the body;
• Identifying a possible disease and displaying a
diagnosis based on the user’s answers;
• Providing the contact details of a specialist in the
field of the user’s possible illness, within his or her
geographical area;
• Statistics in a pie chart with the most affected areas
(data taken from all users in real time);
• The possibility to change personal data (PNC,
gender, name).
2.2 Gantt Chart
For a better organization and planning of the develop-
ment stages of the application, the Gantt chart shown
in Figs. 1.2 and 1.3, created with the SmartSheet
application, was used. The Gantt chart is a tool used to
plan projects, events and work in general. It follows the
stages of running a project according to their duration.
It is a common method in project management. It was
invented by Henry L. Gantt (American engineer and
sociologist) in 1917 and was considered a revolutionary
technique at the time, its author being rewarded for his
contributions to management [13]. Specifically, the
Gantt chart graphically illustrates an activity schedule
that helps plan, coordinate, and monitor project-
specific tasks. It has the form of a matrix with two axes:
a horizontal one indicating the amount of time required
for each activity (with the start and end dates of the task);
and a vertical one, indicating the tasks to be performed.
2.3 Architecture of the Program
The architecture of the application is presented in
Fig. 1.4. The software is developed in the Xcode
programming environment using the Objective-C
programming language. Google’s web and mobile appli-
cation development platform called Firebase was used
for storing and synchronizing the data.
The navigation through the application interfaces
is done through a navigation viewer controller that
contains, after login, a tab bar viewer controller for
managing the other tabs (“statistics” and “my account”).
2.4 Design of the Modules
The application was built on the model presented by
Apple, in which applications must keep a uniform
design, so that the user could see where the applica-
tion’s functions are. The application also follows an
auto-layout, an Apple standard for scaling the app on
any screen size. The application structure is presented
in Fig. 1.5.
The application icon was designed using Adobe
Photoshop CC2017, considering current design require-
ments, the need for fluid integration among other iOS
icons, and the need to be user-friendly (Fig. 1.6). This
is performed vectorally to scale on any device running
an iOS operating system.
The description of the modules is presented in the
next paragraphs.
2.4.1 Logging in module
In order to be able to use the application, the user will
need to log in, which is also the first screen encountered
(start view controller). After logging in from Firebase,
the function that authenticates the user is called, with
the contents of the email and password fields in the
application, and when a response is received from the
server, the user and password are saved in a separate
native file (NSUserDefaults), otherwise they are the
error encountered is displayed.
 CHAPTER 1
FIG. 1.2 Gantt chart (part 1).
FIG. 1.3 Gantt chart (part 2).
The next function will allow the user to use the “Next”
button on the keyboard in order to jump to the next
field, and if it is the last one, the application will “press”
the “LOGIN” button on its own. If the user will press
anywhere else on the screen, the keyboard will disappear.
If the users have an account, they enter their email
and password here. These are saved so that next time
when the users wish to use the application, their login
is made automatically.
2.4.2 Registration module
If the user does not have an account already created, s/he
can register by pressing the top right button, which will
send him/her to the next screen, i.e. the Register screen.
When the user has entered all the required data and
pressed the registration button, the validateInput function
will be called to validate all fields. For a cleaner and
easier way to debug layout, a separate Boolean return
function was used for each validation. The email will
have to contain the “@” and the “.” signs, and the
name and password must contain at least 5 characters.
Mobile Application for Medical Diagnosis 3
Otherwise, the users will see a warning message on
the screen informing them of what they have entered
incorrectly.
In order for the PNC to be considered valid, it must
start with 0 if the user has selected “Male”, or 1 if
“Female” is selected. The selection of the gender is
made by using the two buttons located at the top of
the registration form.
If all these conditions are met, a dictionary contain-
ing the name, PNC, and gender will be created; these
will be created separately from email and password
(encrypted and decrypted by Firebase) in the database
user table. If the registration has been successful, the
user will receive a message on the screen and will be
redirected to the login screen, where the email and
password fields will be automatically filled in.
2.4.3 The human body module
The human body consists of two images: the front- and
rear-view body. Fig. 1.7 represents the male body. When
the user is a woman, the images change.
4 Telemedicine Technologies
FIG. 1.4 Architecture of the program.
For the head we have an interim class that works
according to the same principle, and a separate image
will be uploaded containing only this part, to better select
other related areas (forehead, eye, nose, mouth, chin,
ears). Over the images, buttons have been set with unique
identifiers that are related to the Firebase database.
When selecting a specific area (pressing a button on the
body), it will be shaded to highlight it. This is what
the “setupBodyActions” feature does, which cycles
through the entire collection of buttons, sets them to be
hidden, adds an action that will go to the “goToNextStep”
function and will shade the selected area for better
highlighting.
The goToNextStep function verifies if the user has
pressed the head-marker area (has element_cap as the
identifier) to know which screen to go forward into
(the head seen from the front or back, both having sepa-
rate classes defined), or else it will lead directly to the
symptoms section (QuestionManager ViewController)
for the area that was pressed. The first query is made
in the QuestionManagerViewController class, where
the existing malfunctions are listed. If the user chose
FIG. 1.5 Application structure in Xcode.
FIG. 1.6 Creating the MedicalDiag icon.
 CHAPTER 1 Mobile Application for Medical Diagnosis 7

FIG. 1.7 Division of the body.

the head, where there are several sub-zones, then this
fact will be taken into account when making the query.
Also, this initial query increments the number of hits
for that area.
Once we have the illness chosen by the user, we move
to the QuestionViewController class, which makes a
query, and we take the first set of questions for the cho-
sen illness. Depending on the contents of the “yes” and
“no” keys, we open the same class but with a new query,
and the query path retains its position. This is done
until the “yes” or “no” keys no longer contain dictio-
naries, but values, meaning that that is the diagnosis.
8 Telemedicine Technologies
Next, a new class e DiagnosticViewController - is
presented, which will display the diagnosis in a
scrollable text view next to a doctor contact button.
We also display a button so that the user can return to
the human body page, without having to press “back”
repeatedly. The “contact a specialist” button opens a
native action sheet that gives the user a list of counties
in the country to choose a physician who is closer to
their location. The list of counties is read from a text
file located in the external file folder.
A new class opens, RecDoctorViewController, where
we display the recommended details of the doctor in
the selected county (data read from text files). Here
on the top right corner there is a button where the
doctor can be called directly from the application or a
button that opens a web page containing a list of all
doctors in the country.
2.4.4 My account module
My account gives the user:
• the possibility to change the gender, name and
PNC. It contains the same checks as the registration
module. In order to change the name, PNC, and
gender, a query in Firebase will be taken to retrieve
this data and display it in the corresponding fields
in the application interface.
• the possibility of logging out (removes the email
and password, saves the changes and sends us to the
login screen)
• the possibility to reset the password. The sendPass-
wordResetWithEmail function is called in Firebase,
giving it the current user’s email as parameter, and
when a response is received, the users will receive a
message informing them that the password has been
requested and that they will need to access the reset
link received via email.
2.4.5 The statistics sub-module
The statistics tab makes a query through all parts of the
body in the database, then extracts the “hits” key to
generate a body part dictionary and the number of hits.
To create the pie chart, we use an external library
called AAChartView that helps us build different types
of charts very easily, just by moving the data; it deals
with computing, building and interacting with charts.
In order to populate the chart with the required data
from Firebase (the number of hits for each affected
body part), we created the configChart function that
takes this data from the database as the library expects
(a key and a dictionary value). Each area on the
chart will show the name of the affected area and
the number of hits. This area can be hidden by pressing
the name of the condition in the legend.
2.5 Structure of the Database
Firebase has been chosen because it allows easy access
to in-app data, is easy to scale to a large number of users,
increased security is provided by Google, and APIs are
tailored for mobile systems. The database was designed
with Google’s recommendations for real-time firebase
databases. Its structure is in the form of questions:
• head body part: hits - value, illness (question - value,
answer 1 - value or another dictionary of the ques-
tion&answer1&answer2, answer 2 - value or another
dictionary of the type question&answer1&answer2
• part of the body: hits - value, illness (question - value,
answer 1 - value or another dictionary of the question
&answer1&answer2, answer 2 - answer 2 - value or
another dictionary of the type question&answer1
&answer2
• users: user idcnp - valuesex - valuename - value
The structure of the Firebase database is illustrated
in Fig. 1.8.
3 USAGE OF THE APPLICATION
3.1 Registration Process and Finding a
Presumptive Diagnosis
The first step which is necessary for using the app is regis-
tration. In order to benefit from all of the application’s
utilities, the user has to create an account (Fig. 1.9),
selecting gender (to differentiate body areas and possible
diagnoses) and then filling out a form containing email
address, password, full name and Personal Numeric
Code (PNC).
All these fields will have to be to be completed by
following a set of rules:
The email will have to be in the form of [user] @
[domain]. [TLD], where [domain] is the address of
the website that provides the email service and [TLD]
is the geographic location extension of the domain
(Top Level Domain);
The password must be longer than 6 characters;
The name must be longer than 5 characters;
The PNC will have exactly 13 characters and will have to
begin with the number 1 if the user selected “Male”,
or 0 if they selected “Female” (this rule is available in
Romania, but it can be changed). Otherwise, a
pop-up warning will be displayed specifying what
needs to be corrected. After completing this form
and thus creating the account, the user is redirected
to the Login page, where s/he will enter the email
 CHAPTER 1
FIG. 1.8 Structure of the database.
address and password followed by the “Enter”
button. Once logged in, the human body will be
displayed according to the gender chosen by the two
buttons located at the bottom of the screen: male
and female (Fig. 1.10).
The next step will be to select the affected area from
the human body (differing by gender) by tapping on it.
To make sure that tapping is done exactly in the desired
area, the application will highlight the area with a
Mobile Application for Medical Diagnosis 9
FIG. 1.9 Registration form.
shadow, as it can be seen in Fig. 1.11. The available
body parts are:
• Head e the most complex part of the body; when
selected, the application will zoom in on it to
facilitate easy selection;
• Feet, thigh, knees, fingers, hands;
• Shoulder, arm, forearm, fingers;
• Body: pectorals/breast, hypogastrium, mesogastrium,
epigastrium and genital organs.
After selecting the affected area, the user will select
the symptom (Fig. 1.12) and respond to a set of succes-
sive YES or NO questions, after which s/he will receive a
diagnosis, indicating that this is a presumptive one, and
a medical check is recommended for the diagnosis to be
as accurate as possible.
With the receipt of the presumed diagnosis
(Fig. 1.13), the user will have a button located at the
bottom of the screen, to search for a specialist doctor.
When pressed, the user will be presented with a list of
the country’s 41 counties to narrow searches to the
selected region (Fig. 1.14).
Finally, after displaying the recommended physician
in the selected region, along with his/her address and
phone number, the user can contact him/her via the
button illustrated by a handset at the top right of the
screen.
3.2 Statistics Area
Apart from the above functionalities, the user can
access a statistics area (by clicking on the “Statistics”
10 Telemedicine Technologies

FIG. 1.10 Male body and female body.

tab located in the menu at the bottom of the screen)

where s/he can see with a pie chart, the most affected
areas in all users. Body parts are represented on the
diagram with different colors and when they are
pressed, the number of affected users in the area is
shown (Fig. 1.15).

3.3 Update/Modify the Personal Data

One of the key features of the app is the possibility to
change personal data (gender, name or PNC), this being
done in the “My Account” menu, accessible from the
lower-menu menu bar.
If the user wants to change the password for personal
reasons, the “Change Password” button is pressed
(Fig. 1.16), at which time a pop-up will inform them
that a mail has been sent to their email account with
which they created the account (Fig. 1.17).
In order to complete the password change process, it
will be necessary to access the email link, where the user
will need to enter the new password.
FIG. 1.11 Selection of affected area.
 FIG. 1.12 Symptom list.

FIG. 1.13 Diagnosis. FIG. 1.14 List of counties.

12 Telemedicine Technologies
FIG. 1.15 Affected area percentage.
4 CONCLUSIONS
The MedicalDiag application was built according to the
specifications provided, eventually reaching version
v.1.3.2, bringing new functionalities and improvements
to it during the development. MedicalDiag is available
on any device running the iOS operating system,
designed to diagnose users’ illnesses following a set of
questions.
The biggest challenge of this application was to create
a simpler and more logical structure for arranging ques-
tions, answers and diagnostics. The current solution is
not just “memory friendly”, but also scalable. If one
should want to add one or 100,000 questions later,
this will not affect the application at all. Any element
in the application is scalable and any question, answer,
FIG. 1.16 Changing password.
FIG. 1.17 Email confirmation for changing password.
or diagnosis can be modified without interfering with
the application, all being changed in Firebase.
As an application for a vast domain, it has many
development directions and will be periodically
upgraded, bringing new functionalities and even solv-
ing existing problems. The app will be placed as soon
as possible in Apple’s AppStore, and new features will
be brought to it, such as the ability to contact a physi-
cian in real time with a live chat, or search for it using
the embedded GPS module.
 CHAPTER 1
These two new functionalities are already under
development and another is in plan, namely the possibil-
ity of receiving a diagnosis after uploading a photograph
(if the disease has visual signs, for example varicella).
REFERENCES
[1] R. Ford, J. Wierdermann, The App&mobile Case Study
Book, Indexed edition, TASCHEN, 2011.
[2] W.J. Yi, W. Jia, J. Saniie, Mobile sensor data collector using
android smartphone, in: Circuits and Systems, IEEE 55th
International Midwest Symposium, 2012, pp. 956e959.
[3] A. Székelya, R. Talanow, P. Bágyi, Smartphones, tablets
and mobile applications for radiology, Eur. J. Radiol. 82
(May) (2013) 829e836.
[4] M. Panhale, Beginning Hybrid Mobile Application
Development, first ed., Apress, 2015.
[5] W.J. Yi, W. Jia, J. Saniie, Mobile sensor data collector
using android smartphone, in: Circuits and Systems,
IEEE 55th International Midwest Symposium, 2012,
pp. 956e959. September.
[6] R. Pryss, M. Reichert, J. Herrmann, B. Langguth, W. Schlee,
Mobile crowd sensing in clinical and psychological trials e
a case study, computer-based medical systems, in: IEEE
28th International Symposium, June, 2015.
Mobile Application for Medical Diagnosis 13
[7] R. Pryss, M. Reichert, B. Langguth, W. Schlee, Mobile
crowd sensing services for tinnitus assessment, therapy,
and research, mobile services, in: IEEE International
Conference, August, 2015.
[8] K.F. Braekkan Payne, H. Wharrad, K. Watts, Smartphone
and medical related App use among medical students
and junior doctors in the United Kingdom (UK): a regional
survey, BMC Med Inf. Decis. Mak. (2012) (October).
[9] M.N. Faruk, J. Mallipeddi, An optimal healthcare
self-diagnosis system using cloud framework, in: Interna-
tional Conference On Big Data Analytics and Computa-
tional Intelligence, 2017.
[10] L. Briz Ponce, J. Antonio, J. Méndez, F.J. García Peñalvo,
First approach of mobile applications study for medical
education purposes, in: TEEM ’14, Salamanca, October,
2014.
[11] M.N. Kamel Boulos, A.C. Brewer, C. Karimkhani,
D.B. Buller, R.P. Dellavalle, Mobile medical and health
apps: state of the art, concerns, regulatory control and
certification, Online J. Public Health Inform. 5 (February)
(2014).
[12] L. Csiki, A. Gabor, M. Popescu, A. Naaji, Software applica-
tion for disabled students, Brain 8 (4) (2017) 32e40
(December).
[13] http://www.scritub.com/stiinta/informatica/Ce-este-diagrama-
Gantt1032201711.php, accessed in January 2017.