I believe that Fast Healthcare Interoperability Resources (FHIR), promoted by appropriate and strong government action, can provide the basis for making interoperability a practical and affordable reality. This opinion will come as no surprise to anyone who has been following my posts.
Recently, I discussed how the long-simmering debate about how to achieve interoperability was significantly intensified in April with the release of JASON's report "A Robust Health Data Infrastructure." In parallel with the report's release, Office of the National Coordinator (ONC) for Health IT director Karen DeSalvo said, "This report is consistent with our intent to support nationwide interoperability." She promised swift action when she said that the ONC and the Centers for Medicare and Medicaid Services (CMS) "have already begun to work on many of the recommendations cited in the report."
Clearly, DeSalvo meant what she said. Only five months later, on Oct. 15, the 18-member JASON Task Force (JTF) she convened issued its final report and said that it
… strongly agrees with JASON's call for an orchestrated interoperability architecture based on open APIs as the foundational approach for nationwide health information exchange. The JTF also agrees with JASON's observation that current interoperability approaches -- based on complex, health-care unique, document-oriented standards, and business frameworks -- are functionally limited and need to be supplemented and perhaps eventually replaced with more powerful, API-based models. The JTF thus also agrees with JASON's recommendation that MU Stage 3 be used as a pivot point to begin the transition to an API-based interoperability paradigm.
Before proceeding, let's step back and consider just how remarkable and significant all of this is. Before the Direct email-based exchange was introduced a few years ago, healthcare operated almost entirely in its own proprietary standards environment. In retrospect, Direct was the first step in moving to the same web standards and technologies used by virtually all other industries.
Now, here we are with a serious proposal for a ubiquitous, public, open approach to health information exchange based entirely on web standards for transport and leveraging the massive investments made by industries that are far ahead of us on data exchange. The API model essentially means that health information can be requested and retrieved using the same technologies you already use to find the right gift for someone's birthday on a retail website. Healthcare didn't have to invent it, and we can use web resources virtually for free, because we're sharing them with everyone else.
None of this should be interpreted as ignoring the very real, very healthcare-specific requirements for assuring privacy, security, and trust when protected data is exchanged. Nor can it ignore other health industry-specific challenges such as accurately identifying patients across (and possibly even within) provider organizations. JASON and the JTF clearly recognized both of these and other challenges and proposed approaches to them.
The JTF then goes on to list what it sees as JASON limitations, including:
Progress has been made, as I discussed in a prior post. However, it would be wrong to suggest that we don't still have a very long way to go. Moreover, I doubt we'll get there anytime soon without a better strategy, and I am thrilled to see it coming into focus.
Of great importance, in addition to agreeing with JASON's recommendation that "Meaningful Use Stage 3 include certification and incentives for inclusion of a Public API in Certified EHR Technology (CEHRT)," the JTF formally recommended FHIR as the technology (interestingly, something JASON did not do). Since it is a draft standard, it called for "ONC [to] mobilize an accelerated standards development process to ready an initial specification of FHIR for certification to support MU Stage 3".
The JTF apparently (and, I think, appropriately) views this as minimum set of requirements and not a ceiling. "We do not anticipate that this specification would preclude the use of other existing standards to meet MU requirements."
I hope the ONC and the CMS don't end up bowing to pressure and viewing FHIR-based public APIs as optional -- a concern raised by the JTF:
The simple goal is to make such a FHIR specification available to vendors and providers along with other existing functional specifications so as to offer a viable opening to those who would invest in new standards, while at the same time not penalizing those who are already investing in capabilities based on existing standards.
The JTF also recognized that vendors and their healthcare organization clients must be brought to the interoperability table. Appropriately, the JTF members included representatives from more
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).Mark Braunstein is a professor in the College of Computing at Georgia Institute of Technology, where he teaches a graduate seminar and the first MOOC devoted to health informatics. He is the author of Contemporary Health Informatics (AHIMA Press, 2014) as well as Health ... View Full Bio