Literature Review and Environmental Scan: Evaluation of Personal Health Records Pilots for Fee-for-Service Medicare Enrollees. Chapter 6: Standards for Personal Health Records

Standards for PHRs are a set of rules that ensure that personal health information can be easily stored, accessed, shared, exchanged, and understood by health care providers, payers, regulators, and consumers.[135] Standards have been recognized as the ‘key to realizing the value of PHR technology.’[136] They not only enforce a common language and architecture for storing and displaying health information, but they also provide the framework for health information exchange. While a number of standards for PHRs are currently available or under development, there are also notable gaps in the PHR standards development space.

The goals of this chapter are three-fold: (1) to describe the current standards for PHRs with respect to interoperability, security, privacy, and portability; (2) to highlight the gaps in standards development activities; and (3) to identify the challenges and issues associated with developing and implementing standards for PHRs.

We begin by providing an overview of the standards development community, identifying the stakeholders in PHR standards development, and discussing the current methods used to develop standards. Then, we provide a discussion of the key PHR standards with respect to interoperability, security, privacy, and portability. For each of the four standards categories, we describe the current standards available, identify gaps, and discuss relevant issues and/or challenges with respect to implementing the standards. We move on to discuss other gaps in standards development, highlight areas of overlap in the current standards development arena, and review relevant international standards development efforts. Finally, we close the chapter with our concluding thoughts, list of best practices, and recommendations for moving forward.

• The Standards Development Community

  • Standards development activities involve a number of stakeholders that represent the interests of the consumer, government, regulators, vendors, consultants, providers, informaticists, and other public and private stakeholders. The standards development community is tasked with addressing complex technical and implementation challenges, and also balancing a host of other policy, medical, and ethical considerations. This section provides a high-level introduction to the key players in the standards development community, and other leading organizations in the PHR space.

    Exhibit 5 Key Players in PHR Standards Development

    

    Exhibit 5 provides an overview of the major entities involved in standards development for PHRs.  A brief description of key players and their respective roles are provided below.

     

    • Federal and State Agencies. The federal government has played a key role in standards development for EHRs and has more recently focused attention on PHRs. The U.S. Department of Health and Human Services (DHHS) established the National Health Information Coordinator position in the Office of the National Coordinator (ONC) to facilitate the development of standards-based electronic health records. Within the ONC, the Office of Interoperability and Standards (OIS) coordinates with other DHHS offices to foster the use of standards and certified technology, and advance the development, adoption, and use of health IT standards nationally.[137] The Center for Medicare and Medicaid Services (CMS) is also currently engaged in testing the feasibility of utilizing personal health records for Medicare beneficiaries. The National Committee on Vital and Health Statistics (NCVHS) created recommendations for PHR standards.[138] Finally, the American Health Information Community (AHIC), a federally chartered advisory board, creates recommendations regarding the development and adoption of health IT and delivers these recommendations to the Secretary of DHHS.
    • Certification Organizations. The Certification Health Care Commission of Health Information Technology (CCHIT) decides whether vendor systems meet standards accepted by the Secretary of DHHS. Governed by a Board of Commissioners, CCHIT approves the final certification criteria and oversees a number of work groups that make recommendations on key issues related to standards. The CCHIT Privacy and Compliance workgroup has been tasked with PHR certification. Mark Leavitt, MD, MPH, Chair of CCHIT, announced CCHIT’s plans to certify PHRs by 2009 or 2010.[139]
    • Standards Development Organizations (SDOs). The American National Standards Institute (ANSI) facilitates the development of standards through an accreditation process. ANSI-accredited Standards Development Organizations (SDOs) produce clinical data standards (sometimes called specifications or protocols) for a specific health care domain. Health care domains include clinical and administrative data, pharmacy, medical devices, imaging, insurance, etc. Currently, more than 200 ANSI-accredited SDOs exist in different sectors, including Health Level Seven (HL7), National Electronics Manufacturers Association, Clinical Data Interchange Standards Consortium, The National Council of Prescription Drug Programs, World Health Organization, Regenstrief Institute for Health Care, College of American Pathologists, ASTM International, Centers for Disease Control, and many others. HL7 developed the PHR-S draft trial standard for usage, and ASTM created the Continuity Care Record (both will be discussed in greater detail later). ANSI decides whether the SDO’s standard meets the requirements necessary for accreditation. The ANSI’s Health Information Technology Standards Panel (HITSP) is a cooperative partnership between public and private sector stakeholders to achieve a broadly accepted set of standards that contribute to interoperability and health information exchange, and also to identify gaps in standards development. The HITSP focuses on breakthrough projects specifically recommended by the American Health Information Community, a federal advisory board, as priorities; projects focus on biosurveillance, consumer empowerment, chronic care, and electronic health records. The International Organization for Standardization (ISO) is a non-governmental organization that also develops information technology standards; the ISO is composed of standards development organizations from 157 countries.
    • Technical Committees and Workgroups. A variety of technical committees and workgroups exist in the PHR space. SDOs create workgroups within their overarching framework to address issues relevant to PHRs and EHRs, and to develop standards. The American Health Information Community (AHIC)’s Consumer Empowerment (CE) workgroup is working towards widespread adoption of PHRs over time.
    • Health Care Providers. Providers have a stake in standards development for PHRs, as there are many advantages to interoperability between PHRs and EHRs as well as PHRs and other systems. Standards ensure adequate linkages with the providers’ existing EHRs, fostering a more seamless exchange of patient information.[140] Standards also provide some assurance that the products that providers seek to purchase are capable of exchanging information with other systems.[141]
    • PHR and EHR Vendors. PHR and EHR vendors are involved in the standards development process. Some collaborate to develop new standards, and others review and test trial standards. A variety of vendors exist in the EHR and PHR space – each developing products that vary in terms of architecture, format, features, functions, and business model. Vendors also serve on workgroups and panels for HITSP and SDOs like HL7. Vendors have become increasingly interested in acquiring CCHIT certification; the certification demonstrates their commitment to the overarching goals of enabling interoperable health information exchange.
    • Health Plans and Health Care Organizations. Many health plans and employers have been advocates of the movement toward PHRs. Given that one of the main goals for health plans and employers is to reduce costs, this stakeholder group generally supports PHRs. PHRs are designed to involve patients in their healthcare, and may potentially reduce health care costs indirectly through increased prevention and disease management activities.[142]
    • Consumers and Consumer Advocates. Consumers are a critical part of the standards development process. In order for PHRs to be successfully adopted, consumers need to feel comfortable with the various standards and policies. Consumer advocate groups have been highly visible in standards development efforts as well, especially with regard to privacy and security issues. For example, the World Privacy Forum, a nonprofit, non-partisan public interest research group, explores PHRs and consumer privacy. In February 2008, the World Privacy Forum issued a consumer advisory about the privacy of PHRs and gaps in privacy standards for PHRs.[143]
    • Employers. Employers are beginning to offer PHRs to their employees. Recent research shows that there is an array of employer-based PHRs in existence, and each offers a variety of services.[144] A 2007 study of PHR uptake by large national employers concluded that employers will need to be involved in the PHR standards development process: ‘Employers need to facilitate and adopt standards for PHRs to enable their development, use, and interoperability. At a minimum, these standards should address the privacy, confidentiality, and security of PHRs.’[145] Given that some types of employers are not considered ‘covered entities’ under the Health Insurance Portability and Accountability Act of 1996 (HIPAA), employers may be especially concerned about the development of standards for privacy.
    • Other Stakeholders. Research organizations, survey groups, information technology firms, experts in the field, and other stakeholders have been highly involved in standards development efforts – providing relevant research findings and fostering dialogue that has helped the industry to assess the needs in the PHR standards space. For example, the Markle Foundation explores how the use of technologies such as EHRs and PHRs can address public needs in the areas of health and national security.[146] Markle’s Connecting for Health provides policy and technical resources focused on networked health information sharing.[147] The American Health Information Management Association (AHIMA) is a professional community that works to improve healthcare via the advancement of best practices and standards for health information management.[148] RWJF and the California HealthCare Foundation are also supporting new research on PHRs through Project HealthDesign, a $4.4 million program that will work to stimulate innovation in the development of PHRs.[149]

    Methods for Standards Development

    The American National Standards Institute (ANSI) facilitates the development of standards from more than 200 ANSI-accredited standards developing organizations in the United States. The ANSI Board of Standards Review approves standards as American National Standards if they meet ANSI’s requirements. The ANSI process for standards development incorporates: stakeholder input and consensus; expert and public review and feedback; formal voting; and an appeal process.[150]

    Standards are vetted through a group or ‘consensus body’ that includes a variety of relevant stakeholders, and then offered up to the public for a review and comment period as draft trial standards. After the comment period, feedback from the public as well as from voting members is incorporated into the draft standard. The appeal process is open to any person who believes that due process principles were not followed during the ANSI-accreditation process.

    The International Organization for Standardization (ISO) uses a process that is similar to ANSI’s method for standard development. The features of ISO’s process include: creating a work group composed of experts from various countries to explore the standard; negotiating the details underlying the standard and gaining feedback from manufacturers, vendors, consumer groups, laboratories, governments, and other professionals; and an approval process that results in International Standard acceptance.[151] To be accepted as an International Standard, two-thirds of the ISO members that were part of the work group must approve the standard, and 75% of all ISO members that vote must approve the standard.[152]

