I don’t trust FHIR server Capability Statements.
They tell you what the server says it supports. This is not always the same as what it actually supports.
There are two main reasons why this can happen.
1. Auto generated Capability Statements from the server provider
The Capability Statement comes out-of-the-box from the server provider and is often not updated by the server owner to reflect changes they might have made.
Examples:
- An API management portal sitting in front of the FHIR server that blocks access to some resource types.
- Custom operations that do not have corresponding OperationDefinitions.
Both valid reasons for the Capability Statement to not match the exposed FHIR server functionality.
2. Broken or incomplete features of the FHIR server
I was testing Vanya against eight of the most high profile FHIR server providers yesterday using the Observation “value-quantity” search parameter.
“value-quantity” is one of the most heavily used search parameters for THE most heavily used FHIR resource type — Observation.
All servers said they supported value-quantity in their Capability Statements. But a simple search failed on two of those eight servers.
Here’s the query:
Observation?code=29463-7&value-quantity=gt100|http://unitsofmeasure.org|kg
In English: Give me body weight Observations where the value is above 100kg.
One server failed with a 500 error because it was not handling the Quantity type in the search parameter. The other failed because it couldn’t handle the system|code parameters that identified kgs as the unit of measure.
A very basic search query using a very commonly used FHIR search parameter.
I won’t name the FHIR server providers, but it feels like some unit tests might help here.
When the Vanya FHIR viewing app connects to a FHIR server, it doesn’t read the server’s Capability Statement. My feeling is that what a server does is more important than what it says it does.
---