I was starting to get frustrated.
“Thank you for explaining it again but, based on what you’re telling me, I still don’t know which option is best,” I told the very nice Verizon Wireless representative, who had been detailing the different data plans for our new managing editor’s iPhone. “What I would like to do is tell you, again, what the phone will be used for, and then have you simply tell me which plan is best.”
After much convincing, I was able to get the representative to commit. “Fine – I’ll go with that one,” I quickly responded.
Verizon had obviously been coaching their reps to lay out customers’ options clearly and completely, then let buyers decide which plan to choose. In areas I have little knowledge (and no interest in attaining it), I’m apt to go with the vendor-suggested approach — often, I demand it. For example, when installing an application on my computer, I’ve never selected the “custom” approach because I have no idea how to structure it, or why I’d even want it.
When it comes to the installation of advanced clinical applications, there exist the same distinct schools of thought — should vendors insist customers go with their formula or recipe, or should they take a more flexible approach, allowing software customization based on user preferences and workflows?
I got to thinking about these two paths recently while interviewing East Orange General Hospital CIO Tom Ciccarelli. About a year ago, I interviewed Ciccarelli about his organization’s decision to go with GE Centricity as its core inpatient clinical system. I was so impressed by his selection methodology — allowing users to select the system, then trusting their judgment despite his reservations — that I wrote my column about it. This week, I caught up with the New Jersey-based CIO again to find out how the install had been going.
While extremely pleased with GE’s performance, he noted that the company’s flexible approach to configuring departmental systems constituted a “two-edged sword.” On the one hand, users were elated to be in the application-design driver’s seat. On the other, he noted, “Sometimes they weren’t happy with the electronic workflows they had designed.” In short, to borrow one of my favorite movie lines, “They sounded like someone who got what they wanted, but now didn’t want what they got.”
In our interview to be published next week, Ciccarelli says if he had to do it over again, he’d bite the bullet, somehow find the (non-existent) extra money, and bring in consulting help to assist his users with their application customization. This, he said, could have blunted the second edge of flexibility’s sword.
Other vendors, some extremely successful, are known for taking the opposite approach. They bring their recipes for success to a customer, not merely offering them for consideration, but requiring they be applied as stakes to play. I’ve interviewed CIOs who’ve embraced this approach and, almost to a person, they did so in the hopes, and with the expectation, of replicating the vendor’s past successes.
Is there a right way? Perhaps not, but Ciccarelli ‘s courageous and generous interview — given with an eye to helping peers avoid some of the challenges he’s grappled with — is instructive. For those with limited resources on a tight budget — that is, for most hospitals in this country — flexibility is a slippery slope. A CIO who gives wide berth to users in allowing them to design their systems is playing a dangerous game. Thus, perhaps a simple rule could serve to inform these decisions — the leaner the shop, the greater the need for a proven recipe; the larger the organization, the greater the ability to support on-the-ground customization.
As Ciccarelli notes, only the passage of time will reveal if some decisions are right or wrong. As such, I’ll be visiting with him again in six months for an update on East Orange’s EMR journey — stay tuned.
Meredith Miller says
The two edges of the sword of any configurable/customizable application. Edge one – the more options/choices you have within an application, the more complex the implementation & training, because then everyone has to stop and THINK about whether option A, B, or C is the best option for their given situation, until usage of the systems becomes second nature. Edge two is that if you implement an application that is NOT flexible, configurable, with options as to how to execute a task, I guarantee the end users, specifically physicians, will not like the system because it is too rigid and inflexible.
Clear & appropriate expectations need to be set up front between the vendor and the client. You can have a flexible configurable solution that will require more involvement on the part of the end users throughout the implementation and after, or they can take the vanilla, out of the box product, implement and use ‘as is”.
Two ways to implement, it depends on how you like your pain:
A) A little pain over a long period: minimally configure the application and clinical content to the practice, then once live maintain a steering committee to evaluate and prioritize customization of the product as they move forward. This gets you up and running fast with minimal decision making, workflow consideration or customization of the product, which you can then gather feedback from your users as to how they want it to work going forward. Users do not really know what they want the application to do until they know what it does and does not do to begin with, therefore by waiting until AFTER Go Live (when the rubber really hits the road) you are saving yourself upfront implementation time & resources, but you will need to maintain ongoing customization resources, development meetings and training.
B) A lot of pain for a short period: Invest time resources and money in your implementation process. Get your project team lined up and fired up, then turn them loose on the software as is. Ask the vendor to demonstrate your most common clinical workflows in the system as is and allow the project team to determine if this is workable or if other workflow processes need to be created. Once the most common are nailed down, repeat the process with your most unusual/complicated clinical processes. Configure the application appropriately and re-test the workflows until acceptable. In the meantime, collect the clinical content required by all providers and insure this is included in your application build. Never forget the 80/20 rule. If 80% of patients/providers need it, it goes in, if 20% it is an exception to the rule. Roll it out, use it, and provide a process for users to submit enhancement requests to the project team for evaluation, prioritization, build & training. This becomes part of how your practice functions going forward.
So I agree, there really is not wrong or right answer, but appropriate, detailed guidance and expectation setting on the part of the vendor, or better yet, your consulting implementation manager, will provide the practice with a robust understanding of what the options are, and the pros and cons to each, thus allowing the practice to choose which path to take based on facts and options, not just a sales pitch or vendor only guidance.