4. 医疗软件利益相关者分析

利益相关者分析是医疗软件需求工程的起点。医疗场景的特殊性在于：同一个功能，不同角色对它的期望可能完全相反。例如“病历修改”对医生是纠错手段，对监管机构却是合规风险点。因此，需求分析不能只问“系统要做什么”，而要先回答“谁在什么约束下使用它、谁为结果负责”。本节围绕角色识别、需求提取、约束提取和冲突消解四个动作展开，并给出可直接套用的分析表。

一、先分清三类角色，避免遗漏

医疗软件的利益相关者可分为三类。第一类是直接操作者：医生、护士、技师、药师、登记员，他们直接与界面交互，需求集中在效率、准确性、少点击。第二类是间接受影响者：患者及其家属、被会诊科室、后续接手人员，他们不直接操作系统，但系统输出会影响其安全与体验。第三类是约束施加者：医院信息科、医务处、医保部门、药监局、卫健委、数据安全负责人，他们不常使用系统，却决定系统能否上线、能否留存数据、能否对接。

识别时可用“角色—触点—关注点”三列法：先列出所有角色，再写出他们与系统的接触点（登录、查看、录入、审批、导出、被通知），最后写出他们最在意的一件事。触点能暴露隐藏角色，关注点能暴露隐藏需求。例如“被通知”这一触点会带出检验科、影像科等下游角色。

二、从角色到需求：用“场景+动词”提取

需求提取不要停留在“医生要方便”这类形容词，而要落到“谁在什么场景下对什么对象执行什么动作，期望什么结果”。下面给出一个可复用的提取句式：

角色 + 场景 + 对象 + 动作 + 期望结果 + 约束条件
示例：
护士 + 夜班交接 + 患者医嘱 + 核对并签名 + 3秒内确认未执行项 + 必须留痕且不可代签
医生 + 门诊接诊 + 检验报告 + 调阅历史对比 + 同屏看到趋势 + 不得跨科室越权访问
监管机构 + 飞行检查 + 处方数据 + 导出近三年记录 + 字段完整可追溯 + 导出需审批并记录操作人

按此句式，每个角色通常能提取出 5～15 条候选需求。提取后要标注优先级和来源，来源用于后续追溯：这条需求是谁提出的、依据是什么。没有来源的需求在评审时最容易被推翻。

三、约束提取：比需求更容易被忽略

约束不是功能，而是功能必须遵守的边界。医疗软件的约束通常来自四个方向：法规约束（如电子病历保存期限、处方权限、知情同意）、安全约束（患者隐私、最小必要访问、审计留痕）、技术约束（必须对接院内 HIS/LIS/PACS、必须支持国产数据库、必须离线可用）、业务约束（门诊高峰并发、护士站不能停、医保结算时限）。

约束要写成可验证的句子。例如“系统要安全”不可验证；“所有患者数据访问必须记录操作人、时间、患者ID、访问字段，日志保存不少于6个月”才可验证。约束一旦可验证，就能转化为测试用例和验收标准。

四、冲突识别与消解：利益相关者分析的核心价值

医疗软件中最典型的冲突有三类。第一类是效率与安全的冲突：医生希望一键调阅，安全要求每次访问留痕并鉴权。消解方式通常是“默认最小权限+显式授权+异步审计”，既不让医生多点三次，也不放弃留痕。第二类是共享与隐私的冲突：会诊需要跨科查看，隐私要求最小必要。消解方式是“按就诊关系动态授权”，有本次就诊关系才可查看，关系结束权限回收。第三类是灵活与合规的冲突：临床希望自由文本，监管要求结构化。消解方式是“结构化字段+受控自由文本”，关键项必填，补充说明可自由填写但纳入质控。

消解冲突时，建议按“法规硬约束 > 患者安全 > 临床效率 > 操作便利”的顺序排序，并把结论写回需求表，注明被牺牲的一方和补偿措施。这样在评审时能解释“为什么没满足某角色”，而不是被当成遗漏。

五、可直接使用的利益相关者分析表

把上述动作固化成一张表，评审时逐行确认，能显著减少后期返工。下表为示例，字段可按项目裁剪。

六、从分析到落地：三个检查点

第一，角色覆盖检查：是否每个角色都有至少一条需求或约束？没有的角色要么被遗漏，要么确实无关，需明确说明。第二，约束可验证检查：每条约束能否写成测试用例？不能则继续细化。第三，冲突闭环检查：每个冲突是否有结论、被牺牲方和补偿措施？没有闭环的冲突会在上线后以投诉或整改的形式回来。

完成本节分析后，应产出一份角色清单、一份需求与约束表、一份冲突消解记录。它们将直接作为后续用例建模、架构权衡和验收测试的输入。角色识别得越完整，后面的需求变更就越少。