Finding a Middle Ground

Those who attended IQPC’s 14th Annual Laboratory Informatics Conference (September 2015, Brussels) had an opportunity to see two sides of the integration of laboratory data/information with corporate systems: the use of information technology within the lab and the use of lab data/information along with data and information collected from other sources merged into “big data” data sets. That opportunity was the result of a parallel conference on big data in the pharmaceutical industry. One observation, which shouldn’t be a surprise to anyone, is that the use of information technology in the laboratory is changing the lab’s role within organizations. In some cases—startups, for example—the lab is the organization; in others, it is a place where data and information are produced to drive corporate decisions on the progress of research programs, providing physical and analytical test results that answer questions about materials, determine the quality of products, and monitor production processes.

The movement away from paper-based data and information management to electronic integration has opened the door to better communication between the lab and the corporate mainstream. The benefits of that communication include a better understanding of the value of lab work to the larger organization and an improved ability to work with lab data in conjunction with other data streams. The potential downside is that lab systems no longer operate in an isolated information bubble. Once upon a time, lab management’s purchase of technology depended solely on the needs of the scientific work; now an additional set of issues has come into play. As laboratory work becomes more technologically sophisticated, the decision process for new purchases brings in a wider range of concerns and considerations.

The impact of organizational integration on the purchase of laboratory systems

The use of digital technology in the laboratory has changed the way products are specified and purchased. Science-based tools (pH meters, balances, instruments, etc.) were, and are, purchased without outside support even if they have digital components. Digital informatics- based systems are different because they provide solutions to laboratory problems that bring in layers of technology and considerations that lie outside traditional, science-based work.

Traditional education programs don’t prepare lab personnel for the tasks and decisions necessary to successfully plan and implement informatics systems in a corporate environment.

Related Article: Informatics are Really, Really, Really Important

This has moved from a science-based process to a multidisciplinary process of science, workflow management and planning, systems integration, and IT. What that means to the lab manager and lab personnel is that a broader range of expertise needs to be brought in, most notably representatives from IT groups and possibly technology management specialists, people who have expertise that bridges the science and IT realms to help facilitate the work. The roles of these groups can be seen in the development of user requirements for lab informatics systems.

First and foremost, user requirements documents should reflect the lab’s needs and not be limited by existing corporate systems. The purpose of a user requirements document is to tell your managers and any other groups what problems have presented themselves and need to be solved. When these documents are drafted, you shouldn’t start your product requirements with “We need a LIMS [laboratory information management system] or an ELN [electronic laboratory notebook].” That statement will focus your thinking in one direction or another, and you’ll miss some key points; the emphasis should be on functions rather than possible solutions—those come later. A number of people I’ve spoken to start thinking in terms of a LIMS because they take “laboratory information management system” too broadly and literally, when what they need is something else entirely. The answer to your product needs might be a LIMS or an ELN, a combination of those with other products, or a hybrid combination of a LIMS and an ELN, maybe with a side order of a lab execution system or a scientific data management system (SDMS). The details of these technologies are available elsewhere. You should become familiar with those details so that you can better understand the proposals that are being presented and the interplay between components if multiple products are needed; these tools will significantly affect your lab’s operations. Note: LIMSs tend to dominate routine testing and quality control, and ELNs are predominant in research, but there are exceptions, so the “obvious choice” may not be the best choice for you.

The basic questions you need to ask are:

• What issues need to be addressed?
• How do you want your lab to operate?
• Do you have a plan for your lab’s technology use?
• What role do you see the products playing in transforming lab operations?
• What will happen if the project is a success?
• What will happen if the project fails?

Developing user requirements is the responsibility of the lab personnel and managers; it is your lab, and you are in the best position to determine how it should function and to evaluate the tools needed. You may want to take advantage of an independent third party to help ask the questions and probe for answers, and possibly to guide the process, but the answers have to come from you. Unless you are fortunate enough to have someone in IT with a lab background and good understanding of how your lab works, this isn’t a place where corporate IT fits in yet.

