医疗器械软件描述文档要求(中英对照).doc

上传人:仙人指路1688 文档编号:2302331 上传时间:2023-02-10 格式:DOC 页数:9 大小:56.50KB
返回 下载 相关 举报
医疗器械软件描述文档要求(中英对照).doc_第1页
第1页 / 共9页
医疗器械软件描述文档要求(中英对照).doc_第2页
第2页 / 共9页
医疗器械软件描述文档要求(中英对照).doc_第3页
第3页 / 共9页
医疗器械软件描述文档要求(中英对照).doc_第4页
第4页 / 共9页
医疗器械软件描述文档要求(中英对照).doc_第5页
第5页 / 共9页
点击查看更多>>
资源描述

《医疗器械软件描述文档要求(中英对照).doc》由会员分享,可在线阅读,更多相关《医疗器械软件描述文档要求(中英对照).doc(9页珍藏版)》请在三一办公上搜索。

1、医疗器械软件描述文档要求(中英对照) 一、适用范围1、独立软件:本身是医疗器械或附件的软件,如处理型软件、数据型软件;2、软件组件:作为医疗器械、部件或附件组成部分的软件,如嵌入式软件、控制型软件;3、专用软件:其他有特定用途的软件,如个体化定制型软件。一、申报要求制造商应提供一份单独的医疗器械软件描述文档,包括基本信息、实现过程和核心算法三部分内容,详尽程度取决于医疗器械软件的安全性级别和复杂程度。软件安全性级别(YY/T 0664-2008)基于医疗器械软件损害严重度分为:A级:不可能对健康有伤害和损坏;B级:可能有不严重的伤害;C级:可能死亡或严重伤害。对于B级和C级的医疗器械软件,软件

2、描述文档的部分内容应提供原始文件 医疗器械软件描述文档的具体内容要求如下:1、基本信息1.1 产品标识描述医疗器械软件的名称、型号、版本号、制造商和生产地址,软件组件为内部标识。1.2 安全性级别依据软件的功能、预期用途和使用环境说明医疗器械软件的安全性级别,并详细说明安全性级别的确定理由。1.3 结构功能依据软件设计规格(SDS)给出体系结构图,图示医疗器械软件组成模块之间、组成模块与外部接口之间的关系。依据体系结构图描述组成模块的功能、模块关系、模块与外部接口关系以及用户界面。组成模块应注明选装、版本号及现成软件的名称、版本号、制造商和类型(外包、成品、遗留)。1.4 硬件关系依据软件设计

3、规格(SDS)给出物理拓扑图,图示医疗器械软件、通用计算机、医疗器械硬件相互之间的物理连接关系。依据物理拓扑图描述医疗器械软件(或组成模块)与通用计算机、医疗器械硬件的物理连接关系。1.5 运行环境描述医疗器械软件运行所需的硬件配置、软件环境和网络条件。硬件配置包括包括处理器、存储器、外设器件和IO设备,软件环境包括系统软件、支持软件、必备软件、选配软件和杀毒软件,网络条件包括网络接口、网络类型(局域网、广域网)和网络架构(CS、BS)。1.6 适用范围独立软件应描述软件的适用范围和适用人群,软件组件应描述其整体的功能用途以及医疗器械产 品的适用范围和适用人群。1.7 禁忌症独立软件应描述软件

4、的禁忌症和不适用人群,软件组件应描述其整体的禁用功能以及医疗器械产品的禁忌症和不适用人群。1.8 上市历史医疗器械软件在中国实质首次注册应依据医疗器械分类目录及后续分类界定通知说明软件的管理类别,实质重新注册应列明在中国所有已上市产品的版本号和产品注册证号。同时应列明医疗器械软件在原产国、美国、日本和欧盟等主要国家与地区首次上市的时间、版本号和管理类别。软件组件应描述医疗器械产品(包含本软件组件)的上市历史。2、实现过程2.1 开发综述描述医疗器械软件开发过程所用的语言、工具、方法和生存周期模型,其中工具应描述支持软件(含开源软件)和应用软件(第三方软件)的名称、版本号和制造商。同时应说明开发

