The Proof of Concept Worked.
Now the Hard Part Starts.

The proof of concept worked.

At its main clinic, a rural health center had tested a new tele-endocrinology service for its patients with diabetes. One experienced nurse presented each patient to the specialist on screen. The medical director championed the service at every staff meeting. The team had written down its assumptions before launch, and one by one, they held. Clinicians rated the visits as good as in-person. Patients said they would recommend the service. Nearly every patient arrived with current labs.

Better still, the team had agreed in advance what success would trigger: expansion to the health center’s two satellite clinics.

Six months later, the picture looked different. Visits at the satellite clinics lagged well behind the main site. One satellite nurse wasn’t sure how she was supposed to present a patient on screen, so she mostly didn’t. Patients were again showing up without current labs. The project manager who had coordinated everything had moved on to the next initiative. And the dashboard still tracked every metric from the proof of concept, more than twenty of them. Nobody opened it.

Nothing had failed technically. The service worked until it had to work without the people who had proven it.

For organizations putting Rural Health Transformation Program (RHTP) funding to work, this is where much of the risk sits. Funding gets a service launched. What happens next decides whether the service delivers the outcomes CMS expects and keeps running after the grant ends.

Why Success Doesn’t Scale Itself

A proof of concept runs under protected conditions. The staff are often hand-picked, a champion is in the room, and the project team is paying full attention. That’s appropriate, because the point is to validate assumptions at a scale where failure is survivable.

Deployment is the phase where the service has to work without those advantages. In the Ingenium Implementation System, it’s the fifth phase, following Selection, Verification, Solutionization and Validation. Its job isn’t to repeat the launch at more sites. Its job is to turn a service that worked into one that keeps working. Sustainably.

One principle captures the difference: a service that survives on grant money and one champion’s goodwill was never designed to sustain. It was merely permitted to exist.

Getting from one to the other takes three deliberate shifts.

1. From Champions to Everyone

The proof-of-concept team understood the service because they helped build it. Everyone who joins during Deployment needs to reach the same understanding without having been in the room.

That starts with training that opens with why. Before anyone learns a workflow, they should hear the Strategic, Business and Clinical Case for the service: why the organization is doing this, why it’s worth the effort, and what it means for patients. Then come the workflows, the technology, the policies, best practices and where to get help.

In ADKAR® terms, the why builds Awareness and Desire. The training that follows builds Knowledge and Ability. Skip the why, and you’re teaching people how to do something they haven’t agreed to do.

For clinicians, this doesn’t need to take a lot of time. A well-designed curriculum covers telehealth awareness, the workflow, the technology, webside manner and the virtual physical exam in about 80 minutes. What matters more is what surrounds the training: one-page cheat sheets at the point of care, and someone at the elbow for the first few visits at each new site.

The satellite nurse in our example didn’t need a longer training. She needed to see the visit done once, a cheat sheet on the wall and a coach for her first few patients.

Deployment is also where design with, not for continues. The Happy Day workflow, the way the visit runs 80 to 90 percent of the time, should stay the same everywhere. But each site’s staff should adapt the alternate workflows to their own building, staffing and patients. People support what they help shape.

This is also where ADKAR® gets tested at scale. The proof-of-concept team worked through all five elements together. Every new site starts at the beginning, with Awareness, not where the main clinic left off. Treating a satellite clinic as if it had already been through the proof of concept is how a working service stalls at its second location.

A successful proof of concept also has a second job: it becomes the example everyone else follows. In Switch, Chip and Dan Heath call these “bright spots,” proof that the change is possible. They also remind us to “rally the herd,” because behavior is contagious and people follow respected peers. The main clinic is both. Its nurse and medical director are the people the satellite staff will listen to, but only if they’re brought in to show how the service works, not just to report that it did.

2. From Launch Support to Ongoing Operations

Launch support and ongoing operations are different jobs. Launch support is intense and temporary: the project team schedules, troubleshoots, fixes and encourages. Ongoing operations are steady and permanent: someone owns the service day to day, supports the staff and keeps improving it.

When the two are confused, launch energy gets mistaken for an operating model. The service looks healthy because the project team is still propping it up, and when the team leaves, it sags.

The fix is to settle ownership before the project team steps back. The clinical and operational leaders at each site should own the service, with central support. A central team that owns every service creates dependency. A central team that supports services owned locally creates a program.

In most organizations, the Telehealth Coordinator carries this role, working across three areas:

• Supporting: scheduling help, patient tech checks and visit support when something goes wrong.

• Training: onboarding new providers and staff, and refreshers when workflows change.

• Optimizing: collecting and reporting performance metrics, and leading improvements.

That last area is where the third shift begins.

3. From Proving to Managing 💡

The proof of concept measured a lot, and it should have. Its metrics answered one question: were we right? Each one tested an assumption.

Once the assumptions are validated, most of those metrics have done their job. Performance management asks a different question: is it still working? Answering it takes a much smaller set of key performance indicators.

The failure runs both ways. Organizations that keep every proof-of-concept metric end up with a dashboard nobody opens by month four. Organizations that skip straight to KPIs never test whether the assumptions underneath the service actually held.

Deciding what to keep doesn’t have to be a judgment call. A few tracing rules make it mechanical:

• Every requirement traces to a need.

• A requirement inherits the priority of the highest-priority need it traces from.

• Every proof-of-concept metric traces to an assumption.

• Every KPI traces to a success criterion defined when the requirements were written.

• Anything that traces to nothing gets cut.

Then, as we’ve described in How to Measure Telehealth Success, each surviving KPI gets four things:

• An owner: an executive owner, an operational owner and a data steward.

• A definition: how the data is collected, how often and how it’s reported.

• An expectation: the target that separates acceptable from successful performance.

• An action: what happens if the KPI misses, meets or exceeds the target.

That fourth element is the one most organizations skip, and it’s the one that matters most. We call it Proactively Agreed Action: deciding the response when the target is set, while nobody is yet invested in the answer.

In change management terms, this is Reinforcement, the final element of ADKAR® and the one that decides whether the change outlives the project. KPIs that someone owns and acts on are how an organization keeps the new way of working from sliding back into the old one.

Take the share of visits where the patient arrives with current labs. At the main clinic, it was high throughout the proof of concept. Suppose the team had agreed in advance that a drop below target would prompt the coordinator to review the scheduling hand-off with each site. The satellite clinics’ problem would have surfaced in weeks, not months, and nobody would have had to argue about whether it was serious enough to act on.

Review the KPIs weekly at first, then monthly once the service is stable. And judge the trend, not a single month. One bad month is a data point; a pattern is a signal.

The Hard Part Is the Part That Lasts

RHTP-funded organizations will be held to outcomes, and to sustaining their services once the funding ends. Neither is decided at go-live. Both depend on whether Deployment built something that runs without its champions: trained staff at every site, clear local ownership and a short list of measures that someone acts on.

The proof of concept shows that a service can work. Deployment makes sure it keeps working.

If your organization is preparing to put RHTP funding to work, our RHTP Implementation Support page describes how we help rural clinics, health centers and hospitals take new telehealth services from a successful proof of concept to lasting performance.