nhcx-reprocess

バージョン 1.11.0、2026-10-25 にビルド、NHA の NHCX パッケージ 1.0.0 に照らして確認済み。

最初に読む：CORE

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

どちらの側か

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

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

• provider：対象が患者を受け入れ、医療従事者と診療記録を管理し、保険会社に請求する、または請求部門から請求を送信する場合は、このファイルと、このルートにある仕様、ステップ、参照資料を使って続行し、payer/ は完全に無視してください。
• payer：対象が加入者または受益者、商品または保険契約とその加入情報を管理し、請求部門で請求を査定する、または資金を支払う場合は、ここで作業を止めて payer/SKILL.md を開き、独自の L1 からスキル全体の手順に従ってください。このルートにある仕様、ステップ、参照資料はすべて無視してください。リンク先はすべて payer/ 内にあります。
• both（患者を受け入れ、かつ制度も運営するシステム）：側ごとに計画と記録を分けて、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.11.0 と、各部分を数値として比較します（1.10.0 は 1.9.2 より新しいバージョンです）。
3. パッケージ内のバージョンのほうが新しい場合は、取得してインストールします。 スキルマニフェストにそのバージョンが記載されたリリース ZIP をダウンロードします。それがない場合は、main のアーカイブ https://codeload.github.com/nha-in/nhcx-package/zip/refs/heads/main を、ターゲットリポジトリの外にある新しい空のフォルダーにダウンロードし、skills/ 配下のすべてのファイルを CHECKSUMS.sha256 と照合します。その後、この SKILL.md が読み込まれたフォルダーと、その隣にインストールされているすべての NHCX スキルフォルダー（nhcx-full、nhcx-coverage、nhcx-preauth、nhcx-claim、nhcx-communication、nhcx-payment、nhcx-reprocess、およびネストされた payer/）を、同じ名前のパッケージ内のコピーで丸ごと置き換えます。古いビルドのファイルを残してはいけません。プラグインマネージャー経由でインストールされたスキルは、そのバージョンが提供されている場合はプラグインマネージャー経由で更新し、提供されていない場合は同じ方法でスキルフォルダーを置き換えます。インストールによってターゲットリポジトリや nhcx-plan/ 内のものが変更されることはありません。ユーザーに1行で伝え（「NHCX パッケージから NHCX スキルを 1.8.0 から 1.9.0 に更新しました。」）、記録した後、インストールしたコピーからこの 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）。

ASK FIRST

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

ディスカバリーで明らかになるため、尋ねない項目が2つあります。HMIS 自体の M1（ABHA の作成、リンク、検証、患者の ABHA 識別子、ABDM セッショントークン）は、L1.3 で見つかった場合は自動的に再利用し、持っていない HMIS にのみ A19. ABHA Create and Verify (ABDM M1)（nhcx-coverage）が必要です。また、ホストの UI コンポーネント（入力補完、選択、テーブル、チップ、カード、アコーディオン、ダイアログ、日付ピッカー、ファイル入力、フラッシュまたはトースト、ドットバッジ付きタブ）は L1.2 で特定し、すべての画面で使用します。

GOAL

対象の HMIS に NHCX の請求再処理と残高解放を追加します。

このスキルには、この目標に必要な仕様のみが含まれます。該当する仕様は SCOPE セクションに記載されています。ここに含まれない、記載された仕様には、それを含むスキルが示されています。

REQUIREMENTS

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

KNOWLEDGE SOURCE

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）、および HMIS が M2 の下でファイルする医療記録と、このスキルが請求に添付する内容（D28. claim_document「記録から」）は、このスキルではなく、そこから読み取ります（abdm-m2 プロンプトと references/KNOWLEDGE.md のアトム）。nhcx-coverage の A19. ABHA Create and Verify (ABDM M1) には、HMIS に独自の M1 がない場合にアプリケーションが行うこと、および get で読み取る M1 フローと操作の ID が記載されており、abdm-m1 プロンプトがそのルーターです。すでに M1 を備えている HMIS はそれを維持します。A19 は何も構築せず、ユーザーにも尋ねません。受益者の生体認証は、NHCX パッケージに含まれており送信がそれに依存するため、証明用のプレゼンスカードである nhcx-coverage の S18. Beneficiary Verification とともに、ここにある nhcx-coverage の A18. Biometric Authentication で詳細に定義されています。

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

