Why are the new eHealth Exchange content interoperability standards and requirements necessary?
Ask just about anyone on your interoperability team about their experience consuming or producing C32s or CCDAs and you’ll probably get an earful about how it’s the “Wild West” out there for clinical documents. Vendor A doesn’t support this component. Vendor B puts it in the “wrong place.” Vendor C puts it in the right place but doesn’t include all the information… The list goes on.
Think of it as a Venn diagram between specification, interpretation, and convention, with different groups of stakeholders promoting different mixes of the three factors resulting in incompatibilities across these “specification fiefdoms”. Disagreements erupt across these borders as unsuspecting participants try to integrate with different fiefdoms- at the Zen offices, we jokingly refer to these as “SpecWars” (short for “specification wars”).
The result is usually different flavors of documents depending on which vendor/stakeholder ecosystem you’re attempting to integrate with and the associated (often unexpected) development time and cost overruns.
We like how the folks at xkcd.com illustrate the situation.
(Illustration source: https://xkcd.com/927/)
Doesn’t this fly in the face of healthcare interoperability? Yes. But, how can we get everyone on the same page?
Getting everyone on the same page:
This testing requirement is a big step in that direction. A national, impartial entity like eHealth Exchange creating and enforcing strict compliance to their detailed specification helps hold up one, very specific goal for all the various stakeholders to work toward, with the clout to avoid becoming “yet another standard”.
Zen Healthcare IT’s Service Bulletin:
For organizations seeking to remain a partner or to complete
