Software devices must be developed for efficacy, safety and security. The effectiveness of the device is effective in achieving the claims made for its intended use. The safety of the device ensures that its use does not expose patients, users or other bystanders to undue risk. Safety includes the potentially exposed public as well as the patient, and includes environmental concerns and potential impacts on other medical devices. Device security must be designed to protect patients, users, and bystanders from unintentional and malicious device misuse. The EU and US FDA have paid much attention to cybersecurity and interoperability in recent years with the rapid growth of wireless devices, Internet usage, and remote monitoring.
The basic medical device software standard is IEC 62304. Medical Device Software – Software Life Cycle ProcessThe standard describes the software development life cycle (SDLC) processes, required activities, and deliverables required for the development of software applications within a design management program. An SDLC provides a foundation for implementing a particular software development methodology (or model) within a structure that maintains objective evidence of software product efficacy and safety. There are myriad ways to structure and document the SDLC, and many different ways to structure the overall framework and document the process of procedures, inputs, activities, and outputs.
Software Life Cycle (SLC) processes are incorporated into design management programs for the ongoing development and maintenance of software products. The design and development of medical device software is driven by the medical device software design standard EN/IEC 62304, adopted by the EU and US FDA. Basic design requirements and safety classification are determined by the intended use and risk classification of the device. Logical standards enable the development of safety-critical and reliable software for medical devices and tend to harmonize quality expectations between Europe and the United States. Although IEC 62304 was written specifically for medical device software, many factors underlie a robust software development process.
- IEC 62304 assumes 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
- The FDA expects software to be under design control, but there are many acts and guidance to ease the burden.
- ISO/TR 80002-1 describes the application of ISO 14971 to software.
- The software itself is not potentially dangerous (that is, contact with the software will not cause harm or injury).
- However, software can expose someone to dangerous situations.
- You need to manage cybersecurity risks
The current environment by regulatory bodies, including the US FDA, competent authorities, or EU Commissions, is constantly evolving and changing. While there are various software applications used in the medical and healthcare industry that are regulated as medical devices, there are many more ancillary products that are not regulated. The massive use of software applications, electronic resources, and Internet “in-the-cloud” applications makes it difficult to determine the regulatory boundaries of these software applications from a regulatory perspective. A review of the medical device definition clearly indicates that the product or device must diagnose, monitor, or treat human patients. This poses difficulties for many medical devices that are software-only applications. This is because, although we do not interact directly with patients, the results and information provided may affect their health and safety.
Computer hardware, software applications, and embedded firmware, in connection with products that provide patient diagnosis or treatment, must be reviewed for ancillary or external influences that may apply from the use of the software. is understood. Clearly, software that runs and manages an infusion pump device is considered a medical device, either integrated with the infusion pump or separate software that controls the infusion pump. Another example is the software used to acquire CT scan data. This software provides the healthcare professional with additional information that is analyzed by the software and may not be readily available from the healthcare provider’s visual review of her CT scan alone. Low-risk products may include wellness software applications that monitor patient activity, such as steps taken per day, or keep a diary for weight loss goals. The US FDA has released various guidance documents detailing various software applications that may be loaded directly onto devices or used as stand-alone software applications. These give examples of various software as medical devices rather than as medical devices, but there is still much software in the gray area of interpretation as medical devices.
The U.S. FDA primarily focuses on regulations that apply to products based on indications of use or claims made against the device. Indications for use or intended use describe how the product is used, mechanism of action, operational features, where the product is used, anatomical location, and number of patients. There is often a relationship between instructions for use and claims. Because these are statements about what the product does or can provide to patients: labels, product brochures, or physician information statements. Indications or claims must be supported by medical device safety and performance through design controls, verification, validation, performance testing, and/or clinical trials. Applying this to software-only products can be difficult. This is because of the need to consider patient impact and collateral effects, as well as information presented to healthcare providers. When data, results, or patient health information is used by a healthcare provider to act, initiate treatment, or discontinue treatment because the patient is at risk, the software application identifies medical devices in risk-based classifications. may be regulated as of the device.
See how Sterling Medical Devices helps clients develop medical device software.
Carrie Hetrick is Director of Regulatory and Clinical Operations at Sterling Medical Devices.