Hospital Kaizen

IT Systems vs. Busines Systems

2011-12-21T17:15:00.001-06:00

I was watching a lecture on the subject of information management/information technology/etc., and the lecturer began discussing systems thinking, a favorite subject of mine. I was expecting a Senge-like discussion, and maybe an explanation of how information technology plays a role in a modern business system. But the lecturer had a different viewpoint. I think he saw IT systems and business systems as being synonymous. In other words, the professor's view seemed to be:

Business System = IT System

This equation implies an IT-centric approach to business with which I disagree. I see IT systems as only one part of a larger business system. My equation is more like:

Business System = People + Processes + Management + Technology + Lots of Other Inputs

For me, IT systems are just one type of technology, which is just one type of input into a business system. Sure, for e-commerce and other Internet-based endeavors, IT systems are extremely prominent features of the business system. But even then, they're not the only features. So often in the business world it feels like this is forgotten.

I would recommend to IT professionals and others in charge of developing, managing, or improving business systems that they take a step back and see things holistically. Don't be overly focused on technology as a silver bullet, even if IT is your area of expertise. Use IT systems to support the business instead of seeing IT systems as the business.

Top 3 Things I've Learned After 18 Months in Healthcare

2011-10-28T10:49:00.000-05:00

It's been almost 18 months since I made the move to healthcare, thanks in part to the encouragement I received from my friend, Mark Graban. In that time, I've learned a lot and I continue to learn everyday. What have I learned? Here's my Top 3 list:

The healthcare business is all about people. In my article "The Human Factor in Healthcare," I discuss how important it is to be agile when it comes to how we approach improvement in healthcare because of the human factor. This is by far the most important lesson I've learned in healthcare. Our "product" is the patient, a human being. Most of our processes are highly dependent upon manual labor, which is performed by human beings. We have front-line workers (doctors and nurses) with much more education, training, and influence that the average front-line worker in a factory. In pediatrics, we have to account for the needs of not only the patient, but of the patient's family as well. In an academic healthcare setting, we have to account for the learning needs of medical students, residents, and fellows. The human element exists in every industry; it's hugely magnified in healthcare.
The healthcare business is complex. In my article "10 Complexities in Hospitals," I discuss how many different levels of complexity we encounter in healthcare. The end-user and the payer are often different entities with completely different goals. We are highly regulated by national agencies, state agencies, the Joint Commission, and other entities with differing goals. We implement technology solutions of Rube Goldberg proportions that I've come to believe nobody fully understands. We have a nearly infinite amount of data at our disposal, of which only a fraction is actually timely, relevant, and easy to use. Healthcare reform is creating huge paradigm shifts (pardon the business cliche) in every healthcare organization in the land. Changing priorities are the norm, and it makes things really complex.
The healthcare business can be wonderful. Many of the people I've met in healthcare have been passionate, committed, highly-intelligent, experienced, interested in learning, focused on serving the needs of the patient, and highly competent. Not everybody, but a high percentage. That makes for a wonderful workplace. Plus, it's just easier to get up in the morning when you know your work might help make a sick child's life a little better, even if indirectly through process improvement or whatever.

Like I said earlier, I've learned a lot (a lot more than is shown here) and I continue to learn everyday. If you're an engineer, project manager, quality professional, operations manager, or any other type of business professional, you can make the move to healthcare. Just be ready to focus on people, deal with complexity, and be proud of your work. Most of all, be ready to continuously learn and improve.

True Value in Healthcare

2011-09-19T22:15:00.000-05:00

In the year and a half that I've been working in healthcare, I've heard some really good arguments from some really smart folks regarding what makes an activity value-added. Based on what I've heard, read, studied, and observed, the prevailing approach to defining value in healthcare is the following:

The Standard Definition of Value in Healthcare

Under this definition, for an activity to be considered value-added, it must satisfy three requirements:

The activity must be something the patient wants/needs
The activity must be done correctly
The activity must change the form/fit/function of the patient

If it does not satisfy all three of these requirements, an activity is considered non-value-added under this approach.

This is a pretty strict approach, especially considering that it does not recognize the value of activities that contribute to the correct diagnosis of illness, something which I believe is of tremendous value to the patient. Until recently, I've tended to favor a slightly more lax definition of value.

