Particle Health vs Health Gorilla vs Redox vs 1upHealth vs Direct EHR Integration: Which Path Fits Your Product (2026)

Particle Health and Health Gorilla are network aggregators: they query national exchange networks such as Carequality, CommonWell and eHealth Exchange for a patient's records held by providers you have no connection with. Redox is an integration platform that runs your connections to specific health systems, 1upHealth is a data platform built for health plans, and direct integration means connecting to Epic, Oracle Health or athenahealth APIs yourself. The right choice depends on one question: do you need outside history, or do you need to work inside a clinician's workflow?

This guide compares all five paths using only what each company publishes in its own documentation, explains what aggregators structurally cannot do, and ends with a decision table and checklist. We build direct EHR integration and hybrid architectures, so we will also say plainly when an aggregator is the better buy.

Key takeaways

• Network aggregators (Particle Health, Health Gorilla) are the quickest route to outside records, mostly as C-CDA documents or data derived from them, gated by a permitted purpose such as Treatment.
• Integration platforms (Redox) connect you to a named health system's EHR, including write-back, but each site still has to agree and configure the connection.
• 1upHealth now positions itself for health plans, and its patient-authorized 1up Patient Connect product sunsets on September 30, 2026.
• Direct EHR APIs give you full control of SMART launch, EHR-specific data such as scheduling and flowsheets, and per-site configuration.
• TEFCA: Health Gorilla is a Designated QHIN. Particle Health takes part through CommonWell, also a Designated QHIN.
• Many products end up hybrid: an aggregator for history, direct APIs for workflow, one identity layer between them.

What are the three ways to get EHR data into your product?

There are three integration models. A network aggregator queries nationwide exchange networks for a patient's records. An integration platform maintains interfaces to the specific health systems you contract with. A direct EHR integration connects your code to each EHR vendor's own APIs. They differ in breadth, depth, freshness, and who must say yes before data flows.

Network aggregators

Particle's network documentation describes Carequality as a framework in which participants query each other as nodes, and CommonWell as a hub that members submit requests to. An aggregator signs those network agreements once, runs patient discovery and document retrieval across them, and returns results through a REST API. You get breadth. You give up control over what each responder returns and when.

TEFCA now sits across these networks. The ONC TEFCA page describes QHINs as a "network-of-networks" and lists Common Agreement version 2.1, published February 2025. The RCE's Designated QHIN list names CommonWell Health Alliance, eClinicalWorks (PrismaNet), eHealth Exchange, Epic Nexus, Health Gorilla, Kno2, Konza Health, MedAllies, Netsmart, Oracle Health Information Network and Surescripts Health Information Network. TEFCA defines six exchange purposes: Treatment, Payment, Health Care Operations, Public Health, Government Benefits Determination and Individual Access Services.

Integration platforms

An integration platform sits between your app and each health system. It owns the transport (HL7v2, FHIR, vendor APIs) behind one API, but every new site is still a project the health system must approve and staff.

Particle Health vs Health Gorilla vs Redox vs 1upHealth: side-by-side comparison

In short: Particle Health and Health Gorilla sell network access, Redox sells managed connections to the health systems you name, 1upHealth sells FHIR infrastructure to payers, and a direct integration trades vendor help for full control. This comparison uses only each vendor's public documentation as reviewed in September 2026.

Vendors change products and terms often. Confirm current capabilities, supported purposes of use and commercial terms with each vendor before you commit, and ask how any published coverage figures are counted.

What is Particle Health and how does it work?

Particle Health is a network aggregator. Its developer documentation describes a single API that "connects to all three nationwide health information networks" and names CommonWell as its QHIN for TEFCA. You register a patient, submit a query with a purpose of use, and retrieve records as C-CDA, FHIR or flattened datasets.

Beyond the national networks, Particle lists state HIEs Healthix (New York) and Manifest MedEx (California). In November 2024 Particle announced it would join the CommonWell QHIN while keeping its existing connections. The recommended flow in the Deltas API docs, paraphrased and trimmed (check the docs for exact paths and headers):

1. Create the patient with the Patients API          -> particle_patient_id
2. POST https://api.particlehealth.com/deltas         (patient ID, purpose of use, specialties)
3. GET  https://api.particlehealth.com/deltas/{particle_patient_id}
       202 = still querying networks, 200 = complete (or use a webhook)
