FerroHEALTH documentation

Revised 2026-10-08.

This book holds what is true for every FerroHEALTH product: who makes them, how a vulnerability or a complaint reaches the manufacturer, what the manufacturer does under the Cyber Resilience Act (CRA) and the European Health Data Space Regulation (EHDS), the licence terms, and how the products fit together. Cadasto B.V. is the manufacturer of every product in the family and publishes this book.

Each product documents itself in its own book. A product’s book keeps what is about that product (its installation, its configuration, its API, its risk assessment) and links this book for the rest, so the family-level text exists once.

The products

Four more are planned. Each has a repository that holds its licence and its brand, and none has a release or a book yet:

The family site, https://ferrohealth.eu/, shows what each product has released and when its code last moved.

What is in this book

• The manufacturer: Cadasto B.V., its address and its single point of contact.
• Security: how to report a vulnerability, coordinated disclosure, security advisories, the support period and how you hear of an update.
• Post-market: complaints, serious incidents, corrective action and withdrawal, cooperation with the authorities, and what happens if the manufacturer ceases operations.
• The Cyber Resilience Act: the manufacturer’s side of the CRA, the conformity route of each product and the questions for counsel.
• The EHDS EHR system: the intended purpose and the shared responsibility of the EHR system that FerroEHR and FerroBRIDGE form together.
• Licensing and trademarks: the Business Source License 1.1 terms every product carries, commercial licences, the brand terms and the terms for contributions.
• How the products fit together: which product calls which, and running them side by side.
• Revisions: the dated record of every change to these pages.

Which revision a release relies on

Every page carries the date it was last revised, and the revisions page lists each change with its date. A product release that relies on a page here names it with that date, for example “the FerroHEALTH security policy, revised 2026-10-08”. The text of every revision stays in the history of the FerroHEALTH repository.

What belongs here

A page belongs in this book when it is about the family or about Cadasto B.V. as manufacturer, and its text holds for every product it names. A fact about one product belongs in that product’s book, and this book links it. A new product links these pages from its own book and its repository; it does not copy them.

Note

These pages are not legal advice. They say what Cadasto B.V. does as manufacturer and Licensor, and they do not say that a product or a deployment meets any regulation.

The manufacturer

Revised 2026-10-08.

Cadasto B.V. is the manufacturer of every FerroHEALTH product and the Licensor named in each product’s LICENSE. This page gives its details and says what being the manufacturer covers.

Warning

The quotations are from the Official Journal texts at EUR-Lex: the CRA, Regulation (EU) 2024/2847, and the EHDS, Regulation (EU) 2025/327. The exact texts these pages were checked against are vendored in the FerroEHR repository under docs/law/eu/, each with its provenance and digest.

Contact details

EHDS Art. 30(1)(g) has the manufacturer of an EHR system “indicate the name, registered trade name or registered trade mark, the postal address, and the website, email address or other digital contact details through which they can be contacted”, with “a single point at which the manufacturer can be contacted”. CRA Art. 13(17) asks a manufacturer for “a single point of contact to enable users to communicate directly and rapidly with them”. The address above is that point for every product: a complaint, an incident report, a vulnerability report by email, a licensing question and a request from an authority all go there.

What the manufacturer is

CRA Art. 3(13) defines the manufacturer as “a natural or legal person who develops or manufactures products with digital elements or has products with digital elements designed, developed or manufactured, and markets them under its name or trademark, whether for payment, monetisation or free of charge”.

Cadasto B.V. places each tagged release of each product on the market. A release is one product with digital elements: the source archive and the binaries, images and charts that the product’s release lane publishes for that tag. What a release contains is product-specific, so each product lists it:

An organisation that runs a release for itself puts that product into service. It does not become the manufacturer by doing so. Whether an organisation that modifies the source and runs the result becomes one is among the questions for counsel.

Who handles what

Where a product names its manufacturer

EHDS Art. 30(1)(g) asks for the details “in the EHR system”, so a product that Cadasto B.V. declares as an EHR system shows them when it runs. FerroEHR prints them on its startup banner and in ferroehr --version, and serves them on GET /management/info. FerroFED names them on GET {base}/, OPTIONS {base}/, its startup banner and ferrofed --version. Each product’s book says where else it shows them.

Certification

Cadasto B.V. holds ISO 9001, ISO/IEC 27001 and NEN 7510 certification for its management system. A certificate covers the organisation within its certified scope. It never makes a product certified, and no page in this book or in a product’s book calls a product certified. Whether the certified scope covers the development and release of the FerroHEALTH products, and a service Cadasto B.V. hosts for others, is an open point.

Security

Revised 2026-10-08.

This page is the vulnerability-handling policy of Cadasto B.V., the manufacturer of every FerroHEALTH product: how to report a vulnerability, what happens after you do, how a fix and its advisory reach you, how long a release is supported, and what the manufacturer reports to the authorities. Each product’s SECURITY.md keeps what is particular to it: the artefacts it publishes, its scope notes and the release-by-release support table. Where a product applies the policy differently today, the table below says so.

Warning

The quotations are from the Official Journal text of the CRA, Regulation (EU) 2024/2847, at EUR-Lex. The exact text these pages were checked against is vendored in the FerroEHR repository at docs/law/eu/cra/text.html.

Reporting a vulnerability

Do not open a public issue for a suspected vulnerability. Report it privately through GitHub private vulnerability reporting on the product’s repository:

• FerroCHART: https://github.com/FerroHEALTH/FerroCHART/security/advisories/new
• FerroEHR: https://github.com/FerroHEALTH/FerroEHR/security/advisories/new
• FerroTERM: https://github.com/FerroHEALTH/FerroTERM/security/advisories/new
• FerroBRIDGE: https://github.com/FerroHEALTH/FerroBRIDGE/security/advisories/new
• FerroFED: https://github.com/FerroHEALTH/FerroFED/security/advisories/new

The form is “Report a vulnerability” on the repository’s Security tab, and it needs a GitHub account. Without one, email info@cadasto.com, the manufacturer’s single point of contact, with the product’s name and “vulnerability” in the subject, for example “FerroEHR vulnerability”. CRA Art. 13(17) has the single point of contact “not limit such means to automated tools”. The address has no published encryption key, so send what you are comfortable sending by email and say that more is available; a channel for the rest is agreed with you.

Include what you can: the product and the version, tag or commit; what an attacker can do; steps to reproduce or a proof of concept; and any fix you suggest. Never include patient data. Describe the case, or build a synthetic one. Never test against a live clinical deployment you do not own.

If you have seen the vulnerability exploited, say so in the report. Your report is one way the manufacturer becomes aware of an actively exploited vulnerability, and that starts the 24-hour clock below.

What happens next