But the more and more I read about Population Health and ACO, the more and more I've begun to question the the standard definition of value in healthcare. I've started to subscribe to a more systemic and holistic definition of value, which I refer to as True Value.

My Definition of True Value in Healthcare

The following two guidelines define my current, half-baked view of "true" value in healthcare:

If an activity is related to providing care for a preventable illness, it is waste.
If an activity is related to providing care for an unpreventable illness, and satisfies the three requirements of The Standard Definition of Value in Healthcare as shown above, it is value-added

Thoughts?

FYI, I prefer comments on LinkedIn or Twitter, so I've shut off comments on this blog.

Thank you for sponsoring my Little League team. Those mesh hats were sweet.

The Human Factor in Healthcare

2011-05-17T17:27:00.000-05:00

Several times recently, I've been asked by manufacturing folks about the challenges of making the move to healthcare as a lean coach. The one challenge that I always emphasize is the human factor. The human factor exists in every industry, but it's magnified in healthcare. This is partly due to the manual nature of the work, partly due to to the fact that the product is the patient, and partly due to the unique cultural aspects of working in an organization that directly saves lives on a daily basis.

As a lean coach in healthcare, one must adjust both his expectations and tactics.

Adjust Your Expectations

Expect a lot of variation. I mean a lot of variation. Even with a calibrated, properly maintained, properly operated piece of machinery, we expect a level of variation. Now take away the calibration, maintenance, and proper operation and see how much variation you get. Now take away the machine altogether, replace it with a person, and see how much variation you get. I could go on, but I think I've made my point. Expect a lot of variation!

Adjust Your Tactics

As for our tactics, we must adjust them to take into account the human factors. We have to design around the needs of not only the patient, but also the family of the patient. We might have to make choices we don't want to make to accomodate the teaching needs of an academic hospital. We have to define value in terms of not only the patient, but also of the payer. There are so many layers of complexity that prevent us from getting to an optimal future state, but we can't let that stop us from moving towards at least a better future state. We have to adjust our tactics and be much more agile.

Experiments as Nemawashi

2011-05-11T18:33:00.002-05:00

Lean folks have heard the term nemawashi. I've heard it described as preparing the roots of a plant for transport. It's related to consensus-building, and is especially critical when we are proposing big changes to a process.

I started thinking about nemawashi last week when I was in Six Sigma training. We were learning about Design of Experiments (DOE), which is a methodical and data-driven approach to testing future-state processes, potential countermeasures, etc. Immediately, I started to compare and contrast the DOE approach to the less scientific Barn-Raising Kaizen and Quick PDCA approaches that have served me well in the past. I wondered how we were able to achieve what we did without the rigor that DOE provides. Then it dawned on me that one of the reasons for our success with these less rigorous and more action-biased approaches was that we were performing a type of nemawashi.

We have all probably seen this formula...

R = Q x A

...which of course stands for...

Results = Quality of the Countermeasure x Acceptance Level.

Whenever we test a new countermeasure, we are doing more than collecting data to check the quality of the countermeasure. We are also impacting the acceptance level for change. If done right, an experiment can help remove the fear of the unknown, send a message that change is coming, and bring out ideas that don't arise until we see a new process live in action. These are all symptoms of nemawashi being performed.

Small-Batch PDCA

2011-05-04T16:05:00.000-05:00

I'm a fan of small batches. Partially, this is explained by my appreciation of the many fine single-barrel and small-batch bourbons produced in good ol' Kentucky. But principally, my bias towards small batches is due to the positive impact that batch-size reduction has on process flow, quality, etc.

Normally, we associate batch-size reduction with process improvement. But if we take a step back and look at our process for conducting process improvement, batch-size reduction is equally as applicable. Specifically, the way we go about testing countermeasures via PDCA can be enhanced by batch-size reduction. I call this principle Small-Batch PDCA.

What is Small Batch PDCA?

When we're in the planning phase of of PDCA, we have to decide how many countermeasures we want to test during the current PDCA cycle. There's a trade-off between the number of countermeasures we test and the amount of time, effort, and resources that will be required to conduct the test. More countermeasures equals more testing complexity. In order to properly execute a complex test, we might feel the need to utilize a complex tool such as Design of Experiments (DOE). My bias is to avoid this testing complexity by testing in smaller batches when possible.

