TL;DR: A clinic that wants its clinicians to use an AI agent inside the EHR must today get the EHR vendor to agree, and the information blocking exceptions give the vendor a long series of permitted ways to price, redirect, and decline. ONC should stop treating this as a request to the vendor. A condition of certification should say that a customer may have software of its choosing operate the EHR’s ordinary screens, under a clinician’s login or an account the customer sets up for it, with no separate license, fee, or vendor approval. Draft regulatory text is below.

Agents that operate software the way a person does (reading the screen, clicking, typing) now work well enough to read through a chart before a visit, draft the note, and queue orders for a clinician to sign. For a practice this is a tool, like dictation software, or a new assistant who needs a login. For the regulations it is something else: a third party asking an EHR vendor for access, which starts a process built for a different problem.

The story below is fiction. The clinic, the startup, and the vendor are invented, and the calendar is stylized. Every step the vendor takes is one the current rules allow.

The request

Three parties are involved.

• The clinic. Cedar Street Family Medicine has six clinicians and a large Medicare panel. Its owner, Dr. Okafor, wants help preparing for annual wellness visits.
• The developer. Maya founded Pencilwork, a four-person startup. Its agent works the EHR’s screens the way a staff member would, under whatever account the clinic gives it.
• The vendor. Cedar Street’s EHR is cloud-hosted by a company I’ll call Quillon.

Before each annual wellness visit, the agent reviews how the patient has been doing since the last one: the visit notes, labs, and outside records, plus every portal message the patient has sent. It checks the practice’s health maintenance list for screenings and vaccines that are due. It then drafts a pre-visit summary and a draft prevention plan in the clinician’s queue and pends the due orders for signature. It never sends or signs anything.

EHR vendors already sell AI tools that draft replies to patient messages. This is different work: it cuts across the whole chart, and a small practice might reasonably want it from a specialist rather than wait for its vendor to build it.

Two things the agent needs are one click away on the EHR’s screens but outside USCDI, the standard data set that certified FHIR APIs must serve: the patient’s message history and the health maintenance list. No version of USCDI through v7 includes either.

Cedar Street has signed a pilot agreement and a HIPAA business associate agreement with Pencilwork. It wants the agent, will pay for it, and takes responsibility for it. Only the vendor is left.

Day counts are business days. Dark pills are periods the regulations set; dashed pills are periods with no limit, where the story assumes a plausible wait.

What each step sounds like

Each step of the diagram as a short exchange. Open any one to read it.

Days 0 to 8: the license

Customer license agreement · a contract term, with no clock for answering

Dr. Okafor: We'd like our clinicians to use an AI agent in the EHR. It would work under their logins, or under its own account with a limited role if you prefer. Can you confirm that's fine?

Quillon account manager: Section 4.2 of your agreement prohibits access "by automated means, including scripts, bots, or robotic process automation" and any access by third parties without our written consent. Third parties go through Partner Programs. I've sent them your developer's name.

Days 9 to 34: the manner requested

§171.301(a) Manner exception · no time limit

Maya: We're requesting that Cedar Street's clinicians be allowed to operate Quillon's screens through our agent, under accounts the clinic authorizes.

Dana, Partner Programs: Happy to help. The program is $25,000 a year, plus four cents per automated interaction, plus 12% of revenue from joint customers. You'll grant us a license to feedback and improvements. Security review has a ten-week queue.

Maya: A fee based on my revenue is barred by the Fees exception, and an IP grant-back is barred by the Licensing exception.

Dana: Those conditions apply when we fulfill a request in an alternative manner. For the manner you requested, §171.301(a)(2) says our fees and licenses don't have to meet them. These are our market terms.

Dana, a week later: Also, please stop the demo sessions. Our written security policy flags scripted input, and the test account has been locked.

