软件确认的总则Word格式文档下载.docx

软件确认的总则Word格式文档下载.docx

《软件确认的总则Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《软件确认的总则Word格式文档下载.docx（27页珍藏版）》请在冰豆网上搜索。

3.5设计评审……………………………………………………………………………11

第四部分软件确认的原则…………………………………………………………１２

4.1.要求…………………………………………………………………………１２

4.2.缺陷预防……………………………………………………………………１２

4.3.时间和工作…………………………………………………………………１３

4.4.软件生存周期………………………………………………………………１３

4.5.计划…………………………………………………………………………１３

4.6.规程…………………………………………………………………………１３

4.7.更改之后的软件确认………………………………………………………１３

4.8.确认的覆盖范围……………………………………………………………１４

4.9.评审的独立性………………………………………………………………１４

4.10灵活性和责任………………………………………………………………１４

第五部分活动和任务………………………………………………………………１５

5.1软件生存周期活动………………………………………………………………１５

5.2典型任务支持确认………………………………………………………………１５

5.2.1质量规划…………………………………………………………………１６

5.2.2需求………………………………………………………………………１７

5.2.3设计………………………………………………………………………１９

5.2.4结构或编码………………………………………………………………２１

5.2.5由软件开发者测试………………………………………………………２２

5.2.6用户现场测试……………………………………………………………２８

5.2.7维护和软件更改…………………………………………………………３０

第六部分自动化工艺设备和质量体系软件的确认…………………………３１

6.1需要多少确认证据？

………………………………………………………３３

6.2确定用户需求………………………………………………………………３３

6.3成品软件和自动化设备的确认……………………………………………３４

附录A-参考文献………………………………………………………………

美国食品和药品管理局参考文献……………………………………………………

其他政府参考文献……………………………………………………………………

国际和国内一致同意的标准…………………………………………………………

生产工艺软件参考文献………………………………………………………………

一般的软件质量参考文献…………………………………………………………

附录B–开发团队………………………………………………………………

第一部分目的

本指南概述美国食品药品管理局的确认原则，被认为适用于医疗器械软件的确认，或用于设计、开发或制造医疗器械的软件的确认。

这是最终指南文件，版本2.0,代替草案文件，软件确认的总则，版本1.1，注明日期1997年6月9日。

本指南描述医疗器械质量体系法规的某种规定如何应用于软件和机构的评价软件确认体系的当前方法。

例如，本文件列出美国食品药品管理局对于软件确认可接受的要素；

然而其没有列出在所有情况下被用于遵守法律的所有活动和任务。

本指南的范围比该术语的最严格定义中确认的范围稍宽。

本指南中讨论的优良软件工程的规划、验证、测试、可追溯性、结构管理和许多其它方面是重要的活动，共同帮助支持软件经确认的最终结论。

本指南推荐软件生存周期管理和风险管理活动的整合。

基于和要开发的软件有关的预期用途和安全性风险，软件开发者应当确定要使用的特定方法和技术的结合，与适用的工作级别。

虽然本指南并不推荐任何特定的生存周期模式或任何特定技术或方法，其推荐贯穿整个软件生存周期进行的软件确认和验证活动。

当软件是由不同于器械制造商的人开发时（例如，成品软件）软件开发商也许不对符合美国食品药品管理局法规直接负责。

在那种情况下，负有管理责任的用户（即器械制造商）需要评定成品软件开发商的活动的适当性，并确定需要什么附加的工作来建立软件已经为器械制造商的预期使用确认过。

2.1适用性

本指南适用于：

*软件用作医疗器械的组件、部件或附件；

*软件本身是医疗器械（例如血液建立软件）；

*软件用于器械的生产（例如在制造设备中的可编程逻辑控制器）；

和

*软件用于执行器械制造商的质量体系（例如记录并维护器械历史记录的软件）。

本文件基于通常公认的软件确认原则，因此可适用于任何软件。

美国食品药品管理局的意图，本指南适用于和规定的医疗器械有关的任何软件，如由联邦食品、药品和化妆品法案的201章节规定和由当前的美国食品药品管理局软件和法规政策规定。

本文件并不特别识别哪个软件规定了或没有规定。

2.2观众

本指南为如下的个人提供有用的信息和推荐：

●服从于医疗器械质量体系法规的人员

●负责医疗器械软件的设计、开发或生产的人员

●负责用于设计、开发或制造医疗器械的自动化工具或用于执行质量体系本身的软件工具的设计、开发、生产或取得。

