《医疗软件设计及风险控制》培训笔记

人生理想

第一章 背景
故事从Therac-25开始。
Therac-25是Atomic Energy of Canada Limited所生产的一种完全由软件控制的辐射治疗设备。由于其软件设计时的瑕疵，致命地超过剂量设定导致在1985年6月到1987年1月之间，由于软件瑕疵，导致病人收到比正常剂量高百倍的辐射，在六件已知的医疗事故中，患者死亡或严重辐射灼伤。
1. 事故的总结
此次事故引发了导致Therac-25灾难性后果的深入调查，并引发了软件风险的提出，进而演变成法规要求（如软件标准IEC62304），总结此次事故归咎于一下几点：
- 对软件过度自信。
- 混淆软件的可靠性和安全性
- 缺少防御性设计
- 不现实的风险评价
- 对事故报告调查不充分
- 软件和系统工程实践不充分
- 软件重用缺乏验证
- 界面安全和友好的平衡
1.2 对软件过度自信
制造商对软件过度自信，在设备的风险分析过程忽略了软件部分，仅考虑了硬件故障。而Therac-25很多安全特性被设计为软件实施，比如连锁、过剂量保护。因此没有设计相应的备用系统或保护系统，规避软件的这些功能失效的事件。在使用风险分析模型时，应当包含并识别软件部分的风险。
1.3 混淆软件的可靠性和安全性
1.3.1 可靠性与安全性
可靠性，元件、产品、系统在一定时间内、在一定条件下无故障地执行指定功能的能力或可能性。
安全性（医械），对人、环境和财产造成伤害或损失的能力或可能性。
比如麦克风的使用寿命，出现故障的频率视为可靠性低。麦克风出现尖锐的噪音，或结构设计上扎手，这些问题视为安全性低。
1.3.2 可靠性和安全性的关系
可靠性和安全性的因素可能相互关联，也可能相互独立。
比如血压测量设备如果过高的计算过压保护传感器的信号，将导致设备在低于正常泄压压力的情况下泄压，这不会影响血压测量设备的安全性，但压力不足将影响血压测量设备的可靠性。
1.3.3 硬件与软件的可靠性与安全性
对于纯粹的机械电子系统，其可靠性来自于元器件的老化，其安全性可以近似假定为可靠。
在软件中，可靠性意为对应每一个输入总数返回一致的输出，安全性意为错误的输入将总时输出错误的结果。
1.3.4 Therac-25事件分析
在Therac-25案例中，厂家一直在寻找硬件的原因，忽略了软件的错误输入将引发错误的输出，认为软件是可靠的，并最终导致悲剧发生。应当有效的识别软件系统的可靠性与安全性。
1.4 缺少防御性设计
在Therac-25案例中，
- 软件设计没有包含自检或其他错误检测和错误处理，在用户使用中发生错误后，仍然允许用户继续操作，进而将失效的事件传到至下一个事件，并最终造成重大伤害。应当对系统进行全面有效的可靠性自检的设计。
- 对于设备的运行和正确性，没有提供独立的检查。针对设备的验证仅对于硬件。应当对系统使用中进行全面测试。
- 没有服务和性能运行日志，当出现故障时，不能快速分析根本原因，并最终错误的将问题归咎于硬件的原因。应当设计有效的日志用于故障分析。
1.5 无价值的风险评价
在Therac-25的案例中
- 厂家过度的使用定量风险评价，而在评价过程中却排除了难以定量的分析事件，比如软件需求的缺陷，或对系统安全性有很大影响的事件。当难以定量分析其概率时，应当采用最差情况设计，将其发生概率设定为百分之百。
- 风险分析评价的数据缺乏数据支撑，厂家错误判断为硬件旋转开关的故障，在更换硬件开关后称，风险降低了五倍。实际上该评价没有任何实验数据支撑。风险分析必须基于数据进行评价。
1.6 对事故报告调查不充分
Thereac-25由于用户使用越来越熟悉，操作越来越快，软件反而出现了错误。错误不能重复，维护工程师现场无法重现。厂家没有对该错误深入研究，第二次出现后用户直接关闭对话框继续操作，弹错错误后提示结束放疗，用户关闭后，设备并没有停止，对病人造成伤害。
当出现事故时，没有对事故的根本原因进行分析，并让用户人为不是严重问题，当再次出现后，用户的“自信”操作引发了严重危害。
当问题、故障或事故时，应当对事故进行充分调查分析，找到根本原因。如果无法识别，应当完善日志的设计，使问题暴露。
1.7 软件和系统工程实践不充分
1.7.1 缺少软件需求
在设计开发过程中应当建立软件需求和软件设计规格，这可能引发系统实现的功能与系统目标发生偏差，并产生新的风险。
应当在设计开发前充分识别和定义有价值的软件需求，这也是IEC62304中的要求。
1.7.2 缺少软件质量控制
缺乏测试，或只进行系统性测试，缺乏单元和集成测试。缺少这些工程实践的节点，将导致系统存在大量未验证路径，进而引发新的风险事件。
软件开发过程应当符合ISO13485质量体系要求，包括配置项管理、风险管理、版本管理、缺陷管理、追溯分析等，及IEC62304中单元测试、集成测试的要求。而不仅仅进行系统测试。
其中，配置项的目的是为了防止以外的修改。缺少配置项管理将极大可能出现文档的意外修改和版本失控。
追溯分析的目的是为了确保系统设计过程有效。缺少追溯分析将导致系统设计不满足最初的设计需求，最终无法通过确认。
1.7.3 开发人员与测试人员缺乏协作
开发过程中，软件工程师和测试工程师没有充分协作，软件错误提示含糊不清，使测试工程师无法充分验证。开发人员设计满足需求的方案，与测试人员沟通其可验证性，为测试人员定义测试用例分析提供必要支持。
系统测试和单元测试有可能分开进行，或单元测试或集成测试可能由开发人员进行，测试人员不局限于系统测试人员。
1.8 软件重用
在Therac-25的实践中，Therac-25是对Therac-20的升级改进，其中采用了大量Therac-20的方案和现成模块，实际上Therac-25中部分原来由硬件进行的功能修改为软件，而忽略了这部分变化带来新的风险，错误的认为现成软件已经过大量测试非常安全，导致缺乏Therac-25安全性分析和测试。
在不同的系统中，软件导致的危害可能不同，因此在不同的系统下应当重新进行风险分析，不能因方案重用而忽略。
1.9 界面安全和友好的平衡
1.9.1 性能与验证
为了加速数据输入，程序设计者可能忽略数据输入后的数据检查，而是假定使用者会对数据的有效性进行检查。输入错误的事件可能引发严重的危害，应当对其进行风险分析后确定是否需要软件进行输入验证。
1.9.2 安全性交互设计原则
让设备进入安全状态的动作更容易，而进入不安全的动作更困难。比如急停开关应当设计到便于操作的位置。
2 测试
2.1 测试用例的案例
输入三个值、判断由这三个值组成的三角形是等边三角形、等腰三角形还是普通三角形。设计事件测试该程序。
现场有3~4人（包括我）发言，并最终形成一份测试方案：
- 人机交互输入的有效性检查，判断是否是数值，且不为负。
- 是否超出数值变量的存储范围。
- 遍历三角形分类算法的所有路径
- 输入三个数值无法构成三角形的判断
总结一下，一个简单的场景都需要3,4个人出方案，如果是复杂的方案无法通过人来设计完美的测试方案。
2.2 对测试错误的认识
有人认为对软件进行测试，可以消除软件的缺陷。实际上存在以下两种情况：
- 不可能设计绝对意义上完美的测试用例。
- 凡是有人参与的活动，都会存在缺陷。
因此，测试无法找到所有的缺陷，测试全部通过不意味着没有缺陷。
3 医疗软件
所有医疗软件设计过程种的所有活动都是在对软件的安全性和有效性建立信任。


