Most FHIR servers are forgiving of non-conforming resources.
Not completely forgiving — anything doesn’t always go. But relatively forgiving, and in inconsistent ways.
The HAPI server allows DateTime values into the Patient.birthDate element — a Date only field.
Azure’s FHIR servers sometimes accept resources in a POST request where the cardinality is incorrect.
I was surprised by how common the non-conformance was.
Without naming each server, I’ve found conformance errors on every server I’ve checked. All of them.
This is without taking profiles into account — basic, out-of-the-box R4 servers.
I was writing code over the weekend to validate each resource coming out of a FHIR server. When I tested it locally everything looked ok.
But once I turned the server connection outwards I started seeing errors everywhere I looked, on every public server I could find.
I even found errors on some private servers that I was responsible for. Mea culpa!
What does this mean if you’re POSTing data to a FHIR server?
It means you can’t always rely on the server to enforce conformance or to prevent you sending invalid or incomplete resources.
Whether you’re the client or the server, you need to take a degree of responsibility for the data you’re sending or receiving.
Garbage in, garbage out. An old expression, but it’s one that’s as valid in the FHIR space as it is in any other.
As for the code that showed me all these non-conformance issues, I’ll be posting more on that next week.
If you’re convinced your FHIR server is fully conformant — and if you’re brave enough — send me details and I’ll be happy to take a look. 🙂
---
Sign up to “The Tuesday FHIR Sessions” and receive an email every Tuesday where I go deep on a single FHIR topic.