Mapping IEC 62304 to eSTAR Fast-Track FDA Clearance for Medical Devices with Software

Hello and welcome, everybody. I'm Sean Smith, publisher of MedTech Leading Voice. Let's see. Today's webinar, welcome, Mapping IEC 62304 to FDA East Star Fast Track to FDA Clearance for Medical Devices with Software. Today we're joined with two subject matter experts, Jose Barroquez, President of BoldType, and Rob Packard, President of Medical Device Academy. They'll show you how to align your IEC 62304 software lifecycle documentation with the FDA's E-Star submission format, and help you streamline your next clearance. We'll look at required software artifacts, documentation mapping for different software classes, and common pitfalls to avoid.

Before we get started, I would like to make a few housekeeping announcements. Please, please use the Q&A panel for questions for the speakers. We try to get to your questions. We'll follow up with you if we don't get to them. Probably. And use the chat for questions or comments for me. If you would like a certificate of attendance, please enter your full name as you would like it to appear, along with your email address in the chat. Not the QA, the chat. And… Slides and recording will be mailed out to everyone who's registered to the same email that your Zoom invitation came to tomorrow, 24 hours following the event.

If you don't have the access code, just wait a couple hours and find it on YouTube on MedTech Leading Voice YouTube channel. It'll be there, so don't panic. let's see. Last, last is upcoming events. We have 4 exciting upcoming events. First, for those of you that did not register for the free masterclass and 5-Day Email course on initiating pre-market clinical investigations in the EU, what you need to know. please, I'm gonna put a link in for that. Also, tomorrow, very, very exciting, inside Brazil's MedTech market, what global companies need to know. This is gonna be a panel discussion. You're welcome to join in the conversation. This is one of the greatest networking opportunities on the internet, in med tech, so don't miss Friday in Focus Calls.

This Wednesday… next Wednesday, we're gonna have Building a MedTech Market Pathway, Aligning Regulatory Reimbursement and Commercialization Teams Early with Michelle Lott, Fernanda Nussbaum from TTI Health, and Renee Franz from LeanRocca. Then, Friday, next week, the 5 biggest stumbling blocks small device teams hit in study startup, and what to do next. And that is going to be with Laura Starring, next page. Laura Van Vyck and Robert Bedford from Franklin Health in the UK. Then, Thursday, November 20th, Clinical Data Transferability Strategies for Leveraging Cross-Regional Evidence.

10 a.m. with Jessica Addison, Leslie Hammer-mueller, and Richard Holbrough from BSI. So, lots of exciting things coming up. And I'm gonna put as many links as I can into the chat. I hope I don't overwhelm everybody, but, I see a lot of people joining the call, and I am going to turn it over to today's speakers. Thanks, guys, for joining us.

Thank you, Sean. My name is Jose Borquez, and I've got Rob Packard here with me. And as Sean said, we're going to be talking about FDA, software documentation, and then, IC62304. So here, I'll… Flip on, share my screen… Hopefully you can sing.

Thank you very much, Jose.

For inviting me, and…

I know everybody likes to talk about documentation, especially the programmers.

Absolutely. And by the way, like, the… kind of the format of this is going to be very conversational. Though, you know, we do have some slides that… that I'll be showing you. But they're really primarily there to kind of guide the conversation. What I'm hoping will happen is that you'll get the point of view from two people who've been in medical device development and in software within medical devices. for, you know, multiple decades, we've seen a lot of different things. We've learned a lot through our, you know. good experiences, bad experiences, and sometimes… one of my mentors used to say that, you should learn from your mistakes, but try to borrow scar tissue where possible. So, we've… I know I've borrowed scar tissue seeing where others have failed, and hopefully you'll be able to borrow some scar tissue from our own experiences.

So with that said, just quick intro on, the agenda. So I'll give you just quick background on Rob and on myself, so you understand who we are. We'll go into E-Star. some of the standards that are applicable for medical device software, and then some of the guidance documents that FDA has. We're not going to go into them all in detail, we're really just going to focus on one standard, 60304, and one guidance document, which is the one that relates to software and E-Star. We'll talk about IEC 6 through 304, and then we'll talk about just that mapping between those references, the process that you follow, and then the artifacts or attachments that come out of it. That is what your, you know, your regulatory leader or consultant is going to want from you to upload into eStar so they can submit your 510K.

And then we'll end with just a quick intro into Rob's company, Medical Device Academy. If you don't follow him on YouTube and LinkedIn and all those places, you absolutely should. Rob puts out some of the best content out there to help on a variety of topics, and then I'll tell you about BoldType and CyberMed, which are the two companies that that I head up. And then the last thing I'll say is, if you have questions as we're going through them, just as Sean mentioned, throw them into the Q&A or into the chat. We'll try to keep an eye on that and respond as best we can. All right, cool. So my background, Jose Borquez, I'm president of BoldType. Boltype does software development for medical devices, and then CyberMed, which does cybersecurity consulting. I have a PhD in electrical engineering and computer science. I've been in the medical device space for about 20 years, and I'm part of the association for

advancement of medical instrumentation, the software working group, and the security working group. And also, about once or twice a year, I participate in NIH SBA, or review panels. So, you know, startups are very near and dear to my heart. And I know Rob, the same is true, and Rob, maybe if you can give some background on yourself.

Yeah, I actually started my own medical device company, a laparoscopic imaging system company, back in 2004. And very heavy in software abuse. We were reprocessing video images from red, green, and blue stills into full-front video, and then doing intervention in between Zoom, Nope.

Playing with the lighting, so we didn't have any dim spots on the screen.

