OnSIDES — 药品说明书不良反应结构化库

INFOBOX — OnSIDES 一屏速览

维度	内容
本质	用微调 PubMedBERT 从药品说明书自动抽取药物-不良反应对的机器可读结构化数据库
全称	ON-label SIDE effectS resource（标签内副作用资源）
团队	Cedars-Sinai 计算生物医学系 Tatonetti 实验室；通讯 Nicholas P. Tatonetti
论文	Med (Cell Press) 2025;100642；doi:10.1016/j.medj.2025.100642；PMID 40179876（前身 medRxiv 2024-03）
规模	主 README：7.1M+ drug-ADE pairs / 4,097 药物成分 / 51,460 标签（as of 2026-04）
数据源	DailyMed(US) + EMA(EU) + EMC(UK) + KEGG(Japan) 四国/地区药品标签
词表	药物→RxNorm（国际用 OMOP RxNorm Extension）｜不良反应→MedDRA PT
模型	单模型多节共用 PubMedBERT，HF 公开发布 tatonettilab/onsides-bert
关键指标	ADR 节 held-out F1 0.942 / AUROC 0.996；独立 hold-out F1 0.847；TAC 对照 v3.2.0 F1 89.87
姊妹库	OnSIDES-INTL（欧英日）｜OnSIDES-PED（儿科 359,213 pairs）｜OnSIDES-ANNOT（人工标注）｜OffSIDES（标签外）
获取	GitHub Releases（CSV flat files）+ 预构建 SQLite + onsidesdb.org 交互查询，全部公开无 gated
许可	双许可——软件 MIT；数据 CC BY 4.0（须引用论文署名）
更新	每季度更新；版本链 v1.0.0 → v2.0.0 → v2.1.0 → v3.0.0 → v3.1.1 → v3.2.0

§0 导读：这个数据集解决什么问题

药物不良反应（Adverse Drug Event, ADE）是一个规模惊人却长期被"碎片化"处理的公共卫生问题。按 OnSIDES 论文与机构通稿的表述，ADE 在美国是第四位死因（国际口径为第五位），每年造成数十亿美元的额外医疗支出；专家估计其中约一半是可以预防的。然而真正卡住研究进展的并非"没有数据"，而是没有机器可读的数据。

药物安全性信息其实一直存在——它藏在每一份药品说明书里。FDA 的结构化产品标签（Structured Product Label, SPL）以近乎法律文本的方式，逐条列出某药在临床试验与上市后监测中发现的不良反应、黑框警告（Boxed Warning）、警告与注意事项（Warnings and Precautions）。这些文本对人可读、对机器却是"半结构化荒地"：同一类副作用在不同标签里用词各异，一句"nausea, vomiting, and rarely pancreatitis have been reported"里混着频率限定、否定语境与严重度分级。传统药物警戒（pharmacovigilance）因此长期停留在"一种药一种药地查"的个案层面，难以做跨药物、跨类别的系统比较。

OnSIDES 的核心贡献，是把这道"文本 → 结构化"的坎用一个可复现的自然语言处理流水线跨过去。它的做法是微调 PubMedBERT——一个在海量生物医学文献上预训练的 BERT 模型——让它学会判断"标签文本里的某个词是不是在描述本药的不良反应"，然后把这个模型应用到美国 DailyMed、欧盟 EMA、英国 EMC、日本 KEGG 四个来源的全部人用处方药标签上，把抽取出的药物-不良反应对统一映射到 RxNorm（药物）与 MedDRA Preferred Terms（不良反应）两套标准词表。

于是，原本散落在几十万份 PDF/XML 里的副作用描述，被压缩成一张可以 SELECT ... JOIN ... 的关系表：药物是一个可索引的键，不良反应是一个可索引的键，"某药是否报告过某副作用"变成一行可以连接的数据。这正是论文所称的 computable / machine-readable database——不是又一个供人浏览的查询网站，而是可以被下游模型、知识图谱和统计流水线直接消费的数据底座。

这个底座打开了几类此前很难做的研究：其一，药物重定位与靶点预测——如果两种药在不良反应谱上高度相似，它们可能作用于相同通路，论文据此演示了从 ADE 谱相似性预测新靶点与适应症；其二，药物类别富集分析——某类不良反应是否在某一药理类别中系统性偏高；其三，从分子结构预测不良反应——把 ADE 当作监督标签训练化学信息学模型。

理解 OnSIDES 时必须同时记住它的三条边界。边界一：on-label 而非 off-label。 OnSIDES 只抽取"说明书上写了"的副作用，这意味着它反映的是监管文本的记载，而不是真实世界的因果证据；同一实验室另设 OffSIDES 专收标签外信号。边界二：抽取而非实验。 数据库里的每一对关系都是由一个 F1≈0.9 的模型预测出来的，官方反复强调"会漏、会误判"，并明确警告患者与医护不得据此用药。边界三：口径随版本漂移。 从 v2 到 v3，数据源从单一 DailyMed 扩到四国，规模从 3.6M 涨到 7.1M 对，指标口径也从"单节 F1"演进到"单模型多节 + 独立 hold-out"。引用任何一个数字，都必须连同它的版本与时点一起引用。

本条目接下来会依次拆解：它到底由哪些表、哪些数字构成（§2）；背后的 NLP 流水线为什么能做到 F1 0.9（§3）；评测指标该怎么读、有哪些坑（§4）；儿科/国际/标注三个补充库各自解决什么（§5）；许可是怎么"双轨"的、怎么拿到数据（§6）；它在药物警戒与知识图谱生态中的位置（§7）；方法学上能迁移什么经验（§8）；以及库内可以互链的条目（§9）。最后给出避坑清单（§10）、总结（§11）、FAQ 与硬事实清单。

§1 数据集速览：十问十答

Q1：OnSIDES 到底是什么？用一句话说清。
它是一个用机器学习从药品说明书里"读"出不良反应、并整理成数据库的公开资源。输入是 FDA/EMA/EMC/KEGG 的药品标签原文，输出是"药物—不良反应"关系表，药物用 RxNorm 编码、不良反应用 MedDRA 编码。

Q2：它和 SIDER 有什么区别？
两者都是药品标签副作用库，SIDER 是更早（v4.1）的文本挖掘库，OnSIDES 是其后继范式：用 BERT 而非词典/共现做抽取，且**是唯一纳入复方（多成分）药物、唯一多国（美欧英日）**的同类库。OnSIDES 论文直接拿 SIDER 4.1 作评测对照——在同一 TAC 金标准上，SIDER 4.1 的 F1 为 74.36，OnSIDES v2/v3 为 87.54、v3.2.0 达 89.87。

Q3：数据规模到底多大？
取决于你看哪个版本：论文 2024-02 口径 3,610,120 ADEs / 3,233 成分组合 / 47,211 标签；GitHub 主 README as of April 2026 口径 >7.1M pairs / 4,097 ingredients / 51,460 labels；onsidesdb.org 统计栏给 6,928,666 pairs / 1,866 ingredients / 41,119 products。三者是不同时点/口径，不是互相矛盾（详见 §2.1 与 §4.5）。

Q4：怎么拿到数据？
三条路都公开、都不需要 gated 申请：① GitHub Releases 下的 CSV flat files；② 一个预构建 SQLite 单文件库；③ onsidesdb.org 交互查询。仓库另供 MySQL/PostgreSQL/SQLite 的 create_tables.sql 与加载脚本。

Q5：许可是什么？能商用吗？
双许可：软件（代码/脚本）是 MIT；数据（数据库与全部发布数据文件，含 flat files、SQLite 库、人工标注）是 CC BY 4.0。CC BY 4.0 允许商用，但必须署名并引用论文（doi:10.1016/j.medj.2025.100642）。

Q6：模型是什么？准不准？
一个微调的 PubMedBERT，在 HuggingFace 以 tatonettilab/onsides-bert 公开。ADR 节 held-out（80/10/10 药物级划分 200 标签）F1 0.942 / AUROC 0.996；但在独立的 30 份 hold-out 标签上 F1 降到 0.847——官方强调这是更诚实的外推估计。

Q7：为什么强调"会漏、会误判"？
因为抽取是模型预测不是事实核对。官方 Limitations 原文写明：方法不完美，部分副作用会被漏掉，部分被预测为真副作用的其实是错的；并明确警告患者和医护不应信任或使用这些数据，而应查监管机构信息。

Q8：OnSIDES-PED / INTL / ANNOT 分别是什么？
PED：儿科特异性 ADE（359,213 pairs / 1,161 成分组合 / 20,014 标签），来自标签的 Special Populations 节；INTL：从欧英日标签抽取的国际 ADE；ANNOT：每国/每类别各 200 份人工标注，供训评模型。

Q9：更新频率？版本怎么走？
每季度更新。版本链：v1.0.0 → v2.0.0（2023-06-29）→ v2.1.0（2024-09-25，123MB）→ v3.0.0（引入 INTL/PED/ANNOT）→ v3.1.0 / v3.1.1 / v3.2.0。

Q10：谁该用、谁不该用？
该用：药物警戒研究者、生物医学 NLP/知识图谱团队、药物重定位与靶点预测研究者、做 ADE 监督学习的化学信息学团队。不该用：任何想据它做临床用药决策的人（官方明令禁止），以及把"标签记载"误当"因果证据"的因果推断场景。

§2 数据构成与规格

2.1 规模、来源与机构构成

OnSIDES 的数据来源是一条清晰的四源扩张路径。最初版本仅处理 DailyMed（美国 NLM 运营的 SPL 官方库）；v3 起扩展为四国/地区：

来源	区域	运营方	语言
DailyMed	美国	NLM / FDA SPL	英语
EMA	欧盟	European Medicines Agency	多语（英语为主）
EMC	英国	medicines.org.uk	英语
KEGG	日本	Kyoto Encyclopedia of Genes and Genomes	日语（用 MedDRA Japan）

对应的规模口径按版本分层（这是本条目的核心"多口径"知识点）：

口径来源	时点	drug-ADE pairs	ingredients	labels	备注
论文 / 机构通稿	2024-02	3,610,120 ADEs	3,233 成分组合	47,211	另含 114,322 Boxed Warning ADEs、4,510 唯一 ADEs
v2.1.0 发布 README	2023-11	>3.6M	2,793	46,686	仅 DailyMed
onsidesdb.org 统计栏	抓取时点	6,928,666	1,866	41,119 products	站点正文文案仍为 v2 时代
GitHub 主 README	2026-04	>7,100,000	4,097	51,460	四源 DailyMed+EMA+EMC+KEGG

三个数字并存的根源有二：来源数不同（单源 vs 四源）与计量单位不同（"成分组合"含复方口径 vs "RxNorm ingredient"口径）。论文的 3,233 明确拆为 1,873 单成分 + 1,360 多成分；GitHub 主 README 的 4,097 是 RxNorm ingredient 概念，随四源扩张而增长。它们不是同一个量，不能相减或直接比较。

机构构成方面，全部工作出自 Cedars-Sinai 计算生物医学系（Department of Computational Biomedicine）的 Tatonetti 实验室，系主任 Jason Moore 在机构通稿中为该资源背书。团队横跨临床信息学、生物医学 NLP 与化学信息学。资助来自 NIH 三项基金（R35GM131905、T15LM007079、T32GM145440，见 FACTS §3）——这也解释了为什么该资源能承诺季度更新：它有一个稳定的实验室运维而非一次性论文附录。

2.2 数据库表结构与关系模型

OnSIDES 现行（v3）数据库是七个表的关系模型，读它的关键是分清两组：

产品/数据表（product_ 前缀，来自标签原文抽取）：

1. product_label —— 每一个药品产品（drug product）一行，是标签级的主键表；
2. product_adverse_effect —— 抽取出的药物-不良反应对，外键分别指向产品与 MedDRA 术语；
3. product_to_rxnorm —— 产品到 RxNorm 产品的多对多映射。

词表映射表（vocab_ 前缀，来自 UMLS Metathesaurus 与 OMOP/Athena 词表）：

4. vocab_rxnorm_product —— RxNorm 产品概念；
5. vocab_rxnorm_ingredient_to_product —— RxNorm 产品到成分的多对多映射；
6. vocab_rxnorm_ingredient —— RxNorm 成分概念；
7. vocab_meddra_adverse_effect —— MedDRA 不良反应术语。

这个设计把"标签记载"与"标准词表"分层解耦：product_ 表保证可追溯到具体标签，vocab_ 表保证跨标签、跨国的可比性。一个研究者想"按成分而非按产品"聚合副作用，只需经 product_to_rxnorm → vocab_rxnorm_ingredient_to_product 两级 JOIN 把产品折叠到成分——这也正是官方主表 adverse_reactions（“按成分归组”）的实现方式。

RxNorm 编码的一个关键坑：vocab_rxnorm_product 与 vocab_rxnorm_ingredient 的 rxnorm_id 列对美国药物用标准 RxNorm 概念码，但国际药物（EU/UK/JP）往往没有标准 RxNorm 码，此时改用 OMOP 的 RxNorm Extension 词表，编码以 OMOP 为前缀（如 OMOP991424）。这意味着直接 GROUP BY rxnorm_id 会得到一串"看起来不像 RxNorm"的 OMOP 码——这是设计使然，不是数据损坏。

2.3 主表与历史表的行数口径

