AI Agents & EHR IntegrationThe Write Ceiling Nobody Budgets For

Almost every healthcare AI post-mortem blames the model, the vendor, or the change-management plan. In our experience the real cause is structural and it is stated plainly in one line of federal certification criteria that almost nobody quotes. The Standardized API for Patient and Population Services criterion at 45 CFR §170.315(g)(10) — the rule that produced the FHIR endpoints every health-tech pitch deck relies on — requires Health IT Modules to support API-enabled “read” services, and those services, in ASTP/ONC’s own words, “specifically exclude ‘write’ capabilities.”

Read that again with an engineering hat on. The thing the government made universal is the ability to get data out. Nothing in certification obliges any EHR vendor to let your application put anything back. Every write your AI agent performs — a note, a flowsheet value, a questionnaire response, a booked appointment — exists because a specific vendor chose to expose a specific path, and because a specific customer organization enabled it for you.

The consequence for planning is severe. A read-only integration can be scoped by an engineer from a specification. A write integration cannot be scoped by anyone until you know (a) which vendor, (b) whether that vendor documents a path for the specific data you want to write, (c) whether the customer organization has the program status and internal approvals to enable it, and (d) whether the customer’s interface team has capacity. Three of those four are outside your control, and none of them are engineering.

A note on scope before we go further. Everything in this guide concerns administrative and documentation automation under human review — intake, eligibility, scheduling, reminders, chart summarization prepared for a person to check. The American Medical Association’s framing of augmented intelligence is the right one: assistive, not autonomous. An AI agent does not practice medicine, and nothing here should be read as advocating autonomous clinical writes.

If you build to one thing, build to the certified floor. As of December 31, 2025, a certified Health IT Module supporting (g)(10) is built on FHIR R4, version 4.0.1, US Core STU 6.1.0, USCDI v3, SMART App Launch 2.0.0, and Bulk Data Access (Flat FHIR) v1.0.0 STU1 with group-export support mandatory.

The 2026 certified standards baseline for EHR API integration, plus the SVAP-approved upgrade path.

Above the floor sits the Standards Version Advancement Process, which lets developers voluntarily certify to newer versions. SVAP has approved US Core 7.0.0 (aligned to USCDI v4) and US Core 8.0.1 (aligned to USCDI v5). Treat those as capability detection, not as an assumption: at any given customer you may find 6.1.0, 7.0.0, or 8.0.1, and your client has to negotiate accordingly rather than hard-code a profile version.

The single most useful artifact you can produce in week one of a healthcare AI project is a read/write matrix: every data element the workflow touches, marked as a read or a write, per vendor. It takes a day. It repeatedly saves quarters, because it forces the write dependencies into the open before anyone commits to a launch date.

The structural asymmetry between read and write EHR integration in 2026 — the source of most healthcare AI schedule slippage.

If a healthcare AI roadmap has a write on the critical path before a customer has signed a subscription agreement, that roadmap has a date on it that nobody in the room controls.

— Frenchy Digital engineering principle

The practical design rule that falls out of this: every phase of the product must deliver standalone value using reads only. If the eligibility agent is worthless unless it can write the result back, you have coupled your launch to a permission you may never receive. If it is valuable as a work queue that a biller clears in one click, you ship in six weeks and add the write later as an optimization — if it ever becomes available.

Epic is where most of the folklore lives, and most of it is out of date. App Orchard no longer exists. It split into Showroom, the customer-facing marketplace, and Vendor Services, the paid developer program, with Connection Hub serving as the entry listing. If a vendor is quoting you App Orchard economics, they have not integrated with Epic recently.

More importantly: Epic on FHIR and open.epic are free to develop against. Sandbox access, client-ID registration, and the SMART and CDS Hooks documentation cost nothing, and Epic states directly that direct access to Epic’s software is not needed to develop, test, deploy, or support your product. The barrier to writing code against Epic in 2026 is approximately zero.

Epic developer program tiers after the App Orchard split. Fee figures are practitioner-reported, not published by Epic.

Now the part that actually determines whether you ship. The real gate is per-customer, not per-app. Every Epic organization that runs your application must independently complete a sequence documented in Epic’s API launch guide:

• Sign the open.epic API Subscription Agreement: A per-organization agreement. Your app being approved somewhere else does not carry over to a new customer.
• Have staff with the 'Able to Purchase Apps' security point: A security point inside the customer's own Epic environment. If no one at that organization holds it, nothing proceeds — regardless of how ready your code is.
• Download your app by Client ID: The customer pulls your app into their environment using the Client ID you provide.
• Set a client secret: Per-customer credential configuration, completed on the customer side.

Epic does expose genuine third-party write paths — they are simply narrow, and specific. Here is the documented set relevant to administrative agents, drawn from Epic’s patient-facing FHIR app documentation:

Documented Epic third-party write paths relevant to administrative AI agents, 2026.

Note what is on that list and what is not. Scheduling is real: Appointment.$find and Appointment.$book let an agent discover and book slots, which is why scheduling agents are the most common production write in outpatient care. But booking is slot-constrained— the agent can only take availability that the schedule already exposes. It cannot double-book, cannot create availability, and cannot override templates. Any vendor promising an AI scheduler that “finds room” in a full clinic is describing something the API does not do.