Whereas usually laparoscopic, you have this bright center and dark corners. So we did all the kinds of stuff you can do on your cell phone now for nothing, but laparoscopic imaging systems didn't do that in 2004. Camera phones didn't do that in 2004, so… after I had started that company, I learned the hard way, because my regulatory consultant died of pneumonia, that maybe this was very strategic to learn a little bit about regulatory, and I needed to know a little bit more about the pathway and what documentation was needed. So, I didn't know anything about quality or regulatory at the end of 2004, going into 2005.

And that's when I started learning it. And a year later, I was Director of Quality and Regulatory Affairs for a medical device company. And I've been there multiple times for multiple startup companies, so it's always been startup companies that I've been joining with, and 3 of those have sold and been very successful, 2 of them went public. And now all I do is just help startup companies get their product to market. So the biggest hurdle for them is, how do I do all this paperwork for quality and regulatory? And so that's my goal, is to help 100 companies a year for the next 20 years to get 2,000 products to market.

That's amazing. Yeah, and I think we share that passion for startups. I also kind of grew up in the startup world, having either worked or led startups in the earlier part of my career, and I think… it's the funnest place to be, because that's where a lot of the innovation is happening, and things move a lot faster, and you're kind of trying to move fast and not break things, right? So that's… that's where I think both Both robs.

Full breaking's okay.

A little braking is okay, especially if you've got a good recovery plan, but, you know, hopefully not… nothing that's gonna hurt anyone. So, E-Star Form… Rob, I think your email has the word FDA E-Star in it, so you're, like, I would say Chronicles.

something about it?

Yeah, I'd love to get your thoughts on eStar. When it came about, like, how… like, what do you think about it in general? And then maybe we can talk about, sort of, when your medical device has software, what does that mean from an eStar standpoint?

So, just so people know some of the basics… It's a PDF form. It's a protected PDF form that you cannot.

Manipulate and change the way it works.

you have to have Adobe Acrobat Pro to make it work. There are a couple other software tools that they try to make work with it. But they're always fixing the bugs because it doesn't work with those other ones well. So, do not do that. Don't use somebody else's cheaper software. Spend the 20 bucks a month to get Adobe Acrobat Pro until your project's done. honestly, for the amount of rework I had to do with a couple of clients, I would pay you 20 bucks to get Adobe Acrobat Pro. At least one person in your company. So, but the E-Star stands for Electronic Submissions, Template, and Resources. On the left-hand side is where they have the little blue add attachments. That's where you attach your documents. If there's a red line next to it, it's not optional. If there's a gray line next to it, and you notice none of the software section is gray.

If you have software, and you want to try to avoid a piece of documentation that's on that list, you can't. It won't be allowed to submit. You won't even be able to upload it, because they validated, so you can't. Pretty smart techniques. It eliminates the need for a checklist. And then on the right-hand side, they have these little help buttons that are little blue buttons with a question mark. That's so… I don't know what the hell that is. You just click on… click on that, question mark button, and it tells you what it is, and the one at the very top gives you 3 guidance documents for software.

So, I think it's 3, but… All the guidance documents are in that section. You just click on the help button, and it gives you a hyperlink, and you can download it and read it. And then each of the individual items will have additional comments that are probably copied and pasted again from the guidance. But if you have One document for all your software documentation. That's gonna be a nightmare for you, because you're gonna have to split it up into all these different ones. To answer your question about, do I like it, or what do I think about it. I mastered the old system. And so you're thinking, I don't want to change, I don't want to change, nobody likes change.

Well, I had all my templates working perfectly, everything was running smoothly. I said, okay, guys, as soon as this is available as an E-Star, we've got to tackle this and learn it, because it's going to be so painful to learn. And the first one we did took just as long, if not a little bit faster than a normal one. The second one took me half the time. And every single one has gotten faster since. So, if you're doing an FDA star and you're not hiring a regulatory consultant. It will probably take you the same amount of time as it would have taken to do it the old way. But you probably won't have to look up the directions as much, because they're on the form.

For me.

Hands down, this is so much faster than the old way. And now that everybody has to do it the same way, the FDA doesn't have to play referee well This company has to do it this way, but it's not so important for the… everybody has to do it the same way. Everybody has to use the same form, the template, and everything in terms of what has to be attached is right there. So I… I love that part about it. There are not… it's not perfect, but nothing ever was.

Yeah, I kind of do it almost like paint by numbers, right? And, you know, you made the point, like, even if you've got a regulatory consultant, which, frankly, if you're a startup, I 100% think you should have a regulatory consultant who does this all the time, so they've seen everything, so just call Rob if you need somebody. Even if that's the case, I think entrepreneurs should still download this form and just kind of look through it, because the first time you look at this form should not be as you approach submission. It should be, like, as you're starting your project, so you understand what FDA is looking for. You know, as you mentioned, Rob, I mean, this shows you the guidance documents that you should be looking at. When you click on those question marks, the text in there is almost verbatim, or usually verbatim, from the guidance documents.

So, you know. there's lots of guidance documents, there's a few that you absolutely have to read, and I do think it's a good idea. The other kind of interesting thing about the E-Star form is that at the beginning, there's some check marks and selections you make. That's one of the things that catches people off guard. You know, we're not talking cybersecurity today, but Once you check that your medical device has software, it's like, boom, the 12 cybersecurity attachments come up, so you understand that, you know, FDA's gonna be expecting those too. So between software and cybersecurity. There's about 24 different attachments associated with that. There's, like, 22, but then interoperability comes into play, and then there's labeling.

