本文速览

1. 1985至1987年，Therac-25放射治疗机因软件Bug导致6名患者遭受超剂量辐射，其中3人死亡。

2. FDA调查发现，44%的医疗器械召回根源在设计缺陷，由此催生了“设计控制”法规。

3. 理解这段历史，是读懂ISO 13485、IEC 62304等全球法规底层逻辑的关键。

大家好，我是Alice。

欢迎来到MedReg Lab。这是我的第001篇法规研究手记。

在这个Lab里，我们不满足于背诵条款，而是一起解剖法规背后的逻辑、历史和那些塑造了规则的“关键时刻”。每一份设计历史文件（DHF）的模板背后，每一条看似枯燥的条款深处，都可能藏着一个惊心动魄的故事。

今天，我们就从一个价值数条生命的软件Bug开始，追溯“设计控制”的起源。

一、Therac-25：当代码成为凶器

1985年6月，美国佐治亚州。

61岁的乳腺癌患者Katie Yarbrough躺在Therac-25放射治疗机上，准备接受常规的电子束治疗。几秒钟后，她感到一股难以忍受的灼烧感穿透肩膀——“好像有人把滚烫的咖啡泼在我身上。”

事实上，她遭受了高达20,000拉德的辐射剂量。而一次典型的治疗剂量，应该在200拉德左右。

另一位患者Ray Cox则将这种感觉描述为“强烈的电击”，他尖叫着跑出了治疗室。几天后，放射性烧伤和中毒症状开始显现。

这不是意外，是系统性的谋杀。凶手是软件。

Therac-25是当时加拿大原子能有限公司（AECL）推出的产品。它本质上是一款双模式直线加速器，提供两种放射治疗模式：

直接电子束治疗：通过磁体在治疗区域上扫描高能电子束。

Megavolt X射线治疗：将高电流电子束与靶相撞产生宽X射线束，经过滤波器后用于治疗。

此外，它还有第三种“场光”辅助模式，仅通过可见光照射帮助患者定位，本身不产生辐射。

事故的根源，就出在这两种治疗模式和场光模式之间的软件切换上。为了降低成本，设计者做了一个致命的决定：移除所有硬件安全互锁装置，完全依赖软件来控制安全。

他们相信代码。

然而，正是这段代码里潜伏着一个幽灵般的Bug。当操作员在特定时间窗口内快速按下特定的非标准击键序列时，软件会进入一个“竞态条件”（Race Condition）。结果是，高功率的X射线模式被悄然激活，而治疗台上却没有安装相应的金属靶和过滤器。

患者暴露在完全失控的、致命的高能射线下。

更可怕的是，当故障发生时，操作界面只显示一个冰冷的代码：“MALFUNCTION”，后面跟着一个1到64之间的数字。操作手册没有解释这些错误代码的含义，更没有提供任何处理流程。手足无措的操作员，只能按下“P”键覆盖警告，继续执行。

患者暴露在完全失控的、致命的高能射线下。辐射剂量达到正常值的约100倍。

从1985年6月到1987年1月，Therac-25在美国和加拿大共造成至少6起严重超剂量辐射事故，3名患者直接死亡，多人遭受严重放射性灼伤。其中一名患者Robert W. Fowler，在得克萨斯州的一个诊所接受治疗后，左肩和颈部组织大面积坏死，在痛苦中挣扎数月后离世。

FDA的调查结论冰冷而清晰：这是纯粹的设计缺陷。这台机器的生产过程完全合规，出厂检验100%合格。但产品在被画在图纸上的那一刻，就已经“注定”了悲剧。

二、44%：一个改变行业走向的数字

Therac-25并非孤例。

几乎在同一时期，早期植入式心脏起搏器开始引入软件控制，但同样缺乏严谨的开发流程。多款起搏器因固件Bug，在特定触发条件下会“死机”或输出错误脉冲。比如某款起搏器在电池电压降至某个阈值时，会意外进入“复位模式”，停止起搏——对依赖它的患者而言，这意味着心脏停搏。

FDA开始系统性地追溯：这些上市前明明通过了检测的设备，为什么到了患者身上就出了问题？

结果令人震惊。

他们对1980年代后期的医疗器械主动召回事件进行了根因分析，发现高达44%的召回，其根本原因都可以追溯到设计阶段。不是生产失误，不是原材料问题，不是运输损坏——而是产品在被设计出来的时候，就已经错了。

这个发现触发了一场深刻的范式转变。

在此之前，医疗器械行业的质量管理思维，本质上是一种“事后检验”模式：我生产了100个，把次品挑出来，剩下的就是好产品。这种思维天然地假设：设计本身是没有问题的。

但数据证明，事实恰恰相反。

与其投入海量成本去检测、返工、召回，不如在设计源头就把问题规避掉。正如质量管理大师朱兰（J.M. Juran）所主张的：“质量是设计出来的，不是检验出来的。”

然而，理念归理念。要让整个行业付诸行动，需要“牙齿”。

三、FDA拔剑：设计控制入法

Therac-25的调查报告、起搏器的固件灾难、44%的召回数据——这些血淋淋的证据汇聚在一起，最终推动了一个决定性的立法动作。

1990年，美国国会通过了《医疗器械安全法案》（Safe Medical Devices Act），大幅强化了FDA对医疗器械的监管权力。其中一项关键要求是：制造商必须建立上市前设计控制的程序。

经过数年的细则打磨，1996年，设计控制（Design Controls）被正式写入美国联邦法规21 CFR Part 820.30，即质量体系法规（QSR，Quality System Regulation）。

