Let me start by stating the obvious: I’ve had a bit of a rocky relationship when it comes to the creation of FHIR.
Having said that, it’s interesting to see how FHIR is evolving and to witness the continuing attention the standard is receiving.
My original perspective on the standard was probably a little skewed. I have a deep belief in RESTful integration as the way of the future, and I’m also not really known as someone who has the patience for things like the process involved with drafting a standard. It’s hard not to look it at from the perspective of technology entrepreneurship and see the risk of missing the market. I like my solutions the same way I like my coffee — instant. (Actually,I prefer a nice latte).
Let’s face it, my skill-set is one that personally makes me a terrible standards collaborator. That’s why I’m glad there are people like Grahame, Lloyd and Ewout, who can see these things through to completion. I may have some valuable ideas on where things need to go, but I’m just not cut out to sit through the standards process.
What I am good at however, is being a champion of things that ‘just work’. When there’s a technology or a standard that brings value to the market and that facilitates even more access to data, well, I’m on board. To that point, I think it’s becoming more clear just how and where FHIR can have this kind of a positive impact and so I’m ready to start talking once again.
First, a little background:
As I said: I love RESTful interfaces. I saw the trend back in 2009 and we put our R&D into the Iguana Translator, which we brought to market in 2011. The Translator has supported web services and RESTful interfaces natively just as simply as the well worn part of HL7 ADT integration. In fact, it’s been easy to implement FHIR as far back as when the Translator first came out.
We are now into our 4th year of having our clients prove that RESTful integration is a safe and effective way to implement robust, secure interfaces for integrating hospitals, clinics and labs with their regional exchanges and public health authorities. RESTful web services are inexpensive, easy to implement and they reduce the amount of patient data that needs to travel over external connections. This has brought great benefits to our user base over this time.
Where we are today:
A real shift in the market has occurred: more and more EMR integration is happening with web services. Funnily enough, part of shift in thought was driven by an (in)famous blog post I wrote in 2011 – “The rise and fall of HL7”. That post had a lot of impact. From what I’ve been told, my post woke up a lot of people in the HL7 community to the fact that web services based on JSON were a more powerful and less costly way to integrate health care systems than the traditional HL7 protocol.
It was great to see this idea align with Graeme Grieve, who started investigating how RESTful APIs work; which led him to began the FHIR project.
Funny fact – did you know that Graeme Grieve and I both were students of the same high school, Wellington College in New Zealand? It’s a bizarre little co-incidence in the theatre of health informatics.
That brings us to where we are today. While I’m not going to pretend that I can or will jump in as a hands-on contributor to the finer points of the FHIR standard – though I do have some talented team members who may want a seat at the table – I thought I’d take a few moments to once again offer my opinion on the future and where I think the biggest impact can be made.
The opportunity:
Where I see FHIR having the greatest opportunity is in contributing to what one could broadly call “patient engagement data gaps”. This is the whole area of mobile devices – watches, home care devices and so on. FHIR definitely needs a beach head in the market to succeed and this could be it.
FHIR is competing for influence with native APIs that come from the larger players in this market like Fitbit, Apple and Google. FHIR has a chance in this market because it’s still new and evolving. The potential is for FHIR to act as a reference implementation to enable smaller companies, who are new entrants into this growing market, to compete with some of the larger companies in this area.
It’s easy to see a world where newer medical devices, rather than relying on antiquated RS232 feeds running ASTM and other proprietary interfaces, could instead be using lightweight RESTful interfaces that call back into internal web servers within a clinical environment. FHIR has a chance to establish its place and take hold here.
Love them or hate them, every standard that survives has to find its place. The value of each standard is fundamentally driven by the business value of the data that it carries. In healthcare, X12 handles financial data, HL7 handles clinical data and SOAP is used often for health information exchanges (HIE) and immunization registries. Once a standard is entrenched in an area, it’s very difficult to dislodge it; and there’s hardly any economic benefit in doing so.
FHIR simply won’t be able to displace those standards in their established markets. The market for EMR integration has already gone – vendors like Epic, Cerner and Athena health have already had their native RESTful APIs in the market for many years now. Since most of these APIs give random access to 100% of the real data models of those applications, they will predominate over any other layers of web service standards like FHIR that might be added to those EMRs.
That’s why I really think FHIR’s best shot at entrenching itself today is by focussing on a winnable, evolving space like patient engagement. There’s no question that FHIR brings value to the table, so it’s time to find it’s natural home and start helping organizations realize that value.
Whatever happens, I think it’s time that I finally come clean as a pro-standards guy. I may not be the guy to create them, but I’m definitely one who recognizes that the more standards there are, the more available data there is. The more data we all have access to, the more economic opportunity there is to bring that data together to create value and solve new problems.
That’s where my passion and the passions of the team here at iNTERFACEWARE really align: Finding the solutions that lie within the data, regardless of how it is formed and where it lives.
