Personalized Demo

What state digital health RFPs reveal about telehealth platforms that actually work

State health agencies are conducting experiments in the procurement of healthcare services. Many practice administrators are unaware of those events.

In early 2026, multiple states published formal RFPs for rural digital transformation projects. Those documents show what public sector buyers have discovered about telehealth:

  • Clinical results are more important than specific features.
  • A system’s ability to work with other tools is more important than how new the technology is.
  • Long-term viability matters more than short-term pilot success.

By reading those RFPs, administrators can access information about successful systems because the buyers have already experienced the costs of learning.

As reported by “successful,” states that published rural digital health RFPs in 2026 are asking for specific data. These buyers want measurements based on clinical results instead of total counts of actions.

There is also a focus on plans for long-term financial viability instead of short-term funding for small tests. To prevent the creation of isolated systems, buyers require commitments to interoperability.

The patterns in those documents are relevant to all healthcare organizations that are reviewing virtual care platforms.

Why State RFPs Provide Useful Information

State health agencies are cautious buyers. They write RFPs after reviewing previous projects and listening to the problems that providers report.

Agencies also observe when small programs fail after their funding ends. When many states include the same requirements in their procurement documents during the same three-month period, it indicates a significant trend.

There is a long-term record of experience within the agencies that small practices often do not have. These agencies have paid for telehealth projects that functioned well in the first year but failed in the second year.

They have seen companies go out of business. They have seen connections between systems fail. They have also seen metrics that appeared useful become ineffective.

The requirements in the 2026 RFPs are the ones that agencies have found to be accurate indicators of success.

For a behavioral health practice with five providers or a small primary care group, this information is direct market data. The state has performed the necessary research for the public.

What 2026 RFPs Are Asking For

In early 2026, three requirements appear frequently in rural digital health RFPs.

1. Clinical Results Instead of Activity Counts

Buyers want to measure clinical results rather than total actions.

Agencies want to know whether the health of the patient improved. It is no longer enough to know how many video meetings occurred.

RFPs often require vendors to track specific clinical data, including:

  • How often patients take their medicine
  • How many patients finish their follow-up appointments
  • How long it takes for new patients to receive care
  • How many emergency department visits are avoided

The platform must be able to measure those events.

2. Interoperability With Existing Systems

RFPs ask for proof that a system can exchange data. This often involves the use of HL7 FHIR standards and state health information exchanges.

If a vendor cannot show how its system connects to electronic health records or public health systems, it is excluded from the process.

3. Long-Term Viability

Vendors must provide plans for long-term viability.

This requirement is now more common than in the past. Agencies ask vendors to describe how a platform will continue to function after grant money is gone.

They also ask questions such as:

  • What does it cost to operate the system at a larger scale?
  • What happens to the data if the contract ends?
  • Who maintains the relationship with the patient after the project ends?

Small tests that cannot answer these questions do not receive funding.

Technologies and Methods That States Are Excluding

The reasons for rejecting a proposal are as useful as the requirements.

Activity-Only Metrics

By excluding metrics that only count actions, agencies show that they do not value counts of video visits or messages as proof of success.

In multiple RFPs, there is a requirement to show a link between platform use and clinical health results.

Siloed Solutions

Siloed solutions are also being rejected. This includes:

  • Standalone video tools
  • Scheduling apps that do not connect to clinical workflows
  • Small tests that create data no one can use

There have been many instances where “successful” small tests created data that no one could use.

Vendor Lock-In

RFPs now require that data can be moved easily.

There must be clauses that allow a user to leave a contract and clear rules about who owns the patient records. States have found that platforms that restrict data eventually fail to help their users.

On this point, “successful” reported that hybrid care models are causing buyers to look for platforms that connect with existing systems. It is not helpful to replace all current systems. Vendor lock-in prevents this type of integration.

The Transition From Actions to Results

When the focus moves from counting actions to measuring results, the definition of a successful telehealth project changes.

In the past, a practice with 2,000 video visits in three months was considered successful. Now, the important question is whether those visits caused better management of diabetes or faster mental health appointments.

Buyers also want to see:

  • Fewer missed appointments
  • Better patient retention
  • Faster access to care
  • Measurable improvements in clinical outcomes

Because of this change, there are practical effects on how a practice chooses a platform.

The platform must perform specific functions:

  • Record medical data with enough structure to allow the measurement of results
  • Connect to systems that store other parts of the patient’s medical record
  • Show data points that match the way medical staff and managers assess treatment quality
  • Avoid creating data that appears meaningful but cannot be used to make decisions

In the current market, a system that focuses only on video meetings and scheduled times is not sufficient.

In 2026, the systems organizations select are the ones that include all stages of the patient experience:

  • Initial registration
  • Scheduling
  • Messaging
  • Video meetings
  • Follow-up check-ins
  • Reporting

All of these functions need to be available in one location.

Lessons for Medical Offices Outside Rural Areas

Rural areas have strict limitations. For example, they often have:

  • Low-speed internet connections
  • Few employees
  • Small budgets
  • A low number of patients per medical professional

Because these limitations exist, the requirements for software become more effective for all users.

If a software system functions in a rural location, it is usually:

  • Consistent when internet speeds are low
  • Simple for employees without specialized technical training to operate
  • Less expensive when the number of users is small
  • Fast to set up without the help of a specialized computer team
  • Created so that the user is not forced to stay with one provider

If you manage a medical office with 5–50 providers in any location, those are the features that are necessary for your work.

By contrast, the “enterprise telehealth” message is usually made for large organizations that have specialized purchasing departments. Software for rural areas is less complex, faster to set up, and easier to stop using if it is not functional.


How to Assess Your Own Software Using State Government Standards

To assess your software, you can use the same system that government agencies use.

When you look at a system for medical video meetings that you use or want to buy, ask the following questions.

Results

Is the software able to create reports on medical results that match your standards for treatment quality, or is it only able to show how many tasks were completed?

Connection

Is the software able to send and receive organized data with your electronic health records, billing system, and legally required reporting systems?

Continuity

What are the actual costs to run the system in its third year?

Is it possible for you to pay those costs without money from outside sources?

Data Movement

If you stop using the software, is it possible to move your data to a new system in a format that you can use?

Structure

Does every customer have their own separate digital framework, or are you using the same digital space as other people?

Setup Time

Is it possible to start using the system in a few weeks, or will the project take many months to complete?

History of Use

Are there examples of the software working for many people, or is your office the first one to test it?

For offices that evaluate white-label telehealth platforms using these standards, systems with a single-tenant structure are often better for keeping data separate and making changes.

Then again, software that has already been used by millions of patients is less likely to cause problems because the system has already been tested.

Next Steps

By reading multiple government requests for digital health software, you can test whether the claims of a seller are accurate.

As public agencies have learned what to require, those standards often show which software remains in use after two years.

If you want to see how a system for more than 1,000,000 patients and 200 clinics works according to these standards, you can request a demo and ask the same questions that a government evaluator would ask.

This image has an empty alt attribute; its file name is request-banner-2-1440x474.png