All about patient IDs
Mar 30, 2017
Sometimes when talking to people, the engineer in me wants to blurt out “just get to the point.”
That’s what this blog is about—getting past the details and minutiae of healthcare integration and focusing on the important stuff that makes these projects both possible and successful.
So, what really matters when it comes to integration? Well, before any of the "meat" of integration can take place—before you can exchange orders, file notes, or pull CCDs—you have to get in sync with the EHR. To do this, you have to lay some fundamental groundwork comprised of one essential data element: patient identifiers.
The power of the patient identifier
To push any data into an EHR, you must know the patient ID; to query for a chart summary, you must know the patient ID; to make an appointment or post a result or add a charge to a patient account, you must know the patient ID.
Until a universal patient identifier is adopted, we must deal with the fact that each health system uses its own identifier for patients. In fact, some health systems use many more than that:
Some health systems have a single patient identifier across their entire system. You'll hear different names at different health systems, but medical record number is the most common label and generally understood to be this universal ID you're interested in. Despite the variation in name, you’re usually safe using the title patient ID as well, as I have in this article.
Some health systems have multiple patient identifiers. I've seen hospital systems with a different identifier at each location, so a given patient could have a dozen patient IDs or more. Sometimes, a health system will have a mostly universal identifier for their patients, but they acquired a hospital or clinic recently and haven't converted those patient records, so any patient seen at both locations would have two IDs.
All this being said, here’s some practical advice for app developers: code your system with the assumption that there will be just one patient ID for you to work with. When you begin integrating with a new health system, always have the discussion early regarding whether this assumption is true, and work from there.
Learning the patient ID
As we've established, before you can send any data into a health system, you must know the patient ID. Depending on your workflow, there are a few different ways to get your hands on it:
"Listen" to the Patient Admin data model
Registration systems send a steady stream of data regarding the patients that are being registered in their system. Linking your application to this data feed gives you a steady stream of information about patients, including updates to demographics, identifiers, next of kin, and visit activity at the hospital or clinic.
A Patient Admin data feed can feel a lot like drinking from a firehose. Watch for specific events (tip: we can filter them for you) and store the relevant patients and relevant activities. Filter and ignore the rest.
Grab the patient ID from another data model you're using, such as Orders or Scheduling
This is for systems that only need to know information about a patient when there is relevant activity. For example, if your application’s workflow is driven by orders, you may get away with simply using an Orders data model and storing the relevant patient demographics (including that handy patient ID) when you receive an order message.
Perform a historical data backload.
Some systems need to know who the patient is prior to any registration or ordering activity. For example, if you have an app that any patient from a health system can use, there may not be a convenient message trigger prior to the patient using your app.
In cases like this, you'll need to pursue converting the patients from the registration system into yours. This is a relatively straight-forward process, but it does require a bit of effort from the health system’s IT team. One point to bear in mind: if this is your strategy, you will also need to ensure your demographics remain up-to-date by using an incoming Patient Admin data model.
Query for demographics
Some registration systems support a demographics query, known in Redox as Patient Search. This allows you to gather and query for patient demographics (the more you can get, the better the search results will be) and then send those to the registration system to determine if there is a patient matching those demographics. If there is, you’ll get the patient ID in the return message and be able to use it in future integrations.
When using the Patient Search data model, be sure to address what your application does if no patient information is returned. This could happen if the patient isn’t registered at the health system or there are mulitple patients with very similar demographic information, so a positive match couldn’t be made. This could also occur if the patient has changed some aspect of their demographics, such as a change in address or change in name from getting married or divorced. Regardless of the reason, this outcome is unavoidable, so your application should have an established protocol for when this happens.
Patient Management and Merging Duplicates
In 2013, a survey of hospitals found the rate of duplicate patient records to be between 8% and 12%. Health systems work hard to ensure their patient database is as clean as possible because not only does this give patients the best chance of their doctors having access to their full patient record when delivering care, but it’s required in Meaningful Use. To do this, health systems run tools that analyze their master person index (MPI) and identify potential duplicates. They then review the list of duplicates and perform chart merges for each confirmed duplicate in their system.
When merges happen, downstream systems need to begin using the new patient identifier to ensure your data is filed to the correct place in the EHR. Merges are communicated on the Patient Admin data model with the event type of “Patient Merge”.
We hope this gives you a clear rundown of what patient IDs are, how to obtain them, and how they are the fundamental building blocks that truly power integration. If you have any questions, feel free to reach out!