医疗器械生产质量管理规范附录《独立软件》

第一部分  范围和原则

      1.1     本附录适用于独立软件，软件组件参照执行。

解读：

本文中的软件，应该是指用于“医疗目的”的软件；独立软件指“运行于通用计算平台”“不依赖于医疗器械”就可以起到“医疗”作用的软件；软件组件指“控制或驱动医疗器械硬件或运行于医用计算平台”的软件。

当然，用于医疗器械企业“生产制造过程控制”“工作流程管理”的软件，不在本文适用范围，不过对于所有“软件”本身的生命周期管理与开发过程的客观规律，都是一样的，也值得我们生产企业和装备行业借鉴。

1.2  本附录遵循软件生存周期过程和网络安全的基本原则和通用要求，是对独立软件生产质量管理规范的特殊要求。

解读：

软件的生命周期过程、数据可靠性、网络安全……对所有软件都是一样的，遵循软件本身的客观规律，不管是“医疗目的”软件，还是医械产品“生产制造过程控制软件”，都应该遵循软件的客观规律和生命周期管理。这其实并非什么“特殊”要求。

第二部分  特殊要求

2.1  人员

2.1.1  软件开发、测试、维护人员应当具备与岗位职责要求相适宜的专业知识、实践经验和工作能力。

解读：

对于软件的开发/测试/维护……来说，相关参与人员的“专业知识、实践经验、工作能力……”当然都是十分重要的。

2.1.2  黑盒测试应当保证同一软件项的开发人员和测试人员不得互相兼任。

解读：

那么，白盒测试呢？开发人员和测试人员可以互相兼任吗？这个我真不知道。实际上，开发是为了实现客户的需求，测试是为了保证软件的质量；一些小型的软件公司，出于成本考虑，开发与测试人员也可能是兼任的，就是自己测试自己开发的软件，如果他具备测试的能力和素质，当然这本身没有什么大的问题，就像生产人员可以检验自己生产的产品质量一样；

但是基于“职责所在”和“利益关系”的考虑，也基于“专业分工的不同”，不得互相兼任也是十分有道理的。

就像医疗器械企业“生产负责人”和“质量负责人”不得兼任一样，但是对于一线的开发人员和测试人员，其实本身就是两个不同的岗位而已。

2.1.3  用户测试人员应当具备适宜的软件产品使用经验，或经过培训具备适宜的软件产品使用技能。

解读：

用户测试人员，就是“医疗目的”软件的用户了。用户要有软件的使用经验，主要关注软件的使用功能、使用技能……。

其实，对于医械企业的设备操作员工，也是设备控制软件和流程管理软件的用户，应该主要关注软件的使用经验、使用功能、使用技能……而不需要过度关注软件开发过程和测试过程。

2.2  设备

2.2.1  应当在软件生存周期过程持续提供充分、适宜、有效的软件开发和测试环境，包括软硬件设备、开发测试工具、网络等资源以及病毒防护、数据备份与恢复等保证措施。

解读：

对于软件企业而言，软件开发环境和测试环境，相当于“制造行业”的生产环境（包括厂房设施、设备系统）与检验环境，就像制药行业的厂房设施、洁净环境、生产设备、检验体系、公用工程一样；

本附录要求软件企业必须为软件的开发与测试提供必要环境条件，开发环境、测试环境，需要特定的硬件设备、软件环境、特定的开发工具、测试工具、网络资源、安全保障条件（病毒防护、数据备份与数据恢复……）。

2.2.2  软件开发和测试环境维护应当形成文件，确定软件开发和测试环境定期验证、更新升级、病毒防护等活动要求，保持相关记录。

解读：

对于软件企业而言，软件开发环境和测试环境，当然需要进行“确认、验证、再验证”、更新、改造、升级、报废……安全防护、数据可靠性要求……

开发环境和测试环境的维护活动，要有相关的文件、记录……

2.3  设计开发

2.3.1  应当结合软件生存周期模型特点建立软件生存周期过程控制程序并形成文件，确定软件开发策划、软件需求分析、软件设计、软件编码、验证与确认、软件更新、风险管理、缺陷管理、可追溯性分析、配置管理、文件与记录控制、现成软件使用、网络安全保证、软件发布、软件部署、软件停运等活动要求。

