Repository navigation
0.1.2
Added
-
The viewer has a design system, and every screen is drawn from it. Colour is named by role on
:rootand redefined once under:root.dark, so a theme decision is never taken per element; type is six steps, spacing four on an 8-point grid, and motion one duration. A screen names a role and a step and nothing else, whichscripts/checks/viewer-tokens.shenforces as its own CI job: a palette entry, a per-elementdark:variant, a raw type size, an off-scale spacing value, or a bracketed value fails the build. The point is measurement rather than tidiness: a pairing defined once is checked once, and the WCAG 2.2 AA contrast pass covers every pairing the viewer draws in both themes and both densities. -
A command bar sits above every screen, and the navigation is four labelled groups. One field takes a code, a canonical, or free text, decides which it is from the string's shape before any request, and offers what this root can do with it; every offer is a real link, so the keyboard contract is the browser's own and an offer can be shared. The screens are grouped by what a reader came to do rather than by resource type.
-
Every runner picks its code system rather than waiting for a canonical to be typed.
GET /{version}/{type}?_elements=url,name,title,versionis about four kilobytes where the whole search is a quarter of a megabyte, so each control offers what this root publishes, the name leading and the canonical as the value, with the versions beside it being the ones that canonical was published in. A canonical the root does not publish is still typed, and the control opens on the text field for one rather than snapping back to a list it is not in. The screens are named for the question rather than the operation that answers it: Check a code, List a value set, Map a code. -
The overview reads a twenty-system deployment on one screen. It is one table rather than a card each, sortable by any system-level column, each row leading with the name its code system was published under and the canonical beside it, quieter and still selectable. Absence is a mark with the sentence behind it rather than a sentence in every cell. The top bar and the sidebar stay put while the screen scrolls under them.
-
_elementsis answered on every served version. The parameter is defined by every release this server speaks (http://hl7.org/fhir/SearchParameter/Resource-elements) and was refused as unsupported; a search now returns the elements it names plus the ones every resource keeps, and marks what it sendsSUBSETTEDso a client cannot store a subset back as the whole resource. Reading eleven code systems by name costs 4 KB where the whole search costs 255 KB. -
SNOMED CT's
normalFormandnormalFormTerseare generated and served. Both are the Necessary Normal Form of a concept, which the FHIR SNOMED CT page defines and does not say how to produce. The generation is a rendering rather than a computation: the necessary normal form of a precoordinated concept is what the release's inferred view already holds (the SNOMED CT Release File Specification, Appendix D), so the focus concepts are the concept's inferredis aparents and the attributes are its other inferred rows, and no reasoner and no supertype walk runs. The syntax is the Compositional Grammar specification §5, the definition status prefix its §6.7:===where the RF2definitionStatusIdsays the concept is sufficiently defined,<<<where it does not, both always written because the grammar assumes===when none is. Three shapes are this server's own, because no specification fixes them, and each is recorded: the order of what is rendered, which term a reference carries, and the layout. A request naming no property is answered as before, which is what "the server chooses what to return" admits. -
An openEHR archetype's local terminology is served through the ordinary operations. An archetype constrains most of its coded fields with an archetype-local
at-code list, and nothing publishes those as FHIR resources. The scope decision is recorded: this server ingests the resources a producer derives from an archetype and reads no openEHR artefact, so it keeps no openEHR dependency. Theat-codes as aCodeSystem, anac-code as aValueSet, andterm_bindingsas aConceptMapload throughFERROTERM_CODESYSTEMSlike any other supplied resource, and$lookup,$expand,$validate-codeand$translateanswer over them with no openEHR-specific request shape. No openEHR specification defines a canonical URI for a local value set, so whoever produces the resources mints the URL from the archetype id, and this server reads it as an opaque canonical: two deployers minting the same archetype under their own domains are served side by side, and two directories naming one canonical at one version refuse to load rather than picking a winner. -
The brand tokens state what each is safe for. Three of them are safe for the mark and not for text, and nothing said so: teal reaches 3.58:1 on the light surface, which clears the 3:1 a graphic needs and falls short of the 4.5:1 a label needs. Each token carries its measured ratio against both grounds,
--ferroterm-brand-textis the brand colour as text (deep teal on light, teal on the tile, each at 4.5:1 or better), andscripts/checks/brand-contrast.shfails when a token's own comment or the published table stops matching what the value measures. The mark is unchanged.
Fixed
-
An unresolvable
exclude.valueSetis named rather than passed over.ValueSet/$validate-codewalked the excludes only after an include had held the code, so an exclude naming a value set this server does not hold was never reached and the answer was a silentresult = falseover a definition it could not fully evaluate. The excludes are walked either way now, which changes what is reported and no answer: an exclude removes codes, so afalseit could not evaluate was never going to become atrue. The terminology ecosystem settles the reached case as an answer rather than a refusal, with the canonical named in an issue oftx-issue-type#not-found, and it requires$expandand$validate-codeto differ in shape over one such value set; a refusal stays reserved for a definition that cannot be processed at all, which is a cycle. -
A cycle names the value set that closed it. The reference chain pushed the root as
url|versionand every reference as the bare reference string, so the two spellings could never match: a value set referencing itself was caught one hop late, and a two-hop loop was reported under the value set it reached rather than the one that closed it. One rule now decides whether a reference re-enters a chain entry, comparing the url and the versions where both name one, because a reference naming no version means the version the server resolves to. -
check-system-versionis compared against the version an include resolved to. The check ran against the version or pattern a value set wrote, before that version had been resolved against what the server serves, so a value set naming1.x.xwas reported as failing a1.0.xcheck under the pattern's own spelling rather than under the1.2.0it selects, and a value set naming a version nothing serves was reported as failing the check rather than as naming a version that does not exist. The pin now applies the defaults and the forces alone and the checks run over the versions the expansion actually used, so a version that resolves to nothing fails as unknown first, which is what it is. An answer that says a version is unknown also names the versions the server does hold.