EHR Integration for Apps:FHIR, SMART on FHIR and ONC Rules 2026

"The EHR is certified, so the API is open, right? We just need the app to book the appointment and drop a note in the chart."

That's close to word for word what a founder said to me on a scoping call, and it's the most expensive sentence in health tech. Half of it is true. The certified API is open, in the sense federal rules mean it. The other half, booking the appointment and writing the note, is not something any federal rule hands you.

This article is the version of that call I wish I could send ahead of time. It covers the standards you build on (FHIR R4, US Core, SMART App Launch, Bulk FHIR), the federal rules and their exact status as of September 29, 2026, the four big vendor developer programs, and the path from sandbox to a live health system.

If you're building an AI agent rather than an app, read this for the plumbing and then read the companion piece on AI agents and EHR integration, which covers what changes when software, not a person, decides what to read and write.

Here's the model most smart people walk in with. The 21st Century Cures Act said patient data must be accessible through APIs "without special effort." ONC certified the EHRs. So an app that follows the standard can plug in and do what it needs.

Why doesn't that hold? Because the certification criterion that matters, 45 CFR 170.315(g)(10), the standardized API for patient and population services, is about reading. It requires a certified EHR to expose the USCDI data classes through FHIR, with SMART authorization, for a single patient and for groups of patients. It says nothing that obliges an EHR to accept a new appointment, a note or an order from your app.

ONC's own HTI-5 proposal makes the point from the other side: its stated direction for future FHIR API requirements is to move beyond read-only interactions. You don't write that about a program that already requires writes.

So what changes? Three things.

• Your feature list splits into two columns on day one: reads that ride on the certified API, and writes that need a vendor capability plus a health system's permission.
• Every write becomes a commercial and security conversation, not just an engineering one. Budget calendar time for it separately.
• An app whose core value depends on a write is a riskier bet than one whose core value is built on reads. That is not a reason not to build it. It is a reason to know which kind you have.

To be clear, many EHRs do offer write APIs. Epic, Oracle Health, athenahealth and eClinicalWorks all publish more than the certified minimum. The point is that the extra surface is theirs to offer, price and gate, and each customer decides whether to switch it on for you.

You build on four layers, and each one has a version that matters.Think of it like a shipping container. FHIR is the container size everyone agreed on. US Core is the packing list that says which boxes go inside and how they're labeled. USCDI is the government's list of what must be shipped. SMART is the lock and the key.

FHIR R4.Everything certified runs on R4. Don't write a line of new code against anything earlier.

US Core.HL7 publishes US Core annually, and the current published version is 9.0.0. But the certification baseline under HTI-1 is 6.1.0, required since January 1, 2026. The 2026 Standards Version Advancement Process (SVAP) approved US Core 9.0.0 for the (g)(10) criterion, usable from August 29, 2026. SVAP is voluntary. Some vendors will move; others won't for a while.

What does that mean in practice? Code against 6.1.0 as your floor, then read each EHR's capability statement (the metadata endpoint) to see what that specific server supports. Never assume two certified EHRs behave identically bc they claim the same criterion.

USCDI.USCDI v3 replaced v1 as the baseline on January 1, 2026. The 2026 SVAP approved USCDI v6 for seven criteria including (g)(10). USCDI tells you which data classes you can expect, like allergies, problems, medications and health status assessments. It doesn't tell you how a particular clinic actually records them. That gap is where most integration bugs live.

SMART App Launch. HL7 publishes version 2.2.0 as the current release. HTI-1 made SMART v2 the certification baseline from January 1, 2026. The big visible change from v1 is scope syntax: patient/Observation.rs means read and search observations for the patient in context, and system/Encounter.rs is the backend equivalent. Finer scopes are good for patients and good for your security review, bc a health system can see exactly what you want.

Bulk FHIR.The HL7 Bulk Data Access guide defines exports for a whole group of patients as files. You kick off an export, poll until it's ready, then download. It's the right tool for analytics, registries and population health, and the wrong tool for anything a user is waiting on.

SMART defines three connection patterns, and choosing the wrong one is the second most common scoping mistake I see. The first is the write-back assumption.

A quick rule of thumb. If a clinician will use it during a visit, start with EHR launch. If a patient will use it at home, standalone. If nobody is watching, backend services. Most real products end up using two of the three, which is fine, but each one is its own registration and often its own review.

One more practical note: SMART supports asymmetric key (private key JWT) and shared secret client authentication. A mobile app can't keep a secret, so if yours ships a client secret inside the binary, a reviewer will find it. We cover the wider set of controls in our security audit service, but the short version is that tokens belong in the platform keystore and nowhere else.

The federal rules come in a numbered series, and their status matters more than their content.A proposed rule is not law. A withdrawn proposal is not coming. A final rule with a future date isn't binding yet. Here is where each one stood on September 29, 2026, checked against healthit.gov and the Federal Register.

