The architectural shift from batch billing to bidirectional FHIR — and what changes when the loop closes.
It’s a Tuesday morning. The CIO of a 400-bed regional health system is sitting in the same conference room she sat in eighteen months ago, presenting the third “AI denial prevention” pilot to the same finance committee. The denial rate has barely moved. The committee is polite. The fatigue in the room is louder than the slides.
If you’ve sat in that room — or you’re scheduled to sit in it next quarter — this article is for you.
Initial denial rates hit 11.8% in 2024, up from 10.2% just four years earlier (Kodiak Solutions). Medicare Advantage sits at 15.7%. Medicaid managed care at 16.7% (Premier Inc.). The U.S. healthcare system spends roughly $19.7 billion a year appealing denials that should never have happened in the first place.
Every tool that came through that conference room was supposed to fix this. Most of them haven’t.
This isn’t a tooling problem. It’s an architecture problem.
“Adding technology to a broken process just makes you fail faster.”
Why more RCM technology keeps failing
Walk into any health system’s revenue cycle stack and you’ll find the same pattern: a billing engine wrapped in increasingly clever scrubbers, sitting downstream of an EHR that hands it whatever data it has at end-of-encounter. New denial-prevention tool? Bolt it on the side. New AI claim review? Plug it into the same end-of-encounter handoff.
But the data on where denials actually originate is unambiguous: 70% to 80% of denial-causing errors happen at registration and during the clinical encounter — not in billing. By the time the claim hits the scrubber, the chance to fix it has already passed. The patient is gone. The clinician has moved on to forty other patients. The documentation is buried in a chart no one is going to reopen.
“You can scrub a broken claim until it shines. It’s still broken.”
This is the polite secret most vendors don’t lead with: when you add technology to a broken process, the process doesn’t get fixed. It just fails faster, more efficiently, and with a better dashboard.
The health systems that are actually moving their denial rate aren’t the ones buying more tools. They’re the ones rebuilding the layer underneath.
The difference between a billing engine and an execution system
Most hospital RCM stacks are billing engines. They process whatever data the EHR finishes handing them, scrub it, submit it, and report on what came back. If the data was wrong on the way in, the billing engine submits wrong data more efficiently.
An execution system is structurally different. It does not wait for end-of-encounter. It observes clinical activity as it happens, triggers the right action at the right moment, and closes the loop between clinical events and financial outcomes — before the claim is ever assembled.
Three differences matter:
1. Latency. Billing engines run on batches. Data flows once a day, sometimes once a shift. Execution systems are event-driven. A failed eligibility check, a missing CPT modifier, a service ordered without prior auth — the system sees it the moment it happens.
2. Direction. Most legacy integrations are one-way. HL7 v2 ADT, ORM, and DFT messages flow from EHR to billing. The billing system receives, but it cannot push back. An execution system writes back. It can flag a missing field into the EHR while the patient is still in the room.
3. Scope. A billing engine cares about claims. An execution system cares about the workflow that produces a claim — eligibility, authorization, documentation, coding, charge capture, submission, remit — as one continuous loop instead of seven disconnected steps.
Vendors who sell “RCM automation” rarely make this distinction. The architecture is what decides whether you’re actually preventing denials or just processing them faster.
Bidirectional FHIR: observe, trigger, close the loop
The technical shift that makes execution systems possible is bidirectional FHIR.
HL7 v2 — still the backbone of most health-system integrations — was designed for one-way batch messaging. It moves data from system A to system B. It does not support real-time queries, callbacks, or write-backs into the source system. Whatever you build on top of HL7 v2 inherits its constraints.
FHIR R4 changes the shape of integration. It is a RESTful API. You can GET a resource the moment you need it, POST a new resource the moment something happens, and PUT updates back into the source. Layered on top:
- SMART on FHIR — the OAuth 2.0 identity and consent layer that lets external services act on patient data with the right scopes.
- CDS Hooks — the trigger mechanism. The EHR calls out to your decision-support service mid-workflow, and your service returns a card the clinician sees on screen, without leaving the chart.
- Da Vinci Implementation Guides — CRD, DTR, PAS, and others — that define how prior authorization, documentation requirements, and payer-side workflows actually move through FHIR.
Those four pieces together are the foundation for the three verbs that define an execution system:
Observe. Subscribe to FHIR events. When a ServiceRequest is created, when an Encounter is updated, when Coverage changes — your integration layer sees it in real time.
Trigger. When the observed event matches a denial-risk pattern — a high-dollar order without prior auth on file, a documentation field that fails medical-necessity rules, a coverage gap — the system fires the right action: a CDS Hooks card to the clinician, a task to the prior auth team, a charge correction to the coder.
Close the loop. Write the resolution back into the source system as a FHIR resource update. The EHR, the billing engine, and the CDS service now agree on the same state. The claim is built from clean data because the clean data already exists in the chart.
This isn’t a redesign of the entire RCM stack. It’s an integration layer that sits between the systems you already own — and turns them into something that works as a single workflow instead of seven disconnected ones.
From HL7 v2 to bidirectional FHIR: a phased migration
Most health systems can’t rip out HL7 v2 — and shouldn’t try. The path is incremental, and it pays off in stages.
Phase 1: Map the denial-driver workflow (Months 0–2). Pull the top three denial categories from your last twelve months of remits. For most health systems, those will be eligibility, prior auth, and medical necessity. Trace each one back to the specific clinical workflow that produces it — not the billing step that processes it. The fix lives upstream of the claim.
Phase 2: Stand up a FHIR integration layer (Months 2–5). Most major EHRs already expose FHIR R4 endpoints. You don’t need to wait for a vendor upgrade. The integration layer normalizes data across EHR, billing, and CDS so each system can subscribe to the same events. Design it so payer-specific differences live in configuration, not in code forks — you’ll thank yourself when you connect to your fourth payer.
Phase 3: Wire the first closed loop (Months 4–8). Pick one high-volume, high-impact denial driver. Build the observe → trigger → close-the-loop flow end to end. Real-time eligibility verification at registration is usually the cheapest first win: query Coverage, return a clean status before the visit starts, and write the verified eligibility back into the chart. One workflow. Live in production.
Phase 4: Expand (Months 8+). Add prior authorization next. This is where the CMS-0057-F mandated payer FHIR APIs start delivering value — and the integration layer you built absorbs them as configuration changes, not new projects. Then medical necessity. Then documentation prompts via CDS Hooks. Each new loop reuses the foundation.
Common Mistake: Treating this as a billing-department project. The owners must be clinical informatics, IT integration, and revenue integrity together — not RCM alone. If the workflow change does not touch the EHR, the loop will not close.
Consultant’s Tip: Don’t try to standardize across the whole health system on day one. Run the first closed loop on a single service line — surgery, imaging, or specialty pharmacy are good candidates because they have concentrated, high-dollar denial patterns. Prove the model. Then scale.
What this looks like from the CFO’s seat
Numbers matter. They aren’t the whole story.
“Every claim denial is a downstream cost — and an upstream human one.”
It’s a case manager calling a family on a Friday afternoon to explain that a procedure is paused while a prior auth gets re-submitted. It’s a coder rebuilding documentation six weeks after the patient was discharged. It’s a CDI specialist sending the same query, for the third time, on the same case. It’s the clinician getting pinged about a charge they entered yesterday — because the system didn’t catch the gap when it mattered.
If you’re a CFO or CIO at a U.S. health system reading this in 2026 — especially across the Pacific Northwest, where margins are tightest and consolidation pressure is highest — you’ve heard the FHIR pitch before. You’ve also heard the “AI-powered” pitch, the “unified dashboard” pitch, and the “value-based care platform” pitch. The fatigue is earned.
What’s different now is that the integration architecture has actually changed. FHIR R4 is mature. SMART on FHIR is in production at every major EHR. CDS Hooks is no longer a research project. The pieces fit together in a way they didn’t five years ago.
The health systems that move their denial rate in the next 24 months won’t be the ones buying another tool. They’ll be the ones rebuilding the layer underneath.
The takeaway
The denial problem isn’t really a revenue cycle problem. It’s a clinical workflow problem that shows up in the revenue cycle.
The fix isn’t a better appeals team. It isn’t a smarter scrubber. It isn’t a third AI pilot. The fix is closing the loop between what happens clinically and what gets submitted — before the claim is filed. That’s what denial management looks like when it’s built into the workflow, not bolted on after.
That’s the architecture we build at Itirra.
Are your denial trends moving in the wrong direction despite new tooling? Let’s talk about your project.
Sources
- Kodiak Solutions RCM Benchmarking Report 2024–2025 — initial denial rate of 11.8% in 2024, up from 10.2% in 2020. Cited via HFMA coverage, December 2024.
- Premier Inc., 2024 Trends in Healthcare Payments — Medicare Advantage 15.7% denial rate, Medicaid managed care 16.7%, ~$19.7B annual industry spend on appeals: premierinc.com
- HL7 FHIR R4 specification — RESTful API standard for healthcare data exchange: hl7.org/fhir/R4/
- SMART on FHIR — OAuth 2.0-based authorization framework for healthcare apps: smarthealthit.org
- HL7 CDS Hooks specification — real-time clinical decision support trigger mechanism: cds-hooks.hl7.org
- HL7 Da Vinci Project — implementation guides for payer-provider FHIR workflows (CRD, DTR, PAS): hl7.org/about/davinci
- CMS-0057-F Final Rule (CMS Interoperability and Prior Authorization) — federal mandate for payer FHIR APIs by 2027: cms.gov