Design of a Data Container for mhealth Apps

Design of a Data Container for mHealth Apps Sandro Speth† , Johannes Schnapper‡ , David Michel♠ , Alexander Frank∇ , and Jonas Thiel

Figure 1: Health Data Storage in the Course of Time Abstract— The amount of digital data concerning health is constantly growing. As mobile devices such as smartphones or tablets are becoming more powerful, the so-called mHealth Apps - i.e. apps dealing with medical data - are on the rise. These apps collect, connect and evaluate various health data in order to improve people’s health situation, to make the doctors’ work more efficient and to save both money and time. The crucial part of mHealth is the storage of highly sensible health data, reaching from simple data such as blood pressure values to complex treatment plans and medications. Therefore, it is necessary to have a storage component that deals adequately with patients’ health records. In this paper we want to determine the requirements a data container has to fulfill and present a data model for such a container. Additionally, we present an application that uses our storage component in order to assess the data container. Index Terms—mHealth, eHealth, Privacy Management Platform, Android, Medical Data Storage

1

I NTRODUCTION

As a matter of fact, health gains more and more significance in today’s society. The conventional treatments go to the limits of their capacity, and they consume way too much money. On top of this, the amount of patients that a single doctor has to treat increases, as the population grows faster than the number of doctors. That is why new ways of treatments and health provision have to be found, which consume less resources, i.e., money and time. Along with always being available, this is the main motivation to encourage mHealth. This promotion can be observed in the United States, as Obama’s Government tries to improve the medical service. Therefore it is hardly surprising that many companies creating mHealth applications are located in the United States. The general idea is digitalizing the health data of all patients in order to save time and money [9]. Over time storing data in time- and space-consuming ways like file cabinets got replaced by storing data on local computers, but this only solves the space-consuming aspect. In order to tackle the timeconsumption, the data is stored in cloud systems more and more, making it easier accessible for different parties. This development is depicted in Figure 1. In the future it is unlikely for doctors to store their patients’ data only on isolated office system within their doctor’s office. The different doctors have to be connected with each other, share their knowledge and data concerning patients and also enable patients to have a look at their health record themselves. Another important aspect is encouraging the patients to collect data themselves using different electronic devices and this way relief the doctors. It could even be made possible to automatically run analyses when the patient updates his/her values. Therefore it is vital to store health data from different sources into a single database, which should be as generically designed as possible. Due to the fact that mHealth is constantly gaining importance, a huge market with a volume of several billion dollars already developed. The forecast for the next few years is even more astonishing as shown in Figure 2. Numerous developers implemented their own applications and the

Health is one of the, if not the most important topic that humans have to deal with. From its beginning on, technological progress tried and continually tries to improve various aspects of human health. With the rise of mobile devices which are constantly connected to the Internet, completely new facets in terms of providing and supporting people’s health and a healthy lifestyle emerged. Mark Weiser predicted the ubiquitous presence of smart electronic devices in all aspects of human life over twenty years ago [19]. Considering that the application fields where new technologies come into play are almost countless, this paper specializes on the area of so called „eHealth“, more precisely „mHealth“. G. Eysenbach defines eHealth as „an emerging field in the intersection of medical informatics, public health and business, referring to health services and information delivered or enhanced through the Internet and related technologies“ [5]. The term mHealth defines a special aspect of e-health, where mobile devices such as tablets and smartphones are used [7] . However, mHealth proves to be a huge field itself. The most important areas of mHealth usage are education, awareness, remote data collecting, remote monitoring, communication and training for healthcare workers, disease and epidemic outbreak tracking, diagnostic and treatment support and many more [4].

† Sandro Speth [email protected]

‡ Johannes Schnapper [email protected]

♠ David Michel [email protected]

∇ Alexander Frank [email protected]

 Jonas Thiel [email protected]

1

• Services to store and manage collected data, e.g. the Microsoft Health Vault service. • Holistic services which make it possible to collect, transfer, manage and evaluate data. These systems consist of a Server, applications running on the frontend and a way of communication between those two. Some examples of these systems will be presented and discussed in the following. 2.1

Frontend Applications - Candy Castle