OnSIDES 的表设计里有一个容易被忽略但极重要的口径细节：每个数据表都有"活跃标签"与"全部标签"两个版本。

以 v2.1.0 为例：

表	行数	含义
adverse_reactions	129,624	主表：当前活跃标签、按成分归组
adverse_reactions_active_labels	3,061,873	活跃版本标签的全部抽取
adverse_reactions_all_labels	3,610,120	所有版本（含历史修订、仿制药等）的全部抽取
boxed_warnings	6,087	主表：活跃标签按成分归组
boxed_warnings_active_labels	93,691	活跃标签全部抽取
boxed_warnings_all_labels	114,322	所有版本全部抽取
ingredients	129,316	各标签的成分行（复方多行）
dm_spl_zip_files_meta_data	147,025	DailyMed 元数据（标注哪版为当前版）
rxnorm_mappings	456,932	set_id → RxNorm CUI 映射
rxcui_setid_map	147,087	SetID → RxNorm 产品 id
rxnorm_product_to_ingredient	247,040	RxNorm 产品 id → 成分 id

为什么要有三张表？ 因为药品标签是持续修订的：同一成分在生命周期里会有多个标签版本（初版、修订、仿制药替代）。_active_labels 回答"当前在售的说法是什么"，_all_labels 回答"历史上曾记载过什么"，而 adverse_reactions 主表则把活跃标签折叠到成分粒度，供跨产品聚合研究。混用这三个口径是新手最常见的错误——例如把 _all_labels 的 3.61M 说成"当前药物-副作用关系数"，就会系统性高估。

dm_spl_zip_files_meta_data（147,025 行）的存在还揭示了另一个工程细节：DailyMed 下载的 SPL 包里有大量历史版本，官方用这份元数据判断"哪个 set_id 的哪一版才是当前版"，避免把废弃标签的副作用误当成现行记载。

2.4 标准词表、术语映射与"成分组合"口径

OnSIDES 的两端标准词表是整个资源可用的前提：

• 药物端 → RxNorm。RxNorm 是 NLM 的美国临床药物标准命名体系，把商品名、通用名、成分、剂型统一到概念码（CUI）。OnSIDES 的产品—成分映射走 product_to_rxnorm 与 vocab_rxnorm_ingredient_to_product 两级。注意"成分"（ingredient）是 RxNorm 的一个语义层级——一盒复方药有多个成分，这正是论文把 3,233 拆成"1,873 单成分 + 1,360 多成分"的原因。
• 不良反应端 → MedDRA Preferred Term (PT)。MedDRA（Medical Dictionary for Regulatory Activities）是 ICH 维护的监管活动医学词典，分层为 SOC（系统器官分类）→ HLGT → HLT → PT（首选术语） → LLT（最低层级术语）。OnSIDES 落在 PT 层——这是监管上报与药物警戒统计的事实标准层，使得 OnSIDES 的副作用标签可以直接与 FAERS 等上报系统对齐。

为什么"多成分药物"是一个卖点？ 官方反复强调 OnSIDES"是唯一纳入复方药物的同类库"。传统文本挖掘库（如 SIDER）在处理"某种复方片的副作用"时很难归属到具体哪个成分；OnSIDES 通过 RxNorm 的两级多对多映射，让复方的副作用可追溯到成分组合层。这对复方药安全性研究意义重大，但也带来 §10 会展开的"成分归因含糊"坑。

2.5 与 SIDER 及同类库的关系边界

把 OnSIDES 放进药品副作用库的家族里看，它的定位来自三个"是/否"：

维度	SIDER 4.1	OnSIDES
抽取方法	词典/共现文本挖掘	微调 BERT 模型打分
覆盖区域	主要美国	美国 + 欧盟 + 英国 + 日本
复方药物	覆盖有限	明确纳入（多成分）
分节抽取	未系统分节	分 ADR / Boxed Warning / Warnings & Precautions 三节
儿科特异	无	OnSIDES-PED
TAC 2017 F1	74.36	87.54（v2/3.0.0）/ 89.87（v3.2.0）
词表	MedDRA	MedDRA PT + RxNorm

关键边界在于方法论代际：SIDER 代表"字符串层面的文本挖掘"，OnSIDES 代表"上下文感知的神经抽取"。BERT 的价值在于能利用"候选术语之后的上下文"判断该词是否真在描述本药不良反应——论文的输入工程实验（125 词窗口、87.5% 后置、用通用 token「EVENT」替换候选词）正是把这一优势显式化的结果。

但 OnSIDES 不是 SIDER 的替代品，而是同源不同代的对照物：论文把 SIDER 4.1 作为评测基线之一（F1 74.36，召回 52.89——低召回是其短板），用来说明"神经方法在召回上的提升"。库内已收录 sider（rid=92），是 OnSIDES 条目最重要的一级互链条目（见 §9）。

2.6 数据格式与加载路径

OnSIDES 的发布物有四种形态，对应不同使用场景：

1. CSV flat files——最通用的发布形态，适合导入任意数据库或直接用 pandas 读取；
2. 预构建 SQLite 单文件库——开箱即用，适合本地探索与教学，也可用 pgloader、sqlite3-to-mysql 迁移到 MySQL/PostgreSQL；
3. Schema 文件（create_tables.sql）——官方为 MySQL/PostgreSQL/SQLite 各供一份，配示例 bash 脚本按正确顺序建库并加载，示例走 Podman 容器但可适配现有数据库；
4. 交互站点 onsidesdb.org——无需下载即可查询，适合快速核对单条事实。

加载顺序不能乱。 因为 product_adverse_effect 外键指向 product_label 与 vocab_meddra_adverse_effect，product_to_rxnorm 又连接 vocab_rxnorm_product，若有外键约束则必须先加载词表与主键表、再加载关系表。官方示例脚本之所以强调"proper order"，正是在处理这件事。

规模提醒：以 v2.1.0 归档 onsides_v2.1.0_20240925.tar.gz 为例，压缩包 123MB；解压后的 CSV 与预构建库会显著更大（表级行数从数万到数百万不等）。规划本地存储时应按"解压后数百 MB 至 GB 级"预估，而非按 123MB 规划。

§3 抽取流水线：一个 F1 0.9 的模型是怎么炼成的

3.1 七步流水线全景

OnSIDES 的生成流程在官方 README 中被明确拆为七步，这条链的每一步都值得单独理解，因为它们各自对应一类工程难点：

1. 下载：从四个来源（DailyMed / EMA / EMC / KEGG）抓取全部人用处方药标签；
2. 解析：处理原始格式（PDF、XML），抽出相关章节，把标签文本统一格式化；
3. 术语匹配：在格式化文本中字符串匹配 MedDRA 术语（日本标签用 MedDRA Japan）——把"候选不良反应词"先框出来；
4. 模型打分（非日本）：用 PubMedBERT 对每个匹配到的术语打分，再套一个阈值 cutoff 判定真伪；
5. 药物映射：把所有药物产品映射到 RxNorm；
6. 汇聚建库：把抽取结果（产品、识别出的不良反应）汇成数据库，并接入 RxNorm 产品→成分信息与 MedDRA 概念映射；
7. 校验导出：验证数据库，导出为 flat files。

为什么第 3 步和第 4 步要分开？ 这是整条流水线的核心设计哲学：先用词典把候选框出来（高召回、低精度），再用模型精筛（提精度）。MedDRA 字符串匹配能保证"凡 MedDRA 里有的术语在文本中出现就被考虑"，避免模型从零识别时漏掉罕见术语；而 BERT 的职责是判断"这个词出现在这段文本里，是不是在描述本药的不良反应"——例如区分"the patient had nausea before enrollment"（既往史，不是药物导致）与"nausea was commonly reported"（不良反应）。这种"词典召回 + 模型精排"的两段式，是生物医学 NER 的经典范式，也是 OnSIDES 能在保持召回的同时把精度推高到 0.9+ 的关键。

日本为何例外（第 4 步标注"非日本"）？ 因为日文标签的语言与 MedDRA Japan 的特殊性，论文与 README 都说明对日本标签的处理路径不同（用 MedDRA Japan 匹配），这是多语言扩展必须付出的适配成本。

3.2 输入工程：125 词、87.5% 与「EVENT」替换

论文里最"反直觉"也最值得学习的一组实验，是关于怎么把标签文本喂给 BERT。三个发现：

• 窗口长度 125 词：输入串以 125 词为最优——太短丢上下文，太长引入噪声并增加计算；
• 87.5% 的词来自候选术语之后：即上下文的重心在候选词的右侧。这符合说明书的写作习惯——不良反应术语往往出现在句首或句中，其后跟着频率、严重度、限定语（“commonly”“rarely”“in clinical trials”），这些后置信息才是判断该词是否为本药不良反应的关键证据；
• 候选术语替换为通用 token「EVENT」并前置术语与节来源：把具体的候选词用一个占位 token 替掉、并在输入最前面拼上"这个术语本身 + 它来自哪一节（ADR / Boxed Warning / Warnings）"，可进一步提升模型性能。

第三点的意义在于解耦：如果直接把"nausea"原样喂进去，模型可能过拟合到"某些词通常是不良反应"这种先验，而非真正判断这句话的语境。用「EVENT」占位、把术语身份额外注入，模型学到的更接近"在这段上下文中，这个位置的词是否被当作不良反应陈述"。节来源的注入则让同一个模型能区分"这一段是 ADR 节还是黑框警告节"，为多节共用模型铺路。

3.3 单模型多节：一个模型如何通吃三节

早期版本与现行版本在模型策略上有一处重要演进。现行 GitHub 主 README 明确写：“a single fine-tuned PubMedBERT model trained on all sections is used for OnSIDES”——即用一个模型同时处理 Adverse Reactions、Boxed Warning、Warnings and Precautions 三节，而不是为每节各训一个。省下的不只是训练成本，更重要的是跨节一致性：同一术语在不同节的判定标准由同一个模型给出，避免了"同一副作用在 ADR 节算数、在警告节不算"的分裂。

训练与评测的划分也值得一提：held-out 采用 200 份人工标注 FDA 标签的 80/10/10 药物级划分。"药物级"是关键——划分按药物而非按句子，避免同一药的不同句子分别落入训练集和测试集造成标签泄漏。这是医学 NLP 评测的卫生要求，也是为什么官方能给出 0.942 这样一个"看起来很高但不虚"的 F1。

3.4 从模型到数据库：打分、阈值与归档

模型给出的不是一个"是/否"的硬标签，而是一个概率分。第 4 步的"apply a cutoff threshold"就是把这串概率二值化：高于阈值的候选术语被接受为不良反应。阈值是一个可调的超参——调高提高精度、降低召回，调低反之。官方在 INTL/PED 场景中还专门为儿科"re-computing the prediction cutoff"（重新计算预测阈值），因为儿科室的句式与术语分布不同，沿用通用阈值会失准（儿科抽取精度 0.61 / accuracy 0.64 / AUROC 0.66，明显低于通用人群，见 §5.1）。

最后一步"validate the database, and export tables as flat files"保证了发布物是可复现的静态快照：每个季度跑一遍这条链，产出一套新的 CSV + 版本号（如 v2.1.0_20240925）。这也是为什么 OnSIDES 的数字会随版本漂移——它不是一次成型的固定数据集，而是一个持续运行的流水线的季度切片。

3.5 人工标注的角色：不是纠错，而是校准与评测

OnSIDES 的"人工"部分常被误解。它不是让标注员逐条修正数据库（700 万对不可行），而是集中在两处：

1. Denmer-Fushman et al. 的 200 份人工标注 FDA 标签——这是训练与评测的黄金标准，模型在这 200 份上微调、也在这 200 份的 held-out 划分上报告 F1；
2. OnSIDES-ANNOT 补充标注——为 INTL/PED 各标注 200 份随机抽样标签，用于训练与评估那些补充库的模型。

换句话说，人工标注是"尺子"而非"橡皮擦"：它定义了什么叫"抽取正确"，然后用这把尺子去度量流水线的输出。这也解释了一个容易被误读的事实——OnSIDES 的 F1 0.9 是在"与这 200 份标注一致的判定标准"下的成绩，换一套标注口径，数字会变。这不是数据造假，而是所有有监督抽取任务的固有属性；理解这一点，才不会把"F1 0.942"当成"94.2% 的副作用都是真的"。

§4 评估与基准：这些数字该怎么读

4.1 三套指标口径并存

OnSIDES 的模型表现，官方在不同位置给出了三套口径，混用是踩坑重灾区：

口径 A：v2.0.0 README / onsidesdb.org 站点（旧版四舍五入口径）

节	F1	AUROC	AUPR
Adverse Reactions	0.90	0.92	0.95
Boxed Warnings	0.71	0.85	0.72
Warnings and Precautions	0.68	0.66	0.68

口径 B：GitHub 主 README 现行 held-out（80/10/10 药物级划分，200 标签）

节	F1	Precision	Recall	AUROC	N
Adverse Reactions	0.942	0.962	0.922	0.996	10,604
Boxed Warning	0.901	0.977	0.835	0.996	894
Warnings and Precautions	0.880	0.851	0.911	0.995	9,702

口径 C：GitHub 主 README 独立 hold-out（30 份人工标注 FDA 标签，未用于训练/调阈值）

