【做有源器械的注意了!】软件等级不是研发说了算

核心观点：软件安全等级分类，不是研发拍脑袋定的。它必须基于风险分析，且直接决定你注册资料的厚度和审评老师用什么标准来考你。

做注册这几年，软件研究资料被打回的原因来来回回就那么几个。但排在第一位的，永远是同一个：

软件安全等级分类，定得没有依据。

研发说"这个软件很简单，不会出事的，定A类"。你收了资料，整理进申报文件，递上去。然后审评老师一句补正："请依据风险分析结果，重新确认软件安全等级分类的合理性。"

翻译成人话：你这个A类，是怎么来的？拍脑袋来的？

然后就开始了——等级从A升到C，软件描述文档推翻，开发过程文档推翻，验证报告推翻。三个月白干。项目组开会互相甩锅，研发说"你们注册怎么不早说"，你说"你们研发当初不是说A类没问题吗"。

这种事我见过太多了。根源在哪？在于大多数团队——包括不少注册专员——没搞清楚一件事：软件等级分类这个决定，到底谁来做、怎么做、做错了谁承担后果。

这个分类，不是研发说了算

很多注册同事的默认认知是：软件等级是技术问题，研发定就行，我只管收资料交资料。

搁五年前，这种心态勉强能过。2022年药监局修订了《医疗器械软件注册审查指导原则》之后，不行了。

审评老师现在看软件研究资料，第一个看的就是等级分类有没有依据。你说A类，依据在哪？有没有做过风险分析？分析结论是什么？有没有记录？

核心观点：没有依据的等级分类，等于没有等级分类。

而等级一旦定了，后面所有的东西都跟着走——你的软件描述文档写多厚、你的开发过程留多少记录、你的验证测试覆盖到什么粒度，全由这个等级决定。

A类和C类的差距不是"多写几页纸"。A类基本上只需要一份功能描述。C类呢？需求规格说明书、架构设计文档、详细设计说明、单元测试记录、集成测试报告、系统测试报告、风险管理贯穿全程——一个都不能少。开发团队在整个项目周期里的文档工作量，可能差出五到八倍。

你提交了A类，审评扫一眼过了。你提交了C类，审评会逐条对照——需求追踪链有没有断、测试用例有没有覆盖所有风险控制措施、软件变更有没有走完整的评审流程。

你交什么等级，就是主动告诉审评老师用什么尺子来量你。

审评到底在看什么

这里有一个认知差，很多注册同事没有跨过去。

YY/T 0664-2020是一份过程标准。这话你可能听过，但你不一定想过它对你意味着什么。

拿你熟悉的GB 9706.1来对比——那是性能标准。审评看结果：漏电流超不超标、绝缘够不够。你过程怎么做的他不管，结果过了就行。

YY/T 0664反过来了。审评看的是你做事的方式。你的需求分析有没有遗漏关键功能、你的架构设计有没有考虑风险控制、你的测试用例有没有对准需求一条条验证、你的软件变更有没有经过评审和回归测试——这些都是"过程"。

说白了，你的软件研究资料不是在证明"我们的软件好用"，是在证明"我们的开发过程是规范的"。

我见过太多研发写出来的软件描述文档，通篇在讲功能有多强大、技术有多先进、算法有多精准。审评老师看完内心毫无波澜——我不关心你有多厉害，我关心的是你的需求文档在哪、你的测试报告谁签的字、你的变更记录闭环了没有。

提醒：注册如果理解了这一点，跟研发的沟通就不是"你给我补资料"，而是"你告诉我你开发过程中这几步做了没有"。沟通效率完全不一样。

有一个坑特别容易踩

研发经常说："我们硬件有保护电路，软件失效了也不会伤到人，所以可以降级。"

这话对不对？标准里确实有这条——如果有独立于软件的硬件安全保护机制，软件等级可以降低。但条件非常严格：

硬件保护必须跟软件完全独立。你不能说"硬件看门狗复位了软件就好了"——看门狗本身就是跟软件配合的，不算独立。必须是那种软件彻底死了、硬件照样能防住危险的机制。

而且，这个降级推理必须写进风险分析文件里，不能口头说"我们有硬件保护"就算数。

更常见的坑是模块分级。一个C级系统里，日志模块可能确实是A级，数据显示模块可能是B级。但前提是你在架构上做了隔离——低等级模块崩了不会拖垮高等级模块。如果架构上没隔离，全系统按最高等级走。

很多团队根本没做过这种架构层面的隔离分析，就直接给不同模块定了不同等级。审评一看：你模块之间数据流是通的、错误会传播——凭什么定A级？

注册在这个环节该做什么

落到行动层面，注册不需要变成软件工程师，但有三件事你得卡住。

第一，介入时机。等级分类应该在项目早期、风险分析阶段就确定。你不需要参加技术讨论，但你需要确认这件事发生过——研发做过风险分析、分析里考虑了软件失效场景、结论里明确了等级、记录在风险管理文件里。如果研发给你的等级分类只是一张表、没有风险分析支撑，你有充分理由打回去。

第二，匹配性检查。等级定了之后，看文档"厚度"对不对。A类配两页功能说明，合理。C类只配一份测试报告？缺东西。你不需要判断技术细节对不对，但你能判断"这个等级应该有的文档，是不是都有了"。

第三，确认和验证不是一回事。研发经常把系统测试报告当软件确认提交上来。但YY/T 0664明确说了——标准不覆盖软件确认。确认是产品层面的活动，在真实或模拟使用环境下验证软件满足用户需求。系统测试是验证活动，不是确认活动。两个都要有，不能用一个顶两个。

注意：如果研发只交了测试报告当确认，你该追问：这个测试覆盖了实际使用场景吗？有没有用户参与？

最后

十年前做注册，软件研究资料可能就是个附件，审评老师翻一翻就过了。现在不行了。含软件的医疗器械越来越多，审评对这块的审查只会越来越细。

你不需要懂代码，但你需要知道：软件等级分类是你在注册这条线上遇到的第一个关口，也是最重要的关口。定错了，后面所有的工作都建在沙子上。

研发说A类没问题的时候，你问一句：依据在哪？

这一句话问出来，你就不是资料搬运工了。