Digital Health Commercialisation: From Patient Activation to Paid Care

Offering a digital-health programme is the beginning of a care pathway. Patients still need to activate it, provide usable information and receive the service specified by the programme. The commercial model may pay for covered members, delivered care or an institutional licence; each makes a different part of the pathway economically important.

This article follows activation into sustained use, provider workflow and paid service. It asks which evidence is needed at each hand-off and where patients leave the pathway. The source window ends in December 2025; reimbursement and intended-use examples retain their jurisdiction and programme limits.

Define the programme and its participation funnel

Write the counting rule beside every adoption number. “Adoption” may mean a health system purchased a platform, a clinician was provisioned an account, a patient was offered access, a patient activated an account, a user opened an app, a device transmitted data, or a clinician acted on that data. Each is a different event with a different denominator.

The FDA description of digital health covers mobile health, health information technology, wearable devices, telehealth, telemedicine, sensors, software, and related uses. That breadth is useful for scope, but it also makes an unqualified “digital health users” total commercially weak. A patient portal, a remote-monitoring device, a clinical decision-support function, and a consumer wellness app do not share one utilization pathway.

Record the product function, buyer, user, geography, period, channel, denominator, and event definition. State whether the observation is a stock of contracted organizations, a flow of new activations, a count of active users, a number of monitored days, a clinical encounter, a claim, or recognized revenue. If the source does not state the denominator or observation window, mark the result unresolved rather than converting it into a rate.

Separate availability, activation, engagement, utilization, and payment

Use a staged vocabulary:

1. Available: the product is offered, contracted, listed, or technically accessible.
2. Activated: a user or organization completes the setup needed to enter the service.
3. Engaged: the user returns, records information, completes a task, or participates in a workflow.
4. Utilized: the defined clinical, administrative, or monitoring service occurs at the required cadence.
5. Paid: a payer, provider, employer, consumer, or other customer pays under a valid route.
6. Recognized: the supplier records revenue under the applicable contract and accounting policy.

The ONC 2024 patient-portal and smartphone-app brief illustrates why the stages must stay separate. It distinguishes being offered online access from accessing a portal, and it reports access at least once during the past year. That is meaningful engagement evidence, but it is not a measure of paid digital-health services. A portal can be included in a health system's operating cost, a payer contract, or a free patient-access obligation without producing a separately billable event.

Build a stage ledger before calculating conversion. Do not multiply a count of available seats by an assumed activation rate and call the result paid utilization unless each factor is evidenced and measured at the same grain.

Scroll horizontally to compare all columns.

Do not add the rows together. They are checkpoints in a path, not mutually exclusive market segments.

Patient cohorts and the provider workflow

Digital health has several buyers and users. A provider may buy a workflow platform while a patient supplies data. A payer may fund a program while a clinician delivers the intervention. An employer may sponsor access while an employee decides whether to use it. A consumer may subscribe directly, with no reimbursed service at all. The same product can have different paid-utilization rules in each route.

Define the cohort by buyer, user, condition, setting, and service. For a remote-monitoring product, separate eligible patients with a covered condition from all patients who could technically pair a device. For a patient portal, separate people offered access from those who use a feature that matters to the provider's workflow. For a digital therapeutic, separate a download from a prescribed course, adherence, clinical assessment, and payer or employer payment.

A pathway map should name the handoffs: procurement, implementation, enrollment, consent, setup, first use, repeat use, clinical review, intervention, claim or invoice, payment, renewal, and discontinuation. Missing handoffs are commercial unknowns, not reasons to assume a smooth funnel.

Map patient and provider activation

Activation has at least two sides. The patient or member may need to accept an invitation, create credentials, pair a device, or complete onboarding. The provider may need to configure a workflow, assign staff, connect an electronic health record, and decide who reviews alerts. A product can have high patient activation in a pilot while the provider workflow remains too costly to sustain.

Measure the cohort and clock for each side. “Activated” could mean a completed registration, a first data transmission, a first message, or a configured clinical pathway. Keep those definitions separate. Record invitation-to-activation time, device setup completion, failed connections, staff training, and the percentage of eligible users who never reach first use.

The ONC brief reports that provider encouragement is associated with higher portal access: in the 2024 survey, 87% of people encouraged by their provider accessed a portal at least once compared with 57% of those not encouraged. That comparison describes an observed association within the survey denominator; it does not prove that encouragement creates paid utilization. A commercial model should therefore keep intervention cost and downstream payment visible.

Sustained use, clinical work and integration

One access event is rarely the service. A monitoring program may require readings across a 30-day period. A behavioral program may require completed sessions. A provider workflow may require an alert to be reviewed and acted on. A digital therapeutic may require a prescribed course with documented adherence. Choose the utilization cadence that matches the product's intended outcome.

The CMS remote patient monitoring page describes three components: education and setup, device supply with at least two days of transmitted readings in a 30-day period for eligibility, and treatment or management using the data. Those components show why a connected device or downloaded app is not the same as a covered monitoring service. A reading also needs context: valid device, correct patient, required period, and a provider action that fits the service rule.

