组织、权限、平台与 AI 产品方案

患者标签 V1 的目录、各岗位维护／读取矩阵及最小页面投影统一见 Frontoffice §2.7（2026-11-02 已追加护士全部人工标签维护、默认协助分类、管理员独立目录管理及患者标签搜索；本地实现与逐项验证边界见该节）；标签权限不替代本篇患者来源、有效岗位和财务明细权限；2026-11-03 已确认 Lab／Drug Dispensing 在原获授权单据来源范围内展示全部标签及财务状态，状态投影与账单／金额权限的边界由 Frontoffice §2.7 统一维护。

患者标签既有角色兼容：既有护理角色运行时补齐此前未配置的标签读取／人工维护默认动作，医生等岗位仅补齐其 canonical 默认读取动作；明确角色拒绝、已发布策略规则和停用权限仍优先，不因补齐默认值扩大患者来源可见范围。

更新：2026-11-11 · 责任：权限与平台为 WS6／WS7，覆盖 Line A–D；AI 与集成为 Line D

本方案说明集团内各类人员如何使用患者资料，以及管理员如何配置岗位、权限和审批。阅读时可以先了解数据归属和人员分工，再查看具体资料的访问规则，最后了解配置、授权和审计流程。

正文描述产品要求。尚待决定的规则集中见第 11 节；当前交付状态和实际验证分别见交付状态与测试证据。

1. 功能地图与阅读顺序

阅读权限部分时，先看第 2 节的人员和数据关系，再看第 3 节的访问规则。需要配置账号或处理授权申请时，分别进入第 4、5 节。

角色决定业务动作，诊所任职与当时有效的 Doctor Group 分配决定护士可处理哪些问诊；保密内容另查批准。2026-11-11 用户确认的工作范围模型取代护士与医生服务关系及普通问诊 Read／Edit／Sign 分级授权，规则见 §3.1、§4.4 和 §5。当前代码仍有旧路径，设计更新不代表已部署。

2. 集团、人员、患者与记录的关系

2.1 组织与人员：岗位连接人和工作单位

flowchart TD
  G[Medical Group 集团] --> C[Licensed Center 持牌中心]
  C --> Z[Doctor Group 原 Zone]
  Z --> Q[Rooms and Equipment 房間與設備]
  G --> E[未轉換的 standalone Clinic]
  G --> O[Back Office 后台]
  G --> W[WDL / Central Pharmacy]
  U[User 同一真实员工] --> M[Membership 岗位：主体、有效期]
  C --> M
  O --> M
  W --> M
  M --> R[Role 每个岗位的业务角色]
  R --> M
  U --> P[Provider 稳定医生身份]
  P --> D[该医生在某 Clinic 的有效关系]
  C --> D
  M --> N[护士在某 Clinic 的有效岗位]
  N --> S[Clinic Manager 维护默认分配和排班]
  Z --> S
  S --> A[有效工作范围内普通问诊操作和签署]
  A --> B[保密内容仍需独立批准]

集团下可以有诊所、后台和中央药房等工作单位。员工通过岗位与工作单位建立关系。同一账号可在一个或多个单位获配不同角色，每次会话只选一个有效岗位。

用户通过全局 Context Selector 切换本人有效的 Clinic／业务主体。除 Appointment Calendar 明确允许的受控日程汇总外，各 App、Tab、列表、详情与动作只使用当前主体。切换先按 §4.7 处理未保存工作、进行中写入及结果未明的提交；取消时保留原主体与工作。获准切换后，服务端重新计算 auth context 与 ui_access，页面清除旧患者、队列、历史、角标和已确认放弃的草稿，并取消旧读取；迟到响应不得写回新主体。列表、详情和动作接口均再次校验主体与对象授权，缺少主体或权限投影时默认拒绝。

医生在不同诊所出诊时沿用同一个 Provider 身份，并在各诊所归属相应 Doctor Group。诊所必须先配置并管理 Group 和组内医生。护士注册只绑定诊所，具体 Doctor Group 由 Clinic Manager 通过独立界面的默认配置和排班调整；不再维护护士与单个医生的权限关系。跨诊所日历与问诊操作分别判断。原 Zone 转为 Doctor Group，作为诊所下的子 Unit；房间、设备和历史位置归属统一由 Clinic 承接。组织主档、医生固定归组与护士排班分别按 §4.4 的唯一入口配置，具体迁移和现有实现差距见工程方案。

持牌 Center 与 Doctor Group

组织与位置关系（2026-11-11 已确认）： Clinic／Centre 是第一层 Unit，原 Zone 转为下属 Doctor Group。Doctor Group 表示医生固定归属及护士工作分组，不再承载房间、设备或历史位置关系。房间、设备、预约地点、位置展示及 CDU 归 Clinic／Centre；组织页统一维护诊所与其 Doctor Group。持牌 Centre 的牌照、正式名称、地址核验及既有诊所 ID 保留。

Clinic／Centre
├─ Doctor Group（原 Zone）→ 医生固定归组、护士默认／排班
├─ Rooms & Equipment → 诊所级预约资源
└─ CDU → 诊所级库存与患者售价

医生、护士与 Pharmacy 在 Clinic／Centre 持有有效 Membership，各岗位独立计算动作权限，Provider 身份保持稳定。医生在账号的每条诊所任职配置固定 Doctor Group；护士任职只绑定诊所，实际 Group 从经理默认配置／排班解析。Group 不是另一处登录诊所或预约地点。医生归组不自动开放其他医生的问诊；非护理岗位既有临床对象、动作和批准边界不因本轮结构调整放宽。

迁移期间的既有范围： 现有 Center／Zone 数据和部分接口仍按旧位置模型实现；原 Membership Zone 限制及批次矩阵不能被当作新护士排班。旧配置应按明确来源映射至目标模型，不能把未配置／空分组自动解释为全部组。非护理岗位原有范围在接入新来源前继续约束其业务，页面筛选只缩小授权。患者主档及共用个人资料仍属医疗集团范围，按原角色动作和集团来源处理；能查看患者不代表能访问其全部问诊。修改配置保留岗位与审计历史，并使受影响的会话及缓存重新授权。

CDU 角色范围（沿用 2026-10-26 确认）： Pharmacy Staff／既有 Pharmacy 任职只配置至 Clinic／Centre，覆盖整间诊所；不建立 Doctor Group 任职或部分 Group 库存池。医生组与护士组共用所属 Clinic 的 CDU。CDU 不提供 Group 范围切换；本轮不改变库存计量、批次、成本、采购或患者售价算法，也不增加药房人员的临床资料权限。完整规则见 Drug。

业务来源： 新预约、Walk-in、Visit 的地点和资源归 Clinic；Doctor Group 作为独立的护理工作来源保存，预约转 Visit 时继承已确认的组，不能根据医生今天的归组改写历史来源。旧 Zone 的位置关联迁到所属 Clinic，历史查询、打印和汇总按 Clinic 解析；迁移保留原始标识、冻结单据及审计证据，不因显示层归并而改写已签内容、已过账金额或库存流水事实。当前实施是否已完成见 §11.2，迁移步骤见护士工作范围工程方案。

以下为既有 Center／Zone 迁移的来源对照，保留作本轮核验依据： 首批只轉換以下 13 個現有 ID，另建立四個 Center。原 ID、代碼及 MyPlatform UUID 保留為 Zone／來源身份；其他診所透過相容解析維持現行流程。

上表名称是营运标签。正式持牌名称、牌照号码及处所地址仍须在正式环境核对；2026-10-03 Samuel 批准的 UAT 测试资料只用于明确的 UAT／隔离数据库，不表示正式核实。原 Unit ID、代码及 MyPlatform UUID 与历史对应关系保留供迁移核验，不按同名重建实体。每个 Doctor Group 只属于同集团的一间 Clinic／Centre，有业务引用后不开放随意跨诊所移动。重复同角色期间的既有交集、未完整采购关系停用等约束仍须在迁移时核验。身份／诊所／工作组变化沿用 Context Transition 的缓存及草稿保护。

既有迁移历史见 Center／Zone 执行手册，本轮目标及兼容改造以护士工作范围工程方案为准。本地实施、开发分支发布、STG／UAT 与业务验收分别记录，不以建立 Unit 资料代表已完成迁移。

多角色任职与独立职位（2026-10-02 用户确认）

一个账号可有多个有效角色，并分别绑定一个或多个工作单位。同一单位允许不同角色，禁止重复的「用户＋单位＋角色」有效任职。登录及切换时只选择一个岗位，权限与工作场景来自该岗位，不取其他岗位的权限并集。本次决定取代 2026-09-10 的账号唯一角色规则。Title 是独立自由文本职位，不授予权限、工作场景或专业资格；新建及编辑人员资料必填，既有空值不阻止登录。

配置示例： 给 User 授权时，Operating unit 一样而 Role 不一样，可以建立不同的合法岗位。同一个用户在诊所 A 是医生、在诊所 B 是护士，也可分别配置，但各岗位必须满足对应主体、专业身份、服务关系及动作授权要求；当前登录只使用所选岗位，不把医生与护士的权限合并。添加第二岗位不替换第一岗位，也不重复创建同一「用户＋单位＋角色」任职。

Cashier 是业务功能，不单独设置角色。Reception 合并为 Frontline Staff，现场接待、准备、授权临床支持及 checkout 受指定站点范围限制。临床支持按当前问诊授权模式核验专业身份、服务关系与具体医生授权；Frontline Staff 的可逆临时模式见本节角色矩阵。后台人员按本节角色矩阵工作。

统一护理角色（2026-11-09 用户确认）： Nurse 与 Frontline Staff 统一为 Frontline Staff；frontline-staff 为有效角色代码，旧 nurse 仅作兼容身份，不再提供独立新分配。历史任职、护理关系、授权及审计 ID 保留，不自动恢复已停用角色或失效任职；会话、角色目录与权限计算按同一护理身份处理，原有显式权限拒绝继续生效，不把不同任职权限取并集。旧护理服务关系保留迁移与审计用途；新模型按 §3.1 的 Clinic／Doctor Group 判断普通工作范围。当前诊所真实预约的 Reminder 沿用预约资格，唯一规则见 Frontoffice §4.7。

Staff／External 只是人员分类，不是业务角色。管理员测试功能使用审计的 Assume Role；正常多角色任职使用明确的角色及单位切换。系统仅开放明确授予的权限，未写明允许的操作不自动放行。

CP Staff 可以保留本人角色，在获授权诊所代办采购；采购授权不包含患者发药，也不需要增配 Clinic Pharmacy 角色。详细规则见 CP 采购代办。这项能力仍需按 CP PRD 的实施状态判断。

2.2 患者与病历：同一人，多次就诊，多份来源记录

flowchart TD
  P[Patient 同集团共享患者主档] --> A[Appointment 某次预约]
  P --> V[Encounter / Visit 某次就诊]
  A -.到诊关联.-> V
  C[来源 Clinic] --> V
  D[负责 Provider：适用时明确] --> V
  V --> N[Consultation Notes 保密正文]
  V --> DX[Diagnosis 公共诊断]
  V --> A2[Action 公共行动计划]
  V --> RX[Prescription 处方]
  V --> X[生命体征、服务、检查及附件]
  P --> S[公共医疗摘要与历史索引]
  DX -.公共诊断索引.-> S
  RX -.生成有限摘要.-> S
  P --> L[患者关联多个 Clinic]
  F[首次建档来源和有效历史 Visit] --> L

患者主档由集团共享。同一位患者可以在多家诊所就诊，也可以由不同医生接诊；每次就诊记录分别保留来源诊所、负责医生、实际作者和版本。

因此，找到一位患者，并不意味着可以读取其全部病历。系统根据正在查看的资料类别，分别判断是否允许访问。

本文把患者资料分为基础信息、公共医疗资料、保密 Consultation Notes、处方和附件。一次就诊（Visit／Encounter）关联这些记录，但不把它们捆绑为同一读取权限。敏感身份字段及财务动作继续按原有专门权限处理。

3. 查看与编辑权限如何匹配

权限设计围绕三件事展开：集团共享患者基础资料，医生负责问诊记录，护士和药房按照各自职责处理本次就诊。共享到什么程度、谁可以修改，需要分别说明。

护士权限模型（2026-11-11 已确认）： 普通问诊操作与保密内容访问分开。护士在当前有效诊所／Doctor Group 范围内可读取普通内容、修改、保存并完成签署，不再先关联医生或申请 Read／Edit／Sign。保密内容按 §5 单独授权。护士可提交对象申请，负责医生也可把本人的保密 Note 共享给当前 Doctor Group 的当值护士。

申请仍保留目标对象、用途、期限和审计。未批准时不返回保密正文，锁定内容不视为空值；未获批准的护士仍可完成整次问诊，保密内容由服务端原样保留。完整完成规则见 Consultation §2.4。

通用规则（AC-02）： 有效账号、岗位、动作、资料范围、时效、记录状态及适用患者同意继续校验。患者主档的集团共享、独立敏感字段、药房及 Lab 执行权限分别保留。普通问诊签署能力不开放保密正文，也不授予用户、角色、目录或财务管理权限。

父级单位与子单位： 具有父级 Center 相应操作和全部子范围的有效岗位覆盖其所属分组／Site；只分配指定子集时仍限该子集。All sites 或视图筛选不能扩大授权。记录、附件及审计保留原来源；已完成 Visit 的附件补传及历史保护继续按 Consultation §8.2。护理具体分组以 §4.4 的有效分配为准。

3.1 医生、护士的日程与问诊记录范围

工作区范围与切换（2026-11-13 修正）： 业务页面统一显示 Clinic／Centre 和只读的当前 Doctor Group，不再提供 Site／All sites／Zone 选择器。Doctor Group 是医生归属与护理工作分配，不是地点。新增组织单位不再创建旧 Zone；旧地点在管理页保留迁移状态及原始关系，不能通过改名或更改结构直接转换为 Group。只有同一集团、同一角色有多个有效 Clinic 任职时才显示诊所选择器；单诊所显示名称，模拟身份不混入操作者自己的任职。护士不提供 All Clinics 合并视图；其他适用角色的合并视图也只包括本角色有效诊所。切换前检查未保存工作，切换失败或取消时保留原范围；成功后清除旧跨诊所视图和旧工作区数据。Clinic Manager 的护士默认组／排班配置入口在权限模型启用前即可准备配置，仍只允许管理本人有效诊所；准备配置不等于目标环境已启用新权限模型。入口统一命名为 Nurse Groups & Shifts（護士分組與排班）；经理逐行选择护士默认 Doctor Group 后自动保存，限时变更在同页使用临时排班。没有有效组别时明确提示联系组织管理员为本诊所建立 Doctor Group，不指引经理进入其无权访问的组织配置页面。

已确认目标（2026-11-11）： Doctor Group 需在诊所下事先配置和管理，医生归属于 Group；护士与医生通过 Group 建立工作关联。用户注册只将护士绑定到诊所；Clinic Manager 在独立界面维护护士的默认 Group 和排班。Group 主档在 Organization → Units 维护，医生的固定归组在医生账号的诊所任职维护。当前有效工作范围决定护士普通问诊的读取、编辑、保存及完成签署，不再检查护士与该负责医生的服务关系。

跨诊所日历（2026-11-13 用户澄清）： 护士仅能查看当前有效 Doctor Group 内医生在其他诊所的忙闲，不能扩展为本诊所全部医生或所有诊所全部医生。未分组、休班或组别失效时不返回跨诊所忙闲。外诊所仅返回医生、Clinic 地点、时间和忙闲，不返回患者信息、问诊内容或可直接进入问诊的业务对象；同一医生跨诊所出诊不授予处理外诊所业务的权限。前台日历呈现见 Frontoffice §4。

问诊范围： 必须匹配记录实际所属诊所和 Doctor Group。同诊所未分配分组、外诊所记录、旧链接和直接接口均不能通过医生同一或患者同一绕过。患者主档与既有独立共享摘要保持各自规则；其读取不能充当具体问诊的操作依据。历史来源缺失、无分组 standalone 单位和同诊所未授权分组的日历投影仍需按 §11 确定映射及边界。

保密内容： 护士需同时满足当前工作范围与 §5 的保密内容授权。Note 可使用对象审批或负责医生的组级共享；保密附件查阅仍使用对象审批。离开诊所或分组工作范围时，系统收回相应问诊访问。

医生规则： 医生继续按稳定 Provider、当前有效任职及原有负责／获批记录范围操作；本次护士规则不扩大医生的临床职责、患者自助确认或签署范围。切换账号、岗位、诊所及排班范围变化时重新授权并清理失去权限的内容，迟到响应不得恢复旧资料。

3.2 数据类别 × 查看 × 编辑

下表用于快速比较各类资料。具体申请方式和例外见后续小节。

问诊资料公共／保密边界（2026-10-26 用户确认，分阶段实施）： 沿用现有身份、岗位、单位、服务关系及授权流程，只调整资料结构与可见范围。“公共”指原有系统公共资料访问范围内可见，不是互联网公开，也不自动授予修改、执行或签署权。