• Standards for Personal Health Records

  • According to David Lansky, Ph.D., Senior Director of the Health Program at the Markle Foundation, about seventy to eighty percent of the standards developed for EHRs are relevant to and potential serviceable for PHRs.  However, there are still a number of gaps in the PHR standards space. This section begins with an overview of the most comprehensive efforts to date focused on developing a framework for PHR functionality. Then, we address standards for PHRs in four categories: interoperability, security, privacy, and portability.

    The PHR-System (PHR-S) Functional Model

    The Health Level Seven (HL7) PHR work group – under the auspices of the HL7 EHR technical committee – developed a PHR-System functional model (PHR-S).[153] The PHR-S may be the first effort to define the basic functions for PHRs.[154] The PHR-S is a draft standard for trial use (DSTU). It provides a common framework for understanding the basic functionality that should be part of any PHR offered to consumers. The model has between 60 and 70 different functions, which describe the requisite functions for a PHR. The model is composed of personal health functions, supportive functions, and information infrastructure functions:

    • The personal health functions enable the consumer to manage his/her health care information, including encounters with providers, preventive activities, and historical clinical data. The functions also enable the consumer to maintain an accurate and up-to-date record of his/her healthcare.
    • The supportive functions address administrative and financial management requirements. The functions manage provider and facility information, health insurance and benefit information, legal documents, consents and authorizations, end-of-life documents and advance directives, and public health related updates.
    • The information infrastructure functions address privacy and security issues, and interoperability between PHR systems and between PHR and EHR systems.

    As a DSTU, the PHR-S will be released into the industry for up to two years where health care organizations, vendors, and consumers can use it for various purposes and provide feedback. Specifically, the trial use period also provides time for PHR vendors to examine what types of activities they need to engage in to conform to the functional model. After two years and appropriate revisions, the model will be balloted for ANSI accreditation. According to Donald Mon, Ph.D., Vice President of Practice Leadership at the American Health Informatics Association (AHIMA), the EHR functional model was designed using the same process, and was a draft standard for trial use for approximately two years before it was balloted.

    To date, there is already growing acceptance of the HL7 PHR-S functional model, as payers such as Blue Cross Blue Shield and Delta Dental are planning to develop a payer-based profile derived from the PHR-S functional model, and providers such as Kaiser Permanente and the Mayo Clinic are leading an effort for a provider-based PHR, and one for health record banking.

    Project HealthDesign’s Functional Requirements and Common Platform Components

    Project HealthDesign is a $4.4 million project funded by RWJF with support from the California HealthCare Foundation that is fostering the development of new PHR applications. Project HealthDesign worked with Sujansky & Associates, LLC to create a set of functional requirements and common platform components for PHR applications.[155] The team worked closely with the project’s nine grantees to identify the functional needs of the projects; findings from this assessment informed the development of a common platform – or infrastructure – for PHR applications. The platform components are software modules for medication list management, calendaring, observations captured in the course of daily living, and identity management. Essentially, these platform components will be the building blocks of PHRs.

    The goals of this project are to: (1) promote the development of personal health applications through the development of needed software resources, and (2) move towards interoperability among PHR applications by creating models for exchanging data and common interfaces that will be accessible to multiple PHR applications.

    Project HealthDesign’s effort to develop functional requirements and common platform components differs from HL7’s work on the PHR-S functional model. While the HL7 PHR-S functional model defines the end-user functionality, the Project HealthDesign components will be used to identify the types of data that the common platform components should handle and the operations that they should provide to enable PHR applications.[156] Thus, while both HL7 and Project HealthDesign address some of the same elements of PHRs, the projects are quite distinct from one another. Project HealthDesign’s efforts are intended to inform future PHR standards development efforts.

    Interoperability Standards

    PHR and EHR standards create opportunities for interoperability. Regardless of how one defines a PHR, interoperability is critical to ensuring that the information used by the patient and provider are linked.[157] One of the goals of interoperability is to ensure that providers can access data from PHRs as seamlessly as possible.[158] Another key aspect of interoperability is the ability of multiple EHRs from different providers to populate the same PHR.

    Current standards address interoperability with respect to both syntax and semantics. Syntax targets the structure of communication, whereas semantics address the meaning of the communication during health information exchange.[159] Both types of interoperability are achieved through standards for data exchange and messaging, terminology, documents, concepts, applications, and architecture. [160]

    Semantic interoperability is the ability of systems to exchange information with one another and have a common understanding and interpretation of that information. Semantics convey the meaning of communication during information exchange.[161] Semantic interoperability is important because it ensures that data can be understood and used by the receiver of the information during information exchange. The relevant standards for semantic interoperability are terminologies such as SNOMED and LOINC and document standards such as HL7 Clinical Document Architecture.Select standards for interoperability are provided in Exhibit 6.

    
    
    

    Exhibit 6 Select Standards for Interoperability

    Standard	Type of Standard	Description
    Systematized Nomenclature of Medicine (SNOMED)	Terminology	In 2003, the U.S. Department of Health and Human Services signed an agreement with the College of American Pathologists to create a unification of medical terminology. The College of American Pathologists developed SNOMED, a licensed standardized medical vocabulary available for free use in the United States. SNOMED is a required standard in interoperability specifications of the U.S. Healthcare Information Technology Standards Panel.
    Logical Observation Identifiers Names and Codes (LOINC)	Terminology	LOINC codes are universal identifiers for laboratory results and clinical data that foster interoperability between reporting systems and care systems. The LOINC database and documentation are maintained by the Regenstrief Institute, and initially created to foster exchange and pooling of clinical data (e.g., blood hemoglobin, serum potassium, vital signs, etc).[162] The LOINC database is crucial because it ensures that an institution’s reporting system can understand clinical data results from multiple producers/sources (laboratory reporting systems) without adopting the producer’s laboratory codes or engaging in extraneous code mapping from every producer’s code system to the institution’s internal code system.[163]
    International Classification of Diseases- 9 (ICD-9)	Terminology	ICD is a terminology standard for medical diagnoses. Version 9 is used for billing and reimbursement purposes in the U.S.
    HL7 Clinical Document Architecture (HL7-CDA)	Data Exchange and Messaging	Health Level Seven is an American National Standards Institute (ANSI)-accredited Standards Development Organization (SDO). Health Level Seven’s domain for producing standards is clinical and administrative data.
    National Council of Prescription Drug Programs (NCPDP)	Data Exchange and Messaging	NCPDP developed a structure for transmitting prescription data (e.g., prescription requests and fulfillment).
    Digital Imaging and Communications in Medicine (DICOM)	Data Exchange	DICOM enables viewing of medical images, such as CT scans, MRIs, and ultrasound.
    RxNorm	Data Exchange	RxNorm is a designated standard for use in federal government systems for exchange of drug related information.[164] RxNorm provides standard names for clinical drugs (both branded and generic) and dose information, and links drug names to many drug vocabularies used in pharmacy management.

    In addition to the standards discussed in Exhibit 5, HL7 released the EHR Interoperability Model (EHR-IM) as a draft standard for trial use in February 2007. The EHR-IM provides a reference list of requirements for interoperable EHRs. The HL7 EHR-IM was created by a public-private partnership led by the HL7 EHR Technical Committee. EHR/IM establishes the requirements for interoperable EHR records.[165]

