FTC’s rule requires vendors of personal health records and related entities to notify consumers when the security of their individually identifiable health information has been breached. Both the FTC and the HHS rules were required by provisions in the American Recovery and Reinvestment Act, signed into law this past February.

As with the HHS rule, entities must notify affected individuals without unreasonable delay and no later than 60 calendar days after discovery of the breach. Neither HHS nor FTC amended the timeline specified in the ARRA provision.

The rule specifies that notifications should be written in plain language and include, to the extent possible, a brief description of what happened, the types of information involved, steps individuals should take to protect themselves, and a brief description of what the entity is doing to investigate and mitigate the breach. The notification must provide consumers with contact information that includes a tollfree number, e-mail address, and Web site or postal address.

Entities must notify the FTC, also. They must report breaches involving more than 500 people within 10 business days of discovery. This doubled the amount of time in the proposed rule. Commenters expressed concern that 5 days may not be enough time to properly investigate the incident prior to reporting it. That change may get attention in California, where state law requires healthcare entities to notify both consumers and the state of breaches within 5 days.

The final page of the Federal Register notice includes a form that PHR vendors may use to file breach reports.

The FTC rule does not apply to HIPAA-covered entities or to “any other entity to the extent that it engages in activities as a business associate of a HIPAA-covered entity.” However, there could be instances where a company serves as both a business associates of a HIPAA-covered entity and a vendor of PHRs to the public. That entity could be subject to both the HHS and FTC. The final rule provides several examples.

The Definitions

The rule defines a PHR as an “electronic record of PHR identifiable health information on an individual that can be drawn from multiple sources and that is managed, shared, and controlled by or primarily for the individual.” The rule offers further definition of what information constitutes PHR identifiable health information.

Paper PHRs are not covered by the rule, because ARRA legislation specified a rule on electronic records only.

FTC defines a ‘‘PHR related entity’’ as an entity that “(1) offers products or services through the Web site of a vendor of personal health records; (2) offers products or services through the Web sites of HIPAA-covered entities that offer individuals PHRs; or (3) accesses information in a personal health record or sends information to a personal health record.”

The final rule adopts the definition of breach provided in the proposed rule: “the acquisition of unsecured PHR identifiable health information of an individual in a personal health record without the authorization of the individual.”

Preemption

Preemption of state law does apply, with FTC clarifying that the final rule preempts only contrary state laws.

A state law is contrary if it would be impossible to comply with both state and federal requirements or if the state law “stands as an obstacle to the accomplishment and execution of the full purposes and objectives’’ of the federal requirements.

The rule does not preempt state laws imposing additional—as opposed to contradictory—breach notification requirements.

The site offers consumer information on choosing a PHR, starting a PHR, and protecting your privacy. Community groups can also schedule local PHR presentations through AHIMA’s community education program.

HIM professionals can play four important roles, the authors write:

• Advocating, designing, and testing PHR products that are sensitive to underserved populations
• Promoting PHR use within their communities
• Training both consumers and providers in PHR use
• Helping secure personal health information to both safeguard individuals and build the trust that will encourage consumer acceptance of health IT

See “Healthcare Disparities and the Role of Personal Health Records” by Jennifer Garvin, Barbara Odom-Wesley, William J. Rudman, and Rachelle S. Stewart.

For a look at the need to improve data collection in support of efforts to reduce disparities, see the April 2009 Journal feature “Data Collection and Reporting for Healthcare Disparities.”

The American Recovery and Reinvestment Act establishes the first federal requirements on health data breach reporting and notification. It assigns the Department of Health and Human Services to oversee organizations that qualify as covered entities and business associates under HIPAA. It assigns the FTC to oversee everyone else, including vendors of personal health records.

Both HHS and FTC are required to publish final interim regulations by August 16. The provisions become effective 30 days after publication.

According to an FTC press release, the proposed rule:

• Requires “vendors of personal health records and related entities” to notify consumers of a breach
• Requires a service provider to a PHR vendor to notify the vendor of a breach, which in turn must notify its customers
• Defines the triggers for a notice, as well as the timing, method, and content of the notice
• Requires that entities notify the FTC of a breach, which will in turn post the information on its Web site and share with HHS

The NPRM will appear in the Federal Register shortly, according to FTC.

Public comments on the notice of proposed rulemaking are due by June 1. AHIMA’s commentary will available on this site in advance of that date.

Update April 20: HHS released its required guidance on rendering protected health information unreadable on April 17. The guidance relates to both HHS’s and the FTC’s breach notification regulations. HHS is accepting comments until May 21.

Health record banks centrally store copies of consumer’s health records, which providers “deposit” into the accounts. Consumers control which providers can contribute information and which providers and individuals can view their records.

This model of health information exchange, where many providers send patient information to one central location, is seen as an alternative to the many-to-many exchange model, where several organizations directly exchange copies of patient’s records. If the pilot project is successful, Washington State hopes to show by example that health record banks are the ideal model for nationwide information exchange, says Juan Alaniz, health record bank pilot project manager for HCA.

Advocates for the health record banks agree that the pilot is an important demonstration of the model. William Yasnoff, MD, PhD, is managing partner of National Health Information Infrastructure Advisors and CEO of the Health Record Banking Alliance. “As the first operational health record bank, the Washington State pilots represent an important step in demonstrating how this approach addresses the key challenges of making comprehensive electronic medical records available at any point of care,” he says.

A main goal of the pilot is to show that health information can get into the hands of patients and providers, Alaniz says, which will reduce redundant medical procedures and costs and improve the quality and safety of care provided. “By having this information available, I think that we are arming consumers with valuable information they can use in a timely basis,” he says.

Three Pilot Sites

The Washington State pilot is the first large-scale testing of the health record bank model. The test contains three projects across the state, which will target 18,000 participants who have specialized healthcare needs such as chronic-illness patients, families with children, and caregivers.

The banks are managed by local community healthcare facilities, which identified and recruited patients to take part in the pilot, Alaniz says. The state contributed $1.7 million to the pilot, with participant healthcare communities also pitching in funds.

The three pilot sites are in the following locales:

• Bellingham, with St. Joseph Hospital Foundation and the Critical Junctures Institute
• Cashmere, with Community Choice Healthcare Network
• Spokane, with Inland Northwest Health Services.

“High Value” Data

Participating providers will begin by loading five types of “high value” data into consumers’ health record banks: medication history, immunization records, allergy information, family history, and a health status synopsis. 

The pilot will end in July, when a preliminary results analysis will be conducted, Alaniz says. The project will test the financial sustainability of the banks, their ability to provide public health data, and how the banks should be organized and governed.

But most importantly, the pilot is meant to see if consumers and providers find health record banks valuable and would sign up for a fully-integrated, statewide health record banking system. “If it is of no value to consumers or providers, then we certainly don’t want to do this,” Alaniz says.

At the end of the pilot, the health record banks will continue to operate if funding can be secured. The goal is to have the banks financially self-sustainable by 2011. 

Private Infrastructure

The pilot banks run PHR programs from Microsoft Health Vault and Google Health. Each site chose between the two programs, which Alaniz describes as PHRs “on steroids.” When data are uploaded into the bank, the information is automatically organized in specialized ways useful to patients and providers.

Having private companies provide the infrastructure saved HCA the cost of developing its own software. In addition, the banks benefit from the companies’ work to make the interfaces consumer friendly, says Alaniz. If the health record bank project was to advance, Alaniz says banks would have their choice between using existing products and developing platforms from scratch.

Prior to the pilot, it was unclear who would build or provide the technical infrastructure for health record banks. The choice of Google and Microsoft isn’t surprising, says Yasnoff—the majority of health information infrastructures are built and operated from systems developed by private firms. Each of the health record bank pilots is governed by the local community, which he says will provide a watchful eye on how the records are managed.

Public Results

Washington State officials plan to share the information they obtain from the pilots with interested parties. HCA has already talked with Oregon and New York state officials about sharing pilot data. Other communities including Louisville, KY, Ocala, FL, and Kansas City, MO, are also interested in pursuing health record banks, Yasnoff says.

The pilots are only the “test and learn” phase of building a state-wide health record bank system, which officials hope to launch in 2012, Alaniz says. If the results of the pilot support moving forward, the project will begin implementing lessons learned and develop the basic bank infrastructure.