• Acknowledgement and assessment. The maintainer acknowledges the report and assesses its severity, then states an intended fix window. The times each product commits to are in the table below. If you hear nothing within that time, the report has not reached us: try the other route, or open a public issue saying only that a private report awaits acknowledgement, with no details.
• Coordinated disclosure. A disclosure date is agreed with you, and you are told when the fix ships. If the manufacturer misses its commitments, publishing is your call.
• Credit. The advisory credits the reporter with the name and link they give, if they want credit; say in the report whether you do. Declining credit changes nothing about how the report is handled.

Safe harbour

FerroEHR’s policy carries this safe harbour. Cadasto B.V. will not pursue or support legal action against anyone who reports a vulnerability in good faith and follows this policy: you tested against your own deployment or a test instance you control, you did not access, modify or retain data belonging to anyone else, you did not degrade service for others, and you gave the manufacturer the response times above before publishing. If you are unsure whether something is in scope, ask first; a question is always in good faith.

How a fix reaches you

A fix ships forward, in a new release. A published release is immutable: its assets and its tag cannot be changed. There are no maintenance branches and no backports in any product, so the security update for a release ships in the newest release, and the action for you is to upgrade. Old releases stay downloadable as an archive, and an older release does not receive the fix.

CRA Art. 13(10) allows this where a manufacturer has placed successive substantially modified versions of a software product on the market: it may meet the requirement to remediate vulnerabilities (Annex I Part II(2)) “only for the version that it has last placed on the market, provided that the users of the versions that were previously placed on the market have access to the version last placed on the market free of charge and do not incur additional costs to adjust the hardware and software environment in which they use the original version of that product”. Every release of a product is published under the same licence terms as the one before it, so a user with the right to run one release has the same right to run the newest. Whether this holds for every commercial licence is a question for counsel; a commercial licensee for whom it does not hold raises it with Cadasto B.V. at info@cadasto.com.

A security fix comes alone where it can. CRA Annex I Part II(2) asks that “where technically feasible, new security updates shall be provided separately from functionality updates”. A security fix ships in a security-only patch release: the next patch on the current line, carrying the fix and nothing that adds or changes functionality. A release may carry a security fix with functional changes only when a recorded reason makes the separate release technically infeasible, and that reason is written in the release’s notes under its ### Security heading.

Updates stay available. Each security update stays available for at least ten years after it is issued, or for the rest of the support period if that is longer (CRA Art. 13(9)). Releases are never deleted.

Security advisories

Every fixed vulnerability gets a GitHub security advisory on the product’s repository, published with the release that fixes it (CRA Annex I Part II(4)). That covers a vulnerability in the product’s own code, and a fix to a dependency or a base image that changes what a shipped artefact contains or how it behaves. Where a product publishes VEX statements (FerroEHR does, under security/vex/), a dependency finding that a statement shows does not affect the artefact gets no advisory, and the statement is its record. Each advisory carries:

• a description of the vulnerability and its impact;
• its severity, as a CVSS vector and score;
• the affected and fixed versions of each artefact concerned;
• what to do: the release to upgrade to, and any mitigation that works before you can upgrade;
• the CVE identifier when one is assigned, and credit to the reporter unless they declined it.

The product’s changelog entry for the fix carries the advisory’s GHSA- identifier, and the release notes repeat it.

When the details may wait

Annex I Part II(4) allows that “in duly justified cases, where manufacturers consider the security risks of publication to outweigh the security benefits, they may delay making public information regarding a fixed vulnerability until after users have been given the possibility to apply the relevant patch”. Cadasto B.V. uses it only when all three of these hold, and records the reason in the draft advisory:

1. the vulnerability can be exploited without credentials, or by any authenticated caller, against a deployment that has not yet upgraded;
2. no mitigation short of upgrading is available;
3. the details are not already public, and the vulnerability is not actively exploited. An actively exploited vulnerability is told to users at once, under CRA Art. 14(8).

Even then the advisory is published with the fixing release, naming the affected versions, the severity and the release to upgrade to. Only the technical description and any reproduction wait, and they are added no later than 30 days after the fixing release, or as soon as they become public elsewhere. The 30-day ceiling is an open point that Cadasto B.V. still has to confirm.

The support period

CRA Art. 13(8) has the manufacturer handle a product’s vulnerabilities for a support period that “shall be at least five years”, unless the product is expected to be in use for less time, and Art. 13(19) has its end date, “including at least the month and the year”, stated to the user. These articles bind the releases placed on the market from 11 December 2027 (CRA Art. 71(2) and 69(2)). Each product states its support period in its own SECURITY.md, because the line of releases and their end dates are its own. Where products differ today, the table below says how.

A release withdrawn because it did not conform is unsupported, and the product’s SECURITY.md lists it with the release to move to (withdrawing a release).

Hearing of an update

To hear of new releases and fixes for a product, subscribe to its release feed and read its published advisories. For a product <Product>:

• the release feed, https://github.com/FerroHEALTH/<Product>/releases.atom;
• the advisories, GET https://api.github.com/repos/FerroHEALTH/<Product>/security-advisories, machine-readable through the GitHub REST API. An advisory that names a published crate also reaches the GitHub Advisory Database in OSV format.

Cadasto B.V. also writes directly to the users it knows from a contract when a vulnerability or an incident needs action from them (CRA Art. 14(8)).

What Cadasto B.V. reports to the authorities

CRA Art. 14 has the manufacturer notify “any actively exploited vulnerability contained in the product with digital elements that it becomes aware of” (Art. 14(1)) and “any severe incident having an impact on the security of the product with digital elements” (Art. 14(3)). An actively exploited vulnerability is one “for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner” (Art. 3(42)). The duty applies from 11 September 2026 (Art. 71(2)), and Art. 69(3) reaches the products “placed on the market before 11 December 2027”, so it covers every release of every product.

The notification goes through ENISA’s single reporting platform to the CSIRT designated as coordinator in the Netherlands, where Cadasto B.V. has its main establishment, and is visible to ENISA at the same time (Art. 14(7)). It comes in three steps, each counted from the moment the manufacturer becomes aware:

Users are told of the vulnerability or incident, and of what they can do about it, through a GitHub security advisory on the product’s repository and the release notes of the fixing release (Art. 14(8)). Coordinated disclosure with the reporter continues alongside the notification. The steps the manufacturer follows, and how a CRA notification relates to an EHDS serious-incident report and to a hospital’s own NIS2 notification, are on the post-market page.

Vulnerabilities in a component a product integrates

A vulnerability the manufacturer finds, or is told of, in a component a product integrates (a Rust crate, a base image, a vendored asset) is reported to that component’s maintainer through its own channel, and a fix written for it is offered upstream (CRA Art. 13(6)). A vulnerability you find yourself in such a component goes to its maintainer; tell the manufacturer as well if it reaches a FerroHEALTH product. The procedure is on the post-market page.

