IT Standards for PHRs: Are PHRs Ready for Standards? Are Standards Ready for PHRs?

by Kevin Heubusch

The personal health record market looks like a blur, but organizing around common technical standards will help PHRs gain traction with providers, payers, and consumers.

In late April the National Alliance for Health Information Technology released a consensus definition for a personal health record. The work, undertaken as part of a federal contract, is an attempt to put a stake in the fast-shifting ground of product development, giving the healthcare industry a common understanding of what is meant by “PHR.”

Like any standard, the definition’s success will depend on its acceptance; however, it is unlikely to channel product development into a single model of a personal record. Nor is that its intention. There are too many players, too many ideas, too many consumer needs, and too much unexplored ground for that.

Technical standards share something of the same goal. They don’t intend to define a single product but to establish common ground; in this case, technical specifications that promote desired characteristics, such as strong security controls or the ability for different IT systems to communicate with each other.

Whatever format they take, PHRs need standards to proliferate. Providers in particular can’t afford to adapt to every new product that comes along. Even the largest enterprises have finite IT budgets. But how to set down standards in such a volatile market?

A number of established and emerging IT standards already apply to PHRs as they are currently envisioned. These can help advance PHR adoption through their ability to facilitate the gathering and exchange of health information or ensure security. But one defining feature of the current PHR market is the speed at which it is evolving. The standards that PHRs may require in just several years are anyone’s guess.

Applying Standards from Other Systems

One organization that has taken a close look at the PHR environment and the standards that apply to it is the National Opinion Research Center. The center manages the National Resource Center for Health Information Technology on behalf of the Agency for Healthcare Research and Quality. It also conducts interrelated work with AHRQ groups and through AHRQ with other federal agencies.

NORC immersed itself in PHRs on behalf of the Centers for Medicare and Medicaid Services, which sought evaluation of its pilot program on the potential benefit of PHRs for Medicare beneficiaries. Part of that evaluation included an environmental scan to capture the state of the PHR.

“PHRs are in their infancy, so a lot of the learning is establishing what we don’t know—we as a nation—which is an awful lot,” says Dan Gaylin, executive vice president for health research at NORC. The scan included a look at what current standards could apply to PHRs and what standards might be needed.

These included standards around interoperability, messaging, semantics, security, and portability—“everything that is currently being done that remotely intersects with what PHRs might do,” explains Prashila Dullabh, a NORC health IT program manager who led the evaluation. The team grouped standards into broad categories of interoperability, portability, and privacy and security.

Gaylin notes that to date PHRs have largely been constructed as a kind of a minimum data set based on what clinical information the industry thinks would be helpful to the patient. For that reason, PHRs as currently envisioned borrow from a range of current standards designed for other health IT. “There will be little bits and pieces of various, broader, extant standards systems in the medical world that will then apply to the PHR,” Gaylin says.

Many of these apply to interoperability. That space has been well explored, because it leverages work that has already been done for EHRs, notes Dullabh—messaging standards from Health Level Seven, for example, and LOINC codes for identifying lab data.

Bringing such standards to bear on PHRs will help govern how consumers enter information into their PHRs so that it may be read by a provider’s system—the type of semantic interoperability that ensures that data can be understood and interpreted with the same meaning in the receiving system.

Such an exchange benefits patients and providers by creating records that can share data between multiple provider systems. It also encourages provider acceptance by creating personal records that integrate with other standards-based IT the provider may use.

Based on NORC’s research, in fact, there wouldn’t appear to be any standards that are unique to PHRs. Not currently, at least. Future functionality, devices, and uses may require unique standards.

Devices or systems that are not tied to an EHR or a claims system are one example. The potential interaction of PHRs with health information exchange networks is another.

One of the biggest messages resulting from the NORC scan is that the present won’t be here long. “It’s our sense that this PHR environment is going to be radically different in a couple of years,” says Dullabh. “Some of it will build on the work that is being done now, and I think some of it is going to be brand new to the industry.”

The Continuity of Care Document

One standard with the potential to exert a strong organizing influence on PHRs is the Continuity of Care Document, or CCD, which gained clout earlier this year through recognition by the Department of Health and Human Services.

The CCD is a standard format for the exchange of basic patient information such as demographics, medications, and allergies. Federal recognition means that government agencies may only purchase health IT systems that comply with the CCD standard.

The standard was developed by ASTM International and HL7 and recommended to HHS by the Healthcare Information Technology Standards Panel (HITSP), the public-private body created through HHS to identify and harmonize the data and technical standards necessary to advance health IT adoption.

HITSP’s work is focused by priorities set by the American Health Information Community, presented as use cases. HITSP identifies the gaps, overlaps, and redundancies in applicable standards and comes up with “one unambiguous cookbook that describes how data will be exchanged for each use case,” explains John Halamka, MD, HITSP chair and CIO of Harvard Medical School and Beth Israel Deaconess Medical Center.

One of those use cases centers on consumer empowerment through the use of a PHR to exchange medications, problems, allergies, labs, and demographics in one standard national format. HITSP settled on the CCD as that format.

“Some use cases are transactional—a lab sends a result to an EHR,” explains Halamka. “That uses an HL7 251 standard. Some, like e-prescribing standards, are mandated by Medicare part D, and those use NCPDP standards. Those are about routing messages to systems.” In contrast, the CCD determines content, enabling a longitudinal record of a person’s health history that could span a lifetime.