So there's lots to it, and it's a great idea to look through it. The other interesting thing about the fact that it's interactive is that you can see what shows up here is 10 different documents, but this drop-down is where you select whether your software is basic or enhanced, and if you're basic, one of these goes away, which is the software design specifications. So the form in general is interactive like that. But what I thought we would do is… you made another really good point, Robin, and I think it ties into the main story of today's webinar, which is that we always advise people Try to build your SOPs in your process so that the output matches, like, the attachments for the form.

Because, like you said, we've seen this where it's like, well, you know, we kind of have a single document that has our architecture and our software design specification. It's like, well, just break it up into two, you know, and change your process so you naturally have two documents. Or, yeah, so just do things… make it as easy as possible for the reviewer to know exactly, like, what to expect in that document, and your review process will go a lot smoother.

There was a question in the Q&A, so if you have any questions, put them in the Q&A. We'll both be monitoring that. This one is an easy one. Is there an updated form available for the QMSR? And the answer is no. Because the 510K submissions are not about your quality system. there about the VNV testing for your device. So, the only place that it would really relate to quality system as it relates to software is right above I'm sorry, right below the software design specification that Jose was showing.

Right below that, it says Software Lifecycle Processes, Management Maintenance.

That's where you're going to put in procedures. If you look in the QMSR, it doesn't really say anything about software in there, other than go see ISO 1345-2016, and if you read ISO 1345-2016, it doesn't say anything about design of software. It talks about validation of quality system software, it talks about validation of calibration software. It talks about equipment like sterilizers, that equipment being automated, validating that. It does not talk about 62304 other than, no, go see 62304. So… You don't have… there's no updated one. There is a version 6.0 that came out October 1st.

So you have to be aware that they do update this periodically, and people… I can guarantee it will be updated in the middle of your project at least once. There's an export-import button at the bottom of the form that's pretty easy, and if you don't know the shortcuts on how to get all your attachments over, call me up and I'll show you. It's the best half hour ever you spent. You have some attachments in there, you need to upgrade to 6.0. I'll show you in a heartbeat how to do it.

Perfect. Good, alright, cool. So moving on from here, I debated whether to include this diagram, because the idea is not to freak people out, but there is a lot of stuff that you should be aware of, and you should read, or somebody on your team should know, and it can be your extended team. What I'm showing here on the left in pink, is a variety of standards that are particularly important if your medical device has software. So, as Rob just mentioned, ISO 1345 for quality management systems. 14971 for risk, and then 62304 is kind of like the main software-focused standard, but 62366 around usability is also relevant, right? Your medical device has to be usable, the software has to be usable, and then SW96 is kind of the new kid on the block.

It's related to cybersecurity. It's the successor to a couple of TIRs, 57 and 97. And then there's… there's a variety of other ones. 8002-1 is really… I find it very helpful, right? It's kind of showing you how to apply 14971 to software, because they're… they're similar, but it's not the same process, so that's a good one. And then FDA has a lot of guidance documents. You know, this one here, the content of pre-market submissions for device software functions, is a really critical one. It's kind of the one that explains to you what goes into the E-Star form. But, you know, lots of other ones around off-the-shelf software, around

you know, of course, the cybersecurity ones. This one for validation's 20 years old, but it's still, you know, important and active. So lots to be familiar with. Rob, I don't know any, any… Tips that you give clients as they try to navigate all of this?

You had a really good point earlier. Don't wait for the very end of the process to look at the E-Star. Same thing is true for all these standards. That's all the… this entire slide is what Design Inputs is all about. you need to understand these standards and their impact on your device. Some of these don't apply to your product. I don't know of any product that has all of these.

Right.

And also, even if you have one that applies, not all the clauses in it apply. For example, if you have a Class B device, all the parts of 62304 related to these Class C devices do not apply to you. So, you need to read each one and understand whether it applies to you or not, and if you feel overwhelmed when you see a list this long. That makes sense, because you probably can't develop an entire product all by yourself. You probably have a design team that does that, and you might even have some suppliers carrying some heavy loads for you, too. You might have somebody doing cybersecurity, somebody doing software documentation, maybe somebody's doing the mobile app and you're doing the web-based.

So you divide and conquer, and that's exactly what you should do with this very long list of standards, is divide and conquer. But it would be at the design input stage of your design process. Not that I'm telling everybody to use the waterfall process, because I'm not. I'm just saying, when you have a list of approved inputs at the end of the day, that list of inputs should include most of this list.

Good. Alright, cool. So, so now if we get it into 6-304 itself, we're talking about this with Rob earlier, that, you know, some people, like, it's almost like they're nervous or scared to look at 6-304, and the part of the standard that's really relevant is you know, maybe 20 pages long, and really, the main, main portion of it, which is clause number 5, is literally 10 pages long, right? So there's, like, the software development process, if you look, it starts on page 22, and ends on page 32, 10 pages. And then you should read through the risk management process, but that one is only 3 pages long, right? So, it's not so long.

Now, it's good for somebody on your team to understand all of it, because it's not like, you know, software configuration management doesn't matter, it does matter, and it's part of what you're telling FDA about. But… most of the people on your team who are touching software should spend the 20-30 minutes it takes to read at least through those 10 to 15 pages, and get a sense of what 62304 is trying to talk about. And… you know, like, I'm gonna skip through some of this thing and just kind of get to the punchline here. 60304 is about process, and the general principle is that if you follow a good process.

it's more likely to end up in good software and a good medical device than if you're sloppy about it and you're just kind of doing it haphazardly. But Rob, we'd love to kind of get your thoughts on Like, how you think about 6 and 304, and how you help people with that?

