Trust Information-Based Privacy Architecture for Ubiquitous Health

Introduction

Overview

Both ubiquitous health and pervasive health are terms that describe a new business model (these terms have been used in many papers synonymously). Similarly to health care, its goal is to make health services available to everyone, but many of its features separate it from health care [1]. According to Ruotsalainen et al, ubiquitous health is a metasystem that is a dynamic network of interconnected systems offering health services to a data subject (DS) in an unsecure information space [1]. Contrary to health care where the services are defined by health professionals, in ubiquitous health, the DS creates the network, selects the systems, and sets rules (policies) that regulate how and by whom the DS’ health information is used and shared. In ubiquitous health, the existence of predefined trust between the DS and systems cannot be assumed, and systems’ features, their business goals, and regulation systems followed are often unknown. Furthermore, health care-specific regulations do not rule the ways health data is processed and shared [1]. It is evident that ubiquitous health features generate privacy and trustworthiness challenges that should be solved to make it successful.

Privacy is a complex, personal, and situation-depending concept that can be interpreted in various ways [2]. Westin defined privacy as “the claim of an individual to determine what information about himself or herself should be known to others and what uses will be made of it by others” [3]. Privacy is also a human right that is protected by international directives and constitutions. Privacy protection approaches aim at hiding user’s identity and/or some part of the personal identifiable information (PII), whereas privacy management offers transparency to the DS concerning the collection and processing of PII.

Trust can be understood as the subjectively perceived probability by a DS that a system will perform an action before the DS can monitor it [4]. It indicates uncertainty about the features of communication partners [5,6]. Trust is also context-dependent and the ways it is formulated vary, for example, it can be based on the recommendation received from others, it can be reputation-based, or it may be a subjective degree of belief of others [7,8].

Privacy and trust are interrelated concepts, that is, “data disclosure means loss of privacy, but an increased level of trustworthiness reduces the need for privacy” [1]. The DS interest is to get maximum benefit from services and at the same time to minimize the loss of privacy.

In health care, internationally accepted principles, good practice rules, and domain-specific legislation define patient’s rights and service providers’ responsibilities. Health care-specific legislation also states how patient’s privacy must be protected [1]. Researchers have started to develop such kind of principles for ubiquitous health. Ruotsalainen et al have developed the THEWS (Trusted eHealth and eWelfare Space) principles for trustworthy ubiquitous health. The THEWS principles state that the DS possesses the right [1]: to verify the trustworthiness any system that collects or processes his or her personal health information (PHI). Principles state that DS should also have the right for controlling the processing of PHI, both inside the systems and between them. DS should define personal privacy policies, which regulate how his or her health data is collected, processed, disclosed, shared, stored, or destroyed. The principles also require the DS to be aware of all events, situations, and contexts where his or her health data is collected, processed, stored, and disclosed.

Furthermore, systems and stakeholders have the responsibility to publish information needed for trust verification and support openness and transparency of data processing.

Ubiquitous health features and its ubiquitous environment suggest that trustworthiness and privacy are real concerns [9,10]. In ubiquitous health, it is difficult to understand the processing of data inside the systems [11], as systems do not always perform in accordance with their policies, and the privacy preferences of DS might conflict with the business objectives of the system [12]. As a result, the DS cannot assume that the existing legal framework guarantees the processing of PHI lawfully and according to the rules proposed by him or her [13,14]. In addition, DS also cannot assume that systems have implemented security rules and functional privacy requirements derived from laws and standards [1,15]. A big challenge in ubiquitous health is that different stakeholders (eg, systems, customers, third parties, and regulators) can have their own privacy policies.

Here we hypothesize that in order to be successful, ubiquitous health requires trustworthiness and privacy management made by the DS. Without these two features, DS will not dare to use its services. Furthermore, the architecture supporting ubiquitous health should fulfill the THEWS principles presented above. As traditional security and trust mechanisms used in today’s health care information systems may not provide adequate security and privacy in ubiquitous health [1,2,16], a novel architecture is required.

Prior Work

The development of ubiquitous systems and the growing use of ubiquitous computing have raised the following question: What kind of trust and privacy models, services, and architectures offers acceptable level of privacy and trustworthiness?

Trust Models

