MAUDE — FDA 医疗器械不良事件报告数据库

INFOBOX — MAUDE 一屏速览

维度	内容
本质	美国 FDA 的医疗器械不良事件（MDR）报告库（非药品、非影像数据集）
全名	Manufacturer and User Facility Device Experience（制造商与使用机构器械经验）
法律依据	21 CFR Part 803（Medical Device Reporting 规则）
主管	FDA / CDRH（器械与放射健康中心）
报告来源	制造商、进口商、器械使用机构（医院/门诊/护理院/门诊手术中心）+ 自愿报告者
报告触发	死亡、严重伤害、以及"若复现则可能导致死亡/严重伤害"的故障
时限	制造商 30 日（需补救措施 5 日）；使用机构死亡 10 工作日
规模	openFDA device/event 26,136,889 条（2026-09-08）；MDR Data Files 主表 23,636,521 条（through 2025）
覆盖	使用机构自 1991、自愿自 1993-06、分销商自 1993、制造商自 1996-08；MAUDE 库公开自 1999
网页检索	仅覆盖近 10 年，Simple/Advanced 各上限 500 条
API	openFDA device/event：2009–2026-10-07，每周更新，Elasticsearch 语法
全量下载	MDR Data Files：zip 内 pipe-delimited 文本，每月更新
结构	6 类关联文件 / 135 字段，全部以 MDR REPORT_KEY 关联
许可	public domain + CC0 1.0（可商用）；例外：GMDN® 术语受 The GMDN Agency 许可约束
脱敏	FOIA 豁免：贸易秘密 (b)(4)、个人/医疗信息 (b)(6)
2026 变局	MAUDE 数据迁入 AEMS（Adverse Event Monitoring System）
库内互链	openFDA（上游门户 rid=420）、FAERS（药品域对照 rid=264）、FDA 哨兵（主动监测 rid=505）、JADER（rid=1088）

MAUDE 是"医疗器械世界的 FAERS"：只要一件器械可能致死、致严重伤害，或出现"若再次发生就可能致害"的故障，制造商、进口商或使用它的医院就必须依法向 FDA 报告，这些报告汇总成了一个横跨三十余年、累计逾两千万条的公开数据库。它是全球器械安全监测的事实基准——任何一款新器械上市前的风险分析、任何一次召回决策的事后复盘、任何一篇器械警戒论文的实证基础，几乎都要回到 MAUDE 里翻一遍历史报告。但 MAUDE 的声誉也是一把双刃剑：它常被误当作"器械致病率"的度量，而 FDA 官方反复强调——报告存在不等于因果成立，且报告量不能换算成发生率，因为没有分母。

导语读法三则：

1. 只想拿数据：直奔 §6 获取与许可——注意"网页检索只看近 10 年"与"全量下载走 MDR Data Files"两条路的分工，别在网页界面里找 2010 年之前的报告。
2. 要读结构：直奔 §2 与 §4——6 类文件、135 字段、MDR REPORT KEY 关联是解释一切合并问题的钥匙。
3. 做安全分析：直奔 §3 报告制度与 §7 局限——把"报告计数≠发生率"“存在≠因果”"编码是索引不是诊断"三句刻进流程。

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

0.1 一句话定位

MAUDE（Manufacturer and User Facility Device Experience，制造商与使用机构器械经验数据库）是美国食品药品监督管理局（FDA）依 21 CFR Part 803 建立的医疗器械不良事件报告库：凡制造商、进口商、器械使用机构在获悉其上市器械可能致死、致严重伤害，或出现"若复现则可能致害"的故障时，必须依法提交 Medical Device Report（MDR，医疗器械报告），这些报告汇入 MAUDE 向公众开放。它是美国器械上市后安全监测（postmarket surveillance）最核心的公开数据源之一。

0.2 它回答什么问题

• 某款器械出过什么事：按品牌名（brand name）、通用名（generic name）、制造商、型号或 FDA 三字母产品码（product code）检索历史不良事件。
• 某类风险有多普遍：按事件类型（死亡/伤害/故障）、器械问题码、患者问题码聚合，观察某类问题的分布。
• 某制造商/某产品码的报告趋势：结合 openFDA API 做时间序列与聚合统计。
• 监管决策的证据来源：FDA 内部用 MDR 监测器械性能、识别潜在安全问题，并纳入受益-风险（benefit-risk）评估。

0.3 它不回答什么问题（最重要的一节）

MAUDE 最容易被误用之处，恰恰是它最明确声明"不能做"的事。FDA 官方在 openFDA device/event 页与 MAUDE 数据页反复列出三条边界：

1. 不能建立因果：报告中所列的产品与反应之间，无法确认因果关系。FAERS/MAUDE 的官方措辞是"a causal relationship cannot be established"；疑似关系可能存在，但未经医学验证，不应作为临床决策的唯一依据。
2. 不能算发生率：报告系统没有暴露分母（不知道某器械实际有多少台在用），因此无法从报告计数推断发生率或流行率，也无法评估事件率随时间的变化或跨器械比较事件率。
3. 不能读成"安全结论"：报告稀少不等于器械安全——它更可能只是漏报。同理，报告激增也未必是安全恶化，可能只是报告意识与收集力度提升（FDA 明言近年一直在加强不良事件收集，总数上升"很可能源于报告改善"）。

一句话记忆：MAUDE 里的每一条记录，都是"某人说发生了什么"（what someone said happened），而不是"已经查实的结论"（not a finding about what happened）。

0.4 与相邻概念的边界（防混淆）

概念	域	关系
MAUDE（本条）	医疗器械	器械不良事件报告库本体
FAERS（库内 rid=264）	药品	药品/生物制品不良事件自发报告库，与 MAUDE 平行
JADER（库内 rid=1088）	药品（日本）	日本 PMDA 药品不良事件库，跨国对照
openFDA（库内 rid=420）	多域门户	MAUDE 是其 device/event 端点的底层原始库；门户是聚合层
FDA 哨兵系统（库内 rid=505）	药品/器械	主动监测（分布式查询真实世界数据），与 MAUDE 的被动自发报告形成方法论对照
VAERS	疫苗	疫苗不良事件报告系统，同属被动监测但独立

关键区分：用户任务书所述"须与在库药品不良事件库（jader 1088、faers）区分"——本条是医疗器械不良事件，与药品两条报告体系完全独立（官方明示：器械走 MAUDE，药品走 FAERS，疫苗走 VAERS）。库中不存在 maude 同名/别名条目，非撞库。

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

Q1：MAUDE 的全名与缩写是什么？
Manufacturer and User Facility Device Experience（制造商与使用机构器械经验），缩写 MAUDE，读作 /mɔːd/。

Q2：谁维护它？
美国 FDA 下属的器械与放射健康中心（Center for Devices and Radiological Health，CDRH）。

Q3：数据从什么时候开始？
分层起点（FDA MDR Data Files 页口径）：使用机构报告自 1991 年；自愿报告自 1993 年 6 月；分销商报告自 1993 年；制造商报告自 1996 年 8 月。MAUDE 数据库本体自 1999 年起公开；更早的器械经验由 CDRH 的 DEN（Device Experience Network）系统收录（1984–1996）。openFDA 的 device/event 端点覆盖期为 2009 至 2026-10-07。

Q4：现在有多少条？
两个官方口径：openFDA device/event 端点 26,136,889 条（最后更新 2026-09-08）；FDA MDR Data Files 的 mdrfoithru2025 主记录 23,636,521 条（through 2025）。第三方全量索引（BEUDAMED）标注 25,039,198 条。三者时点与范围不同，引用时须标注时点（详见 §4）。

Q5：每年新增多少？
FDA 官方两处口径不同：openFDA 页称"每年数十万份"（several hundred thousand）；FDA MDR Data Files 页称"每年超过两百万份"（over two million）。差异源于统计口径（是否含去重前、是否含 ASR 汇总报告）。引用时须同时给出两个口径或注明所取页面。

Q6：报告由谁提交？
四路：（1）制造商（manufacturer，强制）；（2）进口商（importer，强制）；（3）器械使用机构（device user facility = 医院、门诊诊疗机构、护理院、门诊手术中心）；（4）自愿报告者（医护人员、患者、消费者，经 MedWatch 提交）。

Q7：什么时候必须报？
制造商/进口商在获悉"其上市器械可能致死、致严重伤害，或故障若复现可能致害"时，一般 30 个日历日内报告（需采取补救措施时为 5 个工作日）；器械使用机构报告死亡时，一般 10 个工作日内同时报 FDA 与制造商，报告严重伤害时报制造商（厂商不明则报 FDA）。

Q8：怎么获取？
四条路：（1）网页检索 accessdata.fda.gov（近 10 年，上限 500 条）；（2）openFDA API https://api.fda.gov/device/event.json；（3）FDA MDR Data Files 全量 zip 下载；（4）第三方索引平台。

Q9：什么许可？
openFDA 官方明示：数据为 public domain（公有领域），以 CC0 1.0 Universal 贡献，可复制、修改、分发、商用，无需许可。重要例外：GMDN® 术语内容（医疗器械命名法）受 The GMDN Agency 的商标与许可约束，用于 AI 训练或商业服务须另行取得授权。

Q10：有什么坑？
最主要三个：（1）报告量≠发生率（无分母）；（2）报告存在≠因果成立；（3）网页检索只看近 10 年且上限 500 条，做研究必须走全量下载或 API。其余坑见 §10 避坑清单。

§2 数据构成与规格

2.1 六类关联文件：MAUDE 可下载数据的骨架

MAUDE 的可下载数据并非一张大表，而是由多类关联文件拼装而成。以 FDA MDR Data Files 页的官方口径，可下载文件由以下 6 类构成，全部以 MDR REPORT KEY（报告主键）关联：

文件类	中文	内容	行粒度
Master Event Data	事件主表	不良事件与产品问题信息（MedWatch 3500 表 B、E、H 节），含分销商与制造商联系方式（F、G 节）	每个报告来源一条记录
Device Data	器械表	器械标识：制造商、产品名、型号、产品码等（D 节）	每个涉及的器械/部件一条
Patient Data	患者表	患者治疗与结局信息（高度脱敏）	每患者一条
Text Data（FOITEXT）	叙述文本表	事件描述与制造商评估的自由文本（B5、H3、H10 节）	每段文本一条
Device Problem Data	器械问题表	器械问题码（F10、H6 节）	每问题码一条
Patient/Problem Code 表	问题码/患者问题表	问题码映射或患者健康影响临床码	每码一条