For 62304, I really like… giving people tools in that info diagram that you had, where you had 5.1, 5.2, 5.3, you went through all the sections of 5, and then you just had an arrow that went across and said, here's all the requirements for attaching in the 510K. Understanding that those are almost one-for-one is really helpful. And… people have said to me, but it's this iterative loop, how can you do that one for one? And, like. Well, because you revise the documents, just like you revise your software. So, I asked a question to Jose earlier when we were in the practice session at the beginning, and I was like, Jose, do you…

Do you approve the documents at the end, or do you approve them at, Not approve them and have them as drafts, unapproved, and then, and edit them that way. So it was like, how do you do the approvals of these documents? And he and I have seen different ways to do it. But, it's really important to think about, you have these 5.1 through 5.8 error requirements of 62304. That tells you how you develop software and how you document it. And they're… they're shalls, and the FDA requires that you say you actually follow that. And then over on the other side. for the documentation, they're asking you for the end result. Please attach it.

Yeah, we'll touch on that a little bit, too, on just kind of, like, how those two end up mapping. Something also that trips people up is, you know, they're used to hearing that their medical device is either Class 1, Class 2, or Class 3, and all of a sudden, they get to 623 or 4, and they see that their software is either Class A, Class B, or Class C. And then they go to fill out their E-Star form, they say the software is basic or enhanced. So I'd say that the simple one, you know, just forget Class 1, Class 2, Class 3. There's not a one-to-one mapping. Obviously, there's correlation. If you're a Class 3 medical device with software, it's more likely that you're going to be Class C.

But it's not, you know, it's not a one-to-one mapping. The big question, and we'll look at the flow chart next, but is, you know. If the software could fail, and no damage, no harm, no injury is gonna happen to somebody, then you're Class A. In our experience, it's quite rare. I would say that the majority of software falls into Class B. And very little falls into Class A, and then, like, some proportion into Class B. And, I know, Rob, you've got maybe some historical statistics on that, at least in your experience. Class B is… you could cause injury if there's a failure in the software, but it's non-serious.

And then Class C is, like, death or serious injury could be possible if the software fails. And we'll kind of look at that in a little bit more detail, but just as a frame of reference, understand that that's the classification, and as Rob mentioned earlier, that classification maps to subclauses that either are or are not applicable to your specific device. We'll look at that, in a minute, but… But that's… that's the gist of it. Okay, cool. Yeah.

For the 62304 classifications, I would say it's maybe… Less than 10% of products that are… go to the FDA are Class A. no matter how much you say it's Class A, the FDA is pretty much not regulating Class A's. They might have them as a Class 1 510K exempt. But if they're reviewing it as a 510K, it's probably not a Class A. Just a rule of thumb.

No, that's great.

Less than 10%, single-digit naps. The Class C, that's not the case. There are a lot of products out there that the FDA definitely thinks are Class C. You and I might not agree on that, but the FDA wins on a lot of these. They're saying they're Class Cs. And they're even worse on the Enhanced, so… as Jose said, we have ABC, and then we have basic and enhanced. the enhanced, they are more likely to say it's enhanced than your IR conservative. They're bureaucrats. They don't want to make… when in doubt, go… go tougher. So, I would say there are definitely more C's than there are A's, but B is definitely the fat middle.

And there is definitely more, basic out there than I think there is enhanced. But it's not an 80-20 split, it's more like a 60-40 split. So I would say there's 60% basic and 40% enhanced. And I think companies… A lot of times, just by not doing a really good job of architecture and risk controls make the FDA really nervous and push themselves to enhance sometimes.

That's a good thing to keep in mind. It's like, if you're in doubt, if it's kind of on the edge, you're probably better off, treating it as enhanced. We'll talk about what those differences are, and it's not like it's the end of the world. But you're definitely going to be more rigorous and comprehensive. There's a spreadsheet that we made internally for our team. I'm happy to share it with you, just if you want a copy of it, just comment spreadsheet in the comments, and we'll email it to you. But, you know, when we're looking at East Star versus 62304, and the classification, you know, as Rob alluded to this differently, as you go through that standard, there's gonna be little brackets that'll say A, A comma B, A comma B, C, or just B and C. Well, actually, if it includes… they'll include C, right? C, you require everything.

Fewer number require B and fewer number require A. So, as an example, something like, you know, software development standards, methods, and tools, you know, that's only required if you're Class C. Something like, you know, the different types of testing, for example, might be required for different ones, so your software supporting items to be controlled, you know, having that documented is only required if you've got Class B or Class C. So, you'll look through that, and you'll see that the higher the classification, the more of the clauses that apply to you. But, you know, as Rob mentioned, like, one of the things you can do through here is go, hey, we know we're Class B, okay, filter out all the Class C stuff, you don't necessarily need to worry about that.

Sometimes it's a good practice anyway. There's products that we develop, you know, as an example, unit testing, right? Unit testing is not required, you know, if you're Class A or Class B even, but it is for Class C, and it is for an enhanced documentation for FDA, you have to actually submit the unit testing, results. Like, you're not just providing a summary. So, being aware of that early, so that you incorporate unit testing into your system is really important. You don't want to get to the end of your development process and then realize that FDA is going to ask for all your unit test documentation, and you didn't do a unit testing. You're not going to get the benefit of it, you know, it's beneficial to do it, and it's going to be a lot more work.

But, I don't know, Rob, anything else that comes to mind?

didn't have anything else. We had a couple of questions here I was trying to answer.

Okay, cool.

There was a really good one in there about the, The new version is 62304.

Oh, yes.

I know you… you personally are, very up-to-date on that. I made the comment, they were asking if the E-Star is likely to change, and the process is likely to change with the new standard, and I would say absolutely yes. But at the same time, it'll also absolutely say that it's not going to happen in 26, because the FDA takes 6 to 12 months to recognize the standard to start with, and we don't know how it will impact it yet.