Three rounds of redlines follow. Dana is right about the rule text: the cost-based, nondiscriminatory conditions sit in the Fees and Licensing exceptions, and the Manner exception applies them only to an alternative manner. ONC has said it expects "market" terms for the manner requested and that unconscionable terms could still be information blocking, but its proposal to write that into the rule was deferred. As codified, the parties need only fail to "reach agreeable terms," with no deadline for finding that out. The lockout is defended under the Security exception, §171.203.

Days 34 to 39: the alternative manner

§171.301(b) · "without unnecessary delay"

Dana: Since we couldn't agree, we'll fulfill your request in an alternative manner. First in the order of priority is certified technology. That's our FHIR API.

Maya: The agent needs each patient's message history and the health maintenance list. Neither is in USCDI, so neither is in your FHIR API.

Dana: It's what the order of priority gives us. If it doesn't meet your needs, we can discuss a flat-file extract next.

Days 39 to 54: app registration

§170.404(b)(1) API condition · 10 business days to verify the developer, 5 more to enable the app

Maya: Fine. We'll take the API so we can at least start testing chart retrieval.

Dana: There's no charge to you for the certified API. We'll verify your company within ten business days and enable the app within five after that.

The app is enabled on day 54. This is the one step where the rules give the developer a firm, short deadline and a price of zero, because the certified API has its own condition of certification.

Days 54 to 70: the missing data, and write access

§171.204(a)(3) and (b) Infeasibility exception · written response within 10 business days

Maya: The API returns medications, problems, labs, and notes. It has no message history and no health maintenance list, and it can't save a draft pre-visit note or pend the screenings that are due. Those are the product.

Dana, ten business days later, in writing: For the messages, we can offer a nightly flat-file extract as a further alternative manner; licensing it would take up to 30 business days. Saving draft notes and pending orders is a request to use EHI in order to modify EHI, and you are a third party. That is infeasible under the "third party seeking modification use" condition.

Maya: A nightly file misses the message the patient sent this morning about the visit. So there is no path?

Dana: The modification condition doesn't apply when a health care provider asks its own business associate. Cedar Street could make the request.

The 30-business-day window for the extract comes from the Licensing exception, §171.303(a): 10 business days to open negotiations and 30 to conclude.

Days 71 to 95: the same ladder, a new requester

§171.301 again, then §171.204(a)(4) Manner exception exhausted

Dr. Okafor: Then I'm asking. Let my clinicians use this agent. I'll provision it like any other staff account.

Quillon account manager: We can amend section 4.2 with our Automation Enablement add-on: $90 per clinician per month, usage caps, and you indemnify us for anything the agent does.

Dr. Okafor: That's more than we pay for the EHR seat. No.

Quillon, ten business days later, in writing: We could not reach agreement on the manner requested. We have offered two alternative manners, the certified API and a flat-file extract. We do not provide the requested access to a substantial number of similarly situated customers. The request is infeasible.

Day 96: the complaint

42 U.S.C. 300jj-52 · no deadline for a decision

Maya and Dr. Okafor file an information blocking complaint through ONC's portal. The confirmation email has a case number and no timeline.

The same month, Quillon announces Quillon Assist, its own agent, at $149 per clinician per month.

What the story shows

The process took more than four months and produced a chart-retrieval integration that can’t see the message history or the screening schedule the visit prep depends on. Of the 96 business days, 35 were periods the regulations themselves provide: 15 days for app registration and two 10-day response periods. The other 61 were waits with no limit at all.

No single step is the problem. Each exception was written for a reasonable case: a vendor shouldn’t have to build every custom interface on demand, should be able to recover costs, license its technology, and protect security. Stacked together, and applied to a request that asks the vendor to build nothing, they become a procedure whose default outcome is delay.

The requester needs a lawyer at every step. Whether terms were at “market,” whether an extract’s royalty is “reasonable,” whether a lockout was “tailored” are all judgments made first by the vendor and reviewed, if ever, after a complaint.

