Evaluation of Cross-Platform Development Tools for Patient Self- Reporting on Mobile Devices

Proceedings of the 8th Australasian Workshop on Health Informatics and Knowledge Management (HIKM 2015), Sydney, Australia, 27 - 30 January 2015 Evaluation of Cross-platform Development Tools for Patient Self- Reporting on Mobile Devices

Hyung Jin Kim1 Sudara Karunaratne1 Holger Regenbrecht2 Ian Warren Burkhard Claus Wunsche3 1 Department of Electrical and Computer Engineering University of Auckland, Auckland, New Zealand, [email protected], [email protected] 2 Department of Information Science University of Otago, Dunedin, New Zealand, [email protected] 3 Department of Computer Science University of Auckland, Auckland, New Zealand, [email protected], [email protected] Abstract to empower health consumers to better manage and monitor their health, e.g., by proving self-reporting tools. Western societies are aging rapidly and novel solutions A recent survey found that 75% of physicians believe must be found to make healthcare more effective and that patient self-tracking is tied to better health outcomes affordable. One step towards this goal are mobile (Manhattan Research 2013). Self-reporting provides applications for patient self-reporting. The tools healthcare professionals with improved monitoring data, provide healthcare professionals with improved whereas patients benefit from a reduced number of doctor monitoring data, whereas patients benefit from a visits and improved diagnosis and interventions. So far reduced number of doctor visits and improved diagnosis self-tracking data is obtained primarily using low-tech and treatment. In order to make self-reporting tools as methods, such as patient handwriting the data accessible as possible they must be affordable, easily (Manhattan Research 2013). accessible, and easy to use. Smartphones are an ideal In order to make self-reporting tools effective they platform for patient self-reporting tools, but must be affordable, accessible, and easy to use by both development is made complicated by the lack of patient and doctors. Smartphones are an ideal platform standardised operating systems and development for patient self-reporting tools, since they are frameworks. In this paper we evaluate popular cross- readily available, already in widespread use, very platform mobile application development tools. They affordable (< 50 US$ for entry level Android devices), are evaluated against a generalizable simple patient and many patients are already familiar with their self-reporting application scenario called interface. It has been demonstrated that “Feelometer”. We show that PhoneGap is currently smartphones are able to deliver health improvement one of the most suitable technologies for that purpose. interventions to traditionally hard-to-reach It creates applications of similar look and feel as populations (Agarwal & Lau 2010). natively developed applications. However, memory Development of mobile applications is made usage and application startup time are worse than for complicated by the lack of standards associated with natively developed applications and not all necessary healthcare applications, and the lack of standardised functionalities for telehealth applications are operating systems and development tools. In order to supported. maximise usefulness a self-reporting tool should run on Keywords: cross-platform development, mobile all common mobile phone operating systems. A web- applications, patient self-reporting, mHealth based interface might appear to be an easy solution, however, is not practical since it limits access to certain 1 Introduction mobile phone functionalities and would only be available The healthcare systems in many developed countries are when an Internet connection exists. under pressure due to an increasing number of elderly Over the past few years several cross-platform people and more chronic diseases affecting them (World development tools for mobile applications have emerged. Health Organisation 2006, Machlin 2009). One approach In this paper we evaluate popular cross-platform mobile to make healthcare more effective and more affordable is application development tools by using as example a ______simple patient self-reporting tool called “Feelometer”. Copyright © 2015, Australian Computer Society, Inc. This Section 2 reviews current popular cross-platform paper appeared at the 8th Australasian Workshop on Health development tools for mobile applications. Section 3 Informatics and Knowledge Management (HIKM 2015), summarises previous work evaluating cross-platform Sydney, Australia, January 2015. Conferences in Research and development tools and mobile applications for self- Practice in Information Technology (CRPIT), Vol. 164, reporting. Section 4 presents a requirement analysis, Anthony Maeder and Jim Warren, Ed. Reproduction for which is used to motivate the design and implementation academic, not-for profit purposes permitted provided this text is of our solution presented in section 5 and 6, respectively. included. We evaluate different implementations of our application

55 CRPIT Volume 164 - Health Informatics and Knowledge Management 2015

