The PATIENT AI Act: A New Prescription for FDA Software Review, or More of the Same?

U.S. Senator Bill Cassidy, Chairman of the U.S. Senate Health, Education, Labor, and Pensions Committee, has announced a discussion draft of the Protecting Americans Through Intelligent, Ethical, and Transparent Artificial Intelligence in Health Care Act, or PATIENT AI Act. The draft addresses privacy, cybersecurity, liability recommendations, transparency, workforce training, datasets, and health information technology. It also proposes Medicare coverage, coding, and payment initiatives for AI-based services. Not surprisingly, this post focuses solely on Title II, Food and Drug Administration, which proposes changes to the premarket review process for software devices; whether those changes meaningfully alter the review process is not entirely clear.

Integrated Devices and Software-Based Devices

The draft introduces two categories of devices to which different provisions of the draft would apply. The first are “integrated devices,” which are devices that incorporate software functions and other components. This sounds a lot like the current category of devices known as “software in a medical device” (SiMD), which are distinct from stand-alone “software as a medical device” (SaMD) products. The second category is “software-based devices,” which are devices whose intended medical purpose is achieved primarily through one or more software functions. This seemingly refers to SaMD, but the draft does not clearly state whether integrated devices and software-based devices are mutually exclusive terms that should be understood similar to the more familiar framework of SiMD and SaMD.

Component Review for Integrated Devices

To begin, Section 201 would establish a voluntary process for preliminary premarket review of individual components of “integrated devices” prior to traditional premarket review of the full integrated device. The component review process would include a review of inputs, software functions, and outputs, considering evidence such as associated testing and validation data and conformity with consensus standards. FDA may also consider previous reviews or determinations related to the software function or other component and “shall, to the maximum extent practicable, rely on such prior evaluation to the extent applicable to the intended use of the component in the integrated device.”

This new review process would not result in standalone clearance or approval of individual software components. The full device would still need authorization under an existing pathway, such as a 510(k), de novo, or premarket approval (PMA).

At first blush it is not clear what a manufacturer would gain from a pre-review of its software components when a full submission is still required or how effective any review of software could be when isolated from other components of the device. Though not stated in the draft, this optional review may ultimately be a more elaborate pre-submission process. The question, of course, is what feedback the sponsor will get, how it would be different from the current pre-submission process, and what the timing for the review would be. The draft also does not say whether there will be a user fee for these component reviews—FDA recently proposed a user fee for pre-submissions as part of the MDUFA VI negotiations, so it would be surprising for these component reviews to be free.

Perhaps the most useful provision relates to reliance on prior review, and the extent to which this is something akin to a substantial equivalence; on its face the statutory language would appear to require FDA to rely more heavily on prior related reviews. If passed, FDA would be required to issue a guidance document within 180 days of enactment setting forth the process for this review, including the procedures for relying on previously reviewed components.

Risk-Based Review and Pre-Market PCCPs for Software-Based Devices

While Section 201 looks like a software-specific pre-submission pathway, Section 202 directs FDA to establish a “risk-based approach to the premarketing review of software-based devices” under the existing 510(k), de novo, and PMA authorities.  It is not clear why this direction is needed since FDA’s current authorities mandate a risk-based review of all devices, which necessarily include software-based devices. This section repeats the definition of low- to moderate-risk devices, the requirement for FDA to apply the least burdensome means of assessing safety and effectiveness, and the consideration of intended use and risk presented by such use in conducting the premarket review. Interestingly, FDA would be required to issue a guidance within 180 days of enactment of this act, should it pass, regarding “the factors [FDA] will consider in determining whether a software-based device” is considered low- to moderate-risk. It would be interesting to see if those factors are different for software-based devices than for other devices and, if so, why.

While the first part of Section 202 frankly seems unnecessary and duplicative of already-existing authority, the second half presents a new proposal. The draft would permit sponsors to submit predetermined change control plans (PCCPs) describing software changes the sponsor expects to make during FDA’s review of a PMA application or 510(k) notification. Congress previously authorized PCCPs for changes a sponsor planned to make after marketing authorization. This new proposal would allow development and improvements to continue while the submission is pending. As with the original PCCP language in the Food and Drug Omnibus Reform Act of 2022, Congress forgot to include de novo authorization; we assume that FDA will apply these provisions to de novo in the same manner it has applied currently available PCCP authorities to those premarket submissions.

If FDA accepts one of these pre-market PCCPs, a change consistent with the plan would not, solely because of that change, require a new submission, withdrawal and resubmission, or restarting the applicable review period. The sponsor would still provide information FDA considers necessary to show the change does not materially alter safety or effectiveness.

Less pressure to freeze the design sounds attractive. But FDA still needs to know which version it is reviewing and which data support it. A last-minute change could leave reviewers assessing new information without restarting the review period, squeezing an already tight schedule and potentially rushing work against MDUFA deadlines. Without clear version-control and timing rules, the flexibility could become a recipe for confusion rather than faster review.

Third-Party Review for Software-Based Devices

Section 203 would create an accredited third-party review program supplementing FDA’s existing pathways for low- to moderate-risk software-based devices. According to the draft’s text, third-party review recommendations could support 510(k), de novo, and PMA submissions—broader than the existing 510(k)-only third-party review program. But the new review program is limited to “low- to moderate-risk” devices, which would seemingly exclude its application to high-risk PMA devices. Read this way, the draft would only expand third-party review to de novo requests for software-based devices.

Like the existing program, the third-party reviewer would submit its recommendation and supporting documentation to FDA, and the agency would have 30 days to accept the determination or decide additional review is appropriate. FDA would be directed to rely on adequately addressed third-party work rather than routinely repeating it.

The existing third-party program’s practical shortcomings give us little reason to assume a new version focused on software will fare better. Indeed, adding de novo requests could mean substantially more clinical data and novel questions for outside reviewers to evaluate. If FDA then needs to revisit that work, sponsors may pay for another layer of review without shortening the path to authorization. A broader program is not necessarily a better one.

Postmarket Surveillance Pilot

The last section related to FDA authority, Section 204, would require FDA to establish a voluntary pilot to modernize postmarket surveillance for integrated and software-based devices. Its focus would include leveraging device data generated during routine health care delivery and real-world evidence, automating and standardizing data collection and transmission, reducing the costs and administrative challenges of generating postmarket evidence, and coordinating with CMS to consider reimbursement and payment associated with postmarket surveillance.

This is not entirely new territory. FDA’s 2025 request for public comment on real-world AI device performance asked about monitoring infrastructure, data quality, performance drift, and barriers to implementation. That request was a discussion document, not guidance or a new regulatory requirement, but it illustrates the overlap in the frameworks being proposed and discussed by both Congress and FDA.

Conclusion

Title II of this draft bill is, in many ways, duplicative of FDA’s existing premarket authorization pathways. Whether any of the proposals would produce meaningful efficiencies depends on implementation: how FDA would use prior component evaluations, when it would accept change control plans, and whether it would rely on adequately supported third-party recommendations without duplicating the review. As a discussion draft, the proposal does not change manufacturers’ obligations. The measure of any eventual legislation should be whether it reduces duplicative work and makes review more predictable without compromising the applicable safety and effectiveness standards. Without that result, Title II risks adding procedures rather than improving the path to market.