Written for the CIO and digital leader weighing an AI initiative, where the persuasive job is to redirect enthusiasm toward the unglamorous foundation before it's spent on a model demo. Deliberately avoids positioning WeHub as an AI platform; the product mention stays narrow and correctly scoped to in-workflow AI sitting on top of the data foundation, not replacing the argument for building one. UK-NHS market with the framing translatable elsewhere.
A clinical AI pilot ends quietly, the way most of them do. Not with a dramatic failure, but with a slow loss of confidence: the model's outputs drift, someone spots a case where two systems disagreed about a diagnosis code, and the project moves to "under review" and stays there. The vendor's model was competent. The data it was trained and run on wasn't ready for it, and nobody had defined what ready meant before the contract was signed.
This happens often enough in the NHS that it's worth stating plainly: AI initiatives succeed or fail on the data foundation underneath them, not on model choice. Getting that foundation right is an integration problem, and it has a specific, checkable shape.
In brief
"AI-ready" is not a data volume claim; it's a data quality claim, and it breaks into three properties. The data must be structurally consistent, meaning it arrives in a predictable shape rather than a different flavour per source system. It must be semantically bound, meaning coded values are anchored to known terminologies rather than free text or ungoverned local codes. And it must be traceable, meaning every value's origin and transformation history can be reconstructed when a model's output is questioned. None of this requires an organisation to become an AI company; it requires the integration layer to already be doing its job properly, because clean, standards-native, terminology-bound data is what AI-readiness actually looks like underneath the phrase.
The post-mortem that's always the same
Run the retrospective on enough stalled AI pilots and the pattern repeats. A model trained on data from one system performs unevenly when it meets data from another, because the two systems represented the same clinical concept differently and nobody normalised it. A summarisation tool produces a confidently wrong output because the free-text field it read from was inconsistently populated across departments. A classification model's recommendation gets challenged by a clinician, and the team discovers they can't reconstruct which source system the underlying value came from or what happened to it in transit.
Every one of these is a data engineering failure wearing an AI costume. The model did what models do: learn the patterns in what it was given. The problem was what it was given.
What "AI-ready" actually means
Strip the phrase of its marketing gloss and three properties do the real work.
Structural consistency. The same clinical concept needs to arrive in the same shape regardless of source system. An encounter is an encounter whether it came from the EPR or a departmental system; an observation has the same fields whether it originated in pathology or a bedside device. This is precisely the discipline FHIR imposes, which is why organisations serious about AI find themselves converging on FHIR resources as an internal data shape even before any AI initiative is named.
Semantic binding. A code without a governed terminology behind it is a label, not data. If two systems both record "diabetes" but one uses a local code and the other uses SNOMED CT, a model trained across both is learning noise disguised as signal. Terminology binding, meaning every coded field is anchored to a known code system and validated against an agreed value set, is what makes cross-system data actually comparable rather than superficially similar.
Traceability. When a model's output is questioned, and in a clinical context it will be, the organisation needs to answer where the underlying data came from, what transformed it, and when. Without a field-level record of that journey, "why did the model say that?" has no answer beyond "the training data said so," which satisfies nobody in a clinical governance meeting.
Structurally consistent: the FHIR argument
The case for FHIR as an internal data shape isn't really about interoperability with the outside world; it's about interoperability with yourself. A Trust with an EPR, three departmental systems and a data warehouse effectively has four different opinions about what a patient record looks like. Any model or analytics layer built across all four either has to reconcile those opinions itself, badly, or the organisation reconciles them once, upstream, by normalising into a consistent resource shape as data moves.
The second option is strictly better, because it means every future AI or analytics project inherits clean structure rather than re-solving the same normalisation problem from scratch. This is the practical argument for treating FHIR conversion as infrastructure rather than a project-specific task.
Semantically bound: the terminology argument
Structure alone isn't enough. Two Observation resources can be perfectly well-formed FHIR and still be semantically incompatible if their codes come from ungoverned sources. This is where terminology infrastructure earns its place: code systems as the dictionaries, value sets as the governed shortlists for each context, concept maps translating between systems that disagree. A platform like WeHub Term exists to host exactly this layer, so that a model consuming coded fields is consuming meaning that's been validated, not text that happens to look similar.
The practical test is simple. Pick a clinical concept your organisation cares about and ask how many different codes represent it across your systems today. If the honest answer is "several, and nobody's mapped them," that's the AI-readiness gap, and it exists before any model gets near the data.
Traceable: the governance argument
Traceability is the property people remember last and need most. In a clinical or research context, a model's output that can't be traced back to its source data is a liability, not an asset, because the question "why did it say that?" is not optional; it's the first thing a clinical safety review asks. Field-level lineage, meaning a record of what arrived, what was transformed, and what was written at every step of an integration, is what turns "we don't know" into an actual answer.
This is also, not coincidentally, the same audit trail that DSPT and information governance conversations already demand of a well-built integration layer. Organisations that have already invested in that traceability for compliance reasons discover they've quietly built most of what AI-readiness requires as well.
Where Trusts get this wrong
The most common mistake is treating AI-readiness as a separate initiative from integration maturity, staffed and funded separately, when it's really the same underlying investment viewed from a different angle. A close second is assuming that more data volume compensates for inconsistent structure; it doesn't, it just means the model learns the inconsistency at scale. And the quieter mistake is skipping terminology work because it's slow and unglamorous compared to a model demo, when terminology binding is precisely the part that determines whether a model's output means the same thing across two departments.
What AI-readiness looks like in practice
A genuinely AI-ready flow looks unremarkable from the outside, which is the point. Data lands from source systems in whatever native shape they produce. It's converted to a consistent internal resource model, most practically FHIR, as a standing capability rather than a one-off project. Coded fields are validated and bound to governed value sets as they pass through, with a concept map applied wherever two systems' vocabularies disagree. Every step is logged at the field level, so provenance is a query away rather than an investigation. Only then does a model, whether it's doing summarisation, classification, or anything else, meet the data, and by that point most of the interesting problems have already been solved by the integration layer rather than left for the model to paper over.
WeHub's own position here is deliberately narrow: AI operating inside workflows for tasks like summarisation, generation and classification, sitting on top of exactly this foundation, rather than an attempt to be an AI platform in its own right. The foundation is the part worth investing in regardless of which model an organisation eventually chooses.
The bottom line
AI initiatives on NHS data don't fail because the models are bad. They fail because the data underneath was never made structurally consistent, semantically bound and traceable before a model was asked to learn from it or act on it. That's not an AI project; it's the integration and terminology work a well-run Trust should be doing regardless of any AI ambition. Before the next AI pilot gets funded, ask the three questions this piece is built around: is the data structurally consistent, is it semantically bound, and can you trace it. Wherever the answer is no, that's this quarter's actual AI project.
