Prior Auth Review Skill：把 30 分钟 PA 审批压进 5 分钟

Pre-authorization。PA。预授权审批。不管你怎么叫它，这个词在任何一个美国医保支付方机构里，都是运营成本的吞噬黑洞。

传统流程是这样的：医生提交 PA 申请，附上病历、诊断代码和诊疗方案。支付方的审阅员坐下来，打开 CMS 政策文档，逐个核对三件事：诊断码和诊疗码是否匹配，覆盖政策是否支持，以及医疗服务提供者是否资质齐全。一份申请平均耗时 30 到 60 分钟。问题是其中 40% 到 60% 的案例其实是明显合规的，根本不需要人工判断。

这就像让一个注册会计师去核对超市小票。浪费的不只是时间，是专业审阅员本该花在疑难案例上的判断力。

Anthropic 在 healthcare 仓库里放出的 prior-auth-review-skill，就是冲着这个痛点来的。它的逻辑简单直接：把 PA 审批里那些机械、重复、有明确规则可循的部分，全部交给 AI。人只处理那些真正需要临床判断的灰色地带。

整套系统目前 376 个 GitHub star，283 次安装，放在 anthropics/healthcare 仓库里。数字不大，但它瞄准的市场是美国年处理量超过 2 亿次的 PA 审批流程。

环境准备

这个 Skill 不是独立跑的服务。它跑在 Claude Code 或 Claude.ai 的 Skills 运行时环境里，安装就一行：

npx skills add https://github.com/anthropics/healthcare --skill prior-auth-review-skill

装完之后它不会直接干活。启动时它会先做 MCP 连接器检查，必须凑齐三个医疗数据源：

• CMS Coverage MCP Connector，查 Medicare 覆盖政策（NCDs、LCDs）
• ICD-10 MCP Connector，校验诊断代码是否有效
• NPI MCP Connector，通过 NPPES 数据库验证医疗服务提供者资质

缺任何一个，Skill 直接报错退出，不给半成品。这个设计挺聪明的，与其跑一半发现缺数据，不如一开始就拦住你。很多 healthcare AI 工具在这个环节是”优雅降级”，缺数据就猜一个结果。这个 Skill 的立场很明确：没有完整数据就不干活。

操作流程

调用方式极其简单，一句话触发：

Use the prior-auth-review-skill

Skill 启动后会先检查是否存在中断未完成的请求（支持断点续跑），然后引导你提供 PA 申请材料。要么用内置的 sample 数据先跑一遍看效果，要么直接甩真实病历文档进去。

流程本身分两大步。

第一步，信息采集与评估。Skill 从你给的临床文档里提取患者人口统计信息、诊断列表、拟议的诊疗方案和医疗服务提供者详情。然后逐个调用三个 MCP 连接器验证：医生是不是真医生，诊断码能不能对上，CMS 有没有对应的覆盖政策。

从文档来看，每一步 MCP 调用前后都会输出通知，比如”正在通过 NPI MCP Connector 验证提供者资质……“和”NPI MCP Connector 执行成功，提供者已验证：Dr. Smith”。这个 Trace 设计对审计友好度很高，你在日志里能清楚看到每一步是谁调了什么、结果是什么。

第二步，决策与通知。基于第一步产出的 assessment.json，Skill 跑一遍决策矩阵，输出 APPROVE、PEND 或 DENY，附带详细理由和引用政策编号。最后生成一份给医疗服务提供者的通知函。

两阶段之间的中间结果全部落在 waypoints/ 目录，文件结构干净得像教科书范例。

关键设计

这个 Skill 最值得关注的设计决策，不是技术架构，是它的决策政策配置方式。

核心文件 rubric.md 定义了一套完整的决策矩阵。默认跑的是 Lenient Mode，翻译一下就是不轻易拒绝，宁愿挂起也不误杀。具体规则是这样的：

提供者 NPI 验证失败？PEND，要求补充资质文件。CPT/HCPCS 诊疗码无效？PEND，要求澄清。ICD-10 诊断码有问题？PEND，要求更正。覆盖政策找不到？PEND，可能需手动政策检索。所有必要标准满足？APPROVE。

一句话总结默认策略：只批准明确合规的，其余全挂起等人看。系统默认不自动拒绝任何案例。

但 rubric.md 是可编辑的。如果你的机构想要 Strict Mode，把表格里 PEND 那一列改成 DENY 就行。代码不需要动，改一个 Markdown 文件里的配置表。这个设计让非技术人员的运营主管也能自己调政策松紧度，不用找工程团队改代码。

