ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

UK Biobank临床科研数据挖掘实战:申请、表型定义与孟德尔随机化

UK Biobank临床科研数据挖掘实战:申请、表型定义与孟德尔随机化 做过临床科研的人大概都有同一个体会收数据是最大的瓶颈。单中心几百例随访不齐基因检测贵到飞起想发一篇像样的遗传流行病学文章难如登天。所以当我第一次接触英国生物银行UK Biobank时第一反应是这哪是数据库简直是一座随时可以开采的矿。UK Biobank是一个超大规模前瞻性队列数据库招募了约50万名40—69岁英国居民从他们身上采集了基因型、血液生化、尿液、体格测量、生活方式问卷、认知测试、住院与死亡登记以及数十万人的脑、心、腹部影像数据。对临床人来说只要你有合理的科学问题、能通过规范化申请就能在这套数据上做遗传关联分析、孟德尔随机化、多基因风险评分乃至影像表型研究。这篇内容就写给所有打算把UKB作为自己第一篇数据挖掘论文素材的临床医生和研究生从数据怎么拿、表型怎么定义、分析怎么做到常见的坑怎么绕一条线讲清楚。1. 一条数据洪流UK Biobank到底存了什么1.1 50万人的大样本是怎么攒出来的UK Biobank的核心是“规模”。2006年至2010年研究团队在英国苏格兰、英格兰、威尔士的22个评估中心招募了50万余名中老年人基线年龄多在40—69岁之间。每个入组个体都经历了长达数小时的基线评估包括问卷调查、体格测量、血压与肺功能测试、静脉血和尿液采集。这个设计决定了它在流行病学上的一句话特点它是一个能同时支持“暴露在前、结局在后”的前瞻性研究设计的数据库不是一堆横断面数据的简单堆叠。光有基线还不够。UK Biobank对这批人进行了持续追踪通过住院记录、死亡登记、癌症登记、初级保健记录等途径不断回补新发疾病信息。这意味着你可以用基线测量比如血脂、血压、生活方式去预测未来若干年内某个事件的发生风险这种“时间先后关系”是普通电子病历数据库给不了的。1.2 数据仓库里的具体货架把UKB想象成一个巨大的数据仓库里面不同的货架放着不同类型的数据。我习惯把它分成几个大类方便头脑里有个地图数据类别主要内容大致覆盖情况基因型数据基因分型芯片数据、imputation后遗传位点、线粒体DNA全队列50万人完成芯片分型全外显子/全基因组测序WES、WGS、变异注释分批发布覆盖面持续扩大健康记录住院主诊断与手术操作码ICD-10、OPCS-4、死亡原因、癌症登记全队列持续随访基线问卷吸烟、饮酒、饮食、睡眠、职业暴露、家庭收入、教育程度绝大多数参与者体格与功能血压、心率、身高体重、腰臀比、肺功能、握力、骨密度、认知测试大多数参与者血液与尿液血脂、血糖、糖化血红蛋白、炎症标志物、肾功能指标等基线全覆盖部分人有重复测量影像数据脑MRI、心脏MRI、腹部MRI、DXA全身骨密度影像亚队列设计目标10万人衍生数据遗传主成分PCs、样本批次、亲缘关系矩阵、影像衍生表型IDP按批次提供关键点在于UKB的原始数据不是一个统一文件夹而是按场次和文件分散存储的。和你平时操作Oracle、MySQL这类关系的数据库一样你需要通过“字段编号样本编号”的键值把不同表关联起来。UKB的字段Field有固定编号比如Field 31是性别Field 21003是年龄Field 41270是住院ICD-10诊断代码。很多人刚上手时被几千个Field编号砸晕这很正常——把它当成一张巨大的宽表来管理就行了外键就是那个每个人的唯一编号eid。1.3 为什么临床人会绕不开它临床人的痛点是样本量不够、随访时间短、对照不好找、蛋白和影像数据太贵。UKB一次性把这些问题都摊平了。如果你做传统临床队列光靠自己的病例收集十年也很难凑到5000例有心梗事件的数据但在UKB里这只需要一条SQL查询加上合理的表型定义。如果你做药物靶点方向UKB的基因型数据加上血浆蛋白组、代谢组数据可以让你完成从“遗传变异—中间表型—临床结局”的整条因果链条分析。如果你做影像研究UKB提供的脑区体积、白质纤维束结构等衍生指标已经过了大量QC可以直接关联到认知、精神疾病和心血管风险。更关键的是UKB允许你合法地在“个体水平”上做分析而不是像很多公开数据库只给汇总统计量。这意味着你可以自己定义暴露、自己定义结局、自己调整协变量自由度极高。这一点同时带来了风险如果没有数据库基本功很容易在字段筛选和数据清洗上翻车后面的分析全白做。2. 拿钥匙的艰难与正确姿势申请与数据访问2.1 申请窗口里的硬性门槛UKB不是一个下载即用且适合所有人的免费资源。它的准入机制本质上是科研项目评审不是注册后随便抓数据。首次申请需要主申请人Principal InvestigatorPI具备研究机构任职资质通常要求是高校、医院、研究所的员工或长聘教职人员。如果你是硕士生或博士生一般需要挂靠导师或科室主任作为PI自己作为协作者进入系统。申请需要提交一份研究方案Research Plan核心是讲清楚三件事你要回答什么科学问题你需要哪些数据字段你的统计分析和伦理考量是什么很多临床人的误区是“我想先看看数据再说”。这在UKB行不通。你必须在申请时明确列出需要的Field编号所以动手申请前先花一周时间泡在UKB Showcase里熟悉字段非常值得。另外方案里最好带上一点初步统计计划哪怕只是简单的“先做Logistic回归再做有向无环图调节中介分析”也能显著提高通过率。审批周期通常从几周到半年不等。有些临床人以为提交后马上就能用结果耽误了论文投稿窗口。我的建议是在写标书阶段就提交申请等标书中的方案敲定UKB数据也正好批下来。2.2 拿到数据有几种姿势我说“拿到数据”其实是个泛称因为UKB提供好几条访问路径选错了路径会让人多走很多弯路。第一种是传统下载方式。你在申请获批后从AMS系统Access Management System里勾选需要用到的字段集和数据版本打包下载。优点是可以把数据拉到本地用习惯的软件Roll缺点是很多组学数据体积惊人全外显子的VCF文件几百GB到几TB都有可能机箱里没有足够硬盘还能忍网络传输断了才是最让人崩溃的。第二种是UKB Research Analysis PlatformRAP基于DNAnexus搭建的云平台。我强烈建议临床人优先用这种方式。RAP把原始数据托管在云端分析环境预制了JupyterLab、RStudio、Spark SQL等常用工具不需要下载数百GB文件直接在云端写代码、跑回归。用RAP还有一个额外好处计算资源和数据在同一机房很多耗时的“数据搬运”环节被直接抹掉。它的费用模式是按计算量计费但UKB会给获批研究者一定的免费计算额度绝大多数初筛分析用不了太多钱。此外还有UKB Showcase它是数据字典负责回答“这个字段到底存的什么、单位是什么、分几期测量”。我见过太多人把Showcase当成下载入口以为在那里点Download就能拿到数据结果绕了一大圈。2.3 数据库版本与同步问题热词列表里有一堆关于数据库同步工具、数据库管理工具的搜索记录。放在UKB的语境里你得养成一个习惯跟踪数据版本。UKB不是静态的它会随着测序完成、影像扫描进度和新随访数据更新而定期发布新版本。同是一个Field隔几个月可能有增补记录或修正值。你写方法学时必须写清楚用的是哪个版本如2024年某月发布的外显子数据否则别人复现不了你的结果。我个人的习惯是建一个专门的版本记录表把每次下载的数据集名称、文件日期、字段版本、下载时间都登记进去。这一步看起来多此一举但在回复审稿人“你用的数据是哪个release”时非常救命。数据库同步工具本身并不适用于UKB——你不能像同步自己的业务库那样直接拉取UKB只能通过批准的数据集申请接口获取。把“同步”做好靠的是文档习惯而不是某个现成的软件。3. 临床人的第一个UKB分析从选题到落地3.1 选一个能打的问题在UKB上发论文最常见的选题思路有三条疾病预测类基线指标遗传风险评分→未来心血管事件/糖尿病/痴呆风险病因关联类某暴露饮食、睡眠、生化指标→某结局的风险比孟德尔随机化类用遗传变异作为工具变量推断中间表型与结局的因果关系临床人最大的优势是临床知识扎实知道哪些表型定义可操作、哪些指标在临床上真正重要。但光有临床直觉不够你还需要先看UKB里的事件数够不够。举例来说你在方案里想研究“心肌梗死”可以通过Field 41270住院ICD-10主诊断或Field 42001自报非癌疾病代码提取但必须提前估算事件例数避免苦哈哈分析完发现统计功效不足。好在UKB的汇总统计数据可以在Showcase和部分公开论文里查到申请获批前就能查到大致的患病与事件数量。我的建议是从“暴露可测、结局常见、机制尚未完全清楚”的题目入手。比如“睡眠时长与2型糖尿病”“血浆维生素D与骨折风险”“握力与全因死亡”都属于容易出结果、审稿人也能接受的稳妥方向。3.2 表型定义的细节之水确定题目后最耗精力的环节是表型定义。UKB不会给你一张现成的“是否患病”的干净表格你需要自己把自报疾病、住院记录、死亡记录、初级保健记录拼起来。拿心肌梗死来举例。一个相对稳妥的定义是自报心肌梗死Field 20002非癌自报疾病代码里有代码1161或住院诊断Field 41270里包含ICD-10代码I21急性心肌梗死I22再发心梗或I23心梗后并发症等或死亡原因Field 40001、40002里包含I21/I22/I23这种多来源交叉的好处是减少漏诊但坏处是可能混入“陈旧性心肌梗死”和“急性事件”。你需要根据研究设计选择”单次事件时间“还是“首发时间”。定义表型时在论文方法部分写清楚用了哪些Field和代码是审稿人最看重的基本功。除了疾病表型暴露变量同样要留意Field单位。收缩压Field 4080和Field 93都存过血压但一个是自动读数、一个是手工读数age字段21003在不同随访时间的值不同分析时要注意用的是第几次随访的Instance。上一个字段编号眼花分析对象从血压变成了骨密度这种事不是没发生过。3.3 从GWAS到孟德尔随机化到PRS拿到干净的表型后主流分析框架有以下三大类临床人至少要了解每一种的适用场景。基因组关联分析GWAS是UKB的看家本领。你把基因型数据和表型数据连接起来对每个遗传位点做一次回归P值小于5×10⁻⁸即达到全基因组显著水平。常用工具是BOLT-LMM、SAIGE、regenie和PLINK。plink2 --bfile ukb_geno_chr21 \ --pheno mi_pheno.txt \ --logistic \ --covar covars.txt \ --ci 0.95 \ --out gwas_chr21_mi跑之前必须加入遗传主成分PC作为协变量用来校正人群分层。UKB直接提供Field 22009的10个遗传主成分不要自己重新算。孟德尔随机化MR则是利用“遗传变异在受精时随机分配”的特性来推断因果。它相当于一个天然的随机对照试验工具变量就是那些与暴露强相关的遗传位点。基于UKB的单样本MR常用两步最小二乘法或IVW法两样本MR则可以通过公开GWAS汇总数据来完成。这里要注意一个关键陷阱如果做两样本MR工具变量所在的GWAS人群与结局数据必须没有重叠样本否则会产生弱工具变量偏倚和样本重叠偏倚。UKB个体的数据是受控的很难从外部GWAS汇总数据中彻底剔除所以很多MR论文现在喜欢用“UKB单样本MR外部两样本MR交叉验证”的组合方式。多基因风险评分PRS是临床预测方向最常用的方法。你在独立的GWAS发现数据里筛选一批显著位点用它们的效应量构建加权评分然后到UKB验证该评分对疾病的区分度和校准度。常见的构建工具有PRSice-2、LDpred2等。注意如果发现数据和验证人群有重叠评分的预测效果会被高估。更稳妥的做法是用UKB内部的一部分样本做发现另一部分做验证或者干脆使用不与UKB重叠的外部GWAS汇总数据。3.4 一个最小可复现的分析流程下面我用一个“睡眠时长与高血压风险”的假想例子给你梳理出一套最小工作流。第一步在AMS中申请需要的字段eid唯一编号、Field 21003年龄、Field 31性别、Field 22009遗传主成分、Field 1200饮酒频率、Field 1239吸烟状态、Field 4080收缩压、Field 4100舒张压、Field 1160睡眠时长、Field 41270ICD-10诊断、Field 42001自报疾病。第二步把随访数据中关于高血压的诊断代码整理出来。高血压的ICD-10编码包括I10到I15再加上自报代码和降压药使用字段Field 6153/6177可以构成一个相对广泛的“高血压表型”。第三步用R读入数据并做基础清洗library(data.table) d - fread(ukb_extract.csv) d - d[!is.na(age) !is.na(sex), ] d$hypertension - ifelse(d$icd10_primary %like% %I1[0-5]% | d$self_report_hypertension 1, 1, 0) # logistic regression model - glm(hypertension ~ sleep_hours age sex PC1 PC2 PC3, data d, family binomial) summary(model)第四步如果活动范围扩大到遗传分析就把样本切成“发现集”和“验证集”先用发现集跑GWAS获取显著位点再构建PRS并在验证集里评估AUC增量。这个流程可以套用到绝大多数临床表型上只要把暴露和结局字段换成你的研究变量即可。在我的经验里第一次跑通这套流程少则两周多则两个月。慢不是因为代码复杂而是字段定义、数据清洗和版本核对会让新手反复卡壳。老生常谈一句话前面20%的时间能决定后面80%的成果质量。4. 避坑手册我把常见的翻车点都踩了一遍4.1 申请阶段最容易犯的错申请被拒最常见的三个原因PI资质不够硬、研究方案写得不具体、没有说明伦理考量。后两个其实都可以通过“把方案当成写标书来写”解决。我见过一份被拒的方案通篇都是“我想看看基因和疾病的关系”没有具体到哪个基因、哪种疾病、哪个队列、哪个统计模型。审阅人当然无从判断。相反一份好方案会在两页内写清楚研究背景、目标暴露与结局的Field编码、样本纳入排除标准、统计模型、敏感性和亚组分析、多重检验校正方法。再加上一句“本研究将遵循UKB的伦理框架和数据保护要求结果以汇总统计形式发表”基本就够了。另外主申请人如果是临床医生最好邀请所在机构的医学统计或生物信息人员加入团队在申请表中明确写上各自的协作分工。UKB审批方看到“临床统计”组合时通过率和审核速度都会明显提升。4.2 数据合并时那些让人崩溃的时刻数据下载到手后你需要把“表型表”“基因型表”“随访记录表”通过eid合并。eid本身是加过密的样本编号同一个个体在不同文件中必须保持一致。很多新手把同一个人的多行记录当成多个人一个不留神就出现几十万条虚假样本。另一个高频坑是Field里的“Instance”概念。UKB的很多字段在基线、第一次随访、第二次随访等多个时点都有记录你选Instance 0和选Instance 1可能是两套完全不同的数据。比如Field 21003年龄在Instance 2时就代表了第二次随访时的年龄而不是基线年龄。分析时一定要在AMS提取界面或Showcase里确认你要下载的是哪个Instance。基因型数据本身也有格式坑。UKB同时提供bed/bim/fam格式、bgen格式和VCF格式。bed格式适合PLINKbgen适合BOLT-LMM和regenieVCF适合更底层的变异筛选工具。下载之前先确认自己的软件读哪种格式别下错了版本还硬跑。热词里搜“mysql的数据库连接池”“数据库增删改查”的兄弟放到UKB场景里其实是同一个道理你要懂得主键、外键、多表连接、版本一致性。UKB不是MySQL但在数据管理逻辑上你需要拿出工程思维。4.3 统计分析里最隐蔽的伪影人群分层是UKB分析里的经典陷阱。UKB招募点遍布英国各地不同地域的人群祖先成分比例差异明显。如果你不加入遗传主成分校正很可能会把一个地域差异当成基因与疾病的关联。所以GWAS和PRS分析里加入Field 22009的10个PC是默认操作不要为了省事跳过。同样的坑还出现在“样本重叠”上。用UKB数据同时做发现和验证时如果两个数据集有重叠你得到的预测指标一定虚高。正确做法是将样本分成无重叠的训练集和测试集流程上保证训练集和测试集分离后再计算AUC。交叉验证虽然也能用但在审稿人眼里“独立验证集”比“交叉验证”更有说服力。多重检验校正也是临床人经常忽视的点。GWAS全基因组通常用5×10⁻⁸的阈值影像衍生表型动辄几千个IDP此时应该再乘以严格的Bonferroni校正系数否则假阳性会成批出现。另一个稳妥的办法是用FDR做初步筛选再做外部验证或功能信息辅助过滤。还有表型误分类的问题。只看ICD-10住院记录会漏掉很多仅在初级保健中记录的患者只看自报疾病又会混入主诉与诊断的偏差。比较稳妥的做法是把住院记录、死亡记录、癌症登记、初级保健记录和自报疾病结合成一个复合定义并在敏感性分析中分别报告单一来源的结果。这样即使审稿人对表型定义持有异议你也拿得出更稳健的替代分析。4.4 合规使用与发表时的注意事项UKB对个体数据有严格的使用协议。获批的研究方案之外不得随意扩展到其他未批准的分析场景。如果你发表论文时的分析范围超出了当初申请的范围必须在投稿前向UKB提交修正案Amendment。这里的红线是原始个体数据不能重新发布或转交给未授权第三方论文附件只能放汇总统计结果不能把几十万人的基因型和表型CSV打包上传到补充材料。论文方法部分和致谢部分必须写清楚UKB资源编号和应用号Application Number通常格式类似“This research has been conducted using the UK Biobank Resource under Application Number 12345.”。同时还要引用UKB核心综述文献一般引用两篇一篇描述队列设计一篇描述基因型数据或者影像数据生产流程。投稿前把这些参考文献备好能省不少来回修改的时间。正确引用不仅是礼貌问题也是可复现性的体现。审稿人看到应用号就能追踪你的数据版本和分析范围这对文章可信度加成很大。反过来没有写应用号的UKB论文基本可以断定作者踩了合规的坑。5. 长期主义UKB不只是一篇论文的素材库很多临床人第一次接触UKB目标就是“发一篇SCI”。但深入了解数据后会发现它完全可以支撑一个系列化的研究方向。举个例子你如果对“睡眠与心血管疾病”感兴趣第一篇文章可以先做一个大规模的观察性关联研究第二篇可以用孟德尔随机化验证因果方向第三篇可以基于多基因评分建立预测模型第四篇还可以叠加影像数据看脑区结构的中介作用。同一个临床表型一套完整逻辑下来就能形成一个小型的研究体系比到处换题更高效。从资源投入来看申请一次获批后你在该应用号下就可以持续获取更新数据不必每次都重新走完整审批流程当然新扩展还是需要修正案。这意味着早一年申请UKB相当于早一年拥有了一个可长期更新的科研数据底座。周围很多临床同行起初觉得UKB申请“门槛高”“文书麻烦”真正批下来之后都觉得这个时间花得值。如果你正准备开始我个人的建议是先不急着走正式申请花几天时间在UKB Showcase上注册一个浏览账号把感兴趣的研究方向的Field翻一翻看一看每个字段的说明、单位和覆盖人数。这一步零门槛但价值极高能帮你判断自己的题目到底可不可行也能锻炼看数据字典的基本功。等你对字段编号和数据结构建立起直觉后再提交正式申请被拒的概率会小很多。最后再分享一个小技巧在UKB相关社区里多看看别人发表的数据声明和算法定义。很多研究组会在论文补充材料里给出详细的Field编号清单这些都是可以“偷师”的财富。照着成熟团队的做法搭建自己的表型算法和代码流程足以让你的第一篇UKB论文少走三个月弯路。数据矿就在那里剩下的事情就看你能不能沉下心去挖了。
返回列表