HTC-19 Interview: Automating the “Hyphen” In Practice

When we expand the concept of hyphenation beyond GC–MS, what are the biggest practical barriers to treating the full workflow— from sample preparation to data handling—as a single integrated system?

Addressing this topic will inevitably involve some generalization, as a key lesson from my experience as an application chemist is that different sectors within the analytical community have very different needs and drivers.

That said, I do believe there are patterns that can help us better understand where the barriers to implementing such a mindset shift might lie.

Resources: Undoubtedly, the most tangible of the three barriers because it probably involves the highest activation energy. When we talk about resources, I mean all their facets: money, time, and expertise.

The economic aspect is self-explanatory. Budget barriers can prevent research groups and laboratories from implementing the additional technology required, both in hardware and computational components.

Time is not only precious but also a gift, especially in analytical scenarios where timelines are incredibly demanding and unforgiving, given high throughput and the need for rapid information turnaround. A change of approach often involves an investment in method development, fine-tuning, and validation, which, although beneficial and rewarding over time, must be carved out of an already intense instrument and people schedule.

Last but certainly not least, the technical aspect encompasses both the current limitations of existing technology, which may not be able to translate every step of every manual workflow, and the need to build additional technical knowledge around the newly implemented technology to create a single integrated system.

This applies to both hardware and software, and, depending on the extent of integration, to coding and scripting as well. In an ideal world, this expertise is either already present within the team or can be built through training and time. But it is undeniable that confidence comes only with years of experience, and when other priorities take precedence, that commitment might falter.

Regulatory: Many laboratories operate under strict regulatory and compliance requirements, including data integrity expectations, that may limit certain deviations or be difficult to reconcile with how emerging technologies operate.

While this barrier might not be relevant to research and development scenarios, it can become a significant roadblock to such a radical shift in modus operandi. Yet it is not insurmountable.

Trust and Reliability: We cannot dismiss the emotional component associated with implementing any novelty; after all, we are only human and, as such, sentient beings.

Trust is the foundation of any relationship, and a relationship with new technology and workflows is no exception. This shift requires a leap of faith that not everyone might be willing to take, especially when the existing approach “does the job”. It is only when the test of time has proven otherwise that this emotional aspect can be overcome, but it remains an invisible barrier with a waterfall effect on the timelines involved in change.

How do highly automated workflows balance robustness and throughput with the need for method flexibility, especially when dealing with diverse or unpredictable sample matrices?

I’d say it mostly narrows down to three aspects: the upfront choice of robotic platform format, its configuration, and the level of training provided to the end user.

1) Choice of robotic platform: In the world of analytical automation, as I like to call it (i.e. automation narrowly focused on the specific context of the analytical workflow; otherwise, automation per se is too broad a concept applicable to many different sectors), there isn’t a one-size-fits-all solution. Different robotic platforms exist, each with its strengths and weaknesses and the consequent capability to fulfil the different drivers of automation. While robustness and method flexibility can coexist, especially on certain platforms such as instrument-top systems, much will depend on the actual configuration applied to the system and the level of training provided to end users, empowering them to make the adjustments that method development requires.

2) Configuration: Flexibility in configuration varies across platforms, but if enough time is spent on a thorough evaluation of all the tasks (e.g. liquid handling, mixing, centrifuging, filtration, solid-phase extraction (SPE) et cetera), we can better anticipate which capabilities may be needed when implementing new methods for diverse applications and matrices. That comprehensiveness can be translated into the hardware and software capabilities available on the platform. That is the foundational step: if the hardware cannot translate a critical manual action into its automated analogue, the workflow reaches a dead end before method flexibility has even entered the conversation. Once the essential building blocks are in place, it is a matter of implementing method flexibility through scripting and testing to assess any hurdles specific to the new sample matrix.

3. Training level: Not surprisingly, this aspect again links back to the type of robotic platform chosen. That is mainly due to how the translation process involved in moving from a manual to an automated workflow works, which we might call automated workflow programming. And just as with robotic hardware, there’s a variety of options here, each with a different approach. Broadly speaking, the manual-to-automated translation pathways fall into two main categories: script-driven and software-driven.

