简介：设计开发控制程序(YYT0287-2017).pdf是一份依据YYT0287-2017标准编写的医疗器械设计开发控制程序文档，面向质量体系管理人员、研发项目负责人及审核人员，帮助企业在产品策划到上市的全流程中落实法规要求、明确职责分工并保持可追溯性。文件仅1个PDF，压缩包约4KB，内容精炼，但覆盖了设计开发策划、输入、输出、评审、验证、确认、设计转换、更改过程、文档管理与供应商管理等关键环节，并逐条列出总经理、技术部、采购部、生产部、质量部的职责权限。文档中包括《设计开发策划书》编制要求、工作程序及阶段控制要点，适合作为编写内部体系文件的模板或培训材料。已有109人学习，适合医疗器械企业用于完善设计开发流程、通过体系审核以及新员工上岗培训。

1. 设计开发控制程序：YY/T 0287-2017 下的项目“施工图”，项目负责人绕不开的合规起点

这份《设计开发控制程序》在医疗器械行业里就像一份项目施工图：产品立项之后流程怎么落、输入怎么收、每一步谁签字、转换和变更怎么控，全得看它说了算。做过体系审核的人应该都有感觉，审核老师查设计开发记录时，盯得最紧的不是你那几个技术指标有多先进，而是每个环节有没有留痕、职责有没有打架。我见过不少初创医疗器械公司，技术方案没有一点问题，翻车就翻在策划书没批、输入项漏了可用性、验证和确认傻傻分不清，一张不符合项整改通知就能把拿证节奏拖慢两三个月。这份 PDF 不是拿来背的，是可以直接对照着落到自己公司质量体系里的模板。适合三类人：刚接手质量体系的新人、要给公司搭设计开发全流程的研发主管、准备迎接体系审核的注册专员。下面我按“策划 → 输入 → 输出 → 评审验证 → 转换变更 → 避坑”这条线索逐段拆开讲。

2. 策划与设计输入：立项后的第一个管理动作，先把 4 类输入项评审到位

2.1 职责权限：总经理只做任命，项目负责人才能管策划

设计开发的程序文件里，最先被实际执行的是职责权限。很多中小器械公司一份职责表把“设计开发”全部压到技术部头上，研发部既做输入输出、又自己评审验证，运动员和裁判员是同一个人，内审或者外审时这种情况最容易被挑战。YY/T 0287-2017 的核心思想是分工与受控，职责划分不清晰，后续每个环节都会出现推诿。

你可以把这份 PDF 里的职责分配直接拿来当参照：总经理负责组织建立项目组、指定项目负责人、提供人力资源和工作环境，他授权但不管细节；项目负责人主持设计开发策划，也就是编写《设计开发策划书》；技术部承担输入、输出、评审、验证、确认的组织实施；采购部管物料采购与供应商审核；生产部负责设计转换活动和样品实现；质量部负责新产品的检验试验，并参与评审、验证、确认和风险管理。

这里有一个细节值得单独提醒：程序文件里职责写的是部门，但实际执行时一定要落到具体岗位。比如“技术部负责设计和开发输入”这一条，如果公司里结构设计、电子设计、软件设计分属不同小组，那么输入文件的编制人要写明是什么岗位、硬件工程师和软件工程师分别对哪部分输入负责。我一般会建议把职责权限表做成“部门 × 活动”的矩阵，发布前让各部门负责人签阅确认。否则内审抽查时，经常会出现“我不知道这件事归我们管”的尴尬场面。

2.2 《设计开发策划书》的编制与审批：五个必须写透的内容

项目立项之后，第一份正式文件就是《设计开发策划书》。按照程序要求，这项工作由项目负责人编制，报总经理批准。策划内容至少要包含目标和意义、技术指标分析、各阶段划分、每个阶段的评审验证确认活动、部门接口与职责分工。实际项目里，我会把策划书的实操性放到第一位，要求必须写清楚下面五个板块：

