NR-707C Week 2 The Data Pipeline and Access: How to Write It

What NR-707C Week 2 asks for

A virtual visit queue produces four different counts of the same week depending on where you stand. The scheduling system counts appointments booked. The video platform counts sessions connected. The billing extract counts encounters closed. The nursing documentation report counts assessments filed. None of them is wrong and no two of them agree, because they were built to answer four different operational questions and none of those questions is yours. The written task at this stage is to choose one, say why, and document precisely what it counts and what it silently drops.

The boundary that governs this manual. Practicum hours, hour logs, encounter counts submitted as your clinical record, site paperwork, and preceptor or mentor evaluations are your own record of your own work, verified by your school and your organization. They are never drafted, reconstructed, or estimated with help, and no writing support of any kind reaches them. The written layer is what a manual teaches: how a data pipeline is described, how a validation pass is reported, how a limitation in the source is disclosed in scholarly prose. Anything drawn from real records enters your writing de-identified, and access to any of it follows your organization's own authorization process rather than a convenient shortcut.

There is a governance dimension here that separates doctoral writing from project writing. Using operational data for an academic deliverable is not automatically permitted because you happen to have clinical access. Most organizations have a defined route: a request, an approval, sometimes a data use agreement, sometimes a determination about whether the activity constitutes human subjects research. Your written work should describe the route you followed, with dates and roles, and should never predict or characterize an outcome that has not been issued. Describing the process accurately is a competency; assuming permission is a risk you should not be carrying.

Expect the deliverable to be a data or methods section inside a progress document, often with a table of sources, sometimes a written data management plan, and frequently a posted discussion where classmates compare the obstacles their organizations put between them and a number. Those obstacles are worth writing about analytically; they are a real feature of practice-based evaluation.

The NR-707C Week 2 method, step by step

Six analytic moves for building a data route you can defend in week eight.

1. 1. Inventory every candidate source for each measure

   List the systems that could produce the number and what each one actually counts. Choosing a source without knowing the alternatives means you cannot explain, later, why your figure differs from the one a director quotes in a meeting.

2. 2. Interrogate the logic behind any prebuilt report

   Ask whoever owns the report for its inclusion rules in writing. Dashboards carry filters, date attributions, and exclusions that nobody documents publicly, and inheriting them silently means inheriting them into your conclusions.

3. 3. Follow the authorization route and record it

   Request, approval, agreement, determination: name each step your organization requires, the role you submitted to, and the date. Describe the process rather than forecasting a result, and never begin extraction ahead of the approval you are describing.

4. 4. Validate the extract against a manual sample

   Pull fifteen to twenty-five records by a stated rule and check them by hand against the extract. Report matches and mismatches with counts. This single pass is what allows you to write that your data was verified rather than that it was downloaded.

5. 5. Specify refresh, lag, and the freeze date

   Operational data changes retroactively as documentation completes and coding lands. State the lag, then name the date on which you will freeze the dataset for analysis, so that your week six figure and your week eight figure are the same figure.

6. 6. Document handling, storage, and disposal

   Where the file lives, in what form, who else can reach it, whether any linking information exists, where that linking information stays, and what happens to all of it when the block ends. Write this before the first extract rather than after.

A layout for a data pipeline write-up

Our frame for this stage's methods section, sized for roughly 1,200 to 1,500 words plus a source table. It is our own outline rather than anything the university issues, and your week's rubric outranks it wherever the two disagree.

Evidence craft for data and methods writing

Describe the source as a stranger would need it. Name the system, the report or query, the fields used, and the date range. A methods section that says data were obtained from the electronic health record has told the reader nothing they could check or reproduce, and reproducibility of process is one of the few research virtues that transfers cleanly into improvement work.

Report validation as numbers, not as reassurance. Twenty records checked, seventeen matching, three mismatched because the extract attributed the encounter to the scheduling date rather than the service date, is a validation. Data were reviewed for accuracy is a sentence that survives no scrutiny at all.

Say what the pipeline cannot see. Attempted contacts that never connected, care delivered and documented elsewhere, patients who were eligible but never entered the queue: every operational data source has a population it never records. Naming those absences in the methods rather than the discussion is the doctoral ordering.

Keep improvement evaluation distinct from research. You are assembling operational data to evaluate a local change. The write-up should not adopt the vocabulary of a trial or imply the design protections of one. Where your organization requires a determination about human subjects oversight, describe the process followed and its date, without characterizing an outcome.

Protect identifiers structurally, not just editorially. De-identification is a decision about what you extract, not only about what you type. Request the minimum fields necessary, keep any identifier that must exist inside your organization's systems rather than in an academic file, and state that rule in the methods so a reader knows it governed the whole block.

Five mistakes that cost points in this week's territory

• Inheriting a dashboard's logic unexamined. If you cannot state the report's inclusion rules, the report is stating your conclusions for you.
• No validation pass. Unverified extracts are the single most common reason a results section collapses when someone at the site reads it.
• Extracting before the approval route is complete. Convenience of access is not authorization, and the distinction is one your program takes seriously.
• No freeze date. Retroactive completion means the same query run twice returns two answers, and a document with drifting numbers cannot be defended.
• Silence about what the data misses. A reader who identifies an invisible population you never mentioned discounts everything else you wrote.

Before you submit

• Each measure names its source system, report or query, fields, and date range
• Inherited report logic is documented from the report's owner
• The authorization route is described with roles and dates, without predicting outcomes
• A validation pass is reported with counts of matches and mismatches
• Refresh lag and an analysis freeze date are stated
• Storage, access, linking information, and disposal are all specified

Questions students ask about this stage

Keep going