Archive for category: Blog Archive

The Life Sciences business is an Information Business.  We sell small containers of material at a considerable price.  But without supporting information representing the product’s identity, purity and potency, we are unable to sell it.  So in essence, Information IS our Product. That’s why companies spend so much time and energy ensuring that the information is correct.  Usually, there is a document or report that attests to the authenticity of the product or service.  In the pharmaceutical industry, this document is called the Certificate of Analysis (COA). In the diagnostics industry, it’s called a Test Report (TR).  In both cases, the company must provide strong traceability from test result back through the testing process so they can prove the veracity of the results.

During system implementations, we generally recommend that final report generation be part of the initial project.  For instance, when I work with a customer on a pharmaceutical LIMS, I always steer them towards COA creation in the first version.  Once the system “owns” the results, it becomes possible to perform Statistical Process Control (SPC) on the results and catch trends early.  If the system doesn’t own the actual results, it undermines its usefulness.  A system that does not contain the results can start to atrophy because the staff goes elsewhere for answers.

The other reason we like to produce the final report is because it represents our customer’s product.  If possible, we like to provide direct access to the final report using a portal.  When we provide direct report access, customer satisfaction increases and the customer support workload goes down; freeing up staff for science.

One of my clients used to fax Test Reports to a physician’s office at the end of each business day.  This entailed printing the report to paper and feeding the fax machine for up to an hour.  Then we instituted a secure daily email that had links back to the online final reports.  Now, the physician’s office receives the email and can self-serve.  And my client’s staff can work on higher value tasks.  This would not have been possible if the system didn’t own the results.

So when you are designing your next system, don’t discount the value of final report generation.  I encourage you to include this feature in the initial version.  Because if your system can’t generate the final report, it doesn’t “own” the results.

Image courtesy of nokhoog_buchachon and freedigitalphotos.net

Human Genome Sciences (HGS), one of Maryland’s Biotech anchors, was recently purchased by Glaxo SmithKline (GSK).  HGS was purchased because of its drug pipeline but, not so long ago, it was renowned for sequencing human genes and amassing a treasure trove of Intellectual Property.  I had the great honor of being part of the HGS informatics team during that time.

In the early days, we were confronted by a torrent of gene sequences poring forth from a room full of ABI sequencers.  It was important to capture and catalog each gene sequence; making sure it was associated with the correct tissue, disease, and developmental stage.  But the sequencing instrument’s control software wasn’t designed to enforce our indexing rules.  So we had to provide that control.

This problem is not unique.  We continually encounter it when building scientific pipelines. This is because instrument builders don’t understand they are part of an informatics supply chain.  They envision white coat-clad scientists meticulously typing instructions into their instrument’s control software.  These imagined scientists wait expectantly for the output and process it manually when it arrives.  But if the instrument is part of an automated pipeline, it often lacks the necessary control features.

One of the first things we do when automating scientific processes is to establish the informatics supply chain.  As mentioned above, this often entails augmenting the participating instruments’ control software; either with technical or procedural controls.  Once established, this supply chain acts as a “conveyer belt”; ensuring high quality meta-data is delivered along with the scientific raw data and the interpreted results.  Furthermore, the supply chain must be navigable.  Scientists must be able to trace back through the process to understand the precise conditions, materials, and equipment used to generate the data.

It is surprising how many labs neglect this simple, but necessary step.  It is especially common when science is being performed at bench-top scale.  Many bench-top labs are neglected by the IT department.  They are left to fend for themselves with Excel, PowerPoint, Email, and corporate shares (and of course paper lab notebooks).  Although good practices can be established by individual scientists, they tend to be local and highly manual.  They tend to generate data that is not well suited for automated interpretation (parsing).

If you are building software solutions in the life sciences industry, or are a scientist in a bench-top lab who wants to prepare for automation, you should consider a couple of practices that can establish your informatics supply chain.

First, design a consistent coding scheme that can be used during sample and reagent accessioning.  The coding scheme may contain embedded information or it may just be an anonymous number.  Just make it consistent and unique.

Second, be disciplined about using this coding scheme when loading the instrument.  The identifiers you load into the instrument’s control software will be embedded into the output files.  So using the agreed upon coding scheme will greatly enhance traceability.  If possible, avoid manually typing the identifiers because it’s inevitable that people will transpose and substitute digits.  Instead, try to programmatically insert a “sample manifest” into the instrument’s control software.  This can be accomplished by most commercial LIMS systems.  But a point solution can perform this function as well.

By taking these steps, you can increase the fidelity of your scientific data and provide context for interpretation.  And when the “Mother of All Informatics Systems” arrives, your data will be able to snap-in to the framework with ease.

When I examine laboratory processes, I always look for a way to tie information together in a seamless, navigable way.  If, at some point, we get to work together, I’m probably going to ask you …  “Where is your lab’s informatics supply chain?”

Image courtesy of Victor Habbic and freedigitalphotos.net

You can’t work in a modern corporation without being exposed to the two prevailing process improvement methodologies; Six Sigma and Lean Manufacturing. Six Sigma focuses on reducing variability in an effort to produce consistent outcomes, (i.e. uniform widgets). Lean Manufacturing aims to reduce waste; thereby increasing productivity and throughput.

Although not formally trained in either methodology, I’ve been in and around companies with active programs in both and have witnessed their impact. So I was surprised to find a different, unknown process improvement technique; The Theory of Constraints. At least it was unknown to me.

The Theory of Constraints (TOC) was first put forth by Eliyahu Goldratt in his book, The Goal. It recognizes that in any process, there is a constraining activity. The activity with a growing backlog is the likely culprit. TOC asks you to think of the end-to-end process like a chain. And the weakest link in that chain determines the overall process throughput. By concentrating on improving the capacity of the constraining activity (or weakest link), the system’s overall throughput can be increased.

This approach seems intuitively satisfying. And I’ve been wondering why it didn’t make the leap to the corporate world. In an article entitled How to Compare Six Sigma, Lean, and the Theory of Constraints”by Dave Nave from 2002 , the author puts forth some organizational differences that may be able to explain why. In essence, Mr. Nave explains that TOC is favored by traditional hierarchical organizations that have a clear delineation between workers and management. TOC is driven by management without much input or influence from the workers. I can imagine that this didn’t appeal to modern, progressive organizations that are trying to flatten their org charts.

The aspect of TOC that appeals to me however, is how the process is viewed as a whole. I liken TOC to the work a metropolitan traffic planner might undertake by flying over the city in a helicopter. She may observe various bottlenecks and choke points during rush hour and direct the road crews to tune traffic light patterns or (in some cases) add new lanes. Over time, she could see the impact of these adjustments and observe the bottlenecks moving to new locations or dissipating altogether.

In contrast, I’ve observed many Lean activities that are narrowly focused. They may improve efficiency locally, without fully considering the overall organization. That’s like adding lanes to a highway without reducing overall commute time.

TOC is an interesting way to think about process improvement and it deserves to be considered along with Lean and Six Sigma. So I’m going to add TOC to my professional toolkit. How about you?

Image courtesy of ShutterStock.com