course material

1. MMHA 6600 WU Technology and The Future in Healthcare Discussion
RESEARCH ARTICLE Conceptual Privacy Framework for Health Information on Wearable
Device Seyedmostafa Safavi*, Zarina Shukur Unit of Cyber Security, Faculty of Information
Science and Technology, Universiti Kebangsaan Malaysia, 43600, Bangi, Malaysia
*Safavi@takhosting.info Abstract OPEN ACCESS Citation: Safavi S, Shukur Z (2014)
Conceptual Privacy Framework for Health Information on Wearable Device. PLoS ONE
9(12): e114306. doi:10.1371/journal.pone.0114306 Editor: Muhammad Khurram Khan,
King Saud University, Kingdom of Saudi Arabia, Saudi Arabia Received: August 17, 2014
Accepted: November 8, 2014 Published: December 5, 2014 Copyright: ß 2014 Safavi,
Shukur. This is an open-access article distributed under the terms of the Creative Commons
Attribution License, which permits unrestricted use, distribution, and reproduction in any
medium, provided the original author and source are credited. Wearable health tech
provides doctors with the ability to remotely supervise their patients’ wellness. It also
makes it much easier to authorize someone else to take appropriate actions to ensure the
person’s wellness than ever before. Information Technology may soon change the way
medicine is practiced, improving the performance, while reducing the price of healthcare.
We analyzed the secrecy demands of wearable devices, including Smartphone, smart watch
and their computing techniques, that can soon change the way healthcare is provided.
However, before this is adopted in practice, all devices must be equipped with sufficient
privacy capabilities related to healthcare service. In this paper, we formulated a new
improved conceptual framework for wearable healthcare systems. This framework consists
of ten principles and nine checklists, capable of providing complete privacy protection
package to wearable device owners. We constructed this framework based on the analysis
of existing mobile technology, the results of which are combined with the existing security
standards. The approach also incorporates the market share percentage level of every app
and its respective OS. This framework is evaluated based on the stringent CIA and HIPAA
principles for information security. This evaluation is followed by testing the capability to
revoke rights of subjects to access objects and ability to determine the set of available
permissions for a particular subject for all models Finally, as the last step, we examine the
complexity of the required initial setup. Data Availability: The authors confirm that all data
underlying the findings are fully available without restriction. All relevant data are within
the paper. Funding: This research was supported by The National University of Malaysia
(UKM) grant ERGS/1/2013/ICT04/UKM/01/1. The funder had no role in study design, data
collection and analysis, decision to publish, or preparation of the manuscript. Competing

2. Interests: The authors have declared that no competing interests exist. Introduction Given
that healthcare is one of the most important aspects of not only our lives, but also economy,
it is not surprising that it is gaining attention in wearable technology. Healthcare provision
via wearable devices brought changes in PLOS ONE | DOI:10.1371/journal.pone.0114306
December 5, 2014 1 / 16 Conceptual Privacy Framework for Health Information on
Wearable Device treatment and examination of patients, as well as research and
development in different areas. Given that the advanced communications technology has
ensured that most individuals own Smartphones, which are capable of using 3rd party
applications and many more devices connected to it, it was logical to find the ways for
healthcare to benefit from this trend. This prompted the emergence of a new field called
Mobile Health that, according to World Health Organization (WHO), has enabled health
checkups to be conducted via Smartphone or some other type of wearable device. It is
envisaged that, soon, health management and supervision will be conducted with the help
of functions like sound, SMS and MMS, Bluetooth and other services [1] (Figure 1). On the
other hand, Google has already made significant progress in this field, by introducing
wearable OS called Android Wear and the new types of wearable devices, such as Android
watches and Google Glasses (the glasses that can provide their wearer with information and
collect it at the same time). Google developers have proposed the idea of inbuilt technology
that can use sensors to provide all kinds of information about the user’s health [2]. The
applications recently announced by Apple (HealthKit), Google (Google Fit) and Samsung (S
Health) facilitate health monitoring through sensors that measure a user’s heart rate and a
gyroscope that calculates a user’s movement. This technology and API along it may help
providers to collect the most relevant data, because the glasses are something most
individuals are used to wearing. Producing devices with such capability could bring much
more innovation to the healthcare system. Rapid growth in the number of subscribers to
technology, such as cell phone, can ensure connectivity and usability throughout the
healthcare system. According to the report by Wu et al. [3], usage of cellular technology,
Smartphones in particular, in the medical field is increasing, since the devices can be used to
record patient’s medical history, symptoms and details about lifestyle. This information can
assist physicians in providing treatment and diagnosis in a safe and effective way. Findings
of similar research studies indicate that, with more widespread health IT adoption, we can
have an effective means to improve the quality and safety of healthcare [4]. However, this
innovation also poses an issue of ensuring that protected health information (PHI) is not
misused, (protected health information (PHI) is any information about health status,
provision of health care, or payment for health care that can be linked to a specific
individual). A study recently published by comScore suggests that the number of cell phone
subscribers in the US increased from 49 to 76.8 million between 2010 and 2011 [5], [6]. As
shown in Figure 2, the demand for portable devices like Smartphone can ensure that they
are widely available in healthcare. It is important to note that, if mobile healthcare
technology is to be widely utilized, it must be ensured that the client is given full control of
the data, even if a different party owns the applications. Thus, issues are likely to rise when
one party decides to share information with different companies for profit. Hence, in the
context of the healthcare system, it is necessary to apply privacy and safety rules [7]. PLOS

3. ONE | DOI:10.1371/journal.pone.0114306 December 5, 2014 2 / 16 Conceptual Privacy
Framework for Health Information on Wearable Device Figure 1. Mobile sensors and area of
coverage. doi:10.1371/journal.pone.0114306.g001 While wearable healthcare provision
devices could bring us better lifestyle and remove the need to regularly visit clinics, it may
introduce greater security and privacy issues to our society [8], [9]. Healthcare technology
gadgets have to be designed with the aim of improving health, as well as keeping the client
out of privacy and secrecy difficulties. Clearly, there is a potential for misuse of health
information, which must be addressed. In this paper, we propose a concise, improved and
effective privacy framework for wearable device manufacturers, as well as application
developers, capable of Figure 2. Adoption of mobile health initiatives and phases, globally
[1]. doi:10.1371/journal.pone.0114306.g002 PLOS ONE |
DOI:10.1371/journal.pone.0114306 December 5, 2014 3 / 16 Conceptual Privacy
Framework for Health Information on Wearable Device providing greater privacy and
security to the wearable device owners. The framework consists of two parts—the
principles and the checklists. Since the framework is related to the privacy of health
information on a wearable device, several critical aspects are considered when constructing
the framework. For creating the checklists, we propose: N N N Wearable technology that
includes the device technology and its operating system, Functionalities of health apps,
System architecture based on PHR standard. For formulating the principles, we offer: N N
Expanding the existing privacy and security framework related to health information,
Conducting a healthcare system projects case study. The proposed framework is
subsequently compared with other frameworks based on six CIA and HIPAA principles
pertaining to Information Security, namely Confidentiality, Integrity, Availability,
Authenticity, Non-repudiation and Information security analysis. This paper is organized as
follows: Section 2 presents a review of the aforementioned aspects, while the proposed
framework is described in Section 3. In Section 4, we evaluate the framework, and Section 5
concludes the work. Review on Technology and Health Application 1. Popular PHR
Architectures Wearable technology, and especially mobile health, can bring advanced
supervision to any place at any time without the need for the patient to visit the clinic. As a
result, the cost of healthcare can be substantially reduced. To record medical history, two
standard formats, Personal Health Record (PHR) and Electronic Health Record (EHR), are
used. While PHR is designed by the patient, EHR is designed and supported by the
healthcare supplier, such as a clinic or hospital system. Since PHRs contain significant
amount of data and must be subjected to stringent privacy rules and controls, they are the
main focus of this paper. Presently, Google [10] healthcare service and Microsoft [11], are
the two main PHR providers, as shown in Figure 3. Both companies offer applications that
permit the users to control their own PHI with the help of Internet. This enables collation of
PHI from different sources pertaining to the same person. Moreover, the user can change
the elements in the existing record, as well as share the content with family or healthcare
providers. Once they have created a Microsoft account, users can control and handle their
own or family member’s PHR, as well as authorize others to handle their own PHRs at any
time and level. As mentioned earlier, as clients can share their own data with whomever
they choose, they are effectively accepting the risks associated with the process. PHRs with

4. different PLOS ONE | DOI:10.1371/journal.pone.0114306 December 5, 2014 4 / 16
Conceptual Privacy Framework for Health Information on Wearable Device Figure 3. PHR
model provided by Microsoft [13]. doi:10.1371/journal.pone.0114306.g003 types of
protection designs [12] indicate that it is likely that how service providers handle the
sensitive data and protect the health information will change in the future. Via Internet, the
clients can check the submitted information and visit schedules at anytime, as well as
choose a specific doctor to visit. This method involves client sharing the PHI across the PHR
model, which may also include receiving data associated with financial claims and lab
results by multiple suppliers. Similarly, physicians will receive all the necessary information
about the patient across the system. As the PHR model is based on users holding their data
on a central repository, the client must keep and share the entire PHI data via Internet or
portable devices. Presently, this includes flash memory or Smartphone, but the number of
options is likely to expand in the future. It is essential, however, that these allow the user to
add and change fields of database records using the device or a dedicated Internet website.
This model authorizes suitable devices to run processes on user PHR information with
specific technology. In case of different vendors providing PHR, a set of standards must be
imposed. For example, if a Smartphone health gadget seller supplies a specific application
that can record the information received by the same device, it must be recognizable by all
other devices involved in the healthcare system and allow the patient to access data with
the help of seller’s Internet site. In addition, privacy in mobile health in organizations
should be using the same client-centric PHRs. Presently, many service providers can
provide cellular connectivity. While this reduces the price of technology and expands its
usage, it poses much greater risk to security and privacy. PLOS ONE |
DOI:10.1371/journal.pone.0114306 December 5, 2014 5 / 16 Conceptual Privacy
Framework for Health Information on Wearable Device 2. Operating System Main Features
The most popular platforms are largely similar in terms of allowing the users to receive
useful applications. However, their operating systems are typically incompatible. As shown
in Figure 4, ideally the platform should be able handle all types of health care devices, with
the focus on wearable gadgets that always stay with the user. The Android Operating
System designer and developer (Google company) is focusing on health system since many
users use the device and would like to benefit from it in terms of improving their health and
fitness. As shown in Figure 4, the operating system needs to support features that can help
applications to connect to the wearable device and have hardware that can receive and
store data in real time. In case of any issues or noticeable changes in the user’s health, the
wearable device should automatically start working in emergency mode. Among the three
most widely used operating systems available in the market, only Android has included
built-in connectivity to Bluetooth Health Device Profile (HDP) system [15]. 3. Brief Review
on Popular Wearable Devices As of April 2014, the Unit of Cyber Security in Faculty of
Information Science and Technology, Universiti Kebangsaan Malaysia (UKM) has completed
analysis of some wearable devices that are still not available to public worldwide, namely
Google Glass from Google Company and Galaxy Gear Fit designed and developed for
wearable system from Samsung. As an appointed explorer (the first author) for the latest
wearable devices, we found that, with the sensors available in these wearable devices and

