ProntAPP: A mobile question answering application for medicines

Luis Miguel Mancilha de Almeida Martins de Jesusluisjesus@ist.utl.pt

Instituto Superior Tecnico, Lisboa, Portugal

November 2015

Abstract

We have been witnessing an increased amount of medical data that is available online. Such datais accessed not only by medical staff but also by patients, and the public in general. However, withthat much data, it has become increasingly difficult to search for the correct answers we are lookingfor in a specific situation. ProntAPP is an Android and iPhone mobile application that aims at ful-filling this gap with a question-answering system in Portuguese for medicines. In this document, wedescribe the main features of ProntApp, we present the current state-of-the-art of the medical domainquestion-answering systems, web-based systems and mobile applications for medicines, its architectureand the implementation decisions. Finally, we describe the experimental evaluation that we conductedto validate ProntApp and the results obtained, and draw some final conclusions.Keywords: mobile application, question-answering system, medicines, voice recognition

1. Introduction

More and more medical information is becomingavailable on the web (e.g., Medscape1, Epocrates2,etc.). Both medical staff and common users needto access this information efficiently. However, withthat much information, it has become increasinglydifficult to search for the correct answers we arelooking for in a specific situation. For example,when a user searches on Google ”What are thecontra-indications of Vastarel?”, the answer con-sists of a list of search hits, meaning that the an-swer is not answered immediately. There are severalweb-based medical systems that present detailedmedicine information for certain medical questions(e.g., Infarmed3, Medscape). However the questionsare usually keyword-based, therefore they must beposed with limited search terms so that the systemis able to answer. Medical professionals are usedto search for medicines with very specific keywordsand terms. Contrarily, the common user is not thatfamiliar with such terms. In addition, the com-mon user may not be a computer expert, and mayhave some difficulties using such keyword-based in-terfaces. These interfaces should be available forusers in a more convenient and ever-present way,taking advantage of the new technologies and gad-gets, and therefore enabling more users to accessthe information they need, exactly when it is con-venient for them.

1http://www.medscape.com/2http://www.epocrates.com/3http://www.infarmed.pt/

Currently, the most popular gadget in the worldis clearly the smartphone; as a matter of fact, suchdevices are becoming more and more popular. Itis estimated that, by 2017, at least 34% of theworld’s population will own a smartphone, a fastincrease with respect to 9.6% in 20114. In terms ofthe Portuguese market, 55% of the country’s entirepopulation owns a smartphone, 5 and this numberis rapidly increasing. We believe that it is of ut-most relevance to have information about medicinesavailable on a smartphone. This enables to offer ac-cess to such information anywhere, in a convenientway, and taking advantage of many of the smart-phone’s unique features.

1.1. Objective

The main goal of this thesis is to develop a mobileapplication, named ProntAPP, to answer questionsabout medicines in Portuguese. This application isintended to be used by the common user, includ-ing elder people, as well as medical staff. How-ever, elder people are not the most proficient smart-phone users. Additionally, we had the opportunityto gather some feedback with some medical doctorsto find out how they would use such an application,and the most important features that the applica-tion should have, in addition to answering medicalquestions. From their feedback, we came to the con-

4http://www.statista.com/statistics/203734/global-smartphone-penetration-per-capita-since-2005/

5http://www.telecompaper.com/news/smartphones-take-55-of-handset-market-in-portugal–965938

1

clusion that medical doctors deal with the same setof medicines on a regular basis, and would benefitfrom having them easily and rapidly accessible inthe application. In addition, they proposed that,since the application is also targeted to the com-mon user and elder people, there should be somekind of reminder to take the medicines in due time,with options to control the type of dosage, amount,and several hours of the day.

1.2. RequirementsTaking the target users and their limitations intoaccount, and also the feedback that we gatheredfrom medical doctors, the application must fulfillthe following requirements:

• R1. Users must be able to pose naturallanguage questions about medicines in Por-tuguese, and thus should not be limited tokeyword-based questions.

• R2. The information about medicines that isreturned as an answer must be as detailed aspossible.

• R3. Users must be able to search for whatthey need with a simple interface (e.g., usinga speech recognition interface), and in a smallamount of steps.

• R4. The application should provide easy accessto frequently used medicines.

• R5. The application should remind the userto take their medicines in due time with theability to choose the type of dosage, amount,and several times a day.

• R6. The application must be available in alarge number of mobile devices, ranging fromlow-end to high-end devices, and running dif-ferent operating systems.

