NR-702B · Week 7 of 8 · Evaluation design and the data plan

NR-702B Week 7 Evaluation Design and Data Plan: How to Write It

The short answer

Near the end of a project practicum the plan has to say how anyone will know whether the change did what it was supposed to do. A quality improvement evaluation is not a trial: it watches a small set of measures over time, expects to explain variation rather than test a hypothesis, and treats delivery as something to be measured rather than assumed. The written work is a design plus a data plan concrete enough that someone else could run it while you are on leave. Your section may print this as NR 702B or NR702B; it is the same course. Chamberlain publishes no syllabi outside Canvas. The placement here is our teaching judgment from the course's catalog arc; your section's rubric decides what your week actually asks.

NR 702B Week 7 grading scale at Chamberlain, the criterion levels this assessment is scored on, from Chamberlain Tutors
How Chamberlain grades NR 702B Week 7, visualized by Chamberlain Tutors.

What NR-702B Week 7 asks for

What question does an evaluation actually have to answer? Usually two at once: did the thing get done, and did anything change as a result. A correctional health clinic introducing a structured intake screening step will find that these come apart immediately. If the screening rate rises from almost nothing to most eligible intakes but the downstream referral completion does not move, that is not a failed project; it is a delivered intervention meeting a second barrier further along the pathway. An evaluation designed only around the downstream outcome would have reported failure and learned nothing. The design writing at this stage is largely about building in the capacity to tell those two situations apart.

The second demand is a data plan that survives an ordinary week. Every measure needs a source, an owner, a frequency, a storage location and a de-identification step. Plans that say data will be collected weekly, without naming who does it and from where, are the ones that produce three weeks of data and a gap. The deeper hour load in a three-credit block gives you the room to test the retrieval before you commit to it: run the query once, see what the field actually contains, discover that the checkbox is used inconsistently, and design around it while there is still time.

Third, the analysis has to match the data you will actually have. Improvement data is serial, operational and often small. Displaying it over time with a stated rule for what counts as a signal is usually more informative and more honest than a comparison of two aggregate periods, and it is far more defensible than a significance test applied to a handful of encounters. Choosing the analysis to fit the data rather than to look rigorous is itself a scored competency at doctoral level.

The boundary that governs every page in this manual. Clinical hours, hour logs, encounter counts, preceptor evaluations, site documentation and signatures are the student's own record and are never drafted, reconstructed or estimated with help. No tutor extracts data, reviews charts, or documents clinical activity on a student's behalf. Support is written only: defining measures precisely, structuring a data plan, and describing analysis in prose. Every patient detail must be de-identified, and small-cell results should be aggregated so that no individual patient or staff member can be identified from them.

The NR-702B Week 7 method, step by step

Seven moves for an evaluation design that fits a site-level improvement project.

  1. Write the evaluation question before the measures

    One sentence saying what decision the data will inform and for whom. Measures chosen before the question tend to be the ones that are easy to obtain rather than the ones that answer anything.

  2. Carry the outcome definition across verbatim

    Copy it from your baseline section rather than rewriting it. A single changed word between the baseline and the evaluation invalidates the comparison the entire project rests on.

  3. Add a process measure with a fidelity threshold

    The proportion of eligible cases in which the specified step actually happened, and the level you decided in advance would count as delivered. Without it, a flat outcome cannot be interpreted.

  4. Choose a balancing measure aimed at a named harm

    Longer intake time, a displaced task, a delay elsewhere in the pathway. Pick the consequence you consider most plausible and measure that, rather than a general satisfaction score that will show nothing.

  5. Test the data route once before committing to it

    Run the query, pull the report, open the field. Discovering that the value is free text, or that it is only completed by one team, changes your plan and is much cheaper to find now than in week three of implementation.

  6. Set the observation rhythm and expected volume

    Weekly or biweekly points if volume allows, and the number of eligible cases each point should contain. Points built on two or three cases will swing wildly, and knowing that in advance shapes how you will display them.

  7. Pre-commit to interpretations

    Write now what you would conclude under each combination of process and outcome results. Deciding in advance is what prevents an evaluation from becoming an exercise in explaining whatever happened.

A layout and word budget for an evaluation design

Our frame for this deliverable, sized for roughly 1,400 to 1,700 words. It is our own outline rather than anything the university issues, and your week's rubric outranks it wherever they disagree. If a measures table is required, definitions live in the rows and the prose around it shortens.

SectionWhat belongs in itWord target
Evaluation questionThe decision the data informs, who will use it, and by when they need it.110 to 140
Design chosenThe evaluation approach, its logic, and what it can and cannot rule out at a single site.180 to 220
Measure setOutcome, process and balancing measures, each with an operational definition and a source.320 to 380
Data planOwner, frequency, extraction route, storage, de-identification and what happens to working files.230 to 280
Display and analysisHow data will be presented over time, the signal rule, and any statistical treatment with justification.220 to 270
Interpretation scenariosWhat each pattern of process and outcome results would mean and what you would recommend.200 to 250
Reporting to the siteWho receives findings, in what format, and how the results feed back into practice rather than a file.140 to 180

