GARD 罕见病信息中心 — 面向患者的口语化疾病名录

六千二百六十五条疾病页 / 一万六千余条名录 / 一份 CSV 就是全部批量口径

来源 https://rarediseases.info.nih.gov/发布时间: 2026-10-29最后更新: 2026-10-29 阅读 11

信息速览

数据集名称GARD 罕见病信息中心 — 面向患者的口语化疾病名录
数据类型知识图谱,元数据,生物医学文献
规模不适用（以疾病条目计：名录一万六千二百一十四条，有详情页六千二百六十五条）
接入方式https://rarediseases.info.nih.gov/
AI 就绪度

GARD 是「Genetic and Rare Diseases Information Center」的缩写，中文多译作遗传与罕见病信息中心。它是美国依据 2002 年《罕见病法案》设立的公共信息项目，由国立卫生研究院下属的国家转化科学促进中心（NCATS）管理，国家人类基因组研究所（NHGRI）出资，成立于 2002 年。它做的事情可以用一句话概括：把 Orphanet、OMIM、MONDO、HPO、MedGen 与 MedlinePlus 里写给医生和研究者看的疾病描述，改写成患者与家属能一屏读完的通俗页面，再配上患者组织名录与临床试验入口。

它与一般意义的疾病数据库不同。它不生产原始知识，上游的每一个事实都能在别处找到；它生产的是「可读性」——同一个病，在 OMIM 里是十几页带文献引用的专业综述，在这里是一段能读给家属听的概述加一张症状清单。代价是精确度的损失：基因只给符号不给位点，患病率只给带条件的量级描述，文献引用被折叠进页脚的统一说明。因此把它当作命名归一与科普问答的语料是合适的，把它当作遗传学证据链的一环则不成立。

与它同场出现的还有 Orphanet 与 OMIM，三者的分工值得先说清楚：Orphanet 偏欧洲的临床分类与孤儿药，条目带孤儿药适应症与专家中心；OMIM 偏基因与表型的对应关系，条目由专人撰写并附完整文献；GARD 偏美国官方的患者教育口吻，条目以「怎么找医生、去哪找组织、有什么研究」收尾。下面的速览表把规模与口径先摆出来，再逐层拆。一屏速览见下表。

维度 内容
全称 Genetic and Rare Diseases Information Center
运营方 NCATS（NIH），NHGRI 出资
设立依据 2002 年《罕见病法案》
上游来源 Orphanet、OMIM、MONDO、HPO、MedGen、MedlinePlus
名录条目 16,214 条
有详情页 6,265 条
详情页栏目 概述、病因、遗传方式、发病年龄、症状、患者组织、临床研究
症状术语 统一映射到 HPO
疾病身份 以 MONDO 为骨架
语言 英文为权威版本，西班牙文仅 356 条
批量导出 一份四列 CSV
检索方式 按名称、缩写、同义词、分类标签
分类体系 12 个大类
明确不含 诊疗建议、病例、基因变异、剂量、预后

§1 它要解决的具体麻烦

1.1 确诊之后，家属拿到的是十几页文献而不是一段话

罕见病的确诊往往耗时以年计，官方口径给的平均数字是六年以上。确诊那一刻，患者与家属通常得到三样东西：一个写满缩写的诊断名、一叠检验报告、以及一句「这个病很少见，你可以上网查查」。问题恰恰在这里——能查到的资料都是写给专业人员的。OMIM 的条目按基因分段，每一段后面跟着几十条文献编号；Orphanet 的条目按临床特征与流行病学分层，字段密度高但句子上不加解释；综述文章需要订阅，且默认看的人熟悉通路与蛋白名。

换句话说，罕见病信息的问题从来不是「查不到」，而是「查到了读不懂」。GARD 的切入点正是这一层：它不追求比上游更全或更准，它追求同一件事被说成一句普通话。关于页把这件事写得很直白——把写给临床医生与研究者看的科学语言，翻译成能拿去和医生沟通的通俗信息。

这也决定了它的产出形态。别的资源在条目内部追求字段的完整性，它在条目内部追求段落的可读性。同一句话在 OMIM 里可能是一句「p.Gln18dup 导致蛋白聚集」，在 GARD 里是「基因的某处改变使身体产生的蛋白质出了问题」。后者对科研无用，对刚拿到诊断的家庭则是能读懂的第一句话。

1.2 三条常见的错误期待

常见期待 实际情况
以为它是一个可以整库下载的疾病数据库 批量文件只有一份四列名录，正文段落不随文件提供
以为它比 Orphanet 或 OMIM 更权威 它的信息全部来自这两家加 MONDO，是二手改写
以为它有基因位点与变异层面的内容 基因只列符号，没有位点、没有致病性判定、没有频率

1.3 它能给到的与给不到的

你的需求 它给的 够不够
一份罕见病的规范名称与别名清单 名录 CSV 四列，含正名与同义词串 够，这是它最实用的部分
某个病的通俗概述段落 详情页开头一段概述 够做科普素材，不够做临床判断
某个病的症状清单 HPO 术语加常见/少见两档 够做表型检索，不够做鉴别诊断
某个病的遗传方式 一句话模式说明加教育性解释 够理解，不够做遗传咨询
某个病有哪些患者组织 按国家列出的组织名录 够找社群，不保证覆盖
某个病有哪些在研试验 指向 ClinicalTrials.gov 的检索入口 是跳转，不是本地数据
基因层面的变异与致病性 无 不够，须回 OMIM 或 ClinVar
患病率与流行病学的分层估计 只有带条件的量级描述 不够，须回 Orphanet
可直接训练的成品语料 无，需自行抓取并清理 不够

1.4 你的处境与它能帮到的事

你的处境 它能帮你什么 下一步该做什么
刚拿到罕见病诊断，想先弄懂病名 详情页的概述一段，配同义词帮确认叫法 用同义词回查病历里的别名，再找遗传科
做罕见病命名归一，缺一份别名表 名录 CSV 的同义词串，一万三千余条带别名 按竖线切分后清洗前导空格，再与 MONDO 对齐
做面向公众的罕见病问答模型 详情页的通俗段落是最接近口语的官方表述 逐页取正文，注意条款，自行脱敏
找某个病的患者社群 详情页的患者组织名录，含服务对象与国家 直接联系组织，核对其自述的服务范围
需要做基因型与表型的关联分析 无基因位点与变异字段 转向 OMIM、ClinVar 或 Orphanet
需要各国患病率做卫生经济学测算 只有量级描述，无分层估计 转向 Orphanet 的流行病学字段

1.5 一句话判断

如果你要的是一份「能让家属读懂、让模型学会通俗表述」的罕见病名录，GARD 是少数几个由官方维护、可自由取用的选项；如果你要的是可以进证据链的遗传学事实，它给不了，也不打算给。

1.6 不适合谁：四条边界

第一，不适合需要基因变异级数据的人。GARD 的详情页在病因一节只做两件事：说明这个病是基因改变引起的、列出已知基因的符号。位点、变异类型、致病性分级、人群频率一概没有。想回答「哪个错义变异导致这个表型」，必须回 OMIM 或 ClinVar。

第二，不适合需要流行病学分层的人。关于页写明数据里含「患病率与人群估计」，但落到页面上是「很罕见」「在某些人群更常见」这类量级表述，而不是按国家、按年龄、按性别的分层数字。要拿来做卫生经济学测算，这套口径远远不够。

