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
