DEV Community: Michael Nikitin

Building AI-Powered Healthcare Appeals: A Three-Stage Architecture Guide

Michael Nikitin — Fri, 20 Mar 2026 23:21:54 +0000

Most healthcare orgs only chase one of two appeal paths when claims get denied. The other path – member appeals – is a technical problem worth solving.

When a claim is denied, clinical staff typically file a provider appeal. But every patient also has a legal right to file a member appeal, which triggers a separate adjudication track with different review criteria. Most organizations ignore this path entirely, leaving recoverable revenue on the table.

Building member appeals at scale is an integration and automation problem: pull clinical data from the EHR, match it against payer-specific criteria, generate patient-facing documentation, and track outcomes. Here's a three-stage architecture for building that system.

The Integration Layer: FHIR + HL7

Before any AI logic, you need reliable data access. The clinical evidence supporting appeals (lab results, medication history, prior authorizations) lives in Epic, Oracle Health, MEDITECH, and similar systems.

You'll likely need both major interoperability standards:

FHIR for structured, on-demand data. RESTful APIs give you discrete clinical data when you need it. For appeals, the key resources are:

ExplanationOfBenefit and ClaimResponse for denial details
Patient and DocumentReference for supporting evidence
MedicationRequest and Observation for clinical context

HL7 v2 for real-time event triggers. ADT (Admit-Discharge-Transfer) and DFT messages let your system react the moment a denial posts. If you need to kick off an appeal workflow automatically when a claim status changes, this is likely your event source.

Map your data needs to specific FHIR resources and HL7 message types before writing integration code. Start with ExplanationOfBenefit and ClaimResponse, expand based on which denial categories you're targeting first.

Stage 1: LLM Wrapper

The simplest implementation: a general-purpose LLM behind an API, wrapped in a prompt layer.

The flow:

Pull denied claim + clinical notes via your EHR integration
Construct a prompt with denial reason, EOB data, appeal requirements
Send to LLM API
Return draft appeal letter for human review

This ships in weeks. Engineering effort is prompt tuning plus a thin integration layer. Costs are mostly API usage.

What you get: Working prototype, early data on which denial types respond well to AI-assisted appeals, something concrete to iterate on.

What you don't get:

No calibration to your specific payer mix or denial patterns
Hallucination risk (model may cite nonexistent policies)
No evaluation framework to measure output quality
No audit trail for compliance
Limited transparency into generation logic

Stage 1 is a starting point. Treat it as a data collection instrument – every draft generated, every human correction, every outcome tracked becomes training data for later stages.

Stage 2: Decomposed Architecture with RAG

The architectural shift: stop asking the LLM to do all the reasoning and decompose the problem instead.

LLM handles: Language tasks (summarization, draft generation)
Deterministic logic handles: Classification, routing, compliance checks

Stage 2 Pipeline

Classify – Rules engine categorizes denied claim by denial code + payer
Retrieve – RAG pipeline pulls payer-specific guidelines and historical overturn data from vector store
Generate – LLM drafts appeal grounded in retrieved context (not free-associating from training data)
Validate – Check output against known criteria before human review
Review – Human edits and submits

This decomposition gives you visibility. When an appeal fails, you can trace whether the issue was classification, retrieval, generation, or missing clinical data. You fix the specific component.

What you're building:

Vector database for payer guidelines and historical cases
Classification layer (denial code → workflow routing)
Prompt management system
Orchestration logic
Evaluation framework measuring output quality against real outcomes

What you can now measure:

Appeal success rates by denial category
Time to resolution
Dollars recovered through member appeals
Audit trails for compliance

Run Stage 1 through a pilot first. Collect error patterns. Use that data to prioritize which denial categories get Stage 2 treatment – highest revenue impact per engineering hour.

Stage 3: Fine-Tuned Domain Models

Stage 3 means training on your proprietary data: historical denial and appeal outcomes, payer behavior patterns, and documentation quality signals.

At this level, the system anticipates denials rather than reacting:

Flags at-risk claims based on historical patterns
Recommends preemptive documentation improvements
Routes appeals by predicted overturn likelihood
Surfaces systemic denial trends pointing to upstream issues

For member appeals specifically, a custom model can:

Predict which denied claims are the strongest candidates for patient-initiated appeals
Generate documentation calibrated to language-specific payers respond to
Learn from every outcome to improve predictions

Prerequisites (non-negotiable):

Mature FHIR/HL7 integrations
Clean, normalized historical data at scale
Robust testing harness from Stage 2 to validate the custom model actually outperforms a well-configured general LLM

Without the measurement infrastructure from Stage 2, you can't prove your expensive custom model beats what you already had. Build measurement first.

Sequencing the Build

Each stage generates the data that the next stage depends on.

Months 1-3: Integration + Stage 1

Connect to EHR via FHIR and HL7
Target highest-volume denial categories
Deploy LLM wrapper for member appeal drafting
Goal: generate production data on AI-assisted appeal performance

Months 3-9: Stage 2 on real data

Use Stage 1 error patterns to prioritize denial categories
Build classification, RAG pipelines, eval framework
Prove ROI, build the dataset Stage 3 will train on

Months 9-18: Stage 3 development