How each product applies it today

The products adopted this policy at different times, and their SECURITY.md files still differ on these points. Each product’s own file is the statement for that product until it links this page in place of its own text.

The email address info@cadasto.com reaches the manufacturer of every product, whichever routes a product’s file names. The duties of CRA Art. 13 and Annex I, the support period among them, bind the releases placed on the market from 11 December 2027; the reporting of Art. 14 binds every release now.

Post-market

Revised 2026-10-08.

This page is the post-market procedure Cadasto B.V. runs as manufacturer of every FerroHEALTH product: how to complain or report an incident, how a report is classified, what happens when a released version turns out not to conform, the reports to the authorities, and what happens if the manufacturer ceases operations. The duties come from two regulations: Regulation (EU) 2025/327 on the European Health Data Space (the EHDS), Articles 30, 43, 44 and 45, and Regulation (EU) 2024/2847, the Cyber Resilience Act (the CRA), Articles 13 and 14. The steps that carry them out are the manufacturer’s own design.

Each product keeps its own registers and the steps bound to its own repository (its tracker, its release lane, its withdrawal tooling), and its book lists what counts as a possible serious incident for that product.

Warning

The quotations are from the Official Journal texts at EUR-Lex: the EHDS, the CRA, the NIS2 Directive, Regulation (EU) 2019/1020 and Commission Delegated Regulation (EU) 2026/881. The exact texts these pages were checked against are vendored in the FerroEHR repository under docs/law/eu/. This page is not legal advice, and it says nothing about whether a product or a deployment meets either regulation. It says what the manufacturer does.

Which products the duties reach

The CRA reaches every product: each tagged release is a product with digital elements that Cadasto B.V. places on the market. The EHDS duties on this page bind the manufacturer of an EHR system. Cadasto B.V. declares two:

• the EHR system that FerroEHR and FerroBRIDGE form together (intended purpose);
• FerroFED, which Cadasto B.V. classifies as an EHR system of its own (FerroFED’s regulatory status).

This book records no EHDS classification for FerroTERM or FerroCHART.

When the duties apply

The procedure runs now for all of them, so that it is practised before the EHDS and the rest of the CRA apply.

Who does what

Making a complaint or a report

EHDS Art. 30(1)(n) asks the manufacturer to “establish channels of complaint and keep distributors informed thereof”. Pick the channel by what the report contains, and put the product’s name in the subject:

Say which product and which version you run, and how it is deployed, and describe what happened. Never send patient data: describe the case, or build a synthetic one. A product may offer a command that writes a report of the deployment for this purpose; its book says which.

An emailed vulnerability report runs through the same procedure as a private GitHub report. Its arrival is the moment the manufacturer becomes aware for CRA Art. 14, so whoever reads info@cadasto.com forwards a message about a vulnerability or an exploit to the maintainer at once and writes down the hour it arrived.

How a report is classified

The person who reported is answered through the channel they used.

The registers

EHDS Art. 30(1)(o) asks the manufacturer to “keep a register of complaints and a register of non-conforming EHR systems and keep distributors informed thereof”. CRA Art. 13(6) adds the record of vulnerabilities reported upstream. The registers are kept per product, public, in the product’s repository, appended and never rewritten:

A complaint gets its row within one working day of receipt, whatever the channel. No row names the person who complained or carries patient data, and the upstream register names components, never people. A vulnerability enters the registers when its advisory is published, so a row never discloses one before its fix; until then the draft advisory is the record.

Corrective action, withdrawal and recall

When the manufacturer considers, or has reason to believe, that released versions “are not or are no longer in conformity with the essential requirements laid down in Annex II”, it takes “without undue delay any necessary corrective action”, or recalls or withdraws them (EHDS Art. 30(1)(i)). CRA Art. 13(21) asks for the same “immediately” where a product or the manufacturer’s processes do not conform with the CRA’s Annex I.

A withdrawal is any measure that prevents a product in the supply chain from being made available; a recall is any measure that achieves the return of a product already made available to the end user (Regulation (EU) 2019/1020 Art. 3(22) and (23), which EHDS Art. 2(1)(d) and CRA Art. 3(49) and (50) adopt). The steps:

1. The finding enters the product’s register of non-conforming versions.
2. The fix ships in a new patch release. A published release is immutable, so a non-conforming version is never changed or deleted.
3. The manufacturer decides between correction, withdrawal and recall, and writes the decision and its timetable into the register. A withdrawal moves the product’s floating image tags (<major>.<minor> and latest) to the correcting release and lists the version as unsupported in the product’s SECURITY.md. The version’s own tag and image digests stay published, so a deployment pinned to them keeps running the withdrawn version until it moves. A recall adds a direct message to every known user to replace the version. FerroEHR and FerroFED each carry scripts/release/withdraw.sh for the steps bound to their own repository.
4. The national authorities of each Member State where the version was made available or put into service are told of the non-conformity, of the corrective action “including the timetable for implementation”, and of the date the version was “brought into conformity or been recalled or withdrawn” (EHDS Art. 30(1)(i)).
5. Distributors, the authorised representative, importers and users are told of “the non-conformity and of any corrective action, recall or withdrawal” (EHDS Art. 30(1)(j)): through a security advisory or an announcement, the release notes of the correcting version, and directly where the manufacturer knows them.

The same routes carry any “mandatory preventive maintenance of the EHR systems and its frequency” (EHDS Art. 30(1)(k)).

Serious incidents (EHDS Art. 44)

EHDS Art. 2(2)(r) defines a serious incident as “any malfunction or deterioration in the characteristics or performance of an EHR system made available on the market that directly or indirectly leads, might have led or might lead to any of the following: (i) the death of a natural person or serious harm to a natural person’s health; (ii) serious prejudice to a natural person’s rights; (iii) serious disruption of the management and operation of critical infrastructure in the health sector”. Each EHR system’s book lists the events its manufacturer treats as possible serious incidents: FerroEHR’s and FerroFED’s.

EHDS Art. 44(7) sets the report:

• To whom: “the market surveillance authorities of the Member States where such serious incident occurred and of the Member States where such EHR systems are placed on the market or put into service”. Each Member State designates its authority, and “The Commission and the Member States shall make that information publicly available” (Art. 43(2)).
• What: the incident, including “a description of the corrective action taken or envisaged by the manufacturer”.
• When: “immediately after the manufacturer has established a causal link between the EHR system and the serious incident or the reasonable likelihood of such a link and, in any event, not later than three days after the manufacturer becomes aware of the serious incident involving the EHR system”. The three days run from awareness, so the report goes in on time while the cause is still being established, and is completed later.

The steps:

1. Day 0, on awareness. The date and hour are written down, and the complaint and non-conformity rows are entered. The deployment is asked how it is deployed and what happened.
2. The same day. The manufacturer checks whether the event is also a CRA Art. 14 matter. If it is, that clock runs as well; neither report replaces the other.
3. By day 3 at the latest. Cadasto B.V. reports to the authorities above: what happened, the versions involved, the causal link as far as it is established, and the corrective action taken or envisaged.
4. Harm. Where an authority finds that an EHR system “has caused harm to the health or safety of natural persons”, the manufacturer “shall immediately provide information and documentation” to the affected person or user (Art. 44(3)).
5. Corrective action continues as above for every copy placed on the market in the Union (Art. 44(4)).

Where a serious incident concerns personal data protection, the market surveillance authority informs the data protection supervisory authorities (Art. 44(6)); a deployment’s own duties under the GDPR remain its own.

Actively exploited vulnerabilities and severe incidents (CRA Art. 14)

The manufacturer becomes aware through a private vulnerability report, an emailed one, a CSIRT telling it of someone else’s notification (CRA Art. 15(4)), or its own finding. The deadlines and the content of each step are on the security page. The steps:

1. Hour 0. The date and hour are written down. Cadasto B.V. decides, on the evidence, whether the vulnerability is actively exploited or the incident severe. CRA Art. 14(5) calls an incident severe when it affects or can affect the ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or when it has led or can lead to malicious code.
2. Within 24 hours: the early warning, through ENISA’s single reporting platform to the CSIRT designated as coordinator in the Netherlands.
3. Within 72 hours: the notification, saying how sensitive Cadasto B.V. considers the information. Where a fix is expected within 72 hours, the notification says so: that is a condition under which the receiving CSIRT may delay passing it on (Commission Delegated Regulation (EU) 2026/881 Art. 3(a), adopted for the delay CRA Art. 16(2) allows).
4. Users are told through a GitHub security advisory on the product’s repository and the release notes of the fixing release, with the mitigations users can apply before they upgrade (Art. 14(8)).
5. On request, an intermediate report to the CSIRT (Art. 14(6)).
6. The final report: for a vulnerability, no later than 14 days after a corrective or mitigating measure is available; for an incident, within one month after the notification.

An event can be an EHDS serious incident and a CRA notification at once. Each report is then made, each on its own clock.

NIS2

EHDS Art. 44(7) makes the serious-incident report “without prejudice to incident notification requirements under Directive (EU) 2022/2555”, the NIS2 Directive. NIS2 Art. 23 has each Member State require essential and important entities to notify significant incidents to their CSIRT or competent authority, and healthcare providers are a sector in its Annex I. A hospital running a FerroHEALTH product may owe that notification under its own national law. The manufacturer’s EHDS report and CRA notification do not stand in for it, and the hospital’s notification does not stand in for them. The manufacturer gives the hospital the facts it needs: the advisory, the affected versions, the mitigations and the timeline it reported.

Security advisories

CRA Annex I Part II(4) has the manufacturer, “once a security update has been made available, share and publicly disclose information about fixed vulnerabilities”. Every fixed vulnerability gets a GitHub security advisory on the product’s repository, published with the fixing release. What an advisory carries, and when its technical details may wait, is on the security page.

Vulnerabilities in integrated components

When the manufacturer identifies a vulnerability “in a component, including in an open source-component, which is integrated in the product”, it shall “report the vulnerability to the person or entity manufacturing or maintaining the component”, and share any fix it wrote (CRA Art. 13(6)).

• Who reports: the maintainer, on behalf of Cadasto B.V.
• When: as soon as the vulnerability is confirmed in the component, whether the product’s own work found it (a fuzz crash, a review, a test) or a reporter told the manufacturer of it. A component vulnerability that a scanner reports from a published advisory is already known upstream and needs no report.
• Through which channel: the component’s own security policy first. For a Rust crate, its SECURITY.md or private vulnerability reporting on its repository, then a RustSec advisory once it can be public; for a base-image package, the project’s security contact or the distribution’s security tracker; for a vendored asset, its publisher’s contact.
• The fix: a patch the manufacturer wrote is offered upstream, under the component’s licence.
• The product’s own side: the vulnerability is handled like any other: a draft advisory, a security-only release when the product is affected, or a VEX statement when it is not.
• The record: a row in the product’s upstream register once the upstream advisory is public, naming the component and never a person.

A request from an authority

On request, the manufacturer gives a market surveillance authority “all the information and documentation necessary to demonstrate the conformity” of the product, in an official language of the Member State concerned (EHDS Art. 30(1)(l)), “in paper or electronic form” and “in a language which can be easily understood by that market surveillance authority” (EHDS Art. 30(5); CRA Art. 13(22)), and cooperates on any action to bring the product into conformity or to eliminate its risks (EHDS Art. 30(1)(m), Art. 44(1)). A request goes to the single point of contact, info@cadasto.com. An authority may restrict, recall or withdraw an EHR system whose manufacturer does not cooperate or whose information “is incomplete or incorrect” (EHDS Art. 43(5)).

If the manufacturer ceases operations

CRA Art. 13(23): “A manufacturer that ceases its operations and, as a result, is not able to comply with this Regulation shall inform, before the cessation of operations takes effect, the relevant market surveillance authorities as well as, by any means available and to the extent possible, the users of the relevant products with digital elements placed on the market, of the impending cessation of operations.”

If that happens, Cadasto B.V. will:

1. Decide and date it. The board of Cadasto B.V. decides that it will cease operations, or that a product will no longer be maintained, and the date it takes effect. The steps below run as soon as that date is set, so every notice goes out before it.
2. Tell the authorities first: the market surveillance authority of each Member State where a product is made available, and, while the EHDS applies, of each Member State where an EHR system is put into service. The notice names the products, the date, the date from which vulnerabilities are no longer handled, and what stays published.
3. Tell the known users: a direct message to every operator and every commercial licensee it knows of.
4. Tell the public: a pinned issue on each product’s repository, a notice at the top of each product’s SECURITY.md, on its documentation site and in this book, and a final security advisory naming the last supported release. The notice says that the support periods end early, on the cessation date.
5. Leave everything published. Every release, image, chart, crate, advisory, register and page stays where it is. Releases are immutable, and nothing is withdrawn because the manufacturer stops.
6. Close the registers: every open row gets its outcome as it stands.

Under the licence published with each version, a version becomes licensed under the Apache License 2.0 four years after its publication (licensing). The licence text ties that change to the version’s publication date and sets no condition on the Licensor continuing to exist. A commercial licence is governed by its own contract.

Open points

Nothing in the products’ repositories answers these. Cadasto B.V. supplies them:

1. The CSIRT designated as coordinator for the Netherlands under CRA Art. 14(7), and Cadasto B.V.’s account on ENISA’s single reporting platform (Art. 16(1)).
2. Who at Cadasto B.V. decides that a vulnerability is actively exploited or an incident severe, and signs the CRA notification and the EHDS serious-incident report; and who stands in when that person is away, since the clock runs in hours.
3. The market surveillance authority of each Member State where a product is placed on the market or put into service, with its contact for a serious-incident report.
4. Whether Cadasto B.V. is itself an essential or important entity under NIS2 in the Netherlands, in particular once it hosts a product as a service for other organisations.
5. The list of distributors, importers and known users to whom the EHDS Art. 30(1)(j) and (n) notices go, which is the register of economic operators of EHDS Art. 35.
6. Whether info@cadasto.com should publish an encryption key for vulnerability reports, and who reads that inbox and forwards a report the same day, including outside working hours.
7. The 30-day ceiling on delaying an advisory’s technical details, which the security page states, needs Cadasto B.V.’s confirmation.
8. Who on the board of Cadasto B.V. decides a cessation of operations, and whether a successor would take over the support periods.
9. Whether the certified scope of Cadasto B.V.’s ISO 9001, ISO/IEC 27001 and NEN 7510 certificates covers the development and release of the products, these procedures, and a service Cadasto B.V. hosts for other organisations.

The Cyber Resilience Act

Revised 2026-10-08.

The Cyber Resilience Act (CRA, Regulation (EU) 2024/2847) sets cybersecurity requirements for “a software or hardware product and its remote data processing solutions” (CRA Art. 3(1)) made available on the EU market, and duties for the manufacturer that places it there. This page is the manufacturer’s side, which is the same for every FerroHEALTH product: who the manufacturer is, which duties apply from when, how conformity is assessed for each product, and which questions are open. Each product keeps its own risk assessment and its own Annex II information in its own book.

Warning

The quotations are from the Official Journal text of the CRA at EUR-Lex. The amendments that Article 104 of the EHDS, Regulation (EU) 2025/327, makes to the CRA are read from that Regulation, and the product categories from Implementing Regulation (EU) 2025/2392. The exact texts these pages were checked against are vendored in the FerroEHR repository under docs/law/eu/. No conformity assessment has been carried out for any product, no EU declaration of conformity exists and no product carries the CE marking. This page is the manufacturer’s reading, not legal advice.

The manufacturer and the products

Cadasto B.V. is the manufacturer of each tagged release of every FerroHEALTH product in the sense of CRA Art. 3(13) (the manufacturer). Each tagged release is one product with digital elements. Its single point of contact (CRA Art. 13(17)) is info@cadasto.com, beside GitHub private vulnerability reporting on each product’s repository (security).

A library a product publishes on its own, such as the openehr-* crates FerroEHR publishes on crates.io, is a product of its own. Its owning product’s book says what the CRA asks of it.

Not free and open-source software

CRA Art. 3(48) defines free and open-source software as software “made available under a free and open-source licence which provides for all rights to make it freely accessible, usable, modifiable and redistributable”. Every FerroHEALTH product is published under the Business Source License 1.1, whose Additional Use Grant allows production use for non-commercial purposes only; any other production use needs a commercial licence from Cadasto B.V. (licensing). The licence does not provide for all of those rights, so no product is free and open-source software under the CRA. The provisions written for such software do not apply: the open-source software steward regime of CRA Art. 24, and the option of CRA Art. 32(5) to use the internal control procedure for an important product whose technical documentation is public.

Each version becomes available under the Apache License 2.0 four years after its publication (the Change Date). The position above is about each release as Cadasto B.V. places it on the market. A library a product publishes under Apache-2.0 is free and open-source software, and its owning product’s book treats it separately.

What applies, and from when

Each product ships new releases often, and each tagged release is placed on the market when it is published, so the releases published from 11 December 2027 are the ones the full Regulation measures.

Reporting, the support period and vulnerability handling

• Reporting (Art. 14). Cadasto B.V. notifies an actively exploited vulnerability or a severe incident to the CSIRT designated as coordinator in the Netherlands and to ENISA, through the single reporting platform: an early warning within 24 hours, a notification within 72 hours, and a final report. The steps are on the security and post-market pages.
• The support period (Art. 13(8)). “the support period shall be at least five years”, and “Where the product with digital elements is expected to be in use for less than five years, the support period shall correspond to the expected use time”. The end date, month and year, is stated to the user (Art. 13(19)). Each product states its own period and the end date of each release (security).
• Vulnerability handling (Annex I Part II). Fixes ship forward in the newest release, as Art. 13(10) allows, security fixes ship separately from functionality where technically feasible, and every fixed vulnerability gets an advisory (security).
• Software bill of materials (Annex I Part II(1)). Each product’s release lane attaches SBOMs and signed provenance to its releases; each product’s SECURITY.md lists them and says how to verify a release.

The information that accompanies each release

CRA Art. 13(18) has each product “accompanied by the information and instructions to the user set out in Annex II”. Three of its points are the same for every product, and this book is their source:

The other points are product-specific, and each product answers them in its own book. FerroEHR’s are on its CRA information and instructions to the user page.

How conformity is assessed, product by product

Cadasto B.V. declares two EHR systems under the EHDS: FerroEHR with FerroBRIDGE, and FerroFED. EHDS Article 104 amends the CRA for that case:

• The procedure. CRA Art. 32(5a), inserted by EHDS Art. 104(3): “Manufacturers of products with digital elements that are classified as EHR systems under Regulation (EU) 2025/327 […] shall demonstrate conformity with the essential requirements set out in Annex I to this Regulation using the relevant conformity assessment procedure provided for in Chapter III of Regulation (EU) 2025/327.”
• One set of technical documentation. CRA Art. 31(3), as EHDS Art. 104(2) replaces it: “a single set of technical documentation shall be drawn up containing the information referred to in Annex VII and the information required by those Union legal acts”.
• One risk assessment. CRA Art. 13(4), as EHDS Art. 104(1) replaces it: for such a product, “the cybersecurity risk assessment may be part of the risk assessment required by those Union legal acts”.
• One declaration. CRA Art. 28(3): “Where a product with digital elements is subject to more than one Union legal act requiring an EU declaration of conformity, a single EU declaration of conformity shall be drawn up”.

The EU declaration of conformity

CRA Art. 28 has the manufacturer draw up an EU declaration of conformity, Art. 13(20) has it accompany the product or be available at an address the user information states (Annex II point 6), and Art. 28(3) makes one declaration cover every Union act that applies. None has been drawn up for any product. The obligation applies from 11 December 2027. Recording the conformity route of each product and drawing up the declaration is tracked in FerroEHR#3696; when a declaration exists, it is published with each release it covers, and this page gives its address.

Default product, or important product

