企业官网建设流程全解析

简介：在临床试验统计中，估计目标（Estimand）并非一种新的统计方法，而是对治疗效应定义与分析逻辑的重构。ICH E9(R1)增补指导原则要求研究者先明确“估计什么样的治疗效应”，再选择模型与缺失数据处理策略，从根本上改变了传统“先定方法再套数据”的分析路径。该框架通过处理条件、目标总体、变量、伴发事件策略和群体水平汇总五个属性定义临床问题，并依据伴发事件的类型选择Treatment Policy、Hypothetical、Composite等策略。理解这一逻辑对统计师与临床团队都至关重要，直接影响试验方案的撰写、敏感性分析的设计以及监管审评的通过率。在降糖药、抗肿瘤等适应症的III期试验中，正确应用估计目标能够显著提升结论的稳健性与临床可解释性，本文结合SAS代码与实操案例，系统梳理从方案设计到报告交付的完整落地路径。

1. 估计目标不是又一个统计方法，而是一次分析逻辑的重排

做临床试验统计的人，这两年应该都被同一个词反复敲打过：估计目标（Estimand）。ICH E9(R1) 这份增补指导原则，表面上在讲怎么定义治疗效应、怎么做敏感性分析，实际上它把过去几十年我们习惯的「先定分析方法、再套数据」的思路整个倒了过来。过去我们拿到一个终点，第一反应是「用 Mixed Model 还是 ANCOVA」，而 E9(R1) 要求你先回答一个更前置的问题：**你估计的到底是什么治疗效应？**这个问题不回答清楚，P 值再好看，审评员也可能直接判定你的主分析答非所问。

这套框架最反直觉的地方在于：它不关心你的统计模型有多精巧，它先逼你承认「数据里存在一些会干扰效应解释的事件」——患者中途停药、用了救援药物、死了、换了治疗方案——然后要求你把这些事件的处理策略作为分析方案的组成部分，在方案阶段就写清楚。我的实际经验是，第一次按这个逻辑去做一个 III 期试验的统计分析计划（SAP），几乎把整个团队逼疯，因为以前我们默认这些「脏数据」都靠缺失值假设兜底，现在必须逐类说明它们算什么、怎么处理、为什么这么处理。这篇笔记就围绕估计目标的五个属性、五种伴发事件处理策略和敏感性分析的落地路径展开，尽量把我踩过的坑和目前认为比较顺的做法说透。

2. 估计目标框架的五个属性：先把问题问对，再谈模型

2.1 一个贯穿全文的模拟案例

为了不让讨论悬空，我虚构一个贯穿全文的场景：某公司做一个口服降糖药的 III 期试验，对照是安慰剂，主要终点是治疗 24 周后 HbA1c 相对基线的变化值。试验中允许患者在血糖控制不佳时接受救援治疗（加用其他降糖药）。这个设计在真实世界里很常见，但它恰恰是 E9(R1) 框架要处理的核心矛盾：到了 24 周，一部分患者的 HbA1c 是在「试验药 + 救援药」的共同作用下测得的，那么我们要估计的治疗效应，到底是「单纯试验药的效果」，还是「试验药策略（含允许救援）的效果」？这两种问法对应完全不同的统计模型、完全不同的结论解读。这就是估计目标要解决的第一件事：把这个问题用五个属性固定下来。

五个属性分别是：处理条件、目标总体、变量（终点）、伴发事件处理策略、群体水平汇总。前三个相对直观，处理条件指我们比较的是「试验药 vs 安慰剂」还是「试验药 + 某背景治疗 vs 安慰剂 + 某背景治疗」；目标总体指我们关心的患者群，是所有随机化患者，还是某个亚群（比如依从的患者）；变量就是主要终点，包括它的定义、测量时间点和转换方式。真正的难点集中在第四个属性——伴发事件处理策略，以及它对第五个属性（如何汇总成单一数值）的传导。

2.2 五个属性如何写进方案：一个可抄的模板

在实际操作中，我习惯用下面这个表格把每个属性在方案里的文字固化下来，这个习惯救过我很多次，因为口头讨论时大家觉得达成共识了，落笔时才发现对「处理条件」的理解根本不一致。

我见过的最常见的翻车点在于：团队把「处理条件」写成了「试验药 vs 安慰剂」，但实际统计分析里把使用过救援药的患者数据照常纳入，而救援药的使用率两组又不平衡，最后审评质疑「你声称估计的是纯药物效应，实际数据里混了救援效应，目标的处理条件到底是什么？」所以每次方案讨论，我都会追一句：这句话写进 SAP 里，审评员看了会不会追问？追问了你能不能用第五个属性回答？回答不了就回去改定义。

2.3 从传统分析到估计目标：思维转换的关键一步

传统统计分析的起点是「数据生成机制假设」，比如假设缺失值随机缺失（MAR），然后用混合模型估计。E9(R1) 的起点是「临床问题」，先确定要回答的问题，再反推需要什么样的假设、什么样的模型。这种转换听起来简单，做起来别扭——尤其是团队里如果有老统计师，他会觉得「我用了十年的 MMRM 怎么就不对了？」。其实 MMRM 在估计目标框架下仍然可以用，只是你得先说明：你选择的伴发事件策略是假设策略还是处理策略？如果是处理策略，那么 MMRM 的缺失值假设就要和数据里实际缺失模式对得上；如果是假设策略，那你要么剔除伴发事件后的数据，要么给伴发事件后的数据人为赋一个假设值。

我个人的经验是，做这个转换最有力的抓手不是统计理论，而是把「估计目标」当成一个向临床团队提问的工具：你问临床同事「这个患者用了救援药之后，你希望他的数据在分析里代表什么？是他真实会发生的情况，还是我们假设他继续用试验药会发生的情况？」临床团队一旦被迫回答这个问题，他们就会理解为什么统计师要区分五种策略，而不是简单地打一个「缺失」标签。这一步看似是沟通工作，但直接决定后面所有的模型和敏感性分析设计，值得专门开一次会来对齐。

3. 五种伴发事件处理策略：选型、实现与典型场景

3.1 策略全景与选择逻辑

伴发事件（Intercurrent Events）是 E9(R1) 框架里最核心也最容易混乱的概念。它不是传统意义上的「缺失数据」，而是「发生后会改变我们对治疗效应解释的事件」。同一类事件，在不同估计目标下可以选不同策略，比如在同一个试验里，对「使用救援药物」这个事件，如果目标是估计「随机分组策略的效应」，选处理策略（Treatment Policy）；如果目标是估计「如果所有人都严格按方案用药的效应」，选假设策略（Hypothetical）。下面这张表是我自己整理的五种策略速查，方便在方案讨论时快速对齐。

选策略没有绝对的对错，但有一个核心原则：策略必须服务于你真正想回答的临床问题，而不是服务于数据的可用性。很多团队先看数据里停药的人多不多，再回来选策略，这是完全倒置的。我见过最典型的错误就是把所有事件都默认套用 Treatment Policy，因为它在统计分析上最省事（所有数据照单全收），但如果试验里大量患者因为疗效不佳而停药换药，Treatment Policy 估计出来的效应会稀释得非常厉害，审评员就会质疑你的估计目标对临床决策没有指导意义。反过来，如果大量患者停药，你却选了 Hypothetical 策略，统计模型对未观测数据的依赖会非常大，结果的不确定性也会很大，这类敏感性分析通常很难看。

3.2 五种策略在 SAS 里的落地：代码级拆解

实际编程时，不同的策略对应不同的数据整理方式和过程步。下面我用模拟数据的分析需求，给出每种策略在我日常工作中最常用的实现骨架。数据集里有三列关键变量：trt（分组）、hba1c_change（终点）、rescue_time（使用救援药的周数，没有则为缺失）。模糊的是，真实项目中你还会有更多协变量，但骨架逻辑是一样的。

首先是 Treatment Policy 策略。它最直接——所有患者的数据都进分析，不管他什么时候用了救援药。常用 MMRM 或 ANCOVA，SAS 代码大概是：

proc mixed data = trial_data; class trt site; model hba1c_change = trt baseline_hba1c site / ddfm = kenwardroger; lsmeans trt / diff cl e; ods output diffs = diff_results; run;

这段代码的逻辑是：用混合模型估计治疗组的均值差，其中 site（研究中心）作为随机效应，baseline_hba1c 作为协变量调整，残差用 Kenward-Roger 法校正自由度。Treatment Policy 策略在缺失值上通常假设 MAR，如果试验脱落机制比较复杂，更稳妥的做法是在 MMRM 后加一个多重填补（用下面的 Hypothetical 策略里的填补逻辑）。

其次是 Hypothetical 策略，这是在实际项目中代码最费功夫的。它要求我们构造「如果伴发事件不发生」的数据。常规做法是多重填补：把使用救援药之后的数据视为缺失，然后基于其他变量填补。SAS 里可以用 proc mi 做填补，再用 proc mixed 做分析，最后用 proc mianalyze 合并结果：

