Digitizing your SaMD Testing

What is software as a medical device (SaMD)? How does one test SaMD? What testing is required? What are the risks related to your SaMD and its testing? 

In this episode of the Global Medical Device Podcast, Etienne Nichols talks to Rahul Kallampunathil, Vice President of Arbour Group’s Digital Compliance practice, about digitizing your SaMD testing.

Rahul builds teams that help companies proactively manage compliance risks toward a true digital enterprise. He is an innovative thinker with more than 18 years of experience in risk management, compliance, and internal controls focused on information technology and data.

Listen now:

Like this episode? Subscribe today on iTunes or Spotify.

Some highlights of this episode include:

• Rahul defines SaMD as software used to perform a medical purpose without being part of a hardware medical device. SaMD is capable of running on any general purpose platform, such as your Android or iOS mobile phone.

• SaMD is different from software in a medical device (SiMD). SaMD is independent from hardware; SiMD is embedded in a physical medical device.

• Also, there’s differences between SaMD and medical device data systems (MDDS). MDDS only transfers, stores, or displays medical device data, but it does not have an algorithm or business rule to help make medical decisions.

• IEC 62304 impacts SaMD organizations and how they approach the risk of their solution. All SaMDs are not equal, and it’s important to understand the level of risk in every SaMD.

• Companies should prepare for SaMD testing with a clinical evaluation to demonstrate a valid clinical association between SaMD’s output and targeted clinical condition.

• Before thinking about designing and developing a product, a quality management system (QMS) should be established. Software companies need to adopt and modify their QMS to serve their product and its users, while fulfilling FDA requirements.

• Rahul discusses the pros and cons of manual versus automated/electronic  documentation and testing, including risk management for patient safety.

• Best practices for SaMD testing are using agile and devops methodologies. Potential pitfalls are not testing continuously, even after the product is on the market.

Links:

Rahul Kallampunathil on LinkedIn

Etienne Nichols on LinkedIn

Arbour Group LLC

FDA - SaMD

FDA - Medical Device Data Systems (MDDS)

FDA - Cybersecurity

IEC 62304

International Medical Device Regulators Forum (IMDRF)

Greenlight Guru YouTube Channel

Greenlight Guru Community

Greenlight Guru Academy

MedTech Nation

Greenlight Guru

Memorable quotes from Rahul Kallampunathil:

“Software as a medical device - it is software that is intended to be used for a medical purpose, and it performs that purpose without being part of a hardware medical device.”

“There is no physical device, in this case, that you can touch and feel. It’s purely software.”

“The nature of software - it’s something that you cannot touch or see. It’s all code. From a testing perspective, especially, there’s a lot of things that you need to pay attention to.”

 “The quality management system or quality management process, that has to be established even before you think about the product, even before you design the product.”

Transcript

Announcer: Welcome to the Global Medical Device Podcast, where today's brightest minds in the medical device industry go to get their most useful and actionable insider knowledge, direct from some of the world's leading medical device experts and companies.

Etienne Nichols: Hey, everyone. Welcome back. Today, we're going to be talking with Rahul Kallampunathil from the Arbour Group. And I hope he will forgive me if I've mispronounced his last name. But we're going to be talking about digitizing your Software- as- a- Medical- Device testing. Rahul is vice president in Arbour Group's digital risk practice, where he builds teams that help companies proactively manage their regulatory and compliance risks as they embark or continue on their journey toward a true digital enterprise. We go through a lot of different details regarding how to test, what a Software medical device is, what potential testing could be required. So it's a very good episode as far as the overview and the risk related to your Software-as-a-Medical- Device and its testing. Definitely recommend you check this out. Let us know if you have any feedback or comments at podcast @ greenlight. guru. Thanks. Hey, good to be back. Hey, Rahul. How are you doing today?

Rahul Kallampunathil: I'm doing great, Etienne. How are you?

Etienne Nichols: Doing well. So just wanted to talk to you today a little bit about Software-as- a- Medical- Device. We have a lot of different things to cover. Before we just jump straight into maybe the specific things, I wondered if you maybe wanted to give a quick overview of Software- as- a- Medical- Device. And the reason I asked that is I recently heard, assume zero knowledge and infinite intelligence, and I thought that might be a good way to start some podcasts. What are your thoughts on Software-as-a- Medical- Device?

