1. 药物研发主数据治理工程导论
药物研发是一项高度依赖数据连续性的知识密集型活动。从一个候选化合物的发现，到临床前研究、临床试验、注册申报，再到上市后变更，数据在数十个系统、上百个流程节点之间流转。如果每个系统各自维护一套“自己的数据”，研发团队就会陷入同一物质在不同系统里叫不同名字、同一试验在不同报表里对应不同编号的困境。主数据治理工程要解决的，正是这类跨系统、跨阶段、跨组织的“共同语言”问题。
一、课程目标与主数据的定义
本课程的目标不是讲一套抽象的数据管理理论，而是围绕药物研发的真实对象，建立一套可落地的治理方法：能识别哪些数据属于主数据，能为它们定义唯一标识与属性模型，能设计变更与分发机制，也能在系统集成和审计场景中验证治理是否有效。
主数据（Master Data）通常指在多个业务过程中被反复引用、描述核心业务实体、且需要保持全局一致的基础数据。它区别于交易数据（如一次检测记录、一张领料单）和分析数据（如汇总报表）。判断一条数据是否属于主数据，可以看三个特征：是否被多个流程共享、是否具有较长生命周期、是否一旦不一致就会引发连锁错误。在药物研发语境中，化合物编号、靶点标识、试验方案编号、受试者标识、对照品批次、仪器设备编号等，都符合这些特征。
二、药物研发场景中的主数据范围
药物研发的主数据可以按“研究对象—研究活动—研究资源”三个层面来划分。
- 研究对象类：化合物/生物大分子、靶点、适应症、给药途径、剂型、晶型、盐型等。它们是研发活动的核心客体，贯穿发现、药理、毒理、临床各阶段。
- 研究活动类：项目、试验方案、研究阶段、访视、评估指标、实验室方法等。它们定义“做什么、怎么做、按什么标准做”。
- 研究资源类：受试者、研究者、研究中心、仪器设备、试剂/对照品、供应商、组织单元等。它们回答“谁来做、用什么做、在哪里做”。
这些对象并非孤立存在。例如一个化合物会关联多个靶点、多个试验方案、多个批次；一个试验方案会关联研究中心、研究者、受试者和检测方法。主数据治理的关键，就是把这些关联关系显式建模，而不是让它们散落在各业务系统的外键里。
三、治理工程的整体框架
治理工程可以理解为一条从“定义”到“消费”再到“反馈”的闭环链路。它包含五个相互衔接的环节：
- 主数据识别与范围界定：通过业务流程梳理和数据资产盘点，确定哪些实体纳入治理范围，明确优先级。
- 标准与模型设计：为每个主数据对象定义唯一编码规则、属性字段、值域、层级关系和生命周期状态。
- 采集与清洗：从现有系统抽取数据，做去重、归一、补全和冲突消解，形成可信的初始主数据集合。
- 分发与集成：通过接口、消息或批量同步，把主数据推送到各业务系统，并保证版本一致。
- 运维与度量：建立变更审批、数据质量监控和问题反馈机制，持续评估覆盖率、一致率和及时率。
这五个环节不是一次性项目，而是持续运营的工程能力。很多团队在“清洗”阶段投入大量人力，却忽略了分发和运维，导致几个月后数据再次分裂。
四、核心挑战与应对思路
药物研发主数据治理面临的挑战具有鲜明的行业特征。
第一，多源异构与命名冲突。同一个化合物在化学信息系统中可能以结构式存在，在药理系统中以内部编号存在，在临床系统中又以申办方代码存在。治理时不能简单“统一成一个名字”，而要建立“主标识+多别名”的映射关系，保留各系统原有编码作为交叉引用。
第二，阶段演进带来的属性变化。一个化合物在发现阶段只有结构和初步活性，到临床阶段会增加适应症、剂型、给药方案等属性。主数据模型必须支持属性随阶段扩展，而不是一开始就设计一张大而全的表。
第三，法规与审计要求。药物研发数据受GxP、ALCOA+等原则约束，主数据的每一次变更都需要可追溯：谁改的、什么时候改的、为什么改、影响了哪些下游记录。因此变更管理不是附加功能，而是治理框架的内置能力。
第四，组织协同与责任边界。主数据往往跨越发现、临床、注册、生产等多个部门，如果没有明确的数据所有者（Data Owner）和数据管理员（Data Steward），治理规则很难落地。
五、本节知识结构总览
下面的图示把本节涉及的核心对象、治理环节和挑战之间的关系集中呈现出来，便于在后续章节中反复对照。
从图中可以看到，主数据范围、治理闭环、核心挑战和下游消费方构成一个相互作用的整体。范围决定治理对象，闭环决定治理能力，挑战决定治理难度，而下游系统的反馈又反过来推动范围和规则的调整。后续章节将沿着这条主线，逐一展开识别方法、模型设计、清洗策略、分发机制和度量体系。