• Continuity of Care Record Versus Continuity of Care Document as the Basis for Interoperable Information

  • Document standards are essential to achieving interoperability between PHR systems and between PHRs and EHRs.[166] Two types of common document standards are the Continuity of Care Record (CCR) and the Continuity of Care Document (CCD). The CCR and CCD are standard specifications developed by different groups of organizations to achieve similar goals: improved continuity of healthcare, a reduction in medical errors, and improved health information transportability between patients, providers, and health care institutions. It is particularly important to note that the CCD or CCR is not the underlying personal health record itself; rather it is an interchange. The CCD and CCR provide the ability for one record to extract information, and for the next record to insert the information extracted into its own system.

    The CCR is a standard specification that has been developed by ASTM International, the Massachusetts Medical Society (MMS), the Health Information Management and Systems Society (HIMSS), the American Academy of Family Physicians (AAFP), and the American Academy of Pediatrics.

    ASTM’s CCR is an XML-based set of data from health care records, medical legal documents, and health care encounters. The CCR is the clinical record of the patient’s current and historical health care status. [167]^,[168] The basis for CCR is a Patient Care Referral Form developed by the Massachusetts Department of Public Health. Basic patient information is included, such as patient and provider information, insurance, patient health status, recent care provided, care plan information, and reason for referral or transfer.[169] One of the CCR’s goals is to foster health information transportability between providers, such as when a patient is referred, transferred to, or seen by another provider. The CCR was designed to ensure that adequate information is collected on a patient prior to referral or transfer so that the information can be exchanged.

    The Continuity of Care Document (CCD) was developed as a result of collaboration between ASTM and HL7. HL7 is a not-for-profit, international standards development organization that is accredited by the ANSI. Both ASTM and HL7 were working independently to develop a standard for health information exchange. ASTM developed the CCR, while HL7 focused on developing the Care Record Summary. Both ASTM and HL7’s efforts were targeted at developing a standard to produce an electronic patient care summary that could be exported and read by EHRs and PHRs.[170] In 2005, ASTM and HL7 signed a memorandum of understanding to collaborate and create the CCD.

    The CCD has been said to combine the ‘best of HL7 technologies’ and the ‘rich experience of ASTM’s CCR with clinical data representation.’[171] The CCD describes the use of the CCR standard dataset so that it can function within the HL7 Clinical Document Architecture (CDA). HL7 members were balloted regarding the adoption of CCD. The CCD was a successful ballot, concluding on January 7, 2007, and termed a ‘very significant development for healthcare IT’ and ‘a milestone in the standards world.’[172]

    In February 2007, the Health Information Technology Standards Panel (HITSP) of the American National Standards Institute (ANSI) approved the CCD, recognizing the harmonization of the ASTM and HL7’s standards.[173] Currently, both the CCD and the CCR are used to transfer health information electronically among providers.

    Some experts have questioned the adequacy of the minimum data set used in the CCR and CCD. A CCR can have up to 17 categories of information, and each category contains structured fields rather than free text. However, one key concern is whether the CCR and CCD capture all of the necessary information resulting from a health care encounter. The National Committee on Vital and Health Statistics Subcommittee on Privacy and Security noted that the CCR and CCD’s minimum data sets may be unnecessarily omitting important health information, if this information does not fit neatly into one of the structured data fields.[174] In other words, consumer friendly language and informal medical data needs to be mapped to the structured, technical medical jargon.

    Since the development of CCD, there has been some controversy regarding whether the CCD or the CCR should be the basis for interoperable information for PHRs. Specifically, should PHR vendors use the CCD or CCR? According to Donald Mon, Ph.D., Vice President of Practice Leadership at AHIMA, larger vendors, which have likely adopted many of HL7’s specifications already, may find it easier to use the CCD. This is because the CCD is already part of the HL7 CDA architecture. Other vendors that do not utilize the HL7 CDA architecture can choose to use either the CCD or CCR just as easily.

    The PHR-S functional model, developed by the HL7 work group, is agnostic in terms of specifying the CCD or CCR, so that the market can decide which approach to adopt. According to an expert from the HL7 work group, both CCD and CCR-related activities are proceeding.

    Vendors have also adopted the various standards. Microsoft’s HealthVault, while not a PHR, is a platform that has the ability to service numerous personal health applications (PHAs) – and thus, is important to the future of PHRs. Taking a ‘standards agnostic’ approach to interoperability, Microsoft has created data exchange interfaces that are compliant with both the CCD and the CCR.[175]