方法学权威口径（Ensign & Cohen, 2018, eGEMs，PMC5994953）：MAUDE 可下载文件由 4 个主文件（Master Event / Device / Patient / Text）+ 2 个补充文件（Device Problems / Problem Code Descriptions） 构成，共计 135 个字段。论文同时指出：MAUDE 官网"所有记录类型以 MDR REPORT KEY 关联"的说明是不完整的——实际关联关系远比一句"都以主键相连"复杂（见 §4.3）。

2.2 双口径存照：6 类还是 7 张表？

这是一个必须存照的口径分歧：

• FDA MDR Data Files 页（官方下载页）：明确列出 6 类文件——Master Event、Device、Patient、Text、Device Problem、Patient Problem。
• PMC5994953 论文（方法学权威）：4 主 + 2 补 = 6 类 / 135 字段，其中补充第二表命名为 “Problem Code Descriptions”（问题码→短文本描述映射）。
• 任务书口径：“含 7 张关联表结构”。

核验结论：主流一手来源（FDA 官方页 + 方法学论文）均指向 6 类。任务书所述"7 张表"未获直接佐证。可能的解释有两条：（a）把 ASR（Alternative Summary Reporting） 或 DEN（Device Experience Network） 遗留数据文件另计，可达 7；（b）把 openFDA 端点的 UDI 相关表或问题码映射表单独拆出计数。本条按 6 类成稿，并将"7 张表"存照为遗留疑点（详见 §9.1 与 FACTS.md §9）。

2.3 记录粒度：三条容易踩空的规则

MAUDE 的数据模型有三条粒度规则，直接决定"数出来多少条"是否可靠：

规则一：一次事件可能产生多条事件记录。 FDA 官方明示：如果一个事件被使用机构、分销商、制造商和自愿报告者分别报告，则 Master Event 文件里会产生四条事件记录。因此"事件数"≠“报告数”≠“记录数”。

规则二：一个报告可能关联多个器械。 事件涉及的每个器械部件单独成一条 Device 记录（例如一台含多个组件的植入器械可能一次产生多条器械记录）。PMC5994953 与 Kavanagh 等人的髋关节假体研究均对此有专门说明。

规则三：缺失或拼写差异会导致同一事件产生不同主键。 若数据拼写错误、缺失或以不同方式表述，同一患者/事件可能获得不同的 MDR_REPORT_KEY，从而被计为多条记录。FDA 官方明示不作去重；研究者若不去重，会系统性高估事件数。

2.4 关键字段速查

Master Event Data（事件主表）常用字段：

• MDR_REPORT_KEY：报告主键，全库关联键
• REPORT_NUMBER：报告编号（形如 6176304-1，前 7 位为序号，末位为校验位）
• DATE_RECEIVED：FDA 收到报告的日期
• DATE_REPORT / REPORT_DATE：报告日期
• DATE_OF_EVENT：事件发生日期（常缺失）
• EVENT_TYPE：事件类型（D/IN/M/O，见 §2.5）
• REPORT_SOURCE_CODE：报告来源（P/U/D/M）
• SOURCE_TYPE：来源类型（可多值，逗号分隔）
• REMEDIAL_ACTION：补救措施
• MANUFACTURER_NAME：制造商名
• SUMMARY_REPORT：是否汇总报告
• MANUFACTURER_LINK_FLAG：分销商报告若后续有制造商报告，设为 ‘Y’

Device Data（器械表）常用字段：

• MDR_REPORT_KEY、DEVICE_EVENT_KEY
• BRAND_NAME（品牌名）、GENERIC_NAME（通用名）
• MANUFACTURER_D_NAME（器械制造商名）
• MODEL_NUMBER（型号）、CATALOG_NUMBER（目录号）
• DEVICE_REPORT_PRODUCT_CODE：FDA 三字母产品码（如 DZE、KWA）
• DEVICE_SEQUENCE_NUMBER
• UDI-DI：唯一器械标识（2022-10-20 起 openFDA 端点新增 UDI-DI 与 UDI-Public）

Text Data（FOITEXT 叙述表）常用字段：

• MDR_REPORT_KEY、MDR_TEXT_KEY
• TEXT_TYPE_CODE：文本类型（D=事件描述 / N=制造商补充叙述）
• DATE_REPORT
• FOI_TEXT：文本正文（含 FOIA 脱敏标记）

Patient Data（患者表）：高度脱敏，字段稀少——据报道仅有结局字段与少量治疗字段，实操中常不纳入分析。

2.5 编码体系：把字符串读成人话

MAUDE 用一套受控编码体系压缩信息，理解它们才能读懂数据：

EVENT_TYPE（事件类型）：

码	含义
D	Death（死亡）
IN	Injury（伤害）
M	Malfunction（故障）
O	Other（其他）
（空）	未提供

REPORT_SOURCE_CODE（报告来源）：

码	含义
P	Voluntary（自愿报告）
U	User Facility（使用机构）
D	Distributor（分销商）
M	Manufacturer（制造商）

SOURCE_TYPE（来源类型，可多值）：00 Other / 01 Foreign / 02 Study / 03 Literature / 04 Consumer / 05 Health Professional / 06 User facility / 07 Company representation / 08 Distributor / 99 Unknown。

TEXT_TYPE_CODE（文本类型）：

码	含义	MedWatch 表位置
D	事件或问题描述	B5
N	制造商补充叙述	H10

读懂一行的关键：看到 REPORT_SOURCE_CODE = U 就应意识到——这是"临床医生所见的叙述"，而非"厂商的投诉调查"；二者在证据性质上完全不同（见 §3.4）。看到 EVENT_TYPE = M（故障）要警惕：从轻微软件 bug 到灾难性器械失效都可能归入此类，具体是什么只有读 FOI_TEXT 才知道。

§3 报告制度：谁在什么时钟上报告

3.1 21 CFR Part 803：法律底座

MAUDE 的法律基础是 21 CFR Part 803（Medical Device Reporting，医疗器械报告规则）。该规则规定了三类强制报告主体与自愿报告渠道，以及各自的报告时限与内容要求。理解报告制度，是理解"MAUDE 里的数据为什么长这样"的前提。

3.2 四类报告主体与时限

报告主体	强制程度	必须报告的情形	时限
制造商	强制	死亡、严重伤害；以及"故障若复现可能致害"的故障	一般 30 个日历日；需补救措施时 5 个工作日
进口商	强制	死亡、严重伤害（报 FDA 与制造商）；故障（报制造商）	一般 30 个日历日
器械使用机构	强制	器械致其机构内患者死亡或严重伤害	死亡：10 个工作日（报 FDA 与制造商）；严重伤害：报制造商（厂商不明则报 FDA）
自愿报告者	自愿	医护人员、患者、消费者经 MedWatch（FDA 3500 表）自愿提交	无强制时限

器械使用机构的范围：医院、门诊诊疗机构、护理院（nursing home）、门诊手术中心（ambulatory surgical facility）。

3.3 MedWatch 3500：报告的物理形态

报告通过标准 MedWatch Form 3500 / 3500A 提交，事件详情由编码字段 + 叙述文本组合描述。这正是 MAUDE 数据双轨结构的来源：

• 编码轨：结构化字段（事件类型、问题码、产品码、器械分类等），便于聚合统计。
• 文本轨：自由文本叙述（事件描述 + 制造商叙述），承载具体临床细节。

MEDWATCH 3500 表中的各节与 MAUDE 文件的对应关系（据 PMC5994953 与字段解剖文）：B5→事件描述（Text 文件 TEXT_TYPE_CODE=D）；H10→制造商补充叙述（TEXT_TYPE_CODE=N）；D 节→Device 文件；F、G 节→Master Event 的制造商/分销商联系信息；F10、H6→Device Problem 与 Patient Problem 码。

3.4 报告者身份本身就是一个信号

同一个事件，由不同主体报告，其证据性质不同：

• 使用机构报告：通常是临床医生对其亲眼所见事件的叙述——第一手观察，描述性强。
• 制造商报告：通常是公司被要求披露的投诉调查——无论公司是否认同投诉者的说法都必须提交，往往包含厂商调查结论与纠正措施，但也可能写明"多次尝试联系用户未果"或"未能取回器械评估"。

因此，读到一条记录时，先看 REPORT_SOURCE_CODE，就能在阅读叙述前对证据性质有个预判。

3.5 FDA 如何使用 MDR

FDA 的医护专业人员会审查并分析报告，用以识别新的安全信号。官方明示对以下类型报告给予"高度关注"：涉及火灾、爆炸、过敏性休克（anaphylaxis）、儿科死亡，或多名患者死亡/严重伤害的报告。在适当时机，FDA 可能建议采取包括公共卫生警示、标签变更、器械召回、以及面向医护与消费者的教育活动等具体行动。

3.6 补充报告与"事件 vs 报告"的分母陷阱

MAUDE 中同一事件可有多条记录：初始报告（I）+ 后续补充报告（F） 会各自成条（TYPE_OF_REPORT 字段区分 I/F/X/O）。研究者若不去重，就会把一次事件数成多次。这直接引出方法学论文反复强调的核心概念——"报告分母"与"事件分母"的差异（report vs event denominators）：算报告数还是算事件数，结论可能显著不同。

§4 数据获取与工程细节

4.1 四条获取路径

路径	入口	覆盖	上限/规模
网页检索	accessdata.fda.gov MAUDE 检索界面	仅近 10 年	Simple/Advanced 各上限 500 条
openFDA API	https://api.fda.gov/device/event.json	2009–2026-10-07，每周更新	Elasticsearch 语法；无 key 240 次/分/IP、1000 次/天/IP
全量下载	FDA MDR Data Files 页（zip）	各报告类起始年份至今	pipe-delimited 文本，每月更新
第三方索引	BEUDAMED 等	全量索引	提供 API/MCP，附 510(k)/召回交叉

4.2 openFDA API 关键参数与限流

• 语法：Elasticsearch 查询语法，field:value，支持 AND/OR，count 参数做聚合统计，返回 JSON（meta + results）。
• 限流：无 API key 时 240 次/分钟/IP、1,000 次/天/IP；有 key（免费申请）时 240 次/分钟/key、120,000 次/天/key。
• 分页硬上限：skip + limit ≤ 25,000。大规模拉取必须按日期窗口切分，这是工程上的头号约束。
• 强制 HTTPS：api.fda.gov。
• 延迟：openFDA API 不一定包含最新报告（从提交到出现在 API 中有数天至数周延迟）；如需最新，走 MAUDE 官网月度更新或 AEMS。

