参考资料来源：
1、FDA-510(K)
2、General Principles of Software Validation
3、CFDA 医疗器械软件注册技术审查指导原则 --------------------------------------
CFDA和FDA医疗器械软件注册指南对照
The CFDA and FDA Medical software registration guide comparison Only focus on MODERATE CONCERN 仅罗列中等关注级别 EXP1a~1z Means the explain in Appendix 1 EXP2a~2z Means the explain in Appendix 2
附录一：FDA指导方法 CFDA和FDA医疗器械软件注册指南对照 The CFDA and FDA Medical software registration guide comparison EXP1a: Level of Concern 关注程度 We recommend that you indicate the Level of Concern for your Software Device, determined before the effects of any mitigations. We recommend that you clearly state which one of the three levels of concern is appropriate for your device and include documentation of the rationale for your decision. We also recommend that your documentation make your decision-making process apparent to FDA.
我们建议您了解软件设备每个关注程度级别所列举的内容，确定其影响。我们建议您清楚了解你的设备的内容符合三个级别中的哪一个，包括您设备的原理。我们也提供给您建议在决策过程中提交给FDA的文件。 EXP1b: Software Description 软件描述 We recommend that you provide a comprehensive overview of the device features that are controlled by software, and describe the intended operational environment. Generally, we recommend that you provide the information in paragraph format and highlight major or operationally significant software features. The software description should include information on the following: 

我们建议您提供一个综述，描述被该软件控制的器械的特征和预期的操作环境。一般来说，我们建议贵司提供段落格式、主要亮点或操作上重大的软件特征。软件描述应该包括以下信息：

 programming language
设计语言
hardware platform
硬件平台
operating system (if applicable)
操作系统（如适用） ·
use of Off-the-Shelf software (if applicable)
使用即插即用软件（如适用）
If your device uses Off the Shelf software, please refer to the FDA guidance document “Guidance for Off-the-Shelf SoftwareUse in Medical Devices.”
如果你的设备使用现有的软件，请参考“Guidance for Off-the-Shelf Software Use in Medical Devices”。 EXP1c:Device Hazard Analysis 器械危害分析 We recommend that you submit a Device Hazard Analysis for all Software Devices. The Device Hazard Analysis should take into account all device hazards associated with the device’s intended use, including both hardware and software hazards. We recommend that you present the information in tabular form with a line item for each identified hazard. This document can be in the form of an extract of the software-related items from a comprehensive risk management document, such as the Risk Management Summary described in ISO 14971. 我们建议您提交所有软件设备的设备风险分析。设备危险性分析应考虑到与设备的预期使用相关的所有设备的危害，包括硬件和软件的危害。我们建议您以表格的形式为每一个确定的危险的行项目提供信息。我们建议您按照ISO14971写的风险管理报告模板制作风险管理综述文件。必须包括以下每个内容： 

identification of the hazardous event

危害事件识别 

severity of the hazard

危害严重性

 cause(s) of the hazard

危害原因 

method of control (e.g., alarm, hardware design) 

控制方法（比如警报、硬件设计）

 corrective measures taken, including an explanation of the aspects of the device design/requirements, that eliminate, reduce, or warn of a hazardous event; and

采取正确的措施以根除、减少或警告危险事件，包括对器械设计／要求的解释 

verification that the method of control was implemented correctly.

 验证正确控制的方法 

When performing a hazard analysis, we recommend that you address all foreseeable hazards, including those resulting from intentional or inadvertent misuse of the device. 

当进行危险分析时，我们建议您解决所有可预见的危害，包括那些导致故意或无意误用的设备。 

EXP1d: Software Requirements Specification 

 软件规格需求说明书

