Information sheet

Regulation (EU) 2025/327 on the European Health Data Space (the EHDS Regulation) has every EHR system “accompanied by an information sheet that includes concise, complete, correct and clear information that is relevant, accessible and comprehensible to professional users” (Art 38(1)), free of charge for the user (Art 30(1)(d)). This page is that sheet for FerroFED. Each section answers one point of Art 38(2). The instructions for use are the other document Art 30(1)(d) asks for.

Art 38(3) lets a manufacturer enter the same information into the EU database of Art 49 in place of supplying the sheet. The data that database holds is set by a delegated act under Art 49(4) that is not adopted, so the sheet is supplied here. Every quotation is from the Official Journal text, vendored at docs/specs/eu-ehds/reg-eu-2025-327-en.xhtml.

(a) The manufacturer

Art 38(2)(a): “the identity, registered trade name or registered trademark, and contact details of the manufacturer and, where applicable, of its authorised representative”.

The running gateway names the same details in GET {base}/, OPTIONS {base}/, its startup banner and ferrofed --version (Complaints and incidents).

(b) Name, version and date of release

Art 38(2)(b): “the name and version of the EHR system and date of its release”.

The EHR system is FerroFED. This sheet describes FerroFED 0.0.9, released on 2026-10-05. It ships as these forms:

• the gateway image ghcr.io/ferrohealth/ferrofed, for Linux on x86_64 and aarch64;
• the gateway binary ferrofed, for Linux on x86_64 and aarch64, on glibc and on musl;
• the operator console image ghcr.io/ferrohealth/ferrofed-viewer;
• the source code, under the Business Source License 1.1 (Licensing).

Each release lists its changes in the changelog, and ferrofed --version prints the version a binary is. The book on the main branch also documents changes merged since the release above; the changelog’s [Unreleased] section lists them, and the next release carries them. From FerroFED 0.0.10 on, the sheet of a release is this page at that release’s tag.

(c) Intended purpose

Art 38(2)(c): “the intended purpose of the EHR system”.

FerroFED is a federation gateway intended by its manufacturer to be used by healthcare providers when providing patient care. A clinician’s application sends it an ordinary AQL query about a patient. FerroFED resolves the patient to a record at each openEHR clinical data repository (CDR) of a federation, asks each CDR for its part of the answer, and returns one answer that names the CDR each row came from. It routes the follow-up reads and writes of that answer to the CDR that holds the record. It holds no clinical data of its own.

The users are healthcare providers and their health professionals, through the client applications they use in patient care, and the operator who configures a deployment. FerroFED offers patients no access service of its own. The full statement, and the classification as an EHR system under Art 2(2)(k), are on Regulatory status.

(d) The categories of data

Art 38(2)(d): “the categories of electronic health data that the EHR system has been designed to process”.

FerroFED selects no data by category: a query reaches whatever the member CDRs hold. It is designed to intermediate personal electronic health data of all six priority categories of Art 14(1):

The codes are those of HL7 Europe’s EEHRxFDocumentPriorityCategoryCS (hl7.fhir.eu.health-data-api 1.0.0-ballot), and the record writes each with that system. The categories a deployment declares under national law are recorded as well, each in the system its Member State defines (Categories).

(e) Standards, formats and specifications

Art 38(2)(e): “the standards, formats and specifications supported by the EHR system and versions of those standards, formats and specifications”.

scripts/checks/versions.sh holds every row of this table to the pin matrix, docs/VERSIONS.md, so a version that moves there fails CI until this sheet moves with it. Each Item names its row in the matrix exactly.

Beside them:

• IHE XCPD (ITI-55), IHE ITI Technical Framework Volume 2 Revision 20.1, for localizing an undirected query.
• FHIR R4 (4.0.1), the version every IHE and Dutch profile above is written for.
• OAuth 2.0 and its extensions, by RFC: 6749, 7523 (client assertions), 7662 (introspection), 8414 (server metadata), 8693 (token exchange), 8705 (mutual TLS), 9068 (access tokens), 9396 (authorization details) and 9449 (DPoP); and the OpenID FAPI 2.0 Security Profile, Final, for the FAPI 2.0 grant of the Dutch binding.
• SMART on openEHR, the scope grammar of ITS-REST 1.1.0, for the scopes each route requires.

The European electronic health record exchange format of Art 15 is not supported by this release. Its implementing act is not adopted, the interoperability component that will produce the format is a library the gateway does not serve, and no receive path exists (Regulatory status). The instructions for use list this and the other limitations.

Support period

Art 38(2) asks for no support period. Regulation (EU) 2024/2847, the Cyber Resilience Act, does, and it reaches every FerroFED release as a product Cadasto B.V. places on the market (Regulatory status). Its Art 13(19) has “the end date of the support period …, including at least the month and the year”, specified “at the time of purchase”, and its Annex II, point 7, puts “the end-date of the support period” in the information to the user.

The manufacturer gives every release placed on the market from 11 December 2027 a support period of at least five years, the minimum of Art 13(8), with its end date published. SECURITY.md says which releases receive security fixes. Stating the support period and the end date of each release there, and on this sheet, is planned (#763).

Accessible formats

Recital 37 asks for the sheet and the instructions “including in accessible formats for persons with disabilities”. This sheet is HTML text with headings and tables with header rows; no information on it is carried by an image or by colour alone. Its source is plain Markdown in the repository, website/book/src/evaluate/information-sheet.md, which a screen reader or a braille display reads as text. The book’s print page renders every page as one document for printing or saving. Ask the single point of contact above for another format.

How the sheet is kept

Every release cut updates this sheet in its version-bump pull request (docs/release.md, Before the tag): the version, the date of release, the release table and the standards. scripts/checks/versions.sh fails while the product version or a pin here differs from the pin matrix, or while the date of release differs from the release’s heading in CHANGELOG.md.