这是全球医疗器械史上，首次将“如何做设计”变成法律的强制要求。

它不再只是一个建议，而是必须遵守的规定。设计控制的每一个要素——设计计划、设计输入、设计输出、设计评审、设计验证、设计确认、设计变更——都被明确定义，并强制要求记录在设计历史文件（DHF）中。

是FDA最先让设计控制有了“牙齿”。

当然，理念并非凭空而来。质量管理学界和系统工程领域的先驱们，早已论证了“需求追溯”和“设计评审”的价值。但将此理念系统化、强制化、并写入法规的第一推手，确实是FDA。

四、涟漪：从QSR到全球共识，再到软件专属标准

FDA的这一立法动作，掀起了一场全球性的涟漪。

2003年，国际标准化组织（ISO）发布了ISO 13485:2003《医疗器械 质量管理体系 用于法规的要求》。这一标准的核心第七章“产品实现”，几乎完整地吸纳了FDA设计控制的框架与逻辑。

从此，“设计控制”不再只是“美国要求”，而成为了全球通用语言。

你今天翻开任何一份主流市场的法规，都能看到它的影子：

中国NMPA《医疗器械生产质量管理规范》：在设计开发章节中，对输入、输出、评审、验证、确认的要求一应俱全，且体考老师对“可追溯性”的审查日益严格。

欧盟MDR：在附录IX至XI的符合性评价程序中，设计控制思维渗透在技术文件审查的每一个环节，尤其是与临床评价、风险管理文件的交叉。

MDSAP（医疗器械单一审核程序）：以ISO 13485为基石，将设计控制作为五大审核模块之一，一次审核覆盖美国、加拿大、澳大利亚、巴西、日本五国的要求。

但故事到这里，还没有完。

Therac-25事故的深度调查，还暴露了一个更具体、更致命的问题：软件工程本身被系统性地漠视了。

调查委员会发现，AECL的软件代码没有经过独立审查；软件与硬件的组合测试从未在医院组装前进行过；工程师盲目重用了旧型号的软件代码，却移除了那些型号中赖以保命的硬件互锁——这是一种典型的“货物崇拜编程”（Cargo Cult Programming），即不理解原理地盲目模仿或复用旧代码。更基础的问题是，软件用汇编语言编写，变量标志通过递增而非固定赋值来设置，偶尔发生的算术溢出会导致标志归零，从而绕过所有安全检查。

这些发现，直接指向了一个空白：医疗器械行业缺乏专门的软件开发生命周期标准。

于是，针对Therac-25相关事件的教训，国际电工委员会（IEC）创立了IEC 62304——医疗器械软件 软件生命周期过程。这一标准为医疗设备软件的开发、维护、风险管理、配置管理和问题解决建立了全生命周期的框架，并对“使用未知谱系软件（SOUP）”提出了具体的管控要求。

从此，医疗器械的软件，终于有了属于自己的“设计控制”。

五、对今天的我们，这意味着什么

讲这些故事，不是为了怀旧。是因为到今天，每一份设计开发文档，每一行软件代码，都在承载这段历史的重量。

当你被审核老师反复追问“这条需求的输出在哪里”时，背后是44%的召回率。

当你在DHF中吃力地补充追溯矩阵时，背后是Therac-25操作员无法撤回的那个按键。

当你对着IEC 62304的条款，逐项核对软件架构、单元测试和遗留软件分析时，背后是那行冰冷的“MALFUNCTION”和手足无措的按下“P”键的手。

作为医疗器械行业的从业者，理解这段历史，至少可以带给我们三点启示：

1. 需求追溯不是为了应付审核，而是为了延续安全

设计控制的灵魂是“输入到输出”的可追溯性。它确保设计输出的每一个细节，都能追回到用户需求和预期用途。这不是形式主义，而是用系统方法，把“软件Bug杀人”这类悲剧的概率降到最低。

2. 风险思维必须前置到设计阶段

ISO 14971风险管理不是一份独立文档，而是与设计控制深度交织。Therac-25的教训恰恰在于，它的“安全机制”是软件的一部分，而不是独立的保护层。今天的设计失效模式分析（DFMEA），本质上就是把这堂课写进了流程。

3. 理解不同市场“口音”的底层，才能游刃有余

不论是FDA对DHF的“考古式审查”，还是欧盟对临床评价与设计输入链路的关注，抑或是NMPA对追溯性的紧追不舍，以及全球统一换版的IEC 62304对软件生命周期的要求——它们的底层逻辑是一脉相承的。掌握了这个底层逻辑，我们在面对不同市场的差异化要求时，就不会死记硬背，而能触类旁通。

这，也是MedReg Lab未来想与你持续探索的方向。

后记

2010年，《纽约时报》在一篇关于医疗软件安全的调查报道中，将Therac-25案称为“软件工程的切尔诺贝利”。

它提醒着每一位医疗器械从业者：我们手中的需求规格书、风险管理报告、验证方案、软件架构文档——这些看似普通的文件，最终连接着的，是手术室里的一条生命，是诊所里一个期待康复的人。

法规的严肃，源于生命的脆弱。

这也是MedReg Lab存在的意义。

感谢你读到这里。这是Lab Report#001，一份关于设计控制起源的研究手记。如果你觉得有收获，欢迎转发给一位同行。也欢迎在后台留言，告诉我你还想探索哪些法规背后的故事。

我是Alice，一名RA，也是三只猫的铲屎官、一个撸铁七年的长期主义者。这里是MedReg Lab，我的法规研究手记。

下次见。