第三，不适合需要个体化诊疗建议的人。站内每页都带免责声明，明确说所提供信息不能替代医生的判断。它不给剂量、不给方案对比、不给预后判断。任何从它的段落里推出来的治疗结论，都不是它提供的。

第四，不适合需要可复现接口的人。它没有 API 文档，没有版本化数据包，批量文件只有一份按月刷新、文件名带月份的四列名录。想做可复现的批次处理，必须自己记录下载日期与文件哈希，并在上游变动时重新对齐。

§2 数据构成与规格

2.1 三层产物：名录、索引、详情页

GARD 的公开产物分三层，层次之间的定位差别很大，混在一起谈容易出错。

第一层是名录。这是唯一可以整份下载的东西，一份 CSV，四列：GARD 编号、正名、同义词串、详情页地址。编号形如 GARD:0021052，由前缀加七位数字组成。正名是英文的规范写法，同一疾病只用一种写法。同义词串用竖线分隔，多的能到几十个。详情页地址一列，有页面的写完整网址，没页面的留空。

第二层是索引。详情页的列表页与搜索框依赖一份 JSON 资产文件，内容是每个有页面的疾病的编号、正名、页面路径别名、同义词数组，以及三组标签：疾病大类、关注领域、接诊科室。这份文件不出现在任何下载说明里，是从页面资源里读到的，但它比 CSV 更有结构，因为它把同义词拆成了数组，也带上了分类。

第三层是详情页。这是内容的主战场，每个页面固定七个栏目，加上一组面向专业人员的跳转链接。正文不提供批量下载，也没有独立的数据文件，只能逐页取。

2.2 名录的字段字典

字段 示例 类型 说明
ID GARD:0021052 字符串 主键，前缀固定，七位数字不省略前导零
Display Name 10q22.3q23.3 microduplication syndrome 字符串 英文正名，同一疾病唯一
Synonyms `dup(10)(q22.3q23.3)\ trisomy 10q22.3q23.3` 字符串
URL https://rarediseases.info.nih.gov/?gard_id=0021052 字符串 有详情页才非空

四列里真正每天都用得到的是第一列与第三列。前者用来做稳定外键，后者用来做别名匹配。第二列看起来多余，实际是最容易出错的地方——它看起来和同义词首项重复，但并不总是重复，因为有些条目的正名与任何同义词都不一致。

2.3 索引的字段字典

字段 类型 含义 可否用于筛选
id 整数 详情页路径里的数字，与名录编号的数字部分对应 是，主键
name 字符串 英文正名 是，文本检索
encodedName 字符串 页面路径别名，去标点后连字符化 是，可直接拼 URL
synonyms 字符串数组 同义词，已拆分，但部分元素仍带前导空格 是，别名匹配
spanishId 整数 西班牙文页的数字编号，仅部分条目有 是，判断有无西语版
spanishName 字符串 西班牙文页路径别名 否
tagsDiseaseCategory 字符串数组 疾病大类，取值自 12 类词表 是，最常用的粗筛
tagsAccount 字符串数组 关注领域，取自更细的一组子类 是，做专项筛查
tagsSpecialist 字符串数组 接诊科室，用于推荐该找哪一科 是，做科室路由
tagsCause 字符串数组 病因归类 结构中保留，实际为空

这张表里最值得注意的是最后一行。索引里为病因留了一个标签字段，但在抓取到的全部条目里这个字段都没有取值。也就是说，「按病因筛选」这件事在数据层面是预留的，在内容层面尚未落实。任何依赖这个字段的筛选逻辑都会返回空集。

2.4 一条记录的完整解剖

取一个具体的病，它在名录与索引里的样子如下。左列取自名录，右列取自索引，两处描述的是同一条记录的两个侧面。

#-- 名录一行（四列）
GARD:0021052
10q22.3q23.3 microduplication syndrome
dup(10)(q22.3q23.3)|trisomy 10q22.3q23.3
https://rarediseases.info.nih.gov/?gard_id=0021052

#-- 索引一条（JSON 对象的近似形态）
id              : 21052
name            : "10q22.3q23.3 microduplication syndrome"
encodedName     : "10q223q233-microduplication-syndrome"
synonyms        : ["dup(10)(q22.3q23.3)", " trisomy 10q22.3q23.3"]
tagsDiseaseCategory : ["Genetics", "Congenital Abnormality"]
tagsAccount     : ["Chromosomal Anomaly"]
tagsSpecialist  : ["Genetics", "Pediatrics"]
tagsCause       : []

两处对照能看出三件事。其一，索引的 id 是整数，名录的编号是带前缀的字符串，两者靠数字部分对齐，21052 与 0021052 指向同一个病。其二，同义词在索引里已拆成数组，但第二个元素带前导空格，直接拿去匹配会失败。其三，索引里的 encodedName 去掉了小数点，10q22.3q23.3 变成 10q223q233，这是拼详情页地址时必须遵守的规则。

2.5 规模的三个数字

关于 GARD 有多大，官方页面给出的数字散落在两三处，口径并不完全一致，使用时必须分开说。

口径 数字 出处 性质
名录收录的疾病数 16,214 名录 CSV 行数 精确，可复算
有详情页的疾病数 6,265 列表页分页计数；CSV 中 URL 非空的行数 精确，两处一致
有西班牙文页的疾病数 356 索引中带西语编号的条目数 精确，可复算
疾病大类数 12 分类词表文件 精确
接诊科室标签数 34 索引标签去重 精确，可复算
全球罕见病估计总数 一万以上 关于页引用 估计值，非本库规模

最后一行需要在任何引用里点明：一万以上是全球罕见病的估计总数，不是 GARD 收录的疾病数。GARD 的名录事实上覆盖了这个量级的一半多一点，剩下的一半没有稳定身份，也就无从收录。这一点决定了它不能当作「罕见病全集」来用。

2.6 与同类资源的字段差异

同样是罕见病资源，不同库的字段侧重差别很大，选错会浪费大量时间。

维度 GARD Orphanet OMIM
定位 患者与家属的科普页 欧洲的临床分类与孤儿药 基因与表型的对应
编号体系 GARD 前缀加七位数字 ORPHAcode 六位 MIM 号，带四类前缀
疾病身份骨架 MONDO 自有本体，向 MONDO 映射 自有，向 MONDO 映射
症状术语 HPO，常见与少见两档 自有临床特征词表 自由文本描述
患病率 量级描述 分层估计，带地域 一般不给
基因 只给符号 给基因与部分变异 给基因、等位变异、分子机制
文献引用 折叠为统一说明 按条目给 逐段给编号
批量导出 一份四列名录 多类产品，含本体与映射 受限，需许可
语言 英文为主，西班牙文三百余条 多语种 英文

从这张表能看清一件事：GARD 的每一个字段，在上游都有更细的版本。它的增量不在字段，而在句子的可读性与栏目编排的面向对象。理解这一点，才不会为了要患病率而跑到 GARD 里空手而归。

§3 它的身份：谁的信息，对谁负责

3.1 三个名字，一个东西

GARD 有三个层面的名字。全称是「Genetic and Rare Diseases Information Center」，这是法案与预算文件里的正式称谓；简称 GARD 是所有人日常用的；在网址里它是 rarediseases.info.nih.gov 这个子域。中文语境里译名不统一，有译作「遗传与罕见病信息中心」的，也有直接音译保留缩写的。