HTI-1 is the one you build to. It took effect March 11, 2024, and set January 1, 2026 as the date when USCDI v3, US Core 6.1.0 and SMART v2 became the baseline. It also added algorithm transparency requirements for decision support and an Insights condition that has developers report on API use.

HTI-2 is the one people misremember. It was proposed on August 5, 2024 as a large package. Pieces were finalized in late 2024, including a TEFCA rule effective January 15, 2025 and a separate Protecting Care Access rule. Then on December 29, 2025, ASTP/ONC withdrew the remaining proposals that had not been finalized. If a blog post tells you HTI-2 is going to require some new API, check the date on it.

HTI-4 is final and took effect October 1, 2025. For app developers, the interesting part is three new FHIR prior authorization criteria: (g)(31) Coverage Requirements Discovery, (g)(32) Documentation Templates and Rules, and (g)(33) Prior Authorization Support, built on the HL7 Da Vinci guides. It also set e-prescribing and real-time prescription benefit dates that run to January 1, 2028.

Then, quietly, the FY 2027 IPPS final rule (CMS-1849-F), which is mostly about hospital payment, carried an ONC section that adopts newer versions of seven FHIR guides, including Da Vinci CRD 2.2.1, DTR 2.2.0 and PAS 2.2.1. It is effective October 1, 2026, and it replaces the versions HTI-4 adopted. If you're building prior auth tooling, pin to those versions, not the HTI-4 ones.

CMS-0057-Fsits beside all this. It binds payers (Medicare Advantage, Medicaid and CHIP programs and plans, and exchange plans), not practices. Its Patient Access, Provider Access, Payer-to-Payer and Prior Authorization APIs are due January 1, 2027. If your app talks to payers, that date is your friend. If it talks only to a clinic's EHR, it mostly isn't your rule.

HTI-5 is a proposed rule, and on September 29, 2026 it had not been published final. ASTP/ONC released it in December 2025; it appeared in the Federal Register on December 29, 2025, and comments closed February 27, 2026. A WEDI federal update in August 2026 reported the final rule under review at OMB. A Federal Register search on the day I checked found no final rule.

Its title is a signal of intent: "ONC Deregulatory Actions to Unleash Prosperity." HHS says it would remove more than half of the certification program's criteria and reset the program's scope around standards-based APIs like FHIR and AI-enabled interoperability. Legal summaries of the text describe the removal of 34 of 60 criteria, with 7 revised.

For information blocking, the proposal would update the definitions of access and use to cover automated and AI systems, narrow some exceptions, and remove the TEFCA Manner Exception.

So what should a developer do with a proposal? Two things, and they point in opposite directions.

• Don't build a roadmap that depends on it. Proposed rules change between proposal and final, and some never finalize. HTI-2's leftovers are the proof.
• Don't build a roadmap that fights it either. The direction is clear: fewer checkbox criteria, more weight on FHIR APIs. An app built cleanly on FHIR R4, US Core and SMART v2 is on the right side of every version of this rule I can imagine.

HHS also published savings estimates for the rule. Those are the agency's projection of its own proposal, so I'm not repeating them as fact.

Information blocking enforcement moved from theory to practice between September 2025 and February 2026. Here are the pieces, in order.

The HHS Office of Inspector General published its civil money penalty rule on July 3, 2023. It covers developers of certified health IT and health information networks or exchanges, with penalties of up to $1 million per violation. Penalties have applied since September 2023.

Providers are handled differently. A CMS rule effective July 31, 2024 sets Medicare disincentives for providers the OIG finds have committed information blocking, through programs such as Promoting Interoperability and MIPS.

On September 3, 2025, HHS announced it would actively enforce the rules, with OIG investigating and ASTP expanding certification audits. Then on February 11, 2026, the Assistant Secretary for Technology Policy said ASTP had begun issuing notices of potential nonconformity to health IT developers, according to Holland & Knight's account of the announcement. No count of notices was disclosed.

What does this mean for you as an app developer? It's a lever, not a skeleton key.

If a vendor or health system refuses your patient-directed app read access to data the patient is entitled to, the rules give you something real to point at. But the rules have exceptions for security, infeasibility, fees and the manner of access, and an actor who documents a legitimate exception is on solid ground. Nothing in them requires a vendor to build you a custom write path.

And a quieter point. If your app ever holds and exchanges patient data at scale for others, you should ask whether you are becoming a health information network yourself. That's a question for counsel, not for a blog post. I'm not a lawyer, and this isn't legal advice.

