It’s late Friday afternoon. A patient has been medically ready to leave since morning, but not to go home. The case manager has called one facility after another, faxed the same packet to each, and is now waiting for someone to call back. Somewhere down the hall, someone says what everyone is thinking: we need a new EHR.
Usually, you don’t. A broken workflow doesn’t automatically mean a broken EHR. More often, the system holds the record just fine, and the work around it runs on phones, faxes and one person’s spreadsheet. This article is about that work: how EHR workflow automation fixes hospital workflows around the system you already have, five practical EHR integration options, and the limits to find before you commit.
You wouldn’t be alone in keeping it. KLAS reported that the number of U.S. hospitals affected by an acute care EHR purchase decision fell about 40% in 2025 compared with 2024, as buyers held back on policy uncertainty and moved budget toward AI and efficiency tools (KLAS Research, May 2026). That’s market context, not a verdict on your hospital. But it means a lot of teams are asking the same question you are: how do we get more out of what we already run?
Do you have to replace your EHR to automate hospital workflows?
Often, no. And that matters, because a replacement is a long, expensive project that lands on the same staff who are already stretched.
The doors for outside software are usually already there. Developers of certified API technology had to move to a standardized, FHIR-based API under ONC’s §170.315(g)(10) criterion and provide it to customers by December 31, 2022. More than 95% of certified health IT developers met that deadline (ONC, 2023). FHIR (Fast Healthcare Interoperability Resources) is the standard that defines how health data is structured and requested.
Hospitals use these doors every day. In 2022, about 4 in 5 non-federal acute care hospitals reported using APIs to let clinician-facing apps read EHR data, and about 4 in 5 reported using them to write data back. These included both standards-based and proprietary APIs (ONC Data Brief 68).
A door isn’t a promise, though. The certification rules focused mainly on reading data. What your EHR actually lets you read, write and trigger still has to be checked in your environment.
So the useful question is rarely “Can our EHR do this?” It’s “What exactly needs to happen, and which door does it need?”
If the EHR works, why are hospital workflows still manual?
Because the work doesn’t stay in one system. A record arrives from another organization. Someone retypes it. A referral goes out by fax. Someone calls to check it arrived. Nobody calls back. The status lives in a spreadsheet that one person understands, and that person is out today.
This isn’t a rare edge case. In 2023, only 51% of hospitals routinely integrated electronically received summary-of-care records into the EHR without manual entry. And 41% of rural hospitals and 42% of critical access hospitals did not take part in all four measured parts of interoperability (sending, receiving, finding and integrating records) even some of the time (ONC Data Brief 71, 2023 data).
Every one of those manual steps has a cost you can count: hours on hold, days a referral sits unanswered, pages faxed, a bed that could have gone to the next patient. And a cost that never shows up in a report: the nurse or case manager who stays late to finish it.
The data alone doesn’t say where the problem sits. It could be the EHR, its local configuration, an outside partner, or the steps between them. Finding that out is the first job. The good news: much of this is repetitive administrative work that can be measured and automated, while clinical judgment stays with the people who should make it.
What are the 5 EHR integration options for workflow automation?
Here’s the map we walk through with hospital teams: five practical EHR integration options. It’s not a strict technical classification, and real projects often combine two or more.
| Approach | What it is | Good fit when | Main dependency |
|---|---|---|---|
| EHR-launched app | An app launched from the EHR using SMART authorization and launch context | Staff need to see or act on something during their EHR work | App registration, local approval, supported context and permissions |
| Backend API integration | A service that uses supported FHIR or proprietary APIs, with no screen of its own | Data needs to move without anyone opening an app | Which resources and operations are allowed, authentication, monitoring |
| HL7 v2 interface | A messaging interface for events such as admissions, transfers and discharges | Event-driven work that can use an interface the hospital already runs | Interface setup, message mapping, an agreed secure connection |
| File exchange | Scheduled exchange of structured files or documents | Batch work: reports, reconciliation, daily lists | File formats, secure delivery, validation, timing |
| Integration intermediary | A platform that connects systems through the interfaces they support | Existing connectors can save build time | Real connector coverage, who runs it, fees and exit terms |
The first row is where staff feel the difference. A SMART on FHIR app uses the HL7 standard for apps that launch from the EHR. An EHR-launched app can reuse the user’s EHR session and receive context such as the selected patient (HL7 SMART App Launch). Whether it opens inside the EHR screen or in a separate window depends on the EHR and the local setup. When it works well, it’s the difference between a tool people use and a tool they quietly skip. One more login and one more screen is the first thing a busy team drops. (We covered the common SMART on FHIR implementation pitfalls separately.)
A common combination: an EHR-launched app for the people doing the work, plus a backend integration that keeps the data current without anyone touching it.
Is keeping the EHR cheaper than an EHR replacement?
Not automatically. Put the options side by side: native configuration, an existing module from your EHR vendor, an intermediary, and a custom integration. Compare implementation cost, monthly fees, hospital IT effort, who supports it after go-live, downtime risk, and what the next change will cost. The right answer is the smallest change that fixes the workflow and that your team can live with. Sometimes that’s not new software at all.
What does EHR workflow automation look like in practice?
Go back to the case manager from the first paragraph. The clinical record lives in a modern EHR. The referral lives on the phone and the fax machine.
AIDA Healthcare set out to fix exactly that handoff, and Itirra built AIDA’s FHIR app to run inside the hospital’s EHR, not next to it:
- Case managers open the app from the EHR with single sign-on, without a separate login.
- Referral data moves to post-acute providers through APIs instead of fax.
The hospitals kept their EHR. What changed was the work around it: the calls, the faxes, the waiting. If you’re a healthtech company with a product like this, the lesson is the same from the other side: hospitals want the work inside the EHR, so the product has to go there. The full story is in our AIDA case study.
What are the limits of EHR integration?
We’d rather you hear this now than discover it three months into a project. Keeping the EHR is a good starting point, not a guarantee. Here’s where it gets harder:
- Smaller platforms and older versions. API use was lower among hospitals not on one of the largest EHR platforms, and among small and independent hospitals (ONC Data Brief 68). The door may exist but be narrower.
- Heavily customized builds. Years of local configuration can mean the data you need isn’t where the standard expects it.
- Data outside the EHR. Payer portals, spreadsheets and paper records may not have an approved, usable interface for your workflow. Part of the project becomes getting that data into a system first.
- Writing back, not just reading. Hospitals were somewhat less likely to use standards-based APIs to write to the EHR than to read from it (ONC Data Brief 68). Plan write-back early, including how to avoid duplicates.
- Approvals before go-live. Production use may need app registration, vendor onboarding, a hospital security review and local configuration. A marketplace listing is needed only when the vendor or the distribution route requires it. In our experience, vendor review alone can take anywhere from days to months, and no one can rush it on your behalf.
- Changing scope later. Adding data, operations or permissions after deployment can mean code changes, new authorization, testing and another review. Choose the list with some room to grow.
And if direct integration isn’t ready yet, there is often a fallback, such as staff entering a patient identifier once and the rest of the data loading automatically. It isn’t perfect. It lets a hospital start helping its staff now, while the full integration catches up.
How does a technical discovery reduce EHR integration risk?
By answering the hard questions before anyone writes code. A useful discovery covers six:
- What is the workflow today, step by step, including every place it leaves the EHR.
- Can the EHR already do part of it with configuration or a module you own.
- What data does each step need, where it lives, and how patients are matched across systems.
- What does your EHR expose for that data: which APIs, which events, what write-back is allowed and safe.
- Which approach, or which mix, fits the workflow, the budget and the people who will maintain it.
- How you’ll know it worked: today’s baseline, acceptance criteria, and who handles errors and retries.
The result should be a plan you can hold anyone to: scope, architecture, integration points and known risks. We’ll cover what a good discovery should hand you in a separate article on November 2. If you’re comparing partners for that work, here’s what to look for in a FHIR development partner.
Two more things matter. The solution is built against your systems and your workflow, not a template that assumes a process you don’t have. And you own what we build, and that’s written into the contract. Interoperability is not a side effect of the project. It is the deliverable.
The EHR isn’t going anywhere. The fax machine can.
Frequently Asked Questions
What is EHR workflow automation, and do we need a new EHR for it?
EHR workflow automation means moving manual steps, such as retyping records, faxing referrals or chasing statuses, into software connected to the EHR you already run. Often you don’t need a new EHR for it. Certified API technology has had to support ONC’s standardized FHIR-based API criterion since the end of 2022, and in 2022 about 4 in 5 hospitals reported using APIs for clinician apps to read EHR data (ONC). What your specific EHR allows, especially for write-back, still needs to be confirmed in discovery.
What is a SMART on FHIR app?
It is an app that uses the HL7 SMART App Launch standard for authorization and can launch from the EHR with context such as the current patient. How it appears to staff, embedded or in a separate window, depends on the EHR and local configuration.
How long does it take to get an app approved?
It depends on the vendor, the hospital, the review route and how complete the submission is. In our experience, vendor review alone ranges from days to months and can’t be sped up from outside. Confirm the steps early, in discovery.
Is EHR workflow automation realistic for a small or rural hospital?
Yes, but discovery matters more. In 2023, 41% of rural and 42% of critical access hospitals did not take part in all four measured parts of interoperability (ONC). Start by confirming what the EHR exposes and where data still moves by hand.
Do we need a VPN to integrate with our EHR?
Usually not for FHIR APIs, which typically run over secure web connections with OAuth authorization. HL7 v2 interfaces more often use a VPN or another private connection. The final setup is decided with the hospital’s integration and security teams.
Which step in one of your processes still leaves the EHR: a fax, a phone call, or a spreadsheet?
Ready to talk?
Let’s talk about your project.
Think of the process your team has quietly given up on, the one everyone says is impossible without a new EHR. Let’s look at where it leaves the system you have, and what it would take to bring it back in.
Sources
- US Acute Care EHR Market Share 2026: Market Uncertainty Significantly Cuts Buying Decisions. KLAS Research, May 14, 2026. Source for the ~40% drop in hospitals affected by EHR purchase decisions in 2025 vs. 2024 and the stated reasons.
- Achieving a Major Milestone: Health IT Developers Certify to Cures Update. ONC, Feb 10, 2023. Source for the §170.315(g)(10) standardized API criterion, the Dec 31, 2022 deadline and the 95%+ developer compliance figure.
- Hospital Use of APIs to Enable Data Sharing Between EHRs and Apps (Data Brief No. 68). ONC, Sept 2023, 2022 AHA IT Supplement data. Source for clinician-app API read/write use and differences by hospital type.
- Interoperable Exchange of Patient Health Information Among U.S. Hospitals: 2023 (Data Brief No. 71). ONC, May 2024, 2023 data. Source for the 51% integration figure (Figure 2) and the 41% rural / 42% critical access figures (Table 1).
- SMART App Launch Implementation Guide, STU 2.2. HL7. Source for EHR launch, launch context and authorization.