需要说明的是，GARD 这个名字在美国语境里还有另一个常见所指——「Global Alliance against Respiratory Diseases」一类同名缩写。检索时必须以全称或站点域名为准，只搜四个字母会混入大量无关结果。

3.2 运营方的实际构成

关于页写得很清楚：GARD 由 NCATS 管理，NHGRI 参与出资。这两家的关系决定了它的气质——NCATS 的使命是「转化科学」，即把实验室与临床的发现变成可用的公共产品，因此 GARD 被定义为转化链条上的一环，而不是一个学术数据库。关于页自己也这么说：GARD 强调转化科学。

运营并不完全由联邦雇员完成。项目历史上长期以合同方式委托外部机构承担信息检索与内容运营，公开的合同记录显示承接方为一家位于弗吉尼亚州的咨询公司，联邦财政年度预算在数百万美元量级，其中绝大部分来自 NCATS，少部分来自 NHGRI。这意味着站点的日常产出是「按合同履约的内容加工」，而不是「研究人员自发维护的知识库」。

信息专员的设置是它区别于其他数据库的另一点。站内明确提供电话与表单两种求询方式，并给出二到十个工作日的答复预期。这一点很重要：GARD 从一开始就不只是一个网站，它是一个有真人接线的信息服务台。公开的项目说明里提到，累计答复的咨询量在十万条量级。

3.3 对谁负责：三种责任边界

责任对象 它承担的部分 它不承担的部分
患者与家属 把病名、症状、遗传方式说成人话 不做诊断、不给治疗方案、不做预后判断
上游数据方 如实转述 Orphanet、OMIM、MONDO 的事实 不承诺与上游同步，也不标注逐句出处
下游使用者 提供可自由取用的名录与页面 不提供接口、不提供版本化数据包、不承诺字段稳定

把这三条摆在一起看，能提炼出一条使用准则：把 GARD 当作「一份可以引用、可以抓取的患者教育文本」，不要当作「一个可以编程调用的知识接口」。它没有为后者做过设计。

3.4 坐标系的三根轴

GARD 建立的坐标系有三根轴：疾病轴、栏目轴、语言轴。

疾病轴由 GARD 编号定义。编号是七位数字，前缀固定，一经分配就跟着疾病走。但疾病身份本身由 MONDO 决定，一旦上游拆分或合并了某个疾病，GARD 这边要么改页面要么新增编号，旧编号可能失效。因此做长期追踪时，不能只记 GARD 编号，要同时记 MONDO 标识。

栏目轴由七个固定栏目定义。这七栏的顺序是稳定的：概述、病因、遗传方式、发病年龄、症状、患者组织、临床研究。任何两页之间可以按栏目对齐，这对批量抽取是好消息——抽取规则可以一次写好，全站复用。

语言轴由英文与西班牙文两条线定义。英文是权威版本，西班牙文是子集。两者不是逐句对应的翻译关系，而是各自成页，编号也不同。做多语对齐时，只能按疾病身份关联，不能按段落序号关联。

§4 它的手艺：如何把专业表述压成一段话

4.1 七栏的编排逻辑

GARD 的详情页栏目不是随意排的，它对应的是一个人拿到诊断后会依次提出的七个问题：这是什么、为什么是我、会不会传给孩子、什么时候开始的、有什么表现、有没有同类人、有没有办法参与研究。

第一栏是概述，一两句话把病说清楚，通常以「a rare … characterized by …」的句式开头。

第二栏是病因，分基因改变与染色体改变两条支路，选中哪条取决于上游标注。选基因支路时，页面会说明「这个病由下列已知基因的突变引起」，然后列出基因符号；选染色体支路时，说明是数目或结构改变。

第三栏是遗传方式，给出一个模式名，再配一段教育性解释。解释的写法高度模板化，例如常染色体显性一段会说明「患病者把变异传给子女的概率是百分之五十」。

第四栏是发病年龄，把年龄划成产前、新生儿、婴儿、儿童、青少年、成人、老年七档，用选中与未选中表示。

第五栏是症状，按常见与少见两档列 HPO 术语，可以逐个展开看同义词。

第六栏是患者组织，一张表，列出组织名称、服务对象、有用链接、所在国家。

第七栏是临床研究，本体不存试验记录，只解释什么是临床研究、为什么参与，并给出跳转到 ClinicalTrials.gov 的检索链接。

这七栏里，前五栏是「信息」，后两栏是「行动」。这个分工是它最不同于学术数据库的地方——学术库在第六、七栏的位置上通常给的是参考文献与相关条目。

4.2 症状条目如何落到 HPO

症状一栏是本库最有结构的部分，也是唯一能直接做计算的部分。每个症状是一个 HPO 术语，带一个通俗名与一个括号内的规范名。例如「Abnormally small skull」后面括号里是「(Microcephaly)」，「Cross-eyed」后面是「(Strabismus)」。

这种写法的好处是双轨的：对家属而言读的是前面的通俗名，对做匹配的团队而言取的是括号里的规范名。两轨并存意味着任何抽取都要明确取哪一轨——取通俗名会丢失本体对齐，取规范名会丢失可读性。

分档只有两档，这是需要注意的简化。HPO 注解里原本可以表达「非常常见、常见、偶见、罕见」四级频率，GARD 把它压成「常见」与「少见」两档，并用两段固定说明解释含义：常见是「很多人有，但不是所有人都有」，少见是「一些人会有，但多数人没有」。分档的思路对公众友好，对统计无用——两档之间没有可换算的比例。

4.3 发病年龄的七档切分

年龄一栏看起来简单，实际是全站最风格化的设计。七档的边界是固定的：产前指出生前，新生儿指出生到四周，婴儿指一个月到二十三个月，儿童指二到十一岁，青少年指十二到十八岁，成人指十九到六十五岁，老年指六十五岁以上。

每一档旁边写的是区间而不是标签，例如婴儿档旁边写「1-23 months」。这种写法避免了「儿童」这类词在不同语境下含义漂移的问题。但七档之间不重叠也不留缝，边界值归哪一档由站点自己定，跨库对齐时要注意别家的切法可能不同。

页面还会在档位表下方给一句汇总，例如「症状可能始于新生儿与婴儿期」。这句汇总不是表里选中项的机械拼接，而是按语言学规则重新组织的句子，说明后半段的生成是带规则而非纯模板。

4.4 案例：从名录的一行走到详情页的一段

用 GARD:0021052 走一遍，能看清三层产物是怎么串起来的。

第一步，在名录里定位这一行。四列里第三列给出两个同义词：dup(10)(q22.3q23.3) 与 trisomy 10q22.3q23.3。第四列给出地址，说明它有详情页。

第二步，用地址里的编号到索引里取结构。索引里这个病的 encodedName 是 10q223q233-microduplication-syndrome，去掉了小数点。大类标签是「Genetics」与「Congenital Abnormality」，接诊科室是「Genetics」与「Pediatrics」。

第三步才是读详情页。概述一句话说明这是一种罕见的染色体异常，特征是发育迟缓、轻度智力障碍与面部特征异常。病因一栏走的是染色体支路，说明是染色体数目或结构改变所致。症状一栏列出十来个 HPO 术语，含小头、眼距过近、前额宽、斜视。患者组织一栏列了五个组织，多数是泛罕见病组织而非本病专设。这个案例在后面的检索路径与使用指引里会被反复用到。

#-- 在本地名录里做一次同义词反查：给定病历里的别名，找 GARD 编号
import csv

