The Central or Non-Central Question: Identifying Patients Statewide

Determining the best way to identify patients statewide or nationally is one of the hottest topics of debate within today’s health IT 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 securing their protected health information (PHI).

What we can not 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 in emergency departments?

If there was only one way to do this, or a single point of concern, it wouldn’t be such a hotly debated topic. The challenge is, there are several viable ways to get the job done — each with pros and cons.

Two Approaches

States have generally begun implementing one of two approaches for their record locator service (RLS): one with a central, statewide patient registry (similar to the Enterprise Master Person Index (EMPI) used in hospitals), or a decentralized RLS based upon 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 RLS uses searching/matching technology to identify the correct patient, and sends 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 RLS acts like a query broker. The state RLS 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 RLS can return summary clinical data (e.g. medication lists) along with the demographic information.

Pros and Cons

Each of the approaches have different advantages and disadvantages based on performance, accuracy, and security.

Performance and Accuracy

An RLS with a central registry guarantees certain levels of performance, reliability, and accuracy, which can be critical in an emergency department. Because basic patient information for every citizen is in one location, response 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 not available.

An RLS 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 in an emergency situation elsewhere.

With basic patient information in one place, information sharing between and among organizations is much more accurate and efficient. Stakeholders can put high trust in the system.

Security

Security is generally where the centralized vs. distributed approach brings out the debate.

From one perspective, a centralized registry provides enhancedsecurity 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 is not at risk.

From another perspective, keeping patient information at the local level denies hackers a single point to attack. However, then, 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 response – a false-negative response.

From a performance perspective, particularly in the case of larger states, many of the 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 ROI be achieved.

Conclusion, Advice, and Considerations

From our perspective, the central patient registry approach is a smarter long-term decision, for performance, accuracy, information sharing, and even security reasons. Yet, making a final decision on the type of architecture to implement for statewide patient identification is not easy.

When making your decision, consider the size and maturity of the HIEs already in place. Will they be able to exchange information with one another? Also consider an approach that gets you wherever you’re going in stages. You can, for example, start with a federated system and then move to a centralized one.

Regardless of the method you choose, let’s all keep our eye on the same ball — of accurately identifying patients while minimizing risk.

Dr. Schumacher is Chief Scientist and Lorraine Fernandes is Health Ambassador for Initiate, an IBM Company.