Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial 

Intelligence / Machine Learning-Enabled Device Software Functions - Draft Guidance

April 13, 2023

Moderator: Elias Mallis

 

Elias Mallis: Hello, and welcome to today's CDRH webinar. This is Elias Mallis, Director of the Division of 

Industry and Consumer Education in CDRH's Office of Communication and Education. And I'll be your 

moderator for today's program. 

Today's topic features FDA's draft guidance, titled, "Marketing Submission Recommendations for a 

Predetermined Change Control Plan for Artificial Intelligence/Machine Learning-Enabled Device 

Software Functions." This draft guidance is currently open for public comment. As a result, we're holding 

this webinar to provide you with an opportunity to learn more about this proposed policy and to answer 

your questions as you consider providing us with your feedback. 

Now due to the anticipated high interest in this topic, we've expanded today's webinar to 90 minutes so 

we can present all of the key highlights of the guidance and answer as many of your questions. A few 

quick notes before we get started. First, please make sure that you've joined us through the Zoom app 

and not through a web browser. This will help avoid any technical issues. And second, the intended 

audience for this webinar is industry. Members of media are encouraged to consult with FDA's Office of 

Media Affairs for any questions you may have. 

Now it's my pleasure to introduce you to our presenters for today's program-- Catherine Bahr, Assistant 

Director for Emerging Technology Assessment and Strategy; Dr. Matthew Diamond, Chief Medical 

Officer; and Dr. MiRa Jacobs, Biomedical Engineer for Policy Leadership and Development. All presenters 

come from FDA's Digital Health Center of Excellence in CDRH's Office of Strategic Partnerships and 

Technology Innovation. We'll hear from our presenters and then come back around for a discussion and 

field your questions. 

Dr. Diamond will kick off our remarks today. Once again, thank you all for joining us today, and let's hear 

from Matt. 

Matthew Diamond: Thank you, Elias. And hello, everyone and thank you for joining us today for this 

webinar. I am very pleased we're here today talking about the newly released draft guidance, 

"Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial 

Intelligence/Machine Learning or AI/ML-enabled Device Software Functions." I realize that title is a 

mouthful, but we'll go through this step by step in this webinar to ensure it's clear, what we're saying in 

the guidance. And with that in mind, I'd like to go ahead and describe our specific learning objectives for 

today. 

For today's webinar, first, we'll be providing some background information on this guidance, which 

we're issuing in draft for your feedback, and how it represents the next important step in our 

collaborative patient-centered approach to AI/ML-enabled devices. After that, we'll describe the 

purpose and scope of the guidance. Next, we'll dive into the rest of the content of the guidance and 

explain FDA's current thinking on modifications for machine learning-enabled device software functions 

or ML-DSFs. 
2

And then we'll share some specific recommendations for how to use a predetermined change control 

plan or PCCP in a marketing submission for a device that is or includes an ML-DSF. And we'll focus on 

what information should be included in a PCCP. At the end of this presentation, we'll walk through a 

brief example of modifying an AI/ML-enabled device using a PCCP. And we'll make sure you have the 

information you need to submit comments on this guidance to the public docket. 

Now let me make a few very brief comments on terminology for this webinar, including the fact that 

sometimes we might refer to the draft guidance as just "the guidance" for simplicity. But please 

remember that it is a draft. Also, throughout the guidance and this presentation, we'll sometimes use 

the acronym ML-DSF to represent the term machine learning-enabled device software function. 

Sometimes it may be easier to think of the ML-DSFs as simply the device, but we're using the term 

machine learning-enabled device software function consistent with our function-based approach and 

the fact that many devices perform numerous functions. And another acronym we'll be using a lot is 

PCCP. Remember, that's the predetermined change control plan itself, which is what describes the 

modifications that will be made to the device and how those modifications will be implemented and 

assessed. 

So, let's begin with some background information on this draft guidance and FDA'S approach to AI/MLenabled devices. 

First and foremost, all of this work is grounded in our vision at CDRH that patients in the US have access 

to high-quality, safe, and effective medical devices of public health importance first in the world. And 

that includes devices enabled by machine learning. In our approach to these technologies, as in all of our 

work, patients are at the heart of what we do.

As we work to ensure patients have access to safe and effective AI/ML-enabled devices, we're seeing 

these technologies playing an increasingly important role in health care and our daily lives for diagnosis, 

treatment, prevention, personalized care, and for learning new scientific insights. And this is across a 

broad spectrum of diseases and conditions. Keep in mind that generally, machine learning-enabled 

devices today assist a user, which could be a health care professional, a patient, or caregiver, in 

performing a task. 

Examples include devices that analyze images like X-rays or physiologic data like EKGs, ones that can 

serve as an extra set of eyes during a procedure, or that can assist a patient or health care professional 

in making decisions. We're excited that these machine learning-enabled technologies can provide not 

only improved outcomes for individual patients, they can expand access to high-quality care. And they 

can improve the value of the care that patients receive, all while supporting health care professionals in 

their roles and patients in their care. 

To address the data-driven nature of machine learning-enabled devices, which lends itself to rapid 

technological improvement over time, the PCCP mechanism described in this guidance provides a way 

for developers to pre-specify specific planned device modifications and how those modifications will be 

implemented. And you'll hear a lot more details about that in a moment. The ability for devices to adapt 

to changes in clinical environments is important so that the devices can remain safe and effective over 

time, despite data shifts that may occur, for example, due to change in clinical practice or emerging 
3

diseases. Our aim is for this type of technological agility to be facilitated by the regulatory agility of the 

PCCP. 

This guidance describes a science-based approach to ensuring AI/ML-enabled devices are safe, effective, 

and can reach their full potential to help people. This is central to FDA's public health mission. This 

approach will put safe and effective advancements in the hands of health care professionals and users 

faster, increasing the pace of medical device innovation in the United States and enabling more 

personalized medicine. 

In addition to across the board or global device updates, under the proposed approach, AI/ML-enabled 

devices could be more extensively and rapidly modified to learn and adapt to local conditions. This 

means, for example, that diagnostic devices could be built to adapt to the data and needs of individual 

health care facilities and that therapeutic devices could be built to learn and adapt to deliver treatments 

according to individual users' particular characteristics and needs. 

Additionally, under the proposal in the draft guidance, a PCCP could enable both changes that are 

implemented manually and changes that are implemented automatically by the software. The 

recommendations for PCCPs that we'll discuss today have been informed by FDA's significant experience 

in regulating AI/ML-enabled devices, the more than 500 authorizations of AI/ML-enabled devices we've 

performed over the past few decades. 

We're proud that this guidance supports FDA's strategic priority to promote health equity, an important 

focus for us at FDA as it is across the federal government. This guidance is consistent with and promotes 

the principles described in the "Blueprint for an AI Bill of Rights," which was issued by the White House 

in October of 2022 and describes principles that should guide the design, use, and deployment of 

automated systems. We at the Center for Devices and Radiological Health are committed to advancing 

health equity as one of our 2022 through 2025 strategic priorities, which affirm that digital health 

technologies should be designed and targeted to meet the needs of diverse populations. 

Predetermined change control plans can take this further by facilitating more rapid and continuous 

improvement of AI/ML-enabled device performance across diverse populations. The approach FDA is 

proposing in this guidance would ensure that important performance considerations, including with 

respect to race, ethnicity, disease severity, gender, age, and geographic considerations, are addressed in 