2026-10-28 实施边界： 字段拆分轮次及 dev/sai 合并带入了保密投影／附件保护；用户随后批准公共字段独立读取与编辑、两个 Consultation 入口及 Read／Edit／Sign 的联动优化。新增联动已完成本地实现与受影响完整服务链验证，实际覆盖及旧回归限制见本轮验证；合并带入的附件能力不由本专项推定已穷举验收；详见 Consultation。

• Diagnosis、Action 为独立、必须保留的公共板块，不再受 Consultation Notes 的查看锁限制；个人模板不得删除或隐藏这两个板块。结构及模板规则见 Consultation §3.1。
• 本次问诊资料的保密范围仅为 Consultation Notes 其余正文／自定义板块，以及保密附件。 其余临床资料按公共资料及对应岗位的业务范围提供，不因与 Note 属于同一 Visit 而要求 Note 授权；现有敏感身份字段和财务专门权限保持。
• 普通附件默认公共；医生或护士可标记单份附件为保密。在 Consultation Notes 界面上传、用于 OCR 的文件默认保密，原文件、预览、下载与 OCR 提取内容使用同一权限，不能通过识别结果绕过保密限制。
• 保密附件查看申请沿用现有问诊记录／附件申请流程，由负责医生审批；获准查看不会使附件变成公共资料。取消保密标记仅由负责医生手动操作，护士的上传、标记保密或编辑／发布权限不包含取消保密资格。
• 所有保密板块及附件须显示明确的 Confidential 标识，可采用锁图标配合标签／提示；无查看权时仅显示受限状态和申请入口，不返回或展示保密正文。列表、详情、历史、OCR、下载及 AI 引用应使用同一分类。

护士按 §3.1 在当前工作范围内直接处理公共 Diagnosis、Action 及其他普通问诊内容；保密 Note 默认锁定，按 §5 检查相应内容和动作授权。护士仍可操作普通内容及完成整次问诊。记录状态、期限、撤销与版本约束保留；无医生仅接种的本人 Note 继续按限定来源处理。

受限正文与共享资料分别判断。 工作范围不能成为保密 Note 批准依据，公共字段可编辑不能解锁正文；内容批准也不能扩张护士地点范围。两种 Consultation 入口使用相同判定，普通附件和 Service 按本 Visit 业务范围处理，保密附件按单份对象规则。角色、来源、状态、交易保护及真实／Assume 身份在服务端复验。

公共医疗信息读取应在角色模板中单独配置，并清楚显示是否已授予。拥有基础查询权限，或角色名称是 Doctor、Nurse，都不能代替这项配置。药房安全资料、V-Lab 执行资料及后台财务资料，继续按各自岗位的必要业务范围和既有权限提供。

旧资料如何处理。 已明确分类为公共资料的旧记录，可以按集团及角色权限只读查看。归属不清的完整病历、结果、正式文档和历史附件，应先核对来源与授权；缺少负责医生不能成为公开正文的理由。系统保留来源质量标记，不根据姓名猜填医生，也不允许借来源修复改写历史。

管理人员可以查看获授权的配置和审计信息，但管理身份本身不开放患者或临床正文。护士目前已有的草稿协作范围及处方草稿的实施差距，统一见 §11.2。

敏感字段的查看流程

敏感字段在搜索、列表、患者详情、审核页和历史快照中默认隐藏。系统只在查看获准后返回明文，不提前把完整值发到页面再遮盖。

1. 用户点击“申请查看”。页面提示：“本次敏感信息查看将记录操作者、患者、查看字段、时间、用途及结果，供操作审计。”
2. 系统按独立字段权限和适用审批规则处理，并显示申请状态。确认审计提示不等于申请获批。
3. 授权生效后，用户可以查看批准范围内的字段。未授权、待批准、到期或撤销时，字段继续隐藏。

系统记录访问结果和授权依据，审计日志不复制敏感值。修改或确认其他基础资料时，不会自动显示原敏感值；未读取、未修改的隐藏字段也不能被空值覆盖。

现有敏感字段分类继续适用。完整字段清单，以及现有机制尚未覆盖的审批人和有效期配置，仍需在实施前细化；本次确认没有授予无限期访问。

3.3 患者资料修改与确认：集团来源、角色与字段权限

患者基础资料归集团管理，包括姓名、性别、出生日期、证件资料、联系方式和地址等。集团内有查询权限的人员可以检索和查看这些资料，不必先在当前诊所为患者建立一次就诊。敏感字段仍按上一节的流程处理。

修改和确认共用资料，按集团来源与当前有效岗位权限判断。 依 2026-09-15 已确认的集团公共主档规则及后续 Center／Zone 规则，患者在本集团任一诊所有首次登记来源或非取消就诊，即具集团共用资料维护来源；不要求在当前诊所重复登记或接收。该规则取代旧的“每个当前诊所分别取得维护资格”口径。无任何集团来源的旧患者仍须接收登记；仅有普通预约或技术 link 不构成来源。虚拟预约患者的身份补全另按获授权的当前预约流程检查。 前台可以新建、修改和确认获准范围内的基础信息；医疗及安全资料、保险计划和整份 H5 提交审核，由具备相应权限的岗位处理。

既有转诊、推荐及接收审批保留原来源与审计，但不作为集团已有来源患者在每个诊所维护共用主档的额外前置条件。临床正文及预约、付款、附件等具体业务仍按其对象和动作边界判断。

待批、拒绝或取消的接收申请不产生登记来源。来源缺失的旧患者应完成接收登记；已有独立集团来源的共用主档资格不因另一条接收申请取消而消失。任何关联预约仍须与患者和诊所一致。

患者卡片显示真实关联诊所，不将操作者当前岗位写成患者归属。历史关联只依据可核实的建档审计恢复。接收批准开放的是资料维护资格，其他医生的完整记录和敏感字段仍按各自授权处理。

3.4 公共摘要、历史详情与附件如何呈现

先让工作人员了解病史概况，再按权限打开详情（AC-10）。 具有公共医疗信息读取权限的人员，可以查看集团内的就诊次数、最近日期、诊所和医生，以及诊断摘要、药物摘要、生命体征、安全摘要、疫苗等非受限医疗资料。打开历史页时先加载这些索引，无需逐条检查全部历史正文授权。

当前 Patient 360 候选展示最近记录中的诊断和药名，各最多十项，并标明最近日期。历史药名不能直接当作医生已核实的当前用药。摘要也不能包含整篇正文、完整 SIG 或给药指示，搜索不能利用未授权正文泄露内容。

没有保密内容权限时，页面仍显示用户有权查看的公共资料，并提供申请入口；应说明“Confidential／需要授权”，而不是显示“没有病史”。其他医生和护士按 §5 核验 Note 与附件的独立授权；历史版本、OCR 和 AI 上下文遵守相同分类。

负责医生跨来源查看患者共享病史。 既有岗位／分组范围限制预设工作清单，不以患者登记位置拒绝负责医生查看资料。医生以本人有效岗位登入，且患者已通过有效的当前问诊或当日／未来有效预约分配到其真实医生／Provider ID 时，可自动只读查看同集团内该患者各医生来源的公共临床资料、处方及普通附件；保密 Notes、保密附件及其版本仍须负责医生授权；本次 Consultation 的历史参考页亦包含其他医生已完成记录的公共部分，公共读取毋须额外确认。姓名相同、登记诊所或已结束的历史问诊不能建立这项当前关系。每次读取及响应发送前重新验证分配、登入、岗位、账号、Provider 和来源位置，并保留真实医生、患者、病历来源及自动分配读取依据的查看稽核。问诊结束、预约取消／过期／改派或资格撤销后失去由该当前接诊关系提供的患者历史读取资格；原医生自己的既有记录仍保留只读资格。此患者资格不开放其他患者，也不授予修改、处方开立、签署或日程／队列管理；这些动作继续使用现有权限。

医生确认存取同一患者的其他来源病历。 医生以本人有效岗位登入后，可以在患者病历页查看额外记录的来源 Clinic 及记录分组，明确确认需要存取并接受稽核。确认成功后取得该患者在所列来源位置的非保密临床资料、处方及普通附件只读权限；该自助确认不解锁 Consultation Notes、保密附件及其版本，受限内容仍须负责医生批准，不开放同位置其他患者。确认与授权写入同一事务；稽核失败不放行，来源位置已变化须重新显示并确认。取消不授予权限。范围限于本次登入及所选岗位，最长八小时；退出、岗位撤销／变更或账号停用后失效。审计保存真实医生、患者、来源 Clinic、记录分组及原始来源标识、时间、登入、确认及后续查看依据。角色模拟、护士和管理身份不能使用此医生自助确认。患者搜索及共用基本资料继续按集团权限提供；独立敏感字段审批、修改、处方开立、签署及日程／队列 Zone 范围保持各自门槛。

不同类型的历史资料按以下方式处理：

• 疫苗旧记录即使缺少可靠的就诊关联，也可供同集团且具有公共医疗读取权限的医生、护士查看。新增、更改和撤销仍检查来源医生的写入权限。
• 安全备注及核实日期属于公共资料。更正备注需要维护权限、获准写入的有效就诊记录和版本校验；省略备注保留原值，明确提交空值才清除。系统不恢复未分类的旧完整病历快照，核实及创建时间由服务端维护。
• Service Selection 和既往服务项目索引按公共医疗读取权限显示。历史只取本次就诊之前、同一患者且来源一致的有效记录。检查结果及报告按公共临床资料和业务范围读取；被标记保密的报告附件仍需负责医生授权。
• 查看公共资料不会触发空草稿保存或 Note 推荐。护士编辑需当前工作范围和适用内容批准；医生模板维护及其他医生专属能力保持原规则。
• Vital Trends 翻页失败时保留已加载曲线；切换患者或身份时清空旧资料并取消旧请求。只有真实迁移记录显示迁移提示，已删除或患者、诊所来源冲突的记录不进入索引。

系统在返回公共资料前核对患者和集团来源。撤销 Note 查看权，不影响另有权限的公共资料；补齐原本缺失的负责医生后，详情和返回前检查应使用新的归属规则。某份处方可以查看，也不代表同次就诊下的独立报告或附件都已开放。

安全资料修改的现有代码限制，以及旧接口和附件分类的验证进度，见 §11.2。

3.5 预约、护理与患者资料使用不同范围

护士按当前有效诊所／Doctor Group 工作范围处理业务。 日程、预约维护、签到、普通附件与 Cashier 使用同一地点依据，不再按服务医生筛选。外诊所忙闲可见不允许创建／维护预约或现场业务；需要实际处理另一诊所业务时，必须具备有效诊所任职和相应工作分配。既有独立预约能力仍按本域动作和来源核验。

前台保留预约和患者基础资料维护。 前台可以在授权范围内查询、创建、确认、改期或取消预约，也可以检索、新建、修改和确认患者基础信息。写入资料时检查维护权限及 §3.3 的集团来源资格；共用表单只向前台开放基础字段。

前台不执行签到、护理、附件管理或付款，也不维护医疗、安全和保险计划资料，不审核整份 H5 提交。这些限制同时适用于页面和直接接口。预约阶段记录付款安排，仅用于预约信息交接，不代表已经收款或结算。

同诊所护士的患者资料修改边界： 护士必须在当前诊所有有效岗位、具有患者维护动作，且患者已按 §3.3 具备集团来源资格时，才可修正已开放的基础字段。当前已有代码范围为姓名、主手机和地址；其他身份或敏感字段仍按独立字段权限、审计及版本校验。经 2026-09-27 用户确认，符合上述患者维护资格的护士可直接修改共享 Allergy／ADR／Alert 和安全备注，无需医生代为确认或本人负责的 Visit；医生仍须有合格来源 Visit。护士及医生均须提供修改原因并通过预期版本校验；服务端记录实际操作者、版本及审计事件，单项展示实际最后修改者和时间。预约、签到、付款、问诊草稿、H5 审核和保险计划各有独立动作与范围，不因“同诊所护士”而全部开放。

实现差异已解决（2026-09-27）： 已按上述用户决定，将旧 API 测试和界面与护士直接保存策略对齐。独立注射执行权限见 Frontoffice §2.6；这项安全摘要权限不授予临床代签权限。

本次附件和历史附件分开处理（AC-08）。 范围内护士无需另获普通问诊分级授权，就可以管理本次普通附件，包括上传的检查报告等文件。不过，这项权限不包括系统生成的正式临床文档或结构化临床记录。

删除本次附件时，系统保留文件标识、来源、操作者、时间及删除记录，并保护已签临床版本和引用证据。历史附件不能按本次权限删除；查看时检查原来源与公共／保密分类，保密附件另查负责医生授权。打开旧就诊，或把旧文件复制关联到本次，都不会使它自动变成可自由访问的本次附件。已关闭（Closed）的就诊也不能因此重新打开。

新预约、签到、付款及工作范围本身，不解锁保密 Consultation Notes 或保密附件。其他医生的记录查看与临时代诊职责分别授权。对于没有负责医生的 No Consultation 服务，资源及护理分工仍待确认，不能默认交给全诊所护士处理或收费。

3.6 Consent、撤权与版本控制

患者同意应按用途管理。 建档、通信、跨诊所共享、程序或手术、AI、资料发送是不同用途，不能用一次勾选代替所有同意。现有系统已有部分就诊纸质 Consent；患者级版本、撤回、监护人（Guardian）、用途绑定及共享细则仍是部分实现或待确认。AI Scribe 沿用 Consultation 已有的同意检查。

授权变化后，后续操作按新权限执行。 账号停用、工作范围失效、保密授权撤销，或用户切换角色、诊所、患者时，系统清理不再允许显示的内容和缓存。切换前的迟到响应不得恢复旧正文。如果撤权先于保存提交，保存应被拒绝；此前已经合法提交的内容保留作者和版本。

护士范围内保存及签署记录本人身份；原有未处理代改历史保留，迁移处理不能自动批准或丢弃。授权不允许直接覆盖已签历史、药房交接或收费快照；已关闭的就诊不可重开。查看权限也不自动包含导出、复制为新记录或编辑。

收紧权限时，应同时提供可用的申请和审批入口。系统不能为兼容旧宽权限而补造医生批准。页面应分别说明加载失败、没有数据、无权限、待审批和记录状态不允许修改，帮助用户判断下一步操作。

4. 用户、岗位与角色配置

管理员在用户详情中维护员工资料和诊所任职；Clinic Manager 在独立界面维护护士分组与排班，权限概览读取同源结果。组织、角色模板和审批记录各自在对应入口维护；用户详情引用这些配置，不再维护另一份副本。保密内容继续由合资格负责人在申请中心审批；旧护士普通临床分级授权入口随新模型停用。

4.1 工作场景与角色

工作场景按岗位职责组织。后台角色即使可以查看、维护或处理诊所业务，也在后台场景完成对应操作；不能因为业务记录来自某个 Clinic，就把该后台角色列在 Clinic 下或要求切换成诊所角色。CP 的仓库执行和现场管理工作在 WDL 场景完成；相关财务工作统一进入后台 Finance，即使任务与问诊、处方或结算关联，也不因此归入 Clinic。

AC-04： 同时区分当前工作场景／Operating Unit、有效角色、获授权的数据范围、业务记录的来源 Clinic。后台或 WDL 操作不修改原业务归属，也不复制第二份 Invoice、处方、附件或库存记录。列表按获授权的来源 Clinic 筛选；进入详情继续校验对象、动作和版本。审计同时记录真实操作者、工作场景、有效角色及源业务对象／Clinic。

AC-05： Finance 统一属于后台（Back Office），Clinic 和 WDL 均不提供 Finance 角色入口。财务在同一后台 Finance 中处理获授权的 Clinic 与 WDL／CP 价格、采购财务、附件查询和报告工作，按来源单位／业务类型筛选；进入关联记录后保持后台 Finance 身份。复用原权威记录、状态和版本，不复制单据或通过角色切换扩大权限。本条取代 2026-09-07 的后台与 WDL 双场景规则。

AC-06： 原 Billing／Insurance 合并到 Operation Manager；Finance 独立迁移为 Finance Team。现场 checkout 属 Frontline Staff／Clinic Manager 的功能，后台能力独立配置，不因处理同一账单叠加权限。

4.2 Finance 的业务动作

Business Report 与 Day-end Revenue Report 的来源范围独立配置和验证。Business Report 使用明确的 Reporting access 或符合规则的有效诊所任职；Day-end 沿用当前 Clinic／Center／Zone 的来源授权。无范围须显示不可用，不能返回伪零收入或默认全集团。配置报表范围仅由已有相应管理资格的人员按获认可诊所执行，本轮不新增 Finance 临床任职或其他权限；入口可用及范围配置不构成金额计算验证。

2026-09-08 用户明确要求构建诊所／医生 Day-end Revenue Report，仅统计新 Cashier 账本，收入报表按 Cashier §6.1 实施；现金盘点关账／Period Close 继续排除。角色场景归属和上述权限是目标产品契约；角色入口及有效会话分类已有基础；完整后台数据范围及权限细分仍待实施。

