Reference Check Questions to Ask a Healthcare AI Vendor's Existing Clients

A vendor demo shows what the product looks like when everything works. A reference call shows what happens when something doesn't work. That's the whole reason reference checks exist, and it's also why most of them fail: the questions asked are too polite, too general, and too easily answered with a demo-quality response instead of an operational one.

Vendor Demos and Deployment Viability Questions

Healthcare AI procurement carries a different weight than most enterprise software decisions. An error in a marketing automation tool wastes a campaign. An error in a healthcare AI agent touches patient care, creates a PHI exposure with real legal consequences, and often can't be undone once a workflow has already shifted staff behavior around it. Once staff reorganize their workflows around an agent, reverting isn't a quiet rollback, it means undoing behavioral habits that took months to build.

Demos are built to show the best-case path. They walk a clean claim through a clean system with no interface changes, no ambiguous documentation, no payer portal redesign mid-workflow. What a demo cannot show is what happens when a payer changes a form field, when a claim batch fails without an alert, or when staff quietly stop trusting the tool and start double-checking its work. Whether a deployment succeeds is determined after go-live, when a payer changes a form field, when a claim batch fails without an alert, or when staff quietly stop trusting the tool and start double-checking its work.

The scale of this gap is documented: sixty-three percent of healthcare organizations report using AI or automation somewhere in the revenue cycle, yet only 15% report positive ROI from it. Sixty-three percent of healthcare organizations report using AI or automation somewhere in the revenue cycle, yet only 15% report positive ROI from it. That's a wide gap between adoption and return, and it's exactly the gap a good reference call is built to diagnose. Three failure modes tend to explain it: go-live timelines that ran longer than promised, change management that got dumped on the practice instead of the vendor, and edge cases that never got a real answer.

Questions about how long go-live took and what drove the gap

The single most diagnostic gap in healthcare AI procurement sits between what a vendor promises at contract signing and what a reference client actually experienced. Ask for both dates directly: what was the stated go-live timeline, and what was the actual date the first live workflow ran unattended?

Then ask what caused the difference. Integration complexity, staff readiness, credentialing delays, a BAA negotiation that ran far longer than anticipated, these are all common and none of them are damning on their own. What matters is whether the vendor anticipated them or got surprised by them. If a vendor claimed a no-integration deployment and the reference client describes IT tickets, API access requests, or EHR reconfiguration work that wasn't scoped upfront, flag that loudly.

Push further on one specific number: how many weeks passed before the tool ran without daily vendor hand-holding. A system can be technically "live" on day one and still require a vendor engineer checking in every morning for two months. That's an extended pilot with a signed contract attached, not deployment. Reference clients who answer with specific weeks and specific causes have lived the deployment. Clients who answer in vague terms, "it took a little longer than expected," probably haven't thought hard about it, or don't want to say more.

Questions about what happens when systems change unexpectedly

Payer portals redesign their interfaces. EHR vendors push updates. Prior authorization forms get new required fields. None of this happens on a schedule, and none of it comes with advance warning to whatever AI agent has been reading those screens for the past year.

This matters most for agents that operate by reading and clicking through interfaces the way a human would, rather than connecting through a stable API. Computer-use agents are documented in the research literature as being sensitive to a button that moves or a field that gets renamed, and the agent can fail silently or, worse, take the wrong action with confidence. Silent failure is the dangerous case, because a downstream problem occurs before anyone notices.

Ask reference clients directly whether a payer portal update or EHR change has broken a live workflow since go-live, and what happened next. Who caught it first, the vendor's monitoring or a staff member noticing a backlog? How long did restoration take, and what happened to the work that queued up during the outage? Does the vendor own ongoing configuration maintenance, or does that responsibility quietly shift to the client's IT team after go-live, buried in a contract clause nobody read closely?

The strongest answers describe who caught the failure first, how quickly the configuration was restored, and whether that restoration work fell to the vendor or to the client's own IT team.

Questions about how the agent handles errors, exceptions, and edge cases

