Information Blocking and Clinical Dental AI: What the 21st Century Cures Act Expects When an Agent Holds Patient Data

The information-blocking provisions of the 21st Century Cures Act have applied to health care providers since April 5, 2021, and since October 6, 2022 they have reached the full scope of electronic health information rather than the narrower USCDI data set. Enforcement then arrived in two waves — civil monetary penalties of up to $1 million per violation for certified health IT developers starting September 1, 2023, and CMS disincentives for providers finalized in 2024.

That said, most dental AI deployments were scoped before anyone asked who answers when a patient, a referring oral surgeon or a replacement practice-management system wants the data an agent is holding. This piece walks through how 45 CFR Part 171 reaches that data, where the practice carries the exposure, and what the architecture has to do so a vendor contract never becomes the reason a request stalls.

What Information Blocking Means Under 45 CFR Part 171

The Cures Act defines information blocking by its effect on the data, not by the intent behind a single decision. Accordingly, the regulation focuses on whether a practice is likely to interfere with access, exchange or use of electronic health information (EHI) and whether the actor had the required knowledge.

The rule names three categories of actors, and each one carries a different knowledge standard:

• Health care providers. A dental practice, DSO or group is an actor when it knows a practice is unreasonable and likely to interfere with access, exchange or use of EHI. That is a higher bar than the one developers face, but it is not a high one once a complaint or a written request puts the practice on notice.
• Developers of certified health IT. Any company that offers at least one ONC-certified Health IT Module is an actor across its whole business, not only the certified product. The standard here is that the developer knows, or should know, the practice is likely to interfere.
• Health information networks and exchanges. Entities that control the technology or terms for exchange among unaffiliated parties fall under the same knows-or-should-know standard as developers.

All of the above means the first question for any dental AI deployment is which of these boxes each party sits in. The answer decides who carries the liability when an agent-held record is slow, expensive or impossible to get out.

Who Is the Actor When an AI Agent Holds the Data?

Most dental AI vendors — caries detection, voice perio charting, phone agents, insurance verification — do not sell an ONC-certified Health IT Module and do not operate as a health information network. In that case the vendor is not an actor in its own right, and the regulatory weight lands on the practice that hired it.

Keep in mind that the vendor is still a HIPAA business associate holding protected health information on the practice's behalf. The practice signed the contract that governs export, retention and fees, so a restrictive term in that contract is evaluated as the practice's own conduct once the practice knows the term interferes with a request.

On the contrary, a vendor that does hold ONC certification for any product — common among larger EHR companies that also ship AI features — is directly exposed. For instance, an ambient-documentation add-on sold by a certified developer inherits the developer's actor status and its $1 million-per-violation ceiling, enforced by the HHS Office of Inspector General.

Which Agent Outputs Count as Electronic Health Information?

EHI is electronic protected health information to the extent it would be included in a designated record set under HIPAA. The designated record set covers medical and billing records plus any other records used, in whole or in part, by or for the practice to make decisions about individuals.

That definition reaches further into an agent pipeline than most teams assume. Here is how the artifacts a typical dental agent stack produces tend to fall:

Agent artifact	Likely EHI?	Reasoning
Signed clinical note summary	Yes	Once a provider signs it into the chart, it is part of the medical record.
Radiograph annotations and caries overlays	Yes, when relied on	If a clinician used the overlay to plan treatment, it was used to make decisions about the patient.
Voice perio charting transcript	Usually	The structured pocket depths are EHI; the raw audio depends on retention and use.
Eligibility and benefits breakdown	Yes	Billing and payment records sit inside the designated record set by definition.
Phone-agent call transcript	Depends	Scheduling chatter is borderline; a transcript capturing symptoms used for triage is not.
Vector embeddings and prompt logs	Unsettled	Derived, non-human-readable and regenerable, but ONC has not ruled on them directly.

Our working position is to treat every human-readable artifact a clinician could rely on as EHI and to document the embedding layer as a derivative index that can be regenerated from the source record. Note that this is a defensible operating posture, not settled guidance, so it belongs in your compliance file with the reasoning written down.

