保健提供者进行
Posted: Thu Jan 02, 2025 9:35 am
在最近的一篇博文中，技术政策助理部长 Micky Tripathi 描述了我们机构对可能不遵守与信息共享相关的法规和条例的日益担忧。该博文涵盖了与认证医疗 IT 开发人员和 ASTP/ONC 医疗 IT 认证计划 (Certification Program) API 要求相关的问题。在这篇博文中，我们分享了我们注意到的有关医疗保健提供商以及认证医疗 IT 开发人员可能违反信息阻止法规的担忧。
医疗服务提供者的实践
自该法规于 2021 年 4 月生效以来， ASTP/ONC每个工作日都会收到超过一起信息阻止投诉，其中近 90% 的投诉针对的是医疗保健提供者。在我们进行的听证会上，我们听到了对医疗的许多种做法的担忧。提出的一个担忧是，医疗保健提供者可能会对电子健康信息 (EHI) 的访问、交换和使用施加先决条件，而这些条件并不是 HIPAA 隐私规则或其经营所在司法管辖区的法律所要求的。例如，提供者一直要求签署 HIPAA 业务伙伴协议 (BAA)，而HIPAA 并不要求这样做，比如对于方便个人访问他们自己的 EHI 的应用程序。其他担忧包括可察觉的访问障碍，例如把关、延迟以及建立连接或注册患者用于访问其 EHI 的应用程序的困难。信息屏蔽法规不仅涵盖了这些示例和类似类型的做法，而且我们还在规则制定和常见问题解答中专门讨论了某些情况，并指出这些做法将或可能涉及信息屏蔽法 金融和银行电子邮件列表 规。以下是其中一些做法：
拥有经 170.315(g)(10)认证的本地托管 EHR 技术的医疗保健提供商选择不自动发布其服务基础 URL，而是仅将其提供给特别批准的应用程序，从而阻止应用程序（以及患者）访问应可通过标准化 API 轻松访问的数据（84 FR 7518）。
在没有认证 API 开发人员协助的情况下在本地管理其 FHIR 服务器的医疗保健提供者拒绝向认证 API 开发人员提供患者访问其 EHI 所需的 FHIR 服务基 URL ( 85 FR 25813 )。
当 EHR 开发商的患者门户提供此功能时，医疗保健提供者选择不允许患者直接向第三方传输或请求直接传输其 EHI 给第三方（84 FR 7519）。
医疗保健提供者有能力以患者或患者医疗保健提供者要求的形式和格式提供当日 EHI 访问权限，但需要几天时间才能做出回应 ( 84 FR 7519 )。我们还注意到，如果在通过 API 向患者授权接收其 EHI 的应用程序提供患者的 EHI 时出现延迟，则可能会造成干扰 ( FAQ22.1.2021MAR和89 FR 63802 )。
一家医疗保健提供商表示，经过认证的 API 仅供患者访问，不得供其他提供商等其他授权方访问。
经认证的医疗 IT 开发人员的实践
相关方还对经认证的医疗 IT 开发商的 API 相关做法提出了具体担忧。一些担忧包括开发商未能发布服务基础 URL 供患者访问其 EHI（45 CFR 170.404(b)(2)），以及开发商只愿意向特别批准的应用程序提供 URL。其他担忧包括开发商在完成真实性验证后，拒绝在规定时间内注册并启用应用程序用于生产用途（45 CFR 170.404(b)(1)(ii)）。
我们在《治愈法案最终规则》中描述了这些做法和类似类型的做法，我们在其中指出，支持患者访问的服务基础 URL 的公开可用性是绝对必要的，否则，EHI 的访问、交换和使用将受到阻碍 ( 85 FR 25813 )。正如我们所说，任何行为者限制此类 URL 公开可用性的行为不仅可能构成信息阻止法规下的干涉，而且会完全阻止 EHI 的访问、交换和使用 ( 85 FR 25813 )。同样，我们已经指出，行为者拒绝注册允许患者访问其 EHI 的应用程序也将有效阻止其使用，使其无法连接到经过认证的 API 技术( 85 FR 25813 )。我们指出，在患者访问的背景下，这种拒绝是非常可疑的，而且很可能涉及信息阻止 ( 85 FR 25813 )。
医疗服务提供者的实践
自该法规于 2021 年 4 月生效以来， ASTP/ONC每个工作日都会收到超过一起信息阻止投诉，其中近 90% 的投诉针对的是医疗保健提供者。在我们进行的听证会上，我们听到了对医疗的许多种做法的担忧。提出的一个担忧是，医疗保健提供者可能会对电子健康信息 (EHI) 的访问、交换和使用施加先决条件，而这些条件并不是 HIPAA 隐私规则或其经营所在司法管辖区的法律所要求的。例如，提供者一直要求签署 HIPAA 业务伙伴协议 (BAA)，而HIPAA 并不要求这样做，比如对于方便个人访问他们自己的 EHI 的应用程序。其他担忧包括可察觉的访问障碍，例如把关、延迟以及建立连接或注册患者用于访问其 EHI 的应用程序的困难。信息屏蔽法规不仅涵盖了这些示例和类似类型的做法，而且我们还在规则制定和常见问题解答中专门讨论了某些情况，并指出这些做法将或可能涉及信息屏蔽法 金融和银行电子邮件列表 规。以下是其中一些做法：
拥有经 170.315(g)(10)认证的本地托管 EHR 技术的医疗保健提供商选择不自动发布其服务基础 URL，而是仅将其提供给特别批准的应用程序，从而阻止应用程序（以及患者）访问应可通过标准化 API 轻松访问的数据（84 FR 7518）。
在没有认证 API 开发人员协助的情况下在本地管理其 FHIR 服务器的医疗保健提供者拒绝向认证 API 开发人员提供患者访问其 EHI 所需的 FHIR 服务基 URL ( 85 FR 25813 )。
当 EHR 开发商的患者门户提供此功能时，医疗保健提供者选择不允许患者直接向第三方传输或请求直接传输其 EHI 给第三方（84 FR 7519）。
医疗保健提供者有能力以患者或患者医疗保健提供者要求的形式和格式提供当日 EHI 访问权限，但需要几天时间才能做出回应 ( 84 FR 7519 )。我们还注意到，如果在通过 API 向患者授权接收其 EHI 的应用程序提供患者的 EHI 时出现延迟，则可能会造成干扰 ( FAQ22.1.2021MAR和89 FR 63802 )。
一家医疗保健提供商表示，经过认证的 API 仅供患者访问，不得供其他提供商等其他授权方访问。
经认证的医疗 IT 开发人员的实践
相关方还对经认证的医疗 IT 开发商的 API 相关做法提出了具体担忧。一些担忧包括开发商未能发布服务基础 URL 供患者访问其 EHI（45 CFR 170.404(b)(2)），以及开发商只愿意向特别批准的应用程序提供 URL。其他担忧包括开发商在完成真实性验证后，拒绝在规定时间内注册并启用应用程序用于生产用途（45 CFR 170.404(b)(1)(ii)）。
我们在《治愈法案最终规则》中描述了这些做法和类似类型的做法，我们在其中指出，支持患者访问的服务基础 URL 的公开可用性是绝对必要的，否则，EHI 的访问、交换和使用将受到阻碍 ( 85 FR 25813 )。正如我们所说，任何行为者限制此类 URL 公开可用性的行为不仅可能构成信息阻止法规下的干涉，而且会完全阻止 EHI 的访问、交换和使用 ( 85 FR 25813 )。同样，我们已经指出，行为者拒绝注册允许患者访问其 EHI 的应用程序也将有效阻止其使用，使其无法连接到经过认证的 API 技术( 85 FR 25813 )。我们指出，在患者访问的背景下，这种拒绝是非常可疑的，而且很可能涉及信息阻止 ( 85 FR 25813 )。