HIMSS15 was supposed to be an opportunity for HIT vendors to really expand on interoperability with possibilities represented by FHIR and other newish standards. At least that’s what I thought.
Interoperability is an overarching concern across HIT and many are expecting big things from FHIR. Only Epic proclaimed its faith flashily with a stylized HL 7 FHIR logo inside an actual fireplace. But the company gave some people who asked about data integration the bum’s rush while also announcing that they would not be charging — at least for a few years — for data transfers between Epic customers and non-Epic customers with Care Elsewhere. Very confusing. Otherwise, the hyping of FHIR at a poster or display level was way more understated than I expected. Inside meeting rooms on the other hand, FHIR came up in every conversation I had.
These conversations fell into two patterns. The first, and most numerous, followed a familiar script: we are closely monitoring this new technology, recognize its enormous potential, and will evaluate how and when to build solutions based on what makes sense for our customers.
The second set of conversations sounded decidedly less cautious. These vendors expressed strong optimism about the benefits of FHIR as a standard but were essentially vague about product plans. While the interoperability issues facing healthcare are far broader than FHIR, I was still expecting a little more substance than was on display in Chicago, especially concerning all the hype we’ve been hearing about interoperability in recent months.
For those who crave substance, a well-attended session by David McCallie of Cerner and Sam Huff of Intermountain set the tone and made the conference for me. This presentation described one potential way to a more interoperable future. These two interoperability stalwarts position the EHR as the system of record and pluggable lightweight applications as the system of engagement for healthcare. Connecting them and providing the data fuel will be a set of FHIR-based APIs. The youngish crowd in the big hall asked a lot of questions and seemed genuinely ready to seize on this approach as a way to penetrate the walled gardens of our EHR-mediated HIT landscape.
I was pretty focused on FHIR this year because it will be an important element in solving the broader interoperability problem. And on that front – the Friday before HIMSS15, ONC issued a report to Congress on information blocking in healthcare.
Not too surprising due to timing, at HIMSS, no one that I talked to had read it and most seemed unaware of it.
The gist of this report is that information blocking is most definitely a problem. ONC’s most significant findings were that the scope of the problem is not well understood, the causes are a bit more murky than the simple competitive concerns of EHR vendors and large providers. The key takeaway is that business practices, rather than technology, may be the primary cause that information blocking occurs and by inference, the lack of interoperability.
Since HIMSS15, I have had several conversations with both vendors and providers who mention this report, usually in passing, as a way to illustrate how far we have to go in healthcare to making patient data as portable as it needs to be to deliver truly coordinated care. Next year, I am hoping that vendors will be talking in more concrete terms about the ways that they have implemented FHIR-based data access for HCOs.
What I really want to know is the underlying data for FHIR consistent from one implementation to the next? We might have interoperability at the message layer, but is what gets populated into the message mapped the same from implementation to implementation. Nobody seems to talk about this type of potential inconsistency.
That is the million dollar question. HL7 V2 is not consistent vendor-to-vendor, department-to-department, HCO-to-HCO. It can also be partially consistent. It seems like HCOs that exchange CDAs and HL7 messages routinely eventually get it right. FHIR’s most loyal devotees believe that the standard’s support for “constrained extensions” will ensure the kind of consistency you point out as sorely lacking.
FHIR seems to work in the small, but how do I scale to a region, state or even a national level. As FHIR takes hold and thousands to hundreds of thousands of FHIR points of presence (URLs)appear, how do I locate them? Do I broadcast to every endpoint looking for a patient? How do I know which endpoint is associated with which facilities or providers?
As we continue to work on the FHIR speciications and local implementations, we need to start working on how to scale beyond a few known FHIR endpoints.