Every health system, lab, and community organization we talk to is wrestling with the same question: what are we doing with AI?

The honest answer, for most organizations, is that the AI question is really a data question wearing a different hat. Ambient documentation tools, risk stratification models, prior authorization automation, and clinical decision support all share a single dependency. They need clean, complete, current, correctly attributed data to get the best results. When an AI pilot project underperforms it is sometimes due to the model chosen, but often it is a lack of complete, clean data to feed the AI processes.

After more than 25 years building healthcare interfaces, we have seen some of the same patterns repeat through each technology wave. Organizations invest in the destination and underfund the plumbing. AI raises the stakes, because in the past a poorly built process that resulted in an incorrect report was easily caught, due to the high-touch processes and human involvement of traditional methods. These days, AI models can produce a confident, well-formatted, plausible-sounding recommendation built with incomplete data that nobody notices is completely wrong.

What AI-ready clinical data actually means

The phrase gets used loosely, so it is worth defining. Clinical data is AI-ready when it has six properties.

• Complete. The record contains the elements the use case requires, not just the elements that happened to flow through an existing interface. A readmission model built on ADT feeds alone is guessing about medication adherence and social context.
• Normalized. Codes, units, and value sets are consistent across sources. If one lab sends results in mg/dL and another sends mmol/L, and nothing reconciles them, the model learns noise instead of structure.
• Identity-resolved. Every record is attached to the right person. Duplicate and fragmented records are among the quietest and most damaging data quality problems in healthcare because the resulting analysis looks fine, but the results can be not just wasteful, but fatal.
• Timely. The data arrives within the window where a decision can still be influenced. A nightly batch can be adequate for reporting, but useless for real-time alerting and critical decision-making.
• Contextual. Clinical data alone describes what happened inside the four walls. It does not explain why a patient missed three appointments. Housing, transportation, food security, and benefit status live in other systems entirely.
• Governed. Consent, minimum necessary access, provenance, and auditability must be enforced before data reaches a model, not bolted on after a compliance review.

Miss any one of these and the output degrades. Miss identity resolution or governance, and the output becomes a liability.

Where clinical data breaks down before it reaches AI

In practice, the gap between “we have the data” and “the data is usable” comes down to a handful of recurring failure points.

• Format sprawl. A typical mid-sized organization is moving HL7 v2 messages, likely also an older format or CDA feed, CCD documents, X12 transactions, NCPDP pharmacy data, a few ODBC database pulls, and maybe even an old delimited file or report that somebody set up years ago and nobody wants to touch today. Each format carries its own assumptions about structure and required fields.
• Point-to-point interface debt. Interfaces built one at a time, system to system, create a web with no central place to inspect data quality. When a downstream AI tool returns something strange, tracing it back through a mesh of direct connections takes days.
• Free text where structure should be. Critical information often sits in notes and comment fields because the sending system had nowhere else to put it. Large language models are good at reading unstructured text, which creates a temptation to skip normalization entirely. That works until the model needs to compute rather than summarize.
• Silent identity fragmentation. The same person exists as four unique records across the EHR, the lab system, the referral platform, and the community partner’s case management tool. No error is thrown. The data simply describes four people with partial histories.
• Latency mismatch. Batch-oriented pipelines were designed for retrospective reporting, while real-time AI applications need event-driven delivery.
• Missing social context. Health-related social needs drive a large share of utilization and outcomes, and almost none of that data lives in the clinical record. It lives in housing authorities, food banks, transportation providers, workforce programs, and 211 systems.

The integration layer powers the AI layer

This is the part that often gets missed. If your AI strategy does not include an integration strategy, you do not have an AI strategy.

An integration engine sitting between source systems and analytics destinations does the work that makes AI viable. It translates between standards, so HL7 v2, FHIR R4, CCD, X12, and flat files all arrive in a consistent, AI-ingestible format. It applies normalization and mapping rules in one place, so a value set correction is made once instead of in six downstream tools. It routes messages by content and condition, so the right data reaches the right system without a new custom build. It monitors every transaction, so when data quality drifts, somebody sees it in a dashboard rather than discovering it in a model output three weeks later.

That last point matters more than it sounds. Observability at the interface layer is one of the most cost-effective AI safety controls available. If organizations can see message volumes, rejection rates, and field-level completeness by source, they can catch a feed that started dropping a segment before it corrupts anything that a clinician sees.

This is the role HEMI plays for our customers. It is a configuration-driven engine, so interface changes are made through the administrative portal rather than through a development cycle, and standard interfaces are typically deployed in days or weeks rather than months and months. The value for AI readiness is not just speed, it is that the transformation logic lives somewhere inspectable, versioned, and centrally governed.

A practical AI readiness checklist for clinical data

If you are being asked to prepare for AI and want a sequence that does not require starting at zero, start here instead.

1. Inventory your interfaces. List every feed, its format, its owner, its update frequency, and whether anyone monitors it.
2. Measure duplication. Run a match analysis across two or three of the largest person-level data sources and find out what the real duplicate rate is.
3. Centralize transformation. Move mapping and normalization logic out of individual point-to-point connections and into one governed layer.
4. Instrument data quality. Track volume, rejection rate, and field completeness by source, with alerting on drift.
5. Make consent structured. Capture consent state as data, carried with the record, enforceable at access time.
6. Close the latency gap for one use case. Pick a single real-time need and prove event-driven delivery before re-architecting everything.
7. Document provenance. For any dataset feeding a model, know where each field originated and what transformations were applied.

None of these steps require an AI vendor. All of them make every future AI decision safer and more cost-effective.

The uncomfortable summary

AI does not fix data problems. It industrializes them. A flawed dataset used to produce a flawed spreadsheet that a skeptical analyst questioned. A flawed dataset now produces AI output that carries the authority of a system, at volume, in front of people making care decisions.

The organizations that will get real value from clinical AI are the ones treating integration, identity, and governance as the actual project. The model is the easy part to buy. The data foundation is the part you have to build.