Fine-tune domain-specific models
Start where you have deepest data and clearest performance gap

Principles

Start with denial categories where member appeals have the highest dollar recovery potential
Treat Stage 1 as data collection, not just a productivity tool
Budget for integration as a first-class investment—the FHIR/HL7 plumbing becomes the foundation for everything

The critical dependency at each transition is data quality. Rushing the timeline without underlying data produces expensive models that don't outperform simpler approaches.

The three-stage framework applies beyond healthcare appeals – any domain where you're moving from generic LLM to production-grade, measurable AI follows a similar arc: wrapper → decomposed architecture with retrieval → domain-specific fine-tuning. The lesson is respecting the build order.

The Architecture Behind FHIR-Based Member Appeals Automation

Michael Nikitin — Wed, 11 Mar 2026 13:39:40 +0000

A lot of member appeals products are solving the wrong problem.

They make it faster to submit an appeal – better forms, cleaner portals, fewer clicks. But the actual bottleneck was never submission. It's the 30–90 minutes a nurse spends hunting through an EHR to assemble clinical evidence that already exists in structured form, just not anywhere the appeals workflow can reach it.

If you're building in the prior auth or claims space, this distinction matters. The companies that treat appeals as a data retrieval problem build fundamentally different and better products than the ones treating it as a submission problem. This post is about the architecture, decisions, and sequencing behind the first approach.

Briefly about member appeal lifecycle

A member appeal is a formal request to overturn a health plan's denial of coverage. The member or their provider submits clinical evidence arguing medical necessity. Most appeals start with prior authorization denials, not billing disputes.

The denial reasons are predictable: incomplete clinical documentation (data was in the EHR, just not attached), coding mismatches, payer-specific rule failures, or missed submission windows. In nearly every case, the data to prevent the denial or win the appeal was already captured somewhere in the system. It wasn't surfaced, structured, or transmitted in time.

The implication for builders: if your product only handles the appeal after the denial, you're entering the workflow at the most expensive, lowest-leverage point. The earlier you can pull structured clinical data into the process, the more valuable the product becomes, and the architecture choices you make in month one determine whether that upstream expansion is even possible later.

What changes when you have live EHR access

EHR integration doesn't just speed up appeals — it makes entirely different workflows possible

Automated evidence assembly is the starting point. Instead of a person copying chart data into a submission, your system queries the EHR for the specific FHIR resources a payer requires for that denial reason (Condition, Observation, MedicationRequest, DocumentReference) and packages them programmatically. The appeal gets built in seconds from data that already exists.

Gap detection and triage is where it gets interesting. With live clinical data, you can score appeal probability before submission. Flag the ones likely to win, route the ones that need more clinical input, and stop wasting time on appeals that were dead on arrival. This alone changes how teams allocate their skilled staff.

Faster payer-provider exchange compresses review cycles. When both sides exchange structured FHIR data rather than faxed PDFs, the payer gets machine-readable clinical information, and the provider gets structured status updates instead of portal notifications.

Upstream denial prevention is the end game. If you're integrated deeply enough to analyze prior auth submissions before they go out, you can catch documentation gaps that would trigger a denial. No denial, no appeal. This is the highest-value capability, but it requires a foundation that most teams don't lay early enough, which is why sequencing matters.

Architecture decisions that matter more than the API calls

The FHIR queries themselves are straightforward. You'll pull from a small set of resources – Patient, Condition, Observation, MedicationRequest, DocumentReference, Procedure, and Claim/ClaimResponse on the payer side. That's well-documented. What's less documented is where the real architectural decisions live.

Payer rules as configuration, not code

Every payer has different medical necessity criteria, documentation requirements, and submission formats. The temptation in Phase 1 is to hard-code logic for your first payer and move fast.

It’s important you don’t do it.

Build a rules engine from the start – even a simple one. Map denial reason codes to required FHIR resources and payer-specific evidence criteria. Define lookback periods, required observation categories, and whether step therapy evidence or a letter of medical necessity is needed – all as configuration, not conditionals.

When you onboard payer number two, you want to be adding configuration rows instead of rewriting query logic. The alternative of a growing chain of payer-specific if blocks is one of the most common architectural dead ends in appeals products. It works for one payer, then breaks at three. By five, you're looking at a rewrite.

Handling the "structured data isn't actually structured" problem

FHIR gives you structured access. It does not guarantee structured content. This is the gap that catches most teams off guard.

Clinical notes come back as free text inside DocumentReference. Lab results use local codes instead of LOINC. Diagnosis codes are outdated or too general to support medical necessity arguments. You need a data quality layer between the FHIR response and your evidence package.

That layer doesn't need to be sophisticated on day one. Start by checking whether lab results have standard LOINC coding, whether clinical notes are structured or free-text blobs, and whether diagnosis codes are specific enough for the payer's criteria. When quality checks fail, route to a human for review rather than submitting a weak package that will get bounced, which restarts the entire cycle and costs more than the delay.

The goal is to build this quality layer into the architecture from the beginning, even if the checks are basic. Bolting it on later means retrofitting every pipeline that touches clinical data.

Auth: the timeline you should actually plan for

Implementing SMART on FHIR for OAuth2 authorization is well-documented. What's less obvious is the non-technical timeline around it.