5、人员数量、开发时间、工作量(人月数)、代码行总数和控制文档总数。2.2 风险管理应提供风险管理报告,包括名称、严重度、原因、解决措施和结果。风险管理实施情况应另附原始文件,软件组件应提供医疗器械的风险管理报告。当组成模块采用现成软件时,所有级别医疗器械软件均应对现成软件进行风险管理。2.3 需求规格A级医疗器械软件应描述软件需求规格(SRS)关于功能和性能的要求。B级和C级医疗器械软件应提供软件需求规格全文。需求规格应另附原始文件,软件组件可提供医疗器械产品的需求规格。当组成模块采用现成软件时,B级和C级医疗器械软件应说明相应要求。2.4 生存周期A级医疗器械软件应提供软件开发生存周期计划摘要

6、,描述各阶段的任务、内容和结果。B级医疗器械软件在A级基础上应提供软件配置管理计划摘要和维护计划摘要,描述相应的工具、流程和要求。C级医疗器械软件在B级基础上应列明各阶段的输入输出控制文档。生存周期实施情况应另附原始文件,YY/T 0664-2008或YY/T 0708-2009核查表可提供作为参考。当组成模块采用现成软件时,B级和C级医疗器械软件应在开发生存周期计划、配置管理计划和维护计划中说明相应要求。2.5 验证与确认A级医疗器械软件应提供系统测试、用户测试的测试计划和报告摘要,描述测试的条件、工具、方法、通过准则和结果。B级医疗器械软件在A级基础上应概要介绍开发各阶段的验证活动,描述相

7、应的工具、方法、内容和结果,其中单元测试应描述覆盖率要求,集成测试应描述集成策略。C级医疗器械软件应概要介绍开发各个阶段的验证活动,并提供系统测试、用户测试的测试计划和报告。系统测试和用户测试应另附原始文件,可追溯性分析报告可提供作为参考。当组成模块采用现成 软件时,所有级别软件均应进行验证与确认。2.6 缺陷管理A级医疗器械软件应描述缺陷管理的工具、流程和要求,列明开发阶段所发现的缺陷总数和剩余缺陷数。B级和C级医疗器械软件在A级的基础上应列明剩余缺陷的严重度、处理措施和处理时间。当组成模块采用现成软件时,B级和C级医疗器械软件应列明全部剩余缺陷情况。2.7 修订历史A级医疗器械软件应描述软

8、件版本号的命名规则,列明软件在原产国本版本所有修订活动的版本号、类型(完善型、适应型、纠正型)和日期。B级医疗器械软件在A级基础上应详述本版本与原产国前次批准上市版本的变更内容。C级医疗器械软件在B级基础上应列明软件在原产国首次上市后历次修订且批准上市的版本号、类型和日期。2.8 临床评价临床评价资料包括文献资料、临床数据和临床试验报告,应另附原始文件。3、核心算法依据软件设计规格(SDS)和用户说明书列明核心算法的名称、原理、用途和类型。核心算法包括后处理算法和人工智能算法,其中后处理算法通常会改变原始医学图像或数据,包括但不限于压缩、分割、配准融合、三维重建、量化分析和异常识别;人工智能算

9、法通常基于数据库进行分析处理,包括但不限于模式识别、神经网络和专家系统。类型是指公认成熟算法(公开文献专利标准、原理简单明确、上市超过四年且无不良事件)或全新算法(源自科学研究和临床数据)。核心算法提交材料的详尽程度取决于安全性级别和类型。当安全性级别为A级时,公认成熟算法可只列明名称,全新算法应描述原理和用途。当安全性级别为B级或C级时,公认成熟算法应描述原理和用途,全新算法除描述原理和用途外还应提供安全性与有效性的验证资料。医疗器械软件实质首次注册应列明所有核心算法的名称、原理、用途和类型,实质重新注册应列明本版新增核心算法的名称、原理、用途和类型。三、现成软件随着计算机技术的快速发展,医

10、疗器械使用现成软件的情况越来越普遍,但是现成软件并不能完全满足医疗器械的全部预期用途。同时,由于未进行完整的软件生存周期控制,制造商使用现成软件的风险要高于自主开发的软件,但是仍然要对医疗器械后续的安全性和有效性负责。因此,制造商应采用基于风险管理的方法对现成软件进行管理。对于部分采用现成软件的方式,外包、成品和遗留软件申报要求相同,已在前一章详细说明。对于全部采用现成软件的方式,申报要求如下:1、外包软件应提供外包合同和软件描述文档;2、成品软件应提供外购合同和软件描述文档(不适用内容应说明理由),如已在中国上市应提供产品注册证复印件和相应资料;3、遗留软件应提供产品注册证复印件和软件描述文

