2. 药物研发数据特征与合规约束
药物研发数据平台的第一道工程难题，不是“存不下”，而是“存得对、连得上、说得清、合规用”。同一款候选药物从靶点发现到上市后再评价，会依次产生多组学、临床前、临床和真实世界四类数据。它们在类型、规模、质量要求和法规约束上差异极大，却必须在平台内被统一标识、关联和治理。理解这四类数据的特征差异，是后续架构设计、元数据建模和权限控制的直接依据。
四类数据的类型与规模特征
多组学数据是研发早期的探索性数据，包括基因组（WGS/WES，单样本原始数据约 30–100 GB）、转录组（RNA-seq，每样本 2–10 GB）、蛋白质组、代谢组和单细胞数据。其核心特征是：单条记录价值密度低、总量极大、维度极高（单细胞可轻松达到数万细胞×数万基因的矩阵），且分析结果高度依赖参考基因组版本、比对工具版本和参数。因此多组学数据的“可复现性”本质上依赖完整的分析溯源，而非仅保存结果文件。
临床前数据来自体外实验、动物模型、毒理和药代动力学研究，类型高度异构：既有结构化的剂量-反应表、血药浓度时间序列，也有病理切片图像、流式细胞图和实验记录。规模通常在 GB 级，但格式碎片化严重，且大量数据以非结构化或半结构化形式存在。其质量要求集中在实验条件可追溯、动物个体标识唯一、剂量与时间点记录完整。
临床数据以受试者为中心，包括人口学、入排标准、访视、实验室检查、不良事件、合并用药和疗效终点。单项目规模通常在 GB 级，但字段规范严格，受 CDISC（SDTM/ADaM）等标准约束。临床数据的质量要求最高：任何字段缺失、日期逻辑矛盾或编码不一致，都可能影响统计分析和监管递交。
真实世界数据来自电子病历、医保理赔、可穿戴设备和患者登记，规模可达 TB 级。其特点是覆盖广、随访长，但缺失率高、编码不统一、时间戳精度参差，且存在选择偏倚。真实世界数据不能直接等同于证据，必须经过数据质量评估和适用性判断后才能用于监管决策。
质量要求的差异与工程含义
四类数据的质量维度并不相同。多组学关注可复现性：同一份 FASTQ 在不同参考基因组或比对参数下可能得到不同变异结果，因此平台必须记录参考版本、工具版本、命令行参数和运行时间。临床前关注可追溯性：实验条件、动物个体、给药剂量和时间点必须能回溯到原始记录。临床关注完整性与一致性：SDTM 域间日期逻辑、AE 与合并用药的关联、访视窗口偏差都需要规则校验。真实世界关注适用性：数据是否覆盖目标人群、缺失机制是否随机、编码映射是否可靠，直接决定能否用于监管级证据。
这些差异直接决定平台设计：多组学需要对象存储加分析工作流引擎；临床前需要灵活的非结构化数据接入与实验元数据模型；临床需要强 schema 校验和 CDISC 转换管道；真实世界需要大规模去标识化、编码映射和偏倚评估工具。用一套 schema 硬套四类数据，必然导致早期数据丢失溯源、后期数据无法递交。
法规约束如何落到平台功能
GxP（GLP/GCP/GMP）的核心要求是数据完整性，即 ALCOA+ 原则：可归属、可读、同时记录、原始、准确，外加完整、一致、持久、可获取。落到平台上，就是审计追踪不可关闭、电子签名与记录绑定、原始数据不可覆盖、时间戳由系统生成而非用户填写。任何允许用户直接修改数据库字段而不留痕的设计，都不满足 GxP。
HIPAA 针对美国受试者健康信息，要求对 18 类标识符进行去标识化，并区分“有限数据集”与“专家判定去标识”。平台需要支持字段级脱敏、最小必要访问和访问日志留存。需要注意的是，去标识化不等于匿名化，若仍保留就诊日期和邮编等准标识符，再识别风险依然存在。
GDPR 将遗传数据、生物识别数据和健康数据列为特殊类别个人数据，处理需满足更严格的合法性基础。其影响包括：数据主体享有访问、更正、删除和可携带权；跨境传输需有充分性认定或标准合同条款；同意必须具体、明确、可撤回。对多组学数据而言，基因数据天然具有唯一性和不可更改性，删除权在技术上极难彻底实现，因此平台更应在采集阶段就做好分层授权和用途限定。
一个可落地的数据质量检查示例
以下是一份针对临床数据入湖前的质量检查规则片段，用于在 ETL 阶段拦截明显问题。规则以配置形式表达，便于平台统一执行和审计。
rule_id: CLIN-DQ-007
domain: DM
description: 出生日期不得晚于知情同意日期
check: brthdtc <= rfstdtc
severity: ERROR
action: reject_record
rule_id: CLIN-DQ-012
domain: AE
description: 不良事件开始日期不得早于首次给药日期
check: aestdtc >= rfstdtc
severity: ERROR
action: reject_record
rule_id: CLIN-DQ-021
domain: LB
description: 实验室检查结果单位必须属于受控词表
check: lbtestcd in controlled_terminology(lbtestcd)
severity: WARNING
action: flag_for_review执行后，平台应输出每条规则的通过率、失败记录数和失败原因分布。若 CLIN-DQ-007 失败率超过 0.5%，通常意味着源系统日期字段存在录入或时区问题，需要回溯到采集端修复，而不是在入湖后强行清洗。这正是“质量要求差异”在工程上的具体体现：不同数据域、不同严重级别的规则，对应不同的处理动作和责任人。
合规约束下的数据流设计要点
综合来看，平台需要在数据流中同时满足三类约束：技术约束（多组学大文件、真实世界高吞吐）、质量约束（临床强校验、真实世界适用性评估）和法规约束（GxP 审计、HIPAA 去标识、GDPR 同意管理）。可行的做法是建立统一治理层，在数据接入时即打上来源、用途、敏感级别和同意状态标签，后续所有查询、导出和建模都基于这些标签做策略判断。这样，四类数据虽然特征迥异，却能在同一套合规框架下被安全地关联和使用。