• Gaps In Interoperability Standards

  • The National Committee on Vital and Health Statistics of the U.S. Department of Health and Human Services (DHHS) determined that interoperability standards development efforts for PHR systems should focus mapping formal medical terms to consumer-oriented concepts and terms.[176] In addition, the Committee recommended that DHHS should encourage the adoption of standards for PHRs that are currently used to promote the interoperability of EHRs. The Committee also determined that the private sector, vendors, and health care institutions should adopt data content and exchange standards based on standards accepted for EHRs.[177]

    Another interoperability standards gap is for workflow processes related to ‘request changes’. According to HITSP, there are no known standards that govern patient-requested changes to the PHR.[178] Request changes involve three key steps. First, the annotated document is transmitted to the original provider or institution for confirmation. Second, the original provider confirms that he/she has received and read the annotation. Third, the annotated document is sent back to the consumer’s PHR and indicates that a change has been made. Standards need to be developed to govern each step of the workflow. Standards also need to be developed to address more complicated situations, such as if the original provider is not available to read/ receive the annotation, or if the provider refuses to respond to the request change.[179]

    Standards are also needed to address more complicated situations, such as if the PHR is offered by a health plan. Dr. Archelle Georgiou, an independent consultant, noted that in this case, the ‘request change’ process may be more challenging. If the PHR is offered by a health plan, the originator of the data is actually the provider (hospital/doctor/facility) that submitted the data through claims. In order to change the data, the provider would potentially need to resubmit a claim – which is unlikely to be a feasible approach if the claim has been processed and paid.

    Other more complicated situations that need to be considered are if the original provider is not available to read and/or receive the annotation, or if the provider refuses to respond to the ‘request change’.[180]

• Security Standards

  • 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.[181] 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.[182] 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.[183]

    Exhibit 7 Security Standards for PHRs

    Area	Policy/Process	Technology
    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.[184] 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.[185] 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.’ [186]

    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.

