Map the pathway
Every use case has a completed pathway map, and technology requirements were derived from it.
A POCUS study is a decision instrument. Until you know which decision, you cannot specify the study, the report, the operator, or the technology.
This is the phase that most program guidance omits entirely, and its absence explains a great deal of what goes wrong later. Programs that skip it end up specifying technology against a modality rather than against a decision, which is how organizations acquire capability they do not need and miss capability they do.
Every POCUS use case sits inside a pathway. Something precedes it, which is what brought the patient to the point where imaging became the right next step. Something follows it, which is the management action the finding is supposed to inform. Both ends determine what the study must capture and what the report must direct.
What comes before
For each use case in scope, document the entry conditions.
The presenting problem. What symptom, sign, or risk state brings the patient into this pathway. Acute dyspnea, undifferentiated hypotension, suspected volume overload, abnormal screening result, post-procedure surveillance, a positive review of systems in an annual visit.
What has already been done. Prior imaging, laboratory results, physical examination findings, prior POCUS studies on the same patient. This matters for three reasons. It establishes medical necessity in the documentation. It tells you whether the POCUS study is the first look or a comparison. And in ambulatory settings it frequently determines whether prior authorization applies, because payer policy often conditions coverage on what was tried first.
The alternative if POCUS is not performed. Referral to formal imaging, empiric treatment, watchful waiting, transfer. The alternative is the comparator in every value argument the program will ever make, and defining it now prevents having to reconstruct it under pressure in Phase 5.
What comes after
This is the half that determines report design.
The decision the finding informs. Treat or do not treat. Admit, observe, or discharge. Order the confirmatory study or stand down. Adjust the medication. Refer to specialty. Proceed with the procedure. Escalate care level.
The threshold that changes the decision. Most useful POCUS answers a question with a decision boundary rather than a descriptive question. Reduced versus preserved ejection fraction. B-lines present above a defined count. Bladder volume above a retention threshold. Effusion with tamponade physiology. Naming the threshold is what converts an image into an action, and it is what the report must state unambiguously.
Who acts on it and when. The performing clinician acting immediately is a different report requirement than a finding routed to a primary care physician for follow-up next week, which is different again from a finding that has to reach a specialist for a referral decision.
What the finding must trigger downstream. An order, a referral, a registry entry, a risk model input, a quality measure numerator, a recall for surveillance. Anything the finding must trigger automatically has to exist as a discrete, coded field rather than as prose in a note.
The pathway map
Complete one row per use case before any technology conversation.
| Element | What to record |
|---|---|
| Use case name | |
| Care setting | |
| Presenting problem or risk state | |
| Prior tests, findings, or events that precede it | |
| Alternative if POCUS is not performed | |
| Question the study answers | |
| Study type | Rule out, triage, quantify, monitor over time, guide a procedure |
| Decision threshold | |
| Decision the finding informs | |
| Who acts, and on what timeline | |
| Required downstream trigger | Order, referral, registry, recall, measure |
| Who performs the study | |
| Who interprets | |
| How the finding is communicated | |
| How we will know it changed anything |
The last row is the program's outcome measure for that use case, and defining it here rather than in Phase 6 is what keeps quality assurance connected to clinical purpose rather than reduced to image review.
From pathway to solution requirements
Now the technology conversation becomes tractable, because requirements derive from constraints the pathway exposed rather than from a feature list.
Read the map for each use case and identify which constraints are actually present. Then, and only then, specify capability.
| Constraint the pathway reveals | Capability requirement it creates |
|---|---|
| The people available at the point of need have no sonographic training | Guided acquisition with real-time feedback and an acquisition quality indicator |
| Acquisition quality varies enough to change the answer | Objective acquisition quality scoring, view verification, exportable acquisition metrics |
| The decision turns on a quantitative threshold | Automated quantification, with documented agreement against a reference standard for that measure |
| Interpretation capacity is the bottleneck, or reads occur remotely | Post-processing, preliminary quantification, remote read routing, worklist management |
| Variation between readers would change management | Standardized measurement, blind re-read capability, reader analytics |
| The finding must trigger an order, referral, recall, or registry entry | Structured, coded output mapped to discrete EHR fields |
| The finding must be comparable to a prior study on the same patient | Longitudinal patient-level retrieval, consistent measurement method, prior study accessible at the point of read |
| The study happens where no archive exists | Cloud archive with a business associate agreement, defined retention, and a retrieval commitment |
| The organization has no imaging billing capability | Revenue cycle enablement covering coding, documentation templates, claim submission, and denial management |
| Prior authorization applies in this setting | Eligibility and authorization workflow, with the clinical criteria documented against payer policy |
This table is the core discipline of the playbook. Artificial intelligence appears twice in it, once as guided acquisition answering an operator constraint and once as post-processing answering a reader constraint. Neither is a program objective. Both are answers to specific questions the pathway asked. A use case where trained operators are already available and reader capacity is not constrained does not need either one, and buying them anyway adds cost, validation burden, and monitoring obligation without adding value.
Run this exercise per use case rather than per program. A single organization will frequently find that one use case needs guided acquisition badly and another needs none of it, and that the real shared requirement across both is structured output nobody was asking for.
In the practice setting
The pathway work matters more here, not less, because the practice cannot absorb a mistake.
A health system can carry a use case that turns out to be marginal. A twelve-provider primary care group cannot. The pathway map is what tells a practice whether POCUS is a revenue-generating service line, a referral-avoidance play, a quality-measure enabler, or a clinical convenience that will not pay for itself. Those are four different decisions and only the first justifies a capital and workflow commitment on its own.
Two additional entry conditions belong on the practice map. Whether the study is being performed in place of a referral the practice currently sends out, which defines both the revenue opportunity and the referral relationship it affects. And whether the payers in the practice's mix cover the service in an office setting at all, which is a question to answer before the pathway map is finished rather than after.
What to require from your vendor
Bring the pathway map to the vendor conversation and ask them to respond to it rather than to present against it. The useful questions all derive from the map.
For each capability they propose, which constraint on our map does it address. Where a capability is offered that no constraint on our map requires, what is it for and what does it cost separately.
For any quantification capability, what the agreement is against the reference standard for that specific measure, in a population resembling ours. For any guided acquisition capability, which operator populations the evidence covers.
What the system produces that is discrete and coded rather than narrative, and whether those fields can populate the downstream triggers our map requires.
A vendor who cannot map their offering to your constraints will map your constraints to their offering. The order matters.
Failure mode
Technology is specified against the modality rather than against the decision. The organization acquires guided acquisition for a department that already has trained operators, misses structured output for a use case whose entire value depended on triggering a referral, and writes a report template that describes findings without stating the threshold that would change management. Clinicians use the tool, find it useful, and cannot explain to anyone why it mattered.
Gate criteria
This is one of the two genuine dependencies. The workstream is done when every use case in scope has a completed pathway map, the constraint-to-capability translation is documented, the outcome measure for each use case is defined, and the resulting requirements set is written down. Because those requirements are the input to technology selection, this work precedes device specification rather than following it.