Trust Information-Based Privacy Architecture for Ubiquitous Health

Original Paper Trust Information-Based Privacy Architecture for Ubiquitous Health Pekka Sakari Ruotsalainen1*, DSc (Tech); Bernd Blobel2*, PhD; Antto Seppälä1*, MSc; Pirkko Nykänen1*, PhD 1School of Information Sciences, Center for Information and Systems, University of Tampere, Tampere, Finland 2eHealth Competence Center, University Hospital Regensburg, University of Regensburg, Regensburg, Germany *all authors contributed equally Corresponding Author: Pekka Sakari Ruotsalainen, DSc (Tech) School of Information Sciences Center for Information and Systems University of Tampere Kanslerinrinne 1 Tampere, 33014 Finland Phone: 358 505 004 046 Fax: 358 405261336 Email: [email protected]i Abstract Background: Ubiquitous health is defined as a dynamic network of interconnected systems that offers health services independent of time and location to a data subject (DS). The network takes place in open and unsecure information space. It is created and managed by the DS who sets rules that regulate the way personal health information is collected and used. Compared to health care, it is impossible in ubiquitous health to assume the existence of a priori trust between the DS and service providers and to produce privacy using static security services. In ubiquitous health features, business goals and regulations systems followed often remain unknown. Furthermore, health care-specific regulations do not rule the ways health data is processed and shared. To be successful, ubiquitous health requires novel privacy architecture. Objective: The goal of this study was to develop a privacy management architecture that helps the DS to create and dynamically manage the network and to maintain information privacy. The architecture should enable the DS to dynamically define service and system-specific rules that regulate the way subject data is processed. The architecture should provide to the DS reliable trust information about systems and assist in the formulation of privacy policies. Furthermore, the architecture should give feedback upon how systems follow the policies of DS and offer protection against privacy and trust threats existing in ubiquitous environments. Methods: A sequential method that combines methodologies used in system theory, systems engineering, requirement analysis, and system design was used in the study. In the first phase, principles, trust and privacy models, and viewpoints were selected. Thereafter, functional requirements and services were developed on the basis of a careful analysis of existing research published in journals and conference proceedings. Based on principles, models, and requirements, architectural components and their interconnections were developed using system analysis. Results: The architecture mimics the way humans use trust information in decision making, and enables the DS to design system-specific privacy policies using computational trust information that is based on systems’ measured features. The trust attributes that were developed describe the level systems for support awareness and transparency, and how they follow general and domain-specific regulations and laws. The monitoring component of the architecture offers dynamic feedback concerning how the system enforces the polices of DS. Conclusions: The privacy management architecture developed in this study enables the DS to dynamically manage information privacy in ubiquitous health and to define individual policies for all systems considering their trust value and corresponding attributes. The DS can also set policies for secondary use and reuse of health information. The architecture offers protection against privacy threats existing in ubiquitous environments. Although the architecture is targeted to ubiquitous health, it can easily be modified to other ubiquitous applications. (JMIR Mhealth Uhealth 2013;1(2):e23) doi:10.2196/mhealth.2731 JMIR Mhealth Uhealth 2013 | vol. 1 | iss. 2 | e23 | p.1http://mhealth.jmir.org/2013/2/e23/ (page number not for citation purposes) Ruotsalainen et alJMIR MHEALTH AND UHEALTH XSL • FO RenderX KEYWORDS ubiquitous health; privacy; computational trust; policy; context-awareness 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 JMIR Mhealth Uhealth 2013 | vol. 1 | iss. 2 | e23 | p.2http://mhealth.jmir.org/2013/2/e23/ (page number not for citation purposes) Ruotsalainen et alJMIR MHEALTH AND UHEALTH XSL • FO RenderX 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 contextor 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 JMIR Mhealth Uhealth 2013 | vol. 1 | iss. 2 | e23 | p.3http://mhealth.jmir.org/2013/2/e23/ (page number not for citation purposes) Ruotsalainen et alJMIR MHEALTH AND UHEALTH XSL • FO RenderX 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. JMIR Mhealth Uhealth 2013 | vol. 1 | iss. 2 | e23 | p.4http://mhealth.jmir.org/2013/2/e23/ (page number not for citation purposes) Ruotsalainen et alJMIR MHEALTH AND UHEALTH XSL • FO RenderX Figure 1. Method for the development of the THEWS architecture. 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 contextand 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. JMIR Mhealth Uhealth 2013 | vol. 1 | iss. 2 | e23 | p.5http://mhealth.jmir.org/2013/2/e23/ (page number not for citation purposes) Ruotsalainen et alJMIR MHEALTH AND UHEALTH XSL • FO RenderX Table 1. Suitability of common privacy protection and management approaches for ubiquitous health. SuitabilityApproach Security cannot offer reasonable level of privacy in ubiquitous health. Access control alone is insufficient. The DS is not familiar and cannot control authorization rules used inside a system Privacy protection using security services (eg, authentication, authorization, and access control) Health care and health services require the knowledge of the DS’s identityPrivacy control by hiding the DS’s identity Delegation requires knowledge to whom the DS delegates access rights. Systems specifically do not publish this kind of information to the DS Delegation approach Rules deployed in a label might be inadequate and in conflict with the DS policy that may or could not be specified in labels Privacy labels Supports dynamic policies, but requires computer-understandable policy language. Common ontology, ontology harmonization (matching, mapping, etc.), or reasoning is needed Privacy management using contextand content-aware policies All systems do not accept injected or active codeMetadata approach Health services require large amount of PHI for correct and effective services, as incomplete PHI can lead to wrong decisions or prevent the use of services Data filtering and adding noise to data Table 2. Characteristics and weaknesses of common trust models. Characteristics and weaknesses in ubiquitous healthModel Characteristics: Based on belief, attitude, or others’opinions (recommendations)Dispositional trust and recommended trust Weakness: Recommendations are unreliable and based on unsecure opinions. It is difficult or even impossible to check the reliability of others’recommendations Characteristics: Based on belief or attitude that organization has implemented sufficient safeguardsBlind trust Weakness: Does not guarantee trustworthiness Characteristics: Based on assumption that an organization has implemented required regulatory servicesPredefined trust Weakness: Static model. Unsuitable for dynamic environments. Characteristics: Based on organizational or personal labelsTrust label Weakness: Inappropriate granularity and insufficient consideration of dynamic contextual conditions Characteristics: Based on assurance of service providerTrust manifesto Weakness: Based on belief or attitude. The DS should blindly trust Characteristics: Based on subjective opinions of othersReputation Weakness: The reliability of reputations is difficult to measure Characteristics: Based on system’s measured or observed featuresComputational trust Weakness: A simple trust value or rank might offer insufficient information for the DS in designing personal policies Characteristics: Based on risk or threat assessmentRiskand threat-based models Weakness: Difficult or even impossible to measure personal privacy risks Characteristics: Based on credentials issued by authorities. It is targeted to create trust between organizationsTrust management using credentials Weakness: Credentials are static. Difficult to evaluate and require a network of trusted authorities. It is difficult to force everyone and virtual systems to accept credentials or a TA 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 JMIR Mhealth Uhealth 2013 | vol. 1 | iss. 2 | e23 | p.6http://mhealth.jmir.org/2013/2/e23/ (page number not for citation purposes) Ruotsalainen et alJMIR MHEALTH AND UHEALTH XSL • FO RenderX 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. Table 3. Trusts and privacy services for the THEWS architecture. ServiceConcern/Function Trust calculation serviceSystem’s trustworthiness Context service Identification service Trust interpreter service Decision support serviceThe DS’s information autonomy Policy-binding service Monitoring, trust calculation, and notification servicesAwareness and transparency Monitoring and notification servicesThe use of PHI inside the system Monitoring and notification servicesDoes the system use PHI according to the DS’s policies Policy-binding serviceChoice and secondary use and post-release of PHI Metadata (eg, sticky policy or active code for apoptosis) Decision support serviceDesigning privacy policies and comparison and preference formulation Policy management servicePolicy formulation and post-choice and new policy creation Policy assistant service Ontology service Trust calculation serviceSystem’s features and relations Monitoring serviceFeedback and alarm or conflict notice Trust interpreter and policy assistance servicesLearning 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 systemand 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: JMIR Mhealth Uhealth 2013 | vol. 1 | iss. 2 | e23 | p.7http://mhealth.jmir.org/2013/2/e23/ (page number not for citation purposes) Ruotsalainen et alJMIR MHEALTH AND UHEALTH XSL • FO RenderX 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. JMIR Mhealth Uhealth 2013 | vol. 1 | iss. 2 | e23 | p.8http://mhealth.jmir.org/2013/2/e23/ (page number not for citation purposes) Ruotsalainen et alJMIR MHEALTH AND UHEALTH XSL • FO RenderX Figure 2. The framework model for the THEWS architecture. Figure 3. The interconnection of privacy and trust services in the THEWS architecture. JMIR Mhealth Uhealth 2013 | vol. 1 | iss. 2 | e23 | p.9http://mhealth.jmir.org/2013/2/e23/ (page number not for citation purposes) Ruotsalainen et alJMIR MHEALTH AND UHEALTH XSL • FO RenderX