0.0.14

The EU profile release. FHIRconnect contexts round-trip the HL7 Europe Base
and Core medicalTestResult-eu-core, the Laboratory Report
Composition-eu-lab and the Medication Prescription and Dispense profiles,
and the facade answers Composition/$document. The eehrxf crate, the
European interoperability software component, moves here from FerroFED, its
canonical URLs move to ferrobridge.eu, and HL7's FHIR Validator checks the
documents its suites write. The server and the operator console run on the
FerroSYS crates, with config check, healthcheck, the family's [server]
keys and GET /operator/readiness. The facade and $tofhir give every
resource, created ones included, one deterministic id, which is a breaking
change for stored ids. The CDR client reads RFC 9457 problem details, and
every error outside the FHIR routes is one. Each release now attaches the EHR
system's information sheet and instructions for use.

The library crates publish at fhirconnect 0.1.206, ferrobridge-term
0.1.141, ferrobridge-validator 0.1.141, ferrobridge-hl7v2 0.1.164,
openehr-mapping-core 0.1.135 and eehrxf 0.1.131, and fhir-types
0.1.128, ferrobridge-fhirpath 0.1.128 and hl7v2-types 0.1.127 stay where
they are. A crate version an entry below names is the step at which that
change came in.

Added

• Composition/$document on the FHIR facade (#116, the R4 operation
  Composition-document). GET /fhir/Composition/{id}/$document, and
  GET /fhir/Composition/$document?id={id}, answer a document Bundle: an
  identifier derived from the composition version, the assembly timestamp,
  the Composition first and then every resource its context's outbound run
  creates, each with its read URL as fullUrl. The caller needs read on every
  type the document carries. persist=true and graph are refused with an
  OperationOutcome, and the operation is declared on Composition in the
  CapabilityStatement. The facade now binds a context whose start is a
  composition model, such as Composition-eu-lab, to the composition itself.
