Consent Management Architecture for Secure Data Transactions

Jarkko Hyysalo, Harri Hirvonsalo, Jaakko Sauvola and Samuli Tuoriniemi

Faculty of Information Technology and Electrical Engineering, University of Oulu, Pentti Kaiteran katu 1, Oulu, Finland

Keywords: Consent Management, Digital Health, Data Intensive Services, Sensitive Transactions, Security

Architecture.

Abstract: Digitalization of data intensive services presents several challenges, such as how to safely manage and use

the multitude of personal data across various public, private and commercial service providers. Guaranteed

privacy is especially critical in sensitive cases like health data management and processing. A key challenge

and enabler for efficient data utilization is the need for an adequate consent management framework that

meets the General Data Protection Regulation (GDPR). To facilitate sensitive secure data transactions

where end-control always resides with the individual, a consent management architecture (CMA) is defined,

utilizing the new MyData approach. The proposed CMA enables context-driven authorization of multi-

sourced data for safe access by various health services. CMA proof-of-concept and experiences are

described and discussed to concretize and evaluate the suggested architecture. Consent management and

authorization topics are discussed as a service function of the MyData Operator. The technical APIs

required for registering and authorizing data sources and data services via the Operator are demonstrated

and analyzed to expedite development of this important area within the research and industrial communities.

1 INTRODUCTION

Digitalization of data-intensive domains with

associated analytics and services is of growing

economic importance. Enabled through new avenues

of innovation, the many benefits range from basic

process efficiencies and cost savings to the creation

of new service and business models to maximize

customer reach. Creating, managing and utilizing

large volumes of relevant information generated by

multiple sources and entities is required for value-

added service delivery, for efficient professional

practice or, yet more critically, to make timely

decisions in a healthcare setting—for instance,

treatment of an illness or execution of clinical

practice. Preventive and reactive healthcare is

among the most impacted domains now under

pressure to break with old conventions on the

promise of innovation and increased efficiencies

across care chains and personalized services. The

health domain has multiple opportunities to create

new value by exploiting the sourcing of relevant

digital data for useful services and applications.

Digitalization and genuine digital generation of

health data that produces a continuous flow of

historic and present events as interoperable records

offer significant opportunities for progress in this

sector—for example, in self-management of

personal health information. Developments in digital

health have attracted considerable research interest

in recent years. Steinbrook (2008) envisioned new

personalized health services based on better data

sharing with doctors, emergency departments, and

family members; including prescription, fitness and

diet management services; communication with

others with similar health problems; and information

about participation in clinical trials. Steinbrook also

identified new problems arising from digitalization,

such as inaccurate data, risk of losing control of

personal data, lack of data verifiability and the

uncertain implications of new revenue-based health

models involving large corporations such as Google,

Microsoft and others. In a review of electronic

personal health record systems, Archer et al., (2011)

found that dependency on primary care physicians’

electronic medical record systems is hindering

progress toward broader adoption of personalized

health management. Archer et al. called for trials to

evaluate the effectiveness and sustainability of

personal health record systems. Tucker et al., (2009)

identified new opportunities created by cost-

effective, massively parallel sequencing for medical

Hyysalo, J., Hirvonsalo, H., Sauvola, J. and Tuoriniemi, S.

Consent Management Architecture for Secure Data Transactions.

DOI: 10.5220/0005941301250132

In Proceedings of the 11th International Joint Conference on Software Technologies (ICSOFT 2016) - Volume 1: ICSOFT-EA, pages 125-132

ISBN: 978-989-758-194-6

125

genetics, disease research and personal genomic

profiling. In summary, these new opportunities also

bring challenges related to the use of new

information in a socially responsible manner.

To expedite the promise of digitalization,

requirements for a suitable digital health and data-

intensive service architecture in a many-to-many

actor and owner environment must be identified.

While there are many good vertical approaches and

implementations, there are very few scalable generic

solutions other than commercial one-provider

systems. Our approach adopts the open MyData

architecture to specify a system having multiple data

sources with legal and technical touchpoints in

support of new levels of personal data ownership

and control (Byström et al., 2015). This approach