The main idea behind Candy Castle [17] is motivating children suffering from diabetes to constantly check their blood sugar level (BSL). This is achieved by making a fun game out of it. The player has to protect his or her castle against attacking forces. When measuring the BSL, the player creates a new tower at the current GPS location, which then protects the castle. The more castles at different locations are created, the better the defense gets and the more points are scored. That means that the children are not only motivated to measure their BSL, but to walk around varying the position of their towers. Candy Castle stores its data in the Google Datastore, which means that it can be accessed by doctors as well. There is also an analytics component implemented, which analyzes the collected data. The data that are accumulated are very specific, and so is the database. The idea behind the application is very useful and the data storage sufficient for its case. But instead of storing the data in a special, case-specific database, it is desirable to have a more generic data storage that can potentially be combined with other applications.

Figure 2: Expectation of the mHealth Market Volume Over the Next Years [18].

spectrum of these applications is rather wide. There are games like „Candy Castle“, which motivates children to constantly check their blood-sugar level [17], a World Health Organization initiative against smoking [12], or commercial projects by companies like Microsoft [11] and Merck [10]. The problem with most of these solutions is that they either use isolated data storages, which are not compatible with each other or that they do not adequately address privacy issues. This work’s focus is mainly on patients’ data and the question how to efficiently and securely store them and grant access for doctors to this data. What we want to accomplish with our work is:

2.2

• Designing a generic data model for the storage of various kinds of health data.

2.2.1

Data Storage Systems Microsoft Health Vault

The online service Health Vault [11], which was developed by Microsoft, offers a more generic approach to mHealth. One can save various health data such as medication, diseases, X-ray pictures and many more in a cloud. The system is optimized for both personal computers and mobile devices. It is further possible to invite other people to gain access to your data, e.g. doctors that are currently treating the user. It is also possible for devices like blood pressure measurement instruments or blood sugar monitors to connect directly to the Health Vault application so that the user does not even have to save the data manually. These devices are then able to import the measured data into the database automatically. Statistics which are erected from the given data then provide tips for the user on for example cancer check-up or ways to improve the health situation. The Health Vault Application can be seen in Figure 3. A partnership between Microsoft Health Vault and the American Department of Health and Human Service in the United States made it possible to fill in questionnaires at the hospital or doctors office in a more direct way because of the already available data. The main issue with this system is the data storage. The highly sensible health records are uploaded into Microsoft’s cloud, and it does not become clear how the data is processed further on, nor whether the user can totally delete them or not.

• Implementing the model as an extension for the PMP. This data storage can then be accessed by different kinds of applications and it benefits from the privacy advantages that the PMP offers. • Implementing an application that uses the database from the doctor’s point of view. This application allows the doctor to manage his patients and therapies. • Presenting the functionality of the database by showing a demo run with our app. We use the PMP, a privacy-aware application platform, for our work in order to support an easy to use accessibility for any app. Furthermore, our data storage component profits from the privacy protecting features of the PMP. For more details on the PMP see [15] [13] and [14]. The remainder of the paper is structured as follows: In Section 2 we discuss existing mHealth solutions and point out their strengths and weaknesses. The third section presents our conception of a container for mHealth data and the issues that go along with it. Section 4 focuses on the implementation of this container and an Android app that uses it, giving an idea of which software can be build to usefully access the collected data. In the fifth section we present a little demo to illustrate the functionality of our Android app called MedicalService. In the last section a brief outlook on what can be achieved by our design is given, as well as conclusion of our work.

2.2.2

Google Health

The Service Google Health [6], which is meanwhile closed down, on the other hand provided the possibility to import already existing data from healthcare centers and pharmaceutics companies. Another function of Google Health was to find the nearest health care facility. In comparison with Microsoft Health Vault, Google Health on the one hand provided chargeable programs for data import and health tips and on the other hand linked external websites containing programs like for example diabetes calculators. Like the Health Vault Service, Google’s approach showed many good ideas and functions, but the data security question remains completely unanswered. As privacy becomes increasingly important for users, the Google Health service was closed down due to "not

2 R ELATED W ORK Due to the fact that mHealth has become an important issue since the upcoming of mobile devices, there already exist multiple running mHealth systems. These systems can roughly be categorized in three different classes: • Applications that only run on the mobile device. An example is the above mentioned game Candy Castle. 2

