Technical Review Guideline Of Medical Device Software Registration
2021-06-22
Appendix Technical Review Guideline of Medical Device Software Registration This guideline is intended to guide manufacturers in submitting declaration data for medical device software registration and standardize the technical review requirements for medical device software as well. This guideline consists of general requirements for medical device software. Manufacturers shall submit the declaration data for registration according to the characteristics of the medical device software, and determine whether the specific content in the guideline is applicable or not. If not, reasons for not applying the contents shall be elaborated. Manufacturers may also use other alternative methods to meet the regulatory requirements. However, detailed research and verification data shall be provided. This guideline is formulated based on the current regulations, standard system and cognitive level, with reference to foreign — regulations and guidelines, international standards and technical reports. With the continuous perfection of regulations and standards, and the continuous improvement of cognitive level and technical capabilities, the relevant content will also be amended in time. This guideline is a guiding document for manufacturers and reviewers. It neither includes the administrative matters involved in review and approval, nor is it enforced as laws and regulations. The guideline shall be used in compliance with relevant laws and regulations. According to the particularity of the software, this guideline further clarifies the requirements for medical device software under the requirements of current laws and regulations, especially the requirements for software updates and software versions. This guideline is a general guiding principle for medical device software, and other guidelines related to software medical device products can be targeted adjusted, modified or perfected on the basis of this guideline. I.Scope This guideline applies to the registration and declaration of medical device software, including the Class II and Class III — medical devices. The applicable software development methods include self-development, partial adoption of off the shelf software and full adoption of off the shelf software. Medical device software includes software as a medical device (SaMD) and software in a medical device (SiMD). SaMD: software as a medical device or its accessory; SiMD: software as a component of a medical device, its components or its accessories. SaMD shall have the following three characteristics at the same time: it shall have one or more medical purposes; it shall be able to complete the intended use without medical device hardware; and it shall be able to run on a common computing platform. SaMD as medical device includes general-purpose software and special-purpose software, in which the general-purpose software is jointly used with a number of medical device products based on a general data interface, such as PACS and central monitoring software; special-purpose software is jointly used with specific medical instrument products based on a general and dedicated data interface, such as Holter data analysis software and ophthalmic microscope image processing software. SiMD shall have both of the following characteristics at the — same time: it shall have one or more medical purposes; and it shall be able to control (drive) medical device hardware or run on a dedicated (medical) computing platform. SiMD includes embedded software and control software, in which the embedded software (i.e., firmware) runs on a dedicated (medical) computing platform and controls (drives) medical device hardware such as the software of electrocardiographs and electroencephalographs; the control software runs on a general computing platform and controls (drives) medical device hardware such as software of CT image acquisition workstation and MRI image acquisition workstation. SiMD can also have the processing functions. Dedicated SaMD cannot only be registered separately, but also be registered as a software component with the medical device. II. Basic Principle Due to non-physical nature of software, human factors affect everywhere in the course of development and application. The software testing cannot cover all situations due to the limit of time and cost, so the software defect cannot be avoided. At the same time, software updates frequently and rapidly. Even minor updates can have serious consequences. In addition, degradation is another — problem (i.e., a new flaw is created whenever several defects are repaired), so software defect cannot be eradicated. Therefore, software defect can be regarded as one of the inherent attributes of software. However, the quality of software cannot be ignored. In view of the particularity of the software, medical device software can only ensure the safety and effectiveness by comprehensively considering the requirements of risk management, quality management and software engineering. The risk level of medical device software is graded by using software safety classification (YY/T 0664 Medical Device Software: Software Development Life Cycle Plan), which is divided as follows based on the severity of software damage: Level A: It is impossible to cause injury and damage to health; Level B: It may cause not serious injury; Level C: It may cause death or serious injury. Software safety classification shall be determined by combining with the intended use, the use environment and the core functionality (the software fulfills all essential functions of the intended purpose in the expected application environment) of the — software. Among them, the intended use mainly considers the software’s medical purpose (such as diagnosis, treatment, monitoring, screening, etc.) and degree of importance (such as important effect, auxiliary effect, supplementing effect, etc.). The application environment mainly considers the software’s operation place (such as hospital and house, etc.), the type of disease (such as severity, urgency, infectivity, etc.), the patient group (such as adults, children, the elderly, women, etc.) and the types of users (such as professional users, general users, patients, etc.). The core functionality mainly considers the software’s type of function (such as control and driving, processing and analysis, etc.), implementation methods (for example, use filtered back projection algorithm or iterative algorithm for CT image reconstruction; use conventional image processing algorithm or artificial intelligence algorithm for anomaly identification etc.) and its complexity (such as the scale of algorithm, the number of parameters, computing speed, etc.). Software safety classification can also be determined according to the risk level confirmed by the risk management. Software safety classification and the risk level can be classified in different levels, but they also have correspondence. Therefore, software safety — classification can be determined according to the risk level. Manufacturers should determine software safety classification before taking risk mitigation measures and establish a software life cycle process that matches software safety classification combining with the requirements of quality management system, including software development process, software maintenance process, configuration management process, risk management process and problem-solving process. At the same time, manufacturers can use Good Software Engineering Practice to complete the requirements of Quality Management System, and ensure the software quality. In addition, manufacturers shall ensure the information security of the software itself, and ensure the confidentiality, integrity and availability of the health data. Manufacturers shall submit the corresponding data for registration and declaration based on software safety classification. The data for registration and declaration is derived from the documents formed in the software life cycle process, and the degree of detail depends on the security level and complexity of the software. Although SaMD and SiMD are different from each other in — structure, function and risk situations, the software life cycle processes are basically the same. Therefore, the basic principles for their registration data requirements are same while the specific requirements are different. III. Software Description Documentation Software description documentation was compiled based on YY/T 0664 Medical Device Software: Software Development Life Cycle Plan and applied to the registration of self-developed medical device software products. Software description documentation includes: basic information, implementation process and core algorithm (see Table 1 for details). (I) Basic Information
Software Identification Specify the name, model, version, manufacturer and manufacturing site of medical device software. SiMD identification shall be applied by the manufacture quality control. 2. Safety Classification Specify the software safety classification (Class A, Class B or Class C) and elaborate reasons of this determination. —
Architecture Function Architecture design chart and graphical user interface (GUI) (if applicable) shall be provided based on Software Design Specification (SDS). Architecture design chart is applied for illustrating the relationship between component modules, and between component modules and external interface. The function, module relation and external interface of the component modules (specify optional installation and module version) shall be described based on architecture design chart. GUI is applied for describing the relationship among user interfaces. The function and module relation of clinical functionality module (specify optional installation and module version) shall be described based on GUI (if not applicable, use architecture design chart).4. Hardware Topology The physical topology graph shall be provided based on SDS to illustrate and describe the physical connection relationship among software (or component modules), general purpose computers, and — medical device hardware. 5. Operation Environment Specify the hardware configuration, software environment and network condition required to software operations. Hardware configuration includes processor, memory and peripheral components. Software environment includes system software, supporting software and security software. Network condition includes network architecture (BS, CS), network type (WAN, LAN, PAN), and bandwidth. 6. Scope of Application The scope of software application shall be described for SaMD and the scope of application for medical device products shall be described for SiMD. The country of origin shall be described for software of imported medical devices. 7. Contraindications As for SaMD, contraindications or service restrictions of the software shall be described. In regarding to SiMD, contraindications or service restrictions of the medical device product shall be described. The country of origin shall be described for software of — imported medical devices. 8. Registration History As for SaMD, the registration situation in China (released versions and certificate number of each registration shall be listed) and the country of origin (if applicable, dates, released versions and administration categories of each registration shall be listed) shall be described. Registration situations in other major countries and regions can be provided as well. The registration situation of medical device products shall be provided for SiMD. (II) Implementation Process
Development Overview Specify the language, tool and method used in the software development process. As for the tool, the name, completed version and manufacturer of the supporting software (include open-source software) and application software (third-party software) shall be described. At the same time, the developers’ number, development time, workload (number of person and month), and total number of code line shall be specified. 2. Risk Management — A software risk analysis report and a software risk management report shall be provided according to relevant standards of risk management. The risk management materials shall be submitted separately in attach with the original documents. The risk management report of medical device shall be provided for SiMD. 3. Requirement Specification Requirements regarding to software functionality of Software Requirement Specification (SRS) shall be provided for Class A software. As for Class B and C software, the whole SRS shall be submitted. SRS shall be submitted separately in attach with the original documents. If there are no specific software requirement specifications for SiMD, requirements specifications for medical device products can be provided. 4. Life Cycle For Class A software, the abstract of software development life cycle plan shall be provided, and the division of development phases and tasks shall be described. On the basis of Class A, as for Class B software, the abstract of software configuration management plan and maintenance plan shall be provided and applied tools and processes shall be described. On the basis of Class — B, as for Class C software, an index table of design historical file (DHF) shall be submitted. For the life cycle, the manufacturers’ software life cycle process documents or the checklist of process standards such as YY/T 0664 Medical Device Software: Software Development Life Cycle Process can also be submitted to replace the corresponding description. 5. Verification and Validation Verification refers to the determination that the output of a certain stage of software development meets the input requirements by providing objective evidence, which includes code test, design review, testing and other quality assurance activities. Validation is the determination by providing objective evidence that the software meets the need of users and intended uses, which usually refers to the user tests conducting in a real or mock service environment. Traceability analysis refers to tracking the relationships among requirements specifications, design specifications, source code, testing, and risk management, and analyzing the correctness, consistency, completeness, and accuracy of identified relationships. For Class A software, please provide system testing plan, user — testing plan and report abstract, and describe the testing condition, tool, method, pass criteria and result. For Class B software, please provide plans and reports for system tests and user tests; introduce the validation activity of each development stage briefly; and describe the corresponding tool, method, content and result. For Class C software, please provides traceability analysis reports (traceability requirements specifications, design specifications, tests, risk management relationship tables) on a level B basis. Please attach original files for system tests and user tests. As for the test report, a sample test record and a complete list of test records shall be provided. For validation activities, documents of manufacturers’ software quality assurance plan document can also be submitted to replace the corresponding description. 6. Defect Management For Class A software, please describe the tool and work flow of defect management listing the numbers of total defects and residual defects of this registration. For Class B and C software, please list the known residual defects on the basis of Class A to demonstrate that the risk of all known residual defects is acceptable. The original document may be attached for the known residual defects. —
Update History For Class A, B and C software, the software version naming rules shall be described; all the fields and their meanings of the software version shall be specified; and the complete version and the released version of the software shall be confirmed. For Class A software, the complete version, date and type of each software update between this registration and the previous registration shall be listed. For Class B software, please elaborate the updated content among each software updates on the basis of Class A software. For Class C software, please list the complete version, date, type and specific updated content among each software updates during each registration. As for the imported medical device software, the update situation in the country of origin shall be described. For the initial registration of a product, the update situation during the software development stage shall be described. Revision history can be submitted in attach with