For more on how those indexes are built and scoped, our piece on vector databases for clinical AI covers retention and tenant boundaries. The same logic applies to clinical note summarization pipelines, where the draft-versus-signed distinction decides when an output enters the record.

Vendor Practices That Look Like Interference

ONC's commentary and FAQs describe interference broadly, including contract terms, fees, technical limits and delays. Some examples of vendor practices that put a dental practice in a difficult position include but are not limited to:

• PDF-only export. Handing back a flattened PDF when the data exists in structured form and the requestor asked for a machine-readable format is hard to square with the Manner exception. The practice is expected to offer the requested manner or a reasonable alternative in a defined order.
• Per-record export fees. Fees must be based on objective, verifiable criteria and reasonably related to the cost of providing access. A $25-per-patient export charge on a 9,000-patient practice is a $225,000 exit toll, and that is the pattern the Fees exception was written to stop.
• Delete-on-termination clauses. A contract that purges data 30 days after termination without a guaranteed export window effectively destroys the practice's ability to respond to future requests.
• Ownership claims over generated notes. Some agreements assert vendor rights in AI-generated output. If that output is in the chart, the practice cannot let a license term block a patient's access to it.
• Asymmetric rate limits. An export API throttled to 10 requests per minute while the vendor's own analytics jobs run unthrottled fails the consistent-and-nondiscriminatory test in the Health IT Performance exception.
• Review holds. Holding results until the vendor's QA team signs off adds delay without a privacy, security or harm rationale behind it.

Overall, none of these terms is automatically unlawful, and each one has a version that fits an exception. The problem is that most dental AI contracts were written for sales velocity, so the exception analysis was never done and nobody wrote it down.

The Exceptions You Will Actually Use

The regulation provides a set of exceptions, and an actor that meets every condition of one is not information blocking for that practice. In an agent deployment, a handful do nearly all of the work:

Exception	Where it applies to an agent	What you must document
Infeasibility	The request asks for data the system cannot segment or produce	A written response to the requestor within 10 business days stating why
Manner	The requestor wants a format you do not support	The alternative manner offered, following the regulatory order of preference
Fees	Bulk export, integration or third-party app access	Cost basis, uniform application and no fee for an individual's electronic access
Security	An unauthenticated app or suspicious request	A written security policy the denial ties back to, applied consistently
Privacy	Consent gaps, state-law limits or a patient's request not to share	The specific privacy rule or patient request relied on
Health IT Performance	Planned maintenance or a degraded agent endpoint	Duration no longer than necessary and nondiscriminatory scope

The Preventing Harm exception also exists, but it requires a reasonable belief that the practice will substantially reduce a risk of harm. In dental settings it rarely fits, so do not plan your request handling around it.

What's more, the Privacy exception connects directly to opt-out handling. If a patient asks that their data not be shared with a particular party, the request has to be recorded somewhere the agent can read it, which is the problem our post on patient opt-out tracking addresses.

How Information Blocking Differs From HIPAA Right of Access

The two regimes overlap, but they are enforced by different offices and run on different clocks. The HIPAA right of access, enforced by the Office for Civil Rights, gives an individual a copy of their records within 30 calendar days with one 30-day extension.

Information blocking has no fixed deadline. Instead, any unnecessary delay can be interference, and the rule protects requests from other providers, payers, health apps and anyone else with a lawful basis, not only the patient.

As a result, a dental practice that tunes its process to the 30-day HIPAA window can be compliant on one rule and exposed on the other. Our guide to HIPAA requirements for clinical dental AI covers the business associate side, and the state health privacy rules piece covers where state law tightens either one.

What Penalties Apply to a Dental Practice?

For providers, the Cures Act calls for appropriate disincentives rather than direct fines. The CMS rule finalized in 2024 ties them to federal programs, so the exposure depends on which programs a practice participates in:

• MIPS eligible clinicians. A clinician found to have committed information blocking receives a zero in the Promoting Interoperability performance category, which carries a meaningful share of the MIPS final score.
• Medicare Shared Savings Program. An ACO, ACO participant or ACO provider can be barred from the program for at least one year.
• Eligible hospitals and critical access hospitals. Hospital-based dental programs and oral surgery departments sit under the hospital's Promoting Interoperability exposure.

Be aware that many private dental practices bill too little Medicare to fall inside MIPS, so the direct financial disincentive may never reach them. However, an OIG determination is still a public finding, a referring hospital system will notice it, and a certified-developer vendor in the same chain faces up to $1 million per violation.

Additionally, the information-blocking analysis often surfaces alongside other compliance reviews. Our posts on Section 1557 and patient decision tools and on state dental board AI rules cover the adjacent obligations a regulator or auditor tends to ask about in the same meeting.

How to Architect an Agent That Never Gates the Record

The cleanest defense is an architecture where the agent never becomes the only place a piece of EHI lives. Here is how we build that into a NexV deployment:

• Write back to the system of record. Every signed note, chart entry and verified benefit lands in the practice-management system, so a request to Dentrix, Eaglesoft or Open Dental returns it without touching the agent. Our posts on idempotent PMS write-back and the Open Dental API cover the mechanics.
• Ship a documented, machine-readable export. Structured data goes out as JSON and CSV with a published schema, and imaging goes out as DICOM with the annotations preserved, as covered in our DICOM interoperability guide. A practice administrator can trigger it without filing a support ticket.
• Keep a request ledger. Each inbound request is written to a DynamoDB table with the requestor type, the data scope, the timestamp and any exception invoked. An EventBridge Scheduler rule fires at business day 7 so the 10-business-day Infeasibility response never slips.
• Scope export by tenant. Bulk export runs inside the same tenant boundary as inference, using per-practice KMS keys, so one DSO location's export cannot leak another's patients. Our post on multi-tenant isolation covers the IAM and key layout.
• Log the exception decision, not just the outcome. CloudTrail tells you an object was read; it does not tell an auditor why a request was denied. The ledger entry carries the exception name and the written rationale.

All of these controls add up to a simple property: if the agent disappeared tomorrow, every piece of EHI it produced would still be retrievable from the chart or the export within a business day. That is the property an auditor is actually testing for.

Questions to Put to Your AI Vendor Before Renewal

Renewal is the cheapest moment to fix a gating term, because the vendor wants the signature. Before you sign, get written answers to the following:

• Certification status. Does the company or any affiliate offer an ONC-certified Health IT Module? If yes, the vendor is an actor and should already have an information-blocking policy you can read.
• Export format and cost. What formats are available, is the schema published, and is the fee tied to a stated cost basis?
• Termination terms. How many days after termination is a full export guaranteed, and in what format?
• Ownership of output. Does the contract claim any right in generated notes or annotations that sit in the chart?
• Request routing. If a third party sends a request directly to the vendor, how fast is it forwarded to the practice, and is that logged?
• Audit evidence. Will the vendor share SOC 2 Type II results covering the export path, as discussed in our piece on SOC 2 for clinical vendors?

Remember that a vague answer to any of these is itself a finding. The practice carries the knowledge standard, and a written question with a written non-answer is exactly the kind of record that establishes what the practice knew.

Bringing Your Agent Stack Into Part 171 Alignment

Information blocking is the compliance layer most dental AI rollouts skipped, largely because the vendor was not an actor and nobody on the practice side mapped what the agents produce. Once that mapping exists, the fixes are mostly contractual and architectural, and few of them are expensive.

If you are auditing an existing dental AI contract against Part 171 or scoping a new agent deployment, the NexV team builds and operates HIPAA-grade clinical agents against Dentrix, Eaglesoft and Open Dental every week. Reach out for a working session — we will inventory every artifact your agents produce, mark which ones are EHI, and leave you with an export path and request ledger you can put in front of an auditor.