healthcare-providers-verify

医疗服务提供者验证

借助 Nimble 的网页数据 API，根据 NPI 注册表和权威来源验证从业者资质。

用户请求：$ARGUMENTS

运行任何命令之前，请先阅读 references/nimble-playbook.md，了解 Claude Code 的约束（无 shell 状态、不使用 &/wait、子 Agent 权限、沟通风格）。

---

说明

步骤 0：预检 + WSA 发现

同级技能交接检查： 在运行完整预检之前，按照 references/nimble-playbook.md 中的同级技能交接模式，检查本次会话中是否已运行 healthcare-providers-extract 或 healthcare-providers-enrich。 如果存在当天的输出，则跳过 CLI 检查和配置文件加载，并复用 WSA 第 1/3 层 清单。只有在验证重点发生变化时，才重新运行第 2 层。

否则，运行完整预检，遵循 references/nimble-playbook.md（同时运行 5 个 Bash 调用：日期计算、今天、CLI 检查、配置文件加载、index.md 加载）。

同时运行 WSA 发现和设置：

• mkdir -p ~/.nimble/memory/{reports,healthcare-providers-verify/checkpoints}
• ls ~/.nimble/memory/healthcare-providers-verify/checkpoints/ 2>/dev/null
• 根据 references/wsa-reference.md 运行第 1 层（垂直领域）和第 3 层（通用工具） WSA 发现。第 2 层（会话专属）在步骤 1 之后运行，此时你已了解用户的专科和验证重点。

将发现的 Agent 分类到验证类别，并按照 references/wsa-reference.md，使用 nimble extract:templates get 进行验证。

根据预检结果：

• 缺少 CLI 或未设置 API 密钥 -> 阅读 references/profile-and-onboarding.md，然后停止
• 为所有 nimble CLI 调用添加标记：nimble --client-source nimble-agent-skills <subcommand>。MCP 请求会在传输层进行归因——请参阅 references/nimble-playbook.md。
• 配置文件存在 -> 记录下来以供参考。根据 references/nimble-playbook.md 的智能日期窗口规则确定模式：
  • **完整模式：**首次运行，或上次运行距今超过 14 天
  • **快速刷新：**上次运行距今不足 14 天（仅重新验证先前标记为 未验证/已标记的从业者）
  • **当天重复运行：**如果 last_runs.healthcare-providers-verify 是今天，请检查 ~/.nimble/memory/reports/healthcare-providers-verify-*[today].md 中是否存在 报告。 如果存在，请询问：“今天已经运行过。要为新数据再运行一次吗？”
• 不存在配置文件 -> 没关系。此技能不需要引导设置。继续步骤 1。

步骤 1：解析输入 + 初始问题

**同级技能链式调用快捷方式：**检查当天是否有 extract 或 enrich 输出：

ls ~/.nimble/memory/reports/healthcare-providers-extract-*$(date +%Y-%m-%d).md 2>/dev/null
ls ~/.nimble/memory/reports/healthcare-providers-enrich-*$(date +%Y-%m-%d).md 2>/dev/null

如果存在当天的报告，解析 {slug} 并加载服务提供者数据 （providers.json 或 enriched.json）。其中包含姓名、资质、专科和地点——跳过解析，直接进入步骤 2。

根据 references/nimble-playbook.md 中的输入解析模式解析 $ARGUMENTS， 并按以下规则确定处理路径：

• 检测到同级技能输出（providers.json/enriched.json） -> 继续步骤 2
• 检测到 CSV/表格/粘贴的数据 -> 继续步骤 2
• 不明确 -> 询问（计为最多 2 次提问中的 1 次）

如果输入明确，请确认，并提出一个补充问题（纯文本，不使用 AskUserQuestion）：

“找到 N 位从业者，准备进行验证。请快速回答：

1. 要验证哪些内容？（资质、专科、执业状态、诊所地址——或全部）
2. 医疗垂直领域是什么？（眼科、牙科、皮肤科、综合或其他）”

如果输入含糊，使用 AskUserQuestion（计为最多 2 次提问中的 1 次）：

要验证哪些从业者数据？

• 直接粘贴服务提供者数据（姓名 + 资质 + 地点，每行一条）
• 提供 CSV 文件路径或 Google 表格网址
• 或描述你现有的数据（例如：“一份包含 50 位眼科医生的名单，我需要对照 NPI 注册表进行验证”）

