Mettler-Toledo International Inc. (MTD) Earnings Call Transcript & Summary

Hello, and welcome to our webinar about Data Integrity and Common Myths around this topic. My name is Christoph Jansen, and I work for Mettler-Toledo as a Technical Key Account Manager with some passion for the topic data integrity to support large pharma companies. I'm a chemist and worked most of my professional life with analytical instruments. I already gave a number of webinars around this topic, and many of them with Bob McDowall as our consultant. Today, I have Mr. Bob McDowall here with me. He recently wrote a number of papers around misconceptions in data integrity, and I think it's worth discussing some of the topics. Welcome, Bob, can you please introduce yourself?

I'm Bob McDowall. I'm currently an independent consultant for some 29 years. I started life as a forensic toxicologist where I worked for 6 years analyzing dead bodies and then moved to the pharmaceutical industry, where I worked for 15 years for 2 major pharmaceutical companies, Smith, Kline & French and [ Wellcome ] Research. And then, as I say, 29 years ago, I became an independent consultant. My background is really analysis, but it is also implementation of computerized systems, validation and coming out of that data integrity and interpretation of Part 11 and the various computer regulations. My role here is to try and bring my expertise to answer some of the questions that you're going to offer me, Christoph.

Yes. And you wrote a number of books.

I have written a number of books. I edited the first book on LIMS in 1987, way back in the last century. I have 2 additions of validation of chromatography data systems and more recently, a book on data integrity for regulated laboratories. I've also been involved in contributions to good practice guides for IT infrastructure, the second edition lab systems guide and also the records on data integrity guide in 2017 and 2 subsequent good practice guides. Apart from that, I know absolutely nothing.

Before we start the discussion, I have to make a legal disclaimer. Although we seek to ensure accuracy, we might have made mistakes and some of the statements we give are based on our interpretation of the regulations, facts and observations. Please check the facts for yourself before making any decision. We also don't give legal advice here.

Bob, the pharma world has changed a lot since we first discussed about data integrity starting in 2014. By then, I had a lot of discussions with pharma companies explaining the benefits of our software labs for electronic records. A quite common reply from QC and lab managers was, our IT will never allow connecting an analytical instrument to our company's database. As I said, I still rely on paper more than on electronics or computers. Computers are way too complicated to handle. Data get lost easier or another frequently heard argument was I would need to replace all my analytical instruments to have network connectivity. And with that, I will have to revalidate all my methods. Bob, what is the situation today? Those statements contain a lot of points that we need to discuss today. Let us start with the first statement of going electronic. I think the situation has completely changed since then.

I think that has changed completely because if we don't automate laboratories, laboratories are going to die. I think that you've got to be able to analyze quickly and in the way that we do QC testing at the moment, at the end of the process, the lab is rate limiting. I know they've been talking about real-time release testing, but it's still a long way to go, and you won't be retro-engineering it for current products. So you've got to make the lab more efficient and more productive and doing it on paper just won't be good enough because if you can speed up release by one or 2 days, the impact that, that will have on a company's cash flow will be absolutely amazing.

We see every day that pharma companies have difficulties to change and update processes, especially if it's about digitalization. Perhaps the right people don't see the business benefits and fear the effort in manpower, fear for revalidation and have the attitude, never change the working system. Isn't keeping current a legal requirement in CGMP?

Many companies don't invest for the future. They don't try and keep current and this is one of the problems that you have with the industry that they don't invest. They think same old, same old. If it was okay the last inspection, it's going to be okay this or the next one, and that's not going to be the case. We move from focus on paper to focus on electronic records. And that's the critical thing. The more you focus on the e-records, and I know we talk about paperless laboratories, electronic laboratories, digitalized laboratories, whatever the buzzword is, you've got to be automated, and that includes some of the basic simple observation tests as well as the larger spectroscopic and chromatographic analyses.

