The Central or Noncentral Question: Identifying Patients Statewide
By Scott Schumacher, PhD, and Lorraine Fernandes, RHIA
Determining the best way to identify patients statewide or nationally is one of the hottest topics of debate in today’s HIT community.
We all agree on the importance of identifying patients, of ensuring that information about a patient is accurate and accessible regardless of where that patient is being treated.
We also agree on the importance of eliminating risks and securing patient information, of maintaining patient privacy, and of securing protected health information (PHI).
What we cannot seem to agree on is the best way to achieve successful patient identification while eliminating risk.
What is the best architecture to implement for identifying patients throughout a state and, potentially, across state lines? How can states ensure the privacy of citizens’ health information while providing timely responses to medical questions to doctors in their offices or emergency departments?
If there was only one way to accomplish this, or a single point of concern, it wouldn’t be such a debated topic. The challenge is, there are several viable ways to get the job done, each with pros and cons.
States have generally begun implementing one of two approaches for their record locator service: one with a central statewide patient registry (similar to the enterprise master patient index used in hospitals) or a decentralized record locator service based on sending a distributed query to local participants.
The central registry approach contains a database of basic patient demographic information collected from the local participants. Within this architecture, an organization issues a query on a particular patient and the record locator service uses searching/matching technology to identify the correct patient, sending back the demographic information along with pointers to the local systems that house the detailed clinical data. The key point is that the patient identification is handled entirely by the central system.
Conversely, with the distributed approach, all information, both demographic and clinical, about each patient remains within each health information exchange (HIE) or local organization’s database. In this architecture, the state record locator service acts like a query broker. The state record locator service receives the patient ID request, reformats and relays the query to the participants, receives and ranks the responses, and returns the information to the user. In this model, the record locator service can return summary clinical data (eg, medication lists) along with the demographic information.
Pros and Cons
Each approach has different advantages and disadvantages based on performance, accuracy, and security.
Performance and Accuracy
A record locator service with a central registry guarantees certain levels of performance, reliability, and accuracy, which can be critical in an emergency department. Because basic patient information is in one location, responding to a query will take only seconds—if that long. And because patient information is stored centrally, it is not subject to multiple types of data formatting, errors in sending, or false-negative results when information is unavailable.
A record locator service with a central registry also opens the door for proactive healthcare management—for example, sending alerts to a patient’s doctor or “home hospital” if that patient is admitted elsewhere in an emergency situation.
With basic patient information in one place, information sharing between and among organizations is more accurate and efficient.
Security is generally where the centralized vs. distributed approach brings out the debate.
From one perspective, a centralized registry provides enhanced security and privacy. With this approach, basic patient information is in one place, protected by a single security system that is governed by a single set of security parameters. And since patient clinical information continues to reside within each individual HIE or healthcare organization (only basic information is centrally stored), a patient’s personal data are not at risk.
From another perspective, keeping patient information at the local level denies hackers a single point to attack. However, the system is only as secure as the weakest link.
The trade-offs for ultimate security, however, are performance and accuracy—specifically an increased risk of false negatives. Let’s say a request is sent for data on a particular patient. If the local database that holds that data is down, the requestor will get a negative, or false-negative, response.
From a performance perspective, particularly in the case of larger states, many local systems simply cannot handle the level of traffic generated based on the number of requests made. If the system cannot handle the traffic, responses will be slow. In an emergency department situation, waiting several minutes for a response is simply not an option. From a trust perspective, if users can’t trust that they’ll get a timely response, they will not use the system and the information sharing goals will not be met nor will the release of information be achieved.
Conclusion, Advice, and Considerations
or performance, accuracy, information sharing, and even security reasons. But a final decision on the type of architecture to implement for statewide patient identification is not easy.
When making this decision, consider the size and the maturity of the HIEs already in place. Will they be able to exchange information with one another? Also consider a staged approach. For example, start with a federated system and then move to a centralized one.
Regardless of the chosen method, let’s all keep our eye on the same goal of accurately identifying patients while minimizing risk.
— Scott Schumacher, PhD, is chief scientist and Lorraine Fernandes, RHIA, is health ambassador for IBM.