In the script-driven approach, automated workflows are created using scripts, sets of instructions written in a dedicated programming language that varies by platform. That automated workflow script is typically embedded directly into an overarching software system, but at such, it remains a black box, not accessible or editable by the user unless that knowledge has been transferred. In the software approach, automated workflows are built using standalone, user-friendly vendor software that blends a graphical interface with intuitive menus to configure each action of the robotic platform. All the coding or scripting has been done “behind the curtain”. The user is simply responsible for orchestrating the sequence of actions and tweaking settings.

The script-driven route is undoubtedly more versatile. But that flexibility comes at a cost: prior scripting knowledge is essential, or access to that expertise must be available. The software route, on the other hand, gives users a way into workflow design without requiring them to script or write code directly. However, the options remain limited to the actions, parameters, and logic that the software designers have built into the software.

So, when flexibility for new matrices and applications is a key driver, platforms that rely heavily on locked or manufacturer-controlled scripting can become more cumbersome. New scripts can, of course, be developed, but that may require input from the manufacturer and potentially additional cost.

On the other hand, if the robotic platform operates through user-friendly workflow software, the right level of training can empower end users to tweak existing methods, troubleshoot matrix-specific challenges, or develop new methods altogether.

In your experience, is sample preparation still the weakest link in achieving full workflow integration, and what chromatographic considerations should guide its automation?

In some cases, yes, but it is hard to generalize because it depends heavily on the sample preparation step and the application in question. For example, in some untargeted or screening approaches, the tendency is often to minimize sample preparation or to avoid highly selective preparation, because it can become a discriminator and alter the chemical picture under investigation. In some non-GC workflows, even chromatographic separation may be reduced or removed, with greater reliance placed on the resolving power of mass spectrometry. In those cases, the bottleneck may shift to data processing, data mining, interpretation, and reporting.

Where sample preparation is indeed the weakest link, this is usually due to one of these issues: either the requirements for miniaturization are not compatible with the sample size needed to guarantee representativeness, or the existing technology cannot yet robustly automate a key manual step, such as automation-compatible tissue homogenisation.

If those two limits can be overcome, the chromatographic considerations I would propose to guide automation are mainly two.

First, from a hardware perspective, when the robotic platform allows it, an online setup is worth considering. This is often more straightforward for GC configurations. For LC configurations, additional elements may be required, such as a dedicated LC valve and, potentially, an injection tool designed to address carryover and contamination, especially in LC-MS contexts.

Second, automated sample preparation often involves miniaturisation. While this is desirable for reducing solvent consumption and waste, it can become a hurdle, especially for solids, where reduced sample size may affect representativeness or overall method sensitivity. Therefore, the chromatographic method should be developed with this in mind. For LC, this may mean considering injection volume, solvent compatibility, focusing effects, and carryover. For GC specifically, it may involve considering a programmed-temperature vaporisation (PTV) inlet and large-volume injection (LVI) to compensate for sensitivity losses introduced upstream.

As automation increases upstream, does data processing risk becoming the new bottleneck, particularly in terms of chromatographic peak deconvolution and compound identification?

Indeed, we now face the opposite problem to previous generations of analytical chemists: too many data. This facet brings us back to the definition of automation. The term automation shouldn’t be limited exclusively to sample handling, sample preparation, and sample introduction. True automation strives for an end-to-end workflow. The hardware captures only the physical side of human action, for instance, through robotic platforms. Computational tools, on the other hand, automate the thinking side of human action, including data processing and, increasingly, data mining and decision-making. Automated deconvolution and library searching are now routine capabilities in many vendor software platforms, and an increasing number of tools are incorporating AI-assisted capabilities for tasks such as integration review, anomaly flagging, data-quality assessment, and compound identification support.

Looking at it from the other side of the coin, being able to produce more data more easily will certainly lower the barrier for implementing data analytics within the analytical workflow: from something as simple as additional replicates to support statistical confidence in targeted analysis, to larger sample sets that can support chemometric tools in untargeted analysis.

