DailyKaizen

Thank you to Group Health patient Donna Kerr for writing down her experience. Please let us know what you think. I think I would like to continue to see patients involved in every event.

Day4: Transforming the Commonplace

We are in our last day of the work of this Quality Improvement Support Team. The changes in the system have gone live in this medical center (to enthusiastic applause); now reports are beginning to walk in the door. During the first three days, I characterized and tried to figure out how this improvement process works. Today I want to tell a small story. It is about something that just happened here in Conference Room C.

10:22 a.m. Nurse S walks into the QIST room to report to the system builders that the SmartSet (here, information for the patient) did not appear with the blood pressure alert (BPA) that fired for a hypertensive, diabetic patient. The builders took down the information necessary to investigate the case and thanked the nurse for letting them know.

11:17 a.m. The EMR support staff confirmed that the builders’ correction in response to Nurse S was up and working.

Commentary: That is precisely what we hoped would happen. A member of the clinical flow staff spotted a problem and made the effort to report it. Though predictable in this context, what just happened is remarkable!
The organizational commonplace would be for a change to be instituted, for the staff member to observe the glitch and then remark to a colleague that the failure was so predictable. Further comments in private might excoriate the very improvement effort, for example: “How dare they think that they know how to improve upon what we do!” That is, a mistake would occasion finger-pointing. Instead, because the process values perspectives of the flow staff, treats errors as important sources of information, and makes it clear that the system builders’ role is to help the flow staff, Nurse S came to the QIST room with her report. In organizational life, this represents a transformation of the commonplace.

This QIST is finishing its business, as is my participation. Ted, thank you for your invitation to share my experience as a member participant. Writing my observations has helped me see. I hope that I have done this laudable improvement process justice. Congratulations to you all and thank you for taking care of my healthcare system.

I started reading the new Jeffery Liker book last week called Toyota Talent and I have found it very insightful.  In the book Liker reveals the people development systems that Toyota has in place that have been so effective for the company.  If I had read this book a year ago I don’t believe I would have found it nearly as interesting or useful since I was still mainly focused on leading event driven Lean.  A year ago I was much more focused on solving problems for people then I was helping them solve them on their own.  I would apply the tools and principles, but did very little to teach line managers and staff how to do what I already new how to.

Now that I am deep into the Model Line work many of the lessons that Liker brings out within the book really ring true and confirm that we are doing the right work.  In order for us to be successful everything we do needs to be focused on developing people.   Almost every ounce of our energy as a consultancy is now focused on teaching as opposed to doing.  It has been fun to watch many of the Line managers that we are working with make huge strides in their ability to manage, lead, think and behave effectively.   In this spirit I am going to take a quote from Liker:

“The techniques are valuable, but people cannot learn to make them work if they are not challenged and supported in the process of learning how to make them work.  The dilemma, then, is that people merely want to copy the outward appearance of what Toyota is doing, but they do not want to pursue the much harder and time-consuming aspect of changing their own behavior to replicate Toyota’s culture and infrastructure.”

Written by Donna Kerr, Group Health patient:

I am participating in this Quality Improvement Support Team as a patient participant. However, in doing so, I do not check my own professional expertise at the door. Patients are, of course, not only patients. As a patient, I am keenly interested in understanding what accounts for this wonderfully effective process for strengthening my healthcare system. Having entrusted my healthcare to this organization, I want to understand the “magic” of QISTing well enough to explain it. As a person who also has leadership and hands-on experience in the development of institutions with quality measures in mind, I want try to figure out how QISTing works. (Here’s follows what I am learning, though clearly I may have relearning to do and would appreciate feedback in this regard.)

It is obvious to me that QISTing doesn’t just happen. What looks like magic is not. The assemblage of the pertinent clinical, informatics and organizational expertise reflects both a commitment by top-level leadership and considerable advance work. In turn, a decision at the top to commit the resources doesn’t just happen.

Courage in leadership. We QISTers have been focusing on supports for the treatment of hypertension this week. As a patient, it has occurred to me that if I were to have consistently elevated blood pressure, I might not want to acknowledge the numbers. Having hypertension with all its dangers would not accord with how I want to view myself. Indeed, wanting to see myself as a highly competent, vigorous person in charge of my own fate, I might well be inclined to ignore the unwelcome BP numbers. Similarly, I can imagine that the leadership of my healthcare organization might not want to attend to HEDIS numbers that do not bespeak the quality of performance claimed in the branding, boilerplate for donors, and self-images of administrative competence. Hence, one of the necessary components for QIST to work is leadership’s courage – the courage to acknowledge inconvenient, unflattering facts and the courage to commit the needed resources.