缺陷预防：避免缺陷被设计到软件种。通常涉及需求分析、测试、追溯确认等过程。
缺陷消除：发现软件缺陷并消除缺陷。通常涉及日志的涉及、故障分析等过程。
第二章 医疗软件风险分析及控制
1 危害模型
风险概率有两种，发生概率P1，出现伤害的概率P2。软件风险大多数属于P1，软件不会直接造成危害。
单纯对软件进行风险分析是没有意义的，必须结合系统，参考危害模型来分析风险。


2 分析理论
2.1 软件风险包含于系统风险
软件风险分析不能和器械整体风险分析隔离，因为
- 软件本身不是危险，是导致危险情况发生的原因（事件）
- 软件失效影响的是风险因素的P1。
- 在器械风险分析过程中，软件风险Ps一般设定为1。
- 一般采用FTA或FMEA方法确定P1
- P2应考虑不同等级伤害发生的概率。
注：底层软件亦属于软件，同样需要进行风险控制。
2.2 软件可靠不等于软件安全
正如第一章内容描述，对于某一个错误的输入数据而言，软件能够正确的执行并得到可靠的结果，但该结果并不安全。
2.3 概率与风险
P1的概率包括初始事件的概率、过程事件的概率。
P2的概率包括不同危害的概率。
风险的概率为不同等级下对应的P1 x P2。


