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

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

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

正文描述产品要求。已经实现到哪一步、哪些内容仍待确认，集中见第 11 节；相关验证记录从该节查阅。

1. 功能地图与阅读顺序

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

角色说明一个人可以做哪些工作；诊所、服务医生和记录授权进一步确定他可以处理哪些资料。例如，护士服务某位医生，可以处理相应的护理工作，但查看医生的完整问诊记录仍需授权。

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

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

flowchart TD
  G[Medical Group 集团] --> C[Clinic 诊所 A 或 B]
  G --> O[Back Office 后台]
  G --> W[WDL / Central Pharmacy]
  U[User 同一真实员工] --> M[Membership 岗位：主体、有效期]
  C --> M
  O --> M
  W --> M
  U --> R[Role 用户唯一角色]
  R --> M
  U --> P[Provider 稳定医生身份]
  P --> D[该医生在某 Clinic 的有效关系]
  C --> D
  M --> N[护士在某 Clinic 的有效岗位]
  N --> S[服务关系：护士 + Clinic + Provider]
  D --> S
  S --> A[医生另行授权：记录、查看或编辑、期限]

集团下可以有诊所、后台和中央药房等工作单位。员工通过岗位与工作单位建立关系，同一个人可以在多个单位任职，但当前业务角色保持一致。

医生在不同诊所出诊时，沿用同一个医生身份。护士可以服务多位医生，每条关系都要说明所属诊所。图中的关联不会自动授予其他资料权限。房间、设备等预约资源单独管理，不使用共享医生账号。

用户角色唯一性（2026-09-10 用户确认）

一个账号只有一个当前业务角色。员工可以在多个工作单位以同一角色任职，但不能在 A 诊所是医生、在 B 诊所是护士。新增岗位只增加工作范围，不增加第二个角色。（2026-09-10 用户确认）

Cashier 是护士使用的收费功能，不单独设置业务角色。前台保留预约及患者基础信息维护，护士按所在诊所和服务医生关系处理护理及付款。具体资料范围见第 3 节。后台 Finance、Billing & Insurance，以及医生获授权的只读报告入口，继续按各自职责使用。

Staff／External 只是人员分类，不是业务角色。管理员测试功能时，应模拟另一个真实用户，不给自己的账号叠加角色。系统仅开放明确授予的权限，未写明允许的操作不自动放行。

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 Note 完整病历]
  V --> RX[Prescription 处方]
  V --> X[生命体征、服务、检查及附件]
  P --> S[公共医疗摘要与历史索引]
  N -.生成有限摘要.-> S
  RX -.生成有限摘要.-> S
  P --> L[患者关联多个 Clinic]
  F[首次建档来源和有效历史 Visit] --> L

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

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

本文把患者资料分为基础信息、公共医疗摘要、完整问诊记录、处方和附件。一次就诊（Visit／Encounter）将相关记录联系起来，但这些记录各有访问规则。敏感字段还需要单独处理，详见下一节。

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

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

患者基础信息可以在集团内查询，修改和确认仍由与患者有关联的诊所按权限处理。公共医疗摘要也在集团内共享，但需要单独授予角色读取权限。完整问诊记录由负责医生管理，其他医生和护士需要获得相应授权。

护士与医生的服务关系按诊所维护。护士日常处理日程、签到、本次附件和付款，不需要为这些工作逐次申请临床记录授权；查看完整问诊记录或历史附件时，再检查医生授权。药房人员则按处方所属诊所承接审方和发药。

通用规则（AC-02）： 以上权限都以有效账号和岗位为前提。系统还会检查角色允许的操作、资料所属范围、授权期限、记录状态，以及适用的患者同意。能够查看一份资料，并不代表可以修改、导出或签署它。

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

医生主要处理本人负责的日程和问诊。 系统根据医生身份和有效诊所任职，显示其工作范围。查看其他医生的完整记录，需要明确的记录授权；这类授权只开放获批资料，不同时授予日程管理、代诊或签署权。集团基础资料查询和获授权的公共医疗摘要，不受医生本人问诊名单限制。

护士的工作范围是“在某家诊所服务哪些医生”。 例如，医生甲同时在 A、B 两家诊所出诊，可以分别由不同护士支持。A 诊所的护士只能根据 A 诊所的服务关系处理工作；即使服务的是同一位医生，也不能因此处理 B 诊所的日程、签到、附件和付款。

