Testing an Outcomes-Based Model

Revenue is linked to outcome - operational outcomes to health outcomes measured in cost, quality, revenue, patient experience, and process improvements.

Why an Outcomes-Based Business Model is valuable to your business:

  • Deep alignment with customer's business
  • Payment tied to actual patient outcomes may provide competitive advantage if peers cannot tie activity to outcome
  • May require complete reconfiguration of product and service to drive outcomes
  • May require a regulatory process or claim
  • May have no impact on actual outcomes
  • Operational KPIs: affect core customer metrics (utilization, readmission, other)
  • Determine service level agreement (SLA)
  • If health outcome - KPIs around core service offering that leads to better health outcomes

Why an Outcomes-Based Business Model is valuable to your customers:

  • Deep alignment with customer's business
  • Seen as a strategic partner, with a value proposition closely tied to customer's mission
  • Knowing which products, services, and workflows drive which outcomes
  • Understanding system dynamics of organization
  • Customer may not be in control of key processes
  • Actual operational or quality KPI performance vs. baseline

Companies using DaaS business models:

Health Catalyst
Omada Health

KPIs of an Outcomes-Based Model depend on where in the continuum the company falls:

Most healthtech companies aim for outcomes-based as a future state business model, achieved after other lower hanging fruit models are established, claims are strengthened, and data transformed into knowledge.


HealthTech companies often find other startup business models before earning their way into outcomes-based

Health Catalyst only recently offered a pay-for-outcome business model to a close partner, after a long term commitment and agreement to provide deeper service models to Alina Healthcare


Key interview questions to validate an Outcomes-Based model:

Before you consider the Outcomes-Based model:

  • Test for jobs to be done, level of pain on the pain scale. How much of a priority is (defined problem or pain)?
  • Do we fit within the workflow of our customer enough to change the operational or quality outcome?
  • Do we require a regulatory process to make claims?
  • Can we determine another path to market that does not require regulatory process for MVP?
  • Do customers value outcomes enough? What is the total cost of not solving the problem? Of solving it poorly vs. our solution?

    When testing the solution:

    • How do we get access to critical data that informs our outcome?
    • Can we design smart ways to report out outcomes?
    • Determine the minimal offering that would be compelling enough to have the customer pay for the offering.
    • Can you design an MVP that has high usage and engagement with a minimal feature set?
    • Is there a user proposition that can be easily tested and implemented?
    • Is there a primary business model that can be considered ahead of delivering outcomes-based?
          • Example test cards (Osterwalder's Value Proposition Design)