3 基于故障树确定P1
3.1 故障树
从顶层事件往下分解，分解到软件。如果软件还有前置子系统，如果充分隔离则可以不考虑。当然，也可以继续往下分解分析。
在危害模型中，Pb一定是在Pa发生前提下的概率，而不是Pb单独的概率。如果由于软件故障导致后续事件必然发生，则P1就是1。


故障树的方法一般不适用于复杂情况。如Pb既有前置事件，又有自身概率。
所有节点的概率必须有数据支撑，否则应当采用最差情况设计。
故障树中的标记内容包括：
- 根节点表示危险情况。
- 其他叶节点表示事件，每个叶节点标记其发生概率，软件事件概率一般为1。
- 使用无箭头连线连接条件符、事件和危险情况。


表示与条件关系，其上根节点概率为其叶节点相乘。


表示或条件关系，其上根节点概率为其叶节点相加。
3.2 自动除颤器故障树案例


例图中SW does not sense VF应该还有前置事件，内容仅作参考。
4确定P2
4.1 分析方案
相对于P1，P2的概率更难以确定，例如冬天暴露在感冒病毒环境下，可能会感冒，有人只是打喷嚏，有的人发烧，有的人进ICU。
P2伤害等级分为5级。如果不进行分析，而采用最坏情况分析，直接把P2当做最危险：死亡。这种方式成本太高，应当尽可能考虑发生概率的因素。
一般采用以下两种方法确定P2：
- 类似产品的临床使用数据，可以通过检索期刊杂志、新闻报道等方式获取数据。
- 临床专家的输入，一般邀请5名临床专家进行评估。
可以通过Fda、英国药监局，mhra等组织发布的官方数据，或实验数据作为P2数据支撑。如果产品没有国内产品，没有参考，P2建议临床专家（5个）输入概率。综合考虑确定P2概率。
4.2 案例
对于伤害“持续性房颤”，通过文献检索或事后数据库搜索，有14篇文献报道类似产品导致持续心房颤动，总计79例，其中：
- 造成死亡（catastrophic）67例
- 永久性损伤或生命威胁（critical）8例
- 需医疗处理的暂时性损伤（serious）4例
- 不需要医疗处理的损伤（minor）0例
- 无损伤（negligible）0例
4.3 辅助诊断设备的P2风险评估
如果由设备直接导致伤害，则考虑这个过程的直接概率。
如果设备到伤害之间还有其他外部的非必然事件节点，则不需要考虑。
例如体外诊断设备的检测结果需要医生凭借经验下诊断结论，而不是直接由设备下诊断结论及治疗方案，因此设备的直接伤害。
5 分析案例


风险分析报告P2部分应按以下方式填写：


风险分析报告P1部分应按以下方式填写：


