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.