Topics discussed:

• John admitted he hates conceding it, but argued the way the group works now is a bit loosey-goosey. People come in for a while and drop off, decisions get made, and someone who wasn't there didn't agree with them. A defined process at least means everyone knows where decisions happen and that turning up is how you influence them. His second argument was about the audience: a lot of people are now adopting the spec, and they want some confidence in how it will change from here — which the group hasn't really had to offer up to this point.
• The mechanics as John understood them: a proposal that FHIR-I votes on, then a fuller project scope statement, then the group becomes a sub-project of FHIR Infrastructure much like SDC — meeting advertised on the HL7 calendar, probably HL7's Zoom, formal minutes. Two things he couldn't answer: whether this counts as R1 or R2 in HL7's eyes given the spec already has a version 2, and the ballot lead times, which are long enough that May looked already out of reach. One downside he raised without resolving is that a different channel may bring in a different type of participant than the group normally attracts — but putting off the wider HL7 community is worse.
• The counting question came back. John wants to know how you ask a server how many patients match before running the query, and how you find out whether a server can run your view at all, given implementations support different sets of functions. Graham had raised a dry-run variant of this. John's own guess at the answer was a FHIRPath search parameter, built on the machinery a server has already had to build to execute ViewDefinitions anyway.
• Arjun pushed back: that already is a query. If you have a query resource and can run arbitrary SQL over views, what does a dedicated API capability actually buy you? It comes down to API design philosophy — how far you bend an API towards specific use cases, given nobody uses all the optionality anyway. Left on the list, with John betting it becomes obvious once people start building things on top of the API.
• John also raised the consistency problem that keeps recurring: you almost always need several ViewDefinitions to do anything non-trivial, and you want them all from the same point in time so you can join them afterwards. Exporting patients and then conditions two minutes later isn't good enough when the server is still taking writes. Steve wondered whether run should just accept several views at once. Separately, Steve had implemented repeat programmatically without trouble — which John noted is a different problem entirely to doing it in SQL, where whether you can do it at all depends on the flavour.