护士如需在另一诊所工作，应先切换到本人有效的该诊所岗位。系统随后重新加载该诊所的服务医生和授权记录，并清除旧患者、队列、历史列表及提醒数量。切换前尚未完成的请求，即使稍后返回，也不能把旧资料带回页面。

列表、搜索、详情、下载和保存使用同一套权限规则。直接输入记录编号或打开旧链接，也要经过检查。缺少必要的诊所或医生关系时，系统提示原因，不改为显示全诊所资料；跨集团访问不在本共享范围内。

3.2 数据类别 × 查看 × 编辑

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

完整问诊记录包括什么。 本文所指的受限记录包括完整问诊笔记（Note）、诊断详情、检查结果和正式临床文档。护士读取这些内容时，需要在记录所属诊所有有效岗位、服务该位医生，并取得仍有效的查看授权。查看和编辑草稿分别授权，具体方式见第 5 节。

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

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

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

敏感字段的查看流程

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

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

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

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

3.3 患者资料修改与确认：诊所资格与集团查询分开

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

修改和确认资料，需要诊所与患者有关联。 前台可以新建、修改和确认获准范围内的基础信息；医疗及安全资料、保险计划和整份 H5 提交审核，由具备相应权限的岗位处理。

需要申请接收资格时，工作人员从患者页为当前诊所提交申请。原诊所有审批权限的人员或指定负责人，在 Requests & Approvals 处理。批准后，接收诊所内的有效前台、医生和护士，按照各自的维护动作和字段范围使用资料。

待批、拒绝或取消的申请不提供维护资格。批准到期或撤销后，这项资格停止；如果诊所已有独立的有效就诊关联，仍按该关联判断。通过预约取得的接收批准必须关联同一患者、同一诊所的有效预约，预约取消或改诊所后不再继续放行。

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

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

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

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

没有详情权限时，页面仍显示用户有权查看的摘要，并提供申请入口；应说明“需要授权”，而不是显示“没有病史”。其他医生要读取完整处方、问诊正文、诊断详情、检查结果或正式临床文档，须取得原医生或指定负责人的记录授权。确认患者详情或阅读审计提示，不能代替这项批准。历史附件、版本和 AI 上下文同样按来源授权处理。

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

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

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

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

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

护士负责所服务医生在当前诊所的日常工作。 有效服务关系配合相应功能权限，允许护士处理日历、预约创建和变更、签到、本次附件及 Cashier。护士可以服务“本诊所全部医生”，也可以服务“指定医生”；前一种配置只扩大服务范围，不自动取得医生的临床记录授权。

服务医生清空、关系结束或授权失效后，系统显示无有效服务范围，不恢复为全诊所。跨诊所总览同样不授予现场操作权限。

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

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

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

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

新预约、签到、付款及服务关系本身，不开放完整问诊记录或历史附件。其他医生的记录查看与临时代诊职责分别授权。对于没有负责医生的 No Consultation 服务，资源及护理分工仍待确认，不能默认交给全诊所护士处理或收费。

3.6 Consent、撤权与版本控制

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

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

护士保存的草稿记录其本人身份，医生复核该版本后再签署。授权不允许直接覆盖已签历史、药房交接或收费快照；已关闭的就诊不可重开。查看权限也不自动包含导出、复制为新记录或编辑。

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

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

管理员在用户详情中维护员工资料、配置岗位和服务医生，并查看最终生效的权限。组织、角色模板和审批记录各自在对应入口维护；用户详情引用这些配置，不再维护另一份副本。医生另在个人设置中管理护士的临床授权。

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： Insurance 和 Billing 是同一个团队，角色入口合并为 Billing & Insurance；保险核验、账单、付款责任和回款是同一团队内部的工作。团队作为后台岗位工作时使用后台场景，不为处理某诊所的账单切换为 Clinic 角色。现场岗位的 Cashier 能力与后台团队入口分开配置；团队合并不自动赋予 Finance、采购审批或临床签署权限。旧 billing-team／insurance-team 账号关系与审计需要在实施时兼容迁移，不能只改显示名后声称已经合并。

4.2 Finance 的业务动作

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

4.3 管理入口与用户资料

