Topics discussed:

• A demo from someone who had never heard of FHIR six weeks earlier and had taken about two SQL classes: two ViewDefinitions over Synthea data — haemoglobin and haematocrit — materialised and joined on the subject. The same thing was then written by hand against Postgres and against DuckDB for comparison, and the verdict on hand-rolling nested JSON access was that it is "a lot more nasty". About a week of work end to end. As a usability datapoint that is worth more than most of the arguing.
• getId needs a companion. References are polymorphic — a subject may be a Patient or a Group — so the bare ID isn't a safe join key, and without string functions in the view layer you can't filter on the type either. Proposals: getId taking an optional resource type, plus a separate function returning the reference's type. Someone suggested going further to an opaque join key you don't have to understand, on the grounds that joining is all you wanted from it anyway.
• The outer-join keyword finally got a name: forEachOrNull. It beat unroll, expand and explode on the grounds that a descriptive name tells you what it does, and the group had already leant towards a separate keyword rather than a parameter, since parameters accumulate and make things harder to read. The real point was agreeing on something tentatively — implementations were about to diverge, and any common name beats four different ones.
• Do views proliferate, or are there stock ones? Implementing a view definition is non-trivial work, and the hope is a common catalogue covering families of use cases rather than one view per question, with authoring separated from usage so most people only consume. The comparison offered: something like an implementation guide, but far cheaper to produce — and possibly attached to one, so the views you'd typically want over an IG ship with it.
• Unit conversion splits three ways. Things UCUM handles with a single multiplication from its own database — just arithmetic, and easy enough to be worth doing. Other scaling formulas, which are harder. And conversions needing outside knowledge, like moles to milligrams per litre for glucose, where you must know it is glucose and know its molar mass. The group wanted a worked glucose example before deciding whether any of it belongs in the view at all, rather than in the SQL above it — and if it does, with an explicit formula rather than implicit magic.