Roszdravnadzor, the Russian regulating authority in the sphere of medical devices, has published the updated rules for evaluation of the software intended to be used for medical purposes. The document initially issued on February 12, 2021, and named “The methodological recommendations on the procedure for the examination of the quality, effectiveness, and safety of medical devices (in terms of software) for state registration within the framework of the national system” describes in detail the approach to be applied in the course of the assessment of medical software. The present document constitutes an updated version of the previous recommendations adopted earlier in October 2020.
General Provisions
The methodical recommendations described herein are initially intended to introduce a unified approach for the examination of quality, effectiveness, and safety of the software regulated as a medical device. The document prescribes a unified approach to be applied for the evaluation of compliance with the regulatory requirements set forth under the existing framework. The present methodological recommendations provide the definitions of the most important terms used in the context of medical software, such as “SaaS,” “web browser,” or “software,” and also introduce detailed instructions to be followed by the respective authority and expert organizations.
The scope of the present recommendations covers the examination of quality, effectiveness, and safety of the software subject to regulation as a medical device, including the software utilizing the Artificial Intelligence technology.
According to the document, the review of the application for state registration of medical software should be reviewed simultaneously with the examination of completeness and the results of the trials conducted.
The document also describes the risk-based classification to be applied for medical software. As it is stated in the document, all medical software could be divided into four classes depending on the risks associated thereto: Class 1, 2a, 2b, and 3 respectively. The appropriate risk class should be assigned to the medical software irrespectively of the risk class of a medical device it is intended to be used with. Additionally, medical software should be assigned with the safety class (A, B, or C respectively) depending on the potential impact caused to the patient, user, or other persons due to hazards associated thereto.
Updated Requirements
The new version of the aforementioned methodical recommendations contains certain improvements and amendments including, inter alia, the ones described below.
- The numbers of the software versions shall contain the information about the changes in the underlying software resulting in the changes to its versions. For instance, in the case of the A.B.C. number, “A” should be the main number of the version (should be changed in case of changes of the functional core, the addition of new functions changing significantly the functionality of the software), “B” – supplementary version number (to be changed in case of minor changes to the functional core or user interface), and “C” – the build number (to be changed in case of correcting errors that do not result in changes to the functions of the software).
- For the purpose of the technical documentation review, the software manufacturer (developer) shall provide the information about possible changes to the software that impact or do not impact its intended purpose or principal mode of action. Under the applicable regulatory requirements, it is also necessary to provide information about the way the user can obtain information about the current version of the software and the way it could be updated.
- The information to be provided by the developer should also contain the details about the interpretation function, the source of data set, hardware platform used, as well as the way the software would be deployed and could be accessed.
- In the case of software based on Artificial Intelligence / Machine Learning technologies, it is also necessary to provide a detailed description of the technologies used, including the details about the algorithm, machine learning method, and the dataset used for the initial training.
- The developer shall also provide a detailed description of the components of the software including its parts and modules, accompanied by the structure schemes of its architecture. Moreover, the developer shall highlight the means of control and identified potential hazards.
- The information to be provided shall also include the details on the process of installation and removal of the software, including the detailed description of actions to be taken on each step. It is also necessary to indicate the requirements for training or qualification of persons performing such procedures (if applicable).
- Another important aspect to be highlighted in the documentation to be provided relates to the verification and validation of the software. For this purpose, the developer shall provide test reports and the results of the trials. This information should contain the details about the methods used, the list of the measuring means and equipment, detail about the datasets used, the results of the trials and evidence received in terms of the correctness and reliability of processing incoming data and providing output data, as well as compliance of the algorithms used with the applicable regulatory requirements and standards.
- The medical software developer shall provide information about the product`s lifecycle processes, including the details about the main development stages. Such information could be accompanied by schemes, images, diagrams, or other clarifications. Technical documentation should also contain information about the measures taken by the manufacturer (developer) to ensure a sufficient level of informational security.
- Under the general rule, the medical software developer shall implement the development process which, to the maximum extent possible, ensures sufficient protection against the maximum amount of hazards and interventions. This approach should cover not the development process itself, but also the further use of the software.
- The software manufacturer shall determine the applicability of the national regulatory requirements related to personal data protection and ensure compliance with the applicable ones.
- The operational documentation of a medical software shall outline all intended purposes the software subject to review could be used for; determine the system necessary to deploy the software; indicate the software means of control for warnings and notifications; consider the risk associated with the human factor; prescribe the maintenance procedures; provide information about cases in which the customer (layperson) shall consult with the healthcare professional; and also indicate the particular knowledge the user shall have to be able to use the software in question in a safe and efficient way.
- The new rules do not prescribe a special approach to be applied in the case of Class 1 medical software intended for in vitro diagnostic purposes – the appropriate provisions have been repealed.
Summary
The updated methodological recommendations describe in detail the approach to be applied with regard to the software intended for medical purposes. In particular, the document clarifies the most important regulatory requirements prescribing the scope of the information to be provided by the medical device manufacturer (software developer) when applying for the state registration of its product. The updated version of the recommendations also covers the aspects related to the medical software based on the novel technologies – artificial intelligence and machine learning.
How Can RegDesk Help?
RegDesk is a next-generation web-based software for medical device and IVD companies. Our cutting-edge platform uses machine learning to provide regulatory intelligence, application preparation, submission, and approvals management globally. Our clients also have access to our network of over 4000 compliance experts worldwide to obtain verification on critical questions. Applications that normally take 6 months to prepare can now be prepared within 6 days using RegDesk Dash(TM). Global expansion has never been this simple.
Sources:
