3. 医疗合规与数据安全架构设计

医疗App的合规架构不是“上线前补一份隐私政策”就能解决的，它必须落到数据模型、接口边界、存储加密、访问控制和审计链路上。本节围绕三条主线展开：HIPAA、GDPR 与《个人信息保护法》（PIPL）的关键要求差异，医疗数据分类分级方法，以及隐私计算与脱敏方案如何嵌入架构。最后给出一份可执行的合规架构检查清单。

一、三套法规的关键要求与架构落点

HIPAA 主要约束美国境内的受保护健康信息（PHI），核心是隐私规则、安全规则与违规通知规则。它要求对 PHI 实施行政、物理和技术保障，技术保障中明确包括访问控制、审计控制、完整性控制和传输安全。GDPR 的管辖逻辑不同：只要处理欧盟数据主体的个人数据，就可能适用，医疗数据属于第 9 条“特殊类别数据”，原则上禁止处理，除非取得明确同意或满足医疗保健等例外。PIPL 将医疗健康信息归入“敏感个人信息”，要求单独同意、告知必要性、进行个人信息保护影响评估（PIA），并满足境内存储与跨境传输的额外条件。

三者的架构落点可以归纳为：数据最小化（只采集诊疗必需字段）、目的限定（一次采集不能无限复用）、可追溯（谁在何时以何目的访问了哪条记录）、可删除（支持数据主体删除与撤回同意）、跨境可控（数据出境评估与合同约束）。在系统设计上，这意味着不能把“用户同意”做成一个全局布尔值，而应做成按目的、按数据类别、按时间维度的授权记录。

二、医疗数据分类分级

分类分级是合规架构的起点。建议按“数据类别 + 敏感级别 + 使用场景”三维建模。类别可划分为：身份标识类（姓名、身份证号、手机号）、临床数据类（诊断、处方、检验检查、影像）、基因与生物特征类（基因序列、人脸、指纹）、支付与保险类、设备与日志类。敏感级别建议分为 L1 公开、L2 内部、L3 敏感、L4 高敏感。L4 包括基因数据、精神疾病记录、传染病记录、未成年人医疗数据等。

分级结果直接决定控制强度。例如 L4 数据在存储时必须使用独立密钥加密，访问需双人复核，导出需审批并加水印；L3 数据可单点授权访问但必须记录审计日志；L2 数据可做聚合分析但不可反查个人。分级不是静态标签，应随数据生命周期变化：原始影像在脱敏后可从 L4 降为 L3，但脱敏映射表本身必须保持 L4。

三、隐私计算与脱敏方案

脱敏解决“数据可用不可见”的基础问题，隐私计算解决“多方联合计算不泄露原始数据”的问题。常见脱敏手段包括：直接标识符删除（姓名、证件号）、准标识符泛化（出生日期→年龄段，邮编→前三位）、假名化（用稳定令牌替换患者ID）、差分隐私（在统计结果中加噪）。需要特别注意的是，假名化后的数据仍属于个人信息，映射表必须单独加密并限制访问。

隐私计算在医疗场景主要有三条技术路线：联邦学习适合多医院联合训练模型，各方数据不出域，只交换梯度或模型参数；安全多方计算（MPC）适合联合统计与匹配，例如跨机构重复参保核查；可信执行环境（TEE）适合需要集中计算但要求硬件隔离的场景。以联邦学习为例，某示例配置中，三家医院各持 2 万条糖尿病随访记录，采用横向联邦，每轮本地训练 5 个 epoch，学习率 0.01，通过安全聚合上传梯度，中央服务器只聚合不接触原始数据。评估时观察全局模型 AUC 是否接近集中式训练基线，同时检查梯度中是否可反推出个体信息。

四、合规架构设计检查清单

以下清单可直接用于架构评审。每项应给出“是/否/不适用”及证据位置，避免只做口头确认。

落地时建议把上述检查项嵌入 CI/CD 与架构评审门禁：新增数据字段必须填写分级与目的；新增接口必须声明访问的数据级别；新增第三方合作必须完成 PIA。合规不是文档工作，而是持续运行的控制系统。只有把法规要求翻译成数据模型、密钥策略、访问策略和审计事件，医疗App才能在业务迭代中保持可审计、可解释、可追责。