Rahul Kallampunathil: Yeah, I think it's very important to really talk about what it is at the outset, because a lot of people get confused with it. You know, there is Software- as- a- Medical- Device, Software- in- Medical- Devices, there is MDDS and mobile apps. So a lot of different things going on. So let me start off with what exactly is the Software-as-a- Medical- Device. So Software-as- a- Medical- Device is any software that is intended to be used for a medical purpose and it performs that purpose without being part of a hardware medical device. So the way it is different from traditional medical device is that it's capable of running on any general purpose platform. And typically, it works on many different platforms. So for example, it could work on your mobile phone, your smartphone, it could work on an Android platform or an iOS platform. So that is where it's different, because there is no physical device, in this case, that you can touch and feel. It's purely software. It might be connected to a physical device, but it's not needed for that device to function. SaMD, as we call it, Software-as-a- Medical- Device, may be used in combination with the physical medical device, it could be used with other SaMD devices, or it could also be interfaced with a general purpose software.

Etienne Nichols: What's the difference in SaMD and SiMD, Software- as- a- Medical- Device and Software- in-a-Medical-Device.

Rahul Kallampunathil: Software-as-a-Medical-Device is the one that is kind of independent of the hardware. Software- in- a- Medical- Device, it's embedded in that medical device.

Etienne Nichols: Okay. Oh, go ahead. Sorry.

Rahul Kallampunathil: Oh, sorry. No, I was going to say that if a physical medical device needs some software for it to function, that wouldn't fall under SaMD.

Etienne Nichols: Okay. Is there ever a gray area between the two where maybe as you're going to submit that device to the regulatory agencies where you're like, is it a Software- as- a- Medical- Device or software in a medical? Are there any gray areas?

Rahul Kallampunathil: Yeah, I would say the one biggest gray area that I've seen in practice, having worked with this in the last few years, is between SaMD and sometimes MDDS. And MDDS, again, a lot of acronyms are going to be used today. MDDS is medical device data system. So essentially what MDDS does is that it can transfer data. It can store data, or it can display medical device data, or medical imaging data, but it doesn't do anything that helps with the decision making. What I mean is that, it doesn't have an algorithm or any business rule that converts the data it is getting into some other output. It just transfers data from point A to point B, or it just stores data. So lot of the gray area usually is between MDDS and SaMD. SaMD helps with various medical decisions by practitioners. I'll give you just a quick few actual examples that may help, and I'll try to make the distinction between MDDS and SaMD clear with that example. So there are a lot of remote monitoring devices that we use these days, right? Even when the pandemic hit us, the hospitals were getting overwhelmed. A lot of healthcare providers, they started going with this remote monitoring model, where they could treat the patients at their homes, especially the ones that are not super critical, by having them wear various devices that monitor their vitals. So for example, a pulse oximeter. But pulse oximeters won't be able to transmit the readings, especially if it goes below a certain threshold, to the healthcare provider, who's physically at a very distant place. So in that case, there's software device software that actually takes the input from those medical devices, and the software is usually on the smartphone. So when the patient is wearing a pulse oximeter, the pulse oximeter sends a reading to the smartphone, which is placed in proximity to that patient. And that smartphone, in turn, transmits that information to a cloud- based centralized location, where the doctor can see the vital parameters of that patient. So if that software is just sending the reading from the pulse oximeter, which is attached on the patient's body, to the doctor's dashboard, then it would be just an MDDS, because it's not doing anything with that data. If it shows the oxygen concentration is 90, it would just show that it is 90 on the doctor's dashboard.

Etienne Nichols: Okay.

Rahul Kallampunathil: So that is MDDS. So if the same software will have some thresholds and alert the doctor, so say the doctor sets up a threshold, like if it's below 92, I need to get a notification right away, because then you need to more actively monitor the patient. So in that case, if the software has that algorithm built into it, or the rule where it takes the reading, it analyzes the reading, and then does some action based on it, in this case, generating an alarm. In that case, it's a Software- as- a- Medical- Device.

