AI Regulation Tracker  /  Regulation in force

CMS Just Made "The AI Got It Wrong" a Scored Medicare Reporting Habit: New 2026 Patient Safety Activity

For the 2026 performance year, Medicare added a MIPS improvement activity that gives credit for logging AI-attributable patient harm and near misses, then analyzing the cause and planning a fix. Here is what counts, who it reaches, and how to claim it.

By Anthony Guerriero  ·  Reviewed by The Leveraged Years Editorial Desk  ·  Published June 27, 2026  ·  Last updated June 27, 2026

The vague worry now has a checkbox

Every clinic that has turned on an AI scribe or a decision-support prompt has had the same hallway moment. Someone says the tool got it wrong, a note gets fixed, and the conversation ends. There was rarely a place to write it down, and almost never a reason to. Medicare has now given clinicians that reason.

In the CY2026 Physician Fee Schedule final rule, published in the Federal Register on November 5, 2025 (FR Doc 2025-19787, 90 FR 49266), CMS added a new MIPS improvement activity called IA_PSPA_34, "Patient Safety in the Use of Artificial Intelligence." It sits in the Patient Safety and Practice Assessment subcategory. The activity does not ban any tool or grade any vendor. It asks a practice to start keeping records when its AI tools contribute to patient harm or a close call, and to do something with those records.

What the activity actually asks for

Per the CY2026 Physician Fee Schedule final rule (FR Doc 2025-19787, published November 5, 2025), the activity requires a practice to develop a data-collection field within its patient safety reporting system to capture AI-attributable events, including both actual harm and near misses, and to document a process for identifying the cause of those events and planning future mitigation; the plain-language breakdown that follows here summarizes those published criteria and is not a substitute for the rule's own text.

Read at face value, the activity has three working parts. First, the practice develops a new data-collection field inside its patient safety reporting system specifically for AI-attributable events, capturing both actual harm and near misses. Second, when an event is identified, the practice follows a protocol to figure out what caused it. Third, the practice documents a plan to keep that kind of event from happening again.

The scope of an AI-attributable event is deliberately wide. Per the activity specification, it covers not only automated or semi-automated devices but any electronic tool used to support clinical decision making. That language reaches the ambient documentation assistant that mishears a medication, the risk score that flags the wrong patient, and the imaging prompt that points a clinician toward a read that turns out to be wrong. If the tool helped shape a clinical decision and something went sideways or nearly did, it belongs in the field.

Why a near miss matters as much as a harm

The most useful word in the activity is one many practices would skip. A near miss is an event where the tool produced a bad output but a human caught it before it reached the patient. Those are the events that never generate a complaint, never reach a chart correction, and never get discussed. They are also the early warning that a tool is drifting or being used outside its lane.

By asking for near misses alongside actual harm, the activity pushes a practice to log the quiet failures while the stakes are still low. A pattern of caught errors in one workflow is the signal a practice leader wants long before that pattern produces a real harm. The validation documentation treats actual harm as required and near misses as the ideal, so the strongest attestation captures both.

How this fits the way MIPS already works

Improvement activities are the lowest-friction part of MIPS, which is the point. A clinician or group attests to performing the activity for the required period and keeps documentation to support it. For IA_PSPA_34, the validation evidence is concrete: proof of the new AI-event data field, a protocol for identifying harms linked to AI tools that support clinical decisions, and a protocol that ensures identified harms are mitigated going forward.

That means the lift is mostly procedural rather than technical. Most practices already run an incident or safety reporting system. The work is adding one category, writing a short definition of what counts, and naming the person who reviews entries and closes the loop. A practice that already does informal AI triage is close to done. A practice that has never written any of this down has the most to gain, because the activity forces the habit into existence.

What to put in place before you attest

Start with ownership. Name the person who owns the AI-event field and the cause analysis, because an activity with no owner produces no documentation. Write the definition next, in plain terms, so front-line staff know an ambient scribe error and a decision-support misfire both qualify. Decide where the entry lives, ideally inside the safety reporting system already in use, so this becomes one more category rather than a separate tool nobody opens. Then close the loop on purpose: every logged event gets a cause and a mitigation note, and that record is what you keep.

The deeper value is not the MIPS credit, useful as it is. It is that a practice using AI in care now has a running, dated record of where its tools fail and what it did about it. When a vendor question, a malpractice question, or a board question arrives, that record is the difference between a shrug and an answer.

Browse the full AI Regulation News tracker

Informational analysis for working professionals, not legal advice. Confirm how any rule applies to your situation with qualified counsel.