The pending HTI-5 proposals would help only at the edges. ONC proposed to say outright that “access” and “use” include robotic process automation and agentic AI, to remove the third-party modification condition, and to add contract-fairness tests to the Manner exception. The October final rule deferred all of it. Even if finalized, the proposals leave the structure in place: the agent’s developer is still a requester, the vendor still controls an “interoperability element,” and the Licensing and Fees exceptions still frame the negotiation.

A different premise: the agent works for the customer

Go back to the first scene. Before anyone made a “request,” Cedar Street already had everything it needed: licensed seats, a way to create accounts and assign roles, and screens that show each account what its role allows. The agent needs nothing the clinic couldn’t give a new staff member. It asks the vendor to build nothing and to disclose nothing new.

So the rule should start there: when software operates the EHR’s ordinary client, by whatever means, under an account the customer has authorized and within that account’s permissions, it is the customer’s own use. No request to the vendor exists, so no exception process begins.

The customer can set this up in either of two ways, and both have long-standing precedents.

• In a clinician’s own session. The agent works alongside the clinician with exactly that clinician’s access. Speech recognition, text expanders, and screen readers already operate EHR screens this way, and nobody thinks the dictation vendor needs a license from the EHR vendor.
• Under its own account. The customer provisions the agent as it would a scribe, a student, or a medical assistant: a named account, a role limited to the job, and a sponsoring clinician who reviews and signs. The agent’s actions are logged separately, and its access can be narrower than any clinician’s and revoked on its own.

The second model will often be the better one, because it reuses the provisioning, role, and audit systems health systems already run. The rule should protect both and let the customer choose.

This keeps authority where it belongs.

• The health system or practice decides. It is the vendor’s customer and the HIPAA covered entity. It chooses which agents may be used, signs the business associate agreement with the agent’s supplier, and can say no. An employed physician gets no right to override their organization.
• The clinician stays accountable. The agent can see and do only what its account allows. Everything it does is logged, and the clinician who signs answers for it as they do for a scribe’s draft or a dictated note.
• The vendor keeps its product. It may secure access, manage load, and price by usage, as long as the rules are the same whether a person or a program is at the controls. It does not have to support, test, or warrant anyone’s agent.

Proposed regulatory text

The rule would sit in the conditions every certified EHR developer already agrees to. One of them, the Assurances condition, has developers promise not to engage in information blocking “or any other action that may inhibit” access to and use of health data. That broader promise doesn’t run through the information blocking exceptions, so a vendor can’t answer it with the licensing and fee process from the story. ONC has built on it before, to require full-record export. The mechanics borrow from another condition that already bars developers from gagging customers who talk about their software: an annual notice that contrary contract terms won’t be enforced, and no new contracts containing them.

In plain terms, a certified developer would have to:

• Let a customer have software of its choosing operate the product’s ordinary interfaces, under a clinician’s account or an account the customer sets up for the software, within that account’s permissions.
• Let customers create, restrict, and deactivate accounts for software with the same tools and terms they use for staff.
• Require no separate license, agreement, registration, fee, or approval from the customer or the software’s supplier.
• Price and limit use only by published measures that apply the same way to people and software.
• Not treat the software’s view of the screens as a breach of confidentiality or intellectual property terms.
• Tell customers each year that contrary contract terms won’t be enforced, publish its policy, and attest to all of this twice a year.

Actions taken through the software count as the customer’s, and the developer owes the software no support. A sentence added to the information blocking definitions says that operating an interface the customer already has is not a separately licensable “interoperability element.”

The draft text, for discussion:

Four choices in this text are worth explaining.