ステップ

このスキルはマイルストーンモードのみでビルドします。ビルドは、milestones/INDEX.md にある請求ライフサイクルの垂直スライスに分割され、次のスライスに進む前に、各スライスをすべてのステップまで完了させます。レイヤーモードはありません。すべての仕様に対してL1を実行してから、すべての仕様に対してL2を実行する、といった進め方はしないでください。これは以前の方式であり、使用しません。nhcx-plan/knowledge.json に "mode": "milestone" を記録します。

各ステップでは、対象リポジトリ内の nhcx-plan/<Nx>/ にマイルストーンごとに1つのファイルを作成します。また、すべてのサブステップとファイル変更を nhcx-plan/progress.json と nhcx-plan/progress.md に記録します（steps/LOG.md）。各プロンプトの最後には、実行内容にかかわらず、nhcx-plan/report.html を再生成します（steps/LOG.md）。レポートには、概要（KPI、マイルストーンステッパー、マイルストーンとステップのマトリックス）、ブートストラップタブ、各マイルストーンのタブ（L1からL7までのステップと記録）、エンドツーエンドタブ、ログタブが含まれます。nhcx-plan/make-report.sh once で再生成し、make-report.sh watch で最新の状態を維持します。

各マイルストーンで実施する7つのステップ（ディスカバリーからドライランまで）は次のとおりです。

1. L1 Discovery：ナレッジソース、対象の技術、およびそのマイルストーンで提供するすべての仕様項目について、見つかったもの、一部のみ見つかったもの、見つからないものを、ファイル名と行番号とともに記録します。
2. L2 Mapping：マイルストーンのフィールドをデータベースのカラムとFHIR要素に対応付けます。
3. L3 Integration Planning：SCAFFOLDING のビルド順序に沿って、対象におけるマイルストーンのフェーズ、ステップ、サブステップを計画します。これには、HMISホーム画面、サイドバー、またはナビゲーションバーの「Claims」エントリーも含まれます（N0）。
4. L4 Code Planning：SCAFFOLDING を対象の規約に適用して、マイルストーンのファイル、関数、実装順序を整理します。
5. L5 Write Code：ファイルごとに nhcx-plan/<Nx>/code.json に記録し、スキャフォールディングの依存関係ルールを守ります。
6. L6 Validate Code：各ファイルを仕様に照らして検証します。
7. L7 Dry-run Tests：ネットワークは使用せず、NHCXとレジストリにはフェイクを使用します。モックのゲートウェイとスタブ化したコールバックに対して、各マイルストーンの完了条件をここで証明します。

続いて、すべてのマイルストーンのドライランが成功した後に一度だけ、マイルストーンごとではなく、次を実行します。

8. L8 End-to-end Tests：NHCXサンドボックスに対して、ライフサイクル全体（N1からN6まで）と、references/TESTS.md にあるTテストを実行します。それぞれ画面（GUI）とコマンドライン（CLI）の両方から実行し、リポジトリのルートに nhcx-plan/e2e.json を1つ作成します。

マイルストーン

ビルドでは、milestones/INDEX.md の各スライスを依存関係の順序に従って実行します。順序は N0 Foundation、次に N1 Search Policy、N2 Coverage and Insurance、N3 Pre-authorisation and Biometric、N4 Communication、N5 Claim、N6 Payment です。各マイルストーンでは、提供する仕様 ID のみに対して、上記の7つのステップ（L1〜L7、調査からドライランまで）を実施します。また、依存するマイルストーンを明示し、それらが構築したものを作り直さずに再利用します。L8 のエンドツーエンドはマイルストーンには含まれません。ライフサイクル全体を対象に、最後に一度だけ実行します。