in section 7. We conclude our research in section 8 and 2.1.1 RhoMobile Suite give an outlook on future work in section 9. RhoMobile is a set of products for cross-platform development, consisting of Rhodes for application 2 Background development, RhoConnect for remote integration with Mobile applications can be developed in three servers, RhoHub for application deployment and different ways (Smutny 2012): RhoGallery for application management. Rhodes is  Native apps are written for the target platform created using a single code-base written in HTML, using the programming language and tools that are JavaScript and CSS and uses native applications to supported by the platform. For example, native improve end-user experience. Rhodes is open source Android apps are written in Java while native and can be used via a browser with a hosted Integrated iOS apps are written in Objective-C. Natively Development Environment (IDE) or locally with developed apps are fast and reliable and have standard IDEs. Applications can be compiled into access to all of the device’s features. The look Java bytecode for Blackberry or into Ruby 1.9 and feel of native apps also provides a familiar bytecode to be used in all other platforms. One major experience to the users of the platform. The disadvantage of RhoMobile is that it is not very well drawback of writing apps this way is that the documented compared to other tools. Ruby is also a app is made to only work on the platform it is language that we have never used before and as such it written for. would be expected there would be a learning curve. RhoMobile also does not have access to the device’s  Web apps are generally a condensed version of a web page to fit on a small screen. This means that Accelerometer which is a useful feature for the they will run on any modern mobile browser “Feelometer” application scenario. regardless of platform. They are built using web 2.1.2 PhoneGap technologies such as HTML5, CSS and JavaScript. Because web apps are not distributed by the app PhoneGap is a mobile application development frame- store and are instead hosted on a server, updates work, which enables development using web-based can be deployed more easily without an update languages such as JavaScript, HTML5, and CSS3. download from the app store. However, web apps Native device capabilities can be accessed via plug- lack the ability to access native device features, ins. PhoneGap applications are hybrid: the UI is limiting the amount of functionality they can have. rendered via web views, but the applications have access to native device APIs and are packaged as apps  Hybrid apps are a compromise between web and for distribution and not accessed through the web. The native apps. These apps are developed using web underlying technology behind PhoneGap is known as technologies and then embedded into a native Apache Cordova. PhoneGap is free and openly licensed container. The HTML content is rendered by the under Apache 2.0. device’s browser while the native container The PhoneGap Build service allows uploading of provides access to native platform features. These web-code to the Adobe cloud service to be compiled apps are quicker and cheaper to build than native into targeted mobile OS implementations such as iOS, apps and only a portion of native code needs to be Android, Windows Phone, Blackberry 7, webOS and re-written to make the app work on a different Symbian. platform. They also support a wider range of Reported disadvantages of PhoneGap are that the device functionality than web apps. The drawbacks free developers’ license has limitations, that the of this approach are that the reuse of the user generated code is not as fast as native code, and that it interface means that apps will not have the native does not support the Cappuccino Web Framework for look and feel unless native UI code is written for creating advanced Web applications. each platform. Hybrid apps also suffer in performance compared to native apps because they 2.1.3 DragonRad run on the device’s browser. DragonRad is a database driven cross-platform 2.1 Cross-platform Development Technologies development tool with a unique twist. Using a drag- and-drop GUI for application development, DragonRad In recent years a number of cross platform development tools have emerged. Academic projects facilitates integration and synchronization of database offer many innovative new ideas. For example, Meads systems with native mobile functions. It is composed of and Warren presented “OdinTools”, a visual language a designer, host and client. The host can be run on for developing intelligent mobile services (Meads & Linux or Windows Server, and establishes a connection Warren 2011). Dickson presented “Cabana”, a web- with a mobile device for data communication. The based tool for cross-platform mobile application client behaves like a native application on device. development suitable for introductory computer DragonRad also has an emulator which can run and science courses (Dickson 2012). However, we found that most tools resulting from academic research lack debug applications, with an online compilation tool. A depth, stability, a sufficiently large user community, major drawback is that the DragonRad commercial and documentation. We therefore review in this license costs US$ 4900 per developer per year. A free section only the most popular commercial and open 30-days trial version is available. source projects.

56 Proceedings of the 8th Australasian Workshop on Health Informatics and Knowledge Management (HIKM 2015), Sydney, Australia, 27 - 30 January 2015

