3. 远程医疗会诊业务需求分析

远程医疗会诊平台的建设，第一步不是选服务器、也不是画界面，而是把“谁在什么场景下、为了什么目的、和谁、按什么规则完成一次会诊”讲清楚。需求分析做不实，后面所有开发都在猜。本节围绕四件事展开：临床会诊场景梳理、用户角色与权限、业务流程建模、需求规格说明书编写。

一、临床会诊场景梳理

会诊场景不能笼统写成“医生发起会诊”。真实场景的差异体现在发起方、参与方、时效要求、是否跨机构、是否涉及影像这几个维度上。工程上通常先按“时效”和“范围”两个轴切分：

• 科内会诊：同一科室内部，针对疑难病例，通常当天完成，参与人数少，不跨机构。
• 院内多学科会诊（MDT）：肿瘤、心脑血管等病例，需影像科、病理科、外科、内科共同参与，需提前预约、准备资料。
• 院际会诊：基层医院向上级医院申请，跨机构、跨网络，涉及患者数据出域，是合规重点。
• 急诊/危重会诊：时效优先，要求分钟级响应，通常以音视频为主，资料可后补。
• 远程影像/病理读片会诊：以静态影像和报告为核心，异步为主，不强制实时视频。

梳理场景时建议逐条记录：触发条件、参与角色、时效上限、必需资料、是否留痕、是否收费。例如“院际急诊会诊”的时效上限可设为申请提交后 10 分钟内被受理、30 分钟内开始，这类量化指标直接决定后续的排班、通知和超时告警设计。

二、用户角色与权限

角色划分要落到“能看什么、能做什么、能改什么”。平台典型角色如下：

权限设计建议采用RBAC + 数据级授权双层模型：角色决定功能菜单，会诊单决定数据可见范围。专家被邀请进入某次会诊，才临时获得该患者数据的读取权，会诊结束后权限自动回收。这一点必须在需求中写明，否则容易出现“专家能翻看全院病历”的越权问题。

三、业务流程建模

会诊主流程可抽象为“申请—受理—准备—会诊—结论—归档”六个阶段。下面这张图给出的是院际会诊的状态流转与关键判断，重点表达状态之间的迁移条件和异常分支，而不是简单罗列步骤。

建模时要注意三点：一是状态必须互斥且可枚举，不能出现“进行中但已出结论”这种模糊态；二是每个迁移都要有触发者和触发条件，例如“待受理→已受理”由会诊管理员操作，条件是资料完整性校验通过；三是异常分支要显式建模，拒绝、退回、超时都是真实高频路径，不能只画理想流程。

四、需求规格说明书编写

需求规格说明书（SRS）是把上述分析固化为可评审、可追溯、可验收的文档。建议按以下结构组织，并保证每条需求都有唯一编号：

1. 范围与目标：明确本期建设覆盖哪些会诊场景，哪些不做。
2. 角色与权限矩阵：用表格列出角色×功能的授权关系。
3. 业务流程与状态机：附状态流转图和迁移条件表。
4. 功能需求：按模块编号，如 FR-01 会诊申请、FR-02 排期管理。
5. 非功能需求：性能、安全、合规、可用性，需量化。
6. 数据需求：患者标识、影像格式、报告字段、留存期限。
7. 接口需求：与 HIS、EMR、PACS、CA 的对接方式。

功能需求建议采用“编号 + 描述 + 优先级 + 验收标准”四段式。例如：

FR-03 会诊邀请与通知
描述：申请医生可邀请一名或多名专家，系统向受邀专家推送站内消息与短信。
优先级：高
验收标准：
1. 邀请提交后 5 秒内，受邀专家收到站内消息；
2. 受邀专家可在 10 分钟内接受或拒绝，拒绝需填写原因；
3. 超时未响应，系统自动提醒申请医生并允许改邀他人。

非功能需求同样要量化，否则无法验收。例如：

最后强调可追溯性：需求编号要能一路映射到设计文档、测试用例和验收记录。这样当会诊流程在后期发生变更时，才能快速判断哪些功能、哪些接口、哪些测试需要同步调整，避免“改了流程、漏了权限、错了日志”的连锁问题。