Digital Health Solutionization:
From Start to Sustainability

Most digital health services that fade away were never designed to last. They were approved, purchased and launched, and then kept alive by whoever cared most. Whether a new service is still running two years later is rarely decided at the end. It is decided months earlier, in a phase most organizations don’t realize they skipped.

That phase is Solutionization. Yes, it is a made-up word. It earns its chuckle and then it earns its place: it names the work between an idea that has been verified as worth doing and a service that is live and serving patients.

The Ingenium Implementation System takes a new technology-enabled service from idea to serving patients in five phases: Selection, Verification, Solutionization, Validation, and Deployment. Selection filters ideas. Verification asks whether a service should exist at all. Solutionization designs how it will actually run here — with these clinicians, this staff and this budget. Validation tests it in a proof of concept. Deployment scales it.

The question is especially pressing for organizations implementing projects funded by the CMS Rural Health Transformation Program (RHTP). Every award has an end date, and CMS expects outcomes that outlast the funding period. The same logic applies to any new service, whether it’s funded by a grant, a foundation or the operating budget. Once the launch money and launch energy are gone, what remains has to run on its design.

Five Dimensions, Two Blind Spots

Sustainability is not one thing. A service has to hold up along five dimensions:

• Strategic Sustainability — it keeps advancing what the organization is trying to achieve.

• Financial Sustainability — it pays for itself, or it is deliberately funded.

• Clinical Sustainability — clinicians trust it as good medicine.

• Operational Sustainability — the organization can run it, day after day.

• Human Sustainability — the people who carry it can keep carrying it.

Three of these are tested before any design exists. Verification builds a Strategic Case, a Business Case and a Clinical Case, and a service that fails any one of them should not go forward.

The other two can’t be tested at that gate. “Can we run this?” and “What will this cost the people who do the work?” have no answer until there is a design to evaluate. So operational and human sustainability get designed in Solutionization, or they don’t get designed at all.

That is the principle underneath this phase: sustainability is designed in, not enforced. A service that survives on grant money and one champion’s goodwill was never designed to last.

The Five Deliverables, Read for Sustainability

Solutionization produces five deliverables: policy, workflows, technology, support, and training. An earlier Telehealth Tuesday article walks through that sequence and why the order matters. This article looks at them from the other end: what each deliverable protects.

Policy — the clinical and financial foundation. Eligibility, scope, standard of care, consent, licensure, documentation, billing and escalation authority. Every downstream decision inherits these rules. Without a written policy, each clinician invents their own standard and billing gets worked out one denied claim at a time. (Creating a telehealth policy)

Workflows — the operational and personal core. A workflow is a series of predefined actions taken by multiple people in response to a trigger, and a telehealth service runs on seven of them, from scheduling to billing. This is where workload is either designed or discovered. Design the Happy Day scenario first — the 80–90% of visits that go as planned — then give the alternate and exception scenarios systematic, bounded attention. A workflow that quietly adds a few minutes to every visit for the nurse is a human sustainability problem. Six months later it will be diagnosed as resistance.

Technology — the financial check. Compared against workflows already designed and evaluated on total cost of ownership rather than purchase price. Often the right answer is the technology the organization already has. Doing the due diligence shows which compromises come with it. (Vendor selection resources)

Support — operational sustainability, made explicit. Launch support, optimization support and operational support are three different jobs and the third one never ends: troubleshooting, onboarding new staff, monitoring utilization and quality. The structure that lasts puts support in a central team and ownership in the clinical teams that deliver the care. A central team that owns every service produces dependency. A central team that supports services owned locally produces a program. (The 7 Skills of a Rock Star Telehealth Coordinator)

Training — human and clinical sustainability. Designed here and delivered in Deployment. It opens with why: the Strategic, Business and Clinical Cases from Verification come back as the first module. Then it covers workflows, technology, policy, and best practices such as webside manner and the virtual physical exam. It also has to cover how the next hire gets trained, long after launch, because staff turnover is the quiet test every healthcare service eventually faces. (Telehealth training resources)

Two Services, Eighteen Months Later

What does a service deployed without conscious design look like eighteen months in? A single clinician who believes in it. A coordinator who handles the scheduling workarounds from memory. A platform license renewed automatically because nobody decided not to renew it. Utilization data that goes unreviewed. When the champion leaves or the grant ends, the service goes with them.

A consciously designed (“solutionized”) service looks less exciting and lasts longer. The policy says who is eligible and how visits are billed. The workflows are written down, so a new medical assistant can learn them in a morning. Support has a name and a phone number. Training exists for the next hire, not only the launch cohort. The service belongs to the clinical team that delivers it.

Both can run on the same platform. The difference between them was decided in Solutionization.

Designed With the People Who Carry It

Change management runs under every phase. In Solutionization it has a specific job: putting clinicians and staff in the room when their workload gets designed. The front-line team knows where the extra steps will land and which current practices are worth protecting. Designing with them rather than for them addresses the personal dimension before it turns into a turnover problem. It also protects the buy-in that was earned at Verification.

Designing Past the Launch

Funding makes it possible to start, whether it comes from RHTP, another grant or the operating budget. Solutionization is what makes it possible to continue. The organizations still running their digital health services two years from now will be the ones that designed policy, workflows, support and training to hold up once the funding, the launch energy, and the original champion are gone.

Technology accounts for roughly 10% of what makes a digital health service succeed. Solutionization is a large share of the other 90%.

Organizations implementing RHTP-funded projects can see how Solutionization fits into the full path from award to lasting outcomes at ingeniumdigitalhealth.com/rhtp. For everyone else, our resources page provides guidance on the policy, workflow, vendor selection, and training referenced above.