nhcx-payment

版本 1.11.0，构建于 2026-10-25，并已针对 NHA 的 NHCX 软件包 1.0.0 完成检查。

请先阅读：CORE

开始前，请先阅读 references/CORE.md，并在整个任务过程中牢记其中内容。其指令具有约束力：每一步、每个文件都必须严格遵循，并在每个步骤（L1 至 L8）开始时重新阅读。其易混淆之处明确了容易混淆的术语含义；遇到含义模糊的词时，以 CORE.md 为准。其中还包含基础 URL，以及每次交互的路由、bundle、工作流 ID 和回调。

区分角色

此技能属于提供方侧：它将 NHCX 集成到医院的 HMIS 中。该参与方负责提出请求（资格、计划、预授权、理赔），并接收答复。payer/ 文件夹是同一技能的付款方侧：保险公司、TPA 或方案系统，由该参与方答复、建立案件并作出决定。双方除了网关设计外没有任何共通之处；它们的 ID（S1、A1、C1）分别编号，绝不可混用。

在 L1 探索阶段开始时、匹配任何规范之前，先确定角色侧，并将其记录为 nhcx-plan/discovery.json 中的 side，同时也记录在进度日志中：

• provider：目标系统接收患者、保存执业人员和就诊记录、向保险公司开账单，或设有提交理赔的理赔部门。请继续使用此文件及根目录下的规范、步骤和参考资料，并完全忽略 payer/。
• payer：目标系统保存成员或受益人、产品或保单及其登记信息，由理赔部门裁定理赔，或拨付资金。请在此处停止，打开 payer/SKILL.md，从其自身的 L1 开始，将其作为完整技能遵循，并忽略根目录下的所有规范、步骤和参考资料。它链接的所有内容都位于 payer/ 内。
• both（同时接收患者并运行某项方案的系统）：需要进行两项集成，每一侧分别规划并记录；先处理用户要求的一侧，绝不要在同一个计划文件中混用两组 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）下载到目标仓库之外的全新空文件夹中，并根据 CHECKSUMS.sha256 检查 skills/ 下的每个文件。然后将加载此 SKILL.md 的文件夹，以及安装在其旁的所有同级 NHCX 技能文件夹（nhcx-full、nhcx-coverage、nhcx-preauth、nhcx-claim、nhcx-communication、nhcx-payment、nhcx-reprocess 和嵌套的 payer/）替换为软件包中同名的完整副本：不得残留旧版本中的任何文件。若技能由插件管理器安装，且插件管理器提供该版本，则通过插件管理器更新；否则以相同方式替换其技能文件夹。安装过程中不得改动目标仓库或 nhcx-plan/ 中的任何内容。用一行话告知用户（“已从 NHCX 软件包将 NHCX 技能从 1.8.0 更新至 1.9.0。”），记录此次操作，然后重新读取已安装副本中的此 SKILL.md 和 CORE.md，并以此为准继续；随后，VERSION 会根据发生的更改重新检查已完成的步骤。
4. 版本相同或更旧： 使用此构建继续工作。
5. 无法访问或校验和失败： 使用此构建继续工作，用一行话告知用户原因，并记录原因。校验未通过的副本绝不能安装，哪怕只安装一部分也不行。

每次检查都必须记录在 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 部分中的问题，并等待回答：理赔是否必须从已登记的患者开始，以及是否在开始时采集成员 ID；创建病例后是否自动获取保险计划（默认方式），还是由服务台获取；是否自动或手动刷新；以及按每个付款方和保单获取一次，还是按每个病例获取一次；医院需要付款方的 InsurancePlan 中哪些字段；预授权页面是否提供福利核查和授权要求判定；是否允许在入院前提交预授权（届时会在 Claim 选项卡上关联入院记录），以及患者未入院时，已批准的预授权在多少小时后撤销；是否需要补充文件、将 Aadhaar 作为支持信息，以及生物识别验证；理赔是否需要入院记录；是否在理赔前发送出院通知；服务台是通过“刷新”按钮检查付款方的答复，还是由病例按固定间隔轮询（频率是多少）；以及服务台必须查看哪些付款方函件。将每个答案记录在 nhcx-plan/plan.json 的 decisions 下。有问题的地方，绝不凭猜测行事。

