So You Want to Market Your Regulated Digital Health Device in the US?
good day everyone and welcome I'm Jack Van Horn from the University of Virginia and I am very proud to welcome you to this edition of our 2022-2023 foundations of biomedical data science seminar series the lecture series is supported by uva's integrated translational Health Institute of Virginia the UVA brain Institute the College of Arts and Sciences the school of data science and through a grants from the National Institutes of General Medical Sciences since 2016 the foundations of biomedical data science seminar series is focused on the use of data science methodology's artificial intelligence deep learning and statistical modeling as they pertain to differing themes in the biomedical and Health Sciences this year's theme is data science and the public health consequences of the covid-19 pandemic where each Friday we listen to talks from leading thinkers about the issues promises opportunities and hurdles associated with understanding the secondary health effects of covet 19. these include delayed Health checkups and treatments and mental health and drug abuse increased obesity and the long lingering health effects associated with this terrible virus indeed our 2022-2023 application cycle is now open and will be for only a few more days and so time is running out we really encourage you to if you're a junior faculty member working in this space or working in spaces such as infectious diseases epidemiology clinical medicine population Health as well as data science machine learning Ai and statistics and other relevant domains to please consider applying we have doing this for a while now and we believe this is a very exciting and engaging program where characterizing the secondary health effects this year characterizing the secondary health effects of covid-19 really necessitates unique quantitative approaches but also new multi-disciplinary collaborations the participants selected for our biomedical data science Innovation lab program will leverage presentations like we're about to hear as vital material for our culminating in-person Grant project development Workshop to be held at the lodge at St Edwards Park in Seattle Washington in June of 2023. so today I am delighted to welcome our speaker Dr vinay pai from the U.S Food and Drug Administration Dr pai is one of our mentors this year for our biomedical data science Innovation lab and he is a digital health specialist within the digital Health Center of Excellence at the Food and Drug Administration Center for devices in radiological Health in the office of strategic Partnerships and Technology Innovation part of the division of Health at the FDA and he's been there since uh September of 2019. uh vinay has his PhD in mechanical engineering from Florida State University and earned a masters of Business Administration from John Johns Hopkins University currently he is focused on Horizon scanning for new digital Health Technologies evaluating existing and emerging digital Health Technologies and helping to develop strategies for how to evaluate them prior to his time at the Food and Drug Administration Renee was at the National Institutes of Health First as a staff scientist in the National heart lung and Blood Institute and then as a program of officer and division director for biomedical Imaging informatics and health informatics at the National Institute of biomedical Imaging and bioengineering before the NIH vinay was a faculty member at New York University School of Medicine developing techniques using proton and hyperpolarized helium magnetic resonance imaging to study cardiac and lung function in continuing with our 2022-2023 biomedical data science seminar series the nay's lecture today is entitled so you want to Market your regulated digital Health device in the United States as fda's Center for devices in radiological Health recently established the digital Health Center of Excellence to provide regulatory advice guidance and support to the fda's regulatory review of device software functions a large number of early stage digital Health Products struggled to get to the U.S market due to the perception of difficulty navigating the cdrh regulatory processes vinay is going to walk us through the various Pathways for bringing digital Health devices and Technologies to Market in the United States he's also going to highlight the guidance documents within the digital health and medical device portfolios which can help and be useful during the process of moving digital Health Technologies from prototype to real world deployment as always we are streaming this lecture live and for recording via YouTube and if you are watching on YouTube thank you so much for joining us also our specially selected 2022-2023 biomedical data science Innovation lab participants and alumni are encouraged to submit any questions they have for Dr pai via the chat feature in their Zoom sessions I will synthesize these questions and ask them on your behalf during the last 10 minutes or so of the lecture and with that vinay welcome we are so excited to have you here speaking to us today so excited to have you as a mentor and we are really looking forward to hearing your lecture thanks Jack uh hope you can hear me well um and you can see my slide yep thank you um thanks again for the introduction and I'm going to jump right into the presentation because it's fairly extensive um and my presentation is going to focus uh the way I'm planning on doing this by showing some background content on the agency and the technology that we're working with before doing a deeper dive into guidances that are applicable for digital health um when you talk about the U.S foreign Drug Administration it's a it's a regulatory agency and the key word that is Regulatory and our responsibility is protecting Public Health um the agency does this through regulating a wide range of products as you can see here which range from like human drugs and biological products animal drugs medical devices tobacco products food cosmetics and radiation emitting electronic products and obviously the entire the camera activity is so vast that it's not run out of one Center there are several centers within the FDA which are responsible for regulating these various aspects of the agency and these are mentioned on the left and the right of the screen and yeah we also have extra additional centers like the oncology center of excellence so when you look at cdrh which is one of the centers as I mentioned it's Center for devices and radiological health and this is a Center focus on medical devices and um it goes without saying that patients are at the heart of what we do and our centers of vision as articulated by Dr Jeff shurin and is that we want to ensure that U.S patients have access to high quality safe and effective
medical devices or public health importance and first in the world so we shouldn't be lagging and having these devices come to the use of the US public in patients as soon as possible um I wanted to switch uh topics a little bit going from looking at an agency perspective to start looking at what do you mean what do we mean by digital Health technology because obviously uh when you come from an academic setting um you have a pretty broad spectrum of things and so when we think about digital Health Technologies we see how we see these things as convergence of computing power connectivity uh sensors and software that are used in healthcare and are applicable over the spectrum of healthcare as you can see from on the top where I can see from Healthy Living all the way out to like managing disease or treatment and having how patients are utilizing these Technologies in their treatment and Care Um this can also be either be used as medical products or be used to study a medical product or be either be incorporated into a medical product like a combination product or can be used as a companion or adjunct to a medical product including Diagnostics and Therapeutics so taking a little bit further on this axis it's like when you look at the solutions that are coming out in digital health and Landscape is pretty Broad and if you look at it you're not only thinking about moving the healthcare from the clinic to the patient but you're also trying to understand how behavior and Physiology is being impacted or looked at in the real world versus looked at in control clinical trials right and so digital Health gives us a lot of power in understanding some of these aspects which they had difficulty doing before and if you look at the type of solutions that you're seeing come out into the marketplace arranged quite a bit from like wearables where you look at like sleep apnea monitors or neurological models and like Telecare which is like activity monitoring which has been pretty useful for like pandemic uh conditions as you know and also thinking of things like health and wellness Solutions where people uh companies are coming out with approaches for improving different functions and trying to make sure that these devices can help the US patient population as much as possible and the diversity also gives us an interesting challenge because basically while you're trying to achieve the situation of U.S patients getting access to um medical devices Public Health importance first in the world you also want to make sure that they are high quality and they are safe and effective so balancing that those two sort of competing interests is always important to be careful that we don't miss that Target in that sense so as you notice the landscape is pretty Broad and it's evolving very rapidly and so in order to make sure that the agency was on top of things here we launched in 2020 the digital Health Center of Excellence or DH soe and this was basically driven by our ongoing commitment to advancing access to uh digital Health technology collaboratively the goal our goal in the center is to empowered stakeholders to Advance Health Care by fostering responsible and high quality digital Health Innovation and we seek to find ways to tailor our regulatory approaches um that is fit for purpose for these Imaging Technologies including like artificial intelligence and machine learning which has obviously a huge potential to a personal impact Public Health in we believe that this is a shared goal for all stakeholders involved in this space and we are a partner and contributor in the overall ecosystem and we want for Australia responsible Innovation to make sure that our standards of safety and effect in us are met from our perspective the digital Health Center of Excellence has three components in this addressing this goal um one is that you want to connect the work that's being done both inside the FDA and outside the FDA to other parts of the ecosystem and secondly we want to bring that knowledge together creating a network that people can stand upon so that there's less duplication and we can drive Synergy and the overall emphasis of all this is to make sure that we can innovate and that the Innovation not just like new technology coming to the U.S population but also make sure that this technology is safe and effective these are some of the areas of focus as you can see that it's a pretty broad sort of areas and it's a sort of living document incense that obviously new technologies coming on online as every day and so we had to be on top of these things and some of these are also cross-cutting to the Technologies already out there like real world evidence is a area of active interest across the entire Center and the agency and also this is not quite an exhaustive list obviously but we are looking at a lot of new and exciting areas of authorization and looking at it from a pre-marketer and post Market space like for example virtual reality and augmented reality and also looking at AIML and ranging from Advanced manufacturing approaches also to Patient generated Health Data or pght as we talk about so while we before we go down further into this very uh focused area of interest from a digital Health perspective I think it's important to make sure that we are all on the same page on some of the basic concepts that how the agency looks at things um versus how we may consider these words or concepts outside the agency or outside the scope of a pre-market authorization space so the first thing is we have to be careful when you talk about a thing called a device or a product so when the agency talks about a device we are basically saying that a definition that comes to us from the federal drug and cosmetic act section 201h and that's listed here in detail and basically the I'm not going to read the whole definition and you can read it obviously but there's some key aspects to this definition right first of all at the top you're having these kind of um content about what this thing is right like it could be an instrument apparatus Implement and so on and so forth but the other two aspects the key aspects here are the two bullets here the first one is like what is the intended use of this particular thing which is going to be considered as the device well if it is used in diagnosing a disease or curing mitigating treating or preventing of disease then it's a device right and so that's key when you come with the product to the FDA what are you doing with that product what is the intended use of that product so that is one of the key driving forces how we look at a device how we look at a product whether it's considered a device for us or not and the second thing we look at is like okay what is it doing um like is it intended to affect the structure or any function of the body and we're also delineating a device from a drug or a biologic where we say that it does not achieve its primarily intended purpose through chemical action right so a device is not a drug so so we're going to be careful about how we Define these things and so it also helps you understand which part of the agency your particular product might end up in based upon how you how the intended use of your device or product is set up and so you want to be careful when you're thinking about your product when you're building a product where you start from an academic Circle to going out to a startup or to a company and saying okay this is what I want to do think about this definition clearly and make sure that what you're doing with what are you intending to use this particular thing that you're building where does it fit in the spectrum of things that can be regulated um when you talk about devices uh as I said before it's all dependent upon how you what the intended use of the devices and also how we describe or the device is actually doing and what its technological characteristics are and then based upon those two criteria the level of regulatory control from the agency that is going to be given for that particular product will be inside it and we typically have three different classes class one class two and class three and the as you go up in risk of the device you go to a higher class and the other thing we have to mention here is that um basically like we use something called Product codes or Pro codes which is allowing us to um group similar devices together and make sure that we can sort of build a family of devices where they are doing the same intended use and so you can if you look at a product code you can tell what are the devices that have been cleared under that product code so um I I believe that this is going to be a lot of new Concepts coming to you because I used to be the United and when I moved to NIH to FDA the language changes of how we speak about scientific things if I may say that so here just it may be a little bit confusing as a lot of new definitions come here just be patient and you can go back and listen to the talk and get more feeling understanding of what actually these concepts mean so um this slide reiterates some of the points I mentioned in the previous slide and the key thing to note here as I said like classes one two and three and the risk level is increasing at the higher class but the main thing here is what are the controls right we have something called regulatory controls that are applicable to a product area and these are allowing us to provide consistent requirements so make sure that we are predictable safe and effective medical devices and we have appropriate level of regulatory oversight on these devices and so these controls are generally broad but maybe specific and at the bottom I've listed the general controls which are applicable even to the lowest class devices which is basically like you have to provide labeling for your device then you have to you have to do medical device reporting for example if there are device related injuries or that's you have to report that to the agency then you have to register your establishment with the agency and then here they have a device listing and like you could have like a global device IDs so approach and then your Quality Systems that you would have in place make sure that the device is safe and effective and finally obviously you have to make sure that you can track more adulteration and misplanting Concepts and these are the type of uh submission types that we get to see um Within These different classes and this basically for a moderate risk it typically will CFI 10K more than any other type of submission you will see some denova submissions too but most of the time it'll be a 510k or exempt submission then when you go to the highest risk device you'll pretty much end up with something called a pre-market approval or PMA device which is how which will have the highest amount of regulatory control on those devices when you look at the class 2 devices besides the general control we also have something called special controls and basically what we see here on the left is these are very they're specific only to class two devices not for class 1 devices and they're not typically common but basically applicable for well-established device types and when you're looking for uh example of where is a special control applied then you can look at the when you look at the code Federal Regulation and you look at the B section of that particular product it'll tell you like okay what is the classification what are the special controls that are applicable to this particular device and if you look at the I given some examples this is not an exhaustive list but these are some of the examples special controls that are placed on these devices because they are a little bit higher risk than like a class one device but they're obviously not as high as as a class 3 device so you can have requirements when it's coming in with your pre-market submission like you need to provide design or characteristics or specifications then you need to provide testing you may need special labeling and there are some guidance documents here to go through to make sure that your device um satisfies the special controls or be before it can be allowed to be authorized to be going out into Market in the US so here um this is a very simplistic and brief outline of the steps for bringing a new product to Market in the US uh through the FDA and I think the most important part in this particular slide is the link at the bottom because um I think cdrh learn would be a very valuable asset for if if you're bringing a device to Market in the US because it walks you through uh in fairly simple approach and logic that how you can explain all the process aspects for bringing your device to the market in the US and what are the various aspects of how we do research How We Do how you get your data together how you make sure that your Quality Control process is in place how you make sure you verify and validate your devices operation and so some of those things will be more easily explained in that site um and and this is this slide doesn't do justice too the expansive aspect of this thing and but very briefly going over the slide babe what do you start out this is pretty much sequentially what you want to do is lucky first of all you want to establish your product make sure that it's description and the intended to use the indications were used the duration of views like how long should we use in the Target population like for example uh it could be age range which you wanted water age range is it applicable for what type of populations what disease is it applicable for those kind of things you want to get that clear first and then you want to go to like you want to verify that this product is actually medical device remember as I said the federal drug Food Drug and cosmetic act tells us like what is the device and so does your once you define your intended use does it fit within that particular definition or not where does it fit in that scope and then once you've done that like you want to find the classification regulatory pathway is it going to be class 1 Class 2 class 3 and which particular pathway do you want to go down based upon the risk it'll tell you once you have figured out that these are the things I have to do then you then go ahead and build your evidence for your scientific evidence make sure that you can come in with the free market submission but I would strongly encourage any or any of you who's interested in bringing a device to Market is work with the FDA as early as possible because the earlier you get those involved in your process development of even from like once you established that this is what you want to do you can come in and talk to us and say okay this is my intended use where do I fit in your scope of controls and it might be something as simple as saying okay your device we don't or you're a product we don't regulate in which case you might have a different pathway versus we say Okay a high risk products because you're doing X Y and Z and so having that conversation right at the bat I think it's going to be very valuable rather than waiting till you are up at step five and then coming and talking to us and then realizing you had to go back and redo a lot of things because you totally misunderpreted what regulatory systems are so talk to our review divisions as much as possible and you can all I'll put out I'll provide an email address reach out to us and we can connect you with the review divisions which are appropriate for your particular product but please do work with us as early as possible rather than waiting till the end um but when you talk about devices then question becomes how does that apply in the scope of digital health and it gets very interesting when you talk about devices in the digital Health Spectrum so we start out on this initial definition right which is saying the section 201h of the food drug and cosmetic act has a definition for device an Indian product that's not within that spectrum is going to be something that we considered not a device so okay that's clean and easy but then the Nuance that quicksand kicks in is that we have the 21st stage cures act that came in and said that okay when you're thinking about software functions there are some parts of software functions that should not be considered as a device that should be regulated by the FDA and so once you start thinking about that aspect then you realize that there are a lot of software Solutions the software functions that you can develop which don't necessarily have to come to the FDA and you can go straight to Market and so this is uh the first guidance I think which uh which is the power listed at the bottom here which we call the 3060 guidance and basically what it is doing is it's listing the changes that apply to existing medical software policies because of this cures act and as you can see here from left to right like there are a lot of software functions that it talks about which it says that these are sort of functions that do not need to be regulated by the FDA and so I'll be going to more detail into these different sort of functions um as you go forward but think about when you're building your product like where does it fit in this spectrum does it fit in these kind of um sort of buckets or not and then that's where you go from like how when you talk to the FDA also and in the previous slide I mentioned the word function and I want to make sure that when we talk about function within the agency or within like pre-market space or in the authorization space we have a different meaning than like a mathematical function right so in here we are talking about a distinct purpose of a product and so when we talk about a function a device function basically it's a function that meets the definition of a device so that's something that we can potentially regulate and then when you say device software function we talk about a software function that meets the device definition so you want to be careful that when you say function here we talk about how does this thing function what does it do and basically when we and as it goes back to the pointer is the beginning of this talk which is like the whole thing hinges on intended use of the product what is the product doing so the intended use is a function of that particular product and you can have multiple intended users and so for example if you just are having one intended use which is analyzing the data then it's only one function which is analyzed data on the other end if it's Integrity you store transfer and analyze then it has three different functions right it has a function to store it has function to transform it is a function that will analyze the data that's come through it and do something with that right so you want to be careful that when you start to build your product you have to think about what are the functions of this product and what which basically translates to what are the intended uses of this product and then you can go down to Pathways okay this is a device function or it's not a device function and so when you talk about not a device function sort of thing we talk about other functions and I'll come back to this later but basically it's a function that does not mean the definition of a device so it can be an intended use but it might be an intent to use that doesn't fit under Section 201 edge of the food drug and cosmetic acts and so or it could be something like it could be an exempt kind of function so you want to be careful about the nuances that apply to any of the functions of a device and so when we're looking at which functions are being reviewed by the FDA then it's it'll be called device function review and so on and so forth so obviously I'm not suggesting that you memorize all this and you shouldn't but it's a slide that I put up we can go back and look at it and these are definitions that are available on the FDA website and you can look at them and understand the nuances of how things are looked at when they come into the agency the other thing I was also going to mention is when you think about the intended years which I mean uh sort of mentioning all along is like um we had an amendment um to this in intended use through the 24-hour CFR code of federal court Federal Regulation 801 where basically like there was some aspect related to okay how do you define intended use right how do you know what the products intended to use is and so here we provided more clarity and Direction regarding what type of evidence can be used to determine its intended use and so we can use any relevant source of evidence which can include direct evidence you might have supplied or um to us when you submitted your application or like interact with circumstantial evidence such as how you're selling the product in the marketplace and quotes that recognized that self-serving labels cannot be used or cannot be allowed to mask the vendors true intent as indicated by the overall circumstances so the intended use can be determined using these different um approaches to truly understanding whether person or the spawn the device manufacturer or product manufacturers how is how are they trying to sell this device so what is it being sold for so going back to the regulatory classification question when you talk about digital Health Products um where does a particular digital Health product sit is dependent upon the risk categorization of that device and the intended use of the device so you can either be a not a device we are looking at remember a device is not a product device is something the ftnc act or we can intend to use exercise something called enforcement discretion and I'll come to that in the future next subsequent slide or it'll be under the regulatory oversight of the Ft in which case it's a different pathway it goes down so when you look at software functions right and um basically like if it's a software function the we want to look at how it's regulated and you can see at the bottom there's an error which goes increasing risk and basically as I said in the previous slide as a risk of a device increases the risk of the intendities of the device increases then the more oversight comes into play from the fda's perspective and so if you're on the left hand side of the risk cab flow then you are basically looking at functions that are intended for like a log record so this is an example right so in which case we're saying that you can either log record track a wallet or make decisions or behavioral suggestions but there's no reference to a disease or a condition in this in this particular example on the other hand we start adding more information like we're trying to help smokers quit or you want to help patients recovering from addiction or you're developing apps or pregnant women then these are apps or you may the risk level is higher and then the agency has an intent to exercise enforcement discretion depending on the where the risk sits on that particular profile for those particular devices and finally then if you're looking at a product where you're building a sort of function that uses sensors or leads to track measure and display like electrical signal like ECG then those are higher risk products and so we definitely have a regulatory oversight on those products foreign so in order to help industry and consumers get clarity on the regulatory aspects related to software um cdrh has been has released a number of guidance documents over the last few years as I've shown here uh some of these are in draft state which means that there's not considered final guidances and they are currently they're accepting public comment or we are evaluating uh comments that have been provided by the public before after the commenting period is closed and the final guidance will be published sometime soon um but definitely these are documents that are can be sometimes difficult to read and understand but can be once I mean they're very valuable in helping you understand how the agency is interpreting uh authorizations or Congressional authorizations rewarded to it I think the key uh tool that you may want to start out with is something called the digital Health policy Navigator this is something that the digital Health Center of Excellence recently made available it's on our fta's website and this is mainly to help product developers understand how their software function fits within the regulatory framework of the agency it's an interactive workflow and you basically uh answer different questions which are shown here like different steps and based upon how we answer these questions it's a rule-based system where it basically takes you down different Pathways and it tells you like okay based upon how we answered a particular set of questions um you will either be like will not be a medical device or it could be some a device or a product where enforcement discretion applies or a device where you have to come in and talk to us and have regulatory oversight on that and so and it's a nice starting point it's um but it's not the be all an end also just because it tells you one thing it doesn't necessarily mean you shouldn't and talk to us but I think it's a good starting point to tell you where you are in that spectrum of which guidance is applied to your particular device so I want to do a deeper dive into some of the aspects related to software functions that we talked about and so um I'm going to start with more of the functions that we don't have the FDA doesn't have kind of considered as devices and so this is coming from the section 5201a of the fdnc act and basically any software function that you build which is for administrative administrative support of a healthcare facility those types of functions are historically not considered to be devices by the agency and so I've provided some examples here where basically if you are uh tracking Financial records claims of billing information or you're looking at building scheduling for your medical staff or if you're building a software for like analyzing historical claims data for cost effect in us or looking at health benefit eligibility those are the functions that the FDA doesn't get in um look at as devices it's not to say that any other regulatory agency within the federal government may or may not have it uh opinion on how these functions are deployed but from the FDA perspective this is not something we look at um then the second one I think it's a interesting one for digital health because they will see a lot of products out there that make a large number of General awake claims about health so uh when we talk about General Wellness we we are basically considering two different types of products so one is that either the intended for only General Wellness use as defined in the guidance of General Wellness or and they present at lower risk to the safety of these in other persons and basically what we're saying here is that we do not intend to examine low risk General Wellness products and basically the thing becomes like how how are you defining these kind of risk low risk and General Wellness and so one of the ways if you look at the guidance the two categories that we talk about winter about low risk and uh but if you make if your product is making claims about sustaining or offering General Improvement uh to functions associated with the general cdfl then do not make any reference to disease or condition then that's one category of General Wellness on the other hand if you're talking about making reference to disease or condition you're only um making intelligence claims of sustaining or offering General Improvement functions associated with the general state of health and so basically we are talking about relationship between healthy lifestyle choices and sustaining a general state of health so think about these aspects when you are trying to think whether you're in the devices your products intended to use is a general awareness or not and so when you are in that space I would recommend again as I said before come and talk to us the next one I want to talk about is electronic health records and this is an interesting area of focus basically that um under the section 5201 C of the fdmc ACT some software functions that are intended to serve as electronic patient records are not considered as devices and so these are three different conditions that apply they have to all we have to be met and the first two I think the third one is the most interesting one and basically the first one basically says we're creating it for people like for healthcare professionals or individuals working under Healthcare professionals supervision are the ones looking at creating and storing or reviewing these kind of Records they also have to be part of like no NC Office of the national coordinator for Health Information Technology based upon the Public Health Service Act 3001 CF and so if it's under that program and the third thing which is important is to know that these should not be intended for interpretation analysis no patient records including like medical image data but the purpose of diagnosis cure mitigation prevention on treating of disease or condition and if you if you remember this the last part of the language actually comes if from the food food drug and cosmetic act right we'll talk about the intendities of this particular function and where does it fit in so if you're using that particular function for these kind of activities then yes that would be a device because of the it's doing diagnosis cure and all that other potential possibilities the other thing to mention about the EHR is that basically at this time there's some overlap with um I think I mentioned the second criteria that there's overlap the onc uh which is part of the statutory definition of this particular uh process and so even after you established that a product is an EHR you have to be careful the fact is that when you're talking about product functions that just because you have an EHR function does not mean that other functions of your device are not or every product are not a device right so you want to be careful about you might have one function which is the HR but there might be another function which might be doing something which is which can be considered as the device for the FDA so you want to consider all these functions separately and also a value you want to evaluate that anything either you add new functionality to your product see how that impacts within that fdnc act and again going back to the 3060 act 3060 guidance you want to look at how the different criteria are describing electronic health records for healthcare professionals and we also said that in the second bullet we're talking about like how if it enables patients individuals to non-healthcare Providers to create store or transfer health records They are considered personal health records so these are not meant for as I said before because they're not meant for intended use of diagnosis key or mitigation so on so forth they would also not be considered devices under the ftnc ACT section 201h um going on to the next guidance um this one is uh interesting one because it's talking about medical device it's a pretty long name for the guidance which is basically talking about medical device Data Systems medical image storage devices and medical image Communications devices and we I have a short economy for that it's called mdds and basically these are hardware and software Hardware or software products that are mainly intended to transfer store convert formats and display medical device data the key here is that the mtds cannot or does not modify the data or modify the display of the data and does not control the functional parameters so like for example if you think about a hardware device a router would be considered Hardware device it just transfers data from one point to point point A to point B and it doesn't modify the data or modify the display of the data and does not control the functional parameters of any other medical device so it depends on how you look at it and it's very valuable to think about your device whether it's an mdds or non-mtds and so when you think about um mtds system we have software functions and we have Hardware functions and so each of these can be considered differently and if it's it's a software function that just transfers towards a converts format and doesn't uh do all the modifications that are controlled then it's not a device and it won't be subject to regulate requirements similarly when you think about Hardware functions that again do the same kind of activity or actions then those are considered as device mdds and for certain device entities we do not intend to enforce the requirements the next interesting part as you transition from like General Wellness from tmtds to clinical decision support systems um this is a interesting area because there's a lot of action we're seeing from artificial intelligence so machine learning related to clinical dishes and support systems and so CDs is basically a tool that allows Healthcare professionals and patients to get more information and to filter that and have it presented to them at appropriate time to ensure that health and Healthcare is delivered correctly um so the key is obviously you want to make sure that these are all safe and effective and there are a lot of different aspects of CDs as you can see here like you can range from like clinical guidances guidelines to developing diagnostic support or having contextually relevant reference information so uh this field is pretty big and Broad and we have um um the cures act has talked about like the 5201e that the fdnc ACT has also provided some information like as to how do we decide whether the particular CDs is uh something that should be considered as a device or can be excluded from the device function and so there are four statutory criteria that have been defined in this particular section of the ACT which are allowing us to determine whether particular function becomes a device or not device and so when we talk about non-device we're talking about basically those functions that do not mean the definition of device right that we talked about before and the other thing is like when you talk about functions which are excluded from device definition we have to be clear that these are independent of the platform that they're being run on so it could be running on as Android or iOS it doesn't matter it does you know these functions are excluded from device definition independent of that so these are the four criteria from the cures act right and so the key here is that all four conditions have to be met or um there so if you look at it uh there it starts you start from the first one you go down the rank that way and basically the first two are basic input kind of uh aspects basically you're saying that is it intended to acquire process analysts a medical image or the second one is intended for displaying something and then the last term I mean look came from the output perspect like is it providing an intended to provide recommendation and for finally is it like intended for enabling uh Healthcare professional independently review the basis of such recommendations so any CDs software that you develop it has to meet all four conditions to be excluded from the device definition so it can be a little hard to make sure that you hit all four of them um this cartoon like sketch or graphic outline which is available online fda's website um it's sort of like a cheat sheet of how this process works and so the top row is basically saying that if it meets all these four criteria that are shown here then that particular one would be considered as a non-device CDS but if it fails any of them then you are no longer you are pretty much a device and we will be regulating you and so for example if you look at uh a device example if you're looking at in vitro Diagnostics or you can MRI and next-gen sequencing those kind of functions are you're failing this particular step one right and then you go to like step two for already looking at like ECG you are looking at Medical images and then this question becomes okay how are you looking at those confirmation and then the other examples here looking at like Risk score for disease or conditions and probability of a disease or a condition that you might have and then final time critical outputs are something that we always are concerned about and finally like here we look at if you if your AI for example if a algorithm is not providing the basis of the recommendation that it provides you as to why a vertical action is Justified to be taken and if if the clinician cannot understand why that's being done then that's something that people want to see as a device um going further down we're talking about um policy for device software functions the Mobile Medical applications or as you call it the tsf MMA guidance and this is an interesting guidance because it's a it's a fairly broad guidance and it's very useful reading to understand what kind of aspects of digital Health come under the different Umbrellas of whether it's a device or it comes under reinforcement discretion or whether it's regulated by the FDA and so I think it's a very useful starting point when you start to look at digital Health Products like which guidance you want to start with I think I would recommend this particular guidance it's all our guidance is obviously well written but this I think feels like a very nicely collected Gardens and it's sort of like a first go-to guidance when we have any example or a question come into us about a digital Health inquiry and then we say okay how did we interpret it in this particular guide and so I think um if you're starting out in the field it's a good guide to start out with and some of the other aspects related to this particular guidance is beside the fact that it defines some of these functions it also talks about like we do not regulate the sale or you generally use of consumer use or smartphones or tablets and so this was one of the things I think comes easy out output from this guidance but I think as I mentioned before the main things that are relevant here is the fact that we're talking about where are the regulatory oversights that have been established through this guidance we're talking about um it walk um basically we're talking about which software functions are medical devices are not medical devices and which are the ones where we intend to exercise enforcement discretion and the right hand side talks about what do we mean by enforcement discretion right basically we're saying that even if it meets the definition of medical device we do not intend to exercise enforcement like basically like uh we believe that these functions are for proposing lower risk to the public based upon the evidence we have in the field or from scientific literature and so um generally we intend to exercise enforcement discussion for several different types of examples and um if it's something that's helping a patient self-manage the disease or condition without providing specific treatment or treatment suggestions then we definitely are looking in that space and so I'll list two here but this is not exhaustive and if you if you you can go back to that guidance and look at the different examples and different scenarios that have been laid out of how enforcement policies uh implemented in those conditions I think um that would be a good guidance look through the last one I want to talk about is something called the multiple function guidance and this is a when you think about a product which has multiple functions um remember we talk about let me say functions we talk about internet use and so um depending on different intended use this guidance gives you clarity about how we look at the other functions right and so you look at the right hand side we talk about what's another function well it doesn't meet the definition of a device or if it meets it then there's some kind of exemption that's applicable or if it's meeting the difference but some kind of intent the FDA is expression is not to enforce compliance and so when you talk about these kind of other functions as being part of a device itself then how does the FDA look at those particular functions and this particular guy this multiple function guidance walks you through some of those aspects so just because they're part of a multiple function device doesn't mean we want to look at it on the other hand we will look at how this particular other function impacts the the device function that we're actually interested in right so you want to make sure that the device function that you're reviewing are not in their safety and infection is not impacted by these other function that you have sitting on the side so for example if you have a general purpose Computing platform we don't regulate that but we are interested to know how does that General function general purpose Computing platform that you're using for your app which is sitting on top of that how does that interaction work and how are you ensuring that your app is safe and effective when there are issues or aspects related to the general purpose Computing platform so we would ask for that kind of connection to be established and so similarly for the hardware that if you are looking at uh integrastic balloon which is subject to a PMA or pre-market approval and you have an endoscope accessory that is 510k exempt for example in a desktop guide where we may still want to see how this guide were impact the safety infection of the balloon so in that sense you have to be careful that when you look at devices multiple functions how do the other functions interact with your function that you're actually coming to the agency with for authorization so um basically if you look through the gardens it'll talk you through like you want to look at do a risk assessment right and so when you do a risk assessment you want to see what the other function impacts as far as the device function that review if there's a positive impact like it improves safety and Effectiveness right for example uh increase gpus or higher neural net or something like that then you want it obviously improves processing speed but it has something that we want to look at and also you want to see if there's an adverse effect right if it's for example you added some kind of lower capacity Ram or something like that in which case obviously a computation time slows down and so we would like to know what kind of or if you added a software Library which has slower computation now it was not updated for a while then in which case those functions can impact adversely so you want to know how does that particular function even though it's not necessarily something we would have looked at but question becomes how does it impact the safety and effectiveness of the device function that we are looking at and then so once you've considered all those aspects of risk assessment then you need to include that in a pre-market submission that tells us how these other functions impact um this the device function that review and you you mainly do that when you either positively impacting and you're going to show that uh for the function the review and or if it's negatively impacting the device function in the review so I know this is in a whirlwind tour of digital Health at cdrs and um Jack has my slide and this information and as I said cdrs learn is a great site to go to to learn more about how we look at different devices and how we regulate them I want to conclude by just summarizing some of the aspects I had on during this talk which is basically saying like when you talk about software function it's a device if it's intended for use in the diagnosis cure mitigation treatment or prevention of a disease or condition and so what we the way we the vocabulary we use if we call them device software functions so remember the word device has its own meaning and then we take what software functions that are meeting this device definition so that's how we Define software functions and then when you look at the 21st century cures act um there's some software functions that are excluded from definition of a device so and we have as I walked you through several of our guidances these can help you understand okay whether your particular product is coming under that or not right and so they'll help you understand like whether you um you need to walk through all the different aspects or not but I think at this end of the day having good quality control systems in your processes as you build your product is going to be always valuable even if it's a device not authorized not coming under FDA uh or purview I think for success of your product and your company I think it's valuable for you to build good quality control systems within your product development processes so that's something I would encourage and then when you look at regulatory oversight we're looking at primarily sort of functions that are medical devices and we're looking at risk categorization if it's functionality failure would impact the safety of the patient then it's something we're really interested and want to oversee uh like from a regulatory perspective and as I mentioned uh towards the last few slides that we recognize that there are function products that have more than one function or more than one intended use and so the question becomes like you want to make sure that when your other functions how about those other functions impacting the function that you're looking at from a regulatory perspective and you want to make sure that we look at both positive and negative aspects of those other functions and the last thing I want to point out is like there are several ways you can reach out to us we have the digital Health inbox which is as shown here digital Health at fda.sha should go where a number of guidance documents that you have released and we also have regulatory tools such as the digital helpers Navigator and also cdrs learn is another valuable tool which you can use to get to understand how you bring your product to Market in the U.S so this is the last slide and basically if you have any questions you can either reach out to digital Health at fda.hs.gov or you can email me also directly if you need to thank you vinay thank you so much this um stuff you talked about here I think will be of a lot of interest to many folks who are parts of our biomedical data sense Innovation lab and generally speaking a lot of at least the work that we're familiar with through our interactions with the community from where we sit here at UVA have been in the space of developing computational algorithms that are linked to some sort of biometric device and so what you're talking about here where there's the device itself and there's the software there's the interaction between the two I think this is exactly the kind of information that people who have these if they're looking at cardiac function or they've got their uh you know basically looking at the eye for example or they're you know making some other metric like with a wearable device that and they want to Market it that this is the kind of information they need definitely and I think um the one thing I mentioned at the beginning and I will keep happening awaited because we have discussions with within the agency also like um any developer of a software should come and talk to us as early as possible and uh we are friendly we we are nice to talk to us so uh please do reach out early don't wait till the last minute and then you I mean it's a lot of investment as I mean when you build startups it's a lot of upfront Investments you want to make sure that at a minimum you're on the right path for this particular product I think that's very very good advice one of the things that um I wanted to ask about is and we were sort of talking a little bit about this before we got started today but you brought it up several times and you really kind of iterated on it um about how much terms matter um and the definitions of these words that perhaps those of us who don't know any better would use interchangeably but you point out um rightly so that you know that there is a difference between in a device and a product and you gave several other uh several resources to uh for people to look at to avoid confusion are there any common mistakes that people make in mixing up terms that could you know they might use in one context but to the FDA mean something else um how to come back and look at because I'm pretty sure there are now I've been so immersed in the FDA approach of thinking about things like sometimes it's hard like I think I mentioned before the call like the word signal has a different meaning within FTA connotations and um I think also like words like monitoring or I mean so post Market is an interesting space where we look at how devices perform in the real world and so some of those aspects related to how devices are monitored or tracked can be meaning different things of different agencies and so I think that's one aspect I think device and product is the most obvious one I think because we have a clear I mean we food Dragon cosmetic is act is clearly defined for us what that means and those words have specific meanings and I think the other place where we are had aspects that is in AIML because especially when you talk about bias trying to understand different types of bias like statistical bias versus systemic bias and understanding explainability of a algorithm those are some of the nuances that are different from different uh perspective not just within the agencies but also even in the academic Community as to understanding what those particular words mean and I think one thing I was going to mention is that we have something called the imtrf which is international medical device Regulators forum and we have started to build glossary of words and so that we also understand when we're sayin
2023-02-04 10:18