By reducing the complexity involved with carrying out a test, Small-Batch PDCA allows us to compress the lead time from idea generation to idea testing. This gives us the chance to perform more iterations of PDCA, which in turn gives us a chance to adjust our model more frequently.

Is there a downside to Small-Batch PDCA?

One of the drawbacks of Small-Batch PDCA is that we don't get to test the future-state in a holistic manner, at least not during the first few rounds of testing. This means that any data we collect early on might not show the dramatic improvement we want, and in fact, it may be impossible to detect any statistically significant changes in performance. This is a valid concern, but this drawback is partially mitigated by the fact that if we are willing to go to the gemba and observe the test with our own eyes, we don't have to rely on data as much.

Plus, there are some important things that just can't be measured, so we usually need to go to the gemba regardless. In other words, data isn't everything. Subjective feedback from those involved with the process can be extremely valuable. Insights gained from direct observation can also be extremely valuable. Small-Batch PDCA provides us with most of the feedback we need to effectively carry out process improvements, even if the data is not as perfect as we would like.

To Sample or Not to Sample

2011-05-03T08:06:00.002-05:00

Image courtesy of Stanford School of Medicine

I'm sitting in Six Sigma Black Belt training this week, learning all about two-sample t-tests, ANOVA, and other statistical analysis techniques. One thing I noticed is that these techniques are based on sampling. Basically, you collect data based on a sample, not the whole population. An example from a hospital would be randomly picking 10 patients from a census of 100 and looking at their infection rates.

Obviously, data from a sample is not as thorough as that of a population, but often it's thorough enough to be statistically reliable. The benefit of sampling, of course, is that we don't have to go through the time and expense of collecting data for the entire population. However, thanks to powerful database software available to us in healthcare and pretty much any industry nowadays, we can easily pull all the data for all the patients in our system, at virtually no marginal cost. This begs the question--why bother with sampling if we already have the population data?

I guess we wouldn't, unless there was some added value in sampling beyond the data that we gather. If we're sampling by just pulling data out of a database, then there's probably not much value beyond the data. But, if we're sampling by directly observing a process, then there's a lot of additional value: we see the process with our own eyes, we get direct feedback from those involved with the process, we often get to directly hear the voice of the customer (the patient), and we get the opportunity to collect data that we didn't even know was relevant by looking at a database.

So, basically, it's not a question of "to sample or not to sample" but "to go & see or to not go & see."

3 Quick Thoughts on Copycatting Hospitals

2011-05-01T16:45:00.000-05:00

Mark Graban over at the Lean Blog got me thinking about the pros and cons of copycatting (using what works somewhere else to fill a need of your own). I'm not talking about plagiarism, intellectual property theft, or anything like that; I'm just talking about one hospital copying the tools and techniques of another, as opposed to coming to solutions independently. Here are three quick thoughts on copycatting:

Copycatting is supported by the "no need to reinvent the wheel" principle, which is logical and intuitive, especially for hospital folks who are busy saving lives and whatnot.
However, copycatting is a barrier to creative thinking and the building of the problem-solving muscles hospital teams need to foster continuous improvement.
Copycatting precludes the emergence of innovative ideas that other hospitals have not thought of yet

One last thought...there's something about copycatting that makes me think we are sometimes too scared of failure. Maybe our risk aversion prompts us to go with what other hospitals have used, as opposed to trying something new and failing. Does this mindset stem from traditional management philosophy that encourages us to hide problems?

Shock Absorbers in an ER

2011-04-28T18:43:00.000-05:00

In an Emergency Room, it's pretty hard to control the volume and acuity of patients coming in the door. Variation is inevitable. It's like riding down an old dirt road--you have some smooth spots and some bumpy spots. That's why our cars come with shock absorbers.

What is our shock absorber in an ER?

How do we mitigate the effect of variation in patient volume and acuity? Sometimes, we take the wasteful but safe approach of over-staffing. Or, we might look at the measures of central tendency and variability in our patient volumes and acuity, and come up with a staffing model that is both statistically reliable and much less wasteful than blunt force over-staffing.

Being able to absorb the shock of uncontrollable patient volumes and acuities is especially critical if an ER is attempting to go to a cellular flow model. In this model, you might try to even out the variation by distributing patients to the multiple cells evenly. This works well as long as the cells are equipped for all patient types.

