The Telehealth Pilot That "Went Fine" —
Yet Went Nowhere

Ninety days in, the numbers looked good. The rural clinic had enrolled about twenty-five patients with uncontrolled hypertension in remote patient monitoring. Patients liked the cuffs. Readings were coming in. The monitoring nurse said the workload was manageable, and the medical director had seen several patients’ blood pressure trend down.

At the wrap-up meeting, everyone agreed: the pilot went fine.

Then someone asked the obvious question — should we expand to the other two sites? — and the room went quiet. Was forty patients enough to know? Would “manageable” still be manageable at 150? Did the trend hold, or were these the patients who would have improved anyway? Nobody could say, because nobody had ever said what “fine” needed to look like.

Six months later, the program was still a pilot, still at one site, still waiting for a decision nobody felt equipped to make.

The pilot didn’t fail. It just never ended in a decision. With RHTP and other funding putting remote monitoring and virtual care programs into motion across rural health at the same time, this pattern is set to repeat itself in a lot of organizations.

Why Pilots End Without a Decision

Most telehealth pilots are defined by time: run it for 90 days, or until 50 patients are enrolled, then see how it went. Success is informal — “it works” or “people seem to like it”. And the hardest question, what happens next, is deferred until after the results are in.

That last part is where pilots go wrong. By the time results arrive, the equipment is bought, the champion has spent political capital, and the team has a stake in the answer. The conversation is no longer only about evidence, and it tends to produce one of two familiar endings: the pilot that disappointed but launched anyway because the budget was committed, or the pilot that succeeded but never scaled because nobody had agreed what success would trigger.

One of my favorite quotes, attributed to Dr. Paul Batalden’s, applies here: “Every system is perfectly designed to get the results it gets”. A pilot built around a calendar and informal success criteria is designed to end in a meeting where people say “it went fine”.

A proof of concept is designed differently.

It runs until the critical assumptions are validated — frequently within weeks — rather than until a date. Its success criteria are formal and verifiable. Its mindset is “let’s validate our assumptions and improve the solution until it’s ready for deployment”. And at any point, you can say how far along it is.

Validation: Where the Plan Meets Reality

In the Ingenium Implementation System, Validation is the fourth of five phases on the path from idea to serving patients. Selection screens competing ideas against three questions: is it strategically aligned, financially sound, clinically viable? Verification answers the same three in depth, building a Strategic Case, a Business Case and a Clinical Case. Solutionization designs the service — policy, workflows, technology, support and training. Deployment brings it to full scale.

Validation sits between design and deployment, and it is the first time the plan is tested against real patients and real staff. It also tests what could not be tested earlier. Whether a service is operationally workable, and whether the people carrying it can sustain the workload, are questions that only have answers once a design exists.

Start With the Assumptions — Including the Hidden Ones

Every new service rests on assumptions, and most of them are never written down. The first step of a proof of concept is to surface them. Go back to the three Cases and to the design, and ask: what did we assume?

For the RPM program above, the list might include:

• Strategic: monitoring will reduce avoidable ED visits for hypertensive crises.

• Financial: enough patients will transmit readings consistently for the program to be reimbursable at the volume we projected.

• Clinical: clinicians will trust the readings enough to adjust medications based on them.

• Operational: medical assistants can enroll a patient and train them on the device within a standard visit.

• Human: the monitoring nurse can review readings and alerts without displacing other work.

A real list is usually longer — patient acceptance, device reliability, home connectivity, caregiver involvement. Not all assumptions matter equally, so the multidisciplinary team prioritizes them together. Clinicians belong in that conversation as the people who know which wrong assumptions would sink the service.

Measuring Success

Each priority assumption then gets three things: a metric that would validate it, a goal for that metric, and a collection system — who owns the measurement, how the data is gathered, and how it will be analyzed.

Most organizations never build this table. When they do, two things change. The proof of concept now has an end: it is complete when the significant assumptions are validated. And progress becomes visible — “six of nine assumptions validated” is a status report a calendar can’t give you.

Beyond Measuring: Proactively Agreed Action

Measuring success tells you whether an assumption held. It doesn’t tell you what you will do about it. Without that, a well-measured proof of concept can still end in the same quiet meeting.

So for each priority assumption, the team agrees — before launch — what happens at each outcome.

For the nurse workload assumption above:

• If it holds (60 minutes or less): expand to the second site and plan staffing for the next 25 patients at the measured ratio.

• If it partly holds (60 to 90 minutes): revise alert thresholds and the triage protocol, then re-measure for three weeks before expanding.

• If it fails (more than 90 minutes): pause enrollment and redesign the staffing model before any expansion.

This is the step virtually every team skips, and it is the one that turns measurement into a decision.

The actions are agreed while nobody is yet invested in the answer — before the equipment is the champion’s equipment, before the results belong to anyone. When the data arrives, the response is already settled. That prevents both familiar endings: the service that launches despite failing its test, and the service that passes and stalls.

“Stop” is a legitimate outcome. A proof of concept that reveals a broken assumption at small scale, before full deployment, has done its job.

Small Scale, Continuous Improvement

A critical hallmark of a proof of concept is the mindset of continuous improvement to optimize the results and outcomes. Once the proof of concept launches on a small scale, the team improves workflows, technology, training, and operational support as it runs. Validation is the final round of Solutionization refinement, conducted where mistakes don’t have a big impact. It is also where change management becomes concrete — whether staff have the knowledge and ability the new service requires shows up quickly with real patients.

When the proof of concept ends, many of its metrics retire with it. A small subset becomes the ongoing performance measures for deployment, where the question shifts from “were we right?” to “is it still working?”

Back to the Clinic

Picture the same RPM program with the assumptions written down, the goals set and the actions agreed before the first cuff shipped. Ninety days in, the wrap-up meeting is short. Seven of eight priority assumptions are validated. Nurse workload came in at 75 minutes a day, so the alert thresholds get revised and re-measured for three weeks — as agreed. Then the second site goes live.

Same clinic, same technology, same patients. The difference is that “it went fine” was replaced by a decision the team made months earlier, before anyone had a reason to argue about it.

For organizations implementing RHTP-funded projects, that difference matters. Funded programs have end dates and are expected to demonstrate outcomes. A proof of concept with proactively agreed actions is how a funded trial becomes a decision — and how a decision becomes a service that lasts.

If you’re planning a proof of concept for an RHTP-funded or other new digital health service, our 9-question anonymous readiness check at ingeniumdigitalhealth.com/rhtp is a good place to start — or reach out, and let’s talk through your assumptions.