( SRS) The Software Requirements Specification (SRS) documents the requirements for the software. This typically includes functional, performance, interface, design, developmental, and other requirements for the software. In effect, this document describes what the Software Device is supposed to do. Examples of some typical requirements that would be included in a SRS are described below. For Software Devices that are identified as Minor Level of Concern, we recommend that you provide only the summary functional requirements section from the SRS, including identification of off-the-shelf software. For Software Devices that are identified as Major or Moderate Level of Concern, we recommend that you provide the complete SRS document. 

软件需求规格说明书（SRS）归档管理文件的软件需求。通常包括功能，性能，界面，设计，开发和其他要求的软件。实际上，这个文档描述了软件设备应该做的。一些典型的要求，将被纳入如下的一个SRS的例子。关注级别小的软件设备，我们建议您只提供从SRS摘要的功能要求部分，包括现成的软件识别。关注级别为主要或中等水平的设备，我们建议您提供完整的SRS文档。 

Hardware Requirements

 硬件设备 

Microprocessors 

微处理器 

memory devices 

记忆体

 Sensors 

传感器

 energy sources

 能量源 

safety features 

安全特征 

communications 

通讯 

Programming Language Requirements 

程序语言要求

 Programming language requirements include program size requirements or restrictions, and information on management of memory leaks. 

编程语言的要求包括程序大小的要求或限制和管理内存泄漏的信息。 

Interface Requirements Interface requirements generally include both communication between system components and communication with the user such as: 

接口要求一般包括系统部件与用户的通讯，

比如： 

Printers

打印机

 Monitors

监控器 

keyboard

键盘

 mouse

鼠标 

Software Performance and Functional Requirements 

软件性能和功能需求 

Software performance and functional requirements include algorithms or control characteristics for therapy, diagnosis, monitoring, alarms, analysis, and interpretation with full text references or supporting clinical data, if necessary. Software performance and functional requirements may also include: 

软件性能和功能需求包括运算法则或控制治疗、诊断、监控、警报、分析和阐明的特性，必要时充分地参考原文或支持诊断数据。软件性能和功能需求也包括：

 device limitations due to software 

因软件而导致的器械的局限性 

internal software tests and checks

内部软件测试和核查 

error and interrupt handling

错误和干扰处理 

fault detection, tolerance, and recovery characteristics

故障测探，误差和恢复特征 

safety requirements

安全需求

 timing and memory requirements 

时间和记忆需求

 identification of off-the-shelf software, if appropriate.

适用时即插即用软件的识别 

EXP1e: Architecture Design Chart

 设计模块架构图 

This document is typically a flowchart or similar depiction of the relationships among the major functional units in the Software Device, including relationships to hardware and to data flows such as networking. It is usually not necessary to include every function call and module in this document; however, there should be sufficient information to allow for review of the organization of the software relative to the functionality and to the intended use of the Software Device. For Moderate and Major Level of Concern devices, detailed information such as state diagrams may be useful to clearly depict the relationships among the software functional units. If the Architecture Design Chart is included in another document such as the SRS then you should include in your submission a statement to that effect and a reference to the location of the Architecture Design Chart in the submission. 

该文档通常是一个流程图或类似的描述的软件设备中的主要功能单元之间的关系，包括到硬件和数据流如网络关系之间的关系。它通常没有必要包括在这个文件中的每一个函数调用和模块，但是，应该有足够的信息，以便审查该组织的软件相对于功能和预期使用的软件设备。关注级别为主要或中等水平的设备，详细描述状态图对清楚描绘软件功能单元之间的关系有益。如果设计图包含在另一个文档中，如SRS，那么应该提交一份声明，并标注参考位置。 

EXP1f: Software Design Specification 软件设计规格说明书( SDS) The Software Design Specification (SDS) describes the implementation of the requirements for the Software Device. Interms of the relationship between the SRS and the SDS, the SRS describes whatthe Software Device will do and the SDS describes how the requirements in the SRS are implemented. The information presented in the SDS should be sufficient to ensure that the work performed by the software engineers who created the Software Device was clear and unambiguous, with minimal ad hoc design decisions. The SDS may contain references to other documents, such as detailed software specifications. However, the document you submit should, in and of itself, provide adequate information to allow for review of the implementation plan for the software requirements in terms of intended use, functionality, safety, and effectiveness. 