def build_alias_index(path):
    idx = {}
    with open(path, encoding="utf-8-sig", newline="") as fh:
        for row in csv.DictReader(fh):
            gid = row["ID"]
            #-- 第四列非空才说明有详情页
            has_page = bool(row["URL"].strip())
            #-- 竖线切分后必须去掉前导空格，否则永远匹配不上
            for syn in row["Synonyms"].split("|"):
                syn = syn.strip().lower()
                if syn:
                    idx.setdefault(syn, []).append((gid, has_page))
    return idx

alias = build_alias_index("GARD_Rare_Disease_List_Sep2026.csv")
print(alias.get("wagr syndrome"))

这段代码里有一处必须强调：row["Synonyms"].split("|") 之后不加 strip()，得到的每一个别名都会带上原文的前置空格。名录 CSV 写成 a|b|c 时看起来没有空格，但索引 JSON 里 " trisomy 10q22.3q23.3" 是带空格的，两种来源混用时不加清洗就会出现「明明有却查不到」的情况。

4.5 通俗化改写的代价

把专业表述压成一段话，这件事有代价，而且代价是可枚举的。

第一是数量词的丢失。上游说「在每十万活产中约若干例」，改写后可能是「非常罕见」。前者能进模型做特征，后者只能进分类器做粗判。

第二是条件限定的丢失。上游说「在北欧人群中更常见」，改写后可能是「在某些人群更常见」。国别信息在改写中被抹掉，这在做地域差异分析时是致命的。

第三是分歧的丢失。同一个病，OMIM 与 Orphanet 对某一表型的描述可能不一致，改写时通常取其中一家或取交集，页面不会告诉你这里有分歧。要看到分歧，只能回上游逐条比对。

这三条代价不是失误，是设计的必然。它面向的人只有一类——需要一句话的人。要求它在保留全部限定条件的同时保持一句话，是不可能的。

§5 取数：从名录 CSV 到逐页抓取

5.1 四条取数路径的取舍

路径 适合的人 代价 边界
名录 CSV 做命名归一、做别名表的人 一次下载几 MB 只有四列，无正文
索引 JSON 需要分类标签与同义词数组的人 需从页面资源里找 非官方文档，字段可能变
网页逐页阅读 家属、医生、科普作者 人工成本 无法批量
逐页抓取 做语料的人 需自建队列与限速 须自行遵守条款

四条路径背后是同一批内容，区别只在「要结构」还是「要文本」。要结构，名录与索引足够；要文本，只能逐页取。

5.2 名录 CSV 的直接使用

名录是唯一有官方说明的批量文件。关于页在「包含哪些疾病」一段里给出下载链接，文件名带月份，最近一次读到的是 2026 年 9 月版。文件本身编码为带 BOM 的 UTF-8，四列表头为 ID、Display Name、Synonyms、URL。

#-- 第一步：下载并核对文件是否完整（列数应为 4）
curl -sL -o gard_list.csv "https://rarediseases.info.nih.gov/"

#-- 第二步：数行数。注意名称里可能有逗号，用 csv 解析而不是 wc -l
python3.11 -c "
import csv
rows = list(csv.DictReader(open('gard_list.csv', encoding='utf-8-sig')))
print('总条数', len(rows))
print('有详情页', sum(1 for r in rows if r['URL'].strip()))
"

第二行演示的坑值得单独说：名录的正名与同义词里含逗号与小括号，直接用行数统计会把带引号的多行字段算错。CSV 解析器能正确处理引号包裹，行数统计不能。

5.3 按分类做粗筛

如果只需要某一类罕见病，用索引里的疾病大类做筛选比逐页读正文高效得多。12 个大类里，遗传病与先天畸形覆盖最广，这两类本身就是 GARD 的主场。

#-- 按疾病大类筛选，并只保留有详情页的条目
import json

with open("diseases_trimmed.json", encoding="utf-8") as fh:
    diseases = json.load(fh)

def pick(category):
    return [d for d in diseases if category in d.get("tagsDiseaseCategory", [])]

for name in ("Genetics", "Congenital Abnormality", "Neurology"):
    print(name, len(pick(name)))

#-- 取出某一类的全部正名与同义词，直接喂给模糊匹配
target = pick("Neurology")
print(target[0]["name"], target[0]["synonyms"][:3])

这段用的大类是索引里的英文原值，不是中文译名。大类词表共 12 项，取值固定，改写就容易筛空。

5.4 详情页的定位规则

详情页没有稳定的编号路由。编号无法直接拼成地址，必须借助路径别名。规则是：正名小写，去掉标点，空格换成连字符。因此 10q22.3q23.3 microduplication syndrome 变成 10q223q233-microduplication-syndrome。

#-- 由索引条目拼出详情页地址，避免手工推导别名
import json, re

def slug(name):
    s = name.lower()
    s = re.sub(r"[^a-z0-9]+", "-", s)   #-- 非字母数字一律换连字符
    return s.strip("-")

with open("diseases_trimmed.json", encoding="utf-8") as fh:
    diseases = json.load(fh)

for d in diseases[:3]:
    assert slug(d["name"]) == d["encodedName"], (d["name"], d["encodedName"])
    print(f"https://rarediseases.info.nih.gov/diseases/{d['id']}/{d['encodedName']}")

这里有一个必做的断言。写法一旦出现例外，断言就会失败，失败的信息会直接告知名与别名不匹配。不写断言而直接拼地址，错误会以 404 的形式在几百页之后才暴露，排查成本高得多。

5.5 逐页抓取的纪律

批量取正文没有官方接口，只能按页面抓。真要这么做，有几条纪律必须守住，否则要么被封，要么拿到的是一堆空壳。

其一，页面正文是服务端渲染的，直接用 HTTP 取 HTML 就能看到内容，不需要执行前端脚本。这意味着用最基础的请求加上解析即可，不必上无头浏览器。

其二，必须有间隔。站点的内容量在数千页量级，全部取一遍对服务器不是压力，但密集并发会被限流。按每秒一页的节奏走，几千页在一小时量级内完成。

其三，必须有去重与断点。抓取中断是常态，脚本要能从中断处继续，而不是从头再来。用编号做进度文件是最简单可行的做法。

其四，必须记录时间。每一页底部都有一行「Last Updated」，标明该页最近一次修订的月份。做语料时把这个日期一起存下来，否则一年后无法判断两条内容是否同一时点。

5.6 与上游对齐

如果目标是做统一视图，GARD 必须与上游对齐，而不能自成一套。

对齐的第一步是疾病身份。GARD 编号不是跨库通用的，必须通过 MONDO 标识桥接。名录本身不带 MONDO 标识，这就要靠索引里的组别标签加正名做匹配，或用同义词做模糊匹配再人工核对。

对齐的第二步是症状术语。症状一栏已经落在 HPO 上，这一层可以直接对齐，不需要额外映射。这是 GARD 相对上游的一个便利：它把 Orphanet 的自有临床特征词表转成了 HPO，做本体联合查询时省一步。

对齐的第三步是基因符号。基因一栏只给符号，符号本身是跨库通用的，但版本会变。做长期项目时，基因符号应转换成稳定的基因标识再入库。

§6 与库内条目的关系

6.1 关系图谱

GARD 在库内的位置，可以用「原料、加工、出口」三层来理解。Orphanet 与 OMIM 是原料，MONDO 与 HPO 是缝合用的标准件，GARD 是把原料按患者视角重新组织后的出口，MedGen 与 MedlinePlus 是出口处的延伸阅读。