Yeah. Yeah, and one of the things that happens in the next version, what's expected, is there's also going to just be two classifications. But from what I've seen, it's not a match of basic and enhanced versus the two classifications that will be in the new version of 62304. It's almost like… The mapping right now is pretty close. I think that's one of the upcoming slides. It's pretty close to Class C, is definitely enhanced, and then Class B is, like, maybe 20% or 30% of products that are Class B would still be considered enhanced. That's… I mean, that would be my estimate. Rob, I don't know if you've got a different one.

I think… I think that's probably true. What I… what I really wish they would do is come up with a little bit better guidance at the FDA, On how to migrate from what the standard says. To what they're using, or just… Marry themselves to what the standard says. And it seems like this is an opportunity, but doesn't mean they'll agree with the new standard.

Yeah, good point. Yeah, so, so, you know, the verdict is out, because it's not out yet, but, I can tell you that it's not going to be a perfect match either. You know, you kind of have to perform the analysis from FDA's standpoint when it comes to enhanced versus basic, and as Rob has been saying, like, you want to do it early in the process, because you don't want to then have to go back and retrofit your design history file. From a process standpoint, this is kind of a high-level view of the process. This is Figure 1 of 62304. You know, they're saying, look, we don't… we don't regulate, like, this is not relevant for… directly relevant to 62304. It's not what 62304 is about. It's not about customer needs or the system architecture, but that feeds into…

The software development process. And, you know, a couple things to note. One of them is that software risk management is seen across the entire lifecycle of product development. It's a point that they make here, it's also a point that's made in, In, 8002. where it says, look, this isn't an exercise you do once. As you go through the development process, you're gonna realize that there's new risks that arise, maybe because you made a certain design decision, or during your testing, you realize there's a new thing. So risk management really traverses the entire process. And then there's sort of an implication that this is a waterfall model, right? You do first the planning, then the requirements analysis, then the architecture design, then the detail design.

then unit implementation, integration, system testing, software release, but there is allowance for having a more agile approach in this. You know, and there's a good There's a good standard. Technical reporter around that, to look at, but… you know, you can kind of… like, if you're going to do in sprints, for example, then for any given sprint, you might want to say, okay, what impact does that have on the architecture? What is the design of the thing that we're going to build in the sprint? And then you build it, and then you test it, and then you go to the next one. So there's still this idea that you should have.

Requirements, architecture, design, implementation, test. And then, you know, the other one that… or the other two things that are true along the whole cycle are… configuration management, and then software problem resolution. That's just something that's happening along the entire, software development process. So, so it's all about process, all about, like, these are things you should be doing. And of course, artifacts are dropping out of this.

There was a… A couple of things in the chat. But before I get to those, I wanted to say… this is always going to be iterative, and with software, it's one of the few areas, because the cost of verification validation is not nearly as expensive, usually, as something like electrical safety testing. You can usually test something out on a prototype. And go through the whole testing plan. and have it fail, and go back and make corrections and modifications. You can't necessarily afford to do that when you're spending $100,000 in electrical safety labs. But you can guarantee that your product owner is going to add a feature at some point.

Because you had customer feedback at one of your reviews that said. oh, it would be really cool if it had this feature, and everybody's like, oh, yeah, you're right, we gotta add that! And… Or you realize the software doesn't really work the way you want it to without that feature. Or, whoops, we didn't read the cybersecurity section where it says we have to have these 8 controls. So all those… all 3 of those examples, you have to go back and add requirements And now you have new SRS, you have new SDS, and you're doing a lot more work, so it's always going to be iterative. I would say that the same is true of hardware, but people deny that and say it's not true, and then I see them make edits to their design and make new prototypes. So, I think it always happens, and all design is

a hybrid model of iterative and phase gate, but software especially, you're gonna always have people adding stuff on. The comments I was going to make about what's in the chat, somebody said, or a couple people said, please send me the spreadsheet. put the spreadsheet request in the chat, correct, Sean?

Yeah, we should be able to find them in both places, but…

Okay, beyond both places. And, I… I really think that… that… This particular slide is really helpful to people to see that the process.

What comes first, what comes second, what comes third, but if they understand that it's iterative.

That… that's the key piece of understanding is, yes, it's linear, but at the same time, you're going to have to go back and fix things and try again.

Yeah, no, absolutely. And I think the… and again, like, somebody put this in the chat, thank you, I was blanking out on the number. TIR45 is all about Agile, so thanks to Rama. about you incorporating Agile into 62304, you can have sprints, right? It's just, within those sprints. You shouldn't be designing something if you don't have requirements around it, right? So, so you're gonna wanna, within the sprints, like, what are the requirements of the thing we're building? Because how are you gonna test that the thing you built works if you don't have requirements to test against. So it's this notion of, like, you know, you're gonna have a.

I should have done.

Yeah, exactly. What's the definition of done, if you don't have requirements? And during testing, you know, as you said, you might discover, hey, there's, like, a change that we need to make that we're finding because of that. That's okay. So the next sprint, you just update the requirement. One of the sort of tips that we were discussing with Rob earlier is. You want to make your approval process really… as easy as possible. You know, you want to… you probably don't want to have 12 people signing off on an architecture document. You don't want to have, like, you know, very cumbersome processes, because then people just will try to skip them.

You're much better off saying, let's have these as living documents that can be easily up-revped, so we've got a snapshot of what was the architecture that we designed these features around, and we did this testing around. So, you know, it's not to say that it's the only way to do it, but I know on our end, and when we're doing software development, what we try to do is, you know, we try to put together a preliminary version of requirements early, sign off on it, go, like, we know these things have to be made, so as we start building some of the features, we're building them against requirements.

