The audit trail of the FerroHEALTH products: who looked at which patient's data, recorded the standard way.
Documentation · Quick start · What ships today · Licensing
Project
Quality and security
Conformance and compliance
Patients and regulators have a right to know who looked at a health record. Every access to patient data has to be written down, kept safely and handed to the people who check it. FerroAUDIT does that for every FerroHEALTH product, in the formats hospitals already use, so their audit systems can read the records without a custom connection.
It writes each access as a standard audit record (IHE ATNA, the profile hospitals use for audit trails), sends it to the hospital's audit repository, and keeps it in a local queue until the repository confirms it, so a record is never lost when the network is down. It also records what the European Health Data Space regulation asks of an electronic health record system: which categories of data were read, by whom, and how long the record is kept.
- Privacy officers and hospital IT, who receive the audit trail of every FerroHEALTH product in their existing audit repository.
- Developers of health software in Rust, who need ATNA and EHDS logging without writing it again.
Every release is signed and carries SLSA build provenance, so you can check
that the crate you use is the one built here. The source is public, and
every function is in this repository: there is no paid edition with extra
features. A record names a patient toward its repository and nowhere else,
and a record the queue cannot take is refused at once, so nothing is
dropped silently. The IHE and EU texts the crates implement are vendored at
the versions docs/VERSIONS.md pins, so you can check
each record against its standard.
FerroHEALTH is five servers, each its own product, that reach each other only over published standards: FerroEHR stores the record, FerroBRIDGE translates it to FHIR and the OMOP research model, FerroFED connects records across organisations and borders, FerroPIX matches patient identities, and FerroTERM serves the code systems (the shared lists of medical terms). Work that every server needs lives in three shared libraries: FerroAUTH for sign-in and access control, FerroAUDIT for the audit trail, and FerroUI for the web consoles. FerroEHR, FerroFED and FerroPIX send their audit records through FerroAUDIT, and each keeps its own audit store.
Add the crates to a Rust project:
cargo add ihe-atna@=0.3.3 --features balp
cargo add ehds-logging@=0.3.3 --features balpPin the versions exactly. The crate documentation on
docs.rs is the integration guide, and
docs/architecture.md has the design.
- ATNA audit messages (ITI-20): the DICOM audit message over syslog with TLS, to any Audit Record Repository
- BALP audit events: the FHIR
AuditEventfor every IHE FHIR transaction, posted over the FHIR feed - A store-and-forward queue that keeps every record until the repository takes it, oldest first
- Retrieving audit events (ITI-81): the FHIR search a product serves over its own audit store
- The EHDS access record, as Annex II 3.2 of Regulation (EU) 2025/327 asks, with its data categories and retention
Published crates (2)
| Crate | What it does | Version | Docs | Downloads |
|---|---|---|---|---|
ihe-atna |
The IHE audit trail: ATNA (ITI-20) over syslog and TLS, BALP AuditEvents over the FHIR feed, the spool and forwarder, and ITI-81 retrieval |  |
 |
 |
ehds-logging |
The EHDS logging component: the Annex II 3.2 access record, its categories and retention, written as a BALP AuditEvent |  |
 |
 |
ihe-atnaandehds-loggingon docs.rs, and the FerroHEALTH book- Architecture and the pinned specifications
- Changelog and milestones
- Security policy
- Contributing, code of conduct, support, governance and maintainers
Business Source License 1.1 (LICENSE), with Apache License 2.0 as the Change License four years after each version; the licensing page says when you need a commercial licence from Cadasto B.V.