Topics discussed:

• The scope statement puts the work under FHIR Infrastructure as sponsor, with CQI and Security both having flagged an interest during the proposal stage — Security making a certain amount of sense once you remember this is about SQL queries. John's read on becoming a line item under FHIR-I: the meeting goes on the HL7 calendar, the group picks up infrastructure it currently lacks and finds awkward to provide itself, and the profile of the work rises a little. Somewhere along the way it also gets a place to keep minutes.
• They're aiming at STU rather than normative. John explained the difference for anyone who doesn't live in HL7 parlance: standard for trial use versus a normative standard, where the extra rules mean you essentially can never break the normative parts. FHIR itself sat at STU for a couple of years before graduating, so starting there and maturing later is the sane path. On timing, the May ballot deadline had already quietly passed — the lead time runs back to around November — so September is the target.
• A naming note: Arjun avoids the words "working group" entirely, because it's a term of art inside HL7 and means something specific. He calls it the FHIR Analytics Collaborative instead — for the avoidance of confusion, as the lawyers like to say. John's response was that he's pretty much good with anything.
• What happens to sqlonfire.org once it's balloted: there'd be an edge version and a balloted version, and the canonical URLs move to HL7-prefixed ones, which matters for integration with the FHIR spec — resource types, capability statements and the rest. Arjun wants to keep sqlonfire.org regardless, as a wrapper pointing at the published spec, since it's a resource people already use and it centralises things. The advantage of the HL7-published form, per John, is that the spec sits in the same place as its canonical URLs, so links in an operation definition actually resolve.
• The IG Builder column on the implementations page still won't fill, and it bugs John. There's a SQL on FHIR implementation inside the IG Publisher itself — it validates ViewDefinitions, runs them, and can execute a view over the example resources bundled in an IG, so you can embed a SQL-driven view in a published page. He wrote a test runner for it, got it merged into FHIR core, and it produces a report in the build; the one missing piece is publishing that report somewhere the implementations page can read, which means enabling GitHub Pages on the core repo. Not all tests pass — boundary tests, the usual suspects — but John's view is that's fine and rather the point: the page exists to give people a visual incentive to implement alongside, and is never meant to be finished. Four public implementations have been added since the previous year, covering the run and export operations, the query resource, the library work for passing queries over views, and the repeat directive. Steve contributed a small fix along the way: an operation had been renamed from $run to ViewDefinition-run and one reference still said $run.