患者、预约、到诊与护理 PRD

更新：2026-11-02 · 责任：Line A · 配套：业务总流程／测试用例

本篇说明患者从资料登记、预约到实际到诊的工作流程。前台负责预约和基础资料维护，护士按有效诊所／Doctor Group 工作范围完成签到和护理准备。各入口共用同一份患者资料，访问范围见 权限方案。

权限要求与交付状态分开维护：本篇定义应有行为，当前实现及验证结果见交付状态和权限验证。

功能地图

按患者建档、预约、实际到诊三个业务对象组织；界面、字段与异常放在所属功能内。

1. 三个入口如何协作

Patient & eMR 管一个人的长期资料，Appointment 管某次预约安排，Registration 管当天到诊和准备。三者共用患者主档和同一预约／Visit 关联。患者从哪个入口来，不应决定他有几份档案。

旧设计的“只保留 Overview／Timeline”不覆盖后来确认的患者级历史 Tab。页面数量也不构成业务验收指标。

1.1 当前诊所与跨诊所日程

已轉換單位按持牌 Center／Zone 模型運作：日曆及隊列預設 All Zones，顯示服務 Zone 並可篩選。預約與 Walk-in 必須指定啟用 Zone；房間／設備屬該 Zone，醫生可用性仍檢查整個 Center。同 Center 在任何 Visit 建立前可稽核改 Zone，沿用 Appointment ID／UUID／Chit 並重驗資源；到診後凍結位置。跨 Center 繼續建立新的關聯 Encounter。舊來源 ID、有效 H5 Token 及重試 namespace 保留，新建立命令及 Token 使用明確的 Center／Zone 版本契約。

Patient & eMR 和 Registration 只使用全局 Context Selector 的当前 Clinic，不在 App 内混合展示不同诊所的患者、队列、历史或附件。切换主体后重新取得 auth context 与 ui_access，清除旧患者、队列、历史、角标、未保存表单和进行中请求；迟到响应不得写回新主体。列表、详情及所有写入动作均由服务端再次核对主体、对象关系、状态和 capability。

Appointment Calendar 可以提供“我的有效诊所”日程汇总，但只展示获授权的日程元数据：Doctor 仅看本人 Provider，Nurse 仅看本人有效岗位／服务关系覆盖的诊所。汇总视图不得展开跨主体患者或临床资料；进入其他 App 查看另一诊所前，必须先通过全局 Context Selector 切换主体。

1.2 贯穿预约、到诊与收费的诊症单身份

核心身份流程已在本地实现；历史迁移与发布验收尚未完成。 已保存的患者预约或 Walk-in 登记即取得一个永久 Encounter UUID 和一个可见的 Chit No.，供前台、医生／护士、药房、收费和会计共同追踪本次服务。签到、问诊、接种、处方、检查、Invoice、Receipt 及后续退款沿用这组身份；各自的临床记录、订单及财务单据编号仍独立保留。同一诊症单可对应多张账单、分次付款及后续调整。

• 旧 M0008… 等已记录 Chit 保持原值；新 AI-CLIP Chit 继续采用已确定的 M02 加八位序号，首号 M0208000001，不重置已使用序号。本次改变的是发号时点和贯穿流程的 UUID，不改变 PN／VPN 或药品／影像编码规则。
• 预约取得编号不代表已经到诊、获得病历权限、完成临床服务或产生收入；实际到诊才建立／关联 Visit。未匹配患者主档的预约须先核实绑定患者，才可签到或收费。纯资源 Block-out 不产生医疗 Chit。
• 同诊所改约及获准更换医生沿用身份；重试不能重复发号。取消／No-show 保留原号，不回收。新的复诊、重新预约或跨诊所转移建立新的关联 Encounter；同日两次独立到诊也不能按患者和日期自动合并。
• 同次到诊的多项接种与问诊共用 Encounter，但各接种事件独立留痕；多日疫苗疗程按每次到诊分别编号。疫苗专属服务须有获授权的完成／收费流程，不伪造医生 SOAP。患者级历史疫苗或附件没有可靠 Visit 来源时，不补造诊症。
• 日历、Reception、临床及收费详情展示同一个 Chit，并支持完整编号查看／查询；UUID 用于系统关联，不要求前线人员日常抄写。Invoice／Receipt／退款编号不被 Chit 替代，Closed 后的结果和财务调整仍关联原身份。

当前代码从已保存预约或 Walk-in 发号，签到沿用同一身份；已导入历史资料须经受控回填后才具有统一 UUID，不在系统启动时自动迁移。字段映射见 Patient reference §6.1。系统影响与迁移方案及本地验收说明实际实施边界；无医生疫苗收费完成按 §5.3 的已确认限定流程处理。迟到的旧 Chit、历史一预约多 Chit、预收款及外部会计接口仍须完成明确评审，不能静默改号、合并记录或扩大临床权限。

2. Patient & eMR

Patient & eMR 保存患者的长期资料，也是查询历次就诊的入口。工作人员先搜索患者，核对身份后打开已有档案；确实没有记录时，再按建档权限新建，避免重复登记。

前台可以维护基础信息；护士和医生按各自权限维护其他资料。患者可以关联多家诊所，查询基础信息、修改主档和查看完整病历分别判断。保存后的主档由各业务入口共同使用，历次就诊仍引用原记录。

患者列表与历史展示： 一位 Patient 一条主档结果，显示 Patient No.、姓名、获授权且按规定脱敏的身份匹配信息及有效关联诊所，不因多张卡、多次 Visit 产生重复患者行。无搜索条件时的可见范围仍执行集团／角色查询规则；本轮设计默认按患者编号升序提供稳定浏览，显式查询的精确编号匹配优先，再按患者编号稳定排序，不用最近就诊推定当前排队。各历史 Tab 默认原业务事件日期降序、稳定来源记录 ID 降序，空日期置末并显示未记录；不同类型事件不混用上传／迁移时间作为临床发生时间。搜索无匹配提供获授权的新建入口；读取失败不能引导用户重复建档。 2026-10-19 确认： 在 Patient & eMR 打开任何患者详情后，搜索栏和现有搜索结果继续保留，已输入关键词不清空，可直接重新搜索并选择其他患者；从 Reception 等入口打开真实或虚拟患者档案同样适用。仅员工主动选择收起时才隐藏搜索区，展开后恢复原搜索条件。窄窗口中搜索与详情仍并排可用，搜索区不覆盖详情；切换患者沿用未保存修改提示与身份／权限校验，不因搜索或点击结果跳过保护。自助填报审核保留第 3 节的专用审核界面，返回患者档案后恢复搜索区。 搜索结果的患者主信息提供可聚焦按钮，名称包含患者姓名及现有辨识信息；Enter／Space 与鼠标选人共用同一上下文检查，按钮点击不重复触发行选择，选中状态向辅助技术表达。 窄窗及三窗并排时，搜索区与病历区按布局占用各自空间，不能用覆盖层遮挡 Notes 等病历操作；用户仍可主动收起搜索。

2.1 字段定义

患者卡片的诊所标识： 只展示患者资料返回的有效诊所关联名称；多个诊所并列，不建立单一 Primary Clinic。没有诊所名称时，只有后端明确标记与当前诊所有关联，才可显示当前诊所名称并标明关联；其他诊所显示 Other clinic，关联未知则显示未记录。当前岗位、Nurse／Doctor 角色和工作场景不能填入患者卡片，也不能因患者可被搜索就将其归到当前诊所；当前操作者身份仍可在工作台顶部显示。此展示修正不扩大历史读取或护理授权。

新建患者主电话： Patient & eMR 与预约新增患者共用独立的国家／地区代码及号码输入框；默认香港 +852。代码下拉支持按中英文地区名称、ISO 代码及拨号码搜索，优先列出香港、中国、澳门、台湾、日本、韩国、其他常用亚洲地区及澳洲，其他受支持地区亦可搜索。号码只可输入数字；香港必须恰好 8 位，不足或超长明确显示错误并阻止保存，保留输入供修正。其他地区按 libphonenumber-js 元数据校验可接受长度，允许本地前导 0；保存及重复检查采用相同格式：香港沿用本地 8 位号码，其他地区使用含国家代码的国际 E.164 格式。此校验不证明号码已分配、可接通或属于该患者，不追溯改写已有患者电话号码。

2.2 创建、重复校验与修正

患者目录读取错误与注册弹窗的必填、OCR、查重、保存错误分别呈现，不相互清空。取消／关闭／重开只重置注册局部错误；保存失败保留输入，进行中及结果未明继续执行原 busy／未保存保护。OCR、候选查询和保存响应校验当前表单生命周期，旧表单关闭后的迟到结果不得回填新表单或冒充目录错误；不因未知保存结果自动重复创建患者。

PT-01～PT-04： 先搜索再创建；证件完全匹配或规范化姓名＋主手机号同时匹配时阻止重复保存，显示命中依据，允许打开已有患者或返回修正。单姓名或单电话相同只提示候选。本期不自动合并患者；治理人员处理误匹配／确需合并的操作规程仍待确认。

保存后各获授权业务入口读取同一最新主档。普通患者基础资料补全及更正无需员工手填修改原因，系统保留操作者、时间、操作来源、前后值及新版本；恢复旧内容仍需原因并形成新版本，不销毁后续历史。同集团具角色查询权限的人员均可搜索和查看患者基础信息，不受当前诊所关联限制；修改、确认与临床历史分别校验。前台可新建、修正和确认基础信息，不能维护医疗／安全资料或保险计划。护士日常预约管理限当前 Clinic 的有效 Doctor Group 工作范围；另选 Booking clinic 创建预约时，目标诊所须属于本人有效预约范围，详见第 4 节。预约可以保留运营关联，但不产生患者资料维护资格；有效首次建档来源、既往 Visit 或另行批准的接收资格按 患者资料维护规则 判断，也不开放他医 Note／处方。搜索精确字段和脱敏默认见 组织、数据权限与授权方案。此规则取代旧的 Patient & eMR 一律仅显示当前诊所患者口径。

患者资料保存边界： 基础资料查询按集团及角色授权返回，敏感字段默认隐藏；申请查看须提示操作审计并经独立字段权限判断，详见 Platform §3.2。当前有效岗位有维护动作权限，且患者在同集团任一诊所有登记或有效就诊来源时，可维护相应共用资料；无集团来源的旧患者须接收登记，普通技术 link 和预约 Confirmed 不代替来源。编辑页只提交实际修改的可维护字段，未返回的病史或保险数据不视为空值。医生更正最小安全摘要另需选择本人负责的 Visit；合格护士可直接更正。两者均须保留原详细备注；身份版本与安全摘要版本分开分类。

安全资料快捷录入： Allergy 与 Alert 分别展示可搜索的常用选项及全部选项，药物通用名、品牌、繁体中文别名和药物类别均可搜索。选择只建立待保存的条目，不自动填写过敏确定性、严重程度，也不由药物类别推断具体成分。目录无匹配时可明确以自由文字录入；历史自由文字不自动改写。已存在项目应进入原条目编辑，避免重复。ADR 仍独立录入；空列表不得显示为“无已知过敏”。单项显示最后修改者／时间；历史修改原因、作者及前后内容在版本历史查看。

保险资料独立保存： 保险卡按当前诊所运营权限单独加载与保存，不随患者资料版本隐式覆盖或删除。保存前校验整组待修改卡片，仅可删除本次确实加载过的卡片；新增、修改及删除记录实际操作者和变更原因。若多卡保存部分成功，必须重新读取当前记录再继续，不能将保险保存结果描述为患者资料版本已整体保存。

2.3 历史查看与附件

疫苗为同集团公共记录，获独立公共医疗信息角色读取授权的医生与护士跨诊所读取无需原医生逐记录批准，旧记录缺少 Visit 来源不影响读取；旧疫苗接口写入仍保留原医生权限及修改审计。新注射执行记录按 §2.6 的独立执行权限维护。其余信息按 数据分类与读写矩阵 逐项判断：同集团公共医疗摘要、生命体征等共享资料仍需角色级读取授权，不因来源医生不同逐记录审批；完整 Note、诊断详情、检查结果、正式临床文档、历史附件及处方按来源医生授权判断，药房执行读取另按对应诊所范围，隐私字段独立检查；当前患者可搜索或本次已预约，不表示全部历史可读。受限时提供共用申请入口，不返回正文后再遮罩，也不显示为“无病史”。

2.4 患者持有的保险与企业计划

患者资料编辑的 Insurance cards 页签、共享维护组件及 Overview 汇总统一为 Insurance & Benefit Programmes。Add programme 从一个共享目录选择保险、企业计划、员工福利；保留真实类型和 Policy／Benefit Contract 来源，不合并成 insurance 类型。空记录不代表 Self-pay。

• 保险字段为 Insurer、Member no.、Policy no.；企业为 Organisation、Member / employee no.、Programme no.；员工为 Organisation、Employee no.、Programme no.。有效期与患者计划备注一并维护。
• Primary 文案改为 Patient default，表达患者档案偏好；它只用于展示排序，不替患者选择本次付款安排。
• 更换目录计划时保留患者持有记录及默认标记，但清空旧个人编号、有效期、资格和备注，防止将旧计划资料套入新计划；重复选择同一计划保留已填信息。
• 患者计划维护及预约选择共用类型语义；读回时保留元数据中的企业／员工来源，维护无目录 ID 的旧计划亦不得丢失已记录的类型。修改患者主档不自动重写预约／Visit 的历史快照。
• 公开预览仅使用显式 preview 路由的合成患者及目录；资料编辑可应用到页面会话，刷新重置，不调用真实主档保存接口，也不模拟正式版本审计完成。

2.5 附件上传与识别

本次附件按角色和工作范围管理。 Clinic Manager 在有效岗位及附件操作权限内管理本次问诊附件；父级 Center 对子单位的覆盖沿用 Platform 通用权限规则。护士在当前诊所拥有本 Visit 的有效 Doctor Group 工作范围及附件操作权限时，可以上传、查看和删除本次问诊附件，无需额外申请临床记录授权。Reception 角色本身不授予附件管理权。

完成后补传（2026-10-22）： Registration Queue 对已保存的原生 Visit 保留附件入口，包括 Ready for Cashier 与 Checkout Completed。Cashier Queue 也在每行操作区提供独立 Add attachment 弹窗，交互与账务不变边界见 Cashier 队列规则。上传资格统一见 Consultation §8.2：护士能查看并操作本次预约即可上传，不要求问诊 Edit／Sign；后端核验患者、原 Visit、诊所范围及当前操作资格。Registration 附件弹窗独立读取当前 Visit 内获授权的公共附件列表及下载代理，不为加载列表而读取完整签署问诊；护士操作列表不包含医生私人附件或来源不一致的附件；医生仅按原有逐文件读取资格保留可见附件，文件下载及响应审计均按同一逐文件权限复核，审计不将公共附件升级为完整临床记录访问；实时身份或来源变化仍拒绝返回。进入 Cashier 或完成阶段不要求先退回问诊；签署记录、账务及就诊状态不变，已完成记录的原有删除／修改限制不放开。原生 Closed 的 Consultation 附件入口遵循相同追加规则；导入历史不适用。详细契约见 Consultation 附件规则。

查看历史附件时，应检查原记录授权；当前服务关系或将文件复制到本次，都不能代替批准。删除操作保留来源和审计，保护已签版本及引用证据。附件管理也不授予正式临床文档撤销权，详见 权限方案 §3.5。

• 每个附件最大 50 MB（50 × 1024 × 1024 字节），允许等于上限；多选时逐个文件上传，不把多个文件合并计算。超限在选择时明确提示；服务端仍独立校验。该上限用于统一文件接口，不改变 Excel 导入或录音专用接口的独立规则。
• 选择文件后的状态是「Ready to upload」，必须点击 Save attachments 才写入。弹窗读取既有附件时仍保留用户刚选中的待上传文件，不得用迟到的列表响应覆盖本次选择。发送时显示 Uploading，失败显示 Upload failed 及可重试错误；每个成功文件立即显示 Uploaded 并关联 Patient＋Visit，后续文件失败不反转已成功结果、不重复上传成功文件。
• 文件保存与 OCR 是两个独立结果：识别尚未完成／失败不使已保存附件变成 Pending。识别失败保留原件；同内容文件在另一 Patient／Visit／Clinic 必须分别建关联，不能按文件内容直接复用别的问诊附件。
• 公共 Registration 原件的自动 OCR／手动重试复核当前上传资格、原 Visit 操作范围及逐文件读取权限；待审与保密原件遵守同一文件访问边界，不能借 OCR 绕过 Edit／Sign 或待审限制。每次派发和结果写回继续校验实时身份与同一原件；授权撤销或来源变更时拒绝继续。医生私人附件与其他临床来源保留原临床写权限边界。
• 附件阅读器持续提供可见的 Print／Fullscreen 操作。Print 加强视觉层级；文件加载时说明就绪后可打印；不支持的格式或预览失败时提示使用 Open source。PDF、图片、文字沿用既有打印能力与授权，不以按钮出现证明打印成功（2026-10-17，I-062）。
• 原附件上传／识别改动的历史验证边界：Git、预览发布、STG 配置生效和业务 UAT 分别记录，执行证据见 agent_docs/test_cases/attachments/validation-20260908.md。

