What our side-by-side study revealed about where HIE data helps, where it falls short, and why normalization is the missing part of the discussion.

Health Information Exchange data has become one of the most important infrastructure layers in healthcare interoperability. For organizations trying to understand a patient's history, support clinical review, prepare charts, close care gaps, or accelerate intake workflows, HIEs can provide something incredibly valuable: fast access to records that might otherwise take days or weeks to retrieve manually.

But HIE data is often misunderstood.

Providers can share countless examples of where HIEs failed to produce the health record information they needed, but their responses are anecdotal. One cardiologist we spoke with estimated that even with Care Everywhere, in 50%-60% cases, MAs and office staff were still left to chase records that weren't available on the exchange.

Given this sentiment is continually echoed by physicians, we set out to form a stronger opinion around where HIE data might be sufficient, and where it is more limited.

We started with a 30-patient sample spanning multiple specialties to compare HIE results against traditional manual record retrieval.

The highlights: HIE data provided meaningful early visibility, but it did not consistently deliver the complete patient record to support clinical decision making.

• In only 20% of cases, HIE-only retrieval was sufficient
• In 17% of cases, HIE data was partially useful but manual follow-up was still required to complete the records.
• In nearly 50% of cases, no meaningful digital data was available
• In 13% of cases, data was technically available but not clinically useful because it was fragmented, incomplete, or created additional review burden.

That does not mean HIE data failed. It means HIE data did what HIE data is best suited to do: accelerate the start of the workflow, surface available history quickly, and help teams understand where to focus next.

What HIE Data Is Good At

HIE data is strongest when the goal is fast, directional visibility.

Most providers have intra-network sharing capabilities enabled by their EHR (think: Care Everywhere). Many have also contracted with an API-based point solution to return additional data available on digital exchanges. The result is that HIEs can return useful information quickly. In operational terms, that makes HIE data valuable for intake, triage, encounter mapping, and identifying which parts of a patient's history may require deeper manual retrieval.

This is based on several observations:

• Larger hospital systems were more likely to have extensive records available digitally
• Labs were the strongest-performing data category.

That makes intuitive sense: large systems often have more mature interoperability infrastructure, and lab data is more likely to be structured, discrete, and routinely exchanged.

This is where HIE data can create immediate operational leverage. It can help answer questions like:

• Is there any recent hospital activity?
• Are there labs, medications, imaging reports, or diagnoses that provide a useful clinical starting point?
• Which providers or facilities appear in the patient's history?
• Which parts of the record might already be available digitally, and which gaps need to be filled manually?

That kind of early visibility matters. In clinical operations, the first useful record often determines how quickly a case can move from intake to review. HIE data can shorten that path.

Where HIE Data Falls Short

The biggest limitation of HIE data is completeness.

HIE networks are broad, but they are not magic. In large part, this is because they depend on the participation of providers. Data is only available if the provider participates, the provider's EHR pushes data into the network, the patient can be matched accurately, and the records are actually resulted and available at the time of query. Gaps in HIE data usually reflect gaps in provider participation, what they choose to contribute, matching, or timing, and not necessarily the inability to access a record. Oftentimes when a record is not accessible through HIEs it's because it's not there.

This is the most important takeaway: because there is discretion around what is shared in the first place, and there are a variety of reasons data may not be associated with a patient's profile, HIE access is not the same as complete longitudinal record retrieval.

Several observations around where HIEs were limited:

• Smaller, private practices were significantly less likely to have findable digital data
• Provider notes were some of the least likely categories of medical data to appear, and when they appeared, they were often fragmented or broken into discrete components rather than delivered as a complete, review-ready note set.
• Certain EHRs also appeared to have limited HIE availability in the sample

This matters most in high-stakes clinical workflows, and outcomes-based care models Care navigation, virtual health monitoring, 2nd opinion services, complex specialty practices (surgery, oncology, nephrology, GI), and imaging-heavy workflows often depend on very specific documents: office visit notes, operative reports, pathology reports, complete imaging reports, DICOM images, growth charts, color photos, specialty notes, full lab values, ADT alerts, and longitudinal provider documentation.

Those are exactly the kinds of records HIE data may not reliably return.

