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.
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.
A Standard Definition
The question “what standards apply to a PHR?” begs a question in response: “what kind of PHR?”
In April the National Alliance for Health Information Technology completed a PHR definition based on a year’s worth of review, forums, and public commenting (see box). One result may be that the standard, consensus-based definition helps give shape to standards work.
“Today you say ‘Hey, Revolution Health has a way where you can type in your medication list—that’s a personal health record,’” says Halamka. “Is it really? I guess it could be, but so is a word processor, then.
“If I define a personal health record as a seamless interface to a pharmacy, a payer, a clinic that allows you the patient to at any time pull your information from those entities, apply privacy flags, exchange it with others as you will, add to your record, and push it back—well, that’s a very different set of standards, a different set of privacy issues.”
A common definition, then, Halamka says, offers focus, helping define the scope of the architecture and the standards necessary.
Defining the Record, Not the System
In mid-May the definition was in draft form, waiting presentation to the American Health Information Community. At press time it ran:
Personal Health Record (PHR)
An electronic record of health-related information on an individual that conforms to nationally recognized interoperability standards and that can be drawn from multiple sources, while being managed, shared, and controlled by the individual.
Several features leap out from this definition. Most obviously, the Alliance has defined electronic records only. Secondly, it has defined the record itself, not the system that produces it. Thus the definition does not describe functionality.
The scope is narrower yet. Only records controlled by the individual meet the definition. Thus portals hosted by a payer or provider—windows into the organization’s record, where access and control are maintained by the organization—do not meet the definition. This may be the most significant feature in distinguishing a PHR from an electronic health record or an electronic medical record.
Finally, the record conforms to “nationally recognized” interoperability standards and is capable of drawing information from multiple sources. That narrows the definition further, omitting a whole swath of the current market that offers siloed products unable to share information, such as services that serve primarily as diaries or reference tools.
A Different Definition for Healthcare
There is something else notable about the PHR and the other four definitions. They are short.
“These definitions are going to look very different than what people in healthcare are used to seeing from definitions,” says Jane Horowitz, the Alliance’s vice president, chief marketing officer, and project lead.
“They don’t run on for four or five pages, as you would find in a functional or technical definition, where that makes sense.” Instead, she says, the definitions aim to make the terms accessible and useful for policy makers, contractors, customers, and the public.
According to Horowitz, the work groups asked themselves: “Can we provide standard terms so that when policy makers are drafting or evaluating policies, there is a common language, a common way of looking at it? And can we provide a reference point for standards organizations as they do their work? And finally, can we facilitate more effective contracting between a vendor of the product and their customer?”
Each definition is bracketed with an overview and characteristics that provide context and logic behind the definitions. The format, Horowitz says is a “very concise way of looking at it, and if we’ve done our job, then it is free of any ambiguity, anywhere.”
Here Today, Gone Tomorrow?
It might seem that today’s fast-changing health IT climate would be tough on definitions. But approached properly, definitions last. For this reason, the work groups brought in a lexicographer.
“Working with a lexicographer was extremely eye-opening for many of us,” Horowitz says, and it was “extremely helpful” in understanding what constitutes good definition writing.
“A good definition will stand for a long time,” she says. “So we don’t think these definitions will change much.”
Over time, the descriptive text surrounding each definition—the overviews and distinguishing characteristics—may require tweaking as uses and functionality expand.
Whether HHS will “mandate” federal use of the definitions—similar to what it has done with standards from HITSP—is unclear at this stage.
Horowitz expects the definitions will work their way into the contracts, proposals, and descriptions of HHS health IT initiatives. The definitions could serve as touch points in regulatory work.
The Definitions Project
The PHR definition results from a contract issued by the Office of the National Coordinator for Health IT to reach consensus on definitions for five health information technology terms. The Alliance worked under the guidance and management of consulting firm BearingPoint.
Five terms defined by two work groups:
- Records terms: EMR, EHR, PHR
- Network terms: HIE, RHIO
- Literature review
- Two public forums
- Two public comment periods
- Health IT concepts expressed in a language the public comprehends
- Standard terms that policy makers can use when drafting and evaluating policies
- A reference point for standards development activities
- A reference point for more effective contracting between vendors and their customers
For more information, visit http://definitions.nahit.org.
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 (email@example.com) is editor-in-chief of the Journal of AHIMA.
"IT Standards for PHRs: Are PHRs Ready for Standards? Are Standards Ready for PHRs?"
Journal of AHIMA