Developers need better FHIR tools
Not long ago I worked on a greenfield project for a healthcare company. I was building the API that sat between the UI screens and the backend FHIR database, hosted on one of the larger cloud providers.
It was my first exposure to FHIR.
I’ve worked with databases of all kinds: SQL Server, Postgres, MySql, Sqlite, even DB2 back in the good old days. But this was my first encounter with a database that can only be accessed via an API.
If you’re unfamiliar with FHIR, it’s an open source data format for storing healthcare data. All the big cloud providers and a host of smaller companies provide FHIR database servers accessible via a commonly structured FHIR API. It’s growing in popularity. If you’re building a new app or starting a new project in the healthcare space, someone on your team or in the business will suggest using FHIR.
One of my first questions back in the early weeks of the project was: “Is there a desktop client I can use to access FHIR or do I have to use Postman?”
Postman it was.
This may have been followed by “I can’t believe there’s no desktop client I can use to query FHIR!”
For those unfamiliar with Postman, it’s the most popular API platform used to build and access APIs. It’s super easy to use, free for the most part, API agnostic and requires little in the way of technical know-how to get by.
But it’s generic, not optimised to work with any particular API or type of API over another. So while it works well as an API access tool, it’s limited as a FHIR database access tool.
I wanted a desktop client.
I work as a .NET contractor and I move around a lot: different companies, different industries, different problems with different solutions. When each contract ends I do a retrospective of my time there, asking myself questions such as: “Did I learn anything here that I can use?”, “Did I encounter anything this industry needs that is missing?” and “Can I take anything from my time here and build a product from it?”
I was on a flight into Dublin airport last week when I did the retrospective on this particular contract. Usually I come up with lots of ideas but they tend not to be ideas with a commercial leaning, as in: interesting, but no one will pay for that as the pain isn’t big enough.
Not this time. My mind and my pen went right back to week one: “Is there a desktop client I can use to access FHIR or do I have to use Postman?”
There should be.
Sure, it’s an API not a database. I might have to call it something else instead of a database client. But Postman is not a good enough tool for accessing FHIR APIs, not for developers building products and apps on top of FHIR. Developers want something more SQL-like. They need to be able to write a query not make a GET request in Postman.
When you’re building a new app or debugging Production, you want to move fast. You don’t want to be fiddling around with Postman and manually skipping through pages of JSON results to find what you’re looking for.
There are tools out there to help FHIR developers. There’s a .NET sdk provided by a Dutch company. There are CLI tools sitting on top of that sdk. There are companies providing FHIR servers who have their own tools exposed for use with their servers.
But I wanted a SQL-type desktop client that I could use against any FHIR API. Somewhere to build and store common queries that I could save and share with the team. An easy tool that allowed me to drill down into the FHIR data by clicking on Resource identifiers.
I wanted a cross platform desktop client for accessing FHIR APIs on Azure, AWS, Google and other FHIR servers. It doesn’t exist but it should.
Maybe I’ll build it.
To hear more from me, you can follow me on Twitter or on LinkedIn.
Originally published at https://darrendevitt.com on November 11, 2021.