5. help of API, healthcare providers can record data and protect the device owner. Presently,
they can use the technology to find out the position of the user and record the number of
steps taken, along with other fitness measurements, including heart rate measured by the
built-in sensor, these devices are incapable of recording and transmitting data, such as
location, without connection to a Wi-Fi network or a specific smartphone (Figure 5). This
scenario may change with the recently announced Android Wear devices (e.g. Galaxy Live,
LG G-Watch R, Moto 360), as well as the Apple Watch, which has a Healthkit system, and the
Samsung Gear S, which includes 3G, GPS, and a heart rate monitor. After proper analysis of
devices, we concluded that the mechanism that ensures data security is presently lacking,
which must be changed in later versions. Data protection is crucial for widespread use of
these devices as a means of keeping daily checks of user’s health and lifestyle. Thus, this
point is added to our checklist. 4. Review of Health Apps We analyzed the applications made
for different Operating Systems in Table 1, based on the platform, functionality and targeted
audience of the specified application. In this study, the strategy of selecting applications
follows three main PLOS ONE | DOI:10.1371/journal.pone.0114306 December 5, 2014 6 /
16 Conceptual Privacy Framework for Health Information on Wearable Device Figure 4.
Comparison of Market share percentage and main healthcare features supported by three
mobile OS platforms [14]. doi:10.1371/journal.pone.0114306.g004 criteria: (1) category,
which refers to the listed applications categorized under the patients’ section, (2) download
per application, or the popularity of the application that can lead users to find more useful
applications under the first criteria, and (3) the mobile operating system covered by the
selected application. After conducting an extensive analysis of applications, we conclude
that proper transparency in application, ease of User Interface (UI) use, customer
interaction with the system and having moderator and privacy settings are the most
important aspects of wearable healthcare applications. Hence, these elements are included
into the newly proposed framework. The Proposed Framework The proposed framework
considers the client control across the healthcare information, implying the power to share
data with a specific organization or a particular person relevant to the subject. At the same
time, it is essential to Figure 5. Google Glass design (front view) [1].
doi:10.1371/journal.pone.0114306.g005 PLOS ONE | DOI:10.1371/journal.pone.0114306
December 5, 2014 7 / 16 Conceptual Privacy Framework for Health Information on
Wearable Device Table 1. Applications that we have reviewed. Application Platforms
Functions Main Audience S Health by Samsung Android It can help you achieve your fitness
goals by monitoring your fitness levels during workouts and throughout the day. The
application will be connected to wearable devices to monitor your health at all times Patient
Davis’s Laboratory and Diagnostic Tests Android, BlackBerry, iOS, Palm OS, Windows
Mobile. User will receive care before, during, and after the test; RSS receives feeds of clinical
lab-product news. Patient Pocket Guide to Diagnostic Tests Android, BlackBerry, iOS, Palm
OS, Windows Mobile. Clinical settings laboratory procedures; diagnostic imaging tests;
complex algorithms flowcharts will be ready at all times; laboratory tests; images are color
images; and cloud support app. Patient/Clinics Labs 360 Android, BlackBerry, iOS, Palm OS,
Windows Mobile. Providing values; cross-reference available; up to date Healthcare
providers 5MCC Android, BlackBerry, iOS, Palm OS, Windows Mobile Diagnostic

6. information, algorithms and flowcharts available; drug therapy in every case available.
Doctor/Patient 5MIDC Android, BlackBerry, iOS, Palm OS, Windows Mobile Alphabetically
listed topics of interest Patient/Healthcare providers/Doctor ID Notes Palm OS Organs,
illnesses and related treatments, different types of indexing. Doctor/Patient P.M.I.D Palm
OS, Windows Mobile Guideline and therapy suggestion; users will be categorized by
physical history and therapy specify to the same user. Patient/Healthcare providers S.G
Antimicrobial Therapy Palm OS, Windows Mobile, iOS, BlackBerry. Facility to search;
categories available; organized diseases & historical conditions; organized drug info; very
efficient navigation. Doctor/Patient ePocrates ID Palm OS, Windows Mobile, iOS,
BlackBerry, Android 900 infections, pathogens and drugs recorded in its database; anatomic
location and price details by alphabetical categories; ability to record personal notes and
information in the database. Doctor Mobipocket Reader BlackBerry, Windows Mobile,
eBooks library; search in the dictionary; customizable display. Symbian OS, Palm OS
Doctor/Patient J.H.A.Guide iOS, Android, Palm OS, Includes expert noted information about
illnesses; drug lists and Windows Mobile, BlackBerry interactions; Info on anti-microbial
agents; Doctor Palm LabDX Palm OS, Windows CE Alphabetical tests listed; includes test
info; mostly info about testing. Doctor/Patient UpToDate iOS, web-enabled smartphone
Includes 14000 physicians, drug topics and related information; provides search filters to
find the information in three categories: adult, pediatric, patient. Doctor/Patient EyeChart
iOS Complete eye charts used by professionals. Doctor/Patient Lab Unit Converter iOS
Conversions and tests, ability to search lab results. Doctor Normal Lab Values iOS Search
reference visualizes labs alphabetically. Doctor/Patient DizzyFIX iOS Assists treatment of
BPPVc Doctor/Patient Video Laser Level iOS The oculoplastic surgeons can check alignment
of canthal position at the time of surgical planning and after the job. Doctor eRoentgen
Radiology Dx iOS Identifies best radiology test for the user; can be searched via
diagnosis/symptoms. Doctor Calculation of drug dosages and adjustments based on
patient’s data t. Doctor/Patient Antibiotic Dosage Calculator iOS
doi:10.1371/journal.pone.0114306.t001 differentiate between level of responses. We
expect that the portable and wearable devices, like Smartphone and smart watch, with the
help of Internet and application developers, will help rapidly expand the use of healthcare
technology [16]. The patient should have the option to share the data monitored and stored
by these devices with family members [17], [18], [19], or with 3rd parties. For example,
doctors can use the data for diagnosis [20], the insurance system can PLOS ONE |
DOI:10.1371/journal.pone.0114306 December 5, 2014 8 / 16 Conceptual Privacy
Framework for Health Information on Wearable Device Figure 6. Conceptual framework in
Wearable Healthcare System. doi:10.1371/journal.pone.0114306.g006 access the
information to provide cover for the user, and researchers can access the records in order
to conduct analyses and tests [21]. It is also envisaged that other authorized persons may
use this information to design diet, health plan or a training program for the client [22]. The
framework depicted in Figure 6 is designed with the aim of improving security and privacy
level for the healthcare system owner and it may help device manufacturers to improve
privacy checklist. Privacy rules in this framework are sourced from major popular
frameworks that have been available since 1999 (ONC, the Markle Foundation, HPP, and

7. CCHIT) [23] and various healthcare system projects (CDT, CF) [24]. In Connecting for Health
(CF) project, every device should be capable of transferring data, from forms to the data
architecture. In CDT, which is based on using policy scenes of the CF, the focus is on policy
papers [25]. 1. The Principles We recommend several improvements to both ONC and CF,
which are formulated and programmed by various groups of professionals. Since we have
PLOS ONE | DOI:10.1371/journal.pone.0114306 December 5, 2014 9 / 16 Conceptual
Privacy Framework for Health Information on Wearable Device focused on information
privacy on wearable devices, the CF framework is deemed a more objective framework and,
as it is user-centric, it will be covered in the following sections. The new framework is based
on ten essential principles shown in Figure 6. N N N N N N N N N N Pr1. The user-collected
information should be treated as private data and only be available to a specific list of
authorized persons or companies. Pr2. The purpose of collecting data should be clearly
stated and adhered to. Pr3. The wearable device should have safeguards to protect the
content from unauthorized access or misuse. Pr4. The device should have monitoring
service that can gather information about the application’s data collection protocol and the
data owner should have the right to monitor, review and stop specific application. Pr5.
Wearable devices should have a component that controls the information stored in the
database, as well as allow the data owner to edit or delete content at any time. Pr6. The
technology used to gather the data should be transparent at all times. Pr7. The device user,
or other trusted entities, can insert the personal data from the device to an application
specified to collect the data from the owner of the wearable device, while adhering to
respected policies. Pr8. The device should collect data in a transparent way mentioned in a
relevant policy and the aim of the collection of information must be completely visible. Pr9.
The ownership of data collection has to be fully transparent and granted solely to the device
owner. Pr10. The systematically distributed PHR database should be involved and the
wearable device owner should be able to modify the content at any time. We acknowledge
that wearable healthcare system may provide protection through many different aspects,
and the attributes noted above may used by other sectors, not only those related to portable
or wearable healthcare system. Since wearable healthcare system is the most likely one to
be used, it is a vulnerable service; thus, we may have to adjust remote supervision to control
the device. In addition, applications should have the capability to disable remote monitoring
and even shut down the device to protect the user’s complete PHI package. 2. The Checklist
for Privacy This checklist was created after an extensive analysis of the currently available
devices capable of supporting the healthcare monitoring system. It is divided to two parts,
one pertaining to device protection and the other to data privacy and security. I. Proper
device healthcare Application checklist: N N CL1. Communication line to transfer
information. CL2. Direct connection between the user and the support center. PLOS ONE |
DOI:10.1371/journal.pone.0114306 December 5, 2014 10 / 16 Conceptual Privacy
Framework for Health Information on Wearable Device N N CL3. Designed secure port to
exchange relevant information between the system and the user. CL4. Secure access control
method for authentication of the healthcare user. For example, PIN authentication process,
or some system based on biometrics, including an eye focus to open the lock, a retinal scan,
voice scan, and so on, could ensure that only the authorized individual can access the data.

