The following content is
provided under a Creative Commons license. Your support will help
MIT OpenCourseWare continue to offer high-quality
educational resources for free. To make a donation or to
view additional materials from hundreds of MIT courses,
visit MIT OpenCourseWare at ocw.mit.edu. BO MADSEN: Continuous
process improvement-- we're going to need
some improvement here. Can we agree on that, or
did it flow seamlessly? You're happy? Maybe it feels like something
you're already used to so hard to see the difference. So at the end of
this, you should recognize the PDSA or PDCA-- Plan-Do-Study-Act
some of your notes. I think say, Plan-Do-Check-Act. It really, it is the same. We just like the study
better than the checking. And because you need to see-- follow up on what your
changes they actually mean. We'll get to that. A bit about A3
thinking-- and there's a lot more about that tomorrow. But it is an effective
improvement process approaches. And you should be able to use
a framework, continuous process improvement framework for
bettering your system. You should be able to
apply the value stream mapping did a little bit
about that yesterday. I know it was short, and
you'll do some more now, so it should help you get that
concept more under the skin. And then we'll do some root
cause analysis as well. And we talked about the
five whys yesterday. We'll get into that more now. So what is it this
Plan-Do-Study-Act? Well, it's something that we
use because for improvement. And you use it as a
problem-solving tool. And you use it as something
that will give you an overview of what you're doing
now, how you plan your changes, and then actually
doing those changes, and remembering to
follow up on it. It's also so that we try to
solve problems in the same way. Because that way, it's
easier to integrate work in the organization. And instead of working in silos,
you can work across everybody. It's using the same methodology. The A3 thinking is built
on the same as well. So A3 thinking-- collaborative
problem-solving approach-- and it gives us a
logical approach to how to solve problems. It tells you something
about where are we now? What is the strategy
of our organization? Where is it that we want to go? And how do we plan to go there? Do you know what A3 stands for? AUDIENCE: Paper size. BO MADSEN: It's a paper size. Yeah, exactly--
you know A4 paper? So in Europe, we don't
use the letter form. We have something called
A4, double-size A4, it's double-size
letter is an A3. So A3 thinking is your plan
for improving something that fits within an A3 size. So it forces you
to be very concise. You can't go on rambling about
this, that, or the other. Because there's
simply no room for it. And it does fit
within that size-- takes a little bit
of practice, maybe. But it does. And again, what is
so important about it is is well, if everybody in
your organization is using this, you can collaborate. Because that your partners-- they are thinking
the same way as you are, which is really important. If you think about it, how
it is now in many places, people-- they solve
problems totally different. Some departments they have a
chair, who's maybe a dictator. This is a problem, this
is how you'll fix it. Others say OK, let's sit down. Let's think about
how we can do this. And you brainstorm,
and maybe you come up with who does what,
or maybe you just come up with a lot of ideas that are
sitting there and collecting dust. But this gives you
really a platform to do it the same way-- everybody, which is nice. And part of that in this A3
thinking or your plan here is the Plan-Do-Study-Act. It is a piece of how you solve
problems and improve processes. But it's only a piece of it. It is not the
answer-all questions. So don't take it as such. So for the continuous process
improvement, the framework here, there are
a number of steps we will get through them
as we go along here. But first, do we
perceive the problem? Do we understand
what the problem is? That's important before you
start improving anything, you know what they say. So all improvement is a change,
not all change is improvement. So you need to find out
what your problem is to improve the right thing. So you need to grasp
the current situation. How do you do that? How is it we find out what
the current situation is? AUDIENCE: [INTERPOSING VOICES] BO MADSEN: You observe. Where do you observe? AUDIENCE: Gemba. BO MADSEN: In Gemba-- where the actual people
do the actual work in the actual place. There you go--
the three actuals. Value stream
mapping-- so I said, we did a little bit yesterday. So we need to find out
what our value streams are. Have we mapped the
end-to-end processes here-- the information flow? Do we know that right now? After our little
simulation exercise here? We have an idea about it. My perspective sitting
over at table three here was that the information
flow was maybe what we had the most difficulty
with finding out where-- how that is connected. I don't know how-- what
was your experience here? Was it the physical
flow of location? Or was it more information flow? AUDIENCE: Information flow. BO MADSEN: Yeah,
so maybe that would be valuable to find
out about that. And then, you add
on the process data. Also, like we talked
about yesterday, add on things that will give
you valuable information. But don't clutter it with all
information under the sun. Because it ain't
going to be useful, and you won't have space for
it if you do it on your A3 as well. So you need to think about what
metrics represent the system performance-- wait time, throughput time,
financial performance. So not so much
talking from here-- 15-minute exercise. Develop your process map
as it looks right now, not the anticipated
future state. But what does it
look like right now? Write your process
steps on your Post-its. You have the easels that
you can put them up on. And you can connect them. And just before you
start, add the decisions-- the waits, the holds,
and the inventories. Are there pileups? And look at this one. That's how you can look at it. Inventory or awaiting--
triangles, task, rectangles, burst-- if there are issues-- diamonds, decision points. Try to do that. You have 15 minutes
so quarter past 11. HUGH MCMANUS: So this exercise
is just like yesterday. You should be writing
at kind of the exam or whatever the single sticky
per process level on these. Do them first then the
inventory and decisions. And when you're quite satisfied
with all that on the stickies and you have [INAUDIBLE]
then tie them together with the matches. [INTERPOSING VOICES] SPEAKER 1: The only reason
it would go in a discharge is if they've already
been to the lab. I guess put that
there too, though. Because it's an option. SPEAKER 2: So make it
a little different-- SPEAKER 3: Just
make these in pink. SPEAKER 2: This has
to come back here. SPEAKER 3: Right,
But then failed has to go back there too. SPEAKER 4: I think we need
another decision point here-- if previous tests. So if there was a
failed test then it would have to go back to here
because of [? positive ?] test. And they've already been-- SPEAKER 5: You can go like-- SPEAKER 4: they go
back to discharge. SPEAKER 5: We can go
test results here. HUGH MCMANUS: OK, So
everybody's gotten pretty close. They're still tweaking some
stuff and realizing that when you try to map out this process,
although it seems fairly simple, it isn't. It's kind of
complicated, and it's complicated a couple of
different dimensions. What I'd like to start
with is just to have-- why don't we start with you
folks briefing your map, just real quick because
everybody knows the process they've got the
same one, just brief how you mapped it. If you could do that. SPEAKER 6: Go ahead. SPEAKER 1: OK. So we put our three
big decision points made by triage, the MD, and
lab as these green diamonds. And then instead of
having a waiting room, we treated all of
the wait times with these upside-down triangles. HUGH MCMANUS: So that's nice. It's functional. There's a couple--
there's one thing that you sort of abstracted, which is
that issue of everything going back to the waiting room, which
you distributed, which is fine. You have to make that decision. But you've sort of
abstracted that. And the other thing,
of course, is the fact that there's a dependency. The lab results often affect
what the MD has to decide. So there's an
additional complication, which isn't captured at
this level of detail. You could capture it. But it would essentially be
more detail on the decision. [INTERPOSING VOICES] HUGH MCMANUS: We're
just multiple decisions that the MD has to make. Has this patient been seen? Did they fail their
lab tests, et cetera. Did they get a positive
result, because that affects where things go. That's cool, so
now let's have you folks just by way of contrast,
tell us your strategy for plotting out the
value [INAUDIBLE].. SPEAKER 7: So we have
the different tasks that people have
to do, which were all in green, so scheduling,
registration, triage, et cetera. But what we
represented the waiting room as a physical location. So it was like a mix
between that spaghetti chart and the downstream map-- so basically in between
every single task they have to go back
to the waiting room. And so we are also
didn't quite finish, but we try to have
the dependency. If the test result
is negative, you go back to the waiting
room, and then discharge. If positive, then
something else [INAUDIBLE].. And then the MD has to decide
based on the previous test, what to do. AUDIENCE: They also start
with times [INAUDIBLE].. HUGH MCMANUS: That's kind
of our next step, actually, so they're ahead of
the game as usual. This table is good at that. So you guys can
finish up your traces. But here, they're taking
a more physical approach. And the maps capture
different things. This, it's sort of hard to
see the flows and decisions. Because everything's going back
and forth to the waiting room. So it provides a sort of
a visual confusion factor. But maybe, the issue
is that everything's going back to the waiting room. Maybe that's like
an issue that we need to deal with, because
that is obviously, confusing. It also has an awful lot
of waste of motion in there with the poor patient and
the potential for confusion that that engenders. And I can see your strategy
although you didn't finish that there's actually
individual paths here, which are going to get more
complicated as we get the failed diagnostics,
where maybe you could use a different color to trace
the extra ones [? too. ?] So you can follow it,
but it's a bit torturous, but it does capture certainly
the chaos of the system quite nicely. So why don't we finish here
and see what you guys have? You want to say
something about it? [INTERPOSING VOICES] SPEAKER 8: We have each of
the stations in the blue. I think the main
source of chaos for us was what happens with the
exam process and the decisions afterward. So that was our main
point of contention at the end of this
process is where do we put all these
negative-positive failed test outcomes? And how do they
eventually link back to the patient-to-start process. HUGH MCMANUS: And got some
color going there to sort of try to chase that around. AUDIENCE: These are all value
stream maps from the patient. But we don't have
the information for-- HUGH MCMANUS: Right, there's
some other [INAUDIBLE] there. AUDIENCE: There's charts
and paperwork flying around. HUGH MCMANUS: That's right. And we did say we were following
the patient value stream. But there are some other value
streams up there-- the charts, the paperwork, which we
actually could use pretty much the same map to chase. But they also have their own
chart room and record room and to some extent,
their own processes. They don't follow exactly
the same path as the patient. So this is good. So why don't we continue
with our exercise. BO MADSEN: Yes, so
remember, yesterday we talked about different times. We talked about cycle time-- the time from the beginning
to the end of the process. The touch time--
where the actual work is being done, where you
exclude the wait times. And then again, value added
non-value added time-- so we talk about some
different types of time. And obviously, it is the value
added time that we really want, and we prefer to get
rid of the rest of it. So then there is also-- when we get to the
capacity things as well, you need to think
about failed tests. This is not 100% right. You have a certain
amount of your test that just they're neither
positive nor negative. They're just failed. Hospital systems for us-- what I have in my face
every day is potassium. Do you experience
the same things? You get high potassium. Everybody gets scared. Because it is dangerous. You need redraws. And we used to be around 20%. And now, I think we're down
to 7% through leaning it out. But 7% is still a lot. Because like you said,
what does everybody do when they come
to the hospital? They get lab tests. So we have probably a
couple of patients every day referred to the emergency
department for hyperkalemia that we redraw. And then it's negative-- normal. So that's expensive. HUGH MCMANUS: So why don't we-- because this group seems to
have caught the basic issue, and some of them have
already jumped ahead-- and what we want to do is add
some time and reliability data to our map. The tricky thing is, of
course, every patient is different based
on the dice, right? So we have to pick some kind of
unit of analysis-- an average, a median, something. BO MADSEN: A min and max maybe. HUGH MCMANUS: A
min and max, right. So we need to decide what
our unit of analysis is and be consistent. It almost doesn't
matter what it is. Over long experience
with these things, I found that doing
a min-max average is easily enough detail. When you start putting min-max
average on all of these, you suddenly realize, I got a
whole bunch of numbers here. And it's enough to
tell most of the story. So we don't need a deep
statistical analysis of these numbers. But we need to decide
what our unit of analysis is, put the times up. And the times can pretty
much be the hourglass. If there's a little bit of
non-value-added touch-time, if there's a little bit of
futzing time or confusion time or waiting for supplies time,
you can add that, as well. And put those times
on our processes. And then the percentages of
different decision outcomes, again, need to be estimated. Some of those are
based on the dice. So you sort of have the
numbers in front of you. Some of them aren't so much. When do they go to the hospital? Well, when the
right-colored head shows up. When does that happen? You don't know. You just have to
kind of estimate based on your experience, OK? So not too complicated. Let's take another 10-ish
minutes to finish our maps and annotate them. EARLL MURMAN: I love that. AUDIENCE: So we're doing a
weighted average to our-- EARLL MURMAN: Yeah. AUDIENCE: Yeah, so if there
are two patients waiting, one will be waiting
for this much. And the second will be
waiting for two units of this. EARLL MURMAN: Excellent, yeah. AUDIENCE: Yeah. And if there's a third
patient, the third patient will wait for three
units of this. EARLL MURMAN: Yeah, OK. But we have to kind of
average when we roll it. So on average, how many patients
do you think were waiting? So treatment time is
three times the dice roll. AUDIENCE: Yes, 40 seconds. EARLL MURMAN: OK, of which only
1/3 is value-added time and 2/3 is waste. The average time a
patient is in here is 80 times 3, which is
240, which is 240 seconds. AUDIENCE: OK, so
should we just put 240? EARLL MURMAN: 240-- AUDIENCE: Yeah, you can do that. EARLL MURMAN: --of
which 80 is value-added. AUDIENCE: So how about we put
average time and value-added? EARLL MURMAN: Yeah, OK. AUDIENCE: OK. HUGH MCMANUS: There's
basically two ways you could tackle the challenge
of collecting data in the sim. And I think different
teams did it different ways, which
is an interesting thing about this group. It's a fairly
sophisticated group. I think that people
have grasped the issue and made different decisions
about how to tackle it. You could go in, and
you could say, well, OK. If I rolled an infinite
number of dice, what would be the
statistically likely outcome? What would be my
weighted average time? What would be my weighted
average of different outcomes through the system? So you could do it that way. And that's something
in the real world you could do if you had profound
knowledge of the system, if you just knew that 30%
of this kind of patient went this way. Or other approach is you
could use data, right? We have data. So you can just
count them, right? Which ones went where? How many dots do we have to do? How much rework was there? The problem with that is
that it's small n, right? It's not going to give
you the same answer as the statistical study unless
you have a really large sample. Now, is that your world? Pretty much, right? In fact, medical studies tend to
not really converge unless they have really large samples. But this is real. This is the reality
on the ground. Which one do you trust? Which one do you believe? You have to choose, right? There's no absolute answer. BO MADSEN: It depends on
what system you are in. So BI would probably have the
most advanced medical records in this country. So we can pull everything out. And we can go 10 years back,
50,000 or 55,000 visits in the emergency
department per year. And we could just
pull all of that out. It's fairly easy, but that's
because we have good people. But that's not the
reality everywhere. So I worked with Iceland
and with Denmark. And, well, they have
fairly sophisticated electronic medical records. But a lot of it
is still on paper. And you just need to go
and look at the paper. And at BI, our record
has limitations, too. Let's just say we
want to study sepsis. We want to study the antibiotics
that these patients got. I can electronically see what
got pulled out of the Pyxis. You may be familiar
with the Pyxis-- locked cabinet. You punch in the patient's
medical record number and what you want to pull out. But I need to look at the paper
to see what the nurse gave because one thing is
that they pulled out 4.5 grams of x, y, or z. But if they only gave 3
grams, that information is only available
on paper as it is. All right, so, yes,
you can go either way. HUGH MCMANUS: And that's-- BO MADSEN: Here, with the
numbers that we added on, we had it a little bit fudged
because, well, when you handle stuff, it takes time. 15 seconds for just handling
the patient to the waiting room, passing on the message. New patient takes time. There is a range of how long
the different steps take, and the weighted
average plus the fudge. OK, so it's hopefully
pretty similar to what the different groups found. Maybe? Take a look. HUGH MCMANUS: Yeah, did you do
something kind of innovative here instead of-- AUDIENCE: We calculated
the actual waiting time for the patient in MD. So the process time-- so
if it's 1 or 2 on a roll, then it's, what's their
probability of 30 seconds? And if it's 3 to 4, it's,
what's their probability of-- [INTERPOSING VOICES] And then I calculated all
of them and summed them up. So for one patient,
the [INAUDIBLE] average time is 80 seconds. HUGH MCMANUS: 80 seconds, OK. All right. So-- EARLL MURMAN: But then there's
another important step-- HUGH MCMANUS: Yeah. AUDIENCE: Yeah. EARLL MURMAN: --is that
she's got patients waiting. HUGH MCMANUS: Oh, OK. AUDIENCE: Yeah, so if
one patient is waiting, and he probably will wait for
the [INAUDIBLE] time that's 80 seconds. And if two patients
are waiting-- so this is 80 seconds-- this
one will be 160 seconds. HUGH MCMANUS: OK,
there's an issue. I noticed that we didn't
even try [LAUGHS] to estimate the waiting times, right? So she's gotten extra
sophisticated and said, the 80 is actually, we tacked
on 15 seconds for paperwork. And so we're agreeing
on that exactly. What she's doing,
which is very clever-- and this, you probably
do need to do database. How many patients did you
have waiting typically? So yep. EARLL MURMAN: So she estimated
that she has two patients on average waiting. HUGH MCMANUS: Waiting, OK. That's right. EARLL MURMAN: So the
actual time in the MD was three times the
actual treatment. HUGH MCMANUS: Right, right. So if we have-- BO MADSEN: So 240. HUGH MCMANUS: Yep, yeah. So that's great, right? That's going deeper than
we did in our example. And that's right. Any time you have inventory
in front of a process, yeah, it's going to have to-- something called
Little's law, which we'll talk about next time. You're going to have
to wait essentially that number of cycles to
get through the process. So if there's two patients
waiting and one in exam, it's going to, on
average, take three cycles to clear a patient
through there. So that's very good. OK. BO MADSEN: And then
if you look at your how long time things
[? they ?] take, you should also get a sense of
what the rate-limiting steps are here. What would you say? [LAUGHTER] When you look at it,
who's the limiting step? AUDIENCE: MD and the lab. BO MADSEN: MD and the lab. AUDIENCE: Yeah. BO MADSEN: What's the difference
between the MD and the lab? The MD is-- AUDIENCE: One. BO MADSEN: --one person. And the lab can do,
how much at a time? AUDIENCE: Three. AUDIENCE: Potentially. BO MADSEN: Three with a
little bit of good luck, right, because they can do three
different things at a time. But if you look at the times
of the lab, well, 45 to 205. The same for the lab. But the MD is really
only one and can only be in one place
at a time, so OK. And then there's some rework. HUGH MCMANUS: And that,
too, we have essentially the same issue, right? People can look at the
dice and guesstimate. Or they can look at
their data and figure out what the rework rates are. The thing that
actually you can't do there is that some of that
depends on the patient color, which you don't know, right? There's an externality
there that you don't have any control over. And if that's true, all you can
do is look at your data, right? You don't know what the
big world looks like. You only know what
your data looks like. So based on that, you should
have something on this order. Something on the order of half
of the tests don't go so well. So that's another
major detractor. BO MADSEN: All right, so
diagnosing root causes. You need to find out,
what are the causes here? What's the effect? What's the cause? It's nice to separate those
out because the root causes, if you can find an
effect of those, you have a better chance
of improving your system. We haven't talked
much about workaround. But it's very prominent
in the medical field. So the medical field and
the engineering field, I think that we have some
of the same attributes. It is that we fix
problems, right? We see a problem, we fix it. So I have a problem at
work, I just fix it. I don't go back and say, all
right, why is it that it takes 15 minutes to do
a lumbar puncture? It's not that it's
the 11 minutes that it takes to find the
stuff and get everything ready. I just go ahead, and I do it. Or if it's a new resident, I'll
help them and collect the stuff for them, instead of
saying, OK, we need kits. We need the stuff to be
available in the area where we use it because
that's a long process. It involves our
nursing leadership, physician leadership,
and restocking guys. And it's someone else's
area of responsibility. And they're going to be upset
if I say this is all wrong. And so we just do workarounds. That's not a good
way of doing it. You can analyze the root-cause
analysis in different ways-- the 5 Whys we talked about
with the Jefferson Monument. It's very interesting. It's really useful. If you think about
a medical system and say, we do too many
joint replacements, why do we do too many
joint replacements? Well, because the
joints are worn. Why are the joints worn? Chime in here. Why do people get joint
replacements in the US? AUDIENCE: Obesity. BO MADSEN: Yes, obesity. Why are people obese? AUDIENCE: McDonald's [INAUDIBLE] [LAUGHTER] BO MADSEN: No, no. And again, these things
are being answered in a personal manner, right? So you can end up
with different things. But I think you're right on. Pre-processed food is cheaper
than making your own food, right? And then it gets
into, who earns what? So you do, why? Pre-processed food is
cheaper than the other. Why is it? Because we put
garbage in the food. And why is that? Blah, blah, blah. OK, so 5 Whys really work. And it works on many
different things. It's not only the Jefferson
Monument, which is nice, too. We can do capacity analysis. We looked at that yesterday. Remember, how much
time is available? What is our cycle time-- again, limited by the slowest
steps in this process. All right, so
tomorrow you're going to look at cause-and-effect
diagrams and some Pareto charts, too. This we're just going to stop. And pitfalls, they can
be answered differently. Some are based on
values and on opinions. If there's too much
difference, then maybe you need a more
sophisticated tool for that particular problem. But in general, it's going to
work well on many problems. Good place to start. Yeah, it's difficult to identify
all the possible causes. If you have input that's
higher than your capacity, then you're going to
have a bottleneck. And then you're just going
to have a build-up of things that are waiting. Example from Denmark--
pardon me again-- so there is a plan that
says, for instance, pancreatic cancer
patients, they should be able to have
surgery within, I don't remember if it's
two or four weeks. One would hope
that it's tomorrow. But it's two or four weeks. Nonetheless, they don't have
the capacity to do that. And then you have a
build-up of patients. And some of them, they get
surgery two months later, maybe three months later. Others, what happened to them? Well, when it's
cancer, you know what? It becomes inoperable, right? And then they drop off the list. So when capacity and
supply is mismatched, you're going to have a build-up. Theoretical capacity, so
this is a very cool field. You'll have more
about that tomorrow. So maximum capacity is, well,
the maximum sustainable flow rate. Any activity, we like
to think about 100%. Hugh is going to tell you
tomorrow that that's actually not really attainable. And it's not an attractive goal
because it will not function. It will lead to longer wait
times and things like that. Effective capacity
takes into account the errors, the
distracters, the reworks, what you can actually achieve. And we can look at that. So if you can see
five patients per hour but you have an
error rate of 20%, then in reality
you're only going to see four patients
per hour, right? OK, so that's your effective
capacity, not your maximum. All right, let's see. We can look at this one here. Capacity calculation, time
available-- we know that. And then the cycle time, the
time per unit, time per round, the number of resources
that you have. But you're not always
available, are you? You're not available
100% of the time. People, they go to eat. They have bathroom breaks. In Europe, they smoke. And some places, that is being
taken out of your work time now. I'm not kidding. But that's a new concept. It never used to be. So I think smoking
will go down with that. I think it's an excellent step. [LAUGHTER] No, I mean-- and
I'm not kidding. [LAUGHS] The actual touch time,
where you're doing something that is useful for the patient. And then the number of repeats,
the failed test or the, I had a positive test, I
need to go back to the MD, as in our simulation here. So you put that
in your equation. And then you get
your real capacity. The green ones are
the good stuff. And the red ones
are the detractors. So this is basic concepts. People, if you go back
to your organizations, they might be confused by
the words that you're using. But if you talk about
this as a concept, then you should all
be on the same page. So now we have 10 minutes
to do a root-cause analysis for your clinic operation here. So identify causes
that can be remedied using lean principles and tools
that you heard about yesterday. Try to put it on your easel. And let's talk about it. HUGH MCMANUS: So think a little
bit more about what's wrong. You can finish up
your value stream map. Rather than do a separate
easel chart display, why don't you go ahead and
put your suspected root causes right there on the
chart, you know? Is this the problem,
chaos in the waiting room? I don't know whether
that's the root cause. That may actually be a symptom. But we'll put that
right on the chart. So we'll finish the morning
with an annotated chart of the things that
you want to fix. And after lunch, we're going
to proceed to fix them. EARLL MURMAN: So it
sounds like we've identified two major problems. We have the bottleneck here. And there's a solution
to get the [INAUDIBLE].. And then the
failing [INAUDIBLE],, we got to find some
solution for that. AUDIENCE: Yeah. EARLL MURMAN: And then those
are the two main long poles in the tent. And then next level
down is stream-lining the ordering system
and this, just, flow through the waiting room. AUDIENCE: Also
optimizing the order that we get patients from
the MD to the diagnostics so that I can run
a couple at a time. AUDIENCE: So we're doing that. AUDIENCE: Yeah, because-- EARLL MURMAN: Oh, OK. So we actually want to have
this distributed waiting room type of thing? AUDIENCE: No, that is
just so she doesn't-- like, she has to pick which
order she sees the patients in. AUDIENCE: Right, if I'm
treating a gray patient and she's got a gray patient
and blue patient that she's trying to decide
who to treat next, pick the blue one so that I
can run it at the same time. EARLL MURMAN: Ah, wow. So this is a visual control. AUDIENCE: Yeah. EARLL MURMAN: OK. OK, cool. HUGH MCMANUS: Let's talk
about the conclusions you guys came to on your
root-cause exercises. If we could just go
around and just tell me two things that you think
are the biggest problems with your processes from
a root-cause perspective. Let's start back here. AUDIENCE: So our main
problem was the bottleneck in the exam room. HUGH MCMANUS: OK. AUDIENCE: So when it boiled
down to the root causes, we thought it was due to
triage failure, potentially due to inadequate
training here in triage-- HUGH MCMANUS: OK. AUDIENCE: --as well
as test failure due to equipment issues, for
example lack of maintenance, more training required,
and a protocol that just would make the
process less efficient. HUGH MCMANUS: Right. So the rework issue
from diagnostics is easy to understand. What was the issue with triage? AUDIENCE: So we
potentially were thinking that we could start
cross-training staff between registration and
triage because this might just be a step that we
don't need necessarily. HUGH MCMANUS: OK,
so you think there's some inefficiency there. AUDIENCE: Well, in
triage, the doctor was seeing levels of care
that were either too easy, they could have been managed
by triage to either discharged to home or sent to the hospital
without ever seeing the doctor. So he could have seen fewer
patients if triage was-- HUGH MCMANUS: OK, so triage
was feeding unnecessary work to the doctor. OK. You folks? What's your top two? AUDIENCE: We think one of them
is too much patient movement, having them shuttle back and
forth to the waiting room. It created a lot of
confusion for all areas in that we didn't know where
they were supposed to go next. So that kind of covered
actually a couple of them. We also have the inefficient
registration triage system and also the [INAUDIBLE]
information flow, where the chart was getting
separated from the patient and going to the chartroom
in between each time. And really one way
to solve that would be keep the chart
with the patient as they move through the system. HUGH MCMANUS: So
you focused more on the detractors
for the bottleneck, while you guys are focusing
more on the overall process issues of the confusion of
having the patient moving. These are both valid. It's interesting that folks
are getting kind of different-- so who wants to
speak for this table? AUDIENCE: So we also
agreed with them, so I won't reiterate that point. But one minor thing
that we noticed is we had a lot of unused
capacity in diagnostics. HUGH MCMANUS: OK. AUDIENCE: And we had a
backup with the physician. And the physician
didn't have a method of choosing which
patient to see next. So we set up a signal system
whereby any unused device would be set in front of
the eyes of the physician so that she could pick the
right patient to see next instead of running back
over to diagnostics. HUGH MCMANUS: Yeah, OK. AUDIENCE: [INAUDIBLE] HUGH MCMANUS: So looking at
the outflow from the physician, making sure that patients didn't
have to wait on the other end, as well. Yeah? EARLL MURMAN: That's a
really good instance of pull. HUGH MCMANUS: Yes, yep. EARLL MURMAN: OK, you can see
what the diagnostics could use. And they really have
something set up almost like a [? combine. ?] HUGH MCMANUS: It's almost like
a [? pull ?] [? combine, ?] yep, that, yeah, the patient is
pulled into diagnostic based on the availability.
