1、目的
越简洁越好，例如：“规范医疗器械软件生存周期过程控制。”

2、适用范围
越简洁越好，例如“适用于xx公司所有医疗器械软件软件设计和开发控制，覆盖从初始概念到最终停用和处置所有阶段的生存周期控制。”

3、职责
职责描述注意点：

越贴近公司组织架构越好，与岗位职说明书保持一致、最好不要以项目维度重新定义项目角色，以免造成沟通成本增加和职责不清现象。

越贴近业务流程越好，与业务流程所需职责保持一致，最低要cover住业务流程所需职责，以防止体系运行时出现无人负责情况。

岗位职能齐全，就算只有2人开发的医疗器械软件，也要开发和质量（测试）两个独立岗位。

例如这样设置：

3.1 研发负责人

产品经理、技术负责人职责都合并到这个角色上；

3.2 评审团队

略

3.3 质量

项目经理和质量可合并到这一个角色上；

3.4 项目组

各职能部门职责用统一话术描述，但是要根据组织架构介绍项目组，不要有遗漏，例如：

项目组成员包括：研发、质量、采购、注册、生产等，具体职责如下：

制定职能领域内工作计划、并与整体项目计划保持一致；

完成产品设计和开发计划中职能领域的活动和交付；

与职能部门负责人沟通相关问题。

4、定义
描述此文件中用到的所有术语，特别是法规中有定义的术语，一定要与法规保持一致，目的防止出现鸡同鸭讲现象。例如：

4.1 生存周期

生存周期是指从一个医疗器械最初概念的形成到最终的退出市场和处置的整个生命中的全部阶段(包括：设计开发阶段到监控&维护阶段)。

4.2 设计历史文档（DHF）

设计历史文档是指对于一个设计完成的医疗器械产品，描述该设计历史记录的汇编，称为设计历史文档。

4.3 验证（Verification）

验证是指通过检查和提供客观证据来证实设计输出实现了设计要求。

4.4 确认（Validation）

确认指通过检查和提供客观证据来证实一个过程或设计，能始终如一的满足一定预期用途的特殊要求。

5、流程图
纯软件开发采用敏捷模式的比较多，但是从最最根本上来讲，我们还是用软件工程（在软件（包括程序和文档）设计，实现，测试，运行，维护的各过程中，建立在科学基础上的一套实用方法。）来完成每次迭代的功能。所以敏捷模式也是可以的。因为要保证医疗器械软件有效和安全，跟非医疗器械软件比，在软件生存周期控制上主要有如下几点不同：

a） 风险管理要求比较高，需要实实在在的做风险管理，而且全生存周期管理。

b） 记录要求比较高，特别是设计文档、验证记录、可追溯性、评审记录等，这相当于是对风险管理的另外一种手段。----设计大家都理解，但是验证记录、追溯性、评审记录为啥要有呀？没有的话，可能就会漏做，举个曾经在一家公司亲身经历过的未按照规则评审返工的例子，我们对单元测试评审的内容主要2块：1测试报告，2测试日志，有一次开发改了代码，单元测试脚本改错了，测试报告上显示所有用例测试通过，但是日志显示有问题，大家当时就没按照单元测试评审的要求进行评审，这个问题一直到系统测试结束，所有测试记录归档前最后复审时才发现。你设身处地的想象一下，这是团队当时是什么感受。

c） 验证过程特有的注册检验，这验证过程可以理解为监管机构委托第三方对企业开发出来的医疗器械软件进行验收，验收合格可以执行下一步，不合格打回。

d） 验证过程特有的临床试验，其实这个验证过程可以简单理解为互联网的灰度发布验证过程，即少量真实用户使用，在一定程度上可代表用户确认。

e） 运行环境发布特有要求，是要根据医疗器械软件注册审查指导原则相关要求，做相应的变更注册或备案。

6、程序
6.1 总述流程输出物表xxx（也可以直接用DHF代替）和流程裁减说明准则。例如：需要对软件生存周期管理流程各阶段的活动和交付物进行删减、合并、拆分、修改或补充时，应在流程输出物表xxx中说明结果和理由。本文中提及“适用时”且未指明适用条件的，一般应选择为“适用”；若选择为“不适用”，应在流程输出物表xxx中说明不适用的理由。这些裁剪行为需遵守以下的原则：

a） 任何对基础流程应用的裁剪不能违反该产品应当符合的法规和标准；

b） 裁剪活动由质量负责主导，在“流程输出物表xxx”中说明；

6.2 流程图上各个节点的输入输出详细要求介绍，对于需要输出记录的，写输出记录具体要求，对于需要符合作业指导书要求的引出操作指导书，如果不知道写什么，就参考YYT 0664要求细化，例如：软件系统测试

软件系统测试活动主要作用是验证软件的系统功能是否全部实现《软件需求说明书》中所述的全部功能。

1.为软件需求制定测试项:针对《软件需求说明书》中每个需求，设计详细的《软件系统测试用例》。并其进行评审，确保所有用例满足如下要求：

a） 无相互矛盾用例;

b） 无避免模棱两可的描述;

c） 已制定相应的测试标准和性能要求，以评估系统能达到测试标准；

d） 可唯一识别（有用例编号）。

2.使用软件问题解决过程：参照《缺陷管理作业指导书》执行缺陷管理。

3 更改后再测试：当软件发生更改后，应评估更改后的测试范围，即更新《软件系统测试用例》描述（例如增、删原有用例、或筛选需要复测用例）。以确保用例满足如下要求：

a) 重复或补充测试，来验证问题已经被修复。

b) 已更新的测试用例，可以证实没有引入非预期的副作用。

c) 已按照《医疗器械风险管理控制程序》，进行更改后再测试过程的风险管理活动。

4 软件系统测试记录内容：测试系统测试记录于《软件系统验证报告》中，为了支持可重复性测试记录需包含以下信息：

a） 对测试案例程序参考，以说明所需行动和预期结果;

b） 测试结果（通过/失败和异常列表）;

c） 被测试的软件版本;

d） 相关软硬件测试配置;

e） 相关测试工具;

f） 测试的数据;

g） 负责执行测试并记录测试结果人的工号。

5 评价软件系统测试：根据《软件验证计划》评价《软件系统验证报告》，确保其满足如下要求：

a) 《软件需求说明书》中的所有需求都在《软件系统验证报告》中体现，且都以测试或评审等其他方式验证通过；

b) 《软件验证计划》已描述软件系统测试用例如何追溯到软件需求；

c) 《软件系统验证报告》记录的结果已满足指定的通过/失败标准。

7、参考文件
《医疗器械风险管理控制程序》

《缺陷管理作业指导书》

8、记录
《流程输出物表xxx》此表里包含记录中所有的文件名称，各表单需要包含哪些信息，后续统一放到实践样例中表述。

《软件需求说明书》

《软件验证计划》

《软件系统测试用例》

《软件系统验证报告》

《评审记录》

9、变更记录