Forecasting FHIR

“The best way to predict the future is to invent it.”
Theodore Hook

It’s been said that it takes about 10 years for a healthcare technology standard to progress from initial work within a standards development organization to being available in commercial products.

As this article represents my 10-year anniversary writing for the magazine I thought it might be interesting to look back at what my co-author’s and I wrote about FHIR’s progress and explore where its headed.

We first wrote about FHIR in 2012 when most EHR projects where focusing HL7 v3 and CDA. Our message for Canadian interoperability projects was “keep calm, carry on”. FHIR was showing some promise as a simpler and more flexible alternative to HL7’s other standards, but it was still in its infancy and there wasn’t enough evidence to suggest vendors and government funded initiatives would support it.

In 2014, the message shifted to “keep calm, but time to pay attention”. There were signals from the US marketplace that large vendors like Epic and Cerner were starting to collaborate on the creation of APIs that would use FHIR as the payload for the data to be exchanged.

We noted that it was still early days, but the fact that these organizations were choosing FHIR over other established HL7 standards suggested that it was better aligned to their needs. The article concluded that Canadian implementers shouldn’t abandon investments in existing standards, but projects with greenfield space should at least evaluate FHIR.

By 2016 FHIR had evolved from a simple standard for describing health data to an ecosystem combining FHIR with other modern technologies that supported rapid development and testing of FHIR based applications. There was a proliferation of free tools and resources to support new implementers, something noticeably absent in the previous HL7 standards.

In 2017 we wrote about the SMART on FHIR specification, which describes how source applications can be designed to launch external apps and use FHIR-based APIs to exchange data between the two applications. The specification also described how an external app could be launched “in context”, which allows users to maintain a common view of a patient between the two apps. US vendors were starting to launch their own ‘app stores’ that relied on SMART on FHIR APIs.

The article questioned if US vendors would enable their SMART on FHIR APIs in Canada given the differences in underlying data (e.g., code sets) and business drivers between our respective countries. It was also unclear if Canadian vendors would invest in similar APIs, especially considering they don’t have the same deep pockets as some of their US counter parts.

In January 2020 I attended Epic’s first Canadian user conference and I couldn’t help but smile when several presentations focused on their experience integrating a 3rd party app with Epic’s SMART on FHIR API. Each presentation described challenges with typical lower layer interoperability (e.g., firewalls, digital certificates, etc.) but none of them focused on payload issues (i.e., healthcare data expressed as FHIR resources).

What about Canadian vendors? On January 29, 2020, at Digital Health Canada’s Webinar Wednesday, a group of Canadian vendors demonstrated a complex mental health referral scenario and showed how data can be passed between their systems using FHIR APIs.

The participants – QHR Technologies (Accuro EMR), CognisantMD (Ocean eReferral Network), Strata Health (Strata Pathways), Caredove, and Alayacare – demonstrated the exchange of referral data from a primary care physician through multiple intermediary providers and applications to the final scheduling of home care services for the patient. The demo also showed how data traversed its way back through the providers’ applications, effectively closing the communication loop which is necessary for true coordinated care.

While the prevalence of SMART on FHIR APIs in Canada is at the start of its growth curve, we predict they will be increasingly available in vendors’ applications over the next 4 years. By 2024 we won’t be writing about FHIR per se, and instead will be focusing on the use of the APIs to support data exchange across organizational boundaries to meet the needs of patient centred care coordination.

We expect SMART on FHIR APIs will be used to support point-to-point data exchanges similar to the mental health referral example previously discussed. The same APIs will also be used to pull data into regional or provincial repositories, delivering the holistic view of patient data required for provider and consumer applications, reporting against performance-based indicators, and clinical research.

In the spirit of the opening quote, no one can predict the future. All we can do is visualize a future where technological improvements are supporting the quadruple aim of care, and then work collaboratively towards making it a reality.

share this article...
Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn