How is Lab Compliance Changing? An Interview With JAF Consulting

No one relishes the thought of an unexpected visit from the FDA. 

But as technology continues to evolve (and perhaps, evolves faster than regulations can keep up with), you’re right to wonder if every piece of software you use is helping or hurting your chances of meeting regulatory standards. 

We had the honor of sitting down with Joe Franchetti, CEO of JAF Consulting, recently to get his take on how AI and CSA are changing the game for lab compliance, and what labs need to do to stay ahead. 

JAF Consulting is a consulting firm specializing in regulatory compliance for the pharmaceutical and manufacturing industries. This exclusive interview will give you an inside look at how firms like JAF think about and assess compliance risk, as well as the type of work they do with their clients to help them meet FDA regulations and GxP standards. 

Key Takeaways

This is a lengthy interview; if you’re in a rush, the top takeaways are:

• A risk-based approach is essential: CSA (Computer Software Assurance) prioritizes testing based on risk to patient safety, product quality, and data integrity rather than testing every function regardless of impact.
• Trust but verify your systems: While software vendors may claim their products are "validated," the ultimate responsibility falls on the end-user organization to ensure compliance within their specific operational context.
• A LIMS can be a great asset for labs: Successfully implementing a Laboratory Information Management System demands more than just software installation; it requires rethinking processes and allowing for a learning curve.
• Partnership is key: Effective validation involves collaboration between consultants, software vendors, and end-users to ensure systems meet regulatory requirements while supporting operational needs.

What does JAF do? And who do you guys serve?

JAF is a regulatory compliance consulting firm that serves pharmaceutical and manufacturing labs. Over the years, we’ve evolved as technology continues to change. 

At our core, a lot of what we do is regulatory compliance: specializing in FDA regulations and FDA regulatory activity, as well as some ISO standards, and then even more so, some international regulations.

Now let’s talk about AI. How has that played a role?

AI has definitely changed things for labs.

We're working on digital transformation with AI-enabled applications and helping companies become ready to move into that state, as well as validating those applications. Over the years, we’ve:

• Run data integrity and risk assessments
• Developed quality management systems for organizations
• Run training and education
• Conducted audits of all kinds, whether it's an internal assessment, external vendor audits, supplier audits, clinical audits, and we work across all the different regulatory pieces. GMP, GLP, GCP, and then getting into some of the accreditations like CAP and CLIA.

Many people are wondering, especially around AI, ‘how do we implement these systems?’ And that's always a difficult question to answer, because everybody's organization is slightly different.

About that, are AI systems compliant? Is it safe for them to interact with sensitive data?

Take this meeting recording, for example: the criticality of the information that's being shared here is minimal. It’s just not applicable to regulatory standards. 

But as you get into these AI systems, especially on the clinical side where you start moving into software as a medical device where those clinical systems are now making clinical decisions for the healthcare practitioners and part of the clinical trial team when you get into executing clinical trials, some of the systems have that capability that they're starting to integrate.

So the level of risk starts approaching a higher threshold for risk-tolerable activity. 

“When these tools are used more to make clinical decisions, determine the quality of a product, or make some sort of predictive analysis, all of this is associated with risk. It’s not only about complying with regulatory expectations, it’s about ensuring patient safety.”

When these tools are used more to make clinical decisions, determine the quality of a product, or make some sort of predictive analysis, all of this is associated with risk. It’s not only about complying with regulatory expectations, but ensuring patient safety, whether in a non-clinical or clinical situation, during protocol execution, or a manufacturing activity.

You need to understand and assess the risk. 

OK, let’s talk about validation. The FDA released guidance on CSA over CSV – where do you stand?

CSA is the primary of the two, but CSA and CSV have historically had different approaches. 

When validation first came about, it was primarily in manufacturing and slowly moved into technology. But as risk tolerance decreased, people started demanding more testing for everything, even low-risk functions that wouldn't impact safety or data integrity.

The example I use is when you hit the F1 key on your keyboard, regardless of what application or system you're operating in, a help screen pops up. Now, how important is that help screen to you in executing that particular task? It's a very small risk as to whether or not we would have any effect if that screen came up.

