nhcx-full

Version 1.9.3、2026-10-19 ビルド。NHA の NHCX パッケージ 1.0.0 に照らして確認済みです。

最初に読むこと：CORE

作業を始める前に、references/CORE.md を読み、タスク全体を通じてその内容を念頭に置いてください。その Instructions は必ず守る必要があります。すべてのステップおよびファイルで厳守し、各ステップ（L1 から L8）の開始時に読み直してください。その Confusions には、混同しやすい用語の意味が定められています。用語に曖昧さがある場合は、CORE.md の定義に従ってください。また、基本 URL と、各やり取りのルート、バンドル、ワークフロー ID、コールバックも記載されています。

どちら側か

このスキルは プロバイダー側 です。病院の HMIS に NHCX を組み込み、問い合わせ（適格性、プラン、事前承認、請求）を行って回答を受ける参加者を対象とします。同じスキルの payer/ フォルダーは 支払者側 です。保険会社、TPA、または制度システムとして、回答し、ケースを登録し、判定する参加者を対象とします。両者が共有するのはゲートウェイの設計だけです。ID（S1、A1、C1）はそれぞれ別に採番され、混在することはありません。

L1 の調査を開始した時点で、仕様との照合を始める前に側を決め、nhcx-plan/discovery.json と進捗ログの side に記録してください。

• provider：対象が患者を受け入れ、医療従事者や診療記録を管理し、保険会社に請求する場合、または請求窓口から請求を送信する場合は、このファイルに従ってください。このルートにある仕様、ステップ、参照資料を使用し、payer/ は完全に無視してください。
• payer：対象が加入者や受益者、商品や保険契約、およびその登録を管理する場合、請求窓口で請求を審査する場合、または資金を支払う場合は、ここでの作業を中止し、payer/SKILL.md を開いてください。そこに記載された内容を独立したスキルとして L1 から実行し、このルートにある仕様、ステップ、参照資料はすべて無視してください。リンク先はすべて payer/ 内にあります。
• both（患者を受け入れると同時に制度も運営するシステム）：側ごとに1つ、計2つの連携を行い、それぞれ独立して計画・記録してください。ユーザーが依頼した側を先に実施し、1つの計画ファイルで2つの ID セットを混在させないでください。

判断に迷う場合は、L1.1 の前に、対象がどちら側なのかユーザーに確認してください。後続のプロンプトで、もう一方の側が意図されていたと判明した場合は、corrected エントリーを記録し、正しい側で L1 からやり直してください。

まず更新してください

各タスクの開始時に、質問と L1 の前に、また作業を続ける後続の各プロンプトの開始時に、NHCX パッケージにこのスキルの新しいビルドが含まれているか確認してください。含まれている場合はインストールし、そのビルドを使って作業してください。

MCP やナレッジソースとは無関係です。 L1.0 で選択されたナレッジソースにかかわらず、確認では常に GitHub 上のパッケージを読み取ります。接続された nhcx-docs MCP はこの確認に応答せず、確認を省略することもありません。また、MCP の catalogue_info のバージョンをスキルのバージョンと比較することもありません。スキルのバージョンは独自のものです。パッケージのリリースタグでも、カタログのバージョンでも、1.0.0 でもありません。比較するのは skills/manifest.json にあるバージョンだけです。