the ongoing development, validation, implementation, and monitoring of AI/ML-enabled devices. The 

guidance proposes to place a significant and increased emphasis on the importance of transparency, in 

other words, the importance of clearly communicating valuable information about the device to 

stakeholders, including users. Transparency of devices is fundamental for a patient-centered approach 

and supports their safe and effective use. 

This AI/ML guidance represents the next important step in our collaborative patient-centered approach 

to the regulation of AI/ML-enabled devices. And we're showing on this slide some of the highlights of 

the work we've done together over the past few years. We very much appreciate all the feedback and 

input that you've all provided from your responses to our 2019 discussion paper on machine learningenabled software, to your participation in our workshops and our meetings, including on radiological AI, 

transparency of machine learning-enabled devices, and patient trust in AI/ML technologies. 
4

We valued the opportunity to participate in collaborative communities, both those that are wholly 

focused on AI and those where AI is an important theme. And we've made international harmonization a 

priority in our approach to AI/ML through work at the International Medical Device Regulators Forum, 

or IMDRF, and other international efforts, for example, our guiding principles for good machine-learning 

practice. 

I'd like to briefly highlight today two of these recent milestones, the AI/ML discussion paper, leftmost on 

this slide, and the AI/ML action plan toward the middle, and how they're related to the draft guidance 

pictured here on the right, which is the focus of our webinar today. 

In the 2019 discussion paper, we introduced the pre-determined change control plan and described how 

a total product lifecycle-based approach could be used to ensure AI/ML-enabled devices remain safe 

and effective while changing over time. In our 2021 action plan, we described a holistic strategic 

approach to these technologies, ensuring their safety and effectiveness while supporting responsible 

innovation in this space. 

In addition to a focus on good machine-learning practice and transparency about AI/ML-enabled 

devices, the action plan reaffirmed the agency's commitment to continuing to develop the regulatory 

framework for these devices through the draft guidance that we're discussing today. We're now inviting 

you to contribute your comments on this draft guidance to help us continue our proactive and patientcentered approach to these devices. At the end of this presentation, we'll provide some specific 

information on how to submit your comments on the draft. 

Next, I'd like to highlight some recent legislation on PCCPs that our guidance is aligned with. The recent 

Food and Drug Omnibus Reform Act or FDORA includes a specific provision for PCCPs, which adds a 

Section 515c to the Federal Food, Drug, and Cosmetic Act. And we've worked hard to ensure that this 

guidance addresses and is aligned with this provision. That act, or FDORA, granted the FDA authority to 

authorize PCCPs reviewed in premarket notifications and premarket applications. And it clarified that 

changes to a device that are consistent with an authorized PCCP do not require a supplemental 

application.

It may also require that change control plans require labeling for safe and effective use. And we'll 

discuss these principles in greater depth later in the webinar. It's important to note that while the draft 

guidance is focused on PCCPs for AI/ML-enabled devices, the omnibus provision applies to more than 

just AI/ML. And in fact, the bill provides authority for PCCPs for all devices. The guidance we're talking 

about today, while consistent with the new amendment to Section 515 introduced by the provision, is 

focused on submissions of PCCPs for machine learning-enabled device software functions in 510(k)s, De 

Novos, and PMA applications to the agency. 

Ok, so now that we've talked about some of the background, let's dive into the guidance itself, starting 

with its purpose and scope. 

While the PCCP mechanism and the principles in this guidance have broad applicability, this guidance is 

specifically applicable to machine learning-enabled device software functions that a manufacturer 

intends to modify over time. This guidance describes recommendations on information to be included in 

the PCCP as part of a marketing submission for a device. And these recommendations are also 

generally meant to apply to the device constituent part of a combination product when the device 
5

constituent part is or includes a machine learning-enabled device software function. It's important to 

note that the PCCP is a fully optional mechanism within a marketing submission for a device that is or 

includes an ML-DSF. That is, PCCPs provide an available route for introducing certain specific significant 

changes to an ML-DSF, which we hope will synchronize well with the pace of iteration characteristic of 

good machine-learning practice. Devices are not required to include a PCCP as part of their submission 

and may continue to implement device changes via additional premarket submissions to FDA, as 

applicable. 

Now in addition to talking about what's within the scope of the guidance, I'd also like to touch on what is 

not in scope. 

This guidance is not intended to provide a complete description of what may be necessary to include in 

a marketing submission for an ML-DSF. Rather, it supplies general recommendations and examples for a 

PCCP. 

The guidance is also not intended to provide a comprehensive description of the types of modifications 

the agency would consider acceptable on a PCCP. We've included some discussion on the types of 

changes we believe may generally be appropriate to propose within a PCCP and some considerations 

regarding the kinds of changes that may not be appropriate to review in a PCCP. We'll discuss these in 

more depth later in the presentation. 

As each device brought to review will be unique and may have many different considerations that affect 

the needs of a marketing submission in the course of review, it should be understood that ultimately the 

FDA team responsible for reviewing a device and proposed PCCP will determine whether the scope of 

proposed modifications is appropriate for inclusion in such a plan and what evidence and other 

information may be needed to support specific proposed modifications for machine learning-enabled 

device software function in a marketing submission.

We've talked about the scope of this guidance, and now I'd like to say a few words about the different 

pathways for authorization relevant to PCCPs. 

FDA considers the pre-determined change control plan to be a part of the technological characteristics 

of a device. A PCCP may be reviewed in a 510(k) if the device remains substantially equivalent to the 

predicate and safe and effective without any such change. 

If the introduction of a PCCP to a device is found to raise different questions of safety and effectiveness 

from its predicate device, then the subject device within its PCCP could be found to be not substantially 

equivalent to the predicate. Notably, when a device with an authorized PCCP is used as a predicate, only 

the version of the device that has been cleared or approved prior to implementing any of the changes 

delineated in the PCCP may be used as the predicate.

 

So, we've covered the background, including recent legislation, as well as the scope of the guidance. 

Next, we'll continue moving through the guidance, including a review of some definitions and an 

overview of how a PCCP can be established, authorized, and implemented. And for that, I'll pass the 

microphone to my colleague here in the Digital Health Center of Excellence, MiRa Jacobs.
6

MiRa Jacobs: Thanks, Matt. Before we get into a more detailed review of the policy proposed in the 

draft guidance, I'd like to take a moment to go over some definitions we'll be using throughout the rest 

of the webinar. First, to revisit a term that we've already been using today, we have device software 

functions and machine learning-enabled device software functions.

A device software function, or DSF, is a software function that meets the device definition in section 

201(h) of the FD&C Act. As we discuss in other FDA guidances, the term "function" is used here to mean 

a distinct purpose of the product, which could be the intended use or a subset of the intended use of 

the product. A machine learning-enabled DSF, or ML-DSF, is a device software function, as we just 

defined above, that implements an ML model trained with ML techniques.

 

When we discuss data and the various data sets that may be used as part of ML-DSF development and 

improvement, in this guidance we specifically use the terms training, tuning, and testing data. Here, 

training data is used to describe the data used by an ML-DSF manufacturer in procedures in ML training 

algorithms to build an ML model, including to define model weights, connections, and components. 

Tuning data is used to describe the data typically used by an ML-DSF manufacturer to evaluate a small 

number of trained ML-DSFs to explore, for example, different architectures or hyperparameters. It is 

