FDA Webinar

Moderator: Irene Aihie

10-14-19 

Page 1

FDA Webinar: 

Changes to Existing Medical Software Policies Resulting from Section 3060 of the 21st 

Century Cures Act: Final Guidance

Moderator: Irene Aihie

November 14, 2019

2:00 pm ET

Coordinator: Welcome and thank you for standing by for today's conference. All 

participants will be in listen-only mode until the question-and-answer session. 

At that time to ask a question, please press Star 1. Today's conference is being 

recorded. If you have any objections, you may disconnect at this time. I would 

now like to turn the conference over to Irene Aihie. Thank you. You may 

begin.

Irene Aihie: Hello. And welcome to today's FDA webinar. I am Irene Aihie of CDRH's 

Office of Communication and Education. On September 27, 2019, the FDA 

issued the final guidance titled Changes to Existing Medical Software Policy 

resulting from Section 3060 of the 21st Century Cures Act. This guidance 

provides FDA's current thinking regarding the amended revised definitions 

and the resulting effect the amended definition has on FDAs guidances related 

to medical device software.

Today, Bakul Patel, Director of Digital Health and Matthew Diamond in the 

same division both here at CDRH will present an overview of the final 

guidance document. Following the presentation, we will open the line for your 
FDA Webinar

Moderator: Irene Aihie

10-14-19 

Page 2

questions related to the information provided during the presentation. 

Additionally, there are other center subject matter experts here with us today

to assist with the Q&A portion of our webinar. 

Now I give you Bakul.

Bakul Patel: Thank you, Irene. And welcome everybody to the webinar. Hopefully we can 

cover today the topic of the five guidances that we published on September 

27. But before we do that, let me just walk you through sort of the 

background and then hand it over to Matthew to dive into details about the 

3060 guidance and the nuances and the details that went into modifying our 

existing policies that we had laid out prior to the 21st Century Cures.

So let me just start with this picture of this page approach to regulating and 

overseeing software and digital health products. As we think about 

(unintelligible), I think we need to think about how do we focus narrowly our 

approach and overseeing so that we are focusing our efforts on things that 

matter the most. At the same time, we are focusing on those functionalities 

that enable these products to be medical devices and in a way that gives us 

independence from the platform changes and innovation that's happening. 

And allows us to not only promote responsible innovation but also promote 

patient engagement where patients are the center of the discussion where we 

are having in this world of digital health.

We also want to highlight that this approach has been - is what we've been 

taking for the last almost 10 years in developing a method and a way to think 

about patients and the safety of the patients for these products. But keeping all 

these actors in balance is really what our policies are developing, and we've 

developed over the last many years. 
FDA Webinar

Moderator: Irene Aihie

10-14-19 

Page 3

Today, we are finalizing our interpretation of 21st Century Cures because 

really look at how FDA had already thought about (unintelligible) digital 

health produces where the Cures Act fundamentally codifies our policies 

which is in line with our least burdensome approach to device regulation. Just 

to give you a really high level overview on the 21st Century Cures Act, the 

Section 36D of the Cures Act basically amended the device definition and 

removed certain software functions that we had previously said would be 

under what we coined enforcement discretion which basically mean our 

enforcement priorities would not lie to those lower risk products. This final 

guidance is making that interpretation final, modifying our current policies so 

that we are aligned and we're implementing the Cures Act. 

Just to highlight and remind people what the Cures Act sort of outlined, it 

basically said administrative support functions of that exists in any product or 

any system that is highlighted in the work we did in the FDASIA health IT 

effort is now getting codified to 21st Century Cures. The only wellness 

products we said certain products are lower risk and we would not be 

enforcing a requirement. Electronic patient records which are also part of the 

discussion of the (FDASIA) health IT discussion and health management

functionality are also now something that we have basically said is not part of 

the device definition.

And then medical device data systems which we promulgated and regulations 

call MDDS. That function and the functionality of those kind of products are 

also no longer considered medical devices. The Act also talked about clinical 

