Q&A: Automated Analytical Method Development

Main image credit: 

Workflow advantages and future developments. Who can benefit from automated method-modeling software? Probably more laboratories and research teams than you think—perhaps even your own. That’s because all the method-development experience in the world is no match for an automated modeling software package that can eliminate human error, provide a 360-degree view into the design space, and accelerate time to development of a truly robust method.

As DryLab Specialist at Molnár-Institute for Applied Chromatography, Arnold Zöldhegyi understands this better than anyone. So, LCGC Europe sat down with him to discuss the benefits of the new DryLab/Empower connection in pharmaceutical analysis and to get a peek at future goals and advances for the automation module.

The main benefit of a modeling software is that it literally illuminates the whole possible Design Space (DS) — and such DS easily consists of more than a million workpoints or method-parameter combinations. In the case of DryLab, all it takes is 12 distinct input runs to visualize all of the chromatographic interactions inside of the DS.

Now, some packages are statistically based and they will run plenty of experiments, keeping your instrumentation busy, day-in, day-out, in an automated way. DryLab has a different approach. Probably, because it was programmed by two scientist, Lloyd Snyder and John Dolan, who contributed extraordinarily to the understanding of HPLC. They basically evolved DryLab along with their own research since 1986. So, getting back to the difference between DryLab and a statistical package: a statistical package will tell you if your method works or if it fails, but it won’t demonstrate what is going on in your Design Space in the same way DryLab does. DryLab will visualize the interactions of your separation at all possible method conditions — so that you precisely see what areas your method will work in, which parameters can be varied, and which need to be strictly controlled.

Now, occasionally, you’ll meet a person that says: «Oh, you know, I’m really good at method development, I don’t need to use modeling software. In fact, my intuition tells me where to find the perfect work point way better than any of the packages out there».

Having a hunch and doing trial-and-error may be helpful in some areas of life, but what we’ve seen is that it’s the wrong approach when you try to receive marketing authorization for a new drug product. And I am saying this with the notion that CROs that do contract method development work on a daily basis, clearly very experienced chromatographers, use DryLab to not head in the wrong direction and because they need to model to substantiate their decision making for the filing. Also, without using modeling software, in addition to the headache of not understanding of what is going on in your Design Space, you will also be losing a lot of time.

So, the term AQbD implies a method development that is based on scientific understanding – based on HPLC’s underlying theories. Snyder and Dolan conceived their DryLab software as a tool that would make their findings applicable for all kinds of people facing separation problems both in academia and the industry. Now, adding automation to DryLab will further lower the threshold of utilizing this AQbD software to the level that you’ll be using it on an everyday basis. Because DryLab takes the advantage of the absolute accuracy of the laws describing the retentions mechanisms in HPLC, 12 input runs is all you’ll need. What then really decides over the quality of your DryLab model is going to be the pristineness and reproducibility of your input data. In other words, you can expect a close to perfect model if you manage to rule out any transcription errors and other slips — which is exactly what the automation does.

The automation module connects directly to Empower, writes the sample sets, making sure that the proper re-equilibrations are performed between the runs and then acquires the integrated data from Empower back to DryLab. It does this across the DryLab workflow, which is: firstly, designing and running the 12 input experiments on Empower, then executing and acquiring confirmation runs and finally running and acquiring robustness verification runs to confirm the robustness assessment.

Now, you can imagine if you’re a subject matter expert in charge of a separation center that delivers to analytical operations, you probably have set up an SOP that implements the usage of DryLab on a daily basis. But of course, not all of the people you are dealing with are equally experienced in method modeling. Here, having the Empower automation really makes your and their life easier with all data being seamlessly transferred across the DryLab workflow.

But not only does the new Automation module and its Empower connection facilitate DryLab modeling for the less experienced users — it generally prevents all users from making any mistakes when writing the method sets, exporting from the CDS, importing to DryLab and copy-pasting additional peak data from the spreadsheets. It really brings DryLab’s AQbD modeling to your daily routine on all those levels, plus it vastly saves time: your SampleSet is written with only one-click.

Right, robustness is a key performance criterion of an analytical method and the way DryLab has been assessing it since we made the module back in 2011, turns out to be in line with what ICH Q12 recommends in this regard.

But I think the reason for industry to turn to the Robustness Module is that it really gives you a very good understanding of how well your method will perform in routine use and in what areas of your Design Space it can be run across its lifecycle without having to face any Out-of-Specs. And this is highly relevant to many of our customers because their business model depends on their ability to yield profits in a limited window of opportunity. And for their analytical development this means that methods have to perform flawlessly in subcontractor labs in regulatory systems across six continents.

The way DryLab’s robustness assessment works is the following: first, and based on scientific theory, the Design Space and its chromatographic interactions are modeled. Next, and based on that knowledge, the MODR (Method Operable Design Region) is identified. Now, the precision of the instrumentation is taken into account and this is done by including the range of gradient sensitivity, temperature-, and pH-accuracy and also other specs that could vary… such as flow rate, for instance. This information is then added to the Drylab model to evaluate what the robustness of a work point or a work space will be.

So, once your MODR has been scrutinized in this way, the chromatographer continues and validates the robustness assessment. From the systematic way your model has progressed so far, you can now see for instance, at which point in your MODR the API will elute the earliest and at which point the latest, which will give you a certain range you can expect in routine use — which will be highly relevant for your SST (system suitability test). Also, you’ll see where in your MODR peaks-of-interest, for instance the critical peak pair, will have their lowest critical resolution. So, these strategically relevant points you then take from in-silico and run them for confirmation, fully automated, SampleSets being written and executed through DryLab’s Empower Connection, then acquired from Empower and compared to confirm the model in DryLab.

Now, the whole point of doing this with regard to Q12 is to use the software capabilities of visualizing the interactions that are going on, and to determine which parameters affect your separation in routine use, and also which won’t. This information is gathered and structured in DryLab’s Knowledge Management Document and is then the scientific basis for your Post-Approval Lifecycle Management. Flexible regulatory approaches regarding later changes would derive from, for instance, a downgrading of certain parameters from prior approval to notification.

Well, firstly I have to say the we have some really amazing customers and they use DryLab extensively across the techniques: ion-exchange, ion-pairing, hydrophobic and hydrophilic interaction chromatography, and of course normal and reversed phase. We also see a lot of protein analysis going on, with large teams of analytical scientists in the industry using DryLab for separation work on polypeptides, oligonucleotides, with the DryLab workflow being laid down in their SOPs. Very impressive applications we see in monoclonal antibody work, for instance from Szabolcs Fekete, from Geneva, who’s doing some really amazing stuff with DryLab.

Beyond that, there is something that we’re seeing that’s rather new and that is: industry is filing their DryLab models in their application dossiers. So, they’re adding the DryLab Knowledge Management Document to the Pharmaceutical Development Section of their CTDs. I can tell you that Chromicent’s Alexander Schmidt has been doing this with great success for a couple of years now — and from my understanding, there hasn’t been a single case of rejection or even requests or Q&As from regulatory side.

Its motivating and good to see, how all the research and scientific theory that reflects in DryLab is now spot-on with our customers submitting DryLab models as their analytical development outcome. It facilitates approval because it provides all the relevant information that is missing if you only file validation results instead. Validation results alone are no basis to justify any post-approval leeway — leeway, that regulators may have granted or could have granted if you had turned in a documentation of your analytical procedure development.

So, in this regard, customers filing DryLab’s Knowledge Management Documentation may have the potential to actually advance the field over the next years!