• PHR Privacy Policies and Standards

  • Privacy of personal health information is a key concern for consumers of PHRs. A 2005 survey conducted by CHCF in collaboration with Forrester Researcher found that two-thirds of the sample of 2,000 consumers (1,000 nationally and 1,000 in California) said they were ‘very concerned’ (36%) or ‘somewhat concerned’ (31%) about the privacy of their health records.[187] Research also suggests that consumers are concerned about the types of information collected and entered into the PHR; how the information is handled internally; and whether and how the information is provided to any external entities.[188] Clearly there is a need for privacy standards and privacy policies for PHRs. However, there is not yet a consensus among PHR service providers about the specific elements that should be in all PHR privacy policies. [189] Experts have attested that the widespread adoption of PHRs will largely be a function of public confidence and trust that personal health information will be adequately protected.[190]

    This section addresses privacy issues related to PHRs. First, we discuss privacy standards and issues related to privacy with respect to personal health information stored in PHRs. Then we present an overview of several PHR privacy policies under development. It is important to note that the privacy standards section and the security standards section are highly related, as many aspects of privacy are entwined with security issues.

    Challenges Associated with Developing Privacy Standards for PHRs

    There are a number of challenges associated with developing privacy standards for PHRs. In this section, we discuss the following challenges:

    1. There are no statutes or standards that define PHR service providers’ legal responsibilities.
    2. Consumers are misinformed about their privacy rights with respect to personal health information under HIPAA.
    3. Privacy standards for employer-provided PHRs will need to be considered, especially since HIPAA does not cover some employers.
    4. PHR vendors or third parties that are not covered by HIPAA do not need to notify consumers of their privacy policies and practices related to secondary uses of personal health information. As a result, consumers may be unaware that their personal health information is being used and disclosed to other entities in the U.S. or abroad for secondary.
    5. States have different laws governing privacy and security of personal health information.
    6. Privacy standards must balance the needs for privacy and confidentiality, with the need to maintain an accurate medical record.

    The first key challenge associated with developing a privacy standard for PHRs is defining the legal responsibilities of PHR service providers, given that they are non-covered entities under the Health Insurance Portability and Accountability Act (HIPAA). The National Committee on Vital and Health Statistics (NCVHS) at the Department of Health and Human Services (DHHS) concluded that there are no statutes or standards that define PHR service providers’ legal responsibilities.

    Under HIPAA, ‘covered entities’ are asked to provide consumers with information about their privacy policies and practices. Covered entities include health plans, health care clearinghouses, and health care providers that engage in electronic transactions for which HIPAA standards have been adopted.[191] Entities such as PHR vendors, employers, certain types of insurers, providers that do not engage in electronic transactions for which HIPAA standards have been adopted, and third-party data warehouses are all not covered by HIPAA, and thus not required to comply with HIPAA regulations.[192] Privacy policies will need to clearly outline whether the PHR vendor is covered by the HIPAA privacy policy.

    A second challenge is that research suggests that consumers are misinformed about their privacy rights with respect to personal health information under HIPAA.[4] For example, when PHR vendors state that they are ‘compliant with HIPAA’ this does not mean that they are ‘covered under HIPAA’. This is an important distinction that consumers may not understand.[193] Such a distinction may be confusing, and further necessitates the development of a PHR privacy policy and privacy standards, more generally.

    A third issue is that HIPAA does not cover some employers, and thus, privacy standards for employer-provided PHRs will also need to be considered. HIPAA does not consider employers who collect information directly from employees (e.g., for a pre-employment physical, job application, or via an employee assistance or wellness program) to be ‘covered entities.’[194] Given that PHRs are being developed by certain employers and other entities that are not covered by the HIPAA privacy rule, privacy standards will need to be developed with respect to the use and disclosure of personal health information within employer-provided PHRs. A 2007 CHCF issue brief concluded that employers will need to develop standards that ‘at a minimum address privacy, security, and confidentiality of PHRs.’[195]

    A fourth challenge is that non-covered entities, such as PHR vendors, do not need to notify consumers of their privacy policies and practices (e.g., secondary uses of data for other purposes, such as marketing, population health purposes, other purposes) with respect to personal health information.[196] The NCVHS concluded that: ‘The Committee is unaware of any requirement that compels PHR vendors not covered by HIPAA to provide to consumers the terms and conditions governing the privacy of their personal data.’[197] Thus, consumers may be unaware that their personal health information is being used and disclosed to other entities in the U.S. or abroad for secondary purposes. This is a major concern for consumers with a PHR service provider that involves an outside business partner like a third party data warehouse. Lecker et al. (2007) studied PHR privacy policies for the Department of Health and Human Services and found that only 3% (one in 30) of PHR privacy policies indicated that consumers needed to explicitly consent before the PHR vendor could share the data in their PHRs.[198] None of the privacy policies studied identified the PHR vendor’s third party partners. This study demonstrates that even though consumers have not given explicit consent to share their personal health information with a third party or for other purposes such as marketing, consumers may still be at risk due to the construct of the PHR vendor’s privacy policy. [199]

    A fifth challenge is that states have different laws governing privacy and security of personal health information, and consumers may not be aware of their rights. For example, while California has stringent privacy and security laws governing the use of personal health information that are layered on top of the HIPAA privacy rule, other states have more limited regulations.[200] A February 2008 issue brief by CHCF explored the issue of consumer control over personal health information, and determined that the current legal system ‘falls short as a viable legal framework for health information custodians,’ such as PHRs.[201] Existing federal and state laws will need to be considered when developing PHR privacy standards.

    A final key challenge associated with developing a privacy policy for PHRs is balancing the need for consumer privacy and confidentiality, with the need for an accurate medical record. Experts have debated the issues of access and control from a privacy standpoint. What degree of control should consumers have over the information in their PHR? Some believe that account holders should have the ability to prevent access to certain aspects of the record or ‘blind’ sensitive information within the PHR. Others are concerned about enabling consumers to blind or delete health information, as omissions may lead to deleterious clinical implications.

    In June 2006, NCVHS released its report titled Privacy and Confidentiality in the Nationwide Health Information Network, which includes recommendations on consumer rights over their personal health information and also covers a host of other issues ranging from regulatory issues to recommendations for maintaining and establishing the public trust.[202] These recommendations were presented to the U.S. Secretary of Health, Michael O. Levitt. The NCVHS recommended that consumers should have a limited right to control their personal health information electronically:

    Giving individuals unlimited control is one way to empower them. On the other hand, if individuals had unfettered control, health care providers would likely place less confidence in the accuracy and completeness of their records….For these reasons, if individuals are given the right to control access to their records, the right should be limited.[203]

    NCVHS was not prescriptive about the best method to institute limited individual control over health records. NCVHS continues to work on furthering these recommendations. In June 2007, the NCVHS Subcommittee on Privacy and Confidentiality Working Group discussed privacy issues and other issues related to consumer control over PHRs in a working session held in Washington, D.C.[204]

    Specifically, the group addressed privacy of health information within the context of the CCR and CCD. [205] The Committee discussed the merits of masking certain types of data in the CCR or CCD, and the implications of transferring masked data from one provider to another. For example, should certain types of drugs (e.g., mental health drugs) or genetic information (e.g., family history of Huntington’s disease) be masked to protect the account holder’s privacy? One member of the Committee was particularly concerned about the social and ethic ramifications of blinding/masking mental health or genetic information: ‘By treating mental illness separately [and] by treating genetic disorders separately, we may be further contributing to the stigmatization of these conditions and putting into the future the time when there will be no difference between mental illness and other illnesses and so forth.’[206]

    The Subcommittee did not come to a consensus on a privacy standard for PHRs. Specifically, the Committee concluded that it would be optimal to wait for Congress’s definition of ‘genetic information’ under the Genetic Information Nondiscrimination Act (GINA). A Congressionally mandated definition of genetic information could dictate whether and what type of genetic information can/should be masked in a CCR or CCD. Despite these challenges, deciding upon the principles and components of a privacy policy for PHR service providers is a critical and necessary step to ensuring consumers and PHR service providers under their rights and responsibilities.

    Recommendations for PHR Privacy Standards

    The NCVHS made several recommendations for the development of PHR privacy standards. [207] First, standards should be developed to ensure that consumers are always notified of secondary uses of data in PHRs. NCVHS specifically recommended that if HHS or another agency intends to use CMS data in PHRs, then there should be a requirement which ensure that those PHR systems provide notice to consumers of the uses of personally identifiable information. Second, privacy standards for PHRs should be developed within the context of the National Health Information Network (NHIN). Third, consumers should be educated about their rights with respect to privacy and personal health information stored in PHRs. Fourth, if individuals are granted control over the specific content within their health records, that control should be limited by specific factors such as the individuals’ age, treatment/condition, and/or type of provider.[208] Finally, the NCVHS recommended that third party vendors, or other entities not covered by HIPAA, adopt their own privacy policies that are at least equal to those outlined in HIPAA.[209]

    Additional recommendations for a PHR privacy policy were developed by Altarum, a non-profit research institute, in early 2007. Altarum was contracted by the Office of the National Coordinator for Health Information Technology (ONC), in support of the American Health Information Community (AHIC) Consumer Empowerment (CE) Workgroup, to review existing privacy policies for PHRS and make recommendations.[210] Recommendations for characteristics of a PHR privacy policy included:

    • Policy must be required for all PHR vendors;
    • Policy must be transparent on secondary data uses;
    • PHR vendor must disclose business relationships relating to “handling, processing, data mining, or other management of PHR data” to consumers;
    • Policy must provide information about the relationship between the PHR service provider’s policies to HIPAA; and
    • Policy must be written at a 6^th grade reading level and include a glossary of technical terms used.[211]

    The World Privacy Forum released a report on privacy and PHRs in February 2008, which specifically outlines eight areas of concern: ‘privilege, subpoenas, marketing of health care data, linkage of records, security, ability to correct files, consent issues, and the role of privacy policies.’[212] These areas should be considered when developing privacy standards for PHRs. Finally, the Federal Trade Commission (FTC) is also exploring patient privacy and consumer protection issues in health information technology, which may be relevant to the development of PHR privacy standards. The FTC is holding a public workshop to examine patient privacy in health information technology in April 2008.[213]

    Examples of Privacy Statements

    While privacy standards for PHRs are still under development, organizations such as Microsoft and Elder Issues have released privacy policies and statements for the use of their PHR products and platforms. A brief discussion of their privacy policies is presented below.

    Microsoft recently released a privacy statement for the beta version of HealthVault. The privacy statement specifically applies to data collected by Microsoft through the Microsoft HealthVault beta version, but not data collected through other Microsoft products.[214] The privacy statement begins with an introduction to sharing health information via HealthVault. The second section addresses the collection of personal health information and authentication process. This section indicates that the owner of the account is, by default, the custodian of the record, and therefore has full control over the information.

    Given that HealthVault is a platform – not a PHR – Microsoft also urges users to reference the privacy statements of other programs that they use in concert with HealthVault. The third section of the privacy statement explains the utility of the HealthVault Connections Center; users can use the Connections Center to add data to health records in their HealthVault account from other health devices (e.g., heart-rate monitor, etc). The fourth section discusses how users can share health information with other parties or programs, and the process of assigning access. The fifth and sixth sections address how Microsoft will use the personal health information in HealthVault, and the process used to aggregate information and statistics. In addition, the statement explains that personal information collected using HealthVault may be “stored and processed in the United States or any other country in which Microsoft or its affiliates, subsidiaries, or agents maintain facilities, and by using the Service, [users] consent to any such transfer of information outside of the U.S.”[215] Microsoft HealthVault’s privacy statement indicates that users’ personal information may aggregated for marketing purposes, but is not associated with an individual account without the users’ opt-in consent. [216]

    Microsoft also refers users to its general privacy policy, ‘Microsoft Online Privacy Statement’, as this policy explains how credential information is used when the user signs in to Microsoft sites, including HealthVault.[217]

    The next few sections discuss account access and controls, sharing records with other programs/ services, deleting records, and archiving health information. Microsoft describes the process for sharing records with other service users. The lower levels of access are view-only access and view-and-modify access; both are time-limited. Custodial access is the highest level of access, as the custodian of the health record can read, change, and delete the record. The custodian of the account can also grant and revoke different levels of access to others.[218] Other components of the privacy statement include: Microsoft’s TRUSTe certification; enforcement of the privacy statement; use of cookies; use of web beacons; changes to the privacy statement; and contact information for more information.

    LifeLedger has a privacy policy comprised of five components: treatment of personally identifiable information; sharing of information with third parties; security technology and procedures; cookies; and the consumer’s role in protecting health information.[219] The privacy policy indicates that Elder Issues will not share personally identifiable information internally or with a third party. Access to personally identifiable information can be granted to a care-manager or proxy by the account holder. The policy describes the encryption practices used to secure sensitive data. In addition, the privacy policy encourages users of LifeLedger to protect the password information. Contact information is provided if users have additional questions or concerns about the confidentiality of their personal health information.

