Building compliant software in healthcare / The rules that apply to your code
Audit controls under the Security Rule
One sentence in the Security Rule creates the widest gap between what healthcare teams build and what the rule describes. Audit controls require mechanisms that record and examine activity in systems containing PHI, and in healthcare the activity that matters most is the one almost nobody logs: reading.
Published August 22, 2026. Editorial.
Key takeaways
- The standard says activity, not changes. A change history is a partial implementation.
- Inappropriate access in healthcare is overwhelmingly a read problem, and reads produce no writes to notice.
- The word examine implies review. A log nobody looks at satisfies half the standard.
- Emergency access needs the most detailed logging, because it bypasses the access model the rest of the controls rely on.
Section 164.312(b) reads in full: implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information [1].
It is a short standard with no implementation specifications underneath it, which makes it easy to treat as satisfied by whatever logging already exists. Two words need close attention.
"Activity" is not "changes"
Most application audit systems were designed to answer a product question: what happened to this record, and who changed it. That produces a change history, which is genuinely useful and is not what this standard describes.
Consider what inappropriate access to clinical data looks like. A staff member looking up a neighbour's records. A curious employee reading a celebrity patient's chart. A departing member of staff downloading every record they can access in their last week. Someone accessing a family member's information out of concern rather than malice.
Every one of those is a read. None of them modifies anything. In a system that logs changes, all of them are invisible, and they are close to the entire risk model this control exists for. The disclosure risk in healthcare is dominated by people who are allowed to access the system doing things with that access they should not, and that behaviour leaves no trace in a change history.
So the engineering requirement is that access to PHI produces a record, on read, through every path. Not just the clinical interface: the administrative back office, the reporting tool, the scheduling system, the billing view, direct database access by an engineer debugging something, and the API a partner integration calls.
"Examine" implies somebody looks
The standard says record and examine. A great deal of implementation effort goes into the first verb and almost none into the second, which leaves the control half complete.
Examination does not have to mean a person reading log lines. In practice the workable version is automated detection over the records, with human review of what it finds. The patterns worth detecting are well known in healthcare: access to a record with the same surname as the accessing user, access to records outside the user's usual department or patient panel, volume anomalies where someone reads far more records than their peers, access to records of individuals flagged as sensitive, and access at unusual hours by users who normally work fixed shifts.
None of those is conclusive on its own. All of them are worth a look, and a system that finds them turns a passive log into an actual control. The reason this matters practically is that a log which is never examined provides evidence after an incident and prevents nothing, and organisations frequently discover inappropriate access only when the patient complains.
Cost, and why it stopped being the reason
The honest historical objection to logging every read was cost. Reads outnumber writes by a large factor in clinical systems, the storage adds up, and the engineering work to instrument every path is significant and delivers no clinical value.
Two things have changed the calculation. Storage is cheap relative to the cost of a breach investigation conducted without records. And the instrumentation work, which used to be weeks of tedious, low-status engineering spread across every interface, is now a fraction of that. This is the specific place where the economics argument in why AI-native development fits regulated work turns into a control that either exists or does not.
Where volume genuinely is a problem, the answer is scoping rather than omission: log all access to PHI in full detail, and be more selective about everything else. That is a decision you can document and defend. "We do not log reads" is not.
What the record needs to contain
The same fields that make any audit trail usable, with one healthcare-specific addition.
Who, resolved to a person rather than a shared account or a service identity. What record, by an identifier that stays the same through merges and renames. What action, with export distinguished from read. When, with an unambiguous timestamp. Through which interface.
The healthcare addition is the relationship or the reason. In systems where it is feasible, recording why this user had a legitimate relationship to this patient at this moment, the care relationship, the assigned department, the open ticket, transforms review from guesswork into something answerable. Without it, every review question becomes an investigation, because nothing in the record distinguishes appropriate access from inappropriate access.
Emergency access needs the most logging
Emergency access procedure is a Required specification [1], which means your system has a path that bypasses the ordinary access model, by design and by obligation.
That path is where the audit requirement is strictest, for the obvious reason. Use of emergency access should produce a distinct record type rather than mixing with ordinary access, capture the reason if the workflow allows it, be reviewed on a defined schedule rather than on suspicion, and be time-bounded so the elevated access expires without anybody remembering to revoke it.
The failure here is not usually that emergency access is unlogged. It is that emergency access entries look identical to ordinary entries in the log, so nobody can find them, and nobody reviews a category they cannot filter for.
Checking it
Every claim on this page can be an assertion that runs on every change, which is how it stays true after the next twenty features.
Assert that a read through each interface produces an entry with all fields populated. Assert that the entry names a person, including when the access came through an integration acting on someone's behalf. Assert that an emergency access produces a distinguishable record type. Assert that the audit store's configured retention meets the obligation, which catches the day somebody reduces it for cost. Assert that audit rows cannot be modified using the application's own database credentials.
The last one deserves emphasis in healthcare, because an audit trail that the audited party can edit is the one control whose failure is silent and total. The mechanics are covered on audit trails that satisfy an examiner.
If you want to know what your current logging actually covers, get in touch and we will trace it.
Best for
- Clinical systems where many staff can legitimately reach a large number of records
- Products with an administrative back office or reporting layer built separately from the main application
Avoid if
- What counts as PHI has not been scoped, since logging everything in full detail has real cost and no limit
Check before you decide
- Read a patient record through every interface and check what appears in the trail
- Ask who examines the audit records, how often, and what they look for
- Filter the log for emergency access and see whether it is possible
- Attempt to modify an audit row with the application's own database credentials
Common questions
Does HIPAA require logging reads of patient records?
The standard requires mechanisms that record and examine activity in systems containing PHI, and reading a record is activity. Since inappropriate access in healthcare is overwhelmingly a read problem that produces no writes, a change history leaves the primary risk invisible.
What does the word examine add to the audit controls standard?
It implies the records are reviewed rather than merely produced, which means a log nobody looks at is a half-complete control. The workable version is automated detection over the records with human review of what it finds, since a log that is never examined provides evidence after an incident and prevents nothing.
What access patterns are worth detecting automatically?
Access to a record sharing the accessing user's surname, access outside the user's usual department or patient panel, volume far above peer norms, access to records flagged as sensitive, and access at unusual hours by users on fixed shifts. None is conclusive alone, but each is worth a look, and finding them turns a passive log into a real control.
Isn't logging every read too expensive?
It was the honest objection historically, and both parts of the cost have changed: storage is cheap next to a breach investigation conducted without records, and the instrumentation work that used to take weeks across every interface is now a fraction of that. Where volume is genuinely a problem, scope by logging all PHI access in full detail and being selective elsewhere, which is a defensible documented decision in a way that not logging reads is not.
How should emergency access appear in the audit log?
As a distinct record type that can be filtered for, rather than mixing with ordinary access entries. The usual failure is not that emergency access goes unlogged but that its entries look identical to everything else, so nobody can find them and nobody reviews a category they cannot isolate.
What is the audit controls standard under HIPAA?
Section 164.312(b) of the Security Rule, which requires hardware, software, or procedural mechanisms that record and examine activity in information systems containing or using electronic PHI. It has no implementation specifications underneath it, which makes it easy to treat as satisfied by whatever logging already exists rather than by what the two operative words actually describe.
What fields does a HIPAA-relevant audit record need?
Who accessed the record, resolved to a named person rather than a shared account or a service identity, which record by an identifier that stays the same through merges and renames, what action was taken with export distinguished from read, an unambiguous timestamp, and the interface used. In healthcare specifically, recording the care relationship or reason for access turns a review from guesswork into something answerable.
How do you check whether audit controls are actually working?
Read a patient record through every interface, including the administrative back office and any reporting tool, and confirm each access produces a complete entry. Then try to modify an audit row using the application's own database credentials. An audit trail the audited party can edit is a control whose failure is silent and total, which is why that check matters as much as confirming the entries exist.
Related reading
Adding eval tests was the best decision we made
We generate every line of code we release. The single change that made that safe was writing the check before the code, and it turned out to change how we review, how we spec, and how fast we can work.
A practical pre-launch security review for a small team
You do not need perfect security to launch. You need to check the few basics that find most real problems, and to know when the risk is big enough to bring in a specialist.
More in The rules that apply to your code
Minimum necessary in a permission model
Minimum necessary is the HIPAA principle everyone can state and almost nobody enforces in software. It is not a policy problem. It is a permission-model problem, and permission models only ever grow wider unless something is actively checking.
Encryption and the proposed Security Rule update
Encryption of PHI is not currently required by the HIPAA Security Rule. It is Addressable, which surprises people and explains a good deal of real-world practice. A proposed update would change that, and the sensible response is to build now in a way that makes the change a configuration matter rather than a project.