aligns well with the ongoing work on the European

General Data Protection Regulation (GDPR) and

takes account of various stakeholders in a)

generating personalized data and b) offering value-

added services based on the multiple data sources.

This novel approach accumulates value from mass

data, offering meaningful and highly relevant

services, both to individuals and to larger interest

groups. Based on the assumption of personal data

management, where the person is effectively in

charge of their own data, the key issue, both

technically and behaviorally, is how the individual’s

consent is to be managed, and how this works in

practice across multiple data sources, service actors

and end users such as healthcare professionals,

commercial entities or other individuals or groups.

Consent can be defined as permission to process

personal data and must always be given by the Data

Subject to the Data Controller. Consent must be a

freely given, specific, informed and unambiguous

indication of the Data Subject’s wishes.

The present paper focuses on the concept of

consent and consent management architecture

(CMA) in a distributed, multi-actor, multi-source

data environment as in Poikola et al.’s (2015)

MyData approach. We propose a CMA as a basis for

enabling secure transactions; for authorizing data

access to services; and for health-related personal

data management and processing. We believe that

CMA is a crucial enabler in sharing and utilizing

personal data in health information systems and

services. In response to the research question How

should a consent management framework be

designed and built following GDPR?, we address the

implications of sourcing such data and how service-

provider management and processing of personal

data might accommodate the individual as key

consent giver. To address this question, we propose

a novel consent-based authorization architecture,

which is influenced by User Managed Access

(UMA) protocol. In addition, we describe proof-of-

concept implementation to evaluate the potential of

our CMA framework and to prove its value. To the

best of our knowledge, no such implementation of a

general purpose consent management framework

and architecture exists in the literature or among

commercial solutions that meet the GDPR.

The paper is structured as follows. Section 2

discusses related work. Section 3 outlines the

proposed consent management architecture for

secure transactions. Section 4 describes the

implementation of our architecture framework and

describes our experiences. Section 5 discusses the

results, and Section 6 presents conclusions.

2 RELATED WORK

Efficient management of Electronic Health Records

(EHRs) is essential for the creation of new value for

healthcare processes and treatments. However,

within the healthcare domain, given all its legacy

systems, actors and stakeholders, EHRs are seen as a

complex and sensitive issue (Jin et al., 2011). The

most common access control model used in

healthcare domain is Role-Based Access Control

(RBAC), however, it seems that in most cases, only

the healthcare professionals, general practitioners, IT

and pharmacists can access the data (Ferreira et al.,

2007), which is not in line with the GDPR and

MyData principles.

The challenges for health-related personal data

management and processing include also issues of

interoperability; compatibility of user devices with

third party devices, external sensors or measurement

devices; and other issues of usability (Milenković et

al., 2006; Liu et al., 2011a; Liu et al., 2011b;

Jovanov and Milenković, 2011). Limited standards

have also been identified as problematic (Liu et al.,

2011b), including existing wireless communication

standards that fail to provide a secure and trusted

communications infrastructure between devices,

sensors, actuators, health providers, network

providers and so on. Another issue relates to the

requirements of emerging body area networks—for

example, interference problems or security concerns

(Pantelopoulos and Bourbakis, 2010). There are also

severe security-related concerns relating to lack of

confidentiality (Pantelopoulos and Bourbakis, 2010;

Liu et al., 2011b).

Al Ameen et al., (2012) elaborated further on

security concerns, separating these into two

ICSOFT-EA 2016 - 11th International Conference on Software Engineering and Applications

126

categories: system security (administrative level,

physical level, technical level) and information

security (data encryption, data integrality,

authentication and freshness protection). One major

unanswered question concerns who should manage

the data (Milenković et al., 2006; Liu et al., 2011b;

Jovanov and Milenković, 2011), and privacy and

consent-related concerns were also common (cf. Liu

et al., 2011b; Al Ameen et al., 2012).

The forthcoming GDPR presents new challenges.

Traung (2012) argued that considerable work is

required to achieve the goals of GDPR. For

example, by virtue of its length, complexity and

vagueness, GDPR leaves room for interpretation in

terms of its implementation (Kuner, 2012; Koops,

2014), and the text is too complicated to be

