AI Agents for Hospitals and Health Systems

Five, in roughly this order, and the ordering is about organisational readiness rather than technical difficulty.

• Ambient documentation. The clearest first project. The baseline already exists in your EHR audit logs, the affected group is defined, and clinicians feel the difference within a fortnight. It is also the one where a bad rollout is most visible, which concentrates the mind usefully.
• Prior authorization. High volume, high friction, and staffed by people whose time you can cost precisely. Payer variability is the limiting factor, so scope it to your top three payers rather than all of them.
• Denial management. Systems have the claim volume that makes pattern work meaningful. This is the use case where scale is a genuine advantage rather than an overhead.
• Clinical inbox triage. Message volume has grown faster than the staffing model. Drafting replies for clinician approval is a defensible pattern; routing without review is not.
• Broader revenue cycle work. Worth doing after one of the above has proven that your governance path actually terminates in a signed contract.

What these share is a cash or hours baseline that finance already tracks. If the CFO cannot see the number today, they will not believe your improvement to it tomorrow.

The table below is our working view for a multi site system with a single dominant EHR. Effort assumes you have an integration team but must queue for it. Time to signal is time to a number a finance partner will accept, not time to a demo.

Two patterns fall out of it. The projects with the fastest signal are the ones where the agent drafts and a human approves. The projects with the largest theoretical payoff are the ones that cross the most departmental boundaries, which is exactly why they stall.

In systems we have worked with, the path from a service line asking for a tool to a signed contract runs one to three quarters. The elapsed time is dominated by waiting for committee dates, not by the reviews themselves.

The committees that matter are usually four: an AI or digital governance body that decides whether the use case is appropriate, security review that decides whether the vendor is safe to connect, privacy and legal who negotiate the business associate agreement, and clinical informatics who decide whether the workflow is real. Each meets monthly at best.

You can compress this in three ways, and only three. Run the reviews in parallel rather than in sequence, which mostly requires someone senior to say so out loud. Pre commit to a standard security questionnaire and a standard BAA addendum so the vendor is answering a known set rather than a bespoke one. And define the approval criteria before the demo, so the committee is deciding against a written standard instead of arguing about impressions.

What does not work is going around it. A department that buys a tool on a corporate card creates a shadow integration, an unsigned BAA and a problem that surfaces during the next audit. If your governance body does not yet exist in a usable form, building one is a project in its own right, and it is what our AI governance and compliance work is scoped to do.

This is the most expensive failure mode in the sector, and it is almost never a technology failure. The pilot works. The tool is liked. Eighteen months later it is switched off.

Four causes account for most of it.

• No production owner. The pilot was owned by a project manager whose project ended. Nobody inherited the escalation path, the template maintenance or the new starter onboarding.
• The budget was never in the operating plan. Pilot money is often one time innovation funding. Nobody put the recurring licence into the service line's base budget for the following year, so it appears as a new ask at exactly the wrong moment.
• No scaling criterion was written down. Without a pre agreed threshold, expansion becomes a fresh political negotiation instead of the execution of a prior decision.
• The measure was enthusiasm. Pilot volunteers are not representative. A tool that delights early adopters can be actively resented by the department that gets it next, and nobody planned for the difference.

The fix is unglamorous. Before the pilot starts, name the person who will own it in production, write the number that would justify expansion, and get the second year licence into the budget cycle that is happening now rather than the one after the pilot ends.

The HIPAA baseline applies to everyone, but three wrinkles are sharper at system scale.

Certified health IT obligations. If a predictive feature is delivered through your certified EHR, the transparency and risk management requirements introduced under the ONC HTI rules apply to that technology. Our HTI-1 and HTI-2 pages set out what has to be disclosed and by whom. This matters because a system is far more likely than a small practice to be consuming AI features embedded in the EHR itself, where the compliance obligation sits with the developer but the operational one sits with you.

Payer side rules that reshape your workflows. The CMS interoperability and prior authorization rule changes what impacted payers must support. Automation you build on top of today's portal based process may need reworking as those interfaces arrive, so scope prior authorization projects with that in mind.