Mobile Device

Mobile Device

Patient App

Doctor‘s App

Health Status

Push Notification (& SMS)

Health Risk (& SMS) Enquiries

Browser Patient Portal

Doctor‘s Portal

Frontend

Recommendations

Enquiries

Health API (RESTful)

Health Health Health Services Services Services

Orchestration

Analytics Analytics Analytics

Health Data

Backend

Management & Provisioning Engine Health Server

Figure 3: Graphical User Interface of Microsoft’s Health Vault [1]

Figure 4: Overall Architecture of ECHO [2]

having the broad impact that we [the developers] hoped it would [have]" [3]. If people give their most private information away, they want to know how it is handled.

The backend is represented by the database which stores the collected data and several cloud services. The database and services together form the Health Server. The services can be extended and are responsible for the automatic analysis of the data that users upload. The project ECHO includes some very interesting approaches in terms of automatically analyzing the patients’ data and giving them feedback as fast as possible. It is a rather specific system, which aims solely at the treatment of patients suffering from chronic diseases. It is therefore not viable when it comes to creating a general health record.

2.3 2.3.1

Holistic mHealth Services Med App

A very interesting approach towards a holistic service is the so called „Med App“ which was developed by members of the University of Saskatchewan, Canada [8]. This application is already used by the City Hospital of Saskatoon, Canada, and has proven to be very satisfactory for their special purpose. The main concept behind this project is the usage of three different layers to collect, evaluate and securely store patients’ data. On the lowest layer are the mobile devices, e.g. smartphones or tablets which are used by doctors to both collect and evaluate data. The other end of the layer hierarchy represents the server on which all the data is stored. However, the core element of this architecture is the middleware, through which all traffic is routed. Every authorization process takes place on the middleware. It also manages the access rights for different user groups. Another crucial task of the middleware is an event manager, which informs medical workers when a patient’s data are updated. Thus, they are constantly being synchronized with the doctors’ mobile devices and therefore also stored on them. This enables the users to access the stored values even if they do not have an active internet connection. The Med App pleases with its transparent description of how the different layers work and interact. Nonetheless, it is not explained how the data is stored on the mobile device exactly, nor how it is encrypted or if it is encrypted at all. Another problem is that the application is specifically developed for hospitals, and it seems very hard to extend the usage to patients collecting data themselves. 2.3.2

2.4

In General

There is a variety of applications and services on the market that fulfill different aspects and functionalities concerning mHealth. The problem is that there is no solution which perfectly covers all the conditions we impose in the following sections towards a good data container. 3

C ONCEPT

AND

S CHEME

In this section we present our conception of a container for mHealth data and the issues that go along with it, followed by discussing the scheme of our application. 3.1

Fundamental Database Model

The main goal of our data schema is to provide a simple and easy to use container for our data. The simple structure of our database makes it easy to look up specific data stored in it. The database consists of several individual tables that are connected to each other as shown in Figure 5. Details about the particular tables are given in the following:

ECHO

• The "Patient"-table This table contains all personal data concerning the patient. This includes the patient’s name and birthday as well as his username and his password. In addition to that this table contains the patient ID which is used as an identifier to connect the patient to his doctors, therapies and other data stored in the medical cloud.

ECHO, which is an abbreviation for "Enhancing Chronic patients’ Health Online", is a project that concentrates on monitoring patients who suffer from serious chronic diseases [2]. The patients have to daily update certain measured data which are then evaluated. Afterwards, the patient gets a treatment or a recommendation either automatically or from his doctor. The main goal behind this monitoring is the prevention of medical emergencies and unnecessary hospitalizations in order to save money. The overall architecture of the system is shown in Figure 4. The frontend of the system is either designed as applications for smartphones or web pages. Thereby it is differentiated between a patient’s application and a doctor’s application. Both applications access the health data which is stored in a cloud.

• The "Medic"-table This table contains all data about the doctors. This includes the doctor’s name, his username and password as well as a type that describes what kind of doctor he is. Additionally the medic’s ID is stored which is used to connect the doctor to his patients, therapies and other data stored in the medical cloud. 3