How do you approach risk assessment in validation?

Before, we would test every function of an application, even the little non-risk activities. 

But the paradigm has shifted. We've been practicing a risk-based approach and implementing it within our clients for a while, the better part of 15-20 years. And JAF has only been around for 24 years. 

So we've been focusing on risk: 

• What's the risk of that particular process? 
• How does it affect patient safety and product quality? 
• How does it impact drug efficacy?

And so on.

You start by looking at systems in regard to those risks, and break them down into what type of risk each function has. For instance, does it impact data integrity? Would it compromise data? And so on. When you start shifting that paradigm, you start changing your approach.

Before, risk assessment was identified as the risk of getting caught by the FDA or any other regulatory association and not doing validation. 

It kind of was a joke many years ago because, 'Well, we don't think we have to do that because of all these... so we've assessed our risk, we don't have to validate.' Well, in fact, you do have to validate; you just may not have had to get to the same level because the level of risk isn't as high.

How does this shape your approach to CSA versus CSV?

We're now focusing more on or concentrating on those higher-risk processes, higher-risk functions, and functions that could possibly impact the integrity of the data, as opposed to some of the lower-risk, non-consequential functions of a system or overall platform. 

Because there are different levels, too, and different risks based on whether it's a software platform or even the hardware and infrastructure components, you're looking at different risks across each of them.

CSA is essentially a part of CSV. It's focusing more on the risk process. There are a number of different differences between the two, but primarily with CSA, you're looking at software reliability based on that fit for use or intended use, based on the risk to patient, product, process, or data. Whereas in CSV, it's just you're testing everything.

When testing software, how much depth do you go into? Do you use the software yourself?

We have deep partnerships with several software vendors. 

When we implement software, we try to partner with the organizations that the software belongs to. Often, we partner with them to ensure they fully understand and are educated.

There are some platforms that were developed with an idea and a strong cup of coffee, and they put them together, and they work great. But they don't have a strong software development methodology, which is crucial to the quality of the usability of software.

So when we partner with these organizations, we provide them with that regulatory research side of it because we want them to continue to develop cool stuff, cutting-edge, bleeding-edge technologies, and work with AI so that the end-users will benefit from it.

When they have regulatory questions, QA questions, validation questions, usability questions – we ask them to talk to us, and together we can work through those questions to feel more confident in delivering validated software products.

That’s quite a lot. Do you have to do any training on the software?

We may go through training, individual training, or anything outside of working with the client. 

We'll work with them in helping them define those deliverables that they should be working on, and they can contribute to that validation process. Then we will have somewhat of an inside track, to say, 'Well, here are requirements that you don't have any capabilities to support as part of your validation.’

We help labs understand where their line is in the sand, and the value is that turnkey process where we can tell them, ' Yes, we can get you almost there. You're still gonna have to do a little work to get it validated, but we can get you almost there.' 

And then we can pick it up, going beyond that in the intended use of that application to make sure all their processes are fleshed out, and are working as they expect them to.

What are some things that you see clients or potential clients forget in the validation process?

I think it comes down to trust, but verify. 

I have these conversations with our partners and with other companies that we've talked to or met at conferences and symposiums. They'll say, 'we're validated,' but it's very difficult for them to validate an application. They can move the needle pretty close, but they can't get it there 100%.

The end-users see a product, they know they have to use it, and a lot of times, they'll say, 'We don't need to do validation on here because of XYZ.' And I like to turn that around a little bit and say, 'Well, why would you need it? Why would you need to do validation? Tell me why you need to do validation on this particular product?'

Lab systems, even standalone laboratory applications, are fairly complex. And the standalone lab operations are now tying into other databases and other AI models as well. So you really have to have a complete understanding of this.

That's why I think the FDA and other regulatory agencies aren't going to walk in and dive right into validation deliverables. They start going through an organization, and they start pulling those data threads, and they start seeing where data integrity issues are being challenged. And if those challenges are because the system allows changes without an audit trail, you're removing some of that metadata and context from that particular data.