普通管理员应能在一个用户上下文内完成资料、任职和服务范围配置，并解释为什么该用户可以或不可以访问某类资料。医生在 Settings 中管理关联护士授权。共享角色模板、组织主档和审批记录保留各自唯一来源。

角色目录的“业务操作数”统计当前有效 permission，不表示可见菜单、App 或 Tab 数量。三角色集团模板只覆盖 Doctor、Nurse、Master；其他受支持角色读取既有有效底表授权，并保留已有角色权限上限，不得因未纳入模板或发布三角色模板被清空。CP Staff／PIC 应显示实际 CP 动作；Finance 保留获授的 CP 只读入口，不因此获得审批或仓库写权限。Billing／Insurance 旧别名使用同一边界。未知／停用角色仍不可用。当前页面未提供菜单 → App → Tab 的可配置树；入口可见性仍按角色、场景及实际动作权限计算，不能把本轮零权限修复记为界面权限编辑器已实现。

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

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

用户列表与资料查看

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

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

详情、组织配置和角色配置使用 App 内右侧栏，窄窗口占满 App 内容区域；列表筛选及滚动位置保留。遮罩不关闭，未保存变更须确认放弃，提交期间阻止重复操作及关闭；页头与主要保存操作固定，内容内部滚动。

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 补录或更正，保留变更原因及版本校验。旧记录不自动生成或猜填注册号；缺号影响最终临床签署，不单独取消现有草稿保存资格。旧缺号身份仍可停用，重新启用前必须补齐；停用不删除原记录、不自动恢复历史授权。

新建账号与配置岗位

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

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

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

管理集团与跨集团任职

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

共享账号全局资料由 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 岗位与护士服务范围

一条配置对应一个主体，继承用户唯一角色（见角色唯一性），不能逐行选择不同角色；Clinic、Back Office、WDL 分别使用真实主体。页面默认显示当前及待生效任职；已停用、已到期及旧角色记录折叠到“历史任职（N）”，不加载历史护士服务表单。仍有效的异角色记录明确警示角色冲突，不通过隐藏或自动改写解决。点击“添加工作单位”或某行“编辑”才展开表单。护士的日常配置在同一行／详情中完成：

角色及恢复限制（2026-09-14 用户确认）： 工作单位继承用户唯一业务角色，候选角色及前后端保存均须一致。Doctor 只配置出诊诊所，复用本人 Provider；只有当前有效 Nurse 任职展示可操作的服务医生配置。旧角色任职只读保留，不可直接启用；角色变更使用独立流程。同单位重复新增拒绝并提示编辑既有任职，不能暗中覆盖日期或默认登录设置。已到期的 active 任职引导调整有效期；已停用且过期的任职引导重新配置，不允许仅切换 active 状态造成假恢复。停用但尚未过期且角色一致的记录可填写原因恢复，已终止的服务关系和临床授权不自动恢复。

操作步骤见用户与工作单位操作手册，手册引用本节规则，不维护第二套权限定义。

从岗位配置服务医生时，Clinic 自动带入并以文本显示，不再重新选择 Source clinic。医生候选按该 Clinic 联动；增设 B 诊所服务必须先有 B 的有效归属。护士只有 A 归属时，即使管理员可以管理 A／B，也不能在 A 岗位直接保存 B 服务关系。

整诊所模式和指定医生模式互斥。整诊所模式后续纳入本诊所新有效 Provider 只增加服务关系，不产生该医生的临床授权。指定范围被清空、到期、撤销后显示“无有效服务医生”，不能回退整诊所。切换模式前展示新增／移除医生及受影响授权；后端按同一变更提交并留证。

界面可以提出未来生效的调整，但保存时不能立即结束今天仍有效的旧范围。预约调整应明确生效时点和转换结果；如果尚未具备定时切换能力，则该阶段只支持明确立即生效，不能接收未来日期却提前撤权。

4.5 有效权限概览

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

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

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

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

4.6 Master、负责人及角色模板

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

护士 Consultation 的医生授权依据仍须明确保存，不能仅从 Master 管理操作推导已获医生批准。任何管理／访问审批均不替代负责医生对临床内容、处方、检查开单及最终签署的确认。负责关系失效后停止接受其新审批；既有授权还须继续满足受益人的服务关系、账号及其他生效条件。

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

4.7 登录、模拟与退出

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