Vendor registration with the EHR (Epic, Oracle Health, etc.) can take weeks on its own. Then comes the health system's security review – they'll want to know exactly what data you're accessing, how you're storing it, and your BAA status. You may request access to Observation and DocumentReference, but get pushback on the breadth of clinical data you're pulling. Scope negotiation is real.

The technical auth flow is standard OAuth2. Budget your timeline for the administrative process, not the code. A realistic range for a first production integration is 3–6 months, and admin approvals (not engineering) drive most of that.

On the payer side, the CMS Interoperability and Prior Authorization Final Rule is pushing health plans toward FHIR-based APIs. This regulatory tailwind is real and worth building toward, but implementation timelines vary significantly by payer.

Failure modes that aren't in the docs

Skipping the provider workflow. If your tool requires providers to change how they document, adoption stalls. The best appeals integrations are invisible to the clinician – they pull data that's already captured without adding documentation steps. The moment you ask a physician to fill in a new field "for the appeals tool," you've lost them.

Building denial prevention before proving evidence assembly. This is a sequencing mistake driven by ambition. Denial prevention requires deep integration on both the provider and payer sides, plus enough data to build reliable gap detection models. If you haven't proven you can save a nurse 45 minutes on appeal prep, you're not ready to pitch upstream prevention to enterprise buyers. Walk before you run.

Treating EHR integration as a phase two feature. This is the most expensive mistake on the list. Startups that build the submission layer first and bolt on EHR integration later end up constrained by early architecture decisions — the data model, the payer rules structure, the evidence packaging pipeline. All of these are shaped by whether you assumed manual data entry or programmatic retrieval. Retrofitting is painful, slow, and often means rebuilding the core of the product.

Phased roadmap

Phase 1 (Months 1–3): Read-only evidence assembly. Connect to one EHR environment. Pull clinical data for the most common denial types. Measure time savings for your first pilot customer. Ask them for their top five denial reason codes by volume and scope Phase 1 around those – it keeps the build tight and makes ROI easy to prove.

Phase 2 (Months 3–6): Structured submission and status tracking. Compile and submit appeal packages in structured formats. Integrate status tracking so users aren't manually checking payer portals. Begin supporting a second EHR vendor or additional sites.

Phase 3 (Months 6–12): Bi-directional payer-provider exchange. Payers request and receive structured clinical data through your platform. This is where payer partnerships start to matter, and your platform becomes the exchange layer, not just the submission tool.

Phase 4 (Months 12+): Upstream denial prevention. Pre-submission analysis catches documentation gaps before the prior auth goes out. Highest value, highest complexity. Don't start here, but make sure your Phase 1 architecture doesn't prevent you from getting here.

The real argument

The regulatory environment is moving toward FHIR-based exchange, and the CMS Prior Authorization Final Rule is accelerating it, but regulation isn't the reason to build this way.

The reason is simpler: the clinical data needed for most appeals already exists in the EHR, and the teams that build products around retrieving it programmatically will outperform the ones that build better paperwork.

Every architectural decision – how you model payer rules, how you handle data quality, how you scope your first integration – either moves you toward that or away from it. Start with read-only evidence assembly. Prove the time savings. Then expand upstream. The foundation you lay in Phase 1 determines whether Phase 4 is a natural extension or a rebuild.

From Billing Engine to Execution System: Architecting Real-Time Healthcare RCM with FHIR

Michael Nikitin — Wed, 18 Feb 2026 19:32:38 +0000

Key Takeaways

RCM must move upstream
Value-based care ties reimbursement to outcomes, not volume. RCM needs real-time clinical awareness and workflow triggers during care delivery – it can't wait for claims.
Execution system = observe → trigger → close the loop
Execution systems add what billing engines don't: real-time clinical awareness, workflow actions (not dashboards), and EHR write-back.
FHIR EHR Integration Is the Foundation
FHIR enables bidirectional workflows: reading clinical data and writing operational data back into the EHR. This makes near-real-time execution scalable across vendors.

Why RCM Needs to Move Beyond Billing

Most RCM companies traditionally focus on working with physicians to optimize documentation and adjust procedures for appropriate reimbursement, submit claims and manage denials when payers reject them, ensure diagnosis and procedure codes are accurate and complete, and handle prior authorizations so payers approve coverage before services are rendered.

These functions aren't going away, but they're increasingly insufficient on their own.

Value-based care (VBC) contracts are restructuring how providers get paid. Shared savings, bundled payments, capitation, quality bonuses – these models tie reimbursement to outcomes, not volume. When revenue depends on whether a care gap was closed or a readmission was prevented, the RCM function can't sit downstream waiting for claims to be processed. It needs to be wired into clinical workflows in near-real time.

The core shift for RCM companies isn't deciding whether to make this move; it's defining how fast you can do it without breaking what already works. And that's where EHR integration consulting becomes a strategic investment, not just a technical line item.

What "Execution System" Actually Means in Practice

Calling RCM an "execution system" sounds compelling on a slide. In practice, it means your platform does three things that a traditional billing engine does not.

Real-Time Clinical Awareness

Your system doesn't wait for a claim to show up. It knows when a patient is admitted, when a lab result posts, and when a diagnosis is documented – all because it's connected to the EHR event stream, not just the billing feed.