节	F1	Precision	Recall	AUROC	N
Adverse Reactions	0.847	0.871	0.825	0.965	7,782
Boxed Warning	0.736	1.000	0.582	0.988	597
Warnings and Precautions	0.756	0.789	0.725	0.973	2,209

口径 B 与 C 的差距（0.942 vs 0.847）是这三套数字里最有价值的信号。 口径 B 的测试集与训练集来自同一个 200 标签池的药物级划分，模型见过同池其他药的风格；口径 C 是完全独立的 30 份标签，更接近真实外推。所以引用性能时应优先用口径 C，口径 B 宜标注为"同池划分"以免误导。

4.2 TAC 2017 金标准的四列演进

与社区第三方模型的横评采用 TAC 2017 ADR 抽取任务的金标准与官方评测脚本：

指标	TAC (Best Model†)	SIDER 4.1	OnSIDES v1.0.0	OnSIDES v2/3.0.0	OnSIDES v3.2.0
F1 Score	82.19	74.36	82.01	87.54	89.87
Precision	80.69	43.49	88.76	91.29	85.52
Recall	85.05	52.89	77.12	84.08	94.68

† Roberts, Demner-Fushman & Tonning, Overview of the TAC 2017。另主 README 另处给"Micro-F1 0.87 / Macro-F1 0.85"。

这张表要读出三件事：

1. 对 SIDER 的全面超越：SIDER 4.1 的瓶颈在召回 52.89（漏了一半），OnSIDES 把它拉到 84-95。这正是神经抽取相对词典挖掘的核心增益——上下文感知能救回大量被频率/否定语境遮蔽的术语。
2. v3.2.0 的"精度换召回"取向：v3.2.0 主动把 Recall 推到 94.68（最高），代价是 Precision 从 91.29 降到 85.52。这不是退步，而是面向"知识库完整性"的取舍——作为供下游挖掘的资源，漏报（低召回）比误报更致命，因为漏掉的信号下游永远看不到。
3. 列名口径不一：“v2/3.0.0” 与别处 “v2.0.0” 的写法不同，社区镜像页还可能滞后。核对指标务必回到主 README 与对应版本 README。

4.3 三节性能差异的成因

同一模型在三节上的表现差异很大，且顺序一致：ADR > Boxed Warning > Warnings & Precautions（在口径 B 为 0.942 / 0.901 / 0.880；在口径 C 为 0.847 / 0.736 / 0.756）。成因有三：

• 文本规范性：ADR 节是标签里格式最规范的部分，通常就是"不良反应—频率"的清单式罗列，模型最容易学；
• 术语密度与句式复杂度：Warnings and Precautions 节是散文体，混入机制解释、禁忌、注意事项、剂量调整，不良反应术语散落在长句与嵌套从句中，判定更难；
• 样本量与标注量：口径 C 中 Boxed Warning 独立 hold-out 只有 597 条（N 最小），F1 0.736 的置信区间天然更宽；ADR 节 7,782 条、WP 节 2,209 条。

Boxed Warning 在口径 C 下的 Precision 1.000 / Recall 0.582 是另一个极具信息量的组合：模型在黑框警告节"凡判必对"（零误报）但漏掉近四成。对于"最严重的副作用"这一节，漏报的代价尤其高——使用者若要研究黑框警告，必须意识到召回只有 58%，不能把"OnSIDES 该药黑框警告里没有 X"读成"该药黑框警告不含 X"。

4.4 高置信交集：用多源一致性做"人工置信度"

因为 OnSIDES 有四个来源（美欧英日），官方提供了一种无需额外标注就能提高置信度的机制：取多源交集。一个药物-不良反应对若同时出现在美国和英国的标签上，其可信度高于只出现在美国标签上的；若四个来源都有，则置信度最高。v3.1.1 的交集规模：

交集	pairs	ingredients	effects
US-EU-UK-JP	663	71	180
US-EU-UK	3,489	206	591
US-UK-JP	1,516	197	284
EU-UK-JP	1,285	74	355
US-EU-JP	1,047	85	261
US-UK	10,141	620	1,045
EU-UK	9,541	267	1,571
US-EU	11,199	501	1,143
UK-JP	3,462	223	591
US-JP	4,240	297	557
EU-JP	2,270	87	569

四源全交集只有 663 对（71 成分 / 180 效应）——官方自己提示"overlap 相对较小"。这既反映了各国监管文本的差异，也说明高置信集合很"金"但很"窄"：想要覆盖广就用全集（信噪比低），想要高置信就用四源交集（覆盖极小）。官方给出的 source_intersection 建表 SQL 让使用者可以按需自取任意交集的层级。这个设计值得单独称赞——它把"信噪比权衡"的主动权交给使用者，而不是替用户拍一个阈值。

4.5 读这组数字的四条守则

1. 口径先于数字：说"F1 0.9"必须问"哪一节、哪个版本、held-out 还是独立集"。0.942（口径 B）与 0.847（口径 C）差近 10 个点，指代不清就是错误引用。
2. 规模先于时点：3.61M（论文 2024-02）、6.93M（站点）、7.1M+（主 README 2026-04）分属不同来源数与口径，不可直接比较涨跌。
3. 召回优先于精度（对知识库而言）：OnSIDES 作为挖掘资源，漏报的危害大于误报；引用时说明该版本取向（v3.2.0 高召回）。
4. "官方警告"是数据的一部分：Limitations 里"会漏、会误判、患者医护不得使用"是必须一并引用的使用前提，不能只抄 F1 0.9 而略过这段话。

§5 三个补充库：INTL、PED 与 ANNOT

OnSIDES 不是一个孤立的主库，而是一个"主库 + 三个补充库"的家族。理解这三者的分工，才能判断"我要的那个副作用到底在哪个表里"。

5.1 OnSIDES-PED：儿科特异性不良反应

动机：主库抽取的是一般人群标签里的 ADE，但儿科患者是已知的 ADE 高风险人群。由于儿科临床试验受限（人群少、伦理约束），儿科的药物安全知识尤其匮乏。同实验室早前的 KidSIDES 从自发上报数据库中挖掘儿科 ADE 信号、并考虑发育阶段；而 OnSIDES-PED 是从药品标签里抽取儿科特异 ADE，与 OnSIDES/KidSIDES 互补并用。

构建方法（论文口径）：

1. 在标签的 Specific Populations 节中，抽出发出 “pediatric” / “child” 的子节；
2. 经此过滤，得到 25,453 份含潜在儿科 ADE 提及的标签；
3. 因不存在儿科标注参考集，人工标注 200 份随机抽样标签，用于微调与评估；
4. 沿用 OnSIDES 的输入串构造方法，套用为 OnSIDES 微调的 BERT 模型，但重新计算预测 cutoff（儿科句式不同）；
5. 得到儿科特异库。

规模与性能：

指标	数值
药物标签-ADE 对	359,213
唯一药物成分组合	1,161
唯一 ADEs	1,526
标签数（源自 Special Populations 节）	20,014
儿科抽取 accuracy	0.64
儿科抽取 precision	0.61
儿科抽取 AUROC	0.66

关键读法：儿科抽取的 accuracy/precision 明显低于主库（precision 0.61 vs 主库 0.96），官方也承认这体现的是"方法对特定条件的可适应性"（flexibility），而非同等精度。用 PED 做研究时必须意识到它的噪声更高。表结构上，官方说"OnSIDES-PED 的表被包含在主 OnSIDES 数据库内"（tables enclosed in the main database），而非独立发布。

5.2 OnSIDES-INTL：多国多语言不良反应

动机：欧盟、英国、日本是全球美国之外最大的几个医药市场，且各有独立于美国的监管流程。同一药物在不同监管辖区的标签，对同一副作用的记载可能不同——这正是国际比较研究的价值所在。论文称 OnSIDES"是唯一最新且多国的药品标签 ADE 数据库"。

数据源与处理：从 EMA（EU）、EMC（UK）、KEGG（Japan） 的标签中抽取 ADE。日本标签用 MedDRA Japan 匹配、处理路径与美欧英不同（见 §3.1）。官方还额外提供 约 25,000 份药品标签的格式化文本数据（CSV 与 XML），这本身就是一个语言资源级产物（README 称 “multi-national/multi-lingual”）。

与主库的关系：INTL 不是替代主库，而是扩充源集合——现行主 README 的 7.1M 对 / 51,460 标签就是把 INTL 的欧英日源并入后的口径。而在交集高置信场景中，四源（US/EU/UK/JP）的可用性正来自 INTL（见 §4.4）。

遗留疑点：本次抓取未取得 INTL 的独立规模数字（各语种标签数/ADE 数），只能确认其为三源扩展；如需精确数字，应查 v3.x 各版本 release notes（FACTS §9 已记录）。

5.3 OnSIDES-ANNOT：可复用的标注集

是什么：为训评 INTL/PED 模型，官方对每个子区各人工标注 200 份抽样标签，v3.0.0 起作为可下载数据发布（仓库 database/annotations/）。

为什么它本身有价值：这是一个跨语种、跨人群的药物标签 ADE 标注集，可用于训练、微调、改进与药物标签 ADE 相关的语言模型（README 原文指向"large language models"）。对做生物医学 NER/RE 的团队而言，ANNOT 是一个可直接使用的高质量标注语料，而不仅是 OnSIDES 的副产品。

许可：与其余数据文件一致，属 CC BY 4.0（官方明确"manual annotations"落在数据许可内）。

5.4 OffSIDES：家族外的"标签外"姊妹库

OnSIDES 的 On 字面就是"标签内（on-label）"。对应地，同团队另设 OffSIDES（offsidesdb.org）专收**标签外（off-label）**副作用。两者构成一个完整视角的二分：

• OnSIDES：说明书写了的副作用——监管文本的"已知"；
• OffSIDES：说明书没写但被观察到的副作用——往往是新信号、药物重定位的线索。

用 OnSIDES 做药物重定位时，务必区分这两者：从 on-label 谱发现的重定位线索是"已知副作用的再利用"，而从 off-label 发现的是"新信号"——两类研究的因果强度与监管含义完全不同。本条目只覆盖 OnSIDES，OffSIDES 属独立资源（库内是否有对应条目见 §9）。

5.5 三个补充库的分工对照

库	追加的维度	数据来源	规模	怎么进
OnSIDES（主）	一般人群、on-label	DailyMed 为主	论文 3.61M / 主 README 7.1M+	主库表
OnSIDES-INTL	地理/监管辖区	EMA/EMC/KEGG	并入主库口径	主库表（多源标记）
OnSIDES-PED	患者人群（儿科）	标签 Special Populations 节	359,213 pairs	表在主库内
OnSIDES-ANNOT	标注语料（方法用）	各子区各 200 份	子区各 200 标签	独立下载
OffSIDES（家族外）	标签外 on/off 视角	独立管线	见其站点	独立站点

一句话记忆：主库管"普遍且已记载"，INTL 管"别国怎么写"，PED 管"儿童怎么样"，ANNOT 管"怎么训练评测"，OffSIDES 管"说明书没写的"。

§6 获取与许可：双轨许可的门怎么进

6.1 双许可：软件 MIT、数据 CC BY 4.0

OnSIDES 采用双许可（dual-licensed），官方在 README §License 里把"软件"与"数据"显式区分：

• 软件（仓库源码、脚本、工作流）→ MIT License
• 数据（数据库与作为 OnSIDES 发布一部分分发的全部数据文件，含 flat files、SQLite 数据库与人工标注）→ Creative Commons Attribution 4.0 International（CC BY 4.0）

为什么这个区分重要？ 因为很多数据集把"代码许可"与"数据许可"混为一谈，导致使用者误以为可以按 MIT 自由使用数据。OnSIDES 明确规定：代码随便用（MIT），数据要署名（CC BY 4.0）。CC BY 4.0 是允许商用的宽松许可，唯一的硬性义务是署名（attribution）——官方要求使用数据时引用论文进行署名：doi:10.1016/j.medj.2025.100642。

一个常见误读（务必避坑）：GitHub v2 仓库页早期标注 “MIT license”（那是仅指软件），若据旧页把数据也当成 MIT 就会踩坑。正确的数据许可以主 README §License 与 LICENSE-DATA 文件为准。

6.2 四类获取入口

入口	内容	适用场景
GitHub Releases	CSV flat files（分版本归档，如 onsides_v2.1.0_20240925.tar.gz，123MB）	批量下载、导入自有数据库
预构建 SQLite	单文件数据库	本地探索、教学、快速原型
Schema 文件	MySQL/PostgreSQL/SQLite 的 create_tables.sql + 加载脚本	建生产库
onsidesdb.org	交互式查询	快速核对单条事实、无需下载
HuggingFace	微调模型 tatonettilab/onsides-bert	复用/微调模型

全部入口公开、无 gated 申请——这是 OnSIDES 相对许多需 DUA（数据使用协议）的临床数据集的巨大优势：从一个想法到拿到数据，不需要邮件审批、不需要机构签字。

6.3 版本链与"季度更新"承诺

官方承诺每季度更新数据库，并在 Releases 页保留历史版本：

