FHIR: The good, the bad and the ugly
Since FHIR was released in its first trial version in September 2013, a lot of changes have been made. Through an iterative process and an active community, the standard has evolved from a trial standard to the normative release R4 today. With FHIR R5 on the ballot, Founda's Head of Engineering - Luuk Gruijs - gives his perspective on what he thinks is good, bad, and quite ugly (sorry!) about FHIR.
Back into history
FHIR first came out as a Draft Standard for Trial Use in 2013. It was presented as the new way forward for healthcare data exchange. It contained 49 resources and primarily focused on two use cases: creating personal health records on a mobile device, and the retrieval of documents. In 2015, DSTU2 succeeded DSTU1 and included implementation guides to increase adoption. Resources were adjusted to make creating extensions easier, allowing for more use cases to be covered. New resources were added to also support non-clinical data uses. DSTU2 furthermore introduced the FHIR maturity model which we still use today. Two years later, in 2017, STU3 was released. STU3 mainly contained improvements to the core resources. Then finally, in 2019 there was a major milestone in the FHIR releases. R4 was released. FHIR R4 is the first release that contained normative resources, meaning that those resources passed the HL7 normative ballot and its criteria.
The industry came from quite far and still has a long way to go. But where many years ago we could only deal with ancient tech to exchange data, we now have modern REST API’s and a (FHIR) standard to reason about. Things like pipe delimited HL7v2 messages, verbose XML SOAP requests, and on-premise installs don’t belong to the past yet, but there is hope. That hope is FHIR. Secure, yet open API’s with good documentation that any party can integrate with.
The good
After a brief history, we come to FHIR as it is today. FHIR is a major step forward since it excels in a number of things:
There is a standard
Let’s just start with the fact that it’s great there is a standard. There are described resources, structure definitions, implementation guides and profiles. A guideline with a set of agreements on what data should look like, and what it means. On top of this, the FHIR Implementation Guides also prescribe behavior which is absolutely essential for any integration. Profiles are there to help with localization challenges for simple things like the patient address or personal identifiable number which has different formats in every country. Having this allows for a level of standardization that should lead to reusable integrations, and reusable integrations should lead to (cost) efficiency. Efficiency is what healthcare needs to provide increasingly more care with less people to provide this care. While this challenge is far greater than just a technical one, FHIR certainly helps. Have you ever stood still by the idea of this standard not being there and how your technical integrations would look like? I can tell you, one gigantic, time-consuming and costly mess. Let’s all appreciate there is a standard.
The maturity model
Healthcare IT is complex. There are many processes and use cases for which FHIR should have a solution. Healthcare is also a very sensitive domain. Mistakes in data could cause serious harm to healthcare operations and, in the worst case, death of patients. Hence it’s good there is a process for refining and testing changes in the standard. Checks and balances are in place, work groups are being formed, the changes are tested across multiple use cases and systems and have to be implemented in at least five production systems to eventually become normative. In this, the changes move from FMM0 (draft) to FMM6 (normative), having to pass criteria before it can mature to the next level. Because of this process, I consider FHIR to be very mature.
Based on modern web standards
FHIR is based on modern web standards. From an engineer's perspective, this is why engineers like FHIR the most. FHIR mandates a restful API based on the HTTP(S) protocol, with the ability to use JSON, XML and RDF. Like every other industry we can “just” use API’s to fire (pun intended) requests and exchange information. There are JSON schemas available that you can use to validate your requests. The http documentation is very explicit about instance-level interactions, type-level interactions and whole system interactions. FHIR mandates usage of headers, status codes, URL structures and responses based on best practices. Through SMART-on-FHIR, there is a modern way to authenticate and authorize – inspired by OAuth 2.0. If you are coming from a different industry, you are probably wondering why this is a big deal. But as mentioned earlier: if you are used to exchanging information with HL7v2 over MLLP through a VPN tunnel, your life is much easier now. For engineers this really is a big step forward.
The 21st Century Cures Act
For FHIR something great happened in terms of adoption recently. The 21st Century Cures Act aims to make health information more shareable among patients, providers and payers. By December 2022, all healthcare providers should adhere to the act and be able to provide patient information through a standardized API. The standard that has been chosen for this is FHIR. Whether this is a full-blown FHIR server or just a facade does not matter. There should be a way to access patient data through FHIR. While many organizations are still operating in the MLLP and SOAP realm, it means that all providing organizations will soon have a layer in their architecture that speaks FHIR. The act forces all organizations to familiarize themselves with FHIR and discover the benefits it has to offer. In the meantime, we as system integrators should always push for using FHIR in any project, if available. This way, we enlarge adoption, knowledge and eventually interoperability.
It's flexible
As mentioned earlier, the healthcare domain itself is large and complex. To make matters more complex, within healthcare many provider organizations have their own processes, different implementations of EHRs, different terminologies and different regulations and jurisdictions. For a standard it’s very hard to cover all these differences, hence it needs to be flexible enough to “fit” onto many use cases. The solution of FHIR is "profiles". Profiles are created to cover specific use cases and can extend or restrict FHIR resources and API’s. Profiles can also change the cardinality of elements in a resource. Essentially profiles provide a ruleset that data consumers should comply with. I think the concept of profiles works well as it provides structure and clarity when deviating from the standard.
A great community
The community around FHIR is great. There are forums to ask questions, where it is not rare that the creators of FHIR themselves give you answers. Multiple times a year there are connectathons, where companies come together to test their FHIR implementations with one another. I’d like to describe these as FHIR WLAN parties. Lot’s of nerds together in a room sending requests over to each other and validating outcomes. It’s truly a great way to do production-like tests without exposing yourself to production circumstances. Also there are various commercial conferences like the FHIR DevDays. We also see increasing contributions from industry giants like Microsoft, Google and Amazon putting in more and more focus on healthcare. They open source their work which benefits the entire industry.
The bad
Getting started with FHIR also poses some challenges:
It's too flexible
While earlier in this blog I wrote about FHIR being great in flexibility, the flexibility of FHIR is also an easy "pitfall". Extensions of FHIR in that sense are both a blessing and curse as they undermine the commonality of FHIR resources. Any deviation from the standard hurts interoperability. Period. Yet I dare to make the statement that anyone who is already familiar with FHIR can name a couple of projects where it was “just” easier to create an extension for that one field or dataset to make the use case work. While this works for that one use case, the solution is no longer standard, can often not be reused and therefore provides zero (cost) efficiency in the long run. As system integrators, we should think further than our invoice being paid and take responsibility. Building point-to-point solutions hurts the market.
At Founda we adopted IHE profiles. Those profiles describe behavior for certain interaction patterns on how to use a standard like FHIR to exchange data. IHE profiles do not accept any deviation from the profile to always be sure that when both parties implement the profile, you can exchange data without lengthy integration projects. Both parties start from the same expectations and sending requests to each other “just” works. You can test compliance of IHE profiles through the IHE connectathons. We actively “sell” this as a solution to encourage standardization, reuse-ability and also cost efficiency trough-out everything we do. Join our movement!
FHIR looks easy, but is complicated
As mentioned before, Healthcare IT is complex. The FHIR standards reflect this complexity. FHIR resources are generally large, contain many fields, resources have sub data-types, have references to other resources, can be used for multiple use-cases, and have inconsistencies between them. We often get asked whether we can provide an abstraction layer on top of FHIR to make integrating easier. This would hurt interoperability, so we rather help with educating customers on FHIR and its benefits. But it is a sign. Engineers new in the field need to undergo a steep learning curve to understand what is going on and how FHIR works. There are not many free learning resources. The complexity sometimes almost is a business model on its own, as there are plenty of quite expensive learning courses out there. This all together increases the threshold for using FHIR.
Adoption is lagging
While the 21st Century Cures Act has almost reached its compliance deadline, still many healthcare providers tend to stay pretty comfortable with what they have been doing for the past 25 years. EHR vendors prefer to stay as “closed” as possible because opening up might hurt their market position and decrease relevance. Steps are being made, but it goes slow. Hence with every integration project it’s always a research on what API’s can be used and what data is exposed. We can not safely assume yet there is a nice FHIR API to consume. While for the market this is painful, we at Founda have a solution. We can offer a FHIR API facade in front of non-FHIR hospital systems, where we bridge data-models and normalize the data to a FHIR profile so data consumers can consume consistent data from different organizations and systems.
No clear strategy on using multiple profiles
Standards can never cover all use cases and leave a certain amount of room for free interpretation. One of such use cases is how to expose multiple FHIR profiles in your solution. Should we map all FHIR profiles to separate urls? Should we pass meta-data? Should we use headers? All perfectly valid ways to accomplish the desired result. But if every provider that exposes FHIR profiles chooses one of the many solutions there still is no interoperability. FHIR does not seem to be ready yet for new breeds of products like global gateways that offer connectivity too many healthcare systems across the globe.
Validation of profiles
HL7 only exposes JSON schema’s for FHIR core. There are no provided JSON schemas for other profiles. For that reason it’s harder than needed to do runtime request validation on things like US Core or implementation guides like CDEX or PDEX. Based on structure definitions you can still generate your own validation logic, but when we talk about adoption these to me are prerequisites that should just be there.
The ugly
Now the last thing I want to get off my chest. I recently discovered something quite ugly:
Nested extensions
I still find it hard to wrap my head around it. As per the FHIR documentation: “Extensions can also contain extensions, either because the extension definition itself defines complex content - that is, a nested tree of values in the extension - or because the extension is extended with an additional extension defined separately.” Wait, what? Yes, extensions of extensions because extensions themselves can be too complex. It feels a bit like having a meeting to talk about meetings. We should be able to do better here.
Conclusion
All things considered, FHIR is bringing us a lot of good things. Ten years ago the healthcare IT world looked a lot different. FHIR offers a source of truth, is based on modern REST APIs, and offers enough tools and structure to achieve interoperability. It’s here to stay and something hard to go around in a couple of years. While FHIR helps us with a technical challenge in an integration, there is always still a political and process challenge in any integration. If we stick our heads together and are willing to walk the extra mile, we can really achieve something great. That is a shared responsibility between all of us, where we as Founda gladly take our share.