4.3 管理入口与用户资料

普通管理员应能在一个用户上下文内完成资料、任职和服务范围配置，并解释为什么该用户可以或不可以访问某类资料。医生的保密内容审批沿用既有对象申请流程；护士普通范围由经理排班配置。共享角色模板、组织主档和审批记录保留各自唯一来源。

Entity／Site 地址（2026-10-19 确认）： 在 Organization 的单位编辑中，具备组织维护权限的人员可新增、修改或清空普通独立单位的 Address，最多 2,000 字符，保留多行地址。持牌 Center 使用现有 Licensed premises address 及牌照核验规则。Doctor Group 只显示所属 Clinic／Centre 的地址摘要，不独立维护地点或覆盖地址。保存仍需原因并校验组织版本，记录地址前后值；遗漏地址字段时保留原值，清空须明确保存空值，不影响单位的其他配置。预约 Reminder 按预约来源 Clinic 读取该地址；旧 Zone 来源经明确映射解析所属 Clinic，跨诊所查看不套用当前工作单位地址，历史消息不随配置修改。

批量审批（2026-09-19 确认）： 请求清单提供「全选／批量批准」，范围仅为当前已加载、可批准的待审记录，不隐式选中未加载分页。批量复核页保留接收人／患者、操作与记录范围、原申请起止时间及原因，可取消个别选择，并填写统一审批原因。提交沿用每条申请的原范围及期限；每条独立校验当前身份、权限、状态和版本，记录独立审计与结果。成功项不重复提交；失败项明确显示原因，版本变化须刷新后重新复核。切换角色、任职、诊所或离开组件停止后续提交；已发送请求的结果仍以服务端为准。适用于临床记录访问及患者资料接收申请；现有单条、部分批准、拒绝及撤销动作继续保留。医生代编辑和采购审批沿用此交互及各自原有业务门禁，不因批量操作获得额外权限。

同批包含读取与编辑申请时先处理读取申请，再处理依赖读取授权的编辑申请；读取未获批准时，编辑申请仍须独立满足原有授权条件，不能跳过门禁。

Cashier 功能入口依所选角色的有效动作开放；Doctor、Frontline Staff、Finance Team 的系统默认包含各自适用的只读能力，集团模板可在批准上限内调整。Billing History 与 Checkout Queue 的可见性、业务数据范围和写权限仍按有效模板、Cashier PRD 及服务端鉴权执行。

角色分類與描述

新增帳戶及任職使用可搜尋的角色選單，依下列五個類別分組；Clinic Manager 為第一列。每列顯示角色名稱及描述，搜尋涵蓋名稱、描述與類別。2026-10-04 15:37 SGT 唯讀核對 UAT vai_clip_uat.clinic_roles 及實際執行後端的角色目錄：下表 13 個角色均已啟用且可指派，另外 22 個歷史角色已停用；名稱與描述採用現行 UAT 定義。UAT 當時已啟用 Frontline Staff 臨時問診模式，具體限制見下文。Proposed access 仍表示產品目標，不代表所有功能均已交付；尚未具備的財務流程另列交付限制，不能因角色名稱聲稱功能已存在。本次核對及文件更新未改動 UAT 帳戶、任職或權限。

Clinic Manager 的「All clinic permissions」不包括集团共享药品写权；药品三层管理职责及读写范围以 Drug PRD §1.2.1 为准。System Admin 在该药品契约中对应现有 Super Admin；本轮权限要求及现有代码差距见三层交接说明，角色名称或入口可见不作为已实现证据。

每個任職以角色及真實工作單位決定權限和工作場景；Title 不參與判斷。Frontline Staff 可有多個 Clinic／site 任職；WDL Staff／Manager 可有多個 WDL 任職，並於選定 WDL 處理已存在的下游客戶。切換任職清除舊資料及快取，後续请求重新验证当前岗位和权限。新 WDL 的採購申請審批仍依真實操作者判斷，提交人不可自批。PIC 單級審批見 Drug PRD §7.1；既有 CP 審批見 CP PRD。

Clinic Manager 的臨床權限只在選定有效診所範圍內生效，保留病歷狀態、付款、Closed 及不可變版本限制。2026-11-06 用户确认：签署、處方和原子完成直接使用预约／本次 Visit 已绑定的 Doctor，界面只读展示、不再增加代表医生选择步骤；服务端核验当前有效执业身份、来源诊所任职及确切 Visit 权限，未绑定或失效时阻断，客户端不得替换为另一位医生；不要求逐问诊的护士授权。快照同时保留实际 Manager、所代表 Doctor、角色及岗位，不改原问诊负责医生。Frontline Staff 的临时问诊模式由部署开关 VAI_FRONTLINE_CONSULTATION_ROLE_AUTHORITY=1 明确启用（默认关闭）：在选定有效诊所任职内复用 Clinic Manager 的问诊读取、编辑、处方和签署权限，无须逐问诊申请；签署／处方同样直接使用本次 Visit 已绑定且在来源诊所有效的 Doctor，保留实际 Frontline Staff 与所代表 Doctor 的冻结身份，不改问诊负责医生。关闭或移除开关并重启受影响服务后，后续请求恢复原具体医生授权策略；既有授权及历史签署证据不删除。该临时模式只改变问诊对象授权，不增加其他 Manager 权限，不覆盖集团禁用的动作、只读模拟或病历状态限制。Allied Health Professional 使用本人有效执业身份，药物处方权限默认关闭，可按专业规则显式配置。

Laboratory Manager 属 Back Office，唯一化验角色；只读获配 Lab 的原始 request 及 request details，用于核对外部系统资料。不提供内部 specimen processing、报告发布或库存操作。Lab 单位必须有明确 vendor 映射，缺少映射拒绝访问。

完成显式 cutover 后只保留上述 13 个有效角色。Reception／Nurse → Frontline Staff，Clinic Admin → Clinic Manager，Pharmacy → Pharmacy Staff，HCProfs → Allied Health Professional，WDL PIC／Staff → WDL Manager／Staff，Billing／Insurance → Operation Manager，Finance → Finance Team，Internal Support → IT Support。Doctor、Operation Manager、Super Admin 保留其身份。Master、Medical Director、舊 Laboratory Staff／PIC 及其他舊角色退出有效目錄；如出现无已批准映射的有效持有人，迁移停止并报告，不能猜测分配。歷史角色、任職、作者和审计快照保留；旧岗位结束后创建新岗位，并记录迁移对应，不改历史身份。未 cutover 的运行环境仍按其实际旧角色、有效任职及模板计算权限，不能根据新显示名称套用目标角色的动作。旧 Lab PIC／Staff 不能仅改名即视为只读 Laboratory Manager；WDL 的两个名称按下列 2026-11-14 已确认统一规则单独实施，不由其他角色的全局 cutover 隐式触发。仅新增角色行或更新标签，不构成模型迁移。

2026-11-14 用户确认：wdl-pharmacist-pic 与 wdl-manager 是同一角色，唯一现行代码使用 wdl-manager；所有用户界面仅显示 WDL Manager，不增加 PIC 标签、括号或职责说明。新任职与角色目录只提供这一项。原 PIC 的采购审批、供应商审核、盘点／召回经理操作、库位启用及 Reports／按药品 P&L，与 Manager 的采购及仓库能力统一；仍要求当前 WDL 有效任职、对应动作权限及对象／业务状态，不扩展临床、其他 WDL 或独立财务权限。Staff 不因本次合并升级。

身份规范化、默认权限／动作上限、集团模板、前后端功能门禁及旧会话刷新必须一起完成。Reports 入口与接口均接受统一 Manager，不可只认旧码；权限不足、读取失败、数据缺失分别处理。旧任职／角色 id、历史作者及审计不改写；仅在 WDL 范围预检并合并有效任职，保留映射、重复任职去重和跨单位隔离，自定义权限限制不得无条件并集覆盖。此决定取代此前 WDL 仅改显示名仍视作不同职责的过渡口径，但不表示迁移已经执行，也不授权本轮运行全站角色 cutover。本地候选实现和迁移回归见11-14 专项证据；目标数据库任职迁移尚未执行，实施、迁移和验收分别留证，工程入口见代码方案。

已 cutover 的角色模型中，全部 13 個角色可由 Super Admin 在各自权限上限内维护集团草稿、预览、发布和审计。角色操作数量是有效业务权限数量，不是 App／Tab 数量。Super Admin 固定保有 Catalogue 的完整查看、维护、导入与发布权限，集团角色配置不得移除其 Catalogue 查看／维护／发布动作。Super Admin 的默认角色不取得直接临床权限，支援临床仍使用受审计 Assume Role 和专业身份检查。

实施与交付边界： 本轮仅目标 STG／UAT，数据库身份 allowlist 加显式 cutover；PROD 不执行迁移。新旧模型切换需备份、只读预览、报告未配置账号／空 Title／受影响授权、受保护分支发布及独立环境验证。实际模型以目标数据库的持久 cutover 标记、有效角色／任职和当前集团模板共同核对；页面显示、源代码或另一环境的核对不能替代。上文保留的 2026-10-04 UAT 证据仅适用于当时的 UAT；截至本轮文档更新，STG 的实际切换仍待独立执行和验证，不宣称 STG 已迁移，也不猜测其当前数据库标记。被替换岗位的临床授权与服务关系结束，需明确重新授权；现有空 Title 不阻止登录。财务已实现的账单、报表、保险回款及 correction 能力按对象范围提供；完整 P&L、坏账审批、doctor commission、bank reconciliation sign-off、财务系统配置及新的退款／折扣／credit-note 审批流程尚未实现。外部医院／客户注册暂缓；不创建虚假的可用权限。

App／Tab 显示与访问配置

Catalogue 的共享父容器按每个子面板所需动作分别判断：目录读取、维护、发布、Policy 读取和价格审批不相互推定；无审批权不加载审批面板或预取其数据。只有具备目录读取及现有审批动作、且相应 Tab 可读时才显示价格审批内容；维护、发布和审批写入继续遵守服务端对模拟身份的限制。只读状态不显示可执行的保存／发布／审批入口；权限或主体变化关闭失效编辑器并阻止旧响应回填。某个辅助依赖失败不应使其他有权目录整体不可用；应在所属面板明确显示错误与重试。此调整不新增角色权限，不改历史价格及发票快照。

完整目录见 App／Tab 清单，日常操作见 用户与组织操作手册。目录使用稳定 App ID、Tab ID，区分已接入、历史整合、未接入及上下文工具；未接入界面不可勾选授权。动态患者／文档实例、弹窗和页面内部内容面板不另建角色权限。

显示配置按 Tab 独立保存；查看与编辑复用现有业务权限，因此共用一个权限的页面同步变化。界面明确说明此联动，不承诺尚未建立的逐页独立后端授权。部分配置页面只有一个管理权限，读取与管理无法进一步拆分，须在限制说明中标明。个人设置及上下文控件由既有个人身份和模块规则控制，不在集团表中虚构新权限。

配置复用集团草稿 → 差异预览 → 填写原因 → 发布，显示差异与业务权限差异一起记录；并发版本冲突、权限上限、集团隔离及现有管理员保护继续生效。隐藏配置随版本保存，复制及未提供该字段的旧客户端保存保留当前配置。发布后服务端下一次请求使用生效权限；界面重新获取会话后刷新，返回浏览器窗口时也刷新投影。未实现的自定义角色新增和单用户例外不在本轮范围。

Audit & Review 继续独立。医生护士授权位于 Settings（Personal Settings）内，不要求医生打开管理员 App。个人偏好和系统共享设置维持既定入口。

用户详情只保留“基本资料”“岗位与服务范围”“权限概览”三个页签。原 Service Scopes & Approvers 不再承接日常人员配置：护士服务范围迁入岗位详情，负责人指定迁入组织／人员的职责区域。旧入口保留定向跳转及筛选上下文，不维护第二份配置。2026-09-10 用户补充：仍展示多人关系记录的列表提供 Element Plus 用户搜索，可按姓名、用户编号或邮箱查找；服务端在分页前匹配，包含有效及历史记录，清空后恢复当前权限内全部结果。

用户列表与资料查看

用户列表以姓名和邮箱为主，分别显示 Account type、多个有效业务角色、Title、工作单位及账号状态；User code 保留搜索及详情只读，不作为首列。Account type 只解释账号分类，正常值显示 Staff／External，不再混入 Permanent／Locum 等雇佣类型。Employment type 不在用户列表、新建或日常资料编辑中展示，未修改的存量值原样保留。旧 human／未知分类显示 Needs classification，不能根据雇佣类型推断 Staff／External；受授权搜索中的旧 service 显示 Service account (legacy)，不自动转换或新增此类型。

默认展示人员，技术服务账号保留受授权搜索和历史兼容；支持姓名／用户编号／邮箱搜索、主体／角色／状态筛选。点击进入用户详情，返回时保留原筛选和滚动位置。

Centre Zone access 批次配置（既有实现及非护理岗位迁移参考）： 该矩阵不再承担护士 Group 配置，护士统一进入 §4.4 的工作范围页；医生固定归组进入账号任职。旧范围仍须逐岗位核验后迁移，不能因入口收口扩大其他角色权限。既有 Users 页头提供中心区域存取侧栏。管理员先选持牌 Centre，再按姓名／邮箱／Title、角色、部门筛选；每行是使用者在该 Centre 的一项有效状态岗位分配，列为此 Centre 的有效 Zone。多岗位不合并授权，未到生效日期／已过期的岗位明确标识，修改 Zone 不改变原岗位、日期或账号资格。没有该 Centre 岗位的人员先从个人「岗位与服务范围」配置岗位。

CDU Pharmacy／Pharmacy Staff 行固定显示 Entire Clinic／Centre，不提供勾选或批次范围变更。其他可编辑角色勾选 Zone 使用 Selected Zones；空选择表示没有 Zone 存取，勾选全部当前 Zone 不授予未来新增 Zone。明确选择 All Zones 才包含未来 Zone。批次操作仅套用至已选且当前筛选可见、可编辑的行。待保存的格子及模式变更突出显示，并汇总涉及岗位、人数和勾选变更；切换筛选保留待保存修改，保存涵盖所有待保存行，包括当前隐藏行。存在待保存修改时不可切换 Centre，关闭侧栏沿用放弃修改确认；提交时不可重复提交或关闭。

保存须填写原因，最多一次 500 项岗位。服务端沿用现有管理员权限、所属集团边界、岗位规则及审计／会话失效处理；同一批次全部成功或全部回滚，任何岗位快照已变化时拒绝整批并提示刷新。角色、有效日期及详细资料从「Open assignment」进入既有个人编辑器；不可用 Zone 配置须在该编辑器检查。患者身份仍按集团共用，Zone 分配限制既有临床／预约范围。本轮本地实现和自动检查与 STG／UAT 部署、浏览器业务验收分别计证。

详情、组织配置和角色配置使用 App 内右侧栏，窄窗口占满 App 内容区域；列表筛选及滚动位置保留。遮罩不关闭，未保存变更须确认放弃，提交期间阻止重复操作及关闭；页头与主要保存操作固定，内容内部滚动。 User 配置按侧栏实际宽度调整字段列数，标签位于控件上方，搜索及筛选可换行；个人资料保存操作位于独立侧栏底栏。Centre Zone access 的筛选／批次操作与表格位于滚动内容区，变更汇总、原因及保存操作位于独立底栏，不叠压表格固定列；多 Zone 保留表内横向滚动，完整显示 Open assignment 操作。医生身份在个人资料中以摘要卡展示注册号、主要专科及诊所任职，编辑表单区分主要专科和票据科室，并说明专科选项来自 Organization → Departments & Specialties 共用目录；存在未保存身份修改时禁用刷新，切换页签或关闭仍须确认放弃。

2026-09-11 用户确认：Organization & Access 采用 Catalogue 的页面结构与视觉层级：带 App 图标及当前角色的侧栏、统一选中态，白色页头承接标题和刷新／新增操作，搜索与筛选放入列表卡片。Users、Organization、Roles & Permissions 和 Requests & Approvals 使用一致的留白、表头、按钮高度及侧栏配置方式；窄 App 窗口保留可滚动表格和完整内容，不因浏览器宽度掩盖窗口溢出。控件继续复用 Element Plus，不照搬旧页面的原生表单或过小字号。

详情顶部固定显示姓名、账号状态、返回入口；内部页签切换保留同一用户。顶部账号状态只表示登录资格，不把账号 Active 解释为所有岗位及授权均生效。

停用账号的查找与恢复（2026-09-10 用户反馈）： 停用不删除账号，Users 默认包含全部状态，可通过 Inactive 和姓名／编号查找。诊所／角色筛选对停用账号保留历史岗位关联，仍受管理员所属集团边界限制。状态变更后保留当前详情，并解除会隐藏该账号的相反状态筛选；无结果时提供清除筛选入口。重新启用恢复账号状态，不自动启用已停用岗位，也不恢复已终止的护理服务关系或临床授权；后两者需分别配置／重新批准。

