nhcx-preauth

版本 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 作为辅助信息，以及生物识别验证；理赔是否需要入院记录；是否在理赔前发送出院通知；服务台是通过 Refresh 按钮检查付款方的答复，还是由病例按固定间隔轮询（间隔多久）；以及服务台必须查看哪些付款方函件。将每个答复记录在 nhcx-plan/plan.json 的 decisions 下。凡是有问题的地方，都不能凭猜测作出决定。

有两件事永远不会询问，因为发现阶段会确定答案：HMIS 自己的 M1（ABHA 创建、关联和验证、患者身上的 ABHA 标识符、ABDM 会话令牌）会在 L1.3 找到时自动复用；只有没有 M1 的 HMIS 才会使用 A19. ABHA 创建与验证（ABDM M1）；以及宿主的 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）。ABHA 调用（A19）仅在 HMIS 没有自己的 M1 时需要，且需要 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 下载最新版本的压缩包（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 中的原子）：A19. ABHA Create and Verify (ABDM M1) 说明当 HMIS 没有自己的 M1 时应用会如何处理，并指出要通过 get 读取的 M1 流程和操作 ID；abdm-m1 提示词则是其路由器。已经有 M1 的 HMIS 会保留它：不会构建 A19，也不会向用户提问。受益人的生物特征认证在此处完整定义：A18. Biometric Authentication，以及其在场证明卡片 S18. Beneficiary Verification，因为 NHCX 软件包包含这项功能，且发送操作依赖它。

在协议相关问题上，知识来源优先于这些规范；在应用行为上，规范优先。非协议声明会标记为 REF（参考实现的选择）、PAYER（取决于付款方适配器）或 SANDBOX（仅在沙盒中观察到）；所有付款方专属值都列在 references/PAYERS.md 中。其中的 ID（例如 NHA 用例 C5）不是此技能的 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。每个里程碑都会针对其交付的仅有的 spec 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，而不是为每个里程碑分别写入。
• 只交付一次，之后复用。 每个 spec 恰好由一个里程碑交付；若两个里程碑都涉及某个 spec，则由较早的里程碑构建，较晚的里程碑复用（而不是重建），并记录所做的扩展（例如，N5 将 N3 的 F8. Claim 构建器扩展为 use: claim）。
• 只有通过试运行验证才算完成。 只有当里程碑的完成条件在试运行中得到满足，才算 done：其代码已编写并通过验证，且在模拟网关、桩替回调的情况下，试运行测试全部通过。绝不能只完成一半就进入下一个里程碑。真实沙箱验证属于最终的 L8：最后一个里程碑的试运行通过后，针对整个生命周期执行一次。
• 持续推进，不要在里程碑之间或单个里程碑的步骤之间暂停。 里程碑会完全离线运行（试运行不需要网络或沙箱凭据），因此某个里程碑的试运行通过后，应立即继续下一个，不要停下来询问任何事情。单个里程碑内部也不要暂停：其步骤应依次执行，无需确认。里程碑规模较大（尤其是 N3）或耗时较长，都不是停止并汇报的理由；试运行通过前，只有无法通过任何默认方案解决的真实阻碍才需要暂停。沙箱凭据、可访问的公共端点和测试受益人信息只会在最终端到端步骤（L8）一次性询问，绝不会在 N0 之后或任意两个里程碑之间询问；在此之前，唯一的问题是一次性的 ASK FIRST 问题集。

步骤文件说明各个步骤的操作；里程碑及其交付的 id 则决定每次运行的范围。ASK FIRST 问题、知识来源、脚手架和 spec 对所有里程碑都相同。

脚手架

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 号码查找标记为“来自记录”的附件记录，以及与病例关联的入院记录。
• 核心规则：预授权在理赔提交后即锁定。 预授权获批且理赔已发送给付款方后，预授权将变为只读：不得增强或更改；只能取消，且仅限付款方决定理赔之前。更改请求将被拒绝，并提示“理赔已发送给付款方，因此预授权为只读状态：无法进行增强或更改。只有在付款方审核理赔期间才能取消。”；逾期取消请求将被拒绝，并提示“付款方已决定理赔；预授权不能再取消。”在入口处被拒绝的理赔从未送达付款方，因此预授权仍保持开放状态。
• 理赔一旦决定，绝不再次发送。 被拒绝的理赔将作为重新处理请求退回（工作流 36，原因 claimrejected 或 rejectiondisputed）；已批准或部分批准的理赔可以申请余额支付（release）。
• 依赖规则： 屏幕调用服务并读取模型；只有服务和回调会写入理赔表；FHIR 构建器绝不接触数据库或网关；网关对理赔一无所知；通过轮询找到的回复由同一个回调处理程序应用。
• 仓库之外： 网关配置、客户端密钥、私钥、账本和归档目录。
• 测试位于 tests/nhcx/（试运行和端到端测试），计划文件位于 nhcx-plan/。
• 构建顺序分阶段进行，从网关基础到导航项；L3 按此顺序制定计划，并省略 SCOPE 中不包含规范的阶段。

L4 会根据 L1 发现的目标自身惯例，将这些占位名称映射到目标的对应约定，无论其使用何种语言、框架和模块形式；各部分的划分及依赖方向不会改变。任何规范都不假定使用特定框架、ORM、路由器或组件库。

范围

此技能包含的规范：

• 界面（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 package 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 package 安装了较新的构建；此时记录的版本就是旧版本。
• 如果后续提示词运行时使用的技能版本与记录的版本不同，请在继续前告知用户，将其记录为一条 corrected 条目并注明两个版本，然后根据发生变更的规范重新核查已完成的步骤。
• 如果知识来源比 1.0.0 更新，则按照 KNOWLEDGE SOURCE 中的说明，以该知识来源的协议为准；请在 knowledge.json 中注明差异。 1.11.0 中的变更；在继续较早的构建时，请对照复核（每项均根据 2026 年 10 月 24 日在一套 HMIS 上对 1.10.0 进行的两次实际运行得出）：
• 付款的身份不再仅由 PaymentNotice.id 决定（D21. claim_payment（在 nhcx-claim 中）规则 4、C10. Payment Notice（在 nhcx-payment 中）、F13. PaymentNotice（在 nhcx-payment 中））：沙箱付款方不发送 PaymentNotice.id，因此同一笔付款的 workflow-30 和 workflow-31 通知被记作两行，S12 除已结清的卡片外，还显示了一张“已发起，等待 UTR”的卡片。现在依次使用 PaymentNotice.id、对账记录 detail[] 中的付款 ID 放置标识符（<paymentId>/Payment），或者金额和日期相同且没有 UTR 的最新 paid 行作为身份。占位 UTR（如 Not available）存储为空值。
• C4 会替换种子计划（C4. Insurance Plan Reply、T13. PMJAY Eligibility, Package Master and Ruling）：标记为 T13 测试种子的 ready 行会接收付款方的回复；种子会经过 C4 自身的应用路径，因此每份种子文档都带有显示内容和阶段。曾有一次运行在种子将状态设为 ready 后，C4 忽略了所有回复，因此始终未能看到 PMJAY 的主数据。
• 阶段仅存储为 pre 或 post，且 D11 的事后关键词新增 bill、hospital bill、lama、dama、death、mortality（D11. claim_plan_benefit）；存在暂缓裁定时，裁定未提及的表单无论标题如何，都会进入理赔流程（D12. claim_plan_form）。
• 出院小结统一归入 HDS，不受其归档类别影响（F8. Claim）。
• 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 布局、阶段词汇、经由处理器传入的固定数据），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 放在旁边。