It’s generally accepted that the 80/20 design rule applies to FHIR.
This means that FHIR resources as they stand aim to encapsulate 80% of the common elements across healthcare domains. The remaining 20% should be handled by extensions.
This “rule” popped up as early as 2013 and does not seem to have been seriously challenged since. At least not in a public or official way.
I fundamentally disagree with it and see excessive use of custom extensions as a big red flag.
For clarity: I do not consider official extensions or backport extension to be “custom.” Custom means you made them up yourselves.
FHIR has matured a lot since 2013. Resources have expanded and new ones have been added. Elements and ValueSets have changed and been improved. All driven by discussion, feedback and work in the wider FHIR community.
A lot of smart people have done a lot of work to make FHIR a lot better.
The 80/20 rule from 2013 should no longer apply.
Is your team working on a large FHIR project?
Are you creating a lot of custom extensions to store data that does not map to existing elements in existing resources?
If you are, chances are you’re doing something wrong.
Are you creating complicated nested extensions multiple levels deep that emulate small data objects?
If you are, chances are you’re doing something wrong.
Maybe your data model is incorrect and needs to be revisited.
Maybe you’re trying to shoehorn data into FHIR that belongs somewhere else – a postgres database, a config file or system variables.
There are exceptions to every rule. I freely accept that someone will come up with a valid use case for using multiple custom extensions or a host of complicated multi-tiered nested extensions.
But exceptions are not the norm.
Excessive use of custom extensions in FHIR is a red flag.
---