7 traps to skirt on way to interoperability
April 6, 2015 in Medical Technology
Kudos should go to Karen DeSalvo and the Office of the National Coordinator for Health IT for finally giving interoperability a central place in the national health IT conversation. Among other things, they have added an Interoperability Roadmap and a Standards Advisory to Stages I, II and now III (in draft) of Meaningful Use and to the burgeoning list of reports (PCAST, JASON, Rand, etc.) that have extolled the need for interoperability progress. Congress is getting back into the interoperability mix too and, together, the whole national talk soup seems almost ready to boil.
But despite all of this talk, objective measures suggest that health IT interoperability itself is still only barely simmering. In this intensely complicated, jargon and acronym-filled area, learning from the past is critical to making an interoperable future work. So, here are seven aphorisms articulating learned lessons that need to be fully digested now if we are to really get interoperability cooking.
Health IT interoperability will not progress if we:
1. Don’t Pay to Play – Health IT interoperability needs incentives too. It is unlikely that we will see 30 billion more dollars for health IT in our lifetimes, but interoperability is work that has technical, legal, business, and lost opportunity costs. There are known disincentives for exchanging health data, and the natural benefits of interoperability frequently accrue to someone other than those who must execute it. Standards and interoperability are not easier; they are harder, take more commitment, and need support to overcome barriers.
Financial, business and/or regulatory incentives are critical to interoperability success, but incentives are not part of the ONC Interoperability Roadmap. The HITECH / Meaningful Use leverage was mostly used for other things and even that is significantly waning. Health reform and market incentives can align with some interoperability needs, but they are down the road for some areas and not applicable to others. If we cannot tie together networks enough to advance “network effects” where people and organizations want to join, it is hard to see how congressional action isn’t the inevitable last resort.
2. Reinvent the Wheel – There are a lot of ways this one can be applied to health IT interoperability – anywhere from technologists’ love of the latest and greatest technologies to the propensities of government administrations to shun anything that happened before them, but I am going to push the metaphor further and make this about network architecture. Said simply, “many-to-many” integration, exchange, and interoperability do not work well.
Hub-and-spoke networks, where the “many” connect to each other through one or more “hubs,” are much more implementable. Look at the production implementations of e-prescribing, electronic claims, and the too-numerous examples from other industries and you will see that hub-and-spoke approaches of some kind dominate real-world data exchange. Health Information Exchange Organizations – HIEs – are hub-and-spoke models that only some have been willing to commit to fund. Health Information Service Providers. or HISPs, were another effort to align a business model with hub-and-spoke design. Regardless of the specific approach, further work needs to be done to make some sort of “hub” viable in the health information exchange picture.
3. Try to Rule the Road – Trust is a critical component of health information exchange and interoperability. And patient privacy must be protected, but the previous effort from ONC to establish “rules of the road” looked a lot like it would curtail exchange rather than enable it. The industry pushed back on that effort and it is hard to see why the new “rules of the road” effort named in the Roadmap will be more successful.
On the other hand, eliminating the need for point-to-point data use agreements and a commitment by all participants to respond to legitimate electronic requests for critical patient data from others are critical policy steps to a robust exchange environment. These were the fundamental elements of the original Nationwide Health Information Network Data Use and Reciprocal Support Agreement, or DURSA, and it worked quite well for a while. But this is a situation where imitation is not flattery at all and the advancement of multiple DURSA’s, instead of pushing to join a common one, defeats some of the purpose of any of them. A second generation DURSA-like approach to facilitating exchange rather than regulating it, and eliminating the need for point-to-point data use agreements, is a must for local or nationwide interoperability. The concerning new trend of expecting organizations to pay to access data held in another organization must be either stopped or otherwise managed immediately.
4. Focus on Bright and Shiny Objects – In the past, interoperability has been forestalled numerous times by folks chasing after the next bright and shiny object on the horizon. It is always nice to think that the next standard or technology will be so great that it will become the “only one” and that consistency and interoperability will ensue. Inevitably though, the new standard and technology does not become the “only one,” but becomes “another one” and for a while at least, the environment is even more complicated. Unfortunately, with time, the shortcomings of any approach become more prominent and the next standard or technology after the now not-so-new one begins to look brighter and shinier.
It is hard to not think about some of the current talk about HL7 FHIR and API’s in this way. Stage II and III of Meaningful Use and those who led them told us that SMTP and Direct were the answer to the exchange problem. Direct was not the solution, but do all of the folks who have recently committed to using it know that? Do they know that the Direct protocols have now been abandoned as a path forward? Nationwide adoption of anything takes a long time and now we have SOAP (Integrating the Hospital Enterprise), SMTP (Direct) and people looking to FHIR (and RESTful approaches). Like old software systems, old standards don’t go away very quickly. RESTful approaches are probably more robust than SOAP and can leverage other Internet standards, but nationwide interoperability could have been achieved with SOAP. As important as a new technology is a schedule for when it will be mature and it is reasonable to use it, and a glide path for the environment to get there are responsible components of industry leadership.
5. CATT (Confuse with Acronyms and Technology Talk) – The previous item makes a perfectly valid point related to the way that people perceive FHIR, but FHIR is actually not specifically about REST or transport standards. That is the way that it is being perceived by many in the national conversation, but being so is a function of how opaque and difficult interoperability related conversations can be. There are several points here. First, if technologists cannot explain in English what they are saying, don’t assume that they are right. Second, those that do not speak in technical tongues need to be willing to be patient and have full English explanations presented to them without giving up and moving on. If either side is an impediment to good communication and full understanding, they should probably not be a part of the conversation.