Components

Every component in the catalogue is implemented and installable. Each has a file under registry/bases/base/, a registry item the shadcn CLI copies into a project, and a page that documents the cases it refuses as carefully as the ones it serves. Every one is shipped, and no further: none has been through an independent accessibility or clinical review, none is ready for a production health surface, and each page lists what has not been measured rather than implying it has been. That status is on every component page in prose and in machine-readable form, at a URL you can guess from the component name.

That is what this page is for. The failure it exists to prevent is an agent, or a developer in a hurry, inferring an API from a plausible name and shipping it into a product that shows people their own health data. A definitive answer at a guessable URL is worth more than a 404, and far more than an invented answer.

60 shipped

Every id in the catalogue has code, a registry item and a hand-written page. Filter by category or status, or search the synonyms: normal range, kpi, gauge, not medical advice, ago.

Status is a promise about change, not a quality score. shipped means the code exists and is documented, and the API may move in any release. It says nothing about whether anybody has reviewed it, and nobody has. Release phases sets out what the three phases promise about semver, the page's own outline and the registry.

Category does two jobs. It groups the sidebar, and it is load-bearing: any category beginning with health- makes the Clinical meaning section and the governedBy frontmatter mandatory, and the build fails without them. It makes their absence mandatory elsewhere too, so Button cannot acquire a clinical meaning by accident.

Aliases are search synonyms, unique across the whole corpus, because the person searching does not know our vocabulary. Someone typing normal range wants RangeBar, and the first thing that page tells them is that normal is a banned word, and why.

Governed by links a component to the doctrine that constrains it. Doctrine is written once in Health and referenced from every component that must obey it, in both directions, so a rule cannot quietly end up applying to nothing.

If you are choosing a component, the decision table in Choose a component maps the shape of your data to the component that displays it. Reading that table is faster than reading every page. If you are writing or reviewing one of these pages, read Anatomy of a component page; it publishes the page contract once so you fill in a template instead of inventing a structure. If you are here to judge whether opsinjs is worth building on, read RangeBar: it carries the most detailed clinical contract in the set and it is the component the rest of the system is arranged around.

How this is generated

The table above is not hand-maintained. Every row comes from registry/catalogue.ts, the single declaration of every component id, its category, its status and its alias namespace. scripts/build-registry.mts reads it and writes lib/generated/catalogue.json and public/r/index.json; <StatusMatrix> renders that JSON and <SectionProgress> counts it.

Nothing here is typed twice. If a row is wrong the catalogue is wrong, and editing this page cannot fix it. scripts/assert-ia.mts fails the build when a catalogue id is missing the page it should have, when a page claims an id the catalogue does not know, or when two pages claim the same alias.