Intro To FHIR
FHIR® has become nearly synonymous with healthcare interoperability with rapidly growing adoption by EHR vendors, developers, payers, and patient applications. So what is FHIR? And how does it help solve some of the pervasive problems plaguing interoperability?
This article is meant as a FHIR® 101, or FHIR® for “dummies”. If you’re looking for more in depth content, you can jump into many other detailed FHIR® topics linked below.
FHIR® Documentation | FHIR® for Developers | FHIR® Bulk Data Analytics
FHIR® Acronym
FHIR® (which stands for Fast Healthcare Interoperability Resources and is pronounced ‘fire’) is a standard for exchanging healthcare information electronically using modern web technologies. FHIR® was developed by HL7, a Standards Development Organization (SDO), and was first published as a Draft Standard for Trial Use in 2014.
FHIR® File Format
FHIR® data can be represented as either JSON or XML and consists of discrete data elements (called resources) and standard Application Programming Interfaces (APIs) to create/read/update/delete those data elements. Resources are representations of content such as patients, procedures, medications, claims, and many more resource types. Each resource is a building block that is assigned a unique identifier and the APIs enable multiple stakeholders to reference the same underlying resource across health systems, payers, developers, etc. FHIR® resources can be interpreted by any system including patient mobile apps, EHRs, Claims Processing Systems. Check out an example of a patient FHIR® resource.
FHIR® Regulations
FHIR® resources are open source and available to any developer, allowing limitless connections to applications, providers, payors, and patients. As an added advantage, FHIR® is also Meaningful Use 3 compliant, which is a federal mandate that drives all patients to have access to all of their electronic health records.
Further FHIR® APIs are specifically required in certified Electronic Health Records (EHRs) by the February 2019 Notice of Proposed Rulemaking (NPRM) by ONC, and is the specified standard by which health plans will be required to make patient data available under the CMS Interoperability and Patient Access Proposed Rule, both of which will further accelerate its already growing adoption.
Lately, there’s been a lot of buzz focusing on all of the advantages of FHIR. From health systems, to federal agencies, to application developers, talk of FHIR® is everywhere. FHIR® has been around since 2014, however momentum started to increase significantly as of recently. So why now?
Since its inception FHIR® has made great strides to address some of the biggest challenges plaguing healthcare interoperability by enabling health IT developers to quickly and easily build applications to exchange data using modern web technologies they’re familiar with (e.g., HTML, JSON, XML, OAuth, etc.) rather than esoteric, outdated clinical languages.
Now a number of organizations are building directly on FHIR.
HL7 Version 3 overall failed to gain widespread adoption given its high complexity, lack of flexibility, and high effort implementations that required a deep level of knowledge/expertise.
For the most part, the only part of HL7 v3 that remains widely adopted today is the Clinical Document Architecture (CDA). CDA allows for metadata standardization and various clinical data points. However, as implied by the name, CDA is only specific to clinical data. C-CDA, is a consolidated form of CDA and is focused on the most essential and common healthcare data elements; aligning closer to FHIR.
So what are the biggest similarities between FHIR® and HL7/CCDA as well as differences? The 3 are similar in terms of providing support to specific use cases, provide validation tools, and data standardization. Some of the differences, is that FHIR® provides for a multitude of FHIR® resources, allows for an easier, faster, and cheaper way to to build various applications, and encloses not only a document exchange format like (HL7 v3 and CCDA), but also allows for the exchange of APIs, messages, resources, and various documents like doctor notes. Additionally, the modular FHIR® approach lends itself to more flexibility when developing applications for patients and providers. The CDA approach was initially intended to provide a data dump of the full medical history of a patient, which FHIR® can also do, along with the $everything query. Furthermore, because FHIR® breaks up data into smaller, discrete pieces, there is better uniformity than in CDA which can be messy when processing larger documents for patients with more complex care histories. For more information on FHIR® vs. CDA, visit our blog post.
1upHealth is not the only one pushing FHIR® forward, many various organizations are jumping on board, including the US government, EHR vendors like Epic and Cerner, Apple, Microsoft, Google, and the list goes on. The reasons for this are twofold: first, because FHIR® is based on modern web technologies that software developers can easily use without in-depth healthcare domain knowledge or familiarity with one-off esoteric languages. And second, because companies are starting to recognize the multitude of benefits and use cases FHIR® can be used for.
FHIR® can be thought of as the future of data access. Prior to FHIR, integrating with health systems as well as sharing data have been a difficult and extensive process. The reason for this is because developers would have to build customized applications for each EHR in order to read and write back data. This often would take a lot of human resources, spending a long amount of time understanding unique integration requirements. However, with FHIR, fast interoperability between various platforms can be completed quicker in a standardized manner, where the data is in a structured format.
With an increasing demand for interoperability, and success of MU3, FHIR® has been gaining unstoppable momentum. FHIR® adoption has been spreading across various EHRs, including Cerner, EPIC, AllScripts, etc., as well as business have been modifying their models to accommodate the need of FHIR. With growing patient expectations to have an easy way to access their data, FHIR® paves the way for the future of effortless integration that has become the de facto norm in other industries.
What are the limitations of FHIR?
Migrations from HL7 to FHIR® can be a lengthy process due to lack of backward compatibility and standardization of various health systems. For the migrations to successfully happen, FHIR® resources have to be extended, which adds an extra layer of difficulty. Resources are built based on the 80/20 rule, containing data elements if 80% of existing systems include them with extensions as the other 20%. Extensions are meant to meet specific use cases and don’t scale unless they have been shared and adopted in implementation guides.
What is the FHIR® history?
2011:
In August 2011 Graham Grieve, known as the ‘Father of FHIR’, asserted that HL7 Version 3 had failed. Graham Grieve and a small team that created a new standard for interoperability called ‘Resources for Healthcare’ or ‘RFH’. Thankfully, for the sake of easy remembering and ready pun-making, the standard was renamed to much catchier Fast Healthcare Interoperability Resources otherwise known as FHIR® (pronounced ‘fire’).
2012:
In March 2012, the FHIR® was lit (sorry had to). The specification work was transferred to HL7 International, which allowed for free access and availability. FHIR® went through several iterations before stakeholders reached consensus that it was ready.
2014:
In December 2014, the Argonaut project emerged with the goal to accelerate oAuth and FHIR® in health information exchange through FHIR® implementation guides and profiles. Thus, on February 2014, HL7 published FHIR® as a ‘Draft Standard for Trial Use’ (DSTU), Release 1, which led to the October 2015 release of the ‘Second Draft Standard for Trial Use’ (DSTU2).
2015:
The Argonaut project was to be rolled out by May 2015, and consisted of EHR vendors (Epic, Cerner, athenahealth, etc.), health systems (Mayo Clinic, Intermountain, etc.), and SMART at the Boston Children’s Hospital (BCH) Informatics Program led by Ken Mandl. The outcome of this would be to enable digital electronic health records and health information technology exchange for patients, providers, and payers.
2017:
FHIR® Release 3 in March 2017 was published, as the first ‘Standards for Trial Use’ (STU) release. For a list of supported data as part of STU, check out here.
The key changes of this focused on:
Improvement the RESTful API framework
Added Financial Management and Terminology Services
Additional support for Added support for: Clinical Quality Measures and Clinical Decision Support
Expanded use cases to encompass clinical workflows
Specified format of how FHIR® relates to Linked Data as well as an RDF format
2019 - Present:
More recent FHIR® developments in 2019 include:
FHIR® Release 4 was released with the first Level 6 normative resources
The FHIR® Bulk Data specification was balloted (by a company called 1upHealth) and the initial reference implementation was developed by - you guessed it - 1upHealth and Boston Children’s Hospital under a $1M HHS LEAP grant *FHIR® adoption has been spreading across various EHRs, including Cerner, EPIC, AllScripts, etc., as well as business have been modifying their models to accommodate the need of FHIR
FHIR® is an HL7 standard which brings RESTful APIs and a common format for hundreds of clinical data models to healthcare. If you're new to FHIR, here's what you need to know:
For healthcare integrators, this means that traditional HL7 standard data formats and messages are going to transition to the FHIR® formatted XML and JSON objects, with read and write functionality based on the GET/PUT/POST/DELETE functions used in web based APIs. For healthcare app developers, you will now be able to have atomic data access to individual items within resources like the Patient demographics or Observations for lab results among many other resources.
For healthcare systems, you can build and run applications on this new API standard and produce richer products with data connected from external systems. FHIR® is required under the new rules of Meaningful Use 3, so most EHR vendors will offer support in 2018.
As a patient, you can get and share your medical data in more ways than ever before, including share it with apps that you use. FHIR® also means you'll have more choices of apps in the near future.
1upHealth is building the world's most integrated FHIR® API platform. We already support the largest network of FHIR® connections to healthcare systems which your users can connect with two clicks. 1upHealth provides a managed FHIR® API Server with comprehensive support for FHIR® resource types and data models. Additionally, our FHIR® API allows dynamic search, supports version histories, Provenance and AuditEvent tracking all in a HIPAA compliant cloud. Any developer or health system can get started connecting patient data in minutes on the 1upHealth FHIR® API platform.
To get started, visit here, email us at [email protected], or register for our FHIR® hours and ask questions in real time.