• 项目目标和技术指标分析：指标不能笼统写“满足国家标准”，要写清楚适用标准号和具体条款，比如“按 GB 9706.1-2020 第 6 章进行电气安全测试”“测量精度不超过 ±0.1 mL”。
• 设计和开发各阶段的划分：建议按方案阶段、样机阶段、试产阶段、验证阶段、确认阶段划分，每个阶段都要有入口和出口准则，不能只是写几个时间节点。
• 每个阶段对应的评审、验证、确认和设计转换活动：常见错误是只列了评审和验证，漏掉确认和转换，结果到产品落地时候才发现工艺没有提前验证。
• 各部门活动的接口：明确各阶段评审人员组成、批准人，以及各阶段预期的输出结果——是输出图纸、BOM、作业指导书，还是输出验证报告。
• 风险管理介入点：设计开发过程中的风险分析不是只在输入阶段做一次，而应该和设计评审同步迭代，每轮评审都更新风险分析文档。

我把策划书要素整理成了一张可参考的检查表，发布前逐项核对：

这份策划书批准之后并不是锁死的。项目发生重大调整时应该走变更流程更新策划书，而不是口头改改、旧版不回收。后面设计变更那一段我还会细说。

2.3 设计输入的四类来源：市场、法规、功能、可用性，少一个都是坑

设计输入是整个设计开发活动的基准线，后续的验证和确认都拿它来比对。程序里明确写了销售部负责市场调研、提供市场需求信息，技术部组织输入工作；这个安排本身就是想打破“技术部闭门造车”的局面。实际项目里，我通常要求把设计输入分成四类建档管理：

• 市场输入：由销售部提供，包括目标用户画像、使用场景、竞品对比、预期销售价格。这类输入的作用是定义产品定位，避免研发做出来的东西跟市场需求完全脱节。
• 法规输入：包括产品适用标准、强制法规条款、国家和行业政策要求。特别要留意产品出口时的目标市场法规，不同地区的安规差异非常大，漏一条后面送检就可能卡住。
• 技术与功能输入：包括性能指标、功能清单、接口定义、环境适应性要求、寿命要求、包装运输要求。每一条都要可测量、可验证，不能写“手感好”“外观精美”这种主观描述。
• 可用性与安全输入：包括人因工程要求、标识、说明书、禁忌内容、使用环境限制、风险可接受准则。这是 YY/T 0287-2017 强调的内容，也是很多公司第一次搭体系时最容易漏掉的。

设计输入不能只是技术部内部写一份《产品需求规格书》就完事。规范做法是组织各相关部门开一次设计输入评审会：销售部确认市场信息，法规部确认法规条款，生产部确认工艺可行性，质量部确认检验标准。评审会上对每一条输入项逐项确认并记录在案。如果某个输入项当天无法确认，宁可标记为“待定”并指定负责人限期补充，也不能含糊通过，否则后面验证失败时，连当初这条指标是谁提的、依据是什么都说不清。

2.4 输入评审记录：一份输入清单要对应一份评审报告

设计输入评审不能走形式，要有留痕文件。我见过比较规范的做法是：技术部把每一类输入整理成一张表格，每条输入带一个独立编号。评审时参会人员逐条确认并签字，有异议的直接在“评审意见”列写清楚。下面是一个可复用的设计输入清单模板：

这些输入记录的价值会在后面慢慢显现出来：验证数据不合格时，你能回到输入清单去反向查当初是谁定的指标、依据是什么、评审时谁签的字。如果输入端是一笔糊涂账，验证阶段的偏差完全没有办法定位。

3. 输出、评审、验证与确认：四步闭环做到位，体系审核才开不出不符合项

3.1 设计输出：不只是一套图纸，而是“能指导采购和生产”的完整定义

设计输出是设计输入的直接映射。YY/T 0287-2017 强调设计输出应能对照设计输入进行验证，并且发布前要经过批准。程序文件里技术部组织输出，实际输出物通常包括：产品设计图纸、物料清单 BOM、产品技术规格书、加工工艺文件、检验规范、包装标签规范、风险管理报告等。

