角色分类与权限矩阵

本矩阵列出技工所病例管理软件 Cympha 中的每个角色及其可执行的病例操作，从临床医生到设计师和患者.

适用对象: 决定团队中谁担任什么角色的技工所管理员、请求加入技工所的员工,以及任何想理解为什么某个病例落入(或没落入)自己队列的人.

你将了解到: Cympha 定义的角色、各角色能做什么、登录后落在哪里,以及加入技工所的"请求 - 批准"流程如何运作.

所需时间: 四分钟.

一句话总结的角色模型

每个 Cympha 账户恰好有一个角色,该角色决定三件事:登录后看到哪个应用外壳、能持有哪些病例状态、对病例能采取哪些操作.

Cympha 定义了 13 个角色,外加 7 个"待定"变体(在技工所相关角色等待技工所管理员批准期间使用). 新账户一开始没有任何角色:你在 Select Your Role 界面选择一个(角色卡片分为 Clinical、Lab、Partner 三组),角色一经设定,就无法从你自己的账户更改. 面向医生的卡片标注为 Clinical;患者角色从不出现在此界面 —— 它仅通过邀请存在.

VISITOR

是谁. 已注册账户上的真实占位角色 —— 已注册但尚未确定工作角色的人. 在角色选择时选择 Partner 卡片,会在合作伙伴申请处理期间把你注册为 visitor.

能做什么: 登录并使用最小化导航. Visitor 是唯一之后仍可升级的角色 —— 其他角色都是一次性设定.

落在哪里: 一个最小化的仪表盘.

CUSTOMER(显示为 "Clinical")

是谁. 临床医生(牙医、正畸医生),或任何外部病例提交者."我来送活给技工所"的角色. 在角色选择界面上,此卡片标注为 Clinical.

能做什么: 在 /cases/new 创建病例、提交给技工所、在 /cases/<id>/approve 审核交付物、批准 / 请求修改 / 升级、以只读方式与同事共享病例,以及(对对齐器病例)向患者共享方案.

落在哪里: 客户仪表盘 /.

LAB_MANAGER

是谁. 技工所的所有者 / 主要运营者. 任何新技工所的第一位用户.

能做什么: 完成技工所入驻向导、在 My Lab 管理技工所资料和服务、在 My Team 批准待定团队成员请求、查看 /queue 中的所有病例、分配病例、覆盖状态、处理升级(ESCALATED 路由到此角色),并在 SHIPPING 和 SUBMITTED 上作为持有人.

落在哪里: 登录后 /queue.

注意. 每个技工所在病例路由上恰好有一个 LAB_MANAGER. 技工所管理员在选择角色时立即激活 —— 没有审批环节;确认对话框为 "Your lab account is ready",下一步就是设置技工所.

LAB_ADMIN

是谁. 需要总览技工所工作、但不参与病例路由轮转的资深技工所员工.

能做什么: 查看技工所的病例队列. Lab admin 是技工所端的观察者角色:他们不是任何病例状态的期望持有人,因此病例不会自动路由给他们;病例分配和技工所配置仍由技工所管理员执行.

落在哪里: /queue.

DESIGNER

是谁. 技工所中的人类设计师. 除技工所管理员外最常见的技工所端角色.

能做什么: 接收病例分配、持有 DESIGNING 病例、请求批准(把病例翻转到 AWAITING_APPROVAL),并短暂持有 APPROVED 病例直到其自动推进. 当客户对某个交付物请求修改时,病例会回到构建它的设计师手上.

落在哪里: My Assignments(/assignments)—— "分配给你处理的病例",带患者姓名搜索和状态筛选.

ALIGNERBOT

是谁. 自动化 AlignerBot 席位的角色. 机制上属于设计师类角色,但工作通过配对的桌面代理完成,而非人工. 它是一个授权的自动化席位 —— 在角色选择时选择它会经过订阅提示,拒绝则注册为普通 Designer.

能做什么: 接收对齐器病例分配、持有 DESIGNING、通过代理推进工作.

落在哪里: 设计师视图(与 DESIGNER 同一外壳).

CASE_INTAKER

是谁. 一种设计前的质量控制角色:在病例进入设计师队列前检查扫描、CBCT、处方完整性和患者基本信息的人.

能做什么: 持有 INTAKE_REVIEW 病例. 没有 CASE_INTAKER 的技工所会完全跳过 INTAKE_REVIEW —— SUBMITTED 病例直接进入 DESIGNING. 这是按设计如此;并非每个技工所都需要一个接收步骤.

落在哪里: 接收队列(/queue 的筛选).

MANUFACTURING_ENGINEER

是谁. 负责物理制造的人 —— 打印、铣削、修整.

能做什么: 持有 IN_MANUFACTURING 病例. 在物理(技工所服务)病例上,医生批准设计后,病例会停在 Approved,等待技工所手动移到 In Manufacturing —— 这是一个刻意的手动步骤,让技工所掌控自己的排程.

落在哪里: 制造队列.

OPERATIONAL

是谁. 发运文员、技工所协调员,处理制造与快递之间物理世界事务的人.

能做什么: 与技工所管理员一起持有 SHIPPING 病例.

落在哪里: /queue.

DSO_MANAGER