●美国食品药品管理局研究者

●美国食品药品管理局的符合官员

●美国食品药品管理局的科学评审员

2.3最不繁重方法

我们认为我们应当考虑在医疗器械法规的所有范围内的最不繁重方法。

本指南反应我们的对有关科学的和法律需求的仔细评审，我们所认为的是对你符合那些要求的最不繁重方法。

然而，如果你认为一个可供选择的方法将是最不繁重的，请联系我们，因此我们能考虑你的观点。

你可以发送你的书面意见给本指南的前言中列出的联系人或给设备仪器与放射健康中心的调查官员舞弊情况的政府官员。

关于设备仪器与放射健康中心的调查官员舞弊情况的政府官员的综合性信息，包括联系他们的方法，见网址http:

//www.fda.gov/cdrh/resolvingdisputes/ombudsman.html.

2.4软件确认的法规要求

美国食品药品管理局的3140医疗器械的分析在1992年和1998年之间实施的召回揭示其中的242（7.7%）可归因于软件失效。

和召回有关的那些软件，192（或79%）由当对软件最初生产和销售之后做出更改时引入的软件失效引起。

本指南中讨论的软件确认和其它有关的良好软件工程实践是避免这样的缺陷和作为结果而发生的召回的主要方法。

软件确认是质量体系法规的要求，其在1996年10月7号的联邦公报中发布，1997年6月1日实施。

（分别见联邦法规编码（CFR）的标题21的820部分和61联邦公报（FR）52602。

）确认要求适用于用作医疗器械组件的软件，适用于本身是医疗器械的软件，适用于在器械的生产中或在器械制造商的质量体系实施中使用的软件。

除非在分类法规中特别免除，任何在1997年6月1号之后开发的医疗器械软件产品，不管其器械种类，服从适用的设计控制规定。

（见21CFR820.30）本要求包括完成当前的开发项目，所有新的开发项目，和所有对现有医疗器械软件做出的更改。

器械软件确认的特定要求见21CFR820.30（g）。

其它的设计控制，例如规划、输入、验证、和评审是对医疗器械软件的要求。

（见21CFR820.30）来自这些活动的相应的备有证明文件的结果可提供医疗器械软件经确认的结论的附加支持。

任何用于使器械生产过程的任何部分或质量体系的任何部分自动化的软件必须确认其预期用途，如21CFR820.70（i）的要求。

本要求适用于使器械设计、测试、组件验收、制造、标记、包装、销售、投诉处理自动化的任何软件或用于使质量体系的任何其它方面自动化的任何软件。

另外，用于创建、修改和维护电子记录和管理电子签名的计算机系统也服从确认要求。

（见21CFR11.10（a）这样的计算机系统必须经确认以确保准确度、可靠性、与预期性能一致，辨别无效的或改变了的记录的能力。

为上述应用的软件可在内部开发或在合同之内开发。

然而，为特定的预期用途频繁地购买成品软件。

所有的生产和/或质量体系软件，即使购买的成品，应当具有完全规定其预期用途和信息的备有证明文件的要求，据此可比较测试结果和其它证据，显示已经确认软件的预期用途。

在自动化的医疗器械和自动化的制造和质量体系运行中，成品软件的使用在增加。

成品软件可以有许多性能，器械制造商仅仅需要其中的少数。

器械制造商对用于他们的器械中和用于生产器械的软件的适当性负责。

当器械制造商购买“成品”时，他们必须确保其如它们选择的应用中所预期的运行。

对用于制造或质量体系中的成品软件，附加的指南包括在本文件的6.3部分中。

对器械软件，附加的有用信息可见于美国食品药品管理局的行业指南，美国食品药品管理局评审员，和符合用于医疗器械的成品软件。

2.4质量体系法规对上市前提交

本文件标明包括实现软件确认的质量体系法规出版物。

其为管理和控制软件确认过程提供指南。

软件确认过程的管理和控制不应当和任何其它的确认要求例如对自动化制造过程的过程确认相混淆。

器械制造商可使用同一规程和记录符合质量体系和设计控制要求，以及上市前提交给美国食品药品管理局。

本文件并不覆盖和软件确认有关的任何特定的安全性或功效问题。

规定软件的上市前提交的设计问题和文件编制要求并不由本文件标明。

有关安全性和功效的特定问题，和要求在上市前提交的文件编制，应当向器械评价办公室（ODE），设备仪器与放射健康中心（CDRH）或血液研究与评审办公室，生物制品评价与研究中心（CBER）标明。

