What are saas fees?

SaaS fees are the recurring charges a customer pays to use Software as a Service (SaaS)—software delivered over the internet, typically hosted by the vendor, and accessed via a browser or app. Instead of buying a perpetual license and installing software on hospital servers, you pay an ongoing subscription (monthly or annually) to keep using it.

In medtech and digital health, SaaS fees can look deceptively simple (“$X per month”), but the real cost is often shaped by security, compliance, integrations, and clinical workflow requirements.

What SaaS fees usually include (and what they don’t)

At a baseline, SaaS fees cover the vendor’s ongoing cost to run and improve the product. Typical inclusions:

• Software access: user logins, core features, updates/bug fixes.
• Hosting and infrastructure: cloud compute, databases, backups, uptime monitoring.
• Security maintenance: patching, vulnerability management, logging.
• Customer support: help desk, onboarding materials, basic training.

Common items that may not be included (often billed separately):

• Implementation: initial setup, workflow configuration, SSO setup, environment provisioning.
• Integrations: EHR connectivity (e.g., HL7/FHIR), PACS/RIS, lab systems, device data feeds.
• Data migration: importing legacy patient or operational data.
• Custom features: site-specific requests, bespoke dashboards, custom reports.
• Advanced compliance artifacts: extra documentation, customer-specific audits, or validation support.

Common SaaS pricing models (with medtech examples)

SaaS fees are usually tied to a “pricing metric” (what you charge per). In healthcare, pick a metric that maps to value and procurement reality.

• Per user / per seat: e.g., “$X per clinician per month.” Works for care team tools, admin dashboards, or imaging review collaboration.
• Per facility / per site: e.g., “$X per hospital per year.” Often preferred by hospital procurement because it’s predictable.
• Per patient: common in remote patient monitoring or chronic care programs; can align with reimbursement but requires careful definitions (enrolled vs. active vs. billed).
• Per encounter / per study: e.g., per radiology study analyzed, per ECG interpreted, per surgical case. Good for AI/analytics where value scales with volume.
• Usage-based: fees tied to API calls, compute time, or messages processed. This is common in general SaaS, but hospitals often dislike unpredictable bills.

Many medtech SaaS businesses use a hybrid: a base platform fee (predictable) plus a variable component (volume-based) and add-ons (integrations, extra modules).

Medtech-specific drivers that inflate SaaS fees

Healthcare customers aren’t just buying “software.” They’re buying risk reduction, compliance posture, and operational reliability. These requirements often explain why medtech SaaS fees are higher than consumer or generic B2B tools.

HIPAA, BAAs, and security reviews

If you handle protected health information (PHI), customers will expect a Business Associate Agreement (BAA) and will run a security assessment. Your SaaS fee may implicitly fund:

• Security questionnaires and vendor risk management cycles
• Audit logs, access controls, encryption, incident response processes
• Pen tests and ongoing security hardening

Even if you don’t quote these as line items, they are real costs you must recover.

EHR integrations and interoperability

Connecting to Epic/Cerner and other systems can require interface engines, HL7/FHIR mapping, testing environments, and ongoing maintenance when upstream systems change. Many vendors charge:

• One-time interface/implementation fees for initial build
• Ongoing integration maintenance fees for monitoring and updates

Hospitals also care about who owns the integration relationship and who pays third-party interface costs—clarify this early.

Clinical validation, IRB, and evidence generation

If your product touches clinical decision-making, customers may ask for evidence, validation studies, or even an IRB pathway for evaluation. SaaS fees sometimes include “clinical success” support (training, protocol help), or you may price it separately as professional services.

Regulatory pathway: SaMD vs. non-device software

Some digital health software is Software as a Medical Device (SaMD), which can trigger FDA considerations (e.g., 510(k), De Novo, or PMA depending on risk and predicates). Regulatory status doesn’t automatically dictate pricing, but it affects your cost structure (quality management system, documentation, post-market processes). If you’re regulated, your SaaS fee must cover those ongoing obligations.

Reimbursement and procurement realities

Hospitals buy differently than startups expect. Procurement often prefers:

• Annual contracts with clear renewal terms
• Predictable total cost of ownership (TCO)
• Defined scope: what’s included vs. billable add-ons

If your product’s value depends on reimbursement (e.g., workflows tied to CPT codes), customers may push for pricing aligned with revenue capture or cost savings. Be careful: “we’ll take a percentage of reimbursement” can be attractive, but it complicates contracting, compliance, and forecasting.

How to read a SaaS quote: the 8 line items to look for

When someone says “SaaS fees,” they might mean only the subscription—or the full commercial package. In medtech, ask for a quote that separates:

1. Subscription fee (base platform)
2. Pricing metric and limits (users, sites, patients, studies, etc.)
3. Overage fees (what happens when you exceed limits)
4. Implementation/onboarding (one-time)
5. Integration fees (one-time + ongoing)
6. Support tier (standard vs. premium, response times)
7. Data/storage fees (retention, backups, exports)
8. Security/compliance commitments (BAA included? audit support?)

Also check contract terms: auto-renewal, annual uplift caps (if any), termination rights, and data return/export clauses.

Founder perspective: how to set SaaS fees without guessing

If you’re building a medtech SaaS product, your pricing should reflect (1) value delivered, (2) customer buying behavior, and (3) your true costs.

• Start with a value hypothesis: What budget does this come from—IT, clinical department, quality, revenue cycle? Pricing must match who signs.
• Choose a metric that scales with value: If your product saves time per study, “per study” can be intuitive. If it’s a platform used across departments, “per site” may be simpler.
• Separate subscription vs. services: Hospitals expect implementation to be a project. Don’t hide it inside the subscription unless you can standardize it.
• Plan for procurement friction: A slightly higher annual fee with fewer variable components can close faster than a “cheap” but complex usage model.

What to do next

1. Collect 10 real quotes from adjacent vendors (not just direct competitors) and map their pricing metric, contract length, and what’s included.
2. Write your pricing one-pager: subscription, implementation, integrations, support tiers, and clear definitions (e.g., what counts as a “patient” or “active user”).
3. Run 5 procurement-style interviews with hospital IT/security + a clinical champion to learn which line items trigger delays.
4. Stress-test unit economics: estimate your per-customer costs for hosting, support, and integration maintenance before you lock pricing.