How US Health Systems Actually Buy Software

I have spent most of my career on the selling side of complex enterprise deals, and the pattern I kept running into is the same one I now watch play out in healthcare. The technical conversation goes well. The demo lands. Everyone in the room agrees the thing should exist. Then four months pass and nothing has moved, and when you finally get an honest answer it has nothing to do with the software.

Healthcare makes this worse than most industries, because the number of people who can stop a purchase is unusually high and the number who can start one is unusually low. Understanding where those people sit is most of the job.

There are three buyers, and none of them can say yes alone

In almost every health system deal of any size there are three constituencies, and they want different things.

The clinical or operational sponsor is the one with the problem. A VP of revenue cycle watching denials climb, a CMIO whose physicians are charting at nine at night. They have urgency, they will champion you internally, and in most systems they do not control the money.

The IT and security organisation owns the risk. They are measured on breaches that did not happen and integrations that did not break, which means their incentive runs opposite to speed. They cannot usually approve a purchase, but any one of them can stop it indefinitely, and they frequently do.

The finance and procurement side owns the contract and the budget calendar. They care about which bucket the spend comes from, whether it was planned, and what the exit looks like if it fails.

A deal moves when all three are satisfied at roughly the same time. Most stalls I have seen are not a rejection from any of them — they are the three being satisfied months apart.

Security review is the real gate, and it starts before you expect

If the software will touch PHI — and in healthcare it usually will — third-party risk assessment is not a formality at the end. It is the longest pole, and it often begins the moment IT hears your name.

What you will be asked for is reasonably predictable: a completed security questionnaire, a SOC 2 Type II report or HITRUST certification, evidence of recent penetration testing, your subprocessor list, your breach notification process, and a signed Business Associate Agreement before anything with patient data moves. Larger systems route this through a dedicated vendor risk platform, and the assessment goes into a queue with everyone else's.

Two things reliably add months here. The first is arriving without the artefacts and assembling them under deadline. The second is a subprocessor nobody mentioned — an AI model provider, an offshore delivery team, a cloud region outside the US — surfacing halfway through review. That is not a disqualifier by itself, but discovering it late converts a routine assessment into a trust problem.

We treat this as an engineering concern rather than a sales one, which is why SOC 2 readiness and HIPAA compliance architecture are things AST builds into delivery rather than documenting afterwards. The difference shows up in how long review takes, not in whether you pass it.

Procurement runs on a calendar, not on momentum

This is the part that surprises people coming from software sales elsewhere. A health system's buying machinery runs on cycles that have nothing to do with how your conversation is going.

Capital expenditure is frequently planned a year ahead, and if your project was not in that plan it may genuinely have to wait for the next one — or be restructured as an operating expense, which changes who approves it. Many systems run fiscal years that do not match the calendar, so the urgency your sponsor feels in March may be shaped by a budget that resets in July. Committees that review new technology often meet monthly, and missing one by three days costs you four weeks.

None of this is obstruction. It is how an organisation that cannot afford surprises manages spending. But it means the single most useful question in a first call is rarely about requirements.

Where deals actually die

Having watched a fair number of these go sideways, the failure modes repeat.

• A champion with no budget. The most enthusiastic person in the room is often the one furthest from the money. Enthusiasm is necessary and it is not sufficient.
• Scope that crosses two departments. A project touching both clinical documentation and billing needs two sponsors who each think the other should pay. These stall quietly, and usually permanently.
• An unexamined integration dependency. If the work requires anything from the EHR vendor's own program or a third-party interface team, that timeline belongs to someone who is not in your meetings and has no stake in your quarter.
• A pilot with no defined end. Pilots that were never scoped to conclude do not convert. They are extended, then defunded.
• Silence read as progress. Long gaps in healthcare procurement are normal and tell you nothing. A deal with no internal advocate looks identical to a deal waiting on a committee, right up until it does not.

What integration actually adds to the timeline

Most proposals I see underestimate this, and not because anyone is being optimistic about the engineering. The engineering is usually the predictable part.

Writing into a chart is a different conversation from reading from one, and it tends to involve the EHR vendor rather than just the health system. Interface work is frequently queued behind the system's own projects. Test environments have their own access process. If the data has to reach a payer, that is another party with another timeline.

At AST we scope EHR integration by naming every party whose approval the work depends on before quoting a date, because a schedule that assumes only two organisations are involved will be wrong by months in a way that damages trust at exactly the point you need it. Our EMR/EHR development engagements start the same way, with the dependency map rather than the feature list.

How I would run the first conversation

1. Map the three constituencies Ask directly who the clinical sponsor, the security owner and the budget holder are. Write down the names. If one is missing, that is the gap to work on, not the requirements document.
2. Find the budget line Capital or operating, this year or next, whose department. This single answer predicts the timeline better than anything else you will learn.
3. Start security early Ask for the vendor assessment process in the first two weeks. Volunteer your SOC 2 report, your subprocessor list and your BAA template before anyone requests them.
4. Name every dependency List the organisations whose approval the work needs — the EHR vendor, an interface team, a payer, an existing vendor whose contract overlaps. Agree the list with the buyer so the timeline is shared rather than assumed.
5. Scope the pilot to end Define what it proves, how long it runs, what number or judgement converts it, and who makes that call. A pilot without a defined conclusion is a subscription to being evaluated.
6. Confirm the committee calendar Find out when the relevant group meets and work backwards. Most urgency in healthcare procurement is calendar urgency.

None of this is about being clever in the room. It is about finding out early which of the four things that can stop a deal is going to be the one that does, and dealing with it while there is still time.

Why this shapes how AST sells

We would rather lose a deal in week three than month nine, and that preference changes what the early conversations look like. We ask about budget lines before scope. We volunteer the compliance artefacts before they are requested. We put the dependency map in the proposal, including the parties we do not control, because a date that quietly assumes otherwise is a date we will miss.

It makes for a less comfortable first meeting than the version where everyone agrees the technology sounds good. It also means the projects that reach a contract tend to reach production, which is the only part either side is actually paid for.