As the digital revolution continues to transform healthcare, the role of software in medical devices has become increasingly significant and created further complexities within regulatory definitions and treatment. Last week, I attended a Software as a Medical Device (SaMD) course organized by the Regulatory Affairs Professionals Society (RAPS). This course, led by experts Michelle Jump from MedSec, LLC, and Pat Baird from Philips and including multiple guest speakers from the FDA, provided deep insights into the regulatory landscape of SaMD. Here, I share some of my takeaways from the course, focusing on regulatory pathways, cybersecurity, AI, and the use of cloud environments.
Understanding SaMD: The Basics
SaMD refers to software intended for medical purposes without being part of a hardware medical device. For example, an app that analyzes ECG readings to diagnose heart conditions may qualify as SaMD. However, the software running the ECG machine likely does not, as it primarily drives the hardware device.
Identifying whether your software is considered a SaMD and, if so, its risk classification are initial steps to understanding how to handle your software’s regulatory path to market.
It is helpful to highlight a few definitions taken from the FDA that can be found here.
- Device: an instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including a component part, or accessory, which is, among other criteria, intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease in man.
- Function: a distinct purpose of the product, which could be the intended use or a subset of the intended use of the product.
The FDA’s Digital Health Center of Excellence (DHCoE) has generated an online tool, the Digital Health Policy Navigator, to help users classify their software per US regulations. It provides an interactive overview of digital health policies that may apply to your product’s software functions.
The FDA separates Software Functions into three categories.
- Device Software Functions: software functions that meet the definition of a device and are subject to requirements of the FD&C Act.
- Subject to Enforcement Discretion: software functions that meet the definition of Device Software Functions but are a low enough risk that the FDA does not intend to enforce the requirements of the FD&C Act.
- Not a Device: Software functions that do not meet the definition of a device and are not subject to the requirements of the FD&C Act.
It is important to note that software often contains multiple functions, which may be a mixture of qualifying as device software functions and not. In this case, only the qualifying portions are treated as SaMD, but the FDA assesses the impact of non-device functions on the device function under review. Controlling and updating these two portions of your software with different processes is possible. Still, it is incumbent on the developer to determine if the benefits of this flexibility justify the added complexity of multiple control systems.
The FDA’s Multiple Function Device Products Guidance provides further insight.
Global SaMD Regulations
The general concepts related to SaMD are similar across jurisdictions; however, understanding the differences that do exist is crucial for developers aiming to market their products globally:
- Australia: The TGA oversees Australia’s regulations, which generally align with those of the EU. However, Australia adjusts the risk scenario to account for whether data is provided directly to the patient or a health care provider, resulting in a lower risk classification. Additionally, Australia utilizes an Exempt classification, similar to the US’s Enforcement Discretion designation, except it is a formal, legislated classification that a subset of SaMD requirements still applies to.
- Canada: Similar to the US, Canada’s regulations for SaMD, overseen by Health Canada, classify software based on the risk associated with its functions. However, Health Canada treats predictive functions differently, emphasizing the potential harm from incorrect information.
- European Union: The European Union’s regulations for SaMD, governed by the Medical Device Regulation (MDR), emphasize usability issues and classify software based on potential risks similar to the US. However, specific consideration needs to be taken regarding the labeling and definition of the device importer and distributor, particularly for SaMDs distributed as apps.
- UK: The UK’s regulations for SaMD, overseen by the Medicines and Healthcare products Regulatory Agency (MHRA), align closely with the EU’s MDR.
- Other Countries briefly discussed with SaMD regulations include Brazil, Japan, Singapore, and South Korea.
Cybersecurity: A Critical Component
Cybersecurity is a critical aspect of all software today, including SaMD. For SaMD, a comprehensive security risk management plan is essential, encompassing a security risk management report, periodic testing, and adherence to guidelines for cryptographic algorithms. Aligning with IEC 81001-5-1 is crucial for ensuring the global acceptance of your SaMD. Although the FDA does not require the use of IEC 81001-5-1, it is accepted by the FDA and mandated by most other jurisdictions.
In the US, the 2023 Consolidated Appropriations (“Omnibus”) Act introduced Section 524B, “Ensuring Cybersecurity of Devices,” into the FD&C Act, transforming previous FDA cybersecurity guidance into firm regulatory requirements. This legislative change has prompted the FDA to enforce stricter reviews of SaMD cybersecurity measures.
Unique concerns for the FDA include managing end-of-support dates for software components, the impact of Bluetooth vulnerabilities, and establishing robust plans for maintaining software security post-launch throughout the device’s intended lifecycle.
The FDA’s updated premarket cybersecurity guidance emphasizes several key areas:
- Documentation Requirements: Manufacturers must submit detailed cybersecurity documentation, including a Software Bill of Materials (SBOM) and comprehensive security risk management reports.
- Cybersecurity Management Plan: A plan to monitor, identify, and address postmarket cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure (CVD) procedures, is required. This plan must cover the entire product lifecycle, ensuring the device remains secure after market authorization.
- Periodic Security Testing: Regular cybersecurity testing is mandated to identify potential vulnerabilities before they can be exploited. This includes penetration testing with detailed reports on findings and mitigation strategies.
- Designing for Security: Incorporating security into the design phase is critical. The FDA recommends frameworks like IEC 81001-5-1 for secure product development, focusing on threat modeling, security architecture, and continuous vulnerability management.
- Cryptographic Algorithms and Key Lengths: The FDA provides specific guidance on using cryptographic algorithms and key lengths.
For regulatory affairs practitioners, staying updated with these evolving requirements is essential. The stringent cybersecurity standards aim to protect patient safety and ensure the effectiveness of SaMD in an increasingly interconnected digital landscape.
AI and Machine Learning in SaMD
Artificial Intelligence (AI) is increasingly integral to the advancement of Software as a Medical Device (SaMD), bringing both opportunities and challenges to the healthcare landscape. The FDA broadly defines AI as the science of making intelligent machines, with Machine Learning (ML), a critical subset of AI involving training algorithms to learn from data and make decisions, enhancing the capabilities of SaMD.
The regulatory landscape for AI in SaMD is evolving, with the FDA considering a lifecycle-based framework that allows real-time modifications based on real-world data while ensuring safety and effectiveness. The session highlighted the importance of Good Machine Learning Practice (GMLP) principles, advocating for transparency and performance in AI systems. Current standards and projects in development, such as those by ISO/IEC and IEEE, are addressing critical aspects like governance, risk management, and bias management. Notable examples of FDA-cleared AI applications, like the IDx-DR system for diabetic retinopathy screening, illustrate AI’s practical benefits and potential to improve healthcare outcomes.
For regulatory affairs practitioners, the key takeaways from this session include the necessity of staying up-to-date with evolving standards and regulatory frameworks, understanding the implications of AI biases, and ensuring robust data quality management. The session also discussed future directions, including the International Medical Device Regulators Forum (IMDRF) projects and the European Union’s AI Act, which classifies AI applications based on risk levels. These efforts underscore the need for practitioners to engage with ongoing regulatory developments to enhance AI-enabled medical devices’ safety, effectiveness, and equity, ultimately aiming to improve patient outcomes and foster innovation in the healthcare sector.
New Developments in Cloud Environments
Cloud computing has become an integral component in developing and operating Software as a Medical Device (SaMD). Leveraging cloud environments offers numerous benefits but also introduces unique challenges that must be managed to ensure the safety and effectiveness of medical devices.
The rapid growth of cloud computing is driven by its ability to provide scalable, reliable, and cost-effective solutions. However, one primary challenge is maintaining a validated state when medical devices or quality management systems operate on third-party public cloud services. The AAMI CR510:2021 report emphasizes that the best achievable state under these conditions is an “intermittently validated state.” This concept accepts that while continuous validation may not be feasible, a high benefit/risk ratio can be maintained if manufacturers understand and plan for real-time changes that occur on commercial cloud platforms.
Key recommendations from AAMI CR510:2021 include applying a risk-based approach to evaluating cloud resources, rigorously assessing vendors, and establishing plans to address adverse impacts from cloud updates. For instance, cloud providers often implement updates and changes that can affect the software’s performance. Manufacturers must develop strategies to revalidate the software efficiently and ensure its continued safety and effectiveness.
Cloud computing’s flexibility allows for hybrid models where local data centers are combined with public cloud services, providing additional layers of redundancy and security. However, this complexity requires robust supplier monitoring processes and a thorough understanding of the dependencies between various third-party services. For example, a medical device may rely on multiple layers of third-party software hosted on different cloud platforms. This interconnectedness necessitates continuous monitoring and risk assessment to mitigate potential vulnerabilities.
For regulatory affairs practitioners, these insights underscore the importance of integrating cloud-specific risk management strategies into their quality systems. Responsible adoption of cloud technologies involves not only leveraging their benefits but also anticipating and managing the associated risks to maintain the validated state of SaMDs and ensure patient safety.
These principles for utilizing Cloud Environments may be expanded to cover other third-party software components that are not entirely under the SaMD developer’s control.
List of Referenced Standards and Guidances
The following Standards and Guidances were discussed during the course.
- ISO/IEC 81001-5-1: Health software and health IT systems safety, effectiveness, and security — Part 5-1: Security — Activities in the product life cycle.
- AAMI TIR57: Principles for medical device security—Risk management.
- ISO 14971: Medical devices—Application of risk management to medical devices.
- IEC 62304: Medical device software—Software life cycle processes.
- ANSI/AAMI SW91: Classification of defects in health software.
- NIST SP 800-131A Rev.2: Transitioning the Use of Cryptographic Algorithms and Key Lengths.
- AAMI CR510:2021: Consensus report on the use of cloud services in a regulated environment.
- FDA Postmarket Cybersecurity Guidance: Recommendations for cybersecurity in medical devices post-market.
- FDA Premarket Cybersecurity Guidance: Requirements for cybersecurity documentation and management in premarket submissions.
- FDA Guidance on Clinical Decision Support (CDS): Guidelines for CDS tools and software.
- FDA Policy for Device Software Functions and Mobile Medical Applications: Framework for software functions and mobile medical applications.
- Multiple Function Device Products Guidance: Guidance on managing multiple function device products, including non-device functions.
These standards and guidelines provide the foundation for ensuring the safety, effectiveness, and security of SaMD throughout its lifecycle, from development to post-market management.
Conclusion
In conclusion, the regulatory landscape for Software as a Medical Device (SaMD) is complex and constantly evolving. Understanding the classification of SaMD, regulatory pathways, and global regulations is crucial for developers aiming to market their products globally. Additionally, emphasizing cybersecurity as a critical component of SaMD is essential for ensuring the safety and effectiveness of medical software. Navigating these regulatory complexities and focusing on cybersecurity will be key for developers to bring innovative and safe SaMD products to the market.