Feature Adoption Is Not an AI Strategy

In 2018 I watched a Stripe dashboard cross a million dollars in a single day.

I remember the feeling precisely, and it wasn't triumph. It was closer to vertigo, because I knew what the product was. It was fine. It was not a million-dollars-a-day kind of fine. We'd poured so much into acquisition that the dashboard had stopped describing our company and started describing our media budget.

The number was real. The number was also lying.

I thought about that dashboard when I read a Becker's piece this summer in which health system CIOs described success as adopting 75% of their EHR vendor's new AI enhancements. Adoption rate. As the metric. And I recognised that feeling immediately, because it's the same category of error: mistaking a number that goes up for a thing that's working.

Why isn't EHR vendor AI adoption the same as an AI strategy?

Because adoption rate measures how good a customer you are, not how capable your institution is. Those are different things and only one of them survives a deposition.

Dr Zain Khalpey made this case bluntly in his response on architectural sovereignty, and the line that stuck with me was about the 75%. Which 75%? Whose clinical priorities shaped those features? Who profits when the algorithm is wrong?

Nobody in that meeting is asking. They're optimising their position on a treadmill somebody else controls the speed of.

What does architectural sovereignty actually mean in practice?

It means separating the administrative layer from the intelligence layer, and holding different governance standards for each.

Your EHR is a system of record. It handles documentation, orders, billing, and it's genuinely good at that. Your AI infrastructure handles inference, prediction, and decision support. Those two things have different upgrade cadences, different validation requirements, and radically different accountability profiles. Bundling them because they happen to share a vendor isn't architecture. It's an abdication with a purchase order attached.

The test I'd apply is simple and slightly cruel. If your AI feature were disabled tomorrow, does your EHR still work? If the answer is no, you didn't buy a feature. You acquired a dependency.

Should hospitals self-host clinical AI models?

For anything touching sensitive PHI or influencing clinical decisions, yes, and the economics are less forbidding than most CIOs assume.

Reporting cited in JAMA perspective coverage suggests 79% of US hospitals now use EHR vendor AI models while 59% use third-party solutions, so most organisations have already made this governance choice without formally making it. On cost, the comparison in this self-hosted versus cloud AI analysis puts a mid-size deployment at roughly $60,000 to $80,000 upfront against $3,000 to $15,000 a month for cloud APIs, breaking even somewhere around 12 to 18 months and getting steadily cheaper after that.

But the money isn't the argument. The argument is that the moment your clinical data trains a vendor's model, you've handed over the most valuable asset you own. We built HANA fully open source and self-hosted with no external model dependency for exactly this reason, and it wasn't a philosophical decision. It was a liability decision.

Who is accountable when a bundled model is wrong?

You are. Always you. The vendor's BAA makes them contractually liable for their part, which is a much smaller part than most procurement teams realise.

A business associate agreement does not make a service compliant. It covers designated in-scope services, often excludes newly shipped AI features until they're formally added, and leaves you holding configuration, access control, audit logging, minimum-necessary discipline, and the actual clinical outcome. Meanwhile a silent model refresh can change how a tool summarises, codes, or triages, and if updates aren't versioned, testable, and roll-backable, the update mechanism itself has become your governance risk.

Set and forget is not a clinical AI strategy. Algorithms drift, populations shift, and a tool validated on last year's cohort is not automatically valid on this year's. We publish our own monitoring and outcomes methodology partly because I think every vendor should have to, and almost none do.

What should a health system own and what should it rent?

Own the layer that touches patients and clinical judgment. Rent the layer that touches documents.

Concretely: let the vendor handle note summarisation and inbox drafting, the low-risk workflow-native stuff where integration convenience genuinely wins. Own anything patient-facing, anything that feeds a decision, anything that would need defending. And whatever you rent, rent it behind a stable internal interface so you can swap the model without rebuilding the workflow, because the difference between a supplier and a captor is whether you can leave.

Then close the gap between the people who build the tools and the people who use them. The most dangerous configuration in clinical AI is the one where the engineers never watch the thing run on a real patient and the clinicians never saw how it was built. Our deployment case studies keep landing on the same finding: the programmes that work are the ones where a clinician can articulate what the system knows, what it doesn't, and where it will fail.

Key Takeaways

Feature adoption rate is the healthcare equivalent of my Stripe dashboard. It goes up, it feels like progress, and it tells you nothing about whether the underlying thing is sound. The system that deploys fewer, better-validated AI tools with real clinical governance behind each one will outperform the system with 90% feature adoption and a Gold Star, and it won't be close.

So separate your intelligence layer from your administrative layer and govern them differently. Own your data and watch it continuously, because drift is not a hypothetical. Keep your integration points narrow enough that you can substitute a model without rebuilding a workflow. And make sure somebody in your institution, a named human being, can explain what every deployed algorithm is doing and why. If nobody can, you don't have an AI programme. You have a vendor relationship and an exposure.

Frequently Asked Questions

Is EHR vendor AI a bad choice?

Not at all, for the right workloads. It's often the correct first move for low-risk, workflow-native tasks where rollout speed and integration fit matter most. The mistake is treating it as your AI strategy rather than one managed dependency inside a strategy you actually control.

Does self-hosting make us HIPAA compliant automatically?

No. Self-hosting removes the business associate relationship with an AI vendor and eliminates third-party data exposure, which is significant. You still owe the full Security Rule: access controls, encryption, audit logs, risk assessments, and workforce training. What changes is that the compliance surface is entirely yours to inspect rather than partly opaque.

What's the single best question to ask an AI vendor?

Ask what happens if the AI feature is switched off. If the core system stops working, you've found coupling risk that belongs in front of your board rather than buried in a procurement checklist. Follow it with whether you can pin model versions and whether your prompts and outputs train their broader systems.

If you're weighing build versus buy on the patient-facing layer and want to pressure-test the governance before committing budget, book time with me here. Bring your procurement team.