Findings
Enhanced documentation is required for high-risk device software where flaws could result in serious injury or death.
Risk management plans should include robust risk assessments, including residual risk evaluations.
Verification and validation activities are critical to confirm software functionality and mitigate risks.
The lack of traceability between software design and requirements can undermine device safety and effectiveness.
Unresolved software anomalies must be carefully documented and justified based on a risk assessment.

Recommendations
Use a risk-based approach to determine whether basic or enhanced documentation levels are required for premarket submissions.
Include comprehensive risk management documentation, detailing hazard identification, risk control measures, and residual risk evaluations.
Provide detailed system and software architecture diagrams, highlighting relationships between modules and external systems.
Document unresolved software anomalies and justify their impact on safety and effectiveness using a risk-based rationale.
Align software development, configuration management, and maintenance practices with FDA-recognized standards like ANSI/AAMI/IEC 62304.

Regulatory Considerations
Adherence to 21 CFR Part 820 Quality System regulations, emphasizing design controls and risk management.
Submission of risk management files and unresolved software anomalies as part of premarket documentation.
Use of system and software architecture diagrams to demonstrate software functionality and risk mitigation.
Implementation of cybersecurity measures as part of software validation and risk management processes.
Documentation of premarket changes and interactions between device functions and external systems, particularly in multi-function devices.

Findings
CADe devices must meet classification requirements under 21 CFR 892.2050, including general and special controls, and require FDA clearance through 510(k) submissions.
Each new CADe device or significant modification must demonstrate substantial equivalence to a predicate device in terms of safety and effectiveness.
Robust testing and validation are necessary, including standalone and clinical performance assessments, to evaluate detection accuracy and false positive rates.
Devices with substantive technological differences or new intended uses may require clinical performance assessments.
Enrichment strategies for study populations (e.g., including challenging cases) are encouraged but should not bias performance evaluations.

Recommendations
Clearly describe the CADe algorithm, training datasets, scoring methodologies, and intended use in premarket submissions.
Conduct standalone performance assessments to measure detection accuracy and generalizability.
Compare new devices to predicate devices whenever possible, using consistent datasets and methodologies.
Develop and submit user training materials that address expected device performance, limitations, and appropriate usage scenarios.
Provide comprehensive labeling, including indications for use, directions, warnings, precautions, and performance metrics, to ensure clinician understanding and appropriate application.

Regulatory Considerations
All CADe devices under 21 CFR 892.2050 must comply with 510(k) premarket notification requirements, including general and special controls.
Changes to CADe algorithms or device characteristics must be evaluated for significant impact on safety and effectiveness, potentially requiring new submissions.
Devices with altered indications for use or significant technological differences may need additional clinical performance studies to demonstrate substantial equivalence.
Labeling must comply with 21 CFR Part 801 and provide sufficient information to describe the device, its intended use, and directions for use.
Manufacturers should consult FDA for guidance on substantial modifications or unique device characteristics.

Findings
The MDR/IVDR enhance the focus on cybersecurity for devices incorporating electronic programmable systems and software. Cybersecurity risk is inherently linked to patient safety and effectiveness; manufacturers must reduce all risks, including security risks with safety impacts, to an acceptable level. The management of security risks should be integrated into the product's overall Risk Management System. Due to the rapid change in the threat landscape, security maintenance is a critical, ongoing requirement across the entire product lifecycle. Other EU legislation, such as GDPR (data protection) and the NIS Directive (network security), also apply in parallel.

Recommendations
Manufacturers must follow a "Secure by design" strategy throughout the Design and Development phase, adopting a "Defense-in-Depth strategy". This includes:
Risk Management: Conduct a Security Risk Assessment (using techniques like Threat Modelling) to identify vulnerabilities and their potential impact on safety and effectiveness.
Risk Control: Prioritize mitigating risks in this order: eliminate/reduce risks through safe design; take adequate protection measures (e.g., encryption, authentication, alarms); provide information for safety and training .
Minimum IT Requirements: Clearly set out the minimum hardware, IT network, and IT security requirements for the device's operating environment and communicate these in the Instructions for Use. Devices should be as autonomous as possible in terms of security and avoid sole reliance on the operating environment.
Vigilance: Establish a robust Post-Market Surveillance (PMS) System to actively collect information, review data, and timely implement corrective actions (e.g., security updates/patches) for security vulnerabilities and incidents throughout the device's lifespan. Manufacturers must report all serious incidents and Field Safety Corrective Actions (FSCA).

Regulatory Considerations
Manufacturers must ensure that technical documentation includes information demonstrating conformity with all general safety and performance requirements, including justification and verification/validation of security solutions. Instructions for Use must include information on residual risks related to IT security and detailed instructions for secure installation, configuration, operation, and deployment of security updates. The entire process is a continuous, iterative cycle, requiring regular updates to technical documentation, risk management, and clinical evaluation

