Why Audit Logs Matter Differently in Clinical AI
Traditional EHR audit logs record which user opened which chart at what time. That problem is well-understood. Clinical AI introduces a structurally different challenge. When a large language model processes a patient intake record, generates a clinical summary, or flags a screening result, no single "user" opened a chart in any conventional sense. The model ingested data, transformed it, produced output, and potentially wrote a result back into a clinical workflow. Each of those steps touches ePHI and each of them must be traceable.
At TheraPetic® Healthcare Provider Group, our clinical informatics team encounters this gap regularly. Organizations deploying AI-assisted screening tools often have excellent application-layer logs but almost no visibility into what the model itself received, what context window it operated on, or what downstream system consumed the output. That gap is exactly what HIPAA's audit controls standard is designed to close, and it is exactly what OCR investigators look for when a breach occurs.
The 21st Century Cures Act adds another dimension that engineering teams frequently overlook. Information blocking provisions apply to health IT developers and certain healthcare providers. When a clinical AI system's log architecture makes it impossible to reconstruct who accessed patient data or whether data access was properly authorized, that opacity can be interpreted as a technical information blocking practice under ONC's implementing rules at 45 CFR Part 171.
HIPAA Technical Safeguards and the Audit Controls Standard
HIPAA's Security Rule places audit controls under the Technical Safeguards category at 45 CFR 164.312(b). The regulatory text is deliberately non-prescriptive: covered entities and business associates must "implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information." The standard is addressable in its implementation specification, meaning organizations must document why a specific approach is reasonable and appropriate for their environment.
That flexibility is not a loophole. OCR's guidance and enforcement history make clear that "addressable" does not mean optional. What it means is that the implementation must be calibrated to the risk environment of the system in question. A clinical AI system processing behavioral health intake data carries a materially higher sensitivity profile than a billing clearinghouse. The audit controls must reflect that.
For clinical AI specifically, the audit controls standard requires thinking through at least four distinct event categories. First, authentication events: every attempt to authenticate to an API that exposes patient data, whether successful or failed. Second, data access events: every query to a database, FHIR R4 endpoint, or data lake that returns records containing ePHI. Third, model inference events: every invocation of an AI model where the input or output contains or is derived from ePHI. Fourth, output delivery events: every instance in which a model output is delivered to a clinical interface, written to an EHR, or transmitted to a downstream system.
Organizations sometimes argue that logging model inference events is operationally impractical at scale. Our clinical informatics experience does not support that argument. Structured logging at the inference layer is an engineering problem with known solutions. The cost of implementing it is far lower than the cost of an OCR investigation that concludes with a corrective action plan.
What OCR Actually Expects During Breach Response
When OCR investigates a breach involving a clinical AI system, the investigation does not begin with the model. It begins with the logs. Investigators will request evidence that the organization can reconstruct, with specificity, what data was accessed, by which system component, during what time window, and whether that access was authorized under the organization's minimum necessary policies.
OCR's published resolution agreements consistently reveal a common failure pattern: organizations can demonstrate that a breach occurred but cannot demonstrate its scope because log records are incomplete, were not retained long enough, or were stored in systems that were themselves compromised. HIPAA's documentation requirements under 45 CFR 164.316(b)(1) require that security policies and procedures be retained for six years from creation or last effective date. Logs that support breach scope determination should be treated with equivalent or greater retention discipline.
For clinical AI systems, scope determination during a breach investigation requires answering questions that traditional EHR logs were never designed to answer. Which patient records were included in the context window passed to the model? Did the model's output contain inferred health information about individuals not explicitly named in the input? Did the inference result get cached, and if so, where? Was the cache encrypted? Was the cache purged on the retention schedule?
Engineering teams building clinical AI pipelines at TheraPetic®'s technical partners address these questions by treating the model context window as a data access event equivalent to a database read. Every call to an embedding model, every retrieval step in a RAG pipeline that touches a patient record store, and every prompt assembly step that incorporates ePHI is logged with a structured event that captures the record identifiers involved, the timestamp, the requesting service identity, and the model endpoint invoked.
OCR does not currently publish a formal technical standard for clinical AI audit logs. What exists is the combination of the Security Rule's audit controls standard, OCR's breach investigation practice, and published resolution agreements. Reading those sources together produces a clear operational requirement: if you cannot reconstruct what your AI system did with a specific patient's data on a specific date, your audit controls are inadequate.
The 21st Century Cures Act and Information Blocking Log Retention
The 21st Century Cures Act prohibits information blocking practices by health IT developers, health information networks and exchanges, and certain healthcare providers. ONC's implementing regulations define information blocking as a practice that is likely to interfere with access, exchange, or use of electronic health information, absent a recognized exception.
The intersection with audit logging is less obvious than HIPAA but equally consequential. If a clinical AI system's architecture makes it technically impossible for a patient or an authorized third party to obtain an accurate accounting of how their health data was accessed or used, that architectural decision may constitute an information blocking practice. The key provision is ONC's Content and Manner Exception and its counterpart, the Infeasibility Exception. Invoking the Infeasibility Exception requires documenting why accurate disclosure is technically infeasible, and that documentation must be supported by evidence. Absent audit logs that could enable accurate disclosure, the infeasibility argument collapses.
The practical implication for clinical AI engineering teams is this: log retention policies must account for two separate compliance frameworks simultaneously. HIPAA drives retention from the date of creation or last effective date of the policy that governs the log. The Cures Act drives retention from the perspective of a patient's right to access an accounting of disclosures. Under the HIPAA Privacy Rule, patients have a right to an accounting of certain disclosures of their ePHI for up to six years prior to the request date. A clinical AI system that cannot support that accounting because its logs were purged at 90 days is not compliant with either framework.
ONC's information blocking enforcement has focused primarily on EHR vendors since the rule took effect, but the agency has made clear through guidance documents that the definition of health IT developer is broad. Organizations that develop and deploy AI tools that access, process or transmit electronic health information for clinical purposes fall within that definition. The compliance exposure is real and the engineering solution is straightforward: retain structured audit logs for a minimum of six years and ensure they are stored in a system that is itself HIPAA-compliant, versioned and tamper-evident.
What a Clinical AI Audit Log Must Capture
An audit log for a clinical AI system is not a generic application log. It requires a defined schema that captures the specific attributes investigators and compliance officers need to reconstruct events. The following field categories represent the minimum viable schema our clinical informatics team recommends for any AI system processing ePHI.
Identity and Authentication Fields
- Service identity of the requesting component (not just the human user, if any)
- OAuth token or API key identifier (never the credential itself)
- Authentication outcome and failure reason if applicable
- IP address and geographic region of the request origin
Data Access Fields
- Record identifiers for every ePHI record accessed (patient ID, encounter ID, document ID)
- Data source identifier (FHIR endpoint, database name, document store)
- Query type and scope (read, write, delete, bulk export)
- Row count or token count of data returned where applicable
Model Inference Fields
- Model endpoint identifier and version
- Prompt template version and hash
- Whether patient-identifying data was included in the prompt (boolean flag, not the data itself)
- Output classification or category (clinical summary, risk flag, screening result)
- Inference latency and token counts for capacity audit purposes
Output and Delivery Fields
- Destination system identifier (EHR endpoint, clinician interface, API consumer)
- Output format (FHIR Observation, plain text, structured JSON)
- Whether the output was reviewed or modified by a Licensed Clinical Doctor before delivery
- Retention status of the output in the destination system
Storing these fields in structured JSON in an append-only log store with cryptographic checksums provides the tamper-evidence that both HIPAA and Cures Act compliance require. SIEM integrations should be configured to alert on anomalous patterns including bulk access events, authentication failures exceeding threshold, and model invocations outside scheduled maintenance windows.
Implementing Audit Infrastructure for Clinical AI at Scale
The engineering challenge is not capturing audit events. Modern observability tooling makes event capture straightforward. The challenge is capturing the right events at the right granularity without introducing latency into clinical workflows and without creating a log volume that is effectively unmanageable at retention scale.
Asynchronous logging is the standard architectural answer. The primary inference pipeline writes a structured event to an in-memory queue, returns the clinical output without waiting for log persistence, and a separate logging consumer writes to the durable log store. This pattern decouples logging latency from inference latency. It introduces a small window of log durability risk during a crash, which can be mitigated with write-ahead logging or a persistent message queue like Apache Kafka configured with replication.
FHIR R4 AuditEvent resources provide a standards-based schema for healthcare-specific audit logging. For organizations already operating within a FHIR-native infrastructure, mapping clinical AI audit events to AuditEvent resources creates a unified audit trail that spans both traditional EHR access and AI-assisted processing. The AuditEvent resource's agent, entity and source elements map cleanly to the identity, data access and output delivery field categories described above.
Log storage must comply with HIPAA's encryption requirements for ePHI at rest and in transit. If audit logs contain patient identifiers, those logs are themselves ePHI. This creates a layered compliance requirement: the audit infrastructure protecting clinical AI logs must meet the same security controls as the clinical AI system itself. Organizations sometimes treat audit logs as lower-sensitivity operational data and store them in unencrypted flat files. That practice creates a secondary breach surface and a direct HIPAA violation.
Retention policies should be codified in the organization's HIPAA policies and procedures documentation with specific retention periods, destruction schedules and disposal methods. Logs subject to active litigation hold must be flagged and excluded from automated destruction cycles. Integrating log retention management with a data governance platform like MyDataKey provides automated policy enforcement and creates the documentation trail that OCR expects during a breach investigation.
The TheraPetic® Infrastructure Model for Compliant AI Logging
TheraPetic® Healthcare Provider Group operates as a 501(c)(3) nonprofit healthcare provider with EIN 81-3003968. Our HANK AI screening infrastructure and the verification infrastructure at verify.mypsd.org process sensitive behavioral health data under HIPAA Business Associate Agreements. The audit logging architecture we have developed reflects lessons learned from operating compliant clinical AI at scale in a resource-constrained nonprofit environment.
Our approach treats every HANK AI inference event as a first-class audit event equivalent in compliance weight to a clinician accessing a patient record. The structured event schema described above is implemented in full. Logs are written to an encrypted append-only store with cryptographic checksums verified on a nightly schedule. Anomaly detection runs continuously against the log stream with alerts routed to our HIPAA Security Officer.
The clinical team, led by Dr. Patrick Fisher, PhD, LPC, NCC, requires that every AI-assisted screening output be reviewed by a Licensed Clinical Doctor before it enters any patient record. That human review step is itself a logged event. This creates an audit chain that runs from data ingestion through model inference through clinical review through output delivery. When an OCR investigator asks us to reconstruct what happened with a specific patient's data, we can answer that question completely and quickly because the audit infrastructure was designed from day one to support that question.
Organizations building clinical AI systems in 2026 do not have the luxury of treating audit logging as a post-deployment compliance retrofit. The regulatory environment, shaped by HIPAA's Technical Safeguards and the 21st Century Cures Act's information blocking provisions, requires that logging architecture be a first-order engineering concern from the first line of system design. The cost of getting it right at design time is a fraction of the cost of retrofitting it under regulatory pressure or after a breach.
For technical guidance on FHIR R4 AuditEvent implementation, the HL7 FHIR specification at hl7.org is the authoritative reference. ONC's information blocking regulations are published in full at healthit.gov. OCR's guidance on the Security Rule audit controls standard is available at hhs.gov. Engineers building in this space should treat all three sources as required reading.