I assume we are already in the middle of misconceptions. So why don't we start with today's agenda. Okay. We will talk about the claims and myths bit by bit based on comments I hear quite often from our customers. First, paper is easier and cheaper to handle than electronic records. Second, I can avoid computers in the lab easily by direct instrument connection and thus avoid the validation effort as I only have to qualify the instrument. I heard once in a webinar, 2 days, and I'm done. Number three, if I go electronic with my instruments, I will need to revalidate my methods. Next, when going electronic, I should connect all instruments and brands to the same system to reduce the effort of validation. Next, systems should not be updated too often as this needs a lot of overhead for revalidation. And number six, as long as the pressure for going electronic and my company does not increase, I will not get the time and resources to start such a project. Number seven, an auditor or inspector is always right and the instructions must be followed even if I have doubts. Number eight, something that customers say based on marketing material, I prefer to buy a system or software that is fully compliant and validated. And this is already today's agenda. Some of the statements may sound silly to you, but we will take them all seriously. Maybe it is good to first classify the statements if it is based on a myth, misconception or lie with just short explanations. And after that, we will discuss a few of them a bit more in detail. Let us first classify the topics and claims as myths, misconceptions or lies. Bob, for now, please give a classification with a short explanation. Later, we will discuss a few items a bit longer, but now to the management summary. First statement. Companies say, paper is easier and cheaper to handle than electronic records.

Okay, misconception. They don't understand the current regulatory environment and the situation that has changed since the Able laboratories [ fraud ] case in 2005. The focus with a computerized system is now electronic records, paper is incidental.

Well, then we see concepts where the labs want to transfer PDF copies of the result report to the next level. For example, LIMS. What can you say about this?

That's a misconception as well simply on the basis that you're generating electronic paper, which you then have to abstract the information from. You'd be far better generating the data directly into an instrument data system of whatever type and managing it from there.

Well, some companies think going electronic can be easier by connecting the instrument via a printer port. Instead of printing to paper, the result is electronically transferred to the next level.

That's, I think, a misconception and bordering on a lie simply because you are now testing into compliance, and that is a no-no. As soon as the record is created, it has to be saved. You don't take the best result and say, that's the one I want. You've got to look at complete data.

Well, here comes on I frequently discussed with our customers. They have the impression that the direct connection of a stand-alone instrument to LIMS can make the computerized system validation or CSV easier. Is there really a way around CSV?

That's a myth because it's really built on marketing perception by companies and global labs taking that at the hook. I think you've got to look at this from a process perspective and make certain that you cover all of the elements within the process that you're trying to automate rather than anything else.

So the conclusion for this topic weighs around CSV, there is no way...

I don't think there is unless you are wanting a fast track to a 483 observation.

Okay. Paper is bad, hybrid systems where electronic records are combined with paper printouts are bad. Electronic paper, meaning PDF transfer is bad. But that means companies better go electronic? There are some obstacles to consider. I often hear, if we go electronic, we only want to use one system for all our instruments and brands. What is your opinion?

The problem with that is [ good ] because of the diversity of different analytical instruments, you are going to have, I think, a lot of customization. As someone who has been involved in a very heavy customization of a LIMS, I don't like it because you never get the spec right and you're ever enhancing the system to correct the errors that you should have thought about before you started the project.

So it's a misconception.

A misconception, yes.

Yes. I once had a discussion with a pharma lab manager. I knew their current process comprises a big risk of in compliance and gave him information, including warning letters, underlining my argument. His reply was, as long as QA does not force me to do it, I can't make the change, and I will not get the budget for that.

I think that is a misconception. If you know you've got a compliance problem, fix it. Don't wait. It's like waiting for Godot. Don't. You got a problem. There is no excuse for being out of compliance.

Then labs tell me they need to revalidate all methods when making a change to the process. Is that true?

I think that's a myth on the basis that you providing you are doing like with like, you should be able to make the change. However, I would say is you don't put that level of detail into a marketing authorization. You keep it very high level to make it easier to manage.

I think that needs further explanation, but we leave that for later. Well, next observation, I often make digitalization projects can take forever because they are not resourced adequately, People, not enough people have to do the validation next to their daily routine work. What do you think about that?

I think failing to resource the project is a misconception. I think here, the misconception is that people can work on the project at the same time they're doing their work. They can't. If you try to do that, whatever project schedule you've got, you don't make it. If you do, what suffers is the normal work. So you've got to get this balance right.

And it needs good trained and enough people to work on the project.

Yes, yes, yes.

Now to a frequently asked question. Updates, never change our working system because updates mean a lot of work. Thus keep the validated system as is preferably forever.

Updates. I think it's a misconception that you don't change a system just because it's validated. I think you need to be far more proactive. I think you need to be able to manage updates in a fast, quicker and easier way than you do normally. Don't leave it to the end when the systems out of support. Be proactive and update carefully, and every update does not require a total revalidation. Sometimes you may just need to patch and do a little bit of revalidation. It's not a problem.