Bundling clinical and informatics expertise in both the team and the process. This is one of those times when saying the obvious has a purpose. QISTs are supported by an organizational entity entitled the “Clinical Information System.” The success of this entity depends crucially upon the fact that it brings together clinical and informatics expertise. Several correlative facts might not be so obvious – facts that remind us that QISTS have distinct uses and limits:

(1) QISTs can address only problems that lend themselves to extant information or information categories; they regard populations and not individuals. Put otherwise, their solutions would not regard me and my particular concerns, but populations and categories of health data and diagnoses.

(2) QISTs produce solutions exclusively in the form of computer-managed information.

(3) QIST solutions do not call for acquiring new clinical knowledge, but instead ask clinicians to bring to mind things they already know when thinking about individual patients. QISTS do not probe clinical judgment or occasion further education.

(4) The Clinical Information System succeeds in using the QIST as a tool only in measure that it constitutes a team that puts clinical and informatics together in describing and modifying actual work flows around the selected issue.

(5) The QIST work plan does more than bring the pertinent expertise to the table to generate a solution; it also includes a process that test drives the solution in the context of local clinical work flows prior to system-wide implementation. That is, the pertinent clinical expertise includes, of necessity, those who are themselves immersed in and responsible for work flows.

Tending relationships. While leadership and clinical-informatics expertise are essential elements of the QIST “magic,” there is a third essential leg: careful attention to the relationships among team members. This thoughtful attention to relationships is necessary and not just nice, though participating on a QIST clearly feels good! Persons are invited to be a part of the team precisely because they have expertise and experience pertinent to the work flow that is under the microscope. Engagement of that expertise requires tending the human relationships.

The process will succeed only if team members feel that the environment is safe for speaking the truth about work flows, that their contributions are valued, and that part of everyone’s job is to honor the contributions of others. In other words, it is not some disembodied QIST process that produces the needed solutions; it is persons standing in relationship to one another who get the job done. Lest this point risk seeming too vague, I hasten to add specifics. I find extraordinary the genuine solicitousness, the expressions of appreciation (including applause) and the sense of collective energy that permeate at least this QIST’s work.

What is being built here is not just better healthcare delivery around a specific issue, but also a healthier healthcare organization. That makes me pleased to be a member both of this team and of this healthcare cooperative.

Another guest posting from member Donna Kerr:

Second-day notes on QISTing

Here follow some notes on what I am learning about QISTing.

Visibility. Transparency in leadership is one thing; visibility of work is entirely another. An essential and powerful tool of QISTing is the tool of tracking work and its progress visually. When work is tracked from “in queue” to “in process” to completion via cards for all to see, the writing is literally “on the wall.” It is a powerful reminder that though the tasks and organization may be complex, all of the pieces come together. This visibility allows us all to see how our work and how we are doing. Judging from the sense of camaraderie, I also surmise that making our work visible to one another creates the “we” who do the work. Such a context enables even the “lone cowboys” to regard work as held in common.

Clinical knowledge and informatics. While QISTing draws on the system of electronic medical records, it focally addresses clinical work flow. Hence, QISTing is not just another application of EMRs. First, it calls clinicians to get clear about the work to be done – a process that requires much discussion and coming to agreement; second, it requires that the clinicians and information system builders consult to the end of the clinicians understanding the uses and limits of the system and the system builders understanding the clinical-support tools that they are being asked to develop.

Solving locally, applying globally. Centralized planning has, by definition and by history, solved problems globally and required local applications. QISTing takes a different route. It brings into discussion small samples local clinicians and other members of the flow staff together with centralized system builders, regulatory expertise on population-based care and improvement specialists. The goal is to develop a system that will be tested and work locally. If and only if it passes the test in one locale will it be applied globally in the healthcare system. The defining focus derives from lean management, which organizes its activities around the work flow “on the production floor.” Any and all improvements take place in clinical work flow.

The ten-minute encounter. I have a hypothesis that there’s a tacit assumption driving much of QISTing, namely that the physician (perhaps the entire clinical staff) has and will continue to have patient encounters that endure for far too short a time for the complexity of clinical assessment and knowledge. It is this “fact” that drives the definition of problems and the shape of the solutions that QISTs generate. For example, “best practice alerts” are developed as a way to remind a time-short physician of what she or he already knows, but may not have readily at hand in the press of the moment.