• Portability Standards

  • Portability standards address the consumer’s ability to move his or her entire PHR to a new location. Portability more typically refers to data transfer and not the transfer of the PHR’s functionality. This becomes particularly important for patients that have visited a number of hospitals and doctors in various systems. How is it possible to gather the patient’s information from multiple providers, and aggregate this information within a PHR? Experts believe that plan-to-plan PHR portability is a necessary move in the direction of interoperability and a National Health Information Network. [220]^,[5][221]

    In December 2007, the Health Privacy Project released best practices from the Employers’ Working Group on PHRs, an expert work group convened by CHCF and IBM which focuses on issues facing employers that offer PHRs. The work group, composed of the Center for Democracy & Technology, Dell, Hewitt Associates, IBM, Markel Foundation, Omnimedix Institute, Pfizer, Pitney Bowes, Revolution Health, Wal-Mart, and WebMD, identified a portability best practice. The portability best practice is that ‘employers should offer PHRs that are portable, to the extent feasible, allowing employees to maintain or move the PHR and/or the data it contains even after employment or coverage ends or changes.’[222]

    Standards and communication protocols are currently available to transmit information from other systems to PHRs. Common standards and protocols include Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP), Simple Object Access Protocol (SOAP), Extensible Markup Language (XML), Web Service Definition Language (WSDL), and Universal Description Discovery and Integration (UDDI).

    HITSP and Integrating the Healthcare Enterprise have worked to empower the consumer with the ability to manage their health care information, and be able to further distribute that information to providers. Efforts underway to develop portability standards for PHRs are discussed in this section.

• Plan-to-Plan PHR Transfer (X12)

  • Industry-led efforts beginning in 2006 have catalyzed a movement towards portability standards for payer-based PHRs. In 2006, America’s Health Insurance Plans (AHIP) and Blue Cross Blue Shield Association (BCBSA) announced their plan to conduct a pilot test that explores PHR portability between PHRs, and between PHRs and EHRs.[223] The goal of the pilot was to develop standards that ensure patients can move their payer-based PHRs from one plan to another as their health coverage changes. This pilot demonstrated the ability to move and transfer the data from the PHR only. When the data was transported to another health plan’s PHR, the format, display, navigation, and functionality were unique to the receiving health plan’s PHR.

    AHIP, BCBSA, and HL7 announced plans to collaborate on data portability standards for PHRs in December 2007, when the three organizations signed a Memorandum of Understanding.[224] AHIP and BCBSA developed an implementation guide with standards and other information that will foster PHR portability standards.[225] AHIP and BCBSA have entrusted HL7 and Accredited Standards Committee X12 with further development and technical maintenance of the portability standards. The X12 plan-to-plan transfer portability standard is currently being balloted by HL7 as part of the PHR-S functional model.

    The X12 standard is used to ‘communicate individual patient information requests and patient information (either solicited or unsolicited) between separate health care entities in a variety of settings to be consistent with confidentiality and use requirements.’[226] In this definition, patient information is defined as demographic, clinical, and other supporting data.

    Cross-Enterprise Document for Sharing (IHE-XDS) Integration Profile

    Integrating the Healthcare Enterprise (IHE), an initiative designed to improve electronic health care information sharing, has done a great deal of work related to portability. [227] Namely, IHE’s standards-based specifications address the movement of the content within PHRs. According to Charles Parisot, Manager of Standards and Testing for GE Healthcare, and co-chair of the IHE IT Infrastructure Planning Committee, the movement of information is handled by the Cross-Enterprise Document for Sharing (IHE-XDS) Integration Profile. The XDS also provides the functionality to extract and move information between systems, and to share that information in a certain domain, which could be managed by a PHR, a RHIO, or a PHR hosted in a hospital. This is consistent with the HITSP Interoperability Specification IS 03 which also relies on XDS for PHR interchange of CCDs with EHRs, Plans and Pharmacies.

    For example, suppose a patient were to visit a hospital/provider. The hospital/provider would produce several documents that summarize the health encounter. Through XDS, the patient would then be able to access information that the hospital/provider published. The hospital/provider would also be able to publish the information to the patient’s PHR or through the Regional Health Information Organization (RHIO). Then, the patient can search for these documents and bring them into his/her own PHR. Thus, the XDS enables the patient to retrieve information, gather it, and bring it into their own PHR.

    Cross-Enterprise Document Reliable Transfer (IHE-XDM)

    IHE also created the Cross-Enterprise Document Reliable Transfer, IHE-XDM, a standards-based specification which provides cross-enterprise document interchange using a common file and directory structure over standard media devices. This specification is highly relevant to PHRs because it permits patients and/or providers to use physical media to carry sets of medical records. Specifically, the IHE-XDM provides the interchange to transfer documents and metadata over memory devices (e.g., CD-R and USB) and email using ZIP attachments.[228] The specification promotes interoperability between EHRs and PHRs, enabling the exchange of documents between patients and providers, or between providers. According to Charles Parisot, Manager for Standards and Testing for GE Healthcare, and co-chair of the IHE IT Infrastructure Planning Committee, the real value of XDM is that it can work in conjunction with XDS.

    HITSP approved the use of XDM to extract part or all of the content source or aggregate information from a PHR, and move it to another doctor or provider location. XDM defines an interoperable media organization and file system that enables a person to carry documents from the PHR to another place that will be able to open the media, and navigate the media through various registration entries. The media may contain one or many documents of interest, and serves as a transportable mini registry and document repository.

    Charles Parisot described the process of moving information from one doctor/ provider location to another. The patient can input documents (previously received as input from a variety of locations) from his/her PHR into a piece of media,  as well as extract his/her current view as a CCD document, and copy this document to the media. Then, the patient is able to carry the media with them.  If they chose to open a new PHR somewhere else, the patient will be to load the input documents, and reconstruct the PHR with the same content as on the other server.

    Cross-Enterprise Document Reliable Interchange (IHE-XDR) Integration Profile

    The IHE Cross-Enterprise Document Reliable Interchange (XDR) Integration Profile is a standards-based specification that was also published by IHE. The IHE-XDR enables the exchange of patient-related medical documents between ‘health care entities’ (e.g., private physicians, clinics, in-patient facilities, etc) using a point-to-point network.[229]

    In contrast to the XDM, where the person carrying the media does the sharing of information and has the ability to give specific access to a party, the XDR is useful in situations where a patient wants to share information with a single designated entity. The XDR is point-to-point in the sense that when one or more documents in a source system need to be shared with the target system, the patient can use the XDR to push documents into the target system. The patient can choose to not publish specific pieces of information to the target system as well (such as medication information).

    One of the benefits of the IHE-XDR Integrastion Profile is that it enables document sharing in the absence of a document sharing infrastructure such as the IHE-XDS Integration Profile.[230] A second benefit of the IHE-XDR is that it enables document sharing between one or more health care entities via a point-to-point interchange.[231] The IHE-XDR is an important standard for PHRs because it enables interoperability between PHRs, EHRs and other health IT systems.[232]

    PDF/H Standard

    The PDF/H (PDF Healthcare) was co-developed by Adobe Systems and Intel, and also has support from a number of medical societies.[233] PDF-H is a secure data exchange container or ‘safe-deposit box’ for data inclusive to a PHR.[234] The PDF-H contains for personal health information in the form of digital images and data (e.g., X-Rays, CT-Scans, MRIs, and Sonograms, lab data, ECD, EEG, etc). The PDF-H will work in conjunction with the CCD or CCR format to make data portable across and between different types of systems.[235] The PDF technology has several benefits. First, the PDF is platform and system-neutral. Second, it enables various types of data to be stored regarding of source or destination. Third, information stored in a PDF can be easily selected and quickly printed. Finally, the technology enables bi-directional information exchange.[236]

    In 2007, AIIM – the Enterprise Content Management Association (ECM) and ASTM International developed a working group charged with developing best practices for the PDF/H that ‘facilitate the capture, exchange, preservation and protection of health care information.’ The PDF/H effort represents an effort by industry leaders to promote the adoption of PHRs and ensure that medical information is portable. The PDF-H standard has been submitted for ISO approval.