Figure 5: Entity-Relationship-Model of our Database

4

• The "Therapy"-table In this table the data about the therapies is stored. The patient’s and the medic’s IDs are used to define which patient and which doctor is involved. In addition to the date of the treatment, the diagnosis, the taken measures, the prescribed medicine as well as possible annotations of the doctor are stored.

as for example, changing one’s own medication would most likely do more harm than good, not even considering possible abuse of this function. So how can a patient be granted power over his/her data in a meaningful way? One potential feature that allows this could be: • Adding self-made measurements to the database

• The "Disease"-table This table contains the information which patient suffers from which diseases. The patient’s ID is used to connect the patient to his diseases what makes it easy to keep track of the diseases a patient is currently suffering from.

This way, not only is the patient granted some sort of power over his/her own data, but part of the doctors’ responsibility is transferred as well. Consequently, potential risks arise if a patient is not motivated to use this feature responsibly. This has to be considered when talking about the implementation. However, such a mHealth-Application also has very important nonfunctional requirements. As already mentioned earlier in our work, due to the high confidentiality of the data we are trying to manage, the last issues that need to be solved are ensuring the data’s privacy as well as its security.

• The "Intolerance"-table Similar to the "Disease"-table, this table contains the data of the intolerances a patient has by connecting the patient’s ID with the different intolerances. 3.2 Requirements of the Application The application is the interface between a user and the data stored in the server’s database. As shown in Figure 6 the user of such a mHealth-Application can be both a doctor as well as a patient. Consequently, the app should allow the user to manage the data relevant to him. The first core function that comes to mind, is rather obvious:

• Ensuring privacy and security of data Now that the scope of the application’s functionality and requirements has been carved out, what is left is implementing the aforementioned functions. 4

• Looking up/Editing patients’ data

I MPLEMENTATION

The following section focuses on the implementation of the application tailored to the usage by doctors. Necessary changes to the functionality required for a patient-focused application will be discussed at the end. The server’s implementation is unaffected by different groups of users.

The scope of this data is subject to discussion, but intuitively, things like a list of the patient’s therapies, diagnoses or prescribed medicines come to mind. Of course, looking up as well as editing a patient’s data requires some sort of data to work with. Therefore the user needs the possibility to add a new patient to the list of already registered patients:

4.1

• Adding new patients’ data to the database

MedicalService

The application is run on a mobile device and allows the user to access a patient’s data whenever and wherever it is needed, thus allowing a higher grade of mobility than a stationary data access point such as a computer in a doctor’s office, consequently saving time and money. Additionally, costs can be further cut by either involving the patient in the ascertainment of data and/or by allowing other, trusted applications to access the data and provide services like preprocessing, thus decreasing the amount of time spent on therapies. Finally, in contrast to applications that rely purely on server-based data storage, MedicalService stores data relevant to the user on the mobile device as well, further improving the aspect of accessing data when- and wherever you want by removing the need of a continuous internet connection. Local data can still be uploaded to the server to update its database when an internet connection is available.

In theory, adding data and editing it already fulfill most of the required tasks. For security and consistency reasons, the user cannot remove patients from the database. This results in a doctor still having stored data on patients he might no longer be responsible for, for example patients who changed their family doctor. This data only consume storage without becoming relevant. Obviously, the action of removing a patient’s data should only be applicable to the data stored in the local database on the mobile device. • Removing patients from a doctor’s view of the database Should a removed patient’s data become relevant again, his/her data can simply be added again the same way as if he/she was a new patient. Now the application fulfills all required tasks, but only for a single user which is not optimal as a patient may be registered in several doctors’ local databases. It is not unlikely that changes to a patient’s data may become relevant for other doctors as well (for example intolerances and prescribed medicines). Thus the application needs to be optimized in regards of usage by multiple users:

In the following, we further explain our application’s control flow as shown in Figure 7. 4.1.1

Database Control

Communication between application and server as well as managing data access and data manipulation is handled by functions of the DatabaseControlActivity. This includes checking whether login data is correct, checking whether a patient’s data is existent in the database, as well as the application’s main functions (Section 3):