软件设计规范（SDS）描述了软件设备的需求的实现。SRS和SDS之间的关系是，SRS描述软件设备需求，SDS描述了如何把SRS的要求落到实处。在SDS的信息应该足够，以确保由软件工程师的工作是明确的，已达到最小化的设计决策。SRS是软件器械需求的实施说明, 一般按预期使用、功能性、安全性和有效性来提供信息。它和SRS 的区别是: SRS 是描述器械将做什么( what) , 而SDS 是描述SDS 中的需求如何执行( how)。 

EXP1g: Traceability Analysis

 可追溯性分析 

A Traceability Analysis links together your product design requirements, design specifications, and testing requirements. It also provides a means of tying together identified hazards with the implementation and testing of the mitigations. We recommend that you submit for review explicit traceability among these activities and associated documentation because they are essential to effective product development and to our understanding of product design, development and testing, and hazard mitigations. The Traceability Analysis commonly consists of a matrix with line items for requirements, specifications and tests, and pointers to hazard mitigations. It is possible to document traceability simply through a shared organizational structure with a common numbering scheme; however, we recommend that you include some mechanism, such as a matrix for guiding the reviewer through the information you submit. 

可追溯性贯穿需求、规格说明书、危害识别和降低、验证和确认测试的始终。我们建议您提交审查明确追溯这些活动及相关文件，因为它们能有效的帮助产品开发，对我们的产品设计开发、测试和风险缓解措施的理解至关重要。可追溯性分析通常包括需求项目矩阵，规格和测试，以及风险缓解措施的指南。可追溯性文档可以简单地通过一个共享的组织结构或一个共同的编号方案，但是，我们建议你使用一些机制，如一个指导审稿人审核你提交的信息的追踪矩阵。 可追溯性分析包括追溯概念文档中的软件需求到系统需求; 追溯软件设计描述到软件需求规格, 以及软件需求规格到软件设计描述;追溯源代码对应到设计规格, 以及设计规格对应到源代码。分析确定它们之间正确性、一致性、完整性、精确性的关系。

 A Traceability Analysis links together your product design requirements,design specifications, and testing requirements. It also provides a means of tying together identified hazards with the implementation and testing of the mitigations. 

一个可追溯性分析与产品的设计要求、设计规格、测试要求是联系在一起的。它同时给出把识别危害、缓解测试和执行联系在一起。

 EXP1h: Software Development Environment Description 

 软件开发环境的描述 

For Moderate and Major Level of Concern Software Devices, the submission should include a summary of the software development life cycle plan. This summary should describe the sponsor’s software development life cycle and the processes that are in place to manage the various life cycle activities. For Major Level of Concern Software Devices, this document should also include an annotated list of the control/baseline documents generated during the software development process and a list or description of software coding standards. 

对于关注级别中等或高等的设备，提交文件中应包括软件开发生命周期规划的概要。该概要应描述提交者的软件开发生命周期和在适当位置管理各种各样的生命周期活动的过程。对重点关注的器械软件，该文件应也涵盖在软件开发过程和软件译码标准的清单或描述中控制／基线文件的注解单中。 

As mentioned elsewhere, configuration or change management is a crucial aspect of software development. Changes to the Software Device after initial market release should be subject to positive control, with definitive specification and test plans including well-defined regression testing where appropriate. The description of the development environment should provide information on your configuration management and maintenance plan that addresses these aspects of the software development life cycle. For a Major Level of Concern device, we recommend that you provide sufficient detail to allow for a thorough understanding of the configuration management and maintenance plan. For a Moderate Level of Concern device, we recommend that you provide only a summary of the configuration management and maintenance plans. 