2.1.4 MoSync  Launch time: It is important that an app is MoSync is a full SDK with libraries, runtimes, device responsive. profile database and compilers developed by the Testing was done on both an emulator and on real Swedish company MoSync AB. Applications are built hardware to confirm that performance didn’t differ on in MoSync with C/C++ or in combination with a real smartphone. The emulator ran Android 2.2 while the real device used was a low-end Huawei Ideos HTML5 and JavaScript, then targeted at a device X3 running Android 2.3.3. The Procrank utility was profile using GNU Compiler Collection (GCC) and used to measure the unique set sizes (the amount of Pipe-tool, MoSync’s code transformation engine. The memory unique to the process) of the test apps. These MoSync platform can also access parts of the native values were measured using only the emulator because UI system on Android and iOS devices. MoSync has a the Procrank utility is unavailable on real dual license scheme, a commercial license for closed smartphones. source applications and an open source GPL version 2 The authors found that code produced with Illumination had the smallest size and fastest launch license for open source applications. MoSync is well time compared to native code. PhoneGap and MoSync documented, however, it does not have access to the performed slightly worse, whereas RhoStudio and Accelerometer API which is important for many Titanium created code with significantly larger launch healthcare applications (Dhillon et al. 2012). time and package size. The authors criticise all current XMTs with regard to support for platform-specific 2.2 Titanium user interface and user experience requirements and they conclude: “Todays XMTs are merely suited for Titanium is a cross-platform development tool developing cross-platform applications, which impose released by Appcelerator Inc. It supports iPhone and modest demands on CPU power and memory resources, Android based mobile applications as well as other do not rely on cutting edge technologies, and do not platforms. Titanium uses JavaScript, HTML and CSS make high GUI demands.” (Ohrt & Turau 2012). along with other web technologies and the Titanium Dhillon and Mahmoudhis introduce a framework for API to develop applications. Titanium is an evaluating the features, performance and developers’ interpreted application cross-platform development experience of cross-platform mobile application tool, what this means is that the application code is development tools (Dhillon & Mahmoud 2013). The deployed to the mobile device and then interpreted at authors suggest that user interface intensive tasks runtime across different platforms. Appcelerator has favour Titanium or Air whereas simple applications also released its own IDE called Titanium Studio for would be best developed on PhoneGap to reach the development of Titanium applications. widest audience. Heitk¨otter et al. designed criteria to assess cross- 2.3 Illumination platform development approaches, and used them to The Illumination Software Creator is a visual compare Web apps, apps developed with PhoneGap and programming environment for cross platform Titanium Mobile, and natively developed apps development. Applications are built using a drag-and- (Heitk¨otter et al. 2012). The authors conclude that drop user interface which enables arrangement of PhoneGap is preferred, but Titanium makes it easier to “building blocks” which describe functionalities. The create user interfaces which resemble native apps. building blocks are connected to structure the flow of Palmieri et al. compare four popular cross-platform the application. The software creates native code: tools: Rhodes, PhoneGap, DragonRad and MoSync Objective-C for iOS and Java for Android devices. (Palmieri et al. 2012). The authors score the Rhodes The license model is currently donation based. tool highest because it supports both web-based services and the MVC framework. However, the 3 Related Work authors identify for all tools some distinct advantages: PhoneGap offers a wrapper that works 3.1 Evaluation of Cross-Platform Mobile with several IDEs; MoSync supports the greatest Application Development Tools number of programming languages and APIs across JavaScript and C/C++; and DragonRad has its own Ohrt and Turau recently conducted a study on the IDE with extensive features and drag and drop GUI performance of apps created with Cross Platform for developers to design, develop and install mobile Mobile Tools (XMTs) (Ohrt & Turau 2012). The applications. authors evaluated a simple app that consisted of one Regenbrecht et al. developed the Android-based screen with a small text label and a default icon, self-monitoring application IBDsmart and evaluated it developed with each tool. Each app was then compiled with patients suffering from inflammatory bowel for Android in release mode. The study used these diseases (Regenbrecht et al. 2014). They found a high apps to compare the XMT produced code with a native acceptance of their questionnaire-based application, Android implementation using the following three but had to lend Android smart phones to patients, performance metrics: because many patients did not own compatible  Application package size: A lower file size phones. improves the time required to install the app.  Required RAM: Lower RAM usage means that more apps can run concurrently.

57 CRPIT Volume 164 - Health Informatics and Knowledge Management 2015

