Finding the Right Records: Inside Particle Health's Record Locator Service

Particle Health's Record Locator Service (RLS) determines which healthcare endpoints to query when searching for a patient's records across the fragmented U.S. health data landscape

Finding the Right Records: Inside Particle Health's Record Locator Service

When a clinician queries a patient's health history through Particle Health, they're not simply pulling from a single database. They're initiating a targeted search across a fragmented landscape of tens of thousands of endpoints — hospitals, clinics, specialty practices, urgent care centers — each siloed, each holding pieces of a patient's story. The engine that figures out which of those endpoints to query is called the Record Locator Service, or RLS.

This post is a technical look at how Particle’s RLS works today — including a multi-method discovery process that's considerably more sophisticated than what we described when we first wrote about this in 2022.

The Core Problem

Health data in the United States is not stored in one place. It lives across a patchwork of EHR systems, health information exchanges, and national networks like CommonWell, Carequality and eHealth Exchange. When a query comes in for a patient, the naive approach — query everything — is computationally expensive, slow, and ultimately inappropriate. The smarter approach is to find only the endpoints that are likely to hold relevant records, and query those.

That's what RLS does. Before a single endpoint is contacted, RLS runs a series of discovery methods to build the right target list. Think of it less like a database lookup and more like a multi-signal inference problem: given what we know about this patient, where has their care likely taken place?

The Multi-Method Endpoint Discovery

RLS doesn't run a single algorithm. It runs up multiple distinct methods, each designed to surface a different category of endpoints. Some methods always run; others are conditional on what's known about the patient or what features are enabled for the querying organization.

Method 1: Geographic Search by Postal Code (Primary)

The first and most fundamental method queries endpoints within a radius of the patient's home zip code. This captures the majority of primary and specialty care for most patients. 

Method 2: “Hint” Postal codes 

RLS also accepts "hint" postal codes — locations where the patient is known to work or regularly receive care — and extends the geographic search to include those areas.  This is something a customer can specify as part of their query. 

Method 3 - Demographic Enrichment for old addresses and Snowbirds

The above were provided by customers.  In a feature we launched fairly recently, we use additional data sources to enrich the patients demographics.  This allows us to look up name alternatives, as well as additional previous addresses that the customer may not have had on record.  This feature is also especially useful for people who move between different locations, such as Snowbirds. 

Method 4: Prior Address History via Verato

Patients move. A patient who relocated from Ohio to Arizona two years ago may have years of care history sitting in Ohio systems that a zip-code-only search would miss entirely. To address this, RLS integrates with Verato's Enterprise Master Patient Index (EMPI), querying it for historical addresses associated with the patient's identity. Those prior locations are then used to expand the geographic search accordingly.

Method 5: Inbound Gateway Patient Matching (Reciprocal Discovery)

This method flips the logic: instead of asking "where might this patient have records?", it asks "which endpoints have already asked us about this patient?" When an external endpoint queries Particle's gateway and successfully matches to a patient in our system, we record that signal. If that same patient is later queried outbound, those endpoints are prioritized — because they've already demonstrated they know this patient exists.

Method 6: Specialty Search

When a query specifies one or more medical specialties — oncology, cardiology, endocrinology, orthopedics — RLS targets endpoints known to specialize in those areas. This feature is gated per organization, but the results have been notable.  In beta testing after launching specialty search in late 2022, 25% of queries that had previously returned no records successfully retrieved data, and 43% of patients received additional records beyond what a standard geographic query had found.

Specialty search is particularly valuable when the care you're looking for happened at a dedicated specialist practice that wouldn't surface in a geography-only search.

Method 7: Condition/Diagnosis-Based Search

Not every query will specify a specialty explicitly — but the patient's prior query history often contains diagnostic information that implies relevant specialties. Method 6 analyzes historical diagnoses from previous queries for this patient and uses those to infer which specialty endpoints might hold relevant data.

This is the difference between explicitly asking for cardiology records and recognizing, from a prior query, that this patient has a documented history of heart failure — and routing accordingly. It ensures that specialist endpoints aren't missed simply because the querying application didn't know to ask.

Method 8: Multi-State Health Systems 

Some large multi-state health networks aren't well-captured by geographic endpoint searches because their data infrastructure doesn't map cleanly to zip code boundaries.  Method 8 maintains a curated list of these networks and ensures they're included when appropriate. This list is maintained operationally and updated as the network landscape changes.

Why This Complexity Is Necessary

Each of these methods exists because real patient care is messy. People move, see specialists, get care at pharmacies, travel across state lines, and accumulate records in systems that don't talk to each other. A record locator that only looks close to home will miss the oncologist three states away. One that doesn't account for reciprocal matching will miss the endpoints that already know this patient exists.

The multi-method approach means no single failure point collapses the query — methods degrade gracefully, and each one adds a signal the others don't provide.

The result is a more complete picture of where a patient's records actually live, which means fewer gaps when it matters most.