EHR Integration Timeline: What Actually Sets the Clock

Every founder and VP of Engineering scoping an EHR integration opens with the same question: how long does this actually take. It is a fair question, and the honest answer is that the number is mostly set before anyone writes code, by decisions that rarely make it onto the first call.

Two teams can both say "we need EHR data" and be months apart on delivery. One is connecting a patient-facing app where each user authorizes access to their own records. The other is integrating on behalf of provider organizations, vendor by vendor, each with its own approval process. Same sentence, different projects.

This article gives you the map instead of a single number. It walks through the three ways teams actually reach clinical data, the two forks that decide which one fits, and where the time really goes. It is written from EHR work Momentum has delivered, including Caily, a patient-facing platform architected to connect users to their records across seven major EHR systems, and clinical-trial and consumer products that needed live records from thousands of providers at once.

If your team already has deep FHIR and HL7 expertise in-house, some of this compresses. If you are still weighing custom development against an off-the-shelf EHR, that decision comes first and this map comes after it.

Everything below assumes the US interoperability landscape (FHIR vendors, TEFCA, and the national exchanges). Other markets, such as national health-record systems abroad, follow different rules.

The First Fork: Who Authenticates, and Under What Basis

Before you compare vendors or APIs, answer one question: does the patient authorize access to their own records, or does a provider organization authorize it on their behalf.

Patient-facing access. The patient logs in, consents, and pulls their own data. This is the model for consumer health apps, personal health records, clinical-trial matching, and any product where the end user is the account holder. The legal basis is the patient's individual right of access, which tends to give the cleanest footing for commercial or product use of the data.

Provider-facing access. Your product integrates on behalf of a clinic, hospital, or health system, and the data moves under a treatment relationship. This is the model for provider workflow tools, care coordination, and clinical decision support that sit inside the delivery of care.

The reason this fork matters so much is purpose of use. Records obtained under a treatment purpose are generally tied to that purpose. They are excellent for supporting care and difficult to repurpose for something like commercial AI training. Patient-authorized access carries a different basis, which is usually what a consumer-facing or data-product use case needs. Putting a clinician "in the loop" to unlock a treatment-based path when the real goal is a commercial one is exactly the kind of move that creates legal exposure, so this is a question for your counsel early, not an implementation detail for later.

Get this fork right and the rest of the plan follows. Get it wrong and you can build a technically clean integration whose data you are not allowed to use for the thing you built it for.

The Three Ways to Reach Clinical Data

Once you know who authenticates, there are three practical connection patterns. The first two are how you serve patient-facing access, where the patient authorizes their own records. The third is the provider-facing, treatment-based route. Most real projects use one as the spine and occasionally a second for coverage.

1. Direct FHIR API integration (patient-facing or provider-facing)

You connect straight to a specific vendor's FHIR API, such as Epic, athenahealth, or NextGen. For a patient-facing product, the patient authenticates against each institution through SMART on FHIR. The same underlying API also supports provider-facing access through backend service accounts. This is the cleanest connection and gives you the most control over what you pull and how you store it.

The tradeoff is that every vendor is its own onramp. You register an app, request sandbox credentials, and clear that vendor's review before you reach production, and each one runs on its own timeline. In the patient-facing case there is also more front-end work, because provider search sits on your side: the patient has to find their institution among thousands of endpoints.

2. Patient-mediated connectivity gateway (patient-facing)

A gateway like Fasten Health sits in front of the whole problem. One API covers thousands of provider systems, the patient picks their clinic from the gateway's catalog, and the gateway handles the per-provider connections, normalization, and validation. You are not building or maintaining an integration per vendor, which is the single biggest reason this path is fast. This is patient-facing by design: each user connects and consents to their own records.

It directly solves the "patients cannot find their provider" problem, since the catalog is the search. Clinical notes usually come through inline, as base64 PDF, text, or HTML, within the scope of the patient's consent. Two honest limits: the gateway surfaces what each source exposes through its patient-access API and no more, and it will not chase notes that live behind external URLs referenced inside a record. Network-wide retrieval through standards like TEFCA can extend coverage further, though it is best treated as an extension of the standard flow rather than a drop-in replacement, since coverage depends on which organizations participate.

3. Clinical-network aggregator (provider-facing)

Aggregators such as Health Gorilla and Particle Health pull records through the US national networks, Carequality and CommonWell, and TEFCA's QHINs, usually under a treatment purpose. The appeal is that there is no per-patient action: no portal login, no OAuth prompt. The data set can be broad. Integration engines like Redox solve a related but different problem, connecting you bidirectionally to many EHRs, rather than pulling records from the national networks.

The cost is structural. Access is gated on providing treatment, which means a medical entity in the loop and a Business Associate Agreement, and it carries the purpose-of-use constraint from the first fork. The commercial model is usually a sizable upfront commitment plus per-query fees, which fits provider workflows far better than a large consumer base. Standing this path up takes longer than the other two, even though it asks nothing of the end user.

The Second Fork: FHIR vs Proprietary API

This fork applies to any direct integration, path 1 above, whether the patient or the provider authenticates. The biggest cost multiplier is whether the vendor speaks FHIR or a proprietary API.

FHIR compounds. The first FHIR R4 integration is the real investment, because you are building the authentication model, the resource handling, and the tooling once. The second FHIR vendor reuses most of that. The auth pattern is the same SMART on FHIR flow, the resources are mostly the same shapes, and your pipeline already knows what to do with them. Connecting a second FHIR EHR does not double the timeline, which is why a strategy across multiple EHR systems is best planned FHIR-first.