You know, put together your preliminary architecture document, sign off on it, and then just kind of get over that sense that once it's signed, it's set in stone, it is not. Like, it's just one revision. Just… if you need to change it, just upright it. Should be easy.

I think this would be a good place for me to mention Or explain what value-added auditing of software is? A non-value-added auditor says, your procedure says this, you didn't do it. Or, this standard says this, you didn't do it. Or worse, they come up with their own opinions and force them on you and say, well, this is the best practice, and you didn't do it that way, and here's your nonconformity. Those had absolutely no value. What adds value is when you're doing an internal auditor, or internal audit, or a supplier audit, and you go in and look at the way they're doing their documentation, say, how long did it take you to get from here to here?

You know, like… Something's wrong, and like, why haven't you signed off on this document yet, or why don't you have this documented yet? And you start to understand how their process is, and you realize either they're approving things too early, they're approving them too late, they've got too rigorous of a process for review and approval of something they're going to change multiple times. So you have to make your processes streamlined and easy to update and revise, just like you've done your code. You have configuration management and version control of software. You have to have a quality system that works the same way.

It's absolutely essential for software developers to have a robust. streamlined, streamlined, I emphasize, process for software documentation, where you create the documents because you know you need that, and you make it easy to revise and approve. So, it evolves with your software, and there are several different ways to do that, and a good value-added audit can help see where you're inefficient and slow, or completely not meeting a requirement, and give you advice, because there are An internal auditor, or a second-party auditor doing a supplier audit of a software party… And not a third-party certification body that isn't allowed to give you advice.

And if you're not sure how to do that. Couple options. One is hire an outside firm that does a good job of that. And we have a couple people that do that, but if you want to learn how to do that, if you want to have somebody on your team that does auditing learn how to do that, we have a course that we're launching in December, and if you want to be on the waitlist, just type in the comments or the chat here. waitlist. Wait list. And we'll… we'll get you on the waitlist. And you can take that course, and you can take it as many times as you want, as new standards come out, like 62304, the new version, we're gonna have updates to the course, and all those are free. So you buy it once, and you get all the updates for free.

Yeah, that's… that's great. Yeah, that's great knowledge to have. I mean, I know you spent part of your career as an auditor yourself, and I'm sure that was hugely valuable to now helping people put these things together. That's something I tell people all the time, too, is like, you know, there's… Startups, right? We mostly deal with startups, so when I say people, I'm mostly talking about startups. we tend to focus on getting FDA clearance, but that's one time you're going to interface with the FDA. Like, another time you're going to interface with them is when they come knocking and audit, you know, your SOPs and your, you know, your facility and everything else like that. So it's not like we're cleared, we're good.

you know, there's still gonna be… there's things that you don't submit to FDA during your 510 submission. that you still are responsible for doing, and so making sure that you keep your design history file and your quality management system in good shape is, is critical for long-term success. It can be too, Too short-sighted. Alright, we got 15 minutes, so I'm gonna move on here real quick. I saw that there was a question earlier, and I wanted to touch on it. So, you know. when you're going through 6, 3, or 4, that… this is the decision tree for that, right? It's, you know, you start off, and you… you're starting off with the assumption you're Class C, right? So, as Rob mentioned earlier.

from a regulatory standpoint, you always kind of want to be a little conservative. So you start, you go, okay, class, you're probably not going to be, but start with that assumption. And then you ask, can a hazardous situation arise From a failure in the software. And one important thing to note here is that this isn't like, is it likely to? You know, like, what's the likelihood that it could result in this? It's like, is it possible? that a software failure could result in a hazardous situation. And then, if it is, then you evaluate the effectiveness of risk control measures external to the software. You know, so you can't be like, oh, we're gonna add this, you know, routine in the software, there's this, you know, this part of the software that protects it. It has to be outside of that software.

Oh, and then you ask yourself, does the failure of the software result in unacceptable risk? And then, what's the severity of the risk? And that's what's going to tell you, is it Class A, Class B, or Class C? And in determining this, you assume that the software is going to fail. It's not like, you know, your 14971 risk management, where you're… you've got probabilities of whether or not it's gonna happen. FDA's telling you, like, assume the software is going to fail. Okay, what's the worst case harm that's going to come from that failure? So that's the 6-304 lens. from an FDA standpoint, it's a little bit different.

They're saying enhanced documentation should be provided for any pre-market submission that includes software device functions with failure or flaw of any device software function could present a hazardous situation with probable risk of death or serious injury. So, it's pretty similar, right? But it's… it's more tied to class… that's what we're saying, we're sort of, like. captures all of Class C and a part of Class B. But, you know, Rob, I don't know, you see a lot of these, and I know you mentioned earlier.

I actually have a good way to handle that I use as a rule of thumb. I use it for risk management in 14971, and I use it also for software. And it answers one of the questions that was in here. And I hope I answer your question, so I'm going to answer… say, quick answer live, but hopefully I'm answering. If not, go ahead and clarify what you want to know. But I say. Use a 5-point scale, because that's what the FDA is most used to, and if you have a 10-point scale, you spend a whole bunch of wasted time arguing over whether it's a 5 or a 6. The smaller the scale, the less arguing it goes on. And then I say 3s, 4s, and 5s could be reportable.

Ones and twos are not. And reportable events are something that could result in a serious injury. So, if you're saying the… it's a 3, Then you're saying it's a serious injury. Some people don't like that scale, but I find that a lot of things that people want to say are twos. the FDA says it's a 3, and a lot of things, people say, well, that's not a serious injury, the FDA disagrees. So, I tend to go with 3 is a serious injury. 4 is a permanent disability, and 5 is death. And usually people get that pretty well. Serious injury, permanent disability, death. Could it happen? And it's not just directly from your device that's software, it's from the hazardous situation that results from it.

