NR-709A · Week 3 of 8 · Assembling data and testing its integrity

NR-709A Week 3 Data Assembly and Integrity: How to Write It

The short answer

Roughly a third of the way into an evaluation term the data stops being a plan and becomes a file, and the written task turns to assembly and integrity: what you pulled, from where, over what period, what was missing, what was duplicated, what changed inside the system during your measurement window, and what you did about each of those. This is the methods section of a doctoral project report, and it is graded on whether a reader could follow your handling well enough to trust the numbers that come next. Your section may print this as NR 709A or NR709A; 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 709A Week 3 grading scale at Chamberlain, the criterion levels this assessment is scored on, from Chamberlain Tutors
How Chamberlain grades NR 709A Week 3, visualized by Chamberlain Tutors.

What NR-709A Week 3 asks for

Why do clinic numbers jump for reasons that have nothing to do with care? A county program running blood pressure follow-up out of two neighborhood sites saw its documented follow-up rate rise sharply in a single month, and the change had a completely non-clinical explanation: a system update had moved the follow-up field from a free-text note into a structured checkbox, and the standing report suddenly began finding entries it had previously missed. Nothing about the care had changed that month. Everything about the measurement had. An evaluation that had not noticed would have reported an impressive improvement and attributed it to a project.

This stage teaches you to find those seams before they become conclusions. Real clinical data is messy in specific and recognizable ways: fields that are optional and therefore incomplete, patients who appear twice under two records, encounters coded by a template that changed, staff turnover that shifts documentation habits, and periods where a workflow was suspended for reasons nobody wrote down. The written product is a methods account that tells the truth about all of it, and doctoral readers regard that account as a direct signal of how much weight the results deserve.

Expect a deliverable that documents your data handling, sometimes as a methods section of the growing project report and sometimes as a standalone data plan or progress paper. The tone should be plain and procedural. This is not the place for argument; it is the place where a reader learns whether your later argument stands on anything.

The boundary that governs this manual. Practicum hours, hour logs, encounter counts, preceptor evaluations, signatures and site documentation are your own record and your site's, never drafted, reconstructed or estimated with help from anyone, and no one should perform or document clinical activity on your behalf. What can be supported is the written layer around real work you did: describing a data process accurately, structuring a methods account, presenting figures honestly and writing analytically. Every patient detail is de-identified before it enters your writing, and the site is described by type and size rather than named.

The NR-709A Week 3 method, step by step

Seven moves for assembling an evaluation data set you can defend.

  1. Pull once, save the raw extract, and never edit it

    Keep the original file untouched and do all cleaning in a copy or a script. When a figure is questioned four weeks later, the ability to go back to the unmodified pull is what lets you answer instead of guessing.

  2. Count everything before you clean anything

    Record how many rows arrived, over what date range, and how many unique patients or encounters they represent. That starting count anchors every subsequent statement about what was removed and why.

  3. Keep a cleaning log with a line per decision

    Date, what you found, what you did, how many records it affected. Duplicates merged, test records removed, an implausible value corrected or excluded. The log becomes your methods section almost verbatim and it cannot be reconstructed from memory.

  4. Characterize missingness rather than deleting it

    Ask how much is missing, in which field, and whether it clusters by month, site, clinician or patient group. Missing data that clusters is telling you something about the workflow, and that finding often matters more than the value that is absent.

  5. Look for system and template changes inside your window

    Ask the people who maintain the record system whether anything changed: an upgrade, a template revision, a new required field, a report rebuild. Then plot your measure by month and look for step changes that align with those dates rather than with your implementation.

  6. Check the denominator's stability month to month

    A denominator that swings by a third between periods is usually a definition problem or a real change in who is being seen, and either way it has to be explained before any rate built on it can be interpreted.

  7. Write the data flow as a sequence a reader can follow

    Records pulled, records excluded at each step with the reason and the count, records analyzed. Presented as a short numbered sequence or a simple figure, it does more for credibility than any other paragraph in the methods.

A layout and word budget for a data and methods account

Our frame for the data handling section of an evaluation report, sized for roughly 1,100 to 1,400 words. It is our own outline rather than anything the university issues, and your week's rubric outranks it wherever the two disagree.

SectionWhat belongs in itWord target
Sources and extractionEach system or report, who ran it, on what date, covering what period, at what level of aggregation.170 to 210
Starting countsRows, unique patients or encounters, and the date span, stated before any exclusion is applied.100 to 130
Cleaning decisionsEach decision with what was found, what was done, how many records it touched and why.210 to 250
Missingness describedWhich fields, how much, and whether the absence clusters by period, site, role or patient group.180 to 220
System changes in the windowUpgrades, template revisions or report rebuilds, with dates and their likely effect on the measure.150 to 190
Data flow summaryThe path from records pulled to records analyzed, with counts at every step.140 to 170
Integrity limitationsWhat the data cannot support, stated plainly before any results are presented.150 to 190

Evidence craft for a defensible methods account

