Why Healthcare Is Different

Ship a checkout bug and a customer's cart empties itself. They are annoyed, they maybe tweet about it, and they buy the thing tomorrow instead. The company loses a transaction worth a few dollars to a few hundred. The failure is fully recoverable — refund the order, patch the code, apologise, move on. Most software failures, even bad ones, look like this.

Notice what makes that recoverable: the loss is measured in money, money is fungible, and the customer who was harmed is the same person who can be made whole again with a refund. All three of those hold for almost every consumer app you have ever used. Health tech is the category of software where none of the three reliably hold.

Ship a dosage-calculation bug and a patient gets the wrong amount of a drug. Ship a bug that silently drops a penicillin allergy from a record, and the next prescription written against that record can trigger a reaction. Neither failure has an “undo” button. You cannot refund a medication error the way you refund an order.

These are not hypothetical categories. Medication errors — wrong drug, wrong dose, wrong patient, or a dropped allergy flag like the one above — are estimated to harm well over a million people a year in the US alone, and a share of those errors trace back to exactly the kind of software bug that would be a shrugged-off ticket in a shopping app: a default value that silently overwrote a manual entry, a dropdown that defaulted to the wrong unit, a field that failed to carry over during a system migration.

In a shopping app, the person who clicks the button, the person who feels the consequence, and the person whose card gets charged are the same person. Their incentives point in one direction: they want the thing to work.

In healthcare, that alignment breaks into three separate parties. The patient uses the software and lives with the outcome. The provider — the hospital or clinic — chooses which software to buy and trains its staff on it. The payer — an insurer or employer — is who actually settles most of the bill, and was rarely in the room when the software was selected. Three parties, three different things each one wants: the patient wants to get better, the provider wants a tool its staff will actually use, and the payer wants the bill to be as small as the outcome allows.

Almost none of that lines up in a consumer app. When it doesn't line up here, software gets built to satisfy whoever is actually writing the cheque — which is not always the person the software is supposedly designed for.

A consumer app ships an update on a Tuesday and the whole user base has it by Friday. A hospital buying a new piece of clinical software is more often making an eighteen- month to three-year commitment before a single clinician touches it, because the software has to be evaluated, secured, integrated with an existing record system, and trained on before it goes anywhere near a patient.

1. 1

   Request for proposal

   The hospital defines what it needs and invites vendors to bid, often over months.

2. 2

   Security and privacy review

   The hospital's own IT and compliance teams audit the vendor before any contract is signed.

3. 3

   Clinical validation

   Clinicians test whether the tool fits an actual workflow, not just a demo.

4. 4

   Integration with the existing record system

   The new software has to exchange data with whatever the hospital already runs — see Part 2 of this track.

5. 5

   Staff training and phased rollout

   One department at a time, because a hospital cannot afford every unit learning a new system on the same day.

None of that is bureaucracy for its own sake. Every one of those stages exists because the cost of getting it wrong is the harm described two sections ago, not a bad app store review.

A consumer app answers to its app store and, loosely, to its own terms of service. Software that diagnoses, doses, or monitors a patient can fall under “software as a medical device” — a real regulatory category, not a loophole — and that means a government body has to sign off before it reaches a patient at all, not just review it after a complaint.

That slogan works when the cost of a bug is small and reversible enough that shipping fast and fixing later beats shipping slow and safe. Healthcare inverts both halves of that trade: the cost of a bug is not small, and it is frequently not reversible. Moving fast still matters — a clinic drowning in paperwork is its own kind of harm — but the same three months a startup spends on user growth, a health tech team often spends on validating that a feature is safe before anyone with a real diagnosis touches it.

Add the misaligned incentives from two sections ago and the picture completes itself. A shopping app that breaks things fast finds out from angry users within a day. Health software built to satisfy a payer, sold through a years-long procurement cycle, and gated by a regulator before launch can go a long time before the person actually affected by a design flaw ever gets a say in it.