6 风险控制
遵循ISO14971风险控制措施优先级
6.1 本质安全设计
使风险发生的概率接近0或为0。
比如血液加热器的设计中，加热装置在正常和故障条件下最高温度都不能超过37℃，采用硬件设计保护措施，使之本质安全。
6.2 预防措施（影响P1和P2）
交叉校验或边界校验关键计算结果，比如输入超范围的数据。
校验和或循环冗余校验通讯数据，防止器械对错误数据作出反应。
6.3 纠正措施（影响P1和P2）
当CPU没有重置看门狗计时器时，CPU应当重新初始化。
6.4 缓和措施（影响S）
血液注射器，过量控制也算是减轻严重性，因为终止了过量，过量会随着计量增大而出现更严重后果
可以通过特殊方式使CPU挂停，防止注射泵进一步过量注射。
7 特殊说明
7.1 概率的说明 (IEC62304)
Risk is considered to be a combination of the severity of HARM and the probability of its occurrence. However, no consensus exists for a method of quantitatively estimating the probability of occurrence of a software failure. When software is present in a sequence or combination of events leading to a HAZARDOUS SITUATION the probability of the software failure occurring should be set to 1. when it is possible to estimate the probability for the remaining events in the sequence) as it may be if they are not software) that probability can be used for the probability of the HAZARDOUS SITUATION occurring interesting figure B
有直接导致软件事件的其他事件的概率，那么以该事件作为软件的概率。有软件的概率不好测量则设置为1。
7.2 数据支撑的要求 (IEC62304)
Estimates of probability of HAZARDOUS SITUATION lead to harm generally require clinical knowledge to distinguish between hazardous situations where clinical practice would be likely to prevent harm. And hazardous situations that would be more likely to cause harm
P2的概率需要有临床的支撑。
7.2 其他
软件风险分析参见AMI TR32。
软件可以是起始事件，也可能是中间事件，软件不可能单独分析。
IEC62304种的风险分析模型：


胰岛素注射设备的例子：



第三章 医疗软件安全分类
1 分类原则
基于软件失效对病人、使用者或其他人造成伤害的风险，进行分类，一般严重伤害包括以下集中情况：
- 威胁生命
- 身体功能或结构永久损伤
- 需要医疗或手术介入防止永久性损伤。
分类时需要考虑软件系统以外意外的风险控制措施。如果风险分析外还有保护措施，可以降低风险等级。
风险安全分类是软件分析的结果，而不是主观判定。
进行软件风险分析时，假定概率为100%，并认为：
- 所有的软件失效都是系统性的设计缺陷。
- 没有可靠的方法统计软件失效的概率。
如果设备的结果直接引发误诊及伤害，不需要医生等其他因素参与，为C类。例如AI心电图系统代替医生诊断，直接出具诊断结果和治疗方案。
如果导致事件链还有其他因素，比如医生通过经验规避，这种情况属于B类。他会影响P2，但不会影响P1。
又比如体温计，测量之后有其他渠道，比如手摸等确认。所以B类。
2 分类方法
判断是否由于软件过错导致危险情况，如果没有则为A类。
测量和评估软件引发的风险，并进行风险控制。
判断软件失效风险是否可以接受，可接受则为A类。
判断是否带来严重伤害，如果轻微伤害，则为B类。
其他情况均为C类。


3 案例分析
3.1 硬件失效案例分析
下表中，Harm.2和Harm.3是由硬件失效引起的两种危害，其中最高概率的严重程度分别为Serious（60.4）和Minor（46.8），因此选择最高的情况（Serious）


3.2 心电显示系统案例分析
整个系统包含固件和应用软件两个系统，其中Fireware属于C类，Software application属于B类。


4 隔离
4.1 影响因素
如果整个系统中等规模，可以当作高等级处理。除非系统非常大，则可以考虑划分子系统，隔离划分，采用不同的等级。
不同安全等级的软件隔离的因素包括：
- 共享RAM
- 共享外围器件
- 共享处理器时间
- 相互通讯
4.2 常见隔离方法
通常使用以下方法隔离多个系统：
- 独立处理器
- 硬件内存保护
- 避免低等级软件向高等级软件发送数据
- 共享期间事件防护
4.3 案例
例如血液透析设备，主要功能使抽血离心，之后将血浆注射回病人体内，可以隔离为两个系统，分别为：
控制系统，配置独立cpu，抽、离、注，B类
保护系统，配置独立cpu：识别到空气或气泡则钳住管子，C类
第四章 医疗软件设计过程
1 “V”生命周期模型
包括产品需求、软件需求、设计、实现、单元和集成测试、软件需求确认、系统测试。


其中前三个活动的主要目的是预防缺陷，明确要做什么。
后三个活动的主要目的是纠偏，发现和消除缺陷。
2 过程要求 （IEC62304）
下图为IEC62304中不同等级软件对应的开发过程要求。


