Keep the EHR. 5 Ways to Fix the Workflow.
By Michael Nikitin, CEO at Itirra
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 piece is about that work: how to automate it around the EHR you already have, five practical ways to connect, and the limits to find before you commit.
Fewer hospitals are switching
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. Buyers held back on policy uncertainty and moved budget toward AI and efficiency tools.
That’s market context, not a verdict on any one hospital. But it means a lot of teams are asking the same question: how do we get more out of what we already run?
The doors 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. 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. Those numbers include both standards-based and proprietary APIs.
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?”
A broken workflow is not, by itself, a reason to replace the EHR. Often the pain lives in the handoffs around it.
Why hospital workflows are 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.
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.
Five ways in
Here’s the map we walk through with hospital teams. It’s not a strict technical classification, and real projects often combine two or more.
1. An app launched from the EHR. Uses SMART authorization and launch context. Fits when staff need to see or act on something during their EHR work. Depends on app registration, local approval, and the context and permissions the EHR supports.
Get Michael Nikitin’s stories in your inbox
Join Medium for free to get updates from this writer.
2. Backend API integration. A service that uses supported FHIR or proprietary APIs, with no screen of its own. Fits when data needs to move without anyone opening an app. Depends on which resources and operations are allowed, authentication and monitoring.
3. HL7 v2 interface. Messages for events such as admissions, transfers and discharges. Fits event-driven work that can use an interface the hospital already runs. Depends on interface setup, message mapping and an agreed secure connection.
4. File exchange. Scheduled exchange of structured files. Fits batch work like reports and reconciliation. Depends on formats, secure delivery, validation and timing.
5. Integration intermediary. A platform that connects systems through the interfaces they support. Fits when existing connectors save build time. Depends on real connector coverage, who runs it, fees and exit terms.
The first one is where staff feel the difference. An app launched from the EHR can reuse the user’s EHR session and receive context such as the selected patient. 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.
Is keeping the EHR cheaper?
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 it looks 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 we 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.
Where it gets hard
I’d rather you hear this now than discover it three months into a project.
Smaller platforms and older versions often have narrower doors: API use was lower among hospitals not on one of the largest EHR platforms, and among small and independent hospitals. Heavily customized builds put data where the standard doesn’t expect it. Payer portals, spreadsheets and paper may not have an approved, usable interface. Writing back is harder than reading, so plan it early, including how to avoid duplicates.
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 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. Adding data or permissions later can mean new code, new authorization and another review, so choose the list with room to grow.
What discovery should answer first
A short technical discovery, before anyone writes code, should answer six questions. 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 does it live, and how are patients matched across systems? What does your EHR expose, and what write-back is allowed and safe? Which approach, or mix, fits the workflow, the budget and the people who will maintain it? And how will you know it worked?
The result should be a plan you can hold anyone to: scope, architecture, integration points and known risks.
The part that matters most
The solution should be built against your systems and your workflow, not a template that assumes a process you don’t have. You should own what gets built. Interoperability is not a side effect of the project. It is the deliverable.
The EHR isn’t going anywhere. The fax machine can.
Originally published on itirra.com. Itirra builds EHR integrations, FHIR apps and RCM automation for hospitals and healthtech teams. Sources: ONC Data Briefs 68 and 71, ONC Cures Update milestone (Feb 2023), KLAS Research (May 2026), HL7 SMART App Launch STU 2.2.