3.2 Smartphone Self-Reporting Applications Based on the specification, analysis of the literature, We could not find any examples of cross-platform and discussions with users we derived the following mobile self-reporting tools. All papers we found requirements. developed native code for one platform only. 4.1.1 Functional Requirements An example is the “Personal Health Monitor application” (PHM), which offers real-time health  The application should run on iOS, Android and monitoring using wireless sensors and a Windows Windows platforms with different screen sizes. mobile phone. No implementations for the iPhone  The application requires access to the phone’s and Android phones are offered. Intended for patients accelerometer or gyroscope to detect tremors. with Cardiac problems the PHM performs Cardiac  The application should be able to process data on Rhythm Monitoring for several weeks in a normal the client side and give feedback if necessary. environment to collect data. Unlike our “Feelometer” application the PHM is more specialised to cardiology  The application should be able to store data patients, requesting data input after exercises and locally. remote monitoring of vital signs (Gay et al. 2009).  The application should use a peer-to-peer User feedback is obtained using predefined answers, architecture due to restrictions in installing non- which users can select by pressing the associated approved software in a hospital environment, and button on the touch interface. Patients can upload their because of restrictions in storing confidential monitoring data to a web-interface, which healthcare patient data. professionals can use to monitor patients remotely.  The application should vibrate for time triggered Hicks et al. present an application for Android events. phones, which allows researchers to create customised surveys (Hicks et al. 2010). The smartphone application  The application should be able to read a collects the data, server software manages deployment configuration file specifying patient specific and acts as a central repository for data, and a questionnaires and answers. dashboard front-end can visualise incoming data in  The application should be able to send emails via real-time. SMTP. 4 Requirements Analysis 4.1.2 Non-functional Requirements 4.1 Specification  The application should be responsive to user inputs, providing visual or auditory feedback to We want to develop a cross-platform mobile input within 1 second. smartphone application, which supports patient self- reporting. The to-be-developed app should allow for  The application should be reliable and always be voluntary user input as well as for requested input. available regardless of Internet connectivity. All data should be time-stamped and stored locally on the phone. A function should allow the transmission of  The application should require minimal training the data to the medical practitioner via SMTP in and should be easy-to-use, especially when machine and human readable formats. patients are distressed. We do not want a client-server architecture due  The system should be robust and provide constraints involving storing of confidential patient understandable feedback to errors. data, and due to restrictions in installing non- approved software in a hospital environment. Consultation with  The application should maintain the integrity, medical professionals suggested that the graphical user security, and privacy of patient data (see also peer- interface could look like illustrated in Figure 1. to-peer architecture). The functional and non-functional requirements for “Feelometer” cover a wide and practical range of standard challenges with which mobile self-reporting tools are faced. They also share some commonalities with general health monitoring in sports exercise or quantified self-data gathering and reporting. We would argue that any mobile self-reporting application fulfilling these requirements is likely to succeed in fulfilling its specific requirements too. Our results Figure 1: Paper prototype of the GUI for the presented in section 7 are hence relevant to developers “Feelometer”. of other mobile health applications. An important component is the configuration file, 5 Design which allows the medical user to specify the type, timing, and possible answers for questions asked. The 5.1 Tool Selection configuration file might also contain information on Based on the requirements analysis it was determined how the information is displayed to the medical users, that the XMT for “Feelometer” requires support for e.g. labelling emails with different priorities depending accelerometers, file management, vibration and on the patient answers. Internet connections. Titanium, PhoneGap, MoSync