particularly important here to note that we understand the ML community sometimes uses the word 

"validation" when referring to the tuning data and phase. In this draft guidance, to be consistent with 

the language in 21 CFR 820.3(z), we recommend that the word "validation" not be used when referring 

to data or operations related to training or tuning ML models intended for medical applications. 

When we use these terms in the draft guidance, we intentionally preserve this distinction between 

tuning and validation. 

Lastly, testing data is used to describe the data that's used to characterize the performance of a machine 

learning-enabled device software function. The testing phase is expected to provide the data to 

establish a reasonable assurance of safety and effectiveness before an ML-DSF is marketed.

In the draft guidance, we also distinguish between pre-determined change control plans, or PCCPs, and 

authorized PCCPs. A PCCP more generally is considered the documentation describing what 

modifications will be made to the ML-DSF and how the modifications will be assessed. And in the draft, 

we discuss PCCPs as being comprised of at least three parts, a description of modifications, the 

modification protocol, and an impact assessment. We'll revisit each of these parts and discuss 

recommendations for each component here in a little bit.

It's also important to note that a PCCP is intended to include specifically only proposed changes that 

would otherwise require a new marketing submission. An authorized PCCP is one that's been 

established through a device marketing authorization. An authorized PCCP is also considered a 

technological characteristic of the authorized device with which it was established. And a legally 

marketed device's authorized PCCP is the only one that can be followed for the device such that 

implementing those changes would not require a supplemental application. And a PCCP is only 

considered authorized once it's been established via review and authorization by FDA as part of a 

device's marketing submission. 

Now as we highlighted previously, this draft guidance isn't the first time we've introduced the PCCP 

concept. That said, as we transition to discussing the components of a PCCP today, we'd like to make 
7

sure we bring attention to where some of the language we're using for these plans in the draft guidance 

has changed since their first introduction. In the 2019 discussion paper, we talked about PCCPs as being 

comprised of SaMD pre-specifications and an algorithm change protocol.

 

We also described how it was important to discuss the impact of proposed changes on the device and its 

use as well as the collective impact of multiple changes on each other. In the draft guidance, really, we 

preserve these exact same components. But for clarity, we're using the term "description of 

modifications" in lieu of SaMD pre-specifications and "modification protocol" in lieu of algorithm change 

protocol. We've also described an impact assessment as a discrete component of a complete PCCP, 

incorporating the same concepts of assessing modification impact that were presented in the discussion 

paper. 

So following the terms and concepts we just covered and generally aligning with the flow of this 

webinar, the draft guidance itself includes an overview of the policy we proposed for PCCPs for MLDSFs; recommendations for the description of modifications, modification protocol, and impact 

assessment components of a PCCPs; and appendices with example elements that may be useful to 

include as part of a modification protocol, as well as examples illustrating how the proposed policy for 

PCCPs may be applied to machine learning-enabled device software function scenarios. 

So, following that outline, I'll now share an overview of the approach and policy for proposing 

modifications to a machine learning-enabled device software function in a PCCP. 

First, and reiterating what we've already briefly touched on, it should be understood that an authorized 

PCCP is intended to specify planned modifications that if not included in the plan could otherwise 

require a new marketing submission, which does mean that modifications that might be planned for a 

device, but may already be implemented without a new marketing submission in accordance with 

existing regulations and described in the device modifications guidances, would not be the kinds of 

changes that are intended to be included in a PCCP. Those modifications that are part of an authorized 

PCCP can in turn be implemented for the ML-DSF with which it was authorized without triggering the 

need for a new marketing submission. In other words, as long as the changes were detailed in and 

implemented according to the authorized PCCP, the modified device will not need to be reviewed again 

by FDA. 

On the other hand, those modifications that are not part of an authorized PCCP could require a new 

marketing submission, depending on the change. Just as you currently do now for an authorized device 

that doesn't have a PCCP, those planned modifications that weren't specified should be reviewed by the 

manufacturer and implemented pursuant to 21 CFR 807.81 (a)(3) and 21 CFR 814.39 (a) and in 

accordance with the modifications guidance, which may mean a new marketing submission for the 

modified device is required before prior-- or prior to making the change. 

So then if a manufacturer wishes to include a PCCP as part of a marketing submission for a device that is 

or includes an ML-DSF, the draft guidance recommends that the proposed PCCP can be structured with 

three components-- Description of Modifications, a Modification Protocol, and an Impact Assessment. 

Together, these three elements are intended to describe what the manufacturer intends to modify, how 

they will make those modifications while ensuring the device remains safe and effective, and lastly, to 

discuss the benefits and risks of the proposed modifications and how identified risks will be mitigated. A 

little more particularly, the description of modifications section of a PCCP is intended as the section of 
8

the plan where each specific modification a manufacturer wants to implement with an authorized PCCP 

is delineated. Effectively, this section of the PCCP is meant to draw what can be understood as a range 

of FDA-authorized specifications around the device's characteristics and performance. 

The Modification Protocol section is intended to include a description of all the methods that will be 

followed when developing, validating, and implementing the modifications that were described in the 

description of modification section. Each modification detailed in the description of modifications should 

have corresponding methods and metrics for implementation that are addressed in the modification 

protocol. 

Lastly, the impact assessment section of the PCCP is intended to provide an assessment of the benefits 

and risks of each modification outlined in the description of modifications as well as the collective 

impact of those modifications.

It's recommended that this section also provides a discussion of how the activities proposed in the 

Modification Protocol mitigate the risks that were identified in the impact assessment. Basically, the 

impact assessment should help make clear how all these activities help to reasonably assure the device 

with any PCCP-defined modifications implemented will remain as safe and effective as the version of the 

device that will be reviewed at the time of the initial marketing submission. So that is the version of the 

device without any modifications implemented.

 

All right so now let's discuss some recommendations on how to properly include a predetermined 

change control plan in a marketing submission and how to put an authorized PCCP into practice. 

First, to establish a PCCP, it should be included as part of a marketing submission for a device. The PCCP 

will be established as part of the authorization for the device with which it was submitted. And once it's 

been established, it's then referred to as an authorized PCCP. Only those changes that were delineated 

in an authorized PCCP established for a given device may be implemented for it without potentially 

needing an additional marketing submission. So then if a manufacturer wants to establish a new PCCP 

for a previously authorized device, whether it was originally authorized with or without a PCCP, a new 

marketing submission is going to be needed. And that new marketing submission must include all the 

appropriate marketing submission requirements for the device and should include the new proposed 

PCCP so that it can be established as part of the new authorization.

In any marketing submission, when including a PCCP, we do recommend that it be included as a 

standalone section of the submission and listed in the table of contents clearly as the predetermined 

change control plan. We also recommend that it's clearly stated in the cover letter of a submission that 

a PCCP is included. Manufacturers should also plan for the PCCP to be described in any public 

documentation such as the 510(k) summary, de novo decision summary, or PMA summary of safety and 

effectiveness document and approval order for the device, as applicable. It's important for the details of 

a PCCP to be included in sufficient detail to support transparency to users regarding the safety and 

effectiveness of the device. 

Additionally, the device labeling provided for review as part of a device submission should include an 

adequate description of the PCCP and associated changes to ensure appropriate use of the device, 

because device labeling must comply with applicable statutes and regulations, which includes adequate 

directions for use. Along these lines, in a modification protocol, the draft guidance recommends that 
9