2.6 注射与免疫执行记录

Vaccine History 提供 Injection records。2026-10-22 确认 Registration Queue 移除逐行 Injection records 快捷按钮；不删除已有注射记录，不改变其他既有入口及执行权限。具有独立 clinical.administration.write 动作的医生或护士，在当前诊所的有效就诊内记录实际注射；医生限本人负责就诊，护士限有效护理服务关系内的就诊。此权限不授予修改医生已签 Note 的资格。医生完成问诊后仍可记录实际执行；Cancelled／Closed／Voided 等终止就诊不能写入。

每次注射独立编号，同一医嘱参考可以对应多次真实执行。表单区分疫苗和其他注射，记录产品名称／可选编码、实际日期时间及其时区、剂量／单位、途径／部位、可选批号／厂家／效期／剂次、同意和检查、观察／反应／护理备注。已注射记录须有日期时间、剂量／单位、途径及部位，执行者由当前身份确定；历史导入缺失资料不补造。当前医嘱参考为记录文字，尚未作为处方或服务医嘱外键校验，也不代表医嘱授权或库存扣减。

结果分为 Draft、Administered、Not given、Entered in error；未注射不能显示为已完成接种。草稿可以完成为真实结果；已记录结果只能作同结果更正或标记误记，误记记录保留历史。每次保存要求原因、预期版本和重试键，记录、版本及审计同事务提交。更正保留实际执行人，同时通过版本记录更正人；界面提供修改前后、人员、时间及原因。重复请求不会新增一次注射，陈旧版本拒绝覆盖。

Vaccine History 从同一执行记录投影疫苗结果，并继续显示旧疫苗行；其他注射留在执行记录中。未接入外部 eHRSS 发送、库存联动、历史接种补录或医生会签。角色策略及这些后续范围见实施计划。实际测试证据与发布状态另行记录。

无医生仅接种的 Note 与收费完成见 §5.3，与本节实际执行记录分别留痕；选择疫苗并交予 Cashier 不等于已经结算或实际 Administered，也不会自动补造一次注射记录。

2.7 患者标签（V1 已本地实现，工程验证与业务验收分列）

已确认方向（2026-11-01）： 患者标签采用数量受控、统一维护的目录；2026-11-02 已确认管理员独立新增／停用功能，取代此前仅通过版本交付变更目录的限制，日常工作人员仍不支持自定义标签；给患者添加标签时只能从既定目录选择，不能现场自由创建名称。自动未付提示采用中性文案「有未付」，不使用「有欠款」作为标签名称。用户随后确认下列完整第一版方案；业务确认不表示已实现、已部署或已验收。

第一版已确认方案（2026-11-01）： 用户已确认第一版清单、归属范围、维护权限及页面展示；2026-11-02 追加确认护士可维护全部人工标签、Special Attention、五类协助需要及便捷入口（取代此前护士不可维护 VIP 的限制），并要求整理完整开发方案和验收清单。用户随后授权按方案开发、遵循项目 UI 规范、完成本地完整服务链测试后提供预览；不提交、不推送、不部署 STG。本地代码已落地，工程验证及未覆盖子场景按验收清单逐项记录；不代表业务 UAT。工程入口见开发实施方案，逐项用例见验收清单。

固定标签清单

系统预置 14 个默认选项，管理员可在当前医疗集团另增受控普通服务标签（最多 100 个新增项）。VIP 与 Special Attention 独立共存；协助需要最多同时选择 5 项，语言及联系渠道各最多 1 项；有未付由系统计算。默认目录不表示自动给所有患者添加标签。数量是本版固定清单，不是未来永久上限。未记录不生成「无偏好」或「普通患者」标签。默认目录不预置 VVIP、黑名单、难沟通、高消费、爽约、疾病／过敏、套餐持有及逾期独立标签；现有临床安全 Alert、过敏、套餐和通信同意继续按原模块维护。其他语言或具体服务细节沿用适当的既有备注，不通过「其他」自由文字生成新标签。旧自由文本 Alert 不自动批量转换为标签。

有未付的判定口径： 在当前授权范围内，只要任一有效账单仍有患者责任余额大于 0，标签就必须保留。未付款、部分付款、分次付款、仅付清多张账单中的一张均遵循此规则；患者责任余额全部归零后系统自动隐藏，任何角色都不能人工添加、撤销或设失效日。退款或账务调整若重新产生患者责任余额，标签重新出现；付款失败或未知不能提前隐藏。 只计患者责任未付，不含保险／企业及医生应收，不含“本次暂不处理”的未开票项目；补收或有效账务调整后按来源余额自动解除，Deposit 只在实际抵扣后影响未付。金额与责任以 Cashier 为准，标签不新增账务计算口径。具有原财务读取资格时，点开显示授权范围、币种、未付金额、账单及已有到期日；不同币种不直接相加。Lab／Drug Dispensing 的状态展示不开放账单或金额明细。没有到期日不推断逾期，首版不增加独立逾期标签。存在标签不阻断就诊／发药、不改变原结算门禁；无标签只表示当前已查询范围未命中，不代表集团内全部结清。除下述 Lab／Drug Dispensing 的已确认状态投影外，无财务读取资格不返回标签存在性、金额、数量或隐藏标签计数；读取失败显示状态暂不可用，不能显示为无未付。

Lab／Drug Dispensing 全标签展示（2026-11-03 用户确认）： 这两个界面显示全部有效患者标签，包括 VIP、联系偏好、管理员启用的普通服务标签及系统「有未付」，取代此前只显示语言／协助、详情才显示 VIP、排除财务标签的限制。仍须具备 patient.tags.read 及原检验单／配药单的读取资格；VIP 和有未付按该单据来源诊所／Center 解析，其他普通标签沿原集团归属。财务只返回同一患者在该来源诊所的患者责任未付状态，不返回金额、账单、付款记录或补收动作，也不授予财务权限；无明确来源、来源不匹配或已失去授权时不返回财务标签，不能仅凭页面名称或患者 ID 扩大读取。未知状态继续显示暂不可用；无标签不代表其他诊所结清。全部标签在这些页面只读，不新增维护入口，不改变检验／发药及结算门禁。

目录及患者标签维护权限

独立目录管理： 在现有 System Settings 中设「Patient tag catalogue／患者標籤目錄」独立页，由真实 Super Admin 且具有 patient.tags.catalog.manage 动作的管理员维护当前医疗集团目录，不支持 Assume。支持以中英文名称新增普通服务标签，以及停用／重新启用人工标签；名称各最多 60 字，同名拒绝。新增标签归入「其他服務標籤」，可多选，不改写 VIP、语言、财务等既有类别的语义，不允许自定义自动规则。此功能不授予任何患者资料、患者标签或账单读取权限。集团目录复用组织 metadata，变更记录实际操作者及前后值，版本冲突必须重载，不能静默覆盖。

「有未付」为受保护的系统标签，任何管理员都不能停用或改变自动口径。人工标签停用后不可新加，普通摘要不再显示；已有患者关联及历史保留，维护面板标明「已停用」并允许撤销，搜索仍可选停用项以定位历史关联。重新启用恢复未失效关联的正常显示，不重新授予已撤销／过期标签。停用与患者新增操作在服务端串行校验；用户不能绕过界面提交停用标签。既有权限模板的显式禁用保留，新版默认权限与实际环境授权迁移分开验证。

上述为已确认默认能力，最终仍同时校验有效岗位、患者／诊所范围、标签动作和字段权限；旧角色名称不直接授予新动作。共用资料维护沿用 Platform §3.3 的集团来源资格，不能仅凭有预约而取得。VIP 不自动授予折扣、排队优先或额外权限。所有人工变更保存实际操作者、时间、来源诊所及前后值；VIP、Special Attention 添加／撤销需原因，偏好依据可选择患者本人／获授权代述人确认，失效后保留历史。服务需求改变时可撤销，第一版不自动周期性过期或从临床文本推断。

标签管理交互（2026-11-04 用户要求整体调整）： 弹窗顶部汇总已保存的当前标签与来源范围；获授权人工标签提供「×」快捷移除，点击后切到所属类别并标记「待移除」，在保存前可原位撤销。多选仅移除所点项目，保留同组其他选择；跨类别已有草稿时仍须确认丢弃。点击不会立即写入，需底部保存确认；VIP／Special Attention 撤销仍须原因，点击后聚焦原因栏；系统「有未付」及只读岗位不提供移除按钮。主区分为「标签／变更记录／未付账单」页签，历史及账单仅按既有权限显示。标签页使用单一分类列表，直接显示各类别当前值，不再同时提供快捷按钮和分类下拉；默认打开首个获授权分类，点击已有标签则进入对应分类。右侧标明该类别适用诊所／医疗集团，单选项直接选择并提供明确的「未设置」，协助需要／其他服务标签多选，取消勾选即为待保存移除。

每次只保存当前类别。有效期、确认来源、原因／备注在选项下方；VIP／Special Attention 添加与撤销仍须原因，空原因在字段内提示并聚焦。固定页脚提供儲存變更、取消變更及关闭，未实际修改时禁用保存；取消或切换类别时，未保存草稿须明确确认丢弃。查看历史／账单保留草稿，带未保存变更时不能直接跳转账单；关闭／Esc 沿同一丢弃确认，保存中及结果未知时禁止离开，结果未知仅能查询或重试同一请求。保存成功更新当前标签和分类摘要，留在当前类别继续核对；版本冲突保留草稿并显式重载。窄屏分类改为两列、编辑区纵向排列，内容内部滚动且页脚可达。此调整不改变标签目录、归属范围、财务状态、权限或后台保存接口。实现与执行证据见管理交互专项，本地、Git／STG、PRD 发布和 UAT 分别计证。

各页面展示方式

通用展示： 浅色底配文字；VIP 用低饱和金色、语言／联系偏好用中性色、协助用蓝色、有未付用琥珀色，不将普通未付显示为红色风险。颜色只辅助辨认，不改变已有状态语义。默认顺序为有未付 → VIP → Special Attention → 协助 → 语言 → 联系渠道，临床按上表服务优先顺序展示；药房／Lab 使用上表含财务与 VIP 的顺序。超出页内上限使用「+N」，N 只统计本页可展示且用户获授权的有效标签；点击／键盘可展开，不能仅靠悬浮。自动标签标明系统计算及数据范围；人工标签说明来源、更新时间及有效期。切换患者／岗位／诊所后清除旧结果并重读，停用或失效标签不再展示，历史仍可追溯；VIP 和有未付均不改变队列排序。

实施与验收状态： 2026-11-02 新增护士权限、默认目录、便捷入口、管理员目录页和标签搜索已本地实现，列明的专项后端、前端及浏览器流程通过；原第一版列明的完整服务链工程验证保留，不能自动覆盖追加范围；逐项通过、部分通过及未覆盖子场景见验收清单与验证记录。实现需覆盖本节全部入口、权限和自动标签规则；本地完整链验证、Git／STG、应用运行、PRD 发布及业务 UAT 分别记录。原标签及随后入口／资源可选修复已分别完成获授权的 Git／STG 交付，详见专项证据；本次新建病人标签和按钮强化为追加本地改动，Git／STG、目标环境运行及 UAT 状态仍单独报告。优先复用已有功能板块、底表及依赖，不建设独立标签 App，不为同类能力重复建表；管理员目录页位于现有 System Settings。

3. H5 自助填报与审核

功能目的： 减少重复录入，由患者确认信息、护士审核后写入正式资料。

使用者与对象： 患者处理专属填报草稿，获授权护士发码与审核。

操作与结果： 预填发码 → 患者填写并确认身份关联 → 提交 → 护士核对／修正 → 批准或退回澄清。

关键边界： 提交不直接覆盖主档；身份修正或旧确认缺失由护士核实处理，修正、核实依据与患者原始 Consent 分开留痕。

2026-09-07 用户确认（取代旧的提交后常规重复患者核验）： 在患者填写后的核对确认环节完成匹配；患者确认本人信息一致后关联已有患者。护士审核页展示已确认结果，不常驻疑似重复提示或再次要求关联同一患者。

PT-06 状态： Intake Draft → 有效患者专属链接 → 身份匹配／患者确认关联或新患者 → Submitted → Awaiting review／Needs clarification → Approved 或 Rejected。身份更正导致确认失效时保留待审核，由护士核实后继续；链接 Expired 由服务端控制，不使已提交资料必须重填。

界面： 审核时收起非当前任务的患者搜索栏和重复待办横幅；主区使用全部可用宽高。列表与详情随 App 容器宽度改变，760px 以下变为横向选择列表＋纵向详情，480px 以下详情字段单列。正文滚动、主要动作保持可达。Pending／Clarification／Reviewed 可切换；历史及原始提交在处理后仍可查看。编辑中取消须确认丢弃。

自助填報隊列（2026-10-07）： Patient & eMR 在患者目錄及查看患者時均提供「自助填報隊列」入口，限現有具 patient.read 的非醫生診所角色，沿用目前 Clinic／Center／Zone 的資料範圍。「填寫中」為預設篩選，僅表示有效連結已開啟但尚未提交，不能推斷患者正在輸入或完成百分比；另有「尚未開啟」、「待審核」及「已過期」。待澄清亦列入待審核，並顯示其狀態；已提交資料即使連結過期仍列待審核，已過期僅包括沒有提交資料的過期草稿。已核准、拒絕、撤銷及舊版 reviewed 不列入此未完成隊列，處理歷史仍由原審核頁查看。

隊列顯示姓名、已有患者編號、主要電話、草稿參考編號、狀態、發出人員、發出／首次開啟／到期時間；可按姓名、患者編號、電話或參考編號搜尋。各狀態計數沿用相同授權及搜尋範圍，每頁 50 筆，不以今天截斷，按發出時間及草稿 ID 升序，未知發出時間置末。可手動更新，畫面可見時每 30 秒自動更新；隐藏、關閉及進入審核時停止查詢，切換診所／Zone 或任職時不得沿用舊範圍回應。更新失敗保留上次成功的資料、明示錯誤及重試，不冒充沒有資料。「審核提交」只讀取所選草稿的完整審核資料，返回時保留隊列篩選及分頁；關閉隊列恢復原患者及資料分頁。隊列摘要不包含令牌、證件號碼、臨床回答及審核歷史，亦不增加 H5 草稿自動儲存、即時輸入追蹤或提醒。

遺失 QR 的處理： 具現有 patient.write 及有效診所任職的人員，可在尚未開啟、填寫中及待澄清的記錄按「顯示 QR」，再次複製 QR 圖片／連結或下載圖片。有效連結沿用同一草稿及原到期時間，並不使患者手上的連結失效，也不把尚未開啟記錄變成填寫中。連結過期時改為「重新發出 QR」，先說明再由人員確認；沿用現有重發規則，產生新的 48 小時連結，舊連結立即失效，原草稿及已保存提交仍保留。已提交且非待澄清、已核准、拒絕、撤銷及 reviewed 記錄不提供 QR 恢復。取碼時重新核對 Clinic／Center／Zone、任職及寫入權限，只返回連結所需資料，普通隊列摘要仍不包含令牌；關閉或切換範圍清除畫面中的連結及 QR。

审核列表基础展示（本轮设计补充，待实现核验）： 初始 Pending，包含已提交且等待护士处理的草稿，不以今天截断跨日积压；Clarification 显示待澄清，Reviewed 显示已批准／拒绝，未提交和仅链接过期不冒充待审。Pending／Clarification 按本次提交或重提时间升序、Intake Draft ID 升序；Reviewed 按最终处理时间降序、Draft ID 降序，未知时间置末并标记。修正保存不重置原提交时间，真正重提保留各次事件。每行显示患者匹配结果／编号、来源诊所、提交时间、状态、最近处理人及原因入口，不直接暴露完整敏感编号。批准／拒绝成功后移入 Reviewed；并发已处理须重新读取，不重复批准或建档。

审核权限与归属： 正式审核由获授权护士按当前有效 Clinic 任职及生效权限执行；前台的基础字段维护权不包含整份 H5 提交批准：查看需要 patient.read，修正、批准、拒绝、待澄清及重发需要 patient.write。填报草稿绑定发码时的集团与 Clinic；有预约关联时必须与该 Clinic 和患者一致，不能凭患者姓名、预约地点或 Confirmed 状态自动跨诊所转移草稿。护理的 Provider 服务范围与患者基本资料登记分别管控，审核不授予完整 Note／历史处方权限。