Here is what the major ambulatory EHR vendors actually require and actually charge, separating sandbox access (nearly always easy) from production access (nearly always the constraint). Where a vendor does not publish pricing, we say so rather than filling the cell with a plausible-looking number.

EHR API access and economics as of August 2026. “Quote-only” means the vendor publishes no pricing — not that it is expensive.

Three observations an engineering lead should take from that table. First, the cheapest technical path in the market is eClinicalWorks, which states that certified FHIR APIs are available to third-party application developers and eClinicalWorks customers at no cost at this time, with 30 days’ notice before any fee is introduced. That is a real, quotable commitment, with an explicit expiry mechanism you should note in your risk register.

Second, Canvas Medical is the only vendor here that publishes a full price list: its Builder tier is $4,000 per month covering the first 1,000 monthly active patients, unlimited users, unlimited API calls with no API fees, and implementation included, on a two-year initial term. For a digital-health builder who needs guaranteed write access and predictable API economics, a modern API-first EHR is often cheaper end-to-end than fighting for narrow write paths in a legacy system.

Third, athenahealth’s gate is a process, not a price. The sandbox is self-serve, and athenahealth’s own FAQ states there is no fee to use the Marketplace and no interface or setup fees. What stands between you and production is the Marketplace partner program, including a Solution Validation call. Budget calendar time, not dollars. And be aware that the “15 to 30 percent revenue share” figure circulating in integration write-ups cannot be traced to any athenahealth document — we could not source it, and neither should you.

If you have researched EHR integration costs in the last two years you have seen the same numbers repeated with total confidence across dozens of sites. They are not real. They trace back to AI-generated integration-agency blog posts that cite each other, and they cannot be sourced to any EHR vendor document.

Widely repeated EHR integration figures that could not be traced to any vendor or primary source.

This matters beyond tidiness. A team that budgets $150,000 for “bidirectional Epic integration” has allocated money to a line item that does not correspond to anything purchasable, while allocating nothing to the thing that will actually consume the quarter: per-customer authorization workflows and the change-management cost of immutable app records.

Here is the counterweight to the write ceiling, and it is genuinely useful. On the read side, you are not negotiating from nothing. Federal information blocking rules give you a real lever, and as of 2026 that lever has enforcement behind it.

On September 3 and 4, 2025, HHS issued a press release alongside a joint OIG and ASTP Enforcement Alert. The alert confirmed civil money penalties of up to $1 million per violation for developers of certified health IT, health information exchanges, and health information networks, and confirmed that ONC can ban or terminate certification. Providers face disincentives rather than CMPs — but those disincentives have teeth.

Information blocking enforcement posture and claim volume, September 2025 through July 2026.

The date that changed the conversation is February 11, 2026, when ASTP/ONC began issuing letters and notices of nonconformity to certified EHR developers over API and interoperability concerns — the first enforcement activity since the ban was enacted. Volume is real too: ASTP/ONC reports 2,563 total portal submissions and 2,450 possible information-blocking claims between April 5, 2021 and July 31, 2026.

The forward-looking piece — and it must be labeled correctly. HTI-5 is a proposed rule, published December 29, 2025, with comments closed February 27, 2026. It is not finalized as of August 2026.

As proposed, it would expand the definitions of “access” and “use” at 45 CFR 171.102 to cover automated means, explicitly including robotic process automation and agentic AI. The implication for anyone in this field is direct: if finalized in that form, blocking an AI agent’s API access could itself constitute information blocking.

What we tell clients: architect as if automated access will be treated as legitimate access, because that is the direction of travel — clean OAuth flows, declared scopes, per-agent identity, and full audit logging. Then plan the business as if nothing changed, because as of today nothing has.

The sequence below is the one we use on every EHR-integrated engagement. Its defining property is that value ships before any write dependency becomes critical path.

Frenchy Digital EHR integration sequencing for AI agents, 2026. Durations assume one vendor and are additive per additional vendor.

• Phase 0 is not optional: The read/write matrix is the artifact that prevents a write from silently landing on the critical path. Build it before writing any code, and rebuild it per vendor.
• Phase 2 must stand alone: If the read-only pilot has no independent value, redesign the workflow. A pilot that only pays off after write access arrives is a pilot with an unbounded end date.
• Phase 3 is a customer function, not an engineering function: Subscription agreements and security points are administrative tasks at the customer. Staff them, script them, and track them like a sales pipeline — because that is what they behave like.
• Phase 4 can fail permanently, and that is fine: Some writes will never be available. The correct response is to ship the fallback architecture from the next section, not to keep the project open waiting.
• Phase 5 freezes the surface: Before you mark an Epic app production-ready, confirm the scope set is complete. After that point, changes cost customer migrations.

Teams treat “no write access” as a failure. In 2026 it is frequently the right architecture regardless, and framing it that way with a clinical stakeholder tends to go better than framing it as a limitation.

