Activated Is Not the Same As Realized

Earlier this fall, Epic published results from OLVG, a teaching hospital in Amsterdam. Pediatricians using one of Epic’s AI documentation capabilities spent 31% less time writing notes per appointment and 27% less total time in the chart.

Those are encouraging results and what interests me most is that they took the time to measure what changed after the technology went live.

The numbers raise another question: what value did the improvement ultimately produce?

Less documentation time might mean less after-hours work, more time with patients, additional clinical capacity, or some combination. Those outcomes differ, and the answer depends on what the organization intended to achieve.

A capability can be activated without extensive adoption. It can be adopted without meaningfully changing the work. And it can improve a workflow without delivering the operational or financial result its business case anticipated.

Activated is not the same as realized.

The words we use tell the story

Listen to how organizations describe technology after an implementation.

The capability is “live.” It’s “activated.” It’s “deployed.” It “went in clean.”

Every one of those statements tells us something important about the technology.

None, by itself, tells us whether the investment delivered value.

Activation has an approval, a project team, a testing process, and a date. Value realization depends on what happens afterward: whether people use the capability, whether the work changes, whether expected benefits materialize, and whether those benefits persist.

The implementation can be successful while the value question remains unanswered.

Sometimes things get worse.

The distance between activated and realized

There are distinct questions an executive team should be able to answer about a technology investment.

Was it activated? Was the capability configured, tested, and made available to its intended users?

Was it adopted? Are those users actually using it, consistently and appropriately, beyond the initial rollout?

Did the work change? Did the technology reduce steps, save time, improve accuracy, or remove a burden? This is where the OLVG results provide useful evidence. They measure a change in clinicians’ work, not simply confirmation that the capability was turned on.

Did the expected value materialize? That depends on the investment. For one capability, the expected result may be reduced documentation burden. For another, the business case may promise improved patient access, fewer denials, better quality, reduced operating expense, or increased revenue. The measure has to match the promise.

Attribution matters, too. If revenue improves after an implementation, how much of that improvement can reasonably be connected to the technology rather than other operational changes?

A workflow improvement is not automatically a financial return. Four minutes saved per encounter do not become four minutes of reduced labor expense simply because someone multiplies them across a year’s appointments.

Those minutes may have substantial clinical value. But if the business case promised financial savings, leadership still needs to determine whether it captured those savings.

Did the result hold? Does the benefit persist through staff turnover, workflow changes, and subsequent upgrades? Who reviews it? Who is accountable when performance slips?

These are distinct tests of value, not necessarily a rigid sequence. Adoption and workflow redesign may occur together, and you can measure outcomes before broad deployment.

What matters is that each question gets answered.

Why the gap persists

When a technology investment is approved, someone also defines what it should accomplish.

The implementation then acquires a familiar structure: milestones, budget, project leadership, steering committees, status reporting, and a defined endpoint.

But the operational result often doesn’t fit neatly into that framework.

A project manager can confirm that a capability went live on schedule. That doesn’t mean the project manager can redesign clinical staffing, change department workflows, or ensure an operational leader uses the capability to produce the expected result. Those decisions belong elsewhere.

When the project closes, the mechanisms that kept everyone focused on delivery may close with it.

When adoption plateaus or expected benefits fail to materialize, accountability for resolving the gap can be much less explicit than accountability for meeting the go-live date.

The technology has an owner. The outcome may not.

That’s a governance problem, not simply a measurement problem.

Why this matters more now

Health systems have carried unfinished optimization work for years. Overlapping initiatives, competing priorities, and constrained resources are hardly new.

What’s changing is the continuity and pace of capability arriving from major platforms, AI tools, integrations, and other technology investments.

The next opportunity appears while the previous one is still being absorbed.

An underused capability doesn’t necessarily disappear from the organization’s workload. It may continue to require support, training, maintenance, and attention. Meanwhile, the next initiative asks for many of the same clinical and operational resources.

The cost isn’t limited to unrealized benefits. It can also include the organizational capacity consumed by work that was never fully resolved.

Value realization cannot remain something an organization plans to address after implementation.

Increasingly, there may be no “after.”

Going back may be the highest-yield work available

One of the most useful exercises an executive team could undertake may not involve new technology at all.

Go back to the capabilities activated over the past two years.

For each one, ask three questions.

1. What did we expect? Return to the original business case. Identify the intended clinical, operational, financial, or workforce outcome, not just the implementation deliverables.

2. What actually happened? Examine sustained adoption, workflow changes, measured outcomes, and the evidence connecting those outcomes to the investment. Distinguish demonstrated benefits from assumed benefits. Distinguish operational improvements from financial results actually captured.

3. What should we do now? Some capabilities deserve further improvement. Others need workflow redesign, clearer accountability, or changes in how they’re used. Some may already be delivering sufficient value. And some may no longer justify the capacity required to pursue the original promise. Consolidating, replacing, or stopping them may be the better decision.

The goal isn’t to force every investment to deliver its original business case at any cost.

It’s to decide what value remains available, what it would take to capture it, and whether that is still the best use of the organization’s capacity.

The question that should outlive the project

Health systems have spent years developing the disciplines required to implement complex technology.

Those disciplines matter. Successful implementation is difficult, consequential work.

But implementation and value realization are different responsibilities.

The first makes capability available.

The second determines whether that capability changed something worth changing, and whether the organization received the benefit it expected.

The question shouldn’t disappear when the project team moves on.

Of the capabilities your organization activated in the past two years, how many can you trace to an outcome someone still owns?

Next
Next

Is the Squeaky Wheel Setting Your Technology Priorities?