跳过用户在初始消息中已回答的问题。

步骤 2：分析输入数据

将输入解析为结构化记录。针对每位从业者，识别：

• 声称的信息 — 姓名、资质、专科、州／城市、诊所名称
• 核验目标 — 根据用户关注点确定要核查哪些信息

最低必需字段： 姓名 + 以下至少一项（资质、州、专科）。 如果某位从业者只有姓名，没有其他标识信息，请标记： “无法核验 [name] — 需要提供州、资质或专科才能搜索。”

生成核验计划摘要：

“正在分析 N 位从业者以进行核验：

• 已提供姓名：N/N
• 声称的资质：N/N
• 声称的专科：N/N
• 州／所在地：N/N

正在开始 NPI 核验……”

在已知专科后，立即运行第 2 层 WSA 发现：

nimble extract:templates list --limit 50  # filter items for "[specialty]"
nimble extract:templates list --limit 50  # filter items for "[registry-user-mentioned]"

有关特定会话的发现，请参见 references/wsa-reference.md。

步骤 3：NPI 注册信息查询

优先使用 NPPES API — 一次调用即可返回结构化 JSON，无需先搜索再提取（两次调用）。根据从业者的信息构建查询 URL：

nimble extract --url "https://npiregistry.cms.hhs.gov/api/?version=2.1&first_name=[First]&last_name=[Last]&state=[ST]&limit=5" --format markdown

如果已知专科且足够具体，请添加 &taxonomy_description=[Specialty]。API 会在一次调用中返回 NPI 编号、状态、资质、分类代码、地址和登记日期 — 完成核验所需的信息一应俱全。

如果 NPPES API 返回零条结果或出错，则回退到网页搜索：

nimble search --query "[Name] [Credential] [State] NPI registry" --max-results 5 --search-depth lite

然后从 NPI 来源中提取首条结果（见下方来源优先级）。

来源优先级（在子 Agent 提示词中强制执行）：

1. NPPES API（npiregistry.cms.hhs.gov/api/）— 首选，返回结构化 JSON
2. npidb.org/doctors/ — 数据结构清晰，是良好的备选来源
3. nppes.cms.hhs.gov（provider-view 页面）— CMS 官方来源
4. 跳过所有其他来源（healthline、hmedata、vitals 等）— 格式不一致

告知子 Agent：“只能从 NPPES API、npidb.org 或 nppes.cms.hhs.gov 提取信息。 忽略其他 NPI 聚合网站。”

每位提供者的搜索预算： 每位从业者最多进行 3 次搜索查询 + 1 次提取。如果尝试 3 次后仍未找到匹配的 NPI，请标记为“未核验”并继续处理。 告知子 Agent：“每位提供者最多运行 4 条 nimble 命令。若届时仍未找到匹配项，则标记为‘未核验’。”

对于 10 位及以上的从业者，请使用子 Agent（见下方“子 Agent 策略”）。

NPI 记录中的关键字段 — 完整列表请参见 references/npi-verification-patterns.md：NPI 编号、状态、资质、分类／专科、登记日期、上次更新时间、诊所地址。

检查点强制要求： 每当子 Agent 返回一批结果后，主上下文 MUST 在启动下一步或呈现结果之前写入检查点：

1. 接收子 Agent 的结果
2. 写入检查点：echo '[results]' > ~/.nimble/memory/healthcare-providers-verify/checkpoints/{slug}/batch-{n}.json
3. 继续下一步

请勿跳过此步骤 — 如果运行在步骤之间失败，用户会丢失所有进度。

步骤 4：交叉比对与验证

对于每位从业者，将其声称的信息与提取的 NPI 数据进行比较。按照 references/npi-verification-patterns.md 中的验证逻辑操作：

1. 姓名匹配 — 规范化双方姓名，并根据参考文档中的姓名匹配规则确定匹配级别（Strong、Likely、Weak、No Match）
2. 资质匹配 — 将声称的资质与 NPI 记录进行比较
3. 专科匹配 — 使用参考文档中的分类匹配策略，将声称的专科与 NPI 分类进行比较
4. 地址匹配 — 将声称的州/城市与 NPI 执业地址进行比较
5. 状态检查 — 确认 NPI 状态为 Active

根据证据综合情况，为每位从业者分配验证状态：