understood by data subjects and data controllers

(Blume, 2014). As GDPR is a long and ambitious

text (De Hert and Papakonstantinou, 2012), we have

elected to focus on the consent management issues.

This is because we consider the consent

management framework to be a crucial enabler for

sharing and utilizing personal data in health

information systems and services—but, as noted

above, there is at present no such framework. For

example, in the U.S. healthcare industry, Electronic

Medical Records (EMRs) have been widely adopted,

but consents are still managed primarily by pen and

paper or scanned electronic documents (Yu et al.,

2014). According to Kaye et al. (2015), the situation

in Europe is similarly paper-based. We therefore

argue the need for a simple general purpose consent

management framework to enable movement toward

full digitalization and genuine digital generation and

utilization of health data.

Table 1 sets out the key issues and requirements

for consent management as it relates to GDPR.

A generic, human-centered framework for

consent management is of paramount importance, as

GDPR requires that consent should be freely given,

for a specified purpose, informed and unambiguous

in confirming the data subject’s agreement to

processing of their personal data.

Derived from the literature, the requirements are

addressed within our consent management

framework and indicate how to build a general

purpose consent management architecture that aligns

with the GDPR.

3 CMA OVERVIEW

The GDPR is in later stages of preparation and will

be deployed for personal data-related information

Table 1: Consent management-related issues as requirements for the proposed framework.

TOPIC ISSUE REQUIREMENT

ROLES

Vague and outdated delineation of roles (De Hert and

Papakonstantinou, 2012) and responsibilities (Blume,

2014)

The framework shall identify and define the

roles and responsibilities of important actors.

RULES

Vague rules for further processing of collected data

beyond the originally specified purpose (De Hert and

Papakonstantinou, 2012)

The framework shall define the consent

management mechanisms required for further

processing of data.

WITHDRAWAL Individual right to withdraw consent

The framework shall provide mechanisms for

consent withdrawal.

PRIVACY POLICIES

Different privacy policy requirements (De Hert and

Papakonstantinou, 2012) and different laws (Blume,

2014) in different EU member states

The framework shall have the necessary

readiness and capability to adapt to different

privacy policies.

DATA USAGE

Lack of awareness of when and how one’s own data are

being processed (De Hert and Papakonstantinou, 2012)

The framework shall provide transparent

processing for a person’s own data.

PURPOSE

Data controller’s obligation to delete information as

soon as it is no longer needed (De Hert and

Papakonstantinou, 2012; Blume, 2014)

The framework shall enable data removal.

PORTABILITY RIGHTS

Individual’s right to obtain a copy of their profile as

uploaded to internet platforms in a suitable format for

further personal processing and use (De Hert and

Papakonstantinou, 2012; Voss, 2014)

The framework shall enable data portability.

INTEROPERABILITY

No mention of system interoperability in EU law (De

Hert and Papakonstantinou, 2012)

The framework shall enable interoperability

between systems.

MANAGEMENT OF

INDIVIDUAL DATA

Very limited individual capability to manage one’s own

data (Tene and Wolf, 2014; Gnesi et al., 2014)

The framework shall guarantee the

individual’s right to manage and control

personal data.

PRIVACY POLICIES

Low level of individual expertise to analyze and

manage complex privacy policies (Tene and Wolf,

2014; Gnesi et al., 2014)

The framework shall provide comprehensible

policies (Gnesi et al., 2014).

Consent Management Architecture for Secure Data Transactions

127

management during 2016-2018. To address the lack

of a general purpose consent management

framework, we propose a person-managed data

rights architecture framework, following the

approach and key principles of MyData (Poikola et

al., 2015; Byström et al., 2015) and the key

functional requirements of the GDPR. The top level

requirements state that a) individuals should have

the right and the practical means to manage their

data and privacy according to GDPR attributes; b)

data should be easy to access and use; c) there

should be a way to convert data from single entities

into a meaningful resource that can be used to create

new services; d) in support of an open business

environment, the shared data infrastructure should

enable the coordinated management of personal

data, should ensure interoperability and should make

it easier for different entities (e.g. companies, public

officials and public-private service partnerships) to