4. GET  FHIR or FLAT endpoints with _since=...        (net new data only)

Two details shape your architecture. The _since filter is based on when Particle last queried the networks, not on clinical dates, so "new" data can describe an old encounter. And per Particle's C-CDA vs FHIR guide, FHIR output is converted from retrieved C-CDA documents. Particle says C-CDA queries finish faster (roughly 80% complete in 3 minutes, against 5 minutes for FHIR).

Particle Signal monitors enrolled patients and sends admit, discharge, transfer, discharge summary and new encounter alerts by webhook.

On purposes of use, Treatment is widely supported, Payment and Operations are not supported on every network, and Individual Access requires patient consent plus identity verification. The bi-directionality policy is what teams underestimate: if you query under Treatment, you must make your records available, post net new data within one month, and respond to TEFCA Treatment and Individual Access Services queries, or Particle may suspend query access. You contribute by uploading documents to Particle's master patient index. That is contribution to the network, not write-back into a provider's EHR.

What is Health Gorilla and what does being a QHIN change?

Health Gorilla describes itself as the first organization dual-designated as a TEFCA QHIN and a California Qualified Health Information Organization. Its QHIN page says HHS recognized it on February 13, 2023. Its Patient360 API offers access to clinical data across national networks "through a single FHIR-based interface."

Its network participation docs list TEFCA, Carequality, CommonWell and eHealth Exchange. As a QHIN it exchanges with other QHINs directly under the Common Agreement.

Retrieval is asynchronous. After creating or matching a patient, you call the operation from the Patient360 process guide:

GET /fhir/R4/DocumentReference/$p360-retrieve?patient={hg_patient_id}

Health Gorilla then retrieves and deduplicates documents, stores the originals as DocumentReference resources, extracts clinical data into FHIR resources, and reconciles duplicates. Its docs warn that documents "may arrive at different times depending on network response and retrieval latency." Network-specific operations ($cq-search, $cw-search, $ehex-search) return DocumentReference entries pointing to Binary content, and scopes are limited to those approved at onboarding.

The differentiator is breadth beyond records. Its lab network takes orders as FHIR RequestGroup and ServiceRequest and returns DiagnosticReport and Observation results. Its QHIN page lists Treatment and Individual Access Services as required first, with other purposes to follow. Confirm which are live for your use case today.

What is Redox and how is it different from an aggregator?

Redox is an integration platform, not a record locator. It connects your application to the specific health systems, payers and partners you work with. Its data exchange docs type traffic as notifications from the connection, synchronous queries, and asynchronous write-backs into the connection's system.

The supported methods page lists HL7v2, FHIR, C-CDA, X12 and DICOM, IHE profiles such as XCPD and XCA, and connections including Epic, Cerner, athenahealth, eClinicalWorks and NextGen. Write-back is first class: its results and vitals guide documents Observation$observation-create and DiagnosticReport$diagnosticreport-create. Redox also supports launching your app inside an EHR when the connection has its own FHIR API.

What Redox does not remove is the health system. Its guide to planning with your connection asks you to confirm "whether your connection needs to purchase, set up, or reuse any interfaces," agree mappings and review workflows. Its Carequality onramp and TEFCA via CommonWell onramp are documented for the Treatment purpose of use.

What does 1upHealth do in 2026?

1upHealth describes itself as a solutions provider "for health plans." Its 1up Platform is FHIR-first, with products mapped to CMS payer requirements: Patient Access, Provider Access, Payer-to-Payer, Provider Directory, Formulary and electronic prior authorization. It fits payers and companies selling into payers.

Two changes matter. On September 1, 2026, 1upHealth launched 1up Clinical Connect, which pulls USCDI clinical data from provider EHRs, including Epic and athenahealth, through FHIR APIs for health plans. And its documentation says 1up Patient Connect, its patient-authorized connection product, is discontinued with a sunset date of September 30, 2026. The pages we reviewed do not describe network query or EHR write-back. For the payer side, see our guide to payer and provider data exchange under the CMS FHIR APIs.

What is direct EHR integration?

