The privacy policy document must be easily accessible to PHR systems users. This document was accessible or available in 23 of the 24 PHRs, with myMediConnect being the only PHR system to lack this characteristic. The details of its privacy policy were in the website’s FAQ section [50]. Of the PHR systems analyzed, 14 indicated that their users are notified of changes to their privacy policy. Changes could be announced on the home page [28,30,32,33,37,38,40-42,44-46] or via email [39]. A total of 17 of the PHR systems allowed users to grant and revoke access to their data, and 10 indicated that users could grant access to their data to health care professionals. Among these, Google Health and Microsoft HealthVault [28,30] also allowed access to be granted to other system users or to certain services or applications (such as insurance companies or pharmacies).

Only 5 of the PHR systems reviewed defined kinds of permissions. The Google Health PHR system [30] determined two access types for services or applications: write-only access and read/write access. The RememberItNow! PHR system [38] defined three kinds of accesses: write, read, and administrator. Microsoft HealthVault [28] established access levels for users and programs. The Healthy Circles PHR system [34] defined read permission and read/write permission. PatientsLikeMe [41] allowed the contents to be public (anyone could access them) or visible (only PatientsLikeMe users could access them). Finally, only 6 PHRs considered data access in case of an emergency. This access could be total [34] or partial [28].

PHRs contain information users’ personal data, which are managed by the user in 20 of the PHRs reviewed. However, MyChart indicated that its users could not manage their own data [47]. Users could only notify the associated health care providers of incorrect data, but not modify them. MyChart was responsible for managing the data. The remainder of the PHR systems did not indicate whether users could manage their data.

A total of 12 PHR systems used aggregated information about users to publish trends or to improve their services [29,30,32-34,37,38,40,41,44,46,48]. Of the PHR systems reviewed, 3 could access users’ identifiable data without their consent [39,45,47].

One mechanism that allowed users to verify whether data confidentiality and integrity were maintained is access audit. In this respect, 9 of the PHR systems permitted users to check who had accessed their data [28,30,32,34,36,38,47,49], and 2 of them allowed users to verify what changes were made [28,30].

PHR systems also presented security measures to maintain data integrity and guarantee confidentiality. Of the PHR systems reviewed, 20 indicated whether they used physical or electronic security measures: 15 of them used physical security measures in their servers. On the other hand, we found 12 PHR systems that used encryption to protect the data during transmission [28,30,32,35,36,38,40,43,46,50], and 4 also stored the data encrypted [35,36,43,46]. And 1, ZebraHealth [31], stated that they regularly reviewed and revised data security plans as required by the evolution of technological and security needs. Some PHR systems even had a privacy seal: Microsoft HealthVault, Healthy Circles, Juniper Health, and dLife were certified by TRUSTe [52].

To avoid unauthorized access of users’ records, an authentication system is required. The most widespread authentication system was the combination of a user ID with a password, which is something the user knows [28-51]. Some PHR systems combined this with the use of an activation code that had been given to users previously [37,47,48,51]. Only 1 PHR used something the user has for authentication. To access MedsFile.com [39], users had to enter the personal identification number on their access card.

As for the access criteria, the most common one was role-based access control [29,31,32,34,36,39,40,42-44,47,48,51]. PHR systems allowed patients, health care providers, insurances, companies, etc, to access records. Access criteria based on location were applied by 1 PHR [40]. This PHR changed the data shown, such as the list of health care providers, depending on the country from which the user accessed the system. Moreover, 2 PHRs enabled users to establish a period of validity for permissions, which were revoked once this period expired [28,38].

Some legislation and statements are satisfied by or related to the PHR system analyzed. A total of 6 systems complied with HIPAA, while another 4 indicated in their privacy policy that they were not covered by HIPAA, although some of their procedures were inspired by this regulation. Finally, another 7 PHR systems complied with the Health on the Net Foundation Code of Conduct (HONcode) principles for trustworthy health information. HONcode is the oldest and most-used ethical and trustworthiness code for medical and health-related information available on the Internet.

In general, most of the PHR systems we reviewed had a document called a privacy policy. This document contains the information related to how the user’s information is managed by the system. The user should be able to access this document [53]. Moreover, users must be notified of changes to the privacy policy, given the importance of this document. To fulfill this requirement, most of the PHR systems published an advertisement on their website, which obliges the user to check the PHR website to verify whether the privacy policy has changed. Some authors [54] believe that direct notification of any change is a better solution. One characteristic not found in the PHRs we reviewed is that of notifying users when their data have been exposed. Some regulations, such as the Directive on Privacy and Electronic Communications of the European Union [55], indicate that users have the right to be notified of any personal information disclosure. Most states in the United States also have data breach notification laws [56], which PHR systems must satisfy. These require a data custodian to report a data breach to the individuals affected, state attorneys general, the media, consumer reporting agencies, or other government agencies. One means to ensure that users trust their data security is to indicate that the PHR website is certified by a certification authority. The PHR systems we reviewed used the TRUSTe [52] certification, which guarantees that the security requirements included in the privacy policies are supported by the website.