Users may now share their health profiles with others, such as doctors and family. Account owners grant access to others via e-mail addresses. Viewers cannot edit or share a profile. Account owners control how much of the profile others see, another change.

Google’s list of partners continues to grow. Partners are primarily national pharmacy chains that can feed medication information into Google Health accounts. However, patients of the Cleveland Clinic and Beth Israel Deaconess Medical Center can import their records through those facilities’ patient portals.

Now, more than 10 years since its creation, PCASSO can be more fully appreciated as an innovator in technology that many hospitals have only recently begun to adopt.

As complex health data exchanges such as health record banks, health information exchanges, and personal health records begin to gain ground, PCASSO deserves a retrospective look as an early project that promoted patient access to health records and demonstrated it could be done security over the Internet, says Dixie Baker, PhD, former principle investigator with the PCASSO project and senior vice president and chief technology officer for health solutions at Science Applications International Corporation. The project anticipated many of today’s security threats and incorporated a high level of protection that many contemporary portals do not.

“Military-grade Security”

PCASSO used “military-grade security” in protecting access to health records, Baker says. The system protected against threats that most people did not think possible, let alone common. “Some of the things we did, people couldn’t understand why we did it,” Baker says, “[but] today the threats that we were protecting against are very, very commonplace.”

For example, PCASSO protected against malicious software that hackers might use to capture user names and passwords. At the time many people did not expect such programs could be developed, but such spyware and other snooping devices are common today. (Yesterday, in fact, Microsoft rushed out a patch for its Internet Explorer Web browser that addresses such as vulnerability.) “Everything that we protected against is now widely recognized as a threat,” Baker says.

In recent years, major healthcare networks such as Kaiser Permanente and Cleveland Clinic have implemented patient and provider health record Web portals. But Baker says the precautions taken with PCASSO are still not fully implemented in some portals. “From a security perspective, we went well beyond securities implemented in any Internet-based [electronic medical record] system today,” she says.

Beginnings

PCASSO was developed through a partnership between the Science Applications International Corporation and the University of California, San Diego (UCSD). The National Library of Medicine provided funding as a way to test the feasibility of using security technology to enable safe assess to personally identifiable electronic health data over the Internet. If the project succeeded, it would open up vast possibilities for online information access and data exchange.

UCSD healthcare facilities served as the testing grounds for PCASSO, where 178,000 patient records were made accessible. The project had nearly 300 active users, including both patients and providers, who could search and view electronic health records for patient demographics, medications, lab tests, and transcription reports. Data were displayed through a Web interface.

As configured for the UCSD trial, PCASSO recognized five levels of information sensitivity; the level of access was tied to user role. The system allowed organizations to define roles and the rules associated with them.

Logging in to the system was a multistep process that required a diskette to establish an encrypted link between the server and the client computer. Once that link was established, the server “challenged” the user to enter a number from a list previously issued to the user. Each number could be used only once.

The project ran from 1996 to late 1999, when it came to the end of its test period and was closed down.

Some Annoyances

High security was both an asset and annoyance in PCASSO. The portal’s strong protections came at the cost of convenience to users. During patient and provider reviews, PCASSO received some negative feedback that the security measures made the program cumbersome. Baker believes this is the reason most portals today do not use the high level of security protections PCASSO possessed.

However, the strict security measures did their job. Numerous attempts were made to break into the portal, Baker says—both by her team as well as unauthorized outside entities—and it never cracked.

A Legacy of Patient Empowerment

The high level of security may have frustrated some users, but it allowed PCASSO to offer patient information that many portals still do not.

“One thing that distinguishes it from anything that is out there today is we allowed [patients and providers] access to the entire record, including information that has special protections like HIV/AIDS information, psychological health information, [and] sexually transmitted diseases,” Baker says. “These kinds of diseases and conditions have special protections and in general are not usually viewable through the portals that are out there today.”

Putting information into patients’ hands is an important part of PCASSO’s legacy. The research project is remembered for more than demonstrating the ability to tame the Web for exchange of health information. It is also viewed as groundbreaking in patient empowerment.