4.3 全量下载的工程坑（PMC5994953 教训）

方法学论文以"经验教训"形式列出了一批实操陷阱，做二手数据分析者几乎必踩：

1. 文件格式：zip 内文件为 pipe-delimited（竖线分隔） 文本。
2. 表头不齐：Master Event 与 Device 文件带表头行，其余文件需手工补字段名——直接读会错位。
3. 非打印换行符（LF）：文件里存在极少数不可见的换行符，会导致记录在 LF 处被截断，后续内容被当作"新记录"处理，引发记录数错误与数据类型不兼容。用 SAS 时可用 TERMSTR=CRLF 选项规避。
4. 年份文件碎片化：Device 与 Text 文件按年新增，一个覆盖 1991 年至今的完整 MAUDE 库需要超过 50 个文件。
5. 早期数据另计：1998 年之前的 Device 数据、1996 年之前的 Text 数据是单独文件。
6. 补字符的老忠告：MAUDE 官网建议"导入前在第一条记录末尾加一个字符，否则最后一列数据可能丢失"——论文实测在 SAS 9 与 RStudio 中并不总是必要，但值得留意。
7. 关联关系比"都用主键相连"复杂：论文专门指出官网关联说明不完整，需要按文件类型逐一处理父子关系（Master Event 为父；Text、Device 为子；Patient 高度脱敏）。

4.4 数据规模硬数字（并列口径）

口径	数值	时点/来源
openFDA device/event 端点	26,136,889 条	2026-09-08，open.fda.gov/about/status
FDA MDR Data Files 主表 mdrfoithru2025	23,636,521 条	through 2025，FDA MDR Data Files 页
当年基础记录 mdrfoi.zip	1,406,457 条	FDA MDR Data Files 页
当月新增 mdrfoiadd.zip	261,298 条	FDA MDR Data Files 页
基础数据更新 mdrfoichange.zip	614,484 条	FDA MDR Data Files 页
第三方全量索引（BEUDAMED）	25,039,198 条	2026，beudamed.com

引用纪律：三者范围与时点不同（端点为 API 口径、主表为年度归档口径、第三方为索引口径），并列时必须标注时点，不可混用为单一"总数"。

§5 统计与聚合：在 MAUDE 上做分析的正确姿势

5.1 三个必须区分的计数单位

在 MAUDE 上做任何统计，第一步是明确"数的是什么"：

计数单位	定义	陷阱
报告数（report count）	以 MDR_REPORT_KEY 计数的记录数	同一事件多渠道报告会重复计数
事件数（event count）	去重后的真实事件数	需按事件键去重，MAUDE 官方不去重
器械数（device count）	Device 文件的记录数	一个报告可含多个器械，会大于报告数

方法学论文的核心告诫即在于此："报告分母"与"事件分母"的差异是 MAUDE 分析最常见的系统性偏差来源。

5.2 聚合分析的常用维度

• 按产品码（product code）聚合：标准化程度最高，比品牌名可靠得多（品牌名常拼写错误、缩写或过时）。研究某类器械风险时，官方推荐先用 FDA 产品分类数据库查出正确的三字母产品码再检索。
• 按事件类型聚合：D/IN/M/O 四类分布；注意"故障（M）"类占比通常最高，但其中相当比例经叙述核查实为用户错误而非器械失效。
• 按制造商聚合：注意同一公司多名（含并购遗留名）需模糊匹配。
• 按时间聚合：观察趋势，但须警惕报告行为变化带来的假趋势。

5.3 检索策略：先宽后窄

业界通行的 MAUDE 检索纪律：

1. 用产品码而非品牌名：品牌名不标准化，产品码标准化。
2. 先宽后窄：从产品码 + 较宽日期范围起步，再按事件类型或制造商收窄；起始过窄会遗漏相关报告。
3. 仔细读叙述：结构化字段给数量概况，自由文本叙述给实际临床细节。
4. 注意日期字段的区别：事件日期（DATE_OF_EVENT）与报告日期（DATE_REPORT）可能相差数月甚至数年，做时间序列时选错字段会得到错误的"趋势"。

5.4 信号检测方法（器械域）

器械警戒可迁移药物警戒的成熟信号检测方法（FDA 及学界对 FAERS 的标准做法）：

• 非均衡性分析（disproportionality analysis）：ROR（Reporting Odds Ratio，报告比值比）、PRR（Proportional Reporting Ratio，比例报告比）——频率学派。
• 贝叶斯方法：IC（Information Component）、MGPS（Multi-item Gamma Poisson Shrinker）——贝叶斯收缩估计。

关键共识：无论哪种方法，检出的"阳性信号"都只是假设（hypothesis），而非因果证明。信号的下一步是人工审评与流行病学研究，而非直接下结论。

5.5 典型实证研究（展示 MAUDE 的分析谱系）

研究	范围	关键数字
非临床场景器械伤害/故障分析（SASPublishers，2009–2013）	210 万条报告	85% 事件地点未知；非临床场景 13,739 条（占全部 0.7%，占已知地点报告 4.5%）；其中 97% 涉及家用器械
牙种植体上颌窦相关事件文本挖掘（BMC Oral Health 2026）	2015–2025，产品码 DZE	3,386,753 条 DZE 器械记录 / 3,386,630 个唯一 DZE 报告
髋关节假体 KWA 产品码报告来源分析（Kavanagh，1997–2017）	产品码 KWA	按报告来源与报告者职业分析

这些研究展现了 MAUDE 分析的两大范式：结构化字段聚合（产品码 + 事件类型）与叙述文本挖掘（FOI_TEXT 的 NLP 分析）。后者正是 MAUDE 作为"医学文本数据集"的价值所在——它蕴含数十万至数百万条真实世界器械事件叙述，是医疗 NLP 与事件抽取研究的富矿。

§6 获取与许可：CC0 的宽松与 GMDN 的例外

6.1 许可结论（一手核实）

openFDA 官方许可页（open.fda.gov/license/，最后修改 2014-05-27）明示：

除另有说明外，openFDA 上的内容、数据、文档、代码及相关材料均为 public domain（公有领域），以 Creative Commons CC0 1.0 Universal 贡献。依 CC0，FDA 已在法律允许的最大范围内放弃全球著作权，包括所有相关及邻接权利。你可以复制、修改、分发和表演本作品，甚至用于商业目的，全部无需申请许可。

任务书所述"公共领域/CC0（须核实）"——核验通过：确为 public domain + CC0 1.0 Universal。这是本条在 AI-Ready 意义上许可最宽松的资产之一。

6.2 重要例外：GMDN® 术语

CC0 有一个必须标注的例外：

GMDN® 是 The GMDN Agency 的注册商标。openFDA 站内包含由 The GMDN Agency 提供的 GMDN 内容（Global Medical Device Nomenclature，全球医疗器械命名法），该内容依 GMDN Agency 许可使用。任何希望从本网站提取 GMDN 内容、将其作为创建与支持商业服务（如替代分类、替代术语分配、映射到其他分类或本体，或用于 AI 训练）之基础的数据/信息提供者，必须首先取得 The GMDN Agency 的适当许可。未经许可，不得进行此类活动。

实操含义：如果你只是用 MAUDE 的 MDR 记录做分析——CC0，畅通无阻。但如果你的产品依赖 GMDN 术语（例如构建器械分类服务、做术语映射、用 GMDN 名称训练模型），就必须单独向 GMDN Agency 取得授权。这是 AI-Ready 使用中最容易被忽略的许可陷阱。

6.3 数据质量免责声明

openFDA 每个 API 响应的 meta 段都包含免责声明，MAUDE 数据页亦有专门声明：

“Do not rely on openFDA to make decisions regarding medical care… assume all results are unvalidated.”（请勿依赖 openFDA 做医疗决策……假设所有结果均未经校验。）

MAUDE 数据页明确：MDR 未经过广泛的验证或核查，不能据此在产品与所报反应之间建立因果关系；疑似关系可能存在，但未经医学验证，不应作为临床决策或产品安全/有效性假设的唯一依据。

6.4 FOIA 脱敏规则

依《信息自由法》（FOIA）与《隐私法》（5 U.S.C. § 552），FDA 在公开披露前必须删除：

• 构成贸易秘密、商业机密或财务信息的内容 → 替换为 (b)(4)（例如产品配方）。
• 构成人员、医疗及类似信息且会构成"明显无理由侵犯个人隐私"的内容 → 替换为 (b)(6)（例如患者年龄）。
• 报告者身份与使用机构标识一律删除。

因此 MAUDE 是去标识化的公开数据：无患者出生日期、年龄、体重、性别等直接标识（这也是它被广泛认定为可安全二次利用的原因）。但注意，(b)(4)/(b)(6) 标记本身也是分析时需过滤的噪声。

6.5 版本演进链

• 1991 / 1993 / 1996：使用机构 / 自愿与分销商 / 制造商报告陆续入库
• 1999：MAUDE 数据库本体公开
• 2014-06-02：openFDA API 上线，首发四端点含 device/event
• 2022-10-20：openFDA 的 UDI 端点新增 UDI-DI 与 UDI-Public 字段（UDI-Public 为 MDR 报告中所提供标识的脱敏版本；注意并非所有 MDR 都提供 UDI 数据，且当前数据未经校验）
• 2026：MAUDE 数据迁入 AEMS（Adverse Event Monitoring System）

6.6 AI-Ready 就绪度小结

维度	评价
许可宽松度	极高（CC0，可商用）——受 GMDN 例外约束
获取便利度	高（网页/API/全量下载三路）
结构化程度	中高（编码字段 + 自由文本双轨）
规模	极大（逾 2,300 万条）
新鲜度	高（API 每周、下载每月、AEMS 迁入后趋近实时）
文档完备度	中（官网关联说明不完整，需依赖方法学论文补全）
机器可读性	中高（pipe-delimited 需清洗；API 为 JSON）
主要阻碍	叙述文本质量参差、字段缺失普遍、粒度规则复杂

§7 生态与影响：MAUDE 在器械安全版图中的位置

7.1 谱系：从 DEN 到 AEMS

MAUDE 不是凭空出现的，它站在一条三十余年的制度演进线上：

DEN（Device Experience Network，1984–1996 遗留报告）→ MAUDE（1991 起分报告类入库，1999 库本体公开）→ openFDA API（2014 起程序化访问）→ AEMS（2026 数据迁移）

FDA 在 MDR Data Files 页同时保留了 ASR（Alternative Summary Reporting，替代汇总报告，1999–2019-04） 与 DEN 两类历史数据，作为 MAUDE 的补充。理解这条谱系，才能解释为什么"某器械的历史报告"可能分散在三个不同系统里。

