So, What Is Your Problem?

Loading...

En provenance du cours de Johns Hopkins University

Taking Safety and Quality Improvement Work to the Next Level (Patient Safety VII)

13 notes

Explorer les vidéos de cours associées

Vous trouverez chez Coursera les meilleures vidéos de cours du monde. Voici quelques-unes de nos recommandations personnalisées pour vous

Johns Hopkins University

Taking Safety and Quality Improvement Work to the Next Level (Patient Safety VII)

13 notes

Cours 7 sur 7 dans Specialization Patient Safety

In this culminating course in the Patient Safety and Quality Improvement Specialization, you will apply the skills you have acquired across the previous six courses to address a realistic patient safety issue confronting Mercy Grace, a 500-bed urban hospital that is part of a larger hospital system. Based on the scenario provided, you will assess the situation and work through the problem using a variety of tools and strategies. You will have the opportunity to identify defects, root causes, and potential mitigation strategies; you will create a project implementation plan for addressing the issue in the form of an A3; you will identify risks of project failure and design a change management plan; you will identify means of converting the project from local to system-wide; and you will identify quality and safety measurements that will be used in evaluating the success of the project’s implementation.

À partir de la leçon

Problem-solving and Proposing Interventions

In this module, you will build upon what you learned in the previous module by continuing your investigation of patient falls and clarifying your project goals. You will review content from previous courses in the specialization that discussed problem identification, scoping your project, building an A3, and specifying performance measures. You will then initiate a first draft of an A3, and complete a first draft of a 5-Whys Table.

Module 2 Introduction1:02

So, What Is Your Problem?10:33

Building Your A35:40

Specifying Performance Measure and Common Data Sources for Measurement10:45

Rencontrer les enseignants

David Schwartz
Instructional Design Technology Manager
Armstrong Institute for Patient Safety and Quality

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 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 where is the problem specifically.

It helps in turn to 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 could 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't go it alone.

So, by defining the problem,

if you do it well,

you're going to have others knocking on

your door willing to help you resolve this problem.

You need to later understand whether that problem was

fixed or mitigated or 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 out of,

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 know always now.

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 kick the tires if you will and I was talking to him and he said,

before we go any further,

I know what the problem is.

The problem is rooted in registration.

Our registration is killing us.

We need to get that fixed.

That's okay but do you mind if we look at

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

He reluctantly said, "Yes,

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 percent 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 back seat 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's 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 indebted.

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,

his 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 a 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 a possibly with your champion,

and then show it to a few other people that are stakeholders that process.

Remember that Sitepack tool,

this is a tool called Sitepack.

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 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.

Explorer notre catalogue

Rejoignez-nous gratuitement et obtenez des recommendations, des mises à jour et des offres personnalisées.

Coursera propose un accès universel à la meilleure formation au monde, en partenariat avec des universités et des organisations du plus haut niveau, pour proposer des cours en ligne.

© 2019 Coursera Inc. Tous droits réservés.

Télécharger dans l'App Store

Disponible sur Google Play