A while back, I attended a webinar by our good friend James Agnew, the man behind the successful open source Hapi-FHIR project. My role was to showcase our usage of Hapi-FHIR at Lifen. While I explained how FHIR is at the core of our system architecture and data modeling, I employed a term I had just made up - FHIR-native. To my surprise, the FHIR community jumped on the bandwagon and began using it too! In this article, we’ll not only elucidate what being FHIR-native means to us, but also take a look at the driving principles our engineering team chose to implement to bring value to our custumers.

‍

Language meets tech

What language do you dream in? Whatever your answer may be, I bet it’s your native language! Likewise, when people communicate, they usually choose to do so in their mother tongue. Many are lucky enough to speak a foreign language well enough to be able to translate their thoughts on the fly. For others, however, speaking a foreign language can bring about miscommunication, mental strain and fatigue.

Surprisingly, the same phenomenon applies to technical stacks: when the data exchange model (language A) is different from the data storage model (language B), data scientists might begin to show signs of wear. In the world of information technology, the way you store your data can be considered your native language.

There is a common piece of wisdom that is often shared accross large-scale systems. It says: “Store your data in a format that is optimised for your business critical function.” And for good reason - if you’re a massive Content Distributed Network, you probably want to minimise the cost for your read operations. Ergo, it’s acceptable if the cost of adding a file to your global cache (a write operation) is higher - this doesn’t clash with your business fundamentals.

In the same line, if you’re a log collection and storage service, you probably want to maximise your ingestion rate to keep up with what your customers send you. The log search queries can be slightly slower, but you have to be on top of your log ingestion game!

In both cases, the cost of resources at runtime (CPU, Memory, IO) and at development time (code writing, testing, bugs, project management) is high. Translating the data being read from, or written to, the data store serving that critical business function, is no piece of cake.

In the world of healthcare interoperability, today emerging’s lingua franca is FHIR. Is FHIR the brick that the hospital of the future will be built in? I’m reasonably certain that it is the case. Hence, it would make sense to represent all healthcare data as FHIR resources. Not only in transit, but also when exploiting it.

‍

Baptism of FHIR

Back in 2017, Lifen made the bold decision to adopt FHIR as our blueprint and mother tongue. The founding team of FHIRers set down four gold rules:

1. Thou shalt stick to standard resources by default
2. Thou shalt have a fully defined FHIR profile and validate it
3. Thou shalt store all persisted state in FHIR resources
4. Thou shalt use extensions wisely, and preferably for internal-use only data

Let’s dig into them…

‍

Thou shalt stick to standard resources

FHIR is extensible in many dimensions by design. Still, we believe that the DSTU3 (or R4) resources, the corollary of thousands of hours of collective thought from the world’s best experts in the field, are the sturdiest. Instead of reinventing the wheel, we found out that we could, in the vast majority of cases, use the existing resources and model our data accordingly. This saves us time and effort in the data modelling phase, during implementation, and even on documentation. When using DSRU3 resources is off the table, we use extensions (more on this later.)

Thou shalt have a fully-defined FHIR profile

Languages breed local dialects - think American English versus British English. Granted, they share the same rules, but spelling and slang can differ.

FHIR Profiles are the equivalent of local dialects. Thus, at Lifen we decided to define our own FHIR dialect, a combination of the French IHE Profile and our extensions and specifics. We officially published it on Simplifier.net and enforced it in our API validation.

This was a key choice that helped uncomplicate things for our internal users and partners alike.

Thou shalt store all persisted state in FHIR

For simplicity and easier auditing, we decided that all data that is related to the medical field, whether directly (medical data) or indirectly (metadata such as AI predictions (link), data lifecycle management, et cetera), would be stored in our FHIR-based storage. This makes FHIR the single source of truth in the system. Additionally, customers that can speak FHIR can easily interact with any of our data.

Thou shalt use extensions wisely

As we mentioned in the first rule, standard resources don’t cover all use cases. This is especially true for internal workflows and business logic.

First, it must be noted that extensions are considerably harder to validate than standard resources. Second, extensions tend to evolve fast as their use case also develops. Keeping them for internal use only will avoid the need to coordinate with partners to migrate them to newer versions. Likewise, it will also spare you the effort of maintaining older versions of the API to accommodate less agile ones.

Last but not least, at Lifen, we wanted our API partners to be able to consume our FHIR API using standard clients and without prior knowledge of any extensions. No core functionality should require the ability to understand extensions.

Conclusion: it's okay to play with FHIR

As far as Lifen is concerned, storing our data using the FHIR Data Model has proven to be the most efficient choice. FHIR helps us iterate faster and generate additional value for our customers.

Now, it’s your turn to light the flame; what has your experience with FHIR been like? What do you think of FHIR-native approaches? Get in touch with us and let us know what you think!

‍