Software can have different applications in healthcare, with many benefits for healthcare systems, physicians, and patients. Qualifying and classifying medical software and applying the appropriate regulatory requirements is important to ensure quality and safety. This article describes and compares the requirements for market entry of medical device software in the EU and US, based on the different applications and intended use that software can have in healthcare. The article examines the EU Medical Devices Regulation (EU MDR; 2017/745), the European regulation applicable to medical devices, and the Medical Device Coordination Group (MDCG) guidelines for medical device software in the EU. The Federal Food, Drug, and Cosmetic Act (FD&C Act), the US Code, Title 21, and the US Food and Drug Administration (FDA) guidelines applicable to medical device software are examined for the regulatory framework applicable in US.
Introduction
Software can collect, store, process, and elaborate multiple input data from different sources to generate output data and results. Software is used in the healthcare system to:
- Perform diagnosis using image analysis for making treatment decisions;
- Rank therapeutic suggestions for a health care professional based on patient history, test results, and patient characteristics; and
- Analyze a user’s heartbeat, detect abnormalities, and inform a physician via a mobile app.
Medical mobile applications can also be extensively used in clinical trials. In these trials, mobile apps can monitor remote participants to ensure the effectiveness and safety of the investigational therapy, reducing the number of onsite follow-up visits.
Medical software is essential for reducing costs, time, and resources while supporting healthcare professionals and patients. This software will continue to evolve and further improve the delivery of healthcare services. In terms of cost efficiency, AI tools can automate nearly 45% of administrative tasks in the healthcare sector, amounting to annual savings of $150 billion. The percentage of physicians using digital health tools increased from 85% in 2016 to 93% in 2022. Key factors influencing a physician’s decision to use digital health tools were cost efficiency and improved clinical outcomes for the patients.
The increased application of software in healthcare in general is necessary and unavoidable. It is necessary to regulate the medical device software and apply an adequate regulatory pathway for its authorization and market entry. Regulatory requirements are important in ensuring medical software’s quality and safety before placing the product on the market to reduce any risk for patients. This article analyzes and compares two important regulatory frameworks: the EU and the US.
Medical device software in the EU (European Union)
Under the EU Medical Devices Regulation (EU MDR; 2017/745), a medical device is defined as any product with a medical intended purpose and is used on human beings. The term medical intended purpose includes “diagnosis, monitoring, treatment of any disease or modification into the human body of a physiological process or of the human anatomy.” According to the EU MDR, the primary distinction between a medical device and a medicinal product is that a medical device cannot achieve its principal intended action by pharmacological, immunological, or metabolic means. However, it may be assisted in its function by such means. A software with a medical purpose is included in the definition of a medical device and is defined under the EU framework as medical device software (MDSW).
The EU MDR was published in May 2017, replacing the previous legislation and introducing increased requirements, efforts, and resources for obtaining the CE mark of conformity for all medical devices, including software. The CE mark of conformity is a symbol required for all medical devices in the EU. It ensures that devices comply with the applicable requirements based on the EU MDR and that they are safe and perform as the manufacturer intended. Under the EU MDR, the CE mark of conformity is required before placing a medical device in the EU market. Although software is widely used in healthcare, not all software can be considered a medical device. The European Commission has published software guidance (MDCG 2019-11) to clarify the qualification of software as an MDSW (Figure 1).
The EU MDR requirements must be applied for software to qualify as an MDSW and be placed on the European market.4 These requirements depend on the risk-based classification of the medical device software as described in the EU MDR classification Rule 11 (Figure 2)
Rule 11 was introduced specifically for software. Under the previous EU legislation, all medical device software was classified under Class I, the lowest-risk class. The process to obtain the CE mark is faster for Class I software and can be done by the manufacturer without the intervention of an external regulatory body.
Under Rule 11, most medical device software was reclassified into higher-risk classes (Class IIa, Class IIb, or Class III), for which the conformity assessment is longer and complex, and an external regulatory body – the notified body – is required to assess the compliance and the safety of the device. Considering that much medical device software generates data for supporting diagnoses or therapies, most of it is classified in higher-risk classes, resulting in a longer conformity assessment process and, therefore, a longer time to market.
Finally, the EU MDR introduced specific requirements (EU MDR, Annex I, Section 17) that apply to medical device software and must be considered during the software development and after the market entry, in particular:
- Software must ensure repeatability, reliability, and performance in line with their intended use;
- Software development must consider lifecycle and risk management, including information security, verification, and validation;
- Software used in combination with mobile platforms must be designed considering the specific features of the platform; and
- Software development must include safety measures, including protection against unauthorized access.
Medical device software must comply with all these requirements to obtain the CE mark of conformity and reach the market.
In addition to the EU MDR, one must consider that an MDSW may manage a patient’s private personal data. For this reason, the software development process must consider the requirements of the EU’s General Data Protection Regulation (GDPR) on protections regarding the processing and free movement of personal data. Personal data can include any information or data collected or elaborated by the software relating to a living individual who can be identified from those data (e.g., name, address, contact information, health data, medical treatments, face images).
Under the GDPR, data processing performed by the software must be transparent for the user, who must have access to their personal data and be able to decide at will when to erase the data or request to update them. The software must manage these personal data only for the specific medical purpose of the software and not for any other scope. The software must also have appropriate measures to ensure the security and integrity of the personal data and protection against unauthorized access.
In addition, the software must include informed consent. Before collecting the patient’s personal data, the software must display or provide a privacy policy, and the patient or user must confirm that they consent to the collection of their data. The privacy policy should include at least the type of personal data collected, how the data will be used and for how long, and any limitations on the data. If the data are going to be provided to third-party services, then the privacy policy must address how the user can access, control, verify, correct, or delete the data.
Software as a medical device in the US (United States)
In the US, SaMD is the abbreviation used to define medical device software. According to the FD&C Act, a medical device is defined as any article intended for a medical purpose (such as diagnosis, treatment, or prevention) in human beings or to modify the structure of the body, and which does not achieve its primary intended use through any pharmacological action in the body. Unlike the EU MDR, the US medical device definition does not explicitly mention the word “software.” The FDA refers to the International Medical Device Regulators Forum, which defines SaMD as “software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device.” Therefore, for software to be qualified as a medical device by the FDA, it must have a medical purpose and must be standalone software that is not integrated into equipment or hardware.
The FDA has also issued guidance to support the qualification of software as a medical device.
Based on this guidance, software can be qualified as aa SaMD if it:
- Modifies or processes the received medical data and is not limited to the display of the received data;
- Provides a specific clinical decision and not just a recommendation or option; and
- Provides information that the healthcare professional can use to make a medical decision.
The software can be qualified as a medical device and is subject to the FDA requirements if all the above conditions are met. The FDA guidance provides many examples of software qualified as medical devices that can be consulted by manufacturers that are subject to the FD&C Act. These include software that acquires, processes, or analyzes health data such as signal acquisition systems, in vitro diagnostics results, x-ray or magnetic resonance imaging, parameters monitoring, signal acquisition systems, and continuous signals/patterns. It also includes software that provides risk scores, probabilities, or time-critical outputs for specific diseases and conditions. According to the FD&C Act, SaMD must be classified according to the FDA’s medical device classification system and is subject to FDA oversight based on the assigned classification (Table).
In addition, the US regulatory pathway requires that the definition of the intended use of the medical device software be predetermined from the beginning, which determines its risk classification, different applicable requirements and controls, and the type of FDA premarket application required.
The FDA also issued another important guidance to clarify and support the preparation of the documents to be submitted to the FDA for premarket notification (for Class II SaMD) or for premarket approval (for Class III SaMD). The required documentation depends on the SaMD’s risk. Enhanced documentation should be provided for any premarket submission that includes device software where a failure could present a probable risk of death or serious injury of users or patients. Basic documentation should be provided where there is no serious health risk to patients or users. Basic documentation includes the software description, risk analysis, software requirements, its architecture, and the software version history. Enhanced documentation is more detailed and includes information about each design phase, the test protocols conducted on the software, and the passing testing results.
Finally, specific software requirements must be considered in medical device software development. In particular, medical devices connected to the internet, hospital networks, and other medical devices pose increased cybersecurity risks that must be prevented or mitigated as much as possible. Cybersecurity risks must be included in the risks analysis throughout the SaMD lifecycle and not only during development.
Manufacturers are also required to keep and update a software maintenance process (including changes implementation), a configuration management process (i.e., a unique identification of configuration items, versions, and change control), and a process for software problem resolution (i.e., problem reporting, investigation, trends, and resolution). All these requirements must be met in the premarket phase and maintained after the market entry and throughout the SaMD lifecycle.
Conclusion
Software in healthcare can have many different applications in diagnosis, therapy, and patient monitoring, providing tangible benefits for patients, physicians, and healthcare systems. Medical device software must be regulated and follow the appropriate requirements to ensure their safety and quality. Regulatory requirements should not be considered as a barrier to market entry but rather as an opportunity to ensure the performance of the software. Manufacturers must consider the applicable regulatory requirements from the beginning because compliance with those requirements is required for the marketing authorization needed to enter the market. Including the regulatory requirements at the early stages of design and development can simultaneously ensure compliance and timely market entry, whereas implementing those same requirements at the later stages of product development could require product changes and a design review, resulting in additional resources and delayed market entry.
Abbreviations
CE, conformité Européene; EU MDR, European Medical Devices Regulation EU 2017/745; FDA, US Food and Drug Administration; FD&C Act, Federal Food, Drug, and Cosmetic Act; GDPR, General Data Protection Regulation; MDSW, medical device software; SaMD, software as medical device.
REFERENCE: Regulatory Focus (RF Today; JRA – Journal of Regulatory Affairs); 26 AUG 2026