库内相关词条 与本词条的关系 一句话区隔
OMIM 直接上游 OMIM 给基因与表型的专业综述加文献，GARD 把其中一段改写成家属能读的话
Orphanet 直接上游 Orphanet 给欧洲的临床分类与孤儿药，GARD 取其中的名称、同义词与患病量级
MONDO 疾病身份的骨架 MONDO 定义疾病边界，GARD 按这个边界决定页面归属
HPO 症状术语的来源 HPO 提供四级频率与术语树，GARD 压成常见与少见两档
MedGen NCBI 侧的疾病概念库 MedGen 是概念与术语的汇总，GARD 是叙述性页面
ClinVar 变异层 ClinVar 给变异与致病性判定，GARD 只到基因符号这一层
罕见病相关表型资源 部分重叠 表型资源以术语树为中心，GARD 以疾病页为中心

这张表里最需要强调的一行是 OMIM。库内已有 OMIM 词条，两者极易被当成同一类东西，其实它们的产物形态完全不同：OMIM 的条目是给人读的综述，但面向的是专业人员，句子密度高、文献多；GARD 的条目也是给人读的，但面向的是家属，句子短、文献统一折叠。要引用「某个变异导致某个表型」，答案在 OMIM；要说「这个病是怎么回事」，GARD 更省力。

6.2 检索路径

你的问题 该去哪个词条或入口 理由
这个病的规范叫法与常见别名 本词条，名录 CSV 正名唯一，同义词一次给全
这个病的通俗概述 本词条，详情页首段 这是它为唯一目标写出来的段落
哪些患者组织在服务这个病 本词条，详情页患者组织栏 组织名录是本库独有的收尾栏目
这个病涉及哪些基因 OMIM 或 Orphanet GARD 只给符号，不给机制
某个变异是否致病 ClinVar GARD 没有变异层
各国的患病率估计 Orphanet GARD 只有量级描述
疾病的规范边界与同义关系 MONDO GARD 的边界是照抄 MONDO 的
症状的标准术语与频率分级 HPO GARD 已把频率压缩成两档

6.3 与 Orphanet、OMIM 的逐项区隔

库内已有 OMIM 词条，Orphanet 也在待办之列，三者经常被并列提起，因此差别必须逐项写清。

对比项 GARD Orphanet OMIM
一句话定位 患者与家属的科普页 欧洲的临床分类与孤儿药 基因与表型的专业综述
建立年份 2002 1997 1966
运营方 NCATS 与 NHGRI 法国 INSERM 协调的联合体 约翰霍普金斯大学
面向人群 患者与家属 临床医生与卫生政策 遗传学研究者
条目粒度 疾病 疾病、亚型、基因 基因、表型、等位变异
编号 GARD 前缀加七位数字 ORPHAcode 六位 MIM 号
患病率 量级描述 分层估计，按地域 多数不给
变异数据 无 部分 有，逐等位给出
孤儿药信息 无 有，按适应症 无
批量导出 一份四列名录 多类产品 受限
语言 英文加少量西班牙文 多语种 英文
引用方式 折叠为统一说明 按条目 逐段

一句话记住：GARD 把专业信息换成了可读性，Orphanet 把广度换成了标准化，OMIM 把可读性换成了精确度。三者的选择不冲突，常常是同一条链上的三站——用 GARD 入门，用 Orphanet 查分类，用 OMIM 查基因。§6.3 的分工在后面的选型建议里还会再用到。

§7 质量评估与局限性

7.0 阅读本节前的一个前置校正

评估 GARD 时最容易犯的误判，是拿评估学术数据库的尺子来量它：问它文献引用率多少、字段完整率多少、版本号有没有。这些维度上它必然低分，因为它从设计上就不承担这些工作。

正确的评估框架是：在「把上游的罕见病知识转成公众可读文本」这个任务上，它的改写是否准确、栏目编排是否有效、覆盖是否够广，以及这套改写换来了哪些不可逆的损失。下面每一处扣分都应理解为「它的取舍带来的代价」，而不是「它没做好」。把这一点校正过来，后面的评分才不会读歪。

7.1 五维评分

维度 分数 依据
覆盖广度 4 / 5 名录一万六千余条，几乎覆盖所有有稳定身份的罕见病；扣分在没有详情页的条目占近三分之二
可读性 5 / 5 面向家属改写是它唯一的核心竞争力，七栏编排对应七个实际问题
结构化程度 3 / 5 症状已落 HPO、分类标签齐备；扣分在无接口、无数据字典、病因标签为空
可追溯性 2 / 5 引用折叠为统一说明，不逐句给源；无版本号，只有月份
批量可用性 2 / 5 只有一份四列名录，正文需逐页取，无接口无许可细则

7.2 DAIMS 视角下的四条线

DAIMS 关注的是数据从采集到使用的链条是否可解释。按这四条线看 GARD：

DAIMS 线 GARD 的表现
数据获取与处理 上游来源在关于页公开列名，改写流程只有原则描述
数据建模 疾病页七栏固定，症状落 HPO，模型稳定但未文档化
数据溯源 只到「来自 Orphanet、OMIM 与 MONDO」这一层，不逐句标注
数据使用与治理 免责声明明确，批量使用条款缺失

四条线里最弱的是溯源。想知道某一句概述的原句在哪，页面上找不到线索。这一点对做学术引用是硬伤，对做科普素材影响不大。

7.3 已知的、可枚举的偏差

偏差不止一类，逐条列出比笼统说「数据有偏」有用得多。

第一，覆盖偏斜。名录收录一万六千余条，有详情页的六千余条。这个筛选标准是「已发表与已策展的信息是否充分」，因此被漏掉的主要是三类：极罕见、新近发现、以及文献分散在非英文期刊里的疾病。这直接导致冷门病在语料里更冷门。

第二，语言偏斜。西班牙文页只有三百余条，其余全部英文。对美国西语裔家庭，这意味着绝大多数病名只能用英文找。中文完全没有，这是做本地化时的起点条件。

第三，表述粒度偏斜。已成熟研究的病，页面写得长且分栏齐全；研究不足的病，页面可能只有一句概述加一条挂起提示。批量取正文时，这种长度差异会让分布严重右偏。

第四，组织名录偏斜。患者组织一栏按国家列，实际以美国组织为主。其他国家只有零星收录。用它做全球社群分布研究，会系统性低估非美国地区。

第五，术语简化的偏差。HPO 的频率分级被压成两档，稀有表型与常见表型之间的中间态消失。用它训练表型分类，学到的边界比真实边界更粗。

7.4 外部验证矩阵

验证角度 外部证据 结论
上游一致性 关于页列明 Orphanet、OMIM、MONDO 三家为来源 事实层可回上游核，叙述层不可
受众定位 关于页明确面向患者与家属，强调通俗 与「学术数据库」的误读可直接排除
运营稳定性 2002 年至今连续运营，预算来自单一联邦机构 停服风险低，但依赖单一出资方
语言覆盖 西语页数量远少于英文页 双语服务是有限的，不能假设全覆盖
数据形态 只有一份名录 CSV，无接口 批量使用能力弱，是设计而非疏漏

7.5 它为何能持续：把成本压在「改写」这一步

一个患者教育项目能不能活下来，取决于两件事：上游变动时它能不能跟上，以及下游是否有人持续需要它。GARD 在两点上都有结构性优势。