• The HL7 Europe Laboratory Report 2.0.0 Composition-eu-lab round trip
  (#116). A FerroBRIDGE document context starts at the report composition of
  the published KDS_Laborbericht template and maps it to a
  Composition-eu-lab: status, identifier, date, author, the LOINC 11502-2
  type and a title, and one section that carries the test's code and
  references the DiagnosticReport-eu-lab, which references its results and
  specimens. The document's report reads its status and identifier out of
  openEHR, because the Composition writes those nodes going in.
• The HL7 Europe Base and Core 2.0.0 medicalTestResult-eu-core round
  trip (#116). A FerroBRIDGE context maps the laboratory test result of the
  published KDS_Laborbericht template to a medicalTestResult-eu-core
  Observation, with its category, code, effective time, status and report
  identifier, and each analyte as a member Observation-resultslab-eu-lab
  it references. The result's status travels through the codes the R4
  diagnostic-report-status and observation-status code systems share.
• The HL7 Europe Medication Prescription and Dispense 1.0.0 round trip
  (#116). Two FerroBRIDGE contexts map FerroBRIDGE's medication template, an
  ADL 2 template over seven published CKM archetypes, to
  MedicationRequest-eu-mpd and MedicationDispense-eu-mpd, each with a
  referenced Medication-eu-mpd and the dosage as a Dosage-eu-mpd; the
  dispense is the medication ACTION at its careflow step "Prescription
  dispensed". scripts/vendor/ckm-medication.sh vendors the archetypes at
  the CKM mirror commit docs/VERSIONS.md pins, and the suites build the
  operational template at test time. fhirconnect 0.1.196 (with ferrobridge-hl7v2 0.1.152 and openehr-mapping-core 0.1.131) takes
  openehr-adl as a test dependency, and the bridge moves to the
  openehr-* crates at 0.0.100, whose ADL 2 Web Template builder reads the
  ADL 1.4 term constraints of the CKM sources.
• The EHDS readiness page in the book (#116). It states the legal status
  plainly: Regulation (EU) 2025/327 names the six priority categories, the
  implementing act that fixes the exchange format is not adopted, and the HL7
  Europe guides are the current proxy, so nothing is a conformance claim. Its
  readiness matrix lists, per category, each target profile with its
  committed template and the round-trip test that proves the transform, and
  records the patient summary Composition, imaging and discharge reports as
  corpus gaps. A fhirconnect test generates the matrix from
  docs/ehds/readiness.toml and fails when a template, a context or a test it
  names is gone. fhirconnect 0.1.198 (with ferrobridge-hl7v2 0.1.153)
  takes toml as a test dependency.
• ferrobridge config check and ferrobridge healthcheck (#1260), the
  FerroHEALTH family's subcommands from ferrohealth-server. config check
  prints the running configuration one key per line with where each value
  came from and every secret as ***, then resolves it as serve does and
  exits 78 with every refusal on stderr. healthcheck asks the running
  server for /health/readiness on loopback and exits 0 only on 200, and
  the image declares a HEALTHCHECK through it. Every subcommand takes
  --set key=value, applied over the file and the environment.
• $tofhir answers one resource per occurrence of a repeated start
  archetype (#1271). A composition holding two diagnoses answers two
  Conditions under one Provenance, each with a stable id derived from the
  composition and its occurrence, and an occurrence the context's condition
  does not admit is counted in the OperationOutcome. The identity seam's
  request names the occurrence, and two resources taking one id refuse the
  call.
• Each release attaches the EHR system's information sheet and
  instructions for use. The EHR system Cadasto B.V. declares under the
  EHDS is FerroEHR with FerroBRIDGE, and both documents are pages of the
  FerroHEALTH book. The release lane takes them at the FerroHEALTH commit
  docs/ehds/system-documents.env pins, refuses a page whose revision
  differs from the pin, and attaches ferrobridge-<tag>-information-sheet.md
  and ferrobridge-<tag>-instructions-for-use.md with the release's facts
  appended: the system version, the release date (EHDS Art. 38(2)(b)) and
  the versions of the standards FerroBRIDGE supports (Art. 38(2)(e)). The
  release notes name the pinned revision of each system page (#1279).
• ferrobridge-hl7v2 sends over MLLP (#1281). mllp::send opens a
  connection within a connect timeout, writes one message as one MLLP frame
  and returns the one reply frame within a reply timeout, bounded by the
  codec's ceiling. A refused connection, either timeout, a peer that closes
  before or inside its reply, and a reply past the ceiling are each their own
  SendError variant, and none carries the message or the reply. FerroPIX
  sends its ITI-10 notifications through it.
• The family's [server] keys (#1287): base_path,
  header_read_timeout_ms, drain_delay_ms, max_concurrent_requests,
  retry_after_s, trusted_proxies, forwarded_header, compression,
  compression_min_bytes and [server.tls], and [telemetry] environment.
• GET /operator/readiness behind the operator scope: the readiness
  document with why each indicator is down, which the open route no longer
  names. The operator console reads it, and falls back to the open route
  while the operator API is off (#1287).
• The eehrxf crate, the European interoperability software component of
  an EHR system under Regulation (EU) 2025/327 (Art 2(2)(n), Art 25(1)),
  joins the crate line at 0.1.128. It moves here from the FerroHEALTH
  federation gateway, where it was built up to 0.0.40 and never published,
  so its earlier history is that project's changelog. It carries the
  format-neutral dataset model read from the Xt-EHR EHDS Logical Information
  Models, one feature per Art 14(1) category with its crosswalk to the HL7
  Europe profiles, the exchange format in FHIR R4 (fhir-r4), and the
  mapping between openEHR and that format through fhirconnect
  (openehr). Against 0.0.40 its one change of behaviour is the id of a
  resource mapped from a composition, which is now the FHIRconnect
  deterministic id fhirconnect 0.1.203 derives from the composition's uid
  and the entry path (FHIRconnect v1.0.0, engine/id-management.adoc,
  Deterministic IDs). The corpora its tests read are vendored by
  scripts/vendor/eehrxf.sh, and the book gains the component's pages: the
  component, the category crosswalks and receiving a document (#1314).
• HL7's FHIR Validator checks the documents the eehrxf suites write. The
  CI fhir-validator job runs it offline over every patient summary document
  the suites emit under EEHRXF_EMIT_DIR, against the HL7 Europe Patient
  Summary and Base and Core profiles and the MyHealth@EU Master Value Sets
  Catalogue. It fails on an error, a fatal issue or a claimed profile it
  could not find, and keeps its results as the eehrxf-fhir-validation
  artifact (scripts/checks/fhir-validator.sh) (#1318).
• The CDR client reads RFC 9457 problem details. A CDR that answers its
  refusals as application/problem+json keeps its explanation on the facade:
  the problem's title, detail, each errors violation as path: detail,
  and its type reach the OperationOutcome diagnostics, as a
  {message, validationErrors} body still does. The composition and
  contribution writes already send Prefer: return=representation, so a CDR
  that lists violations only for such a write lists them (#1334).
• The run report of etl fhir carries an element ledger (#408): per input
  resource, every element with a value and one of four outcomes. mapped
  names the openEHR node a ...

0.0.13

The security and OMOP release. A write the facade makes for an authenticated
caller states that caller as its committer, and [auth] mode = "introspection" checks opaque access tokens (RFC 7662). On the OMOP side,
etl fhir loads FHIR R4 into the CDM with no CDR and every row names its
resource, vocab load loads an Athena download, the OMOCL targets write
DEATH, provider_id and visit_detail_id, [cdm.pseudonymisation]
pseudonymises source identifiers and shifts dates, and the Data Quality
Dashboard's conformance, completeness and temporal plausibility checks run in
Rust through dq check. The derived tables keep another ETL's rows, the CDM
pool trusts the configured CA alone, FHIRconnect converts DV_ORDINAL and
writes an ACTION's time, and the first HL7 Europe profile contexts arrive.

The library crates publish at fhirconnect 0.1.192, ferrobridge-term
0.1.136, ferrobridge-validator 0.1.136 and ferrobridge-hl7v2 0.1.146, and
fhir-types 0.1.128, openehr-mapping-core 0.1.128, ferrobridge-fhirpath
0.1.128 and hl7v2-types 0.1.127 stay where they are. A crate version an
entry below names is the step at which that change came in.

Added

• Every CDM row etl fhir writes names the FHIR resource it was mapped from
  (#409): the bridge schema's resource_origin table records each
  composition's resource type, id and meta.versionId in the commit's
  transaction, and CdmWriter::origins_of_row and rows_of_resource look a
  row's resources and a resource's rows up. cdm init adds the table.

• ferrobridge_eu_laboratory.context targets HL7 Europe Laboratory Report
  2.0.0 over the published KDS_Laborbericht template: the laboratory
  result becomes a DiagnosticReport-eu-lab that references one
  Observation-resultslab-eu-lab per analyte and one Specimen-eu-lab per
  specimen. The round trip asserts each profile's canonical and elements:
  the report's identifier, status, code, effective time, conclusion and
  references; the result's status, laboratory category, code, quantity,
  interpretation and method; the specimen's type, accession identifier,
  received time and collection. The mapping library's eehrxf_lab context
  is recorded as refused (#1235). The testkit exposes the template as
  KDS_LABORBERICHT_OPT (#116).

• ferrobridge-term 0.1.135 takes the client credentials token of
  ferrohealth-smart as its TokenProvider behind the new smart feature
  (#1227): smart::SmartToken, built from a TokenSource, sends the cached
  token and drops one the server refuses with 401, so the repeated request
  carries a token fetched anew. The server's terminology lane uses it in
  place of its own adapter. ferrobridge-hl7v2 0.1.144 and
  ferrobridge-validator 0.1.135 move with it.

• The first HL7 Europe profile context: ferrobridge_eu_condition.context
  targets Base and Core 2.0.0 condition-eu-core over the published
  KDS_Diagnose template, with the published diagnosis, qualifier and
  composition model mappings and FerroBRIDGE's extensions for the profile's
  assertedDate extension and onsetDateTime slices and its canonical. The
  round trip asserts the code, both slices, clinicalStatus and
  verificationStatus (#116).

• ferrobridge mapping check --vocabulary checks every literal concept id of
  the OMOCL files against the vocabulary loaded in the [cdm] database: a
  literal the vocabulary does not hold, or whose domain is not one the CDM
  field definitions name for its column, is a diagnostic (#97).

• ferrobridge_eu_patient.context targets HL7 Europe Base and Core 2.0.0
  patient-eu-core over the published KDS_Person template, loading the
  person chain of the KDS person context with a gender extension that names
  the EU profile in place of the MII one and leaves out the German
  gender-amtlich extension. The round trip asserts the required name and
  birthDate, gender and the canonical (#116).

• The profile package set pins hl7.fhir.eu.laboratory 2.0.0 and
  hl7.fhir.eu.mpd 1.0.0, the HL7 Europe Laboratory Report and Medication
  Prescription and Dispense guides the EU profile contexts target, fetched
  with their provenance by scripts/vendor/profile-packages.sh; every
  package they depend on was already in the set (#116).

• The Data Quality Dashboard's seven temporal plausibility checks run in Rust
  beside its conformance and completeness checks (#1222):
  measureObservationPeriodOverlap, plausibleTemporalAfter,
  plausibleDuringLife, withinVisitDates, plausibleAfterBirth,
  plausibleBeforeDeath and plausibleStartBeforeEnd, each planned where the
  Dashboard's v2.9.0 settings enable it, with its threshold, and translated
  from its SQL template, which scripts/vendor/dqd.sh now vendors.
  dq check and the post-load step of etl run report them. A person whose
  year of birth is 0, as a placeholder PERSON row carries, has no birth date
  for these checks instead of failing them.

• [cdm.pseudonymisation] pseudonymises every row the CDM writer writes
  (#410): the columns the CDM field definitions describe as a link back to the
  source carry an HMAC-SHA-256 pseudonym under a _file secret key, stable
  across runs so incremental loads join, the provider's name, npi and dea
  and a location's address are NULL, and date_shift_days moves every date
  of a person by one per-person shift, so intervals within a person stay
  intact. The Integrate and Operate pages state what it does not de-identify.

• cdm init and every etl run and etl fhir count the rows of each CDM
  table whose ids the bridge assigns that no entry of its side table owns,
  rows another load wrote, and warn of each table; the run report carries the
  counts as foreign_rows (#240). The Operate page states that one bridge owns
  the tables it writes and that era ids are not stable across rebuilds.

• ferrobridge-hl7v2 0.1.143 serves a consumer of its listener and parser
  alone. parse::structure::structure_declared selects the structure
  MSH-9.3 names over the message definition where the two disagree, so an
  IHE ITI-8 ADT^A05^ADT_A01 groups by the A01 structure (IHE ITI TF-2
  §3.8.4.1.2.1; HL7 v2.5.1 chapter 2 §2.15.9.9) (#1217).
  parse::ErrorCode::UnknownKeyIdentifier is table 0357's 204 (#1218).
  mllp::Connection::peer gives a handler the address of its connection's
  peer (#1220). map and its dependencies (fhirconnect,
  ferrobridge-term, fhir-types and the openEHR crates) sit behind the
  default map feature, so default-features = false drops them (#1221).
  A consumer that matches ErrorCode exhaustively adds the new variant.

• A write the facade makes for an authenticated caller states that caller as
  the version's committer, as ITS-REST 1.1.0 recommends ("provision these
  headers based on authentication and authorization runtime data"): a
  single write sends openehr-audit-details with committer.name set to the
  token's sub (or the Basic user-id) and a committer.external_ref in the
  issuer's namespace, and a transaction states the same committer in every
  UPDATE_AUDIT of its CONTRIBUTION. system_id keeps naming the bridge.
  A write no caller made (an HL7 v2 message, an open surface) still commits
  under the bridge's name. Reads still reach the CDR under the bridge's own
  credential (#532).

• [auth] mode = "introspection" with an [auth.introspection] table
  checks opaque access tokens by OAuth 2.0 Token Introspection (RFC 7662)
  through ferrohealth-smart's introspector: each token is posted to the
  issuer's introspection endpoint under the bridge's client authentication
  ([auth.introspection.client]) or a client credentials token
  ([auth.introspection.bearer]), an active answer with scope,
  client_id and exp admits the caller with its scopes and patient
  context, the answer is held until its exp and at most
  cache_max_age_seconds, an inactive token answers 401 and an endpoint
  that fails 503 (#533). The Operate configuration page lists the keys.

• ferrobridge etl fhir PATH loads FHIR R4 resources, a Bundle or an NDJSON
  file, into the CDM with no CDR (#1209, decided on #407): each resource maps
  through the FHIRconnect set into an openEHR composition held in memory,
  which the OMOCL set maps to CDM rows the writer commits. The composition's
  identifiers derive from the resource's type, id, meta.versionId and
  subject, so a re-run writes the same rows, and the run report counts the
  resources read, mapped, unmapped and refused. [etl] aql becomes optional
  at load; etl run refuses to start without it.

• ferrobridge vocab load DIR --schema NAME loads an OHDSI Athena vocabulary
  download into the vocabulary tables of the CDM schema (#233). It takes the
  nine files every download carries and SOURCE_TO_CONCEPT_MAP.csv when
  present, replaces each table in a transaction of its own through COPY
  with the column list from the header row checked against the CDM
  definitions, names every other file and leaves it alone, and prints the
  rows per table and the vocabulary version. The format is the one the Athena
  application writes, read from its source at a pinned commit and vendored
  under docs/specs/athena/ by scripts/vendor/athena.sh (#88). The Operate
  pages describe the load and the vocabulary licences you accept.

• FHIRconnect converts DV_ORDINAL against CodeableConcept
  (DV_ORDINAL.adoc §CodeableConcept, #93): the coding carries the symbol,
  and going into openEHR the ordinal value is the one the template's
  C_DV_ORDINAL lists for the symbol's code. A symbol the template does not
  list, or a node whose template lists no options, is refused.
  fhirconnect 0.1.191 adds RmValue::Ordinal, lens::ordinal and a
  fifth parameter to cell::put, the node's ordinal options; a caller of
  cell::put passes &[] where it has none.

• An OMOCL mapping's provider_id and `visit_detail_id...

0.0.12

The FHIRconnect and facade outcomes release. A write through the facade now
shows the client the losses its mapping declared, a transaction names why it
refuses a linked resource, and the FHIRconnect operations answer 502 when
the terminology server fails. FHIRconnect looks up the display of a DV_TEXT
that fell back to a code, ranks a direct data-type pair above the text
fallback, and openehr-mapping-core exposes the DV_ORDINAL options a
template constrains. The fhir-types XML codec holds the narrative div to
well-formed XHTML both ways. The terminology client gains $expand,
$subsumes, the date input, a caller-built HTTP client for mutual TLS or a
private trust root, and context-aware $validate-code, and the operator
console draws the running configuration.

The library crates publish at fhir-types 0.1.128, openehr-mapping-core
0.1.128, fhirconnect 0.1.190, ferrobridge-term 0.1.134,
ferrobridge-validator 0.1.134, ferrobridge-fhirpath 0.1.128 and
ferrobridge-hl7v2 0.1.141, and hl7v2-types stays at 0.1.127. A crate
version an entry below names is the step at which that change came in.

Added

• WebTemplateIndex::ordinal_options returns the options an OPT 1.4
  C_DV_ORDINAL constrains at a DV_ORDINAL node, in template order: each
  OrdinalOption carries the ordinal value and the code and terminology
  of its symbol, and a node with no ordinal constraint answers None.
  openehr-mapping-core moves to 0.1.127, fhirconnect to 0.1.186 and
  ferrobridge-hl7v2 to 0.1.135 with it (#1090).
• The facade shows a write's declared losses to the client that wrote it: a
  committed transaction entry carries them in response.outcome, and a
  single create or update asked for Prefer: return=OperationOutcome lists
  them after the committed version, one issue per loss with the FHIRPath in
  expression and the openEHR path in details (#1115).
• GET /operator/configuration answers the configuration the bridge started
  on, behind [operator] and the operator scope like the other operator
  routes: every key with its value and its source (the file, the
  environment or the default), and each secret by reference alone (set,
  read from a file, or unset), never its value. The document is
  ferrobridge_operator_api::configuration::Configuration, which the
  operator console decodes (#1147).
• The operator console draws the running configuration: a Configuration
  page with the Logging, Mappings and Server and access tabs, a Settings tab
  on the FHIR facade, HL7 v2, the OMOP ETL and each connection, and the
  host and credentials of each upstream in the Connections table. Every
  value is read-only, with its TOML key and whether it came from the
  environment or is the default, and every secret is shown by reference
  alone; How configuration works opens from the line that names the file.
  An empty [auth] product_scope is answered as the scope the bridge runs
  on, __ferrobridge.operator (#1147).
• hl7v2-types (Apache-2.0) and ferrobridge-hl7v2 (BUSL-1.1) join the
  crate line at 0.1.127, leaving their 0.0.0 name reservations, so the next
  publish ships the HL7 v2 tables and the HL7 v2 face (MLLP framing, MSH-18
  decoding, the positional parser, the acknowledgment and the v2-to-FHIR
  map) on crates.io for other projects to depend on. Each README carries a
  worked example, and the entry points of ferrobridge-hl7v2 carry tested
  # Examples. Pin each exactly, as for every crate of the line (#1131).
• ferrobridge-term 0.1.130 sends ValueSet/$expand and
  CodeSystem/$subsumes, on STU3, R4 and R4B and in a batch.
  Client::expand takes an Expansion (url, valueSetVersion, date,
  filter, offset and count, includeDesignations) and answers the
  expanded value set with the nesting of expansion.contains kept, each
  entry with its system, version, code, display, abstract, inactive and
  designations; a value set the server does not know is
  ExpandOutcome::NotFound carrying the OperationOutcome and its
  tx-issue-type, and an expansion the server could not make is a refusal,
  never an empty expansion. Client::subsumes answers SubsumesOutcome:
  Equivalent, Subsumes, SubsumedBy or NotSubsumed.
  Client::code_system_count asks
  GET [base]/CodeSystem?url=<system>&_summary=count. ferrobridge-validator
  moves to 0.1.130 and ferrobridge-hl7v2 to 0.1.128 with it (#1177).
• ferrobridge-term 0.1.131 reaches a terminology server through an HTTP
  client the caller builds: Client::with_http(config, reqwest::Client)
  sends every request through it, so a deployment can present a client
  certificate for mutual TLS, trust a private root beside the platform's or
  use a proxy. The configured timeout still bounds each request, and the
  credentials, the retry budget and the typed errors apply as for
  Client::new (#1180).
• ferrobridge-term 0.1.131 validates a code whose system its context
  implies: Coded::InContext sends ValueSet/$validate-code with
  context, code and display and no system, which R4 and R4B accept
  ("If a code is provided, a system or a context must be provided"), alone
  or in a batch. STU3 requires a system for a code, so an STU3 client
  refuses the form with the new Error::SystemRequired and sends nothing,
  and Client::check answers the same (#1181). ferrobridge-validator
  moves to 0.1.131 and ferrobridge-hl7v2 to 0.1.129 with it.

Changed

• fhirconnect 0.1.188 moves engine::rm::NULL_FLAVOUR, NULL_REASON and
  null_flavour_of to engine::rm::null_flavour, which breaks an import of
  them: name them through engine::rm::null_flavour:: (#1194).
• A transaction entry whose mapping links a resource as a composition of its
  own is refused with 422 and not-supported, naming why and the ways that
  commit it: the resource on its own, or as an entry of a batch, whose
  entries commit one at a time and follow the link as a single create does
  (#1120).
• ferrobridge-term 0.1.130 carries the date input of CodeSystem/$lookup
  and ValueSet/$validate-code: Client::lookup_at sends it, and
  Request::Lookup and Validation gain a date field. This breaks a
  struct literal of either: add date: None where no date is meant (#1177).
• SECURITY.md states the fix-time targets every product of the Ferro family
  commits to, counted from the confirmed assessment: a fixed release within
  7 days for a Critical vulnerability, 30 days for High, 90 days for Medium
  and with the next release for Low, beside the acknowledgement within about
  5 business days and the initial assessment within about 10, both best
  effort as before.

Fixed

• The fhir-types XML codec holds a narrative div to well-formed XHTML
  both ways: xml::to_xml refuses a div that is no well-formed XHTML
  div in the XHTML namespace with an EncodeError naming its element path,
  such as Basic.text.div, and xml::from_xml refuses a start tag whose
  attributes are not well-formed XML (no whitespace between two attributes,
  a name that is no XML name, a < in a value), in the narrative and in
  every other element, where it accepted them and wrote them back repaired.
  fhir-types moves to 0.1.128, fhirconnect to 0.1.189,
  ferrobridge-term and ferrobridge-validator to 0.1.134,
  ferrobridge-fhirpath to 0.1.128 and ferrobridge-hl7v2 to 0.1.140 with
  it (#1178).
• A coding with no display written into a DV_TEXT, whose value would
  otherwise fall back to the coding's code, is looked up through
  CodeSystem/$lookup as one written into a DV_CODED_TEXT is: the display
  becomes the value, an unknown code refuses unless
  [terminology] display_fallback is set, a failed call refuses, and with no
  server the code stands. fhirconnect moves to 0.1.185 and
  ferrobridge-hl7v2 to 0.1.134 with it (#1188).
• An untyped dateTime mapped onto an ELEMENT whose value admits
  DV_TEXT and DV_DATE_TIME converts into DV_DATE_TIME whatever the
  template order: a class that pairs with the FHIR type directly outranks
  the text fallback. fhirconnect moves to 0.1.181 and ferrobridge-hl7v2
  to 0.1.130 with it (#1114).
• $toopenehr and $tofhir answer 502 with the issue type transient
  when the terminology server fails during the run, with the upstream status
  in the diagnostics, as the facade's writes do. A translation the server
  answers with no match stays a 422 (#1119).

Support period

Only the newest release is supported. When a new release is published, every earlier release stops receiving fixes: there are no maintenance branches, no long-term-support line and no backports. If you are not on the newest release, upgrade; upgrading is free. Under the Cyber Resilience Act, Cadasto B.V. commits to keep publishing security fixes for at least five years after each release (Art 13(8)) and ships them only in the newest release (Art 13(10)). For this release that commitment runs until the end of October 2031 (Regulation (EU) 2024/2847 Art 13(19)); see SECURITY.md.

Information and instructions to the user (CRA Annex II)

CRA information and instructions to the user for v0.0.12: the manufacturer, the vulnerability contact, the support period, secure use, updates and decommissioning (Regulation (EU) 2024/2847 Art 13(18) and Annex II).

0.0.11

The operator console release. The console is rebuilt page for page on
FerroUI 0.3.6 and renamed from ferrobridge-viewer to ferrobridge-console,
so its image, environment variables, compose profile, cookies and page
addresses change: the Changed section below lists each, with what an
operator changes. Release images are scanned before they are tagged, every
release carries a vulnerability record in which each finding is judged, and
the notes state the support period and link the CRA information for users.
FHIRconnect registers the last mappingCode functions of the published
library and gains display resolution, NULL_FLAVOUR, the EVENT choice and
the quantity, temporal, URI, string and interval data-type pairs.

Added

• The book has a CRA information for users
  page (#1152): the information and instructions Annex II of the Cyber
  Resilience Act (Regulation (EU) 2024/2847) has accompany each release,
  point by point, from the manufacturer and the vulnerability contact to the
  support period, secure use, updates, decommissioning and the SBOMs. The
  release notes scripts/release/plan.sh composes now end with a link to it,
  and the composition refuses when the book does not list the page.
  SECURITY.md names the operator console's release tarballs and site
  bundle among the supported artefacts.

• The eighth mappingCode function of the published FHIRconnect library,
  ehrStatusAddExternalREF, is registered (#1065), so
  KDS_admin_entry_person.yml loads in the published person context. It
  writes no template node: it offers each Identifier the mapping reads as
  the subject of the EHR, on the new Outcome::subject channel
  (fhirconnect::engine::subject::SubjectIdentifier), and coming out of
  openEHR it is declared skipped (SkipReason::EhrStatusSubject). The
  facade writes it into EHR_STATUS.subject.external_ref through ITS-REST
  1.1.0 ehr_status_update with If-Match on the version it read, before
  the composition is committed, for the identifier of the new
  [facade] ehr_status_identifier_system key. An EHR_STATUS that names
  another subject answers 409, a CDR refusal answers through the status
  table with nothing committed, and with the key unset a write whose mapping
  offers identifiers answers 422 naming the key. New for a consumer of
  fhirconnect: MappingFunctions::writes_subject and to_subject, with
  defaults, and the SkipReason variant. fhirconnect 0.1.180.

• A FHIRconnect mapping that names an EVENT node itself, with a FHIR time
  on the other side, writes and reads the event's time (#1059), as
  types-of-mappings/data-type/EVENT.adoc §POINT_EVENT and INTERVAL_EVENT
  pairs them. A dateTime, instant or date is a POINT_EVENT's time;
  a Period is an INTERVAL_EVENT whose time is Period.end, whose
  width is the span back to Period.start and whose math_function is
  the RM default 640|actual|. A choice element such as effective[x]
  picks the class from the alternative going in and from the event's class
  coming out. A FHIR time, a period with a missing or partial bound, and a
  non-choice element of the other class are refused; an interval event whose
  math_function is not actual declares it as a loss going out.
  WebTemplateIndex::amend edits one node instance of a built composition
  and validates it again. New variants a consumer matching exhaustively adds
  arms for: PathError::AbsentInstance, Derived::Event,
  EngineError::EventTime and SkipReason::EventFunctionUncarried.
  laboratory_test_result.v1.yml:120 and :448 no longer warn
  fc-anchor-without-children. openehr-mapping-core 0.1.126,
  fhirconnect 0.1.179.

• FHIRconnect LINKED mappings (#94): a link whose FHIR side names a
  resource, such as a Condition's encounter, now commits that resource as a
  composition of its own through the context its meta.profile names, and
  writes ehr:/<ehr_id>/compositions/<versioned_object_uid> into the
  linking composition's LINK.target. A facade create or update runs in two
  passes, because ITS-REST 1.1.0 lets the CDR, not the client, assign a new
  composition's id: a probe run finds the linked resources, each is
  committed as a POST would commit it (a replay links the composition the
  first delivery produced, and a resource this server already serves links
  where it stands), and the final run writes their URIs. A resource no
  context maps is a declared loss, skipped-unmapped-link. A linking commit
  the CDR refuses answers its refusal with a warning naming each linked
  composition it left. A transaction or batch entry that links a resource is
  refused, since a transaction is one CONTRIBUTION, and $validate runs
  the link without committing. The engine gains the
  engine::linked::LinkedCompositions seam (Seams::with_linked),
  SkipReason::UnmappedLink and ReferenceError::Link; a run with no seam
  refuses as before. fhirconnect 0.1.174.

• The FHIRconnect engine converts ELEMENT.null_flavour against the code
  of the R4 data-absent-reason extension both ways (#93), through
  engine::lens::null_flavour with GetPut and PutGet property tests and a
  test per entry of its committed table. A tail on the element reaches
  null_flavour as the _null_flavour family of the node the element
  shares with its value, with _null_reason beside it. FHIRconnect
  NULL_FLAVOUR.adoc's table is no function; the cell reads it with the
  openEHR terminology's null flavours (271 "no information", 253
  "unknown"), keeps a FHIR code with no flavour of its own in
  null_reason, and refuses a code outside either set. Breaking:
  SkipReason gains NullReasonUncarried, the declared loss of a
  null_reason that names no code, so a consumer that matches SkipReason
  exhaustively adds the arm. fhirconnect 0.1.176.

• A FHIRconnect mapping can now name the origin of an observation's
  history, $archetype/data/origin, which no Web Template node carries
  (#95). The engine writes it as the Simplified Formats history_origin of
  the observation and reads it back from HISTORY.origin. An OBSERVATION
  whose HISTORY carries events, each with an ITEM_LIST, now round-trips
  under both lens laws against a synthetic template: going out each event
  becomes its own resource (the FHIRconnect hierarchy split), and the origin
  and each event's time keep their offset in both directions. The round-trip
  pass list gains ferrobridge_observation_events (5 of 5). fhirconnect
  0.1.171.

• Going into openEHR, a coding that carries no display now has its display
  resolved through CodeSystem/$lookup on the [terminology] server
  (#95), as the FHIRconnect DV_CODED_TEXT page recommends. A found
  display becomes the DV_CODED_TEXT value. A code the server does not know
  refuses the resource unless [terminology] display_fallback = true
  (FERROBRIDGE__TERMINOLOGY__DISPLAY_FALLBACK) writes the code instead. A
  failed call refuses either way, carrying the upstream status. With no
  terminology server the code stands as before, the page's alternative "if
  a term server is not an option". Lookups join the translations in one
  call or one batch per round. The FHIRconnect terminology seam gains
  lookup and display_fallback, both with refusing defaults. The engine
  answers EngineError::UnknownDisplay and EngineError::DisplayLookup.
  fhirconnect 0.1.170.

• Five more mappingCode functions of the published FHIRconnect library
  are registered (#95). timingToDaily writes a frequency per one unit of
  time as the 1/<unit> frequency of the daily timing cluster (or an
  interval of them with frequencyMax), one event per longer period as the
  interval between doses, and the one time of day. dosageQuantityToRange
  writes a dose Range as an included DV_INTERVAL<DV_QUANTITY>.
  rangeToText writes a rate Range as the text <low> <code> - <high> <code>, the only form the rate element admits beside a quantity.
  ratio_to_dosage and ratio_to_dosage_action write a rate Ratio (R4's
  "500ml over 2 hours") as the rate per unit of time and the administration
  duration. Every quantity and range converts through the engine's
  DV_QUANTITY and DV_INTERVAL<DV_QUANTITY> cells, a rate divides and
  multiplies exactly or is refused, and each function refuses what it
  cannot carry. A port onto a polymorphic ELEMENT now
  reads only the value node whose _type matches. The library's
  dosage.v2.yml, dosage.v2.BackboneElement.yml and
  timing_daily.v1.yml now load, so the medication statement context gets
  to compile. Its refusals there are recorded on #101. It landed in
  fhirconnect 0.1.169 beside #1076, with no version of its own.

• The FHIRconnect engine converts a scalar Integer or Integer64 tail
  against FHIR integer and a scalar Real tail against decimal both
  ways (#1081), through engine::lens::scalar with GetPut and PutGet
  property tests; going out these refused with no cell. A value outside
  FHIR's 32-bit integer is refused going out, and a decimal whose text
  the Real cannot render back (5.40, 1e3) is refused going in, where
  it was rounded to the nearest binary number with no loss declared.
  fhirconnect 0.1.173.

• The FHIRconnect engine converts DV_QUANTITY against Quantity, decimal
  and integer, and DV_COUNT against integer, Quantity and Count
  (#93), each a lens with GetPut and PutGet property tests over the tables of
  FHIRconnect DV_QUANTITY.adoc and DV_COUNT.adoc. Where a table is silent
  or contradicts R4, the cell decides and refuses rather than drops: the UCUM
  system is written beside a code (R4 qty-3), units_display_name is the
  counterpart of unit, and a magnitude_status no comparator states, a
  magnitude with more places than its precision, a count outside FHIR...

0.0.10

The openEHR demographics release. The FHIR facade serves Patient,
Practitioner, PractitionerRole and Organization from FHIRconnect party
contexts over the ITS-REST 1.1.0 Demographic API, searches them through the
Cadasto experimental AQL demographic extension, chains clinical searches
through the patient identifier, and gives a created Patient its EHR. The
terminology lane authenticates with OAuth 2.0 client credentials, and the
static bearer token is gone from both upstreams.

Added

• The terminology lane authenticates with the OAuth 2.0 client credentials
  grant (#962): [terminology.credentials.oauth] takes the keys of
  [cdr.credentials.oauth], and the same token cache obtains the token,
  shares it across calls, renews it before it expires, and renews it once
  when the terminology server answers 401. A renewal that obtains no token
  ends the call with the terminology server's refusal and the token
  endpoint's error. ferrobridge-term 0.1.129 adds
  config::Credentials::OAuth over a caller-supplied config::TokenProvider,
  and the error::Error::Token and error::Error::Renewal variants.
  ferrobridge-validator moves to 0.1.129 with it.

• The party search takes name, _id and _count=0 beside identifier
  (#931). name matches a name that starts with the value, case-insensitively
  as R4 string search asks: [facade.party_search.types.<Type>] name_query
  binds the value as typed, in lower case and capitalised, because the
  extension's LIKE is case-sensitive; other case forms and accents are a
  stated gap. _id reads the one party it names. _count=0 answers the
  number of matches in total with no entries (R4 search §3.1.1.5.3), and
  _count is capped at search_count_max. A bare identifier value two
  parties carry answers both. A type's query is now optional, and the
  CapabilityStatement declares exactly the parameters each type takes.

• A Patient created in a party context gets its EHR under the subject link
  when [facade] ehr_policy is create_on_first_write (#932): the facade
  finds the EHR keyed by the new party's id, or creates it with that id in
  EHR_STATUS.subject, so the clinical resources that name the Patient find
  it. Under existing the create sends no EHR call. A failed EHR call after
  the party committed answers the EHR refusal with a warning naming the stored
  Patient. No specification governs this: our own design.

• fhir-types 0.1.127: every schema::FieldSchema carries
  target_profiles, the ElementDefinition.type.targetProfile canonicals of
  the element's types in definition order, in all five versions (#926), so a
  consumer reads which resource types a Reference admits from the element
  table. A consumer that builds a FieldSchema literal adds the field.

• The facade's subject search parameters take the :identifier modifier
  (#923): Condition?patient:identifier=[system]|[value] matches the
  Reference.identifier of a resource's subject (R4 search.html
  §3.1.1.4.12). That identifier is the subject the identity map keys by
  system and value, which the facade renders as an identifier. A subject
  rendered as a literal reference carries none and matches nothing, and so
  does |[value]. [value] alone and [system]| answer 400 not-supported,
  because the map keys a subject by system and value. No specification
  governs the identity map: our own design.

• The facade searches Patient, Practitioner, PractitionerRole and
  Organization by identifier through the Cadasto experimental AQL
  demographic extension, behind [facade.party_search] with one configured
  query per type (#480). Each page runs the query with offset and fetch
  and reads every party it names over the Demographic API. A CDR that answers
  400 to the query, as one without the extension does, answers 501 with
  not-supported naming the extension. The CapabilityStatement declares
  search-type and identifier on exactly the configured types, and a
  configured type no party context serves refuses to boot.
  docs/architecture.md §4.12 writes down the dialect's semantics as the
  extension's guide documents them and Cadasto observed them, with the
  findings Cadasto plans to change. No specification governs the extension:
  our own design.

• The FHIR facade serves Patient, Practitioner, PractitionerRole and
  Organization from party contexts over the ITS-REST 1.1.0 Demographic API,
  DEVELOPMENT, behind [cdr] demographic (#470). Read, vread,
  GET [type]/[id]/_history, create, update (over If-Match or the latest
  version) and DELETE [type]/[id], which answer not-supported for a type no
  party context serves; a party context with the key off is a boot refusal. The
  id is the party's versioned_object_uid and meta.versionId its version
  tree id, with no identity-map entry; a Demographic API 400 answers 500,
  and 404, 409, 412 and 422 answer as themselves. The
  CapabilityStatement declares the six interactions and no search per party
  type. No specification governs a party context: our own design.

• A party context maps ROLE.performer, the mandatory PARTY_REF no template
  node holds (RM Demographic IM, the ROLE class), as $archetype/performer,
  so the facade creates and updates a PractitionerRole (#911).
  PractitionerRole.practitioner must name a Practitioner the facade
  serves, relative or under its base, with nothing beside reference. It
  becomes PARTY_REF {namespace "demographic", type "ACTOR", id HIER_OBJECT_ID <uid>} and reads back as Practitioner/<uid>, the type taken from the
  element's targetProfile. A reference of another server
  (EngineError::ForeignParty), of another type, carrying a display, or local
  to the request answers 422, and a ROLE with no performer, built or
  served, is refused (PartyError::RoleWithoutPerformer). An element whose
  reference admits no single type is refused at load
  (fc-party-ref-target). fhirconnect 0.1.151 adds RmValue::PartyRef,
  the PARTY_REF-against-Reference pair, EngineError::ForeignParty and
  EngineError::PartyRefTarget, which breaks an exhaustive match over
  either enum; openehr-mapping-core 0.1.118 adds
  PartyError::RoleWithoutPerformer the same way. No specification governs
  this correspondence: our own design.

• The facade's search chains through the patient identifier (#492):
  Observation?patient.identifier=MRN-1, subject.identifier and
  subject:Patient.identifier, on every type a search declaration answers.
  With [facade.identifier_search] enabled, a configured demographic AQL
  query in Cadasto's experimental extension resolves the identifier to its
  parties, each party's uid names a patient, and the EHR comes from the
  identity map or GET /ehr?subject_id=. An unknown identifier answers an
  empty searchset with no clinical query, and _count=0 answers the total
  alone. A value naming a system needs system_query. The
  CapabilityStatement documents the chain on each subject parameter while
  it is on. No specification governs the resolution: our own design.

• A party program runs through the engine (#905). WebTemplateIndex:: build_party builds a canonical PERSON, ORGANISATION or ROLE from the
  node values a party context writes, through the openehr-rm types: the
  objects between two template nodes are the ones the OPT 1.4 constrains
  there, named by their rubric, every list attribute is an array, no
  composition attribute is written, and the result decodes strictly as the
  root's class (PartyError::Invalid otherwise). openehr-sdt 0.0.87 builds
  no correct party (#897, FerroHEALTH/FerroEHR#3810). fhirconnect's
  engine::traverse::party::to_party and from_party map a FHIR resource to a
  party and back; WebTemplateIndex::read reads any CanonicalDocument. No
  specification governs a party build: our own design.

• FHIR Organization round-trips through the KDS laboratory request chain
  (#543). The published KDS_Laborauftrag template is vendored by
  scripts/vendor/kds-laborauftrag-opt.sh at the openFHIR commit
  docs/VERSIONS.md pins, and a FerroBRIDGE project context compiles the
  library's organisation.v1.yml verbatim, reached through the service
  request's reference to its requester: a contained Organization maps into
  the Einsender cluster and comes back as a created Organization the
  request references, and both lens laws hold. organisation.v1.yml joins the
  mapping-library pass list and kds_laborauftrag the round-trip list; every
  published file of the chain that does not compile is pinned by file and
  line.

• FHIRconnect party contexts compile (#898). A context whose operational
  template is rooted at a PERSON, ORGANISATION or ROLE is a party
  context, read from the RM type of the template root, and Program::party
  names the class. A party context refuses at load, each with a code of its
  own: $composition (fc-party-composition-variable), a path naming a
  composition attribute the defaults or ctx/ set
  (fc-party-composition-field), participationsFunction
  (fc-party-participation), link (fc-party-link) and entering a context
  whose start slots a composition (fc-party-sub-context-composition).
  to_openehr and to_fhir refuse a party program with
  EngineError::PartyProgram until the party build lands (#897). No
  specification governs a party context: our own design. Breaking for a
  consumer that matches ResolveCode or EngineError exhaustively: add the
  new arms.

Changed

• Only the newest release is supported (#979). SECURITY.md says that every
  earlier release stops receiving fixes when a new one is published, with no
  maintenance branches, no long-term-support line and no backports, and that
  upgrading is free. Cadasto B.V. commits to keep publishing security fixes
  for at least five years af...

0.0.9

Added

• The ITS-REST 1.1.0 Demographic API, DEVELOPMENT, behind [cdr] demographic
  (off by default; #894). The Demographic OpenAPI document is vendored beside
  the other ITS-REST documents, its x-status: DEVELOPMENT checked, and a test
  holds the generated openehr-its client to every operation it declares.
  CdrClient::demographic reads, creates, updates and deletes PERSON,
  ORGANISATION and ROLE; a 400, 404, 409, 412 or 422 maps to a
  facade answer through facade::status::demographic. A Release 1.1.0
  PARTY that carries reverse_relationships reads: the member is dropped
  before the decode and the dropped entries are counted, because each one
  restates a relationship the repository holds (RM Demographic IM Release
  1.1.0 §2.2.1; #845). No FHIR resource is served from it yet.

• A FHIRconnect sub-context's template.id is checked against the template
  the parent's OPT 1.4 states at the slot node (C_ARCHETYPE_ROOT.template_id,
  read by the new WebTemplateIndex::embedded_template). A different template
  is refused as fc-sub-context-template-mismatch, and a slot node that states
  none leaves the warning fc-sub-context-template-undecided
  (sub-contexts.adoc §Validation errors; openehr-mapping-core 0.1.115,
  fhirconnect 0.1.145; #886).

• FHIRconnect sub-contexts (#864, types-of-mapping-files/sub-contexts.adoc).
  fhirconnect 0.1.143 reads slotContext on a mapping, and scope (root
  or sub) and contexts on a context. The strict schemas carry all three,
  with slotArchetype and slotContext mutually exclusive.

  • The semantic rules refuse:
    • a slotContext or a contexts entry naming no loaded context;
    • a slotContext at openehr: $reference;
    • a scope: sub context no context lists;
    • a cycle through contexts.
  • The resolver compiles a slotContext into the parent program as
    Method::SlotContext, from the entered context's start with that
    context's own extensions and against the parent's template, and skips the
    composition slot of a root context entered this way. It refuses:
    • a sub-context compiled as a root;
    • a slotContext the entering context does not list;
    • a sub-context whose start slots a composition;
    • a start that does not match the slot's archetype.
  • The engine maps a sub-context into the parent composition in both
    directions, and Outcome::consumed names the resource a slotContext
    pulled in through a reference.
  • The server loads only root contexts as programs and never fetches a
    sub-context's template. A transaction passes over, as a root, an entry
    another entry's slotContext consumed, and answers it 200 OK with no
    location of its own. An entry nothing consumes is still processed as a
    root.

• fhir-types 0.1.126 reads ValueSet and CodeSystem release-neutrally
  (#876). definition::ValueSetRead covers the composition (includes,
  excludes, filters, imports, inactive) and the expansion, and
  definition::CodeSystemRead covers content, hierarchy meaning, case
  sensitivity, the declared properties and the concepts. A nested concept or
  expansion entry is read through the same trait as its parent
  (ConceptRead, ContainsRead). Every version implements them from its own
  package, and STU3's uri imports read as R4's canonicals. The profile
  validator now decides STU3 bindings from the STU3 ValueSets and
  CodeSystems of the package set as it does R4 ones. Release names the
  release's ValueSet and CodeSystem, PackageSet::value_set and
  code_system answer in the release's model, and
  Reason::TerminologyNotRead is gone.

• A Patient keys its own EHR through the configured subject link (#867).
  Under [facade] subject_id_form = "logical_id" or "uuid" a Patient create
  or update finds or provisions its EHR by its logical id in
  subject_namespace, the id a Patient/<id> reference of its resources
  names, so on a CDR whose owner links each EHR under its own namespace the
  Patient and its resources reach one EHR. A Patient with no id, or under
  uuid one whose id is no UUID, is refused naming
  facade.subject_id_form. In a Bundle, a subject reference to a Patient
  entry that carries an id keys by that id too, and one without an id,
  such as an HL7 v2 message's Patient, keeps the identifier key. Under
  reference nothing changes.

• The profile validator validates STU3 resources against STU3 profiles
  (#838). PackageSet::<Stu3>::load_release reads a package set as STU3, and
  Validator over it walks the STU3 element table with the checks, refusals
  and unevaluated listing of R4: cardinality, the types of a choice, the
  single STU3 type.profile and type.targetProfile, slicing, the lexical
  forms of the STU3 package, invariants as FHIRPath over the STU3 types, and
  extension contexts in STU3's resource, datatype and extension codes.
  The walk is generic over the sealed release::Release (R4, Stu3) and
  reads every definition through the release-neutral fhir_types::definition
  read. PackageSet and Validator take the release as a type parameter
  defaulting to R4, and PackageSet::load and PackageSet::new still read
  R4. An STU3 binding is never decided from the package set, since its
  ValueSets and CodeSystems have no release-neutral read yet (#876): it is
  listed with the new Reason::TerminologyNotRead and kept for a terminology
  server.

• The facade's patient-to-EHR link is configured to match the CDR owner's own
  link (#467). [facade] subject_type sets the PARTY_REF.type of the
  subject of an EHR the facade creates (default PERSON, until now fixed),
  and [facade] subject_id_form sets how the id of a literal subject
  reference is written: reference (the default, Patient/<id> as before),
  logical_id (the bare <id>) or uuid (the bare <id>, refused with a
  diagnostic naming the key when it is no UUID). A subject_type outside
  the BASE PARTY_REF Type_validity set, or a subject_namespace that
  breaks the OBJECT_REF namespace rule, refuses the boot naming the key;
  both are checked through openehr-base. The bridge never derives a
  subject id the CDR mints itself, such as a pseudonym.

• fhir-types 0.1.124 completes the release-neutral definition read (#859).
  ElementDefinitionRead gains is_modifier, and its reads carry a type's
  regex, a binding's max_value_set and a constraint's best_practice,
  read from the core extensions with those urls in every version (STU3
  states maxValueSet as a Reference, R4 as a canonical; the R5 and R6 core
  packages define neither of the two binding and constraint extensions). The new StructureDefinitionRead reads the url,
  version, type, base definition, kind, abstract, derivation, snapshot,
  contexts and context invariants of every version: an STU3 context (one
  contextType beside a list of strings) reads as the same ContextRead
  entries as an R4 context, each release keeping its own type codes.
  fhirconnect moves to 0.1.140 for the requirement. Breaking for a consumer
  that builds TypeRead, BindingRead or ConstraintRead literals, or
  implements ElementDefinitionRead itself.

• The ITS-REST 1.1.0 Overview and System OpenAPI documents are vendored
  beside EHR, Query and Definition (#478). All five are x-status: STABLE
  at tag Release-1.1.0. The Overview defines the common headers the CDR
  client sends (openehr-version, openehr-audit-details,
  openehr-template-id), and System defines the OPTIONS / capability call.
  scripts/vendor/its-rest.sh fetches and checks all five, and the corpus
  test reads each.

• The FHIRPath evaluator has an STU3 type model, model::stu3::Stu3, over
  the generated STU3 element table (#837), so paths, ofType(), is and
  as resolve against STU3 types (an STU3 valueAttachment,
  Patient.animal). Every STU3 core invariant with a typed element passes
  the static check, except the two the package publishes with a defect
  (inv-1, sdf-15).

Changed

• Breaking for a library consumer of fhirconnect 0.1.146: a demographic
  Reference.reference resolves through the new Demographics seam
  (engine::demographics, #469), and the Seams default, NoDemographics,
  refuses it. A consumer installs IssuerDemographics (the ids of its own
  FHIR server, the fallback engine/demographics.adoc names) or its own
  Demographics with Seams::with_demographics. The identity travels in
  PARTY_IDENTIFIED.identifiers where the FLAT format carries it, and in
  PARTY_PROXY.external_ref on the composer and on a participation's
  performer; a read turns it back into the reference. The server installs
  the facade-base port, [facade] base_url is checked at boot as its
  issuer, and the operations lane uses it when the facade is configured.

• ferrobridge-validator, ferrobridge-term and ferrobridge-fhirpath join
  the crate line at 0.1.126, leaving their 0.0.0 name reservations, so the
  next publish ships the validator as it stands on main. Pin each exactly,
  as for every crate of the line (#432).

• The operator console draws with ferrohealth-ui 0.1.3, the FerroHEALTH
  component library the four consoles share (#850). It keeps only its brand
  theme and its screens: the shell, the cards, tables, pagers, code panels,
  forms, refusals and empty states are the library's, its icons are the
  library's Lucide glyphs, and the console's own Tailwind stylesheet, style
  module and highlighter are gone; the site build no longer installs the
  Tailwind CSS CLI (#890). The top bar carries the one theme toggle,
  a moon in the light theme and a sun in the dark one, which posts with no
  script and, once hydrated, swaps the theme in place while the server keeps
  the choice in its cookie. The playground (its navigation entry now
  reads "Playground"...

0.0.8

Added

• fhirconnect 0.1.136 holds every FHIR resource a run out of openEHR
  produces or creates to R4 ext-1 before it leaves the engine (#651). An
  extension with a url and no value, or with a value and nested extensions,
  refuses the run as the new EngineError::Invariant, naming the constraint
  and the instance path, so a facade read or a $tofhir call refuses it
  instead of answering a resource that breaks an error-severity constraint
  (R4 conformance-rules.html §2.1.0.6). engine::invariant holds the checks,
  one per constraint key; docs/architecture.md §4.4 records why they are
  targeted checks and not FHIRPath evaluation. A consumer matching
  EngineError exhaustively gains a variant.

• The operator console has browser journeys, screenshots and a book page
  (#602). The journeys drive headless Chrome through chromedriver with the
  thirtyfour WebDriver client against a running bridge (ferrobridge serve's run path over a wiremock CDR and a synthetic mapping tree) and
  a running console serving its release site bundle, and fail on any error
  the browser logs. They cover the sign-in, the shell and its theme switch
  and sign-out, the engine state, every mapping file view, the transform
  playground (an answer, a refusal, and an operations lane that is off) and
  the mapping editor end to end: a refused draft leaves the disk and the
  running set unchanged, a save is byte-identical and reloads the programs,
  and the bridge's audit line names the actor and the file and nothing of
  the draft. They run behind FERROBRIDGE_JOURNEYS=1 in the new
  journeys (browser) CI job at the Chrome for Testing release
  docs/VERSIONS.md pins, which scripts/release/journey-tools.sh installs
  locally. FERROBRIDGE_SCREENSHOTS=1 captures every console page in light
  and dark at 1440 pixels for the book's operator console page, and a guard
  in the ordinary suite fails on a console route without both images. The
  test OpenID Provider of the testkit can now sign a real browser in.

• The FHIRPath evaluator admits the functions FHIRPath 3.0.0 adds as
  Standard for Trial Use behind the opt-in
  Environment::with_fhirpath_stu3_functions (#633), so the default stays
  FHIRPath N1 2.0.0, the release FHIR R4 cites. This change implements
  matchesFull(), trim(), split(), join(), encode(), decode(),
  escape() and unescape(). HL7's FHIRPath R4 suite now counts as two
  corpora with a badge each: fhirpath-r4 (874 of 886, N1) and
  fhirpath-r4-stu3 (33 of 104, the tests that call one of the 13 3.0.0
  functions, run with the opt-in).

• The FHIRPath 3.0.0 opt-in adds lowBoundary(), highBoundary(),
  precision() and comparable() (#633). A decimal boundary is half a unit
  of its last place away, rounded outward to the precision asked for. A date
  and time boundary fills the missing components and keeps the value's own
  offset, as the 3.0.0 examples show. fhirpath-r4-stu3 moves to 85 of 104;
  the suite cases that contradict those examples are the upstream report
  #815.

• The FHIRPath 3.0.0 opt-in adds sort(), with the asc and desc key
  directions of the 3.0.0 grammar's sortArgument (#633), which completes
  the 13 functions. fhirpath-r4-stu3 moves to 93 of 104.

• The FHIRPath evaluator has a strict ordering mode,
  Environment::with_strict_ordering, off by default (#636). It refuses
  first(), last(), tail(), skip(), take() and the indexer over a
  collection derived from children() or descendants() with
  EvalError::Unordered, the error FHIRPath N1 §3.1 lets an implementation
  return for an order-dependent operation on a list whose order is
  undefined.

• The profile validator checks a resource against a profile on the
  abstract Resource or DomainResource (#620): a reference target, a
  meta.profile claim or a profile discriminator walks the resource over
  the profile's elements and its own core definition for the rest, so it
  conforms or fails instead of being listed. Reason::AbstractProfile is
  gone, as nothing is listed for it any more.

• The profile validator holds every resolved extension to where its
  definition admits it (#481): each StructureDefinition.context of the
  types element, extension and fhirpath, read as R4
  defining-extensions.html §2.5.1.2 and the extension-context-type code
  system define them, and each contextInvariant evaluated on the element
  holding the extension with %extension bound to it. A misplaced
  extension is an extension-context error and a broken context invariant
  a context-invariant error; a context the walk cannot decide, and a
  context invariant that does not parse or evaluate, stay listed as
  unevaluated with the reason. Reason::ExtensionContext now carries that
  reason as a String, and Constraint::ContextInvariant is new: a
  consumer matching the unit variant changes its pattern.

• A profile slice that holds too few items names why the closest item
  failed it (#490): when a profile discriminator, or slicing with no
  discriminator, keeps an item out of a slice that then falls short of its
  minimum, the errors of the rejected item with the fewest are reported as
  slice-rejection information beside the cardinality error (an EPS
  Bundle whose Patient lacks birthDate now names birthDate).

• The profile validator holds a Reference or a canonical to its
  element's type.versioning (#514, R4 elementdefinition.html
  §2.30.0.4.4): under specific a REST reference without _history/[vid]
  or a canonical without |[version] is a versioning-mismatch error,
  under independent one with a version is, and under any rule a
  Reference without a literal reference is. A reference that names no
  FHIR REST server counts as version specific (references.html,
  Reference.reference), so independent lists it as unevaluated.
  Constraint::Versioning and the reasons NotRestfulReference and
  VersioningRule are new.

• The operator console ships as its own image,
  ghcr.io/ferrohealth/ferrobridge-viewer (#603). docker/viewer/Dockerfile
  builds it on the bridge image's distroless base, runs as 65532:65532,
  and probes itself with the binary's healthcheck subcommand. The
  reusable release-viewer.yml, called from the release lane, builds the
  console's musl binaries with cargo auditable and its site bundle, attaches
  them to the release with their checksums, provenance and SBOMs, and pushes
  the multi-platform image with the same attestations and self-verification
  as the bridge image; a cut refuses to publish without those assets.
  compose.yaml gains a viewer profile with a read-only root, every
  capability dropped, no-new-privileges, and the OIDC client secret as a
  file secret, and CI resolves the quickstart under every profile and
  dry-runs the console image build.

• fhir-types 0.1.118 resolves a JSON member name against the element
  table (#483): TypeSchema::member answers the element an object key
  names, the type code a choice form such as valueQuantity selects, and
  whether the key is the _ sibling of a primitive (R4 json.html §2.6.2),
  and FieldSchema::choices lists a choice element's alternatives with
  their type codes. The profile validator uses both and drops its own
  copy of the choice matching. The change adds API and breaks none;
  fhirconnect moves to 0.1.132 with the requirement.

• fhir-types 0.1.119 lists every primitive type with the type its
  StructureDefinition.baseDefinition names, in each version's
  schema::SCHEMAS.primitives, read by Schemas::primitive_base_of
  (code specializes string) (#635). The new primitives field breaks a
  consumer that builds a Schemas value by hand: it adds the field.
  fhirconnect 0.1.133 follows the requirement.

Changed

• ferrobridge_fhirpath::model::path_types types a path that continues
  through a choice element (Observation.value[x].unit, the unit of
  Quantity) or below a primitive (string.extension, the extension of
  Element), so the R4 core constraint sweep now also checks those 54
  invariants (#572). Only the invariants of the five logical models remain
  untyped.

• The profile validator and the HL7 v2 face each state their support for
  an STU3 terminology server (#558). The validator supports one: a binding
  to a versioned value set, which STU3 $validate-code cannot carry, is set
  aside with the client's UnsupportedParameter and stays listed while the
  other bindings are still sent, where before one such binding failed the
  whole batch. The HL7 v2 face does not: its translations name each table
  map by canonical url, which STU3 $translate lacks, so the run fails
  before anything is sent. ferrobridge-term gains Client::check, which
  answers whether the configured release can carry a request without
  sending it, and the validator's Terminology trait gains supports,
  defaulted.

• fhirconnect 0.1.135, the HL7 v2 face and the profile validator name a
  choice element's JSON members through the element table's
  FieldSchema::choices and TypeSchema::member (#813), so the R4
  json.html §2.6.2 naming rule lives in fhir-types alone. Breaking for a
  consumer of fhirconnect::tree::element::Move: Move::Choice carries
  schema: &'static FieldSchema in place of variants, whose alternatives
  schema.choices() lists.

• The profile validator indexes each Bundle once per validation, its
  entries by fullUrl and by their resource, so resolving a reference
  inside a Bundle no longer scans every entry twice (#515). A synthetic
  document of 12002 entries validates in 3.6 s instead of 9.9 s in a
  release build; the matching rules of R4 bundle.html §2.36.4.1 are
  unchanged.

• The profile validator checks an invariant a profile declares on a choice
  element it narrows against the types the profile keeps (#573, R4
  elementdefinition.html §2.3...

0.0.7

Changed

• A facade search translates a conceptmap code once per request (#763):
  the page and its Bundle.total share the answers of one terminology
  session, so a code repeated across their entries costs one
  ConceptMap/$translate call. Nothing is kept past the request.

• The facade, the FHIRconnect operations lane, mapping check and the
  operator API load a FHIRconnect set through one path,
  mappings::compile (#725): one read, one template resolution from the
  template directory or the CDR, one compile loop. The boot refusals are
  unchanged.

• fhirconnect 0.1.131: the four seam traits, ReferenceSource,
  IdentitySink, Terminology and MappingFunctions, require
  Send + Sync, and a compile-time assertion keeps Seams Send, so an
  async caller holds the seams of a run across an .await (#764). This
  breaks the crate's public API: an implementation that holds a Cell or a
  RefCell moves to a Mutex or an atomic. The facade's transaction path
  now looks a reference up in the Bundle's own entries through
  BundleReferences instead of copying them into its resolved set.

• A facade search lists every resource a hierarchy.split with
  create: resource creates beside the entry's own resource, each once
  (#731). A page holds at most _count resources and may end between two
  occurrences of one entry, Bundle.total counts every resource (the count
  reads the rows for such a context), and an _id naming a created resource
  answers that resource alone instead of matching nothing.

• fhirconnect 0.1.130: the four operations::run entry points
  (to_fhir, to_fhir_with_warnings, to_openehr,
  to_openehr_with_warnings) take the caller's &Seams in place of a
  &dyn MappingFunctions (#722), so a caller supplies the terminology server
  beside the mapping functions. This breaks the crate's public API: a
  consumer passes &Seams::default().with_functions(functions) where it
  passed functions. $toopenehr resolves a reference outside the request
  Bundle through the reference source the seams carry.

• The facade resolves a reference a request names and does not carry, for a
  reference mapping that reads it (#224). A relative reference, or one under
  [facade] base_url, is read through the identity map and the CDR; an
  absolute one is fetched only from a base listed in the new
  [facade.references] fetch_bases (empty by default, so nothing is fetched
  until you list a base), with redirects refused, timeout_ms (default
  10000) per fetch and max_depth levels (default 2), each reference once. A
  reference that is not resolved is a declared skip the write proceeds
  without; the log names the reference, the base and the upstream status, and
  $validate answers it as a warning issue. In a transaction Bundle an
  entry answers a reference to its fullUrl or its <Type>/<id> first
  (#753).

• ferrobridge-term translates by concept map with an optional target
  system and an optional reverse (#721). This breaks the crate's public
  API: Client::translate takes a Translation (Translation::new(system, code) with with_version, with_concept_map, with_target_system and
  with_reverse), and Request::Translate wraps one. Each of version,
  url, targetsystem and reverse is sent only when it is set, as R4
  ConceptMap/$translate declares each 0..1, so a FHIRconnect
  conceptmap, which names only the map, can be translated in both
  directions.

• A resource the facade's outbound mapping creates, a further
  hierarchy.split occurrence with create: resource or the target of a
  reference mapping, is no longer carried as a contained resource with a
  #id reference (#225). It gets an identity-store binding of its own under
  an id derived from its parent's entry, the creating mapping and the openEHR
  occurrence, stable across re-runs and composition versions, and the parent
  references it as <Type>/<id>. GET /fhir/<Type>/<id> and the vread answer
  it, a PUT of it answers 405, and a type only a reference creates is
  declared with read and vread in the CapabilityStatement. The identity
  store writes schema 3 and reads schemas 1 to 3; a file of schema 1 or 2
  opens unchanged and is stamped 3, and a build before this one refuses a
  schema 3 file by name.

• The FHIRconnect operations lane reads its mapping directory through the
  walk the facade uses (#524), so a .YML or .YAML file is now read by both
  lanes; the operations lane read only the lower-case spellings before.

• The README, the book's Licensing page and the landing page answer "do you
  need a commercial licence?" at a glance (#111): a table of what you are
  doing, what you need and the part of LICENSE that decides it, the same
  shape as the FerroHEALTH family table, with the change date and the
  commercial-licence contact beside it. The README's top navigation links the
  table, and the ferrobridge-fhirpath and ferrobridge-validator READMEs
  state the terms like the other BUSL-1.1 crates.

• SECURITY.md and CONTRIBUTING.md keep what is particular to FerroBRIDGE
  and link the FerroHEALTH family book at https://ferrohealth.eu/docs/ for
  the rest (#402). SECURITY.md keeps the supported versions, the reporting
  route, the response times, the scope and release verification, and links
  the family policy for disclosure, advisories and the support period.
  CONTRIBUTING.md describes the current build and test gate,
  scripts/checks/fast.sh. The README and the book's introduction link the
  family book for the manufacturer, the Cyber Resilience Act, how the
  products fit together, and licensing and trademarks.

• The identity store records its schema (#298): a file with no schema row,
  which 0.0.6 or earlier wrote, reads as schema 1 and is stamped on open, and
  a file in a schema this build does not read stops the start with an error
  naming the file, the schema found and the schemas this build reads, leaving
  the file unchanged. The schema this build writes is in the entry for #225.

Added

• The console shows the mapping files (#607): the list from GET /operator/mappings with each file's language, kind, owner, whether it is
  writable and its diagnostics count, and each file at /files/{path} from
  GET /operator/mappings/{path}, verbatim, one numbered line per line, its
  YAML highlighted on the server and its SHA-256 from the ETag. Beside
  each file are the running load's diagnostics about it, read into
  openehr_mapping_core::diagnostic::Diagnostic and each linked to its
  line. A file that is not UTF-8 is refused, never shown altered, and a path
  that is not plain names below a root is refused before the bridge is
  asked.
• The console shows the engine state (#604). The dashboard has the
  bridge's build facts, pins, lanes and listeners from GET /health/info,
  its readiness indicators from GET /health/readiness, and the counts of
  its running load from GET /operator/state. The capability screen shows
  the R4 CapabilityStatement as cards for its resources with their
  interactions, search parameters and operations, the system level and the
  security, with the JSON behind a disclosure and the SMART discovery
  document beside it. The mappings overview shows each context's program
  with its template, profile, resource type, models, extensions and search
  declaration, the templates with their source, the OMOCL files, and every
  diagnostic, read into openehr_mapping_core::diagnostic::Diagnostic. Each
  screen is drawn on the server. A refused or unreachable call draws its
  status and diagnostics, or the fault, in its section.
• The console has its shell and visual system (#601): a role layer
  (surface, ink, muted, accent and the status tints) derived from the
  "Indigo & Iron" brand tokens, the light, dark and system themes drawn by
  the server from a cookie and switched by a plain form post, the top bar
  with the bridge's status and version as a word and a tint, the theme
  switch and the operator menu, the navigation grouped Overview, Mappings,
  Tools and Bridge with a drawer on a narrow screen, a skip link, an About
  page naming Cadasto B.V., and the page for a path the console does not
  serve. A test computes WCAG 2.2 contrast for every text and ground pair in
  both themes (4.5:1 for text, 3:1 for a control edge and the focus ring),
  and the scroll padding keeps a focused control clear of the top bar (SC
  2.4.11). The WebAssembly budget rises to 244 KiB with the measurement in
  .claude/rules/leptos-ui.md.
• The operator API saves search declarations (#766): PUT /operator/mappings/fhirconnect/{name}.search.yml checks the declaration
  against the context it names and writes it under
  mapping_dir/fhirconnect/, where it was refused with 400 before. The
  reload binds every declaration, provisioned and console, and swaps them in
  with the facade's programs. A declaration that does not bind answers 422
  with an fb-search-declaration diagnostic and changes nothing.
• The operator API saves OMOCL files (#757): PUT /operator/mappings/omocl/{path}
  checks the draft with the whole set and writes it under
  mapping_dir/omocl/, where it was refused with 409 before. etl run
  reads that directory beside [mappings] omocl whenever the operator API is
  on, through the same OMOCL load the reload checks with: a provisioned file
  owns a path both directories hold, and two files that define one mapping
  refuse the run.
• The operator API checks, saves and reloads mapping files (#597), with
  [operator] mapping_dir set: POST /operator/mappings/check?path= answers
  a draft's diagnostics over the running set; PUT /operator/mappings/{path}
  with If-Match (or If-None-Match: *) and a Ferrobridge-Reason header
  saves a FHIRconnect file under mapping_dir/fhirconnect/ when the whole
  set compiles with it, written to a synced ...

0.0.6

Added

• A FerroBRIDGE OMOCL Person mapping for the KDS person template (#568),
  crates/omocl/tests/fixtures/projects/ferrobridge/kds_person/kds_person_data.yml.
  The corpus file person_data/person_data_v0.yml reads gender at
  items[at0019], which KDS_Person does not carry, so every KDS person
  took gender_concept_id 0. This file reads the administrative gender at
  items[at0022]: its code resolves through the loaded OHDSI vocabulary
  into gender_concept_id and is kept in gender_source_value, and a person
  with no gender, or a code with no standard concept, takes concept 0. Point
  [mappings] omocl at a directory holding it in place of the corpus file.
• [etl.vocabulary_aliases] maps a terminology id, such as a URI or an OID,
  to the OHDSI vocabulary_id the ETL looks a coded value up in (#625).
  The table is added over the defaults (LOINC to LOINC, SNOMED-CT to
  SNOMED) and checked at load: an empty id or vocabulary, or a vocabulary
  longer than the 20 characters of OMOP CDM v5.4 VOCABULARY.vocabulary_id,
  refuses the start. A KDS administrative gender coded under
  http://terminology.hl7.org/CodeSystem/v2-0001 now reaches
  person.gender_concept_id once that id is aliased to the vocabulary that
  holds its codes; before, any terminology id longer than 20 characters
  resolved to concept 0.
• The FHIR facade answers batch Bundles on POST [base] (#531). Each entry
  runs as the read, vread, search, create or update its request names,
  through the same handler as the single interaction, with ifMatch and
  ifNoneExist as its conditional headers and the request's
  Prefer: return applied to it, and the answer is a batch-response
  Bundle with one entry per request entry in the same order, each carrying
  its status, location, etag and resource, or its OperationOutcome in
  response.outcome (R4 http.html §3.1.0.11). A CDR refusal of one entry is
  that entry's status through the status table and the others still run.
  Under [auth] each entry is authorised on its own, and an entry the token
  does not cover, or one outside a patient/ token's compartment, answers
  403 inside the response. An entry referencing another entry's fullUrl
  answers 400, as R4 calls it non-conformant, and a Bundle with an entry
  that has no request, or a POST or PUT with no resource, is refused
  whole with 400. Each entry leaves its own audit line, with its position
  as entry, beside the request's line, whose interaction reads batch. The
  CapabilityStatement declares batch beside transaction.
• The FHIR facade answers search (#98): GET [base]/{type}?… and
  POST [base]/{type}/_search over an AQL projection declared beside the
  context mapping, in a <name>.search.yml file that names the context, the
  subject parameters, the token, string and date parameters with the
  repeated node each is read under and its path relative to that node, and
  the total order pages are read in. The query binds that node in its FROM
  once per parameter occurrence, so a token's code and system always come
  from one coded value (#526), a path crossing a node the template lets repeat
  below the bound one is refused at load, and a composition matching on
  several nodes is one entry, counted once. FHIRconnect leaves
  search out, so the format is FerroBRIDGE's own. Every declaration is checked
  and every query it can build is parsed at boot, and a declaration that does
  not parse refuses the start. A search answers a searchset Bundle with an
  id, meta.lastUpdated, one entry per composition with a unique fullUrl
  and search.mode = match, total counting matches, and self and next
  links over the CDR's offset and fetch paging. _id, _count (capped by
  the new [facade] search_count_max, default page search_count), _count=0
  and _summary=count, _sort and _total are supported. A parameter the
  type does not declare is a 400 naming it unless the client sends
  Prefer: handling=lenient; an unsupported modifier is always a 400. An
  unknown subject or id is an empty searchset with no CDR call, and a CDR
  refusal maps through the facade's status table, a query 400 to a 500 and
  a query 408 to a 502. The CapabilityStatement names search-type and
  exactly the declared parameters with _id. Under [auth], a search needs
  the s permission of its type, and a patient/ token's search is held to
  its patient's EHR.
• FHIR Patient from the KDS person template through FHIRconnect (#468).
  The published KDS person chain of the FHIRconnect mapping library compiles
  against the published KDS_Person operational template, which
  scripts/vendor/kds-person-opt.sh vendors from the openFHIR test resources,
  under a FerroBRIDGE project context, and a synthetic MII Person Patient
  holds both lens laws through it. The published files that do not load,
  compile or convert are replaced by stand-ins, each refusal pinned by file
  and line; the defects are recorded on #475 and #468. Seven library files
  join the mapping-library pass list and the chain joins the round-trip one.
  fhirconnect 0.1.114 adds the DV_DATE against date and DV_BOOLEAN
  against boolean cells, reads value on a primitive as the primitive
  itself, the form FHIRconnect writes in a condition, and writes the
  context's health_care_facility as the _health_care_facility family. The
  facade keys a Patient by its first identifier with a value, so a
  Patient written through it is stored as the KDS_Person composition of
  its own EHR and reads back.
• The terminology client speaks FHIR STU3 (3.0.2) beside R4 and R4B (#455).
  [terminology] wire_version = "stu3" selects it, and every operation and
  the batch go through the generated STU3 operation contracts. The client
  sends a code system version as STU3's version on $validate-code, reads
  STU3's code-typed $lookup property values, and reads the same
  $translate match parts and equivalence codes as R4. A request naming a
  parameter STU3 does not declare (a concept map URL on $translate, a
  value set version on $validate-code) is refused with
  Error::UnsupportedParameter before anything is sent.
• The FHIR facade authenticates its callers as a SMART App Launch 2.x
  resource server (#400). A new [auth] section, off by default, names the
  issuer and the audience; the issuer's metadata and key set are read at
  boot, and every request under /fhir needs a bearer JWT access token
  (RFC 9068 profile by default) except GET /fhir/metadata and the new
  /.well-known/smart-configuration document. A missing or invalid token
  answers 401 and a token whose SMART v2 scopes (patient/, user/,
  system/ with cruds, v1 .read and .write included) do not permit
  the request answers 403, neither naming a claim or a scope. A
  patient/ token reaches only its patient's compartment, a transaction is
  authorised entry by entry and fails whole, a create that revises a
  resource the facade holds needs u beside c, a scopeless token gets system
  rights only for a listed subject, and every FHIR request leaves one audit
  line on the ferrobridge::audit target without the token or the body.
  The CapabilityStatement carries rest.security with the SMART service
  and the oauth-uris extension. With [auth] off the facade stays open,
  and the server warns at start-up.
• The R4 profile validator evaluates every invariant on every element in
  play, the core definitions' and each profile's, with ferrobridge-fhirpath
  on each occurrence of its element (#439). The focus is the element,
  %resource the resource holding it and %rootResource its container when
  it is contained. A failed invariant is an issue of type invariant under
  its key and declaring canonical with the constraint's own severity; a
  best-practice one (elementdefinition-bestpractice) is a warning unless
  Validator::with_best_practice(BestPractice::Error) asks for errors. An
  empty result neither meets nor breaks the rule, which asks for "true"
  (conformance-rules.html §2.1.0.6), and is listed (Reason::InvariantEmpty). resolve() reaches contained resources
  and Bundle entries, memberOf() reads the value sets of the package set
  and conformsTo() validates against a profile of it. An invariant whose
  expression does not parse, does not fit its element's type or does not
  evaluate, including a call the run cannot answer, is listed as unevaluated
  with the error (Reason::InvariantRefused and Reason::NoExpression
  replace Reason::Invariants), and the published defects of
  cid-0, inv-1 and dom-3 name their upstream report. A constraint the
  snapshot repeats from the core is evaluated once per occurrence.
  ferrobridge-fhirpath adds Focus::within to name the resources
  %resource and %rootResource stand for.
  and the server warns at start-up. The guard classifies every route under
  /fhir by name, and a route it does not classify answers 403 without
  reaching a handler, so a route added without a classification fails closed
  (#547).
• fhir-types 0.1.111 names each type's base type in the element table
  (TypeSchema::base, from StructureDefinition.baseDefinition, and for a
  backbone element the BackboneElement or Element its element names), in
  every version, and carries the abstract types a base chain passes through
  (Resource, DomainResource, BackboneElement, and from R5 Base,
  DataType and BackboneType) as table-only entries.
  Schemas::base_of and Schemas::specializes walk the chain.
  ferrobridge-fhirpath reads it, so is, as, ofType and a leading type
  name see Age as a Quantity and Patient as a DomainResource and a
  Resource; the R4 profile validator takes a resource under an element typed
  DomainResource only when its type specializes `...

0.0.5

Changed

• The repository moved to the FerroHEALTH organization
  (https://github.com/FerroHEALTH/FerroBRIDGE, #385); the old
  rubentalstra/FerroBRIDGE URLs redirect. The image now publishes to
  ghcr.io/ferrohealth/ferrobridge, and the quickstart, the book and the
  landing page name that reference. Everything published up to v0.0.4 stays
  available under ghcr.io/rubentalstra/ferrobridge, and its signatures name
  rubentalstra/FerroBRIDGE as the repository that built it (SECURITY.md).
  The roadmap board is now https://github.com/orgs/FerroHEALTH/projects/3.
  fhir-types steps to 0.1.107 for its new repository field and README
  links.