Currently, medical mobile applications availablefrom Google Play, and the App Store do not fulfillthis set of requirements. In particular, most appli-cations are only available in English, and do not of-fer a question-answering functionality. In addition,only eMed.pt offers an alarm functionality, howevera very basic one (without the ability to set multi-ple hours per day). We provide more details aboutsuch solutions in Chapter 2.

1.3. Proposed SolutionIn order to satisfy the set of requirements mentionedabove we developed two mobile applications, onefor Android and one for iPhone, which present thefollowing set of features:

• Data about medicines: ProntAPP provides itsusers with vast information about medicines,such as contra-indications, pricing and dosage.

• Question-Answering for medicines in Por-tuguese: ProntAPP recognizes Portuguese nat-ural language questions. It also lets userssearch for the information they need by posingspoken questions to the system, and by search-ing for keywords.

• Online server communication: ProntAPPleverages on the computational power of on-line servers to perform highly intensive tasks,like voice recognition and natural language pro-cessing.

• Voice recognition: To further facilitate theuser’s input, ProntAPP provides a voice recog-nition interface.

• Favorites: ProntAPP has a favorite medicineslist, so they are easily accessible. The user canadd a medicine to their favorites list, and alsoremove it.

• Alarm: ProntAPP has the ability to set alarmsfor medicines, with the ability to choose dosagetype, amount and multiple hours per day. Thisalarm system reminds the user to take hismedicines in due time.

• Large Number of Supported Devices: The de-veloped mobile applications support 96% of allAndroid devices6 and 84.2% of all iPhone de-vices.7

1.4. Contributions

As a result of this thesis, two native mobile ap-plications were developed: one for Android andone for iPhone. The applications will be availablefor download on Google Play and AppStore. Themain features of these applications are the abilityto answer natural languages in Portuguese aboutmedicines, voice recognition using Google’s voicerecognition and Nuance Dragon, the ability to adda medicine as a favorite and the ability to add arepeating alarm for several hours of the day for agiven medicine. This application is the only onecurrently available that has this functionalities, be-ing innovative in its field.

Furthermore, the question-answering mod-ule of the application was implemented usingMedicineAsk. In order to do this, we had to dosome major code refactoring in the online versionof MedicineAsk in order to develop an API sothat the question-answering functionality couldbe accessed from outside clients (Android andiPhone).

6https://developer.android.com/about/dashboards/index.html7https://david-smith.org/iosversionstats/

2

2. Related WorkThis section presents several systems that are rel-evant and related to ProntAPP. First, we compareMedicineAsk[6][3] and MEANS[1], two question-answering systems that support Natural Languagequestions. Second, we compare Epocrates, Med-scape, Drugs.com and eMed.pt which are mo-bile applications that provide information aboutmedicines. Finally, we present the state of theart in terms of voice recognition systems for mo-bile applications. In particular, we discuss Googlesvoice recognition system. CMU Sphinx, and Nu-ance Dragon, and draw some conclusions.

2.1. Comparison of question-answering systemsMedicineAsk and MEANS are two question-answering systems for medicines. Both systemsare able to provide an answer to Natural Languagequestions about medicines and active substances.There are some differences between MedicineAskand MEANS. MedicineAsk uses Infarmed’s web-site as its information source, while MEANS usespublicly available resources. The method usedby MedicineAsk for answering the questions is byquerying the extracted information using SQL. Onthe other hand, MEANS annotates the processeddocuments in RDF[4] to build a graph traversedto answer queries using SPARQL[2]. MedicineAskcan answer questions about medicines, active sub-stances and what they treat. MEANS has a broaderscope, answering questions about medicines, activesubstances and what they treat, who should takemedicines and differences between diseases identifi-cation. Finally, MEANS supports questions in En-glish, while MedicineAsk supports questions in Por-tuguese.

2.2. Comparison of voice recognition systemsIn this section, we present the state of the art interms of voice recognition systems. In particu-lar, we discuss Google’s voice recognition system8,CMU Sphinx, developed at Carnegie Mellon Uni-versity9, and Nuance Dragon10.

Google’s and Nuance’s voice recognition is notopen-source, therefore they cannot be modified inany way. CMU Sphinx is open-source with a BSDLicense, which imposes minimal restrictions on theredistribution of the software. Both Google’s voicerecognition system and CMU Sphinx’s are availablefor free, while Nuance’s is free only up to 20,000transactions per month, charging $.008 per trans-action after that. Google’s voice recognition sys-tem and Nuance’s is available for the Portugueselanguage while CMU Sphinx does not yet supportPortuguese language (however the system can be

8http://developer.android.com/9http://cmusphinx.sourceforge.net/

10http://developer.nuance.com/

trained). Both Google’s voice recognition and Nu-ance’s is performed online servers (cloud speechrecognition), therefore they are only available ifthe client is connected to the network, while CMUSphinx’s voice recognition is performed locally.

