5.5 医疗与金融：跨机构联合分析

5.5 医疗与金融：跨机构联合分析

本节摘要：医疗与金融是监管最重、数据最敏感、协作收益也最明确的两个行业。本节以三个完整场景展开：跨医院罕见病联合统计（加密列联表与卡方检验）、基因组关联分析的加密计算（学术界竞赛的基准负载）、跨行联合风控（加密评分与黑名单碰撞），并讨论合规口径（匿名化认定、数据出境）与多中心部署的工程形态。

场景一：三所医院统计一个罕见指标

设定三家医院各持有本院的病历库，想联合回答"某基因标记在某罕见病患者群中的占比是否显著偏高"。单院病例数不足以达到统计显著性，交换明细数据又触碰隐私红线。协议设计走加密列联表路线：每家医院本地把自己的计数（分组单元格数）加密上传，云端在密文上把三份列联表逐格相加，返回加密的合计表；各家协作解密，得到合计列联表——只有总数，没有任何一家的分布。再进一步，卡方统计量的计算（涉及乘法与除法）也可以在密文上完成：乘法用整数线密文乘法，除法转化为乘逆元或预先把尺度因子扩大编码，最终只解密一个统计量与临界值的比较结果。

这个场景的选型要点值得展开。计数是精确整数语义，用整数线方案（第三章的判断标准直接套用）；列联表天然是小矩阵，打包摊销收益有限，维度档不必拉高；统计检验涉及的非线性（卡方分布的分位数比较）只需对固定的临界值做一次比较，可以在密文域做完多项式计算后，把"结果是否超阈值"作为一个比特交给布尔线或者干脆在最后一步解密单个中间量。整个计算的乘法深度在三五层内，常用档参数足够，不需要自举——性能上整个联合统计在分钟级完成，瓶颈往往在三家机构的审批流程而不是密码学。

# 加密列联表联合统计的骨架（整数线，接口形态参考主流库）
def joint_contingency(hospitals, cloud):
    enc_tables = []
    for h in hospitals:                        # 每家本地
        table = h.count_cells()                # 本地列联表（明文计数）
        enc_tables.append(encrypt_vector(table))   # 逐格加密上传

    total_ct = cloud.sum_ciphertexts(enc_tables)   # 云端密文逐格求和
    stat_ct = chi_square_homomorphic(total_ct, grand_total_plaintext)
    # 卡方分子在密文上算乘加；期望频数由明文总数派生（总数本身可公开）
    threshold_ok = compare_result(stat_ct)     # 与临界值比较，输出一比特
    return threshold_decrypt_and_report(stat_ct, threshold_ok)
​

骨架里的一个设计自由度是"公开什么"：总计数的公开（用于计算期望频数）通常可接受，各院分布保密；若连总计数都敏感，可以把它也留在密文域、用除法的同态近似完成。信息出口的粒度由业务与伦理委员会共同划定，这本身就是医疗数据协议设计的一部分。

场景二：基因组关联分析的加密计算

基因组数据的敏感性等级比病历更高（一次泄露终身有效、血缘亲属连带），而全基因组关联分析（标记与表型的相关性检验）是精准医学的核心工具。学术界的加密基因组分析竞赛为此提供了现成的基准负载与公开成绩，可以作为选型的锚点：竞赛任务包括加密逻辑回归训练、卡方检验、隐马尔可夫模型计算等，参赛系统的量级记录——加密逻辑回归在数万样本规模上训练收敛以小时计（优化的实现与硬件加速后进入更低的量级），加密统计检验以分钟计。这些数字的背后是明确的方案选择：回归类负载用近似线（梯度是浮点），检验类负载用整数线（计数精确），序列比对类负载切布尔线（动态规划的状态转移是比特级逻辑）——同一行业内三线并用，第三章的选型矩阵在真实负载上得到完整验证。

部署形态上，基因组场景发展出"密钥分层"的最佳实践：数据个体的原始测序数据用存储加密保护，进入分析的衍生标记由各机构分别加密，统计计算的中间密文只在计算节点流转，最终统计量由多机构门限解密。密钥分层的每一层对应不同的审批与访问控制策略——密码学结构映射组织结构，是这类系统设计的通用法则。

场景三：跨行联合风控

金融场景的需求形态与医疗不同：数据规模大（亿级客户与流水）、实时性要求高（毫秒到秒级的授信决策）、对手关系更复杂（协作方同时是竞争者）。三个高频需求对应三种同态用法。联合黑名单与灰名单碰撞是隐私求交的直接应用（上一节的算例原型）；联合评分是加密特征聚合——各方加密自己的特征分量，中心在密文上加权求和得到加密总分，解密仅在授信决策点发生；反欺诈的联合规则引擎在密文上执行阈值与组合逻辑，布尔线的可编程自举在此效率最佳。监管合规的口径要单独说：多方安全计算与同态加密在多数监管框架下被认定为"匿名化处理的技术手段之一"（因为任何单方都无法还原个体数据），但认定口径随法域变化，跨境数据流的场景（母子公司跨法域联合风控）要按更严格的口径预先评估，这不是技术问题而是法务与技术的联合设计问题。

多中心部署的工程形态

三个场景落到部署上有共性可提炼。其一，控制节点与计算节点分离：密钥与审批在机构侧，计算在独立云节点，网络拓扑按"密文进、密文出"设计。其二，审计接口前置：每类解密操作登记操作者、时间、密文哈希与业务理由，审计日志的不可篡改性可以用区块链或 append-only 存储保证（第五章第四节的技术反向服务了这里）。其三，性能预算按"审批等待是主要延迟"的现实来分配——把密码学优化到毫秒级对整体交付周期贡献有限，工程资源应优先投在协议清晰度与可审计性上。这个反直觉的结论在医疗金融两类项目中反复被验证，值得写进任何立项评估的开头。

⚠️ 常见坑：联合统计只加密了明细、把合计数当无害公开——某些低频场景下，合计数配合外部知识可以反推个体（小格子问题）。防御是设定最小单元格阈值（少于若干例的格子不出结果），这条规则在传统统计伦理里早已存在，搬到加密协议里同样有效。

本节要点回顾

• 要点一：跨院联合统计走加密列联表，计数用整数线、深度浅不需自举；信息出口粒度由业务与伦理委员会共同划定
• 要点二：基因组分析是三线并用的典型——回归近似线、检验整数线、比对布尔线；密钥分层映射组织审批结构
• 要点三：金融三需求三种用法——碰撞用求交、评分用加密聚合、规则引擎用布尔线；监管认定口径是联合设计问题
• 要点四：多中心部署三共性——控制与计算分离、审计接口前置、性能预算按真实瓶颈（审批）分配