Skip to content

docs: SQL-on-FHIR analytics evaluation — query notebook that scales to BI (#650) - #775

Open
dougc95 wants to merge 3 commits into
mainfrom
docs/650-analytics-evaluation
Open

docs: SQL-on-FHIR analytics evaluation — query notebook that scales to BI (#650)#775
dougc95 wants to merge 3 commits into
mainfrom
docs/650-analytics-evaluation

Conversation

@dougc95

@dougc95 dougc95 commented Aug 28, 2026

Copy link
Copy Markdown
Contributor

The #650 deliverable: a decision document under docs/ evaluating where users should analyze SQL-on-FHIR tabular output.

Recommendation

Build a native query notebook for SQL-on-FHIR that scales into governed BI — query cells → charts → dashboards + a semantic layer — staged on the #649 UI, rather than bundling any third-party notebook or BI tool. Python / ML stays a later tier (companion service or external platform), fed result data, not credentials.

What's in it

  • Buy-vs-build framing; per-candidate license / no-CDN / footprint across the full Research: evaluate open-source analytic notebook tools for bundling or integration into HFS #650 candidate set (JupyterLite, marimo, DuckDB-WASM, Evidence, Graphene, Cube, Superset, Zerve, Deepnote/Hex/Databricks, Quarto, Observable, Polars, pysof baseline).
  • The BI-as-code blueprint — Evidence / Graphene / Cube adopted as design, not runtime.
  • Locally measured spikes (screenshots embedded): JupyterLite vendored-offline (463 MB, 0 off-origin) vs marimo WASM (CDN-locked, 13 off-origin); DuckDB-WASM (~8 MB gz) and Arrow JS (51 KB gz) self-hostable.
  • Security / tenant model, staged architecture (§11), and proposed follow-up issues (§14).

Runnable POCs

Four demonstrators accompany this document as draft PRs: #768 native notebook · #769 DuckDB-WASM over Arrow · #770 pysof baseline · #771 JupyterLite.

Relates to #650. Follow-up implementation issues are proposed in §14; not auto-closing the research issue.

dougc95 and others added 3 commits August 28, 2026 08:43
…o BI (#650)

Decision document for #650. Recommends building a native query notebook
for SQL-on-FHIR that scales into governed BI (charts -> dashboards ->
semantic layer), staged on the #649 UI, over bundling any third-party
notebook or BI tool.

Includes: buy-vs-build framing, per-candidate license / no-CDN / footprint
comparison across the full #650 candidate set, the BI-as-code blueprint
(Evidence / Graphene / Cube adopted as design, not runtime), locally
measured spikes (JupyterLite vendored-offline vs marimo WASM, with
browser-verified off-origin request counts), security/tenant analysis,
staged architecture, and proposed follow-up issues.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PTFfaGwHDggEbrFtfejJtE
…ted results (#650)

$sql-run silently truncates at 100k rows (engine.rs:277), so browser-side
group-by/sum/avg over a large ViewDefinition would chart a wrong number.
Aggregation now specified as server-side (SQLView SQL); client-side DuckDB-WASM
pivot is scoped to sub-cap results. Fixes a verified gap-review finding.
…vs proposal (#650)

Adds a "Proof of concept" subsection to §5 mapping each option to its built
demonstrator (PRs #768-#771) with what each verified, and relabels the
now-shown feasibility as [demonstrated] while keeping the product decision,
correct Stage 2, Stage 3, and the open questions as [proposal].
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant