Tuesday, December 1, 2009

Standardizing Audit Trails

Over the past month, the HIT Standards Committee and its Privacy and Security Workgroup have discussed the simplest set of security standards for 2011 and beyond.

We've had debates about audit trails, strong identity management, and consistent time. Each of these topics deserves its own entry and I'll start with audit trails. Thanks to John Moehrke of GE for background information - he was part of the team that wrote the IHE profile on auditing, ATNA, which is based on ASTM E2147 healthcare specific audit trail standards.

What is an audit trail and how does it differ from a disclosure log?

Audit is simply a record of system events -- it does not get into "why" as does accounting for disclosures (which includes release of information to external organizations for a specific purpose). HIPAA requires that organizations:

1. Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information; and

2. Implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports.

The first HIPAA requirement is what should be captured in the EHR product certification criteria, and the second is a "meaningful use" policy statement. While the ATNA profile draws upon the ASTM E2147 standard in its specification of the data elements to be captured in an audit trail, it goes beyond what either ASTM or HIPAA require in its focus on the concept of centralizing audit information by having multiple systems send audit messages to an audit repository. The ASTM standard specifies the data elements to be captured when auditing accesses to protected healthcare information, but goes beyond ATNA by also specifying a list of data elements to be included in an accounting of disclosures.

The issue with audit trail standards is determining how specific to be about their requirements. Technical requirements for auditing accesses in EHR systems, from most restrictive/intrusive to least could be:

1. Cross-enterprise ATNA - the ability of an organization in a health information exchange to query another organization's audit trail. This is helpful in maintaining trust because there is a virtual audit trail for the community.

2. Intra-enterprise audit integration - the capability to construct a continuous audit trail across systems within an organization using ATNA (such as the Veteran's Administration Auditing Service project.

3. The first HIPAA requirement above, which is a policy "standard" not a technological one.

Initially, we debated the need for cross-enterprise audit trails. Shouldn't ARRA privacy requirements be met with just #3, a policy?

In our Security Testimony on November 19th, we heard that availability of audit trails between organizations is one of the most important elements of building trust in a health information exchange.

Automating audit trails at the organizational level, #2, seems like a wonderful solution to security, breach notification, and privacy. There have been very public exposures of health data, and in each case the people who violated privacy were discovered through the use of audit logs:

There are more…

When it comes to real world implementation of audit logs, I know there is a big difference between legacy software and new applications. Typically EHRs have built up audit logging incrementally, based on customer requests, not via foundational design. Ideally, audit logging would have been architected to be a replaceable code module or web service, but this is not likely in existing applications. However, Healthcare Information Exchange/NHIN is largely a greenfield. This is new code that could be held to higher standards.

Thus, one possibility is to use #3 (a policy) for organization level audit trails, but to use a standards based audit repository (ATNA) for Health Information Exchanges. For internal security events it could be acceptable to record audit logs in a proprietary format as long as they can be exportable into a text file format with a well formed time-stamp.

We'll be having an ongoing dialog about this topic over the next month. I welcome your input.


Keith W. Boone said...

John Moehrke makes some great points about the distinction between Audit and Disclosure and of course I had to add my two cents.

John Moehrke said...

For further technical and implementation details on how ATNA can be used to inform an Accounting of Disclosures: http://healthcaresecprivacy.blogspot.com/2009/11/atna-and-accounting-of-disclosures.html

Glen said...


I write this comment as and author and contributor to the audit standards work.

The core standard for ATNA auditing is not ASTM E2147. Rather, it is RFC3881, a record of consensus among various organizations: HL7, DICOM, IHE, ASTM, and the NEMA/COCIR/JIRA Security & Privacy Committee. See www.RFC3881.net for details.

The participating organizations had developed separate uncoordinated views, even though they had overlapping membership. I was responsible for forming the consensus and documenting it. In parallel with the effort to get RFC3881 approved and published by IETF, IHE developed ATNA.

ATNA implementations -- both audit sources and repositories -- has now been tested at six successive IHE Connectathons and demonstrated in six successive HIMSS Interoperability Showcases. So it's not something new or technically difficult.

I would be overjoyed to see so more positive contributions to realize widespread value from what ATNA enables. We need national policies for the capture, storage, and use of the ATNA audit data. We also need best practices, if not standards, for reporting it and other notifications. Then we can have measurable meaningful use.

Sean Nolan said...

An important topic -- I would, though, love to see us start from a slightly different place. What level of auditing do we really NEED in order to enable exchange?
More thoughts on my blog. Thanks for keeping the discussion moving.

Anonymous said...

Are there any privacy issues with audit trails? I've been wondering if, for example, a celebrity's treatment at a substance abuse clinic could be verified to looking at the audit logs, without leaving a trace in the EHR logs themselves.

Arien Malec said...

As John Moehrke note, the base use case for ATNA is security monitoring within the enterprise. I believe that ATNA is misapplied to ensure disclosure and trust across enterprises.

I would also note that one of the principles of security that should be applied in a cross-enterprise case is to have a level of mistrust for any transactions that cross the enterprise boundary. That is to say, as an HIE provider, I only trust the audit events that I create and manage, and would be foolish to trust the audit events generated by an external system. One of the core principles in building applications exposed to the internet is "never trust the client." ATNA security logs streamed across enterprise contexts provides a false measure of trust and security.

Auditability, disclosure, ability to apply forensics, and ability to expose the access history to a patient are all core policy requirements. They do not need ATNA to be realized. As Sean notes, the default answer here should be to enforce the minimal standards required for interoperability. As I noted to the HITSC, I do not believe that ATNA should be part of that set.

Lmoisan said...

What do you think of the Common Event Expression (CEE™) initative ?