表型 · 本地处理

Recipe Builder

交互撰写 ukbflow 的 UK Biobank 表型配方：按十一个来源槽填规则，实时校验编码格式，导出与 recipe_write() 同排版的 YAML 及 recipe_new() 代码。

配方

标识

idlabelshort_labelversion

createdupdated

description

自报疾病

derive_selfreport()

规则 1

fieldregex

HES 住院 ICD-10

derive_hes()

规则 1

icd10matchposition

死亡登记

derive_death_registry()

规则 1

icd10matchcause

来源

合并

casedate

备注

3 规则 · 3 来源

id: type_2_diabetes
label: Type 2 diabetes
short_label: T2D
version: 2
created: '2026-07-06'
updated: '2026-07-13'
description: 'A UK Biobank operational phenotype definition for incident type 2 diabetes
  as used by Zhang et al. 2026 (Eur J Epidemiol, DOI 10.1007/s10654-026-01373-7),
  one component of their cardiovascular-kidney-metabolic (CKM) outcome: ICD-10 E11
  (non-insulin-dependent diabetes mellitus) from hospital inpatient (HES) and death-registry
  records, plus baseline self-report.'
sources:
  selfreport:
  - field: noncancer
    regex: ^type 2 diabetes$
  hes:
  - icd10: E11
    match: prefix
  hes_icd9: []
  opcs: []
  gp_read2: []
  gp_ctv3: []
  death:
  - icd10: E11
    match: prefix
  first_occurrence: []
  cancer_registry: []
  cancer_registry_icd9: []
  algorithm: []
logic:
  case: any
  date: earliest
notes:
- 'Provenance: Zhang et al. 2026, Eur J Epidemiol, DOI 10.1007/s10654-026-01373-7
  (PMID 41721995). Type 2 diabetes as one component of the cardiovascular-kidney-metabolic
  (CKM) outcome, UK Biobank.'
- 'SELF-REPORT is a reasonable inference: the study ascertained cases partly from
  baseline self-report but does not publish the field or codes. This recipe maps the
  disease name to the UKB p20002 non-cancer illness value ''type 2 diabetes'' to mirror
  the E11 (type 2) ICD arm; the generic ''diabetes'' value (which does not distinguish
  type) is deliberately not matched.'
- 'INCIDENT: the study excluded participants with prevalent CKM disease or cancer
  at baseline. This recipe records the code definition only; prevalent-case exclusion
  is an analysis step (see derive_case / prevalent handling).'
- E11 = non-insulin-dependent (type 2) diabetes mellitus; under match=prefix this
  captures E11.0-E11.9.

YAML 的排版对齐 recipe_write()的输出，所以生成的文件与库里的文件互相 diff 时，只显示定义本身的差别。

校验

id «type_2_diabetes» 已经是配方库里的一条（Type 2 diabetes）。要新增一条定义就换个后缀，例如 type_2_diabetes_<第一作者>；id 撞了会覆盖既有的那份。
配方库里已有 6 条同名表型的定义（type_2_diabetes_chong、type_2_diabetes_feng、type_2_diabetes_lu、type_2_diabetes_nyberg、type_2_diabetes_thompson、type_2_diabetes_wirler）。label 保持一致是对的 —— 它们是同一个表型的不同操作化。

错误会拦下载，警告不会 —— 警告多半是「你可能想错了」，该不该听是撰写者的事。

说明

配方是什么: 一份配方记录的是「某篇研究把这个表型操作化成了什么」：哪些来源、哪些编码、怎么合并。它不是数据，也不替你决定某个定义是否适合你的研究 ——derive_recipe() 负责把它应用到队列上。
十一个来源槽: 槽内多条规则按 OR 合并，槽间按 logic.case 合并。没用到的槽在文件里写成 []，所以任意两份配方都能逐行对齐着读。
selfreport触摸屏问卷 p20002（非肿瘤）/ p20001（肿瘤），匹配的是疾病名称文本
hes医院住院记录 p41270（任意位置）/ p41202（主要诊断），编码带点存储
hes_icd91996 年前的住院记录 p41271 / p41203，编码不带点
opcs住院手术操作 p41272（任意位置）/ p41200（主要操作），编码带点存储
gp_read2GP 长表 gp_clinical 的 read_2 列（需另行 extract_gp() 取数）
gp_ctv3GP 长表 gp_clinical 的 read_3 列，与 Read v2 是两套独立编码系统
death死因登记 p40001（根本死因）/ p40002（次要死因），ICD-10 带点存储
first_occurrenceUKB 已调和好的首次发生日期字段（Category 1712），一个三字符 ICD-10 一个字段
cancer_registry国家肿瘤登记 p40006（ICD-10）+ p40011（组织学）+ p40012（行为学）
cancer_registry_icd9早期肿瘤登记 p40013（ICD-9），组织学与行为学字段同 ICD-10 分支
algorithmUKB 算法判定结局 ADO（Category 42），判定后的日期字段如 42018 痴呆
编码格式: HES 的 ICD-10 与 OPCS-4 都是带点存储的（I25.2、K44.1），ICD-9 不带点。肿瘤登记那两个槽的编码字段收的是正则（^C44），不是编码表。这三条是撰写时最常踩的坑，校验面板会逐条提醒。
为什么不带注释: recipe_write() 生成的文件里没有 YAML 注释。出处、编码格式的坑、写下来但执行不了的分支，一律走 notes —— 注释是软件看不见的东西：不进对象、不过校验、不被 print() 和配方目录消费。
怎么用到配方库: 下载的 YAML 放进 ukbflow 的 inst/extdata/recipes/，recipe_list() 就能看到它。要贡献回上游，按仓库的贡献指引提 PR；配方在并入库之前会经过复核。
本地处理: 全部计算在浏览器内完成，草稿不上传。配方是表型的定义，本来就不含任何个体级数据 —— UK Biobank 的个体数据留在 RAP 上，这个工具碰不到，也不需要碰。