systems support. We use the term clinical decision support in the short form 

for that last provision which talks about, you know, how (FDASIA) health IT 

report identified both function in the health management functionality.
FDA Webinar

Moderator: Irene Aihie

10-14-19 

Page 4

Today we are going to focus only on the top four parts of the Act and not 

about the part E which is clinical Decision Support. We discussed that in the 

previous webinar, that particular topic of clinical Decision support. So we will 

focus our conversation today and the discussion today on the top four and how 

it sort is reflected in the guidance that we published and the interpretation. 

And the effect of that interpretation on our existing policy.

With that, I want to turn it over to Matthew to help us talk through the details 

about what was explained in the guidance and finally open up for questions. 

Matthew?

Matthew Diamond: Thank you very much, Bakul and Irene. It's good to be here speaking with 

you today about the changes to existing medical software policy resulting 

from Section 3060 of the 21st Century Cures Act guidance which we can just 

call the 3060 guidance for short. And let's take a moment and review the 

objectives for today's webinar.

Number 1, we're presenting what software functions were excluded from the 

device definition by the 21st Century Cure's Act. Which we can simply refer 

to as the Cure's Act. And Bakul has already introduced this. And Number 2 

will explain how a number of FDA's existing software guidances have been 

updated to reflect that change to the device definition. To be clear, if a 

software function is excluded from the device definition that means that we do 

not consider it to be a medical device function. And as Bakul alluded to, we've 

adopted a function-based approach to digital health regulations and that's why

we're speaking here in terms of functions.

So let's talk a little bit more about the software provisions of Section 3060 of 

the Cure's Act. And there's a lot of words on this slide but it's worth going 

over the most important points. And first and as we've already mentioned, 
FDA Webinar

Moderator: Irene Aihie

10-14-19 

Page 5

Section 3060 defines some set of software functions that are not devices. 

Bakul already showed on the previous slide the different categories, A through 

E of the FD&C Act 520(o)1 of software functions excluded from the device 

definition, and we'll revisit them again in more detail soon.

Second, it states that the FDA shall not regulate non-device functions of a 

product with multiple functions, but can consider the impact of non-device 

functions on the device functions. Next, there is a process by which FDA can 

regulate software functions that are excluded from the device definition by the 

Cures Act if the agency finds that it would be reasonably likely to have 

serious adverse health consequences. And additionally, software used in the 

manufacture and transfusion of blood and blood components for humans are 

not excluded from the device definition by the Cure's Act even if they would 

otherwise be.

So here is a list of the final guidances that were updated based on the Cures

Act. In other words all of these guidances were published previously and have 

now been updated, or in one case withdrawn, with the publication of the 3060 

guidance. They include the mobile medical app guidance which is now called 

the policy for device software functions and mobile medical applications. The 

general wellness policy for low-risk devices, medical device data systems, 

medical image storage devices, and medical image communication devices or 

MDDS, off-the-shelf software used in medical devices, and guidance for the 

submission of premarket notification for medical image management devices 

which is actually being withdrawn.

So we're now going to walk through some of the changes to the 3060 

guidance, software category by software category. And the way we’ll do this

is that we’ll first discuss if there were any changes to the 3060 guidance from

draft to final. And then for areas where there is another affected guidance, 

we’ll discuss the highlights from that affected guidance.
FDA Webinar

Moderator: Irene Aihie

10-14-19 

Page 6

We'll start with the changes to the 3060 guidance related to the types of 

software functions described in 520(o)1A of the Food, Drug and Cosmetic Act 

and then we’ll make our way down the Act from A to D. 

And so here we see the first set of software functions excluded from the 

device definition in Section 3060. They are intended for administrative 

support of a healthcare facility. These functions include maintenance of 

financial records, information about patient population, and laboratory 

workflow. This slide highlights changes from what was written in the draft

3060 guidance in the left column to what is now the final 3060 guidance in the 

right column. So in the final guidance in this area, we did not make any 

changes in FDA policy. But we did clarify, however, that certain laboratory 

