1. Radiology Option for Audit Trail and Node Authentication Robert Horn
Agfa Healthcare

2. Working Together to Deliver Interoperable Health Information Systems
W W W . I H E . N E T
Providers and Vendors
Working Together to Deliver
Interoperable Health Information Systems
In the Enterprise
and Across Care Settings
June 28-29, 2005
Interoperability Strategy Workshop

3. IT Infrastructure Profiles
Audit Trail and Node Authentication (ATNA) –Centralized privacy audit trail and node to node authentication to create a secured domain
Consistent Time (CT) – Coordinate time across network systems
2004
Patient Identifier Cross-referencing for MPI (PIX)
Retrieve Information for Display (RID)
Consistent Time (CT)
Patient Synchronized Applications (PSA)
Enterprise User Authentication (EUA)
2005
Patient Demographic Query (PDQ)
Cross Enterprise Document Sharing (XDS)
Audit Trail and Note Authentication (ATNA)
Personnel White Pages (PWP)
2006
Cross-Enterprise User Authentication (XUA)
Document Digital Signature (DSG) –
Notification of Document Availability (NAV)
Patient Administration/Management (PAM)
June 28-29, 2005
Interoperability Strategy Workshop

4. Interoperability Strategy Workshop
Audit Trail and Node Authentication (ATNA) + Radiology Option Abstract / Scope
Defines basic security features for an individual system for use as part of the security and privacy environment for a healthcare enterprise.
Provides host level authentication, which is used in conjunction with the user authentication from EUA and XUA.
Provides audit trail mechanism for monitoring activities related to security and patient privacy
June 28-29, 2005
Interoperability Strategy Workshop

5. Interoperability Strategy Workshop
Audit Trail and Node Authentication (ATNA) + Radiology Option Compatibility with Basic Security
“But, what if I already have systems that support Basic Security?”
ATNA + Radiology Option is backward compatible with Basic Security
Integration Statements should change support claim from “Basic Security” to “Radiology Option for ATNA”
June 28-29, 2005
Interoperability Strategy Workshop

6. ATNA Value Proposition
Protect Patient Privacy and System Security:
Meet ethical and regulatory requirements
Enterprise Administrative Convenience:
Unified and uniform auditing system
Common approach from multiple vendors simplifies definition of enterprise policies and protocols.
Common approach simplifies administration
Development and support cost reduction through Code Re-use:
Allows vendors to leverage single development effort to support multiple actors
Allows a single development effort to support the needs of different security policies and regulatory environments.
June 28-29, 2005
Interoperability Strategy Workshop

7. ATNA vs Basic Security Value Proposition
Why Change?
Use an Audit Repository that supports more than just imaging domains like Radiology.
Use a reliable, error correcting, secure transport for audit messages
Is Change necessary?
For Secure Nodes (audit sources): NO, transition when it is convenient.
For Audit Repositories: YES, add the ability to accept audit messages from more than just radiology.
June 28-29, 2005
Interoperability Strategy Workshop

8. Interoperability Strategy Workshop
ATNA vs Basic Security
What else is different?
ATNA added the requirement to have configurable control over the use of TLS when on a physically secured network or when using a VPN.
Any configurable Secure Node for Radiology Basic Security is also a Secure Node for ATNA with no further modifications.
Basic Security Profile being deprecated by Radiology Option for ATNA
Implementers need to refer to ITI Technical Framework for ATNA definition and Radiology Framework for Radiology Option definition
June 28-29, 2005
Interoperability Strategy Workshop

9. ATNA Security Requirements
Reasons: Clinical Use and Privacy
authorized persons must have access to medical data of patients, and the information must not be disclosed otherwise.
Unauthorized persons should not be able to interfere with operations or modify data
By means of procedures and security mechanisms, guarantee:
Confidentiality
Integrity
Availability
Authenticity
June 28-29, 2005
Interoperability Strategy Workshop

10. ATNA Security Measures
Authentication: Establish the user and/or system identity, answers question: “Who are you?”
ATNA defines: How to authenticate network connections.
ATNA Supports: Authentication mechanisms, e.g. Enterprise User Authentication (EUA) or Cross Enterprise User Authentication (XUA)..
Authorization and Access control: Establish user’s ability to perform an action, e.g. access to data, answers question: “Now that I know who you are, what can you do?”
ATNA defines: How to authorize network connections.
ATNA requires: System internal mechanisms for both local and network access.
June 28-29, 2005
Interoperability Strategy Workshop

