Topics discussed:

• A guest from a large US health plan laid out why the interest in clinical data is real rather than compliance theatre. Payers have run for decades on claims, and 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 candid failure story was 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. The conclusion they reached was to 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. John's point was that 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. 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 was 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: whether rowIndex is visible inside nested expressions, not just the first one. The agreed reading is that it applies in all nested contexts down to the next forEach or the leaves, and restarts numbering at each level. The gap is that the documentation names forEach, forEachOrNull and repeat but never mentions union — so union needs saying explicitly, with test cases to match.