• Synchronizing data between the server and a mobile device Having covered the needs of doctors as users, one may chose to increase the scope of use-cases by including additional groups of users. For a medical application, the logical is including the patients: Once again, the first core function is obvious:

• Looking up / Editing patient’s data

• Looking up one’s own data

• Adding new patients to the database

Including diagnoses, prescribed medicines and other relevant data. This one function alone already fulfills most of the basic requirements of a patient application. Still, with this model, the user only acts passively as an observer and has no direct influence on his/her data. Of course, a patient’s influence on the data has to be restricted,

• Updating patient-medic relationship • Synchronizing data between server and mobile device 5

Figure 6: Requirements Diagram for Different Users

4.1.2

Start and Login

agnosis, measures, prescribed medicines and further notes. The entered data is added to the database via clicking the confirmationbutton. The last button on the PatientInfoActivity leads to the PrescribedMedicineActivity, a chart containing the medicine’s name, the date of the relevant therapy. Clicking the ShowDiseases- or ShowIntolerance-button opens up either the DiseaseActivity or IntoleranceActivity. These Activities consist of a chart displaying the patient’s history of diseases/intolerance.

Upon start, the application’s MainActivity confronts the user -in our case a doctor- with a login dialogue and prompts the user to identify him/herself by entering his/her username and password. Access to the application’s functions is only granted upon entering a matching combination of username and password, missing or incorrect input is answered by an alert dialogue and the user has to repeat the login process. Logging out can be achieved by either clicking the ’Logout’button on the following screen or simply closing the app. Upon successfully logging in, the user has the option to either look up a patient’s data, add a new patient to the database, ’remove’ a patient from the database (The patient’s data is still stored in the database, the doctor only gives up the authority to view the patient’s data. This might become relevant for example when a patient changes his/her family doctor.) or update the database. 4.1.3

4.1.4 Adding New Patients Adding a new patient to the database is achieved by entering his/her name, date of birth and his/her unique identifier (in this case the insurance policy number) and confirming the input in the NewPatientActivity. 4.1.5 Severing the Relation Between Doctor and Patient Updating the relation between a doctor and a patient works analogically to adding a patient but features additional alert dialogues for informing the user if the relevant patient cannot be found and another dialogue for confirmation of the current action. The action has to be either confirmed or canceled in the dialogue. As mentioned earlier, this action only restricts the currently logged-in doctor from accessing a patient’s data. The data itself is still stored in the database and is accessible for all doctors with the needed authority.

Looking Up and Editing Patients’ Data

Choosing to look up a patient’s data activates the LookUpPatientActivity. Here the user has to enter a patient’s name and his/her unique identifier known only to doctor and patient (for example the patient’s insurance policy number) to search for that patient’s data or click the cancel-button to cancel the input and return to the MainActivity. A click on the confirmation-button either leads to the PatientInfoActivity (in case a patient with the input name and ID was found in the database) or creates an alert dialogue if the patient cannot be found or part of the needed input data is missing. The PatientInfoActivity consists of the patient’s name, date of birth and the buttons to either show the patient’s record of therapies, add data about a new therapy or show a list of prescribed medicines. The Therapy-button opens the TherapyLookupActivity with a dropdown-list of therapies made by the currently logged-in doctor concerning a certain patient which the user can choose from (specifying one as well as all therapies is possible). The user may also choose to lookup a record of the patient’s registered diseases or intolerances. Clicking the OK-button activates the TherapyActivity which shows a chart with the date, diagnosis, prescribed medicines, measures and furthers notes for all therapies during the time specified earlier. Here the user also has the option to add new therapies to the database. Choosing to add a new Therapy opens the NewTherapyActivity containing text fields for entering the date of the new therapy, the di-

All of the aforementioned Activities feature a Cancel-Button that (if applicable) cancels the action taken on the currently active screen and returns the user to the last Activity-Screen. 4.1.6 Synchronizing Data Updating local data as well as data on the server is handled by the DatabaseControlActivity. Clicking the Update-button synchronizes data between the local database and server database, applies changes made to the local database to the server database thus making said changes visible to other users of the application. 4.1.7 Additional, non-functional requirements • Data Privacy When trying to solve the issue of warranting the privacy of 6

