FHIR vs. Proprietary API: Why the Second EHR Integration Is Cheap and the First Proprietary One Isn't

Every EHR integration estimate runs into the same question early: how much of this scales, and how much is a one-off. The answer depends almost entirely on one fork in the decision tree covered in our guide to EHR integration: does the vendor speak FHIR, or does it expose a proprietary API.

That single distinction is the biggest cost multiplier in any direct integration. Two vendors that are both FHIR R4 compliant let you reuse most of what you built for the first one. Two proprietary vendors don't, even if they sit in the same clinical category. Teams that estimate EHR work as a flat per-vendor cost, without separating these two paths, tend to overshoot on FHIR and undershoot on proprietary systems in the same breath.

This piece walks through why FHIR compounds and proprietary APIs don't, what a predictable data floor actually looks like once you're connected, and where the real estimating risk sits even inside a fully FHIR-compliant integration.

Why the first FHIR integration is the investment

A direct FHIR integration means registering an app in a vendor's developer program, requesting sandbox credentials, and implementing SMART on FHIR, the OAuth 2.0 layer that sits on top of FHIR. A patient-facing app does a standalone patient launch: the patient logs in at their institution, consents to scopes, and the app receives a token. A provider-facing app typically uses a backend service, system-to-system, with client credentials instead of a patient in the loop.

None of that is trivial the first time. You're building the auth flow itself, the FHIR resource pull with pagination and token refresh, error handling for a vendor's specific quirks, and the mapping from FHIR resources into your own data model. That work has to happen once, in full, before any data moves.

Why the second FHIR vendor is a fraction of the first

Here's what changes on vendor number two. The OAuth dance is largely the same. The resource shapes are mostly the same, because USCDI, US Core Data for Interoperability, sets a baseline that certified EHRs have to expose under the Cures Act. The pipeline you built for parsing, mapping, and storing FHIR resources carries over almost entirely.

What's left is the vendor's own approval process, which runs on its own timeline regardless of how clean your code is. Connecting a second FHIR EHR doesn't double your integration timeline. It adds a fraction of the original engineering effort, plus whatever that vendor's developer program takes to clear. A third and fourth vendor follow the same pattern. This is the mechanism behind realistic EHR integration timelines: engineering effort flattens quickly across FHIR vendors, while approval time does not.

Why proprietary systems don't compound

Not every EHR speaks FHIR, and the systems that don't are usually the ones where FHIR carryover would matter most: behavioral health platforms, wound care systems, and older hospital and long-term care systems that predate the current interoperability push.

Each proprietary vendor has its own authentication scheme, its own data model, and its own set of quirks, with almost no reuse from the last one you built. Budget each proprietary connection as its own project, not as a variation on your FHIR work. This is the single most common estimating mistake we see in multi-EHR integration planning: treating a proprietary vendor as "one more EHR" when it's closer to starting over.

The category itself is also less stable than it looks. Long-term and post-acute care vendors like PointClickCare and MatrixCare were, until recently, treated as proprietary by default. Both now expose FHIR alongside proprietary APIs, and PointClickCare runs a self-service developer program. Assuming a vendor is proprietary because its category historically was is exactly the kind of shortcut that produces a bad estimate. Check each vendor directly before scoping the work.

What a FHIR-compliant vendor actually gives you

USCDI, and the US Core FHIR profiles built on top of it, define the floor of data a certified EHR has to expose: demographics, problems, medications, allergies, labs, and clinical notes among them. That floor is genuinely useful. It means you're not negotiating, vendor by vendor, over whether basic clinical data is available at all.

What USCDI doesn't guarantee is that two vendors hand you the same concept in the same shape. Two FHIR R4-compliant EHRs can both expose a patient's medication list and still differ in which extensions they use, which code systems they reference, and how complete the data actually is in practice. Reconciling those differences against your own data model is where a clean per-vendor estimate turns into a real one. Skipping that reconciliation step is a common source of late-stage surprises in FHIR and HL7 interoperability projects that looked simple on paper.

Clinical notes are the part that resists standardization

Structured fields, the ones covered by USCDI, are the predictable part of an integration. Clinical notes are not. They typically arrive through the DocumentReference and Binary FHIR resources, inline as base64-encoded PDF, text, or HTML, within the scope of whatever the patient or provider consented to.

What you won't get automatically: a guarantee that every note the patient sees in their own portal is exposed over the API, or documents referenced by external URLs that sit outside the record you pulled. Completeness varies meaningfully by source. If a use case depends on notes specifically, and especially if it needs de-identified notes for a downstream use, that's a distinct workstream to scope early rather than discover mid-build.

The practical strategy: FHIR-first, proprietary as a separate line item

Given how differently these two paths scale, the estimating approach that holds up in practice is FHIR-first. Standardize on FHIR wherever a vendor supports it, treat every proprietary connection as its own scoped project, and plan explicitly for the data-reconciliation work between FHIR vendors rather than assuming it away.

This is also why direct integration isn't the only path worth considering. For patient-facing products that need broad coverage across many systems quickly, a patient-mediated gateway can absorb the per-vendor connection work entirely, at the cost of depending on what that gateway's catalog already covers. For provider-facing products with deep, ongoing bidirectional workflows, an integration engine solves a different problem than either direct FHIR or a gateway. Caily connected patients to their own records across seven major EHR systems in roughly two months, a timeline that reflects exactly this kind of path decision made early rather than worked around later.

Momentum's EHR integration work has supported healthcare integrations serving 1M+ patients, spanning FHIR, HL7, CDA, and direct vendor APIs. If you're scoping a new integration and aren't yet sure which vendors on your list are FHIR-compliant and which aren't, that's the first question worth answering before any estimate gets written down.