information systems include software functions that remain devices.

An important note here is that FDA generally did not consider these 

administrative support software functions to be devices even prior to the 

Cure's Act.

The next slide summarizes the second set of software functions to be excluded 

by the Cures Act described in 520(o)1B. They are intended for a purpose 

related to general wellness and are described in detail in the general wellness 

guidance. We won't spend too much time on this slide because we have 

unpacked the info of general wellness into the next few slides. The main point 

to take away from this slide is that there is no change in policy for the low 

risk, general wellness products from the draft 3060 guidance to the final 3060 

guidance. To summarize, there are changes to the general wellness guidance 

as a result of the Cures Act. But there are no policy changes related to general 

wellness in the final 3060 guidance compared with the draft 3060 guidance.
FDA Webinar

Moderator: Irene Aihie

10-14-19 

Page 7

So let's go ahead and get into more detail on some of the main point of the 

updated general wellness guidance. The general wellness guidancedescribes 

two categories of general wellness intended uses. And this should be a 

review. It's not new to this guidance update. Category 1 has an intended use 

that relates to maintaining or encouraging a general state of health or a healthy 

activity. Category 2 has an intended use that relates to the role of a healthy 

lifestyle with helping to reduce the risk or impact of certain chronic diseases 

or conditions when it is well understood and accepted that healthy lifestyle 

choices may play an important role in health outcomes for the disease or 

condition. 

So what's the regulatory status of these two categories of wellness products? 

Let's start with what we just called Category 1 general wellness software 

functions. The software functions for maintaining or encouraging a healthy 

lifestyle are now excluded from the device definition by the Cures Actthat is 

as long as the software function is unrelated to the diagnosis, cure, mitigation, 

prevention or treatment of a disease or condition.

Prior to cures, and as described in the previous general wellness guidance, the 

software functions have been under enforcement discretion. Meaning that 

based on the agency's understanding of the risks of these devices they did not 

intend to enforce compliance with applicable device requirements, as Bakul 

mentioned earlier.

As opposed to software, hardware for general wellness intended uses that 

meet the device definition remain devices. But these remain under 

enforcement discretion.

Okay so we've covered general wellness Category 1, how about Category 2 

general wellness software functions? If the intended use relates the role of a
FDA Webinar

Moderator: Irene Aihie

10-14-19 

Page 8

healthy lifestyle with helping to reduce the risk or impact of certain chronic 

diseases or conditions and where it is well understood and accepted that 

healthy lifestyle choices may play an important role in health outcomes for the 

disease or condition then the product is not excluded from the definition of the 

term device. We encourage you to refer to the general wellness guidance for 

more information for current policy on these devices.

Okay, so we've discussed some ramifications of 520(o)1A and 520(o)1B of 

the FD&C Act that was modified by Section 3060 of the Cures Act. Now let's 

discuss 520(o)1C. The third category of software functions excluded from the 

device definition are electronic patient records. For the record to be excluded 

from the device definition, it must be created or reviewed by healthcare 

providers. It must be certified under the ONC health IT certification program. 

And it must not be intended for interpretation or analysis for the purpose of 

diagnosis, cure, mitigation, prevention or treatment of a disease or condition.

In the draft 3060 guidance, FDA explained that we do not intend to enforce 

the requirements for records that are not certified under the ONC health IT 

certification program. We also noted that personal health records, those that 

are not created or reviewed by healthcare professionals, are not devices. This 

distinction is separate from the exclusion of the cure's act.

In the final guidance, we did not change any of the policies. We created 

sections to better describe each of the exclusion criteria and we added 

examples as requested by the comments on the draft guidance.

Okay, let's move on to 520(o)1D, the fourth set of software functions 

excluded from the device definition by the Cure's Act. The fourth category of 

software functions excluded from the device definition are those intended to 

transfer, store, convert, format or display device data and results. These 
FDA Webinar

Moderator: Irene Aihie

10-14-19 

Page 9

functions echo functions described in the medical device data system or 