If, however, a certain type of patient can only be seen in a certain cell, and a bunch of those patients come in at the same time, then we have a big problem. In this circumstance, we need a different kind of shock absorber, perhaps flex resources (doctors, nurses, etc.) that are not assigned to a single cell, but that can flow to where they're needed. Of course, in the long-term, we should try to even out the capabilities of the cells so that this whole issue is moot.

Whether it's through blunt force over-staffing, statistically sound staffing, level loading to cells, flowing flex resources to unleveled cells, or evening out of cell capabilities, we absolutely must have a way to ride over the bumpy spots in the road. We have to have a shock absorber.

3 Lean Coaching Tactics for Project Managers

2011-04-19T12:38:00.001-05:00

I'm fortunate to be a project manager who works almost exclusively on lean/six sigma projects. I say fortunate, because it gives me the chance to be a lean coach, as well as a project manager. Of course, it's challenging to try to mix in lean coaching within a traditional project management setting.

Anybody who has sat for the PMP Exam or perused the PMBOK knows that traditional project management as a field of study is very, very light on lean/agile concepts. So, as a project manager who loves lean coaching, I get to find creative ways to sprinkle in some lean learning throughout my projects. Here are three tactics I utilize:

Genchi Genbutsu...In traditional project management, we might be tempted to accept whatever project assumptions are indicated on the project charter. But as a lean coach, we should encourage our project team to go to the gemba and see for ourselves. We don't rely on data either; we prefer facts, observed with our own eyes when possible.
Small-Batch PDCA...In traditional project management utilizing the 'waterfall' approach, we might be tempted to get a big batch of project planning done, then move into the project execution phase and execute a big batch of deliverables. But as a lean coach, we should encourage our project team to instead perform many turns of the PDCA wheel, constantly testing, constantly iterating, in small batches of planning and execution. This has all sorts of benefits, one of the biggest being we get a chance to uncover flaws in our plan much quicker than with 'waterfall.'
Visual Collaboration...In traditional project management, we might be tempted to conduct meetings the old-fashioned way, relying mostly on verbal discussion and taking notes down on paper. But as a lean coach, we should encourage our project team to utilize visual collaboration techniques. Use whiteboards, sticky notes, flip charts, etc. to visualize topics of discussion. Once we visualize the discussion, we can structure it into affinity diagrams, fishbone diagrams, or whatever structure makes sense. You can't do that if the discussion vanishes into thin air or is only captured on our individual note pads.

Utilizing these tactics and several others, we are able to sprinkle in a little lean into all of our projects. This will not only help us project managers on our projects, but it will also help our project team members in their day-to-day.

When the Gemba is an ER

2011-04-15T13:09:00.002-05:00

As any student of Toyota knows, going to the gemba is step one when investigating a problem. This principle is often referred to as genchi genbutsu, and lean thinkers know why it's such a powerful and almost mandatory concept.

But what about when the gemba is an Emergency Room?

My first thought is that all workplaces are different, but what we're looking for pretty much stays the same. In other words, a gemba is a gemba. But, having spent enough time in ER's recently, I think there are a few differentiators that we can take into account:

The doctors are the touch labor. Whereas in manufacturing, we sometimes see the problem of the touch labor employees not being respected and their voices not being heard, we sometimes have the opposite problem in healthcare. Doctors are so well-respected, and sometimes so feared, that they can have an almost unwieldy amount of influence.
Everybody is at a computer. No, they're not playing solitaire or checking Facebook. They're working extremely hard to enter their patient encounter information into the system. In modern healthcare, it feels like everything is dependent upon electronic information management.
Flow is hard to see. Many ER's were not designed with one-piece flow in mind. Or cellular flow. Or pull systems. Or level loading. Or visual management. Or any of the other concepts that help improve flow and make flow visible. The structural design of many ER's can make it almost impossible to see the flow of patients through the system.

If you're a lean thinker looking to make the move to healthcare, these are just a couple of thoughts to keep in mind. But, if you're a lean thinker, you've probably been to many gembas and you probably know that each one has their own set of differentiators. An ER is still a gemba, just one that maybe requires a little extra patience and finesse.

3 Thoughts on Doctor/Nurse Teamwork

2011-04-11T17:53:00.003-05:00

Photo courtesy of iStockphoto