CRA Art. 7(1): products “which have the core functionality of a product category set out in Annex III shall be considered to be important products with digital elements”, and “The integration of a product with digital elements which has the core functionality of a product category set out in Annex III shall not in itself render the product in which it is integrated subject to the conformity assessment procedures referred to in Article 32(2) and (3)”. Implementing Regulation (EU) 2025/2392 gives each category’s technical description. For an important product of class I whose manufacturer has not applied harmonised standards, common specifications or a certification scheme in full, CRA Art. 32(2) requires a third-party procedure (module B with C, or module H). Each product’s book states its reading of its own core functionality; FerroEHR’s is on its CRA page.

A deployment Cadasto B.V. hosts as a service

Cadasto B.V. may host a product as a service for another organisation. The CRA reaches “remote data processing solutions”, which recital 11 describes as “data processing at a distance for which the software is designed and developed by or on behalf of the manufacturer […], the absence of which would prevent the product with digital elements from performing one of its functions”. Recital 12 adds that “Directive (EU) 2022/2555 applies to cloud computing services and cloud service models, such as Software as a Service (SaaS)”, and that cloud solutions are remote data processing solutions “only if they meet the definition laid down in this Regulation”. For EHR systems, EHDS recital 112 states that “EHR systems offered through the SaaS licensing and delivery model do not fall within the scope of that Regulation”, the CRA, and that “EHR systems that are developed and used in-house do not fall within the scope of that Regulation, as they are not placed on the market”. FerroFED’s book reads its hosted deployments that way. A recital is not an operative article, and EHDS Art. 26(2) still counts an EHR system offered as a service as put into service. Whether a hosted deployment of a self-hostable product is inside the CRA’s product scope, and whether Cadasto B.V. is then an essential or important entity under NIS2, are questions for counsel.

In a hosted deployment Cadasto B.V. also operates the instance and is the customer’s processor under a GDPR Art. 28 contract (shared responsibility).

Who the CRA binds in a self-hosted deployment

The manufacturer’s duties are Cadasto B.V.’s. An organisation that runs an unmodified release for itself is a user of the product and not its manufacturer. CRA Art. 22(1) makes a person “that carries out a substantial modification of a product with digital elements and makes that product available on the market” a manufacturer; whether an organisation that modifies the source and only runs the result for itself is reached is a question for counsel, as is the corresponding EHDS question.

Questions for counsel

1. Whether each product is an important product under Annex III and Implementing Regulation (EU) 2025/2392, and whether CRA Art. 32(5a) changes the procedure for the products declared as EHR systems.
2. Whether CRA Art. 13(10) holds for commercial licensees under BUSL-1.1, and whether security updates are free of charge for every commercial licence (Annex I Part II(8)), tracked for FerroEHR in FerroEHR#3647.
3. Whether a deployment that modifies the source and puts the result into service becomes a manufacturer itself (CRA Art. 21 and 22, EHDS Art. 34).
4. Whether a deployment Cadasto B.V. hosts as a service is remote data processing outside the CRA’s product scope, and whether Cadasto B.V. is then an essential or important entity under NIS2.
5. Whether user information in English alone meets the CRA Art. 13(18) duty (“a language which can be easily understood by users and market surveillance authorities”) in each Member State where a product is made available, or which Member States require a translation.

The EHDS EHR system: intended purpose

Revised 2026-10-08.

This page is the statement by Cadasto B.V., the manufacturer, of the use it intends the EHR system that FerroEHR and FerroBRIDGE form together for: what the system is for, who uses it, which data it is designed to process, how it is operated, and what the intended purpose excludes. Each product’s book carries its own part of the statement: its essential functions, the data it holds, the environment it relies on, and the use and misuse that can be foreseen for it.

Two regulations measure the system against this statement. The Cyber Resilience Act (CRA, Regulation (EU) 2024/2847) defines the intended purpose as “the use for which a product with digital elements is intended by the manufacturer, including the specific context and conditions of use, as specified in the information supplied by the manufacturer in the instructions for use, promotional or sales materials and statements, as well as in the technical documentation” (CRA Art. 3(23)), and asks for it “including the security environment provided by the manufacturer” in the information that accompanies the product (Annex II point 4). The EHDS (Regulation (EU) 2025/327) asks for “its intended purpose, and the date and version of the EHR system” in the technical documentation (Annex III 1(a)) and on the information sheet (Art. 38(2)(c)), and forbids advertising that suggests uses “other than those stated to form part of the intended purpose in the technical documentation” (Art. 28(c)).

Warning

The quotations are from the Official Journal texts at EUR-Lex: the CRA, the EHDS and the MDR, Regulation (EU) 2017/745. The exact texts these pages were checked against are vendored in the FerroEHR repository under docs/law/eu/. This page says what the manufacturer intends. It does not say that the system, or a deployment of it, meets either regulation: no conformity assessment has been carried out and no EU declaration of conformity exists.

The statement, its version and its scope

A change to the intended purpose is a new revision of this page, and the release notes of the release that relies on it name its date. Under the CRA, a change that “results in a modification to the intended purpose for which the product with digital elements has been assessed” is a substantial modification (CRA Art. 3(30)), so each product’s risk assessment is revised with it.

FerroFED is an EHR system of its own, with its own statement on its regulatory status page. This page does not cover it.

What the EHR system is for

The EHR system stores, versions and queries the structured health records of one healthcare provider, serves them to the software that provider’s health professionals and patients use, and exchanges them in the European electronic health record exchange format. It has no clinical user interface of its own: health professionals reach it through the clinical applications the provider connects to it.

EHDS Art. 2(2)(k) defines an EHR system as “any system whereby the software, or a combination of the hardware and the software of that system, allows personal electronic health data that belong to the priority categories of personal electronic health data established under this Regulation to be stored, intermediated, exported, imported, converted, edited or viewed, and intended by the manufacturer to be used by healthcare providers when providing patient care or by patients when accessing their electronic health data”. EHDS Art. 25(1) asks an EHR system to include both harmonised software components, and the two products carry one each:

The EHDS defines each component as independent of the other. FerroEHR and FerroBRIDGE are separate products that meet only over the openEHR REST API. FerroEHR documents the logging component’s requirements and the system-level ones of Annex II point 1; FerroBRIDGE documents the interoperability component’s.

Who uses it

The data the EHR system is designed to process

EHDS Annex III 1(b) and Art. 38(2)(d) ask for “the categories of personal electronic health data that the EHR system has been designed to process”. The system is designed for the priority categories of EHDS Art. 14(1): “(a) patient summaries; (b) electronic prescriptions; (c) electronic dispensations; (d) medical imaging studies and related imaging reports; (e) medical test results, including laboratory and other diagnostic results and related reports; and (f) discharge reports”, and any category a Member State adds in national law. Which of them a deployment holds depends on the templates it loads, and the deployment declares that. Beside the clinical content, the system holds the identities of the record subjects, the link between the two, and the access log.