Human-in-the-loop and fallback architectures when a write path is unavailable or undesirable.

The reason this is defensible rather than a compromise: a licensed human stays accountable for what enters the chart. That is the same principle CMS applies to its own AI-assisted review work — in the WISeR Model, CMS states that all recommendations for non-payment are determined by appropriately licensed clinicians. The AI triages; it does not issue the decision. Applying the same shape to chart writes is not timidity, it is the design that survives contact with a compliance officer.

One more practical note: any vendor processing ePHI on your behalf is a business associate and needs a signed BAA under HIPAA. That includes model providers, transcription services, and hosting. There is no such thing as being “HIPAA-certified” — what exists is a HIPAA-compliant posture, executed BAAs, and Security Rule safeguards you can evidence.

Two other regulatory surfaces shape what an EHR-integrated agent can do over the next eighteen months. Neither changes the (g)(10) read-only scope, but both change what data will be reachable and from where.

Adjacent regulatory surfaces for EHR-integrated AI agents as of August 2026.

CMS-0057-F is the one most often misread. It binds payers, not practices — Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programs, Medicaid and CHIP managed care plans, and QHP issuers on the federally facilitated exchanges. The Prior Authorization, Provider Access, and Payer-to-Payer FHIR APIs are due January 1, 2027. If your agent’s roadmap assumes payer FHIR endpoints exist today, correct that assumption now.

What is live from that rule, since January 1, 2026: 72-hour expedited and 7-calendar-day standard prior authorization decisions, denial notices that must state a specific reason, and public prior-auth metrics on payer websites, with the first report due March 31, 2026. Those are operational facts your workflows can rely on now. HTI-4, effective October 1, 2025, covers e-prescribing, real-time prescription benefit, and electronic prior authorization on the certification side — relevant because it shapes what your customers’ certified systems are capable of.

Every one of the following has cost a real project real time. None of them is solvable by picking a better model or a better framework.

Known EHR integration failure modes for AI agents and the mitigations we build in by default.

The read is an engineering problem and you will solve it. The write is an organizational problem and you will negotiate it. Any plan that treats them as the same kind of work is already late.

— Frenchy Digital delivery principle

We will also say the unglamorous thing: for a large share of outpatient workflows, the highest-return integration in 2026 is read-only. Pulling the schedule, the coverage, the problem list, and the last visit note into an agent that prepares work for a human is fast to build, cheap to authorize, easy to defend in a security review, and does not depend on a privilege you cannot compel.

These are Frenchy Digital’s own scoping bands for EHR-integrated agent work in 2026. They are ours to state, unlike the circulating integration figures earlier in this article.

Frenchy Digital cost bands for AI agent engagements with EHR integration, 2026.

One line item most agencies omit and we insist on naming: per-customer onboarding effort. If you are selling to ten practices on Epic, you are running ten authorization workstreams, each requiring a signed subscription agreement, a staff member with the right security point, and a client-secret configuration. That work is real, it is repetitive, and it belongs in the budget as its own line rather than hiding inside “integration.”

Use this list even if you hire someone else. Each item below is something we have seen quoted to a practice or a founder in the last twelve months.

The Frenchy Digital red-flag checklist for buying EHR integration and healthcare AI agents, 2026.

Ask any prospective vendor one question: “Which of these are reads and which are writes, and for each write, name the documented vendor path.” The answer separates people who have shipped EHR integrations from people who have read about them.

— Frenchy Digital buyer's principle

Frenchy Digital is a senior-led, Black-owned Los Angeles agency that builds administrative AI agents for healthcare organizations. Here is how an EHR-integrated engagement actually runs:

• Discovery in days, not weeks: A 60-minute structured discovery call, then a written scope and fixed-price phased proposal within 5 business days. The first deliverable is always the read/write matrix.
• Senior engineers only: Every SMART launch, scope design, and audit-logging decision is made by someone who has shipped that integration to a live health organization before.
• Read-only value first: We sequence so the first shipped phase delivers standalone value with read scopes only. Write paths are added when and if the vendor and customer make them available.
• Human-in-the-loop by design: Every state-changing step passes through a review gate sized for the volume a real person can process, with the supporting evidence surfaced next to the recommendation.
• Compliance posture, documented: Signed BAA, Security Rule safeguards, minimum-necessary scope design, and audit logging of every access and every action — evidenced, not asserted. We never claim to be 'HIPAA-certified,' because that does not exist.
• Per-customer onboarding runbook: A scripted, repeatable process for subscription agreements, security points, Client ID download, and client-secret configuration — so customer number ten is faster than customer number one.
• Full ownership transfer: Source code, prompts, infrastructure accounts, and IP transfer to your organization at delivery. 30-day post-launch warranty on every engagement. No vendor lock-in.

To scope an EHR-integrated agent, book a discovery call at calendly.com/frenchydigital/discovery-call or call +1 (424) 272-5601.

If you remember one thing from this article, remember that the federal API mandate made reading universal and left writing entirely to vendor discretion — so plan the read like engineering, plan the write like a negotiation, and never let a write sit on the critical path of a date you have promised someone.