The FHIR Code

A guest post from one of the FHIR Chief's: Lloyd McKensie

---

A little over three years ago, when Grahame introduced the concept thFHIR(TM) standard, he didn’t just have set of technical ideas for how to better share healthcare information. He also had some fairly strong ideas about what we needed to hold as “important” as we pursued that new approach. The technical approach has evolved, in some places quite a lot. However, the underlying priorities have remained pretty consistent.

at would become

Principles are actually important core to FHIR – or any standards effort. They drive what gets produced. They also guide the community. If the principles aren’t well understood or clearly expressed, it’s easy for a standard to drift and lose focus. It’s also easy for it to deliver the wrong thing. V3 had a really strong focus on “semantic” interoperability. We made great strides in that space. However, we sort of lost track of the fact we still needed technical interoperability underneath that. (And that ease of use was sort of relevant too . . .)

Some of those principles such as “the 80%” have been widely shared (though not always well understood) . Others have found their way into presentations in slides such as the FHIR Manifesto. However, we’d never really sat down as a project and written down exactly what the fundamental principles of FHIR were or why we felt those principles were central to what FHIR was.

So the FHIR Governance Board (with review from the FHIR Management Group) has written down what we see as the “core principles” of FHIR – the FHIR Code, if you will. These are the underlying drivers that we feel should guide every design decision, every methodology rule, every step we take in deciding on scope, ballot timelines, etc. They can be found on the HL7 wiki.

I don’t think any of these principles will be a surprise to those who have been following the FHIR project. They pretty much all stem from the first principle:

FHIR prioritizes implementation 

Note that these aren’t hard and fast rules, but guidelines. You can’t say “I’m an implementer, I don’t like what you’re doing – therefore you’re violating FHIR core principles”. But they do reflect the spirit of what we’re trying to do and we’ll try to adhere to them as much as we can. (As well, we interpret “implementer in the broad sense – we don’t only care about those who write code but about all those who use FHIR.)

The FHIR code isn’t done though, because FHIR isn’t a top-down process. It’s about community (Grahame’s been re-enforcing that a lot this week.) And as I write this, I realize we may have missed a principle that should be added to the list. In any case, we want the principles to be reflective of the desires of the community – so we’re throwing them out to implementers and the broader FHIR community:

Do these principles reflect your vision for FHIR? Is this what should be guiding our decisions? Will this help us to keep our focus on the right things? Are they clear enough?

We’ll take your feedback (here, on the FHIR list, implementer’s Skype chat or any other means you choose). Then we’ll seek feedback as part of the next FHIR DSTU.