4.3.6

Added

• The server verifies the audit hash chain on a schedule (#3640, CRA
  Annex I Part I(2)(f)): [audit.store] verify_interval_seconds (default one
  day, 0 turns it off). A finding is logged at ERROR, counted in
  atna_audit_chain_findings and reported as the audit_chain indicator.

• The running server states its support period (#3639): five years from
  the release month (CRA Art. 13(8)) on the boot banner, in ferroehr --version, on GET /management/info and on the REST status document
  (support.status is supported, ended or unreleased). Once the period
  has ended it logs a WARN at boot and daily (CRA Art. 13(19)).

• More access records carry EHDS priority categories (#3653): logical
  composition deletes, CONTRIBUTION reads with or without resolve_refs,
  VERSIONED_COMPOSITION reads, and EHR Extract export and import records;
  EHR_ACCESS is classified none.

• FerroEHR's intended purpose is stated (#3641). The new book page
  Intended purpose is Cadasto B.V.'s statement of who FerroEHR is for, the
  data it is designed to process (with the EHDS Art. 14(1) priority
  categories), the environment it runs in, the security environment it
  assumes (TLS termination, an identity provider, database protection) and the
  misuse it foresees (CRA Art. 3(23), Annex II point 4; EHDS Annex III 1(a)).

• A CRA cybersecurity risk assessment (#3635). The new book page CRA risk
  assessment rates FerroEHR's cybersecurity risks, states for each point of
  CRA Annex I Part I(2) whether it applies, how it is implemented, the
  evidence and the open issue, justifies the limbs that do not apply
  (automatic updates, application-level encryption at rest, configuration
  integrity), and lists every outbound data flow, the usage report included
  (CRA Art. 13(2) to (4)).

• A hazard log for the access log (#3618). The new book page Hazard log
  lists nine patient-safety hazards of the European logging software
  component, each with its control, the tests that show it holds and what
  remains (EHDS Annex II 1.1).

• A claims review (#3619). The new book page Claims review records the
  reading of every public text against EHDS Art. 28, release by release, and
  re-assesses EHDS Annex II 2.5 against the authorisation defaults.

• An information sheet and instructions for use accompany every release
  (#3617). The new book pages Information sheet (every point of EHDS
  Art. 38(2): the manufacturer, the name, version and release date, the
  intended purpose, the Art. 14(1) data categories, and the standards and
  their versions) and Instructions for use (what FerroEHR runs on, an EU
  deployment's configuration with deployment_profile = "production",
  [audit.categories] and retention_years, the maintenance it needs and how
  often, and the known limitations EHDS Art. 28(b) asks to be stated, with the
  CRA Annex II user information mapped point by point). The release lane
  attaches both, cut from the tag, to each GitHub release
  (scripts/release/accompanying-documents.sh).

• The CRA information and instructions to the user, linked from every
  release's notes (#3650). The new book page CRA information and
  instructions to the user carries each point of CRA Annex II in order (the
  manufacturer, the vulnerability contact, identification, intended purpose
  and security properties, the risks, the declaration of conformity, the
  support period, the instructions of point 8(a) to (f) and the SBOMs), each
  with its source. The release notes link the copy frozen for the tag, and
  the release lane refuses notes without that link or the support period
  (scripts/checks/release-notes.sh, CRA Art. 13(18)). Rust crates gains
  the information for integrators of the openehr-* crates that point 8(f)
  asks for.

• The technical documentation of EHDS Art. 37 and CRA Annex VII (#3616)
  is kept in docs/technical-documentation/, one file per Annex III element
  and per CRA Annex VII point that adds one, each citing its evidence. A
  release that changes the logging component updates it
  (scripts/checks/technical-documentation.sh --since <previous tag>, EHDS
  Art. 30(2)), and the tree states how each release's documentation is kept
  for ten years, where the declaration of conformity will be published, and
  how a translation is requested.

• SECURITY.md names how to hear of new releases (#3639): subscribe to
  the release feed (https://github.com/FerroHEALTH/FerroEHR/releases.atom)
  and poll the published advisories
  (GET https://api.github.com/repos/FerroHEALTH/FerroEHR/security-advisories),
  since the server does not look for newer releases itself.

• A Cyber Resilience Act page (#3626) states FerroEHR's position under the
  CRA: Cadasto B.V. as manufacturer, why BUSL-1.1 is not free and open-source
  software under CRA Art. 3(48), the reporting duty in force since 11
  September 2026, the five-year support period, the conformity route through
  the EHDS (CRA Art. 32(5a)), the default-product reading beside the competing
  Annex III class I reading, the hosted-service case, and the questions for
  counsel.

• Vulnerabilities can be reported by email (#3646): SECURITY.md,
  security.txt (a second Contact: mailto:info@cadasto.com) and the
  Complaints, incidents and vulnerabilities page name info@cadasto.com
  beside GitHub private vulnerability reporting, so a report needs no GitHub
  account (CRA Art. 13(17)). An emailed report runs through the same
  procedure and starts the same CRA Art. 14 clock.

• Component vulnerabilities are reported upstream (#3648). Cadasto B.V.
  reports a vulnerability it finds in an integrated component to that
  component's maintainer and offers its fix (CRA Art. 13(6)), and records each
  report in the new public register docs/registers/upstream-reports.tsv.

• What happens if Cadasto B.V. ceases operations (#3651): SECURITY.md
  and the Complaints, incidents and vulnerabilities page say whom the
  manufacturer tells, in which order, that the support periods end on the
  cessation date and that every published release stays published (CRA
  Art. 13(23)).

• Every access record carries the EHDS priority categories of the data it
  served or wrote (#3621, Annex II 3.2(c)). A new [audit.categories] map
  classifies an access from the template id, then the root archetype id, as
  patient-summary, eprescription, edispensation, imaging,
  test-results, discharge-report, national:<code> or none. An access the
  map cannot classify is recorded unclassified with its ids and is never
  refused. The map's digest is on the boot line, on GET /management/info and
  on every record, and the FHIR AuditEvent carries the classification as
  entity details.

• The retention register can key a period on an EHDS priority category
  (#3621, Annex II 3.4): category on PUT /admin/retention/policy, echoed by
  the policy and due lists. The category map is mirrored into the register at
  boot, and an unclassified object takes the longest period configured for its
  kind.

• [audit.store] retention_years (#3625) states the access-log horizon in
  calendar years as an alternative to retention_days. It is compared exactly
  against the retention floors and ceilings, which are now registered in years,
  and reaped with calendar arithmetic; setting both keys is a boot error.

• The regulation corpus gains the EHDS implementing acts and the
  market-surveillance acts (#3607). docs/law/eu/ now carries Commission
  Implementing Regulations (EU) 2026/2083 (MyHealth@EU) and 2026/2099
  (cross-border identification and authentication), both applying from 26
  March 2027; Commission Recommendation (EU) 2019/243 on the European
  electronic health record exchange format, which EHDS recital 26 names;
  Regulation (EU) 2019/1020 on market surveillance, whose Article 3
  definitions EHDS Article 2(1)(d) takes over, at its consolidation of 12
  August 2026; Regulation (EC) No 765/2008, whose Article 30 sets the general
  principles of the CE marking, at its consolidation of 16 July 2021; and CRA
  Implementing Regulation (EU) 2025/2392 on the important and critical product
  categories. Each is fetched by scripts/vendor/law-eu.sh with its own
  provenance record and digests.

• The CRA record carries the Regulation's three English corrigenda
  (#3607). They correct the title, Article 64(10) ("paragraphs 2 to 9", where
  the published text says "3 to 9") and the point number Article 67 adds to
  Directive (EU) 2020/1828. The vendored OJ text includes none of them, and
  docs/law/eu/cra/PROVENANCE.md says which file to cite for which provision.

• Complaints, serious incidents and exploited vulnerabilities have a
  written procedure (#3613). The new book page Complaints, incidents and
  vulnerabilities names FerroEHR's manufacturer, Cadasto B.V., and its single
  point of contact, the channels (GitHub private vulnerability reporting;
  info@cadasto.com with "FerroEHR incident" or "FerroEHR complaint" in the
  subject; a public issue), the public registers of complaints and of
  non-conforming versions under docs/registers/, and what happens on a
  non-conformity, an EHDS serious incident (reported within three days of
  awareness, EHDS Art. 44(7)) and an actively exploited vulnerability or severe
  incident (the CRA Art. 14 early warning within 24 hours, notification within
  72 hours and final report), with NIS2 kept separate. docs/post-market.md
  is the maintainers' checklist; SUPPORT.md and the issue chooser point to
  the page.

• A non-conforming release can be withdrawn (#3615).
  scripts/release/withdraw.sh <version> --to <version> refuses a version the
  register of non-conforming versions does not name, moves the
  <major>.<minor> and latest tags of the server, viewer and PostgreSQL
  images that still point at it to the correcting release, and prints the
  advisory, the SECURITY.md line, the notices to authorities and users, and
  the register columns to fill. The version's own tag, its digests and its
  chart version stay published, so a deployment pinned to them keeps running
  it until it is moved; an OCI chart registry cannot mark one chart version
  deprecated, and the notice says so. --dry-run prints every command and
  changes nothing.

• The regulation corpus gains the CRA delegated acts and the NIS2
  corrigendum (#3627). docs/law/eu/ now carries Commission Delegated
  Regulation (EU) 2026/881 (when a CSIRT may delay passing on a CRA Art. 14
  notification, CRA Art. 14(9) and 16(2)) and (EU) 2025/1535 (the CRA Art.
  2(5) exclusion of products within Regulation (EU) No 168/2013), and the
  English corrigendum to NIS2 Art. 19(1) beside the NIS2 text, whose record
  now says which file to cite. docs/law/README.md records Implementing
  Regulations (EU) 2026/771 (the EHDS Board) and 2026/2098 (dataset metadata
  for secondary use) as adopted and not vendored, with the reason.

• Every release states its support period (#3610). Cadasto B.V. is the
  manufacturer of each tagged release under the Cyber Resilience Act, and
  SECURITY.md now gives each release a support period of five years from the
  month it is published (CRA Art. 13(8)), with the end date printed in a new
  "Support period" section of the release notes (Art. 13(19), Annex II point
  7). The security update for a release in its support period ships in the
  newest release (Art. 13(10)).

• SECURITY.md describes the CRA Art. 14 notifications (#3609): the
  early warning within 24 hours, the notification within 72 hours and the
  final report Cadasto B.V. sends through ENISA's single reporting platform to
  the Dutch CSIRT for an actively exploited vulnerability or a severe incident,
  and how users are told through the security advisory.

• A weekly EUR-Lex watcher (#3608) files one issue per new act adopted
  under, amending or correcting the EHDS (Regulation (EU) 2025/327) or the CRA
  (Regulation (EU) 2024/2847), naming the article it implements, against a
  committed baseline of the 18 acts known on 2026-10-06.

• The control matrix knows the CRA (#3606) as a legal source, so a control
  can declare a CRA article.

• The running system names its manufacturer (#3612), as EHDS Art. 30(1)(g)
  asks: Cadasto B.V., Comeniusstraat 2d, 1817 MS Alkmaar, The Netherlands,
  info@cadasto.com, https://www.cadasto.com/contact/. It appears on the
  startup banner, in ferroehr --version, as a manufacturer object on
  GET /management/info, in the viewer's footer and a Manufacturer card on
  /system, and in an eu.ferroehr.image.manufacturer label on the three
  container images, all read from one source file.

• ferroehr report (#3614) writes one redacted JSON document naming what a
  deployment runs: version, commit, build date, enabled features,
  specification pins, openehr-* crate versions, the migration level of each
  schema set, the deployment posture, the licence summary, the manufacturer and
  the effective configuration. A manifest names any part it could not read and
  why. No credential, URL userinfo or patient data reaches it: its configuration
  passes the same userinfo masker as ferroehr config check (#3629). Attach it
  to a complaint or a serious-incident report.

• The Helm chart carries the access-log category map and the calendar-year
  horizon (#3655): config.audit.categories (empty templates and
  archetypes, as in the binary) and config.audit.store.retention_years
  (unset) in values.yaml, typed by shape in values.schema.json. Chart 11.0.1.

• The Helm chart and the Compose files declare the deployment profile
  (#3637): config.deployment_profile: sandbox, with a comment listing what
  production refuses under the chart defaults, and
  deployment_profile = "sandbox" in the quickstart, dev and hosted-sandbox
  configurations. The new book page Returning to the original state resets
  an instance's configuration and database, and the deploy-probe harness runs
  the Compose procedure.

• Every published artefact has an SBOM (#3643): each release attaches a
  CycloneDX SBOM per openehr-* crate, attested against the .crate archive
  crates.io serves, and each chart version attests a CycloneDX SBOM naming
  every image it deploys by digest.

• Every release publishes an exploitability record (#3636): every image
  and server binary is scanned with no severity floor and with unfixed
  findings included, each finding is joined with its OpenVEX statement in
  ferroehr-<tag>-vulnerability-record.json, and the release is refused,
  before any image is tagged, while a finding has none.

• The CRA risk assessment declares its security-relevant paths (#3649).
  A release that changes one of them since the previous release is refused
  until the assessment gains a revision row.

• ferroehr db erase permanently removes all data and settings of an
  instance (#3642; CRA Annex I Part I(2)(m), Annex II point 8(d)). It deletes
  every multimedia blob FerroEHR wrote, then drops the ext, clinical,
  party, linkage and audit schemas, one transaction per database. Without
  --confirm it is a dry run that prints what it would remove and the value
  that confirms it (the stored instance id, or the clinical database's name). A
  wrong value or an unreachable blob store refuses before anything is touched,
  and a rerun after success is a no-op. The new Decommissioning page covers
  the retention duties before erasing and what the command cannot reach:
  backups, WAL archives, replicas, the chart's Secrets and claims, database
  roles, configuration files and media remanence.

• Patient-data requests can require an authentication assurance level and a
  natural person (#3622; EHDS Annex II 3.1 and 3.2). [auth.oidc.assurance]
  maps the token's acr (or another claim) to the eIDAS levels low,
  substantial and high; with minimum set, a patient-data request below it is
  refused with 401 and an RFC 9470 insufficient_user_authentication
  challenge naming the accepted acr_values. [auth.oidc.professional] names
  the claim identifying the natural person; a client token is then refused on
  patient data with 403 unless acting_for_claim names the professional it
  acts for. Basic credentials are refused on patient data when either block is
  set. The access record gains the acting mode, the assurance level and its raw
  value, and the professional's identifier (audit migration 0009); the FHIR
  AuditEvent and the DICOM message render the professional as the requesting
  participant and the client application as a second one, and neither format
  can carry the assurance level. Both blocks are off by default.

• An emergency access is marked in the access record (#3624; EHDS Art.
  11(5)). [audit] emergency_purpose_codes names the agreed purpose-of-use
  codes that declare an access necessary to protect the vital interests of the
  patient; an access declaring one carries emergency_access in its record
  (audit migration 0010) and, on the FHIR AuditEvent, a purposeOfEvent with
  HL7 v3 ETREAT and a plain-words text, so the patient's subject-scoped
  ITI-81 retrieval shows it. Each code must also be on purpose_codes, or the
  server refuses to start. The mark lifts no restriction: a GDPR Art. 18
  restricted object is refused with an emergency purpose exactly as without
  one. The DICOM syslog message has no purpose element and does not carry it.

• production refuses three more plaintext paths (#3676, #3689; CRA Annex
  I Part I(2)(e)). An enabled change-event outbox on a plain amqp:// broker
  (no amqps://, no tls = true) opens
  plaintext_broker; an enabled audit FHIR feed on an http:// URL opens
  plaintext_audit_feed; an enabled multimedia store with allow_http = true
  opens plaintext_object_store. Each refuses boot unless accepted by name in
  deployment_accepts, and the viewer's deployment notice names each in plain
  words.

• The Helm chart ships values-production.yaml (#3678), an overlay that
  boots under deployment_profile = "production": one database Secret per
  storage domain, a migration Job under migrate = verify, the audit trail
  failing closed, a restricted EHR_ACCESS default, declared subject
  namespaces, OIDC, and a TLS Ingress with a NetworkPolicy admitting only the
  ingress controller. It accepts plaintext_listener by name, because TLS ends
  at the Ingress. Chart validation and the boot check cover it.

• Every binary in the published images lists its Rust dependencies
  (#3675): the server and viewer binaries inside the images, and the viewer
  image built from source, are built with cargo auditable, so an image scan
  and the release's exploitability record see the Rust graph. The OpenVEX
  statement for RUSTSEC-2023-0071 now covers the viewer image.

• Every operating-system finding in the three images carries an OpenVEX
  judgement (#3673): ferroehr-os.openvex.json (25 statements for the
  distroless ferroehr and ferroehr-viewer images) and
  postgres-os.openvex.json (101 for ferroehr-postgres), each argued from
  what the shipped programs load and import. Seven are affected, with an
  action statement: CVE-2026-8674 (a long resolver search domain) in all three
  images, and three libxml2 and two glibc JISX0213 findings any database login
  reaches through PostgreSQL's XML functions, which FerroEHR itself never
  calls. The release's exploitability record now has a judgement for every
  finding.

Changed

• The family-level documentation moved to the FerroHEALTH book (#3701), at
  https://ferrohealth.eu/docs/: the manufacturer, the security policy shared
  by every FerroHEALTH product (response times, disclosure, advisories,
  security-only patches, CRA Art. 14 reporting, cessation of operations), the
  post-market procedure, the manufacturer side of the CRA, the intended purpose
  and the shared responsibility of the EHR system FerroEHR forms with
  FerroBRIDGE, licensing and trademarks, and how the products fit together.
  The book pages Complaints, incidents and vulnerabilities, Cyber Resilience
  Act, Intended purpose, Shared responsibility and Licensing & legal keep
  their addresses and now carry only FerroEHR's own facts, with a link to the
  family page. SECURITY.md keeps FerroEHR's supported versions, its reporting
  routes and scope, and the repository's security settings. The information
  sheet, the instructions for use, the EHDS readiness and technical
  documentation pages, the CRA risk assessment and the Annex II user
  information stay in this book.

• deployment_profile = "production" refuses two more plaintext paths unless
  each is accepted by name. A syslog audit feed with transport = "udp" opens
  the new audit_syslog_udp gap (#3669, EHDS Annex II 1.4): set
  [audit.syslog] transport = "tls", or accept the gap where the UDP path stays
  on a trusted segment. A separate management listener ([management] port)
  now opens plaintext_listener (#3668), because it binds every interface in
  plain HTTP: unset the port so the surface shares the main listener, or accept
  the gap where the port is unreachable off the host.

• What FerroEHR answers without a credential says only what a client or
  probe needs (#3671). /health/readiness keeps its 200/503 semantics
  but its body carries the aggregate status and each indicator's name and
  status only; the detail moves to GET /management/health. The public
  {rest root}/status keeps status, versions, timestamp and the deployment
  profile; the licence, the deployment gaps and the support period move to
  GET /management/status. Both new endpoints are off until
  [management.endpoints] names a level for them. The Security page lists
  every route reachable without a credential and why, and a test drives every
  mounted route to keep that list closed.

• Licence tokens are verified against the licensor's two master keys. A
  [licence] file token is accepted when it carries exactly one text
  signature, made directly by one of the two embedded Cadasto B.V. keys
  (F2D214FC30698BA65A846B2BF2EA48D4C316406D,
  0BCE848225EFAECA912175292DBFB014CA506311); whether a key may sign is read
  from the embedded certificate, never from the copy the token carries. The
  previous licensing key is no longer trusted, and the embedded
  non-commercial grant is re-signed (licence id
  01a1175c-cd67-777d-bdc0-c95bf1c900d3). A token signed under the previous
  key is reported as refused on /management/status, and the embedded grant stays
  in force; the server behaves identically either way.

• deployment_profile = "production" refuses two more postures (#3638):
  auth.enabled = false (auth_off) and a plaintext listener on a routable
  address (plaintext_listener), unless the gap is named in
  deployment_accepts. A loopback bind is exempt; a deployment behind a
  TLS-terminating ingress accepts plaintext_listener by name.

• A security fix ships in a security-only patch release (#3644), unless
  the release notes record why that was technically infeasible (CRA Annex I
  Part II(2)); SECURITY.md no longer leaves it open.

• Every fixed vulnerability gets a GitHub security advisory (#3645), for
  FerroEHR's own code and for a dependency or base-image fix that changes a
  shipped artefact, with a CVSS severity, the affected and fixed versions and
  the remediation; the changelog's ### Security entry carries the GHSA-
  identifier. SECURITY.md states when the technical details of a fixed
  vulnerability may be published later (CRA Annex I Part II(4)).

• The README, the landing page and the book no longer claim multi-tenancy,
  "spec-compliant" or "hardened by default" (#3619). FerroEHR is
  single-tenant; the openEHR conformance record is described as measured, with
  the version it measured; the README states that TLS is off by default, that
  the shipped profile is sandbox, and that FHIR R4 mapping is FerroBRIDGE's.

• The EHDS readiness and technical-documentation pages follow the
  manufacturer decision (#3626). Every Annex II row was re-read on
  2026-10-06; the open questions are replaced by the decisions of #3606 (Cadasto
  B.V. is the manufacturer, FerroEHR with FerroBRIDGE is the EHR system,
  FerroBRIDGE ships the interoperability component) and the questions for
  counsel; rows 3.1 and 1.3 now say what is missing (the assurance level, the
  emergency-override mark), row 3.4 reflects the category-keyed retention and
  retention_years, and each partial row links its open issue. The
  shared-responsibility page and the compliance overview state both cases:
  Cadasto B.V. is not the processor of a self-hosted deployment, and is the
  customer's processor where it hosts FerroEHR. Verifying releases counts
  nine published openehr-* crates, not eight.

• Every EU Member State carries an access-log retention floor of three
  years (#3625, EHDS Art. 9(2), applying from 26 March 2029 and 2031 under
  Art. 105). A longer national floor still wins (the Netherlands, five years),
  Switzerland keeps one year, and the boot refusal names the provision the
  floor rests on. A declared SGB V § 309 controller in Germany sets
  retention_years = 3, because no day count meets both the three-year floor
  and the three-year § 309 ceiling.

• auth.oidc.issuer and every smart URL are refused at boot when they
  carry a user name or password (#3629; OpenID Connect Core 1.0 §1.2). The
  SMART check applies even with SMART disabled, because the discovery document
  publishes those URLs.

• The system-options vendor defaults to Cadasto B.V. (#3612), read from
  the manufacturer constant (it was FerroEHR project); [server.identity] vendor still overrides it. The OCI vendor and authors labels of the three
  images, and the author of the two OpenVEX documents, name Cadasto B.V. too.

• The quickstart docker-compose.yml forwards
  FERROEHR__USAGE_REPORT__ENABLED from your shell (#3623). The report stays
  on by default; exporting the variable as false before docker compose up
  now switches it off, which it did not before.

• The ferroehr-viewer image is scanned before it is tagged (#3674): the
  release and main image lanes scan it by its pushed digest on both platforms,
  so a fixable high or critical finding stops the viewer's tags as it stops
  the server's.

• The ferroehr-postgres image drops GnuPG and the Go gosu (#3673).
  GnuPG and the libraries only it uses (gnupg, gpg, gpg-agent, gpgsm,
  gpgconf, dirmngr, pinentry-curses, libgnutls30t64, libp11-kit0, libtasn1-6,
  libksba8, libassuan9, libnpth0t64) served upstream's build-time key import
  alone. gosu is now a shell wrapper over util-linux setpriv under the same
  name, so the upstream entrypoint runs unchanged and the image carries no Go
  binary and no Go standard-library findings; the 22 gosu exceptions in
  .trivyignore.yaml and postgres-gosu.openvex.json are gone. The base is
  re-pinned to the 2026-10-06 respin of postgres:18.6.

Removed

• The in-tree FHIR connector is removed; FHIR R4 mapping is FerroBRIDGE's
  (#3080). This is a breaking change with no deprecation period. Mapping
  between FHIR and openEHR is served by
  FerroBRIDGE (BUSL-1.1), a
  separate server that keeps its mappings as FHIRconnect documents and reaches
  FerroEHR over ITS-REST. A stored fhir_mapping row does not carry over to
  it. What is gone:

  • the routes POST /fhir/r4/{resource_type},
    POST /fhir/r4/{resource_type}/$validate, GET /fhir/r4/{resource_type}
    and the /admin/fhir_mapping CRUD, with their fhir tag and the
    ferroehr-fhir.openapi.json document of the served OpenAPI (the ITI-81
    route now has its own ferroehr-audit.openapi.json document);
  • the outbound FHIR emitter on the ferroehr.fhir AMQP exchange and its
    fhir_outbound health indicator;
  • the configuration sections [fhir] (api_enabled) and [fhir.outbound]
    (enabled, url, url_file, exchange, tls, batch_size,
    poll_interval_ms, publish_max_retries) and their FERROEHR__FHIR__…
    environment forms, which now fail at boot as unknown keys;
  • the fhir_mapping table, dropped by the new clinical migration
    0013_retire_fhir_connector.sql, which also deletes the emitter's
    fhir-outbound cursor row so it no longer holds the outbox prune floor;
  • the org.fhir.rest service of the SMART discovery document;
  • the viewer's FHIR screen and its sidebar entry;
  • the Helm values config.fhir.* and secrets.fhirOutboundUrl (chart
    version 11.0.1), the fhir deploy-probe family, the
    fhir-r4-connector and fhir-mapping-store rows of the conformance
    statement, and the book pages FHIR connectors and FHIR connector
    (the EHDS priority-category table moves to EHDS readiness).

  The plaintext_broker deployment gap now concerns [events] alone. Not
  affected: the FHIR AuditEvent rendering and the ITI-81
  GET /fhir/r4/AuditEvent retrieval ([audit.store], [audit.fhir_feed]),
  the FHIR terminology client ([terminology.external]), the change-event
  outbox and its AMQP publisher ([events]), and the Simplified Formats. The
  fhir cargo feature stays and now covers the audit rendering and the
  terminology client only; it no longer pulls in events.

Fixed

• An AQL query over EHR_ACCESS and a CONTRIBUTION that deletes a version
  are classified like the object path (#3667). The query records the
  category none, as an EHR_ACCESS read does, and the contribution records
  the categories of the newest version with content before the delete, as a
  single logical delete does.
• The viewer names every deployment gap in plain words (#3670), including
  audit_fails_open, open_ehr_access_default, auth_off,
  plaintext_listener and audit_syslog_udp, instead of showing the raw code.
• The FHIR AuditEvent of an AQL query carries the origins of the data it
  served (#3654), one entity per origin with the capped-count marker, as a
  document read does.
• The test harness no longer connects a database socket to itself
  (#3630). On macOS localhost resolves to ::1 first while the test
  container publishes its port on IPv4 only, and a port in the ephemeral range
  could occasionally connect to itself (a TCP simultaneous open), which surfaced
  as an internal database error in a test. testkit now uses the host's IPv4
  address.
• CI and the test harnesses no longer send usage reports (#3623). The
  compose smoke test, the viewer login smoke, the deploy probes, the Helm
  probe, the browser end-to-end runs and the conformance runs switch the
  report off, so throwaway instances on GitHub-hosted runners stop appearing in
  FerroPULSE. A CI check fails any new test launcher that leaves it on.
• Every access record carries its request id (#3665). The audit
  trail's request_id column was empty on every record, because the id was
  read from the response before the request-id layer copied it there; it is
  now read from the request and equals the x-request-id the client received.
• FERROEHR__AUDIT__PURPOSE_CODES is read as a comma-separated list
  (#3624). The environment form was refused as a string, so the purpose codes
  could only be set in the TOML file.
• The served OpenAPI document uses the released operationIds with a dot
  (#3679): the ADL 1.4 template operations (definition_template_adl1.4_*) and
  the stored-query store operations (definition_query_store.yaml,
  definition_query_version_store.yaml) were served in an underscore form
  that did not match the id in the access record.

Support period

Cadasto B.V. handles vulnerabilities in this release until the end of October 2031 (Regulation (EU) 2024/2847 Art 13(8) and (19)). The security update for a release in its support period ships in the newest release; see SECURITY.md.

Information and instructions to the user (CRA Annex II)

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