This matters because value-based contracts penalize gaps. Let’s say a patient with diabetes visits the clinic and no A1C is ordered – a billing system won't notice until the quality report is due. An execution system flags it during the encounter.

Workflow Triggers, Not Just Reports

Traditional RCM generates reports. Execution-oriented RCM generates actions. A missing prior authorization triggers a task in the care team's queue. An incomplete surgical note triggers a documentation prompt before the case is closed – not three weeks later during coding review.

Common Mistake: Building dashboards that surface insights, but don't connect to actionable workflows. Instead, design every clinical flag with a clear "what happens next" path – a task, a notification, a queue assignment, so insights don't just sit in a report no one opens.

Closed-Loop Feedback

The system writes back. When your platform identifies a care gap, it doesn't just log it internally – it pushes a flag, an order suggestion, or a task back into the EHR where clinicians actually work. This closed-loop capability is what separates "analytics platform" from "execution system."

FHIR EHR Integration as the Backbone

None of the execution-system capabilities above work without deep, reliable EHR connectivity. This is the infrastructure layer that most RCM companies underestimate and where the real competitive moat gets built.

Why FHIR Matters for RCM Specifically

FHIR gives RCM platforms a standardized way to read clinical data (Condition, Observation, Encounter, MedicationRequest) and write operational data back (Task, Flag, DocumentReference) across EHR systems. Before FHIR, most RCM integrations relied on HL7 v2 feeds and batch file drops – workable for claims, but too slow and too rigid for real-time execution.

With FHIR, you can query a patient's active problems during an encounter, check whether required quality measures have been completed, and push a care gap alert back into the EHR – all through documented APIs rather than custom point-to-point interfaces.

The Integration Isn't Just "Connecting to Epic"

The most common misconception is that EHR integration is a one-time technical project. For RCM execution systems, it's an ongoing architectural concern. You need:

Clinical event subscriptions — knowing when encounters open, close, or change status
Order and result awareness — seeing labs, imaging, and referrals as they flow
Documentation completeness signals — detecting missing notes or unsigned orders before they become coding problems
Write-back channels — pushing tasks, flags, or structured summaries into the EHR

Consultant's Tip: Start your EHR integration with the read-side use cases that directly impact your highest-volume denial categories. This gives you the fastest measurable ROI and builds credibility with health system IT teams before you ask for write-back permissions, which always take longer to approve.

Integration Patterns That Scale

Once you've committed to real EHR integration, the architectural choices matter more than most RCM teams expect. The patterns you pick early will either accelerate or constrain your ability to scale across sites, EHR vendors, and contract types.

Event-Driven vs. Batch: Choosing the Right Pattern

Not every RCM workflow needs real-time data. The right architecture usually combines both patterns, matched to the use case.

Common Mistake: Defaulting everything to real-time, because it sounds better on a demo. Real-time infrastructure is expensive to build and maintain. Over-indexing on event-driven patterns for workflows that are fine with nightly batches wastes engineering cycles and increases operational complexity. Match the pattern to the clinical and financial urgency.

SMART on FHIR Apps vs. Backend Services

SMART on FHIR apps launch inside the EHR. They're ideal when a clinician or coder needs to see your RCM insights in context – care gap alerts during a visit, documentation prompts while charting, or risk score overlays on a patient panel.

Backend services run without a user session. They're the right choice for automated workflows – nightly quality measure runs, batch eligibility checks, and automated task creation based on clinical events.

Most mature RCM execution platforms need both. The mistake is building only backend services and missing the chance to surface insights at the point of care. Check out pros and cons of both approaches to understand what’s right for you.

The Role of AI in Modern RCM

AI is already embedded in RCM workflows, and its role is expanding rapidly. But the value AI delivers depends entirely on the quality and timeliness of the data feeding it, which brings us back to EHR integration.

Where AI Is Delivering Value Today

Current AI applications in RCM cluster around a few high-impact areas:

Coding assistance — AI models suggest diagnosis and procedure codes based on clinical documentation, reducing coder workload and catching missed codes that affect reimbursement
Denial prediction — Machine learning models flag claims likely to be denied before submission, allowing preemptive corrections
Prior authorization automation — AI extracts relevant clinical data and pre-populates authorization requests, cutting manual effort significantly
Documentation improvement — Natural language processing identifies gaps in physician notes that will cause coding or compliance issues downstream

These applications work best when they have access to real-time clinical context rather than just the claim data that arrives after the fact.

Where AI Is Heading

The next wave of AI in RCM moves from assistance to autonomous action. Use cases are endless; the most important ones to head to are:

Automatic prior auth submission when clinical criteria are met (read more about CMS-0057-F final rule for prior auth)
Real-time coding suggestions surfaced during documentation, not after
Predictive models that detect patients at risk of care gaps before their next visit
Large language models (LLMs) summarizing complex clinical histories to support appeals or peer-to-peer reviews

The trajectory is clear: AI will handle increasingly complex RCM tasks with less human oversight. But none of this works without the integration foundation.

An AI model predicting denials is only useful if it can trigger a workflow → A coding assistant is only valuable if it sees the clinical note as it's being written → An LLM drafting an appeal letter needs access to the full clinical context, not just the claim.