"Works 95% of the time" sounds impressive until you ask what's inside the other 5%. In healthcare, that 5% might be a missed prior authorization, a misrouted referral, or a claim that goes out with the wrong code. The failure rate's composition affects what fails and how severely: in healthcare, that 5% might be a missed prior authorization, a misrouted referral, or a claim that goes out with the wrong code.

Research on long-horizon computer-use agents backs this up. The OS-Marathon benchmark found that leading agents struggle substantially on vast-horizon, repetitive tasks: errors accumulate across subtasks, and simply breaking a big task into smaller ones doesn't stop those errors from propagating downstream. An agent that's highly accurate on any single step can compound that error across a twenty-step workflow into something far less reliable by the end.

So ask what the agent actually does when it hits something it can't resolve, an unexpected portal state, a missing document, an ambiguous field. Does it stop and flag a human, take a best guess and move on, or log the failure somewhere nobody checks? Ask how escalation physically reaches a person: does it come as an alert, a task queue, or an email, or does the work just sit there until someone happens to look. Ask whether an audit log exists for every action the agent took on a given task, including the failed attempts, not just the successful ones.

The strongest signal in a reference call is a specific story. A reference client who can describe one real escalation event, what triggered it, how it reached a human, how it got resolved, has proven the escalation pathway actually exists. A client who can only describe the pathway in the abstract probably hasn't tested it under pressure.

Questions about staff adoption and whether the tool added monitoring work instead of eliminating it

The ROI gap mentioned earlier, 63% adoption against 15% positive return, has a common root cause: staff keep monitoring the agent instead of handing the task off to it. The tool runs, technically, but someone still checks its work line by line. The labor cost never actually dropped.

Ask when the tool went live, did staff stop doing the task, or did they keep doing it in parallel as a safety check? How long before the team trusted the output enough to stop reviewing every single item? Did the vendor bring an actual change-management plan to the table, or was adoption left entirely to the practice to figure out on its own, one frustrated staff meeting at a time?

There's a meaningful difference between a tool that drafts or recommends, requiring a human to review before acting, and a tool that executes autonomously, requiring a human only for exceptions. Ask the reference client directly which mode they're actually operating in today, not which mode was pitched at signing. Those are two very different labor models, and vendors sometimes blur the line between them in a sales conversation.

Scheduling AI offers a useful comparison point. Adoption among hospitals jumped from 51% to 67% between 2023 and 2024, a sharp rise by any measure. But adoption numbers alone say nothing about whether staff actually handed the scheduling work off or just added a new oversight layer on top of what they were already doing. Adoption and workload reduction are not the same metric, and a reference call should never conflate them.

Questions about HIPAA compliance, BAA terms, and how PHI is handled inside the agent

Any vendor touching PHI is a business associate under HIPAA, and a signed BAA is the floor, not the finish line. What actually matters is the language inside that BAA: can client data be used to train the vendor's models, what the breach notification timeline looks like, and what audit rights the client retains.

This has gotten sharper with the proposed 2025 HIPAA Security Rule amendments, put forward by HHS OCR on January 6, 2025, the first major update to the Security Rule in roughly twelve years. The proposal removes the "addressable" designation for encryption. Every PHI data path an agent touches, including temporary storage and inference pipelines, would need validated cryptographic encryption rather than encryption-if-convenient. The same proposal would require a written inventory of every AI system that creates, receives, or transmits ePHI. Ask reference clients directly whether the vendor helped build that inventory or left the client to assemble it alone.

Beyond the BAA language itself, ask about third-party audits: has the vendor completed a SOC 2 Type II audit, and did they share the actual report or only a certification letter (the letter alone tells you almost nothing). Ask whether the vendor has ever had a breach or security incident involving client data, and how quickly it was reported. Ask how the agent handles minimum necessary access, does it pull only the specific fields required for its task, or does it operate with broad standing access to the record. Broad access isn't automatically disqualifying, but it's a materially different risk profile, and a reference client should be able to describe which one they're living with.