2.3. Comparison of existing medical mobile appli-cations

In this section we compare medical mobile ap-plications. In particular, we make a compari-son between Epocrates, Medscape, Drugs.com andeMed.pt, which are the mobile versions of their re-spective web-based counterparts.

All of the above mentioned applications are avail-able for Android and iOS. The eMed.pt applicationis the exception in terms of language, since it is theonly mentioned application with information in inPortuguese. All applications are available to down-load and use for free, however Epocrates and Med-scape have a paid subscription with more function-alities. Offline use is possible in all applications ex-cept for Drugs.com which is only available if the de-vice is connected to the network. Keyboard-basedsearch is also supported by all applications, how-ever none of them supports natural language searchor speech recognition. Epocrates, Medscape andeMed.pt have a local database on the device which isdownloaded from an online server, while Drugs.comdoes not. Drugs.com and eMed.pt are the onlyapplications developed natively for the operatingsystems, being developed in Java (native program-ming language of Android) and Objective-C (na-tive programming language of iOS). Both Epocratesand Medscape are hybrid applications developed inHTML.

2.4. Discussion

Since neither of these applications fulfill the set ofrequirements listed in Section 1, we propose a mo-bile application, named ProntAPP, which fulfillsthem. This application will use MedicineAsk forthe question-answering system since it is the mostadvanced available in Portuguese. In terms of voicerecognition, we will use Google’s voice recognitionfor the Android mobile application and NuanceDragon voice recognition for the iOS mobile appli-cation, since they are the most advanced in theirrespective operating systems. Although Epocrates,Medscape, Drugs.com and eMed.pt present detailedinformation about medicines, they fail to meet ourrequirements of being able to answer natural lan-guage questions in Portuguese, having easy accessto frequently used medicines, an alarms function-ality (except for eMed.pt) and neither of these hasa voice recognition system, hence the need for thedevelopment of ProntAPP.

3

3. Proposed SolutionProntApp features an online architecture, whichmeans that its main functionalities are only avail-able if the user is connected to the Internet. Wehave chosen this architecture because it is quitepopular in mobile applications nowadays, and fur-ther facilitates further ports of the mobile applica-tion to other operating systems, since all the mainbusiness logic is stored server-side. Furthermore, wecan leverage on the computational power of onlineservers to perform intensive tasks, like voice recog-nition.

There are two databases in ProntAPP: (1) oneavailable online in the question-answering onlineserver, which we refer to as online database and(2) one local database available offline in the mo-bile client application, which we refer to as of-fline database. The online database stores allthe medicines data, active substances, interac-tions, medical conditions, etc. This informationis only available in the online database. The of-fline database is only present in the mobile clientapplication, and only stores the information aboutmedicines added to the favorites list, and about thealarms configured by the user.

Figure 1: The architecture of ProntApp.

The architecture of ProntAPP is represented inFigure 1. ProntAPP works on a mobile phonewhich runs the mobile client application. The mo-bile client application is divided into three layers:the Presentation Layer, the Business Layer and theData Layer. The Presentation Layer provides auser interface where the input of the applicationis specified (e.g. form inputs, buttons, etc.) andits output is shown (e.g. tables, text, etc.). Italso contains the presentation logic which showsthe data in the native user interface of the oper-ating system (i.e. in the case of Android, this logicmeans displaying the data in Android’s views). ThePresentation Layer communicates with the Busi-ness Layer when a user interacts with the ap-plication. The Business Layer contains all thelibraries that ProntAPP uses. In particular, itmakes the necessary requests to perform the voice

recognition (which is performed in online servers),question-answering processing (performed in an on-line server) and business logic (e.g. alarm function-ality, favorites logic, server communication).

When the user accesses its Favorite medicinesor the Alarms, the Business Layer requests datafrom the Data Layer. The Data Layer stores thelocal database, handles all the database commu-nication using data access components (i.e., SQLConnectors), and converts the data returned by thedatabase into structures that can be handled by theother layers, with database helpers which performthe mapping from SQL cursors into structures.

As mentioned above, an offline database is storedin the mobile client application. Since the searchfunctionality is only available if the user is online,we found that it was not necessary to store a copyof the online database on the client application.Therefore, the local database only stores informa-tion about the favorite medicines, not all medicines.When a user adds a medicine as a favorite, all theinformation is fetched and stored for offline use.The local database also stores information aboutthe alarms scheduled by the user. The online serverprovides an API that the mobile application usesfor the question-answering functionality, via HTTPrequests.

