10 Use Cases of Usage-Based Billing for Healthtech SaaS

Why Healthtech SaaS Needs a Different Billing Conversation

Healthtech SaaS operates under constraints that most software categories never encounter. HIPAA in the US, GDPR in Europe, MDR for medical devices, FDA oversight for Software as a Medical Device (SaMD) — the regulatory surface area is large, and billing infrastructure touches it directly.

Usage data in healthtech is often Protected Health Information (PHI) — or at minimum, data that could be used to infer it. Billing events that contain patient identifiers, session timestamps correlated to specific providers, or diagnostic inference counts can fall within HIPAA’s scope. That means the billing system itself — the platform that ingests and stores usage events — is part of the compliance boundary.

This is one of the primary reasons healthtech companies evaluate self-hosted billing infrastructure. A SaaS billing provider that stores usage event logs on their own servers may require a Business Associate Agreement (BAA), and may not be able to satisfy data residency requirements for non-US customers operating under GDPR.

The ten use cases below cover the most common healthtech product categories where usage-based billing makes commercial and operational sense — and where the billing infrastructure choices carry compliance weight.

1. Telehealth and Virtual Care Platforms

The use case

Telehealth platforms connect patients with providers for video consultations, asynchronous messaging, and remote assessments. Platforms may serve direct-to-consumer (DTC) markets, employer benefits programs, or as white-labeled infrastructure for health systems.

Why usage-based billing fits

Telehealth consumption is episodic and variable. A DTC mental health platform has different utilization patterns than an employer benefits program or a specialist consultation service. Charging a flat monthly fee per provider seat ignores that some providers are full-time and others see patients once a week. Charging per consultation or per minute aligns revenue with actual platform activity.

Billable metrics that work

• Consultation sessions — per completed video or audio session, the most common unit
• Session minutes — total time across all provider-patient interactions; finer-grained
• Asynchronous messages — per secure message thread or message sent; relevant for asynchronous-first platforms
• Active providers — per provider who completed at least one consultation in the period; a hybrid between seats and consumption

Regulatory and billing infrastructure considerations

Session records in telehealth may contain PHI — provider ID, patient ID, session timestamp, duration. If these fields flow into billing events, the ingestion pipeline operates within the HIPAA boundary. The billing system must store usage data in an environment covered by a BAA, or strip PHI fields before ingestion.

For platforms serving EU patients under GDPR, usage data tied to health consultations is sensitive personal data under Article 9. Billing logs containing session metadata cannot leave the EU without adequate safeguards. Self-hosted billing infrastructure in the customer’s own cloud region eliminates this cross-border data transfer risk.

2. Electronic Health Record (EHR) and EMR Platforms

The use case

EHR/EMR platforms are the operational backbone of clinical practices — scheduling, charting, prescribing, billing, and care coordination. Cloud-based EHR products (Athenahealth, Elation, Canvas Medical) increasingly sell to independent practices, group practices, and health systems.

Why usage-based billing fits

The right billing unit for an EHR is not seats — it’s clinical activity. A practice with 10 providers who see 50 patients per day has fundamentally different resource consumption than one with 10 providers who see 10 patients per day. Per-encounter billing aligns platform revenue with practice revenue, which makes budget conversations significantly easier for clinical buyers.

Billable metrics that work

• Patient encounters — per completed clinical visit recorded in the system
• Active patients — unique patients with at least one encounter in the period
• Prescription transactions — per e-prescription sent through the platform
• API calls — per programmatic record access, relevant for EHR platforms with developer ecosystems (FHIR APIs)

Regulatory and billing infrastructure considerations

EHR billing events are inherently tied to patient records — encounter IDs map directly to PHI. The billing system must either operate under a BAA or work exclusively with de-identified aggregate counts (e.g., “this practice had 1,247 encounters this month”) rather than per-encounter event records.

Audit trails for EHR billing carry additional weight because practices may use billing dispute resolution to cross-reference against their own encounter counts. The billing system must produce a count that matches what the practice’s own records show — not just what the platform logged. Discrepancies in encounter counts are not just billing disputes; they can imply clinical record integrity issues.