• 最初にグローバルなブートストラップを行います。 N0 の前に、L1.0（ナレッジソース）、L1.1（NHCX のスキャン）、L1.2（対象のテクノロジーとコンポーネントキット）、L1.3（ABDM モジュール）を一度実行します。これらはスライスではなく対象に固有の情報なので、一度だけ確認し、プランのルートにある nhcx-plan/knowledge.json と nhcx-plan/discovery.json のテクノロジー部分に記録します。すべてのマイルストーンがこれらを読み込みます。
• 一度に1つのマイルストーンを、順番どおりに進めます。 依存するすべてのマイルストーンが完了するまで、そのマイルストーンには進みません。まず N0、その後 N1 の前に N2、N2 の前に N3、N3 の前に N4 と N5、N5 の前に N6 を完了します。N4 と N5 はどちらも N3 に依存しており、どちらを先に完了してもかまいません。
• プランファイルはスコープごとに分けます。 各マイルストーンでは、提供する ID を対象に L1〜L7 を実行し、独自のファイルを nhcx-plan/<Nx>/ の下に作成します（discovery.json、mapping.json、plan.json、code-plan.json、code.json、validation.json、dry-run.json）。最後の L8 では、マイルストーンごとではなく、ルートに nhcx-plan/e2e.json を1つ作成します。
• 一度提供し、その後は再利用します。 各仕様は、必ず1つのマイルストーンだけが提供します。2つのマイルストーンが対象とする仕様は、先行するマイルストーンが構築し、後続のマイルストーンはそれを作り直さずに再利用します。後続側では、追加した拡張を記録します（たとえば、N5 では N3 の F8. Claim (in nhcx-preauth) ビルダーを use: claim 用に拡張します）。
• ドライランで実証できたら完了です。 ドライランで完了条件を満たした場合にのみ、マイルストーンは done になります。つまり、コードが作成され、検証され、ゲートウェイをモックし、コールバックをスタブ化した状態でドライランのテストに合格している必要があります。次のマイルストーンに未完成のまま進むことはありません。サンドボックス環境での実証は最後の L8 で行い、最後のマイルストーンのドライランが成功した後、ライフサイクル全体を対象に一度だけ実行します。
• 続けて進め、マイルストーン間やその中のステップ間で中断しないでください。 マイルストーンはすべてオフラインで実行できます（ドライランにネットワーク接続やサンドボックスの認証情報は不要です）。そのため、あるマイルストーンのドライランが成功したら、何かを尋ねるために停止せず、次のマイルストーンへそのまま進みます。マイルストーンの中でも中断しないでください。各ステップを確認待ちなしで順番に実行します。特に規模の大きいマイルストーン（上記の N3）や経過時間は、停止して報告する理由にはなりません。ドライランが成功する前に停止するのは、デフォルトでは解決できない真のブロッカーがある場合だけです。サンドボックスの認証情報、到達可能な公開エンドポイント、テスト用の被保険者について尋ねるのは、最後のエンドツーエンドステップ（L8）で一度だけです。N0 の後や、マイルストーン間で尋ねることはありません。それ以前に質問できるのは、一度だけ行う ASK FIRST の項目のみです。

各ステップのファイルには、そのステップで行う内容が記載されています。各実行のスコープは、マイルストーンと、そのマイルストーンが提供する ID によって決まります。ASK FIRST の質問、ナレッジソース、スキャフォールディング、仕様は、すべてのマイルストーンで共通です。

スキャフォールディング

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

• NHCX モジュールは 1 つ（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 で記録されています。そのため、異なる 2 つの HMIS でも、それぞれ独自のパーツで同じ画面を構成できます（references/SCREENS.md、コンポーネントキット）。コンポーネントを実装するのは、ホストに該当する種類のものがない場合のみとし、ホストのデザイントークンを使ってスタイルを設定します。
• 患者のキーは ABHA です。 「From records」から添付された記録と、ケースに紐づく入院は、ケースの ABHA 番号で検索します。
• 中核ルール：事前承認は請求に連動してロックされます。 事前承認が承認され、請求が支払者に送信された後は、事前承認は読み取り専用になります。拡張も変更もできず、取り消しのみ可能ですが、これも支払者が請求を審査している間に限られます。変更は「請求が支払者に送信されたため、事前承認は読み取り専用です。拡張または変更はできません。支払者が請求を審査している間に限り、取り消すことができます。」というメッセージで拒否され、期限後の取り消しは「支払者が請求の審査を終えたため、事前承認を取り消すことはできません。」というメッセージで拒否されます。受付時に拒否された請求は支払者に届いていないため、事前承認はオープンのままです。
• 審査が確定した請求は、再送信しません。 却下された請求は再処理（ワークフロー 36、理由は claimrejected または rejectiondisputed）として戻されます。承認または一部承認された請求は、残額の請求（リリース）が可能です。
• 依存関係のルール： 画面はサービスを呼び出し、リードモデルを読み取ります。請求テーブルに書き込むのはサービスとコールバックのみです。FHIR ビルダーはデータベースにもゲートウェイにもアクセスしません。ゲートウェイは請求について何も知りません。ポーリングで見つかった応答は、同じコールバックハンドラーで適用します。
• リポジトリの外部に置くもの： ゲートウェイ設定、クライアントシークレット、秘密鍵、台帳、アーカイブディレクトリ。
• テストは tests/nhcx/（ドライランとエンドツーエンド）、プランファイルは nhcx-plan/ に配置します。
• ビルド順序は、ゲートウェイの基盤からナビゲーション項目まで、フェーズ順です。L3 ではこの順序で計画し、仕様が SCOPE に含まれないフェーズは除外します。

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