AC-01（2026-09-09 用户确认）： 默认角色切换采用完整功能测试，选择目标真实员工在该诊所／主体的有效岗位；Doctor 同时绑定稳定 Provider。Assume 的数据和操作权限与该目标真实登录一致，不因模拟身份额外禁止患者维护、Reception、本人问诊、授权申请或管理。权限取目标岗位的当前模板、服务关系及已批准记录，不继承 Super Admin 的范围；管理员登录身份与目标员工身份分别保留。只读预览须显式选择并明确标识；仅角色模板预览没有真实受益人，不冒充个人临床授权。目标人员／任职失效时停止该模拟，不能自动转绑另一任职。 非患者个人文件的所有者、列表、上传去重、下载及删除资格同样按目标员工判断；实际管理员身份仍保留在访问审计中。退出模拟后恢复原人员的文件范围，不把模拟期间上传的文件归到管理员，也不迁移已有文件的所有者。患者文件仍独立按资料分类、来源和临床／隐私权限判断。

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

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

5. 临床记录授权、续期与撤销

医生可以授权护士协作处理自己的问诊记录，也可以按申请开放指定记录给其他医生。本节说明授权前需要具备的关系、如何选择记录范围，以及授权何时生效或失效。

申请人从可识别的患者和既有就诊列表中选择记录，无需手工输入记录 ID。申请未获批准并生效前，页面不加载受限正文。

5.1 护士授权的匹配键与范围上限

护士获得临床授权前，需要先在记录所属诊所任职，并与负责医生建立服务关系。 例如，护士在 A 诊所服务医生甲，医生甲给她的授权只能覆盖相应的 A 诊所记录。即使医生甲也在 B 诊所出诊，也不能直接把 B 诊所记录加入这份授权。

如需在 B 诊所协作，管理员应先为护士建立 B 诊所的有效岗位，再关联该诊所的医生。医生的授权页面不能代替管理员增加护士所属诊所。

系统检查以下条件，全部满足后才开放记录（AC-09）：

1. 护士账号、角色操作权限和来源诊所岗位有效。
2. 护士在该诊所与负责医生的服务关系有效。
3. 医生批准的范围包含本次请求的记录和操作。
4. 授权尚在有效期内，记录状态也允许该操作。

新护士岗位没有指定医生时，系统应明确保存“本诊所全部医生”的默认服务范围。以后清空指定范围、撤销关系或关系到期，则显示“无有效服务医生”，不能恢复为全部医生。整诊所服务关系本身不开放完整病历。

账号、单位、岗位、医生身份或服务关系失效后，相应临床授权停止提供访问。历史记录保留，恢复关系不会自动恢复已撤销或结束的授权。

5.2 从申请到生效

flowchart LR
  S[选择既有记录、动作、用途、期限] --> Q[按原医生拆分申请]
  Q --> A{原医生或指定负责人复核}
  A -->|拒绝| R[保存原因，不产生访问权]
  A -->|全部或子集批准| G[保存明确授权集合]
  G --> T{开始时间与全部关系有效?}
  T -->|未到开始时间| W[待生效]
  T -->|全部满足| E[生效中]
  E --> X[到期、撤销、账号或关系失效]

申请和批准

申请人选择记录、操作、用途和期限后，由原医生或有资格的指定负责人处理。记录来自不同医生时，系统分别建立申请，不要求无关医生共同签批。

审批人可以批准全部或部分记录，也可以拒绝。部分批准只开放列明的记录，其余部分需要另行申请。医生可以主动为关联护士建立申请并亲自批准，但任何人都不能批准自己的申请，或批准超出本人职责和申请范围的内容。护士临床访问的医生授权依据必须真实保存，管理员不能代填医生身份。

申请状态和授权状态分别展示。申请可以是待审批、已批准、部分批准、已拒绝或已取消；获批授权则可能尚未开始、正在生效、已到期、被撤销或因关系失效而停止。Access Center 提供“我的申请”“待我审批”“有效授权”和历史记录，逐条显示结果。

选择记录范围

授权时需要分别选择“覆盖哪些记录”和“有效多久”。没有到期日，不表示未来新增记录也自动纳入授权。医生可以选择以下两种模式（2026-09-10 确认）：

保存持续授权前，页面应明确显示医生、诊所、当前可识别范围、允许操作和起止时间，并说明同时包含既有及未来记录。系统按规则判断新记录是否纳入，不复制病历。