Provider 注册资料（2026-09-10 用户确认）： 新建界面明确标为 Doctor registration number，并说明系统 User code 在建账号时自动生成、与执业注册号分开；复用已有 Doctor 身份时只读带出其注册号，旧缺号明确显示 Not recorded。 首次配置 Doctor 岗位并创建 Provider 时，必须填写非空执业注册号（最多 120 字符）；资料不完整时整次岗位创建不生效，不留下半成品医生身份。已有 Provider 跨诊所复用稳定身份与注册号，新增岗位不得覆盖注册号或自动重新启用停用身份。管理员通过用户基本资料 → Doctor identity → Configure identity 补录或更正，保留变更原因及版本校验。旧记录不自动生成或猜填注册号；2026-10-12 用户确认的全局临床规则：注册号不作为签署或处方的准入条件；2026-11-06 已取消所代表医生选择列表，改为从本次 Visit 读取已绑定医生；预检及最终提交仍校验有效账号、活动 Provider、诊所任职和确切 Visit 权限。已有注册号照常保留；缺号显示 Not recorded，签署快照保留实际空值，不猜填号码。此规则不改变管理员新建身份／重新启用时的资料录入要求。旧缺号身份仍可停用，重新启用前必须补齐；停用不删除原记录、不自动恢复历史授权。

医生身份与专科（2026-11-04 用户确认）： CMS 按尚至本次确认的业务范围取消 GP／SP 分类及对应配置，不再提供 Consultation classification 字段、分类标签、必填提示或分类接口写入。医生主要专科与票据可用科室／默认科室继续独立维护；专科不自动产生权限、价格或套餐资格。普通问诊统一规则见 Frontoffice。此决定取代 2026-10-27 的 GP／SP 分类规则；旧字段仅保留历史兼容，不用于新业务判断，历史预约、已签署记录及票据不批量改写。

专科可选项： Organization → Departments & Specialties 共用目录以 2026-11-04 查阅的 尚至官网专科服务及英文专科／专科医生导航为初始参考，提供以下 28 项英文／繁体中文名称。官网仍存在全科医生入口；本系统范围以用户本次决定为准，目录排除全科及物理治疗、营养等非医生专业条目。家庭医学科按官网的专科名称保留，不等同于恢复 GP 分类。官网不同页面的同义表述合并为一个选项，已有自定义专科、停用状态及稳定关联保留；管理员仍可维护名称和状态，初始化不得覆盖其后续修改，也不按姓名自动替医生选专科。

医生票据用多科室身份

2026-10-27 用户确认并授权实施；多科室配置与打印选择已实现并通过本地验证，STG 发布核验见专项证据，业务 UAT 尚未执行。 在用户资料 → Doctor identity → Configure identity 中维护“可用于票据的科室／专科”：同一稳定 Provider 可关联共享专科目录的多个有效条目，并指定其中一个默认打印身份。此关联描述同一医生的票据展示身份，不增加医生账号或 Provider，不代替实际接诊医生，也不表示自动取得新的临床专业资格或业务权限。

• 沿用现有医生资料维护权限、版本校验与变更原因审计；专科目录仍由有权维护该目录的管理员管理。打印人员只选择已配置身份或不显示科室，不能自由输入科室、创建目录项或选择另一医生。
• 保留现有主要 Specialty 及其旧消费者兼容；票据身份为独立多选关联。主要 Specialty 的更正与票据身份配置分别保存，不能以一次打印选择反向覆盖人员资料。行政 Department、工作单位／岗位与票据科室是不同概念，不自动互相映射。
• 默认项必须属于该 Provider 的可用关联；目录或关联停用后禁止新选择，不静默选择另一个科室。缺少配置可不显示科室；旧自由文本专科只能标为未映射，不能拆词猜测为多个有效身份。
• 打印候选先由原 Invoice／Visit 的实际医生稳定身份确定，再按当前有效资料及既有诊所／Centre／Zone 访问边界取值；同名不能匹配，其他医生的身份即使在同一诊所也不能使用。旧票缺少稳定医生关联时不开放猜测式选择，保留原冻结显示并提示资料缺失。
• 科室选择及当时名称进入该次打印快照。后续改名、停用或默认变更不重写历史，历史版本重印仍受当前票据读取资格及作废／退款状态约束；详细规则唯一见 Cashier PRINT-05、PRINT-08。
• 本次实施配置与展示契约，不修改已有角色种子、权限模板、医生肖像／签署身份、价格、Visit 或历史票据。实施与迁移建议见统一打印实施计划。

界面取自本地隔离合成数据；实际验证及上线边界见打印专项记录。

新建账号与配置岗位

新建账号分为三步：填写人员资料及独立 Title；逐条配置角色及工作单位；最后核对并保存。管理集团只有一个可选项时自动带入，多个可选项才由管理员选择。新建审计原因默认“New user initial configuration”，备注选填；给既有用户新增工作单位仍需原因。

进入 Work scope 前校验姓名／邮箱／Title 及真实管理集团；进入 Review 前逐条校验角色、匹配工作单位、新临床专业人员执业注册号及日期顺序。角色与工作单位使用同一次集团引用数据，切换集团清除旧单位，失效角色不能沿用。Working units 区分加载中、加载失败可重试、无匹配角色单位和搜索无结果，保留人员输入；无合适单位时提示返回选择集团／角色或在 Organization 配置。仅建账号通过 Person 的 Review account only 显式进入复核，仍校验人员及集团，保存不创建 Provider 或岗位。本轮以原子 onboarding 实现完整创建，Users 与 Doctor directory 的 Add doctor 复用同一流程；既有用户复用其身份。重复提交同一请求返回完整原结果，任一步失败全部回滚。

暂不配置岗位时： 允许保存尚未配置岗位的账号，但必须先明确真实管理集团，并标为“未配置岗位／暂不能进入业务”。

管理集团与跨集团任职

管理集团关系不授予临床或业务权限；Master 固定当前集团；Super Admin 只有一个可管理集团时自动带入，多个可选集团时明确选择。岗位主体只列当前管理员有权管理且账号已关联集团内的有效组织；跨集团任职需 Super Admin 先显式关联接收集团并填写原因，不能通过空组织或自由文本扩大候选范围。

User → Profile → Management groups 表示哪些管理集团可以承接该账号并在其下配置工作单位。操作上先在用户资料中 Link a management group 并记录原因，再到“岗位与服务范围”为该集团下的 Clinic／Back Office／WDL／Lab 新增工作单位。只关联 Management group 不会创建岗位、选定角色、开放 App，也不会授予患者、用户、临床或财务数据权限。集团范围内查询仍须匹配当前角色、具体 capability、有效岗位、数据对象及必要授权；“有集团权限”不等于可查看所有患者记录或全部用户数据。

共享账号全局资料由 Super Admin 维护，各集团 Master 只维护允许的本集团岗位。旧数据仅根据已有岗位和可核实建档来源回填集团，真正无来源的账号保持待关联，不猜测归属。

页面提示： 已关联的管理集团明确显示 Linked；Super Admin 的集团下拉保留已关联项并标为不可重复选择。没有可关联集团时显示明确状态，不展示空下拉；搜索无匹配和全部已关联分别解释。Master 及不具备关联资格的上下文只读展示，不提供失效的关联操作。选择集团及填写原因属于未保存变更，切换用户／工作单位配置／关闭侧栏时沿用放弃确认。

用户资料字段与填写要求

以下字段要求于 2026-09-10 确认。

前端与接口使用同一字段含义：日期只用 YYYY-MM-DD，时间戳携带时区；布尔值只能为 true／false；省略字段表示保留，显式 null 才清除允许为空的字段。新增和修改执行同等格式校验，不静默截断、吞掉拼错字段或把缺失值改成今天。错误定位到字段，保留输入并允许修正；旧资料中未修改的空值或退役选项不阻断无关资料更新。新建重试复用同一请求标识，不重复创建账号；搜索或列表迟到响应不得清空已打开的详情或服务范围编辑弹窗。

行政部门只在基本资料的“更多资料”内选填，未配置显示“未填写”，不阻断账号创建和工作范围配置。它不从工作单位自动推断，也不删除旧资料。部门目录属于当前管理集团；可关联真实工作单位，但不会创建或改写 Membership。原有 Operating Unit 的 department 类型仍表示旧后台工作场景，不转换成新的资料部门。Specialty 是医生专业目录，不是组织层级。目录停用阻止新选择，保留现有引用、历史和显示；改名保留 ID。无来源的 SSO／导入账号显示未配置，需要管理员明确关联集团和角色，不能自动取得业务入口。

基础资料下拉规则（2026-09-14 用户确认）： 管理集团、工作单位／诊所、行政部门和医生专科必须选择权威目录条目并保存稳定 ID，不在用户配置中以自由文字创建同名机构。集团和工作单位由组织管理维护，部门及专科在“组织 → 部门及专科”维护；共享专科由平台管理员维护。选项必须按当前管理权限、集团及有效状态过滤，服务医生进一步限定当前诊所。名称变更不改变引用 ID；停用条目禁止新选，保留既有引用与历史显示。无可选资料时先维护基础资料；行政部门可留空，必需的集团／工作单位不能用手填名称绕过。旧文字资料保留为未映射，不按名称自动赋予组织关系或权限。姓名、注册号和备注等自然文本仍按各字段规则填写。

4.4 Doctor Group 配置、医生归属与护士排班

已确认（2026-11-11）： 组织以 Clinic／Centre 为第一层 Unit，原 Zone 转为其 Doctor Group 子 Unit，位置、房间和设备由 Clinic 承接。Group 必须预先在 Organization → Units 配置；新 Group 的代码由系统生成并只读显示，人员只填写名称和必要配置，改名不改变 ID 或已生成代码。旧 Group／Zone 的既有代码与来源关系在迁移时保留核验，不因界面调整自动重新编号。

医生的 Group 是其在该诊所的固定归属，在医生账号的诊所任职内配置，不随护士排班变动。护士账号创建及用户配置只绑定诊所，不选择 Group 或服务医生；Clinic Manager 在独立护士工作范围页维护默认分组及临时排班。该页只选择本诊所已有有效 Group，不提供建组、改医生归属或历史来源补映射。

注册仍支持多选工作单位，每个单位独立有效期、角色和默认登录选择；单单位自动确定登录入口，多单位的默认只影响登录入口，不扩大权限。新增和变更保留当前原子保存、重复岗位校验、账号状态、岗位历史及版本保护。医生继续复用稳定 Provider 与各诊所有效任职。

Users／「使用者」是现有账号管理入口，不是新增的组织关系表或另一个 Group 维护页。组织页、医生账号和护士排班之间使用明确跳转及同源摘要，不提供多处编辑同一关系。

配置顺序： 在 Units 选择 Clinic 并配置 Group → 在医生账号的该 Clinic 任职设置固定 Group → 注册护士只绑定 Clinic → Clinic Manager 设置护士默认组和班次。例如 A 的 Blue 包含医生甲、乙，护士小林在 A 任职并当前分配 Blue；小林通过该组处理范围内业务，不再逐人绑定甲、乙。医生在 B 的归组单独维护，不让小林取得 B 的问诊权限。

Group 生命周期： 组织主档支持受控新增、改名和停用；医生归组变更归账号任职管理。医生和护士排班页不随意新增 Group。停用前展示现有医生、护士默认、未来班次及未完成业务的影响；改名保留稳定标识，停用阻止新分配，历史引用及审计保留。组织管理与账号管理权限沿用各自既有职责，不因 Clinic Manager 能排班而自动取得这两类管理权。

同一医生在同一诊所是否有必须同时归属多组的真实例外，以及在途预约／Visit 的跨组交接规则，仍须核对。本地候选按一位医生在每间诊所一个组实现；既有预约／Visit 保存确定的来源组，医生后续组织变更不自动重算历史访问范围。Zone 的位置、房间和设备职责移交 Clinic 已确认；实际映射、库存／交易历史的兼容与迁移验证属于工程实施事项。

当前候选及待细化排班： 本地候选采用一个默认组、非重叠的临时时段覆盖、到期恢复默认及显式休班。无默认或休班不回退为全部组。是否增加每周模板、多组同时覆盖和更复杂班次仍列 §11；不为这些未决扩展增加重复入口。界面要同时显示预设、实际生效结果、来源和下一变化时间，实际授权以每次请求的服务端计算为准。

Clinic Manager 只为其管理诊所已有有效护理任职配置分组及排班，不创建跨诊所任职，也不因此取得用户管理、角色模板或保密审批权限。默认、排班及用户详情摘要读取同一数据；新增、撤销、到期与修改保留操作者、来源、原因及版本。旧服务医生配置和本人服务医生申请停止作为新护士权限依据，既有记录保留历史。原任职停用、恢复和账号状态控制保留；恢复任职不复活已终止保密批准。旧 Nurse 与 Frontline Staff 采用一致迁移口径。

实施边界： 本地候选已验证 Units 分组、医生归组、护士默认分组及排班，并在隔离数据中完成旧 Zone 与 Clinic 位置整合演练。实际诊所数据复核、目标环境启用与 UAT 另行执行。见本地候选验证及护士工作范围实施方案。

4.5 有效权限概览

概览是同一套服务端规则的只读解释，不是新的一套 Allow／Deny 配置。先选择具体主体／岗位，避免把多个岗位的动作并集误显示成当前诊所可用权限。

管理员看到授权元数据，不因此看到临床正文；默认不能代医生开启这项个人授权。既有被指定负责人的其他审批职责继续按原权限处理，也不能制造医生本人授权。医生和护士详情可从两个方向读取同一授权记录。由用户详情进入申请中心时带入人员／主体筛选，页面明确当前筛选且可清除。

新概览必须解决当前护士权限列表仍出现 pharmacy 动作而 App 不可用的差异，逐项核对前端入口与服务端有效动作，不将原始角色代码清单直接命名为最终可操作权限。此为实施核查项，尚未证明所有相关 API 存在越权。

权限概览按具体工作任职及其集团当前生效策略解释，不能把跨集团权限并集作为某个诊所的实际权限。clinical.write 包含到诊、护理评估、候诊准备和付款安排等现有工作动作，不等同于临床签署或处方权。患者自填审核按当前 Clinic、patient.write、主档维护资格及患者确认结果逐项判断；正式接入与版本／审计契约见 Frontoffice §3，不能以扩大护士权限替代业务校验。患者、预约、问诊／临床文档、收费、CP 与 V-Lab 各模块保留自身对象范围、动作和状态检查；入口可见与操作获准分别验证。

Calendar 护士跟进 Reminder（2026-11-01）： 新增可配置的 calendar_reminder.read／create／process／manage，分别控制查看及计数、来源候选与创建、完成／延期／取消、负责人／备注更正与有原因恢复。同日用户进一步明确全部患者跟进 Reminder 仅护理岗位（nurse／frontline-staff）可见及使用，医生、管理员和其他非护理岗位不可配置上述能力；即使有旧授权，API 仍按当前岗位拒绝。2026-11-02 修正既有护士默认能力：nurse／frontline-staff 默认拥有这四项动作；旧角色或已发布模板遗漏新动作时继承默认，无须改写已发布历史。明确角色拒绝（未启用集团模板时）、集团模板拒绝或不合法配置、目录停用均不被默认覆盖；权限编辑器展示同一有效默认，保存明确取消时保留 deny。其他岗位不继承，仍校验当前集团、有效任职及 Clinic／Center／Zone；护士不再以护理服务医生关系为门槛，按当前工作范围执行 Frontoffice §4.7。个人 Reminder 与 Calendar 患者跟进的接收范围独立，具体对象和轮班规则唯一见 Frontoffice §4.7，本地授权与撤权验证见 专项记录。

4.6 管理员、负责人及角色模板

AC-07： Super Admin 在获授管理范围内维护权限并指定负责人；管理员身份本身不等于全部病历读取权或临床审批权。Master 仅保留历史来源，不在新模型使用。只有被指定为相应范围负责人时，才可以承担该范围的病历访问审批；同诊所与跨诊所审批都适用。原医生或指定负责人只批准自己有权处理的记录和动作，不得自批、给自己扩权或批准超出申请的目标。

护士普通 Consultation 操作与签署保存当前工作范围依据；保密内容另保存原合资格审批人的真实批准，不从管理员操作推导已获批准。工作分配不解除保密限制，也不改写负责医生身份。资料负责关系失效后停止接受其新保密审批；既有批准仍须满足账号、当前工作范围及对象有效条件。

