2. 线上诊疗流程建模与需求分析
线上诊疗不是把线下门诊简单搬到网页上，而是一条由患者、医生、药师、支付机构、配送方共同参与的业务链。要把它做成可落地的系统，第一步不是写代码，而是把“谁在什么条件下做什么、产生什么数据、交给谁”讲清楚。BPMN 负责把流程的时序、分支、事件和参与者边界画准，用户故事地图负责把流程中的功能点按用户活动组织成可排期的需求清单，两者结合，才能输出既符合业务逻辑、又能直接进入开发的需求规格说明。
一、先划定流程边界与参与者泳道
线上诊疗的完整闭环通常包含六个核心环节：问诊、复诊、开方、审方、支付、配送。建模前先确定参与者泳道，建议至少划分五条：患者、医生、药师、平台系统、配送方。支付机构可作为外部参与者单独标注，因为它的回调结果直接决定处方能否进入配送队列。
以一次典型的复诊开方为例，流程的起点是患者发起复诊申请，终点是药品签收。中间的关键判断点有三个：医生是否接诊、药师是否审核通过、支付是否成功。这三个判断点决定了流程的分支走向，也是需求分析中最容易遗漏异常路径的地方。
二、用 BPMN 表达主流程与异常分支
BPMN 的核心价值在于把“正常路径”和“异常路径”同时画出来。下面这张图展示了从复诊申请到药品签收的完整流程，包含医生接诊判断、审方通过判断、支付成功判断三条分支，以及超时未支付、审方驳回两条异常路径。
图中三条异常路径对应三类需求：拒诊后的申请退回与费用处理、审方驳回后的处方修改与重新提交、支付超时后的订单取消与库存释放。这些异常路径如果不在建模阶段明确，开发时就会出现“流程走不通”的返工。
三、用户故事地图：把流程拆成可排期的需求
BPMN 画的是“流程怎么走”，用户故事地图回答的是“系统要提供哪些功能”。用户故事地图的横轴按用户活动排列，纵轴按优先级分层。以复诊开方为例，横轴活动依次为：发起复诊、医生接诊、开具处方、处方审核、支付、配送、签收。每个活动下挂具体用户故事，按“必须做、应该做、可以做”三层排列。
| 用户活动 | 必须做（MVP） | 应该做 | 可以做 |
|---|---|---|---|
| 发起复诊 | 选择历史就诊记录、填写症状描述 | 上传检查报告图片 | 智能预填上次处方 |
| 医生接诊 | 查看患者资料、接诊/拒诊操作 | 图文消息实时提醒 | 接诊超时自动转派 |
| 开具处方 | 选择药品、填写用法用量、提交 | 常用处方模板 | 药物相互作用提示 |
| 处方审核 | 药师查看处方、通过/驳回 | 驳回原因标准化选择 | 审方规则引擎自动预审 |
| 支付 | 生成支付单、调起支付、回调确认 | 支付超时自动取消 | 多种支付方式聚合 |
| 配送 | 生成配送单、分配配送方 | 配送轨迹查询 | 预计送达时间计算 |
| 签收 | 确认收货、订单完成 | 用药提醒推送 | 复诊到期提醒 |
四、从故事到需求规格说明
用户故事本身不是需求规格，它只是需求的“占位符”。要落地，必须为每个故事补充验收标准和关键字段。以“处方审核”为例，验收标准应写明：药师在收到处方后 30 分钟内完成审核；驳回时必须选择标准化原因（如“剂量超限”“适应症不符”“重复用药”）；驳回后处方状态变更为“待修改”，医生端收到通知并可重新提交。关键字段包括处方编号、患者ID、医生ID、药品编码、审核状态、驳回原因码、审核时间戳。
五、需求规格说明的落地结构
最终输出的需求规格说明建议按以下结构组织：流程概述（含 BPMN 图）、参与者与系统边界、功能需求清单（按用户活动分组）、每个功能的验收标准、数据字段定义、异常处理规则、接口需求（支付回调、配送状态回传、电子处方流转）。其中接口需求最容易被低估，线上诊疗涉及支付机构、配送方、电子处方中心三方外部接口，每方的回调格式、超时时间、重试策略都必须在需求阶段明确。
把 BPMN 的流程逻辑和用户故事地图的功能拆解对齐后，需求规格说明就不再是一份“功能列表”，而是一份可以直接驱动开发、测试和验收的工程文档。下一阶段进入系统集成时，接口契约和状态机定义就可以直接从这份文档中提取。