有两件事绝不询问，因为探索会给出答案：HMIS 自身的 M1（ABHA 创建、关联和验证、患者档案上的 ABHA 标识符、ABDM 会话令牌）只要 L1.3 找到就会自动复用；只有 HMIS 没有 M1 时，才使用 A19. ABHA 创建与验证（ABDM M1）（位于 nhcx-coverage）；以及宿主的 UI 组件（输入提示、选择器、表格、标签、卡片、折叠面板、对话框、日期选择器、文件输入、闪现提示或 toast、带圆点徽标的选项卡），这些会在 L1.2 中查找，并用于每个屏幕。

目标

向目标 HMIS 添加 NHCX 付款通知。

此技能仅包含实现此目标所需的规格；SCOPE 部分会列出这些规格。此技能未包含但提及的规格，会标明由哪个技能提供。

要求

• 目标 HMIS 源代码，且其构建、测试和迁移命令可正常工作。
• 设施的 NHCX 参与方凭据：参与方代码、ABDM 客户端 ID 和客户端密钥，以及为该代码注册的加密证书私钥。
• NHCX 可访问的公共 URL，已注册为参与方的 endpoint_url，并路由至应用的入站路径（/in/<path> 或 /v1/<path>）。
• 知识源：nhcx-docs MCP 服务，或可下载 NHCX 软件包的网络访问权限（参见 KNOWLEDGE SOURCE）。仅当 HMIS 没有自己的 M1 时才需要的 ABHA 调用（A19）必须使用 MCP：软件包不包含 M1。
• 受益人的生物识别认证（A18；对任何付款方均可选，对 PMJAY 为必需）需要服务台机器上已注册且运行 RD 服务的指纹或虹膜设备；或者患者手机上用于人脸识别的 ABHA 应用；还需要一个客户端 ID，其会话令牌可被 ABHA 和生物识别服务接受。
• 端到端测试所需：沙盒凭据、会响应的沙盒付款方，以及测试受益人。

知识来源

NHCX 事实（API 路径和标头、FHIR 配置文件和示例 bundle、代码、工作流 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 bundle 使用 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（在 nhcx-coverage 中）“来自记录”），均从该目录读取，而非从本技能读取（abdm-m2 提示词和 references/KNOWLEDGE.md 中的原子）：A19. ABHA 创建和验证（ABDM M1）（在 nhcx-coverage 中）说明 HMIS 没有自己的 M1 时应用程序会如何处理，并指出要通过 get 读取的 M1 流程和操作 ID；abdm-m1 提示词则是其路由器。已经有 M1 的 HMIS 会保留它：不会构建 A19 的任何内容，也不会向用户发问。受益人的生物特征认证在此处完整定义，即 A18. 生物特征认证（在 nhcx-coverage 中）及其在场证明卡 S18. 受益人验证（在 nhcx-coverage 中），因为 NHCX 软件包包含该内容，且发送操作依赖它。

就协议而言，知识来源优先于这些规范；就应用程序的行为而言，规范优先。非协议相关的陈述标记为 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>/ 下为每个里程碑写入一个文件，并将每个子步骤和文件变更记录到 nhcx-plan/progress.json 和 nhcx-plan/progress.md 中（steps/LOG.md）。每次提示词结束时，无论执行了什么，都要重新生成 nhcx-plan/report.html（steps/LOG.md）：包含概览（KPI、里程碑步骤导航和按步骤划分的里程碑矩阵）、Bootstrap 标签页、每个里程碑各自的标签页（其 L1 到 L7 步骤及记录）、端到端标签页和日志标签页；nhcx-plan/make-report.sh once 会重新生成报告，make-report.sh watch 会持续更新报告。

每个里程碑都要完成以下七个步骤（从发现到试运行）：

1. L1 发现：知识来源、目标的技术，以及该里程碑交付的每一项规范内容，并标明已找到、部分找到或缺失，以及对应的文件和行号。
2. L2 映射：将里程碑的字段映射到数据库列和 FHIR 元素。
3. L3 集成规划：针对该目标的里程碑阶段、步骤和子步骤，按照 SCAFFOLDING 的构建顺序安排，包括在 HMIS 首页、侧边栏或导航栏中添加“索赔”入口（在 N0 中）。
4. L4 代码规划：将 SCAFFOLDING 套用到目标的惯例上，规划里程碑涉及的文件、函数和顺序。
5. L5 编写代码：逐个文件记录到 nhcx-plan/<Nx>/code.json，并遵循脚手架的依赖规则。
6. L6 验证代码：根据规范逐个检查文件。
7. L7 试运行测试：不使用网络；为 NHCX 和注册中心使用假对象。在这里通过模拟网关和桩回调，验证里程碑的完成条件。

然后，在每个里程碑的试运行均通过后，只执行一次（而非每个里程碑都执行）：