3. Medical Imaging AI and Diagnostic Inference

The use case

AI diagnostic platforms process medical images — X-rays, CT scans, MRIs, pathology slides — to detect conditions, prioritize worklists, or assist radiologists and pathologists. Platforms like Aidoc, Viz.ai, and Paige sell per-image or per-inference to radiology departments and health systems.

Why usage-based billing fits

Image analysis is a discrete, countable action. Each image submitted for inference is a unit of value delivered: the AI either analyzed it or it didn’t. Flat-tier subscription pricing for diagnostic AI creates a ceiling that constrains adoption — a radiology department that wants to expand from chest X-rays to CTs and MRIs would face a plan upgrade conversation rather than simply paying for more inferences.

Billable metrics that work

• Images analyzed — per image processed through the inference pipeline; the clearest value unit
• Studies processed — per imaging study (which may contain multiple images/slices); more relevant for worklist prioritization
• Positive findings — per AI flag or alert surfaced (outcome-based pricing); high alignment but hard to audit
• Modality-weighted credits — different rates for X-ray vs. CT vs. MRI vs. pathology slides, reflecting inference cost variance

Regulatory and billing infrastructure considerations

Medical images (DICOM files) contain embedded patient metadata — name, date of birth, study date, referring physician. The inference request that triggers a billing event typically includes the study UID, which maps directly to PHI. The billing pipeline must be designed to receive de-identified billing triggers (study UID → billing event, without PHI) or operate within a BAA-covered environment.

For FDA-regulated SaMD, the audit trail requirements are stricter: every inference event must be traceable to the specific model version that produced it, for post-market surveillance purposes. If the billing system also serves as the inference log, the event schema must capture model version alongside usage count.

4. Remote Patient Monitoring (RPM) Platforms

The use case

RPM platforms collect continuous or periodic data from connected devices — glucose monitors, blood pressure cuffs, pulse oximeters, cardiac monitors, wearables — and surface it to care teams. CMS reimburses RPM under specific CPT codes, making billing complexity layered: the platform bills the health system, which bills CMS.

Why usage-based billing fits

RPM data volume is proportional to the number of enrolled patients and the monitoring frequency. A platform monitoring 500 patients with daily readings generates different data volumes than one monitoring 5,000 patients with continuous streams. Charging a flat fee per platform ignores this variance entirely.

Billable metrics that work

• Enrolled patients — per patient actively monitored in the period; the most predictable unit
• Data transmissions — per reading or per device sync event; higher granularity, maps to data ingestion cost
• Alert events — per threshold breach that triggers a care team notification
• CMS-qualifying readings — per reading that meets the 16-day threshold for CPT 99454 reimbursement; aligns vendor billing with payer billing

Regulatory and billing infrastructure considerations

RPM platforms operate at the intersection of two regulatory frameworks: HIPAA (patient data) and CMS reimbursement rules (specific data requirements for billing). Billing events tied to CPT code qualifications must be auditable against raw device data — a health system that gets a reimbursement denial from CMS will look to the RPM platform’s audit trail to understand why a patient’s readings were or weren’t counted.

The billing system must therefore maintain event-level audit trails that survive beyond the current billing period — typically 7 years for HIPAA-covered entities. Billing data in a third-party SaaS provider’s database cannot easily satisfy this retention requirement without additional contractual controls.

5. Health Data Exchange and Interoperability Platforms

The use case

Health data exchange platforms enable clinical data to move between health systems, payers, labs, pharmacies, and patients. The 21st Century Cures Act mandates FHIR-based APIs for patient data access. Platforms like Health Gorilla, Particle Health, and 1upHealth sell API access to these data flows.

Why usage-based billing fits

Health data exchange is fundamentally an API product. The value delivered is data records retrieved or transmitted per API call. Charging a flat monthly fee for data exchange access doesn’t reflect the actual volume of data flowing — a small practice connecting one patient a day consumes far less than a payer pulling records for 100,000 members.

