Topics discussed:

• Steve Munini showed a SQL on FHIR runner written in Rust — deliberately minimal and stateless, so you can drop it into a pipeline either as a command line tool or as a small microservice. It passes the test suite and handles CSV, JSON and NDJSON; group and source are the gaps. Supporting source matters because his clients keep piles of FHIR data sitting in S3 and would rather transform it in place than load it into a database first.
• Brian Kaney walked through a profile that wraps a SQL query in a FHIR Library resource: one conceptual query per Library, with several attachments if you want that same query in more than one dialect, plus an invariant forcing the attachment's content type to start with application/sql.
• Nikolai objected to the name. Brian's code was query-library; Nikolai argued that if it's one logical query it should say so — sql-query — because "library" implies a bag of many. Brian's counter was that we don't call it SQLViewDefinition, just ViewDefinition; Nikolai's answer was that ViewDefinition is generic flattening and may one day target something other than SQL, whereas this one only ever is SQL. Gino Canessa floated query-definition to echo the existing model-definition pattern, and Brian took the point.
• The sharper disagreement was how many code systems to have. Brian wanted one SQL on FHIR code system holding everything, and finds it weird when an IG carries a hundred code systems with two codes each — "SNOMED has a lot of stuff in it." Nikolai wanted one per classification, since library types, dialects and formats are different concepts that change for different reasons, and SNOMED gets away with it only by being an ontology of everything. Gino said that if you take the single-code-system route you at least need hierarchies or properties rather than a grab bag, but he defaulted to Nikolai's side; Brian conceded without enthusiasm.
• On formats, Gino asked why invent codes when MIME types exist. The answer is short names: people want _format=json in a query string, FHIR-style, not a full MIME type. Gino pointed at the pattern FHIR already uses for exactly that — bind to the MIME types, supplement with a small code system for the friendly names, and let a value set pick out the nice ones.