一、先把「可用性工程」和「找几个人试用一下」分开
初次接触 IEC 62366 的企业,常把它理解成注册前找几位临床人员操作一遍、录段视频、补一份报告。按这个理解准备资料,递上去往往会被要求补正。原因在于,审评关注的并不是「有没有做过测试」,而是「与用户接口相关的安全性,是怎么被系统性地识别、设计、再验证出来的」。
先说明本文的书写口径:下文统一用 IEC 62366 指代可用性工程这一套标准体系。真正填写注册资料时,引用依据栏里应当写成什么样的完整编号、是否还需要同时引用配套的指导性文件,请以标准原文现行有效版本和受理机构的现行公开要求为准,不要照抄本文或任何二手资料里的写法。编号写法这件事看着琐碎,但它恰恰是审阅时一眼就会落到的地方。
IEC 62366 描述的是一套过程:从明确预期用户、预期使用环境和预期用途开始,识别与用户接口相关的危险及危险情境,把其中与安全相关的部分提炼成用户接口规范,再通过评价活动确认这些部分在真实操作条件下不会诱发不可接受的使用错误。测试只是这条链条尾端的一环。链条前段缺环,尾端做得再细致也补不回来。
这一点直接决定了实验室在项目里的角色边界。实验室可以承接与用户接口相关的合规性审核、配合总结性评价的执行与记录,以及与 IEC 60601-1、GB 9706.1 体系中安全要求相交叉的那部分验证;但「使用规范」和「与安全相关的用户接口规范」这两份源头文件只能由厂家产出。它们属于设计输入,不是检测结论,实验室代写既不合适,也无法支撑后续追溯。
二、先判断自家产品该走哪条准备路径
不同形态的产品,用户接口的重心差别很大,准备工作也不该按同一份模板来做。下表是我们在承接项目时用来做初步分流的判断维度,供研发和注册同事在启动前对号入座。
| 产品特征 | 用户接口的主要形态 | 准备重点 | 通常需要并行考虑的体系 |
|---|---|---|---|
| 无源、无显示与控制件 | 说明书、标签、包装提示、器械本身的结构引导 | 随附文件的可理解性;装配、佩戴或开启步骤的防错设计 | ISO 14971 |
| 有源医用电气设备 | 物理控制件、显示、报警、连接接口 | 控制件的辨识与误操作防护;报警信息的可察觉性与可理解性 | IEC 60601-1、GB 9706.1、ISO 14971 |
| 含嵌入式软件或独立软件 | 图形界面、参数录入、状态反馈 | 参数录入的边界防错;界面状态歧义;软件标识与界面版本的一致性 | IEC 62304、ISO 14971 |
| 预期由非专业用户在家庭环境使用 | 上述形态的组合 | 用户群体代表性;无培训条件下任务能否独立完成 | ISO 14971,并对用户群体差异带来的风险重新评估 |
表里只列了与可用性直接相关的并行体系。至于检测报告究竟怎么挂接到设计输入、设计变更记录与体系文件上,那是质量管理体系层面的题目,本文不展开,我们在质量管理体系相关的文章里单独讲。
分流之后还有一个判断要做:哪些用户接口环节是「与安全相关」的。判断依据不是操作是否复杂,而是该环节一旦发生使用错误,是否会经由某条路径导向危险情境。举个工程分析的例子(这是基于机理的推演,不是统计结论):一台带加热部件的治疗设备,「治疗时长设定」看起来只是普通参数录入,但若时长录入错误会直接导致组织受热超出预期,这一环就必须进入与安全相关的用户接口规范;而「界面语言切换」虽然操作更繁琐,却不构成通向危险情境的路径,可以不纳入总结性评价的必测任务。把这条线划清楚,能显著压缩后续评价的工作量。
三、送检前要凑齐的文件包
可用性资料被打回,多数不是因为测试做得不好,而是因为文件包缺项或者互相对不上。下面这张表是我们在正式排期前会逐项核对的清单。
| 文件 | 由谁产出 | 在检测环节的作用 | 常见的退回原因 |
|---|---|---|---|
| 使用规范(预期用户、使用环境、预期用途、操作原则) | 厂家研发与临床 | 界定评价对象与场景边界 | 用户群体写得笼统,未区分专业与非专业、未说明培训前提 |
| 与用户接口相关的危险及危险情境清单 | 厂家,与风险管理协同 | 推导出需要验证的使用场景 | 只列了器械失效模式,没有列使用错误 |
| 与安全相关的用户接口规范 | 厂家 | 确定哪些操作任务必须被验证 | 与风险控制措施对不上号,无法互相索引 |
| 用户接口评价计划 | 厂家编制,可由实验室协助 | 定义评价方法、任务集合与判定方式 | 形成性评价与总结性评价混为一谈 |
| 形成性评价过程记录 | 厂家 | 证明设计经过迭代与改进 | 只留了结论,没有留过程与改进闭环 |
| 说明书、标签、包装与培训材料的定稿件 | 厂家 | 作为用户接口的组成部分参与评价 | 送检时仍是草稿,与样机上的实际标识不一致 |
| 样机状态说明(含软件标识与配置项) | 厂家 | 确认评价对象处于定型状态 | 样机与拟量产状态存在差异且未声明 |
| 引用依据清单(本次申报实际引用的标准编号与版本状态) | 厂家注册 | 让文件包与申报路径对应 | 直接照搬他人模板,编号与目标路径不匹配 |
| 风险管理文件中的相关内容 | 厂家 | 支撑使用错误到风险控制的追溯 | 两套文件各写各的,缺少交叉引用 |
其中容易被低估的是表里末尾那一项。可用性资料和风险管理资料如果由两拨人分头编写,很容易出现口径打架:风险管理里写了「通过说明书警示予以控制」,可用性评价里却没有任何一项任务去验证这条警示是否真的被用户读到并理解。这种缺口在审阅阶段一看便知。
倒数第二项是这次特意加进清单的。很多企业的可用性文件本身做得不差,卡在引用依据这一栏:模板是从别处拿来的,写的是境外路径的编号,实际申报走的却是国内路径,或者反过来。这一栏填错,前面所有文件的说服力都要打折扣。
四、国内与境外两条路径:差别主要在引用依据和文件命名
方法层面,两条路径其实是同一套逻辑:先有使用规范,再有与用户接口相关的危险及危险情境,提炼出与安全相关的用户接口规范,然后用形成性评价推动设计迭代、用总结性评价做收口确认。真正让人踩坑的差别不在方法,而在资料怎么写、怎么命名、怎么被索引。
| 对比维度 | 国内注册路径 | 境外技术文件路径 | 实务建议 |
|---|---|---|---|
| 引用依据的写法 | 通常引用转化后的国内标准,编号与现行有效版本需按标准原文与受理机构要求确认 | 通常直接引用国际标准编号,同样以现行有效版本为准 | 编制资料前先把这一栏定死,不要边写边改 |
| 文件的组织形式 | 更常按受理机构给定的资料目录逐条对应归入 | 更常集中归集为一份可用性工程相关的技术文件 | 同一套内容做一次,索引生成两份 |
| 追溯的索引方式 | 更依赖资料目录之间的交叉引用 | 更依赖文件内部的追溯矩阵 | 追溯矩阵先做出来,两种索引都从它导出 |
| 与安全标准的衔接 | 与 GB 9706.1 等国内安全标准的相关要求衔接 | 与 IEC 60601-1 等国际安全标准的相关要求衔接 | 安全项目与可用性项目的样机、软件状态要统一 |
需要强调的是,上表描述的是实践中常见的形态,不是法规条文的复述。具体应当引用哪个编号、执行哪一版、资料按什么目录组织,一律以标准原文现行有效版本和目标市场受理机构的现行公开要求为准;同一产品在不同市场的分类判定与随之而来的资料深度差异,也需要按具体产品逐一确认,不能凭同类产品的经验类推。
对同时要走两条路径的企业,我们的建议是:内容层只做一套,把使用规范、危险清单、用户接口规范、评价计划与评价记录做成互相独立又能拼装的模块;申报层再按路径分别生成引用依据清单和目录索引。这样做的好处是,任何一次设计变更只需要改内容层一处,两份申报资料同步更新,不会出现两边说法不一致。
五、追溯链条:使用错误到风险控制要能一路走通
建议在送检前自己先画一遍追溯矩阵,横向至少要串起这几段:预期用户与使用场景 → 可能发生的使用错误 → 由此进入的危险情境与可能的损害 → 采取的风险控制措施 → 验证该措施有效性的评价任务。本节只讨论这一条链,记录如何受控、报告如何并入体系文件,属于另一个话题,不在这里展开。
按 ISO 14971 的逻辑,风险控制措施有优先次序,落在用户接口上的控制往往属于「通过信息进行的安全保障」这一类,其有效性本身就依赖用户的感知与理解。因此凡是把控制措施押在标识、警示、界面提示上的,都必须在评价中有对应的验证任务,不能只在风险文件里写一句话就算完。反过来,如果某项使用错误在风险分析中被判定为不需要控制,也要有可复核的理由,而不是在清单里直接消失。
矩阵画完之后做一次反向检查:从评价计划里的每一项任务倒推,看它是否都能找到来源;找不到来源的任务说明清单遗漏,或者任务设置得过宽。这一步花的时间不多,但能挡掉相当一部分后续返工。
六、总结性评价的样机、用户与场景怎么定
样机状态是踩坑较多的地方。总结性评价要求评价对象处于定型状态,意味着外观标识、控制件手感、界面文案、随附说明书、包装形式都应当与拟上市产品一致。工程样机上贴一张打印标签、界面里还留着调试菜单,这类情况一旦被发现,评价结论的适用性会被直接质疑。软件产品还要额外注意软件标识与评价记录能对应上,否则后续任何一次界面改动都可能引发「是否需要重做」的争议。
用户群体的代表性是另一个高频问题。参与评价的人员应当来自使用规范里定义的预期用户群体,其经验背景、培训经历、感官与操作能力分布要能覆盖真实使用人群,而不是由本企业的研发或市场人员代劳。对于预期由非专业用户使用的产品,还要考虑视力、握力、认知负荷等差异带来的影响。如果产品在真实使用中会经过培训,那么评价中给到的培训内容与形式也应当与实际提供的一致,并在报告中说明。
使用场景的还原程度同样重要。评价环境不必与临床现场一模一样,但影响操作绩效的关键要素应当保留:照明条件、环境噪声对报警可察觉性的影响、操作者是否戴手套、是否存在多任务干扰、单人还是双人配合。这些要素中的任何一项被简化掉,都可能让评价结果偏离真实使用。涉及具体环境条件与判定方式的量化要求,以标准原文现行有效版本为准。
还有一点常被忽略:主持人的引导方式。任务指令如果无意中提示了正确操作路径,使用错误就被掩盖了。建议在正式开始前用内部人员做一次预演,专门检查指令措辞是否中立。
七、说明书与标签是用户接口的一部分
不少企业把说明书当作注册资料的附件,而不是产品的组成部分。在可用性框架下,随附文件与器械本体一样承担着引导正确操作的功能,因此也要接受评价。需要检查的包括:关键安全信息是否出现在用户实际会查阅的位置、警示与操作步骤的先后顺序是否符合真实操作流程、图示与实物是否一一对应、面向非专业用户的表述是否避免了专业术语堆砌。
一个常见的问题是,说明书由技术文档岗独立编写,与研发的设计意图脱节:设备上的按键名称与说明书里的叫法不一致,或者说明书描述的操作顺序与固件实际逻辑存在出入。这类不一致在实验室做界面比对时很容易暴露。送检前把实物、界面文案、说明书三者做一次逐项对照,成本很低,收益却很直接。
如果产品要同时投放国内与境外市场,随附文件还有一层容易被忽略的工作:语言版本之间的一致性。翻译版本里的警示措辞、图示编号、步骤顺序如果与母版对不齐,评价结论只能覆盖被评价的那个版本。稳妥的做法是把母版定稿、翻译定稿、评价所用版本这三者的对应关系在样机状态说明里写清楚。
八、含软件的产品:两套文件要能互相指认
对于含软件的器械,IEC 62366 与 IEC 62304 的文件之间需要建立可见的关联。软件生命周期文件中的需求项,凡是涉及界面呈现、参数录入、状态反馈、报警触发与提示的,都应当能在用户接口规范里找到对应;反过来,可用性评价中发现的界面问题,其整改也应当回到软件需求与验证流程中闭环,而不是在界面上临时改一版了事。
另一个实务要点是配置管理。评价时使用的软件标识、参数配置、可选功能开关状态都要记录在案。若产品存在多种配置组合,需要在评价计划中说明抽取哪些组合、依据是什么,避免出现「评价了一种配置、声称覆盖全部配置」的情况。
九、什么时候把实验室拉进来比较合适
按我们承接项目的经验,等到注册资料快要递交时才找实验室,往往已经错过了成本较低的介入窗口。比较顺的节奏是:设计输入基本冻结、界面方案初步成型时先做一轮沟通,确认使用规范与用户接口规范的颗粒度是否够用;形成性评价阶段可以自行组织,但把方法和记录格式先对齐,能省掉后面重写记录的功夫;总结性评价则建议提前排期,因为受试人员招募、场景搭建、样机到位这几件事的周期通常比测试本身长。
如果产品同时要做电气安全、电磁兼容等项目,还可以把可用性相关的准备与这些项目的送检节奏合并考虑。样机数量、软件版本冻结时间、说明书定稿时间这几个节点一旦错开,很容易出现「安全项目用的是一版样机、可用性用的是另一版」的尴尬。关于送样与资料的通用要求,可以先查阅送检要求与检测流程,把内部排期做在前面。
我们能提供什么
沙格实验室在上海与合肥设有实验室,通过 CNAS、CMA 与美国 IAS 认可,可承接医用电气设备的电气安全、电磁兼容、生物相容性、灭菌与包装等检测项目,并可就 IEC 62366 可用性工程相关资料的准备、用户接口评价方案的对齐、说明书与界面一致性核查提供配合与技术沟通。需要说明的是,认可标志只证明实验室在认可范围内具备相应技术能力,不构成对目标市场准入结果的承诺,结论以受理机构的审评意见为准。
更多检测能力与项目范围见检测服务,标准解读与实务文章见知识中心。项目咨询与排期请致电 132 4819 8029,或直接联系报价,我们会根据产品形态与目标市场给出送检准备清单与周期建议。