Driver Diagrams: Linking an Aim Statement to Change Ideas

A driver diagram is a one-page map of a quality improvement team’s theory of change: a measurable aim on the left, the small number of primary drivers that theory says will move that aim, the secondary drivers that break each primary driver into workable pieces, and the specific change ideas the team will test — usually through PDSA cycles — against each secondary driver. It answers a question a fishbone diagram cannot: not “what caused the last event” but “what, in what order, do we believe will fix the pattern going forward.”

The four parts, in the order they’re built

1. Aim

The single box the whole diagram points toward. It should be specific, numerical, and time-bound in the same way an aim statement for a PDSA project has to be — not “reduce catheter-associated infections” but “reduce CAUTI rate on the medical-surgical units from 1.8 to below 1.0 per 1,000 catheter-days by the end of Q3.” A vague aim produces a driver diagram no reviewer can actually falsify, because there’s no number to check the drivers against later.

2. Primary drivers

The small number — most published guidance recommends two to five — of high-level factors the team’s theory says most directly determine whether the aim is met. Primary drivers come from process mapping, from the team’s own front-line knowledge of the work, and, when one exists, from a prior root-cause or common-cause analysis of the same problem. They are not actions; they are the levers an action would pull. “Timely catheter removal,” “insertion technique,” and “surveillance accuracy” are primary drivers for a CAUTI aim — none of them is a task anyone can be assigned on Monday.

3. Secondary drivers

Each primary driver breaks into several secondary drivers — the more specific mechanisms or subsystems that make the primary driver move. Under “timely catheter removal,” secondary drivers might include a daily nurse-driven removal protocol, an EHR reminder tied to catheter-days, and physician order defaults that expire rather than renew automatically. This is the layer where the diagram stops being a theory and starts pointing at real workflow.

4. Change ideas

The specific, testable interventions attached to each secondary driver — the things that actually become a PDSA cycle. “Add a catheter-necessity checkbox to the daily nursing flowsheet” is a change idea; “improve documentation” is not, for the same reason a vague aim isn’t a real aim. A single secondary driver commonly carries several competing change ideas, tested one at a time or in small combinations, with the ones that move the measure kept and the rest discarded.

A worked example

The following is an illustrative composite, not a real hospital’s actual driver diagram, built to show how the four layers connect:

Notice each change idea is small enough to run as a single PDSA cycle, and each secondary driver has a measure attached — usually a process measure the team can move within weeks, which is what makes the primary driver, and eventually the aim, move on a longer timescale.

Building one

1. Write the aim first, alone. Don’t sketch drivers until the aim box has a number and a date in it.
2. Draft primary drivers from evidence, not brainstorming alone. A process map of the current state, existing quality measures already being tracked, and any recent root-cause or common-cause findings on the same problem should shape the primary-driver list before the team free-associates.
3. Push each primary driver down to secondary drivers until they describe a specific mechanism or workflow, not a restatement of the primary driver in different words.
4. Attach at least one measure to each secondary driver — usually a process measure — so progress is visible before the aim measure itself moves.
5. Generate multiple change ideas per secondary driver and expect to discard most of them; a driver diagram with exactly one change idea per box is usually a plan dressed up as a theory.
6. Revise the diagram as cycles report back. A driver diagram is a working document, not a poster — a change idea that fails a PDSA cycle should prompt a new one, and a primary driver that never moves the aim after several honestly-tested change ideas is a signal the underlying theory is wrong, not that the team needs to try harder on the same driver.

How it feeds PDSA cycles

The driver diagram and the PDSA cycle are not competing tools — the diagram is where a team decides what to test, and PDSA is how each of those change ideas gets tested, one small, time-boxed cycle at a time. In practice, a change idea box on the driver diagram becomes the “what change can we make” answer for a specific PDSA cycle; the outcome of that cycle (adopt, adapt, or abandon) feeds back into whether the secondary driver it sits under actually belongs on the diagram. Teams that build an elaborate driver diagram once and never touch it again usually also have PDSA cycles running in isolation from any larger theory — the two failures tend to travel together.

The driver diagram as programme theory for reporting

Beyond planning the work, a driver diagram does a second job that is easy to miss: it is close to a ready-made answer to what a SQUIRE 2.0 writeup requires. SQUIRE’s Introduction section calls for “a rationale grounded in the local context” and “the specific aim(s) of the intervention,” and its Methods section calls for “a full description of the intervention(s)” and the process, outcome, and balancing measures used to evaluate it. A driver diagram that was actually used to run the project already contains the aim, the theorized mechanism connecting the intervention to that aim, and — if measures were attached at the secondary-driver level as recommended above — most of the measurement description SQUIRE’s Methods section expects. Teams that build the diagram only after the fact, to satisfy a reviewer, tend to produce a tidier-looking but less honest one than the version that was actually revised in real time as change ideas succeeded or failed.

Common mistakes

• An aim with no number or date. “Improve patient safety” cannot be checked against a driver diagram three months later.
• Primary drivers that are really change ideas in disguise. “Add a checklist” is a change idea, not a driver — it belongs several boxes to the right.
• No measure below the aim level. Without process measures on the secondary drivers, a team only learns whether the project worked at the very end, defeating the point of testing small changes early.
• Treating the diagram as final on day one. A driver diagram drawn once at kickoff and never revised as cycles report results is a planning artifact, not the working theory of change it’s meant to be.
• Confusing it with a fishbone diagram. Using a driver diagram to catalogue everything that might have contributed to a past event, instead of what the team plans to change going forward, collapses two distinct tools into one that does neither job well — see fishbone diagrams for the retrospective counterpart.

Frequently asked questions

How many primary drivers should a driver diagram have?

Most published quality-improvement guidance recommends two to five. Fewer than two usually means the aim hasn’t been analyzed deeply enough; more than five usually means some of the boxes are secondary drivers that got promoted a level too high.

Is a driver diagram the same as a key driver diagram?

Yes — “key driver diagram” and “driver diagram” refer to the same tool; “key” emphasizes that only the drivers judged most important to the aim are included, which is already the intent of the primary-driver layer.

Do secondary drivers always need their own measure?

Not strictly required, but strongly recommended for any secondary driver carrying more than one change idea — otherwise the team has no way to tell which change idea is actually responsible when the primary driver eventually moves.

Can a driver diagram change after the project starts?

It should. A driver diagram that predicts a primary driver will move the aim, and then repeated, honestly-tested change ideas under that driver fail to move it, is evidence the underlying theory needs revision — that’s a working diagram doing its job, not a sign the original one was drawn wrong.

What’s the difference between a driver diagram and a logic model?

Both display a theory of change, but a driver diagram is built specifically to generate testable change ideas for rapid-cycle PDSA testing, while a logic model (common in program evaluation and grant reporting) more often maps inputs, activities, outputs, and outcomes for a whole program over a longer, less iterative timescale. A driver diagram can sit inside a broader logic model as the detail behind a program’s “activities” layer.