comply with tightening data protection regulations;

and e) individuals should be able to change service

providers and to control their data manager(s).

Figure 1: CMA framework with roles, responsibilities and

liabilities according to GDPR and MyData approach.

Figure 1 depicts our consent management

architecture framework. According to requirements,

the CMA is partitioned to Operator(s), Source(s) and

Sink(s), each with distinct and interoperable roles

and responsibilities in terms of consent management

regulation. Our current CMA specification has

borrowed some concepts and naming conventions

(e.g., Protection API and Authorization API and the

concept of Resource Set) from UMA protocol

specifications, but does not conform to UMA

protocol flow.

The CMA framework is based on the definition

of user accounts as i) interoperable and ii)

standardized by account model, managed control

and data flows through API practices. User accounts

can be held and managed by one or more trusted

operators. The key concepts are MyData Operator

and MyData Account. MyData Operator enables

digital consent management and provides MyData

Accounts and related account management services.

MyData Account will host all service contracts and

consent receipts, defining access means and rights to

Data Sinks and Data Sources. MyData Account is

the interface that enables individuals to manage their

personal data across multiple data sources, providers

and individuals.

Other key roles include Account Owner, Data

Source and Data Sink. Actors can take one or more

operational roles; typically, the same organization

would act as Data Source and Data Sink. Account

Owners are individuals who create and use MyData

Accounts to link services and authorize data flows

with consents. Data Sources provide the data for

services that use the data (Data Sinks).

The key requirement is to offer logical paths

enabling the data owner (an individual) to control

their personal data as an unambiguously defined

entity during the multiple creation, storing and

processing events by viable Source(s) and Sink(s).

User accounts can be provided either by

organizations acting on behalf of the account holder

or by account holder(s), who can set up their own

user account services (as when hosting a personal

web service or e-mail server), offering the accounts

as a service.

By virtue of the open architecture and consent

model, developers can build access and services to

this framework using public programming interfaces

and libraries.

The CMA separates flows of data according to

purpose and usage rights. Consent permissions (e.g.,

Table 2: Summary of APIs with providers, utilizers and descriptions.

NAME PROVIDER UTILIZER DESCRIPTION

Protection API Operator Data Source

- Introspection: Verifying authorization status of data request

Authorization API Operator Data Sink

- Refreshes expired proof of authorization when consent is still valid

Data Sink API Data Sink Operator

- Operator-delivered consent and proof-of-authorization

- Consent management in general (CRUD)

Data Source API Data Source Operator

- Operator-delivered consent

- Consent management in general (CRUD)

Data API Data Source Data Sink

- Sink request data from source with resource identifier

ICSOFT-EA 2016 - 11th International Conference on Software Engineering and Applications

128

protection, authorization and control) are managed

by means of a separated set of interfaces and

programming instances, allowing new consent

operators, services and applications to evolve. The

actual personal data flow used by the services is

always executed as a transaction between Source(s)

and Sink(s) entities, with eligible permissions by

operator.

As illustrated in Figure 1, this architectural

arrangement allows for separation of actual user

account management with consent services and

logged service data flows only between data

Source(s) and user(s). In this way, the operator never

stores any personal data (e.g., health data) generated

by any Source(s) but acts as a trusted consent

manager, assigning rights or limits to the use of a

present user’s data, on their behalf.

With clearly defined APIs (see Table 2 for

summary) and operator(s) registry principles, the

operator is able to offer a consolidated view to the

present user account holder of granted permissions,

permission requests and changed permissions.

Source and Sink entities can utilize the generic

CMA framework to access the consent service by

operator APIs. Transfer of data from Source to Sink

happens through Source-provided Data API that

should be accessible by a Sink, either directly or

through a proxy service, combining interfaces from

many Sources (e.g., public officials in a health care

region). Issues impacting interoperability such as

discovery of compatible Sources and Sinks, trust

between networks and data formats have been

addressed, but they are beyond the scope of this

paper.

4 IMPLEMENTATION OF THE

CMA FRAMEWORK

To validate the feasibility of the proposed consent

management framework, we have made a proof-of-

concept implementation of the operator and