MDDS regulation. These functions were under enforcement description 

according to the 2015 MDDS guidance we described earlier. That guidance 

did not distinguish between hardware and software functions, neither does the 

regulation.

In the final guidance, we clarified that the Cure's Act only excluded software 

and MDDS functions from the device definition, and the MDDS hardware 

remains devices. However, FDA does not intend to enforce the requirement 

under the FD&C Act for hardware products, provided the hardware function is 

limited to performing the excluded MDDS software functions.

We also state that general purpose IT products that are not intended for a 

device function, for example all-purpose computer monitors or routers, are not device functions. 

In the draft 3060 guidance, we included a reference to a policy for alarms, alerts, and flags 

because the MDDS regulation refers to active patient monitoring. In the final 3060 guidance we 

refer the discussion of alarms, alerts and flags to the clinical decision support or CDS guidance, 

since comments noted that these types of functions may be excluded from the device definition 

according to Section 520(o)1E, which is discussed in the CDS guidance and not in the 3060 

guidance. In the CDS guidance we describe these functions as device functions because they 

analyze medical device data, so they are not excluded from the device definition. There is a lot 

here on this slide and you can refer to it as a reference but let's review this information in a little 

bit less compressed format on the next few slides.

So software functions that are solely intended to transfer, store, convert 

formats and display medical device data or results are now excluded from the 

device definition by the Cures Act and considered non-device MDDS. Note 

that the non-device software functions may or may not be intended for active 

patient monitoring. Software functions intended to interpret or analyze clinical 

laboratory test or other device data, results, or findings are not considered 
FDA Webinar

Moderator: Irene Aihie

10-14-19 

Page 10

MDDS, and are not excluded from the device definition. In other words, while 

these non-device MDDS software functions are transferring, storing, 

converting or displaying medical device data, they are not modifying it or 

interpreting or analyzing it.

And one other thing I'd like to highlight about these non-device MDDS 

software focuses is that they do not control the functions or parameters of a 

connected medical device. Now we just said that non-device MDDS software 

functions may or may not be intended for active patient monitoring. But note, 

that software functions intended to generate alarms or alerts or prioritize

patient-related information on multi-patient displays are generally considered 

device software functions because these functions involve analysis or 

interpretation of laboratory tests or other device data and results.

So it is the analyzing/ interpreting feature of alarms and alerts that would

make them not be excluded from the device definition, in other words that 

would make them devices, not the fact that they are intended for active patient 

monitoring.

Okay, we've discussed software MDDS which is non-device MDDS. Let's 

move on to hardware MDDS. Hardware products that are solely intended to 

transfer, store, convert, format and display medical device data results are 

considered device MDDS. But FDA does not intend to enforce compliance 

with the regulatory controls for such devices. They are under enforcement 

discretion, that is provided that the hardware function, as I mentioned, is 

limited to assisting MDDS software functions, in other words the electronic 

transfer, storage, conversion, format or display of medical device data.

An important note here is that specialized medical diplay hardware devices, 

for example digital mammography, radiology, pathology and ophthalmology 
FDA Webinar

Moderator: Irene Aihie

10-14-19 

Page 11

have not been considered device MDDS and are not excluded from the device 

definition by the Cure's Act. So were distinguishing here between hardware 

that is intended for what you could call a general MDDS functionality, which 

are under enforcement discretion. And hardware that is intended for a 

specialized medical display function, which are not.

And on the next slide we will summarize hardware that is not specifically 

intended for medical purposes either general or specialized, in other words,

hardware that is not intended by the manufacturer for a medical device 

function. 

So general purpose products --IT infrastructure like network routers, network 

storage equipment, general purpose computer monitors, or PDF software --

not intended for a medical purpose do not meet the definition of a device for 

either the software or hardware function and therefore are not regulated as 

devices. 

Okay, that was the last slide on MDDS. Let's move on to the last few 

guidances. The mobile medical app guidance now called policy for device 

software functions and mobile medical application has a few changes 