Evidence craft for evaluation writing

Draw on improvement reporting standards, not trial reporting standards. Published guidance exists for describing quality improvement work, and naming it signals that you understand what kind of study you are running. Borrowing trial vocabulary for a site-level project is the most common category error at this stage and it is easy for a reader to spot.

Report counts alongside every proportion. Twenty-two of 58 eligible intakes, not thirty-eight percent. With small denominators, a two-case difference can look like a large swing, and only the base lets a reader see it.

Keep causal claims proportionate to the design. A single-site before-and-after comparison supports language about change coinciding with implementation. It does not support caused, proved or demonstrated. This restraint is graded, and overreach undoes an otherwise careful plan.

Describe data stewardship concretely. Where the working file lives, who can open it, how identifiers are removed and when the file is destroyed. Improvement work carries the same duty of care as any other handling of health information, and stating it is expected rather than optional.

State the review pathway without asserting its result. Name the determination process your program and site use and what you will submit. Do not claim in advance that a project will be classified in a particular way or that approval is assured, since those determinations belong to the reviewing bodies.

Five mistakes that cost points in this week's territory

  • An outcome measure standing alone. Without a process measure, a null result cannot be told apart from an intervention that was never consistently delivered.
  • Definitions that drift from the baseline. Any wording change between sections makes the before and after comparison unusable and is trivially avoidable.
  • Two aggregate periods instead of a series. Comparing one lump to another throws away the pattern that improvement data carries and hides ordinary variation.
  • A data plan with no owner. Passive collection language guarantees gaps once a clinic gets busy, which is usually the second week.
  • Interpretations written after the fact. Deciding what results mean once you have seen them invites the reader to wonder what other reading was available.

Before you submit

  • The evaluation question names a decision and the person who will use it
  • The outcome definition matches the baseline definition word for word
  • A process measure carries a pre-set fidelity threshold
  • The balancing measure names the specific harm it watches
  • Every measure has an owner, a frequency, a route and a storage location
  • The data route was tested once before the plan committed to it
  • Display method and signal rule are stated before any analysis
  • Interpretations for at least three result patterns are written in advance

Designing the NR-702B evaluation?

Send the rubric and your measure definitions out of Canvas. A premium original draft comes back in 24 to 48 hours with a measure set that holds together, a data plan someone else could run and analysis sized to your real denominators, and revisions run until the grade lands.

Questions students ask about this stage

How do I evaluate an outcome that will not move inside my timeline?
Choose an intermediate outcome on the same causal pathway and say explicitly why it stands in for the distal one. Many worthwhile changes affect events that take months or years to appear, and no eight-week window will show them. What the window can show is whether the step is being delivered, whether the intermediate marker responds, and whether the pathway is behaving as the evidence predicted. Write the logic as a chain: the intervention affects this proximate measure, which the literature associates with the distal outcome, which cannot be observed within this project. That chain is honest, it is checkable against your synthesis, and it gives a committee a reason to accept a proxy. What fails is presenting a proximate measure as though it were the outcome anyone actually cares about.
Is a survey of staff a legitimate measure?
It can be, for the right question, and it is frequently used for the wrong one. Staff report is a reasonable way to assess acceptability, perceived burden and whether a workflow feels sustainable, all of which matter for a change you hope will outlast the project. It is a poor substitute for whether the step was actually performed, because recall and social pressure both distort it, and a record-based process measure is nearly always available instead. If you use a survey, say whether the instrument is published and validated or written by you, keep it short enough that busy clinicians complete it, describe how responses stay anonymous in a small team, and be realistic about response rates. Two or three well-chosen items answered by most of the staff beat a twenty-item questionnaire answered by four people.
Can someone else pull my project data or help build the dataset?
No. Clinical data extraction happens under your own access and your site's authorization, and nobody outside that arrangement can query records, review charts or assemble encounter-level data on your behalf. The same applies to anything the university or a preceptor verifies. What written support can legitimately do is everything made of words: sharpening measure definitions so they are unambiguous, structuring the data plan so it is followable by a colleague, describing the analysis approach accurately, and later presenting findings clearly to a practice audience. Any figures in a draft prepared with writing support are figures you provided, already de-identified and aggregated, and you should be able to check each one against your own source.
What if the process measure is high but nothing else moves?
That is a genuine and reportable finding, and it is one of the most useful things a doctoral evaluation can produce. High fidelity with no outcome change tells you the intervention was delivered as specified and did not produce the expected effect here, which points at three possibilities worth writing about: the effect exists but is smaller than your window or denominator can detect, the mechanism that worked in the study settings does not operate in yours, or the barrier limiting the outcome sits somewhere else on the pathway. Say which explanation your data supports and what would test it. Write it in the same measured language you would use for a positive result. Committees respect an honest null with a clear interpretation considerably more than a strained argument that something worked.

Keep going

Online now