8. L8 端到端测试：在 NHCX 沙盒中测试从 N1 到 N6 的完整生命周期，并执行 references/TESTS.md 中的 T 测试；每项测试都要通过屏幕（GUI）和命令行（CLI）运行，并在根目录写入一个 nhcx-plan/e2e.json。

里程碑

构建过程会按依赖顺序执行 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，从探索到试运行），声明其依赖的里程碑，并复用这些里程碑已构建的内容，而非重新构建。端到端 L8 不属于任何里程碑：它会在最后跨越整个生命周期运行一次。

• 先完成全局初始化。 在 N0 之前，运行一次 L1.0（知识来源）、L1.1（NHCX 扫描）、L1.2（目标的技术与组件套件）和 L1.3（ABDM 模块）：这些是目标本身的属性，而非某个切片的属性，因此只需发现一次，写入计划根目录下的 nhcx-plan/knowledge.json 和 nhcx-plan/discovery.json 中的技术部分，再由每个里程碑读取。
• 按顺序一次处理一个里程碑。 只有在某个里程碑所依赖的所有里程碑都已完成后，才能继续处理该里程碑。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，而不是为每个里程碑分别写入。
• 每项内容只交付一次，之后复用。 每项规范只由一个里程碑交付；如果两个里程碑都涉及某项规范，则由较早的里程碑构建，较晚的里程碑复用（而不是重新构建），并记录所做的任何扩展（例如 N5 扩展 N3 的 F8。nhcx-preauth 中 use: claim 的构建器）。
• 试运行验证通过才算完成。 只有在某个里程碑的完成条件于试运行中得到满足时，该里程碑才算完成：代码已编写并通过验证，且在模拟网关、存根化回调的条件下，其试运行测试全部通过。绝不允许只完成一半就进入下一个里程碑。实时沙盒验证是最终的 L8 步骤；只有在最后一个里程碑的试运行通过后，才会针对整个生命周期运行一次。
• 持续推进；里程碑之间以及单个里程碑内部的步骤之间都不要暂停。 里程碑会完全离线运行（试运行不需要网络或沙盒凭据），因此某个里程碑的试运行通过后，应直接进入下一个里程碑，不要停下来询问任何信息。也不要在里程碑内部暂停：其中的步骤会依次运行，不设置确认关卡。里程碑规模较大（尤其是上文的 N3）或耗时较长，都不是停下来汇报的理由；试运行通过前，只有确实存在且无法通过默认设置解决的阻塞问题才应暂停。沙盒凭据、可访问的公共端点和测试受益人只会在最终的端到端步骤（L8）询问一次，绝不会在 N0 之后或任意两个里程碑之间询问；此前唯一的问题是那组一次性 ASK FIRST 问题。

各步骤文件会说明每个步骤的具体操作；里程碑及其交付的 ID 决定每次运行的范围。每个里程碑使用相同的 ASK FIRST 问题、知识来源、脚手架和规范。

脚手架

references/SCAFFOLDING.md 描述了代码在目标 HMIS 中的形态。开始 L3 前请先阅读，并在整个 L5 阶段保持打开。

• 一个 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 为每种类型记录的组件（输入时联想、选择器、表格、标签、卡片、折叠面板、对话框、日期选择器、文件输入框、闪现消息或 toast、带圆点徽标的标签页），因此，两个不同的 HMIS 最终会用各自的组件构建出相同的屏幕（references/SCREENS.md，组件套件）。只有在宿主缺少某种组件时才编写该组件，并使用宿主的设计令牌设置样式。
• ABHA 是患者标识。 通过病例的 ABHA 号码查找关联的“来自记录”的记录，以及关联到病例的入院记录。
• 核心规则：预授权会在理赔后锁定。 预授权获批且理赔已提交给付款方后，预授权变为只读：不能增强或更改；只能取消，且仅限付款方作出理赔决定之前。更改请求将被拒绝，并显示“The claim has gone to the payer, so the pre-authorisation is read only: no enhancement or change can be made. It can only be cancelled while the payer is deciding the claim.”；逾期取消请求将显示“The payer has decided the claim; the pre-authorisation can no longer be cancelled.”。在提交阶段就被拒绝的理赔从未到达付款方，因此预授权仍保持开放。
• 理赔一旦作出决定，就绝不会再次发送。 被拒绝的理赔会作为重新处理请求提交（工作流 36，原因为 claimrejected 或 rejectiondisputed）；获批或部分获批的理赔可以申请余额支付（释放）。
• 依赖规则： 屏幕调用服务并读取模型；只有服务和回调可以写入理赔表；FHIR 构建器绝不访问数据库或网关；网关对理赔一无所知；通过轮询找到的回复由同一个回调处理器处理。
• 仓库之外： 网关配置、客户端密钥、私钥、分类账和归档目录。
• tests/nhcx/ 下的测试（试运行和端到端测试），以及 nhcx-plan/ 下的计划文件。
• 构建顺序分阶段进行，从网关基础到导航项；L3 按此顺序规划，并省略 SCOPE 中未包含规格的阶段。