Potential Privacy Threats

Trusted Components Privacy Policy 1

1

1..* provides 1 App

1..* Service Range

Privacy Rule

User Settings

preconfigures

5

consists of

1..* Service Feature

patient’s submitted data is within the acceptable bounds or he/she should consult a doctor.

Presets

1..*

1..*

Context

1..*

Data

1 Resource 0..*

1..* pools

1

Privacy Setting

1 Resource Group

5.1 Figure 8: PMP’s Privacy Policy Model [16]

Example Scenario

Our example patient Jonny B. is suffering from severe toothache for a few days but unfortunately his dentist is on vacation for another week. So Jonny has to visit another dentist and luckily Dr. Acula has a free slot the next morning. As Dr. Acula arrives at work the next morning he starts his application and logs himself in to get access to the data of the patients he is going to treat at this day. The first patient at this day is Jonny B. Because he is seeing Dr. Acula for the first time, Dr. Acula has to add him to his patients in order to see any information or being able to store any of his diagnoses. To do so, Dr. Acula asks Jonny for his personal information, enters it into the application and adds him to his patients. Jonny tells Dr. Acula that one of his teeth started hurting a few days ago. So Dr. Acula examines Jonny’s hurting tooth and finds inflamed gum in the general area of the aching tooth. After that Dr. Acula enters Jonny’s name and patient ID in the app to open up Jonny’s medical records. In the treatment section he looks up teeth related diagnoses during the past year to search for additional information regarding Jonny’s problem. Dr. Acula finds a couple of entries from Jonny’s other dentist that show that Jonny had trouble with this particular tooth for a few times in the last eight months. Up until now those problems were treated with painkillers and antibiotics. Looking up this information would have been impossible if not both dentists used this app. Then Dr. Acula would have had no information of Jonny’s medical record other than what Jonny could have told him. And he would not have been able to ask the other dentist since he is on vacation. After running some additional tests Dr. Acula decides that the tooth has to get pulled out. Before he injects the local anesthetic he checks Jonny’s patient information for any intolerances but finds none. But shortly after the injection Jonny is showing light allergic reactions. To prevent this from happening again in the future Dr. Acula notes this in the database. In Jonny’s personal section he adds the information of his intolerance to the database so no one will use this anesthetic on Jonny in the future. After successfully removing the bad tooth, Dr. Acula prescribes Jonny some painkillers. After the session, Dr. Acula adds the information of Jonny’s treatment in the database of the app. He selects the new entry function on Jonny’s information screen, than he enters the date, the diagnosis and the treatment, selects the prescribed medicine and saves the entry in the data base.

the data stored in the database, one can find many different approaches that feature different advantages and disadvantages [14]. Depending on the use case some approaches are more fitting than others. One approach that is worth considering is the Privacy Management Platform for Android, as it offers a "customizable, fine-grained, context-based, crashproof, and intuitive privacy policy model" [16] and only slight modifications to the application’s Manifest are required to support it. The PMP is an additional layer between the application layer and the application framework layer, allowing us to protect the patients’ data stored in the database from unwanted access by other third-party applications thus removing potential privacy threats. The privacy policy model of the PMP is shown in Figure 8. For more details on the PMP and its functionality, refer to [15] [14] [13]. • Data Security Another important requirement for mHealth applications is data security. Since we are not working with real patient data, data security is a part of future work. Data security can be assured for example by following one of the already existing concepts such as data encryption. As warranting the data’s security is not within the scope of our work, it will not be discussed further in this paper. As we do not require excessive resources for our demonstration, we decided on implementing our data model on a MySQL-server. This way we profit from easy usability while still having all the functionality needed for our application at hand. The concept of interaction between MedicalService and database is shown in Figure 9. 4.2

D EMO

To further explain the workflow of MedicalService it is easiest to show its functions with an example. In this demonstration we will explain a possible scenario in which a doctor logs in to the application, adds a new patient and looks up his information. In the end he saves the diagnosis and treatment data in the medical cloud, as seen in Figure 10. For this scenario to work, the doctor account already has to exist as well as the medical records of our example patient and the lists of medicine and diagnoses.

The Patient’s Mobile Application