是谁. 一组诊所(DSO)的管理者,或支持一组医生的经销商. DSO 管理员管理的是医生,不是技工所.

能做什么: 查看其组内医生提交的每个病例 —— 严格只读. DSO 管理员在任何病例上都没有操作按钮,任何病例操作都不接受此角色. 他们在 My Doctors 页面管理自己的组:通过邮箱邀请医生(医生必须已有 Cympha 账户并且必须接受)、批准或拒绝请求加入的医生、移除医生. 医生也可以随时单方面离开 DSO.

落在哪里: 仅有两个导航项的仪表盘 —— Dashboard 和 My Doctors.

注意. DSO 成员关系独立于技工所成员关系,并且它是 Cympha 中唯一双向运作的加入流程(医生请求,或 DSO 邀请).

PATIENT

是谁. 通过对齐器病例的 Share to Patient 流程被共享了 .gvw 的最终患者. 受限角色,没有通用 Cympha 前端. 仅通过邀请获得 —— 从不出现在角色选择界面.

能做什么: 查看医生与他们共享的 .gvw 文件的一页清单;点击其中之一以打开 Cympha Studio 查看器. 通过相机流程回传 Ortho Monitoring 照片轮次. 仅此而已 —— 没有病例文件夹、没有其他患者、没有编辑工具、没有设置.

落在哪里: /patient,无浏览器外壳,列出共享的 .gvw 文件.

待定角色流程

设计师、Case Intaker、制造工程师、Lab Admin、Operational 用户和 AlignerBot 操作员不能直接声明自己的角色 —— 方向永远是从员工到技工所:员工发起请求,技工所管理员批准. 技工所没有任何方式邀请或添加团队成员;加入总是从员工一侧开始. 在技工所管理员批准之前,请求者处于 PENDING_* 角色,不被授予任何技工所端访问.

映射:

| 目标角色 | 待定占位符 | |---|---| | DESIGNER | PENDING_DESIGNER | | CASE_INTAKER | PENDING_CASE_INTAKER | | LAB_ADMIN | PENDING_LAB_ADMIN | | MANUFACTURING_ENGINEER | PENDING_MANUFACTURING_ENGINEER | | OPERATIONAL | PENDING_OPERATIONAL | | ALIGNERBOT | PENDING_ALIGNERBOT |

(还存在一个 PENDING_LAB_MANAGER 值,但技工所管理员和 DSO 管理员在选择角色时立即激活 —— 审批环节不适用于他们.)

实际运作

新用户在 app.cympha.com/sign-up 注册.
在 Select Your Role 界面,他们选择想要的技工所端角色(如 Designer).
他们输入技工所管理员的邮箱并进行查找. 技工所管理员必须已有 Cympha 账户 —— 如果找不到该邮箱,应用会提示,并请员工先让管理员注册.
账户以 PENDING_* 角色创建,请求出现在技工所管理员 My Team 页面的 Approval Requests 下.
技工所管理员打开 My Team、看到待定行、点击 Approve.
用户的角色从 PENDING_* 翻转到真实角色. 在下次页面加载时,他们获得技工所端外壳.

如果请求发给了错误的技工所,或员工改变了主意,他们可以自己撤回 —— 待定界面提供 Cancel request & resubmit,将他们带回角色选择,以选择不同的技工所或角色.

各角色能做什么 —— 快速矩阵

| 角色 | 提交病例 | 批准设计 | 分诊队列 | 设计 | 运行 AlignerBot | 制造 | 发货 | 批准团队请求 | |---|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:| | CUSTOMER | 是 | 是 | — | — | — | — | — | — | | LAB_MANAGER | — | — | 是 | — | — | — | 是 | 是 | | LAB_ADMIN | — | — | 查看 | — | — | — | — | — | | DESIGNER | — | — | 自己的 | 是 | — | — | — | — | | ALIGNERBOT | — | — | 自己的 | (经由代理) | 是 | — | — | — | | CASE_INTAKER | — | — | 自己的 | — | — | — | — | — | | MANUFACTURING_ENGINEER | — | — | 自己的 | — | — | 是 | — | — | | OPERATIONAL | — | — | — | — | — | — | 是 | — | | DSO_MANAGER | — | — | — | — | — | — | — | — | | PATIENT | — | — | — | — | — | — | — | — |

"自己的"指该角色仅看到分配给自己的病例;"查看"指对技工所队列的只读可见性. DSO_MANAGER 以只读方式查看其医生的病例.

各状态期望什么

要让按状态驱动的分配落到某处,技工所至少要在每个期望角色里有一名用户:

| 状态 | 期望角色 | |---|---| | Submitted | Lab Manager | | Intake Review | Case Intaker | | Designing | Designer、AlignerBot | | Awaiting Approval | 客户 | | Changes Requested | 上一位技工所工作人员 | | Escalated | Lab Manager | | Approved | Designer、AlignerBot、Manufacturing Engineer | | In Manufacturing | Manufacturing Engineer | | Shipping | Lab Manager、Operational |

较小的技工所只配 Lab Manager 和 Designer 也可以 —— 接收步骤被跳过,数字交付完全不需要制造工程师,而没有制造工程师时,物理制造轨道根本不会出现在该技工所的工作流中.

最近更新: 2026-07-30.