How does saas?

What “SaaS” actually means (and why medtech makes it different)

SaaS stands for Software as a Service: instead of installing software on a hospital server or selling a one-time license, you host the application and customers access it via a browser or app. They typically pay a recurring fee (monthly or annual), and you continuously ship updates.

In a normal industry, SaaS is mostly about product, uptime, and sales. In medtech (including digital health), SaaS also has to survive:

• Clinical risk (patient safety, decision-making, alarm fatigue)
• Regulated data (HIPAA in the US; often BAAs with customers)
• Hospital procurement (security review, vendor onboarding, long cycles)
• Potential FDA oversight if your software is considered Software as a Medical Device (SaMD) or part of a device system
• Reimbursement and coding realities (CPT codes, payer coverage) if your business model depends on clinical billing

So “how does SaaS?” in medtech = how do you deliver software continuously while proving it’s safe, secure, and worth buying.

The SaaS delivery model: what’s happening under the hood

1) You host it, customers subscribe

In SaaS, you run the infrastructure (cloud servers, databases, monitoring). Customers log in and use the product. You charge for access rather than a boxed product.

Common pricing units in medtech SaaS include:

• Per clinician seat (e.g., per physician/nurse user)
• Per facility (per hospital, per clinic site)
• Per bed (common in inpatient workflow tools)
• Per study / per patient / per encounter (analytics, imaging AI workflows)
• Per device connected (remote monitoring platforms)

The key SaaS concept is recurring revenue: predictable income that compounds as you retain customers and add new ones.

2) Multi-tenant vs single-tenant (and why hospitals care)

Multi-tenant means many customers share the same application instance (with strict data separation). Single-tenant means each customer gets their own isolated instance.

Multi-tenant is usually cheaper and faster to scale. Single-tenant can make security reviews easier for some health systems and can simplify data residency requirements, but it increases your operational burden.

3) Updates are continuous—but in medtech you need change control

Classic SaaS ships frequently (daily/weekly). In medtech, you still can ship frequently, but you need change control: documented review of what changed, why, risk impact, and verification/validation (V&V) evidence.

If your software is regulated (or could become regulated), build your development process as if an auditor will read it later: requirements, traceability, testing, and release notes that map to risk.

Medtech-specific realities: FDA, IRB, and “are we a medical device?”

FDA pathways: 510(k), De Novo, PMA (only if you’re in scope)

Not all medtech SaaS is FDA-regulated. But if your product performs medical device functions (diagnosis, treatment recommendations, triage, etc.), it may be considered SaMD or part of a regulated system.

High-level FDA routes you’ll hear:

• 510(k): you show “substantial equivalence” to a legally marketed predicate device.
• De Novo: for novel, low-to-moderate risk devices without a predicate.
• PMA (Premarket Approval): for higher-risk devices; typically the most rigorous.

Which applies depends on intended use, claims, risk, and existing predicates—this varies. A practical founder move is to write a one-paragraph intended use statement early and pressure-test it with regulatory expertise before you build yourself into a corner.

Clinical evidence vs product validation

Even if you’re not FDA-regulated, hospitals will still ask: “Does it work?” That can mean:

• Analytical validation: does the algorithm compute correctly?
• Clinical validation: does it improve or match clinical outcomes or decisions in the real world?
• Usability validation: can clinicians use it safely under real conditions?

If you plan a prospective study, you may need IRB approval (Institutional Review Board). IRB is about protecting human subjects; it’s separate from FDA clearance, but the two often interact in real projects.

Security, privacy, and integrations: the “hidden product” in medtech SaaS

HIPAA, BAA, and the hospital security review

In the US, if you handle protected health information (PHI), you’ll likely sign a BAA (Business Associate Agreement) with the provider organization. Expect a security questionnaire and proof of controls (access logging, encryption, incident response, etc.).

Security is not just a checkbox; it’s a sales blocker. Many deals die in procurement because the vendor can’t pass the review.

EHR integration: HL7/FHIR and “workflow or it didn’t happen”

Clinicians don’t want another login. If your SaaS touches clinical workflow, you’ll eventually face EHR integration. Two common standards:

• HL7 v2: older but widely used for ADT (admit/discharge/transfer), orders, results.
• FHIR: newer API-based standard for clinical data exchange.

Integration work is often underestimated. Budget time for mapping, testing, and go-live support. Also decide early: are you “read-only” (safer, faster) or do you write back into the chart (more value, more risk and scrutiny)?

How SaaS makes money in medtech: buyers, reimbursement, and procurement

Who pays vs who benefits (the classic trap)

Medtech SaaS often fails because the economic buyer (the person who controls budget) is not the end user (clinician) and not the beneficiary (patient). You need a value story that matches the buyer’s incentives.

Common buyer/value angles:

• Quality & safety: fewer adverse events, better guideline adherence
• Operational efficiency: reduced length of stay, faster throughput, fewer denials
• Revenue capture: improved documentation, fewer missed charges (careful: compliance matters)
• Cost avoidance: fewer readmissions, fewer unnecessary tests

CPT codes and reimbursement (only if your model depends on billing)

If you’re building something like remote patient monitoring, digital therapeutics, or clinician services enablement, reimbursement can matter. CPT codes

Procurement reality: timelines and proof

Hospital procurement can take months. Typical steps include stakeholder alignment, pilot, security review, legal/BAA, and vendor onboarding. Your SaaS needs:

• Clear ROI narrative (time saved, cost avoided, revenue protected)
• Implementation plan (training, integration, support)
• Evidence (even small pilots with measurable endpoints)

Design your product so a pilot can be run with minimal IT burden—this is often the difference between “interesting” and “purchased.”

What to do next

1. Write your intended use + claims in plain language, then decide if you might be SaMD (and which FDA pathway is plausible: 510(k), De Novo, or PMA).
2. Pick a pricing unit (per site, per seat, per patient, etc.) and draft a one-page ROI model that matches the economic buyer.
3. Plan for security early: list the PHI you touch, whether you need a BAA, and what controls you must implement to pass hospital review.
4. Define your integration strategy: start “read-only” where possible; document what data you need (HL7/FHIR) and what you’ll avoid in v1.
5. Run a pilot with measurable endpoints (time-to-task, error rate, throughput, adherence) and capture implementation lessons for procurement.