Trust models such as belief, organizational trust, dispositional trust, recommended trust, and direct trust have been proposed for pervasive systems [8,17,18]. Dispositional trust describes the general trusting attitude of the trustor [17]. Direct trust is derived from the outcomes of interactions with peers [19]. In recommended trust, an agent makes a recommendation based on the beliefs that other entity is trustworthy at certain degree. Organizational or institution-based trust is based on the perceived properties of, or the reliance placed on, a system or institution [7]. Reputation is a recommended rating based on the opinions of others [8]. All of them are situational, that is, the amount of trust that a DS experiences depends dynamically on situation and service-specific trust features [20,21].

A trust is typically based on the trustor’s characteristics such as ability, integrity, and benevolence and should not be a blind guess [5]. It is expressed either by value, rating, or ranking or as probability or belief [22]. Trust attributes such as integrity, motivation, competence, and predictability are proposed to measure the confidence level [23]. Attributes proposed by Hussin include trustee’s identifier, certificate, ability, predictability, trustee’s privacy policy, legal requirements, and system’s properties such as transparency, authenticity, confidentiality, and nonrepudiation [24]. Researchers have developed mathematical methods such as Bayesian probability, Beta probability, maximum likelihood, game theory, weighted arithmetic means, and average of weighted recommendations to measure the degree of belief or recommended trust [25-27]. Trust degree can also be measured from interaction frequencies between trustor and trustee [28], or from context-dependent direct and indirect recommendations collected from selected users [19].

In contrast to belief and recommended trust, computational trust built on abstractions of human concept of trust has been proposed by researchers [25,29]. Within ubiquitous computing, computational trust means automation of decisions in the presence of unknown, uncontrollable, and possibly harmful agents [29]. Computational trust value has been calculated using trustor’s experience, recommendations, interactions, knowledge, measurements, distance, and density of events [13,25,28,30,31]. Service level agreements, contractual agreements, reputation based on the brand’s name, trust manifesto, trust negotiation, exchanging and evaluating credentials, and recommendations made by a trust authority (TA) are also widely used in commercial eServices [32,33].

The aforementioned trust models have noticeable weaknesses in ubiquitous environment. Recommendations are unreliable because they are based on unsecure opinions. It is difficult to force everyone to accept certificates or common TA, and many virtual organizations do not have connection to it. A common ontology that is required for successful negotiation and calculation of trust attributes seldom exists. Trust manifesto assumes that the DS blindly trusts that service providers will deliver their promises. Furthermore, the reliability of reputations is difficult to measure, and credentials are difficult to evaluate [25].

Privacy Models and Formula

Many privacy models developed by researchers are useful in ubiquitous environment. Lederer et al proposed a model of situational faces [34]. The model proposed by Hong et al uses control and feedback [10]. The model suggested by Friedwald et al included actors, environment, activity, information flow, control level, and enabling technology [35]. Adams and Sasse look at privacy as preferences and constraints, and use a computer-understandable language for expressing them [36]. Jiang and Landay used an information space model [37], and Kapadia et al applied virtual walls for privacy management [38]. Diaz et al proposed entropy as measure of privacy level [39].

Privacy management model proposed by Lederer et al combined Adams’s perceptual model and Lessing’s societal privacy models [40,41]. In the model by Lederer et al, a preferred privacy level depends on legislation, market features, norms, technology used, nature of personal information disclosed, contextual features, information sensitivity, characteristics of information user, and expected cost-benefit ratio. A limitation of this model is that its variables are qualitative and abstract.

Trust and Privacy Technologies and Solutions

Numerous trust and privacy technologies have been proposed for ubiquitous systems. In Gray’s solution, the trust is based on the belief of a person that systems have implemented proper de-identification structures and safeguards. It also includes a compliance checker and a trust value calculator [42]. PoliCyMaker, KeyNote, Simple Public Key Infrastructure, and Pretty Good Privacy solutions use credentials [43]. The Trust-X approach by Bertino et al uses digital credentials, which are iteratively disclosed and verified [32]. Becerra et al proposed intelligent agents to evaluate which other agents can be trusted [23]. According to the Skopik’s approach, rule-based trust interpretation takes into account the subjective nature of trust [44]. Joshi et al noted that it is possible to make security and privacy decisions based on trust attributes [45].