Write in a way that permits replication, not in a way that reassures. Data were reviewed for accuracy tells a reader nothing. Fourteen duplicate encounter rows were identified by matching on encounter identifier and removed, leaving 1,208 encounters is a sentence somebody could reproduce, and it earns trust precisely because it is checkable.

Report every exclusion count, including the embarrassing ones. If a third of the records lacked the field your numerator depends on, that number belongs in the paper in plain sight. Concealed exclusions are the most damaging thing a reader can discover later, and disclosed ones frequently turn out to be the most interesting finding in the evaluation.

Attribute the reporting guidance you are following. Published reporting frameworks exist for improvement work and they specify what an evaluation account should contain. Naming one and following its structure gives your methods a defensible shape and demonstrates that you know the genre has standards, which is exactly the doctoral signal.

Distinguish a data artifact from a clinical change in your language. When a rate moves at the same moment a field changed, describe both and say which you believe explains it and why. Presenting an artifact as an effect is the single most common way an otherwise careful evaluation reaches a wrong conclusion.

Handle protected information the way your site requires. Work with de-identified or minimum-necessary extracts, store them the way your organization directs, keep nothing identifiable in your academic files, and describe the setting by type and volume. Where a single case illustrates a data problem, reduce it to the structural detail and remove everything else.

Five mistakes that cost points in this week's territory

  • Cleaning in the original file. Once the raw pull is overwritten, no discrepancy can be traced and no figure can be defended.
  • Missing data deleted silently. Dropping incomplete records without reporting how many or checking whether they cluster changes the population you are describing.
  • No counts at each step. A methods account without numbers is a description of intentions rather than of what happened.
  • Ignoring system changes. An unnoticed template or report change inside the measurement window can manufacture an improvement out of nothing.
  • Limitations saved for the end. Integrity problems that shape the results belong before the results, not in a closing paragraph after the reader has already believed them.

Before you submit

  • The raw extract is preserved unmodified and its pull date is recorded
  • Starting counts appear before any exclusion
  • Every cleaning decision is logged with its reason and record count
  • Missingness is quantified and checked for clustering
  • System, template or report changes in the window are identified with dates
  • Denominator stability across periods is examined
  • A data flow from records pulled to records analyzed is presented
  • Integrity limitations appear before the results
  • No identifiable information appears in any file that leaves the site

Writing the methods section for NR-709A?

Send the rubric and your cleaning log out of Canvas. A premium original draft comes back in 24 to 48 hours with counts at every step, missingness characterized rather than dropped, and limitations placed where a reader can weigh them, and revisions run until the grade lands.

Questions students ask about this stage

A quarter of my records are missing the key field. Is the evaluation ruined?
Not ruined, but the paper has to change shape. First find out whether the missingness is patterned: does it concentrate in particular months, particular clinicians, particular visit types or a particular site. Patterned missingness is itself a finding about the workflow and often explains part of your result, while scattered missingness is a limitation you describe and live with. Then decide and disclose your handling rule: analyze only complete records and say what that assumes, or treat missing documentation as the step not having occurred, which is defensible in some improvement contexts and must be stated. What you cannot do is drop them quietly. Report the proportion, state the rule, and add one sentence saying which direction the missingness would push your result if the assumption is wrong.
Should I do a chart audit to fill the gaps?
Sometimes, and only if you scope it to what a 128-hour term can carry alongside everything else. A structured audit of a defined sample, using a written abstraction rule and conducted by you within the access your site has granted, is legitimate and often strengthens an evaluation considerably. Plan it as its own small method: sample definition, sample size, abstraction form, and a check on your own consistency by re-abstracting a handful of records. Budget it realistically, because chart review always takes longer than estimated and this is a term with a report due at the end of it. What an audit is not is a way to reconstruct documentation that should have happened at the time. You are describing what the record shows, not adding to it.
How do I write about a data problem caused by a colleague's documentation habits?
Structurally and without individuals. Write that documentation of the step was recorded inconsistently across the period, that completion of the field varied by role, or that a workflow depended on a step no protocol required, and let those sentences carry the analysis. Naming or implicating a person adds nothing you need and creates a real problem in a document that circulates at your site. Frame it as a system property, because that is both accurate and useful: a change that depends on individual habit rather than on a designed workflow is fragile by construction, and that observation belongs in your sustainability thinking later. Keep the same discipline in any figure or appendix, where a small number of clinicians can be identifiable even when unnamed.
My site changed its electronic record system in the middle of my project. Can I still evaluate?
Often yes, with the transition treated explicitly as a boundary rather than smoothed over. Establish first whether the measure is even comparable across the change, which usually means checking whether the same field and the same eligibility rule exist on both sides. If they do not, you may have two shorter series rather than one long one, and reporting them as two, with the transition marked, is honest and interpretable. If they do, run the measure separately on each side of the switch and look for a step change at the transition date. Either way the conversion itself disrupts documentation for weeks, so consider excluding a stated stabilization window with the reason given. Describe all of it in the methods, because a reader who discovers a system change you did not mention will discount everything else.

Keep going

Online now