“At the end of the day, we must recognize and realize that the FDA bases its decision on data that we provide them. So they have to have a level of trust in that data.”

At the end of the day, we must recognize and realize that the FDA bases its decision on data that we provide them. So they have to have a level of trust in that data. And how do we build trust with the agency? Well, we perform our validations. We have our programs. And we have our procedures. And we follow those procedures because those procedures are the interpretation of how we expect to comply with the regulations.

As organizations are becoming or getting inspected, they run the risk of, 'Hey? If we don't have those processes, that's going to erode the trust.' And having a process and not following it all erodes trust as well. If those missing pieces cascade down and waterfall down and cause further challenges and troubles downstream, we are now building a program that is going to drive us out of compliance.

But having a process and not having 100% of the attributes tied into that process, that's okay. 

How have you seen a LIMS help labs improve their operations and data management? 

One thing we have to remember is that computers are pretty stupid – it all goes back to how well they are programmed to do a task. 

Through that validation effort, you're verifying that the task is being executed the same every single time, and doesn't change. It may change based on inputs. But if the same input is put into a system, it's going to produce the same output.

A LIMS will, if you configure the workflows correctly, you configure all of your processes correctly, force compliance. You also force doing things the wrong way if it's defined the wrong way. 

When these systems force compliance, they force the activities. 

There are gates, approvals, and everything else to move data through. You can't mess up. For calibration programs, a LIMS will notify you when the equipment is ready to be calibrated. A LIMS allows you to register a piece of equipment if it's in this calibration period, and won't allow you to do it if it's outside of this calibration period. It'll let you know when equipment's down, up, and under maintenance.

In other words, a LIMS is as good as you set it up to be. 

People think, 'Oh, yeah, I'm gonna buy a LIMS. I'm gonna implement it.' There's such a learning curve. There's a lot that these end users might not know, or might try to automate without thinking it through.

Can you give a specific example of how LIMS helps with day-to-day lab operations?

All that said, a LIMS can bring incredible value to labs by documenting and automating processes. 

For instance, let’s say you’re making a reagent or making a buffer. The LIMS walks you through and is connected to balances, so you're able to electronically transfer information, and steps you through that process. That's awesome, because at the end of the day, if it walks through everything, and you have all the checks and balances in there, you can say we made this buffer according to our process. Now, if our process is wrong, it doesn't matter. But we followed our process.

So when you go through investigations in the laboratory and there are problems – I'm going to test a particular sample, that sample is not going to fall within my specification, I'm going to have to put a laboratory investigation in place – now I can go back and say, were my buffers done? Did I use the right samples? Did I check out the right samples? Were the controls within specification? Did the equipment operate the right way? Do I have the right system suitability or controls coming off the system? 

In other words, I have all of that information right there to perform that investigation. A LIMS is invaluable for that.

How does this help with regulatory compliance and traceability?

It all goes back to having a complete audit trail for your lab.

From staff training to test results, you can tie all of that information in. And so when you do your investigations, you can then come out and say, 'Yes, this number is out of specification. We can retest this now.'

There are many different components to the LIMS application, including different modules. It's important to understand that implementing all of those components will help you force compliance within a laboratory, prepare you for those laboratory investigations, and provide everything in a very compact and concise manner. And it makes the labs that much more efficient because you're not searching for information. 

Looking to Improve Compliance in Your Lab? Schedule a Demo of QBench LIMS

As we’ve seen in this interview, a LIMS can be a fantastic asset to bolster your compliance practices, but you need the right blend of ease-of-use with powerful automation capabilities.

But only if you have the right LIMS – and if it is implemented in the right way. If you are looking for a LIMS that provides:

• Robust integrations and API access
• Automation
• Reporting
• No-code configuration
• Ease of use
• Excellent support

Along with an experienced implementation team that can guide you every step of the way, where will you turn? We’d suggest QBench.

A LIMS should help your lab work smarter and with unparalleled flexibility to drive whatever the future brings. It’s one of the reasons we’re so proud that this commitment continually gets recognized by G2 and why QBench ranks among the best LIMS on the market. Click the button below to schedule a demo and see for yourself.