1. パッケージのスキルマニフェストを読み取ります。 パッケージ（github.com/nha-in/nhcx-package）には、ビルド済みスキルのコピーが skills/ の下にあり、skills/manifest.json に各スキルのバージョン（プロバイダースキルは version、skills/payer/ の下のペイヤースキルは companion.version）、skills/CHECKSUMS.sha256 に全ファイルのハッシュが記載されています。https://raw.githubusercontent.com/nha-in/nhcx-package/main/skills/manifest.json から読み取ってください。読み取れない場合は、最新リリースの ZIP（nhcx-package/skills/manifest.json）（https://api.github.com/repos/nha-in/nhcx-package/releases/latest の ZIP）から読み取ってください。ナレッジソースとしてすでにダウンロード済みのパッケージは、main より古い可能性があるため、この確認には使いません。
2. 比較します。 パッケージの version を、このビルドの 1.9.3 と各要素を数値として比較します（1.10.0 は 1.9.2 より新しいバージョンです）。
3. パッケージのほうが新しい場合：取得してインストールします。 対象リポジトリの外に新しい空のフォルダーを作成し、スキルマニフェストにそのバージョンが記載されたリリース ZIP をダウンロードします。該当する ZIP がない場合は、https://codeload.github.com/nha-in/nhcx-package/zip/refs/heads/main の main アーカイブをダウンロードしてください。次に、skills/ 以下のすべてのファイルを CHECKSUMS.sha256 と照合します。その後、この SKILL.md の読み込み元フォルダーと、その隣にインストールされているすべての NHCX スキルフォルダー（nhcx-full、nhcx-coverage、nhcx-preauth、nhcx-claim、nhcx-communication、nhcx-payment、nhcx-reprocess、およびネストされた payer/）を、同じ名前のパッケージ内のコピーに丸ごと置き換えます。旧ビルドのファイルを残さないでください。プラグインマネージャー経由でインストールされたスキルは、そのバージョンが提供されている場合はプラグインマネージャーを通じて更新し、提供されていない場合は同様にスキルフォルダーを置き換えます。インストール時に対象リポジトリや nhcx-plan/ 内のものには一切触れません。ユーザーには「Updated the NHCX skills from 1.8.0 to 1.9.0 from the NHCX package.」のように1行で伝え、記録を残してから、インストールしたコピーの SKILL.md と CORE.md を再度読み取り、それに基づいて作業を続けます。その後、VERSION で変更後の手順に照らして完了した手順を再確認します。
4. 同じか古い場合： このビルドで作業を続けます。
5. アクセスできない場合、またはチェックサムが一致しない場合： このビルドで作業を続け、その理由を1行でユーザーに伝え、記録を残します。チェックサム検証に失敗したコピーは、一部であっても決してインストールしません。

確認結果はすべて nhcx-plan/knowledge.json の skill_update（checked_at、source、package_skill_version、installed_version、result：current、updated、unreachable、または checksum_failed）に記録し、nhcx-plan/progress.json にも記録します（ステップ L0、項目 skill update）。

まず質問してください

発見作業の前に、ナレッジソースを確認する前に、ファイルを読む前に、steps/L1-discovery.md のセクション L1.A にある質問を、番号付きのメッセージ1つにまとめてインテグレーターに尋ね、回答を待ってください。請求は登録済み患者から開始する必要があるか、また会員 ID は開始時に取得されるか。ケース作成後に保険プランを自動取得するか（デフォルト）、それとも窓口が取得するか。自動または手動のどちらで更新するか。また、支払者および保険契約ごとに一度取得するか、ケースごとに取得するか。支払者の InsurancePlan のどのフィールドが病院に必要か。事前承認ページで、給付内容の確認と承認要件の判定を提供するか。入院前に事前承認を申請できるか（その場合、入院情報は Claim タブで関連付けます）、また承認済みの患者が入院しなかった場合、何時間後に事前承認を取り消すか。追加書類、補足情報としての Aadhaar、生体認証が必要か。請求に入院が必要か。請求前に退院通知を送るか。窓口は更新ボタンで支払者の回答を確認するか、それともケースが固定間隔（頻度も確認）でポーリングするか。また、窓口が確認する必要のある支払者からの通知文書はどれか。すべての回答を nhcx-plan/plan.json の decisions に記録してください。質問がある項目について、推測に基づいて実装することはありません。

次の2つは、発見作業で回答が得られるため、質問しません。HMIS 自身の M1（ABHA の作成、リンク、検証、患者の ABHA 識別子、ABDM セッショントークン）は、L1.3 で見つかった場合に常に自動で再利用され、M1 がない HMIS のみが A19. ABHA Create and Verify (ABDM M1) を使用します。また、ホストの UI コンポーネント（入力補完、セレクト、テーブル、チップ、カード、アコーディオン、ダイアログ、日付選択、ファイル入力、フラッシュまたはトースト、ドットバッジ付きタブ）は L1.2 で確認し、すべての画面で使用します。

目標

アプリケーション内で NHCX ゲートウェイを実行し、保険証券の検索から支払いまでの NHCX プロバイダー側の請求機能を対象の HMIS に追加します。

このスキルには、この目標に必要な仕様のみが含まれます。対象仕様は SCOPE セクションに記載されています。ここで言及されているものの、このスキルに含まれていない仕様には、それを含むスキルが記されています。