审核中的保障卡选择使用患者登记所需的最小有效卡种目录，不额外要求保险合同管理权限，也不开放合同配置或图片管理接口。首次队列加载失败必须明确显示错误及重试入口，不能显示为没有待审核资料；保存过程中禁止继续修改字段，避免提交后遗漏修改。

批准与资料写入： 审核使用服务端保存的患者确认或护士核实结果，界面不能提交另一个 Patient ID 强行关联。已有患者仍须满足集团来源及当前有效岗位的主档维护资格；仅有普通预约不绕过该资格。新患者在批准事务中完成重复身份检查、建档及注册来源 Clinic 归属；批准失败不留下半条患者或保障记录。原预约尚未关联患者时，批准在同一事务中原位绑定已确认患者，保持 Appointment ID、Encounter UUID 与 Chit 不变；预约及 Encounter 的患者一致。并发已绑定则拒绝覆盖。提交、修正和最终批准保留原始提交、当前版本、操作原因和实际操作者，批准同时校验填报版本和已有主档版本；另一人已处理或主档发生变化时必须刷新核对，不能用旧画面覆盖新资料。

护士核实与异常处理： 正常自填审核由护士处理。非身份修正保存后可继续批准；身份字段实质变化、旧记录缺少可信身份确认凭据，均显示「待护士核实身份」，不自动退回病人。当前 Clinic 下具 patient.write 的有效 Nurse 可在审核页记录核实依据并执行「护士核实身份」。服务端依据当前提交重新匹配，返回已匹配病人编号或新病人结果；护士核对该结果后批准。患者原始提交及 Consent 保持不变，护士核实单独记录来源、操作者、诊所、时间、依据及草稿版本，不伪装为患者重新确认。

护士核实不能绕过已有病人的主档维护资格、预约病人一致性、重复身份检查或并发版本控制。匹配冲突时护士应核对修正资料或按现有主档流程解决冲突；系统不允许任选其他病人或强行新建。已提交资料即使旧链接过期、已经重发或处于待澄清，也可由护士核实后继续审核；没有提交内容的空草稿不能核实，已批准／拒绝／撤销／旧版 reviewed 不可重开批准。

仅在护士无法解决的信息疑问、确实需要病人补充时才使用待澄清及可选重发链接；重发的 48 小时有效期、旧链接失效和历史保留规则继续适用。护士不能代填个人资料 Consent 或通信同意；缺少必要 Consent 的记录仍需补齐真实患者同意，不得通过身份核实动作自动生成。旧版 reviewed 仍仅表示旧版已审核，新 approved 才表示本流程事务写入成功。

交付边界： 正式令牌、提交服务和审核路径已有代码；独立预览只使用合成数据，不充当保存结果。当前分支判断见交付状态，实际执行范围见护士核实证据和自填流程证据；这些记录不自动证明目标环境或 UAT 已通过。

4. 预约与资源日历

护理日历范围（2026-11-11 已确认，待实施）： 护士可以查看在本诊所有效任职的医生在各诊所的日历，外诊所仅显示医生、地点、时间和忙闲，不显示患者信息或问诊内容，不提供进入问诊、修改预约、签到或收费的资格。只在其他诊所任职的医生不因该功能进入候选集合。本诊所问诊操作仍限当前有效 Doctor Group；开户只绑定诊所，分组由 Clinic Manager 在独立默认配置／排班界面维护。统一规则见 Platform 工作范围。

跨诊所响应必须由服务端返回字段白名单，不能复用带患者、护理备注和 Visit 详情的完整预约对象再前端隐藏。日历可见、预约维护、问诊访问分别核验。诊所内非授权分组的忙闲展示及旧资源预约例外仍待确认，不由本次跨诊所只读需求扩大。

医生筛选保留用户明确保存的空选择；未选择医生时不发出不受医生选择约束的预约或封锁时段查询，也不自动全选。空态依次区分载入、读取失败、未选医生及当前筛选无匹配，并提供选择医生或重试入口。数量仅指当前筛选，未选、载入中或状态失效时以未知占位显示，不让 0 被误读为当天诊所总量。

同一页面的桌面窗口通过既有 Clinic queue changed 事件使 Calendar 预约状态失效：短时多事件合并，按当前已授权诊所、日期和医生选择重读预约，不重新载入完整 roster、资源或医生偏好。收到失效即暂停旧状态相关操作，失败保持禁用并允许重试，成功以后端状态恢复判断；已打开确认／取消及编辑弹窗同样受保护。保留日期、筛选和草稿，只有服务器实际改变的流程状态字段随回读更新；旧请求、身份切换前响应及卸载后响应不得回填。此机制仅覆盖同页面桌面多窗口，不宣称跨浏览器 tab 同步，后端幂等与状态前置条件不变。

功能目的： 把患者、医生／资源、时间和本次付款安排组成可执行的预约。

使用者与对象： 前台／护士及获授权医生；对象为 Appointment、Provider 和 Resource。

操作与结果： 选择患者和有效时段 → 填写预约与付款安排 → 保存／确认 → 到诊时进入 Registration。

关键边界： 保存预约不等于签到，不赋予跨诊所资料编辑或他医病历权限。

日历与 List 的基本展示： 桌面并排布局的左侧日历与右侧所选日期各占 50%，Grid／List 切换不改变左右比例；右侧列表按自身宽度收紧列宽，保留完整状态标签、现有行高及行内操作。窄屏沿用上下布局。首次进入选当前诊所业务日期，右侧所选日期默认 List，仍可切换 Grid；Calendar scope／跨诊所预约范围放在 Filter 内，不单独占用一行；用户切换日期后 Grid／List 共享所选日期及筛选，不因切视图跳回今天。List 按预约开始时间升序、Appointment ID 升序，同一时间不同患者分别显示；Block-out 明确为不可预约资源段，不显示成患者 Visit。至少显示患者／预约编号、日期与时段、Provider／Resource、Consultation Type、状态及 Remark。取消、改期和 No-show 保留明确状态与历史，不继续当作待签到；不能根据页面过去的时间自动认定 No-show。改期保存成功后按新时段归位；失败保留输入和原预约结果，是否创建新关联对象按已有改期规则处理。刷新、搜索与返回适用共同列表契约。

4.1 新建及编辑字段

预约选人身份核验（2026-10-16 确认）： 正式患者的 Confirm Patient Identity 必须具有已保存 Patient ID、系统 MRN，以及姓名、主要电话、证件类型、证件号码、出生日期和性别六项资料。姓名可使用已有中文或英文姓名；出生日期须有效且不晚于当天，性别须符合现有字段定义，年龄由出生日期计算。缺项或无效字段逐项显示错误并禁用核验声明和 Confirm Patient，确认动作本身也执行相同检查。记录的 Unknown／Other 性别值保留，不能自动猜测。缺少 MRN 须修正主档编号，不在弹窗临时补造。

仅 Virtual Patient 的预约阶段可暂缺身份资料、出生日期和性别：新建快速预约沿用姓名／电话选填；选中已有虚拟主档时保留其 Patient ID、MRN 与 virtual 状态，核对已有预订资料后可继续，明确提示到诊须补齐。此例外不适用于正式患者，也不延伸至 Check-in、创建 Visit 或进入问诊。 2026-10-19 确认：虚拟预约只建立占位身份和运营关联，不提前分配正式诊所 Patient No.（PN）。 身份核实并成功登记为正式患者后才分配；重复保存不重复发号。历史已经分配的 PN 保留且不回收，但虚拟状态下不作为正式编号展示。VPN 是 Virtus Patient No.，不能从其前缀推断患者是否虚拟，身份状态以服务端字段为准。

弹窗提供 Update Patient Information，打开同一病人的 Patient & eMR Overview，保留未保存预约。资料修改继续受现有权限和版本原因约束；打开 eMR 不增加编辑资格。保存／恢复主档版本后，或返回核验弹窗时，重新取得获授权的最新资料，清除旧核验勾选；载入失败时保持不可确认，并提供重试。核验完成前不得把待选病人写入预约草稿。

搜索后快速预约（2026-10-15 确认；2026-10-21 更新按钮布局）： 患者区先搜索。无匹配或搜索结果均非本人时，在结果区直接提供 Create virtual patient；不再要求事先勾选虚拟患者模式。Create virtual patient 与 Register new patient 在结果区底部靠右成组，虚拟患者入口为共享主题浅色实底、深色文字及同色边框按钮，正式登记入口为共享主题深色实心主按钮；窄窗允许换行，标签完整可见。此视觉层级取代原完整登记的弱化次级样式，不改变两条建档路径的权限和提交时机。姓名及电话沿用选填，明确可识别的搜索输入可带入，保留当前时段、Provider 与其他预约草稿。快速录入在原患者区域展开／收起，最终保存预约时才持久化虚拟患者及关联，取消草稿不建档。成功后标明身份待补全；搜索失败不得当作无结果而允许跳过失败提示。正式患者的选人核验规则继续适用，虚拟预约到诊时按签到流程补齐身份。

4.2 操作、状态和异常

预约时段管理（2026-11-02 用户确认）： Calendar 提供独立“预约时段管理”入口，按当前诊所维护普通与套餐预约共用的资源时段，不依赖套餐定义或 Package Setup 权限。获授权管理人员加载服务、当前诊所有效医生及既有时段，明确选择服务、医生（需要时）、资源、起止时间和总容量，再保存；支持载入／失败重试、未保存离开保护及结果未明请求恢复。切换身份或诊所后清除旧时段及草稿，迟到响应不能回填。

一个资源时段可以选择多种服务，所有服务共享所填总容量。例如两种服务、容量 3，合计最多预约 3 人；不得为每种服务各复制 3 个名额。套餐预约和普通预约使用同一容量计数与并发保护，取消后释放原名额。每次预约按实际选择的服务确定类型及医生要求；不能用第一项服务替代全部服务分类。已有单服务时段继续兼容；已占用时段不能通过改换服务、医生、资源或时间移动既有预约，容量不得低于现有占用。医生名单来自当前诊所有效任职，以稳定 Provider ID 选择、切换、保存和回显；加载失败须可重试，不能按姓名猜配。

普通预约资源入口（2026-11-04 用户调整）： 普通预约不再显示“使用已发布服务资源”勾选项及独立外框，不新增服务时段选择步骤；保留原有 Room/Equipment 字段。没有服务时段绑定的预约不查询这套资源、不因命中已配置时段强制选资源，亦不阻挡普通预约保存。编辑已绑定时段的预约仍以简洁的“Service time slot／服務時段”字段回显并核对 Zone、服务、医生、时间及容量；明确清空并成功保存后释放名额，取消编辑不改变已保存绑定。新保存的无需资源预约明确记录该选择，不计入旧预约“未分配资源”核对。既有无明确选择的历史记录保留后端核对语义；套餐权益预约继续从套餐专用流程选择对应服务时段。资源查询使用当前 Centre 的实时授权 Zone，跨 Centre、未授权／停用 Zone 与已选资源容量校验继续有效。本规则替代 11 月 2 日在普通预约中增加资源勾选项的界面方案。

独立动作 appointment.capacity.manage 与 package.setup 分别授权，默认管理岗位为 Clinic Manager／Super Admin，仍按当前集团及所选诊所校验；护理人员可使用已发布时段预约，但不能因此维护容量。明确拒绝不被默认补齐覆盖；界面与 API 执行同一门禁。

预约编辑器的已发布资源查询沿用预约权限及当前成员的实时 Zone 授权。Centre 是会话所属单位，Zone 是实际服务地点，不能要求二者 ID 相等；查询须解析有效服务 Zone，并与预约保存采用相同资源范围。编辑既有预约时保留原始来源单位，只有具备该预约维护资格时才可从容量中排除本次预约。跨集团、跨 Centre、未授权或已停用 Zone 均不得返回资源；资源查询不授予时段管理权限。

AP-05 未指定医生： 先记录诉求、症状及必要背景，按专科、诊所、排班、语言和付款限制提供候选医生及理由，由患者或授权人员最终确认。信息不足或无匹配转人工；推荐不构成诊断，也不自动保存预约。该推荐闭环仍是目标，不能以固定医生列表或专科字段代表已实现。

首次预约与换医生： 首次预约不是从全部医生中任意选择；只能在本次诊所、服务／专科、有效排班、资源及付款条件都匹配的 Provider 中，由患者或授权人员确认。复诊改由另一位医生接诊时，对尚可编辑的预约执行 Reschedule 并显式选择新 Provider；已结束的历史 Visit 保留原医生，不改写归属。新医生能否查看旧医生的完整记录，另按临床记录授权判断；换医生或新预约本身不自动转移历史病历权限。

普通问诊统一类型（2026-11-04 用户确认）： 新建普通预约、尚可编辑预约、签到、Walk-in 及自动／手动复诊统一为 Consultation／问诊，不再按医生 GP／SP 或专科拆分流程。新建预约仅提供一个 Consultation 类型，移除原有 GP／SP 分类说明及类型旁的分类展示，不保留两类预约选项。医生没有专科资料也不触发“缺少 GP/SP”提示或阻止选用有效诊金。问诊收费仍核验实际医生、诊所／Zone、有效价格与币种，不因取消分类而忽略这些条件；没有有效价格仍按原有 Price unavailable 流程处理。疫苗、体检、Prescription-only、Day Procedure 等独立业务类型保持各自流程。旧普通类型在后续允许编辑／签到时兼容统一，已完成、受保护临床阶段或已有收费活动的记录不批量重写。主要专科配置见 Platform 医生资料。本规则取代原 GP／SP 自动分类和管理员补录要求。

No Provider 不是患者状态： 在预约搜索中，它只表示找不到可靠的“最近未取消 Visit 医生”作为参考。它不表示无人负责、不自动建立转诊，也不允许绕过本次 Assigned Provider 的明确选择。界面应显示为 No previous provider，并继续按 AP-05 选择或人工确认本次医生。

预约可编辑范围： 有效维护人员可在状态允许时修改 Assigned Provider、日期、开始时间、时长／结束时间、Consultation Type、Service／Resource、Payment Arrangement、Case No.／Eligibility／Notes 及 Remark；Patient 身份更正进入患者共享表单，不在预约中覆盖主档。保存时重查排班、Block-out、资源、权限和当前版本。Ready 后先明确退回 Preparation，保留系统操作审计及可选备注；已进入 In Consultation 后不得从预约页直接更改临床就诊事实。

转诊当前边界： 系统已能以有效转诊／推荐或另行批准的新预约，为接收诊所建立患者资料维护资格；详见 Platform §3.3。但是完整转诊对象、发起／接收岗位、接收时限、附件清单、回复与关闭状态尚未形成已确认产品契约。在这些规则确认前，不把普通换医生、病历授权或资料接收批准冒充为已完成的转诊流程。

AP-01～AP-04： 新增、日历空格、Reception、患者档案与复诊共用同一预约入口；一般保存状态按明确选择，Reception 新增默认 Confirmed。Unconfirmed 可确认或由 Confirmed 退回；确认及退回未确认须保留该预约已选 Provider、诊所／Zone 和房间／设备，不因后台载入预约或新建表单残留状态清空选择，也不要求重复点击才能完成。只有打开的新建预约草稿主动切换诊所／Zone 时，才清空原 Provider 和资源并重新选择；已有预约继续执行服务端权限、医生有效性及状态校验。改约与换医生走 Reschedule。取消保留记录并释放有效时段，当日取消排在有效日程之后。普通取消、改期、重约、换医生、确认与编辑不强制员工另写原因；系统仍保存动作类型、前后值、实际操作者及时间，用户备注单独保留，不能把系统说明冒充用户填写。此放宽不适用于退款、已签署临床记录更正、权限变更、任务转派或库存调整。保存结果须明确已保存的日期／医生／状态；如修改后记录移出当前服务范围，提示保存已成功及范围变化，不能因后续读取不可用而显示为保存失败。

日历布局（2026-10-26 用户确认短预约展示）： 左侧日历与右侧所选日期 Grid 使用同一时间轴，卡片起点反映实际开始时间。预约卡片设可读的最小展示高度，短预约的显示高度不代表实际时长；卡片明确显示真实起止时间。按卡片的展示范围分列避让，包括实际时间不冲突、但放大后会相互遮挡的相邻预约；显示分列不改变预约时长、冲突判断或可预约时段。左侧优先显示时间与患者姓名，再显示预约类型、医生及状态；右侧重叠列使用紧凑内容和 More，完整详情与全部原有操作仍可访问。完整姓名、医生、类型、状态及预约备注可通过悬浮或键盘聚焦提示查看，不把被省略的内容画到卡片背景外。确认／退回未确认、Check-in、打印标签、提醒、历史及取消仍通过原权限与状态校验后操作。More 可用键盘打开、遍历并以 Escape 关闭。List 保留现有资料列与操作排列。