対象範囲

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

• 画面（4）：S5、S6、S11、S19
• API（6）：A6、A10、A11、A12、A13、A17
• コールバック（2）：C1、C8
• FHIR（7）：F1、F3、F10、F15、F16、F17、F18
• データベース（19）：D1、D2、D3、D8、D9、D11、D12、D13、D15、D16、D17、D18、D20、D21、D23、D28、D29、D30、D32
• ゲートウェイ（11）：G1、G2、G3、G4、G5、G6、G7、G8、G9、G10、G11
• テスト（4）：T1、T2、T12、T20

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

• nhcx-full：医療提供者側のNHCX連携全体と、すべての交換処理を最初から最後まで網羅します。
• nhcx-coverage：受益者の保険プラン検索と給付資格の確認。
• nhcx-preauth：事前承認：支払者のプラン、そのプランから見積もられた明細項目、給付範囲と承認要件の確認、事前承認、増額、キャンセル、ステータス。
• nhcx-claim：退院後の請求提出、その判定とステータス。
• nhcx-communication：支払者からの照会、通知、メモ、およびそれらへの返信。
• nhcx-payment：支払い通知とその受領確認。

バージョン

これはnhcx-reprocessバージョン1.11.0で、2026-10-25にビルドされました。このプロトコルの表（ワークフロー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.11.0 での変更点。以前のビルドを続行する際の再確認用（いずれも、2026年10月24日に、1つの HMIS 上で 1.10.0 を実行した2回の実環境テストから学んだ内容です）：
• 支払いの識別には PaymentNotice.id だけを使わなくなりました（D21. claim_payment ルール4、C10. Payment Notice (in nhcx-payment)、F13. PaymentNotice (in nhcx-payment)）。サンドボックスの支払者は PaymentNotice.id を送信しないため、1件の支払いに対する workflow-30 と workflow-31 の通知が別々の行として登録され、S12 では消し込み済みのカードのほかに、誤って「開始済み、UTR 待ち」のカードが表示されました。現在は、PaymentNotice.id、それがない場合は消し込みの detail[] 支払者識別子（<paymentId>/Payment）に含まれる支払い ID、それもない場合は、同じ金額と日付で UTR のない最新の paid 行の順に識別します。プレースホルダーの UTR（Not available など）は null として保存されます。
• C4 はシード済みプランを置き換えます（C4. Insurance Plan Reply (in nhcx-preauth)、T13. PMJAY Eligibility, Package Master and Ruling (in nhcx-coverage)）。T13 のテストシードとしてマークされた ready 行は支払者からの返信を受け取ります。シードは C4 独自の適用経路を通るため、シードされたすべてのドキュメントに表示情報とステージが設定されます。シードによって ready になった後、C4 がすべての返信を無視した実行では、PMJAY のマスターを一度も確認できませんでした。
• ステージは pre または post のみで保存され、D11 の post を示す語に bill、hospital bill、lama、dama、death、mortality が追加されました（D11. claim_plan_benefit）。裁定が保留されている場合、フォーム名にかかわらず、指定されていないフォームはクレーム側に分類されます（D12. claim_plan_form）。
• 退院サマリーは、どのカテゴリで登録された場合でも HDS に格納されます（F8. Claim (in nhcx-preauth)）。
• D10 の再利用では response_json をコピーしなくなりました（18 MB のマスターを29件コピーすると、データベースが645 MBになったためです）。
• GUI テストの実行ではブラウザーを操作するか、状態を blocked にします（T2. Test Runners、L8）。ブラウザードライバーは確認を求めずにセットアップ中にインストールされます。成果物は PNG スクリーンショットです。各ランナーは独自のクレームを開きます。e2e.json のエントリーには browser と plan_source が含まれます。T10 では入院に対する請求書を発行し、T11 で D21 の計上を検証します。T11 では支払いごとにカードが1枚だけ表示され、状態が posted であることを確認します。
• 実行後に機能テストレポートを作成します（T20. Functional Test Report、nhcx-e2e report）。GUI ランナーはプロセス全体（サインイン、各ステップの前後、すべての拒否、最後の各タブ、URL が指定されている場合は支払者のデスク）をスクリーンショットで記録します。ビルダーは、機能テスト監査レポートの形式（表紙ブロック、文書管理、目次、要件表、範囲、実行詳細、方法論、ツール、各テストステップにつき番号付きの証拠セクション1つと、そのスクリーンショットおよび1行の説明、概要）に沿った PDF と、ステップごとに1行を記載した Excel ブックを生成します。会社名は記載せず、認証情報も印字しません。T1 に NHCX_TEST_FT_* と NHCX_TEST_PAYER_DESK_URL の新しい変数が追加され、e2e.json のステップには expected と screenshots が含まれます。
• L6 に機械的チェックが3つ追加されました（SCAFFOLDING のレイアウト、ステージの語彙、ハンドラー経由のフィクスチャ）。また、L7 にテストが4つ追加されました（クレーム上の HDS、実際の PMJAY マスターに対する D11 ルール、シードに対する C4、2つの通知がある支払い）。LOG.md：エントリーは発生時に記録し、コミットがブランチ上にあることを確認します。L1.A：SCOPE 内の仕様は、実行自体によって破棄されることはありません。 1.10.0 の変更点。以前のビルドを続行するときに再確認してください。
• ビルドはマイルストーンモードのみで実行されるようになりました（milestones/INDEX.md）。クレームライフサイクルの垂直スライス（N0 Foundation、N1 Search Policy、N2 Coverage and Insurance、N3 Pre-authorisation and Biometric、N4 Communication、N5 Claim、N6 Payment）を、各マイルストーンが提供する仕様 ID のみを対象に、依存関係の順に、再構築せず再利用しながら、L1 から L7（ディスカバリーからドライラン）まで進めます。各マイルストーンには独自のドライラン完了条件と、nhcx-plan/<Nx>/ 配下の独自の計画ファイルがあります。従来のレイヤー別実行（すべての仕様を一つのステップで処理してから次のステップに進む方式）は廃止されました。従来のレイヤー構成で以前のビルドを開始していた場合、既存の nhcx-plan/ ファイルは保持されますが、新しいステップはすべてマイルストーンごとに実行され、レポートもマイルストーンごとに再構築されます。report.html はマイルストーンごとに構成され、各マイルストーンを開くと、そのステップとサブステップが表示されます。
• エンドツーエンド実行は、マイルストーンごとではなく、最後に一度だけ行います。 マイルストーンはドライラン（L7）で終了し、モックゲートウェイとスタブ化されたコールバックを使って完了条件を実証します。L8 のエンドツーエンド実行はマイルストーンのループから切り離され、すべてのマイルストーンのドライランが成功した後に一度だけ実行されます。サンドボックスに対してライフサイクル全体を N1 から N6 まで実行し、ルートにある nhcx-plan/e2e.json を一つ生成します。レポートにはマイルストーンの後に共通のエンドツーエンドタブが一つ追加され、各マイルストーンタブには L1 から L7 までの七つのステップが表示されます。

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

