A patient signs up for your product. You ask them to connect their medical records, they agree, and you show them a search box.

They start typing the name of their cardiologist's practice. Nothing useful comes back. They try the doctor's name. Still nothing. They try the neighborhood. They close the tab.

You'll see that in your funnel as a drop-off at the record connection step, and you'll probably file it as a UX problem. It isn't. It's the moment your data coverage quietly stops mattering.

What a Record Search Actually Asks Of Someone

Most patient-facing retrieval flows present the patient with a list of health systems to choose from. That list looks like a directory of care providers. It's really a directory of EHR endpoints, organized by whichever legal entity operates each one.

Now consider what the patient actually knows. They know their doctor's name, usually. They know the practice name, often. They might remember the street, or the building, or that it was the place near the grocery store. What they almost never know is which corporate entity operates the electronic health record their chart lives inside.

Why Nobody Knows Their Own Health System

Healthcare has spent the last fifteen years consolidating. Independent practices and small specialty groups get acquired by hospital systems and larger networks, and when that happens the practice usually keeps its name, its signage, its phone number, and its front desk staff. What changes is the back end. The charts migrate into the parent organization's EHR.

Here's the version we run into constantly. A patient sees a cardiologist at a well-known cardiology practice in their city. At some point that practice was acquired by a large regional health system, so the EHR endpoint holding their cardiology records now sits under the parent organization. The patient has no idea. They went to the cardiology practice, the sign out front still says the cardiology practice, and as far as they're concerned that's who has their records.

They type the practice name into the search box. It returns nothing, because the endpoint is filed under the parent system.

The patient isn't confused. They're entirely correct about where they received care. The directory is organized around a corporate relationship they were never told about.

This Is Where Retrieval Actually Fails

The industry evaluates patient data access on coverage, completeness, and speed. How many facilities can you reach, how much of the chart comes back, how long does it take.

All three of those measurements start one step too late. Before any of them apply, the patient has to successfully identify the provider they want records from. If they can't, the retrieval never happens, and none of your other numbers were ever in play.

Which means a vendor can advertise access to hundreds of thousands of facilities and still deliver, in practice, only the records from providers the patient happened to be able to name correctly. Coverage you can't reach isn't coverage. It's a number in a pitch deck.

What We Built Instead

We let the patient search by whatever they remember. The doctor's name. The practice name. A partial name. The city. Anything that's actually in their head rather than in a corporate filing.

Then we resolve that to the right endpoint on our side, including across acquisition relationships. A patient types their doctor's name or the practice name, and we route the query to the parent system's endpoint, because working out which larger organization now operates that practice's records is our job, not theirs.

As far as we know, we're the only patient-directed FHIR retrieval vendor that does this. Everyone else requires the patient to know and select the parent health system.

Why This Matters More Than It Sounds

The obvious effect is conversion. More patients successfully connect more providers, so you get more records per user and fewer abandoned sessions.

The less obvious effect is which records you lose when search fails, because it isn't random.

Patients reliably remember their primary care physician. That one's easy. What they struggle with is the specialist they saw twice, three years ago, at a practice that has since been folded into a larger network. The cardiologist. The endocrinologist. The oncologist they saw during a period they'd rather not revisit in detail.

Those are exactly the encounters carrying the diagnoses, the medication changes, and the clinical reasoning that make a record worth having. A patient who connects only their primary care physician has technically completed your onboarding flow while handing you the least informative slice of their history.

So the failure mode isn't just fewer records. It's a record that's systematically missing its specialist care, which is the part your product most likely needed.

What This Looks Like In Practice

If your product depends on patients finding their own providers, there are a few things worth measuring that most teams don't.

What percentage of users connect more than one provider? What percentage of connected providers are specialists rather than primary care? How many searches return zero results before a user gives up? That last number is usually the most uncomfortable one, and it's the clearest measure of how much of your coverage is theoretical.

Then compare that against what you'd expect. Most adults with any ongoing health concern have seen multiple specialists. If your data says otherwise, the data is describing your search box, not your users.

The Reframe

Conversion normally sits with the growth team. Search relevance sits with product. Data coverage sits with whoever manages vendors. Three different owners, three different dashboards.

In record retrieval they're one problem. The quality of the clinical data you end up holding is determined, upstream of every integration decision, by whether a patient could find their doctor in a search box. That's not a growth metric or a design detail. It's the first and least examined input to your data quality.

We built name-based search because we kept watching good retrieval infrastructure fail on a question no patient should have been asked in the first place.

If you'd like to learn more about Consolidate Health's API and how we retrieve a complete longitudinal record, book an intro call today.

If you prefer to try the product with zero commitment, you can request sandbox access.