POCUS: Success Is More Than a Device

Point-of-care ultrasound programs rarely fail for clinical reasons. The evidence settled years ago. Adding POCUS to the diagnostic pathway for acute dyspnea raises the rate of correct diagnoses without raising adverse events, which is why the American College of Physicians built a guideline around it. In internal medicine inpatients it changes or adds to the primary diagnosis in up to a quarter of cases and alters management in roughly half. Emergency medicine has required ultrasound training for more than a decade, and critical care, obstetrics, and increasingly family and internal medicine have followed.

Programs fail somewhere else entirely. They fail because images never reach an archive. Because documentation cannot support a claim. Because privileging was completed for the physicians who least needed it and never for the staff performing most of the scanning. Because a quality process designed for fifty studies a month was applied to five thousand. Because when the budget cycle came around, nobody could produce a number.

Every one of those is a delivery problem, and every one of them lands on the buyer.

The asymmetry nobody prices

Map the imaging value journey from population risk identification through acquisition, reporting, clinical decision-making, and population health management, then list what has to be true for imaging to produce value at scale. There are roughly fifteen foundational requirements. Vendors fully own three. They partially address four more. Everything else is unbuilt, unowned, or quietly assumed to be the customer's problem.

The vendor footprint concentrates in the middle of that map, at acquisition and reporting, which is where devices and their immediate outputs live. The upstream question of which patients should be imaged and the downstream question of what happens to the finding are both left to the buyer. That pattern has been stable for decades. It is not an oversight. It is the shape of a business built around capital equipment placement, and it worked when the capital equipment was the scarce resource.

In point-of-care ultrasound the equipment is no longer the scarce resource. Devices are portable, capable, and increasingly commoditized. The scarce resource is everything on either side of them.

So the pattern repeats predictably. A system evaluates devices, compares transducer configurations and AI features, negotiates a capital purchase, and discovers it has bought the smallest component of the thing it needed. What follows is eighteen to thirty-six months of internal work that nobody scoped, nobody budgeted, and nobody warned them about. The customer's hardest year begins the day the vendor's engagement ends.

Some organizations do that work well and say so honestly. The University of Rochester Medical Center is three years into a four-year enterprise deployment with 1,199 of a planned 2,000 probes live across more than seventy departments, and reports a 26 percent growth in hospital charges. They also report that they have not yet fully implemented their image storage policy, that documentation compliance among established providers remains a challenge, and that isolating POCUS-attributable revenue under a diagnosis-related group framework proved difficult enough that they tracked charges rather than revenue. That is what a well-run, well-resourced, publicly documented deployment looks like from the inside.

What a program actually requires

Twenty components have to be in place before a POCUS program produces clinical value that anyone can measure and defend. The device is one of them.

Three of the twenty are fully supplied by the device vendor, and all three live on the device. Six more are partially covered, meaning something ships but a gap remains that somebody has to close. Seven are yours entirely. Four are usually built by nobody, and those four are the ones discovered late.

Two sequences, both inverted almost everywhere

Most of the difficulty in this category traces to two ordering errors. Neither is complicated. Both are expensive.

Clinical need has to precede technology specification. A POCUS study is a decision instrument. Until you know which decision, you cannot specify the study, the report, the operator, or the technology. Yet almost no program writes down what precedes the study and what follows it before evaluating products.

What precedes it is the presenting problem, the tests and findings already in hand, and the alternative if POCUS is not performed. That last item is the comparator in every value argument the program will ever make, and in ambulatory settings it is frequently the clinical criteria a prior authorization will require.

What follows it is the decision the finding informs, the threshold that changes that decision, who acts and on what timeline, and what the finding must trigger downstream. Most useful POCUS answers a question with a decision boundary rather than a descriptive question. Reduced versus preserved ejection fraction. B-lines above a defined count. Bladder volume above a retention threshold. Naming the threshold is what converts an image into an action, and it is what the report has to state unambiguously.

Do that work and the technology conversation becomes tractable, because requirements now derive from constraints the pathway exposed rather than from a feature list. Skip it and you specify against a modality, which is how organizations acquire capability they do not need and miss capability they do.

Infrastructure has to precede devices. The dependency chain runs in one direction and does not negotiate. Workflow architecture determines whether images reach an archive. Archived images determine whether documentation can reference a stored study. Documentation determines whether a claim is defensible. Claims determine whether the program has a financial record. The financial record determines whether the program survives its second budget cycle. Quality assurance requires a retrievable sample, which requires the archive, which requires the workflow.

Break the chain at the front and every downstream capability degrades. The severity is easy to underestimate because the failure is invisible. The scans happen. Patients benefit. Clinicians are satisfied. And the program has no record, no revenue, no quality sample, and nothing to defend when someone asks what it produced.

