1. IEC62304强调医疗软件在明确和满足其预期用途的前提下，不能引发不可接受的风险

2. 62304提供一个医疗软件开发的框架，并指出框架下每个过程的要求，62304将过程分解为若干活动，活动分解为若干任务

3. IEC认为开发高质量的医疗软件必须结合ISO13485质量管理体系和ISO14971风险管理体系

4. IEC认为软件既可以引入风险也可以作为其他部分的风险控制措施

5. IEC认为软件开发和软件维护是同样重要的事情

• 软件开发过程

• 软件维护过程
• 除了软件开发和维护的过程，IEC认为软件配置管理过程、软件问题管理过程也应该是软件质量控制的一部分

1. 62304中没有关于组织结构方面的要求，唯一的要求是要满足62304中提出的过程、活动、任务，已达到符合62304的目标

2. 62304中并没有指定某一份设计文档要叫什么名字，这由企业自己来决定，但是，需要记录62304中的任务

3. 62304中没有指定特定的软件生命周期模型，这依赖组织或团队来自行决定

4. 62304中的shall表示强制要求、should表示推荐执行、may表示可以达到某一目标的某种方法、establish表示定义、记录、实现；as appropriate表示一个过程是强制执行了，除非你能证明你有更好的流程

5. 62304适用于那些自身是医疗设备的软件或是作为医疗设备的一个部件的所有软件

6. 62304并不包含医疗设备的确认过程，无论是作为医疗设备的部分还是软件本身就是医疗设备

7. 62304与60601-1、ISO13485、ISO14971的部分由对应关系

8. 遵从62304是基于内部或外部对于软件安全等级的评估，再来决定哪些过程是必须要的，如Class A的软件过程比Class B的软件少很多，当然，IEC也认为虽然标准制定了，但是可以有一定的弹性，这个就不好说了，在有条件先完全符合才是最好的做法

9. 术语和定义

   英文	中文	定义
   ACTIVITY	活动	任务的集合

ANOMALY

异常

任何与预期的需求规格的不一致

ARCHITECTURE

架构

系统的或组建的组织结构

CHANGE REQUEST

变更请求

软件产品的已记录规格要发生改变

CONFIGURATION ITEM

配置项

能够唯一标识的实体

DELIVERABLE

可交付物

活动或任务的预期成果或输出

EVALUATION

评估

某一项实体是否满足其指定标准的系统化评价

HARM

损害

对人或财务的物理上的伤害或损毁

HAZARD

危害

潜在的损害源

MANUFACTURER

制造商

任何设计、制造，或集成医疗设备系统、软件的自然人或法人

MEDICAL DEVICE

医疗设备

以为人类达到以下一项或多项目标

—疾病的诊断、阻止、监控、治疗或者缓；

—伤口的诊断、监控、治疗、缓和或者启动补偿机能；

—调查、更换、修正或者支持物理程序的剖析；

—支持或者延续生命；

—概念的控制

—医疗设施的消毒

—通过从人体获得的样本做试管实验，为医疗用途提供信息

而单独或组合使用的任何工具、装置、器具、机器、器械、植入物、试管中的试剂或者校准器、软件、材料或者其他相似或相关的物品

MEDICAL DEVICE SOFTWARE

医疗器械软件

单独作为医疗设备使用或被组合到医疗设备中的软件系统

PROBLEM REPORT

问题报告

一份关于用户或任何感兴趣人员认为的医疗设备软件违反或不符合预期用途或不符合规格而认为或感到不安全的报告，厂商可以合理拒绝这类报告

PROCESS

过程

将输入转化为输出的独立或相关的活动的集合

REGRESSION TESTING

回归测试

确认对某一系统组件的修改没有引发功能、可靠性、性能方面问题的过程

RISK

风险

损害发生概率和严重性的组合

RISK ANALYSIS

风险分析

系统的使用已知信息来识别危害和估算风险的过程

RISK CONTROL

风险控制

制定降低和维持风险在某一特定等级的过程

RISK MANAGEMENT

风险管理

分析、评估和控制风险任务的系统化的管理策略、程序和实践

RISK MANAGEMENT FILE

风险管理文档

风险管理过程产出的文档和记录

SAFETY

安全性

没有不可接受的风险

SECURITY

保密性

阻止信息和数据被非授权人员和系统读取和修改，允许授权人员和系统获取的措施

SERIOUS INJURY

严重损伤

可能直接或间接造成人员死亡或永久性伤害，永久性伤害指不可逆的身体结构或既能损害

SOFTWARE DEVELOPMENT LIFE CYCLE MODEL

软件开发生命周期模型

从软件需求定义至软件发布的整个过程，包含

——识别过程、活动和任务

——描述活动或任务之间的顺序和依赖关系

——识别里程碑

SOFTWARE ITEM

软件项

可识别的程序部分

SOFTWARE PRODUCT

软件产品

计算机程序、过程以及相关文档、数据的集合

SOFTWARE SYSTEM

软件系统

为了达到特定功能或功能集的软件项的组合

SOFTWARE UNIT

软件单元

不能再细分的软件项

SOUP 

software of unknown provenance (acronym)（OTS）

第三方软件

不是为了组成医疗设备而开发的已可获取的软件项或已经被开发出但无法获取到充足的开发过程记录的软件

SYSTEM

系统

为了满足预设目标和对象的一个活多个过程、硬件、软件、设备和人的组合

TASK

任务

需要被完成的单个工作项

TRACEABILITY

可追踪性

建立两个或两个以上开发过程产出的关联关系的度量

VERIFICATION

验证

通过提供客观的证据确认特定的需求已经得到完全满足

VERSION

版本

标识某配置项的特征

1. 医疗设备的制造商要能证明医疗设备软件既能满足客户的需求，又能符合法规的要求，这个证明可以通过质量管理系统，可以是ISO13485或一个当地（国家的）的质量管理体系

2. 风险管理需要遵循ISO14971

3. 制造商应该对所设计生产的软件系统赋予一个安全级别，

   1. A级不会对健康造成伤害

   2. B级没有严重伤害

   3. C级可能造成死亡或严重伤害

   4. 如果某种危害是因为软件系统识别出来的，那么这种危害发生的概率认为是100%

   5. 软件风险引发的危害或潜在危害，只有通过硬件风险控制措施，才能降低软件安全等级

   6. 软件安全等级分级应该基于风险控制措施之后的来制定

   7. 应该在风险管理文档中记录软件安全等级

   8. 如果软件系统被细分，每一个软件项都应该被赋予一个安全级别

   9. 软件系统的初始安全等级应该是C，直到风险分析做完，赋予了一个软件安全级别后，才使用具体的软件安全级别的流程

4. 软件开发计划应该包含

   1. 软件系统开发所使用的过程

   2. 活动和任务的可交付物

   3. 系统需求、软件需求、风险措施以及系统测试之间的可追踪性

   4. 包含SOUP在内的软件系统开发支持工具、配置项和变更管理

   5. 软件系统缺陷管理计划

   6. 除此之外，应该保持更新计划的状态

5. 如果软件的安全等级是C，软件开发计划中应该包含或引用开发软件项的工具、方法和标准

6. 软件验证计划应该包含

   1. 需要验证的交付件

   2. 每个生命周期活动的验证任务

   3. 可交付物验证的里程碑

可交付物验证的接受标准