AI Safety Events Under PSO Rules: Compliance Guide

How PSQIA Defines a Patient Safety Event

Under the Patient Safety and Quality Improvement Act (PSQIA), a patient safety event is defined without reference to the technology involved. The statute focuses on outcomes and conditions: events, near misses, and unsafe conditions that result in or could result in patient harm. The definition does not carve out or specially classify software, algorithms, or autonomous systems.

As a result, an AI-driven clinical decision support error, an autonomous agent action, or an unsafe recommendation can meet the statutory definition when patient harm occurs or is reasonably foreseeable. Classification turns on the clinical and operational facts of the incident, not on whether an AI system participated in the care pathway.

Where AI-Involved Incidents Fit Into the Definition

Because the PSQIA definition is technology-neutral, AI involvement does not create a separate reporting category by itself. No AHRQ or HHS guidance currently provides an AI-specific classification standard. Providers therefore evaluate AI-involved incidents against the same patient safety event criteria used for other clinical and operational failures.

To qualify related data for PSQIA confidentiality protection, organizations must map AI system logs and outputs into an existing Patient Safety Evaluation System (PSES). Confidentiality protection attaches only to data assembled within that documented system as Patient Safety Work Product, not to raw operational telemetry retained solely for IT or product governance.

PSQIA framework applied to AI incidents

Technology-neutral definition PSQIA covers events, near misses, and unsafe conditions regardless of the tool involved, including AI systems.
PSES intake required Confidentiality protection attaches only to data assembled within a documented Patient Safety Evaluation System.
No AI-specific Common Format AHRQ's reporting templates do not yet include a dedicated taxonomy for AI or algorithm involvement.
Separate FDA track FDA's AI/ML SaMD oversight operates independently of PSQIA reporting and confidentiality rules.

Confidentiality and Privilege Limits for AI Governance Records

PSQIA confidentiality and privilege protections do not automatically cover every AI-related record an organization keeps. Logs, model version histories, override records, and monitoring outputs used for internal governance remain ordinary business records unless they are assembled within the PSES for patient safety activities and reported to a PSO as protected Patient Safety Work Product.

Organizations should distinguish data retained for runtime governance, quality monitoring, and change control from data formally captured for PSES and PSO reporting. Mixing those purposes without clear process boundaries can leave sensitive material outside PSQIA protection, or create ambiguity about what may be disclosed in discovery, regulatory inquiries, or dual-reporting scenarios.

FDA AI/ML device oversight and state incident reporting remain separate obligations. The same underlying AI-related event may require PSO reporting and independent external reporting. Privilege under PSQIA does not substitute for those other pathways.

Audit Logging and Traceability Needed to Support Reporting

Reconstructing how an AI system contributed to a patient safety event typically requires linking model version history, decision and override logs, and clinical documentation into a single evidentiary chain. Organizations lacking unified traceability across these data sources face greater difficulty producing a timely and accurate PSO report, since gaps in the record make it harder to establish what the AI system recommended, what a clinician or operator decided, and how the two interacted.

Build a reconstructable evidentiary chain

Runtime monitoring and audit logging infrastructure that records AI agent actions, tool invocations, and policy enforcement decisions can supply the underlying evidentiary record that a PSES intake process then formalizes into protected Patient Safety Work Product. This is a technical and governance requirement distinct from, but supportive of, PSQIA compliance, and it is separate from the change-control and monitoring pipelines organizations maintain to satisfy FDA's AI/ML device oversight.

Practical boundary

Treat runtime audit trails as the source material for PSES intake. The protection analysis turns on how and why the organization assembles that material inside the Patient Safety Evaluation System, not on logging alone.

Questions for Compliance and Clinical Safety Teams

Use the following prompts to assess whether AI-involved incidents can be classified, documented, and reported under existing PSO arrangements.

Does the organization have a documented PSES that can formally capture AI or algorithm-related logs and outputs as protected Patient Safety Work Product?

What audit logging and traceability capabilities exist to reconstruct an AI system's decision, version, and override history for a PSO report?

How is AI data used for internal governance and monitoring distinguished from data assembled specifically for PSES and PSO reporting?

Is the contracted PSO an AHRQ-listed entity, and has it addressed how AI-involved events should be classified absent a standardized Common Format field?

What is the process for determining when dual reporting, such as PSO plus FDA or state incident reporting, is required for the same AI-related event?

Build the Audit Trail PSO Reporting Requires

Compliant classification and reporting of AI-involved patient safety events depends on reliable audit logging and traceability across AI agent actions and decisions. Trussed AI provides runtime governance and audit logging capabilities that support the evidentiary record healthcare organizations need for internal AI governance.

Explore Runtime Governance