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.
-- Keith
* While that may not be the politically correct term, it does tell you what it is.
As you indicate SSA needs to gather medical information to determine disability claims. Since they are not part of TPO activities, they needed to piggy-back on national efforts such as the NwHIN Specifications. What is actually very interesting is that they brought a business case to the table to encourage healthcare organizations and health information exchanges to the table.
ReplyDeleteBenefits
SSA pays for medical records provided by healthcare providers using the eHealth Exchange, automated release of information with a patient authorization, automated payment for successful payable transactions and the largest benefit is healthcare coverage through Medicaid/Medicare for patients that have been approved for SSA disability that may have been uninsured or underinsured. This last benefit helps not only healthcare providers but patients too. Many patients that file for disability may use charity care or be self-pay patients that end of going to collections since they are unable to work and pay for care.
Large and small organizations can see these benefits.
There is another way that a smaller organization could see these benefits beyond using an aggregator like a health information exchange is to use an EHR that (directly or indirectly through a vendor) supports an Exchange gateway.
The beauty is that SSA has been leveraging existing national standards and policy for the past four years, but also provides a positive business case that benefits not only SSA, but healthcare providers, EHRs, HIEs and ultimately patients.
Everybody wins.