Hello. Now we're going to talk about the problem affectionately known as,

so, What is Your Problem?

I could have said anyway. Defining the problem.

As I said earlier,

it starts with a problem.

Every single improvement effort begins with a problem,

otherwise, you wouldn't have to improve it.

Let's define the problem.

Why do we need to do that?

We need to have a clear,

concise statement of the problem to be able to articulate it to people,

in order to establish a common understanding.

When we define something, that's key,

we're establishing a common understanding among

the various groups of what we're going after and what is the problem specifically.

It helps in turn establish what the corresponding metrics should be,

the way we're going to measure that problem,

and what the goal is of,

what does problem resolution look like at the end?

It helps determine if the problem is the right one to work on.

Sometimes we're chasing something that's perceived to be a problem that really isn't.

So, if you can articulate the problem clearly,

people can see immediately that perhaps they can do that litmus test and say, wow,

we're not sure that really is a large problem and maybe you need some data to go after.

It helps you obtain help from others.

This is a team sport folks,

and you can go it alone.

So, by defining the problem,

if you do it well,

you're going to have others knocking your door willing to help you resolve this problem.

You need to later understand whether that problem was fixed or mitigated,

reduced in some way shape or form.

Anything you're doing is about data,

and you need to understand what the problem is to be able to then look at the metric,

then look at the goal and understand later,

was that specific problem made better, reduced.

Sometimes the problem changes over time as more becomes known.

We don't always know what we don't always know.

So frankly, it sometimes takes a little bit more data or a little bit of

evolution to understand maybe that problem wasn't exactly the problem,

maybe it was something else.

So for example, there was one clinic that

the medical director came over to me and asked me to help, and I went over,

and I kicked the tires if you will,

and I was talking to him,

and he said, "Before we go any farther,

I know what the problem is.

The problem is rooted in registration.

Our registration is killing us.

We need to get that fixed." I said okay.

But do you mind if we look at

the total process and just determine if that truly is the problem?

He reluctantly said, "Yeah,

go ahead, but I think you're wasting your time."

Well, it turns out registration wasn't the problem after all.

The problem was rooted actually in terms of the provider.

The provider taking variability in terms of the room,

how long the patients were in there,

wound up being the issue.

So again, what you think is the problem may not have been the real problem.

So over time, you have to be willing to understand that

this problem statement will shift and drift over time,

and it's not cast in stone,

that it will change most likely.

So how do we create that problem statement?

So essentially, you're stating what the current situation is.

So the problem, it's something very specific,

and sometimes we know the extent of that problem.

So, maybe our infection rate is one-half of one percent currently.

But what does that result in?

It results in something undesirable.

You want to state what that undesirable thing is.

It should answer the question of,

So What? So what?

Example: demand for IV drugs in the production pharmacy is 20% higher than last year.

Well, we stated a problem.

But how likely are you going to want to be,

if you're working with this person,

to jump in and fix it?

Maybe we need to add something to that.

We call this the Burning Platform. Let's finish that.

Leading to stress on staff,

longer work hours, and increased potential for patient harm error.

That's the Burning Platform.

So the Burning Platform, I like to say,

consists of two separate pieces,

one of which is,

what is the impact on the patient?

Sometimes there isn't any but more often than not there is.

So state what the impact is on the patient and secondarily,

state what the impact is on the staff,

because we're all here for the same reason,

to improve the quality of patients' lives,

improve the patient condition.

That's the wonderful thing about health care.

So, immediately when you're speaking in terms of what the patient is feeling,

the staff will relate to that.

But the staff will also think about,

how does this impact me?

So if you can combine both of those in one sentence,

it becomes very powerful.

We call this tugging at the head and heart.

You want to appeal to both sides.

Why work on this? Why now?

Well, we all know that quality improvement efforts do take a backseat to providing care.

Our key mission is to provide care.

And why are we perfect or close to perfect?

We just simply don't have the time to fix everything.

So, we all know that everyone is busy, overworked, stressed out.

And lately, everything is deemed to be important,

because we have to measure it, and we have to report it.

We have to measure it and report it for QI efforts.

We have to measure it and report it for outside regulatory agencies.

We have to measure it and report it for our own internal structures.

So, it's a lot of work going on.

We all know we're inundated.

So, because of that,

we need to passionately be able to

articulate not only what needs to be fixed but, doggone, why.

What's the impact to the patient and family?

What's the impact on the staff?

We call that WIIFM.

What's in it for me?

If you can clearly identify an appeal to both those stakeholder groups,

they will be knocking at the door willing to help.

So in summary, the current situation results in something undesirable,

and you want to outline exactly what that is.

So this is one of the best Burning Platforms I can remember.

And this is from a speech that President Kennedy made,

the so-called man on the Moon speech, in May 1961,

and it states, "First,

I believe that this nation should commit itself to achieving the goal,

before this decade is out,

of landing a man on the Moon and returning him safely to Earth.

No single space project in this period will be more impressive to mankind,

or more important for the long term exploration of space;

and none will be so difficult or expensive to accomplish."

Well, for those of you who weren't around in 1961 or don't remember,

we were at a critical time in this country's history.

The Soviets were winning the so-called space race,

and we were behind,

and we were scared,

and we didn't want to dedicate the money or energy or

time to doing something so trivial as to put a man on the moon.

But Kennedy, through his vision,

decided this was something that would move the country ahead and indeed it did.

Prior to that, there was no interest in it.

After the speech, it literally galvanized the nation

overnight to accomplish this and obviously, we were successful.

Problem statement do's and don'ts.

So this kind of wraps up what I just talked about.

The do's, always have others weigh in on crafting the problem statement.

So what I recommend,

is you create it possibly with

your champion and then show it

to a few other people that are stakeholders of that process.

Remember that Site Park tool.

There's a tool called Site Park.

The suppliers and the customers could be some of those folks who weigh in.

Include that compelling Burning Platform.

I think we hit that hard enough.

Keep it brief and specific,

nobody wants to read two pages of a problem statement,

keep it very specific to a paragraph.

Use words anybody can understand.

We all know in our healthcare vernacular there are a lot of words and acronyms out there.

We want to stay away from them and use things that any stakeholder can relate to,

anyone from the finance department down to the janitor.

Don't explain multiple problems,

focus on the key problem.

Select something too large,

we talked about scope earlier.

Make it all about the money,

unless it is all about the money.

If it's a finance project,

go ahead and use money as a metric.

However, anything dealing with clinical practice,

typically stay away from the money.

Usually the money comes as a result of doing some of the right things.

And the other thing is the regulatory issues.

I can't tell you how many times I've seen problem statements that

mention a joint commission requirement or something along those lines.

We want to try to stay away from those,

because those are grounded in clinical practice.

Focus on the benefit to our patient and our staff,

not so much the key metric there in terms of a regulatory issue.

That would possibly be listed as a benefit later on.

State the solution if it is a discovery approach.

So for example, if we're not sure what the solution is,

don't state what you think the solution should be in the problem statement.

Leave it open, later on the data will lead to the solution.

So, What Is Your Problem?

Planning a Patient Safety or Quality Improvement Project (Patient Safety III)

Conheça os instrutores