Building AI-Readiness Into Your RCM Platform

AI-readiness isn't a feature you bolt on later – it's an architectural posture you adopt now. RCM companies that want to leverage advanced AI capabilities in the next two to three years need to be building the foundation today. That foundation comes down to five infrastructure requirements.

AI-readiness starts with the foundation: structured data capture with provenance. AI models are only as good as the data they learn from, so clinical inputs should be captured in structured formats with clear source system, timestamp, and lineage. In healthcare, if you can’t trace an output back to its inputs and explain why it happened, teams won’t trust it or adopt it.

Next is real-time data access. High-impact AI needs clinical context as it’s created – during the encounter, documentation, and before submission steps, so it can influence decisions while they’re still reversible. That’s why event-driven pipelines and low-latency access matter more than nightly batch exports.

Then comes bidirectional workflow integration. Insights sitting in dashboards rarely change outcomes; AI has to reach the people who can act. The practical bar is being able to push recommendations back into the EHR or operational tools as tasks, alerts, pre-populated forms, or suggested actions, embedded directly where work happens.

AI also depends on identity resolution and data quality. If patient records don’t match across systems, or coding and fields are inconsistent, model outputs quickly become unreliable. You don’t need perfect data, but you do need consistency supported by deterministic matching rules, validation, and ongoing quality monitoring across your integration layer.

Finally, durable AI requires feedback loops for continuous improvement. The system should capture what happened after each recommendation – whether it was accepted, modified, or rejected, and feed that signal back into the refinement process. Without this closed loop, performance plateaus; with it, the system improves in the ways that actually matter in production.

Common Mistake: Treating AI as a layer you add on top of existing RCM infrastructure or thinking of AI as "something we'll add once we have enough data". AI capabilities should be designed into your integration architecture from the start. Retrofitting AI onto a batch-oriented system limits you to retrospective analytics rather than real-time intervention.

From Claims to Clinical Execution: RCM's Role in Value-Based Care

Understanding the VBC Landscape

Value-based care encompasses several contract models, each with different implications for RCM:

Shared savings programs — Providers keep a portion of savings when they reduce costs below a benchmark while meeting quality thresholds
Bundled payments — One payment includes all services for a care episode (e.g., joint replacement), creating an incentive to reduce complications and unnecessary services
Capitation — Providers receive a fixed per-member-per-month payment regardless of services delivered, shifting utilization risk to the provider
Quality bonuses and penalties — Payers adjust reimbursement based on performance on specific quality measures

Each model requires RCM to track different data, trigger different workflows, and measure success differently than fee-for-service.

Why VBC Changes the RCM Value Proposition

Under fee-for-service, RCM value is measured in clean claim rates and days in A/R (Accounts Receivable). Under value-based contracts, the metrics shift dramatically:

Care gap closure rates → Are patients getting the preventive services their contracts require?
Risk adjustment accuracy → Is every documented condition properly captured and coded?
Cost avoidance → Are unnecessary readmissions, ER visits, and duplicative tests being prevented?
Quality measure performance → Are you hitting the thresholds that trigger bonuses rather than penalties?

An RCM platform that can only process claims can't move these levers. An execution system, wired into EHR data, triggering workflows, and closing loops – can.

A Phased Roadmap for the Shift

You can't rebuild your RCM platform overnight. You can, however, sequence the transition, so each phase delivers value and funds the next.

Phase 1: Read-Side Clinical Intelligence (Months 1–4)

Connect to EHR clinical data via FHIR, starting with Condition, Encounter, and Observation resources. Layer this on your existing claims data to identify patterns your billing-only view misses.

Phase 2: Automated Workflow Triggers (Months 3–7)

Build event-driven triggers for your highest-impact workflows: prior auth gaps, missing documentation flags, quality measure reminders.

Phase 3: Point-of-Care Integration (Months 6–12)

Deploy SMART on FHIR apps that surface insights where clinicians work. Care gap alerts during visits. Risk adjustment prompts during coding.

Phase 4: Closed-Loop Write-Back and VBC Optimization (Months 10–18)

Enable write-back to the EHR. Optimize for specific VBC contract types. Build reporting that ties your platform's actions to contract performance.

Choosing the Right Integration Partner for RCM Company

The shift from billing engine to execution system touches every layer of your platform – data pipelines, authorization models, clinical workflows, write-back architecture. Doing that while keeping your existing revenue cycle running is the hard part. A good EHR integration partner makes this manageable by absorbing the complexity your team shouldn't have to learn from scratch.

Specifically, the right partner compresses the work in three ways:

They've already mapped the vendor landscape. Every EHR has its own FHIR coverage gaps, extension quirks, authorization flows, and IT approval processes. An experienced partner knows where Epic differs from Oracle Health, which write-back paths require additional governance, and how to scope requests so health system IT teams say yes faster. Your engineers skip months of trial-and-error discovery.

They sequence the buildout so you ship value early. Without guidance, most RCM teams try to build the full integration layer before launching anything and run out of budget or patience. A partner who's done this before designs the architecture in phases, shipping read-side wins in months while laying groundwork for write-back and AI. Each phase pays for the next.

