Topics discussed:

• Gino walked through the additional resources mechanism. The catch is that FHIR refers to things by short name almost everywhere — the API surface, capability statements, search parameter targets, reference targets — and most of those places have no room for a full URL. So the short name has to be controlled: someone must make sure ten different groups aren't each defining something called ViewDefinition with ten different meanings. There is a GitHub registry mapping short names to canonical URLs, and a new extended resource types value set so terminology services can answer questions about them. Graham had already dropped ViewDefinition into that registry while tinkering, but it isn't authorised and can't be — the resource has to be defined in an IG that goes through HL7 International's STU ballot, because there is no path for externally developed content into the core.
• Nikolai asked what the mental model actually is — he'd assumed additional resources were about extensibility. Gino said no: a large part of the industry pushes hard for a closed world, because if the justification for a diagnosis is some resource you've never heard of, you can't parse it and it isn't a valid US Core or AU Core diagnosis any more. Nikolai's reframing was that this is modularisation, splitting the core into pieces rather than extending it. Gino agreed but said "module" is already taken in FHIR, so the leading term is "incubator" — which Nikolai disliked, since it implies something unfinished when these may live as separate pieces forever.
• On what formalising costs day to day: the meeting goes on the HL7 calendar, you need a sponsoring work group, and spec changes need JIRA tickets and votes. Gino argued that's lighter than it sounds — FHIR-I does block votes, thirty dispositions at a time, and almost nobody ever objects because the people who cared were the ones doing the work. Nikolai pushed back that Graham just writes three pages and discusses afterwards; Gino's answer was that there is still a ticket — "add authorization hinting to subscriptions" is the ticket, and the extensions, code systems, value sets and documentation all hang off it. John's read: prototype informally for months, and only push things through once they're mature.
• John presented the repeat directive. ViewDefinition has everything except a way to deal with recursive structures, and QuestionnaireResponse is the sore spot as SDC takes off: the data can be arbitrarily deep, so today you hand-unnest and hard-couple your view to however deep your data happens to go. repeat takes one or more paths, walks down the tree collecting each, unions the results, then applies the selection — needed because items hide under both item.item and item.answer.item, same shape, different routes. Nikolai flagged that if repeat and forEach sit on the same node the order must be explicit: repeat, then forEach, then columns.
• Brian Postlethwaite asked the awkward question: how do you get at the parent's link ID? He suggested a CodeSystem with child concepts as a second example — parent and child are explicit there, while in a QuestionnaireResponse you can't tell whether a link ID belongs to the parent or the item itself — and was careful to say a second example, not a replacement. Nikolai's answer was that the select is a cross join, so the first expression can carry the parent column and cross-join with the repeated rows. Implementing it is the open part: straightforward in a programmatic implementation, much less so in a SQL transpiler, where Nikolai wants to try Postgres JSON path recursion rather than a common table expression.