Comparison Table of Revision and Change of Guiding Principles for Medical Device Software Registration Review

This guidance may also be used as a system verification reference for medical device software, QMS software.

Level B provides a configuration management plan summary and a maintenance plan summary on a level A basis, describing the tools and processes used. Level C provides a design history document set index form (DHF) on a level B basis. The survival cycle may also submit the manufacturer’s software survival cycle process document or a verification table of the process criteria such as YY / T 0664 Medical Device Software Survival Cycle Process for the replacement of the corresponding description.

Cell testing is the testing of software units, usually with a white box test. Integration testing is the testing of software items (consisting of several software units, i.e., software modules) and a combination of white box test, black box test, gray box test; Systematic testing is the testing of software systems (consisting of several software items), usually using black box tests, which can be further divided into functional tests, performance tests, concurrent tests, stress tests, interface tests, memory tests, compatibility tests, user interface tests, installation offloading tests, security tests, etc., from a test content perspective.

Internal testing refers to tests implemented by the registered applicant and includes a combination of unit testing, integration testing, systems testing, white box testing, black box testing, gray box testing; User testing means that the intended user tests the software system in real or simulated use scenarios, employing black box tests; Third party testing refers to testing of software systems by third party institutions, typically with black box testing.

Regression testing refers to software testing used to determine that software updates have not produced undesirable effects and that no new defects are unacceptable with respect to risk have been introduced.

Algorithm types include well-known mature algorithms and new algorithms. Among them, recognized mature algorithms refer to algorithms derived from public literature, with simple and clear principles, and have been on the market for many years without adverse events, while brand-new algorithms refer to new algorithms derived from clinical research and scientific research.

From the perspective of complexity, it can be divided into simple algorithms and complex algorithms. The former is simple and clear in principle or based on mature formulas, while the latter is usually based on model research, with many assumptions and many influencing factors. There are also differences in speed and so on.

From the perspective of interpretability, it can be divided into white-box algorithms and black-box algorithms. The former can be associated with existing knowledge, while the latter is difficult to establish association with existing knowledge. The former is better than the latter in interpretability.

From the perspective of the scope of supervision, it can be divided into medical device functions and non-medical device functions. Among them, medical device functions refer to software functions that can be used as the basis for the definition of medical devices, and vice versa, which are non-medical device functions and patient information necessary to achieve medical device functions. The management function belongs to the medical device function. The two should be split as far as possible through modular design. If it is technically impossible to split, the non-medical device functions should be considered as an integral part of the medical device software.

The real-time perspective can be subdivided into real-time and non-real-time, the former risk is usually higher than the latter. Therefore, software functions can be divided into auxiliary decision-making functions and non-aided decision-making functions, real-time functions and non-real-time functions from the perspective of software use.

Among them, the intended use mainly considers the clinical use of the software (such as diagnosis, treatment, monitoring, screening, etc.) and the degree of importance (such as important role, auxiliary role, supplementary role, etc.), and the use environment mainly considers the place where the software is used (such as hospitals, families, etc.), disease type (such as severity, urgency, infectiousness, etc.), patient population (such as adults, children, elderly, women, etc.) and user types (such as professional users, ordinary users, patients, etc.), the core functions are mainly considered software function type (such as control drive, processing analysis, etc.), implementation method (such as CT image reconstruction using filtered back-projection algorithm or iterative algorithm, abnormal identification using conventional image processing algorithm or artificial intelligence algorithm, etc.) and complexity (such as algorithm scale) , number of parameters, operation speed, etc.).

If there are multiple operating environments or multiple release versions, each incompatible operating environment (including cloud computing) or each release version that does not cover each other needs to be used as a detection unit.

If there are multiple operating environments or multiple release versions, each incompatible operating environment (including cloud computing) or each release version that does not cover each other needs to be used as a detection unit.

If the core functions of the software are the same but the types of core algorithms are different, the core functions corresponding to each type of core algorithm need to be detected (the detection object is the core function rather than the core algorithm).

