Findings
The FDA classifies CDS software as Non-Device CDS only if it meets four specific criteria related to data inputs, information display, HCP support, and independent reviewability. Software functions that analyze medical images, signals from IVDs, or patterns from signal acquisition systems remain regulated as medical devices. Non-Device CDS must be intended for health care professionals and not for patients or caregivers. Automation bias and the time-critical nature of decision-making are key factors in determining whether an HCP can truly review the basis of a recommendation independently. If software provides a specific diagnostic or treatment directive rather than a list of options, it generally fails to meet the exclusion criteria.

Recommendations
Developers should ensure that software intended as Non-Device CDS provides a plain language description of the underlying algorithm and the data used for validation. The software or labeling must clearly identify the intended HCP user, the patient population, and the required input medical information. To support independent review, the software should highlight the source of its clinical recommendations, such as specific clinical practice guidelines or peer-reviewed studies. Developers are encouraged to use usability testing to verify that HCPs can understand the basis of recommendations without relying primarily on the software’s output. For multiple function products, developers should follow the FDA’s policy for assessing products that contain both device and non-device functions.

Regulatory Considerations
The FDA applies a risk-based approach to software oversight, focusing on functions that acquire or analyze complex medical data like ECG waveforms or genomic sequences. Software intended for time-sensitive or critical medical decisions is typically regulated as a device because the user lacks the time to independently verify the recommendation. The agency intends to exercise enforcement discretion for certain software functions that provide only one clinically appropriate recommendation if all other non-device criteria are met. Sponsors may use the Q-Submission process to discuss alternative approaches or clarify the regulatory status of specific software functions. Existing digital health policies continue to apply to software functions that meet the device definition, including mobile medical applications.