• 已验证 — 所有声称的信息均与 NPI 记录匹配
• 部分验证 — 找到 NPI，但存在轻微差异
• 未验证 — 未找到匹配的 NPI，或无法消除歧义
• 已标记 — 存在需要人工审核的不匹配项

各状态的详细标准及不匹配严重程度级别（Critical 与 Warning）请参阅 references/npi-verification-patterns.md。

步骤 5：WSA 补充验证（可选）

如果用户要求进行 NPI 查询以外的监管验证，或步骤 5 将一些从业者标记为未验证且可能需要其他来源的信息：

运行在步骤 0 中发现的验证阶段 WSA。有关验证阶段映射、Agent 评估和回退链的信息，请参阅 references/wsa-reference.md。

执业信息确认： 对于未验证的从业者，可尝试通过执业机构级 WSA 或网络搜索确认其执业机构是否存在：

nimble search --query "[practice-name] [city] [state]" --max-results 5 --search-depth lite

监管验证： 对于用户要求进行监管检查的从业者：

nimble search --query "[name] [credentials] clinical trials OR FDA OR board certification" --max-results 5 --search-depth lite

步骤 6：去重与置信度评分

遵循 references/nimble-playbook.md 中的实体去重模式。 技能专用的去重规则位于 references/provider-extraction-patterns.md。

NPI 去重检查： 所有子 Agent 返回结果后，检查各批次中是否存在重复的 NPI 号码。如果两个不同的提供者映射到同一个 NPI，则将两者都标记为“已标记 — 可能存在 NPI 冲突，需要人工审核”。这有助于发现数据录入错误以及源提供者列表中的姓名混淆。

专用验证评分： 此技能使用验证状态（已验证 / 部分验证 / 未验证 / 已标记）代替置信度评分。每种状态都包含一个置信度限定级别：

• 高置信度 — 2 个或更多 NPI 来源相互印证，姓名匹配度高
• 中置信度 — 单个 NPI 来源，姓名很可能匹配
• 低置信度 — 姓名匹配度低，部分字段匹配

步骤 7：输出

以验证报告的形式呈现结果，列出每位从业者的状态及具体不匹配详情。按验证状态分组，并在末尾添加“这意味着什么”部分。

# Provider Verification: [N] Practitioners Checked
*[Date] | [V] Verified, [PV] Partially Verified, [U] Unverified, [F] Flagged*

## TL;DR
Verified [V] of [T] practitioners against the NPI registry. [F] flagged for
review: [brief description of critical issues]. [U] could not be verified —
[common reason].

## Verification Results

| # | Name | Claimed | NPI Status | Verification | Issues | Source |
|---|------|---------|------------|-------------|--------|--------|
| 1 | Dr. Jane Smith | MD, Retinal Surgery, TX | Active (NPI 1234567890) | Verified | — | [NPI](url) |
| 2 | Dr. John Doe | OD, Ophthalmology, CA | Active (NPI 0987654321) | Partially Verified | Subspecialty differs | [NPI](url) |
| 3 | Dr. Alex Chen | MD, Dentistry, NY | Not Found | Unverified | No NPI match | [NPPES query](api-url) |
| 4 | Dr. Pat Lee | DO, Cardiology, FL | Deactivated | Flagged | NPI deactivated 2024-01 | [NPI](url) |

## Flagged Practitioners (Requires Human Review)

### Dr. Pat Lee
**Claimed:** DO, Cardiology, FL
**NPI Record:** NPI 1122334455 — **Deactivated** (01/15/2024)
**Issues:**
- CRITICAL: NPI status is Deactivated since January 2024
- Credential matches (DO confirmed)
- Specialty matches (Cardiovascular Disease taxonomy)
**Source:** [NPI Record](url)
**Action needed:** Confirm if provider has re-registered or if this is a
different individual.

[Repeat per flagged practitioner]

## Unverified Practitioners

[List practitioners where no NPI match was found, with search queries attempted]

## Verification Summary
- **Verified:** [V] practitioners — all claims confirmed
- **Partially Verified:** [PV] — minor discrepancies noted
- **Unverified:** [U] — no NPI match (common names, missing identifiers)
- **Flagged:** [F] — critical issues requiring review

## Sources
[Clickable URL for every NPI lookup page used, grouped by practitioner]

