2. 医疗业务流程建模标准

医疗流程建模的难点不在于“把图画出来”，而在于选对标准、用对扩展，并让模型能被引擎执行、被系统集成、被临床接受。BPMN 2.0、CMMN、HL7 FHIR 与 DICOM 工作列表分别解决不同层面的问题：BPMN 描述可预测的流程编排，CMMN 描述知识工作者驱动的案例，FHIR 承载临床与工作流数据，DICOM 工作列表负责影像设备与信息系统之间的任务分发。理解它们的边界与衔接方式，是后续引擎落地的前提。

BPMN 2.0 在医疗场景的扩展

BPMN 2.0 提供了任务、网关、事件、子流程、泳道等标准元素，适合表达“医嘱开立—审核—执行—计费”这类路径相对确定的流程。但医疗场景有三类特殊需求，标准元素无法直接覆盖：一是角色与权限的强约束，同一任务在不同科室、不同职称下可执行性不同；二是临床语义的附加信息，如医嘱优先级、标本类型、影像检查部位；三是合规留痕，关键节点必须记录操作者、时间戳与理由。

常见扩展方式有三种。第一，使用 BPMN 的 extensionElements 挂载自定义属性，例如在用户任务上增加 med:requiredRole、med:orderPriority、med:auditLevel。第二，通过 dataInputAssociation 与 dataOutputAssociation 绑定 FHIR 资源，使任务输入输出有明确的数据契约。第三，用边界事件与补偿事件表达医疗异常，如“标本溶血”触发重采、“患者拒绝”触发流程终止并记录原因。

<userTask id="reviewOrder" name="审核医嘱">
  <extensionElements>
    <med:requiredRole>主治医师</med:requiredRole>
    <med:orderPriority>STAT</med:orderPriority>
    <med:auditLevel>full</med:auditLevel>
  </extensionElements>
  <dataInputAssociation>
    <sourceRef>ServiceRequest/12345</sourceRef>
  </dataInputAssociation>
</userTask>

扩展的原则是：标准元素表达控制流，扩展属性表达临床语义，FHIR 资源表达数据。三者不要混用，否则模型既难被引擎解析，也难被临床人员理解。

HL7 FHIR 工作流资源

FHIR 不是流程引擎，但它定义了工作流中“谁在什么状态下处理什么”的资源模型。与流程建模最相关的资源包括：ServiceRequest（请求，如医嘱、检查申请）、Task（任务，承载状态与执行者）、Appointment（预约）、Encounter（就诊）、CarePlan（照护计划）。其中 Task 是连接 BPMN 与临床系统的关键：BPMN 用户任务可映射为一条 Task 资源，其 status 字段（requested、accepted、in-progress、completed、cancelled）直接对应流程实例中任务的生命周期。

一个典型的映射关系是：BPMN 流程启动时创建 ServiceRequest，进入用户任务时生成 Task 并指定 owner（执行科室）与 requester（申请医生）；任务完成时更新 Task.status=completed，并回写 ServiceRequest.status。这样流程引擎与临床系统通过 FHIR 资源解耦，引擎只关心状态迁移，业务系统只关心资源读写。

CMMN 案例管理模型

并非所有医疗流程都能预先画成固定路径。肿瘤多学科会诊、急诊复苏、复杂慢病管理这类场景，下一步做什么取决于当前病情、检查结果和医生判断，属于“知识工作者驱动的案例”。CMMN 正是为此设计：它用案例文件组织数据，用任务（而非流程节点）描述可执行动作，用哨兵（Sentry）定义任务激活与完成的条件，用里程碑标记阶段性目标。

CMMN 与 BPMN 不是替代关系，而是互补。实践中常见做法是：用 BPMN 描述确定性主干（如入院登记、出院结算），用 CMMN 描述主干之间的不确定诊疗活动，两者通过案例文件或 FHIR CarePlan 交换数据。选择判断标准很简单：如果路径可以事先穷举并强制执行，用 BPMN；如果路径需要根据实时信息动态决定，用 CMMN。

DICOM 工作列表集成

影像检查流程中，BPMN 负责“开单—预约—到检—报告”的编排，而 DICOM 工作列表（Modality Worklist, MWL）负责把检查任务推送到 CT、MR、DR 等设备。MWL 基于 DICOM C-FIND 服务，查询键通常包括 PatientID、AccessionNumber、Modality、ScheduledProcedureStepStartDate。设备操作员在控制台查询当日工作列表，选中患者后自动带入患者信息与检查参数，避免手工录入错误。

集成的关键点在于：BPMN 流程中“检查预约确认”节点完成后，需要向 MWL SCP（通常由 RIS 或 PACS 提供）写入或更新工作列表条目。写入内容应包含 AccessionNumber（与 ServiceRequest.identifier 对应）、RequestedProcedureID、ScheduledProcedureStepID 以及患者基本信息。检查完成后，设备通过 MPPS（Modality Performed Procedure Step）回传实际执行状态，流程引擎据此推进到“报告书写”节点。这条链路把流程引擎、RIS、PACS 和设备串成闭环。

建模工具选型

工具选型应围绕三个维度：标准支持度、引擎可执行性、医疗集成能力。仅画图不执行的工具适合沟通，但不适合工程落地；支持 BPMN 但缺少 CMMN 的工具无法覆盖复杂案例；缺少 FHIR 与 DICOM 适配的工具会把集成工作全部推给开发团队。