4. Implementation

In this section we describe the implementationprocess of ProntAPP. We start by presenting thechosen target mobile operating systems, Androidand iPhone, and our reasons. Next, we presentthe question-answering module. In particular, thechanges made to the MedicineAsk system and theimplementation of the API. We proceed by dis-cussing the databases of ProntAPP (online and of-fline). Next, we describe the implementation ofthe voice recognition module, and the implemen-tation of the alarms and favorites functionalities.We present the main libraries used in our devel-opment process and lastly we present and discusssome screenshots the final user interface.

4.1. Target Mobile Operating Systems

There are three main markets in terms of mobile ap-plications: Android, iOS and Windows Phone. InPortugal, Android and iPhones take the majorityif the market share.11 Therefore, we believe thatthese are the mobile platforms that must be priori-tized. Accordingly, ProntAPP was developed as anAndroid and an iPhone native mobile application.

11http://www.telecompaper.com/news/smartphones-take-55-of-handset-market-in-portugal–965938

4

4.1.1 Android

If we analyze Android versions’ market distribu-tion,12 we see that approximately 99.3% of Androidsmartphones are on version 2.3.3 (Android SDK10) or above. Therefore, the application was de-veloped to work on devices with the Android SDK10 or above. The application is developed in Javalanguage, using Android’s SDK. We use a typi-cal Model-View-Controller [5] software architecturesince it is the standard when developing Androidmobile applications.

Regarding the voice recognition functionality,ProntApp uses Google’s voice recognition, since itis the most advanced voice recognition system avail-able in Portuguese, and has great support and toolsfor integrating the system with mobile applications.The user interface is implemented using native An-droid views, provided by the Android SDK. Fur-thermore, the voice recognition module is imple-mented using Google’s Speech Recognizer. Thequestion-answering module is implemented by ac-cessing the new MedicineAsk’s API using an An-droid software library called RetroFit. In addition,the local database is an SQLite database and is ac-cessed through an Android software library calledActiveAndroid. These software libraries are betterdescribed in Section 4.6.1.

4.1.2 iPhone

Approximately 86% of Apple devices are on iOS8.0 or higher13 (which means iPhone 4S or bet-ter). Therefore, this is the operating system ver-sion that most developers target, since they canmake use of new features of XCode like Auto-Layoutand adapt their design to multiple screen densities.Consequently, ProntApp was developed to work ondevices with iOS version 8.0 or higher (includingiPads, although the design is not adapted to tabletdevices). The application is developed in Objective-C, using the iOS SDK. Like on Android, we usea typical Model-View-Controller software architec-ture since it is the standard when developing iPhonemobile applications. The iPhone application wasdeveloped by the standard iOS design guidelines,meaning that the design was not a direct port fromthe Android version.

Regarding the voice recognition functionality,ProntApp uses Nuance Dragon Mobile SDK. It isthe most advanced voice recognition system avail-able in Portuguese for iPhone. This voice recogni-tion, like Google’s, is processed on online servers.

The user interface is implemented using nativeiOS views, provided by the UIKit Framework in

12https://developer.android.com/about/dashboards/index.html13https://developer.apple.com/support/app-store/

the iPhone SDK. Furthermore, the voice recogni-tion module is implemented using Nuance MobileDragon SDK. The question-answering module is im-plemented by accessing the new MedicineAsk’s APIusing an iOS software library called RestKit. Inaddition, the local database is an SQLite databaseand is accessed through an iOS software librarycalled FMDB. These software libraries are betterdescribed in Section 4.6.2.

4.2. Question-Answering Module

The question-answering module used by ProntAPPis the same used in MedicineAsk. A major partof the development process was the adaptation ofMedicineAsk to work in other interfaces, other thansimply retrieving HTML. Most mobile operatingsystems support the display of HTML, however wewanted to have more control over how the datais presented, and not simply display the retrievedHTML, which resulted in the development of anAPI, so that the mobile client applications can re-trieve the response, process it, and display it in itsown native user interface, like they were communi-cating directly with the database.

The MedicineAsk system is very coupled with theweb-interface (meaning that the code related to userinterface, business logic and database accesses inenter-twined). Therefore, one of the challenges tomodifying this Question-Answering module was toseparate the presentation logic from the processinglogic, so that we could change the data format re-trieved by the Question-Answering module.