“Prior to the PCASSO project, patients were never enabled access to their own medical records,” Baker says. The prevailing attitude was that patients didn’t need to see their records. “The whole movement towards patient empowerment, which is gaining momentum every day right now, really got its start here,” she says.

As time goes on and hackers become better at cracking systems, Baker feels more and more of PCASSOs security precautions will prove necessary in today’s portals.

“I think the state of the art in security will migrate more and more toward PCASSO, because the threat environment is getting greater and greater on a day-to-day basis,” she says.

Baker wrote about PCASSO for the Journal in 2000. You can read the article here.

The Center for Information Technology Leadership (CITL), a nonprofit IT research center based at Partners HealthCare System in Boston, offers the projections in the study “The Value of Personal Health Records.” The study describes an evidence-based model that estimates the industry costs and benefits of four different PHR architectures. The study is the first of its kind to examine the different PHR architectures and show their direct cost savings to healthcare providers and payers, CITL officials say.

PHRs provide patients with greater access to their health information and, depending on the individual product, give them an opportunity to add their own information. Many PHRs put patients in control of who can access their records, allowing them to share their information with providers, payers, and caregivers.

A PHR is different from a provider or payer’s record, which the organization controls for business and legal purposes. PHRs have the potential to improve care by sharing patient information among authorized providers. They can also increase a consumer’s awareness of his or her health and help in making informed health decisions.

Savings Vary by Type

Blackford Middleton, MD, MPH, MSs, is chairman of CITL and director of clinical informatics research and development for Partners Healthcare. He says that CITL believes electronic health record systems—implemented and maintained by providers—are a part of improving care and lowering cost; however, “we believe that the PHR is perhaps an equally important or maybe even more important part of the solution as well.”

Published November 12 and presented at the American Medical Informatics Association annual symposium, the CITL cost-benefit model assumes 80 percent of the US population actively uses one of four emerging PHR architectures: payer-tethered PHRs, provider-tethered PHRs, third-party PHRs, and interoperable PHRs. A panel of healthcare experts organized by CITL synthesized hundreds of articles on healthcare and PHRs to build the model.

Provider-tethered PHRs are tied to a healthcare organization’s internal record system. Payer-tethered systems are tied to a given payer’s system. Consumers use third-party PHRs to aggregate data from different, unconnected sources.

Interoperable PHRs represent a “future type” of record “populated with data from all regional data sources via standards-based automated data exchange. The connections with these sources would create a record that is more complete than any individual repository (e.g., [electronic health records], other PHRs, payer claims databases),” according to the report.

While the implementation and steady use of each of the four PHR architectures would result in vast cost savings, some architectures produce greater savings than others, according to the study.

The model projects that mass use of the interoperable PHR architecture could lead to the highest savings by streamlining healthcare operations and decreasing administrative and clinical costs, such as preventing duplicate medical tests and reducing adverse drug interactions.

The projected annual savings by model are:

• Interoperable PHRs: $21 billion
• Third-party PHR: $16 billion
• Provider-tethered PHR: up to $14 billion 
• Payer-tethered PHR: $13 billion

Highlighting the Value of Data Sharing

The  model assumes that PHRs in each category have certain functionality, including the ability to share test results and medication information. Other, more specialized functions include electronic appointment scheduling and e-visits. Middleton hopes the study will help policy makers and the general healthcare industry understand which PHR models can best improve healthcare and reduce costs.

“The PHR architecture and what data is accessible—and to what degree data is interoperable—that really defines the value of a PHR,” Middleton says. “Our intent is to model a what-if scenario; [for example,] what if everyone had a provider-tethered PHR or an interoperable PHR. And the goal is then to highlight the differences so that we can inform policy makers and the industry about what is valuable.”

Though interoperable PHRs presents the highest potential savings in cost, they are still a work in progress. But CITL’s cost-benefit model indicates that PHR development should lean toward an interoperable architecture, Middleton says. Interoperable PHRs act as a hub for patient information, connecting multiple payers and providers to each other through a patient-controlled record.

