#FHIR, and recursive standards development

May 5, 2014

So Sean Nolan from Microsoft blogged about how he wasn’t that excited about FHIR:

Yesterday evening my family and I went to see the new Spiderman movie (my wife has somewhat of a crush on Andrew Garfield). It was pretty good, although I still do not get why magnetizing the web shooters protected them against Electro. Whatever.

What really caught my eye was the trailer for Edge of Tomorrow, an upcoming show where Tom Cruise has to re-live the same day of battle over and over again (kind of like Groundhog Day but with aliens and Emily Blunt). The tagline is LIVE-DIE-REPEAT, and suddenly sitting there I realized — this captures exactly why I’m so lukewarm about FHIR! (Seriously, that happened.)

This made me laugh - if we’ve got to the point where Sean can’t go to the movies without thinking about FHIR, then we’re doing something right!

So Sean explains what he means:

  1. The community defines a standard that is the state of the art for its time (HL7v2, IHE, Direct+CCDA, FHIR, etc.). People are excited!
  2. But adoption at scale is hard — and it’s mostly not because of technology. Sure, we have to get through vendor upgrade cycles and we run into unexpected code issues, but that’s easy. What’s really hard is fitting use of the standard into daily workflows, solving privacy and trust challenges, navigating politics, and most importantly demonstrating economic value.
  3. Folks start slogging through the hard work. But it’s a long road, and takes time and persistence. People get disillusioned. Technical people get bored.
  4. Sadly, the standards folks don’t have tools to deal with most of this. But they want to do something to make things better … so they look at that last standard/technology and see where it could be better. Go directly to step #1. FOREVER.

So there’s that problem, and there’s this, from XKCD:

Choosing to create a new standard isn’t something that standards folks do lightly. It certainly wasn’t something that we did in the case of FHIR without a lot of consideration - and without first committing to many years of trying to make the existing standards work. Also, choosing to make a new standard has very obvious disadvantages with regard to change and impact on the market.  I think that Sean has under-estimated the degree to which standards folks (most of them, anyway) live in the implementation world, and standards is a secondary activity for us. Even those of us who are ‘standards consultants’ - which I guess includes me - we have to make valuable contributions in the implementation space, or we won’t get work.

But a couple of Sean’s points are important:

  • Adoption at scale is hard. The standards are only a small part of the story
  • We do need to do something to make that better

I was intrigued then, when Sean listed his specific issues list:

What’s the service URL for each provider? How do you register each app with each provider’s OAuth endpoint? Are there policy requirements before somebody allows your app “in”? Anybody hear about something called Covert Redirection? What about push events; are we all going to be polling each other for new data all the time?

These are real problems, that’s for sure. But most of the answers I can think of to these involve… standards. Of some kind.

The real question for me is to what degree standards contribute to overall project outcomes. They’re only a small input to the project, and there’s such a lot more - the project culture, economics, the inherent alignment… it’s hard to think that the standard makes that much difference. But I do see that the standards are a really early input that influence everything that happens downstream; if the standard isn’t clear and simple, then analysis and implementation is even more confusing that it needs to be. Though I’m not aware of any research into measuring that quantitatively.

Sean says:

I don’t have an answer. And you know, if FHIR gains traction you can count on HealthVault to implement it

Well, I don’t really have a good answer for this either - but we only started working on FHIR when we were convinced that the other specifications were getting in the way of solving the problems we all face. And I’m really glad to hear that we can count on Healthvault to implement FHIR, because I regularly get asked about that.

As for getting Sean excited, if the things we’ve done to build an implementation focused community around FHIR are indeed worth what I think they are, then I reckon that he’ll get excited eventually. Sean, why don’t you come to the next connectathon?