问：什么是过程三要素？答：输入、活动、输出。

每一个过程，都有其输入、活动和输出。

过程

从产品全生命周期来看，医疗器械的输入是用(市)户(场)需求，活动是产品开发，输出是具体的医疗器械。

产品开发的输入是用户需求的输出，是具体设计的工程语言，如各项性能指标。产品开发的活动是各种测试。产品开发的输出是各种测试的结果。

医疗器械输出的输入是各种测试的合格结果，医疗器械输出的活动是按监管要求准备并提交注册相关的资料，医疗器械输出的输出是产品获批。

输入、输出，又输出又输入，很绕，因此个人建议，在编写设计开发程序时不要在设计开发阶段名称里加入“输入”“输出”字样，定义好阶段后，在每个阶段规定该阶段的活动和输出内容即可，而输入自然是上个阶段的输出。

GB/T 42061 idt ISO 13485第7.3章节给出的设计和开发的大致活动：

7.3.2 设计和开发策划丨7.3.3 设计和开发输入丨7.3.4 设计和开发输出

7.3.5 设计和开发评审丨7.3.6 设计和开发验证丨7.3.7 设计和开发确认

7.3.8 设计和开发转换丨7.3.9 设计和开发更改的控制

在某次13485培训课上，老师提到，有很企业是按上述章节的活动去划分整个设计开发流程其实是不太对的。

很显然7.3.5评审和7.3.9更改的控制不是设计开发的阶段，评审有阶段评审，变更评审等类别，半天一天短暂的持续时间就能结束的；变更，根据变更内容，涉及面，产品关联度，可能1个月、6个月甚至更长时间才能走完变更流程。

那设计和开发程序中的阶段划分应如何确定呢，一般根据活动内容的大小即工作量，持续时间，是否可以定义为里程碑事件等维度进行评价划分，同时还要考虑详略程度。

最简单的划分是，用户需求→产品开发→产品注册，符合过程三要素，但没有哪家企业会是这么干的，因为产品开发这个阶段的活动量大，时间长，带来的最大影响就是不好监控。

PMBOK中提到五大过程组，我觉得是可以结合瀑布流模型同时对照自个理解的设计开发控制程序思考下。

五大过程组：

启动→ 规划→ 实施→ 监控→ 收尾

瀑布流模型：

用户需求→ 设计输入→ 设计过程→ 设计输出→ 医疗器械

很雷同。实际过程中往往不会一开始就进入到项目的启动阶段，因为成不成还未知，市场情况怎样还未知，但此过程又不得不做，结果是做为项目启动/立项的依据。因此就有可研或预研一说。可研即可行性研究，一般包含3个方面，包括技术可行性、市场需求情况和财务状况，不管哪种说法，其目的是为项目的决策提供依据。因此通常会做为设计开发的第1个阶段，但该阶段一般不纳入设计开发控制范围内。也对应过程组中的启动过程组，完成项目的立项。这个阶段一般不会持续很长的时间。（P1）

接下来就是项目的规划阶段了，正式决定要做这个项目了，就得制定项目开发的计划。如：预计需要多少人力，要做出怎样的产品（要求来源于用户需求，包括内部、外部），大致的产品设计方案，工艺路线等。跟规划过程组是相对吻合的，兼并瀑布流的用户需求和部分设计输入的活动。（P2）

下一步就是项目的实施阶段了。说白了，就是正式动手开始做产品，做迭代测试，但这时候可能会有个问题，上一阶段用户需求转换而来的设计规范里的性能指标具体定多少，怎么定。个人认为应该有3个方法，第1，自己公司有没有已上市产品的数据可参考的；第2，能不能找到竞争对手的指标范围；第3，如果前者都没有，那就根据历史数据在SPC范围内取个限，做为指标限。当前阶段也对应着瀑布流的设计输入、设计过程和设计输出阶段。但请思考下，瀑布流中的设计输入、设计过程和设计输出的输入和输出分别是什么，关联性如何，能不能将这3个分别规定为里程碑事件即定义为设计开发程序的某一阶段。

PMBOK项目管理指南中也有引用里程碑的概念，是以阶段性明确的可交付物来衡量项目进度。

根据项目管理中定义来说，似乎不能将设计输入定义为里程碑事件，因为设计过程中可能会因技术原因实现困难而回过头来对设计输入进行修改，甚至是大修改，不能算是明确的交付物。

设计过程，倒是有可能可以定义为一里程碑事件，因为设计过程的输出是样(产)机(品)，但这个样机是有条件的样机，经过各种测试和迭代，被初步证明符合设计输入的要求，是符合明确交付物定义，一是产品，二是初步测试结果。注：DC指南里没有单独提设design process章节。

设计输出呢？根据GB/T 42061 idt ISO 13485第7.3.4小节，还应包括b) 给出采购、生产和服务提供的适当信息；

是指什么呢？原材料技术要求/质量标准以满足采购需求，生产操作/生产检验/生产流转卡以满足生产需求。

操作/检验相关的SOP输出，整个产品对应的生产工艺流程图也就输出来了。

原材料技术要求/质量标准的输出，对应的产品图纸、BOM也是输出来了。

上述文件即为产品的DMR文档。

同时，FDA的DC指南是这样定义设计输出的，The total finished design output consists of the device, its packaging and labeling, and the device master record.

最终的设计输出包括产品，包装和标签（注：标签出来了，其实IFU也出来了，标签的内容是部分摘至IFU里），以及产品主文档即DMR。均为明确的可交付物，因此可以定义为一开发阶段。

但结合实战经验来说，设计过程看似DOD只有产品一项，但不确定性和持续时间可能是最长的，设计输入的DOD似乎也只有一项，设计规范，但似乎该阶段定不下来明确的交付物，设计输出也有DOD，输出DMR主文档及DMR清单，主要为文件性的工作，但三个结合起来看，似乎又组成了过程的三要素

输入（是设计输入）→活动（是设计过程）→输出（是产品及DMR）

合在一起又是一个完整的过程，既然如此，何不将这3 部分一起定义为一个阶段呢？命名为产品开发阶段或产品定型阶段，可思考下。（P3）

验证（P4）和确认（P5）作为阶段，似乎大家都乐于接受。

验证，是提供证据表明设计输出满足设计输入的要求；确认，是提供证据表明设计输出满足预期用途的要求；是个明显的递进关系，做完验证做确认。

如果证据表明不满足(无论是在验证还是确认活动中)，需进行分析，找出不合格原因，并针对不合格原因实施纠正措施。出现不满足，也是认为是出现了偏差，需要进行纠偏，以使符合既定要求，从这层面来看，其实和项目管理的监控关联性是较大的，个人认为可以类比。

需要说明的是，这里的验证和确认分别包括设计和生产2个维度，设计验证(体外测试)，设计确认(体内试验即临床)，工艺验证(关键工序)，过程确认(特殊过程)。

实际执行过程中，虽然整体呈递进关系，但存在部分子活动可以提前启动/准备/执行一部分的情况，如在做设计验证的时候，可以做过程确认的OQ，但设计确认就在验证之后了。

另外，还有设计转换活动，这个活动放在什么时候，在什么阶段做，暂时不分享，个人认为不能定义为一开发阶段，至少不要单独定义，因为在这一活动的终点即设计转换完成这一事件，对于后续的活动获批注册似乎不是必要的，或者重要性并不那么重要。（P4）（P5）

完成设计确认即拿到临床试验报告后，紧接着就是准备注册事宜了，如准备项目注册相关的资料，临床和非临床的，资料准备就绪后，递交注册，然后体考、发补(如有)、回补(如有)，等待批证。批证下来后IFU、标签信息就要完成变更和备案，再之后是申请生产许可证，准备上市前备货生产了。

这一阶段事情不会很多，按注册要求准备体系资料递交即可。对于研发来说，真可以说是项目的收尾阶段。（P6）

总结一下医疗器械的产品设计开发流程：

可研→策划→开发（设计输入/输出）→验证→确认→上市

和上面提到的五大过程组和瀑布流模型是吻合的，另外，再与项目管理的过程三要素套合看看，也是首尾相连的。

获批上市后，产品生产相关的维护就转移给到供应链团队了，此时，研发的参与逐渐减少，除非有发生重大的变更。