The Donabedian Model: Structure, Process, Outcome

Almost every nursing capstone eventually has to answer one question in a way a committee can actually grade: did the intervention work, and how do you know? The Donabedian Model is the framework healthcare quality research has leaned on for that exact question since the mid-1960s, and it remains the backbone of most capstone evaluation plans today.

Avedis Donabedian was a physician and health services researcher whose 1966 paper on assessing the quality of medical care proposed sorting any evaluation of care into three linked categories: structure, process, and outcome. The insight that made it durable was not just the three categories themselves, but the claim that they are causally connected in a specific order, structure shapes process, and process shapes outcome, so a weak result at any one level usually traces back to a gap at the level before it.

That causal chain is why the model has stayed central to healthcare quality work for roughly sixty years, long after many of its contemporaries faded from use. It gives an evaluator somewhere specific to look when an outcome disappoints, rather than treating a bad result as an unexplained dead end.

This guide covers where the model came from, its three categories in detail, how they connect to each other, how to build a Donabedian-based evaluation table for your own capstone, a full worked example, common mistakes, and how the model compares to the change frameworks covered elsewhere in this cluster. For the wider landscape this model sits inside, see our nursing theory and change frameworks hub.

What Is the Donabedian Model?

The Donabedian Model sorts any evaluation of healthcare quality into three categories, moving from the conditions under which care happens to the actions taken to the results produced. Structure covers the relatively fixed inputs: staffing ratios, equipment, physical layout, policies, and the qualifications of the people delivering care. Process covers what actually happens during care delivery: the specific clinical actions, protocol adherence, communication, and clinician-patient interactions. Outcome covers the effect of all of that on the patient: health status, symptom resolution, satisfaction, complications, and, in some formulations, the patient's own knowledge and behavior change.

Donabedian's key argument was that these three categories are not just a convenient filing system, they form a causal sequence. Good structure increases the likelihood of good process, and good process increases the likelihood of good outcomes. A unit with adequate staffing and the right equipment (structure) is more likely to deliver a hand-hygiene protocol consistently (process), which in turn is more likely to reduce central-line infections (outcome). When an outcome disappoints, the model gives you a built-in diagnostic path: check whether the process was actually followed as designed, and if it was, check whether the structural resources needed to support that process were actually in place.

This is also exactly why the model is so often confused with a change theory and is not one. Donabedian never claimed to describe how to move staff from an old process to a new one, only how to categorize and measure quality once a process exists, old or new. A capstone that wants to both implement a change and evaluate it needs a change framework for the first job and the Donabedian Model for the second.

Because the three categories are broad by design, the model scales from a single-unit BSN capstone measuring one process change to a system-level DNP project touching staffing, protocol, and multi-site outcome data, without needing a different model at each level.

The 3 Categories at a Glance

Applying the 3 Categories Step by Step

Why the Process-Outcome Link Matters

The single most important move in a Donabedian-based evaluation plan is making the process-outcome link explicit, rather than reporting an outcome in isolation and hoping the reader assumes causation. A capstone that simply states "the readmission rate fell" after an intervention leaves an obvious gap: fell compared to what, and why should the reader believe the new process caused it rather than something else happening on the unit during the same period?

A stronger write-up names the specific process measure, reports it alongside the outcome measure, and makes the mechanism explicit: compliance with the revised discharge-teaching checklist (process) rose from 58 percent to 91 percent over the pilot period, and 30-day readmissions for the same patient population (outcome) fell from 14 percent to 9 percent over that same window. The process number is what gives the outcome number its credibility, because it shows the mechanism actually operated, not just that the headline result happened to move in the right direction.

This is also where our nursing capstone evaluation plan guide is useful alongside this one: that guide covers how to structure the evaluation plan section itself, including logic models, SMART outcomes, and evaluation timelines, while the Donabedian Model gives you the specific three-category content that fills that structure in.

Committees reading a results section built this way tend to respond well, because the process-outcome link preempts the most common defense question in a proposal or dissemination meeting: "how do you know this was the intervention and not something else?" Having the process measure already reported gives you a direct answer instead of an appeal to the outcome number alone.

Building a Donabedian Evaluation Table for Your Own Capstone

A simple way to apply the model is to build a three-row table early in your proposal, before data collection begins, naming exactly what you will measure in each category and how. Treat this table as a planning tool first and a results-presentation tool second; most of its value for a committee comes from proving you thought through the measurement plan before you started collecting data, not just after.

Filling in a table like this for your own project forces you to name a data source and a target for each category rather than leaving any one of the three as an afterthought, which is exactly the gap that weakens many first-draft evaluation sections.

A Worked Example: Reducing Catheter-Associated Urinary Tract Infections

To make the model concrete, here is how the three categories play out on a realistic capstone-style topic: a medical-surgical unit introducing a nurse-driven urinary catheter removal protocol to reduce catheter-associated urinary tract infections (CAUTI).

