FHIR as the mother tongue, aka being FHIR-Native
I participated recently in a webinar by our good friend James Agnew, who is behind the successful Open Source Hapi-FHIR project, to showcase our usage of Hapi-FHIR at Lifen and how FHIR (link, link) is now at the core of our system architecture and data modeling. In the presentation (video link), I mentioned the term “FHIR-Native” and our driving principles around it. This has attracted some interest in the community so I thought I would elaborate more.
When people communicate, their “mother tongue” or “native language” is almost always the easiest way to express themselves. They can of course translate to other languages, that they are proficient in, on the fly. This comes at the cost of potentially “imperfect translation” as well as mental strain and fatigue. It comes as no surprise that the same applies to technical stacks where the data exchange model (spoken language) is different than the data storage model (native language).
People often ask : “Which language do you use in your dreams? That’s your native language!”. In Tech, the way you store data is your native “language”
There is a common wisdom in very large-scale systems that says : “Store your data in a format that is optimised for your business critical function”. If you’re a massive CDN (Content Distributed Network), you probably want to minimise the cost for read operations, so it’s acceptable that the cost of adding a file to your global cache (a write operation) could be a little more expensive without breaking your business fundamentals. If you’re a log collection and storage service, you want to maximise the ingestion rate to keep up with what your customers are sending you. The log search queries can be a little bit slower but log ingestion has to be blazing fast. In both cases, this costs resources at runtime (CPU, Memory, IO) and at development time (code writing, testing, bugs, project management), in order to translate the data being read from or written to the data store serving that critical business function.
In the healthcare interoperability field, the lingua franca of today (to a certain extent) and the future (certainly) is FHIR. Therefore, it would be logical to represent the data as FHIR resources, not only in transit but also when persisting it.
We committed to this design decision at Lifen at the end of 2017. We agreed among the team to a set of rules (that we wrote down only recently). This lead us to have a set of working principles that I described in this slide :
Let’s dig into them…
Stick to Standard Resources
FHIR is extensible in many dimensions, by design, but our belief is that the DSTU3 (or R4) resources represent thousands of hours of collective thought from the world’s best experts in the field. 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. We save effort in the data modelling phase, we save effort in implementation, we save effort on documentation. When this is not possible, we use extensions (see below).
A Fully-defined FHIR Profile
Languages have dialects. An analogy would be “British English” vs “American English” vs “Australian English”. It’s all english but certain pieces of vocabulary are sometimes different and spelling can be different.
FHIR Profiles are the equivalent of a dialect for a language. We decided to define our “Lifen FHIR dialect”, which is a combination of the French IHE Profile and our own extensions and specifics, publish it officially on Simplifier.net and enforce it in our API validation. This has made things much simpler for our internal users as well as our partners.
All Persisted State is 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, etc) would be in our FHIR-based storage. This makes FHIR the single source of truth in the system and means that if a client can speak FHIR, they can interact with any data.
Extensions are for Internal-Use (99% of the time)
As mentioned above, standard resources can not cover all use cases, especially the ones pertaining to internal workflows or business logic. The rationale limiting the usage of extensions for internal use cases is based on :
- it’s harder to validate extensions than standard resources
- extensions tend to evolve fast as the use case evolves so keeping them for internal use, avoids the need for coordinating with partners to migrate them to newer versions, and by the same token, the need to maintain older versions of the API accommodate less agile ones.
- we wanted API partners to be able to consume our FHIR API using standard clients without prior knowledge of any extensions. No core functionality should require the ability to understand extensions.
There are of course some rare exceptions but we have been able to limit these to one or two cases. Our goal remains to move them out of extensions in the near future!
Conclusion
Storing all our data using the FHIR Data model has been a great win for our team and has accelerated our ability to iterate and bring value to our customers. Don’t hesitate to share with us your experience in the comments below if you’ve gone down a similar path already!
