Cassandra was a Trojan priestess who was fated to utter true prophecies that would never be believed.
There are times I feel like a modern day Cassandra when I write about FHIR topics that I consider of crucial importance only to have them fall flat, ignored by a disinterested audience.
Here’s an example.
The Problem with “_include” and “_revinclude”
Some FHIR server providers limit the number of “included” resources that they return in a search query. Microsoft and Google spring to mind, but there are others. That limit might be as low as 100 resources.
What this means in practice is that a simple query to get a list of Encounters — along with the associated Patient, Practitioner and Observation resources — could result in missing resources.
Even if the query asked for only 20 Encounters at a time, the included resource count could easily be greater than 100, resulting in a truncated result set.
This topic came up on the FHIR chat forum back in August and resurfaced a week ago. There was a lot of discussion but none of the concern I feel about this when I think of what could go wrong as a result.
Creating Custom $operations
The past couple of weeks I’ve been working a lot with custom $operations in FHIR. Defining them, documenting them and working through issues when building them.
I asked a question in the recent FHIR survey I sent out about operations. I was curious to see how many organizations who use FHIR were building their own. Was I alone in appreciating the benefits?
36% said they had built their own.
Not a surprising figure, as the entry point to building operations is high. Some server providers make it easy to create your own, most do not. It’s often necessary to build a façade on top of the FHIR API to expose new operation endpoints.
I used Simplifier to document the operations and found their Firely Query Language (FQL) very adaptable when it came to creating pages based on OperationDefintion resources.
Here’s an example of a $match operation documented in Simplifier using FQL to generate the Parameters (In) and Return Values (Out) sections.
Multi-tenancy in FHIR
I’ve worked with FHIR in multi-tenant environments for many years and it always surprises me how each organization differs in their approach. There’s no “official” or standard way of handling data from diverse organizations in single or multiple FHIR servers.
Microsoft seem to favor one server per tenant with their Health Data Services “Workspace” functioning as the HIPAA barrier. They may have chosen this approach as their pricing model is use-based and not server-based.
If your FHIR provider charges per server this could quickly become prohibitively expensive.
A week ago I was trying to connect the Vanya FHIR Viewer to FHIR APIs at AthenaHealth and discovered that they were using a parameter based approach to multi-tenancy. All search queries were required to include an “ah-practice” parameter that identified the “practice” or tenant.
I’ve see approaches elsewhere that used tenant specific endpoints, others that insisted on specific request headers containing a tenant id.
There’s no one size fits all — everyone seems to be inventing their own solution to multi-tenancy.
Analytics on FHIR Conference
The Analytics on FHIR Conference is taking place next Wednesday. It’s a free online event with a number of speakers from different organizations.
The focus of the conference is SQL on FHIR — an open source community driven project that flattens your FHIR data and makes it accessible via SQL queries. But the wider focus is on how to run heavy analytical queries against FHIR data.
I recommend signing up even if you can’t attend on the day, as videos will be available after the fact.
You can register here: https://fhiranalytics.org/
1,000 Test Patient Bundles
A couple of week ago I was trouble shooting some issues a reader had with Synthea test data. Synthea publish 1,000s of bundles of patient data on their website — a great resource for developers and testers working with FHIR.
The problem was the bundles didn’t work as they were missing some key resources, causing the POST requests to fail on all FHIR servers.
It turned out they had updated the bundles since I first encountered them, introducing the problem and never fixing it. Luckily a link still exists to the older bundles.
You can find the link on this post.
I recommend you download and store the zip archive before it disappears forever.
Progress on the Vanya FHIR Viewer
I’ll be releasing a new version of Vanya next week. This is the FHIR viewing app I’ve been working on for some time.
My vision for Vanya right from the start was to be able to run complicated search queries using _include and _revinclude parameters and to see the results in a simple viewer similar to a database client.
No more parsing 1,000s of lines of JSON in Postman.
Next week’s release delivers on this, so I’m delighted to get it out there — and to be able to use it myself every day.
Here’s an example of a complicated query with multiple included resources I ran this morning. The test data is from the same Synthea bundles I mentioned earlier.
Fingers crossed for the release next week!
---