如前所述，配置或变更管理是软件开发的一个重要方面。在最初的市场发布后的软件设备的变化应受到积极的控制，具有明确的规范和测试计划，包括明确定义适当的回归测试。开发环境的描述应该提供您的配置管理和维护计划的信息，这些信息涉及软件开发生命周期的这些方面。对于一个关注级别高的设备，我们建议您提供足够的细节，以便对配置管理和维护计划有深入的了解。对于一个关注级别中等的设备，我们建议您只提供配置管理和维护计划的概要。 

EXP1i: Verification and ValidationDocumentation验证和确认文件 The terms “verification” and “validation” described earlier in this document refer to two phases of Software Device testing. This section recommends the type of testing documentation you should include in a premarket submission for a Software Device, based on the Level of Concern. 

本文档前面所描述的术语“验证”和“确认”是指软件设备测试的两个阶段。本节介绍测试文档的类型应基于关注的程度包括在一个软件设备市场批准中。 

Minor Level of Concern Devices 

关注度低的设备 

For Minor Level of Concern devices, we recommend that you submit documentation of system or device level testing, and, where appropriate, integration testing. The documentation submitted should include system or device level test pass/fail criteria and a summary of the test results. 

对于轻微关注度的器械，我们建议提交器械水平或系统测试文件，适用时，综合测试。提交的文件应包括系统或器械水平测试通过／未通过标准以及摘要和测试结果标准。 Moderate Level of Concern Devices 关注度中等的设备 

For Moderate Level of Concern devices, we recommend that you submit a summary list of validation and verification activities and the results of these activities. We also recommend that you submit your pass/fail criteria. You should ensure that the Traceability Analysis effectively links these activities and results to your design requirements and specifications. 

对于中等关注度的设备，我们建议提交验证和确认活动的清单以及结果的总结。提交的文件应包括系统或器械水平测试通过／未通过标准以及摘要和测试结果标准。你必须确保可追溯分析的有效性链接，如设计要求和规格以及结果的符合。 Major Level of Concern Devices 关注度高的设备 

For Major Level of Concern devices, we recommend that you submit the information recommended above for Moderate Level of Concern devices and a description of any tests that were not passed. We also recommend that you include any modifications made in response to failed tests and documentation of results demonstrating that the modifications were effective. Documentation provided in your submission should include examples of unit integration testing and a summary of the results. 

对于关高度注度的设备，我们建议你们提交以上关于中等关注器械的文件，和未通过测试的描述。我们建议你们涵盖对符合测试失败和结果作出的修改，并证明修改是有效的。提交的文件中应包括模块综合测试和结果摘要。 

EXP1j: Revision Level History 

 版本修订历史

 Your submission should include the history of software revisions generated during the course of product development. This typically takes the form of a line-item tabulation of the major changes to the software during the development cycle, including date, version number, and a brief description of the changes in the version relative to the previous version. The last entry inthe list should be the final version to be incorporated in the released device. This entry should also include any differences between the tested version of software and the released version, along with an assessment of the potential effect of the differences on the safety and effectiveness of the device. 

开发过程的主要改变包括版本号和日期, 还有此版和前版的主要不同; 还有测试版和发布版的不同, 以及变化带来的对器械安全性和有效性的潜在影响的评估。提交的文件应包括产品发展过程中软件版本修正的历史。该文件通常使用开发周期中软件主要变化的项目表格，包括以前译本的日期、版本型号和变化的简短描述。 

EXP1k: Unresolved Anomalies (Bugs orDefects) 

 未解决的异常( Bug 或缺陷) 

For Moderate and Major Level of Concern Software Devices, the submission should include a list of all unresolved software anomalies. For each anomaly, we recommend that you indicate the: 对于关注度中等和高的设备，提交的文件需要包含一个所有未解决的软件异常的清单。对于每个异常，需要列明： 

problem

问题点

 impact on device performance

对于器械性能的影响

 any plans or timeframes for correcting the problem (where appropriate). 

解决这些问题的计划或者时间表 

