Nikolai walked his draft export API past Dan Gottlieb, who knew exactly which parts of bulk export he'd redo — Jan 28, 2025
Nikolai's draft — split by what comes out
File, table, or stream — three operations with the parameters kept in line with each other. The file one deliberately copies bulk: kick it off, get a URL back, poll it, read the manifest, fetch the files.
Stay as close to bulk as possible — you then inherit the FHIR async operation pattern for all the polling and file-deleting and manifest handling, and don't have to maintain any of it yourself.
Why bulk's manifest is a custom JSON blob
Dan explained: Parameters was barely sketched out back then and hardly used. Starting today he'd use Parameters — but the custom format is documented, widely implemented and extensible, and nobody stores manifests anyway, so breaking compatibility buys little beyond looking more FHIR-ish.
Nikolai floated Bundle, since response.location could carry the file URL and every SDK can already parse one.
Bundle is tightly constrained to collections of resources and these URLs don't lead to resources. If you're stretching it that far, use Parameters.
The narrower objection — the manifest isn't described in FHIR terms at all
Which makes it a semi-official structure nobody can point tooling at.
Nikolai's proposal: write a logical model for it, backwards-compatibly.
Dan called that a fair gap, one that exists mostly because the spec predates logical models, and said nobody would object if it can be done without adding required elements. John saw no reason it couldn't.
Tying each output file back to the view that produced it
type in the manifest is SHALL and is defined as the FHIR resource type contained in the file. Nikolai wanted the ViewDefinition URL there and noted type is already a bit of a fiction, since the file is CSV or Parquet, not a Patient.
Dan preferred leaving type alone and using the manifest's per-output extension mechanism, which implementers already use in the wild to describe how files are encrypted.
The missing level — a container for a set of views
A query never depends on one view. It depends on a set of views, named certain things, that work together. A flat list of ViewDefinition URLs is too simplistic.
Dan made it concrete by asking what a FHIR-to-OMOP export request would look like, and answering himself: enormous.
Nobody has a container yet. Library is the closest definitional fit, borrowed from the CQL world, and the group figured CRMI has probably already hit this problem.
Dan also wanted references and canonical URLs kept as separate parameters so a server with no CRUD on ViewDefinition could still export from an IG, while Nikolai argued they're both just URLs and the distinction will confuse people — left unresolved.