DocumentaciónSoporteCosta Rica · Contacto
ESENPT
Hablemos
  • Técnica
  • Legal

IHE ATNAAudit Trail and Node Authentication

En pocas palabras

ATNA es un perfil de IHE que define la seguridad básica de cualquier sistema que intercambia datos de salud: que los equipos se autentiquen entre sí, que la comunicación vaya cifrada y que cada acceso o envío de datos quede registrado en una bitácora de auditoría. Permite documentar quién vio o envió la información de un paciente. Muchos otros perfiles de IHE lo exigen o lo recomiendan.

Tipo
Guía de implementación
Responsable
IHE International
Versión vigente
ITI TF Rev. 20.2
Revisado
25 de octubre de 2026

Explicación

Qué es

Audit Trail and Node Authentication (ATNA) es un perfil del marco técnico de Infraestructura de TI (ITI) de IHE. Especifica los elementos básicos de un sistema seguro: autenticación de nodos, autenticación de usuarios, registro de eventos (auditoría) y cifrado de las comunicaciones. A octubre de 2026, la revisión vigente del marco técnico ITI es la 20.2, de noviembre de 2025; el capítulo de ATNA conserva el texto de la revisión 20.0. Muchos perfiles de IHE exigen o recomiendan agruparse con ATNA; XDS.b, por ejemplo, lo exige a todos sus actores.

Actores y transacciones

ActorFunción
Secure NodeSistema que controla toda su pila, del hardware a la interfaz, y aplica los servicios de seguridad a todo lo que contiene
Secure ApplicationAplicación que aplica esos servicios a sus propias funciones, sin controlar el sistema operativo ni el resto del equipo
Audit Record RepositoryRecibe y guarda los registros de auditoría
Audit Record ForwarderReenvía registros de auditoría a otros repositorios
  • Authenticate Node (ITI-19): los dos nodos se autentican mutuamente con certificados X.509 sobre TLS antes de intercambiar información privada. Las opciones con piso en TLS 1.0 fueron retiradas tras el RFC 8996 (marzo de 2021); la opción vigente fija TLS 1.2 como mínimo y sigue la guía BCP 195.
  • Record Audit Event (ITI-20): el evento se envía con el protocolo syslog (RFC 5424), sobre TLS (RFC 5425) o UDP (RFC 5426), y su contenido sigue el esquema de mensajes de auditoría de DICOM (PS3.15, anexo A.5), que IHE extiende con eventos de seguridad y privacidad.

El suplemento RESTful ATNA agrega el registro y la búsqueda de eventos como recursos AuditEvent de FHIR.

Los registros de ATNA documentan qué sistema y qué usuario accedieron a la información de un paciente, y cuándo, con un formato y un transporte estándar. Por eso sirven como evidencia para rendir cuentas. Suiza, por ejemplo, incluye adaptaciones nacionales de ATNA en las normas técnicas de su historia clínica electrónica del paciente.

Errores frecuentes

  • ATNA no define quién puede ver qué. El control de acceso y el consentimiento se resuelven con otros perfiles y políticas.
  • El perfil no especifica cómo analizar los registros ni la capacidad del repositorio: hay que diseñar el monitoreo aparte.
  • Cumplir ATNA no equivale a cumplir una ley de protección de datos. Es una herramienta técnica que ayuda a demostrar el cumplimiento.
  • La autenticación de nodos depende de la gestión de certificados: un certificado vencido o una configuración TLS débil la comprometen.

Ejemplos de uso

  1. El perfil XDS.b de IHE exige que todos sus actores, del Document Source al Document Registry, se agrupen con un Secure Node o una Secure Application de ATNA.

  2. En Suiza, el suplemento 1 del anexo 5 de la ordenanza EPDV-EDI (edición 8, vigente desde el 1 de junio de 2025) define adaptaciones nacionales de ATNA para la historia clínica electrónica del paciente.

  3. La guía suiza CH EPR FHIR incluye RESTful ATNA y el perfil nacional Audit Trail Consumption (CH:ATC) para consultar los registros de auditoría.

  4. El perfil Basic Audit Log Patterns (BALP) de IHE, versión 1.1.4, define patrones reutilizables de AuditEvent de FHIR, con foco en identificar al paciente cuando es el sujeto de la actividad.

  5. El perfil IUA de IHE agrega a ATNA la opción «STX: HTTPS IUA» para conexiones autorizadas con tokens de OAuth.

  6. Un equipo de ultrasonido, que IHE cita como ejemplo de Secure Node, registra en el repositorio de auditoría cada estudio que envía a otro sistema.

Relación con otros términos

Se apoya en2

  • DICOMFuerte

    Los mensajes de auditoría por syslog usan el esquema de mensaje de auditoría de DICOM (PS3.15, anexo A.5); RESTful ATNA agrega como alternativa el recurso AuditEvent de FHIR.

  • FHIRMediana

    Solo cuando se usa RESTful ATNA, que registra y consulta eventos de auditoría como recursos AuditEvent de FHIR.

Dependen de este1

  • IHE XDS.bObligatoria

    Todos los actores de XDS.b deben agruparse con un actor Secure Node o Secure Application de ATNA.

Fuentes

  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
Glosario de interoperabilidad en salud