Each product’s book lists the data it holds, domain by domain: FerroEHR’s.

How the EHR system is operated

The system runs in one of two ways:

• Self-hosted. The deploying organisation installs and runs it, or has a processor of its own choosing do so. Cadasto B.V. is the manufacturer only and has no access to the deployment or its data.
• Hosted by Cadasto B.V. Cadasto B.V. may run the system as a service for an organisation. It is then also the operator, and that organisation’s processor under a contract that GDPR Art. 28(3) requires. An EHR system offered as a service to a person established in the Union “shall be considered as having been put into service” (EHDS Art. 26(2)).

In both cases each organisation gets its own instance of each product. The environment each product relies on and does not provide itself, such as TLS termination, an identity provider and database protection, is stated in that product’s book (CRA Annex II point 4): FerroEHR’s security environment.

What the intended purpose excludes

• Medical device purposes. Cadasto B.V. does not intend the EHR system for any of the “specific medical purposes” in the MDR’s definition of a medical device (MDR Art. 2(1)): “diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease”, and the others that article lists. The system stores, returns and converts records; it computes no diagnosis, score, alert or treatment advice.
• Several organisations in one deployment. One deployment serves one healthcare provider.

Each product’s book lists the exclusions particular to it, and the use and misuse that can be foreseen for it.

Where this statement is used

• Each product’s CRA risk assessment analyses its risks “based on the intended purpose and reasonably foreseeable use” (CRA Art. 13(3)): FerroEHR’s.
• The hazard log of the logging component assesses patient safety “during normal conditions of use” (EHDS Annex II 1.1): FerroEHR’s hazard log.
• The claims review checks every public text against it (EHDS Art. 28(c)): FerroEHR’s.
• The technical documentation maps EHDS Annex III 1(a) onto it, and the information sheet of EHDS Art. 38 repeats it: FerroEHR’s technical documentation and information sheet.

FerroBRIDGE’s book carries none of these pages yet.

The EHDS EHR system: shared responsibility

Revised 2026-10-08.

Almost every obligation in EU and national health-data law rests on the controller, and where the EHR system is operated on that controller’s behalf, on the processor. Software supplies technical measures. It cannot hold a legal basis, sign a processing agreement, notify a supervisory authority or run a management system.

This page draws that line obligation by obligation for the EHR system that FerroEHR and FerroBRIDGE form together, so you can see which part of the work the software has done and which part stays with you. No openEHR specification governs any of it; the division follows the legal texts each row links.

Warning

Each row links the publisher’s text of the provision it cites. The exact EU and national texts these tables were checked against are vendored in the FerroEHR repository under docs/law/, each at a named consolidation with its digest and licence. This page is not legal advice, and it does not tell you whether your deployment satisfies any obligation.

How to read the tables

Each row names one obligation and links its official source. The middle column is what the software provides, linked to the page of FerroEHR’s book that documents it, or to the open issue when the control is planned rather than shipped. FerroEHR is the store and the logging component of the system, so most measures are FerroEHR’s; a row names FerroBRIDGE where the measure is FerroBRIDGE’s, and FerroBRIDGE’s book documents none of its side yet. The right column is the work that stays with the deploying organisation.

“Nothing” in the middle column is a real answer and appears wherever it is the true one. The live status of every control FerroEHR declares is on its control matrix, generated from its tracker.

When Cadasto B.V. is also your processor

Cadasto B.V. is the manufacturer of each FerroEHR and FerroBRIDGE release. Whether it is also your processor depends on who runs the deployment:

• Self-hosted. You run the deployment, or a processor of your choosing runs it for you. Cadasto B.V. supplies the software and processes no personal data on your behalf, so it is not your processor (GDPR Art. 4(8) defines a processor as one “which processes personal data on behalf of the controller”).
• Hosted by Cadasto B.V. Cadasto B.V. runs the deployment as a service for you. It is then also your processor, and Art. 28(3) has that processing “governed by a contract or other legal act” binding it with regard to you.

Where a row says “the processor”, it means whoever runs the deployment for you. What a product sends out on its own by default is stated in its book: FerroEHR’s is its usage report, which Cadasto B.V. receives as controller for its own purposes.

GDPR

Every row below cites Regulation (EU) 2016/679. The duties in it belong to the controller and the processor. The middle column is only the technical measure FerroEHR supplies toward one of them.

EHDS

Regulation (EU) 2025/327 is in force, and its operative obligations apply from the dates its own final provisions carry. No row below claims conformity with any of them.

CRA

Regulation (EU) 2024/2847 puts its duties on the manufacturer of a product with digital elements, which for each release of each FerroHEALTH product is Cadasto B.V. The Cyber Resilience Act page states the position.

National law

The sections above apply to every EU deployment. This one is a single country’s law on top of them, three countries so far: the division a deployment reads is “the EU layer, plus my own jurisdiction”. The compliance overview says what adding another takes (National law).

The Netherlands

The Netherlands: NEN

The NEN 7510 family is where the split is sharpest. A management-system standard cannot be met by a product at all.

Germany

Switzerland

Switzerland is not an EU member state: the GDPR rows above do not apply to a Swiss deployment, and the DSG takes their place.

What this page does not do

It does not tell you whether your deployment satisfies any of these obligations. That depends on your legal basis, your organisation, your infrastructure and your operating practice, none of which a supplier can see.

The companion guidance is in FerroEHR’s book: the DPIA page, the records of processing, the go-live checklist, the compliance overview with the legal sources, and the threat model with the risk that survives each control.

How the products fit together

Revised 2026-10-08.

Each FerroHEALTH product runs on its own, and each speaks a published specification to the others. This page shows which product calls which, and what running them side by side involves. Each product’s own book carries its configuration and its pinned specification versions.

The diagram is one file, shared with the family site and drawn by a generator in the FerroHEALTH repository. Select it to open it at full size.

Reading the diagram

The frame is one FerroHEALTH instance serving one organisation. The nine inside are the family; clinicians, applications, HL7 FHIR, the OMOP database and other organisations sit outside it. A dashed outline is a planned product, and a dashed line is a call into one.

Left to right is the order data moves. Four servers are the data path: FerroCHART takes the record down, FerroEHR keeps it, FerroTERM gives its codes meaning, and FerroBRIDGE carries it out. FerroPIX, FerroSMART, FerroFED, FerroSYS and FerroTASK frame that path. An arrowhead points at what is called or written to, and each edge names the specification it speaks.

Which product calls which

The planned products add these calls once they exist:

• FerroSMART is the SMART on openEHR authorisation server. FerroCHART obtains its token and launch context there (OIDC, SMART launch), and FerroEHR asks it whether a token may do what it asks (token introspection). FerroEHR carries the SMART on openEHR layer itself today.
• FerroPIX is the Master Patient Index. FerroEHR feeds it each EHR it creates (the IHE PIXm Patient Identity Feed), and FerroFED asks it where a patient’s records are (PIXm) before it dispatches a query.
• FerroTASK reads FerroEHR over the openEHR REST API and AQL for task plans and GDL2 guidelines, and commits the state of each plan back.
• FerroSYS is the control plane. Every server reports health, telemetry and events to it and is configured from it, so it is drawn as a band under everything.

Every call in the table speaks a published specification, so any product can be swapped for another implementation of the same standard: FerroTERM for any FHIR terminology server, FerroEHR for any openEHR CDR, and so on.

Running them side by side

No product needs another to start. A deployment runs the ones it needs, each as its own process or container, and points each caller at the others through its configuration:

Three rules hold across the family:

• One instance per organisation. FerroEHR is single-tenant: several organisations are served by several instances, each with its own database. The diagram’s frame is one such instance.
• The record lives in the CDR. FerroEHR holds the record. FerroBRIDGE’s FHIR facade stores nothing, and its OMOP load writes into a database outside it. FerroFED holds no clinical data of its own: it passes each node’s answer through.
• The products meet over published specifications. Every edge in the diagram is one. FerroEHR and FerroBRIDGE meet only over the openEHR REST API, which is what lets them form one EHR system under the EHDS while staying independent of each other (intended purpose).

Licensing and trademarks

Revised 2026-10-08.

Every FerroHEALTH product is source-available under the Business Source License 1.1 (SPDX BUSL-1.1), with Cadasto B.V. as the Licensor. This page states the terms every product shares, how to arrange a commercial licence, the terms of the FerroHEALTH names and artwork, and the terms under which contributions are accepted. It is a summary for evaluators and deployers, not legal advice.

Each product’s LICENSE is the authority

The Business Source License 1.1 is a template: its parameters (the Licensor, the Licensed Work, the Additional Use Grant, the Change Date) are filled in by each product. Each product’s own LICENSE is the text that applies to it:

The Business Source License 1.1 is not an OSI-approved open-source licence, and no product claims that it is. A product may publish some of its parts under another licence, such as the Apache-2.0 openehr-* model crates of FerroEHR; its own book says which parts and why.

Do you need a commercial licence?

The same boundary holds for every product, in the order people ask about it:

The last two rows hold whatever else you are: they need a commercial licence even for an organisation the rows above would otherwise leave free.

What counts as a hosted service

The Additional Use Grant excludes offering a product “to third parties as a hosted, managed, or embedded service”. Each product’s LICENSE says what such a service is for that product, meaning a service through which anyone other than you and your affiliates:

The planned products’ licences are in their repositories, linked above.

The Change Date

Each version of each product becomes available under the Apache License 2.0, its Change License, four years after that version is published. The licence ties the change to the version’s publication date and to nothing else.

Arranging a commercial licence

A commercial licence is arranged with Cadasto B.V., the Licensor, which handles the business side of every product: write to info@cadasto.com or use https://www.cadasto.com/contact/. Companies and care providers building on a FerroHEALTH product are welcome, and the commercial licence is the normal path for them. Technical questions go to the maintainer, Ruben Talstra (@rubentalstra on GitHub), through the product’s repository. How a commercial licence is installed in a running product is in that product’s book; FerroEHR’s is in its licensing page.

Trademarks and brand terms

The names FerroHEALTH, FerroCHART, FerroEHR, FerroTERM, FerroBRIDGE, FerroPIX, FerroSMART, FerroFED, FerroSYS and FerroTASK, the FerroHEALTH mark with its icon and lockup variants, and the architecture diagram are covered by the FerroHEALTH brand terms, TRADEMARKS.md. The artwork is copyright Cadasto B.V., all rights reserved, and is not licensed under Apache-2.0 or any other open licence. The Apache License 2.0 grants no right to the names or the marks either (its section 6).

What you may do. Use the names, and the marks and the diagram unmodified, to refer to the projects: in an article, a talk, a slide or a review; to link to a project or show which of them you build on, deploy or integrate with; and to show how the projects fit together. You may scale a mark or the diagram, and convert it to another file format, provided the result looks the same.

What needs permission from Cadasto B.V.:

• a modified mark: recoloured, reordered, redrawn, combined with another mark, or with its wordmark set in another typeface;
• a name or a mark in the name or the logo of your own product, service, company, domain or social account;
• a use that suggests Cadasto B.V. endorses, sponsors or maintains your work when it does not;
• merchandise.

A fork of a product may say that it is derived from that product. It does not carry the product’s name or mark as its own. Ask at info@cadasto.com or https://www.cadasto.com/contact/.

Each product’s own mark is in its repository under that repository’s terms.

Other organisations’ marks. openEHR® is a registered trademark of the openEHR Foundation. HL7® and FHIR® are registered trademarks of Health Level Seven International. SNOMED CT® is a registered trademark of SNOMED International. None of these organisations endorse FerroHEALTH.

Contributions

The five released products accept contributions on the same terms. By submitting a contribution to one of them you:

1. certify that you wrote it, or otherwise have the right to submit it under these terms;
2. license it under the licence of the files it changes: for the product’s own code, the Business Source License 1.1 as applied to the version it lands in, including that version’s Change License, so it becomes Apache 2.0 with the rest of that version. A product that publishes some parts under another licence names them in its CONTRIBUTING.md; and
3. grant the Licensor named in LICENSE, Cadasto B.V., a perpetual, irrevocable, worldwide, royalty-free, transferable right to use, reproduce, modify, distribute, sublicense and relicense the contribution as part of the Licensed Work under any terms, including commercial licences.

You keep your copyright. Point 3 is what lets each product stay one work with one licensor: a commercial licence, a change of the licence parameters, or a transfer of the project can then cover every line, not only the maintainer’s own. There is no separate agreement to sign: each repository’s pull request template carries a checkbox recording your acceptance of these terms, and a pull request from a person does not merge without it (the contribution-licence-guard check).

This site and its documentation, including this book, are Apache-2.0 (LICENSE), and contributions to them follow the same three points with Apache-2.0 in point 2 (CONTRIBUTING.md).

Revisions

Revised 2026-10-08.

Every change to a page of this book is a revision, dated on the page itself and listed here, newest first. A product release that relies on a page names the page and the date of its revision, for example “the FerroHEALTH security policy, revised 2026-10-08”, and the text of that revision stays in the history of this book. A correction of a typing error that changes no statement needs no revision.

scripts/checks/book-revisions.sh holds the two in step: every page carries a revision date, and the newest row here for each page carries the same date.