GB/T 42984.1-2023
基本信息
标准号： GB/T 42984.1-2023
中文名称：健康软件 第1部分：产品安全的通用要求
标准类别：国家标准(GB)
英文名称：Health software—Part 1:General requirements for product safety
标准状态：现行
发布日期：2023-09-07
实施日期：2024-10-01
出版语种：简体中文
下载格式：.pdf .zip
下载大小：4648383
标准分类号
标准ICS号：信息技术、办公机械设备>>信息技术应用>>35.240.80信息技术(IT)在保健技术中
中标分类号：医药、卫生、劳动保护>>医疗器械>>C30医疗器械综合
关联标准
采标情况：IEC 82304-1:2016,MOD
出版信息
出版社：中国标准出版社
页数：24页
标准价格：43.0
相关单位信息
起草人：陈兴文、刘重生、彭亮、李澍、谢鑫莹、王青松、陈蓓
起草单位：北京怡和嘉业医疗科技股份有限公司、上海市医疗器械检验研究院、国家药品监督管理局医疗器械技术审评中心、中国食品药品检定研究院、东软医疗系统股份有限公司
归口单位：全国医用电器标准化技术委员会(SAC/TC 10)
提出单位：国家药品监督管理局
发布部门：国家市场监督管理总局 国家标准化管理委员会
标准简介
本文件规定了健康软件产品安全的通用要求。
本文件适用于健康软件产品的安全和网络安全，主要关注对制造商的要求。健康软件产品设计运行于通用计算平台，预期无须特定硬件即可上市。
标准图片预览
标准内容
ICS 35.240.80
CCS C 30
中华人民共和国国家标准
GB/T42984.1—2023
健康软件
第 1部分：产品安全的通用要求Health softwarePart 1 :General requirements for product safety（IEC82304-1:2016,MOD）
2023-09-07发布
国家市场监督管理总局
国家标准化管理委员会
2024-10-01实施
1范围
应用领域
符合性
规范性引用文件
术语和定义
*健康软件产品要求
通用要求和初始风险评定
健康软件产品使用需求
健康软件产品使用需求的验证
更新健康软件产品的使用需求
系统需求
系统需求的验证
更新健康软件产品的系统需求
*健康软件
软件生存周期过程
*健康软件产品确认
确认计划
实施确认
确认报告
健康软件产品标识和随附文件
*标识
随附文件
健康软件产品的上市后活动·
软件维护
重新确认
健康软件产品的上市后沟通
8.5健康软件产品的停用和处理
附录A（资料性）本文件要求的理由说明参考文献
GB/T42984.1—2023
本文件按照GB/T1.1一2020《标准化工作导则起草。
GB/T42984.1—2023
第1部分：标准化文件的结构和起草规则》的规定本文件是GB/T42984《健康软件》的第1部分。GB/T42984已经发布了以下部分：第1部分：产品安全的通用要求。本文件修改采用IEC82304-1：2016《健康软件第1部分：产品安全的通用要求》。本文件与IEC82304-1：2016的技术差异及其原因如下：用规范性引用的YY/T0664—2020替换了IEC62304：2006和IEC62304：2006/AMD1：2015，两个文件之间的一致性程度为修改，以适应我国的技术条件。本文件做了下列编辑性改动：
用资料性引用的GB9706系列替换了IEC60601/IEC80601系列；一用资料性引用的GB4793（所有部分）替换了IEC61010系列；用资料性引用的GB16174（所有部分）替换了ISO14708系列；—用GB9706.1—2020替换了IEC60601-1:2005/AMD1:2012；用IECGuide63替换了IEC82304-1：2016术语“风险”的来源；一用ISO/IEC/IEEE12207：2017替换了IEC82304-1：2016中术语“网络安全”的来源并增加了注；
删除了4.2的注4
删除附录A中A.1的最后一段关于国际监管地区适用不同法规的描述请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。本文件由国家药品监督管理局提出本文件由全国医用电器标准化技术委员会（SAC/TC10）归口。本文件起草单位：北京怡和嘉业医疗科技股份有限公司、上海市医疗器械检验研究院、国家药品监督管理局医疗器械技术审评中心、中国食品药品检定研究院、东软医疗系统股份有限公司。本文件主要起草人：陈兴文、刘重生、彭亮、李澍、谢鑫莹、王青松、陈蓓。Ⅲ
GB/T42984.1—2023
健康软件是指使用可测量的健康参数或临床专业知识观察和/或演示的有助于个人健康的软件。该产品设计用于在通用计算平台上运行，并打算在没有专用硬件的情况下投放市场，由其制造商用于管理、维护或改善个人健康或提供护理。一些健康软件可能导致危险情况，因此，要求对所有健康软件进行风险管理。对于可能导致危险情况的健康软件，需要进行风险控制，以防止伤害或降低发生伤害的可能性。
健康软件与医疗器械的界限很难区分清楚。这些软件的开发者，通常不是传统的医疗器械制造商。对这些产品的开发过程和安全要求，宜有合适的标准进行“提前”限定。在各类型健康软件中，健康和保健应用程序ApP是一个快速增长的市场，目前已有数十万个应用程序，其中最受欢迎的应用程序每个都有数百万的下载量。其中一些应用受医疗设备法规的约束，但大多数不受此约束。这些应用通常通过应用商店直接推广给消费者，无须经过任何正式评估。这些应用通常收集敏感的个人信息，但却没有适当的隐私控制，提供关于生育能力、饮食或活动等主题的建议，也没有任何证据支持。人们普遍担心其中的风险。同时，健康应用已经被证明是有效的，可以提高生活质量，甚至延长寿命，但不一定会被大规模采用。许多健康组织都有评估、认可和采购符合当地规定要求的应用程序的项目。这些活动对于任何希望向健康和健康服务提供商推广或销售其产品的应用程序制造商都非常重要，因为提供商希望确保他们向患者推荐的应用程序是安全、可靠和有效的。然而，对于希望在多个市场提供产品的应用程序制造商而言，应对每个国家/地区、组织或地区不同的标准和评估制度的成本高昂
为了有效评估健康软件，包括健康应用程序的质量和可靠性，陆续制定ISO82304系列标准和技术规范，使其建立在世界各地许多地方和国家卫生组织对健康软件的指导方针和要求的基础上并加以整合，以确保软件安全、可靠和有效目前，GB/T42984《健康软件》共分为2个部分。第1部分：产品安全的通用要求。目的在于对健康软件产品的安全性和网络安全提出要求，为健康软件产品未来的监管和责任识别提供指南。一一第2部分：健康和保健应用程序质量与可靠性。目的在于定义有关健康应用程序质量和可靠性相关的问题及其支持证据，以确认（或确定)健康应用程序的质量和可靠性本文件中星号（*）标注的条款在附录A中有与该条款相关的解释和说明。IV
1范围
1.1目的
健康软件
第1部分：产品安全的通用要求
本文件规定了健康软件产品安全的通用要求GB/T42984.1—2023
本文件适用于健康软件产品的安全和网络安全，主要关注对制造商的要求。健康软件产品设计运行于通用计算平台，预期无须特定硬件即可上市。1.2应用领域
本文件涵盖整个生存周期，包括健康软件产品的设计、开发、安装、确认、维护和处理。在每个参考标准中，术语“医疗器械”或“医疗器械软件”在适当时由术语“健康软件”或“健康软件产品”代替。
如果使用术语“患者”，无论是在本文件中还是在参考标准中，它指的是使用健康软件对其健康有益的人员。
本文件不适用于预期作为健康用途而设计的特定硬件的一部分的健康软件。具体而言，本文件不适用于：
GB9706系列涵盖的医用电气设备或系统；a）
GB4793（所有部分）涵盖的体外诊断设备；b）
GB16174（所有部分）涵盖的植入式设备。c）
注：本文件也适用于旨在与移动计算平台结合使用的健康软件产品（例如医疗应用程序、健康应用程序）。1.3符合性
通过检查本文件要求的所有文档来确定是否符合本文件。制造商对符合性进行评估并记录。健康软件产品如需符合监管要求，则可能需要进行外部评估。如果本文件规范性地引用了以安全或网络安全为重点的其他标准的部分或条款，制造商可使用替代方法证明符合本文件的要求。如果这些替代方法的过程结果（包括可道溯性）明显等同并且剩余风险仍然可接受，则可使用这些替代方法。2规范性引用文件
下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。
YY/T0664一2020医疗器械软件软件生存周期过程（IEC62304：2015，MOD）3术语和定义
下列术语和定义适用于本文件。GB/T42984.1—2023
随附文件
accompanying document
随健康软件所带的文件，其内容包含了为责任方或用户提供的信息，特别是关于安全和网络安全的信息。
［来源：GB9706.1—2020，3.4，有修改］3.2
anomaly
与基于需求规范、设计文件和标准等预期，或人的认知与经验相偏离的任何情况。注：反常可能但不局限在健康软件或适用文档的评审、测试、分析、编译/编辑或使用过程中发现。［来源：IEEE1044：19933.1
伤害harm
对人健康的损伤或损害，或对财产或环境的损害。［来源：ISO/IECGuide63:2019,3.113.4
危险 hazard
可能导致伤害的潜在根源。
注：伤害的潜在来源包括违反安全和降低有效性。［来源：ISO/IECGuide63：2019，3.2，有修改3.5
hazardous situation
危险情况
人员、财产或环境暴露于一种或多种危险中的情形。［来源：ISO/IECGuide63：2019,3.33.6
healthsoftware
*健康软件
预期专门用于管理、维持或改善个人健康或提供护理的软件。注1：健康软件完全包括医疗器械独立软件（见A.1中的基本原理）。注2：本文件的范围指预期在通用计算平台上运行的健康软件的子集。3.7
health software product
健康软件产品
健康软件和随附文件的组合。
预期用途
预期目的
intendeduse
intended purpose
按照制造商提供的规范、说明书和信息，对产品、过程或服务的预期使用［来源：GB/T42062—2022.3.6]3.9
IT网络
IT-network
客information technologynetwork信息技术网络
由通信节点和传输链路组成的一个或多个系统，在两个或多个指定的通信节点之间提供物理连接或无线传输。
注：本文件中IT网络的范围是由责任方根据IT网络中的健康软件的位置和IT网络的确定用途来确定的。它包括不是设计上预期用于医疗保健设置的IT基础设施、家庭健康或普通计算组件或系统。见7.2.3.2，2
厂来源：IEC61907：2009，3.1.1，有修改制造商manufacturer
GB/T42984.1—2023
对健康软件产品设计、开发、包装、标记或在健康软件产品上市之前或使用之前对其进行编译的自然人或法人。不论这些活动是由其还是代表其的第三方执行。注1：标记的定义见GB/T42061一2022中3.8。注2：“开发人员”或“开发组织”是健康信息技术背景下常用的术语，而不是指制造商。3.11
剩余风险
residual risk
实施风险控制措施后还存在的风险［来源：ISO/IECGuide63：2019，3.93.12
responsibleorganization
责任方
对健康软件产品的使用和正确运行负有责任的实体示例：负有责任的实体可以是一家医院、某个医疗服务提供者或者某个远程医疗机构［来源：GB9706.1—2020，3.101，有修改］3.13
风险risk
伤害发生的概率和该伤害严重度的组合注：发生的概率包括暴露于危害处境以及避免或限制损害的可能性。「来源：ISO/IECGuide63：2019，3.10，有修改3.14
风险分析riskanalysis
系统性地使用可获得的信息以识别危险和估计风险。［来源:ISO/IECGuide63:2019,3.11]3.15
风险评定riskassessment
包括风险分析和风险评价的全过程。［来源：GB/T20002.4—2015，3.11，有修改］3.16
风险控制risk control
做出决策并实施措施，以便降低风险或将风险维持在规定水平的过程。［来源：ISO/IECGuide63:2019,3.12]3.17
风险评价
riskevaluation
将已估计的风险和给定的风险准则进行比较，以确定风险可接受性的过程。［来源：ISO/IECGuide63:2019,3.14]3.18
里riskmanagement
风险管理
用以风险分析、评价、控制和监视工作的管理方针、程序及其实践的系统运用［来源：ISO/IECGuide63:2019,3.15]3.19
安全 safety
免除不可接受的风险的状态。
GB/T42984.1—2023
［来源：ISO/IECGuide63：2019，3.16]3.20
security
网络安全
防止蓄意破坏或被迫失败；保密性、完整性、可得性和责任性四个属性，再加上第五个方面可用性的属性，所有这些组合以及它们的保证相关的问题注：在信息安全领域availability译为可用性，而在医疗器械领域usability译为可用性，为避免歧义，本文件将availability译为可得性
L来源：ISO/IEC/IEEE12207：2017,3.1.493.21
软件维护
softwaremaintenance
出于下列一个或多个原因，对发布后用于预期用途的健康软件产品进行修改：纠正型，如修复错误；
适应型，如适应新的硬件或软件平台；b）
完善型，如执行新需求；
预防型，如让产品易于维护。
注：参见ISO/IEC14764：2006。3.22
与健康软件产品交互的人员。
注：通常情况下，不将用户视为责任方，但消费类的健康软件产品除外。例如：个人健康应用或非专业人员使用的产品。
确认validation
通过提供客观证据对特定的预期用途或应用要求已得到满足的认定。注1：确认所需的客观证据是试验结果或其他形式的确定结果，如变换方法进行计算或文件评审。注2：“已确认”用于表明相应的状态，注3：确认的使用条件可以是真实的，也可以是模拟的，［来源：ISO9000:2015,3.8.13]3.24
verification
通过提供客观证据，对规定要求已得到满足的认定注1：验证所需的客观证据可以是检验结果或其他形式的确定结果，如变换方法进行计算或文件评审。注2：为验证所进行的活动有时被称为鉴定过程注3：“已验证”一词用于表明相应的状态［来源：ISO/IECGuide63:2019,3.19]4*健康软件产品要求
通用要求和初始风险评定
制造商应确定并记录：
健康软件产品的预期用途，包括预期的用户概况和预期的操作环境：a）
健康软件产品的安全和/或网络安全相关的特征，危险的识别和相关风险的估计。如适用，包b）
括可以配置和/或支持与其他产品接口的健康软件产品的情况：对不可接受的预估风险采取风险控制措施的必要性4
GB/T42984.1—2023
注1：4.1并未要求风险管理有如GB/T42062一2022所规范的那样正式与完备，然而，执行该流程的初始步骤被认为是良好的实践
注2：风险控制措施是硬件、独立软件系统，医疗护理流程或其他方式之注3：有关网络安全漏洞的信息来源包括官方的公开报告，以及供应商的发布信息，例如操作系统和第三方软件供应商的发布信息。
4.2健康软件产品使用需求
制造商应确定并记录以下内容。a）针对预期用途的需求
b）接口需求，包括适用的用户界面需求。注1：与作为健康软件产品系统需求的一部分用户界面规范相比，用户界面需求不描述技术（实现）需求，它们描述了技术需求的目的。
示例：在急诊室中，显示信息可在3m的距离内正常读取，注2：IEC62366-1:2015提供了建立用户界面需求的过程。对使用共同硬件资源的其他软件的非预期影响的抵抗能力或敏感性的需求。c）
涉及授权使用、个人身份验证、健康数据完整性和真实性以及防止恶意意图等领域的隐私和网d）wwW.bzxz.Net
络安全需求
注3：有关网络安全方面的更多信息见7.2.3.1和IEC/TR80001-2-2（网络安全功能列表）。e）
随附文件的需求，如使用说明（见7.2.2）。f）支持需求：
对以前版本的更新，包括保持数据完整性和与以前版本的兼容性；1）
更新后返回以前的版本；
及时的网络安全补丁的安装和更新；3）
确保安装完整性的软件分发机制4）
数据的停用、永久删除、传输和/或保留。g）来自适用法规的需求，包括受保护信息的规则。4.3健康软件产品使用需求的验证制造商应验证健康软件产品的使用需求：a）使用需求被定义为系统需求的输入并形成文档：b）使制造商能满足规定的使用需求应记录验证的结果。
4.4更新健康软件产品的使用需求适当时，制造商应确保健康软件产品使用需求的更新。例如，作为对健康软件产品使用需求验证（见4.3)或确认的结果。
4.5系统需求
制造商应制定并记录健康软件产品的系统需求。这些需求应包括预期用途的功能，并在适用时包括：
互操作性；
本地化和语言支持；
基于4.1的初始风险评定，在系统层面对健康软件产品实施的风险控制措施；c）
用户接口规范；
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。
CCS C 30
中华人民共和国国家标准
GB/T42984.1—2023
健康软件
第 1部分：产品安全的通用要求Health softwarePart 1 :General requirements for product safety（IEC82304-1:2016,MOD）
2023-09-07发布
国家市场监督管理总局
国家标准化管理委员会
2024-10-01实施
1范围
应用领域
符合性
规范性引用文件
术语和定义
*健康软件产品要求
通用要求和初始风险评定
健康软件产品使用需求
健康软件产品使用需求的验证
更新健康软件产品的使用需求
系统需求
系统需求的验证
更新健康软件产品的系统需求
*健康软件
软件生存周期过程
*健康软件产品确认
确认计划
实施确认
确认报告
健康软件产品标识和随附文件
*标识
随附文件
健康软件产品的上市后活动·
软件维护
重新确认
健康软件产品的上市后沟通
8.5健康软件产品的停用和处理
附录A（资料性）本文件要求的理由说明参考文献
GB/T42984.1—2023
本文件按照GB/T1.1一2020《标准化工作导则起草。
GB/T42984.1—2023
第1部分：标准化文件的结构和起草规则》的规定本文件是GB/T42984《健康软件》的第1部分。GB/T42984已经发布了以下部分：第1部分：产品安全的通用要求。本文件修改采用IEC82304-1：2016《健康软件第1部分：产品安全的通用要求》。本文件与IEC82304-1：2016的技术差异及其原因如下：用规范性引用的YY/T0664—2020替换了IEC62304：2006和IEC62304：2006/AMD1：2015，两个文件之间的一致性程度为修改，以适应我国的技术条件。本文件做了下列编辑性改动：
用资料性引用的GB9706系列替换了IEC60601/IEC80601系列；一用资料性引用的GB4793（所有部分）替换了IEC61010系列；用资料性引用的GB16174（所有部分）替换了ISO14708系列；—用GB9706.1—2020替换了IEC60601-1:2005/AMD1:2012；用IECGuide63替换了IEC82304-1：2016术语“风险”的来源；一用ISO/IEC/IEEE12207：2017替换了IEC82304-1：2016中术语“网络安全”的来源并增加了注；
删除了4.2的注4
删除附录A中A.1的最后一段关于国际监管地区适用不同法规的描述请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。本文件由国家药品监督管理局提出本文件由全国医用电器标准化技术委员会（SAC/TC10）归口。本文件起草单位：北京怡和嘉业医疗科技股份有限公司、上海市医疗器械检验研究院、国家药品监督管理局医疗器械技术审评中心、中国食品药品检定研究院、东软医疗系统股份有限公司。本文件主要起草人：陈兴文、刘重生、彭亮、李澍、谢鑫莹、王青松、陈蓓。Ⅲ
GB/T42984.1—2023
健康软件是指使用可测量的健康参数或临床专业知识观察和/或演示的有助于个人健康的软件。该产品设计用于在通用计算平台上运行，并打算在没有专用硬件的情况下投放市场，由其制造商用于管理、维护或改善个人健康或提供护理。一些健康软件可能导致危险情况，因此，要求对所有健康软件进行风险管理。对于可能导致危险情况的健康软件，需要进行风险控制，以防止伤害或降低发生伤害的可能性。
健康软件与医疗器械的界限很难区分清楚。这些软件的开发者，通常不是传统的医疗器械制造商。对这些产品的开发过程和安全要求，宜有合适的标准进行“提前”限定。在各类型健康软件中，健康和保健应用程序ApP是一个快速增长的市场，目前已有数十万个应用程序，其中最受欢迎的应用程序每个都有数百万的下载量。其中一些应用受医疗设备法规的约束，但大多数不受此约束。这些应用通常通过应用商店直接推广给消费者，无须经过任何正式评估。这些应用通常收集敏感的个人信息，但却没有适当的隐私控制，提供关于生育能力、饮食或活动等主题的建议，也没有任何证据支持。人们普遍担心其中的风险。同时，健康应用已经被证明是有效的，可以提高生活质量，甚至延长寿命，但不一定会被大规模采用。许多健康组织都有评估、认可和采购符合当地规定要求的应用程序的项目。这些活动对于任何希望向健康和健康服务提供商推广或销售其产品的应用程序制造商都非常重要，因为提供商希望确保他们向患者推荐的应用程序是安全、可靠和有效的。然而，对于希望在多个市场提供产品的应用程序制造商而言，应对每个国家/地区、组织或地区不同的标准和评估制度的成本高昂
为了有效评估健康软件，包括健康应用程序的质量和可靠性，陆续制定ISO82304系列标准和技术规范，使其建立在世界各地许多地方和国家卫生组织对健康软件的指导方针和要求的基础上并加以整合，以确保软件安全、可靠和有效目前，GB/T42984《健康软件》共分为2个部分。第1部分：产品安全的通用要求。目的在于对健康软件产品的安全性和网络安全提出要求，为健康软件产品未来的监管和责任识别提供指南。一一第2部分：健康和保健应用程序质量与可靠性。目的在于定义有关健康应用程序质量和可靠性相关的问题及其支持证据，以确认（或确定)健康应用程序的质量和可靠性本文件中星号（*）标注的条款在附录A中有与该条款相关的解释和说明。IV
1范围
1.1目的
健康软件
第1部分：产品安全的通用要求
本文件规定了健康软件产品安全的通用要求GB/T42984.1—2023
本文件适用于健康软件产品的安全和网络安全，主要关注对制造商的要求。健康软件产品设计运行于通用计算平台，预期无须特定硬件即可上市。1.2应用领域
本文件涵盖整个生存周期，包括健康软件产品的设计、开发、安装、确认、维护和处理。在每个参考标准中，术语“医疗器械”或“医疗器械软件”在适当时由术语“健康软件”或“健康软件产品”代替。
如果使用术语“患者”，无论是在本文件中还是在参考标准中，它指的是使用健康软件对其健康有益的人员。
本文件不适用于预期作为健康用途而设计的特定硬件的一部分的健康软件。具体而言，本文件不适用于：
GB9706系列涵盖的医用电气设备或系统；a）
GB4793（所有部分）涵盖的体外诊断设备；b）
GB16174（所有部分）涵盖的植入式设备。c）
注：本文件也适用于旨在与移动计算平台结合使用的健康软件产品（例如医疗应用程序、健康应用程序）。1.3符合性
通过检查本文件要求的所有文档来确定是否符合本文件。制造商对符合性进行评估并记录。健康软件产品如需符合监管要求，则可能需要进行外部评估。如果本文件规范性地引用了以安全或网络安全为重点的其他标准的部分或条款，制造商可使用替代方法证明符合本文件的要求。如果这些替代方法的过程结果（包括可道溯性）明显等同并且剩余风险仍然可接受，则可使用这些替代方法。2规范性引用文件
下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。
YY/T0664一2020医疗器械软件软件生存周期过程（IEC62304：2015，MOD）3术语和定义
下列术语和定义适用于本文件。GB/T42984.1—2023
随附文件
accompanying document
随健康软件所带的文件，其内容包含了为责任方或用户提供的信息，特别是关于安全和网络安全的信息。
［来源：GB9706.1—2020，3.4，有修改］3.2
anomaly
与基于需求规范、设计文件和标准等预期，或人的认知与经验相偏离的任何情况。注：反常可能但不局限在健康软件或适用文档的评审、测试、分析、编译/编辑或使用过程中发现。［来源：IEEE1044：19933.1
伤害harm
对人健康的损伤或损害，或对财产或环境的损害。［来源：ISO/IECGuide63:2019,3.113.4
危险 hazard
可能导致伤害的潜在根源。
注：伤害的潜在来源包括违反安全和降低有效性。［来源：ISO/IECGuide63：2019，3.2，有修改3.5
hazardous situation
危险情况
人员、财产或环境暴露于一种或多种危险中的情形。［来源：ISO/IECGuide63：2019,3.33.6
healthsoftware
*健康软件
预期专门用于管理、维持或改善个人健康或提供护理的软件。注1：健康软件完全包括医疗器械独立软件（见A.1中的基本原理）。注2：本文件的范围指预期在通用计算平台上运行的健康软件的子集。3.7
health software product
健康软件产品
健康软件和随附文件的组合。
预期用途
预期目的
intendeduse
intended purpose
按照制造商提供的规范、说明书和信息，对产品、过程或服务的预期使用［来源：GB/T42062—2022.3.6]3.9
IT网络
IT-network
客information technologynetwork信息技术网络
由通信节点和传输链路组成的一个或多个系统，在两个或多个指定的通信节点之间提供物理连接或无线传输。
注：本文件中IT网络的范围是由责任方根据IT网络中的健康软件的位置和IT网络的确定用途来确定的。它包括不是设计上预期用于医疗保健设置的IT基础设施、家庭健康或普通计算组件或系统。见7.2.3.2，2
厂来源：IEC61907：2009，3.1.1，有修改制造商manufacturer
GB/T42984.1—2023
对健康软件产品设计、开发、包装、标记或在健康软件产品上市之前或使用之前对其进行编译的自然人或法人。不论这些活动是由其还是代表其的第三方执行。注1：标记的定义见GB/T42061一2022中3.8。注2：“开发人员”或“开发组织”是健康信息技术背景下常用的术语，而不是指制造商。3.11
剩余风险
residual risk
实施风险控制措施后还存在的风险［来源：ISO/IECGuide63：2019，3.93.12
responsibleorganization
责任方
对健康软件产品的使用和正确运行负有责任的实体示例：负有责任的实体可以是一家医院、某个医疗服务提供者或者某个远程医疗机构［来源：GB9706.1—2020，3.101，有修改］3.13
风险risk
伤害发生的概率和该伤害严重度的组合注：发生的概率包括暴露于危害处境以及避免或限制损害的可能性。「来源：ISO/IECGuide63：2019，3.10，有修改3.14
风险分析riskanalysis
系统性地使用可获得的信息以识别危险和估计风险。［来源:ISO/IECGuide63:2019,3.11]3.15
风险评定riskassessment
包括风险分析和风险评价的全过程。［来源：GB/T20002.4—2015，3.11，有修改］3.16
风险控制risk control
做出决策并实施措施，以便降低风险或将风险维持在规定水平的过程。［来源：ISO/IECGuide63:2019,3.12]3.17
风险评价
riskevaluation
将已估计的风险和给定的风险准则进行比较，以确定风险可接受性的过程。［来源：ISO/IECGuide63:2019,3.14]3.18
里riskmanagement
风险管理
用以风险分析、评价、控制和监视工作的管理方针、程序及其实践的系统运用［来源：ISO/IECGuide63:2019,3.15]3.19
安全 safety
免除不可接受的风险的状态。
GB/T42984.1—2023
［来源：ISO/IECGuide63：2019，3.16]3.20
security
网络安全
防止蓄意破坏或被迫失败；保密性、完整性、可得性和责任性四个属性，再加上第五个方面可用性的属性，所有这些组合以及它们的保证相关的问题注：在信息安全领域availability译为可用性，而在医疗器械领域usability译为可用性，为避免歧义，本文件将availability译为可得性
L来源：ISO/IEC/IEEE12207：2017,3.1.493.21
软件维护
softwaremaintenance
出于下列一个或多个原因，对发布后用于预期用途的健康软件产品进行修改：纠正型，如修复错误；
适应型，如适应新的硬件或软件平台；b）
完善型，如执行新需求；
预防型，如让产品易于维护。
注：参见ISO/IEC14764：2006。3.22
与健康软件产品交互的人员。
注：通常情况下，不将用户视为责任方，但消费类的健康软件产品除外。例如：个人健康应用或非专业人员使用的产品。
确认validation
通过提供客观证据对特定的预期用途或应用要求已得到满足的认定。注1：确认所需的客观证据是试验结果或其他形式的确定结果，如变换方法进行计算或文件评审。注2：“已确认”用于表明相应的状态，注3：确认的使用条件可以是真实的，也可以是模拟的，［来源：ISO9000:2015,3.8.13]3.24
verification
通过提供客观证据，对规定要求已得到满足的认定注1：验证所需的客观证据可以是检验结果或其他形式的确定结果，如变换方法进行计算或文件评审。注2：为验证所进行的活动有时被称为鉴定过程注3：“已验证”一词用于表明相应的状态［来源：ISO/IECGuide63:2019,3.19]4*健康软件产品要求
通用要求和初始风险评定
制造商应确定并记录：
健康软件产品的预期用途，包括预期的用户概况和预期的操作环境：a）
健康软件产品的安全和/或网络安全相关的特征，危险的识别和相关风险的估计。如适用，包b）
括可以配置和/或支持与其他产品接口的健康软件产品的情况：对不可接受的预估风险采取风险控制措施的必要性4
GB/T42984.1—2023
注1：4.1并未要求风险管理有如GB/T42062一2022所规范的那样正式与完备，然而，执行该流程的初始步骤被认为是良好的实践
注2：风险控制措施是硬件、独立软件系统，医疗护理流程或其他方式之注3：有关网络安全漏洞的信息来源包括官方的公开报告，以及供应商的发布信息，例如操作系统和第三方软件供应商的发布信息。
4.2健康软件产品使用需求
制造商应确定并记录以下内容。a）针对预期用途的需求
b）接口需求，包括适用的用户界面需求。注1：与作为健康软件产品系统需求的一部分用户界面规范相比，用户界面需求不描述技术（实现）需求，它们描述了技术需求的目的。
示例：在急诊室中，显示信息可在3m的距离内正常读取，注2：IEC62366-1:2015提供了建立用户界面需求的过程。对使用共同硬件资源的其他软件的非预期影响的抵抗能力或敏感性的需求。c）
涉及授权使用、个人身份验证、健康数据完整性和真实性以及防止恶意意图等领域的隐私和网d）wwW.bzxz.Net
络安全需求
注3：有关网络安全方面的更多信息见7.2.3.1和IEC/TR80001-2-2（网络安全功能列表）。e）
随附文件的需求，如使用说明（见7.2.2）。f）支持需求：
对以前版本的更新，包括保持数据完整性和与以前版本的兼容性；1）
更新后返回以前的版本；
及时的网络安全补丁的安装和更新；3）
确保安装完整性的软件分发机制4）
数据的停用、永久删除、传输和/或保留。g）来自适用法规的需求，包括受保护信息的规则。4.3健康软件产品使用需求的验证制造商应验证健康软件产品的使用需求：a）使用需求被定义为系统需求的输入并形成文档：b）使制造商能满足规定的使用需求应记录验证的结果。
4.4更新健康软件产品的使用需求适当时，制造商应确保健康软件产品使用需求的更新。例如，作为对健康软件产品使用需求验证（见4.3)或确认的结果。
4.5系统需求
制造商应制定并记录健康软件产品的系统需求。这些需求应包括预期用途的功能，并在适用时包括：
互操作性；
本地化和语言支持；
基于4.1的初始风险评定，在系统层面对健康软件产品实施的风险控制措施；c）
用户接口规范；
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。