8. II. Checklist for privacy protected applications: N N N N N CLP1. Full transparency in
application. CLP2. Internet connected application for Smartphone and easy to use User
Interface (UI) for the customer interaction with the system. CLP3. The user-manageable
application to receive data. CLP4. Restrictions on information privacy and unity. CLP5.
Inclusion of moderator and privacy guard. 3. The Improved PHR Model Once the new
improved framework was determined, we designed a new and improved PHR model
(Figure 7) that would be more secure as well as flexible. Thus, in our view, it can be used to
protect the user, while being responsive at all times. 4. Framework Evaluation Based on CIA
and HIPAA Principles The evaluation presented here is based on the CIA and HIPAA
principles for information security and tried to cover all aspect of privacy and security as
well as usability of the model via proper analysis. As the first step, we tested the ten
principles noted above with respect to ensuring better security, as well as providing a user-
friendly interface. Thus, we started with flexibility that brings the ability to support
frequent changes in policy, and continued with granularity of the process, with respect to
the permission levels that can be applied to different objects. In the second step, we
assessed the access control model performance, whereby we tested the authorization
complexity of the proposed model. Next, we moved onto analysis that involved modifying
access privileges to check if the model is flexible enough. Finally, we tested whether the
privileged data is modifiable and, at the same time, attempted to modify the rights of
subjects to access objects. After finishing the analyses noted above, we moved onto testing
the capability to revoke rights of subjects to access objects, followed by the ability to
determine the set of available permissions for a particular subject for the proposed model.
In the final step, we examined the complexity of the required initial setup. As shown in
Figure 7, the requests from different parts of system will be checked by the new framework,
which will use the priority settings in order to respond correctly. PLOS ONE |
DOI:10.1371/journal.pone.0114306 December 5, 2014 11 / 16 Conceptual Privacy
Framework for Health Information on Wearable Device Figure 7. New improved PHR
model. doi:10.1371/journal.pone.0114306.g007 5. Comparison with major frameworks
This comparison is based on the CIA principles for information security and tries to cover
all aspect of the wearable device privacy framework in Table 2. We have divided the table
into six principles recommended by CIA, with corresponding keys to the existing and new
frameworks. We compare our new framework with Office of the National Coordinator for
Health Information Technology Framework (ONC) [23], Health Privacy Project Framework
(HPP) [26], Best Practices Framework (BP) [27], Markle Common Framework (CF) [28],
The Certification Commission for Healthcare Information Technology Framework (CCHIT)
[29]. 6. Case Study We illustrate and evaluate this framework with a wearable privacy
awareness system designed for a clinic. For this evaluation, we conduct a case study on a
user—a heart surgery patient—to effectively manage his or her situation, including
significant variations in his or her blood stress level, frequently elevated blood pressure,
and step counts. The doctor advises the patient to subscribe to a health management
program designed by the clinic. The patient is also advised to wear a Samsung Wear device
that will continuously monitor his activities. The device and application are designed as a
wristwatch to prevent any kind of loss or misuse. In the first attempt, the wearable device

9. features pulse waveform and pair- PLOS ONE | DOI:10.1371/journal.pone.0114306
December 5, 2014 12 / 16 Conceptual Privacy Framework for Health Information on
Wearable Device Table 2. Comparison with major frameworks. CIA Principles Proposed
Framework Frameworks related to features Confidentiality Accountability, Access control,
Disclosure of data, Treatment Pr9/CL4/CL1 ONC1, ONC2, HPP3, BP3, CF1, CF6, CCHIT4,
CCHIT 5, CCHIT 6, CCHIT 7, BP9, CF9, ONC5, HPP2, BP4, BP6, CF4, CF7 Integrity Data
quality/integrity, Informed consent Pr2/Pr5 ONC6, ONC7, BP7, BP8, CF6, CF7, ONC4, HPP4,
HPP6, BP5, CF1, CF3, CCHIT1, CCHIT3 Availability Access control, Disclosure of data
Pr2/Pr1/Pr7/ CL2/CL4/CLP2 ONC1, ONC2, HPP3, BP3, CF1, CF6, CCHIT4, CCHIT 5, CCHIT 6,
CCHIT 7, ONC5, HPP2, BP4, BP6, CF4, CF7 Authenticity Data quality/integrity, Informed
consent, Transparency Pr1/Pr6/Pr4/CL3 ONC6, ONC7, BP7, BP8, CF6, CF7, ONC4, HPP4,
HPP6, BP5, CF1, CF3, CCHIT1, CCHIT3, ONC1, ONC 3, ONC 4, HPP 4, HPP 6, BP1, CF2
Protection safe guard CL4/CLP5/Pr4/Pr10 This feature is not available in any of them Non-
repudiation Transparency, Informed consent, Disclosure of data Pr1/Pr8/Pr2/CLP1 ONC1,
ONC 3, ONC 4, HPP4, HPP 6, BP1, CF1, CF2, CCHIT3, ONC4, HPP4, HPP 6, BP5, CF3, CCHIT1,
CCHIT3, ONC5, HPP2, BP4, BP6, CF4, CF7 Information security analysis Informed consent,
Access control, Accountability CL4/CLP3/CLP4 ONC4, HPP4, HPP 6, BP5, CF1, CF3, CCHIT1,
CCHIT3, ONC1, ONC2, HPP3, BP3, CF1, CF6, CCHIT4, CCHIT 5, CCHIT 6, CCHIT 7 Protection
safe guard Pr3/CLP5 This feature is currently not available
doi:10.1371/journal.pone.0114306.t002 to-pair connection to the patient’s mobile system
for the authentication of an actual patient. Moreover, if the patient has to move away from
the mobile device, he or she has to enter a code in the device to initiate its operation in
stand-alone mode (Pr3 and CL4). During its installation in a smartphone, the application
shows the permissions that must be accepted to send information from the mobile and to
allow the sensors to continuously provide a report to the installed application (CLP1). After
installation, the patient is notified of a carefully designed privacy policy list that is clear,
concise, easily understandable, and not too long so as to discourage the patient from simply
accepting it without reading it (CLP2, Pr2, Pr8, and Pr6). This privacy policy clearly
indicates how information is collected and with whom it will be shared (Pr1). After the
patient reads and accepts the privacy policy, the application proceeds to the setup for
information collection. This process allows the patient to specify and choose with whom
and at what time to share the collected information (Pr9 and CLP4). This selected setting
can be changed at any time and is flexible enough to conceal data location when the patient
chooses the secrecy option (Pr5). More choices are available for sharing data that can
facilitate the level of access to PHI; for example, doctor information and insurance company
are not be the same (Pr1). The patient or an authorized person may change the settings and
preferences for the specific ID (Pr10 and Pr4) through the mobile, watch, and website
interfaces (with username and password). The device continuously monitors a patient’s
health and activity and sends encrypted information to the smartphone if paired with a
mobile device (CL3). The application in the smartphone is capable of sending information
with a set of certified cryptographic keys to a clinic server with a configurable setting of the
same application (CL1). It is also capable of verifying that the patient’s wearable PLOS ONE |
DOI:10.1371/journal.pone.0114306 December 5, 2014 13 / 16 Conceptual Privacy

10. Framework for Health Information on Wearable Device device is calibrated at all times. The
information received by the application in the smartphone is equipped with mobile device
capabilities, such as a sensor that determines location (GPS), Wi-Fi address (MAC and
localization address), and calendar schedule, to facilitate the effective planning of the
patient’s health program (Pr4). The application in the wearable device alerts the user to
engage in some activity when he or she has free time, such as a notification to exercise by
waking or slow jogging. The wearable device enables the patient to send diet information to
the application and the server connected to the device using voice command and camera
(Pr7). The device’s smart notification reminds the patient to take his or her medicine or
sends him or her motivational messages to control his or her diet and activity, but only
when the patent’s calendar registers free time. The application in the wearable device,
smartphone, and secure website interface with username and password provides the
patient information about activities that can help prevent illness (CLP3). The patient’s
doctor may also monitor and analyze the patient’s improvement. However, insurance
companies may have access to particular information to keep the patient under insurance
rules and regulations (Pr1). In case of device loss or theft, the device is automatically
disconnected and wiped remotely after the patient reports loss or the back-end server audit
log flags a report. The log is reported to both patient and clinic for further investigation
(CLP5). The same back-end server reports the name of the patient and the time and location
collected by the wearable device (CL2). In addition, the updates of the application on the
wearable device and smartphone are automatically applied to ensure the security of the
device and the remote protection of privacy (CL4 and CLP5). Conclusion In this paper, we
improved privacy and security of wearable devices intended for use in healthcare provision
by designing a new framework that can work on every wearable operating system. After an
extensive analysis of data and frameworks related to the healthcare system, we proposed a
different framework that can support new wearable devices, such as Google Glass, Galaxy
Gear Fit or Galaxy Wear. The suggested framework incorporates ten essential principles for
wearable healthcare systems. In addition, we have proposed a comprehensive checklist that
can help both developers and manufacturers to improve the quality of privacy safeguards in
their products. We believe that our conceptual framework is one of the most comprehensive
concepts available at the time of publishing this paper. However, we are fully aware that
these frameworks cannot be implemented without law enforcement that combines the
security and privacy with regulation. Such collaborative effort between technology
developers, service providers and law professionals will ensure that healthcare not only
becomes cheaper, but also PLOS ONE | DOI:10.1371/journal.pone.0114306 December 5,
2014 14 / 16 Conceptual Privacy Framework for Health Information on Wearable Device
more accessible to all. We hope that this work has contributed to the better understanding
of the security protocols. Acknowledgments This research was supported by The National
University of Malaysia (UKM) grant ERGS/1/2013/ICT04/UKM/01/1. We are very thankful
to anonymous reviewers for their comments, reply and suggestions for Conceptual Privacy
Framework for Health Information on Wearable Device, which helps and improve the future
researchers. Author Contributions Conceived and designed the experiments: SS ZS.
Performed the experiments: SS ZS. Analyzed the data: SS ZS. Contributed

