$materialise — tell the server to keep a view up to date elsewhere — May 20, 2025
Language on a view — the wrong tool
Graham had asked whether ViewDefinitions should take a language parameter, so he can build IG pages in several languages.
A parameter is the wrong tool. The runner isn't the thing that knows about language, so if you want a view in Spanish you need a Spanish view definition, and the runner can pick the best match the way an Accept-Language header does.
Arjun made the same point from the other end: nobody in the room could say what a language parameter would actually do to a column name, which makes it sound like an ETL job rather than a view.
Translating coded values — where this group does have work to do
John noted Pathling already has a designation function that takes a language and passes it to the terminology server, so you can get Spanish display terms out of SNOMED CT or LOINC — but it is not standard FHIRPath.
Pathling bolted on translate, designation and property because the standard set stops at memberOf and subsumes and the %terminology mechanism is awkward for this.
Nikolai's caveat: none of it is cheap, since you need the full terminology, language packs and concept maps.
$materialise — hand the server a view and a destination
Nikolai's sketch: hand the server a view definition and a destination — Postgres, ClickHouse, Parquet files on a bucket — and say keep this up to date, with the replication machinery hidden.
Arjun couldn't think of a better name than $materialise; he had considered replicate but that leans too far towards the remote case.
Steve had already built this
Called it continuous — a parameter on a view, not a separate endpoint.
It dragged scheduling in behind it, because people then wanted cron, and that pushes a scheduling engine into the server whether the server wants one or not.
In his design the view definition stays put and a separate export job carries the status, the record counts and the enable/disable switch.
John — a materialisation is state
You need more than an API to ask for one — you need APIs to list what currently exists, check status and tear it down, much the way Subscription does.
Nikolai liked the Kubernetes shape, where you post a resource and the server writes status back into it, and deleting the resource stops everything.
John was wary: if status lives in the resource, every status change makes a new version of the thing you are authoring.
They settled on starting with extensions and seeing whether anyone uses them.