Etienne Nichols: Wow. Okay. Interesting. So it really seems to boil down to indication for use, maybe a few other pieces of criteria.

Rahul Kallampunathil: Yes. Yes.

Etienne Nichols: One thing I'd ask about that then, do you see, or have companies, when they look at this, the possibility is just stay in the MDDS realm versus taking that leap into Software- as- a- Medical- Device. That one feature would alert the doctor, it seems like it'd be a powerful feature to have, even if it's an MDDS. Maybe we're getting into the conversation, what is the difference in MDDS and Software-as-a- Medical- Device as it relates to the actual regulatory submission or the actual development? Can you speak to that?

Rahul Kallampunathil: Yeah, sure. That's a very good question, actually. So the MDDS, FDS, earlier they had a different guidance on this, but now the latest guidance says that all MDDS is considered class one. So you don't have to really go through that pathway for MDDS. But if it's a SaMD, you still have to go through the regulatory pathway to bring it to the market.

Etienne Nichols: Okay. And so, if companies are looking at this different pathways, have you gone through that process or had that conversation where adding that feature that will bring it up to a SaMD or a class two level, is that something that maybe they would say," Well, we don't really want to pursue that," or is that even a determining factor? Does that play into people's decisions in the development process? Or have you seen that?

Rahul Kallampunathil: Yeah. So let me also clarify that the regulators themselves, it takes some time to get used to this because the guidance is there. But when you go on a case by case basis, sometimes it's really hard to determine which category it falls under. And that alert or alarm function, that was just one example. There could be other things like that, where the software is helping make some kind of decision by adding something more than what it received as an input. So, for example, if you're getting a lot of images, if the software tries to read that image and, say, identify potential health conditions from that image, that also puts it under the SaMD category. So as far as the manufacturers are concerned, I mean, MDDS category is much easier to bring to the market. But if your product is sophisticated and it's really meant for a specific purpose, I mean, it makes sense to go through this route, because otherwise you are not really, when you do the internet use, you really have to say that it's. I mean, it may have more capacity than what you're claiming to be.

Etienne Nichols: Sure. That makes sense. Well, so the standards in place that I think of our IEC 62304, how do those impact SaMD organizations? And how have organizations been implementing those that you've seen?

Rahul Kallampunathil: Yeah. So as far as the regulatory landscape is concerned for SaMD, there's an organization called International Medical Device Regulators Forum, IMDRF. It's a voluntary group of medical device regulators from across the world. FDS is a very active member of that forum. And they issue the guidance for Software-as- a- Medical- Device. So in essence, they try to define what is SaMD. Then they try to, how do you approach the SaMD? So they try to categorize the SaMD. Again, all the SaMDs are not equal. You could have two, three or different categories, depending on the criticality and whether it's treating a serious or non- serious condition. So it could have those different levels. So that categorization is there. And then when you approach the SaMD itself, the IMDRF, they do refer to that IEC 62304 for a software design and this system development life cycle. One thing different from traditional medical device for SaMD as far as IEC 62304 is concerned. For a traditional medical device, usually, you go through that life cycle, and then it's pretty steady state after that. Once you design and develop and manufacture the product, it's not very often that you change the product. For Software- as- a- Medical- Device, just by nature, there are so many frequent changes, there are new upgrades, there are releases and so on. So your life cycle has to be, instead of SDLC, system development life cycle, they use the term TPLC, which is the total product life cycle. Because the life cycle, it doesn't end with the marketing of the product, even after it goes to the market, you need to monitor and collect trail world data. And also, you have to push upgrades or the new versions to the customers. You have to test it before you push it out. So all that is there. So it's quite different in that way.

Etienne Nichols: I totally agree. The changes are much more rapid in software. And there are different challenges with that as far as change management. We don't necessarily have to go into that, necessarily. But the testing itself, one thing I might ask is, how does a company prepare for the software as a medical device testing? And maybe if I took a step back, you have software companies that are pure software, and then you have medical devices that are pure medical. And then it seems that we're seeing a lot more software developers come into the medical device world to develop software as a medical device. And the amount of verification validation, I don't know if it's the same or if it's more rigorous, I would expect it to be more rigorous. But how do companies prepare for the level of rigor that a SaMD would require?

