So You Want to Market Your Regulated Digital Health Device in the US?

So You Want to Market Your Regulated Digital Health Device in the US?

Show Video

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

Show Video

Other news