版本	时点	亮点
v1.0.0	早期	初版，F1 82.01（TAC 对照）
v2.0.0	2023-06-29	第二主版本，模型显著改进，2.8M 反应 / >45,000 标签
v2.1.0	2024-09-25	123MB 归档；README 口径 >3.6M / 2,793 成分 / 46,686 标签
v3.0.0	（v3 首发）	引入 INTL / PED / ANNOT 三补充库；语言模型与标签全面更新
v3.1.0 / v3.1.1	迭代	交集表口径（US-EU-UK-JP 663 等）
v3.2.0	现行	TAC F1 89.87 / Recall 94.68（高召回取向）

版本选择的实务建议：

• 要可复现的研究 → 锁定一个版本号并记录归档文件名（如 onsides_v2.1.0_20240925）；
• 要最新覆盖 → 用主 README 所述最新版（v3.x，四源）；
• 要跨国比较 → 必须用 v3.0.0 及以后（含 INTL）；
• 要儿科 → 用 v3.0.0 及以后（含 PED 表）。

切勿混用不同版本的指标与规模——§4.5 的口径守则同样适用于"获取"：先问版本，再问数字。

6.4 实践要点：把数据用起来的最小路径

路径 A：SQLite 三步走（最快）

1. 从 Releases 下载预构建 SQLite 文件（或下载 flat files 后用 schema 建库）；
2. 用任意 SQLite 客户端打开，先 SELECT * FROM product_adverse_effect LIMIT 5 熟悉字段；
3. 通过 product_to_rxnorm → vocab_rxnorm_ingredient_to_product JOIN 折叠到成分层。

路径 B：导入 PostgreSQL/MySQL（生产）

1. 取 create_tables.sql 建表；
2. 用官方示例 bash 脚本（Podman 容器版）按 proper order 加载：先词表与主键表，后关系表；
3. 建索引（product_adverse_effect 的 label_id / effect_meddra_id 外键列）后再做批量查询。

路径 C：直接调模型（复用/微调）

1. 从 HuggingFace（沙箱内走 hf-mirror.com）取 tatonettilab/onsides-bert；
2. 按 §3.2 的输入工程（125 词窗、87.5% 后置、「EVENT」替换、节来源前置）构造输入；
3. 套用你场景的阈值（注意儿科等特殊人群要重算 cutoff）。

高置信子集查询（官方 source_intersection 思路，SQLite 语法）：

-- 建多源交集表（判断每对 ADE 出现在哪些来源）
CREATE TABLE source_intersection AS
SELECT
  pi.ingredient_id,
  a.effect_meddra_id,
  count(distinct source) AS num_sources,
  max((source = 'US')::int) AS US,
  max((source = 'EU')::int) AS EU,
  max((source = 'UK')::int) AS UK,
  max((source = 'JP')::int) AS JP
FROM product_label l
INNER JOIN product_to_rxnorm lp USING (label_id)
INNER JOIN vocab_rxnorm_product p ON lp.rxnorm_product_id = p.rxnorm_id
INNER JOIN vocab_rxnorm_ingredient_to_product pi ON p.rxnorm_id = pi.product_id
INNER JOIN product_adverse_effect a ON l.label_id = a.product_label_id
GROUP BY pi.ingredient_id, a.effect_meddra_id;

-- 取四源全交集（最高置信，v3.1.1 口径 663 对）
SELECT * FROM source_intersection
WHERE US = 1 AND EU = 1 AND UK = 1 AND JP = 1;

注意：官方明确 source_intersection 是派生表，不在官方 schema 内——它需要你自己建，这也意味着官方不对它的行数负责，数字随版本变（663 是 v3.1.1 口径）。

6.5 使用前必读的三条红线

1. 不得用于临床决策。官方原文：患者与医护不应信任或使用该数据，应查 FDA/EMA/MHRA/PMDA 等监管机构信息并咨询医生。任何面向临床的二次产品都必须绕过或明确红线。
2. 必须署名引用。数据是 CC BY 4.0，使用（含商用）须引用 doi:10.1016/j.medj.2025.100642。忽略署名的二次发布违反许可。
3. 引用须带口径。汇报任何数字（3.61M / 6.93M / 7.1M、F1 0.9 / 0.942 / 0.847）都要带版本与时点，否则等于制造错误信息。

§7 生态与影响：一个资源如何嵌入药物安全图景

7.1 在药品知识库谱系中的位置

OnSIDES 不是凭空出现的，它处在一个药物知识库的谱系中，与三类资源相邻：

• 药物本身的知识：DrugBank（库内 rid=89/571）、DrugCentral（rid=344）、PharmGKB（rid=374）、KEGG（rid=433）——描述药物是什么、靶点是什么；
• 药物-靶点/药物-药物：IUPHAR/BPS Guide to PHARMACOLOGY（库内 rid=364）、DrugTargetCommons（rid=1080）——描述药物作用于谁；
• 副作用/毒性：SIDER（rid=92）、Tox21（rid=93）、ToxCast（rid=194）——描述药物有什么害处。

OnSIDES 落在第三类，但它的独特之处在于：它把"副作用"这件事从"文本"中解放出来，并接了标准词表。这使得它可以作为桥梁，把"药物结构/靶点"（第一、二类）与"临床有害结局"（第三类）连起来——这正对应论文演示的第三个应用：“从化合物结构直接预测不良反应”。也就是说，OnSIDES 让"分子 → 副作用"这条监督学习链路第一次有了足够大、足够规范的标签源。

7.2 三个官方展示的下游应用

官方在 README 与论文中点名了三类用例，每一类都对应一种研究方法：

1. 由药物间 ADE 谱相似性预测新靶点与适应症。原理是"副作用指纹"：两种药如果在几百个 ADE 上的分布高度相似，可能共享药理机制或靶点。这是一种无监督/半监督的药物重定位信号生成方式，ADE 谱扮演了"表型指纹"的角色。
2. 分析 ADE 在药物类别间的富集。把药物按药理类别分组，统计某类 ADE 是否在某一类药中系统性偏高——这是群体层面的药物警戒，恰是"个案式"传统方法做不到的事。
3. 从化学结构预测 ADE。以 OnSIDES 的 ADE 标签为监督信号，训练化学信息学模型，做"分子 → 副作用"回归/分类。这类工作此前受困于标签稀缺，OnSIDES 的 700 万对（或论文口径 361 万）极大缓解了标签瓶颈。

一个诚实提醒：这三类应用都建立在"on-label 记载"之上，而非"真实因果"。ADE 谱相似 → 共享靶点是一个假设，不是结论；论文的定位是"展示潜在应用"（present potential applications），而非"已验证的发现"。做衍生研究时应把 OnSIDES 当信号源而非金标准。

7.3 与库内条目的关系（详见 §9）

库内的 sider（rid=92）是 OnSIDES 的直接对照物——OnSIDES 论文用 SIDER 4.1 作为评测基线之一（TAC 对照表中 SIDER 4.1 F1 74.36）。此外，drugbank、drugcentral、iuphar-bps、kegg、pharmgkb、drugtargetcommons、tox21、toxcast、drugprot 等条目与 OnSIDES 存在多层次的互链可能（药物端、靶点端、毒性端）。详细的互链建议与 rid 见 §9。

7.4 影响力与局限的平衡描述

OnSIDES 的影响力可从三方面观察：方法层面——它示范了"BERT + 词典召回 + 多源交集"这套可复制的药物安全文本抽取范式；资源层面——它成为跨药物、跨类别研究的事实数据源，并被 Cedars-Sinai 作为机构级成果对外发布通稿；社区层面——模型公开发布于 HuggingFace，标注集公开，降低了复现门槛。

但影响力不等于无懈可击。它最根本的局限是**“记载 ≠ 事实”**：说明书写了什么，取决于监管沟通的历史与各药企的书写习惯，而非纯粹的流行病学证据；一次不良反应在某标签中被写进黑框警告，可能与法律/监管压力而非风险幅度有关。任何把 OnSIDES 的 ADE 频率直接当作"真实发生率"的研究，都是在做未经声明的强假设。

§8 方法学启示：三条可迁移的经验

8.1 "词典召回 + 神经精排"是低成本高收益的通用范式

OnSIDES 最值得迁移的不是某个模型，而是流水线的两段式结构：先用高召回的词典/规则把候选框出来，再用神经模型做高精度筛选。这个结构的优势在于：词典保证了覆盖（罕见术语不漏），模型保证了判别力（否定/既往史/频率语境能分辨），而且候选集的存在让模型的任务被简化（不是从零识别，而是二分类打分），训练数据需求与推理成本都更低。任何"从专业文本抽结构化关系"的任务——临床病历、专利、监管文件——都可以照搬这个骨架。

8.2 输入工程与阈值是被低估的性能杠杆

论文里 125 词窗口、87.5% 后置、「EVENT」替换、节来源前置这组实验说明：在不换模型的前提下，光靠输入串设计就能显著提升性能。与之呼应的是阈值重算（PED 场景）与多源交集（置信度分层）——这三者都是"用工程手段换取质量分层"的范例。迁移启发：先榨干输入设计与后处理的空间，再考虑换更大的模型，投入产出比往往高得多。

8.3 把"资源"当"持续运维的流水线"而非"一次性快照"

OnSIDES 从 v1 到 v3.2 持续迭代、承诺季度更新、维护版本链与历史归档——这种运维式数据集的思维，是它能在两年多里从 3.6M 扩到 7.1M 对、从单源扩到四源的组织基础。它也带来一个使用侧的纪律要求：使用者必须版本锚定，否则复现性与跨研究可比性都会崩坏。这与库内许多"一次性发布"的数据集形成鲜明对照，值得作为"长期维护型数据资源"的样板讨论。

8.4 医学 NLP 评测的卫生：药物级划分与独立 hold-out

80/10/10 药物级划分 与 独立 30 标签 hold-out 这两个设计，是所有医学文本抽取任务都应遵守的评测卫生。句子级/切片级随机划分会造成同源泄漏，把性能虚高；而独立 hold-out（口径 C，F1 0.847 vs 口径 B 0.942）才是诚实的外推估计。OnSIDES 把两者并列呈现，而不是只报高的那个，这一点值得称道——它把"数字可信度的边界"透明地交给了使用者。

§9 与库内条目的关系

9.1 家族图谱与互链点

OnSIDES 在"千方病案医数集"库内的互链，建议按四类关系组织：

（1）直接对照（副作用/毒性同类）——最高优先级

库内条目	rid	关系	建议互链理由
sider	92	方法论代际对照	同为药品标签副作用库；SIDER 4.1 是 OnSIDES 论文评测基线（TAC F1 74.36 vs 87.54/89.87），是最紧密的一级互链
tox21	93	毒性数据（细胞/通路层）	OnSIDES 是临床文本层毒性，Tox21 是体外通路层，互补
toxcast	194	毒性数据（体外高通量）	同上，构成"体外—标签"毒性视角对照

（2）药物端（药物本体/命名）

库内条目	rid	关系
drugbank	89 / 571	药物本体与靶点，OnSIDES 药物端（RxNorm）的上游参照
drugcentral	344	药物-靶点-适应症
kegg	433	OnSIDES 日本数据源即 KEGG DRUG，直接血缘
pharmgkb	374	药物基因组学

（3）药物-靶点端（下游任务对接）

库内条目	rid	关系
iuphar-bps	364	受体/通道药理（GtoPdb），OnSIDES"由 ADE 谱预测靶点"任务的对齐对象
drugtargetcommons	1080	药物-靶点关联，同上下游

（4）NLP 方法与词表

库内条目	rid	关系
drugprot	827	生物医学关系抽取（NER/RE）任务集，与 OnSIDES 的方法学同域

互链 rid 纪律（R018 教训）：以上 rid 均为写作前 DB 实查 status=1 AND del_sign=0 的在架值；正文中出现的目标 rid 若因重号被软删，须由主会话在入库后统一核对回填。frontmatter 的 relatedLink 只写占位 URL，明细写在正文（本表）。

9.2 检索路径建议

• 想对比"新旧两代药品标签副作用库" → sider(92) ↔ onsides：看方法代际（词典挖掘 vs BERT）、覆盖区域（美国 vs 四国）、复方处理、指标演进。
• 想做"分子结构 → 副作用" → onsides ↔ drugbank(89) / drugcentral(344)：把药物端标识打通（RxNorm ↔ DrugBank ID）。
• 想做"副作用谱 → 靶点" → onsides ↔ iuphar-bps(364) / drugtargetcommons(1080)。
• 想做"药物警戒 + 基因组" → onsides ↔ pharmgkb(374)。
• 日本药物视角 → onsides（KEGG 源）↔ kegg(433)。

9.3 与库内可获取性光谱的对照

库内数据集在"可获取性"上从 gated 请求制到完全公开分布很广。OnSIDES 属于最开放的一档：双许可（软件 MIT / 数据 CC BY 4.0）、全部入口公开无申请、预构建 SQLite 开箱即用、模型与标注集一并公开。对照那些需 DUA 的临床数据（如 MIMIC 类），OnSIDES 的获取摩擦几乎为零——这也是它适合作为"开放数据资源"样板的原因。

§10 避坑清单：八个已踩过的坑

以下坑点来自论文数字、官方 README 明确表述与本次核验过程中发现的真实口径冲突，均为使用者高频踩坑处。

坑 1：把"标签记载"当成"真实发生率"。OnSIDES 记录的是说明书上写了什么，不是"某副作用在人群中的真实频率"。某药某副作用出现在库里，只说明监管文本提过它，不说明它常见、更不说明它由该药导致。任何"发生率""因果"结论都需另找证据（FAERS、RCT、流行病学研究）。