要件

• 対象 HMIS のソースコード。ビルド、テスト、マイグレーションの各コマンドが動作すること。
• 施設の NHCX 参加者認証情報：参加者コード、ABDM クライアント ID とクライアントシークレット、およびそのコードに登録された暗号化証明書の秘密鍵。
• NHCX がアクセスできる公開 URL。参加者の endpoint_url として登録され、アプリケーションの受信パス（/in/<path> または /v1/<path>）にルーティングされていること。
• ナレッジソース：nhcx-docs MCP サーバー、または NHCX パッケージをダウンロードできるネットワークアクセス（KNOWLEDGE SOURCE を参照）。ABHA 呼び出し（A19）は、HMIS に独自の M1 がない場合にのみ必要で、MCP が必要です。パッケージには M1 が含まれていません。
• 受給者の生体認証（A18。すべての支払者で任意、PMJAY では必須）には、窓口のマシンに RD サービスを備えた登録済みの指紋または虹彩認証デバイス、あるいは顔認証用の患者の携帯電話上の ABHA アプリが必要です。また、セッショントークンを ABHA および生体認証サービスが受け入れるクライアント ID も必要です。
• エンドツーエンドテストには、サンドボックスの認証情報、応答するサンドボックス支払者、テスト用受給者が必要です。

ナレッジソース

NHCX の事実（API パスとヘッダー、FHIR プロファイルとサンプルバンドル、コード、ワークフロー ID、エラーコード、稼働開始ルール）は、1 つのナレッジソースから取得します。L1 の開始時に選択し、nhcx-plan/knowledge.json に記録します。詳細はreferences/KNOWLEDGE.mdを参照してください。

1. nhcx-docs MCP。 nhcx-docs MCP サーバーが接続されている場合（catalogue_info が応答する場合）は、それを使用してください：search_docs、get_operation、get_fhir_profile、get_fhir_example、validate_request、decode_error（NHCX バンドルに対して validate_fhir は使用しないでください。ABDM の DocumentBundle ファミリーしか認識しません。references/KNOWLEDGE.mdを参照してください）。
2. GitHub パッケージ。 それ以外の場合は、github.com/nha-in/nhcx-package/releases から最新リリースの zip（nhcx-package-v<version>.zip）をダウンロードし、nhcx-plan/knowledge/nhcx-package-v<version>.zip として保管し、nhcx-plan/knowledge/nhcx-package/ に展開して、MANIFEST と照合してください。

同じ MCP サーバーは、ABDM の HIE-CM カタログも提供します。ABHA の作成と検証（M1）、および M2 で HMIS が記録する医療記録と、このスキルが請求に添付するもの（D28. claim_document の「記録から」）は、このスキルではなく、サーバーから読み取ります（abdm-m2 プロンプトとreferences/KNOWLEDGE.mdのアトム）。A19. ABHA Create and Verify (ABDM M1)には、HMIS に独自の M1 がない場合にアプリケーションが行うこと、および get で読み取る M1 フローとオペレーション ID が記載されています。また、abdm-m1 プロンプトがそのルーターです。すでに M1 がある HMIS はそれを維持します。A19 は何も構築せず、ユーザーにも尋ねません。受益者の生体認証は、NHCX パッケージに含まれており送信がこれに依存するため、ここで完全に定義します：A18. Biometric Authenticationと、その本人確認カードであるS18. Beneficiary Verificationを参照してください。

プロトコルについては、これらの仕様よりナレッジソースを優先します。アプリケーションの動作については、仕様を優先します。プロトコルではない記述には、REF（リファレンス実装の選択）、PAYER（支払者アダプターによって異なる）、SANDBOX（サンドボックスでのみ確認）のいずれかのマーカーが付いています。支払者固有の値はすべてreferences/PAYERS.mdに記載されています。そこにある ID（C5 などの NHA ユースケース）は、このスキルの ID ではありません。nha:C5 のように記述してください。

手順