11. reagents/materials/analysis tools: SS ZS. Wrote the paper: SS ZS. References 1. Kay M
(2011) mHealth: New horizons for health through mobile technologies. World Health
Organization. 2. Safavi S, Shukur Z (2014) Improving Google glass security and privacy by
changing the physical and software structure. Life Science Journal 11. 3. Wu F-J, Kao Y-F,
Tseng Y-C (2011) From wireless sensor networks towards cyber physical systems.
Pervasive and Mobile Computing 7: 397–413. 4. Gaylin DS, Moiduddin A, Mohamoud S,
Lundeen K, Kelly JA (2011) Public attitudes about health information technology, and its
relationship to health care quality, costs, and privacy. Health services research 46: 920–938.
5. comScore I (2014) comScore Reports May 2010 U.S. Mobile Subscriber Market Share. 6.
comScore I (2014) comScore Reports May 2011 U.S. Mobile Subscriber Market Share. 7.
Cohn SP (2006) Privacy and confidentiality in the nationwide health information network.
8. Al Ameen M, Liu J, Kwak K (2012) Security and privacy issues in wireless sensor
networks for healthcare applications. Journal of medical systems 36: 93–101. 9. Giannetsos
T, Dimitriou T, Prasad NR (2011) People-centric sensing in assistive healthcare: Privacy
challenges and directions. Security and Communication Networks 4: 1295–1307. 10.
Google.com (2014). 11. HealthVault M (2014) Microsoft HealthVault. 12. Bernstein WS
(2008) Whose Data is it Anyway? Expanding Consumer Control Over Personal Health
Information: California HealthCare Foundation. 13. Rwjf (2014) Personal Health Records–
Business Models, Open Platforms and the Challenges Ahead. 14. Express TF (2014) Google
Android lords over 85 pct of smartphone OS market share, Apple?s iOS distant second: IDC.
15. Lollipop A (2014) Android Lollipop | Android Developers. 16. Safavi S, Shukur Z, Razali
R (2013) Reviews on Cybercrime Affecting Portable Devices. Procedia Technology 11: 650–
657. PLOS ONE | DOI:10.1371/journal.pone.0114306 December 5, 2014 15 / 16 Conceptual
Privacy Framework for Health Information on Wearable Device 17. Wang Q, Shin W, Liu X,
Zeng Z, Oh C, et al. (2006) I-Living: An Open System Architecture for Assisted Living 2006.
pp. 4268–4275. 18. Organizedwisdom.com (2014) OrganizedWisdom | Connecting you to
health experts and their wisdom. 19. Dailystrength.org (2014) Online Support Groups and
Forums at DailyStrength. 20. Rochester.edu (2014) Rochester Review? University of
Rochester. 21. Intel (2014) Intel Labs – Research. 22. Aylward R, Paradiso JA. A compact,
high-speed, wearable sensor network for biomotion capture and interactive media 2007.
ACM. pp. 380–389. 23. Hhs.gov (2014) Accreditor for ONC Health IT Certification Program
approved for second term. 24. Markle.org (2014) Markle | Connecting Consumers. 25.
cdt.org (2014) Comprehensive Privacy and Security: Critical for Health Information
Technology. 26. German RR, Lee LM, Horan JM, Milstein R, Pertowski C, et al. (2001)
Updated guidelines for evaluating public health surveillance systems. MMWR Recomm Rep
50: 1–35. 27. Castro D (2007) Improving health care: why a dose of IT may be just what the
doctor ordered. ITIF Reports. 28. Detmer D, Bloomrosen M, Raymond B, Tang P (2008)
Integrated personal health records: transformative tools for consumer-centric care. BMC
medical informatics and decision making 8: 45. 29. Brown B (2008) HIPAA Beyond HIPAA:
ONCHIT, ONC, AHIC, HITSP, and CCHIT. Journal of Health Care Compliance 10: 41. PLOS
ONE | DOI:10.1371/journal.pone.0114306 December 5, 2014 16 / 16 Copyright of PLoS
ONE is the property of Public Library of Science and its content may not be copied or
emailed to multiple sites or posted to a listserv without the copyright holder’s express

12. written permission. However, users may print, download, or email articles for individual
use. WEB CONTENTS appliedclinicaltrialsonline.com NOTEWORTHY Go to:
www.linkedin.com/groups/Applied-Clinical-Trials-2949042/about
appliedclinicaltrialsonline .com to read these exclusive stories and other featured content.
twitter.com/clin_trials “From the list below, what are the main reasons why your company
conducts or will conduct adaptive design trials? (select all that apply)” (Base=98) To make
earlier go/no-go decisions 63% Improve development decision-making A daptive Trial
Designs Gain Momentum. 51% Faster to market/commercialization 46% Shorter trials,
time savings in general 41% Lower overall development costs 38% Higher likelihood of
candidate success 37% More focused resources on trial arms that demonstrate effcacy 36%
Portfolio optimization 30% Avoid underpowered/overpowered studies 23% Smaller trials
in general 20% To provide better clinical care, fewer patients, fewer adverse events 19%
Integral to personalized medicine approach 0% © industry standard research 16% 10%
20% 30% 40% 50% 60% 70% % of respondents Source: ISR’s 2015 Adaptive Trials: Market
Dynamics and Service Provider Benchmarking report. eLearning eBooks Webcasts The
latest eBook from Applied Clinical Trials is Project Management in Clinical Trials, which is
written for project managers and those professionals interested in budgeting, forecasting,
and negotiating clinical trial contracts. Download your copy at http://bit.ly/1cwZIeg From
our OnDemand Webcasts archive, register to watch “Double Blind: De-Identification and
Data Masking,” which sets expectations about what is needed in a de-identification solution
for clinical trial data, and offers a pragmatic look at emerging standards in this area.
http://bit.ly/1zZBJiA Wearable Tech Boom Advances to the Brain T he boom in wearable
devices has been facilitated by technological advances enabling the miniaturization of
sensors and circuitry. Processors and sensors have become smaller, faster, and smarter,
which has enabled huge growth in the production of affordable consumer devices aimed at
the health and wellness market. An interesting aspect of the use of devices such as activity
monitors is the recording of continuous monitoring data, and the associated complexity this
brings in terms of the receipt, cleaning, interpretation, and summary of the data. Unlike a
glucose meter or spirometer, which provide simple point data, continuous monitoring falls
into the class of complex wearables due to the additional rigor needed in managing and
interpreting the data recorded. Consumer products that measure brain activity are
essentially devices worn around the head to measure EEG signals. Firmware within the
device interprets the signals from a series of dry electrodes contained within a headset to
provide continuous EEG signal traces. In health and wellness, one main area of developing
application in mobile EEG monitoring is using measured brain activity output to control a
product to produce a physical action or enable communication. A compelling example of
this is the use of live brain monitoring to enable paraplegic patients to communicate via a
computer. Social Media Have you joined our LinkedIn group or follow us on Twitter? Here’s
our most popular content on Twitter if you missed it: 1. CRO Experience in Orphan Drugs
bit.ly/SponsorPreference 2. INC Integrates DrugDev Site Cloud bit.ly/INC_DrugDev 3. Peer-
Reviewed Article on eSource bit.ly/eSourcePR Our top 3 most-read LinkedIn posts: 1.
Having a Brain Wave linkd.in/1FdZEeE 2. What Keeps Ukranians Away from Trials
linkd.in/1KJ0GiL 3. Digital Marketing According to HIPAA linkd.in/1IxFJtQ eNewsletters

13. ACT Direct will deliver every Tuesday this summer. ACT Social Media Trends will deliver
6/23, 7/8, 7/22, and 8/12. Oncology, RBM, Patient Engagement, and Regulatory will
alternate every Thursday. Subscribe at bit.ly/NBvcNx to receive directly to your inbox. Visit
bit.ly/1KIY3gR for the full version of this article 6 APPLIED CLINICAL TRIALS magenta cyan
yellow black appliedclinicaltrialsonline.com June/July 2015 ES626915_ACT0615_006.pgs
06.02.2015 23:11 ADV Copyright of Applied Clinical Trials is the property of Advanstar
Communications Inc. and its content may not be copied or emailed to multiple sites or
posted to a listserv without the copyright holder’s express written permission. However,
users may print, download, or email articles for individual use. Computers in Biology and
Medicine 51 (2014) 14–23 Contents lists available at ScienceDirect Computers in Biology
and Medicine journal homepage: www.elsevier.com/locate/cbm An open platform for
personal health record apps with platform-level privacy protection P. Van Gorp a,n, M.
Comuzzi b, A. Jahnen d, U. Kaymak a, B. Middleton c a Eindhoven University of Technology,
The Netherlands City University London, United Kingdom c Partners HealthCare and
Harvard Medical School, MA, USA d Public Research Center Henri Tudor, Luxembourg b art
ic l e i nf o a b s t r a c t Article history: Received 7 February 2013 Accepted 28 April 2014
One of the main barriers to the adoption of Personal Health Records (PHR) systems is their
closed nature. It has been argued in the literature that this barrier can be overcome by
introducing an open market of substitutable PHR apps. The requirements introduced by
such an open market on the underlying platform have also been derived. In this paper, we
argue that MyPHRMachines, a cloud-based PHR platform recently developed by the authors,
satisfies these requirements better than its alternatives. The MyPHRMachines platform
leverages Virtual Machines as flexible and secure execution sandboxes for health apps.
MyPHRMachines does not prevent pushing hospital- or patient-generated data to one of its
instances, nor does it prevent patients from sharing data with their trusted caregivers.
External software developers have minimal barriers to contribute innovative apps to the
platform, since apps are only required to avoid pushing patient data outside a
MyPHRMachines cloud. We demonstrate the potential of MyPHRMachines by presenting
two externally contributed apps. Both apps provide functionality going beyond the state-of-
the-art in their application domain, while they did not require any specific MyPHRMachines
platform extension. & 2014 Elsevier Ltd. All rights reserved. Keywords: Personal health
records Apps Architecture Trust Privacy 1. Introduction Without the participation of the
patient, a health care provider cannot effectively treat (or prevent) disease-causing
behaviors. The doctor–patient relationship is therefore gradually evolving from a
paternalistic approach to a more participatory model [1,2]. Houston and Ehrenberger argue
that a key factor for successful patient participation is information sharing: patients require
good information not only to care for themselves, but also to effectively communicate with
their physicians [3]. Empowering the patient with information is particularly important
since information exchange between different caregivers is very limited [4], especially
beyond the scope of local business networks (such as the Partners HealthCare system in the
US state of Massachusetts or the The Eye Care Network in the Netherlands [5,6]). The two
key stakeholders in this scenario, i.e., patients and their physicians, are often willing and
capable to share information. Already before the turn of the millennium, for instance,

