1. 药物研发数据平台全景
药物研发数据平台并不是一个“把数据集中存起来”的数据库，而是一条贯穿十余年研发周期的数据供应链。理解它的第一步，是把新药从实验室到患者床旁的完整链条拆开，看清每个阶段产生什么数据、由谁产生、以什么形态存在、被谁消费，以及这些数据在阶段之间如何交接。只有先建立这张全景图，后续讨论的数据模型、主数据、血缘、权限与合规才有落脚点。
一、全流程数据流的六个阶段
典型的小分子或生物药研发可划分为六个数据阶段，每个阶段的数据形态和核心实体差异很大：
- 靶点发现与验证：产生基因组学、转录组学、蛋白结构、CRISPR 筛选、文献与专利数据。核心实体是基因、蛋白、通路、疾病关联。数据以组学矩阵、结构文件（PDB）、序列（FASTA）为主，体量大、非结构化程度高。
- 先导化合物发现与优化：产生化合物结构、活性数据（IC50、EC50）、ADMET 性质、构效关系。核心实体是化合物、靶点、实验批次。数据以化学结构式（SMILES/InChI）、剂量-响应曲线、实验记录为主。
- 临床前研究：产生药效学、药代动力学（PK）、毒理学、安全药理数据。核心实体是候选分子、动物模型、剂量组。数据以表格化实验数据、病理切片、报告文档为主，受 GLP 规范约束。
- 临床试验（I–III 期）：产生受试者、访视、不良事件、疗效终点、实验室检查数据。核心实体是受试者、方案、中心、药物批次。数据以 CDISC SDTM/ADaM 标准、EDC 表单、电子源数据为主，受 GCP 与 21 CFR Part 11 约束。
- 注册申报与上市审批：产生 CTD/eCTD 文档、数据集、审评问询与答复。核心实体是申报资料、数据集、变更记录。数据以受控文档、可追溯数据集为主。
- 上市后研究：产生真实世界数据（RWD）、药物警戒个例报告（ICSR）、回顾性队列、主动监测数据。核心实体是患者、暴露、结局、信号。数据以 EHR、理赔、登记队列、FAERS 报告为主。
这六个阶段并非线性串行，而是存在大量反馈回路：临床前毒理发现的问题会回退到先导优化，上市后信号会触发新的机制研究。平台必须支持这种双向、迭代的数据关系，而不是假设一条单向流水线。
二、平台边界：什么该进平台，什么不该进
架构工程中最容易被忽视的问题是边界。药物研发数据平台不等于把所有系统推倒重建，也不等于把所有数据都复制一份。合理的边界划分遵循三条原则：
第一，源系统保留其权威性。LIMS 是实验记录的权威源，EDC 是临床数据的权威源，EHR 是诊疗数据的权威源。平台不替代它们，而是通过受控接口获取数据，并在平台内建立跨源关联。平台存储的是“用于分析与决策的整合视图”，而非源数据的唯一副本。
第二，平台负责跨阶段的主数据与关联。化合物、靶点、受试者、研究项目、药物批次这些实体跨越多个阶段，需要在平台内建立统一标识与映射关系。例如一个化合物在化学信息系统中叫 CPD-1023，在临床前报告中叫“候选物 A”，在临床方案中叫“研究药物 X”，平台必须能把这些别名归一到同一主数据实体。
第三，平台不承担源系统的业务操作。平台不负责录入实验数据、不负责随机化、不负责电子签名。它承担的是整合、治理、服务与合规留存，业务操作仍由专业系统完成。
三、架构工程的核心挑战
从架构视角看，药物研发数据平台面临五类结构性挑战，它们不是运维问题，而是设计问题：
异构数据融合。组学数据是矩阵型、临床数据是关系型、化学数据是图结构、文档是半结构化。平台需要在保持各领域语义的前提下建立统一查询层。常见做法是采用“领域模型 + 统一标识 + 映射层”的三层结构，而不是强行把所有数据塞进一张宽表。
全生命周期追溯。监管要求能够回答“这个结论来自哪次实验、哪批数据、哪个版本的分析代码”。平台必须记录数据血缘（lineage），包括源系统、抽取时间、转换规则、分析脚本版本。血缘不是日志，而是可查询的一等数据。
合规与隐私。临床数据涉及受试者隐私，组学数据可能涉及遗传信息。平台需要在数据接入时完成去标识化或假名化，并保留再识别密钥的独立管控。审计追踪必须覆盖数据的创建、修改、删除与访问，且不可篡改。
规模与性能。一个中型药企的组学数据可达数十 TB，临床数据可达数亿条记录。平台需要区分热数据与冷数据，对高频查询建立物化视图或索引，对批量分析采用分布式计算，而不是让所有查询都走同一路径。
跨阶段协同。研发、临床、注册、PV 团队使用不同工具、不同术语、不同节奏。平台需要通过标准接口（如 CDISC、FHIR、ISA-Tab）和统一术语服务降低协同成本，而不是要求所有团队改用同一套工具。