NR-706 opens by asking you to name a decision that is currently being made without adequate information, and to argue that the shortfall is an informatics problem rather than a staffing or motivation problem. That is a harder opening than it sounds, because most nurses describe technology first and the decision second. A doctoral reader wants the order reversed: who decides, how often, on what evidence, and what the missing data is costing. Your section may print this as NR 706 or NR706; 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.
What NR-706 Week 1 asks for
A chart audit is the scene that makes this stage concrete. Picture a quality specialist pulling forty records to see whether a sepsis screen was completed within the required window, and finding that in eleven of them the screen was done and the result lives in a nursing note rather than in the flowsheet field the report reads. Nothing clinical failed. The information failed to travel. That gap between work performed and work visible is the native territory of healthcare informatics, and the opening written work in this course usually asks you to find one such gap in a setting you actually know and describe it precisely enough that a reader could go look for it.
At doctoral level the framing has to carry organizational altitude. You are not writing about your own frustration with a screen. You are writing about a decision made by a role on a schedule, using data produced by other roles under time pressure, and about what happens downstream when that data is late, incomplete or ambiguous. The unit of analysis in this course is the information flow, not the software. A grader reading an opening paper is deciding whether you can see a system where most clinicians see an inconvenience.
Deliverables in an opening stage are usually modest and diagnostic. A short written analysis, a posted introduction that names the problem you intend to work on for the session, or both. Whatever the format, treat the first submission as the place where you commit to a problem you can sustain for eight weeks, because the later stages in an informatics course tend to build on the same setting. If your section runs a discussion this week, write it as final copy: posts do not reopen after submission in Canvas, and an opening post that describes an electronic record generically tells your grader you have not yet learned to look at data paths.
One more thing this stage rewards, and it is the difference between a passing paper and a strong one. Say what the current information actually supports before you say what it fails to support. A charge nurse deciding staffing at seven in the morning is not working blind; she is working from a census, an acuity tool and twenty years of pattern recognition. Naming what already works is what makes your claim about the gap credible rather than dismissive, and doctoral graders read dismissiveness as inexperience.
The NR-706 Week 1 method, step by step
Six moves that turn a complaint about a system into a defensible informatics problem statement.
-
Reduce the rubric to its verbs before you choose a setting
Copy each scored row into a blank file as a heading and strip it to the verb it demands. Analyze, evaluate, synthesize and propose sit at different depths, and an opening row that says evaluate is telling you that a description of your unit will not clear it no matter how detailed.
-
Start from a decision, not from a system
Write one sentence naming the role that makes the decision, the interval on which it is made, and the action that follows. Discharge readiness decided by the attending on morning rounds. Escalation decided by the charge nurse each shift. The sentence has to survive a reader asking who and when.
-
Trace the data element from creation to consumption
Name the field where the element is captured, the person who captures it, what else that person is doing at that moment, and every hop between that field and the screen where the decision maker sees it. Most informatics failures live in the third item.
-
Quantify the gap with counts and denominators
Convert your impression into a number you could defend. Eleven of forty audited records is evidence. Often is an adjective. If you do not have a count, say what audit would produce one and how long it would take.
-
Rule out the non-informatics explanations in writing
Test your gap against the alternatives a systems reader will raise: is it a training gap, a staffing gap, a policy ambiguity or a culture problem wearing a technology costume. Naming and dismissing two rivals is what earns the word analysis.
-
Close on a problem statement that scopes the session
One paragraph that names the setting, the decision, the data gap, the measured or estimated size of it, and the boundary of what you will address. A statement broad enough to include everything commits you to a paper that cannot be written in eight weeks.
A layout that makes an opening informatics analysis defensible
Below is the frame our tutors keep beside an opening informatics submission, sized for a piece of roughly 1,000 to 1,300 words. It is our own outline rather than anything the university issues, and your week's rubric outranks it wherever the two disagree. Scale the targets proportionally if your assigned length differs.
| Section | What belongs in it | Word target |
|---|---|---|
| The decision under examination | Role, interval, action taken, and what a wrong call costs in that setting. Named before any technology appears. | 130 to 160 |
| Setting and current information | The unit or service line, its volume, and what data the decision maker already has and uses well. | 170 to 200 |
| The data path as it runs today | Capture point, capturing role, field type, every hop to the point of use, and where the delay or loss occurs. | 250 to 300 |
| Size of the gap | Audit counts with denominators and a window, or an explicit statement of what would have to be measured to size it. | 150 to 190 |
| Rival explanations tested | Two alternatives that are not informatics problems, each examined and either dismissed with reasons or partly conceded. | 170 to 210 |
| Scoped problem statement | The single paragraph the rest of your session will build on, with an explicit boundary around what is out of scope. | 110 to 140 |
Evidence craft that survives a doctoral reader
Separate what you observed from what you were told. An informatics analysis mixes personal knowledge of a workflow with literature, and the two carry different weight. Write observed at the workstation over three shifts in a clause where it applies, and let cited work carry the general claim. Blending them silently is the fastest way to lose the analysis row.
Cite the informatics literature, not just the clinical literature. Papers about workflow interruption, documentation burden, data quality dimensions and sociotechnical models exist in their own journals, and a doctoral paper in this course that cites only clinical outcome studies is reading half the field. Name the framework you borrow and give it a year in the sentence.
Describe fields, not screens. A screen is a rendering; a field is where data lives. Saying that the screening result is captured as free text in a note rather than as a discrete flowsheet value is a technical claim a reader can check, and it is what makes the rest of your argument operable. Vague references to the chart signal that you have not looked.
Every number arrives with its base and its window. Twenty-eight percent of records is unweighable. Eleven of forty records audited across two weeks in March is evidence. If the number is an estimate, say so in the same sentence and say what it is estimated from.
Keep the vendor out of it. Naming a product is rarely necessary and often narrows your paper into a support ticket. Describe the capability, the configuration and the constraint. Faculty read product-specific complaints as evidence that the writer has confused an implementation with a system.
Five mistakes that cost points in this week's territory
- Opening with the technology. A paper that begins by describing an electronic record has answered a question the scoring rows did not ask. The decision comes first, always.
- A gap with no size. Without counts, denominators or a stated measurement plan, the problem is an anecdote and the analysis row cannot be earned.
- Scope that swallows the session. Improving communication across the hospital is not a problem statement; it is a category. Narrow it until one audit could test it.
- Master's altitude in a doctoral course. Summarizing what informatics is, rather than analyzing one information flow, reads as coursework from a level you have already passed.
- Blaming the end users. If your explanation is that staff do not chart properly, you have stopped one question short of the design flaw that makes correct charting expensive.
Before you submit
- The decision, its owner and its interval appear before any system is named
- The data path is written field by field, including who captures each element and when
- At least one count with a denominator and a time window supports the gap
- Two non-informatics explanations are raised and answered
- A named informatics framework or model is attributed with its year in the sentence
- The closing problem statement carries an explicit out-of-scope boundary
Starting NR-706 this week?
Send the instructions and the rubric out of Canvas. A premium original draft comes back in 24 to 48 hours with the decision framed first and the data path written out field by field, and revisions run until the grade lands.