FHIR Validation Is Not Data Governance

Almost no one explicitly says that FHIR validation IS data governance.

But many FHIR implementations behave as if it is, relying exclusively on profile validation to ensure data quality.

This is dangerous and creates real risk.

Here’s a concrete example:

An app can send a US Core compliant Patient resource to your FHIR API while embedding a second patient’s sensitive data in extensions, in the text narrative, or as additional identifiers.

Each scenario passes FHIR validation. Each scenario is dangerously wrong.

FHIR validation checks structure and sometimes content. It does not check meaning. It confirms your JSON is valid, not that your data makes sense.

Two questions for you:

  1. Can external applications POST directly to your FHIR server?
  2. Do you maintain a “governance” layer between your public FHIR endpoints and your FHIR server?

If you answered “yes” to the first and “no” to the second, you don’t have meaningful data governance.

Data quality needs an owner. The buck has to stop somewhere. If it’s your FHIR server, it should stop with you.

I’ve seen enough “FHIR Native” implementations to know that this isn’t hypothetical. There are systems in production today behaving just like this.

FHIR gives you the ability to accept anything.

Data governance requires that you don’t.

---

Download my “FHIR Architecture Decisions” book

Discover more from Darren Devitt

Subscribe now to keep reading and get access to the full archive.

Continue reading