Anyone familiar with HL7 has undoubtedly heard about the emerging HL7 FHIR standard, introduced by Grahame Grieve, principal at Health Intersections in Melbourne, Australia, and an active participant in the HL7 International organization. To illustrate its popularity, just last week at the SIIM (Society for Imaging Informatics in Medicine) 2013 Annual Meeting, I saw three presentations in one day alone that referenced FHIR as an emerging standard that has tremendous potential to advance healthcare interoperability.
(For background info on FHIR, also see: 5 Things to Know About HL7 FHIR and The Interoperability Paradigms of HL7 FHIR)
I had the pleasure of sitting in on an HL7 FHIR seminar Grahame conducted last month in the Dallas area, and, with collaboration with some of my more knowledgeable coworkers, came up with the following 5 questions to ask him about FHIR. Special thanks to Grahame Grieve for answering the questions and for his passion in creating this exciting standard.
1. Can you explain your decision to create HL7 FHIR using modern protocols? How would you compare this decision to the history of HL7 Version 2 and 3?
FHIR was born out of frustration with the overall direction of HL7 (i.e. v2, v3, and CDA). V2 has been great, but has come to the end of the road. V3 has tremendous strengths but in the end it failed — too much too soon, I think. CDA fixes only some of v3′s problems, but is a document, not a data interchange specification.
FHIR was kind of an accident. HL7 created a fresh look task force and I wondered what it would look like if I took a modern internet approach and rewrote it for health (I actually picked the Highrise API). I drafted something, and it took off like, well, wildfire. And here we are.
2. As opposed to the historical approach of HL7, FHIR is free and open – both really free (as in speech) and free as in beer. How did that process unfold? Do you feel like FHIR’s entry into the HL7 community was part of the reason for the IP change at HL7? What are the benefits and the unique challenges of creating a free healthcare standard?
It was clear that the existing HL7 community wasn’t going to sink money into yet another approach until it was well proven. They’d be nuts to do anything else. So we needed to get runs on the board outside HL7. And that meant that the specification had to be truly free for use for non-HL7 members—otherwise, how would that happen?
The board graciously agreed to this – for which I thank them. I think that FHIR was small part of the reason for the IP change at HL7—kind of the straw that broke the camel’s back; there was already a lot of discussion about the change prior to FHIR entering the picture.
I think that the IP change will have longer deeper ramifications for HL7 than most of the participants realize. There’s a series of rights/patents issues that become more evident once HL7 IP is publicly available, and there’s definitely going to be a change in the cost/benefits of participating in the specification development – I think it will be harder to justify it.
It’s a problem with standards – the whole point is that expenditure of a small amount of money somewhere saves money *somewhere else* (if it saves money right where it’s spent, it just happens organically, and we don’t call it a standard). So it follows that the cost of the standard has to be extracted from somewhere—where will that be? And/or how can we drive the cost down?
3. I’ve heard you say that HL7 FHIR will open up HL7 adoption to mobile developers. Why do you believe this will happen in comparison to any other standard? And, why did it take so long for HL7 to reach out to mobile developers?
FHIR is good for mobile developers for two reasons – it’s technically suited – http, json, oauth, all that stuff. But more important, it’s a web-centric framework that is also suited to the needs of existing healthcare systems, so the data silos can be unlocked more cheaply.
At HIMSS this year it seemed to me that it was the year of the PHR. But until the PHR interfaces are a commodity (they aren’t now), I don’t see how the PHR eco-system can be viable. FHIR is the only candidate standard I know of for commoditizing the PHR space.
4. What are the primary challenges to the development of the FHIR standard? How about the challenges adopting the standard?
Well, any standard has to go through the consensus process – that’s where the value comes from. But that process is time consuming and ugly, and it has a habit of creating needless complexity. We’ve done a number of different things to manage that, and they are working relatively well (especially the connectathons).
As for adopting the specification, I think that there’s going to be a lot of political/positioning issues, but putting them aside, I think that we will be focusing on finding areas of complexity where we either need to simplify or document better.
5. Gaze into your Magic 8-Ball and answer this question: Two years after HL7 publishes FHIR’s Draft Standard for Trial Use (DSTU), the ONC will designate HL7 FHIR as one of the primary standards to use in health data exchange.
Well, ONC have been watching our progress very closely, and we regularly welcome ONC folks to our meetings. Conceptually, FHIR is very much to their liking. However, FHIR is still well over the horizon so it’s not yet a direct interest for them. When FHIR is ready, they’ll certainly be looking at it, and then it’ll have to complete on merit with other candidates. If we’ve done FHIR right, there’ll be no competition, but there’s a lot of work to be done before we get to that point.
