Over the last decade, digital health solutions have become increasingly important, powering revolutionary developments in areas such as robotics, genomics, diagnostics, patient/provider interactions, and many more.
In our recent webinar with MDM Engineering Consultants and BeanStock Ventures, we talked about critical standards and best practices to follow. Attendees also heard critical insight from industry leaders in digital health development.
Watch the webinar or read the recording to learn more about:
- Digital health solution classifications
- The most common digital health development challenges
- How Jama Connect can be leveraged in your development process to help ensure FDA compliance
- Industry leading insight and knowledge
Below is an abbreviated transcript and a recording of our webinar, Ensuring FDA Compliance for Your Digital Health Solution.
Mercedes Massana: Digital health merges different digital technologies to make health and healthcare applicable to our living in society and make it more personalized for the patient. Many people see digital health as the future of healthcare. Some things that are digital health are like wearable devices. For example, your Apple Watch. It has some sensors that can do an EKG. That would be considered a wearable device. Things like telehealth and telemedicine, which we all became more familiar with because of COVID, are also part of digital health.
For digital health to use technologies such as different computing platforms connectivity, which is very important because you’re trying to get information to the healthcare provider, software plays a huge and significant role in digital health, and then different technology with sensors. So these technologies are intended to be used as a medical product or as a companion diagnostic to a medical product and help the healthcare provider make decisions. Software is playing an increasingly important role in healthcare in general. As medical devices have gotten more complex, software has played a bigger role.
Three Types of Software in Medical Devices
Mercedes Massana: There are three different types of software related to medical device. One is software in a medical device, embedded in a medical device. Another is software as a medical device, which we’ll call SaMD, and we’ll be discussing today. And the third is software used to produce or maintain a medical device. All these three types of software are regulated by the different regulatory agencies. Software as a medical device, is software that is intended to be used for one or more medical purposes that perform these purposes without being embedded in a medical device. So when we say embedded in a medical device, it’s software that’s physically part of a medical device. Like an infusion pump has embedded software in it that runs on the GUI on infusion pump.
This means that this software that’s a medical device in itself is not something that’s tangible. It’s not something that you can touch, like a medical device where you can touch. Well, this software lives on the ether and it’s not something you can touch. But it provides meaningful information that can help you mitigate disease, it can help you diagnose screening. For example, if you had software that took information from an MRI and helped define whether cancer was present, that would be software as a medical device. It takes information from another device and it helps a healthcare provider and make a diagnosis.
Determining the Intended Use of Software in a Medical Device
Mercedes Massana: So for software as a medical device, an important part is to determine what that intended use is. And in order to do that, guidance documents provide… You have to provide the answers to these three very direct questions. One is what is the significance of the information provided by SaMD to the healthcare decision? Is this information going to be used to help treat a disease, to help diagnose a disease, to help clinical management of the disease like diabetes, or to just inform clinical management? Obviously, it’s more critical if it’s going to treat or diagnose a disease. We also want to know the healthcare situation or condition, the scenario in which the software is going to be used and whether absence for incorrect information at that time can result in critical and putting somebody in a critical position, where they might be subjected to serious injury. Or in a serious position where they might be subjected to additional procedures and things that would not be necessary. Or in a non-serious position where it’s just information is not really that critical.
And then we also want to know what is the core functionality of the software. What are the what is it supposed to do? What are his critical features and functions? So based on these three questions, we would craft an intended use statement for the software as a medical device. The healthcare situation, there’s three different classifications, as we said. Critical is where accurate or timely diagnosis or treatment action is vital to avoid death or serious injury. Serious is where we need accurate and timely information in order to avoid an unnecessary intervention. And then non-serious is where the information is important, but it’s not critical in order to avoid that serious injury or unnecessary intervention.
Using Categories provided by International Medical Device Regulators Forum (IMDRF)
Mercedes Massana: Once we’ve determined what that healthcare situation or condition is, then we can determine the significance of the software. We use the categories provided by IMDRF, which is the International Medical Device Regulators Forum. This organization has actually generated some guidance for SaMD. And it’s used by regulators to try to have some common level of standards on how the software is going to be regulated. So in order to get to the classification, we determine the healthcare condition, what’s that healthcare scenario. And then we determine what that information provided is going to be used for. So if it’s going to be used to treat or diagnose disease, and it’s in a critical scenario, that will have the highest level of criticality, which is a four. There’s four levels of classification one being the least critical.
Again, it’s a level of one to four. Four has a very high impact and one in low impact. So, a device that would screen for cancer or something that software would be used to screen for cancer, would be very high impact. Something where maybe we’re sending a heart rate for somebody who’s going through cardiac rehabilitation, that might be a lower impact because it’s just using to inform the clinician on how things are going, but it’s not being used directly to impact on the treatment. There are additional ways to classify medical devices. The global harmonization task force has a classification of A, B, C, or D. So four stage classification, where A is the lowest level of risk, and D is the highest level of risk. These can be used because SaMD is in itself a medical device, we can use this level too.
RELATED: Regulatory Shift for Machine Learning in Software as a Medical Device (SaMD)
IEC 62304 Classifications of Software
Mercedes Massana: Additionally, IEC 62304 classifies software in three different classes, C, B or A, where C is if the software fails, it can result in serious injury or death. B it can result in non-serious injury. And A would result in no injury or harm. Now, why is it important to classify software? Because this will tell us how much effort we need to put into the documentation and testing and so forth of software. Obviously, the more critical it is, the more effort it will be required. FDA also classifies software. They have a level of concern for software. And there’s three levels also which align pretty well with the definition of IEC 62304. For FDA, they use major, moderate and minor.
Software in general has always been challenging for manufacturing. Software as a Medical Device (SaMD) poses some additional challenges to the developer of the software. Some of these are, for example, the use of off-the-shelf software is a lot more prevalent in SaMD than it is with embedded devices. Regulatory agencies want to see a lot of information when you’re using off-the-shelf software or suit, which is software of unknown providence, so there’s a lot of requirements that you need to meet. This is essentially software that you don’t own, you don’t have the source code for, but it’s still used in your medical device, so you’re still responsible to ensure that it’s safe within the parameters that you’re using it. Software as a Medical Device also, it will run on different platforms. It can run on a computer. It can run on an iPad, it can run on a smartphone as opposed to embedded software where you know the environment that it will always operate in. So it is a challenge to ensure that software behaves effectively in any of the platforms that it will run it.
Challenge: Interconnectivity with Other Systems
Mercedes Massana: Even though most medical devices today have some form of interconnection right to other systems, for SaMD, it’s almost given that it will have to be interconnected because the information will have to get to the healthcare provider, and that is typically through the internet. It’s going to be sent… There will be connectivity to other systems that will provide challenges like cybersecurity. We need to keep information safe. Those are challenges that we need to meet. Secondly, the method of distribution, the frequency of updates of SaMD is different than that of an embedded medical device. So for an embedded medical device, the device gets built, the software gets put in EPROMS that gets built into the device, the device gets packaged. It gets sent out to a pharmacy where you might buy it or it gets sent out to a hospital where it will be unpacked and tested.
Well, Software as a Medical Device is not a tangible thing, so it’s going to be distributed through the internet there is no checks and balances there. There’s no checksum to know that you’ve downloaded it correctly, so it proves some additional challenges there. And then lastly here, it’s much easier to duplicate software that’s on the internet that you can download. The manufacturer doesn’t always have control of how this software is duplicated, as opposed to software for an embedded medical device where in the manufacturing facility it gets thrown into EPROMS and then gets put into the medical device. So the manufacturer has control. For SaMD, the manufacturer does not have control, or does not always have control.
RELATED: Software as a Medical Device (SaMD): Four Key Development Best Practices
Challenge: Rapid Development Time
Mercedes Massana: For most applications, the apps we have on our smartphones, they get updated probably three, four, five, six times a year. So for a medical device software, you need to have a pretty rapid development time in order to keep up with this change of information. Then there’s also cybersecurity risks that we need to be aware of. Again, information security is a big issue. SaMD is something that regulatory agencies are very interested in. How do we get to meet these development challenges? Well, we need to have a very robust design development process to help us meet these challenges. We need a process that’s very methodical and systematic. We need a good quality management system. And then we need a software lifecycle process that takes us through the entire software lifecycle for the development of this application. It should take us from the point of where we’re starting to understand user needs, all the way to where we’re ready to retire the software. IEC 62304 is such a process where most people that are developing medical device software are utilizing this process.
Challenge: Managing Software Changes
Mercedes Massana: In addition, because the environment that the software is used and can change after release of the software, it is important to have a very strong post-market surveillance process to monitor customer issues in the field. You also need to monitor for cyber security threats, things like that. And you might need to make changes to your software based on what you’re observing in the field. So a post-market surveillance process is very important. Additionally, managing software changes, which is always important no matter what the software is used for, whether it’s a Software as a Medical Device, or embedded software in a medical device, is very important to manage changes. But for Software as a Medical Device, it’s even more important because what you change in the software could actually change the classification of the software. It could be more critical or less critical and it can also change the intended use. If you change the intended use, that means that you’re going to have to submit to regulatory agencies, so you want before you get approval to market that software.
There are a lot of software applications. Now, Software as a Medical Devices where they’re getting so much data and information that they’re using artificial intelligence, or machine learning to make the software smarter and better. Using this could potentially change the classification of the software. SaMD is still fairly new to regulatory agencies so I don’t think they’ve figured out exactly how they’re going to regulate things like artificial intelligence and machine language. But managing changes and understanding the impact of those changes is very important for our Software as a Medical Device. There aren’t a lot of guidance documents out there for Software as a Medical Device, but luckily there are a few standards that can guide us in our development efforts.
To learn more, watch the full webinar, “Ensuring FDA Compliance for Your Digital Health Solution.”