4. 医疗App安全需求分析与隐私影响评估

医疗App的安全与隐私工作，不能等到开发完成后再补测试，而应在需求阶段就把“保护什么、防住谁、做到什么程度”转化为可验证的工程约束。本节围绕三条主线展开：用需求工程方法把模糊的合规要求拆成可测试的安全需求；用隐私影响评估（PIA）与数据保护影响评估（DPIA）流程识别高风险处理活动；最后通过一个医疗场景演练，把模板落到具体字段与判断依据上。

一、从合规条款到可验证的安全需求

需求工程的核心动作是“分解”与“可验证化”。以《个人信息保护法》中“处理敏感个人信息应取得单独同意”为例，它不能直接作为开发任务，需要拆成若干可测试条目：App在采集病历、基因、生物识别等敏感信息前，必须弹出独立于通用隐私政策的同意界面；该界面需明确列出信息类型、处理目的、保存期限；用户拒绝时，相关功能应降级而非整体不可用；同意记录需包含时间戳、版本号、用户标识并留存可审计日志。这样每条需求都能对应一个测试用例，而不是停留在“要合规”的口号上。

常用做法是建立需求追溯矩阵：左侧是法规条款或内部隐私政策条目，中间是拆解后的安全需求编号，右侧是验证方式（代码审查、渗透测试、日志抽查、界面走查）。医疗场景还应额外引入“最小必要”判断：例如在线问诊只需症状描述与既往史，不应默认索取通讯录或精确位置；若确需位置用于推荐附近药房，应提供手动输入城市作为替代路径。

二、隐私影响评估与数据保护影响评估流程

PIA偏重“隐私风险”的全面识别，DPIA则更聚焦“高风险处理活动”的系统性评估，二者在医疗App中通常合并执行。流程可归纳为五个阶段：触发判断、处理活动描述、风险识别与评级、缓解措施设计、复审与留档。

触发判断先回答“是否属于高风险”：涉及敏感医疗信息、大规模用户画像、自动化决策、跨机构共享、向境外传输、持续大规模监控等情形，均应启动DPIA。处理活动描述要写清数据流：从哪个入口采集、存于哪类存储、经过哪些内部系统、共享给谁、最终如何删除。风险识别常用“可能性×影响”二维评级，例如“未授权访问病历”可能性中、影响高，则风险等级为高，必须设计加密、访问控制与审计三重缓解。

三、DPIA模板的关键字段

一份可执行的DPIA模板不必追求篇幅，但字段必须能支撑判断。建议包含：处理活动名称与负责人；数据主体类别（患者、家属、医护人员）；数据类别（身份信息、健康信息、生物识别、支付信息）；处理目的与法律依据；数据来源与接收方；存储位置与保留期限；跨境传输情况；已识别的风险及等级；缓解措施与剩余风险；用户权利实现方式；审批人与复审日期。

其中“剩余风险”最容易被忽略。缓解措施不可能把风险降为零，例如加密能降低泄露影响，但无法消除内部人员越权查询。因此模板应要求填写“缓解后风险等级”，并明确是否可接受。若剩余风险仍为高，则需上报隐私负责人或暂停该处理活动。

四、医疗场景案例演练

假设某医疗App新增“在线复诊开方”功能，用户上传既往病历，医生在线开具电子处方，处方流转至合作药房。按DPIA流程演练如下。

触发判断：涉及健康敏感信息、处方流转至第三方药房、可能包含未成年人，属于高风险，必须启动DPIA。

处理活动描述：用户端采集病历图片与文字描述；App服务端OCR识别并结构化存储；医生端调阅并开方；处方经接口推送至药房；药房回传配送状态；会话结束后180天匿名化。

风险识别：病历图片可能包含身份证号等额外信息，OCR后进入数据库，存在超范围留存风险；药房接口若字段过宽，可能泄露诊断详情；医生账号若共享，审计无法定位到人。

缓解措施：上传前提示用户遮盖无关信息，OCR后自动检测并脱敏身份证号；药房接口仅传处方编号、药品、剂量、配送地址，不传诊断文本；医生账号一人一号并绑定执业编号，操作日志留存不少于6个月。

五、把评估结果回写到需求

DPIA不是一次性文档。评估中发现的“药房接口字段过宽”应转化为安全需求：接口字段白名单、传输加密、接收方审计权。每条缓解措施都应有责任人与完成时限，并在版本发布前由隐私负责人复核。这样，需求工程与隐私影响评估形成闭环：法规→需求→设计→验证→复审，医疗App的隐私保护才真正可落地、可审计、可迭代。