Most stalled AI programs in healthcare are not model failures. They are “meaning” failures.

The pattern is familiar by now. A decade goes into collecting everything. Then a model is handed ten years of unformatted, inconsistent fragments and asked to read between the lines. The data got bigger. The clarity did not. Plenty of teams read that as evidence the technology has peaked. We read it as evidence that almost nobody did the actual work first.

Healthcare is the extreme case, which makes it a good place to show what the actual work is.

What arrives in a month

Here is the intake of one mid-sized Value-Based Care organization, in a single month.

  1. Clinical extracts from two or three EMRs, each with its own idea of what a problem list is and when a diagnosis becomes historical.
  2. CMS Claim and Claim Line Feed files for the Medicare fee-for-service population: authoritative, monthly, and completely silent about how to interpret themselves.
  3. Bulk FHIR from the CMS Beneficiary Claims Data API, arriving days after a claim is submitted rather than weeks, in a shape that shares almost nothing with the flat files.
  4. Research extracts from the CMS Virtual Research Data Center, delivered in SAS.
  5. Medicare Advantage drops, where each plan sends whatever format it prefers, because no standard drop exists for MA.
  6. Eligibility rosters.
  7. Attribution files.
  8. Quality submissions.

Eight arrivals. One patient.

And the trouble starts before anyone reaches analytics, because no two of those files agree on who that patient is.

Problem one is that nobody agrees on identity

The Medicare files know a beneficiary by an MBI, which CMS will reissue if it is ever compromised. The EMR knows the same person by a medical record number that means nothing outside that one instance. The plan knows them by a member id that changes when the product changes. The quality submission may carry none of the three.

So the first thing a pipeline has to own is a resolution step, which is a deliberate, testable, versioned decision about how those identities reconcile, and what the system does when they conflict. Most organizations have a join written by an analyst who has since moved on, and an assumption that it still holds.

The same discipline applies inside the claims themselves. The stable handle for a claim is the identifier the source system assigns it, not a surrogate id invented by whatever transport carried it in. Build joins on what the source owns. Transport identifiers are conveniences, and conveniences change.

Problem two is that there are two clocks

This is the one we see teams miss most often, and it is the one that destroys trust in a number.

The monthly files are settled. They are the record you can defend in a settlement conversation. The faster feed is not settled, and it carries partially adjudicated claims, visible within days of submission. Both are real. They answer different questions.

Blend them into the same cost table and your trend line rewrites itself on every refresh, in a way nobody can explain to a board. So our rule is that partially adjudicated claims never enter the canonical cost tables. They land in their own lane, labeled as what they are, joined to the same patient, and available wherever timeliness matters more than finality: care management, transitions, utilization signals.

Finance reads the settled lane. Operations reads the fast lane. Neither contaminates the other, and the separation is a property of the model rather than a caveat in a footnote.

None of this replaces the monthly files. They remain authoritative for attribution and for amounts the faster feed does not carry. Faster is a second lane, never a substitute.

So we built the ingestion layer before we built the products. Ariv Connect is the layer that sits under every Ariv product.

One declarative connector per source, and the connector contract is the same whether the source is a flat file drop, a bulk FHIR pull, or a SAS research extract. An immutable, sealed, per-tenant landing zone, so raw data is never edited in place and a delivery can always be replayed exactly as it arrived.

Then the part that matters, which is that every source is translated into a single canonical model of clinical and financial truth. It is not a schema we improvised.

A standards-based model, hardened for value-based care, that arrives with its own terminology sets, input contracts, and data quality tests. Product marts sit on top of that model, never beside it.

Standardize once, not once per product

That is the whole economic argument. A source is standardized one time. ACO settlement, patient intelligence, market analytics, home health, the CRM. Every one of them reads the same canonical tables. Nobody writes a second importer. Nobody maintains a per-product interpretation of a canceled claim.

When our numbers reconcile across products, it is not because someone checked. It is because there was only ever one set of numbers.

Two rules make it hold

Every interpretation is a named rule with a named ratifier. Nothing is cleaned, collapsed, or excluded as a side effect of code. Each behavior carries an identifier, a written rationale, and a domain expert who signed it. Where a question is still open, the rule sits in proposed status, the system applies the documented default, and it says so. It does not quietly decide. The knowledge that used to live in one analyst’s head now lives in the system that does the work, which means it survives that analyst’s next job.

Every new feed is on probation. Deliveries are held for human review until a connector earns a clean history, then it graduates to automatic. Trust is a state a source reaches, not an assumption it starts with. A source that starts misbehaving goes back.

What AI-native actually means

Those two rules are the reason we can put a model in front of any of this.

There is no chatbot bolted to the front of our products. The model reads the same canonical layer the screens read, through tools rather than scraped pages, so it cannot see a version of the truth that the application does not. Every figure it returns carries its year, its population scope, and the rule that produced it. Where the data does not support an answer, it fails closed and says so, which is the only behavior that makes a model safe to hand to someone making a real decision.

That is not a model capability. It is a data contract. The model is the easy part, and it was always going to be the easy part.

Scale was never the constraint. Meaning was.

If your AI program stalled, the model is probably fine. The narrower question, and the one we would put in front of the next steering meeting, is this:

What was our data standardized against, and whose name is on it?

If the answer is a script nobody wants to touch, that is not an AI problem. It is the problem the AI was never going to solve for you.