Scientific Data Management System (SDMS) was first introduced as a system used primarily for data archival and retrieval. And certainly, the importance of data archiving cannot be understated in QC and the R&D domain, as regulations require that pharma companies keep quality and data discovery data around for a number of years – which is sometimes not feasible with an active/live system.  

Furthermore, larger organizations typically have quite large requirements for data silos, so investing in SDMS can provide them with a lot of bang for their buck, whereas smaller organizations refrain from this investment due to their comparatively smaller budget and/or data silos sizes.  

In recent years, however, SDMS has grown in terms of what it can bring to the table for the QC and R&D divisions, providing much more than just data archival and retrieval systems, including a heterogenous data reservoir, an instrument integrator, and a meta-data information processor.  

Leaner LIMS 

It’s imperative that you look at your current QC systems inventory and identify the challenges and opportunities your QC group faces today. Instead of simply looking for the next “cool” system for your IT inventory, try to identify and compartmentalize the various functional units of QC and then determine what the best-suited application for your company would be. If you’re in the market for a solution that can make your organization less dependent on any one system, allow you to host data in the system where it belongs, and leverage some of the newest technologies, then SDMS could be the right choice for your quality system inventory.  

Considering SDMS

You may have heard the saying, “planning may not guarantee success, but not planning almost guarantees failure.” If your organization is considering SDMS, here are key considerations to keep in mind during deployment:

Cloud-based implementation. Today, organizations are looking for more and more cloud-based solutions. It not only allows the organization to leverage their third-party expertise to manage the infrastructural needs, but it also frees up internal resources to focus on leveraging and building expertise around the usage of the applications. You would want to confirm that the application and/or vendor you are opting for does, inf act, support cloud-based solutions. 

SaaS-based solution. Based on the size of your organization and your willingness to take the onus to support and manage the application, you may want to look for a Software as a Service (Saas) solution. This option frees you from the responsibility of maintaining the compliance state of the application, which as we know in the QC vertical is imperative – and not to mention, expensive. If you’re walking this direction, you may also want to keep the following in mind when considering a vendor: 

• What services are available from the vendors?   
• When and how often are the application upgrades are available? 
• When you encounter an issue, what course of actions are needed?  
• Are there any responsibilities that you would have to fulfill when the application upgrades? 
• Should we experience downtime? 
• Is the setup dedicated to us or shared by other clients as well? 
• How would I export data to share with other applications? 
• How does licensing work, and are service fees applicable? 
• In future if I decide to move away from SaaS model, is that a possibility, and what are the steps involved? 

Planning to Deploy SDMS

One of the benefits of SaaS model is to pay based on the services, since the deployment is never going to be a big bang and services are deployed incrementally over a period of time. 

Dual Networks. In today’s world, it’s not uncommon for organizations to hide their sensitive application(s) and/or verticals like QC domain behind separate network layers. At times, this poses a challenge for the externally hosted application to provide access to double layers. Imagine that your instruments and/or applications are behind the second network layer, and this new cloud-based application may require access to these instruments and applications via some additional level of access through the second layer. This type of access is not uncommon but at the same time requires additional time, resources, and efforts, as the second layer is imposed for a reason, and any haste may lead to negating the affect and importance of this second layer.  

Infrastructure Layers. Recently, while working with a client, the application vendor we chose was not supporting the server configurations/environments (The client was all Windows-based shop, but the vendor insisted that certain aspects of the application be the LINUX setup). This was identified early in the game, however, and some adjustments were made at both ends to accommodate the application. It’s imperative to discuss the infrastructure limitation you have upfront to make sure that if you’re providing the infrastructure using your own providers (e.g., you already have a cloud service provider that your organization partners with), you want to make sure that application infrastructural requirements can be fulfilled by your partner. 

Going Forward with SDMS

With the introduction of a system like Scientific Data Management System (SDMS), LIMS can be made a lot leaner, using it to keep record for your final QC result data for key decision-making and instead hosting your supporting data in systems like SDMS. Our team of LIMS consultants at Clarkston leverages their distinguished industry expertise to enable solutions tailored to meet the unique needs of your business and your long-term objectives.

Contributions by Vishal Sehgal