Every vendor in patient data access says the same sentence: we can get the record.

It sounds like a single capability, the way "we can send email" is a single capability. It isn't. There are two architecturally different ways to retrieve a patient's records, they return different things, and the choice between them determines what your product can actually do. Most vendors only do one and don't draw attention to which.

It’s worth understanding the difference before you evaluate anyone, including us.

Method One: Straight From the EHR

Certified Electronic Health Record vendors  are required to expose standardized APIs that make it easy for patients to use an app or service of their choice to obtain a copy of their health records.

When you retrieve this way, it’s first hand data, straight from the source. You get the patient's clinical data as structured FHIR resources: conditions, medications, lab results, allergies, immunizations, encounters, and vitals. And critically, you also get what's attached to the chart. Progress notes, imaging reports, procedure notes, discharge summaries, usually as HTML, PDF, or plain text files.

That second category is where the reasoning lives, and it's the part that gets lost most often.

The cost of this approach is that somebody has to build and maintain an integration with each EHR. That's not primarily a coding problem. It's registration processes, approval queues, business agreements, authentication quirks that differ system to system, sandbox environments that behave differently from production, and vendor support inboxes that answer on their own schedule rather than yours. It's relationship work and maintenance work on an ongoing basis.

Method Two: Querying a Network

The other approach is to ask a network rather than a single EHR.

Under TEFCA, participating organizations exchange records through QHINs. You submit a query, the network figures out where that patient has records, and documents come back. The reach is the appeal.

What comes back is usually a collection of CCDAs. A CCDA is essentially a visit summary. It carries a real and useful slice of the chart, and for a lot of purposes it's genuinely fine.

But a document is a summary of a record, not the record. CCDAs generally don't include attachments, which means the nuance found in progress notes, imaging reports, and the physician's narrative may not always make the trip. And because documents get generated per encounter or per request, you often receive many of them describing overlapping periods, with the same medication appearing across a dozen files in slightly different forms, requiring a lot of work to clean up.

There's a further wrinkle we've written about before, which is that a lot of what gets delivered as FHIR through the networks is derived from legacy document formats rather than being FHIR-native. It looks like structured data on arrival. But ultimately, it’s only as good as the CCDA it was converted from.

Why the Difference Shows Up in Practice

Consider a patient who saw a physician for fatigue. Bloodwork came back showing a deficiency, and the physician told them to start a daily supplement at a specific dose.

Pull that record through a structured-data-only path and you'll find the labs, the encounter, maybe a diagnosis code. What you probably won't find is the instruction, because a supplement recommendation isn't a prescription and it isn't a discrete medication entry. It was free text in the progress note. Retrieve the attachments and it's right there. Retrieve CCDA only and it may never have been included in the first place.

Multiply that across a chart. Why a medication was stopped. What the physician was ruling out. What the patient said their symptoms were. Which of two possible diagnoses the specialist actually favored and on what basis. That's the material that turns a list of data points into a clinical picture.

It matters more, not less, when the consumer of the data is a model rather than a person. A clinician skimming a stack of overlapping documents can hold the redundancy in their head and ignore it. An agent working through the same stack spends its context window reconciling twelve versions of the same medication list before it can begin reasoning about the patient at all. Cleaner input isn't a nicety there. It's the difference between an answer and a timeout.

Why We Do Both

For the first several years, we only did the first one. We built direct integrations across the major EHRs because we wanted the fidelity, and because the product we were building at the time depended on it.

The limitation of that choice is obvious in hindsight. Direct integration gets you excellent data from the systems you've integrated with, and nothing at all from the systems you haven't.

So we added the network path. A patient verifies their identity, and we query on their behalf for whatever records exist across the participating organizations, including providers the patient wouldn't have thought to mention or couldn't have named.

Both paths, one integration, one normalized output. Where we can reach the EHR directly, you get the full-fidelity version with the attachments. Where we can't, you get network coverage rather than a gap.

What to Ask Anyone Selling You This

Four questions, and they work on us too.

Which method do you use, and if it's both, which one am I getting for a given patient? Do I receive the unstructured attachments or only CCDA’s? Is the structured data FHIR native or just CCDA’s converted to FHIR? And when the patient's chart changes next month, do you notify us, or do we have to query again and see if there’s any change?

Vendors who only do one of the two will usually answer the first question by describing the outcome rather than the mechanism. That's the tell. "We get you the complete record" is a claim about the destination. The mechanism determines whether it's true.