2. 互联网医院平台需求分析与业务建模
互联网医院平台的需求分析，不能从“要做一个挂号功能、要做一个处方功能”这样的功能清单出发，而应当从两条真实的主线出发：一条是患者就医旅程，另一条是医生执业流程。这两条主线在平台上交汇，交汇点就是业务场景，而业务场景背后沉淀下来的，才是可被系统承载的核心业务对象。本节的任务，就是把这两条主线拆开、对齐，再用用例图、活动图、领域模型三种工具把它们固化下来，最终输出患者、医生、排班、问诊、处方、订单这六个核心对象及其关系。
一、患者就医旅程：从“有症状”到“拿到药”
患者侧的需求，本质是一条带有明确阶段目标的旅程。以一次典型的线上复诊为例，可以拆成六个阶段：症状感知与信息获取 → 选择医院与医生 → 挂号/预约 → 候诊与问诊 → 获得处方与购药 → 用药随访。每个阶段患者关心的东西并不相同：第一阶段关心“我这个情况能不能线上看”，第二阶段关心“哪个医生擅长这个病、什么时候有号”，第三阶段关心“能不能约到、要花多少钱”，第四阶段关心“医生什么时候回我、能不能说清楚”，第五阶段关心“处方能不能开、药怎么送到”，第六阶段关心“吃完有没有效、要不要复诊”。
把这条旅程翻译成需求，就会得到一组关键业务场景：线上复诊资格校验（判断患者是否属于常见病、慢性病复诊，是否在本院有过就诊记录）、医生检索与排班查询、号源锁定与支付、图文/视频问诊、处方开具与药师审核、药品下单与配送、随访与复诊提醒。注意，这些场景不是并列的功能点，而是有先后依赖的：没有复诊资格校验，后面的问诊和处方就缺少合规前提；没有排班，号源就无从产生；没有问诊记录，处方就没有依据。
二、医生执业流程：从“出诊”到“完成诊疗”
医生侧的需求与患者侧并不对称。医生的核心诉求是在合规前提下高效完成诊疗，并留下可追溯的医疗记录。其执业流程可以概括为：排班设置 → 接诊 → 问诊与病历书写 → 诊断与处置决策 → 开具处方/检查 → 审核结果与随访。
这里有两个容易被忽略的工程细节。第一，排班不是简单的“几点到几点”，它需要区分号别（普通/专家）、号源类型（图文/视频）、单次问诊时长、可接诊上限、停诊与替诊规则。例如某三甲医院互联网医院设置：某副主任医师每周二、四 19:00–21:00 开放视频复诊，单次 15 分钟，每时段放号 8 个，提前 7 天 08:00 放号。这些参数直接决定了号源生成逻辑和患者可预约范围。第二，处方不是医生单方面行为，它必须经过合理用药审查和药师审核，形成“医生开方 → 系统审方 → 药师复核 → 处方生效”的链路，任何一环不通过，处方都不能流转到订单。
三、用三种模型把需求“钉死”
需求分析如果只停留在文字描述，开发阶段一定会出现理解偏差。业务建模的价值就在于用三种互补的模型把需求固定下来。
用例图回答“谁在什么边界内做什么”。参与者包括患者、医生、药师、平台运营、支付网关、物流系统；系统边界是互联网医院平台；用例则对应上面识别出的业务场景，如“预约挂号”“发起问诊”“开具处方”“审核处方”“支付订单”“查询物流”。用例图的作用是快速对齐范围，避免把“医院 HIS 内部结算”这类不属于本平台边界的用例画进来。
活动图回答“一件事按什么顺序发生、有哪些分支”。以“线上复诊开方”为例，活动流为：患者提交复诊申请 → 系统校验复诊资格（不通过则终止并提示线下就诊）→ 患者选择医生与号源 → 支付挂号费 → 进入候诊队列 → 医生接诊并问诊 → 医生书写病历、下诊断 → 医生开具处方 → 系统合理用药审查（不通过则退回医生修改）→ 药师审核（不通过则退回）→ 处方生效 → 患者确认处方并生成订单 → 支付 → 药房调配/配送。活动图把“分支条件”和“退回路径”显式画出来，这正是需求评审时最容易漏掉的部分。
领域模型回答“系统里到底有哪些对象、它们之间是什么关系”。这是本节最重要的输出。下面这张图给出了六个核心业务对象及其关系，可以作为后续数据库设计和接口设计的共同语言。
四、六个核心对象及其关系说明
结合上图，可以把六个对象的关系讲清楚：
- 患者与排班：患者通过预约行为占用排班中的号源，一个排班可被多个患者预约，但号源数量受“可接诊上限”约束。
- 医生与排班：医生是排班的归属主体，一个医生可以有多个排班，一个排班只属于一个医生；排班是医生执业时间在系统中的数字化表达。
- 排班与问诊：排班产生号源，患者预约号源后进入候诊队列，医生接诊后生成一次问诊记录。因此问诊是“排班 + 患者 + 医生”三者交汇的产物。
- 问诊与处方：一次问诊可以开具零到多张处方（例如同时开中药和西药），但每张处方必须且只能关联一次问诊，保证处方可追溯到具体诊疗过程。
- 处方与订单：处方生效后生成订单，一张处方对应一张订单（若拆方配送则可能一对多，需在订单中记录拆方标识）。订单承载金额、支付状态、配送信息。
- 患者与订单：患者是订单的支付主体，订单金额来源于处方明细，形成“诊疗—处方—支付”的完整闭环。
五、从模型到需求清单的落地方法
实际项目中，可以按以下顺序推进：第一步，用患者旅程和医生流程各画一条泳道，标出所有交互点；第二步，把交互点整理成用例清单，并标注优先级（如“复诊资格校验”为 P0，“随访提醒”为 P1）；第三步，对 P0 用例逐个画活动图，重点确认分支和异常路径；第四步，从活动图中抽取名词，归并成领域对象，画出类似上图的领域模型；第五步，用领域模型反查用例，确认每个用例都有对象承载，每个对象都有用例驱动。经过这五步，需求就不再是一堆零散的功能点，而是一张有结构、可追溯、能指导开发的业务地图。