Ezekial Emanuel offered a hopeful story in The New York Times, 6 May 2015: How to Solve the E.R. Problem.

He described the effort of Group Health Cooperative of Puget Sound, working with the SEIU Healthcare NW Health Benefits Trust, to reduce emergency room use of a target population by 27% over four years.

This is an important accomplishment because recent experience suggests that broadening health insurance coverage actually increases expensive emergency room use in the absence of other interventions.   There appears to be increased emergency room visits by people now covered under the Affordable Care Act, contrary to expectations stated by some, including President Obama.

For example, Emanuel summarized what happened after Oregon expanded Medicaid coverage in 2008. Per person emergency room visits for the newly insured increased by 40%:  “This was most likely because previously uninsured individuals could now go to emergency rooms without owing a co-pay.”

Emanuel then describes the strategy adopted by GHC and SEIU that combined incentives, an increase in co-pay for E.R. visits, education about the difference between urgent care and emergency room care, and information about how to use the GHC urgent care system.

Emanuel then concludes the story: “The good news is that this strategy is not neurosurgery. It is a relatively simple set of interventions that could easily spread to almost every other employer and insurer.   This is how we’ll finally deliver on the president’s promise—and save us all billions of dollars.”

There’s good reason to believe that copying the four components of the GHC-SEIU strategy won’t yield the potential billions—a consequence of Peter Rossi’s Iron Law of Evaluation:

I learned about Rossi’s Law from my colleague Gareth Parry, Ph.D., senior scientist at the IHI, who is an expert in what works to spread programs and what doesn’t—the Rossi slide is from one of Gareth’s presentations.

Furthermore, Gareth has outlined a mechanism that explains  Rossi’s Law. Take a look at the video clip that mashes together a few more of Gareth’s slides: 


(Slides appear in  “Recommendations for Evaluation of Health Care Improvement Initiatives”, Gareth J. Parry, PhD; Andrew Carson-Stevens, MBBCh, MPhil; Donna F. Luff, PhD; Marianne E. McPherson, PhD, MS; Donald A. Goldmann, MD, ACADEMIC PEDIATRICS 2013;13:S23–S30)

As Gareth points out on the last slide, we have a way out of the trap of the Iron Law, if we can learn to amend protocols to fit the circumstances of specific organizations, communities, and conditions.

Employers and insurers who are inspired by the GHC-SEIU example will need to adapt the original four components to local conditions to escape the consequences of the Iron Law.   The best way we know to adapt a protocol is to run tests, rapidly and efficiently.   So, I’d amend Emanuel’s suggestion:  Almost every employer and insurer should test and adapt the simple set of interventions, sharing lessons and challenges along the way.

(For more on Rossi’s Law, see recent Health Affairs blog by Gareth and colleagues).


Several posts ago (Deming's chain reaction), I cited Tim Fuller’s 1985 article, “Eliminating Complexity from Work:  Improving Productivity by Enhancing Quality” (National Productivity Review, 4, 327-344, Autumn 1985 issue), available at your local research library or on-line here, if you pay John Wiley a fee.

In this paper, Tim described his seminal experiences working for Hewlett-Packard in the early 1980’s, applying improvement principles outlined by W. Edwards Deming and coached by an early Deming acolyte, Dr. Perry Gluckman. From direct observation, Tim concluded that most people spent most of their time in unproductive work in both electronic assembly and office operations.

Tim offered a quick test to determine where one would find opportunity to improve operations:  “The more complexity in an area, the more quickly and easily significant improvements can be made.”

Tim continues: “Often, one can make a rough estimate of the level of complexity in an operation by just walking around the work area and making visual observations of certain conditions.”

Good advice, go see!   

But you have to know what to look for, to be an educated observer, not just a tourist passing through an exotic destination.

Tim guides you on what to look for in the workplace; it's worth quoting the article at length on this point:

"Seven conditions indicating a high level of complexity, and seven corresponding conditions indicating a low level, are listed below:

Indicators of high complexity:

1. Lots of work-in process materials. Many shelves in the work area to hold material.
2. Many people walking from place to place, standing in a line waiting for something, standing idle.
3. Work areas that are in disarray. Dusty boxes on the floors, bookcases full of dusty binders, and desks and walls covered with little scraps of paper serving as reminder notes.
4. People who can give only a brief, vague explanation of what they are working on and why it is important.
5. Humorous signs taped to the walls that say things like, “You want it when? Ha! Ha!” or “A clean desk is a sign of a sick mind.”
6. In office areas, piles of processed and unprocessed documents stored in the work area.
7. Supervisors and managers pacing around the area trying to find out what’s going on, ascertain who made a critical mistake, and expedite late orders.

Indicators of low complexity:

1. A small amount of work-in-process material. Few shelves in the work area to hold material.
2. Few people walking around carrying materials. Most people working at a steady, relaxed pace. No one waiting in line at copy machines, office supplies, stores.
3. Work areas that are neat. Everything in a department has a place and a use. People using time management systems instead of scraps of paper. Desk tops containing only what the person is working on at the time.
4. People on the production floor or in an office area who can give complete descriptions of what they do, why they do it, who their customers are, and what’s important to those customers.
5. The most common item displayed on department walls are monthly performance graphics, daily control charts of defects, Pareto charts of defects and problems.
6. In office areas all documents are received, processed, and filed. In baskets are clean.
7. Supervisors and managers who are relaxed, walking around the area talking with employees, asking them what they are working on, and looking for ways to make their employees’ jobs easier and more satisfying.”

Anyone who has tried to improve organization performance will find nothing new or surprising in Tim’s guidelines.  Students of the Toyota Production System will naturally substitute “waste” for “complexity”.   

Nevertheless, Tim’s descriptions of a low complexity operation are simple to understand and in common English, if you allow for the modest technical references to control and Pareto charts. 

 Try  Tim's indicators along with your favorite waste checklist the next time you observe a workplace.

Historical note: While Shigeo Shingo’s study of the Toyota Production System first appeared in English in 1981 (subsequently re-ranslated in 1989) few people in the U.S. had much knowledge or appreciation for the Toyota Production System at the time Tim conducted his studies. Toyota and GM did not open their joint-venture assembly plant in Fremont, California until 1984.


In my work with The Conversation Project, I’ve developed a Shiny application that uses R code to query Google Analytics information about TCP’s website.   The Shiny app extends the simple graphs and table summary available on the Google Analytics dashboard.


The app checks for daily visitors and the number of downloads of The Conversation Project “Starter Kit.” The app displays run charts of counts of visitors, counts of downloads, and downloads as a percent of visitors. (A run chart is a time-ordered plot with a reference median often used in quality improvement projects.)

We’re starting to test changes to the website, aimed at helping us communicate more effectively with the public. Thus, I’ve added a simple annotation function to allow my TCP colleagues to describe tests and special events, which will show up on the run charts.  We started our first formal test last Thursday, though the annotation feature is also useful to flag special events, like the feature of the project on the PBS Newshour show on 28 March that led to a spike in visitors and downloads.




I’ve put the scripts for the app in a public GitHub repository for reference.  I did NOT include the Google Analytics token file, which is required to connect the app to Google Analytics.

If you are interested in the steps to connect your R code to Google Analytics, the article by Kushin Shah from 11 May 2014 is a good place to start.



Back to top