Rahul Kallampunathil: Yeah. So that's like, again, an excellent question. So I would say, it's not necessarily more or less. I wouldn't put it that way. I would put it more like, it's really different, what you do here, because the one thing that it makes it easier, I would say, is takes out a lot of those physical aspects out of the equation. So you don't have a machine, you don't have to calibrate it, all those things are not there. But on the other hand, just the nature of software, it's something that you cannot touch or see, it's all code. So from a testing perspective, especially, there's a lot of things that you need to pay attention to. One is, that's a whole clinical evaluation that needs to be made. And basically, there should be a valid clinical association between your SaMD's output and the targeted clinical condition. You need to be able to demonstrate that relationship is there. So step one is through testing it to make sure that the SaMD correctly processes the input data and provides the accurate and precise output. That is step one of testing. The step two is really to show that output that you got, that meets the intended purpose for your targeted population in that clinical context.

Etienne Nichols: Okay. And when they're setting that up, I guess it just depends on the standard of care at the time that they're using to evaluate it against, whether it's a doctor's determination of, I don't know, imaging versus the algorithm's determination from those same images. Is that part of what that clinical validation is evaluating?

Rahul Kallampunathil: Yeah. That's definitely one way to do that. But I would take a step back. So if you look at the background. First of all, the quality management system or quality management process, that has to be established even before you think about the product, even before you design the product. So that should take into account all the things that are different for a SaMD. And you actually used two good examples. One is, software companies that are bringing SaMD products to the market. And the other one is the traditional medical device manufacturers bringing SaMD. So the traditional manufacturers, they usually already have a quality management system. It just needs to be adopted and slightly changed to accommodate all the things that the SaMD needs. But when it comes to the software companies, a lot of them, they don't have a quality management system that stands up to the FDA requirements. I mean, they may have something from a good IT practice standpoint, but not from an FDA, life sciences standpoint.

Etienne Nichols: Yeah. Let me ask you something about, I don't want to cut you off. There's something you asked about, or you said with the QMS. They may have an established QMS. It just needs to be adopted and maybe slightly changed. What are those slight changes, in your mind, that might be required in a typical medical device company that's starting to develop software?

Rahul Kallampunathil: The traditional medical devices, it goes through, I would say, a very regimented process where you have a design file, you kind of know things ahead of time you want to do in certain ways, and then you go and build it, then you test it, and then you take it to the regulatory pathway. And then you launch the product. When it comes to SaMD, just because you're not physically building anything. It's coding. So the way the coding works in 2022, it's a very agile environment, right? It's not like where you kind of go into it without knowing a lot of things. And your testing has to be kind of a dynamic along with the design and development. So what it means is that you could possibly use some kind of methodologies like agile or DevOps, which are more suited to these kind of rapid development and then continuous change kind of situations. So that is one aspect. So having that, the QMS should be able to support a quick turnover. I mean, it should not become the bottleneck like it usually becomes. That is one key aspect of SaMD when it comes to QMS.

Etienne Nichols: There's a few things that I've had traditional companies ask me about. And one is, is the SaMD required to have a DMR, for example or like a UDI? And how do those things tie in? That's almost worth, at some point, someday, putting kind of a category next to each other and linking the two. One is traditional, one is Software-as- a- Medical- Device, and just saying," Hey, this is two Software-as- a- Medical- Device, et cetera." But can you comment on that? Do you have any specifics?

Rahul Kallampunathil: Yeah, sure. So that, again, is a good question because that's one area that people kind of get stumped. Without using the exact words for that, when it comes to software, your design, you could have all these kind of technical specifications, functional specifications, user requirements. Those are really your DHR and all those kind of files. Again, when I refer back to that IMDRF framework, that method should be defined in your life cycle process, and that should be documented. So you need to keep the documentation of all the designs that you're doing for the software, and works from a technical perspective and a functional perspective, and any additions that are made. And in this SaMD world, there are quite a few changes that happen frequently. So all that should be retained. And that is where digitalizing all these files becomes very handy. Because if you look at any of these systems that support agile, I mean, there are a lot of tools out there in the market, it becomes very easy to do that. I mean, you have your user stories and then directly, you can have your test cases, they all correlate. So all that goes into your file. I mean, that's what you would.

