Topics discussed:

• The only thing standing between the group and a tag was where to link the functional model page from. The argument that won was explicitly about shipping: minimise the change, put a short "for more information" link at the top of the ViewDefinition page and in the table of contents, and stop dragging out a release that is otherwise done. Then call it a release candidate on Zulip, and if nobody objects, declare it released.
• On OMOP, the worry coming back from the Vulcan side was that this is yet another FHIR-to-OMOP transformation that ignores what they have already learned. The response the group wanted to make is that it isn't a conversion project at all — it's a way of proving out and improving SQL on FHIR — and that a conversion built on a standard view layer has genuinely different characteristics from one written directly against FHIR.
• A concrete technical objection to how the mapping was being collected: listing FHIR elements down one side and asking people to fill in the OMOP column opposite can't express the real work. Getting to a given OMOP column usually needs a FHIRPath expression — pulling a race extension, say — not a field-to-field correspondence. Starting from the OMOP columns and working back is the direction that survives contact with the data.
• The hypothesis worth testing: there is real variability in how FHIR-to-OMOP can be done, and a common set of intermediate views might absorb most of it, so the last mapping step becomes simpler than reaching into FHIR elements directly. The only way to find out is to run it through a couple of genuinely different scenarios.
• The IG publisher turns out to be two things at once — it runs views over resources during publication into a SQLite database, and it validates any ViewDefinitions in the guide. Its validator doesn't understand forEach: it sees a path that can return a list and complains you haven't set collection, when forEach has already unnested it. Related, and unresolved: ViewDefinitions written for R4 fail against an R5 default, which raises the question of what an engine should do when a view declares one FHIR version and the resource is another.