Findings
Software functions for administrative support of healthcare facilities, general wellness, and maintaining electronic patient records are excluded from FDA regulation if they meet specific criteria under section 520(o)(1) of the FD&C Act.
MDDS software functions for transferring, storing, converting formats, and displaying data are not devices unless they include interpretive or analytical features.
Wellness-related software functions that are unrelated to disease diagnosis or treatment (e.g., tracking fitness or sleep) are no longer regulated as devices.
Software functions associated with certified health IT under ONC Health IT Certification are not considered devices, provided they are not intended for interpretation or diagnosis.
Software involving clinical alerts, prioritization of patient information, or medical decision support remains subject to FDA oversight under section 520(o)(1)(E).

Recommendations
Clearly define software functions to assess whether they fall under the excluded categories outlined in section 520(o)(1) of the FD&C Act.
For software functions that combine device and non-device functionalities, ensure that only device-related functionalities are included in FDA regulatory submissions.
Maintain compliance with general FDA requirements for software that still meets the definition of a device, particularly those with interpretive or decision-support capabilities.
Align product labeling and marketing claims with the revised guidance to accurately reflect whether software functions meet the exclusion criteria.
Use the latest FDA-recognized consensus standards to assess compliance for any software functions still considered devices.

Regulatory Considerations
Non-device software functions under section 520(o)(1) are excluded from FDA regulation, but any interpretive or analytical capabilities must still comply with device requirements.
Software functions certified under ONC Health IT Certification are not devices unless intended for analysis or diagnosis.
Hardware associated with MDDS functions remains subject to FDA regulation, but non-device MDDS software functions are excluded from oversight.
FDA continues to regulate functions that prioritize patient-related information or trigger clinical alerts under section 520(o)(1)(E).
Software combining device and non-device functions must clearly delineate each functionality’s regulatory status to avoid unnecessary oversight of non-device components.

Findings
Medical devices using OTS software are vulnerable to cybersecurity threats, which can compromise safety and effectiveness.
FDA emphasizes that most software patches can be applied without prior approval unless they alter the device’s intended use or compromise safety and effectiveness.
Manufacturers must validate software changes to ensure they meet user needs and function as intended, following Quality System regulation.
Healthcare organizations rarely possess sufficient technical resources to independently manage medical device software, relying on manufacturers for updates and guidance.
Collaboration between healthcare organizations and manufacturers is critical for developing and implementing cybersecurity plans.

Recommendations
Manufacturers should monitor sources of quality data to identify vulnerabilities and implement corrective actions to maintain device safety and effectiveness.
Validate all software patches and changes, documenting that they meet user needs and functional requirements.
Develop and follow plans for managing software changes, including timelines, testing protocols, and communication strategies.
Healthcare organizations should collaborate with manufacturers to implement cybersecurity measures and address vulnerabilities.
Avoid applying third-party software patches to medical devices without guidance from the device manufacturer.

Regulatory Considerations
Manufacturers must comply with FDA’s Quality System regulation, ensuring that software patches and changes are validated and documented.
FDA approval is required for software changes that alter the device’s intended use or significantly affect its safety and effectiveness.
Healthcare organizations should not independently apply software patches but rely on manufacturer guidance to ensure compliance with FDA regulations.
Manufacturers should maintain a plan for managing cybersecurity vulnerabilities, including monitoring for threats and updating devices as needed.

Findings
High percentage of medical device recalls due to software failures.
Need for comprehensive software validation processes.
Importance of integrating software life cycle management with risk management.
Flexibility in applying validation principles while ensuring compliance.
Critical role of software validation in assuring quality and reducing recalls.

Recommendations
Develop a comprehensive validation plan, integrating software life cycle and risk management activities.
Document all software requirements and specifications to ensure traceability and validation.
Implement defect prevention measures throughout the development process, rather than relying solely on post-development testing.
Conduct thorough regression analysis and testing following any software change, including small updates.
Validate off-the-shelf software by leveraging vendor documentation, auditing vendor practices, or conducting system-level testing as necessary.

Regulatory Considerations
Adherence to Quality System Regulation (21 CFR Part 820), including specific software validation requirements under §820.70(i).
Compliance with Electronic Records; Electronic Signatures regulation (21 CFR Part 11) for systems managing electronic records and signatures.
Validation of automated systems for production and quality management, including tools for software design and testing.
Maintenance of documentation for validation protocols, test results, and system configurations to support FDA inspections.
Addressing validation requirements for all software, including components developed in-house, off-the-shelf software, and contractor-developed systems.