第一，它不做原创知识生产，只做改写。上游一变，它只需重跑抽取与改写，不需要重新组织研究议程。这使它的维护成本与上游规模而非与科学进展同步。

第二，它接住了「确诊之后」这个公共部门最该接、商业机构最不愿接的环节。患者组织名录与信息专员热线这两项，都不产生学术产出，却直接对应患者最急的需求。联邦预算为这类不产出论文的工作买单，逻辑上说得通，因此项目在二十多年里没有中断。

第三，它的产出形态极其轻。一份 CSV 加一堆静态页，托管成本可以忽略。这解释了为什么它到今天还是这套形态，而不是一个带接口的数据库——对它的目标用户来说，接口没有意义。

§8 生态位与历史

8.1 历史沿革

时间 事件
2002 年 依据《罕见病法案》设立，由 NHGRI 与罕见病研究办公室共同创建
2002 至 2016 年 累计答复咨询六万余条，平均每年数千条
2011 年 NCATS 成立，罕见病研究办公室并入，GARD 的归属随之转入 NCATS
2017 年 发表十五周年回顾，梳理求询者画像与满意度调查
2020 年前后 上线用于支撑策展的数据树结构，用计算方式做术语归一
2023 年 启动网站现代化，改为从 MedlinePlus、UMLS 与 MedGen 自动取数
2024 年至 2026 年 新版站点上线，页面结构改为七栏，名录按月刷新
2026 年 9 月 名录版本更新，疾病页最近一次修订

从这条时间线能读出两件事。其一是归属的稳定性：GARD 的运营方一直挂在「罕见病研究办公室」这条线上，该办公室从独立机构并入 NCATS 后，GARD 也随之归 NCATS，中间没有发生跨机构移交。其二是形态的转向：2023 年之后，站点从「人工撰写每一页」转向「批量抽取加统一改写」，关于页自己写明「网页是按批量方式填充的，而不是一页一页地写」。这个转向解释了为什么名录的条目数远大于详情页数——批量填充先解决有没有，再解决全不全。

8.2 与同代资源的错位竞争

同期出现的罕见病资源各有侧重。Orphanet 走的是标准化路线，建立自己的本体、编码与孤儿药清单，成为欧洲卫生政策的工具；OMIM 走的是学术路线，由专人撰写基因与表型的综述，成为遗传学的参考文献。GARD 走的是第三条路——公共信息路线，不建本体、不写综述，只负责把前两者的结论说成人话。

这三条路至今没有合并，原因不是技术，而是受众不同。Orphanet 的用户是临床医生与政策制定者，OMIM 的用户是研究者，GARD 的用户是拿着诊断书不知道下一步该问什么的家庭。受众不同，衡量成功的标准就不同：Orphanet 看编码覆盖率，OMIM 看文献完整性，GARD 看求询者能不能读懂。

8.3 在 AI 时代的再定位

罕见病信息在近两年重新受关注，原因不难理解：罕见病单个病种样本极少，正适合用知识驱动的方式补足数据驱动的不足；而面向患者的通俗表述，恰恰是大模型最容易学歪的部分——医学论文语料里没有这种写法。

GARD 的形态在这个背景下有一个明确的用途：它是少数由官方维护、可以用作「通俗医学表述」参照的语料。把它与 OMIM 的专业表述配对，可以构造「同义改写」的训练样本；把它与 HPO 的症状清单配对，可以构造「术语到俗名」的映射。

这也带来一种新的误用风险：把名录的上万条疾病名当作「罕见病全集」去训练分类器。实际上名录里近三分之二的条目没有详情页，只有名字；而名字本身来自上游，包含大量亚型、同义重复与已被合并的旧名。任何拿它当全集的工作，都必须先去重并与 MONDO 对齐。

8.4 与商业罕见病资源的互补关系

有一种看法是商业罕见病数据库终将取代公共项目，这个判断在可预见的范围内不成立。商业库的价值在于「深度、结构化、可对接」，公共项目的价值在于「免费、可引用、有官方背书」。前者回答「这个病的完整临床画像是什么」，后者回答「这个病叫什么、该去哪里」。

两者是上下游关系：用公共名录确定病名与别名，用商业库或上游专业库补齐深度。§7.5 提到的「成本压在改写这一步」正是这条链能长期运转的原因。

§9 使用指引

9.1 三种角色的路径

患者与家属的路径最短：直接在站内搜索病名或缩写，读到概述后，看症状一栏是否对得上自己的经历，再看患者组织一栏有没有可联系的组织。不需要下载任何文件。

做命名归一的团队的路径是数据先行：先拿名录 CSV 建别名索引，把每个别名映射到 GARD 编号，再通过 MONDO 桥接到其他库。要点是同义词必须清洗前导空格，且要保留原文以便回查。

做科普语料的团队的路径最重：需要逐页取正文，按七栏切分，并记录每页的修订月份。要点有三：一是限速与断点续传，二是把七栏当作固定结构而不是自由文本，三是在入库时把免责声明一并保留，避免后续误用。

9.2 一条最短的可用流程

下面这条流程从零到一个可用的科室路由表，是 §4.4 的案例在脚本上的完整版本。

#-- 第一步：确认名录与索引都能取到
curl -sI "https://rarediseases.info.nih.gov/diseases?page=1" | head -1

#-- 第二步：取名录（按关于页给出的链接下载，文件名带月份）
ls -lh gard_list.csv

#-- 第三步：取索引（详情页列表页引用的资源文件）
curl -s -o diseases_trimmed.json \
  "https://rarediseases.info.nih.gov/assets/diseases.trimmed.json"

#-- 第四步：把索引整理成「疾病 → 接诊科室」的路由表
import json, collections

with open("diseases_trimmed.json", encoding="utf-8") as fh:
    diseases = json.load(fh)

routes = collections.defaultdict(list)
for d in diseases:
    for spec in d.get("tagsSpecialist", []):
        routes[spec].append(d["id"])

#-- 只保留覆盖上百个病种的科室，避免长尾
main = {k: v for k, v in routes.items() if len(v) >= 100}
print(len(main), "个主要科室")
print(sorted(main, key=lambda k: -len(main[k]))[:5])

这段流程里每一步都有理由。先确认可达是为了避免在下载断流上浪费时间；名录取的是官方链接而不是自己拼，是因为文件名带月份，拼不出来；索引从资源文件取，是因为它比 CSV 多出三组标签；最后按覆盖数截断，是因为末端的科室每个只对应个位数的病种，做路由没有实际意义。

9.3 引用方式

引用要写到三层，缺一层都会让复现打折扣。

第一层是页面本身。写清访问日期与页面底部的修订月份，两者不是一回事：访问日期是你看到的时间，修订月份是内容的时间。

第二层是名录版本。名录文件名带月份，引用时抄全文件名，必要时附文件哈希。只写「GARD 名录」而不写月份，别人无法判断你用的是哪一批。

第三层是上游。如果结论涉及某个具体事实，应回 Orphanet 或 OMIM 找到对应条目再引一次。理由是 GARD 只是转述，转述的准确性应由上游负责。

§10 AI 使用声明