医生颜色标识（2026-10-27 修正）： 同一集团内不同 Provider 必须分配不同的日历颜色，并以实际完整医生名单检查视觉区分度；采用明亮、轻柔且色相丰富的浅色系，不限定莫兰迪色；通过色相、明度及配套深色标记拉开差异，避免大片灰褐／橄榄色或荧光感。2026-10-27 用户进一步确认，Mint／Seafoam 等近似组合应专门拉开，并连同相近橙色、紫色做全量视觉比较，不能只以色值不相等代替肉眼可辨。颜色按稳定 Provider 身份在服务端持久保存，不随姓名、目录顺序、诊所／Centre、日期、筛选、浏览器或刷新改变；新增医生使用未占用颜色，不重排既有医生。不得再以 Provider ID 对有限色板取余或循环复用；色板容量不足时必须扩充并保留原有映射，不能静默撞色。经确认的色表版本升级可一次性调整各槽的视觉 token，但保留 Provider 与槽的持久关系；新版本之后不随名单规模重排，客户端旧 token 不能覆盖新版本。大规模色表的不同色值不保证全部可凭人眼准确区分，始终显示医生姓名。未指定医生使用中性色。Calendar List 使用对应医生的整行浅色背景和浅底深字姓名标签，可在整行外缘保留细识别线，但不在 Patient 单元格内重复粗色条；Practitioner Name 每个下拉选项显示对应医生的浅色底、深色姓名和圆点；单选时已选医生摘要也使用同一浅色底，多选／全选摘要保持中性底和人数，不借用某一医生的身份色。悬停、键盘聚焦和选中保留医生底色，以轮廓及勾选区分交互状态，周／日 Grid 保持白底卡片与对应医生色条。不同医生的背景和标记均须有区分度。颜色仅辅助辨认，不能替代姓名或权限判断。List 状态在 Time 下方以状态语义颜色的图标＋文字标签展示；医生底色与状态颜色各自表示不同信息。未确认卡片可保留虚线边框，取消记录独立分区。本规则取代此前“36 色可重复”的口径。

Calendar 紧凑展示（2026-10-15 确认）： Go to date、日期范围／翻页、Today 和 1 Day／3 Days／Week 聚在同一组；医生多选筛选位于独立区域，不插入日期与时间控件之间。诊所切换保留原入口和范围规则。List 的患者姓名、医生、Zone 和详情长文字单行省略，悬停可查看完整内容；备注最多两行。时间及状态、患者摘要、Zone、详情和操作按钮整体垂直居中，各文本列仍按可读性左对齐。Consultation Type 移至 Details，Patient 保留患者身份与医生摘要；Zone 使用较窄的独立列，不在 Details 重复，通过限定列宽避免长姓名撑宽或无谓增加行高。List 表头统一左对齐并与行共用列宽；表头固定于列表滚动区域，避免横向滚动后错列。取消列表纵向网格线，用轻量的浅白色水平分隔线区分相邻记录；表头使用浅灰底和柔和的底部分隔线。Time 列留足状态标签宽度，状态标签按文字自然宽度显示且不可收缩，确保 Unconfirmed／Checked-in 等文字完整位于边框内。患者信息按姓名、编号与电话、医生三级展示；List 模式为右侧列表分配较大宽度，Grid 保留原时间比例。2026-10-23 确认：顶部工具栏移除 Insurance Cards；List 每行及 Grid 每个预约的 Actions「…」提供 Insurance policy info，只读查看该预约所关联患者的已保存保险卡和关联 Policy，可在患者多张卡之间切换。无已保存卡显示明确空态，不沿用上一患者资料；未关联已保存患者、缺少 patient.read／benefits.read 或预览模式时禁用。该只读入口不受预约是否可编辑限制，不修改预约、付款安排或保险资料；保险目录维护仍由独立 Insurance & Benefit Programmes 应用承担。

预约范围： 护士可在同集团的有效预约诊所范围内查询并创建预约。普通独立诊所的 Booking clinic 必须具有该护士有效岗位及有效服务关系；选择器、预约查询和直接创建接口使用相同资格校验，创建时重新核验，不能通过修改请求参数绕过。跨诊所总览不提供直接改期／取消。只有原本具目标诊所维护权，切换到该诊所作为当前工作诊所后才能修改；无维护权不允许靠切换或修改请求参数取得。医生的有医生参与预约按本人或有效显式授权过滤，列表、日期统计、医生选项和直接详情一致，完整关系规则见 组织、数据权限与授权方案。Calendar 显示当前操作诊所与记录来源；切换后清除失效编辑表单并丢弃旧请求。

新预约仅提供本次业务资料。医生需要其他医生既往记录时，从患者详情的共用申请抽屉发起申请，不因为预约成功或恢复诊所关系而直接开放历史。申请流程不阻塞已获授权的身份核验和预约工作。

仅关联护士可使用 Calendar 的 Check-in 跳转 Registration 并打开签到界面；打开或取消不提交签到、不新增 Visit、不改变预约状态或患者身份。只有在签到界面完成核对后点击底部 Check in 才提交签到；前台不显示签到入口且直接接口拒绝。Ready 后须先明确退回 Preparation 才允许修改或取消，保留系统操作审计及可选备注；已 In Consultation 的患者不能从前台取消。已到诊记录的回退／取消由获授权关联护士按状态处理；涉及 Appointment 与 Visit 时同一事务提交，失败整体回滚，前台不能借取消预约操作改变签到／护理状态。

Doctor Block-out 填医生、日期、开始／结束、原因及备注。普通问诊与 Prescription-only 不能落入 Block-out；No Consultation 只按护士服务例外处理，仍需检查资源。已有预约不能因新增 Block-out 被悄悄删除或改期。

完整资源需要稳定 Resource ID、诊所、能力、容量、开放时间、Block-out、启停及权限；同预约多个 Assignment 共享主预约。容量冲突、多资源改约、资源停用影响分析仍为待开发设计。

No-show 宽限时间、迟到优先级及收费、资源冲突允许的例外尚待确认；没有确定参数就不预设“迟到多少分钟自动取消”。

日期导航提示（2026-10-17，I-069）： Go to today 只把日期移到今天，保留当前 1 Day／3 Days／Week 检视与医生筛选；天数按钮只改变可见范围，不代表跳回今天。保持已有筛选和数据查询规则。 日历时区默认 Asia/Hong_Kong（GMT+8），不跟随浏览器时区；只在 System Settings → Calendar Date & Time 修改，日历不显示时区标签或选择器。设置按当前诊所共享，持牌 Center 下各 Zone 共用；仅具诊所配置权限者可修改，保存校验当前诊所及原时区并留审计。首次进入、Go to today、日期快捷项与建议预约时间使用该时区；已有预约日期／时间不重新换算。此日历设置不改写财务报表口径或历史记录时间。

4.3 本次付款安排

New / Edit Appointment 与 Registration 共用 Payment Arrangement 组件。它选择本次主要付款／保障安排；Cash／Credit Card 等实际收款方式及金额仍由 Cashier 确认。

• 上层仅三项：To be confirmed、Self-pay、Insurance & Benefit Programme。保险／Corporate／Staff 共用一个可搜索的患者已持有计划列表，小标签说明类型，不要求用户先区分合同来源。选择一个具体计划后，系统保留 insurance／corporate_membership／staff_benefit 的真实类型。
• 新预约初始为待确认。患者主卡／默认计划只决定展示优先级，不自动成为本次选择；无卡也不自动意味着自费。待确认可以保存及签到，但必须在完成 Preparation 前明确。
• 选了计划入口但没有选具体计划时不得保存，应选择计划或改为待确认。资格有效日期按预约／Visit 日期判断；选计划不等于已核验，更不等于已获全额支付保证。
• 待确认／自费不自动读取运营保险卡，避免未完成登记的患者仅打开预约或签到界面就触发保险操作错误；选择保险／福利计划或恢复已保存的计划时才读取患者可用计划。自费只显示本次自付说明，不显示保险卡、资格或 Case 字段。计划显示机构、个人编号、保单／计划号、有效期与本次 Reference／人工计划审核／Coverage notes；企业与员工不叫 Insurer／Policy。
• 编辑和重新打开必须恢复本次已保存的选择与 Snapshot，不按患者当前默认计划或数组第一项重新选。患者主档后续修改不覆盖历史预约／Visit 的付款快照；同一已选计划重复点击保留本次填写内容。
• 更换患者、类型或具体计划，清除原计划的 Case、资格及备注；换后重新录入的本次信息明确绑定当前选择，不继承旧核验结论。选择本次付款安排不修改患者主档；独立卡片维护动作按下述权限及保存规则处理。
• 计划来自患者自己的已持有记录。后端验证患者归属和类型并生成 Snapshot，不信任客户端伪造的计划详情。保险引用 Policy；企业／员工引用对应 Benefit Contract，继续沿用现有主档。
• 预约保存至既有 clinic_appointments.metadata.payment_arrangement，包含版本、类型、持有记录 ID 和来源／基本资料 Snapshot；兼容旧 insurance_* 字段，保留其他 metadata。Check-in 传入 Visit 的 payer_snapshot，登记准备可保存本次安排并同步原预约；本次修改记录审计。
• 已进入 Ready／问诊后的安排变更需先按现有流程回 Preparation；存在账单时拒绝通过预约／登记直接更换，走 Cashier 调整。不会重写原发票、付款金额或临床签署记录。
• 企业／员工计划可能仅提供协议价或福利；不能仅凭选中计划建立企业应收或假定企业付款。后续保险全额／CoPay、实际收款及欠款确认统一进入 Cashier 付款责任，本次选择和人工核验只作为该步骤输入。
• 旧预约按其自身保存信息兼容读取，明确旧 Self-pay 保留自费，已有保险 Snapshot 保留保险，空值为待确认；无法可靠辨认的旧企业记录不按名称猜测类型，需重新选明确计划。旧 Visit 无新版付款快照时继续原有准备契约。
• 查询失败保留已保存选择并显示重试；搜索无结果与患者无计划分别显示空状态。选择器支持键盘焦点，所有新／编辑预约入口继续共享实现。

预约、签到与准备时维护患者保险卡（2026-10-22 更新）

目的：患者在预约时提供卡片、带来新卡、原档案没有卡片或 Virtual Patient 首次到诊时，获授权人员可在 Appointment、Check-in 或完成签到后的 Prepare 的 Payment Arrangement 区完成补卡，无须离开当前页面。Prepare 的 Payment arrangement 标题区直接提供 Add insurance card，即使暂选 Self-pay 或没有已存卡也可新增；Appointment／Check-in 仍从 Insurance & Benefit Programme 区进入。已选持有卡提供 Edit selected card，复用患者资料中的共享卡片维护组件，以单卡表单展开。只对有当前诊所保险运营维护权限的人员开放；签到前按预约的最终患者保存，签到后 Prepare 按当前 Visit 的患者保存；Prepare 入口另须具准备资料保存权限，只在允许修改付款安排且尚无账单的准备阶段保存。已进入 Ready／问诊须先按现有流程退回 Preparation，已有账单走 Cashier 调整。已有卡列表、目录查询失败和空结果仍分别展示；没有卡不自动选择 Self-pay。

• 字段与来源： 从现有 Insurance & Benefit Programmes 目录选择卡样，展示配置的参考图片，机构／计划由目录带入；填写卡号／会员编号、生效日期、到期日期，保单／计划编号及备注选填。沿用 insurance、corporate_membership、staff_benefit 的真实类型与字段名称。当前版本卡样、个人编号及两个日期必填；不将空到期日解释为永久有效。不在签到入口创建卡样或维护合同；目录无对应卡样时交由目录管理员处理。
• Check： 检查必填、真实日期、起止顺序、字段长度及同一患者已有有效持有记录中的重复卡样＋卡号；比较卡号时忽略首尾空格和大小写，保留号码内部字符。不虚构统一卡号长度／纯数字格式或外部保险机构核验能力。出现重复时提示选择已有卡或编辑有效期，新卡不覆盖旧卡。相关字段或患者变更后检查失效，保存由服务端再次验证。
• 有效期与资格分离： 按预约／Visit 日期提示未生效／已过期，允许保存正确记录的卡片资料，不能将 Check 通过解释为保险资格、预授权或支付保证。保存后本次资格恢复待审核；原有人工审核与完成 Preparation 的门禁继续适用。
• Virtual Patient 归属： 可先填写并检查卡片草稿；正式保存前必须在患者区完成身份核实、查重及候选选择。确认新患者时先保存身份，再将卡片写入确认后的患者。查重改选已有患者后，重新加载目标患者的持有卡；新卡草稿保留，但须明确确认属于当前患者并重新 Check。已有患者卡片的编辑不能转移到另一患者；切换前提示放弃该未保存编辑。服务端保存时锁定并核对预约当前患者与请求患者，虚拟身份或已变化的归属不能通过。
• 预约时维护： 真实患者可在新建／编辑 Appointment 直接新增或修改已选卡；卡片独立保存，仍须保存预约才持久化本次付款安排。该入口只用于签到前的预约；患者归属、诊所权限、重复卡、旧版本及重试校验沿用单卡维护规则。
• Virtual Patient 预约草稿（2026-10-22 确认）： 预约阶段只把已检查的卡片资料保存为 Appointment 草稿，不建立患者持有卡，不赋予资格或把草稿当成已选持有卡；付款安排保持待确认。重新打开预约可以查看及修改草稿。Check-in 自动带入草稿，须完成真实身份处理、确认卡片归属并重新 Check；保存患者卡时原子消费对应草稿版本，同一请求重试不得重复建卡，旧预约窗口不得复活已处理草稿。取消本地卡片编辑不等于删除预约已保存草稿；若本次不使用，可取消编辑并明确选择其他付款安排。
• 查看卡片与 Policy（2026-10-22 确认）： Reception 列表仅在本次到诊已选择保险卡付款时，于患者姓名／EMR 入口旁显示紧凑的 Check Policy 图标按钮（保留文字提示与可访问名称），无须进入 Check-in／Prepare；自费、付款方式待确认或仅患者档案存有保险卡时不显示。以本次 Visit 付款快照优先，不因患者默认卡或预约后续修改而改变显示条件。已选卡旁亦保留 View card and Policy／查看保險卡及 Policy。列表入口优先展示本次付款快照已选卡；无已选卡且仅有一张已存卡时直接展示，多张则由用户选择，无卡显示空状态。按需读取患者卡片，沿用 patient.read、benefits.read 与服务端患者范围校验；切换卡片仅影响查看内容。弹窗只读显示会员编号、患者保单号码、卡片有效期、目录卡片样本、按 programme ID 实际关联的 Policy 合约及计划指导信息；患者保单号码与 Policy 合约号码分别标示。未关联或读取失败明确提示，不按机构名称猜配，不修改本次付款安排或资格结论。目录卡样不冒充患者上传的实际卡片。
• Cashier 接续（2026-10-24 确认）： check-in／Prepare 保存的付款安排作为 Cashier 初始值，未冻结账项可在 Cashier 的 Insurance／Self-pay 下拉中改为自费或改选患者持有的其他保险卡；选择 Insurance 后可从保险卡下拉末项新增卡，或维护已选卡；换卡／改卡后重新审核，保留原登记快照。卡片维护与本次账务确认分开提交。具体交互、责任分配及付款方式规则见 Cashier §5.0，不扩大 Reception 的修改状态或 Policy 按钮条件。
• 保存与签到： Save and use for this visit 独立保存患者持有卡，并明确选作本次付款安排；不会自动提交签到、改变患者默认卡或重写历史预约／Visit／账单快照。编辑已选卡后更新本次草稿 Snapshot，并清除旧 Case／人工审核结果。底部 Check in 或 Save preparation 仍单独提交；存在未保存卡片草稿时须先保存或取消。Prepare 内新增／修改后自动刷新可选卡，并更新本次草稿；只有保存准备资料才持久化本次付款安排，不自动完成 Preparation。
• 恢复与审计： 关闭保留未保存提醒；校验或请求失败保留输入。保存结果未知时保留同一请求用于重试，防止重复新增或重复应用编辑；服务端检测已有卡被他人修改的冲突。身份保存、卡片保存及签到／准备提交分别计结果；卡片已保存而签到／准备提交失败时保留卡片，重试后续步骤不再新增卡片。新增／编辑沿用实际操作者、时间、原因及变更审计，不随患者资料版本隐式保存。

代码、本地浏览器、隔离 API／CI、预览发布与正式后台／UAT分别记录；本次卡片维护与查看见本地验证，既有付款安排见 agent_docs/test_cases/appointment_payment/validation-20260907.md。

4.4 本次计划人工审核

