Impact of Rule 11 on the European medical software landscape: analysis of EUDAMED and further databases three years after MDR implementation

Impact of Rule 11 on the European medical software landscape: analysis of EUDAMED and further databases three years after MDR implementation | Research Square window.SnipcartSettings = { analytics: { enabled: false } }; (function() { var accessVector = localStorage.getItem('access_vector') || ''; window.dataLayer = window.dataLayer || []; if (accessVector) { window.dataLayer.push({ user: { profile: { profileInfo: { snid: accessVector } } } }); } })(); (function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src='https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);})(window,document,'script','dataLayer','GTM-K279D39R'); Browse Preprints In Review Journals COVID-19 Preprints AJE Video Bytes Research Tools Research Promotion AJE Professional Editing AJE Rubriq About Preprint Platform In Review Editorial Policies Our Team Advisory Board Help Center Sign In Submit a Preprint Cite Share Download PDF Research Article Impact of Rule 11 on the European medical software landscape: analysis of EUDAMED and further databases three years after MDR implementation Arndt A Schmitz, Miriam Font-Nieves, Toumani Doucoure, Hans-Peter Podhaisky This is a preprint; it has not been peer reviewed by a journal. https://doi.org/ 10.21203/rs.3.rs-4990580/v1 This work is licensed under a CC BY 4.0 License Status: Published Journal Publication published 28 Jan, 2025 Read the published version in Therapeutic Innovation & Regulatory Science → Version 1 posted 8 You are reading this latest preprint version Abstract Introduction: Medicine is increasingly supported by software, with digital health technologies offering innovative ways to capture insights and drive therapies. Globally, medical device software must follow regulatory processes based on risk classification. The introduction of MDR represents a significant shift in risk-based qualification for Medical Devices in Europe, including classification Rule 11 for software, which has caused significant discussions among European regulators. Materials and Methods Three years after implementation, we conducted a systematic impact assessment of MDR classification Rule 11 for MDSW through a qualitative and quantitative analysis of over 2,000 software entries from the European Medical Device database, complemented by data from other public databases such as the German DiGa directory and mHealthBELGIUM. Results and Discussion Our results indicate a shift of the per-default classification of MDSW in Europe after the implementation of the MDR: while most of legacy software in EUDAMED falls in the lowest risk category as MDD Class I (53%), the situation reverses for the MDR conform entries with the most entries in Class IIa (55%). Analyzing the legacy MDD patient apps in Germany implies that three quarters will have to re-classify as MDR Class IIa at the end of the transition period in 2028. A comparison of the European and US regulatory landscapes, along with a systematic review of software features for Class I vs. Class IIa products, explains our findings and enables us to recommend a regulatory strategy for developing MDSW compliant with MDR Class I rules, ensuring fast access to the European market. DHT DiGa MDR MDSW Regulatory Strategy SaMD Figures Figure 1 Figure 2 Figure 3 Figure 4 Introduction Medicine is increasingly supported by software. For example, digital health technology (DHT) such as wearables, sensors, or mobile apps offer novel opportunities to capture patient experiences in real world settings, to assess the impact of different diseases, and to drive therapies. Software that classifies as Medical Device Software (MDSW*) needs to undergo an appropriate regulatory process according to its risk classification. The requirements for the life cycle process of Software as Medical Device (SaMD) respectively MDSW are described by the ISO Standard ICE 62304 [1] and are comparable with the requirements for other types of medical devices (MD): Developers of MDSW should identify and assess potential risks throughout the entire lifecycle of the MDSW and implement appropriate measures to mitigate those risks. Further guidance on the risk categorization of MDSW is provided by the International Medical Device Regulators Forum (IMDRF) guideline ‘Software as a Medical Device: Possible Framework for Risk Categorization and Corresponding Considerations’ [2]. Risk-based qualification approaches for MDSW protect the interests of users and consider the impact of a malfunction of this software: While the failure of a software that calculates the dosage of a tumor medication can be life-threatening, the malfunction of a software that, for example, provides dietary advice for obesity is mostly an annoyance for the user. Accordingly, the latter, low-risk example requires significantly less regulatory scrutiny. In most legal systems the lowest risk category of MDSW can even be put on the market without prior approval of an authority. In 2018, US FDA adopted the IMDRF principles for SaMD into the national regulatory landscape when issuing the guidance document titled ‘Software as a Medical Device (SaMD): Clinical Evaluation’ [3]. In addition, dedicated guidance is provided for software with a low risk profile with limited functionality where FDA does not enforce the law [4] and for software that does not drive the clinical management and is exempted from medical device regulations [5]. Also, Japan and UK did follow the IMDRF approach. While the Japanese categorization concept for medical software is comparable with the US approach [6], for the UK the MHRA currently maintains the risk categorization for MDSW of the former European Medical Device Directive (MDD) [7]. The introduction of the Regulation (EU) 2017/745 (MDR) [8] superseding the MDD represents a significant change to enact the risk-based qualification approaches for MDSW proposed by the IDMRF into the European regulatory landscape. While the classification Rule 11 of the MDR provides criteria allowing a differentiation of MDSW into four different categories (I, IIa, IIb, III), almost any software characteristic apparently leads to a middle- or high-risk classification [9]. The stringency of Rule 11 has been noted [9–11] and, while some have welcomed this approach [12], an EFPIA reflection paper on Digital Health Technology provides a concise summary of worries regarding Rule 11: ‘There is a wide industry concern that Rule 11 could lead to a systematic upgrade from Risk Class I under the MDD to Class IIa under the MDR. For example, a simple software application that is used to help patients with diabetes manage their disease by tracking and trending their food intake, exercise and lifestyle activities, and blood glucose value is a Class I medical device under the MDD but becomes a Class IIa medical device under the MDR. ’ [13] Also, the relevant Medical Device Coordination Group (MDCG) guidance document on the classification of medical devices according to MDR did not solve the issue. In particular, it did not answer the question which MDSW still fall in the lowest risk category in Europe, as it provided only one concrete example for a possible Class I product, a ‘MDSW app intended to support conception by calculating the user’s fertility status based on a validated statistical algorithm’ [14]. The impact on software companies to launch their products as Class IIa instead of Class I is significant, in particular for a small MedTech company, making development lengthier and costlier: a certified quality management system is needed, and a risk-based design control process must be documented. The clinical evaluation of a Class IIa device typically requires a prospective clinical investigation. Finally, a conformity assessment procedure with a Notified Body (NB) is mandatory [13],[15],[16]. The substantial change of the classification principle for MDSW compared to the former MDD introduced by Rule 11 has caused considerable discussions within the regulatory community, for example in blog posts [9], [17]. However, we are not aware of any systematic analysis of the actual impact of Rule 11 on the situation of MDSW in Europe. Three years after the implementation of the MDR in 2021, we perform a quantitative and qualitative data analysis of the data for MDSW from publicly available databases such as the European Database on Medical Devices (EUDAMED) to contribute evidence to the ongoing discussion and to develop strategic guidance for developers of MDSW for the European market. Materials and Methods A manual search of the European Database on Medical Devices (EUDAMED) [18] was performed for device type = 'software' and all combinations of the fields ‘applicable legislation’, ‘risk class’, and ‘status’. The number of search results per query was documented. All UDI-DIs resulting from selected combinations of search terms were downloaded manually to xls files and used as input for semi-automated data scrapping. Search queries were built and parametrized and one search per UDI-DI was executed on June 25th to 28th, 2024, with each of the available three EUDAMED user interface APIs [19]. The automated search included the UDI-DIs as query parameters. The search results were combined to create an excel-consumable file. The above download per UDI-DI included the data field “details_2.manufacturer.countryIso2Code” for country, “details_2.manufacturer.srn” for Single Registration Number (SRN), and “details_1.cndNomenclatures” from which the European Medical Device Nomenclature (EMDN) code was extracted using Excel text formulas and manual polishing. For comparison, V1.1 of the code list (status 2021-09-29) was downloaded from the EMDN website [20]. Further databases utilized included EU’s ‘new approach notified and designation information system’ (NANDO) on NB [21]; the German DiGa directory [22]; the UK MHRA database, PARD [23]; and a Belgium mhealth platform [24] operated by industry associations [25]. Where possible, we also considered the webpages of the manufacturer of the MDSW listed in the German and Belgian databases or downloaded and installed the application to analyze its characteristics. Data were analyzed using standard office software package, Excel. All results are descriptive. There was no statistical analysis planned or performed. Only the correlation between number of MDR Class I UDI-DIs and statistics such as total GDP per EU country (obtained by multiplying the GDP per person [26] with the population size [27]) was fitted linearly and the correlation coefficient r 2 documented as calculated by Excel. Two letter countries codes used in Fig. 2 are according to ISO 3166-1 [28]. Results Analysis of regulatory MD databases EUDAMED, EMDN, NANDO, and PARD EUDAMED was queried to obtain an overview of all MDSW that have been registered so far on a voluntary basis or because of a serious incident or field safety corrective action reported for a legacy MDSW [29], identifying 2,298 entries. The number of software differs between regulatory pathways (Fig. 1). Already today, three years after MDR implementation, there are more MDSW under MDR registered than under MDD, IVD, and IVDD combined. We did not find any software under AIMDD (not shown). Close to 95 % of registered MDSW are currently on the EU market. The number of software also differs by risk Class (Fig 1b). While the absolute number of MDR Class I MDSW is significantly larger than the number of MDD Class I MDSW (461 versus 273), their percentage shrinks from 53 % to 35 %. In contrast, more than 90 % of all IVDR software is Class I. There is hardly any Class III MDSW (n = 2, both MDD). Software under IVDD is classified differently, most is ‘general’ (not shown). To obtain a more granular picture in an effective and structured manner, EUDAMED’s three application programming interfaces were used to ‘scrap’ information on all MDD Class I, MDR Class I, and MDR Class IIa UDI-DIs, resulting in 1,401 structured data sets. Each of these entries was analyzed for the single registration number, the manufacturer’s country, and European medical device nomenclature (EMDN) codes. We then counted the number of MDSW per Class per country (Fig. 2). The country with the highest number of MDD Class I MDSW retrieved from EUDAMED is Finland (Fig. 2a). Closer inspection revealed that more than half of Finnish MDSW is registered by a single government institution, Oy Apotti Ab, followed by Tietoevry, a multinational publicly traded tech & IT company with more than 10,000 employees (not shown). Among the top 15 countries in each class, one third are non-EU countries, such as the USA, UK, Switzerland, PR China, or South Korea, but not Japan (see Fig. 2a, b, and c). Regarding the Russian Federation (Fig. 2c), all UDI-DIs are registered by the same manufacturer, Medical Technologies Ltd, for the same Basic UDI-DI. The data on the manufacturers of the MDR Class I MDSW from EUDAMED on all 27 EU countries were used to identify possible patterns behind the data reflecting the impact of economic and industrial policies. However, a series of recent statistics on the digital status of their healthcare systems [30] did not correlate well with the data, neither did the number of NBs, population size, or GDP per capita (data not shown). The only correlation we found was between the total GDP per country and the number of MDSW UDI-DI (r 2 = 0.86, see Fig. 2d). While Germany and France as the two largest economies provide even more medical software than the trendline, Italy and Spain as the next largest economies provide less. When analyzing the number of NBs per country, as listed in the NANDO database, we noticed two aspects, the EU also endorses NBs in non-EU countries, such as Turkey or Norway, and the number of NBs certified for MDR differs widely per country: the 49 NBs registered are mostly based in Germany (n=11) and Italy (n=10) while France has only two NBs and Spain one NB (data not shown). Finally, we analyzed the EMDN codes assigned with each listed UDI-DI from EUDAMED. Table I: Use of EMDN codes by software listed in EUDAMED. Most entries had exactly one EMDN code listed, a minority up to four. We determined the frequency of EMDN codes for MDD Class I and MDR Class I and Class IIa UDI-DIs listed in EUDAMED (see Table I). While around half of all entries of MDD or MDR class I MDSW are using the EMDN generic group V92 (‘medical device software not included in other classes’), only 15 % of MDR Class IIa MDSW use this code. Most of these higher risk MDSW are using the EMDN group Z11 (“bioimaging and radiotherapy instruments (all types)”). The EMDN group Y21 (“communication and information management aids (all types)” is used frequently by MDR Class I MDSW. The EMDN group Z12 (“instruments for functional explorations and therapeutic interventions (all types)”) is used for a quarter of all entries in each of the three software groups. For comparison to EUDAMED, we accessed another public government database from outside the EU listing medical devices, UK’s MHRA PARD, which is currently only available in a limited beta version. Here a simple search retrieved 373 entries of ‘software’, to which 173 different GMDN codes are assigned. Three quarters of the entries were for MDD MDSW, with a distribution to risk classes like the situation in the EU (not shown). However, a further individual assessment of MDSW was not possible here, as PARD does not disclose any specific information on the device itself (e.g., brand name) and therefore does not allow an assignment of an entry to a concrete MDSW. Analysis of specialized MDSW databases DiGa directory and mHealthBELGIUM Neither EUDAMED nor PARD currently contain any further content description of the medical devices listed, such as the intended use or features of MDSW. We thus searched for further public databases with structured information on medical MDSW to complement our research by a qualitative analysis of the MDSW. We identified two further European databases for MDSW (mobile/web-based apps) that provide information on the intended use and functionality and thus allowing an in-depth analysis of the entries beyond a statistical summary. The German regulatory authority BfArM hosts the DiGa directory of all patient apps ever reimbursed in Germany, with currently 63 entries [22]. The Belgium platform for mobile applications mHealthBELGIUM [24] currently lists 30 entries. First, we performed a consistency check by comparing their contents to EUDAMED. We noted that around half of DiGAs in the BfArM directory listed an SRN or UDI-DI; while basically all SRN could be confirmed in EUDAMED, around half of UDI-DI were not confirmed by a quick search. Similar results were obtained for mHealthBELGIUM entries (not shown). In Germany, around half of all DIGA solutions fall in the category of Class I MDSW according to the former MDD or according to the current MDR, and a few more are MDR Class IIa. In Belgium, more than half of all listings are in Class IIa or higher, only one third are in MDD Class I (Fig. 3a). Next, we did a deeper regulatory assessment of all software listed in these two databases. According to our analysis, all current assignments of software to the MDD and MDR risk classes in the two databases are plausible with respect to the intended use and the main functionalities of the MDSW. For example, we did not identify any MDR Class I product with a personalized diagnostic functionality. An analysis of the intended purpose and their functionality of the legacy MDD Class I products according to new MDR rules [8] showed that 74 % (20 of 27) DiGA MDD Class I solutions require a reclassification to at least MDR Class IIa to continue business after the transition period in 2028 [31]. A similar situation is found in Belgium, where also the majority of the listed MDD Class I solutions (56 %, 5 out of 9) require a reclassification to at least MDR Class IIa (Fig. 3b). Our qualitative analysis of the specific characteristics of German and Belgian web based/mobile apps in legacy Class I MDD compared to Class IIa MDR conform MDSW showed that the subgroup of MDSW that can remain in the lowest risk Class I even after the end of the transition phase to the MDR in 2028 is characterized by low-threshold functionality (respectively low medical value) with a focus on health literacy, prevention including lifestyle suggestions, and cognitive behavioural therapy for stress management (Fig. 4a). Then we did a further analysis of these two databases to identify the functionalities of MDR Class I MDSW in comparison with MDR Class IIa products. We grouped the individual features into generic categories and found that the most common features in the Class I are related to ‘Goal Setting and Motivational Support’, ‘Cognitive Behavioral Therapy (CBT), Psychoeducation, and Health Literacy’, and ‘Health Diaries, Symptom Tracking, and Patient Feedback’ (Fig. 4c). Any monitoring or personalised diagnostic or therapeutic functionality of MDSW is only found in Class IIa software (Fig. 4b). Finally, to put our findings in the context of the regulatory landscape, we compared the regulatory risk classification concept provided by Rule 11 of the MDR with the IMDRF approach as implemented by FDA. Our analyses showed a discrepancy between these concepts for the categorization of a MDSW as a low-risk device (Table 2). Table 2a: IMDRF/ FDA Risk-based qualification approach of SaMD. [2] Table 2b: Regulatory impact assessment of the risk-based qualification approaches for MDSW provided by Rule 11 of the MDR. While the FDA offers dedicated and comprehensive guidance documents for this lowest risk category of MDSW: enforcement discretion [4], clinical decision support tools [5], and guidance for wellness apps [43], MDR Rule 11 lacks specific classification criteria for software intended for non-serious health conditions or software that only provides supplementary information to an HCP without driving clinical management. Thus Rule 11 does not provide any equivalent criteria for the classification of low-risk software except the two words ‘any other’ and the corresponding MDCG document [32] does not provide further clarity here. Discussion By introducing MDR, the EU aimed “to establish a robust, transparent, predictable and sustainable regulatory framework for medical devices which ensures a high level of safety and health whilst supporting innovation” [8]. The potential of conflicts among these goals had been already noted by others in the case of high-risk, physical medical devices [33]. A recent decision of a German upper court [34] regarding the proper classification of MDSW according to Rule 11 underlines the significance of the topic and demonstrates its impact on software startups. We analysed the impact of the regulatory change of the MDR on MDSW, with a particular focus on low-risk, Class I solutions, using publicly available databases, as we are not aware of any quantitative and qualitative research regarding this subject. Though use of EUDAMED is not mandatory yet, already more than 2,000 entries for MDSW are listed. Despite an unknown number of MDSW on the market not registered in EUDAMED, we are confident that the assessment of more than 2,000 entries allow some fundamental conclusions about the impact of Rule 11 of the MDR: Our result clearly show that the main regulatory classification of MDSW in Europe shifted after the implementation of the MDR from Class I MD to Class IIa. 53% of the MDD conform entries for MDSW in EUDAMED fall in the lowest risk category of a Class I MD while only 35% of the MDR conform entries fall in that category (Fig. 1b). This can be interpreted as the intended effect of the policy to ensure a higher safety level, but it also significantly increases the burden for manufactures to market such software in Europe: to launch a Class IIa MD in Europe a certified quality management system, substantial clinical evidence, and a conformity assessment procedure by a NB becomes mandatory while Class I MD can be marketed based on a self-declaration of conformity. We next analyzed detailed data on around 1,400 MDD class I, and MDR Class I and IIa entries that we were able to automatically extract from EUDAMED via data scrapping. The MDR also ‘aims to ensure the smooth functioning of the internal market’ and ‘to facilitate trade’ with non-EU countries [8]. We therefore analysed the geographic distribution of manufacturers and found a good correlation with total GDP per EU country. While global including Asian economies are well represented on the EU market, we noted an absence of Japanese companies among the top manufactures. This is matching the Japanese Ministry of Economy, Trade and Industry’s recent advice to industry to consider the US market as particularly important for global expansion and economic returns, due to its size, growth rate, and technological leadership [35]. Similar to Yu et al. [36] who analysed the OpenFDA database to understand the US MDSW landscape, we extracted further info from EUDAMED in form of EMDN codes. Half of all Class I MDSW is self-declared in the generic group V92 (‘medical device software not included in other classes’), while in Class IIa, where NBs are involved, only each sixth solution is in this group. In contrast, more than half of all Class IIa solutions are in group Z11, bioimaging and radiotherapy instruments, indicating that their features typically trigger this medium risk classification. The emerging potential of EUDAMED as a data resource for research is yet to be appreciated by the community. Only Bini et al. consulted EUDAMED for each EMDN code they identified being relevant for medical software, with a focus on Extended Reality applications. Also, in their analysis around half of the software used the V category [37]. The wide use of the generic coded for class I MDSW significantly diminishes the values of the database. In addition, EUDAMED lacks critical information on MDSW such as the specific intended purpose, intended user, main functionality, technical platforms, or reimbursement status in EU member states and there is no search option to easily identify MDSW for indications or to differentiate between MDSW for HCPs vs. laymen. In theory, more specific EMDN codes could be defined. EDMS codes allow for 2.6 billion combinations of which fewer than 9,000 have been defined [20]. UK’s PARD database uses GMDN codes which includes only 100,000 possible and offers subcategories that distinguishes between lay users and HCP-targeted software, for example code 62169 (‘Wireless patient monitor/sensor reporting software, layperson-use’) and 65832 (‘Wireless patient monitor/sensor reporting software, professional-only’). However, as the GMDN system is not publicly available, a further analysis was not possible here. We believe a more intuitive enhancement of EUDAMED would be to create mandatory data fields for the intended use and main functionality of MDSW. This aligns with the existing transparency for higher-classified products, where manufacturers provide summaries of clinical safety and performance. The benefits clearly outweigh the additional administrative burden. Mobile medical applications or web-based MDSW are innovative solutions with significant potential to enhance care delivery. The opportunity to obtain structured data at patient level offers the promise to realize the vision of value-based healthcare [38]. This has generated interest in various approaches realized in the USA [39], Germany [40], Belgium [25] and internationally concerning reimbursement strategies [41]. Considering the limitations of EUDAMED described above, we identified two specialized databases for medical apps that provide information on the intended use and the functionalities in a systematic manner: the German DiGa directory of patient apps reimbursed in Germany, with currently 63 entries [22] and the Belgium platform for mobile applications mHealthBELGIUM [24] currently covering 30 entries with Apps for patients and/or HCPs, provide information on the intended purpose of the MDSW and allowed an in-depth analysis. In Germany, almost all DiGa solutions are classified as MDD Class I or MDR Class I, with a few in MDR Class IIa. In Belgium, over half are Class IIa or higher, while only one-third are MDD Class I (Fig. 3a). Furthermore, we found the categorization of all MDSW by MDD or MDR criteria to be reasonable across both examined databases. A closer look at the MDSW that are currently classified as MDD Class I solutions in DIGA and mHealthBELGIUM demonstrated the significant impact of classification Rule 11: an analysis of the intended use and the functionality disclosed that 74% of German (20 of 27) and 56% of Belgium (5 of 9) of MDD class I solutions have to be up classified to a Class IIa product, at the latest after the end of the transition period to the MDR in 2028 [31]. If a substantial change is made to this software, this may be necessary even earlier, as the validity of the self-certification according to MDD will then expire. These data confirm our findings from Fig. 1b, that the transition from MDD to MDR causes a shift of the per-default classification of MDSW in Europe from Class I to Class IIa. The risk for patients is, that these current MDD Class I products may not be available after the MDR transition period deadline in 2028 [31], pending certification by an NB, or will be withdrawn from the market by manufacturers not able or willing to invest significant efforts into a conformity assessment procedure for a software that is per se characterized by limited medical value. Our analysis reveals the typical profile of a MDR conform Class I MDSW in comparison to the functionalities of a Class IIa product (Fig. 4a, Fig. 4b, and Fig. 4c). MDSW classified as Class I according to MDR is limited to software functions covering ‘Goal Setting and Motivational Support’, ‘Cognitive Behavioral Therapy (CBT), Psychoeducation, and Health Literacy’, and ‘Health Diaries, Symptom Tracking, and Patient Feedback’. We hope that this information provides more clarity to developers about the character of MDR Class I conform software, as the relevant MDCG guidance paper only mentions a MDSW to support conception as potential use case for a Class I product. The addition of any personalized therapeutic or diagnostic functionality to a MDSW, including those for harmless medical conditions, however, leads directly to a Class IIa product (Fig. 4c), for which a conformity assessment procedure with an NB must be carried out. Interestingly, a NB recently published their lead times for assessments indicating that in practise several additional months waiting time must be added to an already lengthy process [42]. An in-depth regulatory analysis of MDR Rule 11 reveals possible reasons for our observations and shows the differences between the regulatory landscape in Europe and the US (Table 2 a,b). The foundational concept of IMDRF for categorizing the risk of Software as a Medical Device (SaMD) is rooted in evaluating its intended use and functionality. This involves assessing the severity of the medical condition and aligning it with the significance of the software's information in healthcare decision-making, while also considering the potential impact of software malfunction (please see Table 2 ) [43]. The US-FDA did not only adopt this concept but also provides further detailed guidance for software of the lowest risk category: the FDA does not ‘enforce’ the regulatory oversight for certain software ‘that provide or facilitate supplemental clinical care’ including some simple medical calculators [4], exempts software from MD regulations that ‘provides a healthcare professional (HCP) with evidence-based tools to support HCP decision-making but does not replace or direct the judgment of the HCP by directing them to a specific action’ [5], and provides guidance for wellness apps ‘that promote a healthy lifestyle’ [43]. In contrast, the MDR only partially adopted a risk-based categorization approach for MDSW in Europe, lacking clear classification criteria for low-risk software solutions as outlined by the IMDRF (Table 2 a). The relevant classification Rule 11 can be divided into three subsections providing criteria for an assignment of MDSW to a low, moderate, or high-risk category (Class I, IIa, IIb, III) (Table 2 b). The granularity of the criteria in Rule 11 for risk classification of software is significantly less pronounced than in the corresponding IMDRF/US guidelines. Any type of therapeutic or diagnostic purpose, regardless of the severity of the medical situation or the level of knowledge of the user of the software, leads to classification as a moderate-risk device Class IIa, or higher. A strict interpretation of Rule 11 may classify simple medical calculators, like creatinine clearance and even BMI calculators, as Class IIa MDSW. For the classification as low-risk Class I, Rule 11 gives the vague reference ‘all other’, without mentioning a concrete criterion. Also, the MDCG guidance [32] document does not provide further clarity for the Class I category here. Our research suggests a strategy for European manufacturers to address this situation for fast and affordable market access. Maintaining a low-risk classification while at the same time providing a relevant medical benefit to ensure reimbursement can be achieved by developing a MDSW compatible with a MDR Class I self-certification as shown in Fig. 4a. For example, a tool with a preventive character can certainly provide a relevant medical benefit, as our analysis of the DiGA list demonstrated. A potential viable long-term strategy for a manufacturer could be to first launch a low-risk Class I product as a self-certified minimal viable product, gather clinical evidence in real-world conditions with the marketed product, and subsequently introduce a more developed solution that has undergone a conformity assessment by a Notified Body. Such a guidance might be appreciated by small and medium enterprises who regard MDR as a burden [44], in particular start-ups. While certainly EU legislators wrote Rule 11 with good intent to protect citizen from malfunctioning software, our analysis suggests that this strict classification may inadvertently hinder innovation and slow down access for patients and healthcare providers to new software solutions. To foster innovation in Europe, we hope that the current public consultation process by EU on future MDR revisions currently in preparation [45] will introduce clearer criteria for MDSW risk classification. The current blanket classification of diagnostic and therapeutic software as Class IIa does not accurately reflect their often-marginal risk. Within the frame of the current legislation, a revision of the MDCG guidance document [32] and the provision of concrete use case for a class I MDSW classification under the MDR Rule 11 would be helpful. Complementarly, a European equivalent to FDA guidance documents for low-risk software, clinical decision support tools, or for their policy for wellness app would be appreciated. These measures would enable the full implementation of IMDRF principles for MDSW into the European regulatory landscape, provide precise guidance for manufacturers for the European Union market, and drive global harmonization resulting in better access to innovative therapies. Abbreviations API, Application Programming Interface DiGa, Digitale Gesundheitsanwendung (regulated patient app reimbursed by German statutory health insurance) EUDAMED, European database on medical devices FDA, US Food and Drug Administration FDCA, US Federal Food, Drug, and Cosmetic Act GDP, gross domestic product IMDRF, International Medical Device Regulators Forum MD, Medical Device MDD, Medical Device Directive MDR, Medical Device Regulation (EU) 2017/745 MDSW, Medical Device Software MHRA, (UK) Medicines and Healthcare products Regulatory Agency NB, notified body SaMD, Software as medical device UDI-DI, unique device identification device identifier Declarations Funding statement All authors are currently employed by legal entities of the multinational enterprise Bayer. T.D. is also student at Université Paris-Saclay, Orsay, France. Conflict of Interest statement All authors are currently employed by legal entities of the multinational enterprise Bayer. A.A.S. and H.P.P. also hold stocks of Bayer AG. The views expressed in this article are the personal views of the authors and may not be understood or quoted as being made on behalf of or reflecting the position of the institutions with which the authors are affiliated. Author contributions (mandatory) for all authors A.A.S. and H.P.P. contributed substantially to the conception, designing, and drafting the work. All co-authors contributed substantially to the acquisition, analysis, and interpretation of data for the work and to revising the work critically for important intellectual content. All gave final approval of the version to be published and agreed to be accountable for all aspects of the work in ensuring that questions related to the accuracy or integrity of any part of the work are appropriately investigated and resolved. Data availability statement Downloads from EUDAMED are available upon request. Acknowledgements We would like to thank our colleague Kai Uwe Rieger for help with data scrapping and our colleague Nicolas Bertrand for critically reading a draft of the manuscript. References New references added, “available from” and “[internet]” will be removed after all comments for finalization. 1. International Organization for Standardization (ISO). ISO/IEC 62304:2006 (en), Medical device software — Software life cycle processes [Internet]. Available from: https://www.iso.org/obp/ui/en/#iso:std:iec:62304:ed-1:v1:en 2. International Medical Device Regulators Forum (IMDRF). “Software as a Medical Device”: Possible Framework for Risk Categorization and Corresponding Considerations [Internet]. 2012. Available from: https://www.imdrf.org/sites/default/files/docs/imdrf/final/technical/imdrf-tech-140918-samd-framework-risk-categorization-141013.pdf 3. Food and Drug Administration (FDA), Center for Devices and Radiological Health. Software as a Medical Device (SAMD): Clinical Evaluation Guidance for Industry and Food and Drug Administration Staff [Internet]. 2017. Available from: https://www.fda.gov/regulatory-information/search-fda-guidance-documents/software-medical-device-samd-clinical-evaluation 4. Food and Drug Administration (FDA), Center for Devices and Radiological Health, Center for Biologics Evaluation and Research. Policy for Device Software Functions and Mobile Medical Applications [Internet]. 2022. Available from: https://www.fda.gov/regulatory-information/search-fda-guidance-documents/policy-device-software-functions-and-mobile-medical-applications 5. Food and Drug Administration (FDA), Center for Devices and Radiological Health, Center for Biologics Evaluation and Research, et al. Clinical Decision Support Software, Guidance for Industry and Food and Drug Administration Staff [Internet]. 2022. Available from: https://www.fda.gov/regulatory-information/search-fda-guidance-documents/clinical-decision-support-software 6. Aoyagi Y. Updated Regulatory Strategies for Innovative Medical Devices in Japan [Internet]. 2017. Available from: https://www.mhlw.go.jp/content/11123000/000335171.pdf 7. Medicines and Healthcare products Regulatory Agency (MHRA). Guidance: Medical device stand-alone software including apps (including IVDMDs) v1. 10f [Internet]. 2023. Available from: https://assets.publishing.service.gov.uk/media/64a7d22d7a4c230013bba33c/Medical_device_stand-alone_software_including_apps__including_IVDMDs_.pdf 8. The European Council and the Council of the European Union. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, amending Directive 2001/83/EC, Regulation (EC) No 178/2002 and Regulation (EC) No 1223/2009 and repealing Council Directives 90/385/EEC and 93/42/EEC [Internet]. OJ L Apr 5, 2017. Available from: http://data.europa.eu/eli/reg/2017/745/oj/eng 9. Gerhart M. MDR Classification Rule 11: The classification nightmare? [Internet]. Johner-Institute. 2023. Available from: https://blog.johner-institute.com/regulatory-affairs/mdr-rule-11/ 10. Keutzer L, Simonsson US. Medical Device Apps: An Introduction to Regulatory Affairs for Developers. JMIR MHealth UHealth. 2020;8(6):e17567. 11. Podhaisky HP. Digital Health Technology (DHT) in European Clinical Trials, How to Improve the Status-Quo of the Regulatory Landscape? Ther Innov Regul Sci. 2024;58(4):610–3. 12. Kyhlstedt M. The need for action by evaluators and decision makers in Europe to ensure safe use of medical software. Front Med Technol. 2022;4:1063622. 13. European Federation of Pharmaceutical Industries and Associations (EFPIA). EFPIA Reflection Paper on the Need for Better Defined Regulatory Pathways in the EU for Digital Health Technologies used concomitantly with Medicinal Products or as drug development tools during Clinical Development [Internet]. 2021. Available from: https://www.efpia.eu/media/636454/efpia-rp-digital-health-technologies_november-2021.pdf 14. Medical Device Coordination Group (MDCG). MDCG 2019-11 Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR [Internet]. 2019 [cited 2024 Jun 12]. Available from: https://health.ec.europa.eu/system/files/2020-09/md_mdcg_2019_11_guidance_qualification_classification_software_en_0.pdf 15. Gelis L, Stoeckert I, Podhaisky HP. Digital Tools-Regulatory Considerations for Application in Clinical Trials. Ther Innov Regul Sci. 2023;57(4):769–82. 16. Karakoyun T, Podhaisky HP, Frenz AK, et al. Digital Medical Device Companion (MyIUS) for New Users of Intrauterine Systems: App Development Study. JMIR Med Inform. 2021;9(7):e24633. 17. Eidel O. The MDR Class I Software Situation [Internet]. OpenRegulatory. 2023. Available from: https://openregulatory.com/mdr-class-i-software-situation/ 18. European Commission, Directorate-General for Health and Food Safety (DG SANTE). EUDAMED - European Database on Medical Devices [Internet]. Available from: https://ec.europa.eu/tools/eudamed/#/screen/search-device 19. European Commission, Directorate-General for Health and Food Safety (DG SANTE). Information Centre EUDAMED [Internet]. Available from: https://webgate.ec.europa.eu/eudamed-help/en/data-exchange.html 20. European Commission. European Medical Device Nomenclature (EMDN) [Internet]. Available from: https://webgate.ec.europa.eu/dyna2/emdn/ 21. European Commission, Directorate-General for Internal Market, Industry, Entrepreneurship and SMEs. Notified bodies - Single Market Compliance Space [Internet]. Available from: https://webgate.ec.europa.eu/single-market-compliance-space/notified-bodies/notified-body-list?filter=legislationId:34,notificationStatusId:1 22. Bundesinstitut für Arzneimittel und Medizinprodukte. DiGA-Verzeichnis [Internet]. Available from: https://diga.bfarm.de/de/verzeichnis 23. Medicines and Healthcare products Regulatory Agency (MHRA). Public Access Registration Database (PARD) [Internet]. Available from: https://pard.mhra.gov.uk/ 24. Agoria, beMedTech. mHealthBELGIUM, Belgian platform for medical mobile applications [Internet]. Available from: https://mhealthbelgium.be/ 25. Lievevrouw E, Marelli L, Van Hoyweghen I. Weaving EU digital health policy into national healthcare practices. The making of a reimbursement standard for digital health technologies in Belgium. Soc Sci Med 1982. 2024;346:116620. 26. Eurostat. Real GDP per capita [Internet]. Available from: https://ec.europa.eu/eurostat/databrowser/product/page/sdg_08_10 27. Eurostat. Population change - Demographic balance and crude rates at national level [Internet]. Available from: https://ec.europa.eu/eurostat/databrowser/product/page/demo_gind__custom_7127262 28. International Organization for Standardization (ISO). Country Codes Collection [Internet]. Available from: https://www.iso.org/obp/ui/#iso:pub:PUB500001:en 29. Medical Device Coordination Group (MDCG). MDCG 2019-5 Registration of legacy devices in EUDAMED [Internet]. 2019. Available from: https://health.ec.europa.eu/system/files/2020-09/md_mdcg_2019_5_legacy_devices_registration_eudamed_en_0.pdf 30. Majcherek D, Hegerty SW, Kowalski AM, et al. Opportunities for healthcare digitalization in Europe: Comparative analysis of inequalities in access to medical services. Health Policy Amst Neth. 2024;139:104950. 31. The European Council and the Council of the European Union. Regulation (EU) 2023/607 of the European Parliament and of the Council of 15 March 2023 amending Regulations (EU) 2017/745 and (EU) 2017/746 as regards the transitional provisions for certain medical devices and in vitro diagnostic medical devices [Internet]. OJ L Mar 15, 2023. Available from: http://data.europa.eu/eli/reg/2023/607/oj/eng 32. Medical Device Coordination Group (MDCG). MDCG 2021-24 Guidance on classification of medical devices [Internet]. 2021. Available from: https://health.ec.europa.eu/document/download/cbb19821-a517-4e13-bf87-fdc6ddd1782e_en?filename=mdcg_2021-24_en.pdf 33. Ben-Menahem SM, Nistor-Gallo R, Macia G, et al. How the new European regulation on medical devices will affect innovation. Nat Biomed Eng. 2020;4(6):585–90. 34. Landesrecht Hamburg, Hanseatisches Oberlandesgericht Hamburg 3. Zivilsenat. Einordnung einer Softwareapplikation für die hautärztliche Behandlung als Medizinprodukt [Internet]. Available from: https://www.landesrecht-hamburg.de/bsha/document/NJRE001563508 35. Ministry of Economy Trade and Industry (METI). Japan Vision for the Medical Device Industry 2024 [Internet]. 2024. Available from: https://www.meti.go.jp/policy/mono_info_service/healthcare/iryou/downloadfiles/pdf/iryoukikisangyouvision2024/Vision_for_the_Medical_Device_Industry_2024.pdf 36. Yu J, Zhang J, Sengoku S. Innovation Process and Industrial System of US Food and Drug Administration-Approved Software as a Medical Device: Review and Content Analysis. J Med Internet Res. 2023;25:e47505. 37. Bini F, Franzò M, Maccaro A, et al. Is medical device regulatory compliance growing as fast as extended reality to avoid misunderstandings in the future? Health Technol. 2023;13(5):831–42. 38. Porter ME, Teisberg EO. How physicians can change the future of health care. JAMA. 2007;297(10):1103–11. 39. Onodera R, Sengoku S. Innovation process of mHealth: An overview of FDA-approved mobile medical applications. Int J Med Inf. 2018;118:65–71. 40. Schmidt L, Pawlitzki M, Renard BY, et al. The three-year evolution of Germany’s Digital Therapeutics reimbursement program and its path forward. NPJ Digit Med. 2024;7(1):139. 41. Van Kessel R, Srivastava D, Kyriopoulos I, et al. Digital Health Reimbursement Strategies of 8 European Countries and Israel: Scoping Review and Policy Mapping. JMIR MHealth UHealth. 2023;11:e49003. 42. BSI Group. Notified Body and UK Approved Body lead times [Internet]. 2024. Available from: https://www.bsigroup.com/siteassets/pdf/en/insights-and-media/insights/brochures/bsi-md-nb-capacity-lead-times-en-gb.pdf 43. Food and Drug Administration (FDA), Center for Devices and Radiological Health. General Wellness: Policy for Low Risk Devices Guidance for Industry and Food and Drug Administration Staff [Internet]. 2019. Available from: https://www.fda.gov/regulatory-information/search-fda-guidance-documents/general-wellness-policy-low-risk-devices 44. Huusko J, Kinnunen UM, Saranto K. Medical device regulation (MDR) in health technology enterprises - perspectives of managers and regulatory professionals. BMC Health Serv Res. 2023;23(1):310. 45. European Commission. EU rules on medical devices and in vitro diagnostics – targeted evaluation [Internet]. Available from: https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/14155-EU-rules-on-medical-devices-and-in-vitro-diagnostics-targeted-evaluation_en Footnotes * As this study pertains to a European regulatory matter, we will use the term MDSW going forward, acknowledging that this is an abstraction, as the definition of this term is not fully aligned with the term Software as Medical Device (SaMD) regularly used by IMDRF and US-FDA for such software. Additional Declarations No competing interests reported. Supplementary Files ImpactofRule11onMDSWTables.pptx Cite Share Download PDF Status: Published Journal Publication published 28 Jan, 2025 Read the published version in Therapeutic Innovation & Regulatory Science → Version 1 posted Editorial decision: Revision requested 14 Oct, 2024 Reviews received at journal 02 Oct, 2024 Reviewers agreed at journal 02 Oct, 2024 Reviewers agreed at journal 26 Sep, 2024 Reviewers invited by journal 04 Sep, 2024 Editor assigned by journal 30 Aug, 2024 Submission checks completed at journal 29 Aug, 2024 First submitted to journal 28 Aug, 2024 You are reading this latest preprint version Research Square lets you share your work early, gain feedback from the community, and start making changes to your manuscript prior to peer review in a journal. As a division of Research Square Company, we’re committed to making research communication faster, fairer, and more useful. We do this by developing innovative software and high quality services for the global research community. Our growing team is made up of researchers and industry professionals working together to solve the most critical problems facing scientific publishing. Also discoverable on Platform About Our Team In Review Editorial Policies Advisory Board Help Center Resources Author Services Accessibility API Access RSS feed Manage Cookie Preferences © Research Square 2026 | ISSN 2693-5015 (online) Privacy Policy Terms of Service Do Not Sell My Personal Information {"props":{"pageProps":{"initialData":{"identity":"rs-4990580","acceptedTermsAndConditions":true,"allowDirectSubmit":false,"archivedVersions":[],"articleType":"Research Article","associatedPublications":[],"authors":[{"id":351559408,"identity":"709ec846-cde0-4a86-be59-108500e6a5d1","order_by":0,"name":"Arndt A Schmitz","email":"","orcid":"","institution":"Bayer AG, Pharmaceuticals R\u0026D","correspondingAuthor":false,"prefix":"","firstName":"Arndt","middleName":"A","lastName":"Schmitz","suffix":""},{"id":351559409,"identity":"1bb0d290-232a-4f68-ad98-098bf5652115","order_by":1,"name":"Miriam Font-Nieves","email":"","orcid":"","institution":"Bayer Hispania, S.L, Sant Joan Despi","correspondingAuthor":false,"prefix":"","firstName":"Miriam","middleName":"","lastName":"Font-Nieves","suffix":""},{"id":351559410,"identity":"86cffbe8-72a8-47d8-a4f2-a8999e1cd214","order_by":2,"name":"Toumani Doucoure","email":"","orcid":"","institution":"Université Paris-Saclay","correspondingAuthor":false,"prefix":"","firstName":"Toumani","middleName":"","lastName":"Doucoure","suffix":""},{"id":351559411,"identity":"c1ac51b1-386f-4017-80be-092b5c3d4632","order_by":3,"name":"Hans-Peter Podhaisky","email":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAZAAAAAyAQMAAABI0h/eAAAABlBMVEX///8AAABVwtN+AAAACXBIWXMAAA7EAAAOxAGVKw4bAAABL0lEQVRIiWNgGAWjYBACA1Qu2wEGNiBk+NhAWIsEihbGmSRpARIMzLx4tJiznz38gXGHTR2/9AG2Bx/K7sjz8R9Lk7bdYZfYL32A8cPHHAwtlj15aRKMZ9IkJPsS2A1nnHtm2CaRdkw690xy4sy+BGbJmdswHXYgx4z5b9thCYMzDGzSvG2HGdsk2Nukc9uYEzcARZh5sWg5/8b4A2Pbfwl7qBb7Nv7jbdKWbfWJ+3FpuZFjIMHYdkDCgAeiJbGNAegwRiBjAw8uLW/MgH5JlpxxhrEd6JfDyUC/JFv2njluDBRpxuqX8zlAh+2w4+fvYT4GDLHDtvP7jxne+LmjWra/h/ngh4+YWsCAsQFMtsH4LKBYcmyAiuPRAkooEMD8AUjY41Q+CkbBKBgFIw0AAKCMa1XJSlUHAAAAAElFTkSuQmCC","orcid":"","institution":"Bayer AG, Pharmaceuticals R\u0026D","correspondingAuthor":true,"prefix":"","firstName":"Hans-Peter","middleName":"","lastName":"Podhaisky","suffix":""}],"badges":[],"createdAt":"2024-08-28 11:08:09","currentVersionCode":1,"declarations":"","doi":"10.21203/rs.3.rs-4990580/v1","doiUrl":"https://doi.org/10.21203/rs.3.rs-4990580/v1","draftVersion":[],"editorialEvents":[{"content":"https://doi.org/10.1007/s43441-025-00747-5","type":"published","date":"2025-01-28T15:58:10+00:00"}],"editorialNote":"","failedWorkflow":false,"files":[{"id":64249355,"identity":"fbf254e4-dd1b-4478-8150-5be8468edab4","added_by":"auto","created_at":"2024-09-10 21:04:47","extension":"png","order_by":1,"title":"Figure 1","display":"","copyAsset":false,"role":"figure","size":127315,"visible":true,"origin":"","legend":"\u003cp\u003e\u003cstrong\u003eOverview of software listed in EUDAMED.\u003c/strong\u003e A, The absolute number of software by regulatory pathway. Blue, on the EU market; orange, no longer placed on the EU market; grey, not intended for the EU market. B, The percentage of software by regulatory pathway (left, MDD; middle, MDR; right, IVDR) and risk class (green, Class I / A; yellow, Class IIa / B; orange, Class IIb / C; red, Class III / D – MDD only).\u003c/p\u003e","description":"","filename":"1.png","url":"https://assets-eu.researchsquare.com/files/rs-4990580/v1/a88bf716dc19aa2af86ebc11.png"},{"id":64249003,"identity":"0983e741-1ba6-4225-bc98-e5332ecdf5cc","added_by":"auto","created_at":"2024-09-10 20:56:47","extension":"png","order_by":2,"title":"Figure 2","display":"","copyAsset":false,"role":"figure","size":90351,"visible":true,"origin":"","legend":"\u003cp\u003e\u003cstrong\u003eGeographic origin of software listed in EUDAMED\u003c/strong\u003e. The number of UDI-DIs per country of manufacturer in A (top left) MDD Class I, B (top right) MDR Class I, and C (bottom left) MDR Class IIa category. EU countries are shown by filled grey bars; non-EU countries are shown by empty bars. Only the top 15 countries per category are shown. D (bottom right), correlation of the number of MDR class I solutions per country with the total GDP of that country, for all 27 EU countries.\u003c/p\u003e","description":"","filename":"2.png","url":"https://assets-eu.researchsquare.com/files/rs-4990580/v1/70c561b2a500418163cc4b8a.png"},{"id":64249354,"identity":"93d8ce24-0a0a-4d31-b39b-e42f7260accf","added_by":"auto","created_at":"2024-09-10 21:04:47","extension":"png","order_by":3,"title":"Figure 3","display":"","copyAsset":false,"role":"figure","size":125625,"visible":true,"origin":"","legend":"\u003cp\u003e\u003cstrong\u003eAnalysis of German and Belgian mobile applications. \u003c/strong\u003eA, The classification of mHealth apps in German (left, n=63) and Belgian (right, n=30) web database. Green, MDD Class I; yellow, MDR Class I; orange, MDR Class IIa; red, MDD Class IIa; and dark blue, other classifications (these two in Belgian only). B, The reclassification of MDD Class I apps in German (left, n=27) and Belgian (right, n=9) web database based on our analyses. Green, can remain Class I under MDR; red, upgrade to at least MDR Class IIa required.\u003c/p\u003e","description":"","filename":"3.png","url":"https://assets-eu.researchsquare.com/files/rs-4990580/v1/0e9a3f64cb7d7802c8e1f348.png"},{"id":64249004,"identity":"1472f80f-2adb-4b6f-a3f7-7b02e8e54093","added_by":"auto","created_at":"2024-09-10 20:56:47","extension":"png","order_by":4,"title":"Figure 4","display":"","copyAsset":false,"role":"figure","size":286151,"visible":true,"origin":"","legend":"\u003cp\u003e\u003cstrong\u003eFeatures of MDSW products and their regulatory classification.\u003c/strong\u003e A, Software functionalities that can (still) be self-certified as Class I under MDR: Communication and health literacy tools, diaries, tools with behavioural suggestions, stress management tools, and tools to provide suggestions for healthy lifestyle. B, Software functionalities that trigger certification as Class IIa or higher under MDR: Any personalized diagnostic or therapeutic functionality, any dose calculation independent of the severity of the medical conditions, or any monitoring function of the physiological state leads to a classification of that software as class IIa solution (or above for more severe conditions). C, Analysis of DiGA and mHealthBelgium data. Detailed comparison of software functionality of MDR Class I vs Class IIa MDSW.\u003c/p\u003e","description":"","filename":"4.png","url":"https://assets-eu.researchsquare.com/files/rs-4990580/v1/e8a0c051495960b68ad85411.png"},{"id":75351472,"identity":"10afa7d1-d5f9-4ac1-9de9-2d6fcbb80b6b","added_by":"auto","created_at":"2025-02-03 16:11:47","extension":"pdf","order_by":0,"title":"","display":"","copyAsset":false,"role":"manuscript-pdf","size":1579737,"visible":true,"origin":"","legend":"","description":"","filename":"manuscript.pdf","url":"https://assets-eu.researchsquare.com/files/rs-4990580/v1/860a7052-cfaa-4aaf-be9b-cf9fc3799439.pdf"},{"id":64249006,"identity":"2becb71c-a8c7-4823-9e4c-527d06a6fd6a","added_by":"auto","created_at":"2024-09-10 20:56:48","extension":"pptx","order_by":0,"title":"","display":"","copyAsset":false,"role":"supplement","size":66240,"visible":true,"origin":"","legend":"","description":"","filename":"ImpactofRule11onMDSWTables.pptx","url":"https://assets-eu.researchsquare.com/files/rs-4990580/v1/09efa9a05bea572cfac67f4a.pptx"}],"financialInterests":"No competing interests reported.","formattedTitle":"Impact of Rule 11 on the European medical software landscape: analysis of EUDAMED and further databases three years after MDR implementation","fulltext":[{"header":"Introduction","content":"\u003cp\u003eMedicine is increasingly supported by software. For example, digital health technology (DHT) such as wearables, sensors, or mobile apps offer novel opportunities to capture patient experiences in real world settings, to assess the impact of different diseases, and to drive therapies. Software that classifies as Medical Device Software (MDSW*) needs to undergo an appropriate regulatory process according to its risk classification.\u003c/p\u003e \u003cp\u003eThe requirements for the life cycle process of Software as Medical Device (SaMD) respectively MDSW are described by the ISO Standard ICE 62304 [1] and are comparable with the requirements for other types of medical devices (MD): Developers of MDSW should identify and assess potential risks throughout the entire lifecycle of the MDSW and implement appropriate measures to mitigate those risks.\u003c/p\u003e \u003cp\u003eFurther guidance on the risk categorization of MDSW is provided by the International Medical Device Regulators Forum (IMDRF) guideline \u0026lsquo;Software as a Medical Device: Possible Framework for Risk Categorization and Corresponding Considerations\u0026rsquo; [2]. Risk-based qualification approaches for MDSW protect the interests of users and consider the impact of a malfunction of this software: While the failure of a software that calculates the dosage of a tumor medication can be life-threatening, the malfunction of a software that, for example, provides dietary advice for obesity is mostly an annoyance for the user.\u003c/p\u003e \u003cp\u003eAccordingly, the latter, low-risk example requires significantly less regulatory scrutiny. In most legal systems the lowest risk category of MDSW can even be put on the market without prior approval of an authority.\u003c/p\u003e \u003cp\u003eIn 2018, US FDA adopted the IMDRF principles for SaMD into the national regulatory landscape when issuing the guidance document titled \u0026lsquo;Software as a Medical Device (SaMD): Clinical Evaluation\u0026rsquo; [3]. In addition, dedicated guidance is provided for software with a low risk profile with limited functionality where FDA does not enforce the law [4] and for software that does not drive the clinical management and is exempted from medical device regulations [5]. Also, Japan and UK did follow the IMDRF approach. While the Japanese categorization concept for medical software is comparable with the US approach [6], for the UK the MHRA currently maintains the risk categorization for MDSW of the former European Medical Device Directive (MDD) [7].\u003c/p\u003e \u003cp\u003eThe introduction of the Regulation (EU) 2017/745 (MDR) [8] superseding the MDD represents a significant change to enact the risk-based qualification approaches for MDSW proposed by the IDMRF into the European regulatory landscape. While the classification Rule 11 of the MDR provides criteria allowing a differentiation of MDSW into four different categories (I, IIa, IIb, III), almost any software characteristic apparently leads to a middle- or high-risk classification [9]. The stringency of Rule 11 has been noted [9\u0026ndash;11] and, while some have welcomed this approach [12], an EFPIA reflection paper on Digital Health Technology provides a concise summary of worries regarding Rule 11:\u003c/p\u003e \u003cp\u003e \u003cem\u003e\u0026lsquo;There is a wide industry concern that Rule 11 could lead to a systematic upgrade from Risk Class I under the MDD to Class IIa under the MDR. For example, a simple software application that is used to help patients with diabetes manage their disease by tracking and trending their food intake, exercise and lifestyle activities, and blood glucose value is a Class I medical device under the MDD but becomes a Class IIa medical device under the MDR.\u003c/em\u003e\u0026rsquo; [13]\u003c/p\u003e \u003cp\u003eAlso, the relevant Medical Device Coordination Group (MDCG) guidance document on the classification of medical devices according to MDR did not solve the issue. In particular, it did not answer the question which MDSW still fall in the lowest risk category in Europe, as it provided only one concrete example for a possible Class I product, a \u0026lsquo;MDSW app intended to support conception by calculating the user\u0026rsquo;s fertility status based on a validated statistical algorithm\u0026rsquo; [14].\u003c/p\u003e \u003cp\u003eThe impact on software companies to launch their products as Class IIa instead of Class I is significant, in particular for a small MedTech company, making development lengthier and costlier: a certified quality management system is needed, and a risk-based design control process must be documented. The clinical evaluation of a Class IIa device typically requires a prospective clinical investigation. Finally, a conformity assessment procedure with a Notified Body (NB) is mandatory [13],[15],[16].\u003c/p\u003e \u003cp\u003eThe substantial change of the classification principle for MDSW compared to the former MDD introduced by Rule 11 has caused considerable discussions within the regulatory community, for example in blog posts [9], [17]. However, we are not aware of any systematic analysis of the actual impact of Rule 11 on the situation of MDSW in Europe. Three years after the implementation of the MDR in 2021, we perform a quantitative and qualitative data analysis of the data for MDSW from publicly available databases such as the European Database on Medical Devices (EUDAMED) to contribute evidence to the ongoing discussion and to develop strategic guidance for developers of MDSW for the European market.\u003c/p\u003e"},{"header":"Materials and Methods","content":"\u003cp\u003eA manual search of the European Database on Medical Devices (EUDAMED) [18] was performed for device type = 'software' and all combinations of the fields \u0026lsquo;applicable legislation\u0026rsquo;, \u0026lsquo;risk class\u0026rsquo;, and \u0026lsquo;status\u0026rsquo;. The number of search results per query was documented.\u003c/p\u003e \u003cp\u003eAll UDI-DIs resulting from selected combinations of search terms were downloaded manually to xls files and used as input for semi-automated data scrapping. Search queries were built and parametrized and one search per UDI-DI was executed on June 25th to 28th, 2024, with each of the available three EUDAMED user interface APIs [19]. The automated search included the UDI-DIs as query parameters. The search results were combined to create an excel-consumable file.\u003c/p\u003e \u003cp\u003eThe above download per UDI-DI included the data field \u0026ldquo;details_2.manufacturer.countryIso2Code\u0026rdquo; for country, \u0026ldquo;details_2.manufacturer.srn\u0026rdquo; for Single Registration Number (SRN), and \u0026ldquo;details_1.cndNomenclatures\u0026rdquo; from which the European Medical Device Nomenclature (EMDN) code was extracted using Excel text formulas and manual polishing. For comparison, V1.1 of the code list (status 2021-09-29) was downloaded from the EMDN website [20]. Further databases utilized included EU\u0026rsquo;s \u0026lsquo;new approach notified and designation information system\u0026rsquo; (NANDO) on NB [21]; the German DiGa directory [22]; the UK MHRA database, PARD [23]; and a Belgium mhealth platform [24] operated by industry associations [25]. Where possible, we also considered the webpages of the manufacturer of the MDSW listed in the German and Belgian databases or downloaded and installed the application to analyze its characteristics.\u003c/p\u003e \u003cp\u003eData were analyzed using standard office software package, Excel. All results are descriptive. There was no statistical analysis planned or performed. Only the correlation between number of MDR Class I UDI-DIs and statistics such as total GDP per EU country (obtained by multiplying the GDP per person [26] with the population size [27]) was fitted linearly and the correlation coefficient r\u003csup\u003e2\u003c/sup\u003e documented as calculated by Excel. Two letter countries codes used in Fig.\u0026nbsp;\u003cspan refid=\"Fig1\" class=\"InternalRef\"\u003e2\u003c/span\u003e are according to ISO 3166-1 [28].\u003c/p\u003e"},{"header":"Results","content":"\u003cp\u003e\u003cstrong\u003e\u003cu\u003eAnalysis of regulatory MD databases EUDAMED, EMDN, NANDO, and PARD\u0026nbsp;\u003c/u\u003e\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eEUDAMED was queried to obtain an overview of all MDSW that have been registered so far on a voluntary basis or because of a serious incident or field safety corrective action reported for a legacy MDSW [29], identifying 2,298 entries. The number of software differs between regulatory pathways (Fig. 1).\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eAlready today, three years after MDR implementation, there are more MDSW under MDR registered than under MDD, IVD, and IVDD combined. We did not find any software under AIMDD (not shown). Close to 95 % of registered MDSW are currently on the EU market. The number of software also differs by risk Class (Fig 1b). While the absolute number of MDR Class I MDSW is significantly larger than the number of MDD Class I MDSW (461 versus 273), their percentage shrinks from 53 % to 35 %. In contrast, more than 90 % of all IVDR software is Class I. There is hardly any Class III MDSW (n = 2, both MDD). Software under IVDD is classified differently, most is \u0026lsquo;general\u0026rsquo; (not shown).\u003c/p\u003e\n\u003cp\u003eTo obtain a more granular picture in an effective and structured manner, EUDAMED\u0026rsquo;s three application programming interfaces were used to \u0026lsquo;scrap\u0026rsquo; information on all MDD Class I, MDR Class I, and MDR Class IIa UDI-DIs, resulting in 1,401 structured data sets. Each of these entries was analyzed for the single registration number, the manufacturer\u0026rsquo;s country, and European medical device nomenclature (EMDN) codes. We then counted the number of MDSW per Class per country (Fig. 2).\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eThe country with the highest number of MDD Class I MDSW retrieved from EUDAMED is Finland (Fig. 2a). Closer inspection revealed that more than half of Finnish MDSW is registered by a single government institution, Oy Apotti Ab, followed by Tietoevry, a multinational publicly traded tech \u0026amp; IT company with more than 10,000 employees (not shown). Among the top 15 countries in each class, one third are non-EU countries, such as the USA, UK, Switzerland, PR China, or South Korea, but not Japan (see Fig. 2a, b, and c). Regarding the Russian Federation (Fig. 2c), all UDI-DIs are registered by the same manufacturer, Medical Technologies Ltd, for the same Basic UDI-DI.\u003c/p\u003e\n\u003cp\u003eThe data on the manufacturers of the MDR Class I MDSW from EUDAMED on all 27 EU countries were used to identify possible patterns behind the data reflecting the impact of economic and industrial policies. However, a series of recent statistics on the digital status of their healthcare systems [30] did not correlate well with the data, neither did the number of NBs, population size, or GDP per capita (data not shown). The only correlation we found was between the total GDP per country and the number of MDSW UDI-DI (r\u003csup\u003e2\u003c/sup\u003e = 0.86, see Fig. 2d). While Germany and France as the two largest economies provide even more medical software than the trendline, Italy and Spain as the next largest economies provide less.\u003c/p\u003e\n\u003cp\u003eWhen analyzing the number of NBs per country, as listed in the NANDO database, we noticed two aspects, the EU also endorses NBs in non-EU countries, such as Turkey or Norway, and the number of NBs certified for MDR differs widely per country: the 49 NBs registered are mostly based in Germany (n=11) and Italy (n=10) while France has only two NBs and Spain one NB (data not shown).\u003c/p\u003e\n\u003cp\u003eFinally, we analyzed the EMDN codes assigned with each listed UDI-DI from EUDAMED.\u003c/p\u003e\n\u003cp\u003e\u003cbr\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTable I: Use of EMDN codes by software listed in EUDAMED.\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003cimg src=\"https://myfiles.space/user_files/58854_b38fc7f3db2c487f/58854_custom_files/img1726001185.png\" width=\"539\" height=\"252\"\u003e\u003c/p\u003e\n\u003cp\u003e\u003cbr\u003e\u003c/p\u003e\n\u003cp\u003eMost entries had exactly one EMDN code listed, a minority up to four. We determined the frequency of EMDN codes for MDD Class I and MDR Class I and Class IIa UDI-DIs listed in EUDAMED (see Table I). While around half of all entries of MDD or MDR class I MDSW are using the EMDN generic group V92 (\u0026lsquo;medical device software not included in other classes\u0026rsquo;), only 15 % of MDR Class IIa MDSW use this code. Most of these higher risk MDSW are using the EMDN group Z11 (\u0026ldquo;bioimaging and radiotherapy instruments (all types)\u0026rdquo;). The EMDN group Y21 (\u0026ldquo;communication and information management aids (all types)\u0026rdquo; is used frequently by MDR Class I MDSW. The EMDN group Z12 (\u0026ldquo;instruments for functional explorations and therapeutic interventions (all types)\u0026rdquo;) is used for a quarter of all entries in each of the three software groups.\u003c/p\u003e\n\u003cp\u003eFor comparison to EUDAMED, we accessed another public government database from outside the EU listing medical devices, UK\u0026rsquo;s MHRA PARD, which is currently only available in a limited beta version. Here a simple search retrieved 373 entries of \u0026lsquo;software\u0026rsquo;, to which 173 different GMDN codes are assigned. Three quarters of the entries were for MDD MDSW, with a distribution to risk classes like the situation in the EU (not shown). However, a further individual assessment of MDSW was not possible here, as PARD does not disclose any specific information on the device itself (e.g., brand name) and therefore does not allow an assignment of an entry to a concrete MDSW.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e\u003cu\u003eAnalysis of specialized MDSW databases DiGa directory and mHealthBELGIUM\u003c/u\u003e\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eNeither EUDAMED nor PARD currently contain any further content description of the medical devices listed, such as the intended use or features of MDSW. We thus searched for further public databases with structured information on medical MDSW to complement our research by a qualitative analysis of the MDSW. We identified two further European databases for MDSW (mobile/web-based apps) that provide information on the intended use and functionality and thus allowing an in-depth analysis of the entries beyond a statistical summary.\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eThe German regulatory authority BfArM hosts the DiGa directory of all patient apps ever reimbursed in Germany, with currently 63 entries [22]. The Belgium platform for mobile applications mHealthBELGIUM [24] currently lists 30 entries. First, we performed a consistency check by comparing their contents to EUDAMED. We noted that around half of DiGAs in the BfArM directory listed an SRN or UDI-DI; while basically all SRN could be confirmed in EUDAMED, around half of UDI-DI were not confirmed by a quick search. Similar results were obtained for mHealthBELGIUM entries (not shown).\u003c/p\u003e\n\u003cp\u003eIn Germany, around half of all DIGA solutions fall in the category of Class I MDSW according to the former MDD or according to the current MDR, and a few more are MDR Class IIa. In Belgium, more than half of all listings are in Class IIa or higher, only one third are in MDD Class I (Fig. 3a).\u003c/p\u003e\n\u003cp\u003eNext, we did a deeper regulatory assessment of all software listed in these two databases. According to our analysis, all current assignments of software to the MDD and MDR risk classes in the two databases are plausible with respect to the intended use and the main functionalities of the MDSW. For example, we did not identify any MDR Class I product with a personalized diagnostic functionality. An analysis of the intended purpose and their functionality of the legacy MDD Class I products according to new MDR rules [8] showed that 74 % (20 of 27) DiGA MDD Class I solutions require a reclassification to at least MDR Class IIa to continue business after the transition period in 2028 [31]. A similar situation is found in Belgium, where also the majority of the listed MDD Class I solutions (56 %, 5 out of 9) require a reclassification to at least MDR Class IIa (Fig. 3b).\u003c/p\u003e\n\u003cp\u003eOur qualitative analysis of the specific characteristics of German and Belgian web based/mobile apps in legacy Class I MDD compared to Class IIa MDR conform MDSW showed that the subgroup of MDSW that can remain in the lowest risk Class I even after the end of the transition phase to the MDR in 2028 is characterized by low-threshold functionality (respectively low medical value) with a focus on health literacy, prevention including lifestyle suggestions, and cognitive behavioural therapy for stress management (Fig. 4a).\u003c/p\u003e\n\u003cp\u003eThen we did a further analysis of these two databases to identify the functionalities of MDR Class I MDSW in comparison with MDR Class IIa products. We grouped the individual features into generic categories and found that the most common features in the Class I are related to \u0026lsquo;Goal Setting and Motivational Support\u0026rsquo;, \u0026lsquo;Cognitive Behavioral Therapy (CBT), Psychoeducation, and Health Literacy\u0026rsquo;, and \u0026lsquo;Health Diaries, Symptom Tracking, and Patient Feedback\u0026rsquo; (Fig. 4c). Any monitoring or personalised diagnostic or therapeutic functionality of MDSW is only found in Class IIa software (Fig. 4b).\u003c/p\u003e\n\u003cp\u003eFinally, to put our findings in the context of the regulatory landscape, we compared the regulatory risk classification concept provided by Rule 11 of the MDR with the IMDRF approach as implemented by FDA. Our analyses showed a discrepancy between these concepts for the categorization of a MDSW as a low-risk device (Table 2).\u003c/p\u003e\n\u003cp\u003e\u003cbr\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTable 2a: IMDRF/ FDA Risk-based qualification approach of SaMD.\u003c/strong\u003e[2]\u003c/p\u003e\n\u003cp\u003e\u003cimg src=\"https://myfiles.space/user_files/58854_b38fc7f3db2c487f/58854_custom_files/img172600118633.png\" width=\"539\" height=\"390\"\u003e\u003c/p\u003e\n\u003cp\u003e\u003cbr\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTable 2b: Regulatory impact assessment of the risk-based qualification approaches for MDSW provided by Rule 11 of the MDR.\u0026nbsp;\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e\u003cimg src=\"https://myfiles.space/user_files/58854_b38fc7f3db2c487f/58854_custom_files/img1726001186.png\" width=\"539\" height=\"535\"\u003e\u003c/strong\u003e\u003cbr\u003e\u003c/p\u003e\n\u003cp\u003e\u003cbr\u003e\u003c/p\u003e\n\u003cp\u003eWhile the FDA offers dedicated and comprehensive guidance documents for this lowest risk category of MDSW: enforcement discretion [4], clinical decision support tools [5], and guidance for wellness apps [43], MDR Rule 11 lacks specific classification criteria for software intended for non-serious health conditions or software that only provides supplementary information to an HCP without driving clinical management. Thus Rule 11 does not provide any equivalent criteria for the classification of low-risk software except the two words \u0026lsquo;any other\u0026rsquo; and the corresponding MDCG document [32] does not provide further clarity here.\u003c/p\u003e"},{"header":"Discussion","content":"\u003cp\u003eBy introducing MDR, the EU aimed \u0026ldquo;to establish a robust, transparent, predictable and sustainable regulatory framework for medical devices which ensures a high level of safety and health whilst supporting innovation\u0026rdquo; [8]. The potential of conflicts among these goals had been already noted by others in the case of high-risk, physical medical devices [33]. A recent decision of a German upper court [34] regarding the proper classification of MDSW according to Rule 11 underlines the significance of the topic and demonstrates its impact on software startups. We analysed the impact of the regulatory change of the MDR on MDSW, with a particular focus on low-risk, Class I solutions, using publicly available databases, as we are not aware of any quantitative and qualitative research regarding this subject.\u003c/p\u003e \u003cp\u003eThough use of EUDAMED is not mandatory yet, already more than 2,000 entries for MDSW are listed. Despite an unknown number of MDSW on the market not registered in EUDAMED, we are confident that the assessment of more than 2,000 entries allow some fundamental conclusions about the impact of Rule 11 of the MDR: Our result clearly show that the main regulatory classification of MDSW in Europe shifted after the implementation of the MDR from Class I MD to Class IIa. 53% of the MDD conform entries for MDSW in EUDAMED fall in the lowest risk category of a Class I MD while only 35% of the MDR conform entries fall in that category (Fig.\u0026nbsp;1b). This can be interpreted as the intended effect of the policy to ensure a higher safety level, but it also significantly increases the burden for manufactures to market such software in Europe: to launch a Class IIa MD in Europe a certified quality management system, substantial clinical evidence, and a conformity assessment procedure by a NB becomes mandatory while Class I MD can be marketed based on a self-declaration of conformity.\u003c/p\u003e \u003cp\u003eWe next analyzed detailed data on around 1,400 MDD class I, and MDR Class I and IIa entries that we were able to automatically extract from EUDAMED via data scrapping. The MDR also \u0026lsquo;aims to ensure the smooth functioning of the internal market\u0026rsquo; and \u0026lsquo;to facilitate trade\u0026rsquo; with non-EU countries [8]. We therefore analysed the geographic distribution of manufacturers and found a good correlation with total GDP per EU country. While global including Asian economies are well represented on the EU market, we noted an absence of Japanese companies among the top manufactures. This is matching the Japanese Ministry of Economy, Trade and Industry\u0026rsquo;s recent advice to industry to consider the US market as particularly important for global expansion and economic returns, due to its size, growth rate, and technological leadership [35].\u003c/p\u003e \u003cp\u003eSimilar to Yu \u003cem\u003eet al.\u003c/em\u003e [36] who analysed the OpenFDA database to understand the US MDSW landscape, we extracted further info from EUDAMED in form of EMDN codes. Half of all Class I MDSW is self-declared in the generic group V92 (\u0026lsquo;medical device software not included in other classes\u0026rsquo;), while in Class IIa, where NBs are involved, only each sixth solution is in this group. In contrast, more than half of all Class IIa solutions are in group Z11, bioimaging and radiotherapy instruments, indicating that their features typically trigger this medium risk classification. The emerging potential of EUDAMED as a data resource for research is yet to be appreciated by the community. Only Bini \u003cem\u003eet al.\u003c/em\u003e consulted EUDAMED for each EMDN code they identified being relevant for medical software, with a focus on Extended Reality applications. Also, in their analysis around half of the software used the V category [37].\u003c/p\u003e \u003cp\u003eThe wide use of the generic coded for class I MDSW significantly diminishes the values of the database. In addition, EUDAMED lacks critical information on MDSW such as the specific intended purpose, intended user, main functionality, technical platforms, or reimbursement status in EU member states and there is no search option to easily identify MDSW for indications or to differentiate between MDSW for HCPs vs. laymen.\u003c/p\u003e \u003cp\u003eIn theory, more specific EMDN codes could be defined. EDMS codes allow for 2.6\u0026nbsp;billion combinations of which fewer than 9,000 have been defined [20]. UK\u0026rsquo;s PARD database uses GMDN codes which includes only 100,000 possible and offers subcategories that distinguishes between lay users and HCP-targeted software, for example code 62169 (\u0026lsquo;Wireless patient monitor/sensor reporting software, layperson-use\u0026rsquo;) and 65832 (\u0026lsquo;Wireless patient monitor/sensor reporting software, professional-only\u0026rsquo;). However, as the GMDN system is not publicly available, a further analysis was not possible here.\u003c/p\u003e \u003cp\u003eWe believe a more intuitive enhancement of EUDAMED would be to create mandatory data fields for the intended use and main functionality of MDSW. This aligns with the existing transparency for higher-classified products, where manufacturers provide summaries of clinical safety and performance. The benefits clearly outweigh the additional administrative burden.\u003c/p\u003e \u003cp\u003eMobile medical applications or web-based MDSW are innovative solutions with significant potential to enhance care delivery. The opportunity to obtain structured data at patient level offers the promise to realize the vision of value-based healthcare [38]. This has generated interest in various approaches realized in the USA [39], Germany [40], Belgium [25] and internationally concerning reimbursement strategies [41].\u003c/p\u003e \u003cp\u003eConsidering the limitations of EUDAMED described above, we identified two specialized databases for medical apps that provide information on the intended use and the functionalities in a systematic manner: the German DiGa directory of patient apps reimbursed in Germany, with currently 63 entries [22] and the Belgium platform for mobile applications mHealthBELGIUM [24] currently covering 30 entries with Apps for patients and/or HCPs, provide information on the intended purpose of the MDSW and allowed an in-depth analysis.\u003c/p\u003e \u003cp\u003eIn Germany, almost all DiGa solutions are classified as MDD Class I or MDR Class I, with a few in MDR Class IIa. In Belgium, over half are Class IIa or higher, while only one-third are MDD Class I (Fig.\u0026nbsp;3a). Furthermore, we found the categorization of all MDSW by MDD or MDR criteria to be reasonable across both examined databases. A closer look at the MDSW that are currently classified as MDD Class I solutions in DIGA and mHealthBELGIUM demonstrated the significant impact of classification Rule 11: an analysis of the intended use and the functionality disclosed that 74% of German (20 of 27) and 56% of Belgium (5 of 9) of MDD class I solutions have to be up classified to a Class IIa product, at the latest after the end of the transition period to the MDR in 2028 [31]. If a substantial change is made to this software, this may be necessary even earlier, as the validity of the self-certification according to MDD will then expire. These data confirm our findings from Fig.\u0026nbsp;1b, that the transition from MDD to MDR causes a shift of the per-default classification of MDSW in Europe from Class I to Class IIa. The risk for patients is, that these current MDD Class I products may not be available after the MDR transition period deadline in 2028 [31], pending certification by an NB, or will be withdrawn from the market by manufacturers not able or willing to invest significant efforts into a conformity assessment procedure for a software that is per se characterized by limited medical value.\u003c/p\u003e \u003cp\u003eOur analysis reveals the typical profile of a MDR conform Class I MDSW in comparison to the functionalities of a Class IIa product (Fig.\u0026nbsp;4a, Fig.\u0026nbsp;4b, and Fig.\u0026nbsp;4c). MDSW classified as Class I according to MDR is limited to software functions covering \u0026lsquo;Goal Setting and Motivational Support\u0026rsquo;, \u0026lsquo;Cognitive Behavioral Therapy (CBT), Psychoeducation, and Health Literacy\u0026rsquo;, and \u0026lsquo;Health Diaries, Symptom Tracking, and Patient Feedback\u0026rsquo;. We hope that this information provides more clarity to developers about the character of MDR Class I conform software, as the relevant MDCG guidance paper only mentions a MDSW to support conception as potential use case for a Class I product.\u003c/p\u003e \u003cp\u003eThe addition of any personalized therapeutic or diagnostic functionality to a MDSW, including those for harmless medical conditions, however, leads directly to a Class IIa product (Fig.\u0026nbsp;4c), for which a conformity assessment procedure with an NB must be carried out. Interestingly, a NB recently published their lead times for assessments indicating that in practise several additional months waiting time must be added to an already lengthy process [42].\u003c/p\u003e \u003cp\u003eAn in-depth regulatory analysis of MDR Rule 11 reveals possible reasons for our observations and shows the differences between the regulatory landscape in Europe and the US (Table\u0026nbsp;\u003cspan refid=\"Tab2\" class=\"InternalRef\"\u003e2\u003c/span\u003ea,b). The foundational concept of IMDRF for categorizing the risk of Software as a Medical Device (SaMD) is rooted in evaluating its intended use and functionality. This involves assessing the severity of the medical condition and aligning it with the significance of the software's information in healthcare decision-making, while also considering the potential impact of software malfunction (please see Table \u003cspan refid=\"Tab2\" class=\"InternalRef\"\u003e2\u003c/span\u003e) [43]. The US-FDA did not only adopt this concept but also provides further detailed guidance for software of the lowest risk category: the FDA does not \u0026lsquo;enforce\u0026rsquo; the regulatory oversight for certain software \u0026lsquo;that provide or facilitate supplemental clinical care\u0026rsquo; including some simple medical calculators [4], exempts software from MD regulations that \u0026lsquo;provides a healthcare professional (HCP) with evidence-based tools to support HCP decision-making but does not replace or direct the judgment of the HCP by directing them to a specific action\u0026rsquo; [5], and provides guidance for wellness apps \u0026lsquo;that promote a healthy lifestyle\u0026rsquo; [43].\u003c/p\u003e \u003cp\u003eIn contrast, the MDR only partially adopted a risk-based categorization approach for MDSW in Europe, lacking clear classification criteria for low-risk software solutions as outlined by the IMDRF (Table\u0026nbsp;\u003cspan refid=\"Tab2\" class=\"InternalRef\"\u003e2\u003c/span\u003ea). The relevant classification Rule 11 can be divided into three subsections providing criteria for an assignment of MDSW to a low, moderate, or high-risk category (Class I, IIa, IIb, III) (Table\u0026nbsp;\u003cspan refid=\"Tab2\" class=\"InternalRef\"\u003e2\u003c/span\u003eb).\u003c/p\u003e \u003cp\u003eThe granularity of the criteria in Rule 11 for risk classification of software is significantly less pronounced than in the corresponding IMDRF/US guidelines. Any type of therapeutic or diagnostic purpose, regardless of the severity of the medical situation or the level of knowledge of the user of the software, leads to classification as a moderate-risk device Class IIa, or higher. A strict interpretation of Rule 11 may classify simple medical calculators, like creatinine clearance and even BMI calculators, as Class IIa MDSW. For the classification as low-risk Class I, Rule 11 gives the vague reference \u0026lsquo;all other\u0026rsquo;, without mentioning a concrete criterion. Also, the MDCG guidance [32] document does not provide further clarity for the Class I category here.\u003c/p\u003e \u003cp\u003eOur research suggests a strategy for European manufacturers to address this situation for fast and affordable market access. Maintaining a low-risk classification while at the same time providing a relevant medical benefit to ensure reimbursement can be achieved by developing a MDSW compatible with a MDR Class I self-certification as shown in Fig.\u0026nbsp;4a. For example, a tool with a preventive character can certainly provide a relevant medical benefit, as our analysis of the DiGA list demonstrated. A potential viable long-term strategy for a manufacturer could be to first launch a low-risk Class I product as a self-certified minimal viable product, gather clinical evidence in real-world conditions with the marketed product, and subsequently introduce a more developed solution that has undergone a conformity assessment by a Notified Body. Such a guidance might be appreciated by small and medium enterprises who regard MDR as a burden [44], in particular start-ups.\u003c/p\u003e \u003cp\u003eWhile certainly EU legislators wrote Rule 11 with good intent to protect citizen from malfunctioning software, our analysis suggests that this strict classification may inadvertently hinder innovation and slow down access for patients and healthcare providers to new software solutions. To foster innovation in Europe, we hope that the current public consultation process by EU on future MDR revisions currently in preparation [45] will introduce clearer criteria for MDSW risk classification. The current blanket classification of diagnostic and therapeutic software as Class IIa does not accurately reflect their often-marginal risk. Within the frame of the current legislation, a revision of the MDCG guidance document [32] and the provision of concrete use case for a class I MDSW classification under the MDR Rule 11 would be helpful. Complementarly, a European equivalent to FDA guidance documents for low-risk software, clinical decision support tools, or for their policy for wellness app would be appreciated. These measures would enable the full implementation of IMDRF principles for MDSW into the European regulatory landscape, provide precise guidance for manufacturers for the European Union market, and drive global harmonization resulting in better access to innovative therapies.\u003c/p\u003e"},{"header":"Abbreviations","content":"\u003cp\u003eAPI, Application Programming Interface\u003c/p\u003e\n\u003cp\u003eDiGa, Digitale Gesundheitsanwendung (regulated patient app reimbursed by German statutory health insurance)\u003c/p\u003e\n\u003cp\u003eEUDAMED, European database on medical devices\u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;\u003c/p\u003e\n\u003cp\u003eFDA, US Food and Drug Administration\u003c/p\u003e\n\u003cp\u003eFDCA, US Federal Food, Drug, and Cosmetic Act\u003c/p\u003e\n\u003cp\u003eGDP, gross domestic product\u003c/p\u003e\n\u003cp\u003e\u0026nbsp;IMDRF, International Medical Device Regulators Forum\u003c/p\u003e\n\u003cp\u003eMD, Medical Device\u0026nbsp;\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eMDD, Medical Device Directive\u003c/p\u003e\n\u003cp\u003eMDR, Medical Device Regulation (EU) 2017/745\u003c/p\u003e\n\u003cp\u003eMDSW, Medical Device Software\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eMHRA, (UK) Medicines and Healthcare products Regulatory Agency\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eNB, notified body\u003c/p\u003e\n\u003cp\u003eSaMD, Software as medical device\u003c/p\u003e\n\u003cp\u003eUDI-DI, unique device identification device identifier\u003c/p\u003e"},{"header":"Declarations","content":"\u003cp\u003e\u003cu\u003eFunding statement\u003c/u\u003e\u003c/p\u003e\n\u003cp\u003eAll authors are currently employed by legal entities of the multinational enterprise Bayer. T.D. is also student at Universit\u0026eacute; Paris-Saclay, Orsay, France.\u003c/p\u003e\n\u003cp\u003e\u003cu\u003eConflict of Interest statement\u003c/u\u003e\u003c/p\u003e\n\u003cp\u003eAll authors are currently employed by legal entities of the multinational enterprise Bayer. A.A.S. and H.P.P. also hold stocks of Bayer AG. The views expressed in this article are the personal views of the authors and may not be understood or quoted as being made on behalf of or reflecting the position of the institutions with which the authors are affiliated.\u003c/p\u003e\n\u003cp\u003e\u003cu\u003eAuthor contributions (mandatory) for all authors\u0026nbsp;\u003c/u\u003e\u003c/p\u003e\n\u003cp\u003eA.A.S. and H.P.P. contributed substantially to the conception, designing, and drafting the work. All co-authors contributed substantially to the acquisition, analysis, and interpretation of data for the work and to revising the work critically for important intellectual content. All gave final approval of the version to be published and agreed to be accountable for all aspects of the work in ensuring that questions related to the accuracy or integrity of any part of the work are appropriately investigated and resolved.\u003c/p\u003e\n\u003cp\u003e\u003cu\u003eData availability statement\u003c/u\u003e\u003c/p\u003e\n\u003cp\u003eDownloads from EUDAMED are available upon request.\u003c/p\u003e\n\u003cp\u003e\u003cu\u003eAcknowledgements\u003c/u\u003e\u003c/p\u003e\n\u003cp\u003eWe would like to thank our colleague Kai Uwe Rieger for help with data scrapping and our colleague Nicolas Bertrand for critically reading a draft of the manuscript.\u0026nbsp;\u003c/p\u003e"},{"header":"References","content":"\u003cp\u003e\u003cem\u003eNew references added, \u0026ldquo;available from\u0026rdquo; and \u0026ldquo;[internet]\u0026rdquo; will be removed after all comments for finalization.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003e1. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;International Organization for Standardization (ISO). ISO/IEC\u0026nbsp;62304:2006 (en), Medical device software\u0026nbsp;\u0026mdash; Software life cycle processes [Internet]. Available from: https://www.iso.org/obp/ui/en/#iso:std:iec:62304:ed-1:v1:en\u003c/p\u003e\n\u003cp\u003e2. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;International Medical Device Regulators Forum (IMDRF). \u0026ldquo;Software as a Medical Device\u0026rdquo;: Possible Framework for Risk Categorization and Corresponding Considerations [Internet]. 2012. Available from: https://www.imdrf.org/sites/default/files/docs/imdrf/final/technical/imdrf-tech-140918-samd-framework-risk-categorization-141013.pdf\u003c/p\u003e\n\u003cp\u003e3. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;Food and Drug Administration (FDA), Center for Devices and Radiological Health. Software as a Medical Device (SAMD): Clinical Evaluation Guidance for Industry and \u0026nbsp;Food and Drug Administration Staff [Internet]. 2017. Available from: https://www.fda.gov/regulatory-information/search-fda-guidance-documents/software-medical-device-samd-clinical-evaluation\u003c/p\u003e\n\u003cp\u003e4. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;Food and Drug Administration (FDA), Center for Devices and Radiological Health, Center for Biologics Evaluation and Research. Policy for Device Software Functions and Mobile Medical Applications [Internet]. 2022. Available from: https://www.fda.gov/regulatory-information/search-fda-guidance-documents/policy-device-software-functions-and-mobile-medical-applications\u003c/p\u003e\n\u003cp\u003e5. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;Food and Drug Administration (FDA), Center for Devices and Radiological Health, Center for Biologics Evaluation and Research, et al. Clinical Decision Support Software, Guidance for Industry and Food and Drug Administration Staff [Internet]. 2022. Available from: https://www.fda.gov/regulatory-information/search-fda-guidance-documents/clinical-decision-support-software\u003c/p\u003e\n\u003cp\u003e6. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;Aoyagi Y. Updated Regulatory Strategies for Innovative Medical Devices in Japan [Internet]. 2017. Available from: https://www.mhlw.go.jp/content/11123000/000335171.pdf\u003c/p\u003e\n\u003cp\u003e7. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;Medicines and Healthcare products Regulatory Agency (MHRA). Guidance: Medical device stand-alone software including apps (including IVDMDs) v1. 10f [Internet]. 2023. Available from: https://assets.publishing.service.gov.uk/media/64a7d22d7a4c230013bba33c/Medical_device_stand-alone_software_including_apps__including_IVDMDs_.pdf\u003c/p\u003e\n\u003cp\u003e8. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;The European Council and the Council of the European Union. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, amending Directive 2001/83/EC, Regulation (EC) No 178/2002 and Regulation (EC) No 1223/2009 and repealing Council Directives 90/385/EEC and 93/42/EEC [Internet]. OJ L Apr 5, 2017. Available from: http://data.europa.eu/eli/reg/2017/745/oj/eng\u003c/p\u003e\n\u003cp\u003e9. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;Gerhart M. MDR Classification Rule 11: The classification nightmare? [Internet]. Johner-Institute. 2023. Available from: https://blog.johner-institute.com/regulatory-affairs/mdr-rule-11/\u003c/p\u003e\n\u003cp\u003e10. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;Keutzer L, Simonsson US. Medical Device Apps: An Introduction to Regulatory Affairs for Developers. JMIR MHealth UHealth. 2020;8(6):e17567.\u003c/p\u003e\n\u003cp\u003e11. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;Podhaisky HP. Digital Health Technology (DHT) in European Clinical Trials, How to Improve the Status-Quo of the Regulatory Landscape? Ther Innov Regul Sci. 2024;58(4):610\u0026ndash;3.\u003c/p\u003e\n\u003cp\u003e12. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;Kyhlstedt M. The need for action by evaluators and decision makers in Europe to ensure safe use of medical software. Front Med Technol. 2022;4:1063622.\u003c/p\u003e\n\u003cp\u003e13. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;European Federation of Pharmaceutical Industries and Associations (EFPIA). EFPIA Reflection Paper on the Need for Better Defined Regulatory Pathways in the EU for Digital Health Technologies used concomitantly with Medicinal Products or as drug development tools during Clinical Development [Internet]. 2021. Available from: https://www.efpia.eu/media/636454/efpia-rp-digital-health-technologies_november-2021.pdf\u003c/p\u003e\n\u003cp\u003e14. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;Medical Device Coordination Group (MDCG). MDCG 2019-11 Guidance on Qualification and Classification \u0026nbsp; of Software in Regulation (EU) 2017/745 \u0026ndash; MDR \u0026nbsp; and Regulation (EU) 2017/746 \u0026ndash; IVDR [Internet]. 2019 [cited 2024 Jun 12]. Available from: https://health.ec.europa.eu/system/files/2020-09/md_mdcg_2019_11_guidance_qualification_classification_software_en_0.pdf\u003c/p\u003e\n\u003cp\u003e15. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;Gelis L, Stoeckert I, Podhaisky HP.\u0026nbsp;Digital Tools-Regulatory Considerations for Application in Clinical Trials. Ther Innov Regul Sci. 2023;57(4):769\u0026ndash;82.\u003c/p\u003e\n\u003cp\u003e16. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;Karakoyun T, Podhaisky HP, Frenz AK, et al. Digital Medical Device Companion (MyIUS) for New Users of Intrauterine Systems: App Development Study. JMIR Med Inform. 2021;9(7):e24633.\u003c/p\u003e\n\u003cp\u003e17. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;Eidel O. The MDR Class I Software Situation [Internet]. OpenRegulatory. 2023. Available from: https://openregulatory.com/mdr-class-i-software-situation/\u003c/p\u003e\n\u003cp\u003e18. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;European Commission, Directorate-General for Health and Food Safety (DG SANTE). EUDAMED - European Database on Medical Devices [Internet]. Available from: https://ec.europa.eu/tools/eudamed/#/screen/search-device\u003c/p\u003e\n\u003cp\u003e19. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;European Commission, Directorate-General for Health and Food Safety (DG SANTE). Information Centre EUDAMED [Internet]. Available from: https://webgate.ec.europa.eu/eudamed-help/en/data-exchange.html\u003c/p\u003e\n\u003cp\u003e20. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;European Commission. European Medical Device Nomenclature (EMDN) [Internet]. Available from: https://webgate.ec.europa.eu/dyna2/emdn/\u003c/p\u003e\n\u003cp\u003e21. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;European Commission, Directorate-General for Internal Market, Industry, Entrepreneurship and SMEs. Notified bodies - Single Market Compliance Space [Internet]. Available from: https://webgate.ec.europa.eu/single-market-compliance-space/notified-bodies/notified-body-list?filter=legislationId:34,notificationStatusId:1\u003c/p\u003e\n\u003cp\u003e22. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;Bundesinstitut f\u0026uuml;r Arzneimittel und Medizinprodukte. DiGA-Verzeichnis [Internet]. Available from: https://diga.bfarm.de/de/verzeichnis\u003c/p\u003e\n\u003cp\u003e23. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;Medicines and Healthcare products Regulatory Agency (MHRA). Public Access Registration Database (PARD) [Internet]. Available from: https://pard.mhra.gov.uk/\u003c/p\u003e\n\u003cp\u003e24. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;Agoria, beMedTech. mHealthBELGIUM, Belgian platform for medical mobile applications [Internet]. Available from: https://mhealthbelgium.be/\u003c/p\u003e\n\u003cp\u003e25. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;Lievevrouw E, Marelli L, Van Hoyweghen I. Weaving EU digital health policy into national healthcare practices. The making of a reimbursement standard for digital health technologies in Belgium. Soc Sci Med 1982. 2024;346:116620.\u003c/p\u003e\n\u003cp\u003e26. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;Eurostat. Real GDP per capita [Internet]. Available from: https://ec.europa.eu/eurostat/databrowser/product/page/sdg_08_10\u003c/p\u003e\n\u003cp\u003e27. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;Eurostat. Population change - Demographic balance and crude rates at national level [Internet]. Available from: https://ec.europa.eu/eurostat/databrowser/product/page/demo_gind__custom_7127262\u003c/p\u003e\n\u003cp\u003e28. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;International Organization for Standardization (ISO). Country Codes Collection [Internet]. Available from: https://www.iso.org/obp/ui/#iso:pub:PUB500001:en\u003c/p\u003e\n\u003cp\u003e29. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;Medical Device Coordination Group (MDCG). MDCG 2019-5 Registration of legacy devices in EUDAMED [Internet]. 2019. Available from: https://health.ec.europa.eu/system/files/2020-09/md_mdcg_2019_5_legacy_devices_registration_eudamed_en_0.pdf\u003c/p\u003e\n\u003cp\u003e30. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;Majcherek D, Hegerty SW, Kowalski AM, et al. Opportunities for healthcare digitalization in Europe: Comparative analysis of inequalities in access to medical services. Health Policy Amst Neth. 2024;139:104950.\u003c/p\u003e\n\u003cp\u003e31. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;The European Council and the Council of the European Union. Regulation (EU) 2023/607 of the European Parliament and of the Council of 15\u0026nbsp;March 2023 amending Regulations (EU)\u0026nbsp;2017/745 and (EU)\u0026nbsp;2017/746 as regards the transitional provisions for certain medical devices and in vitro diagnostic medical devices [Internet]. OJ L Mar 15, 2023. Available from: http://data.europa.eu/eli/reg/2023/607/oj/eng\u003c/p\u003e\n\u003cp\u003e32. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;Medical Device Coordination Group (MDCG). MDCG 2021-24 Guidance on classification of medical devices [Internet]. 2021. Available from: https://health.ec.europa.eu/document/download/cbb19821-a517-4e13-bf87-fdc6ddd1782e_en?filename=mdcg_2021-24_en.pdf\u003c/p\u003e\n\u003cp\u003e33. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;Ben-Menahem SM, Nistor-Gallo R, Macia G, et al.\u0026nbsp;How the new European regulation on medical devices will affect innovation. Nat Biomed Eng. 2020;4(6):585\u0026ndash;90.\u003c/p\u003e\n\u003cp\u003e34. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;Landesrecht Hamburg, Hanseatisches Oberlandesgericht Hamburg 3. Zivilsenat. Einordnung einer Softwareapplikation f\u0026uuml;r die haut\u0026auml;rztliche Behandlung als Medizinprodukt [Internet].\u0026nbsp;Available from: https://www.landesrecht-hamburg.de/bsha/document/NJRE001563508\u003c/p\u003e\n\u003cp\u003e35. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;Ministry of Economy Trade and Industry (METI). Japan Vision for the Medical Device Industry 2024 [Internet]. 2024. Available from: https://www.meti.go.jp/policy/mono_info_service/healthcare/iryou/downloadfiles/pdf/iryoukikisangyouvision2024/Vision_for_the_Medical_Device_Industry_2024.pdf\u003c/p\u003e\n\u003cp\u003e36. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;Yu J, Zhang J, Sengoku S. Innovation Process and Industrial System of US Food and Drug Administration-Approved Software as a Medical Device: Review and Content Analysis. J Med Internet Res. 2023;25:e47505.\u003c/p\u003e\n\u003cp\u003e37. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;Bini F, Franz\u0026ograve; M, Maccaro A, et al. Is medical device regulatory compliance growing as fast as extended reality to avoid misunderstandings in the future? Health Technol. 2023;13(5):831\u0026ndash;42.\u003c/p\u003e\n\u003cp\u003e38. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;Porter ME, Teisberg EO. How physicians can change the future of health care. JAMA. 2007;297(10):1103\u0026ndash;11.\u003c/p\u003e\n\u003cp\u003e39. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;Onodera R, Sengoku S. Innovation process of mHealth: An overview of FDA-approved mobile medical applications. Int J Med Inf. 2018;118:65\u0026ndash;71.\u003c/p\u003e\n\u003cp\u003e40. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;Schmidt L, Pawlitzki M, Renard BY, et al.\u0026nbsp;The three-year evolution of Germany\u0026rsquo;s Digital Therapeutics reimbursement program and its path forward. NPJ Digit Med. 2024;7(1):139.\u003c/p\u003e\n\u003cp\u003e41. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;Van Kessel R, Srivastava D, Kyriopoulos I, et al. Digital Health Reimbursement Strategies of 8 European Countries and Israel: Scoping Review and Policy Mapping. JMIR MHealth UHealth. 2023;11:e49003.\u003c/p\u003e\n\u003cp\u003e42. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;BSI Group. Notified Body and UK Approved Body lead times [Internet]. 2024. Available from: https://www.bsigroup.com/siteassets/pdf/en/insights-and-media/insights/brochures/bsi-md-nb-capacity-lead-times-en-gb.pdf\u003c/p\u003e\n\u003cp\u003e43. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;Food and Drug Administration (FDA), Center for Devices and Radiological Health. General Wellness: Policy for Low Risk Devices Guidance for Industry and Food and Drug Administration Staff [Internet]. 2019. Available from: https://www.fda.gov/regulatory-information/search-fda-guidance-documents/general-wellness-policy-low-risk-devices\u003c/p\u003e\n\u003cp\u003e44. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;Huusko J, Kinnunen UM, Saranto K. Medical device regulation (MDR) in health technology enterprises - perspectives of managers and regulatory professionals. BMC Health Serv Res. 2023;23(1):310.\u003c/p\u003e\n\u003cp\u003e45. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;European Commission. EU rules on medical devices and in vitro diagnostics \u0026ndash; targeted evaluation [Internet]. Available from: https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/14155-EU-rules-on-medical-devices-and-in-vitro-diagnostics-targeted-evaluation_en\u003c/p\u003e"},{"header":"Footnotes","content":"\u003cp\u003e* As this study pertains to a European regulatory matter, we will use the term MDSW going forward, acknowledging that this is an abstraction, as the definition of this term is not fully aligned with the term Software as Medical Device (SaMD) regularly used by IMDRF and US-FDA for such software.\u003c/p\u003e"}],"fulltextSource":"","fullText":"","funders":[],"hasAdminPriorityOnWorkflow":false,"hasManuscriptDocX":true,"hasOptedInToPreprint":true,"hasPassedJournalQc":"","hasAnyPriority":false,"hideJournal":false,"highlight":"","institution":"","isAcceptedByJournal":true,"isAuthorSuppliedPdf":false,"isDeskRejected":"","isHiddenFromSearch":false,"isInQc":false,"isInWorkflow":false,"isPdf":false,"isPdfUpToDate":true,"isWithdrawnOrRetracted":false,"journal":{"display":true,"email":"[email protected]","identity":"therapeutic-innovation-and-regulatory-science","isNatureJournal":false,"hasQc":true,"allowDirectSubmit":false,"externalIdentity":"tirs","sideBox":"Learn more about [Therapeutic Innovation \u0026 Regulatory Science](https://link.springer.com/journal/43441)","snPcode":"43441","submissionUrl":"https://www.editorialmanager.com/tirs/default.aspx","title":"Therapeutic Innovation \u0026 Regulatory Science","twitterHandle":"","acdcEnabled":true,"dfaEnabled":true,"editorialSystem":"em","reportingPortfolio":"Springer Hybrid","inReviewEnabled":true,"inReviewRevisionsEnabled":false},"keywords":"DHT, DiGa, MDR, MDSW, Regulatory Strategy, SaMD","lastPublishedDoi":"10.21203/rs.3.rs-4990580/v1","lastPublishedDoiUrl":"https://doi.org/10.21203/rs.3.rs-4990580/v1","license":{"name":"CC BY 4.0","url":"https://creativecommons.org/licenses/by/4.0/"},"manuscriptAbstract":"\u003ch2\u003eIntroduction:\u003c/h2\u003e \u003cp\u003eMedicine is increasingly supported by software, with digital health technologies offering innovative ways to capture insights and drive therapies. Globally, medical device software must follow regulatory processes based on risk classification. The introduction of MDR represents a significant shift in risk-based qualification for Medical Devices in Europe, including classification Rule 11 for software, which has caused significant discussions among European regulators.\u003c/p\u003e\u003ch2\u003eMaterials and Methods\u003c/h2\u003e \u003cp\u003eThree years after implementation, we conducted a systematic impact assessment of MDR classification Rule 11 for MDSW through a qualitative and quantitative analysis of over 2,000 software entries from the European Medical Device database, complemented by data from other public databases such as the German DiGa directory and mHealthBELGIUM.\u003c/p\u003e\u003ch2\u003eResults and Discussion\u003c/h2\u003e \u003cp\u003eOur results indicate a shift of the per-default classification of MDSW in Europe after the implementation of the MDR: while most of legacy software in EUDAMED falls in the lowest risk category as MDD Class I (53%), the situation reverses for the MDR conform entries with the most entries in Class IIa (55%). Analyzing the legacy MDD patient apps in Germany implies that three quarters will have to re-classify as MDR Class IIa at the end of the transition period in 2028. A comparison of the European and US regulatory landscapes, along with a systematic review of software features for Class I vs. Class IIa products, explains our findings and enables us to recommend a regulatory strategy for developing MDSW compliant with MDR Class I rules, ensuring fast access to the European market.\u003c/p\u003e","manuscriptTitle":"Impact of Rule 11 on the European medical software landscape: analysis of EUDAMED and further databases three years after MDR implementation","msid":"","msnumber":"","nonDraftVersions":[{"code":1,"date":"2024-09-10 20:56:43","doi":"10.21203/rs.3.rs-4990580/v1","editorialEvents":[{"type":"communityComments","content":3},{"type":"decision","content":"Revision requested","date":"2024-10-14T15:37:40+00:00","index":"","fulltext":""},{"type":"editorInvitedReview","content":"","date":"2024-10-02T08:46:28+00:00","index":"hide","fulltext":""},{"type":"reviewerAgreed","content":"73791644178452690740771651280322596928","date":"2024-10-02T07:53:25+00:00","index":"hide","fulltext":""},{"type":"reviewerAgreed","content":"89192245899772854358461444806455194998","date":"2024-09-27T02:52:02+00:00","index":"hide","fulltext":""},{"type":"reviewersInvited","content":"","date":"2024-09-04T14:17:15+00:00","index":"","fulltext":""},{"type":"editorAssigned","content":"","date":"2024-08-30T13:14:16+00:00","index":"","fulltext":""},{"type":"checksComplete","content":"","date":"2024-08-29T06:35:56+00:00","index":"","fulltext":""},{"type":"submitted","content":"Therapeutic Innovation \u0026 Regulatory Science","date":"2024-08-28T11:06:43+00:00","index":"","fulltext":""}],"status":"published","journal":{"display":true,"email":"[email protected]","identity":"therapeutic-innovation-and-regulatory-science","isNatureJournal":false,"hasQc":true,"allowDirectSubmit":false,"externalIdentity":"tirs","sideBox":"Learn more about [Therapeutic Innovation \u0026 Regulatory Science](https://link.springer.com/journal/43441)","snPcode":"43441","submissionUrl":"https://www.editorialmanager.com/tirs/default.aspx","title":"Therapeutic Innovation \u0026 Regulatory Science","twitterHandle":"","acdcEnabled":true,"dfaEnabled":true,"editorialSystem":"em","reportingPortfolio":"Springer Hybrid","inReviewEnabled":true,"inReviewRevisionsEnabled":false}}],"origin":"","ownerIdentity":"3e7a3bcf-836f-413a-ab2a-0cec20a4c31a","owner":[],"postedDate":"September 10th, 2024","published":true,"recentEditorialEvents":[],"rejectedJournal":[],"revision":"","amendment":"","status":"published-in-journal","subjectAreas":[],"tags":[],"updatedAt":"2025-02-03T16:07:04+00:00","versionOfRecord":{"articleIdentity":"rs-4990580","link":"https://doi.org/10.1007/s43441-025-00747-5","journal":{"identity":"therapeutic-innovation-and-regulatory-science","isVorOnly":false,"title":"Therapeutic Innovation \u0026 Regulatory Science"},"publishedOn":"2025-01-28 15:58:10","publishedOnDateReadable":"January 28th, 2025"},"versionCreatedAt":"2024-09-10 20:56:43","video":"","vorDoi":"10.1007/s43441-025-00747-5","vorDoiUrl":"https://doi.org/10.1007/s43441-025-00747-5","workflowStages":[]},"version":"v1","identity":"rs-4990580","journalConfig":"researchsquare"},"__N_SSP":true},"page":"/article/[identity]/[[...version]]","query":{"redirect":"/article/rs-4990580","identity":"rs-4990580","version":["v1"]},"buildId":"_2-kVJe1T_tPrBINL-cwx","isFallback":false,"isExperimentalCompile":false,"dynamicIds":[84888],"gssp":true,"scriptLoader":[]}