Just three random thoughts on doctor/nurse teamwork:

If the doctor and nurse sit near each other, in the same area where the patients are roomed, communication is infinitely better. We so often rely on technology to communicate with each other, when quick, natural face-to-face discussions are more effective.
If the doctor and nurse see the patient together, there is more opportunity for shared understanding, and potentially, even collaborative diagnosis and plan-of-care development...that is, if the culture in your hospital allows for that sort of thing.
If the doctor and nurse work side-by-side in similar attire, there is increased potential for confusion from patients on who is the doctor and who is the nurse. Somewhat silly, but not a trivial point.

Your thoughts?

10 Complexities in Hospitals

2011-04-06T08:49:00.002-05:00

Having worked in a hospital as a Lean Coach for about a year now, I've grown accustomed to dealing with a wide range of complexity related to healthcare, and hospitals in particular. Here's a list of some of the types of complexity I've seen in the hospital (it's not an exhaustive list by any means, and is in no particular order)...

We often have no ability to control/level the volume going into the system, especially in an ER setting
We have seasonal, weekly, and daily volume fluctuations
We often have a wide range of acuity levels, which are high-mix, low-volume in nature
Clinical workflows are often controlled by complex computer systems, which makes some processes more inflexible that we'd prefer
The most highly-trained and often most powerful people in a hospital are the physicians, who are also the "touch labor" for our front-line processes
We have 24/7/365 business hours, making cross-shift collaboration a challenge sometimes
In pediatric hospitals, we have to design processes that accommodate the needs of both the patient and their family
In academic hospitals, we often have to design processes with educational needs in mind
The customer and the payer (insurance companies, Medicare, etc.) are often not the same entity
In places like Texas, we have huge language barriers that our processes have to accomodate

Every industry has its own sources of complexity. Healthcare, and hospitals in particular, bring special types of complexity that are pretty challenging. I personally love the challenge, but I also realize that I have a long way to go if I want to be a Lean Coach who is capable of overcoming the complexity found in hospital systems.

DMAIC, the Power Drill

2011-04-04T18:51:00.001-05:00

In previous posts, I wrote about the virtues of "Quick PDCA" and "Barn-Raising Kaizen." It's obvious I favor approaches that have a bias for action. But does that mean I'm averse to more methodical approaches such as the DMAIC approach as practiced by Six Sigma Black Belts? Absolutely not.

As I mentioned in the "Barn-Raising Kaizen" article:

"Some repairs call for a hammer, and others call for a power drill. It depends on the problem we're trying to solve, the information that is available, the stakeholders involved, and a whole lot more. My suggestion is that we should not lock ourselves into any one way of bringing about improvement. Use what works for whatever situation is presented."

I think DMAIC is an awesome approach in certain types of situations:

Some problems are better analyzed through data analysis and statistics, something which is at the heart of DMAIC
Some organizations require that any and all projects show a measurable and verifiable ROI...something which is embedded in the DMAIC approach
Some managers want projects in their departments to have a formal structure and mandatory gate reviews...which also is embedded in the DMAIC approach

There are many situations that call for the power drill that is DMAIC instead of the hammer that is Quick PDCA/Barn-Raising Kaizen. Of course, many situations can be handled just as well by either approach. I just think we have to pick the tool that makes the most sense for the situation.

Stay open-minded. Be flexible. See the scientific method in both the hammer and the power drill.

Barn-Raising Kaizen

2011-04-03T15:33:00.001-05:00

A good friend of mine has an approach to process improvement that he calls "Barn-Raising Kaizen." If you don't know what barn-raising is, here's a quick excerpt from Wikipedia:

"A barn raising is an event during which a community comes together to assemble a barn for one or more of its households, particularly in 18th- and 19th-century rural North America."

It's all about community, teamwork, and just getting it done. I love it.

My friend uses the barn-raising concept when facilitating improvements out on the shopfloor. He'll gather the folks together, get some ideas flowing, and then implement changes right there on the spot. Then they'll monitor the changes, check results, and make adjustments...again, right there on the spot. It all happens in this informal, team-oriented atmosphere that resembles the barn-raising events of yesteryear. No prolonged data collection, no measurement system analysis, no project charter, no gate reviews...just kaizen.

So, is "barn-raising" kaizen effective?