保险付款在 Appointment、Check-in／Prepare 显示独立医生支持检查，按所选计划、稳定医生、诊所和本次日期自动匹配；缺少规则显示 Unknown。前线可申请例外，获独立确认权的 Insurance／Billing 核实后确认；该例外不替代下述人工资格及预授权。未保存医生／日期等修改不能沿用旧结果，预约转 Visit 仅在相同上下文继承；规则与审计口径唯一见保险医生支持及本次例外。

Appointment 与 Check-in／Preparation 的计划板块统一提供 Review and confirm manually（人工审核确认）。展开后逐项确认：已核对患者卡及所选计划、已核对计划或个人资料变化、已核对本次日期的有效期；另分别记录资格结果和预先申请结果。此入口不调用旧保险 Check／Benefit QR 校验，不将本地资料比对表示为保险公司实时答复。

• 资格结果：Eligible（人工确认）、Not eligible、Awaiting confirmation。预先申请：确认不需要、需要且已获批、申请／批核待处理、尚待确认；选择已获批时必须填批核凭据编号。审核备注可记录确认方式、变化、限制及跟进事项。
• Confirm manual review 记录本次表单审核；保存预约／登记后，服务端记录实际登录审核人、UTC 时间、上述核对项及结果，绑定本次计划快照和就诊日期，并随 Appointment → Visit 保存。界面显示明确的人工审核结果；单独提交旧 Checked 或伪造嵌套审核人／时间不能建立审核证据。
• 待确认、不合资格、申请待批可以保存、签到或继续 Preparation，但不能完成准备交接。只有三项核对完成、人工确认合资格、无需预先申请或已获批，且计划在就诊日期有效，才能完成准备。自费继续不需要计划审核。
• 相同计划和日期再次保存保留审核人、时间和结果；更换计划／患者或就诊日期后重新审核。旧计划 Snapshot 的历史内容不由患者主档更新自动覆盖。已进入临床阶段或已有账单的变更继续沿用 §4.3 限制。
• 人工确认不是付款保证；第三方责任、自付金额、最终收费复核和实际收款仍由 Cashier 处理。旧 Visit 无新版付款快照的兼容契约不在本次进行历史数据迁移。

代码与验证证据见 agent_docs/test_cases/appointment_payment/manual-review-validation-20260907.md；公开预览使用合成记录及 Preview staff，真实审核人由后端认证上下文写入。正式后台部署、端到端联调与业务 UAT 单独验收。

4.5 Reminder 模板与消息生成

本节是面向患者的消息生成工具；§4.7 Calendar Reminder是安排护士何时联系患者的独立工作记录，消息复制／打开渠道不等于已完成提醒。

2026-10-19 用户确认：采用个人模板＋系统预设，不建设诊所共享模板。2026-10-23 更新：Reminder 使用按内容高度显示的紧凑弹窗，移除 Trigger History 区；保留复制消息与打开 WhatsApp／SMS／Email 的人工发送流程，并新增 WeChat 与普通话（简体中文）预设。WeChat 只提供 Copy for WeChat，员工自行粘贴至微信对话发送，不推定发送或送达；触发记录只证明已复制／打开渠道，不能表示已发送或已送达。

• 现有旧病人提醒、新病人提醒、改约通知作为唯读系统预设；用户可复制为个人模板，不能覆盖系统预设。个人模板仅当前有效使用者可查看、维护和设为默认，服务端按使用者与医疗集团保存，在同集团不同诊所及设备间可复用。角色模拟沿用实际被模拟身份，不能写入操作者或另一用户的模板。
• Reminder 模板选择区分“我的模板／系统预设”，提供唯一的 Edit templates 编辑入口；支持新建、编辑、复制、删除及设为默认。每个模板含名称及英文／繁体中文／普通话正文，至少维护一种语言；不自动翻译。切换到仅提供另一语言的模板时同步显示该模板的可用语言；在同一模板中切换至未提供的语言时明确提示，不静默套用另一语言。删除当前默认个人模板后回退至旧病人系统预设，历史消息不受影响。
• 正文以纯文本和受支持变量组成：{{patient_name}}、{{appointment_date}}、{{appointment_time}}、{{doctor_name}}、{{clinic_name}}、{{clinic_address}}、{{clinic_phone}}。编辑器提供变量插入及本次预约预览；不执行表达式、HTML 或任意代码。名称不超过 100 字符、每种语言正文不超过 10,000 字符、每用户每集团最多 50 个个人模板。
• 姓名、医生、预约日期／时间来自获授权预约；诊所名称、地址及电话来自预约所属诊所，持牌 Center 地址优先使用其登记场所地址，登记场所为空时可使用经核实的单位地址，不套用员工当前工作诊所或固定地址。提醒变量接口与病人预约查询使用同一行级读取范围：护士须有来源诊所的有效任职及对应医生／服务关系；无任职、已到期或已撤销的服务关系不得读取提醒变量，不能仅依赖界面入口隐藏。日期与时间保留预约的本地墙钟语义。缺少模板所需资料时保留可识别占位文字并提示；员工补充或移除占位文字后才可复制／打开渠道，不猜测缺失资料。
• 地址配置（2026-10-19 确认）： {{clinic_address}} 使用 Organization 的 Entity／Site 配置：普通独立单位可维护 Address；持牌 Center 继续维护 Licensed premises address，Zone 沿用所属 Center 的持牌地址并显示继承来源，不另设覆盖值。2026-10-23 的地址补齐只匹配已核实的机构名称及单位代码，并记录官网来源；保留已有地址，不按模糊名称猜配。无法核实的单位及通用演示诊所保持空白。地址为空时保留缺失变量提示；配置修改影响后续生成的消息，不改写既有提醒历史。
• 生成消息后可单次修改，修改不自动回写模板；不提供 Save as my template；所有模板新增、修改及复制均在 Edit templates 内进行，员工自行将需要复用的内容设置为变量。切换模板／语言或关闭已修改消息时保护未保存正文；模板编辑、切换和关闭同样保护未保存修改。模板保存不能覆盖正在编辑的本次消息。
• 后端核对当前身份与诊所请求上下文，并以版本检查拒绝另一窗口造成的过期覆盖。发生冲突时保留本地草稿，提供重新载入最新模板；其他模板的远端增改继续保留。同一模板已被远端修改时，展示远端版本并由用户明确选择保留自己的草稿或采用最新版，再保存；远端已删除时只能把保留的草稿另存为新模板，不能以旧版本复活原 ID。提交结果未确认时，先保留恢复依据并锁定模板编辑与离开，回读核对是否已保存后再决定是否重试，不重复创建。载入／保存失败不能冒充空模板或保存成功。触发历史保存当次正文、模板名称、渠道及实际动作，后续模板修改／删除不追溯改写记录。

发送提醒与模板维护统一使用共享 AppDialog、Element Plus 表单和当前系统主题；病人及预约日期作为紧凑上下文行，不使用渐变大标题。渠道／语言选择与正文清楚分区，Edit templates 使用铅笔图标及主题色次要入口；发送／打开渠道仍为主操作。模板列表标明当前选择、系统唯读及默认项；加载、冲突、保存恢复与未保存保护保持原规则。

4.6 病人全部预约查询与定位

2026-10-19 用户确认：Calendar 提供独立 Patient appointments 弹窗，默认当前诊所、全部日期及全部状态；仅用户主动选择后，才查询已有权限范围内的其他诊所。

• Calendar 的 All appointments／全部預約 入口紧邻顶部患者搜索框右侧，同高、紧凑白底浅边框，使用日历搜索图标；不再放在诊所／日期导航行。日历当前搜索继续用于当前视图筛选，提示说明当前范围；全部预约按钮提示跨全部日期、默认当前诊所，并带入搜索词。按姓名、编号、电话及现有身份匹配信息搜索后明确选定病人，再以稳定 Patient ID 查询；2026-10-21 用户确认另支持 Nurse note（含旧 Remark／护理内容）与 Insurance policy number 的不区分大小写、包含式匹配。新增字段从当前诊所、当前角色可读的全部日期／状态预约记录检索；不因主日历日期筛选而遗漏历史或未来预约，同一患者去重。匹配只返回既有患者身份摘要，不向集团身份目录额外暴露备注／保险详情，也不扩大医生／护士可读预约范围。不按同名或共用电话混合预约，也不进入新增预约的身份核验。预约详情提供同一病人的查询入口。
• 查询不受主日历当前日期、医生或状态筛选限制，默认包括历史、今天、未来及取消预约。时间筛选为全部／今天／未来／历史；日期归类以所选诊所日历时区的今天为准，与预约业务状态分开，过去日期不自动表示完成。默认顺序为今天、由近到远的未来、由近到远的历史；排序在服务端完成后分页，每页默认 25 条。
• 可按已有权限范围内的诊所、医生、状态筛选。诊所及医生选项、条目、总数、详情和后续动作均受同一现行预约权限限制；“全部”不扩大医生／护士授权，不等于完整病历访问。默认只看当前诊所；跨诊所查看不改变当前工作身份，不赋予改期／取消／Reminder 的维护权。
• 顶部保留病人姓名、已记录编号及必要联系方式；列表显示日期／时间、诊所／Zone、医生、预约类型、业务状态，并提供 View details 和 Locate in Calendar。取消记录明确标记，不能默默过滤。详情及定位返回后保留搜索、筛选、分页和列表位置；优先按原可见预约及滚动偏移恢复，记录已被移出当前结果时回到仍可用的原滚动位置。
• 定位以临时预约视图切到目标日期并高亮该条，提示病人、来源诊所与日期，临时绕过仅用于展示的日历筛选；不覆盖已保存的医生偏好。Back to patient appointments 恢复原日历日期／视图并返回原查询结果；Restore calendar 恢复原日历。跨诊所定位只展示已授权来源预约，不自动切换工作身份或开启维护权。从预约编辑器进入查询／定位时保留原未保存内容和编辑基线；恢复时还原原日历范围及 List／Grid。活动及暂存草稿均参与关闭工作窗口、切换身份及离开编辑的未保存保护，取消离开须保留输入；保存进行中不得离开。再次定位或返回不能默默覆盖另一份正在编辑的内容。
• 没有当天预约的病人仍可查到历史／未来记录；无匹配病人、无预约和查询失败使用不同状态，失败提供重试，不能显示为“没有记录”。切换病人或工作身份须取消旧请求并清除失效上下文。

4.7 Calendar Follow-up Reminder／护士跟进提醒

决定及状态（2026-11-01）： 用户最终确认护士新建任何实际 Appointment（含普通问诊、复诊、疫苗及其他预约）成功后，均提供是否创建 Reminder 的入口；多次接种可按针次生成多条，且覆盖已确认但尚未预约的后续针次计划。该补充取代此前仅 Follow-up 预约触发的范围限制；预约通用化及计划项扩展已本地实现，验证覆盖与未执行分支单列于专项证据。完成 Cashier 本轮处理确认后亦自动弹出 Reminder 创建入口；同日澄清：Cashier 完成仅是弹窗触发时机，检测是否已付款／已形成结算不是提醒资格，未付款、下次再付也须覆盖。本澄清取代先前按有效结算／付款安排筛选检测的表述；Calendar 单独显示 Reminder 类型，不沿用 Book No Consultation 的逻辑。用户随后已授权按方案本地开发及完整流程预览。独立 Reminder、创建入口与 Calendar 固定栏／弹窗已本地实现，已完成列明的本地完整服务链专项验证，实际覆盖与预览见 专项证据。2026-11-02 用户追加授权：完成测试修复、整体复核及一轮迭代优化后，提交推送并合并 STG；Git 交付结果与 STG 应用运行／业务 UAT 分别记证，当前执行状态见专项记录。PRD 发布状态见交付说明，与应用运行／业务 UAT 分开记录。

使用岗位（2026-11-01 用户进一步确认）： 本节整套患者跟进 Reminder 仅对当前有效护理岗位开放，包括 Calendar 栏位／计数／列表／详情／历史、来源手动创建及业务成功后的自动弹窗。医生、管理员及其他非护理岗位均不可见，也不得通过 API 读取、创建或处理；拥有旧 Reminder 动作授权不能绕过岗位限制。2026-11-02 按护士默认可用的原业务意图修正：有效 nurse／frontline-staff 默认取得 Reminder 查看、创建、处理及管理动作，无须为每名既有护士补配；旧角色或已发布模板未列出新动作时采用此默认，明确禁用仍优先，权限目录停用也不被绕过。2026-11-09 用户确认 Nurse 与 Frontline Staff 为同一护理角色（身份兼容规则见 Platform §4）。在当前已授权诊所内，具备预约读取及创建／维护／签到操作资格的员工，可为该范围内的真实预约设置、查看和处理其 Reminder，无须额外护理服务关系。自动弹窗与手动新增使用同一资格；有效岗位、账号、集团、Clinic／Center／Zone 和 Reminder 动作权限仍逐次检查。完成后的提醒也按当前资格读取，任职／Zone 撤销或账号失效后立即拒绝后续访问。此路径仅适用于纯预约来源；临床 Visit、检测、未预约计划及混合来源保留原有护理／临床校验，跨诊所仍须原有有效目标岗位与护理服务关系，不因本诊所资格扩大。本规则取代此前允许医生在来源创建的约定。

目的与责任： 让护士在日常预约／收费操作后顺手安排联系患者，并在日历中完成或延期处理。Line A 主责，WS1 承接日历与提醒，WS5 承接 Cashier 处理完成后的提醒入口触发，WS2 对接问诊结束时创建复诊预约的成功结果。提醒完成只表示本次提醒工作完成，不代表检测执行、报告出具或问诊完成。

4.7.1 类型、对象及范围

Reminder 是日历记录类型，不是第八种 Consultation Type，也不是 No Consultation 的子状态。已有 No Consultation 继续承载真实护理／资源预约；不批量转换历史预约。Tasks & Notifications 中的个人 Reminder 仍只提醒本人，不自动转成诊所共享跟进；本功能不要求护士进入 Task，也不建立需要重复完成的两份事项。可复用现有消息模板及审计能力，来源和状态仍以本条 Reminder 为准。

第一版自动化为业务成功后自动弹出、自动预填、人员一键确认创建。静默自动创建、自动发送患者消息、周期性催办、临床检测时间推断、检测结果追踪及历史回填不纳入第一版。未预约的后续疫苗针次由护士显式确认后纳入计划跟进；这不等于建立自动医学排程或通用人群召回。套餐剩余服务次数仅是使用权益，不能直接当作已确认接种计划。

4.7.2 业务触发与失败恢复

以下入口均先核验当前护理岗位与创建权限： 非护理岗位完成相同的预约／问诊／收费操作后不展示跟进 Reminder，也不自动代建；有权护士可随后从已保存来源补建。

将触发时机与提醒资格分开： 完成 Cashier 本轮处理确认（包括零实收、下次付款或本次暂不处理的安排保存成功）是集中展示入口的工作流节点，不等于患者已经付款，也不要求所有检测项目今天执行。候选范围来自本次 Visit 已保存、仍需跟进的 Lab／Imaging 项目，不限本轮已付款／已开票行。付款状态仅供核对，不作为创建 Reminder 的门槛；Reminder 也不解除原检测执行／收费门禁。

候选按本次 Visit 的具体已保存检测服务项目判断，不按实收、是否已结算或付款方式筛选。尚未保存的检测草稿不能成为来源；付款草稿未提交只表示尚未到自动弹窗节点，不表示已保存检测不能手动设置 Reminder。已取消、已作废或来源已明确完成的检测项目不默认纳入；执行状态未知时明确显示未知，不能把“已付款”当成“已检测”。已有实际检测预约仍可安排提醒，弹窗展示其真实时间。

弹窗在原业务成功后的安全位置展示，不遮挡仍需完成的付款确认，不抢占未保存表单。同一成功操作产生多个检测项目时只弹一个汇总入口；不同患者或不同成功操作不混合。允许「暂不创建」，记录该来源已提示／已跳过，不创建空 Reminder，也不因页面刷新不断重弹。来源预约／付款详情保留「Set reminder／设置提醒」及已有 Reminder 状态，可稍后补建；当前无创建权限时不展示可执行创建动作，后续由有权人员从来源补建。

预约／Cashier 处理确认成功与 Reminder 保存分别返回结果。Reminder 失败不得回滚或重做已成功的预约／Cashier 处理，明确显示「业务已成功，Reminder 未创建」，保留输入并仅重试 Reminder。超时先查回实际结果；已经创建则返回原记录。关闭页面后来源详情仍可恢复设置入口；待创建提示不是正式 Reminder，不计入日历待处理数。

跨诊所预约： 合法跨范围建约保留原成功结果。新预约不属于当前护理身份可操作的诊所／Center／Zone 时，不直接以当前身份请求 Reminder 候选；成功反馈明确提示通过 Calendar 顶部诊所／Center 切换至目标护理身份，再打开该预约使用「设置提醒」。不自动切换身份、不放宽 Reminder 数据范围；同 Center 内属于当前护理授权的其他 Zone 不因日历视图筛选而被误判为越范围。

