![podcast_andrew wu]()
These days, medical devices often include software or are standalone software.
So, software as a medical device (SaMD) is a hot topic, and regulatory bodies have been updating regulations and launching new initiatives to seek applications being submitted for approval.
However, a lot of confusion surrounds the how, what, and when to do things to meet FDA and other regulatory expectations.
On today’s episode, we have Andrew Wu, a software consultant for Rook Quality Systems. He helps SaMD companies ensure that their documentation, platform, and systems they establish during the design, development, and manufacturing of software aligns with regulatory requirements.
LISTEN NOW:
Like this episode? Subscribe today on iTunes or Spotify.
Some highlights of this episode include:
● SaMD is a standalone software that performs 1 or more medical purposes without being a part of a hardware device.
● Embedded firmware and software that monitors performance of a hardware device are not SaMD. They are still software and an integral part of the device.
● FDA’s guidance is not enough for many applications, so it is planning and engaging in new activities and programs for future SaMD applications.
● 62304 Standard: Consensus standard for manufacturers on how to manage their software lifecycles. Initially, classification determination was unclear.
● Care about the SaMD classification to know what information to provide and understand the impact of its safety profile when a failure or defect occurs.
● Manufacturers should be in constant contact with the FDA and consultants about regulations because of frequent changes and additions.
● SaMD companies need to have a quality management system (QMS) during the development process to address regulations; don’t wait until it’s too late.
● No regulatory standard of method to use or not use; but describe, define, and document your methodology.
Links:
Rook Quality Systems
FDA SaMD
Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices
Digital Health Software Precertification Program
IEC 62304
International Medical Device Regulators Forum
Greenlight Guru
Quotes:
“Software as a medical device is a standalone software, which performs 1 or more medical purposes without being a part of the hardware device.” - Andrew Wu
“As this industry is progressing, and the way that providers are utilizing software in many different areas, the landscape is really changing.” - Andrew Wu
“This classification is very critical and helps you understand the scope of the documents that you need to provide.” - Andrew Wu
Transcription:
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.
Jon Speer: Okay, Software as a Medical Device. This is a very hot topic in the medical device industry today and there's a lot of confusion on how and what and when to do things to meet FDA or EU or other regulatory body expectations.
So sit back, relax and enjoy this conversation that I have with Andrew Wu, Andrew is a Software Consultant for Rook Quality Systems and has a ton of experience on working with SAMD companies and ensuring that the documentation to platform the systems that they establish during the design development and manufacturing of software adheres to and aligns with the regulatory requirements.
Jon Speer: Hello and welcome to the Global Medical Device podcast, this is your founder and DP of quality regulatory green light as well as your host for the Global Medical Device podcast, Jon Speer and you know, folks, I know it's crazy to think about today in the medical device industry how many products are incorporating or including or exclusively software based these days.
There's kind of this new acronym that's out there SAMD, Software as a Medical Device. And good news for you, I have Andrew Wu, Andrew is the Software Consultant for Rook Quality Systems, and an expert in how to manage software as a med device projects. So Andrew, welcome to the Global Medical Device podcast.
Andrew Wu: Thanks for having me, Jon. It's my pleasure to be here.
Jon Speer: Now, Andrew I know you do work all over the world, and I believe as we're chatting today you're in some exotic location, so where are you calling from today?
Andrew Wu: I'm currently in Taiwan right now, helping a startup of a friend of mine, who I have been knowing for a long time. But for the past I have been helping many companies in the space of software medical devices both embedded software and also SAMD so standalone software for applications in the healthcare space.
To have the opportunity to help out those firms navigating through the regulatory landscape constantly changing, in fact, it's really rewarding to us and to the team at Rook.
Jon Speer: Well that's great, and I know you guys have been doing some fantastic work. For those of you listening, I suspect some of you this might be old hat, you might have been in the medical device industry for quite some time. Others of you, if it's indicative of conversations that I have on a weekly basis, you may be developing a software product that, yeah it's considered a medical device but you may not speak regulatory. You may not speak FDA or 13485 or 62304.
Andrew I thought maybe before we dive too deep into the topic, it might be good to level set the audience a little bit, just give an explanation or a definition of what is Software as a Medical Device?
Andrew Wu: Yeah, definitely. As we all have seen, the software applications in healthcare industry is emerging and adoption of those standalone software services is increasing significantly. So as a result, all the regulatory bodies in the world have been updating their regulations over time and even launching new initiatives and programs to accommodate a variety of new applications seeking for approval to be marketed.
Software as a Medical Device is a standalone software which performs one or more medical purposes without being part of the hardware device. For instance, if the software's main objective is to be the driver for the hardware device, it will not be considered Software as a Medical Device.
However, if there is a computer-aided detection software which performs the post-processing of images to help the breast cancer detection, through the supply of images by the user or by the provider and have their back end algorithm that gives you the result in 48 hours, this will be considered as a standalone Software as a Medical Device.
Jon Speer: Alright, well that's helpful. It might also be helpful to explain what is not Software as a Medical Device, based on the definition that you just provided. Embedded firmware, not Software as a Medical Device?
Andrew Wu: Yeah, for example a piece of software that monitors the performance or the proper functioning of a hardware device, that will not be considered as a SAMD. Also the other example that is, when a piece of software is enabling the clinical communication and workflow without giving any medical purposes, that will not be considered as SAMD either.
I think that's where Rook and our consultant is very experienced at, is helping the manufacturers navigating through this definition of SAMD or other type of softwares because the regulations have been changing constantly and the regulatory bodies have been accommodating and making some tweaks on the way that they foresee and try to give oversight to many new applications on the market.
We will be able to provide more information in regards to that and work closely with the clients in that regards.
Jon Speer: Well it's a really good point and at the same time, even that embedded firmware, for all intents and purposes from a regulatory perspective, is considered software. I realize that it may not be SAMD but it still is software that is an integral part of a medical device.
Andrew Wu: Yeah, that's exactly correct, Jon. That's where FDA have been putting most of their focus on. As many of the manufacturers already know in 1997, FDA published a software validation, basically a guiding principle to provide manufacturer guidance how they should provide and prepare their regulatory submissions in terms of the content, or what they submit.
As this industry is progressing and the way that providers are utilizing software in many different areas, and the landscape is really changing and that particular foundation guidance is not enough for many applications. For instance, FDA have been recently publishing a pre-certification program for digital health applications. This will allow the developers, or A.K.A. the manufacturers, to create, adapt and expand their functionalities of their software and constantly be in communication with the FDA and have the dialogue in making sure that while the FDA is giving enough oversight on the application, the manufacturers still have the flexibility to make changes to their software pieces.
I think that's a great example of how FDA is planning and engaging in this kind of activities for future applications in this critical area. And we're really very excited that FDA have been actively doing that.
Jon Speer: Yeah it's a really great program, it's one of the examples of some of the relatively recent more progressive, more innovative regulatory programs that FDA is starting to implement and the feedback that I've heard has been really good as well.
Andrew I wanna dive into something that I think creates a lot of confusion, at least from the seat that I sit in and the conversations that I have on a fairly regular basis. It kind of goes like this, there's a software company or a software team that's developing, for all intents and purposes, what is a medical device. So it fits under the SAMD but these software developers, very brilliant people, excellent software developers, but they don't speak regulatory. They don't speak FDA, and so on.
Somewhere along the way they discover this standard IEC 62304 and they start to really adapt or adopt some of the methodologies that are in the 62304 standard, but I think there's a disconnect between the practices that are in place and being able to translate that information into regulatory speak, if you will.
Might be worthwhile to take a few moments and talk a little bit about the 62304 standard, focusing on a level of concern, classification and that sort of thing.
Andrew Wu: Yeah, absolutely. That's a very important topic that many manufacturers would be willing to know more, and in fact, IEC 62304 is the consensus standard that many regulatory bodies all over the world have agreed to. And this standard basically gives a high level guidance to the manufacturer on how they should manage their software life cycles. From their planning to develop, during their development process and during their design verification and validation stage, and also post-launch or before that its deployment to the client, and post-launch surveillance.
So that's very similar steps of a typical medical device being on the market, but have the regulatory pieces on the software control. That's where a lot of people have confusion on, and the very first step for manufacturers to realize what they need to prepare for regulatory submission is to understand the classification.
Back in the previous release of 62304 I believe was back in early 2000, I cannot remember exactly what year was it, the classification was not that clear so it opens up to many interpretations to the manufacturers to make a call on this. However, in 2005, there's an amendment to 62304 and they provided a flow chart, allowed the manufacturers to follow and helped them delineate the hazardous situations that caused by software failure or latent defect or application, and also taking considerations of the risk control measures they plan to develop, the effectiveness of those measures.
And last but not least the severity of injuries which the previous release of the standard have put a lot of emphasis on.
So in short, there are many changes in how manufacturers have to leverage to identify the classification of their software and in addition to 62304 I think there are two other resources that's worth looking at for manufacturers.
If you are a U.S. based manufacturer, the level of concern guidance by the FDA is very very helpful to help to determine in what scope of documentation needs to be provided to the FDA for your classification devices and also to the topic that we stick today, in particular the SAMD classification in a guidance provided by the international medical device regulatory forum. They also provided a good example to help you determine the classification of your software devices, software as medical devices, so there are multiple ways of doing so, but the best practices is really to understand how those regulatory bodies structure this classification procedure and have a chat, have further discussion with people who have done this before and to really help you identify precedents that they have seen that can help you take advantage of the regulatory path that some of the manufacturers have explored with the FDA.
Jon Speer: So when we talk about SAMD classification and level of concern, I get that standard 62304 and FDA guidance, you give some explanation on that, but Andrew, I mean help me, help the audience, why does that matter? Why do I care about level of concern when I don't care about my SAMD classification?
Andrew Wu: Well, essentially it's just like any other medical devices. Looking at the safety profile of the software and understand the impact of the safety profile, when a failure happens or when a defect occurred what kind of safety concern should be addressed sufficiently. Similarly, to any hardware devices out there, we have to understand how we plan to implement control over those risky scenarios that occur.
On the other hand, when the manufacturer is going through this preparation on their regulatory submissions to the regulatory bodies, such as FDA, this classification is very critical that helps you understand the scope of the documents that you need to provide.
A good example of that is for FDA level of concern documentation requirements, which is clearly listed on the level of concern guidance document that we highly suggest any manufacturer out there to take a look and check it out.
For minor concern devices, essentially there are many documents that you do not need to provide to the FDA while they are reviewing it. You just have to keep that in your quality management system and have a traceability among those documents, but it's not required to do it extensively.
However, if you're software as medical devices is considered a major concern, the FDA definitely will require you to provide more than enough information help them review the devices. And also at some point in time they might ask you to provide your surveillance, postmark your surveillance data on performance of your software even or some other relevant information that the FDA thought as a manufacturer that you should address more and more extensively.
So, I think the FDA is taking this opportunity to work with many manufacturers all over the country or even all over the world to really streamline this process, but really software is case by case and FDA is taking this learning opportunity as well to refine their way to give oversight to the manufacturers, but at the same time, the best approach for the manufacturer is to be in constant communication with the FDA, to be aware of all the changes on the regulatory guidelines and be sure that you have conversation with consultant or who have done this before, and that would be really helpful and that's definitely our best advice for many manufacturers out there.
Jon Speer: Absolutely. Ladies and gentlemen, I just want to remind you I'm talking to Andrew Wu. Andrew is a software consultant for Rook Quality Systems. Rook is a partner of ours at Greenlight Guru. We're starting to dive into areas on this conversation about the importance of a quality management system and documentation during your software development process. You should know that this is a big reason why we're here at Greenlight Guru is to try to simplify those quality management system needs and the documentation that is expected and required and frankly it's going to help demonstrate and prove that your products, the software that you're developing as a medical device, are safe and effective and meet your indications for use.
So if you'd like to learn more about how Greenlight Guru is helping software's med device companies bring their products to market and insure compliance along the way, you should definitely go over to www.greenlight.guru and learn more information and feel free to request a demo so you can learn how our platform is helping companies like yours.
So, Andrew, you started to talk a little bit about the quality system needs and I think that's really important because sometimes when we talk to software's med device, as I've already mentioned in this conversation, oftentimes it's the first time that the team assembled to develop this software's med device, it's the first time that they're entering into a regulatory environment. They don't speak FDA, they don't speak regulations and sometimes the conversation is a bit challenging because here I am trying to promote best practices when it comes to implementing a quality management system and you just hit on a couple of things that are really important or companies to think about, but oftentimes it's like, Oh I don't need to worry about that right now; I'll deal with that later.
But you just hit on some very key reasons why, even in the development cycle, it's important for an SAMD company to start to build their quality management system.
Andrew Wu: Yeah, absolutely. We cannot emphasize enough how important quality management system is for manufacturers out there, not just hardware devices but software devices in particular.
When I first started working with Rook on occasions with a few startups, which their founders did not have prior experiences in healthcare space, we try to communicate how important this quality management system is to them.
We actually found out that our approach of letting him know the framework and complexity of the quality management system is not the best way to help them understand.
Most of the time their team learns by doing it and encountering all the pitfalls that we have seen multiple times in our past experiences with prior clients and then they'll realize how important that is.
But at the same time, we try to keep them informed during their development process: which documentation needs to be recorded, what's the best practices to have those records, how do you keep traceability among all different stages during the development and even on the market.
We just cannot emphasize how important and how meticulous a QMS system would be very helpful for many manufacturers to follow, not just from the regulatory standpoint, not just trying to get an approval from the regulatory bodies, but also to help the manufacturers to keep a close eye on every step along the way; every development step, every testing steps, every [inaudible 00:22:46] step.
All those steps, it can get down to granulars, and following a good QMS framework with help from experienced people outside can really help you both on the quality of your product but also meeting the regulatory requirements by the FDA and other regulatory bodies.
Jon Speer: I want to level set one term that you mentioned a couple of times. In that last explanation, you mentioned the term manufacturer. And I know some of you listening may say: Oh well we're a software company, we are not a, quote, manufacturer, but it's important to realize when Andrew used the word manufacturer, if you are developing an SAMD device that you're going to launch into the marketplace, you are considered a manufacturer. I realize you're not tangibly building a mechanical device but still, by definition, you are a, quote, manufacturer. So just keep that in mind. That term does apply to you even though you're making a software product.
The other thing that I think is important, and you hit on this as well, is there are Rook Quality is good example, Greenlight Guru is another good example. We know how to build quality systems for software as a med device. We know how to speak FDA and ISO 13485 and ISO 14971 and these are all expected practices that companies need to adopt and implement within their systems. I can't emphasize enough, whether you come to Andrew at Rook quality or you come to me at Greenlight Guru or someone else, do seek out guidance on this because it is very important to make sure that you build systems that will scale and grow. Andrew one other thing that often times I hear and I believe this to be kind of a myth but I'll let you weigh in on it, a lot of times the software company will say "Oh well that quality system stuff, that traceability stuff, it's waterfall and we're lean and agile and very dynamic in our development practices, so we can't implement a quality system, we can't follow FDA regulations because FDA and all the 13485 it requires a waterfall approach and that's just not how we do business." Can you speak to that myth a bit?
Andrew Wu: Definitely waterfall development technology or development model is the traditional way that many development firm follow. However, a waterfall model sometimes can be a challenge for regulatory bodies to understand how closely that you follow quality management system. Let me take an example of what we have seen before, because waterfall process is ... I'll just give a high level description on this. You started with the planning of the development of software and you started developing within your scope, within your resources and after that you do testings and validation activities, the requirements are not met, the acceptance criteria needs to be adjusted. You go back to the development phase and make some changes and then do it again and after you have completed all the testings and passed all the testing requirements and then you do the rest [inaudible 00:26:44] to the clients and such. However, software have many many pieces, many modules in there, like as we call software components and 62304. When you are dealing with multiple software components at a time, each component interfaces with each other at different occasions. That's where the challenge of following the waterfall methodology comes from. When you look at one software component and do the testing you still have to consider how the dependencies other software components come into play when they're interacting at some occasions.
You have to be nimble at the same time, you have to be closely monitoring how each software component is behaving, at the same time you still have to foresee what kind of scenario, hazardous scenario that one or multiple software component fail or have defect will cost the overall system and what level of concern. There are many many things that you have to consider during the development, during the testing and definitely during when you're choosing a model to develop your software. All that really comes down to a good approach following a good quality management system and have the design control, appropriate design control tools to allow the manufacturers to better visualize their hardware, firmware, and software components. For your software and also incorporating some of the open source software you been, which is a hot topic for many software developers. How do you manage that? How do you incorporate that into your QMS? I think follow a good solid QMS and have a good advice from people who have done this before and have experience in space is going to be very very valuable to any of the manufactures out there.
Jon Speer: Yeah and let me just set the record straight folks, nowhere in FDA regulations, nowhere in ISO 13485 or any regulatory standard that I'm aware of does it prescribe that thou shall do waterfall. The methodology, the approach that you take when it comes to design and development of your products is up to you to decide. To Andrew's point, define your methodology, define it in a process, define it in a procedure. You can do D-model, you can do agile, you can do waterfall, you can do a combination of any of those things or something yet that still we haven't even talked about. There's nothing that dictates the methodology that you apply during the design and development process, the expectation is that you do describe and define and document activities during the design and development process and demonstrate traceability of all of these different design control elements and risk management elements. That's the requirement. How you get there is a little less important as long as you have a process that's defined.
Andrew Wu: That's absolutely correct, Jon. You have summarized it very very well.
Jon Speer: Okay so Andrew again, toward the tail end of our conversation today you mentioned that the onset that this is an area where you have a lot of expertise, you shared a little bit about a company that you're working with today but maybe give the audience a little more insight as to how Rook quality assistance can help software as a med device companies.
Andrew Wu: Yeah absolutely. For the past few years Rook has a lot of experience helping manufactures getting their clearances for their med software and SMAD. Our experience lies on IOT devices which we have many experiences communicating with FDA with Bluetooth applications, addressing the cyber security issues and the user ability issues. Those are the hot topics and those are the critical things that FDA reviewers have been putting a lot of emphasize on. We do all sorts of things not just helping manufactures with their quality management system, we also help our clients planning, design, and even development testing and develop a testing plan even for them to stream line their process before they apply for a submission to FDA. Also I would like to really emphasize and say that we are very grateful to have had the opportunity to be partner with www.greenlight.guru. We have many success working with our clients using the www.greenlight.guru platform complete [inaudible 00:32:04] software projects and that we found this platform really allow us to keep close eye on many aspect of the projects.
Our clients also found this platform very very intuitive and very flexible for them to make the changes according to their approach to their process. We can't be more grateful to have the opportunity to work with www.greenlight.guru. On top of that I would like to highlight that the multi level design control, a new version of the www.greenlight.guru platform that was published recently ... I think Jon can definitely speak more about this than myself but on our experiences using this new platform we found it many many [inaudible 00:33:02], more helpful especially for managing software projects. It's definitely worth checking out, having a demo by Jon in particular in think that's very good news for many many manufacturers out there.
Jon Speer: Andrew I definitely appreciate you sharing that information and those antidotes about the Rook quality teams experience and helping SAMD companies and using the Greenlight platform through that process. Folks I want to thank Andrew Wu, Andrew is a software consultant for Rook Quality Systems, you can learn more about what Rook is doing by going to Rookqs.com. As always if you'd like to learn more about how the only EQMS software platform in the world that's been designed specifically for and exclusively by medical device professionals, I would encourage you to go over to www.greenlight.guru, request a demo and we'd be happy to have a conversation with you and help share with you the importance of why it is important to be a true quality professional as your designing, developing, and manufacturing, and selling medical devices. So Andrew once again, thank you so much for being a part of the global medical device podcast.
Andrew Wu: Thank you very much Jon I really appreciate it.
Jon Speer: Alright for all of you, thank you once again for listening. As always this is your host, founder, DP of quality and regulatory at Greenlight Guru and you have been listening to the global medical device podcast.
ABOUT THE GLOBAL MEDICAL DEVICE PODCAST:
![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 SoundCloud.
