FHIR profiles as a stand-in for data governance is becoming a pattern.
Here’s how it happens:
An organization maps out a new application with FHIR sitting at the center. They’re ambitious and forward-thinking – or so they think.
FHIR-native is chosen because of its strong data model. An Implementation Guide is planned, complete with a set of profiles that can be validated against. MDM and EMPI have big boxes on the architectural diagram, but implementation is pushed out.
The same for “data governance”. Its importance is stressed. Teams are planned but not assigned. It too can wait for later.
Test data begins to flow and the apps built against the FHIR server are all working. Happy path scenarios deliver. Client demos are positive and live presentations at industry events are well received.
Everything looks polished, which makes the business think it IS polished.
Pressure starts building and the technical implementation teams are pushed to cut corners. No one quite says “cut corners” – they never do in big organizations – but that’s what they mean.
Someone floats the idea that FHIR profiles already deliver “a kind of data governance”. After all, it’s validation of a sort, right?
MDM and EMPI get pushed further and further out – no longer as important as the V1 release date that everyone is pushing for.
The first client site is provisioned. Live patient data begins to flow. Business leadership is happy, but technical leadership is crossing their fingers and hoping they can get proper data governance in place before anyone notices it’s not there.
FHIR profiles are carrying a lot of weight – weight they were not designed to carry.
Profiles validate structure, cardinality, terminology bindings and data types. They do not identify duplicate patients, validate the correctness of data, or prevent conflicting updates to resources.
Valid FHIR can still be bad data.
Eventually, what was bound to happen happens.
Data quality deteriorates as no one is responsible for it. Duplicate patients start stacking up because there is no EMPI in place to prevent it. Application updates to patient records conflict with each other, as MDM processes do not exist.
FHIR profiles could not prevent any of this. It was never their job.
---
Download my “FHIR Architecture Decisions” book
FHIR Weekly
Join 1,100+ business and technical leaders.