#FHIR and confusion about the 80/20 rule

Feb 28, 2014

One of the most common misconceptions out there about the FHIR is about the 80/20 rule we use when debating whether fields should be included in resources. This is how I often hear it formulated:

FHIR only includes 80% of the elements that are used

But this is not correct - it’s not how the rule is formulated. This implies that the intent is to limit functionality, to ensure that it won’t actually work properly. That we prefer simplicity over actually solving the problem properly (e.g. we are externalising the complexity).

That’s not the intent at all. The intent absolutely is that FHIR supports 100% of the functionality that people use.

The 80/20 rule is about something different: it’s about keeping edge-cases and disagreement out of the specification. It’s about making the complexity live where it belongs.

Properly formulated, the 80/20 rule is that

FHIR only includes an element if 80% of systems implement it

Some initial comments about this rule:

  • It’s actually only a guideline. There are other considerations around safety and consistency that are also considered
  • It’s not a statistical thing, it’s a rule of thumb.
  • It is deliberately based oncurrent implementationsin order to avoid the problem of wishful thinking or futuristic designs that don’t relate to what really happens

There’s an aspect to this rule that most people don’t consider: if a domain is well-agreed, then what 80% of systems implement is 100% of the domain. That’s how we prefer things, really. And consider, what would a 100% rule say?

  • We only add a field to the specification if it’s implemented in 100% of systems
  • We add 100% of fields that are used in some system somewhere

I’m pretty sure that no specifications written this way would be useful in real life. So there has to be rules along these lines, but I’ve never heard them formally elucidated.

We made the rule explicit in FHIR in order to make it easy (well, possible) for committees to say “no” to requests for additions to the resources that are not mainstream features (committees get these all the time, often from large vendors or national projects). We don’t want edge cases - things that only one particular country does, or one particular project did - added  to the specification.

Nor do we want things that people disagree about added to the specification. In the past, I have argued that FHIR is not the right place to float trial balloons around which to create such agreement, but that has proven impractical - there’s real enthusiasm to add new domains to FHIR, where there’s still change to how the domain is understood (e.g. genetics), and a DSTU is exactly the place to try things out. But we need to be careful: the FHIR rules for inter-version compatibility are very restrictive (they need to be, for a repository standard), so it’s important to keep experimentation well away from normative status in the FHIR specification.