In the rapidly evolving medical device industry, software integration plays a critical role in enhancing device functionality, improving patient outcomes, and increasing system efficiency. From implantable pacemakers to imaging systems, software advancements are reshaping healthcare.

The Rise of Software as a Medical Device

The “Software as a Medical Device” (SaMD) valued at $5.6 billion in 2023, is growing at a projected CAGR of 10.71%. This growth is driven by digital healthcare adoption and the rising prevalence of chronic diseases. SaMD applications in diagnosis, monitoring, and condition management are expanding rapidly, with significant market growth projected by 2032.

Since 2012, USFDA-approved SaMDs have surged, with AI- and ML-based devices representing 22% of all approvals by 2021. The U.S. leads SaMD development, accounting for 45% of USFDA-approved devices in the past decade.

Software in a Medical Device (SiMD)

Software in a Medical Device refers to embedded software within physical devices like pacemakers, infusion pumps, and ventilators, controlling hardware functions and ensuring safety. Regulatory focus for SiMD includes software reliability, risk management, and quality adherence. Updates or modifications often require careful evaluation due to their potential impact on safety and performance. Although specific 2023 figures for SiMD are limited, its market growth parallels trends in digital health.

AI/ML in a Medical Devices

AI/ML-based devices are increasingly cleared via the USFDA’s 510(k) pathway, leveraging substantial equivalence to predicate devices. Between 2019 and 2021, over a third of AI/ML devices stemmed from non-AI/ML predicates. However, frequent task changes, particularly in radiology devices, raise safety concerns. Establishing substantial equivalence remains crucial for advancing patient care.

Understanding the 510(k) requirements

A 510k submission is a premarket notification to the USFDA, demonstrating that a medical device is as safe and effective as a legally marketed predicate device. According to USFDA 21 CFR 807.81(a)(3), Premarket notification 510(K) must be submitted when:

Regulatory Challenges and Software Changes

The USFDA’s guidance helps determine when software changes require a new 510(k) submission. Some of the common software change types include:

Infrastructure: Changes to the software support system, such as switching compilers, programming languages (e.g., C to C++, C++ to Java), or software drivers/libraries.
Architecture: Structural modifications, such as switching operating systems or adding hardware platforms.
Core algorithm: Modifications to an algorithm that affect the device’s intended function, such as alarm algorithms in monitors or motor control algorithms.
Clarification of Requirements: Changes made to clarify software requirements after a product has received 510k clearance without altering the device’s functionality.
Cosmetic Changes: Changes made to the appearance of the device that do not impact the clinical use of the device. E.g., changing the company logo displayed on the background involve modifying multiple software modules.
Reengineering and Refactoring: Reengineering evolves alteration of software to reconstitute it in a new form. Refactoring involves changing a software program internal structure without changing its clinical performance specification.

Evaluating the Need for a 510(k) Submission

Manufacturers must assess several key factors to determine if a new 510(k) is required for software changes to an existing device:

Intent of the Change: A new 510(k) is required if any modification significantly affecting device safety or effectiveness. (for example, to improve clinical outcomes, to mitigate a known risk, in response to adverse events, etc).
Unintended Consequences: Evaluate potential unintended outcomes, especially when the change aims to improve performance. For example, compatibility issues arising from operating system updates.
Initial Risk-Based Assessment: Conduct a risk-based assessment to analyze all risks (new and existing) and evaluate on the severity of harm to determine their impact on safety and effectiveness to decide if a submission is necessary.
Role of Testing: If risk assessments indicate no new 510(k) is required, verification and validation should confirm this decision. Unexpected testing results might mean revisiting the need for a new 510(k). Conduct verification and validation activities to confirm that changes do not degrade device performance.
Evaluating Multiple Changes: Assess individual and collective impacts of simultaneous modifications to determine if a new 510(k) is needed.
Comparative Device Analysis: Compare the modified device to its previously cleared version to determine the significance of changes.
Documentation Requirement: Maintain comprehensive records of changes per 21 CFR Part 820 quality system regulations whenever manufacturers change their device.
510(k) Submissions for Modified Devices: When a new 510(k) is submitted for a device with multiple changes, that 510(k) should describe all changes that trigger the requirement for submission of a new 510(k).
Substantial Equivalence Determinations: When submitting a new 510(k), Clearly document all changes to demonstrate substantial equivalence.

Flowchart

A decision-making flowchart simplifies evaluating whether a software modification requires a new 510(k), guiding manufacturers through regulatory compliance.

Conclusion

As medical device software evolves, frequent updates require manufacturers and the USFDA to adapt. SaMD adoption may increase 510(k) submissions by 15% annually over the next five years.

The US FDA’s 510k submissions process ensures software safety and compliance. Manufacturers must evaluate changes, follow guidelines, and test thoroughly. With the healthcare software market projected to reach $84.3 billion by 2029, proactive compliance and expert support are key to meeting challenges and improving patient care.

Author

Ms. Ruksana Sanafar (B.E. Biomedical)
Sr. Consultant, FDA Compliance | Medical Device