Liability for a system of action
The ability to own the decision will define the next great generation of healthcare companies.
For the last twenty years, software has been very good at consistently automating actions that someone else had already decided should be taken. Decisions lived with people; the software scaled execution.
Today, we can automate the decision itself. And decisions, unlike actions, carry consequences. Consequences carry liability. If your software decides which medication a patient is actually on, which comorbidities matter in a case, or whether a patient is ready for surgery, then someone needs to own the quality of those decisions. The interesting question is who.
Most software vendors have answered that question by punting it back to the customer. Our tool is a decision support. The clinician is the final word. That answer is fine for a recommendation engine on a shopping site. It does not hold up well in healthcare, where the consequences are large, the regulator is awake, and “the clinician must review” is a real amount of work that the clinician does not have the bandwidth to do.
The ability to own the decision, and accept the liability that comes with that, will define the next great generation of healthcare companies
A detour through cars
The cleanest version of this argument did not happen in healthcare. It happened on the road over the last decade.
For years, Tesla sold a dream. Their hardware would ship to the consumer; the consumer would own the asset; and when they weren’t using the car, it could be opted into a Tesla-controlled network and earn its owner passive income as an autonomous taxi. Asset-light for Tesla. Liability-light for Tesla. Unbounded upside for everyone, in theory.
The cracks were always in the same place: who owns the asset, who owns the insurance, and who owns the consequence when the car gets it wrong. Tesla’s autonomous systems have prevented some crashes and caused others. Regardless of what their crash rate is, and how it compares to that of human drivers. It’s not contentious to say that the rate is not zero, and won’t be for the foreseeable future. In a model where the consumer holds the title, and Tesla holds the algorithm, the answer to “who pays” gets murky fast.
Waymo went the other direction. They built their own cars, owned their own fleet, bought their own insurance, and stood up remote human operators as a fallback. On a cost-structure basis, Waymo looks much more like a taxi company than a software company.
Five years on, Waymo is doing roughly 500,000 paid rides a week and growing. Tesla has quietly walked back the consumer-fleet pitch in favor of building its own robotaxi network, which is to say in favor of looking more like Waymo. The market told them which model was actually scaling.
Why owning the stack wins
There are two structural reasons the heavier model outperforms over time, and they apply far beyond ride-hail.
1. Less change management for the customer. When you own all the pieces, the customer adopts an outcome rather than a workflow. You can swap what’s under the hood without renegotiating their interface, their training, or their compliance posture. Adoption is faster because it asks less.
2. Faster iteration. When the pieces that need to fit together are all yours, you don’t need permission to rearrange them. You don’t have to wait on a partner’s roadmap, a customer’s IT calendar, or a vendor’s API council. The loop from problem to fix is much shorter, and in a regulated market, that compounds.
Back to healthcare
The same fork shows up in every healthcare AI conversation right now.
If your tool makes decisions but shifts liability back to the hospital, you’ve actually created uncapped liability. Before they can adopt you, they have to build the monitoring infrastructure, the QA processes, and the audit trail to defend whatever your tool produces, which creates a significant barrier to adoption. Even if you provide those analytics, the customer would still need to staff and monitor.
The other path is to absorb that work yourself. Build the QA into the product. Stand behind the output. Take the liability for what you produce.
The economic upside of doing that is significant. If your underlying cost structure is mostly software, taking on the labor-like responsibility of owning quality lets you price like labor while still earning software margins. You get greater control, greater stickiness, better revenue per customer, and faster adoption.
Liability is coming anyway
The risk of not picking the heavier model is not that you stay where you are. It’s that you get caught flat-footed.
Courts have started narrowing the safe-harbor logic that platforms have leaned on for years. A recent verdict against Meta and YouTube found the platforms liable in cases the industry assumed were settled. A parallel ruling against Workday extended that thinking to enterprise AI. The trend is consistent: the era of “we just provide the tool, the customer is responsible for what comes out” has passed midday.
Vendors who design for liability ownership now will be ahead of that curve. Vendors who don’t will inherit the same exposure without any of the upside that comes from having priced and built for it.
How Orchestra is simplifying patient readiness
This is one of the fundamental bets we’re making at Orchestra. We don’t sell a recommendation that the clinician must verify; we own data ingestion, reconciliation, clinical QA, and the output end-to-end. The company’s economic model looks more like a service than a SaaS tool, and that is the point.
Owning the work lets us own the decision, and owning the decision lets us actually move the needle on patient readiness instead of adding one more tab a clinician has to check.
The next generation of great healthcare companies will look heavier than the last one. That is not a bug, it’s a feature.