Key Takeaways
- Four distinct connection paths exist for EHR data: direct FHIR API, a patient-mediated gateway, a network aggregator or QHIN, and an integration engine.
- The first three are covered in depth in our EHR integration timeline guide. This piece is a quick-reference companion, not a replacement, and adds the fourth path most teams conflate with an aggregator.
- Integration engines like Redox and network aggregators like Health Gorilla solve different problems, even though they get lumped together as middleware.
- An aggregator retrieves records from national networks. An integration engine wires a product into many EHRs for durable, bidirectional workflows: orders, results, and notes write-back.
- The choice is not really about the technology. It follows from who authenticates, patient or provider, and whether the product needs one-time record retrieval or ongoing two-way data exchange.
Is Your HealthTech Product Built for Success in Digital Health?
.avif)
Most EHR connectivity conversations start in the wrong place: which vendor, which standard, which pricing model. The question that actually determines the shape of the project is simpler. Who authenticates, the patient connecting their own records, or a provider organization connecting on behalf of its care delivery workflow. Our EHR integration timeline guide covers that fork in depth, along with three of the four ways teams reach clinical data once the answer is clear.
This piece exists as a fast comparison for teams who already know roughly which path they need and want the tradeoffs side by side, plus the one path that gets confused with an aggregator more often than any other: the integration engine.
The Four Paths, Side by Side
Direct FHIR API. Patient or provider facing. Per-vendor build required. Medium speed, gated by vendor approval. Best for full control, write-back, specific vendors.
Patient-mediated gateway. Patient facing. No per-vendor build, one API. Fastest path. Best for broad patient-facing coverage.
Network aggregator or QHIN. Provider facing, or IAS via a QHIN. No per-vendor build, network access. Slowest to stand up. Best for provider record retrieval inside care.
Integration engine. Provider facing. No per-vendor build, one platform integration. Medium speed. Best for bidirectional workflows across many EHRs.
A direct FHIR integration means registering with each vendor's developer program individually, following the same SMART-on-FHIR authorization flow each time. It gives the most control and is the only path that supports write-back into the EHR for most vendors, but every system is its own onboarding process on its own timeline.
A patient-mediated gateway, the model behind Fasten Health, puts one API in front of a large catalog of health systems. The patient picks their provider from the gateway's catalog rather than the product team building and maintaining a connection to each one. It is the fastest route to broad patient-facing coverage, at the cost of being limited to whatever each source system exposes through its own patient-access API.
A network aggregator or QHIN, the model behind Health Gorilla and Particle Health, pulls records through national networks like Carequality and CommonWell under a treatment purpose, with no per-patient login step. It fits provider workflows that need broad retrieval without asking each patient to authenticate, but it carries the highest upfront commitment and the tightest constraint on how the data can be reused afterward.
Where the Integration Engine Actually Fits
This is the path most often folded into "aggregator" conversations, and it solves a different problem entirely. An integration engine like Redox connects a product into a large network of EHRs for ongoing, bidirectional workflows: sending orders, receiving results, writing notes back into the record. An aggregator retrieves records from the national networks in one direction. An integration engine wires two systems together so data keeps moving in both directions as long as the workflow runs.
The distinction matters because the economics and the scoping differ. An aggregator engagement is sized around the volume of records retrieved. An integration engine engagement is sized around the durability of the workflow: how many organizations connect through it, how much bidirectional traffic it carries, and how long the integration needs to stay live and current as EHR vendors update their own APIs.
Teams evaluating "middleware" as a category often assume Redox and Health Gorilla are interchangeable options solving the same problem at different price points. They are not. One is a record-retrieval network. The other is a workflow integration platform. Getting that distinction wrong at the scoping stage is a common source of mismatched estimates later in the project.
How to Use This Table
Start with the authentication question: does the patient connect their own records, or does a provider organization connect on the product's behalf. That answer rules out at least two of the four paths immediately. From there, the deciding factor is usually whether the use case needs a one-time or recurring pull of records, or an ongoing, two-way workflow. The first points toward direct FHIR, a gateway, or an aggregator, depending on who authenticates. The second points toward an integration engine, regardless of who authenticates, because that is the only path built for durable bidirectional exchange.
For the full breakdown of timeline, cost drivers, and how clinical notes factor into each path, the EHR integration timeline guide walks through the complete decision tree. This comparison is meant to sit alongside it as a fast reference once the direction is roughly set.
Momentum scopes the connection path as the first step of any EHR integration engagement, matched against the product's authentication model and whether the workflow needs one-time retrieval or ongoing exchange. For products that also pull data from consumer devices, the same scoping conversation usually extends to wearables integration, since patient-facing health products increasingly need both streams working together.
.png)
.png)
