Respect the Adoption Curve

Some patient charts are longer than Moby Dick. I am not exaggerating. A prolonged hospitalization can generate more text than Melville did, and somewhere in that ocean of documentation is the one detail that changes your plan for the day. So when we built a tool that could summarize an entire chart into a readable narrative, it felt like a sure thing.

It wasn't. And the reasons it wasn't have almost nothing to do with the technology. They have everything to do with a lesson I keep relearning: innovation lives or dies on the adoption curve, and the curve does not care how clever your tool is.

Two kinds of innovation

After more than a decade of go-lives, I have come to believe there are really only two kinds of innovation in a health system, and they demand completely different playbooks.

The first is the slow burn. You have time. The change asks individuals to volunteer, to rework their own habits because they see something in it for them. People sort themselves along the classic adoption curve. Your early adopters go first, they talk to their colleagues, and eventually you hit a tipping point where the technology sells itself and you can scale. Slow-burn innovation is more work up front, but it usually produces a better product, because it gets shaped by iteration and by the fingerprints of many different users along the way.

The second kind is trickier: the all-at-once innovation. For technical or structural reasons, you can only turn it on for everyone simultaneously. This is hard for a simple reason. You have to be very good on day one, because your laggards and your skeptics get the same exposure at the same moment as your enthusiasts. There is no warm-up act.

People think the big bang is the sexy approach, or that it is somehow a faster path to scale. Almost always, it costs you trust. Users lose the sense of agency, the feeling that they can see and influence the pace of change in their own microenvironment. And because there are no early adopters evangelizing to their colleagues over coffee, you inherit a wave of resistance during and immediately after go-live, and then you scramble to win people back. Avoid the big bang whenever you can. When you can't, co-build with your users as deeply as the timeline allows.

Build the group before you build the tool

The single most transformational thing we did to make innovation actually happen was not technical at all. We created a small group of clinicians, carefully selected by their own leaders, and gave them early access to the tools. No protected time, no extra pay. Just permission to play with things, break them, and tell us whether the workflow would actually work. Then we put them in a room with the designers.

That group becomes your early adopters. Two pieces of advice about its composition. First, don't fill it with technophiles. You want a few contrarians in the mix, not laggards exactly, but people who need convincing. They will find the problems your enthusiasts forgive. Second, rotate the membership. Over a year or two, any group like this develops its own cohesion and identity, and its center of gravity drifts from "how do we help our colleagues" toward "what new thing can we get." Nothing formal, no fixed terms. Just make sure people cycle on and off.

Once you launch, adoption should be your primary and, early on, your only focus. Adoption is the proxy for whether the innovation is useful at all. Some initiatives, like care standardization, will always have a harder adoption hill than tools that offer pure freedom and convenience. That is fine, as long as your operational goals are aligned with the organization and you have sanded the adoption hurdle down as far as it will go. If you haven't, you will spend the next five years dragging people up that hill.

People first. Workflow second. Technology third.

If I had to compress everything I have learned about scaling innovation across a health system into three points, it would be these, in this order.

People first. Cultivate the soil before you plant anything. Is the culture ready? Do you have a trusted group who can test the technology and confirm it fits the purpose it was designed for? If not, start there, not with the vendor demo.

Workflow second. The workflow you are proposing must be easier than the current one, or at most very mildly harder. That is the entire tolerance band. Get a project manager if you can, map where processes diverge across sites, and ask the uncomfortable question: is this variation inherent and necessary to how care works in that location, or is it a norm that calcified over years and nobody remembers why?

Technology third. The technology has to live where people already work. Another platform, another login, another copy-paste ritual, and you have built a barrier, not a tool. Put it in front of people's faces in their existing environment and let them discover it is useful.

Three stories from the field

Chart summarization: the sure thing that stalled. On paper, an obvious win. We went live with an alpha group and the feedback was genuinely positive. Interestingly, it didn't save time so much as change how time was spent: less hunting and pecking through the chart, more time acting on what was found. Then we spread it, and it mostly got ignored. Why? Generating a summary took a minute or two, longer for longer charts. The summary lived in a sidebar, three or four clicks from view, unless you manually added a column to your patient list. And users had no control over length or content, so a one-day admission and a one-month admission produced the same undifferentiated wall of text. We are still working on it, and it is going okay, but until the summaries move into the workflow and give users real control, adoption will stay slow. The technology was fine. The workflow failed it.

The note template: This was a forced big bang. For technical reasons, a recent note template overhaul could not be staged. We did the homework: months of refinement, user feedback in non-production environments, select users testing in production. Then we flipped the switch for everyone, and two things happened. We had missed a group of clinicians in our education plan, and the last-minute scramble delayed the go-live and shaped how they experienced the change, as something done to them rather than with them. And a not-insignificant number of people felt the new template was worse than the old one, even though it was quantifiably better and built for what comes next. The perception was that the way we had always done it was the best way. It took sustained hand-holding and post-go-live education to get through. Not a failure, but a reminder that in a big bang, the unforeseen is the one thing you should foresee.

Hospital course generation: when it all lines up. Our AI-assisted discharge and hospital course tool relieved a real pain point. Nobody enjoys typing out a long narrative of a patient's hospitalization. The tool was fast, gave users agency over the output, and sat inside the note workflow behind a large, obvious tab. And one design choice mattered more than any other: it was built so you could not copy a colleague's course forward into your own note, which gently forced each user to generate the course when they took over a patient. Adoption was wide, rapid, and durable. It is still used avidly across our system. People, workflow, technology, in that order, and all three aligned.

The honest summary

Innovation is tough. Most of the craft is not in building the thing; it is in understanding the fail states before you meet them, matching the right rollout to the right innovation, and having the courage to pivot quickly when the curve tells you something you didn't want to hear.

The curve is always telling you something. Respect it.