From the design review of Brett's Export screens (frames "Export" and "Active Exports" in the design file). Companion to the Bulk Import workspace (#527/#531): same web UI, the pull-based half — driving HFS's own, already-shipped $export operation.
What it is
A Bulk Export workspace in the web UI, replacing the "Export" coming-soon placeholder in the Batch & Data nav section.
Export page
- Scope cards ("What are you exporting?"), single-select: Everything ("the whole server — every resource type you select below"), Patients ("every patient and the records that belong to them; nothing patient-unrelated"), Group ("just the members of a cohort you've already defined" — Group picker).
- Resource types: a checkbox grid of the server's resource types with a Clear/select-all affordance; the selection becomes
_type.
- Narrow it down:
_elements, _typeFilter, and _since (presets: last day / 7 days / 4 weeks / all time, plus a custom date-time).
- An optional name for the job (the design shows named jobs like "Diabetes registry 2024").
- Footer: an Active exports (N) shortcut and the Start export action.
Active Exports page
- One card per job: name, status chip (IN PROGRESS / COMPLETE / FAILED), progress bar.
- In progress: percent + rough time remaining (from the status poll's progress header), Cancel.
- Complete: file count, elapsed time, link expiry, Download (manifest output files).
- Failed: the OperationOutcome/HTTP error verbatim ("The server ran out of time building Observation.ndjson (504). Try a narrower date range."), Retry with the same parameters.
Backend surface (already shipped)
System/Patient/Group $export kick-off with _type/_typeFilter/_elements/_since, async status poll via Content-Location (202 + progress → 200 + completion manifest), output file downloads, cancel via DELETE. The UI drives these endpoints on the server's own API — same self-call pattern as the conformance viewers, same job-state persistence approach as the Bulk Import workspace (per-user settings document, byTenant subtree, htmx every-5s polling fragment with one server-side poll per fetch).
Out of scope this round
Auto-download bundling (zip), scheduling/recurring exports, and cross-user shared job visibility.
From the design review of Brett's Export screens (frames "Export" and "Active Exports" in the design file). Companion to the Bulk Import workspace (#527/#531): same web UI, the pull-based half — driving HFS's own, already-shipped
$exportoperation.What it is
A Bulk Export workspace in the web UI, replacing the "Export" coming-soon placeholder in the Batch & Data nav section.
Export page
_type._elements,_typeFilter, and_since(presets: last day / 7 days / 4 weeks / all time, plus a custom date-time).Active Exports page
Backend surface (already shipped)
System/Patient/Group
$exportkick-off with_type/_typeFilter/_elements/_since, async status poll via Content-Location (202 + progress → 200 + completion manifest), output file downloads, cancel via DELETE. The UI drives these endpoints on the server's own API — same self-call pattern as the conformance viewers, same job-state persistence approach as the Bulk Import workspace (per-user settings document,byTenantsubtree, htmx every-5s polling fragment with one server-side poll per fetch).Out of scope this round
Auto-download bundling (zip), scheduling/recurring exports, and cross-user shared job visibility.