Pages

Thursday, April 26, 2012

Patient Data in the Audit Log

There are many different Audit Logs that we often think of. These audit logs should be designed and maintained independent as they have very different purposes.

Security Audit Logs -- contain log of security relevant events that have happened. These logs are used to prove that the security controls are working properly and to evaluate if the organizations security and privacy policies are being upheld. The use of these audit logs are limited to the privacy/security office. I outline inAccountability using ATNA Audit Controls how to get Privacy Audit Reports from a Security Audit Log.

Medical Records Audit Logs -- contain log of clinically relevant events that have happened. Are used to prove that a clinical event has happened. Examples include that a drug that was ordered was administered by a specific nurse at a specific time. These audit logs need to be visible to the clinical users and are used in clinical decision support and reporting.

Error/Event Audit Logs -- contain log of errors or events that have happened. Often these are debugging logs or diagnostic (software or hardware) logs that are used by service personnel during the installation, configuration, or servicing of the system/equipment

How much Patient Identifiable Data is allowed in Security Audit Logs?

There are a few factors in this question:

Patient Identifiable Data is the binding of healthcare data with identifiers of the patient. In the USA this is referred to as Protected Health Information (PHI).

The Audit Reporting system can always use lookup services (IHE PWP, PDQ, XDS, or other) to convert identifiers into displayable names, or to find aliases that should also be used in the searching.

Audit logs, especially security logs, generally do NOT need healthcare data. They need to identify the data, which is done using unique identifiers assigned to the data where possible.

Thus the answer to the question is that audit logs should have as close to zero PHI in them as possible. This of course is the goal, with the possibility of good reason to break this goal. Usually these good reasons are because the identifiers are not yet available, or not available in the code-path that is recording the audit event.

Therefore the audit logs should include the user ID, but not the display name of the user. They should include the patient ID, but not the patient's name. They should include the lab order number, but not the lab values.

The point is that the reporting tools have the ability to look these up, with appropriate access controls and audit logs too…

It is understood that some clinics are specialty clinics, like Betty Ford Clinic, and thus a patient being associated with that clinic is enough to suspect that the patient has that ailment. These specialty clinics need to be handled as special cases.

Where are Security Audit Logs stored?

Security Audit logs need to be protected from threats. These are a different class of threats and there is a very different set of mitigation.

A security audit log needs to be writable by any system that is creating authentic audit log events, clearly the record needs to show what system recorded the event. One risk this presents is that a malicious individual could simply create many audit events and thus overflow the audit server with useless messages, so the operational design needs to handle this.

The security audit log should be readable only by those authorized to read it. This will be a small sub-set of employees as the security audit log will contain sensitive health information (PHI), but will also contain sensitive employee information.

There are many different filtering, reporting, and alerting requirements on the audit log system.

This is why the ATNA profile utilizes syslog standards to record the audit events on a specialized system. These specialized systems are used often outside of healthcare, and there is a very large industry built around them (IBM tivioli, CA unicenter, etc). The Healthcare industry should utilize these network standards and focus our attention on continuing to develop clinical capability. There is no reason for the healthcare industry to reinvent this wheel.

About Me

The information posted here are mine and not necessarily represent By Light Professional IT Services Inc. I am a Standards Architect specializing in Standards Architecture in Interoperability, Security, and Privacy for By Light Professional IT Services Inc. Primarily involved in the international standards development and the promulgation of those standards. Co-chair of the HL7 Security workgroup, a member of the FHIR Management Group, FHIR core team, and co-chair of IHE IT Infrastructure Planning Committee. Participate in ASTM, DICOM, HL7, IHE, ISO/TC-215, Kantara, W3C, IETF, OASIS-Open, and other. Was a core member of the Direct Project specification writing, authoring the security section, and supporting risk assessment. Active in many regional initiatives such as the S&I Framework, SMART, HEART, CommonWell, Carequality, Sequoia (NwHIN-Exchange), and WISHIN. Active in the Healthcare standardization since 1999, during which time authored various standards, profiles, and white papers.

Surely there are other copyright and trademarks that I should recognize, but everyone else seems to be reasonable; expecting readers of blogs know that I am not trying to claim or take ownership of their copyright and trademarks.