proc mi data = trial_data out = mi_data seed = 20240501 nimpute = 50; var trt baseline_hba1c hba1c_change rescue_time; mcmc; run; proc mixed data = mi_data; by _imputation_; class trt site; model hba1c_change = trt baseline_hba1c site / ddfm = kenwardroger; lsmeans trt / diff cl; ods output diffs = mi_diffs; run; proc mianalyze data = mi_diffs; modeleffects trt; stderr stderr; run;

这段代码的逻辑是：先用 MCMC 法对每个患者缺失的结局做 50 次填补，生成 50 套完整数据；然后对每套数据跑相同的 MMRM 模型；最后用 proc mianalyze 把 50 次的估计值和标准误合并成单一的推断结果。其中nimpute = 50是可调的，一般 20 到 100 都有人用，我习惯用 50，因为合并后的标准误在 50 次以后趋于稳定，再多只是增加计算时间。

Composite 策略相对好实现：把终点重新定义，比如「治疗失败」是指 24 周 HbA1c 降幅不达标或使用救援药，然后跑二分类逻辑回归或者时间事件分析。While-on-treatment 的处理方式通常是数据截断：把停药之后的时间点数据删掉，只分析停药前测量，但要注意如果停药比例太高，这种分析会丧失大量信息，而且要说明截断后的数据在治疗组间是否可比。Principal Stratum 是最难实现的策略，往往需要潜在分层模型或结构方程模型，我在实际项目里用得比较少，因为它的假设很强且很难用数据验证，但如果监管沟通中明确要求了这种估计目标，还是要认真对待。

proc logistic data = trial_data; class trt / param = ref; model failure(event = '1') = trt baseline_hba1c / clodds = wald; run;

这是 Composite 策略的一个简单落地示例，failure 是重新构造的复合终点变量，取值 0 表示 24 周时 HbA1c 达标且未使用救援药，取值 1 表示不达标或使用了救援药。逻辑回归输出的优势比就是这个估计目标下的效应度量。

3.3 策略选型的决策矩阵：什么时候该用哪种

策略选型没有万能公式，但有一个决策顺序可以参考。第一步，和临床团队确认「如果患者用救援药了，你在临床实践中会怎么看待他？」如果临床上认为「救援药是治疗方案的一部分」，那 Treatment Policy 就是默认选择；如果临床上认为「救援药意味着治疗方案失败，我们真正关心的是没有救援情况下的效果」，那么 Hypothetical 或 Composite 更合理。第二步，看事件发生率。事件率低于 5%，策略选择的影响通常很小，可以选最简单的 Treatment Policy；事件率到 20% 以上，策略选择就会显著影响效应量，必须花时间讨论。第三步，看审评先例。同类适应证前面获批的产品用了什么策略，虽然不是决定性因素，但可以帮你预判监管会重点关注哪个方向。

一个容易被忽略的细节：同一个试验里不同伴发事件可以选不同策略。比如「使用救援药物」用 Treatment Policy，「死亡」可能用 Composite（将死亡视为终点中的最差情形），「提前停药」可能用 Hypothetical。SAP 里必须逐类事件写明策略，不能笼统写「采用处理策略处理所有伴发事件」。我见过一个方案初稿就是这么写的，被统计审评直接打回，理由是无法判断「每个事件对效应解释的影响是否一致」。

4. 敏感性分析与补充分析：怎么设计才算正经

4.1 主线分析、敏感性分析、补充分析的关系

E9(R1) 把分析分为三类：主线分析（主估计目标的推断）、敏感性分析（对同一估计目标结论稳健性的考察）、补充分析（对不同估计目标或不同人群的探索）。很多人初期容易把三者搞混，尤其是把敏感性分析做成「换一个统计模型跑一遍」——这远远不够。真正的敏感性分析必须锚定同一个估计目标，在主分析的基础上，对推动结论的关键假设做挑战。假设主分析用的是 Treatment Policy + MMRM + MAR 缺失假设，那么敏感性分析应该考虑：如果缺失不是 MAR，而是缺失与未观测的结局相关（MNAR），结论还稳不稳？如果用另一种伴发事件策略（比如把使用救援药视为治疗失败），结论方向会不会变？

这里有个区分技巧：换模型（比如从 MMRM 换成 GEE）但估计目标不变，这算敏感性分析；换伴发事件策略（比如从 Treatment Policy 换成 Hypothetical），这严格来说是换了一个不同的估计目标，应该作为补充分析呈现，而不是混在敏感性分析里。这个界限在监管沟通里非常关键，如果把换了策略的分析当作「敏感性分析」写进 SAP，审评员会认为你对估计目标的定义不够稳定，反过来质疑主线分析。

4.2 敏感性分析方法的常见组合