Roles & Permissions 按有效业务角色目录展示；Cashier 是功能、不作为独立可分配角色，历史 Cashier 角色引用须保留来源并另行迁移，不能静默改绑账号。其余有效基础角色按上述类别展示；已退役角色通过 Include retired roles 查看，不依赖是否已有集团模板历史；每项明确实际生效动作数量及来源（系统默认或集团配置）。角色目录和模板历史分别加载：历史读取失败时保留已验证的角色目录与动作，明确提示历史暂不可用，并禁用依赖版本的编辑／发布；角色目录本身失败则显示加载错误，不编造角色或权限。切换集团／身份时清除旧上下文结果，不将过期响应用于新集团。集团角色模板维护动作清单、草稿、变更影响预览及发布版本；只配置获授范围，不改变其他集团。模板不能解除医生签署资格、来源关系、隐私规则或 Closed 限制。全部 13 个批准角色可在各自权限上限内编辑，发布前展示影响及限制。新增岗位不扩大既有临床授权；停用和升级不恢复已撤销账号、服务关系或管理者调整过的权限。

4.7 登录、模拟与退出

登录状态检查： 登录页检查已有会话时，未登录响应表示继续展示登录入口，不弹出“unauthorized”错误。该响应仍不得建立会话或取得业务权限；实际服务器错误、网络失败以及其他接口的权限拒绝继续显式提示，保留既有日志和会话过期处理。 测试环境角色登录（2026-09-10 用户确认）不调用真实 SSO，沿用原壁纸和圆角角色按钮。选项来自后端配置的真实测试账号及有效岗位，选择后建立完整登录会话；Doctor 沿用该账号的 Provider 关联。登出后保持角色选择页，刷新不能进入虚拟 Super Admin；只有真实会话可自动返回桌面。角色入口及操作权限都按所选岗位计算。STG 可显式开启测试角色登录，UAT／生产不启用此入口。

STG 测试账号切换（2026-11-11 用户澄清）： 首次以获准的个人 SSO 身份进入 STG 后，在登录页的 Test account → Sign in 选择医生、护理等测试账号及有效任职，以该账号自身身份和权限登录，不使用 Assume Role。“Log out”结束当前测试账号业务会话、清除旧患者／岗位缓存与草稿，并返回同一账号选择页；保留尚未过期且仍在白名单内的 STG 个人准入记录。切换账号不再次启动 SSO，也不延长准入记录原有的 8 小时有效期。选择页的 End STG test session／结束 STG 测试会话 同时清除准入记录；准入过期或白名单撤销后仍须重新认证。每次账号登录轮换会话标识，审计保留个人测试者与所选业务账号的对应关系。未保存工作确认、在途写入保护及服务端权限检查继续适用。该机制只作用于已配置个人准入的 STG；不开放匿名准入，也不改变 UAT／PROD 或 IdP 策略。同日早先误加的 Assume“Switch role”快捷入口已撤回，原有管理员模拟功能保留。

Remembered sign-in email: The SSO email field restores the last valid submitted email from a host-only cookie on the same browser and environment for 180 days. The Remember my email on this browser checkbox starts enabled; clearing it immediately deletes the saved email, and an unchecked submission does not save it. HTTPS uses Secure and SameSite=Lax. Cookie access failures do not block sign-in. This preference stores no password, token or authentication state and does not bypass SSO. When sign-in follows a Docs link, the page identifies the destination while preserving the existing safe return route and filters.

SSO 当前边界： 用户资料目前只显示 SSO 关联状态和最近活动，无来源的 SSO／导入账号必须先由管理员关联真实管理集团、唯一业务角色和有效工作单位，才能取得业务入口。SSO 认证成功不代表拥有全集团权限，帐号停用、既有账号访问窗口、岗位日期、服务关系和临床授权仍分别生效。生产身份提供方、域名／租户、MFA、自动建号或自动停用、会话时长及并发登录限制尚未在本 PRD 形成已确认规则；在业务确认前不按行业惯例自动补齐。

AC-01：Assume 后，按目标角色和人员的真实权限操作。（2026-09-09 确认，2026-09-16 重申并补充）

Super Admin 进入 Assume 后，业务权限以所模拟的角色、目标员工及其当前有效岗位为准。页面、数据范围和每一项操作，都应与该员工在相同诊所、相同授权条件下直接登录时一致。真实登录人仍是管理员，但这一身份只用于会话管理和审计追踪，不能叠加到目标人员的业务权限中，也不能用于跳过任何角色限制或业务门禁。

进入、切换和退出 Assume 只改变发起者当前会话的有效身份；这些会话动作不改写正常角色模板、本人或目标员工的任职、权限、服务关系及执业身份，也不影响目标员工按原有效岗位正常登录使用。退出后按服务器返回的本人有效上下文恢复权限，不能保留目标角色权限或用前端缓存拼接权限。模拟中的实际业务提交仍按既有业务流程落库并审计，退出模拟不撤销已提交的业务记录。

完整功能测试须选择目标真实员工在该诊所／主体的有效岗位；Doctor 同时绑定其稳定 Provider。系统按目标人员的角色权限、诊所范围、当前工作范围、保密批准及记录状态共同判断访问和操作资格。Assume 本身不生成服务关系、临床授权或医生资格；“完整功能测试”或旧 unrestricted 标志也不表示无权限限制。目标人员／任职失效时停止该模拟，不能自动转绑另一任职或恢复为 Super Admin 继续当前业务。仅角色模板预览没有真实受益人，不能使用管理员身份补齐个人临床授权；只读预览仍须显式选择并明确标识。

UAT 的 Assume a role Centre 选项限定为 Central、H Zentre、Virtus Children 818、Virtus The Heart Clinic，对应既有 Center 编码；保留各 Center 下的有效 Site／Zone。其他 Clinic 仅从该测试入口选项隐藏，不停用组织、不删除历史记录，也不重写既有成员任职。STG／PROD 不应用此选项过滤。

模拟入口的组织与角色层级： Assume a role 的角色选项按业务类别 → 实际角色分组，沿用 Organization & Access 的现行角色目录及可分配规则。Center 与 Site／Zone 分开且并排选择；Site 默认 All sites，只列所选 Center 下的有效 Zone，切换 Center 清除旧 Site 和目标职员。模拟创建时在同一事务验证并保存 Site；Site 仅是视图筛选，不增加所选职员的临床权限，失效／跨 Center Site 不得替换既有模拟会话。

Assume 提交后，前端须核对服务端实际会话、目标用户、角色、工作单位与所选 Zone 均与本次选择一致；不一致时显示身份已变化并重新读取实际身份，不能将另一会话的结果显示为本次成功。此保护不替代服务端逐次鉴权。

弹窗采用较宽且适应窄屏的共享 AppDialog；权限模式的标题和较小补充说明分行，Read-only 明确显示为说明。图标用于标题、组织位置及权限区，角色分类和选项保持语义清晰。2026-10-03 该入口改动为本地实施，正式 STG／UAT 发布及验收另行记录。

护士拿到医生批准，仍然是护士。 医生批准只允许该护士在获批记录、模块、操作及有效期内协作，不会把护士变成医生，也不会解除其他护士门禁。Super Admin Assume 该护士后，必须得到同样结果：只获查看权时不能编辑；获草稿编辑权时只能执行已允许的协作动作，不能因此新增／修改药品、最终确认医生医嘱、执行 Billing & Finish、Review & Complete 或医生签署。具体协作范围沿用 问诊协作规则。能进入问诊工作台，不等于能执行工作台里的全部动作。

这一规则同时适用于菜单、页签、按钮、字段、数据读取和服务端接口。隐藏按钮不能代替接口拒绝；直接链接、手工接口请求、缓存的管理员权限和切换前的迟到响应，都不能恢复已不属于当前模拟身份的能力。授权撤销、到期、角色／诊所／人员切换后，重新计算权限并清除旧范围的数据和操作状态。目标角色原本允许的患者维护、本人业务、申请和管理等动作，也不应仅因 Assume 被额外禁止。

业务责任字段引用目标真实人员，访问及操作审计同时保留真实管理员、目标人员、有效角色／岗位、诊所、模拟会话、动作与授权判断结果。非患者个人文件的所有者、列表、上传去重、下载及删除资格同样按目标员工判断；退出模拟后恢复原人员的文件范围，不迁移文件所有者。患者文件继续独立按资料分类、来源和临床／隐私权限判断。

已知缺陷与验收边界： Assume 护士在取得医生批准后进入问诊工作台时，部分护士限制及门禁仍可能被绕过。这是需要修复的权限缺陷，不是管理特例；受影响接口、修复版本和目标环境结果必须单独留证，不能沿用其他 Assume 或护士授权测试的通过结论。

退出模拟： 退出本人有效角色模拟会话须验证真实登录、CSRF 和模拟会话归属；Doctor／Nurse 的目标角色动作上限不能阻止此退出动作。End 结束该模拟并恢复原有效上下文，不为目标角色增授管理或临床权限，既有退出安全审计保留。未修改身份的迟到请求只能续期，不能覆盖已开始或已结束的模拟会话，也不能复活已登出的会话。本人明确退出后，仍持有该旧模拟快照的请求不再具备业务权限，也不能清空刚恢复的有效岗位或覆盖随后开始的新模拟。会话或任职已经失效时继续沿用现有 401／409 处理，要求重新登录或选择有效上下文；本次不扩大失效会话的可操作范围。 等待选择岗位时发出的旧请求不得清除随后成功选择的新岗位，也不能执行业务动作；后续请求使用新有效上下文，已到期或撤销岗位仍按原规则失效。

统一切换保护： 正常岗位、Clinic／Center、Zone、进入／退出模拟和登出使用同一保护顺序：检查各已打开工作区的真实未保存及提交状态，完成其原有保存／放弃确认后，才暂停新业务请求、卸载旧身份的内容、取消旧读取并提交会话切换。任一工作区取消时保留原会话、窗口和草稿，不预先清空；并行切换不能互相覆盖。已发出的保存、签署或付款不可被切换伪装为取消、失败或回滚；提交结果尚未返回，或响应丢失后仍在回读确认结果时，继续阻止切换。回读失败则明确保留“提交结果未确认”状态及原请求依据，不能用 Discard 清除这一阻断；以服务器确认的结果恢复后才允许继续。

切换请求成功或失败后均重新读取服务器实际会话，再恢复获授权的工作区。接口失败不代表服务端未切换，也不能本地猜测回到原角色；恢复读取失败时停止展示旧身份业务内容，并提供重新登录或选择有效上下文的路径。旧身份的读取结果，包括迟到成功、权限拒绝、会话过期和网络异常，不得写回新页面、弹出旧业务错误或使新会话退出。未改变身份的普通请求及正常角色使用继续遵循原权限和错误处理。

会话隔离验收： 以下是要求验证的结果，不代表目标环境已经通过；正常登录与完整功能测试模拟须使用相同有效员工、岗位、单位／Zone、权限模板和对象状态进行对照。明确选择的只读预览继续受其只读限制，不以完整模拟的对照结果替代。

旧 Visit coverage 仅作为医生读取指定记录的兼容依据，继续检查医生身份、来源和有效期；它不授予草稿编辑、开单或签署权限。签署另行检查医生资格、具体签署动作及记录状态，不因能读取记录而放行。本轮固定记录的申请、审批及撤销按 §3–5 实施，本地验证边界见文末测试入口。模拟本身不会生成护理服务关系或医生授权；完整模拟中的申请、批准、撤销、保存和签署仍通过相同真实业务流程，固定记录目标及状态检查不变。业务责任字段引用所选真实人员，审计同时保留实际管理员、目标人员、登录和模拟会话；不把护士草稿保存记为医生签署。急诊例外仍待确认，未确认前不提供自动越权入口。

5. 保密内容申请、共享与撤销

2026-11-11 已确认： 护士普通问诊操作按 §3.1 的有效工作范围。护士发起的保密内容申请沿用对象审批，在获批对象及期限内开放查看及允许的修改。保密正文未获授权时，护士仍可完成范围内问诊，服务端原样保存正文。具体事务见 Consultation §2.4。旧批准、代改和签署历史保留。

5.1 对象与范围上限

申请来自可识别患者及真实记录，不能手输无来源 ID 扩权。保密 Note 和单份保密附件保持原对象粒度、合法所有者及审批关系；一份批准不将其他对象变成公共资料。独立敏感身份字段仍按其专门流程，取消保密标记仍按负责医生资格，不由内容批准附带。

护士使用批准须同时具备有效诊所任职、当前 Doctor Group 工作范围及对应业务动作。无需先配置与负责医生的服务关系；医生作为资料负责人／审批人的关联保留。其他医生的临床职责、范围和正式签署资格不因合并内容授权而增加。

无医生 Vaccination 的本人 Note 仍要求真实仅接种来源、当前有效工作范围及原有执行资格；不补造医生或批准人。原限定流程见 Consultation §7.4，普通问诊权限不由该例外产生。

5.2 申请、批准与生效

用户选择对象、用途及独立有效期后提交；记录属于不同审批负责人时按原规则拆分。申请未生效前不预加载保密正文、历史版本、转录、OCR 或 AI 内容。申请窗口保留未提交输入，关闭沿用未保存保护；提交中或结果未明时按原幂等键核实，不重建等价申请。

固定记录可以全部／部分批准或拒绝，部分批准只开放列明对象；原有持续范围保持合法记录范围和期限语义，但需要解除旧服务关系依赖，不能扩大护士当前工作范围。是否迁移旧持续配置及具体兼容策略见工程方案，不用删除服务关系记录替代迁移。

审批人必须符合原对象资格，不能批准本人申请、超出自身职责或扩大申请范围；管理员不伪造医生身份。医生主动为他人设置批准时同样保留真实依据。创建、决定、续期及撤销重验身份、源记录、当前版本和状态，重复点击及并发请求不得重复授权。

申请状态与批准生效状态分别显示：待审批、批准／部分批准、拒绝、取消；以及待生效、生效、到期、撤销或资格失效。界面显示原申请起止时间、当前授权期限及申请／决定原因，续期不得混淆来源。

5.3 授权管理界面

医生从 Requests & Approvals 处理本人有权审批的申请，并在「授權護士存取保密醫療問診資料」管理 §5.7 的主动共享。诊所选择只改变管理筛选。护士分组和排班由 §4.4 的独立界面管理。

待我处理默认 Pending，按提交时间及稳定 ID 升序；历史按决定时间及 ID 降序。列表一条申请一行，多个对象在详情展开，不按患者姓名合并。成功批准与真正生效分别显示；列表计数、分页、空态及上下文切换遵循共同列表契约。

5.4 匹配示例

小林当前在 A 的 Blue 分组工作。她可处理 Blue 内不同医生的普通问诊并完成签署；未获批准的 Note 不可读写。获某 Note 统一批准后可在该对象内查看和修改，但不取得同医生在 B 的问诊权限。调班离开 Blue 后不能因批准尚未到期继续访问 Blue；批准撤销而仍在 Blue 时，仅锁住保密内容。

5.5 撤销与范围变化

每次内容读取、修改、下载及响应发送前重查有效范围和批准；来源医生／诊所变化按原对象归属规则复核。批准到期、撤销或资格失效不删除历史；任职或排班恢复不能复活已经终止的批准。多个独立依据的撤销分别处理，但任何依据都不能越过护士当前工作范围。

固定记录续期只延长期限，不改变对象或批准人；原持续模式的时间语义保留，起止按精确区间计算，不能把无到期解释为所有未来记录均获批。正式交接、临时代诊及医生职责仍单独处理，不能由保密批准代替。

5.6 失败提示与迁移边界

提示应分别说明不在当前 Doctor Group、保密内容未批准、批准已到期、记录不可修改或真实加载失败，不返回无权知道的对象信息。模拟护理身份与本人直接登录使用相同规则，保留真实登录人与实际业务操作者。

旧 Read 继续只读。旧 Edit／Sign 的目标环境迁移及原待审稿处理仍需核对。最新本地覆盖见专项验证。

5.7 医生向当前 Doctor Group 共享保密 Note

2026-11-12 用户确认由医生选择授权类型，受益人随 Doctor Group 当值安排确定。医生以本人有效诊所任职操作，系统显示所属 Clinic 和 Doctor Group。有效工作范围与该组一致的护士可按规则访问。

医生填写原因，系统保存范围、级别和稽核记录。医生可停止共享，护士换组、下班或医生不再属于该组时，相应访问随有效范围收回。共享以原 Clinic、Group 和负责医生为限。单笔对象申请仍可独立生效。附件、签署和其它业务操作分别检查各自权限。

6. 桌面入口与配置管理

全平台价格与金额展示（2026-10-17 用户确认，含 I-012）： 处方、收费、目录、采购、库存成本、报表、票据及 AI 费用等金额统一固定显示两位小数，保留币种／单位语义。真实零值显示 0.00；未定价、缺失或无效金额显示「—」或原有明确的未配置说明，不转换为 0.00。不因展示舍入改写储存值、已签快照、计费金额或计算精度；允许四位小数的原始单价录入继续保留四位，并以原始值计算后按既有金额规则舍入。数量、用量、比例及体征不套用金额格式。实施及本地验证见本轮证据，不代表应用部署或 UAT。

6.1 App 目录

桌面、Start 菜单、搜索和移动端共享以下目录；角色只过滤可见 App／功能，不改变它的所属类目。个人设置作为额外全局工具入口。下表列出现有代码承接，不把入口整合视作每项业务均已完成或验收。