Proprietary is a fresh start each time. Many niche, specialty, and older systems, most often on the provider side, expose a proprietary API or lag on FHIR. Some categories are shifting: long-term and post-acute care vendors like PointClickCare now offer FHIR alongside proprietary APIs, so it pays to check each vendor rather than assume. Where a system is genuinely proprietary, each one brings its own authentication, its own data model, and its own quirks, with almost nothing carrying over from the last integration. A FHIR-first strategy with a proprietary fallback is the usual answer: standardize where you can, and budget the proprietary connections as separate projects.

One caveat even inside FHIR: implementations vary. Two vendors can both be FHIR R4 compliant and still hand you the same clinical concept in different shapes. Reconciling that inconsistency against your own data model is where a clean estimate turns into a real one.

The Step Teams Underestimate: Authorization

Across every path that touches a vendor directly, authorization is the quiet timeline killer, and it has almost nothing to do with code.

Getting production access to a major EHR vendor means clearing its developer program and requesting sandbox credentials, sometimes through an app review the vendor controls, not you. Some vendors turn sandbox requests around in days. Others take weeks, or want a signed production agreement before they issue test credentials at all. It is common to start a project with no sandbox access to any target system, which means the clock on vendor approvals starts at zero on day one.

Business Associate Agreements have to be in place with the EHR vendor and every subprocessor touching protected health information, including your cloud provider, before a single record moves. If you do not already have a HIPAA-compliant baseline, this is where to set one up. Momentum's open-source HealthStack Terraform modules get that infrastructure running in days rather than weeks, which is one of the few places in this timeline where you control the pace.

Clinical Notes and Data Completeness

If your use case depends on clinical notes, and anything involving AI usually does, plan for the fact that notes availability varies by source.

Through patient access, a meaningful share of notes does come through, typically inline as base64. What you will not get automatically is a guarantee of the complete set a patient sees inside their portal, notes an EHR simply does not expose over its API, or documents that live behind external URLs referenced in the record. Deciding whether to handle de-identification of that content, and where in the pipeline it sits, is a real scoping decision with real cost, especially once large PDFs and OCR enter the picture. It is far cheaper to answer this at scoping than to discover it mid-build.

Putting the Timeline Together

Here is how the paths compare in practice. A patient-mediated gateway is the fastest to broad coverage, typically weeks, because the time is driven by your own product work rather than vendor approvals, since one API covers many systems. A direct FHIR integration with your first vendor runs on build time plus that vendor's own approval process. Each additional direct FHIR vendor after the first reuses most of the earlier build, so it costs a fraction of the first, plus its own approval. A proprietary API vendor is a separate project each time, since there is no carryover in authentication or data model. A clinical-network aggregator takes the longest to stand up, since it requires a medical entity in the loop, a Business Associate Agreement, and network onboarding, even though it asks nothing of the end user directly.

Patient-facing work is usually the fastest, because it leans on individual patient access rather than a queue of vendor contracts. Caily is a useful reference point here: the platform architected connectivity across seven major EHR systems, including Epic, Cerner, Allscripts, Veradigm, NextGen, athenahealth, and Altera, inside a single HIPAA-ready platform on iOS, Android, and web, as groundwork for future medical data access rather than a same-day live connection to every vendor. A patient-mediated gateway like Fasten Health can compress that kind of per-provider connection work considerably, since one API absorbs what would otherwise be built vendor by vendor.

Provider-facing programs sit at the other end. A direct integration with a single vendor and the compliance groundwork already in place is a matter of weeks of build plus that vendor's authorization. A program spanning several provider-side vendors with different data models, proprietary APIs, and separate Business Associate Agreements can run into several months, driven far more by approvals and per-vendor data mapping than by the code itself. None of these ranges account for what happens after go-live, when vendors update their APIs on their own schedule and your integration needs watching for the moment a change breaks something quietly.

What Actually Moves the Timeline

Four factors shift these ranges more than anything in the build itself.

Patient-facing or provider-facing. Patient access leans on individual consent and, through a gateway, avoids per-vendor contracts entirely. Provider-facing work carries vendor agreements, BAAs, and network onboarding, which is where the months accumulate.

Your FHIR-to-proprietary mix. A roadmap of FHIR vendors compounds in your favor. A roadmap heavy on proprietary systems does not, because each one resets the work.

Vendor responsiveness during authorization is the variable you control least. Mature developer programs offer self-service sandboxes. Others still require a call and a wait measured in weeks.

In-house interoperability depth. Teams doing their first EHR integration spend weeks on specification research that an experienced partner has already internalized. This is often the difference between an estimate and a surprise three months in.

Working With Momentum on EHR Integration

Momentum has delivered healthcare integrations serving 1M+ patients, handling FHIR, HL7, CDA, and direct vendor APIs. That work spans patient-facing products connecting thousands of providers through a single gateway and provider-facing platforms integrated across Epic, Cerner, athenahealth, and more. Caily is the patient-facing multi-EHR reference; other engagements have run prior authorization and clinical data flows at the scale of millions of patients, and platforms like Bennabis Health were built to support up to 5x membership growth while maintaining 99.9% uptime.

Our EHR integration services start with an assessment and scoping phase built to remove the guesswork before a contract is signed, so your engineering team stays on your core product instead of EHR plumbing.

If you are scoping an integration and want a realistic timeline against your specific vendors, your legal basis, and your compliance situation, talk to our team about what your project would actually look like.