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). The PHR-S may be the first effort to define the basic functions for PHRs. 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. 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. 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.
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. One of the goals of interoperability is to ensure that providers can access data from PHRs as seamlessly as possible. 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. Both types of interoperability are achieved through standards for data exchange and messaging, terminology, documents, concepts, applications, and architecture. 
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. 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.
|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). 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.|
|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. 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.