This Year's Models: a Look at Patient ID in the Four Newly Demonstrated NHIN Prototypes

This winter the healthcare industry got a first look at four prototypes for a nationwide healthcare data exchange network. Created under contract to the federal government, the demonstration projects paired technology developers and healthcare providers in 12 communities across the US. The working models, presented at the government-sponsored NHIN Forum in January, are intended to spur the development of both national and regional health data exchange.

As the contractors wound up their first year of work and prepared to unveil their models, the Journal of AHIMA spoke with them about their individual approaches to arguably the biggest initial hurdles in widespread data exchange-patient identification and record location.

Demonstrating Patient ID and Record Location

The prototypes got their start in November 2005 when the US Department of Health and Human Services (HHS) issued four contracts to develop demonstrations for a nationwide health information network (NHIN). Each contract involved a consortium of technology developers and healthcare providers in three local markets, led respectively by Accenture, Computer Sciences Corporation (CSC), IBM, and Northrup Grumman.

Each was charged with testing patient identification and information locator functions; user authentication, access control, and other security protections; specialized network functions; and the feasibility of large-scale deployment. HHS also charged each consortium with sharing information about the architecture and prototypes with the federal government, each other, and the public. In January the prototypes were also presented to the American Health Information Community, the federal advisory committee mandated to advise HHS and the industry on adopting interoperable electronic health records.

The contracts were the last in a series awarded by HHS to achieve the Bush administration’s goal of widespread use of electronic health records by 2014. Previous contracts called for creating processes to harmonize health information standards, developing criteria to certify and evaluate health IT products, and finding ways to address variations in business policies and state laws that affect privacy and security practices.

The NHIN contracts give special significance to patient matching because robust matching capabilities will be key to the ambitious, universal data exchange required to connect local and regional networks in a coast-to-coast system. The HHS Office of the National Coordinator for Health Information Technology calls patient matching a primary interoperability issue. A survey by eHealth Initiative came to a similar conclusion, with accurate patient matching and identification in data exchange identified as the second most pressing issue behind financial sustainability.

As important as patient matching may be, however, there is no single best way to accomplish it, a fact borne out in the different methods utilized by the contractors. While the means may be distinct, all have achieved operable networks to exchange protected data between disparate organizations, and all confronted similar challenges and addressed similar issues in creating the networks. A first step was to study local conditions.

Local Autonomy

The effort led by CSC had to work with data exchange and patient identification functions already in place at its three participating regional health information organizations (RHIOs). Indiana Health Information Exchange in Indianapolis, MA-Share in Boston, and Mendocino Health Records Exchange in Ukiah, CA, were already collaborating in a Connecting for Health initiative to develop a national health information exchange network that started in January 2005.

Each RHIO had slightly different methods in place for local record exchange prior to joining either Connecting for Health or the HHS-contracted efforts, so CSC did not enforce a common application solution or require participants to adopt the same technologies. “We thought it best to allow a great deal of autonomy at the local level,” explains Greg DeBor, partner and leader of the CSC project.

Because each RHIO was already using a probabilistic matching algorithm, CSC did not attempt to develop one at the NHIN level. Instead, participants settled on six search criteria for patient identification: first and last names, middle initial, date of birth, gender, and zip code. When one RHIO wants to check for records at another, these data elements are transferred via an internetwork bridge. The receiving RHIO then applies its own algorithm to seek a match within its network.

This approach enables each RHIO to establish its own search procedures and priorities, in keeping with community norms and in compliance with state regulations. For instance, one element in the Indiana algorithm is Social Security number; however, state law prohibits this in Massachusetts. The RHIOs can also set different weights for search criteria and different return thresholds for match requests.

Developing a Centralized Approach

If CSC established only the barest transactional structure at the NHIN level, the Accenture-led consortium took a different approach and developed a robust central architecture. Its three participating local networks-Eastern Kentucky Regional Health Community; CareSpark in Kingsport, TN; and West Virginia eHealth Initiative in Charleston-all use the same probabilistic patient identification methodology.

The model also involves a core amount of demographic data maintained at the NHIN level, along with a unique patient identification number that is used only within the Accenture network. When a member RHIO requests information on a patient, the system compares the request with the NHIN-level master patient index. If the system determines that the patient is associated with a unique patient identification number, it links the records to particular servers at the participating RHIOs.

One of the main considerations in using this approach was the need to develop a scalable solution, according to Brian Kelly, MD, executive director and leader of Accenture’s NHIN project. “When it comes to patient matching at the regional versus national level, if there are only three RHIOs, it’s probably OK at the regional level. But if there are 1,000, there may be performance issues,” he explains.

In the Accenture model, a message sent to the NHIN level would identify where the patient’s records were located, and the requesting RHIO would then contact only the RHIOs known to have records. “Think of the impact of messaging at those two levels versus messaging all RHIOs,” says Kelly.

