A Serious Proposal For Healthcare IT Interoperability

progressive companies that have made significant contributions to interoperability. However, there are hundreds of health IT companies, and, as one would expect, they vary significantly in their commitment or willingness to adopt interoperability standards without a mandate. They may lack the resources or skills to adopt a standard that is overly complex. It is also not clear that many health enterprises would willingly provide access to patient data without some incentive or mandate. In my view, we need, not just a new technical approach, but also incentives approaching a mandate.

To accomplish this, the JTF specifically recommends that the ONC/CMS exercise what it calls "three levers":

If there is a technical controversy already generated from this, it may well be the future role of document standards (e.g., the Consolidated Clinical Document Architecture or CCDA). The JTF recognized the role of these standards:

Given the long-term nature of this transition, we would not expect nor recommend that current interoperability activities be halted or delayed in anticipation of an API-based framework. Even with its limitations, the current framework for document-based exchange offers opportunities to improve the quality, safety, efficiency, and affordability of care and will live in parallel with the growth of an API-based approach for some time to come. These recommendations are focused on providing a meaningful spark to what will undoubtedly be a long industry-wide transition.

The initial reactions to all of this have been mostly, but not entirely, positive. For example, Keith Boone, a noted expert on CDA (and author of The CDA Book), said, "I was impressed with the JTF report. It was a very thoughtful response to the original work," but he seems to object to a mandate and perhaps even a government program of incentives (although that's not clear).

To say (as the JASON Task Force does) that "There is currently no industry- or government-led plan or effort focused on ubiquitous adoption of standardized Public APIs" is technically correct. But let me ask you, where was the plan to adopt HTTP and HTML and CSS for the World Wide Web? XML and Schema? MIME and SMTP and POP for eMail? If anywhere, it was in the minds of the creators of those standards and the implementers. There was no government program driving adoption.

I can't agree. If we've learned anything in the past 30-40 years, it is that healthcare is a classic "complex adaptive system" (education, where I work, is another one), and it won't change without a strong outside force -- which can only be the government. Arguably, if it hadn't intervened, we'd still be at less than 5% EHR adoption, as we were only six years ago. At the same time, I would urge the ONC/CMS to avoid the temptation to overspecify. Set the framework, provide incentives, and let the increasingly innovative HIT marketplace figure out the rest based on customer input.

Keith is even-handed and fair in his discussion of the role of document standards. He may fear they will be abandoned, but I hope he doesn't want them incorporated into the "baseline" approach. (FHIR and JASON are both based on discrete clinical entities or concepts -- Keith calls this a "data item-centric approach" -- with some surrounding information, but nothing nearly as extensive or at the level of complexity that is found in CDA documents.) His discussion of this is too long to quote in its entirety, but I feel the essence of his argument is that "the fundamental organization of data in an EHR around information documented during an encounter isn't likely to change whether you look at a large grained document-centric approach, or a finer-grained data item-centric approach."

I have no problem with document-based exchange as an optional element of any future nationwide interoperability approach to be used by "consenting" organizations or entities. However, anyone who has worked with them knows how complex CDA documents are (Keith's book is 307 pages long for a reason). There are alternatives within the FHIR framework. For example, I see no reason why "bundles of data items" can't be exchanged using a set of REST APIs. All that is required is that both sides of the transaction understand what this set consists of. Often that's what is really needed.

In contrast, CDA documents end up being a superset of anything anyone might want to exchange in a specific set of use cases -- hence their complexity. To illustrate, a request for data needed to perform a particular clinical decision support rule could request just the set of data items needed to support that rule. A new REST syntax (an FHIR extension) would need to be specified, but this is envisioned by FHIR. Indeed, my Georgia Tech students are already "inventing" them for projects they are doing. Something similar might also be developed for transitions of care. I readily admit that extensions, taken to the extreme, might overly complicate FHIR and need to be carefully managed to avoid that.

So, as John Halamka said in his blog about the JTF report, "2015 will be a pivotal year for real-time query-based data exchange." I hope all involved in any ensuing debate remember that, in the end, a simple, reasonably easy-to-implement, affordable approach to health information sharing is essential. Despite any possible pushback, I'm convinced that Eliot Muir was right when he said, "Complicated standards can be pushed for a while, but ultimately markets reject them." We've tried that approach, and it didn't work. Let's not repeat history.

PS: For those of you still unclear about the API model, I'll explore it next time. I was working on that when the JTF report was released and overtook that priority.

It doesn't matter whether your e-commerce D-Day is Black Friday, tax day, or some random Thursday when a post goes viral. Your websites need to be ready. Get the new Battle-Tested Websites issue of InformationWeek Tech Digest today (free registration required).