Similarly, if the core functions of the software are the same but the core algorithm types are different, the core functions corresponding to each type of core algorithm need to be tested.

Manufacturers can pick up substantial equivalent contrasts for the same class of software features included on an already marketed medical device product.

Non-assisted decision-making software functions are based on core functions to compare medical devices of the same type. New core algorithms, core functions, and intended uses all require clinical evaluation in principle. Simple operation and simple process optimization software functions can be evaluated by non-clinical evidence.

The auxiliary decision-making software function is based on the core algorithm to compare the medical devices of the same variety, and the clinical evidence of the selected medical devices of the same variety must be based on clinical trials (including retrospective studies, the same below) in principle. In principle, all new core algorithms, core functions, and intended uses require clinical trials. If a clinical trial adopts an active control design, independent software with the same intended use and equivalent core algorithms or core functions can be selected for comparison.

The registration applicant needs to consider the requirements for software interface requirements analysis, risk management, verification and validation, maintenance plan and other activities, as well as the design requirements for instructions and labels.

The registration applicant can submit a separate interoperability research material, including basic information, requirements specification, risk management, verification and confirmation, and maintenance plan; the software interface requirements can also be reflected in the relevant clauses of the self-developed software research report.

Registration applicants are required to provide research data on the measurement accuracy and inform users in the instructions. In addition, the objective physical measurement needs to specify the accuracy index in the product technical requirements, and the graphic measurement needs to provide warning information about the measurement accuracy in the manual.

The registered applicant is required to provide the corresponding research data in software research data, network safety research data, specify the requirements of performance indicators in the technical requirements of the product, and inform the users in the instructions about the use requirements of the corresponding functions (including network safety).

If the medical device software cannot technically separate the non-medical device functions, the non-medical device functions need to be considered as a part of its own as a whole, focusing on the impact and risks of the non-medical device functions on the medical device software.

Delete GB/T 25000.51 in the technical requirements, and the registration applicant shall submit the GB/T 25000.51 self-test report in the software research materials, or submit the self-test report or inspection report instead of the self-test report.

Software components should also be tested according to GB/T 25000.51.

software identification

physical topology

Requirements specification: A level provides requirements specification summary, B, C level requires software requirements specification document verification and validation: A level provides test plan and report summary, B, C level requires test plan and report document

Traceability Analysis: Grade C provides traceability analysis report

Clinical evaluation

Add: HASH value, delete: scope of application, contraindications

Added: Physical connection relationship of prerequisite software

Software requirements specification documents are required at level C of A & B and C level.

The full text of the test plan and report should be provided at the level C of A & B and C.

Both An and B & C are required to submit traceability analysis reports.

Delete clinical evaluation.

Added: conclusion description

Identify the types of objects processed by the software, such as images (such as CT, MRI, X-ray, PET, US, etc.), data (such as ECG, blood pressure, blood oxygen, blood sugar, etc.)

Clarify the input data type of the software (such as medical images, physiological parameters, in vitro diagnostic data, etc.) and the output result type (such as processing, measurement, analysis, etc.).

Identify common data interfaces for software (such as Dicom, HL7), product interfaces (standalone software that can be used in conjunction, medical device hardware)

Define the application program interface (API), data interface (including transmission protocol, storage format, such as DICOM, HL7, JPG, PNG, private protocol and format) and product interface (other independent medical device software and medical device hardware products that can be used jointly) for software to be invoked by users.

Identify the independent software and medical device hardware necessary for the software to complete the intended use

Specify other independent medical device software (name, model and specification, release version) and medical middleware (name, model and specification, release version) and medical device hardware products (name, model and specification) necessary for the normal operation of the software.

Clarify the software’s defense ability against user operation errors that lead to serious consequences.

Meet the requirements of Chapter 5 of GB / T 25000.51

Specify the software release version.

If necessary, the instructions shall specify the delivery, installation, setting, configuration, update, use restrictions, warnings and other contents of all ready-made software contained in the external software environment.