Building healthtech in 2026: HIPAA, FHIR, and the ransomware math you can't skip

One number sets the stakes before you write a line of code: the average healthcare data breach now costs about $10.22 million, and healthcare has held the title for the most expensive breaches of any industry for fourteen years running. That's not a tail risk you patch after launch. For anyone building software that touches patient data, it's the thing the whole product ends up being built around.

A scheduling tool and a patient-scheduling tool look almost identical in a demo. Same calendar, same booking flow, same confirmation email. The difference is all underneath: who can see a record, where it's stored, who you've legally promised to protect it, and what happens the day someone tries to steal it. None of that shows up in a screenshot, and all of it decides whether the product is shippable.

Three things shape what "good" means in healthtech right now. HIPAA's Security Rule is being rewritten for the first time in over twenty years. Federal interoperability deadlines are forcing health data onto a common API standard. And ransomware has gotten bad enough that regulators stopped treating a breach as bad luck and started treating it as evidence. If you're scoping a build, treat all three as design constraints, not legal footnotes you handle later. The early version is far cheaper than the retrofit.

Ransomware stopped being someone else's problem

The scale is hard to wave away. Since 2009, the US has logged more than 7,400 healthcare data breaches, affecting north of 935 million records — more than the country's population, several times over. Ransomware drives a growing share of it: it's behind roughly 28 percent of large healthcare breaches, and that slice keeps getting bigger. For a small company holding patient data, one successful attack isn't an IT incident. It's potentially the end of the company.

Founders tend to underestimate what comes next. When the Office for Civil Rights opens an investigation after a breach, the first thing it asks for usually isn't a forensic timeline of the attack. It's your risk analysis — the document showing you'd identified where patient data lived and what could go wrong with it. A missing or stale one is the violation most settlements are actually built on. OCR resolves somewhere between fifteen and twenty-odd of these a year, frequently tied to a ransomware event, an absent risk analysis, or a records request someone sat on. The average settlement in 2025 ran about $1.2 million.

So a breach bills you in layers: the recovery itself, the regulatory settlement on top, and the customer trust that doesn't come back at any price. And "we were unlucky, we got hacked" is no longer much of a defense. What an investigator wants to know is whether you'd done the basic work to see it coming.

HIPAA is being rewritten, and "optional" is on its way out

For most of its life, the HIPAA Security Rule split its safeguards into two buckets: "required" and "addressable." In practice a lot of teams read "addressable" as "optional," and skipped things like encryption with a one-line justification. The rewrite working its way through HHS — the first major overhaul of the rule in more than two decades — closes that loophole. The proposal pushes safeguards that used to be negotiable, including encryption of data at rest and in transit, multi-factor authentication, and an actual inventory of the systems that hold patient data, toward being flatly mandatory.

If you're building now, the move is obvious: build as if those are already required, because the rules are only moving in one direction. None of them are exotic. They're easy to design in while the system is young and painful to inject into a live one with patient data already flowing through it.

It helps to be concrete about what "HIPAA compliant" even refers to, because the phrase gets thrown around like a badge you buy. There's no certificate. What there is: a set of administrative, physical, and technical safeguards you can show you implemented, a risk analysis you keep current, and a signed business associate agreement with every outside service that handles the data for you. That last one trips up more early teams than anything else — the analytics tool, the email provider, the error tracker, each one is a vendor touching patient data, and each one needs a BAA or it shouldn't be in the stack.

Your data has to speak FHIR

The second force reshaping healthtech is interoperability, and it's moving on a calendar. CMS's Interoperability and Prior Authorization rule requires affected payers — Medicare Advantage, Medicaid, CHIP, and the plans connected to them — to stand up FHIR-based APIs, with the first provisions landing January 2026 and the core API requirements due by January 2027. In April 2026, CMS proposed extending the same approach to drug prior authorization. The deadlines keep arriving, and the standard underneath all of them is FHIR.

You might not be a payer, so the letter of the rule might not bind you. The gravity still does. Once the large systems your product needs to connect to all expose and consume FHIR, a proprietary data model becomes a translation problem you've signed yourself up to solve forever. The teams that designed their schema around FHIR resources from the start integrate in days. The teams that didn't tend to discover it the week a hospital partner asks how they exchange data.

This is the cheapest place to be disciplined early. Modeling a patient, an appointment, or an observation the way FHIR already defines it costs you almost nothing at the start and saves a migration later. Inventing your own version feels faster on day one and bills you for it on day five hundred.

What this means for how you build

The thread tying all of this together: in healthtech, compliance lives in the architecture, and the order you make these decisions in determines whether they're cheap or ruinous. A few things are worth getting right before the first real patient record exists:

• Don't roll your own compliant infrastructure. The major clouds offer HIPAA-eligible services and will sign a BAA. Building secure infrastructure from scratch is a way to spend a year reinventing what you can rent.
• Design access and audit logging in from the start. Who can read which record, and a trail of who actually did, is trivial to add early and a rewrite to add late.
• Vet every vendor for a BAA before you integrate it. If a service won't sign one, it doesn't get to touch patient data, however convenient it is.
• Treat the risk analysis as a living document. It's the first thing a regulator asks for, so it shouldn't be something you draft the week before a breach forces the question.

Connected devices add their own exposure. The market for internet-connected medical hardware was already worth around $47 billion in 2023, and every sensor, wearable, or monitor that streams data into your product widens the surface someone can attack. If hardware is part of the plan, the security model has to stretch all the way to the edge, not stop at the server.

I won't pretend any of this is free. Doing it properly adds time and cost to a build, and a founder racing to validate an idea feels every week of it. But the cost is mostly knowable, and a knowable cost is one you can plan around. You can budget for HIPAA-eligible infrastructure, for a FHIR-shaped data model, for a security review. What you can't budget for is the other path: a breach that averages well into seven figures, an OCR file landing on top of it, and the customers who quietly leave because a healthcare product that leaked their records is a hard thing to forgive. Between a known cost and an unknowable one, the known cost is the bargain.