设计一台医疗器械需要承担极大的风险。以下五条建议有助于设计安全至上的医疗器械，同时避免出现对开发过程不利的常见错误做法。
在20世纪80年代，由于简单的数据输入错误，导致六名患者接受Therac-25放射治疗系统的辐射量超出了规定范围10.000%。该错误导致了至少有3名患者死亡。该事件证明，医疗器械制造商承担的风险极高。过失行为不仅导致人员伤亡，而且常常使企业面临官司和永无休止的诉讼。如今，臭名昭著的Therac-25事件提醒人们设计医疗行业的器械时必须慎重，开发过程除了符合基本要求外更应以安全至上为准则。本文将概述设计安全至上的医疗器械中的几大要素，并处理对开发过程不利的一些最常见错误做法。
- Go Beyond the Standards
美国规定安全至上项目的开发必须遵守软件开发生命周期（SDLC）标准。医疗器械SDLC对应的标准是IEC 62304。其中列出了详细的记录和监控流程，几乎覆盖软件规范、设计、编码和测试的所有方面，有关监督、合规和认证的标准也异常严格。
为了确保软件更安全，设计人员需要超越需求认证标准，在各级开发过程中谨慎采取系统和增量步骤。安全复杂的系统只能建立在安全、简单的原则之上。当复杂系统失控时，只能按照基础级合规标准确保安全性。
- Reduce Design Complexity
对能在预算紧、时间短的情况下开发出系统的经理，企业通常给与奖励。但强调速度、压缩成本也助长了偷工减料、造假数据和忽视小警示等现象。周转速度的重要性应该低于质量。
不能只重视时间和成本，只有提高安全性才有望缩减开支。设计复杂性降低时，通常实现的改进最大，包括选择性地使用更高级的工具，例如功能和类型安全编程语言，以及模型驱动开发（MDD）。对于安全至上的系统，C和C++语言很流行，但也让人生畏。流行的原因是，它是各种工具使用的语言，可供有经验的开发人员使用。让人生畏的原因是，进行不安全指针和直接内存管理时，它造成了几乎无法解决的测试设计问题。
程序员的脑容量是有限的，因此在给定设定下，能解决的问题范围取决于大脑所处的抽象级别。强大的工具功能和快速的反馈有利于更快地生成系统，同时改进各种可构建的系统。
- Requirements Must Be Testable
系统要求的设置流程本身是一个巨大的错误来源。随着系统越来越复杂，样板文本会按照原设计进行制作或“调整”。一切运作顺利时，会及早发现并处理或删除这些错误；流程失败时，将运行一个无意义的代码，跟踪不适用的要求。
需要尽早确定利益相关者。通过代码可以追踪相关要求，对于深入了解这些利益相关者需求的个人，也需要对其要求进行追踪。相较于其他描述内容，进行动态、灵活的开发、采用、审查和要求拒绝过程对系统安全性的影响更大。
- Design to Pass Every Test
对于高效可靠的软件来说，全面的集成式内部测试设计与有效的要求同样至关重要。这恰恰也是开发早期最容易被忽略的要素，如果不从头开始有效地重写代码，就无法将其添加到现有的代码库中。
代码设计中必须包括有效的测试设计。在写第一行代码前，必须在前端使用测试范式评估语言、框架、模拟器和其他工具套件。
- Ignore Mean Time Between Failure
最后，让我们来解决故障计算之间平均时间的谬误。简单来说，讨论软件时应该禁止谈论这个问题。有关这些陈述的数学基础的假设本身就太过主观，容易出错，因此我们应该假设所有精心构建的图表和图形无任何意义。
首先应当假设任何进程和系统都有可能出现故障。构建完整的测试套件不能只依赖一个团队，故障修复也必须依靠多个团队提出各种不同意见。独立的监督过程，特别是将其与冗余、独立的硬件传感器阵列结合使用后，可以使技术性能优异，故障模式少。由于“软件可以做到”，因此要避免去除机械和电子防护措施。
The Lesson
启示
任何一个大型工程缺陷几乎不会造成像Therac-25这类造成重大伤亡的事故，但整个设计过程中的小失误不断累积后却会造成安全性问题。对先前模型的过度自信、在现实环境中缺乏测试以及不愿意相信系统会发生故障，这三者均会导致机器在临床使用时完全失灵。开发团队无法预测并防止此类错误，这使人们意识到，设计安全至上的软件时即便是最小的步骤也非常重要。通过对设计流程的各个里程碑节点以及超出基线标准的测试方案的深思熟虑，可以将这样的悲剧扼杀在摇篮里，而不是等伤害发生后才追悔莫及。