Understanding the Right Process Validation for Life Science Manufacturers and Distributors.
Good day everyone. Thank you for taking the time to join today's webinar, Busting the Myths of FDA Validation and Business Systems. My name is Sean Barbera. I'm the Marketing Director here at Navigator Business Solutions.
Today's executive webinar. Will be presented by Archie O'Leary, Vice President at Arbour Group, your one-stop provider, of regulatory compliance and testing needs. Along with Archie, Ralph Hess Vice President at Navigator Business Solutions an SAP Partner serving Life Sciences companies.
The Arbour Group is the leading provider of regulatory compliance products and services for the Life Sciences industry. Arbour Group helps clients achieve and maintain a state of compliance in an effective and efficient manner.
Navigator, companies come to Navigator when they find their ability to grow and or adapt is being limited by their current systems. Navigator has developed life science industry expertise over the last 13 years delivering SAP offerings configured to our clients current and future needs.
If you have any questions during the presentation, please submit them through the GoToWebinar control panel and we will have a Q and a session at the end. With that, I'll pass control over to you, Archie.
Perfect. Thank you, Sean. Hi, this is Archie O'Leary. I'd like to add my welcome to the webinar. What my portion of the webinar, we're going to talk about, validation requirements and I will go through some, just some brief slides in terms of what's required, what's the expectation, and also talk about some of the challenges and a couple of the myths that are associated with validation.
FDA Validation
So I'll just start with a brief explanation of FDA validation. So the response just in general, as we all know, the responsibility of the FDA is to protect the health and safety of the general public and it, as it says, veterinary drugs, vaccines, biologics, food, and you know, most of us only hear about the FDA when something goes wrong, and because they get involved when that happens. And this applies to also in the Life Sciences industry, you know, the principles of FDA validation are to make sure that things, can be tracked and trace when there's something that occurs for the sake of inspection or the sake of a recall and et cetera.
FDA Validation – What is required?
Okay. What is required for FDA validation, FDA validation is typically referred to as, you may hear this a lot. Part 11 compliance. And what that means is it's in the federal Part 21 of the code of federal regulations, Part 11 Specifically it's for electronic records and signatures, but it's much more than that. It applies to electronic records and signatures and the related rules establishes requirements. The computer systems use to create, modify and maintain electronic records and signatures are subject to validation, et cetera. As you can see, computer systems including hardware and software controls, must be readily available for inspection. So the point of all this is, in the manufacturer of a pharmaceutical product or a medical device, FDA needs assurances.
That the product you're manufacturing has been manufactured to certain standards and processes and that the appropriate quality records are being maintained. Quality records such as, expiration dating and tracing and serialization where things shipped to, you know, the whole genealogy of the product. The FDA says to you, manufacturer, you need to have these records, verified hence software validation comes into play. And it is an expectation of any and all companies who are subject to FDA oversight. So any and all companies that, sell in the US. So FDA oversight applies to US manufacturing companies as well as international companies that sell product in the US and vice versa. If there's a company here that sells in Europe or Australia, we have to, the US companies have to be compliant with that. But all of those regulations are pretty much harmonized these days. There's not truly a lot of difference. So with that background, with those two,
Archie, I was going to actually ask that question because we, we've seen some of our customers as of late come in with requirements for some EU type of regulatory requirements. And I was even as a panelist here, I was going to ask that question of how similar are the requirements? Do you know across the EU and in the U S and other markets?
Sure, yeah. They, they're very much harmonized. In the FDA, USFDA is 21 CFR part 11. In, the European union, it's, annex 11. So, those, several years ago, those requirements were harmonized. They are just, so close, there's almost no distinction in terms of how, what's in scope, how do you address risk deliverables and et cetera.
And we get involved with international companies all the time. And I can assure you there's these days there's virtually no difference. This applies to Canada, which has health Canada, Australia and New Zealand, which is the Therapeutic Goods Authority, and other international companies. Great. Thank you.
Validation Summarized
Validation Summarized. What is it all mean, it just means that you have a software system that you're running in the manufacturer of a product, it says that the FDA says you have documented evidence, that there is regulated functionality, has been successfully tested for its uses. So regulated functionality is anything relating to the product, the manufacturer of the product or the materials they go into it. So parts of purchasing all of manufacturing a warehouse management because that is that if you want to be tracing, expiration dating and any type of traceability that has to occur.
It does not include General Ledger. The FDA is not concerned nor does it cover a general ledger transactions, financial transactions and the like. Another good example is sales orders. The scope within sales orders as it relates to where the, where the product went, what was on the packing slip, that sort of thing. So it can be traced, but, there is no concern nor no testing that relates to pricing or anything like that. So those are a couple of examples. Security and access controls, e-signature and audit trails. These are critical. That Bullet two is specifically Part 11. It has to be tested. Evidence needing test cases have to be put together to make sure access is controlled and not just anybody can go up to your computer and log in and the quality inspector. Obviously that's not allowed. So that control is there.
There's e-signature in terms of login and password security and audit trail, which is a critical one, which says that any all transactions have to have an audit trail date stamped and timestamped. And that audit trail cannot the modified, and we've run across some software systems where that hasn't been the case so rarely, but it does happen. Procedures are in place for the use of the system. You know, do people know how to use the system and the software, they have to be written procedures, they have to be trained on use of those procedures and that training record and that training has to be evident in a, in a record of some sort, paper, electronic, doesn't matter. It has to be evident and that change control is maintained, so that as you change the system, you update and validate as appropriate.
So that's, that, the regulations on validation are much longer than that. But, that really sums it up. Point one being critical, for intended uses meaning specific configuration.
What has to be Validated?
21 CFR Part 11
So specific configuration, access control procedures, training and change control. What has to be validated? Well, it depends. Finished pharmaceuticals and medical devices. It varies and I'm not going to go through this list, but it just to give you an idea of what the FDA is concerned with. As you can see on the left side, you wander down there packaging and labeling, distribution procedures, on the right side of batch production records, distribution records, complaint files. Many people don't know that complaint systems when clients have or customers, consumers have an 800 number that they call in to register complaints, those have to be filed and followed up and those systems have to be validated. So that's an idea of pharmaceuticals and, similarly for medical devices, as you can see in parenthesis, those are just the regulatory citations. But, same type of controls. And if you, as you look through the list, it said, you, you'll look and say, yeah, that kinda makes sense. You know, they want to know when it was made, how was made, where did he go? Did you have control over it? Are you manufacturing from the right baseline? Meaning the right device master record or there, right, batch master record as appropriate, that sort of thing.
Validation Deliverables
So you go through this validation. You test to its intended uses and here's what it looks like. These are industry standard or best practice standard deliverables. It turns out to be a lot of documentation, just so you know. But when a client is inspecting the customer or the FDA's inspecting a customer, a manufacturer rather, they're going to expect these types of things. And so it's not, you can't, you don't just do system test and UAT test and then say, Oh, it's in there, or repurpose UAT tests. They have to be separate deliverables that demonstrate that you're, you have a quality system in place and you're following validation processes that are contained in your quality system or your software development life cycle, your SDLC. So they are a validation plan, outlines what you're going to do, how are you going to do it, what's in scope, what's out of scope.
It makes sense, right. User requirements and functional specifications are quite simply the intended use. That definition we talked about before, it takes the configuration that an integrator that would set up, so for example, Navigator, would set up configuration for a client and then we Arbour Group would come in and identify, pull out, the regulated functionality that's contained in there for manufacturing is called Good Manufacturing Practices, regulations, GMP. And we would identify those and for those regulated functions we would write various test cases, IQ, OQ and TQ test cases, which simply means it was installed properly, IQ. Do the functions operate as they should, which is most of the validation. The OQ. And does the system work end to end, the performance qualification testing. And, and that third bullet is, in a validation that, could be as little as eight weeks, as much as 12 or 15, depending on how complicated the solution is.
That takes up most of the time. That's most of the effort to pull these test cases together, execute them, documented screenshots, you know, all that sort of thing. And then it required requirements, traceability matrix, cross references, all the user requirements, functional specs to a test case. Just so it's for ease of inspection. It's literally a matrix for ease of inspection. And then the validation summary report, it kind of does. What do you think, what do you think you would do? Summarizes everything, recaps, what did I do? How many passed, how many failed, how am I going to maintain change control? So, that real quickly is the FDA expectation in terms of what rules apply, what should be in a validation, what the documentation should look like.
Validation Myths & Challenges
So with that we can get on some, myths and challenges of validation.
Which is kind of the heart of what we want to talk about here. Misconceptions, [MYTH] applications in the cloud do not require a validation to the still we hear this a lot. We hear it from software developers, we hear it from some clients and it's just, it's just not true. And the reason it's not true is because the definition of validation is testing to intended use. You can't have an intended use without a configuration, without interfaces, without a specific use case. So now, all software developers including cloud software developers need to make sure their systems work properly and are validatable. That part is true. So it may be, it's just a way of interpreting what's being said, but anyway, out of the box.
Yeah. And I think even running counter to that, Archie, I've actually had some people say, well, it's in the cloud, so it can't be validated. And I think that's a version, you know, software releases and updates, which you're going to address in just a minute. But yeah, when you talk about cloud, you hear when you hear one or the other, right? Either it doesn't require validation or it can't be validated. And that is just not true.
Right, the next one is [MYTH] cloud hosting providers do not have to comply with customer compliance. The client, the one using the software, the customer will say, who's deploying the software? The manufacturer, is responsible for compliance. So this myth is that cloud providers have nothing to do with that. That is also not true! The certificate holder, meaning the one the FDA holds responsible, the manufacturer user of the software has to ensure the cloud provider has certain minimal standards in place to make sure that policies, practices and procedures are such, are in place and to the extent that they protect, the data integrity, that data integrity with the cloud providers. One of the things like how do you handle maintenance updates? Are you those procedures in place? Are they reasonable? Do you do backup and recovery? Do you have a disaster recovery plan? Those kinds of things. Now you may say, well, how am I, Mr. Small User going to influence a cloud host provider? Well, quite simply, it's either through an audit and this audit doesn't have to be anything dreduous. That audit just make sure that you either have a questionnaire to the cloud provider and you make sure that they comply with your quality system, which is the requirement. And they may also take a quality agreement. Many Cloud providers, particularly in Life Sciences are used to this and they probably already have a quality agreement laid out. It tells you how they do maintenance, how they do updates, how they do releases, and how they are compliant to include how often, releases come, how long do you have to validate before you take the release? All that kind of thing.
As little as five or six years ago, that was a bit of a mystery, but that, that mystery has pretty much been solved. The cloud hosting providers, providers get it, now. Similar to that [FACT] software developers can pre validate this kind of an offshoot of that first one. It's true. They can pre validate, they can, we've had engagements where a software provider, can you validate our software? And we said, yes sir, we can. However, this doesn't take the place of your, of the customer so you're not supplanting the customer's responsibility. And their answer is yep, we know. We just want to give that customer the assurance that we the past, you know, mustard, which is great. [MYTH] Validation has to occur after each software release update. That would be exorbitant obviously. What has to happen is change control, the customer has to have, a change control process that evaluates releases for their impact and tests appropriately accordingly.
After that, for example, release one might be just general ledger. The requirement then would be to have a process that says, I looked at this. It's all general ledger. There's no regulatory or GMP process. Sign it off. Do nothing as far as validation testing is concerned. Scenario two. You may have and it affects inventory, well that is a regulated function because of item characteristics and the like, that has to be validated. So, you do an impact analysis, identify the functional processes that were impacted by the software release. Select those test cases that apply to that, rerun them. And if they run successfully, you're good. If there's new functionality you may have to write some test cases to address that new functionality, but the point is, change control testing is far, far less onerous as opposed to a validation.
And another [MYTH], Excel spreadsheets are exempt from validation. This is quite common. No they're not. If Excel spreadsheet has quality data such as characteristics of a test. You keep tests, records in there for, you know, lab test records or something like that, or calculations that are used for manufacturing process control. They're in there. Those spreadsheets have to be validated and it's, it's reasonably straightforward. A matter of, you know, confirming the calculations, making sure access is locked down and there's a procedure in place for use of the spreadsheet.
Validation Challenges
So those are some of the Myths and then as far as the challenges, It's a matter of expertise. Challenges are a matter of expertise, interpretation of regulatory requirements. What's GMP, what's not, how do you approach risk assessment? How do you put together a test strategy based on the regulatory requirements? That's something, this can be, this scale, can be resident within a company. It just depends on the company and they want to devote resources to that, understanding 21 CFR part 11. It's reasonably straight forward. It's just, it kind of remains a mystery in general, but it's reasonably straightforward. There has to be specific testing. You cannot assume the testing, as I mentioned earlier in UAT and that sort of thing. You have to specifically outline these test cases.
As I look at that, People get intimidated by that., Part 11. You know, it's, it really is when you break it down and that's all get into some of the screenshots that we're going to show. We'll talk a little bit about that.
Perfect. And then regulatory risk assessment. What that means is the FDA requires you, test appropriate to the risk and, that means you don't have to test everything exhaustively. There can be variation in how the depth and breadth of testing based on a risk assessment. Now that risk assessment is going to say, things like, expiration dating is high risk that that's going to be in every risk assessment. So you're going to test expiration dating in all its facets, whereas other things will be test less slightly. You can test more likely if you have good procedural controls in place and that sort of thing.
But, there are standards out there and practices out there. That's a challenge for most people. And then effective change control and other software development, change control and another SDLC procedures. Why is that a challenge with just the procedure? You're absolutely right. The catch with software development, life cycle procedures are many times the procedures are not kept up to date. And what we see is companies get dinged in an inspection, not for, not having a procedure in place. But not following the procedure, meaning procedures written X years ago. They've changed it. Their processes are great. It's just not documented. So the FDA expects that your written documentation and what you do, are in sync.
That was awesome. Now what we want to do with this webinar was not to make it any huge sales pitch. We wanted it to be informative. And I think that what Archie just provided in terms of content, you know, I find it great cause I learned something from them every time I listened to him. For instance, I just made some notes here that I didn't know that complaint systems were something that would be under regulation and validation. So what I wanted to do was just zip through some sample screens here that, that kind of brings to light some of what Archie was talking about. And I made the comment earlier that I find that a lot of our customers when they're starting to talk about FDA validation, really get run over intimidated by the part 11 and e-signature and all of the, kinda, if you read it deeply, may over-interpret what it's really requiring. But as, as we look at just some of the base functionality of, of your most popular ERP. Out here I'm showing SAP Business ByDesign is to provide some context here.
Security and Control
You know, security and control, which is all key and essential to part 11. Well, you know, a documented user account policies is a big part of that. Minimum password requirements, password expirations, automated log-outs, discreet application authorization. All of those things that really are, are known as just good practice. Best practices today will help you pass the validation, for security and control.
Process Validation and Controls
Having proper controls in place. So as, as we take a look at this particular screen, you have a workflow which requires approvals. So you're properly controlling access to information, approval of any of any documents which are going to be processed through the system transactions that are going to be processed through the system up to and including, having PINs, electronic PINs, to reinforce electronic signature. So if you really need it on key processes and key documents such as in this case it's showing a supplier product approval. The fact that we're going to be allowed to add this particular vendor or supplier to our approved supplier list, that may require an electronic signature in the form of a PIN, electronic signatures in general.
Electronic Signatures
So as Archie made mention, as people are logging onto the system and as you have proper access control through your password and, and user authorization, each of each document, each piece of master data needs to be user, date and timestamp. So as, as we're taking a look at this particular screen, we've got an item master which is keeping track of all the changes date and time it was made. Who made that change and actually what the data was that was changed on that particular record. Same thing with transactions or documents. So here we're looking at a sales order and the changes that have been made to this particular sales order. So you can imagine if this was a, we'll show in just a moment bill of material, any or a purchase order any of those types of controls in quality data that to be validated, you have proper electronic signatures on.
Good Manufacturing Practices (GMP)
Archie referred to Good Manufacturing Practices. And really I just pluck this definition right off the web, which is a system for ensuring that products are consistently produced and controlled according to quality standards. It's designed to minimize the risk, as Archie had mentioned, risk mitigation involved in any production that cannot be eliminated through the testing of the final product. So what does that mean? It means that you have a good manufacturing process in place. You have good workflow requiring proper approvals with a trail of e-signature and a trail of traceability throughout it that enforces good manufacturing practices and mitigate any risk associated with the production of that product. I think we all have heard recently that the FDA is weighing in, in an expedited manner on a lot of these COVID-19 Tests. That's exactly what they're going in and looking to these test manufacturers to make sure that they have GMP in place.
Device History Records
Device History Records. So again, as we take a look if we're in the biomedical device field, taking a look at having tight engineering and process controls things like engineering, change orders, engineering change order approval workflows, having those types of controls in place to make sure that the quality system, which is, which is really kind of the overarching guidance on all of your business processes. Basically ensuring that everything that you define in that quality system is being done in this case, in the form of good engineering, change control management to support again, that GMP.
Track and Trace
We've all heard of track and trace. Archie mentioned it, you know, this ability to be able to know what went into a product where that product has been delivered, where it sits in the warehouse, what transaction has been performed on it, who did it, what date, what time. All of that track and trace is readily available, through this screen that I'm showing on ByDesign. So really having a system in place that supports that is key and essential, to meeting the validation challenges.
Recall Management
And then as we take kind of a last look at it as we've gone through and we've taken the sales orders, and we manufactured the product using GMP and we've kept track of where they've gone using track and trace, having that ability to have CAPA cases, being able to do recall being able to research and identify and quarantine the product. It's all key and essential to an overall system solution that's going to support your process validation with the FDA. So those were just a few screenshots that I wanted to be able to show to bring to light some of the, the points that Archie spoke about. So Sean, I guess we'll go back to you kind of moderate the last pieces of this.
Questions and Answers
Yeah. Thank you Ralph. Thank you Archie. We have a couple of questions. If the attendees have more, please just type them in and I'll get them over to Archie and Ralph.
One question. Do new SOPs have to be written once a software solution has been validated?
Okay. Yeah. Archie here? I'll take it.
Probably in other words, SOP has to be in place. I mentioned your procedures have to be in sync with your practices. So once a new software system comes in because of software interfaces with you know the flow, you know, on the manufacturing floor or put or other process those software procedures, those SOPs will probably have to be modified and the modification will be as it relates to how the software is used. Maybe the new SOP eliminates two steps, adds another, what have you. Okay. Yeah, they do that have to be rewritten, but they will in all likelihood, would have to be modified. And that is a requirement that modification has to be in writing and users have to be trained and the training is just, you know, read and understand, sign a training record and they're done.
Okay, we got another one here. I guess it could be either Archie or to Ralph.
What regulatory process should be followed related to periodic software releases and updates.
So we all know in the cloud, most systems are updated quarterly or yearly. What has to be followed.
I'll let Archie take that one. That was one of his bullet points, so that's great.
Okay. Yeah, the, the, the quarterly releases, this is one that is surprisingly misunderstood also. Software is validated and everything's great. Then you get your first release and subsequent releases. What has to happen is it can be very straightforward. Most companies have a change control process in place now because to run a business, you need to change control process. You just don't install software and hope it works. Yes, so anyway, that change control process needs to be updated or modified to accommodate validation, which means each release has to be, I'm judged for impact. And I think in my example earlier I said if it has no GMP or regulated functionality, you still have to have documentation that I looked at this, there's no regulated functionality, no further validation testing required, signed off by at least quality and probably quality and IT. Many times that's going to have, is going to be regulated impact and then same process follows, impact assessment, identify is there an impact what is affected and then you know, test accordingly which could mean rerun test cases to make sure that they still execute and, or if there's new functionality, of course new test cases would have to be written, executed and documented.
But it really reduces the burden of validation. I mean, I, I can't imagine revalidating after each software release that would just be unworkable. It's a matter of updating the current Change control process to accommodate validation.
Thank You
Great. Thank you Archie. With that, that brings us to just over the 30 minutes we promised that we would take from your day. I want to thank Archie and Ralph for taking the time to present some of these myths. And the validation and business system approach to the FDA process. I want to thank everybody for attending today. Just a quick note over the next few days, a recording of this webinar will be made available. We will send you a link to it so you can review it or share with, uh, your coworkers as well. If you do have any follow up questions for either Ralph or Archie, please feel free to reply to the webinar communication, email address and I will make sure those questions get routed appropriately. Again, with that, we'll end this webinar. Have a great day, rest of your week. Thank you for attending.
