Healthcare Exchange Standards: IHE - Privacy and Security Profiles

This is the prime security profile in the IHE toolbox. Prime in so many ways, but it wasn't the first. The Audit Trail and Node Authentication (ATNA) profile is composed of three things.

The first part of ATNA is not found in the name, that is that the profile expects that the system functionally includes reasonable access controls. Because this is a functional requirement, IHE doesn't further define it. This has more to do with the purpose of IHE than the need. The expectation is that product suppliers will do the right thing, and that operational environments will inspect their systems before they grant them network access. The other two parts of ATNA: Audit Controls and Network Controls will be further explained below.

The Actor/Transaction diagram looks complex, but it isn't as complex as it appears. The diagram includes the actors from the Consistent Time profile. The diagram complexity comes from the practical fact that our original Actors were more monolithic and reality is more plug-and-play. IHE had originally defined a Secure Node as complete hardware and software system that is considered in whole to be one, although it may be made up of multiple computers, but it is one distinguishable system.
Examples:

MRI – made up of many components and computers, may even be made up of discrete physical cabinets
EHR – whole system considered as one including all workstations and supporting servers
EKG device – single small medical device

The concept of a Secure Node is ultimately the configuration desired, but we had to recognize that software components and services are being developed and they need to be responsible for what they control. Thus IHE had to define Secure Application – a software component that is expected to be integrated into a larger system. Where this software component is responsible for securing any communications it is controlling, initiating, receiving; responsible for any controlling access that it is responsible for; and responsible for logging any security events that it is in control of. This means that a Secure Application is simply not responsible for something that is out of it’s control (for example: auditing of the system startup event, or user-login event) Example:

A network service, such as a eMPI, that requires to be integrated into a database farm
A software application that must be installed onto a workstation

The other Actor shown is the Audit Record Repository – Receives the Record Audit Event transaction. A system implementing this actor will typically process, report, record, alert, forward, and in any other way process the security events. More on this later.

Secure Nodes and Secure Applications are expected to use secure communications, specifically the "Authenticate Node" transaction. This transaction is not really a transaction but an augmentation of transaction in a way that both sides of the transaction can be assured of mutual-authentication, and that the communications between them are protected against risks to confidentiality and integrity. The easy part of this to understand is that the network communications is encrypted. The thing that I usually need to emphasize is that this communications is mutually-authenticated.

On the Internet we are getting use to using a web-browser to connect to a web-server, normally this has no security. For sensitive sites we are using HTTPS, which adds authentication of the server and encryption. This would mean that the browser user knows which server they are connecting to with high assurance (not as much trust as you would think). But the problem with this model is that the web-server has zero knowledge of the client. For healthcare we want to not only make sure we are connecting to the server we wanted to connect to, but the server wants to make sure it is only connecting with clients that it can trust. It is this client authentication that is special, and allows for a trusted network to develop.

The most simple protocols profiled in ATNA is Transport Layer Security (TLS). This is what is otherwise referred to as SSL. The difference is that TLS is defined in an IETF standard, where as SSL is defined by Netscape. Ultimately they are now the same, and advancements are being made to TLS. TLS has advantages that it is very easy to deploy, has built in protocol negotiations, built in certificate discovery, and is built into many toolkits and platforms.

Sometimes other configurations are called for, so IHE ATNA also recommends end-to-end security with Web-Services Security, and S/MIME for e-mail. In both of these cases the certificate discovery and management is not automated, thus they are more complex to deploy.

Audit logging is the final component of the ATNA profile. The idea of the Audit logging in ATNA is that ultimately the use of an audit log is a specialized functionality that needs to have all events that happened on all the various systems in the organization. This is a specialty that has been developing in the general IT market around Firewall, Intrusion Detection, Routers, Databases, and Operating system audit log analysis. Given that specialty exists, we felt it was better for healthcare specific products to simply note that a security relevant event happened and send the details off to an Audit Record Repository for this analysis. So we followed the general IT market architecture. Here is some history and the relationship of the standards:

ASTM E2147 – Setup the concept of audit logs for healthcare including accounting of disclosures
IETF RFC 3881 – Defined the Information Model (IETF rule forced this to be informative)
DICOM Supplement 95 – Made the information model Normative, defined Vocabulary, Transport Binding, and Schema
IHE ATNA – defines the grouping with secure transport and access controls; and defined specific audit log records for specific IHE transactions.
NIST SP800-92 – shows how to do audit log management and reporting – consistent with our model
HL7 PASS – Defined an Audit Service with responsibilities and a query interface for reporting use
ISO 27789 – is defining the subset of audit events that an EHR would need

The goal of the Audit log is to support security surveillance to look for abuse of policy, abuse of systems, and to inform an accounting of disclosures. The ATNA audit log is not intended to be used to track changes made to the medical records, this would be the responsibility of the medical records systems.

This diagram shows a use-case where there are multiple Audit Record Repositories distributed across an XDS environment. This would be a common configuration where each organization in an Health Information Exchange (HIE) has decided to maintain their own Audit Record Repository independent from the HIE. In this way the Audit Record Repository in any one organization would manage the audit log entries for that organization and would forward copies of any audit log entry that is a result of a transaction with the HIE (the dotted orange lines).

A good example of why this is important is the basic XDS Document Retrieve transaction. If this transaction does not force an user assertion (discussed later) then the Document Repository can only record the document unique ID that was requested and the system identity that requested it. This is not enough information for the organization hosting the Document Repository to fully report an account of disclosures, but is sufficient information to trace the specific event back to a specific Document Consumer system where the further details can be found.

When this transaction includes an XUA assertion the audit log on the Document Repository would include the user identity and likely purpose of use, but would require extra processing to determine the patient (this extra processing could take place during the transaction, could be known through other means, or could be looked up during audit analysis and reporting)

References:

Status: Final Text
IHE ITI Technical Framework

Vol. 1 - Section 9
Vol. 2a - Sections 3.19, 3.20

Standards Used

Secure Communications

Security Audit Log

ASTM E2147 – Setup the concept of audit logs for healthcare including accounting of disclosures
RFC-3881 – Defined the Information Model (IETF rule forced this to be informative)
DICOM Supplement 95 – Made the information model Normative, defined Vocabulary, Transport Binding, and Schema

“Security Considerations” section found in other Profiles may specialize how ATNA is applied
The Audit Event Message typically specialized in Vol 2 at the Transaction level

PIX QueryTransaction : See section Vol 2a:3.9.5.1
XDS Register Document Set-b: See section Vol 2b:3.42.7.1

Additional Information:

ATNA - This is a comprehensive profile that indicates that Access Control, Audit Control, and Network Controls are important

Access Control
- There is no standards pointed to by ATNA here. There is simply a statement that a system needs to have access controls that can be shown to a local authority are sufficient to protect the systems resources according to the local policies
- If this can't be demonstrated, then the system should not be authorized to be used. Specifically it should not be given a network identity (see network controls)
Audit Controls
- Specifically Security Audit logging
- This is a very thin profiling of the commonly used SYSLOG protocols for communicating that an auditable event has occurred
- This is a FULL PROFILE of the content of that auditable event into an XML encoded message
- There is a set of 'auditable events'. That is events that when they happen an audit log should capture what happens
- The audit log message is fully describing: Who, What, Where, When, How, and Why.
- This requires that the audit event time be kept consistent. Which is why the CT profile exists. The CT profile says use common NTP protocol to keep clocks synchronized to about 1 second, which is generally good enough for security audit logs
- See Accountability using ATNA Audit Controls And ATNA and Accounting of Disclosures

Network Controls
- There are a set of standards specific to the type of network communications. They all address three aspects of network communications of protected information. Not all network communications are protected, for example DNS is not generally needing to be protected as it is not communicating protected information (mostly)
- Authentication of both sides of all communications that include protected information
- Encryption of the communications that include protected information
- Integrity control of the communications that include protected information
- TLS is the general mechanism when no other mechanism is used. TLS is the 'standardized' protocol that is more commonly called SSL. (mostly)
- S/MIME is used for e-Mail
- WS-Security mechanisms are allowed for Web-Services that want to use end-to-end security. Note that none of the IHE profiles leverage this as they are all profiles defining endpoints that need access. But this is specified because there may be deployments where someone puts in the middle of an IHE transaction some form of intermediary that needs partial access
- See Also