YY/T 0664-2008 English PDF (YY/T0664-2008)

YY/T 0664-2008: Medical device software - Software life cycle processes
Delivery: 9 seconds. Download (and Email) true-PDF + Invoice.
Newer version: (Replacing this standard) YY/T 0664-2020
Get Quotation: Click YY/T 0664-2008 (Self-service in 1-minute)
Historical versions (Master-website): YY/T 0664-2020
Preview True-PDF (Reload/Scroll-down if blank)


YY/T 0664-2008
Medical device software.Software life cycle processes
ICS 11.040
C30
People's Republic of China Pharmaceutical Industry Standard
Medical device software software life cycle process
(IEC 62304..2006, IDT)
Published on April 25,.2008
2009-06-01 Implementation
Published by the State Food and Drug Administration
Contents
Foreword III
Introduction IV
1 Scope 1
1.1 Objective 1
1.2 Application range 1
1.3 Relationship with other standards 1
1.4 Compliance 1
2  Normative references 1
3  Terms and definitions 1
4  General requirements 5
4.1 Quality management system 5
4.2 Risk Management 5
4.3  Software security level 5
5 Software Development Process 6
5.1 Software development planning 6
5.2 Analysis of software requirements 8
5.3 Design of software architecture 9
5.4 Detailed software design 10
5.5 Implementation and verification of software units
5.6 Software integration and integration testing 11
5.7 Software system test 12
5.8 Software release 13
6 Software Maintenance Process 14
6.1 Develop a software maintenance plan 14
6.2 Analysis of problems and modifications 14
6.3 Implementation of modification 15
7  Software Risk Management Process 15
7.1 Software analysis that promotes hazardous situations 15
7.2 Risk control measures 16
7.3 Verification of risk control measures 16
7.4 Risk management of software changes 16
8 Software Configuration Management Process 17
8.1. Configuration ID 17
8.2 Change control 17
8.3  Configuration status record 18
9  Software problem solving process 18
9.1 Preparation of Problem Report 18
9.2 Research Questions 18
YY/T 0664-2008/IEC 62304..2006
9.3 Notify interested parties 18
9.4 Application change control process 18
9.5 Record keeping 18
9.6 Analyzing the Trend of the Problem 18
9.7 Solutions to Verification Software Problems 18
9.8 Test Document Contents 19
Appendix A (Informative) Explanation of reasons required by this standard 20
Appendix B (Informative) Guidance on the provisions of this standard 22
Appendix C (informative) Relationship with other standards 32
Appendix D (Informative) Implementation 51
Reference 53
Figure 1 Overview of software development processes and activities IV
Figure 2 Overview of software maintenance processes and activities Ⅴ
Figure B. 1 Software item division example 25
Figure C. 1 Relationship between key medical device standards and this standard 32
Figure C. 2 Software as part of the V model 35
Figure C. 3 This standard is the same as GB 4793's application 43
Table A. 1 Summary of Software Security Level Requirements 21
Table B. 1 Development (model) strategy specified in GB/T 8566 22
Table C. 1 Relationship with ＹＹ/T 0287-2003 33
Table C. 2 Relationship with Y/T 0316-2008 33
Table C. 3 Relationship with IEC 60601-1 36
Table C. 4 Relationship with IEC 60601-1-4
Table C. 5 Relationship with GB/T 8566 44
Table D. 1 Checklist for small manufacturers without quality management system certification 51
YY/T 0664-2008/IEC 62304..2006
Foreword
This standard equivalently adopts IEC 6302..2006 "Medical Device Software Software Life Cycle Process" (English version).
IEC 62304..2006 "Medical Device Software Software Life Cycle Process" gives an index of terms defined in Chapter 3. This standard
Delete the index.
The clauses marked with an asterisk () in this standard indicate that there are guidelines on the clauses in Appendix B.
Terminology in IEC 62304..2006 "Medical Device Software Software Life Cycle Process" (English version) and references in Appendix C
ISO 14971..2000 clauses. As the ISO 14971..2007 edition has been released, this standard references ＹＹ/T 0316-2008/ISO 14971.
Corresponding part of.2007.
Appendix A, Appendix B, Appendix C and Appendix D of this standard are informative appendices.
This standard was proposed by the Department of Medical Devices of the State Food and Drug Administration.
This standard is under the jurisdiction of the Technical Committee for Standardization of Medical Device Quality Management and General Requirements (SAC/TC220).
This standard was drafted. Medical Device Quality Management and General Requirements Standardization Technical Committee, Beijing Guoyi Huahua Certification Co., Ltd.
the company.
The main drafters of this standard. Qin Shuhua, Chen Zhigang, Milan Ying, Wu Junhua, Li Huimin.
YY/T 0664-2008/IEC 62304..2006
introduction
Software is often an integral part of medical device technology. Establishing the safety and effectiveness of medical devices including software requires that
Knowledge of the intended use of the software and to demonstrate that the use of the software accomplishes the intended purpose without causing any unacceptable risks.
This standard provides a framework for the life cycle process of the necessary activities and tasks for the safe design and maintenance of medical device software. this
The standard specifies requirements for each life cycle process. Each life cycle process is further divided into a set of activities, and most activities go further
Divided into a set of tasks.
As the main basis, it is envisaged that medical device software is developed within a quality management system (see 4.1) and a risk management system (see 4.2)
Development and maintenance. The international standard ＹＹ/T 0316 describes the risk management process well. Therefore, this standard only uses normative references
The favorable condition is ０/T 0316. The software needs to add some minor supplementary risk management requirements, especially those related to hazards.
Identification of influencing factors. These requirements are summarized and incorporated into Chapter 7 as a software risk management process.
In the hazard determination activities of the risk management process, determine whether the software is the influencing factor of the hazard. When determining if software is the cause
When doing so, you need to consider hazards that may be indirectly caused by the software (for example, providing misleading information that could lead to inappropriate treatment). use the software
Decisions to control risk are made in the risk control activities of the risk management process. The software risk management process required by this standard must include
Contained in the medical device risk management process established in accordance with Y/T 0316.
The software development process consists of several activities. These activities are shown in Figure 1 and described in Chapter 5. Because many accidents at the scene are and
Services or maintenance related to medical device systems, including inappropriate software updates and upgrades. Software maintenance process is considered to have been developed with software
The process is just as important. The software maintenance process is similar to the software development process. See Figure 2 and Chapter 6 for descriptions.
Figure 1 Overview of software development processes and activities
YY/T 0664-2008/IEC 62304..2006
Figure 2 Overview of software maintenance processes and activities
This standard identifies two complementary processes that must be considered for the development of secure medical device software, namely the software configuration management process (Chapter 8) and
Software Problem Resolution Process (Chapter 9).
This standard does not specify the organizational structure for a manufacturer or which part of an organization performs which process, activity, or task. This standard only requires completion
Establish a process, activity, or task to determine compliance with this standard.
This standard does not specify the name, format, or explicit content of the document to be formed. This standard requires task files, but how to organize them
Decisions on these documents are left to the standard users.
This standard does not specify a specific life cycle model. Users of this standard are responsible for selecting life-cycle models for software projects and
The processes, activities, and tasks in this standard are mapped on this model.
Appendix A provides a rationale for each chapter of this standard. Appendix B provides guidance provided by this standard.
For this standard.
"Shall" means that in order to comply with this standard, compliance with a requirement is mandatory;
"Should" means that in order to comply with this standard, meeting a requirement is recommended but not mandatory;
"May" is used to describe the way to achieve compliance with a requirement;
"Established" means to specify, document and implement; and
· The term "asappropriate" in this standard, when used with a required process, activity, task or output, means manufacturing
The manufacturer shall use the process, activity, task or output unless the manufacturer can document the justification for not doing so.
YY/T 0664-2008/IEC 62304..2006
Medical device software software life cycle process
1 Scope
1.1 Purpose
This standard specifies the life cycle requirements for medical device software. A set of processes, activities, and tasks described in this standard
Mechanical software life cycle process establishes a common framework.
This standard applies to the development and maintenance of medical device software.
When the software itself is a medical device, or when the software is an embedded part or component of the final medical device, this standard applies to that medical device
Development and maintenance of instrument software.
This standard does not cover the identification and final release of medical devices, even when the medical device consists entirely of software.
1.3 Relationship with other standards
When developing medical devices, this medical device software life cycle standard is used in conjunction with other applicable standards. This standard and other related
The relationship between relevant standards is shown in Appendix C.
1.4 compliance
Compliance with this standard means that all processes, activities, and tasks identified in this standard are implemented in accordance with the software security level.
Note. The software security level assigned to each requirement is determined in the text following the standard requirements.
Check all documents required by this standard (including risk management documents and processes, activities, and tasks required for software security levels).
Service assessment) to determine compliance. See Appendix D.
Note 1. This assessment can be achieved by internal or external audits.
NOTE 2 Even if the processes, activities and tasks to be completed are specified, the implementation of these processes and the methods for performing these activities and tasks are flexible.
Note 3. When any requirement that includes "as appropriate" is not completed, it is necessary for this assessment to document for reasons.
Note 4. Where the term "compliance" is used in this standard, the term "conformance" is used in GB/T 8566.
2  Normative references
The clauses in the following documents have become the clauses of this standard after being referenced. For dated references, all subsequent documents
The amendments (excluding the content of errata) or revisions are not applicable to this standard, however, all parties that have reached an agreement in accordance with this standard are encouraged to study
Is the latest version of these files available? For undated references, the latest version applies to this standard.
ＹＹ/T 0316 Application of Medical Device Risk Management to Medical Devices (ＹＹ/T 0316-2008, ISO 1497..2007, IDT)
3  Terms and definitions
The following terms and definitions apply to this standard.
3.1
Single or multiple interrelated or interacting tasks in a group.
3.2
Any deviation from expected specifications, design documents, standards, etc., or any perception or experience from some people
Case. Anomalies may be discovered during, but not limited to, the review, testing, analysis, editing, or use of software products or applicable documents.
[IEEE104..1993, Definition 3.1]
YY/T 0664-2008/IEC 62304..2006
3.3
The organizational structure of a system or component.
[IEEE 61.12..1990]
3.4
Documented instructions for making changes to software products
3.5
An entity that can be individually identified at a given datum point.
Note. Based on GB/T 8566-2007, definition 3.6.
3.6
The required result or output (including documentation) of an activity or task.
3.7
Systematically determine the extent to which a physical project meets its prescribed criteria.
[GB/T 8566-2007, definition 3.9]
3.8
Physical injury or damage to human health, or damage to property or the environment.
[ISO /IEC Guide 51..1999, Definition 3.3]
3.9
Potential source of damage.
[ISO /IEC Guide 51..1999, Definition 3.5]
3.10
Design, manufacture, package or mark medical devices, assemble systems, or modify medical devices before they are marketed and/or put into service
The responsible natural or legal person, regardless of whether the above work is done by himself or by a third party.
[ＹＹ/T 0316-2008, definition 2.8]
3.11
The manufacturer's intended use is for human use for one or more of the following specific purposes, regardless of whether the instrument, equipment, or devices are used alone or in combination.
Equipment, appliances, machines, utensils, implants, extracorporeal reagents or calibrators, software, materials or other similar or related items.
These purposes are.
--- diagnosis, prevention, monitoring, treatment or remission of the disease;
--- diagnosis, monitoring, treatment, mitigation or compensation of injuries;
--- research, replacement, regulation or support of anatomical or physiological processes;
--- support or sustain life;
--- pregnancy control;
--- disinfection of medical equipment;
--- Provide medical information through in vitro examination of samples taken from the human body.
YY/T 0664-2008/IEC 62304..2006
The main designed effects on the human body or in the body are not obtained by pharmacological, immunological or metabolic means, but there may be these
Means participate and play a certain auxiliary role.
Note...