2.1 策划阶段
策划的目的是最大程度避免设计错误。软件开发策划是一个渐进明细的动态过程。
策划阶段要求以下内容：
- 软件开发计划（ABC）
- 软件开发标准、方法和工具策划（C）
- 软件集成和集成测试策划（BC）
- 软件验证策划（ABC）
- 文档策划（ABC）
- 配置项管理策划（ABC）
- 受控的支持项（BC）
- 识别和避免通用软件缺陷（BC），IEC/TR 80002-1附录提供了针对不同的应用领域提供了通用的软件缺陷内容供参考，在规划阶段使用该清单核查。
2.1 需求分析阶段
软件失效的来源70%来自需求，不充分和需求识别错误是软件缺陷的主要原因。软件需求分析应定义软件必须实现的功能，而不是定义怎么实现。
2.1.1验证需求
需求必须经过验证，包括：
- 有效性验证，软件需求满足真实的系统需求，而不是想象出来的。
- 一致性验证，软件需求之间不能互相冲突。
- 完整性验证，包含所有的需求和限制。
- 可验证性，软件需求应可验证。
由于需求转化为开发方案时通常会出现不明确的情况，因此软件需求的评审应当包含开发人员，确认正确理解需求。
软件需求评审和方案评审的策略相同。
2.1.2 需求规格书的要求
- 避免复合需求，例如“当三个连锁传感器处于非活动状态时，设备应开始处理样本，当连锁传感器处于活动状态时，出发报警。”其中出发条件应当增加“同时”，活动状态检查应当明确连锁传感器数量，应当明确报警方式（比如什么样的声音，什么样的文字等）
- 避免负需求，例如“泵速不能由用户校准”，但没有写明水可以校准。
- 可测试性，例如“药物应该以1ml/min的速率注射”，精确值是无法测试的，必须增加可接受范围，比如正负1。
2.1.3 良好的需求用例


2.2 设计阶段
应当按照最小检测单元进行分解，得到所有的功能模块。
例如心电采集系统的设计结构图如下：


2.3 测试阶段
2.3.1 测试和验证
测试的目的是尽可能找到软件中的错误，而不是通过测试证明软件没有错误。
应当制定有效的测试和验证计划：
- 测试目的
- 测试方法和工具
- 可接受标准
- 测试人员和日期
2.3.2 常用方法
常用方法包括：
- 静态测试，比如代码审核
- 动态测试，比如黑盒、白盒测试。
2.3.3 测试用例的要求
进行系统测试用例设计时，测试条件和记录应当客观，比如：
- 操作不明，验收标准模糊不清：按下开关，检查压力
- 验收标准是模糊不清：按下红色开关，检查压力是不是好的
- 没有验收标准：按下红色开关，记录压力值
- 缺少记录的操作指引：按下红色开关，检查压力值是否在59~70PSI。
- 较好的测试用例：记录压力值，检查压力值是否在59~70PSI。
2.3.4 单元测试
单元测试是所有测试中最困难的，需要考虑转移、语句和路径的覆盖。
循环复杂度CC = E – N + 2，其中E为边数，N为节点数。
测试事件设计CC越高，表示测试路径越多，但这并不意味着测试的质量好。因为测试深度可能不足。
一个考虑测试深度的例子：


2.3.5 集成测试
集成测试主要针对内部和外部交互的部分，通常包括：
- 安全关键功能
- 外部通讯协议
- 子系统到子系统的交互
- 用户交互
测试人员应当记录测试方案及结果，以便能够重复测试。
2.3.6 系统测试
系统测试一般采用黑盒测试方法，测试内容包括：
- 功能
- 极端条件下的反应
- 恢复程序的有效性
- 可用性
- 于其他软件的兼容性
2.3.7 常用软件测试方法
一般常用的软件测试方法有：
- 等价类测试
- 边界值测试
- 计算及准确度测试
- 错误猜测测试
- 随机测试
2.3.8 测试案例
以下为使用等价类测试和边界值测试的案例，数据输入区域规定，有效的数据输入是从1到10的整数，如何设计测试事件。


2.4 追溯要求
追溯是对系统功能实现的确认，通常使用追溯表进行记录。

山外青山更高一筹

不错，学习了

青权

大佬，请问可以问一下胰岛素注射设备和自动除颤器的故障树图是出自哪里嘛？非常感谢！

正义不会缺席

培训课程提供的案例，具体产品信息不了解，抱歉哈！

城市森林公园

哦哦哦，同样感谢！