steps/INDEX.md の手順に順番どおり従ってください。各手順では、対象リポジトリ内の nhcx-plan/ に1つのファイルを書き込みます。また、各サブ手順とファイルの変更はすべて nhcx-plan/progress.json と nhcx-plan/progress.md に記録します（steps/LOG.md）。各プロンプトの終了時には、何を行ったかにかかわらず、レポートビルダーを実行して nhcx-plan/report.html を再構築してください。すべての計画ファイル（進捗、ログ、調査、マッピング、計画、コード、検証、ドライラン、エンドツーエンドの結果）をそれぞれ独立したタブに表示する、自己完結型のページにします。エラーを先頭に表示し、更新ボタンを設けます。nhcx-plan/make-report.sh と make-report.bat は10秒ごとにレポートを再構築します（steps/LOG.md）。

1. L1 Discovery：ナレッジソース、対象の技術、および SCOPE 内の各仕様項目について、検出済み、一部検出、未検出のいずれかをファイル名と行番号とともに記載します。
2. L2 Mapping：対象のフィールドをデータベースの列および FHIR 要素に対応付けます。
3. L3 Integration Planning：SCAFFOLDING の構築順に従って、この対象のフェーズ、手順、サブ手順を計画します。HMIS のホーム画面、サイドバー、またはナビゲーションバーに「Claims」項目を含めます。
4. L4 Code Planning：SCAFFOLDING を対象の規約に合わせて適用し、ファイル、関数、実装順を定めます。
5. L5 Write Code：スキャフォールディングの依存関係ルールを守り、nhcx-plan/code.json に記録しながら、ファイルごとにコードを書きます。
6. L6 Validate Code：各ファイルを仕様と照合して検証します。
7. L7 Dry-run Tests：ネットワークを使用せず、NHCX とレジストリのフェイクを使います。
8. L8 End-to-end Tests：NHCX サンドボックスを使い、references/TESTS.md の T テストを、それぞれ画面（GUI）とコマンドライン（CLI）から実行します。

骨組み

references/SCAFFOLDING.md には、対象 HMIS におけるコードの構成が記されています。L3 の前に読み、L5 まで開いたままにしてください。

• 1 つの NHCX モジュール（nhcx/）に、gateway/（G、インプロセス）、fhir/（F、純粋なビルダーとパーサー）、services/（A）、callbacks/（C）、models/ と migrations/（D）、screens/ と routes（S）、およびメッセージの archive を含めます。
• 既存の HMIS モジュールは、NHCX に必要なフィールドのみ変更します。患者の ABHA（D3。HMIS 独自の M1 がある場合はそれを介し、ない場合は A19 を通じて検証または作成）、医療従事者の HPR id と資格（D2）、施設の HFR id と参加者コード（D1）、および「Claims」ナビゲーション項目です。
• ホストのコンポーネント。 すべての画面は、HMIS 独自のコンポーネントを使って構築します。L1.2 では、各種コンポーネント（入力候補表示、選択、テーブル、チップ、カード、アコーディオン、ダイアログ、日付ピッカー、ファイル入力、フラッシュまたはトースト、ドットバッジ付きタブ）について記録します。これにより、異なる HMIS でも、それぞれの部品を使って同じ画面を作成できます（references/SCREENS.md、コンポーネントキット）。コンポーネントを新たに作成するのは、ホストに該当する種類のものがない場合に限り、ホストのデザイントークンでスタイルを設定します。
• 患者のキーは ABHA です。 「記録から」添付された記録と、ケースに関連付けられた入院は、そのケースの ABHA 番号で検索します。
• 基本ルール：事前承認は請求の背後でロックされます。 事前承認が承認され、請求が支払者に送られた後は、事前承認は読み取り専用になります。増額や変更はできず、取り消しのみ可能です。ただし、支払者が請求を判断するまでに限ります。変更を試みた場合は「請求は支払者に送られているため、事前承認は読み取り専用です。増額や変更はできません。支払者が請求を判断するまでの間に限り、取り消すことができます。」と拒否します。遅れて取り消そうとした場合は「支払者が請求を判断したため、事前承認を取り消すことはできなくなりました。」と拒否します。受付時点で拒否された請求は支払者に届いていないため、事前承認は未確定のままです。
• 判断済みの請求は再送しません。 却下された請求は再処理（ワークフロー 36、理由 claimrejected または rejectiondisputed）に回します。承認または一部承認された請求では、残額を請求するリリースを申請できます。
• 依存関係のルール： 画面はサービスを呼び出し、読み取りモデルを参照します。請求テーブルに書き込むのはサービスとコールバックのみです。FHIR ビルダーはデータベースにもゲートウェイにもアクセスしません。ゲートウェイは請求について何も把握しません。ポーリングで見つかった返信も、同じコールバックハンドラーで適用します。
• リポジトリ外に置くもの： ゲートウェイ設定、クライアントシークレット、秘密鍵、台帳、アーカイブディレクトリ。
• テストは tests/nhcx/（ドライランとエンドツーエンド）に、計画ファイルは nhcx-plan/ に置きます。
• ビルド順序は、ゲートウェイの基盤からナビゲーション項目までのフェーズで構成します。L3 はこの順序で計画し、仕様が SCOPE に含まれないフェーズは除外します。

