DocumentationSupportCosta Rica · Contact
ESENPT
Let’s talk
  • Technical
  • Legal

IHE ATNAAudit Trail and Node Authentication

In short

ATNA is an IHE profile that defines the basic security of any system exchanging health data: machines authenticate each other, communication is encrypted and every access to or transfer of data is recorded in an audit log. It makes it possible to document who viewed or sent a patient's information. Many other IHE profiles require or recommend it.

Type
Implementation guide
Steward
IHE International
Current version
ITI TF Rev. 20.2
Reviewed
October 25, 2026

Explanation

What it is

Audit Trail and Node Authentication (ATNA) is a profile in IHE's IT Infrastructure (ITI) Technical Framework. It specifies the foundational elements of a secure system: node authentication, user authentication, event logging (audit) and telecommunications encryption. As of October 2026, the current revision of the ITI Technical Framework is 20.2, from November 2025; the ATNA chapter keeps the revision 20.0 text. Many IHE profiles require or recommend grouping with ATNA; XDS.b, for example, requires it for all of its actors.

Actors and transactions

ActorRole
Secure NodeA system that controls its whole stack, from hardware to user interface, and applies security services to everything on it
Secure ApplicationAn application that applies those services to its own functions, without controlling the operating system or the rest of the device
Audit Record RepositoryReceives and stores audit records
Audit Record ForwarderForwards audit records to other repositories
  • Authenticate Node (ITI-19): both nodes authenticate each other with X.509 certificates over TLS before exchanging private information. The options with a TLS 1.0 floor were retired after RFC 8996 (March 2021); the current option sets TLS 1.2 as the minimum and follows BCP 195.
  • Record Audit Event (ITI-20): the event is sent with the syslog protocol (RFC 5424), over TLS (RFC 5425) or UDP (RFC 5426), and its content follows the DICOM audit message schema (PS3.15, Annex A.5), which IHE extends with security and privacy events.

The RESTful ATNA supplement adds recording and searching events as FHIR AuditEvent resources.

Why it matters legally

ATNA records document which system and which user accessed a patient's information, and when, with a standard format and transport. That is why they serve as evidence for accountability. Switzerland, for example, includes national extensions to ATNA in the technical rules of its electronic patient record.

Common misconceptions

  • ATNA does not define who may see what. Access control and consent are handled by other profiles and policies.
  • The profile does not specify how to analyse records or the repository's capacity: monitoring must be designed separately.
  • Complying with ATNA is not the same as complying with a data protection law. It is a technical tool that helps demonstrate compliance.
  • Node authentication depends on certificate management: an expired certificate or a weak TLS configuration undermines it.

Usage examples

  1. The IHE XDS.b profile requires all of its actors, from Document Source to Document Registry, to be grouped with an ATNA Secure Node or Secure Application.

  2. In Switzerland, Supplement 1 to Annex 5 of the EPDV-EDI ordinance (issue 8, in force since 1 June 2025) sets national extensions to ATNA for the electronic patient record.

  3. The Swiss CH EPR FHIR guide includes RESTful ATNA and the national Audit Trail Consumption profile (CH:ATC) for querying audit records.

  4. IHE's Basic Audit Log Patterns (BALP) profile, version 1.1.4, defines reusable FHIR AuditEvent patterns, focused on identifying the patient when they are the subject of the activity.

  5. The IHE IUA profile adds the "STX: HTTPS IUA" option to ATNA for connections authorized with OAuth tokens.

  6. An ultrasound machine, which IHE cites as an example of a Secure Node, records in the audit repository every study it sends to another system.

Relation to other terms

Relies on2

  • DICOMStrong

    Syslog audit messages use the DICOM audit message schema (PS3.15, Annex A.5); RESTful ATNA adds the FHIR AuditEvent resource as an alternative.

  • FHIRMedium

    Only when RESTful ATNA is used, which records and queries audit events as FHIR AuditEvent resources.

Depend on this one1

  • IHE XDS.bRequired

    Every XDS.b actor must be grouped with an ATNA Secure Node or Secure Application actor.

Sources

  1. IHE ITI Technical Framework (Revision 20.2)profiles.ihe.net
  2. IHE ITI Technical Framework Vol. 1 — Audit Trail and Node Authentication (ATNA)profiles.ihe.net
  3. IHE ITI TF Vol. 2 — Authenticate Node [ITI-19]profiles.ihe.net
  4. IHE ITI TF Vol. 2 — Record Audit Event [ITI-20]profiles.ihe.net
  5. IHE ITI Technical Framework Vol. 1 — XDS.b Required Actor Groupingsprofiles.ihe.net
  6. IHE — Basic Audit Log Patterns (BALP)profiles.ihe.net
  7. Fedlex — Ergänzung 1 zu Anhang 5 EPDV-EDI (Ausgabe 8, 2025)fedlex.admin.ch
  8. eHealth Suisse — CH EPR FHIR (R4)fhir.ch
Health interoperability glossary