解读：

对于独立的医疗软件或者医疗器械的控制软件而言，软件开发企业（医疗器械企业）对于软件生命周期管理及控制程序，应该非常熟悉，形成系统性的文件，以规范软件生命周期的管理和控制，是必要的。

2.3.2  软件生存周期过程质量保证活动要求应当与软件安全性级别相适宜。软件安全性级别应当在采取风险控制措施之前，结合软件的预期用途、使用场景和核心功能进行综合判定，并仅可通过外部风险控制措施降低级别。

解读：

软件生命周期的质量保证活动要求，基于软件的安全等级，而软件的安全等级是基于软件本身功能对患者的风险等级相适应的，采取必要的外部（软件本身之外）风险控制措施可以降低软件本身的风险到可接受程度，从而降低软件的风险级别。

对于非独立软件（软件组件）而言，软件的风险等级又和软件本身控制的医疗器械硬件的功能对患者的风险相一致。

2.3.3  应当依据风险管理控制程序实施软件风险管理活动，结合产品识别、分析、评价、控制和监测软件功能、接口、用户界面、现成软件、网络安全等风险，并贯穿于软件生存周期全过程。

解读：

独立软件、带软件的医疗器械，都是直接用于医疗目的，对其进行风险评估与风险控制，类似于对产品的生产工艺过程进行风险管理，同样基于软件的功能（类似于产品的质量属性）和软件的开发、测试过程控制，进行风险管理活动。

2.3.4  软件配置管理应当建立控制程序并形成文件，规范软件版本、源代码、文件、工具、现成软件等控制要求，确定配置标识、变更控制、配置状态记录等活动要求。使用配置管理工具保证软件质量，并贯穿于软件生存周期全过程。

解读：

对于软件开发企业（独立软件开发企业或者相关医疗器械生产企业），这些基本要求都是必须的。

2.3.5  软件版本控制应当基于合规性要求确定软件版本命名规则，涵盖软件、现成软件、网络安全的全部软件更新类型，各字段含义应当明确且无歧义无矛盾。软件版本变更应当符合软件版本命名规则的要求。

解读：

软件命名规则、软件版本控制，需要有系统的、科学的命名方法，包含所有的全部软件（医疗目的软件、开发软件、测试软件、网络安全软件……遗留软件、成品软件、外包软件……）。

2.3.6  软件可追溯性分析应当建立控制程序并形成文件，涵盖现成软件、网络安全的控制要求，形成软件可追溯性分析报告以供评审。使用可追溯性分析工具保证软件开发、软件更新过程满足可追溯性要求，并贯穿于软件生存周期全过程。

解读：

软件的可追溯性，通过“软件需求、软件设计、源代码、软件测试、软件风险管理”之间的关系，分析和评估各个步骤之间的“正确性、一致性、完整性、准确性”，当然需要使用“可追溯性分析工具”， 网上也可以下载“软件追溯性分析报告”模板。

2.3.7  现成软件使用应当形成文件，确定风险管理、验证与确认、缺陷管理、可追溯性分析、软件更新、配置管理、文件与记录控制、网络安全保证等活动要求。遗留软件还应当确定现有文件、上市后使用情况、用户投诉、不良事件、召回情况等评估活动要求。使用开源软件应当遵循相应开源许可协议。

解读：

现成软件，应该是指“以前自己开发的软件、外购的成品软件、委托第三方开发的软件”没有按照本规范进行完整的生命周期控制的软件，这些软件的管理，当然需要有一套文件，规定“风险管理、验证与确认、缺陷管理、可追溯性分析、软件更新、配置管理、文件与记录控制、网络安全保证”的工作流程。

用于“医疗目的”的“独立软件或医疗器械”，产品上市后需要跟踪“使用情况、不良事件、用户投诉、产品召回……”并定期评估这些活动。

