PHRs can either be exclusively controlled by the individual (e.g., via a thumb-drive based PHR system or a smart-card system) or sponsored by a health care provider, health plan, or other commercial vendor. In addition, for the aged, disabled, and children, the PHR may also be controlled by a care manager (e.g., an adult child, parent, relative, or friend of the patient). Depending on the type of PHR used and who has access, there are different security issues that need to be considered.
Security standards for PHRs must address an array of issues including authentication, identity proofing, access consent and control, data integrity, confidentiality, privacy, accountability, and non-repudiation. For example, does the consumer have ultimate control of the information stored in the PHR? How should amendments or deletions be indicated within the PHR? What are the relevant security features for assigning a care-manager or proxy to manage another account holder’s PHR? In this section, we discuss security standards, and highlight potential challenges with respect to the development and implementation of new security standards for PHRs.
Security Standards for Authentication and Access Control
PHR vendors approach security issues such as authentication and access control in various ways. For authentication, vendors may require the account holder to authenticate his/her identity by entering a name and password combination. Other vendors require additional information such as zip code, date of birth, or an answer to a self-selected question. CMS has received feedback that higher levels of security in terms of authentication and authorization are necessary, especially for a PHR designed specifically for Medicare beneficiaries. In 2005, CMS solicited public feedback about its role in the PHR space via a Request for Information. A total of 51 organizations, including vendors, health plans, provider organizations, and trade associations, responded to questions specific to PHRs. Respondents were asked about the types of authentication that should be used for a PHR. Responses ranged from physical tokens and biometrics to a Medicare smart card.
With respect to access control, some PHR vendors enable the account holder to have full access control to view, add, edit, and delete information. Others have functions which enable the account holder to assign read/ write access to all or parts of the PHR via a proxy function. The security implications associated with assigning a proxy are discussed in greater detail later in this section.
Currently, there are a number of security standards that are mature and ready for use. PHRs can employ different security mechanisms and need to carefully balance ease of access and security.Exhibit 7 describes the current security standards for PHRs.
|Identity Proofing||Under review by AHIC||Policy and process issue|
|Authentication||FIPS 190-1FIPS 196-1ASTM E-1985||Kerberos, IHE EUA, LDAP, SAML, WS-Security, IHE XUA|
|Certificates||ASTM E-2212||X.509, LDAP|
|Consent||ASTM E-2211||IHE BPPC, HL7 Consents|
|Access Control||ASTM E-1985||LDAP, HL7 RBAC, ISO PMAC, XACML|
|Integrity||FIPS 180-1 (NIST SHA-1), RFC-1321 (MD5)|
|Confidentiality||ASTM E-2085ASTM E-2086||RFC-2246 (TLS), SSL, RSA, Triple-DES, FIPS-197 (AES), IHE ATNA|
|Accountability||ASTM-2147||RFC-3164 (SysLog), RFC-3881, IHE ATNA|
|Non-Repudiation||ISO-17090||FIPS 186-2, ISO 17090, ASTM E-2084, ASTM E-1762, XADES, IHE DSG|
Integrating the Healthcare Enterprise’s Work on Privacy and Security Issues
Integrating the Healthcare Enterprise (IHE), an initiative designed to improve electronic health care information sharing, has done work in the areas of privacy and security. First, IHE has addressed the encryption of information and audit trails for information to maintain privacy.
Second, IHE has worked on the Basic Patient Privacy Consent (BPPC). The BPPC was implemented as a trial, further refined, and adopted by HITSP in 2007. The BPPC is proposed as the first step for consent management. IHE has tried to devise the BPPC to maintain patient control over the PHR, and enable patients to handle consent issues in multiple ways.
Third, IHE has addressed user authentication issues through the Cross-Enterprise User Assertion (XUA). User authentication or user assertion ensures that it is possible to assert who users are when they try to access the PHR. The XUA work is fairly recent and has been adopted by HITSP. It provides the foundation to convey basic roles for user assertion.
The final area that IHE has been working on related to privacy and security is digital signatures for documents.
Challenges Associated with Developing Security Standards
One of the greatest challenges to developing security standards for PHRs is deciding how much access, use, and control consumers should have over their personal health information. According to Donald Mon, Ph.D., Vice President of Practice Leadership at AHIMA, there is less clarity with respect to standards for PHRs because there is not a broadly accepted policy about how much access, use and control a consumer should have over their PHR. Dr. Mon also noted that while there are prescribed legal procedures for EHRs with respect to documenting information, the same is not true for PHRs. For example, the EHR is a legal record for business and disclosure purposes; rather, deletions are marked as erroneous and amendment can be added.
According to Donald Mon, Ph.D., the industry cannot encumber the consumer with responsibility to maintain a legal record on the clinical side. However, there is no clear answer as to how much control consumers should over the information within their PHR. When developing the PHR-S functional model, the HL7 work group – composed of vendors, consumer advocates, and clinicians – discussed consumer access to and control of information. Vendors in the work group stated that consumers would like the ability to remove information from their PHRs. However, other experts have stated that presenting an incomplete PHR to a clinician will have serious consequences from both a health information exchange standpoint and a clinical standpoint.
One solution offered by the HL7 work group was to flag information that has been deleted or changed within a PHR to alert the clinician. The HL7 PHR-S functional model has a criterion that a flag must indicate that some information in the record has been modified, which communicates important information to the provider. While the flag does not disclose what information has been deleted, it will serve as a reminder to the clinician that information has been deleted, so that the clinician can have an informed conversation with the patient. According to Donald Mon, Ph.D., regardless of whether the flag method proposed by the HL7 work group becomes a law or a best practice, it is necessary to make a policy decision first, and then implement from a technical perspective: ‘After we deal with the social and ethical issues, we can then figure out how to deal with [these issues] within the context of a PHR.’
Security Considerations for People Who Have a Care Manager
For the frail, aged, or disabled, a care manager may be responsible for coordinating health care visits; scheduling appointments, tests, and consultations; transporting the patient to and from the provider; and potentially even assisting in the patient’s admission to different health care facilities. There are several security considerations related to designing a PHR that enables the account holder (the person whose information is embedded in the PHR) to assign his/her care manager as a proxy to the PHR.
While some consumers may be comfortable with authorizing their proxy to have full access to view their entire PHR, others prefer that their proxy or care-manager have access to only certain aspects of their record (e.g., physician information, medications, emergency information, final plans, etc). Vendors are providing account holders with the ability to assign field-by-field access controls to each proxy. For example, in the case of the LifeLedger – a PHR-like product which enables a care-manager to manage an aged individual’s health information – the PHR account holder may assign the care manager (or any number of proxies) three degrees of access: ‘none;’ ‘read only’ or ‘read/write’ to each individual page. As a result, the account holder can control what pages the proxy does or does not see, and whether the proxy can amend information in the PHR. Other vendors address this issue in a slightly different way, providing the account holder with the ability to hide specific sub-sections or elements of the PHR, such as one particular health encounter, from the care-manager or proxy.
The HL7 PHR-S functional model is addressing the issue of proxies via the requirement that vendors must give the account holder the ability to determine what information is available to an authorized account holder of the PHR information. While PHR-S indicates that the account holder should be able to authorize the proxy to update information within the PHR, it does not state how to implement the authorization. PHR-S also says that ‘account-holders should have the ability to mask data on a selective, record, field-by-field, or class basis as one aspect of controlling access to personal health data.’ 
According to Donald Mon, Ph.D., from a technical standpoint, it is not particularly complicated for a software vendor to implement a PHR where the proxy has access to all or none of the account holder’s information. However, from a vendor’s perspective, it is more technically challenging to implement a PHR whereby the proxy has granular access to only parts or specific sub-sections of the PHR.
Do consumers want the ability to assign varying levels of control and read/write access to their proxies or care-manager? David Lansky, Ph.D., suggest consumers are highly segmented in terms of their desire to employ access controls. The expert noted that while some users want to restrict access to providers and other parties by utilizing detailed access controls, between 60 and 80% of consumers would prefer not to navigate the access and consents processes.
Gaps in Security Standards
Currently, there are several critical gaps in PHR security standards:
Authentication practices. While the PHR community broadly accepts that it is necessary for the account holder to be able to authenticate himself/herself to the PHR, there is not a broadly accepted standard for authentication. According to an expert on the PHR-S model, clarifying standards related to authentication is an important and necessary step for the industry.
- Authorization practices. Security standards need to be developed for authorizing a care-manager or proxy to have access to and control over health information in the PHR.
- Audit practices. The National Committee on Vital and Health Statistics recommends that PHR standards enable consumers to audit who has accessed their personal health information.
- Data Access. The industry needs to come to a consensus about ‘blinding’ data or restricting access to subsets of information within the PHR.
- Emergency Override Practices. The industry needs to develop a standard practice for overriding authentication practices in the case of a medical emergency.