Pathway mapper
One map per use case. What precedes the study and what follows it determine what the read must capture, which operator can perform it, and which capabilities you actually need to buy.
Before
What brings the patient here, and what happens if you do not scan.
The study
A useful POCUS question has a decision boundary, not a description.
After
The half that determines report design.
Constraints
Check only what the map above actually exposes. A box left unchecked is a capability you do not need to buy.
Run this per use case rather than per program. A single organization frequently finds 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.
Requirements appearing across multiple use cases are the ones to solve architecturally. Requirements appearing once should be scoped and priced separately, and should be defensible on that single use case alone.