Starting from the doctor’s application, several modifications need to be made to the implementation to arrive at an application tailored to the needs as well as authority of a patient. The LookUp-Patient-Function an its sub-functions can be kept almost unchanged with the sole modification being the restriction to only show the patient’s own data. The option to manipulate the data can either be completely removed as well, or it can be modified to allow only the update of certain parts of the data. The AddNewPatientand EnablePatient-Function are removed, as they offer no meaningful functionality for the patient. This very restricted version already offers a good amount of functionality to the user without giving them to many rights. Additional functions may be added to the application to expand the patient’s influence on his own health data by enabling them to add data they can measure themselves, for example blood sugar values in case of diabetes patients. Consequently, the user’s responsibility for his own data increases as well, thus modifications to encourage a sensible use of this feature may be required. Possible solutions would be either creating some sort of fun-factor in collecting data [17] or in giving relevant feedback, for example some sort of notification whether a

As this example shows, using MedicalService comes with different advantages. Since both dentists are using our medical cloud to store Jonny’s medical record, Dr. Acula can directly access those entries. Because the other dentist is on vacation, he could not have send Dr. Acula Jonny’s medical records and important information would have been missed. This accessibility is not restricted to dentists but works for every type of doctor as long as he is treating Jonny. This provides the different doctors the access to all medical data stored in our medical cloud. This way of storing data saves a lot of time, work and money since medical data do not have to be send by mail or delivered by hand but are stored online and are always ready to be looked up. Furthermore 7

Figure 7: Structure of MedicalService

Figure 9: Concept of our App-Database-Interaction

8

Figure 10: Sequence Diagram of the Given Example Scenario

this accessibility comes without any additional work for the doctors except setting up MedicalService once and storing the patient data in the medical cloud instead of using file cabinets. 5.2

as good as possible. However, the current implementation is realized as a native Android application. • Implementing the database design. We managed to implement the presented design as a SQL database. The database can easily be implemented as a PMP resource and profits from the privacy benefits that the PMP offers. Furthermore, this kind of implementation allows the creation of additional applications that access the same data storage, e.g. an application for patients looking up their own health record, updating values or directly getting feedback when one of the values becomes critical.

Setup Requirements

To demonstrate this application to possible users, a couple of things are required. First of all a computer or laptop to run the server containing the database is essential. Since running the database does not require a lot of hardware power, a low end machine should suffice. The next thing needed is smartphones or tablets that are able to run the application. In order to make the application work, the smartphones or tablets have to communicate with the database. Therefore a wireless network is necessary. Since the users only have to operate a smartphone or tablet the required space is minimal, only enough to let the users comfortably use the smartphones. To try out MedicalService, the users have to take one of the smartphones or tablets, log in with one of the dummy accounts and explore the possibilities of the application. To make the experience for the user as smooth as possible, a supervisor could be helpful to give a brief introduction or help in case of complications. 6

• Implementing an application using the storage component. We successfully implemented an Android application that goes beyond a pure demonstration. It is rather a fully functional mHealth application created for doctors to organize their patients. The doctor can add or delete patients he treats, fill in diagnoses, measures, medicine and further notations. In future work, this application could be extended and new applications interacting with the database could be implemented. The collected data can be stored both on a server and on the mobile device. This means that the health information could be accessed even when there is no active internet connection.

C ONCLUSION

With the increasing amount of applications centered around mHealth, there is also an increasing necessity for a generic and privacy secure storage component. Our evaluation shows that none of the existing solutions fulfill all the requirements we demand, and therefore we created a design which satisfies all these aspects. The creation of such a design is exactly what our work’s main goal is.

• Presenting the functionality via a demo run. In our demo, we show how MedicalService works and which features it covers. Step by step, we demonstrate the navigation through the application and show how an example scenario is handled.

• Our database design is generic. The design enables the user to store different values in the table. The implementation of our design is not bound to any platform restrictions, though we decided to implement the design for Android in order to make it easily integrable into the PMP. That way, the highly sensible health data’s privacy can be assured

The advantage that our work offers compared to state of the art approaches is the serious discussion and evaluation of the privacy. Every user can understand how and where the data is saved and evaluate whether he/she wants to use such a platform or not. This transparency is what users expect from a mHealth application that collects their most private health information. 9