14. various online surveys demonstrated high adoption rates of e-mail as a patient-provider
communication medium [7]. E-mail information n Corresponding author. E-mail address:
p.m.e.v.gorp@tue.nl (P. Van Gorp). http://dx.doi.org/10.1016/j.compbiomed.2014.04.019
0010-4825/& 2014 Elsevier Ltd. All rights reserved. sharing, unfortunately, has several
limitations. Most notably, message exchanges are completely ad hoc, preventing patients to
build and maintain a longitudinal record of their health data, to use the integrated record to
effectively care for themselves, and to share all their health data effectively and securely
with their caregivers. To overcome these limitations, Personal Health Record (PHR) systems
have been proposed by various companies and authors in academia [8]. PHR have many
societal benefits, such as empowering patients in the management of their own health and
fostering interoperability among health care providers, possibly reducing the overall costs
of diagnosis and treatment [9]. Policy makers, therefore, have repeatedly called for
technologies that “enable patients, doctors and other health care providers to access
personal health records securely through the Internet, no matter where a patient is seeking
medical care” [10,11]. Unfortunately, PHR adoption levels in practice are very low due to
privacy concerns as well as the lack of convincing medical and business use cases. The US
department of Health and Human Services, for instance, has invested heavily with the
expectation that “once the market has structure, patients, providers, medical professionals
and vendors will innovate, create efficiencies and improve care” [10]. One of the reasons for
the low level of adoption of PHRs is their lack of openness at the platform level. Mandl and
Kohane [12] have addressed the issue by looking at positive and negative P. Van Gorp et al.
/ Computers in Biology and Medicine 51 (2014) 14–23 experiences from various health
record projects. The authors conclude that PHR technologies should go beyond the
“conventional” requirements for Electronic Health Record (EHR) technologies, i.e.,
interoperability, security, and privacy. PHR systems should support open innovation and,
therefore, they should (a) reduce impediments to the transfer of data, (b) provide
substitutable software components, i.e. “apps”, and (c) they should allow competition and
“natural selection” for high-value, low-cost software components. Regarding
substitutability, the authors clarify that PHRs should enable the combination of software
components developed by different vendors without creating impediments to replace such
components over time [12]. In this paper, we propose the use of MyPHRMachines, a PHR
platform that satisfies the above requirements. The platform is unique in its openness: it
presents the least possible impediments to the transfer of data and it prevents apps from
violating privacy requirements by design. These properties are based on the use of Virtual
Machines (VMs) as flexible and secure execution sandboxes for the apps. To show the
effectiveness of the approach, we discuss externally contributed apps for Radiation
Exposure Measure (REM). As we will show later, radiology and, more specifically, REM, is a
typical application scenario that can benefit from an open PHR platform. The remainder of
this paper is structured as follows. Section 2 discusses the shortcomings of current PHR
platforms with regards to openness. Section 3 describes the MyPHRMachines platform.
Section 4 gives the motivation for and presents the REM application scenario, while Section
5 describes the REM apps in MyPHRMachines. Finally, Section 6 discusses the contribution
of the paper by providing a link also to the PHR literature. 2. Openness of PHR platforms

15. Opening a platform enables its owners to strategically disclose aspects related to the
development or commercialization of the platform [13]. There are broadly two different
approaches to opening a platform. The first entails giving up some control over the
platform, whereas the second entails only granting access to the platform to outsiders [14].
When a company devolves all control over a platform, there is no longer a single party who
controls its evolution. In terms of PHR platforms, this would mean for example that the
development activities for a platform are opened up to the open source community, or to
selected commercial software vendors. The Indivo platform is the primary example of this
form of PHR platform openness [15]: starting from a development project at the Harvard
Medical School and Massachusetts Institute of Technology, the project was then opened to
the open source community as well as to Google, Microsoft and other commercial partners.
The second form of openness (granting access) implies that the platform owner maintains
control over its core development while relying on the market to provide complementary
innovation around it. Apple’s App store is a well known example of this approach, where the
company not only preserves control over the platform’s development, but even controls the
transactions on the platform. Microsoft HealthVault is a well known PHR platform that is
open to apps from third party developers, while Microsoft controls the core platform [16].
We position the novelty of our PHR platform in the latter category. MyPHRMachines
provides app developers with open access to the app platform, but it guarantees that
patients can trust the platform in the protection of their personal data. As illustrated in the
remainder, other PHR platforms are either (1) completely closed or (2) pose too tight
restrictions on the type of data that can be managed by the platform. In the latter case, 15
technical guarantees regarding the prevention of data abuse are completely missing.
Therefore, for those PHR platforms that grant app developers access to deploy their apps,
access is only granted to trusted parties that can be held liable in case they violate their
promises to the platform provider and end users. MyPHRMachines makes such app-specific
trust considerations irrelevant, since technical privacy protection measures are already
implemented at the platform level. Consequently, a MyPHRMachines-based App store can
be opened up securely also to non-trusted app developers. PHR system architectures can be
classified into provider-tethered and free-standing ones [17]. For the provider-tethered
variant, the PHR system is essentially a portal extension of Hospital Information Systems
(HISs), which only contain data from one health care provider or institution. Examples in
this category are EPIC MyChart [18] and MyHealtheVet [19], tethered from the EPIC EHR
and the HIS of the US Department of Veterans Affairs, respectively. Free standing PHRs are
stand-alone PHR platforms, which can store data generated and provided by various health
care institutions or by the patient. Examples in this category are HealthVault and Indivo
version X [15]. In principle, this classification only considers the stakeholder controlling the
PHR platform (a single health organization versus an independent party). In practice, all
tethered PHR systems are completely closed, while some free-standing PHR systems make
their platform accessible to external app builders. Still, there are fundamental issues even
for free-standing solutions. Below, we discuss some of these issues for the cases of Microsoft
HealthVault and Indivo X. Microsoft HealthVault provides a set of libraries (e.g. for Java and
.NET developers) to Create, Read, Update, and Delete (CRUD) all types of data in the

16. HealthVault system. The libraries are based on a Web service API. Similarly, Indivo X
enables external software to perform CRUD operations on its health data through XML-
based standard data models. Indivo X is also integrated with SMART [20], a more general
solution to support the exchange of health data among health institutions. SMART provides
an OWL-DL ontology to semantically annotate health data. Unfortunately, for both
platforms, two of the requirements elicited in Section 1 are not satisfied: 1. existing
platforms do not actively prevent apps from violating end-user privacy requirements, and 2.
existing platforms poseimpediments on the transfer of health data. The first issue relates to
Mandl et al.’s conventional requirements for EHR systems, while the second one relates to
their extra requirements for openness. The privacy issue is caused by the fact that neither
HealthVault nor Indivo X apps are executed inside a controlled ecosystem. Instead, app code
is executed on a third party infrastructure and, if users grant an app access to load PHR
data, then that data can travel freely to the servers of the app providers. In terms of liability,
the platform providers (Microsoft and others) push responsibilities to the app builders and
the end-users. This implies that (i) all app builders need to provide terms of use agreement
that promises that patient data will not be abused and (ii) endusers need to review and
consent such agreements for each and every app. While such agreements can protect end-
users ex-post (e.g., legally) they do not physically prevent app providers to maliciously use
the PHR data behind the scenes. Also, for app builders not interested in patient data, this
need for app-specific data use agreements forms an undesirable barrier to entering the app
market. The second issue, i.e., impediments on the transfer of health data, is caused by the
fact that data can only be stored on the 16 P. Van Gorp et al. / Computers in Biology and
Medicine 51 (2014) 14–23 HealthVault or Indivo X servers if it strictly conforms to the data
formats that have been selected by the platform providers. This is a fundamental limitation
since it prevents a market-based evolution of such formats. As a practical example of the
impediment, we observed that it is impossible to store radiology images in the Indivo X
platform and in the European deployment of HealthVault. A practical negative consequence
of this is that, for example, in the case of HealthVault, many third party apps store data
outside the platform’s data repository. This is in conflict with the substitutability of the PHR
apps requirement, since only the apps from specific third parties will be able to access the
radiology data. Although over time platforms such as Indivo X and HealthVault may address
such limitations, we argue that fundamentally, there will always be medically meaningful
data for which a competitive app market moves ahead of platform-imposed standard data
formats. In the remainder, we explain how MyPHRMachines overcomes these issues. 3.
MyPHRMachines as an open and trustable PHR App platform In this paper we focus on the
aspects of MyPHRMachines that make it an open platform. Other details about
MyPHRMachines can be found in the previous work of the authors [21–23].
MyPHRMachines is a cloud-based PHR system. It gives patients convenient access to
remotely running virtual machines (VMs), which give access to all their PHR data. We
informally define apps as light-weight applications that provide very focused functionality
(as opposed to monolythic information systems). In this context, VMs are the
MyPHRMachines-specific “app” technology. VMs run as a service on a trusted and powerful
hardware infrastructure and fulfill the role of app containers. MyPHRMachines apps can be