坑 2：只报 F1 0.942 而漏掉独立集 0.847。口径 B（同池药物级划分）与口径 C（独立 30 标签 hold-out）差近 10 个点。对外引用应优先用口径 C 0.847，并把"0.942 是同池划分"说清楚，否则构成选择性汇报。

坑 3：把三个规模口径当同一件事比较。论文 3,610,120（2024-02，单源 DailyMed 为主）、onsidesdb.org 6,928,666（站点统计栏）、主 README >7.1M（2026-04，四源）——来源数与计量口径都不同。说"涨了一倍"是错的，因为分母变了。

坑 4：把 _all_labels 的行数当成"当前关系数"。adverse_reactions_all_labels（v2.1.0 = 3,610,120）含所有历史版本标签的抽取，adverse_reactions_active_labels（3,061,873）才是活跃版。研究"当前记载"应用 active 或主表 adverse_reactions（129,624，按成分归组）。

坑 5：把国际药的 OMOP 前缀编码当成脏数据。EU/UK/JP 药物常常没有标准 RxNorm 码，官方用 OMOP RxNorm Extension（如 OMOP991424）替代。这是设计使然；直接按 rxnorm_id 跨美国/国际聚合会得到混合编码，需显式区分。

坑 6：忽略黑框警告节召回只有 58%（口径 C）。Boxed Warning 独立 hold-out 的 Precision 1.000 但 Recall 0.582——漏掉近四成。把"OnSIDES 该药黑框警告里没有 X"读成"该药黑框警告不含 X"是严重误读；研究黑框警告必须意识到召回天花板。

坑 7：据 GitHub v2 旧页把数据当 MIT 使用。旧仓库页标 “MIT license” 仅指软件；数据是 CC BY 4.0（须署名引用论文）。忽略署名的商用二次发布违反许可。

坑 8：把 OnSIDES 与 OffSIDES 混为一谈。OnSIDES 只收 on-label（说明书已载）副作用；标签外信号在 OffSIDES。做药物重定位/新信号发现时，若研究需要"说明书没写的"，用错库会系统性错失发现。

坑 9（附加）：跨版本混用指标。TAC 对照表列名有 “v2/3.0.0” 与 “v2.0.0” 两种写法，且 v3.2.0 是新列（F1 89.87、Recall 94.68）。跨版本比指标前，先确认版本映射与口径一致。

DAIMS 评估表

DAIMS（Data and AI Management/Maturity Scorecard）用于对数据集的 AI-Ready 就绪度做分维打分（满分 5）：

维度	评分	依据
可发现性（Discoverability）	5	GitHub 主仓库 + onsidesdb.org 交互站 + HuggingFace 模型 + 论文，多入口且被大量引用
可获取性（Accessibility）	5	全部入口公开无 gated；CSV/SQLite/schema 齐全；无 DUA 摩擦
可互操作性（Interoperability）	4.5	双端标准词表（RxNorm + MedDRA PT）；国际药用 OMOP 前缀略有异构；有 7 表关系模型与官方 schema
可复用性（Reusability）	5	数据 CC BY 4.0、软件 MIT；模型与标注集公开；版本链清晰可锚定
可理解性（Understandability）	4.5	README/SCHEMA/PERFORMANCE 文档完善；但站点与 README 口径不同步、跨版本指标易混（需使用者自行甄别）
质量与可信度（Quality）	4	ADR 节 F1 0.942（同池）/ 0.847（独立）；官方明示"会漏会误判"；三节性能差异大，黑框召回偏低
文档与元数据（Documentation）	4.5	详尽 README、SCHEMA.md、MODEL_TRAINING.md、PERFORMANCE.md、DATABASE.md；多口径并存是唯一减分项
维护与治理（Maintenance）	5	承诺季度更新、版本链完整、有稳定实验室与 NIH 资助运维
综合	4.7 / 5	开放度与工程化极佳；主要扣分在"自动抽取固有噪声"与"多口径需自行甄别"

结论：OnSIDES 在 AI-Ready 光谱上属于高就绪档——开放、标准、文档齐全、可版本锚定。其"就绪"的边界不在工程，而在语义：它是信号源，不是临床真值。把它用对的前提，是始终记得"载 ≠ 实"。

§11 总结

11.1 三句话总结

1. OnSIDES 是用微调 PubMedBERT 从美欧英日四国药品说明书里自动"读"出药物-不良反应对的机器可读数据库，双端映射 RxNorm 与 MedDRA PT，是 SIDER 之后的新一代药品标签副作用库。
2. 它的价值在于"把医学文本变成可连接的表"：700 万+（v3，2026-04）药物-不良反应对、7 张关系表、标准词表、季度更新、CC BY 4.0 开放，使跨药物、跨类别、跨国的药物安全研究第一次有了规整的数据底座。
3. 它的边界在于"载 ≠ 实"：数据库记的是说明书写了什么，不是真实发生率，也不是因果结论；官方明示"会漏会误判、患者医护不得使用"，使用者必须把它当信号源而非临床真值。

11.2 适合谁

• 药物警戒 / 药物流行病学研究者：跨药物、跨类别的副作用谱比较与信号挖掘；
• 生物医学 NLP / 知识图谱团队：复用其模型、标注集，或把 ADE 接入药物知识图谱；
• 药物重定位与靶点预测研究者：用 ADE 谱相似性生成重定位假设；
• 化学信息学团队：以 ADE 为监督标签做"分子 → 副作用"学习；
• 开放数据 / AI-Ready 研究：作为"持续运维型数据资源 + 双许可"的样板案例；
• 教学场景：SQLite 开箱即用，适合药物安全数据实操教学。

11.3 不适合谁

• 临床决策：官方明令禁止据此用药，医护应查监管机构信息；
• 因果推断：库中关系是"标签记载"而非因果证据，直接当因果用会系统性偏倚；
• 需要标签外信号者：应用 OffSIDES，而非 OnSIDES；
• 要求逐条人工核验的场景：库是模型产物，无逐条人工背书，高精度场景需另找源。

11.4 30 秒决策卡

你的问题	该做什么
我要一个可 JOIN 的药物-副作用表	下 Releases 的 CSV 或预构建 SQLite，用 create_tables.sql 建库
我要模型自己抽	取 HF tatonettilab/onsides-bert，按 125 词/87.5% 后置/「EVENT」构造输入
我要高置信 ADE	建 source_intersection，取 US-EU-UK-JP 交集（v3.1.1 = 663 对）
我要儿科 ADE	用 v3.0.0+ 的 OnSIDES-PED（359,213 pairs，precision 0.61）
我要跨国比较	用 v3.0.0+ 含 INTL 的版本
我要引用指标	ADR 节独立 hold-out F1 0.847（同池 0.942 需注明口径）
我要许可靠谱	数据 CC BY 4.0（署名引论文），软件 MIT
我要做临床决策	不要用本数据，去查 FDA/EMA/MHRA/PMDA

FAQ（高频问答 32 问）

A. 基础认知

1. OnSIDES 的全称是什么？
ON-label SIDE effectS resource，即"标签内副作用资源"。名字本身就点明了范围：on-label（说明书已载）。

2. 它和一般"药物副作用数据库"有何不同？
它不是人工编纂的副作用手册，而是机器学习从药品说明书自动抽取的结构化库；也不是纯文本库，而是映射了标准词表（RxNorm + MedDRA PT）的关系型数据。

3. “Adverse Drug Event (ADE)” 和 “side effect” 是一回事吗？
在 OnSIDES 语境里基本混用，都指"与用药相关的不良事件"。严格说 ADE 更强调查明与药物的关联性，而 OnSIDES 记的是"标签上描述的"不良事件，不保证因果。

4. 谁是作者？
Cedars-Sinai 计算生物医学系 Tatonetti 实验室；第一作者 Yutaro Tanaka，通讯作者 Nicholas P. Tatonetti。完整作者 12 人（见 §1、FACTS §3）。

5. 论文发表在哪？
正式论文：Med（Cell Press），2025-03-27，doi:10.1016/j.medj.2025.100642，PMID 40179876。前身是 medRxiv 预印本（2024-03，doi:10.1101/2024.03.22.24304724）。

6. OnSIDES 和 KidSIDES 什么关系？
同一实验室的两条不同路线：KidSIDES 从自发上报数据库挖儿科信号（考虑发育阶段）；OnSIDES-PED 从药品标签抽儿科 ADE。二者互补并用，不是同一库。

7. OffSIDES 是什么？
标签外（off-label）副作用姊妹库，独立站点 offsidesdb.org。OnSIDES 管"写了的"，OffSIDES 管"没写的"。

B. 数据与获取

8. 数据现在多大？
取决于版本：论文 2024-02 口径 3,610,120 ADEs / 3,233 成分组合 / 47,211 标签；主 README 2026-04 口径 >7.1M pairs / 4,097 成分 / 51,460 标签（四源）；onsidesdb.org 统计栏 6,928,666 pairs / 1,866 成分 / 41,119 产品。先问版本再问数字。

9. 包含哪些国家的标签？
美国（DailyMed）、欧盟（EMA）、英国（EMC）、日本（KEGG）四国/地区。

10. 怎么下载？
GitHub 主仓库的 Releases 段（CSV flat files），或取预构建 SQLite 单文件；也可在 onsidesdb.org 在线查。全部公开无 gated。

11. 有没有 schema？
有。官方提供 MySQL / PostgreSQL / SQLite 三套 create_tables.sql 与示例加载脚本。

12. 加载有顺序要求吗？
有。有外键约束时须先加载词表与主键表、再加载关系表；官方示例脚本强调 “proper order” 正为此。

13. 数据多大（存储）？
以 v2.1.0 归档为例压缩包 123MB；解压后 CSV/预构建库会达数百 MB 至 GB 级。

14. 更新频率？
每季度。Releases 保留历史版本（v1.0.0 → v2.0.0 → v2.1.0 → v3.0.0 → v3.1.x → v3.2.0）。

15. 需要签数据使用协议吗？
不需要。这是 OnSIDES 相对临床数据集的最大优势——零审批摩擦。

C. 模型与方法

16. 用的什么模型？
微调的 PubMedBERT（基础模型 microsoft/BiomedNLP-PubMedBERT-base-uncased-abstract），公开发布于 HuggingFace tatonettilab/onsides-bert。

17. 一个模型还是多个？
现行为单模型多节共用（one model trained on all sections），同时处理 ADR / Boxed Warning / Warnings and Precautions 三节。

18. 流水线几步？
七步：下载 → 解析 → MedDRA 术语匹配 → BERT 打分+阈值 → RxNorm 映射 → 汇聚建库 → 校验导出。

19. 为什么要先词典匹配再模型打分？
词典保召回，模型保精度。先用 MedDRA 字符串匹配框出所有候选（不漏罕见术语），再用 BERT 判断语境（区分不良反应陈述 vs 既往史/否定）。

20. 输入串怎么构造？
最优为 125 词窗口、87.5% 的词来自候选术语之后、候选术语替换为通用 token 「EVENT」、并在最前拼接术语本身 + 节来源。

21. 日本标签为何特殊处理？
语言与词表不同——日本标签用 MedDRA Japan 匹配，且 README 标注第 4 步"非日本"才走 BERT 阈值路径。

22. 阈值是什么？
模型输出的是概率分，"cutoff threshold"把它二值化。阈值可调（调高提精度、降召回）；儿科场景重算 cutoff。

D. 评测与指标

23. 模型准不准？
分节分口径：ADR 节同池 held-out F1 0.942、独立 30 标签 hold-out F1 0.847；黑框警告独立集 F1 0.736；警告与注意事项独立集 F1 0.756。

24. 为什么有两个 F1？
0.942 是同一 200 标签池的 80/10/10 药物级划分（口径 B）；0.847 是完全独立的 30 标签 hold-out（口径 C）。后者更接近真实外推，引用应优先用 0.847。

25. 和 SIDER 比呢？
在 TAC 2017 金标准上，SIDER 4.1 F1 74.36（召回仅 52.89），OnSIDES v2/3.0.0 F1 87.54，v3.2.0 F1 89.87（召回 94.68）。

26. 黑框警告表现如何？
独立 hold-out 下 Precision 1.000 但 Recall 0.582——"凡判必对"但漏近四成。研究黑框警告必须知道这个召回天花板。

27. 什么是"高置信交集"？
OnSIDES 有四个来源，取多源交集可提高置信度。四源全交集（US-EU-UK-JP）在 v3.1.1 只有 663 对（71 成分 / 180 效应）。

28. 官方怎么警告使用？
官方 Limitations 原文：抽取不完美，会漏也会误判；患者与医护不应信任或使用本数据，应查 FDA/EMA/MHRA/PMDA 并咨询医生。

E. 许可与库内

29. 许可是什么？能用吗？
双许可：软件 MIT、数据 CC BY 4.0。CC BY 4.0 允许商用，须署名（引用论文 doi:10.1016/j.medj.2025.100642）。

30. 库内有没有相关条目？
有。最直接的是 sider（rid=92）（同为药品标签副作用库、OnSIDES 的评测基线）；另有 drugbank(89/571)、drugcentral(344)、iuphar-bps(364)、kegg(433)、pharmgkb(374)、tox21(93)、toxcast(194)、drugtargetcommons(1080)、drugprot(827) 等（详见 §9）。

