So I arrived on Saturday and got checked in and joined the tail end of the FHIR Connectathon.
It was good to meet Ewout Kramer in person, Grahame Grieve, Lloyd McKenzie again and Dave Shaver popped in for a bit (and there was also some guy from the UK who left before I got his name!). It was nice to be able to go to a conference which from my perspective is pretty quiet and not like the ‘speed dating’ like HIMSS. Shock – there is actually some time to think!
I tried writing a bit of connection code in Iguana and pulled off some example patient demographics off Grahame’s FHIR server in XML and then tried out the JSON mode – all good – little bit of bother with some UTF8 characters – groan – either the issue here is between the keyboard and the chair or there are a couple of genuine issues to be resolved here – it’s probably something cosmetic – ah well – good to be involved.
The discussion was interesting. I know I pushed hard for HL7 to adopt a standards process which involves implementing the standards being described. I still very much think as painful as it is to implement these standards, it’s a darn good litmus test of the quality and practical value of these standards – if you are going to fail, it’s better to fail fast.
In this venue and at this time though I think it’s better to step back a little and look at the bigger picture without getting to lost in the weeds of the current implementation of FHIR.
So what should/could FHIR be? First of all it’s good to be very honest about what RESTful interfaces are good for and what they aren’t good for.
RESTful interfaces do not match SQL databases or ‘No SQL’ databases either when it comes to the ability to do adhoc querying. Trying to get them to do so will be an exercise in futility – whenever you begin this exercise in trying to make a really flexible querying interface it never ends well. You alway end up creating an adhoc crappy SQL wannabe interface. It reminds me of the evolution of XSLT – it was just a bad idea to try to build a scripting language from a beginning of XML. If you want a scripting language go use a real one that was designed to be a language in the first place.
If you are CIO of a hospital trying to do reporting about trends in your business, or you are the CDC trying to look for trends in infection data then your best option continues to be to use tools like SQL databases or it you feel adventurous the new ‘No SQL’ databases like Mongo DB. This gives you the most flexibility when it comes to doing large scale data-crunching to see the patterns in the tea leaves and find out whatever trends you care about. That means either directly accessing the databases of your applications or mirroring the data in your own databases. RESTful interfaces will just provide another more flexible means of getting that data in the first place.
So what advantage does a RESTful interface have over just a straight database? One obvious advantage is that if the application the RESTful interface exposes does not belong to you then it’s a good way to get data that you would otherwise have no other means of getting at. In the CRM world with on demand products like Highrise and Saleforce.com that’s the only way to get data out. And from what I hear that is one of the practical issues – it can be tricky to do the reporting that enterprises used to do off the more traditional applications where they could get to the database.
Where RESTful APIs really excel though is in terms of providing a clean easy way to get data into a system. Having access to a vendor database to put data into the application is relatively risky – especially when systems get upgraded. Having a well defined, documented, unit tested (hopefully!) APIs to put data into a system which cover data in a granular manner is a strength of what can be achieved with REST.
It’s also possible to define interfaces with REST that can be used to drive a traditional HL7 2.X HL7 interface in a more flexible maintainable manner than doing the usual business with staging tables, triggers etc.
The big elephant in the room of course is to what extent is it possible to create a generic specification for a set of RESTful APIs which can be used across the global healthcare industry. This is what FHIR is attempting to be.
The pessimist in me says no – it’s a hopeless cause. The needs of interfacing are too diverse – if they were not so diverse then someone like Microsoft or Oracle would have made the one application that solves it all and the rest of us would be looking for employment. Clearly we are a long way from that happening (at least until I am retired … please!!).
If it simply is not possible to create a generic interface that can solve everything, then this scenario isn’t all bad. HL7 the organization (see the holy trinity of HL7) could see it’s role changing to simply being a place where people get together in healthcare inter-operability to discuss different specific interests. It would be a trend in de-centralization of standards concerns into specific applications like say immunization registries. In this scenario FHIR would be is to be the ‘midwife’ of change that educates and brings about fresh thinking in how we think about integration in healthcare. Culture can change to where organizations and applications do publish APIs to their data which are open, easy to understand and comprehensive.
It would actually be a really positive outcome.
But maybe more is possible.
The optimist in me says we just need to work a little bit harder to find that simple abstraction where FHIR could actually be something more than just a transitory change agent. The core of the idea is building on something along the lines of what I was exploring a few years ago. I am not totally sure if it could work but my plan on Sunday morning (about 5 hours from now) is to white board out the concept with the FHIR team and see where the ideas go.
I think these are important issues that affect us all. I rather like the proverb that Charles Jaffe the CEO of HL7 used in his May brief:
If you want to go fast, go alone.
If you want to go far, go together.
Progress requires a bit of both – individuals give ideas and critical commentary but ultimately for ideas to matter lots of people have to get behind them. Anyway if you reading this – don’t be silent – comment here on my blog or if you are at the Atlanta WGM come and chat to me in person. Let’s see together where this goes.