查看和草稿编辑各自保存范围、模式、期限及批准人。编辑范围不能超过有效查看范围，因此不能只授予几条固定记录的查看权，却授予更广的持续编辑权。编辑仍限于已允许协作的草稿；不能创建护士无权创建的医生模板、修改正式处方或代签。医生尚未初始化可编辑内容时，授权不会自动建立记录。

生效、续期和范围变更

到了开始时间，而且各项关系仍有效，授权才开始生效。来源就诊后来变更负责医生或诊所时，系统按新归属判断后续访问。账号、岗位、医生或服务关系失效时，持续授权也停止，恢复关系不自动恢复已终止的授权。

旧固定授权继续按原范围使用。医生要改成持续覆盖，应明确保存新版本，系统保留旧依据。续期只延长时间，不改变覆盖模式、记录集合、医生、诊所、服务关系或审批依据；原关系已结束的，应重新申请。

护士切换到另一个有效诊所岗位，不会改变已有固定授权的受益人和原绑定关系。系统仍重查原关系，日常日历则按当前岗位显示。每次访问记录实际操作者、记录、授权编号和版本、覆盖模式，便于追溯。

实施状态： 固定记录授权已有基础；持续覆盖仍待开发和验证。未支持的模式应明确显示尚不可用，不把批量选择记录或设置无到期日显示为持续授权成功。

5.3 医生端“我的护士授权”

医生从个人设置（Personal Settings）进入“护士授权”，无需先打开患者或问诊页面。页面默认显示当前诊所，也可以选择本人其他有效诊所，并始终显示正在管理哪家诊所的授权。

这里选择诊所，只改变授权管理范围，不切换正在处理的患者或诊疗工作。按照 2026-09-10 确认的安排，授权统一在 Settings 维护，不向 Consultation 增加额外操作。

先选关系，再设操作。 表单固定护士、诊所和医生，不能在授权时换成无关联人员或增加所属诊所。查看和编辑两个选项作用于已经选择的临床记录，不在初始界面增加大量模块开关。

选择编辑时，系统同时选择查看并提示用户。在这个统一设置中关闭查看，会在保存时一并结束依赖它的编辑授权；以后重新开启查看，不会恢复已结束的编辑。

调整选项时先保留为页面草稿，点击“保存授权”后才生效。保存前列出记录范围、期限和变更结果；取消则保留原授权。

授权记录覆盖边界必须明确呈现。固定模式选择可识别的既有 Visit，不要求手输 ID；持续模式明确显示所选医生、Clinic、既有及未来覆盖、动作和有效期，保存前确认影响。两种模式按 §5.2 实施；旧授权默认仍是固定记录，持续功能未开发时不能提供假成功。

护士可以对医生 A 是仅查看，对医生 B 是查看＋编辑；医生 A 在 Clinic A 的授权不包含本人 Clinic B 的记录。医生授权只覆盖自己负责的受限临床资料，不扩展到同患者他医或其他 Clinic 的完整记录。

查看范围包括获批记录中的完整问诊正文、诊断详情、检查结果、正式临床文档、处方和历史附件。公共摘要和本次附件另按第 3 节处理。

编辑范围限于允许协作的病历或问诊草稿。处方草稿协作仍是待细化、待实施的方案，现有 clinical.draft.write 不代表护士已经可以选药或改药。最终开单、签署、正式修订及结算后的更正，仍由医生按原流程处理；系统保留护士实际编辑的记录。

5.4 查看与编辑匹配示例

以下为说明规则的合成人员和记录，不代表已执行测试。假设医生甲在 Clinic A／B 有有效岗位，医生乙在 A；护士小林只属于 A，并在 A 关联甲和乙。小林获甲的 V1 查看授权、乙的 V2 查看＋草稿编辑授权。患者 P 的 V1 属 A／甲、V2 属 A／乙、V3 属 B／甲。

若小林后来加入 B，但只关联 A 的甲，V3 仍不开放；建立 B＋甲服务关系后还须取得 V3 对应医生授权。患者同一、医生同一、护士同一，均不能抹去来源 Clinic 和记录集合的区别。

5.5 撤销、人员调动及正式交接

医生设置的授权和旧固定记录授权，按同一护士、诊所和医生统一展示。撤销查看权后，依赖该范围的编辑立即不可用，历史操作记录仍保留。其他诊所、医生和公共资料的独立权限不受连带影响。

