HI300 Unit 9 Seminar Reflection Example

The Whiteboard Nobody Removed: A Unit 9 Seminar Reflection on a Workaround Labor Nurses Invented After Go-Live, Why It Survived Six Months and What It Was Telling the System's Owners

[Student Name]

Purdue University Global

HI300: Information Systems for Health Care

Unit 9 Seminar Reflection

[Instructor Name]

[Date]

The unit, the workaround and the seminar are composite; the sources cited are real.

Where I Started

The seminar case described a whiteboard. After go-live, the composite unit's charge nurses began writing each laboring patient's room, last tracing category, time of last cervical exam and nurse's initials on a whiteboard at the nurses' station, updating it every hour. The system had a summary view that showed most of the same information. Six months later, the board was still there and still updated. I came into the seminar sure that the board was a training problem. The system had the information; the nurses had not learned where to find it, or had not trusted it, and the board was duplicate documentation that could disagree with the record. My plan, if I had been the analyst, was a refresher session on the summary view and a deadline to take the board down.

What the Seminar Did to That View

A classmate who works as a labor nurse asked one question: from where on the unit could you see the summary view? The answer in the case was only from a workstation, after signing on, and only one patient list at a time. The whiteboard could be seen from every labor room door, by anyone, without a sign-on, at a glance. The instructor then asked what the board was doing that the system was not. Our group listed three things: it was always visible, it showed every patient on one surface and it let a physician walking past see in two seconds which room needed attention. The board was not a copy of the record. It was the only display on the unit built for a glance, and the nurses had built it themselves because nobody else had. The reading for the week made the same point more formally. Koppel and colleagues, studying how nurses got around bar code checks at the bedside, found that staff invent such fixes in response to real gaps between how a system works and how care is delivered, and that workarounds carry information about those gaps as well as risks of their own (Koppel et al., 2008). Removing one without addressing its cause tends to produce a new one.

So What

This changed how I think about my future role. As an HIM or informatics analyst, I will see workarounds every week: sticky notes, shadow spreadsheets, paper forms kept after go-live. My first instinct was to treat them as compliance problems. The seminar showed me they are also requirements that were missed. The whiteboard was a requirement for a shared display that no one on the project team had written down, because no one watched a busy night after go-live. The risk is real too. A board updated hourly can lag the record, and a physician acting on it might go to the wrong room first. But that risk is a reason to provide a better display, not a reason to hide the need. I also had to admit that my plan to take the board down would have failed on its own terms. If the nurses needed a display built for a glance, removing the board would have produced another one, perhaps a sheet of paper taped to the counter, and the project team would have learned nothing. The sociotechnical view of health IT that the course uses names this directly: the people, the workflow and the technology have to be considered together, and changes in one show up as adaptations in the others (Sittig & Singh, 2010).

Now What

If I were the analyst on this unit, I would start by asking the charge nurses what the board does for them and watching it used on one night shift. I would then ask the vendor whether the summary view could run on a large, always-on display at the station, readable from the room doors and showing only what the board shows. If it can, I would pilot it beside the board for a month and let the nurses decide when the board comes down. I would also add a question to every post-implementation review I run: what have staff built for themselves since go-live, and what does each one tell us we missed? Ash and colleagues reached the same advice in their study of unexpected effects of clinical systems: look for the new kinds of work a system creates, because they are rarely visible from the project office (Ash et al., 2004). That one question would have found the whiteboard in week two instead of month six.

References

Ash, J. S., Berg, M., & Coiera, E. (2004). Some unintended consequences of information technology in health care: The nature of patient care information system-related errors. Journal of the American Medical Informatics Association, 11(2), 104-112. https://doi.org/10.1197/jamia.M1471

Koppel, R., Wetterneck, T., Telles, J. L., & Karsh, B.-T. (2008). Workarounds to barcode medication administration systems: Their occurrences, causes, and threats to patient safety. Journal of the American Medical Informatics Association, 15(4), 408-423. https://doi.org/10.1197/jamia.M2616

Sittig, D. F., & Singh, H. (2010). A new sociotechnical model for studying health information technology in complex adaptive healthcare systems. Quality and Safety in Health Care, 19(Suppl 3), i68-i74. https://doi.org/10.1136/qshc.2010.042085