L4 会按照 L1 发现的目标自身惯例，将这些占位名称映射到目标的命名方式，无论其使用何种语言、框架和模块形式；各部分的划分和依赖方向保持不变。任何规格都不预设框架、ORM、路由器或组件库。

范围

此技能包含的规范：

• 界面（4）：S5、S6、S12、S19
• API（6）：A8、A10、A11、A12、A13、A17
• 回调（2）：C1、C10
• FHIR（8）：F1、F3、F13、F14、F15、F16、F17、F18
• 数据库（11）：D1、D2、D3、D8、D9、D13、D20、D21、D22、D30、D32
• 网关（11）：G1、G2、G3、G4、G5、G6、G7、G8、G9、G10、G11
• 测试（5）：T1、T2、T11、T18、T20

基于同一来源构建的其他技能：

• nhcx-full：涵盖提供方侧 NHCX 集成的全部内容，以及端到端的每次交换。
• nhcx-coverage：受益人保单搜索和承保资格检查。
• nhcx-preauth：预授权：付款方的计划、从计划报价的项目、承保和授权要求检查、预授权、增强、取消和状态。
• nhcx-claim：出院后的理赔提交、判定结果和状态。
• nhcx-communication：付款方的查询、通知和备注，以及相应回复。
• nhcx-reprocess：对已判定或部分支付的理赔重新处理并释放余额。

版本

这是 nhcx-payment 版本 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 进行两次实际运行后总结得出）：
• 一笔付款的身份不再仅由 PaymentNotice.id 确定（D21. claim_payment 规则 4、C10. Payment Notice、F13. PaymentNotice）：沙盒付款方不发送 PaymentNotice.id，因此同一笔付款的 workflow-30 和 workflow-31 通知被记录为两行，S12 除了已结清的卡片外，还显示了一张「已发起，等待 UTR」卡片。现在，身份依次取 PaymentNotice.id、对账记录 detail[] 中 placer identifier 的付款 ID（<paymentId>/Payment），或金额和日期相同且没有 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 (in nhcx-coverage)）；存在裁定时，裁定未列出的表单无论标题如何，都会进入理赔流程（D12. claim_plan_form (in nhcx-coverage)）。
• 出院小结统一归入 HDS，不论其归档类别为何（F8. Claim (in nhcx-preauth)）。
• D10 重用不再复制 response_json（复制 29 份 18 MB 的主数据曾使数据库膨胀至 645 MB）。
• GUI 运行会驱动浏览器，否则状态为 blocked（T2. Test Runners、L8）：安装设置时会自动安装浏览器驱动，无需询问；产物为 PNG 截图；每个运行器都会打开自己的理赔；e2e.json 条目包含 browser 和 plan_source。T10 会开具入院账单，以便 T11 验证 D21 过账；T11 预期每笔付款只有一张卡片，且状态为 posted。
• 运行结束后会生成一份功能测试报告（T20. Functional Test Report、nhcx-e2e report）：GUI 运行器会截取整个流程的屏幕截图（登录、每个步骤执行前后、每次拒绝、结束时的每个选项卡，以及提供 URL 时的付款方工作台）；报告生成器会生成符合功能测试审计报告格式的 PDF（封面区块、文档控制信息、目录、需求表、范围、执行详情、方法、工具、每个测试步骤对应一个编号证明章节，并附截图和一句说明、总结），以及每个步骤一行的 Excel 工作簿；不写入公司名称，不打印凭据。新增 T1 变量 NHCX_TEST_FT_* 和 NHCX_TEST_PAYER_DESK_URL；e2e.json 步骤包含 expected 和 screenshots。
• L6 新增三项机械检查（SCAFFOLDING 布局、阶段词汇、通过处理器提供的 fixtures），L7 新增四项测试（理赔中的 HDS、针对真实 PMJAY 主数据的 D11 规则、针对种子的 C4、双通知付款）。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）。对于布局已由规范确定的文件（F、A、C、D、屏幕），L4 代码规划不再预先列出 functions[] 和每个文件的测试规则列表；两者都会在 L5/L7 中重新推导。这些变更缩短了计划步骤中最耗时的写入过程，同时没有删去 L3/L4/L5/L7 读取的任何内容。
• S11 出院日期选择器的最早日期和最晚日期相同（预授权于当天发送）时，该日期仍可选择：选择器不会被禁用，也不会被锁定为只读。