两种撤销方式需要分别处理：

• 在 Settings 中关闭查看并保存，按 §5.3 同时结束依赖的编辑授权。以后开启查看，不自动恢复已结束的编辑。
• 单独撤销一条查看授权时，独立编辑授权保留记录，但暂不可用。只有重新取得相应查看权，而且编辑授权本身仍有效，才可以继续编辑；已结束或撤销的编辑权不能恢复。

旧授权记录或其他入口不能绕过撤权。修改岗位、服务关系或有效期前，应显示受影响的授权；保存和后续访问再次校验。授权期限不能超过所属岗位或服务关系的期限，不一致时提示并拒绝保存。

普通入职：建账号 → 添加 Clinic 的 Nurse 岗位 → 配置整诊所／指定医生 → 查看结果 → 医生按需授权。人员调动：结束旧主体／关联并确认影响 → 建立新主体／关联 → 新来源医生按需授权。旧作者、历史记录及合法提交不迁移或重写。

访问授权只开放批准资料；临时代诊需明确临床职责并由有资格医生执行；正式交接保留原作者／签署者与版本。正式交接是否覆盖持续照护及未来预约仍待确认，不能自动开放接收方全部后续记录。

失败应明确说明“护士未归属该 Clinic”“请先关联该医生”“未获得编辑授权”或“记录已签署”等实际原因；只披露请求者有权知道的对象信息。撤权与编辑并发按“Consent、撤权与版本控制”处理。

5.6 授权界面的显示与操作

用户详情、医生授权和申请中心读取同源结果；角色、主体、服务关系、授权状态分别显示。用户／多人关系列表支持按姓名、用户编号、邮箱搜索，在分页前匹配有效与历史结果。进入申请页可带筛选，必须明确且可清除。

主列表用表格，表单按需展开；固定标题与操作区，中间正文滚动，窄屏仍可完成全部输入。长岗位名、日期和记录清单不能撑出弹窗；蒙版不能关闭未保存表单，切换用户／Clinic 保护未保存内容。查看／编辑变更只有保存后才生效。表单、搜索多选、日期时间、日历、按钮统一复用 Element Plus 与项目封装，详细组件表只维护于页面设计指南。

6. 桌面入口与配置管理

6.1 App 目录

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

V-Lab 的独立执行工作台仍为已确认待接入需求，未接入时不恢复说明性 App。未实现的通用 Workflow、Security、Numbering、Integration 等配置不新增假保存页，后续实际接入时归 System Settings 或各自业务 App。

账号管理收敛（2026-09-09 用户反馈）： User Accounts 是唯一以人为中心的账号维护入口，详情内包含 Profile & Access Window、Roles & Subjects、Effective Permissions；基本资料、所属主体、唯一用户角色、任职生效／失效日期与账号访问窗口在同一用户上下文管理；Roles & Subjects 不表示允许一个用户拥有多个角色，目标规则以角色唯一性为准。新建账号默认 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 共享配置与个人偏好

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

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

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

共享 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 对象及手机本地角色选择均不能恢复无权入口；角色／权限变化后撤下图标及不再授权的窗口，保留仍获授权窗口。未取得真实会话或未选角色时不以本地存储的 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 会话时显示访问不可用，不注入模拟库存或自动取得权限。

此前桌面收敛只完成其记录中的入口及权限呈现；本轮权限改造也不代表独立 CP 原型、跨地点库存流水、诊所库存或业务 UAT 已完成。

6.4 收费与药房入口分工

Cashier 展示本次药房进度及阻断原因，供关联护士判断开票／结算条件；不提供启动 Drug Dispensing 的跨岗位入口。药房人员从自己的获授权工作台完成审核、标签、备药和最终交付，护士在 Cashier 的显式 Return to Consultation 仍是独立就诊回退动作。

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

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

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

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

桌面启动恢复： 初次读取已保存布局期间，用户新打开、关闭、聚焦或调整过的窗口优先于旧布局；迟到的恢复结果不得关闭或替换这些窗口及其输入。会话与初始布局处理完毕后，桌面进入 Ready，随后继续保存当前布局。此行为已有代码与独立浏览器回归场景，运行证据须以对应 CI 结果为准。

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

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

7. 审计查询与异常复核

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

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

7.1 事件查询

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

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

8. AI 辅助与知识库

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

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：