L4 では、L1 で調査した対象の規約に従って、言語、フレームワーク、モジュール形式を問わず、これらの仮の名前を対象独自の規約に対応付けます。各部分の分割と依存関係の方向は変わりません。どの仕様も、特定のフレームワーク、ORM、ルーター、コンポーネントライブラリを前提としていません。

SCOPE

このスキルに含まれる仕様：

• Screens (19): S1, S2, S3, S4, S5, S6, S7, S8, S9, S10, S11, S12, S13, S14, S15, S16, S17, S18, S19
• APIs (18): A1, A2, A3, A4, A5, A6, A7, A8, A10, A11, A12, A13, A14, A15, A16, A17, A18, A19
• Callbacks (10): C1, C2, C3, C4, C5, C6, C7, C8, C9, C10
• FHIR (19): F1, F2, F3, F4, F5, F6, F7, F8, F9, F10, F11, F12, F13, F14, F15, F16, F17, F18, F19
• Database (32): D1, D2, D3, D4, D5, D6, D7, D8, D9, D10, D11, D12, D13, D14, D15, D16, D17, D18, D19, D20, D21, D22, D23, D24, D25, D26, D27, D28, D29, D30, D31, D32
• Gateway (11): G1, G2, G3, G4, G5, G6, G7, G8, G9, G10, G11
• Tests (19): T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15, T16, T17, T18, T19

同じソースから作成されたその他のスキル：

• nhcx-coverage：受益者の保険プラン検索と給付対象資格の確認。
• nhcx-preauth：事前承認：支払者のプラン、そのプランから引用した明細、給付対象範囲と承認要件の確認、事前承認、追加承認、キャンセル、ステータス。
• nhcx-claim：退院後の請求提出、その判定結果とステータス。
• nhcx-communication：支払者からの問い合わせ、通知、メモ、およびそれらへの返信。
• nhcx-payment：支払通知とその確認応答。
• nhcx-reprocess：判定済みまたは一部支払い済みの請求の再処理と残高解放。

VERSION

これは nhcx-full バージョン 1.9.3 で、2026-10-19 に構築されました。プロトコルテーブル（ワークフロー ID、ステータス、ベース URL）は、NHA の NHCX パッケージ 1.0.0（github.com/nha-in/nhcx-package）と照合済みです。

• 作業の開始時に記録してください：nhcx-plan/knowledge.json と nhcx-plan/progress.json の target には skill と skill_version が記録され、nhcx-plan/report.html のヘッダーにも表示されます。
• UPDATE FIRST により、プロンプトの開始時に NHCX パッケージから新しいビルドがインストールされている場合があります。その場合、記録されるバージョンは古いものです。
• 後続のプロンプトで、このスキルのバージョンが記録済みのものと異なる場合は、続行する前にその旨をユーザーに伝え、両方のバージョンを明記した corrected エントリーとして記録し、変更された仕様に照らして完了済みの手順を再確認してください。
• KNOWLEDGE SOURCE の記載どおり、1.0.0 より新しいナレッジソースがある場合は、プロトコルについてはそちらを優先し、knowledge.json に差異を記録してください。

1.9.3 での変更点。以前のビルドから作業を続ける場合は、以下の内容を再確認してください。

