7 Digital Health Business Models (and Who Actually Pays)
Digital health companies get paid seven distinct ways: SaaS subscriptions sold to providers, per-member-per-month (PMPM) contracts with payers or employers, fee-for-service billing per encounter, value-based contracts tied to outcomes, marketplace commissions on a transaction, direct-to-consumer (D2C) purchases, and licensing deals that power someone else's product. Each implies a different buyer, sales cycle, and evidence bar — picking the wrong one is a slower way to fail than picking the wrong market.
Quick Answer: The seven common digital health business models are SaaS, PMPM, fee-for-service, value-based/risk contracts, marketplace, D2C, and licensing/white-label. Match the model to whoever actually benefits enough to pay — that's rarely just "the user" — and validate willingness to pay before you build around any one of them.
If you've mapped healthcare's buyers before, you already know the punchline: your business model has to fit whichever buyer you picked, not the other way around. Who pays for digital health explains why providers, patients, payers, and employers rarely overlap. This piece goes one layer deeper — for a given buyer, which pricing and contracting structure actually gets a check written, and what you need to prove before you build around the wrong one.
How to choose a digital health business model
Choose a business model by matching three things to your product: who receives enough value to justify paying (payer alignment), how much proof they need before they'll sign (evidence bar), and how you'll actually reach and close them (sales motion). Get any one of the three wrong and the other two won't save you.
- Payer alignment. The party who pays has to be the party who benefits, directly or through a chain of incentives they actually feel. A model that bills a provider for savings that accrue to a payer will stall no matter how real those savings are — the bill and the benefit have to land on the same desk.
- Evidence bar. A patient paying out of pocket needs a trustworthy experience. A health system needs a workflow case. A payer needs outcomes data across a population. Match your validation effort to the bar the model actually sets, not the bar you'd prefer.
- Sales motion. Consumer marketing, clinical sales, and payer contracting are three different disciplines that share almost no playbook. Choosing a model is really choosing which of those disciplines your company gets good at first.
The way to find out which model fits is not to guess — it's to run the smallest test that would tell you the truth, in the spirit of the experiment library in Testing Business Ideas: a letter of intent with a number attached beats a landing page, and a signed pilot beats both. If you haven't yet run a structured pass on the underlying idea, do that first — the complete guide to startup idea validation walks through the process this article assumes you've already started.
SaaS: subscriptions sold to providers and health systems
SaaS is the most familiar digital health model and the easiest to explain to investors — but it only works when the software saves a provider organization more time or money than the subscription costs, and someone inside that organization controls a software budget for exactly this problem.
Typical buyers are clinics, hospitals, and health systems paying for workflow tools, care coordination platforms, documentation assistants, or patient engagement software, usually priced per seat, per facility, or per provider. The sales cycle runs months, gated by procurement and IT security review rather than by enthusiasm from the clinicians who'll actually use it. Pricing tends to tier by usage or facility size, with expansion revenue coming from adding departments or locations once the first one proves out.
The trap is a crowded budget line: hospitals already run dozens of point solutions competing for the same compliance-driven purchasing cycle, and a tool that's merely "nice to have" loses to whatever is mandatory this year.
Validation test: find the person who owns a software budget for this specific use case, show them the actual time or cost your product would save, and confirm they can point to a real budget line — not just interest — before you build deep integrations.
Per-member-per-month (PMPM): pricing to payers and employers
PMPM works when you can show that an intervention reduces total cost of care or improves a specific, measurable outcome across a covered population — it is a payer and employer model, not an individual-consumer one, because no single member decides whether the contract renews.
The buyer pays a fixed fee for every enrolled member, whether or not that member ever uses the product, which is what makes PMPM attractive to a payer trying to budget population health spend predictably. It shows up most often in chronic condition management, virtual primary care, and behavioral health, contracted with insurers or self-funded employers on an annual or multi-year basis. The sales cycle is long and tied to renewal cycles, and the pitch has to be framed in the buyer's own cost or utilization terms, not in user-experience terms.
Validation test: before pricing anything PMPM, ask the buyer what specific cost or utilization number they'd need to see move, by how much, and over what period, to renew the contract. If they can't answer that question concretely, you don't have a PMPM buyer yet — you have an interested contact.
Fee-for-service: getting paid per visit, test, or encounter
Fee-for-service is the most transactional and fastest to validate of the seven models, because each unit of service carries its own price and its own proof point — but your margin is exposed to reimbursement or cash-pay rates you don't fully control.
This model covers telehealth visits, diagnostic tests, remote monitoring days, and cash-pay encounters billed individually rather than bundled into a subscription. It can be paid by a payer through a billing pathway, by a provider organization purchasing the service wholesale, or directly by the patient. Because each transaction is discrete, you can validate demand one unit at a time — run a small number of real, paid encounters and see whether people or institutions actually pay for the next one.
The trade-off is exposure: if reimbursement rates for your billable unit shift, or a payer changes what it will cover, your unit economics move with it, and you have limited control over that policy.
Validation test: confirm there's an actual billable or cash-payable unit behind your service — a visit, a test, a monitored day — and that someone will pay for that unit today, not once you scale enough to negotiate a better rate.
Value-based and risk-based contracts: getting paid for outcomes
Value-based contracts pay you for the outcome you produce rather than the service you deliver, which sounds ideal until you realize you're accepting some of the payer's financial risk in exchange — this is the highest-ceiling and highest-evidence-bar model of the seven.
Structures range from shared-savings arrangements, where you split the cost reduction you help create, to fuller risk contracts closer to capitation, where you're paid a set amount and bear the cost if outcomes run worse than expected. These deals almost always layer on top of an existing fee-for-service or PMPM relationship once you have a track record to negotiate with, rather than serving as a company's first contract. Understanding how healthcare reimbursement actually works — the coverage decisions and billing pathways underneath any payer-facing model — matters most here, because a risk contract without a real reimbursement pathway underneath it is a bet, not a business model.
Validation test: don't sign a risk contract as your first deal. Prove the underlying outcome under a lower-risk model first — fee-for-service or PMPM — then negotiate for value-based upside once you have your own data to negotiate with, rather than a projection.
Marketplace: taking a cut of a two-sided transaction
Marketplace models are attractive because you're neither the direct payer nor the direct provider — you just take a cut when a transaction happens. But they inherit the classic two-sided cold-start problem, and in healthcare each side also carries its own trust and compliance bar that consumer marketplaces don't.
Examples include matching patients with specialists or clinical trials, or matching clinicians with facilities that need staffing. Revenue comes as a take rate on each completed match, so the model scales with liquidity rather than headcount — but liquidity is exactly what's hardest to bootstrap in a fragmented, locally-licensed industry like healthcare. A marketplace with a large number of sign-ups on both sides but no density in any single specialty or metro area has not proven it can reliably produce a match.
Validation test: prove you can manufacture liquidity in one narrow segment — one specialty, one metro area, one shift type — manually if you have to, before you build the matching engine. Total sign-ups on both sides don't validate a marketplace; a repeatable match does.
Direct-to-consumer (D2C): patients paying out of pocket
D2C is the fastest model to test and, in health, one of the hardest to sustain, because the same retention and behavior-change problems that hit every consumer subscription are compounded by an expectation that health costs get covered by someone else.
The appeal is real: short decision cycles, marketing-driven acquisition, and fast iteration, all of which feel familiar if you came from consumer software. The risk hiding underneath that familiarity is that people paying out of pocket for health products are a self-selected slice of the population, and strong sign-up numbers can mask a conversion rate to paid that's far thinner than it looks — and a retention curve that falls off a cliff once the initial motivation fades.
Validation test: get a real payment method on file — a pre-order, a deposit, a live paywall in front of a working product — before polishing anything further, then track whether people are still paying and using it sixty and ninety days later. First-week sign-ups measure curiosity, not a business.
Licensing and white-label: powering someone else's product
Licensing works when your technology is valuable enough that a larger, already-distributed company would rather rebrand it than build it themselves, trading a lower per-unit price for someone else's distribution and sales force.
This is a B2B2B model: you license your technology to an EHR vendor, a pharma company, another digital health platform, or a health system that wants to offer it under its own brand. Revenue comes as a licensing fee, an integration fee, or a revenue share, and a single deal can move a large volume of end users at once — which is the appeal. The risk is dependency on a partner's roadmap and the possibility that the partner eventually builds a version internally, so this model only holds up long-term if your technology or data has an advantage that's genuinely hard to replicate.
Validation test: get a signed pilot or a paid integration agreement with one distribution partner before assuming licensing is your path to scale. A partner who is "excited" about your technology is not the same as one who has cleared it through their own procurement and product roadmap.
Comparing the 7 digital health business models
The seven models differ most on who pays, how long it takes to close them, how much proof they demand, and what margin profile they leave you with. The table below lines them up on all four so you can see the trade-off at a glance before you commit to one.
| Model | Primary payer | Typical sales cycle | Evidence bar | Margin profile |
|---|---|---|---|---|
| SaaS | Provider / health system | Months, gated by procurement | Workflow fit and a clear time/cost case | High gross margin; scales with seats |
| PMPM | Payer / employer | Long, tied to annual renewal cycles | Population-level cost or outcome evidence | High margin at scale; heavy upfront evidence investment |
| Fee-for-service | Payer, provider, or patient, per unit | Short per unit; ongoing at volume | A real billable or payable unit exists | Margin exposed to reimbursement or cash-pay rates |
| Value-based / risk | Payer / employer | Longest; usually a second-stage deal | Rigorous outcomes data and a track record | Highest ceiling; real downside risk accepted |
| Marketplace | Whichever side transacts | Short per match; slow to reach liquidity | Two-sided trust and local density | Take-rate margin; scales with liquidity, not headcount |
| D2C | Individual patient | Shortest; a single purchase decision | A trustworthy experience and a credible recommendation | Volume-driven; thin per-unit, sensitive to acquisition cost |
| Licensing / white-label | Enterprise partner | Long enterprise partnership cycle | Defensible IP or data, partner fit | Lower per-unit price; large volume per signed deal |
Two patterns cut across this table. The buyers with the deepest pockets — payers and enterprise partners — also demand the most evidence and the longest cycles, so plan your runway around the model's cycle length, not its ceiling. And every model except D2C requires you to prove value to someone who isn't the person actually using the product, which is why the buyer-mapping question always comes before the pricing question.
Most durable digital health companies don't stay on one model forever. A common path starts narrow — fee-for-service or D2C, because both validate fastest — and layers on a PMPM or value-based contract once there's real outcomes data to bring to a payer conversation. Treat your first model as the one that gets you evidence fastest, not necessarily the one you expect to end on.
Key Takeaways
- Seven distinct models, seven distinct buyers — SaaS, PMPM, fee-for-service, value-based/risk contracts, marketplace, D2C, and licensing each imply a different economic buyer, and choosing the model means choosing the buyer first.
- Payer alignment, evidence bar, and sales motion decide the model — not which one looks best on a pitch deck.
- Fee-for-service and D2C validate fastest; PMPM, value-based, and licensing validate slowest — size your runway to the cycle length of the model you're testing right now.
- Value-based and risk contracts are usually a second deal, not a first one — prove the outcome under a lower-risk model before accepting a payer's downside risk.
- A signed pilot or contract beats enthusiasm in every model — a named budget line, a pre-order, or an executed agreement is evidence; a good meeting is not.
- Most durable digital health companies run more than one model over time — often starting narrow and adding a payer-facing contract once they have their own outcomes data to negotiate with.
Frequently Asked Questions
What is the most common digital health business model?
SaaS and fee-for-service are the most common starting models, because both have a shorter sales cycle and a lower evidence bar than PMPM, value-based, or licensing deals. Most companies use one of these two to get initial traction, then add a payer-facing model like PMPM once they have outcomes data to support it.
Can a digital health startup use more than one business model at once?
Yes, and most successful ones eventually do. A common path is proving the product with fee-for-service or direct-to-consumer revenue first, then layering a PMPM or value-based contract with a payer or employer once there's real outcomes data to negotiate with. Running all seven from day one, however, spreads a small team across too many sales motions to execute any of them well.
What is PMPM pricing in digital health?
PMPM (per-member-per-month) is a fixed fee a payer or employer pays for each enrolled member, regardless of how much that person actually uses the product. It's common in chronic condition management, virtual primary care, and behavioral health, and it requires evidence that the intervention lowers cost or improves outcomes across the population — not just for individual users who happen to log in.
How is value-based different from fee-for-service in digital health?
Fee-for-service pays you for each unit of service delivered — a visit, a test, a monitored day — regardless of the outcome. Value-based (or risk-based) contracts pay you based on the outcome or cost result you actually produce, which means accepting some financial risk if the outcome doesn't materialize. Value-based deals demand more evidence and usually come after a company has already proven itself under a simpler model.