7.2 AEMS：2026 的结构性变局

FDA 官方明示"2026 年 MAUDE 数据将迁入 AEMS"。据行业分析，AEMS（Adverse Event Monitoring System）相对 MAUDE 的核心差异：

维度	MAUDE	AEMS
界面	表单式查询	交互式仪表盘（按产品类别分页）
刷新	定期更新（月度/季度批）	每日刷新（近实时，约 24 小时内）
范围	仅器械报告	跨产品（药品/器械/疫苗/化妆品/食品/烟草）
数据范围	1991 年起（逾 1,600 万器械报告）	1968 年至今（含迁移的遗留数据）
导出	CSV/TXT 下载	仪表盘导出线列表
AI 工具	无	集成 AI 脱敏与数字化工具

对使用者的影响：器械 MDR 的数据访问模式正在从"下载静态文件"转向"仪表盘交互 + 每日刷新"。但报告提交渠道自身未变（21 CFR Part 803 的报告义务与时限不变）。做长期分析者需注意数据源切换带来的口径连续性风险。

7.3 与其他 FDA 器械数据的交叉

MAUDE 很少被孤立使用，常见交叉组合：

• TPLC（Total Product Life Cycle）：整合器械上市前（510(k)、PMA）与上市后（MAUDE、召回）数据于同一检索界面——做竞品情报与器械全生命周期分析时极为有用。
• 器械召回（device/recall）：把 MAUDE 报告与召回事件关联，观察"报告聚集 → 召回"的链条。
• 器械分类（device/classification）：用产品码把 MAUDE 记录映射到器械分类（Class I/II/III）与监管描述。
• UDI（唯一器械标识）：借 UDI-DI 把报告精确锚定到具体器械型号。

7.4 MAUDE 与 AI 医疗器械的张力

这是 MAUDE 当下最具讨论价值的议题，也是本条目作为 AI-Ready 资产必须点明的一节：

MAUDE 的机制无法捕获 AI 特有的失效模式。 行业分析（StarFish Medical）指出：AI 赋能的器械会引入 MAUDE 目前无法收录的风险——概念漂移（concept drift） 与 协变量偏移（covariate shift）。这类问题会降低模型性能，却在技术上不构成"器械故障"，因而不满足 MDR 的报告触发条件。而 MAUDE 的案例级（case-by-case）结构，也难以揭示那些只有在大规模聚合使用中才可见的 AI 性能问题。

背景数字：截至 2025-08-20，FDA 的 AI 赋能医疗器械清单已收录 1,247 件（2023 年底为 864 件），增长迅猛。这意味着 MAUDE 与 AI 器械安全之间正形成一个结构性缺口：增长最快的器械类别，恰是现有被动报告体系最不擅捕捉的类别。这一缺口是该领域未来数年最重要的研究议程之一。

7.5 全球器械警戒版图中的位置

MAUDE 是全球器械不良事件公开数据中最重要、最易获取的一个。同类系统对照（据 meddeviceguide 综述）：

系统	地区	可获取性
MAUDE	美国	免费，全量可下载，API 完备
EUDAMED	欧盟	部分可用，全面警戒模块预计 2027 Q4 起强制
DAEN（TGA）	澳大利亚	免费，PDF 结果，检索较难
PMDA	日本	部分免费，英文有限
MHRA（Yellow Card）	英国	免费，器械警戒数据较受限
Swissmedic / ANSM / BfArM	瑞士/法国/德国	免费，多为 FSN 与警示，非完整事件库

结论：在研究者可及性上，MAUDE 是唯一提供完整原始记录全量下载 + 免费 API 的全球级器械不良事件库——这正是它成为器械警戒研究事实标准的原因。

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

8.1 被动监测的天花板由"报告行为"而非"真实风险"决定

MAUDE 最深刻的一条启示是：在一个被动报告系统中，测量到的是报告行为，而不是风险本身。同一款器械，在报告文化成熟的医院用得多，报告就多；在一家刚经历培训断层、批量补报的医院用得多，报告也会一次性激增。FDA 官方自己就坦言，近年不良事件总数的上升"很可能源于报告改善"。这提示所有基于 MAUDE 的结论都必须先问一句：这个变化，是风险变了，还是报告变了？

8.2 分母是自发报告数据的原罪

MAUDE 没有"多少台器械在用"的字段。这意味着报告计数无法换算成率。所有"某器械报告数最高所以最危险"的推断都犯了同一个错误：把分子当成率。正确做法是把报告计数视为一条值得追查的线索，而非一个能自行解答问题的数字。

8.3 编码是索引，不是诊断

MAUDE 的编码字段（事件类型、器械问题码、患者问题码）由填报者从受控词表中选择——往往不是亲历事件的临床医生，也很少有人在选码时手握器械工程资料。因此这些码应被视为粗略的检索索引，而非经裁决的因果。真正的细节在叙述文本里。

8.4 文本叙述是最大价值，也是最大噪声

MAUDE 的自由文本字段（事件描述 + 制造商叙述）是数据库"最有价值但也最不一致"的部分。它承载了结构化字段无法表达的具体临床情节，是医疗 NLP 的富矿；但它也常简短、不完整、表述不清，且含 (b)(4)/(b)(6) 脱敏标记。任何基于 MAUDE 文本的自动化分析，都必须把"文本质量参差"作为一等公民来建模。

8.5 数据模型复杂度是隐性门槛

MAUDE 不是一张表，而是 6 类以主键松耦合的文件，且官网关联说明不完整。方法学论文的价值恰在于此——它把"拼接 MAUDE 文件"这一隐性门槛显性化了。这提示：一个数据集的 AI-Ready 程度，不只取决于许可与规模，还取决于拼装成本。MAUDE 在这三者间呈现一个典型张力：许可与规模都极优，拼装成本却不低。

§9 与库内条目的关系

9.1 家族图谱与消歧

MAUDE 在千方病案医数集内没有同名或别名条目（DB 实查无 maude 记录），但与以下条目构成明确的上下游与对照关系：

库内条目	rid	关系类型	说明
openFDA	420	上游门户（聚合层）	MAUDE 是 openFDA device/event 端点的底层原始库；openFDA 是其程序化访问入口
FAERS	264	平行对照（药品域）	药品/生物制品不良事件自发报告库，与 MAUDE 分属两条独立报告体系，方法论高度可比
FDA 哨兵系统	505	方法论对照	主动监测（分布式查询真实世界数据）vs MAUDE 被动自发报告
JADER	1088	跨国对照（药品域）	日本 PMDA 药品不良事件库，同属被动监测
cardiac-implantable-device-cxr	599	应用侧（器械域）	心内植入装置影像数据集，属器械数据类型而非事件数据

9.2 关键消歧（检索者必读）

1. MAUDE ≠ FAERS ≠ JADER：官方明示器械走 MAUDE、药品走 FAERS、疫苗走 VAERS。把 MAUDE 与 FAERS 混为"一个库"是最常见的检索错误。
2. MAUDE ≠ openFDA：openFDA 是多域门户/API 聚合层，MAUDE 是其中器械域的底层库。openFDA 还含药品（drug/event=FAERS）、食品、烟草、化妆品等多个端点。
3. MAUDE ≠ FDA 哨兵系统：哨兵是主动监测系统（主动查询分布式健康数据），MAUDE 是被动自发报告系统，二者互补而非替代。
4. MAUDE ≠ 器械影像数据集：cardiac-implantable-device-cxr(599) 是影像数据；MAUDE 是事件报告文本与编码数据。

9.3 检索路径建议

• 想做器械警戒/药物警戒方法论研究：MAUDE（本条）+ FAERS（264）双库对照读，看被动监测的共性与器械/药品的差异。
• 想用 openFDA API 做工程接入：先读 openFDA（420）了解门户全貌与统一认证限流，再回到本条看 device/event 端点的具体字段结构。
• 想研究主动 vs 被动监测：MAUDE（本条）+ FDA 哨兵（505）对照。
• 想研究器械数据全谱系：本条 + cardiac-implantable-device-cxr（599）——事件数据与影像数据的对照。

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

坑 1：把报告计数当发生率。 最常见也最致命。MAUDE 无暴露分母，报告数不能换算成率，也不能跨器械比较"谁更危险"。FDA 官方明示"incidence or prevalence of an event cannot be determined from this reporting system alone"。对策：把计数降格为线索，任何涉及"率"的表述都要标注不可得。

坑 2：把报告存在当成因果成立。 报告只是"某人说发生了什么"，不是"已查实的结论"。FDA 官方：“a causal relationship cannot be established”。对策：复述报告内容而非断言器械致病；除非叙述本身记录了查实的调查结论。

坑 3：在网页界面找 10 年前的报告。 MAUDE 网页检索界面仅覆盖近 10 年，且 Simple/Advanced 各上限 500 条。对策：历史报告与大规模检索一律走 MDR Data Files 全量下载或 openFDA API。

坑 4：混用 MAUDE 与 FAERS 数据。 器械走 MAUDE、药品走 FAERS，两条独立体系。对策：检索前先明确产品是器械还是药品；器械用 device/event 端点，药品用 drug/event。

坑 5：忽略重复报告导致高估事件数。 同一事件可经多渠道重复提交，拼写/缺失差异会产生不同 MDR_REPORT_KEY，FDA 官方不去重。对策：分析前按事件键去重；区分"报告分母"与"事件分母"。

坑 6：把"故障（M）"事件都当作器械失效。 事件类型为 M 的报告从轻微软件 bug 到灾难性失效都有可能，且相当比例经叙述核查实为用户错误。对策：读 FOI_TEXT 叙述确认具体情形，不只看编码。

坑 7：用品牌名而非产品码检索。 品牌名常拼写错误、缩写或过时（变化影响检索结果，官方明示"仅检索包含检索词的记录"）。对策：先查 FDA 产品分类数据库得到三字母产品码，用产品码检索，再按需收窄。

坑 8：混淆事件日期与报告日期。 DATE_OF_EVENT（事件发生）与 DATE_REPORT/DATE_RECEIVED（报告提交/接收）可能相差数月甚至数年，且事件日期常缺失。做时间序列时选错字段会得到错误趋势。对策：明确分析目的对应的日期字段；缺失严重时说明其影响。

