How the Cures Act ended 'too burdensome' objections to audit trail production
Providers once argued audit trails were too hard to produce. Between HIPAA's audit-control requirement and the Cures Act's information-blocking rules, that objection no longer holds up.
For years, the standard response to an audit-trail request was some version of 'that data is too burdensome to produce' or 'the system doesn't really keep that.' That objection was always weaker than it sounded, and a stack of federal requirements has now made it close to untenable. The audit trail is not an optional artifact a provider may or may not have bothered to keep — it is something federal law requires the system to maintain.
HIPAA: audit controls are required, not optional
The HIPAA Security Rule requires covered entities to implement audit controls — mechanisms that record and examine activity in systems containing electronic protected health information. In plain terms, the regulation obligates the provider to have a system that logs who did what to the record. A litigant asking for that log is not asking the provider to build something new; they are asking for the output of a control the provider was already required to operate.
That reframes the burden argument entirely. A provider cannot simultaneously maintain that it complies with the Security Rule's audit-control requirement and that it has no meaningful audit data to produce.
HITECH: enforcement with teeth
The HITECH Act strengthened HIPAA enforcement, increasing penalties and expanding accountability for the security and integrity of electronic records. Its practical effect on discovery is indirect but real: it raised the stakes for actually maintaining the controls HIPAA requires, which means audit data is more likely to exist, be retained, and be retrievable than a 'we don't really keep that' objection suggests.
The 21st Century Cures Act: information blocking
The most decisive development is the Cures Act and its information-blocking rules. The regime defines information blocking as a practice likely to interfere with access, exchange, or use of electronic health information, and it presses providers and their technology vendors toward making electronic health information available rather than withholding it.
The interaction with litigation is straightforward. A provider that takes the position it cannot or will not produce electronic health information that its system maintains is making an argument increasingly at odds with the direction of federal health-information policy. The 'too burdensome' objection runs against a legal current that expects this data to be accessible.
Taken together: HIPAA requires the audit controls, HITECH put enforcement behind them, and the Cures Act pushes toward access rather than withholding. The audit trail is data the provider is required to keep and increasingly expected to release.
What this means for the burden argument in practice
- Reframe the request around required controls: you are seeking the output of an audit-control mechanism HIPAA already obligates the provider to maintain.
- Press for the provider to identify its EMR and version and the audit reports it can run — vague burden claims rarely survive contact with the system's documented capabilities.
- Treat 'the data is hosted by the vendor' as logistics, not an exemption; cloud-hosted platforms retain audit data centrally and the provider can request exports.
- Where production stalls, the regulatory framing supports motion practice: the data is one the provider is required to keep, not one it is free to disclaim.
None of this is legal advice, and the precise application turns on jurisdiction, posture, and the facts of the case — that is your domain, not ours. What the technical and regulatory landscape establishes is narrower and firmer: the audit trail exists because the law requires the controls that generate it, and 'too burdensome' is a far harder position to hold than it was a decade ago.
This article is technical and regulatory information, not legal advice. EMRCheck is not a law firm.