healthcare-providers-verify

Healthcare Providers Verify

NPI 登録簿および信頼できる情報源に照らして医療従事者の資格を検証します。Nimble のウェブデータ API を活用します。

ユーザーのリクエスト：$ARGUMENTS

コマンドを実行する前に、Claude Code の制約（シェル状態の保持なし、&／wait の使用禁止、サブエージェントの権限、コミュニケーションスタイル）について、references/nimble-playbook.md を読んでください。

---

手順

ステップ 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 の後に実行します。

検出したエージェントを検証カテゴリに分類し、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 回として数えます）。

入力が明確な場合は確認して、条件を絞る質問を 1 つ尋ねます（AskUserQuestion は使わず、プレーンテキストで尋ねます）。

「N 人の医療従事者が見つかりました。確認したいことを教えてください。

1. 何を検証しますか？（資格、専門分野、現役かどうか、診療所の住所、またはすべて）
2. 医療分野は何ですか？（眼科、歯科、皮膚科、一般、その他）」

入力が曖昧な場合は AskUserQuestion を使います（最大 2 回の質問のうち 1 回として数えます）。

検証する医療従事者のデータを指定してください。

• 医療従事者のデータを直接貼り付ける（氏名＋資格＋所在地を 1 人につき 1 行）
• CSV ファイルのパスまたは Google スプレッドシートの URL を指定する
• または、手元にあるデータを説明する（例：「NPI 登録簿で検証したい眼科医 50 人のリスト」）

最初のメッセージですでに回答されている質問は省略します。

Step 2: 入力データを分析する

入力を構造化されたレコードに解析します。各施術者について、次の情報を特定します。

• 申告された項目 — 氏名、資格、専門分野、州／都市、診療所名
• 検証対象 — ユーザーの関心に基づいて確認する申告内容

