The labels biotech, medtech and healthtech are useful shorthand. They become a trap when a company mistakes a label for a strategy—or assumes that combining technologies makes the underlying requirements disappear.

  • Technology categories and legal classifications are different. A product can combine biology, hardware and software while still having an identifiable regulatory route.
  • Evidence and payment are separate. A clinically useful product can face a difficult commercial path; an attractive business model cannot establish clinical benefit.
  • Clarity means defining the product. Choosing a single industry label is less useful than identifying the intended use, users, evidence, costs and responsibilities.

What the three labels do—and do not—tell us

Biotechnology describes work that uses biological systems or processes. Medical technology includes devices, and devices can include software. Health technology is a broad business label covering activities as different as administrative software, consumer wellness and regulated clinical products. These categories overlap because they answer different questions about how a product works and where it is used.

A drug-discovery platform may be sold to pharmaceutical researchers without itself being a treatment. Software used in patient care may be a medical device, part of a device, or a function outside the device definition. The relevant inquiry is the particular function and intended use, not whether its maker calls itself a technology company.

The FDA distinguishes standalone Software as a Medical Device from software integral to hardware. Its examples specifically put software controlling an infusion pump outside the standalone SaMD definition. That does not make pump software unregulated; it means the correct category is more precise than “all medical algorithms are SaMD.” FDA examples of SaMD and other device software.

Regulatory complexity does not mean regulatory absence

Consider an actual integrated treatment technology. In August 2024, the FDA expanded the indication for Insulet's SmartAdjust automated insulin-dosing technology to adults with type 2 diabetes. The controller works with a compatible insulin pump and continuous glucose monitor. The agency reviewed the software through the 510(k) pathway. This is a concrete counterexample to the assumption that a system combining software, sensing and life-sustaining delivery must be trapped between regulators or automatically need a Class III premarket approval. FDA's SmartAdjust decision.

It is not a precedent for every pump, algorithm or proposed genetic-analysis feature. A new feature can change the evidence needed, and an individual product still requires a proper classification assessment. The point is narrower: integration itself does not demonstrate that no route exists.

For products meeting the legal definition of a combination product, the FDA has an Office of Combination Products. It assigns a lead center and coordinates reviews. Primary mode of action helps determine jurisdiction; a single marketing application is generally sufficient, although exceptions exist. “Biotech plus software” is not itself the statutory definition of a combination product. FDA combination-product questions and answers.

International expansion can add separate obligations, but it is misleading to count a law, an FDA center and a European conformity-assessment regime as interchangeable “regulators.” Data-protection duties, device requirements and advertising rules address different risks. Their applicability needs to be mapped for the particular jurisdiction, organization and function.

Clinical decision support is another boundary case. Some functions meet statutory criteria for exclusion from the US device definition; other medical software remains within it. Whether a clinician sees the output is not the entire test. The FDA's January 2026 guidance explains that boundary with examples. FDA Clinical Decision Support Software guidance.

Where convergence can create real business friction

The defensible criticism of convergence concerns coordination. A team may have to demonstrate that a biological component works, a device performs reliably, software behaves safely, users can operate the system and a purchaser will fund its use. A result in one area does not resolve the others.

  • Clinical purpose. What must be made explicit: Population, intended use and outcome Risk if left vague: Evidence answers a different question from the sales claim
  • Product boundary. What must be made explicit: Which components and functions belong to the marketed product Risk if left vague: Unplanned development, validation or maintenance work
  • Evidence milestone. What must be made explicit: The next uncertainty the funded work will resolve Risk if left vague: Investors and founders mean different things by “ready”
  • Payment. What must be made explicit: Who buys, who uses and who benefits Risk if left vague: Clinical interest does not become a viable contract
  • Ongoing ownership. What must be made explicit: Updates, monitoring, support and incident handling Risk if left vague: Essential work falls between organizations

This framework is a strategy synthesis, not a statutory classification checklist. It does not establish that one category always costs a particular amount or takes a fixed number of years. A narrowly scoped software function and a novel implant cannot be compared responsibly using a generic “medtech cost” figure.

Investors fund defined risks, including convergence

Investors differ in expertise, mandate, check size and tolerance for development risk. It is reasonable to expect a company to explain how its milestones fit a prospective investor. It is not reasonable to conclude that nobody funds products spanning categories.

SV Health Investors' Medtech Convergence Fund explicitly describes a strategy combining devices, software, telecommunications and new care models. The manager's own description establishes that such a mandate exists. It does not establish the returns of convergence funds or how easy fundraising will be for a particular company. The fund's published investment strategy.

The useful fundraising question is therefore concrete: which uncertainty will the next round resolve, what evidence will demonstrate that result, and which investors understand it? A clear answer can still involve more than one discipline. A simple label cannot repair a weak clinical rationale or an implausible budget.

Clinical evidence is not a payment mechanism

The distinction is especially visible in digital therapeutics. Demonstrating a benefit does not automatically create reimbursement, prescribing demand, integration capacity or sustained patient engagement. Equally, a reimbursement problem does not prove that the clinical result is false.

Device evidence should be judged by the claimed benefit, population, comparator and study design. It is inaccurate to assume that all drug trials enroll thousands while all digital-treatment studies are small pilots. Nor should a product be called equivalent to a medicine merely because it has a prescription pathway. The actual result and indication have to carry that comparison.

Procurement can involve clinical, pharmacy, information-technology, privacy and financial teams. That may make ownership harder to agree, but it does not prove that every hospital has mutually exclusive budgets or no route for an integrated product. Those are facts to establish in the target organization.

A focused first product can still use several technologies

A useful way to limit complexity is to define one initial use case and postpone features that do not help establish it. That is a recommendation about scope, not a demand to strip a product of useful integration. A device and algorithm may need to be designed together to deliver their intended benefit.

Partnerships can provide missing expertise, but they also need explicit responsibilities. A software partner's update can affect a device manufacturer's evidence; a clinical service may depend on support that is absent from a licensing contract. The handoff matters as much as the component.

The strongest criticism of vague convergence language is that it can conceal unresolved decisions. The answer is to expose those decisions: the claim, the evidence, the market, the payment route and the organization responsible after launch. Convergence can be productive. Unspecified responsibility is the more useful warning sign.

For an organ-specific example, see the cardiac digital-twin evidence review.