They handle the non-technical bottlenecks. The hardest parts of EHR integration are often administrative, not technical – security reviews, data use agreements, scope approvals, and change control processes. A partner who knows these workflows keeps your project moving when your engineering team would otherwise be stuck waiting on paperwork they've never seen before.

When evaluating partners, the questions that reveal depth of experience are:

Have they built integrations that combine clinical and financial data, not just one or the other?
Can they show you a phased approach specific to your platform and your customers' EHR mix?
Do they understand closed-loop clinical workflows, not just read-only data pulls?
How would they approach write-back authorization with a health system IT team?

Itirra works with healthcare companies navigating exactly this transition, combining FHIR integration consulting, EHR connectivity across major vendors, and strategic sequencing that turns an integration project into a platform capability. If you're an RCM company evaluating how to move from a billing engine to an execution system, a focused architecture assessment is usually the right starting point. Schedule a consultation with us to plan your next steps together.

FAQ

How is an RCM "execution system" different from adding analytics to a billing platform?

Analytics tells you what happened. An execution system acts on what's happening. The difference is real-time EHR connectivity, automated workflow triggers, and write-back capability – your platform doesn't just report care gaps, it pushes alerts into clinician workflows and tracks closure.

Why can't traditional RCM handle value-based care?

Traditional RCM only sees data after services are completed and claims generated. Value-based contracts tie reimbursement to outcomes determined during care delivery. By the time traditional systems see the claim, it's too late to close care gaps or ensure quality measures are met.

What's the biggest technical risk in this transition?

Underestimating write-back complexity. Reading clinical data is relatively straightforward; writing back requires stricter authorization, more rigorous testing, and longer health system approval cycles. Plan for write-back to take 2-3x longer than read-side integration.

Do we need FHIR integration if our RCM platform already receives HL7 v2 feeds?

HL7 v2 messages and file-based exchanges can move events and documents, but they’re inconsistent to map. FHIR gives you queryable APIs, standardized clinical resources, and write-back channels that HL7 v2 simply doesn't offer. Most RCM companies keep their existing HL7 feeds for legacy workflows while building new VBC capabilities on FHIR.

How does AI fit into an RCM execution system?

AI amplifies what the execution system can do – predicting denials, suggesting codes, automating prior auth. But AI without real-time clinical data access is limited to retrospective analysis. The integration layer is what makes AI actionable rather than just informational.

How do we decide between event-driven and batch integration patterns?

Real-time infrastructure is expensive, so you need to match the pattern to urgency. Use event-driven when timing matters and encounters need real-time (prior auth gaps, documentation prompts before signing, in-visit care gaps). Use batch when aggregation matters (panel-level quality measures, trend analysis, forecasting). Most mature platforms use both – event-driven for action, batch for measurement.

Can we build this in-house, or do we need an EHR integration partner?

It depends on whether your team has built production FHIR integrations with write-back before. If not, an experienced partner compresses the learning curve from 6+ months to 8-10 weeks and helps avoid architectural decisions that are expensive to reverse.

How FHIR Enables Agentic AI in Healthcare

Michael Nikitin — Sat, 07 Feb 2026 07:59:47 +0000

What Is Agentic AI in Healthcare?

Agentic AI has become a prominent topic in healthcare technology discussions, but the term often lacks clarity in clinical contexts. If you’re evaluating where AI fits in your product roadmap or considering EHR integration consulting to support AI features, understanding what agentic AI actually means is essential for sound architectural decisions.

In its simplest form, agentic AI refers to systems capable of taking autonomous action toward a goal, rather than simply answering questions or generating text. A chatbot that responds to patient questions is not agentic. A system that identifies a patient at risk for readmission, drafts a care plan, schedules a follow-up, and notifies the care team without requiring a human to initiate each step would be agentic. That’s the vision many technology leaders describe. The clinical reality, however, looks quite different.

The Gap Between Vision and Reality

Today’s clinical AI remains fundamentally reactive and advisory. Most implementations fall into narrow categories: chatbots that triage symptoms, documentation assistants that summarize notes, risk models that flag patients for review, and clinical decision support alerts. These tools provide value, but the human clinician still makes every decision and takes every action. The AI suggests – the clinician executes. True agentic AI would invert this: the AI would execute, and the clinician would approve or supervise, creating entirely different technical, regulatory, and safety requirements.
Healthcare presents unique challenges. An AI that books an incorrect flight creates inconvenience. An AI that orders an inappropriate medication or misses a drug interaction can cause serious patient harm. Clinical context is messy and incomplete, with the “right” action often depending on preferences, circumstances, and nuances not captured in structured data. Accountability is legally defined, and regulatory frameworks don’t provide clear answers for autonomous systems making consequential decisions. This doesn’t mean agentic AI is impossible – it means the path forward requires careful architecture. FHIR provides a foundation that enables thoughtful clinical automation.

Why Agentic AI Fails Without Interoperability and How FHIR Solves It

Autonomous AI systems require reliable data access and predictable mechanisms for taking action – capabilities healthcare has historically lacked. Consider what an agentic workflow requires: an AI identifies declining kidney function in a diabetic patient and needs to pull current medications from the EHR, check for contraindicated drugs, draft an order modification, and document the rationale. Each step requires reading from or writing to clinical systems through consistent interfaces. Without standardization, every deployment becomes bespoke: you cannot build scalable workflows when every hospital requires different API calls and data formats.

