Revolutionizing Healthcare: The Rise of Medical Device Software and EU Regulatory Compliance

The use of software in the healthcare field is here to stay. Technologies emerging over the past years are revolutionizing patient care today–from efficient electronic systems that store patient information to innovative medical device software (MDSW) options such as artificial intelligence that can drive patient management. In Europe, MedTech regulators aim to ensure innovation while safeguarding users from potential risks by developing robust frameworks and industry standards that include considerations on MDSW.

NAMSA has drawn on our extensive expertise as a MedTech CRO and examined the clinical and performance evaluation requirements for MDSW as well as discussed related feedback our teams received from different Notified Bodies.

Clinical/Performance Evaluation for MDSW According to EU Regulations

The Clinical evaluation process, which follows the requirements established by the Medical Device Regulation (MDR), aims to evaluate the existing clinical data of medical devices to verify their safety and performance. On the IVD front, the performance evaluation process, which follows the requirements established by the In Vitro Diagnostic Medical Device Regulation (IVDR), aims to assess the scientific validity, analytical and clinical performance of IVD products. Additionally, the Medical Device Coordinating Group (MDCG) published a guidance document in 2020 to support MDSW manufacturers in developing clinical and performance evaluations for these particular devices.

According to MDCG 2020-1, the manufacturer must consider three key components to demonstrate compliance with the MDR/IVDR requirements when developing the MDSW’s Clinical Evaluation Report (CER) or Performance Evaluation Report (PER):

• The valid clinical association (MDR)/Scientific validity (IVDR)
• The validation of the technical performance (MDR)/Analytical performance (IVDR)
• The validation of clinical performance according to the intended purpose

MDCG 2020-1 provides guidance on how to generate data to support each of these key components and their common sources in MDSW evaluation. It is noteworthy that exceptional circumstances may lead to procedure variations. For example:

• MDSW with multiple features or modules: Clinical performance only needs to be demonstrated for features or modules of an MDSW claiming a specific clinical benefit.
• Inability to meet requirements based on clinical data: When demonstration of compliance based on clinical data is not appropriate (per MDR Article 61 Section 10), the manufacturer must provide a solid justification on the clinical/performance evaluation and demonstrate conformity using non-clinical data (i.e., bench testing, preclinical evaluation and usability assessment).
• MDSW with no direct clinical benefit or measurable outcome: Manufacturers occasionally do not explicitly claim direct clinical benefits for their MDSW, or if they do, these benefits may not be quantifiable or tied to specific clinical outcomes. The Regulation acknowledges this situation and explains that usability (predictable and reliable use) can serve as a demonstration of clinically relevant outputs. In such cases, prioritizing and reinforcing technical/analytical performance evidence is fundamental.

Insights From MDSW Submissions

• Safety objectives for MDSW: Software safety issues are often less apparent compared to other medical devices. The risks primarily involve incorrect diagnosis and inaccurate dose calculations (caused by an inaccurate output of the software), rather than direct physical harm. Risk management files should reflect all considerations software may contribute to indirect harm to a patient, i.e. delayed or incorrect treatment. Considerations should also be given to cybersecurity, artificial intelligent features and usability. This complexity when identifying risks highlights the importance of collaborating with engineers during the development of the MDSW, as well as conducting thorough validation studies. The manufacturer must keep in mind that risks may be less apparent and alternative approaches may be required to uncover them.
• Differentiating safety and performance objectives for MDSW: In some cases, safety objectives could also be considered as performance objectives, particularly when the accuracy of the software’s output is involved. In such cases, careful attention must be given to the wording, e.g., distinguishing between “accurate measurement of…” (performance objective) and “limited inaccurate measurement of…” (safety objective). Additionally, the CER/PER should provide a thorough justification explaining any relationships between safety and performance in software, and why the acceptance criteria have been identical in both cases.
• Risk classification of MDSW: Determining the risk profile classification of an MDSW can also be challenging. This classification is essential, as it dictates the level of clinical evidence required to support the device’s safety and performance. For instance, classifying an MDSW as Class I can facilitate the development of the CER/PER utilizing non-clinical performance such as internal software verification and validation. Higher-risk class software products may require additional validation activities and even clinical data. Unfortunately, as a general rule, MDSW is rarely classified as Class I. This is because software applications and software-controlling medical devices often play a critical role in making diagnoses or determining patient dosages. However, there are exceptions where the manufacturer explicitly states that the MDSW output is just one factor among many other considerations for the physician. In such cases, if the MDSW has a relatively simple mode of operation, it may be classified as Class I since the output is not directly used for patient diagnosis/management/therapy.
• Lifetime of MDSW: Estimating the lifetime of an MDSW can be a difficult part of the clinical/performance evaluation of the device–particularly for MDSW that encompasses both software and hardware components. In such cases, it is appropriate to determine the lifetime based on the availability of the hardware on which the software runs, and the availability of the compatible operating system. Alternatively, the lifetime of the MDSW can be specified as the duration until the software is replaced by the next release. Therefore, for many MDSWs, it is not possible to state the lifetime in terms of a specific timeframe. Manufacturers must clearly identify the lifetime of the MDSW through version release, hardware versions or another valid The clinical/performance evaluation and assessment of the device’s safety and performance must be performed throughout its entire lifecycle, as specified in the MDR/IVDR. This requirement considers the possibility of various maintenance procedures that a device may undergo during its lifespan, including repairs, updates, upgrades or servicing.
• Generalizability: In certain cases, the manufacturer may state that the intended population (e.g., Adults regardless of sex) is broader than the population described in the supporting clinical data of the device (e.g., due to the clinical condition profile, the clinical trial participants may have been primarily older than 40, even though the intended population includes younger adults). In such cases, the manufacturer can combine existing clinical data, systematic literature searches, vigilance searches and PMS findings to support the device’s generalizability to the entire population. The manufacturer may acknowledge that the management of the remaining population with no supporting clinical data might not be extensively reflected in the presented data due to the prevalence of the clinical condition. However, the absence of vigilance incidents or complaints related to device malfunctions in this population, along with positive PMS data for other population sets, may support the device’s safety and performance in this remaining population. The concept of generalizability is first introduced in MDCG 2020-1, but don’t worry! Although it’s a new concept in this document, it aligns with what a Notified Body might request for any other type of device (non-MDSW) and obtaining the required data may be relatively simple.

How Can NAMSA Help?

The rapid development of MDSW applications opens the door to new opportunities in the digital health field but also means new challenges. MDSW manufacturers face a big struggle when balancing the drive to bring in innovation while complying with the safety and performance standards established by the Regulations. One of these challenges may be identifying which features need to be addressed in the clinical/performance evaluation of their MDSW, as well as determining adequate quantity and quality of clinical data providing evidence for the intended purpose.

At NAMSA we are experts in MDSW. Our Medical Writing teams can help you prepare or update the clinical or performance evaluation documentation for your MDSW in compliance with the EU Regulations and applicable guidance documents. Contact us to get connected with the best SME for your project.