One important item that separates lab work from other work in an organization (aside from process control in production operations) is the role of instrumentation and communication between instruments and informatics systems. If those connections are going to be part of your requirements, they need to be stated early on. There are different ways of implementing instrument-informatics communications, and they aren’t all equally appropriate for any given situation. One example is bidirectional communication between a LIMS or an ELN and a balance or pH meter. The process of using those items with an informatics system could require multiple readings and calculations (telling the system that an empty sample container has been placed on the balance, for example, and then that the sample has been placed in the container), with the system recording both values and making calculations. That kind of need can dictate connection mechanisms that support interactive communication rather than simple data transfer.

All current and planned instrument connections, including the type of communication and use that is expected, should be part of the user requirements. Other examples include the exchange of work lists between an informatics system and an instrument-computer combination.

So far everything we’ve discussed affects work and systems inside the laboratory. Corporate IT groups will have concerns about network traffic, the computers being used, and their role in supporting the systems, which could be addressed in conjunction with vendor support groups. The next step is where corporate IT would definitely enter the picture. Corporate IT is responsible for the overall information and communication infrastructure of the organization. Your lab is part of that infrastructure. Corporate IT is accountable for the networks used, backups (both local and online), system maintenance, and, with increasing importance, systems security. That work may be done by an in-house group or be completely or partially handled by an outside organization. Just as you may not be educated in the details of information technology, corporate IT may not have been exposed to the details of lab work. You need to find a middle ground, either by educating them (give them a tour of the lab, not to impress them but to make them comfortable being there) or bringing in someone with science and information technology experience to bridge that gap. The reason is fairly simple: you need them on your side.

Why corporate IT is your friend

The evolution of information technology has moved from having everything nearby in the lab to networked systems that might be within a stone’s throw of your lab or in another state or country. Systems such as LIMSs, ELNs, and SDMSs have several types of implementations:

• In the lab, or somewhere close to it, usually in the same building. This structure is useful since it facilitates connections between instruments and data systems.
• Campus wide private cloud. If several labs are sharing access to the same
  application software, with either shared databases or separate instances where your lab is independent of the others, this can reduce costs and make support easier. Instrument connections can be made over networks or via local-to-the-lab instrument data systems, including SDMSs.
• External cloud systems that are hosted on the vendor’s hardware at a remote location. These offer low
  start-up costs and get up and running quickly, with no support required and no hardware installed.

Some product sources may support only one of these implementation types; others, such as CORE Informatics (www.coreinformatics.com), support all three, allowing you to get a fast start and migrate from one to another as needs dictate.

All of these will require assistance from IT in order to get you up and running. It may need very little, as in the third option, but IT can help provide secure network access and other capabilities.

Among those “other capabilities” are:

• Vendor evaluation. You are responsible for determining the functional features; IT can look at technical issues like the vendor’s technology, supportability, upgrade policies, etc.
• If remote hosting is being considered, IT can evaluate how reliable the hosting system is and identify legal issues involved with shared hosting or private instances on remote servers. The latter points are critical for intellectual property considerations.

Now we return to the beginning of this article, connections between lab systems and the corporate world; this is IT’s home ground. As noted, lab systems do not exist leadership & staffing in isolation as they once did. Organizations want to make use of data/information as quickly as possible to get the most value from it, and that means transfers to larger databases. IT can make that happen, and if this is a consideration, their input will become part of the user requirements—“user” becomes broadened to mean you and the organization that supports you.

Labs and IT groups have an interesting history, with the word “conflict” frequently being used. Most problems between labs and IT services are matters of conflicting policies and education, both of which can and should be solved to the benefit of both groups. The size of the organization has an impact on this and may require senior managers to make a realistic appraisal of goals and what it will take to reach them. This becomes more complex with outsourcing IT services, since that group may not have the commitment to success, the motivation to develop closer relationships, or the lab-savvy background needed to make things work that an internal group does.

Skills Needed to Successfully Implement a Laboratory Informatics System

Learn what each member of your team will need to bring to the table in order to make your lab informatics implementation as smooth as possible. www.labmanager.com/ITs-complicated