这里要特别注意一个问题：设计输出不是研发觉得“画完图了”就算完，而是要能支撑采购、生产和检验三个环节。采购部拿着 BOM 和物料规格就能下单；生产部拿着工艺文件就能排产；质量部拿着检验规程就能做验收。达不到这个标准，就说明输出还不完整。很多项目在试产阶段突然卡壳，原因往往就是输出文件少了一份工艺参数表，或者检验规范里漏了某个关键尺寸的测量方法。等到生产线上才发现，再回头补文件，时间就白白浪费了。

3.2 设计评审组织：时机、参与部门与评审报告

设计评审按策划书规定的节点进行，通常要安排在关键阶段出口。评审组不能只是项目组内部几个人，程序文件里质量部是必须参与的，实际执行时视产品风险大小还会邀请采购部、生产部、销售部甚至外部专家。总结下来，评审会不是技术内部的“自嗨会”，它更像是一个阶段关卡：输入和输出是不是匹配、风险是不是受控、能不能放行到下一阶段，都要在这里给出一个明确答案。

常见做法是每个评审节点形成一份《设计评审报告》，包含评审日期、参会人员签到表、评审内容、提出的问题和整改措施、评审结论。评审记录最重要的价值在“问题的闭环”：评审中提出的每一条意见都要有对应的处理结果，而不是在报告里写“已修改”三个字就糊弄过去。审核老师查评审记录时，往往先看上次提出的问题是不是关闭了、有没有验证证据。如果连续几次评审记录都是原封不动的模板，那这份记录基本可以判断是补写的。

3.3 验证与确认：一个回答“做对了吗”，一个回答“做的是对的吗”

验证与确认在设计开发里是两个经常被弄混的活动。验证，是通过提供客观证据，证明设计输出满足设计输入的要求，比如你输入要求测量精度 ±0.1 mL，验证就是拿样机实际测一组数据，确认结果落在公差区间里。确认，是通过提供客观证据，证明产品满足预期的使用要求和用户需求，通俗讲就是放到真实使用场景里，看目标用户能不能正常完成操作、结果是不是符合临床预期、说明书和标识是不是足够清楚。

很多公司在这一点上犯晕：用内部实验室测试代替用户环境下的确认，或者两个词混着用，记录里通篇写的都是“验证”。区分起来其实不复杂：验证对的是输入指标，确认对的是真实使用需求；验证可以在实验室完成，确认尽量要在接近真实使用场景中做。程序文件里写得很清楚，确认工作同样由技术部组织实施，质量部参与配合。如果你们公司同时做国内注册和 CE 认证，这个区分更是要命的细节，因为公告机构审核员一定会问你要确认证据，而不是验证报告。

3.4 风险管理的接口：设计评审里加一份风险分析更新记录

YY/T 0287-2017 与 ISO 14971 是配合使用的，设计开发过程的每一阶段都应该体现风险管理。很多公司会单独做一份《风险管理报告》放在文档目录里，但这份报告如果不跟设计评审联动更新，实际上就是一份孤立的文件，起不到控制作用。我一般会在设计评审节点要求同步更新风险分析记录：本轮设计引入了什么新风险、已有控制措施是否有效、剩余风险是否可接受。如果设计输入阶段识别出的风险，到了输出阶段仍然没有对应控制措施，这个评审节点就不应该通过。

4. 设计转换、变更控制与文档追溯：从样机到批产，记录断链是最大隐患

4.1 设计转换活动：试产完成、工艺验证通过、设备能力确认，一个环节都不能省

设计转换是把设计输出变成可批量生产的过程，程序文件里把这一步明确交给了生产部，技术部提供支持，质量部负责检验。实际操作中，设计转换通常是这样一步步走的：先做小批量试产，验证工艺参数和生产线实际能力；再做过程确认，特别是灭菌、注塑、焊接这类特殊过程，必须把过程参数、设备状态、操作人员资质全部确认到位；然后培训生产操作人员，把技术文件转化为一线能用的作业指导书；最后质量部确认检验方法和抽样方案已经落地。