• S17 の「In network」は、1.9.2 の「valid cover」ルールに置き換わります。支払者からいずれかの患者の保険プランをこの病院が取得すると（D10 のプランが ready で確定すると）、その支払者はネットワーク内になります。D32 に plan_fetched_at が追加されます（C4 が一度だけ設定し、取得済みプランからの移行によって値を埋めます。更新時にクリアされることはありません）。支払者チェックでは、未設定の場合に取得済みプランから値を一度だけ設定し、on_network と plan_fetched_at を返します。画面には「In network: this hospital has fetched an insurance plan from .」という緑のチェック付きの行が 1 つ表示されるか、何も表示されません。 1.9.2 の変更点。以前のビルドを続行する際に、再確認してください。
• S17「ネットワーク内」：適格と回答した支払者の保険のみを対象とします。該当する場合は、緑のチェックマーク付きで「ネットワーク内：この病院は、有効な補償がある 件の の保険を保有しています。」という行を 1 行だけ表示し、該当しない場合は何も表示しません。
• 過去の日付での事前承認は不可：S4 の入院日付ピッカーは今日から選択できるようにし、過去の日付で新しい事前承認を保存または送信しようとした場合は、「入院日は今日より前にできません。事前承認を遡及して申請することはできません。」と拒否します（D9、A4、S9）。支払者がすでに保有している日付は、そのままでもかまいません。
• S4 の各診断には「暫定」または「確定」の区分を付けます（D25 dx_type）。PMJAY の送信形式に合わせ、F8 diagnosis.type として SNOMED CT 148006 または 89100005 を送信します。
• S11 の退院日付ピッカーは今日まで選択できるようにし、未来の日付は「退院日は今日より後にできません。」と拒否します（D20）。
• 請求の判定は、承認額の全額または一部が承認された場合、「最終承認」と表示します（ステージが Claim の S11、S5）。事前承認のラベルは変更しません。
• 支払い：ワークフロー 30 で、すべての金額を含み UTR のない paid として開始し、31 で UTR を含む cleared として完了します。どちらも同じ PaymentNotice ID を使用します。支払い済みとは、ステータスが cleared であるか、paid で UTR がある状態を指します。UTR のない paid 通知は開始済みであり、請求書には決して転記されません（F13、D21、A17、C10、S12、A8）。従来の「disposition に initiat が含まれる」というルールは廃止されました。S12 の「開始済み、UTR 待ち」チップは、UTR がなく、ステータスが cleared 以外の場合に表示します。
• S12 の不足額は請求額ではなく、請求の承認額を基準に算出します。通知で計上される金額（通知ごとに、その支払い、TDS および控除の各明細がある場合はそれら、なければ通知の金額）が承認額と等しければ不足額はありません。それ以外の場合は、承認額から計上額を差し引いた金額とし、0 を下回らないようにします（D21、D22、A17 payment_approved、payment_accounted、payment_shortfall）。4 番目のタイルは、請求額ではなく「承認済み」（請求の承認額）です。

1.9.1 の変更点。以前のビルドを続行する際に、再確認してください。

• NHCX 設定ページ（S19）は独立した計画フェーズです（L3 フェーズ 3。D1、参加者マスター D32 とその日次更新を含みます）。常に実装し、HMIS の施設設定の下に独自の「NHCX」項目を設けます。S19 がないビルド、または参加者マスターがないビルドでは、それらを追加します。S19 は現在、参照仕様に一致しています。参加者コードはゲートウェイのデフォルト値を代わりに使用し、レジストリカードでエンドポイントを登録し（「レジストリを更新」）、キーのカードでステージング、証明書の登録、有効化、失効を実行し、カードから医師およびスタッフのマスターにリンクします。S17 と S18 は、それぞれフェーズ 4 と 6 に配置します。L3 では、スキルに列挙されているすべての画面について、実装済みか、理由を付けて対象外にしたことを確認します。L8 では、請求のテストを始める前に S19 を開きます。

1.9.0 の変更点。以前のビルドを続行する際に、再確認してください。

