An organization we work with had just licensed a tool marketed as AI-powered risk prediction, and the care management director was walking us through it. It ranked patients by predicted likelihood of hospitalization in the next 30 days based on a variety of factors & customized the outreach based on different indicators we knew about the patient.

I asked her to walk me through the top five names. On the third one, she stopped. That patient had been admitted three weeks earlier, discharged, and was recovering at home with a home health nurse checking in twice a week. The model had flagged him as high risk for a readmission.

The tool wasn't broken. It was doing exactly what it was built to do: score patients based on the data it had access to. The problem was the claims feed it was reading from ran on a six-week lag, so the model was making predictions off a clinical picture that was already out of date by the time anyone saw the list. The output looked like foresight and was actually old news dressed up as a prediction.

"AI-Powered Decision Support" Is Doing a Lot of Work in That Phrase

Every vendor conversation I sit in right now uses some version of this term, and it rarely means the same thing twice. In practice, what gets sold under this label breaks down into three distinct capabilities, and each one requires a different kind of data foundation to actually work.

Prioritization and scoring. This is risk stratification, readmission prediction, and rising-risk identification: models that rank your patient population so your limited care management capacity goes to the people who need it most. This is the category my care management director's tool falls into, and it is only as good as the recency and completeness of the data feeding it.

Extraction and generation. This is a model reading unstructured clinical documentation and turning it into structured output: pulling HCC coding opportunities out of visit notes, generating a payer-required data submission from EMR fields, drafting a quality measure gap summary. I've watched this exact use case play out with a client whose staff member spent a meaningful chunk of every week manually pulling chart data into a document format a payer required. The data existed in the EMR the entire time. What was missing was the infrastructure to extract and format it automatically. That is decision support in its most literal form: turning a manual judgment task into a generated document a human reviews instead of builds from scratch.

Next-best-action prompts. This is the category most vendor demos lead with because it demos well: a care manager opens a chart and gets a suggestion for what to do next, informed by the patient's full data picture. It is also the category with the least room for error, because a bad suggestion delivered with confidence at the point of care is worse than no suggestion at all.

Three very different capabilities, marketed under one umbrella term, each requiring a different level of data maturity to actually deliver value instead of noise.

The Foundation Question Underneath All Three

I've written before about why most primary care data infrastructure is not ready for the AI layer everyone wants to bolt on top of it, and that argument holds here too, but the specific failure mode is worth naming for decision support specifically.

A scoring model is only as current as its inputs. If your claims data runs on a lag, your risk scores are describing the recent past, not the present, no matter how sophisticated the underlying model is.

An extraction tool is only as good as your documentation consistency. If three providers at three clinic sites document the same clinical concept three different ways, the extraction either misses two of them or standardizes something that was never actually equivalent.

A next-best-action prompt is only as trustworthy as the completeness of the record it's reading. A recommendation built on a partial clinical picture, delivered with the same confidence as one built on a complete picture, teaches your care team to stop trusting the prompts. Once that trust breaks, the tool gets ignored, and you've spent the licensing fee on a feature nobody uses.

None of this is an argument against decision support. It's an argument for sequencing. The organizations that get real value from these tools are the ones who built the reconciled, current, well-governed data environment first and layered decision support on top of it, not the ones who bought the tool hoping it would compensate for a foundation that wasn't there yet.

Three Questions Worth Asking Before You Buy

When a vendor pitches AI-powered decision support, three questions cut through most of the marketing quickly.

What is the actual latency between when something happens in the clinical or claims record and when your model sees it? A model reading six-week-old claims data is not predicting anything. It's reporting.

What happens when the underlying data is incomplete for a given patient? Does the tool flag the gap, or does it generate a score or a recommendation anyway, with the same apparent confidence as a patient with a complete record?

Who owns the logic once it's deployed? If your contract's risk model changes, or a new quality measure requires a new input, can your team update the tool's logic directly, or does that go through the vendor's development queue?

Vendors with a real answer to all three are worth a serious look. Vendors who answer with a demo instead of a direct response are telling you something too.

Decision Support Built on Infrastructure You Own

The version of this that actually works is decision support built as a layer on top of a data environment your organization already owns and controls, not a standalone product sitting on top of whatever data happens to be available to it.

When the underlying infrastructure is yours, the scoring logic can be built around your specific contract's risk model instead of a generic one calibrated to an average population. The extraction rules can be tuned to how your specific providers actually document, instead of a one-size-fits-all template. And when something needs to change, whether that's a new payer requirement or a documentation pattern the model is missing, your team makes the change directly instead of filing a request and waiting for a vendor's roadmap to catch up.

That's the difference between AI as a feature you're renting and AI as a capability built into infrastructure that's actually yours.

DAXHS builds decision support as an extension of the data infrastructure we build for each client, sized and tuned to their specific contracts and clinical workflows, not licensed as a generic model layered on top of someone else's platform. Our VBC Readiness Assessment is a structured two-week diagnostic engagement: a working session with your leadership and data team, a review of your current EMR and analytics environment, and a written report with findings and a prioritized roadmap. If you're evaluating an AI tool right now, that assessment will tell you whether your data foundation is ready for it.