• 完全に new のテーブルでは、L2 マッピングで fields[] を列ごとに列挙しなくなりました。このようなテーブルは tables[] に一度だけ記録され、L5 は列を D 仕様から読み取ります。fields[] に含まれるのは、後続のステップで処理する項目（実際の対象位置を持つ mapped 列または要素、あるいは解決方法がある missing／conflict）のみになりました。L4 のコード計画では、仕様ですでにレイアウトが確定しているファイル（F、A、C、D、画面）の functions[] と、ファイルごとのテストルール一覧を事前に列挙しなくなりました。これらはどちらも L5／L7 で再導出されます。これらの変更により、L3／L4／L5／L7 が読み取る情報を削除することなく、計画ステップで最も時間のかかっていた書き込みを削減できます。
• S11 の退院日ピッカーでは、最早日と最遅日が同じ日になる場合（事前承認が当日に送信された場合）も、その日を選択可能なままにします。ピッカーが無効化されたり、読み取り専用に固定されたりすることはありません。

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

• S11 の退院日ピッカーは、入院日と事前承認の送信日（D18 submitted_at、施設の現地日付）のうち、遅い方の日付から開始し、終了日は引き続き今日です。これより前の日付は「退院日は事前承認日より前にはできません。」（D20）として拒否されます。入院日のルールの後にチェックされます。

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