这些工作，当然是由“医疗目的”独立软件提供商、医疗器械的制造商来做，肯定不应该由独立软件或医疗器械的“用户”来主导；很多用户不是直接患者，那么这类用户也应当直接参与到这些活动中。

2.3.8  软件开发策划应当确定软件需求分析、软件设计、软件编码、验证与确认、风险管理、缺陷管理、可追溯性分析、配置管理、文件与记录控制、现成软件使用、网络安全保证、评审等活动计划，形成相关文件和记录，并适时更新。软件开发策划应当保证软件开发和测试的人员及环境与软件开发要求相适宜。

解读：

软件生命周期的管理，应该是从软件需求分析开始，软件开发策划，相当于软件开发的项目计划书，涵盖整个软件开发与软件测试流程的所有方面的活动计划，严格执行该计划并形成文件和记录。（软件开发主计划）

2.3.9  软件需求分析应当综合分析法规、标准、用户、产品、功能、性能、接口、用户界面、网络安全、警示提示等软件需求，确定风险管理、可追溯性分析、现成软件使用评估、软件确认测试计划创建、评审等活动要求，形成软件需求规范和评审记录并经批准，适时更新并经批准。可追溯性分析此时应当分析软件需求与风险管理、软件需求与产品需求的关系。

解读：

软件需求分析，相当于对“软件用户需求”的分析、评估，基于“法规、标准、功能、性能、风险管理、使用评估、可追溯、确认测试、评审要求……“等方面，最终形成“软件需求规范”并经评审与批准，该功能需求文档应清楚地列出系统大致的一二级功能模块以及相关的界面和界面功能。（软件需求规范）

2.3.10  软件设计应当依据软件需求规范实施软件体系架构、功能、性能、算法、接口、用户界面、单元、网络安全等设计，确定风险管理、可追溯性分析、现成软件使用评估、软件验证测试计划创建、评审等活动要求，形成软件设计规范和评审记录并经批准，适时更新并经批准。可追溯性分析此时应当分析软件设计与软件需求之间的关系。

解读：

软件设计阶段，依据“软件需求规范”来实施软件的“构架与功能”设计（或者叫做系统设计），形成“软件设计规范”并经评审与批准。

系统设计（或概要设计）需要对软件系统的基本处理流程、系统的组织架构、模块划分、功能分配、接口设计、运行设计、数据结构设计、出错处理设计……等进行设计，为软件的详细设计提供基础。 

软件系统的详细设计应该描述实现具体模块的主要算法、数据结构、类的层次结构及调用关系，需要说明软件系统各个层次中的每一个程序(每个模块或子程序)的设计考虑，以便进行编码和测试，应当保证软件的需求规范被完全落实到整个软件设计中，详细设计报告是下一步“软件编码”的依据。

2.3.11  软件编码应当依据软件设计规范实施，确定源代码编写与注释、现成软件使用、可追溯性分析、各级测试用例创建、评审等活动要求，形成评审记录，并适时更新。源代码编写与注释应当符合软件编码规则文件的要求。测试用例应当保证软件验证与确认测试的充分性、适宜性、有效性。可追溯性分析此时应当分析源代码与软件设计、源代码与测试用例的关系。

解读：

根据《软件系统详细设计报告》中对数据结构、算法分析和模块实现等方面的设计要求，开始具体的编写程序工作，分别实现各模块的功能，从而实现对目标系统的功能、性能、接口、界面等方面的要求。在规范化的研发流程中，编码工作在整个项目流程里最多不会超过1/2，通常在1/3的时间

2.3.12  软件验证应当确定源代码审核、静态分析、动态分析、单元测试、集成测试、系统测试、评审等活动要求，涵盖现成软件、网络安全的验证要求，并保持相关记录。白盒测试应当确定语句、判定、条件、路径等测试覆盖率要求，并与软件安全性级别相适宜。

解读：

本附录是针对医疗械器本身操作软件或“做医疗用”的独立软件，软件的“验证”也是要求软件的开发商或器械的制造商来做，所以，源代码审核、静态分析、动态分析、单元测试、集成测试、系统测试、系统评审……包括白盒测试的具体要求，都应该严格执行软件验证的全生命周期的IT行业验证标准。

