The Short Answer
Prior authorization, medical coding, and care coordination are multi-step processes with approval gates and failure branches, not single questions — so a chat window cannot express them, which is why hospital AI pilots that demo well stall at production. The unit of deployment has to be a governed pipeline. On ibl.ai you own all the code and the data, so those pipelines run inside the hospital perimeter where PHI already lives.
The model is almost never what fails. What fails is that the thing being automated has eight steps and the interface has one.
Why does chat break down on clinical administrative work?
Chat breaks down because a conversation carries no structure, and clinical administrative work is almost entirely structure.
Prior authorization is a worked example.
The actual process is: verify eligibility and benefits, retrieve the supporting clinical documentation, check it against the payer's medical-necessity criteria, assemble a submission with the correct CPT and ICD-10 codes, submit it, monitor the status, escalate against a deadline, and draft an appeal if it is denied.
That is eight steps, at least two points where a human must sign off, and several branches where it fails in ways that require different handling — a missing document is not the same problem as a payer timeout.
A chat interface handles any one of those steps well.
What it cannot do is hold state across all eight, guarantee that submission never happens without the required review, retry a step that failed for a transient reason, or produce a record of which evidence supported which decision.
Medical coding and care coordination have the same shape. So does most of what happens between a patient arriving and a provider being paid.
Why do pilots succeed and production deployments stall?
Pilots succeed because they test the one step chat is good at, and production stalls because it asks for the other seven.
The demo is almost always generation: the model drafts an appeal letter, summarises a chart, suggests a code. It does this well, everyone is impressed, and the project gets funded on the strength of it.
Production then asks the questions the demo never touched. Who approved this submission, and is that approval recorded? What happens when the payer portal times out at step six — does someone find out, or does the case silently age past its deadline?
Which documents did the model actually use, and can we produce them if the denial is contested?
None of those are model questions. They are workflow questions, and the pilot had nowhere to put them because a conversation has no place to express a retry policy or an approval gate.
This is the same failure we described from the financial angle in why healthcare AI should start in the billing office — where roughly 65% of denied claims are never appealed despite about 54% of appeals succeeding.
The economics are compelling and the deployments still stall, because the work is a pipeline and the tool was a chat box.
What does a governed pipeline have to express?
A governed pipeline has to express the things a transcript cannot: sequence, branching, gates, and evidence.
Sequence and state. Each step knows what the previous steps produced. A case in progress has a position, not just a history.
Branches and loops. Different failures take different paths, and some steps repeat — polling a payer for status is a loop with a deadline, not a single call.
Guardrail checks. Conditions evaluated inside the run, not left to the model's discretion. Whether a submission meets documentation requirements is a check, not a suggestion.
Explicit human approval steps. A named point where a person signs off, recorded as part of the run. This is the difference between "a human reviewed it" as a policy and as a fact you can produce.
A validated structure. A workflow that is structurally broken should be refused before it runs, not discovered mid-case.
That last property is the one most easily skipped and most costly to skip, because a malformed pipeline in clinical administration fails against a deadline that has legal and financial consequences.
How ibl.ai gives an agent structure
ibl.ai provides two complementary structures — Projects and Workflows — because the problem has two halves.
Projects give a body of work its own document set, standing instructions, and assigned agents, so every conversation started from that project carries the same context. Project files each carry a refresh interval, a visibility setting, and an active switch, and several agents can share one project when the work spans more than one specialism.
Workflows lay a multi-step agent run out as a graph — branches, loops, guardrail checks, and human approval steps. Publishing validates the graph before promoting it to the running version, so a structurally broken workflow is refused rather than shipped.
The division matters.
A Project answers "what does the agent know and stand for on this work." A Workflow answers "what happens, in what order, with which gates." Prior authorization needs both: the payer criteria and documentation standards as project context, and the eight-step submission-and-appeal path as a validated graph.
Why does this have to run inside the hospital perimeter?
It has to run inside the perimeter because every step in these pipelines touches protected health information, and a pipeline moves more of it than a chat does.
A single chat exchange sends one prompt. A prior-auth pipeline retrieves the chart, reads the clinical notes, assembles the documentation, and writes an appeal citing specific findings — repeatedly, across every case, automatically.
If that runs against a vendor endpoint, the volume and sensitivity of the transfer is materially larger than the pilot ever demonstrated, and the business associate agreement, vendor security assessment, and data-residency review scale accordingly.
Running the pipeline where the PHI already lives removes the transfer instead of documenting it. The architecture question collapses from "is every one of these transfers justified and contracted" to "the data did not leave."
The cost shape points the same way.
Per-seat licensing at roughly $30–60 per user per month bills every coder, biller, and revenue cycle analyst whether or not a pipeline ran that day, so a 2,000-person health system pays $60,000–120,000 a month on an axis unrelated to case volume.
Pipeline work does not behave like headcount. It behaves like claim count — which is why usage-based or owned infrastructure tracks it and per-seat licensing cannot. Each denied claim already carries $25–$118 of administrative cost before anyone decides whether to appeal it.
On ibl.ai you own all the code and the data, run it model-agnostic across any LLM, and pay with no per-seat pricing — so you can deploy anywhere, including a fully air-gapped network. 1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University.
ibl.ai is family-owned and operated from New York, NY — a U.S.-headquartered, domestically-owned long-term partner, not a vendor that sells licenses and moves on. For the deployment posture in a clinical setting, see our air-gapped clinical AI platform overview.
Frequently asked questions
Does a pipeline remove the clinician or coder from the process?
No. A well-built pipeline makes the human step explicit and recorded rather than implicit and assumed. The reviewer validates assembled work instead of building it, which is what changes the economics.
Is chat useless for clinical work?
Not at all — it is the right interface for a single question against known context. The mistake is using it as the unit of deployment for a process that has sequence, gates, and failure branches.
Where should a health system start?
With one process that has a clear owner and a measurable baseline. Denial appeals are a good candidate because the current write-off volume is already countable, so the value of the pipeline is quantifiable before it is built.
The bottom line
Hospital AI pilots do not usually fail on model quality. They fail because the work is a pipeline and the pilot was a conversation, and nothing in a conversation can hold an approval gate, a retry, or an audit trail.
Make the pipeline the unit of deployment, validate it before it runs, and keep it inside the perimeter where the PHI already is. The model was never the hard part.