minimum viable stub implementations of Source and

Sink. APIs of all entities are implemented as REST

(Representational State Transfer) APIs.

The framework was implemented using Python

language, which was selected because it enables

rapid development and prototyping. We made

(heavy) use of Flask, a Python framework for

building RESTful web services and web

applications. We also utilized Flask-extension Flask-

RESTful, which eases writing of REST APIs. Flask

also provided support for SQLAlchemy, which we

used as Object Relational Mapper (ORM). For

actual database implementation, we originally chose

SQLite, but as the implementation progressed, we

found it necessary to switch over to MySQL.

In its current state, our framework enables

Account Owner to complete the necessary actions to

establish a consented data flow of their data from a

Source to a Sink, involving three main steps: Service

Connection, MyData Authorization and Data

Connection. Each step can be performed only after

the previous step is completed.

4.1 Service Connection

In the service connection step, depicted in Figure 2,

a service (i.e., a Source or a Sink) is connected to a

person’s user account on an operator. During service

connection, the person’s account in the service is

associated with their user account on the operator.

Being connected, operator and service also exchange

information needed to ensure secure communication

of consent information (e.g., agreeing on

cryptographic keys used for signing of consent

receipts and proof-of-authorization sent to a Sink).

Figure 2: Service connection.

4.2 MyData Authorization

In the MyData Authorization step, depicted in

Figure 3, a Source is given consent to provide a

person’s data, and a Sink is given consent to fetch

this data from the specific Source. In other words,

Source is authorized to provide data, and Sink is

authorized to fetch data. In order to unambiguously

identify data referenced by these consents, Operator

generates a resource set, describing data the user has

elected to share to Sink and the resource set

identifier, which is used to refer to the previously

generated resource set. Operator delivers the

resource set and its corresponding ID to Source

within Source’s consent. Only the resource set ID is

delivered to Sink within Sink’s consent. Sink must

use this identifier in data requests it makes to

Source. It is worth noting that Source is not

Consent Management Architecture for Secure Data Transactions

129

explicitly instructed to provide data to a specific

Sink as such. On receiving a request for data, Source

is expecting proof that Sink making the request is

authorized to request the data in question. Operator

delivers this proof-of-authorization to Sink along

with Sink’s consent, and Sink must deliver this proof

with every data request it makes to Source.

Figure 3: MyData authorization.

4.3 Data Connection

In the Data Connection step, depicted in Figure 4,

Sink makes a request to Source for data, using the

resource set identifier delivered by operator in the

previous step. This request must contain proof-of-

authorization to request the data referenced by

resource set identifier. Upon receiving such a

request, Source executes an introspection step, in

which it queries operator about the validity and

extent of the provided proof-of-authorization by

delivering it, along with the requested resource set

ID, to operator. Operator verifies that the received

proof-of-authorization is in fact issued by operator

and that the consent associated with this proof-of-

authorization is still valid (and not, for example,

withdrawn). Operator also verifies that the resource

set Sink has requested is the same resource set as it

was authorized to have. Based on operator’s

response to introspection, Source either rejects and

denies data access or accepts Sink’s data request and

delivers data to Sink.

Figure 4: Data connection.

5 DISCUSSION

Although relatively simple, the CMA framework

still addresses the set requirements, providing a

simple, general purpose consent management

framework and architecture that conforms to the

GDPR. In our framework, the main focus was on

consent and how consent can be used. This is

somewhat similar to what the UMA protocol

defines, but our implementation focuses on use cases

in a distributed, multi-actor and multi-sourcing data

environment while following requirements imposed

by GDPR.

CMA provides one example on how to

implement the MyData approach. On our approach,

data subjects can manage their own consents easily,

following the core idea of MyData—that individuals

are in control of their own data. The implementation

presented in this paper offers a novel way of

addressing the forthcoming GDPR. It provides a

model for human-centred personal data management

using a consent-based approach realized within a

generic consent management architecture

framework, with clarifying roles, responsibilities and

liabilities in line with GDPR and the MyData

approach. This is a practical technical solution that

can be applied to the growing need of individuals to

control their own data, as well as the need of