While PHR use does offer savings, establishing the products and the networks takes money. The cost-benefit model also adjusts to reflect the savings after deducting the cost of implementing each PHR architecture. Providing interoperable PHRs for 80 percent of the US population could cost an estimated $3.7 billion to acquire and $1.9 billion annually to maintain, the study estimates. After cost, and based on a 10-year roll-out of infrastructure, the interoperable PHR could still save $19 billion annually in healthcare costs.

CITL hopes several things come as the result of this model, Middleton says. Third-party PHR companies like Google Health and Microsoft HealthVault can use the study to recognize the value of standards that will make their products more interoperable. Providers and payers can recognize the value of PHRs and pledge their support for PHR adoption. Finally, policymakers can recognize the value of PHRs and address issues that will allow nationwide health IT adoption, Middleton says.

RWJF launched the $5-million national program to explore the “purpose and potential of electronic PHRs” and “move the perception of PHRs from static repositories of health information to dynamic, tailored applications that allow people to easily and actively manage their health as they go about their daily lives,” according to the Project HealthDesign web site.

Over the next several months, the design teams will publish details about their work, as well as extend the use of their applications to the clinical practices connected to their institutions.

User-centered design plays a large role in developing patient-centric products like the Project HealthDesign prototypes. “The ability of PHRs to truly meet the needs of individuals depends in part on how well product designers attend to the needs and wants of the users and how extensively they engage users in PHR design and testing,” wrote Margarita Morales Rodriguez and coauthors in an April 2007 journal article “Patient-centered Design.”

Google’s PHR allows users to upload and store their medical records as well as research health conditions and receive personalized medical alerts. Users can enter in their own data as well as have records automatically uploaded from Google Health partners like provider Beth Israel Deaconess Medical Center in Boston, pharmacy chains such as Walgreens, and labs including Quest Diagnostics. Records can also be downloaded from providers such as physicians and hospitals.

Like any Google offerings Google Health will be modified over time based on user feedback and technological developments. “This is version one, and it is our philosophy at Google that products launch early and iterate often,” says Jerry Lin, Google Health product manager, who helped build the product.

Connections Growing

The Google Health user interface was fine-tuned this spring in a pilot test with nearly 1,500 patients at Cleveland Clinic in Ohio. Several elements of the product were changed during the pilot, including the way records are sorted and how they can be edited, Lin says. Patients were impressed by the portability of their records, Krasner says, and pleased with the ability to integrate information from other medical treatment sources. 

One major area of development lies in adding more Google Health partners. The record service launched with several major healthcare stakeholders including CVS and the Cleveland Clinic, but its goal is to perpetually increase the number of providers and services that can upload and download data to the service. These prospective partners include payers, medical groups, and even EHR vendors, Krasner says.

Those collaborations rest on both sides using recognized health IT standards for exchanging data. Google Health currently uses a modified version of the Continuity of Care Record for its information exchange. This was the most prevalent standard at the time Google Health was developed, Lin says.

But with the growing emergence of the Continuity of Care Document standard, Lin says Google Health has begun working to integrate the CCD into its product for future use. “It is very important for Google Health to stay with the standards and promote and use these standards so that we will really reduce the adoption barrier,” Lin says. 

No Paper Allowed

All data submitted to Google Health must be done electronically. This will present a problem when the company tries to partner with smaller physicians’ offices who use only paper records. The partnership is a future goal, Krasner says, and a solution is still being developed. Getting paper records into a user’s account can currently be done, but at a price.

Along with the site’s launch, Google published its API so third-party developers could build applications for the site. Three of the 14 third-party applications available at launch offer to convert a user’s paper medical records into structured Google Health profile data, starting at $30. Some current services will collect a user’s records from providers, but at a higher cost.

To Come: Social Networking, Consent Detail

Future versions of Google Health will add unique features created by in-house and third-party collaborators, Lin says. For example, Google Health is working on allowing consented user-to-user data sharing, which would foster social collaboration on disease management. The company also is working to make the consent authorizations more granular, so users can select exactly what information to share and with whom. Currently, users can only consent to share all or none of their information with an entity.

Google is also modifying the system to accept images such as x-rays, CAT scans, and possibly scanned images of paper medical records. “These are very critical pieces of your medical record, and at Google Health we want to be able to provide that infrastructure in order to facilitate the exchange of that information,” Lin says.