In particular, an endpoint was exposed throughthis API called analyze. This endpoint accepts aGET request with a query parameter with the user’squestion. After MedicineAsk’s NLI and NLP anal-ysis and database retrieval this endpoints retrievesthe data in a JSON format. This JSON response isthen parsed on Android and iOS by their respectivelibraries and displayed on screen using native views.

In addition to the analyze endpoint anotherendpoint was exposed called alarm quantity typeswhich retrieves a JSON response with the alarmquantity types and dosages available for schedulingalarms in ProntAPP’s alarm functionality.

These modifications allowed us to have the samesource code of MedicineAsk running on the web(essentially keeping MedicineAsk’s website intact)to also be used by the mobile applications. Thisapproach will also facilitate further updates to theQuestion-Answering module, since any updates tothe MedicineAsk’s NLI and NLP modules are trans-parently updated and used by the mobile applica-tions, without any need of changes to the mobileapplications’ source code.

5

4.3. DatabaseIn this section, we discuss the implementation ofboth the online database and the offline databases(iPhone and Android).

4.3.1 Online Database

We wanted to enhance the alarms functional-ity with some features, like choosing the typeof medicine dosage and type (e.g. Take 1/2Pill), therefore we had to extend this databasewith two new tables called alarm quantity type andalarm quantity option. The alarm quantity type ta-ble stores the type of alarm quantities (i.e. pill, ap-plications) while the alarm quantity option storesthe options for each type (i.e. 1 pill, 1/2 pill, 3/4pill). The alarm quantity option table stores a for-eign key to the alarm quantity type so that we caninfer the options of each type.

4.3.2 Mobile Application Databases

The local database present in both the Android andiPhone mobile applications is in the SQLite format.Althougo both Android and iPhone provide classesin their SDK to access the database, we chose touse some software libraries. In the case of An-droid, we chose to use an ORM (Object-relationalmapping) library to further facilitate this data ac-cess and storage. The software library we choseto use is ActiveAndroid and is further describedin Section4.6.1. The iPhone SDK provides devel-opers with a standard, near-transparent interfaceto a database file called Core Data. With CoreData, an app can define a database schema, cre-ate a database file, and create and manage recorddata. In the case of iPhone, we chose to interactdirectly with the database with a software librarycalled FMDB. The reasoning for this choice was theease of use of FMDB in relation to Core Data (sinceCore Data is intended to larger projects), since thedeveloper can easily provide their own SQL queriesand parse the data from SQL cursors directly. Thelocal database stores all the information relative tothe favorite medicines, and also stores informationabout the alarms.

4.4. Voice Recognition Module4.4.1 Android

Google provides an API to Android developers tofacilitate the integration of mobile applications withits voice recognition system. The Android SDKcontains a class called Speech Recognizer.14 Thisclass provides access to the speech recognition ser-vice, which is an Android service which enables ac-cess to the speech recognizer. All the voice recog-

14http://developer.android.coml

nition is performed on Google’s servers, since it isa heavy task to perform on smartphones, and thereis no publicly available SDK announced by Googlefor using this service offline.

4.4.2 iPhone

For the Voice Recognition Module on iPhone, wechose to use the Nuance Dragon Mobile SDK whichfeatures the SpeechKit Framework. The SpeechKitframework is a high-level framework with two ma-jor components for developers: the speech recog-nizer and the text-to-speech synthesizer. For theVoice Recognition Module, we only used the speechrecognizer. SpeechKit follows a server-based archi-tecture and relies on the Nuance speech server forvoice recognition and text-to-speech synthesis. Forvoice recognition, the SKRecognizer class sends au-dio streams to the server which then returns a listof text results.

4.5. Alarms and FavoritesIn this section we explain how we implemented boththe Alarms and Favorites functionalities in the An-droid and iPhone applications.

4.5.1 Favorites

When a user is viewing the medicine detail andtaps the favorite icon, a query is made to thelocal database using ActiveAndroid on Androidand FMDB on iPhone. This query verifies if themedicine is already present in the favorites tableor not. If it is not present, a dialog is presentedasking the user to confirm if he wants to add themedicine to the favorites. If the user confirms, anew row is inserted in the favorites table in theSQLite database storing all the information aboutthis medicine. If the medicine is already present inthe favorites table, a dialog is presented asking theuser to confirm if he wants to remove the medicinefrom the favorites. If the user confirms the action,the row is deleted from the SQLite database. Whenthe user enters the favorites screen, a query is madeto the local database and all the rows of this tableare then presented in an Android ListView using acustom Adapter, or in an iPhone UITableViewusing custom UITableRowCells.

4.5.2 Alarms