Accenture’s choice to maintain a set of basic demographic information at the NHIN level is a departure from some of the other prototypes. “If you want data on a specific patient and go to the RHIO level [to obtain it] that’s fine for a physician seeing a patient, but what happens if you need to aggregate data for biosurveillance? That’s the value in aggregating core data,” says Kelly. “We’ve also spent a lot of time normalizing the data so members can run decision support.”

Patient Privacy, Local Autonomy

The IBM-led consortium also employed a unique NHIN-level patient identification number to link facility-specific records and a probabilistic patient-matching algorithm. Like the Accenture model, this unique patient number is used only within the IBM NHIN architecture, and the participating RHIOs cannot use it for other purposes.

The network’s three local RHIOs-Taconic Health Information Network and Community in Fishkill, NY; North Carolina Healthcare Information and Communications Alliance in Research Triangle; and North Carolina Healthcare Information and Communications Alliance in Rockingham County-have the freedom to run on different hardware and software platforms. “Our architecture is agnostic. It can handle different types of systems,” explains Casey Webster, executive for IT architecture and leader of IBM’s NHIN project.

The IBM consortium elected not to house any demographic data at the NHIN level. “Storing data outside the existing clinical enterprises is not the wrong thing to do, but it requires that another entity has to be trusted and hosted properly. We wanted to avoid any possible data corruptions or misuses,” says Webster.

Like Accenture, the Northrup Grumman consortium elected to maintain a limited amount of demographic data at the NHIN level. “There’s sufficient information to identify a patient and know what facilities know about me as a patient, but not specific clinical information,” explains Robert Cothren, PhD, chief scientist and project manager for the NHIN contract.

For instance, a query on the name Robert Renfro would identify the participating facilities that had information on Mr. Renfro and the types of information the facility could provide, such as laboratory and imaging tests. It would not specify whether there actually were laboratory or imaging results available for Renfro, or what the results were. The requesting facility would need to query the individual organizations identified through the NHIN-level search to ascertain exactly what records were available.

Northrup Grumman’s three participating RHIOs-Santa Cruz RHIO in Santa Cruz, CA; HealthBridge in Cincinnati, OH; and University Hospitals Health System in Cleveland, OH-were already established and had their own procedures and technologies, so it sought to make the patient identification function as simple as possible, according to Cothren.

“We wanted to keep the exchange lightweight and keep away from doing anything strong centrally. We felt that would be a barrier for organizations to participate. We also felt that patients would not like having any of their information stored in external servers.”

Setting the Threshold for Matches

Even though each consortium used slightly different record locator and patient identification methods, all operated off a set of principles that reflected the needs and cultures of the participating RHIOs.

For instance, the Northrup Grumman project determined that it would be owned and controlled by the member organizations and RHIOs, that patient privacy was to be protected as much as possible, and that patient participation was to be encouraged and enabled through the network technology.

A major point of discussion for all four consortia was where to set return thresholds for the patient-matching algorithms. Lowering the threshold-the combination of relative weights set for each criteria as well as the number of criteria that a query must match in order to identify a potential patient-results in a higher false positive rate. This means more potential matches, but ultimately incorrect records may be identified.

On the other hand, raising the threshold reduces the number of false negatives but may miss close but not exact matches. For instance, a very high threshold might exclude as a potential match two records for Susan A. Smith with respective birthdays of January 2, 1950 (01-02-50) and February 1, 1950 (02-01-50).

For now, most of the consortia have erred on the side of a high threshold, even though it means some matching records will be missed. “At the risk of sometimes not returning data, we set a very conservative threshold. We didn’t want to run afoul of any HIPAA regulations or increase the risk of medical errors or bad practices because of a match to the wrong person,” explains IBM’s Webster.

Northrup Grumman set the threshold to return only exact matches. “The response comes back as either a yes or no. It does not give the five closest matches. It’s either a complete or no match at all,” explains Cothren. “It was our policy decision to have only one return to protect privacy.”

The contractors indicated their participants are still discussing a number of policies related to patient matching with most still not firmly established. Consistent matching thresholds may become a point of industry debate as the NHIN matures, CSC’s DeBor predicts.

The consortia are also continuing to establish and refine policies about informing participating organizations of inconsistencies in their data in order to improve match rates. For instance, in the above example of two records for Susan A. Smith (one with a birthday of 01-02-50 and the other 02-01-50), once the requesting organization confirms with the patient her correct birthday, should it attempt to inform the responding institution that it has erroneous data?

While Accenture has invested in creating a core set of robust demographic data at the NHIN level, other consortia have not moved in that direction. “We make no attempt to resolve discrepancies. We decided not to try to force the historical record at the local level,” explains Cothren of Northrup Grumman.

Data quality will be an ongoing issue for the NHIN, DeBor predicts. There aren’t insurmountable technology issues, but there are potentially insurmountable data integrity issues. “How can you guarantee a name will always be spelled correctly? There’s a misconception that because we’ve overcome technical matching challenges and there are clear standards for HL7 messaging that everything is worked out.”

Gina Rollins (rollinswrites@verizon.net) is a freelance writer specializing in healthcare.