Where artificial intelligence actually belongs

Two distinct capabilities get collapsed under one label, and separating them makes the decision clean.

Guided acquisition answers an operator constraint. It lets clinicians and staff without sonographic training obtain diagnostic-quality images in defined applications, with reported performance in some applications approaching expert benchmarks. If the people available at the point of need cannot reliably acquire the images the decision requires, this resolves it. If trained operators are already there, it resolves nothing and adds validation and monitoring burden.

Post-processing and automated quantification answer a reader constraint. If interpretation capacity is the bottleneck, if reads happen remotely, or if reader variation would change management, this resolves it. If the performing clinician interprets at the bedside and acts immediately, the case is weaker.

The two constraints are independent, and which one you have varies by use case inside the same organization. A rural clinic scanning with medical assistants has an acute operator constraint and no reader constraint. A cardiology practice with an echo backlog has the reverse. Buying the same package for both is how organizations pay for capability they never use.

There is a third distinction that is not about AI at all. Some systems produce a better image. Some produce a structured, coded inference that can populate a registry, feed a risk model, support a quality measure, or trigger a referral. The first improves a single study. The second determines whether the program's output participates in anything downstream.

Eight workstreams, and where your program actually is

The work divides into eight workstreams. Most of them run in parallel rather than in a strict line. Each one ends in a gate, a plain definition of done you can hold it to. Two dependencies are real and worth respecting. Clinical need has to precede technology specification, and infrastructure has to precede device deployment. Everything else advances together, and the gates tell you which workstreams are actually finished rather than merely underway.

Read the eight below and mark the ones your program cannot yet answer yes to. Those are where the work is, regardless of how many devices you have deployed. Most organizations rate themselves a workstream or two ahead of where the gates put them.

Two starting points

Published guidance in this category almost uniformly assumes an enterprise archive, an imaging informatics function, and a medical staff office. Health systems have those, and their problem is integration.

Primary care groups, specialist practices, and multi-site clinic organizations have none of them, and their problem is not integration. It is assembly. There is no PACS to route to, no informatics team to build the interface, no medical staff office to run privileging, and often no revenue cycle capability beyond a practice management system and a billing service. For these organizations the requirements do not disappear. The question becomes who meets them, and the answer is a vendor package decision covering device, cloud archive, revenue cycle enablement, quality assurance, and competency validation. That single decision sets the timeline to a billable study more than any other choice the practice will make.

What the industry owes

Consolidate every requirement this playbook places on a supplier and you describe a delivery relationship almost nobody in the category currently offers. That is not an accusation. It is an observation about what the commercial model optimized for.

Three patterns follow from it. Feature competition at the device level, because modality teams are rewarded by modality P&Ls, which means a health system buying across modalities from one manufacturer experiences separate contracts and account teams sharing no quota, pipeline, or strategy. Unstructured output, because devices ship images and reports while health systems need coded findings that downstream systems can consume. And the procurement cliff itself, where the commercial relationship intensifies through evaluation, closes at purchase order, and hands implementation to a services organization measured on a different clock than program success.

There is also a segment the model does not serve at all. The commercial motion is built for buyers with imaging infrastructure, and a large share of the clinically appropriate volume sits with buyers who have none. Serving them requires a package rather than a product, priced and contracted for an organization with no informatics staff and no tolerance for a six-month implementation. The offerings that attempt it tend to be complete on the components that resemble a product and thin on the components that resemble a service, which is precisely where the practice cannot substitute its own capability.

The alternative is not for imaging companies to claim they orchestrate care pathways. They do not, and the claim is not credible to anyone who has run a health system. Imaging contributes decisive information at specific decision nodes while the electronic health record coordinates the continuum around them. The defensible position is platform participation, which requires moving from device features to platform coherence, from reports to structured findings, and from hardware placement to program enablement. Owning more of the fifteen rather than three of them. Being measured on program outcomes at eighteen months rather than installed units at ninety days.

Health systems can accelerate this. Ask for the health economics evidence during evaluation. Ask which operator populations sit within cleared intended use. Ask what code the vendor expects you to bill. A question asked consistently across a market becomes a requirement.

The gray space and the white space

The gray space in this category is the eighteen to thirty-six months between procurement and program, where nobody's incentives align and most of the value is either created or lost. The white space is the delivery requirements that no one currently owns.

Both are addressable. Neither is addressed by a better device.

Where to go from here

The eight phases are reference rather than reading. Open the one you landed on. The pathway mapper is the phase two work made usable, and it is the step that changes what everything downstream costs.