客服热线：
手机版
二维码
北京市医疗器械软件产品标准编写要求介绍
一、编写医疗器械软件产品标准应遵照以下文件
1、《医疗器械标准管理办法》(国家食品药品监督管理局令第31号)
2、《医疗器械说明书、标签和包装标识管理规定》(国家食品药品监督管理局令第10号)
3、GB/T1.1-2000 《标准化工作导则 第一部分：标准的结构和编写规则》
4、GB/T 17544-1998 《信息技术 软件包 质量要求和测试》
5、《医疗器械申请注册产品标准编写规范》（国药监械[2002]407号）
6、相关的国家标准和行业标准。
二、标准正文的内容
标准正文的内容应包含：范围、规范性引用文件、分类、要求、试验方法、检验规则、标志、标签、使用说明书、包装、运输和储存。
1、 范围
明确说明本标准规范的对象和所涉及的各个方面，指明适用的界限。
2、 规范性引用文件
应包含引导语和规范性引用文件一览表。
2.1引导语
下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的修改单（不包含勘误的内容）或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。
2.2规范性引用文件一览表
GB/T 17544-1998 信息技术 软件包 质量要求和测试
相关的国家标准
相关的行业标准
相关的国际标准
3、 分类
3.1型号
3.2组成
3.3硬件配置要求
4、 要求
4.1产品描述(详见附录A)
4.2用户文档(详见附录A)
4.3程序和数据(详见附录A)
4.4外观
5、 试验方法
产品描述、用户文档、程序和任何要交付的数据都作为软件包的组成部分，对产品描述和用户文档的测试通过文档的检查测试来进行；
对程序及数据的测试采取黑盒测试的方法来进行，且应按GB/T 17544-1998《信息技术软件包 质量要求和测试》第3章及附录A中的要求进行符合性测试。
5.1测试预要求
5.1.1产品项的现场要求
测试现场应包含产品所有要交付的内容和产品描述中已标识的需求文档。
5.1.2对系统组成部分的现场要求
测试现场应包含产品描述中已指明要求的所有计算机系统的组成部分。
5.2测试活动
5.2.1产品描述的测试
根据A.1（参见附录A）中每1个条款的内容要求，通过文档的检查方式验证产品描述的符合性。
5.2.2用户文档的测试
根据A.2（参见附录A）中每1个条款的内容要求，通过文档的检查方式验证用户文档的符合性。
5.3.3程序和数据的测试
根据A.3（参见附录A）中每1个条款的内容要求，采用黑盒测试技术，通过创建测试用例的方法对程序和数据进行测试。
5.3.4外观的测试
6、 检验规则
应明确出厂检验及型式检验的时机、抽样方法、检验项目及判定规则。
其中出厂检验的检验项目至少应包含第四章要求中4.1产品描述及4.2用户文档的要求；型式检验应包含第四章要求的全部内容。
7、 标志、标签、使用说明书
产品的标志、标签、使用说明书应满足如下文件的要求：
7.1GB/T 17544-1998《信息技术 软件包 质量要求和测试》
7.1《医疗器械说明书、标签和包装标识管理规定》(国家食品药品监督管理局令第10号)
8、 包装、运输、储存
应规定产品的包装要求、运输储存要求。
附录A：
质量要求
A.1产品描述
A.1．1 内容的通常要求
a) 产品描述宜是充分可理解的、完整的并且易于浏览，以协助潜在的购买者在购买该产品前评价产品对他们自己的适用性。
b) 产品描述应避免不一致，每个术语在任何地方都应有相同的意义。
c) 产品描述的说明应是可测试的并且是正确的。
d) 应包合或宜包含下列A.l.2到A.1.8的内容 。
A．1．2 标识和指示
a）产品描述的标识
产品描述应且有唯一的文档标识。它能够有不同于产品描述的命名，例如，“功能描述”、“产品信息”“产品清单”。
b) 产品的标识
产品描述应标识产品。产品标识应至少有产品名字和版本号或日期。假如在产品描述中提及两个或多个派生版本，则每个版本应至少有产品名、派生版本名和版本号或日期。
c）供方
产品描述应至少包含1个供方的名字和地址。
注：名字和地址不必打印；有供方的公章即可。
d）工作任务
产品描述应标识期望的产品能完成工作任务。
e）符合需求文档
产品描述能够引用产品应符合的需求文档的内容，在这种情况下应标识相关的编辑版本。
f）要求的系统
应标识将产品投入使用所要求的系统（硬件、软件以及配置），包含制造厂商名和所有部件的类型标识符，例如；
包含协处理器的处理单元；
主存规格；
外存的类型和规格；
扩展卡；
输入和输出设备；
网络环境；
系统软件和其它软件。
对于不同的工作任务、不同的边界值或不同的效率要求，能够规定不同的要求系统。
假如先前特定的硬件或软件产品已经标识，则语句“（假如兼容，或任何其它……）”能够出现在产品描述中。假如产品的先前版本已经标识，则语句“假如兼容，或升级的版本”能够出现在产品描述中。语句“自版本X至少到版本Y”能够出现在产品描述中，而“自版本X”不能出现在产品描中。
g）与其它产品的接口
假如产品描述引用了其它产品接口，则应对所引用的接口或产品进行标识。
h）要交付项
应对要提供的产品的每个物理部件进行标识，特别是所有打印的文档和所有的数据媒体。
应说明提供的程序形式如源程序、目标模块，或加载模块。
i)安装
应说明产品安装是否能由用户来完成。
j)支持
应说明是否提供对产品操作的支持。
k）维护
应说明是否提供维护。假如提供维护，应说明具体包含什么。
A．1．3功能说明
a）功能概述
产品描述应概述产品的用户可调用功能、必须的数据、所提供的设施。
对每个所论及的功能（尤其是选项和变量）是否是下列内容的一部分应清晰地说明：
产品功能的；
在产品描述中完整描述的产品扩展功能的；
在产品描述中所引用的产品扩展功能的；
无保证的补充功能的。
注：不必论及每个用户可调用功能，不必给出功能怎样调用的每个细节。
b）边界值
假如由于产品特定的边界值致使产品的使用受限，则应提供这些边界值。例如：
最小或最大值；
键的长度；
文卷中的记录的最大数日；
检索准则的最大数目；
最小样本大小。
当不可能提供固定的边界值时（例如，边界值取决于应用问题的类型或输入数据时），则应说 明这些限制，能够提供容许的值组合，更具体的信息写入用户文档。
C）安全
假如提供的话，产品描述中应包含有关防止对程序或数据非授权的无意访问或蓄意访问的手段。
A.1.4可靠性说明
产品描述应包含数据存储规程的信息。
注：例如，只要说明使用操作系统进行备份就能够了。
应描述保证产品的功能能力的附加性质。例如：
检验输入的合理性；
防止由于用户的错误而产生的严重后果；
出错恢复
A.1.5易用性说明
a)用户界面
应命名用户界面的类型，例如：命令行、菜单、窗口、功能键及协助功能。
b）要求的知识
应规定应用该产品所要求的专门知识。例如：
技术领域的知识：
操作系统的知识；
经过专门培训可获得的知识；
除了已写入产品描述中以外的其它语言知识。
应说明用户文档和用户界面（包含出错信息和可视数据）所使用的所有自然语言，软件包本身和该产品描述中所涉及的所有其它产品的有关内容都应加以说明。
C）适应用户的必须
假如产品能被用户作适应性修改，则应标识这种修改的工具和修改工具的使用的条件。例如：
参数的改变；
计算的算法改变；
功能键的分配。
d）防止侵权行为
假如防止侵权的技术保护可能有碍于软件的使用，则应说明这种保护，例如：
防止拷贝的技术保护；
程序设置的使用截止日期；
相互约定的付费拷贝。
e）使用效率和用户满意度。
产品描述能够包含关于使用效率和用户满意度的数据。
A.1.6效率说明
产品描述能够包含产品的时间行为的数据，诸如在指定条件下（例如系统配置和 负载分布）关于给定功能的响应时间和吞吐率。
A．1．7可维护性说明
产品描述可包含可维护性说明。
A．1．8可移植性说明
产品描述可包含可移植性说明。
A.2用户文档
A．2．l完整性
用户文档应包含产品使用所需信息。在产品描述中说明的所有功能以及在程序中用户可调用的 所有功能，都应在用户文档中加以完整地描述。
用户文档中应再次说明产品描述中给出的所有边界值。
假如安装能由用户来完成，则用户文档应包含安装手册，该手册应包含所有必要的信息（见A．3.la）。安装手册宜说明一次安装的最小文卷和最大文卷。
假如维护能由用户来完成，则用户文档应包含程序维护手册，该手册应包含各种有关该软件维护所必须的信息。
A.2.2正确性
用户文档中所有信息应是正确的，不能有歧义和错误的表达。
A.2.3一致性
用户文档自身内容或相互之间以及与产品描述之间都不应相互分歧。每个术语的含义宜处处保持一致。
注：程序和数据的一致性在A.3.1 d)中论及。
A.2.4易理解性
用户文档对于正常执行其工作任务的通常用户宜是易理解的，例如，通过使用适当的术语、图形标明，详细的解释以及引出有用的信息源来表现。
A.2.5易浏览性
用户文档宜易于浏览，以使相互关系明确。
每个文档应有目录表和索引表。
假如文档未提供印刷本，则应指明打印过程。
A.3程序和数据
A.3.1功能性
a)安装
如用安装能由用户来完成，则按照安装手册中的信息应能成功安装。产品描述中指出的每种所要求的系统对于程序的安装应是充分的。
安装之后，程序能否运行应是可鉴别的。例如，使用提供的测试用例或通过相应信息的自检。
b）菜单现
用户文档中提到的所有功能应是可执行的。程序应按照用户文档中的给定形式，在规定的边界值范围内使用相应的设施、性质和数据执行其功能。
注：由于在产品描述中涉及的所有功能也应出现在用户文档中，这些功能更应是可执行的。
C）正确性
程序和数据应与产品描述及用户文档中的全部说明相对应。为完成工作任务，程序功能应以正确的方式执行。特别是，程序和数据应符合产品描述所引用的任一需求文档中的全部需求。
d）一致性
程序和数据其本身不能自相分歧，并且同产品描述和用户文档不能相互分歧。每个术语应处处具有相同的含义。
由用户行使的程序操作控制和程序行为(例如，消息，屏幕输入格式和打印报表)宜有一致的结构。
A.3.2可靠性
系统（包含硬件、要求的软件及属于该产品的程序）不应陷入用户无法控制的状态，既不应崩溃也不应丢失数据。
即使在下列情况下也应满足上述要求：
使用的容量到达规定的极限；
企图使用的容量超出规定的极限；
由产品描述中列出的其它程序或用户造成的错误输入；
用户文档中明确规定的非法指令。
只是那些不能用任何程序捕获的硬中断和操作系统中断（例如，系统操作复位用的键或组合键）不在此范围之内。
当程序认为输入错误或输入未经定义时，应视为不容许的输入，不加处理。
A.3.3易用性
关于易用性，根据本标准的规定，鼓励研究ISO 9241系列标准最新版本应用的可能性。
注：特别是宜考虑ISO 9241系列的第10部分和第13部分。
a)易理解性
程序的问题、消息和结果应是易理解的，例如：
通过选择适当的术语：
通过图形标明；
通过提供背景信息：
通过协助功能的解释。
出错消息应提供解释相应差错产生原因和纠正的详细信息（例如通过引用用户文档的条文）。
b)易浏览性
假如有多种媒体，则每种数据媒体应具有产品标识、可辨别编号或文本。
对于使用程序进行工作的用户，总能找到哪个功能正在被执行是可能的。
程序宜以易观察易读的形式向用户提供信息。通过对信息的适当编码和分组对用户提供指导，必要时，程序可向用户发出警报。
源程序的消息应如此设计，即用户通过类型容易区分它们。例如：
确认；
程序询问；
警告：
出错消息。
屏幕输入格式，报表和其它输入、输出宜设计清晰和易于浏览。通常包含：
字母数字字段左对齐：
数字字段右对齐；
在表中，小数点或逗号要排在同一垂直线上；
字段界限是可识别的；
什么字段的使用是受限的，什么字段是可识别的：
标识输入失败后要立即在屏幕输入格式中加亮；
通过1个可视或可听的信号来引起用户注意屏幕内容的改变。 c) 可操作性
具有严重后果的功能执行应是可逆的，或者程序应给出该后果的明显警告并且在执行该命令前要求确认。特别是数据的删除和重写，以及中断1个过长的处理操作，这种动作往往有严重后果。
假如文档文本编制是以对话形式提供，用户应直接访问该文本的子条文，例如通过目录表显示的选择和按关键字检索功能来实现。
A.3.4效率
应遵循产品描述中的效率说明。
A.3.5可维护性
应遵循产品描述中的可维护性说明。
A.3.6可移植性
应遵循产品描述中的可移植性说明。
北美产品安全ULCASETL
北美产品安全UL CAS ETL
申请人向UL申请的基本程序如下：
（一） 申请人向UL提供下列信息：申请人的名称、地址和联络人；产品的种类型号；产品的功能和操作；产品照片；产品线路图；产品安装说明；产品外形尺寸及资料；产品主要元器件一览表（对己认证过的元器件需单独列出）。
（二）UL项目工程师对提供的资料进行分析，假如认为资料已足够充分，即对该产品的认证立项，并向申请人寄发正式信件，该信件标明了必须的样品型号及数量、样品的装运要求、成本估算和应预付的保证金，还附带一式三份正式申请表。
（三） 申请人接到正式信件后，在申请表上签字，此后将三份申请表中的两份回寄给UL的项目工程师，另一份自己留存。同时UL预付保证金和发运样品。
（四） UL的项目工程师收到申请人签字的申请表、保证金、样品和要求的资料后即开始编制测试计划，并在项目工程师的指导下进行测试。
（五） 假如产品测试合格，UL将起草一份详细的技术报告（或称检验细则），并将该技术报告的副本寄给申请人。假如产品测试不合格，UL同样要发给申请人一份报告，说明不合格的具体原因，同时提出改进建议。待产品改进后可重新申请测试。
（六） 对测试合格的产品颁发认证标志。
（七） （假如申请人对测试鉴定结果有不同意见，可与项目工程师以及上级领导进行探讨，以求得解决。
其它：
UL收费： 如贵公司需认证单一品种，UL将依据具体的产品而定收费标准，如需认证一系列品种，需依品种数量而定。
本公司服务内容：为贵公司提供联络、沟通及翻译服务（如贵公司无翻译）。
时间：约4—6个月。
贵公司需提供资料：
A：产品技术参数。
B：外包装结构图。
C：电路图。
D：原理结构图。
E：资料采购方清单。
今日通过对《北美产品安全UL CAS ETL》的学习，相信你对认证有更好的认识。假如要办理相关认证，请联络我们吧。