实施与配置、检索质量和真实模型联调结果见 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 尚待业务确认

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

11.2 用户配置与授权的当前边界

本次权限规则的来源。 2026-09-14 用户确认了集团基础资料共享、修改和确认保留诊所关联、敏感字段查看审计提示、公共医疗信息角色授权、按诊所维护护士与医生关系，以及问诊记录、附件和处方的访问范围。随后明确前台保留预约和基础信息维护，但不能签到。这取代此前基础详情读取也受诊所关联限制、仅 Note／历史处方受限，以及前台可签到或收费的表述。规则见第 3 节，本轮修改不代表应用已经实施或验收。

单角色配置的已有基础。 全局角色 authority、数据库约束及显式角色转换已有代码和本地定向完整链路验证，发布与业务验收另有记录。当前和未来岗位都继承同一业务角色；新增或恢复岗位不能取得第二个角色。存量冲突显式列出，保留原有有效操作和历史记录，不在启动时自动选择角色。

角色转换先预览旧岗位、护理关系、记录授权、临时代诊和会话的影响，再凭预览结果提交。相关条件发生变化时重新预览。仍承担审批职责的人员须先移交职责，才能完成转换。旧岗位结束后新建岗位，不复用原 ID；医生身份和历史作者保持不变。

安全资料的现有写入限制。 当前代码只允许拥有来源就诊的医生更正安全资料。同诊所、有患者维护权限的护士可以修正姓名、手机和地址，但已有 Allergy／ADR／Alert 及备注仍只读，草稿协作授权不开放这项修改。护士安全资料更正尚未实现。核实及创建时间由服务端维护，省略备注保留原值，显式空值才清除；不恢复未分类旧完整病历快照。旧接口和附件分类改造仍需逐项验证。

2026-09-14 已确认、待实施核验： §3 权限分类及最新前台边界已更新；本轮不修改应用代码或角色种子。源码中患者身份投影仍包含 hkid 等字段，公共疫苗读取仍复用 patient.read，不能据此认定敏感信息默认隐藏或独立公共医疗读取能力已落地。基础字段限制、当前／历史附件分流、Cashier 护士操作范围和完整问诊类别需后续逐接口对照；证据与发布状态见本轮 PRD 修订记录。

1. 持续记录覆盖已确认、待实施： 2026-09-10 本轮评审允许医生明确选择持续覆盖，查看及草稿编辑分别授权。具体模式、旧授权兼容、关系失效和权限上限统一见 §5.2；现有固定 Visit 实现不作为持续范围已生效的证据。
2. 处方编辑实施需细化： 本方案建议允许已授权的处方草稿协作，具体可改字段及创建／删除草稿能力需在实施前形成模块契约；最终开单／签署仍由医生，历史正式处方不可直接改写。
3. 本轮实施边界： 已实现四入口、三页签、按需展开岗位表单、护士范围原子多选与立即生效、医生固定记录授权入口及管理员同源只读记录。新关系跟随岗位上限，保留未修改关系的既有更短期限；本轮不提供未来自动切换或新建更短服务期限。

已落地的主体检查同时作用于服务配置、医生授权及临床读写决策；旧跨主体记录保留历史，但不再作为有效授权依据，可在该护士岗位的范围编辑中修正。角色动作按岗位展示，医生授权显示同源记录和失效状态；完整逐项权限诊断、角色动作与 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、权限测试及导航测试。本轮整理以当前开发分支及项目索引指定的本地候选为来源；不新增应用完成或 UAT 结论。已确认业务与候选代码不一致时继续记录差距。

全局主体上下文与数据范围（已确认）

用户通过全局 Context Selector 切换本人有效的 Clinic／业务主体；各 App 不再自行提供跨诊所筛选。任一 App、Tab、列表、详情与动作只使用当前主体，并由服务端重新计算 auth context 与 ui_access。Doctor 在当前主体只能查看本人 Provider 的日程、当前问诊患者及历史问诊记录；Nurse 只能查看当前 Clinic 内且满足本人有效服务关系及医生授权的日程、队列和记录。切换到另一有效 Clinic 后才可加载对应数据。主体切换清空旧患者、队列、历史、角标、未保存内容和进行中请求；迟到响应不得写回新主体。列表、详情和动作接口均再次校验主体与对象授权，缺少主体或投影时默认拒绝。