Structure. The unit has an electronic health record capable of generating a daily catheter-necessity flag, 1:5 nurse-to-patient staffing during day shift, and no existing written protocol allowing nurses to remove catheters without a physician order. Before the pilot, the capstone documents baseline staffing, confirms EHR flag functionality, and secures medical staff sign-off on a new nurse-driven removal order set, which becomes the structural foundation the rest of the project depends on.

Process. Once the structural piece is in place, the process measure is the percentage of flagged, eligible catheters actually removed within 24 hours of meeting removal criteria, audited weekly from EHR data rather than self-reported by staff. This is the number that tells you whether the new nurse-driven protocol is actually being used, independent of whether infection rates have moved yet.

Outcome. The outcome measure is the unit's CAUTI rate per 1,000 catheter-days, tracked against the same measure for the six months before the pilot. Reporting the process compliance rate alongside this outcome lets the capstone argue, with evidence, that any drop in CAUTI rate is plausibly linked to faster catheter removal, not simply a seasonal fluctuation or a change in testing practices.

Notice that none of the three categories stands alone. The outcome claim is only as strong as the process evidence behind it, and the process evidence is only possible because the structural piece, the EHR flag and the nurse-driven order set, was confirmed first.

Choosing the Right Kind of Outcome Measure

Not every outcome measure carries the same weight with a committee, and picking one that is too distant from your process measure is a common source of a weak evaluation chapter. It helps to sort candidate outcomes into three rough categories before settling on one.

Clinical outcomes are the most directly attributable to care and the easiest to defend: infection rates, fall rates, pressure-injury incidence, medication-error counts. These sit closest to the process measure in Donabedian's causal chain, which makes the process-outcome link easier to argue convincingly in a capstone of limited scope and timeline.

Patient-reported outcomes capture something clinical measures miss, such as satisfaction, pain control, or confidence managing a condition at home, but they are shaped by more factors outside the intervention itself, including a patient's baseline expectations and unrelated experiences during the same stay. A capstone using a patient-reported outcome should say so explicitly and acknowledge that attribution is somewhat softer than with a clinical measure.

Utilization and system-level outcomes, such as readmission rate, length of stay, or cost per case, are often the most attractive to a project's sponsor because they carry an obvious financial story, but they sit furthest from a single process change and are the most vulnerable to confounding from factors the capstone never measured, such as seasonal census swings or unrelated staffing changes during the same period. When a sponsor asks for one of these as the headline outcome, pair it with a closer clinical or process measure so the causal argument does not rest on the system-level number alone.

A well-built evaluation plan often reports one measure from each tier rather than relying on a single number: a process measure to show the intervention was actually used, a clinical outcome to show it worked at the patient level, and, where relevant, a utilization outcome to show it mattered at the unit or system level.

The Donabedian Model vs. Other Frameworks in This Cluster

Because the Donabedian Model answers a different question than the change frameworks covered elsewhere in this cluster, it is worth being precise about where each one actually fits in a capstone document rather than treating them as competing choices.

Used together rather than in place of one another, these frameworks cover the full arc of a quality-focused capstone: a change model explains how the new behavior was adopted, the Donabedian Model organizes how its quality was measured, and the evaluation plan guide shows how that measurement gets written up as a graded section.

Why Choose the Donabedian Model for Your Capstone

Reach for the Donabedian Model when your capstone centers on evaluating a quality or safety intervention and your committee expects a structured, defensible evaluation chapter rather than a single outcome claim. Its three-part structure is broad enough to apply to almost any clinical, educational, or systems-focused capstone topic, and specific enough that a committee can quickly check whether all three levels were actually measured.

It is a particularly strong fit when you can access structural and process data in addition to an outcome number, since the model's real strength is the causal chain it lets you argue, not just the outcome category by itself. A capstone that only has outcome data available is still better served by naming that limitation explicitly than by presenting the Donabedian framework and then skipping two of its three categories.

Where the model is a weaker fit on its own is for the implementation chapter, since it does not describe how to lead staff through adopting a new process. Most strong capstones pair the Donabedian Model for the evaluation chapter with a change framework, most often Lewin's Change Theory or Kotter's 8-Step Change Model, for the implementation chapter, using each model for the job it was actually built to do.

Common Mistakes When Applying This Model

• Treating the Donabedian Model as a change theory and trying to use it to describe how staff adopted the new behavior, rather than how quality was measured
• Reporting an outcome number without a paired process measure, leaving the causal link unproven
• Skipping the structure category entirely because it feels like background information rather than a measurable part of the evaluation
• Choosing an outcome measure so broad or distant from the intervention that no process measure could plausibly explain a change in it
• Building the evaluation table after data collection instead of before, which often reveals too late that a needed data source was never set up
• Assuming a strong structure guarantees a strong process, when in practice staff workload, habit, and communication gaps can still break the chain even with the right resources in place

Related Guides