Topics discussed:

• Josh demoed a patient-consent product that reads from over 300 US payer FHIR endpoints. Payer patient-access APIs never had an Inferno conformance suite the way provider APIs did, so implementations vary wildly — and the team now writes ViewDefinitions over ExplanationOfBenefit, Coverage and Patient purely to measure fill rates: which fields and code systems actually turn up, and how often. Writing a handful of FHIRPaths turned out to be much easier than the equivalent JSON queries against Postgres.
• That reframes the use case: SQL on FHIR as a data-quality tool at the network layer, not just something you point at your own warehouse. The working pattern is to write one ViewDefinition that is a superset of everything the endpoints might plausibly do, then see which parts come back empty — and hand that feedback back to the endpoint owners. The group liked the idea of shipping ready-made ViewDefinitions inside an IG so implementers get them for free.
• Nikolai opened his API draft with the awkward question: why do we need an API at all? The answer that stuck was roles first — describing the parts of an implementation is useful whether or not there is ever a wire protocol. Two use cases got singled out: exporting data for ViewDefinitions that ship in an IG, and fitting ViewDefinition into ordinary FHIR REST semantics.
• The objection to the REST half: FHIR search already defines plenty that nobody implements, and expecting vendors to stand up tables per IG on demand would be more of the same, given how much of their capacity regulatory work already eats. The counter was that referencing a ViewDefinition by canonical URL lets a server hardcode five views and export them with none of the REST machinery — plausibly even a legacy system with no FHIR in it, since the hop from its own flat tables to a flat view is shorter than the hop through FHIR and back. Bulk export was agreed as the low-hanging fruit; a full runner was pushed out.
• The CapabilityStatement problem: you can add /ViewDefinition to your server, you just can't advertise it, because rest.resource.type is a required binding to real FHIR resource types. The R4 workaround is Basic plus cross-version extensions, which the group's own experience with topic-based subscriptions says technically works and is ugly. Two suggestions: use the Application Feature Framework IG, which grew out of CapabilityStatement for exactly this reason and back-ports to R4; and propose ViewDefinition as a real R6 resource.