Donna Kerr, a Group Health member, has accepted my invitation to be a guest blogger during her time with us in our Olympia Medical Center:

A Learning Organization – an introduction

At Ted’s invitation, I write this entry as a guest. I have the splendid fortune to be participating this week as the patient on a primary care Quality Improvement Support Team (QIST). The team is focusing on changes in the information system to support an effort to ensure that no hypertensive patient goes inappropriately untreated. The team includes physicians, “flow staff,” information-system builders, administrators, professional improvement staff and me. The goal is to design a solution, to develop an effective modification to the information system, and to have it “go live” for local testing prior to global implementation.

I am witnessing an organization that is learning from experience. This primary-care QIST, a cross-functional team, is engaged in a focused discussion of the problem that has been identified through HEDIS data. That leadership might discuss such a problem is not by itself predictive of an organization that has the capacity to learn. The crucial pieces are (1) that key medical and informatics staff are involved, (2) that the perspective of each participant is being heard and valorized; (3) that some clinicians actually acknowledge errors, even in the presence of me, a patient; and (4) that the point of the QIST is to define and implement a solution in light of information gleaned from the errors and with the goal of improving patent care.

I celebrate the capacity of this “lean”-inspired system to define a problem created by practice and to learn from this experience. This is truly extraordinary in organizational life, where the destructive practices of obfuscation and denial are commonplace. In particular, I am heartened by the fact that my healthcare organization has a culture that supports learning – a culture where it is apparently safe to own problems, recognize limitations in knowledge or its application and acknowledge mistakes. As an educator who has also led organizational development, I appreciate how very difficult it is develop an organization with the capacity to learn from experience. As a patient in this healthcare organization, I could not be more pleased.

Meanwhile…in another part of our delivery system…we began such an RPIW, with doctors, nurses, and for the first time in a real way….a patient/member of our care system.

I will admit here that I know this is the right thing to do, and it makes me nervous at the same time. I am not worried at all about a member seeing what we do for them. More is better. I am nervous (as a physician is about things out of their control) that I want this to be a standard piece of work in everything we do.

So far so good. I have asked our member to compose her thoughts on her time with us and I will post them here, when she is ready.

In terms of my participation in this event, I asked the event leads to kick me out of the work room, and to hesitate to let me back in, so that I could spend my time shadowing care providers. They graciously agreed.

I began by shadowing a Licensed Practical Nurse managing incoming phone calls and messages. At one point, I think I presented as a curiosity to the staff - a physician shadowing a nurse (such curiosities should run rampant in health care). I think I learned 10 things every 10 minutes as I hoped to.

I then shadowed a family practitioner in the medical center, who really represented the amazing breadth of family medicine in terms of the people he cared for. In each case, the patient graciously welcomed me in to observe, and I thanked each one for the gift of their time, which is much more precious than mine.

RPIW (rapid process improvement workshop) is the name that our organization uses for our standard, five day, cross-functional improvement event that is based on the Toyota model for supplier organizations.  Eight months ago when we began working in the Division that is home to our Model Line only one RPIW event had ever been facilitated.  Eight months later we now have event taking place a couple of times per month and the power of Kaizen is really beginning to show itself as managers and staff are able to have multiple lean experiences.  

With most of the groups that I have worked with in the past we would lead a couple of point improvements, show a return and then move on to the next group.  As a result, teams were never able to get the deep understanding that of lean that only comes through application, trial and error. 

I remember talking with a Lean leader once during a benchmarking interview he commented that it take years of hands on experience to really master lean, but that teams will start to get it after their third kaizen event.   In the Model Line many of our managers and staff members have had several opportunities to learn and apply lean principles and tools and it is exciting to see them developing and learn how to work differently.   I have had several managers comment to me over the last couple of weeks that they would never be able to “go back to their old ways.”    On a large scale we are developing leaders through doing (kaizen) and as they continue to become more experienced they will only get better and be able to teach others.  

“The three great essentials to achieving anything worthwhile are: first, hard work, second, stick-to-it-iveness, and third, common sense.” –Thomas Edison

