Maximizing a LIMS typically involves creating LIMS interfaces with other systems. SAP is a common interface but there are many others, as well.
Five LIMS Interface Examples And Their Purposes
Here are just five examples of common LIMS interfaces and their purposes:
- MES (Manufacturing Execution System) – you’ve heard of an LES (Lab Execution System) which enforces procedures within the lab. An MES is the same thing but for manufacturing. It’s a way to structure the processes and enforce their order, exceptions handling, types of information entered at various steps, and similar data and process issues. The MES requires sampling at various points in order to track the product quality. It can tell LIMS how much of various manufacturing materials were combined. It can indicate to the LIMS what type of material to test and at what manufacturing step this is. LIMS then performs the testing and sends back some amount of information that the MES requires. This is typically some pass/fail information, as well as some of the testing that is specifically needed by the LES.
- ERP (Enterprise Resource Planning) – the purpose of these systems is to automate your entire business. This includes financials and other office-related tasks. It also includes various technology solutions, as well. An ERP can have some amount of manufacturing features including MES functionallity included as part of it. SAP is just one example of this. Where LIMS comes into this is that the ERP manages the quality sampling and sends to to LIMS, LIMS does the work and reports back.
- Accounting Systems – some companies charge tests back to either internal or external customers. In these companies, the LIMS and the accounting system get an interface. Typically, at the end of each month, the LIMS will send chargeback information to the accounting system. Where the MES and ERP interfaces tend to get real-time interfaces, this type tends to be done in a batch mode.
- Calendars and Time Management Systems – labs with a high throughout tend to prioritize tests and organize them with regard to which tests for what samples should be done, first. Some of this is based on due dates but also on the availability and load of the instruments. Then, the LIMS the company’s calendar system get an interface. This is often a real-time interface.
- Instruments and Instrument Software – this is the most common type of interface with a LIMS. This is because it’s often the place that provides the most value. When we consider that LIMS, or even ELNs or LES, are systems that, at their core, cut down on transcription errors, then this is obviously the most important interface to most groups. The more complex the instrument, the more likely the interface will be with some type of software that runs the instrument.
Even Instrument to LIMS Interfaces Can be Complicated
Let’s consider the instrument interfaces. These appear to be the most common and “simplest” of LIMS intefaces. Yet, even instruments can have processes around them that affect the interface. For example, when we look at testing such as drug delivery or uniformity of dosage units, we’re no longer merely looking at sending some test results from the instrument software back to LIMS. Now, we’re looking at controlling the USP/BP/EP/JP PASS/FAIL/CONTINUE process.
Then, where should that happen? In the LIMS? At the instrument-level? Either way, there are data and process issues to work out. As complex as this becomes (and it can), it’s one of the easier example. When you start interfacing plate reader software, such as SoftMax Pro, you realize there are yet more process issues to resolve and yet more levels of complexity. The point I’m trying to make is just that instrument interfacing isn’t as simple as some think when they say “just write a script and be done with it.”
Your Process Isn’t Their Process
Two systems will have different processes.
Here’s another way to explain this – the purpose of an accounting system or an MES is entirely different than that of a LIMS, ELN or an LES. A LIMS process isn’t like an ELN process, either. They not only have different data but different processes, of course. But the point at which they need similar data is entirely different.
For example, let’s suppose that the MES system has mixing materials and done some processing to them. It could be fermentation, distillation, anything really. But it then asks the user to take a sample to send to the lab for testing to do the quality check. No problem, at this point, that the user takes the sample and gets it to the lab.
From there, the lab needs to test it. It does need to know some additional information about what’s being tested. This is in order to know which tests to run. In addition, if the MES system wants the LIMS to send back a pass/fail indication, the LIMS needs some way to identify yet more about that material, possibly even the version of a product formula.
Let’s add a layer – a PLM system. The PLM (Product Lifecycle Management) system manages the product versions. If the PLM interfaces only with the MES and only for certain steps, then there is no link to the LIMS to provide the product version information. It’s common to miss issues such as this when planning interfaces.
You might now think it’s easy to add that in but it might not be. If the PLM interface is considered “done” then you might have to bring in more people to add this feature into the PLM interface.
No, Seriously, Your Process Isn’t Their Process: Three Reasons Why
Now, some of you have also tried to interface a LIMS with a LIMS or an ELN with an ELN, for example. It’s still not trivial. Here are three reasons why:
- Two brands of LIMS will have different table and field structures.
- Two implementations of the same brand of LIMS, even for the same type of lab, will usually be implemented slightly differently. This is true even if they’re implemented by exactly the same implementation team. After all, they’re separate for a reason and the reasons probably have to do with slightly different processes and data.
- You can have exactly the same type of data in two systems and it doesn’t always easily map. The most common example are stability time points and conditions. They seem straightforward but there are a wide variety of variations on how implementations represent them.
When Two Systems Don’t Map, Who Wins?: SAP Example
If you’re interfacing anything with SAP and something doesn’t quite map, SAP always wins. Sorry, but that’s just how it is.
One reason is that SAP is considered the more important system because it’s running the company. It’s also typically more difficult and more expensive to change the SAP processes and programming.
But let’s suppose there’s just one bit of missing information that your system needs from SAP. And, let’s suppose that you get the bright idea that, “Hey, all I really need to do is link to one of the SAP tables to get the extra bit of information the LIMS, ELN or LES needs.” Nope, sorry. So far, I haven’t yet been on a project with an SAP interface that allows this, whether it’s with QM or any other part. There appear to be a variety of reasons for this but, seriously, start thinking of other options.
When Two Systems Don’t Map, Who Wins?: Everyone Else
When you’re putting in two systems around the same time, you can negotiate between them. That doesn’t mean there won’t be mistakes or limitations that have to be worked around. It can be difficult to think of every issue and that’s why there should be periods where everyone tries their pieces out, together, as a systems integration test.
However, whichever system was created, first, it is them most likely to be the other system that has to do extra programming in order to make it all work.
But that doesn’t always work, either. Let’s suppose that you have one system in-place but the process of the other system entirely just doesn’t work even with extra programming. In that case, you have to put in the difficult work to determine how best to address this.
LIMS Interfaces: An Example
Let’s suppose your MES system has these steps:
- Notification that it’s time to take the sample. The information available is the batch number coming from the manufacturing system. This happens in a real-time manner as soon as the MES is ready to ask for the samples. At this point, it sends LIMS a message to start testing.
- This steps waits for the testing. Then, it gathers all the information about what formula version relates to this step. This actually already happened a few steps ago. It had to happen in order to make the material. However, it’s not done, again, until the MES has the samples back is is ready to do its reporting back to the shop floor. Yet here in this step, it’s waiting for a message back from LIMS, first, before it will go to gather any extra information.
So, in step # 1, LIMS received a message to start testing and must send that information back for the MES’ step # 2 to happen. However, what if LIMS is supposed to check the specs? And what if the specs aren’t in LIMS but coming from the MES? This does happen, by the way. Then, in the case where the MES wants the LIMS to check the specs, more work needs to be put into this process.
Yet More Thoughts on LIMS Intefaces
Let’s go back to that example from the previous section. If one of these systems is already implemented and running, it’s might be quite difficult to change it.
For example, suppose your LIMS has been running for some number of years. Now, you automate one division. In addition, to do that, there’s some truly basic manner in which your LIMS works that just doesn’t work with the way you want to implement your MES. Do you force the MES to have more complex processes and leave the LIMS alone? Or, do you spend a great deal of money to change something that could affect the way your entire LIMS works? If you do that, do you do it just for one division or for everyone? How do you address retrofitting all your past LIMS data?
Honoring Processes and Data Within LIMS Interfaces
Let’s suppose that you’re working with another team on an interface between your system and theirs and you realize you need or want to make a change to the interface or the way you’ll use it. You have to contact them to work through the change to ensure it won’t affect the effectiveness of the interface. That’s true whether it’s a process change or a data change.
Now, let’s suppose you’re the system that “wins.” Let’s suppose you’re the system that makes changes that EVERYONE ELSE has to live with with no complaint. At the VERY LEAST, you should notify them all BEFORE YOU DO IT! No excuses on this and I sincerely mean that.
Even something trivial, such as changing the data in your dropdown boxes and the associated information can. This simple change can cause problems for someone else’s system. One great example is if you have a clinical system and you change from sending the one-letter codes “M” and “F” to sending the actual words (and more of them, by the way) “MALE”, “FEMALE” and “NONBINARY” you need to notify every system on the receiving end. In addition, if you’re a decent planner, you’ll notify them all in enough time that they can address any programming changes their sides might need. I can imagine some have programmed their system as “IF (patientSex = /M’) THEN doTheMailSetOfTests ELSE doTheFemaleSetOfTests” so give them a chance to prepare.
Let me go back to this example yet one more time – there is no reason nor excuse for this to happen. I agree that human beings occasionally make mistakes and miss things. But that’s not the same as just not caring to manage the interface. Interfaces are a project in and of themselves. Manage them, accordingly.
Final Thoughts on LIMS Interfaces
For anyone who thinks that LIMS interfaces have to do with buying third-party software with drag-and-drop features and just making it happen, think again.