To what extent can fully integrated GC-MS workflows be standardised across different laboratories without sacrificing performance or adaptability to specific analytical questions?

Transferability is, in fact, one of the strengths of a fully integrated GC–MS workflow, and as such, it can translate powerfully into standardization across different laboratories, especially when performance has been fully understood and optimised throughout the development process.

The important distinction, in my view, is that standardization does not have to mean rigidity. What can be standardised is the workflow architecture: the sequence of operations, critical control points, automation logic, injection strategy, data-processing rules, and system suitability checks. What may still need to remain adaptable are the method parameters that respond to the analytical question, sample matrix, or required performance.

While performance would not be sacrificed — quite the opposite — adaptability can be compromised if it is not considered early enough. We hinted at this strategy in question two when discussing automation and method flexibility. Again, it is all in the effort put in upfront to shape the ideal configuration and anticipate the requirements for adaptability. Some robotic platforms, such as instrument-top systems, lend themselves very well to retrospective upgrades and hardware modifications because they are intrinsically modular. So, if adaptability is a key driver in the translation from manual to automated workflow, that can be taken into consideration upfront and woven throughout the development process.

Do integrated and automated chromatographic workflows meaningfully reduce solvent use, energy consumption, and human error, or do they introduce new sustainability trade-offs that need to be considered?

I have very quickly come to realize that whenever the sustainability layer is brought into the picture, trade-offs are unavoidable because of the multifaceted nature of the problem. As Prof. Psillakis beautifully captures in her recent review, “Towards sustainable analytical chemistry”,1 sustainability challenges are inherently systemic. Therefore, systems and nexus thinking become essential because “the integration of sustainability factors in analytical products represents a major challenge, as managing the overlap and conflicting aspects of the different elements, called trade-offs, results in a complex and uncertain decision-making process that is context-dependent”.

With that established, automation is undoubtedly a strategy that has been brought forward to help specifically with the greenness pillar of sustainability. Its value becomes even clearer when we expand the lens from greenness alone to whiteness,², and include analytical efficiency (redness) and functionality (blueness) in the picture.

From a greenness perspective, automation often involves miniaturisation. When transitioning from manual to automated workflows, a scaling factor is often applied from the larger volumes handled manually to the smaller volumes the robot can handle. Scaling down can clearly reduce the direct impact of the methodology, as smaller volumes lead to less waste and a reduced toxic reagent burden.

Certain robotic platform formats also allow highly efficient hazard containment through sealed vessels and, where appropriate, operation inside a fume hood. Both measures can limit analyst exposure to toxic substances. These aspects align well with the principles of green chemistry, especially regarding reagent toxicity and operator safety.

Energy consumption is probably comparable to that of the same equipment on the bench, but I don’t have enough data to claim a significant reduction. To better understand this, we ran an experiment using a smart plug to measure the energy consumption of an automated workflow performing dispersive liquid-liquid microextraction over 8 hours, preparing a full batch of 40 samples. The system’s idle power demand was approximately 62 Wh, comparable to running an old incandescent light bulb for the same time. When running, the average energy consumption across the automated tasks remained modest (73 Wh), comparable to a few minutes of household vacuuming.

Redness-wise, analytical automation offers increased control, for example, over experimental parameters, randomisation, and batch processing, as well as improved consistency through reduced human error and increased precision. These directly influence figures of merit and, therefore, data quality, leading to a consequent reduction in repeated runs and, therefore, waste of resources.

Last but not least comes blueness: the practical utility aspect of the analytical methodology. This is where the convenience associated with automation truly shines: through delegation, traceability, and multitasking. For instance, instrument-top platforms can not only prepare samples but also inject them directly into a GC or LC system, facilitating end-to-end operation and reducing operator touch time.

But this perspective still does not fully capture the impact on the social and economic pillars, nor the circularity angle, where many of the trade-offs are likely to emerge. And that is when we go back to the beginning: systems and nexus thinking need to be part of the picture.

References

1. Psillakis E., TrAC Trends in Analytical Chemistry, 2025, 191,118371.

2.Nowak P.M et al. TrAC Trends in Analytical Chemistry, 2021,138, 116223.