给 Agent 装一道脱敏闸门再让它读自己的病历：一笔要自付 1000 美元的肠镜账单，由它写申诉草稿
Eugene Vestel（Substack 专栏 evestel 作者，原帖作者本人）Substack · 2026-02-24
打开原帖来源文字 / 整理摘要
原帖相关段落逐字（Substack，2026-02-24，本轮直连取得全文，HTTP 200）： “I created a personal FHIR server. Not a startup platform. Not a shared cloud. A private instance. … Epic patient-access FHIR data from two health systems, Additional clinical records not available via TEFCA, Pharmacy data, Insurance history and claims via Flexpa using the CARIN Alliance IG (Coverage + EOBs).” “This guardrail proxy sits between Open Claw and any FHIR server. Every request passes through it. No exceptions. … Automated PHI reduction (masking, truncation, stripping identifiers), Immutable audit logs, Step-up authorization for writes, Human-in-the-loop confirmation for clinical actions.” “Case in point: my colonoscopy. I was never told it would be billed as diagnostic instead of routine. That meant a $1,000 deductible despite the fact that if I'd waited a few weeks (turning 45 in 2026), it would've been fully covered. Open Claw helped me: understand the billing nuance, draft a dispute, identify leverage (including credit reporting thresholds), decide whether escalation was worth it.” 中文对照：他建了一个私有 FHIR 实例，汇总两家医疗系统的 Epic 数据、TEFCA 之外的临床记录、药房数据与 Flexpa 的保险理赔；护栏代理位于 OpenClaw 与 FHIR 服务器之间，做 PHI 脱敏、不可变审计日志、写操作升级授权、临床动作人工确认；肠镜被按诊断性计费产生 1000 美元 deductible，Agent 帮他理解计费口径、起草申诉、找出施压点并判断是否升级。
业务摘要
把散落在几家医院、药房和保险公司里的健康与理赔数据，先汇总成一私有 FHIR 实例，再在 Agent 与数据之间插一层护栏代理：Agent 拿到的永远是脱敏后的必要字段，写操作与临床动作必须人工点头。它替代的是你自己在多个门户之间下载、比对、翻账单的时间，不替代医生判断，也不替你直接提交申诉。
跨多家医疗机构看病、手里有一堆解释不清的账单与 EOB 的人；正在准备就诊或保险申诉、需要把两年数据拉成一条时间线的人；也包括任何想让 Agent 碰敏感数据、但又清楚「先脱敏再接模型」这条底线的人。
执行链路
- 先把数据归拢到你自己手里
按原帖做法，把患者访问数据、药房记录、保险理赔集中到一个你自己掌控的实例：两家医疗系统的 Epic 数据、TEFCA 之外的临床记录、药房数据，保险侧走 CARIN 标准的 Coverage 与 EOB。家庭数据要单独限定范围并隔离。
- 在 Agent 与数据之间插一层脱敏护栏
所有请求必经这一层，无一例外：自动做 PHI 脱敏（掩码、截断、去标识），保留不可变审计日志，写操作要求升级授权，临床动作必须人工确认，读取时注入医学免责声明。这层不做好，后面所有能力都不该开。
- 只给「刚好够用」的字段，不给全量
按当前任务确定字段白名单：看计费就给计费字段，看趋势就给检验值与日期。不要让 Agent 直连原始 PHI。原帖作者明确区分了在数据层脱敏与在模型层脱敏，前者才是有效边界。
- 先做只读盘点，输出费用疑点清单
让它把账单与 EOB 逐条对一遍，标出计费口径不一致的项目，例如原帖的肠镜：被按诊断性而非筛查性计费。每条疑点要写清依据（哪一份文件、哪一个编码）和建议动作，不确定就标不确定。
- 起草申诉，人工确认后才提交
按疑点起草申诉或随访消息，明确标注未提交，附上依据文件清单，并给出可施压的点与是否值得升级的判断（原帖提到的施压点包括信用报告相关阈值）。提交动作一律留给人。
- 把长期指标拉成一条时间线
在原帖提到的就诊准备、随访、填表、申诉之外，最有留存价值的是趋势：把同一指标按时间排开，标出超出参考区间与复查间隔的点，下次就诊直接带着这一页去。需要说明的是，趋势跟踪这条能力是原帖列出的 Agent 动作之一，但「怎么排、标什么」是本站的建议，原帖没有给实现细节。
- 运行环境隔离，第三方能力一律不装
原帖作者的做法是：不装来路不明的 skill，Agent 跑在独立机器的独立账号上（他用的是一台 Mac mini 的专属账号），PHI 脱敏在数据层完成，临床与财务动作都要人工确认。这四条是持续运行的底线，不是一次性设置。
复用方案
- 能拿到自己的患者访问数据与保险理赔数据（患者访问权与 CARIN 标准接口）
- 一个你自己掌控的私有数据实例，不是共享云盘
- 一层可审计的脱敏与授权代理，位于 Agent 与数据之间
- 一台隔离的运行环境（原帖作者用独立机器的专属账号）
- 愿意接受：临床判断归医生，提交动作归自己，Agent 只出草稿
Prompt 指令
本站整理 · 未实测
你是一个个人医疗账单核对助手。目标是帮我把看不懂的账单变成能拿去争的一份草稿。你只有脱敏后的只读数据，没有提交权。 【输入】 本次任务范围：[例如某次检查的账单与对应 EOB] 可用字段白名单：[例如日期、项目名、计费编码、计费类型、金额、自付部分] 可用依据文件：[文件清单] 我本人负责：医学判断、是否提交申诉、是否升级 【执行步骤】 1) 先列出本次范围里的每一条计费：日期、项目名、计费编码、计费类型、金额、自付部分。只使用白名单字段，不得索取或输出原始身份信息。 2) 逐条与依据文件对照，标出三类问题：计费类型与记录描述不一致、同一项目重复计费、应覆盖却计入自付。每条写清依据出自哪份文件。 3) 对每条疑点给出建议动作：核对编码、申请复核、提交申诉，或资料不足先补资料。 4) 基于我指定的疑点起草一份申诉或随访消息草稿，注明未提交，并在末尾列出要附的依据文件。 5) 给出是否值得升级的粗判断：涉及金额、时限、以及可能的上诉或信用影响路径，只做提示不做决定。 6) 全程不写任何诊断结论；涉及临床表述一律标注需由医生确认。 【输出要求】 - 计费清单：表格，列为 日期 / 项目 / 编码 / 计费类型 / 金额 / 自付 / 疑点。 - 疑点说明：每条含疑点类型、依据文件、建议动作。 - 申诉草稿：标题、正文、附件清单，明确标注「草稿，未提交」。 - 升级提示：金额、时限、可能路径，结尾写明「是否升级由你决定」。 - 不确定项：单列，写清缺什么资料。 【人工确认点】 - 不得提交申诉、不得联系机构、不得代发任何消息，草稿必须经我确认后由我提交。 - 不得输出姓名、身份证号、完整病历号等原始身份信息；只使用白名单字段。 - 不得给出诊断结论或用药建议；涉及临床内容一律标注需医生确认。 - 不得扩展本次范围之外的字段或文件。 【失败与缺资料处理】 - 缺少对应 EOB、编码含义不明、金额对不上，一律进不确定项并说明缺什么，不得推断编码含义。 - 依据文件读不到内容时按失败报告，不得凭常识补齐。 - 任何一步资料不足，先停在该步并列出待补清单，不得继续起草。 【合成示例（非真实业务数据，仅演示格式；金额均为不带币种的合成数字）】 输入：范围「2026-02 某次门诊检查账单与对应 EOB」；字段白名单：日期、项目、编码、计费类型、金额、自付 输出（节选）： | 2026-02-11 | 结肠镜检查 | 示例编码 | 诊断性 | 示例金额 | 示例自付 | 记录描述为筛查性，计费类型不一致 | 疑点说明：计费类型与记录描述不一致，依据为 EOB-示例编号 第 2 页；建议先申请编码复核。 申诉草稿：标题「关于某次检查计费类型的复核申请」，正文 4 段，附件 2 份；标注「草稿，未提交」。 升级提示：涉及自付金额、复核申请时限 30 天；是否升级由你决定。
运行成本与避坑指南
成本：原帖未披露 token、费用或用量，采集站亦未给出。这类任务的成本主要在长病历与多份 EOB 的读取上；本站不给未经核实的数字，建议先只投一份账单试跑估量。
运行条件：最大的限制在接入侧：患者访问权、CARIN 标准接口、TEFCA 覆盖范围各不相同，TEFCA 之外的临床记录需要单独补。原帖作者明确指出这类系统原本不是为自主 Agent 设计的，门户、二维码、PDF 都是给人用的接口。
避坑：第一坑是让 Agent 直连原始 PHI——脱敏必须落在数据层，指望模型自觉等于没有边界。第二坑是提示词注入与来路不明的 skill，原帖作者的规则是不装。第三坑是把自付敞口当成已省下的钱：1000 美元是待争取的支出，申诉结果原帖并未给出。第四坑是越界给临床结论，这既不安全也不合规。
示例与验证记录 · 合成示例
一次账单核对的合成演示（非真实业务，未涉及任何真实病历）
范围：某次门诊检查账单与对应 EOB；字段白名单：日期、项目、编码、计费类型、金额、自付；依据文件：EOB-示例编号、检查记录-示例编号。
| 2026-02-11 | 结肠镜检查 | 示例编码 | 诊断性 | 示例金额 | 示例自付 | 记录描述为筛查性，计费类型不一致 | 疑点：计费类型与记录描述不一致；依据 EOB-示例编号 第 2 页；建议先申请编码复核。 申诉草稿：标题「关于某次检查计费类型的复核申请」，正文 4 段，附件 2 份——标注「草稿，未提交」。 升级提示：涉及自付金额，复核申请时限 30 天；是否升级由你决定。 不确定项：EOB 第 3 页编码含义不明，需向机构索取编码说明。