organizations to meet the requirements of the

GDPR.

Returning to the research question, How should a

consent management framework be designed and

built following GDPR?, we have presented a proof-

of-concept implementation of a CMA architecture

influenced by UMA specifications. The

implementation emphasizes the role of MyData

Operator, which helps to introduce the Sources and

Sinks to each other, simplifying the authorization

process by comparison with the UMA specification.

Another key element is MyData Account, a

personalized communication interface through

which individuals can view, manage and control

their consents easily, in a transparent and

standardized way. This interface can also be

accessed at any time, and standardization is

emphasized to enable interoperability. The ability to

transfer consents enables individuals to choose and

change service providers easily. Improved

interoperability also enables easier secondary use of

data as suggested by Cresswell et al., (2013).

In summary, the theoretical implications here

create new knowledge for organizations developing

solutions for personal health information systems

and services. This work identifies current challenges

ICSOFT-EA 2016 - 11th International Conference on Software Engineering and Applications

130

in consent management and describes potential

solutions for tackling these challenges. The

implications for practice include the experiences and

solutions and, more specifically, our framework,

which offers a means of realizing a consent

management architecture.

Our study also indicates issues and directions for

future research, such as the need for a better

understanding of consent management mechanisms

and architecture. As our consent management

architecture is defined at a general level and is not a

functional or requirements specification, further

work is still needed. Our future work will include

more thorough specification and empirical

evaluation of our framework, especially with regard

to performance and usability, in collaboration with

industry and research organizations.

6 CONCLUSIONS

Significant amounts of personal data are currently

collected by different applications and services,

which can be used for further processing with e.g.

monetizable outcomes. To date, individuals have

typically had little or no control over how their data

are created or used. Privacy laws set strict

requirements for collecting, processing and sharing

personally identifiable information, and utilizing

personal data must begin from free, informed,

specific and explicit consent given by the data

subject. Domain specific solutions for consent

management do exist, but there is strong demand for

more generic cross-domain solutions that would

enable new and legacy systems to share and use

personally identifiable information. Our research

question was addressed by means of a novel

consent-based authorization architecture, and in

addition we presented a proof-of-concept

implementation and discussed our experiences

during implementation.

This paper makes an important contribution to

the secure digitalization of data and personalization

of services in the domains of health and information

systems. Furthermore, our results enable the creation

of new digital health solutions by virtue of a novel

privacy-preserving architecture. Organizations will

also benefit from practical methods of securing an

individual’s consent to the use of personal data, so

improving opportunities to utilize those data to

provide innovative services. Finally, our

implementation confirms that the technologies

already exist to build CMA, although some still need

further development. Improvements are proposed,

such as the centralized operator (MyData Operator),

which lends novelty to our approach, and we

recommend consideration of MyData Operator’s

role in addition to UMA-specified roles to simplify

the authorization process.

This paper has its code available at

https://github.com/dhrproject.

ACKNOWLEDGEMENTS

This research has been supported by a grant from

Tekes–the Finnish Funding Agency for Innovation

as part of Digital Health Revolution programme.

The multi-disciplinary programme is coordinated

and managed by Center for Health and Technology,

University of Oulu, Finland.

REFERENCES

Al Ameen, M., Liu, J., Kwak, K., 2012. Security and

privacy issues in wireless sensor networks for

healthcare applications. Journal of Medical Systems,

36(1), 93–101.

Archer, N., Fevrier-Thomas, U., Lokker, C., McKibbon,

K. A., Straus, S., 2011. Personal health records: A

scoping review. Journal of the American Medical

Informatics Association, 18(4), 515–522.

Blume, P., 2014. The myths pertaining to the proposed

General Data Protection Regulation. International

Data Privacy Law, 4(4), 269–273.

Byström, N., Hirvonsalo, H., Honko, H., Kallonen, A.,

Kortesniemi, Y., Kuikkaniemi, K., Maarala, I.,

Niskanen, I., Poikola, A., Rautiainen, M., Tuoriniemi,

S., 2015. MyData Architecture—The Stack, version

1.0.0. Available at: https://hiit.github.io/mydata-stack/

