Nothing in informatics can be improved until the current state is written down accurately, and writing it down accurately is harder than it sounds because the documented process and the real one are almost never the same. This stage of NR-640B usually turns on current-state analysis: mapping how work actually flows, where data is created and re-created, what the workarounds are, and why they exist. The graded skill is describing a process precisely enough that somebody who has never seen it could find its failure points. Your section may print this as NR 640B, NR640B or NR 640-B; 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-640B Week 2 asks for
Why does every informatics project begin by watching people work? Because the process on paper is a description of what somebody once intended. On the floor of a busy family clinic, the intake nurse has a sticky note on the monitor with the three fields the report actually requires, the medical assistant enters the vitals in the flowsheet and then again on a printed form because the front desk cannot see the flowsheet, and the last two steps of the documented procedure have not been performed by anyone in a year. All of that is the current state, and none of it is written down anywhere before you write it.
The deliverable at this stage is usually a current-state description, often with a workflow diagram, and it has a specific standard of precision. Each step needs an actor, a trigger, an action, a system or artifact where the output lands, and a handoff to whatever comes next. Steps written without actors produce diagrams that look tidy and explain nothing. Steps written without triggers hide the queues and delays that are usually where the real problem lives.
Workarounds deserve their own treatment because they are the most informative thing on the page. Clinical staff do not invent extra work for entertainment. Every workaround is a solution to a problem the system created, and an informatics nurse who documents the workaround without asking what it solves will design a replacement that gets worked around in exactly the same way. Naming the underlying constraint is the analytic move that separates a description from an analysis.
Expect this stage to reward restraint about causes. Your job here is to describe with precision, quantify where you honestly can, and hold off on the redesign. Students who jump to the future state in the middle of a current-state document lose the ability to demonstrate that their proposed change addresses anything real, and it is a difficult section to repair later because the observations were never captured.
Where our help stops and your practicum begins
The 72 practicum hours in this course are yours, and observation is the part that most obviously cannot be delegated. We do not attend meetings, shadow staff, visit sites, contact your mentor or your organization, complete hours, or produce site documentation. Hour logs, activity records, mentor and preceptor evaluations, learning agreements and any signed or verified form are your own record and are never drafted, reconstructed or estimated with our help.
The written layer is where we work. That means the structure of a current-state document, the discipline of the actor-trigger-action-artifact step, how to write a workaround so its cause is visible, how a diagram and its narrative divide labor instead of duplicating it, and how observations are reported with their bases. We can shape the writing about what you watched. We cannot watch it for you, and a description of a workflow neither of us has seen would be a fabrication.
De-identification in workflow writing has two edges. The obvious one is clients, who never appear in identifiable form: no names, record numbers or details that would single out a person. The less obvious one is staff, because a workflow description that says the evening nurse on the second floor performs a workaround identifies an individual as clearly as a name would in a small clinic. Describe roles generically, keep behaviors at the level of the process, and never include system screenshots without checking what your organization permits, since test environments frequently contain real data.
The NR-640B Week 2 method, step by step
Six moves for turning what you observed into a current-state document.
-
Fix the boundaries of the process before writing step one
Name the trigger that starts it and the event that ends it, in one sentence each. Most weak workflow documents are unreadable because they never decided where the process began, so they drift outward until everything is in scope.
-
Write each step as actor, trigger, action, artifact
Who does it, what prompts it, what they do, and where the output lands. Four elements, every step, no exceptions. The discipline is boring and it is what makes the document usable by somebody else.
-
Mark every point where data is created, copied or re-entered
Duplication is where informatics value hides. Flag each instance and note whether the copies can disagree, because a field that exists in two places with no reconciliation rule is a defect waiting to be found in a report.
-
Document the workaround and the constraint behind it
Two sentences each: what people actually do, and what the system prevents that makes them do it. A workaround recorded without its cause is a complaint; recorded with its cause it is a requirement for your redesign.
-
Quantify what you can, honestly and with bases
Observed durations, counts across a stated number of observations, queue lengths at a stated time. Four of the eleven admissions observed over two mornings is evidence. Often is not.
-
Close with the failure points, ranked and unsolved
Three or four places where the process breaks, ordered by how much they affect the problem you framed, with no solutions proposed yet. Ranking is analysis; listing is transcription.
A layout and word budget for a current-state analysis
Our frame for a current-state document of roughly 1,100 to 1,400 words plus a diagram. It is our own outline rather than anything the university issues, and your scoring guide outranks it wherever the two disagree.
| Section | What belongs in it | Word target |
|---|---|---|
| Scope and boundaries | The triggering event, the end event, the roles included, and what is deliberately outside the map. | 120 to 160 |
| How the process was observed | Sessions, hours, roles observed, whether staff knew you were mapping, and what you could not see. | 130 to 170 |
| Step narrative | The steps in sequence, each with actor, trigger, action and artifact, written to complement rather than repeat the diagram. | 300 to 380 |
| Data touchpoints | Every place data is created, copied or re-entered, with whether the copies can disagree. | 190 to 230 |
| Workarounds and their causes | Each workaround paired with the constraint that produced it, and who it protects. | 200 to 250 |
| Ranked failure points | Three or four break points ordered by impact on the framed problem, without proposed solutions. | 160 to 210 |
Evidence craft for workflow documentation
Use a named notation and use it consistently. Swimlane diagrams and standard process notation exist so that a reader knows what a shape means. Say which convention you followed and cite the source; an invented symbol set makes the reader learn your language before they can read your analysis.
Let the diagram and the narrative do different jobs. The diagram carries sequence and handoffs. The narrative carries why, what varies, and what happens when the usual path fails. Repeating one in the other is the most common way workflow documents become twice as long and half as useful.
Report observation conditions with the observations. Two mornings on weekdays, one clinician per session, no evening or weekend coverage observed. That sentence tells the reader exactly how far your description generalizes, and it costs nothing to include.
Anchor the analysis in informatics literature. Duplicate documentation, alert fatigue, workaround behavior and information handoff failure all have published evidence behind them, and connecting your local observation to that body of work is what makes the section graduate rather than descriptive.
Five mistakes that cost points in this week's territory
- Mapping the policy instead of the practice. Copying the documented procedure produces a diagram of something nobody does and forfeits the whole point of the exercise.
- Steps without actors. Passive steps such as the information is entered hide the handoff that is usually the failure point.
- Solutions inside the current-state section. Once you start redesigning, you stop observing, and the gaps in the description become permanent.
- Workarounds treated as noncompliance. Framing staff behavior as a training problem misses the constraint and guarantees a redesign that fails the same way.
- Screenshots taken from a live or test system. Both can contain real data, and an image in an academic document is a disclosure risk you never need to take.
Before you submit
- The process has a stated start trigger and end event
- Every step names an actor
- Each data touchpoint says whether duplicate copies can disagree
- Each workaround is paired with the constraint that causes it
- Observation conditions are stated with hours, roles and coverage gaps
- No client or individual staff member is identifiable in text or image
Mapping your practicum workflow this week?
Send the scoring guide and your de-identified observation notes. A premium original draft comes back in 24 to 48 hours with every step given an actor and every workaround tied to its cause, and revisions run until the grade lands.