7 traps to skirt on way to interoperability
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.
The reason that language is so germane here is that FHIR is mostly about clinical terminologies and content standards – the language of health information exchange. The HL7 processes for modeling how information is recorded and exchanged have historically been very slow and cumbersome. They also have not always had technologists and health professionals both contributing to the process. The new data modeling suggested in FHIR look to greatly accelerate the process to enable more rapid adoption of a common language for 80 percent of the need.
Unfortunately, in the rush to this new modeling approach a lot of additional expectations have been conflated through the hype and the acronym and jargon filled health IT conversation. No one benefits from this in general. Specifically though, the unattended technical and standards needs that are jumbled together will come back to bite FHIR here too. JSON is, if anything, less constraining than XML. But it is constraint that interoperability needs. REST, oAuth, OpenID and other technical standards need constraint and specification if they are to work for health too and it is not at all clear that this is being done.
And as tedious as previous data modeling methods have been, the long pole in the health language standardization tent is not the data modeling, but is rather getting people to work through a process for agreement and adoption of the packages for different business needs. Having a shared pool of 80 percent of the data would be great, but there are still needs to identify the specific parts of the 80 percent that are to be used in each transaction to meet health business and policy needs. Chasing FHIR puts us back at the start of identifying and specifying all of them.
6. Avoid Blocking and Tackling – The opposite of the bright and shiny object phenomenon is the tedious, obsessive attention to incredible detail and consistency that is necessary to have one software system securely share something with another system and have the meaning persist. In the health language domain, this dreary, mundane blocking and tackling is about specifying data and packages of information for specific purposes. It is largely antithetical to the narrative text that most humans are more comfortable with and, frankly, it involves being inflexible. Options for expression are the enemy of interoperability but are frequently the result of striving for consensus. The Consolidated Clinical Document Architecture (C-CDA) is the latest victim of this dynamic. This bright and shiny object was recently sold as being better than previous summary of care standard efforts because it was more flexible – and it is. The technical confusion (CATT), though, did not insure that the blocking and tackling of specification and constraint was achieved and has led to a difficult solution at best.
There is also more purely technical blocking and tackling to do. With all of the talk of onerous regulations, for example, even simple things such as having digital certificates for EHRs and other systems consistently in place is missing. Digital certificates are needed to encrypt data being exchanged between organizations and to secure those connections. This is another place where other standards being conflated with FHIR and general technical terminology confusion are operative. If, alternatively, there is a suggestion that username and password will be enough for system to system encryption and authentication, that would only be if there is not enough discussion of the risks. If there is a suggestion that tokens from the oAuth standard will suffice, then where are the examples of system-to-system use that is meeting sensitive health data needs? Otherwise, where is the technical blocking and tackling that asserts that every EHR should have a digital certificate?
7. Think “There is an App for That” – A lot of the talk of FHIR has been aligned with the suggestion that open application programming interfaces (APIs) will solve the interoperability problem. Sometimes added to FHIR is the suggestion that EHRs can have third party “apps” that can be developed and distributed to run on EHRs. At times it seems that what is being suggested is that all data exchange needs really should be replaced by apps that would run in this EHR-centric view of the health IT world. Just like with FHIR there is some value here. Apps are a new model for developing programming code and logic to run on in clinical care without having to have each EHR company code it themselves. The challenge of distributing code and logic is a long standing one.
But apps are not a substitute for data exchange and interoperability - they are a potential complement to it. The Meaningful Use incentive dollars have so focused the discussion on EHRs there is sometimes a failure to recognize all of the other health IT systems that need to be interoperable with EHRs and need to send and receive information. These other systems that are run in other organizations to support other users cannot be coded into EHR apps. So here, too, with this promising approach to distributing code and logic, there is technical confusion about the problem it is trying to solve and a rush to think that it may be a solution to “everything.”
In truth, there is a lot of blocking and tackling needed before either APIs or apps are viable solutions to the specific problems for which they do make sense. APIs need to address the problem of how they will not bring EHRs to their operational knees from well-intentioned but computationally taxing code. It is not the EHR vendors who necessarily see this problem. But all the operations folks who are wary of someone crippling their mission-critical EHR with a poorly formed query will be intensely interested in these controls. In the original Nationwide Health Information Network efforts, no one would point those “organizational APIs” directly at operational systems like EHRs because of these fears. The result can be the implementation of “shadow” systems that the APIs are actually pointed at defeating some of the purpose of having API’s to begin with. The highly federated nature of EHRs also presents issues for using broader populations of individuals than EHRs tend to encompass. Where is the architecture for providing other than practice specific or organization specific queries and interactions?
Finally, app stores will have limited use if there are many of them and they are not compatible. A significant amount of the appeal of using apps to distribute code and logic is based on the ability to share such apps with multiple or all EHRs – not just one. Think about the Android vs. the Apple vs. the Microsoft app stores. Apps have to be coded for each of them separately. Will we have app stores for each EHR? Even the proponents of the app store approach admit that there is much more to standardizing apps than anything that FHIR is offering in the near future. Don’t we need app certification and regression testing to address these and other app issues? How long with that take to get in place?
There is a lot of interoperability opportunity to be had in health IT. Hopefully, learning from the efforts of the past will get us to that opportunity sooner rather than many years later.