YY/T 0664-2020 Medical device software - Software life cycle process
1 Scope
1.1 * Purpose
This standard defines the life cycle requirements for medical device software. The set of processes, activities, and tasks described in this standard establishes a common framework for medical device software life cycle processes.
1.2 * Field of application
This standard applies to the development and maintenance of medical device software when software is itself a medical device or when software is an embedded or integral part of the final medical device.
Note 1: This standard can be used in the development and maintenance of software that is itself a medical device. However, additional development activities are needed at the system level before this type of software can be placed into service. These system activities are not covered by this standard, but can be found in IEC 82304-1 [11].
This standard describes processes that are intended to be applied to software which executes on a processor or which is executed by other software (for example an interpreter) which executes on a processor.
This standard applies regardless of the persistent storage device(s) used to store the software (for example: hard disk, optical disk, permanent or flash memory).
This standard applies regardless of the method of delivery of the software (for example: transmission by network or email, optical disk, flash memory or EEPROM). The method of software delivery itself is not considered medical device software.
This standard does not cover validation and final release of the medical device, even when the medical device consists entirely of software.
Note 2: If a medical device incorporates embedded software intended to be executed on a processor, the requirements of this standard apply to the software, including the requirements concerning software of unknown provenance (see 8.1.2).
Note 3: Validation and other development activities are needed at the system level before the software and medical device can be placed into service. These system activities are not covered by this standard, but can be found in related product standards (e.g., IEC 60601-1 [6], IEC 82304-1 [11], etc.).
1.3 Relationship to other standards
This medical device software life cycle standard is to be used together with other appropriate standards when developing a medical device. Annex C shows the relationship between this standard and other relevant standards.
1.4 Compliance
Compliance with this standard is defined as implementing all of the processes, activities, and tasks identified in this standard in accordance with the software safety class.
Note 1: The software safety classes assigned to each requirement are identified in the normative text following the requirement.
Compliance is determined by inspection of all documentation required by this standard including the risk management file, and assessment of the processes, activities and tasks required for the software safety class.
Note 2: This assessment could be carried out by internal or external audit.
Note 3: Although the specified processes, activities, and tasks are performed, flexibility exists in the methods of implementing these processes and performing these activities and tasks.
Note 4: Where any requirements contain “as appropriate” and were not performed, documentation for the justification is necessary for this assessment.
Note 5: The term “conformance” is used in ISO/IEC 12207 where the term “compliance” is used in this standard.
Note 6: For compliance of legacy software, see 4.4.
2 * Normative references
The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition (including having amendments) applies to this document.
YY/T 0316 Medical devices - Application of risk management to medical devices (YY/T 0316-2016, ISO 14971:2007, corrected version, IDT)
3 * Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
activity
a set of one or more interrelated or interacting tasks
3.2
anomaly
any condition that deviates from the expected based on requirements specifications, design documents, standards, etc. or from someone’s perceptions or experiences. An anomaly may be found during, but not limited to, the review, test, analysis, compilation, or use of medical device software or applicable documentation
Note: It is revised from IEEE 1044:1993, definition 3.1.
3.3
architecture
organizational structure of a system or component
[IEEE 610.12:1990]
3.4
change request
documented specification of a change to be made to a medical device software
3.5
configuration item
entity that can be uniquely identified at a given reference point
Note: It is revised from ISO/IEC 12207:2008, definition 4.7.
3.6
deliverable
required result or output (includes documentation) of an activity or task
3.7
evaluation
a systematic determination of the extent to which an entity meets its specified criteria
[ISO/IEC 12207:2008, definition 4.12]
3.8
harm
physical injury, damage, or both to the health of people or damage to property or the environment
[YY/T 0316-2016, definition 2.2]
3.9
hazard
potential source of harm
[YY/T 0316-2016, definition 2.3]
3.10
manufacturer
natural or legal person with responsibility for design and/or manufacture of a medical device with the intention of making the medical device available for use under his name; regardless of whether these operations are carried out by that person or by a third party on that person’s behalf
Note 1: The "natural or legal person" is ultimately responsible for ensuring compliance with all applicable regulatory requirements of the country or jurisdiction in which the medical device is expected to be available or marketed, unless the regulatory authority (RA) of that jurisdiction expressly imposes that responsibility on another natural or legal person.
Note 2: The manufacturer’s responsibilities are described in other GHTF guidance documents. These responsibilities include meeting both pre-market requirements and post-market requirements, such as adverse event reporting and notification of corrective actions.
Note 3: In the above definition, “Design and/or manufacture” may include the specification development, production, fabrication, assembly, processing, packaging, repackaging, labelling, relabelling, sterilization, installation, or remanufacturing of the medical device; or putting a collection of devices, and possibly other products, together for a medical purpose.
Foreword i
Introduction v
1 Scope
1.1 * Purpose
1.2 * Field of application
1.3 Relationship to other standards
1.4 Compliance
2 * Normative references
3 * Terms and definitions
4 * General requirements
4.1 * Quality management system
4.2 * Risk management
4.3 * Software safety classification
4.4 * Legacy software
5 Software development process
5.1 * Software development planning
5.2 * Software requirements analysis
5.3 * Software architectural design
5.4 * Software detailed design
5.5 * Software unit implementation
5.6 * Software integration and integration testing
5.7 * Software system testing
5.8 * Software release for system-level applications
6 Software maintenance process
6.1 * Establish software maintenance plan
6.2 * Problem and modification analysis
6.3 * Modification implementation
7 * Software risk management process
7.1 * Analysis of software contributing to hazardous situations
7.2 Risk control measures
7.3 Verification of risk control measures
7.4 Risk management of software changes
8 * Software configuration management process
8.1 * Configuration identification
8.2 * Change control
8.3 * Configuration status accounting
9 * Software problem resolution process
9.1 Prepare problem reports
9.2 Investigate the problem
9.3 Advise relevant parties
9.4 Use change control process
9.5 Maintain records
9.6 Analyse problems for trends
9.7 Verify software problem resolution
9.8 Test documentation contents
Annex A (Informative) Rationale for the requirements of this standard
Annex B (Informative) Guidance on the provisions of this standard
Annex C (Informative) Relationship to other standards
Annex D (Informative) Implementation
Bibliography
Figure 1 Overview of software development processes and activities vi
Figure 2 Overview of software maintenance processes and activities vi
Figure 3 Assigning software safety classification
Figure B.1 Pictorial representation of the relationship of hazard, sequence of events, hazardous situation, and harm – from YY/T 0316-2016 Annex E
Figure B.2 Example of partitioning of software items
Figure B.3 Relationship among off-the-shelf software, SOUP and legacy software from the regulatory perspective
Figure C.1 Relationship of key medical device standards to this standard
Figure C.2 Software as part of the V-model
Figure C.3 Application of YY/T 0664 with IEC 61010-1
Table A.1 Summary of requirements by software safety class
Table B.1 Development (model) strategies as defined in ISO/IEC 12207
Table C.1 Relationship to YY/T 0287-2017
Table C.2 Relationship to YY/T 0316-2016
Table C.3 Relationship to IEC 60601-1
Figure C.3 Application of YY/T 0664 with IEC 61010-1
Table C.4 Relationship to ISO/IEC 12207:2008
Table D.1 Checklist for small manufacturers without a certified QMS
Standard
YY/T 0664-2020 Medical device software—Software life cycle processes (English Version)
Standard No.
YY/T 0664-2020
Status
valid
Language
English
File Format
PDF
Word Count
32500 words
Price(USD)
975.0
Implemented on
2021-9-1
Delivery
via email in 1~10 business day
Detail of YY/T 0664-2020
Standard No.
YY/T 0664-2020
English Name
Medical device software—Software life cycle processes
YY/T 0664-2020 Medical device software - Software life cycle process
1 Scope
1.1 * Purpose
This standard defines the life cycle requirements for medical device software. The set of processes, activities, and tasks described in this standard establishes a common framework for medical device software life cycle processes.
1.2 * Field of application
This standard applies to the development and maintenance of medical device software when software is itself a medical device or when software is an embedded or integral part of the final medical device.
Note 1: This standard can be used in the development and maintenance of software that is itself a medical device. However, additional development activities are needed at the system level before this type of software can be placed into service. These system activities are not covered by this standard, but can be found in IEC 82304-1 [11].
This standard describes processes that are intended to be applied to software which executes on a processor or which is executed by other software (for example an interpreter) which executes on a processor.
This standard applies regardless of the persistent storage device(s) used to store the software (for example: hard disk, optical disk, permanent or flash memory).
This standard applies regardless of the method of delivery of the software (for example: transmission by network or email, optical disk, flash memory or EEPROM). The method of software delivery itself is not considered medical device software.
This standard does not cover validation and final release of the medical device, even when the medical device consists entirely of software.
Note 2: If a medical device incorporates embedded software intended to be executed on a processor, the requirements of this standard apply to the software, including the requirements concerning software of unknown provenance (see 8.1.2).
Note 3: Validation and other development activities are needed at the system level before the software and medical device can be placed into service. These system activities are not covered by this standard, but can be found in related product standards (e.g., IEC 60601-1 [6], IEC 82304-1 [11], etc.).
1.3 Relationship to other standards
This medical device software life cycle standard is to be used together with other appropriate standards when developing a medical device. Annex C shows the relationship between this standard and other relevant standards.
1.4 Compliance
Compliance with this standard is defined as implementing all of the processes, activities, and tasks identified in this standard in accordance with the software safety class.
Note 1: The software safety classes assigned to each requirement are identified in the normative text following the requirement.
Compliance is determined by inspection of all documentation required by this standard including the risk management file, and assessment of the processes, activities and tasks required for the software safety class.
Note 2: This assessment could be carried out by internal or external audit.
Note 3: Although the specified processes, activities, and tasks are performed, flexibility exists in the methods of implementing these processes and performing these activities and tasks.
Note 4: Where any requirements contain “as appropriate” and were not performed, documentation for the justification is necessary for this assessment.
Note 5: The term “conformance” is used in ISO/IEC 12207 where the term “compliance” is used in this standard.
Note 6: For compliance of legacy software, see 4.4.
2 * Normative references
The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition (including having amendments) applies to this document.
YY/T 0316 Medical devices - Application of risk management to medical devices (YY/T 0316-2016, ISO 14971:2007, corrected version, IDT)
3 * Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
activity
a set of one or more interrelated or interacting tasks
3.2
anomaly
any condition that deviates from the expected based on requirements specifications, design documents, standards, etc. or from someone’s perceptions or experiences. An anomaly may be found during, but not limited to, the review, test, analysis, compilation, or use of medical device software or applicable documentation
Note: It is revised from IEEE 1044:1993, definition 3.1.
3.3
architecture
organizational structure of a system or component
[IEEE 610.12:1990]
3.4
change request
documented specification of a change to be made to a medical device software
3.5
configuration item
entity that can be uniquely identified at a given reference point
Note: It is revised from ISO/IEC 12207:2008, definition 4.7.
3.6
deliverable
required result or output (includes documentation) of an activity or task
3.7
evaluation
a systematic determination of the extent to which an entity meets its specified criteria
[ISO/IEC 12207:2008, definition 4.12]
3.8
harm
physical injury, damage, or both to the health of people or damage to property or the environment
[YY/T 0316-2016, definition 2.2]
3.9
hazard
potential source of harm
[YY/T 0316-2016, definition 2.3]
3.10
manufacturer
natural or legal person with responsibility for design and/or manufacture of a medical device with the intention of making the medical device available for use under his name; regardless of whether these operations are carried out by that person or by a third party on that person’s behalf
Note 1: The "natural or legal person" is ultimately responsible for ensuring compliance with all applicable regulatory requirements of the country or jurisdiction in which the medical device is expected to be available or marketed, unless the regulatory authority (RA) of that jurisdiction expressly imposes that responsibility on another natural or legal person.
Note 2: The manufacturer’s responsibilities are described in other GHTF guidance documents. These responsibilities include meeting both pre-market requirements and post-market requirements, such as adverse event reporting and notification of corrective actions.
Note 3: In the above definition, “Design and/or manufacture” may include the specification development, production, fabrication, assembly, processing, packaging, repackaging, labelling, relabelling, sterilization, installation, or remanufacturing of the medical device; or putting a collection of devices, and possibly other products, together for a medical purpose.
Contents of YY/T 0664-2020
Foreword i
Introduction v
1 Scope
1.1 * Purpose
1.2 * Field of application
1.3 Relationship to other standards
1.4 Compliance
2 * Normative references
3 * Terms and definitions
4 * General requirements
4.1 * Quality management system
4.2 * Risk management
4.3 * Software safety classification
4.4 * Legacy software
5 Software development process
5.1 * Software development planning
5.2 * Software requirements analysis
5.3 * Software architectural design
5.4 * Software detailed design
5.5 * Software unit implementation
5.6 * Software integration and integration testing
5.7 * Software system testing
5.8 * Software release for system-level applications
6 Software maintenance process
6.1 * Establish software maintenance plan
6.2 * Problem and modification analysis
6.3 * Modification implementation
7 * Software risk management process
7.1 * Analysis of software contributing to hazardous situations
7.2 Risk control measures
7.3 Verification of risk control measures
7.4 Risk management of software changes
8 * Software configuration management process
8.1 * Configuration identification
8.2 * Change control
8.3 * Configuration status accounting
9 * Software problem resolution process
9.1 Prepare problem reports
9.2 Investigate the problem
9.3 Advise relevant parties
9.4 Use change control process
9.5 Maintain records
9.6 Analyse problems for trends
9.7 Verify software problem resolution
9.8 Test documentation contents
Annex A (Informative) Rationale for the requirements of this standard
Annex B (Informative) Guidance on the provisions of this standard
Annex C (Informative) Relationship to other standards
Annex D (Informative) Implementation
Bibliography
Figure 1 Overview of software development processes and activities vi
Figure 2 Overview of software maintenance processes and activities vi
Figure 3 Assigning software safety classification
Figure B.1 Pictorial representation of the relationship of hazard, sequence of events, hazardous situation, and harm – from YY/T 0316-2016 Annex E
Figure B.2 Example of partitioning of software items
Figure B.3 Relationship among off-the-shelf software, SOUP and legacy software from the regulatory perspective
Figure C.1 Relationship of key medical device standards to this standard
Figure C.2 Software as part of the V-model
Figure C.3 Application of YY/T 0664 with IEC 61010-1
Table A.1 Summary of requirements by software safety class
Table B.1 Development (model) strategies as defined in ISO/IEC 12207
Table C.1 Relationship to YY/T 0287-2017
Table C.2 Relationship to YY/T 0316-2016
Table C.3 Relationship to IEC 60601-1
Figure C.3 Application of YY/T 0664 with IEC 61010-1
Table C.4 Relationship to ISO/IEC 12207:2008
Table D.1 Checklist for small manufacturers without a certified QMS
