One of the challenges in connecting the dots in health care – linking together all the fragments of health data about a given patient that is scattered widely across many different settings of care – is trying to match patient identities. The practice-internal ID number given to a patient in one medical practice has no bearing on the one given to the same patient in a different practice. Even the names may be slightly different (there are multiple variations of Gonzales/Gonzalez, for example).
So how do we link it all together? When a patient is referred from one doctor to another for a consultation, the identity matching is fairly manual. Typically, a referral form is sent, with patient name, date of birth, insurance information, authorization number (if needed), and a brief description of what the referral is for. If accompanying clinical notes are to be sent, they are usually sent by fax, and the identity-matching is done by hand. This is adequate for the one-on-one way of connecting practices together, but doesn’t help achieve the goal of a seamless, shared medical record viewable by both physicians involved in the case.
The issue of matching patient identities in an automated way has been a challenge when trying to assign lab results imported electronically into an EHR. A “best guess” algorithm is generally used to make a likely match, and the lab reports thus drop into a “lab tests to be reviewed” bucket with the most likely patient assignment. Sometimes the assignment cannot be made (insufficient match of patient name and date of birth), and the patient associated with the lab result needs to be picked manually.
Best-guess matching works to an extent, and is even pretty scalable. Sending electronic prescriptions through the national pharmacy-intermediary hub Surescripts, for example, identifies a patient by first name, last name, date of birth, and zip code. This is generally sufficient for the purposes of getting the prescription to the pharmacy endpoint, and verification of the patient can be done manually at the retail pharmacy. Refill requests sent by pharmacies back to the prescribing physician passes these same 4 identifiers, and the EHR uses them to make a best-guess – but again, a manual confirming step is needed to make sure the right patient is being referenced.
National Patient Identifiers
One approach that has been proposed is the creation of unique national patient identifier numbers, similar to social security numbers, which would thus be used for all healthcare transactions. This separates financial identifiers (social security numbers) from healthcare identifiers, and allows the application of HIPAA rules to the patient identifier numbers and the health data linked to it.
Given that such a proposal is still theoretical, there has been considerable debate about whether we, as a nation, should do this. Assuming that such a national identification system comes into being, and that there is universal enrollment in such a system (like there is for social security numbers), and assuming that all health transactions use such a number (this would mean introducing a new data field into insurance systems, hospital systems, EHR systems, lab systems, imaging systems, pharmacy systems – in short, every single system currently designed to process healthcare transactions), such an identifier would make interoperability much simpler.
There are also some rather rabid opponents of such a system, based not so much on the system-revamp burden of changing every single computer system that is involved in health care (remember Y2K), but instead based on exaggerated fears of breach of privacy. There is an argument that somehow patients do not have control over who sees their personal health information (PHI), and that this data is currently used by the government and by private corporations for internal benefit. This is simply not true – not just a different interpretation, but in fact factually incorrect. PHI is rigorously protected by HIPAA, and adds a layer of identity protection dramatically more stringent than the general identity protection afforded to other personal data (such as personal financial data). All PHI, whether it is on paper or in electronic form, is strictly prohibited from being shared without specific patient consent. EHRs, both locally hosted and web-based, must adhere to these rules.
When PHI is breached, disclosure must occur. This is an ongoing vigilance within the health IT community. Ways to safeguard electronically-stored medical information is constantly being improved upon. Large-scale HIPAA breaches catch headlines, but are relatively rare and usually involve theft of machines with local PHI on them (something that is not encountered with web-based EHRs). However, the most common form of HIPAA breach is small-scale snooping (unauthorized looking at specific records of family/friends/celebrities) – this happens with paper as well as EHRs, though the Access Logs of EHRs can catch such activity much more effectively than the unrecorded access of paper charts.
So what about Universal ID numbers – are they a good thing?
The arguments against Universal ID numbers for healthcare that are based on fear of PHI breaches are not especially compelling – HIPAA offers very strong protection against such events, making health data even more secure than personal financial data. The privacy naysayers don’t have a credible argument, and have relied on premises that simply aren’t true.
The main thing of concern is the practicality of creating such a system. A large number of changes would need to take place, including the issuance of such numbers (new government structure), the creation of a policy framework to define where and how such numbers are generated, the ongoing effort to identify and merge duplicate ID numbers to the same person, and changes to include this new data field in every single piece of healthcare-related software used by all elements in the highly complex healthcare ecosystem. The effort is not unlike the issuance of NPI numbers to healthcare providers (physicians, hospitals, labs, etc.) – only on a much larger scale, as it encompasses everyone in the country.
Yes, having such a number would simplify record-matching. However, I won’t hold my breath for such a system to become realized, due to the complexity and scale of such an implementation. In the meantime, we will continue to rely on best-guess algorithms using elements currently available, and continue to rely on manual validation of these best-guess matches. It’s not ideal, but it’s what we have.