Topics discussed:

• Evgeny presented FTR, the FHIR Terminology Repository — a layout and protocol for distributing expanded value sets. The core is a gzipped ND-JSON terminology file holding code systems, value sets and concepts, canonically sorted so diffs are reproducible. Around it sits a git-like model: patch files hold the changes between versions, a tag points at the current hash, and a master tag index lists every value set and its head. A client compares its tag index with the master's and pulls only the patches instead of reloading the whole terminology. A whole code system like ICD-10 is just a value set expanded over every concept, so both collapse into one file format.
• The pitch for this group was that the concept table is exactly what memberOf wants to join against, and that a standard published repository would stop everyone writing their own SNOMED converter. It was not proposed for the spec itself — at most a recommendation that you can work with terminology through a concept table.
• The licensing objection came with an apology for raising it. SNOMED needs a click-through even under the US blanket licence, and CPT's display text costs a per-view fee to the AMA, so codes and text often load separately. That can force you to distribute scripts that build the terminology from each organisation's raw files rather than the compiled result — a completely non-technical reason to make a technical decision. The answer: they already ship such conversion scripts, and the S3-style protocol can be gated with signed URLs.
• Brian showed the spec built as a real HL7 IG — the existing markdown moved into the publisher's layout, plus ViewDefinition as a logical model in two flavours: a minimal one, and one wrapped in the canonical/definitional pattern with url, version, identifier and usage context. Names were spelled out (expression, not expr) and an invariant with a regular expression keeps column names database-friendly. The group's answer was merge now and edit after, rather than settle everything pre-merge.
• Two things were left open. On the name: the argument was that the work is not deeply tied to SQL — the key piece is a flattened view of FHIR, so something like 'flat FHIR views' would avoid confusion, with SQL as the common worked example. It stayed 'SQL on FHIR' for now, to be revisited before publishing. On balloting: not yet — the group wanted implementations and a real test suite first. JSON Schema's suite was the model everyone admired, one file per feature so you can implement one keyword at a time; the counter-example was validation testing built from real-world resources full of errors, where a run just gives you a pile of failures and no way to focus.