坑 9：以为数据是"干净"的结构化表。 MAUDE 全量下载是 pipe-delimited 文本，Master/Device 带表头而 Patient/Text 需手工补字段名，且存在非打印换行符（LF）会导致记录截断。对策：按 PMC5994953 的导入要点处理；TERMSTR=CRLF（SAS）；校验记录数。

坑 10：忽略 GMDN 术语的许可限制。 MAUDE 整体是 CC0 可商用，但 GMDN® 术语内容受 The GMDN Agency 许可约束，用于 AI 训练或商业服务须另行授权。对策：若产品依赖 GMDN 术语，单独取得授权；仅用 MDR 记录做分析则不受此限。

附加坑（AI 器械方向）：期待 MAUDE 捕捉 AI 失效。 MAUDE 无机制报告概念漂移/协变量偏移等 AI 特有失效模式，因其不构成传统"器械故障"；其案例级结构也难揭示需大规模聚合才可见的 AI 性能问题。对策：AI 器械安全研究不能仅依赖 MAUDE，需结合真实世界性能监测（RWP）等补充手段。

§10.5 DAIMS 评估：数据资产就绪度评分

DAIMS（Data Asset Information Maturity Score，数据资产信息成熟度评分）从八个维度评估数据集作为 AI-Ready 资产的就绪度，满分 5 分：

维度	评分	依据
权威性（Authority）	5.0	美国 FDA 官方数据库，法定强制报告制度（21 CFR Part 803）支撑
规模（Scale）	5.0	逾 2,300 万条报告记录，三十余年跨度
许可宽松度（Licensing）	4.5	CC0 公有领域可商用（扣 0.5 因 GMDN 术语例外）
可得性（Accessibility）	5.0	网页/API/全量下载/第三方索引四路，无门槛
新鲜度（Freshness）	4.5	API 每周更新；迁入 AEMS 后趋近每日刷新（现阶段下载侧为月度）
结构化程度（Structure）	4.0	编码字段 + 自由文本双轨；6 类文件需拼装，官网关联说明不完整
互操作性（Interoperability）	4.0	有产品码/UDI-DI 等标准标识，但字段命名与编码体系不统一于通用本体
文档完备度（Documentation）	3.5	官网说明存在不完整与口径冲突（关联关系、文件命名），需依赖外部方法学论文补全
综合	4.4	世界级器械安全数据资产；短板在拼装成本与文档一致性

DAIMS 结论：MAUDE 是一份许可与规模双优、拼装与文档偏弱的典型 AI-Ready 资产。其价值不在"拿来即用"，而在"投入适度的工程与领域知识后，可释放巨大的安全监测价值"。对 AI 应用而言，它是构建器械安全问答、事件抽取、信号检测系统的必然起点。

§10.6 写作与引用规范（供二次使用者参考）

• 引用 MAUDE 规模数字时必须标注时点与口径（openFDA 端点 26,136,889 条/2026-09-08 vs MDR Data Files 主表 23,636,521 条/through 2025）。
• 引用"每年报告量"时注意 FDA 两页口径不同（数十万 vs 超两百万），建议双列或注明所取页面。
• 陈述任何"因果"或"率"时必须附带 MAUDE 官方免责边界。
• 涉及病历文本复述时注意 (b)(4)/(b)(6) 脱敏标记，不要误读为数据噪声。
• 学术引用建议优先引方法学论文（Ensign & Cohen 2018, eGEMs, DOI 10.5334/egems.221），它是理解文件结构最权威的单篇文献。

§11 总结

11.1 三句话总结

1. MAUDE 是美国 FDA 依 21 CFR Part 803 强制收集的医疗器械不良事件（MDR）报告库，四路报告（制造商/进口商/使用机构/自愿者）累计逾 2,300 万条，是器械安全监测的全球事实基准。
2. 它以 CC0 公有领域开放（可商用），提供网页检索、openFDA API、全量 pipe-delimited 下载三路获取，但受 GMDN® 术语许可例外约束。
3. 它是被动监测系统，先天不能建立因果、不能计算发生率——报告量反映的是报告行为而非真实风险；做分析必须先分清报告分母与事件分母。

11.2 适合谁

• 器械警戒与上市后监测（PMS）从业者：MAUDE 是必备的数据库检索对象。
• 药物警戒/信号检测研究者：器械域的信号检测方法可从 FAERS 迁移，MAUDE 提供器械侧实证。
• 医疗器械法规事务（RA）从业者：做竞品风险分析、等同器械评估、PSUR 数据库检索。
• 医疗 NLP 研究者：数十万至数百万条真实世界事件叙述文本，是事件抽取与文本挖掘的富矿。
• 真实世界数据（RWD）分析者：需要大规模、低门槛、可商用的器械安全数据。
• AI 医疗器械合规研究者：研究现有被动报告体系对 AI 器械安全监测的结构性缺口。

11.3 不适合谁

• 想估计某器械"致病率"的人：MAUDE 无分母，做不到。请改用主动监测或流行病学研究。
• 想直接拿"干净结构化表"做建模的人：MAUDE 需拼装 6 类文件并清洗文本，不是即用型数据集。
• 想用 MAUDE 证明某个器械"安全"的人：报告稀少更可能是漏报，不能证明安全。
• 不了解 GMDN 许可就打算商用 GMDN 术语的人：需先取得 The GMDN Agency 授权。

11.4 30 秒决策卡

要用 MAUDE 吗？

• 需要器械不良事件数据 → 是
• 需要药品数据 → 否，去 FAERS（rid=264）
• 需要发生率 → 否，MAUDE 无分母
• 需要因果结论 → 否，MAUDE 只记录报告
• 需要近 10 年、少量结果 → 用网页检索
• 需要全量/历史/程序化 → 用 MDR Data Files 或 openFDA API
• 商用且依赖 GMDN 术语 → 先取得 GMDN Agency 授权

FAQ（高频问答 32 问）

A. 基础认知

A1. MAUDE 是什么的缩写？
Manufacturer and User Facility Device Experience（制造商与使用机构器械经验）。

A2. 它是药品还是器械数据库？
器械。药品走 FAERS，疫苗走 VAERS，器械走 MAUDE——三者独立。

A3. 谁在维护？
FDA 的 CDRH（器械与放射健康中心）。

A4. 法律依据是什么？
21 CFR Part 803（Medical Device Reporting 规则）。

A5. MAUDE 与 openFDA 是什么关系？
openFDA 是 FDA 的多域开放数据门户/API 聚合层；MAUDE 是其中器械事件（device/event）端点的底层原始库。

A6. MAUDE 与 FAERS 能合并分析吗？
技术上可分别获取，但不应混为一库：报告制度、触发条件、编码体系不同。做跨域研究需谨慎对齐口径。

A7. 什么是 MDR？
Medical Device Report（医疗器械报告），MAUDE 收录的正是 MDR。

B. 数据与获取

B1. 有多少条数据？
openFDA device/event 端点 26,136,889 条（2026-09-08）；MDR Data Files 主表 23,636,521 条（through 2025）；第三方索引 25,039,198 条。三者口径与时点不同，引用须标注。

B2. 数据从哪年开始？
分报告类：使用机构 1991、自愿 1993-06、分销商 1993、制造商 1996-08；MAUDE 库公开自 1999。openFDA API 覆盖 2009–2026-10-07。

B3. 怎么免费获取？
四条路：网页检索（accessdata.fda.gov）、openFDA API、MDR Data Files 全量下载、第三方索引。

B4. 网页检索能查多久以前的数据？
仅近 10 年；更早的走 MDR Data Files 下载。

B5. 网页检索结果有上限吗？
有，Simple/Advanced 各上限 500 条。大规模检索必须走下载或 API。

B6. openFDA API 有限流吗？
无 key：240 次/分/IP、1,000 次/天/IP；有 key（免费）：240 次/分/key、120,000 次/天/key。分页硬上限 skip+limit ≤ 25,000。

B7. 全量下载是什么格式？
zip 压缩的 pipe-delimited（竖线分隔） 文本，每月更新。

B8. 数据多久更新一次？
MAUDE 官网检索界面月度更新；openFDA API 每周；AEMS 迁入后近实时（约 24 小时）。

B9. 需要 API key 吗？
不需要也能用（限流较低）；免费申请 key 可提升限额。

B10. 数据会移到别处吗？
会。FDA 明示 2026 年 MAUDE 数据将迁入 AEMS。

C. 结构与字段

C1. 有几张表/几类文件？
6 类（Master Event / Device / Patient / Text / Device Problem / Patient Problem），共 135 字段，以 MDR REPORT_KEY 关联。任务书所述"7 张表"未获一手佐证，见 §2.2、§9.1。

C2. 主键是什么？
MDR_REPORT_KEY（报告主键），全库关联键。

C3. 报告编号长什么样？
形如 6176304-1，前 7 位为报告序号，末位为校验位。

C4. 关键字段有哪些？
EVENT_TYPE、DATE_RECEIVED、DATE_OF_EVENT、DEVICE_REPORT_PRODUCT_CODE、BRAND_NAME、GENERIC_NAME、MANUFACTURER_D_NAME、MODEL_NUMBER、UDI-DI、TEXT_TYPE_CODE、FOI_TEXT 等。

C5. 事件类型有哪些码？
D=Death（死亡）、IN=Injury（伤害）、M=Malfunction（故障）、O=Other（其他）。

C6. 报告来源码有哪些？
P=Voluntary、U=User Facility、D=Distributor、M=Manufacturer。

C7. 文本类型码 D 和 N 是什么？
D=事件/问题描述（MedWatch B5）；N=制造商补充叙述（H10）。

C8. Patient 文件能用吗？
高度脱敏，字段稀少（仅结局与少量治疗字段），实操中常不纳入分析。

C9. 什么是 UDI-DI？
唯一器械标识的器械标识符，2022-10-20 起 openFDA 端点新增；但并非所有 MDR 都提供 UDI，且数据未经校验。

C10. (b)(4) 和 (b)(6) 是什么？
FOIA 脱敏标记：(b)(4) 替换贸易秘密/商业信息，(b)(6) 替换个人/医疗信息（如患者年龄）。

D. 统计与分析

D1. 能算某器械的发生率吗？
不能。 无暴露分母，FDA 官方明示无法从报告系统确定事件的发生率或流行率。

D2. 报告多说明器械危险吗？
不一定。报告量受使用人数、报告文化、报告力度影响。广泛使用的器械报告自然更多（“常见产品因使用人数多而有更多不良事件”——FDA 官方表述）。

D3. 报告少说明器械安全吗？
不一定。可能只是漏报。被动报告系统的漏报是系统性低估。