We recommend that you annotate each item with an explanation of the impact of the anomaly on device safety or effectiveness, including operator usage and human factors issues. Typically, this list can be generated as an output of a change control board or similar mechanism for evaluation and disposition of unresolved software anomalies. We recommend that you communicate this list to the end user as appropriate to assist in the proper operation of the device. In all instances where it is practical to do so, you should include any mitigations or possible work-arounds for unresolved anomalies; this recommendation applies to Blood Establishment Computer Software in particular. 

对每种未解决的异常应说明: 困难所在、对器械性能的影响、解决困难的计划或日程表。 综上所述, 可以看出FDA 对医疗器械软件管理的特点有以下三个。一是基于风险管理控制, 产品应在风险管理体系之内开发和维护; 二是结合了软件产品的特点, 遵从软件生存周期过程的规律; 三是用众多的指南性文件支持其管理, 从产品的注册指导到产品生产的过程确认原则再到专门的软件类别要求一应俱全, 由点及面。这样, 各种软件包括软件组件在各个活动阶段都能找到适合的指导原则。 总之, FDA 对医疗器械软件的管理要求较具体并有相关国际化标准或国家标准作为技术支持或参考, 例如ISO14971、IEC60601- 1- 4 和AAMI SW68等, 它们之间是紧密关联的。借鉴美国FDA 对医疗器械软件管理的经验, 国内也应尽快出台相关的法规来规范对医疗器械软件的要求, 以适应医疗器械软件产业的快速发展。 

CFDA和FDA医疗器械软件注册指南对照 

The CFDA and FDA Medical software registration guide comparison 

Appendix 2：CFDA Medical device software registration technical reviewguidelines

 附录二：CFDA医疗器械软件注册技术审查指导原则 SFDA要提交的文件清单： 软件描述文档 软件描述文档基于YY/T 0664《医疗器械软件软件生存周期过程》予以制定，用于自主开发医疗器械软件的产品注册。软件描述文档包括基本信息、实现过程和核心算法（详见表1）。 

（一）基本信息EXP2a:软件标识 明确软件的名称、型号规格、发布版本、制造商和生产地址。软件组件标识为制造商质量控制所用标识。EXP2b:安全性级别 明确软件安全性级别（A级、B级、C级），详述确定理由。EXP2c:结构功能 依据软件设计规范（SDS）提供体系结构图和用户界面关系图（如适用）。 体系结构图用于图示组成模块之间、组成模块与外部接口之间的关系，依据体系结构图描述组成模块（注明选装、模块版本）的功能、模块关系和外部接口。 用户界面关系图用于描述用户界面之间的关系，依据用户界面关系图（如不适用则为体系结构图）描述临床功能模块（注明选装、模块版本）的功能和模块关系。 EXP2d:硬件拓扑 依据软件设计规范（SDS）提供物理拓扑图，图示并描述软件（或组成模块）、通用计算机、医疗器械硬件之间的物理连接关系。EXP2e:运行环境 明确软件运行所需的硬件配置、软件环境和网络条件。其中硬件配置包括处理器、存储器和外设器件，软件环境包括系统软件、支持软件和安全软件，网络条件包括网络架构（BS、CS）、网络类型（广域网、局域网、个域网）和带宽。 EXP2f:适用范围 独立软件描述软件的适用范围，软件组件描述医疗器械产品的适用范围。进口医疗器械软件描述原产国情况。EXP2g:禁忌症 独立软件描述软件的禁忌症或使用限制，软件组件描述医疗器械产品的禁忌症或使用限制。进口医疗器械软件描述原产国情况。EXP2h:注册历史 独立软件描述中国注册情况（列明历次注册的发布版本和注册证号）和原产国注册情况（如适用，列明历次注册的日期、发布版本和管理类别），在其它主要国家和地区的注册情况也可提供。软件组件描述医疗器械产品的注册情况。 