When checking a medicine’s information, the usercan schedule an alarm by pressing the clockicon. This icon opens a custom dialog. Be-fore the dialog opens, a web-service call is madeto the alarm quantity types endpoint to retrievethe possible dosage types and amounts. Thealarms are scheduled using native alarm managers

6

(AlarmManager for Android and UILocalNoti-fication for iPhone). Alarms based on these nativealarm managers give a way to perform time-basedoperations outside the lifetime of the application. Inour approach to this, when a user schedules, for ex-ample, a repeating Monday and Wednesday, two re-peating alarms are scheduled with a repeat intervalof one week. These native alarm managers them-selves do not show the notifications that ProntAPPpresent, they simply trigger a callback. This meansthat we had to implement our own callback whichfires a notification when it is triggered.

4.6. Software LibrariesIn this section we present the main libraries usedin the development of the mobile applications anda brief description of all of them, providing insightson their value to mobile software developers.

4.6.1 Android

The software libraries dependencies in Android weremanaged by using Gradle’s 15 built-in dependencymanagement system. Gradle is an advanced buildtoolkit that manages dependencies and is integratedinto Android’s development IDE, Android Studio.In particular, the libraries used were:

• Retrofit: a type-safe REST client for Androidbuilt by Square. It was used to communicatewith MedicineAsk’s API and retrieve the nec-essary JSON responses from the server.

• ActiveAndroid: an active record style ORM(object relational mapper). It was used to ac-cess the local SQLite database containing infor-mation about favorite medicines and alarms.

• Butterknife: an annotation helper that helpsdevelopers to instantiate the views from our ac-tivity or fragment. It was used to eliminate allthe boilerplate code and make the code simplerand easier to read and maintain.

4.6.2 iPhone

The software libraries dependencies in iPhone weremanaged by using CocoaPods dependency manage-ment system, a dependency manager for Swift andObjective-C Cocoa projects. Although it is not di-rectly integrated into iPhone’s development IDE(XCode) like Gradle is integrated into Android’sdevelopment IDE (Android Studio), this is a musthave when a developer wants to integrate severaldifferent libraries, developed by other users, intotheir own iOS application. In particular, the li-braries used were:

15http://gradle.org/

• RestKit: a framework for implement-ing RESTful web services clients on iOS.This library was used to communicate withMedicineAsk’s API and retrieve the necessaryJSON responses from the server.

• FMDB: an Objective-C wrapper aroundSQLite. This library is used to access the localSQLite database containing information aboutfavorite medicines and alarms.

• MLPAutoCompleteTextField: a librarywhich manages a drop down table of autocom-plete suggestions that update as the user types.This library is used to implement the auto-complete functionality when typing a questionin the search box.

• Nuance Dragon Mobile SDK: a librarywith features like speech recognition and text-to-speech functionality. We use this library toimplement the voice recognition functionalityin iOS.

• ActionSheetPicker: an iOS library which al-lows a user to select from a number of im-mutable options. This is used to present thedosage types and quantities in the alarms sec-tion.

4.7. User Interface

In this section, we present and discuss the final userinterface of ProntAPP in both the Android and theiPhone versions.

4.7.1 Main Screen

The main screen of the Android application is pre-sented in Figure 2. This screen of the applica-tion provides a tab-based navigation throughoutthe main sections of the application: search, fa-vorites and alarms. On the Android version thetabs appear on the top of the screen and on theiPhone version the tabs appear on the bottom ofthe screen with icons, following both platforms userdesign principles and guidelines. In both platformsa help message is presented with instructions to theuser, before performing a question. This message isalso shown if there are no results for a given search.

Figure 2 presents the user interface after a search.In the blue rectangle with white letters the applica-tion notifies the user of the question that was under-stood. Below that, a list is presented with sectionsfor each active substance and a list of medicines.

The results list is clickable and, when a user se-lects an item from the list, he is presented with themedicine detail screen.

7

Figure 2: Main Screen after performing a question

4.7.2 Medicine Detail Screen

The Android’s medicine details screen is presentedin Figure 3. The screen presents the user with infor-mation about the medicine, in particular it showsthe name of the medicine, the laboratory, the price,if the medicine is a generic or not, farmaceuticalform, grouping, comparticipation and PMU. On thetop of the screen, a user can add the medicine to itsfavorites (or remove it) by pressing the heart icon,or he can add an alarm by pressing the clock icon.When a user clicks the clock icon, he is presentedwith the add alarm dialog.

Figure 3: Medicine Detail Screen