D4. 怎么做信号检测？
可迁移药物警戒方法：ROR/PRR（频率学派）或 IC/MGPS（贝叶斯）。但阳性信号只是假设，非因果证明。

D5. 同一事件会被数成多条吗？
会。多渠道报告 + 拼写差异会产生不同主键，FDA 不去重。分析前须去重并区分报告分母/事件分母。

E. 许可与合规

E1. MAUDE 数据可以商用吗？
可以。openFDA 数据为 CC0 1.0 Universal 公有领域，可复制/修改/分发/商用无需许可。

E2. 有任何许可例外吗？
有。GMDN® 术语内容受 The GMDN Agency 许可约束，用于 AI 训练或商业服务须另行授权。

E3. 数据含个人隐私信息吗？
不含直接标识。依 FOIA 已删除报告者身份、机构标识及个人/医疗信息。

E4. 引用数据需要署名吗？
CC0 不强制署名，且不应暗示 FDA 背书；学术使用建议规范引用来源。

E5. 用 MAUDE 做医疗决策可以吗？
不可以。官方免责声明明示"请勿依赖 openFDA 做医疗决策……假设所有结果未经校验"。

F. 工程与实践

F1. 全量下载导入有什么坑？
表头不齐（需手工补字段名）、非打印换行符导致截断、年份文件碎片化（完整库 >50 个文件）、格式为 pipe-delimited。

F2. 数据拼接复杂吗？
比想象的复杂。官网"都以主键关联"的说明不完整，需按文件类型逐一处理父子关系（见 PMC5994953）。

F3. AI 器械的失效 MAUDE 能记录吗？
不能有效记录。概念漂移/协变量偏移等不构成传统"器械故障"，不触发 MDR 报告，是结构性盲区。

F4. 做时间序列要注意什么？
注意区分事件日期与报告日期（可能相差数月数年，事件日期常缺失），并警惕报告行为变化带来的假趋势。

F5. 检索应该用品牌名还是产品码？
产品码。品牌名不标准化（拼写错误/缩写/过时），产品码标准化，先查 FDA 产品分类数据库得码。

事实清单（硬事实 32 条）

1. MAUDE 全名：Manufacturer and User Facility Device Experience。
2. 主管机构：美国 FDA / CDRH。
3. 法律依据：21 CFR Part 803。
4. openFDA device/event 端点记录数：26,136,889 条（2026-09-08）。
5. FDA MDR Data Files 主表 mdrfoithru2025：23,636,521 条（through 2025）。
6. 第三方全量索引（BEUDAMED）：25,039,198 条。
7. openFDA device/event 覆盖期：2009 至 2026-10-07。
8. openFDA device/event 更新频率：每周。
9. MAUDE 库本体公开起始：1999 年。
10. 使用机构报告起始：1991 年。
11. 自愿报告起始：1993 年 6 月。
12. 分销商报告起始：1993 年。
13. 制造商报告起始：1996 年 8 月（FDA 官方页口径）。
14. 更早遗留系统：DEN（Device Experience Network）收录 1984–1996 报告。
15. ASR（Alternative Summary Reporting）收录 1999–2019-04 报告。
16. 数据文件类数：6 类（Master Event / Device / Patient / Text / Device Problem / Patient Problem）。
17. 字段总数：135 个（PMC5994953）。
18. 关联主键：MDR_REPORT_KEY。
19. 报告编号形态：如 6176304-1（前 7 位序号 + 末位校验位）。
20. 事件类型码：D/IN/M/O（死亡/伤害/故障/其他）。
21. 报告来源码：P/U/D/M（自愿/使用机构/分销商/制造商）。
22. 文本类型码：D（事件描述，B5）/ N（制造商叙述，H10）。
23. 网页检索覆盖：近 10 年。
24. 网页检索上限：Simple/Advanced 各 500 条。
25. openFDA 无 key 限流：240 次/分/IP、1,000 次/天/IP。
26. openFDA 分页硬上限：skip+limit ≤ 25,000。
27. 全量下载格式：pipe-delimited 文本（zip）。
28. 全量下载更新频率：每月。
29. 许可：public domain + CC0 1.0 Universal。
30. 许可例外：GMDN® 术语受 The GMDN Agency 许可约束。
31. 脱敏标记：(b)(4)（贸易/商业信息）、(b)(6)（个人/医疗信息）。
32. 2026 迁移目标系统：AEMS（Adverse Event Monitoring System）。

---

消歧与互链说明（不写入 frontmatter，仅正文）：本条 MAUDE 与库内 FAERS（rid=264）、JADER（rid=1088）分属器械/药品两条独立报告体系，非同一实体，勿合并；与 openFDA（rid=420）为底层库与聚合门户的上下游关系；与 FDA 哨兵系统（rid=505）为被动 vs 主动监测的方法论对照。数据库实查确认库内无 maude 同名或别名条目，本次为非撞库首发。

主要来源：FDA openFDA device/event 端点页、openFDA MAUDE 数据页、openFDA 许可页、FDA MDR Data Files 页、FDA MAUDE 检索界面、PMC5994953（Ensign & Cohen 2018, eGEMs）、FDA 21 CFR Part 803。

§12 深度扩展：MAUDE 的六个切面

12.1 切面一：报告制度的社会学

MAUDE 表面上是一个数据库，本质上是一套制度激励的产物。理解它的数据形态，必须先理解推动报告产生的三股力量：

第一股：法律强制。 21 CFR Part 803 规定了制造商、进口商、使用机构的报告义务与时限。这套规则决定了什么事件会被记录——只有达到"死亡/严重伤害/可致害故障"阈值的事件才进入强制报告通道。轻微不适、短暂异常、无后果的近似错误（near miss）不会进入这套体系。

第二股：报告者的处境差异。 同一事件的四类报告者，动机与视角截然不同：

• 制造商：30 日强制（需补救措施 5 日）。但制造商报告往往是投诉调查——公司被要求披露，无论是否认同投诉者说法。因此制造商叙述里常出现"多次尝试联系用户未果""未能取回器械评估"等措辞，反映的是信息获取的困难，而非事件性质。
• 使用机构：死亡 10 工作日。临床医生对亲眼所见事件的叙述——第一手观察，但受限于临床视角，未必理解器械工程细节。
• 进口商/分销商：处于制造商与使用机构之间，报告往往转发性、信息衰减。
• 自愿者（患者/消费者/医护）：无时限，主观性强，常缺器械型号与批次信息。

第三股：报告文化的演变。 FDA 明言近年一直在加强不良事件收集，总数上升"很可能源于报告改善"。这意味着时间序列上的增长，不能直接解读为风险上升——它可能是报告意识提升、报告渠道便利化、或监管关注度提高的结果。

方法论启示：研究 MAUDE 数据前，先问"这条记录为什么存在"。理解了报告制度，才知道数据的选择偏差（selection bias） 在哪里。

12.2 切面二：从编码到叙述的双轨证据

MAUDE 最有价值的工程设计，是它的编码-叙述双轨结构：

编码轨的优势：结构化、可聚合、可统计。产品码、事件类型、问题码让百万级记录得以快速切片。研究者可以秒级回答"某产品码下故障类报告有多少条"。

编码轨的陷阱：编码由填报者从受控词表选择，往往不是亲历事件的临床医生，也少有人在选码时手握器械工程资料。因此：

• 事件类型为 M（故障）的报告，可能从轻微软件 bug 到灾难性失效。
• 报告为"死亡"的记录，可能查实与器械无关（例如患者从轮椅上摔落死亡被归入"死亡"，而实际归因于患者虚弱而非轮椅本身）。
• 器械问题码的选择可能混杂用户错误与器械失效。

叙述轨的价值：自由文本承载了编码无法表达的具体情节——用户当时在做什么、器械做了什么或没做什么、制造商取回器械检查后发现了什么。

双轨的正确用法：编码轨用来检索与聚合，叙述轨用来确认个案性质。任何基于编码轨的统计结论，在关键处都应以叙述轨抽样核查。

这使 MAUDE 同时成为两类研究的对象：结构化统计分析（编码轨）与文本挖掘/NLP（叙述轨）。后者在近年尤其活跃——事件抽取、问题分类、因果线索识别等任务都在 MAUDE 叙述上找到了真实应用场景。

12.3 切面三：MAUDE 作为医疗 NLP 资源

从 AI-Ready 的视角看，MAUDE 的叙述文本是一份被低估的资产：

规模：逾 2,300 万条报告，其中相当比例含事件描述与制造商叙述两段文本。即使按较低比例估算，也是一个百万量级以上的医疗事件文本语料。

领域独特性：与临床病历（EHR）文本不同，MAUDE 叙述是器械-人交互的事件叙述，涵盖场景、器械行为、故障表现、后果、厂商调查等要素，是构建器械安全事件抽取与故障归因模型的理想语料。

许可友好：CC0 公有领域，可商用，这在医疗文本资源中极为罕见（多数临床文本受 HIPAA 与机构 IRB 约束）。

已有实践：牙种植体上颌窦相关事件的回顾性文本挖掘（BMC Oral Health 2026）就是范例——研究者用 DZE 产品码筛出 338 万余条器械记录，再对 FOITEXT 做症状关键词匹配与叙述分析。

挑战：

• 文本质量参差，常简短、不完整、表述不清。
• FOIA 脱敏标记 (b)(4)/(b)(6) 打断语义连续性。
• 同一事件的多条报告文本需要去重合并。
• 叙述风格随报告者类型剧烈变化（制造商措辞 vs 临床描述）。

一句话：MAUDE 的叙述轨是医疗 NLP 的高价值-高噪声语料，适合做领域适配与事件抽取研究，但不适合直接用现成通用模型零样本处理。

12.4 切面四：MAUDE 与器械全生命周期

在 FDA 的器械监管数据生态中，MAUDE 处于上市后监测的枢纽位置，与其它数据库构成完整链条：

阶段	数据库	作用
上市前	510(k)（约 176,000 条）	实质等同性许可
上市前	PMA（约 57,066 条）	高风险器械上市前批准
上市前	device/classification（约 7,091 条）	器械分类与产品码
上市后	MAUDE（device/event）	不良事件报告
上市后	device/recall（约 59,129 条）	召回事件
上市后	device/enforcement（约 39,885 条）	执法行动
上市后	device/udi（约 5,182,695 条）	唯一器械标识
上市后	device/registrationlisting（约 334,839 条）	注册与列名

（其余端点记录数见 openFDA 状态页；上述数字来自库内 openfda 条目已核验的 2026-08~09 时点口径。）