FHIR is what turns EHR connectivity from one-off custom work into repeatable building blocks—so agentic workflows can scale beyond a single health system. For a practical roadmap (discovery → build → validation), see FHIR integration for digital health companies.

Consistent data structures and API patterns in FHIR enable workflows that function beyond a single implementation. Standardization enables three critical capabilities:

portable logic where decision rules reference standard resources across Epic, Cerner, or MEDITECH;
auditable actions where reads and writes log consistently for regulators;
incremental automation where you can progress from read-only recommendations to write capabilities without architectural rewrites.

Consultant’s Tip: Before building any agentic capability, map your entire workflow to FHIR resource types. If a step can’t be represented as a standard FHIR operation, that’s where your integration will break when you scale.

Four FHIR Capabilities Enabling Agentic Workflows

Standart data models

FHIR defines consistent resource structures: Patient, Observation, Condition, MedicationRequest, CarePlan. When your AI evaluates a patient’s state, it queries predictable fields and relationships.

This matters because autonomous decision-making requires reliable interpretation. An AI can’t safely act on lab results if “abnormal” means different things in different data feeds. FHIR’s standardized value sets provide a consistent semantic foundation.

Consistent RESTful APIs

FHIR specifies interaction patterns, not just data structures. Create, Read, Update, Delete operations follow standard HTTP conventions. Search parameters work consistently across resource types.

For agentic AI, this means “works anywhere FHIR is implemented.” Your workflow uses the same API calls to check allergies, whether the data lives in Epic or Cerner. Reading and writing use the same patterns – an AI that queries Observations to detect risk can later create Observations to document findings.

Explicit Clinical Semantics

FHIR resources reference standard terminologies: SNOMED CT for findings, LOINC for labs, RxNorm for medications. Your AI interprets coded values against established ontologies rather than parsing free text.

For autonomous action, coded data enables programmatic safety checks. Before drafting a medication order, the AI verifies against the patient’s coded allergy list. That verification is only possible with consistent terminology.

Auditability and Governance

FHIR includes provenance tracking: where data came from, how it was modified, by whom, and when. When an AI takes action, that action becomes part of the auditable medical record.

This isn’t optional for clinical AI. Regulators and risk managers will reconstruct what happened when something goes wrong. FHIR’s native provenance support makes that reconstruction possible without custom audit infrastructure.

Why Structured Clinical Data and Context Matter for Safe AI Automation

AI decision quality depends entirely on input data quality. FHIR’s resource model encourages structured, coded data. When the AI evaluates blood pressure control, it applies deterministic logic to coded values with LOINC codes, units, and reference ranges. It doesn’t parse “BP running a bit high lately” from clinical notes.

Effective decisions also require longitudinal context. A single elevated reading means different things for a patient with 20-year hypertension history versus a healthy 30-year-old. FHIR enables assembling context by querying across resource types and time periods. In practice, data quality varies enormously – some fields are reliably coded, others are frequently missing. AI designed for autonomous action must handle quality issues gracefully: refusing to act when critical context is missing, flagging low-confidence recommendations for review.

Before you automate anything, you need reliable inputs, consistent coding, and an audit trail you can defend. Treat that as integration work – find the sequencing outlined in AI readiness roadmap for healthcare startups.

Human-in-the-Loop: Why Agentic AI Requires Approval Workflows

Recommendations vs. Actions: The Essential Distinction

This distinction is fundamental to how agentic AI should function clinically.
Recommendations are AI output: “This patient should receive a flu vaccine,” “Consider adjusting this dose.”

Actions are changes to the medical record: the order entered, the prescription modified.

In properly designed workflows, AI generates recommendations and prepares corresponding actions, but humans approve before execution. The AI performs cognitive work identifying what should happen; the clinician validates and authorizes.

This “recommend and prepare, then approve” model isn’t a temporary compromise until AI gets smarter. It’s a fundamental design principle. Clinicians bring contextual knowledge AI cannot access, professional judgment from training and experience, and legal accountability that cannot be delegated to software. AI brings consistency, comprehensive data review, and ability to surface overlooked information. Both contributions are essential.

Designing Effective Approval Workflows

Effective approval design follows key principles:

Make approval fast for routine cases. One-click confirmation when the recommendation is clearly correct.
Force attention for edge cases. Require explicit acknowledgment when confidence is low or risk factors exist.
Provide easy override paths. Clinicians must modify or reject without friction.
Document every decision. Approved, modified, or rejected – it becomes part of the record.

Current regulatory frameworks assume human decision-making. Clinicians are licensed and accountable; AI systems are tools they use. This means write-capable clinical AI operates under significant constraints. Even when the AI drafts an order, a licensed clinician typically must sign it.

Common Mistake: Treating human approval as an annoying constraint to minimize. Clinician approval is your safety mechanism and regulatory compliance pathway. Design it as a core feature, not an obstacle.

CDS Hooks and SMART on FHIR: EHR Integration Standards for Agentic Workflows