manufacturers should include how their labeling will be updated as modifications are implemented in 

accordance with the PCCP to ensure that users may continue to use the device safely and effectively as 

the device changes. And per the addition of Section 515 (c) to the FD&C Act, it should be noted that FDA 

may require that a PCCP include labeling required for safe and effective use of the device as such device 

changes pursuant to such plan. 

Once the device has an authorized PCCP, the modifications detailed in it can be then implemented. In 

the draft guidance, we've provided this flowchart to help illustrate how a manufacturer can walk 

through applying their authorized PCCP to a modification they may want to make. 

First, a manufacturer should assess whether the modification they want to make was specified in their 

authorized PCCP's description of modifications and if they're planning to-- planning and able to 

implement it in conformance with both the methods and performance specifications that were included 

in the authorized PCCP's modification protocol. 

If the manufacturer is able to answer yes to both of these items, then the modification can be 

implemented without an additional marketing submission and documented in accordance with the 

manufacturer's quality system. 

However, if the manufacturer answers no to either of these items, then they should review the desired 

modification and consideration of the applicable laws and regulations to determine whether a new 

marketing submission is required. 

If the manufacturer determines that, while not specified in or implemented according to their 

authorized PCCP, the modification would still not require any marketing submission for the applicable 

laws and regulations, then the modification may be implemented without an additional marketing 

submission and documented in accordance with the manufacturer's quality system. 

However, if the manufacturer finds instead that upon review of the modification, per the applicable laws 

and regulations, that a new marketing submission is required, then the manufacturer should, as you 

may have guessed, submit a marketing submission for the modified device prior to releasing it. Here, it's 

also important to recall that when a new marketing submission is needed, if the manufacturer intends 

for a PCCP to be established with that modified device, the PCCP should be submitted as part of the 

marketing submission so that the modified device and PCCP can be authorized together.

 

So, from this flow, we hope to make clear that the PCCP mechanism is intended to sit alongside existing 

policy regarding the introduction of changes to devices. The PCCP is intended to allow a means for 

certain modifications that would generally require a new marketing submission to be implemented 

without a subsequent additional review by FDA. And modifications outside of those included in a PCCP 

may be approached the same way any desired change would be assessed for a device without an 

authorized PCCP, which does mean that sometimes a supplementary submission to FDA will be needed, 

noting here, of course, that implementing a change to a device that was delineated in a description of 

modifications, but not in accordance with the modification protocol, is still considered a change that is 

outside of those included in the authorized PCCP. And the manufacturers should evaluate it as such.

So, to carry that point forward, manufacturers should review any change that is outside the scope of an 

authorized PCCP to determine whether a new marketing submission is needed. And if it is, the 
10

manufacturer must submit the appropriate submission to FDA before the modified device is marketed. 

Further, if the manufacturer wishes to establish a PCCP with the modified device, that PCCP should be 

included as part of the new marketing submission so both the modified device and PCCP can be 

authorized together.

All right, so then maybe the next apparent question would be how to modify the PCCP itself or the 

device it was authorized with. Modifying an authorized PCCP would clearly be considered a modification 

outside of those included in the authorized PCCP. So, such changes will generally require a new 

marketing submission. And then, as we've just gone over, when a previously authorized device with a 

PCCP is modified, whether that be the device or PCCP itself is modified, such that a new marketing 

submission is needed for the change, then the new submission needs to include both the appropriate 

marketing submission requirements for the device and the proposed PCCP.

Thus, critically, an authorized PCCP is only applicable to the version of the authorized device with which 

it was established. So, if an authorized device is significantly modified, except for the modifications 

specified in the PCCP, a new submission for the modified device will be needed that includes the content 

necessary to establish or reestablish the PCCP. 

Now with all of that, I'd like to turn it over to Cathy to provide a more detailed description of these three 

main components of a PCCP. 

Catherine Bahr: Thanks, MiRa. Let's touch now on some of the recommendations the draft guidance 

provides for each component part of a PCCP. We'll start with the description of modifications, which was 

mentioned earlier, can be understood as a manufacturer defining what the intended device to become 

as it learns. 

As highlighted in the draft guidance, the description of modifications section should detail the specific 

changes a manufacturer would like to make. As these are developed, remember, not all changes that 

would generally require a new marketing submission may be suited for a PCCP. The changes should not 

change a device's intended use. They should describe the resulting changes to device characteristics and 

anticipated performance. And they should only include modifications that can be described specifically 

and that can be verified and validated.

 

Building on the previous slide, when you're crafting the proposed modifications, remember to describe 

each one with a level of detail that helps the reader understand the specificity of the change and the 

impact of the change on the device's safety and performance. An example of specificity would be to 

state that the intent of the change is to improve the performance for a particular subset of the device's 

intended population by increasing the device's sensitivity while maintaining its specificity; instead of just 

stating that the change is to improve the device's performance. Ensure that each modification in the 

description of modifications is clearly and directly linked to a particular performance activity described 

in the modification protocol. And lastly, include information related to the implementation of each 

change.

 

As we saw earlier, not all modifications may be appropriate to include in a PCCP. One component of this 

is ensuring modifications maintain a device within its original indications for use. The draft guidance 

recommends that modifications proposed in a PCCP should be for the purposes of maintaining or 
11

improving the safety or effectiveness of the device and are able to be verified and validated within the 

device's existing quality system. 

The draft proposes three areas of modifications that we believe may likely be reasonable to include in a 

PCCP-- first, modifications that are related to quantitative measures of performance specifications. This 

could, for example, include specific improvements to analytical and clinical performance resulting from 

retraining the machine-learning model based on new data within the intended use population from the 

same type and range of input signal. 

Second, modifications related to device inputs, such as expanding an algorithm to accept data of the 

same signal type from different makes, models, or versions of a data acquisition system; and lastly, 

limited modifications related to device’s use and performance, for instance, authorizing use of the 

device for a particular subset of the broader indication population based on training on a larger set of 

data for subpopulations that wasn't previously available.

 

We talked about the what. Now let's talk about how. 

The modification protocol section should include information tailored explicitly to every proposed 

change included in the PCCP. This means that for each modification outlined in the description of 

modifications, the modification protocol should address the four components outlined on this slide and 

in the draft guidance, namely, data management practices, retraining practices, performance evaluation 

protocols, and update procedures. 

To assure that modifications were implemented safely and successfully, update procedures should 

include both the planned communication and any other means of transparency that will be provided to 

users and the plans for real-world monitoring. To help support the review, the draft guidance 

recommends that the modification protocol also include a description of how proposed methods are 

similar to or different from the methods used elsewhere in the marketing submission. 

The draft guidance includes additional specific recommendations for each of the four parts of a 

modification protocol in Appendix A. These examples hopefully help to more functionally illustrate the 

role the modification protocol is intended to provide in a PCCP and the level of specificity recommended 

when developing these plans as part of a marketing submission.

Up to now, we've discussed how each modification described in the PCCP should be clearly linked to 

activities laid out in the modification protocol. To help demonstrate that each proposed change has 

been addressed completely within the modification protocol, an additional recommendation in the draft 

guidance is to include a traceability table that clearly demonstrates the traceability between the 

modification protocol and the description of modifications. As shown on this slide and available in the 

draft guidance, a simple table can help to clearly show the different methodologies applied to proposed 

modifications, where they differ, and how they correspond to data management practices, retraining 