There are no particular differences between thesescreens in Android and in iPhone, other than somerecommended spacings. Also, in the iPhone ver-sion a back button is present on the screen since itis considered a good practice and iPhones do nothave a physical back button. On Android, a usercan return to the previous screen by pressing thephysical back button of his device.

4.7.3 Add Alarm Dialog

The Android’s add alarm dialog is shown in Figure4. This dialog is presented when a users clicks theclock icon in the medicine detail screen in order toadd a new alarm for a given medicine. In the top ofthe dialog a user can select the type of dosage (i.e.,

pill, oral solution, etc.) and the quantity. Next,he can select if the alarm should repeat weekly anddays. In the bottom of the dialog, the user can addmultiple hours for the alarm.

Figure 4: Add Alarm Screen

There are some differences in the implementationand user experience of this screen in Android and iniPhone. In Android, the types of dosage and quan-tities are presented in dropdown lists called Spin-ners. In iPhone, there is equivalent for this usercontrol. Therefore, we had to use the software li-brary ActionSheetPicker in order to present a list ofselectable options. In addition, we also used this li-brary to select the hours, while in Android the hoursare selected through a native DateTimePicker di-alog.

4.7.4 Alarms List Screen

The Android’s alarms list screen in shown in Figure5. This screen is acessible by clicking the Alarmstab in the main screen. In this screen, a list ofscheduled alarms is presented. The user can togglethem on or off, and when the alarm is disabled adialog appears asking the user if he also wants toremove the alarm from the list.

Figure 5: Alarms List Screen

There are no particular differences between thesescreens in Android and in iPhone, since we wereable to use similar user controls in both platforms.

8

5. Results

This section describes the experiments we con-ducted to evaluate the ProntApp mobile applica-tion. The evaluation was divided into two parts: us-ability evaluation and server load evaluation. Theobjective of the usability evaluation evaluation isto help us understand our targeted audience andensure that the application is fulfilling the user’sneeds. On the other hand, the objective of theserver load evaluation is to ensure that the serveris handling the users request properly, and also todetect bugs that may emerged during the develop-ment phase.

5.1. Usability Evaluation

In order to evaluate the usability of the developedapplication, we have collected the feedback from 26users, ranging from common people to medical staff,which have answered a survey. The questionnairewas organized in such a way that the users fill in thefirst two sections of the questionnaire (which givegeneral information about gender, age and experi-ence), and then they were asked to interact withthe application (iOS or Android) in order to per-form three scenarios. No help was given during thattime. Finally, the users were asked to fill the thirdand fourth sections of the questionnaire describingtheir opinion and impressions regarding the appli-cation.

From our 26 users, 96.2% of them stated thatthey found the application useful and that theywould download it to their phone. Only 3.8% ofusers said that the application was not useful at alland would not download it.

Thirteen users found that the application wouldbe useful in other operating systems. In particu-lar, 72.7% think that Windows Phone would be asuitable platform for ProntAPP, while 18.2% thinkthat ProntAPP should be developed for BlackBerrydevices in the future.

Users had some concerns regarding the colorsused in the separators, stating that the color con-trast is not very good. A bug was found on iPhones6 that prevented the users from adding an alarm.Furthermore, a user stated that he did not knowthe meaning of some acronyms, so this should beexplained in the application in the help section.

Our tests proved that the features that we addedto the application were interesting to our users andproven to be useful. The majority of our usersthought that the favorites functionality and thealarms functionality were very useful.

Some users also gave us some insights in terms offeatures that they want ProntAPP to have in thefuture. In particular, some users thought that hav-ing a map with the location of nearby pharmacieswould be very useful.

5.2. Server EvaluationThe tests were performed against the server’sRESTful API. We used the Gatling Stress tool16

to perform the load tests.To achieve reliable feedback, we created a sce-

nario for each of the two different requests: a userperforming a natural language search (which werefer to from now on as ”natural language sce-nario”) and a user performing a keyword-basedsearch (which we refer to from now on as ”key-word scenario”). In the natural language scenario,the question performed was: What are the contra-indications of Paracetamol? (Quais so as contra-indicaes do Paracetamol), while in the keyword sce-nario the search as simply Paracetamol. These testswere made with 1 user, 5 simultaneous users and 10simultaneous users.

The server is hosted on Amazon Web Services’Elastic Cloud Service (EC2) running on an EC2small instance with 2GB RAM and 1 vCPU, whilethe database is hosted on Amazon Web Services’Redundant Data Storage (RDS) running on an RDSsmall instance as well.

