Solving the disconnect between lab and data scientists: part 2

In the rapidly evolving landscape of life sciences, the communication gap between laboratory scientists and data scientists remains a significant challenge. This ‘silo problem’ can impede innovation and slow down research progress. Ian Kerman, Data Science and AI Solutions Architect at Certara and co-chair of the Society for Laboratory Automation and Screening (SLAS) Data Science & AI Topical Interest Group, is working to bridge this divide.  In this second of two interviews, he shares his vision for the future of collaboration between lab and data scientists.

A vision for the future

Raminderpal Singh (RS): Looking 3-5 years ahead, what would be your ideal vision for this relationship between lab scientists and data scientists?

Ian Kerman (IK): Having worked in the life sciences industry for a long time, I’m sure you’re familiar with the concept of silos – data silos and other types of organisational barriers. There are both logical  and physical barriers that can prevent collaboration and hinder data integration. 

While I try to avoid corporate jargon like ‘breaking down silos,’ I genuinely believe that’s precisely what needs to happen for data science and life science professionals to collaborate more effectively. 

Does the data scientist need to be physically in the lab? Not necessarily, but I don’t think it would hurt either. From personal experience, I believe I’m a more effective data scientist in the life sciences industry because I gained laboratory experience as an undergraduate and in graduate school.

That experience gives me insight into how experiments are run, how data is collected, why data is messy, and why there are missing values. I understand what happens in the lab, which helps on the data science side because I can better appreciate the work that goes into collecting the data. This gives me  a deeper understanding of why the data looks the way it does and how to handle it. As a life scientist, you have to deal with missing data – whether by conducting further experiments or through extrapolation – and taking those concepts into data science is valuable.

The evolution of scientific data analysis

RS: In the past, scientists often did their own data analysis using tools like R or spreadsheets with macros. What are your thoughts on what might have been lost with increasing specialisation and the potential to bring some of that integration back?

IK: From what I’ve observed, there’s significant potential for that integration to return. Far more coding now happens in labs than when I was in school. Languages like Python and Go are not only powerful but relatively easy to learn. It has become simpler for someone in the lab without formal coding training to create scripts that meet their specific needs.

Even if these scripts don’t adhere to formal coding standards or lack proper documentation – things software developers prioritise – they work for the scientists and provide access to the data they need. Tools like Jupyter Notebooks can easily generate the plots and graphs they require.

What I’m less sure about is whether this integration continues when students transition from academia to industry. Is there a silo effect where lab work and coding remain separate? Or is it simply that scientists in industry are so busy running experiments and other lab responsibilities that they don’t have time for their own data analysis?

Company size is also a factor. Larger organisations may have policies regarding which groups handle specific tasks, whereas in smaller companies, everyone might do a bit of everything. Early in my career, I worked for a biotech startup with only seven to eight employees, and it was definitely that kind of environment where everybody contributed across different areas.

The role of AI and LLMs

RS: You mentioned large language models (LLMs) earlier. Do you see potential for tools that provide prompts allowing lab scientists to create code without having to write it themselves?

IK: I think there’s definite potential there, and it’s already happening. For example, Anthropic has positioned itself well in this space with Claude Code, where you can feed it your GitHub repository and it will analyse your codebase, helping you develop further code that matches your style and utilises your existing classes.

I can absolutely envision something like that paired with Jupyter notebooks, where everything executes directly in your browser. There are two different areas of expertise required here: understanding the code to ensure it’s doing what you want (because an AI might generate code to calculate statistical tables, but you need to verify they’re the right statistics) and also prompt engineering – giving the right commands and phrasing things effectively. This represents another skill we’re asking laboratory scientists to develop.

The question becomes: is there a lower-friction approach to help lab scientists without requiring them to learn coding? Reviewing code is far easier than writing it, especially with tools that check syntax and other elements automatically.

RS: What about AI assistants that could help with gathering additional data or metadata?

IK: That’s a fascinating idea I hadn’t considered. It reminds me of algorithms and machine learning models used in design of experiments (DOE), which suggest the next experiment to run in order to fill knowledge gaps. I could absolutely see something similar from a data perspective, where an AI model could suggest different experimental conditions or additional data that should be collected to enhance the overall dataset.

Even simpler implementations could be effective – like a chatbot that prompts scientists with questions such as, ‘Did you collect this?’ or ‘Did you collect that?’ based on commonly useful parameters. It could serve as a virtual data scientist in the lab or a virtual lab scientist in the data centre.

I think it could be relatively straightforward to implement a virtual lab scientist for data centres, as much of that would involve Q&A about experiment details and methodologies. The reverse might require more training and direction to be effective.

Advice for early career scientists

RS: What advice would you give to graduate students or early career professionals entering this field?

IK: Not to sound too corporate, but networking and meeting people – especially beyond your immediate circle – is invaluable. Connecting with people in different departments or groups who have diverse perspectives will help you think in new ways and enhance your innovation capabilities.

Along those same lines, become really skilled at your primary discipline – whether that’s laboratory science or data science – and then cross-train. This could mean practical experience, like lab scientists doing coding projects or data scientists spending time in a lab. Alternatively, it could be as simple as watching educational videos to familiarise yourself with the terminology and methods used by professionals on ‘the other side of the wall.’

It’s generally easier to gain additional experience in data science because much of the work can be done on a computer – such as downloading datasets from platforms like Kaggle, building models and participating in challenges. Gaining lab experience is more difficult without institutional access, which is why I’d encourage computer science students interested in pharma or life sciences to intern or volunteer in campus labs early in their education. That hands-on experience helps create a more well-rounded professional.