Etienne Nichols: Okay. And I definitely agree. I'd much rather see things on the computer as far as being able to tie them to each other and link things versus having them on paper. And of course, that's something Greenlight Group, that's the reason we're in existence, but even more so if you're a software developer. One other question, just wanted to run this by you. If we look at the design controls process itself, and if we move from the traditional manufacturer who's developing software and go to the other spectrum, the software developer who is now moving into the medical device space, they may be scratching their heads about this design controls process. What are user needs? What are design inputs, design outputs? And the thing that I've seen this sort of correlated with is, user needs to a software developer, that kind of correlates to the epics. And then design inputs are kind of like those user stories and design outputs, the actual lines of code. Would you agree with that? Or do you have any refinement to put there?

Rahul Kallampunathil: I think I broadly agree with that. I mean, there's going to be some nuances of that. But yeah, I mean, you start at the epic, and you have your user stories. So when it comes to this SaMD, initially you kind of know what the product is going to do. It's just the many things that you need to achieve the final output. So you capture all this as your user stories, all the details. And then actually this is one area where a lot of automated testing is actually encouraged because SaMD's actually a good candidate for that because of the nature of the product.

Etienne Nichols: Maybe we could just go straight into that. I'm curious what your thoughts are as far as manual versus automated testing. How would a company go about setting that up or evaluating, this is a good candidate?

Rahul Kallampunathil: I think as far as automated versus manual is concerned, I'll come to the SaMD, but I think it's a much bigger conversation happening in the industry because the regulators themselves are pushing towards CSA, which is computer software assurance instead of computer software validation, CSV. And automated testing is a big part of it. I mean, the other big piece is the risk based approach. So FDA itself is encouraging moving away from the documentation intensive traditional approach and moving more towards the risk based approach where you do more testing for the items that have more risk and also use automated testing for that. So that's the larger context. And when you put SaMD there, the one thing that you can really achieve by automated testing is that the extent of the testing or the test coverage that can be really enhanced by doing automated testing. Because if you do manual testing, you usually use test data and one example of each scenario. With automated testing, you can literally run hundreds of scenarios within the same time and with the same kind of effort. And you could use your testing resources, your human resources towards the more high risk areas where manual intervention is required. You could do it that way. And then there are some challenges too. I would say that one thing that's new with SaMD is that it works across multiple platforms. So it works on Android, iOS, on Microsoft. So your automated testing tool also has to be adapted to all these different platforms. And the other thing is, the platforms themselves change. I don't know if you use Android or an iPhone.

Etienne Nichols: I'm embarrassed to say, because invariably, somebody's going to put. I use an iPhone.

Rahul Kallampunathil: Yeah. So you can see how frequently they push notifications. And because it's all internet based, it's kind of hard to keep track of it. At a personal level, it's okay if you miss a notification, no big deal. But when you're doing a product that is going to impact patient safety, all these things become challenging. So it's just very important to stay ahead of that and make sure that the automated testing takes care of all the scenarios that your product is capable of working on.

Etienne Nichols: That makes total sense. You mentioned a phrase there that I don't think I'm familiar with. I wonder if you can maybe educate me. So, CSA versus CSV, computer software assurance, am I getting the acronym right?

Rahul Kallampunathil: Right.

Etienne Nichols: What are the differences in those two?

Rahul Kallampunathil: I think I kept my promise of using a lot of acronyms today.

Etienne Nichols: You're doing great. You're doing great.

Rahul Kallampunathil: Traditionally, and I think the initial regulation came sometime in 1992, if I'm not mistaken, that's when we went from paper based forms to actually electronic records and 21 CFR part 11. So CSV is kind of dated in the sense that it came out at that time. And we have been using it still, almost 30 years.

Etienne Nichols: Yeah. Okay.

