Maybe. R&D and QC LIMS can be combined under some circumstances. However, there are a number of factors to consider.

Security and Data Segregation

There are several factors you have to manage in order to combine R&D and QC LIMS systems. In fact, it actually doesn’t necessarily matter if it’s R&D and QC, combined, or some other combination.

The first issue to tackle is that of security and data segregation. You have to have a way to segregate the data between groups. It is partly a matter of security. However, there are times when two groups share security but they don’t want to see each other’s work in every process step.

Some Questions to Ask When Combing R&D and QC LIMS

In order to consider combining an R&D and QC LIMS, you can start by investigating the situation you have, at-hand. Here are some questions to ask of each group and the way they might or might not share data. Ask this for each group and make sure you include everyone involved in these discussions:

  • Which groups should see this data?
  • If they can see the data, when should they be able to see it? (e.g., through the entire process? after final approval?)
  • Exactly how should they see this data? (e.g., should they see raw data or merely final data?)
  • Which groups should change this data?
  • If they can change this data, when should they be able to change it? (e.g., can they change it after it’s been through one approval level? after two approval levels? after release?)
  • Exactly how much of this data would they need to change? (e.g., most people can change their own data if they notice they’ve made a mistake and they do it before the next approval step; however, a supervisor might be able to make corrections to anyone’s data in the group that they supervise)
  • Go back to all of these access requirements and ask how often this is needed. For example, if someone needs to see a group’s data all through their process, they probably get some security function to view the data. If they only need to see it in its final form, they might only receive the final report. In addition, that report might get sent out after a data approval step.

More on Data Segregation

Regardless of the access that we just went over, If we combine R&D and QC, they probably don’t want to see each other’s information when they’re trying to do their work. Often, the R&D Chromatography lab doesn’t want to see the QC Chromatography lab’s test list when work is actually being done. Likewise, no-one from Site A’s Chromatography labs wants to see what Site B’s labs are working on in their work folders.

Think of your own desk. You have access to everything on your desk. You have access to everything on top of your desk and all your file cabinets. However, you probably don’t keep absolutely everything on top of your desk. You keep some things out of site but easily accessible if you need them. Then, there are archived things that you have to do a bit more work to get at. However, they are still available if you do have to get at them.

Security and accessibility works a bit the same way. You have access to what you need but it doesn’t mean that you see it, all the time. Nor does it mean that access is immediate and easy. It’s just a way to both keep data secure AND keep us from being overburdened with too much of it.

Combo R&D and QC LIMS Products

Once, again, while I’m talking about combining R&D and QC LIMS as one system, this discussion applies to any combination of systems. It could be of different languages of implementations or different sites that do very different things.

The key is that you have to buy a system that can handle all of this. AND, this is really important so pay attention, but you have to plan this from the start. If you don’t, you’ll be spending too much time retrofitting it. It’s not impossible to retrofit but I’m telling you that you will be so regretful.

GxP Versus Non-GxP

Keep in mind as you read this, that combining an R&D and QC LIMS is a similar issue to that of combing GxP and non-GxP labs in one system.

Buying the Combo R&D and QC LIMS System

Here’s the bottom line: the more twists you have, in how many different languages, how many types of security, how many different workflows, and any other variation, the more expensive the system will be and more complex. There are three basic reasons for the increase in cost:

  • You will buy a system that has a wide variety of all these tools and that’s expensive.
  • Implementation will be expensive. The external services costs will be greater and your internal costs to participate in this will be greater.
  • Long-term maintenance will be more complex. You’d better put together some good documentation and a good support mechanism. It pains me to tell you that your next LIMS System Admin might come along, not understand what you’ve done, and just start overriding it all (seriously, everything you just paid for is undone – I’m absolutely not kidding that I’ve seen this happen).

Some of this isn’t obvious, either. It’s common to be able to change or add languages to products. It’s a lot different to do that and have a single language running than to start to support multiple languages in one system instance. And it becomes yet more complex when some sites need multiple languages. For example, where you have laws that require two languages be available, you must accommodate them. Another example is where you have to create sample labels in multiple languages in order to ship them to other sites in other parts of the world. That’s a separate issue from showing the correct language to a live user.

R&D and QC LIMS Processes

The question whether to combine R&D and QC LIMS can cause concern. Somewhere along the way, someone in R&D is feeling concerned that they’re going to be forced to use the QC processes, e-sigging everything in sight, and being forced into some kind of rigid nightmare. Someone in QC is concerned that they’re accidentally going to be using some R&D method that isn’t ready for QC with all its loosey-goosey flexibility and they’re already standing up and shouting, “But that’s not GMP!”

Nope. Don’t do that.

It’s pretty simple, really. R&D and QC should have their own methods and processes. If a system can’t accommodate that, then you can’t combine them. Now, while this is a simple concept, it’s difficult to implement. It’s just plain a lot of planning and work.

Along the way, many people will have the bright idea that R&D creates methods and specification limits that will be used for the QC group and why not just share them, right? Indeed, it does sound appealing and ever so practical. But it wouldn’t be a good idea.

An Example: Analysis and Specification Versions

It can be difficult to segregate the version of the analyses or specifications that R&D is working on from those that QC is actually using. Each needs to take different paths. Early in the process, R&D will be working on a single “working” version. They might change it several times before they start “versioning” it in the LIMS.

You have to have a way to “hide” this from QC and that’s not necessarily a simple thing to do. When I say we “hide” it, it’s because QC depends on having the versions managed and automated as much as possible. Most of the versions QC uses aren’t part of a decision-making process, they just “are.” On the QC side, it’s just not considered a good idea to have a bunch of extra versions popping-up, either. In fact, the extra versions probably have to be justified, depending on the products involved, and that’s a lot of extra work.

So, then the issue how to share these comes up. In some systems, you could actually do something like a SaveAs and save the R&D version to be the new QC version. Regardless, you have to have a procedure or a program set up for this. You’ll need to change the security groups, there will be lists, tables and other information that changes – it’s seldom quite as simple as doing a SaveAs to a new name.

Benefits to Combining Systems

You have to look carefully at what you have to determine what benefits you’ll get to combining systems. From what you’ve read, you now understand that, even with R&D and QC being combined into one implementation, that they’re still running separate processes and much of their template data is separated.

Keep in-mind that good programmers will develop some of the multitude of programs that can be used by both groups. Good programmers will make these programs flexible and parameterized (if you don’t know what this means, then you shouldn’t be writing these programs, by the way). These programs can be quite huge, even when these software packages come with lots of “modules” or “plug-ins” or “add-ons” or whatever the vendor decides to call them. Systems such as the LabWare LIMS / ELN or the SampleManager LIMS / LES have powerful tools that can assist you in combining your systems but have high services costs. Thus, it makes sense to plan, accordingly.

Having a centralized management of all this programming can be beneficial because it costs a lot of money to hire all the programmers to properly create and manage them. Even if you don’t have just one centralized group, being able to have several groups around the world rather than a programmer per site per division per laboratory is much more efficient. Getting people trained and coordinated is just so expensive that it’s not a good idea. Plus, you can’t have just one. If you have just one, you have none on the day they’re sick or quit their job.

In addition, if you’re at a large company that has a follow-the-sun plan, you can coordinate the worldwide teams. Then, if you’ve done a good job of it, they can help support issues that occur in the off-hours in other regions.


The bottom line is that there’s no one answer to how to model this. It makes sense to share code among labs that share many common requirements, for starters. When they’re scattered around the world, big companies might have an implementation per some geographic region in order to maintain high system response, but where each system is just a copy of each other. Consider features, geographic response times, and languages, for starters.

Still Confused?

If this all sounds confusing, it’s time to call GeoMetrick Enterprises. We will work with you to come up with a plan that meets your needs.

One Thought to “Should R&D and QC LIMS Be in One System?”

Comments are closed.