Someone signs up for your product. Maybe it's an AI health assistant, a longevity program, a patient intake platform, or a care navigation tool. Whatever you're building, it gets meaningfully better the moment it knows what's actually in that person's medical record.

That record exists. It's just not in one place.

Most adults have clinical data sitting with several prior providers. A primary care physician, a specialist or two, an urgent care visit from a trip out of state, a hospital stay they'd struggle to name if you asked. None of those systems talk to each other in any useful way, and none of them are going to hand the data to your application because you asked politely.

That's the problem we solve. Not healthcare interoperability as a category, not a platform with modules you configure. One problem, which is getting a patient's complete clinical history into your product, with that patient's explicit permission, in a format your team can use the same afternoon.

The Patient Authorizes It

This is the first thing worth understanding, because it shapes everything else about how we work.

We don't move any data without explicit patient consent for that specific transaction. The patient authenticates, sees what they're sharing and who they're sharing it with, and approves it. Their access rights to their own records are established and protected under the 21st Century Cures Act, so this isn't a workaround or a grey area. It's the patient exercising a right they already have, and choosing your product as the recipient.

That model has a practical consequence people tend to notice later rather than sooner. Because the authorization belongs to the patient, you're not negotiating data sharing agreements with health systems, and you're not asserting a purpose of use that somebody might audit you on afterward. The patient decides. You receive.

Two Ways to Get the Record

There are two fundamentally different ways to retrieve a patient's clinical data, and most vendors in this space only do one.

The first is a direct integration with the electronic health record itself, through the standardized APIs that certified EHRs are required to expose. We've built those integrations across the major systems, including Epic, Cerner, athena, eClinicalWorks, NextGen, Flatiron, and Modernizing Medicine.

The second is querying a network. Under TEFCA, participating organizations can exchange records through QHINs, which reach a long tail of providers that no vendor is going to integrate with individually.

These two methods return genuinely different things, and the difference matters enough that we're giving it its own post next week. For now, the short version is that we support both, under one integration, and you don't have to pick.

Two Ways to Receive It

The other thing we support in two forms is delivery, because the people who need patient records aren't all building software.

If you're a platform, you get an API. Clean, normalized, documented, and designed for developers and AI agents rather than for people who've memorized the FHIR specification. If you want a medication list with start dates, stop dates, and dose changes, you get that, not a pile of overlapping resources to reconcile yourself.

If you're a law firm, a brokerage, or a small practice, you get a portal. You invite the patient, they authorize, and their records appear as they come in. No integration, no engineering time, no IT involvement at all. We built this because the segments with some of the most acute record retrieval pain, disability and injury cases, life insurance underwriting, concierge practices, are also the ones least likely to have an engineering team.

Same infrastructure underneath. Different front door depending on who's walking through it.

What Comes Back

Two things, and the second one is where most of the value hides.

The first is structured clinical data. Conditions, medications, labs, allergies, immunizations, encounters, vitals, normalized into a consistent schema so that Epic's version of a resource and Cerner's version arrive looking the same. Even though FHIR is supposedly a standard, every EHR has a slightly different flavor of it, and the normalization layer that handles those differences took us years to build.

The second is everything unstructured. Progress notes, imaging reports, procedure notes, discharge summaries, the attachments where the clinical reasoning lives. A structured medication entry tells you a drug was prescribed. The progress note tells you why, what the physician was ruling out, what they told the patient to do next. If you're feeding this into a model, that context is often the difference between a useful answer and a confident wrong one.

And it doesn't stop after the first pull. Anytime the patient's chart updates at any of their providers, a new visit, a new diagnosis, a medication change, a lab result, we push it to you as soon as the note is signed. Not a nightly sync, not a manual refresh.

Why This Is Infrastructure and Not a Feature

Here's the thing we've come to believe about this layer, having built the wrong version of it first and the right version second.

Record retrieval looks like a feature when you're planning it and behaves like infrastructure once you've shipped it. It's the input to everything downstream. Your risk model, your care plan, your agent's reasoning, your underwriter's assessment, your intake workflow. All of them inherit the quality and the currency of the data underneath. If that data is incomplete, or ninety days old, or arrives as a stack of documents someone has to parse, the ceiling on every feature above it is set for you.

That's why we've narrowed rather than broadened. We're not trying to be your analytics platform or your workflow engine. We're the layer that gets the record, keeps it current, and hands it to you in a shape you can build on. You'll do more interesting things with it than we would.

Where This Goes

Patients have always owned their health data. What's changed recently is that owning it and being able to actually use it have finally started to converge, and the infrastructure to make that real is being built right now, by a number of companies including us.

We think the interesting part isn't the retrieval. Retrieval will get easier and more commoditized as more players join the networks and more EHRs expose better APIs. The interesting part is what sits on top: consent that patients trust, normalization that developers don't have to think about, and a record that follows the patient rather than staying with whichever institution happened to create it.

That's the layer we're building. If you're building something that needs it, we'd like to hear what you're working on.

Book an intro call today to learn more about Consolidate Health's API.

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