项目 说明
本页 AI 参与程度 由 AI 助手依据官方页面、名录文件与索引文件起草，人工核对数字
数字来源层级 见附录 B，官方页面与可下载文件为一级，合同与论文为二级
未核实项 名录与索引的字段语义未在任何官方文档中定义，只能从文件内容推断
版本信息 以 2026 年 10 月读取的名录 2026 年 9 月版与页面为准
已知不一致 任务描述所指的运营方迁移与 NCBI 下载路径，与本次核验结果不符，正文按核验结果写
适用边界 本文描述的是数据集本身，不含对具体疾病结论的评价，也不构成医疗建议
更新机制 名录按月刷新，本文不承诺随版本同步

常见误读（避坑清单）

常见说法 实际 证据
「GARD 已由 NCBI 或 NLM 运营」 运营方仍是 NCATS，NHGRI 出资 NCBI 的 gard 路径返回 404；关于页写明由 NCATS 管理
「GARD 有 FTP 批量下载 XML」 没有，NCBI 的 GARD 目录返回 404 提交页与 FTP 目录均不存在
「学名里带 Information Center，所以是个文献库」 它是信息中心，输出的是改了写法的科普页 关于页强调把科学语言翻译成通俗信息
「名录一万六千条，所以有一万六千个疾病页」 有详情页的是六千二百六十五条 列表页分页计数与名录 URL 非空计数一致
「它是 OMIM 的镜像」 只借用 OMIM 的部分字段，句式为重新改写 关于页把 OMIM 列为来源之一，页面文本与 OMIM 不同
「详情页有患病率数字」 只有量级描述，没有分层估计 抽查的页面无患病率字段，只有定性表述
「基因一栏能给到位点」 只给基因符号 病因栏写法为列出已知基因符号
「症状频率有四档」 压成常见与少见两档 症状栏只出现两档固定说明
「名录 CSV 的 URL 列都能打开」 近三分之二为空 名录中仅六千余行 URL 非空
「同义词可以按竖线直接切」 切出的元素带前导空格 索引 JSON 的同义词元素示例带空格
「站内有中文版」 没有，只有英文与少量西班牙文 西语页仅三百余条，无中文入口
「引用 GARD 就等于引用到原始文献」 引用折叠为统一说明 页脚只列来源库名，不列逐条文献

FAQ

Q1：GARD 现在到底归谁管？

归美国国立卫生研究院下属的国家转化科学促进中心（NCATS），国家人类基因组研究所（NHGRI）参与出资。这一归属自 2011 年 NCATS 成立起延续至今。曾有一种说法认为它已迁至 NCBI 或 NLM，但本次核验中 NCBI 的 gard 路径与 GARD 的 FTP 目录都返回 404，关于页也仍写明由 NCATS 管理。

Q2：为什么名录有一万六千条，页面只有六千多个？

因为详情页按信息充分度筛选生成。关于页写明入选依据是「已发表与已策展的研究信息是否可得」，信息不足的病暂时没有页面，先留在名录里。这个设计是为了尽快覆盖尽可能多的病名，而不是等每一页都写完再发布。

Q3：能不能把它当作 OMIM 的替代品？

不能。OMIM 的条目是专业人员撰写的专业综述，含基因、等位变异、分子机制与逐段文献；GARD 只借用其中的部分事实，重写成通俗句子。要用基因层面的内容，只能回 OMIM 或 ClinVar。

Q4：症状一栏的「常见」与「少见」能换算成百分比吗？

不能。上游 HPO 注解里本来可以表达更细的频率分级，GARD 把它压成两档，并用固定说明解释含义。两档之间没有可换算的比例，任何把「常见」当作百分比的推断都是错的。

Q5：名录 CSV 的四列够用吗？

对于命名归一与别名匹配，基本够用。四列覆盖了编号、正名、同义词与页面地址。但它不含分类标签、不含症状、不含基因，也不含任何正文。要做这些，需要另取索引文件或逐页抓取。

Q6：索引文件从哪里来，官方有说明吗？

没有官方说明。它出现在详情页列表页的资源引用里，是从页面加载的资源中读到的。字段含义只能从内容推断，官方没有数据字典，也没有承诺字段稳定。生产使用时应当锁版本并留快照。

Q7：西班牙文版覆盖多少？

索引中带西班牙文编号的条目为 356 条，相对六千余个有详情页的疾病是很少的一部分。这意味着西语服务是有限的、按需补充的，而不是全站翻译。

Q8：能不能直接抓全部详情页？

技术上可以，页面是服务端渲染的，基础请求就能拿到正文。但官网没有提供接口或批量包，也没有说明批量使用的条款。抓取前应读站点的隐私与免责声明，并控制频率，避免对公共站点造成压力。

Q9：为什么有的病症状栏是空的？

因为该病的表型在 HPO 中没有足够注解，或上游没有提供。页面上仍会保留症状栏的位置，只是内容为空。这类缺口在极罕见病里很常见，是覆盖偏斜的直接表现。

Q10：患者组织名录可靠吗？

它是有用的起点，但不是权威注册表。关于页写明组织的收录有一套筛选标准，站内也声明提供组织信息只为告知，不构成对其服务的背书。联系组织时应核对其自述的服务范围与所在国家。

Q11：它和 MedGen 是什么关系？

MedGen 是 NCBI 侧的疾病概念与术语汇总库，GARD 从 MedGen 取信息用于解释遗传病与罕见病。两者不是同一层：MedGen 是概念层，GARD 是叙述层。要做概念对齐，走 MedGen；要读一段话，走 GARD。

Q12：数据可以商用吗？

作为美国政府作品，站点内容一般不受版权保护，这为再使用提供了基础。但站内部分内容转引自 Orphanet、OMIM 与 MedlinePlus，这些上游各有自己的条款，商用前应逐项确认。本文不构成法律意见。

术语表

术语 含义
GARD Genetic and Rare Diseases Information Center，遗传与罕见病信息中心
NCATS 美国国家转化科学促进中心，NIH 下属
NHGRI 美国国家人类基因组研究所，NIH 下属
罕见病法案 2002 年美国立法，把罕见病定义为美国境内患病人数少于二十万的疾病
Orphanet 欧洲的罕见病与孤儿药数据库，由法国机构协调
OMIM 在线人类孟德尔遗传，约翰霍普金斯大学维护的基因与表型库
MONDO 疾病本体，用逻辑结构统一多个疾病资源
HPO 人类表型本体，提供表型术语树与频率分级
MedGen NCBI 的医学遗传学概念库
MedlinePlus 美国国家医学图书馆面向公众的健康信息站
ORPHAcode Orphanet 的疾病编号
MIM 号 OMIM 的六位条目编号，带四类前缀
正名 一个疾病的唯一规范写法
同义词 同一疾病的其他叫法，含缩写与旧名
表型 疾病在个体身上表现出的可观察特征
常见与少见 GARD 症状栏的两档频率说明，无换算比例
服务端渲染 页面内容由服务器直接生成，抓取时无需执行脚本
名录 本库唯一可整份下载的四列 CSV
索引 列表页与搜索框依赖的结构文件，含分类标签
免责声明 每页附带的「不替代医生判断」声明

附录 A：核心数字核对表

项 值 来源 来源层级
设立年份 2002 关于页 一级
管理方 NCATS 关于页 一级
出资方 NCATS 与 NHGRI 关于页 一级
名录条目数 16,214 名录 CSV 行数 一级
有详情页数 6,265 列表页与名录 URL 计数 一级
西班牙文页数 356 索引统计 一级
疾病大类数 12 分类词表文件 一级
接诊科室标签数 34 索引标签去重 一级
名录列数 4 名录表头 一级
症状频率档数 2 症状栏固定说明 一级
发病年龄段数 7 年龄栏固定切分 一级
页面修订月份 2026 年 9 月 页脚 一级
累计答复咨询量 十万量级 项目说明与官方信息图 二级
平均确诊耗时 六年以上 关于页与站内正文 一级
NCBI 的 GARD 路径 不存在 核验时返回 404 一级

