3. 用户需求与设计输入
在医疗器械设计控制体系中，设计输入是连接“用户想要什么”与“产品最终做成什么样”的关键桥梁。很多项目在后期出现返工，根源往往不在技术实现，而在于设计输入阶段没有把临床需求、用户需求准确、完整、可验证地转化为工程语言。本节聚焦这条转化链：从临床场景出发，提炼用户需求，再将其分解为可执行、可验证的设计输入，并建立设计输入清单及其可追溯性。
一、三层需求的本质区别
临床需求描述的是“临床场景中存在的问题或未满足的诊疗目标”，通常由临床医生、护士、患者或法规标准提出，语言偏场景化，例如“急诊插管时希望快速确认导管位置”。用户需求描述的是“目标用户希望产品具备的能力或体验”，例如“操作者在置管后30秒内获得位置确认提示”。设计输入则是“产品必须满足的、可验证的技术要求”，例如“设备应在置管后≤30秒输出位置判定结果，判定灵敏度≥95%，并具备声光提示”。
三者的关系是逐层收敛：临床需求回答“为什么做”，用户需求回答“用户要什么”，设计输入回答“产品必须达到什么指标”。设计输入必须可测量、可验证、无歧义，否则无法作为后续设计验证和确认的基准。
二、从用户需求到设计输入的转化方法
转化不是简单翻译，而是一次“工程化拆解”。推荐按以下思路操作：
- 识别需求类型：将用户需求分为功能需求、性能需求、安全需求、可用性需求、法规与标准需求。例如“快速确认位置”属于性能需求，“不增加操作步骤”属于可用性需求。
- 提取可量化维度：对每条需求追问“时间、精度、范围、条件、对象”五个维度。以“快速确认”为例，时间维度可定为≤30秒，精度维度可定为灵敏度≥95%，条件维度可定为成人急诊插管场景。
- 设定验收准则：每条设计输入必须配一个可执行的验证方法，如台架测试、模拟使用测试、临床评价或检查。验收准则要写明判定阈值和样本量要求。
- 标注来源与优先级：每条设计输入标注对应的用户需求编号，并区分“必须满足”与“期望满足”，便于后续变更控制。
三、设计输入清单的编写要点
设计输入清单（Design Input List，DIL）是设计控制的核心文件之一。编写时建议包含以下字段：输入编号、设计输入描述、来源用户需求编号、需求类型、验证方法、验收准则、优先级、责任人、版本状态。描述应使用“应”字句，避免“尽量”“较好”等模糊词。
例如，一条合格的设计输入应写成：“DI-004：设备应在环境温度10℃～40℃、相对湿度30%～75%条件下，开机自检时间不超过15秒。”这条输入包含了对象、动作、条件、指标和验证边界，可直接用于测试方案设计。
四、设计输入的评审
设计输入评审的目标是确认“完整性、正确性、一致性、可验证性”。评审应邀请临床代表、研发、测试、法规、质量等角色参加。评审检查点包括：
- 每条用户需求是否至少被一条设计输入覆盖；
- 每条设计输入是否可追溯到来源需求；
- 设计输入之间是否存在冲突，例如体积要求与电池容量要求矛盾；
- 验收准则是否可测量，验证方法是否可行；
- 是否遗漏了法规、标准或风险管理输出的要求。
评审输出应形成评审记录，对不通过项指定责任人和关闭期限。评审通过后，设计输入清单进入受控状态，后续变更需走变更控制流程。
五、可追溯性的建立
可追溯性矩阵（Traceability Matrix）是连接用户需求、设计输入、设计输出、验证和确认的纽带。建立时建议采用“双向追溯”：正向从用户需求查到设计输入和验证记录，反向从测试用例查到对应的设计输入和用户需求。这样在发生设计变更时，可以快速评估影响范围。
实际操作中，可在需求管理工具中为每条需求分配唯一编号，并建立链接关系。若使用电子表格，至少应包含：用户需求编号、设计输入编号、设计输出编号、验证方案编号、验证报告编号、确认报告编号。每次评审或变更后更新矩阵状态，确保没有“孤儿需求”或“无源输入”。
总结来说，从临床需求到设计输入的转化，本质是把模糊的临床期望逐步收敛为可验证的工程指标。设计输入清单的编写、评审与可追溯性建立，是保证这一转化不丢失、不扭曲、可复查的关键手段。只有把这一步做扎实，后续的设计验证与设计确认才有可靠的基准。