In a recent article on the Scientific Computing World website, Change and continuity, Tom Wilkie described how Starlims, now under the ownership of the multinational corporation Abbott, is looking to expand into the healthcare informatics sector. The article pointed out that in the past, the healthcare informatics market and the traditional LIMS market have been very separate. Even the acronyms are different: LIS versus LIMS.
It’s an appropriate moment therefore to take a more general look at, and try to shed light on, developments in these two areas of informatics. Where LIMS stands for ‘laboratory information management system’ and LIS stands for ‘laboratory information system,’ it is no wonder that many people are uncertain of the difference between the two. Add to that, the fact that the two systems have converged somewhat in functionality over the years, and the confusion mounts.
Traditional definitions
There is no such thing as a ‘traditional’ LIMS or LIS. While our industries have created broad definitions, no actual system matches those theoretical definitions one hundred per cent. A more productive approach is to consider what the systems tended to be used for initially.
LIMS: past to present
In the early days of LIMS, these systems were meant to manage samples in the laboratory, usually an analytical laboratory. Features of these systems were that they tracked samples, tests, and results throughout their locations and testing, and that they kept track of the actual test results recorded and the calculations performed. Some of these systems even allowed data to be gathered directly from instruments and instrument software. The critical point to note is that LIMS tend to be sample-based.
In the many years that have elapsed since those early systems, most LIMS now do many more things than merely tracking samples, tests, and results. In fact, some LIMS track things that are definitely not true samples. For example, quite a few LIMS have stability modules, which track stability pulls. There are LIMS that track instrumentation calibrations. These days, most LIMS systems can gather data from a variety of sources, not merely instrument-based sources. In addition, some LIMS now have LIS-like features.
LIS: past to present
The original LIS systems were intended as ‘clinical’ systems. In this context, the term ‘clinical’ refers to clinical diagnostics and the patient; but did not include clinical drug trials. This can be confusing terminology, as many pieces of software will now also manage clinical trials and the term ‘clinical’ is sometimes used in that respect as well. For the purposes of this article, the term ‘clinical’ will be used to refer to clinical diagnostic-based systems. These systems tended to offer features that manage the actual patient data and testing details, rather than addressing the workflow. The critical point to note here is that LIS tend to be patient-based.
Crossover of features
These days, LIS systems have incorporated more and more of what would have, in the past, been considered to be LIMS features. In order to serve many markets, some LIMS and LIS products have begun to encroach on each other’s territory. Some LIS systems now have full capability to manage the testing and samples that are taken as part of a patient’s records. More LIS systems now allow those samples to be tracked for location and status of testing, for example, as well as allowing more flexible workflows. Additionally, more LIS systems are now capable of importing data from instruments and other sources. On the other side, there are LIMS that are now allowing for the different auditing that is needed for patient testing. Most customers of LIMS are not interested in who reads a record, but only who changes or deletes it. In a LIS, it is important to track who has had any kind of access to a patient record, whether they are merely reading it or changing it.
Since much patient testing is performed by independent laboratories, billing has been an important feature for LIS systems – especially in private healthcare systems, such as that in the USA. However, in recent years LIMS systems have been routinely used by contract laboratories that require billing and CRM (customer relationship management), as well, so these types of features are now commonly offered by both LIS and LIMS systems.
Regulatory issues
Regulatory issues to meet clinical needs now tend to be addressed by both types of systems that wish to serve this market. One example in the United States is CLIA (Clinical Laboratory Improvement Amendments – clinical testing guidelines). Patient (personal) privacy is an important issue in much of the world and these systems must follow the United States’ HIPAA (Health Insurance Portability and Accountability Act), Canada’s PIPEDA (Personal Information Protection and Electronic Documents Act), or Europe’s ECHR (European Convention on Human Rights). Internationally, these types of systems need to address HL7 (Health Level 7 – a framework for electronic data exchange).
However, there are some regulations that do not necessarily come specifically from the clinical side, such as the United States’ GLP (Good Laboratory Practice) and 21 CFR Part 11 (the US Food and Drug Administration’s compliance rules for electronic records). These issues affect many sample-based situations.
Specific examples
Trish Meek, director of product strategy for the informatics business at Thermo Fisher Scientific, gave an account of the company’s Clinical LIMS solution. While this product was specifically built as a LIMS, it is now being used also as a patient-based system to compete directly as a LIS. It addresses both regulatory issues such as CLIA and HIPAA, but also laboratory needs such as next-gen sequencing and plate-based planning. At the same time, none of this takes away from the workflow-based features inherent in the product. The samples/aliquots features that are in the base system can also be used with the more LIS-based features such as patient management, physician test request forms and medical billing to give a fuller base of features. Plus, as mentioned previously, systems such as this are meant to interface with just about anything; and this is another set of features that transfers easily from the LIMS into the LIS model.
One important piece of context is worth noting. In general LIMS discussions, the issue of GLP versus non-GLP often arises: where we wonder whether services personnel who have experience in one area can easily switch to the other. The answer is that they can do it, but they do need to know a few key issues about the other ‘side’. However, when talking about a product such as a LIS that would interface with medical devices, where making a mistake can actually kill a person and where there are complex rules to follow, software vendors implementing these systems stress that the issue of using untrained personnel can be a true disaster.
Some of these issues were also mentioned by Ed Krasovec, director of clinical solutions at LabWare. LabWare’s approach is similar, in that the LabWare LIMS product has native features to support clinical laboratory workflow, instrument interfacing, sampling, and aliquoting. LabWare’s product architecture allows for the addition of patient management features that enable the system to be patient-centric, while maintaining all sample management and tracking capabilities. LabWare has been able to address the LIS market’s needs using a configurable modular-based approach, to give a flexible, comprehensive, and regulatory compliant solution to the clinical laboratory market which for LabWare includes hospitals, reference labs, and public health labs. Another factor Krasovec brought up in discussion is that specimen storage management features commonly used in clinical research/biobanking are increasingly being utilised in diagnostic settings to facilitate translational research efforts.
Nicoleta Economou, regional marketing specialist, clinical informatics at PerkinElmer and Greg Moody, executive director life science analytics at PerkinElmer, illustrated a somewhat different approach. They maintain that PerkinElmer has a variety of products that could be and are used by their customers within the clinical laboratory situation. Some of them help manage workflow, others might interface with instruments – whatever the need, it would be addressed by a collection of products that best fits the customer’s needs. Thus, instead of focusing on a specific products and adding features to those products to meet the customers’ needs, they look at the entire industry’s needs and focus their solutions on that. They look to the regulatory needs, and the features needed, and use their products as pieces of the puzzle to create the right solution.
Finally
While we now have some idea that what we might have thought of as a LIMS or a LIS has converged, it is not necessarily a simple transition to purchase a product meant for one area and use it in another. This is not merely because of the difference in features, but also due to the difference in regulations from industry-to-industry and country-to-country. While software vendors might have different approaches and provide more complete solutions than might have been available in the past, they nonetheless have to find ways to address these issues in ways that are supportable for their customers.
