With the rapid innovation in digital health such as clinical web and mobile software applications which do not traditionally classify as a “device” due to its lack of custom electromechanics, the Software as a Medical Device guidance (SaMD) was adopted by the FDA along with global regulatory leaders to ensure such software products adopt the same general medical device principles to demonstrate safety, effectivity and performance. The creation of SaMD was heavily influenced by new entrants unfamiliar with medical device regulations and terminology developing a broad spectrum of applications in order to support the new and growing industry.
On August 25th, 2020 Jama Software’s Clay Moore moderated a webinar featuring Beanstock Venture’s CEO, Shawnnah Monterrey, and past and present members of the FDA including John Murray and Bakul Patel.
Watch the full webinar now or read an abbreviated version of the transcript below.
My Software Is a Medical Device (SaMD). Now What?
Isabella Kennedy: As an industry, we are starting to see an influx of software applications being used for clinical support to inform clinical decisions, diagnosis, and treatment. We thought with all the new entrants unfamiliar with medical device regulations, it might be helpful to provide an overview and answer some questions. We’ve put together this amazing team of panelists that come from different organizations with tremendous offerings.
For example, BeanStock Ventures provides Software Online Agile Regulatory training, otherwise known SOAR, QMS, DHF audit and assessments, as well as medical device software development. Software CPR provides expert regulatory and standards compliance advice, FDA negotiations and strategies, and internationally recognized training courses.
We are all, of course, familiar with the FDA that provides numerous guidance documents related to software and specifically, in this case, SaMD. Jama provides software lifecycle management tools to aid in automating the process in facilitating compliance. As a follow-on, we will be sharing helpful resources from each company that might be available with you.
Let’s just have the panel members introduce themselves, starting with Shawnnah Monterrey.
Shawnnah Monterrey: Hi, I’m Shawnnah Monterrey, CEO of BeanStock Ventures.
Clay Moore: This entire category is around the definition and classification that drives regulatory status.
As technology evolves, and software becomes a platform and location independent, it is more important to understand what it does rather than where it resides. How does one determine if their software product is a medical device? Can you describe some elements of an intended use statement?
John Murray: Well, I think that everyone needs to understand that you can describe a device or a product in multiple, multiple ways. You can have engineering description, architectural description, all this stuff. But intended use is kind of special. It’s a special subset of all of that.
The focus of that description or that understanding, you need to focus on the patient and the practitioner. I think that’s the very important thing. I’ve seen lots of descriptions that don’t talk anything about the patient or the clinical use. When you’re addressing intended use, you may get confused by the definition and the regulation.
But you need to start asking yourself basic questions. Some of the questions I’ve come up with are, “So, I’m a doctor. How is this product going to make me or help me practice medicine better? How is this product going to help my patients live better lives?” Those focuses, clinical focused questions are very important to be honest about when you’re addressing that intended use statement.
That’s my first comment on that. Number two is that you have multiple customers here. You have the engineering staff, RAQA, marketing, and clinical staff. My suggestion before you tackle the intended use statement is to take a step back, and write a software product description, and get input from all four of those groups.
You need to balance the wheel and you’ll end up with a document that basically everyone can read, everyone understands. That will become the first step to risk management, the first step to design, the first step to regulatory status. It’s well worth the money and the time to do this correctly. The third caution I have about intended use is it’s never static. You start out today with an intended use and everything is well under control.
You design a great product, you have great customers, everything is fine, but before you know it, it’s being used in a different way. Your marketing team starts selling it in a different way. You need to make sure you keep that dynamic and alignment correctly. You don’t want to be in a situation where your intended use is stated this way, but your marketing intended use is a different way.
There are three things. One is to lean towards the clinical and patient. Write a full software product description. Number three; keep track of the dynamic because every SaMD that I’ve ever seen is always sliding into the future. It never stays the same because once you have it, you go, “I can use it for this now. This is a great opportunity so let’s move on.”
RELATED: Your Guide to Selecting a Medical Device Development Platform
Clay Moore: That’s fantastic. I think we’ll spend some more time later talking about the iterative nature of SaMD products. Bakul, what’s some additional thoughts that you might have around intended uses?
Bakul Patel: Yeah, I think John hit up on most of it. I will just add to the concept of the clinical views and who the user is. From IMDR, and through work that we’ve done in defining and categorizing what Software as a Medical Device should look like and what’s a clear that definition looks like, I think we spend a lot of time talking about that.
Internationally, we thought about two things. What the software is doing. Where it’s going to be used. Who’s going to use it. How it’s going to be used. If you think about what the software is doing in the care, in the practice and then you have the other dimension of the context of sort of where it’s going to be used. Context is a bigger situation.
The term that we use in the IMDR framework is the healthcare situation and condition, which means it considers the disease, the condition of the disease through a varying spectrum of the disease you are trying to target. It’s not everything and anything. You can’t just say heart disease and cover the entire gamut because there are many things that you need to consider.
Even in there, there is a spectrum. Then you have the user who is going to use it in certain areas and certain types. Just working through the logic of where it’s going to be used, who’s going to use, and how it’s expected to be used. It’s sort of honing down on your intentions. I like the point John made about it’s not static. I’m going to give you a non-static version of what John was talking about.
Not just about static, about QMS. Start thinking you want to do this but then you find out your technology can only do this. There’s a difference between where you started and where you ended up. The result and what you want to put out to market should be exactly to what your product is performing. I think when that alignment happens between what the product does versus what you want the product to do is really what the regulatory terms calls intended use.
Clay Moore: Thanks for that additional context there. Shawnnah, what are some other thoughts you might have around intended use? Also, if you could start to peel back a little bit and talk about what if there are gray areas and we’re not sure about whether this really should be classified as SaMD?
Shawnnah Monterrey: Sure. I like to break down the intended use into four pieces. I like to focus on the user, the end user of the clinical product, the clinical utility of the product, the environment in which it’s going to be used, which could vary, and also the demographics of the patient.
Giving you an example, maybe I can walk through a simple example of maybe a heart monitor. A heart monitor, the environment would be, for this particular product, would be home use. The end user for that would actually be the patient. The demographic of the patient let’s say it’s age, I don’t know, 55 and up with heart condition that can be self-monitored.
The clinical utility is to monitor heart arrhythmia. Obviously, you would start there, and you can extrapolate further but I like to divide it in those areas to make sure all aspects of the intended use are covered. In terms of an example, I can give one particular example. I’m not sure if it’s still valid but if you consider Fitbit as traditionally not a medical device.
I think they’re moving towards getting it cleared or they may have cleared a version of it as a medical device in recent times. There was a lot of clinical applications being built on top of Fitbit. How do you determine if your product is a clinical device at that point if you’re taking data from the Fitbit and displaying it to an end user?
If you’re just taking data that’s being provided from the actual tool itself and you’re just passing it through, reading it basically, and rendering it, showing it on the display, generally, that’s not necessarily considered a clinical device. But if you take that data and you start providing additional analytics on top of it or start making clinical inferences based on that data, that’s the point where start getting into the medical device space.
RELATED: How to Executive a Successful Design Review When Building Medical Devices
Clay Moore: That’s great. What if the software helps the patient to not be in a clinical setting, if it’s used at home? John, maybe you’ve got some comments on the, again, would we think of this as something that’s being classified as SaMD or not?
John Murray: I don’t think that the device, not a device question starts with at home use or in clinic use. I think that’s a secondary question. It may determine the actual classification of the product. The product may be for monitoring blood glucose, take an example. You could have one product that’s for design to be used in a clinic, one for use at home. They may have different risk determinations.
That may make the classification different. It always must start with the specific intended clinical use, in my opinion. Part B would be now what’s the risk of this application? That varies depending upon the patient population, the environment of use, and a bunch of other questions that could come into being. That would be how I would start framing that up as a question.
Clay Moore: That’s great. Bakul, any other commentary on example of things that are SaMD or aren’t SaMD? Maybe some gray areas.
Bakul Patel: Yeah. Recently, in the act or jurisdiction doesn’t extend to things that are not meant for clinical purpose. It must be for caring, mitigation, treatment or preventing a disease. That’s statutory definition.
An activity tracker just measuring how many steps you’re taking per day and helping you stay healthy is not something we would consider as a medical device even from that perspective. Then certainly, I think this is what Shawnnah was talking about, is you take that steps and say because you took X, or you took less or took more steps, it means certain disease, or it means certain condition.
Clay Moore: Great. I think each of you mentioned risk at some point in time during each of your responses. Let’s move into more the things that are related to risk and the amount of effort that’s behind these things. Once a company determines their software product is a medical device, the next step is to determine its risk category.
Risk categories are used to determine the rigor required to ensure that the product is safe, is effective, and it needs to perform its criteria necessary. For SaMD, risk is classified using a framework where one is the lowest risk and four is the highest risk. John, can you discuss why understanding risks is important when developing and maintaining a software to medical device?
John Murray: Well, the fundamental basic idea is you don’t want anything bad to happen to good people. That’s the purpose of all these rules. We want to make sure your product doesn’t hurt anybody in a way that’s preventable. That’s the simple explanation of that. I want to talk a little bit about one of the special elements of SaMD in my opinion.
That is that we have a specific risk category that I often see with many of my clients gets left off. I’m going to call that engineering or environmental risk, which is a little bit different than clinical risk, traditional clinical risk. Because you know you’re using a SaMD, you need to think about all the elements of that platform choice that may have an impact on harming people.
It may have an impact on risk. The beauty of this is that once you set up this model, you can reuse these questions repeatedly with every product. One simple example is what if the Bluetooth connection becomes lost? What kind of impact is that going to have on my patient? What kind of impact is that going to have on my delivery of my intended use?
All the known features of a general-purpose computing platform, wi-fi, Bluetooth, all that kind of stuff, you can ask those questions. The beauty of this is that I know the engineers are asking these questions all the time. Those questions never get translated over to the regulatory side where the risk management thing is set up.
The idea is that you want to do what you can do. Maybe if you lose Bluetooth for five seconds, it’s not a big deal but what if you lose it for an hour or two hours? There’s a huge number of SaMD applications where you can lose that connection for a short period of time. It’s not going to be an impact. Do you need to know when that happens, and do you need to inform the patient when that happens? In some applications, a patient needs to know they’re not connected.
One of the other ones that I thought of and we saw in some recalls was that what if you start your algorithm, and you are resource deprived? You don’t have the right amount of memory.
You don’t have the right amount of algorithm power, computing power. All these questions, I know they get asked all the time by the engineering staff. The engineering staff needs to be accustomed to contributing that information to the design and to the regulatory affairs side so that when you present your case, you’ll say, “Yeah, we covered all the environmental engineering risk and here’s our list here.”
That gets sandwiched together with the clinical risk, which I’m not a doctor so I don’t like to talk about that very much. That’s a hugely important thing, is being honest. Being honest that bad things can happen, but will they have an impact on my clinical application?
Clay Moore: Shawnnah, why don’t we go over to you and would love to get some additional color on that as well as maybe thinking about what are some aspects that influence safety, effectivity, or performance?
Shawnnah Monterrey: When I look at performance, I think about technological performance and analytical performance. From a technical perspective, especially for a SaMD product where it can be hosted in numerous environments, you really want to go back and understand how the operator is going to be using your system and the impact that that environment may have on your product.
I’ll give you an example of something that could impact performance for a hosted cloud application could be the latency of the network. Something you can’t control, so it’s important to really understand the environment in which your product is going to be used and then how that would then influence some of the safety associated with some hazards to be identified.
A top four list can include stuff like no result. What would happen if the network goes down and the end user wasn’t able to receive results? Delayed results as a result of network latency and is there any impact to false positive or false negative as a result? I think network latency may not directly influence a false positive and false negative but results in a no result or a delayed result.
That’s something that you should assess and determine the severity based on, again, the intended use of your product. From another performance perspective would be the analytical side. That’s focused more on the sensitivity and specificity of your product and really, looking at a false positive and false negatives.
That requires, again, an understanding of your demographics. What is that patient population that is needed to be able to truly test your product to show and prove the analytical performance of the system?
Clay Moore: There was a question around the differences and overlap between SaMD when it’s a mobile medical application and software is inside a medical device considering the same software can be leveraged across different user contexts.
Bakul Patel: I think the intended use of a piece of software does not rely specifically on the platform that it’s residing on. I think that’s one thing you have be very clear about.
The software is going to take advantage of the computing resources and the surroundings of that environment is what I call it. I don’t think it matters from that perspective. Whenever somebody makes a choice to put a product out, they intentionally market it or design it for a particular product or platform.
When you choose that, I think you need to make sure that you know all the things that you are going to depend on or not depend on in that platform. It could be a multi-thread application or a multi-thread operating environment, but you may not use multi-thread for all kinds of various reasons.
You may know using multi-threading applications may lead to some issue that may raise conditions and you may want to think about that. When you start using operating systems and you are using instructors and you have multi-course going on today, you are going to have to say that, “Even if I used a simple programming language to be on a certain platform, the platform may use my program separately because you have different threads running.”
Just knowing that will help you start answering some of the questions about what do you have to mitigate? How to reduce the risk to a minimum. How do you consider that? I think cloud services is very similar. I think you have very different challenges. Mobile is the same. Very different challenges and different sort of advantages. You just take those into account.
