Everything, and where to get it

Builder's field guide

Ten doors into the FHIR ecosystem — the spec and IGs, packages, validation, testing, community, forms, CQL, HTTP practice, renderers, and where questions actually get answered. Each door says why we point there.

What is FHIR?

The plain-language starting point, for when you need to explain to someone else why records still ride fax machines.

The package registry, joined

Every package this lab tracks — current version, HL7 steward, which CMS rule names it, what our validator can do with it, and where to get it. The honest tiers: validated here, analyzed here, tracked only.

The ecosystem, mapped

Regulation → guide → package → tool → explainer, as a navigable map. Including the dead ends: the rule whose adopted standard is not FHIR, and the proposal with no date.

IG version differences

What actually changed between two published versions of an implementation guide — element changes, profile coverage, must-support expectations, operation parameters, measured from the packages themselves.

Not a compliance assessment · carries no deadline

The FHIR package registry

The npm-style ecosystem for implementation guides: where packages are published, how versions are listed, and the keyless API surface for searching and downloading them.

package-list.json

How an IG declares its own published versions — the file our version tracking reads to know what exists upstream.

Mandates and deadlines

The dated watch-list of CMS milestones this lab tracks, and the single place those dates are authored.

The Learning Lab

The full tool index — 6 tools switched on right now, each with its own scope note.

Payload Workbook

Bring a payload in from a Postman collection, a HAR capture, a .bru file, or curl — and emit it back out in any of them. The bridge between this lab and the client you already use.

Client-side only · no network

Test-Data Factory

The walkthrough for producing controlled synthetic records to drive the rest of the tools — each step links to the surface that performs it.

Synthetic data only

Explain a validator finding

Plain-language explanations of what a finding means and what to change — each one carrying its own provenance, including when that provenance is 'unverified'.

Which code system goes where

Diagnosis, procedure, medication, observation — which terminology families belong in each slot, and which of them are licensed.

We name licensed systems · we never host their codes

CQL or flow logic?

The two mechanisms a DTR questionnaire can use to decide what to ask next, and how to tell which one you are looking at.

Where's my auth?

Reading a prior-authorization response in plain language — and the honesty ladder that refuses to invent an approval the payload never stated.

The public board

Owner-opted cards from the working Kanban, in its own columns — shipped work with dates, drops with reasons, and an honest note about why the rest is not here.

Open-source notices

Every open-source package linked into what this site serves, with its license and the attribution it requires — generated from the lockfile, never maintained by hand.

Security and data handling

Where payloads go, which services run beside the app, and what leaves the browser.

Spec testability register

Which normative statements in a specification can actually be tested, and which cannot.