Direct EHR integration means your application uses the EHR vendor's own interfaces: FHIR R4 APIs on US Core, SMART on FHIR authorization, bulk FHIR for populations, vendor APIs, and HL7v2 feeds for events. You register once per vendor but activate customer by customer, and each site's configuration decides what you actually get. Our EHR integration API comparison across Epic, Oracle Health, athenahealth and eClinicalWorks maps the vendor differences.

Epic's Epic on FHIR documentation describes production and non-production client IDs, the customer signing the open.epic API Subscription Agreement, and the customer downloading your app by client ID. For filing device readings it offers an HL7v2 inbound flowsheet interface or a patient-authorized Observation.Create API, and both need the customer to map flowsheet row IDs. No aggregator can do that per-site work for you. See how to get your app into Epic, and the USCDI vs US Core version mapping for which data elements certified APIs must expose.

What can't a health data aggregator do?

A network aggregator retrieves what other organizations share, as documents or data derived from them, for purposes the networks allow. It does not put your app inside a clinician's EHR, does not write into the treating provider's chart, and does not see EHR-internal data that never lands in an exchanged document. Five gaps come up repeatedly.

• Workflow embedding. An aggregator has no presence in the EHR interface, so it cannot place your app in the chart, in-basket or schedule.
• SMART launch. Under SMART App Launch 2.2, the EHR opens your app and passes iss (its FHIR endpoint) and an opaque launch context. That handshake exists only between your app and the EHR, directly or through a platform that proxies it.
• Write-back. Contributing a C-CDA to a network makes it discoverable. It does not file a note, flowsheet value or order into your customer's EHR.
• EHR-specific data. Appointment slots, flowsheet rows, in-progress orders and worklists rarely appear in exchanged documents. Our guide to bulk FHIR export across Epic, Oracle Health and athenahealth covers the population side.
• Per-site configuration. Aggregators normalize what comes back; they cannot change what a site exposes or how it maps note types and flowsheets.

This is not a criticism. Aggregators were designed for record location across organizations, with a reach no single integration matches. The mistake is buying one to solve a workflow problem, the read-only trap we described in the FHIR write problem for AI agents.

How fresh is the data from each integration path?

Freshness runs from point-in-time documents to live events. A network query returns what each responder had on file when asked. Bulk FHIR export is a scheduled snapshot. A FHIR REST read is current at the moment of the call. Network ADT alerts and HL7v2 feeds push events as they happen, and only they tell you something changed.

A network C-CDA is a summary generated by the responding system, often scoped to one encounter, so "latest" depends on what that system includes. Design for a record that fills in over minutes, not a single response. For event pipelines, see real-time ADT event processing with HL7.

When does direct EHR integration win?

Direct EHR integration wins when your product must act inside a clinician's workflow, write structured data into the chart, or use EHR-specific data at a manageable number of EHR vendors. It also wins when a health system sponsors you and wants no extra third party in the data path.

An aggregator is the better buy when you need history from providers you have no relationship with, qualify for a supported purpose, and can work from documents that arrive asynchronously. An integration platform is the better buy when you need workflow at many EHRs quickly without an interface team. We say this even though direct builds are our business.

Weighing an aggregator against a direct build? We build direct EHR integrations and hybrid architectures across Epic, Oracle Health, athenahealth, eClinicalWorks and NextGen. Talk to our team and we will map what your target EHRs and networks actually expose for your use case before you sign a vendor contract.

What does a hybrid aggregator plus direct EHR architecture look like?

A hybrid uses a network aggregator for outside history, direct EHR APIs or an integration platform for workflow and write-back, and optionally HL7v2 feeds for events. The hard part is not any single connection. It is the shared identity, reconciliation and provenance layer that lets one patient record combine all three sources without duplicates.

An illustrative source-routing sketch in our own shorthand, not any vendor's format:

# illustrative source routing for a hybrid EHR data layer
sources:
  outside_history:
    via: network_aggregator          # Particle Health or Health Gorilla
    purpose_of_use: TREATMENT
    mode: async_query_then_deltas
    output: [ccda_documents, fhir_derived]
  chart_context:
    via: direct_ehr_fhir             # Epic, Oracle Health, athenahealth
    auth: smart_ehr_launch
    reads: [Patient, Encounter, Condition, MedicationRequest, Observation]
    writes: [DocumentReference, Observation]
  events:
    via: hl7v2_interface             # ADT and results from the site
    messages: [ADT^A01, ADT^A03, ORU^R01]
reconciliation:
  identity: enterprise_mpi           # link aggregator IDs to EHR patient IDs
  provenance: keep_source_system_and_retrieved_at

Three rules keep hybrids sane. Keep provenance on every fact. Never write outside data into the EHR without clinical review. Resolve identity first, linking the aggregator's patient ID, the EHR's FHIR Patient ID and your own. For the event leg we run Mirth Connect engines in production. See patient matching beyond demographics, one integration layer across Epic, Oracle Health and athenahealth, and when you need both HL7 and FHIR.

Which integration path fits your product type?

Product type predicts the answer better than feature lists. AI scribes and scheduling agents live inside the EHR workflow and need direct APIs or a platform. Care coordination and risk adjustment need outside history, which is aggregator territory. Monitoring products need write-back. Trial matching starts with outside history, then needs site EHR access.

For AI scribes, note filing matters more than any vendor list; see our ambient clinical documentation engineering guide. For remote patient monitoring, flowsheet mapping at each site is usually the long pole whichever path you choose.

What does onboarding look like for each model?

Onboarding differs in who has to say yes. With an aggregator, the vendor vets your purpose of use and you accept network obligations. With a platform, each health system agrees and configures an interface. With direct integration, each customer sponsors, reviews and activates your app.

Our CTO framework for evaluating interoperability vendors has the scoring questions to bring to those vendor calls.

Where teams get stuck with aggregators and direct EHR integration

Most stalled integrations do not fail on the API. They stall on eligibility, identity, duplicates, contracts and timing. These are the five failure modes we design around when scoping a project, and what each tends to cost.

Purpose-of-use rejections

Networks trust queries based on declared purpose. Redox's Carequality docs say Treatment queries require being a Principal or holding a validated Delegate Attestation from one, and misrepresenting purpose can mean suspension. A company that does not deliver care, or a payer wanting Payment data, can find its use case unsupported after signing. The cost is a roadmap built on data you cannot query. Settle eligibility in writing before engineering starts.

Document dedupe and reconciliation

The same medication list arrives in a discharge summary, a primary care CCD and a specialist's encounter summary. Aggregators deduplicate, but reconciling against your data and the EHR's live data is still your job. The cost is clinician trust, plus post-launch sprints spent writing matching rules.

Patient matching across networks

Network queries match on demographics. A changed address or missing phone number means no match or the wrong patient, and Health Gorilla's docs note incomplete data may reduce match rates. The cost is silent gaps that look like "no outside records" and rarely appear in synthetic-patient testing.

Contract chains

Data can pass through you, your aggregator, its QHIN, another QHIN and a responding provider, each with its own terms. Customer security reviews will ask for every subprocessor in the PHI path and the HIPAA business associate chain behind it. The cost is procurement delay that lands after the build is done.

Latency and completeness

Network retrieval is asynchronous and responders reply at different speeds. A scribe or scheduling experience that waits on a network query feels broken. The cost is redesigning around background jobs and "records still arriving" states, so decide early which features can wait.

Decision checklist: aggregator, integration platform or direct EHR integration

Work through these ten steps before signing with any vendor. The answers usually make the choice obvious.

1. List the data elements and actions your product needs, split into read, write and launch.
2. Mark each as outside history (other organizations) or chart data (your customer's EHR).
3. Name your permitted purpose of use for every network query and get written confirmation it is supported for your organization type.
4. Check reciprocity: what you must contribute back, in which format, and how fast.
5. Rank target EHR vendors by customer count. If two or three dominate, price a direct build.
6. Decide whether you need SMART launch in the chart. If yes, an aggregator alone will not work.
7. Set a latency budget per feature and mark which can tolerate asynchronous retrieval.
8. Design identity, reconciliation and provenance before choosing vendors.
9. Map the contract chain and every subprocessor in the PHI path, and check roadmaps for sunsets such as 1up Patient Connect.
10. Confirm current terms, coverage methodology and pricing directly with each vendor.

If you are choosing between a network aggregator, an integration platform and a direct build, we can help you scope it honestly, including telling you when an aggregator is the right answer. Explore our healthcare interoperability services and our custom healthcare software development team, which builds direct Epic, Oracle Health and athenahealth integrations and hybrid architectures. Talk to our team to get started.