## What This Means
[Actionable interpretation: which practitioners are safe to include in your
directory, which need follow-up, what the verification rate tells you about
your data quality. Suggest next steps for unverified/flagged records.]

必须提供来源链接。 每项验证结果都必须可追溯至来源 URL。

步骤 8：保存到记忆

同时执行所有写入调用：

• 报告 -> ~/.nimble/memory/reports/healthcare-providers-verify-{slug}-{date}.md
• 验证数据 -> ~/.nimble/memory/healthcare-providers-verify/{slug}/verified.json
• 配置文件 -> 更新 ~/.nimble/business-profile.json 中的 last_runs.healthcare-providers-verify（仅当配置文件存在时）
• 遵循 references/memory-and-distribution.md 中的 Wiki 更新模式：更新所有受影响实体文件对应的 index.md 行，并为本次运行追加一条 log.md 条目。
• 清理检查点（完整运行）或保留检查点（部分运行）

更新关联文件： 如果 ~/.nimble/memory/ 下此 slug 对应的 providers.json 或 enriched.json 存在，则将 NPI 号码和验证状态合并到这些文件中。生成已验证的 CSV 导出文件，保存至 ~/.nimble/memory/healthcare-providers-verify/{slug}/verified-{date}.csv，包含所有验证列（NPI、NPI 状态、NPI 分类、验证状态）。在步骤 9 中提供此导出文件路径，方便用户复制到所需位置。

第 9 步：分享、分发与后续跟进

务必提供分发选项，不要跳过。 请遵循 references/memory-and-distribution.md 中的连接器检测和分享流程。

Notion：将完整验证报告作为带日期的子页面。 Slack：仅提供简要摘要、验证数量和标记项。

后续跟进：

• “详细介绍一下 Dr. X” -> 显示完整验证详情
• “导出为 CSV” -> 生成包含验证状态的 CSV
• “仅重新验证标记项” -> 仅对已标记/未验证项重新执行 NPI 搜索
• “标记的那些我该怎么办？” -> 针对每个问题提供可执行的后续步骤

同类技能建议：

后续步骤：

• 对未验证提供者的诊所 URL 运行 healthcare-providers-extract 以获取最新数据
• 运行 healthcare-providers-enrich，补全已验证提供者记录中的缺失信息
• 运行 market-finder，查找该地区的其他诊所

---

子 Agent 策略

批量验证（10 位或更多从业者）时，使用 nimble-researcher Agent （agents/nimble-researcher.md）并行处理 NPI 查询和信息提取。

遵循 references/nimble-playbook.md 中的子 Agent 启动规则 （bypassPermissions、批次上限为 4、明确的 Bash 指令，以及失败时的回退方案）。

启动模式： 每 5 位从业者分配一个 Agent。每个 Agent 为分配到的从业者执行第 3 至第 4 步， 并返回验证记录。尽可能让每个 Agent 对其 NPI 结果 URL 使用 nimble extract-batch；每个 Agent 调用一次批处理，比顺序调用更快。

小批次优化： 如果从业者少于 10 位，请直接在主上下文中执行，而不是启动 Agent。

回退： 如果任何 Agent 失败，请在主上下文中直接完成相应验证。绝不能让输出中出现遗漏。

---

错误处理

请参阅 references/nimble-playbook.md 中的标准错误表（缺少 API 密钥、 429、401、结果为空、提取结果无效）。此技能特有的错误：

• 找不到从业者的 NPI 结果：“在 [state] 中找不到 [name] 的 NPI 记录。姓名可能过于常见，也可能该提供者使用不同的姓名执业。要我尝试使用其他信息（诊所名称、NPI 号码）吗？”
• 匹配到多个 NPI 记录：“在 [state] 中找到多个 [name] 的 NPI 记录。你能确认是哪一条吗？[列出排名前 3 的记录，包括 NPI 号码和专业领域]”
• NPI 页面提取结果无效：“NPI 查询页面似乎是通过 JavaScript 渲染的。正在尝试使用浏览器渲染重试……”（按照共享模式自动使用 --render 重试）
• CSV/Sheet 解析错误：“无法解析输入文件。预期包含从业者姓名以及至少一个标识信息（州、专业领域或资质）的列。你能直接粘贴数据吗？”
• 验证数据不足：“无法验证 [N] 位从业者——他们只有姓名，没有州、资质或专业领域信息。请添加标识信息，或将其从列表中移除。”