从架构推断，选择把决策政策放在一个独立的可编辑 Markdown 文件而不是嵌在代码里，说明 Anthropic 对这个 Skill 的定位很清楚：它提供的是一套自动化框架，具体怎么判、什么标准该过什么标准该卡，必须由支付方自己定。这在医疗合规上是对的，监管审计要追责的是机构，不是 AI。

决策结果的覆盖规则也有讲究。PEND 可以翻成 APPROVE（收到补充材料后），PEND 也可以翻成 DENY（有临床理由），APPROVE 可以改判 DENY（需记录理由）。覆盖规则给了人类审阅员最终决定权。

关键风险点必须说清楚：系统生成的所有结果都是 DRAFT RECOMMENDATIONS ONLY。最终决策必须由有资质的专业人员进行人工复核。这一点在 README 和 SKILL.md 里反复强调，而且是医疗 AI 做决策辅助的基线要求，不是 Anthropic 的免责条款。

使用场景

最典型的场景是 Medicare Advantage 计划的日常 PA 审批流水线。

假设一天进来 200 份 PA 申请。传统模式下需要 200 个审阅员小时，按 8 小时工作制算就是 25 个人天。用这个 Skill，先过一遍自动筛选：那些诊断码和诊疗码都能对上、提供者资质没问题、CMS 政策明确支持的案例，直接给 APPROVE 推荐。按 40% 到 60% 的自动批准率算，80 到 120 份申请不需要人工过。

剩下那些复杂的、信息不全的、政策模糊的案例，审阅员拿着 AI 已经提取好的结构化评估结果（assessment.json），不用再手动翻病历和查政策，直接做临床判断。

另一个适配场景是 Medicaid MCO（医疗补助管理式医疗组织）。Medicaid 的覆盖政策因州而异，比 Medicare 单一联邦政策复杂得多。但 rubric.md 可以按州或按产品线定制，灵活性刚好匹配这种碎片化的政策环境。

不适用场景也值得说清楚。这个 Skill 不适合医疗服务提供者端（医生/医院用来提交 PA 的流程）。它专为支付方审阅端设计。另外，它目前不直接对接 EHR 系统，需要人工或中间件把病历数据转成它要的输入格式。如果你的 PA 申请量一天不到 50 份，ROI 可能不够显著，建议先用 sample 数据跑一遍看效果再决定。

洞察与反思

看完整套 SKILL.md 和 rubric.md，最直观的感受是：这个 Skill 的设计哲学跟大多数 AI 医疗工具不一样。

大多数 AI 医疗工具试图覆盖全链条，从数据采集到决策到通知，恨不得把审阅员完全替代。Prior Auth Review Skill 的策略正好相反：它只做那些”明确对”或”明确错”的判断，把所有模糊地带原样还给人类。

从 SKILL.md 里反复出现的”ONLY REVIEW THE SUBSKILL FILES WHEN THEY ARE NEEDED, DONT PRE-READ THE WHOLE SKILL ON BOOTUP”这句提示来看，设计者对 LLM 的上下文窗口非常敏感。不给模型灌不需要的信息，每个子任务只加载相关指令。这种刻意保持轻量的架构选择，在医疗场景里特别重要，因为每多一段无关上下文，模型就多一个产生幻觉的机会。

MCP 连接器依赖是一个双刃剑。好处是数据源标准化，坏处是部署门槛高，不是所有支付方都有三个现成的 MCP 连接器可用。但回头想，医疗数据本来就不该随便连，把 NPI/NPPES、ICD-10、CMS Coverage 作为硬前置条件，反而是在帮你强制建立数据治理基线。

如果要挑一个明显的短板，是 EHR 集成缺失。现实世界中绝大部分 PA 申请是从 EHR 系统触发的，Skill 目前需要人工把数据从 EHR 搬过来，这个环节可能是瓶颈。但这更像是第一个版本的有意取舍，优先做好核心判断逻辑，集成层留给后续迭代或第三方中间件。

资源地址

总结

Prior Auth Review Skill 解决的是一个真实且昂贵的问题：PA 审批中 40% 到 60% 的明确案例不该占用审阅员的判断力。它用两个子 Skill 加三个 MCP 连接器的架构实现了这一目标，核心判断逻辑可配置但安全边界不可逾越。

如果你是支付方机构的运营负责人，值得花一个下午拿 sample 数据跑一遍。看看自动批准率落在哪个区间，看看 rubric 配置能不能适配你们现有的政策。数据不会说谎，跑一遍就知道了。

如果你在做医疗 AI 的产品设计，这个 Skill 的决策政策分离架构可能是比它的审批能力更有价值的参考点。把”判断什么”和”怎么判断”拆成两个独立文件，让非技术角色能直接修改业务规则，这种设计在医疗合规场景下的可复制性很高。