practices, performance evaluation, or update procedures. While a traceability table is not required, we 

recommend that this information be presented clearly, regardless of format. Providing where to find 

additional detail within a submission helps to facilitate an efficient and comprehensive review. 

The last main component of a PCCP is the Impact Assessment. 
12

The intent of the Impact Assessment is to demonstrate a thorough consideration of risks related to the 

PCCP and an appropriately planned implementation of associated mitigations. An Impact Assessment 

should compare each planned version of the device under a proposed PCCP with the version of the 

device without any implemented modifications.

This means defining the impact of implementing changes on a device's safety and effectiveness. This 

should be done for each individual change, for the impact of one change on another change, and for the 

collective impact of all changes. In other words, recognize that not all modifications proposed in a PCCP 

can or will be independent of other proposed changes. The Impact Assessment should also address how 

the activities in a modification protocol will continue to reasonably ensure that as each new change is

implemented, the device remains as safe and effective as the unmodified version. 

And with that, I'll hand it back to MiRa to share an example that illustrates the application of a PCCP. 

MiRa Jacobs: Thank you, Cathy. Appendix B of the draft guidance includes the following illustration of 

the application of a PCCP and other examples to help demonstrate how the policy and 

recommendations that we've discussed today can be put into practice. Please note that the examples in 

the draft guidance are intended to be illustrative and do not represent examples of complete PCCPs. The 

examples in Appendix B are specifically intended to help clarify the scope of changes that may be 

reasonable to include in a proposed PCCP for a machine learning-enabled device software function.

The example we'd like to share today is regarding a hypothetical skin lesion analysis software that has an 

authorized PCCP. This device is a machine learning-enabled device software function that analyzes 

images of skin lesions by identifying and characterizing its features, for example, color or quantification 

of area change over time, to aid in diagnosis. The device was validated with a specific camera and is 

intended to be used by a primary health care provider. 

For this device, the manufacturer proposes a modification in their PCCP to extend the machine learningenabled device software function for use on additional general purpose computing platforms, including 

smartphones and tablets. This modification also specifies that these general purpose computing 

platforms must include a two-dimensional camera that meets the minimum specifications defined in the 

PCCP. And to implement use of a new platform, the updated device must achieve a minimum 

performance defined in the modification protocol using a specified methodology.

For this device, let's now explore three different modification scenarios, one modification that is 

explicitly defined and methodology for implementation is provided in the authorized PCCP, and two 

additional modification scenarios, which may be reasonable next steps in the device development, but 

are not defined in the PCCP. 

First, let's say that the manufacturer's analytical validation demonstrates the machine learning-enabled 

device software function can be deployed on two additional smartphones that meet the minimum 

specifications that were provided in the PCCP and that the analytical performance using the new image 

acquisition systems is found to be statistically equivalent to the baseline performance. The 

manufacturer proceeds with updates to their device's labeling to reflect the new ML-DSF compatibility 

with additional smartphones. And communication updates on the device compatibility are also 

provided.
13

In this scenario, because the device modification was specified in the authorized PCCP, and it was 

implemented in conformance with the authorized PCCP, the device modification would not require a 

new marketing submission. And the manufacturer could appropriately proceed with introducing the 

modification. The manufacturer should also ensure that the modification is documented in accordance 

with their quality system. 

A second possible scenario might be that this manufacturer also wants to deploy a modified ML model 

that uses images captured by a thermographic camera. However, this new camera technology was not 

specified in the PCCP. In this case, because this modification wasn't included in the PCCP and could 

significantly affect the safety or effectiveness of this device, the manufacturer should bring the 

proposed modified device to the FDA for review and a new submission before it's marketed. 

On our third and last possible scenario, might be that the manufacturer wishes to distribute a new 

version of their device that's patient-facing. This version of the device would provide an analysis of 

physiological characteristics of the skin lesion, as the marketed version of the device does, but it would 

be patient-facing and direct patients to follow up with a dermatologist based on the preliminary analysis 

of the malignancy of the skin lesion. In this case, just as in the last scenario, because this modification 

wasn't included in the PCCP and could significantly affect the safety or effectiveness of this device, the 

manufacturer should bring the proposed modified device to the FDA for review in a new submission 

before it is marketed.

Additionally, the change to intended user population here could raise many new risks that were not 

considered in the original review of the device or its PCCP. 

All right, with that, and now that we've walked through an example of applying a PCCP in a couple 

different scenarios, I'd like to go ahead and hand the mic back to Matthew to wrap up and share more 

on how you can submit your comments on this draft guidance. Thank you.

Matthew Diamond: Thanks very much, MiRa. To conclude this portion of the webinar, I'd like to 

summarize what we aim to accomplish with the guidance and what we talked about today. With this 

guidance, our aims were to describe FDA's proposed approach to AI/ML-enabled devices to support 

their iterative development and improvement over time; to build on the agency's longstanding 

commitment to developing innovative approaches to ensuring that safe and effective digital health 

technologies are available to patients; to include recommendations on information to be included in a 

PCCP provided as part of a marketing submission for an AI/ML-enabled device; to specify that 

modifications to a machine learning-enabled device software function made in accordance with an 

authorized PCCP can be implemented to the device without a new marketing submission; and to include 

details on the recommended content of these sections, with additional clarity provided in the many 

examples in the document's appendices. 

I'd also like to point you to a number of resources that were referenced during the presentation to 

provide additional context and clarity for the recommendations in the draft guidance. You can see them 

all on this slide, with links here for your reference. 

And last, but certainly not least, I'd also like to strongly encourage your feedback on this draft guidance 

and our approach in general. We've made it to this point based on all the input you've provided, and we 

need your continued input as we revise this draft into its final form. With all of your help, we'll continue 
14

to take a collaborative approach to AI/ML-enabled devices for the benefit of public health. Please note 

that while you're able to provide your comments on any guidance at any time, we strongly encourage 

you to submit your comments before the comment closure date so we can carefully consider your 

feedback as we work on this guidance's finalization. 

And here's the specific information. You can submit your comments to docket number 2022-D-2628 by 

July 3 at the URL on this slide. And you can access the draft guidance via the link you see here as well. 

Thank you very much for your time and attention today. I'll now turn this back over to Elias for the 

question and answer portion of this webinar as we welcome your questions about the guidance. Thank 

you. 

Elias Mallis: Thank you, Matt. And thanks to all of our presenters for your very comprehensive overview 

of this really notable draft guidance. Really remarkable. Let's transition now to the interactive question 

and answer segment of our program, where our audience, now you get to ask your questions to our 

panel. 

But first, I'd like to introduce several additional panelists who will join our team in answering your 

questions. Dr. Katherine Drzewiecki, Policy Advisor in the Office of Policy; Dr. Vinay Pai, Digital Health 

Specialist in the Digital Health Center of Excellence; Dr. Berkman Sahiner, Senior Biomedical Research 

and Biomedical Product Assessment Service Expert in the Office of Science and Engineering 

Laboratories; Aneesh Deoras, Assistant Director for Cardiac Ablation, Mapping, and Imaging Devices 

Team in the Office of Cardiovascular Devices from the Center's Office of Product Evaluation and Quality. 

Thank you, panelists, for joining us today. 

So, let's now review how we'll manage this segment. To ask a question, please select the Raise Hand 

icon which should appear on the bottom of your Zoom screen. I'll announce your name and give you 

