HS420 Unit 7 Seminar Reflection on System Complaints Example

Only Five of Twenty-Six Were the Software's Fault: A Unit 7 Seminar Reflection on Sorting Workplace System Complaints

[Student Name]

Purdue University Global

HS420: Health Informatics

Unit 7 Seminar Reflection

[Instructor Name]

[Date]

The seminar, the complaints and the classmates are composite; the sociotechnical model, the study of information system errors and the reflective model cited are real.

Where I Started

Before the session I was certain the health record at my clinic was poorly made. My evidence was the immunization registry problem my group has been studying all term: nurses retyping every vaccine dose into the state's website at the end of the day. I had written in my notes that "the system cannot talk to the registry," and I assumed a replacement was the only fix.

The Exercise

The instructor asked each of us to post our three worst complaints about a system at work on a shared board. Twenty-six complaints went up from nine classmates. Then the group sorted each complaint into one of four columns. Design meant the software could not do the task at all. Setup meant the software could do it but had not been configured or connected. Process meant the steps people followed made the task harder than it needed to be. Training meant people did not know a feature existed or how to use it.

Where My Complaint Landed

My complaint, retyping vaccine doses, was the first one the group argued about. A classmate who works for a vendor asked whether our record had a registry interface. I said I did not think so. She asked me to check during the break. I found the vendor's documentation for a registry module on my phone in two minutes. The module existed; my clinic had never licensed or turned it on. My complaint moved from design to setup.

The thing I had been calling a broken system was a working feature nobody had switched on, and that difference changes who has to act and how much it costs.

The Final Count

By the end of the hour, the board read: design, five; setup, nine; process, eight; training, four. Most of the design complaints were real, such as a medication list that could not show doses in the units a pharmacy used. But the largest groups were setup and process. In the sociotechnical model we read earlier in the term, software is one part among several, and workflow, people, an organization's rules and pressures from outside the clinic all shape what a system can do (Sittig & Singh, 2010). The board was that model drawn in sticky notes.

What Changed

I had been treating every system frustration as a technology problem. The seminar showed me that many are organizational: someone decided not to buy the interface, or nobody owns the error queue, or training stopped after go-live. Studies of unintended consequences describe errors that arise from the fit between systems and work, not from the software alone (Ash et al., 2004). That fit is something an organization can change without replacing anything.

Using Gibbs's reflective cycle, I can separate my feeling during the exercise, mild embarrassment, from what I learned, which is that my diagnosis was incomplete (Gibbs, 1988).

How It Changes My Project

Our group's project assumed the clinic would need a new product. It may need only to license and configure a module it already has. I raised this with my group the next day, and we added a step to our selection comparison: check what the current vendor already offers before evaluating anyone else.

What I Will Do Differently

When I hear a complaint about a system now, I will ask which column it belongs in before proposing a fix. A design problem calls for a vendor request or a new product. A setup problem calls for configuration. A process problem calls for a workflow change, and a training problem calls for teaching. The four answers differ in who must act and what it costs.

I also want to bring the same sorting back to my workplace. Our staff meeting has a standing complaints item, and most months it turns into a list of things the system cannot do. I plan to suggest that we sort each complaint into the four columns before anyone proposes a fix, and to ask whoever raised it to check, as I had to, whether the feature already exists. If the clinic I studied this term is typical, a good share of what we call broken software will turn out to be configuration, routines or training that we can change ourselves within weeks, not years. The ones that remain in the design column will then be the ones worth taking to the vendor, with evidence that they are real.

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

Gibbs, G. (1988). Learning by doing: A guide to teaching and learning methods. Further Education Unit, Oxford Polytechnic.

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