31. OnSIDES 和 SIDER 会不会重复收录？
是同域不同代，会碰撞但不等价——相同药物可能两边都有副作用记录，但方法、覆盖区域、复方处理与指标都不同，应作为对照而非重复。

32. 一句话该不该用？
要机器可读、标准词表映射、多国覆盖的药物副作用数据 → 用；要临床真值或因果结论 → 不用。

事实清单（硬事实 40 条）

1. 全称：OnSIDES = ON-label SIDE effectS resource。
2. 本质：微调 PubMedBERT 从药品说明书抽取药物-不良反应对的关系型数据库。
3. 团队：Cedars-Sinai 计算生物医学系 Tatonetti 实验室。
4. 通讯作者：Nicholas P. Tatonetti, PhD（计算生物医学系副主任）。
5. 第一作者：Yutaro Tanaka。
6. 作者数：12 人（Tanaka, Chen, Belloni, Gisladottir, Kefeli, Patterson, Srinivasan, Zietz, Sirdeshmukh, Berkowitz, LaRow Brown, Tatonetti）。
7. 正式论文：Med (Cell Press), 2025-03-27, 100642。
8. 论文 DOI：10.1016/j.medj.2025.100642。
9. 论文 PMID：40179876。
10. 预印本：medRxiv doi:10.1101/2024.03.22.24304724（2024-03）。
11. 预印本许可：CC-BY-NC 4.0（与数据许可不同）。
12. 官方仓库：github.com/tatonetti-lab/onsides。
13. 交互站点：onsidesdb.org。
14. 模型地址：HuggingFace tatonettilab/onsides-bert。
15. 基础模型：microsoft/BiomedNLP-PubMedBERT-base-uncased-abstract。
16. 数据源：DailyMed(US) + EMA(EU) + EMC(UK) + KEGG(Japan)。
17. 药物词表：RxNorm（国际药用 OMOP RxNorm Extension，OMOP 前缀）。
18. 不良反应词表：MedDRA Preferred Terms (PT)。
19. 论文口径规模：3,610,120 ADEs / 47,211 标签 / 3,233 成分组合（1,873 单 + 1,360 多）。
20. 论文口径：114,322 Boxed Warning ADEs；4,510 唯一 ADEs。
21. 主 README 口径：>7.1M drug-ADE pairs / 4,097 ingredients / 51,460 labels（截至 2026-04）。
22. onsidesdb.org 口径：6,928,666 pairs / 1,866 ingredients / 41,119 products / 6,423 reactions。
23. v2.1.0 口径：>3.6M pairs / 2,793 ingredients / 46,686 labels（截至 2023-11）。
24. v2.1.0 归档：onsides_v2.1.0_20240925.tar.gz（123MB）。
25. v2.1.0 表行数：adverse_reactions 129,624；all_labels 3,610,120；active_labels 3,061,873。
26. v2.1.0 表行数：boxed_warnings 6,087；all_labels 114,322；ingredients 129,316。
27. 数据库表数：7 张（product_label, product_adverse_effect, product_to_rxnorm, vocab_rxnorm_product, vocab_rxnorm_ingredient_to_product, vocab_rxnorm_ingredient, vocab_meddra_adverse_effect）。
28. 抽取流水线：7 步。
29. 输入工程：125 词窗口 / 87.5% 后置 /「EVENT」替换 / 节来源前置。
30. 同池 held-out 指标：ADR F1 0.942 / P 0.962 / R 0.922 / AUROC 0.996（N=10,604）。
31. 同池 held-out 指标：Boxed Warning F1 0.901；Warnings & Precautions F1 0.880。
32. 独立 hold-out（30 标签）：ADR F1 0.847；Boxed Warning F1 0.736；W&P F1 0.756。
33. 独立 hold-out 黑框值：Precision 1.000 / Recall 0.582。
34. TAC 2017 对照：SIDER 4.1 F1 74.36；OnSIDES v2/3.0.0 F1 87.54；v3.2.0 F1 89.87 / R 94.68。
35. v2/onsidesdb 口径指标：ADR F1 0.90 / AUROC 0.92 / AUPR 0.95；Boxed Warning F1 0.71。
36. 高置信四源交集：US-EU-UK-JP = 663 对 / 71 成分 / 180 效应（v3.1.1）。
37. OnSIDES-PED：359,213 pairs / 1,161 成分组合 / 1,526 ADEs / 20,014 标签；precision 0.61 / accuracy 0.64 / AUROC 0.66。
38. 许可：软件 MIT；数据 CC BY 4.0（含 flat files、SQLite、人工标注）。
39. 更新承诺：每季度；版本链 v1.0.0 → v2.0.0（2023-06-29）→ v2.1.0（2024-09-25）→ v3.0.0 → v3.1.0/3.1.1 → v3.2.0。
40. 官方红线：患者与医护不得据本数据用药，须查 FDA/EMA/MHRA/PMDA。

附：来源与延伸阅读

一手来源（本次核验实抓，2026-10-16）

1. 主仓库 README — https://github.com/tatonetti-lab/onsides
2. 官方交互站点 — https://onsidesdb.org
3. 预印本摘要 — https://www.medrxiv.org/content/10.1101/2024.03.22.24304724v1
4. 预印本全文 PDF — https://www.medrxiv.org/content/10.1101/2024.03.22.24304724v1.full.pdf
5. v2.0.0 README — https://github.com/tatonetti-lab/onsides/tree/v2.0.0-20230629
6. v2.1.0 表级行数（fork 页） — https://redirect.github.com/yutarohtanaka/onsides
7. Cedars-Sinai 机构通稿 — https://www.cedars-sinai.org/newsroom/tagfeed/en-us/tags/ai
8. 正式论文 — https://doi.org/10.1016/j.medj.2025.100642
9. 微调模型 — https://huggingface.co/tatonettilab/onsides-bert
10. 训练/评测基准（Denmer-Fushman et al.） — https://pubmed.ncbi.nlm.nih.gov/29381145/

库内互链条目（DB 实查在架）

• sider（rid=92）｜drugbank（rid=89）｜tox21（rid=93）｜toxcast（rid=194）｜drugcentral（rid=344）｜iuphar-bps（rid=364）｜pharmgkb（rid=374）｜kegg（rid=433）｜drugprot（rid=827）｜drugtargetcommons（rid=1080）

延伸阅读方向

• MedDRA 分层结构（SOC→HLGT→HLT→PT→LLT）与药物警戒上报（FAERS）衔接；
• RxNorm 语义层级（ingredient/product/clinical drug）与 OMOP RxNorm Extension；
• TAC 2017 ADR 抽取任务与 Denmer-Fushman et al. 标注方法论；
• 同类资源对照：SIDER 4.1、OffSIDES（标签外）、KidSIDES（儿科自发上报）。

---

条目说明：本条目由千方病案医数集依据公开一手来源编写，数据口径以 2026-10-16 抓取时点为准；OnSIDES 为持续更新资源，规模与指标随版本变动，引用请锚定版本号。正文所有硬数字的来源 URL 见 FACTS.md §9；双口径冲突已逐条存照（FACTS.md §9）。

附录 A：案例解剖——三份药品标签是如何变成数据库行的

抽象地讲"从标签抽 ADE"很容易，但只有走一遍具体案例，才能真正理解这条流水线在做什么、以及它会在哪里出错。本节用三类典型的标签片段（为便于理解而构造的示意性示例，非逐字引用具体标签）来解剖。

A.1 案例一：一句典型的 ADR 节罗列

设想某标签的 ADVERSE REACTIONS 节包含这样一句：

“The most common adverse reactions (incidence ≥5%) were nausea, headache, fatigue, and constipation.”

流水线做了什么：

1. 术语匹配（第 3 步）：MedDRA 词典里存在 Nausea（PT）、Headache（PT）、Fatigue（PT）、Constipation（PT），于是这四个词被框为候选；
2. 输入构造（§3.2）：对每个候选，抽取其周围约 125 词窗口，把候选本身替换成「EVENT」，并在最前拼接"术语=Nausea；节=ADVERSE REACTIONS"；
3. BERT 打分（第 4 步）：模型看到"the most common adverse reactions … were EVENT"这一语境，给出高概率；
4. 阈值判定：过阈值 → 接受为"本药的不良反应"；
5. 映射建库（第 5-6 步）：Nausea 映射到 MedDRA PT 概念，本产品经 product_to_rxnorm 映射到 RxNorm，写入 product_adverse_effect 一行。

这里最容易出错的点：如果窗口太短（比如只截到 “were EVENT”），模型看不见 “adverse reactions” 这个关键锚点，可能把频率描述误读；这就是为什么窗口长度与后置比例是超参（§8.2）。另一个陷阱是否定与既往史——若原句是 “patients with pre-existing nausea were excluded”，术语同样被框出，但语境完全不同，模型必须学会压低其概率；这正是"词典召回 + 模型精排"结构存在的理由。

A.2 案例二：黑框警告里的严重副作用

设想某标签的 BOXED WARNINGS 节写着：

“WARNING: Hepatotoxicity has been reported. Monitor liver enzymes. Discontinue if ALT elevations occur.”

注意两件事：

1. “ALT elevations” 不是 MedDRA PT 层面的标准不良反应术语——它是实验室指标。MedDRA 匹配阶段可能框出 “Hepatotoxicity”（PT），而 “ALT elevations” 未必被框出（取决于是否映射到某 PT）。这意味着库中黑框警告的"效应"数会比人眼看到的强调点少；
2. 黑框警告节召回本就偏低（独立 hold-out Recall 0.582，§4.3）——模型在这节"凡判必对但漏得多"。所以引用"某药黑框警告在 OnSIDES 里有 N 个效应"时，N 是下界而非全量。

实践含义：如果你的研究目标是"严重副作用"，不要只依赖 OnSIDES 的黑框字段做完整性判断，应把 OnSIDES 作为候选生成器，再回原文核实。这一条正是"载 ≠ 实"在具体案例里的体现。

A.3 案例三：复方药的成分归因

设想某复方片含成分 X 与成分 Y，标签 ADR 节写：

“Adverse reactions reported with This Combination Product include dizziness and peripheral edema.”

OnSIDES 会怎么处理： 通过 product_to_rxnorm → vocab_rxnorm_ingredient_to_product 两级多对多映射，这个"产品"会关联到两个成分（X 与 Y）。于是在按成分归组的主表 adverse_reactions 里，dizziness 与 peripheral edema 会在X 和 Y 各出现一次（或作为成分组合出现，取决于查询粒度）。

用户必须知道的后果：

• 归因是"产品的"不是"成分的"：标签说"本复方产品的副作用"，并未断言是哪个成分导致的；OnSIDES 的多重映射会把这条记录广播到两个成分，因此"某成分有 dizziness"这类查询结论，在复方场景下是过包含的；
• 这也是官方宣称"唯一纳入复方药物"的代价——覆盖更全，但成分级归因更含糊；
• 做成分级安全性分析时，应区分单成分药与复方药来源的记录（可通过 product_label 的成分数判断），否则会把复方的副作用错误归给单个成分。

A.4 三个案例的共同教训

案例	流水线动作	典型误用
罗列式 ADR	术语框选 + 语境打分	忽略窗口/后置超参对判定的影响
黑框警告	术语框选（部分指标不映射）+ 打分	把"库中数量"当"严重副作用全量"
复方药	多对多映射广播到成分	把"产品的副作用"当"成分的副作用"

三个案例都指向同一句话：OnSIDES 的输出是一个"经过模型与词表加工的近似"，使用者必须知道每一步加工了什么、丢掉了什么。

附录 B：按角色阅读路径

不同背景的读者需要的部分不同。以下是四条推荐路径，帮你跳过无关章节，直达要害。

B.1 药物警戒 / 药物流行病学研究者

路径：§1 速览 → §2.1 规模口径 → §4 评估与基准（重点 4.2、4.3、4.4） → §5 补充库 → §6.5 红线 → §10 坑 1、坑 6。

要点：先分清"论文 3.61M / 站点 6.93M / 主 README 7.1M"的口径差异；把"高置信多源交集"当作控制假阳性的手段；永远记住黑框警告召回只有 58%。做信号发现时，把 OnSIDES 当假设生成器，验证留给自己。

B.2 生物医学 NLP / 知识图谱工程师

路径：§3 抽取流水线（全节） → §4.1 指标口径 → §6.4 最小路径 → §8 方法学启示 → §10 坑 5。

要点：论文的输入工程（125 词 / 87.5% 后置 /「EVENT」/ 节来源）是可直接迁移的技巧；"词典召回 + 神经精排"是低成本范式；HF 走 hf-mirror.com 取模型；注意 OMOP 前缀编码不是脏数据。若做知识图谱融合，RxNorm 与 MedDRA PT 是两个天然对齐键。

B.3 药物重定位 / 化学信息学研究者

路径：§0 导读 → §7.2 三类下游应用 → §5.4 OffSIDES 的区分 → §9.1 互链 → §10 坑 1、坑 8。

要点：ADE 谱相似性是表型指纹假设；用 on-label 谱得到的是"已知不良反应的再利用"线索，与 OffSIDES 的"新信号"因果强度不同；做"分子 → 副作用"时，OnSIDES 提供监督标签，但标签噪声（尤其 R/P 权衡的版本）会传导到模型。

