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 for implementing 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 critical safety 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, although many elements are fundamental 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 (ie, 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 continuously 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 gray 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 describe how the product is used, mode of action, operational functionality, where the product is used, anatomical location, and patient population. There is often 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, ie, 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.
Learn more about how Sterling Medical Devices helps clients with medical device software development.
Carrie Hetrick is director of regulatory and clinical affairs at Sterling Medical Devices