Billable metrics that work

• FHIR API calls — per request to patient data endpoints; the most granular unit
• Patient records accessed — per unique patient record retrieved; de-duplicated across multiple API calls to the same record
• Data bundles transmitted — per structured data package sent or received
• Network connections — per data source integrated (health system, lab, payer); a setup fee proxy

Regulatory and billing infrastructure considerations

FHIR API calls in health data exchange contain or enable access to PHI by definition. The billing event generated by an API call — even if it only logs the call count and not the response payload — creates a log of what was accessed, when, and by whom. This access log is subject to HIPAA’s accounting of disclosures requirements.

The 21st Century Cures Act information blocking provisions add another layer: platforms must not use their technical or contractual design to restrict legitimate data access. A billing model that creates cost friction for required data sharing could implicate information blocking rules. Usage-based pricing is actually the compliance-friendly approach here — it doesn’t create a fixed cost barrier to access that a health system might invoke to justify restricting data sharing.

6. Clinical Trial Management and eClinical Platforms

The use case

eClinical platforms support the conduct of clinical trials: electronic data capture (EDC), randomization and trial supply management (RTSM), patient recruitment, and safety reporting. Sponsors, CROs, and sites all interact with these platforms across the trial lifecycle.

Why usage-based billing fits

Trial scope is highly variable: a Phase I oncology trial has different data volume and site complexity than a Phase III cardiovascular outcome study. Per-trial or per-participant billing maps revenue to actual trial scale. Flat-tier subscriptions that don’t account for trial size force sponsors into opaque tier negotiations rather than transparent per-unit pricing.

Billable metrics that work

• Active participants — per enrolled patient with at least one data entry in the period
• Data submissions — per completed eCRF page or data point submitted; maps to EDC usage
• Query events — per data query raised or resolved; reflects site activity and data quality workload
• Sites activated — per clinical site configured and active; relevant for site setup-heavy platforms

Regulatory and billing infrastructure considerations

Clinical trial data is subject to 21 CFR Part 11 (FDA electronic records requirements) and ICH E6 Good Clinical Practice. The audit trail requirements are stricter than standard HIPAA: every data entry, modification, and deletion must be logged with timestamp, user ID, and reason for change — permanently.

If the billing system uses trial data events as billing triggers, those events must be immutable. A billing event that was created, then corrected, then re-billed must preserve the original event record. The billing audit trail and the clinical data audit trail serve different purposes but must be consistent — a discrepancy between the EDC’s event count and the billing system’s event count is a regulatory finding.

ABAXUS runs in your own infrastructure — billing data stays in your own database, in your own cloud region, under your own compliance controls

Self-hosted usage-based billing engine with idempotent event ingestion, configurable rate structures, and real-time dashboards. No per-transaction fees. BAA-compatible deployment.

See how it works

7. Mental Health and Behavioral Health Platforms

The use case

Digital mental health platforms — therapy apps, psychiatric medication management tools, crisis intervention services, employee assistance programs — deliver care through licensed providers or digital therapeutics. The market spans DTC consumer apps, employer benefits channels, and health plan partnerships.

Why usage-based billing fits

Mental health care is episodic and variable in intensity. A user in active treatment might have multiple sessions per week; a user in maintenance might have one per month. An employer that contracts for mental health benefits for 1,000 employees will have utilization that varies month to month. Per-session or per-active-user billing aligns cost with actual care delivery, which is easier to reconcile with employer or payer contracts.

Billable metrics that work

• Therapy sessions completed — per completed session with a licensed provider
• Monthly active users — unique users who engaged with the platform in the period; relevant for digital therapeutics
• Crisis interventions — per escalation event handled by a licensed clinician; premium-rate unit
• Prescriptions managed — per psychiatric medication prescription sent or refilled through the platform

Regulatory and billing infrastructure considerations

