送出的是患者，不是文件：虚拟患者模型 + 治疗意图，合一封装在 Cympha 病例中

与技工所协作最难的部分，从来不是扫描，而是翻译. 一例牙科病例本质上是患者口腔里的内容 加上你对该患者的思考——你打算拔除的牙、你会切的修复边缘、你在 CBCT 第 47 张切片上注意到的透射影. 传统的转诊单要求你把这两者压平成一组 STL 文件加上一段文字指令，再要求设计师把它重新拆解还原成一个工作空间.

每一步都会丢失信息. 技工所靠猜测理解 "trim distal of #14" 究竟是什么意思. 你收到一封请求澄清的邮件. 第一版设计回来后不太对. 修改的轮次开始.

我们重建了移交流程，把这个"压平"的步骤直接跳过.

病例 = 患者 + 治疗计划

在 Cympha Studio 里，你不是在拼一组文件. 你是在搭建一个 虚拟患者：扫描、CBCT、口内照片、咬合——全部配准到同一个工作空间. 你旋转它们，浏览 CBCT 切片，调整颜色与透明度，直到这具解剖学结构呈现出你想看到的样子.

接着，你把 治疗意图直接记录在这位虚拟患者身上：

在你计划拔除的牙上画一个圈——一道红色环线出现在截图上，自动落入病例图库.
在你想做的旋转上放一段距离测量——当你完成测量的那一刻，线段、标注以及你当时所在的画面会同时成为永久的视觉记录.
从你希望技工所评估的视角截一张图——相机视角随之保留.

当你在汉堡菜单点击 Create Cympha Case，整个虚拟患者 + 你在它身上做的所有标记会作为一份自包含的记录，进入一个新的 Cympha 病例. 技工所打开这个病例，继承到的是 患者本身以及你对患者的理解. 他们拿到的不是一堆要重新解读的文件——而是你看到的病例，连同已经附着其上的临床思路. Living Case 五个维度中的两个，就在这一次操作里完成了传递：3D——患者是一个模型，而不是一份文件清单；以及 Intent——过去只存在于你脑子里的临床判断依据.

这和"上传文件"的本质区别

一堆 STL 文件告诉技工所 患者长什么样. 它一句也没说 你注意到了什么、你在担心什么、你想让对方做什么. 技工所只能通过阅读你的文字医嘱来补上这一块——但文字对于空间推理来说是一种有损介质："将 #13 向近中旋转约 10°"听起来很精准，直到设计师试图在他面前的实际扫描里判断"近中"到底是哪个方向.

Cympha 移交用 承载临床意图的数据 替代了这个有损步骤：

**虚拟患者模型本身没有歧义. ** 同样的扫描、同样的 CBCT、同样的配准、同样的相机视角. 技工所看的是你看过的那位患者——不是重新导入的近似还原.

**治疗意图直接附着在模型之上. ** 截图上的一个圈告诉设计师"这颗牙、这个区域". 一段带画面的距离测量告诉他"这个尺寸、这个方向，这就是我测量时所见". 一个相机视角告诉他"从这里评估". 这些没有一项需要通过文字来翻译.

**尺寸推理被完整保留. ** 你测量的每一段距离都会自动捕获你当时确认它的画面——线段、标签、视角——直接出现在病例图库里，带有 Distance: X.XX mm 的注释. 复核者和设计师看到的是 测量本身的画面，而不是一个可能因为有人换了角度复测就偏差一毫米的数值. 数值背后的临床判断依据，与数值一起完成移交.

这会改变下游的什么

**更少的来回邮件. ** 当设计师能直接看到你圈出的那颗牙和你希望他评估的视角，"您这里是什么意思？"那封邮件就不必再发生.

**更少的修改轮次. ** 一次修改往往意味着设计解决的是另一个问题，而不是医生心里真正想解决的那个. 当医生的意图作为数据而不是文字传递时，设计第一次就解决正确问题的可能性大得多.

**患者获得结果的速度更快. ** 每一轮修改都要花几天. 每一封澄清邮件都要花几小时. 当病例从你停下的地方开始——同样的患者、同样的意图——设计可以推进而不必经历重建上下文的回路.

**对原始临床思路的还原度更高. ** 这是更微妙的一点. 一段文字医嘱压平了医生的思考；设计师再从文字里把它重新建起来. 一次虚拟患者移交，让医生的思考和患者一起被带过去. 回来的设计真正反映了你在椅旁会做的事.

**技工台不只是更快，而是更安心. ** 收益不是单向的. 设计师打开病例就能看到医生看到的东西，于是不再靠猜、不再写澄清邮件，也不再背着"把错的东西做得很好"这份隐隐的担忧. 这是病例两端共同获得的安心——也是一件技工所乐意署名的设计.

什么时候最能体现虚拟患者移交的价值

**需要骨缩减目标的种植病例. ** 缩减区域上的一个红圈 + 显示深度的距离测量 + 你希望技工所评估的相机视角——它们组合在一起，能说明任何一段文字段落都说不清的内容. 送出之前值得确认一件事：骨缩减导板在技工所一侧属于 Implant Master Studio 档位的能力，修复导板与组合导板则需要 Enterprise 档位.
**有明确牙移动意图的正畸病例. ** 圈出牙、测量计划的移动量、捕获咬合视图. 设计师看到的是你想要的移动意图本身，而不是对它的描述.
**关心边缘位置的冠/桥病例. ** 一张标注好预备体边缘终止位置的截图，加上锁定该边缘的相机视角，胜过几段"龈下、近中-轴向延伸至……"的描述.
**任何带 CBCT 的病例. ** Studio 可以在浏览器里读取整套 CBCT 序列——不需要账户，也不需要上传——而 CBCT 的视图状态会随包传递，设计师打开后落在你当时看的那一张切片上. 他看到的就是你标记过的同一处透射影、同一个根管、同一个解剖标志. 如果治疗方案本身要在 OrthoPlus 中基于这套 CBCT 来构建，技工所需要 Studio 档位：CBCT 与面部扫描输入并不包含在 OrthoPlus Starter 中.

不变的部分

你仍然通过 Cympha 标准的病例创建表单提交病例. 临床医嘱文字、技工所路由、按病例定价、与技工所经理的对话——全部不变. 虚拟患者 + 治疗意图的移交不替代上面任何一项；它只是给病例附加了一个比"一组文件"丰富得多的附件. 喜欢写详细文字医嘱的医生可以继续这样做. 喜欢用展示代替描述的医生，现在有了一条路径. 而 Studio 始终只是你查看与标注的地方，从来不是病例被签署批准的地方：审批仍然发生在 Cympha 中，在病例的 查看并审批 页面上——你会先看到文件与工单再签署，请求修改 与 上报给技工所主管 也都在那里.

病例可以在任何地方被打开

虚拟患者包在 Cympha 中是一类一等公民的可视文件. 在病例文件列表中，它就在 STL 与 GVW 旁边，带有 在 Cympha Studio 中打开 操作，而且对方不需要自己的账户就能打开. 把病例本身分享给转诊专家或同事，是按邮箱进行的只读共享：对方能看到病例和它的文件，但无法上传任何东西. 每一个文件、每一个标签、每一次状态变化都会写入病例只增不改的事件日志，几个月之后你仍然能看到是谁、在什么时候加了什么. 这就是 Living Case 的 People 维度：所有需要这位患者的人看到的是同一位患者，而且没有人能悄悄改动它.

接下来

我们还没完成. 自然的延伸方向：

在源 3D 场景中支持持久标注（而不仅仅是截图上的标注）.
一个"请求修改"的路径，让 Studio 同时打开医生最初的移交版本和技工所当前的工作版本，让关于修改的对话仍然发生在同一位虚拟患者上.
一个仅显示测量的视图，给任何只想看到尺寸记录、不想加载整个工作空间的人使用.

但这趟往返今天已经能跑通了. 如果你曾经觉得，到达技工所的并不完全是你在椅旁见到的那例病例——这就是把那条缝合上的路径.

*在 studio.cympha.com 打开 Studio，搭建虚拟患者，标记你的意图，然后在汉堡菜单中找 Create Cympha Case. 你需要先登录一个持有临床角色的 Cympha 账户——这是医生一侧的角色，在角色选择页面上只选一次，之后不可更改. 技工所一侧无需任何额外配置——封装后的病例格式在 Cympha 中默认就是可视类型. *