普通待安排 follow-up（2026-11-02 已确认并本地实现）： 在Cashier 后续安排中明确选择 Arrange later 后，以该 Visit 的已保存交接安排为稳定来源建立护理 Reminder；不冒用疫苗针次计划，不虚构 Appointment／Visit／Chit／收费。不支持脱离该交接的泛用 Recall。必填下次联系日期并明确合资格护士或诊所护理团队责任；没有真实预约日期时仅使用固定联系日。

后来预约落实，原“联系安排预约”提醒按预约已落实结束并留历史，不标为已联系；新的预约前提醒由护士按真实预约确认。病人明确拒绝时结束对应待安排提醒，原因可选填。取消真实预约时同步处理仅关联该预约的提醒；有其他有效来源的提醒只解除受影响关联，不误取消检测。完成一次联系提醒不自动等于已预约或病人拒绝。该类提醒记录联系完成时同时明确后续结果：继续联系须填写下一次固定联系日并原子建立下一条待处理提醒；病人选择不安排的原因可选填。已经落实预约的来源按预约已落实结束，不冒充实际联系。既有护理权限、患者／诊所隔离及消息复制不等于联系完成的规则保持。工程契约见实施方案，实际本地验证、Git 交付和目标运行／UAT 边界见交接专项。

4.7.3 快捷表单与日期

统一安排卡片（2026-11-02 用户确认并授权开发）： Calendar 预约后、Cashier、来源手动设置及已建 Reminder 查看／编辑弹窗采用同一小卡片组件。病人信息只在弹窗顶部显示一次；每张卡片显示真实 Consultation type 或检测分类、医生／执行机构、预约状态和时间、自由文本 Nurse note、提醒日期及可选时间。Consultation、Lab、Imaging、Vaccination 等沿用类型颜色并保留文字，不只用颜色区分。卡片宽度上限约 340px，单卡弹窗随卡片收窄，多卡保持相同宽度横向排列并在窄屏顺排；卡片不因检测类型、剩余数量或容器留白而拉伸。选择「无需创建提醒」后原位保留同款小卡片，以状态及「恢复提醒」动作呈现，保留草稿，不改为横向列表／折叠汇总；已有提醒也使用同款卡片进入查看／编辑。不再用大块「Booked appointments／Contact schedule」或分组原因说明。Calendar 原位 Reminder 栏、日程 Grid／List 的既有版式保持不变。

• 自动带出与新增： 已保存实际预约保留真实时间；未确认检测安排的日期／时间为空。Cashier 同一 Visit 的获授权实际后续预约及检测可集中带出，候选必须同患者、同责任诊所且逐来源鉴权，不按姓名／相近日期猜配。新增 Reminder 先选真实 Consultation type 或检测类型，选择对应已保存来源，或在符合既有条件时添加已确认后续针次；类型选择不创建虚构服务或绕过正式预约。没有相应来源时先完成原预约／检测流程。

• 分组操作： 默认按执行机构及检测分类生成小卡片，明细折叠。提供「合并至…」「拆分安排」「无需创建提醒」及恢复入口。同机构且尚未绑定既有预约的兼容卡片可合并，使用目标卡片时间及提醒安排并保留双方备注；拆分把真实服务行移入新的时间待确认卡片，每行只属于一个安排。单一不可再拆的真实服务不能复制为多张来源相同卡片；已有正式预约通过原预约入口改期。无需提醒只排除本次创建，不取消检测或真实预约；全数排除可结束而不创建提醒。

• 已有提醒： 已设置项目保留「查看／修改提醒」，不再次默认选中。详情／处理也使用同款卡片，来源明细和历史可展开；保留稍后联系、联络结果、负责人、取消及恢复规则。发送病人消息弹窗沿用卡片外观，消息模板／渠道操作仍是人工发送辅助，不把复制或打开渠道宣称已送达。

• V-Lab： 护士选定组内项目、预约日期／时间及提醒安排后，保存时调用正式预约的权限、患者、冲突和资源校验，在来源诊所建立已确认的无问诊预约，并以稳定服务行标识关联内部执行机构。已有精确项目关联的有效预约自动带入，改期从原 Calendar 预约进行，不按患者姓名或同日时间猜配。预约与本批 Reminder 同一事务；任一组失败均不留下部分新预约／提醒，重复提交沿用同一结果。

• 第三方： 人员填写与机构确认的预约日期和时间，系统只保存这份安排，不宣称已调用第三方系统或自动取得预约。不同人工预约保持独立分组。

• 自动流转边界： 已存在的获授权 Lab 请求／执行详情按精确来源展示预约安排；后续符合原签署及结算门禁的检验交接仍沿既有流程进入 V-Lab。建立预约不新建 Visit／收费、不绕过签署／结算／执行门禁，也不标记已采样、已检测或护士已联系。预约建立地点为来源诊所，不冒充 V-Lab 实验室资源时段库存已锁定。

• 联动： V-Lab 预约改期后，相对 Reminder 随目标日期重算；固定 Reminder 保留原日期并提示需核对。有真实检测来源关联的 V-Lab 预约在执行前允许取消，普通 No Consultation 确认后的取消限制保持不变，伪造元数据不能绕过。取消关联预约取消其未完成 Reminder；取消 Reminder 本身不取消真实预约，再次设置时仍带入原预约。第三方人工记录由人员核对，外部状态不自动同步。

• 失败反馈： 原先已成功的 Cashier 操作保持成功；本次检测预约与 Reminder 是否保存另行明确反馈，保留分组输入供重试，不能在失败时声称新预约已成功。

多条提醒设置： 真实多预约与未预约针次分别标明来源状态；每卡独立设置联系日期、可选时间和 Nurse note，保留真实目标日期，可选择无需创建提醒并恢复。相对提前天数只按该卡已知目标日期换算，结果在卡内可见，过期结果要求调整。不同预约及不同针次各自生成 Reminder；同一天也不把多个针次压成一个状态。只选部分行时仅创建已确认行，原业务结果不受影响。批量保存使用同一命令键，失败保留各行输入；来源失效或任一所选行非法时不留下未确认的部分提醒。

主要按钮为「Create reminder／创建提醒」，次要按钮为「Not now／暂不创建」。已有有效 Reminder 时展示「View / Edit reminder」，已纳入的项目不默认再次选中。护士确认前始终可见实际提醒日期；过去日期／已过时间不能静默保存，提示改为今天、未来时间或调整提前天数；无有效默认时由人员选定，不猜测。

可记住同一用户、同一诊所下上次明确采用的问诊提前天数，作为下次可修改的预填；检测日期不因上次使用而自动套成临床规则。Lab／Imaging 的提前 1 天仅为已确认的可修改界面预填；其他全诊所默认提前天数及静默自动创建策略仍待后续决定，不自行补定，也不把预填视作临床要求或自动创建授权。

4.7.4 日历呈现与状态

固定栏位＋原位展开（2026-11-02 用户确认原型并授权落地）： Calendar 右侧所选日期标题／工具行下方、预约列表或时间网格上方保留 Reminder 栏。首次进入或切换日期／责任范围后，有待办时默认展开；没有待办时收起并显示真实 0（2026-11-02 用户后续反馈，取代此前默认收起）。护士可手动收起／展开，当前范围内后台刷新保持手动选择。有待办时标题使用琥珀色浅底、强调边及数字徽标，同时显示「To follow up／待跟进」，收起后仍明显；无待办或仅查看已完成记录时不显示待办强调。展开逐条提醒，不再分 Pending／Overdue 入口。Grid／List 共用；右侧预约内容独立滚动，展开列表限制为容器的 55% 且最多 260px，可滚动、分页，不能遮挡预约首行。窄屏操作换行且可达；Reminder 不占预约时间格、不在每个医生列重复。

日期、数量与完成筛选： 按联系日期等于 Calendar 所选日期查询（2026-11-02 用户追加确认）；提醒只在设定的联系日展示，不因关联预约日期或尚未处理而复制到后续日期。例如预约在 5 号、联系日在 2 号，Reminder 仅在 2 号展示，预约仍在 5 号。未处理提醒保留原联系日，可切回该日查看或主动改期；保留每条原联系日期／可选时间，按日期、时间（仅日期在先）、稳定 ID 排序，不另分逾期组。默认勾选「Hide completed／隐藏已完成」，仅显示 Pending；取消勾选后在相同日期及责任范围内加入 Completed。计数来自同一服务端筛选，完成后默认减少、取消隐藏后重新计入，不把重叠分类相加。展示已完成时另以同日期／责任范围的待办数量决定强调色，并注明实际待跟进数量，不以当前页是否出现 Pending 推断全量待办。后台刷新保留上次成功数量，首次加载及失败显示未知而不伪装为 0。Cancelled 不加入日常展开列表；展开栏的次要「处理记录」入口查询 Completed／Cancelled，可调整日期范围及状态，保留恢复及审计，不增加 Pending／Overdue 分类。日期、诊所、医生范围改变后回到第一页并刷新，Appointment 状态不筛除 Reminder。加载显示占位，失败显示读取失败／重试，不能伪装为 0；没有待办仍显示入口及真实 0。

逐条处理： 每条提供查看、已提醒、稍后联系；操作进入同一详情弹窗并直接定位确认表单，成功后关闭返回原位列表并刷新数量。完成后显示紧凑且可关闭的「病人姓名 · 已记录联络」反馈，次要链接为「Reopen follow-up…／重新跟进…」，不再显示大尺寸 Restore reminder 按钮；提示可关闭，历史入口仍可重新跟进。重新跟进表单明确说明返回待跟进清单并保留原联络记录，继续要求有效日期，原因改为选填（2026-11-03 用户确认），保留审计，不静默恢复已过的联系时点。已完成记录取消隐藏后可查看详情。原来源入口及历史处理能力保持兼容。

每行展示患者、预约／检测／计划来源类型、联系日期／时间、项目或实际预约摘要、相关医生、负责人及状态；医生以明确「医生／Doctor」标签独立显示，创建弹窗及详情亦保留医生字段，不与负责护士混用。多数提醒沿来源真实医生归属；来源确无医生时显示「未指定医生，由诊所护理跟进」，不强造归属或因此隐藏合法护理项目。诊所／Zone 在跨范围时明确展示。提供「已提醒」「稍后再联系」「查看」；详情在同一弹窗内展开或进入可返回的详情层，显示联系方式、来源、目标日期、历史及取消／更正入口，避免多层弹窗堆叠。Calendar 与来源详情操作同一条记录；来源查看仍单独校验权限，不因能处理提醒而开放完整病历或检测报告。完成或改期成功后同步刷新行及固定栏计数，失败保留原记录及输入；另一护士已处理则提示并回读，不允许重复完成。

统一界面与交互： Calendar 原位列表采用舒展的两行摘要（2026-11-02 用户追加反馈）：每条约 68px 高，首行病人及 Calendar 同款类型 Tag，次行医生与诊所／区域；正文 12px、辅助文字 11px，上下留白 10px、两行间距 4px。类型从实际来源类别映射，Consultation、Vaccination 等沿用 Calendar 语义颜色；检测提醒按实际已保存服务分类显示与 Consultation 同层级的 Lab test／化验检查、Imaging test／影像检查 Tag；合并两类项目时并列显示两个 Tag，不依据项目名称猜测类型，旧记录仅在精确来源可核实时补充分类，无法核实显示 Test／检查，未预约针次显示 Vaccination 并保留计划说明，未知类型使用 Appointment，不强行归为问诊。普通预约不重复展示类型及医生的拼接摘要，检测／针次的具体项目继续保留。联系日期／可选时间及操作在右侧同排；没有指定联系时间时只显示日期，不显示「Date only／僅日期」占位文字，有具体时间时在日期下方显示时间。操作沿用 Calendar 的 28px 图标按钮、语义配色、悬停／键盘提示和可访问名称；长文字省略并可查看详情，窄窗日期及操作自然换行。独立提醒／历史弹窗使用统一卡片列表；详情按病人摘要 → 类型卡片内预约／联络日期、负责人、Nurse note → 当前操作组织，来源明细及处理记录按需展开。延期／取消／恢复／更正采用有标签表单与明确的取消编辑／确认；延期及恢复保留原可选联系时间，护士可修改或清空；实际预约选择器加载／提交时暂停分页，避免并发切页丢失结果；联系日期继续校验，原因／补充说明统一选填，加载／错误采用标准反馈。创建入口共用同一表单，按跟进项目、联络安排、负责人和备注分区；顶部姓名与医生左对齐，提醒类型标签右侧对齐；来源卡片的勾选、已预约标签／目标日期、医生各有独立行高与间距，不重叠。每张卡片提供提前 1／3／7 天快捷选择及带可见标签和「天／days」单位的自定义天数；即时展示换算后的实际联系日，不另设弹窗级套用按钮；日期／时间使用 Element Plus，快捷日期不隐藏最终联络日期。Cashier 手动提醒与病人上下文操作同组，读取候选有加载反馈；不存在可用候选时明确说明。权限、API、审计及原业务成功边界不变。

关闭弹窗后保留 Calendar 的所选日期、Grid／List、筛选及预约滚动位置；弹窗内翻页或查看其他提醒日期不改变底层预约日期。弹窗有明确关闭按钮、可见键盘焦点，关闭后焦点返回触发入口；存在未保存改期／备注时执行共享草稿保护。切换身份／诊所使数据、计数及迟到响应失效；不得将旧弹窗记录带入新身份操作。

栏位、计数、弹窗列表和动作沿用同一授权及明确筛选范围，不能把筛选后的零当作整个诊所没有积压。无医生的提醒有独立「诊所护理／未指定医生」分组，默认纳入有权护理范围；既有空医生筛选不得误清空这一分组，也不得扩大医生预约读取范围。弹窗查询失败显示失败及重试，不显示假空态。

复制消息、打开 WhatsApp／SMS／Email／WeChat、阅读提醒均不自动完成；消息能力沿用 §4.5 的真实发送边界。无实际预约的检测提醒不得把“联系日期”填进消息的预约日期变量，缺失资料仍按模板规则提示。消息发送集成及 Communication History 扩建不因本功能自动纳入。

4.7.5 来源变化、防重复与权限

• 预约改期／取消： 按预约前 N 天设置的 Pending 提醒随成功改期重新计算；若结果已过期，则置为今天待处理并显著提示核对，不写入已过的提醒时点。相对提醒落在今天但原联系时间已经过去时，改为今天仅日期待办并提示核对。人员明确选择的固定提醒日期不被覆盖，提示来源已改期并要求核对。预约取消时结束对应 Pending 提醒，标记 Cancelled／来源预约取消；已经完成的提醒保持历史。新关联预约保留来源链并重新去重，不能同时留下两条有效提醒。
• 未预约针次与实际预约关联： 每个计划项独立保留病人、责任单位、医生及来源链。作为背景的首针／父预约取消，不直接推断整个后续接种计划取消；需由有权护士取消对应跟进。后续实际预约保存后，可显式关联同患者、同责任单位、日期为今天或未来且状态为 Booked／Scheduled／Confirmed 的实际接种预约；已到诊、已进入执行或终态不可作为未预约计划的新关联；保留原计划和处理历史，同一预约不能再留下另一条有效重复提醒。关联后按实际预约的改期／取消规则执行，已完成记录不自动重新激活；明确的固定提醒日期仍不被默默覆盖。
• 检测变化： 项目取消／作废时取消其未完成提醒关联；合并提醒仅移除取消项目，其他有效项目仍待处理，全部取消才结束整条。退款或冲正本身不证明检测计划取消，保留提醒并显示来源变化供核对。创建后才收到实际检测完成状态时，标明已完成供护士决定无需跟进，不能伪造“护士已提醒”；未知状态不自动关闭。
• 患者身份更正： 预约换人或合并虚拟患者时，旧患者的未完成提醒取消并保留原患者／联系方式及审计；不得把原联系任务静默重绑到新患者。后续在最终患者的有效来源上重新建立。动作提交重查来源患者一致性，遗漏同步也不得记录错误患者已联系。
• 来源失效： 负责单位／医生变化或服务项目替换时重查责任及来源权限，不静默把记录转给无权团队；需要重新安排的记录保留可审计关联并供有权人员处理。已完成记录不随来源变化重写历史或自动重新激活。
• 防重复： 同一实际预约／未预约针次计划及提醒用途只保留一条有效提醒；检测按稳定服务项目／执行实例及提醒用途去重，不按项目名称或患者姓名去重。多个项目合并时逐项查重，允许不同真实执行实例分别提醒。重复点击、付款重试、多个入口及并发创建返回已有结果或提示冲突，不能产生重复 Pending。已有完成／取消记录须展示历史；再次提醒由人员明确发起并保留前后关联，不因补款自动新建。
• 权限： 创建、查看／处理和管理更正应分别可配置，沿用 Platform 的集团、有效岗位、Clinic／Center／Zone 及医生／护理服务关系限制。具有预约或收费权限不自动获得提醒权限；所有动作仅护理岗位可配置并执行，医生及其他非护理岗位在 UI 和 API 均被阻止，包括旧授权、命令结果查回及直接来源请求。第一版支持负责诊所内有相应权限的护士接手，不限定为创建人；指定负责人不扩大权限，也不阻止合资格同事轮班接手。
• 最小可见范围： 仅返回完成联系所需患者摘要、联系方式、来源项目和安排；隐私字段沿用已有独立权限。无医生项目依有效诊所护理资格判断，不通过虚拟 Provider 绕过权限。详情、搜索、计数、来源链接及写入使用同一当前授权；Assume／角色模拟沿用平台原规则，不额外获得执行权。
• 并发与审计： 每次写入重验来源、权限及当前版本，另一护士已处理时拒绝陈旧覆盖并刷新；失效身份及迟到响应不得回填旧上下文。创建、跳过提示、改期、联络、完成、取消、恢复及来源联动均可追溯人员、时间、原因／结果和前后值。提醒写入失败不影响原预约／财务事务。

