Key Takeaways
- Four connection paths exist for EHR data: direct FHIR API, a patient-mediated gateway, a network aggregator or QHIN and an integration engine.
- Our EHR integration timeline guide covers the first three in depth. This article is a quick-reference companion that adds the fourth path, which teams often confuse with an aggregator.
- Integration engines like Redox and network aggregators like Health Gorilla solve different problems, even though both get called middleware.
- An aggregator retrieves records from national networks. An integration engine wires a product into many EHRs for durable two-way workflows such as orders and notes write-back.
- The choice follows from two questions: who authenticates (patient or provider) and whether the product needs one-time record retrieval or ongoing two-way exchange.
Is Your HealthTech Product Built for Success in Digital Health?
.avif)
Most EHR connectivity conversations open with vendor choice and pricing. The shape of the project is decided earlier, by who authenticates. That is either 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 article is a fast comparison for teams who roughly know which path they need and want the tradeoffs side by side. It also covers the path most often confused with an aggregator, the integration engine.
The Four EHR Integration 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 and write-back with 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 (individual access also possible through 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 supports write-back into the EHR, which otherwise needs an integration engine. The tradeoff is that 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 that catalog, which spares the product team from building and maintaining a connection to each one. It is the fastest route to broad patient-facing coverage. Its limit is 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. In treatment mode there is no per-patient login step. It fits provider workflows that need broad retrieval without asking each patient to authenticate. It also carries the highest upfront commitment and the tightest limits on how the data can be reused afterward.
Where the Integration Engine Fits
The integration engine is the path most often folded into aggregator conversations, even though it solves a different problem. An engine like Redox connects a product into a large network of EHRs for ongoing, bidirectional workflows such as sending orders and writing notes back into the record. An aggregator retrieves records from the national networks in one direction. An integration engine keeps data moving both ways between two systems for as long as the workflow runs.
The economics and the scoping differ too. An aggregator engagement is sized around the volume of records retrieved. An integration engine engagement is sized around the durability of the workflow, meaning the number of connected organizations and the volume of two-way traffic. It also depends on how long the integration has to stay current as EHR vendors update their APIs.
Teams evaluating middleware often treat Redox and Health Gorilla as interchangeable options at different price points. Health Gorilla is a record-retrieval network, while Redox is a workflow integration platform. Mixing them up at the scoping stage is a common source of mismatched estimates later in the project.
Choosing an EHR Integration Path
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. Next, check whether the use case needs a one-time or recurring pull of records or an ongoing two-way workflow. A pull points toward one of the first three paths, depending on who authenticates. A two-way workflow points toward an integration engine. Direct FHIR also works there when only a few named vendors are involved.
If the product needs the free text inside records, clinical notes bring their own coverage gaps on every path. For timelines and cost drivers, the EHR integration timeline guide walks through the complete decision tree. This comparison sits alongside it as a fast reference once the direction is set.
Momentum scopes the connection path as the first step of any EHR integration engagement, matched against the product's authentication model and its data exchange pattern. For products that also pull data from consumer devices, the same scoping conversation usually covers wearables integration, since patient-facing health products increasingly need both streams working together.
.png)