With 1 user our server handled the requests aswe expected. In the natural language scenario, theserver took 877ms to answer the request, while ittook the server 1969ms to answer the request on thekeyword scenario. With 5 requests, we started tonotice that the server was not handling concurrentrequests properly. This was even more noticeablewith ten requests, since the server was simply re-ceiving all the requests and answering all of themat once, basically multiplying the answer time.

Figure 6: Summarized Results of Server Load Tests

A summarized comparison of the average re-sponse time can be found on Figure 6, which clearlydemonstrates a scalability issue on the server (in redthe keyword scenario, in blue the natural languagescenario), and an exponential trend more noticeableon the keyword scenario.

Our server load tests detected without a doubtthat the server is not handling concurrent requestsproperly. The causes for this may be many: an un-intended database lock while answering a request, abad implementation of database queries (i.e. mak-

16http://gatling.io/

9

ing multiple queries instead of JOIN queries orpreloading the queries) or others.

6. Conclusions

In this document, we have proposed the develop-ment of ProntAPP, a mobile question-answeringsystem for medicines. We started by presentingthe objective, requirements, a brief summary ofour proposed solution and contributions. In Sec-tion 2, we reviewed the most relevant question-answering systems for medicines, existing Androidand iOS medical mobile applications and state-of-the-art of voice recognition systems. Section 3 de-scribed ProntAPP’s architecture and its main com-ponents. In Section 4 we presented the implemen-tation of ProntAPP. And finally, in Section 5 wedescribed the experiments conducted to validateProntAPP and the results obtained.

As a result of this thesis, two native mobile ap-plications were developed: one for Android andone for iPhone. The main features of this appli-cation are the ability to answer natural languagesin Portuguese about medicines, voice recognition,the ability to add a medicine as a favorite and theability to add a repeating alarm for several hoursof the day for a given medicine. This application isthe only one currently available that has this func-tionalities, being innovative in its field.

Furthermore, the question-answering mod-ule of the application was implemented usingMedicineAsk. In order to do this, we had to dosome major code refactoring in the online versionof MedicineAsk in order to develop an API sothat the question-answering functionality couldbe accessed from outside clients (Android andiPhone).

6.1. Future Work

We have identified some limitations with the mo-bile applications of ProntAPP and mainly with theonline server. In particular, these are the points inwhich we think ProntAPP could be improved:

• Server Scalability: Our stress tests to theserver detected that the server is not scalingcorrectly, which means that it is not handlingconcurrent requests properly and may be aproblem if the applications are used by mul-tiple users.

• Pharmacies Location: A feature that wouldbe very valuable to add to the current versionof the mobile applications of ProntAPP wouldbe the location of nearby pharmacies.

• Windows Phone Support: From our ques-tionnaire we gathered that several people wantthe application to be available for Windows

Phone. This means that a native applicationin C could be developed for Windows Phone.

• Tablet Support: ProntAPP was developedfor Android and iPhone smartphones, not tak-ing into account the user interface of tablets.The applications could benefit from having auser interface specifically designed for tablets.

• User Interface Improvements: From ourquestionnaire we gathered some small user im-provements that could be made in both ver-sions of ProntAPP, namely: (1) The word”mapped” is not very familiar for a regularuser, and should be replaced for a more famil-iar one; (2) The intention of the icon used toshow that an alarm in the alarms is a repeatingalarm is not very clear, and therefore it shouldbe replaced; (3) The search box should have aclear button so that a user can delete all thetext easily.; (4) The color contrast in the sepa-rators is not very clear, and should be changed.and (5) A list of acronyms and their meaningcould be added to the help section.

References[1] A. B. Abacha. Recherche de rponses prcises

des questions mdicales: le systme de questions-rponses means. (in french). Universit Paris-Sud,2012.

[2] A. B. Abacha and P. Zweigenbaum. Medicalquestion answering: Translating medical ques-tions into sparql queries. ACM SIGHIT Inter-national Health Informatics Symposium (IHI),2012.

[3] L. C. Helena Galhardas, Vasco D. Mendes.Medicine.ask: a natural language search systemfor medicine information. INForum, 2012.

[4] G. Klyne and J. J. Carroll. Resource descrip-tion framework (RDF): Concepts and abstractsyntax. World Wide Web Consortium, Recom-mendation REC-rdf-concepts-20040210, 2004.

[5] G. E. Krasner, S. T. Pope, et al. A descrip-tion of the model-view-controller user interfaceparadigm in the smalltalk-80 system. Journalof Object Oriented Programming, pages 26–49,1988.

[6] L. C. Ricardo Ferro, Helena Galhardas. A ma-chine learning based natural language interfacefor a database of medicines. Data Integration inthe Life Sciences (DILS), 2014.

10