Cresswell, K.M., Bates, D.W., Sheikh, A., 2013. Ten key

considerations for the successful implementation and

adoption of large-scale health information technology.

Journal of the American Medical Informatics

Association, 20(e1), e9–e13.

De Hert, P., Papakonstantinou, V., 2012. The proposed

data protection Regulation replacing Directive

95/46/EC: A sound system for the protection of

individuals. Computer Law & Security Review, 28(2),

130–142.

Ferreira, A., Ricardo, C.C., Antunes, L., Chadwick, D.,

2007. Access Control: how can it improve patients’

healthcare?. Medical and care compunetics, 4(4), 65.

Gnesi, S., Matteucci, I., Moiso, C., Mori, P., Petrocchi,

M., Vescovi, M., 2014. My data, your data, our data:

Managing privacy preferences in multiple subjects

personal data. In Privacy Technologies and Policy,

154–171. Springer International Publishing.

Jin, J., Ahn, G.J., Hu, H., Covington, M.J., Zhang, X.,

2011. Patient-centric authorization framework for

Consent Management Architecture for Secure Data Transactions

131

electronic healthcare services. Computers & Security,

30(2), 116–127.

Jovanov, E., Milenković, A., 2011. Body area networks

for ubiquitous healthcare applications: Opportunities

and challenges. Journal of Medical Systems, 35(5),

1245–1254.

Kaye, J., Whitley, E.A., Lund, D., Morrison, M., Teare,

H., Melham, K., 2014. Dynamic consent: A patient

interface for twenty-first century research networks.

European Journal of Human Genetics, 23(2), 141–

146.

Koops, B.J., 2014. The trouble with European data

protection law. International Data Privacy Law, 4(4),

250–261.

Kuner, C., 2012. The European Commission's Proposed

Data Protection Regulation: A Copernican Revolution

in European Data Protection Law. Bloomberg BNA

Privacy and Security Law Report, 6, 1–15.

Liu, C., Zhu, Q., Holroyd, K.A., Seng, E.K., 2011a. Status

and trends of mobile-health applications for iOS

devices: A developer's perspective. Journal of Systems

and Software, 84(11), 2022–2033.

Liu, L. S., Shih, P. C., Hayes, G.R., 2011b. Barriers to the

adoption and use of personal health record systems. In

Proceedings of the 2011 iConference, 363–370. ACM.

Milenković, A., Otto, C., Jovanov, E., 2006. Wireless

sensor networks for personal health monitoring: Issues

and an implementation. Computer Communications,

29(13), 2521–2533.

Pantelopoulos, A., Bourbakis, N.G., 2010. A survey on

wearable sensor-based systems for health monitoring

and prognosis. IEEE Transactions on Systems, Man,

and Cybernetics, Part C: Applications and Reviews,

40(1), 1–12.

Poikola A., Kuikkaniemi K., Honko H., 2015. MyData—A

Nordic Model for human-centered personal data

management and processing. Ministry of Transport

and Communications. http://urn.fi/URN:ISBN:978-

952-243-455-5.

Steinbrook, R., 2008. Personally controlled online health

data—the next big thing in medical care? New

England Journal of Medicine, 358(16), 1653.

Tene, O., Wolf, C., 2014. The Draft EU General Data

Protection Regulation: Costs and Paradoxes of

Explicit Consent. The Future of Privacy Forum.

Traung, P., 2012. The Proposed New EU General Data

Protection Regulation: Further Opportunities.

Computer Law Review International, 2, 33–49.

Tucker, T., Marra, M., Friedman, J.M., 2009. Massively

parallel sequencing: The next big thing in genetic

medicine. The American Journal of Human Genetics,

85(2), 142–154.

Voss, W.G., 2014. Looking at European Union Data

Protection Law Reform Through a Different Prism:

The Proposed EU General Data Protection Regulation

Two Years Later.

Journal of Internet Law, 17(9).

Yu, B., Wijesekera, D., Costa, P., 2014. Consent-based

Workflow Control in EMRs. Procedia Technology,

16, 1434–1445.

ICSOFT-EA 2016 - 11th International Conference on Software Engineering and Applications

132