Rahul Kallampunathil: So the traditional approach, it's very documentation intensive, for one. You test everything, you keep a record, you sign and date everything. I mean, it started, as everything, with good intentions, but it became very, I would say, kind of clerical over a certain period of time. And we just have lots and lots of paperwork. And when I say paperwork, even digital, and testing, without actually looking really at the risk of different products. Say you have a software that is actually monitoring a patient's, say, their heartbeat or something like that, which is used in a highly critical hospital kind of situation. And then you have a software that is managing consent, which is before you'd go for a procedure, you need to get the patients signed and date and all that.

Etienne Nichols: Okay.

Rahul Kallampunathil: So if you look at these two software, the one that is for the consent management, it is important to get and record the consent, but it's not directly impacting the patient safety. It's informational. And they can make informed decisions and give the consent. But the other software that actually monitors the patient's physical condition or the heartbeat, that is a much higher risk, because anything wrong with that software literally puts the patient at risk. So the reason I gave that example is because, in the CSV approach, we don't really look at the risk before doing that validation. It kind of follows a one size fits all kind of approach, in many ways. I mean, the example that I used is actually quite dramatic. I mean, there's no comparison between those two software, but sometimes there are different pieces of software. Some are like high risk, medium risk, low risk, and then you have to tailor your testing and validation depending on the press. So the CSA approach, which is the computer software assurance, it just takes a more risk based approach, and the intention being to make sure that the software is meeting the intended use, but you really focus on the areas that are higher risk and you could also use more automated testing.

Etienne Nichols: Okay. So that's really what it boils down to, is the level of focus on the area that is affected the most by risk.

Rahul Kallampunathil: Exactly. Exactly.

Etienne Nichols: Okay. No, that makes sense. Thank you for explaining that. That makes a lot of sense. So when does CSA, is that a relatively new initiative?

Rahul Kallampunathil: Yeah, I think in the industry it has been going around for a few years, I would say three, four years. But nothing has been promulgated yet. I think there'll be some guidance which is expected, but that has been the informal push towards CSA.

Etienne Nichols: Okay. So in your experiences, knowing the different types of validation, what are some best practices that you've seen. And maybe, I always learned from the pitfalls as well. So I don't know, whichever direction you want to go, the positive or the negative. But best practices for companies setting up their test procedures or versus maybe some common pitfalls that they should be avoiding.

Rahul Kallampunathil: So I'll start off with the best practices. I think we mentioned this a little earlier. As far as SaMD is concerned, it's best to use a methodology that is more suited for software, and especially in a changing environment, so methodologies like agile and DevOps, they help manage these projects better. Automated testing definitely helps because it helps increase your depth of testing, increase the number of scenarios. And you really don't need to do a sample based approach, you could kind of test the entire population. So for example, if you're using a SaMD which is an imaging software that kind of reads from different images and then comes to certain conclusions, you could feed it with thousands of images when you're doing an automated test. Whereas if you're doing a manual test, I mean, it's very hard for one person to go through multiple images. Typically, what people do is they use one case, which is a positive scenario, a few cases, one case that is negative scenario, and then they're done with testing. But when you use automated testing, it's much more robust and it's much more convincing because you use much bigger population.

Etienne Nichols: That makes total sense. You've got me convinced on automation a hundred percent. But I want to ask you though about the agile approach, you mentioned that it's a little bit better to use the agile approach, and that makes sense. That's what the software industry is sort of used to anyway. But I'm curious if you could get a little bit more specific, what is it about the agile approach that could potentially develop a better, safer, more effective medical device?

Rahul Kallampunathil: I think the biggest difference is that the testing is kind of embedded into the process. It doesn't have to wait for different stages to be complete. So your testing team is involved through the development process instead of, if you use a more traditional, like waterfall approach, you first do all the design, you start building it and then you go and test it. So just based on the nature of SaMD, if you're coding for certain software, it's better if your testing team, or really your quality management team is involved in the process. You kind of reduce the time it takes to come out with the final product.