11、档(不适用内容应说明理由)。 IApplicable Scope The guidance is applicable to the initial registration and registration renewal of imported products and Class III domestic products, and also applicable to self-developed software, partly using off-the-self software and completely using off-self-software. It include

12、s:(1) Independent software: Software as medical device or accessory, such as processing software, data software.(2) Software component: Software as component of medical device, part or accessory, such as embedded software, control software.(3) Specialized software: Other special purpose software, su

13、ch as individual customer-made software. II. Application Requirement: The MANUFACTURER shall provide a separate software description document of medical device, including basis information, implementation process and core algorithm. The level of specificity depends on the safety class and complicati

14、on level.The MANUFACTURER shall assign to each SOFTWARE SYSTEM a software safety class (A, B, orC) (Note: Please see Clause 4.3 of IEC 62304-2006 about the safety classification) according to the possible effects on the patient, operator, or other people resulting from a HAZARD to which the SOFTWARE

15、 SYSTEM can contribute.The software safety classes shall initially be assigned based on severity as follows: Class A: No injury or damage to health is possibleClass B: Non-SERIOUS INJURY is possibleClass C: Death or SERIOUS INJURY is possibleFor Class B and C software, some software description docu

16、ments should be original files.The requirement of software description document of medical device is as following:1. Basic Information 1.1 Product Identification Provide the name, model, version, manufacturer and manufacturing site of medical device software.Note: Software component should be intern

17、al identifier. 1.2 Safety Class Describe the safety class of software based on the function, intended use and application environment of software.Explain in detail how the safety class is determined. 1.3 Architecture FunctionProvide system architecture diagram based on Software Design Specification

18、(SDS), which shows the relationship among component modules of software, and the relationship between component modules and external interface.Describe component module function, relationship among component modules, relationship between component modules and external interface, and user interface b

19、ased on system architecture diagram.For component modules, please identify that optional configuration or not, version number. For off-the-shelf software, please identify its version number/ manufacturer name / type (outsourcing, ready-made, legacy). 1.4 Hardware Relationship Provide physical topolo

20、gy graph based on Software Design Specification (SDS), which shows the physical connection relationship among software, general purpose computer, and hardware.Describe the physical connection relationship among software, general purpose computer, and hardware based on physical topology graph. 1.5 Ru

21、ntime Environment Describe required hardware configuration, software environment and network condition.Hardware configuration includes central processing unit (CPU), memory, peripheral components, and I/O device.Software environment includes system software, supporting software, essential software,

22、optional software, and anti-virus software.Network condition includes network interface, network type (local area networkLAN, wide area network-WAN), and network architecture (CS, BS). 1.6 Indications For independent software, please describe the indications and applicable population of the software

23、.For software component, please describe its function purpose as a whole, and the indications and applicable population of the medical device. 1.7 Contraindications For independent software, please describe the contraindications and non-applicable population of the software.For software component, p

24、lease describe its disable function as a whole, and the contraindications and non-applicable population of the medical device. 1.8 Listing History For the initial registration of the software in China, please identify the management classification based on “Classification Catalog of Medical Device”

25、and subsequent notices of classification definition.For the registration renewal of the software in China, please list the version number and registration number of all the legally marketed products in China. Please also list the initially marketed time, version number and management classification

26、in country of origin, and other main countries and areas, such as USA, Japan and Europe etc. For software component, please describe the listing history of the medical device (including the software component). 2. Implementation Process 2.1 Development Review Please describe the language, tool, meth

27、od and lifecycle model used in development process. For tool, please describe the name, version number and manufacturer of supporting software (include open-source software) and application software (third-party software).Please also describe the developers number, development time, working load (nu

28、mber of person and month), total number of code line, and total number of control document.2.2 Risk Management Please provide the risk management report which includes name, severity, reason, mitigation measures and result.Please attach original files to describe the implementation of risk managemen

29、t.For software component, please provide the risk management report of medical device.If using off-the-shelf software as component module, please describe the risk management to all the classes of the software. 2.3 Requirement Specification For Class A software, please describe the requirement of so

