一位开发者提议：AI代理操作EHR，不必再经供应商批准
TL;DR：如今，一家希望让临床医生在EHR中使用AI代理的诊所，必须征得EHR供应商的同意，而信息屏蔽例外条款给了供应商一系列被允许的定价、引导和拒绝的方式。ONC不应再把这视为向供应商提出的请求。认证条件应规定，客户可以让自己选择的软件操作EHR的常规界面，既可以是在临床医生的登录名下，也可以是在客户为该软件设定的账户下，无需单独的许可、费用或供应商批准。以下是拟议的监管文本。
我的博客上有更大、更清晰的图表版本：joshuamandel.com/blog/posts/ai-agents-as-ehr-users-without-vendor-permission
以人的方式操作软件（阅读屏幕、点击、输入）的代理，如今已经足够好用，可以在就诊前通读病历、起草记录，并将医嘱排队供临床医生签名。对诊所而言，这是一种工具，就像听写软件，或一个需要登录账户的新助理。但对监管而言，它是另一回事：一个第三方请求EHR供应商授予访问权限，这会启动一套为完全不同问题设计的流程。
下面的故事是虚构的。诊所、初创公司和供应商都是虚构的，日历时间也是风格化的。供应商采取的每一步都是现行规则所允许的。
请求
诊所。Cedar Street Family Medicine有六名临床医生和大量Medicare患者。诊所所有者Okafor医生希望为年度健康访视的准备获得帮助。
开发者。Maya创办了Pencilwork，一家四个人的初创公司。它的代理像员工一样操作EHR界面，使用诊所分配给它的任何账户。
供应商。Cedar Street的EHR由一家我称之为Quillon的公司进行云托管。
在每次年度健康访视之前，代理会查看患者自上次访视以来的情况：就诊记录、化验结果和外部记录，以及患者发送的每一条门户消息。它会检查诊所的健康维护清单，看看有哪些筛查和疫苗到期。然后，它在临床医生的队列中起草一份访视前摘要和一份预防计划草稿，并将到期的医嘱挂起等待签名。它从不发送或签署任何内容。
EHR供应商已经在销售能为患者消息起草回复的AI工具。这是不同的工作：它涉及整个病历，而一个小型诊所理应从专业公司获得这种能力，而不是等待其供应商来开发。
代理所需的两项信息在EHR界面上只需点击一下即可获得，但不在USCDI（认证FHIR API必须提供的数据集）之中：患者消息历史和健康维护清单。目前到v7为止，没有任何版本的USCDI包含这两项。
Cedar Street已与Pencilwork签署了试点协议和HIPAA业务伙伴协议。它想要这个代理，愿意为其付费，并对其负责。只剩下供应商这一关。
天数按工作日计算。深色圆圈是法规设定的时间；虚线圆圈是没有限制的时间，故事中假定为合理的等待。
图中的每一步都有一段简短的剧本式对话，展示实际情形。请在我的博客上阅读。
这个故事说明了什么
整个过程耗时四个多月，最终获得的病历检索集成无法看到就诊准备所依赖的消息历史或筛查安排。在96个工作日中，35天是法规本身规定的期限：15天用于应用注册，两个10天响应期。其余61天是完全没有任何限制的等待。
没有哪一步是问题所在。每条例外都是为合理情况而写：供应商不应被要求按需构建每一种自定义界面，应当能够收回成本、授权其技术并保护安全。但当它们叠加在一起，应用于一个不要求供应商构建任何内容的请求时，它们就变成了一个默认结果是拖延的程序。
请求者在每一步都需要律师。条款是否处于“市场水平”、提取数据的版税是否“合理”、锁定是否“有针对性”，这些判断首先由供应商作出，并且（如果有的话）也只在投诉之后才被审查。
尚未定案的HTI-5提案只会带来边缘性的帮助。ONC曾提议直接说明“访问”和“使用”包括机器人流程自动化与智能体AI，删除第三方修改条件，并在方式例外中加入合同公平性测试。十月的最终规则将所有这一切都推迟了。即使最终定稿，这些提案也保留了原有结构：代理开发者仍是请求者，供应商仍控制着一个“互操作元素”，许可和费用例外仍然框定着谈判。
一个不同的前提：代理为客户工作
回到第一个场景。在任何人提出“请求”之前，Cedar Street已经拥有所需的一切：已授权的席位、创建账户和分配角色的方法，以及向每个账户展示其角色权限的界面。代理需要的任何东西，诊所都能像提供给新员工一样提供。它不要求供应商构建任何东西，也不要求披露任何新内容。
所以规则应该从这里入手：当软件以任何方式操作EHR的普通客户端，使用客户已授权的账户并在该账户的权限范围内时，这就是客户自身的用途。不存在对供应商的请求，因此也不会启动例外流程。
客户可以通过两种方式中的任何一种进行设置，两者都有长期先例。
在临床医生自己的会话中
代理与临床医生并肩工作，完全使用该临床医生的访问权限。语音识别、文本扩展器和屏幕阅读器已经以这种方式操作EHR界面，没有人认为听写软件供应商需要从EHR供应商那里获得许可。
在自己的账户下
客户像配置一名抄写员、学生或医疗助理那样为代理配置：一个具名账户、一个仅限于该工作的角色，以及一名负责审核和签名的发起临床医生。代理的行为被单独记录，其访问权限可以比任何临床医生更窄，并且可以单独撤销。
第二种模式通常更好，因为它复用了卫生系统已经运行的配置、角色和审计系统。规则应同时保护两种模式，并让客户自行选择。
这使权力各归其位。
卫生系统或诊所做出决定。它是供应商的客户，也是HIPAA所涵盖的实体。它选择可以使用哪些代理，与代理供应商签署业务伙伴协议，并可以说“不”。受雇的医生无权推翻其组织的决定。
临床医生保持责任。代理只能看到和做其账户允许的事情。它做的一切都会被记录，签名的临床医生要为其负责，就像为抄写员的草稿或听写记录负责一样。
供应商保留其产品。它可以保护访问、管理负载并按使用量定价，只要规则对人和程序一视同仁。它不需要支持、测试或保证任何人的代理。
拟议的监管文本
该规则将纳入每个认证EHR开发者已经同意的条件之中。其中一项“保证条款”要求开发者承诺不参与信息屏蔽，“或任何其他可能抑制”卫生数据访问和使用的行为。这一更广泛的承诺不经过信息屏蔽例外条款，因此供应商不能以故事中的许可和费用流程来回应。ONC此前已基于该条款要求完整记录导出。其机制借鉴了另一项已禁止开发者通过合同阻止客户谈论其软件的条件：每年通知客户，相反的合同条款将不予执行，并且不得再签署包含这些条款的新合同。
草稿在保证条款（§170.402）中增加一段，并在信息屏蔽定义（§171.102）中增加一句。通俗地说，认证开发者将必须：
- 允许客户让所选软件操作产品的普通界面，可以在临床医生账户下，也可以在客户为该软件设立的账户下，并限于该账户的权限范围内。
- 允许客户使用与员工相同的工具和条款，为软件创建、限制和停用账户。
- 不得要求客户或软件供应商提供单独的许可、协议、注册、费用或批准。
- 只能以适用于人和软件的相同方式的公开措施来定价和限制使用。
- 不得将软件查看界面的行为视为违反保密或知识产权条款。
- 每年告知客户与之相反的合同条款将不予执行，公布其政策，并每半年对这些事项进行证明。
通过软件采取的行动视为客户的行为，开发者对该软件不承担支持义务。Part 171中的那句话表明，操作客户已有界面不是一个可单独许可的“互操作元素”。完整的草稿文本在我的博客上。
草稿中的四个选择值得解释
它要求供应商不构建任何东西。没有新的认证标准、没有测试程序、没有标准。账户段落仅仅阻止供应商将软件排除在其已提供的账户工具之外。这符合放松管制的方针，并且一旦合同停止执行就立即生效。
它覆盖整个产品，而不仅仅是认证功能。HTI-5正在缩小认证功能清单，因此与“认证能力”绑定的规则会随之缩小。该定义遵循EHI导出方法：任何包含认证模块的产品。
它允许按使用量定价。按席位定价假设的是人的操作速度。供应商可以对夜间工作的代理按它产生的负载收费，前提是产生相同负载的人支付同样的费用，而且无论谁操作，账户费用相同。供应商如何重构其价格表，由他们与客户共同协商。
责任条款刻意保持适度。ONC不能改写侵权法。它可以说，在认证计划内，代理的行为是客户的行为，而不是开发者的不合规行为，而且开发者对该代理不承担支持义务。
反对意见
“会产生幻觉的代理会把垃圾写进病历。”代理只能做其账户角色允许做的事，客户可以将该角色设置得尽可能窄：起草但不签名，挂起但不发送。草稿在签名前是否需要审核，这是部署代理的组织面临的临床治理问题，它已经为抄写员、学生和模板回答过同样的问题。
“代理会使系统过载。”适用于每个账户的性能规则仍然有效，按使用量定价也同样有效。消失的只是仅仅因为程序在操作就适用的限制。
“临床医生会把密码交给第三方。”他们不必这样做。客户可以像为新抄写员配置一样，给代理一个自己的账户、自己的凭证、一个受限角色和一名发起临床医生。这比共享密码更安全，并且利用了供应商已经构建的访问控制。如果代理是在临床医生打开的会话中工作，则完全不需要移交凭证。在两种情况下，供应商都是客户的业务伙伴，客户可以在不影响其他人的情况下切断代理的访问。
“我们的界面是我们的知识产权。”确实如此，提案不涉及复制和竞争产品的限制。它只是移除这些术语的一种用法：即宣布客户自己的工具查看客户自己的屏幕构成违约。
“ONC无权监管许可条款。”认证是自愿的，ONC已经根据通信条款监管开发者的合同，并根据API条款监管其费用。法规中的“任何其他可能抑制”适当访问和使用的行动这一短语范围很广，这正是对它的直接应用。
“零售商和航空公司也在对抗代理。为什么EHR供应商应受到不同对待？”九月份，亚马逊屏蔽了Meta的Muse购物代理，称Meta没有发出通知，而且代理从未表明自己是AI。亚马逊还起诉了Perplexity的购物代理，不过此后一家上诉法院站在了Perplexity一边。本周，美国联合航空修改了运输合同，以安全为由禁止AI代理预订或更改机票，而达美、美航和捷蓝航空则让客户自行决定。本文对这些纠纷不持立场，因为医疗保健在四个方面有所不同。
国会已经为健康数据决定了这个问题。《治愈法案》禁止干扰电子健康信息的访问和使用，并将其作为EHR认证的条件。零售和旅行没有这样的法规。
客户是被许可人，不是访客。购物者的代理来到的是一个免费的店面，其业务依赖于这次访问。诊所为其EHR付费，并在其上运行自己的运营，里面的记录属于诊所及其患者。供应商作为诊所的业务伙伴持有这些记录。更接近的类比是一家公司自动化自己的会计系统。
客户无法轻易离开。购物者一分钟后就可以去别处购买。不喜欢供应商代理政策的诊所面临的迁移以月或年计，并且其记录面临真实风险。
代理是身份明确的。亚马逊对Muse的不满在于它从未说明自己是AI。而在本文场景中，代理运行在客户配置的账户下，有自己的角色和审计追踪。
这对API意味着什么
这项提案并非背离基于标准的API。与良好的API相比，通过屏幕点击的代理缓慢且脆弱，供应商和开发者都更愿意使用API。但如今，供应商如果不提供良好的API，就只能什么都不提供。如果客户总是可以回退到他们已经付费的界面，供应商的最佳选择就是提供更好的东西：一个更快、更安全、定价合理的API或MCP服务器，让代理更愿意使用。ONC在下一个规则制定中关于API写入和自动化的计划工作将建立在这一底线之上。
患者在使用门户时也面临同样的问题，同样的原则也应适用于那里。我已经在别处就此写过文章。本提案涵盖临床医生和获得EHR许可的组织。