YY/T 1406-2026Medical device software - Guidance on the application of GB/T 42062 to medical device software (English PDF)

Foreword

This document complies with the provisions of GB/T 1.1-2020 "Standardization Work Guidelines Part

1.Structure and Drafting Rules of Standardization Documents". Drafting. This document replaces YY/T 1406.1-2016 "Medical Device Software Part 1: YY/T 0316 Applications to Medical Device Software". Compared with YY/T 1406.1-2016, the main technical changes in "South" are as follows, apart from structural adjustments and editorial modifications. -- Replace YY/T 0664-2008 and its contents with YY/T 0664-2020 and its contents; -- Replace YY/T 0316-2016 and its contents with GB/T 42062-2022 and its contents; --Change "General Provisions" to "Scope" and "Normative References" (see Chapters 1 and 2, Chapter 1 of the.2016 edition); --The scope of application has been changed (see Chapter 1,

1.1 of the.2016 edition). --Change the term "security-related software" to "security-related software" (see 3.3,

2.3 in the.2016 edition); --Change "General Requirements for Risk Management" to "General Requirements for Risk Management Systems" (see Chapter 4, Chapter 3 of the.2016 edition); --Change "characteristics of a system that includes software security" to "features of a system that includes software security" (see 4.1.4,.2016). Version 3.1.4). --Change "personnel qualifications" to "personnel competence" (see 4.3,

3.3 in the.2016 version); --Change "Programming experience and intention" to "Programming experience and awareness" (see 4.3.3,.2016 version 3.3.3); --Change "Risk-related topics of software development plan (according to YY/T 0664-2008)" to "Software development plan (according to YY/T 0664-2008)" (T 0664) Risk-related specific topics (see 4.4.3,

3.4.3 in the.2016 edition); -- Change "Identification of Intended Use and Safety-Related Characteristics of Medical Devices" to "Intended Use and Reasonably Foreseeable Misuse" (see...) 5.2 (

4.2 in the.2016 edition), changing "General Provisions" to "Intended Use" (see 5.2.1,

4.2.1 in the.2016 edition), and adding a clause. The title is "Reasonably Foreseeable Misuse" (see 5.2.2); --Added "Identification of security-related characteristics" (see 5.3); --Change the heading "Hazard (Source) Identification" to "Identification of Hazards and Hazardous Situations" (see 5.4,

4.3 in the.2016 edition); --Change "Estimate the risk of each hazardous situation" to "Risk estimate" (see 5.4,

4.3 in the.2016 edition); --Added content on risk estimation based on the probability and severity of injury (see 5.5.3); --The "Risk Reduction" clause has been removed (see

6.1 in the.2016 version). --Change "Achieve inherent safety through design methods" to "Achieve inherent safety through design and manufacturing," and add relevant content (see...). 7.1.1.2 (

6.2.1.2 in the.2016 version). --Change "Security Information" to "Security Information and User Training" and add relevant content (see 7.1.1.4,.2016 version). 6.2.1.4). --Change "Risk control measures and software structural design" to "Risk control measures and software architecture design" (see...) 7.1.2.2 (

6.2.2.2 in the.2016 version). --Change "Details of protective measures" to "Details of protective measures" (see 7.1.2.3,

6.2.2.3 in the.2016 version); --Change "Risk Control Measures for Software Anomalies" to "Risk Control Measures for Software Abnormalities" (see 7.1.2.5,.2016 version). 6.2.2.5); --Change "Risk/Benefit Analysis" to "Benefit-Risk Analysis" (see 7.4,

1 Scope

YY/T 1406 is the bridge between risk management and software. It gives guidance on applying the requirements of GB/T 42062-2022, the Chinese adoption of the ISO 14971 risk management standard, to medical device software, covering both standalone software and software that is a component of a device, as those are defined in YY/T 0664-2020. It is explicit about what it is not: it adds nothing to GB/T 42062 and changes none of its requirements, nor those of YY/T 0664. Risk management written for hardware does not map cleanly onto software failure, which is the gap this document exists to close. At 29,500 words it is one of the longest in the series. For any manufacturer of software as a medical device or of a device with embedded software, this is how a Chinese reviewer expects the risk file to be reasoned.

This document provides guidance on applying the requirements contained in GB/T 42062-2022 to the medical device software referred to in YY/T 0664-2020. This document provides guidelines for software components (standalone software and software components). It does not add to or change GB/T 42062-2022 or YY/T 0664-2020. Require. This document applies to medical device software as defined in YY/T 0664-2020.This document also applies to applications requiring security risk management. All software in the healthcare environment, regardless of whether it is classified as a medical device. This document does not apply to. --Production or quality management system software; --Software development tools.

2 Normative references

The contents of the following documents, through normative references within the text, constitute essential provisions of this document. Dated citations are listed below. For references to documents, only the version corresponding to that date applies to this document; for undated references, the latest version (including all amendments) applies. document.

GB/T 42062-2022 Application of Medical Device Risk Management to Medical Devices

YY/T 0664-2020 Medical Device Software Life Cycle Process

3 Terms and Definitions

The terms and definitions defined in GB/T 42062-2022 and YY/T 0664-2020, as well as the following terms and definitions, apply to this document.

3.1 diversity A form of redundancy in which redundant elements use different (diverse) components, technologies, or methods to reduce the common causes that lead to all the desired results. The probability of all elements failing simultaneously.

3.2 Redundancy Provide multiple components or mechanisms to accomplish the same function, so that the failure of one or more components or mechanisms will not prevent the function from being executed.

3.3 Safety-related software Software that can lead to dangerous situations, or software used to implement risk control measures.