很多公司做了试产就默认转换完成，结果漏掉设备能力确认和特殊过程确认，等审核时被要求提供过程确认报告，只能临时补数据，那种记录看起来就会很假。程序文件里提到的“样品的实现和工艺验证”，说白了就是设计转换的核心动作。试产前我一般会先拉一个设计转换检查清单，逐项核对物料是否到位、工艺文件是否发放到工位、设备是否校准、人员是否培训、检验规程是否下发，每一项确认完签字之后再启动试产，没有确认完就不放行。

4.2 设计更改控制：从“改一版图纸”到“全链路影响评估”

设计变更控制是体系里最容易翻车的环节。产品生命周期里，因为生产问题、物料停产、客户要求、法规更新等原因，设计变更是躲不掉的。最危险的做法是：没有审批状态，直接在图纸上改了一个尺寸，打印出来就给车间用。标准明确要求对设计更改进行识别、评审、验证、确认和批准，并且要在实施前完成。

我建议建立一张《设计变更申请单》，至少要包含七个字段：变更内容描述、变更原因、受影响文件和产品清单、风险评估结论、验证方案、批准意见、关联变更记录。这里的关键不是表单本身，而是“是否要重新验证确认”的判断逻辑。比如只换一颗同等规格的电阻，可能只需要做来料检验和常规验证；但如果改变了电路拓扑，或者换了主控芯片，就必须重新走完整的验证确认流程。变更影响评估不是质量部一个人的事，而是技术、采购、生产、质量一起会签，任何一个部门认为有影响，变更就不能轻率放行。变更批准之后，还要同步更新 BOM、工艺文件、检验规范，并在修订记录里注明变更单号，确保追溯链路不断。

4.3 设计开发文档管理：编号、版本、可追溯性怎么设计

文档管理是整个设计开发程序的“记账本”，也是大多数企业做得最薄弱的环节。审批记录、验证记录、确认报告、变更单、图纸和工艺文件，都需要有受控的文件编号、版本号和保存要求。文件编号规则建议在《设计开发策划书》里就定下来，比如用“项目编号-文件类别代码-流水号”的结构，避免不同项目用同一套编号导致冲突。

下面是一张文档可追溯性的检查表，每次归档时可以对照检查：

文档管理看起来琐碎，等到体考或客户审计时会发现它的重要性。文件版本一旦混乱，被审核员当场查到，后面所有记录都会被怀疑是“补写的”，这种信任崩塌后面很难挽救。

4.4 设计开发文档与风险管理文件的关联

设计开发文档不只是设计记录，它还是风险管理报告的实际输入来源。审核员在查体系时，会顺着产品路径核对：输入清单里识别出的风险，在输出阶段有没有对应的控制措施；验证报告里的不合格项，在风险分析表中有没有记录和处理。常见做法是每次评审节点完成之后，同步更新风险管理文档，并把风险分析记录编号填入评审报告的关联文件栏。让每一份验证记录、评审报告、变更单都能通过文档编号在风险管理文件中找到对应位置，这条证据链就算完整了。

5. 避坑排查：设计开发控制程序执行中最高频的 5 类不符合项

5.1 踩坑一：策划书写得太“泛”，审核员追问阶段输出时拿不出来

现象：设计开发策划书整页都是“明确目标、确定阶段、分配职责”这类套话，没有具体的阶段交付物清单，审核员要求你说明“样机阶段到底输出什么”时，现场鸦雀无声。

原因：大多数人直接拿其他公司模板改项目名，没有结合自己的产品特点和实际项目排期，策划书成了应付文件。

解决：把策划书里的阶段输出做成一张交付物表格，每个阶段列清交付物名称、编号规则、责任人、确认方式。同时给每个阶段设置明确的出口准则，比如样机阶段的出口是样机试制报告和功能测试通过记录；试产阶段的出口是工艺验证报告和产能确认记录。出口准则要写到可验证的程度，不能写“样机完成”这种模糊描述。

5.2 踩坑二：验证与确认混淆，两份报告内容雷同

现象：验证报告里写“确认结果符合要求”，确认报告里填的却是试验测试数据，看不到任何真实使用场景的评估记录。