• report.html は人が読みやすいように（LOGH）レイアウトされます。1 行の状態表示と Refresh を備えたヘッダー、未解決件数を表示する固定タブバー、4 つのタイルからなる Overview、横並びの 8 つのステップ、未解決エラーのカード（ID に名前を付け、存在する場合にのみ相関 ID と台帳 ID を表示）、テーブルごとにグループ化された Mapping（すべての D および F 参照を「D1 Organization · name」の形式で記載）、その他すべてのタブにおけるフィールド一覧、ピル付きテーブル、フィルターボックス、空の列の省略、ネストされたデータの JSON ではなくテキストによる表示を備え、ライトテーマとダークテーマにも対応します。標準ライブラリのみを使用する単一の自己完結型ファイルです。以前のビルドで作成されたレポートビルダーは、次のプロンプトで LOGH の CSS とスクリプトを使ってこのレイアウトに書き換えられ、実行されます。計画ファイルには変更を加えません。 1.9.3 の変更点。以前のビルドから続行する場合は、以下と照合して再確認してください。
• S17 の「ネットワーク内」は、1.9.2 の「有効な補償」ルールに置き換わります。支払者が、いずれかの患者について、この病院がその支払者から保険プランを取得するとネットワーク内になります（D10 のプランが ready に確定）。D32 に plan_fetched_at が追加されます（C4 が一度だけ設定し、取得済みのプランから移行時に値を設定します。更新時にクリアされることはありません）。支払者のチェックでは、この値を読み取り、未設定の場合は取得済みプランから一度だけ値を設定し、on_network と plan_fetched_at を返します。画面には、緑のチェックマーク付きで「ネットワーク内：この病院は から保険プランを取得しています。」と表示されるか、何も表示されません。

1.9.2 の変更点。以前のビルドから続行する場合は、以下と照合して再確認してください。

• S17「ネットワーク内」：有効と回答された検証の支払者のポリシーのみが対象です。該当するポリシーがある場合は、「ネットワーク内：この病院は の有効な補償を伴うポリシーを 件保有しています。」という緑のチェックマーク付きの行を 1 行表示し、ない場合は何も表示しません。
• 過去日に遡った事前承認はできません。S4 の入院日付ピッカーは今日から開始し、それ以前の日付で新しい事前承認を保存または送信しようとすると、「入院日は今日より前にできません。事前承認を過去日に遡って申請することはできません。」として拒否されます（D9、A4、S9）。支払者がすでに保持している日付はそのままでもかまいません。
• S4 の各診断には「暫定」または「確定」の区分が付けられます（D25 dx_type）。PMJAY の送信形式に合わせて、F8 diagnosis.type として SNOMED CT 148006 または 89100005 が送信されます。
• S11 の退院日付ピッカーは今日までの日付を選択できます。それより後の日付は「退院日は今日より後にできません。」として拒否されます（D20）。
• 請求の決定は、請求額の全額または一部が承認された場合、「最終承認」と表示されます（S11、請求ステージの S5）。事前承認のラベルは変わりません。
• 支払い：ワークフロー 30 では、すべての金額を含み、UTR を含まない paid として開始されます。31 では UTR を含む cleared として完了し、どちらも同じ PaymentNotice id を使用します。支払い済みとは、cleared、または UTR を含む paid を意味します。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 も配置します。