How Healthcare AI Companies Integrate with EHRs That Lack Modern APIs
FHIR covers patient data. Browser automation breaks on UI updates. This guide walks through the four EHR integration approaches healthcare AI teams use in 2026, where each one fails, and how direct HTTP access gets you to production in under a day.
Imagine your healthcare AI scheduling agent is live with your first clinic. It reads Epic's MyChart FHIR endpoints cleanly, books appointments, and handles cancellations without any manual work. Your second clinic runs Athenahealth. Your third runs Jane App. The fourth uses eClinicalWorks. By the fifth, your engineering team is maintaining five separate integration codebases, each with its own auth flow, its own data shape, and its own failure mode. Every EHR quarterly update breaks at least one of them.
This is not an edge case. It is the default experience for healthcare AI companies scaling beyond a single EHR partner. The fragmentation is structural: there are hundreds of EHR vendors in the US market, each with a different API story, and no standard covers the full range of workflows an AI product needs to automate. This post breaks down the four integration approaches your team will encounter, where each one fails, and what the fastest path to a reliable production integration actually looks like. Updated June 2026.
The Four EHR Integration Approaches
Healthcare AI teams have four realistic paths for integrating with an EHR system: FHIR R4 for patient record access, vendor-certified APIs for extended read capabilities, HL7 v2/v3 interfaces for ADT and lab feeds, and direct HTTP for full read/write access to any workflow the platform supports. Each covers a different surface area, and none covers everything on its own.
Approach | Coverage | Setup time | Write access | Maintenance burden |
|---|---|---|---|---|
FHIR R4 | Patient demographics, clinical notes, labs, medications | 3–6 months (Epic certification) | Limited; mostly read-only | Low once certified |
Vendor-certified API | Varies by EHR; often a read-only data subset | Weeks to months; requires vendor approval | Often read-only | Medium |
HL7 v2/v3 interfaces | ADT and ORU feeds; inbound/outbound lab and admission data | Days to weeks (interface engine required) | Bidirectional for HL7 feeds | Medium to high |
Direct HTTP | Full platform access including scheduling, billing, prior auth | 10–20 minutes to generate endpoints; under 1 day to production | Full read/write | Low (auto-healing on Production plan) |
FHIR R4 is the gold standard for patient record portability. It is the right choice when your product reads clinical data: demographics, problem lists, lab results, medications, clinical notes. The SMART on FHIR authorization layer is mature, and Carequality and CommonWell networks give you cross-organization patient record access where participating EHRs support it.
Vendor-certified APIs sit alongside FHIR for EHRs that publish additional endpoints beyond the standard. Athenahealth's proprietary REST API and Epic's non-FHIR endpoints fall here. These often require a formal certification or marketplace listing, and the scope varies significantly by vendor.
HL7 v2/v3 interfaces are the right tool for ADT (admit-discharge-transfer) and ORU (observation/result) message feeds. If your product needs to receive lab results from a hospital lab or send patient status events to a payer, an HL7 v2 interface through a middleware engine like Mirth Connect is the standard path. They are a poor fit for web-based workflows.
Direct HTTP means connecting to the internal API endpoints that an EHR's own web application calls. No certification is required. Coverage is determined by what the platform actually does, not what it chooses to expose publicly.
Where FHIR Coverage Ends
FHIR R4 covers the data layer (demographics, clinical notes, lab results, and medication lists), but it does not cover the operational workflows most healthcare AI products need to automate: real-time appointment booking, prior authorization submission, insurance eligibility verification, and billing workflow automation. For anything beyond read access to clinical data, you need a different approach.
The four gaps that most healthcare AI teams hit first are real-time appointment booking, prior authorization submission, insurance eligibility verification, and billing workflow automation. Most EHRs have not implemented the FHIR scheduling resource in a way that allows external booking. The FHIR Appointment and Slot resources exist in the specification, but production support across Athenahealth, eClinicalWorks, NextGen, and Jane App is inconsistent at best. Prior authorization and payer portal interactions have no FHIR standard coverage at all.
FHIR covers the data layer. It does not automate the workflows your AI product needs to run.
Carequality and CommonWell extend patient record access across networks, but neither addresses operational workflow automation. If your AI agent needs to book an appointment, check a patient's insurance eligibility in real time, submit a prior auth to a payer portal, or update a billing record, FHIR will not get you there.
Why Browser-Based EHR Automation Creates Production Risk
Browser automation (using Puppeteer, Playwright, or Selenium to drive the EHR web interface) is the path many teams take when FHIR and vendor APIs fall short. It is also the path that creates the most ongoing maintenance work.
The core problem is that EHR vendors update their UIs on their own schedule, and your integration is not part of that schedule. Athenahealth, eClinicalWorks, and NextGen all run A/B tests and gradual rollouts on their web interfaces. A CSS selector that resolves correctly on Tuesday may not resolve on Wednesday. Locating a button by its class name or DOM position is a bet that the layout will not change, and EHR vendors routinely lose that bet for you.
Session management compounds the problem at scale. EHR systems require authenticated sessions. Managing session cookies across a pool of concurrent browser instances means tracking expiry, re-authenticating before timeouts, and handling 2FA challenges that trigger mid-session. Each of these is solvable, but each is also another failure mode to monitor. The maintenance overhead is not a one-time cost; it accrues every time any EHR you depend on ships an update.
Building a browser-based EHR integration takes two to four weeks. Most teams find it breaking within the same quarter.
How Direct HTTP Integration Works for EHR Systems
Integuru generates direct HTTP integrations for EHR systems by analyzing network requests made during normal platform usage, reverse-engineering the private API structure, and producing production-ready endpoints your application can call directly, bypassing the browser layer entirely and targeting the same backend endpoints the EHR's own web application calls. The resulting integration does not depend on what the frontend looks like. A UI redesign that would break every browser automation script leaves a direct HTTP integration unaffected, because the backend endpoints the web app calls change far less frequently than the visual layer on top of them. Integuru's integrations handle complex authentication flows including 2FA by capturing and managing session tokens at the HTTP layer, with auth auto-healing on the Production plan to handle session expiry automatically.
Penciled, an AI scheduling company serving physical therapy clinics, switched from browser automation to Integuru's direct HTTP integrations after their EHR workflows hit both the latency and reliability walls. Their EHR actions were running at 30 to 40 seconds each under browser automation, and they were caching appointment data every 30 minutes to manage the load, which introduced real-world scheduling conflicts when two patients tried to book the same slot before the cache refreshed. After switching to direct HTTP, the same actions completed in around 3 seconds, cache-based conflicts were eliminated entirely, and the team could focus on building the product instead of fixing broken scripts. Full details are in the Penciled case study.
<3 sec average response time for Integuru-generated EHR integrations
10–20 min to generate working endpoints for a new EHR platform
<1 day typical time from endpoint generation to production deployment
What to Expect from EHR Integration Timelines
The timeline gap between EHR integration approaches is larger than most teams expect: FHIR certification with Epic takes a minimum of three to six months, a custom browser-based integration takes two to four weeks before it first breaks, and Integuru generates working endpoints for a new EHR in 10 to 20 minutes with total time to production typically under a day.
Getting FHIR-certified with Epic requires a formal application to Epic's App Orchard program, a technical review, and a compliance period before your app can go live. Athenahealth and other major EHRs have similar certification processes for their vendor APIs. For a healthcare AI startup that signed a customer last month and needs to ship the integration this quarter, that timeline is almost never workable.
Building a custom browser-based EHR integration takes two to four weeks from start to a working demo. In practice, most teams find that the first post-launch EHR update breaks the integration, putting them back into an unplanned maintenance cycle within 60 to 90 days of going live.
Because Integuru's integrations target backend endpoints rather than frontend selectors, they do not require rework every time an EHR vendor pushes a UI update. The choice of approach is also a choice about whose engineering time gets spent on maintenance: FHIR certification shifts that burden largely onto the standard itself once you are live; browser automation shifts it entirely onto your team, on the EHR vendor's timeline; direct HTTP with Integuru shifts it to Integuru's 24/7 on-call maintenance team on the Production plan.
For a broader look at how healthcare AI companies use direct HTTP integrations across scheduling, billing, and prior auth workflows, see the healthcare solutions overview.
Get Started
The EHR integration problem is solvable. The path that gets you to production fastest and keeps you there is direct HTTP access to the same endpoints your provider portal already uses.
The fastest way to start is the CLI:
npm install -g integuru
Or visit app.integuru.com to generate your first EHR integration in the browser. To see what this looks like in a live healthcare AI deployment, read the Penciled case study. If you want to talk through your specific EHR stack first, book a call with us or email us.