Etienne Nichols: You know, part of the reason I asked, I don't mean to lead the witness, necessarily. But I love that you kind of contrast it with the waterfall approach. And while some physical devices, in a lot of development, you can't necessarily adopt an agile approach with a physical device, but if we kind of like zoom out and look industry wide, some of these agile approaches could benefit the development of physical devices as well. Now, it may wind up having to be an agile approach, but do you have any thoughts on that? I know we're on Software-as-a- Medical- Device, but I don't want to get you out of your realm, necessarily.

Rahul Kallampunathil: Yeah, usually I'm not very well versed in actually testing the physical devices. My area of work, it's mostly software related. Even for physical medical devices, we support testing the software that is used as part of it or used as an interface. But I think just taking a common sense approach, I think it's kind of very hard to fit a physical device into that model because you cannot really test it till it gets to a certain stage, whereas software is different. If you have one unit completed, you could test just that unit.

Etienne Nichols: That is true. And I definitely agree with you on that. However, I don't know. There seems to be an approach in the industry, at least I run into sometimes, where verification is treated as an event, a moment in time, versus a series of tests that could potentially be done on features. Granted, need to be done on the to be marketed device at some point, but still just a series of testing. But maybe that's a conversation for a different day.

Rahul Kallampunathil: Yeah, definitely.

Etienne Nichols: But any other thoughts on the best practices or common pitfalls? I kind of cut you off a little bit. You were talking about the approach and then the automation. Any other tips?

Rahul Kallampunathil: Yeah. Those two points were more related to the quality side of it. Another important aspect to remember is that it doesn't end. Testing is kind of continuous in this approach, even after the product is on the market, because you are pushing version upgrades, sometimes it's the platforms that are pushing it. So if your SaMD product is on Android, and Android comes up with a new version, at a minimum, you have to make sure that your product still works on that new platform or new version of that platform. That's the minimum. Or you could, if you want to use some of the new features and extended capabilities of the new version, you could also enhance your product. And then in that case, you will need to do some additional testing. So that is one thing. And then very important thing to keep note is that it's kind of important to keep track of all the people that are using the product, whether they're customers or not. Because when you have these new versions, it might need to be pushed out to the people who are already using them. So for a Software- as-a- Medical- Device, post market activities are also equally important.

Etienne Nichols: One question about that. And we're sort of coming at this from different worlds. You're software. I'm not as much, I'm more of a physical device guy. But I do know, when you have a software that has to be, like you said, enhanced perhaps for a new version, those enhancements, if there's not backwards compatibility, and you have to wind up maintaining two versions. For example, maybe you have, as you mentioned, your user base, some section or segment of that user population is going to stay with an older version, for whatever reason, of that Android or whatever device they have. You still have to maintain that compatibility. Is that accurate or are there any things, from a regulatory or a quality standpoint, that need to be considered when making those changes?

Rahul Kallampunathil: Yeah, again, a really good question. Because that's, again, some of the practical challenges that are there. So it could go two ways. One, if you're bringing in a new functionality, there are going to be customers who say that I don't want that functionality. So maintaining that existing functionality, existing version is important. But there may be cases where it may not work anymore. Maybe there's a technical reason. So that is why this communication is very important, even post market, you need to know and publish it. The IMDRF framework also talks about decommissioning. You have to provide a way for your existing customers to know that they need to decommission the product if it's kind of end life, for lack of a better term. Because when it's a physical device, it's that much easier because you know where it's located or you could find out where it is located. And there is only so many of them. I mean, these Software- as- a- Medical-Device, you could literally download it on your laptop, right? So just keeping track of how many customers are using it becomes a challenge. And that's where one of the biggest differences is, because it's a software. I mean, making copies of it is not a big deal. Whereas if it's a hardware device, you have to manufacture it. You cannot make a copy of it.

Etienne Nichols: Right. That makes sense. There are unique, or at least there seem to be unique challenges with Software-as-a- Medical- Device. Some things I think could potentially be covered under physical device regulations, but there's definitely some things that are unique for sure. When I think about even labeling, like the UDI and changing those iterations, but still having a device on the market that is previous version and having a new UDI, the labeling itself, something as simple as that, at least in my mind, it seems like it would be a challenge as well. I don't know if you want to comment on that. It's okay if you don't.