Computational trust is either based on direct measurements, observed (monitored) features, or past experiences [46]. In ubiquitous environment, successful monitoring requires common ontology and measurable indicators [22]. The trust manager architecture proposed by Salah et al collects trust aspects for calculator that computes a trust score. The architecture also includes recommendation manager, monitor services, context provider, log service, and policy manager [47]. In the EnCoRe architecture, the TA keeps track of promises, manages decryption keys, discloses them, and verifies systems properties [48]. Thereby, the customer should trust on the system’s released willingness to fulfill the personal policies of DS.

Privacy is often protected by using privacy enhancement solutions such as data filtering and minimization, anonymization, and adding noise to disclosed information (eg, data hashing, cloaking, blurring, and identity hiding) [41,49]. In metadata approaches, privacy policies can be injected to application, tagged to the metadata, or added to the database or an active agent [50]. Berghe and Schunter’s “privacy injector” adds privacy rules to existing applications [11]. The EnCoRe architecture uses the sticky policy paradigm where the DS can stick machine-readable rules to the data before it is disclosed [48]. Metadata can include embedded (active) code that enables self-destruction (apoptosis) in the case the environment is not trusted [51]. Apoptosis can also be context- or situation-aware (ie, programmed death) [52]. As per Pallapa et al, active privacy metadata dynamically controls the transparency of data in a context [53].

Other solutions also exist for privacy protection. Kapadia et al created a virtual personal space (a room) to control information flow through its “walls” [38]. In the PICOS platform from Kahl et al, a privacy advisor helps the DS to create own policies [54]. In the United States, a flexible approach that uses privacy and security labels is under development. In this standardized solution, PHI is segmented and security and privacy labels are bound to those segments [55].

In pervasive systems, privacy requirements are typically expressed as policies that are context-dependent. Policies define what is permitted or prohibited, and which are permitted actions [45]. From the DS viewpoint, policy can be understood as a statement (rules) about how a certain system should behave [56]. Policies are typically published in the form of credentials or metadata, and rules are expressed using policy language [33]. The successful use of policies requires policy matching, mismatch notification, policy lifecycle management, risk analysis, regulatory compliance checking, and possibility to model privacy regulations [48,57]. It is also necessary that the DS can enforce personal polices [58]. Policies should also be checked for ontological compatibility [59].

The increasing use of the Internet, peer-to-peer systems, multi-agent systems, and social networks has been main drivers for discussed privacy and trust models and solutions. Unfortunately, most of them are focused on one feature (eg, encryption or context). Ubiquitous health requires much wider approach. Like Bryce et al, we also state that pervasive systems require an architecture that combines dynamic privacy policies, a priori trust validation, privacy management, and a posteriori measurement (ie, feedback) what systems are doing [2]. Regulatory compliance is also needed.

In this paper, we propose a novel privacy management architecture for ubiquitous health. As ubiquitous health is a new concept without widely accepted principles and privacy and trust models, it is necessary to select on which principles and models the architecture is based. THEWS principles, as previously presented, have been selected by the authors on the basis of the architecture, that is, the architecture should be compliant with them. The solution should take into account features of ubiquitous health and enable the DS to dynamically manage the privacy by defining system-specific privacy policies. The architecture should mimic the way humans use trust information in creation of personal policies. The architecture should also offer protection against many known privacy threats existing in ubiquitous environment.

Methods

From system theory and systems engineering perspectives, ubiquitous health is a metasystem that is characterized by its structure, its function/behavior, and how its interrelated components are composed in an ordered way. Instead of creating artificial scenarios or making quantitative privacy risk/threat analysis, a more system-oriented sequential method that combines methodologies used in systems engineering, requirement analysis, and system design is used (Figure 1).

The method used in this study includes the following steps: definition of basic requirements; selection of values, privacy and trust models, and views; identification of concerns; definition of functional requirements; selection of services; developing privacy and trust formula; and designing the architecture. Finally, it is checked how the architecture meets purposes and requirements for which it has been intended.

On the background of processing of health information stay ethical values and codes, principles, and common rules. Selection of these features has also strong impact on the architecture and its services. For some environments (eg, health care), widely accepted codes and rules already exist; however, this is not the case in ubiquitous health. Therefore, the first step is to select privacy and trust models and approaches that are in line with principles and without noticeable weaknesses. This is achieved by carefully analyzing existing research published in journals, conference proceedings, and standards documents. Similarly, identification of concerns and definition of functional requirements are also done. Finally, the architecture combines selected services in such a way that principles and requirements are fulfilled.

