Every FHIR server in production performs some validation.
But how much is enough? And is it possible or even desirable to fully validate every incoming bundle or resource?
I talk to people working with FHIR every week. Different projects, different countries, different FHIR servers. The same questions and problems keep coming up.
FHIR validation is one of the most common.
Let’s oversimplify things a little. I see four categories of validation.
- Structure
Basic validation — the resource structure is correct. - Cardinality
Mandatory fields are populated. - CodeableConcepts
Only codes permitted by the terminology bindings are allowed. - Profiles
Resources conform to specified profiles. This includes slices and profile specific terminology bindings.
The first and second are relatively straight forwards. Most (not all) off-the-shelf FHIR servers will validate the structure and cardinality of incoming resources.
Three is more complicated but still achievable if the terminology servers are reachable.
Number four is where the problems turn up. Complicated slicing and custom terminology make things difficult. Put simply, it’s not easy to validate against some Implementation Guides.
Back to my earlier question: Is it possible or even desirable to fully validate every incoming bundle or resource?
In real world scenarios, poor data entry is common. Should you reject an entire bundle of resources because of one unknown value? Or because historic data does not match current expectations?
The FHIR documentation quotes Postel’s Law here:
“An implementation should be conservative in its sending behavior, and liberal in its receiving behavior.”
I’m very interested in hearing thoughts on this. Do you validate against IGs? Do you insist on perfect data or are you forgiving of non-conforming data?
And most importantly, do existing FHIR validation tools work for you or have you had to build your own?
More about FHIR validation: https://www.hl7.org/fhir/validation.html
---
Sign up to “The Weekly FHIR Sessions” and receive an email every Thursday where I go deep on a single FHIR topic.