Laboratory Manager 通过 Laboratory Requests 只读查看所分配 Lab 的原始请求，实验室执行及报告仍在外部系统处理。未实现的通用 Workflow、Security、Numbering、Integration 等配置不新增假保存页，后续实际接入时归 System Settings 或各自业务 App。

保险目录管理（2026-10-23 修复）： System Administrator 的规范权限模板包含 benefits.read／benefits.manage，可打开 Insurance & Benefit Programmes 并维护卡样及 Policy；旧模板遗漏这些基础管理权限时不应让应用消失。模拟医生等身份仍按当前有效身份权限执行，不继承真实管理员的管理权。此修复不增加患者临床数据权限。

系统监控（2026-09-26 纳入实现）： System Monitoring 放在 Administration，与 System Settings 相邻，只展示基础设施状态，不承接目录、价格或业务消息。默认由真实系统管理员通过 system.monitoring.read 查看；运营管理员可以另行获授，不会因为运营身份自动拥有。模拟身份不能打开页面或调用接口。

页面在进入和手动刷新时读取已保存的快照，时间范围为 5 分钟、30 分钟、1 小时和 24 小时。刷新不会向云端发起查询，也不提供重启、变配、安装或云账号变更。页面显示环境、地域、所选主机或可用区、样本时间和收集时间。主机 CPU 是共享主机占用，不能表述成单一应用或单一环境的 CPU。共享负载均衡的流量不能标成仅 UAT。UAT 服务器组同时包含桌面与 H5。缺样本保持空缺，不显示为零，也不把内存或文件系统的缺失显示成 0%；代理未提供数据时显示需要代理。主机正在运行不代表应用程序可用。收集失败时保留上一份快照并标明延迟。监控读取失败不得阻断临床请求。

监控采集仍须部署已批准资源 allowlist 及对应采集配置；无 allowlist／无样本是配置或数据不可用，不因本轮界面修复宣称接通云端监控。工程依据、已核对的资源和收集方式见 System Monitoring 方案。本节不代表 STG／UAT 已部署或已验收。

账号管理收敛（2026-09-09 用户反馈）： User Accounts 是唯一以人为中心的账号维护入口，详情内包含 Profile & Access Window、Roles & Subjects、Effective Permissions；基本资料、独立职衔、所属主体、每个主体的角色任职、生效／失效日期与账号访问窗口在同一用户上下文管理；2026-10-02 用户确认多角色任职，以多角色任职为准，替代此前单角色限制。新建账号默认 Staff，允许显式选择 External；新结构化部门、专科及历史资料的保存边界统一见 §4.3，不再提供并行的自由文本编辑。只修改资料不得重置任职，单独修改访问窗口不得清空本次未修改的既有资料。Staff Directory、Role Assignments、Temporary Access 和 Effective Permissions 不再作为重复的平级目录；旧链接进入该用户维护入口及对应详情。Roles & Permissions 单独维护共享角色模板。临床记录的特殊访问通过 Requests & Grants 进入既定申请／审批／撤销流程，不能由账号编辑直接越权。Effective Permissions 是有效结果的只读解释；通用的单用户功能权限 Allow／Deny 例外尚未建立独立模型，本轮不将该查看页冒充例外编辑器。 2026-09-10 用户确认：新增账号的 User code 由服务器生成且后续只读，不接受客户端自定义编号。Department、Specialty 按 §4.3 使用各自目录和关联模型，保留旧值兼容，不将资料字段当作岗位授权。新增用户默认无账号到期日；日常期限配置位于岗位及具体数据授权，账号仍可停用。旧账号已设置的访问窗口保留并继续生效，不能因界面收敛恢复已失效账号。

6.2 共享配置与个人偏好

“集中入口”描述管理归属；“生效范围”由真实账户、集团／单位及业务对象决定，不表示每项都是全集团配置。

工作列位置（本地實施，2026-10-08）： Personal Settings → Display & Appearance 提供 Bottom／Left，預設 Bottom。Left 使用 180 px 寬的垂直工作列；選擇即時套用，按登入帳戶儲存在目前瀏覽器，不跨裝置同步，也不隨 Clinic、角色模擬或已命名桌面配置改變。畫面寬度少於 1024 px 時暫用 Bottom，保留 Left 選擇並在畫面變寬時恢復。切換位置保留開啟的 App、草稿及活動視窗，重新計算最大化／貼齊／浮動視窗的可用範圍；舊桌面配置載入時按目前範圍校正。Start、搜尋、工作列選單、桌面配置面板及 AI 側欄均跟隨可用範圍；瀏覽器不能儲存時明確顯示僅目前工作階段有效。此項本地實施不代表 STG／UAT／PROD 已部署或驗收。

Master 不因管理身份获得 Cashier／诊所配置或病历权限；WDL 仍仅显示自身业务 App 及个人设置。管理入口按具体会话模式与服务端能力过滤；完整真实目标模拟不继承原管理员范围，审计读取继续执行真实非模拟身份要求。App 内所有写动作继续服务端独立校验。

6.3 启动、旧入口及权限变化

启动与登入故障恢复： 应用模块载入前已有独立的载入提示；长时间未挂载或模块载入失败时，明确说明尚未完成并提供人工重新载入。已开启工作区发生分块载入失败时，提示先保存草稿，可关闭提示继续处理现有页面；不自动刷新、不清除患者草稿或改变认证配置。只有前端已收到页面且提示资源可用时才具备此恢复能力，不能据此证明外层网关、HTTP Basic 认证或代理故障已解决。

登入分别报告认证模式读取、业务会话检查及测试任职目录三个阶段。只有业务会话检查的正常匿名 401 允许继续显示已核实的登入方式；认证模式失败不得默认成 dev 或沿用旧身份选择。测试任职有独立的载入、成功、失败与重试状态，成功空结果才显示没有有效任职；401、403、服务故障和网络失败不归类为空目录。重试清空陈旧任职选择，页面卸载或后续初始化使迟到响应失效。保留 backend-authoritative local review／dev／SSO 分支；环境网关认证与业务登入分别说明，不要求前端收集或保存网关密码。

员工入门介绍： /docs/get-started 是独立、可在登入前阅读的介绍页，从登入页、Start Menu 及产品资讯页进入；/docs/get-started/doctor、/docs/get-started/frontline-staff、/docs/get-started/back-office 分别提供 Doctor、Frontline Staff、Back Office 的第一步、常用工具和典型交接流程，支持现有英文／繁体中文语言选择。/docs 首页打开公开 Get Started，入门页与须登入的产品更新／操作指南共用左侧 Docs 导航；旧 /getting-started 及角色链接转到对应新路径，并保留查询条件及锚点。这三类是阅读指南，不新增业务角色、改变任职或授予权限；实际 App 和对象访问仍按既有角色／工作范围授权。介绍引用用户提供的「3 大照护领域、6 项 AI 能力、1 个统一平台」框架，说明 Clinic Operations、Lab & Imaging、Pharmacy & Medication 及六项能力的产品方向，不宣称所有能力已启用或上线；实际更新和限制链接到须登入的 Change Logs／Known Issues。介绍页不请求患者资料，也不强制首次登入跳转或记录培训完成状态。

共享 appDirectory.mjs 维护类目、顺序及归属，virtusOsApps.js 维护稳定 App ID、组件与角色范围，managementNavigation.mjs 维护管理子页所需能力。增加入口时必须同时具备实际组件、归属及入口权限；各客户端不得独立复制类目。旧 settings 管理子页转到 Organization & Access／Audit & Review／System Settings；旧 Catalogue 的 packages／coupons／contracts 转到对应独立 App；旧 admin-units／admin-audit-trail 分别归组织／审计。转换后按目标 App／页签重新授权，保留上下文但不恢复无权限组件。已撤出的通用占位配置最多回实际 System Settings 首页，不冒充完成的配置项。

用户要求直接清理重复与无用入口，取代 2026-08-27 的“所有 Shell 保持可见”策略。一个业务目的保留一个实际工作台入口；专用组件只表示已有基础，不等于完整实现或验收。真实会话的桌面、任务栏快捷入口、开始菜单／搜索、移动目录、直接链接和保存布局使用同一授权 App 目录：当前工作场景及角色允许该 App，并具备该 App 入口所需的有效权限，才显示且允许打开。无入口读取权限时隐藏图标，不先显示再等用户点击后报无权限；新 App 未配置入口规则时默认不显示。App 内具体写动作和业务对象访问继续由服务器分别校验，显示入口不自动授予写入或跨患者／单位访问。

队列角标的后台轮询（本地验证通过）： 只在真实会话及当前业务任职已就绪、具备队列所需读取权限时运行；Master、Super Admin、未选岗位、会话切换期间及合成静态预览不自动请求该业务队列。切换身份／诊所后取消旧请求并清空旧角标，迟到响应不得恢复上一身份的数据；同一身份不重叠发出轮询。服务端拒绝当前身份后停止该身份的重复请求，待有效上下文刷新后重新判断。此限制只约束业务队列角标，不关闭系统健康检查，也不替代服务器对统计范围与临床权限的校验。

2026-09-08 用户确认： Doctor 不应看到无权进入的 Central Pharmacy。角色模拟及 unrestricted functional test 也按所选岗位筛选 App，不将“功能测试”变成全 App 目录或把后台组件冒充 Super Admin。已保存布局、旧 CP 别名、缓存 App 对象及手机本地角色选择均不能恢复无权入口；角色／权限变化后撤下图标及不再授权的窗口，仍获授权 App 仅按 §6.5 恢复布局并重建内容。未取得真实会话或未选角色时不以本地存储的 Super Admin 兜底。

只有明确的合成开发预览可展示全部已实现 App；预览不是账号授权证据。用户配置、角色模板、授权及审计已有实现基础，实际覆盖以对应记录为准，正式业务 UAT 尚未完成。Organization & Access、Audit & Review 与 System Settings 的子入口都按当前有效能力过滤；Personal Settings 是全局个人入口。 2026-09-10 用户确认：Clinical 默认以 Patient & eMR 为首个 App，其后为 Appointment Calendar 和 Reception；排序不改变角色可见性或访问权限。

旧 CP／库存 App ID 统一为 central-pharmacy-warehouse，保存布局按 canonical ID 去重，并继续检查目标角色是否拥有入口。被撤出的无替代壳不恢复成窗口，移动旧路径回目录。原需求仍可由仓库和 PRD 追溯，不能从 More 或搜索重新出现。

CP 操作根据服务器会话的 cp.warehouse.read、cp.po.read/create/submit/approve/send 判断，不依据图标或角色名称授权。现有代码中 Staff 可创建／提交，PIC 可审批／发送，PIC 不继承 Staff 写权限；目标采购的 PIC → Finance 两级审批及三人分离以 CP 功能方案为准，不能把旧动作映射当作新流程已完成。Restricted support 禁止写操作；无 PO read 不发请求，失败明确报错，不伪装为空单。公开静态预览没有真实 CP 会话时显示访问不可用，不注入模拟库存或自动取得权限。

桌面入口收敛和权限呈现不代表 Central Pharmacy、跨地点库存流水、诊所库存或业务 UAT 已完成。

6.4 收费与药房入口分工

Cashier 展示本次药房进度及阻断原因，供工作人员判断开票／结算条件；药品审核仍须在获授权的 Drug Dispensing 工作台完成。Frontline Staff 与 Clinic Manager 在所选有效诊所任职范围内可执行处方审核、标签、备药及发药（pharmacy.review、pharmacy.label、pharmacy.pack、pharmacy.dispense），用于完成结算前的药品确认及后续流程。现有处方版本、付款、库存及独立最终核对规则继续执行；权限不替代这些业务检查。Cashier 的显式 Return to Consultation 仍是独立就诊回退动作。

启动及布局恢复都以当前角色的有效 App 目录重新核对，缓存中的旧组件、旧角色或显示属性不成为授权依据。通用 App 预览的可见性不代表 Nurse／Reception 的真实目录获得权限。

Pharmacy Staff 独立 App 边界（2026-10-19 用户确认）： 诊所药房岗位（含旧 pharmacy 及现行 pharmacy-staff）开放 Clinic Dispensing Unit、Drug Dispensing、Tasks & Notifications 及个人 Settings。2026-10-29 用户确认 Patient & eMR 入口亦可开放，并保留在权限管理中配置；此项取代 10 月 19 日对该 App 的固定禁止。Patient & eMR 继续依据有效 patient.read 权限及已发布 App／Tab 显示配置投影，不强制显示或绕过隐藏配置。Consultation、Reception、Clinical Documents、ICD Mapping、eMMS、Clinical AI Copilot 及其他非药房独立 App 不因共用读取权限自动开放。此规则覆盖桌面、程序清单、移动目录、直接链接及保存窗口恢复；正常登录与 Assume Role 使用相同岗位边界。患者姓名在无 eMR App 准入时显示为普通文字，不提供失效的跳转。

药房在 Drug Dispensing 当前患者／处方上下文中继续读取患者身份、处方、过敏与警示；获准打开 Patient & eMR 时沿用原有数据 API 的患者／Visit、集团／诊所及记录保密授权，保留所需 patient.read、clinical.read 及药房动作，不新增临床编辑、签署或开处方权。App 准入与数据 API 权限分开控制：本次入口收窄不等于删除原患者读取权限，也不新增或扩大后台患者／Visit 范围；接口仍须独立核验现有角色、集团、诊所及记录授权。验证证据见 Pharmacy Staff 入口边界。

实现边界： 本轮只调整前端 App 呈现、启动与窗口恢复，未迁移后端历史 pharmacy.dispense 授权或角色种子数据。不能把前端不可打开表述为这些角色的药房 API 已统一禁止，也不扩张真实药房或其他角色的后台权限。真实数据库／浏览器交接使用分别登录的 Nurse、隔离数据库内合成 Pharmacy 操作员及另一位实际 Pharmacy Checker，避免以一个护士会话冒充跨岗位验证。

目录、缓存启动、角色切换清理、医生筛选及跨角色交接已在精确提交 a8e8b802d3738f1e6ce025af9b3a274a2814ab94 完成隔离回归：CI 34091809502 的后端、前端、浏览器与清理检查全部通过。本条不代表生产权限迁移；真实后端部署与业务 UAT 仍未完成。

6.5 桌面恢复与共享配置对象

工作区启动（2026-10-24 用户确认）： 普通登录、重新登录或刷新进入 OS／Clinic View 时，初始没有打开的 App／业务标签页，不自动恢复上次窗口或按角色打开默认流程；历史自动保存布局不得触发启动，也不得用迟到响应覆盖用户已主动打开的窗口。保留用户的 OS／Clinic View 偏好及命名布局，只有用户主动打开 App、手动载入命名布局或访问明确指向某 App 的链接时才打开对应应用。会话与布局目录处理完成后进入 Ready；背景连接及待办角标检查不构成打开 App。

身份、岗位、单位、Zone 或有效权限变化时，以服务器实际会话重新授权；用户主动切换先执行 §4.7 的保护，服务器已撤销的权限则立即停止使用，不能等待草稿确认而继续展示无权内容。已打开且仍允许的 App 只保留位置、大小、最小化／最大化及活动窗口等非业务布局，创建新的内容实例；旧患者／Visit、草稿、查询结果、附件引用及 launch context 不随布局恢复。即使新旧身份均可打开同一 App，也不能沿用旧实例。转换中暂停布局自动保存；取消主动切换不破坏原布局。此身份隔离不同于 §6.7 同一身份下的 OS／Clinic View 切换，后者继续保留持续工作区。

OS View 窗口打开与关闭： 普通应用入口只打开或聚焦目标应用；共享患者／Visit 的恢复、刷新和窗口列表变化不自动补开 Patient & eMR、Consultation 或 Cashier。已关闭的窗口保持关闭，除非用户再次明确打开或主动应用包含它的布局。View Billing、患者姓名／Visit 链接及 Layout 的并排排列仍可明确打开关联应用，并沿用现有权限和未保存／进行中操作保护；窗口关闭不改变就诊、签署或付款状态。Clinic View 的显式参照面板及已打开应用间获授权的患者同步继续保留。

返回队列或关闭 Consultation／Patient & eMR 遇到未保存草稿时，提示“离开目前工作区”，提供保存草稿并离开、放弃修改并离开、留在当前工作区；此动作不改变共享患者选择。真正选择另一患者时继续显示患者切换确认及目标身份，不用空的目标患者提示表示关闭动作。

返回患者目录： 从问诊队列打开 Patient & eMR 后，返回搜索须同时清除当前患者和窗口保存的来源记录上下文；恢复窗口或重新打开目录不得再次选中旧患者。返回后迟到的患者资料响应不得重新打开该记录。

配置归属及影响范围以 §6.2 为准：Organization & Access 维护主体及授权，System Settings 维护跨页面共享配置，Personal Settings 汇总个人偏好，业务主数据在所属 App 维护。个人布局／密度只保存非临床参数。Provider、员工 User、Service Resource、Room／Equipment 分开；同名医生不能成为身份关联依据。