旧 Appointment Alert 防重复： 当前旧 Alert 会生成 callback Task。新建的有权护理岗位预约统一由 Calendar Reminder 承担联系提醒，不再同时生成旧 Task；暂不创建 Reminder 也不暗中创建 Task，新表单不并列展示会被忽略的旧 Alert 设置。非护理岗位和历史预约继续原规则，不批量迁移。历史预约已有有效旧 Alert 时，先显示已有提醒及有权入口，不直接再建一条同用途 Pending；人员按原权限停用／结束旧 Alert 后才显式新建，保留原历史。单个历史预约在明确创建 Calendar Reminder 或被计划提醒关联后，标记为 Calendar 模式并隐藏被取代的旧 Alert 输入，后续编辑不重新生成重复 Task；不自动迁移其他历史记录。个人 Reminder 与 No Consultation 不变。

4.7.6 验收口径与实施边界

开发对象、来源稳定键、接口契约、权限、文件改动、P0–P7 工作包和本地验证步骤统一见 Reminder 开发方案。当前本地实现和测试结果以专项证据为准。

以下 REM 用例为验收条件；已执行子集及结果见专项证据，不将条件清单视为全部通过：

已有基础： 实际复诊预约、Cashier 付款安排、Calendar 消息模板和人工任务能力可作为衔接基础；不据此宣称本节已经实现。本地已实现，验证边界另记： 独立 Reminder 数据与权限、预约／Cashier 处理完成节点触发、快捷表单、日历固定栏与处理弹窗、逾期、来源联动、幂等并发和审计；未据此声明目标环境或 UAT 已通过。尚未定值／后续范围： 诊所统一默认提前天数、静默创建策略、自动发送与周期催办；不阻塞本期人员确认日期的一键创建设计。

5. Registration 与护理

功能目的： 把实际到诊患者完成必要准备后交给正确的医生或服务队列。

使用者与对象： 当前 Clinic 与负责医生有有效服务关系的护士；对象为同一 Appointment 关联的 Visit 及准备记录。前台无签到及护理执行权。

操作与结果： Check-in → Preparation → Ready；回退到相邻阶段保留同一 Visit、已填资料和原因。

关键边界： 准备未完成不交接；已经问诊的患者不从前台直接取消。

RG-01： 当日 Confirmed 进入 Awaiting check-in；未确认只留 Calendar。核对真实到诊后，写入一次关联 Visit、付款保障快照与到达记录。Check-in 读当前主档，仅回写员工实际修改字段，自动带值不能触发无意覆盖。双语姓名用于显示；未修改姓名时，查重、资料保存及签到均使用主档原始姓名，不能将拼接显示名当作身份变更。通用 Walk-in／Visit 创建同样要求真实且未合并身份和六项完整资料（含出生日期、性别）；新 Visit 仅可从 Registered／Arrived 开始，不能直接创建 Ready 或 In consultation 以跳过准备。资料更新须保留签到来源及查重结果，服务端保存前复核；并发身份或候选变化须重新确认。

签到界面（2026-10-15 确认）： 同一弹窗依次展示患者身份、本次预约摘要、付款安排及必要同意。资料齐全先显示摘要并提供 Edit details；缺项或虚拟患者直接展开姓名、主要电话、证件类型及号码、出生日期及性别的小表单，患者编号只读，带入已录资料。常规核对／更正不跳转 EMR、不要求手填原因；保存只提交实际修改字段，沿用维护资格、重复身份检查及版本冲突门禁。虚拟身份命中已有患者时就地明确选择，服务端复核候选；不能静默切换或覆盖已有患者资料。身份已保存而签到失败须分别显示结果，重试不得重复创建身份。所有现行签到入口（包括 Calendar 转入 Registration）均先完整核对姓名、主要电话、证件类型、证件号码、出生日期及性别六项；2026-10-16 确认出生日期和性别在签到时必填，取代此前四项签到口径。出生日期须有效且不晚于当天，性别须明确选择合法值；前端及服务端共同校验，未补齐不得创建 Visit 或继续到问诊。已有患者即使未编辑，也须在六项身份资料下方点击 Confirm identity and check duplicates 完成一次查重；确认按钮、查重结果／错误及每张候选卡片的 Use this patient 均位于患者身份区。底部固定显示 Cancel 和 Check in，身份未确认、查重失败或重复候选尚未处理时 Check in 禁用；使用已有患者只完成身份绑定，重新核对目标资料后才能签到，不要求先填写付款安排才能选择身份。匹配规则复用虚拟患者身份确认的规范化证件一致或姓名＋主电话同时一致；单电话一致不认定重复。查重失败不得按无匹配放行；身份或所选患者变化须重新检查。预约签到及通用 Visit 创建的服务端均必须收到与当前六项资料、候选集合相符的明确查重结果；无候选也须提交 no_matches，存在候选须明确保留为独立患者，不能因无重复候选而兼容省略身份确认。候选展示姓名、患者编号及证件／电话供核对，每张正式患者候选卡片提供 Use this patient。当前预约与候选均为 virtual 时，也提供该选项；服务端复核候选仍匹配且有效后，以本次核实的六项身份资料将所选候选确认并登记为正式患者，再将当前预约所绑定的虚拟档案逻辑合并至该患者，保留目标档案 ID 和其已有预约，并记录身份版本与审计。该选择仅绑定当前预约并完成身份解析，随后仍须重新核对目标资料及查重才可签到；不能把候选虚拟档案当作正式患者、保留为独立患者，或静默创建第二条正式患者记录。虚拟患者沿用现有身份解析；2026-10-16 确认，已绑定真实患者的预约也可快速选择正确的已有患者，但仅限当前 Clinic 内仍为 Confirmed、尚未存在任何 Visit（含已取消记录）、账单或后续临床活动的预约。只替换当前 Appointment 及其 Encounter 的患者关联，保留预约 ID、Encounter UUID 和 Chit；不合并或删除两份真实患者档案，不改其他预约／Visit，不自动赋予目标患者新的诊所资格。服务端复核当前患者、资料版本、候选集合、目标真实身份及当前权限，并记录更正审计；过期页面或新增活动须拒绝并重新读取。绑定后显示目标主档，缺失字段保持空白，不用原患者／草稿值补写目标；须重新核对六项资料及查重，底部 Check in 才创建 Visit。患者相关卡片、计划快照及人工审核清除并退回待确认；自费可保留。核对后仍可明确选择 Reviewed matches — keep this as a separate patient；服务端保存／签到前重新验证当前身份和候选集合，候选变化要求重新查重。成功后按当前权限提供下一步：可记录准备的角色显示 Continue to preparation；无准备权限的角色明确提示交给获授权前线同事，并以返回队列为主动作，不显示不可执行的继续按钮。不自动完成准备。未保存修改离开需提示。

接待队列操作（2026-10-23 确认）： 打印入口统一为 Print label 并使用打印机图标。Ready for consultation 保留可用的附件上传入口，补传不改变就诊状态；Return to preparation 改为紧凑图标按钮，保留完整悬浮说明、可访问名称及原返回流程。

统一 Nurse note（2026-10-26 用户确认）： 原预约／登记 Remark 与准备 Nurse note 合并为同一次预约／Visit 的一份「Nurse note／護理備註」。预约编辑与详情、登记／签到、准备、问诊队列与问诊患者摘要均可在各自已授权范围内读取同一内容；预约、登记及准备沿用各入口现有编辑权限与状态门禁，普通问诊摘要读取不新增编辑权；2026-10-28 用户另行确认 Consultation review 的 Nurse note 查看／填写入口，编辑边界唯一见 Consultation NR-10。准备后重开预约与登记可读回最新值；进入问诊后预约仍只读。旧 Remark 与 triage note 都有内容且不同时，按预约内容在前、护理内容在后的顺序换段保留，完全相同的内容只显示一次；只读访问不改写原始数据，首次保存时在同一事务统一存储，遗漏字段保留，明确清空才清空。仍保留兼容 API 字段，不要求破坏性数据库迁移。每次仅绑定该预约／Visit，不串到同患者其他就诊。主诉、患者长期备注、Allergy／ADR／Alert、状态变更及退回原因保持独立语义。并发保存时按打开时的 Nurse note／准备版本核对；发生冲突提示重新读取并保留草稿，不覆盖另一位用户的结果。多行内容保留换行，问诊摘要可滚动阅读完整内容。

准备与测量界面（2026-10-15 确认）： 顶部紧凑患者／就诊摘要，已完成付款安排可折叠；不重复展示左右两套准备清单。默认只展示血压、脉搏、体温、SpO₂、身高／体重五组常用测量，BMI 自动计算；其余测量统一经 Add measurement 按需加入，不再提供排序、拖动、逐卡折叠或 More measurements 配置。已有非常用输入仍可见且保留校验，不因简化界面丢失。2026-10-23 确认：仅在 Prepare 弹窗体征下直接展示 Allergy、ADR、Alert 三类患者安全资料及独立 Nurse note 输入，移除 Other preparation information 折叠区及其主诉／起病时间／用药输入；原已保存内容保留，隐藏字段不能被清空。Allergy 复用现有结构化／旧自由文字编辑器，ADR 与 Alert 独立记录；不自动推定确定程度、反应或严重度。三类资料沿用患者共用安全档案、角色权限、版本并发检查及审计，与本次准备保存处于同一事务；未经授权的角色仅可读。Nurse note 按下述统一交接契约保存，不用主诉代填。既有医生 pre-check 若已要求，保留完成核对入口及交接门禁；不新增 Required 开关。Check-in 弹窗不在本次变更范围。已知过敏及重要警示摘要保持可见。取消 Vitals Required／Completed 控件，按需输入并校验已填值；保存保持准备阶段，完成准备才推进正确医生／服务队列，其他身份／付款／pre-check 门禁继续保留。体征区提供 Skip vitals for now（空白时）／Hide vitals（已有输入或历史时）及 Show vitals，允许快速收起并恢复测量区；收起不清空草稿或历史、不保存、不自动改变 Visit 状态，显示未录入或已保存／未保存数量及完成准备指引。非法已填值时保持展开并标示具体修正说明，错误与对应输入建立无障碍关联；2026-10-23 的体征录入核对范围及确认规则见下表。切换患者／Visit 后恢复展开。底部 Complete preparation 仍是唯一交接提交，其他门禁不变。默认首次测量表保留；卡片“＋”或“新增测量项目”菜单每次只新增所选项目的空白输入，不批量新增整套测量。血压的收缩压／舒张压仍成组，身高／体重保留同组 BMI 联动；各次复测独立保存。测量项目增加 Others（其他），每笔填写自定义名称（必填、去除首尾空白、最多 80 字元）、有限数值及可选单位（最多 20 字元）；名称／单位不接受控制字元，按纯文字显示。数值允许负数、小数与零，限前后端可安全处理的数值范围，不套用标准测量项的临床范围；标准项采用下述录入核对范围。可重复添加多种自定义项目，各笔分别保存名称、数值、单位、操作者及时间，空白项目不创建观察记录，名称或数值填写不完整时拒绝整次提交。准备阶段与交接后 Vitals 使用同一追加、重试去重及权限规则；重新打开、问诊和患者历史均可读回。Others 不自动映射到标准体征趋势或计算 BMI，也不能覆盖／移除已有标准测量。历史记录按测量时间展示，不能自动当成本次观察。备注单独保存或未录入测量不得清空、覆盖或新增历史测量。

签到弹窗按打开时的任务固定成功反馈：新签到成功显示 Checked in；已有 Visit 的身份补录显示 Identity details updated。队列刷新或新 Visit 返回后不能把新签到误切换为身份补录。

可选测量与暂未测量（2026-11-05 用户确认）： 所有 Vitals 继续按需输入；全部为空默认 Not measured，不创建测量值、不按零处理、不单独阻断 Complete preparation。每个标准测量项目可主动选择 Not yet measured，默认不选；血压两值共用一个状态，身高与体重分别标记。该状态属于本次 Visit，保存真实操作者、时间及审计，保存／重新打开／问诊摘要可读回；问诊顶部按后续确认固定展示标准项目：主动选择的暂未测量显示 Not yet measured，无输入的默认状态显示中性灰色 Not measured；这不改变护士端可选填写规则。补入有效实际值时清除相应暂未测量状态，不影响其他项目；已有实际测量不能重新标成未测量，历史值不可删除或冒充本次输入。状态单独保存及交接后补录沿用当前权限、Visit 状态和并发核对，冲突不静默覆盖；已填值的类型／范围核对保持不变。准备页 Allergy／ADR／Alert 的颜色、直接「无」选项和互斥规则统一见 Consultation §2.5。

血压测量侧（2026-10-23 用户确认）： 每次血压测量旁提供左臂／右臂选项，选填且默认未记录。首次测量与每次复测分别保存测量侧；Prepare、准备后 Vitals 补录、重新打开与历史展示保持一致。未选择及旧记录保持未记录，不自动推断；只选测量侧而未输入血压不会新增测量记录。

体征录入范围核对（2026-10-23 用户附表及确认）： 以下为成人及儿童的录入核对范围，并非正常值或诊断／分诊标准。输入框允许保留原值，不静默截断、替换或丢弃。空白仍为未测量，不按零处理；整数类型、有限数值及数据库可存储范围继续有效。

首次测量、各次复测及交接后独立 Vitals 追加共用此规则。一般保存／Complete preparation 在超范围时先列出项目、数值、单位和范围，由护士选择返回修改或确认数值并保存；取消不写入且保留草稿。确认绑定每一笔测量的具体值，改值后重新确认，服务端再次验证并与真实操作者、录入时间一起留证；不能只传一个可重复使用的忽略提示标记。SpO₂ 特殊硬限制优先。保存中的权限、流程或患者安全版本冲突使整次准备写入回滚，不能先更新安全档案再留下失败的体征／交接。

准备保存与交接的一致性： Save changes 与 Complete preparation 分别使用服务端返回的当前流程能力；可打开或保存准备不等于可推进 Ready。无当前角色／服务范围权限时显示阻断原因，提交前复核，不先写体征再发现转换被拒绝。新准备命令把本次付款安排、准备记录／体征和目标状态作为同一次事务保存；身份、付款、状态或权限校验失败时全部回滚。已有独立身份更正的结果仍单独反馈。使用当前准备版本及同一请求键处理并发和重试，旧版本拒绝覆盖、重复命令不重复插入体征。获授权的 Center 前线／护士读取所属且当前获准操作的子诊所 Visit 时，返回当前准备版本、准备记录及体征；此操作资料不授予医生 Note／Rx 内容权限，其他 Center、已撤销 Zone 或停用子诊所不能据此取得准备操作资料，既有共享历史读取资格仍单独保留。尚未保存的准备明确返回版本 0；缺失或非法版本不能当作 0，前端显示重新打开 Prepare 的提示并禁用保存及完成。真实的准备版本冲突、已完成准备或患者安全资料版本冲突返回可区分的原因与请求标识，说明本次未保存并要求重新读取核对；界面保留草稿，不自动重试覆盖。响应不明时保留原内容及请求键，禁止切换患者、退回步骤、关闭或切换角色；通过读取命令标识或重试原请求核实，确定结果后才解除保护。原命令已经成功、Visit 又推进至后续状态时，显示当前真实状态，不能回退或再次重复保存。

准备操作者与时间： 新记录的作者由服务端取当前有效员工身份；模拟操作同时保留真实操作人及目标员工，不能由前端姓名或固定 Nurse 字样代替。服务端记录带时区的实际写入时间，界面按系统显示时区格式化；用户填写的测量时间与录入时间分开。旧无时区历史按既有香港本地时间口径读取，不做未经证实的批量八小时修正。预约审计时间同样尊重已带的时区偏移，纯日期不作时区转换。回退动作使用 Return to preparation／Return to check-in，明确改变业务阶段，不使用 Previous 暗示只是翻页。