原因：团队对两个概念理解不到位，记录模板本身也没有做区分设计，填的人想怎么写就怎么写。

解决：给研发、质量和生产相关岗位做一次内部培训，把验证定义成“对照输入要求验证”，把确认定义成“对照使用需求确认”。同时把报告模板分成两个独立部分：验证结果栏对输入指标，确认结果栏对使用场景评估，模板上直接写明填写的依据来源，从机制上杜绝混用。

5.3 踩坑三：设计转换没有形成记录，试产做完拿不出证据

现象：试产已经完成，但工艺验证报告缺失，或者报告里没有设备参数、人员培训记录、物料批次信息，数据无法追溯。

原因：技术部和生产部配合不到位，大家默认“试产完成 = 设计闭环”，忽略了程序文件里生产部负责样品实现和工艺验证的规定。

解决：在试产前先行建立一份“设计转换检查清单”，依次核对物料、工艺文件、设备校准、人员培训、检验规程。每一项确认实际完成后再开启试产，试产结束后把过程记录、检测数据、设备参数一起归档。我习惯把转换记录作为试产放行的必要文件，没有这份记录， 同一批次下次就不允许继续。

5.4 踩坑四：设计变更影响评估走形式，只换物料不重新验证

现象：变更单上“影响评估”一栏只写了“无影响”，变更后的产品直接发货，一段时间后市场反馈质量问题，追溯发现就是那颗被更换的物料出了问题。

原因：变更审批人嫌麻烦，或者缺乏技术评估能力，没有用风险评估工具分析变更的实际影响面。

解决：在《设计变更申请单》里强制加入风险评估字段，按四个维度逐一判断：是否影响功能性能、是否影响法规符合性、是否影响兼容性、是否影响可制造性。只要有任一维度为“是”，就必须重新验证，必要时重新确认。变更批准以后同步更新 BOM、工艺文件、检验规范，并在修订记录里注明变更单号，方便后续追溯。

5.5 踩坑五：文档追溯断链，现场同时出现两个版本

现象：车间使用的作业指导书是旧版本，质量部受控文件柜里存放的是修订版，现场核对时两边对不上。

原因：文件分发和旧版回收机制失效，发放记录没有覆盖全部使用场所，或者新版发布后没有安排旧版物理销毁。

解决：把文件管理纳入质量部台账，采用“受控发放号”的办法：每份纸质文件盖受控章、登记发放流水号之后再送到对应工位；新版发布时，质量部根据发放记录逐一回收旧版并在台账上打勾。这套动作听起来繁琐，但真正执行到位，现场版本混乱的问题基本上能根治，审核时也能拿出完整的发放回收记录作为证据。

6. 进阶技巧：用设计评审记录做阶段门看板，让体系文档反哺研发效率

6.1 日复一日地将评审问题状态显性化

在每个设计开发阶段，我会额外维护一份评审问题跟踪表，列为问题描述、提出人、责任人、严重程度、计划关闭日期、当前状态六项。很多设计评审会上提出问题后，就被遗忘在会议纪要里，直到下次评审才被发现没处理。把问题显性化，每周更新一次，其实就是把体系上对评审闭环的要求，变成项目管理上真正使用的工具。项目组看到问题清单可以直观了解目前障碍在哪里。

6.2 用“放行条件”替代“一锤子审批”

我将对评审、验证、确认的理解简化为一个可操作的检查动作：阶段结束时照着检查表逐项确认。检查表包括这些内容：本阶段输入项是否齐备、输出文件是否已受控归档、验证结果是否合格、确认报告是否可接受、遗留风险是否可控。任何一项没有完成，阶段门就不开放。这样做有另一个好处：设计开发记录不再只是为了应对审核才写，而是成为每一次项目决策的依据。

从那以后，我每个设计开发项目开始前都会先建两套表：一套是设计输入输出追溯表，一套是评审问题动态跟进表。这两张表看上去很简单，但能帮你在项目推进中少走弯路，也让你在审核老师面前更有底气。希望帮到你。

本文还有配套的精品资源，点击获取