我在实际项目中常用的敏感性分析矩阵由两个维度构成：维度一是对未观测数据的假设（MAR vs MNAR），维度二是模型类型（参数模型 vs 非参数/半参数模型）。推荐最少做四组：先是 MAR 假设下的不同模型（比如 MMRM vs GEE），再是 MNAR 假设下的模式混合模型（Pattern Mixture Model）和选择模型（Selection Model）。模式混合模型的 SAS 实现相对成熟，基本思路是先按伴发事件（比如是否使用救援药）分层建模，再按层内权重合并：

proc sort data = trial_data; by rescue_flag trt; run; proc mixed data = trial_data; by rescue_flag; class trt site; model hba1c_change = trt baseline_hba1c / ddfm = kenwardroger; lsmeans trt / diff cl; ods output diffs = pmm_diffs; run;

这里的rescue_flag是患者是否经历过伴发事件的二分类变量，by语句让模型分别在两个层内运行。逻辑是：把使用过救援药和没使用过的患者当成两个潜在分布，分别建模，再根据研究目标对两层的贡献加权合并。加权比例是有讲究的：如果选择 Treatment Policy，权重通常按实际比例；如果希望结果偏向「无事件人群」，可以人为调整权重，这就是敏感性分析里常用的探询方法。但这种人为调权需要很谨慎，必须在 SAP 里事先声明，不能等看到数据再定权重。

4.3 敏感性分析结果怎么呈现才不会被误读

呈现敏感性分析结果有一个原则：敏感性分析的价值在于「结论一致」，而不是「P 值都有意义」。我习惯用一个效果量森林图来汇总，横轴是效应量（比如两组 HbA1c 变化值的均值差），每个点对应一种分析，竖线是临床意义阈值。审评员看这种图，一眼就能判断稳健性。如果大部分点落在阈值同侧，结论就是稳健的；如果有些点在阈值另一侧，就要解释为什么不同假设会导向不同结论，通常这是试验设计阶段就该预料到的。还有一种常见误读：敏感性分析的置信区间普遍比主分析宽是正常的，因为敏感性分析很多时候要付出额外的不确定性代价，不是说区间宽就说明你不稳健，关键是效应量的方向和量级变化是否在可接受范围内。

补充分析则灵活得多。比较常见的有：在符合方案人群（Per-Protocol Set）上做同样的分析、用依从性指标做分层分析、把主要终点换成连续变化相对基线的百分比等。但补充分析的结果不能喧宾夺主，SAP 里要明确写「补充分析结果仅用于解释，不作为关键监管决策依据」。

5. 评估与实施中的常见坑：从方案到审评的 4 个翻车点

这个行业里，E9(R1) 的落地最容易在几个地方翻车，每一个我都亲眼见过，写出来供你避雷。

第一个坑：把伴发事件和缺失数据混为一谈。现象是 SAP 里只写了「缺失数据采用混合模型重复测量处理」，对伴发事件只字不提。原因是团队沿用了旧习惯，认为缺失数据的处理方法就是伴发事件的策略。解决方法是：在 SAP 里单独开一节「伴发事件与估计目标」，逐类列出可能的伴发事件，分别指定策略；哪怕某类事件在前期数据里没有发生，也要写明「预计不发生，如发生将按 X 策略处理」。这看起来是文字工作，实际上逼着团队在揭盲前把临床逻辑想清楚，是防翻车最有效的手段。

第二个坑：估计目标定义与数据收集不匹配。现象是方案里选了 Hypothetical 策略，但试验数据收集没有记录「如果未使用救援药，患者本来可能的结局」所需的充分协变量，导致填补模型不可靠。原因是在设计阶段统计师没有把估计目标的属性分解成数据收集需求。解决方法是：在定稿估计目标时，同步检查病例报告表（CRF）字段，特别关注伴发事件发生的时间、发生后的随访数据、以及和结局相关的协变量；如果条件不允许收集，就必须重新审视策略选择，选一个数据能支撑的策略。

第三个坑：敏感性分析做成「全模型乱炖」。现象是统计师把能想到的分析都跑一遍，列一个几十行的结果表，没有任何组织逻辑。原因是把敏感性分析理解为「多跑几个模型壮胆」。解决方法是：回到估计目标的五个属性，对每个属性提出一个「如果不这么设，结论是否改变」的问题，每提出一个问题对应一套敏感性分析；多余的删除，缺失的补齐，这样审评员看 SAP 时能顺着你的逻辑走，而不是在结果堆里自己找结论。