Okay. Next on my list is about auditors and inspectors. Our customers think they are all mighty.

That's a myth. I think the key thing here is the educated auditor is more likely to be right than someone who isn't. That means they have to keep current with the regulations and the current noncompliances that you'll find in warning letters and 483s. They also need to have a good understanding of regulations and the interpretation.

Yes, that's how it should be, but auditors can be wrong. I have a special case in mind where the auditor told the pharma company, they should make paper printouts in parallel to the e-records. I don't know how often this occurs. What would be your classification of such a case?

That's a big misconception. You've got to be able to look at e-records. That's the main focus of all the regulatory guidances, all the regulatory training that inspectors go through. The focus on the e-records because that's what didn't happen at Able Laboratories. And they went through 7 FDA inspections without finding any of the falsification that occurred. As soon as they looked in the electronic records, they found the problems. So an auditor should be looking at the e-records and subsequently to that could request a few paper printouts, but to just focus on paper printouts, no, it's unacceptable. The auditor is wrong.

Okay. That was pretty clear. Are there more frequently heard statements, I mean questionable statements?

One can be my data are compliant, okay? So we come out the lab all my data are compliant. There you go. And I think that is anyone making that sort of statement is on awfully shaky ground. I think that the only way that you can really assure that is having automated processes. If it's not an automated process, making a statement like that, put it this way, I'm not going to do it. The next 2 relate more to suppliers, especially in software. And it's where the company says, firstly, my software is fully Part 11 compliant. Well, if you were Pinocchio, your nose would be growing an awful lot here because a supplier cannot provide a fully Part 11 solution, they can only provide a part or a partial Part 11 solution. And the reason for that is that the controls within Part 11 are threefold: administrative controls, like verification of a person's identity, sending the infamous letter that probably no one does anymore to the FDA to say that electronic signatures are the legal equivalent of handwritten signature; procedural controls of how you work, how you train people; and then technical controls that are built into the software. And the customer is not going to do that or the lab is not going to do that, that is the responsibility of the supplier. So the best that a supplier can do is say that they are technically ready or technically compliant with Part 11. What they are also best that they're able to do is say, Part 11 ready because they can only provide one leg of the store. And basically, the customer has to provide the administrative controls and the procedural controls. And only when you have all 3 in place, are you Part 11 compliant. I think the other thing that really is a like is where our supplier turns around and says software is validated. Now any company making that claim is amazingly stupid because they don't understand pharmaceutical regulations. The company, the regulated company is responsible for validation. It's got to be installed in their environment, configured to their environment. And if you go and look in the preamble, and I know it's 25 years old now, if you go and look in the preamble of Part 11, you will find statements from the FDA that said, a lot of people said that commercial software should be exempt because it's already validated. The FDA rejected this because they said commercial software is not accompanied by statements of fitness for purpose. It's supplied with end-user license agreements that basically says, if my software screws up your data, tough. And because of that, no supplier can say that their software is validated. At best, they can say it's been tested to whatever quality system they're working to. It is ready to be installed, but under those circumstances, can someone say that the software is validated, a supplier. It's only the regulated user that can ever state that. And if you believe that, you also need to be educated...

Training.

Yes, training. Number of companies that I've seen have believed this. They've taken software. They just run OQs and OQs and oh, we're okay, aren't we? No, no control, no user requirements for intended use definition and no configuration documentation, no testing of the configured software to match your user requirements, no traceability of requirements to the rest of the life cycle. So you've got a major problem. On the other hand, for an auditor or an inspector, Christmas has come very early. So be aware, this is the best advice I can give.

Okay. Thanks, Bob. I noticed that none of the statements from the agenda reflected the truth. This was the overview. As we do have some more time, we should discuss a few topics more in depth. I think we should say a few more words about changes of methods and the impact on validation. We often hear concerns when we try to convince our customers to change the supplier or model. And they say, no, we can't because that creates huge cost of revalidation. I can understand this to some extent. As soon as you have to touch the marketing authorization of a drug, it will become extremely expensive, especially if new clinical trials are necessary. That would be a showstopper for any change, okay. But in the new USP General Chapter 1220, there is design space recommended in order to have the ability to improve methods ideally without affecting the marketing authorization. You said companies should not write a too tight level of detail in the method, especially the make or model of test equipment. How would you update or improve a method with new equipment?

