The Case For Accidental Interoperability

Many of us who follow #HITsm on Twitter have encountered the estimable standards guru Keith Boone (known there as @motorcycle_guy). Keith always has something interesting to share, and his recent article, on “accidental” interoperability, is no exception.

In his article, he describes an aha moment: “I had a recent experience where I saw a feature one team was demonstrating in which I could actually integrate one of my interop components to supply additional functionality,” he writes. “When you build interop components right, this kind of accidental interop shows up all the time.”

In his piece, he goes on to argue that this should happen a lot more often, because by doing so, “you can create lot of value through it with very little engineering investment.”

In an ideal world, such unplanned instances of interoperability would happen often, allowing developers and engineers to connect solutions with far less trouble and effort. And the more often that happened, the more resources everyone involved would have to invest in solving other types of problems.

But in his experience, it can be tough to get dev teams into the “component-based” mindset that would allow for accidental interoperability. “All too often I’ve been told those more generalized solutions are ‘scope expansions,’ because they don’t fit the use case,” and any talk of future concerns is dropped, he says.

While focusing on a particular use case can save time, as it allows developers to take shortcuts which optimize their work for that use case, this approach also limits the value of their work, he argues. Unfortunately, this intense focus prevents developers from creating more general solutions that might have broader use.

Instead of focusing solely on their short-term goals, he suggests, health IT leaders may want to look at the bigger picture. “My own experience tells me that the value I get out of more general solutions is well worth the additional engineering attention,” he writes. “It may not help THIS use case, but when I can supply the same solution to the next use case that comes along, then I’ve got a clear win.”

Keith’s article points up an obstacle to interoperability that we don’t think much about right now. While most of what I read about interoperability options — including on this blog — focus on creating inter-arching standards that can tie all providers together, we seldom discussed the smaller, day-to-day decisions that stand in the way of health data sharing.

If he’s right (and I have little doubt that he is) health IT interoperability will become a lot more feasible, a lot more quickly, if health organizations take a look at the bigger purposes an individual development project can meet. Otherwise, the next project may just be another silo in the making.

About the author

Anne Zieger

Anne Zieger

Anne Zieger is a healthcare journalist who has written about the industry for 30 years. Her work has appeared in all of the leading healthcare industry publications, and she's served as editor in chief of several healthcare B2B sites.


  • This article says a lot about the sad state that software development has become. If one doesn’t aspire to and develop generalized solutions, one should not be in the software development business IMO.

    Ever since the Object Oriented Programming (how to think backwards) craze got started, the profession has relied on process methodology as a substitute for intelligence. And those “helpful” cookie-cutter tools that are used (did someone mention ‘use cases’?) virtually insure a “quick-and-dirty” result.

    Call me an old fogy, but I think that a background in Unix and the out-of-fashion procedural programming approach naturally will lead to the “component-based” generalized results of which you speak. Once one is well versed in the power of the various Unix tools including ‘piping’, it’s hard NOT to think generally.

  • David,
    That’s true until your boss puts an unreasonable deadline before you and so you have to have to hack together a solution for that deadline. Then, all the good intentions and ideas go out the window and we get the quick and dirty solutions we have today. Think about the crazy deadlines that MU and EHR Certification have provided us and the impact that has had on the EHR industry.

Click here to post a comment