11. ATNA Security Measures
Accountability and Audit trail: Establish historical record of user’s or system actions over period of time, answers question: “What have you done?”
ATNA Defines: Audit message format and transport protocol
June 28-29, 2005
Interoperability Strategy Workshop

12. ATNA Integrating Trusted Nodes
Secured System
Secured System
Local access control (authentication of user)
Secure network
Strong authentication of remote node (digital certificates)
network traffic encryption is not required, it is optional
Audit trail with:
Real-time access
Time synchronization
Central
Audit Trail Repository
System A
System B
June 28-29, 2005
Interoperability Strategy Workshop

13. ATNA Suitable Network Environments
Physically secured networks
Explicit physical security preventing access by other nodes, or
VPN and VLAN technologies that provide equivalent network isolation.
Protected networks
Physical security that prevents modification or installation of unauthorized equipment
The network is shared with other authorized nodes within the enterprise that should not have unrestricted access to patient information.
Unprotected networks
Not generally supported, although nodes with sufficient node level security and using encryption may be safe.
June 28-29, 2005
Interoperability Strategy Workshop

14. Interoperability Strategy Workshop
ATNA Node Security
ATNA specifies some of the capabilities that are needed, e.g. access control.
ATNA does not specify policies
ATNA does not specify mechanisms, although other IHE protocols like EUA are obvious candidates.
This permits vendors and enterprises to select technologies and policies that are appropriate to their own purposes without conflicting with the ATNA profile.
June 28-29, 2005
Interoperability Strategy Workshop

15. ATNA Node Authentication
X.509 certificates for node identity and keys
TCP/IP Transport Layer Security Protocol (TLS) for node authentication, and optional encryption
Secure handshake protocol of both parties during Association establishment:
Identify encryption protocol
Exchange session keys
Actor must be able to configure certificate list of authorized nodes.
ATNA presently specifies mechanisms for HTTP, DICOM, and HL7
June 28-29, 2005
Interoperability Strategy Workshop

16. Interoperability Strategy Workshop
ATNA Auditing System
Designed for surveillance rather than forensic use.
Two audit message formats
IHE Radiology interim format, for backward compatibility with radiology
IETF/DICOM/HL7/ASTM format, for future growth
DICOM Supplement 95
IETF Draft for Common Audit Message
ASTM E.214
HL7 Audit Informative documents
Both formats are XML encoded messages, permitting extensions using XML standard extension mechanisms.
June 28-29, 2005
Interoperability Strategy Workshop

17. ATNA Record Audit Event
Reliable Syslog (RFC 3195) is the preferred transport for Audit Records, although BSD Syslog protocol (RFC 3164) is permitted for backward compatibility with Radiology Basic Security.
Audit trail events and content based on IETF, DICOM, HL7, and ASTM standards. Also, Radiology Basic Security audit event format is allowed for backward compatibility.
June 28-29, 2005
Interoperability Strategy Workshop

18. ATNA – Radiology Option Record Audit Event
Radiology Option for ATNA defines radiology specific trigger events (in two main categories)
Security Events:
For example: “The access permissions for Dr. Kildare were changed on the PACS” or “Node authentication between the CT scanner and the PACS failed”
Patient Privacy Events:
For example: “Dr. Welby looked at Mrs. Smith’s MR images and report on 6/29/05” or “Bob Jones’ Renal US study was exported to a CD on 6/30/05”.
June 28-29, 2005
Interoperability Strategy Workshop

19. What it takes to be a secure node
The entire host must be secured, not just individual actors.
The entire host must have appropriate user access controls for identification, authentication, and authorization.
All communications that convey protected information must be authenticated and protected from interception. This means every protocol, not just the IHE transactions.
All health information activities should generate audit trails, not just the IHE actors.
June 28-29, 2005
Interoperability Strategy Workshop

20. What it takes to be a secure node
The Secure node is more than add-on auditing capability. The complete work effort includes:
Deciding what events should be auditable
Instrumenting all applications to detect auditable events and generate audit messages.
Ensuring that all communications connections are protected.
Establishing a local security mechanism to protect all local resources.
Establishing configuration mechanisms for:
Time synchronization using Consistent Time (CT) profile
Certificate management
Network configuration
June 28-29, 2005
Interoperability Strategy Workshop

21. Interoperability Strategy Workshop
More information….
IHE Web sites:
Technical Frameworks, Supplements
ITI V1.0, RAD V6.0, LAB V1.0
Non-Technical Brochures :
Calls for Participation
IHE Fact Sheet and FAQ
IHE Integration Profiles: Guidelines for Buyers
IHE Connect-a-thon Results
Vendor Products Integration Statements
June 28-29, 2005
Interoperability Strategy Workshop