58 Proceedings of the 8th Australasian Workshop on Health Informatics and Knowledge Management (HIKM 2015), Sydney, Australia, 27 - 30 January 2015 and RhoMobile support all these functionalities 6.2 PhoneGap version (Falk2013). However, Titanium currently does not support Windows, and does not have a free developers’ PhoneGap development was also performed through license. Taking into account non-functional the Eclipse IDE, however the layout of the screens was requirements eliminates MoSync, due to its high implemented through HTML files, and the main memory requirements and slow responsiveness (Ohrt functionality through JavaScript files. Creation of & Tu- rau 2012). In order to make the final decision new screens is performed by binding a button to a between MoSync and PhoneGap we evaluated the function which opens a new HTML file - this is how available documentation and community support. Both tools have good documentation; however, we the question screen is invoked. Buttons and text fields found that the developer community for PhoneGap are created through the HTML files, however was much more active and provided more useful positioning of these elements is performed manually information, e.g., about platform independent without an in-built GUI editor. The email sending communication tools. The results are consistent with function is implemented similarly to the Android the literature review in subsection 3.1. version, however a plug-in was created to interface between the native device and PhoneGap, thus the 5.2 System Design email function is performed almost entirely natively. The application consists of three components; the configuration file, the output file sent by email, and 6.3 User Interface Comparison the graphical user interface. The GUI consists of two Figure 2 shows the start screen of the “Feelometer” for screens, the main menu and the question screen. The the native Android implementation (left) and the question screen consists of multiple pages (dependent PhoneGap implementation compiled for Android on the number of questions), since a scrollable screen (right). The GUI of the native Android version was requires PhoneGap’s native plug-in support. predominantly developed using the graphical layout The configuration file, which allows a healthcare builder that is built into Eclipse. For the PhoneGap professional to specify the type, timing and possible version we manually arranged the UI elements using answers for the questions asked is a simple text file HTML code and CSS. In contrast to the Android which the application will access through the native version the PhoneGap version doesn’t have density device’s File API. It will consist of a “Feelometer” independent pixels and instead requires CSS media version verification line, the email address of the queries for screen size responsive design. Hence the medical practitioner, the user ID of the patient, and a application’s buttons in figure 2 have slightly different list of questions together with possible answers and size; and for phones with different screen resolutions dates/times when the patient survey will be the native Android version scales more easily. conducted. The output file will display the “Feelometer” version data, user ID, and machine readable answer data to be later translated into human readable format. 6 Implementation We implemented a prototype using PhoneGap, compiled it for Android, and compared it with native Android code. This enables us to perform preliminary performance comparisons to get an overall feel of the differences between a cross-platform developed application and a natively developed application. The prototypes are intended to have a bare minimum UI, two screens, mock questions, and the ability to send an SMTP message. Both implementations are designed to be visually exact. 6.1 Android version Android development with the Eclipse IDE allows Figure 2: The start screen of the “Feelometer” for creation of UI elements via an in-built GUI editor with the native Android implementation (left) and the the Android layout XML file. Using this, buttons and PhoneGap implementation compiled for Android text-fields were created. Creation of new screens is (right). performed with invocation of an Activity, with the question screen invoked upon selection of the Enter 7 Results Data button. Binding a button to a function is Benchmarking was performed using a Galaxy S2 phone, performed through the Java classes, with the sending an LG Google Nexus 4 phone, and the Eclipse virtual of mail via SMTP function implemented through the device emulator on an i5 2467M dual core CPU extension of the javax.mail.authenticator abstract class (3MByte cache, 2.3 GHz) with emulator RAM size of and a private email address created for the purpose of 256 MByte and targeted at Android version 4.2.2. testing. Similarly to (Ohrt & Turau 2012) we evaluated the

59 CRPIT Volume 164 - Health Informatics and Knowledge Management 2015

