Hello world!
2020年3月3日内部审核与质量管理体系自查程序
2026年8月4日设计验证与设计确认在医疗器械开发中的区别
Design Validation vs Design Verification for Med Device Development
如果您从事产品开发——尤其是医疗器械——那么您一定听说过设计验证Design Verification和设计确认Design Validation(也称为 V&V)这两个术语。本文将解释这两项活动的含义、它们之间的区别,并分享一些提升工作成效的建议。
注意:为验证和确认本文内容,我们联系了刘老师,她是一位医疗器械顾问,在医疗器械验证与确认(V&V)、医疗器械软件、产品与软件质量以及美国和国际器械监管申报方面拥有超过 30 年的经验。您将在文中多处看到她的见解和示例。
目录Table of Contents
- 验证与确认有什么区别?
- 什么是设计确认(Design Validation)?
- 什么是针对NMPA的设计验证?
- 验证与确认 摘要
- 设计确认流程基础
- 设计验证流程基础
验证与确认有什么区别?What’s the Difference Between Validation vs Verification?
验证Verification和确认Validation之间有什么区别?简而言之,确认Validation用于确定您是否在构建正确的产品。该器械是否按最终用户的预期工作?验证Verification用于确定您是否以正确的方式构建产品。设计输出是否与设计输入相符?
让我们更仔细地看一下每个阶段,从确认Validation开始。
什么是设计确认(Design Validation)?What Is Design Validation Exactly?
设计确认是一种通过测试的过程,用以证明(“确认”)您所制造的器械能够按最终用户的预期发挥作用。“establishing by objective evidence that device specifications conform with user needs and intended use(s).”
来自FDA(21 CFR 820.3)的官方表述称,设计确认是“通过客观证据证明器械规格符合用户需求user needs和预期用途intended use(s)。”
设计确认示例Design Validation Example
假设我们正在设计一台在运输病人时维持其呼吸的呼吸机,而用户希望确保该呼吸机在病人转运过程中能正常工工作。
首先,我们必须定义用户需求user needs。用户希望在患者仍连接呼吸机时能够移动他们。但他们实际上想要做什么?“转运过程”可能包括在医院内移动患者,或可能包括通过救护车或航空运输。举例来说,一个用户需求可能如下所示。
用户需求User Need
| UsNe-0001 | 该呼吸机适用于搬运(转运)病人时使用。 |
这个用户需求user need将被分解为产品需求product requirements和设计规范design specifications,以便设计和制造产品。(我们稍后将在设计验证一节中查看这些内容。)
在此之前,让我们审查用户需求user need并查看可能需要哪些设计确认(validation)测试用例。对我们用户需求的确认测试可能如下所示。
| 用户需求 | 确认(Validation)测试 | ||
| UsNe-0001 | 该呼吸机适用于院内转运期间的患者使用。 | TCase-0001 | 确认测试用例:测试呼吸机能否被医院运输人员中的15名成员轻松推行。 |
| TCase-0002 | 确认测试用例:测试呼吸机在被推行过走廊、跨越门槛和电梯门槛时是否在其设计性能规格范围内运行。 | ||
| TCase-0003 | 确认测试用例:测试呼吸机在交流电和电池供电之间切换时是否在其设计性能规格范围内运行。 | ||
确认测试应包括测试用例、测试方案,甚至临床试验,旨在证明按已建造的产品在用户预期使用的条件下按用户期望运行。由于这些测试应在生产或与生产等效的单元上进行,设计确认测试通常是最后进行的测试。
基本上,在设计确认(validation)中,我们需要证明产品满足用户的需求。
顺便提一下,上表还显示了可追溯性traceability从用户需求user needs到测试用例 test cases.的对应关系。该可追溯矩阵trace matrix提供了食品药品监督管理局(NMPA)所要求的部分验证与确认(V&V)证据。
什么是NMPA的设计验证?What Is Design Verification for NMPA?
设计验证是你测试(“验证”)设计输出是否与设计输入相匹配的环节。
再次,根据FDA的定义,设计验证是“通过检查并提供客观证据以确认已满足规定要求”。“confirmation by examination and provision of objective evidence that specified requirements have been fulfilled.”
请记住,尽管这将涉及测试,但还有其他可接受的验证活动。
它们可以包括测试、检查和分析等。
设计验证示例Design Verification Example
让我们回到呼吸机的例子。我们已经确定了用户需求user needs;现在让我们确定设备必须做什么以及必须如何去做。
为此,我们需要定义具体的产品要求。例如:
- 患者的最大负载是多少?(呼吸机需要运送多少空气?)
- 电池需要续航多久?(转运[搬运]需要多长时间?)
- 在运输过程中会遇到哪些情况?(门把手卡住?电梯?)
- 是否需要满足任何监管法规和标准?(安全标准?)
“清晰、完整、无歧义、可测试的需求是成功开发项目的关键组成部分。不充分的需求会导致时间浪费、设计错误、大量返工以及脆弱或易出错的产品。” –刘老师,V&V 顾问
这是定义器械特性中的“什么What”部分。器械究竟需要做什么?(What exactly will the device need to do?)我们的用户需求 user need的产品要求Product requirements(通常包含在产品需求文档中)可能如下所示。
产品需求Product Requirements
| PrRq-0001 | 呼吸机的最大设定为容积控制呼吸每次2升,频率为每分钟20次。 |
| PrRq-0002 | 呼吸机在最高设置下应能以电池供电运行至少90分钟。 |
| PrRq-0003 | 呼吸机应能够安装在带轮支架上。 |
| PrRq-0004 | 呼吸机及其支架应能通过典型医院门槛和电梯门槛。 |
最后,我们需要设计规范design specification。“我们已经定义了要做什么,现在需要定义如何去做,”–刘老师说。这可以通过多种方式实现,包括书面规范、电气或机械图纸、组件购规格或其他方法。
例如,设计规范和图纸可能显示以下内容。
设计规范Product Requirements
| DSpec-0001 | 一台可产生高达40升/分钟气流的涡轮。 |
| DSpec-0002 | 额定至少100安时的锂离子电池组。 |
| DSpec-0003 | 滚动支架的安装件使用额定22磅的钢质杠杆式夹具。 |
| DSpec-0004 | 支架底座宽22英寸,配有5个轮子。 |
| DSpec-0005 | 支架轮子直径为4英寸。 |
设计验证Design verification提供证据(测试结果test results),证明设计输出(实际产品)满足设计输入(产品需求product requirements和设计规范design specifications)。根据被验证的项目,可能会执行测试用例或测试方案,或进行检测或分析以提供所需的证据。
下表示例说明了可能的情况。它们还展示了NMPA所期望的可追溯性。
| 产品需求 | 验证测试 | ||
| PrRq-0001 | 呼吸机的最大设定为容积控制呼吸每次2升,频率为每分钟20次。 | TCase-0004 | 测试用例:验证呼吸的最大设置或呼吸设置组合。 |
| PrRq-0002 | 呼吸机在最高设置下应能以电池供电运行至少90分钟。 | TCase-0005 | 测试方案:在全新充满电的电池上以最大设置验证运行时间。 |
| TCase-0006 | 测试方案:使用已经历50次充电循环的电池验证在最大设置下的运行时间。 | ||
| PrRq-0003 | 呼吸机应能够安装在带轮支架上。 | TCase-0007 | 演示测试:演示呼吸机可从带轮支撑架上连接和拆卸。 |
| PrRq-0004 | 呼吸机及其支架应能通过典型医院门槛和电梯门槛。 | TCase-0008 | 外部测试:由测试服务执行的测试,用以验证呼吸机和支架能按 IEC 60601-1 医疗电气标准在不翻倒的情况下越过门槛。 |
对产品需求product requirements的验证(如上)表明产品完成了我们要求产品所具备的事(性能、功能等)。
设计规格design specifications的确认(下面将展示)表明产品按照我们所说的方式运行(工作)。
| 设计规范 | 验证测试 | ||
| DSpec-0001 | 能够产生每分钟40升空气的涡轮。 | TCase-0009 | 测试方案:验证涡轮在交流电或电池电源下以 40 lpm 产生空气。 |
| DSpec-0002 | 一个额定容量为100安时的锂离子电池组。 | TCase-0010 | 检验测试:验证电池采购规格显示类型为锂离子。 |
| TCase-0011 | 分析测试:收集测试数据并进行数据分析,以证明电池在其使用寿命期间的性能将达到或超过100每安时(Amp)。 | ||
| DSpec-0003 | 滚动支架的安装件使用额定22磅的钢质杠杆式夹具。 | TCase-0012 | 检验测试:验证零件规格为额定22磅或更高的钢制杠杆式夹具。 |
| DSpec-0004 | 支架底座宽22英寸,配有5个轮子。 | TCase-0013 | 测试用例:测量基座直径;计数车轮;测量车轮直径 |
| DSpec-0005 | 支架轮子直径为4英寸。 | ||
本质上,在设计验证中design verification,我们需要证明我们制造的产品就是我们所声明要制造的产品。
当在验证与确认(V&V)报告中汇总时,验证和确认测试结果的组合,以及可追溯到用户需求user needs、产品要求product requirements和设计规范design specifications的链条,构成了向NMPA提交医疗器械以申请批准时所需证据的一部分。
验证与确认摘要Validation vs Verification Summary
下面是一个简短且略为简化的关键差异总结。
| 设计验证Design Verification | 设计确认Design Validation |
| 设计输出符合预期。 | 最终设计满足用户需求。 |
| 系统、子系统和单元测试。 | 系统测试。 |
| 在开发过程中。 | 开发完成后。 |
| 在任何条件下测试单个模块或完成的系统。 | 根据用户需求确定测试条件。 |
| 包括系统检查、分析和测试。 | 包括在实际使用条件下对等同于生产的器件进行的测试。 |
| 包括所执行测试的报告、测试结果和可追溯性。报告经过审查、批准并签署。 | 包括最终报告,含测试结果和可追溯性,准备接受监管审查。 报告经过审查、批准并签署。 |
设计确认程的基础要求Basics of Design Validation Process
设计确认过程在很大程度上将由对器械的测试构成。根据具体情况,您可以通过几种方式进行此项工作。活动可以包括:
- 与用于类似目的的类似设备进行比较。
- 通过数学建模模拟功能。
- 测试最终设计以证明系统按照用户需求定义的方式运行。
测试计划、测试用例、测试执行记录和测试结果应作为设计记录的一部分进行记录和维护。确认并非单一活动的结果,而是所有确认活动结果的汇总。
设计验证流程基础要求Basics of Design Verification Process
验证可以简化为一个简单的五步过程。
识别与准备Identifying and Preparing
确定进行验证的最佳方法。定义要测量的内容以及测量方法。还需要考虑成功验证所需的资源、人员和工具。
计划Planning
验证的规划贯穿整个项目生命周期。您将制定包含关键里程碑的测试计划。每当对设计输入进行更改时,必须更新该计划。
开发Developing
产品开发开始!采用所选的方法论(Scrum、瀑布、混合等)进行。本阶段还包括编写、试运行并批准将用于验证的测试用例。
执行Executing
按照计划执行测试程序。任何无效结果均予记录并复核,随后被接受或记录为缺陷。产品中的缺陷被解决并发布,同时执行回归测试。创建可追溯矩阵以验证在验证测试计划中识别的设计输入已被测试并通过。
报告Reporting
在每个验证阶段结束时进行报告。详细报告包括配置管理和发布报告、按测试类型或产品版本分类的测试结果,以及在验证活动中发现的问题。设计验证可追溯性报告显示需求的测试结果和覆盖情况。最后,每次设计验证活动后完成并批准评审。
做好设计验证与确认的6个建议
以下提示可帮助您在设计验证与确认中获得最大收益。
1. 提前规划(并尽早测试)
在前期制定可靠的计划并让所有人参与。开发计划中应尽早包含测试工程师,以确保需求和设计清晰、完整且可测试。刘老师表示:“尽早开发测试方法可以在技术问题成为重大障碍之前揭示它们。”尽早的测试开发还可以提供测试工具,这些工具可用于加速产品开发流程,并在正式测试期间提供测试证据。
2. 使用统一术语
让团队达成共识对成功的设计验证与设计确认至关重要。达成共识的一部分就是使用统一的术语。使用相同的术语可以消除团队成员的混淆(不仅是新成员——资深成员也是如此)。
3. 使用具有端到端可追溯性的工具
在最简单的情况下,可以使用 Word 文档和电子表格来实现可追溯性,但它们会产生大量手工工作(且容易出错),让你会后悔没有一开始就使用专用工具。
“在进行回归分析以确定在产品更改或修复缺陷后应重新测试的内容时,准确的追踪矩阵是非常宝贵的。”——刘老师,验证与确认顾问
使用具有强大需求-测试-结果追踪功能的工具将帮助你识别覆盖中的空白,并在产品中脆弱或未测试的区域提供早期警示。
4. 在进行中构建您的追踪矩阵
“可能会很想把它推迟,但不要等着再去建立你的追溯矩阵。”–刘老师说。随着进展构建你的可追溯性可以防止漏洞在不被察觉的情况下形成。很少有事情比在你以为开发工作已完成时才发现你漏掉了关键需求、减轻风险的功能或必要测试更难以挽回。
需求、设计和测试演进的过程中,保持可追溯性所需的维护工作要远远少于在最后关头修补设计和开发中的关键漏洞。这项工作还能帮助你识别还剩多少工作量、何处可能需要增加开发或测试人员,或者何时应重新评估交付计划。
避免在最后一刻出现紧急情况!在此,Perforce ALM 中跟踪需求与已完成测试之间的状态。
5. 将需求可追溯性与测试与异常跟踪集成
能够将异常直接与需求关联可改善测试人员与开发人员之间的沟通。这非常有帮助。直接从测试方案失败生成异常意味着会捕获有关问题的更多细节。因此,问题可以更容易地记录、重现、修复和重新测试。
6. 选择可根据您的方法进行自定义的工具
“无论您选择了哪种开发模型——敏捷、迭代、改良瀑布——您都应选择那些能通过适应您的流程来为您服务的 V&V 工具,而不是迫使您为工具而调整流程,”刘老师建议。
将这一切汇聚在一起
设计确认和设计验证是成功器械开发的重要组成部分。当团队之间有共同的理解并配备合适的工具时,您就拥有将器械推向市场的坚实框架。
再次感谢验证与确认(V & V)专家 刘老师 为本文提供的宝贵见解!
