Believe it or not, May 14, 2022, marks 10 years of HL7® FHIR® (Fast Healthcare Interoperability Resources). Built off of its preliminary release, Resources for Health, FHIR began as a way to connect the various technical issues with the standard, aiming to improve the functionality and speed in which information was shared.
The framework was designed to find and exchange health data between different systems as a way to easily access a person’s information while providing better services. The idea of connecting these data systems has been around for quite some time, but using online standards and making it work was revolutionary.
We know that achieving interoperability and the future of intelligent health data still needs time. Similarly, the FHIR standard is constantly evolving to solve existing problems and anticipate the emergence of future issues. What we know for certain is that our industry is on a collective journey to transform healthcare as a whole and that Smile CDR plans to keep pushing forward on this mission.
A Decade on FHIR
In July 2011, before he was known as “the Father of FHIR,” Grahame Grieve had the idea for Resources for Health. The idea came to him when he noticed healthcare’s difficulties in sharing information after experiencing a health emergency in his family. After teaming up with Ewout Kramer and Lloyed McKenzie, the project was presented to HL7 in September 2011. By May 2012, the FHIR started. I was lucky enough to be a part of the small HL7-FHIR group as HAPI FHIR project lead.
FHIR had its early adopters era between 2013 and 2017, with its first DevDays in November 2014 in Amsterdam. What started off as a few tables of approximately 50 developers turned into multiple events with hundreds of people in attendance. At that time, others were building very successful production systems. What makes FHIR stand out is that the people working on it had an academic bend, were using leading edge software and were lucky enough to be in a position to experiment with different systems.
After several iterations with the dedication of everyone involved, FHIR was released for free access trial use in February 2014. Before the year was done, a wide scope of US stakeholders committed to the Argonaut Project, which aimed to promote FHIR Application Programming Interfaces (APIs) for the digitization of health data and technology for Payers, Providers and Patients. Soon enough, the private sector expressed their interest in the project.
At this point development shifted to address the challenges of interoperability in healthcare by utilizing technologies like HTML and JSON. With FHIR adoption picking up steam, it caught the attention of Microsoft, Google and even the US government.
March 2016 marked the launch of FHIR’s community forum, chat.fhir.org, which opened up the discussion on improving and implementing changes to the standard. With so many people all over the world getting involved, the chat forum is quite possibly the reason why the DevDays that November surpassed its 250 participant milestone.
FHIR became more mainstream between 2017-2020, largely thanks to release three (R3) in 2017. Another major contributor to FHIR’s growth happened in 2018 with the inaugural US edition of DevDays, which was organized by Firely and HL7 as well as the introduction of a patient tracking resource.
But what really got people excited about FHIR in a production context was R4’s release in 2019. Though there have been some technical corrections, this release accelerated the trend of building wide-scale systems.
Once the COVID-19 pandemic hit, FHIR-related events went virtual. This proved to be beneficial as interest in the standard was already at an all-time high. The push away from in-person events actually allowed more worldwide participation and took FHIR to a new level.
FHIR’s scale-up period kicked off following the ONC’s Final Rule to the 21st Century Cures Act in March 2020. More people, including mainstream software developers, began to adopt the standard. Though the regulation is only in the US, that singular Act did a lot to spearhead the adoption of FHIR around the world.
The initial version of the standard was only coded in Extensible Markup Language (XML) and had a lot of voids which, as the name suggests, is a data type that has no operations or values. FHIR has since upgraded its coding and shied away from that model. Over the decade, FHIR has evolved in a way that kept its original building blocks. Yet, the system we see today is an unrecognizable upgrade from its predecessor.
The Difficulties of Setting Standards
The growing number of FHIRusers shows that more people are appreciating the virtue of the standard. This, unfortunately, hasn’t always been the case, and some industries had to learn the hard way that not having a standard can have dire consequences.
Let’s have a look at the Great Baltimore Fire, an incident that has instigated the change to the firefighting standards in the US.
The fire broke out at the top of a John Hurst and Company building, after 10am on Sunday, February 7, 1904. As most buildings were made out of wood, the blaze quickly spread. By 1:30pm, multiple blocks of the city were engulfed in flames. The Baltimore Fire Department didn’t have the resources or capacity to fight the fire themselves, so they asked for help from nearby cities.
A total of 1,231 firefighters arrived between that evening and the following morning when 70 city blocks were devastated by the fire. They traveled to Baltimore with their equipment only to discover that it wouldn’t hook with each other; the hoses in Baltimore had different gauge sizes as there were different thread and connector sizes. Ultimately, though well-intended, the firefighters who traveled all that way were unable to effectively assist. Thankfully there were no deaths, but the fire destroyed thousands of buildings.
This resulted in a standard set of gauges and geometry that was soon set up for hose couplings—the first national standard of its kind. Data from 2004 shows that only seven cities have adopted the National Fire Protection Association (NFPA) standard. However, it’s possible that number has changed in 2022.
What we’ve learned from this is that standardization is tough. In over 100 years since the Great Baltimore Fire, the implemented changes aren’t the standards in gauges, it’s the way buildings are constructed—and the fact that firefighters no longer need to take a train to travel between cities.
There’s an immense investment to completely change and rework current products in favor of implementing change. However, there’s an enormous payoff once it’s done; aside from a future tragedy being avoided, there’s a significant cost savings in buying standard products in bulk as opposed to custom parts. When it comes to interoperability in healthcare, developers are quickly adopting new standards as they’re set. The difficulty comes with the industry itself. After all, how can we get help from other areas when not everyone has the same information?
Creating Healthcare’s eBay Effect
A product or industry gains power once it makes major changes to the way it impacts society. For instance, the power of the internet was heightened by the introduction of eBay. No matter where in the world you were or what hobbies you had, with just the click of a button, you could find whatever it was you were looking for. And, in about a month, that purchase would show up at your door. For hobbyists or anyone looking for unique items, this eliminated the need to travel to other cities and search for specialty stores. That game-changing website really revolutionized how we use the internet today.
It’s time for the healthcare industry to experience its eBay moment.
In the last year, Smile CDR has put forth a Master Data Management (MDM) module that allows links to be created among FHIR modules. As they’ve grown the data fabric architecture, new ideas are able to be discovered and tested. With MDM, more golden records and searches have been added.
Another unique feature that was added is Partitioning, which acts as a flexible identifier grouping a set of resources together that can be used to achieve different outcomes. This includes things like subscriptions and bulk exports that need Partitioning fabric support. There were also all kinds of interoperability connectors, which is a key factor to achieving interoperability. The size of Smile CDR’s HL7V2 code base, which supports the majority of common interfaces, was almost doubled which reduced implementation costs and provided a framework for what’s not included in the standard.
Adding to the excitement is the launch of appSphere. The integrated productivity suite was built into Smile CDR and simplifies the registration, building, testing and management of third-party Substitutional Medical Applications and Reusable Technologies (SMART) on FHIR apps using three connected components:
App Gallery for consumers
Developer Portal for third-party developers
Admin Console for Smile CDR admins
Also currently in the pipeline is Marketplace. Ultimately, the vision surrounding Marketplace is to create a participatory ecosystem where people can contribute the things that they do—including data architecture, flow and app development—and have it shared across the platform. Another project nearing its debut is Smile CDR’s Collaborative Roadmap portal which will allow consumers to learn about recently launched products and features, vote on and help inform future product development as well as submit new product and feature ideas.
What’s Next for FHIR?
The possibilities are endless when it comes to a post-interoperability world. There will be a point where FHIRis ubiquitous enough that we won’t need to think about interoperability; it will simply just be a way of life. We already have software that has thousands of data points from various systems contributing to algorithms, finding issues before they become huge problems.
What Smile CDR hopes to accomplish is a singularity in healthcare standards, using FHIR, allowing for the Internet of Health to be safe, secure, well codified and with good synaxis. This new world would allow data to be available whenever and wherever it’s needed. Not only do we believe it’s coming, we’re working to make it happen.
Smile CDR’s developer documentation, as seen online, is a reflection of how people are really using HAPI FHIR. As is typical, towards the end of the year is where there are dips in software development. However, upon looking at the data, it’s clear that there was a massive spike in FHIR development around the time when the COVID-19 pandemic began. This overlapped with the Cures Act Final Rule so it’s difficult to pinpoint the exact cause. Either way, the rate of people beginning to use HAPI FHIRis steadily increasing which is a sign that we’re barrelling towards a post-interoperability world. Though FHIRis not yet eBay, there are plenty of innovators taking advantage of the data fabric to create new opportunities and Smile CDR is excited to be a part of that journey.