In this blog, we discuss key takeaways from a recent whitepaper written in conjunction with Beanstock Ventures on digital health technology.
What is Digital Health?
Digital health merges digital technologies with health, healthcare, living, and society to enhance the efficiency of healthcare delivery to make medicine more personalized and precise.
The past decade has ushered in major disruption in all industries, including the medical device and life science sectors. Market disruptors such as smartphones, social media and more transformed the way that people work, play, and manage their health. Software has transformed how doctors practice medicine, how people manage their health, and the fundamental interactions between patients and providers. During this process, the boundaries between digital health and medical devices began to blur.
According to the Food and Drug Administration (FDA), “Digital health technologies use computing platforms, connectivity, software, and sensors for healthcare and related uses. These technologies span a wide range of uses, from applications in general wellness to applications as a medical device.” These applications are driving a lot of the wearables we see today, like a heart rate monitor running on a smart watch or a mobile application connected to a wearable. Other examples of digital health applications might be something like 23andMe, which uses genetic sequencing data to identify health risk factors.
The Emergence of Software as a Medical Device (SaMD)
Traditionally medical devices have been classified as an instrument, sometimes with software running on the actual device itself.
The lines between digital health technology and medical devices get crossed once the software technology begins to perform a medical function, especially if the technology is not embedded within the medical device. Consider software that determines the right medicine dose for a patient based on his or her personal data, or software that detects and diagnoses a stroke through analyzing MRI images. These are examples of software that could be serving as a medical device.
As digital health has pushed further and further into the traditional realm of medical devices, an entirely new category was formed and regulated, which is software as a medical device (known as “SaMD”). SaMD is described as “software that performs one or more medical functions. While the software may be embedded in a piece of hardware (as is often the case), it’s the software itself that performs the medical function.”
With the emergence of software as a medical device, there are questions around risks, regulations and safety. Understanding trends and potential risks can help teams mitigate challenges and navigate forward with greater success.
To learn more about keys to success and best practices in the digital health medical device market, download the full whitepaper.
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.
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.
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.
This post on Software as a Medical Device (SaMD) development is written by Mercedes Massana, the Principal Consultant of MDM Engineering Consultants.
SaMD software is software intended to be used for one or more medical purposes that do not require embedding in a medical device. These purposes can range anywhere from helping to diagnose or treat disease, helping in the clinical management of a disease, or providing information to help with the clinical management of a disease. SaMD differs from other medical device software in that it will operate on different platforms and will interconnect with other devices, carrying with it an increased cybersecurity risk and a commensurate increase in the use of off-the-shelf software.
On the surface it may appear that the development of SaMD software is no more difficult than the development of Medical Device embedded software, but appearances can be deceiving, and the development of SaMD products can be quite challenging. In order to deal with these challenges, there are four key best practices that should be followed for SaMD software development.
These practices are:
Make use of standards and guidance documents
Apply the right level of rigor
Understand the difference between Verification and Validation
Implement a post-market monitoring program
Best Practice #1– Making Use of Standards and Guidance Documents
Although standards development organizations and regulatory bodies have only started to scratch the surface in the creation of standards and guidance documents to help SaMD development organizations, there is a sufficiently detailed body of work available to help development organizations succeed. The most relevant of these are the documents generated by the International Medical Device Regulators Forum (IMDRF) related to SaMD and IEC 82304 Safety and Security of Health Software Products. The IEC standard points to other well-known standards, such as IEC 62304 Software Development Lifecycle, IEC 62336 Usability Engineering and ISO 14971. Additionally, several FDA guidance documents are available that apply to all medical device software and are useful for the development of SaMD, these include General Principles of Software Validation, Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices, Off-The-Shelf Software Use in Medical Devices and the FDA pre and post market cybersecurity guidance, as well as other guidance documents
Best Practice #2 –Applying the Right Level of Rigor
Within the development of SaMD, a clear understanding of the scope and intended use of the product is necessary, and to that end, it is necessary to have a method to gauge the risks associated with SaMD use. The IMDRF “Software as a Medical Device” Possible Framework for Risk Categorization and Corresponding Considerations, IEC 62304 , and FDA Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices all provide a method for risk based classification of SaMD. The rigor applied to the development of SaMD should be commensurate with the level of risk. IEC 62304 uses the Safety Classification to define the level of rigor of activities to be performed in the software lifecycle based on the level of risk. Ideally, the development process is sufficiently flexible to avoid the over-engineering or under-engineering of the SaMD in question. A development process that is adaptable requires organizational maturity and experience, in order to perform the right set of activities and understand the value provided by those activities.
Best Practice #3 – Understanding the Differences Between Verification and Validation
SaMD is a medical product, a system in and of itself. Therefore, SaMD system requirements must be verified to have been implemented correctly, and SaMD user’s needs must be validated to ensure that the product satisfies the user’s need and that the right product was built for the customer. Validation typically includes human factors testing, clinical evaluation to determine the efficacy of the software for its intended use, and a demonstration that risk controls are effective. This requires more than just your standard set of software testing, which typically consists of code reviews, unit testing, static analysis, integration testing and requirements-based testing.
Best Practice #4 – You Are Not Done When the Software is Released
Your SaMD software has successfully completed verification and validation, has been cleared by regulatory agencies, and is now ready to go live. Time to breathe a sigh of relief and congratulate the team for a job well done. Pop the champagne and throw a party, you have all earned it. Enjoy the festivities, but afterwards turn your attention promptly to monitoring the performance of the SaMD post launch. Rigorous and exhaustive as your testing was, you can never anticipate every possibility. Be ready to respond to identified software defects and emerging cyber threats and deploy patches or software fixes as issues are identified. The nature of cybersecurity risks is ever-changing, and no system, regardless of how well-designed, or rigorously-tested, is free of software defects. Additionally, customer input can provide opportunities for enhancements and improvement. However, be aware that proposed changes can impact the intended use of the device, the classification of the SaMD, and can ultimately result in additional regulatory submissions. It is paramount that prospective SaMD developers evaluate changes thoroughly and plan actions related to these changes to avoid surprises that can delay, or outright derail, SaMD implementation.
In summary, SaMD can provide great benefits to the user; however, to successfully launch SaMD that meets the user’s needs, several best practices should be utilized in their development. These best practices, making use of standards and guidance documents, applying the appropriate level of rigor in the development of SaMD, understanding the difference between Verification and Validation, managing change appropriately, and implementing a good post-market monitoring program. These best practices are indispensable in ensuring a safe and effective SaMD product.
Machine Learning in Software as a Medical Device
Machine learning (ML), a subset of artificial intelligence, has become integral across software in all industries, and the medical and life science spaces are no exceptions. ML can help medical systems improve the identification and diagnosis of disease, create personalized medicine, and help with drug discovery and manufacturing (just to name a few areas). Current guidance and regulations require validation of the final version of the software prior to a release—so what does this mean for Software as a Medical Device (SaMD) systems that incorporate ML and ‘continual’ algorithms designed to accumulate and improve knowledge after a system’s release in the market?
The Current Situation
The FDA and other regulatory agencies currently lack the guidance needed for medical device manufacturers to include continual algorithms that adjust and improve post-market submissions. A changed algorithm would require a premarket review for each minor adjustment due to the potential impact on patient care.
There are many medical ML products on the market today, which currently use the DeNovo and 510(k) process, but the process is locked. Otherwise, the ML product would violate regulatory control. With this limitation, the FDA has been listening to input from the industry to help inform potential guidance and regulatory change.
The proposed framework includes elements from the FDA’s current premarket programs including:
IMDRF’s risk categorizing principles
FDA’s benefit-risks framework
Risk management approaches
IEC 62304 principles
Change management approaches
One of the key proposed expectations from the FDA would be a commitment from manufacturers to be transparent with the constant monitoring of artificial intelligence and machine-learning-based software providing periodic updates, including any changes to algorithm protocols.
The proposed framework received positive feedback from the industry, and the FDA has now decided to implement the discussion paper with guidance. It is expected to be released sometime in 2021. The intended premarket approval process will allow a trusted manufacturer (see below for definition) to make pre-approved post-release changes only if the manufacturer follows a predetermined change control plan.
What is a Trusted Manufacturer?
So what does the FDA mean by a trusted manufacturer?
Firstly, a trusted manufacturer should ensure they have an efficient and proactive quality system in place. Some of the key quality-related areas to focus on are:
Design controls and required documentation to prove to the FDA exactly how the manufacturer has provided for the safety and efficacy of a system or device.
Design verification and validation establishing that what the manufacturer has built works for the end user as intended.
Risk management, ensuring that any applicable hazards have been identified and that mitigations have been implemented.
Iterative design reviews, allowing risks and omissions to be seen quicker, reducing total in-field corrective actions or bugs.
Several other considerations are critical in becoming a ‘trusted manufacturer’ under the anticipated guidance, some of which include:
The ability to follow good machine learning practices during all design stages.
Ensuring that all algorithm changes that are implemented are done according to pre-specified objectives and any applicable change protocols.
Trusted manufacturers are expected to document how the system will learn both pre- and post-release.
Ensuring the integrity of reference data used by continual algorithms.
This is an exciting time for medical and life science companies embarking on or continuing their ML product’s journey. Connect with us to find out how Jama can help!
