mDROID - An Affordable Android based mHealth System
Anju Kansal, Avval Gupta, Kolin Paul and Sanjiva Prasad
Computer Science and Engineering, IIT Delhi, Hauz Khas, 110016, New Delhi, India
mDROID, mHealth, Patient Record System, Biomedical Sensors, Medical Data, XML Medical File, Server,
Bluetooth, Android.
This paper presents a novel approach towards the development of a portable, user-friendly and affordable
mHealth System using Android based mobile devices. The Android application captures personal, biometric
and medical data of a patient and combines them to generate an XML based medical record which is then
uploaded to a server. The medical data are gathered from different sensors interfaced to an Arduino UNO
board. The data are then converted into packets, which are transmitted on request to the mobile phone using
Bluetooth. The XML report makes the mDROID system robust for query and inter-operability at the server end
and also for merging with standardized XML based medical repositories. The mDROID system is designed
for use by minimally trained health workers in the field.
Providing affordable and scalable healthcare is one
of the most important development goals, and one
which may pose many technological challenges. Re-
search by Cisco (CVNI, 2013) projects that by the
end of the year 2016, there will be approximately
10 billion mobile devices in use around the world.
mHealth refers to using mobile phone technology in
providing healthcare. In recent years, mHealth has
shown promising growth mainly because of the fact
that it can alter how healthcare is delivered, the qual-
ity of patient experience, and the cost of health care
(Wang and Liu, 2009). The most common activity
in mHealth has been the creation of health call cen-
tres, which respond to patient inquiries. This was fol-
lowed by using SMS for appointment reminders, us-
ing telemedicine, accessing patient records, measur-
ing treatment compliance, raising health awareness,
monitoring patients, and physician decision support.
With advances in technology, wearable sensors
have been integrated with mobile phones for mon-
itoring health. Despite mHealth having several ad-
vantages in personal healthcare, a 2011 global survey
of 114 nations undertaken by the World Health Orga-
nization found that mHealth initiatives established in
many countries have several issues resulting in vari-
ation in adoption (WHO, 2011). mHealth has shown
maximum adoption in developed countries mainly be-
cause mHealth applications for personal health are
available only on high-end expensive mobile phones.
Thus, mHealth has grown in developed countries
whereas it is still at an exploratory stage in under-
developed nations (Mechael et al., 2010).
In developing countries, data are manually col-
lected by community health workers for (rural) Health
Centres. These data are collected in the field and writ-
ten “in rough” on paper. Later, these readings are
manually uploaded onto servers. The various stages
require constant scrutiny to ensure reliability (Otieno
et al., 2012). Manual entry makes the whole system
both cumbersome and vulnerable to human errors.
Moreover, an important aspect of any mHealth imple-
mentation is ensuring that the data are exchangeable.
Existing systems frequently overlook the fundamental
requirements of interoperable data standards (WHO,
All the factors discussed above demand an
mHealth solution which (1) has an automated sys-
tem for collection of medical data by health workers
with minimal training, (2) consists of all basic med-
ical sensors and is yet portable, (3) is affordable for
mass usage in under-developed countries, and (4) col-
lects data in a format that can be easily exchangeable
and usable within heterogeneous systems. The pro-
posed mDROID system has been designed to address
all these aspects keeping in mind the “pain-points” of
community workers. The all-in-one mDROID system
uses an Android based device to capture medical data
through various electronic sensors with ease, com-
Kansal A., Gupta A., Paul K. and Prasad S..
mDROID - An Affordable Android based mHealth System.
DOI: 10.5220/0004803501090116
In Proceedings of the International Conference on Health Informatics (HEALTHINF-2014), pages 109-116
ISBN: 978-989-758-010-9
2014 SCITEPRESS (Science and Technology Publications, Lda.)
Figure 1: End-to-End Data Flow of the mDROID System.
bines them with personal and biometric information
of the patient to form an XML based medical report,
which can be uploaded to the server on request.
Technologies like mDROID will facilitate heath-
care workers in monitoring the health of local popu-
lations at regular intervals, especially at the bottom of
the pyramid, thereby empowering healthcare officials
to track epidemics and take necessary steps to prevent
them. It will also allow policy makers to understand
the correlation between health and environmental fac-
tors and make changes to suit the population of the
The mDROID system is broadly divided into two ma-
jor parts. The first part consists of getting medical
data from various sensors on the Android phone. The
second part involves development of an Android ap-
plication for processing the data received and gener-
ating medical report to be sent to a server. Figure 1
depicts an overview of the data flow from sensors to
the server.
2.1 Obtaining Medical Data from
Sensors to Android Device
The mDROID system supports multiple medical sen-
sors. The system was designed to make the sensors
work efficiently in capturing multiple data simulta-
neously rather than a one-by-one approach, which is
time consuming, inefficient and possibly less reliable.
Concurrent capture is achieved by using an interme-
diate platform that is capable of connecting to mul-
tiple sensors simultaneously and transmitting to the
Android based device. The data from multiple sen-
sors are combined to form packets, which are then
transmitted to the Android device through one of the
connectivity options supported by Android and Ar-
duino. The mDROID system uses Bluetooth as the
mode of communication between the two platforms.
The two main components of the microcontroller pro-
gram are: (1) formation of medical data packets, and,
(2) managing data transmission through Bluetooth.
2.1.1 Formation of Medical Data Packets
The clinical data obtained from the sensors are cate-
gorized into (1) discrete data points, and (2) contin-
uous data streams. The former category comprises
the measurement of discrete physiological parameters
such as temperature, pulse rate, oxygen saturation in
blood etc., whereas the latter covers measuring graph-
ical medical parameters such as ECG, which is re-
quired to be plotted on a graph over an uninterrupted
time interval.
While acquiring the discrete parameters, the mi-
crocontroller program fetches different data points
from multiple medical sensors and couples them to-
gether into data packets. This feature allows all the
sensor data points collected at one time to be trans-
mitted together. Coupling readings from different
sensors makes it possible to correlate the different
physical parameters. Each data packet consists of a
frame start delimiter, end delimiter, sensor identifiers,
sensor data start and end delimiters, and actual sen-
sor data, as depicted in Figure 2. These delimiters
are required because some bytes are often lost dur-
ing transmission in Bluetooth communication. The
packet Start and End delimiters help in distinguishing
complete data packets from incomplete ones, which is
necessary in building a robust system. Sensor identi-
fiers are used to label particular sensors’ data. This al-
lows the mDROID system to form custom data pack-
ets depending on the specific sensors requested by
the user application, supporting flexibility in the set
of sensors used by an application and eliminating the
need for maintaining a fixed sequence of sensors in
the data packets.
The continuous data stream is acquired separately
without coupling the values with any other sensor
Figure 2: Design of Data Packet.
2.1.2 Data Transmission through Bluetooth
The microcontroller program controls what is to be
transmitted and when. The system continuously lis-
tens for a request for a data packet or continuous
stream of data identified by a REQUEST byte. On re-
ceiving a request byte, it identifies whether the request
is for a discrete data packet or a continuous stream
of data. In the former type case, it fetches the val-
ues from the sensors, couples them into a data packet,
transmits the packet to the application, and goes back
to the listening state. In case of a request for a con-
tinuous stream, it starts fetching and transmitting a
stream of values, until it receives a STOP request af-
ter which it goes back to the listening state.
2.2 Android Application
The second major part of the mDROID system con-
sists of the Android application that forms the core of
the system.
Figure 3: Overview of the mDROID Application.
Figure 3 shows a broad overview of the Android
application. The app handles the Bluetooth connec-
tivity with the Arduino UNO board for fetching the
medical data packets/data stream from it.
Depending on the requirement, the app requests
for a data packet or a stream of data from the Arduino
Figure 4: Medical Data Acquisition in Android through
board. In case of data packets, the application de-
composes them to obtain the data of individual sen-
sors. The design of the application allows the data
to be viewed on the application screen individually
or collectively through a pragmatic interface. The al-
gorithm for obtaining the data from a data packet is
depicted in Figure 4.
In case of a stream of data, the application first
sends the corresponding request to the Arduino board,
starts receiving the data stream, plots a graph for a
specific time interval, and sends a stop request to the
board on completion of the time interval.
In addition to medical data from the sensors, the
application also collects personal information of the
patient, viz., name, age, sex, phone number etc.
The application also utilizes the integrated camera
of the device to capture patient image, which serves as
biometric information of the patient. This feature in-
troduces a sense of authenticity to the system in that it
will make it hard for a health worker to forge medical
Once the personal, biometric and medical data
of the patient are obtained, the application combines
them to generate an XML based medical report. The
application also allows for this report to be sent to a
server on network availability, completing the end-to-
end data flow.
The components used in the implementation of the
mDROID system were carefully selected keeping in
mind portability and low power consumption. Also,
special emphasis was paid to design the user interface
of the mobile phone application in such a fashion that
a minimally trained health worker can capture and up-
load data with ease.
3.1 Medical Sensors and Arduino
In the current version of the mDROID system, the
main parameters captured are Body Temperature,
Pulse Rate, Oxygen Saturation, Galvanic Skin Re-
sponse and ECG.
3.1.1 Body Temperature Sensor
The body temperature was captured using a sensor
which has a TMP102 digital temperature sensor at its
kernel. It gives a 12-bit, 0.0625
C resolution and pro-
vides an accuracy of 0.5
C. It can monitor tempera-
ture ranging between -25
C to +85
C. Since this sen-
sor works at a voltage range of 1.4V to 3.6V DC and
provides an easy two-wire serial interface, it works as
a perfect match for mDROID.
3.1.2 Oxygen Saturation and Pulse Oximeter
Pulse oximetry is a non-invasive method for indicat-
ing the arterial oxygen saturation. Oxygen satura-
tion is defined as the amount of oxygen dissolved in
blood. To measure oxygen saturation, two different
light sources with wavelength of 660 nm (red light)
and 940 nm (infra-red light) are used. By measuring
the absorption spectrum of the two light sources, oxy-
gen saturation is measured. The pulse oximeter used
for mDROID system works at 3.3Volts.
Pulse rate measures the average number of pulses
per minute. The pulse rate is obtained from the pulse
oximeter sensor which measures the peak to peak
time interval between the pulses and calculates the av-
3.1.3 GSR - Galvanic Skin Response
GRS is recorded by a sensitive ohm-meter which
measures the electrical conductivity of the skin.
Sweat glands which are under the control of sympa-
thetic nervous system change the conduction level of
the skin with variation in the psychological state of
the person. The sensor for GSR for the mDROID sys-
tem works at 3.3 Volts which allows portability and
can run easily on batteries.
3.1.4 ECG - Electrocardiogram
ECG is one of the most common tools useful to mon-
itor the status of health of the heart. For a detailed
study, a 12 lead ECG is preferred but arrhythmia can
be monitored from a single lead ECG. mDROID is
currently designed to capture a 10 second single lead
ECG data in the form of an image.
The system uses an INA321 instrumentation am-
plifier at the kernel. A second order filter was utilized
to filter the noise and capture the ECG in the monitor-
ing mode (critical band of 0.5Hz - 40 Hz). The data
were sampled at 250 samples per second. These data
are saved in the form of an image in the mDROID app.
3.1.5 Arduino Program
The mDROID system uses the Arduino UNO R3
board. The code is written using the open source Ar-
duino 1.0.4 software. The e-Health Sensor Shield and
e-Health library is used for interfacing the Arduino
board to the medical sensors. RN-42 Bluetooth Mod-
ule is used for the Bluetooth transmission using the
Serial Port Profile (SPP). Any device communicating
through Bluetooth is required to first enter the pass-
code for pairing with the hardware. Once a device
has been paired, it can start communicating.
3.2 Android Application
The mDROID application is developed using the An-
droid SDK 2.3.3 Java platform. Android was cho-
sen for the implementation of the system owing to its
widespread use, affordability, and extendability. The
application supports any device running Android ver-
sion 3.0 and above with Bluetooth 2.0.
There are four major components of the Android
application: (1) obtaining patient information, (2) ob-
taining patient image, (3) obtaining medical data, and
(4) combining all data into a medical report to be up-
loaded to server.
3.2.1 Obtaining Patient Information (Personal
The first component in the patient record system is ob-
taining the general information about the patient. As
soon as the user launches the app, he/she is displayed
a form to be filled on the app. The module collects
the name, age, sex, and phone number of the patient
and performs suitable validations on the data entered
before allowing the user to proceed. The various val-
idations imposed by the system are as follows
All the entries must be filled. No field can be left
Name and Sex can take text values. Age and
phone number should be numeric values.
Sex can take only M or F as values.
Phone number must be 10 digits.
3.2.2 Capturing Image (Biometric Data)
After properly entering acceptable values in the per-
sonal data of the patient, the user is navigated to cap-
ture an image of the patient, which serves as biometric
information of the patient. Once an image is captured,
the user has the option of either capturing another im-
age (if he/she is not satisfied with the current image)
or proceeding to capture the medical data. The latest
captured image is taken into account.
The image name contains the timestamp when
the image was captured and is of the form
“IMG yyyymmdd hhmmss X.jpg”, where X is a ran-
dom number. This allows the image to be uniquely
identified on the server by minimizing the probability
of different image files having the same name.
3.2.3 Obtaining Medical Data
This component is responsible for establishing Blue-
tooth communication with the sensor hardware and
fetching medical data from the sensors. After the per-
sonal and biometric data are successfully acquired in
the application, the user is navigated to proceed to col-
lection of medical data. The user is required to select
The specific choices described below only illustrate
that these data must be checked for conformance to a spec-
ified format
the desired hardware from a list of available Bluetooth
devices to initiate a connection. Once the connection
is established, the user can hit a button to begin the
data exchange with the microcontroller.
The medical data are displayed to the user in the
app. The design of the GUI allows the user to view
all the discrete medical data at once or particular data
individually. Figure 5 shows a screenshot of the An-
droid app. The medical data displayed are the aver-
ages of the latest ve values retrieved from the sen-
sors. Every time a new value is received, the average
is updated and used. The implementation allows cap-
turing of a 10 second ECG of the patient. The ECG
data is plotted separately and is saved as an image.
Figure 5: Screenshot of mDROID App.
3.2.4 Generating XML Record
Medical record generation is another crucial aspect
of the mDROID system. The design of the medical
record is based on XML because of its simplicity of
representation, versatility and widespread acceptance
as a vehicle for information exchange in the modern
This component is used to put all the pieces of the
system together. After the acquisition of desired med-
ical data, the application generates a complete medi-
cal record based on the user session and stores it on
the Android device. A sample medical record gen-
erated by the application is depicted in Figure 6. If
the user wishes, he/she can choose to upload this data
record onto the server.
The xml record along with the captured image file
and ECG image is uploaded on the server, where the
Figure 6: A Sample XML Report Generated by the
images are stored in separate directories. The pa-
tient img and ecg img tags in the xml report contain
the paths of the respective image files on the server.
The portable and user friendly mDROID system is de-
signed to help acquire data of the patients by health-
care workers in the field. The mobile phone based
system helps the health workers in acquiring patient
data without any specialized or intensive training.
The mDROID application automatically converts
all the acquired data of the patient into an XML file,
which is uploaded to the server. XML allows easy
consolidation, transmission and retrieval of medical
records from servers. Moreover, it allows existing
protocols to be used to exchange data among hetero-
geneous systems. The capability of XML to exchange
data among different types of computing platforms
enables disparate back-end systems in healthcare or-
ganizations to work together. The data records gen-
erated by the mDROID system can hence be easily
made available to the care givers and researchers.
Over the recent years, mHealth is increasingly be-
coming a prime focus of the medical commu-
nity, leading to intense work in this field. The
mDROID system presents a simple user interface with
a straightforward workflow to capture the various
health parameters of patients. The choice of plat-
form for the implementation was Android, owing to
its various advantages. Android based devices are
widely used and their availability is rapidly increas-
ing over a broad range of cost and features, lead-
ing to smartphones and tablets being available at very
low prices. According to the International Data Cor-
poration (IDC) Worldwide Quarterly Mobile Phone
Tracker, the Android platform crossed 80% of the
smartphone market share in the third quarter of 2013
(IDC, 2013). Moreover, Android allows for the built-
in utilities of the smart devices to be utilized without
having to design a separate control processor. The
mDROID system is focused on integrating multiple
medical devices onto a single platform making an all-
in-one package for medical data collection. This re-
duces the cost effectively when compared with using
standalone devices for measuring each of the medical
parameters. There are a host of independent medi-
cal peripherals in the market for the iPhone (iPhone
Medical Devices, 2013). However, the cost of an
iPhone as well as these medical add-ons is uneconom-
ical and hence cannot be used as a cost-effective so-
lution for the health workers working at the bottom
of the pyramid. Moreover, all of these individual de-
vices are very specific and cannot be used together
with other sensors in a customisable fashion. The
mDROID system has been designed to collect data
from medical sensors while keeping them separate
from the phone. The use of Bluetooth enables easier
integration of newer sensors as well as replacement of
sensors. This creates a potential for opening up of a
market for many more such affordable sensors. The
mDROID is a novel one-of-a-kind customisable sys-
tem in mobile healthcare. XML based medical reports
add the benefit of portability of medical data across
platforms. Biometric information brings trust and au-
thenticity to the system.
The Swasthya Slate (Health Tablet) developed by
PHFI (Swasthya, nd) is a similar system which works
on Android based tablet phones. It enables the acqui-
sition of clinical data through electronic sensors. The
price of the device costs approximately INR 30,000.
It has a couple of additional sensors such as test for
water quality, which we plan to deploy in our project
in a later stage. However, there is no provision for
capturing patient image and other metadata, or for
the generation of XML based medical reports in the
Swasthya Slate. The mDROID system is more flexi-
ble as it works on all mobile Phones running the An-
droid platform, including the inexpensive ones; the
price for the mDROID device is projected to be more
affordable than the Swasthya Slate.
Another framework for mobile healthcare is the
SANA technology developed at MIT (SANA, 2010).
SANA is a reliable tool that allows health workers
to transmit medical files in the form of text, image,
audio, video etc. through a cell phone to a cen-
tral server for archiving and incorporation into an
electronic medical record, and to a remote specialist
for real-time decision support. The prime focus of
SANA tool is to transmit the medical information to
the reach of various stakeholders in the healthcare do-
main. However, there is no support in SANA for uti-
lizing electronic sensors within the mHealth system,
and the user is required to feed the data manually into
the Android application making the application prone
to human errors.
Open Data Kit (ODK, 2009) is a framework for
building user interfaces, collecting data on mobile
devices, and aggregating them onto a server. The
ODK framework supports generic interfaces for a
class of sensors, both internal and external to an An-
droid device, although at the time of implementa-
tion of mDROID, these were not released for pro-
duction. While ODK has been used in some health-
related projects, it is not clear to what extent the type
classes of discrete and continuous medical data can be
supported in the systematic manner we have outlined
This comparative analysis suggests that mDROID
promises to be a more effective tool for health work-
ers when collecting data, with authentication, at the
bottom of the pyramid in developing countries. While
the data authenticity is not foolproof, it offers some
level of confidence that the data was genuinely cap-
tured and not forged.
The mDROID system described in this paper relies on
external sensors for obtaining clinical data and is tar-
geted to be operated by non-experts. The next steps
involve providing a framework that can attest to the
provenance of the data collected. The current system
captures the biometric data in the form of patient im-
age, which is not being cross-verified. Future work
involves implementation of sub-systems for acquisi-
tion and verification of biometric information of the
patient as well as the health worker. Further analy-
sis of the system reveals that the clinical data is sent
over a Bluetooth connection to the Android device
and then over a network to the server, both of which
can act as points of network vulnerabilities. This re-
quires investigation of ways to safeguard the privacy
of the medical data over any transmissions. Addi-
tionally, the current system supports a limited range
of medical sensors which are being extended to sup-
port more varieties of sensors, thereby providing a
complete low cost and efficient mHealth data acquisi-
tion system. Further, the current system works using
Bluetooth connectivity. Future scope involves sup-
porting more connectivity modes, viz., Wi-Fi, Zig-
Bee, USB, etc. Currently, the uploaded records are
sent to a small server designed for storage purposes
in XML format. The future work involves support-
ing the server with openEHR standards, and adding
functionalities for extraction and exchange of medi-
cal data from the server. Also, cloud-based solutions
can be used for storing and analyzing medical data
This work has been partially supported from the
DeitY (MCIT, Government of India) funded project
RP02597 “Foundations of Trusted and Scalable ‘Last
Mile’ Healthcare”. The fourth author also acknowl-
edges support from a Microsoft Research grant for
precursors to this work. The authors would like to
thank Mr Vijay Kumar for assistance with configur-
ing the hardware. Dr Shelly Dutta of Sahyog pro-
vided valuable information about the work routines
of healthcare workers in rural Rajasthan.
CVNI (2013). Cisco visual networking index: Global mo-
bile data traffic forecast update, 2012-2017.
IDC (2013). Idc worldwide mobile phone
tracker, august 7, 2013 press release. http://
iPhone Medical Devices (2013). 5 Medical de-
vices with the iphone. http://internetmedicine.
Mechael, P., Batavia, H., Kaonga N. andSearle, S., Kwan,
A., Goldberger, A., Fu, L., and Ossman, J. (2010).
Barriers and gaps affecting mhealth in low and middle
income countries. A Policy White Paper commisioned
by The mHealth Alliance.
ODK (2009). The open data kit.
Otieno, C., Kaseje, D., Ochieng, B., and Githae, M. (2012).
Reliability of community health worker collected data
for planning and policy in a peri-urban area of kisumu,
kenya. Journal of Community Health, 37:48–53.
SANA (2010). The sana project.
Swasthya (n.d.). Swasthya slate of public health foundation
of india.
Wang, H. and Liu, J. (2009). Mobile Phone Based Health
Care Technology. Recent Patents on Biomedical En-
gineering, 2:15–21.
WHO (2011). mhealth: New horizons for health through
mobile technologies. Global Observatory for eHealth
Series, 3.
WHO (2012). Management of patient information: Trends
and challenges in member states. Global Observatory
for eHealth Series, 6.