You didn’t build RBAC, because you thought SMART on FHIR had you covered. “Read” scopes made you think authorization was done.
Then you didn’t build ABAC (attribute based access control), because you thought RBAC was enough. Until you learned that access needed to depend on the relationship between a clinician and a patient, something roles couldn’t express.
Then you found that seeing a resource and seeing everything in it were different questions. A clinician could access the Patient resource but not the contact details inside it. You found yourself filtering individual elements out of the response.
Then security labels appeared and that forced you to classify and restrict sensitive data on the way out. On top of that, your secondary use app needed access to that same data and you had to build a full anonymization engine covering multiple resource types.
Then Patient Consent appeared and all of this had to be revisited. What your team thought was a simple checkbox turned into a data access project that touched every resource type. You needed a consent enforcement engine that could filter outgoing data based on what doctors and systems were allowed to see at the individual patient level – as specified by the patient.
Just when you thought you were done, your analysts brought up break-glass scenarios, which forced you to put in an override to all that you had just built so that doctors could access everything in an emergency.
All of these crept up on you one by one, and they all sat in the same place – between the request, the data, and the response. An intercept or proxy layer. A new component you never thought you would need to build, but one that every other new component required.
None of this was the FHIR server’s responsibility. That remained a six month project – data in, data out, a little mapping. Easy and in scope.
The unscoped work was a series of separate projects that the FHIR server vendor never mentioned and your technical team didn’t know enough to ask about. Missing expertise that turned your small FHIR project into a business roadblock that took eighteen extra months to deliver.
If you’re estimating a FHIR project right now, the server is not the risk. It’s everything else you will need to build that will slow you down.
I’ve worked with enough organizations in the early stages of FHIR projects to know that I may be talking to a wall right now. If you’re shaking your head and thinking “we can do all that later”, then take this one piece of advice to heart: the FHIR server is NOT the project.
---