permission to talk. When prompted, please select the blue button to unmute your line, and then ask 

your question.

Now, a few tips about asking questions. Please limit yourself to one question and try to keep it as short 

as possible. And second, we appreciate that you may have a very specific question involving your device 

or device scenario. Please note that we might not be able to answer very specific questions, but we'll try 

to frame a broader response based on what's proposed in the guidance. Remember, this is your chance 

to better understand and get clarity on what we intend in a proposed guidance. So, we ask you to try to 

frame your questions with this in mind. Now after you've asked your question, please lower your hand 

and mute yourself again. If you have more questions, no problem. Just go ahead and raise your hand 

again. And we'll come back to you if we have enough time in our segment. Now as we wait to get to 

some of your questions, let's welcome our newest panelist with a few questions that we've gotten over 

the past few weeks about the draft guidance. 

So, Katherine, I'm going to start with you. Welcome to our panel today. And our question for you is as 

follows. What are FDA's plans for broadly implementing pre-determined change control plans, that is, 

PCCPs, across all device areas? 

Katherine Drzewiecki: Yeah, thanks, Elias. This is a very good question, likely coming up due to the 

change in statute last year that Matthew had mentioned during the presentation. To recap, on 
15

December 29 last year, section 515c on pre-determined change control plans for devices was added to 

the Federal Food, Drug, and Cosmetic Act by the Food and Drug Omnibus Reform Act or FDORA as part 

of the Consolidated Appropriations Act. And again, as Matthew mentioned, this gives FDA authority to 

clear or approve PCCPs for all devices. So, this change has a big impact. And we are actively working on 

implementation, including updating our policies and procedures. And some of you may have seen, 

we've already updated eSTAR so that manufacturers may add an attachment with a PCCP. If 

manufacturers submit the PCCP for their device, we'll consider that in the course of premarket review. 

And as always, remember that you can submit a Q-submission if you have questions about a PCCP for 

your device, whether or not it is a machine learning-enabled device software function. For today, let's 

focus on this draft guidance, though, which contains our proposed recommendations for PCCPs for 

AI/ML-enabled devices. 

Elias Mallis: Thank you, Katherine, and, again, welcome to the panel. All right, let's continue introducing 

our new panelists. Aneesh, I'm going to send this question over to you. Again, welcome, and thank you 

for joining us. So, this next question-- both the action plan and this draft guidance refer to 

predetermined change control plans for AI/ML-based devices. So, what's the next step to implement 

PCCs-- PCCPs-- in the premarket and post-market review setting? 

Aneesh Deoras: Thanks, Elias, that's a really excellent question. It's important to remember that this 

guidance, which proposes recommendations for the content of PCCPs for ML-DSFs, is a draft guidance, 

and therefore not for implementation at this time. We believe the final guidance on this topic will help 

provide additional clarity on PCCP implementation and more helpful recommendations for the content 

of PCCPs.

However, as Katherine just mentioned, with the enactment of FDORA, manufacturers may submit, and 

FDA may clear or approve PCCPs in device marketing submissions. We do still encourage manufacturers 

to engage with FDA early via the Q-submission program to discuss the planned PCCP for an ML-DSF. And 

it's also important to remember that the approach for each PCCP will be tailored to an individual device 

and the proposed changes. 

Elias Mallis: All right, thank you for that response, Aneesh. And again, welcome. Vinay, let's get to you 

for our next question. And again, welcome to our panel. Our next question is, what does this draft 

guidance offer that hasn't been made available before? 

Vinay Pai: Thanks, Elias. We believe that this draft guidance is the first complete set of proposed 

recommendations to address what should be included in a PCCP from an ML-DSF, including anticipated 

changes to an ML-DSF and how these changes will be assessed and implemented in accordance with the 

PCCP. By including a PCCP in a marketing submission for an ML-DSF, a manufacturer may reduce the 

need for subsequent additional marketing submissions for each future iteration of the ML-DSF. 

We expect this approach to enable manufacturers to make modifications and updates more easily to 

their devices while also maintaining the FDA's ability to assure continued device safety and 

effectiveness. We also think that PCCPs can help advance health equity, one of CDRH's strategic 

priorities, by facilitating more rapid and continuous improvement of AI/ML-enabled device performance 

across diverse populations. The approach could help ensure that important performance considerations, 

including with respect to race, ethnicity, disease severity, gender, age, and geographical concentrations, 
16

are addressed in the total product lifecycle of the AI/ML-enabled devices and that such information is 

clearly communicated to the device users. 

Elias Mallis: Thank you, Vinay. Thank you for that response. All right, let's welcome our final panelist to 

the discussion, Berkman. I'll send this question to you again. Thank you for joining us. So, the question 

for you-- the 2019 discussion paper is specific to AI/ML-based software as a medical device, that is, 

SaMD. Now why does this draft guidance include both SaMD and SiMD, that is software in a medical 

device? 

Berkman Sahiner: Thank you, Elias. AI/ML-based software has become an important part of many 

devices. And the term "software as a medical device" refers to standalone software-only devices or 

software intended to be used without being part of a hardware medical device. However, machine 

learning-enabled device software functions can also be integrated into or within a hardware medical 

device, known as software in a medical device or SiMD. Since SiMD and SaMD share many 

characteristics, we wanted to develop a policy that was applicable to both. 

That being said, SaMD and SiMD are different and present different risks. The type of modifications and 

information in a PCCP for SaMD may be different than for SiMD. For example, for SiMD in a PCCP, it may 

be important to consider how the software modifications may impact hardware capabilities or control 

features of that hardware which may not be present in SaMD. Despite these differences, we concluded 

that the commonality of the machine-learning features in SaMD and SiMD allows us to make this 

guidance a bit more general than the 2019 discussion paper. And we included both SiMD and SaMD in 

this draft. Thank you. 

Elias Mallis: Thank you, Berkman, and again, welcome to our panel. All right, let's get to some of the 

questions that we've gotten. Obviously, a lot of hands raised, so we're going to try to get to as many 

questions as we can. Mona, I'm going to start with you. Please unmute your line and go ahead and ask 

your question to our panel.

Mona, would you like to try to ask your question now? All right, I will move on to our next individual, 

and we'll try to come back to you if we have a chance. Girish, I'm going to unmute your line to allow you 

to speak. So please go ahead and ask your question to our panelists. 

Girish: Sorry, that was a mistake. I-- please continue. 

Elias Mallis: OK, well, thank you for joining us. We'll continue with our next individual. All right, Ebrahim, 

I'm going to unmute your line. Please go ahead and allow yourself to speak and ask your question to our 

panel.

Ebrahim Sherkat: Hi, this is Ebrahim Sherkat from Wise IOT Solutions. One question is about the-- if we 

are planning to, let's say, detect 14 arrhythmia, can we put in PCCP that in the first version, we are 

detecting, let's say, 10 arrhythmia, and we are planning by having more data, we include another 4 

arrhythmia, or no? 

Elias Mallis: Thank you for your question. Aneesh, I'd like to direct it to you for a response from our 

panel. 
17

Aneesh Deoras: Sure. Thanks so much Ebrahim. I would really recommend coming in with a presubmission because that's a little bit specific. But something like that would be something we'd be open 

to discussing in the context of a PCCP for an ML-DSF. 

Ebrahim Sherkat: Thank you. 

Elias Mallis: Ebrahim, thank you for joining us, and thank you for your question. Alex, we're going to 