第四个坑：监管沟通中把「换策略」包装成「敏感性分析」。现象是团队意识到 Treatment Policy 结果不够漂亮，于是把 Hypothetical 策略的结果放在敏感性分析章节里，希望审评员「参考」。这种做法的后果通常很严重：审评员会认为主估计目标定义不稳，甚至要求重新设计。解决方法是：老老实实把不同策略的分析作为补充分析，单独小节呈现，主估计目标就是主分析里确定的那一个，不要动；如果实在想推动某个策略被接受，应该在试验设计阶段和监管沟通，而不是在报告阶段改变呈现方式。

最后一个坑和沟通有关：跨部门对估计目标的理解不一致。现象是临床团队认为「估计目标是统计师的事」，统计团队闭门造车定了策略，揭盲后临床团队才发现结果和自己临床预期对不上。原因是估计目标本质上是临床问题，不能由统计单方面定义。解决方法是：在方案设计早期组织一次工作坊，把五种伴发事件策略用通俗语言解释给临床团队听，让临床医生在「你希望这个事件代表什么」上表态，统计师负责把表态转译成模型假设置于 SAP 中；同时把讨论纪要归档，后续任何改动都走版本控制。

6. 把估计目标变成可代码化的交付物：验证技巧与日常习惯

统计师交付的最终产物不只是 SAP 和结果表，还有可复现的分析代码和清晰的决策记录。在这一章，我分享几个日常使用的高频技巧，它们能让你在这个框架下少走弯路。

第一个技巧是：为每个估计目标建一个代码模板仓库。每次新项目启动时，把估计目标定义、对应分析数据集构建逻辑（比如如何根据策略截断或填补数据）、模型代码和输出格式打包成独立文件夹，并强制团队在项目启动一周内产出第一版。这样做的价值在于，后期想换策略时，改动范围被限制在一个文件夹内，效应量变化可以直接对比，不会牵一发动全身。

第二个技巧是：用模拟数据验证估计目标的统计性质。E9(R1) 允许在方案阶段用模拟来评估估计目标的表现，尤其在比较不同伴发事件策略对偏差和把握度的影响时，这是目前最有效的自检手段。

data sim_data; call streaminit(20240501); do subject = 1 to 500; trt = rand('bernoulli', 0.5); baseline = 8 + rand('normal', 1); * 模拟伴发事件：治疗组发生率低，对照组发生率高； if trt = 1 then p_rescue = 0.10; else p_rescue = 0.30; rescue_flag = rand('bernoulli', p_rescue); * 模拟结局：试验药效果 0.8，使用救援药后额外降低 0.3； effect = -0.8 * trt - 0.3 * rescue_flag; hba1c_change = effect + baseline * 0.2 + rand('normal', 1.2); output; end; run;

这段模拟代码的价值在于：它把伴发事件发生率、效应量、基线相关性都显式建模，你可以用同一套模拟数据跑不同策略的分析，直观看到策略选择如何影响估计值和覆盖率。模拟结果可以作为方案讨论的定量支撑——比如告诉临床团队「如果对照组救援使用率达到 30%，Treatment Policy 策略下检验把握度会从 90% 降到 78%」，这种对话远比抽象的统计讨论有效。

第三个技巧是：验算标准误估计。ddfm = kenwardroger在样本量较小时比默认的 between-within 更准确，不少老程序还在用默认设置；框架下严格执行时，样本量可能因为伴发事件策略而被结构性减少（比如 While-on-treatment 截断数据），这时自由度校正就成了关键。我之前的某个模拟项目X里，组间脱落率差 15%，用默认自由度时置信区间窄了约 8%，换肯沃德校正后审评结论没有改变，但估计的可靠性更说得通。建议所有混合模型统一用ddfm = kenwardroger，SAS 里也推荐这种选择。

第四个习惯是重视元数据：在数据集里保留每个患者的伴发事件发生时间、类型、以及对应策略的标志变量。很多事后分析做不了，不是因为原分析没做对，而是因为数据里没有留下足够的信息重建分析。凡是在 SAP 里写了「如果发生 X 事件，按 Y 策略处理」的，数据集中就必须要有一个变量能区分「该事件是否发生」和「发生后的数据如何处理」，这两层信息缺一不可。这个习惯成本很低，但能让你在后续回答审评问题时不至于抓瞎。

从个人教训来说，我最深刻的体会是：E9(R1) 不是一本教你怎么做统计的书，而是一本逼你在揭盲前想清楚「这试验到底在证明什么」的书。把估算目标五个属性打印出来贴在工位上、每次写 SAP 前逐项过一遍，看似笨办法，但比任何统计技巧都管用。整个分析结束时再回头对着这五个属性检查一遍，你会发现很多审评问题其实在方案阶段就能提前抹平。希望这套执行框架与踩坑清单能帮到你。

本文还有配套的精品资源，点击获取