AHLA's Speaking of Health Law
AHLA's Speaking of Health Law
Clinical Decision Support: The Regulatory and Practical Implications of a Rapidly Developing Power Tool
While clinical decision support tools, especially with the advent of artificial intelligence, have the potential to greatly improve patient care, there are concerns related to patient health and safety and fraud and abuse. Anthony Burba, Partner, Barnes & Thornburg LLP, and Gail Javitt, Director, Hyman Phelps & McNamara PC, discuss the promise and perils of these tools, navigating the Food and Drug Administration’s regulatory efforts, issues related to data storage and validation, and advising providers who are implementing these tools. Anthony and Gail spoke about this topic at AHLA’s 2023 Annual Meeting in San Francisco, CA.
To learn more about AHLA and the educational resources available to the health law community, visit americanhealthlaw.org.
This episode of AHLA speaking of health law is brought to you by a HLA members and donors like you.
Speaker 2:For more information,
Speaker 1:Visit american health law.org.
Speaker 3:Hello and welcome to this AHLA podcast. Uh, my name is Tony Berba , and I'm a partner with Barnes and Thornburg practicing out of our Chicago, Illinois, and Washington DC offices. My practice , uh, centers on healthcare fraud and abuse matters, everything from regulatory counseling to government investigations and , uh, trial defense, a false claims act, and criminal matters in the healthcare space. Um , joined today by , uh, Gail Javit , uh, who is a director at Hyman Phelps and McNamara PC in Washington, dc . Gail, do you wanna give a little bit of background on your practice?
Speaker 2:Sure. Thank you. So I am, as you said, a director in , uh, Hyman Phelps and McNamara. We are , um, a dedicated food and drug law boutique law firm. Uh, I focus primarily on FDA regulation of medical devices, which increasingly includes software.
Speaker 3:Excellent. And our conversation today is gonna be related to clinical decision support tools. Uh, I think we'll cover a number of topics related to CDS , uh, in this podcast. Gail and I, along with , uh, our colleague Ted Chen , who's the , uh, chief Compliance Officer at WakeMed Health System in North Carolina, did a presentation on this during the annual meeting , uh, clinical decisions, support tools, <inaudible> that are designed to assist in the treatment of patients in various ways. Um , these can be anything from computerized alerts and reminders , uh, to providers and patients that may be , uh, administered through a , uh, physician practice or hospital's , um, EHR system , uh, as well as , uh, text alerts and email communications , uh, to patients reminding them of, you know , uh, scheduled visits or , uh, potential , uh, treatments they might need to receive. Um , typically these alerts and different , um, clinical decision support tools are driven by a decision engine that is , uh, in the best cases built on clinical guidelines that are sort of peer reviewed and generally accepted in the industry. It would be interesting, Gail , to hear from you on sort of how the FDA is thinking about these tools and what some of the recent developments in that area are.
Speaker 2:Yeah , sure thing. And , um, you mentioned , um, artificial intelligence, Tony and I, I think that's really what's gotten FDA's attention. I mean, so we've, you know, software has been part of medical practice in some ways for a couple of decades now, but really the, the promise and peril of , of AI is the level of , um, sophistication and the, the power of the tool essentially. You know, computers are so much better at , um, crunching through lots and lots and lots of data and doing it quickly and looking for patterns that we , uh, we humans , um, are not so good at and certainly can't do it , uh, in, in the , the same , um, order of magnitude of time. Uh, so, so the promise is that we can use the software to predict , um, the course of , uh, treat , uh, treatment or course of disease, and also potentially to identify it and prevent disease. Um, and we're al already starting to see clinical decision support type , uh, tools that , uh, that can, for example, help you treat , help a doctor, triage a patient . So who's, who's probably having , um, a stroke and needs to be put to the top of the list , um, who may be rejecting a kidney that they just received and should get extra monitoring , um, who's likely to have a recurrence of cancer and should get more aggressive treatment versus who is less likely and then potentially can forego potentially dangerous treatment. So a huge amount of potential, but , um, sometimes this , uh, there's not necessarily so transparent how the software comes out with its recommendation. So, so FDA's concern, of course, is, is always the patient and whether the information that is being given to the physician , um, is, is accurate and, and has been validated. Um, and, and so that's where , um, clinical decision support comes in. And, and the recent developments that , uh, that we are , we're focused on today come in. So , um, as I , as I think most people know, the Food and Drug Act is an old, old statute , um, more than a century. And, and certainly there was nothing like software around in the early 19 hundreds. But yet , um, the definition , uh, is of a medical device , uh, which is something FDA has authority from Congress to regulate , um, is broad enough to, to encompass software and just , uh, to give our, our listeners , um, a little context. Um, a medical device is an instrument apparatus, implement machine contrivance implant in vitro reagent or other similar or related article , um, that is intended to diagnose disease or conditions or for use in the cure mitigation treatment or prevention of disease. And unlike a drug, it doesn't achieve that effect through chemical action, but rather through physical action , um, and does not , um, is not dependent on being metabolized in the case of it may not even touch, touch the patient. So a clinical decision support tool can help in diagnosis, treatment and prevention without ever touching a patient, because what it's doing is informing the physician , uh, and, and the physician can then use that information for diagnosis or, or treatment or prevention purposes.
Speaker 3:I'd be interested to hear sort of, you know, from your perspective and in your practice, if you have , uh, a client who is operating in this space, how , how do you advise them on where the line falls as to whether or not they need , may need to approach the FDA about their product versus whether they're just, you know , uh, they're sort of safe in the gray zone as a normal , uh, you know , EHR tool or program
Speaker 2:Other than , uh, flipping a coin and hoping for the best <laugh> <laugh> ? No , that , so I wish, I wish there was a , a magic line , uh, that that, but unfortunately there, there's a lot of gray and, and that's not unusual when you have complicated and, and emerging technology. Congress did try to put some bright lines around this , um, back in 2016 with , um, the 21st Century Cures Act. Um, so I, I just mentioned the definition of a medical device. Um, Congress , um, created a carve out for types of software functions that FDA said, Hey, these are not medical devices, because , um, it wanted to streamline the process. So the things that really didn't need to go through FDA didn't get caught up , um, in unnecessary , um, you know, time delay expense. Um, so FDA identified a number of types of software functions that were not medical devices, many of which FDA wasn't in fact regulating, but just to, for, you know, for clarity. So administrative support, so handling financial records, billing information , um, electronic patient records as, as you just said, transferring, storing, displaying test data or other outputs of medical devices. Um, so, so FD Congress said, Hey, FDA , those are not medical devices, don't regulate them. Where it gets more complicated , um, is if the software is also intended to interpret or analyze data from a device such as a clinical laboratory test , um, or, or imaging, you know, MRI , any other type of clinical data that that medical devices display or , uh, output. Um, then the question is , um, you know, does FDA regulate that, so FD the congress , the 21st Century Cures Act , um, in 2016 , um, address specifically clinical decision support tools and said, some of them are subject to regulation as medical devices and some of them are not. So they , um, Congress established four criteria for trying to distinguish between things FDA should not regulate and things FDA , um, should regulate. So , um, as a threshold matter, Congress said, this carve out that we're creating does not apply to software that is analyzing images or signals from an in vitro diagnostic or patterns from some other type of medical device. So if you're doing any, any software that does any of that is still a traditional medical device , um, but software that acquires other types of data , um, and makes predictions based on it could potentially be exempted from FDA oversight if it meets certain other criteria.
Speaker 3:Uh, thanks Gail. Um, I think some other , um, interesting areas on this topic , um, also relate to things that CMS is , uh, CMS and HHS are regulating. You know, one of the key areas here is, is privacy. Um, you know, that's an area that I think from a compliance standpoint , um, providers should have , um, should have some , uh, understanding and visibility into if they're gonna use these tools. Often these tools are driven by third party companies. Um, you know, some software companies like Epic and the larger EHR providers will have their own tools, but they'll also implement through their system, you know, certain third party apps that can be utilized. And so there can be a lot of data exchanged between these various entities, and it's important for, you know, in particular health systems and large medical practices , uh, to be mindful of this when they're putting their business associate agreements in place with , uh, their EHR company to understand what other third parties might be , uh, obtaining their patient records and data, how they're being protected and those kinds of things. Um, I don't know if you've had any experience with , uh, the privacy end of this or , um, you know, I , or how the data collection and data flow might impact the FDA analysis.
Speaker 2:So, so I don't think that , um, that affects whether it is or is not a device per se, because , um, whether something's a device depends on whether it meets the, you know, the statutory device definition of, you know, intended to diagnose, treat, mitigate, cure, prevent disease, et cetera. Um, which is, you know, data agnostic. But where it does come up and where FDA regulations should be considered , um, is around the permission to use the data , um, as part of the research and development of a software tool. Um, so , um, FDA has regulations that , um, oversee human subjects research as, as does , um, you know, NIH and other federal agencies. Um, and they require informed consents , um, not only for , um, things you do to a patient, but often when you're using information about a patient to, to do research. Uh , so it's important to ensure that if you have a dataset , um, and, and that, or , um, sample , genetic sample , uh, sorry. So , um, tissue samples , um, when you wanna study , uh, genetic or other information , uh, from a patient that you have obtained appropriate consent , um, in order to use that data. And often also , um, or typically you would want to have institu , uh, an , um, institutional review board oversight of a protocol to , um, ensure that the , um, data being used has been , uh, properly obtained and that subjects understand how it's going to be used.
Speaker 3:Um , yeah, you know , and I think that there's another issue that , um, has, has come up with some of my clients in this space is just , um, you know, how do you pay for these tools? Uh, you know, there's a certain amount of research and development required , uh, to build out these decision engines and to , uh, create these products. I know with some of my clients, the, you know, you're , you're end customer for the most part is the health system or , um, you know, large physician practice who's gonna implement the software to assist them in the treatment of their patients. But oftentimes, you know, those are not high margin , uh, institutions, and sometimes there's some difficulty in terms of paying for that development. And so, you know, one of the interesting things that I've seen, and it puts you right at the cross cross section of the DOJs Enforcement action, is, you know, to what extent can other traditional , uh, life sciences companies , uh, both, you know, device manufacturers and , um, pharmaceutical manufacturers , uh, engage in funding of the development of these kinds of tools? Uh, I know on my end , um, you know, it certainly propose , uh, creates a risky proposition. Anytime you have a , um, company that's, you know, producing a product that's reimbursed by federal payers that's going to be potentially promoted at a higher rate through the use of ACDS tool. And I know the OIG in particular finds that to be , uh, a high risk area. You know, I think when I'm talking to my clients, I, I talk about things like making sure that the, regardless of who's funding the development, you know, you gotta make sure that you , uh, have a defensible CDS uh, algorithm that's based on neutral , uh, you know , uh, generally accepted medical practice and that you are not promoting a particular , uh, drug device or treatment over , uh, others. And so, you know, and , and also avoid things like <inaudible> and, you know, maybe focus on, you know, partnering with companies that produce technologies that are generally underutilized or otherwise , uh, important to raise awareness of. So things like colorectal cancer screening, certain types of vaccines , um, you know, even , uh, using the expertise of particular life science companies and developing tools that can better diagnose, you know, rare and underdiagnosed , uh, medical conditions. Uh, obviously there's always gonna be risk, but it seems like those are kind of the , uh, cross section of areas where this tool can be super , um, powerful. Uh , I was kinda curious, given your practice, Gail, if you've seen any , uh, sort of traditional life sciences companies getting involved in the space? And if so, you know, how, and if not, you know, what you might say to a client who came in and, and wanted to either help fund the development of ACDS tool or perhaps create their own , um, module for any HR company to implement?
Speaker 2:Um, I , I , I think it's a broad mix of, you know, established companies and, and startups in the space. I do think there are certainly some companies that have never had an FDA regulated product, so it's a bit of a shock to the system to realize that, you know, they're now , um, playing in a regulated environment. Um, but there's also more traditional companies or traditional medical device companies that , um, that see this as a huge opportunity to , um, go in a new direction or to , um, enhance the, the products they already are offering to, to patients , um, or to, well, to for, for using and patients. Um, not sure if that , uh, answers your, your question.
Speaker 3:Yeah. You know, I, I I think it is really , um, try , you know, what I'm, I'm trying to focus on here is really sort of the go-to market for these types of devices, right? I mean, you're going into a , a pretty competitive area, you know, given the number of EHR companies and the number of sort of , uh, companies that are building their business around developing better EHR tools and , um, you know, given the potentially , uh, high value that these tools could have to the life sciences industry , um, it's just , uh, you know, it , it is of interest to me to just know , um, or hear , you know, how some of those companies are thinking about these tools. I just didn't know if you had any, you know, thoughts about that.
Speaker 2:Yeah, I, I mean, I think it's, you know , just a very diverse space because , um, there are just so many different types of, of data that you can apply , um, AI to , uh, so many different clinical contexts. Um, I don't , this, this may be sort of useful , uh, a useful data point. If you look at the distribution of types of , um, AI devices that , um, FDA has that have gone through FDA , you'll see that the vast majority, about 75% are in the radiology space. So, you know, and, and maybe that's not surprising , um, because there , one thing that, that computers can do much, much better than humans is , is recognize patterns in, in images. So , um, many of the applications have been geared around trying to use the software to see better than , um, you know, one, one pair of human eyes can see. Uh, so, so that's really, I think, far ahead , um, uh, radiology from other potential applications of , um, AI-based software.
Speaker 3:How , uh, in your experience , um, you know, we've talked a lot about, you know, the use of data and , and, and whatnot, but you know, one of the challenges I know some of my customers in , or some of my , uh, clients in this area face is sort of validation of data, ensuring that the data you're getting from the providers is, you know , uh, is, you know , accurate, is , um, appropriately , um, transferred in a way that can be used to, you know, drive the engine. Um, have you had any clients deal with challenges around that type of val data validation issue?
Speaker 2:Definitely , um, and, you know, I'm a <laugh> , I'm just a lawyer. Um , but luckily I work with some, some great , um, regulatory folks with , with science background who really can get in the weeds of, of helping clients , um, understand validation requirements. Um, and, and I think that's also an area where, where I think more guidance from FDA would be helpful is , um, articulating , uh, what exactly one needs to do to make sure that the software is appropriately val validated. So, you know, the, the data that you get out of it , uh, is, is reliable and, and , um, useful.
Speaker 3:Um, and then I guess finally on, on the provider side , um, you know, obviously the, the biggest concern in my experience on the FDA side comes from the developer of the product. But, you know, there can also be some risk in , uh, implementing what might be perceived as a , you know , uh, an adulterated , um, medical device or an unapproved medical device on the part of the provider as well. You know, what are some of the key things that , um, providers who are thinking of, you know, signing up and implementing one of these tools should think about
Speaker 2:Understanding from people who work , um, you know, in health systems is they're getting solicitations every day from companies that say, Hey, we can , um, take these data from your, your EHR and, and give you insight into, you know, which patients are at risk of something or which ones you should , um, you should prioritize. And, and it really is unclear , um, to the, the folks in charge of making these acquisition decisions how to, how to sort out which , uh, which product. Um, and, and I'm not sure I have , um, a great answer. Um, certainly it always pays to ask the question of, you know, what , what is the FDA status of , um, of a company's product? Um, they may say it's not subject to FDA regulation , um, and they should have a be able to articulate why that is. Um, so it sounds like, you know, a credible explanation if it's not subject to F regulation, then , um, I think there are other , um, you know, indicia of quality that, that you can request or, or , um, if, if not, I think it would be helpful to have sort of more third party , um, imp perimeters that , um, can tell, you know, quote good software from bad software. Um, if it is the type of software that FDA should be regulating and the company does not have , um, has not gone through FDA, I think that should certainly be of concern , uh, to a health system. Um, and, and they should , uh, you know , exercise caution.
Speaker 3:Okay . Um, are there any other sort of , uh, high level thoughts that you have about this topic in terms of just finishing out the discussion today?
Speaker 2:You know, I, I think it is , um, potentially has the potential to really transform healthcare . Um, at the same time following up in the question you just asked. Um, it is going to be hard to know , um, in a lot of cases for people who are evaluating these, these products, how to tell whether a product, you know, does it is good, it does what it, it says it's going to do. And so , um, from that perspective, I, you know, I think it's , uh, FDA is an important role to play here. On the other hand, the, the challenge is , is that this is moving also so quickly and the existing pro process by which devices go through FDA , um, is, you know, glacially slow in comparison. Um, which, which makes , uh, you know, progress hard. So, so I don't think we yet have the right balance between , um, ensuring some level of oversight , um, but not slowing down the whole enterprise. Um, so I, you know, I'm hoping that over time , uh, we'll, we will get towards that balance,
Speaker 3:Right? Yeah . Buzzwords like AI and, and things of that nature that , uh, are, are not fully understood by regulators yet. And so it's all kind of new and, and both exciting and also frustrating, I think for those who wanna see these tools develop a bit faster, right?
Speaker 2:Absolutely. And you know, that's, I I would say that's a chronic problem, but I think you really see it emphasized , um, with this technology in particular. Um, and I do think there's a, a , a , a role for third parties to play here in setting standards that , um, you know, voluntary standards, but voluntary doesn't always mean voluntary, particularly if you were to tie, you know, reimbursement to it. Um, because I don't think that this is something that can be overseen solely by, by a federal regulator , um, given I think the, the tsunami of, of , uh, products and , uh, that, that we're going to see develop over time.
Speaker 3:Um , all right . Well, I think that's a good place to leave the conversation . Um , certainly appreciate everyone listening to the podcast today, obviously. Um , Gail and I are , uh, both happy to continue this conversation with any of the listeners who , uh, might be interested in, you know, more details or, or have their own thoughts that they'd like to share. So please do feel free to reach out to either of us , us
Speaker 2:Great. Thanks everybody.
Speaker 1:Thank you for listening. If you enjoy this episode, be sure to subscribe to AHLA speaking of health law wherever you get your podcasts. To learn more about AHLA and the educational resources available to the health law community, visit American health law.org.