2.3.13  单元测试、集成测试、系统测试应当依据相应测试计划实施，涵盖现成软件、网络安全的测试要求，确定缺陷管理、风险管理、可追溯性分析、评审等活动要求，形成相应软件测试记录、测试报告以及评审记录，并适时更新。可追溯性分析此时应当分析各级测试用例与软件设计、系统测试与软件需求、系统测试与风险管理的关系。

解读：  

软件测试的对象包括软件需求、概要设计（类似于概念设计吧）、详细设计、软件运行环境、可运行程序和软件源代码等。

软件测试一般分为4个阶段：单元测试、集成测试、系统测试、验收测试。

软件测试必须有相应的测试计划、测试记录、测试报告以及评审记录。

测试过程应关注缺陷管理、风险管理、可追溯性分析、评审等活动要求。

单元测试：

单元测试是对软件中的最小可验证单元进行检查和验证。

集成测试：

集成测试是在单元测试的基础上，把软件单元按照软件概要设计规格说明的规格要求，组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求。

系统测试：

将经过集成测试的软件，作为计算机系统的一部分，与系统中其他部分结合起来，在实际运行环境下进行一系列严格有效的测试，以发现软件潜在的问题，保证系统的正常运行。

验收测试：

也称交付测试，是针对用户需求、业务流程进行的正式的测试，以确定系统是否满足验收标准，由用户、客户或其他授权机构决定是否接受系统。

验收测试包括alpha测试和beta测试，alpha测试是由开发者进行的软件测试，beta测试是由用户在脱离开发环境下进行的软件测试。

2.3.14  软件确认应当确定用户测试、临床评价、评审等活动要求，涵盖现成软件、网络安全的确认要求，并保持相关记录。保证软件满足用户需求和预期目的，且软件已知剩余缺陷的风险均可接受。

解读：    

软件测试结束之后，就应该是软件确认了。

其实和设备的安装调试之后该做确认与验证一样的道理。

软件确认，更关注用户测试、临床评价、评审等活动。

什么是用户测试？就是软件的操作使用、性能功能测试（见下一条）。

对于医疗用软件，更关注临床疗效，对于制药设备软件，更关注使用功能。

如何评估软件的已知缺陷的风险是否可接受，当然是和患者安全与疗效相关的。

2.3.15  用户测试应当依据用户测试计划在真实使用环境或模拟使用环境下实施，涵盖现成软件、网络安全的测试要求，确定缺陷管理、风险管理、可追溯性分析、评审等活动要求，形成用户测试记录、测试报告以及评审记录并经批准，适时更新并经批准。可追溯性分析此时应当分析用户测试与用户需求、用户测试与风险管理的关系。

解读：   

这一条和2.3.13的要求是一样的，只不过这一条是针对用户的“用户测试”，2.3.13是针对软件开发商的“单元测试、集成测试、系统测试”。同样需要关注用户测试的测试计划、测试记录、测试报告以及评审记录。用户测试过程应关注缺陷管理、风险管理、可追溯性分析、评审等活动要求。

2.3.16  软件更新应当形成文件，涵盖现成软件、网络安全的变更控制要求，确定软件更新请求评估、软件更新策划、软件更新实施、风险管理、验证与确认、缺陷管理、可追溯性分析、配置管理、文件与记录控制、评审、用户告知等活动要求，形成相关文件和记录并经批准，适时更新并经批准。软件版本变更应当与软件更新情况相匹配。验证与确认应当根据软件更新的类型、内容和程度实施相适宜的回归测试、用户测试等活动。

解读：   

软件更新，当然需要变更控制，软件本身的每一部分的变化，都需要启动变更控制，按照既定的流程进行评估、策划，考虑风险控制、确认验证，考虑存在的缺陷的处理、文件记录的管理，当然最重要还是需要告诉用户。

软件版本的变更，那就更重要了。

验证确认活动的范围和程度，需要根据变更的类型、内容、程度进行评估，应采用与变更类型及风险相适宜的测试与评估方式。