30、ftware requirement specification (SRS) to function and performance.For Class B and C software, please provide the whole software requirement specification. The whole software requirement specification include requirement in hardware, function, performance, input and output, interface, warning inform

31、ation, security and secrecy, data and database, documents and regulationsPlease attach original files to provide the software requirement specification.For software component, please provide the requirement specification of medical device. If using off-the-shelf software as component module, please

32、describe related requirement for Class B and C software. 2.4 Lifecycle For Class A software, please provide the abstract of software development lifecycle plan, and describe the task, content and result of each stage.For Class B software, please provide the abstract of software configuration managem

33、ent plan and maintenance plan, and describe the corresponding tool, flow and requirement on the basis of Class A.For Class C software, please list input and output control documents of each stage on the basis of class B.Please attach original files to describe the implementation of lifecycle. The ch

34、ecklist form in IEC62034-2006 or IEC60601-1-4 can be used as reference.If using off-the-shelf software as component module, please describe related requirement in development lifecycle plan, configuration management plan and maintenance plan for Class B and C software. 2.5 Verification and Validatio

35、n For Class A software, please provide system testing plan, user testing plan and report abstract, and describe the testing condition, tool, method, pass criteria and result.For Class B software, please introduce the validation activity of each development stage briefly, and describe the correspondi

36、ng tool, method, content and result. Among them, please describe the coverage for unit testing, and the integration strategy for integration testing. Please provide system testing plan, user testing plan and report abstract.For Class C software, please introduce the validation activity of each devel

37、opment stage briefly, and provide the system testing plan, user testing plan and report.Please attach original files for system testing and user testing. Please also provide traceability analysis report as reference.If using off-the-shelf software as component module, please perform the verification

38、 and validation to all the classes of software. 2.6 Defect Management For Class A software, please describe the tool, flow and requirement of defect management, and list the numbers of total defects and remaining defects which are found in development stage.For Class B and C software, please list th

39、e severity grade, removal measures and time of remaining defects on the basis of Class A.If using off-the-shelf software as component module, please list all the remaining defects for Class B and C software. 2.7 Revision History For Class A software, please describe the naming conventions of softwar

40、e version number, and list all the revision activities including version number, type (improvement, adaption, correction) and revision date in country of origin.For Class B software, please describe in detail the modification content between the version and the previous legally marketed version of t

41、he software in country of origin on the basis of Class A (that means the manufacturer also should describe the naming conventions of software version number, and list the revision number, type, and revision date of the version). For Class C software, please list each revision of the software after i

42、nitial legally marketed version, including version number, type and date of being approved into market in country of origin on the basis of Class B (that means the manufacturer also should describe the naming conventions of software version number, list the revision number, type, and revision date o

43、f the version, describe in detail the modification content between the version and the previous legally marketed version of the software). 2.8 Clinical Evaluation The clinical evaluation document includes literatures, clinical data and clinical trial report. The original files should be attached. 3.

44、 Core Algorithm Please list the name, principle, intended use and type of core algorithm based on Software Design Specification (SDS) and operators manual.The core algorithm includes post-processing algorithm and artificial intelligence algorithm. Post-processing algorithm can generally change origi

45、nal images or date, including but not limited in compression, segmentation, registration and fusion, 3D reconstruction, quantitative analysis and abnormal recognition.Artificial intelligence algorithm generally performs analysis and treatment based on database, including but not limited in pattern r

46、ecognition, neural network and expert system.Type means generally acknowledged mature algorithm (published literature patent standard, principle which is simple and clear, being into the market over 4 years without adverse events) and new algorithm (derived from scientific research and clinical data

47、).The level of specificity of submitted core algorithm document depends on the safety class and complication level.For Class A software, it is ok to just list name of generally acknowledged mature algorithm, and describe principle and purpose of new algorithm.For Class B and C software, it should li

48、st name and describe principle and purpose of generally acknowledged mature algorithm, and provide the validation document in safety and effectiveness of new algorithm in addition to describing its principle and purpose.For the initial registration of software, please list the name, principle, purpose and type of all the core algorithms.For the registration renewal of software, please list the name, principle, purpose and type of new added core algorithm. III. Off-the

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 建筑/施工/环境 > 项目建议


备案号:宁ICP备20000045号-2

经营许可证:宁B2-20210002

宁公网安备 64010402000987号