Rahul Kallampunathil: No, that is definitely one area. And even for your IFUs, instructions for use, you also need to mention in that that this product is likely to change. I mean, if you don't know your exact release schedule, you don't have to provide that level of detail. But you have to provide some way of maintaining that communication. You could also provide them somewhere to reach out to you, like a toll free number or an email that's monitored, email inbox, where people constantly know about what is going on with their product. Because like you said, it's not a one time thing with the Software-as-a- Medical- Device. There's actually another thing that I think I didn't mention so far that is different from physical medical device, is that the cyber security, that is a big consideration when it comes to this, because of many reasons, a lot of them very obvious. You could put it on your different laptops, mobile platforms. So the chances of somebody hacking into it and thereby impacting patient safety is that much higher, versus a physical machine, which you can physically secure. And FDA has issued guidance on cyber security. And there has been a lot of focus recently. I mean, they do refer to the Federalist framework for cyber security. So you have all these things like access controls, encryption, different methods of securing your platforms and solutions.

Etienne Nichols: Yeah. I can definitely see that being an incredible challenge because it's an ongoing thing as well. And I suppose it would speak to that post market surveillance or post market activities, maintaining that security of your device.

Rahul Kallampunathil: Exactly.

Etienne Nichols: Yeah. I thought this was really good. Any other thoughts, comments, recommendations you can give to companies as they're gearing up their Software-as-a- Medical- Device, either as it relates to testing or just in general?

Rahul Kallampunathil: First of all, this field is pretty dynamic. So even the regulations can change. The Software- as- a- Medical- Device, all the examples that I used in this conversation so far, where I would say more simple examples, remote monitoring, image analysis and all that, there are a lot of other Software-as-a- Medical- Devices which are much more complex, like your AI driven models, machine learning, which also falls under SaMD. And the guidance for that is changing because those categories of Software-as-a- Medical- Device, they can automatically adapt based on the inputs they're getting and they can learn as they go through more examples. So the guidance itself is changing in this area. So companies that have those type of products, they need to make sure that they keep up with the latest guidance. I think if a company has a good quality management system, everything else kind of falls in place, because they would have a way to keep track and monitor the changes, whether it's with the regulations or with the leading IT best practices. The challenge is more for the companies that are more like the software companies, which don't have that QMS framework.

Etienne Nichols: Yeah. That makes sense. And we definitely recommend going to the Greenlight Guru website, if you need more information about some of these things. But aside from that, there's lots of different places you can get information. Do you have a recommendation, Rahul, for these companies that are maybe early on just getting into the medical device world, coming from the software world?

Rahul Kallampunathil: Yeah. I think companies, especially the ones that are new to this medical device world, they definitely would need some help. I mean, it's a lot of things to do, especially when you're bringing out your first product. I think if you have multiple products, eventually you get more mature state where you can kind of do it by yourself. But before that, I think it definitely makes sense to take help of professionals. And there's a lot of information on the FDA websites about what you can do and what are the different categories and so on. But I think if you are considering, especially if your software falls under one of the categories where you need to go through a regulatory pathway, it makes sense to do it a more professional way.

Etienne Nichols: That makes sense. Well, I appreciate it, Rahul. You kept your promise. Let me see if I can remember some of these. So we had SaMD, of course. MDDS, which I didn't think I knew what that acronym was for previously, MDDS. IMDRF, CSA, CSV. This was really good. So you kept your promise with the acronyms. We'll definitely put a link in our show notes so they can find you and find the Arbour Group, see what you're doing and learn more about what you do at Arbour Group. And very much appreciate this conversation. Thank you, Rahul.

Rahul Kallampunathil: Yeah. Thank you, Etienne.

Etienne Nichols: All right. For those of you who've been listening, you've been listening to the Global Medical Device Podcast. Thank you for listening. And we will see you next time.

About the Global Medical Device Podcast:

The Global Medical Device Podcast powered by Greenlight Guru is where today's brightest minds in the medical device industry go to get their most useful and actionable insider knowledge, direct from some of the world's leading medical device experts and companies.

Like this episode? Subscribe today on iTunes or Spotify.