The CCD offers vendors and providers a single standard for transmitting a core set of patient information. That’s key, says Halamka, because right now the lack of a standard is creating one-off interfaces for each PHR product. That requires providers to write a unique application each time they connect to a new PHR product. The process, says Halamka, is expensive and time-consuming, and it limits the number of products that providers can choose to support.

Consumers will benefit from a standardized interface, also. It will enable them to select PHRs based on the features that are most important to them. They won’t be forced to choose based on whether their providers support a given product.

Halamka expects that HITSP will expand the CCD standard to cover additional use cases over the course of the year. In 2008 the panel is working on a “bench to bedside to sofa” charge—all the standards necessary to take medicine into the home so that home glucometers, scales, and blood pressure devices can communicate remotely with providers—“truly reaching out and getting numbers from devices [and] getting messages back from the doctor to the patient,” Halamka says.

HITSP’s 2008 work also includes standards harmonization around family history and genomics information. “You might imagine the CCD being expanded to have codified family history and even your genome as part of the information exchanged with personal health records,” Halamka says. More could follow in 2009, such as using the CCD to assess individuals for, and subsequently enroll them in, clinical trials.

Plan-to-Plan Portability

Current work around the plan-to-plan transfer of PHR data also figures to have an impact on product development. Such portability standards facilitate the transfer of PHR data from one health plan to another when a consumer’s health coverage changes.

Portability is distinct from interoperability, which enables the meaningful exchange of data between different systems—from a PHR program or a biometric device to an EHR, for example. To enable portability, a system will have some limited interoperability.

America’s Health Insurance Plans and the Blue Cross Blue Shield Association have developed standards, a data dictionary, and operating rules around PHR data portability. In December 2007 the two organizations announced an agreement with HL7 to create a collaborative process for managing them.

The portability model leverages several existing standards, bundling them into a framework that supports transfer of claims, pharmacy, clinical, and patient-entered data. Testing began with claims and medication history, based on ASC X12 and NCPDP standards, well established in the payer community for processing claims-based attachments and pharmacy information. The CCD now supplies a standard for transmitting clinical and patient-entered data.

Under the agreement, HL7 and ASC X12 will assume maintenance of the technical standards for further development, balloting, and long-term maintenance. The first balloting and review took place this spring, with a second round of balloting expected this summer.

The model deserves a close look by hospitals. Given the breadth of standards, it may offer a useful framework for greater interoperability between providers and consumers.

Privacy and Security

There may not be standards unique to PHRs, but some of the privacy issues they raise don’t apply to other electronic records. Dullabh cites aspects of consent and proxy as examples.

There are no technical standards for privacy—privacy is determined through policies and regulations. However, there are standards for security, and those affect the privacy policies that can be enabled. Privacy policy will be local, Halamka believes, but national security standards should allow enforcement of whatever policy is decided locally.

Security standards thus have some influence on the development of privacy policy. HITSP security standards, for example, specify functionality for audit trails and role-based access controls. IT systems adhering to the standards provide a framework for potential privacy policies. In that sense, Halamka notes, security standards empower policy making.

Good Reasons to Conform

The speed at which the PHR market is evolving may suggest that product developers don’t have time to stop and standardize. However, both vendors and providers have good reason to organize around current and emerging standards.

In the case of HITSP, its approved standards are pushed out into the market in two significant ways. Through recognition by HHS, the standards become mandated for federal procurement. They also make their way into the product certification criteria established by the Certification Commission for Healthcare Information Technology.

Meeting those standards can help vendors generate sales. It can also save them money, because it gives them the opportunity to create one good interface that they could use in all markets.

Providers save money, too. Regardless of facility type, they would need just one interface to work with any PHR product on the market.

“It takes cost out of everyone’s software engineering and implementation budgets to standardize,” says Halamka. “And it obviously empowers a lot of people.”

Even a major player like Google succeeds by giving patients access to “as much of their data as possible—from providers, payers, labs, pharmacies—and that won’t happen if all those individual entities are not willing or able to interface with Google,” Halamka says. Any given PHR product will only be as useful as the data that can be gotten into it, he argues.

The Google Health pilot operated on a customized interchange format (a Google version of the ASTM Continuity of Care Record), but the company has committed to using the CCD, Halamka says. Microsoft’s Health Vault will do the same, and over the next year he expects to see other vendors and hospitals adopting the standard.

Dullabh agrees that a PHR’s core value is its ability to gather information from many different healthcare encounters. “In order for information to move between systems [and] applications, the drive to use standards would be compelling. Because, unless you want to be someone very special, why would you develop a proprietary system in today’s times?” she asks.

Dullabh also sees privacy and security as organizing forces. Somewhere down the line, she says, some authoritative assurance such as certification should give consumers confidence that a particular product will safeguard their privacy. Advertising that seal of approval would be a strong motivator for product developers to adopt the related standards, she says.

In the meantime, she sees the need for increased communication. “There are a number of very interesting efforts under way. In some ways a lot of them may be complementary, but because they all are sort of starting up on their own—and they are fast and furious—it would be good, even at this stage, if we start building connections between those efforts.

“As we talked with experts, it became apparent that people are very deep in their specific areas. They are sort of aware of what else is going on, but I don’t think everyone is having the opportunity to talk more broadly.” That situation is compounded by a wide field, including companies that have not previously worked in healthcare.

The goal, as Dullabh sees it, is greater communication early to reduce the burden of standards harmonization later. “I think that even at an earlier stage than [standards harmonization]—where things are germinating and intelligent people are focusing time and energy on this—it would be good to start building connections.”

Kevin Heubusch (kevin.heubusch@ahima.org) is editor-in-chief of the Journal of AHIMA.