As a leader in a pharmaceutical or life sciences organisation, getting the most out of your team and resources is always a top priority. After making the decision to proceed with a critical investment in consulting services, there may even be more pressure to find the optimal use of these time-limited external resources. So, how can you make sure you are using these resources to their full potential? In this blog, our industry expert Micah Rimer will show you how.

During Micah’s 20 years’ working at big pharma & vaccines corporations, including Bayer, Chiron, Novartis and GSK, he has successfully deployed consultancy groups within lab informatics and clinical projects. Micah has worked with Scimcon to support his teams on high profile critical projects

Frame the problem – what does your implementation project need to achieve?

As with any business situation, it is important that there is a common goal that everyone is aligned around.

It is essential that you do not waste valuable time revisiting the same conversations. Ask yourself: “Is it obvious what problem we are trying to solve?” Often, issues can arise when people are arguing about implementing a solution, whilst losing sight of the challenge at hand. 

Take the example of Remote Clinical Monitoring: You might decide that it would be beneficial to have your Clinical Research Associates (CRAs) track and monitor the progress of a clinical study without traveling to clinical sites. That sounds like it could be very promising, but what is the problem that needs to be solved?

• Are you trying to reduce the travel budget?
• Do you want to increase the number of studies your CRAs can cover?
• Are you trying to get access to data more quickly so decisions can be taken faster?
• Or do you want to increase the quality of the study?

Without clear goals on what you want to accomplish with Remote Clinical Monitoring, it will be difficult to declare an implementation a success. In addition, if you and your organisation do not know what you are trying to achieve with a particular technical solution, it will be impossible to give your informatics consultants a clear set of deliverables.

So, first things first, agree on the problem statement!

One of the first times I hired Scimcon to support me with an informatics project, I had recently joined a pharma company and found myself in the middle of conflicting department objectives, with what seemed to be no clear path out of the mess I had inherited. The organisation had purchased an expensive new software system that had already become a failed implementation. After spending a year continuously configuring and programming it, it was no closer to meeting the business needs than when the project had started. There were two loud criticisms to address on that point:

• those who were upset that the problem had not been solved, that the business was still hampered by not having an overview of the laboratory data they needed; and
• the second being the appearance that the department had spent money on software that was of no use.

This also highlighted a far wider range of issues, such as some people who felt their skills were not being properly utilised while problems went unsolved, and that the bioinformatics department might not have the right goals to begin with.

To solve this challenge, we sat down with Scimcon to identify all the different problems associated with the inherited project, and to clarify what we needed to do to turn it into a success. In taking time to review the situation and without too much effort, we were able to come up with four key areas to address: 

1. Understand how bioinformatics/ IT priorities should map to the organisation’s priorities – before we spent any more time and money, what did the organisation actually need?
2. Solve the bioinformatics problem that the software had been purchased for (assuming that was indeed a verified need).  
3. Determine how roles and work could be shifted and changed so that we were utilising the talents and the resources in the department.
4. If possible, put the purchased software to use! 

With the help of Scimcon, we were able to define these problems and then focus on finding answers to each of the questions. In the end it turned out to be one of our most successful engagements together, award winning even. By just asking senior management what their biggest challenge was, we found their overriding priority was to have an overview of all the R&D projects going on. And while the new software was not particularly well suited for solving the bioinformatics problem that it had been acquired for, it could easily be used to map out the R&D process for portfolio tracking. Then, we turned our attention to the bioinformatics problem, which was easily solved by a bit of custom code from one of the bioinformatics programmers who felt that previously his skills were not being properly utilised.

Once we knew where we were, and where we wanted to get to, all we had to do was get there one challenge at a time.

Manage internal expectations – how will the informatics consultants work with your clincial/analytical teams?

Once you have identified and agreed on the problem that you want to solve, the next step is making sure the organisation is ready to work with your consultants. As with all relationships, business or otherwise, a crucial step is to make sure that everyone has the same expectations, and that all the relevant stakeholders are on the same page.

People have many different perspectives on why consultants are brought in.