Mental health data carries heightened protection beyond standard HIPAA in many US states — California’s Confidentiality of Medical Information Act (CMIA), 42 CFR Part 2 (substance use disorder records), and state-specific mental health parity laws all apply. Billing events that expose the fact that a specific person received mental health care can constitute a privacy violation even if clinical content is absent.

The billing system must work with anonymized or aggregated identifiers — a session ID that cannot be reverse-mapped to a patient record — rather than patient-identifiable event keys. Health plan and employer reporting requirements add another dimension: the billing system must produce utilization reports that satisfy the payer’s reporting format while preserving member privacy.

8. Pharmacy and Medication Management Platforms

The use case

Pharmacy technology platforms — medication adherence apps, pharmacy benefit management (PBM) tools, specialty pharmacy management systems, digital prescription routing — sit at the intersection of clinical care and the pharmacy supply chain. Transaction volume maps directly to prescription activity.

Why usage-based billing fits

Prescription volume is the natural unit of value for pharmacy platforms. A pharmacy processing 5,000 prescriptions per month derives more value than one processing 500. Charging both the same flat subscription creates the same revenue leakage problem seen in every other category: the high-volume customer is undercharged until a sales conversation forces an upgrade.

Billable metrics that work

• Prescriptions processed — per electronic prescription sent through the network; maps to transaction cost
• Refill transactions — per refill authorization processed; separable from new prescriptions
• Adherence check-ins — per patient interaction logged for medication adherence tracking
• Prior authorization submissions — per PA request submitted to payer; high-value transactions worth premium pricing

Regulatory and billing infrastructure considerations

Prescription data is among the most tightly controlled PHI. HIPAA minimum necessary standards, DEA regulations for controlled substance prescriptions (21 CFR 1306), and state pharmacy board requirements all apply. Billing events tied to controlled substance prescriptions create an additional audit trail obligation — the DEA requires specific record retention for Schedule II-V prescriptions.

The billing system must be designed so that prescription transaction logs satisfy audit purposes without exposing sensitive medication information in the billing database. A controlled substance prescription flagged for billing purposes must not expose the substance category in the billing event schema — that constitutes a disclosure of sensitive health information.

9. Healthcare Analytics and Population Health Platforms

The use case

Population health platforms aggregate clinical data across patient populations to identify care gaps, risk stratify patients, and support value-based care arrangements. Analytics platforms serve health systems, ACOs, health plans, and public health agencies.

Why usage-based billing fits

Analytics consumption is driven by the size of the patient population under management and the depth of analysis performed. A platform running monthly risk stratification for 10,000 patients consumes different resources than one running weekly stratification for 500,000. Query volume, data refresh frequency, and report generation are all trackable and billable consumption signals.

Billable metrics that work

• Patient lives analyzed — per unique patient included in at least one analysis in the period
• Queries executed — per analytics query run against the patient database
• Risk assessments generated — per patient risk score or care gap analysis produced
• Report exports — per structured data export for regulatory reporting (HEDIS, STARS, etc.)

Regulatory and billing infrastructure considerations

Population health analytics operate on large datasets of PHI from multiple covered entities — health systems, labs, payers — each with their own data use agreements. The analytics platform is typically a Business Associate of all upstream sources. Billing events that reflect per-patient analysis counts must not expose individual patient identifiers in the billing log.

De-identified data used for analytics retains a re-identification risk for small populations. HIPAA’s Safe Harbor and Expert Determination methods for de-identification apply. The billing system should operate on cohort-level or aggregate counts, not patient-level event records, to stay cleanly outside the PHI boundary.

10. Software as a Medical Device (SaMD) and Digital Therapeutics

The use case

SaMD products — FDA-cleared or CE-marked software that performs a medical purpose, such as a clinical decision support tool, a digital diagnostic, or a prescription digital therapeutic (PDT) — face the most stringent regulatory requirements of any software category. Products like Pear Therapeutics (reSET), Welldoc (BlueStar), and Freespira operate as prescribed treatments alongside or instead of drugs or devices.

