As a former healthcare CIO and longtime health consultant, I’ve been through my share of clinical information system rollouts. A couple have gone well. Most have gone okay. A few have left scars.
I’ve been reflecting on the successes and failures of these efforts, and what could have been done better. In doing so, I’ve hit upon an idea that I think is really cool. I wonder if you’d indulge me…
Our traditional approach to implementing clinical information systems is geographic and step by step. If we’re rolling software out in a hospital then we do it a ward at a time. If we’re doing it across a region, a hospital at a time. We shoehorn the solution into place in one location, before rapidly moving on to the next. We’re usually running behind schedule and over budget, and rarely stop to assess the trauma that we’ve caused in forcing clinical users onto a new system. As I sometimes say, “Cerner isn’t a life choice, it’s something that happens to you“.
So no wonder there’s often bitterness towards the IT departments that are responsible. The solution to the paternalistic practices of medicine is not found in a paternalistic approach to eHealth.
But what if things were different? What if we learned lessons from how we rollout software solutions to consumer mass markets?
I want you to think back to the early days of Gmail, the Google email solution. Back in the day, everybody wanted a Gmail account. Only a few people had one. But here’s the thing – when you finally got an account, you received with it the ability to invite 10 friends to Gmail. You had to think carefully about how to use those invites, because you couldn’t recall them.
This flashback to the early days of Gmail got me thinking about the dynamics of a constrained rollout approach, based on invites. I think such an approach has the following properties:
- Restricted supply creates demand – If you take something that is desirable, and make it scarce, this only serves to increase desire for that thing. Because it was hard to get a Gmail account, I wanted one even more.
- Controls growth in a managed way – By limiting the speed of growth to the pace at which people invite their friends, the performance and capacity of the underlying system is tested in a gradual way. Load grows slowly at first, then faster and faster as confidence increases in the IT infrastructure.
- Flattens the change curve – The act of receiving an invite to a system from a friend, for which I’ve been waiting a while, means that I start the process of assessing that solution in a positive mindset. I wanted it. I had to wait for it. I’ve been lucky to get it. A friend gave it to me. My friend liked it enough to pass it on to me. Through these dynamics, my emotional commitment to learning how to use the solution has increased and it’s more likely that strong adoption will take place.
- Taps into a trust network – Lastly, and most importantly, the invite from a friend serves as an implicit recommendation. I trust that friend. They like the solution. They are using one of their limited invites on me. They aren’t just inviting me, but recommending the solution to me. The rollout proceeds outward through a trust network.
The folks at Google are smart, but I’m not sure whether all these effects were intentional. I suspect the second one was, but not sure about the others. Nevertheless, what if we were to harness these dynamics to address the traditional challenges of rolling out clinical information systems to health providers?
I think you guys are there already, but here’s where I’m going. My proposal for a new approach to rolling out clinical information systems.
Trust Network Rollout
A prescription for clinical information system implementation that sticks:
- Start with a “core group” of 10-20 health providers from different disciplines. Some should be the biggest clinical supporters of the solution, but others should be its biggest detractors.
- Work to make the core group happy with the solution. This might take a while. That’s the point.
- Once members of the core group are happy, they have 8-10 invites to send to their clinical colleagues. They are told only to invite people when they’re confident and prepared to back the solution.
- Every time an invite is issued, the project change and training team contacts these individuals to offer support and training. This level of support diminishes slowly over time.
- Once we have reached critical mass in terms of numbers (i.e. > 50-60%) and acceptance, consider a big bang invite for all remaining users.
- Map the trust graph. Literally draw a picture of how the rollout proceeded from person to person. This is the clinical trust graph in your health system.
Worth a thought?
Yes, I know there are some challenges with this approach, particularly with regard to operating multiple systems / clinical workflows and data migration. I’ve got thoughts on those things, but they are for another day. But just stop and think – are the current approaches to clinical information system rollout really working so well?