• It asks vendors to build nothing. No new certification criterion, no test procedure, no standard. The accounts paragraph only stops a vendor from excluding software from the account tools it already offers. That fits a deregulatory program and takes effect as soon as contracts stop being enforced.
• It covers the whole product, not just certified functions. HTI-5 is shrinking the list of certified functions, so a rule tied to “certified capabilities” would shrink with it. The definition follows the EHI Export approach: any product that includes a certified module.
• It allows usage pricing. Per-seat pricing assumes a person’s pace. A vendor can charge an agent that works overnight for the load it creates, provided a person creating the same load pays the same, and an account costs the same whoever operates it. How vendors restructure their price lists is for them and their customers to work out.
• The responsibility clause is modest on purpose. ONC can’t rewrite tort law. It can say that, inside the certification program, what the agent does is the customer’s action and not the developer’s nonconformity, and that the developer owes the agent no support.

Objections

“A hallucinating agent will write garbage into the chart.” The agent can do only what its account’s role permits, and the customer can make that role as narrow as it likes: draft but not sign, pend but not send. Whether drafts need review before signing is a clinical governance question for the organization deploying the agent, the same one it already answers for scribes, students, and templates.

“Agents will overload the system.” Performance rules that apply to every account remain available, and so does usage pricing. What goes away is a limit that applies only because a program is at the controls.

“Clinicians will hand their passwords to a third party.” They don’t have to. The customer can give the agent its own account, with its own credentials, a limited role, and a sponsoring clinician, exactly as it would for a new scribe. That is safer than password sharing and uses the access controls the vendor already built. Where the agent instead works inside a session the clinician opened, no credential changes hands at all. In both cases the supplier is the customer’s business associate, and the customer can cut off the agent’s access without touching anyone else’s.

“Our interface is our intellectual property.” It is, and the proposal leaves copying and competing-product restrictions alone. It removes one use of those terms: declaring that a customer’s own tool looking at the customer’s own screens is a breach.

“ONC lacks authority to regulate license terms.” Certification is voluntary, and ONC already regulates developers’ contracts under the Communications condition and their fees under the API condition. The statutory phrase “any other action that may inhibit” appropriate access and use is broad, and this is a direct application of it.

“Retailers and airlines are fighting agents too. Why should EHR vendors be treated differently?” In September Amazon blocked Meta’s Muse shopping agent, saying Meta gave no notice and the agent never identified itself as an AI. Amazon has also sued Perplexity over its shopping agent, though an appeals court has since sided with Perplexity. And this week United Airlines changed its contract of carriage to bar AI agents from booking or changing tickets, citing security, while Delta, American, and JetBlue let customers decide. This post takes no position on those fights, because health care differs in four ways.

• Congress has already decided the question for health data. The Cures Act prohibits interfering with access to and use of electronic health information, and makes that a condition of EHR certification. Retail and travel have no such statute.
• The customer is a licensee, not a visitor. A shopper’s agent arrives at a free storefront whose business depends on the visit. A clinic pays for its EHR and runs its own operations on it, and the records inside are the clinic’s and its patients’. The vendor holds them as the clinic’s business associate. The closer analogy is a company automating its own accounting system.
• The customer can’t walk away. A shopper can buy elsewhere in a minute. A practice that dislikes its vendor’s agent policy faces a migration measured in months or years and a real risk to its records.
• The agent is identified. Amazon’s complaint about Muse was that it never said it was an AI. Here the agent runs under an account the customer provisions, with its own role and its own audit trail.

What this does for APIs

This proposal is not a retreat from standards-based APIs. An agent clicking through screens is slow and brittle compared with a good API, and both vendors and developers would rather use one. But today the vendor’s alternative to offering a good API is offering nothing. If customers can always fall back on the screens they already pay for, the vendor’s best move is to offer something better: a faster, safer, fairly priced API or MCP server that agents prefer. ONC’s planned work on write APIs and automation in its next rulemaking would build on that floor.

Patients face the same problem with portals, and the same principle should apply there. I’ve written about that separately. This proposal covers clinicians and the organizations that license EHRs.

---

Sources: 45 CFR Part 171 · 45 CFR Part 170, Subpart D · HTI-5 proposed rule, 90 FR 60970 · HTI-5 final rule · SMART Health IT comments on HTI-5