Audit Logs Under HIPAA: What to Record and Keep

Audit logs under HIPAA must record and let you examine activity in systems that hold electronic PHI, but the rule leaves the event list and the retention period to you. For PHI documents, log sign-ins, views, edits, exports and deletions with who, when and which record, keep review records six years, and review the logs on a schedule.

What the HIPAA audit controls standard requires

The HIPAA audit controls standard is one sentence long. It requires covered entities and business associates to put in place mechanisms that record and examine activity in information systems containing electronic PHI. It does not list events, formats, tools or a retention period, so each organization decides those through its own risk analysis.

The full text in 45 CFR 164.312 on eCFR reads: "Standard: Audit controls. Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information." Two verbs carry the weight. "Record" means the system writes down what happened. "Examine" means someone looks at it.

The audit controls standard has no implementation specifications under it, so there is nothing to label required or addressable. It is a standard every covered entity and business associate must meet. The flexibility comes from 45 CFR 164.306 on eCFR, which lets an organization choose measures based on its size, its technical capabilities, the cost, and the likelihood and impact of risks to electronic PHI.

A second rule makes the "examine" part concrete. 45 CFR 164.308 on eCFR includes a required item called information system activity review: "Implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports." The same section lists log-in monitoring as an addressable item, described as procedures for monitoring log-in attempts and reporting discrepancies.

What the rule leaves to you is most of the design: which events count, how much detail each entry holds, where logs are stored, who can read them and how long they are kept. A written policy that answers those questions, tied to the risk analysis, is the usual way to show the choices were deliberate.

Which events belong in a PHI audit log?

A PHI audit log should record every action that reads, changes, moves or removes protected health information, plus the sign-ins that make those actions possible. For a document workflow, that means sign-ins and failed sign-ins, document views, field edits and approvals, exports, deletions, and changes to users, roles or settings.

Each entry needs enough detail to answer who, what, when, where and which record. A practical minimum is a timestamp with time zone, a unique user ID, the action, the document or record ID, the field if one was touched, and the source, such as an IP address or workstation.

Here is an example of entries for one fictional EOB moving through review. Every name, ID and amount is invented for the example.

Read top to bottom, the log tells the life of one document: who brought it in, which fields the software was unsure of, who checked them, what changed, when the data left, and when someone's rights grew. That last row matters as much as the document rows, because a quiet role change often comes before misuse.

Some events are easy to leave out because they happen outside the main screen:

• System actions. Automated extraction, scheduled deletions and integrations that pull data should log under a named service account, not a blank user.
• Search. A search for a patient name reveals who was looking for whom, even if no document was opened.
• Printing and downloads. Both move PHI out of the system and deserve the same entry as an export.
• Log access. Reading or exporting the audit log is itself an event worth recording.
• Setting changes. A lowered review threshold or a new export destination changes what happens to every later document.

Views deserve special mention. A log of changes alone misses them, yet a view of a patient's record is still access to PHI. Logging views is what lets an organization answer the question "who looked at this patient's documents?" after a complaint.

Schema Care logs each reviewer approval and correction with the person and the time. Its homepage compliance list gives the broader access and audit logs item the status "In progress", described as "Every view, edit and export recorded and available to you."

How long should HIPAA audit logs be kept?

HIPAA names no retention period for raw audit logs. It does require policies and records of required activities to be kept six years, counted from creation or from the last date the item was in effect, whichever is later. Your log review records fall under that rule, so keeping the underlying logs as long is a defensible choice.

Log retention questions usually come up during an investigation or an audit, when someone asks to see who opened a record two or three years ago. A period chosen in advance, and written into the policy, turns that request into a lookup instead of an argument about what was kept and why.

The documentation requirement is in 45 CFR 164.316 on eCFR. It says to maintain written policies and, "If an action, activity or assessment is required by this subpart to be documented", a written record of it. Its time limit specification sets the six-year period for that documentation.

Applied to logs, the rule sorts items into three groups:

• Audit log policy. The written policy on what is logged and who reviews it is documentation. Keep each version six years after it was replaced.
• Review records. Notes from each information system activity review show a required activity was done. Keep them six years from the review.
• Raw log entries. The rule does not set a period. Choose one in writing, and consider that a review record is hard to defend if the entries it cites are gone.

State law, contracts or a legal hold can require longer retention for some records. Log retention also belongs in the organization's broader schedule, which is the subject of the guide to writing a data retention policy for medical documents.

Storage is cheaper than reconstruction. Compressing and archiving older logs to protected, encrypted storage keeps them available without leaving them in a live system where many people can read them.

Reviewing audit logs under HIPAA without drowning

Reviewing audit logs under HIPAA works best as a mix of automatic alerts for a short list of high-risk patterns and a scheduled human review of summaries. Nobody can read every entry. The goal is to look at the entries most likely to show misuse, and to write down that you did.

Alerts suit events that are rare and serious. Examples include repeated failed sign-ins on one account, a sign-in from an unexpected location, a bulk export far larger than usual, a deletion outside the retention schedule, and a role change that grants admin or export rights.

Scheduled reviews suit patterns that need judgment. A monthly report might list accounts that viewed an unusually high number of patients, staff who opened records of patients with their own surname, access after hours, and accounts that were active after the person left. The reviewer notes what was checked, what was found and what was done.

A few habits keep the work manageable:

• Start small. Five alert rules that someone reads beat fifty that everyone ignores.
• Tune after each review. If an alert fired on normal work, adjust it and note the change.
• Assign an owner. One named person signs each review, with a backup when they are away.
• Link findings to action. A suspicious entry leads to an incident record, and possibly to a breach assessment.

That last step connects logging to notification. When a review finds access that should not have happened, the organization needs to decide whether it is a breach, which is covered in the breach notification rule basics.

Reviewer approval and correction trails can also serve as a quality tool, showing which fields or document types need attention. That use belongs to the human review category.

Edge case: audit logs that contain PHI themselves

Audit logs often contain PHI themselves, because an entry that names a patient, a member ID or a corrected dollar amount is health information tied to an individual. Once a log holds PHI, it needs the same protections as the documents it describes: access limits, encryption, retention rules and its own audit trail.

The sample entries above show how easily this happens. "Allowed amount: $106.00 to $160.00" next to a document ID that links to a patient is PHI. A log that printed the patient name or member ID directly would be even more sensitive.

There are two ways to reduce the risk. The first is to log references, not values: a document ID and field name rather than the patient's name or the full content. The second is to store values in a separate, more tightly controlled trail, used only when someone needs to reconstruct exactly what changed. Correction trails usually need the old and new values to be useful, so the second approach often suits review work.

Either way, apply the access rules from the rest of the policy to the logs. Few people should read raw logs. Exports of log data should be logged too. Backups of logs need encryption like any other PHI backup.

Logs also leak through troubleshooting. Application error logs and debug output can capture field values or page text without anyone intending it. Include them in the same review, and set them to mask PHI where the software allows.