为上市前提交的可适用的美国食品药品管理局的指南文件的参考文献见附录A。

第三部分软件确认的前后关系

许多人就美国食品药品管理局期望他们做什么来确保符合有关软件确认的质量体系法规寻求特定的指南。

本文件中提出的软件确认信息不是新的。

使用第4和第5部分中列出的原则和任务的软件确认，已经在软件行业的许多部分实施了20多年。

由于医疗器械、工艺和制造设备的较大变化，不可能在一个文件中指定所有特定的确认要素是适用的。

然而，几个宽泛概念的综合应用可被成功地用作软件确认指南。

这些宽泛的概念为建立软件确认的综合方法提供可接受的框架。

附加的特定信息可从附录A中列出的许多参考文献中获得。

3.1定义和术语

除非在质量体系法规中规定，或相反在下面指定，所有用于本指南的其它术语都如美国食品药品管理局的计算机化的系统和软件开发术语的术语表的当前版本中所规定。

医疗器械质量体系法规（21CFR820.3（k））规定“建立”意指“规定、形成文件和实施。

”在本指南中出现的词“建立”和“已建立”应当被解释成具有同样的意义。

一些见于医疗器械质量体系法规的定义在和通常在软件行业中使用的术语相比较时可被混淆。

示例是要求、规范、验证和确认。

3.1.1需求和规范

虽然质量体系法规规定设计输入需求必须备有证明文件，特定的需求必须被验证，法规并不进一步阐明术语“需求”和“规范”之间的区别。

需求可以是体系或其软件的任何需要或预期。

需求反映用户的规定的或暗指的需要，也许是基于市场的、合同的、或法令的，以及组织的内部需求。

可以有许多不同种类的需求（例如，设计、功能、实现、接口、性能或物理需求）。

软件需求典型地得自对已经分配给软件的系统功能性的那些方面的系统需求。

软件需求典型地在功能术语中陈述，并规定、改进和更新为开发项目的进展。

在软件需求的准确地和完全地文件编制中的成功是作为结果的软件的成功确认中的关键因素。

规范定义为“指定要求的文件”（见21CFR820.3（y））其可涉及或包括制图、图形、或其它有关文件，通常指出方法和标准，借此可检查对要求的符合度。

有许多不同种类的书面规范，例如，系统要求规范、软件要求规范、软件设计规范、软件测试规范、软件集成规范等等。

所有这些文件建立“规定的要求”，其设计输出的不同形式的验证是必要的。

3.1.2验证和确认

质量体系法规和ISO8402：

1994协调，其将“验证”和“确认”视为分别的并截然不同的术语。

另一方面，许多软件工程期刊文章和教科书可交换地使用术语“验证”和“确认”有时候涉及软件“验证、确认和测试（VV和T）好像是单一的概念，在这三个术语之间没有区别。

软件验证提供软件开发生存周期特定阶段的设计输出满足该阶段的所有特定要求的客观证据。

软件验证寻找软件和其支持文件的一致性、完整性、和正确性。

在其被开发时，为随后的软件已经确认的结论提供支持。

软件测试是预期确定软件开发输出满足其输入要求的许多验证活动之一。

其它验证活动包括各种各样的静态和动态分析，编码和文件检查、走查和其它技术。

软件确认是已完成器械的设计确认的一部分，但是没有在质量体系法规中分别规定。

对本指南的用途，美国食品药品管理局考虑软件确认为“通过检查和规定软件规范符合用户需求和预期使用的客观证据，和特定要求的实现通过软件可被始终如一地完成来证实。

”在实践中，软件确认活动也许发生在这两个过程中，以及在软件开发生存周期的终端以确保所有的要求已经实现。

既然软件通常是大的硬件系统的一部分，软件确认典型地包括所有软件要求已经正确地和完整地实现并可追溯到系统要求的证据。

软件已经确认的结论高度依赖在软件开发生存周期的每个阶段完成的综合的软件测试、检查、分析和其它验证任务。

在模拟的使用环境中的器械软件功能性测试和用户现场测试典型地被包括作为软件自动化器械的整体设计确认程序的组件。

软件验证和确认是很难的，因为开发者不能始终测试，很难知道多少证据是足够的。

在大的测量中，软件确认是开发（器械满足软件自动化功能和器械特征的所有要求和用户预期）的“置信度级别”的问题。

