Brian Kaney — the base64 objection is a red herring, nobody edits SQL inside JSON — Jul 22, 2025
Brian — the base64 objection assumes something nobody does
The complaint about base64 assumes someone will edit SQL embedded in JSON, and nobody will. You can't even put newlines in JSON, so you're escaping either way. A real query I pulled up runs to about a thousand columns on one line.
His alternative: keep first-class .sql files where your SQL tooling and your agents work, add annotations, and let a small tool compile them into the corresponding FHIR Library.
Library already reaches measures, questionnaires, plan definitions and activity definitions — everywhere FHIR points at logic — so a bespoke resource buys you an intermediary you then have to stitch back to a library that was doing the connecting anyway.
Nikolai — the real objection was parameters, not encoding
My actual objection was never base64 — that was aesthetics — it was parameters.
Once it turned out Library has parameters out of the box, plus dependencies through relatedArtifact and a canonical URL, he was largely sold. John liked it too.
It was never the encoding, it was a blob versus a structured artifact — do we force Library as the structural model, or have something that represents just the query and build libraries up from those?
Gino's worry about annotations
The group keeps promising you only need to know SQL, then layers things on top. If the spec doesn't define the annotation syntax, every tool invents its own and they drift apart the moment an IG published with one tool's annotations meets another's.
He'd rather use SQL's own parameterised literals — partly because passing values as parameters rather than rewriting query text closes off a lot of injection surface.
Which standard, though, is unclear: Gino thought @, Brian said that's SQL Server, and Nikolai pointed out the question mark isn't ANSI either — it's an ODBC and JDBC convention that SQLite also uses.
Left open, with maybe we do need our own hanging in the air.
Library.type has an extensible binding — in R4 as well
Which surprised Brian, so SQL on FHIR can define a query library code and a profile on Library, and repositories can filter for queries. That went in as the concrete next step, with Brian offering the draft.
Arjun's reminder: whatever gets built should hold for a query in any language, not just SQL.
Library's existing $evaluate is less reusable than it looks, since Gino noted it's named for CQL and lives in the CQL guidance rather than core.
Dialects in a MIME-type parameter — genuine disagreement
- Brian and Arjun read it as fair game — parameters are optional, every language has a parser for them, and whoever registered
application/sqlis unlikely to object - Gino wasn't convinced: parameters are defined by the MIME type's registrant, this one doesn't define any, and he thinks that does break the rules
Left to investigate, with an extension as the fallback, and no suffix trick available since SQL isn't suffixable the way +json and +xml are.
John — column type check should be honest about what FHIRPath knows
The shareable profile makes you declare a column type and error if the returned type doesn't match — but FHIRPath doesn't always have a FHIR type, so a string literal is a FHIRPath String, not a uri.
The answer: error when there is a FHIR type and it's wrong, and don't assume the implementation knows more than that. Deeper checking belongs in a separate validate tool.
Nikolai thought such static analysis was tractable and shareable; Gino noted it means traversing the FHIR object model and every extension definition, which is not nothing.