B.4 数据管理者 / AI-Ready 评估者

路径：§6 获取与许可（全节） → §10.4 DAIMS 表 → §9.3 可获取性光谱 → §8.3 运维式资源。

要点：OnSIDES 是"高就绪"样板——双许可、零摩擦获取、季度更新、版本链完整；它演示了长期维护型数据资源的治理形态。唯一需要使用者自行承担的是多口径甄别（同站点与 README 不同步）。

附录 C：一页速查卡

┌──────────────────────────────────────────────────────────────┐
│  OnSIDES 一页速查卡                                          │
├──────────────────────────────────────────────────────────────┤
│  是什么 : 微调 PubMedBERT 从药品说明书抽药物-不良反应对的关系库 │
│  全称   : ON-label SIDE effectS resource                    │
│  谁做的 : Cedars-Sinai 计算生物医学系 Tatonetti 实验室         │
│  论文   : Med (Cell Press) 2025;100642 · PMID 40179876       │
│  站点   : github.com/tatonetti-lab/onsides · onsidesdb.org   │
├──────────────────────────────────────────────────────────────┤
│  规模（务必带版本）：                                        │
│   论文 2024-02 : 3,610,120 ADEs / 3,233 成分组合 / 47,211 标签 │
│   站点统计栏   : 6,928,666 pairs / 1,866 成分 / 41,119 产品    │
│   主 README    : >7.1M pairs / 4,097 成分 / 51,460 标签(4源)  │
├──────────────────────────────────────────────────────────────┤
│  数据源 : DailyMed(US)+EMA(EU)+EMC(UK)+KEGG(JP)              │
│  词表   : 药物→RxNorm(国际 OMOP 前缀)｜反应→MedDRA PT        │
│  模型   : tatonettilab/onsides-bert (PubMedBERT)             │
├──────────────────────────────────────────────────────────────┤
│  指标（分节分口径）：                                        │
│   ADR 同池 held-out  : F1 0.942 / AUROC 0.996                │
│   ADR 独立 hold-out  : F1 0.847   ← 引用优先这条             │
│   Boxed Warning 独立 : F1 0.736 (P 1.000 / R 0.582)          │
│   TAC 对照 v3.2.0    : F1 89.87 / Recall 94.68               │
├──────────────────────────────────────────────────────────────┤
│  补充库 : INTL(欧英日) · PED(儿科 359,213) · ANNOT(标注) ─┐  │
│  家族外 : OffSIDES(标签外)                                │  │
├──────────────────────────────────────────────────────────────┤
│  获取   : Releases CSV / 预构建 SQLite / schema / 在线查询   │
│  许可   : 软件 MIT · 数据 CC BY 4.0（须署名引论文）           │
│  更新   : 每季度 · 版本链 v1→v2.0→v2.1→v3.0→v3.1→v3.2       │
├──────────────────────────────────────────────────────────────┤
│  红线 ① : 不得用于临床决策（查 FDA/EMA/MHRA/PMDA）           │
│  红线 ② : 必须署名引用 doi:10.1016/j.medj.2025.100642        │
│  红线 ③ : 引用数字必须带版本与时点口径                       │
├──────────────────────────────────────────────────────────────┤
│  一句话 : 信号源，不是临床真值；载 ≠ 实。                    │
└──────────────────────────────────────────────────────────────┘

附录 D：常见误解澄清（十条）

误解 1：“OnSIDES 是 FDA 官方数据库。”
不。它由 Cedars-Sinai 学术团队构建，数据源是 FDA 的 SPL（经 DailyMed），但加工与发布方是学术界，与 FDA 无隶属关系。官方也明确"应查监管机构信息而非本库"。

误解 2：“F1 0.942 意味着 94% 的记录是真的。”
不。F1 是术语级抽取性能，且 0.942 是同池划分口径；独立 hold-out 只有 0.847。F1 也不等于"因果真实性"，它只衡量"抽取与人工标注的一致性"。

误解 3：“库里有的副作用就是这药导致的。”
不。库记的是标签上的记载。标签写"已报告"可能来自个案上报、可能来自同类药类推，不构成因果证据。

误解 4：“OnSIDES 覆盖了所有副作用。”
不。只覆盖标签内（on-label）且被模型抽取出来的。漏报是官方承认的固有局限（尤其黑框警告节召回 0.582）。

误解 5：“SIDER 和 OnSIDES 是重复的，选一个就行。”
是同域不同代，可作对照。SIDER 用词典挖掘、覆盖偏美国；OnSIDES 用 BERT、四国覆盖、含复方、指标更高。研究设计里两者并用可获得交叉验证。

误解 6：“数据是 MIT 许可，随便用。”
不。MIT 只覆盖软件；数据是 CC BY 4.0，须署名引用。这是最容易被旧仓库页误导的坑（§10 坑 7）。

误解 7：“三个规模数字互相矛盾，说明数据不可信。”
不。它们分属不同来源数（单源 vs 四源）与不同计量（成分组合 vs RxNorm ingredient），是口径差异不是矛盾。

误解 8：“儿科数据 PED 和主库精度一样。”
不。PED 抽取 precision 0.61 / accuracy 0.64 / AUROC 0.66，明显低于主库。用儿科数据要接受更高的噪声。

误解 9：“有了 OnSIDES 就不需要人工审核了。”
不。官方明示"会漏会误判"，且是研究资源。任何高风险用途（监管、临床）都需人工与多源核实。

误解 10：“订阅季度更新后数字自动可比。”
不。跨版本可比性需要口径对齐——同一版本、同一表、同一计量。版本更新可能同时改变数据源、模型与阈值。

附录 E：下游实操清单

E.1 从零到"跑出一条查询"（约 15 分钟）

1. 打开 github.com/tatonetti-lab/onsides → Releases → 取最新（或目标版本）的归档；
2. 若用 SQLite：直接打开预构建库；若用 CSV：先执行 create_tables.sql，再按官方顺序加载；
3. 熟悉 schema：读 product_adverse_effect 的列（产品外键 + MedDRA 效应外键）；
4. 跑一条冒烟查询，确认库完好：

-- 冒烟：随机看 5 条药物-不良反应对
SELECT product_label_id, effect_meddra_id
FROM product_adverse_effect
LIMIT 5;

-- 看一个成分关联的效应数（示意，字段名以官方 SCHEMA.md 为准）
SELECT count(*) FROM product_adverse_effect;

5. 接入 MedDRA / RxNorm 概念表，把外键翻译成可读术语。

E.2 把数据折叠到"成分层"

官方的"主表按成分归组"就是这道 JOIN 的产物：

-- 产品 → 成分（多对多两跳）
SELECT DISTINCT
  pi.ingredient_id,
  a.effect_meddra_id
FROM product_label l
INNER JOIN product_to_rxnorm lp ON l.label_id = lp.label_id
INNER JOIN vocab_rxnorm_product p ON lp.rxnorm_product_id = p.rxnorm_id
INNER JOIN vocab_rxnorm_ingredient_to_product pi ON p.rxnorm_id = pi.product_id
INNER JOIN product_adverse_effect a ON l.label_id = a.product_label_id;

注意：国际药物在此会带 OMOP 前缀 id，若要与美国标准 RxNorm 分开统计，需显式过滤或分列。

E.3 做"高置信"筛选

建 source_intersection（§6.4 给了 SQL），然后按需取交集：

• 最严：US=1 AND EU=1 AND UK=1 AND JP=1（v3.1.1 = 663 对）；
• 平衡：US=1 AND UK=1（10,141 对）；
• 最宽：全集（信噪比最低但覆盖最广）。

E.4 复现/微调模型

1. 取 HF tatonettilab/onsides-bert（沙箱走 hf-mirror.com）；
2. 按论文输入工程构造输入（§3.2）；
3. 在目标域重算阈值（若换人群/语种，务必重算 cutoff）；
4. 用 OnSIDES-ANNOT 做验证集。

E.5 与库内条目融合的检查点

• 药物端对齐：RxNorm CUI ↔ DrugBank ID（库内 drugbank rid=89）——需另找映射表；
• 靶点端对齐：用 iuphar-bps(364) / drugtargetcommons(1080) 做"ADE 谱 ↔ 靶点"桥接；
• 毒性端对齐：与 tox21(93) / toxcast(194) 做"临床文本毒性 ↔ 体外通路毒性"对照；
• 日本端对齐：KEGG(433) 既是 OnSIDES 的日本数据源，也是库内独立条目。

E.6 交付前自检清单

• [ ] 记录使用的 OnSIDES 版本号与归档文件名；
• [ ] 引用指标时注明口径（同池 / 独立 hold-out）与节；
• [ ] 规模数字注明来源数与计量；
• [ ] 已在成果中署名引用论文 doi:10.1016/j.medj.2025.100642；
• [ ] 若涉及临床相关表述，已声明"本数据不得用于临床决策"。

附录 F：延伸思考——自动化抽取型医学资源的三个元问题

元问题一：机器"读"医学文本的误差，该由谁承担？
OnSIDES 把 F1、阈值、Limitations 全部公开，等于把"知道有误差"的责任交给使用者；使用者若忽略这些披露，误差就转嫁给了下游。这提示一种开放数据的伦理范式：透明度不能替代使用者的审慎义务。

元问题二：当"记载"与"事实"分离，数据库该记哪一个？
OnSIDES 明确选择记记载（标签写了什么），而非事实（真实发生率）。这是一个可辩护但需声明的选择——因为对监管文本的研究本身就重要（它反映监管叙事），但代价是任何把它当事实来源的人会误读。它提醒我们：任何医学数据资源都内嵌一个"记什么"的哲学选择，使用者必须识别它。

元问题三：持续更新的资源，如何保证研究的可复现？
季度更新让 OnSIDES 保持新颖，却对可复现性构成威胁。官方的解法是版本链 + 历史归档，把"新"与"可锚定"分离。这是所有"活数据集"必须回答的治理问题，也是本库在评估"维护与治理"维度给出高分的依据（§10 DAIMS）。

附录 G：MedDRA 与 RxNorm 深潜——两端词表为什么决定了一切

OnSIDES 的可用性,一半来自模型,一半来自两端标准词表。这一节把两端词表讲透,因为绝大多数"用起来不对"的问题,根都在这。

G.1 MedDRA 的五层层级

MedDRA(Medical Dictionary for Regulatory Activities)由 ICH 维护,是监管活动的事实标准词典(注意:它服务的是监管上报,不是临床诊断编码)。其层级自顶向下为:

层级	全称	说明	粒度
SOC	System Organ Class	系统器官分类(如"胃肠系统疾病")	最粗,约 27 个
HLGT	High Level Group Term	高位组语	中
HLT	High Level Term	高位语	中
PT	Preferred Term	首选术语	OnSIDES 落点
LLT	Lowest Level Term	最低层级语	最细,含同义/异形

为什么 OnSIDES 选 PT? 因为 PT 是药物警戒上报与统计的标准聚合层——FAERS 等系统按 PT 汇总,监管文档按 PT 表述。落在 PT 意味着 OnSIDES 的副作用标签可以直接与上报系统对齐,而不用做跨层映射。若研究需要更粗的器官系统视角(SOC),可从 PT 向上聚合;需要更细的同义表述(LLT),则向下展开。

一个必须知道的 MedDRA 特性:PT 之间不是互斥分类——一个医学事件可能挂在多个 SOC 下(多轴性,multiaxiality)。这意味着按 SOC 聚合副作用时,总数会大于 PT 数,不能简单相加。

G.2 RxNorm 的语义层级与"成分"的两种含义

RxNorm 是 NLM 的美国临床药物命名体系,其语义层级大致为:

成分(Ingredient) → 多成分(多 Ingredient 组合)
   ↓
临床药物(Clinical Drug) = 成分 + 剂量 + 剂型
   ↓
品牌药(Branded Drug) = 品牌名 + 剂量 + 剂型
   ↓
产品(Product,可包装/销售单元)

OnSIDES 里"ingredient"出现的两种含义(这是最易混淆处):

1. 论文口径的"成分组合":一盒药由哪些成分组成——单成分药 1 个、复方药多个;论文把 3,233 拆成 1,873 单成分 + 1,360 多成分;
2. RxNorm ingredient 概念口径:主 README 说的 4,097 drug ingredients 是 RxNorm 的 ingredient 语义层概念数。

两者不同源、不同量,别相互换算(§2.4、§4.5)。

G.3 OMOP RxNorm Extension:国际药的编码解法

RxNorm 是美国体系。当 OnSIDES 扩展到 EU/UK/JP 时,许多国际药物在 RxNorm 里没有标准码。OHDSI 的 OMOP 词表提供了 RxNorm Extension,为这些药分配扩展码,以 OMOP 前缀标识(如 OMOP991424)。

实践后果:

• 直接 GROUP BY rxnorm_id 时,结果里会混有标准 RxNorm CUI 与 OMOP 扩展码;
• 若要区分"美国药 vs 国际药",可按前缀过滤(rxnorm_id LIKE 'OMOP%');
• 做跨库映射(如与 DrugBank 对齐)时,OMOP 扩展码通常无法直接匹配,需要额外的跨词表映射表;
• 这不是数据质量问题,而是多国药物标准的现实约束。