• 先に更新すること：すべてのプロンプトで、最初に NHCX パッケージのスキルマニフェスト（skills/manifest.json）を読み込み、skills/CHECKSUMS.sha256 と照合したうえで、パッケージのビルドのほうが新しければインストールします。
• 人に表示するすべてのステップ、サブステップ、テスト、仕様 ID には、その名称を付けます（L3 Integration Planning、T3 ... (CLI): pass）。名称は L1.2 で nhcx-plan/names.json から取得して書き込みます（LOG.md、LOGN）。 1.8.0 での変更点。以前のビルドから作業を続ける際は、以下と照合してください。
• 手順はフレームワークに依存しません。L1 ではホストのスタックとコンポーネントを種類ごとに記録し、L4 と L5 ではそれらからすべての画面を構築し、L6 ではコンポーネントの重複を拒否します。
• 既存の M1 は確認せずに再利用し、A19 と S13〜S15 の ABHA 追加項目は、M1 が存在する場合は L3 で削除します。記録と入院は ABHA で検索します。
• plan.trigger は症例作成後、自動をデフォルトとします。同じ保険の準備完了済みプランがあれば再利用し、なければ要求します。明細項目、給付内容の確認、承認要件の判定は「事前承認」タブに配置し、各明細は支払者の保険プランから引用します（Blood や Ambulance など、給付内容だけの項目を明細にすることはありません）。
• 参加者マスターのエンティティタイプに応じて、2 つの支払者アダプター gov と generic を選択します（pmjay は gov、kyrocare は generic として扱います）。アダプター名は表示しません。
• 保険プランのリクエストとステータス照会はワークフロー ID 1 で送信します。照会への回答は request.initiated として送信します。
• 請求のタブは「概要」「事前承認」「請求」「コミュニケーション」「支払い」「ログ」（新しい順。相関 ID が表示されるのはここだけ）です。支払者から新着情報がある場合は、タブの横にドットが表示されます。事前承認が申請されると、「請求」と「支払い」タブが表示されます。
• 決定済みの請求は再送信しません。再処理を求めるのは却下された請求のみで、承認済み請求の残額の支払いはそのまま維持されます。
• 基本ルール：請求が支払者に送信された後、事前承認は読み取り専用となり、増額や変更はできません。また、支払者が請求を決定するまでに限り、キャンセルできます。

参考資料

• references/CORE.md：ベース URL と、各エンドポイント、バンドル、ワークフロー ID、コールバックを含むすべてのやり取りを 1 ページにまとめています。
• references/KNOWLEDGE.md：NHCX のナレッジソース、MCP または GitHub パッケージ、および各検索で回答する質問を説明しています。
• references/SCREENS.md：対象範囲のすべての画面、そのルート、および機能を説明しています。
• references/API.md：対象範囲のすべての API 呼び出しとその機能を説明しています。
• references/CALLBACK.md：対象範囲のすべての NHCX コールバックとその機能を説明しています。
• references/GATEWAY.md：インプロセス NHCX ゲートウェイの各部分とその機能を説明しています。
• references/FHIR.md：対象範囲の、送信または読み取りを行うすべての FHIR リソースとその内容を説明しています。
• references/DATABASE.md：対象範囲のすべてのテーブルについて、各行の内容と、それを使用する画面、API、コールバック、FHIR リソースを説明しています。
• references/PAYERS.md：支払者アダプター、ワークフロー ID とルール、および REF、PAYER、SANDBOX マーカーの意味を説明しています。
• references/OPERATIONS.md：本番環境への切り替えと、複数インスタンスとしてアプリケーションを実行する方法を説明しています。
• references/TESTS.md：対象範囲のすべてのエンドツーエンドテストについて説明しています。IRDAI と PMJAY の各テストは、画面とコマンドラインから実行します。
• references/READSETS.md：各画面、API、コールバック、ゲートウェイ部分の実装前に読むべき、関連する仕様を説明しています。
• references/SCAFFOLDING.md：ターゲットのモジュール構成、各部分の内容、および各仕様の配置先を説明しています。

出力

対象リポジトリ内には、次のものを用意します。

• コード：SCAFFOLDING の構成に従った NHCX モジュールと、変更した HMIS モジュールのコード。
• テスト：tests/nhcx/ 配下のドライラン（L7）とエンドツーエンド（L8）のテスト。エンドツーエンドのテストには、GUI ランナーと CLI ランナー（nhcx-e2e）を用意します。
• 計画ファイル：nhcx-plan/ 配下の knowledge.json、discovery.json、mapping.json、plan.json、code-plan.json、code.json、validation.json、dry-run.json、e2e.json、names.json（すべての ID の名前）、progress.md を含むログ progress.json、および report.html。これらは、レポートビルダー（report.py または対象言語の同等のもの）によって各プロンプトの最後に再生成します。そのレポートビルダーと同じ場所に make-report.sh と make-report.bat も配置します。