Track active days, completed tasks, valid data days, missing-data reasons, alert-review time, intervention completion, and return or replacement events. Distinguish a failed transmission from a user who deliberately stopped. If the source provides only monthly active users, do not infer clinical adherence or billable utilization.

Distinguish app use from clinical workflow

An app can be opened for a notification, a test result, a prescription refill, a health article, a video visit, or a clinical intervention. Those actions have different commercial and clinical meanings. Aggregate sessions hide the event that a buyer needs to value.

Create an event taxonomy with a user, timestamp, purpose, completion state, and linked workflow. Examples include viewing a result, sending a message, completing a questionnaire, transmitting a physiologic reading, receiving a clinician review, changing a treatment plan, or completing an invoiced consultation. Keep passive exposure, self-management, administrative use, and clinical decision support separate.

For provider products, link the event to a role and task. A clinician opening an alert is not the same as a patient sending a reading; a reviewed alert is not automatically a medication change. For consumer products, link a paid subscription to the service unit actually sold: a plan month, coaching session, treatment course, or transaction. Avoid “engagement” as a catch-all for every click.

Reconcile interoperability and integration

Technical connectivity is an adoption enabler, not a proof of utilization. A hospital may have an interface available but use it for one department or one direction of data flow. A vendor may advertise EHR integration while the buyer relies on manual exports. Integration can reduce friction without producing a paid service until a contract, workflow, and user cohort are active.

The ONC hospital API brief reports that hospitals use APIs for patient access and patient-generated-data submission, while also describing differences between standards-based and other exchange methods. It notes that hospitals may integrate data from third-party technology more often than they provide data back to the third party. That asymmetry matters: receiving a glucose reading can support a workflow, but it does not prove the vendor is paid per reading or that every connected hospital has active patients.

Record interface type, direction, data elements, latency, site coverage, and error rate. Reconcile implementation milestones with actual event volumes and active sites. If integration is sold as a one-time implementation, keep that revenue stream separate from recurring utilization or per-member payment.

Intended use and evidence of value

Adoption and payment can be constrained by what the software is intended and permitted to do. A wellness tracker, an app that stores patient-entered information, a clinical decision-support function, and a regulated medical-device software function have different evidence and oversight questions. A product can be widely used without being authorized for a higher-risk clinical claim, and regulatory status does not establish payer coverage.

The FDA policy for device software functions and mobile medical applications applies a risk-based, function-specific approach. It distinguishes software functions that are medical devices from functions for which the FDA intends enforcement discretion. The FDA examples of non-device software functions include functions that record or share health data without making the clinical decision. Those boundaries help define what adoption evidence can and cannot support.

Keep intended use, jurisdiction, authorization or enforcement-discretion status, version, and effective date in the product ledger. Do not count downloads of a general wellness feature as adoption of a regulated treatment, and do not treat clearance as proof that a payer will reimburse the software.

Test evidence for adoption and clinical value

Evidence has layers. Product analytics can show what users did. Claims can show a submitted or paid service. Clinical records can show a diagnosis, intervention, or outcome. A survey can show perceived access or use. An evaluation can examine clinical or economic effect. None should be substituted for another.

The FDA guidance on digital health technologies for remote data acquisition in clinical investigations focuses on using hardware or software to acquire data remotely from participants in clinical investigations. It highlights a research-use context with data-quality and participant considerations; it does not create a commercial utilization rate. Use study participation, data completeness, and endpoint evidence as separate fields from paid customer use.

For purchasing decisions, the NICE Evidence Standards Framework for Digital Health Technologies gives evaluators and commissioners a framework for judging evidence relevant to health and care technologies. A buyer can use that structure to ask whether a product has evidence for its intended function, implementation, outcomes, and economic value. Evidence readiness can unlock a contract without guaranteeing patient engagement or renewal.

Write the evidence question beside each metric: reach, activation, adherence, clinical action, outcome, cost, or payment. If a pilot has no control group or the denominator changes, preserve the limitation rather than turning the pilot into a market-wide adoption rate.

The payer, contract and service-payment route

Payment has its own eligibility and service rules. A payer may cover a remote service only for certain conditions, providers, device types, data cadence, or documentation. A code may represent setup, data supply, treatment management, or a different service. A covered benefit can still fail commercially if the provider cannot staff the workflow or the allowed amount does not cover acquisition and support costs.

CMS lists remote patient-monitoring components separately and explains that Medicare pays for the three main components using procedure codes. CMS also updates remote therapeutic monitoring codes through its therapy-services guidance. The Telehealth and Remote Patient Monitoring MLN booklet provides additional billing boundaries, including coordination rules with other care-management services. These sources support the payment path; they do not establish a vendor's realized price or renewal rate.

The CMS Physician Fee Schedule documentation explains that fee-schedule files and relative-value inputs describe Medicare payment calculations. Keep the allowed amount, provider reimbursement, vendor contract price, member contribution, and supplier recognized revenue separate. A procedure code in a claim is evidence of a billed service, not proof that the vendor received the listed rate.

Segment payer, provider, and contract route

