[video] Digital Health Innovators: Does your solution qualify as Software as a Medical Device (SaMD)?
If you’re in the Remote Patient Monitoring (RPM) or Remote Therapeutic Monitoring (RTM) space, then you’ll want to understand the criteria and opportunities for qualifying as Software as a Medical Device (SaMD)
I asked our FDA and Life Sciences Practice Lead Tommy Miller to join me for a practical discussion on what SaMD means for RTM and RPM companies.
In this video you’ll discover:
Why devices are vital to RPM and RTM both from a reimbursement perspective and patient compliance perspective;
What kind of software you can use in your RPM and RTM solution and the parameters around it;
Why CMS’s proposed allowance of self-reported data could be a great opportunity for SaMD solutions;
What FDA filing timelines you need to be aware of to meet your business goals;
What use cases we’re seeing already.
(Click here if you don’t see the video above.)
See the lightly edited transcript below.
Transcript with timestamps
Kaitlyn O'Connor (00:05):
Hi everyone. My name is Kaitlyn O'Connor. I a senior counsel and remote patient monitoring practice lead here at Nixon Gwilt. I'm here with my colleague Tommy Miller, who is our life sciences practice lead and our expert in all things FDA. We want to talk just a little bit about software as a medical device and the opportunities that it presents for those of you in the remote patient monitoring and now the impending remote therapeutic monitoring space. If you've been following our firm's content along the way on these topics, you will know how vitally important medical devices are to remote patient monitoring and remote therapeutic monitoring, both from a reimbursement perspective, but also just from the patient perspective, to make sure that the data you're collecting is actually accurate in order for providers to get a full picture of what's actually going on with their patients.
Kaitlyn O'Connor (00:59):
And one of the questions that I always get is what is software as a medical device? What kind of software can I use in my RPM or now RTM solution and what are the parameters around that? So that's what Tommy and I are here to talk about today. If you've been following the introduction of the remote therapeutic monitoring codes, you'll also know that one of the really cool things about these codes as they've been proposed is that CMS is now proposing to allow for self-reported data to be collected and to count toward reimbursement for those services for the remote therapeutic monitoring services. So I also think that is a really exciting opportunity for some cool software as a medical device solutions. And I think that's exactly what Tommy is going to be able to share with us today. So tell me I'll let you introduce yourself in case I missed anything and then let's just dive right in.
Tommy Miller (01:55):
Sure. Thank you, Kaitlyn. Yeah, so I am Tommy Miller. I am the FDA and life science practice lead here at Nixon Gwilt. I work with a lot of our clients on traditional and software as a medical device (SaMD), regulatory and compliance issues and and work through the various different pathways of getting those products cleared and on market. So I've been working with Kaitlyn and Carrie and others in our team since since getting here on RPM issues. And what I see now as a huge opportunity coming out of each remote therapeutic monitoring codes, which have been proposed specifically because, as Kaitlyn mentioned, the opportunities for patient-reported, but also patient-recorded, outcomes, which RPM does not allow in this space of, right now, various different medication adherence or respiratory or musculoskeletal and those sorts of therapeutic spaces.
Tommy Miller (03:01):
We have huge opportunities for virtual physical therapy. We're seeing the use case there, but when it comes down to what softwares and medical devices, we get a lot of clients just asking, Well, is my platform software as a medical device? Does it qualify? How can we, how would we interact with the FDA?" And so we are getting a lot more of those questions. And so again, Kaitlyn, and I thought it would be really good to talk to you about just what software as a medical device is and what we might be able to do to navigate the regulatory requirements for platforms in that area.
Kaitlyn O'Connor (03:34):
And I think as I was thinking through this, before we hopped on to have this conversation, I think there are two major benefits in the RPM and RTM space for software as a medical device in particular. The first is just simplification of your solution. I think that if you can remove hardware or increase the functionality of your software and decrease the amount of different things that the patient has to use or different things the provider has to track, that can be really helpful for keeping patients engaged and making sure they're actually taking the readings they're supposed to take. And then the second is, I think there are expanded opportunities for just the types of data that providers can start to track. I'm sure there are more benefits to this, Tommy, but that's kind of how I'm thinking about the two major benefits that I'm seeing software as a medical device bringing to the RPM and RTM space. So let's kind of talk about that a little bit. How does software as a medical device fit in here? What is it and what are the types of data that might be collected this way?
Tommy Miller (04:35):
Sure. Yeah. So just from a very high level, and this is what I start with every single time, is what is the definition of a device under the FDA's rules and regulations, which is the language that you find in the RPM CPT manual, which is a language that you find proposed for the RTM codes to be able to collect that and get reimbursed under these codes, the platform or apparatus that you're using has to be a device as defined by the FDA. So what is a device that is defined by the FDA? Well, it is an item or apparatus that treats, mitigates, prevents, cures or diagnoses a medical condition and operates on the body by other than chemical means (which would be a drug).
Tommy Miller (05:25):
That is the same definition that's really applied to software as a medical device, except for whereas traditionally a hardware or a physical product might be performing that function, now it is the software that is performing that function. It is an algorithm, it is an analysis, it is a background AI or machine learning that is bringing in data, whether it'/ connected to other hardware or whether it is self-reported/self-recorded inputs from a ,patient and doing something with data and spitting out some sort of an analysis, treatment recommendation,, end point or something to that effect that is intended to, again, meet that larger definition of a medical device. But it just operates independently of a physical piece of hardware and tends to also be platform agnostic. So you can have software as a medical device either as a web portal, or you can have software as a medical device as a mobile medical application. And it can really exist in either one of those two spheres.
Kaitlyn O'Connor (06:33):
Awesome. Yeah, I think, I think that's, I think that's really, really exciting. It sounds to me like this is software that is doing the same thing that hardware is doing, or maybe something different, but in the same vein of, like you said, treating a medical diagnosis or a disease, which is really exciting. This is something that a lot of my clients are asking about. So in the case where we do have a software function, that is software as a medical device meets that FDA definition, what's the next step? Like if a client comes to us and says, here's my software, we look at it and we're like, yep, that's a medical device. Or we've done our analysis and we determined it is a medical device. What do they have to do from there?
Tommy Miller (07:16):
Yeah. So really, as we're making the determination of 'is this device' the big questions that we take a look at, which are really going to, drive that answer are: What claims are you making? What are you saying that your software actually does for a patient or a user? And then, what's the underlying technology behind it and what are the parameters that are being built into your software that are expected to produce those outcomes? And from there, we look at several guidances that exist right now from the FDA. Anda lot of the the work that we do right now is grounded in those guidances because the FDA is still working out concrete rules on really how software as a medical device is going to be regulated.
Tommy Miller (08:08):
And so when I talk about software as a device with clients and we're getting into that area of, is it really a device or is it not? I'm talking to them about things like clinical decision support (CDS). And so there's a guidance out there around that. It's still Draft that FDA promised to Final, but I don't think we're going to get it this year. And then, so they break it down into device CDS or non-device CDS. And there's a whole analysis that we go through in that. There are things called digital therapeutics out there right now, which are actually, there's more and more getting approved. And a lot of those end up going through some sort of a regulatory filing because they are digital therapeutics and software as a medical device that are making certain claims.
Tommy Miller (08:53):
There isn't a predicate because there are so many new ones that have not been evaluated by the FDA before. So if you're going to go down the path of digital therapeutic, you're likely going to be engaging with the FDA on a more substantial basis. And so we need to talk about that path and that strategy. Then there is other software that can get fit into existing product codes. Your software is performing the same function as something that hardware used to do. Like we see a lot of in the PT space right now the use case of cameras measuring range of motion, for example, and there are existing product codes for a device like that. And we can take a look at your product and see what's going on with the technology and see if there's a product code that exists out there in the FDA database that we can fit it into. So really after we determined that you might have a device, we're going to start looking for what regulatory burden are you going to start having to deal with: Is it going to be a filing? Is it going to be a registration. Or is it going to be something a little bit more onerous that you might have to conduct some clinical trials or testing or something like that to get through the FDA?
Kaitlyn O'Connor (10:07):
Yeah. And I know there's a lot of detail and nuance there. We could probably have an entirely different conversation about just those different pathways and regulatory considerations and all of that. But, I think that's what's really exciting about these new software as a medical device opportunities with RPM and RTM is that it's not going to be different than it would be if it was a hardware solution, but you might have to do the work yourself. You're not going to necessarily be able to go somewhere and get a blood pressure cuff. You may develop that technology by yourself. And that means you may have to go through those FDA processes by yourself, but that's actually potentially a competitive advantage as well. If you're the first person to do that or the first one to develop that technology.
Kaitlyn O'Connor (10:57):
But I also think that's where the simplification and the expanded opportunities come in. Because for simplifying your solution, if you're using software as a medical device to simplify your solution, you're probably in that space where there's already a device out there that's doing this, but you're now doing it in a simpler way through software. So rather than the patient having to have a blood pressure cuff and a software app, now they've just got the software app on their phone. But in those expanded opportunity spaces where we're talking about new types of data, maybe now you've got to do a new filing or 510K clearance. (I'm not the FDA expert here, that's you.) But so, I think that might be where those pathways start to differ is, are you doing something that's already happening, but making it simpler, or are you doing something brand new, like analyzing pain levels or finding a new way to collect mood and analyze behavioral health data, things like that that we don't have hardware for yet. That's where you might have to get into that new space of doing a new filing or going through the full clearance process.
Kaitlyn O'Connor (12:01):
Am I thinking about that right?
Tommy Miller (12:04):
Absolutely. And really what I want to highlight there, because of the innovation around some of these data points and the software as a medical device aspect of this, it's really vitally important that you start engaging in that regulatory conversation very early so that we can first establish what the appropriate pathway is going to be long before you are up against some sort of a financial crunch to start making revenues. Because we work with clients in this position too when we try to warp speed it, but if we can get to you early and we can start having these conversations start engaging with the FDA and really solidify that regulatory pathway that's going to align with your reimbursement pathway, we can start the wheels in motion and getting you squared with the FDA.
Tommy Miller (13:04):
If you come to us and say, "we want to start RTM January 1" and we don't even know if we have a device yet, and you tell us that we need some sort of a regulatory filing—we already know that we're going to miss that January 1 deadline, because these filings take six to nine months just for review. And in the meantime you have to prepare the applications and gather the data and all that stuff. And so it takes planning and so early engagement is always best.
Kaitlyn O'Connor (13:37):
Yeah. And I see that a lot with my RPM and RTM clients, as well, even outside of just the FDA context, but at a base level for remote monitoring services, you have to have a medical device. That is a requirement from CMS. They're not going to budge on that. It has to be a medical device. And so that should be one of the first questions that you're asking yourself, is this a medical device? Even if you're getting hardware devices from a manufacturer, make sure that your manufacturer is in compliance with FDA regulations and make sure that it actually is considered a medical device. Because as we talked about before, there are lots of different ways that something can be a medical device, but there are also lots of different ways that you may not fall in that definition.
Kaitlyn O'Connor (14:28):
And that's really important too. So I think this has been a great conversation. We could probably continue for another hour about all of this, about all of the different pathways here, but I think this has been really, really great. I'm excited to learn more from you, Tommy, about software as a medical device and bring that to a lot of my clients. So thank you for sitting down and having this conversation me. And If you're watching stay tuned, because maybe we will get into other parts of this and have deeper conversations later.
Tommy Miller (14:59):
Yeah, absolutely. Thank you, Kaitlyn. I know that you're doing great work to bring these reimbursement models to to broader adoption and use as we push forward in the innovative space that these reimbursement models really open up for the life science and FD-A regulated products kind of communities. So yeah, I agree, great conversation. Definitely more to come from the Nixon Gwilt team on this. So yeah, we'll keep everyone posted.
Kaitlyn O'Connor (15:28):
Yeah, I think we will be working together a lot in the coming months. All right. Thanks Tommy.
More Resources for Digital Health Innovators
Need more info about the MPFS Proposed 2022 Rule for RPM and RTM? We’ve got you covered.
And if you’re ready to talk about the opportunities for SaMD, RPM, or RTM for your business, we’re here to help.