TL;DR: USCDI v5 (effective 2026) elevates Provenance from an "Author Organization / Author Time Stamp" concept into a granular, block-level data-lineage expectation. Most AI scribe vendors still stamp provenance at the document level—leaving a gap that fails payer audits and triggers Information Blocking scrutiny. Scribing.io closes this gap by writing a US Core FHIR R4 Provenance for every HPI and Assessment block: agent[Device]=transcriber (AI) + agent[Practitioner]=author/verifier (human), with a SHA-256 digest that is JWS-signed and RFC3161 time-stamped, then linked via Composition.section. This "Human-Verified" lineage survives EHI export and copy/paste. Jump to the audit scenario or ROI.

• USCDI v5 Provenance Update

• Clinical Logic: Surviving a Payer Audit

• Block-Level Provenance Architecture

• ICD-10 Documentation Standards

• Implementation Sequence for Operations

• ROI and Recoupment Prevention

USCDI v5 Provenance Update for AI Scribes: 21st Century Cures Act Compliance

USCDI v5 Provenance Update: What Changed for AI Scribes Under the 21st Century Cures Act

CLINICAL UPDATE 2026: Revised for new CMS CPT G2211 standards, SB 1120 compliance, and FHIR interoperability.

The CMS/ONC materials that most Clinical Operations Directors encounter treat Provenance as a single data class with two elements: Author Organization and Author Time Stamp. That framing was adequate when a "note" meant one human-authored document. It is no longer adequate when an AI scribe drafts the History of Present Illness (HPI) and Assessment, and a clinician later attests to it.

USCDI v5 and the Cures Act Information Blocking provisions together create an implicit—but auditable—expectation: when electronic health information is accessed, exchanged, or used "without special effort," the recipient must determine who authored each clinically meaningful segment and who verified it. When an AI system generates the HPI, the Author-Role distinction between machine transcriber and human verifier becomes the pivotal provenance fact. Scribing.io was built around that distinction.

The core problem is precise: document-level provenance cannot answer "which sections did the AI draft, and did a licensed clinician attest to each one?" That is exactly the question a payer asks during a recoupment audit. See our Clinical Specialties Directory for how this applies across service lines, and the EHR Integration Library for platform-specific provenance mapping.

SB 1120 in California and parallel state statutes now require disclosure when generative AI drafts clinical communications. Ambient Clinical Intelligence that cannot separate transcriber from verifier at the section level cannot satisfy both federal provenance and state disclosure demands simultaneously.

Scribing.io Clinical Logic: Surviving a Payer Audit Triggered by a Patient Access Complaint

The scenario begins here. A multispecialty clinic receives a payer audit triggered by a patient access complaint. The payer requests proof of who authored and verified 60 diabetes follow-up encounters (E11.9 (ICD-10-CM)) where an AI scribe drafted the HPIs. The incumbent vendor's notes carry no Author-Role provenance—only a document-level timestamp.

The consequence was severe. Twenty-seven claims are recouped for missing clinician attestation, and the case escalates to Compliance. This is not a documentation-quality failure. It is a data-lineage failure—the clinical content may have been perfect, but the notes could not prove the human accountability chain that Cures Act provenance expectations require.

How Scribing.io Resolves the Same Encounter

For each of the 60 diabetes follow-ups, Scribing.io emits a block-level FHIR Provenance resource per HPI and Assessment section. The audit response becomes a machine-verifiable export rather than a manual attestation scramble.

The operational takeaway is clear. The audit shifts from a labor-intensive Compliance investigation into a deterministic query. Every diabetes follow-up (E11.9) and every hypertension encounter (I10 (ICD-10-CM)) carries its own portable, signed lineage record.

The Block-Level Provenance Architecture Competitors Missed

The prevailing industry approach—and the gap left by the CMS Provenance framing—stops at "Author Organization" and "Author Time Stamp" for the note as a whole. That satisfies a checkbox but not an audit. The unaddressed engineering problem: how do you make Author-Role provenance granular, tamper-evident, and durable through export?

Scribing.io implements Author-Role at the block level with a specific, verifiable construction detailed below.

The critical differentiator is the final row. Competitors that generate any provenance typically lose it the moment content is copied between notes or exported for interoperability. By anchoring each Provenance resource to its section through Composition.section, the "Human-Verified" status travels with the clinical block.

This satisfies the exact "without special effort" condition the Cures Act Information Blocking rule contemplates. The recipient of an EHI export does not reconstruct authorship manually—the lineage arrives already attached and cryptographically bound.

Technical Reference: ICD-10 Documentation Standards

Provenance is only defensible when the underlying coded documentation is precise. The two highest-volume codes in ambulatory follow-up—and the two most frequently AI-drafted—are hypertension and Type 2 diabetes.

For these codes specifically, the Author-Role question compounds coding risk. If an AI drafts an E11.9 assessment but the encounter documents neuropathy, the human verifier's attestation is what corrects the specificity to E11.4x.

Block-level provenance records that the human reviewed that assessment—turning a silent AI error into a documented human correction with a signed timestamp. That correction record is itself audit evidence.

Implementation Sequence for Clinical Operations

A Clinical Operations Director deploying block-level provenance should sequence the rollout to protect the highest-volume, highest-recoupment-risk service lines first.

1. Map incumbent provenance depth first. Confirm whether current notes carry any section-level Author-Role data or only document timestamps.

2. Prioritize chronic follow-up encounters. Diabetes (E11.9) and hypertension (I10) drive the highest audit exposure per volume.

3. Bind attestation to the audio. Ensure the RFC3161 timestamp references source audio, not the EHR save event.

4. Validate export durability. Test an EHI export and confirm Composition.section provenance survives intact.

5. Document CPT G2211 linkage. Complexity add-on billing benefits from the same human-verified assessment lineage.

Configuration specifics per specialty vary; consult the EHR Integration Library for how Composition.section maps to your platform's note structure and export pipeline.

ROI and Recoupment Prevention

The financial case rests on avoided recoupment, not just documentation speed. In the audit scenario, 27 of 60 claims were recouped for a lineage gap that block-level provenance eliminates entirely.

To model your own exposure, apply your recoupment rate and average claim value against your chronic-care encounter volume using the AI Medical Scribe ROI Calculator.

Plan tiers and provenance feature availability are documented at Scribing.io Pricing & Plans. Block-level FHIR Provenance is a standard component of the Clinical-Grade Scribing configuration, not a premium add-on.

Compliance note: Author-Role provenance satisfies USCDI v5 data-lineage expectations and supports Information Blocking defensibility. It does not replace payer-specific medical-necessity documentation.