1.9.5 中的变更；继续较早版本的构建时，请重新核对：

• S11 出院日期选择器的起始日期为入院日期和预授权发送日期（D18 submitted_at，机构当地日期）两者中较晚的一天，结束日期仍为今天；如果选择更早的日期，则会被拒绝并显示“The discharge date cannot be before the pre-authorisation date.”（D20），且在入院日期规则之后检查。

1.9.4 中的变更；继续较早版本的构建时，请重新核对：

• report.html 按照面向使用者（LOGH）的方式布局：页眉显示单行状态并提供 Refresh；标签栏固定显示并带有未解决项数量；概览包含四个信息卡片；八个步骤并排显示；未解决错误以卡片形式显示（仅在有值时显示 ID、名称、关联 ID 和账本 ID）；映射按表分组，并为每个 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「网络内」：只有付款方验证结果为符合条件的那份保单才计入；有符合条件的保单时，显示一行带绿色勾号的「网络内：本医院持有 的 份有效承保保单。」；否则完全不显示内容。
• 不允许倒填预授权日期：S4 入院日期选择器的起始日期为今天；保存或发送日期早于今天的新预授权时，拒绝并提示「入院日期不能早于今天；预授权不得倒填日期。」（D9、A4、S9）。付款方已持有的日期可以保留。
• S4 中的每项诊断都标记为「临时」或「最终」（D25 dx_type），并按 PMJAY 的发送方式以 F8 diagnosis.type SNOMED CT 148006 或 89100005 发送。
• S11 出院日期选择器的结束日期为今天；日期晚于今天时，拒绝并提示「出院日期不能晚于今天。」（D20）。
• 理赔的决定显示为「最终审批」，可全额或部分批准（S11、S5 的「理赔」阶段）；预授权保留原有标签。
• 付款：流程 30 中以 paid 状态发起，包含所有金额但不含 UTR；流程 31 中以 cleared 状态完成，并附上 UTR；两者使用同一个 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）。第四个信息块显示「已批准」（理赔的批准金额），而不是「已申报」。

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），名称来自 nhcx-plan/names.json，并在 L1.2 中写入（LOG.md、LOGN）。 1.8.0 中的变更，继续早期构建时需重新核对：
• 这些步骤与框架无关：L1 记录主机的技术栈及按类型划分的组件，L4 和 L5 据此构建每个屏幕，L6 则拒绝重复组件。
• 如果已有 M1，则直接复用，无需询问；如果 M1 已存在，L3 会舍弃 A19 和 S13 至 S15 中新增的 ABHA。通过 ABHA 查找记录和入院信息。
• 创建病例后，plan.trigger 默认为自动触发（复用相同保单的就绪计划，否则发起请求）。项目明细、福利核验和授权要求裁定均位于预授权选项卡中，每个项目都根据付款方的保险计划进行报价（Blood 或 Ambulance 等单纯的承保福利不会作为项目）。
• 两个付款方适配器 gov 和 generic，根据参与方主数据的实体类型选择（pmjay 对应 gov，kyrocare 对应 generic）；绝不显示适配器名称。
• 保险计划请求和状态查询使用工作流 ID 1；查询答复使用 request.initiated。
• 理赔选项卡依次为 Overview、Pre-authorisation、Claim、Communication、Payments 和 Logs（按最新时间优先排序，且只有此处显示关联 ID）；付款方有新内容时，选项卡旁会显示圆点；发起预授权后才会显示 Claim 和 Payments。
• 已裁定的理赔绝不会再次发送：只有被拒的理赔才会请求重新处理，已批准理赔的余额发放则会保留。
• 核心规则：理赔一旦发送给付款方，预授权即为只读（不能增强或更改），且仅在付款方裁定理赔之前可以取消。

参考资料

• references/CORE.md：基准 URL，以及每次交互的路由、捆绑包、工作流 ID 和回调，集中于一页。
• 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/ 下的测试：dry-run（L7）和端到端（L8），端到端测试包含 GUI runner 和 CLI runner（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.json 及其配套的 progress.md，以及 report.html。每次提示词结束时，都要由报告构建器（report.py 或目标语言的等效工具）重新生成 report.html，并将其 make-report.sh 和 make-report.bat 放在旁边。