个人测量排列： 仅拖动项目手柄排序，显示目标位置；血压两项作为一组、身高体重及自动 BMI 作为一组移动。数值跟随稳定字段身份，键盘录入顺序同步；提供键盘／前移后移、恢复默认及加入常用／收进更多的替代操作。浏览器按当前登录用户保存布局偏好，不含患者数据，不修改其他用户或临床记录；存储不可用时仅本次生效并说明。新增项目菜单沿用个人排列，单项复测只展示所选项目；保存记录继续按测量时间排列。

RG-02： Checked in → Preparation → Ready for consultation 必须逐步推进。患者须为真实且未合并身份，姓名、主要电话、证件类型及号码、出生日期、性别六项齐全，本次付款安排已明确；选择计划时本次资格核验和有效期准备完成；Vitals 按需填写，全部为空也不单独阻断交接；已输入数值必须有效。已要求的 Doctor pre-check 必须完成，后端在交接至 Ready 及开始问诊时复核；不单凭前端按钮状态放行。页面自动读取核验结果，不新增几套重复“已核验”勾选。

交接后补录体征（2026-10-17 用户确认，I-060）： Reception 在 Ready for consultation／In consultation 行提供独立 Vitals 按钮。具有当前诊所／区域及负责医生服务关系和护理写入权限的护士，可查看已存测量并追加本次体征，无需将 Visit 退回 Preparation。保存仅新增测量；不修改准备核验、主诉、过敏、用药、医生记录、首次签到时间、队列顺序或就诊状态。已存测量只读；同一提交重试不重复插入。可选填写实际测量时间，另由服务端记录真实录入时间及认证操作者；迟录不得冒充较早录入。服务端保存时重新检查权限和就诊状态，医生已完成问诊或转入收费后拒绝追加；完成／历史就诊保持唯读。

5.1 Reception / Registration queue 展示契约

已签到旧记录的资料补齐（2026-10-17）： 原有 Visit 如缺少当前六项身份资料，保留已记录的到诊状态及首次到诊时间，队列额外显示 Identity details incomplete／身份資料待補齊。Checked in／Preparation 阶段主动作改为 Complete identity／補齊身份資料，打开明确标为补资料的界面；须补齐六项资料并重新查重，Save identity 才可提交。成功更新同一患者和 Visit，继续准备，不重复签到、创建 Visit 或重写首次到诊时间；失败不得显示成功。问诊／结算阶段不借此入口绕过原有修改权限或回退流程。同意书状态明确显示 Consent not checked／Consent pending／Consent received，不能使用无对象的 Not Checked 代替身份确认状态。

状态筛选按流程顺序展示 Awaiting check-in → Checked in → Preparation → Ready for consultation → In consultation → Ready for cashier → Checkout Completed；All today 独立显示总览数量。宽窗口使用约 44px 高的紧凑状态／数量条，标签与数量同行，相邻阶段用短箭头表达流转顺序；All today 与流程阶段分开，不使用高卡片。箭头表达流程关系，不表示某位病人已完成前序阶段。选中阶段使用统一主色及选中标记，点击同一阶段回到 All today；所有窗口宽度始终显示 All today 与七个流程状态及数量；宽度不足时按阅读顺序换为两行，极窄窗口继续换行。保留短箭头与键盘筛选，不改成下拉隐藏状态，也不靠横向滚动查找阶段。搜索／医生／日期及动作保持紧凑；Refresh 与 Add appointment 相邻成组，新增预约不再单独占用标题行；窄窗口筛选采用两列，极窄窗口采用单列，但这两个动作保持同组。搜索输入按 Enter 或点击 Refresh 应用当前筛选；清除搜索同时恢复当前其他筛选下的结果，不能只清空文字而继续显示旧搜索结果。搜索、医生与日期的草稿筛选尚未套用时显示明确提示及当前结果日期，按钮显示 Apply filters；Enter 或点击后才套用。历史日期队列使用 All patients 及实际结果日期，不显示 Today；标题随已请求的日期而非尚未套用的输入变化。此展示不改变队列范围、分支或状态转换。

患者行编号在预约、签到成功、到诊队列和刷新后均按真实身份状态展示：虚拟患者显示“Virtual patient · identity pending”，即使历史上曾提前分配 PN，也不显示为已完成正式登记。真实患者优先显示当前诊所已记录 PN，其次已记录旧 PN；无 PN 但有实际 MRN 时显示明确标记的 MRN，不笼统显示“患者编号待定”；两者均缺失才显示“未有患者编号记录”。接口已返回的 PN 不得因仍保留 VPN 快照而丢失，不把 MRN／VPN 字符改写为 PN，也不借用其他诊所的新 PN。预约身份确认、签到核对及护理准备摘要采用同一编号规则；如另示全局 VPN，须明确标为 Virtus Patient No.，不将其标作诊所 Patient No.。已加载主档明确缺少当前诊所 PN 时，不借用旧行快照或其他诊所关联的 PN。读取页面不批量补号或改写历史身份。患者行不显示电话号码；搜索及获授权资料编辑继续保留联系方式。

点击患者进入档案（2026-10-19／2026-10-28 确认）： Reception 及 Appointment Calendar 的 List／Day／Week 姓名入口中已保存的真实或虚拟患者均可按权限点击姓名进入 Patient & eMR。Calendar 点击姓名只打开对应 Patient & eMR，不同时打开预约编辑器；点击其余预约内容仍沿用原预约操作。以该行 Patient ID 与 Appointment ID 发起统一患者上下文切换，沿用未保存修改保护；缺少已保存患者或无 eMR 入口权限时姓名不提供可执行跳转。此修改仅限 Calendar 展示入口，不扩展预约表单。只有预约而尚未签到时，服务端校验当前预约与患者的真实关联，不要求已有 Visit，也不自动选择该患者最近一次 Visit；已失效、越权或换绑的旧链接明确显示错误。虚拟患者有当前可访问、与该患者／预约相符的已提交未确认扫码资料时，直接进入对应审核界面，保留核实身份、通过、退回澄清等既有权限；若有多份则显示对应待审列表，不猜选另一患者或另一预约的资料。未扫码、只发出二维码但未提交时，进入患者档案维护；有当前诊所可管理的 Booked／Confirmed 预约且具患者维护权限的工作人员，可补全该虚拟身份，无需先伪造注册来源或 Visit。仅保存部分资料仍保持虚拟；补齐并通过现有身份、查重和版本校验后转为正式身份并分配 PN。此例外不扩大正式患者主档或临床历史权限。读取提交资料失败须明确显示并提供重试，不能当作“没有提交”。审核通过后返回实际确认的患者档案，刷新编号和队列；换绑须沿用原 Appointment ID、Encounter UUID 和 Chit，不能重新生成一次诊症。

患者标签（2026-10-23 确认）： 各标签打印入口、悬浮提示和无障碍名称统一使用 Print label，不再显示 Print tag／Print patient tag；FU 专用入口使用 Print FU label。Calendar、Registration、药品、标本和 FU 标签均包含患者电话，保留已有区号，未知时显示 Not recorded，不推断或拼造号码。各自原有身份、预约、处方、标本及业务字段继续保留；不改变打印权限、状态门禁或把打印预览视为实际出纸。一般患者／预约标签保持 90×45 mm，正常长度内容不因新增电话溢出；长姓名／内容允许换行，不截掉临床或身份信息。FU 入口及有效预约来源规则见 Cashier。

列表布局（2026-10-16 确认）： 付款方式不单独占列，仍在签到／准备内核对。准备进度并入 Status，仅在 Checked in／Preparation 展示真实必需核对项；空白体征不计为未完成，医生指定检查未完成时保留文字提示。保留患者姓名／编号、预约及到达时间、医生／服务、Zone、状态原因与可用动作。标题、结果数和筛选区不重复占用大段说明空间，内容高度优先留给 Visit。普通行保留约 72px 基础高度与适当留白，长姓名、风险和阻断信息按需增加高度。宽窗口 Patient 约占列表四分之一：第一行姓名，第二行编号与必要标识；预约时段集中在 Time，已记录的实际到诊时间另加明确标签，不在 Patient 重复时间或服务类型。时间／来源与就诊单号、医生与服务类型／Zone 按信息层级组织。Consultation Type 以完整文字标签展示，沿用 Calendar 的类型颜色，颜色不替代文字或改变就诊路径。Check in／Prepare／回退或 Open Cashier、打印标签、可用的修改／调整及附件使用紧凑行内按钮，按原状态及权限条件显示；常规桌面宽度下操作横排，按钮约 28px 高。主动作、打印标签与修改／调整保留文字和有意义图标；相邻回退与附件入口可采用直接可见的图标按钮，必须有完整无障碍名称、hover／focus 提示及键盘焦点。保留原有主次视觉层级，不将全部常用操作收进菜单，也不为减少行高压缩到难以阅读。按 App 实际宽度重排：宽窗口分列，中等窗口将时间及医生资料并入患者栏，窄窗口同一患者行内分组显示状态与操作；保持全部动作可达，避免队列横向滚动。Order 列及前移／后移按钮在宽、窄窗口均独立可见，不收进 More；原排序、禁用条件、权限与状态规则不变。

展示范围（2026-09-17 用户确认）：当天所有尚未结束的 Visit 都在 Reception 展示，已经进入 Consultation 或 Cashier 也继续展示。 Reception 同时承担当日到诊总览；“不再需要护士准备”不等于“这次 Visit 已结束”。默认 All visits 不能只显示 Checked in／Preparation／Ready；状态筛选是可选缩小范围，不能作为默认隐藏下游患者的理由。

“当天”按 Visit 的业务就诊日期与当前诊所时区判断，不按最后修改日期、预约改期后的日期或客户端时钟。范围先受当前 Clinic 和操作者有效 Provider 服务关系限制；“所有”不扩大授权。未识别的非终态不能直接静默丢弃，显示原状态与需核对提示，写入动作仍须有明确状态规则。

默认 Visit 列表中所有未结束阶段一起按签到时间升序；状态用列／标识表达，不因 In consultation／Cashier 而强制排到末尾。可另看“需要准备”筛选，但总览数量仍明确标为当天未结束 Visit 总数。列表至少显示 Patient name／Patient No.、Visit No.、Provider、Consultation Type、预约时间（如有）、签到时间、当前阶段及可用动作／阻断原因；日期、缺医生和缺时间不得用猜测值填补。

RG-03 签到先后顺序（2026-09-17 用户确认）： 已签到患者的 Visit 按**服务端首次成功签到时间从早到晚（升序）**展示，先签到的在前。这里的签到时间对应可信的 arrival_time，不是预约时段、患者档案创建时间、Visit 编号、最近修改时间或进入 Preparation／Ready 的时间。界面至少能区分预约时间与签到时间；显示到分钟不代表排序可以丢弃秒及更高精度。列表展示顺序不等于自动叫号或医疗优先级。

日期按当前诊所业务时区解释；Reception 的当日范围不扩大为全部历史。跨日未结束的 Visit 不等于已完成，也不得自动重新签到；其独立 Carry-over 展示方式仍待业务确定，医生／Cashier／Pharmacy／Lab 各自保留已定义的跨日任务范围。护士可见范围仍由当前 Clinic、Provider 服务关系和动作权限决定，All doctors 只表示本人获授权集合。

验证边界： 本节补齐产品要求，不宣称代码已符合。已发现当前前端混用预约／签到展示时间、排序丢失秒、本地手动顺序覆盖和非稳定 ID 兜底等差距；追踪于交付说明，目标验收见 QUEUE-01～12。

RG-04 阶段交接： 护士成功后留在 Registration；Visit 同时出现在正确队列。No Consultation 到护士／服务队列，其余医生参与类型目标进入医生队列。Ready → Preparation 需原因且从医生队列移除；Preparation → Checked in 保留同一 Visit 和已录资料。

Walk-in 无预先预约也必须建立可追踪 Visit，来源标清。具体是否强制先建即时 Appointment 仍需确认，不能允许后续临床记录没有 Visit。

5.2 Consultation review 入口

2026-10-27 用户确认；本地实现与专项验证见 Consultation §5.1，不代表 STG／UAT。 Registration Queue 为 In Consultation 及临床已完成、尚在收费／执行流程中的 Consultation Completed 行提供 Consultation review／问诊查阅与服务。使用明确 Visit 打开标准浮动窗口并保留原筛选／队列位置；窗口支持拖动、缩放和与其他页面并行操作，具体布局／草稿规则统一见 Consultation NR-10，不跳转完整 Consultation Page，不触发首次 Start、临床完成或重新打开问诊。Preparation／Ready、Checkout Completed／Closed、取消和迁移历史不由此取得服务编辑资格。

2026-10-29 确认符合既有退回资格的 Ready for Cashier 行提供 Return to Consultation，复用 Cashier 正式退回与原因／版本／财务和发药校验；退回不授予编辑权，不开放已结算项目。队列各状态中的返回上一阶段和 Print label 采用与附件入口一致的紧凑图标按钮，返回提示注明目标阶段；保留键盘操作、可访问名称及悬停／焦点提示。

2026-10-28 确认移除操作栏的 No registration action 占位文字；只显示当前可用动作，保留 Check in／Prepare／Open Cashier 的原状态与权限条件。

完整功能、表格字段、只读 Note／Prescription、医生编辑占用、Note 保存前提及护士 Edit 审核／Sign 发布 Service 的唯一规则在 Consultation §5.1。本入口只维护 Consultation，不改变其他业务流程及流转关系；与既有附件、Vitals、Cashier 动作并存；查看／编辑能力由服务端按来源 Clinic、有效岗位／医生服务关系、Visit 和项目状态分别返回，不能仅凭按钮或行状态决定。医生在写 Note 时提示“医生还在编辑 Consultation Note，请等待医生保存后再处理”；未保存／锁定不妨碍在权限内查看上次已保存的资料。

前台接待角色不因看得到队列自动获得护理 Service 编辑权。Closed 后继续需要收费或更正的情况沿用历史／财务流程，不通过本入口绕过终态。界面布局见初版布局原型，实施顺序见实现计划；原型仅作初版布局来源，AI 交互以 Consultation NR-09 当前规则及本地运行证据为准。

5.3 无医生 Vaccination 的准备与收费交接

Vaccination 沿用真实 Appointment、Check-in、Preparation 和同一 Visit／Chit。服务路径由服务器按已保存预约是否绑定医生派生：有医生为医生评估路径，无医生为仅接种；界面展示该结果，不能靠选择 path、修改 metadata 或伪造普通 Visit 类型获得护士权限。护士须在当前有效诊所岗位及 clinic 范围护理服务关系内操作，具体来源、动作及记录校验统一见 Consultation §7.4。

仅接种的 Prepare 区域选择本次权威疫苗目录中的有效疫苗及数量；身份、安全资料、付款安排、体征有效性和其他准备门禁继续执行。Complete and hand to Cashier／完成並交予收費 在准备成功后打开本次接种问诊，保存疫苗收费来源，再按服务器返回的当前版本完成。准备已成功而收费交接失败时保留当前 Visit 和修正／重试入口；Ready 状态不能使尚未完成的交接按钮消失。完成结果未知的重试规则沿用 Consultation §7.4，不重复准备、保存疫苗或生成收费。

护士可在现有 Consultation 中按限定权限填写本人 Vaccination Note，Note 为可选，不要求补写医生 SOAP 才能交予收费。成功交接进入 Ready for Cashier，实际付款、供药及接种执行继续由相应流程记录；本动作不自动登记已接种，也不开放普通问诊、Service、附件或临床文档权限。医生评估路径保留现有医生队列与签署流程。

Reception／Preparation 的 Patient packages 快捷入口读取同一患者账户，并可保存本次服务使用提议；浏览或提议不直接扣次数。后续预约绑定具体权益及有容量的服务时段，批量结果逐行报告；普通 Calendar 预约不再提供额外的资源勾选入口，无绑定时按普通预约保存；编辑已有时段绑定时继续核对并与套餐预约共用容量；资源候选来自配置，不按名称猜测，也不将未配置范围扩成全院排程；取消／改期同步释放或迁移合法预留，已签到、结算、供药或执行的不自动取消。仅收款 Visit 不进入临床准备／到诊队列。套餐定义及查询见 Catalogue §7.1，结算／退款见 Cashier；独立实施与本地证据见套餐方案，不因单一入口可用推定全部 UAT 完成。

6. 测试入口与已知缺口

PT、AP、RG 用例检验正常流程、重复患者、跨诊所关系、取消／回退及幂等。尚未完成完整交付的能力按交付状态记录；不能因页面可以点过就记 Pass。