You have to go back and look at your marketing authorization and how was it put together? If your registration department has been absolutely stupid and said, we're going to use company X and make a model, that's a big problem. If you'd say it will be analyzed by this analytical technique, you should be able to take out and update your instruments. The recent drafts of ICH Q2(R2) and Q14 whilst making some progress is not complete, but it does start talking about ways of trying to update your methods and restrict the cost of doing so or reduce the cost of doing so. But normally, what happens is that you don't put in to make a model of your particular instrument. You keep that agnostic or you just say, I'm analyzing it by this particular technique and here's the method and you abstract the information from that.

When we look at this survey, we did prior to other data integrity webinars, I get the feeling that the majority of our customers still prefer paper records. 80% of our customers state they still use more than 50% paper records. The number of companies using electronic record is increasing, but only very slowly. According to your experience, why are pharma companies so hesitant to move away from paper? Isn't the regulatory pressure high enough? What would you recommend?

I think it's partly customer practice because you've got to persuade people to change their ways of working. I think it's also management attitudes that if it was okay last inspection, it's going to be okay next inspection. That, as we with [indiscernible] and BBC Group, the warning letters, the regulators are changing the way that they view companies. I think also there is always the, oh, we can't afford this. Now strangely in companies that say they can't afford anything. If you end up with a 483 or awarding letter, money seems to flow like water over Niagara Falls to try and resolve the problem. So if the money is available to fix problems, which usually cost a lot more because the cost of noncompliance is always greater than the cost of compliance.

[indiscernible] 1,000, I guess?

That sort of range, yes, because you've got the boot of the regulator in places where boots should not be placed. And the point here is that if you did it under your own team, you can work it, you can show to a regulator. We've got this problem, and we're addressing it and here's the plan and you can show demonstrable evidence against that plan. They will see you've identified the problem, you're taking steps to resolve it. Where the inspector or an auditor finds a problem, things tend to be a lot worse and especially with an inspection you will try and have a very aggressive time scale to impress the regulator and try, especially if it's a warning letter and you may have an import ban, if you're outside the U.S., you want to try and resolve that pretty quickly. That's going to cost a lot of money.

Companies tend to avoid proper computerized systems by directly connecting an instrument to their LIMS. And when the measurement is done, they press the print button, and instead of printing the result is transferred as a PDF copy to the LIMS. Doesn't that make things much easier?

My basic response to that would be why? Where is the value add in electronic paper? You still have to extract the information from that and get it into the LIMS. So in fact, what you're doing is transferring electronic paper up and the validation then has to be the connection and how you take the information from the PDF and input it into the rest of the process. That's the big problem and you've got to keep the PDF and you've got to be able to show the traceability of whatever data you have taken, and it won't just be a single weight. There will be the SST values that you've used to balance checks or anything else, all have to go up as well and you can't leave the balance checks and everything else on the PDF, that's got to be extracted as well in my view because there is a requirement for some data to be [ printed ]. And given how critical something like a balance is -- an analytical balance, you want to be trending your balance checks on a regular basis. You don't want to leave it to once a year when the service engineer comes in and services and requalifies and recalibrates the balance.

Yes, I have read that in the BBC warning letter. You must not convert dynamic data into static data. The difference is dynamic data are open for further calculation or recalculation. Static data, you cannot automatically process or reprocess. That is why they are called electronic paper. If technically, you have the opportunity to store data dynamically, you have to use it. BBC got the warning letter because on 2 different analytical instruments, they had turned the electronic record function off, correct?

Yes. The company was cited in August 2021 for not recording electronic records. Both instruments had the ability to save and store electronic data. But the company actually turned that off and only relied on paper records. So if the system has the ability to capture and store electronic records and you don't use it, you're going to have trouble.

And we have the discussion at previous webinars that this practice is also dangerous for another reason. It might be interpreted as testing into compliance, right?

The issue first is that if you bring a record into memory, and at some point, the operator decides that this result is acceptable and then presses either the save or the print button, that is unacceptable. Question 12 of the FDA's guidance explicitly talks about this, and this is either at the simplest level testing into compliance. At the worst, it is data falsification and fraud. And therefore, you shouldn't be doing it. If you connect the instrument to a laboratory information management system, then if you have the ability to determine when the result is sent and what that result is, that is still the same testing into compliance or data falsification. Don't do it. It is unacceptable. You need the ability for automatic data capture. So it's stored on authorized media, which is able to last the record retention time rather than keep it in temporary memory, that is against the regulations.

