第2部分：
医疗器械质量体系确认软件
1 范围
适用于：
?质量管理体系中所使用的软件；
?生产和服务提供过程中所使用的软件；以及
?用于要求监测和测量的软件。
不适用于：
?作为医疗器械组件、部件或附件的软件，或
?本身为医疗器械的软件。
2 规范性应用文件
3 术语和定义
?ISO在线浏览平台：http://www.iso.org/obp/。
4 软件确认探讨
4.1 定义
4.2信心建立活动：工具箱内的工具
工具箱内的工具（参见表A.1至表A.5）包括软件生命周期内完成的各项活动，可降低风险并且建立信心。
4.3批判性思维
附件C给出的示例研究，展示了批判性思维在各种情况下医疗器械质量体系所用软件的确认情况，包括不同复杂程度、不同谱系和不同风险等级。
5软件确认与批判性思维
5.1 概述
在医疗器械质量体系软件的整个生命周期，需要采取适当的控制措施，确保软件按预期运行。融入批判性思维并运用选定活动建立信心，使软件有效状态的建立和维护得到实现。图1为典型活动与控制措施的方案视图。图中的典型活动和控制措施从做出决定那一刻开始，到某个过程实现自动化、直至软件退役或不再是医疗器械质量体系生命周期的一部分为止。虽然图1描绘的是一个序变模型，实际上，此过程在元素定义、风险识别和批判性思维应用过程中都具有迭代性。
医疗器械质量体系软件
图1——生命周期控制
在生命周期的开发阶段，执行风险管理和确认计划制定任务，以收集信息，并驱动软件在以下四个方面做出决策：
?所采用的工作量以及对文件记录和可交付成果的审查；
?文件记录与可交付成果的内容范围；
?工具箱工具的选择和工具应用方法；
?工具应用方面的工作量。
这四个领域决策的主要驱动因素即是过程风险，也是软件风险。但是，其他驱动因素也可能影响决策，包括软件和过程的复杂性、软件类型和软件谱系。
在生命周期的开发阶段，风险管理和确认计划制定任务用于确定应用于软件的适当工作量，并确定建立信心使用哪些工具。这种方法可以完成适当的增值活动和确认任务。这是建立某种经确认状态的基础。这些活动和任务完成后，工具及其相关结果将即刻在确认 告中引用，作为对软件确认结论的支持。
部署完成后，软件将进入软件生命周期的维护阶段。在此期间，软件将按照业务需求或法规要求变化下达的指令进行监控、改善和更新。变更控制活动采用的概念与在生命周期的开发阶段所采用的初始方法的概念相同。然而现在评估变化针对的是变化在初始开发期间对预期用途、失败风险、风险控制措施的影响以及对软件本身任何功能的影响。
退役阶段是通过删除过程或替换过程正在使用的软件来去除软件的行为。
图1中显示的活动反映了软件生命周期主要控制活动。其他工作流包括项目管理、过程开发、供应商管理（若适用）以及可能的其他工作流，具体取决于正在实施的软件。
图2描述了其他工作流活动中的软件生命周期控制活动和批判性思维。关键的思考活动出现在迭代风险分析和确认工作流中。在组织的业务模型中对这些工作流进行清晰、正式的定义非常重要，以确保某个程序从业务和监管两个角度妥善管理软件。
注意：在使用术语“develop”或“development”时，“develop”或“development”系指开发软件某一经过确认的状态。
图2——生命周期控制工作流
图2中描绘的各种颜色对应于图1中整体方法过程图中的生命周期部分。红色虚线表示某一个活动输出的信息，而该信息为另一活动提供输入，或在另一活动中有助于推动决策。该图展示了在完成需要输入的活动之前，获取输入信息的需要如何推动活动排顺。值得注意的是，所有活动都会完成，不受正在实施的软件的大小或复杂程度的影响。但是，对于更大或更复杂的软件，此类活动很可能是分离的；而对于更小或更简单的软件，许多活动则会组合在一起或同时完成。
总之，批判性思维方法描述了一种系统方法，用于在各种工作流中识别和包含适当的信心建立活动或工具，以支持软件在发布时得到确认，并且在软件退役之前将保持确认状态的结论。
以下子条款提供了图1中描述的生命周期控件中的每个方块的其他详细信息。子条款使用图2中所示的迭代风险分析、确认和软件活动的工作流描述，提供包含批判性思维的各种决策点以及各种决策驱动因素的透视图。
5.2确定软件是否外在范围内
5.2.1记录软件过程和使用的高级定义
确定是否认为软件用于医疗器械质量体系的第一步是记录该软件的过程和使用的高级定义。在很容易知道软件处在范围内并且有人已经在着手定义软件详尽的预期用途时，此活动可能看起来价值很小。而在此类假设不太清楚的情况下，记录过程和使用情况可以明确确定该软件是否在范围内。此外，对于已确认超出范围的软件，此类活动能够找出导致软件超出范围的原因。
5.2.2监管使用评估
a)软件的故障或潜在缺陷是否影响医疗器械的安全或质量？
b)软件是否自动执行或按照法规要求执行某项活动（特别是医疗器械质量管理体系的要求）？示例可包括捕获电子签名和/或记录、维护产品的可追溯性、执行和捕获测试结果、维护CAPA、不合格、投诉、校准等数据日志。
5.2.3与医疗器械监管要求无关的过程和软件
当过程或软件包含超出医疗器械法规要求的功能时，宜进行分析，确定认为该软件的哪些部分处在范围内，哪些部分不在范围内。应根据软件各个组件、模块和数据结构之间的集成程度以及组织的合规性需求，使这些决策合理化。对于用于支持质量体系的软件（例如：复杂企业资源规划（ERP）的大型软件），这种合理化尤其重要。ERP软件能够包括非医疗器械监管过程（如：会计和财务等）的功能。但是，这种功能对于商业运营能够至关重要，并且必须满足某些政府要求（例如：萨班斯——奥克斯利法案的要求）。
5.3开发阶段
5.3.1制定确认计划
在应用批判性思维时捕获的确认计划制定活动的第一部分，使用过程风险分析的输入（见附件B）确定宜用于文件编制的工作量的基础，并驱使软件从工具箱的“定义”部分选择工具（见表A.1至表A.5）。第二部分使用软件风险分析的输入，驱使软件从工具箱中选择实施、测试和部署工具。执行完毕，软件活动和确认状态随即建立，而且确认的证据在确认 告即刻形成。
5.3.2定义
5.3.2.1定义方块要求
在定义块内完成的活动包括过程的定义、该过程内软件预期用途的定义，以及基于该过程内所确定的固有风险规划确认工作量。图3描绘了选定瀑布模型示例中开发阶段的这一部分。
图3——生命周期阶段：定义方块工作流
5.3.2.2过程要求
应用生命周期控制的第一步是确定整个过程的目的和作用，特别是要由软件控制的部分。最好的实现方法是让适当的主题专家参与，并要包括所有相关方面和活动，无论是否全部受软件控制。好处如下：
?能够清楚地了解监管要求；
?能够清楚地了解在该过程的范围内特定软件的预期用途；
?能够通过程序或其他方式清楚地识别和处理不受特定软件控制的过程问题和活动;
?进出所识别软件的过程活动得到识别，并能在软件故障风险评估过程中和找出软件故障风险控制办法的过程中予以考虑。
过程定义活动为后期在生命周期做出决策奠定了基础，对于把精力中在增值、基于风险的活动上面至关重要。
5.3.2.3过程故障风险分析
软件与医疗产品的最终安全性和有效性之间的关系将在风险分析过程考虑。还宜考虑以下内容。
?对人类有害的风险：这包括对患者和用户的直接伤害以及当软件控制制造或设备质量出现故障时的间接伤害，从而导致设备故障，从而造成伤害。
?监管风险：如果软件故障可能导致监管机构要求的记录丢失（例如CAPA，投诉，设备主记录或设备历史记录）或偏离质量，则应考虑不遵守监管要求的风险系统和制造程序。
?环境风险：软件运行环境的风险。物理和虚拟。
风险分析的结果宜清楚地记录，因为这些结果是从工具箱中选择工具以及证明确认活动所采用工作量合理的有价值的决策驱动因素。
5.3.2.4制定确认计划
确认程度和客观证据的范围必须确保软件要求能够始终如一地执行，取决于整个过程中软件的临界值。因此，关于采用工作量和可交付元素审查的第一个确认计划制定活动以过程故障风险分析输入为唯一根据。
该确认计划制定活动产生确认计划文档的第一次迭代。计划包括选择“工作量”（即决策）以及做出这些选择的理由（即决策驱动因素）。理由宜以某过程故障造成的伤害风险为依据。确认计划制定过程中应提供批判性思维应用于确认计划过程的客观证据。
5.3.2.5软件预期用途
5.3.2.5.1预期用途的要素
预期用途旨在提供软件功能的完整画面及其在过程中的目的。具体来说，预期用途系指描述和解释软件适应整个自动化过程的方式、软件的功能、人们对软件的期望以及人们能够多大程度地依赖软件设计、生产和维护安全医疗器械。预期用途是用于了解与软件使用相关潜在风险的关键工具。
预期用途的三个主要要素是：
?与以下内容有关的目的和意图
?软件的使用（例如，人物、内容、何时、原因、地点、方式等），
?软件的监管使用，以及
?过程内软件的界限或与其他软件和/或用户的界限；
?软件使用要求。一般而言，随着复杂性和风险的增加，该元素增加更详细的有关软件使用的信息（例如：使用案例、用户要求等）；
?软件要求。随着复杂性和风险增加到宜向软件实施者提供明确方向的程度，该元素提供更具体、详细的有关软件期望的信息。
预期用途宜由对经验丰富的，精通法规、质量体系和受控过程的人员正式控制和批准。
鉴于我们应确认“预期用途”，除非软件的预期用途定义充分，否则确认无法进行。
以下子条款提供了有关软件预期用途元素的更多详细信息。
5.3.2.5.2软件目的和意图
包含涵盖三个要素的信息：软件使用、监管使用和边界定义。
a)软件使用
?在定义软件的使用时，宜考虑以下问题：内容、原因、方式、地点、地点。问题的答案探讨软件正在满足过程要求的方式。这种探讨有助于识别表1所示的软件定义的基本信息。
?对软件描述有意义的答案宜纳入既定预期用途定义。
表1——样题和答案
b)监管使用
?在评估监管使用时，可以进一步探讨所回答的问题，以确定软件是否在范围内（见5.2）。展开所有为“是”的答案，从而纳入得出这些结论的原因。既然经确定，软件处在范围内，则需确定任何对人类（医疗器械用户除外）或对环境的潜在危害。以下所有问题都使用户的考虑方向指向公共健康、安全性和有效性或电子记录和签名真实性等作为法规要求一部分的要素。
?软件的故障或潜在缺陷如何影响医疗器械的安全性或质量？
?软件如何自动执行或如何执行法规（特别是医疗器械质量管理系统的要求）规定的某项活动？
?软件怎么会对人（医疗器械用户除外）或环境造成伤害？
c)软件边界
?定义有待通过软件控制的过程的几个部分（该过程的内部边界）以及定义软件接口的位置（与其他软件的边界），有助于促进确认工作的有效性和效率。例如，多个软件产品单独确认相比，多个软件产品作为一组进行确认，通常效率能更高。还应考虑，各种分组策略能够以何种方式影响正在进行的维护阶段活动的效率。
?过程的内部边界
?识别软件在过程内部的边界，清楚地确定了要纳入预期用途中的方方面面。软件既能自动化某个整体过程，也能自动化多个活动的一部分，还能充当该过程的数据存储库。了解软件在该过程内所起的作用，有助于确定与软件某个潜在故障相关的风险。
?与其他软件的边界
?当与其他医疗器械质量体系软件或医疗器械软件进行外部连接时，识别应用程序之间的所有接口非常重要。确认工作通常包括作为方法固有部分的内部接口，但不宜忽视软件的外部接口。软件应用程序之间的所有接口都宜纳入批判性思维过程。
5.3.2.5.3软件使用要求
软件使用要求包括记录良好且可追溯的为软件目的和意图提供额外细节层的元素。从用户的角度或产品需求的角度来看，这些要求提供了对系统使用场景的深入见解。用户的视角能够以用户需求、使用案例的形式或根据其他以用户为中心的需求进行捕获。产品需求视角捕获的是受系统影响的医疗器械的需求，在某些情况下，能够将某个参考文献引入特定器械要求内或纳入某个软件可能影响的生产线的简介内。
5.3.2.5.4软件要求
由元素定义活动组成。这些元素记录良好，具有可跟踪性，用于指定软件为了满足其目的、意图和使用要求需要执行的操作。软件要求包括系统设计的输入，系统配置输入以及测试活动输入。
5.3.3实施、测试和部署
5.3.3.1所需活动
在实施、测试和部署方块中完成的活动包括：
a）规划设计中的确认严格程度，
b）开发和配置，
c）构建软件，和
d）测试基于确定风险的软件。
5.3.3.2软件故障风险分析
软件故障风险分析的关键点是确定并记录与软件故障相关的租赁风险，并确定任何控制措施（包括正在分析的软件之外的过程和软件控制措施）。然后使用该分析得出真现有效的确认方法。
在审查可归因于软件故障的风险时，考虑构成风险控制措施的分析软件之外的任何过程控制。这种风险控制措施能够减少软件故障的影响，从而减少对软件的依赖，进而减少对测试（检查）和文档（客观证据的收集）的依赖，确保软件的安全运行。纳入这些考虑因素将有助于确保在整个过程的背景下查看软件。
附件B中提出的模型并不代表是一个无所不包的公式。由此产生的分析结果为从工具箱中选择用于软件确认的工具提供了输入。
5.3.3.3制定确认计划
此活动采用预期用途定义和软件风险分析结果作为输入，用于确定风险控制措施以及从工具箱中选择用于确认软件的工具。
工具选择过程由符合条件的个人参与，这一点很重要。符合条件的个人不必是软件专家，但了解故障对过程的影响以及将使该过程自动化的软件的故障的固有风险。来自不同学科（监管、质量、临床等）的个人宜参与任何高度复杂或与其故障相关的高风险软件的规划过程。
制定确认计划生成一个文档化计划，该计划描述选择结果（决策）以及选择原因（决策驱动因素）。制定确认计划提供了信心建立活动选择依据的文档证据，以确保软件以预期的方式运行。
5.3.3.4软件实施（设计、开发、构建和测试）
本方块包括工具箱中许多工具的实际应用。工具（确认计划中确定的所需活动）在设计、开发、构建和测试步骤中进行（见图4）。
a包括代码审查等作为活动的风险控制措施以及监督计时器等设计内容。另外还包括目标区域的测试方向和要采用的测试类型。
图4——生命周期阶段：实施、测试和部署方块工作流
5.3.3.5确认 告
足够的信心建立活动一旦完成（包括选自工具箱的工具），以确保软件按预期实施，活动和（有可能）活动结果宜在最终确认 告中引用。 告的正式审查和批准为所有已记录的客观证据提供一份参考摘要，而这些证据支持软件已针对其预期用途完成确认的结论。
5.3.3.6软件发布
确认结论认为，宜存在一种用于发布软件的正式受控方法。定义控制措施应确保并确认：投入使用的软件与已通过确认 告所引用信心建立活动评估的软件相匹配。否则，理论基础和控制措施宜确保并证实结果足以代表已发布软件在其预期环境中的性能。
5.4维护阶段
5.4.1进入维护阶段
阶段入口标准：软件发布后，软件维护阶段随即开始。
活动范围：维护阶段活动包括在适应各类变化的管理和控制的同时，确保软件保持在经过确认的状态。有些变化类型只涉及软件使用所处过程的更化。
对任何已确认系统的更改宜根据政策和程序以受控方式进行。
理想情况下，建议更改在测试环境下进行，并在将系统升级投入生产使用之前进行确认。如果在测试环境下的变化无法确认，而且变化测试宜在生产环境中进行，则应采取适当的控制措施，最大限度地减少对生产环境或直接对产品产生的不良影响。
确认变更选用工具箱中的哪些工具，宜通过分析对现有风险控制措施的影响或通过引入新风险确定；或由两者共同确定。
由于软件或其配置的实际使用能够随着时间变化（尽管在竭尽全力对其进行控制），使用维护阶段专用工具（例如：定期监控实际使用情况，或实时监控软件配置）或许合适。如果预期用途的变化导致风险级别更高，则该变化能够引起范围比原来执行的确认活动更大的一系列确认活动，即使软件毫无变化，也会如此。
关于开展范围更加广泛的确认活动的决定，宜作为确认计划的一部分记录在案，以提供证据，证明软件保持在确认状态。
5.4.2维护安排
应在开始维护阶段之前记录维护计划证据。
理想情况下，维护计划在开发阶段开始安排。宜正确理解变更影响软件确认的方式，检查变更对风险的影响，并规划适当的确认维护活动。
大型复杂的软件或许必须在不影响软件预期执行能力的情况下适应日常维护和性能调整活动。在开发阶段安排维护计划能够在不影响确认的情况下完成哪些操作活动，哪些更改需要确认工作。在软件到达维护阶段之前，宜计划并讨论确定何时对软件开展进一步确认活动的方法，包括底层软件（例如，操作系统、数据库管理系统）的变化影响已确认软件的方式。培训软件操作员识别这些边界并识别正常操作活动与需要确认的任何更改之间的差异是有好处的。
可追溯性分析是管理维护活动的有用工具。可追溯性分析通常是初始确认的基石，并且通常通过可追溯性矩阵来推动。矩阵反映测试或其他确认活动的要求、反映风险控制措施等等。如果初始实施期间可追溯性分析进行良好，可追溯性分析将通过促进变更影响的识别以及促进适当变更确认活动的识别成为维护期有价值的工具。在简单软件中，此类分析能够包含对实施和确认的单级需求跟踪。但是，复杂软件可能需要多级矩阵，将顶级功能分解为较低级别的需求，然后分解为实施和确认。也可以嵌入其他信息，例如，能够在跟踪矩阵内指定认为风险极高的软件部分，可能还指出了其他确认活动。
5.4.3维护阶段内的维护类型
软件在发布使用后可能会发生变化的原因有很多。其中较常见的维护变化类型包括：
?做出纠正维护变化，以纠正软件中的错误和故障；
?完善维护更改，以增强性能、可维护性或其他软件属性；
?为更新软件操作环境而进行的自适应维护（例如，操作系统变化、系统硬件变化或与软件连接的其他应用程序的更化）。
5.4.4过程变化：改变风险控制措施
当由软件完全或部分控制的过程发生变化时，宜进行影响分析，重新评估风险控制措施。
软件完全或部分控制的过程能够独立于软件变化。当某一过程发生变化时，了解该变化对软件确认状态的影响非常重要。过程变化能够影响软件的预期用途或其他有关软件支持信息的预期用途。
过程变化还能影响作为确认基本原理的软件一部分的现用风险控制措施。由于软件是过程的一部分，因此下游控制可能是软件的重要风险控制措施。如果下游控制被正确识别为软件确认基本原理和过程定义的一部分，则建议过程变化影响分析更容易进行。对于软件和软件运行过程而言，以建立信心的方式进行维护，是影响分析的关键。
5.4.5应急变化
应紧变化宜根据批准程序进行调整。这些程序宜要求提供开发和实施的正当理由，要求说明获得和记录变化部署的授权机制，要求说明确保风险得到适当评估和控制的规定，以及调用应急变化所需的任何活动（如：培训、沟通、产品评审和处理等）。在此情况下，执行规定，适当评估和控制风险，就表示需要在发布之前，满足变化确认监管要求所需开展的最小范围的活动。
紧急情况下，可能需要进行软件变更。通常，如果软件操作系统的完整性或数据的完整性受到损害，或为了减轻潜在有害情况，需要进行此类更改。
此外，可能还需要的在应紧变化发生后开展一系列活动，以充分评估变化带来的所有影响。依据某过程故障带来的总体风险，过程输出（数据或产品）可能需要实施额外控制，直到应变化后的所有活动全部完成为止。
造成进程中断软件问题通常很明显，而找出细微、隐蔽的问题比较困难。定期评估错误日志、定期评估帮助中心的请求、客户反馈和其他缺陷 告，可以指出隐蔽的问题。此类监控技术发现的问题，不足以显示在错误 告中，但能够指出可纠正的软件问题。因此，可能需要开展维护活动，通过对未来发布软件实施更正，处理识别出的问题。此外，已发布软件中归因于此类软件问题的问题能够主动管理。
在利用维护活动纠正未来发布软件的问题后，宜检查已发布软件中已识别缺陷的历史影响，并管理其后果。
如果软件确认取决于通过培训确保软件正确使用，定期评估用户培训效果则是另一种有助于维持确认状态的监控技术。
5.4.6维护预期用途
如果软件的预期用途发生变化，则宜确认新的预期用途，或终止新用途。对于后者，风险评估是为了确保在未授权使用期间不会引入任何风险。
预期用途的变化是需要特别注意的类别，因为变化可能很细微，而且难以发现，也可能非常明显。细微变化的变化对象是目的和意图或软件使用要求，并不一定导致详细的软件需求元素发生变化（见5.3.2.5）。这种变化可能是有意为之，也可能只是因为在新模式下简单地使用现有软件，而未意识到预期用途受到了影响。预期用途可能会随着时间的推移慢慢变化，或者用户可能会以最初未预期的方式开始使用该软件。由于这种转变，所部署的软件不再处于确认状态。
每次要对已确认的软件进行更改，都宜重新审查预期用途，确保预期用途与软件的实际用途一致。
5.5 退役阶段
在退役阶段，宜记录软件的退役情况，并建立可以在任何必须的记录保留期内访问任何相关电子记录的方法。
软件退役活动高度取决于要退役软件的类型。有些软件只实施某种活动而不存储任何数据。其他软件则可以像批量可追溯性或文档控制系统一样复杂，其中包含大量与产品相关的数据和与合规性相关的数据。对于需要存储数据的软件，宜存在一份用于处理数据的计划。需要考虑的一些问题包括以下内容：
?是否有软件取代退役软件？
?数据是否能够转移到新软件里？
?数据是否宜转移成便携格式，以便长期保留？
?此类数据的数据保留要求是什么？
?数据是否会存储在耐用媒体上？
?如果数据会存储在耐用媒体上，那么，存储指令或存储程序是什么？可以检索包含所有相关数据要求的数据吗？
?可读耐用媒体和软件的维护程序是什么？
?是否会存储硬件平台档案，用来使用和检索已退役的应用程序？
?存储硬件如何维护？
?是否需要作为投诉或CAPA调查的一部分访问退役软件？
?是否需要平台和应用程序重新创建软件程序？
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！