Questions about revenue cycle and denial outcomes and how the vendor measured them

Denial rates averaged 11.8% in 2024 and climbed to roughly 12% in 2025, with net revenue leakage from denials growing substantially year-over-year. Denial reduction is one of the most common promises in healthcare AI sales conversations, and one of the hardest to verify, because the baseline measurement often gets skipped or gets set after the fact to flatter the result.

An HFMA/FinThrive survey found that only 14% of providers use AI specifically for denial reduction, despite 41% of providers reporting denial rates of 10% or higher. That gap matters for reference calls: most clients a vendor offers up as references will not have a mature denial-reduction program running, so it's worth specifically asking for one that does.

Start with the baseline question: what was the clean claim rate before deployment, and did the vendor establish that number before go-live, or is the comparison being made against a rough guess after the fact? Ask whether the tool predicts denials prospectively, catching problems before the claim goes out, or retrospectively, flagging them after the denial already landed, and ask which mode the client is actually using day to day. Ask whether the denial ruleset updates as payer behavior shifts, or if it's static and needs manual rebuilding every time a payer changes its criteria. And ask about the ramp: what did the denial rate look like at 90 days versus six months, because a tool that shows no early improvement but a real one by month six is a very different product than one that never improves at all.

The strongest reference answer includes a measurable clean claim rate improvement inside the first six months, a denial ruleset the vendor actively maintains, and KPIs that were agreed on before go-live rather than selected afterward to match whatever number came in.

Questions about how end-to-end workflow automation performed versus single-task automation

A prior authorization approval that lands in a dashboard and waits for someone to notice it has automated one step. A prior authorization approval that automatically triggers patient outreach and books the appointment has compressed the entire cycle. Those are two very different products wearing the same marketing language, and the difference appears when you ask about the seams.

Ask which specific steps run end-to-end without a human touch, and where exactly a person still has to step in to move the task forward. Ask whether the agent operates across every system the workflow touches, the EHR, the payer portal, the scheduling platform, the patient communication tool, or if it's confined to just one of them while humans bridge the rest. When a handoff to a human does happen mid-workflow, ask how much context comes with it: does the person receive enough information to act immediately, or do they have to re-investigate the task from scratch, which erases most of the time savings anyway.

Ask whether the vendor has expanded automation to additional steps since go-live or whether the scope has stayed frozen exactly as contracted. And ask for a number: what percentage of workflow volume runs fully automated today, versus how much still needs a human touchpoint somewhere in the chain.

One useful reference point for what end-to-end coverage looks like at real scale: one reported implementation handled close to two million patient conversations across multiple workflow categories. Ask a prospective vendor's references to compare themselves against that kind of volume and category breadth, even loosely. Push reference clients to describe the workflow before and after in plain operational terms, not vendor language, and listen closely for exactly where the human steps still sit.

Questions about multi-location or portfolio-scale performance, what works in one site may not scale

A vendor's success story at a single-specialty, single-location practice says almost nothing about what happens when a private-equity-backed group with dozens of locations, multiple EHR instances, and a mixed payer book tries to deploy the same product. Scale changes the problem, and it changes it in ways that a single glowing reference can hide.

Ask whether the vendor rolled out across multiple locations simultaneously or sequentially, and what drove that choice, sequencing usually reveals where the vendor expected trouble. Ask whether performance varied meaningfully by site, different specialty mix, different EHR version, different payer contracts, and how the vendor adjusted for that variation rather than applying one template everywhere and hoping it held.

Ask directly whether workflow configuration is managed as one uniform template across every site or maintained separately per location, because a rigid one-size-fits-all setup tends to underperform the moment a portfolio has any real variation in it. And ask what governance actually exists at the portfolio level: can a central operations team see performance across every site from one dashboard, or is each location its own island with its own vendor relationship and its own separate set of problems to solve. A reference client running one location well is a data point. A reference client running fifteen locations well, with the variation to prove it, is the answer worth trusting.