Practical Applications of an SDMS

Shirlee Hart is an independent consultant and owner of SMHart Systems, LLC. She holds degrees in Chemistry and Information Technology, and has more than 30 years of experience in the Laboratory Informatics industry. She has worked in the Environmental and Pharmaceutical industries as well as for major LIMS vendors. Currently, she assists clients in data integrity planning and remediation, software quality oversight, vendor selection, training, and compliance.

Opinions expressed by CSols Inc. contributors are their own.

One of the biggest issues facing laboratories is what to do with all of the data that accumulates every day. Organizations are increasingly aware of the value of that untapped data. If you are considering adding a Scientific Data Management System (SDMS) to your lab informatics portfolio, you may be wondering how to explain why you need one. This blog will help you crystallize your thoughts and perhaps, justify a purchase.

There are many software systems used within a laboratory:

• A LIMS is used to manage samples, reagents, equipment, and supplies; and can perform calculations, manage workflows, enact version control, and enable reporting.
• ELNs are used to replace paper notebooks, perform calculations, and preserve intellectual property (IP).
• A CDS is used to manage chromatography runs and reporting.

So, where does an SDMS fit in?

An SDMS can be thought of as an Electronic Document Management System (EDMS) specifically designed for managing laboratory instrument data. The main purpose of both systems is to store and organize data and records. Where the EDMS contains SOPs, policies, manuals, specifications, and other controlled documents, the SDMS contains chromatograms, scans, reports, and other instrument data.

Unfortunately, instrument data are not stored in standard formats; many are proprietary to the specific vendor or instrument. This means that the originating software must be used to read the data. And although you can generate a report from the instrument, it is only a subset of the data collected. The metadata still resides within the instrument software.

An SDMS can solve some data management problems and provide additional functionality to users in a lab. The following are some typical features available in an SDMS (Note: not every system contains every feature):

• Data extraction: manages raw data files, databases, or reports and transfers data to another system (e.g., LIMS, data warehouse) or report.
• Support for multiple file types: allows for storage and retrieval of proprietary file types often found in instrument systems.
• Data archiving: stores data securely and can remove data from an instrument automatically.
• Part 11 compliance: provides secure data storage, version control, audit trail functionality, and electronic signatures.
• Searching: enables complex searching based on key tags, metadata or data fields.
• Workflows: automates processes, and/or enables rule-based (if-then) decisions
• Data analysis tools: allows searching and analysis of data from multiple sources.
• Alarms and notifications: configures rules for critical notifications and alarms.

Additional Reading: The Value of a Scientific Data Management System

Examples of SDMS Applications

There are many uses for an SDMS; some obvious, some that many labs don’t even consider. Below are some ways in which you can use an SDMS for your lab data management.

Plate Reader

When users need to manage access to data from a plate reader, they face several difficulties. A plate reader might require users to have administrator rights to run the software and generate data. The data storage location is not in a secure database (either locally or on the network) and must allow users the ability to modify the files during the run. Users can then modify and/or delete the data files, which is a data integrity issue that has the potential for data falsification issues, either unintentional or purposeful.  

To address these issues, an SDMS can be configured to sweep the files as soon as they are created (plus a delay for the run time). This provides a copy of the raw data as soon as it is created. Runs in the SDMS are then reviewed against the reported runs, to verify that all runs are accounted for. While this does not remove the possibility of data manipulation, it does decrease the associated risk.

Mass Spectrometer Data Storage

A common situation with mass spectrometers is that they generate data on a local hard drive. When the hard drive is full, the instrument stops working.

An SDMS can be configured to sweep data files when they are generated or modified to make a copy in the SDMS. After confirming a copy was made to the SDMS, the SDMS can delete files from the instrument when a specified time has elapsed (e.g., six months) since the creation or last modification.

Flow Cytometer Data Integrity

A flow cytometer may have inadequate security and audit trails. For example, users may need permission to modify files and then to re-gate them during processing, but the software only allows administrators this ability. If users were granted administrator rights, that would also allow them to delete files, thereby creating inadequate security. Additionally, the instrument audit trail only tracks changes to data, not templates.

An SDMS can increase data integrity when it is configured to store and version control templates and data runs (both raw data and processed). Data review then includes comparing SDMS runs to instrument runs.

Chromatogram QA

A QA review of data requires viewing chromatograms, but licenses for the CDS usually are limited to actual users due to cost.

An SDMS can help in this situation because reports can be generated in the CDS and printed to the SDMS along with the raw data, then linked together automatically. Peer review can be performed either in the CDS or the SDMS and electronically signed. QA review of the CDS report occurs in the SDMS, where the reviewer can drill down to the raw data file if needed and display it in the SDMS. Notifications are generated when both peer review and QA review are required. Additionally, if you have multiple CDS systems, an SDMS would allow you to compare chromatograms from multiple instruments and different manufacturers.

Instrument Interfacing

For some instruments, an interface to LIMS is not available or is difficult to configure.  

To help with this, an SDMS can be configured to allow users to print the report to the SDMS, where the report is parsed and the data is automatically transferred to the LIMS. The SDMS interfaces can be standardized, making the implementation easier, but the actual interfacing may or may not be simple depending on the systems.

Is an SDMS Right for Your Lab?

Could your lab benefit from any of these features of an SDMS? Before you rush to requisition one, you should first:

• Understand your current and future software applications and data storage needs
• Assess the compliance risks and gaps
• Determine existing data accessibility gaps or pain points where an SDMS could assist
• Know what instruments you have or plan to acquire in the future

In a perfect laboratory data world, I would like to see all instrument data automatically securely stored and managed. In that perfect world, anyone (with proper credentials of course) would be able to drill down from a result (in a LIMS, ELN, etc.) to the originating instrument report (stored in the SDMS) and, if needed, to the original instrument scan (viewed in the SDMS). An example of this perfect world is shown in the image below.

---

What good or bad SDMS experiences have you had? Tell us about it in the comments.