附录 B：数字的来源分层

一级：官方页面与可下载文件。 包括关于页、名录 CSV、索引文件、详情页的结构与页脚。本文的条目数、页面数、西语页数、分类数、字段名与栏目名均取自这一层，其中条目数与页面数可由下载文件直接复算。

二级：项目文件与公开说明。 包括联邦项目摘要页给出的设立背景与咨询量、机构博客给出的现代化改造目标、预算记录给出的合同承接方与金额量级。这些数字用于说明运营结构与历史，不用于描述当前规模。

三级：未核实。 名录与索引的字段语义没有官方文档定义，本文的字段说明来自对文件内容的观察与页面呈现的对照，属于推断而非官方定义。引用时应说明这一层性质。

附录 C：完整参考文献

  1. Genetic and Rare Diseases Information Center 官方站点，关于页与常见问题，https://rarediseases.info.nih.gov/about-gard ，2026 年 10 月访问。
  2. GARD Rare Disease List（2026 年 9 月版），四列 CSV，由关于页链接提供，2026 年 10 月下载。
  3. GARD 疾病列表页与详情页，栏目结构与页脚修订月份，https://rarediseases.info.nih.gov/diseases ，2026 年 10 月访问。
  4. NCATS 的 GARD 项目介绍页，https://ncats.nih.gov/gard ，2026 年 10 月访问。
  5. NCATS 罕见病转化研究页，含 GARD 数据树与信息学工作的说明，https://ncats.nih.gov/research/research-activities/informatics/rare-disease-translational-research ，2026 年 10 月访问。
  6. 美国国家医学图书馆馆长博客，NCATS 主任客座文章，述及 2023 年 GARD 网站现代化计划，2026 年 10 月访问。
  7. Lewis J, Snyder M, Hyatt-Knorr H. Marking 15 years of the Genetic and Rare Diseases Information Center. 2017.
  8. 美国联邦项目摘要页，GARD 管理与研究支持项目，含设立背景与预算构成，2026 年 10 月访问。
  9. 美国《罕见病法案》2002 年文本，用于罕见病定义。
  10. 人类表型本体与 Mondo 疾病本体官方站点，用于术语体系的对照。

附录 D：取数代码

#-- 完整的最小可用脚本：从名录建别名索引，再按科室标签汇总
import csv, json, collections, re

def load_list(path):
    with open(path, encoding="utf-8-sig", newline="") as fh:
        return list(csv.DictReader(fh))

def load_index(path):
    with open(path, encoding="utf-8") as fh:
        return json.load(fh)

rows = load_list("GARD_Rare_Disease_List_Sep2026.csv")
diseases = load_index("diseases_trimmed.json")

#-- 一、别名索引：键为小写别名，值为 GARD 编号列表
alias = collections.defaultdict(list)
for r in rows:
    for syn in r["Synonyms"].split("|"):
        s = syn.strip().lower()          #-- 必做：去掉前导空格
        if s:
            alias[s].append(r["ID"])

#-- 二、科室路由：只保留覆盖上百个病种的科室
routes = collections.defaultdict(list)
for d in diseases:
    for spec in d.get("tagsSpecialist", []):
        routes[spec].append(d["name"])
main = {k: v for k, v in routes.items() if len(v) >= 100}

#-- 三、把结果存盘，并写清名录版本，保证可复现
with open("alias_index.json", "w", encoding="utf-8") as fh:
    json.dump(alias, fh, ensure_ascii=False, indent=1)
with open("specialist_routes.json", "w", encoding="utf-8") as fh:
    json.dump(main, fh, ensure_ascii=False, indent=1)

print("别名数", len(alias))
print("条目数", len(rows), "有页", sum(1 for r in rows if r["URL"].strip()))
print("主要科室", len(main))

附录 E：如果只记五件事

第一，它是 2002 年依据《罕见病法案》设立的美国公共信息项目，由 NCATS 管理、NHGRI 出资，二十多年一直在这一条线上，没有迁往 NCBI 或 NLM。

第二，它的核心产出是把 Orphanet、OMIM、MONDO 与 HPO 的专业表述改写成面向家属的通俗页，七栏结构对应拿到诊断后的七个问题。

第三，规模上，名录一万六千二百一十四条，有详情页六千二百六十五条，西语页三百五十六条，疾病大类十二个。

第四，批量可用性很弱：官方只提供一份四列名录 CSV，正文需逐页取，没有接口、没有版本号、没有数据字典。

第五，边界很清楚：不含诊疗建议、不含病例、不含基因变异、不含剂量与预后。要这些，回 OMIM、ClinVar 或 Orphanet。

编辑说明

本篇的核验时间为 2026 年 10 月 29 日。核验方式为直接读取 GARD 官方站点的关于页、疾病列表页与若干详情页，并下载名录 CSV 与索引文件做行数与字段统计。所有规模数字均来自可复算的文件，页面栏目结构来自页面本身。

与任务描述不符的三处，按核验结果处理。其一，任务称 GARD 已由 NCBI 或 NLM 运营，实际关于页仍写明由 NCATS 管理、NHGRI 出资，NCBI 的 gard 路径与 GARD 的 FTP 目录均返回 404，因此正文按 NCATS 归属写。其二，任务称有 XML 与 CSV 批量下载，实际只有一份四列名录 CSV，索引文件属页面资源而非官方发布物。其三，任务称历史上由 NCATS 运营并于 2019 年前后迁往 NCBI，实际不存在这一迁移，归属自 2011 年 NCATS 成立起延续至今。

未覆盖的内容包括：名录与索引的字段语义（官方无文档，本文只做观察性说明）、详情页正文的完整抓取（未做全量，只抽查若干页确认结构）、以及各条目的内容准确性（本文不评估单条疾病描述是否正确）。

本页描述的只是数据集本身的结构、规模与边界，不涉及对任何具体疾病结论的评价，也不构成医疗建议或法律意见。数据再使用须逐项确认上游来源的条款。

相关数据集导航

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

  • vaers — 共享标签：医疗NLP / 公共卫生与流行病学
  • orphanet-ordo — 共享标签：公共卫生与流行病学 / 罕见病
  • race-rare-cancer — 共享标签：公共卫生与流行病学 / 罕见病
  • arxiv — 共享标签：医疗NLP / 公共卫生与流行病学
  • ecrin-mdr — 共享标签：医疗NLP / 公共卫生与流行病学
  • omim — 共享标签：医疗NLP / 罕见病
  • litcovid — 共享标签：医疗NLP / 公共卫生与流行病学
  • annotation-dataset-sdoh — 共享标签：医疗NLP / 公共卫生与流行病学
  • cord-19 — 共享标签：医疗NLP / 公共卫生与流行病学
  • maccrobat — 共享标签：医疗NLP / 罕见病

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

返回 AI-Ready 数据集

数据定制

标注服务

欢迎联系咨询

客服二维码

客服二维码

客服二维码
电话咨询

直接咨询

18892062214

微信同号

微信咨询

微信咨询

18892062214

微信同号

邮箱咨询

邮箱咨询

collab@qianfanghub.cn