nhcx-claim

バージョン 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）。

まず質問する

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

ディスカバリーで答えが分かるため、質問しないことが2つあります。HMIS 独自の M1（ABHA の作成、リンク、検証、患者の ABHA 識別子、ABDM セッショントークン）は、L1.3 で見つかった場合に常に自動で再利用されます。M1 がない HMIS に限り、A19. ABHA Create and Verify（ABDM M1）（nhcx-coverage 内）が必要です。また、ホストの UI コンポーネント（入力補完、セレクト、テーブル、チップ、カード、アコーディオン、ダイアログ、日付ピッカー、ファイル入力、フラッシュまたはトースト、ドットバッジ付きタブ）は L1.2 で確認し、すべての画面で使用します。

目標

対象の HMIS に NHCX 請求送信機能を追加します。

このスキルには、この目標に必要な仕様のみが含まれています。含まれる仕様は SCOPE セクションに記載されています。名前が挙げられていても含まれていない仕様には、それを含むスキルが記されています。

要件

• 対象 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 も必要です。
• エンドツーエンドテストの場合：サンドボックス認証情報、応答するサンドボックスの支払者、テスト用受益者。

ナレッジソース

NHCX に関する事実（API パスとヘッダー、FHIR プロファイルとサンプルバンドル、コード、ワークフロー ID、エラーコード、稼働開始ルール）は、単一のナレッジソースを参照します。これは 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 パッケージに含まれ、送信がそれに依存するため、A18. Biometric Authentication と、その本人確認カード S18. Beneficiary Verification でここに完全に定義されています。

プロトコルに関しては、これらの仕様よりナレッジソースを優先します。アプリケーションの動作に関しては、仕様を優先します。プロトコル以外の記述には、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 です。各マイルストーンでは、提供する spec id のみを対象に、上記の7つのステップ（L1 から L7、ディスカバリーからドライランまで）を実行し、依存するマイルストーンを宣言して、それらが構築したものを再構築せずに再利用します。L8 のエンドツーエンドはマイルストーンには含まれず、ライフサイクル全体を対象に、最後に1回実行します。

• まずグローバルなブートストラップを実行します。 N0 の前に L1.0（ナレッジソース）、L1.1（NHCX の調査）、L1.2（対象のテクノロジーとコンポーネントキット）、L1.3（ABDM モジュール）をそれぞれ1回実行します。これらはスライスごとの特性ではなく、対象に関する特性なので、1回だけ確認し、nhcx-plan/knowledge.json と、計画のルートにある nhcx-plan/discovery.json のテクノロジー部分に記録して、すべてのマイルストーンから参照します。
• 一度に1つのマイルストーンを順番に進めます。 依存するすべてのマイルストーンが 完了 するまでは、次のマイルストーンに進みません。すべての前に N0、N2 の前に N1、N3 の前に N2、N4 と N5 の前に N3、N6 の前に N5 を完了します。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つ書き込みます。
• 一度だけ提供し、その後は再利用します。 各 spec は必ず1つのマイルストーンで提供します。2つのマイルストーンが対象とする spec は、先に実行するマイルストーンで構築し、後のマイルストーンでは再構築せずに再利用します。後のマイルストーンでは、行った拡張を記録します（たとえば N5 は N3 の F8. Claim ビルダーを use: claim 用に拡張します）。
• ドライランで実証できて初めて完了です。 マイルストーンは、ドライランで完了条件を満たした場合にのみ done となります。つまり、コードが作成・検証され、ゲートウェイをモックし、コールバックをスタブ化した状態でドライランのテストに合格している必要があります。次のマイルストーンに未完成の状態を持ち越すことはありません。ライブサンドボックスでの実証は、最後のマイルストーンのドライランが成功した後、ライフサイクル全体を対象に1回実行する最終の L8 で行います。
• 続けて進め、マイルストーン間や1つのマイルストーン内のステップ間で止まりません。 マイルストーンは完全にオフラインで実行できます（ドライランにネットワークやサンドボックスの認証情報は不要です）。そのため、あるマイルストーンのドライランが成功したら、何かを尋ねるために停止せず、そのまま次に進みます。マイルストーンの途中で停止することもありません。各ステップは確認を挟まず、順番に実行します。規模の大きなマイルストーン（特に上記の N3）や所要時間は、停止して報告する理由にはなりません。ドライランが成功する前に停止するのは、デフォルト設定で解決できない真のブロッカーがある場合だけです。サンドボックスの認証情報、到達可能な公開エンドポイント、テスト用の受給者について尋ねるのは、最終のエンドツーエンドステップ（L8）で1回だけです。N0 の後やマイルストーン間で尋ねることはありません。それ以前に尋ねるのは、最初に1回だけ行う ASK FIRST の質問に限られます。

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

スキャフォールディング

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、ルーター、コンポーネントライブラリは前提としません。

スコープ

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

• 画面（5）：S5、S6、S11、S18、S19
• API（11）：A5、A6、A10、A11、A12、A13、A14、A15、A16、A17、A18
• コールバック（3）：C1、C6、C8
• FHIR（11）：F1、F3、F7、F8、F9、F10、F15、F16、F17、F18、F19
• データベース（21）：D1、D2、D3、D8、D9、D11、D12、D13、D15、D16、D17、D18、D20、D21、D23、D24、D28、D29、D30、D31、D32
• ゲートウェイ（11）：G1、G2、G3、G4、G5、G6、G7、G8、G9、G10、G11
• テスト（5）：T1、T2、T10、T17、T20

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

• nhcx-full：プロバイダー側のNHCX統合全体。すべての交換をエンドツーエンドで網羅します。
• nhcx-coverage：受益者の保険契約検索と適用範囲の適格性確認。
• nhcx-preauth：事前承認：支払者のプラン、そのプランから見積もられた明細、適用範囲と承認要件の確認、事前承認、増額、キャンセル、ステータス。
• nhcx-communication：支払者からの照会、通知、メモ、およびそれらへの返信。
• nhcx-payment：支払通知とその確認応答。
• nhcx-reprocess：決定済みまたは一部支払い済みの請求に対する再処理と残高の解放。

バージョン

これはnhcx-claimバージョン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日に、ある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件の支払いに対するワークフロー30とワークフロー31の通知が別々の2行として登録され、S12では消し込み済みのカードに加えて「Initiated, UTR awaited」のカードが誤って表示されました。識別には、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](database/D11-claim-plan-benefit.md）。裁定が保留されている場合、裁定で指定されていないフォームは、タイトルにかかわらずクレーム側に送られます（D12. claim_plan_form）。
• 退院サマリーは、どのカテゴリで登録されていてもHDSの下に置かれます（F8. Claim）。
• 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件につきカード1枚が表示され、ステータスがpostedであることを期待します。
• 機能テストレポートは実行後に作成されます（T20. Functional Test Report、nhcx-e2e report）：GUIランナーはプロセス全体（サインイン、各ステップの実行前後、すべての拒否、最後の各タブ、URLが指定されている場合は支払者のデスク）をスクリーンショットに収めます。ビルダーは機能テスト監査レポート形式のPDF（表紙ブロック、文書管理情報、目次、要件表、スコープ、実行の詳細、方法論、ツール、各テストステップにつき1つの番号付き証跡セクションとそのスクリーンショットおよび1行の説明、概要）と、ステップごとに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 も配置します。