nhcx-preauth

バージョン 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 の作成と検証（ABDM M1） のみを使用します。また、ホストの 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、エラーコード、稼働開始ルール）は、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 のように記述してください。

ステップ

このスキルはマイルストーンモードのみでビルドします。ビルドは、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 まで開いたままにしてください。

• 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

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

• 画面（12）：S4、S5、S6、S7、S8、S9、S13、S14、S15、S16、S18、S19
• API（14）：A2、A3、A4、A6、A10、A11、A12、A13、A14、A15、A16、A17、A18、A19
• コールバック（6）：C1、C3、C4、C5、C7、C8
• FHIR（15）：F1、F2、F3、F4、F5、F6、F7、F8、F9、F10、F15、F16、F17、F18、F19
• データベース（29）：D1、D2、D3、D4、D5、D6、D7、D8、D9、D10、D11、D12、D13、D14、D15、D16、D17、D18、D19、D20、D23、D24、D25、D26、D28、D29、D30、D31、D32
• ゲートウェイ（11）：G1、G2、G3、G4、G5、G6、G7、G8、G9、G10、G11
• テスト（14）：T1、T2、T4、T5、T6、T7、T8、T9、T13、T14、T15、T16、T19、T20

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

• nhcx-full：プロバイダー側の NHCX 連携全体。あらゆる交換をエンドツーエンドで扱います。
• nhcx-coverage：受益者の保険契約検索と給付対象の適格性確認。
• nhcx-claim：退院後の請求提出、その判定とステータス。
• nhcx-communication：支払者からの照会、通知、メモ、およびそれらへの返信。
• nhcx-payment：支払い通知とその受領確認。
• nhcx-reprocess：判定済みまたは一部支払い済みの請求の再処理と残高の解放。

バージョン

これは nhcx-preauth バージョン 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（nhcx-claim 内）のルール4、C10. Payment Notice（nhcx-payment 内）、F13. PaymentNotice（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、T13. PMJAY Eligibility, Package Master and Ruling）：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）。
• 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 が指定されている場合は支払者のデスク）をスクリーンショットに収めます。ビルダーは機能テスト監査レポート形式の PDF（表紙ブロック、文書管理、目次、要件表、スコープ、実行詳細、方法論、ツール、各テストステップにつきスクリーンショットと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 も配置します。