例如在规范文件中发现的缺陷，估计剩余缺陷，测试覆盖范围，和其它技术等措施都用于在产品发货前开发一个可接受的置信度级别。

置信度级别，为此需要的软件确认、验证和测试工作级别将依赖器械的自动化功能引起的安全性风险（危害）而变化。

关于软件的安全性风险管理的附加指南见美国食品药品管理局的第4部分包含在医疗器械中的软件的上市前提交内容的指南，和国际标准ISO/IEC14971-1和IEC60601-1-4，在附录A中引用。

3.1.3IQ/OQ/PQ

多年以来，美国食品药品管理局和管理行业试图在过程确认术语的上下文中理解和定义软件确认。

例如，行业文件和其它的美国食品药品管理局确认指南有时按照安装鉴定（IQ）、操作鉴定（OQ）和性能鉴定（PQ）来描述用户现场软件确认。

这些术语的定义和有关IQ/OQ/PQ的附加信息见美国食品药品管理局的过程确认总则的指南，注明日期1987年5月11日，和美国食品药品管理局的计算机化的系统和软件开发术语的术语表。

注明日期1995年8月。

当IQ/OQ/PQ术语良好地服务其用途，并且是在用户现场组织软件确认任务的许多合理方法之一。

也许在许多软件专业人员中本术语没有被很好地理解，其不用于本文件中的别处。

然而，美国食品药品管理局人员和器械制造商两者寻找和提供关于软件确认的信息时需要知道术语中的这些区别。

3.2软件开发作为系统设计的一部分

使用软件来实现系统功能性是在系统设计过程中典型地做出的决策之一。

软件要求典型地得自全面系统要求，为系统中的那些方面的设计要使用软件来实现。

对已经完成的器械有用户需要和预期使用，但是用户典型地并不规定那些要求是否由硬件、软件或两者的一些结组合满足。

因此，软件确认必须在体系的全面设计确认的上下文中考虑。

备有证明文件的需求说明代表用户的需要和预期使用，由此来开发产品。

软件确认的首要目标是然后证明所有已经完成的软件产品符合所有备有证明文件的软件和系统需求。

系统需求和软件需求两者的正确性完整性两者应当作为器械的设计确认过程的一部分来标明。

软件确认包括证实对所有软件规范的符合性，证实所有的软件要求追溯到系统规范。

证实是全部设计确认的一个重要部分以确保医疗器械的所有方面符合用户需要和预期使用。

3.3软件不同于硬件

当软件分担许多和硬件一样的工程任务时，有一些非常重要的区别。

例如：

●软件问题中的大多数可追溯到在设计和开发过程中形成的错误。

硬件产品质量高度依靠设计、开发和制造，软件产品质量主要依靠对软件制造最小关注的设计和开发。

软件开发由可容易验证的再现组成。

很难制造数千的功能和原件完全相同的程序副本；

困难来自使得原程序满足所有的规范。

●最重要的特征之一是软件分支，即基于不同输入的执行选择性的操作系列的能力。

该特征对软件的另一个特性——其复杂性是一个主要的促成因素。

甚至简短的程序可以非常复杂很难充分理解。

●典型地，单独的测试不能充分验证软件已经完成和校正。

除测试之外，其它的验证技术和有结构的备有证明文件的开发过程应当组合以确保综合的确认方法。

●不同于硬件，软件不是物理实体不会磨损。

事实上，当潜在的缺陷被发现和去除时，软件也许随着寿命而改进。

然而，因为软件经常更新和改变，这样的改进有时由在更改期间引入软件的新缺陷来计数。

●不象一些硬件故障，软件失效的发生没有高级警报。

软件的分支允许在执行期间跟随不同的路径，也许隐藏了一些潜在的缺陷直到软件产品被引入到市场很久之后。

●软件的另一个有关特征是速度和易于改变。

该因素可导致软件和非软件专业人员两者相信软件问题可被容易地校正。

和缺乏对软件的理解相结合，可导致管理人员相信紧密控制的工程对于软件不象其对于硬件那么需要。

实际上，相反的是真实的。

因为其复杂性，软件的开发过程应当比硬件更紧密地控制，为了防止在开发过程中不能容易地稍后找到的问题。

●软件编码的表面上不重要的改变会造成软件问题中其它的未预料到的非常重要的问题。

软件开发过程应当充分地良好计划、受控和备有证明文件以发现和校正由软件更改产生的未预料到的结果。

