Regulation of software as a medical device: risk class and process steps
Available in VIDEO! Regulatory roadmap necessary to configure, validate and launch a software as a medical device (MD) in the 10th Breakfast&Learn of the TECSAM Network. Dominique Monferrer, Medical Device Director at Asphalion, showed us the classification of the software according to the risk class and the stages of the regulatory process. Don’t miss it!
The classification of the software according to its risk class (I, IIA, IIB or III) is one of the central points to be defined in the initial phase of the creation of this type of medical devices.
Software as a medical device is classified, by default, as risk IIA, which affects the regulatory process for these medical devices and requires the involvement of a notified body to carry out their validation and market launch. This was one of the central ideas of the 10th Breakfast&Learn of the TECSAM Network.
This new B&L meeting, entitled “Regulation of software as a medical device”, was led by Dominique Monferrer, Medical Device Director at Asphalion, who outlined the steps that every researcher must take to accredit his or her software, from its conceptualization and design to its clinical validation and subsequent commercialization.
One of the essential criteria to be taken into account both in the initial software configuration phase and in its development is the risk class (I, IIA, IIB or III) of the software based on its usability and the degree of potential error that can be identified in its operation, as Monferrer explained.
As stipulated in the new regulations, specifically Rule 11 of the Medical Device Regulation, from the outset, software as a MD is subject to Class IIA, which means that it has to go through a compliance regulation process with a notified body. Software that is classified as IIB and III are those that have the highest risk of impact on patient management. On the other hand, those classified in class I (which occur in very specific cases) have a very lax regulatory control and do not have to go through the agency’s audit.
Despite this classification, Asphalion’s regulatory expert indicated that many applicable rules and sub-rules must be taken into account depending on the typology and purpose of each software and that it must be looked at on a case-by-case basis. However, she stated that, in case of doubt, the strictest rule and sub-rule resulting in the highest risk classification should always be applied.
Regulatory roadmap for software as a medical device, by phases
Any software as a medical device has the potential to solve a medical need, but before becoming a medical device it must go through a complex regulatory path with many intermediate stages. In this session, all the attendees were able to learn first-hand about the roadmap to follow to comply with the regulation and the European framework that governs these technologies.
According to Dominique, the regulatory process for software as a medical device is defined by 5 key moments: software design, risk class definition, product development (clinical validation), technical documentation and the conformity assessment procedure.
Product conceptualization and design
As Monferrer explained, right from product configuration, and apart from design (functionality) and usability (user-friendly) requirements, software manufacturers must adopt a regulatory approach to show compliance with regulatory requirements and technical standards (ISO).
It is also the phase in which the risk class of the technology is determined, which, as mentioned above, is marked by the consequences of a possible software error on the user. The product must also comply with specifications in terms of cybersecurity and interoperability, something that forces developers to implement cybersecurity plans.
The session also focused on the main differences between when a software product is classified as a medical device and, therefore, must comply with the Medical Device Regulation, and when it is an in vitro diagnostic product, governed by the In Vitro Diagnostic Regulation.
Although both have a medical purpose and perform complex data actions, software such as IVDR analyzes a biological sample obtained from the human body, including blood and tissue donations, and its analysis must be exvivo.
Development: verification and clinical validation
Halfway through, researchers reach the product development process, where, in addition to the verification of its technology, all software must undergo clinical evaluation to demonstrate its validity with clinical data, according to Asphalion’s expert in medical devices.
Technical documentation and commercialization
Once these last phases of development are completed, the “compilation of technical documentation” takes place (documentary pack describing the product: what it is, intended use, mechanism of action or operating principle through which the purpose is achieved, design and development process, verification at all levels and final clinical validation) in order to be sent to the notified body.
Once on the market, the software will be subject to post-marketing monitoring and follow-up plans to ensure its safety and efficiency. Regulation is a living process that forces researchers to pay attention to all the regulations in force.
Whether you are in the development and clinical evaluation phase of your software as a medical device or you are just a step away from launching it to the market, you need to know all the regulations surrounding this technology. This session is an opportunity to delve into the complex regulatory field. Did you miss the B&L or do you want to watch it again? You can now access the recorded video session.
You can consult the day’s program and more information about the session at the following link.