TPLC（Total Product Life Cycle） 界面把上述数据整合到统一检索中，是器械竞争情报与全生命周期风险分析的高效入口。

典型分析链：某产品码 MAUDE 报告聚集 → 关联 device/recall 看是否触发召回 → 关联 510(k)/PMA 看器械代际 → 关联 UDI 定位具体型号批次。

12.5 切面五：数字背后的制度史

MAUDE 的数字规模不是凭空增长的，它映射了美国器械监管三十余年的制度演进：

• 1984–1996：DEN（Device Experience Network）系统收录早期器械经验报告，为 MAUDE 前身。
• 1991：使用机构报告义务生效，MAUDE 报告类开始累积。
• 1993：自愿报告（6 月）与分销商报告通道开启。
• 1996-08：制造商强制报告通道生效——这是报告量跃升的关键节点，因为制造商是三类强制报告主体中覆盖面最广的一类。
• 1999：MAUDE 数据库对公众开放，“available in MAUDE Database since 1999”。
• 1999–2019-04：ASR（Alternative Summary Reporting）并行运行，允许某些器械以汇总方式报告，这批数据后被单独发布。
• 2014-06-02：openFDA API 上线，MAUDE 数据从"人工下载"进入"程序化访问"时代。
• 2022-10-20：UDI-DI 与 UDI-Public 字段加入，报告与器械型号的锚定更精确。
• 2026：数据迁入 AEMS，进入跨产品、近实时的新阶段。

读法：分析 MAUDE 的长期趋势时，必须把这些制度节点作为潜在的结构断点（structural break）——1996、1999、2014、2026 都可能在时间序列上留下台阶状变化，而非真实的风险变化。

12.6 切面六：AI 器械时代的结构性缺口

这是本条目最具前瞻性的一节。

缺口的技术成因。 MAUDE 的报告触发条件是"死亡/严重伤害/故障若复现可能致害"。而 AI 赋能器械的典型失效模式——概念漂移（concept drift，数据分布随时间变化导致模型退化） 与 协变量偏移（covariate shift，输入分布偏移）——是渐进的性能退化，不构成"器械故障"事件，因而不满足 MDR 报告触发条件。AI 模型不会像机械部件那样"突然坏掉"，它只会安静地变得不准。

缺口的结构成因。 MAUDE 是案例级（case-by-case） 的：它记录一个个独立事件。但 AI 性能问题往往只有在大规模聚合使用中才可见——单个患者的一次误判可能看起来只是"临床判断差异"，只有当数千次使用的准确率整体下降时才暴露为系统问题。案例级结构天然不适合捕捉这类聚合信号。

缺口的规模度量。 截至 2025-08-20，FDA 的 AI 赋能医疗器械清单已收录 1,247 件（2023 年底为 864 件）。增长最快的器械类别，恰是现有被动报告体系最不擅捕捉的类别。

可能的补足方向（学界与监管讨论中）：

1. 真实世界性能（RWP）监测：对 AI 器械做持续的性能追踪，而非等待事件报告。
2. 主动监测机制：借哨兵系统式的分布式数据查询，聚合层面的性能偏移。
3. 报告标准的扩展：在 MDR 框架中为 AI 特有失效模式（漂移、偏移、置信度退化）建立新的报告触发与编码。
4. 跨源数据融合：把 MAUDE 的案例级事件与器械注册、使用日志、模型监控数据结合。

对 AI-Ready 资产的意义：MAUDE 恰好展示了"数据集的边界由制度定义"这一深层命题——它记录什么、不记录什么，不取决于技术可能，而取决于法律规则如何定义什么是’应报告的事件’。AI 时代需要重新回答这个问题。

12.7 延伸：与 FAERS 的对照读法

既然库内已有 FAERS（rid=264），把两条被动监测体系并读能榨出额外的洞见：

维度	MAUDE（器械）	FAERS（药品）
报告主体	制造商/进口商/使用机构/自愿	制造商/自愿
触发阈值	死亡/严重伤害/可致害故障	严重不良事件/非预期
强制主体差异	有"使用机构"强制通道（医院必须报）	无对应强制通道
时限	制造商 30 日、机构 10 工作日	制造商 15 日（严重）
语料性质	器械-人交互事件叙述	药物-人反应叙述
编码体系	器械问题码 + 患者问题码	MedDRA 术语 + 反应码

关键差异：MAUDE 独有的使用机构强制报告通道，意味着器械事件中临床第一手叙述的比例更高；而 FAERS 更多依赖制造商与自愿报告。这使两个库在"叙述质量"与"选择偏差"上呈现不同的画像——同样的被动监测方法论，落在不同制度上会产生不同形状的数据。这是库内互链最富学术价值的一条对照线。

---

§13 附录：快速上手清单

13.1 五步上手（给新用户）

第一步：明确问题类型。

• 想知道"某器械出过什么事" → 走网页检索或 API 按品牌名/产品码查。
• 想做统计/趋势 → 走 API 或全量下载。
• 想做文本挖掘 → 走全量下载 FOITEXT。

第二步：确定产品码。
在 FDA 产品分类数据库查目标器械的三字母产品码（比品牌名可靠得多）。

第三步：选择获取路径。

• 近 10 年、结果 < 500 条 → 网页检索。
• 需要程序化/聚合 → openFDA API（注意分页上限 25,000，需按日期切窗）。
• 需要历史全量/文本 → MDR Data Files 下载。

第四步：处理数据。
拼接 6 类文件（MDR_REPORT_KEY），按需去重，过滤脱敏标记。

第五步：遵守三条铁律。
不建立因果、不计算发生率、不把报告稀少读成安全。

13.2 常见任务速查表

我要做的事	用什么	注意事项
查某器械某品牌的历史报告	网页检索	仅近 10 年，上限 500 条
统计某产品码的事件类型分布	openFDA API count	编码是索引非诊断
下载全量做 NLP	MDR Data Files	pipe-delimited，需清洗
做长期趋势	API 或全量下载	注意制度断点（1996/1999/2014/2026）
跨器械比较风险	不建议	无分母，官方明示不可比较
关联召回事件	TPLC 或 device/recall	报告聚集 → 召回的链条
定位具体型号	UDI-DI 字段	并非所有 MDR 都含 UDI

13.3 术语对照表（中英）

中文	英文/缩写
医疗器械报告	Medical Device Report (MDR)
制造商与使用机构器械经验	Manufacturer and User Facility Device Experience (MAUDE)
报告主键	MDR_REPORT_KEY
事件类型	EVENT_TYPE
死亡	Death (D)
伤害	Injury (IN)
故障	Malfunction (M)
使用机构	Device User Facility
产品码	Product Code
唯一器械标识	Unique Device Identification (UDI)
叙述文本	FOI_TEXT（Freedom of Information Text）
替代汇总报告	Alternative Summary Reporting (ASR)
器械经验网络	Device Experience Network (DEN)
不良事件监测系统	Adverse Event Monitoring System (AEMS)
全球医疗器械命名法	Global Medical Device Nomenclature (GMDN)
被动监测	Passive Surveillance
上市后监测	Postmarket Surveillance (PMS)
信号检测	Signal Detection
报告比值比	Reporting Odds Ratio (ROR)
比例报告比	Proportional Reporting Ratio (PRR)
概念漂移	Concept Drift

---

条目维护记录：

• 2026-10-16：首版成稿。核验来源为 FDA openFDA device/event 端点页、openFDA MAUDE 数据页、openFDA 许可页、FDA MDR Data Files 页、FDA MAUDE 检索界面、PMC5994953 方法学论文。硬数字采用 2026-09-08（API）与 through 2025（下载）双时点并存口径。
• 遗留待核：任务书所述"7 张关联表"结构与官方 6 类口径的差异（见 §2.2、§9.1）；AEMS 迁移的完整数据口径与旧链接的兼容性。

§14 深度专题：八个值得单独展开的问题

14.1 专题一：为什么 MAUDE 的"死亡"报告不能直接当死亡数读

MAUDE 的 EVENT_TYPE = D（Death）字段看似直白，实则充满解释陷阱：

• 报告的是"疑似关联"的死亡，不是"器械致死的死亡"。FDA 官方明示因果无法建立。一条标记为死亡的报告，可能仅是"患者死亡时正在使用该器械"。
• 归因偏差在叙述中普遍存在。行业分析举过一个典型例子：一位患者从轮椅上摔落死亡，被归入"死亡"类，但实际上被归因于患者自身虚弱，而非轮椅。若仅按 EVENT_TYPE 统计，这类记录会被计入"轮椅致死"。
• 同一死亡事件可产生多条记录。若使用机构、制造商、自愿者各报一次，Master Event 里就有多条 EVENT_TYPE = D 记录。不去重会使死亡数虚高数倍。

正确做法：统计死亡报告时，（1）明确声明这是"疑似关联的死亡报告数"而非死亡数；（2）按事件去重；（3）对关键结论抽样阅读 FOI_TEXT 核实归因。

14.2 专题二：器械问题码体系的复杂度

MAUDE 的器械问题码（Device Problem Code）是一个庞大而精细的受控词表，映射到 MedWatch 3500 表的 F10 与 H6 节。它的复杂度体现在三个层面：

一是码的粒度。从"材料降解"“电池问题”“软件错误"到"标签问题”“灭菌问题”，覆盖器械失效的几乎所有可想象维度。研究者做风险画像时，码的粒度决定了分析的细度。

二是码的多值性。一个报告可关联多个器械问题码（Device Problem 文件与 Master Event 是一对多关系），因为一次事件可能涉及多个问题。

三是码的填报主观性。与事件类型一样，问题码由填报者选择，未必经工程裁决。同一现象（如"泵停止工作"）可能被不同填报者归入不同的码。

与 Product Problem 的区别：MAUDE 有"产品问题（product problem）“与"器械问题（device problem）“的相关概念，前者更偏"产品缺陷”，后者更偏"使用中出现的故障现象”。检索时注意区分字段。

14.3 专题三：UDI 如何改变 MAUDE 的分析精度

UDI（Unique Device Identification，唯一器械标识） 是器械监管的一次结构性升级。在 UDI 之前，MAUDE 报告的器械只能靠品牌名、型号、目录号等非标准标识锚定——而这些字段拼写不一致、格式自由，是检索与分析的老大难。

UDI-DI（Device Identifier） 把报告精确锚定到具体器械型号。2022-10-20，openFDA 的 UDI 端点新增了 UDI-DI 与 UDI-Public 两个字段：

• UDI-DI：器械标识符。
• UDI-Public：MDR 报告中所提供标识的脱敏版本。

但必须注意两个限制（官方明示）：（1）并非所有 MDR 都提供 UDI 数据——覆盖率不完整；（2）当前 UDI 数据未经校验。因此 UDI 提升了精度上限，但不能假设每条记录都可用 UDI 锚定。

分析意义：做器械型号级分析时，优先用 UDI-DI 匹配的设备；对无 UDI 的历史记录，仍需回退到品牌名+型号的模糊匹配。

14.4 专题四：ASR 与 DEN——被遗忘的两批数据

MAUDE 并非 FDA 唯一的器械事件数据源。两批并行数据常被研究者忽略：

ASR（Alternative Summary Reporting，替代汇总报告，1999–2019-04）：某些器械被授权以汇总方式报告不良事件，而非逐事件提交 MDR。这批数据在 MAUDE 主库中长期不显形，后被单独发布在 MDR Data Files 页。分析含义：若某项研究只取 MAUDE 主库，可能系统性遗漏这批以汇总方式报告的事件——尤其影响特定类别的器械（历史上曾有对某些器械使用 ASR 的争议）。

DEN（Device Experience Network，1984–1996）：MAUDE 之前的遗留系统，收录 1984–1996 的器械经验报告，现于 MDR Data Files 页提供。分析含义：做 1990 年代器械安全的长期回溯研究时，必须把 DEN 纳入，否则会在时间序列前段出现"数据真空"。

实践建议：做历史跨度大或特定器械类别的分析前，先确认该器械是否可能落入 ASR/DEN 的范围，并把这批数据并入。

14.5 专题五：为什么"信号检测"在器械域比药品域更难

器械警戒可迁移药物警戒的信号检测方法（ROR/PRR、IC/MGPS），但器械域有额外的困难：

困难一：器械异质性远高于药物。 一款药物有明确的活性成分与规格；而"器械"从纱布到起搏器，同一产品码下的器械在设计与风险上可能差异悬殊。这使得"同类聚合"比药物域困难。

困难二：报告触发条件的宽窄不一。 器械的"故障若复现可能致害"这一触发条件，其解释空间大于药品的"严重不良事件"，导致器械报告的纳入门槛更模糊。

困难三：使用者在回路中。 器械事件高度依赖使用者操作（用户错误 vs 器械失效的区分），而药物反应更多是生理性的。使用者在回路中使归因更复杂。

困难四：无分母问题在器械域更尖锐。 药品尚可通过处方量估算暴露；器械的在用数量极难获取（尤其非植入、非注册类器械），分母缺失更严重。

实践含义：器械域的信号检测应更保守——阳性信号更应被视为"值得进一步调查的线索"，而非可直接行动的结论。

14.6 专题六：MAUDE 数据的可复现性陷阱

做 MAUDE 研究时，一个常被忽略的问题是可复现性：同一个检索意图，不同时间、不同路径可能得到不同结果。

陷阱一：数据在滚动更新。 MAUDE 每月更新、openFDA 每周更新、AEMS 迁入后每日更新。今天跑的数与三个月后跑的数必然不同。对策：论文中必须记录检索日期与数据版本（如"MDR Data Files through 2025"或"openFDA 快照 2026-09-08"）。

陷阱二：检索路径影响结果。 网页检索（近 10 年、上限 500）、API（2009 起、分页上限）、全量下载（各报告类起始年份）三路的覆盖范围不同，同一关键词会得到不同结果集。对策：明确声明所用路径。

陷阱三：品牌名匹配的不稳定。 用品牌名检索时，拼写变体、公司更名、产品退市都会影响召回。对策：优先用产品码；用品牌名时必须列出所有变体并说明。

陷阱四：去重规则不透明。 是否去重、如何定义"同一事件"，会显著影响计数。对策：明确写出去重规则与所用键。

一句话：MAUDE 研究的方法学章节，应至少包含"检索日期 + 数据版本 + 获取路径 + 检索词/产品码 + 去重规则"五要素。

14.7 专题七：MAUDE 在器械开发流程中的实际用法

器械开发团队（据行业实践）如何用 MAUDE：

阶段一：概念与需求。 查同类器械（同产品码）的历史事件，识别高发问题——“这类器械最常在哪失效”。用于风险需求定义。

阶段二：设计与可用性。 读叙述文本，理解用户错误发生的场景——哪些误操作反复出现。用于可用性工程与说明书设计。

阶段三：风险管理。 把 MAUDE 事件模式纳入 FMEA（失效模式与影响分析）与 ISO 14971 风险管理文件。

阶段四：上市后监测计划。 把 MAUDE 检索纳入 PMS 计划，设定检索频率（高风险/新上市器械月度或季度，成熟低风险器械半年度）。

最佳实践（据行业综述）：检索自己的器械、等同器械与竞品器械；按产品码而非品牌名检索；每次检索记录日期、参数、结果数、筛选标准与结论。

与 AI 器械开发的张力：由于 MAUDE 无法捕捉 AI 特有失效模式，AI 器械开发团队不能仅依赖 MAUDE 做风险管理，需补充真实世界性能监测。

14.8 专题八：MAUDE 对中国器械警戒的参照意义

（此节为比较制度视角，不做政策建议。）

美国 MAUDE 是全球最早、最成熟的公开器械不良事件库之一。其他体系（如中国的国家医疗器械不良事件监测信息系统、欧盟的 EUDAMED）在设计上均面临类似的核心问题：

1. 报告门槛如何设定（哪些事件必须报）；
2. 谁承担强制报告义务（是否含使用机构）；
3. 数据如何向公众开放（全量下载 vs 仅统计摘要）；
4. 隐私与商业机密的脱敏边界（FOIA 式的豁免如何平衡）。

MAUDE 的经验展示了一个强开放的选择——全量原始记录公开下载（脱敏后）、CC0 许可、API 程序化访问。这一选择极大降低了二次研究门槛，使 MAUDE 成为全球器械警戒研究的事实数据源，也使其数据质量问题被充分暴露与讨论。

可迁移的启示：数据开放程度与数据质量改进之间存在正反馈——越多人使用 MAUDE，其局限越被显性化，越推动方法学与制度改进。

---

§15 一页速记卡

MAUDE 速记卡

是什么：FDA 依 21 CFR 803 建的器械不良事件（MDR）报告库。
谁报：制造商 / 进口商 / 使用机构（强制）+ 自愿者。
多大：逾 2,300 万条；openFDA 端点 26,136,889 条（2026-09-08）。
多老：使用机构 1991 起；库公开 1999 起。
怎么拿：网页（近 10 年）、API（2009 起，每周）、全量下载（每月）、第三方索引。
什么结构：6 类关联文件 / 135 字段 / MDR_REPORT_KEY 关联。
什么许可：CC0 公有领域可商用；GMDN 术语例外。
三条红线：不建立因果、不算发生率、不把报告稀少读成安全。
三个必查：产品码（非品牌名）、报告来源码、叙述文本。
一个变局：2026 迁入 AEMS。
一个盲区：AI 器械失效模式（漂移/偏移）不被记录。

---

§16 常见误解澄清

误解 1：“MAUDE 报告多，说明这个器械最危险。”
错。无分母，报告多可能只是因为使用人数多或报告文化强。FDA 官方明示不能据此比较器械风险。

误解 2：“MAUDE 里没有某器械的报告，说明它很安全。”
错。更可能是漏报。被动系统的"安静"是漏报的证据，不是安全的证据。

误解 3：“MAUDE 和 FAERS 是一个库的两个名字。”
错。器械走 MAUDE，药品走 FAERS，疫苗走 VAERS，是三个独立体系。

误解 4：“MAUDE 是结构化数据库，可以直接拿来跑模型。”
部分错。它是 6 类文件拼装 + 自由文本混合的半结构化数据，需大量清洗工程。

误解 5：“MAUDE 数据是 FDA 认证过的。”
错。FDA 官方明示报告未经广泛验证或核查，“假设所有结果未经校验”。

误解 6：“事件描述就是客观事实记录。”
错。它是"某人说发生了什么"，是报告者的叙述，可能不完整、不准确或有偏见。

误解 7：“用 MAUDE 就能做出 AI 器械的安全结论。”
错。MAUDE 无法捕获 AI 特有失效模式，AI 器械安全需补充真实世界性能监测。

误解 8：“网页检索能查到所有历史报告。”
错。网页检索仅覆盖近 10 年，且上限 500 条。历史与全量必须走下载或 API。

误解 9：“MAUDE 数据有版权，不能商用。”
错。CC0 公有领域，可商用。但 GMDN 术语内容例外，需单独授权。

误解 10：“报告日期就是事件发生日期。”
错。DATE_OF_EVENT（事件发生）与 DATE_REPORT/DATE_RECEIVED（报告提交/接收）可能相差数月甚至数年，且事件日期常缺失。

---

§17 结语：一份由制度定义的资产

MAUDE 最耐人寻味之处，不在于它有多大，而在于它记录什么、不记录什么，完全由制度定义。

它记录"达到死亡/严重伤害/可致害故障阈值"的事件——阈值由 21 CFR 803 划定。它记录"谁在什么时限内必须报"——时限由报告主体类型决定。它不记录轻微异常、不记录 near miss、不记录"刚刚好没出事"的惊险瞬间。它也（目前）不记录 AI 模型的渐进退化——因为制度尚未把它定义为"应报告的事件"。

正因如此，MAUDE 既是一份珍贵的数据资产，也是一面照见制度边界的镜子。对 AI-Ready 时代的使用者而言，理解 MAUDE，不只是学会用一个数据库，更是理解"数据从来不是自然生成的，而是被制度生产出来的"这一深层命题。

每一次在 MAUDE 上的检索，都是在与三十六年的器械监管史对话——那些报告背后，是真实的器械、真实的事件、真实的人。

---

相关数据集导航

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

• eudravigilance — 共享标签：真实世界数据 / 药物安全 / 医疗登记
• aact — 共享标签：真实世界数据 / 医疗登记
• trinetx — 共享标签：真实世界数据 / 药物安全
• openfda — 共享标签：真实世界数据 / 药物安全
• fda-sentinel — 共享标签：真实世界数据 / 药物安全
• usda-fooddata-central — 共享标签：真实世界数据 / 公共卫生统计
• opensafely — 共享标签：真实世界数据 / 医疗登记
• cprd — 共享标签：真实世界数据 / 药物安全
• twosides — 共享标签：真实世界数据 / 药物安全
• faers — 共享标签：真实世界数据 / 药物安全

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