（二）实现过程EXP2i:开发概述 明确软件开发所用的语言、工具和方法，其中工具描述支持软件（含开源软件）和应用软件（第三方软件）的名称、完整版本和供应商。同时明确开发人员数量、开发时间、工作量（人月数）和代码行总数。EXP2j:风险管理 依据风险管理相关标准提供软件风险分析报告和软件风险管理报告，风险管理资料另附原始文件。软件组件提供医疗器械产品的风险管理资料。EXP2k:需求规范 A级提供软件需求规范（SRS）关于软件功能的要求，B级和C级提供软件需求规范全文。软件需求规范另附原始文件。软件组件如无单独的软件需求规范，可提供医疗器械产品的需求规范。EXP2l:生存周期 A级提供软件开发生存周期计划摘要，描述开发各阶段的划分情况和工作任务。B级在A级基础上提供配置管理计划摘要和维护计划摘要，描述所用的工具和流程。C级在B级基础上提供设计历史文档集索引表（DHF）。 生存周期也可提交制造商软件生存周期过程文件或YY/T 0664《医疗器械软件软件生存周期过程》等过程标准的核查表，用于替代相应描述。 EXP2m:验证与确认 验证是指通过提供客观证据认定软件某开发阶段的输出满足输入要求，包括代码检查、设计评审、测试等质量保证活动。确认是指通过提供客观证据认定软件满足用户需求和预期用途，通常是指在真实或模拟使用环境进行的用户测试。可追溯性分析是指追踪需求规范、设计规范、源代码、测试、风险管理之间的关系，分析已识别关系的正确性、一致性、完整性和准确性。 A级提供系统测试、用户测试的计划和报告摘要，描述测试的条件、工具、方法、通过准则和结果。B级提供系统测试、用户测试的计划和报告，概述开发各阶段的验证活动，描述所用的工具、方法和任务。C级在B级基础上提供可追溯性分析报告（追溯需求规范、设计规范、测试、风险管理的关系表）。 系统测试和用户测试的计划和报告另附原始文件。测试报告关于测试记录的内容可以提供一个测试记录样例和完整的测试记录清单。验证活动也可提交制造商软件质量保证计划文件，用于替代相应描述。EXP2n:缺陷管理 A级描述缺陷管理的工具和流程，明确软件本次注册已知的缺陷总数和剩余缺陷数。B级和C级在A级基础上列明已知剩余缺陷情况，证明全部已知剩余缺陷的风险均是可接受的。已知剩余缺陷情况可另附原始文件。 EXP2o:更新历史 A、B、C级均应描述软件版本命名规则，明确软件版本的全部字段及字段含义，确认软件完整版本和软件发布版本。 A级列明软件本次注册与前次注册之间历次软件更新的完整版本、日期和类型。B级在A级基础上详述历次软件更新的具体更新内容。C级列明软件历次注册时历次软件更新的完整版本、日期、类型和具体更新内容。 进口医疗器械软件描述原产国的更新情况，首次产品注册描述软件开发阶段的更新情况。更新历史可另付原始文件。EXP2p:临床评价 临床评价资料另附原始文件。 （三）核心算法EXP2q:核心算法 依据软件设计规范（SDS）和说明书列明核心算法的名称、类型、用途和临床功能。核心算法是指实现软件核心功能（软件在预期使用环境完成预期用途所必需的功能）所必需的算法，包括但不限于成像算法、后处理算法和人工智能算法。其中成像算法是指用于获取医学图像或数据的算法，后处理算法是指改变原始医学图像或数据产生新临床信息的算法，人工智能算法是指采用人工智能技术进行医学图像或数据分析的算法。 算法类型包括公认成熟算法和全新算法。其中公认成熟算法是指源自公开文献资料、原理简单明确、上市多年且无不良事件的算法，而全新算法是指源自临床研究、科学研究的新算法。 核心算法详尽程度取决于安全性级别和算法类型。当安全性级别为A级时，公认成熟算法和全新算法均列明算法的名称、类型、用途和临床功能。当安全性级别为B级和C级时，公认成熟算法列明算法的名称、类型、用途和临床功能，全新算法在公认成熟算法基础上提供安全性与有效性的验证资料。 【CFDA和FDA医疗器械软件注册参考文献清单】

