Why claims data can never answer a seven-day follow-up question, and what a payer wants from FHIR instead — Feb 17, 2026

Why payer interest in clinical data is real

Claims are retrospective — sixty to ninety days before they're in the warehouse and usable.

Near-real-time clinical data changes what's answerable: some follow-up quality measures require action within seven or fourteen days, and a claim's value for that is exactly zero.

The velocity is the product, not the richness.

The failure story — more useful than the success one

Every time a consuming system needed a slightly different flavour of FHIR for a different use case, it became another project and another invoice, until the business asked why the care management system couldn't just read FHIR once and let the use cases iterate underneath.

They were effectively wiring each use case by hand, because translating nested FHIR into the shape a user experience actually wants is hard.

Their conclusion: stop forcing FHIR on consumers — internal or external — and move towards a data lake, keeping the ability to push to FHIR for interoperability without making anyone consume it.

The thing that made the group sit up

Internally they'd already built a git repo of business-question definitions with a review ceremony and certification levels, so that what is the latest A1C has one blessed SQL query behind it that everyone reuses.

This is precisely what the group is building — the same library of discoverable, executable definitions, except standardised so it runs over any FHIR repository rather than one company's warehouse.

— John

Which is also the economic argument: a user can then go to their vendors and ask them to implement the standard.

The vision restated — a portable "analytic case"

One package holding the data requirements, the ViewDefinition mappings that flatten the data, the queries to run over them, and test cases for the expected results.

Hand it to system X or system Y and get results back. The flattening half is largely done; the query half is what's being filled in now.

The precedent cited: a project with Canadian hospitals during COVID, where nobody wanted to move data, so they shipped the queries out to each hospital and collected only aggregates back — which solves the analytics problem and the privacy problem at once.

On the spec — rowIndex inside nested expressions

The agreed reading: it applies in all nested contexts down to the next forEach or the leaves, and restarts numbering at each level.

The gap: the documentation names forEach, forEachOrNull and repeat but never mentions union — so union needs saying explicitly, with test cases to match.