And if you're looking for examples, the best place to look is not 14971. Because that was not written for software at all. It says that it applies to software, but then they have a separate guidance document that's actually helpful. So go to the 8002-1 standard, it's IECTR 80002-1, go there, and Jose's pulling up, and I think he had it mentioned in his slides. Pull that up, that's really, really helpful. And it has 6 pages of examples of hazards in there. So, go there, and you… it'll really help you master how to document risk and hazards for, software, because 14971 really doesn't do it justice for software.

And in fact, kind of like the parallel advice is in the FDA guidance document, this contents of pre-market, one of the last appendices, like, towards the end, it's documentation level examples. This is almost like a fun game you can play with a couple people on your team. Sorry, where it gives you a bunch of examples, and then tells you the outcome. So, like, a non-invasive blood pressure monitor with inflatable cuff gives you a description, gives you a rationale, and it says the outcome, basic documentation level. And it's got… it's got, like, a couple dozen of these, you know, where it has both enhanced and basic.

So that's a really good way of… I'm really glad they did this, because it's one of the hardest things to go, like, well, what about this? What about that? You know, this gives you a lot of examples. It's not foolproof, right? Your device probably is not going to fit exactly into one of these, but at least it gives you a better sense of what their expectations are. Alright, let me… We gotta lose my slides now. Where'd they go? Give me one second… Alright. Okay, cool. 10 minutes left. Okay, so here's kind of how we recommend having this relationship between these standards… so let me kind of walk you, orient you through the slide. So you've got these various standards, 6 to 304, 14971, etc. You've got all these various software guidance documents. You've got a couple of cybersecurity, guidance documents.

As you're building your SOPs, or working with a consultant, ideally, they're built to sort of meet the needs, or the requirements, or the processes that are dictated in these standards and guidance documents. And what they're for is to guide that software development process and cybersecurity process. So that at the end, you have these 9 or 10 software attachments, and these 12 to 14 cybersecurity attachments. And really, you know, at the heart of this is these SOPs. And you kind of want to start… with both the beginning and the end in mind. So the beginning being these standards and guidance documents, and of course the regulation.

And then the end being, like, what are the deliverables going to be to FDA during the submission? And make sure that your SOPs are designed to meet both needs, so that as you're going through the process, these documents that are kind of dropping off of the process, you don't have to, at the end, massage them all to match what FDA is looking for. Just to kind of give you a real quick example, like, this is part of our SOPs internally for software development at Bolte, and, you know, as in the software development process, you know, you'd be starting. So this is… this is not the entire process, because there's a planning phase that starts before this, but once you get into development, you do your software requirements analysis. That's a process, that's a thing you're doing. The output would be your software requirements specifications.

and your SRS verification. Because, by the way, in 60304, you're not just verifying the end product, there's, like, verification of documents. So, like, you're verifying, for example, that your architecture lines up with your requirements. So when you do your software architecture design. And that output would be your software architecture document itself, and the verification that it meets the requirements, or it's going to. Then the software detail design, if it's applicable for you. Well, that's a process and a result. And here's one of the, I think, key, important insights. The reason 62304 exists is because

Industry recognized that if you just start writing code, you're not gonna end up with good software. That good software comes from a process where you take time to really understand the requirements, take time to architect the whole system. Take time to, like, think through how you're going to design each of these units and subsystems. And then, start coding. Their objective, and FDA says this in the guidance document, is that no developer should ever, like, just sit down to code. making a bunch of design decisions as they're coding, there should be a design in place that they're following, where by the time they're writing code, it's almost paint-by-numbers. Like, they've already kind of thought through how different functions are gonna work, how they're gonna tie together, how they're gonna integrate together, what unit testing they might have to do.

And so you're following that process. And if you structure it correctly, again, these outputs of these processes will be ready to go into the E-Star form. At the end of it. So.

I had a quick question for you about your procedures. Do you have… your CAPA process integrated, Incident responses, or are those two separate processes?

That's a good question. I haven't looked at that in a little bit. But I think we've got the CAPA process as separate, but it's linked through, through the software problem resolution process. But how do you, how do you typically recommend, clients do that?

Well, I… Some clients really want to minimize the number of procedures and consolidate things. And when cybersecurity documentation from the FDA got added on in 2023, we found a lot of companies coming to us saying, we need procedures for this. And the first part was the stuff for their 510K, And that's 12 documents. But then, afterwards, some companies actually have cybersecurity incidents. That really does happen, it's not a myth. And so, when you have cybersecurity incidents, you have to have an incident response plan. And they're, they're like, deer in the headlight, what do I do? I'm like.

this is… this should not be your first fire drill. You should have figured this out beforehand. And so, I hope most of them have a decent CAPA process. And I've often thought maybe for the people that really have not had to tackle an incident response before, and I know you have, but a lot of people with a startup company, maybe they've never done it before. So, tackle it like you would a kappa. I'm like… We have this problem. what are we gonna do to investigate, to figure out what the root cause is? Oh, we need to contain it first! Let's contain it! So… and then we gotta recover… that's part of the containment, like, we gotta get the customer back on their feet with the software, and recover their system.