including the terminology used to reflect a focus on using the term software 

function as opposed to mobile application. Also in the guided several 

examples have been revised as some have been moved from Appendix B to 

Appendix A because some software that was previously under enforcement 

discretion has now been excluded from device definition by the Cure's Act,

like general wellness Category 1 software functions which we discussed.

Okay, moving on to the next guidance. The next guidance we’ll briefly 

mention briefly is the off-the-shelf software guidance, notably the section that 
FDA Webinar

Moderator: Irene Aihie

10-14-19 

Page 12

is specific to laboratory information systems and laboratory information 

management system has been removed.

Okay, we have one guidance left to discuss. And that is the medical image 

management devices guidance. This guidance was withdrawn because some 

software functions described in the guidance no longer meet the definition of 

device as amended. Rather, for the limited subset of medical image medical 

devices that continue to meet the definition of a device, CDRH encourages 

manufacturers to reference the most recent FDA recognized versions of 

relevant voluntary consensus standards.

And the last thing I want to say about the series of guidances released in 

September is that we are asking for your feedback on the one guidance that 

was released in draft format that was the clinical decision support software 

guidance. But this is not the subject of today's webinar.

I would like to take this opportunity again to please ask for your feedback. 

The docket is open to comment until December 26 and we need all of your 

comments and suggestions, which we'll take into account as we update the 

guidance.

And here again is a list of the guidance documents that we did discuss in this 

webinar. And also there's an opportunity to sign up for digital health email 

updates. 

If you have additional questions, you can email FDA's division of digital 

health directly at digitalhealth@fda.hhs.gov. You can also contact FDA's 

division of industry and consumer education or DICE. This live presentation, 

transcript and webinar recording will be available at the link at the bottom of 

the slide. 
FDA Webinar

Moderator: Irene Aihie

10-14-19 

Page 13

Thank you very much and we're going to open up this webinar now for 

questions.

Bakul Patel: Thank you, Matthew. And thank you, everybody. 

Irene Aihie: We'll now take questions.

Coordinator: Thank you and at this time to ask your question, please press Star 1. Please 

unmute your phone and record your name clearly at the prompt. To withdraw 

your request, please press Star 2. Once again, at this time to ask a question, 

please press Star 1. 

Bakul Patel: Great, while we're waiting for comments, questions thank you Matthew for 

that wonderful overview on all the guidances. I'm sure people have a lot of 

questions. I do want to take a minute to highlight some of the nuances that we 

have done for in the guidance itself. And I would underscore a couple of 

points especially on the mobile medical apps guidance that we are taking the 

exact same approach that we have taken on mobile medical apps and applied 

to all software functions and this is true to what we have said all along in 

mobile medical apps guidance. But now in this particular change that we've

done to the title of the guidance it reflects our policies applied to any software 

regardless of the platform. So it's going back to the foundational framework

that I started talking about in the beginning of this webinar.

We'll take some questions now. Operator, when you're ready.

Coordinator: Thank you, one moment please. Our first question is from (Mike Beneke). 

Your like is open, sir.
FDA Webinar

Moderator: Irene Aihie

10-14-19 

Page 14

(Mike Beneke): Hi, Bakul and Matt. Thank you for your webinar. It was great. Could you 

comment on how do you regulate things that are kind of like hybrid apps? 

Like telemedicine apps or something like that like where a patient would 

transmit an image, you know, maybe a selfie to diagnose acne to a physician, 

how would you regulate that?

Bakul Patel: Actually, that's a great question and if you look at the mobile medical apps 

guidance, that is exactly one of the examples we have sort of highlighted and 

said that is not a medical device anymore. Because it's just enabling 

communications to, between a patient and a provider. So those, you know, 

typically messaging or a video or a taxpaying or a picture transmitter over to a 

provider is not something that we are regulating.

(Mike Beneke): Thank you.

Coordinator: Our next question is from (Lauren Zigler). Your line is open.

(Lauren Zigler): Okay, thank you. If this software recommends that a patient see a healthcare 

