Security, Audit & Compliance

ATNA is not just a generic security checklist. It is the IHE profile that tells architects how secure nodes should authenticate to each other and how security-relevant events should be audited across an interoperability domain.

ATNA answers whether trusted systems are talking over protected channels. It does not fully answer who the end user is, what app is acting on their behalf, or which authorization scopes should be enforced on a RESTful clinical API. That is where IUA and older SOAP-era XUA concepts matter.

View full size

Source: IHE IT Infrastructure Technical Framework, XUALast verified: 2026-03-11

This is the conceptual split beginners usually miss: ATNA secures systems and audit pipelines, while XUA or IUA carries the user or application identity context that the receiving service needs for authorization decisions. Without that split, teams often overestimate what transport security alone actually proves.

The subtle part of audit design is not simply generating more logs. It is deciding what must be preserved for accountability while avoiding unnecessary duplication of sensitive result sets. For document queries, the most valuable evidence is usually who queried, what they queried for, the outcome, and the system path used.

That is why audit pipelines commonly capture actor identity, network source, timestamp, transaction name, and query parameters, then correlate those events to registry or repository systems rather than copying full results into the audit sink.

Healthcare integrations often depend on organization certificates, private trust anchors, or regional PKI artifacts such as NASH in Australia. Those credentials should be retrieved at runtime from a managed secrets boundary, not embedded into source code or manual deployment bundles.