You certainly won't get your Six Sigma Black Belt using the barn-raising kaizen approach, but it can be incredibly effective. Because the changes are made so quickly, we get more chances to iterate...more turns of the PDCA wheel. With each iteration, we get a chance to learn what works and what doesn't. We're not at our computer using Mini-Tab to produce a control chart; we're out at the gemba looking at the gembutsu.

Also, every time we do barn-raising kaizen, we get another chance to practice problem-solving and build our kaizen muscles. Have you read Toyota Kata yet?

But, how do you know if you've improved?

The fear is that without having a data collection plan, measurement system analysis, etc., we'll be in the dark when it comes to proving whether the changes worked or not. This probably has more to do with trying to show a good ROI than it does with actually understanding how a change impacted a process. If we're out at the gemba, we can usually see the impact with our own eyes. We don't always need data, except to show ROI on paper.

Are you saying a more thorough approach, like DMAIC, is a waste of time?

Not at all. Some repairs call for a hammer, and others call for a power drill. It depends on the problem we're trying to solve, the information that is available, the stakeholders involved, and a whole lot more. My suggestion is that we should not lock ourselves into any one way of bringing about improvement. Use what works for whatever situation is presented.

On a somewhat related topic, Pete Abilla at the Shmula blog compared the PDCA and DMAIC approaches (link).

Quick PDCA

2011-04-01T20:06:00.001-05:00

Do you ever get impatient when process improvements take too long? I know I do, as do several of the stakeholders that I work with in healthcare. Why does improvement sometimes take so long? One theory is that we wait too long to initiate PDCA cycles.

The Normal, Slow Approach

On a big Black Belt-led improvement project utilizing the DMAIC approach, we don't get to testing countermeasures using PDCA until the Improve phase. On some projects, it can take quite a while to get to that point. Sometimes, it's because data is not readily available during the Measure phase. Other times, it might be that the project team is having difficulty coming to a consensus during the Analyze phase on which countermeasures to implement. Whatever the reason, there almost always comes a point when we need to display a bias for action.

The Quick PDCA Approach

In other words, sometimes we need to stop relying on data and brainstorming, and just go do an experiment. PDCA is our approach for doing these experiments. Plan the test, perform the test, check and study the results, and adjust based on what you learn. It's rigorous, scientific, and time-tested. But we can't enjoy the benefits of PDCA unless we use it. So, have a bias for action. If data is hard to come by, go to the Gemba, do a quick PDCA, and see with your own eyes what works and what doesn't. If the team can't come to a consensus on what the countermeasure should be, stop deliberating and go do a quick PDCA.

Bias for action. Experimentation. Iteration. Learning opportunities. Quick PDCA.

Top 3 Insights from Jim Womack on the Lean Blog Podcast

2011-03-26T09:04:00.000-05:00

I just listened to Jim Womack's interview on Mark Graban's Lean Blog Podcast. Really good stuff, especially the part where Mr. Womack talks about healthcare. Here are the ideas/concepts that really resonated with me...

Healthcare is not scientific. Mr. Womack says we think of the practice of medicine as a scientific endeavor, but when you go to the gemba of a healthcare organization, you often see a highly craft-oriented culture. Process variation between physicians is sometimes the norm, rather than the exception. The decision to perform a process differently is often not based on outcomes data, but rather on the way the process was taught to the physician by her mentor. Scientific, this is not.
Physicians are the front-line workers. Whereas in manufacturing the "touch labor" employee might be an entry-level blue collar worker, Mr. Womack discusses that in healthcare this role is performed by highly-trained, highly-compensated physicians. This creates all sorts of unique situations that we must be aware of when trying to promote kaizen in a hospital setting.
Nurses are the main ones thinking about process. When I came to healthcare as a newcomer less than a year ago, I was surprised that the nurses are pretty much the ones running the show, from a process perspective. As previously mentioned, the physicians are the touch labor employees. Mr. Womack indicates that his leaves the nurses as sort of the stewards of the horizontal flow of patients across our processes. Of course, nurses are also touch labor employees, so horizontal flow often gets pushed aside when the nurses have to focus on performing a touch labor task.

I highly recommend listening to the interview with Jim Womack. He talks a lot about his new book, his approach to walking the gemba, and other insightful tidbits. Check it out.

Measurement System Analysis for Attribute/Discrete Data

