In a perfect world your app could access any FHIR server.
It wouldn’t matter who provided the server as the behavior would be the same. Plug it in and out comes patient data.
This is not the reality.
I spent most of last weekend testing Vanya FHIR viewer against FHIR servers from 8 different providers.
There was healthy uniformity across the resource types. The data flowed and rendered well. But there were also lots of inconsistencies that required server specific code to manage.
Many of these inconsistencies were related to URLs and pagination links.
The Bundle.link element is used by FHIR servers to provide links to enable pagination. A Link contains a “relation” and a url. The relation tells us what sort of link it is. These are the most common:
– next
– prev
– self
All 8 servers populate the “next” link. Without it there could be no pagination.
– Aidbox, Firely, HAPI, Medplum and Oystehr provide “next”, “prev” and “self” links.
The happy path.
– Azure and Google provide “next” and “self” links. No “prev”.
Some changes were required to manage this.
– AWS provide only the “next” link — nothing else.
This was a big surprise and needed some serious code and caching to manage.
I’m shining a light on pagination links as the differences here are serious. Anyone building an app that they expect to work with different FHIR servers will find surprises here.
Why does this happen?
Bundle links are not mandatory.
The FHIR documentation says: “The behavior of navigation link types (next/prev/first/last) are well defined for searchset and history Bundles”.
“Well defined” has no teeth, so diversity and inconsistency are the order of the day.
Here is where I think the FHIR standard is too forgiving. The extra effort for providers to add a “prev” and “self” link to their bundles is minimal.
The extra value to FHIR data consumers (and to their consumers) is huge.
We should insist on the effort.
---