• Standards for Claims-Based PHRs

  • Donald Mon, Ph.D. indicates there is not a specific set of standards currently available for claims-based PHRs. There are, however, two overlapping standards for claims-based PHRs: X12 and IHE-XDR. Claims-based PHRs use a HIPAA X12 275 transaction standard for transmitting PHR data, and the HIPAA X12 275 uses XML to encode the data elements. Specifically, the X12 275 transaction is the outer ‘envelope’ that will contain the CDA/CCD data elements supported by health plan claims and administrative data entered by consumers into the PHR.[237] Claims-based PHRs also use the IHE-XDR; this standard enables the exchange of patient-related medical documents between health care entities using a point-to-point network.

    HL7 is striving to produce standards at the functional requirement level, which will then be applicable to all PHR models, rather than developing standards for different types of PHR models (e.g., claims-based, provider-based, stand-alone, or web-based),

    According to an expert from the HL7 work group, which developed the PHR-S, the goal is for all PHR models to be derived from the same functional model – regardless of whether the PHR is populated by claims data or via some other mechanism. From a standards perspective, it would be beneficial for all PHR systems to conform to a functional model.

• Use Cases Related to PHRs

  • The American Health Information Community (AHIC) develops use cases to provide context for standards harmonization and inform policy discussions that advance health information technology activities.[238] The 2008 use cases under development include remote monitoring, patient-provider secure messaging, personalized healthcare, consultations and transfers of care, public healthcare reporting, and immunizations and response management. AHIC has released three new detailed use cases on patient-provider secure messaging, remote monitoring and personalized healthcare in March 2008. The use cases are described in this section because of their relevance to PHRs.

    Patient-Provider Secure Messaging

    AHIC released a detailed use case on patient-provider secure messaging, which explores the ability of patients to communicate with their health care clinicians from a remote location using technology.[239] AHIC defines patient-provider secure messaging as ‘both secure messaging sent from patients to providers as well as secure messages sent from providers to patients.’[240] In the detailed use case, AHIC also notes that patient caregivers or patient advocates may be included in these communications. Secure messaging tools are built around a PHR, EHR, patient portal, or other types of communication tools.[241] Information is exchanged live and transactions include messages with structured content, unstructured content, or a mixed format. Additional materials can be attached to communications. Secure messaging is not intended for use during emergency situations.

    The detailed use case focuses on the processes for both patient-initiated communication from the patient and clinician perspectives, and for clinician-initiated communication from the clinician and patient perspectives. While presenting each of these processes in detail is outside the scope of this section, we provide a brief overview of the processes for patient-initiated communication from the patient’s perspective in order to highlight where the PHR fits into the process.

    Patient-initiated communication from the patient’s perspective includes the following processes: (1) the patient is authorized and authenticated to participate in secure messaging with his/her clinician; (2) the patient receives a user identification code and password to establish his/her identity; (3) the patient may need to be trained to use the secure messaging tool; (4) the patient can compose a message and send it to a clinician (read receipt features and other capabilities are available); (5) once the clinician responds, the patient is notified that they have a secure message waiting to be read; (6) the patient logs in to read the secure message; and (7) the patient reads the secure message and may update his/her PHR to reflect the information.[242]

    Remote Monitoring

    The remote monitoring detailed use case focuses on the communication of ambulatory remote monitoring information (e.g., physiologic measurements, diagnostic measurements, medication tracking device information, and activities of daily living measurements) to the PHR or EHR.[243] Measurements collected by the remote monitoring devices are transmitted to the PHR so that patients and/or caregivers can access the data. The information may also be sent to clinicians to help them to better manage or treat the patient’s condition. In order to ensure that the data can be transmitted to a PHR or EHR, the remote monitoring information must be available in an interoperable manner.[244]

    The detailed use case presents the processes communication of remote monitoring information to the EHR or PHR from three different perspectives: the clinician’s perspective, care coordinator’s[6] perspective, and patient’s perspective. Essentially, there are five main processes: (1) the patient or caregiver sets up the device; (2) the patient records measurements using the remote monitoring device, which communicates the data to the EHR, PHR, or other device at specific times; (3) the care coordinator reviews the measurement information via a portal provided by the device manufacturer or other third party; (4) the care coordinator will work with the patient or caregiver to check the information communicated and potentially acquire additional information; and (5) if necessary, the clinician will review the measurement information through the EHR, determine if a change in the patient’s treatment is necessary, and then transmit the needed change to the care coordinator and the patient’s PHR. Remote monitoring is an important component of care management for the aging population and people with chronic conditions.

    Personalized Healthcare

    AHIC defines personalized healthcare as the ‘processes by which health care providers can customize treatment and management plans for patients based on their unique genetic makeup.’[245] AHIC’s detailed use case on personalized healthcare focuses on the processes underlying the exchange of family history information and genetic and genomic testing information between patients and clinicians, and how this information is available in an EHR or PHR.[246] The detailed use case explores: (1) the clinical assessment from the clinician and consumer perspectives, and (2) genetic testing, reporting, and clinical management from the clinician and consumer perspectives. In terms of the clinical assessment piece, the use case describes that a consumer can share his/her medical history with a clinician by entering their personal health information into a PHR and then making that information available to the clinician. In terms of the genetic testing, reporting and clinical management component, the use case describes that consumers would receive and incorporate genetic/genomic testing information into their PHR. If the information is interoperable, then consumers can send the data to their clinician. Consumers may also wish to assign a proxy or caregiver access to the information within their PHR. [247]