2011-03-25T16:25:00.000-05:00

My background is mostly in Lean, so to expand my skill-set, I recently went through a really solid Lean Six Sigma training course at the UT-Arlington's Texas Manufacturing Assistance Center (TMAC). TMAC does a great job of developing your analytical skills, and this week I got to use one of my newfound skills--calculating Kappa.

What is Kappa?

It's a score that tells us how reliable our data collection system is when the data being collected is attribute/discrete data like pass/fail, good/bad, etc. Basically, we take two scorers (the folks who decide if something should be recorded as 'pass' or 'fail') and we have them score a sample of products twice. We want a minimum sample size of 40, with about half being good products and half being defective products. Once the samples are scored twice by each scorer, we then plug the results into a spreadsheet and do some calculations to get the Kappa score.

Why two scorers? Why two rounds of scoring each?

Having two scorers lets us see scoring variation between scorers. Having each scorer score the samples twice lets us see scoring variation for one individual across two rounds. If the scorers are consistent with each other, we feel good. If the scorers are consistent with themselves between the two rounds, we again feel good.

What is a good Kappa score?

When looking at the Kappa score between two scorers, if we get above 0.70 (out of 1.0), we've got a pretty good data collection system. When looking at the Kappa score for one scorer between two rounds, if we get above 0.85 (again out of 1.0), we've got a pretty good data collection system.

How does this fit into Lean/Six Sigma and management in general?

Whether we're leading a Lean/Six Sigma project or using data to guide us in everyday management, we want to know if our data is valid. That's what a Measurement System Analysis (MSA) is all about, and a Kappa calculation is just one way of doing a MSA if our data is attribute/discrete data.

Of course, even if we prove that our data is valid, we should never rely on data alone. We can surely use data to point us in the right direction to where problems are, but we should always go to the gemba and check out the gembutsu with our own eyes. Never let data get in the way of facts.

Where can I learn more?

There's a guide I recommend, The Lean Six Sigma Pocket Toolbook by Michael L. George, et al. Starting on pg. 100, you'll see a complete explanation for how to calculate Kappa.

Standard Work for ER Residents

2011-03-24T12:04:00.000-05:00

As a non-clinical member of a large hospital, when I can get even 30 seconds with an ER physician, I consider myself lucky. Today, I got about 5 minutes with one, which gave me the opportunity to throw some ideas out there about ways to standardize and kaizen repetitive aspects of his job.

The Concept

I mention 'standardize' and 'kaizen' together, because as Taiichi Ohno said, "Where there is no standard, there can be no kaizen." Standard work gives us a baseline from which we can analyze deviations, which leads to the discovery of problems, which through good problem-solving leads to continuous improvement. Without the baseline, we can't even tell if we have a deviation. That's why I was discussing standardization with the ER physician today.

The Specifics

We specifically discussed standard work in the context of the Resident-to-Attending report-out. This is the process by which a Resident (a med school graduate who is in-training) reports to the Attending (a senior physician) on the condition of a patient and what the treatment plan should be. This is typically done verbally, which makes it critical that there be some sort of structure around the verbal report-out.

In med school, students are taught reporting structures such as SOAP that help provide some standardization to the report-out process. If we say that the SOAP approach is our standard, we can at least check to see if it is being used and look for deviations. If there are deviations, we can ask why and keep asking why until we get at the root cause. If needed, we can find a better standard. The point is, we need something to get us a baseline from which we can assess the process.

The Reason

But why do we even need to worry about the Resident-to-Attending report-out process? Because it causes patient delays, which can cause patient safety and quality of care issues. Until the Resident reports to the Attending and a plan of care is agreed-upon, you don't usually see any orders being placed. No orders, no treatment. Nurses can do their best to monitor and support sick patients, but until orders are placed it's hard to provide much care. That's why we need the best Resident-to-Attending report-out process possible, which is why we need standard work and good problem-solving.

Of course, this whole problem makes me think, is there a better way? Is there a different model that would allow Residents to get the training and monitoring they need from the Attending without creating delays for patients? That's true north for the Resident/Attending relationship.

Hey y'all, it's Hospital Kaizen

2011-03-22T22:11:00.000-05:00

Not sure what exactly I'm going to do with this blog, but I'm hoping to explore kaizen concepts within the context of a hospital. Should be fun.