Findings
The document introduces a risk-based credibility assessment framework for establishing and evaluating the credibility of an Artificial Intelligence (AI) model's output when used to support regulatory decisions regarding drug safety, effectiveness, or quality. The framework outlines a 7-step process beginning with defining the question of interest and the Context of Use (COU). Credibility is defined as trust, established through evidence, in the AI model's performance for a particular COU. The credibility assessment is tailored to the AI model risk, which is a combination of model influence (the AI model's evidence contribution relative to other evidence) and decision consequence (the significance of an adverse outcome from an incorrect decision). The document highlights challenges with AI use, including variability in development datasets (training/tuning), the need for methodological transparency due to model complexity, difficulty in quantifying and interpreting uncertainty in model output, and the potential for performance change over time (data drift), which necessitates life cycle maintenance.

Recommendations
Sponsors and interested parties should define the question of interest and clearly define the COU, detailing the AI model's specific role and scope and whether other information will be used. They should assess the AI model risk (low, medium, or high) to ensure that subsequent credibility assessment activities (Step 4) are commensurate with that risk and tailored to the COU. For Step 4, the credibility assessment plan should include a description of the model, model development process (including inputs, architecture, feature selection, and rationale), and data used (training and tuning data). Development data must be deemed fit for use (relevant and reliable) to mitigate issues like algorithmic bias. The plan should also detail the model evaluation process using independent test data and include performance metrics with confidence intervals, an estimate of uncertainty, and a description of model limitations. Early engagement with the FDA is strongly encouraged to discuss model risk and the adequacy of the credibility assessment plan.

Regulatory Considerations
The risk-based credibility assessment framework is intended to help organize and document information for regulatory submissions. The required stringency of assessment activities and the level of documentation should be commensurate with the AI model risk. For AI models whose performance can change over time (e.g., in pharmaceutical manufacturing or postmarketing), sponsors must implement life cycle maintenance plans to monitor performance and manage changes in a risk-based manner. Changes to AI models should be evaluated through the manufacturer's change management system and may require re-execution of parts of the credibility assessment plan. Early engagement can be facilitated through formal meetings (e.g., Pre-IND) or other specialized programs listed in the guidance, such as the Center for Clinical Trial Innovation (C3TI), the Model-Informed Drug Development (MIDD) Paired Meeting Program, and the Emerging Technology Program (ETP) or Advanced Technologies Team (CATT).

Findings
A proactive risk assessment is essential for optimizing study quality by identifying and mitigating risks to human subject protection and data integrity before and during a trial. Monitoring should be comprehensive, addressing not only likely risks identified initially but also less probable, high-impact risks and unanticipated issues that emerge. The effectiveness of a monitoring strategy depends on tailoring its timing, frequency, and methods to study-specific factors like complexity and site experience. Centralized monitoring, as part of a risk-based approach, can detect systemic issues like data omissions or protocol deviations more rapidly than traditional on-site visits alone.

Recommendations
Sponsors should formally document their risk assessment methodologies and ensure these assessments directly inform the creation and revision of monitoring plans. Monitoring plans must be detailed, outlining the study design, specific data sampling strategies, and clear protocols for escalating significant issues. When significant problems are identified, sponsors must conduct a timely root cause analysis and implement corrective and preventive actions. All monitoring activities, findings, and subsequent actions should be thoroughly documented and communicated to sponsor management, clinical site staff, and other relevant parties.

Regulatory Considerations
FDA regulations mandate sponsor oversight and proper monitoring but do not prescribe specific methods, providing the flexibility for sponsors to adopt a risk-based approach. The FDA may request a sponsor's risk assessment and monitoring plan documentation during an inspection. This guidance represents the Agency's current thinking and is nonbinding, allowing sponsors to use alternative approaches if they satisfy regulatory requirements. A key focus of monitoring should be to ensure critical trial processes, such as the maintenance of blinding, are protected to maintain overall data and trial integrity.

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
Cybersecurity threats in healthcare are increasingly frequent and severe, posing risks to device safety and clinical care.
Many vulnerabilities arise from third-party software components and interconnected device ecosystems.
Legacy devices often lack adequate cybersecurity controls, leading to increased patient and organizational risks.
Cybersecurity risk management processes must integrate safety and security assessments throughout the device lifecycle.
Transparency in device cybersecurity is crucial for enabling safe integration and use by healthcare providers and end users.

Recommendations
Implement a Secure Product Development Framework (SPDF) for comprehensive cybersecurity throughout the product lifecycle.
Include a Software Bill of Materials (SBOM) for all premarket submissions to track software dependencies and vulnerabilities.
Perform robust cybersecurity testing, including penetration testing and vulnerability assessments.
Enhance device labeling with clear cybersecurity-related instructions and risks for users.
Develop a coordinated vulnerability disclosure plan for postmarket cybersecurity management.

Regulatory Considerations
Adherence to 21 CFR Part 820 Quality System regulation requirements, including design controls and risk management.
Compliance with Section 524B of the FD&C Act for cybersecurity of cyber devices.
Submission of SBOMs and detailed security risk management reports for premarket applications.
Provision of cybersecurity information as part of device labeling to prevent misbranding under Section 502 of the FD&C Act.
Integration of security testing and validation as part of the FDA review process.

Findings
Pre-Submissions (Pre-Subs) allow submitters to obtain FDA feedback on specific questions before submitting formal IDEs, 510(k)s, PMAs, or other applications. Early feedback can improve submission quality and streamline the review process.
Submission Issue Requests (SIRs) provide a mechanism for addressing issues raised in FDA hold letters (e.g., 510(k) deficiencies) to help expedite resolutions.
Study Risk Determinations help sponsors clarify whether clinical studies are significant risk (SR), non-significant risk (NSR), or exempt from IDE regulations.
Informational Meetings are non-feedback sessions aimed at familiarizing FDA staff with new devices or sharing updates on ongoing development.
The program encourages timely submissions, including supplements for ongoing discussions and amendments to update materials.

Recommendations
Clearly define the purpose and goals of the Q-Sub in the submission to facilitate effective FDA review.
Include specific, well-formulated questions that focus on a limited number of topics to ensure actionable feedback.
For Pre-Subs, align planned testing and submissions with FDA guidance and include detailed device descriptions, testing protocols, and relevant background information.
Use SIRs to discuss proposed solutions to deficiencies raised in FDA hold letters, focusing on timely resolution.
Draft and submit meeting minutes promptly (within 15 days of meetings) to ensure accurate documentation of FDA feedback.

Regulatory Considerations
Submitters should adhere to the timelines specified for different Q-Sub types, including 70 days for Pre-Sub feedback or 21 days for SIRs submitted promptly after a hold letter.
Q-Subs should include all relevant regulatory history and references to prior FDA communications to streamline the review process.
FDA feedback through the Q-Sub program is non-binding and based on the information available at the time; subsequent submissions must align with the provided feedback to maintain consistency.
Informational Meeting requests should clearly state that feedback is not expected and may be used to track interactions outside other formal Q-Sub types.
Confidentiality of Q-Subs is maintained in compliance with FDA’s disclosure regulations and the Freedom of Information Act (FOIA).

Findings
There are various formal and informal engagement pathways available for developers of Digital Health Products and Combination Products to communicate with the FDA to seek advice regarding product classification, regulatory status, and submission strategies. Informal pathways include the Digital Health Inquiry (via the Digital Health Inbox), the DICE Mailbox Inquiry, and the Pre-RFD Process, which provide non-binding feedback. Formal pathways include the 513(g) Program for classification, and the Q-Submission Program (encompassing Pre-Submissions for pre-application feedback and SRD for risk determination).

Recommendations
Manufacturers should use the provided map to determine the appropriate pathway based on their product type (standalone digital health or combination product) and the type of advice they are seeking (informal or formal). The Pre-Submission (Pre-Sub) program is recommended as an opportunity to obtain formal feedback "prior" to submitting an application, particularly if a new product's regulatory pathway is unclear or if planning a study to support a future application. Combination Product manufacturers can use CPAMs to clarify marketing authorization standards or post-market modification requirements.

Regulatory Considerations
The 513(g) Request provides information on a product's classification and applicable regulatory requirements but does not determine substantial equivalence or make final marketing authorization decisions. Programs like the CDRH-Payor Connection and Parallel Review with CMS are voluntary and designed to expedite patient access by aligning clinical evidence for both regulatory clearance/approval and coverage decisions. Participation in these programs, however, does not alter the FDA’s existing, separate standards for regulatory review.

Findings
The QS regulation under 21 CFR Part 820 has been effective but requires updates to align with global standards like ISO 13485.
Adopting ISO 13485 will harmonize FDA requirements with international practices, benefiting manufacturers that sell devices globally.
FDA’s proposed amendments retain some unique provisions to ensure alignment with the Federal Food, Drug, and Cosmetic Act (FD&C Act).
The incorporation of risk management principles throughout the product lifecycle is more explicit in ISO 13485 than in the current QS regulation.
The proposed changes are expected to reduce regulatory burdens and enhance device quality and accessibility.

Recommendations
Align quality management systems with ISO 13485 to ensure compliance with both U.S. and international regulatory requirements.
Establish documentation processes that meet FDA’s additional requirements, such as those for traceability and complaint handling.
Incorporate risk management throughout the device lifecycle, as emphasized in ISO 13485.
Manufacturers should train personnel and update their systems to comply with the new requirements within the proposed one-year transition period.
Provide comments on the proposed rule to FDA before the deadline to address any potential concerns or suggestions for improvement.

Regulatory Considerations
The proposed rule incorporates ISO 13485:2016 by reference and aligns FDA’s QS regulation with international QMS standards.
FDA-specific requirements include:
Traceability for certain life-supporting devices.
Documentation of unique device identifiers (UDI) in compliance with FDA’s regulations.
Complaint handling and servicing records that meet FDA standards.
FDA inspections will not issue ISO 13485 certifications but will assess compliance with the proposed Quality Management System Regulation (QMSR).
Manufacturers must continue to comply with existing FDA regulations where conflicts with ISO 13485 arise.

Findings
The FDA has distinct engagement pathways depending on whether the product is a Standalone Digital Health Product or a Combination Product. The pathways are further categorized into Informal and Formal advice.
Informal Pathways include:
Digital Health Inquiry (Digital health inbox, DICE mailbox inquiry).
General Inquiry for combination products.
CDRH List & Learn.
Formal Pathways for digital health and combination products include:
513(g) request (for classification information).
Q-Submission Program (Pre-Submission, Submission Issue Request (SIR), Information meeting).
CDRH-payor connection (Early payor feedback program, Parallel review with CMS).
RFD/Pre-RFD process (Request for Designation).

Recommendations
Developers should use this map to identify the appropriate mechanism for seeking regulatory advice. The initial decision point is whether the engagement is related to the design, development, or deployment of a digital health product. Once the product type is identified, the map directs the user to the appropriate formal or informal path. The various mechanisms are used for different purposes, such as an Information meeting (to share information without expecting feedback) or a Pre-Submission program (for formal feedback on a planned product).

Regulatory Considerations
The pathways involve different Centers and Offices, including the Center for Devices and Radiological Health (CDRH), Centers for Medicare & Medicaid Services (CMS), and the Office of Combination Products (OCP). The FDA's focus is on engagement pathways for digital health products. For information on developing digitally derived endpoints for drugs, developers are directed to the DiMe and CTTI guides. Engagement is related to design, development, or deployment of the product

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
A “multiple function device product” contains at least one device function and one “other function” that may or may not be subject to FDA oversight.
FDA assesses "other functions" only to the extent they impact the safety or effectiveness of the device function under review or are claimed to provide a positive labeled impact.
Manufacturers must conduct and document risk assessments for all functions within the product to ensure safety and performance.
Functions not directly subject to FDA premarket review are still considered during inspections if they influence the device function under review.
Design separation between device and non-device functions can mitigate risks and simplify regulatory assessment.

Recommendations
Conduct thorough risk assessments for “other functions” and document the impacts, whether negative, positive, or neutral, on the device function under review.
Use design separation to minimize interdependencies between device and non-device functions where feasible.
Include only the relevant "other function" documentation in premarket submissions if it impacts the device function under review or is represented as a labeled positive impact.
For modifications to “other functions,” determine if they significantly affect the safety or effectiveness of the device function, and, if so, submit a new premarket notification as required.
Follow applicable labeling, quality system, and postmarket requirements for both device and non-device functions, ensuring clarity in what has been evaluated by the FDA.

Regulatory Considerations
Non-device functions are not regulated unless they impact the safety or effectiveness of a device function under review.
For device functions under review, manufacturers must comply with FDA's design validation and risk analysis requirements under 21 CFR 820.30(g).
Changes to non-device functions must be assessed for potential impacts on the device function under review to determine whether additional regulatory submissions are necessary.
FDA evaluates the premarket safety and effectiveness of device functions within the context of interactions with non-device functions but does not directly regulate the non-device functions themselves.
Postmarket requirements, such as adverse event reporting, apply to device functions, including when the event involves an interaction with a non-device function.

Findings
The process of obtaining Informed Consent (IC) involves providing adequate information to facilitate comprehension and must allow subjects the opportunity to ask questions, continuing throughout the research. Electronic Informed Consent (eIC) systems, which can use various electronic media, are increasingly used to supplement or replace paper-based IC processes. The eIC process may be conducted on-site or remotely, but the legal responsibility for obtaining consent cannot be delegated to the electronic system. For FDA-regulated clinical investigations, electronic signatures must comply with 21 CFR Part 11 to be considered equivalent to a handwritten signature.

Recommendations
Presentation & Comprehension: eIC information should be easy to navigate, convey information in understandable language, and may use interactive electronic-based technology (e.g., diagrams, video) to facilitate comprehension. Optional questions can be used to assess a subject's understanding of key study elements.
Remote Consent: If consent is obtained remotely, the electronic system must include a reliable method to verify the identity of the subject (e.g., official identification, biometric methods).
Signature & Documentation: Electronic signatures are permitted and can be created using methods like biometrics or username/password, provided they are uniquely linked to the individual. The subject must be given a copy of the signed eIC, which can be electronic or paper.
Privacy & Security: The eIC system must be secure with restricted access and include methods to ensure confidentiality of subject information. If HIPAA applies, information must be encrypted unless otherwise documented.

Regulatory Considerations
IRB Responsibility: IRBs must review and approve all eIC materials and any subsequent amendments, including optional comprehension questions and the usability of the eIC materials. IRBs must maintain records (electronic or hard copy) of the approved versions of the eIC materials.
Submissions & Inspection: For IDE applications, copies of all eIC materials must be submitted to the FDA. During inspections, investigators must have site-specific signed eICs, amendments, and materials available (electronic or paper) for FDA review.
HIPAA: HIPAA authorizations may be obtained electronically, provided the signature is legally valid, and a copy must be provided to the subject.