Closing stages in an informatics course usually ask you to gather the session into one argument: a change worth making, the evidence behind it, the design of the change itself, and how anyone would know it worked. The register shifts from student to practitioner, because the audience for this piece is a committee that can say no. Your section may print this as NR 599 or NR599; 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-599 Week 8 asks for
Here is the kind of problem that makes a strong closing proposal. A family practice with a panel of roughly 2,400 patients cannot reliably tell which children are overdue for a vaccine series, because immunization data arrives from three sources, the registry interface, records faxed from a previous practice and parent report, and only one of those lands in a countable field. Staff run recall by hand every few months when someone has time. The problem is small enough to describe fully, large enough to matter, caused by something structural rather than by inattention, and measurable before and after. Those four properties are what to look for when the assignment says choose an issue in your practice.
The argument then has to survive the question a committee will actually ask, which is not whether the idea is good but what it costs and who does the work. Proposals fail in review for predictable reasons: nobody named the owner, the training burden was invisible, the change required a vendor build that would take nine months, or the measure of success was described as improved compliance rather than as a number with a baseline. Writing against those failure modes deliberately is what separates a proposal that would be approved from an essay about a good idea.
Closing deliverables in this territory are often longer than the mid-session work and may carry a reflective or professional development component alongside the proposal. Treat both parts as graded writing. The reflection is where students relax into diary voice and give away points that the analytic sections earned, when the same content, written as an evidenced account of what changed in your practice and what proof exists, would score cleanly. If a final discussion runs alongside, remember that posts do not reopen after submission in Canvas.
The NR-599 Week 8 method, step by step
Six moves for writing a proposal a committee could act on.
-
Choose a problem you can size in a number
State how often it happens, out of what denominator, over what period, and how you know. A problem without a baseline cannot be shown to have improved, and the measurement row will find that gap immediately.
-
Trace the cause to a design decision, not to people
Where the information enters, what field it lands in, what nobody is asked, which handoff depends on memory. A cause stated structurally points directly at a fix; a cause stated as staff behavior does not.
-
Bring the evidence forward from earlier in the session
Reuse the search you documented and the appraisal you practised. A proposal supported by a set of sources you can defend beats a proposal supported by whatever appeared first this week.
-
Specify the change concretely enough to be built
Which field, which template, which report, which step moves to which role, and at what point in the visit. A specification a builder could follow is the strongest section in this kind of paper.
-
Write the cost side honestly
Build effort, training time, the extra seconds per encounter, and what has to stop to make room. Proposals that admit their costs are believed; proposals that pretend to have none are read as inexperienced.
-
Define the measure, the baseline and the review point
One primary number with its source, a starting value, a date when it will be looked at again, and the result that would make you stop. That paragraph turns a proposal into a plan.
A layout and word budget for an informatics change proposal
Our frame for a closing proposal, sized for roughly 1,400 to 1,800 words with a short reflective section if your assignment includes one. It is our own outline rather than anything the university issues, and your week's rubric outranks it wherever the two disagree.
| Section | What belongs in it | Word target |
|---|---|---|
| Problem with a baseline | The issue quantified with its denominator, period and data source, plus the consequence when it goes unaddressed. | 200 to 250 |
| Structural cause | Where the information enters, where it is lost, and which design decision produced the loss. | 200 to 240 |
| Evidence base | Three to five sources appraised rather than listed, with the strength and limits of each stated in a clause. | 280 to 340 |
| The proposed change | A specification precise enough to be built, including who does what at which point in the workflow. | 280 to 340 |
| Cost, risk and adoption | Build effort, training, added time per encounter, the most likely reason it fails, and the mitigation for that reason. | 220 to 270 |
| Measurement plan | The primary number, its baseline, its source, the review date, and the threshold that would end the trial. | 180 to 220 |
Evidence craft for a closing proposal
Appraise your sources instead of listing them. A sentence naming what a study did, in what setting, and what it therefore supports is worth five citations dropped at the end of a paragraph. Closing rubrics tend to weight synthesis heavily, and synthesis is visible only when the sources are compared.
Give every number a source and a window. Your baseline needs to say where it came from, a report you ran, a manual count you performed, a registry extract, and over what period. A number without provenance is the weakest sentence in an otherwise strong proposal.
Cite guidance for the clinical standard you are trying to meet. If the proposal exists to close a gap against a recommended interval or a recommended practice, name the issuing body and the year of the recommendation, and keep the clinical claim separate from the informatics claim.
Write the reflective section with evidence, not sentiment. Instead of writing that the course changed your view of documentation, name the specific practice you changed, the week it changed, and what a reader of your notes would now see that they would not have seen before.
Keep every example de-identified. Closing papers reach for real cases because they are persuasive. Strip the identifiers, use an age range, drop the dates, and say once in the methods that the material was de-identified before analysis.
Five mistakes that cost points in this week's territory
- A problem too large to specify. Improving interoperability across the health system cannot be designed, costed or measured inside one proposal.
- No baseline number. Without a starting value the measurement section becomes aspirational and the whole proposal loses its spine.
- A change that requires someone else's roadmap. Proposing a vendor development is proposing that nothing happen for a year, which reviewers recognize instantly.
- Costs left out. Every proposal has a cost, and one that reports none reads as either naive or evasive.
- Reflection in diary voice. The last two hundred words of a strong paper routinely give back points that the previous fifteen hundred earned.
Before you submit
- The problem carries a count, a denominator, a period and a data source
- The cause is stated as a design decision rather than as staff behavior
- Sources are appraised and compared rather than listed
- The change is specified precisely enough for someone to build it
- Build effort, training and added time per encounter all appear
- One primary measure has a baseline, a source, a review date and a stopping threshold
Finishing NR-599 this week?
Send the prompt, the rubric and your earlier submissions out of Canvas. A premium original draft comes back in 24 to 48 hours with the problem quantified, the evidence appraised rather than listed and the measurement plan written as a plan, and revisions run until the grade lands.