In this paper, privacy and trust needs are examined from the DS’s viewpoint. Other views are not discussed. To reduce the complexity, only components that are relevant for the privacy management needs of the DS are included in the architecture.

‎View this figure

Results

General Overview

Ruotsalainen et al have noted that privacy rules in ubiquitous health are based on trust [1]. Therefore, privacy and trust models selected should take into consideration features of ubiquitous health, trust and privacy aspects of systems offering health services, regulatory requirements, and the DS’s privacy needs. The asymmetric relationship between systems providing health services and the DS should also be considered (ie, the DS seldom has the power to force a system to put personal rules into effect). Furthermore, in practice, the DS has no tools to make personal observations of systems’ internal security and privacy features and policies [51,60].

Principles, Models, and Views

In spite that privacy is widely accepted as human right (value), different privacy models do exist in real life. Regulatory and self-regulatory models are widely used [15]. Privacy can also be considered as personal property [20]. Regulatory model is insufficient in ubiquitous environments [13], and self-regulation made by business community gives systems as stronger partner much freedom to set rules [15]. Because in ubiquitous health the DS has the right to set personal rules to regulate and control his or her health information, self-regulation model that uses privacy as the DS’s personal property has been selected for the architecture.

Suitability of widely used privacy protection and management approaches in the context of ubiquitous health is shown in Table 1. Based on Table 1 and the fact that pervasive systems require dynamic and context-aware privacy management [46], the foremost privacy approach for ubiquitous health is privacy management that uses context- and content-aware policies and supports transparency and regulatory compliance.

Trustworthy ubiquitous health requires that used trust model enables the DS to work out the level of trustworthiness of systems. Characteristics and weaknesses of widely used trust models in regard to features of ubiquitous health are shown in Table 2. As a result, trust in ubiquitous health cannot be based on the belief or reputation, and the DS usually does not have a right to verify recommended trust. Credentials typically assume that Hobson choice and privacy labels have inappropriate granularity. Although some researchers assume that the protection power of laws is sufficient and certification offers acceptable level of trust [12], the regulations and certificates are found to be insufficient in ubiquitous health.

Computational trust that is based on systems’ measurable or observed properties can offer reasonable information to the DS in designing personal privacy policies [25]. The limitation that the information content of a single trust value is too low for policy formulation [61] can be overcome by using additional system-specific attributes. Therefore, computational organizational trust with attributes is selected as the trust model for ubiquitous health.

From the DS viewpoint, the architecture should mimic humans’ ways to design policies, support more rational choices than intuition, and give feedback to the DS. Louviere’s stated customer choice method fulfills these requirements by including awareness, learning, evaluation and comparison, preference formulation, and choice and post-choice [62]; hence, it is selected for the method that the DS uses in the formulation of privacy policies.

Identification of Concerns

Typical stakeholders in ubiquitous health are the DS, health service providers, other organizations, and secondary users. Different stakeholders have different concerns [1]. This paper is focused to the DS concerns. The main concerns of the DS are as follows: (1) how trustworthy the system is, (2) why is lack of awareness and transparency in data collection and processing, (3) who is using the data inside a system, (4) how to guarantee that data is processed lawfully, and (5) according to the DS’s policies, how to prevent post-release of data and control unnecessary secondary use.

Functional Requirements

Derived from previously mentioned assumptions and selections and the proposals made by other researchers, the architecture should identify the following functional requirements. The architecture should offer tools for the DS to define purposes of data collection, express computer-understandable rules regarding the sensitivity of data elements, design protection needed, rule how long data is stored, and which data is disclosed and for what purposes [14,48].

The architecture should support dynamic content-, context-, and purpose-aware privacy management. It should also offer to the DS system-specific computational trust information with attributes that describe systems’ features, infrastructures, policies, and relations in advance. Humans’ way to design policies, to support more rational choices than intuition, and to give feedback should need to be mimicked. The architecture must be compliance with Louviere’s stated customer choice method. It should support situations where the DS discloses PHI and where data collection or disclosure is made autonomously by a system. The architecture also enables the DS to be aware of data-processing events, and to set policies regulate the secondary use and reuse of PHI.

Trust and Privacy Services