TEFCA is the national network of networks, and most apps reach it through someone else. The Sequoia Project, as the Recognized Coordinating Entity, lists eleven designated Qualified Health Information Networks: CommonWell, eClinicalWorks/Prismanet, eHealth Exchange, Epic Nexus, Health Gorilla, Kno2, KONZA, MedAllies, Netsmart, Oracle Health Information Network and Surescripts.

The RCE's August 2026 slides report about 1.5 billion documents shared since December 2023. The same materials give two very different organization counts, one around 23,000 live and one above 100,000, which likely measure different things. I'm not picking one.

Why should an app builder care? Because Individual Access Services, the TEFCA purpose that lets a patient-directed app retrieve a person's records across networks, has its own operating procedure, with a version 3.0 effective August 3, 2026. If your product needs a patient's records from many providers, not just one EHR, TEFCA through a QHIN is a path worth pricing against one-by-one EHR integrations.

The downside, stated plainly: you sign up to a QHIN's terms and the RCE's operating procedures, individual access has its own compliance requirements (the RCE is currently reviewing QHIN compliance with them), and what comes back may be documents rather than the tidy FHIR resources your app expects. It is a different project, not a shortcut.

Every major EHR runs its own developer program, and the parts they publish are the easy parts.Here is what I could verify on September 29, 2026, and what I couldn't.

Epic.Epic on FHIR describes itself as a free resource for developers building apps for patients and healthcare organizations, with a testing sandbox, client registration, and a process for requesting a Showroom listing. Epic's paid tiers and the fee for its Connection Hub listing aren't on the pages I checked. I found a UK reseller document quoting a figure, but a reseller's price sheet isn't Epic's, so I won't repeat it.

Oracle Health.Oracle's documentation is refreshingly specific about the path. You register your app in code Console, which issues an application ID and a client ID. The health system then logs service requests to have your app provisioned against its tenant, production may need a client approval form, and Oracle Health support does the provisioning. Sandbox and production live at different URLs.

athenahealth.athenahealth runs a developer portal and a Marketplace program. Its Marketplace page blocked automated reading when I checked, so I can't cite its terms. Third-party integration guides describe open sandbox access with production gated on Marketplace acceptance and per-practice authorization. Treat that as a lead to confirm with athena, not as fact.

eClinicalWorks.eCW's open developer portal calls itself the gateway for third-party systems to integrate with its products using standard APIs, with FHIR endpoint listings and an app gallery. Fees and production terms weren't on the page. eCW is also a designated TEFCA QHIN, which matters if your app is patient-directed.

The pattern across all four: the certified FHIR API is documented and usually free to reach in a sandbox. The proprietary surface, the marketplace listing and production enablement are where terms, reviews and fees live, and they're mostly not published. Ask early, in writing.

The integration has seven steps, and you only control about half of them. This is the table I walk founders through before we write any code.

Two of those rows deserve more words.

Step 2, the data map.USCDI says a certified API exposes, say, problems and medications. It doesn't promise that a small practice codes problems consistently, or that medications carry the dose field your feature needs. The sandbox has tidy synthetic patients. Production has twenty years of free-text. Build the map, then test it against the ugliest real data you can get access to under a BAA.

Step 6, customer activation. This is where timelines go to die. The health system will want a security questionnaire, a BAA, sometimes a pen test report, and an internal champion who pushes your ticket through their IT queue. None of that is in your repo. All of it is on your critical path.

Borrowing a concept from project management: the critical path. The total time of a project is set by the longest chain of dependent steps, not by how fast you do the steps you control. In EHR integration, the critical path almost always runs through steps 5 and 6. Speeding up your build doesn't shorten it. Starting the paperwork earlier does.

This is why we run API work as two tracks from week one in our API development engagements: an engineering track against the sandbox, and a paperwork track against the vendor and the first customer. They meet at step 7.

Here is a scenario, not a client and not a benchmark. The numbers are assumptions chosen to show the arithmetic, so swap in your own.

A specialty practice group wants a clinician-facing app launched from its EHR. It reads problems, medications and recent labs, and writes one thing back: a structured note. One EHR vendor, one health system to start.

• Discovery and data map: 3 weeks.
• Build against the sandbox, reads only: 6 weeks.
• The write path, once the vendor confirms the capability and the customer agrees: 3 more weeks of build.
• Vendor review, if required: unknown, so assume 6 weeks and hope to be wrong.
• Customer security review and activation: assume 8 weeks.

Add the engineering track: 3 + 6 + 3 = 12 weeks. Add the paperwork track if it starts only after the build: 6 + 8 = 14 weeks. Run them in sequence and you get 26 weeks.

Now start the paperwork in week 3, right after discovery. The paperwork track ends at week 3 + 14 = 17. The engineering track ends at week 12. The project ends when the later one does: week 17. That's 26 divided by 17, or about 1.5x faster, and not one line of code was written faster.

