查了三年药，我发现自己一直在错误的地方找ATC编码。刚开始做药物利用研究那会儿，组里只要有人问"这个药的ATC是多少"，我第一反应就是开浏览器、翻各种转载的PDF、碰运气式地搜关键词。运气好的时候能搜到，运气不好搜出来的还是十年前的老版本，甚至张冠李戴。直到后来系统地接触了世界卫生组织（WHO）的ATC/DDD分类体系和对应的检索路径，我才意识到：ATC药品分类怎么查，其实是有标准答案的，差别只在你会不会用对工具。
这篇文章想把这条完整路径讲透。从ATC分类为什么存在、五层编码怎么看，到官方索引的正确查法、真正能提效的在线库和本地化方案，最后用几条实际查询流程带你走一遍，再把高频翻车点一次说清。适合刚接触药物编码的临床药师、做药品使用研究的研究生，以及所有需要在系统里维护药品主数据的同行。
1. 这个被反复问起的问题，背后藏着整套医药数据基石
1.1 先理解ATC到底在给药品编排什么
ATC是"Anatomical Therapeutic Chemical"的缩写，中文通常叫"解剖-治疗-化学分类系统"。它做了一件看起来很简单、但至今没有替代品的事：给每一种药品的有效成分分配一个全球统一、含义分层的编码。
这套编码由WHO主导维护，具体执行机构是WHO下属的专门合作中心，专门负责ATC代码体系和DDD体系的更新发布。每年年初发布一次新版本，所有医药相关的国际交流、药品消耗统计、药物经济学研究，基本都以它为准。
你可以把ATC理解成药品的"国际身份证号"。和身份证一样，它有固定位数、有规律可循，同一个成分在世界各国查出来都是同一个编号。这样一来，德国开出的处方、中国医院的用药记录、日本的研究论文里提到的同一个药，就能用同一个编码对齐。
1.2 谁在使用这套编码，用到什么程度
很多人以为ATC只是医药统计员的事，实际远不止。
临床药师做药物利用评价（DUE/DUR）时，需要按ATC分组统计不同治疗类别下的用药量，判断处方合理性；医院药事管理做抗菌药物使用强度分析时，更是离不开ATC编码和DDD值的计算；医保部门和药企做药物经济学评价时，也需要用ATC把同类药物拉齐对比。
我做药品主数据清洗那段时间，几乎每天都要用到ATC编码来合并来自不同数据源的药品名称。同一个成分，中文名叫"硝苯地平"，英文资料里可能叫Nifedipine，厂商资料里则可能显示"拜新同""Adalat"这类商品名，只有ATC编码能把它们牢牢绑在同一个分子上。这就是为什么检索工具的好坏，直接影响整个数据管线的工作效率。
提示：ATC是成分级别的分类体系，不是产品级别。同一成分不同厂家、不同剂型的产品共享同一个ATC编码，但剂型和给药途径会影响DDD值的选取。
2. 五层编码结构拆解：从"消化系统"读到"二甲双胍"
2.1 每一层代表什么意思
ATC编码总共5层，从大类到具体分子逐步收紧，像快递地址一样逐级定位。
- 第1层：1个英文字母，表示解剖学主群，也就是药物作用的器官或系统。从A到V共有14个主群，比如A代表消化道和代谢，B代表血液和造血器官，C代表心血管系统，N代表神经系统。
- 第2层：2位数字，表示治疗学亚群。比如A10就是"糖尿病用药"，C08就是"钙通道阻滞剂"。
- 第3层：1个英文字母，表示药理学亚群。注意这一层已经在按药理机制细分了，比如A10B表示"口服降糖药，除外胰岛素"。
- 第4层：1个英文字母，表示化学亚群。继续按化学结构或作用机制细分，比如A10BA表示"双胍类衍生物"。
- 第5层：2位数字，定位到具体的化学物质。这一层才出现真正的药物成分。
所以一个完整的ATC编码形如：A10BA02。5层信息全部压在这7个字符里，这是它高效之处，也是新手最容易看走眼的地方——每一层都代表不同的分类维度，不能跳层解读。
2.2 拿二甲双胍完整走一遍编码过程
我用最常用的降糖药二甲双胍来演示。它的ATC编码是A10BA02，逐层拆解如下：
| 层级 | 编码片段 | 含义 |
|---|---|---|
| 第1层 | A | 消化道和代谢（Alimentary tract and metabolism） |
| 第2层 | A10 | 糖尿病用药（Drugs used in diabetes） |
| 第3层 | A10B | 降血糖药物，除外胰岛素 |
| 第4层 | A10BA | 双胍类（Biguanides） |
| 第5层 | A10BA02 | 二甲双胍（Metformin） |
这套逻辑最大的好处是：看到A10BA02这个串，哪怕你不认识Metformin，也能立刻判断它属于双胍类口服降糖药。同理，看到C08CA01，即使一时想不起药名，也能判断它是二氢吡啶类钙通道阻滞剂（硝苯地平、氨氯地平都属于这个家族）。
2.3 DDD：查ATC时一定会碰到的另一半
WHO这套体系里，ATC编码从来不是独立存在的，它总是和**DDD（Defined Daily Dose，限定日剂量）**成对出现。DDD指"用于其主要适应症的成年人每日平均维持剂量"，单位通常是毫克（mg）或克（g）。
为什么查ATC一定会碰到DDD？因为ATC编码给出了"这是什么药"的答案，而DDD给出的是"这个药用多少算一天的量"的答案。两者结合，才能计算用药强度、进行跨药物比较。
比如查询结果里写着A10BA02 Metformin 2 g O，意思是二甲双胍的DDD是2克，O代表口服给药。做抗菌药物使用强度分析时，公式分母用的就是这个DDD值。后面讲工具使用时，我会再强调DDD字段的几个坑。
3. 官方查询的完整路径：WHO索引的正确用法
3.1 找到权威源头
很多人一上来就去搜索引擎敲药名加ATC，搜出来的结果可能来自转载博客、课件截图、二手数据库，版本新旧无从考证。做严谨的事，第一站必须是对的地方。
WHO官方维护了一个公开的ATC/DDD索引页面，全称叫"WHO ATC/DDD Index"，每年更新，是最权威的核验基准。打开后在检索框里输入英文药物成分名，就能看到该成分的全部ATC信息。
整个过程分为三步：
- 明确你要查的是成分名（国际非专利名，INN），不是商品名。查"布洛芬"就输入Ibuprofen，不要输入"芬必得"。
- 进入官方索引后，在搜索框里输入成分名，选择包含该成分的ATC条目。
- 查看条目下的完整信息，包括层级路径、DDD值、给药途径、ATC代码。
- 核对版本年份。官方索引首页会标明当前版本年份，确保你引用的和你项目里用的是同一版。
3.2 搜索结果页的字段怎么读
官方索引单条记录通常包含几部分核心内容，我逐个说明：
- ATC代码：5层完整编码，也就是最终需要写入数据表的字段。
- 层级路径：从第1层拉丁/英文主组名到第5层药物名的完整展开，方便理解归类逻辑。
- DDD值：包括数值、单位、给药途径缩写。其中给药途径的缩写很有讲究，O代表口服（oral），P代表胃肠外（parenteral），R代表呼吸道（respiratory），D代表皮肤（dermal）等。
- 备注：有些药物会标注"该DDD对应特定给药途径或特定适应症"，这类备注容易被忽略，但往往最关键。
举个例子，查询结果可能是这样的一段：
B01AC06 Acetylsalicylic acid 100 mg O，括号里的备注还会写着"用于抗血栓"之类的限定说明。这说明阿司匹林的这个ATC编码对应的DDD 100mg口服，是基于心血管抗栓这个主要适应症设定的。
3.3 官方路径的三个限制与应对
官方索引虽权威，实际用起来有几个硬限制，得提前知道：
- 只有英文检索。官方索引不提供中文界面，中文资料里的药名需要先转成INN英文名，对不熟悉英文药名的同行有些门槛。
- 不支持按ATC模糊搜索。官方索引更适合"已知药名查编码"，反过来"已知ATC编码查药名"也可以用，但它不支持"查一下所有钙通道阻滞剂有哪些"这类批量浏览需求。
- 页面交互偏老派。逐条点击查看，效率不高。大批量药品需要核对时，用官方页面一条条点会非常痛苦。
所以，官方索引适合做单药核验和不定期抽查，一旦涉及批量数据处理，就该切换到下一节讲的提效方案。
4. 真正提效的检索方案：在线库、批量接口与本地映射表
4.1 在线快捷查询的场景与用法
如果是偶尔查几个药，很多公共药物数据库其实都带了ATC字段。这类数据库的特点是把官方索引的原始数据做了二次加工，有的补充了中文名称，有的增加了商品名映射，有的还支持按ATC层级浏览目录。
我日常最常用的是"先中文名转INN，再在带ATC字段的公共数据库里确认"这个组合。比如我要查"奥美拉唑"，先在中文资料里确认英文名Omeprazole，再去公共数据库里核对ATC是否为A02BC01。这样两道校验下来，比单纯依赖一个来源可靠得多。
需要提醒的是，使用这类在线库时务必留意两点：一是看它的数据版本标注，确保和官方当前版本一致；二是优先选择明确标注"数据来源为WHO ATC/DDD Index"的站点。数据溯源不明的地方，再方便也不敢直接用。
4.2 批量场景：接口与数据文件
如果手里有几十上百个药要一次性核对，一个个在网页上查就太低效了。更合理的做法是拿到WHO索引的底层数据文件，做一次本地导入。
WHO合作中心对外发布ATC/DDD数据的方式包括年度更新的数据集和部分开放接口。实际项目中，我会把官方数据文件下载后导入数据库，建一张表，字段至少包含atc_code、substance_name、ddd_value、ddd_unit、route、version_year。之后所有查询都在这张本地表上进行：
-- 按药名查ATC SELECT atc_code, substance_name, ddd_value, ddd_unit, route FROM atc_index_2025 WHERE lower(substance_name) = lower('metformin'); -- 按ATC前缀查同类药物 SELECT atc_code, substance_name FROM atc_index_2025 WHERE atc_code LIKE 'A10BA%';第二条SQL特别实用。查"所有双胍类药物"，不用去官网翻目录，一条SQL就出来了。遇到需要按治疗大类汇总统计的场景，还可以直接用LEFT(atc_code, 3)做分组。
4.3 本地映射表怎么搭才不失控
本地建表最大的风险，是"数据版本漂移"和"手工改数失控"。我见过好几个项目组，本地表里混着2020版、2022版、2025版的数据，同一个药出现两个ATC编码，互相矛盾。
这里分享一个我踩过坑之后固定的建表习惯：
- 每次导入必须记录版本年份。表里加一个
version_year字段，全量导入时统一填同一年份。 - 保留原始导入字段，禁止直接改库。业务上名称有误或者需要补充中文名，一律在映射层（比如另一张关联表）处理，不动原始ATC表。
- 每次升级版本做差异对比。新旧版本之间哪些编码新增、哪些删除、哪些DDD值变了，生成一份diff清单留档。这比事后发现问题再回溯要省事十倍。
这样搭建的本地表，既是查询工具，也是后续所有业务数据清洗的基准层。
4.4 按场景选型：一张对比表
| 需求场景 | 推荐方案 | 理由 |
|---|---|---|
| 偶尔查一两个药 | 官方索引 + 公共数据库双重核验 | 权威且零成本 |
| 批量核对几十个药 | 本地导入官方数据文件后用SQL查 | 快、可复现、可留痕 |
| 系统接口间持续调用 | 官方索引数据定期同步 + 缓存 | 避免频繁请求外部依赖 |
| 日常药品主数据维护 | 本地映射表 + 版本diff清单 | 可控、可靠、可审计 |
5. 完整实操演示：三条典型查询路径跑通
5.1 单组分药物：标准三步走
以沙丁胺醇（Salbutamol）为例，完整走一遍：
第一步，确认成分的英文INN名。中文资料、商品名（如"万托林"）都不是查询入口，INN才是。这里确定为Salbutamol。
第二步，去官方索引或本地表检索。官方索引返回结果会显示R03AC02，层级路径为：R（呼吸系统）→ R03（阻塞性气道疾病用药）→ R03A（吸入用肾上腺素类及其他）→ R03AC（选择性β2-受体激动剂）→ R03AC02（沙丁胺醇）。
第三步，记录DDD和给药途径。吸入剂型和口服剂型虽然都归在R03AC02，但DDD值不同，必须按实际使用剂型选取对应记录。这一步如果做错，后续所有剂量换算都会错。
5.2 复方制剂怎么查
复方制剂是新手最容易卡住的地方。记住一条核心规则：ATC编码分配给有效成分，不分配给复方产品。复方产品本身可能也有自己的ATC码（专门用于复方制剂的分类），但更多时候，复方药的有效成分各有各的ATC编码。
举一个常见例子，阿莫西林克拉维酸钾片。这个产品里有阿莫西林和克拉维酸两个有效成分，做成分级分析时要分别查：
- 阿莫西林：
J01CA04（J为抗感染药，J01为抗菌药，J01C为β-内酰胺类青霉素，J01CA为广谱青霉素，04为阿莫西林） - 克拉维酸：
J01CR02组合条目的一部分，或者单独看属于J01CR（青霉素类复方含β-内酰胺酶抑制剂）
具体归到哪个码，取决于你的业务目的是成分统计还是产品分类。做药物利用研究时，通常按产品的ATC主编码归类，但做成分级安全性分析时，则要分别编码。这一点在开始统计分析前就必须定清楚，不然后期返工成本极高。
5.3 一药多码：以阿司匹林为例讲清逻辑
同一个有效成分，在不同适应症下可能拥有不同的ATC编码，这是整个体系里最重要、也最反直觉的规则之一。
阿司匹林就是最典型的例子：
| 适应症定位 | ATC编码 | 说明 |
|---|---|---|
| 抗血栓（心血管预防） | B01AC06 | B为血液系统，B01为抗血栓药 |
| 解热镇痛（普通止痛） | N02BA01 | N为神经系统，N02为镇痛药 |
同样是乙酰水杨酸这个分子，放在心脏科语境里是抗血小板药，放在疼痛科语境里是解热镇痛药。所以查询时必须先明确你关注的适应症，再决定引用哪个编码。国内医院信息系统里常见的情况是：同一盒阿司匹林肠溶片，住院医嘱里按B01AC06统计，门诊止痛场景则可能涉及N02BA01。数据治理时如果不区分语境，统计口径就会打架。
6. 查得越快越要小心：四个高频翻车点复盘
6.1 版本更迭导致的旧码失效
ATC编码也会变动。每年新版发布时，有些编码会新增，极少数会被拆分或调整。如果本地表多年不更新，就会出现"用旧码统计、对不上新报告"的尴尬。
我习惯每年第一季度做一次全量同步，并跑一遍新旧diff，重点关注三类变化：新增编码、删除编码、DDD值修改。DDD值的修改尤其隐蔽，因为它不影响编码结构，只在数值上微调，肉眼很难发现，但会影响用药强度指标的计算结果。
6.2 DDD单位与给药途径的混淆
同一成分不同剂型的DDD值可能不同，DDD单位也可能不同。比如有的药口服剂型DDD以毫克计，注射剂型则以克计，混用单位得出的统计结果完全不可比。
更隐蔽的是给药途径缩写。O和P差一个字母，药物暴露量和日剂量逻辑完全不同。查询时务必把route字段一并记录下来，别只抄一个数值走人。我建议所有建表需求中，都给DDD提供独立的ddd_unit字段，不要用"剂量"这种含糊说法替代。
6.3 拼写、盐基与商品名的干扰
英文药名的拼写差异也是高频坑。同一个成分可能有美式拼写和英式拼写，比如"acetaminophen"与"paracetamol"其实是同一个分子但分属不同地区命名体系。ATC查询时需要先锁定为准的INN名再查。
另外要注意盐基问题。官方索引中有的条目按碱基命名，有的按盐类命名，搜索时如果带上了盐酸盐、硫酸盐之类的后缀反而可能查不到。建议搜索时先从简单形式开始，比如先查"Metformin"，查不到再试"Metformin hydrochloride"。
6.4 形成自己的核查清单
走完这么多弯路之后，我给自己定了一条硬规矩：任何ATC查询结果，至少要过三关才算完成——一是来源关，必须核对是否来自官方索引或明确标注官方数据来源的数据库；二是版本关，确认引用的是哪一年版本，是否和项目口径一致；三是语境关，确认该药物在此场景下的适应症定位是否与所选编码匹配。
这三关每过一关都会花一两分钟，但就是这几分钟，帮我在后续统计汇报里躲开了绝大多数的数据返工。我也建议看到这里的同行，不管用在线库还是本地表，都把这套三关核查沉淀成自己的肌肉记忆。
最后再分享一个操作习惯：我会在本地表里专门建一个"备注"字段，每一条从网上核验来的ATC记录，都顺手记下核验日期和核验来源。这个习惯刚开始觉得多余，后来做历史数据回溯时，才发现当初随手记的备注直接省掉了一整轮重新核验。高效检索工具的意义不在于让你省掉核对，而在于让你把核对变成一件有记录、可追溯的常规动作。
