Beyond FHIR: Why Healthcare Automation Needs Workflow Orchestration, Not Just Interoperability

For the better part of a decade, “healthcare interoperability” has been treated as the finish line. FHIR APIs, HL7 v2 feeds, CommonWell, Carequality – an enormous amount of engineering effort has gone into making sure that clinical data can move between systems. And it’s worked. A referral can carry structured patient data. A payer can query a clinical data repository. An EHR can expose a FHIR endpoint that a third-party app can read from and write to.

But here’s the uncomfortable truth most healthcare IT teams eventually run into: getting the data to move is not the same as getting the work done.

The gap after the API call succeeds

Consider a referral. FHIR interoperability gets you a ServiceRequest resource landing cleanly in a specialist’s system, fully structured, with the right patient identifiers attached. That’s a real achievement. But now what?

• Someone still has to notice the referral arrived.
• Someone still has to check whether the clinical documentation is complete.
• Someone still has to determine urgency.
• Someone still has to decide whether prior authorization is needed before scheduling.
• Someone still has to follow up if the receiving provider doesn’t respond in a reasonable window.
• Someone still has to keep a record of who decided what, and when.

None of that is an interoperability problem. The data already arrived. What’s missing is the process that turns “data has arrived” into “the right next action happens, and is tracked to completion.” That’s orchestration, and it’s a fundamentally different engineering problem than data exchange.

Interoperability answers “can the data move.” Orchestration answers “what happens next.”

It’s worth being precise about the distinction, because the two get conflated constantly in vendor marketing:

Interoperability is about format and access: can System A read a structured, standards-compliant representation of something System B holds? FHIR, HL7v2, and X12 all live here. The output of good interoperability is availability – the right data, in the right shape, in the right place.

Orchestration is about behavior over time: given that data is now available, what sequence of steps, decisions, and approvals needs to happen, by whom, in what order, with what fallback if a step fails or times out? This is a workflow engine’s job – modeling states, transitions, retries, and human checkpoints – and it’s largely indifferent to how the underlying data got there.

You can have perfect interoperability and zero orchestration. That’s most healthcare software today: data flows beautifully between systems, and then it sits in an inbox, a worklist, or a fax queue waiting for a person to notice it, interpret it, and manually push it to the next step. The bottleneck moved from “can the systems talk” to “who notices, and how fast.”

Why this matters more now, with AI in the picture

This distinction becomes sharper – and more consequential – as AI enters the picture. It’s tempting to think “we’ll just bolt an LLM onto the referral inbox and have it draft a summary,” and treat that as automation. But a single AI call is not a workflow. It’s a point capability, and point capabilities without orchestration produce the same failure mode as pre-AI healthcare IT: something smart happens once, in isolation, and then the output sits there waiting for a human to notice it and manually carry it forward.

Real automation requires answering questions an AI call alone doesn’t answer:

• What triggers the AI analysis in the first place – an event, a schedule, a manual action?
• What happens if the AI’s output is incomplete or malformed?
• Who needs to review it, and what happens if they don’t within a defined window?
• What’s the audit trail if that review approves, edits, or rejects the recommendation?
• How does approval translate into an actual downstream action – and how is that tracked?

These are workflow engine questions, not model questions. And they’re exactly the questions that determine whether an AI-in-healthcare project becomes a genuinely useful piece of infrastructure or a demo that never survives contact with a real operations team.

Orchestration also solves a trust problem interoperability can’t

There’s a second reason orchestration matters specifically in healthcare: interoperability alone offers no natural place for human oversight. A FHIR resource moving from System A to System B doesn’t pause anywhere for a clinician to sanity-check it – it’s just data in transit. If you then attach an AI recommendation directly onto that data flow without an orchestration layer, you’ve created a system where AI output can silently become action with no defined approval boundary.

A workflow engine, by contrast, is built around states and transitions – which makes “pause here for human approval” a first-class, structurally enforced step rather than a hopeful convention. AWAITING_APPROVAL isn’t a UI label; it’s a state the workflow literally cannot exit without a recorded human decision. That structural property is what lets you deploy AI in healthcare operations without asking anyone to simply trust the model.

What this means practically

If your organization has invested heavily in interoperability – FHIR compliance, data warehouses, clean patient matching – that work isn’t wasted. It’s the substrate orchestration that needs to function. But it’s a mistake to treat “we can now access the data” as equivalent to “we’ve automated the workflow.” The next layer of value in healthcare technology isn’t going to come from moving data faster or in more standard formats. It’s going to come from reliably, auditable, and safely orchestrating what happens once the data is available – with AI handling the analytical and drafting work, and a well-designed engine ensuring a human stays structurally in control of every consequential action.

Interoperability got healthcare data unstuck. Orchestration is what gets healthcare work unstuck. They’re both necessary, and neither substitutes for the other.