The FDA and Software: A Historical Overview with Dr. Donna-Bea Tillman - Episode Artwork
Technology

The FDA and Software: A Historical Overview with Dr. Donna-Bea Tillman

In this episode, Dr. Donna-Bea Tillman shares her extensive experience with the FDA's evolving relationship with software in medical devices. She discusses the regulatory landscape from the late ...

The FDA and Software: A Historical Overview with Dr. Donna-Bea Tillman
The FDA and Software: A Historical Overview with Dr. Donna-Bea Tillman
Technology • 0:00 / 0:00

Interactive Transcript

spk_0 Hello, my name is Xenofon Babadimitris. I'm a professor in biomedical informatics in
spk_0 data science here at Yale. This one of the supplementary interviews we record for
spk_0 the certificate program in medical software and medical AI. I guess today is Donabit Tillman.
spk_0 She's a principal consultant at Biological Consulting Group. She has over 30 years of experience
spk_0 in medical regulatory work prior to joining Biological Consulting. She spent 17 years at the FDA in
spk_0 various positions first with the center of device and radiological health and this culminated in 2004
spk_0 where she was appointed to be director of the Office of Device Validation, where she saw the
spk_0 medical device pre-market review program for non-IVD devices. During her time at FDA, she played a
spk_0 pivotal role in development of guidance, documents, standards and policy frameworks for medical
spk_0 device software and MIT. In 2010, she left at the end, joined Baxalth Health Solutions Group as
spk_0 director of regulations and policy, responsible of obtaining the appropriate global pre-market
spk_0 registrations and managing Baxalth Health Solutions Groups. She joined Biologics in 2012 and
spk_0 over the past 12 years, she submitted more than 105 10k applications as well as several
spk_0 neurodiversity denobles in the GDOT health space. We might hear some of them. Donabit is
spk_0 a BSE engineering from Tulane and her PhD in biomedical engineering from Drom Hopkins and she
spk_0 also has a Masters in Public Administration from American University. So welcome, thanks for
spk_0 taking the time of this conversation. Let's start just at the beginning here. How did
spk_0 FDA discover software? How did FDA get in the software business? Now we start with food,
spk_0 cosmetics, drugs, devices. This new thing called software one, they hit you. How did that
spk_0 happen? Where does the story begin? Yeah, so FDA didn't actually start formally regulating
spk_0 medical devices until 1976. And back then, there were not even a lot of medical devices that
spk_0 had software in them. But over time, I would say over the next 10 to 12 to 15 years, software
spk_0 started showing up in medical devices. We had some things like early pacemakers, we had
spk_0 medical imaging systems, we had ECG and monitoring devices that started to incorporate some basic
spk_0 software functionality. That is where FDA started with software, which was software in
spk_0 medical devices. So what was the first response of the agency to that? At some point, you
spk_0 realized that you had to do something about software. There were some concerns. I mean, software
spk_0 became a safety issue, I assume at some point and there are some famous actions from the 80s.
spk_0 So what were the beginnings of that process? Yeah, there were sort of two things that happened.
spk_0 The first was that FDA was seeing software in medical devices as part of pre-market submissions.
spk_0 So they put together a guidance document in 1991, which was the reviewer guidance for computer
spk_0 controlled medical devices undergoing 510K review. So this was the great, great granddaddy of the
spk_0 software guidance that we frankly still have out there today. And it laid out a basic framework
spk_0 that talked about if you got software in your medical device, what information you need to provide
spk_0 to FDA when you submit something. And it had things in it that you might expect to see, like software
spk_0 risk analysis, requirements, design documentation, verification, validation testing. So it developed,
spk_0 you know, a set of documents that FDA wanted you to submit. And it also developed a framework for
spk_0 the idea that not all software was the same. So you might have software, for example, in a light
spk_0 system that's in an operating room. Even back then, people were starting to put simple software
spk_0 things in, in a lot of risk devices. But then you've got stuff like pacemaker, that's higher risk.
spk_0 So the second thing that this guidance did was develop kind of a risk-based framework
spk_0 for the kinds of documentation FDA would ask for. And it developed this idea of what we call
spk_0 level of concern, minor, moderate, major, the higher the level of concern, the more documentation
spk_0 that you would need to provide. What's also interesting about this point in time is that at this point
spk_0 in time there was no quality system regulation. The quality system regulation didn't get implemented
spk_0 until 1996. And also, you know, it's hard for some of you who may be listening to understand what
spk_0 the world was like back in 1991. We had no internet. There was no worldwide web or no cell phones.
spk_0 And Windows 3.0 had just been released. So, you know, we have a very different world in terms of what FDA's
spk_0 looking for. And the other thing that FDA did back then was they developed a document, a draft
spk_0 document we call the software policy document from 1989. And this was the sort of second major
spk_0 step that FDA took, which was saying that software by itself could be a medical device.
spk_0 If you look at the definition of a medical device, does it actually include the world word
spk_0 software, or it didn't until relatively recently? And so there was some question about whether
spk_0 software by itself could actually be a device. And FDA said yes, software is a contrivance.
spk_0 One of the words in the definition of a medical device is a contrivance. And so FDA said yep,
spk_0 software can be a medical device. And then they developed this software policy document that talked
spk_0 about, well, what kinds of software might FDA be interested in regulating and what kind of
spk_0 software might FDA not be interested in regulating? And so that was the 89 software policy document.
spk_0 And it created this very interesting concept of competent human intervention. And that was it
spk_0 was a big thing that FDA looked at back in those early days to try to figure out if it was going
spk_0 to regulate software or not, which is can the person using the device exercise competent human
spk_0 intervention in terms of figuring out whether the software is given the right answer or not?
spk_0 And so that document was out there. There's a version of it, I think linked down in the comments
spk_0 that you can take a look at. It was used for a very long time until some of the more recent things
spk_0 came into play. But those were those are the first two steps FDA took back in the late 80s early.
spk_0 So it's funny that 35 years later in the year of AI, human in the loop as risk management is
spk_0 again, is the human competent? Can they really be a risk mediator as they are? It's funny how
spk_0 everything was back. Actually, as an aside here, what were the inputs to this process? What were
spk_0 people reading? What was the literature around? Was it just software engineering literature?
spk_0 Was it safety literature? Where did the start? Now there's a million and one things one can read
spk_0 to think about this stuff. But what was there then? What was the inspiration for some of this?
spk_0 Yeah, I think a lot of the, in terms of what documentation was necessary in order to support
spk_0 a safe medical device, that first piece that I was talking about, the guidance document,
spk_0 it was software engineering as an engineering discipline that was starting to come into play at that
spk_0 point in time. We were starting to develop as an engineering discipline thinking about how do you
spk_0 develop a life-cycle model and manage software in a way to increase the likelihood that the software
spk_0 that you build is actually going to need user requirements and do what it's supposed to do.
spk_0 So I think a lot of there were some IEEE standards back then that talked about how to do good
spk_0 software engineering process. So that was kind of what fed into that reviewer guidance on
spk_0 software controlled medical devices. The software policy that it, some of it talked about things that
spk_0 were explicitly not regulated as medical devices. They were actually in the regulations. So, for
spk_0 example, anything used for training. Training stuff is not regulated as a device. Things like
spk_0 general purpose computing equipment. And so that whole idea, which is going to come up again when
spk_0 we talk about digital health, there was some language in that software policy about that. So it was
spk_0 more focused on the sort of regulatory policy things. And then this competent human intervention,
spk_0 where that came from, I think my opinion, I wasn't there in 89. I didn't join FDA until 94.
spk_0 But I think it was just sort of something that kind of made sense to people. That if you had
spk_0 somebody that could sort of be around to provide a second level of checking on this on what the
spk_0 software was doing, then maybe you would need to exercise fewer regulatory controls.
spk_0 Okay, so that's the beginnings. And ask things evolve. And is that begins your time out of the
spk_0 to how the pros evolve after that? Where did we go? In the early PC era? Well, here.
spk_0 Exactly. So, you know, that guidance went out. It started becoming, you know, the industry became
spk_0 aware of it. And then the next thing that really started to happen was the increasing use of
spk_0 off the shelf software or soup or whatever you want to call it, FDA calls it off the shelf software.
spk_0 And this is actually where I started getting involved with software at FDA. I was at FDA during that
spk_0 time period. And we put together a working group to start to think about, well, we've already
spk_0 talked about what documentation needs to be provided to FDA for the software that accompany rights.
spk_0 How is FDA and the company going to make sure that third party software that's put into medical
spk_0 devices that it's functioning appropriately? What's the right level of documentation to provide to
spk_0 FDA about that? And so I think that that also became sort of an important consideration. And,
spk_0 you know, once against FDA took sort of a risk-based approach where they said, well, if you've got a,
spk_0 if you've got a sort of a low level of concern device, it's enough to basically describe what the
spk_0 off the shelf software is doing, how you're going to manage it, how you're going to make sure that when
spk_0 there's changes made that you're on top of all that. And then for higher risk devices like
spk_0 pacemakers and other, other higher risk devices, you know, you're going to need to have a little bit
spk_0 more confidence about whether or not it's appropriate to use that software. I always like to say back then
spk_0 imagine a thought experiment where you, and this was back in the in the mid-night, so Windows was
spk_0 just becoming a thing. And I'd say imagine you got on an airplane and you're sitting in the seat
spk_0 and the pilot's given is before flight to field. And the pilot comes on and says, our airplane today
spk_0 is being flown by Windows. How many of you would get up and try to get off the plane? And, you know,
spk_0 and so I think that this idea that, you know, third party software has its place, but there are
spk_0 sometimes when it's appropriate and sometimes it was not. And for people who are younger than,
spk_0 a certain age, younger than us, certainly, in that year, we rolled most of our code, right? There
spk_0 was no internet to download libraries. The nuclear problems, like Peebe installed an NPM
spk_0 install for Python JavaScript, but Peebe was used to, like the amount of third party things that we
spk_0 had access to was very limited. It wasn't like the most common source of external code in that year.
spk_0 I was a graduate student back then was typing code in from a book. It was less common to be able to
spk_0 download libraries that did complicated things, but the progression goes from probably back then where
spk_0 you rolled 95% of your code to maybe now where you write 5% of your code and 95% is operating system,
spk_0 library, strivers, all of those things. So it was early days, but I think that's almost the
spk_0 one of the central challenges because we write so little of the code, it's actually involved in software.
spk_0 I think that's a great point too. I mean, a lot of the early concerns were about things like
spk_0 operating systems, but you know, you mentioned typing in your own code. I remember that. I was,
spk_0 I was doing getting my PhD and I finished up in the early 90s and I did a bunch of
spk_0 mathematical modeling as part of my PhD project and I had this book called New Miracle Recipes
spk_0 and it had all of these form, you know, it's had code in there. I think it was written in,
spk_0 I think it was C code and you could, you know, if you needed to do some kind of, you know, an issue
spk_0 in terms of a series analysis or whatever you needed to do, you could go in there and exact,
spk_0 and I actually did that. I went in there and I typed code right out of that book. So yeah,
spk_0 that there was a lot of that going, it was a different world. In back then, you know, there was no,
spk_0 there was no Google. We had really primitive browsers, you know, mosaic and net scape, you know,
spk_0 anybody heard of them today. And at that point in time, you know, mobile phones also, we didn't have
spk_0 any data on our phones. We did have mobile phones, but they only had voice and some basic primitive
spk_0 text messaging. So yeah, so that was that was going on. And then the other thing that was happening
spk_0 is around that time is when the quality system regulation was was implemented in in in 96.
spk_0 And the next question that came up was with was, well, what does it mean to validate software?
spk_0 And you might think with this big quality system regulation, which basically says,
spk_0 software has to be validated. There's nothing in the quality system regulation that says,
spk_0 what software validation actually needs. And so, you know, I was also involved with this at FDA,
spk_0 a small group of us got together and we we wrote a guidance document that that a lot of people
spk_0 know and love called the general principles of software validation, where we we were trying to
spk_0 provide guidance to the industry about what were best practices for how to validate software.
spk_0 What does software validation actually mean? And this document actually was the grand great
spk_0 granddaddy of the software lifecycle standard SW68, which eventually became ISO 6204, which is
spk_0 out there today and still going strong. So the quality system regulation comes in.
spk_0 What's this sort of background to that? What was the
spk_0 unsuspective that what other quality systems did you guys look at? Because quality systems
spk_0 you know, start with the military problem in the 40s, late 30s and the 40s. Certainly what were two,
spk_0 and then we have, you know, the whole Japanese industry explosion and quality control there.
spk_0 So what were you guys looking at as you know, the quality system regulation?
spk_0 So, you know, before the quality system regulation, we had GMPs, good manufacturing practices.
spk_0 And when the when the, you know, the first medical device,
spk_0 statute was enacted in 1976, the idea, you know, the GMP regulations were put in there for devices.
spk_0 And they were basically built on the drug GMPs. But the problem is devices are different than drugs.
spk_0 I mean, drugs are, you know, you might come up with a drug. I always like to say,
spk_0 drugs are discovered and devices are designed. Now that that was more true in the past than
spk_0 perhaps it is today. I think there's more drug design going on nowadays. But back then that was
spk_0 the case. And so as all we had were good manufacturing practices, which talked about how do I,
spk_0 how do I take a design for a catheter and build 100,000 of it? And really about the manufacturing
spk_0 process. How do I, how do I systematically make sure that I, that my manufacturing is producing
spk_0 the device I think it is and that it's meeting my standards? The whole idea of, well, what happens
spk_0 before you get to manufacturing? What happens when you're designing that device? And those,
spk_0 we call those design controls? That was really in my mind one of the most significant parts of
spk_0 the quality system regulation was the idea that the reason why most devices fail and in particular
spk_0 most software devices fail is not because they're not manufactured correctly. Although that does
spk_0 happen is because they're not designed correctly. They are either the user requirements aren't
spk_0 well understood or, or the requirements are improperly implemented. And so, you know, the quality
spk_0 system regulation was really an attempt to develop a more, as you mentioned, based on other industries
spk_0 that had had those kinds of things. The nuclear industry, I think, is another one that,
spk_0 that there was some of that that was fed into this was really the idea that we needed to have a more
spk_0 systematic methodology for making sure that we were designing devices correctly. And so we have this
spk_0 process from drags to devices to software inside devices. And then we get to this point where
spk_0 software can live on its own, right? The hardware now becomes generic. So we stop writing about it
spk_0 for certain applications, obviously doing it with what it's imagines. But a lot of the medical
spk_0 device now is a computation, it's analyzing some data that comes from elsewhere. So now this is
spk_0 another transition, you know, have software as a medical device, right? Without, with the hardware
spk_0 being generic and we can usually sort of safely not ignore it, but for all it doesn't
spk_0 purposes is not important. So, talk us through that process. What did that take to do and where did it go?
spk_0 So where this really started actually was in the medical imaging space. That was, that was,
spk_0 you know, in terms of FDA, we had some software as a medical device to be been around for a
spk_0 little while. We had interpretive ECG as a good example. That had been around for a little bit,
spk_0 where you had software that would look at an ECG waveform and try to identify different
spk_0 herbivious. But that was still, even though it was a software function, it was still largely baked
spk_0 into a medical device. It was part of an ECG device. But in medical imaging, we really started with
spk_0 the idea of software as a device on its own. And in 1998, FDA actually formally classified medical
spk_0 imaging software. So, prior to that time, that software was, it hadn't been considered when the
spk_0 medical device and then it's for an actin back in 1976. We didn't have medical imaging software.
spk_0 And so, FDA created a series of regulations around what they call picture archiving
spk_0 and communication systems or Pax devices. And these were software things that were intended to
spk_0 store medical images to display them and to analyze medical images. And so the idea is that
spk_0 you've got a medical image and you're going to maybe digitize it. And then now you've got a
spk_0 digital version of that image. And you can do things like make measurements on it. You can do
spk_0 things, perhaps like develop if you've got a CT scan where you've got a bunch of slices,
spk_0 create a 3D reconstruction of the heart and the different slices so that somebody can view those
spk_0 that heart in three dimensions. And so, you know, that was when FDA, I think, really first started
spk_0 systematically reviewing software as a medical device. And then it gradually came into other
spk_0 other clinical fields as well. So, and it's interesting, because images are probably the first time
spk_0 where the acquisition and the reading were separated by this bug and the packs the database.
spk_0 So now the images are acquired, they are stored, and now they're pulled out of storage to be read.
spk_0 So the processing is separate from the acquisition whereas the ACG was standing one go, right? It's
spk_0 just integrated into it. And you know, for those of you new to this philectronic medical
spk_0 records and all of that were stealing the future for all the tests and purposes. So that was the
spk_0 one big digital database in the hospital, which makes sense that it would be there.
spk_0 So if you look at the pack system and this is where we're beginning now to more modern year
spk_0 perhaps is part of it as regulated, part of it isn't regulated, right? Not the whole pack system is
spk_0 regulated. So let's talk through that, right? So we're now moving even further down this road.
spk_0 We forget about the hardware and now we're beginning not quite to forget, but stop worrying about
spk_0 some of the software too. Yes, like a piece of the software is regulated now. And a piece is some,
spk_0 so talk us through that and how do people, and now we're in the modern era. So it's not just
spk_0 if you're still going to discuss, how should one think about that even today? Yes.
spk_0 Yeah, so it's definitely involved over time. You know, a couple of other interesting things that
spk_0 happened around that time relating imaging was the emergence of digital radiology and
spk_0 and you know, digital mammography in particular, you know, FDA regulates mammography under
spk_0 something called the mammography quality standards act. So it's another
spk_0 statute that FDA actually enforces and FDA actually exercises a fair amount of control over
spk_0 mammography programs working with the states. And when digital mammography became a thing,
spk_0 when people say, hey, instead of doing mammograms with film, we're going to now create sensors and
spk_0 do digital mammography. When that first came out, FDA said, you know what, that's kind of,
spk_0 we've got some concerns about that. And they actually made those devices, PMAs, which is the
spk_0 higher level of regulatory than a 510K, which is the low level. So digital mammography devices
spk_0 were actually originally PMA devices. And part of that reflected FDA's lack of comfort with
spk_0 digital imaging. It was still kind of a new thing. And some of the very early software to analyze
spk_0 digital mammograms and determine regions of interest that might be suspicious, you know,
spk_0 software that looks at a mammogram and says, hmm, there's something funny over here.
spk_0 Radiologists, you should look at that. And we called those TAD devices, computer-assisted
spk_0 detection devices. That came out. And those were PMAs as well. Now, what's interesting is,
spk_0 over time, as FDA got more comfortable with those products, those devices have actually been
spk_0 downclassified. So digital mammography devices and breast-cad devices actually no longer
spk_0 require PMAs. FDA rarely reduces its level of regulatory oversight. But this is an example where
spk_0 did. So those devices, FDA on its own, decided, you know what, we don't need PMAs for these anymore.
spk_0 We're going to downclassify them. And so those devices are actually classed too now, and they only
spk_0 require 510Ks. So, you know, I think what we saw is this emergence of this digital imaging.
spk_0 A lot of concerns. Worries about what we didn't know, because we're used to the old way of doing it.
spk_0 And then as over 10 or 15 years, when it became better known, then FDA saying, you know what,
spk_0 this isn't such a big deal, we can downclassify it. And what that enabled FDA to do is, when the same
spk_0 starts of questions started coming out in other areas of imaging, like lung software analysis,
spk_0 or software that looks at a dental X-ray, to figure out whether there are cavities.
spk_0 You know, the breast, the breast one kind of came first, and then a lot of the other stuff came
spk_0 after it, and FDA started to apply a lot of those same considerations to these other products.
spk_0 So, okay, so we have all the software. We're beginning to use it. We're beginning to trust it. We're
spk_0 beginning to down-regulate it, which for people who don't know what type of savings that involve
spk_0 import, pages, and money, and years of studies is a non-insignificant thing. But now we're
spk_0 beginning to think about even parts of the software that are not really regulated, right?
spk_0 Functions, the data, and functions that are not. Let's talk through that a little bit,
spk_0 telepathy process works. Yeah, so, you know, there was a little bit of a history with that as well.
spk_0 So back just around the time I left FDA, FDA started dealing with what they were calling medical
spk_0 device data systems. And this was sort of a, you know, we talked about cracks. So a plaque system has
spk_0 a part of the system that stores the image data, part of the system that transmits the image data
spk_0 from this point to this point. Part of the software system that displays it. And in general,
spk_0 FDA exercises less regulatory oversight over that than it does for the software that does a 3D
spk_0 reconstruction of the heart. So then the question became one of well more and more medical devices
spk_0 where now developing the ability to put out digital data like your anesthesia machine. Now all of
spk_0 a sudden, you know, it was possible to hook your anesthesia machine up to an electronic patient
spk_0 record and download a whole bunch of data about that patient or your ventilator. And so what was
spk_0 happening is as devices and as the emergence of networks within the hospital started to come around
spk_0 and electronic health record systems, we now have this vast amount of digital data that's coming out
spk_0 of medical devices that are being used in a lot of different ways that are going into this hospital
spk_0 network and then getting stored in these electronic health record systems. And, you know,
spk_0 originally FDA's idea was it was going to regulate all of that as a class one device that
spk_0 required a quality system, but didn't require a pre-market submission. And that was the original
spk_0 what we call medical device data system rolled that FDA put out. And then what happened is we had
spk_0 this whole back in 2010, we had this whole emergence of something called the high tech act,
spk_0 which was there was this economic bailout program that happened around that time that some of you
spk_0 may be aware of. And as part of that, there was a huge amount of money that the federal government
spk_0 hunked into electronic health records. It created the whole office of the national coordinator
spk_0 for electronic health record systems. And there was this big push to move the medical community into
spk_0 an electronic health record system. And those people who are doing that, which is part of health
spk_0 and human services said to FDA, hey, you're going to you know, you're going to regulate this. That's
spk_0 going to get in the way. We don't think that you should be regulating these things. And so what
spk_0 happened was that FDA actually said, you know what, we're not actually going to regulate medical
spk_0 device data systems anymore. We changed our mind. So put out this rule, so we're going to regulate
spk_0 them. And then they say, nope, on second thought, we're going to exercise enforcement discretion
spk_0 and not regulate them. And then in 2017, Congress came along with something called the 21st century
spk_0 Cures Act and basically removed those products from the definition of a medical device entirely.
spk_0 So you had this whole transition where FDA was going to regulate these things. Then they said,
spk_0 well, maybe will not. And then Congress said, you can't regulate. So we end up with a system where
spk_0 there are parts of these electronic health record systems and hospitals that are not regulated
spk_0 at all because they just they're like electronic health record systems. And then parts that are.
spk_0 And there's a whole series of FDA guidance documents and policies about what will be regulated
spk_0 and what won't. And I think the most important piece out of this because it's kind of complicated
spk_0 is the question of clinical decision support. So in general, you know, FDA has said that it's not
spk_0 going to regulate the sort of architecture part of this. Moving data around, storing data,
spk_0 putting it here, putting it there, you know, doing all that. Not going to regulate that.
spk_0 But now, what if you start taking all of this data and for example, I got a whole lot of data in
spk_0 my patient record and it's going to tell me whether I've got sepsis or not. Or it's going to,
spk_0 you know, somebody's going to write a machine learning AI based algorithm that's going to mine all
spk_0 this EHR data on these individual patients to determine if they've got sepsis or if they're developing
spk_0 high blood pressure or whatever. That's that is where the agency's more recent attention has turned.
spk_0 And you know, as we've gotten into the whole AIML space, lots of interest in a lot of regulatory
spk_0 oversight about how those data are used. Let's switch gears a little bit. The other big thing that
spk_0 happened in the space is mobile devices. Right. All of a sudden, everybody has a computer in their
spk_0 pocket or on their wrist or other incarnations of this that are yet to come rings, glasses,
spk_0 what have you. And now, these are beginning to be almost a platform of choice for many things.
spk_0 And that has its own unique challenges. You are involved in some of that work. It's probably a
spk_0 consulting career. So let's talk about those challenges and how they have affected how we think
spk_0 about how the agency thinks, how people design things, where are we there.
spk_0 Yeah. So the first thing that started happening is we started getting phones that had data capabilities,
spk_0 right. And we could look at stuff on our phones that normally we used to have to only look at on
spk_0 a computer screen. And so the first question that FDA had to deal with, well, if I have software
spk_0 now and it's running on my phone, does that mean my phone and medical device if the software is medical
spk_0 is a medical device software? And if the FDA's answer to that, which I think was the right one,
spk_0 was no. In the same way that FDA doesn't regulate computer, general purpose computing platforms as
spk_0 medical devices, you know, like your laptop or a desktop computer or even a large data center at
spk_0 a hospital that's running a big pack system that just because your phone has medical device software
spk_0 on it doesn't make the phone a medical device. So that that part, I think, was fairly easy and
spk_0 consistent. It just represented the evolution from a computer being the thing on your desk to
spk_0 a computer being something you can carry around into your pocket. So that was that was pretty
spk_0 straightforward. That FDA developed a mobile medical apps guidance document that came out in
spk_0 around 2011. And that's where they base basically dealt with that. So that was easy. So then so
spk_0 the next thing that happened is we just started seeing wearables. And the thing about the wearables
spk_0 was not only were they general were they computing platforms, you know, they could show you your
spk_0 text messages or or some basic functionality when they first came out, but they had sensors on them.
spk_0 And those sensors could be used for medical purposes. So how did that change the calculus?
spk_0 And so the question became one of, well, if I can if I can if I've got a sensor on my wearable
spk_0 and it can measure my heart rate, does that mean that my wearable device because it's now that
spk_0 a sensor on it? Does that make the wearable device regulated? And I think what was really important
spk_0 and I think that FDA's decision on this really had critical implications for the digital health
spk_0 world that we see today. And I think a lot of it goes back to how FDA regulated the whole idea
spk_0 of exercise heart rate. So and in order to understand that, you got to understand the whole issue
spk_0 of general wellness. Yeah, and we're getting to that because that's both general wellness as a
spk_0 hardware thing, but also absolutely up store, diets, gestures, recommendations and you know,
spk_0 Google search maybe. So let's let's maybe conclude our discussion with that wearables
spk_0 because that's also another nice fuzzy line here. We have to learn about it. It is. Yeah, the whole
spk_0 digital health and wellness thing has been, you know, we've just if you look at what's happened
spk_0 over the past five years, it's just taken off. And and actually, you know, where this first started
spk_0 to be coming an issue was back in the 90s actually where people started developing these wearable
spk_0 heart rate sensors that you would wear like Holer had one. It would be like a chest strap that
spk_0 you would wear when you go out and run or when you're on the treadmill and you could connect it
spk_0 to with a cable to either to your treadmill or to a you know, it would have a little display
spk_0 that would show you what your heart rate is. And the question became one of well, if you got a
spk_0 product and it's measuring heart rate, but it's only for exercise is that a medical device.
spk_0 And what happened is FDA decided that well, we're going to exercise enforcement discretion. So
spk_0 that a that a product that is just measuring heart rate for exercise is not going to be
spk_0 regulated as a medical device. And this was really where the whole general wellness policy began was
spk_0 with the idea that there were like heart rate, for example, there were reasons you might want to
spk_0 know your heart rate that don't really have anything to do with whether you're sick or not. They're
spk_0 just I want to get my exercise heart rate up to some level so that I can be in the aerobic zone
spk_0 and I can kind of do my good exercise routine. So so that was really when FDA started first
spk_0 thinking about this idea of wellness. And then they published a guidance document in 2015 where
spk_0 they basically said that they were going to exercise enforcement discretion over products that
spk_0 were intended to be used to maintain or encourage a general state of health or healthy active.
spk_0 So that's like counting your steps, showing what your ex your heart rate is while you're exercising.
spk_0 And that they would also not regulate anything that relates to the role of a healthy lifestyle
spk_0 with the idea that it would reduce the impact of certain chronic diseases. So for example,
spk_0 if I want to develop a calorie tracking app and I want to say that you know this is going to help
spk_0 you to lose weight and oh by the way, if you lose weight that might reduce your risk of becoming
spk_0 type 2 diabetic. That FDA would allow these kinds of claims to be made around those
spk_0 those kinds of claims. And this actually also ended up getting enacted by Congress in 2017
spk_0 as part of that 21st century Cures Act that I mentioned in regards to medical device state
spk_0 and what the Congress basically took what FDA had been doing by policy and implemented in
spk_0 statute where they basically said that software for maintaining or encouraging a healthy lifestyle
spk_0 that's unrelated to the diagnosis mitigation treatment cure prevention of a disease was not
spk_0 actually a medical device anymore. So Congress took what FDA had been doing and actually turned it
spk_0 into law. So what this means for these digital and wearable platforms is that if you have a sensor
spk_0 on it and that sensor is only being used for a wellness activity exercise heart rate then it was not
spk_0 a device function. And so this was really the thing that allowed the first digital health products
spk_0 to go through as software only. So if we take the case study of the ECG app from the Apple Watch
spk_0 which was really I would say the first product in this space and we look at kind of how that worked.
spk_0 So you've got an app that runs on a phone. You got an app that runs on a watch. The watch actually
spk_0 has ECG electrodes in it and you might say well doesn't that make the watch a device?
spk_0 But you could make the argument that the heart rate that's measured by those ECG electrodes
spk_0 could be used for a general wellness function. So Apple could sell the watch they could say we're
spk_0 going to an app it's going to measure your heart rate while you're exercising and that therefore
spk_0 because there was a legitimate non medical device purpose for those sensors it didn't make the
spk_0 watch hardware regulated. And then then when Apple then went in to FDA with its denovo for its ECG
spk_0 app it could go in with a software only product. And so this idea that we can divorce the software
spk_0 from the digital health platforms you know that was really that that was the first product that
spk_0 started that and we have seen more and more of those. So for example Samsung recently got a
spk_0 denovo granted by FDA for a sleep app via feature that relies on the PPG sensor of a Samsung watch
spk_0 because the PPG sensor could be used for non medical device purposes it's not regulated that
spk_0 was a software only device. And the other interesting one that happened fairly recently was that
spk_0 Apple actually got a denovo recently for using the AirPods as a hearing aid. So hearing aids are
spk_0 regulated medical devices as well. Once again FDA said well the AirPods have a non medical device
spk_0 purpose therefore listening to your music. But we're going to regulate the software as a
spk_0 software only device. So I think you know what we've seen is this evolution where we started off
spk_0 with software in a medical device. And then we have software kind of being on its own out there is
spk_0 just standalone software. And then we get software that's now running on these portable phones and
spk_0 wearable devices. And now we're back to this sort of standalone software or software as a medical
spk_0 device that's running on those almost products as well. And I think we're only going to see
spk_0 more and more of that. I feel like the health space is one of the most there's just a tremendous
spk_0 amount in the digital health space that's going on right now. Is there anything else that you
spk_0 wanted to mention before we close this up? Is there anything? No, I think that you know that the
spk_0 next thing as I was sort of touched on is AI machine learning. So there's obviously they can
spk_0 go to a whole another discussion just on that. It's a complicated enough scenario and that's
spk_0 you know that is become an issue both in start to once again the in the medical imaging space is
spk_0 where I think we saw a lot of that beginning. But it's definitely morphing over into the digital
spk_0 health space as well. We've got chat GPT and I was you know how's FDA going to regulate
spk_0 AI's that start making medical recommendations. So I think there's there's still a lot of really
spk_0 interesting questions and problems yet to be resolved. So I think we've come a long way but we
spk_0 still got a long way to go. Yeah and I think just to conclude the conversation for the students
spk_0 especially understanding where we came from and this is what we've tried to do today. It's kind
spk_0 of important because all these decisions build on things that happen like we did this it worked out
spk_0 now as a president now we can use our to think about a new problem which is new but not everything
spk_0 is new a lot of the things have been around for a while in different in slightly different
spk_0 so thank you for taking the time and maybe we'll have a second conversation talk about AI sometime
spk_0 in the future. Thank you very much.