One particular case portrays this well: for a Urology case, HIE returned some useful labs, urine studies, and imaging reports, but critical office visit notes, ultrasound reports, and DICOM imaging still required manual follow-up in order to have a full, clinically-relevant picture. Even more importantly, it was impossible to confirm whether the lab and urine study sets were complete without office-level validation.

That is one of the most underappreciated limitations of HIE data: partial data can be useful, but it can also create a false sense of completeness. You don't know what you don't know about what's missing.

A clinical team may see several labs and assume they are looking at the full lab history. They may see one imaging report and assume the imaging record is complete. They may see a note fragment and assume the provider documentation is covered. But unless someone validates against the source, there is often no reliable way to know whether the HIE returned everything that exists.

Timing Is the Hidden Variable

Coverage is not the only issue. Timing matters just as much.

An HIE query is a snapshot. It tells you what was available through the network at the moment the query was run. It does not necessarily tell you what happened clinically, what is pending, what is sitting in an EHR but not yet shared, or what will become available tomorrow.

This exercise contained a great example of this. In one case, HIE data successfully returned relevant imaging and pathology-related records from a participating health system. On the surface, this looked like a strong HIE success story. But the pathology report had not been finalized at the time of the initial request. It became available roughly two weeks later, meaning a query at the original point in time would not have returned the final pathology report. A subsequent HIE query, or manual follow-up, was required to capture the completed result.

This is the nuance many organizations miss. A missing HIE record can mean several different things:

• The provider does not participate.
• The EHR does not push that record type.
• The record exists but has not been finalized.
• The result is pending.
• The data was not available at the time of query.
• The patient match did not surface the right record.
• The document exists, but not in a form that is usable for the workflow.

Operationally, this means HIE retrieval should not be treated as a one-time event in every case. For workflows involving pathology, radiology, recent procedures, hospital discharges, or specialist consults, timing-aware retrieval matters. A record that is unavailable today may be available in two days, one week, or two weeks. Without a process for re-querying, monitoring, or manually following up, teams risk closing the loop too early.

The right mental model is not "HIE found it" versus "HIE did not find it." The better model is "What is available now, what is still pending, and what needs to be validated or retrieved through another path?"

HIE Data Can Be Available and Still Not Be Usable

Even when HIE data exists, it often arrives messy.

Raw HIE data is not automatically a clean longitudinal patient record. It can include duplicate documents, re-submitted records, inconsistent naming, inconsistent semantics, unformatted data, and fragmented source outputs. These raw outputs are difficult for BI tools, AI applications, and EHRs to consume without normalization.

This is why "access to HIE data" and "usable clinical data" are not the same thing.

In one direct comparison case, the HIE returned more than 800 pages of material, but the records still required significant review. Across the sample set, the average volume of HIE data received per patient was 1,070 pages. That kind of volume can be valuable, but without curation it can also overwhelm clinical teams and create a new bottleneck: chart review. Take Hemoglobin, for example. It might appear in a lab value as Hgb, a provider note as Hb, and elsewhere as Hemoglobin. This semantic difference makes it more complicated to query or trend data, even when it is technically available.

This is where the data curation layer becomes essential.

The real opportunity is not just retrieving HIE data. It is turning raw, fragmented, duplicated, inconsistently formatted data into something clinicians, operations teams, analytics teams, and AI systems can actually use.

In practical terms, that means converting messy HIE outputs into organized categories such as problems, medications, labs, allergies, procedures, notes, providers, vaccinations, pathology results, vitals, family history, and social history. It also means delivering the data in formats that match different workflows: structured JSON or API outputs for technical teams, indexed PDFs for clinical teams, and parquet files for analytics or data warehouses.

That is the difference between data retrieval and data usability.

The bottom line

HIE data is not the finish line. It is the starting signal.

It can tell you what is available now, surface useful clinical context quickly, and help teams move faster. But it cannot guarantee that every provider participated, every result was finalized, every note was shared, or every critical document made it into the exchange.

When you have access to HIE data it is valuable, but raw HIE data is not enough to really advance more streamlined clinical care. Without normalization, deduplication, clinical classification, and targeted manual follow-up where needed, HIE data can simply move the bottleneck from record retrieval to record interpretation.

When it comes to HIE access, the winners are not the organizations that pull the most data. They will be the organizations that piece together a complete patient history and standardize that data, so it is usable. That is how HIE data becomes operationally useful, clinically trustworthy, and ready for the next generation of healthcare workflows.