fhirsmith 0.18.2 → 1.0.0

package/ACCESSIBILITY.md

@@ -0,0 +1,119 @@
+# Accessibility
+
+## Project Information
+
+| Field | Value |
+|---|---|
+| Project | FHIRsmith |
+| Owner | Health Intersections |
+| Issue tracker | https://github.com/HealthIntersections/FHIRsmith/issues |
+| Target standard | WCAG 2.0 Level AA (at least) |
+| Conformance status | Target only - not yet evaluated |
+| Last reviewed | 2026-11-05 |
+
+## Commitment
+
+FHIRsmith aims to be usable by everyone, including people who use assistive
+technologies such as screen readers, screen magnifiers, voice control and
+keyboard-only navigation.
+
+We aspire to ensure that the FHIRsmith web UI meets the
+[Web Content Accessibility Guidelines (WCAG) 2.0](https://www.w3.org/TR/WCAG20/)
+at Level AA, at least.
+
+Our approach is to make the default HTML accessible wherever we can do so
+without significantly degrading the usual user experience (e.g. semantic
+markup, table headers, form labels, keyboard access, not relying on colour).
+
+Where meeting the guidelines would make the usual experience significantly
+worse (e.g. dense tables or interactive tree views), FHIRsmith will provide
+an option (a checkbox in the UI) that switches the generated HTML to a form
+that does meet them. The setting applies to all pages for the remainder of
+the user's session.
+
+## Scope
+
+### In scope
+
+The **web user interface** that FHIRsmith presents in a browser: the home
+page, the module pages (tx, packages, registry, xig, publisher, ips, shl,
+testing etc.), and the HTML renderings of resources.
+
+### Not in scope
+
+FHIRsmith is primarily a server. Most of what it does is provide FHIR APIs
+(terminology, packages, registry, etc.) that are consumed by other software,
+not by people directly. Those APIs return machine-readable content (JSON, XML,
+npm packages), and their accessibility is the responsibility of the client
+applications that present that content to users.
+
+### Third-party content
+
+Some HTML content shown by FHIRsmith (e.g. resource narratives) is authored
+by third parties and published in packages. FHIRsmith presents that content
+as provided and cannot guarantee its accessibility. Accessibility problems in
+that content should be reported to the publisher of the package concerned.
+
+## Conformance Status
+
+**Target only.** Conformance has not yet been formally assessed, and no
+claim of conformance is made.
+
+## Known Limitations
+
+Pages have not yet been reviewed. Areas that are likely to present
+difficulties include:
+
+* Large tables (e.g. value set expansions, package listings, search results)
+* Interactive tree views and editors
+* Colour used to convey status
+
+This section will be updated as pages are reviewed.
+
+## Checking Pages
+
+Setting `accessibility.checkPanel` to `true` in the server's config adds an
+accessibility check panel to the bottom of every page. Pressing its button
+checks the page as it is in the browser at that moment:
+
+* Against WCAG 2.0 A and AA, using [axe-core](https://github.com/dequelabs/axe-core)
+* For heading structure (exactly one top level heading, which comes first,
+  and no skipped levels), labels that point at nothing, accesskeys,
+  placeholder alt text, generic link text, and click handlers on elements
+  that can't be reached from the keyboard
+* For links distinguished from the surrounding text by colour alone
+
+Problems are reported by HHS Section 508 checklist item, and marked on the
+page. axe-core is only loaded when the button is pressed. Like all automated
+checks, these find only some problems.
+
+## Reporting an Accessibility Barrier
+
+If you find part of the FHIRsmith web UI that is difficult or impossible to
+use with assistive technology, please
+[create an issue on GitHub](https://github.com/HealthIntersections/FHIRsmith/issues)
+and include "Accessibility" in the title. Helpful details include:
+
+* The URL of the page
+* What you were trying to do
+* The browser and assistive technology (and versions) you were using
+* What happened, and what you expected
+
+Accessibility issues are treated as bugs, not feature requests.
+
+## Contributor Requirements
+
+Contributions that improve accessibility are welcome. When contributing
+changes to the web UI, please:
+
+* Use semantic HTML (headings, lists, `<table>` with `<th>`/`scope`, `<label>` for form controls)
+* Make sure everything works with the keyboard alone
+* Provide text alternatives for images and icons
+* Don't rely on colour alone to convey meaning
+* If the page has an accessible-mode variant, check that it still works
+
+## References
+
+* [WCAG 2.0](https://www.w3.org/TR/WCAG20/)
+* [ACCESSIBILITY.md template](https://mgifford.github.io/ACCESSIBILITY.md/)
+* [Open Source Accessibility Framework](https://open-source-accessibility.github.io/Open-Source-Accessibility-Framework/foundational)

package/CHANGELOG.md

@@ -5,6 +5,155 @@ All notable changes to Health Intersections FHIRsmith will be documented in this
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [1.0.0] - 2026-11-12
+
+**Upgrading**: a big upgrade - every operator should check their settings, though some might not need to change any. See [Upgrading to 1.0.0](CONFIGURATION.md#upgrading-to-100) for what to check.
+
+Major new features:
+
+- Cluster mode: a master and several tx-workers on one machine and data directory, so terminology can use more than one CPU core (`node cluster.js`, see [cluster.md](cluster.md))
+- Memory protection: a memory guard that refuses new requests (503) when memory is short and aborts running operations near the limit, caps on the caches that could grow without bound, VSAC value sets read on demand, and SNOMED CT caches optionally memory-mapped
+- Lots of performance improvements, particularly in `$expand` paging, `$validate-code` and `$batch-validate-code`
+- Lots of bug fixes around terminology handling (SNOMED CT, LOINC, RxNorm, supplements, filters, limits)
+- Ecosystem resolution: `$validate-code` for code systems this server doesn't have, by asking other servers in the terminology ecosystem
+- Package signatures: npm registry signatures, and publishers' signatures checked by the crawler
+- IPS module
+
+### Security
+
+- Publisher: the administrator (`admin`) was created with a fixed password, `admin123`, and there is no page to change a password. Its password is now the module's `adminPassword` setting, set at every start; without one, the administrator gets a random password (a UUID), which is logged. An administrator that still has `admin123` is given a random one at startup
+- Parsers have depth and size limits: ECL, VCL, SNOMED CT expressions and UCUM units nested past the limit were a stack overflow (RangeError) rather than a parse error, and an unterminated VCL filter list looped until memory ran out
+- SNOMED CT ECL `wild:` terms are matched with re2js: as native regular expressions, a term with many `*`s took exponential time
+- Token module: the session cookie is `Secure` when the request came over https (`req.secure`, which follows nginx's `X-Forwarded-Proto` with `server.trustProxy`; `cookieSecure` overrides). It depended on `NODE_ENV`, which nothing set, so it was never Secure
+
+### Added
+
+- `config.json` may have comments: `//` to the end of the line, and `/* ... */` (`library/config-reader.js`). A syntax error is reported at its line and column in the file
+- A LICENSE file (BSD 3-Clause); the package's licence is now the SPDX id `BSD-3-Clause` (was `BSD-3`)
+- Memory guard (`server.memory`): above `rejectFraction` (0.85) of the memory limit (the cgroup's - systemd `MemoryMax` - or else the machine's RAM) new requests get 503 + `Retry-After`; above `abortFraction` (0.92) running operations are aborted (422 too-costly). While it refuses, it forces a GC (so start node with `--expose-gc`, as `npm start` and the Docker image now do), and, with `trimAllocator` (on by default only with a role), returns the C allocator's free memory. A client that disconnects, or a memory abort, now stops the whole operation, `$batch` and `$batch-validate-code` included
+- Accessibility: [ACCESSIBILITY.md](ACCESSIBILITY.md) (the target is WCAG 2.0 Level AA, at least), and `accessibility.checkPanel`, a button at the bottom of every page that checks the page against WCAG 2.0 A/AA (axe-core, loaded only when pressed) and its heading structure
+- The largest request body the server accepts is a setting, `server.maxBodyMB` (default 50, as before; about 36x the largest IG Publisher request seen on build.fhir.org, 1.39 MB)
+- Packages
+  - `/packages/feed-check` - enter a package feed's URL, and it is read the way the crawler reads it, with nothing stored: for each item, the package (downloaded and checked as the crawler checks it), whether the registry's package-restrictions allow it from that feed, its signature, and whether the registry already holds it (and if it's the same bytes); or what's wrong with the feed itself. The feed's signing keys can be given as JSON (its package-feeds.json `signing` block), to test a feed before its keys are registered. Runs in the background (the report page reloads until done), one at a time, SSRF-guarded, http(s) only (`feedCheck` settings)
+  - publishers' signatures. A package can be signed by its publisher (the IG Publisher does, with a key configured in `fhir-settings.json`): a partner file, `{package}.tgz.sigstore.json`, linked from the feed item by `fhir:signature`, checked against the keys `package-feeds.json` lists for the feed (`feeds[].signing`). `crawler.signatures`: `ignore`, `check` (the default: a signature that fails is logged and the package stored anyway, unless the feed says `signing.required`) or `require` (unsigned or badly signed packages are refused, and feeds that list no keys aren't read). Packages already held are checked against their stored bytes when their feed first carries a signature. Each signature file is kept, as checked, in a new `PackageSignatures` table, and the HTML package lists show each version's signature as confirmed, rejected or absent. The package document has `dist.fhir-signature` (`url`, `status`, `keyid`) for each version with a signature, and `/packages/-/fhir/v1/signatures/{name}@{version}` serves the signature as fetched. Not `dist.attestations`, which npm would fail to verify (see the packages readme)
+  - npm registry signatures, so `npm audit signatures` can check packages installed from the package server. Each version in a package document now has `dist.integrity` (sha512 SRI) and `dist.signatures` (ECDSA P-256 over `{id}@{version}:{integrity}`, as the npm registry signs), and `/packages/-/npm/v1/keys` lists the key. The signature is the registry's, so every version is signed, wherever it was crawled from. On by default (`npmSigning.enabled`); the key is `npmSigning.keyFile`, default `npm-signing-key.pem` next to the database, made at startup if it isn't there. Versions are signed when stored; existing ones are signed in the background at startup (progress in `/packages/status`), and the keys endpoint is a 404 until they all are. Integrity and signatures are in a new `PackageDist` table. `/packages/npm-check` checks signatures too, when the registry lists keys
+- Terminology Ecosystem
+  - OAuth2 client credentials (`oauth`, by server code) for servers that need a token to be scanned (NZHTS); such endpoints are reported as `security: oauth`
+- Terminology
+  - A `fhirsmith-cluster` command (`cluster.js`), alongside `fhirsmith` (`server.js`), for a global npm install
+  - Cluster: the daily report has a Cluster paragraph: when the launcher started; for each process that exited or was recycled, how many times and why, how long it was unavailable, and the requests lost to it (504, 502, cache-ids that came while it restarted); and the requests the launcher refused itself (503) and the connections it closed for write timeouts. The launcher sends the master what it saw over IPC, and the master keeps it in `stats.db` (`cluster_events`)
+  - Cluster: `server.js --role=master|tx-worker` (`--instance-code`, `--port`), and a launcher, `cluster.js`, that starts a master and tx-workers (by default, as many as the CPU cores and the memory limit allow) and sends each request to the right process. The master runs every module; the tx-workers answer terminology requests, opening the master's databases and caches read-only, and never building or downloading them. Settings are in `server.cluster` (see [cluster.md](cluster.md)): with a role a process listens on 127.0.0.1 (`bindAddress`); options `sharedCache` (the `$cache-control` caches in one SQLite file, `databases/resource-cache.db`, at most `sharedCacheMaxMB`, default 256, so any process can answer any cache-id) and `sharedClosure` (every process answers `$closure`), both off by default. The home page and dashboard graph every process, and count every process's requests. With no role, nothing changes
+  - SNOMED CT: how each edition's cache file is loaded is set in `modules.tx.snomed`: `load` = `read` (the default, as before) or `mmap` (memory-mapped, so pages are only resident when used and can be dropped under memory pressure; needs the optional dependency koffi, and falls back to read where mapping isn't available), `prewarm` (editions mapped and read through once at startup, in the background) and `read` (editions always read into memory). The memory guard leaves out the file-backed pages of mapped editions
+  - LOINC: the `answer-list` filter (`answer-list = [LA code]`: the answer lists the answer is in), as agreed with LOINC (UP-645) and tested by the tx-ecosystem `loinc-*-filter-answer-list` tests. `answers-for` is the defined filter for the answers in a list; `LIST` is still accepted, for backwards compatibility only
+  - Extension-codes supplements: a code in a code space the code system reserves for users (`codesystem-reservedCodeSpace`, a regular expression) is a valid code, whether or not anything defines it; with nothing defining it, its display is the code space's `default-display`, or 'User-assigned', and (as a placeholder) another display only gets an information issue. An `extension-codes` supplement in scope defines such codes, with their displays: a global one as if the code system defined them (a different display is an error, or a warning with lenient display validation), one that is referenced as a display that isn't the only correct one (a different display is a warning). Codes from supplements are only in an expansion when the value set lists them. ISO 3166's user-assigned codes work the same way: an extension-codes supplement's display replaces the 'User-assigned' placeholder. So do ICF's qualified (post-coordinated) codes and SNOMED CT post-coordinated expressions (matched as written, or in their minimal rendering): an extension-codes supplement's display is the code's display, and the generated one stays valid
+  - Reserved code spaces: an expansion of all of a code system that reserves code spaces (`codesystem-reservedCodeSpace`) is marked unclosed (`valueset-unclosed`, with the reason), since `$validate-code` accepts codes in those spaces that the expansion can't list
+  - Terminology: `$cache-control` mode=start also returns the issued cache-id in the `X-Cache-Id` response header (the body is unchanged), so a request log taken at the proxy (nginx `$sent_http_x_cache_id`) can tie each cache-id to the request that created it, for replay
+  - Terminology: `$validate-code` (CodeSystem and ValueSet) warns when a coding has no version but its code system says `versionNeeded = true` (`CODESYSTEM_VERSION_NEEDED`); a version pinned by the value set or by the parameters doesn't count, since it's specific to that context and doesn't travel with the coding
+  - Ecosystem resolution (`modules.tx.ecosystem`, off by default): for a code system (or version) this server doesn't have, `$validate-code` against a value set asks the ecosystem registry which server has it, and asks that server (a `$lookup` per code, a `$validate-code` per filter). Servers can be excluded, as can code system patterns; API keys and OAuth client credentials can be given per server; requests are SSRF-guarded; answers are cached for an hour. Requests that had to ask another server are counted and graphed separately (External requests). See tx/README.md
+  - `$translate`: `targetScope` - with a `targetSystem`, a code system's own targets are held to the value set; without one, the maps into the code systems the value set draws on are used (how a national SNOMED CT edition is translated to the International Edition a value set is built on), and what they give is held to the value set. A source version that is a SNOMED CT edition with no date is the release it resolves to
+  - TerminologyCapabilities marks the version of each code system that a request naming no version gets (`isDefault`)
+  - Terminology: Resource pages link codes to their code system's browser: SNOMED CT (to the edition, when the browser has it), LOINC (codes, parts and answers), RxNorm (RxNav), the NCI Thesaurus (EVS Explore) and ICD-11 (the WHO browser; a postcoordinated expression links to its stem)
+  - SNOMED CT: the `display` `regex` filter (VSAC uses it): every concept with an active description (not only the preferred term) that the pattern matches, whole and case-sensitively, in one language - the request's, else the edition's default. The scan is cached as for ECL
+  - SNOMED CT: `concept` filters `descendent-leaf` and `is-not-a`, and `code` is accepted as the same property as `concept` (value sets in production use it)
+  - SNOMED CT `$lookup`: `sufficientlyDefined`, `semanticTag` and concrete values (typed by the MRCM range); the module is `moduleId` (`module` still works); the normal forms are returned when asked for by name
+  - CodeSystem resources: the `descendent-leaf` filter
+  - `modules.tx.pruneTerminologyCache` (default false): once the library and the endpoints' core packages have loaded, what in `terminology-cache` wasn't used is deleted - the `.db` and `.cache` files (with their SQLite side files) and the package folders (old versions, packages no longer in the library, core packages of FHIR versions no endpoint has, failed downloads) - and what was freed is logged. Not other files or folders, not anything changed in the last day, and in a cluster only the master
+- IPS
+  - a Structure view (after Narrative) showing a document's logical structure as an expandable tree: what the Composition refers to, then its sections, each with its entries and what else it refers to, and each resource referred to expanding into its own references. A reference that doesn't resolve in the document is `not-in-document`; a resource already shown isn't expanded again
+  - a nationality step (the first), which decides the document's nation from what it claims (US and AU so far), shown as a flag on the document page and a Nation column on the project page
+  - an analysis step and view - for each resource and section: its extensions (with their definitions, found through the validator), modifier extensions and `implicitRules`, inactive, entered-in-error and unknown statuses, a subject that isn't the document's, dates in the future where one isn't expected, and negation patterns (no known allergies and the like, US Core and IPS styles)
+  - the Narrative view switches between the narrative as provided and the one the server generates; the daily report has an IPS section
+  - `modules.ips.validator.autoLoadPackages` (default true): the validator finds and loads the package that defines an extension it doesn't have
+- READMEs for the publisher, xig and vcl modules, from their settings
+
+### Changed
+
+- The server keeps idle connections open for 65 s (`keepAliveTimeout`; `headersTimeout` 66 s), longer than nginx's 60 s upstream keep-alive: Node's 5 s meant nginx sometimes reused a connection as Node closed it, and a POST then got a 502
+- `node server.js` with `--port` or `--instance-code` but no `--role` stops with an error (they were ignored)
+- `NODE_ENV` defaults to `production` when it isn't set (`npm run dev`: `development`), so Express's error pages no longer include stack traces on a server where nobody set it
+- `npm start` (and the Docker image) run `node --expose-gc server.js`, for the memory guard
+- Dependencies: re2js, koffi (optional, for memory-mapped SNOMED CT), fhir-validator-wrapper 1.7.0, mongoose 9.12.1; rimraf is gone
+- Dashboard: the FHIRsmith release and npm audit's result are one line above "More", with low disk space (under 10% free, still also a problem) in red on the same line (on the home page too, which has no npm audit line); the graphs' key is under "More"
+- Status page (`/` and `/dashboard`): one line (requests, uptime, heap, and problems only when there are any), with the detail - a panel of tiles, a memory meter against the memory guard's thresholds, the caches - under "More"; the graphs are one component for every server, with a line per process in a cluster
+- `config-template.json` has every module turned off: set `"enabled": true` on the ones you run
+- The npm package for FHIRsmith leaves out the release scripts and test reports, and what git ignores (npm doesn't read `.gitignore` when there is a `.npmignore`, so a local `npm publish` included, for one, `private/`)
+- Terminology
+  - `$expand` limits: the defaults are now 10000 codes returned (`externalLimit`, was 3000) and 100000 built (`internalLimit`, was 10000). The three expansion limits (`externalLimit`, `internalLimit`, `walkLimit`) are checked at startup - whole numbers above 0, external <= internal <= walk - and logged. The tx-ecosystem test runner (User-Agent `Tools/Java`) is no longer held to the old defaults: it gets the same limits as any client, and the tests that depend on a limit set `X-TOO-COSTLY-THRESHOLD`
+  - `$expand`: a page (`count` and `offset`) can lie past the expansion limit. Only the page is built; the codes before it are passed keeping only their keys, so `offset + count` is limited by a new, larger `walkLimit` (default 10 x `internalLimit`), and `count` by the expansion limit as before. Over the walk limit: 422 too-costly, `VALUESET_TOO_COSTLY_PAGE`. Value sets with an exclude are paged too (see below); a request with a text filter is as before. Any page, the first too, builds only its own codes: the rest are counted, by key, for the total (reported, as before, only when the whole expansion is within the limit), so a `count=20` first page of a large value set no longer builds codes up to the limit
+  - `$expand` of a code system that caps how many of its codes an expansion may list (`expandLimitation`: CPT, 1000, by agreement with the AMA): no page has codes past the cap, but the total is all the codes (as for `count=0`), and the walk stops at the cap. When the cap keeps codes off the page asked for (e.g. `count=1100`), the expansion says why: a new `expansion-issue` extension refers to a contained OperationOutcome with a business-rule warning (`VALUESET_EXPANSION_CODESYSTEM_LIMITED`). (`addExpansionIssue` is the general mechanism, for other things users of an expansion should know)
+  - `$expand`: every expansion is held to the limits. A value set with an exclude was exempt from the response limit, and an imported value set's codes didn't count against it, so a value set with an exclude or an import came back whole whatever its size (and an imported value set with an exclude escaped the internal limit). Now they are limited, and paged, like any other: an expansion that used to succeed may now be a 422 too-costly, and should be paged (`count` and `offset`). `count=0` still only counts
+  - Global supplements: a code system supplement is used without being referenced when it is a `lang-pack` or `extension-codes` supplement (`codesystem-supplement-type`) marked with `codesystem-supplement-global` = `true`. The `global-lang-pack` code (0.18.1) is gone, and a `lang-pack` supplement that isn't marked global is only used when it is referenced, like any other supplement
+  - VSAC value sets are read from the database when asked for, with the recently used ones kept parsed (`vsacCfg.valueSetCacheMB`, default 64), instead of all ~40,000 being held in memory (about 1 GB); a search reads only the value sets on the page returned
+  - SNOMED CT: a loaded edition uses its cache file's sections in place, rather than copies, so it takes its file size in memory, not twice that
+  - `$expand` builds only what it returns: a page's codes (the codes before it are only walked, the codes after it counted, or totalled by the provider), and only the codes it returns from an imported value set
+  - Performance: supplements are indexed by the code system they supplement (scanning every CodeSystem was 18-24% of CPU under IG Publisher traffic); a code system provider is built once per operation, not once per include or code; a code not in an enumerated include is located once; a response is serialised once; each cache-id's resources are hashed once; long operations give other requests a turn every 10 ms of compute (was 25), as do `$batch-validate-code` between entries and the usage tracker's startup scan; `$batch-validate-code` releases each entry as it is answered; RxNorm has an index on `RXNATOMARCHIVE(RXCUI, SAB)`, added to an existing database at load (an unknown code scanned ~372k rows); `$closure` can use a provider's ancestor sets (`ancestorsOf`)
+  - `x-too-costly-threshold` can't be more than `internalLimit` (a bigger value is cut down to it), and a value that isn't a positive whole number is ignored: there is always a limit (`0` meant no limit)
+  - `$cache-control`: caches are never carried over a restart. With an `instanceCode`, a cache-id carries the process's start, so a request with a cache-id from before a restart is told the cache was lost to a restart (404 `cache-id-unknown`)
+  - ValueSet pages list the first 500 codes of an include or exclude, with "Show all" (`_showAll=true`); VSAC's Medication Brand Name was 33,341 rows, each looked up
+  - The code system provider API (`tx/cs/cs-api.js`) has optional hooks for providers: `handlesSelecting`/`processSelection` (now called, with the value set as context, and may refuse as too costly), `prefetchCodes`, and `ancestorsOf`
+  - LOINC importer: every linguistic variant's language is loaded, and the variants' axis columns become `PartName` designations on the Parts (for some languages, e.g. ko-KR, the only translations LOINC has); relationships the source files repeat are stored once; the import runs as one transaction (much faster)
+  - `$expand` `designation` parameter: a bare code (or `|code`) matches a language, or a use code from any system; `system|code` works as before
+- IPS
+  - on a document's page the actions (Edit, Share, Process again, Delete) are on their own line below the processing pipeline, and Edit is a button like the others
+  - `fhir-validator-wrapper` 1.7.0; the validator is no longer passed `checkIpsCodes` (validator 7.0.4 refuses it, failing every validation)
+
+### Fixed
+
+- A `config.json` with no `server` block failed at startup; every setting in it has a default
+- The home page's folder module entry wasn't closed (`</li>`)
+- Lint: the errors in the project's own code are fixed, and the vendored jQuery files are no longer linted, so `npm run lint` has no errors
+- The release workflow's test job has the heap size that `ci.yml` gives the tests (the suites outgrow Node's default)
+- Terminology
+  - SNOMED CT importer: effectiveTimes were stored a day early when a cache was built in a time zone ahead of UTC (the day count to the 1899 epoch used local dates), so `$lookup` reported e.g. 2002-01-30 for 20020131. Caches built in such a zone need rebuilding
+  - `CodeSystem/$batch-validate-code`: a top-level `url` (and `version`) is the code system for every entry, as for `CodeSystem/$validate-code`, and every entry is validated against a code system - an entry with its own `url` was validated as a value set
+  - `regex` filters match the whole value, for every code system: the pattern is `^(?:pattern)$`. Code systems from CodeSystem resources, ISO 3166 and filters on supplement properties anchored it as `^pattern$`, so an alternation went wrong (`code2|code3` matched every code starting with code2); LOINC matched anywhere in the value (a CLASS regex of `CYTO` matched PANEL.HL7.CYTOGEN). LOINC regex filters may now select fewer codes
+  - ValueSet `$validate-code` with `activeOnly=true`: an inactive code was only rejected when the value set includes all of its code system; when the value set lists the code, or selects it with a filter, it was valid (with an inactive warning). It is now not in the value set whatever the include, for every code system
+  - Only one version of a supplement applies: when the server has one version and the request passes another in `tx-resource` (or a value set names one and the request another), the version the request asks for by version (`useSupplement url|version`, or the value set's `valueset-supplement`) is used - else the request's own, else the latest - and `used-supplement` reports that exact version. Both were applied before, and the server's version was the one reported (and whose displays won)
+  - ValueSet `$validate-code`: a code found through a value set filter didn't report a status the code has while active (`deprecated`: no `status` parameter and no `DEPRECATED_CONCEPT_FOUND` warning), as it does when the value set lists the code
+  - `$expand` text filters (`filter`) now search one language: the first language the request asks for (`displayLanguage`, else `Accept-Language`) that the code system has text in, else the code system's own language - the same rule as the SNOMED CT display filter. All the displays and designations in that language take part, including those from supplements in use; designations in other languages no longer match. LOINC searches its names in other languages (`filter=Volumen&displayLanguage=de` finds Glucose [Masse/Volumen] in Serum oder Plasma) and supplement designations (Uzbek); in English it still searches the displays. SNOMED CT builds a text index per language on editions with more than one (the first search in a language takes a second or two), and a national edition with no language asked for searches its default language
+  - A value set filter on a property that a supplement in use defines (`catalog-group = renal-diabetes` on LOINC or SNOMED CT, with a supplement giving codes a `catalog-group`) failed (500 for LOINC and SNOMED CT, 'not understood' for code systems from CodeSystem resources). Such filters are now evaluated from the supplement, for any code system, in `$expand` (includes and excludes) and `$validate-code`, alone or with the code system's own filters (=, in, regex and exists = true can select codes on their own; not-in and exists = false only narrow other filters). A filter the code system does itself still goes to the code system
+  - Supplements pinned to a version of their code system (`supplements` = `http://loinc.org|2.80`) were applied to whichever version a request without a version resolved to (LOINC 2.83), and reported as used; a value set requiring one didn't fail. Which supplements apply is now decided by the version actually used: one pinned to another version is not applied (so requiring it fails with `VALUESET_SUPPLEMENT_MISSING`), and one from the server's own content pinned to that version now applies when the request doesn't name a version
+  - `$expand` returned no properties for codes from LOINC, SNOMED CT, RxNorm, UCUM, OMOP, CPT or NDC, whether asked for with `property`, `ValueSet.compose.property` or `*` (`$lookup` returned them): these code systems now report the requested properties on each code, as `$lookup` does, and only compute them when some are asked for. UCUM's `canonical` property is returned when asked for (`$lookup` never returned it). An R4 expansion declared a property with no uri with an empty uri extension. OMOP codes from a filter were JSON numbers in an expansion
+  - LOINC: `$lookup` of a claims attachment term (CLASSTYPE 3: 18719-5, 19005-8, 26436-6... - 1,161 of them) failed with a 500 ('valueString must be a string, not a undefined'), and a `CLASSTYPE = 3` filter selected nothing: the importer stores the class type as 'Claims attachment', and the provider only knew 'Claims attachments'. CLASSTYPE is now reported as 3 with the description 'Claims attachment', and the filter selects those terms
+  - The too-costly error (`VALUESET_TOO_COSTLY`) for a value set passed in the request with no url named it 'undefined' or '??'; it now names it by its id, or says it's the value set in the request
+  - A value set with a modifier extension the server doesn't know (on the value set, its compose, an include or exclude, a filter or a listed concept - e.g. VSAC's `vsacOpModifier` on a filter) was refused with a 500. It's a problem with the value set, not the server: `$expand` and `$validate-code` now refuse it with a 422 (`VALUESET_MODIFIER_EXTENSION_UNKNOWN`, `vs-invalid`) naming the extension. A resource with implicit rules is refused with a 422 too
+  - `$expand`: a value set that carries an expansion (one sent as a `tx-resource`, or from a package), whether expanded itself or imported by another, was answered from that expansion, even when it was made from other code system versions than the request asks for (`force-system-version` etc.) or the server has - the opioid-cds IG's value sets got 1,733 codes from stale LOINC 2.82 expansions instead of 2,221 from 2.83. A value set with a compose is now expanded from its compose, as the Java expander does. Its stored expansion is only used when it has no compose, or when a code system the compose includes isn't available here (not loaded, or not the version the include names), so the compose can't be expanded
+  - Search (`CodeSystem?`, `ValueSet?`, `ConceptMap?`): the `version` parameter matched any version containing it (`version=0` found 3.0.0). It is now matched version-aware: exactly, or with wildcards for a semver version (`3.0.x`, `3.x.x`), or as a prefix for others (`2024-01` finds 2024-01-15), using the resource's versionAlgorithm when it has one
+  - Search: the `url` parameter is a left match (the url starts with the value, case-sensitive) for ValueSets and ConceptMaps. A ValueSet url had to match exactly, and a ConceptMap url matched anywhere in the url
+  - VSAC: a value set asked for at a version VSAC doesn't have (`valueSetVersion=19990101`) was answered from its latest version; it is now not found, as a value set from a package is (#94). `VSACValueSetProvider.VERSION_FALLBACK_TO_LATEST` brings the old behaviour back
+  - The expansion caches could fill the heap under steady load (a replay of IG Publisher traffic ran a server with node's default heap out of memory in 7 minutes: 1,000-code pages of whole-SNOMED CT expansions, about 0.8 MB each). The memory threshold (`expansionCacheMemoryThreshold`) was only checked every 5 minutes. The caches of all the endpoints now share a budget of codes (`expansionCacheMaxCodes`; default a quarter of the heap limit at 1 KB a code, about a million codes with a 4 GB heap): each expansion is counted as it's cached, and the least recently used ones are dropped, from whichever endpoint, to stay under it. An expansion bigger than the whole budget isn't cached. The caches also drop entries in least recently used order without sorting
+  - ValueSet `$validate-code` with `inferSystem`: when the value set includes a code system that isn't known, the request failed with a 500 ('Exception expanding value set in order to infer system') if the value set also imports a value set, and otherwise reported that the system couldn't be inferred. The system can't be inferred when the code might be in a code system that isn't known, so it is now a 422 naming that code system (`UNABLE_TO_INFER_CODESYSTEM_UNKNOWN_SYSTEM`). The same applies to the value sets it imports
+  - ValueSet `$validate-code` with `inferSystem`: a value set that imports another value set was expanded to find the code's system, which failed with a 500 when the expansion was too big (an import of all of UCUM: 'too many codes to produce (>10000)'), and cost as much as the value set was big when it wasn't. The system is now found by checking the code against each include, and each include of the value sets it imports, less the value set's excludes, without expanding anything
+  - `$expand` of a value set that lists its codes (as VSAC value sets do), when the codes are more than the expansion limit: `count=0` (the total only) was refused as too costly (422), and a full expansion was refused only after the codes up to the limit had been built (displays, properties) - 0.1 to 3 s for some VSAC value sets. With `count=0` the listed codes are now counted without being built, when every include lists its codes, so the total is returned whatever the limit; otherwise the listed codes are counted first, and an expansion they would take over the limit is refused before any is built (a page that fits within the limit is still served)
+  - Client side caches (`$cache-control`) had no size limit: only idle ones were dropped, so a cache in use could grow without bound, and 500 caches of a 20,000-concept code system ran the server out of memory. A cache may now hold at most `cacheMaxConcepts` concepts (default 250,000, about 10x the largest IG Publisher session measured on build.fhir.org, 24,048): a request that would take it over is not performed: the cache is dropped and the request gets a 404 with one issue coded `cache-id-unknown` (`CACHE_ID_DISCARDED_TOO_BIG`: the cache grew too large and was dropped; start a new cache), as for any cache that is gone, so the client starts a new cache and sends the request again (a later request with that cache-id gets the same 404, saying why it was dropped). A request whose own resources hold more than `cacheMaxConcepts`, which no cache could take, is refused (422 too-costly) and the cache is kept. An endpoint's caches hold at most `cacheMaxTotalConcepts` between them (default 1,000,000, 4 full caches), and the least recently used caches are dropped to stay under it; a request with a dropped cache-id is told so (404 `cache-id-unknown`). 0 = no limit, for either
+  - The usage tracker (behind the `usage-count` expansion property) kept every system and code a `$validate-code` was asked about, forever: validating unique made-up codes grew the heap by 10 MB a second. It now records only valid codes, at most `usageTrackerMaxCodes` of them (default 1,000,000, 2x the about 500,000 a full library's value sets list), none longer than `usageTrackerMaxCodeLength` characters (default 100, 2.5x the longest of those, 40). 0 = no limit
+  - The cache of parsed language tags kept every valid tag forever, and private use tags (`en-x-...`) of any length are valid: unique 8 KB tags in requests grew the heap by 46 KB each. It now keeps the `languageTagCacheSize` tags used most recently (default 1,000: at most about 46 MB of 8 KB tags). 0 = no limit
+  - The tx module logs its memory limits at startup, on one line (`Limits: operationTimeLimit=20s, cacheTimeout=30min, cacheMaxConcepts=250000, ...`)
+  - VSAC: a sync cut short when the server stopped left the cache partly filled until the next scheduled refresh (24 h), since a sync only ran at startup when the cache was empty. At startup the server now carries on with a sync that was interrupted or failed: a sync keeps its work list and how far it has got, and the next one does the value sets that weren't finished first (including one that was part way through its versions, which a fresh listing wouldn't find), then whatever else has changed. A run left marked running is recorded as interrupted. A failed startup sync no longer stops the refresh timer from starting
+  - A tx endpoint answered a request body over the size limit with Express's HTML error page; it now answers with a 413 OperationOutcome (too-costly), in the format the client asked for
+  - SNOMED CT: inactive relationship rows are ignored (agreed with the SNOMED leads; they are still imported) - property filters, ECL refinements, is-a and subsumption, and `$lookup`'s properties, parents and children used them
+  - SNOMED CT: `concept in` a list of plain concepts selected nothing (only reference sets in the list worked); spaces after commas and concepts named twice are handled too
+  - SNOMED CT implicit value sets: the generic form (`http://snomed.info/sct?fhir_vs...`) is resolved against the edition the request asks for (`system-version` and the like), checking the named concept or reference set there, not the default edition; an edition or version named in the url still wins
+  - SNOMED CT `$lookup` `property=*`: every property but the normal forms (and ancestors and descendants), which have to be asked for by name
+  - RxNorm: filters in one include are ANDed (two of the same kind both apply); results and totals count concepts, not atoms; the display is the concept's main atom; `concept in` lists codes, and `code` is accepted as `concept`; relationship filters with `in`; a concept whose display atom is obsolete (`SUPPRESS = O`) is inactive; `$lookup` returns TTY, STY and SAB by default, and RxNorm's own relationships (SAB = RXNORM) with `*` or by name, valued with the bare RXCUI
+  - `$expand` of a value set that includes one version of a code system and excludes another whole version of it: an included code is excluded when the excluded version has it (the excluded version's codes aren't listed, since most providers can't list theirs)
+  - `$expand` from a code system with no content (`not-present`, e.g. THO's time-period-ranges) is a 422, not a 500
+  - A cached expansion made under one request's `x-too-costly-threshold` could be served to a request with another: the limit is now part of the cache key
+  - `CodeSystem/$validate-code` never answered (the connection was held until the client gave up) when an issue was raised before validation started, such as an unknown cache-id
+  - `$validate-code` of a CodeableConcept: the display reported is the reported coding's own, not one from a coding before it; when the code is in no include, the code systems' reasons (an error from another server, say) are reported
+  - An exception in a SQLite callback left the request hanging with no response; now it fails the request, in every module
+  - SQLite connections leaked: `CodeSystem/$validate-code` (and batch entries with no value set) never closed its provider, nor did a request that failed `check-system-version`
+  - A supplement's designations matched a text filter when they had any of its words; they need every word, as the code system's own do
+  - LOINC importer: each externally defined answer list (65 in 2.83) added an Answer with a blank code, shared by all of them
+  - VSAC: a failed sync stopped the refresh timer for good (it now retries after 1, 5 and 30 minutes); after a restart the next sync is due an interval after the last one, not after the restart (a server restarted more than daily never synced); a `refreshIntervalHours` too big for a timer ran syncs back to back
+  - Packages crawler: mirror files are written to a temporary name and renamed into place (nginx could serve a half-written file), before the registry advertises the package; each package is stored in one transaction
+- Statistics: requests per minute is divided by the real time since the last sample (a late timer showed a higher rate), and only responses the static file handlers send count as static hits
+- Startup: logging starts before `config.json` is read, so a server that fails to start says why in the log as well as on stderr
+
+### Tx Conformance Statement
+
+FHIRsmith v1.0.0 passed all 5230 HL7 terminology service tests (modes tx.fhir.org+omop+general+snomed+mimetypes+icd-11+icf+closure+loinc, tests v1.11.1-snapshot, runner v7.0.5)
+
 ## [0.18.2] - 2026-10-29
 
 ### Added

package/CONFIGURATION.md

@@ -0,0 +1,305 @@
+# FHIRsmith Configuration
+
+The server is configured by `config.json` in the data directory (see
+[Data Directory](README.md#data-directory)), plus a few environment variables.
+`config-template.json` is a starting point: it has every section, with comments, and every
+module turned off - set `"enabled": true` on the ones you run. `config.json` is JSON, except that
+it may have comments: `//` to the end of the line, and `/* ... */`.
+
+Upgrading? See [Upgrading to 1.0.0](#upgrading-to-100).
+
+The top level of `config.json` has the server-wide settings described here, and a
+`modules` section with an entry for each module (see [Modules](#modules)).
+
+## Server
+
+Create a `config.json` file in your data directory (use `config-template.json` as a starting point):
+
+```json
+{
+  "hostName" : "[descriptive name for the server]",
+  "server": {
+    "port": 3000,
+    "cors": {
+      "origin": "*",
+      "credentials": true
+    }
+  },
+  "modules": {
+    // per modules...
+  }
+}
+```
+
+| Option | Default | Description |
+|---|---|---|
+| `server.maxBodyMB` | `50` | Largest request body accepted, in MB. A body is read whole into memory before it is parsed, so this bounds what one request can take. A bigger body gets a 413: an OperationOutcome (too-costly) on a tx endpoint, and the module's own handling elsewhere. The largest IG Publisher request seen on build.fhir.org was 1.39 MB, so 50 leaves plenty of room. The ips module reads its own bodies, with its own limit |
+
+Behind nginx, nginx's `client_max_body_size` is checked first. If it is lower than `maxBodyMB`, nginx refuses a bigger body with its own 413 HTML page before FHIRsmith sees it, so set it at or above `maxBodyMB` to get FHIRsmith's OperationOutcome; if it is higher, `maxBodyMB` applies. Requests of over 100 MB have been seen, caused by client-side issues: choose `maxBodyMB` (default 50) and the nginx limit with that in mind. See [nginx.md](nginx.md).
+
+### Memory
+
+`server.memory` sets the memory guard: fractions of the memory limit (the cgroup limit, such
+as `MemoryMax` on the systemd unit, or else the machine's RAM), measured against process RSS;
+with a role, against the whole cgroup's private memory (see [cluster.md](cluster.md#memory)).
+
+| Option | Default | Description |
+|---|---|---|
+| `server.memory.rejectFraction` | `0.85` | Above this, new requests get 503 + `Retry-After` |
+| `server.memory.abortFraction` | `0.92` | Above this, running operations are aborted with 422 too-costly |
+| `server.memory.trimAllocator` | `false`; `true` with a role | Whether the server returns the C allocator's free memory (`malloc_trim`, Linux) while refusing, and, with a role, once after loading. Without a role it is off unless set `true`; with one, `false` is for diagnosis. See [cluster.md](cluster.md#memory) |
+
+### Cluster
+
+To use more than one CPU core for terminology on one machine, a master and several tx
+workers share the data directory and `config.json` (started by `node cluster.js`, or by hand
+with `--role`). Their settings are in `server.cluster`, documented with the arrangement in
+[cluster.md](cluster.md): the launcher's (`workers`, `maxOutstanding`, `queueSeconds`,
+`recycleSeconds`, the fast lane, ...) under
+[The launcher](cluster.md#the-launcher-clusterjs), and what the processes share
+(`sharedCache`, `cacheAffinity`, `sharedCacheMaxMB`, `sharedClosure`) under
+[Options](cluster.md#options). With no role, `server.cluster` is ignored.
+The status panel's snapshot of every process (`statusSeconds`) is under
+[Status](cluster.md#status).
+
+### Statistics
+
+`stats` sets the request counters and the graphs on `/` and `/dashboard`.
+
+| Option | Default | Description |
+|---|---|---|
+| `stats.enabled` | `true` | `false`: the counters are kept in memory only |
+| `stats.database` | `stats.db` | The counters' SQLite file, under the data folder's `databases` directory |
+| `stats.intervalMinutes` | `10` | How often the counters are written to the database; also the graphs' sample interval, unless `sampleSeconds` is set (a server with no role, as before) |
+| `stats.sampleSeconds` | `intervalMinutes`; with a role, 60 at most | How often the graphs take a sample. With a role (cluster.md), at most a minute unless set, so the graphs of a short session can be read. The graphs show 24 hours; under the launcher at most 1,440 samples a process, so with less than a minute they show less. The counters are still written every `intervalMinutes` |
+
+## Logging
+
+Add a `logging` section to `config.json` to control log behaviour. All fields are optional and have sensible defaults:
+
+```json
+{
+  "logging": {
+    "level": "info",
+    "console": true,
+    "consoleErrors": false,
+    "maxFiles": 14,
+    "maxSize": "50m",
+    "flushInterval": 2000,
+    "flushSize": 200
+  }
+}
+```
+
+| Option | Default | Description |
+|---|---|---|
+| `level` | `"info"` | Minimum level to log: `error`, `warn`, `info`, `debug`, or `verbose` |
+| `console` | `true` | Write log lines to stdout/stderr. Disable when running as a systemd service where console output goes to the journal and is redundant |
+| `consoleErrors` | `false` | Whether `error` and `warn` levels appear on the console. When `false`, errors and warnings are written to the log file only |
+| `maxFiles` | `14` | Number of daily log files to retain before old ones are deleted |
+| `maxSize` | `0` (unlimited) | Maximum size per log file before rotation. Accepts human-readable strings: `"20m"`, `"1g"`, or a raw byte count |
+| `flushInterval` | `2000` | Milliseconds between buffered writes to disk. Increase to reduce I/O under heavy load |
+| `flushSize` | `200` | Number of buffered log lines that trigger an immediate flush regardless of the timer |
+
+Log files are written to the `logs/` subdirectory of the data directory as `server-YYYY-MM-DD.log`. A `server.log` symlink always points to the current day's file, so `tail -f data/logs/server.log` tracks the active log without needing to know the date.
+
+## Email and the Daily Report
+
+The server can email a short markdown report on itself once a day. It needs two things in
+`config.json`: an SMTP server to send through, and someone to send to:
+
+```json
+{
+  "email": {
+    "host": "smtp.example.org",
+    "port": 587,
+    "user": "fhirsmith",
+    "password": "...",
+    "from": "FHIRsmith <fhirsmith@example.org>"
+  },
+  "dailyReport": {
+    "to": ["ops@example.org"]
+  }
+}
+```
+
+`user`/`password` are optional (an open relay); `secure` defaults to true for port 465 and
+to STARTTLS otherwise. Without an `email` block nothing is emailed, and without
+`dailyReport.to` there's no report (`dailyReport.enabled: false` turns it off explicitly).
+
+The report, titled "`{hostName}` daily report", goes out at midnight (the server's local
+time), or as soon as the server is up again if it was down at midnight. It has a paragraph
+on the server's stability since the last report - how much of the time it was up, restarts,
+the longest outage, and any upgrade (from the run history in the statistics database, so
+`stats.enabled: false` leaves the uptime unknown); under the launcher (`cluster.js`), a
+paragraph on the cluster - processes that exited or were recycled, how long they were
+unavailable, and the requests the launcher refused or abandoned itself (see
+[cluster.md](cluster.md#the-daily-report)); a paragraph from each running module that
+has something to report (by default, none do); and a paragraph on the system - version,
+Node.js and OS, how long this run has been up, the log files and the free disk space they're
+drawing on, plus anything the npm audit check has found (packages with known vulnerabilities and
+what to do about them, or a newer FHIRsmith release). If any background task's last run failed, a
+final section lists them. When the last report was sent is kept in `daily-report.json` in the data
+directory.
+
+A module takes part by implementing `dailyReport({since, now})`, returning its paragraph as
+markdown (or a promise of it); an empty return means it has nothing to say that day. The
+request counts a module quotes come from `stats.countsSince(since, now)`, the per-operation
+counts in the statistics database for the period. The modules that report:
+
+| Module | Reports |
+|---|---|
+| Terminology server | how many of each operation were performed, over all its endpoints |
+| Terminology server registry | client requests answered by the API, servers registered, and any server that answered none of the registry's scans in the period |
+| Packages | packages served (tarball downloads) and new package versions found by the crawler |
+| XIG | pages served, and whether the database could be accessed (and whether the last download failed) |
+| Testing | pages served, test reports received, and the number held |
+| SMART Health Links | QR codes created (SMART Health Links and Verifiable Health Links), link accesses, and the documents stored to serve them |
+| IPS | pages served, IPS documents received, and the number stored |
+| Publisher | publication runs started, and how many finished successfully |
+
+## Environment Variables
+
+| Variable | Description | Default |
+|---|---|---|
+| `FHIRSMITH_DATA_DIR` | Path to the data directory | `./data` |
+| `PORT` | Server port (overrides config) | from config.json |
+| `FHIRSMITH_ROLE` | `master` or `tx-worker`, as `--role` (see [cluster.md](cluster.md#roles)). Not set: an ordinary single server | none |
+| `FHIRSMITH_INSTANCE_CODE` | This process's cache-id prefix, as `--instance-code` (see [cluster.md](cluster.md#roles)) | a master: `modules.tx.instanceCode`, and with none it stops with an error; a worker: none, and it stops with an error. The launcher gives `m0`, `tx1`, ... |
+| `FHIRSMITH_WORKERS` | How many tx-workers `node cluster.js` starts, as `--workers` (`server.cluster.workers`) | from the CPUs and memory |
+| `FHIRSMITH_CACHE_WAIT_MS` | How long a tx-worker waits for the master to build a cache it reads (see [cluster.md](cluster.md#what-runs-where)) | `300000` (5 minutes) |
+| `NODE_ENV` | Node environment. Express and other libraries check it (in development mode, Express's error pages include stack traces). If it isn't set the server sets it to `production`, or to `development` when run with `npm run dev` | `production` |
+
+## Modules
+
+Each module has its own entry under `modules`, documented with the module:
+
+| Module | Configuration |
+|---|---|
+| `tx` - terminology server | [tx/README.md](tx/README.md#configuration) |
+| `registry` - terminology server registry | [registry/documentation/configuration.md](registry/documentation/configuration.md) |
+| `packages` - package server | [packages/readme.md](packages/readme.md) |
+| `shl` - SMART Health Links | [shl/readme.md](shl/readme.md) |
+| `ips` - IPS documents | [ips/readme.md](ips/readme.md) |
+| `testing` - test reports | [testing/readme.md](testing/readme.md) |
+| `folder` | [folder/readme.md](folder/readme.md) |
+| `npmprojector` | [npmprojector/readme.md](npmprojector/readme.md) |
+| `token` | [token/security_guide.md](token/security_guide.md) |
+| `xig` | [xig/readme.md](xig/readme.md) |
+| `vcl` | [vcl/readme.md](vcl/readme.md) |
+| `publisher` | [publisher/readme.md](publisher/readme.md) |
+
+## Upgrading to 1.0.0
+
+1.0.0 is a big upgrade from 0.17 and 0.18. Most servers won't need to change any settings, but
+every operator should check these. Each item says who it affects; the [CHANGELOG](CHANGELOG.md)
+has the detail.
+
+### Every server
+
+- **Node.js 24** or later (`engines` in package.json). After upgrading Node, `npm ci` (there
+  are new dependencies) - or `npm rebuild` for the native ones.
+- **Start command**: `npm start` is now `node --expose-gc server.js`. A service that runs
+  `node server.js` still works (the memory guard sets the flag itself), but add `--expose-gc`.
+  `--port` or `--instance-code` without `--role` now stops the server with an error (they used
+  to be ignored): drop them from a single server's command line.
+- **`NODE_ENV`** is `production` when it isn't set (`npm run dev`: `development`). Set it
+  yourself if you relied on development mode (Express's error pages with stack traces).
+- **Keep-alive**: idle connections are kept for 65 s (was Node's 5 s), longer than nginx's
+  upstream `keepalive_timeout` (60 s by default). If you set nginx's higher, keep it under 65 s.
+- **Memory guard** (new, on by default): above 85% of the memory limit (the cgroup's - systemd
+  `MemoryMax` - or else the machine's RAM) new requests get 503, and above 92% running
+  operations are aborted (422). If your memory limit is tight, check `server.memory` ([Memory](#memory)).
+- **Request size**: `server.maxBodyMB` (default 50) is now a setting. nginx's
+  `client_max_body_size` must be at least as big, or clients get nginx's HTML 413 rather than an
+  OperationOutcome.
+- **`config.json` may have comments** (`//` and `/* */`), and `config-template.json` now has
+  every module turned off.
+- **New, optional**: `email` and `dailyReport.to` ([the daily report](#email-and-the-daily-report) -
+  nothing is sent without both), `npmAudit` (a periodic `npm audit` of the server; set
+  `"enabled": false` on a server with no internet access), `accessibility.checkPanel`,
+  `stats.sampleSeconds`.
+- **Cluster mode** (`node cluster.js`, [cluster.md](cluster.md)) is new and opt-in: `server.js`
+  runs as before.
+
+### tx (terminology server)
+
+- **Expansion limits**: the defaults are now `externalLimit` 10000 (was 3000) and `internalLimit`
+  100000 (was 10000), and there's a new `walkLimit` (default 10 x `internalLimit`) for paging.
+  The three are checked at startup: one that isn't a whole number above 0, or
+  external <= internal <= walk not holding, **stops the server**. If you set any of them, check
+  them. Bigger expansions now succeed, so a busy server may use more memory.
+- **Value sets with an exclude or an import are limited** like any other (they used to come
+  back whole, whatever their size): a client that expands a big one unpaged now gets a 422
+  too-costly, and should page it.
+- **`Tools/Java` is no longer special**: the IG Publisher and the tx-ecosystem test runner get
+  the configured limits like any client (they used to be held to 3000/10000).
+- **`x-too-costly-threshold`** can only lower the limit: a value above `internalLimit` is cut
+  down to it, and `0` (or anything that isn't a positive whole number) is ignored - it no
+  longer means "no limit".
+- **Memory caps** with defaults (see the `Limits:` line in the startup log): `cacheMaxConcepts`,
+  `cacheMaxTotalConcepts`, `expansionCacheMaxCodes`, `usageTrackerMaxCodes`,
+  `usageTrackerMaxCodeLength`, `languageTagCacheSize`. A client may now get `cache-id-unknown`
+  (or 422) for a `$cache-control` cache that grew too big.
+- **New, optional**: `snomed` (load SNOMED CT editions memory-mapped, or prewarmed - see
+  tx/README.md), and `ecosystem` (`$validate-code` for code systems held by other servers in
+  the terminology ecosystem; off by default).
+- **`pruneTerminologyCache`** (new, default false): delete the databases, caches and packages
+  in `terminology-cache` that the library no longer uses. Turn it on for a server that has the
+  data directory to itself.
+- **`instanceCode`** is checked at startup, and a cluster master needs one.
+- **VSAC** (`vsacCfg`): the default `baseUrl` is https (an http one is logged as a warning);
+  value sets are read from the database when asked for, with a cache sized by `valueSetCacheMB`
+  (default 64); a value set version VSAC doesn't have is now not found.
+- **Language packs**: a `lang-pack` or `extension-codes` supplement is used without being
+  referenced only when it is marked `codesystem-supplement-global` = `true`. The
+  `global-lang-pack` code is gone. If you load language packs, check they are marked.
+- **Behaviour, with no setting**: `regex` filters match the whole value (LOINC regex value sets
+  may select fewer codes); ICD-11 codes are entity ids; a resource that both THO and a core
+  package provide is available in both versions; for LOINC answer lists, `answers-for` is the
+  filter (`LIST` still works, for backwards compatibility only); `$cache-control` caches are
+  never carried over a restart.
+- **Rebuilds** (optional, for the new features): SNOMED CT caches for alternate identifiers and
+  concrete values, and any built in a time zone ahead of UTC (their effectiveTimes are a day
+  early); the LOINC database for its mappings, its Part translations (`PartName` designations,
+  from every linguistic variant) and without the blank answer code that externally defined
+  answer lists added. RxNorm's new index is added to an existing database at load. Coming from
+  0.16 or earlier, the package value set and concept map caches rebuild themselves once, so
+  the first start is slower.
+
+### Other modules
+
+- **registry**: `maxResponseMB` (default 100) limits what the crawler reads from a server. New,
+  optional: `oauth`, client credentials for servers that need a token to be scanned.
+- **packages**: the crawler refuses packages over its new limits (`maxDownloadMB` 250,
+  `maxUnpackedMB` 4096, `maxFileMB` 50, `maxFiles` 250000); raise them only if a real package
+  is refused.
+- **packages, signing** (on by default, `npmSigning`): the registry signs every version, so
+  `npm audit signatures` works against it. At the first start it makes its key,
+  `npm-signing-key.pem` next to the database (`npmSigning.keyFile`) - **back it up**: clients
+  check signatures against the published key - and signs the versions it already holds in the
+  background (`/packages/-/npm/v1/keys` is a 404 until it's done; progress in `/packages/status`).
+  Set `"enabled": false` to opt out.
+- **packages, publishers' signatures**: `crawler.signatures` defaults to `check` (a signature
+  that fails is logged and the package stored anyway); `require` refuses unsigned packages and
+  doesn't read feeds that list no keys. Feeds' keys are in `package-feeds.json`.
+- **packages, `/packages/feed-check`** (on by default, `feedCheck`): anyone can have the server
+  download and check a feed's packages (one run at a time, at most `maxItems` 50 and
+  `maxTotalMB` 500). Set `"enabled": false` if you don't want that on your server.
+- **xig**: `POST /xig/update` only works when `updateToken` is set.
+- **ext-tracker**: set `token` (the IG Publisher's) so only the publisher can submit.
+- **token**: the JSON API takes the API key in a header (`Authorization: Bearer` or
+  `X-API-Key`), not the URL - clients must change. The session cookie is now `Secure` when the
+  request came over https, which behind nginx needs `X-Forwarded-Proto` (`cookieSecure`
+  overrides).
+- **publisher**: the administrator's password is now `adminPassword` in the config (set at
+  every start). Without it, an administrator that still has the old fixed default password
+  (`admin123`) gets a random one at startup, which is logged - set `adminPassword`, or look in
+  the log.
+- **ips**: to use a validator jar of your own, set `validator.jar`, rather than replacing
+  `bin/validator_cli.jar`. `validator.checkIpsCodes` is gone (validator 7.0.4 refuses it);
+  `validator.autoLoadPackages` (default true) lets the validator load the packages that define
+  extensions it doesn't know.
+
+There are no manual data migrations: the databases that changed migrate themselves at startup.
+