continue our Q&A. I have unmuted your line. And please go ahead and hit the prompt and ask your 

question. 

Alex Friedman: Hi. Can you hear me? 

Elias Mallis: Yes, you sound great. Thank you. 

Alex Friedman: OK, terrific. Hi. Well, thank you to the FDA for all the great work leading up to this. And 

thanks for the guidance document and the opportunity to ask the question. I'm with Beckman Coulter 

CDS. The guidance document mentions automatically-- the software automatically updating in a number 

of places. And I think many people have been waiting to see whether the agency would preapprove, preauthorize local tuning. 

So, when a model is implemented in a specific area of the country, we know that there's natural drift 

that always happens and bias, et cetera. And if a model can update automatically based upon truly the 

full local demographics as it goes forward, that's-- without having to submit another 510(k)-- that really 

helps industry. Of course, there are some risks to public health. So can you clarify whether automatic 

means-- is equivalent to the terms the people use when they say "unlocked" or "no human in the loop?"

Is that potentially-- can be pre-authorized through this process? Thank you very much.

 

Elias Mallis: Alex, thank you for your question. Berkman, can we ask you to provide a response for 

Alex? 

Berkman Sahiner: Yes, certainly. So, the intention is to be broad about the types of modifications that 

can be performed. As you mentioned, sometimes the modifications may be very controlled. And after a 

sponsor does a maybe hand-checking of whatever is going on and then allowing a modification, but with 

the proper controls in the PCCP, it can also be automated, like you mentioned. 

Although I would like to mention that would probably require a higher bar in terms of showing that your 

updates and modifications will be safe and effective if you perform them automatically. So, yes, it is 

possible. And we wanted to be comprehensive in our draft guidance. But it will probably need more 

closer evidence, more evidence that the performance is not going to unintentionally deteriorate.

Elias Mallis: Berkman, thank you for that reply. Alex, did that answer your question? 

Alex Friedman: Yeah, that's wonderful. I mean, I think of information meetings and pre-subs, right? You 

have a nice, open dialogue about it. You assess all the risks that could happen. You discuss the risk 

controls that will be baked in from the beginning. And you gain trust with each other, and you move 

forward. 
18

Elias Mallis: Thank you, Alex, for the question. Again, thanks for joining us. Ana, I'm going to go to you 

next. I'm allowing you to unmute yourself and ask your question.

Ana: Hello, this is Ana from Abbott. Thank you so much for the great webinar, and thanks for the 

guidance and the panelists. My question is on the tuning part of the algorithm. For any AI/ML-based 

devices, the base is an ML model. And as you know, over time we need to tune it by getting more data 

from the same device when it's in the hand of the users.

So, the question is you discuss about the tuning data, and when you refer to tuning data, it was in terms 

of initial submission and testing their, basically, algorithm. But what about tuning the model over time 

using the data that is coming out of larger population? Is it something that automatically PCCP would 

cover? Or does it need a different section or a new submission? I would appreciate any 

recommendation on that part. Thank you. 

Elias Mallis: Ana, thank you for your question. Vinay, I'd like to turn it to you for a response to Ana.

Vinay Pai: Yes, thanks, Ana, for the question. I think we do talk about that quite a bit in our aspects 

related to how you build your modification protocol, that we totally understand that when you deploy it 

out in the real world, that you'll be using real-world data to actually improve the algorithm performance. 

And so, I think when you talk about, if you look at the data management practice things that you can put 

in that, as well as with returning practices, those are some of the aspects that we would welcome from 

the sponsor when they're coming in for their submission. But I think also, I think as you mentioned 

before, coming into our discussion through the pre-submission process I think would really help ease the 

process.

Elias Mallis: Thank you, Vinay, for that response. Ana, did that answer your question? 

Ana: Yes, thank you. 

Elias Mallis: OK, thank you very much again. Thanks for joining us. Lane, I'm going to go to you next. 

Please unmute your line and share your question to our panel. 

Lane Desborough: Excellent. Thank you. So, my question is, are traditional adaptive control algorithms 

in scope of AI/ML PCCPs, so things like PCLC, APDS, IAGC devices may include these algorithms to adapt 

their base control loops for changes in patient behavior or physiology over time. So, in other words, 

there are traditional control engineering approaches within the scope of AI/ML. 

And just for context, one of the things that was revealed in the excellent presentation was ML model 

trained with ML techniques. Well, these training, tuning, testing data methods have been cornerstones 

of statistical best practice of system identification for closed loop feedback control algorithms for 

decades, long before ML. So, in summary, are closed loop feedback control algorithms considered to be 

within the scope of this guidance? 

Elias Mallis: Lane, thank you for your question. We'll direct that response to Berkman. 

Berkman Sahiner: Yes. We did not specifically focus on closed loop control systems in this draft 

guidance. So, our intention was more for systems that are, as you mentioned, trained and tested with 
19

machine-learning models. So, if it is-- and I don't know exactly about maybe the specific kinds of such 

closed loop systems that are trained using traditional engineering methods. 

But my suggestion is to in your pre-submission to the FDA, mention that this is trained, or this is using a 

traditional control engineering approach. And justify why you would not need a PCCP. And then we also 

have a guidance for physiologic closed loop systems. And we can make a link to that available in the 

chat-- a draft.

Elias Mallis: Thank you for that reply. Lane, did that answer your question? 

Lane Desborough: Mostly. I just wanted to say I'm super excited about PCCP. And I'm very hopeful that 

this is actually within-- traditional approach is considered to be within scope, because in particular, 

things like OHT7 Diabetes branch, there is a lot of this taking place right now. And right now, that 

process of implementing a new algorithm that has all the hallmarks of something that's evolving over 

time using ML techniques is taking a very long time. So, I'm super optimistic that this is actually within 

the scope. Thank you. 

Elias Mallis: Lane, thank you for your question and thank you for your enthusiasm for this technology 

and to your products. We'll continue with our Q&A. Richard; we'll go to you next. I'm unmuting your line 

now. Please go ahead and share your question to our panel. Richard, I will try to unmute your line again. 

Again, please join us if you have a question to share. 

Richard Frank: Yes, can you hear me now?

 

Elias Mallis: Yeah, you sound great. 

Richard Frank: OK, great, thanks. First of all, I'd like to congratulate the FDA for their ongoing adaptation 

of regulatory oversight processes to take account of the pace of innovation to ensure that patients gain 

access to the benefits of these innovations while still ensuring safety and efficacy. My question was 

substantially answered already by Berkman in response to the prior question about automaticity and 

this still being within the scope of PCCP, although I would have used more precise terminology, such as 

we do in the CPT editorial panel of augmentative and autonomous.

I find it very constructive that the FDA would be willing to consider elevation from purely assistive 

devices to augmentative or even autonomous within the context of PCCP, so long as it remains in 

concert with the other constraints on this. So, Berkman, if I've said anything that assumes too much 

from your answer, please give a clarification now. Thanks very much. 

Elias Mallis: Richard, thank you for your remark. I actually will turn it to Berkman. Is there anything you 

wish to elaborate on or clarify with the prior remarks? 

Berkman Sahiner: Yes. I think the previous question about the automaticity is about whether the 

updates are automated or not and not really whether the device is autonomous or not. So, I'd like to 

make a distinction between the two. You can have automated updates to a device that is still assistive to 

a clinician. So that was the content within which I tried to answer that question. I don't think we have 

