Viewpoint of the Implementer: Perceived Cost to Implement ≫ ROI
Viewpoint of the Beneficiary: ROI > Perceived Cost to Implement
This situation is fairly common, especially in cases of secondary use*. My first encounter with this inequality was back in the days of HITSP, when the Social Security Administration was trying to figure out a standards-based solution to obtain clinical documentation of disability for a patient.
When you look at this problem from the perspective of the SSA, it's a pretty large one, since it accounts for a significant portion of their work. When you look at it from the perspective of a small healthcare provider, there's little value because the number of disability cases they deal with doesn't provide sufficient value to invest in an automated solution (or competes with much more valuable workflows where automation could help, like lab orders and results).
One way to resolve this inequality is to piggy-back on existing work. The SSA took advantage of the NwHIN Specifications to meet their specific needs. Doing so reduced the cost of implementation to a point where Cost to Implement became less than ROI for organizations with enough of a workload.
It still didn't reduce it the cost enough for smaller organizations. That's when aggregators can come into play, like clearing houses and health information exchanges. These organizations can automate because their volume warrants it, whereas for smaller providers, it doesn't. But this step likely won't work if you didn't take that piggy-back step first, because then you'd need smaller providers to do something different for your "secondary" workflow.
This brings up another point about the "art" of interoperability. You need to consider the fact that the solution you design today will be used for things other than what you intended tomorrow, but not so much that it becomes so complex as to be unimplementable. It's a tricky balance.
* While that may not be the politically correct term, it does tell you what it is.