R EFERENCES [1] T. Bishop. Microsoft brings HealthVault app to iPhone and iPad. Website, 2012. http://www.geekwire.com/2012/ microsoft-brings-healthvault-app-iphone, accessed 10/31/2014. [2] M. Bitsaki, C. Koutras, G. Koutras, F. Leymann, B. Mitschang, C. Nikolaou, N. Siafakas, S. Strauch, N. Tzanakis, and M. Wieland. An Integrated mHealth Solution for Enhancing Patients’ Health. In Proceedings of the 6th European Conference of the International Federation for Medical and Biological Engineering, MBEC 2014, pages 1–4. IFMBE, 2013. [3] G. Blog. An update on Google Health and Google PowerMeter. Website, 2011. http://googleblog.blogspot.de/2011/06/ update-on-google-health-and-google.html, accessed 10/31/2014. [4] V. W. Consulting. mHealth for Development: The Opportunity of Mobile Technology for Healthcare in the Developing World. In Washington, D.C. and Berkshire, UK: UN Foundation-Vodafone FoundationPartnership, 2009, page 9, 2009. [5] G. Eysenbach. What is e-health? In Journal of Medical Internet Research, vol. 3, 2001. [6] W. Foundation. Google Health. Website, 2014. http: accessed //en.wikipedia.org/wiki/Google_Health, 10/31/2014. [7] R. S. H. Istepanian. M-Health: Emerging Mobile Health Systems. Springer, November 2005. [8] R. K. Lomotey and R. Deters. Efficient mobile services consumption in mhealth. In ASONAM´13, 2013. [9] D. Manos. Obama budget tags $1.8B for health IT. Website, March 2014. http://www.healthcareitnews.com/news/ obama-budget-tags-18b-health-it, accessed 10/31/2014. [10] Merck. Products Resources. Website, 2014. http://www. merckengage.com/resources.aspx, accessed 10/31/2014. Health Vault. Website, 2014. http://www. [11] Microsoft. healthvault.com/, accessed 10/31/2014. [12] S. Pujari. Tobacco Control and Mobile Health - A New Initiative. In The intersection of mobile health technology and tobacco control, October 2011, Geneva, Switzerland, October 2011. [13] C. Stach. How to Assure Privacy on Android Phones and Devices? In Proceedings of the 14th International Conference on Mobile Data Management, pages 1–3. IEEE Computer Society Conference Publishing Services, Juni 2013. [14] C. Stach. Wie funktioniert Datenschutz auf Mobilplattformen? In G. für Informatik e.V. (GI), editor, Informatik 2013: Informatik angepasst an Mensch, Organisation und Umwelt, Tagungsband der 43. Jahrestagung der Gesellschaft für Informatik e.V. (GI), 16.09. - 20.09.2013, Universität Koblenz-Landau, Lecture Notes in Informatics, pages 1–15. Springer-Verlag, September 2013. [15] C. Stach and B. Mitschang. Privacy Management for Mobile Platforms - A Review of Concepts and Approaches. In Proceedings of the 14th International Conference on Mobile Data Management, pages 1–9. IEEE Computer Society Conference Publishing Services, Juni 2013. [16] C. Stach and B. Mitschang. Design and Implementation of the Privacy Management Platform. In Proceedings of the 15th International Conference on Mobile Data Management, pages 1–4. IEEE Computer Society Conference Publishing Services, Juli 2014. [17] C. Stach and L. F. Schlindwein. Candy Castle - A Prototype for Pervasive Health Games. In Proceedings of the 2012 IEEE International Conference on Pervasive Computing and Communications Workshops (PERCOM Workshops); Lugano, Switzerland, March 19-23, 2012, pages 1–4. IEEE, März 2012. [18] Statista. mHealth (mobile health) industry market size projection from 2012 to 2020. Website, 2014. http://www.statista.com/ statistics/295771/mhealth-global-market-size/, accessed 10/31/2014. [19] M. Weiser. The Computer for the 21st Century. In Scientific American Special Issue on Communications, Computers, and Networks, September 1991.

10