The term Software as a Medical Device is defined by the International Medical Device Regulators Forum (IMDRF) as, "software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device." Software clearly needs hardware to run on, but in this case that hardware is general purpose platforms, such as a PC, mobile device or server. The software can process the output (ex: radiology images) from a medical device as long as it is not part of the device (i.e. necessary to achieve the device's intended purpose). SaMD cannot drive a medical device - that software is considered part of the device. But it can interface with the device.
Overall, the regulatory requirements for a SaMD follow the same requirements as a traditional medical device, but without the electro-mechanical part, and a few SaMD specifics. The sections below summarize the key elements of the SaMD submission.
The definition statement is where you, the manufacturer, state the intended Medical Purpose of your SaMD. Is it to Treat or Diagnose? Is it driving clinical management or informing clinical management. What is the significance of the information the SaMD provides to a healthcare decision? What is the state of the situation/condition? Critical? Serious? Non-serious?
From this information the risk is categorized into four levels, with category IV being highest impact, and I being lowest. The chart below describes how how these categories are established:
This categorization establishes the risks associated with the SaMD and the scrutiny of the design controls and clinical evaluation in the submission.
The risk management process follows ISO 14971 with the software specifics defined in IEC 62304. As for all software for medical devices, identification of software that could contribute to a hazardous situation must be analyzed. What would a bug in the critical part of the software potentially cause? Could the software be misused in a way that would be dangerous? What would be the consequences of unexpected behavior of 3rd party libraries (SOUP)? These are the types of questions the analysis should be asking to determine the risks. Risk control measures can be applied to reduce the risk, and proof of verification of these measures needs to be provided.
Cybersecurity is a big part of the SaMD risk management because of the connectivity generally provided, and the general purpose nature of the platforms on which they run. The FDA has a comprehensive draft (at time of writing) premarket guidance for the "recommendations" of the agency around the Cybersecurity. It has been our experience that these are requirements, and indeed a major focus of the FDA in submissions. With the number of hospitals getting attacked, it is no wonder that the FDA wants to make sure the devices are not vectors of attacks, and SaMD is no exception. Cybersecurity threat modeling and risk analysis, as well as thorough descriptions the design controls used to address the risks is required.
Cloud software cybersecurity can and should be certified for any vendor used. SOC2, HiTrust, or ISO 27001 certification ensures the cloud security design and processes are in place to safeguard information.
For medical devices, quality management system requirements are generally pretty clear to manufacturers. But with the introduction of SaMD and its closeness to general non-regulated health apps, it sometimes gets lost to the SaMD provider that the Quality Management Principals must be applied. IEC 13485 provides the regulatory requirements of medical device quality management systems, and its implications to the organization and lifecycle processes must be followed. ISO 13485 certification of your software provider ensures that indeed the principals and controls are in place.
Clinical Evaluation includes the proposed association between a SaMD output and a Clinical Condition. What evidence, research, literature, data analysis and clinical trials support the assertions? This is followed up by the proof of performance, showing the accuracy, reliability and precision of the results, along with the clinical validation displaying that the output data achieves the intended purpose in the context of clinical care.
Evidence demonstrating a clinical association, with analytical and clinical validation must be provided. We have seen startups swayed by claims by providers (ex: blood pressure measurements using a mobile video camera), but without supporting data proving the claim, it will not get through the regulators.
SaMD often provides a pathway for post-market continuous improvements leveraging real-work performance data. Changes in the clinical evaluation or definition may necessitate a new 510k.
Regulators are grappling with AI/ML. To ensure patient safety, typically only "locked" algorithms have been accepted - learning stops before final test and production. But the regulators do recognize that adaptive/continual learning when post-market is incredibly powerful and has the ability to be transformative. A total product lifecycle (TPLC) approach is being considered by the FDA. After publishing a framework for review, they recently drafted an Action Plan to address Artificial Intelligence and Machine Learning. They plan to update their proposed framework and issue guidance on Predetermined Change Control - How the machine learning algorithm will change through learning while remaining safe and effective. Harmonization of Good Machine Learning Practice (GMLP) will be encouraged describing the set of best practices. Regulatory science efforts to develop methodologies for improvements that can identify and eliminate bias will be supported. And overall a Patient-centered approach will be necessitated. Stay tuned.