Yes, I remember, we had discussed that, and there are more issues such as what if the instrument is the only qualified reader for your data? You'll have to keep the instrument to be able to read the data.

Well, are you going to set up a museum of ancient instruments, right?

Like Boeing does, right? They have to save somewhere in the mountain...

They have a cave in the Cascade mountains, where they store all their old computers, not that they have anyone that knows how to use them these days, I suspect. And I presume, given the speed at which miniaturization is working, they may not need too much more space, the right things are going. But it's not the best situation to be in. If it can only be read and understood on the instrument, you're not much better off on the paper. In a way you've got to look at not just the instrument, you've got to look at the process because if you don't look at the process, how is that instrument going to fit in? And it's not just looking at the output from the instrument, it's what do you do with the data that are output in whatever form, be it paper or electronic, is what are you going to do after that. That's the thing.

When I visit companies, I see lab technicians appointed to do the project next to their routine work. The projects can be quite large. And I see companies that take very long until they go live with electronic records. Can you please outline how you would manage such a project? I mean just a few milestones. I mean, you obviously cannot hire a whole lot of new people for that. In a previous discussion, you mentioned that the project should be resourced adequately.

That's the case. If it is a large project, I would advocate a number of approaches. Number one would be for the key personnel that you need for this project. They are going to be usually experienced people, and they may be used for release of products or solving analytical problems. I would advocate changing the job description that allocates time to perhaps 50% on normal work, 50% on the project. The other way of looking at this, if your organization can do it is to backfill people, bring in people to do the normal analytical work and to then release key people to work on the project. One of the things I mentioned earlier, which is you need people to look after the system to manage it, laboratory administrators, not IT administrators because there's a conflict of interest, but be laboratory administrators. And one of the things that actually is important is that may want to consider one or 2 people to become those laboratory administrators. And therefore, you want them to acquire new skills to enable them to do the work that particular role in the future and being involved in the project may actually be a good way to transition into that role so that when they finish the project, they become administrators because they've been involved with the project. They know how it works. They've been trained on it. And they actually can be in a situation from day 1 that system goes live to do the admin on behalf of the lab. It may be new reports, it may be new workflows, whatever it is, they're there and they know how it's done.

And how would you do this in a case of a LabX project?

You see, I think the thing that you have to look at if we focus on LabX, for instance, is that whilst you have IQ/OQ documentation of the platform, I think that is adequate to show that the platform goes in and is qualified. It is really the focus of the pharma company should be on the workflows that are set up to do particular tasks. And it's that when you need to focus on the real effort. And whilst you may do formal validation plan, risk assessment, functional spec or configuration spec around the platform using Mettler's IQ/OQ package will speed the whole process up. The real focus, in my view, has to be on the individual workflows and how they interact with the instruments because that's where you get the real business benefit. And that's where you have to make certain the control is in place.

While we are discussing organizational topics about the project, about 5 to 10 years ago, I have talked to some companies that aim for projects to have only one software connected to all instruments or vice versa, all instruments only connected to one software. All projects that I know of have failed so far. Today, I hear this request not so often anymore. I think the companies either rely on professional software made for the purpose or they stay with paper or hybrid systems. What is your experience in that kind of project?

The problem with one computer system is it is fine for simple instruments, but more complex ones more difficult because you need the instrument controller to acquire the data. The other thing is that if you take all instruments and put them into one major computer system, you do end up with an awfully complex mixture. And I don't think it's achievable because you also have control of the instrument. You have interpretation of the data. It just doesn't work. I think what you want to think about in LIMS presentations, I refer to a LIMS environment because what you are going to be having is -- the LIMS is going to be looking at sample management. It's going to be looking at instrument management, collection of planning and collection of results and reporting of results. You're going to be having systems sitting underneath that will be controlling and acquiring individual instruments be it thermal analysis, be it classical wet chemistry, chromatography, spectroscopy, all of that, you will need instrument data systems. Building that in provides you with resilience because of the -- if I go back to 1984, this is no reference to [ Orwell ] or anything else, but we want to see a LIMS, and it was a central LIMS controlling all systems, and we walked in. And just as we walked in, there was a disk crash and the whole system was out. And if you've ever seen a laboratory of 60-plus people sitting around wondering what to do, you then know that you've got to build resilience into your network and your informatics solutions. And one of the advantages of having data systems -- separate data systems is you have the flexibility of handling the data. The other thing is that we still live in a proprietary data world. And because of that, you need the instrument manufacturers, data systems to get the best out of the instruments and then abstract that information and transfer it up to the LIMS, so that you have linkages from the LIMS to the individual instrument data systems where you can get hold of the information.

