Developers

The package registry, joined

Every implementation-guide package this lab tracks — its current version from our committed release watch, who stewards it at HL7, which CMS rule names it and on what basis, what our validator can actually do with it, and where to get it. Each claim traces to a registry with its own tests.

Validated here

1 package

Loaded by the validator AND pre-warmed on the hosted sidecar — paste a payload and the verdict engine runs against these versions.

Analyzed here

9 packages

Loaded by the validator for package analysis and version differencing. No sidecar warm — analysis, not payload validation.

Tracked, not validated

2 packages

We watch upstream releases and record every published version. The validator does not load these yet — deliberate and measured, not an oversight: loading a package costs traced deployment weight per version, and we spend that only where a workflow demands it.

Where is CQL?

Deliberately not a row. CQL is a language, not an implementation-guide package — there is nothing at packages.fhir.org to hand you. What exists here: the validation plane reads CQL and ELM as data (three-valued retrieve presence, no engine), and the teaching plane executes curated, build-time-translated ELM against synthetic bundles in your browser. A registry row implying otherwise would be the kind of claim this page exists to not make.

What is CQL? — the card

Getting packages yourself

Every link above is derived from the package id and its canonical URL — nothing hand-maintained, nothing to drift. The pattern: packages.fhir.org/<id> lists versions and serves tarballs; registry.fhir.org is the browsable UI; the canonical site publishes the guide itself; and <canonical>/package-list.json is how a guide declares its own published versions — the same file our release watch reads.