Flat light is a killer.

We’re speaking in the context of the menacing effect occurring when mountains occlude the sun from the ski slopes, or overcast skies homogenize the light in such a way as to wash out any contrast between bumps, texture, or pitch of the run.

Snowboarding with my sons over the holiday break, I came flying down a fairly steep run at about forty mph, and the combination of flat light, dark purple lenses in my goggles, and a chunk of ice, caused me to launch into the air, and as my ten-year-old described it: “your head kept bouncing on the ice as you rolled over and over.”

The human brain is geared to wipe out such events. I not only have no recollection of the crash (my son had to tell me of the chunk of ice), but also no memory of completing the run down to the lift, riding the lift up, having some spiced cider, and sitting in the lodge for an hour before my discombobulation ceased, and I was able to board back down to the car.

I was wearing a helmet, and the buckle of my ski goggles carved a trench into the side of the helmet as an indication of the force of the crash. Had I not had a helmet, my days as the Hice household Jeopardy champion would have been at risk.

Helmets are critical saftey devices, although some people still ignore them.

There is an analogy here in the approach the FDA takes towards drug and food safety in terms of process and computer systems validation. Any company who has spent a lot of time and money on the development of a consistent, defensible, validation approach; or has been on the receiving end of an extensive FDA audit, knows how much work is involved. But there is a method to the FDA’s madness. The FDA wants proof that all systems are in control.

Where life gets interesting for the scientific enterprise is when companies establish a corporate informatics approach, and the holistic informatics environment amalgamates several distinct software applications. A common challenge is when companies try to expand the enterprise environment to include applications that traditionally have not been included in the validated part of the environment.

As an example, FDA-regulated companies utilizing LIMS to make product quality decisions always (er, usually) undertake a rigorous validation approach while developing a LIMS and moving it into a production environment. But those same companies may have chosen to include a Clinical LIS as a discrete component of their holistic informatics architecture. I guess at this point, since there is no etched-in-stone definition of a clinical LIS, we probably should establish a frame of reference to understand the difference between a “conventional” LIMS with clinical functionality, and a standalone clinical LIS.

STARLIMS is a robust enterprise informatics engine that is capable of addressing all corners of the scientific enterprise with one application. So, in addition to what used to be considered “mainstream” LIMS territory, STARLIMS provides advanced state-of-the-art SDMS and ELN functionality; this in addition to STARLIMS’s comprehensive clinical functionality.

In contrast, most “clinical LIS” evolved from systems deployed in clinics or hospital labs. They were very good for what they were designed for: localized clinical testing and result entry. But when these clinical LIS applications are asked to perform at the enterprise level, say in the world of a Contract Research Organization (CRO), or the early and late-stage development cycles in a pharmaceutical or biotechnology company, it often became a stretch to expect these systems to be able to handle diverse sample or specimen volumes with disparate workflows, remote data entry, and sharing results/reports across a geographically-diverse or global enterprise.

Turning back to the validation issue, and specifically 21 CFR 11, and now recalling what we know about the small clinic/hospital lab origins of clinical LIS applications; should it come as a surprise that 21 CFR 11 requirements, such as support for FDA compliant validation and electronic signature capabilities are not present? While some LIS applications maintain basic audit trail functionality to meet CAP/CLIA compliance guidelines, this functionality typically wouldn’t be as robust as that in a mainstream LIMS.

This is not to imply negligence on the behalf of the clinical LIS suppliers, rather, it is an artifact of the world they originally served. Hospital and small clinical laboratories do not normally fall under the auspices of the FDA. I once attended a product demo by a well-known clinical LIS vendor, and when the customer asked if they supported electronic signatures, the vendor said, “Yes, ofcourse. You can scan in a picture of your signature and include it in report documents.”

Those of us dealing with the FDA, and 21 CFR 11 understand that scanned signatures and electronic signatures are worlds apart.

So, we return to the scientific enterprise where a unified informatics platform is desired, and, whether or not the “clinical portion” of their system falls under 21 CFR 11, most enterprise compliance organizations promote adherence to those guidelines just as a matter of good software practices. In this scenario, STARLIMS is ideal because all of the constructs of the system support 21 CFR 11, and the level of data quality in the “mainstream LIMS” functionality is mirrored in all aspects of STARLIMS, including all of the clinical functionality. If the clinical operation falls under the auspices of 21 CFR 11, well, all the better as the tools are there to allow a customer to implement their FDA compliance policies.

There is an old saying: “don’t take a knife to a gunfight.” In this case, as the scientific enterprise requires a unified informatics platform, they also require all elements of that platform to support FDA quality standards, and that can’t be accomplished when apples and oranges are mixed.