17. accessed from regular computers and from tablets or mobile phones. Section 3.1
summarizes the technical architecture of MyPHRMachines, while Section 3.2 discusses
specifically the privacy protection as a service enabled by the design of MyPHRMachines. An
example app, i.e. a radiology image viewer, is presented in Section 3.3. While that example
app has been contributed by the MyPHRMachines platform developers, the two apps from
Section 5 are provided by third parties. Section 3.4 briefly explains the process of deploying
new apps to MyPHRMachines. 3.1. Technical architecture MyPHRMachines has a layered
architecture and reuses various robust components such as a commercially available
hypervisor and an open source data cloud with interfaces to commercial data clouds. The
platform is extremely flexible with regards to PHR data formats and middleware and it
makes apps available as a service via thin client technologies. Fig. 1 shows the architecture
of MyPHRMachines. At the highest aggregation level, MyPHRMachines comprises a client
and a server layer. The server layer is further decomposed into an execution layer and a
storage layer. MyPHRMachines relies on thin clients: a client should be able to (1) access the
app store, (2) run a viewer to work with remote VMs and (3) up- and download PHR data
via the data cloud components. The three arrows leaving the Browser component in Fig. 1
show that any device with HTML and Java support already satisfies the above three
requirements, without any MyPHRMachinesspecific software installation. The Native RDP
Client represents native client software required to support function (2) by non-Java
enabled clients, e.g. clients running iOS, which does not support Java at the time of writing.
MyPHRMachines, in fact, relies on the standard Remote Desktop Protocol (RDP)to view
remote VM sessions. The Native Own Client and Dropbox clients support function (3). For
its data cloud functionality, MyPHRMachines relies upon off-the-shelf software from the
mature OwnCloud project [24]. Besides providing secure storage within the
MyPHRMachines infrastructure, the OwnCloud component also enables users to plug in
their DropBox or Google Drive for mounting less sensitive data [25] (see the link connecting
elements of Dropbox to the Private Data Cloud). In the storage layer, Fig. 1 shows also the
Private Network Folders. While the private data cloud requires an ad hoc virtual network to
the OwnCloud server that runs within the MyPHRMachines infrastructure, these mounted
folders are accessible even to VMs that do not have a network interface. Although the
OwnCloud server is residing in a Demilitarized Zone (DMZ [26]), protected by a firewall, it is
not as secure as the mounted folders mechanism since, in theory, an app could hack its way
from the ad hoc network to the OwnCloud server and then to the public internet. This is
impossible for VMs without a network interface. The execution layer of the MyPHRMachines
server contains two components: the Web Portal (or AppStore) and the Hypervisor. The
web portal manages the access control of users to apps. This can be therefore seen as the
“app store” of MyPHRMachines. The app store Fig. 1. Layers in the architecture: apps run as
a service on trusted infrastructure. P. Van Gorp et al. / Computers in Biology and Medicine
51 (2014) 14–23 also communicates with the Hypervisor, which is a generic piece of
software to start, stop, and clone VMs and control their Internet access. MyPHRMachines
currently uses VirtualBox, i.e. an off-theshelf hypervisor, which is heavily used also in other
industries, e.g., banking. Finally, messages between the app store and the hypervisor are
delivered via SSH, a secure and stable communication protocol. Patients can communicate

18. with their health providers in two ways: first, they can delegate the remote access to a VM
and, secondly, they can share the raw PHR data using the underlying data cloud. This
private data cloud provides file sharing features similar to DropBox and Google Drive, but it
also ensures that the physical location of the data is by default within the trusted
MyPHRMachines infrastructure. This feature was added to MyPHRMachines recently (i.e.,
after the publication of our previous work [21–23]). It relates in general to removing
impediments to the transfer of data between trusted parties (cf., the criteria from Section
1). In particular, it enables patients to grant their GP a copy of specific PHR files for the sake
of accountability. Also, thanks to the OwnCloud sync client, patients can conveniently
upload new PHR content (e.g., a copy of a new radiology CD). Open innovation is supported
by MyPHRMachines by the fact that any health care institution or software provider can
contribute a new app by remotely cloning an existing VM image, installing the new software
remotely, and publishing it to the app store. App developers can choose between accessing
health data files directly from the VM file system or accessing data through a more heavy-
weight Application Programmer Interface (API). The platform is flexible because any kind of
middleware that runs on an operating system that can be virtualized can also be used to
build apps. VM sessions in MyPHRMachines are stateless, meaning that data that is written
to the local disk of a VM will be deleted after VM shutdown. This enables app developers to
update their VMs without worrying about migrating patient-specific VM sessions.
MyPHRMachines does enable apps to create or update data persistently in a patient’s PHR.
This is realized by means of a writable mounted folder in the patient’s VMs. Additionally,
data can be persisted via the private data cloud. 3.2. Privacy protection as a platform service
MyPHRMachines protects privacy as a platform service. Although privacy is seen as
essential in the context of the requirements discussed in Section 1, no other platform
provides technical mechanisms for this. This subsection clarifies that, in contrast to the
novelty of having this service, its implementation is relatively simple to realize, given the
architecture described in the previous subsection. MyPHRMachines can provide a privacy
protection service thanks to its very design, which is based on the principle that software
should be moved to data rather than vice versa. Once all software is available in the
MyPHRMachines private cloud, apps no longer need access to external Internet services.
The MyPHRMachines execution layer therefore enforces that published VMs have no
network interface with Internet access. Even if a malicious app developer, for example,
installs malware in a VM, such malware will fail to push data outside of the app container.
PHR platforms lacking the ability to completely block Internet access by apps have to rely
on complex analyses of the data streaming out of their ecosystem (e.g., has the patient
approved access to the data by the app builder? Is the app builder’s server properly
authenticated? Is traffic properly encrypted? Can the data pass over servers that are subject
to the US patriot act? etc.). Note that MyPHRMachines does not guarantee privacy
protection in general. In particular, since MyPHRMachines aims to reduce impediments to
the transfer of data, patients can choose to use the 17 Fig. 2. MyPHRMachines demo app:
basic radiology image viewer in a specialized VM. OwnCloud component in combination
with a US-based cloud storage provider (e.g., DropBox), and therefore be subject, for
instance, to the NSA scrutiny. Yet, MyPHRMachines does guarantee that PHR data is

19. protected from app builders (and their governments). This implies that when a
MyPHRMachines cloud is deployed on EU infrastructure, the NSA could not force US-based
app builders to give access to PHR data on which their apps are applied. This example
implication is of high political relevance in current times.1 3.3. Example app: radiology
image viewer Radiology tests are often repeated due to the loss of a test result or due to
inconvenient provider access to the images. Besides being inconvenient and unhealthy for
patients, this also represents a waste of insurance and taxpayers money. In order to avoid
this waste, insurance companies can simply provide their patients free use of a specialized
Microsoft Windows app (VM) in MyPHRMachines [21]. As illustrated below, that is
sufficient for giving any specialist convenient online access to a patient’s radiology images.
Ge et al. recently presented a novel portal prototype to store and share radiology images
under patient ownership [27]. The MyPHRMachines radiology image viewer app presented
here provides the same functionality as that prototype with a simpler implementation of an
app that is substitutable. The implementation of the app is simpler since it reuses viewer
software that is already embedded in the patient’s radiology CD. Moreover, the functionality
to give a physician access to the viewer is implemented at the MyPHRMachines platform
layer. The app is substitutable since anyone can install a more advanced viewer to a new VM
and offer that to other MyPHRMachines users. Fig. 2 shows tablet and laptop access to the
image viewer app in MyPHRMachines. As explained in Section 3.1, the laptop provides zero-
install access to the specialized app (since the app viewer relies on HTML and Java only).
The tablet is an iPad (for which Java support is not available). Hence, it relies on a native
RDP client for working with the remote VM. Multiple such RDP clients are available
regardless of MyPHRMachines and our radiology viewer app. Therefore, also at this level,
MyPHRMachines supports substitutability. From the usability point of view, the use of a
native RDP client does require users to enter the address and port on which the remote VM
is running. Android tablets (which do support Java) do not have this potential usability
barrier. 1 See http://ec.europa.eu/justice/data-protection/ 18 P. Van Gorp et al. /
Computers in Biology and Medicine 51 (2014) 14–23 Fig. 3. Workflow for contributing a
new app to MyPHRMachines. The delegation of access to radiology images does not require
any app-specific implementation since it is supported by a generic MyPHRMachines
platform feature, i.e. the app store portal (see Fig. 1). That portal enables patients to
delegate access to any of their active VMs. More specifically, for every active VM, patients
can generate an automatic e-mail message which enables the recipient to log in to the
remote VM without signing up for a MyPHRMachines account [21]. Readers are encouraged
to visit the companion Web site https://sites.google.com/site/myphrmachines/ for hands-
on access to this demo. The demo provides anonymous access to a dummy account for
which multiple radiology CDs have been uploaded to the PHR. 3.4. Contributing a new app
to MyPHRMachines The companion Web site of this paper will be maintained to provide up-
to-date instructions for contributing new apps. In this paper, we abstract from the rather
volatile user interface details and focus on the conceptual workflow for deploying new apps
to MyPHRMachines. Technical details have been published before [22,23], so we omit them
here. Fig. 3 sketches the key activities related to new app provisioning. The diagram uses
BPMN, an industrial standard notation for modeling business processes [28]. The upper

20. swimlane shows tasks that are executed by representatives of an external software vendor
while the lower one displays tasks that are executed by employees of an organization
offering the MyPHRMachines platform services. The current deployment of
MyPHRMachines is maintained for academic demonstration purposes only. However,
anybody can contact the authors for leveraging that demonstrator infrastructure. The
workflow model shows at its top left an empty circle with thin edge, representing the
process start event. The first task in the process (i.e., “Request VM Clone”) is executed by the
app builder. As explained in Section 3.1, the web portal enables such app builders to request
a clone of an existing virtual machine. The two external apps presented in Sections 5.2 and 5
are based on clones of Windows and Linux virtual machines respectively. MyPHRMachines
VMs are organized in groups. This is important since otherwise all apps would be visible in
one global namespace, which would not scale. Each group has at least one administrator.
The “Group Admin” lane in Fig. 3 models the tasks that should be executed by such
administrators, in the context of the new app deployment workflow. The dashed arcs
between different lanes represent messages that are sent by the MyPHRMachines portal.
The workflow can only proceed from one task A to a successor task B if (1) A is completed
and (2) for each incoming message flow in B, a message has been received. Following this
semantics, Fig. 3 sketches that the app builder can only deploy his binaries to the cloned VM
after the clone request was approved by an administrator, and after that administrator has
moved the cloned VM to a private group. The purpose of such group is to contain virtual
machines that are not yet ready to be published in the app store. Fig. 3 includes three tasks
that are labeled “Test VM”. The tasks are in the lanes of the app builder, an alpha tester and
a beta tester. All testers use exactly the same software, i.e., exactly the same VM
configuration, but their VM instances will be initialized with their own individual test data.
Each tester can upload test data using the same functionality that end-users use to upload
PHR data. If either the alpha tester or app builder think the VM is not ready yet for a release
to the app store, the workflow moves back to task “Deploy Binaries”. Upon each entry of
that task, the app builder gets private and mutable access to the VM configuration. When
completing the task, the VM configuration is saved such that each tester and subsequent
user will start from the same software configuration context. When the app builder decides
to publish a VM, a group administrator moves it to a public group. Finally, the VM is made
available in the app store. Optionally, a quality check can be first performed by platform
maintenance staff. While the workflow in Fig. 3 focuses on the general case,
MyPHRMachines manages also the access rights and stakeholder notifications for the
various tasks. 4. Radiation exposure monitoring This section introduces our application
scenario of Radiation Exposure Monitoring (REM). We first discuss the need for REM in
Section 4.1 and then provide more technical details about the measurement of radiation
exposure in Section 4.2. 4.1. The need for patient-level rem services X-rays have been
officially classified as a carcinogen by research agencies and prevention centers [29,30]. The
presumption is that significant increase in the population’s cumulative exposure to ionizing
radiation will cause an increased incidence of cancer years down the line. To prevent this, it
is not advisable to take a passive data collection and prevention approach, since “radiation-
induced cancers typically do not occur until 1 or 2 decades or longer after exposure.” [31]