2.3.17  软件缺陷管理应当形成文件，确定软件缺陷评估、软件缺陷修复、回归测试、风险管理、配置管理、评审等活动要求，形成软件缺陷分析报告以供评审。使用缺陷管理工具保证软件质量，并贯穿于软件生存周期全过程。

解读：     

软件存在BUG是很正常的事情，上市N多年的成熟商用软件，依然会有缺陷和漏洞，所以，供应商会不停地提供补丁，用户也会不断上报缺陷。对于医疗用独立软件，基于对患者的风险，用户（医疗机构）和软件开发商都应建立缺陷管理制度和规程，对缺陷进行上报、评估、修复、测试、软件变更、配置和评审管理。软件开发过程的“缺陷管理工具”，是专业的工具。

2.4  采购

2.4.1  现成软件采购应当形成文件，根据现成软件的类型、使用方式、对产品质量影响程度，确定分类管理、质量控制、供应商审核等活动要求。 

解读：     

本文中的软件，应该是指用于“医疗目的”的软件；独立软件指“运行于通用计算平台”“不依赖于医疗器械”就可以起到“医疗”作用的软件；软件组件指“控制或驱动医疗器械硬件或运行于医用计算平台”的软件。

现成软件，指“不是自己开发的、市场买回来的、或者委托第三方开发的”软件，有可能是软件外包，比如波音外包给印度公司的737MAX软件，现在还在停飞中。又比如，医疗器械公司买回来装到自己生产的医疗器械上“控制或驱动医疗器械硬件或运行于医用计算平台”的软件。又比如医院买回来的“独立软件”。又比如企业买回来的设备上的自动化控制软件。

这些软件，都是“采购”回来的，当然要有文件（难道是URS/合同/图纸/资料/FAT/SAT/DQ/IQ/OQ/PQ……？），影响性评估、关键性分类、质量控制、供应商审核……当然是必须的了，具体要求，和风险程度一致。

2.4.2  应当与供应商签订外包软件质量协议，明确外包软件需求分析、交付形式、验收方式与准则、设计开发文件交付、知识产权归属、维护等要求以及双方质量责任承担要求。

解读：     

和械企与原辅料供应商签订质量协议是一个意思，医疗机构购买医疗用独立软件，医疗器械生产商购买医疗器械的控制程序软件，都需要和软件开发商或软件生产商签订质量协议。负责任的话，就责任重大，不负责任的话，就是一纸空文。除了信任，也还是需要有一定的契约精神吧。

2.4.3  云计算服务协议应当明确网络安全保证、患者数据与隐私保护等责任承担要求。

解读：     

当今社会，大数据、云服务……如火如荼，网络安全、隐私保护……更是火上浇油（无语表达）……安全保证，需要技术，承担责任，需要承担后果，否则都是空话。

2.5  生产管理

2.5.1  软件发布应当形成文件，确定软件产品文件创建、软件产品与文件归档备份、软件版本识别与标记、交付形式评估与验证、病毒防护等活动要求，保证软件发布的可重复性。

解读：     

生产管理，软件的生产，当然就是软件的“开发与测试”了，开发与测试，前面都讲过了，这一段是讲软件的“发布”，或者算是软件的销售吧，和软件的采购相呼应，只是采购可能是一份就够了。销售或发布，也可以叫做软件的物理复制（生产），是N份，各种活动，当然要求保证软件发布的可重复性，否则卖出去的软件都不一样，那就惨了。

2.5.2  物理交付方式应当确定软件产品复制、许可授权以及存储媒介包装、标记、防护等要求，网络交付方式应当确定软件产品标记、许可授权、网络安全保证等要求。

解读：     

软件发布了，如果你不花钱，当然是不能用的。当然了，盗版也可能可以用，但那是违法的。所以，物理交付（光盘、U盘、移动硬盘……）要规定是否可复制、可复制多少份、是否需要许可授权、物理标识要求、物理防护要求。当然也可以网上下载，付款之后给你下载地址、下载权限，或者可以免费下载，但是不花钱是不能用的。或者是试用版？试用出了问题，谁负责？许可授权、网络安全，是很重要，否则带来病毒就麻烦了。

2.6  质量控制