Services of the architecture should fulfill above-mentioned requirements, and take into account expected concerns. Trust and privacy services selected for the THEWS architecture are shown in Table 3.

Privacy and Trust Formula

The THEWS principles and functional requirements determine that the DS can use trust information in the formulation of privacy policies [1]. The following formula has been developed to illustrate how trust information, privacy variables, and privacy policy are related:

Privacy_policy=f(TI, IS, SE, PU)

In this formula, TI refers to trust_information offered by the architecture to the DS. IS, SE, and PU are privacy variables proposed by Lederer [40]. IS refers to the sensitivity of the data, SE describes the situation where information is used, and PU defines the purpose of data collection or use.

To avoid the drawback of a single calculated trust value and to enable attribute-based creation of personal policies [61], the following trust information formula was developed:

Trust_information=Trust_value+Trust_feature_vector

Trust_feature_vector gives the system- and environment-specific information to the DS about systems’ regulatory compliance and their willingness to follow the DS’s policies and support openness. Slightly modified trust attributes originally proposed by Hussin et al have been selected for trust value calculation [24]:

Trust_value=(E, T, P, PO, Pre, Tran, Ab)

where E represents domain specific environmental factors such as legal requirements and system’s contextual features. T represents the type of service provider’s organization (eg, public health care provider, private health service provider, Internet service provider). P (properties) consists of systems architectural and technological aspects and PO is system’s privacy policy. Predictability (Pre), transparency (Tran), and ability (Ab) are different parameters that can be calculated from the system’s past history or by direct measurements. For Trust_feature_vector, the following formula was developed:

Trust_feature_vector=(DGD, DRB, SPO, DSP, ASP, CD, ATV, AUT, RP, PBL, DSA)

where DGD and DRB describe the level of system’s regulatory compliance. The DGD is the degree of data processing made by the system in compliance with international privacy protection directives. The DRB is the degree of data processing performed by the system compliant with health care-specific laws and rules. SPO and RP are parameters that are related to openness. SPO informs if the system has made its privacy policies openly available, and RP tells the status if the system has published its relationships. DSP, ASP, ATV, and AUT are willingness parameters. DSP describes the degree by which the system follows its own privacy policies. ASP informs that the system either enables or rejects the DS to inject personal policies to PHI collected or processed by the system. The ATV expresses whether the system accepts external monitoring of events related to the processing of PHI, and AUT tells whether the system enables external access to its audit trails. The PBL and CD are trustworthiness parameters. CD informs whether the system has been certified, and PBL informs about the position of the system on the blacklist. The DSA is an optional attribute that can be defined by the DS. For DGD and DRB, a linear scale (0...1) is used, whereas all others attributes have only binary values. In case of no or insufficient data, the attribute value is zero.

Using proposed Trust_information, the DS can predict system’s willingness or ability to process PHI legally and follow rules set by the DS. The Trust_information informs the DS about how much it can trust on a system, how system’s policy and technical architecture look like, and to what extent system’s policy is compliant with domain-specific regulations and laws. If needed, the DS can use attributes to mark a system untrusted (eg, in the case it will not publish its policies nor would accept monitoring). Most attributes can be calculated from information the system has, or should have, published; however, some attributes might require direct observations. Attributes such as DSP can be calculated from the system’s past history.

The THEWS Architecture

A layered framework model that describes trust and privacy services of the THEWS architecture is shown in Figure 2. The top layer of the model consists of common services that are offered to all stakeholders. The middle layer includes privacy and trust services needed. Ubiquitous health, stakeholders, other users, and PHI are located in the lowest layer (ie, network layer).

As it is difficult or even impossible for the DS to evaluate the trustworthiness of systems, an independent agent, the trust calculator (TC), is used for this task. The role of TC is not to make trust decisions. Similar to HL7 Privacy, Access and Security Services architecture, the TC should be understood as an information point that sends trust information to the DS [55].

The TC calculates Trust_information (ie, Trust_value and related Trust_feature_vector) by using the information that system has published, and available contextual data, system’s measured or monitored features, and system’s past history. It also detects malicious or fake systems by using information obtained from context and monitoring services. Two assistance services are offered to the DS: (1) trust interpreter and (2) policy assistance service. The DS can use the trust interpretation to understand the meaning of received Trust_information.

