The Skinny on QC Are Laboratory Quality Requirements "Lean"?
In light of the publication of the fifth edition of the Ricos et al biologic variation database, Sten Westgard contemplates another question: what's the quality of quality requirements? In the parlance of the latest management trend, are quality requirements "Lean"?
- A Lean perspective on QC and Quality Requirements
- Requirements: Pushing or Pulling Quality?
- Moving from Push to Pull: A Heirarchy of Quality Requirements
- Is QC Lean is QC "fat"?
- Conclusion (Yes, Virginia, there are Lean Quality Requirements)
On the occasion of the online publication of the fifth edition of the Ricos et al. Biologic Variation database, I believe it’s appropriate to discuss the value and the importance of what Dr. Carmen Ricos and her colleagues have done.
The Ricos et al. Biologic Variation database is now over 300 analytes, with more than 200 references. This fifth edition demonstrates that the database in not static, but continues to grow and evolve with the laboratory testing environment. It represents the best, most comprehensive source of information on biologic variation and, by derivation, quality requirements for analytical testing.
Meanwhile, here in the US, we are still governed by CLIA and those mandated quality requirements. The CLIA proficiency testing criteria, issued back in 1988, covers around 88 different analytes. These numbers have not changed at all since they were first issued, nor has CDC/CMS added any new analytes or quality specifications to the list. Indeed, lately CMS has expressed the desire to get out of the quality requirement business altogether.
A Lean perspective on QC and Quality Requirements
One of the hottest trends (or derisively, fads) in quality management is Lean, also known as Toyota Production methods.
There’s an entire industry of Lean consultants, tools, training schools, etc. We won’t attempt to address every aspect of Lean – but we will use the simple definition derived from the National Institute of Standards and Technology Manufacturing Extension Partnership (NIST/MEP) to describe the central concept:
“[L]ean is a systematic approach to identifying and eliminating waste (non-value-added activities) through continuous improvement by flowing the service or product when the patient needs it (called “pull”) in pursuit of perfection.”
Another way to summarize Lean Healthcare is that it seeks to give patients:
- What they want
- When they want it
- Where they want it
- At a competitive price
- In the quantities and varieties they want
- Always of expected quality [ed. emphasis added]
In the laboratory, Lean is a quality management approach which is usually implemented to rapidly and dramatically restructures the physical layout and staffing arrangements. Often, Lean projects involve counting footsteps, rearranging work-cells, eliminating drawers and storage closets, cross-training staff, making everything visually simple, all of this with the goal of eliminating unnecessary effort while maximizing output and “flow.”
At Westgard QC, we have not commented much about Lean (although we have discussed it here and in our Six Sigma book), mainly because Lean hasn’t said very much about quality control. Anecdotally, we have heard about Lean projects where the QC frequency was increased because management wanted to make sure they wanted immediate notification when the testing process was out-of-control (rather than wait for the end of a shift, or the end of 24 hours, a week, or a month). On the other hand, we have heard of a situation where QC was so neglected in a Lean project that unqualified hourly workers were doing the QC and test results got reported that shouldn’t have been. Most Lean projects in the literature focus on reduced TAT, reduced inventories, and reduced staffing. It’s so rare to see a Lean project that discusses analytical performance that I haven’t come across one yet.
There are two fundamental aspects of Lean management that impact how that school of thought views quality requirements. The first is a question of “Push” versus “Pull” – how the quality requirement is generated. The second question concerns the nature of a quality requirement from a Lean perspective: If you have Lean eyes, do you see quality requirements as waste or value-added?
Requirements: Pushing or Pulling Quality?
At the heart of Lean is the imperative that products and services shouldn’t be pushed at a customer, rather they should be pulled by the customer:
“A pull system is one in which patients (customers) pull value (toward themselves) from preceding upstream activities. So, if the patients need a major activity performed on themselves, that need would automatically pull all required resources and value directly to the patients. The patients should quickly draw all needed services as they move through their treatment experience. A pull system will provide patients with what they want, when they want it, and in the amount they want.”
“Pull” as defined in the Lean lexicon, is what happens when the customer gets to define exactly the product or service that he or she needs, and gets that product or service exactly when he or she needs it. There is no stockpiling, no queues, no wasted effort, because the demand for the product is immediately fulfilled by the producer. The producer delivers the product just-in-time to the customer. In many ways, laboratory testing is a perfect pull scenario, since by definition you can only test the patient’s sample (you can’t stockpile test results, or give uniform test results to all people). Where laboratory testing diverts from Lean is in the handling, processing, and reporting of results.
On the other hand, “Push” in the Lean lexicon, means the producer defines the product or service (often incorrectly), then pushes it out to the customer. Usually, this means too many or too few products or services are produced, with the wrong features, at the wrong time. Stockpiles accumulate as products wait for customers who want them to materialize.
Quality Requirements, on first blush, seem to be a lot like “Push.” I doubt in the history of medical care there is an example where a patient asked for a lab test where the result “is within an allowable error of plus or minus ten percent.” Indeed, today you may even be hard-pressed to find a physician who expresses a quantifiable demand for the quality of the testing. Both patient and physician assume that the testing results are “always of the expected quality,” even if they don’t or can’t articulate what that quality is. But the norm is that the quality requirements for tests are not “pulled.” Instead, CLIA pushes its proficiency testing criteria onto laboratories; inspectors, regulators and accreditors push their quality control rules onto laboratories seemingly with no concern for the end users; experts harangue the laboratory professional about what they should be doing (that’s where we come in); and manufacturers push their methods onto the market with precision and accuracy performance that is “state of the art” but rarely what is needed or what customers need.
If most of the quality requirements are being pushed on laboratories, does that mean a Lean lab shouldn’t use them? How can a Lean Lab “pull” quality specifications?
Moving From Push to Pull: A Hierarchy of Quality Requirements
One resolution to the push-pull over quality requirements is to acknowledge that not all quality requirements are created equal – that some quality requirements are better than others.
What is the continuum of quality requirements? It’s a hierarchy created in 1999, at the Strategies to Set Global Specifications in Laboratory Medicine Conference in Stockholm, Sweden. That meeting involved over 100 participants from 27 countries and included sponsorship from IFCC, IUPAC and WHO. The Consensus statement established this ranking of quality requirements:
Good or Bad? Push or Pull Heirachy level Example BEST PULL I. Evaluation of the effect of analytical performance on clinical outcomes in specific clinical settings Clinical outcome studies II. Evaluation of the effect of analytical performance on clinical decisions in general:
A. data based on components of biological variation
B. data based on analysis of clinicians' opinions
Ricos et al biologic variation database
III. Published professional recommendations
A. from national and international expert bodies
B. from expert local groups or individuals
Desirable Laboratory Precision from Six Sigma Management
IV. Performance goals set by
A. regulatory bodies
B. organisers of External Quality Assessment (EQA) schemes
CLIA PT criteria WORST PUSH
V. Goals based on the current state of the art
A. as demonstrated by data from EQA or Proficiency Testing schemes
B. as found in current publications on methodology.
As you can see, the hierarchy neatly fits into the spectrum between push and pull. Push-type quality requirements, as imposed by EQA programs and regulators, are near the bottom of the hierarchy. Meanwhile, Pull-type quality requirements, such as clinical outcome studies, and biologic variation studies, are near the top of the hierarchy.
Is QC? Is QC “fat”?
On a more abstract level, Lean introduces is a philosophical debate over the value of quality requirements. Is QC itself “Lean”?
As one Lean consultant told me, the Lean philosophy generally characterizes quality control as muda, or waste. From a Lean perspective, processes shouldn’t be “controlled”; they should be mistake-proofed (poka yoke), or made perfect so that they don’t need to be controlled.
Another, similarly dogmatic perspective on quality requirements is that they shouldn’t exist because the existence of quality requirements implicitly allows quality to be less than perfect. That is, if we specify tolerance limits, we therefore tolerate variation. This proves to be particularly wasteful when the tolerance limits are chosen arbitrarily. If, on the other hand, we want nothing but perfection, we should eliminate tolerance limits. It’s a neat rhetorical sleight of hand, attempting to erase the reality of variation by eliminating the terminology that describes it. Unfortunately, eliminating tolerance limits won’t make variation go away.
Nevertheless, we believe quality control and quality requirements serve a useful purpose. If nothing else, they serve as a safety check, in the same way that seat belts and smoke detectors serve as safety devices. Certainly it would be better for highway safety if manufacturers designed a car that didn’t crash, but the cost of that vehicle would probably be prohibitive (and it would probably look and behave like a tank). Designing buildings that couldn’t burn would also be attractive and eliminate the need for smoke detectors, but again, that’s probably unlikely in our time. In our less than perfect world, we need seat belts and smoke detectors, and yes, we need quality control and quality requirements. Those quality requirements are best when they are pulled from the customer/patient, as characterized by the Stockholm heirarchy.
Conclusion (Yes, Virginia, there are Lean Quality Requirements)
In light of this Lean perspective and the Stockholm hierarchy, the publication of Dr. Ricos et al. fifth edition of biologic variation is even more important. Since the quality specifications produced by her and her colleagues’ work are of such high quality (and may be considered “Leaner” than other specifications), they are doubly important to the field.
We should all be deeply thankful for their work, dedication, and persistence.