In this episode, Sandra Rodriguez, an analyst at Axendia, dives deep into the complexities of Computer Systems Validation (CSV) versus Computer Software Assurance (CSA) in the MedTech sector.
She discusses the FDA's draft guidance from September 2022, the industry's response, and the practical applications of it all.
The conversation also covers the evolution of software validation processes, the cost of system implementation, and the importance of critical thinking in Quality System Regulations. The impact of AI on Quality Assurance, the changing dynamics of the CSA Modern Validation, and the role of Software Assurance in the life sciences industry are also discussed.
Listen now:
Like this episode? Subscribe today on iTunes or Spotify.
Some of the highlights of this episode include:
- The evolution of software validation processes, the cost of implementing a system in the life sciences industry, and the role of critical thinking in Quality System Regulations.
- FDA's draft guidance from September 2022, the industry's response, and its practical implementations
- The cultural shift and challenges that accompany the transition to CSA Modern Validation.
- The evolving relationship between life science companies and their technology vendors and how it can bring value to the organization
- The pivotal role of Computer Software Assurance (CSA) in the life sciences industry, including the unintended consequences
- Cybersecurity and how the FDA is looking to adopt this approach across multiple agencies
- How companies can stop spending resources on testing every feature and function
- The industry's shift towards automation and data-driven processes
- The use of the word “validation” vs. “assurance”
Links:
- Medical Device International Consortium
- Case for Quality Working Groups
- FDA CSA Draft Guidance
- Etienne Nichols LinkedIn
- GG Academy
- Omnibus Bill
Memorable quotes from Wade Schroeder:
“Keep in mind if you talk software validation to anyone outside of life sciences, they're going to glaze over. Validation is not used. Software validation is not used outside of this industry.”
“You could tell a lot about potential changes to a draft guidance based on the number of times you see certain things show up as a comment.”
“Now look, if everything is high risk, then you didn't do a risk assessment, just like if everything's a high priority, you haven't prioritized anything.”
Transcript
Etienne Nichols
00:00:00.720 - 00:02:36.910
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 at Greenlight Guru the biggest thing we care about is the biggest thing you care about improving the quality of life with medical devices built with less risk. We know we're not physically there helping you to build devices, but our software is.
So why wouldn't we build our software to be aligned with industry standards like ISO1345 or 14971? We're the only medical device QMS solution provider to be named by G2 as a category leader for 13 quarters in a row. Because it's an odd number.
I can't do the math and tell you how many years, but what does that mean? It's it means medical device companies who are out there making a difference believe we're making a difference and they're telling people about it.
If you're looking to make a difference by getting quality life saving devices to market on an average three times faster, contact Greenlight Guru today to start the conversation. Welcome back to the Global Medical Device Podcast. My name is Etienne Nichols.
I'm the host of today's episode and today we get to speak with Sandra Rodriguez on the topic of CSV versus CSA Modern Validation for Modern MedTech.
In September of 2022, FDA issued a draft guidance regarding Computer Software Assurance or CSC, which sort of took the place of what was previously known as computer systems validation. There have been mixed reactions from the industry. Some companies seem to be afraid that a certain level of rigor will be lost.
But after looking this over, the methodology looks totally in line with FDA's move towards thinking and developing using a more risk-based approach.
So, we brought Sandra in to have a conversation in front of a virtual audience to discuss the ins and outs of this guidance and how it's been received and implemented by the industry. Sandra is an analyst for Axendia, which is a leading analyst and strategic advisory firm focused exclusively on the life sciences market.
They advise medical device and life science companies on how to prepare for, adapt to and overcome disruption by providing them with strategic advice on business, regulatory and technology issues. Sandra has a ton of experience in the specific section of validation, so she is uniquely suited to cover this topic.
We hope you enjoy this episode with Sandra Rodriguez on CSV vs CSA Modern validation for Modern Medtech. Hey Milan, if I'm saying your name correctly, good to see you. I'm Going to give our guest speaker a moment to come on stage.
Sandra Rodriguez
00:02:37.390 - 00:02:38.990
Okay, I'm on stage.
Etienne Nichols
00:02:39.230 - 00:02:41.390
All right. Rock on. Great to see you.
Sandra Rodriguez
00:02:41.790 - 00:02:42.510
Likewise.
Etienne Nichols
00:02:42.910 - 00:02:59.720
Yeah, I'm going to give just a minute for it because I know this. Since this is a live event, we're going to give a minute for some people to show up.
And for those of you who are already here, love to hear where you're coming from. I personally am in Nashville. We are very talking a lot about where Sandra's from. Where are you coming in from, Sandra?
Sandra Rodriguez
00:02:59.960 - 00:03:10.840
I am in Puerto Rico, so, you know, good morning from a very balmy. Probably feels like 105 degrees today.
Etienne Nichols
00:03:12.680 - 00:03:33.230
All right, Oregon. Fantastic. Welcome. Claren, if I'm saying your name correctly. Okay, well, we can go ahead and kick this conversation off.
I know people are going to be kind of trickling in. Looks like we got some people from Texas, Florida, maybe they know a little bit what you're experiencing with the heat waves.
Boston, I was just there last week. Emma, fantastic. Kansas.
Sandra Rodriguez
00:03:33.550 - 00:03:37.950
Oh, go cheese. Heidelberg. Hello. Guten tag.
Etienne Nichols
00:03:39.950 - 00:03:41.950
You're going to have me beat with the multiple languages.
Sandra Rodriguez
00:03:43.870 - 00:03:49.510
Just a little bit of Russian. Dobre, dobre, utrosvitzi.
Etienne Nichols
00:03:49.510 - 00:04:24.850
I hope that's right. I don't know. We'll see. Edinburgh, Scotland. Fantastic. This is great. Lots of people from lots of places.
I'm excited to have this conversation with you today, Sandra, for the recording. Those of you who are listening, you're listening to the Global Medical Device Podcast.
And this is a slightly different type of episode than we ordinarily would have on the podcast. This is a live episode. So, we have a lot of people in the chat coming from a lot of different places today. With me is Sandra Rodriguez.
She's an industry analyst from Axendia. But I'll give you a moment to introduce yourself, Sandra, and give a little bit of an origin story or your background.
Sandra Rodriguez
00:04:25.330 - 00:06:46.080
Okay, great. So, hello everybody. Welcome to the podcast. As Etienne mentioned, I work for Axendia. Axendia is an industry analyst firm.
But what makes us unique is we only cover business, technology and regularly trends in life sciences. Right. So, we don't go into oil and gas utilities, automotive, any of that.
I sold software and professional services in the life sciences in the early 2000s. So, I have about. I don't want to date myself, but yeah, I have around 21, 22 years of experience working within the life sciences and varying roles.
So, one of the things I did used to do was sell validation services as well as software and the implementation services. Everything around there, like, I always like to say, in the good old days, I made a really nice living doing that.
Because validation was this necessary evil that companies needed. You know, in life sciences, the regulations, it's like some people call it, the price you have to pay to play.
And so, when they were implementing software back in the day, even off the shelf, it was so customized. Right.
That the validation effort, anything that the vendor had done right, immediately just went off the table because there had been so much customization and configuration. So, sorry, I feel like I'm going into the topic, but I just want to, I just want to let the, the attendees here know.
Yes, I remember, I remember when validation was a great way to make money. It was a great way to. It was. You wanted to be a consultant, you were going to be busy, you were going to have more work than you could contend with.
And what the. And again, that was the. As, as Dan Matlis, who I work for, the way he puts it is it was the unintended consequence of the regulation.
Etienne Nichols
00:06:46.800 - 00:08:00.950
Yeah. So, and, and I, I appreciate you going into some of the detail about your background. That's fantastic.
And it's one of the reasons we invited Sandra onto the show today to talk about this subject. And what is that subject?
So those of you who are here today, you already know CSA versus CSV, that's computer software assurance versus computer system validation. Modern validation for modern tech. So, when we came up with this topic, part of the reason we came up with this topic is just a little bit of history.
In September, the FDA came out with the draft guidance to talk about computer software assurance.
So, if we were to look at that as maybe a line in the sand as a, or an indicator that the industry is changing, back in September, maybe we should talk a little bit more about the history and what some of that was entailed. You're kind of alluding to the cost of doing business, and it's a high cost to get through that validation. But what was required?
I mean, and just in my background, I remember working in Fortune 500 companies and multiple different companies where we weren't allowed to use certain parts of the software because they said, well, it's not validated yet, and it would be months before it was validated. And there were even things with Excel and things like that. So, what was the scope of this validation and what exactly was happening? Happening.
Sandra Rodriguez
00:08:01.190 - 00:10:51.040
Right. So, the guiding principles of software validation. Look, I think that at the time the agency had really good intentions. Right.
Automation and technology was still very new in life sciences. So, you needed to, you needed Some way to show that you were in a state of control and that the software was being implemented for its intended use.
And you could prove that every single feature and function of the software operated the way that it needed to operate. And then of course, part 11 came on even after that. Right.
That's when the agency started saying, whoa, whoa, whoa, there's no audit trail, there's no electronic records, electronic signatures here. And I think what I don't say, I think I kind of lived it at the time.
There were pharmaceutical companies, medical device companies, biotech, any industry people were, from my recollection, they had entire app dev groups within their businesses, and they were composed of full-time employees and a ton of contractors and they were building these custom applications to meet their customers, current business needs, their challenges. Right. Companies wanted to, they had again, they had good intentions like, hey, we want to automate this, we need a system that can do this.
We have so much paper, so let's build something. And the result of building those things turned into you. Do you want to be a life science company, or do you want to be a software development company?
You know, do you want to keep spending all this overhead on bringing people in to build technology or do you want to buy it off the shelf? And again, like I said earlier, yeah, there was a lot of off the shelf software.
But because of the guiding principles of computer software validation, companies were basically going back and retesting everything that the vendors had already done. Right.
So it's just like, okay, well our SOP says we have to validate this and this is what the validation package looks like and we're going to have a system design specification, we're going to have our URS, our FRS, you know, it was acronym soup, IQ, OQPQ, all the queues, traceability, matrix, validation summary report. We're literally talking thousands of pages of documentation. God forbid you were putting in an ERP at the time.
That was going to be a truckload of documentation, validation documentation showing that you had tested every single feature and function of this system.
Etienne Nichols
00:10:51.440 - 00:11:44.320
Yeah.
And if I were to just describe it in the way I understand it looking back, because I did do, as a manufacturing engineer, I was more on the, the process validation, IQOQ, PQS. I was peripherally involved, peripherally, I guess involved in some of the system validations.
But it's, it from my understanding, they looked at every single feature just like you were saying and had a, a baseline validation that had to happen for every single feature. And that was essentially the, the, the sum total of what, what was happening, those activities.
How does that kind of work differently with computer software validation? Maybe we could talk a little bit about what. I mean, I keep saying the wrong thing.
Computer Software Assurance, CSA, the acronyms are a little bit easier. Ordinarily I don't like the acronyms, but today I do. So, what is, what are some of the differences? Maybe we could talk about what?
Computer, Computer Software Assurances.
Sandra Rodriguez
00:11:45.040 - 00:13:46.030
Okay, so, so the big thing is before I, before I start down that road, keep in mind, if you talk software validation to anyone outside of life sciences, they're going to glaze over. Validation is not used. Software validation is not used outside of this industry. Everywhere else is called Software Quality Assurance.
Software Assurance. Quality Assurance. Right.
So, the biggest, I would say the biggest change, number one, is that we're not calling it validation, we're calling it assurance Yet. If, if, and you know the folks on the podcast today, if you haven't read through the draft guidance, do so now.
Granted, it's, it's in draft format, it is not finalized yet. We can get into that a little bit later. But the language is changing.
And when you look at, and this is the way FDA, for example, Cisco Vicente is the program manager of the case for quality at the FDA. The FDA has a working group called MDIC. MDIC stands for Medical Device Industry Consortium. Okay.
So, if anyone here wants to learn more, you know, Google it, Bing it, whatever your preferred way of searching this is, they do a lot of industry outreach. It's made up of regulators, it's made up of technology and service providers.
I believe the founder of Greenlight Guru is involved in that and a ton of industry companies. Right. Everything from big global medical device companies like Boston Scientific to some of the more smaller niche players.
So, there's room for you in that conversation. Okay, so this draft guidance, so these folks got together and. I know, yes, the draft guidance was issued on, In September of 2022 last.
Etienne Nichols
00:13:46.030 - 00:13:47.310
Year, whatever that was. Yes.
Sandra Rodriguez
00:13:47.470 - 00:16:53.430
Okay, check this out. The working group for computer software assurance through the MDIC was formed in 2015. Eight years ago.
Eight years ago, the regulators, the technology companies and some very forward-thinking life science companies got together and said, what can we do to bring life sciences to, how can we finally catch up with automotive, high tech, all the other industries out there when it comes to automating our production processes and implementing technology? And how, because right now. And people always get shocked again. Remember I, I was involved in professional services for a long time.
Based on my experience, if you spent $100,000 on software, you spend $150,000 on implementation and validation, right? So those pieces became 1.5 times the cost of your initial investment in just the software.
So, the fact that the industry wasn't advancing like everyone else was twofold. There wasn't technology out there. They felt they had to build it. And the cost of implementing a system and life sciences is so unique.
I would say a cap is a CAPA. We know that today.
But back then, everyone's processes and everyone's needs were so unique that they were either going to, like I said, customize and just configure the heck out of it, or they decided that the best thing we have to do is build our application on our own and support it on our own and then the validation of all that. So, now you become a software company, right?
Now you have to come up with your SDLC, your system development life cycle, and again, do this all, you know, within the regulatory frameworks under the quality system regulation, under the guiding principles of computer software validation, all that good stuff. So, software assurance was born, I guess is an idea. Eight years ago, many pilots, many, many pilots.
I'm talking Boston Scientific was involved, Edwards Life Science, there was Zolife Fest, there was Baxter, there were a ton of other companies, and they said, okay, let's look at GAMP. And this was, you know, even back then, what does the risk-based approach mean?
And when you look at validation, and I always describe it as a triangle, right? And it's a podcast, so I can't show it to you, but validation was this.
You look at a triangle at the bottom layer you have documentation, on the top layer you have assurance activities. And then you have. I'm sorry, I'm doing it backwards. Yeah, you have assurance activities, testing.
And then at the top of the pyramid, like if you think of like a, like the food pyramid that, you know, we grew up on, you had critical thinking.
Etienne Nichols
00:16:53.990 - 00:16:55.910
That's a pointy top. Yeah, right.
Sandra Rodriguez
00:16:55.990 - 00:17:35.980
So, what happened was you created all this documentation because your insurance activities were this big and your testing activities were this big. And then your critical thinking at the top was the least, the least bit of effort that you put into how you're going to validate the system.
And I don't want to pick on the validation and the QA people on the podcast today, but you kind of did it to yourselves back then, right?
It was like, I'm going to write a SOP on computer system validation, and this is what we're going to do for every single technology that we implement in this company. And we're going to validate the software to the level that we're going to validate the software in our medical devices themselves.
Etienne Nichols
00:17:36.140 - 00:18:10.810
And actually, I want to, I want to time out for just a second because of something you said.
There actually one person in the chat, Jenny's kind of, she was asking a little bit for some clarification in the conversation, and I think it's a good idea.
So, when we're talking about this computer system validation, we're not talking about the validation of your medical device or your software as a medical device or. And actually, you know, I will direct some people again to the draft guidance.
If you look at that draft guidance that was released On September, pages 7 and 8 actually define the scope. And I'll just kind of quickly go through that. I'm sorry to interrupt you because you'll probably do a better job. It's important.
Sandra Rodriguez
00:18:10.810 - 00:18:11.370
It's important.
Etienne Nichols
00:18:11.370 - 00:18:51.630
And on page seven it talks about software intended for automating production processes. So, we're talking inspection, testing, collection and processing of production data. Software intended for automating the quality system process.
So that's collecting and processing of quality system data, maintaining quality records, the quality system regulation and things that of that nature as well as software that supports those things. So, software that supports production, software that supports the quality system. So those are kind of the main buckets that we're looking at.
We're not talking about the medical device itself. This is more of the processes related to those. And. Yeah. Any clarification there, Sandra?
Sandra Rodriguez
00:18:51.950 - 00:19:21.840
Yeah, and the guidance specifically states non product software. Right. So, your medical device as a product. Right. We're talking, we're talking your ERP, we're talking your QMS system.
If you have PLM, think about a platform like Greenlight Guru, right? Think about this type of technology or technologies that are used to support the production process on the shop floor.
Etienne Nichols
00:19:23.440 - 00:19:55.870
Okay. And so, this is this. I appreciate you going through all the detail and some of the, the things that we previously had to experience. So now we're.
You, you kind of described that pyramid where on the bottom there's all those activities of validation and then that was just an expectation.
Everything's going to experience that, that depth of validation and then you move a little bit higher up to the very top where you start having that risk-based thinking. So that's CSV. Tell me a little bit more about CSA. How do you see that?
Sandra Rodriguez
00:19:56.590 - 00:22:20.370
So, CSA completely flips that pyramid upside down. So, at the bottom you have a lot of critical thinking up front, right? You're looking for your intended use.
You're really looking at what is the impact of this feature and function on the patient, on the quality system, on the production system. How does anything in this software application impact the long term and assess risk to it? So, you start with critical thinking.
Because you're doing all that critical thinking, your assurance activities are going to go down because you've now and by the way, you're not just thinking it, you're documenting it, you're doing your risk assessment and you're backing it up. Right. For a regulator and for yourself as a company.
The one thing that Cisco has said consistently over the years is that validation documentation has to be of value to you as the business, not the auditor. Okay. All right. So, your critical thinking's here. As a result, your assurance activities go down. As a result, your testing goes down.
Now the one thing that the guidance document had people up in arms and I've given plenty of talks and there have been a lot of validation people in the room or QA people. It has things like error guessing and ad hoc testing and unscripted testing. Right.
So, these are new, these are new concepts if you're responsible for validation at your organization or quality in your organization. But these testing methods happen in other industries and software companies use them as well.
So, because your testing activities go down, what your documentation, the amount of pages, the amount of documents that you need to show or keep, again making sure that they're a value to you are going to be reduced dramatically. I mean I've seen numbers of upward upwards of 80%. I mean I'm talking; we're talking about going from 50,000 pages of documents to maybe 1500. Right.
So, think of, think of every document as a resource and then the time that went into creating that document.
Etienne Nichols
00:22:20.930 - 00:22:57.410
Yeah. So, I love the way you use that pyramid to look at that. You know, one kind of use the pyramid for both, just flipping it upside down.
So, I really like that. So, I guess a question that might pop up is how often this is relatively new, at least on paper. But you said it's been thought of since 2014.
What is actually different in practice? I mean we talk about what, what the CSV and what it actually was. What is it in practice? Are some people kinds of already doing this?
Because it seems like we should be already thinking in a risk-based way.
Sandra Rodriguez
00:22:57.970 - 00:25:07.030
Okay, so if you're, for example, if you're one of the, I'm going say pilot companies that I mentioned earlier, you've been doing it since 2015. There are other companies that say, well, we've been following GAMP and we've taken a risk-based approach to validation for a long time.
So, this guidance document isn't really any, it's not really providing any new information. Right. We've been following GAMP and we're, you know, we do critical thinking.
The other thing in this guidance document that's really important is that there's a, there's a big, the word data integrity shows up, right?
About what, you know, what are we really trying to achieve here with this new critical thinking, this new computer software assurance for production and quality systems. And it is data integrity as well.
So it's what it does, in my opinion and with the companies that I've talked to is that it lessens the validation burden on the medical device company, med tech company, and in a way it shifts it back to you, right, to the green light gurus of the world, to your technology vendors of the world.
Because the expectation is that a technology company knows how to build good software, knows how to release good software, and the days of customizing are over or really, really deep configurations are over. Back in the day it was pretty much 80, 20.
There was a rule 80, 20, 80% is going to be customized and then 20% of it we're going to use out of the box functionality that has now shifted to 20% configuration. Customization is a bad word. Now it's 20% configuration, 80% off the shelf.
Etienne Nichols
00:25:07.990 - 00:26:04.220
Yeah. Okay. And so, you mentioned Green Light Guru because obviously that's sponsoring this podcast.
So, I guess we should mention that someone actually asked in the chat, well, what is Greenlight Guru doing? And we previously had done something of a CSV approach.
We have recently announced June 1st we're moving to this; this more modern approach and we are working to streamline that software implementation for companies and really provide a better solution. So, one question, another question that was in the June, the announcement is June 1st to move to June 21st.
Okay, so there was the, a correction from Etienne, who is our fantastic customer, smart guy in the, in the chat.
So, one of the questions though also was about Gant 5, because you mentioned GAMP is the, is the assumption if you are pursuing that approach, you're already covering all of the things’ CSA or this draft guidance is talking about. Can you elaborate a little bit on that?
Sandra Rodriguez
00:26:04.620 - 00:30:27.230
Great question. And I'm going to answer it; I'm going to let the industry answer it for you. So, the draft guidance was issued in September.
If anyone on the, on the podcast today has never done this. You know, these, they are public docket numbers. They're on the FDA website and they're open for comments.
So draft guidance to stay open for 60 days, giving the industry a chance to comment. All right, there are, and I checked yesterday and of course the comment period is very closed.
It closed, I think on November 15, 137 comments were received to this guidance document. They're all public. There was Advamed, there was a society for quality assurance.
There are medical device companies, there's a lot of anonymous people, there's some consultants.
A lot of the comments say that, you know, this is, you know, this was already being covered by GAMP and that they, that the recommendation is that the agency with the appropriate wording and of course there's suggestions right on how to do it, but the recommendation is that they marry those two a little bit closer together so that there is, so it eliminates any kind of confusion or you know, so that people really understand, you know, just to make the language a little bit more not up for interpretation. So short answer, this is specifically, the industry itself is saying, hey, you know FDA, why don't you consider this another thing.
And I don't know if it's going to come up in the chat or if you're going to ask me, but what you could tell a lot about potential changes to a draft guidance based on the number of times you see certain things show up. As a comment, the industry is asking and open system, well I say open system, closed system, cloud and SaaS. Okay.
They are specifically asking for the agency, you know, some and when, when companies were moving to the cloud. And I would say that really started probably right around this time. Right.
Maybe it was about eight years ago that there was a little bit more activity in moving to the cloud outside of like your CRM or email. You know, I'm talking about like ERP in the cloud, QMS in the cloud, those types of things.
So, they are asking for a specific example because the guidance document has a learning management system, an MES, ERP and Excel specific spreadsheet, you know, and a business intelligence or a business analytics tool. Right. They list a couple examples of how to apply critical thinking and taking risk-based approach when it comes to software assurance.
So, the industry is asking for examples of cloud or SaaS software. So, let's see if it makes it in there. And then to no surprise, artificial intelligence, you know, it's like I, yeah, you know, it's the answer.
The question is always, look, I get that, you know, we want it's always okay. It's always better to ask for permission, you know, I'm sorry. It probably is better to ask for permission, you know, ahead of.
And in life sciences, it's always been, look, we know warning letters are bad. They're just, they're bad for pr. They're bad. They're bad in general. Right.
You don't want to be on; you don't want to be on the FDA's website because now you're going to get all kinds of companies calling you and trying to help you fix your problems. So, there is a there.
It's like the industry's begging for like, hey, tell me how to validate my cloud solution or tell me how to validate the SaaS application. And I really want to use artificial intelligence but tell me how I'm supposed to validate that.
Well, the agency itself is still trying to figure out artificial intelligence, number one. Right. There's a ton of discussion papers out there. So, it'll be interesting to see what the final guidance document looks like, if anyone.
And I'm sorry, I'm talking. So, I'm not really keeping up with the chat.
Etienne Nichols
00:30:27.390 - 00:30:28.190
No, that's okay.
Sandra Rodriguez
00:30:28.590 - 00:30:57.330
Question would be, well, when are we going to see it? Okay, so rumor has it that because of these questions. Right.
Or 137 comments because of all this input from the industry, it's going to take a little bit longer than anticipated. And we could, if all goes well, see the final guidance document by the end of the calendar year, not the fiscal year.
So that would be by the end of calendar year 2023.
Etienne Nichols
00:30:57.890 - 00:32:01.920
Okay. And since you mentioned AI, I'm going to put a link in the chat as well as a link in the show notes to the.
What I kind of wonder is maybe going to drive some of the things around that the blueprint for an AI Bill of rights. And so, I always like to go upstream when I think about things changing and shifting. And maybe CSA is a good example as well. Where did it come from?
What was the motivating factor behind these things? So, you could apply that to this other type of software. Really? And where are some of these changes coming down from?
And this blueprint for an AI Bill of rights may be one of those things. You can see that in some of the, the draft guidance is. It's a reference. So just throwing that out there. We'll put that in the show notes.
But let's talk a little bit more about the specifics of CSA and the, the.
If, if you could maybe give some examples of let's say I've got an ERP that I want to validate or okay, keep using that word, I, I have a ERP that I want to be in line with. Computer software assurance. What are some of the differences that I'm going to do on a practical level?
Can you kind of walk me through what the actual steps would look like?
Sandra Rodriguez
00:32:03.080 - 00:32:52.840
Sure. I mean, okay, so the first thing you want to do is you want to assess the risk to the patient and the product. Right.
From failure, event or consequence with potential cause to. Let's say, let's start with low risk. Low risk. And these are some frameworks that are in the guidance document and that come from FDA themselves. Okay.
So, you want to determine what's the risk to the patient or the product? What is the risk to this feature and function of the product not working as intended to the patient or the product or to the quality system.
There is an ERP example in the guidance document. I don't think I have it in front of me. And on page 11, I believe.
Etienne Nichols
00:32:52.920 - 00:32:53.880
Yeah, yeah.
Sandra Rodriguez
00:32:53.880 - 00:34:42.560
I've had a little bit of a challenging technology day today, but what you do is so long story. And this, this really goes to your testing approach. Right.
So, this, this guy, this guidance document is all about documenting your risk assessment, determining your assurance and your testing approach in accordance with that risk. Now look, if everything is high risk, then you didn't do a risk assessment.
Just like if everything's a high priority, you haven't prioritized anything. And so, what the guidance document walks you through is when do I do scripted testing versus unscripted versus ad hoc or error guessing.
And again, this framework was developed with the industry and with technology and service providers. So, of all the companies that have taken this approach over the years, the FDA has accepted it.
Now there is a concern that, you know, what happens in Maryland isn't going to happen here in my neck of the woods when the auditor comes in. And granted there haven't been a lot of in person inspections since early 2020, but the FDA is, does have a, a training.
You know, internally they're getting the word out, they're making sure that everyone's on board. You can't come in and ask for the VAL A.
The validation package that, that you're used to seeing and getting less documents and thinking that just because of that the company doesn't have, you know, they don't have their software assurance for intended use.
Etienne Nichols
00:34:43.280 - 00:34:43.760
Yeah.
Sandra Rodriguez
00:34:44.560 - 00:34:47.400
Appropriately documented or provide digital evidence for it.
Etienne Nichols
00:34:47.400 - 00:35:41.390
So, so when I think of this. So, my product development background kind of starts coming out. So, you know, you'll have to hold me back at some point here.
But one of the things I think about is part 820.30 talks about the way you should design a product. And one of the things you do is you identify the intended use. You talk about those use, those user needs.
And that drives what your design inputs are, your design outputs, the design of the thing that you're building. And then that's how you decide how you're going to verify it and validate.
Now, there's lots of aspects to your device that may not fall under user need. Maybe the color of the plastic, if it's not important, different things like that may not matter. So, they don't necessarily fall into design controls.
Is that kind of the way to think about it? When you, when you think through your intended use, your user needs, is that a way to think about applying the CSA or am I way off base here?
Sandra Rodriguez
00:35:42.230 - 00:36:54.230
Okay, well, I can tell you the way Cisco Vicente of the case for quality and NBIC put it, because a computer software assurance effort is risk based, the burden of validation is no more necessary to address the identified risk. Okay, right. So yes, I don't think there's a, I don't think there's a necessarily a one size fits all for everyone.
And the reason I say that is because of, I don't know, sometimes it just has to do the culture of the organization, the maturity of the organization, the maturity of the technology and the automation in a company. But what, what you're trying to do is again determine whether a software is intended for use as part of the production or quality system.
Okay, so do you mind if I just go into that for a second?
Etienne Nichols
00:36:54.230 - 00:36:56.350
Let's do it. Yeah, okay, absolutely.
Sandra Rodriguez
00:36:56.670 - 00:39:24.590
So, identify your intended use. Determine your risk-based approach.
So, evaluate the level of risk if software were to fail to perform as intended and if the software fails as, as if the software fails to perform as intended, what is the impact on the product and the patient and your quality system? Right. Ultimately the patient. Right. I mean, let's come on, we're in business to make people's lives better.
So, what would be the impact of that on your patient? Then determine your appropriate assurance activities.
Again, this is taking that starting with the critical thinking first and then doing the documentation later. So, identify assurance activities again commensurate with the risk.
So, this is where the different type of testing that you're going to follow and then establish the appropriate record.
So how are you going to capture sufficient evidence to demonstrate that software was assessed and performed as intended in the comments of this guidance document. I, I think it was interesting how there was a lot of pushbacks. There was a lot of.
There were some interesting comments about screenshots, where the technology is today in 2023, and how we can Photoshop or make a screenshot look like anything, really. You can manipulate screenshots easier today than you could 20 years ago, I guess, was one of the commons.
You know what, what really is the value of a screenshot? A screenshot is just saying whether you passed or failed something. Whether something passed or failed.
So rather than spending all these times with these screenshots, just say pass or fail. Right? And if it failed, then how did you fix the fail or. You know what I mean? What. So, we're moving on from where but the screenshots.
And again, I know this is going to make a lot of quality people and a lot of validation people very itchy because this was the process, this is the way we've done it in the past. And the reality is the regulators are trying to make it easier for you, right? They're not taking validation jobs away.
I know everyone's worried about losing their job to generative AI and everything else and automation and robots, but what they're trying to do is make you work smarter and again, stop generating all this documents, spending all this money and resources, and stop using validation as excuse not to come into the 21st century.
Etienne Nichols
00:39:25.390 - 00:39:51.260
Okay, you mentioned something about the culture, and I wonder if you could address that a little bit, because that was actually something that was mentioned in the chat. Is, is that the actual switch might not be the hard part.
The culture and changing the attitudes of those quality assurance personnel might be the more difficult part. Is that something you've seen or what are the, what are the challenges that you've seen personally with companies switching over?
Sandra Rodriguez
00:39:51.900 - 00:40:51.860
Oh, well, I mean, I've, I've, I've heard it right firsthand. You know, it's just, it's a natural resistance to change, and a lot of that is understanding.
You know, you, you guys on the podcast, you have to read the guidance. You have to wrap your head around it. You have to talk to your peers.
Again, there's these communities out there to understand what some of these best practices are. Work with your vendors, leverage what they are doing so that you can, as, as the FDA puts it, take credit for the work that they've done.
So, yes, I've, I'm seeing some resistance out there, and a lot of it is, you know, we tend to get a little sensitive when we think our jobs might go away. And your jobs aren't going away; you're just going to get to actually create a little bit more value. Right. For yourself in the organization.
And you know, stop, stop reinventing the wheel.
Etienne Nichols
00:40:52.820 - 00:40:53.300
Yeah.
Sandra Rodriguez
00:40:53.780 - 00:42:00.540
And, and by the way, I, I've heard folks at FDA say this plenty of times.
You know, you, you don't want to be doing business, you shouldn't have a technology partner, or you shouldn't be in a partnership with a technology company that can't give you good software. Right.
So, you're, you know, the relationship between life science companies and their partners, their vendors are, is changing significantly because of this as well. So, it's not. So now it's a how can you support CSA? And we've heard that consistently. Right. I mean my job's an analyst, so I go all around the country.
I go to conferences, I speak at events, I read, I read for you. I, I attend webinar speak on webinars. You know, this is what I do for a living.
And so, there's been, like I said, there's been some of that resistance.
And then there's other companies, especially the smaller ones, who are like, look, the, the, the easier you can make my life to help me be a quality data driven organization, the better.
Etienne Nichols
00:42:02.060 - 00:42:52.180
Yeah, absolutely. And so, the, the, the difference, it's interesting to think about the difference in the way people are approaching it.
You've worked with a lot of different companies and that was actually one of the reasons we, we started working with you and Axendia is because when we saw this draft guidance come out, it was a draft, and some things could change like you said. 137 Comments. A lot of those repeat things probably will slightly change.
And so, after kind of feeling out the industry, that is one of the ways that we're, we're moving towards. But I'm curious, have you seen anybody jump on too quickly?
And I don't want to know who or anything like that, but what are the potential risks if you jump in a certain way or are there any ways and people are misusing it? Is there a way to misuse it? I guess I should ask.
Sandra Rodriguez
00:42:52.420 - 00:45:47.920
Oh yeah. Oh, there's certainly, certainly a way to misuse it, which is, you know, don't, don't, don't do any kind of software quality assurance on your own.
So, you know, don't you, you have to do. You have to. Okay. You have to. So, like I always say, look, there's a method to my madness Right.
You have to be able to defend, defend your decisions to an auditor. Why you took any one way, one approach or another when the time comes, right. That needs to be documented.
And again, this starts with what is the impact? What is the risk assessment? What did you come up with? What? You're gonna have to defend your decision, and maybe it'll work and maybe it won't.
So, the biggest, I mean, the bat. The worst thing you can do is say, I don't have to do validation anymore because that's just, that's just not true.
And I saw that there's a question here about ISO 1345. So, in the comments, by the way, in the, in, in a lot of the comments, that was a good, good catch.
That was actually another common theme that I saw was industry recommending that, you know, again, these all kind of come together and, and the reality is I don't think they want to make. I don't think the agency wants to repeat the same mistakes. Right. We don't want this guidance to become what the previous one was. Right.
So, the more we can bring in industry standards, you know, the more we can say, look, this is following ISPE and GAMP 5. And then we have ISO here and we have, oh, here's the other thing.
People are very concerned that only medical device companies will follow this approach because, you know, it's coming out by CRH and that actually it's going to support, Support Pharma, Ford Auto. So, this is for, you know, for. I know you guys on, on the podcast today are medical device companies. I'm guessing most of you are.
But this is really, this should cross, you know, the different agencies under the FDA and everyone is looking to adopt this.
So, at the end, this is really about moving the industry forward, coming into the 21st century, automating your production processes, having critical thinking as a foundation to your software quality assurance activities, really focusing on improved patient outcomes, becoming data driven, leveraging technology coming out of the dark ages.
The amount of paper that still exists in this industry is frankly unnerving when you think about the complexity of the products that are coming to market today.
Etienne Nichols
00:45:48.800 - 00:46:07.280
Yeah. And if I were to, I don't know, bring out one of the other.
One of the other questions that came up in the, in the chat was something about cyber security.
And I know that's a little bit of a different topic, but is that something that, I guess that would be part of your risk when you're going through and looking at that?
Sandra Rodriguez
00:46:08.240 - 00:46:25.600
Yeah, well, and so, I mean, I don't want to be the bearer of bad news here, but so there's this omnibus bill that has really, really. That has some new cyber security requirements there to even try to get a product on the market.
Etienne Nichols
00:46:26.640 - 00:46:34.320
So, but again, still product related, not necessarily process related. I think that omnibus. She's really. I can try to get a link to that. I think it was December 29th.
Sandra Rodriguez
00:46:34.920 - 00:46:53.960
Yeah, the omnibus bell is definitely product related as opposed to the cybersecurity of your networks or if your QMS is in the cloud and you're in whichever vendor ecosystem you're in.
Etienne Nichols
00:46:56.200 - 00:47:51.070
Okay, I found a link for those masochists in the audience who want to read that massive bill and I'll put that in the show notes as well. But that being said, those, those specific things related to the process, if there are any cybersecurity related, like cloud, cloud-based software.
The comment was made that in the guidance, the FDA guidance for CSA, it doesn't necessarily mention cybersecurity risks, but when you go through that risk based approach, the assumption in my mind is that as a, if you're a software company that is part of your overall risk based approach, thinking one of the risks potentially is losing, losing some of the important information related to a specific, I don't know, clinical trial or something like that. Is that, is that your thinking or what are your thoughts?
Sandra Rodriguez
00:47:51.070 - 00:48:21.140
Well, I mean, I would probably bring it a little closer to the patient. Right.
Because we're looking, you know, we're looking at risk to the quality system or the product and how, and how those risks would, would ultimately impact the patient. So, you know, it could be anything from, you know, securing, you know, your supplier data. Right. I mean, who you're getting materials from.
I, I wish, I wish I had an answer for that. That one's kind of, I think, a little bit out of my wheelhouse.
Etienne Nichols
00:48:21.220 - 00:48:22.700
Sure. No, that's, that's fine.
Sandra Rodriguez
00:48:22.700 - 00:48:27.900
Maybe I just don't have the right context for it. I could, you know, do a little research and get back to whoever.
Etienne Nichols
00:48:27.980 - 00:48:49.580
No, that's. That. No worries. Yeah. Cyber security is a moving target right now, it feels like. But so, we can keep moving. Okay. This is great.
We covered a lot of ground.
I'm curious, is there anything you feel like maybe we missed or, or questions you've gotten asked quite a bit as far as that, that maybe we haven't gotten to. I'll run through the comments while you think of something there and I'll see if I can come up with something.
Sandra Rodriguez
00:48:50.780 - 00:50:33.940
No, I think, look, I think what I would Want to tell the folks listening today is that you're going to. Okay, this is a, it, you know, it's a step change depending on again, the maturity of your company and how you were approaching validation.
You know, to use, you know, in the good old days. To use the term in the good old days.
But understanding that and I feel like the regulators itself, themselves have said, look, this really isn't that much different than if you were following gap, if you were taking a risk, risk-based approach to your, let's say, validation back then.
I think what probably took everyone off guard is that the word validation went away and again we caught up to other industries and started calling it software assurance and that, you know, it's a good thing. This is, this is again a way for you to stop spending time and resources testing every single feature and function that you don't have too anymore.
Remember, we're not building software anymore. You know, we're, we're, we're focused on bringing medical devices to market.
You know, you don't need to have ISOCOM IT armies, the, IT armies of those, those app dev groups building all this custom software. I mean I, I've been to companies where, you know, the validation.
You literally had a validation manager that had sometimes 50 validation people on staff full time and another hundred contractors.
Etienne Nichols
00:50:34.260 - 00:50:34.740
Yeah.
Sandra Rodriguez
00:50:34.820 - 00:51:09.470
Validating all different kinds of technologies, doing not only system validation but process and equipment qualification. So, you know, this is, like I said, I, it's a step in the right direction. The regulators want you to come into the 21st century.
They're trying to remove some unintended consequences of the prior guidance document out there. And you know, let's see what they say about cloud systems and AI. I'm looking forward to it myself.
I wish, I wish I had a, I wish I could read people's minds. I wish I could just look into my.
Etienne Nichols
00:51:10.150 - 00:51:54.000
Yeah, you, you brought up that 80, that 80, 20 that you mentioned earlier. I think was a really powerful point for me personally because I think, okay, previously you wanted an 80 customized solution.
It made total sense that you in house would have to be validating that because why would the company, you know, do that for you and then do all this validation when they're moving on to the next company?
Whereas nowadays you've got these companies that are building software specific for the industry and pardon me for using Greenlight Guru again for that, but I mean a software that is specifically built for a medical device company that wants to take a medical device to market should be something that the company itself could take on and do that activity for you, so.
Sandra Rodriguez
00:51:54.000 - 00:52:25.430
Right, exactly. And you know, you, you know, you yourself are building industry best standards into your application, right.
So, most of the things are going to be out of the box. You know, there's going to be workflows that are created out of the box that companies can just get in and take advantage of.
So, if you're not changing anything, why are they going behind you and retesting everything that has already been tested? Because you wouldn't be releasing software that doesn't work, but if you did, you wouldn't be in business very long, right?
Etienne Nichols
00:52:25.510 - 00:52:57.580
No, that makes total sense.
And it's interesting when people want a specific, you know, customized workflow and they forget, well, you're trying to follow ISO 1345, 7.3 when it comes to all of your design controls or part 820.30, whatever it is. And so, yeah, it makes sense. One of the questions from the chat that I'm just seeing now, I think it's a good question from Charles.
Is the term validation now obsolete as it relates to computerized systems or software? It probably isn't yet, but I'm curious, should it be, what are your thoughts for non-product?
Sandra Rodriguez
00:52:57.660 - 00:53:47.720
For sure. Right. So, for non-medical product. Yes.
I, I don't think we'll be using validation when it comes to your business applications and, and those technologies, I think we will be using assurance at least.
Oh, that was, and again, I don't know if I mentioned that earlier, but that was another thing that I saw a lot in the comments is that don't use validation. If you're not going to call computer system validation, don't refer to validated or validation in the body of the guidance.
Make it as, you know, make it as clear as possible and communicate that as clear as possible throughout the guidance and be consistent and don't use the V word. But yeah, for non-product, for your medical devices, you're still going to be validating the software in your products? Yes, absolutely.
Etienne Nichols
00:53:48.120 - 00:54:17.430
Okay, I'll run over to the QA. We've kind of been trying to go back and forth so hopefully that's made sense to those who are listening.
But I'll run over to the, the QA to see what, what kind of questions we had Milan asked. GAMP is not a regulation. Why is it, why is it so pushed, and suppliers claim that they're GAMP 5 compliant.
I would expect something different is what are your thoughts there? You kind of covered a little bit about GAMP 5, just kind of being best practices.
Sandra Rodriguez
00:54:17.430 - 00:55:34.680
But yeah, no, no, that's, no and that's okay. So, you have to, you have to realize that life science is a herd mentality. Right.
So, there's, there's very few people at the top, there's a couple stragglers at the end, and the rest are in what I call the warm frozen middle.
So, when you have, when you have GAMP out there, when you have ISB and GAMP 5, and when you have all these, you know, there is a, there is a harmonization. What's the word I'm looking for? Wave. Right.
Happening to again, this is for the, for the, for the, for the benefit of the industry to say, look, this is, this is accepted, these are best practices and now it's not a regulation by any means. Right. There was again from the commons a little bit again time that a little bit more into I think the thought process there from the regulators.
So no, it's not a regulation. But these are good frameworks. I don't know if that's the right way to put it to follow that have been accepted within the life sciences industry.
Etienne Nichols
00:55:35.800 - 00:55:46.820
Sure. Okay. I'm curious if you said it's not regulation yet, do you see any potential future for regulation being impacted by, by this?
Sandra Rodriguez
00:55:48.900 - 00:55:50.420
I, I wouldn't even.
Etienne Nichols
00:55:50.980 - 00:55:51.540
Speculation.
Sandra Rodriguez
00:55:51.940 - 00:56:50.190
Try to guess what, you know, what the, what a future FDA is going to look like. But I will advise the folks on the podcast today to try to stay on top of that a little bit. Right.
So at least in the United States, the FDA itself has an office of digital transformation. The FDA itself just requested $7.2 billion for fiscal year 2024 to modernize and to continue modernizing.
They have an enterprise modernization action plan. They have a data modernization action plan. They said they're moving to the cloud. They. Sure, there's a ton of AI initiatives in there.
So, you know what the FDA is going to do in the future? We don't know. But we know that not doing nothing as an industry could potentially put you behind your regulator.
And that is not a place you want to be in at least if you're, you know, marketing and selling here.
Etienne Nichols
00:56:51.470 - 00:57:09.540
Yeah. Under the FDA, some Rodney asks, is there more emphasis now on risk analysis due to CSA? I'm curious what your thoughts are on, on that.
I mean, I know the FDA's been, been pushing a risk-based approach for a while now. In fact, that's part of the, a big part of the preamble for the QMSR. But what are your thoughts?
Sandra Rodriguez
00:57:09.860 - 00:57:40.360
Yeah, I mean this, yeah, this Is, I mean, this is, again, this all starts with a risk assessment. Yeah, right. This, this is all under.
First of all, this is really understanding your intended use for a system, you know, for a system that is going to, that is going to, for a software application that is going to impact the production or the quality system, really understanding what is your intended use for it and then doing that risk assessment to again understand what is the impact of something not working on the patient.
Etienne Nichols
00:57:40.920 - 00:57:43.800
Yeah, okay, that makes sense.
Sandra Rodriguez
00:57:43.800 - 00:58:48.220
I feel like I'm a broken record with that. But that is the, that has been a very clear and consistent message from the regulators, even when this was just a pilot program back in the day.
Another thing that the industry is concerned about is that, well, you listed a MES system. You listed, you know, you gave five, you know, five examples. And you know, what's the unintended consequence of just listing these five examples?
Everyone is going to do exactly, they're going to do the risk assessment and follow exactly what was shown in these examples, which are really, really small and not really all inclusive. So, we'll see what happens with that.
We'll have, we'll see what happens with the examples because like I said, there's a lot of push to understand how does this impact my relations with, you know, with applications that are in the cloud or SaaS software? How does this impact AI technology that I want to use that could have an impact on the patient or the production and quality system?
Etienne Nichols
00:58:49.500 - 00:59:45.970
Okay. Have you heard the phrase intermittent validated state? And I'm curious if you, if you have heard of it. I'm curious what you think of it.
Or this was an early, this is several years ago that I first heard about this, and I think it was basically pushing more towards CSA with cloud computing. I think there was an AMY report. Let me look it up. Actually, a consensus report. Oh, 2021. Amy CR510. 2021. Maybe I'm, I'll put a link to it.
Maybe I'm shooting from the hip here and I should not ever do that. But if you've not heard about, we can move on. But I'll put a link in the show notes to that.
But it was essentially the appropriate use of public cloud computing for quality system and medical devices.
Now granted, a little bit older, so this draft guidance makes a lot more sense, but I didn't know if that is something that had been on your radar as far as something you've seen.
Sandra Rodriguez
00:59:46.850 - 00:59:52.210
No, that's not terminology that I'm familiar with.
Etienne Nichols
00:59:52.530 - 01:00:29.450
So not mainstream. And it definitely didn't catch on. So, we could just kind of move on from that then. Sounds good.
Let me go back over to the Q and A just to check one more time, see if there's something that we didn't really catch, even peripheral. Peripherally. I should stop using that word. That's the second time.
Can GCP companies use the term validation for purchased GxP software product SaaS in use? Maybe the question more is about the use of the term validation. I don't know that it's absolutely wrong to use that Validator.
It just sounds like, you know, I'm.
Sandra Rodriguez
01:00:30.650 - 01:00:59.690
Yeah, no, I mean, look, I think, I think the word validation isn't, isn't going to go away anytime soon. You know, it's, it's. I'm sorry, I froze. It's.
I think, I think it was clever to remove validation, to stop saying system validation and say system assurance, just because it automatically gets your attention that something, something's changed.
Etienne Nichols
01:00:59.930 - 01:01:00.410
Yeah.
Sandra Rodriguez
01:01:00.410 - 01:01:18.090
And you need to pay attention to the change.
So, look, no one's saying you have to go through your SOPs and remove validation and use assurance, but that's just, you know, I guess that's, that's the new, that's the new lingo. That's what everyone's going to be talking about now is software assurance.
Etienne Nichols
01:01:18.330 - 01:01:33.330
Yeah, I like Ginny's comment. You still need to validate a process. I'm going to have to have Ginny be the podcast host next time. She's asked some really good questions. Yeah, so.
Okay, go ahead.
Sandra Rodriguez
01:01:33.970 - 01:01:55.030
No, I would say, yeah, I mean like again, this is.
The regulators aren’t saying you don't stop, stop out, stop, stop testing, stop proving that you're in a state of control and that technology is meeting its intended use consistency. And if it does, and if it fails, it's not going to impact, you know, the patient or the product.
Etienne Nichols
01:01:55.190 - 01:02:14.710
So, so really, it's a, it's, it's a different way of identifying the activity essentially.
I mean, if you wanted to, you could still call it validated, but it's just easier to use a different term because you're now using a different process. So that's ultimately what you're trying to get at. And I think that's valid. I think that's, that's a great way to approach it. Very cool.
Sandra Rodriguez
01:02:14.790 - 01:02:23.170
And it's, and it's really, look, it's, it, it's. Stop repeating all of the work that your vendors have already done when it comes to, when you' purchasing off the shelf software.
Etienne Nichols
01:02:23.890 - 01:02:25.370
Yeah, right.
Sandra Rodriguez
01:02:25.370 - 01:03:11.530
Like Especially if you're, if you're going to use as much as the, as much of that functionality that's already built in as possible. Because, you know, like the green light gurus of the world or your ERP system or whoever else you're using.
Again, those, those companies have their software quality assurance activities internally. They follow their system development lifecycle. They're doing the testing, they're doing the documentation, they're doing the bug fixes.
They're doing all of that stuff already for you so you don't have to go behind them and spend incredible amounts of time and effort and killing trees just to prove that it works, that it works the way your vendor said it was going to work.
Etienne Nichols
01:03:12.890 - 01:03:46.410
One of the other things that I think is really important is sometimes we start mixing our stories about what this is applicable to.
You're not talking about the product, you're talking about the processes that support it and could potentially impact the product, impact the patient. So, I think that's important. Look at the scope in the draft guidance. For those of you listening, again, think. Look at the show notes.
We'll put all the links in there as well. This has been really fantastic and fun. I don't know if you have any last bits of advice, Sandra.
I, I hope that it cools off where you are, but any, any last piece of advice for companies.
Sandra Rodriguez
01:03:46.490 - 01:04:58.430
Thank you. Thank you.
Yeah, I mean, I would say to the folks on the podcast, you know, like I said, there is a herd mentality in life sciences and, you know, unfortunately it's, you know, no one's ever really trying to be number one, but there's a lot of initiatives going on right now, and there are companies that, you know, people love to put the information out there. What they've done with CSA, what it is, what it isn't. There's a lot of resources from the FDA itself, working groups, I would suggest.
You don't have to take my word for it. You know, there are some really, really smart people out there who've been in the trenches. They've done this again.
They've been following this approach for years now, starting with the pilot eight years ago. Look for them. The one thing I know about Life Sciences is people love to share information.
So, get involved with those working groups, network with your peers, educate yourselves.
You know, you as a company have to determine yourself how this guidance document is going to impact you and your processes, because ultimately, you're going to have to make that decision.
And ultimately, you're going to have to defend your decision to an Auditor, if and when you know that, that that inspection or that audit happens to you.
Etienne Nichols
01:04:59.470 - 01:05:07.710
That sounded like a conclusion. But I have one more question about those working groups you said to get involved in.
Can you give just a little bit more detail and I'll put a link in the show note as you talk?
Sandra Rodriguez
01:05:07.710 - 01:05:13.100
Yeah, yeah, sure. So sorry, I, I see myself freezing. I don't know if the audience does.
Etienne Nichols
01:05:13.260 - 01:05:14.140
You're fine to me.
Sandra Rodriguez
01:05:14.140 - 01:06:28.510
Yeah, yeah. So, you want to look at the case for quality working group within the MDIC, right. The Medical Device Industry Consortium. That's a great start.
Cisco Vicente. His name is Francisco Vicente. He is the, he goes by Cisco. He is the program manager of the Case for Quality at the FDA. He's done a lot of webinars.
There is a lot of content out there, easy person to talk to, you know, if you want to hear it from the horse's mouth himself. I know we have webinars on our site that are on, available on demand and you can hear them talking about things.
But look for, there's a, again, a lot of information out there. I would highly suggest, though, that you look into the MDIC and again, they have virtual events all the time on different topics.
You know, they have a Make Kappa cool program. So, if you're struggling with, you know, is, you know, what is everything a kappa, you know, there's, that was a pilot.
There's just really, they're just putting a lot of good information out there. And again, this isn't just coming from the FDA.
These working groups are companies like yourselves working with the regulators, working to again move the industry Forward into the 21st century.
Etienne Nichols
01:06:29.070 - 01:06:46.510
Fantastic. Well, thank you so much, Sandra. Thank you all.
For those of you who are in our audience, all the great questions and the activity in the chat, we'll be sure and get all those links in the show notes. We talked about a lot of them. Hopefully I can get them all and look forward to seeing you next time.
We'll let you all get back to the rest of your day. Thank you so much.
Sandra Rodriguez
01:06:46.830 - 01:06:47.950
Thanks for the invitation.
Etienne Nichols
01:06:48.590 - 01:08:10.180
Thank you so much for listening. I hope you enjoyed this episode. If you did, reach out to Sandra on LinkedIn, let her know I'd personally love to hear from you via email.
It's Etienne Nichols, Greenlight Guru. It's just Greenlight Guru or look me up on LinkedIn.
If you're interested in learning more about our software built for MedTech, whether it's document management system, our CAPA management system, or our design controls and risk management system or the electronic data capture for clinical investigations. This is software built by MedTech professionals for MedTech professionals. You can check it out at www.Greenlight.Guru, finally, please consider leaving us a review on iTunes. If you've never done it before, you know what these things doing new things will help stave off Alzheimer's is what I'm told. I don't know. Check it out. It helps others find us and it lets us know how we're doing. So be sure and leave us a review on iTunes if possible. Thanks again.
Take care.
The medical device industry is nothing if not unique, so we built software that works the same way. Greenlight Guru is the only quality management system designed by medical device professionals to meet the unique needs of medical device companies. Our cloud-based platform allows companies to bring safer products to market up to three times faster while reducing risk and lowering cost. Visit www.Greenlight.Guru today to request your free personalized demo of Greenlight Guru.
About the Global Medical Device Podcast:
.png)
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.
