DocumentaçãoSuporteCosta Rica · Contato
ESENPT
Fale conosco
  • Técnica
  • Legal

IHE ATNAAudit Trail and Node Authentication

Em poucas palavras

O ATNA é um perfil da IHE que define a segurança básica de qualquer sistema que troca dados de saúde: que os equipamentos se autentiquem entre si, que a comunicação seja criptografada e que cada acesso ou envio de dados fique registrado em uma trilha de auditoria. Permite documentar quem viu ou enviou as informações de um paciente. Muitos outros perfis da IHE o exigem ou recomendam.

Tipo
Guia de implementação
Responsável
IHE International
Versão vigente
ITI TF Rev. 20.2
Revisado
25 de outubro de 2026

Explicação

O que é

O Audit Trail and Node Authentication (ATNA) é um perfil do framework técnico de Infraestrutura de TI (ITI) da IHE. Ele especifica os elementos básicos de um sistema seguro: autenticação de nós, autenticação de usuários, registro de eventos (auditoria) e criptografia das comunicações. Em outubro de 2026, a revisão vigente do framework técnico ITI é a 20.2, de novembro de 2025; o capítulo do ATNA mantém o texto da revisão 20.0. Muitos perfis da IHE exigem ou recomendam o agrupamento com o ATNA; o XDS.b, por exemplo, o exige de todos os seus atores.

Atores e transações

AtorFunção
Secure NodeSistema que controla toda a sua pilha, do hardware à interface, e aplica os serviços de segurança a tudo o que contém
Secure ApplicationAplicativo que aplica esses serviços às suas próprias funções, sem controlar o sistema operacional nem o resto do equipamento
Audit Record RepositoryRecebe e guarda os registros de auditoria
Audit Record ForwarderReencaminha registros de auditoria a outros repositórios
  • Authenticate Node (ITI-19): os dois nós se autenticam mutuamente com certificados X.509 sobre TLS antes de trocar informações privadas. As opções com piso em TLS 1.0 foram retiradas após o RFC 8996 (março de 2021); a opção vigente fixa o TLS 1.2 como mínimo e segue o BCP 195.
  • Record Audit Event (ITI-20): o evento é enviado com o protocolo syslog (RFC 5424), sobre TLS (RFC 5425) ou UDP (RFC 5426), e seu conteúdo segue o esquema de mensagens de auditoria do DICOM (PS3.15, anexo A.5), que a IHE estende com eventos de segurança e privacidade.

O suplemento RESTful ATNA acrescenta o registro e a busca de eventos como recursos AuditEvent do FHIR.

Os registros do ATNA documentam qual sistema e qual usuário acessaram as informações de um paciente, e quando, com um formato e um transporte padrão. Por isso servem como evidência para a prestação de contas. A Suíça, por exemplo, inclui adaptações nacionais do ATNA nas normas técnicas do seu prontuário eletrônico do paciente.

Equívocos comuns

  • O ATNA não define quem pode ver o quê. O controle de acesso e o consentimento são resolvidos com outros perfis e políticas.
  • O perfil não especifica como analisar os registros nem a capacidade do repositório: o monitoramento precisa ser projetado à parte.
  • Cumprir o ATNA não equivale a cumprir uma lei de proteção de dados. É uma ferramenta técnica que ajuda a demonstrar o cumprimento.
  • A autenticação de nós depende da gestão de certificados: um certificado vencido ou uma configuração TLS fraca a comprometem.

Exemplos de uso

  1. O perfil XDS.b da IHE exige que todos os seus atores, do Document Source ao Document Registry, sejam agrupados com um Secure Node ou uma Secure Application do ATNA.

  2. Na Suíça, o suplemento 1 do anexo 5 da portaria EPDV-EDI (edição 8, em vigor desde 1º de junho de 2025) define adaptações nacionais do ATNA para o prontuário eletrônico do paciente.

  3. O guia suíço CH EPR FHIR inclui o RESTful ATNA e o perfil nacional Audit Trail Consumption (CH:ATC) para consultar os registros de auditoria.

  4. O perfil Basic Audit Log Patterns (BALP) da IHE, versão 1.1.4, define padrões reutilizáveis de AuditEvent do FHIR, com foco em identificar o paciente quando ele é o sujeito da atividade.

  5. O perfil IUA da IHE acrescenta ao ATNA a opção «STX: HTTPS IUA» para conexões autorizadas com tokens OAuth.

  6. Um equipamento de ultrassom, que a IHE cita como exemplo de Secure Node, registra no repositório de auditoria cada estudo que envia a outro sistema.

Relação com outros termos

Apoia-se em2

  • DICOMForte

    As mensagens de auditoria por syslog usam o esquema de mensagem de auditoria do DICOM (PS3.15, anexo A.5); o RESTful ATNA acrescenta como alternativa o recurso AuditEvent do FHIR.

  • FHIRMédia

    Só quando se usa o RESTful ATNA, que registra e consulta eventos de auditoria como recursos AuditEvent do FHIR.

Dependem deste1

  • IHE XDS.bObrigatória

    Todos os atores do XDS.b devem ser agrupados com um ator Secure Node ou Secure Application do ATNA.

Fontes

  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
Glossário de interoperabilidade em saúde