Paid utilization depends on who controls access and who bears the cost. Segment public payer, private payer, employer, provider budget, self-pay subscription, research sponsor, and platform license. Within each route, identify the contracted unit: eligible member, enrolled patient, monitored day, completed session, provider seat, site, encounter, or monthly platform fee.

Then add the provider operating model. A health system may centralize enrollment while a clinic supplies the clinician time. A payer may pay a per-member fee while providers absorb setup. An employer may sponsor access without a clinical claim. A consumer subscription can show recurring payment without clinical utilization. The same product name can therefore produce incompatible revenue and utilization series.

Use geography and coverage alongside the route. State policy, payer contracts, licensing, benefit design, language, broadband, device access, and provider capacity can change the eligible cohort. If a product enters a new payer network, distinguish newly covered lives from newly active users and from newly paid services.

Model unit economics and revenue events

Build a commercial bridge with explicit units:

eligible cohort × enrollment rate × activation rate × sustained-use rate × qualifying-service rate × net paid value

This is a structure, not a universal formula. A platform license may be priced per site or provider seat rather than per patient. A remote-monitoring service may combine device supply, setup, treatment management, and support. A digital therapeutic may be sold per course, while an employer program may be priced per eligible member with low actual engagement.

Keep acquisition, onboarding, device, connectivity, clinician time, support, claims administration, integration, and renewal costs separate. Record when the supplier earns the implementation fee, subscription, per-use charge, or outcome payment. A signed contract, an invoice, a collected payment, and recognized revenue are different events. If the contract or recognition policy is not available, leave the commercial endpoint unavailable.

Retention and a qualifying-service scenario

Adoption can rise while paid utilization falls when new users replace inactive ones, when a payer expands eligibility but engagement declines, or when a provider switches to an alternative workflow. A high monthly active-user count can hide short sessions, low adherence, or a one-time onboarding campaign. A low user count can still support a profitable specialist service if the payment per qualifying unit is high and retention is strong.

Use cohort retention rather than a single cumulative user total. Track first activation, second-period return, qualifying-service completion, renewal, pause, churn reason, reactivation, and substitution. Separate patient churn from provider-site churn and payer contract loss. Keep migrations between app versions or vendors visible so a retained clinical relationship is not misread as a new market adoption event.

Substitution also changes the denominator. A digital visit may replace an in-person visit, a remote-monitoring workflow may replace a telephone check, or a provider may move from one platform to another. The product can lose paid volume while the underlying care activity remains stable. Identify the replaced service and compare total pathway utilization before declaring demand destruction.

Apply a buyer-specific adoption-to-paid filter

For a digital-health operator, payer, provider, investor, or market-access team, test the opportunity in eight stages:

1. Function boundary: define the digital function, intended use, jurisdiction, and product version.
2. Buyer and user: identify who contracts, who pays, who uses, and who supplies clinical work.
3. Access cohort: define eligible lives, sites, providers, conditions, geography, and period.
4. Activation and engagement: document invitation, setup, first use, repeat use, adherence, and data quality.
5. Workflow: connect user events to clinician review, intervention, referral, or completed service.
6. Payment gate: test coverage, code or contract, documentation, provider eligibility, and allowed amount.
7. Economics and timing: separate acquisition, delivery, support, renewal, invoice, collection, and recognition.
8. Decision threshold: choose the governing output: qualifying users, monitored days, paid services, net revenue, gross margin, retention, or avoided cost.

The result should be a cohort ledger with unavailable fields visible. “Two million people have access to the app” is an availability or reach statement. “A defined payer cohort completes the qualifying service at the required cadence, the provider performs the covered workflow, the claim or contract is paid, and the supplier retains the account” is a paid-utilization case that can be tested.

Test a fictional adoption-to-paid bridge

The following bridge is deliberately fictional. It demonstrates the calculation structure and does not represent a product, payer, provider, patient cohort, reimbursement rate, market size, market share, or revenue forecast. Every number is invented solely to show how a buyer can keep availability, behavior, workflow, payment, and retention separate.

Conceptual adoption-to-paid-utilization flow for analysis only. The arrows show an evidence sequence; they do not show proportional magnitude or forecast confidence.

Scroll horizontally to compare all columns.

The fictional calculation would be 20,000 eligible members × 40% activation × 60% second-month return × 50% qualifying-service completion × 38 net currency units, with the retained cohort reviewed separately. It is intentionally not presented as a market result. A real bridge would replace each input with contract eligibility, product events, clinical workflow records, coverage and code rules, paid claims or invoices, cost-to-serve, and cohort renewal evidence.

The next research questions should be explicit: Which members and sites are eligible? What setup step is required? What counts as an active day or completed intervention? Which clinician action makes the service qualifying? Who pays and under which code or contract? What deductions, support costs, and integration fees reduce net value? When does the supplier recognize revenue? Which users renew, churn, switch, or remain clinically served through another channel? Answering those questions is how adoption becomes a defensible paid-utilization analysis without pretending that access or app activity is revenue.

Measure drop-off where it changes the contract outcome. A per-member programme may need durable enrollment and service capacity; a service-paid model needs eligible, documented care and accepted payment. Keep those denominators distinct when comparing suppliers. A smaller cohort completing the intended pathway can be commercially more useful than a larger registration total.