6.6 版本資訊與問題回報

Build diagnostics 与正式 release 分开： System Information 可分别读取当前前端建置和服务器程序的环境、实际注入的提交标识、来源指纹及建置／程序启动时间；未记录值明确留空，不从本地 Git HEAD 猜测。服务器诊断只向已认证身份提供，读取失败可单独重试；前后端已知提交不同提示核对部署配对。指纹只用于识别当前两侧来源，不等同正式版本、部署成功或业务验收，STG 仍不生成 UAT／PROD 的正式 release 号。

Getting Help 的一般 Release notes 入口打开独立 Docs 页；保存布局／旧链接中的内嵌 releases 入口安全回到 System information，不自动重建旧面板。只有具发布资格者通过明确的 Manage release notes 动作进入原管理流程，保留草稿、发布权限与历史记录。

UAT 與 PROD 的桌面 Start Menu 顯示目前 CLIP YY.MMDD.NNNNN 版本及系統資訊；日期採香港時間，尾碼為五位隨機數。版本在 UAT 發佈時分配並綁定合併提交，PROD 接受同一 UAT 版本，不在 STG 顯示正式版本。使用者從 System Information 的 Change Logs、Known Issues、Wish List 連結開啟獨立瀏覽器頁面；頁面沿用登入及有效帳號驗證，不套用 OS 桌面或 AppWindow。Start Menu 的 Change Logs 同樣開啟獨立頁面。既有版本登記及管理保留；平台管理員在部署檢查完成、版本登記後撰寫並發佈目前版本的更新內容。未發佈草稿不向一般使用者展示。

System Information 在开发／STG 未配置正式版本时显示预期空态，说明“未配置正式版本”，继续提供可取得的浏览器、作业系统、屏幕、页面路径和时区等排障资料及复制功能。服务明确返回未配置版本，与当前部署未提供服务器诊断能力分别说明，不把两者当作一般业务故障反复弹错；真实服务器或网络失败仍显示读取失败并允许重试。版本、环境及提交标识只展示实际取得的 metadata，缺失项标示未记录，不以本地 Git HEAD 或示例值补造。验收分别覆盖未配置正式版本、诊断能力不可用、实际服务失败及有真实版本资料四种状态；浏览器资料可用不代表服务器版本已核实。

已登入使用者可從 Start Menu 擷取螢幕、檢查截圖、畫筆註解或遮蓋敏感區域，輸入問題與預期結果，亦可選擇英文（香港／美國）或中文（香港／普通話）口述後編輯轉錄文字。提交時收集瀏覽器、作業系統、螢幕、頁面路徑、時區與版本等排障資訊；不收集登入 Cookie、URL 查詢參數或原始錄音。截圖完成註解及遮蓋後，提交前轉為 JPEG（品質 0.7），透明背景鋪白；壓縮後最多 8 MB，既有 PNG 報告仍可查看。臨床附件保留原件，不套用此截圖壓縮。截圖以私有物件儲存在現有 OSS bucket；提交後報告、截圖及轉錄按目前決定長期保留。本人在 Getting Help 的「我的報告」查看自身報告；獲授權的內部 Support Team 或 Super Admin 從 Administration 的獨立「Support Queue／支援佇列」App 查看、留言及更新處理狀態。Getting Help 保留問題提交、本人報告、系統資訊及指向獨立 Docs 的版本更新連結，不再內嵌支援佇列。支援佇列表格按最新提交排序，顯示提交時間、提交者、標題、描述、狀態及版本，並可分頁及開啟截圖、語音轉錄、排障資訊與處理紀錄。外部帳號只可查看自身報告；代入角色情境不可進入問題回報與管理流程。正式上線仍須按發布流程分別驗證與驗收。

Standalone product records are managed in PostgreSQL: structured issue/wish/change rows, Centre/topic metadata and bidirectional change links. SQL performs filtering, counts, sorting and page retrieval; JSON remains an insert-missing migration seed. Repeated seed imports preserve database edits and votes. Record changes have database audit history. The same dedicated support DSN can share content and votes across STG/UAT/PROD; isolated databases remain supported. This local implementation does not establish shared-store provisioning or environment release, Known Issues allows active internal staff with support.issue.manage to edit title, description, priority, status, response/current evidence and a duplicate-of issue link. Status choices remain Awaiting verification, Open, Investigating, Implemented · acceptance pending and Solved. Duplicate marking is independent of resolution and retains the original record; links must target another canonical issue and cannot form chains or cycles. Signed-in active users can add plain-text comments to individual issues. Assumed identities cannot edit or comment. Each edit retains the authenticated account identity/name, timestamp and before/after details in the database audit history; comments retain their author and timestamp. Updates use a record version to reject stale overwrites. Histories and comments are paginated and readable by the same signed-in audience as Known Issues; no private support-ticket details are copied into this catalogue. Standalone product information uses English and server-side pagination (10/20/50 records per page), search, Centre short-form filters and stable deep links. The shared AI-CLIP Docs layout places Get Started first, then Modules, Workflows and Configurations, followed by Product Updates (Change Logs, Known Issues and Wish List). A persistent desktop left sidebar groups guides beneath their section and topic; mobile navigation starts collapsed and can be expanded with an accessible menu control. Page content occupies the right-hand area. Canonical update routes are /docs/change-logs, /docs/known-issues and /docs/wish-list; /docs/ opens Get Started. The short /known-issues link redirects to /docs/known-issues. The existing /support and /support/changes|issues|wishlist links redirect to their corresponding Docs routes, preserving filters, pagination and fragments. Real-login checks and safe login-return targets cover the canonical Docs routes; Getting Started retains its public access as specified in §6.3. Known Issues uses P0 = Blocker, P1 = Critical, P2 = High, P3 = Normal and Unsolved / Solved / All filters. Wish List has no priority column; it offers Pending / Completed / All and one removable vote per signed-in person per wish. Assumed identities cannot vote. Both lists label the column Status. Original CB and Vertue requests display CB and Vertue respectively as source Centre; CB reporting dates remain unknown and Samuel confirmed the Vertue conversation date as 7 October 2026. Existing VTE filter links remain supported; applicability to other centres is not inferred. Vertue intake retains all 46 original item numbers, with 20 provisional issue-verification items and 26 wishes. Meeting descriptions are not proof of defects, delivered features or acceptance; provisional issue priorities and Awaiting verification remain explicit. Project-history entries are labelled Project. Related implementation is not automatically treated as resolution or acceptance. Heart Clinic intake preserves all 35 original item numbers as 13 provisional issue-verification items and 22 wishes, with Source shown as Heart Clinic and source-Centre label HC (Heart Clinic). Samuel confirmed the Heart Clinic conversation date as 8 October 2026. HZ intake uses the supplied meeting date of 8 October 2026 and Source / source-Centre HZ; all HZ-001–HZ-077 references remain searchable. The two HZ-065 login failures have separate issue IDs and require separate verification. HZ issues remain Awaiting verification with provisional priorities; wishes have no priority, and meeting responses do not establish delivery or acceptance. The supplied memo and English classification are retained in HZ source intake. The routine profile-edit reason request links to recorded implementation C-051 without claiming Heart Clinic acceptance. All issues, wishes and changes have reviewed topic tags with readable labels. A tag filter composes with Centre, search, status, priority and pagination; Change Logs activity uses the same topic scope across all matching pages. Search also includes source names and tag labels. Expandable rows show the full requested behaviour, original source item, response/current evidence or change benefit; source artefact paths stay out of the staff detail view.

Change Logs uses readable cards below 768 px and a compact table on larger screens. The table combines ID, date and page/area into one column; Changes contains the full change text, compact coloured topic badges and linked issue/wish badges; Benefits remains a separate column. Related-record lists initially show six links, with an explicit more/fewer control to access every linked ID. Colours distinguish topics and record kinds without implying priority or completion. Both views preserve evidence labels, linked records and server-side pagination; the result summary shows the visible range and total. The activity chart always shows the previous seven complete Hong Kong calendar days, excluding today, with no week-navigation controls. Topic/Centre/search scope still spans all matching pages, and selecting an older or current-day table filter does not move the chart window.

Staff documentation adds authenticated /docs/modules/:article?, /docs/workflows/:article? and /docs/configurations/:article? routes outside the desktop shell. Modules follows every app in the canonical directory and retains its Clinical, Pharmacy, Business Operations or Administration grouping. Workflows describes cross-module tasks and handoff outcomes; Configurations describes the supported settings, ownership and scope. English articles contain audience, prerequisites, ordered steps, expected results, limitations and related guides, with search and stable article URLs that resume after login. Configuration guidance does not expose credentials or live environment values, change settings, grant permissions, or imply planned features are deployed. The versioned catalogue is read-only and travels with normal code promotion through STG, UAT and PROD; guide versions can differ when environment releases differ. Canonical domain PRDs remain authoritative; the staff documentation structure records article provenance and maintenance rather than introducing a parallel business specification.

Change Logs uses ID | Date | Page / Area | Changes | Issue or Wishlist ID | Benefits. Curated history starts on 1 October 2026, with original source headings and engineer attribution retained internally. Above the table, an Apache ECharts daily bar chart shows the selected Monday–Sunday week, recorded-update total and active-day count; previous/next controls browse available weeks. Counts cover all matching entries across pagination, following Centre and search filters. Selecting a bar or its keyboard-accessible daily total filters the table to that recorded date; users can restore all dates. Each row labels its delivery evidence and links bidirectionally to issues/wishes. Dates are recorded change dates; local implementation, recorded configuration/data operations and recorded deployment remain distinct. Private report text, patient data, screenshots and diagnostics are not copied into this catalogue.

The curated catalogue is version-controlled in varclip_flask/src/data/support_portal.json and follows the normal dev/samuel → STG → UAT → PROD promotion. IDs are permanent and must not be renumbered when rows are added or moved between lists. Votes use a separate PostgreSQL table; STG/UAT/PROD can share a dedicated support store via VAI_SUPPORT_PORTAL_DATABASE_DSN, using a server-derived hash of the normalised account email rather than environment-specific numeric user IDs. See support-store installation. No live shared store is established by the presence of this implementation.

6.7 Clinic View：共用 App 的固定診所檢視

目的及範圍： 為偏好傳統固定導覽的診所助理及醫生提供另一個呈現方式，首階段支援桌面及 iPad；未來手機適配沿用同一組 App／模組。OS View 與 Clinic View 共用 App catalogue、元件、工作流程、驗證、API 和同一個持續存在的 workspace owner。修改 Consultation 一次即可影響兩種檢視；不複製診療、配藥或收費實作，不新增後端權限或資料庫規則。

資格及入口： 依登入後目前選定的診所任職判斷。Frontline Staff、Reception、Nurse 使用助理版；Doctor 及既有 GP／Specialist／Surgeon 任職使用醫生版。實際 App／Tab／動作仍由現有權限及顯示配置決定。桌面沒有有效偏好時先進入 OS；合資格者從 Start Menu 的 Switch to Clinic View 切換。既有 iPad chooser 加入 Clinic View；Clinic header 提供 Switch to OS View、Help、診所／角色、Zone 及帳戶操作。

固定安排：

Consultation 的既有 PatientSafetyBanner 移到共用位置，eMR／Billing 參考區不再重複周邊 banner。歷史記錄瀏覽不改變 active Visit；Appointment／Reception 選取及交接仍使用原規則。普通 App 只有一個掛載實例；附件工具保留既有多實例例外，Clinic contextual page 顯示目前實例並提供返回操作。Drawer 沿用 Element Plus 的焦點與關閉處理；觸控裝置使用足夠控制高度。

切換契約： 所有入口使用同一個 requestViewSwitch。檢查登入、選定任職及當前權限；儲存、簽署、付款、任職切換或 blocking dialog 期間禁止切換並提示原因。阻塞原因提示只在目前檢視仍受阻時顯示；解除阻塞、切至另一檢視或 Back／Forward 後必須移除舊提示，不得留下與已可用操作矛盾的浮層。先載入 Clinic layout，再確認身份與 busy state，最後才更新 route 和偏好。載入／導覽失敗保留原檢視與偏好；儲存偏好失敗仍可在記憶體繼續使用。

OS 的 /virtus_os/desktop/、Clinic 的 /virtus_os/clinic/:section? 及 iPad chooser 共用持續 workspace。切換只改 AppWindow 的固定位置、可見性和導覽，不送出新的 launch context，不 reload、不卸載 editor、不呼叫 save／sign／payment。Patient／Visit、草稿、錄音歸屬、篩選、捲動及 pending work 保留；真正切換患者仍經原 unfinished-work guards。隱藏工作區不攔截快捷鍵；回 OS 使用原窗口幾何並聚焦當前流程。

啟動及導覽： 偏好只儲存 view，以使用者及 active role 作 key；患者復原沿用原 ID-only 機制。iPad 沒有有效偏好時顯示 chooser；明確 URL、登入／SSO 返回及 Back／Forward 依同一套切換檢查處理。未選擇流程且 URL 未指定 App 時保持空白並提示選擇 App，不採角色預設流程；獲准但不在固定導覽的 App 以全寬 contextual page 開啟。帳戶／clinic／zone／role 改變時沿用既有失效機制，重新核對資格；失去 Clinic 資格返回 OS 並提示。現有手機 routes 保留。

本地實作與 focused checks 的證據寫入變更日誌；桌面／iPad browser acceptance、STG／UAT／PROD 部署另行記錄。

7. 审计查询与异常复核

功能目的： 让获授权人员知道谁以什么身份访问或修改了什么，并处理需要解释的异常。访问审计、操作日志、账号历史和异常复核各有自己的动作及数据范围，均不授予临床正文权限。

操作顺序： 查询事件 → 查看来源和授权依据 → 必要时认领异常 → 记录说明及结论 → 关闭；原事件不可由复核改写，系统不把异常标记直接认定为违规。

7.1 事件查询

Operation Logs 时间来源： 已有时区的时间才可作为确定时点转换显示；历史无时区 TIMESTAMP 保留记录的日期／时间，明确标记来源时区待核实，不附加 UTC／GMT 或按浏览器时区推断。旧服务器未提供可验证时间依据时提示核实，缺失值显示未记录。当前数据库会话时区不能证明历史写入时区；STG 历史来源尚未核实，本轮不修改历史记录，也不把展示修复表述为统一历史时区已完成。

AU-01： 按时间、当前授权范围内的 Clinic、Actor、动作、对象、结果或来源筛选；详情包含真实操作者、有效身份／角色、当前工作场景、来源 Clinic、患者／Encounter／业务对象、时间、原因、前后值／版本及结果。权限相关访问同时保留 session／request、策略版本、授权与服务关系依据；跨角色和跨诊所会话仍能归并到同一真实人员。敏感字段按查看权限脱敏，审计不复制完整临床正文。

需要覆盖登录／权限变更、人员服务范围、负责人指定、申请／审批／续期／撤销、身份搜索、病历与附件实际读取、拒绝尝试、下载／导出、患者更正、Consent、问诊签署与修订、处方／Order、文档输出、价格／折扣、Invoice／Payment／退款、主数据发布及适用 AI 调用。成功读取、被拒绝、搜索和输出分开计量；当前 Chit activity 只显示本次就诊事件，不代替系统级审计。

审计开启时，访问元数据独立持久保存实际操作者与有效身份、来源／当前诊所、动作／结果、患者与资源引用及授权依据。Access Audit 工作台可按实际人员、结果及已识别患者过滤并查看详情，实际人员／结果筛选与事件详情已通过本地浏览器验证。临床正文不进入事件载荷；未知、不存在或跨集团拒绝目标不伪造资源外键，保留安全的动作／原因信息。事件落库或同步检测失败时返回明确失败，不发送资料；审计期间账号、任职、服务关系或授权失效也须在发送前拒绝。版本差异完整展示、审计导出治理和其余业务入口仍须各自核验，不以本轮钩子覆盖全部未来模块。

有效的仅角色模拟可以没有目标医生／人员：审计保留真实管理员、模拟角色、原登录及模拟会话，目标人员字段保持空值。写入前须核对完整、仍有效的会话绑定；不能为补齐审计字段把管理员当作病历责任医生，也不能因未选择目标人员而阻断原本获允许的运营查询。选择了具体医生时仍记录该目标，病历归属和动作资格继续独立检查。

测试阶段开关（2026-09-09 用户确认，已实现并完成本地自动验证）： 服务端环境配置 VAI_ACCESS_AUDIT_ENABLED 默认开启。只有 VAI_ENV 明确为 local、development、dev、test 或 preview 时允许设为 false；其他环境，包括 STG、UAT、production 以及缺失或未知环境名，均保持开启，非法开关值也保持开启。通过服务端 .env／部署配置控制，启动时对实际关闭状态记录 warning；GET /api/auth/mode 返回 access_audit_enabled 供核对，不新增用户界面或客户端切换入口。

