To find clinical data, you need a Record Locator Service (RLS), and it’s gotta be a good one!
Search engines are great for finding a book or a recipe, but you can’t just Google for clinical records! That’s a problem for our Record Locator Service (RLS) to solve.
Once patient data has been generated, it’s almost always part of one private network or another that Particle’s platform connects to. But the problem with finding that data - and sending it to a new provider - is that the networked data isn’t indexed. You’d have to know exactly where that data resides if you wanted to download it. An RLS addresses this by actively tracking down patient records.
An RLS is like a detective for clinical data. It’s an algorithm that finds locations where patient data is stored (actually downloading that data takes a separate tool).
This detective never sleeps. It's constantly helping us collect clinical data at scale. With the demographic information that users send to our API, an RLS can discover a patient’s past medical history.
The RLS queries endpoints (a.k.a. provider-run servers) on relevant networks, asking if they contain records that match the submitted demographic information.
Here’s the catch though - a healthcare data platform can’t query every endpoint in the country. Healthcare systems can’t handle that volume, and HIE networks don’t appreciate it either!
So the RLS has to search strategically. It finds patient data in a targeted fashion with the limited information that it has. The RLS queries all the endpoints where a patient is most likely to have their healthcare records stored.
Different networks have their own standards here. Take Carequality, where participants will receive your everyday ITI-55 Cross-Community Patient Discovery Request, which every implementer is required to respond to.
Some record locator services use a radius-based search. Particle’s RLS relies on additional proprietary methods to efficiently look for data.
Your average RLS is a set-it-and-forget-it affair. Once it’s built, it’s part of a larger platform where the developers rarely have time to error test.
But, as has been said many times before, healthcare is complicated. Particle has invested a lot into our RLS where others…maybe…haven’t.
Over the years, our team has seen implementation inconsistencies between different organizations. And there are countless small mistakes in the ways that records can be exchanged if an endpoint fails to implement directory specifications to the letter.
Even when endpoints respond in technically valid ways, an RLS needs constant maintenance to keep up. In one major network, for instance, each implementer has their own implementation of a mostly standardized framework for how they connect to network partners. However, they leave developers to identify each framework on their own. In IT, these tuning issues are a fact of life.
Since Particle is dedicated to providing clinical data, our engineering team works on this backend technology continually. Our RLS has improved over time because we’re targeting better results. We identify and code for inconsistencies around implementation. If a certain endpoint wants to respond in a certain way, we make sure Particle’s platform gets the data as well as any network partner can.
There’s more that makes our RLS stand out:
If every clinical data query is a dart, the RLS essentially generates a dartboard. 🎯 It tells us where to send requests for clinical data, but you’re not guaranteed to hit anything.
Ultimately, it’s data holders themselves that control the criteria for matching. We’ll ask endpoints if they have data, but each endpoint has its own rules for confirming a match and sharing data.
As a general rule, the more demographic information that we can send to an endpoint will increase the chances of a match. But each network only accepts certain demographic fields.
Since there’s no such thing as a unique nationwide identifier for patients - something we’ve long wanted to change - an RLS technically doesn’t search for a patient. Instead, it looks for a demographic match based on the information that it’s received.
Before the RLS runs, we’ll check our Master Patient Index (MPI). The MPI is an internally-managed patient directory where Particle can see if and where we’ve successfully found a patient’s data before.
Leveraging the MPI helps our users to find more complete records than they would by developing their own implementation. It prevents incomplete or redundant queries for the same patient.
Whether or not the MPI finds a match, the RLS search function will then kick into gear. Our Record Locator Service starts once our platform has received a patient’s demographic information, but before we’ve found their records. The RLS process is an early part of the complete life of a clinical data query.
The initial query that each endpoint receives basically results from our RLS. The sheer volume of endpoints means that most queries won’t find anything, but many queries will.
Whenever the RLS receives a match, another component of Particle’s platform will take over to download and process the data.
Getting network access doesn’t mean you’re automatically able to intelligently query the entire network. That’s something Particle’s team has put a lot of time and effort into. We obfuscate the searching and directory process for Particle users, which is another great reason to use Particle’s platform.
It’s easier than ever to track, view, and visualize records with Particle’s developer portal!
We know what APIs are, and what they do. So why choose an API as a product? APIs have become largely ubiquitous in the tech landscape, and for good reason. While there are alternatives, it's important to understand why we don’t choose them. Check out Part 2 of our three part miniseries on APIs.
Particle Health offers two distinct APIs: C-CDA and FHIR. They both offer the same level of unparalleled access to patient health data, but they differ significantly in how they offer access to that data. Let’s dig into Part 3 of our three part miniseries on APIs.