2. 临床业务流程建模

医生工作站不是一张“能开医嘱的电子表单”，它嵌入在医院真实的临床业务流里。如果流程梳理不清，系统上线后最常见的现象是：医生在门诊界面找不到住院患者的过敏史，护士在急诊看不到门诊刚做的检验结果，手术申请单在科室之间来回退回。因此，临床业务流程建模是医生工作站建设的第一道设计工序，它决定了后续功能边界、数据流向和角色权限。

一、先分清五条核心流程的“触发—流转—终点”

医院临床业务看似庞杂，但医生工作站直接支撑的主干流程可以收敛为五条：门诊、急诊、住院、手术、会诊。建模时不要先画界面，而要先回答三个问题：流程由什么事件触发？中间经过哪些角色和状态？什么条件算流程终点？

以门诊为例，触发事件是“患者挂号并进入诊室队列”，流转节点包括：分诊叫号→医生接诊→问诊查体→开立医嘱/检查/检验→患者缴费→执行科室回写结果→医生复诊判读→开药或收治入院。终点是“本次就诊结束并生成门诊病历”。急诊流程的触发是“预检分诊”，其特点是时间敏感、状态跳转快，常出现“先抢救后补录”的逆向操作，因此建模时必须允许“绿色通道”状态先于缴费存在。住院流程的触发是“入院登记”，核心状态包括：入科→首次病程→日常查房→医嘱执行→出院评估→病案归档。手术流程的触发是“手术申请”，关键节点是术前讨论、麻醉评估、手术排台、术中记录、术后复苏与随访。会诊流程的触发是“会诊申请”，流转于申请科室、会诊科室和医务管理部门之间，终点是“会诊意见回写并关闭”。

二、业务对象识别：从“名词”里筛出可管理的实体

流程梳理完成后，下一步是把流程中反复出现的名词提取为业务对象。做法很直接：沿着上面五条流程，把每个节点上“被创建、被修改、被查询、被传递”的东西圈出来。门诊里反复出现的是“患者、挂号单、门诊病历、处方、检查申请单”；急诊里是“分诊单、抢救记录、留观病历、时间戳”；住院里是“住院病历、长期/临时医嘱、护理记录、体温单、出院小结”；手术里是“手术申请单、麻醉记录、手术记录、安全核查表”；会诊里是“会诊申请单、会诊意见、时限记录”。

识别出对象后，还要判断哪些是共享对象，哪些是流程私有对象。患者主索引、就诊记录、诊断、医嘱、检验检查结果、费用结算，这六类几乎贯穿所有流程，属于共享对象，必须由统一的主数据服务管理，不能各流程各建一套。而“分诊单”只属于急诊，“安全核查表”只属于手术，“会诊意见”只属于会诊，属于流程私有对象，可以放在各自模块内。这个区分直接决定了数据库表设计和接口边界：共享对象做中心化，私有对象做模块化。

三、用例建模：把“谁在什么条件下做什么”写清楚

用例建模不是画一堆椭圆，而是把参与者与系统的交互契约写清楚。一个可落地的用例描述至少包含：用例名称、主参与者、前置条件、触发事件、主成功场景、扩展场景、后置条件。以“医生开立长期医嘱”为例：主参与者是医生，前置条件是患者已入科且医生有该患者诊疗权限，触发事件是医生在住院医嘱界面选择“长期医嘱”，主成功场景是选择药品→录入剂量/频次/途径→系统校验过敏史与配伍禁忌→提交→护士站接收→药房摆药，扩展场景包括“过敏史冲突时弹出警告并要求双签”“药品库存不足时提示替代药品”，后置条件是医嘱状态变为“已下达”并进入执行队列。

用例之间的关系也要明确：包含关系表示某用例必然调用另一用例，例如“开立医嘱”包含“校验过敏史”；扩展关系表示在特定条件下才发生的分支，例如“开立医嘱”在药品缺货时扩展出“选择替代药品”；泛化关系表示特殊化，例如“临时医嘱”和“长期医嘱”都是“医嘱”的泛化。把这三类关系标清楚，后续做界面跳转和权限控制时就不会漏掉分支。

四、从模型到系统设计的检查点

完成上述建模后，用四个问题做自检：第一，每条流程的触发事件和终点状态是否唯一且可判定？第二，共享业务对象是否都有唯一标识和统一来源？第三，每个用例的扩展场景是否覆盖了临床常见异常，如过敏、缺药、权限不足、结果未回？第四，跨流程对象流转是否有明确的状态机，例如门诊“待缴费→已缴费→已执行→已回写→已判读”。这四个问题答清楚，医生工作站的流程建模才算真正完成，后续的界面设计、接口定义和权限配置才有可靠依据。