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:
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.
No comments:
Post a Comment