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.