The context service collects systems’ contextual data, interprets it, and makes it available to TC and DS, using ontologies. The DS deploys policy management, policy-binding, policy assistance, and decision support services in policy formulation.

The monitoring service offers feedback, reduces risk, and recognizes policy conflicts. It records and assesses how a system in real life processes PHI. It recognizes policy conflicts and alarms the TC and the DS of possible malicious or illegal use of PHI. The notification service works as communication and transparency tool between the DS, systems and services. Using this service, the DS expresses personal policies to systems that in turn publish their policies and relations.

An architectural model describing the interconnection of the THEWS services is shown in Figure 3. In the architecture, the policy formulation is a decision-making process, where the DS chooses privacy rules, privacy management services, and the amount of PHI he or she wants to trade in according to expected service benefits. The selected rules and services depend on privacy needs, Trust_information, and the purpose of data request. Typical privacy management services that can be activated before data disclosure are encryption, anonymization, and data filtering. The DS may also inject policies and/or active code to the metadata.

The THEWS architecture not only fulfils the THEWS requirements but also offers protection against many of the known privacy threats existing in pervasive systems as shown in Table 4.

‎View this figure

‎View this figure

Discussion

In this study, novel privacy architecture is developed for ubiquitous health. It enables the DS to ensure and manage information privacy by choosing personal context-aware privacy policies for each system with the help of computational trust information that includes a trust value and system-specific trust attributes. The architecture combines many trust and privacy services proposed by researchers for pervasive systems such as trust calculation and interpretation, policy management, policy assistance, policy binding and design, and context services and monitoring. The architecture goes far beyond the security services with traditional access control used in health care, and it also illustrates how the THEWS principles can be realized. Furthermore, the architecture offers protections against many privacy threats caused by ubiquitous computing and unsecure environment. Instead of continuous validation of systems’ trustworthiness, the architecture monitors functioning of the systems, detects and informs the DS of policy conflicts and data misuse, and thereby enables the DS to dynamically change policies.

Contrary to a widely used trust manifesto that is based on incomplete, insufficient, or inconclusive information [33] or a single trust value that offers only Hobson’s choice to the DS, the architecture gives information to the DS that indicates the level of transparency and openness of a system, how system follows health-specific privacy rules and regulations, and how mature the system is to accept the DS’s policies. Using this information and policy assistance, decision support, and policy-binding services of the architecture, the DS can construct context- and content-dependent policy profiles and assign them to systems. The architecture is user-friendly, and there is no need to interactively calculate the trust value against the DS’s dynamic privacy needs.

For all pervasive systems, some of the unsolved privacy challenges are as follows: (1) How to prevent data from being collected and used in a way that DS cannot recognize? (2) How to prevent systems for breaching their promises? and (3) How to prevent the misuse of PHI after it has been released for secondary use?

Regulation and monitoring can give partial solution to first two challenges. Policy agents, self-destroying files, programmed death (apoptosis), destruction of cryptographic keys, and mutation engines have been proposed by researchers to give protection in the case of post-release [52,63]. The flexibility of developed architecture enables the DS to deploy any of these engines to control the secondary use of PHI.

In addition, there remain some more important challenges. The TC should understand both international and national regulations, and rules used by systems. Translation of narrative rules into machine-readable policies is an ongoing challenge [14]. The use of computer-understandable and context-aware polices requires either that all stakeholders accept a common policy language (such as Ponder, KAoS, Security Assertion Markup Language, eXtensible Access Control Markup Language, Rei, XPath-Based Preference Language, P3P, and APPEL) or that they use a method that enables semantically correct transformation between languages, based on ontologies [43,64,65]. Meta-policies such as P3P and Rei are candidates for the latter case [64,66,67]. In ubiquitous health, the use of a single policy language and a common ontology might be impossible. A possible solution is that the TC and the DS simply inform to systems about the ontology and policy language they use. If this is not possible, a service that maintains interoperability between policy languages and offers ontology reasoning should be developed [68]. In addition to policy, context and trust ontologies and other ontologies such as information and communication technology ontologies that describe systems’ architectural and organizational aspects and mechanisms are needed. Considering the future work, the authors will evaluate the architecture, and validate its feasibility and functionality in pilot setting. As a minimum, the proof of concept will be done. The authors will also demonstrate that the proposed solution is technically valid, safe to use, and efficient.