Medical device software regulations in the European Union and the United States

Software based medical devices are an integral part of healthcare. To enter the market, a company must successfully navigate and comply with applicable national and international regulatory requirements. Medical device software adheres to regulatory requirements and constraints to ensure that medical devices do not harm patients. The European Union and the United States are important markets for medical devices and are the two largest global bodies responsible for regulating and administering medical devices. Bringing medical device software, hardware, and mobile medical device applications to market requires successful navigation of the EU CE marking and US Food and Drug Administration (FDA) approval processes.

Software devices must be developed for effectiveness, integrity, and security. Device effectiveness is effective in achieving the claims made for its intended use. Do not expose the safety of the patient, user, or other bystanders to undue risk from its use. Safety includes people who are potentially at risk, not just the patient, and includes environmental issues and potential impact on other medical devices. Device security must be designed to protect patients, users, and bystanders from unintentional and malicious misuse of devices. The EU and US FDA have paid great attention to cybersecurity and interoperability in recent years with the high growth of wireless devices, Internet use, and remote monitoring.

The Foundation Medical Device Program standard is IEC 62304, Medical Device Software – Software Lifecycle Operations. The standard describes the Software Development Lifecycle (SDLC) process, required activities, and deliverables necessary to develop software applications within a design control program. The SDLC provides a basis for implementing a particular software development methodology (or model) within a structure that will maintain objective evidence of the effectiveness and safety of software products. There are countless ways to structure and document an SDLC, and a variety of ways to structure the overall framework and document the process into procedures, inputs, activities, and outputs.

The Software Lifecycle (SLC) process is embedded in software design control for the continuous development and maintenance of software products. Medical device software is designed and developed by the EN/IEC 62304 medical device software design standard, which has been approved by the European Union and the US Food and Drug Administration. The basic design requirements and safety rating depend on the device’s intended use and hazard rating. The rationale allows the development of safety-critical, high-reliability programs for medical devices and tends to align quality expectations between Europe and the United States. IEC 62304 was created specifically for medical device software, although many elements are central to any robust software development process.

  • IEC 62304 expects to use ISO 14971
  • The EU MDR expects software development to use “state of the art” methods and to follow IEC 62304 and EN ISO 14971
  • The Food and Drug Administration (FDA) expects software to fall under design controls but has a number of procedures and directives to reduce the burden
  • ISO/TR 80002-1 describes the application of ISO 14971 to software:
    • The software itself does not present a potential danger (eg, contact with the software cannot cause damage or injury)
    • However, the software may cause someone to get into a dangerous situation
  • Cybersecurity risks must be managed

The current environments for regulatory agencies, including the US Food and Drug Administration, competent authorities, or the European Union Commission are constantly evolving and changing. There are many different software applications that are used in the medical field and healthcare industry that are regulated as medical devices, but there are many additional products that are not regulated. With the heavy use of software applications, electronic resources and Internet applications “in the cloud”, this has caused some difficulty from an organizational point of view to define regulatory boundaries for these software applications. A review of the definition of a medical device clearly states that a product or device must diagnose, monitor, or provide treatment for a human patient. This causes difficulty for many medical devices that are software-only applications because while they do not interact directly with the patient, they may affect the patient’s health or safety from the results or information they provide.

In connection with a product that provides diagnosis or treatment to a patient, it is understood that the computer hardware, software applications and embedded firmware should be reviewed for any additional or external effect that may apply from the use of the software. It is clear that the software that operates and manages the infusion pump device is a medical device that is either integrated with the infusion pump or a separate program that controls the infusion pump. Another example is the software used to take CT scan data which is then analyzed by the software to provide the healthcare professional with additional information that may not be readily available by only visual review of a CT scan by the healthcare provider. Low-risk products could include wellness software apps that might monitor a patient’s activity such as the number of steps per day or keep a diary of weight-loss goals. The US Food and Drug Administration (FDA) has released several guidance documents detailing different software applications that can be downloaded directly to a device or used as standalone software applications. While these examples provide examples of various software as medical devices rather than as medical devices, there are still many in the gray area of ​​interpretation as a medical device.

The FDA primarily focuses on the regulations that apply to a product based on indications for use or claims made for the device. Indications for use or intended use describe how the product is to be used, mode of action, operational function, where the product is used, anatomical location, and number of patients. There is often a relationship between indications for use and claims because they are often a statement of what a product can do or do for a patient, for example, statements made on labels, product pamphlets, or physician information. Any indications or claims of safety and performance of medical devices must be supported by design controls, verification, validation, performance testing, and/or clinical testing. It can be difficult to apply for a software product solely because the additional effect or impact for the patient must be considered, in addition to the information being provided to the healthcare provider. If a patient’s health data, outcomes, or information is used by a healthcare provider to act, initiate treatment, or stop treatment for a patient, the Software Applications may be organized as a medical device with a risk-based classification of the device.

Learn more about how Sterling Medical Devices helps customers Medical device software development.

Carrie Hetrick is Director of Regulatory and Clinical Affairs for Sterling Medical Devices

Leave a Comment