Yesterday morning I saw this quote hanging in a picture frame at a local coffee shop and for some reason it stuck with me.  For the last eight months I have been working with a great team and this quote could really be our motto.  Everyone has been working incredibly hard to hold everything together, which has not been easy given the scale of change that is currently in process.   I was remarking to my boss last Friday that I can no longer plan more then a couple hours ahead of me, because so many things come up and need to be worked on in the moment. 

The team has stuck-with-it even though there have been countless days where we have had to pick each other up and dust off the frustrations of the latest problem.   I am learning the art of being patient even though it is against my very nature.  It really has been a two step forward one step backward journey thus far. 

Yet, every week we seem to be making a little more progress then we did the week before and all of our success is based on simple common sense.  Simple in concept and hard as hell to do.  

This was a quote from a colleague manager of one of our information systems teams today. She told me this from 300 miles away, where she is spending the week with information technology colleagues, nurses, and doctors, at one of our medical centers, installing new clinical decision support tools for our entire health care system. These tools are intended to help prevent cervical cancer.

On its face, it would seem the height of inefficiency to transport a high performing information technology team 300 miles away from their colleagues, from the servers, from their managers, to implement a product like this. What CFO would support this?

What we know now is that we aren’t building an I.T. product - we are supporting the product the patient is expecting - lifelong health and a patient-physician relationship where needs are anticipated. The support tools must be created as close to the patient as possible to meet the highest first time quality and critical to quality expectations. And they must be created efficiently.

The amazing feeling happened, she told me, when a physician working in the medical center let her know that the tool that her team turned on today, supported the physician in initiating screening for cervical cancer for a patient who was in for another reason but was overdue. She told me that she didn’t imagine that her work on an enterprise computer system would directly impact a patient that very day. From where I sat, I was imagining that the patient probably didn’t realize that someone 20 feet away, rather than 300 miles away, was improving the system she depends on to anticipate her needs. I read this story to our team back in Seattle as an example of a great accomplishment for our patients.

In the old days, I would get the feedback (good or bad) from our clinical staff, and the technologists would be the nameless, faceless IT department (the old adage “I.T. is most successful when it is invisible”). How much better, though, is it that the person doing the work for the patient, gets to see the impact for the patient? A lot.

We talked more about the process and she mentioned that it was a bit frustrating in the morning testing the tool to work and putting it into the live system. She said, “I was hoping to have 2 whole days to test this out.” Now she only has one and a half.

I joked that I was impressed that here we were complaining that something that should take several months to do using a thick-process should take 2 and a half days instead of 2 days.

So… 2.5 days instead of 2.5 months, clinical staff using tools that they develop themselves, seeing the impact of performing for patients and letting others know about it, better FTQ and CTQ. Asking the question again: What CFO would support this?

Yesterday I received the following question from Marlan, a blog reader, about backlogs that I thought I would answer in a post:

What I’m wondering is how often backlogs are due to the assumptions of people in the system that the cause is due to insufficient resources to meet the demand. I have certainly found that assumption to be almost universal with managers and providers I have worked with to eliminate appointment backlog in behavioral health outpatient clinics.

To the extent this is true in a particular situation, then backlogs may exist more by default rather than by design. Thoughts? Was/is this a factor in your situation?

When we first start working with a team it is almost always that case that we are told that the team is understaffed.  As we begin to collect data and uncover variation most of the time we find that this is not the case.  I can’t think of a single example where once the current state was understood the team still asked for more staffing.  Often times there will be certain team members that have way to much work while other are sitting idle.  You may also find that there are day of the week or hours of the day where demand is greater then capacity and others that are idle. 

If you go to Gemba and collect the data I would be willing to bet that by applying Lean principles you can do more with less and eliminate backlogs.  A backlog as well as thefeeling of being overwhelmed are symptoms of processes that are not stable, balanced and under control.   Teams often feel like they have to much work to complete, because they are not able to view the progress that they are making. 

A good place to start is to look at your backlogs over time as well as your variation in demand.  If backlogs stay fairly consistent you know that your are doing about as much each day/week as is coming in, but maintaining the security of inventory (in Marlan’scase patients).   When there is large variation in demand of incoming work it can often feel like a team is not staff correctly even though they have the capacity.  I am working with a team right now that gets twice as much work on Monday’s as any other day in the week.  As a countermeasure the team has implemented a hejunika, which means they still have a small backlog during the beginning of the week, but by leveling production the team feels far more in control and productivity has gone way up. 

Do other readers have a perspective?