G.4 词表版本的时间陷阱

MedDRA 与 RxNorm 都按版本更新(MedDRA 每年两版,RxNorm 每月)。OnSIDES 在某版本时点用了某版词表映射,而其引用者若用更新的词表回连,可能出现:

• 某 PT 在新版被拆分/合并 → 计数对不上;
• 某 RxNorm CUI 被废弃/重定向 → JOIN 丢失;
• OMOP 扩展码重新分配 → 跨版本不可比。

纪律:与 OnSIDES 融合时,记录并锁定词表版本;跨版本比较前先做概念映射核对。这是所有依赖标准词表的医学数据资源的共同义务。

附录 H：药品安全生态全景——OnSIDES 站在哪里

把视野拉远,OnSIDES 是"药物安全数据"生态中的一个节点。理解生态,才能判断"什么问题上哪找答案"。

H.1 五类药物安全数据源

类型	代表	回答的问题	OnSIDES 的关系
监管标签	FDA SPL / DailyMed、EMA、EMC、KEGG	“监管文本记载了什么”	OnSIDES 的数据源
自发上报	FAERS、EudraVigilance、VigiBase	“真实世界报告了什么”	互补:上报是自发信号,标签是监管叙事
观察性研究	电子健康记录、claims、队列	“某人群中风险多大”	下游验证层
临床试验	RCT、注册平台	“因果证据”	因果金标准,OnSIDES 不提供
体外/机制	Tox21、ToxCast、靶点库	“分子层面为什么”	可与 OnSIDES 桥接(库内 rid=93/194)

OnSIDES 的定位很清晰:它把最上游的"监管标签"结构化,成为整个链条的入口层数据。它不回答"真实发生率"(那是上报/观察性研究的事),也不回答"因果"(那是 RCT 的事)。

H.2 从"文本"到"知识"的加工链

原始标签(PDF/XML)
   → [OnSIDES 解析] → 分节文本
   → [MedDRA 匹配] → 候选术语
   → [BERT 打分] → 判定
   → [RxNorm/MedDRA 映射] → 标准实体
   → [关系型建库] → 可查询表
   → [下游:图谱融合/重定位/结构预测]

每一箭头都是一次信息加工,都引入一次信息损失或变形。OnSIDES 的透明度(公开每步与指标)让使用者能判断"损失在哪",这正是它作为 AI-Ready 样板的价值(§10 DAIMS 综合 4.7)。

H.3 与库内"药物/靶点/毒性"条目的桥接图

        ┌── drugbank(89) ── drugcentral(344) ── pharmgkb(374) ──┐
        │        药物本体 / 药物-靶点 / 药物基因组                 │
        ↓                                                          ↓
   kegg(433)──────→ 【 OnSIDES 】←──── iuphar-bps(364)
   日本源/通路        药物-不良反应     药物-靶点(GtoPdb)
        ↑                                                          ↓
        └──────────── drugtargetcommons(1080) ──────────────────┘
                              ↑
        tox21(93) ── toxcast(194) ── 体外毒性(与临床文本层对照)
                              ↑
                        drugprot(827) —— 生物医学关系抽取方法

用法:OnSIDES 是这张图的中心枢纽之一——一端连药物/靶点,一端连毒性,且自带标准词表,是理想的融合锚点。

附录 I：补充 FAQ（12 问）

33. MedDRA 和 ICD 有什么区别?
MedDRA 服务监管活动(药物警戒上报),ICD 服务临床诊断分类。二者目的不同、结构不同,不可互换。OnSIDES 用 MedDRA 是因为它的场景是药品安全监管文本。

34. RxNorm 和 ATC 哪个更适合分析?
RxNorm 是命名与标识体系(美国的药物概念码),ATC 是解剖治疗化学分类体系。OnSIDES 用 RxNorm 做标识;若研究需要药理类别分组(如"某类降压药"),可从 RxNorm 成分另映射到 ATC,库本身不提供 ATC。

35. 为什么黑框警告的记录数远少于 ADR 节?
两个原因:① 黑框警告本就只覆盖最严重的少数风险,标签里条目少;② 该节的模型召回偏低(独立集 0.582)。所以"少"是真实少 + 抽取漏的叠加。

36. 能否用 OnSIDES 做药物-药物相互作用研究?
不能直接做——OnSIDES 是**单药(或复方产品)**的副作用库,不含"两药合用"的相互作用关系。药物相互作用需另找专门资源。

37. OnSIDES 覆盖生物制品/疫苗吗?
官方口径是**人用处方药(prescription drugs)**的标签。生物制品/疫苗是否系统覆盖,取决于其标签是否在四源的可下载集合内——使用前应实查目标药物是否在库,不要假定全覆盖。

38. 中药/植物药覆盖如何?
取决于该药是否有纳入四源监管标签体系的产品。美国市场的中药若以膳食补充剂形式销售,通常不在 SPL 处方药标签范围。使用前必须实查。

39. 如何知道某药是否在库?
用 RxNorm CUI/名称在 vocab_rxnorm_ingredient 与 vocab_rxnorm_product 里查;或直接在 onsidesdb.org 搜。先验证在库,再做下游分析。

40. 数据的"活性"会随时间变吗?
会。标签持续修订,季度更新会新增、也可能移除某些记录(如某标签删去某副作用陈述)。跨时点比较必须同版本,或对差异做显式说明。

41. 有没有 API?
官方提供的是 flat files、SQLite、schema 与在线查询站;未见公开 REST API 承诺。若需 API,通常自建(导入库后自封装)。

42. 能否用于商业产品?
数据是 CC BY 4.0,允许商用,但须署名(引用论文)。商用前仍应自行做质量评估,官方不担保适用性。

43. 模型能直接拿来抽自己医院的病历吗?
模型是在药品标签文本上训练的,直接迁移到临床病历语域会显著掉点(语域不同、否定/时序结构不同)。可行路径是微调并重算阈值,而非直接套用。

44. 为什么官方反复强调"不要用于临床"?
因为它是模型抽取的研究资源,既有漏报也有误报,且记的是"标签记载"非"临床真值"。临床决策必须基于监管机构信息与专业判断——这条红线在官方 Limitations 中反复出现,是本条目必须一并传达的使用前提。

附录 J：术语速查表

缩写/术语	全称	含义
ADE	Adverse Drug Event	药物不良事件,与用药相关的不良结局
ADR	Adverse Drug Reaction	药物不良反应,常与 ADE 混用;OnSIDES 主要抽标签 ADR 节
SPL	Structured Product Label	FDA 结构化产品标签(标签的机器可读格式)
DailyMed	—	NLM 运营的 SPL 官方分发库(美国数据源)
EMA	European Medicines Agency	欧盟药品管理局(欧盟数据源)
EMC	Electronic Medicines Compendium	英国药品电子汇编(英国数据源)
KEGG	Kyoto Encyclopedia of Genes and Genomes	日本数据库;其 DRUG 部分为日本数据源
MedDRA	Medical Dictionary for Regulatory Activities	监管活动医学词典;OnSIDES 用其 PT 层
PT	Preferred Term	MedDRA 首选术语层(OnSIDES 落点)
SOC	System Organ Class	MedDRA 系统器官分类层(最粗)
RxNorm	—	NLM 美国临床药物标准命名体系
OMOP	Observational Medical Outcomes Partnership	OHDSI 的观察性医疗数据标准;其 RxNorm Extension 用于国际药
BERT	Bidirectional Encoder Representations from Transformers	双向 Transformer 编码器
PubMedBERT	—	在 PubMed 生物医学文献上预训练的 BERT
NER / RE	Named Entity Recognition / Relation Extraction	命名实体识别 / 关系抽取
OnSIDES-INTL	International	欧英日标签 ADE 补充库
OnSIDES-PED	Pediatrics	儿科特异 ADE 补充库
OnSIDES-ANNOT	Annotations	人工标注集
OffSIDES	—	标签外副作用姊妹库
F1	—	精确率与召回率的调和均值
AUROC / AUPR	Area Under ROC / PR Curve	曲线下面积指标
DAIMS	—	数据与 AI 就绪度分维评分卡(本条目 §10 采用)

附录 K：与库内同类条目的横向对照表

条目	rid	类别	与 OnSIDES 的关系	差异要点
sider	92	药品标签副作用	直接对照(同域不同代)	词典挖掘 vs BERT;偏美国 vs 四国;无复方 vs 含复方
tox21	93	体外毒性	互补(Tox21 是通路/细胞层)	体外 vs 标签文本层
toxcast	194	体外高通量毒性	互补	同上
drugbank	89	药物本体	上游(药物标识)	提供药物-靶点,OnSIDES 供副作用
drugcentral	344	药物-靶点-适应症	可桥接	靶点视角
iuphar-bps	364	药物-靶点(GtoPdb)	下游任务对齐	受体/通道药理
kegg	433	通路/日本药物	直接血缘(日本源)	OnSIDES 日本数据即来自 KEGG
pharmgkb	374	药物基因组学	可桥接	基因-药物-表型
drugprot	827	生物医学 NER/RE	方法学同域	关系抽取任务集
drugtargetcommons	1080	药物-靶点关联	下游任务对齐	靶点关联

横向用法建议:若要构建"药物安全知识图谱",以 OnSIDES 为副作用端锚点,用 drugbank/drugcentral 补药物本体、iuphar-bps/drugtargetcommons 补靶点、tox21/toxcast 补体外毒性、sider 作方法学对照——这几条 rid 构成一个完整的融合骨架。

附录 L：版本选择决策树

你的研究需要什么?
│
├─ 可复现(需锚定版本)
│    └─ 选一个明确版本归档(如 v2.1.0_20240925)并记录文件名
│
├─ 最新最全(四国覆盖)
│    └─ 用主 README 所述最新版(v3.x,>7.1M pairs)
│
├─ 跨国比较(EU/UK/JP)
│    └─ 必须 v3.0.0 及以后(含 OnSIDES-INTL)
│
├─ 儿科特异
│    └─ 必须 v3.0.0 及以后(含 OnSIDES-PED 表)
│
├─ 高置信 ADE(低假阳)
│    └─ 用任一含多源标记版本,自建 source_intersection 取交集
│
├─ 复现/微调模型
│    └─ 取 HF tatonettilab/onsides-bert + OnSIDES-ANNOT
│
└─ 需要历史标签版本(修订/仿制药)
     └─ 用 *_all_labels 表(注意口径是"所有版本"而非"当前")

一句话:版本选择 = 研究目标 × 数据源需求 × 口径可锚定性的交叉;先定这三者,再定版本号。

附录 M：数据质量自评工作流（供下游团队落地）

步骤 1：确认在库与覆盖

• 目标药物是否在 vocab_rxnorm_ingredient/vocab_rxnorm_product?
• 是单成分还是复方?是否国际药(OMOP 前缀)?

步骤 2：确认节与口径

• 你要的效应出自 ADR 节、黑框节还是警告节?三节性能不同(§4.3);
• 你用 _all_labels 还是 _active_labels 还是主表?

步骤 3：评估噪声水平

• 通用人群用主库指标(独立 hold-out F1 0.847);
• 儿科用 PED 指标(precision 0.61);
• 黑框警告记得召回 0.582。

步骤 4：提置信度

• 建多源交集,按需取 US-EU-UK-JP 等层级;
• 对关键结论回原文标签核实。

步骤 5：记录与署名

• 记录版本号 + 词表版本 + 查询 SQL;
• 成果中署名引用论文;
• 临床相关表述加"不得用于临床决策"声明。

步骤 6：跨库融合时对齐键

• 药物端:RxNorm CUI(注意 OMOP 前缀);
• 反应端:MedDRA PT;
• 与库内条目融合参见附录 K 骨架。

这套工作流的核心思想:把"数据质量"从"信不信"变成"量化的、可记录的不确定性"。OnSIDES 提供了做这件事所需的全部披露(指标、口径、限定),使用者只需接住并如实转达——这正是 AI-Ready 资源与使用者的共同责任边界。

---

相关数据集导航

以下为站内 AI-Ready 数据集百科中与本词条共享多个主题标签的相关数据集，按相关度降序排列：

• ddi-corpus — 共享标签：医疗NLP / 知识图谱 / 命名实体识别 / 关系抽取 / 药物安全
• sider — 共享标签：医疗NLP / 药物发现与化学 / 知识图谱 / 药物安全
• bc5cdr — 共享标签：医疗NLP / 命名实体识别 / 关系抽取 / 药物安全
• tcmssd — 共享标签：医疗NLP / 药物发现与化学 / 知识图谱 / 命名实体识别
• drugprot — 共享标签：医疗NLP / 药物发现与化学 / 命名实体识别 / 关系抽取
• cadec — 共享标签：医疗NLP / 药物发现与化学 / 药物安全
• drug-reviews-uci — 共享标签：医疗NLP / 药物发现与化学 / 药物安全
• ddinter — 共享标签：药物发现与化学 / 知识图谱 / 药物安全
• biored — 共享标签：医疗NLP / 知识图谱 / 命名实体识别 / 关系抽取
• semmeddb — 共享标签：医疗NLP / 知识图谱 / 命名实体识别 / 关系抽取

导航说明：本章节由全站统一标签体系自动计算生成（标签重合度算法），双向可达；点击链接可跳转至对应数据集词条。