Initially, the search for a cloud laboratory information management system (LIMS) provider is no different from selecting a classic LIMS. You still need to review your current work flows and evaluate reengineering them to improve efficiency, as well as generating the requirements list and other steps to ensure that the LIMS can provide all the functionality that you require.
However, moving to the cloud, while simplifying some things, definitely adds another layer of complexity and questions that you need to make sure are asked and answered. Some of these questions you can delegate to your LIMS selection team or, in some cases, the organization’s IT group or an independent consultant. However, it is imperative that they are asked. The responses that are most critical to a small, independent testing laboratory may prove quite different from those of a global, multinational organization with labs located around the world. The rest of this article will list some of these questions, then explain why it is important to ask them. In many cases, it is expedient to ask the LIMS vendor’s engineering team, as the marketing team is unlikely to be able to supply the technical answers you require. This is also why you are pulling in knowledgeable people from outside the lab, to make sure that the answers provided are understandable and reasonable. You will likely find that the answers received result in requiring a much more detailed and extensive service level agreement (SLA) than initially anticipated.
Who is the cloud provider and what type of cloud do they provide?
In theory, a LIMS provider could also provide their own cloud; however, all whom I have spoken to partner with an existing cloud provider, basically playing to the strengths of both. Most reputable cloud providers will post a document regarding using their cloud in a GxP environment.
A cloud can be public, either as single-tenant or multitenant, or can be private. In practice, a single-tenant cloud is much easier to validate1 and is less prone to intrusion.
Does the LIMS support internationalization (I18N), multinationalization (M18N), or globalization (g11n)?
These numeronyms identify software supporting different degrees of localization. I18N systems have the application text separated from the application code, so that you can localize it for a specific area by substituting a resource library in the target language. M18N and g11n systems go further by tying the language and time displayed, along with other localization features, to a given user ID, allowing two people in the same lab to use their preferred language, or have a single application support global workers in their native languages.
How does the LIMS handle interfacing with instruments in the laboratory?
This question requires a detailed answer, as the primary data acquisition of some systems is to poll a directory at the customer’s site and, on finding a file, transfer it, parse it, and import the results into the LIMS database. As there is no direct “handshake” between the instrument and the LIMS, this could be a regulatory violation, unless the vendor can document steps they have taken to ensure that the result file could not be modified before import.
Some systems are capable of interfacing with existing chromatography data systems (CDSs) and other informatics systems in the laboratory in order to pull data from them. If you don’t have a CDS or the LIMS doesn’t support yours, can it interface directly with chromatographs or other instruments that have an Ethernet port to possibly control and pull data from them?
How does the LIMS interface with legacy instruments, or does it even support that function? If additional hardware is required, can the LIMS vendor provide it or must it be obtained from a third-party source, or even be fabricated internally?
Where is the LIMS data actually stored?
When dealing with larger organizations, particularly multinational organizations and governments, this can become a critical question. Unless it is explicitly specified in your SLA, your data could be stored anywhere, and that location could be subject to random change. This is important because there is currently no global agreement regarding who has legal jurisdiction over that data. In other words, if your SLA doesn’t specify where your data is stored, you don’t necessarily know which government’s laws are going to apply to it. Attempts by the U.S. government to obtain data stored on European servers is the reason that the Safe Harbor Agreement between the U.S. and the EU was invalidated.
Who performs the system validation to ensure regulatory compliance and how is this validation maintained?
Legally, the customer is responsible for compliance with all applicable regulations; however, some vendors sell “prevalidated” systems. Normally, when you purchase software, it can’t be prevalidated, as the validation has to take place in its actual usage environment. Since you are effectively leasing a cloud LIMS, it is important to know exactly what the vendor means by prevalidated and the scope that covers. What do you still need to validate on the laboratory’s end? Does this cover validation of the cloud provider and their systems, or do you have to address that separately?
Historically, when you create a new test in the system, you create it on a separate system for validation purposes, before then rolling over the new test to your production system. Does the vendor provide an instance of such a test/development system or is that a separate expense you are charged for?
Migration to the cloud is frequently sold using the justification that the cloud provider handles all software upgrades and patches, to ensure that you are always running the most recent version of the system. As this is an alteration to the system, who is required to handle revalidation to ensure that the system stays in compliance?
Remember, regulatorily, you are the one legally responsible for validation of the overall system. Technically, any change to the system renders previous validations void. This can be addressed in several ways, e.g., your SLA could prohibit automatic upgrades to the system so that your validation remains effective, but leaving you potentially exposed to existing security holes. Does the vendor periodically revalidate their software against a patched system and then upgrade all the effective servers? They would be the logical ones to do this, since they know the most about the application, but due diligence would likely require you to perform testing as well. Something else to include in your SLA.
Cloud-based LIMSs are frequently sold with the justification that they eliminate the need for investment in internal IT resources. What internal investments does it actually eliminate, and what are the “hidden costs” of resources that the laboratory must still provide?
Presumably, you will still require IT staff for maintenance of your network, if nothing else. However, they may well be involved in helping set up any instrument interfaces as well as troubleshooting any network connectivity issues with the LIMS. All this is a hidden cost that needs to be included in your evaluation.
As both the application servers and software are outside the user’s control, how can you ensure that 21 CFR Part 11 compliance, or equivalent, is being maintained?
One requirement of 21 CFR Part 11 is that the application server be located in a secured location. What kind of documentation can the LIMS vendor provide that this is being done?
Many reputable cloud vendors do take steps to ensure the physical security of your servers and data, but some vendors don’t or might refuse access to an auditor attempting to physically verify the vendor’s security measures.2 Guaranteeing this access can be another item in your SLA.
How is overall system security handled and data integrity maintained?
Does the cloud provider employ state-of- the-art firewalls, malware detection, and intruder detection technology?
Is the LIMS data encrypted during all transfers and while at rest?
Who controls the encryption keys?
As ensuring data integrity is a critical LIMS feature, how detailed is the system’s audit trail, who configures it, and where is it maintained?
The primary purpose of an audit trail is to ensure the authenticity of the data. In theory, you should be able to rebuild your entire LIMS database from the audit trail.3 This requires that the audit trail data be stored on a different server than the result data. Is the system default set to store a fully detailed audit trail?
Does the cloud vendor capture and maintain detailed server and network logs? This includes enabling all the server security logging required for a forensic analysis, which is frequently defaulted to off.
How is data backup handled and who is responsible for it?
Some cloud providers use the cloud itself for backup. Others provide alternate means to back up your data, but consider it the user’s responsibility to perform that backup. It is critical that responsibility for the backup be clear and included in the SLA.
How is disaster recovery handled and who is responsible for it?
The responses to this question might vary, particularly with the size of your organization. If you are running on multiple servers, if one server fails due to high demand, the others you are using might simply pick up the load. If you are running on a single virtual server, does the cloud provider maintain a hot server for failover or is that an extra-charge feature? Details of what the provider guarantees, in terms of hardware, service, uptime, and response time, should be clearly stated in the SLA, along with a clear listing of what is included, what is optional, and the costs incurred by employing these optional services.
I wish I could assure you that answering these questions will guarantee a successful cloud LIMS selection and installation, but we both know that this is only the tip of the regulatory and installation iceberg. However, obtaining detailed answers to the above questions will definitely enhance the probability of success, just be certain that your final SLA is a realistic reflection of the answers you’ve received. In the end, it may be a well-written SLA that makes the difference between a successful implementation and an endless round of finger pointing and additional expenses.
1. CSols, Inc., Validation in the Cloud – Informatics Insider Blog. CSols Inc. (2015) (available at http://www.csolsinc.com/validation-in-the-cloud/).
2. B. (RAK) Duncan, in: The Seventh International Conference on Cloud Computing, GRIDs, and Virtualization, Carlos Becker Westphall, Ed. (IARIA XPS Press, Rome, Italy, 2016; http://aura.abdn.ac.uk/bitstream/handle/2164/8060/cloud_computing_2016_6_10_20060.pdf;jsessionid=947B3A916014B868CC6F884107BD-51B2?sequence=1), pp. 119–124.
3. B. (RAK) Duncan, in: The Seventh International Conference on Cloud Computing, GRIDs, and Virtualization, Carlos Becker Westphall, Ed. (IARIA XPS Press, Rome, Italy, 2016; https://www.researchgate.net/profile/Carlos_Westphall/publication/298785531_CLOUD_COMPUTING_2016_The_Seventh_International_Conference_on_Cloud_Computing_GRIDs_and_Virtualization/links/56eaeddf08aec6b500166a11.pdf#page=132), pp. 125–130.