Medical device software regulations in the EU and US

Software-based medical devices are integral to healthcare. To enter the marketplace, a company must successfully navigate and comply with applicable national and international regulatory requirements. Medical device software is bound by regulatory requirements and constraints to ensure the medical devices will not harm patients. The EU and the US are significant markets for medical devices and the two largest global bodies responsible for issuing and managing medical device regulations. Bringing medical device software, hardware, and mobile medical device apps to market requires successful navigation of the EU CE Marking and US Food and Drug Administration (FDA) approval processes.

Software devices should be developed for efficacy, safety, and security. The efficacy of the device is effective in achieving the claims that are made for its intended use. Safety of the device does not expose the patient, user, or other bystanders to undue risk from its use. Safety includes the potentially exposed public, not just the patient, and includes environmental issues and the potential effect on other medical devices. Security of the device should be designed to protect patients, users, and bystanders from both unintentional and malicious misuse of the devices. The EU and US FDA have paid a lot of attention to cybersecurity and interoperability in recent years with the high growth of wireless devices, use of the internet, and remote monitoring.

The foundational medical device software standard is the IEC 62304, Medical device software – Software life cycle processes. The standard describes the software development life cycle (SDLC) process, requisite activities, and deliverables are necessary for the development of software applications within the design control program. The SDLC provides a foundation to implement a given 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 wide variety of ways to structure the overall framework and to document the process in procedures, inputs, activities, and outputs.

The software life cycle (SLC) process is embedded within the design control program for the continuous development and maintenance of software products. The design and development of medical device software are being driven by the medical device software design standard EN/IEC 62304, which has been adopted by the EU and US FDA. The basic requirements of design and the safety classification are driven by the device’s intended use and classification of risk. The logical standard allows for developing safety critical and high-reliability software for medical devices and tends to harmonize the quality expectations between Europe and the United States. IEC 62304 was created specifically for medical device software, though many elements are foundational to any robust software development process.

• IEC 62304 expects the use of ISO 14971
• EU MDR expects software development to use “state of the art” methods and follow IEC 62304 and EN ISO 14971
• FDA expects software to fall under design controls but has a number of acts and guidance to reduce the burden
• ISO/TR 80002-1 describes the application of ISO 14971 to software:
  • Software in itself is not a potential hazard (i.e., contact with software cannot cause harm or injury)
  • The software may, however, cause someone to be exposed to a hazardous situation
• Must manage cybersecurity risks

Current environments by regulatory agencies, including the US FDA, Competent Authorities, or the EU Commission are continually evolving and changing. There are many different software applications that are used in the medical and healthcare industry that are regulated as medical devices, but many more ancillary products that are not regulated. With the prolific use of software applications, electronic resources, and internet “in the cloud” applications, this has caused some difficulty from a regulatory standpoint to determine regulatory boundaries of these software applications. Reviewing the definition of a medical device clearly shows that a product or device must diagnose, monitor, or provide therapy 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 health or safety of a patient from the results or information they provide.

In relation to a product providing diagnosis or therapy of a patient, it is understood that computer hardware, software applications, and embedded firmware must be reviewed for any ancillary or external effect that may be applied from the use of the software. Clearly, software that is running and managing an infusion pump device would be considered a medical device either integrated into the infusion pump or separate software that controls the infusion pump. Another example is software that is used to take CT scan data that is then analyzed by software to provide the healthcare professional additional information that may not be readily available by only visual review of a CT scan by a healthcare provider. Lower-risk products could include wellness software applications that may monitor the activity of a patient like the number of steps per day or keep a diary for weight loss goals. The US FDA has released various guidance documents detailing different software applications that are either loaded directly on a device or used as stand-alone software applications. While these provide examples of various software as medical devices and not as medical devices, there are still many in the grey area of interpretation as a medical device.

US FDA primarily focuses on the regulation being applied to a product based on the indications for use or claims that is made for the device. Indications for use or intended use describes how the product is used, mode of action, operational functionality, where the product is used, anatomical location, and patient population. There often is a relationship between the indications for use and claims because these often are a statement made for what the product can do or provide to the patient, i.e., statements made on labeling, product brochures, or physician information. Any indications or claims must be supported by the safety and performance of medical devices through design controls, verification, validation, performance testing, and/or clinical testing. This can be difficult to apply for a software-only product because the impact or ancillary effect to the patient must be considered, as well as what information is being presented to the healthcare provider. If the data, results, or patient health information is used by a health care provider to act, begin therapy, or stop therapy for a patient has a risk, then software applications may be regulated as a medical device with a classification based on the risk of the device. RAPS.org