FDA Regulation of Medical Device Software (Part 2 of 3)

I'm now going to turn to medical device software and some of the the sort of special considerations for for this product area so medical devices have had software in them actually for pretty much as long as software has been around in fact FDA's medical device regulations the medical device amendments were enacted in 1976 and there were a couple of different things that sort of led to Congress deciding that it needed to regulate that the government needed to regulate medical devices one of which was the Dalkon shield which some of you depending on your age may remember which was an IU dude I u D device that had some issues and the other was actually a device called the therac-25 which was a radiation treatment system that had a software book and as a result of the software bug it ended up a number of people in this country ended up getting injured and some of them actually died from radiation exposure so it was actually this software failure that really was one of the things that actually offer a bug it ended up a number of people in this country ended up getting injured and some of them actually died from radiation exposure so it was actually you know this software failure that really was one of the things that actually led Congress to deciding it needed to regulate medical devices so the regular regulatory considerations if you have a medical device that has software and it are fairly well understood FDA has a number of guidance documents and actually I was one of the people that wrote these guidance documents that I think do a pretty good job explaining what FDA expects you to provide in your medical device and these include sort of basic considerations such as a risk analysis so what are the things that the software is doing your advice how have you mitigated the risks of software failure FDA requires you to develop a pretty detailed list of software requirements and and show how you translate those into a software design you have to do verification testing which show that that you your device meets all its requirements you have to do validation testing to show that the software and the device meet user needs and intended uses and then you need to have demonstrated traceability which basically means that you have to show that all of your requirements have been met and that you can trace all of the different hazard mitigations throughout the software that you've developed this is not an easy thing to do this is probably 50% of my time is spent helping companies do this but it's fairly predictable and I think it's it's pretty well understood what you need to do it's mostly frankly just a matter of doing it what's more complicated is when software is as a medical device and so this is how does FDA deal with software that is what we call standalone software that meets the definition of a medical device now when I talked at the beginning I mentioned that there are these sort of 1,700 different buckets of medical device types and there are a few of those that are actually standalone software most of them are not actually around in the 1976 when the device amendments were originally enacted but came along a little bit later one of the most notable are the picture archiving and communication systems and these are these radiology imaging systems that are used to manage digital images to store display them to allow radiologists the tools they need in order to interpret them a radiation treatment planning software is another example that's been around for a while as are some kinds of drug dose calculators but these the the number of actual classification regulations that actually are for standalone software are pretty small instead what you find is that most software has been developed as an accessory to a classified medical device and going back to my example of an electrocardiogram people have started started to develop or have started you know many years ago developed algorithms that look at an ECG waveform and can determine things alike is that atrial fibrillation or ventricular fibrillation or does this patient have a extended ST segment or other things that are known to be predictive of certain clinical outcomes and so you get this interpretative ECG similarly there's in and more recently a software algorithm called bists by spectral index that is used to evaluate EEG electroencephalogram waveforms and it's used to help to determine what the depth of anesthesia is so these types of software applications that are accessories to regulated devices even though they are somewhat new the regulatory pathway for these is also sort of fairly well understood but then we get into the the 21st century and and things like mobile apps and electronic health records and the regulatory framework gets much less clear and that's what I'm going to talk about for for the rest of this talk and that is how does FDA regulate standalone software and one of the the biggest categories that FDA has struggled with our mobile medical apps so the good news is that FDA issued a guidance document about a year and a half ago that provides I think some additional clarity around what it's going to regulate as a mobile app and what it's not there's still quite a few questions but I think you know the fundamental principles that FDA elucidated in that guidance document are that if you have a mobile app and it's going to be an accessory to a regulated medical device so for example I mentioned the interpretive ECG example or if it's used to transform a mobile platform into a regulated medical device and what this means is if you're going to take your phone and you're going to use it as a front-end for a blood glucose meter where you're going to attach a piece of hardware to it that is able to read glucose strips and then display the results on your phone that's transforming that mobile platform into a regulated medical device so anytime you basically replace part of a medical device a traditional medical device with a mobile platform FDA is going to regulate those mobile apps as well now the good news is that FDA is not going to regulate general-purpose mobile phone platforms so this means that the people who make the iPhone or the people who make Nokia or or any of the folks who make actual phone platforms they're not going to be regulated as medical device manufacturers even if people take their phones and put medical device apps on them so that was a very important decision that FDA made and the other thing that they've said is that they're not going to regulate owners of app stores and why this is sort of a little bit of a tricky area is if you go and look on most of these app stores that are out there you're gonna find all kinds of stuff that really looks like a medical device and it's pretty clear that the people who are putting it up there have not gone through FDA and you know the question at one point in time was well whose responsibility is it to police those app stores is it is that the owner of the App Store is it FDA's or is the people who actually put the apps up there and what FDA has basically said is it's the responsibility of the people writing the apps to make sure that they've obtained the appropriate regulatory clearances and that's that's sort of how FDA is dealing with enforcing that issue so the things that FDA has said that it's not gonna regulate as medical devices is electronic copies of books so or any kind of training tools things that are used for patient education tools for general office functions so if you have an app that's intended to use manage patient appointments or insurance or billing or anything that frankly doesn't really meet the strict definition of a medical device those are not going to be regulated as medical devices so we have this sort of clarity around what is a medical device which is things that transform a mobile platform into a device or use as an accessory we have pretty good clarity around things that are not medical devices and then what we have is this big bunch of stuff in the middle that FDA his said is going to be subject to enforcement discretion and what this means what enforcement discretion means is that FDA is not saying whether it's a device or whether it's a device or not a device they're saying if it is a device we're going to choose not to regulate it and what this does is it allows FDA it's some future time if FDA decides that in fact it does want to regulate something enforcement discretion could be given and it can be taken away in a heartbeat so this gives FDA the latitude it needs if in the future it decides that perhaps it wants to exercise greater authority over these apps and in the area that is really I think it has been the most interest to people out there and that I see the most absent is this first category here which are apps that supplement professional clinical care by coaching patients with specific diseases or identifiable conditions in their daily environment so these are apps that are targeted usually at people with chronic conditions like diabetes or heart failure example and that are intended to help people manage their disease or condition so they provide tools for things like diet and exercise or for managing stress or for any kinds of factors that are not directly clinical factors and the important thing about these products is that they are intended as I mentioned to help manage a disease not to treat it or to diagnose it and you know I think what this reflects is our our healthcare system is trying to move away from being a system where we manage people once they get sick to a system where we try to prevent people from getting sick to begin with and I think some of this is trying to help as FDA's recognition that there's you know a need for things to help people with these chronic conditions live a healthier lifestyle to try to deal with you know a lot of the challenges we're facing in our healthcare system so I think that was some of the reason why FDA took this path today has also said it's going to apply enforcement discretion to things like medication reminders tools that help people manage or track their health information so these are things that perhaps interact with an electronic medical record system or help manage prescriptions or just help patients be the owners of their own health care information the other interesting category on here that gets people into trouble are apps that perform simple calculations routinely used in clinical practice what FDA is envisioning here is things like calculating BMI they are not thinking about things that are taking results of genetic testing for 20 different genetic markers and developing a statistical model and then saying what the patient's likelihood is of developing breast cancer those are not simple calculations and this is another area that can be kind of tricky to navigate because these calculations what's happening is a lot of people out there are now trying to mine all of the healthcare data that's available and come up with things that are that I guess people would call evidence-based medicine where we're looking at the data we have on a particular patient population and developing models that predict potential outcomes and you know there's FDA sort of distinguishes between that kind of calculation and calculations that perhaps are based on clinical practice guidelines that have been well established by you know the major clinical societies and so this is another area they can be a little bit gray to navigate the other area that is also has a lot of interest are medical device data systems and this is part of the whole burgeoning electronic medical record system and these are applications that are used both within the hospital and between the hospital and patients to move medical data around an FDA had originally said that it was going to classify these as class 1 devices and as you remember class 1 devices are generally exempt from any kind of premarket review but these devices still have to comply with the quality system regular and fda believed that that was the appropriate way to manage these devices well over the course of the past several years there's been a bit of a turf war that has gone on between FDA and the Health and Human Services office of the National Coordinator for health IT and these are the people that are responsible for implementing the HITECH Act in rolling out electronic medical records and and establishing meaningful use you may have heard some of these terms and they are really they're the ones that are really pushing for this and I think they viewed FDA's actions in this area as a as a potential roadblock and so this past year FDA basically retracted that classification regulation and said it was going to exercise enforcement discretion over those devices as well and so that that means that that those devices are not going to be actively regulated the other interesting area out there are general wellness devices and this gets back to the the issue that I was talking about a bit earlier about wellness being not only helping healthy people but also helping people with chronic conditions live a healthier lifestyle and I think what's very interesting about this guidance document is that FDA says that it does not intend to examine low rifts products to determine if they meet the definition of a device and I've got my sort of see no evil hear no evil speak no evil monkeys there because what FDA is saying is they're not going to even ask the question about whether these products or device or not they're just going to exercise enforcement discretion and once again you know what they're saying is that these are products and these are software products but also some non software products that are for general wellness use and that includes risk of developing or managing chronic conditions and that present a very low risk and so you know this is I think it's similar to what FDA had said in the mobile apps guidance but it expanded that to cover not only software devices but more more other devices for general wellness in addition now the other area that is also extremely unclear and I touched on this briefly that is what we call clinical decision support devices and these are devices that are intended to help healthcare providers make clinical decisions now at one end of the spectrum you have clinical practice guidelines and so you have people developing apps that implement established clinical practice guidelines where you basically put your patient into this algorithm and it steps through an established clinical practice guideline and it tells you whatever the clinical practice guideline would have told you these are algorithms that are completely deterministic you get the same answer every time and they could easily be reduced to pencil and paper and flowcharts FDA has said that it's not going to regulate these as medical devices on the other end of the spectrum you've got these sophisticated algorithms that have been developed based on different kinds of statistical models some of these algorithms are learning algorithms where they they change over time they actually the algorithm itself may get better and that they make predictions about the likelihood of a disease or an outcome and some of them may even actually make a diagnosis and these sound like medical devices and will likely be regulated as medical devices then what you have is a whole bunch of stuff that's in the fuzzy cloud area and it's not clear what FDA is going to do with those they've been promising a guidance document on this topic and they've been promising it for several years and I'm continue to be hopeful that this will be the year that we get that guidance but in the meantime this is another area that's a little bit uncertain you know a potential path forward is you can submit something to FDA call it a 513 G and say to FDA here's my device how is it regulated sometimes though what you find is FDA gives you is sort of like the Oracle at Delphi where you get this answer back that is not at all clear that requires a great deal of interpretation and so I think that if we can get this guidance document would be very helpful


  1. Where is part 1

  2. Hi, Thank you for the Video

Leave a Reply

Your email address will not be published. Required fields are marked *