21. The largest epidemiologic study currently available P. Van Gorp et al. / Computers in
Biology and Medicine 51 (2014) 14–23 shows a statistically significant increase in cancer at
radiation dose estimates in excess of 50 mSv [32]. Many computed tomographic (CT) scans
and nuclear medicine studies have effective dose estimates whose cumulative doses easily
exceed this level [31]. Related knowledge is gradually expanding, among others via
international cohort studies [33]. In the meanwhile, “the current annual collective dose
estimate from medical exposure in the United States has been calculated as roughly
equivalent to the total worldwide collective dose generated by the nuclear catastrophe at
Chernobyl” [31,34,35]. REM aims at monitoring the level of exposure to ionizing radiation
by patients. Over the last decades, significant progress has been achieved by monitoring
mean exposure values against so-called Diagnostic Reference Levels (DRLs). Rehani for
example shows that initially some countries had very disturbing high exposures whereas
results were more harmonized after alerting these issues and acting upon them [36]. This is
all however at the national policy level and the exposures for individual patients are not yet
properly governed. The current absence of patient-level monitoring mechanisms means
that individual patients that receive dangerously high exposures will remain un-noticed by
today’s radiology information systems. To the best of our knowledge, this problem has not
received much research attention yet, but one can easily conceive high cancer risk
scenarios. From a healthcare informatics point of view, it is indeed challenging that patients
are likely to undergo scans at different health care institutions during their life. In contrast,
organizing REM support around the patient is very natural since patients can track exactly
the number and type of scans they have undergone. We argue that patients should therefore
be empowered with PHRbased REM application software, enabling them to monitor their
radiation exposure over time and discuss it with their caregivers. This patient
empowerment enables doctors to make better risk assessments and specialize the diagnosis
and treatment plan. Large radiology technology vendors are aware of the aforementioned
issues. However, Brosky has recently clarified on a professional radiologist community
website why it is unrealistic that they will provide integrated REM services soon [37]. The
author describes the results of a European vendor-focused integration workshop. Although
various vendors are offering standardcompliant dose reporting products, these products
are deemed to fail on today’s market. On one hand, there is a vast installation base of legacy
products that (1) do not support the standard reporting interfaces and (2) are not expected
to be phased out. Moreover, even when a standard-compliant reporting system is used,
healthcare administrators still need to configure (or program) the data transfers between
local and centralized REM systems. At such integration workshop, only one of the eight
participating companies provided “a full-scale dose information reporter that enables a
healthcare system to look into the accumulated data and extract actionable information.”
[37]. Other vendors indicated that “If we build it now, no one will buy it”. 4.2. Calculating the
cumulative estimated dose of radiology absorption There is a key difference between the
radiation exposure from the various imaging modalities and the actual amount of radiation
absorbed by a patient. The latter is dependent on the amount and properties of each tissue
encountered by the X-ray beam. As it is not practical to insert radiation detectors into each
organ of every patient, absorbed radiation dose is measured only directly in extreme cases

22. of oncology treatment. Therefore, there is a great need to support the accurate estimation of
absorbed radiation doses. Promising results have been achieved in the area of automatic
CED calculation. More specifically, recent software programs enable 19 the automatic
extraction and analysis of dose-related parameters from image meta-data. So far, these
programs have only been used within complex pipelines. For example, Jahnen et al. [38] use
such an extraction component within the PerMoS chain, which is primarily designed to
monitor DRL conformance at the governmental level. Aware, inc, provides a chain that also
relies on a central dose index registry. The Aware chain does include components at finer
granularity levels: it provides support for monitoring the conformance of individual
technician and physicians and also aims at risk management for individual patients [39].
However, for monitoring patientlevel exposures, the Aware chain assumes that all hospitals
visited by the patient push their data to the central registry. As clarified by Brosky [37], this
is unfortunately not realistic. At the core of the aforementioned chains are, however,
extraction and analysis components that would provide patient-level CED calculations when
provided with patient-level data. In this paper, we use MyPHRMachines to provide patient-
level data securely to the extraction and analysis components of PerMoS (Tudor) and
Aware. 5. REM apps in MyPHRMachines We have deployed the two alternative CED
management components of the Tudor and Aware chains apps in MyPHRMachines. Both
apps visualize received dose values in a patientcentered manner. In the following, we first
discuss the input format requirement of both apps. We then discuss the key functionalities
of the individual apps. Finally, we reason about the implications of having these two
demonstrators. 5.1. App input: DICOM The DICOM standard defines afile format for storing
radiology data on physical media (e.g., CD ROMs) as well as a communication protocol for
transferring images from/to remote servers. File format: DICOM prescribes a standard
format for storing radiology images. Additionally, the standard prescribes how to store
information aboutthe image data. Such information is called “metadata”. Besides
standardizing metadata for characterizing the patient (e.g., name), the standard also
prescribes metadata fields for storing technical equipment and machine parameters (e.g.,
scanner model, scan length, scan modality and scan location). When using full digital
equipment, dose information is stored explicitly in DICOM fields too. For older equipment
types however, such information is missing and therefore the aforementioned simulation
methods need to be employed. The first app (MyPHRDoseReporter) supports full digital
equipment as well as legacy equipment while the second app only supports full digital
equipment. Communication protocol: The second app includes a VM startup script that
automatically collects all the user’s radiology data and sends that via standard DICOM
protocol messages to the Aware REM server that is running locally in the remote VM. From
an end-user’s perspective, the second aspect is an implementation detail. What does matter
for end-users is that both apps require input data stored in the DICOM file format. 5.2.
Tudor app: MyPHRDoseReporter MyPHRDoseReporter is an application supporting the
visualization and management of medical images. The application 20 P. Van Gorp et al. /
Computers in Biology and Medicine 51 (2014) 14–23 integrates various open source
libraries developed by the Public Research Centre “Henri Tudor” into a patient-centered
app. The app supports both the construction of a personal radiology record as well as the

23. inspection thereof. Regarding record building, the app can import data from (virtualized)
patient CDs. The app can harmonize input data in order to overcome differences in the
implementation of the DICOM standard by different scanner manufacturers. Regarding
inspection, the app supports both the interactive viewing of radiology images as well as the
calculation of estimated dose values for various modalities and machine brands. Fig. 4
shows a screenshot with cumulative dose results grouped by imaging modality. The app can
manage input from various radiology imaging modalities, as illustrated in Table 1. Based on
an inspection of all images in a patient record, the app generates a tabular overview of the
received dose. The Computed Tomography (CT) modality involves rotating beams, while
the others involve unidirectional beams. The Computed Tomography Dose Index volumetric
(CTDIvol) value is used as a dose descriptor per CT volume. One CT scan consists of multiple
such volumes and each volume can differ in beam intensity. The Dose Length Product (DLP)
is used to quantify the complete dose for a CT scan. In CT, doses are taken directly from the
DICOM metatadata (if available) or from a Monte Carlo simulation-based application
otherwise (i.e., CT Expo [40]). For Diagnostic Radiology (DR), Fluoroscopy (DF) and
Angiography (XA), MyPHRDoseReporter computes the Dose Area Product (DAP), which
describes the dose quantity per square centimeter. For Mammography (MG),
MyPHRDoseReporter extracts the Mean Glandular Dose (MGD), i.e. the mean dose to the
glandular tissue of the scanned breast. As most MG machines are full digital, no Monte Carlo
based simulation methods are implemented for this modality. All metrics from Table 1 are
well known to radiology specialists. Moreover, since specialists tend to use their own
reference values for these metrics, depending on hospital protocols and national guidelines,
MyPHRDoseReporter simply presents the raw metric results and leaves the interpretation
of the data to the app user. In the long term, the following issues need to be tackled: 1.
understanding which dosimetry concepts are of relevance to patients, 2. understanding
which dosimetry concepts are useful for radiology nurses, 3. understanding how the degree
of uncertainty can be properly presented. These issues are the subject of ongoing research
at Tudor. The app functionality can be extended by (i) including appropriate reference
values in the output report, (ii) aggregating Effective Dose values, (iii) comparing the
received individual dose to easy understandable facts, (iv) adding support for additional
modalities, such as Nuclear Medicine activities, and (v) taking into account the current age
of the patient. Fig. 4. Tudor’s DoseReporter app in MyPHRMachines. Table 1 Dose figures for
the different modalities in MyPHRDoseReporter. Modality DICOM identification Dose figure
Meaning of dose figure Extracted (X) or calculated via simulation (S) Computed tomography
CT Digital radiology Fluroscopy Angiography Mammography DR DF XA MR CTDIvol DLP
DAP DAP DAP MGD Computed tomography dose index, volumetric Dose length product
Dose area product Dose area product Dose area product Mean grandular dose X if available,
S otherwise X if available, S otherwise X X X X P. Van Gorp et al. / Computers in Biology and
Medicine 51 (2014) 14–23 21 Fig. 5. Aware’s MyAccuradREMServer app in
MyPHRMachines. 5.3. Aware app: MyAccuradREMServer The Aware Accurad REM Server is
a software suite that has been designed for empowering radiologists with REM support. The
server is typically connected to all radiology equipment of a hospital and possibly to the
servers of other hospitals. One server typically contains the data of all patients that are