With regard to PHR access management, 71% of PHR systems allowed users to grant and revoke access to their data. This characteristic is particularly important because users require more flexible ways of sharing data, allowing the user to choose who can access their data, which data they can access, and at what level of access [57]. A problematic issue is the access to users’ data in case of emergency—that is, when users cannot explicitly grant access. We found that 35% of PHRs considered this case and provided some type of mechanism to permit the appropriate health care professionals (previously authorized by the user) to access the user’s data. Some PHR systems, such as Microsoft HealthVault, allowed users to select what information could be shared and with whom in case of emergency. Nevertheless, emergency access increases the risk of data breaches. Some national laws assume implicit patient consent in an emergency situation [58], which does not guarantee the privacy of patients’ data. Moreover, this unusual access adds an extra complexity level to the access control model [58]. On the other hand, not all users are very inclined to share their data in a health emergency. Users with good or excellent health are less likely to share their data during this kind of situation [59].

Finally, ownership of the PHR is an important issue to consider. In Europe, although the PHR can store patient information from a health care provider, the patient owns only the copy stored in the PHR, not the information stored with the provider [60]. This is, for instance, the case in the Dutch system. Such a system allows users to remove data from their PHR, but they cannot remove data from a hospital EHR. Other approaches allowed users to access but not modify their PHR, such as HealthSpace [57]. This may make the PHR of less value to patients and physicians, as no information flows back, but it does provide more security. In the United States, there is the case of My HealtheVet, which is a PHR system developed by the Department of Veterans Affairs. According My HealtheVet’s privacy policy, although the content is managed by the Department, the PHR is the property of the veteran and she or he can also manage the information [61].

We examined patient-centered PHR systems in this review, and they allow users to manage their data. In other words, users can add, modify, remove, and update their health data in 83% of cases, according to our review. Connecting the PHR to the EHR would lead to more comprehensive data management by patients [62]. However some physicians have expressed their concern about giving patients so much control over their records, because the information stored in PHRs might be less accurate if patients do not know what exactly is included in them, in comparison with non-patient-centered PHRs [63]. Moreover, if a PHR is hacked—and the patient’s data are modified—then, physicians cannot be sure of the correctness of the data [63]. When information comes from several sources, greater privacy and security risks emerge. However, determining the most appropriate strategy remains an open question: to have multiple reliable sources of information, or to have the patient be the only information source.

Few PHRs permit users to check who accessed their data. This aspect should be improved because, according to HIPAA’s Privacy Rule and Security Rule and to ISO 13606, users should be aware of how their information has been shared.

We found that 3 (13%) of PHR systems used information related to users’ accesses and identified user information to monitor system use without the user’s explicit consent. Since the users’ privacy should be guaranteed, their identifiable information should not be accessed without their consent [64]. Half of the PHR systems used de-identified or aggregated user information. However, it is very difficult to retrieve sufficient information when aggregated data are used in order to ensure that patients cannot be identified, so some risk of re-identification will usually remain [8,65]. A further issue is that PHR privacy policies did not indicate what information they aggregated. PHR designers could consider studies such as that of Sweeney, who designed a model called k-anonymity, and the accompanying policies that allow the individual’s information to be protected, because this cannot be distinguished from, at least, k - 1 other individuals’ information [66]. With regard to the information de-identification process, HIPAA indicates that there are two ways to do this: a formal determination by a qualified statistician, or the removal of specified identifiers of the individual and of the individual’s relatives, household members, and employers. Removal of identifiers is adequate only if the entity covered has no actual knowledge that the remaining information could be used to identify the individual. In any case, one of these two means is required [2].

The PHR systems must take physical and electronic measures to protect user information [67]. Of the PHR systems we analyzed, in their privacy policies, 63% indicated their physical measures and 67% explicitly stated their electronic security measures; however, only 4 (17%) stated that the data were encrypted both for transmission over the network and for storage. The most widely used encryption scheme for communications was secure socket layer. However, encryption is only part of the solution to protect data. There are also other threats, such as virus-infected systems, against which the PHR systems must be protected. Although there are no well-documented examples of EHR/PHR systems linked to security breaches [68], designers should consider threats to Web applications at least when they deploy their PHR system. In 2008, over 63% of all documented vulnerabilities affected Web applications [69].

Important for security vulnerability is authentication [70]. All the PHR systems we analyzed used only one authentication method, the use of something the user knows or has. However, two of the following three methods are recommended for inclusion in an identification system: something a person knows, such as login ID; something a person has, such as an access card; or something that identifies a person, such as biometrics. Therefore, designers should incorporate another authentication system to strengthen authentication [71]. Moreover, the use of passwords as an authentication mechanism is exposed to multiple types of attacks, such as electronic monitoring of network traffic to capture information, or unauthorized access to the password file.

Finally, 38% of the PHR systems used cookies to remember that the user had already logged in. Using cookies increases the likelihood of identity attacks because the cookie’s authentication data can be intercepted by a hacker to gain access to the user’s health data [70].

Finally, less than half of the PHR systems we reviewed were based on standards or regulations, and this shows that there is no guarantee that the privacy and security of patients’ data is ensured. The most frequently referenced regulation is HIPAA, used in the United States. HIPAA is a federal law that protects health information and ensures that patients have access to their own medical records while assigning new responsibilities to those in charge of protecting this information. Although PHR systems are not required to meet HIPAA by law, users might believe that their data are better protected if the PHR satisfies HIPAA [72].