And notice what happens if the write path is refused in week 10. In the parallel plan you still ship the read-only app at week 17 and negotiate the write separately. In the sequential plan you find out at week 12 and your whole value proposition is in question. That asymmetry is why I tell clients to put the write question to the vendor in week one.

The most useful thing we've done in health integrations is refuse to let a vendor's API leak into the rest of the app.

On Zero Front Desk for Dr. Peter K. Cudjoe's oral surgery practice in Miami, the practice management system is Open Dental, not a big hospital EHR. We put it behind an adapter boundary: one module that knows how to talk to Open Dental, and a narrow internal interface everything else calls. Insurance eligibility runs separately, through Stedi for X12 270/271 eligibility checks.

Why bother on a single-practice build? Because the scheduling agent books through signed, opaque offer tokens, so it can only confirm a slot the system actually offered and cannot invent one. That guarantee only holds if there's exactly one place where slots come from. The adapter is that place.

The same idea applies directly to FHIR work. Put Epic, Oracle Health or athena behind your own interface. When the second EHR shows up, when a vendor changes a field, or when US Core moves from 6.1.0 to 9.0.0 at one customer and not another, you change one module.

To be clear about what I'm not claiming: the performance numbers on that project are targets, not results, and I'm not reporting outcomes. What I can say is that it went from first commit to live booking in 31 days, and that the adapter boundary is part of why the integration surface stayed small.

It wasn't all clean. At one point 47 booking links pointed at a hostname with no DNS. We fixed them and added a check that every booking hostname resolves. Boring checks like that catch more integration failures than clever architecture does.

I won't quote an industry average for EHR integration cost, because I couldn't find one with a traceable method. Here are our published bands instead, and how the arithmetic works.

Senior time runs $150 to $225 an hour. So a 400-hour integration module costs about $60,000 at the low rate and $90,000 at the high one: 400 × 150 = 60,000 and 400 × 225 = 90,000. If a quote for a single-EHR integration comes back at a tiny fraction of that, ask what's being left out. Usually it's the write path, error handling or the customer activation work.

Vendor program fees are separate and, as the vendor table shows, mostly unpublished. Put a line for them in your budget with the words "to be confirmed" next to it rather than a guess.

If you're still choosing who builds it, our ranking of healthcare app development companies scores firms on what you can verify, and our healthcare industry page lists the work we do in this space.

Every engagement is a fixed-price phased proposal, with a 30-day post-launch warranty, and you own the full source code and IP.

Integrations rarely fail on the happy path. They fail in these places.

The worst case is the first row, so let's bound it. If the write path is refused, you lose the build weeks spent on it, in the scenario above about 3 weeks. You keep a working read-only app. That's survivable. What isn't survivable is a business plan that only works if the write happens, discovered after launch.

And for any app that uses AI on EHR data: prompt injection is not solved. Anything that reads free-text notes can be steered by what's written in them. Treat that as a blast-radius problem, which is the angle the HIPAA-compliant AI agent architecture guide takes.

Here is what I couldn't verify, stated plainly.

• HTI-5's final text. It was reported at OMB in August 2026 and not published when checked. When it lands, parts of this article about certification criteria and information blocking exceptions may need updating.
• Vendor fees. Epic's Connection Hub fee, athenahealth's Marketplace terms and eClinicalWorks' production terms were not published on the pages checked. Oracle's API fee page blocked automated reading.
• Vendor review timelines. No vendor publishes a service level for app review or customer activation, which is why the timeline section is a scenario, not a forecast.
• The number and substance of ASTP's nonconformity notices. The February 2026 announcement disclosed neither.
• TEFCA organization counts, which differ by a factor of four or more within the RCE's own materials.
• Which EHRs have adopted US Core 9.0.0 or USCDI v6 through SVAP. Check each vendor's certified product listing and capability statement.

I also chased and refused a few figures that show up in this topic: industry-average integration costs and timelines with no method behind them, vendor app counts presented as market facts, and HHS's savings estimates for its own proposal. None of them appear above as fact.

You can get most of the risk out of an EHR integration before you write any code.Here's the order I'd do it in.

1. 1.Split your feature list into reads and writes. For every write, email the EHR vendor and your first customer the same question: is this capability available to us, under what terms, and who approves it? Keep the replies.
2. 2.Pick your launch pattern for each feature (EHR launch, standalone or backend services), then register in the vendor's sandbox and pull the capability statement. Map every field you need to a US Core 6.1.0 resource and note anything missing.
3. 3.Start the paperwork now: ask your first health system for its security questionnaire and BAA template this week, and put an adapter boundary in your architecture document so the EHR sits behind one module from the first commit.

If the answers to the write questions come back yes, you have a project. If they come back no, you've saved yourself a build. Either way, time to send the emails.