professional for a diagnoses and treatment and that is not based on the output 

functionality of the test within the app. Is that still a regulated medical device?

Bakul Patel: So this may, just so that I'm clear and then Matthew see if you want to chime 

in here and provide your thoughts. When we're talking about navigating or 

identifying a healthcare provider as an administrative function, that's 

definitely not a device. And when you are trying to identify a condition and 

then identification of that condition as a result, the action you want the user to 

take is go with it, a specialist or not a specialist. It would be a different. It will 

be considered differently. 
FDA Webinar

Moderator: Irene Aihie

10-14-19 

Page 15

Some of - and I think this is where the nuances are, and I'll encourage you to 

look at the guidance and the example we have taken time to put into the 

document. It might be really helpful for you to take a look at that. But those 

are the nuances that matter. And it becomes important to not just think about 

what it is doing but also how and where and what's the effect of that 

recommendation or suggestion to the user that's going to be and what impact 

of that is.

(Lauren Zigler): Yes, thank you.

Coordinator: And once again to ask a question at this time, please press Star 1 and provide 

your name. Our next question is from (Ralph Crogue). Your line is open.

(Ralph Crogue): Hello, thank you for the webinar. My question is about, I have a product that 

we're - that's under development that would annotate electronic health records. 

So if electronic health records are not a medical device, would something that 

annotates it be a medical device? And then the next question that follows that 

is what if it makes - it analyzes the medical record and makes suggestions 

about how to annotate the medical record?

Bakul Patel: Yes, so the medical record functionality as far as the 21st Century Cures Act 

goes, the function of creating a record or appending a record itself is 

something not regulated by FDA. I mean think about the paper records and the 

explanation that we are given in the guidance in 3060, you can see sort of, 

how and what rationale you should think about for the functionalities that may 

exist on top of the records itself. 

And I think it's important to sort of, highlight some of those points that you're 

raising. In addition to just, you know, annotating a record and there may be 

other functions that may happen as part of your provider entry system that 
FDA Webinar

Moderator: Irene Aihie

10-14-19 

Page 16

exists inpatient setting. I think those are the things that we consider as 

electronic health record systems. And that is specifically - and if it's certified 

by Office of National Coordinator, that is not necessarily able to be 

considered medical device.

Matthew, did you want to add anything?

Matthew Diamond: Yes, and just to add that, you know, I think annotating is a fairly broad 

term and, you know, as Bakul mentioned, a simple annotation would seem to 

fall under the category of electronic patient records. But if the software had 

additional functionality that included analysis and as you mentioned specific 

recommendations, we would have to look at the specifics of that case.

(Ralph Crogue): Okay, thank you.

Coordinator: Next question is from (Resa Sherte). Your line is open.

(Resa Sherte): Good morning and thank you for a very informative session. I'm thinking as -

there's two parts to this question. One is what's the Office of Strategic 

Partnership supposed to do? And how they can help us startups to be able to 

compete with the big companies from the point of view of - actually this 

question is more related to the 2019 and (unintelligible) company was forming 

or helping the regulatory definitions for the software and also for the decision 

making by the software. 

And the second question is if there is new method for analyzing data that we 

captured in our trial, should we provide all the data and how that's normally 

get transferred to a CA? Can we, let's say if we are running with the 

accredited institute, should be we get all the data or how we should think 

about the keeping a good record when we want to go for FDA?
FDA Webinar

Moderator: Irene Aihie

10-14-19 

Page 17

Bakul Patel: Your question is actually very interesting and intriguing at the same time. I 

would highly recommend, I think, and would reach out to what Matthew 

referred to as, you know, the Division of Industry and Consumer Education. 

And if you have specific questions, I think you started off with, you know, 

what is - how FDA is looking at a new paradigm and the pre-certification 

program. I encourage you to write to the precertification inbox as well as our, 

you can write to (unintelligible) health inbox and on the screen you're seeing 

right now.

They field general questions about, you know, do you have certain data and 

how do you want to discuss that with FDA. We have several programs in the 

center stating from queue submission program which basically, you know, 

you can share what you're trying to do in detail, and we can take that 

conversation in that very specific discussion.

Today I think we are talking specifically about policy we laid out to 

encourage people online to start - to highlight some of the things that we 

shared today and see if there's any clarification in the documents we published 

that would be helpful for us to address today.

(Resa Sherte): So which division you mentioned at the beginning? Sorry, I wasn't 

(unintelligible) so I couldn't hear exactly.

Bakul Patel: Yes, so the slides if you're not seeing the slides, it's the Division of Industry 

and Consumer Education. It's the email address is dice@ ...

((Crosstalk))

(Resa Sherte): Is this the one on the slides right now?
FDA Webinar

Moderator: Irene Aihie

10-14-19 

Page 18

Bakul Patel: Yes.

(Resa Sherte): Okay, Division of Industry and Consumer Education. Okay, I got it. Thank 

you, thank you for your response. 

Bakul Patel: You're welcome.

Coordinator: Our next question from (Tucker Tomlinson). Your line is open.

(Tucker Tomlinson): Thank you. I was hoping to get a little clarification on a note that you had 

earlier in the slides about the option to regulate MDDS systems if there's 

sufficient risks around the use. And what the thresholds for that decision 

might be. When you would choose to regulate a system that would otherwise 

be classified as a non-device. Do you have any additional guidance about how 

that decision would be made?

Bakul Patel: Yes, I think at this time, I would recommend that our policy and the last 

basically says that the current set of information that we have from a public 

health perspective, patient safety perspective, FDA has very clearly laid out in 

these final guidances what is that. And this final guidance that they're not 

devices. However, on an ongoing basis as part of the law, we have been asked 

by Congress to continuously observe in this space that are not devices. And if 

there is any public health impact, we would be engaging in a very broad 

public dialogue and before we make any changes to these policies.

(Tucker Tomlinson): So would there be reports or monitoring that would need to be supplied to 

the FDA for these non-devices as part of that ongoing monitoring/
FDA Webinar

Moderator: Irene Aihie

10-14-19 

Page 19

Bakul Patel: No, it is a responsibility that FDA will publish. And engage in a draft and 

final as the policies or notices that will help make people aware if we are 

changing the policies than what we published today.

(Tucker Tomlinson): Okay, and then a second question is for an MDDS, does the consumer of 

the data make a difference? So if the consumer is clinician versus another

medical device, if you had a Class 3 device that's consuming data from a 

MDDS, does that impact how you would regulate the MDDS?

Bakul Patel: So the way the, and you'll see we have a draft guidance on multiple 

functionality which addresses exactly the point you're raising which we are in 

the process of finalizing. But to share what is highlighted in that guidance, it 

talks about it's not about regulated the non-device functions. It's about 

understanding the Class 3 device impact on the Class 3 device from that nondevice function. And that analysis of risk needs to be conducted on the Class 3 

device or device of any other class.

(Tucker Tomlinson): Okay, thank you.

Coordinator: We are showing no further questions. We'll turn it back to Irene Aihie for 

closing remarks.

Irene Aihie: Thank you. This is Irene Aihie. We appreciate your participation and 

thoughtful questions. Today's presentation and transcript will be made 

available on the CDRH learn webpage at www.fda.gov/chrhlearn by Friday, 

November 22. If you have additional questions about today's presentation, 

please use the contact information provided at the end of the slide 

presentation.
FDA Webinar

Moderator: Irene Aihie

10-14-19 

Page 20

As always, we appreciate your feedback. Following the conclusion of today's 

live webinar, please complete a short 13-question survey about your FDA 

CDRH webinar experience. This survey can be found at 

www.fda.gov/cdrhwebinar immediately following the conclusion of today's 

live webinar. 

Again, thank you for participating. This concludes today's webinar.

Coordinator: Thank you. That does conclude today's conference. We do appreciate you 

attending. You may disconnect at this time.

END