最低限必要な項目： 氏名と、（資格、州、専門分野）のうち少なくとも1つ。 施術者の情報が氏名しかない場合は、次のように通知します。 「[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 を参照してください。

Step 3: NPI レジストリの検索

NPPES API を優先してください — 検索と抽出の2回ではなく、1回の呼び出しで構造化 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 番号、ステータス、資格、タクソノミーコード、住所、登録日を返すため、1回の呼び出しですべてを検証できます。

NPPES API が結果を返さない、またはエラーになった場合は、ウェブ検索にフォールバックします：

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

次に、NPI 情報源の上位結果を抽出します（以下の情報源の優先順位を参照）。

情報源の優先順位（サブエージェントへのプロンプトで徹底してください）：

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 など）— 書式に一貫性がありません

サブエージェントには次のように伝えます：「NPPES API、npidb.org、または nppes.cms.hhs.gov からのみ抽出してください。 他の NPI アグリゲーターサイトは無視してください。」

施術者1人あたりの検索上限： 検索クエリは最大3件、抽出は1回までです。3回試しても NPI が一致しない場合は、未検証とし、次に進みます。 サブエージェントには次のように伝えます：「施術者1人につき nimble コマンドを4回以上実行しないでください。それまでに一致が見つからない場合は、未検証としてください。」

施術者が10人以上の場合は、サブエージェントを使用します（以下の「サブエージェント戦略」を参照）。

NPI レコードの主な項目 — 項目の全一覧については、references/npi-verification-patterns.md を参照してください：NPI 番号、ステータス、資格、タクソノミー／専門分野、登録日、最終更新日、診療所の住所。

チェックポイントの徹底： 各サブエージェントがバッチ結果を返した後、次のステップを開始する、または結果を提示する前に、メインコンテキストで必ずチェックポイントを記録します。

1. サブエージェントの結果を受け取る
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 であることを確認します

証拠全体に基づき、各医療従事者に検証ステータスを割り当てます。

• Verified — 申告された内容がすべて NPI レコードと一致します
• Partially Verified — NPI は見つかったものの、軽微な不一致があります
• Unverified — NPI が見つからない、または対象を特定できません
• Flagged — 人による確認が必要な不一致があります

各ステータスの詳細な基準と不一致の重大度レベル（Critical 対 Warning）については、references/npi-verification-patterns.md を参照してください。

ステップ 5：WSA による補足検証（任意）

ユーザーが NPI 検索を超える規制上の検証を求めた場合、またはステップ 5 で Unverified となった医療従事者について追加情報源による確認が有効な場合：

ステップ 0 で検出した検証フェーズの WSA を実行します。検証フェーズのマッピング、エージェントの評価、フォールバックチェーンについては、references/wsa-reference.md を参照してください。

診療所の確認： Unverified の医療従事者について、診療所レベルの 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 の重複排除チェック： すべてのサブエージェントからの応答後、バッチ間で NPI 番号が重複していないか確認します。異なる 2 人の医療提供者に同じ NPI が割り当てられている場合、両方に「Flagged — NPI の衝突の可能性があり、人による確認が必要」とフラグを付けます。これにより、データ入力ミスや、元の医療提供者リストにおける名前の混同を検出できます。

検証固有のスコアリング： このスキルでは、信頼度のスコアリングに代わり、検証ステータス（Verified／Partially Verified／Unverified／Flagged）を使用します。各ステータスには信頼度の補足情報が含まれます。

• 高い信頼度 — 2 つ以上の NPI 情報源で裏付けがあり、名前が強く一致します
• 中程度の信頼度 — NPI 情報源が 1 つで、名前が一致する可能性が高いです
• 低い信頼度 — 名前の一致が弱く、一部の項目のみが一致します

ステップ 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：メモリに保存

すべての Write 呼び出しを同時に実行します。

• レポート -> ~/.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/ 配下に、このスラッグの providers.json または enriched.json が存在する場合は、NPI 番号と検証ステータスをそれらのファイルに統合します。すべての検証列（NPI、NPI Status、NPI Taxonomy、Verification Status）を含む検証済み CSV を ~/.nimble/memory/healthcare-providers-verify/{slug}/verified-{date}.csv に生成します。ステップ 9 では、ユーザーが必要な場所にコピーできるよう、このエクスポートのパスを提示してください。

ステップ 9：共有、配布、フォローアップ

必ず配布を提案してください。省略しないでください。 コネクターの検出と共有フローについては、 references/memory-and-distribution.md に従ってください。

Notion：検証レポート全体を日付付きのサブページとして共有します。 Slack：検証件数と要確認項目のみを含む要約を共有します。

フォローアップ：

• 「Dr. Xについて詳しく教えて」 -> 検証の詳細全体を表示します
• 「CSVとしてエクスポートして」 -> 検証ステータスを含むCSVを生成します
• 「要確認の項目のみ再検証して」 -> 要確認／未検証の項目のみNPI検索を再実行します
• 「要確認の項目について何をすればいい？」 -> 問題ごとに実行可能な次のステップを提示します

関連スキルの提案：

次のステップ：

• 未検証のプロバイダーの診療所URLに対して healthcare-providers-extract を実行し、 最新のデータを取得します
• 検証済みプロバイダーの記録にある不足情報を補完するため、healthcare-providers-enrich を実行します
• この地域の診療所をさらに探すため、market-finder を実行します

---

サブエージェント戦略

10人以上の医療従事者を一括検証する場合は、NPI検索と情報抽出を並列化するため、 nimble-researcher エージェント（agents/nimble-researcher.md）を使用します。

references/nimble-playbook.md のサブエージェント起動ルール （bypassPermissions、バッチ上限4、明示的なBashの指示、失敗時のフォールバック）に従ってください。

起動パターン： 医療従事者5人ごとに1つのエージェントを起動します。各エージェントは割り当てられた 医療従事者についてステップ3～4を実行し、検証記録を返します。可能であれば各エージェントに、 NPIの結果URLに対して nimble extract-batch を使うよう指示してください。エージェントごとに一度 バッチ呼び出しを行うほうが、逐次呼び出しより高速です。

少人数バッチの最適化： 医療従事者が10人未満の場合は、エージェントを起動せず、 メインコンテキストから直接実行します。

フォールバック： エージェントが失敗した場合は、該当する検証をメインコンテキストから直接実行します。 出力に漏れを残さないでください。

---

エラー処理

標準的なエラー表（APIキーの欠落、429、401、結果なし、抽出データの不備）については、 references/nimble-playbook.md を参照してください。このスキル固有のエラーは次のとおりです。

• 医療従事者のNPI検索結果がない場合： 「[state]にいる[name]のNPI記録が見つかりませんでした。 名前が一般的すぎるか、プロバイダーが別の名前で診療している可能性があります。追加の情報（診療所名、NPI番号）を使って 試してみましょうか？」
• NPIの一致候補が複数ある場合： 「[state]にいる[name]のNPI記録が複数見つかりました。 どれか確認していただけますか？[NPI番号と専門分野を添えて上位3件を表示]」
• NPIページの抽出結果に不備がある場合： 「NPI検索ページはJavaScriptで描画されているようです。 ブラウザー描画を使って再試行しています……」（共通パターンに従い、--render を付けて自動再試行します）
• CSV／シートの解析エラー： 「入力ファイルを解析できませんでした。医療従事者名と、少なくとも1つの識別情報 （州、専門分野、または資格）を含む列が必要です。代わりにデータを直接貼り付けていただけますか？」
• 検証に必要なデータが不足している場合： 「州、資格、専門分野のない氏名のみのため、[N]人の医療従事者を検証できません。 識別情報を追加するか、リストから削除してください。」