[1]《医疗器械注册管理办法》（国家食品药品监督管理总局令第4号） 

[2]《医疗器械说明书和标签管理规定》（国家食品药品监督管理总局令第6号） 

[3]《医疗器械召回管理办法（试行）》（卫生部令第82号） 

[4] 国家食品药品监督管理总局关于发布医疗器械产品技术要求编写指导原则的通告（国家食品药品监督管理总局通告2014年第9号） 

[5] 国家食品药品监督管理总局关于公布医疗器械注册申报资料要求和批准证明文件格式的公告（国家食品药品监督管理总局公告2014年第43号） 

[6] 国家食品药品监督管理总局关于实施《医疗器械注册管理办法》和《体外诊断试剂注册管理办法》有关事项的通知(食药监械管[2014]144号) 

[7] 国家食品药品监督管理总局关于发布医疗器械临床评价技术指导原则的通告（国家食品药品监督管理总局通告2015年第14号） 

[8] GB/T 13702-1992《计算机软件分类代码》 

[9] GB/T 18492-2001《信息技术系统及软件完整性级别》 

[10] GB/T 11457-2006《信息技术软件工程术语》 

[11] GB/T 20157-2006《信息技术软件维护》 

[12] GB/T 19003-2008《软件工程 GB/T 19001-2000应用于计算机软件的指南》 

[13] GB/T 25000.51-2010《软件工程软件产品质量要求与评价（SQuaRE）商业现货（COTS）软件产品的质量要求与测试细则》 

[14] YY 0637-2013《医用电气设备放射治疗计划系统的安全要求》 

[15] YY 0709-2009《医用电气设备 第1-8部分：安全通用要求并列标准医用电气设备和医用电气系统中报警系统的测试和指南》 

[16] YY 0721-2009《医用电气设备放射治疗记录与验证系统的安全》 