24. known to the hospital. The MyAccuradREMServer app is a patient-centered VM deployment
of such a server. The patient can access all calculated dose figures or delegate access to a
specialist. In contrast to MyPHRDoseReporter, MyAccuradREMServer does not provide
simulation-based estimations based on the DICOM data from legacy scanners. However, it
provides a more convenient user interface. Besides providing convenient table and graph
filtering widgets, the Aware app provides workflows for defining and monitoring radiology
protocols. Fig. 5 shows the app’s visualization of various cumulative dose results for a
dummy patient. The figure shows that the cumulative dose can be displayed per target
region (head versus lumbar spine, in the example). 5.4. Evaluation From an evaluation
perspective, we stress that (i) both apps have been developed and deployed by stakeholders
external to the MyPHRMachines project and (ii) the two apps do not require any extension
to the MyPHRMachines platform to function. This illustrates that the platform is indeed
open to external functionality. We also stress that the platform is unaware of the format of
the data consumed by the apps (i.e., DICOM content). This is in contrast to the requirements
that other app-oriented PHR platforms (e.g., HealthVault and Indivo X) impose on input and
output data formats. Beyond the PHR context, both apps demonstrate that an open,
patientoriented approach to Health Informatics may empower caregivers with functionality
that may not available in HISs. Using the example apps discussed in this paper, patients can
indeed present cumulative dose reports to their radiologist. Such reports cannot usually be
generated by the HIS used by the specialist. Even hospitals equipped with a state-of-the-art
REM server typically are still lacking integration with servers of other hospitals (cf., Section
4.2). 6. Discussion This section discusses how this paper relates to the PHR literature. In
particular, Section 6.1 discusses the advantages and potential pitfalls of using VMs as a more
general PHR platform technology. Section 6.2 focuses on literature about PHR adoption
barriers and facilitators. We include that section to clarify how we have leveraged adoption
studies from other PHR systems in the design of MyPHRMachines. 6.1. Strengths and
potential pitfalls of using virtual machines as apps This section discusses the key strengths
of the VM-based architecture as well as pitfalls that should be avoided by app 22 P. Van
Gorp et al. / Computers in Biology and Medicine 51 (2014) 14–23 developers. The key
strengths of the architecture are its flexibility and trustability. The flexibility strength is
illustrated by the DICOM viewer example: zero-programming effort was required to deploy
an off-the-shelf DICOM viewer into MyPHRMachines. This flexibility is in strong contrast to
the PHR architectures with restrictive APIs (such as Indivo X [15]), which would require a
significantly higher effort to build and maintain the apps described in this paper. The
trustability strength follows from the aforementioned platform feature, which makes it
impossible for apps to send patient data to external servers. The flexibility strength,
however, comes with a pitfall. Since the MyPHRMachines platform does not impose the use
of standard data formats, a naive use of the platform would result in patient records riddled
with syntactically or semantically incompatible fragments. App developers aware of this
pitfall, however, may turn it into an enabler, by deploying apps to translate health record
fragments into a proprietary format (or in the format of a deprecated standard) or into the
latest standard format. Again, we argue that the ability to obtain such functionality from the
App market makes the architecture more scalable than architectures where only the

25. platform owners can provide data conversion functionality. Note that the fact that
MyPHRMachines does not impose any data standards does not prevent the use of standards.
In this paper, for example, we leverage DICOM as a standard for storing radiology data.
Another pitfall along a similar direction is that MyPHRMachines app developers may re-
build low-level functionality, rather than reuse middleware features provided by platforms
with heavyweight APIs. We argue that app developers should install inside their VM any
meaningful middleware they can afford. For example, developers of diabetes-specific apps
may want to deploy SMART middleware to their virtual machine [20]. This would provide
them with libraries to manage lab data coded using the Logical Observation Identifiers
Names and Codes (LOINC) standard. The MyPHRMachines trustability strength also comes
at a cost. By blocking general Internet access for patient-instantiated VMs, apps cannot by
default leverage public Web services. This is unavoidable if one aims at fully dependable,
platform-provided privacy governance of patient data. The example apps described in this
paper do not require such services. For the sake of generalizability, we briefly discuss here
how MyPHRMachines supports the use of public Web services in apps. MyPHRMachines
enables providers of stateless Web services to deploy their service in long-running VMs
inside the MyPHRMachines cloud. Such VMs can be made available securely to
patientspecific VMs. This is the same design choice we adopted for the OwnCloud service
discussed in Section 3.1, which also runs in a long-running VM. In some practical cases,
providers of very popular Web services could refuse to offer their service in this way. If the
providers of such services are considered trustworthy, then VMs can be given controlled
Internet access to a specific domain. Careless use of this platform feature is however a
pitfall that may decrease the trustability of MyPHRMachines apps. that should bolster trust
in such systems and promote their adoption [41]. Patel’s survey [44] investigates the types
of privacy threats patients are really concerned about. In that study, 94% of the surveyed
patients had no privacy concerns towards their physicians [44], while respondents did have
significant privacy concerns towards insurers, employers and the (US) government. To the
best of our knowledge, no scientific studies have been conducted to analyze whether Patel’s
results are valid beyond the US context. Therefore, it remains unclear which company or
organization provides the right trust level for providing the MyPHRMachines platform
professionally at a European or global scale. However, if within a specific context one
trusted party offers the MyPHRMachines platform, then all the untrusted parties will be
able to effectively deploy apps to that ecosystem. In particular, if patients do not trust the
app providers, the MyPHRMachines platform guarantees that apps will notsend data to the
untrusted parties. Kahn et al. conclude that the key technical adoption barrier for PHRs is
that patients have to provide a large amount of information manually, using tedious and
error-prone Web forms [42]. Other studies report that doctors are concerned about patients
being too poorly informed to understand the meaning of their PHR data [45,46]. Family
physicians interviewed by Witry et al. therefore viewed potential in PHRs as a backup
source of medical information secondary to the patient’s medical record as opposed to a
tool for patient self-care [43]. Also, a physician from that study expressed that “For quality
and efficiency it is worth it” and “It is worth it to give it to people for free. You’d save the
(US) government money.” In the context of this paper, we envision that in the long term,

26. data could be pushed automatically to the PHR once produced in a hospital (or once a copy
arrives at a patient’s GP). In our radiology use case, we currently expect patients to upload
the content of a radiology CD. Patients have a good incentive to upload the data, as they do
not have to worry anymore about preserving the physical CD. The MyPHRMachines
platform also provides technical interfaces (beyond the scope of Section 3.1) enabling
hospitals to send the radiology data directly, saving them the time and costs of creating CDs
and sending them to patient homes. Another study concludes that family physicians are
quite open to sharing information with patients, as long as the related information systems
are easy to use and as long as their value to the practice of medicine has been demonstrated
[46]. Regarding usability, we have also taken into account study results by Witry et al. [43].
The authors conclude that physicians are concerned about the time it takes to log into a
PHR system and lookup specific information. We have taken this concern into account by
enabling patients to (1) collect specific information as preparation for a time-critical doctor
meeting and (2) provide one-click physician access to that specific information, as explained
in Section 3.3. Regarding medical relevance, we stress that the REM apps provide
unprecedented support for personalizing patient safety in radiology (cf. Section 4.1, which
stresses the importance of REM in the context of cancer prevention). 6.2. MyPHRMachines
and PHR adoption barriers In relation to the issues described in Section 2, McGraw
acknowledges that today’s PHR systems too often impose consent contracts that jeopardize
patient privacy [41]. Kahn et al. also highlight that providers of PHR software services are
not necessarily subject to US privacy laws and therefore are not as trustworthy as
conventional care providers [42]. Another study by Witry et al. also reveals concerns about
the consent contracts imposed by today’s health record systems [43]. MyPHRMachines
provides privacy at the platform level, making “app”-specific privacy contracts irrelevant.
According to McGraw, 7. Conclusions In this paper, we demonstrated the potential of
MyPHRMachines in terms of its openness. The MyPHRMachines platform satisfies
requirements that had been identified previously by Mandl et al. and that existing platforms
do not currently implement. In particular, PHR platforms suffer from weaknesses related to
the types of data supported as well as to the way in which they handle data privacy. P. Van
Gorp et al. / Computers in Biology and Medicine 51 (2014) 14–23 MyPHRMachines
leverages VMs as flexible and secure execution sandboxes. We have demonstrated the
flexibility of the platform by showing that external developers could deploy apps that deal
with data that cannot be handled by the repositories of other PHR platforms. The privacy
strength follows from the platform design. The VM sandboxes reside in a private cloud and
apps are not allowed to push data outside their sandbox. In our future work, we will
evaluate MyPHRMachines in controlled clinical settings. We will also refine our example
apps and new demonstrators will be designed and implemented, using data from various
types of devices. Finally, we will investigate which organization has sufficient user level
trust to host the MyPHRMachines platform. Conflict of interest statement The authors have
no conflicts of interest to be declared. Acknowledgments The authors wish to thank Joe
Kushi and James Cialdea from Aware, Inc. for contributing the MyAccuradREMServer app.
Moreover, thanks to Adrian Gropper from HealthURL for the valuable discussions on cloud
technologies. References [1] J. Katz, The Silent World of Doctor and Patient, Free Press, New

27. York, 1984. [2] J. Katz, A. Capron, The Silent World of Doctor and Patient, Johns Hopkins
paperback: Medical Ethics, Johns Hopkins University Press, Baltimore, Maryland, 2002. [3]
T.K. Houston, H.E. Ehrenberger, The potential of consumer health informatics, Semin. Oncol.
Nurs. 17 (1) (2001) 41–47. [4] B.A. Eckman, C.A. Bennett, J.H. Kaufman, J.W. Tenner,
Varieties of interoperability in the transformation of the health-care information
infrastructure, IBM Syst. J. 46 (1) (2007) 19–41, http://dx.doi.org/10.1147/sj.461.0019. [5]
Partners Healthcare, Company Information, January 2013, 〈http://www.part
ners.org/about/company-information/default.aspx〉. [6] Oogziekenhuis Rotterdam, The Eye
Care Network, January 2013,〈http://www. oogzorgnetwerk.nl/〉. [7] K. Siau, Health care
informatics, IEEE Trans. Inf. Technol. Biomed. 7 (1) (2003) 1–7,
http://dx.doi.org/10.1109/TITB.2002.805449. [8] D.F. Sittig, Personal health records on
the internet: a snapshot of the pioneers at the end of the 20th century, Int. J. Med. Inf. 65 (1)
(2002) 1–6, http://dx.doi. org/10.1016/S1386-5056(01)00215-5. [9] D.C. Kaelber, S. Shah,
A. Vincent, E. Pan, J.M. Hook, D. Johnston, D.W. Bates, B. Middleton, The Value of Personal
Health Records, Healthcare Information and Management Systems Society, 2008, URL
〈http://www.citl.org/〉. [10] HHS Press Office, Secretary Leavitt Takes New Steps to
Advance Health It – National Collaboration and RFPs Will Pave the Way for Interoperability,
June 2006, URL 〈http://archive.hhs.gov/news/press/2005pres/20050606.html〉. [11] P.C.
Tang, T.H. Lee, Your doctor’s office or the internet? two paths to personal health records, N.
Engl. J. Med. 360 (13) (2009) 1276–1278, http://dx.doi.org/ 10.1056/NEJMp0810264…