我们在过去一年构建医疗保健集成所学到的经验

Source: Dev.to

引言

在过去的一年里，我们一直在构建与不提供真实 API 的电子健康记录（EHR）系统和支付方门户的集成。这过程相当痛苦，所以我们觉得分享我们的经验并听取他人哪些做法有效——或无效——会很有帮助。

为什么医疗集成如此困难

• 数据碎片化 – 可用的 API 缺少大量功能，甚至根本不存在。
• 受限的 FHIR 端点 – 通常缺少你真正需要的数据，也没有写回能力。
• 昂贵的供应商渠道 – 直接通过 EHR 供应商进行集成成本高且速度慢。
• 支付方门户 – 大多数根本没有 API；有 API 的也功能受限。
• 第三方 API – 常常出现覆盖空白。

正因为这些限制，许多医疗初创公司（包括我们）转向了浏览器自动化。

从全自主浏览器代理开始

我们最初使用 AI 驱动的浏览器代理，因为它们实现成本最低且看起来比较稳健。然而：

• EHR 工作流不直观，需要大量点击。
• 代理难以正确执行这些工作流。
• 速度慢且费用高，每个操作都需要一次 LLM 调用。
• 赋予代理完全自主的点击权会引发安全顾虑。

转向 Stagehand

Stagehand 提供了确定性与 AI 的混合，以捕获错误。但不幸的是：

• 它依赖可访问性树，而该树并不总是映射到 EHR 上的正确动作/选择器。
• 在复杂的 DOM（例如 Athena）上经常失效。
• 我们遇到的错误并非 Stagehand 设计用来处理的类型。

迁移到 Playwright

我们在运行自动化时识别出三类常见错误：

1. 不确定性的弹窗
2. 渲染缓慢的元素
3. 内部逻辑的边缘案例（例如，重复患者但没有明确标识符）

改进措施

• 构建了轻量级弹窗检测器和更智能的等待/重新加载逻辑。
• 手动处理边缘案例，以避免不期望的 LLM 决策（例如，在重复患者之间正确关联转诊）。

尽可能使用网络请求

为提升可靠性、速度和可维护性，我们将部分集成改写为直接的 API/网络调用。好处：

• 相比浏览器代理或 Playwright 脚本更快、更可靠。
• 但某些站点有检测机器人并阻止其访问的安全措施，这使得此方法不适用于这些情况。

更大的转变：构建时 AI 与运行时 AI

最重要的思维模型转变是从 运行时 AI（代理在实时 Playwright 执行期间做决定）转向 构建时 AI：

• Claude Code 生成并迭代 Playwright 脚本，在运行前修复错误。
• 工程师保留对代码的完整可见性和控制权。
• 我们始终参与任何边缘案例的处理，决定正确的处理方式，而不是让 LLM 自主行动。

我们当前的技术栈

脚本创建

• 使用 Playwright + Claude Code 在本地开发。
• 记录工作流、添加注释、运行流程，让 Claude 检查日志和网络请求，以完善自动化。

稳健性

• 特定情况使用 AI 兜底，例如弹窗检测器会捕获截图，确定 X/Y 坐标，关闭弹窗并重试原本的逻辑。

基础设施

• 之前在 GCP Cloud Run 作业上自托管，失败时捕获截图和结构化错误日志，便于调试。
• 最近迁移到 Kernel 和 Browserbase 等托管平台，但这带来了更多的不稳定性。

代码仓库

https://github.com/saffron-health/libretto