Multi state footprints. A system operating across state lines inherits every applicable state AI law at once. Colorado, California, Utah and Texas have each legislated differently, and the practical answer is usually to build to the strictest of them rather than to maintain four configurations.

Start by being honest about what kind of return you are claiming. Hours saved are real, but they are not cash unless a position changes or throughput increases. A finance partner will accept an hours claim as a quality and retention argument and reject it as a savings argument, and they are right to. Revenue cycle use cases are easier here precisely because their return arrives as money.

On procurement, a system has leverage that it usually spends entirely on unit price. The clauses that matter more over three years are these: data use and whether your data trains the vendor's models, exit terms and what you get back in what format, service levels with a remedy attached rather than a credit, and a price protection clause covering renewal rather than only year one.

Ask for a paid proof of concept with a written success definition rather than a free pilot. Free pilots are staffed by the vendor's best people and tell you nothing about steady state support. A paid one with defined criteria tells you what year two feels like.

Finally, budget the internal cost. Interface work, training across shifts, template maintenance and the analyst time to actually measure the thing routinely exceed the licence in year one. If that number is not in the business case, the business case is fiction.

Take this seriously and early, because handled badly it does not slow a project, it ends one.

Where staff are represented, changes to how work is measured, assigned or staffed can carry notice or bargaining obligations under the collective bargaining agreement. That is a question for your labour relations team, and the time to ask it is while you are scoping, not after you have announced a go live date. The same applies to any tool whose output could plausibly feed a performance conversation, even if you have no intention of using it that way.

Beyond formal obligations, be direct about the question everyone is actually asking. Staff want to know whether this is about their evenings or about their jobs. An unanswered version of that question becomes the loudest voice in the room, and a stated answer, even an uncomfortable one, is easier to work with than a rumour.

Practically, that means saying at the outset what happens to the time the tool saves, committing that agent output is reviewed rather than acted on automatically, and giving clinical staff a real route to switch it off in an individual encounter. Adoption follows credibility, and credibility here is built out of commitments you can be held to.

Being specific about this is more useful than another list of opportunities, and it is where our advice most often differs from a vendor's.

• Triage acuity assignment without a clinician in the loop. The failure mode is asymmetric: a wrongly downgraded patient is a patient harm event, and no efficiency gain justifies carrying that risk autonomously.
• Final claim submission without coder review. Agents are good at proposing codes and poor at knowing when the documentation does not support them. Automating the proposal is sensible. Automating the signature is an audit exposure.
• Discharge and level of care decisions. These are consequential, contested and frequently appealed. Keep the human decision and the human name on it.
• Anything that denies or restricts care to a patient. Several states now legislate directly in this area, and the reputational exposure exceeds the operational gain by a wide margin.
• Unsupervised patient facing clinical advice. Scheduling, wayfinding and administrative questions are a reasonable scope. Symptom interpretation is not, unless it is a regulated device and you are prepared to treat it as one.

The common thread is reversibility. Automate the work where a mistake produces a corrected draft. Keep a human where a mistake produces a harmed patient or an unwindable financial event.

Pick one use case, one service line and one measurable baseline. Resist the portfolio instinct: systems that start four projects finish none of them properly, and the four compete for the same interface analyst.

Spend the first three weeks establishing the baseline rather than shortlisting vendors. Note completion times, inbox turnaround, prior authorization cycle days and denial rates by payer are all obtainable from systems you already run, and they are far more persuasive than a vendor's benchmark. Spend the next three weeks getting security, legal and informatics into the same written criteria. Only then talk to the market.

If you want an external read before committing budget, our AI readiness audit produces exactly that: which workflows are actually ready, where your integration queue will bite, and what your governance path will do to the timeline. The free AI readiness assessment is a shorter version you can run yourself first, and it is a reasonable way to decide whether the conversation is worth having at all. Systems with a large ambulatory footprint may also find our notes on urgent care and community health centers useful, since those sites usually sit on different constraints from the acute enterprise.