The Structured Data Tells You What Happened. The Notes Tell You Why
Date Published
Sep 15, 2026
Written by
Consolidate Health
Time to Read
4 min

Say you pull a patient's record and it comes back clean. Conditions, medications with dates, labs with values and reference ranges, allergies, encounters. Properly structured, nicely normalized, everything where you'd expect it.
It can look complete and still be missing the part you needed.
Recently we wrote about the two ways to retrieve a record and what each returns. This is the other axis, and it applies even when you've done everything right. Within any single EHR, clinical information is split between discrete data elements and free text, and a great deal of what actually explains a patient's care sits on the free text side.
What Discrete Data Is Good At
Structured clinical resources are genuinely excellent at a specific job: recording that something is true.
This patient has type 2 diabetes. This medication was started on this date at this dose. This lab value was 6.8 with a reference range of 4.0 to 5.6. This allergy exists. This encounter occurred on this date with this provider.
All of that is machine-readable, unambiguous, and easy to reason about. If you want to know whether a patient is currently on a statin, discrete data answers that cleanly, and no amount of narrative text answers it better.
The limitation is that discrete fields record conclusions. They don't record how anyone arrived at them.
What Gets Left Out
Four categories, roughly, and they come up constantly.
Why something stopped. A medication list shows a drug with a start date and an end date. It doesn't say whether the patient had a reaction, whether it wasn't working, whether they couldn't afford it, or whether the physician swapped it for something in the same class. Those are four completely different clinical facts that produce an identical structured record.
What was ruled out. A visit that ends in a diagnosis of gastritis often involved considering several other possibilities first, and the reasoning behind eliminating them is usually the most clinically valuable thing in the encounter. The coded diagnosis captures the destination and discards the route.
Instructions that aren't orders. A physician tells a patient to walk thirty minutes a day, to come back in six weeks if symptoms persist, to take a supplement at a specific dose, to stop drinking. None of those generate a discrete record in most systems. They're free text, and they're frequently the entire point of the visit.
The narrative read. A radiology study appears in structured data as a procedure that happened. The radiologist's impression, the incidental finding worth watching, the comparison to a prior study, all of that lives in the report itself.
Where That Information Actually Lives
Progress notes, encounter notes, consultation notes, imaging and radiology reports, pathology reports, operative and procedure notes, discharge summaries, referral letters back to the referring physician.
They come out of EHRs as attachments, typically HTML, PDF, or plain text, and they're retrievable through the same standardized APIs that return the discrete resources. But they're a separate ask. A retrieval implementation that requests the structured resources and stops there gets a real record, correctly formed, missing its reasoning.
Worth being honest about the variability here too. What's available differs by system and by how a given organization has configured things, and some note types are held back more often than others. The gap between implementations that pull attachments and implementations that don't is still the largest single difference in what a product ends up holding.
Why This Is Getting More Important, Not Less
For a long time this gap was tolerable, because the consumer of the data was a person.
A clinician looking at a thin summary knows it's thin. They can tell that a medication stopping in March without explanation is a question rather than an answer, and they can pick up the phone, request the full chart, or ask the patient directly. Human readers bring their own suspicion.
A model doesn't do that unprompted. Give it a structured record showing a drug started and stopped, and it will reason from what's in front of it. It has no way to know that the reason the drug stopped was an allergic reaction documented in a progress note that was never retrieved. It won't flag the absence, because the absence doesn't appear in the data.
This is the uncomfortable property of incomplete clinical data. It doesn't announce itself. A record missing its narrative layer looks exactly like a record that never had one, and a patient with a sparse history looks exactly like a patient whose history wasn't fully retrieved.
As more products put agents between the record and the decision, that distinction stops being academic.
What We Do About It
When we retrieve directly from an EHR, we pull the discrete resources and the attachments together, as one operation. Progress notes, imaging reports, procedure notes, discharge summaries, whatever the source system exposes.
Then we make them usable rather than just present. The attachments come through alongside the structured data and are searchable, so an application or an agent can go find the note behind a given encounter instead of receiving a pile of documents with no relationship to anything.
That's the part worth designing for. Having the notes and being able to locate the right one at the moment a question comes up are different capabilities, and only the second one changes what your product can do.
The Question to Ask
If you're evaluating a data source, discrete coverage is the easy thing to check and the easy thing to demo. Everyone's structured medication list looks fine in a sandbox.
The harder question is what happens to the reasoning. Does the narrative layer come through at all? Can you get from a structured entry to the note that explains it? And if it isn't there, does anything tell you, or does the record simply arrive looking complete?
Most of the time nothing tells you. That's the failure mode worth planning around, because by the time it matters, the data is already in your product and something has already made a decision with it.
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.

