Question: When should you adopt FHIR?

Nov 5, 2013

Question: 

Need your opinion on this matter of encouraging people to adopt FHIR for national programs/ national standards for healthcare exchange.What will be your counter arguments if some cowboys say

  1. FHIR is still new, we will wait and see till it matures.
  2. Standard Development is cumbersome process, and it takes extremely long time for them to incorporate new requirements. It is much faster to cook our own unique xml to suit our requirements. You talked about XML cowboys on your website in the past - hopefully you can provide much stronger fire power after two years spent developing FHIR.

Answer:

Well, FHIR is still new, and it will change. The “DSTU” that is coming out soon will be a Draft Standard undergoing Trial use, and users should expect breaking change after trail use. Right now, users that are risk adverse should consider long and hard before using FHIR. Implementing bleeding edge standards is a process that involves the shedding of a great deal of blood - and early adopters of FHIR will be have additional costs due to change in FHIR that people who wait the process out won’t.

Except… the risks of the alternative standards are also well known. I’m constantly surprised at the level of interest that risk-adverse implementers have in FHIR, but they uniformly cite the known problems around cost and complexity in other approaches to me. They think that even given the risk of future change in the FHIR specification, it’s still their least risk option. People say, “better the devil you know” - but it seems that if people think the devil is that bad, they’ll try out new devils to see if they’re better.

Of course, you could also consider not using a standard at all. After all, standards development is a slow, cumbersome process. From conception to the first draft version will have taken FHIR 2.5 years - and for a standard, that’s warp speed. The full normative version of FHIR certainly won’t come quickly. Given this, and the fact that the standards process is not only slow, it often doesn’t give you the outcome that you wanted (Ask for something simple, get something complex back), the impulse to just define your own thing can be overwhelming. It’s tempting just to roll your own format, and go with that. And sometimes, I actually think it’s the best approach - I’ve certainly done it at times in the past.

But the whole process of standards development, the fact that it’s slow and cumbersome - that’s actually it’s value. The point of a standard is that it’s stable, that you can develop to it, and plan for it, and that it’s developed in an open and transparent manner that ensures that a wide base of requirements have been taken into account. Because standards development is cheap compared to the real costly thing: product development. Vendors don’t like to develop product based on unstable interface formats. (Actually, it’s not vendors, it’s their customers, who don’t like paying more than they have to. Vendors just do whatever people will pay for).

So the real problem with XML cowboys is not that they develop their own formats, but that often, they’re externalizing the costs. A national program that develops it’s own formats, thinking it’s saving money…. no, they’re not. The project team might be (probably are) saving their own project money, but they’re certainly going to cost their nation a bucket load of $$$ in the long run. I’m written about the problems of national programs before - there’s lots of drivers to get them to adopt their own formats, and it’s not that’s a bad idea; it’s just the risk of externalizing cost, and by so doing, running up the total cost greatly. Also, there’s the risk that they won’t know what they’re doing, and that they’ll make bad decisions in haste which they rue later - we get enough of that at the standards level, with a wide input. How much easier to do it in a small team with deadlines looming.

Fundamentally, this is a governance question. The sponsors of those programs need to ask themselves hard questions about where they want their money to be spent, what outcomes they want. But politicians aren’t good at asking those questions. Governance is just hard.

When FHIR is stable, there’s every reason to think that leveraging it in general national standards will save money. For now, if national level programs really want to adopt FHIR, they need to contain the risks of future change to specific projects where it’s OK for them to left in a bywater called the DSTU version, or where they have some other strategy to ameliorate the risks.

p.s. If you thought XML cowboys were bad - you ain’t seen nothing. JSON Cowboys.. they’re leagues ahead!