Why usage-based billing fits

SaMD usage is therapeutic — the product is prescribed and used as part of a treatment plan. Billing on engagement or treatment completions aligns platform revenue with clinical outcomes, which maps naturally to value-based contracting with health plans. It also avoids the perverse incentive of flat-subscription SaMD billing, where the vendor is paid regardless of whether the prescribed treatment is actually used.

Billable metrics that work

• Treatment sessions completed — per prescribed therapeutic session completed by the patient
• Active prescriptions — per active prescription in the period; mirrors how payers think about covered lives
• Therapeutic milestones — per protocol-defined milestone achieved (treatment completion, engagement threshold); outcome-adjacent pricing
• Provider orders — per prescription issued by a clinician through the platform

Regulatory and billing infrastructure considerations

SaMD faces the most complex intersection of billing and regulation. FDA’s Software as a Medical Device guidance, the Digital Health Center of Excellence, and the EU’s MDR Article 2(1) all define what constitutes regulated software. The audit trail for a regulated SaMD must satisfy both clinical (21 CFR Part 820 QMS requirements) and billing purposes.

Post-market surveillance obligations under FDA and MDR require SaMD vendors to monitor real-world performance data — which often overlaps with usage data. A billing event that records a treatment session is simultaneously a post-market surveillance data point. The billing infrastructure must be designed with this dual purpose in mind: immutable event records, version-tagged per software release, with retention aligned to device classification (typically 10+ years for Class II/III devices).

Health plan reimbursement for PDTs is still evolving. A billing system that can flex between per-session, per-prescription, and outcomes-based rate structures — without requiring engineering changes — is essential for adapting to payer contracts as coverage policies mature.

What These Use Cases Have in Common

Across all ten categories, three dimensions distinguish healthtech billing from standard SaaS billing:

Data sovereignty and compliance boundary

Audit trail durability

Standard SaaS billing retains data for 12–24 months. HIPAA requires 6 years. Clinical trial records and SaMD post-market surveillance require 10+ years. The billing system must be designed with data retention timelines that match regulatory requirements, not SaaS business model defaults.

Event schema compliance

Billing events must be designed to exclude PHI at ingestion — patient IDs replaced with de-identified session tokens, encounter IDs not directly mapped to patient records. The event schema is a compliance design decision, not just a technical one.

For a deeper look at the underlying billing infrastructure requirements, see 5 Key Features of Usage-Based Billing Software and Metered Billing Explained.

Thinking About Usage-Based Billing for Your Healthtech Product?

Healthtech billing has requirements that most billing platforms weren’t designed for: data sovereignty, audit trail durability, PHI-aware event schemas, and the ability to deploy in your own cloud environment under your own compliance controls.

ABAXUS is a self-hosted usage-based billing engine. It runs in your own infrastructure — your AWS account, your Azure environment, your GCP project. Usage data stays in your own database. No third-party SaaS to add to your BAA inventory. No usage logs leaving your compliance boundary.

If you’re building a healthtech product and want to discuss how usage-based billing works under your specific regulatory constraints — book a 30-minute call with the ABAXUS team. We’ll walk through your billable metric, event schema design, data residency requirements, and rate structure in a single session.

Related Reading

• Metered Billing Explained — the full event ingestion, aggregation, and invoicing pipeline
• 5 Key Features of Usage-Based Billing Software — what the infrastructure needs to do correctly in production
• Usage-Based Pricing vs. Subscription Models — decision framework for choosing the right model
• 10 Use Cases for Dev Tools SaaS — the same pattern applied to CI/CD, observability, and agentic DevOps
• 5 Best Usage-Based Billing Platforms in 2026 — how ABAXUS compares to Lago, Orb, Chargebee, and Metronome
• Billing Readiness Assessment — evaluate your infrastructure across compliance, audit trails, and data residency before choosing a platform

ABAXUS is a self-hosted usage-based billing engine for teams that need full control over their billing infrastructure. See how it works or book a discovery call to discuss your healthtech use case.