Yeah, we've found that it's… like, in our case, we tend to include that in the cybersecurity management plan, because, you know, SOPs tend, you know, are for, like, the whole company, and if you're doing multiple projects, they're incorporated into it. So, what we'll have in the SOPs is, like, hey, you need to make sure that you've got a cybersecurity risk management plan. Or cybersecurity management plan. And that it includes these various elements of it. But the thing that you would do, the game plan. if an incident happens, is not in an SOP, it's in the plan, because it's specific to your particular… to this product, right? It's going to be very nuanced, depending on the components and the architecture.

and the risk level of that specific product, etc. So, what we put in the SOPs is, like, here's what you'll want to include, and then what you're going to do is more in the plan itself.

That's a really great idea. I like it.

Yeah, it's a good way to… Okay, cool. I think this is almost the last slide. You know, this is sort of the piece de resistance of, like. how they map, and it's not a perfect mapping, and there's a couple little notes here. So, you know, 62304, you've got this software development planning process. And then one of the deliverables is this software lifecycle process description, and there's… it's a longer thing. One of the things you can do is actually have a declaration of conformity to the FDA-recognized version of 62304. So that's one of the benefits of your company having SOPs that are designed around 62304, and following that process.

You know, if you do, you can declare that conformity, and you have to provide all of that. With everything else, you do provide the outputs, but, you know, your software requirements specification, that's an easy one. I mean, that one comes right out of your software requirements analysis. Your system and software architecture design chart would come right out of your software architecture design process. Your software firmware description is not really something that 62304 calls for. But if you've got a good architecture document, and the requirements for 62304 for your architecture process are a bit more in-depth than actually what FDA calls for. So you should have enough detail in that where you can

Fairly easily come up with that description. The analysis of software contributing to hazardous situation, again, that's that Clause 7, 60304, would be part of, but it's not going to be sufficient for your risk management file And then it'll feed into your documentation. level evaluation. This is not something that 6 to 304 directly would guide you to, because they view it differently, but the analysis that you do as part of that software classification of ABC will be helpful As you then make the determination around, level of… around the documentation level. Software detail design, again, like, that maps directly if you're… if you're enhanced, which is typically Class C, but as Rob has said, not always.

And then your software unit implementation and verification, your integration and integration testing, and your software system testing. Those are combined into a single kind of thing you deliver, which is the software testing as part of verification and validation. And, you know, what we do is we provide both the protocols and the results. If your class, if you're basic, you only need to provide a summary of unit testing if you needed to do unit testing. If you're enhanced, you actually need to provide, like, a much more comprehensive Like, the actual results and, like, an explanation of all the results when they were executed, that kind of thing.

And then lastly, you know, your software release, which is part of 60304, some of that would feed into your software, version and revision history. And this unresolved software anomalies, it's part of, like, this might be part of your package, of your software release process. Of course, it's also going to be, Fed by your… each of the different types of testing that you did. So I've got a whole article on… actually, I got an article on this on our CyberMed website that you guys can check out. But here, as we wrap up, real quick, I know you're probably coming out, Sean, to tell me we gotta wrap it up. Rob, quick thing you want to say about Medical Device Academy, and what you guys do, and how people can find you?

Yeah, the… Medicaldeviceacademy.com is the website, all one word. We have a very large website, so there's… 150 different pages, then another 250 posts. We have a YouTube channel with almost 700 free videos you can watch. And in December, as I said earlier, we have a lead auditor course that you can take. It's on demand, at your own pace, take it from home. And you can take it as many times as you want, including refreshers, next year or the year after. You only pay once. If you want to be on the waitlist, just type waitlist in the comments, and we'll hook you up with this is when it's available. But it's going to be December 1st is the pre-orders, and then the… it goes live December 19th.

Awesome. And then on my end, you know, as I mentioned earlier, I run a company called Bold Type. We do medical device electronics and software, all medical devices. I do host, like, a workshop. It's an invite-only workshop about once a month, where I'll only invite, like, 8 to 10 companies. It's meant to be a lot more interactive. It's primarily focused towards startups. So if you're a startup, trying to learn this stuff better, just comment workshop, and I'll add you to that invite list. And then cybersecurity, CyberMed is a spin-off of BoldType. It came out of… we have very deep cybersecurity expertise on the team, so if you ever need help with cybersecurity, whether it's preparing the documentation or doing fuzz penetration testing, all of that, you know, reach out there.

Here's our contact info. For me, it's jose at Bulletite.com. For Rob, it's rob at FDAESTAR.com, and then you saw Lindsey's contact info as well. I'm guessing Lindsey probably responds faster, Rob, or…

Yeah, she… she answers it every day, and I'm always behind on emails, but Lindsey, there's… on our Contact Us page, there's actually a button you can schedule meetings with me or Lindsay, and so if you have… just schedule a meeting with one of the two of us.

Perfect.

And I would like to add that, Rob's going to be joining us on MedTech Leading Voice Exchange Friday in Focus. I think we said December 5th? Yes. And so, if you liked hearing Rob today, and you want to hear more about the Lead Auditor Program, and you're not sure, that would be a great time to come and test Test it before you buy it. Yeah?

Absolutely. December 5th. And that'll be after the pre-order, so you can get that nice big discount.

Yeah, so stay tuned for, More… more links, more announcements, plenty of great stuff coming up. And also, lastly, I'd like to say, if there's anybody on the call that, would like a, you know, specific topic covered, please feel free to reach out to me. You know where to find me on LinkedIn. MedTechLeadingvoice.com. Thank you both very much today for your participation, and to the entire audience for giving up an hour of their time.

Yes, thank you all, and I know David's asking for a TIR number. I think it's TIR45 is the one you're asking about, maybe on… on Agile. So, one last answer there before we go, but thank you all also for joining. Thank you, Rob, for joining as well.

Thanks for having me.

Have a great… have a great day. Bye-bye.

Bye, guys.