Posted on
Feb 9, 2025
Posted on
Aug 7, 2026
HTI-2 mandates EHI Export with provenance for AI scribes. Learn what CMIOs must verify before 2026 to avoid information blocking penalties.
TL;DR: HTI-2 Compliance for AI Scribes in 90 Seconds
The Rule: The ONC HTI-2 Final Rule (2026) requires AI documentation tools to support EHI Export standards so patients and clinics can move AI-generated history to any certified health app—no information blocking.
The Gap Most Vendors Miss: HTI-2 EHI Export isn't "notes out." It demands verifiable provenance. Competitors ship PDF/text dumps; those fail trust and ingestion tests.
Scribing.io's Edge: EHI-ready NDJSON attaches a FHIR Provenance record to every DocumentReference/Composition, linking each generated sentence to the original audio timestamp, a SHA-256 hash of the audio file, and the model build ID (DSI transparency).
Why It Matters to Clinical Ops: One-click Single Patient
$exportmeans same-day imports, zero rework, and no information-blocking complaint exposure.
The Data Portability Rule Explained
Why EHI Export Demands Provenance
Clinical Logic: Diabetic Foot Ulcer Transfer
ICD-10 Documentation Standards
Operations Rollout & Pricing
ONC HTI-2 Compliance for AI Scribes: The Data Portability Rule Explained
CLINICAL UPDATE 2026: Revised for new CMS CPT G2211 standards, SB 1120 compliance, and FHIR interoperability.
For a Clinical Operations Director, the ONC HTI-2 Final Rule (2026) reframes the AI scribe from a convenience tool into a regulated node in the interoperability chain. HTI-2 extends the information-blocking framework so that AI-generated clinical documentation must be exportable under Electronic Health Information (EHI) Export standards—meaning a patient or a receiving clinic can move that AI-authored history into any certified health app without a vendor obstructing the transfer.
The practical test is simple: Can your scribe hand off a complete, machine-readable, trustworthy record on demand? Scribing.io answers this with EHI-ready JSON exports built on FHIR profiles. Before evaluating the provenance architecture below, confirm scope using our Clinical Specialties Directory and validate destinations through the EHR Integration Library.
Three regulatory pressures converge here. SB 1120 (California) constrains how AI influences clinical decisions and mandates disclosure of AI authorship. CMS CPT G2211 now attaches to longitudinal care continuity—which auditors expect documented across transfers. HTI-2 supplies the transport standard that binds these obligations together.
Beyond "Notes Out": Why EHI Export Demands Provenance
The prevailing industry conversation—reflected in federal FAQ pages and vendor marketing—treats EHI Export as an interoperability plumbing exercise: expose an API, pass a conformance test, ship the data. What that framing quietly omits is the trust layer. An AI scribe does not merely transcribe; it generates clinical language.
Under HTI-2, moving generated text is only half the obligation. The receiving clinician must be able to verify where each sentence came from. This is Scribing.io's foundational insight: HTI-2's EHI Export requires verifiable provenance, not just data mobility.
Our EHI-ready NDJSON attaches a FHIR Provenance resource to every DocumentReference and Composition. Each provenance record cryptographically and temporally links generated text back to three anchors:
Audio timestamp anchoring — the exact moment in the encounter recording that produced the statement.
SHA-256 hash of source — a tamper-evident fingerprint proving the note derives from a specific, unaltered recording.
Model build ID transparency — satisfying Decision Support Intervention (DSI) expectations by identifying which AI version authored the text.
What HTI-2 EHI Export Requires vs. What Most Vendors Ship | ||
Capability | Typical Competitor (PDF/Text Dump) | Scribing.io (Provenance-Anchored NDJSON) |
|---|---|---|
Machine-readable structure | Flat PDF / free text | US Core FHIR NDJSON |
Discrete clinical data | Buried in prose | Discrete US Core resources |
Source audio linkage | None | SHA-256 hash + timestamp per statement |
AI model transparency (DSI) | Not disclosed | Model build ID in Provenance |
Same-day trusted ingestion | Manual re-entry required | Direct import, verifiable |
The competitor gap is not that they lack an export button—it's that a text dump cannot be trusted or ingested discretely. That failure is exactly what converts a routine transfer of care into an information-blocking exposure.
Clinical Logic: Trusted Transfer for a Diabetic Foot Ulcer Patient
Consider the operational reality this rule is designed to prevent.
The Scenario
A 58-year-old patient with a Type 2 diabetic foot ulcer completes a debridement planning visit, then transfers care to a new clinic. The prior encounter was documented by an incumbent AI scribe producing only PDF output—no HTI-2 EHI Export, no provenance.
The Failure Cascade
The new clinic cannot trust or ingest the prior AI note. There is no way to verify ulcer staging or the antibiotic regimen against a source recording, so staff:
Re-enter ulcer staging and antibiotics from memory, introducing clinical risk and delaying treatment.
Order duplicate imaging because prior results can't be trusted—generating an unnecessary patient bill.
Trigger an information-blocking complaint because the incumbent effectively obstructed a compliant transfer.
The Scribing.io Resolution
With Scribing.io, staff trigger a one-click Single Patient $export. The resulting NDJSON bundle is imported by the receiving clinic the same day, with no complaint exposure and no rework.
Transfer-of-Care Workflow: Incumbent Scribe vs. Scribing.io | ||
Step | Incumbent AI Scribe | Scribing.io |
|---|---|---|
Export trigger | Manual PDF print/download | One-click Single Patient |
Ulcer staging (L97.509 / E11.621) | Free text — re-entered from memory | US Core |
Antibiotic regimen | Re-entered from memory | US Core |
Clinical note | Untrusted PDF |
|
Verification | None | FHIR |
Outcome | Delay, duplicate bill, complaint | Same-day trusted import, zero rework |
The Provenance record is what allows the receiving clinician to accept the ulcer stage and antibiotic history without re-verification—because each statement traces to an unaltered audio source and an identified model build. That is the difference between "data received" and "data trusted."
Technical Reference: ICD-10 Documentation Standards
Accurate, exportable documentation for diabetic foot ulcers depends on discrete coding that survives the FHIR export intact. The two codes central to the scenario above map directly to US Core Condition resources in the NDJSON bundle.
ICD-10-CM Reference: Diabetic Foot Ulcer Documentation | |||
Code | Description | Documentation Notes | Reference |
|---|---|---|---|
E11.621 | Type 2 diabetes mellitus with foot ulcer | Establishes causal diabetic etiology. Use an additional code to identify site and severity of the ulcer. | |
L97.509 | Non-pressure chronic ulcer of unspecified foot, unspecified severity | Codes the ulcer itself; sequence after E11.621 to preserve etiology-manifestation ordering. |
Both codes serialize as discrete US Core Condition entries, each carrying its own Provenance pointer. When the receiving clinic ingests the NDJSON, the etiology-manifestation pairing arrives intact—not flattened into a prose sentence that a human must re-abstract.
Operations Rollout & Pricing
For the Clinical Operations Director, HTI-2 readiness is a procurement checklist item, not a future project. Confirm your scribe exports discrete FHIR resources, attaches provenance, and supports the Single Patient $export operation before signing.
Model the financial exposure directly. Duplicate imaging, re-abstraction labor, and information-blocking penalties compound quickly across a transferring patient population. Quantify avoided cost using the AI Medical Scribe ROI Calculator.
Match deployment scale to volume and review deployment tiers against your transfer-of-care frequency at Scribing.io Pricing & Plans. Provenance-anchored export is standard across every tier—not an add-on.
Verify destination compatibility early. Cross-check your receiving EHR endpoints against the EHR Integration Library, and map in-scope service lines through the Clinical Specialties Directory.


