一、软件测试/检验
1、软件文字的一些变更，例如改名称，改某个界面的基本信息，不涉及代码的改动，这种要不要做软件相关验证？
应评估这种改动对软件系统的影响，然后根据评估结果开展不同程度的验证。一般来说，如果是很小的完善性改动，也应及时进行单元测试，以验证改动的有效性。医用软件作为医疗器械具有安全性和有效性的特性，更应重视产品的修改对性能、安全和有效性的影响。
2、每次软件更新，需要做验证吗？形成验证报告吗？
软件更新，不论程度大小，都应及时开展验证，有的甚至持续多轮。以验证有效性并避免产品版本降级。应根据影响程度不同开展单元测试、集成测试甚至于系统测试。验证报告，就我经验来看，有条件的应形成多轮测试报告，根据BUG数据分析BUG的收束情况。没有条件的，至少应提供最大版本的更新验证报告。
3、软件更新，仓库没有出库的机器也更新的话，需要怎么流程？批记录需要改和重新放行吗？
软件已更新，但产品已经过检验合格到了成品库，待发货的状态下，应由生产人员发起退货申请，明确产品生产日期、生产批号、数量，申请退回理由-生产负责人批准-库管员清点产品，填出库单，明确出库日期、出库产品信息、出库数量及出库原因-库管员及申请人双方核对并签字，各自留存出库单-出库-库管员更新库存信息-申请人进行退回产品的更新。
生产批记录需修改，体现产品的可追溯性。生产完成后也应重新进行检验及放行。
4、已经到代理商和客户给他们更新，需要做什么吗？
类似主动召回：
如果到了代理商那里，想要进行软件更新的话，应发起正式召回通知，写明事由，涉及产品名、规格型号、注册证号、生产批次、数量，还有更新后产品的更新点、更新产品的到货日期都应写明。这件事情的联系人、联系方式。对于在此期间给客户造成的不便表示道歉。通过正式渠道（如在公众号上发布通知等）。
对于召回的产品，应首先到成品库的召回区，库管员登记后，生产人员发起出库申请-出到生产区，重新进行产品更新工艺操作，经过检验-放行审核-成品库入库-出库。
5、渗透测试和漏洞扫描区别吗？
是什么 | 优点 | 缺点 | 比喻 | |
渗透测试 | 使用自动化工具（扫描器）对目标系统（网站、服务器、网络设备等）进行扫描，将其与漏洞特征数据库（如CVE）进行比对，从而列出可能存在的安全弱点。 | 快速全面：能快速扫描大量资产和端口。 成本低：自动化执行，人力投入少。 持续监控：可定期执行，适合纳入日常安全运维。
| 误报率高：工具无法判断漏洞在具体环境中的真实可利用性，常报告“假阳性”。 漏报：无法发现逻辑漏洞（如业务越权、密码重置缺陷）、新型的或未知的（0day）漏洞。 缺乏上下文：只告诉你有漏洞，不告诉你攻击者如何组合利用它，能造成多大实际损害。 | 就像用金属探测器在沙滩上扫一遍。它能“嘀嘀”响，告诉你下面可能有金属（漏洞），但挖出来可能只是个易拉罐拉环（误报），也可能真的是一枚金币（高危漏洞）。但它无法告诉你如何用这枚金币换取更多价值（攻击路径）。 |
漏洞扫描 | 在授权和可控范围内，由专业的渗透测试工程师像真正的黑客一样，使用各种技术手段（包括但不限于工具扫描）对目标进行主动攻击。目的是绕过安全防护，获取敏感数据或系统控制权，从而评估系统的真实防御能力。 | 准确性高：验证漏洞的真实危害，极少误报。
发现深层问题：能发现业务逻辑漏洞、社会工程学弱点、跨漏洞组合攻击链等。
提供实战洞察：不仅指出问题，还演示攻击路径，帮助企业理解攻击者的视角，评估实际业务风险。 | 成本高、周期长：高度依赖专家经验。 无法持续频繁执行：通常按项目（如每年、每季度）或重大变更后执行。 范围有限：在约定时间和范围内测试，可能无法覆盖全部资产。
| 就像聘请一个经验丰富的保险箱大盗来测试你家保险箱。他不仅会检查锁是否牢固（漏洞扫描），还会尝试听密码旋钮的声音、查找保险箱设计缺陷、甚至从通风管道潜入房间（攻击路径）。最后他会告诉你他是如何成功打开的（报告），以及你需要加固哪里（修复建议）。 |
如果你需要... | 应该选择 |
满足基础的合规检查（如等保）、快速了解资产风险概况、日常安全巡检 | 漏洞扫描 |
验证系统在面对真实攻击时的抵抗能力、发现复杂的安全隐患、测试应急响应流程、进行上线前深度评估 | 渗透测试 |
6、软件的互操作性指的什么？
注册材料要求中提到：互操作性产品若通过电子接口与其他医疗器械或非医疗器械交换并使用信息。应当提供互操作性研究资料，包括基本信息、需求规范、风险管理、验证与确认、维护计划等内容。
通常分为四个层次，类似于人际交流：
层次 | 名称 | 描述 | 比喻 |
第一层 | 技术/物理互操作 | 系统之间能建立基础的连接和通信。例如，通过网络协议（TCP/IP）传输比特流。 | 电话线接通了。双方能听到声音，但可能完全听不懂对方在说什么。 |
第二层 | 语法互操作 | 系统能解析数据的格式和结构。交换的数据遵循共同的语法规则，如XML、JSON格式。 | 双方都说英语句子。我能识别出你发来的是一串符合英语语法的字符，但我可能不理解这个专业句子的具体含义。 |
第三层 | 语义互操作 | 这是最关键也是最难的一层。系统不仅解析格式，更能理解数据的准确含义。对于同一概念，双方有统一的理解。例如，都明白“患者ID”这个字段指代的是什么。 | 双方对专业术语有共同定义。我说“心肌梗塞”，你完全明白是指一种心脏病，而不是别的什么。我们能在专业层面进行无歧义的沟通。 |
第四层 | 组织/流程互操作 | 不同系统间的交互能够支持跨组织的业务流程和目标。这涉及业务规则、流程的协调和安全性、治理等。 | 不仅沟通无碍，还能一起高效地完成一个手术。医生、护士、麻醉师各司其职，配合默契，共同实现“救治病人”这个最高目标。 |
二、生产：
7、什么是嵌入式软件？
日常生活中例如血压计、点读笔、电子体温计等，能将控制程序写入设备中的软件就是嵌入式软件。
8、软件烧录是否属于特殊工序，有什么依据或说法吗？
软件烧录是生产工序的其中一个工序，是否属于特殊工序，由公司的技术负责人或生产负责人根据产品实际情况判断。此外，在新版GMP要求的验证和确认章节，提到了特殊过程应经过确认。
三、安装：
10、云服务商和自己搭建的云计算平台，这两种情况分别怎样？
11、独立软件云端部署技术要求有什么要求，注册资料需要提供哪些资料，及参考依据。
除了常规的软件研究资料、产品技术要求、说明书以外，还需要依据《医疗器械网络安全注册技术审查指导原则》，提供网络安全文档，包括基本信息、实现过程、漏洞评估、结论等内容，详尽程度取决于软件安全性级别。其中，基本信息包括软件信息、数据架构、网络安全能力、网络安全补丁、安全软件，实现过程包括风险管理、需求规范、验证与确认、可追溯性分析、更新维护计划，漏洞评估明确已知漏洞信息。
四、注册：
12、pems文档，文档结构和重点审查内容；
PEMS：可编程医用电气系统，在《GB 9706.1-2020》标准的14章 “可编程医用电气系统”中对文档提出要求。
文档结构是
1、生存周期过程文档（含需求设计、概要设计、详细设计、验证与测试文档、发布与部署）：
2、风险管理文档（含计划、过程、控制措施）
3、问题追踪文档（问题与变更控制记录，记录所有缺陷、变更请求，并跟踪从提出到关闭的全过程）
4、维护与退役文档（软件维护计划、定义上市后如何提供支持、修复问题和更新）
重点审查内容
1）需求的可追溯性与一致性（任何无法追溯到源头或没有验证证据的需求，都是重大缺陷）
2）风险管理的融入与闭环
3）软件验证的充分性与独立性
(1)测试覆盖度：测试是否覆盖了所有功能需求、非功能需求（如性能、安全性）和关键风险？
(2)测试环境真实性：测试是否在尽可能真实的或模拟真实的环境中执行？
(3)回归测试：任何变更后，是否执行了充分的回归测试以确保未引入新问题？
(4)验证的独立性：系统测试的执行者是否独立于开发人员，以确保客观性？
4）变更控制的严格性
所有变更必须受控，审查会重点关注变更流程的严谨性：
任何变更（即使是微小缺陷修复）是否有正式的申请、评估、批准流程？
变更评估是否包含了对需求、设计、风险、验证的全面影响分析？
变更实施后，相关的文档（需求、设计、测试用例）是否同步更新，以保持文档一致性？
5） 软件体系结构的安全可靠性
① 审查软件设计本身是否内建了安全性和可靠性：
② 防御性设计：是否考虑了无效输入、异常情况、硬件故障等处理机制？
③ 安全关键功能隔离：安全关键功能（如给药控制）是否与非关键功能有效隔离？
④ 容错与恢复：系统是否具备从错误中安全恢复或进入安全状态的能力？
6）文档的完整性与质量
文档本身的质量直接影响审查效率和结论：
清晰准确：文档描述是否清晰、无歧义？版本标识是否明确？
及时性：文档是否与开发活动同步创建和更新？
规范性：是否遵循了在生存周期计划中定义的模板和标准？
审查实战建议
准备“需求追溯矩阵”：这是应对审查最有力的工具，能直观展示所有需求的来龙去脉。
聚焦“安全与风险”：始终将“风险控制”和“患者安全”作为文档描述和测试设计的核心逻辑。
保证“闭环”证据：对于任何活动（如问题修复、风险管理），都要提供从“发现”到“关闭”的完整证据链。
模拟审计：在正式审查前，组织内部或邀请第三方进行模拟审计，提前发现文档缺口。
总的来说，PEMS文档审查是一个系统性、证据驱动的过程。其核心逻辑是：每一个需求都应有据可依，每一行关键代码都应知其所以然，每一个风险都应受控可追踪。
13、软件可追溯和网络安全可追溯有没有既合规又便于操作的法？
软件可追溯性的确工作量很大，建议采用工具实现。例如 北京水木金昇医疗科技服务
有限公司的那套系统。“软件研发合规化平台”。
网络可追溯性：依据法规：《网络安全注册技术指导原则》网络安全同时还应提供网络安全可追溯性分析报告，即追溯网络安全需求规范、设计规范、测试、风险管理的关系表。
个人理解：在需求设计阶段，除了设计软件的功能方面需求以外，还应同时考虑网络安全及风险管理的需求，这里要求提供的就是一个网络安全方面需求从需求、设计、测试这
三个阶段的追溯关系图，由于医疗器械的特殊性，在需求分析阶段还应综合考虑网络安全在风险管理方面的需求。
14、请教下独立软件需要这6份三阶体系文件吗？1.《软件数据安全管理制度》2.《软件测试管理规范》3.《软件编码管理规范》4.《开发和测试工具管理规范》5.《计算机使用管理规范》6.《信息系统密码管理规范》
从软件企业的代码管理、信息安全管理规范性来看，这6份文件都是需要的。这个问题需要结合实际情况来分析。是在注册或者检验过程中被要求必须提供吗？
五、上市后不良事件处理
15、现在软件的SBOM如何搭建？软件故障后如何做纠正预防启动CAPA调查，是否有对应的方法论？
CAPA：
第一步：事件响应与遏制
目标：防止影响扩大，为调查保留现场。
立即行动：隔离故障服务、回滚到稳定版本、发布服务降级公告。
关键记录：完整保存故障时间点的**日志、监控指标、错误截图、用户报告。在云端环境中，务必第一时间为相关实例和资源创建快照。
第二步：根本原因调查（核心）
这是CAPA的成败关键。切忌停留在表面原因（如“代码有Bug”），必须深入流程和系统层面。除了流程图中的方法，这里再详细说明两种：
1. 5 Why分析法：连续追问“为什么”，直到触及根本原因。
例：故障是“服务器崩溃”。
Why 1: 为什么崩溃？→ 内存耗尽。
Why 2: 为什么内存耗尽？→ 新上线功能有内存泄漏。
Why 3: 为什么没发现内存泄漏？→ 功能测试未包含压力与长时间运行测试。
Why 4: 为什么测试用例没覆盖？→ 测试用例设计规范未要求对资源类问题进行专项测试。
根本原因：测试流程与规范存在缺失。修复措施就是更新测试规范，而非仅仅修复那段泄漏代码。
2. 鱼骨图（石川图）或故障树分析（FTA）：
对于复杂故障，用鱼骨图从人、机、料、法、环、测等多个维度（软件领域可对应为：人员、环境、工具、方法、需求、代码）头脑风暴所有潜在原因。
故障树分析（FTA）则从顶事件（故障）向下逐层演绎，分析所有可能导致故障的逻辑组合，非常适合分析安全关键系统的失效路径。
第三步：制定并实施措施
根据根因，制定针对性措施：
纠正措施：修复当前的故障。例如，修复内存泄漏的代码、重启服务、恢复数据。
预防措施：防止同一根本原因在未来再次引发问题。这是CAPA的灵魂。例如：
更新测试规范，强制要求对资源泄漏进行测试。
在CI/CD流水线中增加静态代码分析或内存检测工具关卡。
修改架构设计指南，对缓存使用、循环引用等做出明确规范。
对团队进行代码评审或故障复盘培训。
第四步：验证效果与关闭
验证：措施实施后，需通过测试、监控、审计等方式验证其有效性。例如，验证新测试用例能否发现同类缺陷，监控后续版本是否出现类似内存增长。
关闭：验证通过后，正式关闭CAPA。必须将本次故障的分析过程、根本原因和有效措施，更新到组织的“经验教训库”或“典型故障案例集”中，并通知相关团队，完成知识传递。
关键输出物（CAPA记录表）
一个完整的CAPA记录通常包括：
| 项目 | 内容 |
| 问题描述 | 清晰描述故障现象、影响范围和严重程度。 |
| 遏制措施 | 为控制影响所采取的紧急行动。 |
| 根本原因 | 使用上述方法论得出的深层原因。 |
| 纠正与预防措施 | 具体的修复行动和体系改进计划。 |
| 责任人/完成时限 | 明确的任务分配。 |
| 效果验证 | 如何验证措施有效的证据和方法。 |
| 关闭批准 | 由质量或负责人审核后关闭。 |
核心要点：CAPA的成功不在于处理了多少故障，而在于通过多少次故障，真正改进了多少开发流程、设计规范或团队能力。这是一个将负面事件转化为组织核心资产的过程。
2025-12-25
快速检索
微信公众号
官方百家号
官方头条号
官方微博