FHIR provides the data layer. Two complementary specifications – CDS Hooks and SMART on FHIR – provide integration patterns that make AI-assisted workflows practical within EHR systems.

CDS Hooks: Triggering AI at the Right Moment
CDS Hooks defines standardized mechanisms for invoking external decision support at specific workflow points. When clinicians open charts, place orders, or schedule appointments, the EHR calls your AI service, passing clinical context and receiving structured recommendations.

CDS Hooks provides the critical “when” of clinical intervention. Your AI activates precisely when clinicians make decisions, with full context about what they’re doing and which patient they’re treating. Standard hook points include:
- patient-view: opening a record, enabling alerts, and care gap identification
- order-select: beginning an order, enabling real-time guidance
order-sign: before signing, enabling safety checks and alternatives
- appointment-book: scheduling, enabling coordination recommendations
Each hook expects “cards”: structured recommendations displayed within the workflow. Cards include alerts, suggested actions, and links to SMART applications. Recommendations appear at the decision moment, not in separate dashboards. Clinicians accept suggestions with minimal friction rather than manually re-entering orders.

SMART on FHIR: Embedded Applications
SMART on FHIR specifies how applications launch from within EHRs with appropriate authorization. While CDS Hooks delivers focused recommendations, SMART enables richer experiences, presenting complex recommendations with evidence, multi-step approval workflows, and collecting additional input. CDS Hooks triggers AI at the right moment; SMART apps launch with full context when clinicians need deeper interaction.

The hard part of SMART is operational, not conceptual: aligning scopes, permissions, and data availability with the actual clinical workflow. For the issues we see most often, see common pitfalls in SMART on FHIR implementation.

Building Toward Agentic AI: Governance and Implementation Readiness

The question isn’t when you’ll deploy fully automated workflows – that timeline remains uncertain. If you’re building clinical AI with an eye toward future autonomous capabilities, what matters is what you should do now.

Technical Readiness

Before pursuing any agentic capability, validate these foundations:

FHIR read access for reliable data input
FHIR write access for future automation
CDS Hooks integration for real-time workflow triggering
SMART app capability for interactive approvals
Provenance tracking for audit trails
Terminology mapping for consistent interpretation

Governance and Implementation Sequencing

Before deploying AI-influenced clinical decisions, establish governance:

scope boundaries documenting what AI can recommend
monitoring for poor recommendations or drift
escalation paths for situations outside confidence thresholds
failure remediation processes
human accountability

A realistic path focuses on foundations:

Phase 1 builds robust FHIR read integration, validates data quality, and implements advisory AI through CDS Hooks.

Phase 2 adds capabilities for AI to prepare actions with approval workflows requiring genuine review.

Phase 3 designs AI-ready data architecture: normalized storage, provenance tracking, consent-aware handling.

Phase 4 expands AI involvement based on demonstrated safety, maintaining human oversight.

Clinical AI automation isn’t purely technical with a predictable timeline. It depends on regulatory evolution, organizational comfort, and accumulated safety evidence. Building foundations positions you when the broader environment is ready.

Key Takeaways

FHIR provides the foundation
Standardized data models, consistent APIs, explicit semantics, and built-in auditability give AI systems the interoperability clinical automation requires.

Agentic AI should recommend and prepare; humans should approve and execute
This isn’t a limitation – it’s a human-in-the-loop design principle reflecting regulatory reality and sound clinical practice.

CDS Hooks and SMART on FHIR enable integration
These specifications let AI activate at the right moment and deliver recommendations within workflows.

Start advisory, earn autonomy
Prove recommendations are good before automating execution. Build monitoring and governance before you need them.

An experienced healthcare integration consultant can help design architecture supporting today’s advisory features while keeping the path to future automation open. The startups building responsible agentic infrastructure now will be positioned to deliver autonomous capabilities when the technology and regulatory frameworks catch up.

FAQ

What’s the difference between agentic AI and traditional clinical automation?

Traditional automation follows static rules (“if X, then Y”) and operates on limited data.
Agentic AI works toward goals: it gathers context, proposes actions, routes approvals, and prepares next steps within real clinical workflows.

The key shift is ownership — the system doesn’t just suggest; it helps execute.

How is agentic AI different from advisory AI?

Advisory AI only recommends actions and relies on humans to manually implement them.
Agentic AI can draft orders, update care plans, or prepare documentation — with clinician approval.

This reduces friction without removing human control.

Why is FHIR critical for agentic AI?

Agentic AI needs structured, real-time clinical context to act safely.
FHIR provides standardized access to that context and supports bidirectional workflows — reading data and writing actions back into the EHR.

Without FHIR, agentic AI remains isolated and unreliable.

How do CDS Hooks and SMART on FHIR enable agentic workflows?

CDS Hooks trigger AI at precise workflow moments, such as opening a chart or placing an order.
SMART on FHIR enables deeper interactions through embedded applications.

Together, they allow AI to integrate seamlessly into existing clinical workflows instead of creating parallel systems.

Who is accountable when an AI agent influences care?

Accountability remains with clinicians and healthcare organizations.
Agentic AI prepares and proposes actions, but humans review, approve, and remain responsible for clinical decisions.

Well-designed agentic systems reinforce — not replace — clinical accountability.