• Sometimes you need to bring an external voice to convince management of something most of the organisation already knows, as the conversation coming from an external party may be able to have more of an effect.  
• Sometimes you are looking for external skills and experience that you do not have internally that are needed to achieve a specific goal.  Maybe you are trying to implement some new workflow or technology, or you are moving into a new area of responsibility with which you are not familiar. 
• Other times you may have the skills internally, but not the resource availability. You and your key people are all tied up in the daily operations and have no time to change your systems and processes into a more efficient way of working. 

As there can be so many different roles and perspectives on the use of consultants, you need to make sure that you address all the different stakeholder perspectives. It is important to establish a positive situation, as you want the consultants to be able to work with your teams without unnecessary tension.

When I was just starting out with my first LIMS implementation (Laboratory Information Management System), I remember being impressed that you could hire someone who had the specific experience and expertise to guide you on something they had done before but that was new to you. I wondered, “why was that not done all the time? Why do so many implementation projects fail when you can bring people in who had solved that particular problem before?” When I asked Russell Hall, a consultant at Scimcon for us on that first project, he said that not everyone is comfortable admitting they need help. As my career has progressed, I have come to value that feedback more and more. There are many people who are highly competent and effective in their jobs, but are not comfortable with the appearance that they are not sufficient on their own. It is always important to manage for those situations, rather than assuming that everyone will welcome external help.

Lastly, it is also critical to manage expectations, regarding the use of consultants. Your boss may need to defend the budget, or be prepared to stand behind recommendations or conclusions that are delivered from people outside of the organisation. It should also be considered that management might not readily accept something that might seem obvious to employees working at a different level. By liaising with senior leaders from the outset, you can make sure both parties are aligned how the consultants will interact with people in the company, and what their role will be. This is important both to achieve what you want internally and also to make sure the consultants have a proper expectation of how their efforts will be utilised. 

Communicate and adjust – how is your information managed between your team and consultants?

While it can be very tempting to feel that you can leave the majority of the project to the experts, the reality is things rarely go as smoothly as planned. As the life science business and information management have advanced over the last few decades, the amount of complexity and details has grown tremendously. It is more and more difficult for a single person to maintain an overview of all the relevant facts. The only way to be successful is to communicate and make sure that the right people have the right information at the right time. Your consultants are no different. 

Many organisations have challenges in terms of taking decisions and communicating them effectively. For your consultants who do not typically have all the same access and networks in the organisation that internal staff do, it is imperative that you make sure they are kept up to date. You want to avoid them spending valuable time on focusing on areas and deliverables that have shifted to being less important. Finding ways to keep consultants informed on all the latest developments is absolutely necessary for them to be able to deliver successfully. Figure out what makes sense by considering the organisation culture and the consulting engagement setup. Whether it is by use of frequent check-ins or online collaboration, be prepared to put in additional efforts to make sure that the information gets to where it needs to go.

As well as good communication, organisations have to be able to adjust as needed. Occasionally everything does work out according to plan, but that is more the exception than the rule when it comes to complex life science informatics projects. While timelines and commitments are critical, it is important to view any project as a collaboration. There will be unexpected software issues. There will be unplanned organisational changes and problems. People get sick, life happens. By having open and continuous dialogue, you can be best prepared to make the adjustments needed to find solutions together to unexpected problems.

Ensuring success in your informatics projects

Consultants can be hugely valuable to you and your organisation.

But you have to setup the right conditions for everything to work out well.

1. Know what the problem you are trying to solve is, and make sure you have as much alignment around the problem statement as possible.  
2. Make sure the organisation is ready for the collaboration by ensuring that your team and management know what to expect out of the engagement, and that your consultants similarly know the scope and what their mission is.
3. Lastly, you need to keep in constant communication and make sure that you are ready to work together to adjust to the inevitable bumps that will come up on the road.

Working together, you can get to where you need to go.

If you’re interested in working with Scimcon on your upcoming informatics project, contact us today for a no-commitment chat about how we can help you succeed.

Profile

• Name: Geoff Parker
• Job title: Co-Founder of Scimcon
• Pets: A Chocolate Labrador, who eats enough for 10
• Favourite animal: Red squirrel
• Favourite food: Sushi
• Favourite film: Forbidden Planet
• Fun fact: I played Angel Gabriel in the school nativity.

What do you enjoy the most about working at Scimcon?

That’s an easy question, I love the constantly changing challenges that informatics consultancy throws up and helping customers and our own internal teams to creatively meet those challenges.

We help customers in pharma, biopharma, and clinical trials to identify and evaluate the goals and challenges ahead and use this to influence information system strategies. We assist with programme and project direction; vendor and product selection (of LIMS, SDMS, ELNs and ePRO solutions); and to drive successful software implementations.

The works is often equal parts frustrating, challenging, and exciting but as people who have been involved in this type of work will recognise, it is ultimately extremely rewarding.

What do you enjoy doing in your spare time?

I am somewhat cursed by having multiple passions to fit into my spare time. Being a keen mountain biker, avid photographer and relentless traveller does present some time-management dilemmas.

Photography is something I have been fascinated by since I was at school, and is something that I have picked up and put down intermittently since then. However, three years ago I was lucky enough to spend a week riding bikes with a professional photographer and this really inspired me to develop my skills and style. You can view some of my results of my photography journey on my portfolio site.

My addiction to mountain biking started when I moved to Scotland ten years ago, as there is some of the best riding in the world, right here. The mixture of physical demands, technical riding skills and the pure pleasure of being surrounded by forest and mountains has proved irresistible. Not that the abundance of local riding has stopped me traveling with my bike. Ten years of truly amazing riding has taken me to some of the best trails in Morocco, Nepal, USA, New Zealand, Switzerland, Norway, Iceland, and Chile! Like most people, I am looking forward to when travel once again becomes possible, then maybe I can put my planned trips to Kyrgyzstan and Bhutan into action.

What is your favourite travel destination?

I’m not sure I can pick a favourite, as it depends on the activity involved. For a chilled afternoon walk drinking coffee, I would have to say San Francisco. Relaxed attitude, wide open streets and great culture make it a hard place to beat.

For mountain biking, it could be any of those places I mentioned above. My trip spending a week on HMS Gassten, a converted World War Two minesweeper, with a group of good friends riding high above the fjords in Norway deserves special mention.  Also, I think Nepal’s Mustang Valley was a special trip. Amazing culture, fantastic people, and as for those mountains – they build them big over there!

2020/21 has been an interesting year – how has it impacted you outside of work?

The biggest difference is that I have been at home for the longest period in about 22 years! In the last 12 months, I have only managed to travel down to our office in Newmarket twice (from my home in Scotland). I would normally travel 2 or 3 weeks out of 4, so it has been a big change.

Distancing from family and friends has also been difficult, as it has for most. I have stayed in touch as much as possible with family and friends the same way anyone else has; telephone calls, meeting in car parks and standing 4 metres apart, in addition to several Zoom quizzes!

Scimcon as a business is deeply rooted in technology – but how technology-oriented are you? What devices do you use?

I have had a long fascination with technology, which of course in part has led to my role at Scimcon. We have obviously come a long way since I first became involved in technology. I started programming on home computers during the explosion of affordable devices in the UK during the early 1980s.

Everything has continued to stem from there, to a point where I’m now the co-founder of a scientific technology consultancy, using technology to drive change and deliver scientific value.

In terms of devices, I use pretty much anything you can imagine. I have electronic shifting on a couple of my bikes, and I have some amazing camera equipment that even five years ago would have been inconceivable.

Does your use of technology differ outside of work?

I don’t think my use of technology in my everyday is too different to how I would use it at work. At Scimcon we try to use technology in a way that enhances people’s work lives, so that they can focus on what is important. If I look at technology in bikes and cameras, what excites me is the same thing – not the technology itself, but what it allows you to do.

For example, when I started photography at school, the process was incredibly different to how it is now. You tried different methods of taking photographs and would be left with a roll of film afterwards that if you were lucky, you’d get developed a week later. Of course, you could guarantee that you would get the photos back after all that time and wonder “what on earth was I trying to do?” Nowadays, we have digital cameras, so you take the photo, see the result, and if it does not work you can just try again instantly.

That’s exactly how we try to use technology at Scimcon. We don’t want technology to get in the way or slow down the result you want to achieve, we want it to enable you to do the work you are trying to do – whether that’s riding bikes, taking photographs, or integrating your LIMS to streamline your workflow.

What is User Acceptance Testing?

User Acceptance Testing (UAT) is one of the latter stages of a software implementation project. UAT fits in the project timeline between the completion of configuration / customisation of the system and go live. Within a regulated lab or clinical setting UAT can be informal testing prior to validation, or more often forms the Performance Qualification (PQ).

Whether UAT is performed in a non-regulated or regulated environment it is important to note that UAT exists to ensure that business processes are correctly reflected within the software. In short, does the new software function correctly for your ways of working?

Identifying and managing your requirements

You would never go into any project without clear objectives, and software implementations are no exception. It is important to understand exactly how you need software workflows and processes to operate.

To clarify your needs, it is essential to have a set of requirements outlining the intended outcomes of the processes. How do you want each workflow to perform? How will you use this system? What functionality do you need and how do you need the results presented? These are all questions that must be considered before going ahead with a software implementation project.

Creating detailed requirements will highlight areas of the business processes that will need to be tested within the software by the team leading the User Acceptance Testing.

Requirements, like the applications they describe, have a lifecycle and they are normally defined early in the purchase phase of a project. These ‘pre-purchase’ requirements will be product independent and will evolve multiple times as the application is selected, and implementation decisions are made.

While it is good practice to constantly revise the requirements list as the project proceeds, it is often the case that they are not well maintained. This can be due to a variety of reasons, but regardless of the reason you should ensure the system requirements are up to date before designing your plan for UAT.

Assessing your requirements

A common mistake for inexperienced testing teams is to test too many items or outcomes. It may seem like a good idea to test as much as possible, but this invariably means all requirements from critical to the inconsequential are tested to the same low level.

Requirements are often prioritised during product selection and implementation phases according to MoSCoW analysis. This divides requirements into Must-have, Should-have, Could-have and Wont-have and is a great tool for assessing requirements in these earlier phases.

During the UAT phase these classifications are less useful, for example there may be requirements for a complex calculation within a LIMS, ELN or ePRO system. These calculations may be classified as ‘Could-have’ or low priority because there are other options to perform the calculations outside of the system. However, if these calculations are added to the system during implementation, they are most likely, due to their complexity, a high priority for testing.

To avoid this the requirements, or more precisely their priorities, need to be re-assessed as part of the initial UAT phase.

A simple but effective way to set priority is to assess each requirement against the risk criteria and assign a testing score. The following criteria are often used together to assess risk:

• Business Risk
• Regulatory Risk (if the system is subject to regulatory compliance)
• Probability of detection (what is the chance an error would be seen by a user)

Once the priority of the requirements has been classified the UAT team can then agree how to address the requirements in each category.

A low score could mean the requirement is not tested or included in a simple checklist.

A medium score could mean the requirement is included in a test script with several requirements.

A high score could mean the requirement is the subject of a dedicated test script.

Planning UAT

A key question often asked of our team is how many test scripts will be needed and in what order should they be executed? These questions can be answered by creating a Critical Test Plan (CTP). The CTP approach requires that you first rise above the requirements and identify the key business workflows you are replicating in the system. For a LIMS system these would include:

Sample creation, Sample Receipt, Sample Prep, Testing, Result Review, Approval and Final Reporting.

Next the test titles required for each key workflow are added in a logical order to a CTP diagram, which assists in clarifying the relationship between each test. The CTP is also a great tool to communicate the planned testing and helps to visualise any workflows that may have been overlooked.

Now that the test titles have been decided upon, requirements can be assigned to a test title and we are ready to start authoring the scripts.

Choosing the right test script format

There are several different approaches to test script formats. These range from simple checklists, ‘objective based’ where an overview of the areas to test are given but not the specifics of how to test, to very prescriptive step by step instruction-based scripts.

When testing a system within the regulated space you generally have little choice but to use the step by step approach.

Test scripts containing step by step instruction should have a number of elements for each step:

• Detailed task instructions.
• The expected outcome of the actions in the step.
• The actual outcome of the step.

A typical example is given below.

However, when using the step by step format for test scripts, there are still pragmatic steps that can be taken to ensure efficient testing.

Data Setup – Often it is necessary to create system objects to test within a script. In an ELN this could be an experiment, reagent or instrument, or in ePRO a subject or site. If you are not directly testing the creation of these system objects in the test script, their creation should be detailed in a separate data setup section outside of the ‘step by step’ instructions. Besides saving time during script writing, any mistakes made in the data setup will not be classified as script errors and can be quickly corrected without impacting test execution.

Low Risk Requirements – If you have decided to test low risk requirements then consider the most appropriate way to demonstrate that they are functioning correctly. A method we have used successfully is to add low risk requirements to a table outside of the step by step instructions. The table acts as a checklist with script executers marking each requirement that they see working correctly during executing the main body of step by step instructions. This avoids adding the low requirements into the main body of the test script but still ensures they are tested.

Test Script Length – A common mistake made during script writing is to make them too long. If a step fails while executing a script, one of the resulting actions could be to re-run the script. This is onerous enough when you are on page 14 of a 15 page script. However, this is significantly more time-consuming if you are on page 99 out of 100. While there is no hard and fast rule on number of steps or pages to have within a script, it is best to keep them to a reasonable length. An alternative way to deal with longer scripts is to separate them into sections which allows the option of restarting the current block of instructions within a script, instead of the whole script.

Are all the requirements covered?

An important task when co-ordinating UAT is be fully transparent about which requirements are to be tested and in which scripts. We recommend adding this detail against each requirement in the User Requirements Specification (URS). This appended URS is often referred to as a Requirements Trace Matrix. For additional clarity we normally add a section to each test script that details all the requirements tested in the script as well as adding the individual requirement identifiers to the steps in the scripts that test them.

What comes next?

UAT is an essential phase in implementing new software, and for inexperienced users it can become time-consuming and difficult to progress. However, following the above steps from our team of experts will assist in authoring appropriate test scripts and leading to the overall success of a UAT project. In a future blog we will look at dry running scripts and formal test execution, so keep an eye on our Opinion page for further updates.

Ajit, please introduce yourself. 

My career history is uncomplicated because straight out of college I started working for myself, and it has been that way for my entire career. I graduated in the US with a background in computing science and I decided I did not want to take the traditional path of finding a job and building a career that way. I always liked to be doing things differently. Coming out of college with very little money and a limited skillset, the reasonable thing to do was to get into software consulting because that did not require a whole lot of capital. Since then, I have founded four companies in the life science sector.

What led you to the science industry?

I ended up in the pharma and life science industry very early on by chance. After I graduated, I was in Boston with database and computing skills, and I started a small consulting company called Megaware. I found out there was a large life science vendor in Massachusetts which had some opportunities around a new life science product they were building. After a lot of persistence, the CIO reluctantly gave me 15 minutes to speak with him. I told him about my background and what I was attempting to do – he said they didn’t have anything for me within his organisation, but he would connect me to his counterpart at their analytical instrument division. I then got a contract to help this analytical instrument company build a part of their (then) new product, the first database driven instrument software, and that was my entry into the pharma world. That seems simple, but it was fortuitous and persistence more than anything else.

Can you give us a potted history of each of your companies? 

My first company was Megaware. Back in those days labs were making the transition from VAX.VMS-based systems to PC-based systems. Enterprises had huge investments in VAX.VMS systems and in HP printers. We produced a product to be able to print from a VAX.VMS system onto a HP printer. It seems straightforward (but it was not!) because you are printing to a Windows-based printer but from a non-Windows system. We built a whole system to rectify this issue. I ran and built Megaware for 4 – 5 years and it was then sold to a boutique consulting company.

NuGenesis was my second company. We identified the issue that labs had several different instruments, from different vendors, but they did not talk to each other. You had large pharma companies, printing reams of paper, spending $millions of dollars on running labs across the globe and eventually all of that intellectual property ended up on paper! In those times when they submitted a new drug application, those applications were on tens of hundreds of pieces of paper which were carried to the regulatory agencies on trucks for review! It made no sense that something started out electronically and ended up on paper to be read by somebody manually. We were able to intercept print streams and capture a lot of information to make the data live. It is remarkable that 20 years later it is still being used – that says a lot about the value and sustainability of NuGenesis. I sold the business to Waters in 2004.

After I sold NuGenesis I was clear I wanted to stay in life sciences but do something different. I went back to many of my clients and ask what problems they are facing – that is when I landed into outsourcing in the area of drug safety, clinical and regulatory.

What was new and different was an area called pharmacovigilance. If you recall, there were a couple of landmark cases related to drugs in the market that had caused deaths. That is when the regulatory agencies realised they do not have a handle around adverse events. They approve drugs, they come to market and years later you start seeing adverse reactions that you did not see during the trial period. The regulatory agencies started mandating reporting of all adverse effects. With the visibility and potential liability, the biopharma industry sprang into action and the flood gates opened to drug safety outsourcing. This was when we launched Sciformix – a scientific knowledge-based outsourcing provider for the life science industry. Any given year when we got to the maturity stage we were doing around 1 million cases. We did everything from cancer drugs to consumer products, from cancer medication to sunscreen lotion. Our success at Sciformix was due to our ability to combine enough science and a very good process. Again, the company grew very rapidly to over 1300-1400 people globally, and it came to a point where it felt like the time was right to divest in 2018. Sciformix was acquired by LabCorp/Covance, a top three CRO (and currently a leader in COVID19 diagnostic testing).

What was the motivation behind the launch of Scitara? 

Having done tech, services and global delivery, I thought I should combine these skills and focus on my finale!

Our core team believes Scitara is more than just a business, it is a goal of ours to solve a major problem that still exists in the scientific laboratory: data connectivity. We are pioneering a new digital revolution when it comes to lab data connectivity. We have invented a platform called Scitara DLX (data lab exchange), and our goal with this platform is to connect your instrument, application, or anything else you use in the lab to our platform and we guarantee they can talk to each other.

Our goal is that science labs can log into any system that they are currently using and can access data from any other system that is in the lab. We have a mantra of ‘no application or instrument left behind’. For us to achieve this goal we need cooperation from the industry, which is why I am calling this a finale. It will require all our connections we have made over the years and the reputation we have built to reach out to everyone in the ecosystem. Companies are making significant headway in their digital transformation initiatives, except they do not know how to get their lab data onto their digital platforms, and that is where we come in.

How did you find your entrepreneurial drive?

I am very driven to be independent. I am useless when it comes to working for someone else and fortunately, I have never had to. My personality drives me to try new things and dive into uncertainty and this has always pushed me into something completely new.

The building of my companies motivated me. What excites me is the building from the ground up. Each time the building is easier, but the expectations are higher. I do not build to divest – I build to create value, disrupt, and hopefully deliver a meaningful impact, and the rest takes care of itself.

If anyone comes to me for advice or mentoring, I ask them why? Why do you want to do it? Why you? What is the motivation? That tells a lot very early on about the chances of success that a person may or may not achieve. It does not guarantee success, but if you have a good understanding of the ‘why’ it helps you go a long way. Beyond that I’d say it is important to find a mentor from the industry – people need to recognise that investments happen in teams not necessarily ideas. Do not latch onto an idea too much because things can change.

Create a loyal fanbase, people often think I have 500+ clients, but it is not the number that counts, it is whether you have a handful of loyal clients who make a lot of noise and reopen doors. That becomes exceedingly important.

What would you say makes you a successful entrepreneur? 

We do not rely on big sales engines in our industry. It is about building solid connections and networks. When clients learn that I created the concept behind several successful companies, people admire that. There is no better way to connect with a client than something that they are fond of and that I am proud of.

I have learnt the hard way; you build the best partnerships in tough times. When things do not go right, it is how you react that defines not only your relationship but your career as an entrepreneur. I have sold to the same clients across multiple companies. Most of those clients I have had difficult moments with, and it has made our relationship much more resilient.

Having a non-scientific viewpoint has also really helped, particularly when it comes to products. To be able to look at the consumer world, or industrial world or finance world and understand how technology has evolved there and bring those learnings into the scientific world is invaluable.

What does the future hold for Ajit Nagral? 

This is the first time after having done this for 20+ years that I have the liberty and luxury to say if this part of my journey were to end, what would be my new journey? It is the first time I have thought about it, and I think it comes with experience and the safety net I have built for me and my family. I am eternally grateful to my customer, employees and investors to put me in this position.

Hopefully Scitara is my last company, as an operating founder. There are many other things I want to do. In addition to being a tech guy I am also a musician. There are things I am doing in music production that I have started already – hopefully in a few years once I am done with Scitara, that is where I will end up!

Do you need improved laboratory informatics systems?

Systems such as LIMS, ELN, LES, SDMS and CDS can contribute significantly to increasing efficiency in the lab, releasing time for core science activities and enabling a wider audience to utilise valuable scientific data.

These systems, of course, come in a variety of formats suited for different industries and processes, from the earliest stages of cutting-edge research to the defined workflows in QC laboratories.

There is a myriad of drivers for adding or upgrading such systems however these drivers are nearly always linked to delivering faster decisions, that are more accurate and that are made with increased confidence.

Where should we invest next?

With a plethora of informatics systems all competing for your organisation’s attention, it can be complex to decide your next move. The existing systems landscape within a laboratory adds to this conundrum, as few labs are greenfield these days. Decisions on information systems made several years ago contribute to systems entanglement that influences todays’ direction.

Developing a laboratory information system strategy that defines the desired target state of systems can vastly assist in taking decisions in the short and medium term that deliver real impact without tying your hands in the longer term.

A great example of long-term goals effecting current decisions is a project we worked on twenty years ago. We worked with a Fast-Moving Consumer Goods (FMCG) company to implement a LIMS, configured to manage the day to day activities of new formulation research. A key requirement was to output the formulation candidate results to what would have been called a data warehouse back in the day. This ‘pool’ of successful and unsuccessful formulation data was to be used by statistics applications to predict interesting formulation areas. The future state being that this data analysis would reduce the number of formulations tested to produce a new product. Crucial in such a competitive space, this would ultimately reduce time to market. Interestingly, over the yearsthe LIMS used by this global company has changed several times, but the project to predict formulations is still a keystone of their information systems strategy.

This example was not chosen randomly, this challenge of balancing the provision of correct tools to support ‘bench science’ and enabling repurposing data for ‘desk-based science’ is of great significance to the life sciences industry.

Laboratory Information Systems Strategies

Information system strategies start by clearly defining what laboratory objectives are required in order to deliver the organisation’s overall business plan. Investigation workshops can then be structured with a cross section of laboratory personnel centred on both the laboratory objectives and the requirements of current and potential systems. Systems currently in place should also be evaluated typically assessing their Strengths, Weakness, Opportunities and Threats (SWOT).

The information gathered in the discovery phase can then be used to document the current state, develop the future state and importantly create a prioritised blueprint of how to move to the future state.

The diagram shows a typical laboratory information systems landscape.

 

The diagram is of course generic and simplistic, some systems will be relevant to some organisations and not to others. Even when you have a well-defined systems high level plan, there are still many details to resolve. Questions such as which processes / data do we include in ELN vs LIMS? Is one vendor for multiple systems better than multiple best of breed vendors? How master data are created and shared can derail the strategy if they are not approached with care. 

Maintaining Relevance

Keeping the IS strategy alive and aligned to the organisation’s plans is critical to achieving long term benefits.

As the picture of the new landscape starts to become clearer, now is the time to consider the governance and maintenance of the IS strategy.

• What will the composition of a steering group consist of?
• How are new projects formalised and submitted to the steering group?
• What size / scope of projects fall under the remit of the steering group?

In addition to ongoing governance, it is important to keep a watchful brief on new technology. I recently heard an industry insider decry the future of ELN and LES, ‘they will wane in popularity and disappear’. While I don’t think this will happen, I can imagine a future where ELNs and LES are driven by voice commands and VR tools, such as Microsoft HoloLens, which could be used to replace existing keyboard, mouse and monitor interfaces.

Another good example is the use of vendor neutral instrument data formats. These have been touted as the future of archive and data reuse for a considerable number of years. However, with the ever-increasing emphasis on ‘desk-based science’ and the growing interest in AI and ML, this could be ‘vendor neutral data format’s’ time in the spotlight.

Final Thoughts

IS strategies develop a structured approach for IS projects and focus your budget on achievable business objectives and promise a step change in utility for scientists.

But until more companies start to adopt best practice approaches to IS strategy, they will struggle to get the most out of their investments, not to mention the knowledge, data and resources trapped in their organisations.

• United Kingdom
• 3 Kings Court,
• Wille Snaith Rd,
• Newmarket,
• Suffolk, CB8 7SG
• +44 (1638) 661 631

• USA
• +1 (305) 677 3540

© 2020 Scimcon Limited, Registered in Cardiff No 4844956. Registered Office: 57 London Road, High Wycombe, Bucks, HP11 1BS

MENU