• Other Gaps In The Current PHR Standards Arena

  • Next, we address several other gaps in the PHR standards arena that have not been discussed in other sections.

    Data Content Standards

    Donald Mon, Ph.D.suggests one of the major areas that the standards community will need to revisit is data content standards. While HL7, DICOM, SNOMED, and LOINC are useful for PHRs, health care organizations still record data according to their own current data set. Thus, interoperability challenges are still present. Two examples illustrate the need for greater standardization with respect to data content.

    The first example addresses gender data. Gender is currently collected in multiple ways across EHRs and PHRs (e.g., male = 1, female = 2; male = M, female = F; etc). Health care organizations may have systems to recognize various types of codes for male and female during data exchange. However, other organizations may also utilize additional codes for gender equal to hermaphrodite or unknown. During data exchange, this additional information would not be recognizable to a system that does not have hermaphrodite or unknown in the current data set.

    The second example relates to medication use habits. David Lansky, Ph.D. asserted that there are a number of medical history data elements that are not standardized across PHRs, leading to interoperability challenges. One example is medication use habits (e.g., does the patient split pills in half; what are the patient’s reasons for not taking the prescribed pills; does the patient have post-procedure complications, etc.). The industry does not currently have a method to make this information part of the patient’s PHR, though it is critical data to include in the patient’s health record.

    Until the industry has greater data standardization or potentially a standard data set, it will be impossible to achieve semantic interoperability for certain data elements. Dr. Archelle Georgiou, an independent consultant, commented on the difficulty of achieving consistency around semantics: ‘Achieving consistency around semantics – beyond the semantics for very specific or objective data points – is a much broader objective than establishing a technology based resource for holding health related information. Semantic interoperability would require cultural change that begins during the medical education process. Since this is unlikely, another approach is to recognize the inevitability of semantic variability and to create systems, support, and processes that work around them.’

    Areas of Overlap in Standards Development

    A number of standards organizations and work groups have been tasked to address similar issues related to PHR privacy, security, interoperability, and portability. While coordination between initiatives is ideal, initiatives sometimes move along different paths – with different missions, charges and time frames. Thus, areas of overlap do exist in the current standards development arena.

    AHIMA is exploring the issues of overlap in standards development initiatives through a new project focused on the development of Regional Health Information Organization (RHIO) best practices for the Office of the National Coordinator for Health Information Technology (ONCHIT). As part of this project, AHIMA will look at how health information is exchanged in a health information exchange (HIE) environment, whereby the PHR could be one node in any HIE. Donald Mon, Ph.D. indicated that the ONCHIT project will require the standards community to think critically about the gaps and inconsistencies with respect to PHR standards and standards initiatives. Currently, a number of different initiatives have addressed PHR standards – including but not limited to the HISPC project, HITSP, IHE, and CCHIT. The project will explore whether the different initiatives, and their areas of overlap, are affecting the HIE (when the PHR is one of the nodes that information can be exchange to and from). Several areas of overlap to date are discussed below.

    Consents. One specific example where there is overlap among standards development efforts is for consents. David Lansky, Ph.D. suggests that currently consents are done in different ways. One method is to use a consent directive, which essentially enables the provider to acquire all of the account holder’s consents up front. The benefit is that when a health care episode occurs, the provider does not need to acquire consent again. This process reduces burden on clinicians and improves the clinician’s workflow. However, from a policy and privacy perspective, there are problems with using a consent directive. Consumer advocates have asserted that consumers will be better protected by a policy that requires providers to ask for consent during each health care episode. Consent directives are one key area where the EHR-PHR standards community lacks a consistent policy. HISPC, HITSP, and other groups have addressed consent directives in a variety of ways, creating overlap in the standards development space.

    Conditions and Diagnoses. According to HITSP, there is also an overlap of standards for conditions and diagnoses – namely SNOMED-CT and ICD-9/10. In 2007, HITSP recommended that both types of codes could be requested, and thus, whatever form the information is available in would be provided.[248]

    Portability. In 2007, HITSP also explored PHR portability standards and determined that that IHE-XDM and X12 are areas of overlap.[249]

• Summary: Standards For PHRs

  • Standards govern the way health information is exchanged between PHRs and other health information systems. A number of entities are involved in developing standards for PHRs. Most recently, HL7 developed the PHR-S functional model (PHR-S). This represents the first effort to define personal health functions, supportive functions, and information infrastructure functions for PHRs. In addition to this effort, other standards development organizations have created standards for EHRs that are also applicable to PHRs. The relevant standards for semantic interoperability are terminologies such as SNOMED, developed by the College of American Pathologists, and LOINC, maintained by the Regenstrief Institute. The HL7 Clinical Document Architecture is another important data exchange and message standard for clinical and administrative data.

    A number of security standards for authentication, consent, confidentiality, accountability, and non-repudiation are available for PHRs. However, one outstanding security issue is how much access, use and control a consumer should have over their PHR. Various PHRs and PHR platforms treat the issues of access, use and control differently. Closely connected to security, privacy is a key concern for consumers of PHRs. Currently, there is no uniform standard for privacy of personal health information stored in a PHR. The NCVHS has released recommendations for the characteristics of a PHR privacy. Several organizations have also released privacy statements for their PHR products and platforms. However, there is no consensus among PHR service providers about the specific elements that should be in all PHR privacy policies.

    Portability of information between health care entities and between PHRs and EHRs is another important issue that the standards community has addressed. Integrating the Healthcare Enterprise has developed the IHE-XDS, IHE-XDR and IHE-XDM standards-based specifications for cross-enterprise document interchange. In addition, America’s Health Insurance Plans and Blue Cross Blue Shield Association have explored portability between PHRs, and between PHRs and EHRs. Their work resulted in the X12 plan-to-plan transfer portability standard, which is under further development by HL7 and Accredited Standards Committee X12.

    Finally, AHIC has developed detailed use cases in the areas of patient-provider secure messaging, remote monitoring, and personalized healthcare; each of these use cases has implications for PHR users.

    While a number of standards are available or under development for PHRs, the standards community, health researchers, and policy makers will need to address four key gaps with respect to standards. First, no standards exist for patient-initiated changes to information within the PHRs. Standards must be developed to ensure that changes requested by consumers are made in a uniform fashion to protect the accuracy of the clinical record. Second, future work should address privacy and security issues related to PHRs. Researchers should explore the possibility of developing a uniform privacy standard that applies to all PHR service providers, regardless of whether or not they are covered by HIPAA. Research should also explore the implications of assigning access, use, and control over a PHR to a care-manager or proxy, as this issue will be particularly relevant to Medicare beneficiaries. Third, future work should focus on further standardizing data content in PHRs to ensure semantic interoperability. Fourth, the PHR community must come to a consensus on the rights and legal responsibilities of all parties involved with PHRs. A clear definition of the rights and responsibilities of consumers, health care providers, PHR suppliers/ vendors, and other entities involved with PHRs will help to foster interoperability and also facilitate the protection of personal health information.

View full report

Download

"litreview.pdf" (pdf, 998.47Kb)

Note: Documents in PDF format require the Adobe Acrobat Reader®. If you experience problems with PDF documents, please download the latest version of the Reader®