I was on a call with a pathology data startup last year. They were early stage in their decision making, asking questions about how to match and merge patient resources, how reliable MRNs were and how update requests worked in FHIR.
They were new to healthcare data and to FHIR. There was a lot they didn’t know.
Later in the call I learned that they had already made key architectural decisions. They were using an Azure FHIR server in the cloud, and they had settled on a FHIR-native approach without realizing they’d done so.
I see this a lot.
New teams, new projects, no previous experience building enterprise FHIR systems, jumping straight to FHIR-native.
A FHIR-native system treats the FHIR server as the system of record for all or most of the data it contains. In its simplest form there is no legacy system to draw on or sync data from. The FHIR server becomes that system.
It’s attractive because it delivers a comprehensive data model out of the box and appears to solve interoperability for free. (it doesn’t)
It’s also attractive because it generally favors a greenfield approach, something developers love. A blank slate where they get to code everything from scratch without any limitations caused by legacy systems.
The problem is not FHIR-native itself, which is a viable architectural model. It’s when FHIR-native is chosen without undertstanding those limitations and without understanding what else needs to be built around the server.
I address this in detail in my free eBook FHIR Architecture Decisions. Chapter 6 looks at the pros and cons of FHIR-native, giving examples of where it makes sense. And Appendix I provides a snapshot of some of the extra components that need to be built alongside the FHIR server.
Many of these extras are large projects in themselves that require a lot of work and expense to implement. Not to mention expertise.
A few examples:
- Master data management and “golden records”
- MPI and EMPI
- Access control beyond Smart-on-FHIR (consent, RBAC, element level)
- Data governance
- A terminology service
None of these are the responsibility of the FHIR server.
The server’s role is simple: it receives a request, validates that request as best it can, and returns a response. That’s it. That’s all the FHIR server is responsible for.
Back to the pathology data startup I mentioned earlier.
They assumed the FHIR server was a complete platform, that it could function as a data store for patient and clinical data straight away, without them having to build or buy extra components.
At the end of our call they had started to realize that they might have bitten off a lot more than they could chew. They decided to go back to the requirements gathering stage and work out what they really needed to build and what their system would truly be responsible for.
If any of this sounds familiar, FHIR Architecture Decisions is free to download.
---