An entire conference in Amsterdam dedicated to the health data standard HL7 FHIR might not top everyone’s list of European travel activities but it did mine. This was DevDays 2023. Here was an opportunity to immerse myself in the community that had built, implemented and engineered tools for FHIR.

Firstly, what is HL7 FHIR?

Tamanu uses FHIR to exchange health data with other software. An example would be a clinician who orders an x-ray but the radiology department responsible for performing the procedure uses different software to record and store the image. This is normal because Tamanu isn’t built to do everything, some very specific requirements are needed to capture and store imaging data.

The radiology software needs to know the details of the x-ray and then needs to return the results to Tamanu. FHIR is a standard way of encoding that data.

Needless to say, health data can become quite complicated with many business rules that often only become apparent during usage. Using a standard like FHIR has enabled us to build Tamanu in a way that leverages the accumulated wisdom inherent in an established framework. In other words, someone else has done the work and solved the problems.

So what about the conference?

Over the past 18 months, Tamanu has been building a series of integrations, exposing data that can be used – as in the radiology example above but also other workflows – like sending lab requests and getting results from lab software, sharing patient details securely with billing software, and sending medication requests to pharmacies.

During this year and a half, I spent much time scouring the API specifications – debating topics and interpretations of minute details with engineers. While tremendously well written, there’s no substitute for a conference full of engineers passionate about FHIR which is what DevDays was.

Here’s what we’re excited about:

Pursuing profiling: It was easy to sit up late bathed in the screen’s glow looking at FHIR specifications in a dogged pursuit of full compliance. It can become an obsession. The FHIR conference taught me never to strive for completeness. Instead, you can use profiles in Forge or FSH to define a subset of the specifications for your implementation. Let’s say patients in Tamanu will never store marital status – it’s possible to exclude that field and then validate all models through the profile. Very neat.
Test Driven Development: TDD was huge then it wasn’t. Now it’s great for specific situations like when you have specifications already well defined (like FHIR). By writing the tests in the beginning it’s a clear way of documenting requirements both to engineers and API consumers then turning those into a suite of unit tests for your CICD pipeline.
Treat FHIR as self-documenting: Up until now, we used FHIR simply as a library of resources (data structures). We have written numerous solution designs to describe each of these. These are perfect in the beginning but sooner or later it’s important to begin thinking of your API independently of how each consumer will use it. Enter the Conformance Module. This is a series of resources that will define exactly how you are implementing FHIR.
Range of Toolsets on offer: If there is a problem you’ve had with FHIR core chances are someone has designed a solution. A case-in-point – we have deployments with hundreds of thousands of patients. Each time we change the patient resource – say add a patient’s ethnicity – we have to update each patient. For software using Tamanu as a patient master index, it means they have to update every patient too. Doing this through the API is nigh on impossible, so it becomes a manual (and tedious) process of exporting and loading data. However, we could use FHIR’s Bulk Data protocol to automate and enable all API consumers to fetch the data themselves. I lost count of the profilers, validators, bespoke languages and other toolsets and imaginative innovations I saw at DevDays.
What’s on the road ahead: Having FHIR founder Grahame Grieve personally go through the recent release 5 was illuminating. Very exciting here is the full rewrite of the Subscriptions resource and workflow. It was also very interesting to see exactly how the roadmap of FHIR has evolved and will evolve in the future, the challenges with managing such an immensely important standard and the opportunities with emerging tech like AI.
The FHIR community is vibrant and HUGE: Perhaps the most important takeaway had nothing to do with technology. It was the knowledge that FHIR is a set of standards led by the community that uses it. This level of participation means that the community is incredibly active and really owns the project. You can sense the grassroots vibrancy at an event like DevDays. If you want to see this in action head to the Zulip site.