●假设对软件专业人员和高度活动的工作人员的高要求，对软件做出维护更改的软件人员也许没有包括在原软件的开发中。

因此，准确的和彻底的文件是必需的。

●历史上，软件组件不象硬件组件一样频繁地标准化和可互换。

然而，医疗器械软件开发者开始使用基于组件的开发工具和技术。

目标导向的方法和使用成品软件组件保证更快和花费较低的软件开发。

然而，基于组件的方法要求集成期间的仔细关注。

在集成之前，需要时间来充分地定义并开发可重复使用的软件编码并充分理解成品组件的性能。

由于这些和其它原因，软件工程比硬件工程需要更高级别的管理研究和控制。

3.4软件确认的益处

软件确认是用于确保器械软件质量和软件自动化操作的关键工具。

软件确认可提高器械的适用性和可靠性，导致减少的失效率，较少的召回和校正措施，对患者和用户的较小风险，减少器械制造商的责任。

软件确认也能通过使得可靠地更改软件和再确认软件更改更容易和成本更低来降低长期成本。

软件维护能代表软件在其整个生存周期的总成本的非常大的百分比。

已确定的综合的软件确认过程通过降低每个软件发布之后的确认成本来帮助降低软件的长期成本。

3.5设计评审

设计评审是设计的备有证明文件的、综合的和系统的检查以评价设计要求的适当性、评价设计满足这些要求的能力，并识别问题。

也许有发生在软件项目期间的开发团队中的许多非正式的技术评审，正式的设计评审是更结构化的包括参与开发团队之外的其它评审。

正式的设计评审也许参考或包括由其它正式的和非正式的评审的产生的结果。

在软件和硬件一起整合到系统中之后，设计评审也许为软件分别进行，或两者。

设计评审应当包括检查开发计划、要求规范、设计桂发、测试计划和规程，所有和项目有关的其它文件和活动，来自确定的生存周期的每个阶段的验证结果，和对整个器械的确认结果。

设计评审是管理和评价开发项目的主要工具。

例如，正式的设计评审允许管理来确定软件确认计划中规定的所有目标已经达到。

质量体系法规要求在器械设计过程中至少进行一个正式的设计评审。

然而，推荐进行多个设计评审（例如，在每个软件生存周期活动的终端，为进行下一个活动作准备）。

在主要的资源用于特定的设计解决方案之前，正式的设计评审在要求活动的终端或附近是特别重要的。

可以更容易地解决在该点发现的问题，节省时间和钱，降低遗漏问题的可能性。

一些关键问题的答案应当在正式的设计评审中备有证明文件。

这些包括：

●已经为每个软件生存周期活动建立适当的任务和预期的结果、输出、或产品吗？

●每个软件生存周期活动的任务和预期结果、输出或产品：

√遵从根据正确性、完整性、一致性和准确性的其它软件生存周期活动的要求吗？

√确保活动的规程、实践和惯例吗？

√为下一个软件生存周期活动的启动任务建立适当的基础吗？

第四部分软件确认的原则

本部分列出应当为软件确认考虑的总原则。

4.1要求

备有证明文件的软件要求规范提供确认和验证两者的基准。

没有已经建立的软件要求规范不能完成软件确认过程（参考文献：

21CFR820.3（Z）和（aa）和820.30（f）和（g））.

4.2缺陷预防

软件质量保证需要集中于防止将缺陷引入到软件开发过程中，不集中于软件编码写好后试图将“测试质量”引入到软件编码中。

软件测试将所有的潜在缺陷形成在软件编码的表面的能力是非常有限的。

例如，多数软件的复杂性防止其被彻底地测试。

软件测试是一个必要的活动。

然而，一般地软件测试本身并不足以建立软件适合于其预期用途的置信度。

为了建立该置信度，软件开发者应当使用方法和技术的混合来防止软件错误并检测到确实发生的软件错误。

方法的“最佳混合”依靠包括开发环境、应用、项目大小、语言和风险的许多因素。

4.3时间和工作

要建立软件已经确认的情况要求时间和工作。

为软件确认的准备应当及早开始，即在设计和开发规划和设计输出期间。

软件已经确认的最终结论应当基于从整个软件生存周期中进行的有计划的工作来收集的证据。

4.4软件生存周期

软件确认发生在已经建立的软件生存周期环境中。

软件生存周期包含软件工程任务和必要的文件以支持软件确认工作。

此外，软件生存周期包含适合于软件预期用途的特定验证和确认任务