application start-up time, package size, and required patients. For instance, in Regenbrecht et al. (2014) the memory. collected data via the mobile phone application is sent Start-up time was measured with two stopwatches directly to the health professionals (nurse, consultant), by computing the average time of seven trials. Memory matched against the patient data stored in the hospital usage was acquired with the Dalvik Debug Monitor system, and action been taken if necessary. Also, the Server (DDMS) through the Eclipse IDE to calculate availability of real-time data on the patient’s health allocated memory size for the emulated device. opens up improved ways of diagnosing patients’ Figure 3 depicts the start-up time of the progress. We have presented requirements for such an “Feelometer” application using different devices and application, and analysed different development implementations. It can be seen that the native Android options. implementation always has a significantly lower start- We showed that a cross-platform, mobile smartphone application is most suitable for such a purpose, and that PhoneGap is currently the most suitable development tool. We implemented the “Feelometer” application both with PhoneGap and natively on Android. We compared the implementations and found that the PhoneGap implementation has a considerable higher start-up time, package size, and memory requirement. However, all parameters were still within the acceptable range for our prototype. Figure 3: Start-up time of the “Feelometer” application using different devices and 9 Future Work implementations. Cross-platform, mobile health monitoring application up time than the PhoneGap implementation. development will change the way on how we collect However, the start-up time for the PhoneGap and monitor health data, will increase the reach of implementation is only slightly more than 1 second for health care by augmenting primary care in hospitals both tested Android smartphone, which is still with community and home environments and will al- considered acceptable. low for new ways for diagnosis and intervention. The more devices and platforms can be targeted the more people can be reached. In future work we want to implement the “Feelometer” application natively on Windows and iOS, and compile the PhoneGap implementation for these platforms. Together with the Android implementations, that will give us six different implementations to compare. In addition we want to evaluate the usability and look-and-feel of the resulting implementation, e.g., email functionality, and readability, layout and responsiveness of user interface components such as buttons. In order to make the evaluation more interesting we want to improve Figure 4: Application package size and required functionality and design of the “Feelometer” RAM for the PhoneGap and native Android application. implementation of “Feelometer”. 10 References Figure 4 depicts the application package size and Agarwal, S. & Lau, C. T. (2010): Remote health required RAM for the PhoneGap and native Android monitoring using mobilephones and web services. implementation of “Feelometer”. It can be seen that Telemedicine and E-Health 16(5):603–607. the application package size of the PhoneGap Dhillon, J. S., Ramos, C., Wu¨nsche, B. C. & implementation is only about 50% larger than the Lutteroth, C. (2012): Leveraging consumer sensing native implementation. However, the RAM devices for telehealth, in Proceedings of the 13th requirements are more than three times as much. For International Conference of the NZ Chapter of the our simple test application that is acceptable since ACM’s Special Interest Group on Human- modern Smartphones have 1 GByte and more system Computer Interaction (CHINZ ’12)’, ACM, 29-35. memory. However, for more complex telehealth Dhillon, S. & Mahmoud, Q. H. (2013): An evaluation applications this increased memory requirement could framework for cross-platform mobile application development tools, in Proceedings of the 2013 IEEE quickly pose problems. Second International Conference on Mobile Services, IEEE Computer Society, 47–54. 8 Conclusion Dickson, P. E. (2012): Cabana: a cross-platform Immediate self-reporting on the current state of mobile development system, in Proceedings of the physical or psychological well-being can be a very valuable tool for medical practitioners to diagnose

60 Proceedings of the 8th Australasian Workshop on Health Informatics and Knowledge Management (HIKM 2015), Sydney, Australia, 27 - 30 January 2015

43rd ACM technical symposium on Computer Science Education (SIGCSE ’12)’, ACM, 529–534 Falk, M. (2013): Mobile frameworks comparison chart. http://www.markus-falk.com/mobile-frameworks- comparison-chart/, Last retrieved 24th August 2013. Gay, V., Leijdekkers, P. & Barin, E. (2009): A mobile rehabilitation application for the remote monitoring of cardiac patients after a heart attack or a coronary bypass surgery, in Proceedings of the 2nd International Conference on Pervasive Technologies Related to Assistive Environments (PETRA ’09), ACM, 21:1–21:7. Heitk¨otter, H., Hanschke, S. & Majchrzak, T. A. (2012): Comparing cross-platform development approaches for mobile applications, in WEBIST, SciTePress, 299–311. Hicks, J., Ramanathan, N., Kim, D., Monibi, M., Selsky, J., Hansen, M. & Estrin, D. (2010): Andwellness: an open mobile system for activity and experience sampling, in Wireless Health 2010, ACM, 34–43. Machlin, S. R. (2009): Trends in health care expenditures for the elderly age 65 and over: 2006 versus 1996, medical expenditure panel survey. Manhattan Research (2013): Taking the pulse u.s. 2013. http://www.clinical-innovation.com/topics/clinical- practice/study-physicians-welcome-patient-self- tracking. Meads, A. & Warren, I. (2011): Odintools–model- driven development of intelligent mobile services, in Proceedings of the IEEE International Conference on Services Computing (SCC 2011), 448–455. Ohrt, J. & Turau, V. (2012): Cross-platform development tools for smartphone applications, Computer 45(9):72–79. Palmieri, M., Singh, I. & Cicchetti, A. (2012): Comparison of cross-platform mobile development tools, in Proceedings of the 16th International Conference on Intelligence in Next Generation Networks (ICIN 2012), 179–186. Regenbrecht, H., Langlotz, T., Ho, C., George, M., Gray, A., Walmsley, R. & Schultz, M. (2014): Field test of a questionnaire-based mobile health reporting system, in Proceedings of OzCHI 2014. [Accepted for publication]. Smutny, P. (2012): Mobile development tools and cross-platform solutions, in Proceedings of the 13th International Carpathian Control Conference (ICCC 2012), 653–656. World Health Organisation (2006): Factsheet no. 302- the global shortage of health workers and its impact. http://www.who.int/mediacentre/factsheets/fs302/en/pr int.html.