Lessons from the Labor and Delivery Room

A few days ago, my wife and I welcomed our second child (and second boy) to our family. Mom and baby are doing very well, and we are getting into the routine of a family of four. We were blessed with a fantastic labor and delivery nurse who took excellent care of my wife while teaching a medical student about hospital procedures for patient care. During a quiet time before delivery, I observed the nurse explain a new protocol that required scanning of bar codes on all medications given to patients, so they are accounted for in inventory and logged against the patient’s electronic medical record. She then hung an IV bag and reached for the scanner.

I noticed that there were two bar codes on the bag, each of different lengths and positioned very close together. My first thought was, “this looks challenging”. Sure enough, our nurse validated my suspicion when she expressed her confusion with the bar code design, telling the student, “These always give me trouble. I don’t know why they put them so close together”. She took the opportunity to explain how to double check that the scan was correct and to assume it was human error first, then she attempted two more scans before she was satisfied it was correct.

This was a new process, required by hospital policy, that introduced risk and added more work than necessary to the job of a very experienced, very diligent nurse. I can imagine that in a situation with greater urgency for medication and a greener or less detail-oriented employee, the medication scan would more likely be incorrect or perhaps not scanned at all, if it were a known annoyance.

Although this happened in a hospital setting, I noticed the parallels to a software development project I consulted on recently. There, we coached end users and development teams using an agile approach to create a software product for internal operations groups. We held working sessions with the project team and user representatives to review recently completed components, so users could literally see how the product was progressing and how it would be used. This gave them a multitude of opportunities to provide feedback that would make sure the product would work correctly and be a valuable addition to their jobs. For any project, after the product is finished and released, we recommend observing it in everyday operation to ensure users are satisfied and to correct any issues that arise unexpectedly. Further, periodic observations in the future can shed light on potential enhancements to make the product even more useful, ensuring its adoption and success.

What are the lessons for the hospital or anyone implementing a new system, process, product, or service?

• Engage end users early and often. Announcing a top down change or gathering requirements is just the start.
• Spend time learning how users do their job and how it is likely to change.
• Listen, observe, and ask questions, especially “why”. Understand the reasons behind the methods.
• Include users at each step. Let them see it, touch it, and try it out on real problems.
• Don’t stop after the project is over. Check in on users to see how they are adapting. Look for external changes that impact how they interact with the ‘product’ you delivered to identify improvement opportunities.

Good user engagement makes the difference between project success and failure. It can improve user satisfaction, reduce the burden of compliance, and create a better working relationship between those delivering a project and those who live with the result – which bodes well for the next investment in the pipeline.

As for that tricky IV bag…  our nurse decided to report the issue to her management team to start the improvement process.