Most Telehealth Rollouts Have Two Phases.
They Need Five.

A rural hospital board decides it’s time for telehealth. Someone loops in IT. IT writes a request for proposal, a vendor gets selected within a few months, and eighteen months later the service is underused, clinicians tolerate it rather than champion it, and the CFO asks whether any of it was worth the money. The post-mortem blames the vendor or patients’ lack of interest.

That’s almost always the wrong diagnosis. The Rural Health Transformation Program is now pushing hundreds of organizations through exactly this pattern on an accelerated funding clock, which makes the mistake faster to make, not a new one.

The pattern has a name, and it isn’t a technology problem. It’s a phase problem: the organization ran straight from idea to solution, with nothing built in between. Fix that gap and the technology question mostly answers itself.

Three Layers, Not One List

Across more than a decade of experience implementing telehealth services — well past a hundred of them, in at least half the states — this two-phase pattern is the single most common root cause behind a program written off as a technology failure. It’s also avoidable, because there’s a fully specified method for everything that belongs between the idea and the solution: the Ingenium Implementation System.

Our system is built from three layers that many consulting methodologies collapse into a single list: principles that hold true no matter which phase the work is in, phases that set the order of the work, and tools attached to specific phases. Collapsing all three into one list is why most methodologies read as arbitrary — a sequence of steps with no stated reason for their order. Keeping them separate is what makes this a system instead of a checklist.

Our approach carries its own name: “From Idea to Serving Patients”, and it has five phases.

Most organizations, in practice, run two: an idea, and then a solution.

The Five Phases to Success

1 – SELECTION is where an idea — usually several ideas competing for the same attention — gets narrowed down to the ones worth spending real time on. Each one gets screened against three cheap questions: does it align with the organization’s strategic goals, is it financially sound, is it clinically viable.

Selection decides which ideas deserve further investment. It does not decide whether the organization should build the thing — that judgment isn’t available yet, and answering it here, before anyone has looked closely, is how weak ideas survive on momentum alone.

2 – VERIFICATION is the phase most approaches skip entirely, running straight from idea to design.

This system puts a formal gate here instead, and it’s the differentiating phase in the whole method. The same three questions from Selection return, at far greater depth, as three cases: a Strategic Case (how, specifically, does this advance the organization’s stated objectives), a Business Case (what does it cost, what does it return, over what horizon, against what alternatives), and a Clinical Case (what’s the evidence, what’s the clinical acceptance, is there a clinical champion who will carry it).

Verification decides whether the organization should do this at all. It does not decide what the service will look like — design doesn’t exist yet. And it can only be answered by the organization itself: a vendor’s case for its own platform is not a substitute for an organization’s verification of its own service, because the two are answering different questions.

For more guidance see: “Verify Before You Start: Can Your New Telehealth Service Deliver?”

3 – SOLUTIONIZATION is where the organization designs how the service will actually run: the workflows, the vendor decision, the training, the support model, and the policy that governs all of it.

Requirements work happens at the beginning of this phase, as part of the design — writing down what’s expected of the new service before designing it is what keeps everyone from discovering, three weeks before launch, that “everybody agreed” meant something different in each person’s head.

Solutionization decides how the service shall work day to day. It does not decide whether the service should exist — that was Verification’s call, and reopening it here is usually a sign Verification got skipped or done too lightly.

4 – VALIDATION is where the organization runs a proof of concept, not a pilot.

The difference isn’t vocabulary. A pilot has a fixed calendar and an informal definition of success — let’s see how it goes. A proof of concept has a list of the assumptions the Verification cases were built on — patient acceptance, clinician acceptance, reimbursement, utilization — a way to measure each one, and a target for each measure, decided in advance, while nobody yet has a stake in the answer. It runs until the assumptions that matter are confirmed or refuted, not until a clock expires.

Validation decides whether the assumptions under the service actually hold and what aspects of the whole solution need to be tweaked before scaling it.

5 – DEPLOYMENT is where the service goes live at full scale, and where the discipline that got the organization this far has to survive contact with routine operations.

Performance gets managed to trend lines, not to individual data points, and the response to a trend moving the wrong way gets decided at the same time the target is set, not improvised three months in when someone’s program is already the subject of an uncomfortable meeting. Deployment decides how the service is sustained. It does not end at launch, whatever the project plan’s final milestone says.

The Same Three Questions, Asked Thrice

The three questions in Selection and the three cases in Verification aren’t the only two passes — there’s a third, later, during Validation. It’s the same three dimensions — strategic, financial, clinical — tested three times, each time for real rather than on paper.

Selection is the cheap screen: does this look worth pursuing. Verification is the expensive one: can the organization prove it, in writing, before anything is built or turned on. Validation is the one that happens after the service is actually running: does the alignment argued for in the Strategic Case still hold, is the return the Business Case promised showing up in real utilization and reimbursement, is the clinical acceptance the Clinical Case predicted what clinicians are actually reporting with real patients.

The same three questions, tested against reality instead of a plan.

Skip Selection, and every idea gets the full Verification treatment, which is slow. Skip Verification, and ideas that merely look good on paper reach a design phase they haven’t earned. Skip Validation — treat Verification’s cases as settled the moment they’re written down — and the organization finds out whether its own business case was ever true only after it’s already live, which is the most expensive place to learn it.

Two Principles Carry the Weight

Two ideas run underneath all five phases.

The first: the technology and its installation account for roughly 10% of whether a telehealth service succeeds; implementation is the other 90%. Vendor selection happens inside Solutionization — deliberately in the third phase’s design work, not the first thing anyone does — because the technology decision is much easier to get right after the workflows, the requirements and the organizational commitment already exist, and nearly impossible to get right before they do.

The second: “Every system is perfectly designed to get the results it gets.”. An underused telehealth service isn’t evidence of an underperforming vendor. It’s evidence of a system — workflows, training, incentives, support — that was designed, whether anyone meant to design it or not, to produce exactly that outcome. Change the system, and the people using it behave differently without anyone having to be convinced to try harder.

Buy-in Gets Earned, Not Announced

Change management runs as a thread under all five phases, too, and the phase where it matters most is the one organizations are least likely to invest in: Verification.

A Strategic and Business Case earns support from leadership; a Clinical Case earns it from clinicians. Both get built before anyone has a stake in defending a decision already made, which is the only point at which buy-in is cheap. Wait until Deployment to start building support, and change management becomes a communications plan applied to a decision nobody outside the project team was part of making — a common reason a technically sound service still fails to take hold.

What Gets Skipped

In practice, most organizations skip the front of this method entirely. An idea arrives, IT gets asked to find a vendor, and a request for proposal goes out before anyone has verified the service should exist, let alone design how it will run.

That’s not a shortcut through Selection and Verification. It’s a decision to run vendor selection — itself a compressed version of Solutionization — as a substitute for both of the phases that were supposed to come first. See: “Buying Technology for RHTP is Easy. Driving RHTP Outcomes is Not.”

The rollout that skips the front of the method still produces a launch. It just doesn’t produce a service anyone verified, designed or tested before turning it on, which is a fair description of most telehealth programs that later get blamed on the technology.

As RHTP funding pushes more organizations through this same sequence faster than most have ever moved before, the five phases aren’t a slower way to get to a working service. They’re what makes “working” a question anyone answered on purpose.

To see how the five phases turn an RHTP award into a solution that produces outcomes — not just funded activity — Ingenium’s RHTP page includes an 8-question readiness check: ingeniumdigitalhealth.com/rhtp.