Topics discussed:

• Nikolai demoed a small Express server: a capability statement advertising a ViewDefinition resource type with list and read, a synchronous $run that returns CSV, NDJSON or JSON, and canonical resources served straight out of a folder so anyone can drop a file in and test. Advertising ViewDefinition that way is technically against the spec, but Graham does it constantly, so the group did too. He'd also started a test suite that reads the capability statement and skips what a server doesn't claim — swap the base URL and the same tests run against anyone's implementation. His argument for writing code before prose was that it drives out details the group would never have thought to argue about on paper.
• The biggest of those was FHIR Parameters versus custom JSON. Bulk export answers with custom JSON, and Dan's explanation is that Parameters simply wasn't widely used at the time. Nikolai wants Parameters for input and output so that ordinary FHIR SDKs can talk to a runner instead of everyone writing a bespoke bulk-export client — he admits he doesn't much like how Parameters look, but you get profiles, real data types and room for implementations to add their own fields. Gino Canessa's version was blunter: if a consensus pattern is forming around Parameters, start there, and anything custom has to earn its way in — and it may never.
• The patient and since parameters were inherited from bulk export, and John Grimes pointed out that patient doesn't mean filter on an id — it means the patient compartment, which is a very different job, and the naive reading processes far too much data. Nikolai floated delegating the whole thing to an underlying $export, and was happy to drop the parameters given they were only copied across; John argued patient is necessary for anything beyond a demo, and noted Pathling already has the compartment because a genomics authorisation job forced them to build it.
• John wants to farm one query out to several backends and concatenate the results, which needs a feasibility check first — how many records exist in each place — before fetching columns. Rather than reimplement the search API and keep it behaving identically to the runner, he proposed count-only as a mode of export. Gino backed it on the grounds that these operations are expensive and long-running and the client knows nothing about the scale of the data on the other side; John then split it into three levels: pre-flight (given your capabilities and my permissions, could you do this at all — parse it, don't run it), count-only, and the real thing.
• Steve Munini described the mindset the API is actually serving: analytics work is batch, a pile of data pulled monthly or quarterly and compared from there. John asked whether anyone keeps the pile fresh nightly with since; Steve said no, because keeping it continuously up to date is a pain in the neck. Nikolai's view is that every batch system eventually wants to be near-real-time, and that updatable views are the hard problem still waiting.