ViewDefinitions to measure fill rates across 300+ payers, and the first pass at what an API is for — Jan 14, 2025

Josh — patient consent product reading from 300+ payer endpoints

Payer patient-access APIs never had an Inferno conformance suite the way provider APIs did, so implementations vary wildly. 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.

Josh Mandel

Chief Architect for Microsoft Healthcare, Chief Architect for SMART Health IT

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 — 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
• 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: 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
• Propose ViewDefinition as a real R6 resource