We already had discussed the case where one of our customers had turned off the recording function of our instrument. Some years back, we had implemented that function for stand-alone usage of our instruments as large pharma customers had asked for that. Since a number of years now, I think this should not be used for CGMP records and the recent BBC warning letter should be a learning. You should always record everything that is technically possible. If you have an instrument with connectivity to our software LabX and you have validated before our instruments, you are in a comfortable situation. You just have to connect it and fill in change control documents and verify your methods. If you want to avoid recording by changing make or model that has no capability to record, then you also risk trouble. If technically, there is a possibility to record, then you should. Now back to the case. In order to avoid trouble for the customer, I recommended to change the current practice. He replied 2 things. He said, I discussed it with my QA and they said, it's okay, the way we are doing it today. And the second statement was, I will never get the budget if QA doesn't force me to change.

My view is a little different. There are no excuses whatsoever for being out of compliance. If you know you've got a hole, you need to address it because otherwise, you're going to be suffering the consequences of that. And one example, I think we could quote is where you have an instrument with the ability to store data and store it. The key there is we can't do this, we rely on paper. So even though you've got the ability to store record, you just print it out. This is the same situation as the BBC Group warning letter from August of 2021. And therefore, QA are not doing sufficient due diligence to see that things are current. And that's inadequate. I know there may be an argument that says, okay, if it's a stand-alone instrument where perhaps we've got things recorded on an SD card or we can transfer things with the USB drive. IT's response is usually, no way. And if you've got an instrument with that sort of capability, really, I don't think that is going to be the best way to approach things. You need to be able to keep the data electronically and manage it and also try and get rid of things like USB drives and SD cards. Acquire it to a data system and then be able to manage the data from thereon.

And what would you say about the argument without QA pressure, I won't get the budget?

I think the key point I would make is that the QC are responsible for the science and QA are responsible for compliance. And in my view, unless there's a compliance issue, keep QA out of QC. I would argue for the way to approach the budget is if you map the process and identify the data of vulnerabilities, the PICC guidance, the MHRA and also WHO 2016 talk about mapping processes and identifying vulnerabilities. Now that's all well and good. So you can put sticking in clusters over the vulnerabilities. You may increase the number of entries in the instrument log book, which is manual. What you really want to be able to do is fix the problems, but also improve the business efficiency. And I think the only way that you are going to get the budget is not to keep the inspectors away, but actually to improve business efficiency. As I said earlier, what would happen if QC could release a product earlier? Now if you have a batch of material that is perhaps EUR 2 million, EUR 3 million, EUR 10 million on the market, and you released that one day earlier. What would the cash flow situation be? But if you didn't just do it for one batch, but you did it for all batches, what will be the impact on the cash flow for the organization? I would suggest management should be coming down with a wheel barrel full of cash saying, do it because if you can get substantial business benefit for your organization, why would you not do it. Forget what QA say. It's a business-driven decision that you want to improve the efficiency of QC in order to release product quicker. Doing that, the money should be available for you to do that. That's the critical thing.

Okay. We come to the end of this webcast. I cannot ask for a conclusion because I think everything we discussed today were conclusions. So maybe I should ask in your eyes, what do you recommend as the most important learnings today?

I think the key thing is that if we start with know the regulations, know your procedures. That helps you discuss with suppliers, auditors and your own QA. So if you've got that information, then if QA say, oh, we're not doing this. For example, I was at a conference and someone asked me a question a couple of months ago. And my QA is asking me to put paper records with signatures on it for training records. But if you read in the regulation, there is no requirement for signatures. Why do you need to interpret? So it's knowing the regulations. It is persuading management of the business benefits of automating your laboratory. If you can justify saving money and speeding release or if you're working in R&D, trying to get the work done quicker, then you will have a tangible business benefit that you can say, can I have the money to improve my processes? That -- and don't ask for too much too soon. Have proof of principle being able to manage things, test it out and then implement it so that you're doing things correctly and have good risk-based approaches to computer validation to ensure things are implemented quickly and effectively. Not everything is high risk, and you should be leveraging what the supplier has done in their development process to mitigate and reduce the amount of work that you have to do.

Okay. Thank you, Bob. That concludes the webinar. I thank you for your time and attention.