I am working on a novel, my second. It involves a serial killer. There is something richly cathartic about killing someone with bits and bytes. If you are in a bad mood, it can be calming. If the killing does not provide the calming effect I had hoped to achieve, rekilling him in a more vengeful manner usually does the trick.
The novel involves the skills of an FBI profiler. If you have read any of the books on profiling you would think it an exact science. Chapter by chapter the writer extols the successes of profiling—this profile worked, that one worked. According to how it is spelled out in the book, one would want to ask, if profiling is so successful, why do they not use it on every case?
Perhaps because there are unwritten chapters, chapters that never make it into the profiler’s handbook. The reason those chapters do not make it to the book is because it sort of defeats the purpose to print cases in which the profiles that were created did not match that of the killer’s—white male in his mid-thirties, wooden leg, drives a Prius, and enjoys watching Dancing with the Stars.
When I thought about it, it occurred to me that business software is pitched a lot like profiling serial killers. You never hear about the bits that do not work.
Think back to when you and your colleagues watched various processes of your software being demonstrated—add a patient or a customer, schedule an appointment, write a new script. The functionality was so smooth it brought a tear of hopefulness to the eyes of the prospective users.
In a recent conversation I learned of a patient scheduling system that had more than five-thousand user screens. That is a five followed by three zeroes; almost enough to have a separate screen for each patient.
Like the author of the book on profiling who only wrote about the cases on which his technique worked, software vendors only show potential buyers those processes that function smoothly. In an EHR system, vendors show how their software works in a real-life setting with only one thing missing, a patient with which it must interact. A rather critical missing part of the functionality puzzle if you ask me.
The entire situation, that of acquiescing over time to having to use bad software, reminds me of the experiment of the frog and the pot of water; drop a frog in a pot of boiling water and it leaps out, place it in a pot of water and gradually raise the temperature and the frog will remain in the pot until it is cooked to death.
Users of bad software are a lot like frogs in a pot. They never quite get up the moxie needed to jump out of the pot. More often than not they allow their situation to worsen until it is too late.
I don’t wake up each day planning to be at odds with ninety-eight percent—I’m probably being overly generous assuming two percent of the people are as jaded as me—of the HIT community, maybe I just come by it naturally.
Many organizations have a Program Management Office and a Program Steering Committee to oversee all aspects of the EHR. Typically these include broad objectives like defining the functional and technical requirements, process redesign, change management, software selection, training, and implementation. Chances are that neither the PMO or the steering committee has ever selected or implemented an EHR. As such, it can be difficult to know how well the effort is proceeding. Simply matching deliverables to milestones may be of little value if the deliverables and milestones are wrong. The program can quickly take on the look and feel of the scene from the movie City Slickers when the guys on horseback are trying to determine where they are. One of the riders replies, “We don’t know where we’re going, but we’re making really good time.”
My favorite thing about healthcare is having witnessed it up close and personal both as a cancer patient in the 80’s and as the survivor of a heart attack seven years ago.