[17] YY 0775-2010《远距离放射治疗计划系统高能X(γ）射束剂量计算准确性要求和试验方法》 

[18] YY 0831.1-2011《γ射束立体定向放射治疗系统第1部分：头部多源γ射束立体定向放射治疗系统》 [19] YY 0832.1-2011《X射线放射治疗立体定向及计划系统第1部分：头部X射线放射治疗立体定向及计划系统》 [20] YY/T 0287-2003《医疗器械质量管理体系法规要求》 

[21] YY/T 0316-2008《医疗器械风险管理对医疗器械的应用》 

[22] YY/T 0664-2008《医疗器械软件软件生存周期过程》 

[23] YY/T 0708-2009《医用电气设备第1-4部分：安全通用要求并列标准可编程医用电气系统》 

[24] YY/T 0887-2013《放射性粒籽植入治疗计划系统剂量计算要求和试验方法》 

[25] YY/T 0889-2013《调强放射治疗计划系统性能和试验方法》 

[26] FDA, Do It by Design - An Introduction to Human Factors in Medical Devices, December, 1996

[27] FDA, Deciding When to Submit a 510(k) for a Change to an Existing Device, January 10, 1997 

[28] FDA, Reviewer Guidance for a Premarket Notification Submission for Blood Establishment Computer Software, January 13,1997 

[29] FDA, Design Control Guidance for Medical Device Manufacturers, March 11, 1997 

[30] FDA, Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices, May 29,1998 [31] FDA, Guidance for Industry, FDA Reviewers and Compliance on Off-The-Shelf Software Use in Medical Devices, September 9,1999 

[32] FDA, Guidance for the Submission of Premarket Notifications for Medical Image Management Devices, July 27, 2000 

[33] FDA, General Principles of Software Validation; Final Guidance for Industry and FDA Staff, January 11, 2002 

[34] FDA, Cybersecurity for Networked Medical Devices Containing Off-the-Shelf Software, January 14, 2005 

[35] FDA, Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices, May 11, 2005
[36] FDA, Guidance for Industry and FDA Staff -Modifications to Devices Subject to Premarket Approval (PMA) - The PMA Supplement Decision, December 11, 2008
[37] FDA, Guidance for Industry and Food and Drug Administration Staff - Computer-Assisted Detection Devices Applied to Radiology Images and Radiology Device Data - Premarket Notification [510(k)] Submissions, July 3, 2012 

[38] FDA, Guidance for Industry and FDA Staff - Clinical Performance Assessment: Considerations for Computer-Assisted Detection Devices Applied to Radiology Images and Radiology Device Data - Premarket Approval(PMA) and Premarket Notification [510(k)] Submissions, July 3, 2012
[39] FDA, Content of Premarket Submissions for Management of Cybersecurity in Medical Devices - Guidance for Industry and Food and Drug Administration Staff, October 2, 2014 

[40] FDA, Mobile Medical Applications - Guidance for Industry and Food and Drug Administration Staff, February 9, 2015 

[41] FDA, Medical Device Data Systems, Medical Image Storage Devices and Medical Image Communications Devices - Guidance for Industry and Food and Drug Administration Staff, February 9, 2015 

[42] FDA, General Wellness: Policy for Low Risk Devices - Draft Guidance for Industry and Food and Drug Administration Staff, January 20,2015 

[43] MEDDEV 2.7/1 Rev.4, Clinical evaluation: Guide for manufacturers and notified bodies, December 2016 [44] MEDDEV 2.7/4, Guidelines on Clinical investigations: a guide for manufacturers and notified bodies, December 2010 

[45] MEDDEV 2.1/6, Qualification and Classification of standalone software, January 2012 

[46] NB-MED/2.2/Rev4, Software and Medical Devices, March 29, 2010 

[47] Team-NB, Frequently Asked Questions related to the Implementation of EN 62304:2006 with respect to MDD 93/42/EEC, April 5, 2013
[48] IEC 62366 Ed1.1:2014, Medical devices - Application of usability engineering to medical devices [49] IEC/TR 80002-1:2009, Medical device software - Part 1: Guidance on the application of ISO 14971 to medical device software
[50] IEC80001-1:2010, Application of risk management for IT-networks incorporating medical devices - Part 1: Roles,responsibilities and activities
[51] IEC/TR 80001-2-1:2012, Application of risk management for IT-networks incorporating medical devices - Part 2-1: Step-by-step risk management of medical IT-networks – Practical applicationsand examples
[52] IEC/TR 80001-2-2:2012, Application of risk management for IT-networks incorporating medical devices - Part 2-2: Guidance for the disclosure and communication of medical device security needs, risksand controls
[53] IEC/TR 80001-2-3:2012, Application of risk management for IT-networks incorporating medical devices - Part 2-3: Guidance for wireless networks
[54] IEC/TR 80001-2-4:2012, Application of risk management for IT-networks incorporating medical devices - Part 2-4: Application guidance - General implementation guidance for healthcare delivery organizations [55] IEC 62304 am1, Medical device software - Software life cycle processes
[56] IEC 82304-1, Health Software - Part 1: General requirements for product safety
[57] IEC/TR 80002-2, Medical device software - Part 2: Validation of software for regulated processes
[58] IMDRF/UDI WG/N7FINAL:2013, UDI Guidance: Unique Device Identification of Medical Devices,December18, 2013
[59] IMDRF/SaMD WG/N10FINAL:2013, Software as a Medical Device: Key Definitions, December18, 2013
[60] IMDRF/SaMD WG/N12FINAL:2014, Software as a Medical Device: Possible Framework for Risk Categorization and Corresponding Considerations,September18, 2014
（本文来源：医疗器械从业者）