Tablet computers are slowly being put into use in hospitals and primary care both by clinicians and patients. This paper will examine security needs of tablet-based eHealth applications, and explore how conventional security mechanisms can be adapted to this space. Our approach will be demonstrated by examining a particular eHealth application; a tablet-based Pain Body Map for use in palliative care.
Tablet computers such as the Apple iPad are increasingly being used in
healthcare settings; recent gures estimate that there are in excess of 12000
healthcarerelated apps in Apple's iTunes store, and three or four times as many when
counting also other mobile platforms [
Copyright c 2014 by the paper's authors. Copying permitted for private and academic purposes.
In this paper we will discuss a set of reusable security requirements proposed for eHealth application, and examine how these requirements can be met by tablet computers in general, and in particular by one speci c eHealth application; a tablet-based Pain Body Map (PBM) for use in palliative care.
The remainder of this paper is structured as follows: Section 2 gives an overview of information security threats towards eHealth applications. Section 3 presents an example tablet-based eHealth application that we will use to examine security needs and subsequently a security solution. Section 4 summarises the security o ered by one speci c tablet platform, i.e., the Apple iPad, and provides recommendations for how it best can be con gured to o er optimal security. Section 6 discusses how our example application addresses the security needs of en eHealth platform, and Section 7 concludes the paper. 2
It has been claimed that the form factor of mobile devices in itself represents an
improved physician-patient relationship [
Jones et al. [
Health information is a perfect example of the kind of sensitive personal
information that is protected by the European Privacy Directive [
In the following we will discuss how these requirements relate to tablet-based eHealth applications, and to what extent the available security mechanisms can ful l them. 3
In this section we will describe an example application that has been developed
for a tablet computer to be used in a clinical setting. Fig. 1 shows an iPad-based
Pain Body Map (PBM) for use in palliative care [
Pain is a common problem for patients with advanced cancer in palliative care.
These patients are taken care of by many healthcare professionals, in many
different settings. Most of the time, these patients are in their own homes, and
in many cases pain management can be very challenging. Pain is a very
abstract phenomenon which can be clear interpreted when you are experiencing
it. Describing it to a third person is challenging due to the lack of a common
description. The process of pain management require pain assessment. close
collaboration between patients and health care workers. The Assessment is de ned
as \an ongoing and dynamic process that includes evaluation of presenting
problems, elucidation of pain syndromes and pathophysiology, and formulation of a
comprehensive plan for continuing care" [
The patients with palliative needs are taken care of by pain specialists, other
specialists or a general practitioner in an in- or out-patient setting. Today PBMs
are either used alone or as an integrated part of several di erent assessment
tools [
In clinical practice, pain is normally assessed by a nurse using a questionnaire before the patient gets to talk to the physician. The data is presented to the physician, and used for better understanding the patient's pain problem. The questionnaires should be saved and used to see changes over time. In this way the health care professional can see the results of the pain management. The assessment can be used in both in- and out-patient settings.
We based our development on an agile user centred development process.
Requirements for the PBM was based on a usability testing of a Computerised
Pain Body Map made for a laptop computer [
The PBM can be used in a hospital setting, but also in ambulatory out-patient care, and could even be used by patients for extended-period self-reporting. We are currently limiting the discussion to tablets managed by an enterprise solution, which implies that any use of personally owned tablets are out of scope for this paper. 4
The key to secure use of iPad and other tablet devices is to make it part of an
enterprise solution [
Any iPad used in a clinical setting should be forced to set an enterprise password
and automatic screen locking. Although it is currently most common only to use
a simple PIN for this purpose, the iPad supports using a proper full-length
password [
The iPad can be con gured to encrypt all persistent data using a key based on the unlock PIN or password. This should be the default con guration for any tablet used in an eHealth setting, enforced via the aforementioned enterprise solution. 4.3
A typical problem with portable general-purpose computing devices is that the
temptation to use them for personal purposes is signi cant. For tablet devices,
there further seems to be a lower psychological barrier to installing new software
than on a desktop computer; some users even seem to think that there is a
di erence between an \app" and a \program". This may be a problem, since both
iTunes and the Android appstore have contained apps that contained malware or
spyware [
If a tablet is to be used in a clinical setting, we recommend removing all non-essential apps, as well as disabling the appstore (preventing the user from installing new apps). Alternatively, the iPad could be restricted to only using a speci c enterprise appstore with approved apps. Also, all general-purpose web browsers should be removed if not explicitly needed by the clinical application, or at the very least restricted to accessing speci c sites in accordance with the intended use of the tablet.
The enterprise solution should also enable remote wiping in case the tablet is lost or stolen. Wiping could also be initiated in case of repeated unsuccessful authentication attempts, although it might be su cient to lock the device in such cases; only unlocking from the enterprise solution when it is veri ed that the tablet is in the possession of an authorised user.
The tablet should be con gured to not synchronise with unauthorised computers, and only allowed to connect to speci c, white-listed network services using an encrypted connection (e.g. using a Virtual Private Network solution). 5
Each individual application (or \app") can encrypt all the data it stores based on, e.g., an application-speci c password. This would make it possible to provide additional protection at an arbitrary level, without being restricted by what the underlying operating system o ers. In this solution, it would be required to provide a password to access the stored data.
If a network connection is available, the eHealth application could be congured to not store data locally, but upload everything to a secure server. The conventional way of securing such communication is by using SSL/TLS, where appropriate con guration of allowed cipher suites can ensure adequate protection. However, if a tablet is to be used in an outpatient setting, a network connection can not always be relied on; even in a prosperous country such as Norway there are still dead spots without even cellular coverage. This implies that the tablet will need to store certain amounts of patient data locally, at least until it returns to the enterprise environment (e.g., the hospital), which means that appropriate measures as indicated above need to be applied.
Many tablets can be tted with a GSM/UMTS Subscriber Identity Module
(SIM), allowing them to communicate using GPRS or UMTS data
communication. Although such communication typically is encrypted, it is important to
know that the level of security o ered actually can vary from operator to
operator [
Finally, there are a number of commercial add-on packages that can provide further security features to tablets; little objective information is currently available for these solutions, so a comparison of pros and cons remains as further work. 6
Since tablets have such a convenient ultra-portable form factor, there is increased
risk that a tablet might be left behind in aircraft seat pockets, taxis and
restaurants [
Considering the requirements outlined by Jensen et al. [
Requirements 1 and 3 can be said to be ful lled implicitly, since a proper password will prevent anyone than the authorised user to access the table. Organisational policies must then deny sharing of tablets. Requirements 4 and 6 are ful lled by the password protection, encryption of stored data, and restriction of which devices the tablet may be synced with. Requirements 2, 5 and 7 is covered by restricting the tablet to communicating only with the enterprise network, protecting the connection with SSL/TLS, and requiring mutual authentication before data is transmitted. Requirement 11 is addressed by employing both device or operating system encryption, and application-speci c encryption, although there may be other single points of failure that are not covered. Requirement 12 is handled su ciently by using SSL/TLS on all network connections.
The audit requirements 8 and 9 are currently not handled in a satisfactory manner by tablet devices, although a tablet may be con gured to lock after a speci ed number of failed logins. However, it can be argued that since a tablet in general will not be remotely accessible and only used by a single individual, the audit requirements might be less critical. The input validation requirement 10 is also not addressed, but may be less relevant since we recommend restricting which hosts the tablet should be allowed to communicate with. Finally, requirement 13 is currently not addressed, although it might be possible to tag (and sign) data collected on the tablet to allow tracing it back to the tablet user. However, this would require modi cations to the eHealth application used on the tablet.
It should be noted that Jensen et al. [
Tablet approach
Password and organisational policies Verify identity of services Rmeustturaicltatuotheenntetircpartiisoennetwork, SSL/TLS, Verify authorisation level of users Password and organisational policies Integrity protection at rest rPeasstsrwicotirodnprotection, encryption, sync Integrity protection in transit Rmeustturaicltatuotheenntetircpartiisoennetwork, SSL/TLS, Access control rPeasstsrwicotirodnprotection, encryption, sync Con dentiality in transit Rmeustturaicltatuotheenntetircpartiisoennetwork, SSL/TLS, Log security incidents (Not addressed - less relevant) Log access to information (Not addressed - less relevant) Input validation (Not addressed - less relevant) Multiple levels of security eBnoctrhypOtSionand application-speci c Data freshness SSL/TLS
Non-repudiation Not addressed
Our example application uses the iPad platform, and it is clear that the closed
software model employed by Apple does make it easier to lock down the security
of an iPad in an enterprise setting than, e.g., for the open Android platform.
However, for the latest Android versions, the enterprise device management
options5 seem to be on par with that available for iOS, and once installing new
apps is denied by policy, the point about more malware on Android [
With correct con guration, tablet devices such as the iPad can now o er su cient security to be used in eHealth scenarios. However, there is still room for improvement, in particular on the logging side, where there is currently little built-in support. Current tablets should only be used by a single healthcare worker, and should be wiped of all stored data before being reassigned.