允许关闭时，跳过新增访问事件采集、持久化及该层同步异常计算，也跳过 HTTP 审计层的附加来源／引用校验和返回前重复复核；业务处理返回原响应内容及状态，不因这层审计失败阻断测试。医生／护士在业务服务中的真实身份、集团与资源范围、服务关系、固定 Visit 授权、签署资格、版本及事务校验仍执行。登录与模拟退出、授权管理、病历签署、财务变更等既有安全／业务审计仍保留；开关不删除旧事件、授权决定或业务记录。默认开启模式继续执行前述失败拒绝契约，关闭模式的通过结果不能作为严格审计及异常检测验收。

Operation Logs（本轮本地实现）： 独立于 Access & Permission Audit 列表，读取现有持久化安全／业务审计和已记录的业务操作日志，可选择来源、刷新及向前翻页。展示时间、操作、结果、记录操作者、岗位、对象引用、来源单位及请求引用；不返回请求正文、自由文本原因、前后值或加密临床载荷。现有操作日志未完整记录模拟身份时不推断真实操作者；旧日志无可验证来源单位时不向前端返回，不按用户当前任职反推历史来源。两类日志是既有覆盖范围，不能声称覆盖全部业务动作。

该读取入口要求真实非模拟身份、access.audit.read、有效任职及当前集团／来源诊所审计范围，与 Access Audit 共用范围策略。Account & Sign-in History 沿用现有 admin.users.read 查询权限；这是现有账户历史能力，不等于其持有者获得操作或病历访问审计权。Alerts & Reviews 继续要求 access.anomaly.manage。系统集中审计不替代 Catalogue、Cashier 等对象页内的业务变更历史。

7.2 复核与导出设计

查阅审计不应更改原业务记录；发现问题应回到相应更正流程。错误或空结果不显示样本审计事件。

7.3 可配置异常识别与复核

AU-05（用户确认）： 对同一护士频繁访问大量患者资料的情况进行异常标记，判断规则可配置。以真实人员跨会话的实际行为和不同患者数量统计；一个患者的多 Tab、刷新或重复请求不等于访问了多个患者。搜索、临床读取、附件下载／导出及被拒绝尝试分别计量；规则不能只依靠账号上的一个异常布尔值。

访问审计开启时，检测随真实访问事件落库同步执行，以当前已发布版本计算，没有后台常驻检测器，也不从内存计数推导完成。 首批异常计数只包括实际允许且暴露患者信息的事件；拒绝／失败尝试保留原始审计，但独立拒绝频率、无工作关系指标和导出频率组合规则仍待扩展。规则窗口从其发布时刻开始，之后按滚动窗口计算。单个告警的触发证据和计数不因后续刷新改变；同一时间分段关闭后再访问不会产生第二个告警，下一分段的新事件会重新计算。更精细的连续异常合并／重开政策尚未确认，不能宣称实时追踪一个持续更新的异常案例。

按 §7.1 在测试环境关闭访问审计期间，不产生新的访问事件或由其触发的异常。已有事件、规则及异常仍按管理权限查询和复核；恢复开启不会补造关闭期间的记录。该时段没有告警不代表没有异常，也不能用于评估正式阈值或检测完整性。

具体数值阈值、复核责任人与可采取的限制措施仍待业务配置／确认。表单不预填时间窗口和计数阈值，草稿不参与检测，只有经有权人员明确发布的版本才启用。建议默认只标记和发起复核，不自动中断当前临床工作； 自动暂停、重新验证或紧急例外须另外明确规则。未配置有效规则时不能把无告警当作已证明无异常；合成演示或测试阈值不作为正式业务值。修改规则保留旧版本和原命中依据，复核无权改写原病历或删除访问事实。

套餐账户与交易权限

套餐动作独立校验：维护／发布 package.setup 仅属于 Super Admin／Clinic Manager 管理岗位上限，护士、医生、AHP、普通前线、运营及财务人员不能经旧授权或角色模板恢复此项；集团共享仅集团 Super Admin 维护，诊所专属仅所属诊所经理及本集团 Super Admin 在对应范围内维护。Setup、版本及服务组件执行相同套餐门禁；普通人员不展示该界面。尚未执行角色模型切换的旧 clinic-admin（界面名称 Clinic Manager）同样承接本诊所套餐设置及预约容量默认权限，保留原岗位身份；不全局替换角色或扩展其余权限，角色模型切换后已退役身份仍禁用。旧经理的这两项兼容默认也保留明确角色／策略拒绝及停用限制。Clinic Manager 默认具有 package.setup：既有角色／已发布策略遗漏时继承默认；明确角色拒绝（未启用集团策略时）、策略拒绝／非法边界或动作停用不被覆盖，权限编辑器投影与运行时一致，不改写已发布策略历史。预约容量独立使用 appointment.capacity.manage，默认授予 Clinic Manager／Super Admin，入口位于 Calendar，使用预约类当前诊所范围；它与套餐设置可分别禁用，不相互授予或撤销。Super Admin 的设置目录与医生名单使用独立配置读取，不附带患者套餐查询权。销售 package.sell 加患者资格；账户查询 package.read；成本、分摊、付款与凭据 package.finance.read；普通服务实际完成登记 package.consume 加当前 Visit 的临床／已授权运营操作资格（Assume 禁写），不因已签署而要求重新编辑病历；预约另需既有预约权限；退款沿用 billing.corrections.manage 及原 Invoice 范围，不新增审批角色。自动接种／Lab 核销使用原执行权限及有效套餐覆盖，不向临床角色隐式授予财务管理。

护士／前线岗位（nurse／frontline-staff）默认可读取、销售及使用患者套餐（package.read／package.sell／package.consume）。旧角色或已发布策略遗漏这些动作时沿现有默认机制补齐；明确角色拒绝、已配置策略的拒绝／非法范围及动作停用均继续生效，不改写已发布历史。此默认不授予套餐设置、财务明细或退款权，所有动作继续校验本人身份、任职与患者／诊所范围。

每次读取、命令及原幂等结果回读，重新核验会话用户、岗位、集团、患者及 Centre；使用范围取购买快照，财务与退款须回到原销售 Centre 和原账单授权。客户端 actor、paid、账户 ID 或 UI 过滤不能替代服务端校验。Operation Manager／Finance 的能力上限包含套餐只读与财务读取，实际仍由当前授权决定；Super Admin 不因系统维护身份自动取得销售／退款资格。无财务资格的套餐目录与账户响应不返回分摊、成本、原付款凭据；Deposit 独立区域展示患者币种与可用现金余额：具有该患者访问资格及现有 Cashier 读取资格（billing.read／billing.checkout／billing.day_end.read 任一）的护士可见，不额外要求 package.finance.read；套餐入口本身仍需 package.read。仅读取原账户，不自动开户或改写账本；收取／抵扣、退款／冲正及套餐成本分摊分别沿用原操作权限。

新命令以当前身份、operation、request_id 和正文 hash 保证重试；同键异正文返回冲突。慢响应／患者或岗位切换不得写回旧上下文；写入结果未知须保留原请求并查询。数量状态和原账务来源保留审计，不提供任意改余额操作。

8. AI 辅助与知识库

AI-02： 未获批准的服务／缺配置／不可用时明确 Disabled 或 Error；不填示例结果。请求和响应绑定患者、Encounter 与输入版本；切换患者后旧结果不得写入新记录。普通 AI Assistant 默认无患者上下文，也不能写临床数据。

AI Chat 模型配置（2026-09-27）： 有 ai.chat.configure 权限的真实 Super Admin 可在 System Settings → AI Chat Models 维护提供方的 OpenAI 兼容 HTTPS 端点、加密 API 密钥，以及模型部署名、显示标签、说明、标记、排序、启用状态与默认项。普通 AI Chat 只显示已启用且提供方配置完整的模型；调用按数据库中的模型与提供方映射路由。更新密钥时只接受新值，不回显原值。旧环境变量作为初始提供方配置来源；一次性初始化后，后续启动不得覆盖管理员设置。此配置不代替服务方的模型部署、配额、数据区域或临床治理审批。 Clinical AI Copilot 首次打开时，若服务器返回的可用模型列表包含 GPT-6 Sol（gpt-6-sol），默认选中该模型；否则依次采用已配置默认模型、列表首项，无可用模型时保持未选择。用户仍可手动切换模型，本次窗口会话内新建对话不重置已选模型。此界面初始选择不改写模型配置、启用状态、额度或计量规则。

AI Chat 用量与月度额度（2026-09-27）： 每个真实用户共用一个跨模型、会话、诊所与设备的月度额度，默认按平台消费 USD 5 计算；提供方成本加价 50% 后扣减。普通用户只看到剩余／待结算百分比、重置时间及各模型消耗占比，不通过用户 API 下发美元额度或单价。香港时间每月一日 00:00 自动进入新额度期，不结转，首个启用月给予完整额度，不追溯旧对话。当前范围仅 Clinical AI Copilot 的文本聊天，不包含 ASR、OCR、PRD 问答或其他 AI 模块。充值属于后续阶段。

每次模型请求记录不含内容的会话 UUID、请求 UUID、真实用户、模型／提供方映射、输入（未缓存／缓存／写缓存）与输出 token、价格版本、加价和结算金额。历史会话再次发送的内容仍按提供方上报的输入计量。输入分类互斥，输出已含提供方计费推理 token 时不得重复累加。价格按部署类型、模型版本、上下文档位与生效时间保存；价格和加价修改不重算既有请求，已建立月度额度不被中途改写。

请求前原子预留保守输入上界及有界输出费用，完成后按提供方 usage 结算并释放差额。重复请求 UUID 不得重复派发；服务端验证真实用户并关闭 SDK 自动重试。额度不足或账务不可用时拒绝派发。缺失 usage／断流／进程中断不得当作零消耗，保留预留待管理员核对；可按提供方已确认 token 结算，或附原因豁免，均留审计。若提供方实际费用超出预留，记录真实消耗并停用该模型待检查。只有已核验价格、usage 格式、输入边界与输出限制的文本模型才能启用计量；参考价格默认待核验，管理员启用前须完成真实提供方验证。

聊天正文、回复、文档文本和 API 密钥不进入用量表、请求正文日志或活动流；仅保留必要元数据。管理员在既有 AI Chat Models 设置页管理价格历史、月额度／加价及按用户／模型／月份筛选的消费与待核对请求。数据库初始化只加表与一次性参考价格，不自动启用账务，不替代环境发布或 Azure 部署验证。

8.1 Knowledge Library

AI-03： 仅 AI Governance Admin 可提交获批准的非患者资料；维护来源、版本、Owner、生效／失效日期与审批人，经 Clinical Governance 审核发布后供检索。失效资料不能继续冒充最新规则。患者原始资料不作为普通知识库资料上传。

AI 服务提供方、用途、数据类别、区域、保留期限与生产批准仍需真实配置与治理证据；界面不显示密钥，不把模型输出或服务账号转化为用户资产承诺。

8.2 PRD 问答助手

2026-09-10 用户要求：在既有 PRD 网站增加基于当前 PRD 的 RAG 问答机器人；入口选定为 PRD 网站，生成服务选用独立 OpenAI 兼容接口。它用于解释产品需求，不是 Clinical Copilot，也不继承患者或临床系统权限。

2026-09-10 用户要求增加点踩及未回答问题留存，帮助补充和完善 PRD：

2026-09-16 用户要求当前 PRD 网站提供英文切换。英文仅是同一份已发布中文 PRD 的阅读视图，不形成第二套独立需求源：

实施与配置、检索质量和真实模型联调结果见 PRD 站点说明，不得将无模型检索或模拟接口测试写成在线生成已通过。

9. 外部集成与人工承接

已有设计包含 Connections／Messages、状态查询、消息详情、失败重试、人工兜底及审计。2026-08-27 已明确延期 Integration Worklist、失败状态、SLA 与重试责任，本版不将旧设计升级为本期确认需求。

Line D 提供连接能力，业务状态仍归 Line A／B／C。连接显示成功不代表已收款、已发药、已出结果或已获临床确认。

10. 历史迁移、环境与移动访问

本地合成登录配置只辅助测试，不授予权限，不进入应用或 PRD 发布产物。配置损坏须明确报错，不悄悄换成另一组账号；详细生成、构建过滤与已执行验证见实施参考。

PL-01 历史迁移： 保留旧患者／Chit 标识、来源、日期和附件关系，校验患者、Encounter、处方、费用及附件关联；失败记录可追溯和重跑。旧记录默认只读，空白不能解释成患者从未有相关病史。记录数／抽样阈值及切换时数据权威仍需确认。

PL-02 附件与恢复： 私有文件按授权短期访问；上传成功不代表 NAS→OSS 全量迁移完成。备份恢复、切换与回滚要有实测记录，不能用操作文档替代演练。

PL-03 环境： 代码实现、本地验证、文档发布、应用部署、端到端联调、UAT 分别记录。预览合成患者与真实业务明确区分；正式空数据或接口失败不回填演示业务数据。

PL-04 移动 Web： 方向为获授权只读患者摘要、用药及相关工具；精确字段、遮罩、会话、安全及性能仍待确认。不把 H5 患者填报视作已完成员工移动临床工作台。

11. 待确认事项与实施边界

11.1 尚待业务确认

护士工作范围改造未决项： 是否在现有默认组／临时班次外增加每周模板或多组并行；同诊所未授权组的忙闲投影；同诊所医生多组的真实例外及在途跨组交接；缺少分组来源的旧记录；旧 Read／Edit／Sign 与待审稿迁移。Clinic 承接位置／房间设备、Group 在 Units 维护、医生固定归组在账号维护以及经理调整护士安排已经确定；实际旧 Zone／候选 Group 的映射和部署切换是工程核验事项。

以下默认是实施建议，不冒充已确认业务决定；依赖未决规则的能力标为待确认，明确部分可继续实施。

11.2 已定规则的交付边界

2026-11-11： 护士诊所／Doctor Group 工作范围、跨诊所忙闲、统一保密授权和原样完成签署已有本地候选及限定范围的验证。最新组织整合、旧 Zone 转 Doctor Group、Clinic 承接位置／资源和医生账号归组仍处于优化方案阶段；本轮文档更新没有执行这些数据库迁移、应用改造、共享环境发布或 UAT。旧专项与候选验证均不能替代新整合方案的完整验收。

第 2～5 节已经明确集团基础资料共享、诊所关系、敏感字段、公共医疗信息、多角色任职、临床支持关系和临床记录授权。本节不再复述历史变化，只保留尚未完成的交付边界：

• 13 角色目标、既有 UAT 核对及 STG 待执行／验证的迁移边界按 §4.3 分别记录；固定记录授权、关系失效、正常／模拟角色对照和切换后的数据隔离须在目标环境完整验证。
• 2026-10-26 确认的规则按阶段实施：字段拆分及 dev/sai 合并已带入保密投影和附件保护；2026-10-28 公共 Diagnosis／Action 独立读写及两入口联动已完成本地验证，见本轮验证。负责医生附件审批、取消保密、历史来源与所有附件路径仍须按原专项逐项核验，不能用本轮公共字段结果代替。PRD、本地验证、STG 运行与 UAT 分别计证。
• 历史代码曾按 Read／Edit／Sign 区分护士临床修改；2026-11-11 已确认改为当前工作范围内直接保存及完成签署、保密内容单独批准。新规则的本地候选覆盖见上述专项，以下旧证据只证明其当时版本。Note 保存前提、医生占用、供应商／本次价格、待审阻断及结算保护统一见 Consultation §5.1，本地覆盖见本轮证据。Cashier 收款／结算和 Lab 执行仍查各自业务动作；不能由入口可见或旧验证结果推定其他模块已获签署权。
• 无医生 Vaccination 的本人 Note 与疫苗收费完成按限定权限实施；本轮集成不代表患者权益总览、套餐收款、疗程预约及简化退款整套方案完成，剩余范围见疫苗设计。应用部署、数据库迁移与 UAT 仍分别验证。
• 角色动作、App 可见性和对象数据范围是三层判断；界面列出某项动作，不代表所有模块和记录都可操作。
• 角色转换须先预览岗位、服务关系、临床授权、审批职责和活动会话的影响。历史作者与已完成记录保留，不能在启动时自动替用户选择角色。

当前代码、分支和环境状态见交付状态；执行范围及结果见权限测试。

11.3 范围与证据入口

经营看板、通用 Report／Insights、现金盘点关账、自定义／定时报表、App Marketplace、完整 WDL 和复杂 Benefit 后台不属于本期完整验收；已确认的 Day-end Revenue Report 按 Cashier PRD 承接，不在通用报表排除项内。权限、临床协作与异常监测的未决细化见 §11.1／§7.3。页面保留策略与功能范围独立；2026-09-06 用户明确要求清理重复及无实际用途的 App，当前策略见桌面入口章节。撤出占位入口不取消已确认需求，也不新增 WDL／集成 SLA 承诺。

权限及会话的兼容迁移和已执行验证见实施参考、WS6、权限测试及导航测试。已确认业务与代码不一致时按交付差距处理，不改写产品规则。