anything specific in this guidance about autonomous AI, but you know very well that we had a meeting a 

few years back that focused on autonomous AI. And it is something that we're keeping our eyes on. But 

this guidance does not specifically focus on autonomous or assistive AI. 
20

Elias Mallis: Berkman, thank you for that follow-up comment and remarks. We'll continue with our 

Q&A. We have about 5 minutes left, quite a few hands raised. So, I'll ask for our next folks to be pretty 

crisp with your questions and then our replies. Cristen, you're up next. Please unmute your line and go 

ahead and ask your question. 

Cristen Taylor: Hi. Thank you. And thank you for the panelists for the time in answering these questions. 

The question is pretty brief. Just, does the agency intend to extend the scope of this document or the 

principles of it to CDER and CBER's Drug Development Tool Qualification Program? 

Elias Mallis: Kristen, thank you for that question. Matt, may I ask you to take the response? 

Matthew Diamond: Yeah, thanks very much for the question. We work very closely with our colleagues 

across the agency. And I'm very pleased that this guidance was issued in partnership with CDER and 

CBER. And it is intended specifically for medical devices that are enabled by machine learning. But we 

know that there are many applications of devices and non-device technology as tools for the 

development of medical products. And so, while, again, the scope of this guidance is focused on devices, 

I think some of the principles are more broadly applicable. And we will continue to work with folks 

across the agency. And I think there's some very exciting work going on there as well on the applications 

of machine learning in drug development, too. 

Cristen Taylor: Thank you. 

Elias Mallis: Thank you for the question, Cristen. And Nick, we'll go to you next. Please go ahead and 

unmute your line and ask your question. 

Nick Faver: Hi. I was wondering if you could speak to how this guidance and even the concept of PCCPs 

in general relate to or might someday modify existing guidance such as deciding when to submit a 

510(k) for a software change to an existing device. Is the future goal to require PCCPs in all cases in 

order to justify not submitting future changes? Will it be required for all future instances where you 

might do a letter to file? Or do we consider this mainly just important for AI/ML DSFs? Could you 

comment on that? 

Elias Mallis: OK, thank you for that question. Katherine, we haven't heard from you in a little bit. May I 

have you provide a initial response? 

Katherine Drzewiecki: Sure. Thanks, Nick. Yeah, I mean, there's a lot of things that we're thinking about. 

As I mentioned earlier, PCCPs can be used for all devices. And so how this may impact our existing 

policies or new policies is something that we're actively working on. 

Elias Mallis: Thank you, Katherine. And thank you, Nick, for the question. Roni, I'm going to go to you 

next. Please ask your question of our panel.

Roni: Hi. Thank you. Can you hear me? 

Elias Mallis: You are clear. There's a little bit of feedback, but please proceed with your question. 
21

Roni: My question is real quick. I was wondering if this-- such an amazing change-- will be part of the 

RTA 510(k) submission? 

Elias Mallis: OK, thank you for that question. We can look to our team for a reply to that one. Aneesh, 

may ask you for your thoughts on the implementation into the RTA? 

Aneesh Deoras: Sure. So, I guess in a sense, do you mean is the part of the refuse to accept checklist 

going to include predetermined change control plans? 

Roni: Yes, that's what I wanted to know. 

Aneesh Deoras: Yeah, so no plans at this time to include them as part of that. We will, of course, take 

note if you have a PCCP during that phase. And then, of course, I would refer you to other draft 

guidances on 510(k) RTA checklists, which include the eSTAR program and certainly the changes that are 

going to come in the fall of this year. 

Roni: Thank you very much. 

Elias Mallis: Thank you for the question. Thank you, Aneesh. Caitlin, I think we have time for one more 

question. So, we'll ask for you to share your question for our panel. Caitlin, are you with us? All right, I'm 

going to proceed with Kiko. I'll give you the last question of our segment. I've unmuted your line. Please 

ask your question to our panel. 

KiKo Wemmer: Exciting, thank you. I'm specifically interested in the potential to quantify and 

standardize concepts such as data quality and algorithm performance. However, the guidance does not 

seem to specify any baseline standards for things like this does the FDA have expectations at the 

moment? And if not, what is the agency's plan to potentially standardize these things moving forward? 

I'm specifically interested in these things as they relate to performance across high-risk subpopulations 

and subgroups for algorithms and deployment. 

Elias Mallis: Thank you for that question. Berkman, we'll ask you to provide a reply to our stakeholder. 

Berkman Sahiner: Yes, standardization of data quality and reference standard and all of that is 

something that we're closely looking into. But we did not want to include those in this draft because this 

is already a very long and involved draft. And those kinds of standardization are, I think, necessary, 

regardless of whether you have a change control or not, even for devices that are not going to be 

updated. But this is something that we are working on as an agency in-- at CDRH. And it is in our action 

plan released a few years back as well.

KiKo Wemmer: Thank you so much.

Elias Mallis: Thank you, Kiko, for the question. Thank you, Berkman, for that reply. This will now 

conclude our Q&A segment. I'd like to turn the floor back over to Matt for his final thoughts for our 

audience today and the draft guidance. Matt, the floor is yours.

Matthew Diamond: Elias, thank you so much. And thank you, everyone, for your participation today. 

And thank you for all your collaboration in digital health initiatives that brought us here to this guidance. 
22

Your input was instrumental for developing this draft guidance. And we need your feedback on it to 

finalize it. And we're really interested in your feedback and suggestions on all of our initiatives here at 

the Digital Health Center of Excellence across the Device Center and across FDA more broadly. 

So please provide your comments to the public docket. Please continue collaborating with us in all the 

initiatives that we're doing. And we can make sure that these technologies and all their benefits are 

available to patients, that they're safe and effective, and that they're available expeditiously. So again, 

thanks again for the collaboration and thanks for your participation today. 

Elias Mallis: Matt, thank you very much for those remarks. This will now conclude today's CDRH 

webinar. I'd like to thank our entire FDA panel of experts for the discussion on really an interesting and 

impactful topic. Catherine Bahr, Doctors Matthew Diamond, Mira Jacobs, Katherine Drzewiecki, Vinay 

Pai, Berkman Sahiner, and Aneesh Deoras. Also, my thanks to you, our audience, for your participation 

and all the great questions you asked today.

 

I'll make a quick plug. If there were questions, we didn't get to today, feel free to email the Digital 

Health Team directly at digitalhealth@fda.hhs.gov. It's also listed on the cover page of this draft 

guidance, so you can track that to as well. 

Now a recording of today's webinar, the presentation and transcript, will be posted to CDRH Learn in 

hopefully a couple of weeks. Please visit CDRH Learn at the link shown on this slide. And you can check 

that out. This topic will be placed under the section Specialty Technical Topics and under the subsection 

Digital Health. Here's a screenshot of where you can find this webinar. And if you're interested in 

learning more about the great work of the Digital Health Team, please check out that section. There's a 

lot of great content and material from that team as well. 

Now for additional questions about today's program and about webinars in general, feel free to email us 

at DICE@fda.hhs.gov . We also encourage you to participate in a future CDRH webinar. We now have 

some really interesting topics coming up over the next few weeks, so please join us. A listing of these 

events is available at the bottom of this slide. Once again, this is Elias Mallis of the Division of Industry 

and Consumer Education. Thanks for joining us today. Take care, and we'll see you next time. 

**********

END