A clinician handed a thick stack of records does something so automatic it barely registers as a skill. They skim. They notice that four of the documents cover the same three months. They read the most recent one carefully, glance at the others to check nothing contradicts it, and discard the rest.

That takes a few minutes and costs almost nothing. It's also completely unavailable to a model.

An agent given the same stack reads all of it, at equal attention, with no prior sense of which parts matter. This is the part that tends to surprise teams when they first put an agent on top of real clinical data. The record they've been working with for years, which their clinical users navigate without complaint, turns out to behave very differently as model input.

Redundancy Is Cheap for People and Expensive for Models

Clinical documents overlap heavily by design.

Every summary document generated for a patient tends to restate their current problems, their medication list, their allergies, and their recent history. That's sensible: each one has to stand alone, because whoever receives it might not have the others. So a patient with ten years of care across several providers accumulates documents that describe the same underlying facts again and again, in slightly different words, with slightly different dates attached.

A person reads that as one patient history with repetition. A model reads it as a large volume of text in which the same medication appears over and over, sometimes with an end date, sometimes without, sometimes under a brand name and sometimes generic, and has to work out whether those are one prescription or several before it can answer anything at all.

That reconciliation isn't free. It happens inside the same finite window the model needs for the actual question, and it happens every single time, because nothing about the reconciliation persists between requests.

Everything Arrives With Equal Weight

The second problem is that documents carry no relevance signal.

A clinician knows that the discharge summary from last month's admission matters more than a routine annual physical from 2019. That judgment comes from clinical training and from knowing why they're reading in the first place. The documents themselves don't encode it. They're just files, in whatever order the retrieval returned them.

So an agent asked a narrow question, what medications is this patient currently taking, has to process material that has nothing to do with the question in order to be confident it hasn't missed anything. The cost of answering a small question scales with the size of the entire record rather than with the size of the answer.

What Actually Helps

The true fix here is not the prompt, it's getting the data to look right.

Deduplicated and normalized. One medication list where a drug appears once, with its start date, its stop date, and its dose changes in sequence. Not twelve documents each asserting a version of it. The reconciliation still has to happen; it just happens once, on our side, rather than on every request on yours.

Discrete where it should be discrete. Conditions, medications, labs, allergies, and encounters as structured fields the agent can query directly, rather than as prose it has to extract. Asking for current medications should return a list, not a reading assignment.

Narrative available but separate. As we wrote a few weeks ago, the reasoning lives in the notes, and an agent frequently needs it. What it doesn't need is all of the notes, all the time. Attachments that are searchable and linked to the encounters they belong to let an agent go get the progress note behind a specific event when the question calls for it, and ignore the rest when it doesn't.

Having the unstructured data and being able to retrieve the right piece of it on demand are different capabilities, and only the second one is usable inside an agent loop.

What Failure Looks Like

Worth knowing what this looks like when it goes wrong, because it is rarely seen as a data problem.

The agent gives a confident answer that's built on an outdated version of the medication list, because it reconciled twelve overlapping documents and picked wrong. It contradicts itself across two sessions on the same patient. It performs well on the demo patient with a thin chart and degrades on the complex patient with fifteen years of history, which is the inverse of what you need. Or it simply runs out of room and returns something partial without indicating that it did.

Every one of those reads like a model problem. So teams respond by changing models, adjusting prompts, or adding retrieval layers. Sometimes that helps, but often the actual constraint was set much earlier, by what the data looked like when it came through the door.

The Part Worth Deciding Deliberately

For most of the history of health data integration, the format of what you received was a detail you worked around. You would get what the source gave you, you wrote transformation code, and the messiness was absorbed by your engineers once.

When an agent is the consumer, that messiness stops being absorbed once and starts being paid for on every single call, at the rate the model costs. The shape of your clinical data has quietly become an architecture decision rather than an integration detail.

We built our schema for that, which is to say we built it for developers and agents rather than for people who've memorized the specification. If you're putting a model between a patient's record and a decision, it's worth looking hard at what that model is actually being handed.

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

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