做药品数据管理的朋友应该都经历过这种场面供应商系统里叫“阿托伐他汀钙片”临床系统里写“阿托伐他汀”研发数据库里是“Atorvastatin Calcium”仓储那边拿着商品名“立普妥”而稽查要的ATC编码又是C10AA05。五套系统、五个叫法月底对账和药品追溯的时候全靠人工翻译一颗药从采购到处方要过手七八个表格每换一个环节就多一分出错概率。药品通用名、ATC、化学结构三种标识的统一管理本质上是给药企、监管机构、医院信息系统和研发平台搭建一套“同一种药全世界只有一个身份”的主数据底座。这个坑在药企数字化转型、合规建设、临床试验数据标准化、真实世界研究数据治理这些方向上都绕不开。医疗行业的数据流转天然是跨系统、跨机构、跨语言的生产端习惯用化学结构标识注册端用通用名报销和用药分析端用ATC编码。三个体系各自独立演进历史上并没有天然互通的“主键”所以要统一管理就必须找到一套能被多数环节认可的中枢标准。本文就沿着WHO INN数据方法论这条主线把三套体系之间的关系、拆解方法、建模思路和实操坑点一次讲透。1. 三种标识各自为政代价远比想象中高先说清楚一个现实这三种标识根本不是同一维度的东西。通用名回答“它叫什么”ATC编码回答“它治什么、在哪个治疗类别”化学结构回答“它在分子层面到底是什么”。它们组合在一起才能完整描述一个“药物实体”单拿任何一个出来做全局主键都会翻车。但翻车的程度不一样有些代价是可以接受的有些则会一路传导到临床决策。1.1 标识体系对比为什么不能靠商品名最直观的反面教材是商品名。商品名是商业资产同一个成分在不同国家、不同厂商手里的商品名五花八门。单说奥美拉唑市面上叫“洛赛克”的、叫“奥克”的、叫“LOSECT”的同一通用名在不同市场的商品名有几十上百个。药品追溯如果用商品名做主键等于让数据跟着商标走商标一变更整条数据链就断掉。再看CAS号它本身非常稳定但它区分得太细——同一种药的不同盐、不同水合物各有CAS号商业采购里“阿托伐他汀”和“阿托伐他汀钙”有时候会被当成两个物质有时候又被当成同一个东西这种粒度不一致让人非常头疼。把主流的标识体系放在一张表里对比问题就很清楚标识体系回答的问题典型示例稳定性是否适合做主键商品名“商品叫什么”立普妥、洛赛克差随商标变更不适合通用名INN“药物学名是什么”omeprazole高全球统一命名适合做中枢锚点ATC编码“属于哪个治疗分类”A02BC01高但会因分类调整变化适合做分类维度CAS号“化学物质注册号是什么”73590-58-6极高但区分过细适合做辅助标识InChIKey“分子结构哈希是什么”27位定长字符串极高结构唯一适合做结构判定从这张表能看出一个关键信息没有单一标识能覆盖所有使用场景所以“统一管理”不是选一个主键替代其他所有键而是建立一个以INN为锚、以结构为证、以ATC为分类维度的映射网络。主数据建模的第一原则是主键必须稳定、唯一、非商业属性WHO INN恰好满足前两条这也是为什么全世界的药物主数据项目几乎都绕不开它。1.2 为什么WHO INN是天然的“中枢节点”WHO INN的全称是International Nonproprietary Names for Pharmaceutical Substances即国际非专利名称由世界卫生组织统一协调全球范围内免费公开且不与任何厂商的商标权绑定。一个化合物一旦获得INN就等于拿到了全球通用的“学名”身份。注意INN不仅仅是一个命名清单它背后有一整套持续运转的命名评审机制这是它区别于其他字典类数据源的核心价值。三个体系之间的关系也很微妙。ATC编码表虽然由WHO奥斯陆协作中心维护但它的分类逻辑大量基于INN体系展开化学结构本身是物质的客观属性但一个结构要进入药理现实必须被赋予一个命名身份而这个命名身份在绝大多数场合就是INN。换句话说INN处在“语义层”和“分子层”的交叉点上向左对接ATC治疗分类向右对接化学结构事实。把WHO INN作为中心锚点两侧分别挂接ATC编码和结构信息是成本最低、通用性最强的统一路径也是我过去几个药物主数据项目一直沿用的核心思路。2. 拆解WHO INN命名体系词干、评审与数据获取既然要把INN当锚点就得先弄明白WHO INN这套体系是怎么运转的。它不是一个静态字典而是一套有语法逻辑、有评审流程、有状态变迁的持续更新系统。理解了内部机制后面做数据解析和冲突仲裁才有依据。2.1 INN词干体系命名是一门语法而不是字典很多人刚开始接触INN数据时会误解以为INN就是一本“取名词典”一个药一个名字背下来就行。实际完全不是这样。INN的后台是一套完整的命名语法核心是词干stem体系。词干指的是药物名称中表示药理类别的固定片段。例如“-statin”代表HMG-CoA还原酶抑制剂所以阿托伐他汀atorvastatin、瑞舒伐他汀rosuvastatin都带这个尾巴“-sartan”代表血管紧张素II受体拮抗剂氯沙坦losartan、缬沙坦valsartan因此同类“-prazole”代表质子泵抑制剂奥美拉唑omeprazole和埃索美拉唑esomeprazole一眼就能看出属于同一家族。这套体系的精妙之处在于它把命名从“背单词”变成了“按语法造词”。结构相似的药名称天然相似哪怕不熟悉药理学的人看到词干也能大致判断类别。对药监部门来说审批时看词干就能快速核对作用机制和类别是否匹配对做数据管理的人来说词干体系还提供了一个天然的“解析线索”新药入库时哪怕官方ATC编码还没发布光看INN词干也能预判其治疗学分类。这里有一个实操细节容易踩坑词干并不总在词尾。单抗类生物药的词干“-mab”通常在词尾但有些词干会出现在名称中间或开头这给自动解析增加了复杂度。我们在自研词干解析脚本时维护了一张“词干位置属性表”逐一标注每个词干是前缀型、后缀型还是中缀型再对INN名称做带位置的子串匹配。实测下来这套方案对INN List的覆盖度能到九成以上剩下的靠人工复核兜底。2.2 INN的评审流程与命名状态INN的命名状态分两种建议INNProposed INN简称pINN和推荐INNRecommended INN简称rINN。一个新化合物先由WHO通过《国际非专利名称建议清单》公示为pINN经过一定周期的意见征集后再在《推荐清单》中转为rINN。从数据管理的角度这两种状态都必须收录但使用逻辑完全不同pINN相当于“暂定名”适合在研发早期阶段使用rINN才是公认的正式名称是注册、上市、编码映射等场景的权威依据。整个评审周期通常是12到18个月。大致时间线是企业向WHO INN专家组提交申请附带化学结构、药理学数据和拟用名称及命名理由WHO专家组审议名称是否与现有INN冲突、是否符合词干规则通过后先公示为pINN公示期满且无异议再转为rINN同步发布在WHO Drug Information上。对企业研发部门来说pINN有时会早于上市审批两到三年所以做研发信息库的同学一定要把pINN和rINN都建索引否则新药真正上市时会面临“临时换名”引发的连锁数据改动。2.3 如何结构化获取INN数据WHO官方发布的INN List有PDF和Excel两种格式定期在WHO官网的“INN and classification of medical products”栏目下更新。我强烈建议直接下载Excel版本解析速度比PDF高一个数量级而且字段完整度很好。除了INN名称和评审状态清单里通常还包含ATC编码、INN词干、CAS号、化学结构式、分子式等字段已经足够支撑主数据建模的初始数据源。解析时有几个点必须注意。第一INN List里的名称是全小写拉丁字母而很多药监系统和供应商系统习惯首字母大写做匹配时要做大小写归一化统一转成lower_case再建唯一索引同时保留原始大小写用于展示。第二同一个INN可能会出现在pINN清单和rINN清单两个历史版本中要注意按“最新状态”字段做覆盖而不是简单追加。第三Excel里有些行的字段是合并单元格或跨行重复的用pandas读取后要做前向填充不然会造成大量空值。3. ATC编码与化学结构的标准化策略INN解决了“叫什么”的问题接下来要把“怎么分类”和“分子是什么”两个维度也标准化。ATC编码负责前者化学结构标识负责后者。这两个维度看起来简单实际操作中它们的坑一点都不比INN少。3.1 ATC分类的逻辑层级与多编码现象ATCAnatomical Therapeutic Chemical分类体系把药物按“解剖学-治疗学-化学”三个维度逐层归类一共五级结构上很像图书馆的索书号。以奥美拉唑为例一级A代表“消化道和代谢”二级A02代表“消化性溃疡和胃食管反流病用药”三级A02B代表“抗溃疡药”四级A02BC代表“质子泵抑制剂”五级A02BC01才是奥美拉唑的完整分类号。这个树形结构天然适合做层级查询也适合做治疗领域的聚合分析。但ATC有一个数据管理上经常踩的坑同一种物质可以有多个ATC编码。最经典的例子是阿司匹林作为解热镇痛药时的ATC编码是N02BA01作为抗血小板药时是B01AC06同一物质因为适应症和临床用途不同被分到了两个不同的治疗分支。二甲双胍也类似既有单方编码A10BA02又在多种复方制剂条目里作为组分出现。所以“一个INN对应一个ATC”这种假设在真实世界里根本不成立数据模型必须把两者设计成多对多关系否则后面合并数据时要么丢分类、要么丢物质。3.2 化学结构标识InChI优先、SMILES辅助、CAS兜底化学结构的标识主流有三个方案InChI、SMILES、CAS号。我的个人排序是InChI优先SMILES辅助CAS号兜底。原因很简单InChI由IUPAC维护对结构的表达是规范化且确定的同一个结构只要输入正确生成的InChI字符串一定唯一。尤其InChIKey是一个27字符的定长哈希非常适合做大表关联和去重索引。SMILES表达方式太灵活同一个分子可以有多种等价写法虽然经过canonical标准化后差异会缩小但不同工具算出来的canonical结果仍有细微出入直接做主键不太稳妥。CAS号本身稳定但它在盐、水合物、异构体上区分得过于细致——同一种药的不同盐各有CAS号——而且官方全量查询有商业授权限制做主数据主键会有数据封闭风险。实际操作中建议用RDKit或Open Babel把结构统一转为“标准InChI InChIKey”分子一致性判断也用InChIKey做比对而不是直接比较SMILES字符串。比如对乙酰氨基酚的InChIKey是RZVAJINKPMORJF-UHFFFAOYSA-N不管上游数据来自ChemSpider还是PubChem只要最终InChIKey一致基本可以判定是同一个分子实体。这种“结构哈希”的思路是解决各数据源名称不同但分子相同这类问题的最可靠手段。3.3 工程化工具链与批量初始化经验结构标准化这块我推荐三样东西RDKit处理SMILES规范化PubChem PUG REST API做批量检索OpenChemLib或CACTVS做结构校验。PubChem接口支持一次性POST多个InChIKey批量查询每天有公开限额但常规项目量级足够了。返回结果里包含canonical SMILES、IUPAC名、CAS号等多个字段非常适合做主数据初始化时的“补充字段”回填。另外提一个体感用在线网站查单个结构很方便但做主数据初始化时动辄上千个化合物手工操作完全不现实一定得写成脚本。我通常的流程是先从INN List里取出全部INN名称批量跑PubChem检索拿回InChIKey后统一入库再用ATC/DDD Index官方数据逐条挂接ATC编码最后对识别失败或结构不一致的记录生成人工复核清单。整个初始化流程一天内能跑完效率比手工翻网站高两个数量级。4. 统一管理的数据模型与映射实操前面讲的都是标准怎么理解、数据从哪来这一章进入正题建表、做映射、定流程。很多项目做到这里就崩了原因不是不懂标准而是没把实体关系设计清楚。INN、ATC、化学结构、商业产品这些概念混在一张表里后面必然出一堆脏数据。4.1 三层模型物质层-编码层-产品层要同时容纳INN、ATC、化学结构并且不丢失商业产品的粒度我建议把数据模型拆成三层物质层Drug Substance、编码层Identifier Mapping、产品层Drug Product。物质层记录“这个分子本身是什么”主键是drug_substance_id核心字段包括inn_name、inn_status、inchi、inchi_key、molecular_formula、molecular_weight、canonical_smiles。这一层一个INN对应一行保证命名和结构一一对应。编码层专门存标识之间的映射关系字段有mapping_id、drug_substance_id、identifier_type、identifier_value、source_system、valid_from、valid_to。因为允许一个物质对应多个ATC这一层自然会产生多行如果要支持历史变化比如某个ATC编码在2019年调整过就用valid_from和valid_to做时间片管理。产品层则和商业产品、制剂规格绑定剂型、规格、盐类型、商品名、批准文号等一个物质可能对应多个产品一个产品也可能含有多个物质复方。这里用一个简化的DDL示例来说明核心设计CREATE TABLE drug_substance ( drug_substance_id VARCHAR(32) PRIMARY KEY, inn_name VARCHAR(128) NOT NULL, inn_status VARCHAR(16), -- pINN / rINN inchi TEXT, inchi_key VARCHAR(27) UNIQUE, canonical_smiles TEXT, molecular_formula VARCHAR(64), molecular_weight DECIMAL(10,2), is_biologic BOOLEAN DEFAULT FALSE, created_at TIMESTAMP ); CREATE TABLE identifier_mapping ( mapping_id BIGINT PRIMARY KEY, drug_substance_id VARCHAR(32) REFERENCES drug_substance(drug_substance_id), identifier_type VARCHAR(16), -- INN / ATC / CAS identifier_value VARCHAR(128), valid_from DATE, valid_to DATE, status VARCHAR(16) -- active / pending_ATC / retired );三层结构从逻辑上解决了另一个常见问题——“碱基和盐”的粒度冲突。INN指向的是碱基或活性部分而实际上市的产品往往是盐或酯的形式比如奥美拉唑镁和奥美拉唑是不同物质形式但治疗学上通常视为同一药物实体。产品层的salt_flag字段就是为这种场景准备的物质层保持“INN碱基”的纯净语义产品层记录盐型差异两层各司其职互不污染。4.2 冲突裁决机制以INN为锚、以结构为证合并多来源数据时难免遇到同一条记录在不同系统里对不上的情况。我归纳了一个三级裁决规则目前用了三个项目都没出过大问题。第一级看INN两边INN名经过大小写归一化后完全相同直接视为同一物质这是最高优先级判定。第二级看结构INN名不一致时比对InChIKey一致则判定为同一物质的不同别名。第三级看ATC当名称对不上、结构也拿不准时用ATC末级编码做辅助判断但不能单独作为合并依据。这个顺序不能颠倒。INN是命名权威结构是客观事实ATC是人为分类标签。命名和结构之间如果有冲突通常是数据采集错误结构和分类之间有冲突往往是分类标签滞后。我踩过的一个真实案例是某个供应商把埃索美拉唑esomeprazole错标成了奥美拉唑omeprazole两个INN完全不同但ATC分类都属于A02BC质子泵抑制剂大类下的相邻编码如果按ATC去合并就会把两种不同物质混成一条记录。只有先比对INN和InChIKey才能第一时间发现异常。4.3 新增药品的完整入库流程把上面的逻辑串起来我落地的新增药品入库流程大致是七步。第一步从申请方或文献收集原始名称、结构、适应症资料。第二步在INN List里检索INN名区分pINN和rINN状态记录收录年份。第三步用INN名批量跑PubChem回填InChI、InChIKey、CAS号。第四步在ATC/DDD Index官方页面查询对应ATC末级编码同时检查是否存在多分类情况。第五步把数据分别写入物质层和编码层InChIKey建唯一索引。第六步人工复核一批“多ATC”和“结构相似但INN不同”的特殊记录。第七步发布到下游系统并通知数据消费方。整个流程中最关键的是第一步就要确定好“物质级主数据”的粒度。很多团队做到一半把粒度偷偷换成了产品级后面盐型、剂型的差异全都混进主数据表清洗成本瞬间爆炸。记住一句话物质层只放“分子身份”产品层才放“商业形态”这个边界线守住了后面所有映射逻辑都会清晰很多。5. 常见问题与排查技巧实录最后分享一些实际项目里反复出现的问题和处理经验。这些内容基本不会出现在官方文档里但做数据治理的人十有八九会遇到。5.1 名称差异paracetamol vs acetaminophenINN不是唯一答案新手往往会以为INN是全球唯一标准实际还要注意其他命名体系的存在。很多国家还有美国药典采用的USAN名称美国采用的名称一些药物中USAN名反而更常见。最典型的例子就是对乙酰氨基酚INN标准名是paracetamol但美国的USAN名是acetaminophen国内药典也用了后者两边供应商各用各的如果只按INN名称匹配会因为“名字不同”漏掉同一条物质。这类问题在数据治理里叫“同名异实”或“异名同实”名称层面的匹配天然不可靠结构字段就是终极裁判。不管叫paracetamol还是acetaminophenInChIKey都是同一个值所以在映射表的INN字段之外一定要保留结构字段做第二道校验。每次跑完批量匹配后建议额外生成一份“名称不同但结构相同”的报告这类记录往往隐藏着最有价值的数据质量问题。5.2 ATC滞后与INN同步问题处理新药从获得INN到获得ATC编码通常有时间差。ATC/DDD Index每年1月发布更新版但新药的ATC编码往往要滞后一年甚至更久。在“空窗期”里研发数据平台不能干等。我们的做法是设计“临时编码槽位”机制在编码层暂存一条“INN 拟分类号参考词干推演 状态pending_ATC”的记录等官方ATC发布后再回填正式编码同时把状态改为active。这个方案比用自定义编号再全局替换要稳得多。下游系统只需要读取状态字段就能区分“临时分类”和“正式分类”历史数据追溯也不会断链。需要注意临时编码槽位里记录的“拟分类号”一定要备注推演依据最好是词干对应的治疗类别后面人工复核时能快速判断当时的推演逻辑是否合理。5.3 复方制剂与生物药的特殊处理复方制剂在INN体系里没有“复方名”每个活性成分各有自己的INNATC则存在专门的复方编码分支。处理时必须在编码层把“复方产品”建模为“多个物质 一个产品记录”不能在物质层把两个成分硬拼成一个INN。我们在实际项目里遇到过一次事故某同学把复方降压药的两个成分拼成了“XX-XX”作为物质名称入库结果下游所有用药分析全部串线最后花了三天才清理完。生物药更特殊。治疗性单抗的INN命名规则在2021年后有重大更新新获批的单抗不再通过前缀差异区分不同厂商的同类产品而是在核心名称上附加随机字母后缀。这意味着生物药的“结构等同性判断”不能只靠名称还得结合氨基酸序列、糖基化等更深层属性。化学小分子用的InChIKey对生物大分子完全不适用建模时至少要给biologic加一个“结构类型大分子”的标记位专门存放序列信息的引用地址别硬套小分子的结构字段。最后再多说一句实操经验。我在做历史批次清洗时习惯把“INN名一致但InChIKey为空”的记录单独拉出来生成待办清单因为这类问题绝大多数是结构字段没回填成功而不是真的同名异质。补跑一次PubChem批量接口后这部分记录的合并率能提升不少是性价比极高的一次清洗动作。药品主数据统一管理这件事标准只是地基真正决定项目成败的还是数据模型设计和那些不起眼的清洗细节希望这篇内容能帮你少踩几个坑。