2.6.1  软件产品放行应当形成文件，确定软件版本识别、安装卸载测试、产品完整性检查、放行批准等活动要求，保持相关记录。

解读：     

软件放行，指的是软件开放商的放行，还是软件生产商（物理复制商或销售商）的放行，我想应该是销售商（或者批量生产商），就和药品的成品放行一样，软件开发商是研发单位，软件生产商，某种意义上就是软件介质的制造商，当然介质上有软件数据，这样的产品（软件）需要经过QA审核、质量受权人放行吧！成批的物理交付放行还好，如果是网络交付？怎么放行？也就是放行到网上的特定下载地址，就OK了吧。

2.7  销售和售后服务

2.7.1  软件部署应当形成文件，确定交付、安装、设置、配置、用户培训等活动要求，保持相关记录。

解读：     

软件部署是什么？还不就是软件在用户那儿进行安装嘛……首先是交付给用户，然后按照SOP进行安装、参数设置、工作流程配置，然后是培训，教会用户操作、维护、应急处理（软件备份、软件恢复……）、软件升级、软件更新版本……做你所写、写你所做，记录是一定要有的。

2.7.2  软件停运应当形成文件，确定停运后续用户服务、数据迁移、患者数据与隐私保护、用户告知等活动要求，保持相关记录。

解读：     

软件的生命周期活动，当然都要有记录，软件停运，当然不能把数据都丢了，一是软件开发商或者销售商停运软件，要通知用户，二是用户自己不用了停掉了，数据的转移存储、数据的安全……重中之重。还有很多软件你花钱买的只是一定时间内的使用权，超过时间就不能用了，要续费的，这个大家都懂。

2.8  不良事件监测、分析和改进

2.8.1  数据分析控制程序应当涵盖软件缺陷、网络安全事件要求。

解读：     

企业（软件开发商、软件的物理生产商、医疗机构……）都应该建立数据分析控制程序吧，需要对软件的使用进行定期的回顾分析和监测，登记软件的缺陷、网络安全事件，并不定期进行软件的修补、改进……

2.8.2  网络安全事件应急响应应当形成文件，确定网络安全事件风险管理、应急响应措施验证、用户告知、召回等活动要求，保持相关记录。

解读：     

网络安全，事关重大，应急预案，当然很重要，基于风险，应急响应措施应验证，说白了，就是进行应急预案的演练呗，这种演练是不是要像消防演练一样定期做？基于风险吧。

第三部分  术  语

3.1 下列术语的含义是：

独立软件：具有一个或多个医疗目的，无需医疗器械硬件即可完成自身预期目的，运行于通用计算平台的软件。

软件组件：具有一个或多个医疗目的，控制、驱动医疗器械硬件或运行于医用计算平台的软件。

软件安全性级别：基于软件风险程度分为轻微、中等和严重，其中轻微即软件不可能产生伤害，中等即软件可能直接或间接产生轻微伤害，严重即软件可能直接或间接产生严重伤害或导致死亡。

软件验证：通过提供客观证据认定软件开发、软件更新某一阶段的输出满足输入要求。

软件确认：通过提供客观证据认定软件满足用户需求和预期目的。

软件可追溯性分析：追踪软件需求、软件设计、源代码、软件测试、软件风险管理之间的关系，分析已识别关系的正确性、一致性、完整性和准确性。

软件更新：生产企业在软件生存周期全过程对软件所做的任一修改，亦称软件变更或软件维护。

软件停运：生产企业在软件生存周期过程末期终止对软件的售后服务和销售，亦称软件退市。

现成软件：生产企业未进行完整生存周期控制的软件，包括遗留软件、成品软件、外包软件。

遗留软件：生产企业以前开发但现在不能得到足够开发记录的软件。

成品软件：已开发且通常可得到的，但生产企业未进行完整生存周期控制的软件。

外包软件：生产企业委托第三方开发的软件。

网络安全：保持医疗器械相关数据的保密性、完整性和可得性。

第四部分  附　则

4.1  本附录由国家药品监督管理局负责解释。

4.2  本附录自2020年7月1日起施行。