In Digital Health, Turning On the Vendor
Is the Last Step, Not the First

While the CMS RHTP program was announced over a year ago, it is not until these months in the fall of 2026 that we are beginning to see organizations receiving actual contracts to start their transformation of health care in rural communities.

As I indicated last week the clock for demonstrating outcomes in return for the funding in this first funding period is already ticking: Funding must be expended by September 30, 2027 and your state will come knocking on your door for some results as early as June 2027.

However many months you have once the contract is actually in place, it will feel short. It is short. And it produces a very specific, very understandable instinct: move fast, and moving fast in many cases means picking a vendor.

That instinct is the trap. Not because urgency is wrong — the deadline is real — but because the fastest path to a vendor selected in the first month is often the slowest path to a service actually producing RHTP-worthy outcomes months later.

Solutionization before Contractualization

The organizations that lose the most time on RHTP-funded digital health projects aren’t the ones that moved slowly to pick a solution. They’re the ones that moved straight to buying the technology before anything else was settled, then spent the back half of the grant period backfilling for the aspects that a technology vendor never signed up for.

There’s a name we use for the phase that sits between deciding a service is worth doing and proving it works: Solutionization.

It’s the middle of the implementation arc — Selection, Verification, Solutionization, Validation, Deployment, Performance Management — and it’s the phase where a digital health service actually gets designed, as opposed to funded or installed.

Most RHTP timelines budget time for the vendor selection and time for the rollout. Few budget real time for the phase in before that, which is exactly why it’s the phase that gets skipped, compressed, or quietly handed off to whichever vendor answers the phone first.

Solutionization isn’t one decision. It’s five, and they have a required order.

The order matters as each deliverable constrains the one after it. A workflow designed before policy exists will eventually collide with a rule nobody wrote down. A vendor selected before the workflow exists will have to be worked around rather than worked with.

Diagnose before you prescribe — the same discipline that governed whether this service should exist at all back in Verification governs how it gets built here. Reverse the order and you’re not saving time. You’re borrowing it, at the risk of running afoul of non-negotiable RHTP reporting deadlines.

5 Steps to Building the Solution

Policy 1st. Before a workflow gets drawn or a demo gets scheduled, somebody has to decide the rules everything else inherits: who’s eligible, what’s in scope, what standard of care applies, how consent works, which license covers which encounter, what gets documented, who has the authority to escalate. Skip this step and every downstream decision — the workflow, the vendor contract, the training curriculum — ends up making its own quiet policy call, usually inconsistently, and usually discovered during an audit rather than a design session.

Workflows 2nd. A workflow is a defined set of actions, by defined people, in response to a defined trigger — scheduling, onboarding, rooming, the visit itself, post-visit, follow-up, billing. Design for the happy day first: the 80 to 90 percent of encounters that go as planned. That’s where the creative energy belongs. The exceptions and edge cases get systematic, bounded attention afterward — not because they don’t matter, but because teams that start with the “what if” rabbit holes rarely finish the workflow that actually needs to ship.

Vendor selection 3rd — not 1st. This is the order most everyone gets backward, and it’s worth stating plainly: process must drive technology, not the other way around. Don’t put the horse behind the cart. A vendor conversation that starts before policy and workflow exist is a vendor conversation with nothing to evaluate against except the sales deck.

Run vendor selection in three phases instead:

1. Define the needs and requirements the workflow already generated.

2. Evaluate finalists against those requirements with the people in the room who will actually use the tool.

3. Then implement and transition with a proof of concept built in from the start — never a pilot, because a pilot has no formal way of saying it worked.

Clinicians should be driving the vendor decision, since they interact with digital health solutions most. Too often they’re absent from it, because their time is scarce — which is exactly the gap a facilitated process exists to close, not an excuse to skip the process. Watch for two more predictable friction points here. A clinician who’s genuinely enthusiastic about a particular platform can be an asset or a liability, depending on whether that preference goes through the same evaluation as everyone else’s or quietly skips it.

IT leadership brings real, necessary judgment — security, reliability, compliance, supportability — but that judgment is not the same as user experience, and treating it as the whole evaluation hands the decision to the wrong stakeholder.

Setting up Support is 4th. A service needs three different kinds of support, and they are not interchangeable:

1. Launch support to get people through the first weeks.

2. Optimization support to keep improving once the launch energy fades,

3. Operational support for the ordinary business of troubleshooting, onboarding new staff, and watching whether utilization and quality are holding steady.

Central teams do their best work supporting services that clinical teams own locally. Organizations that only plan for the first kind of support are planning for a launch event, not a program.

Training 5th — designed here, delivered later. Training earns its place at the end of Solutionization because it can’t be built honestly until the other four are settled. And it should open with why, not with which buttons to press: the strategic, financial, and clinical case for the service — the same case that earned buy-in back at Verification. Skip straight to workflow and technology training and the result is a procedural onboarding, not a persuasive one. Clinician adoption runs on persuasion first, competence second.

Design for Tracking Outcomes

There’s a reporting dimension to this too, one that’s easy to miss under the pressure of a compressed timeline. Every RHTP award carries an expectation of demonstrated outcomes — utilization, quality, the metrics a state agency or CMS will eventually ask about. Those metrics don’t appear during Performance Management out of nowhere. They trace back to assumptions made explicit during Solutionization and tested afterward in a proof of concept. Skip the carefully sequenced solution design work now, and the team producing an outcomes report later is reconstructing, after the fact, decisions that were never written down in the first place.

The Other Ninety Percent

None of this is an argument for slowing down. However much runway you end up with, it’s fixed either way once the deadline is set. The opportunity is to decide what the time should be spent on.

A team that spends a few focused weeks on policy and workflow before touching a vendor contract will spend far less time later renegotiating a decision that never should have been made in the first place.

In our 15+ years of digital health implementation experience, Technology accounts for only roughly ten percent of what makes a digital health service succeed. The other ninety percent is exactly this: the unsexy, ordered sequence of work that turns a funded idea into a service a rural clinician will actually use and a rural patient will actually trust.

RHTP is putting real money behind rural digital health, in every state, on a deadline that isn’t moving. What RHTP didn’t change is the sequence that decides whether that investment produces a service still running in year three or a technology nobody adopted by year one.

For some rural teams right now, that isn’t a competence gap — it’s a capacity gap, five deliverables deep, arriving when everyone’s calendar is already full.

If proper solutionization, change management, project management, or grants management is more than your team has the bandwidth or expertise for right now, take a look at what Ingenium’s RHTP implementation support looks like: ingeniumdigitalhealth.com/rhtp