Health-tech partner programs: CPA, revenue share or hybrid?

Most B2B health-tech companies reach a point where direct sales stop scaling. Clinics, labs and employers buy through people they already trust: practice-management consultants, IT resellers, benefits brokers, implementation partners. A partner program turns those relationships into a channel. The first design question is how to pay partners. The second, and in healthcare the more important one, is what you must never pay them for.

Three ways to pay a partner

Almost every partner deal is a version of one of three models.

CPA (cost per acquisition) is a fixed fee for each qualified new customer, paid once. It is simple to budget and easy for partners to understand.

Revenue share is a percentage of what the referred customer pays you, for as long as the agreement says. Partners earn more when customers stay and grow.

A hybrid deal combines a smaller upfront fee with a smaller ongoing share. The partner gets some cash early, and both sides share the long-term risk.

Performance-marketing industries have spent years refining these structures. AffHouse, a trade publication on affiliate and performance marketing, has published a detailed comparison of CPA, revenue share and hybrid deals that walks through a break-even example and the contract terms that decide what a deal is really worth, such as caps, hold periods, clawbacks and lifetime versus time-limited revenue share. Its examples come from iGaming, but the mechanics carry over to SaaS almost unchanged.

Which model fits which partner

CPA suits partners who make one introduction and move on, such as a consultant who recommends a tool during a clinic set-up project. You know the cost of each customer in advance. The downside is that the partner has no stake in whether the customer stays, so you need a clear definition of “qualified”, for example a signed contract or a first paid invoice, and a reasonable hold period before payout.

Revenue share suits partners who stay involved after the sale: resellers who handle onboarding, support or billing, or integrators whose product sits next to yours. Their income depends on retention, which aligns incentives. The costs are harder to forecast, and long or open-ended terms can become an expensive legacy if the partner stops contributing.

Hybrid deals fit new or uncertain channels, where neither side knows yet how valuable referred customers will be. They are harder to administer, so they only make sense when your billing and partner tracking can handle two payment streams cleanly.

None of these models is better in the abstract. Pick the one that matches what the partner actually does, and write down exactly what triggers a payment.

Software referrals are not patient referrals

In most industries, rewarding people who send you business is ordinary commerce. Healthcare is different. The US federal Anti-Kickback Statute makes it a crime to knowingly and willfully offer, pay, solicit or receive remuneration to induce or reward referrals of items or services payable by federal health care programs such as Medicare and Medicaid. It also reaches payments made to induce someone to purchase, order or recommend such items or services. The HHS Office of Inspector General puts it bluntly: in the Federal health care programs, paying for referrals is a crime.

Remuneration means anything of value, not just cash. The statute treats a violation as a felony, punishable by a fine of up to $100,000, up to ten years in prison, or both, according to the statute's text. The OIG adds civil monetary penalties and exclusion from federal health care programs, and claims that result from a kickback may also create liability under the False Claims Act. Safe harbors exist, but an arrangement is protected only if it fits squarely within one and meets all of its requirements.

So where does a B2B software partner program sit? A commission to a consultant who introduces a clinic to software the clinic pays for out of its own budget is a different thing from a fee per patient sent to a provider. But the line blurs faster than many founders expect: when your product, or a service it enables, is billed to Medicare or Medicaid; when the partner is a clinician or someone else in a position to steer patients or orders; when payments depend on patient volumes, prescriptions or tests ordered rather than on software sold; or when a third party pays you to influence what happens inside your product.

That last scenario is not hypothetical. In 2020 the electronic health records vendor Practice Fusion agreed to pay $145 million to resolve criminal and civil investigations, after the Justice Department alleged that it took payments from an opioid manufacturer in exchange for clinical decision support alerts designed to increase prescribing of that company's products.

Keep patient data out of the partner channel

The second legal boundary is data. Under the HIPAA Privacy Rule, a covered entity such as a clinic must get a patient's authorization before using or disclosing protected health information for marketing, with narrow exceptions such as face-to-face communication. If a third party pays the covered entity for that marketing, the authorization must say so, and selling protected health information also requires authorization, under 45 CFR 164.508.

If your product processes patient information on a clinic's behalf, you are likely a business associate, and you may use or disclose that information only as your business associate agreement permits. In practice, patient lists, appointment data or diagnoses have no place in partner targeting, lead sharing or co-marketing.

In the EU and UK, GDPR treats data concerning health as a special category. Processing it is prohibited unless one of the Article 9 conditions applies, and the UK regulator, the ICO, notes that you need both an Article 6 lawful basis and a separate Article 9 condition. Products that handle medical documents, such as verifiable medical certificates, should be designed so that partners never touch the underlying records at all.

A checklist for a compliant partner program

• Pay for software outcomes only: signed contracts, paid invoices, active accounts. Never tie compensation to patients, prescriptions, tests or reimbursable services.
• Put every arrangement in writing, with the services, payment formula, term and termination rights spelled out.
• Screen partners: be especially careful with clinicians, practice owners and anyone who can influence patient care or ordering decisions.
• Share no patient data with partners, in either direction, and keep lead data limited to business contacts.
• Require disclosure. The FTC's Endorsement Guides FAQ says paid relationships should be disclosed clearly and conspicuously, and that the label “affiliate link” on its own may not be understood.
• Have healthcare counsel review the program before launch and whenever you change the payment model or add a new partner type.
• Document your data handling and security posture so partners can answer customer questions accurately; a public security and compliance page helps.

The short version

CPA, revenue share and hybrid deals are tools; the right one depends on what each partner actually does and how long they stay involved. In health tech, the payment model matters less than what the payment is for. Reward partners for helping organisations buy software, keep patients and their data out of the arrangement, and get a lawyer to sign off before the first commission goes out.

This article is general information, not legal advice; consult qualified counsel about your specific partner arrangements.