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.