The Fast Healthcare Interoperability Resources (FHIR) standard defines how healthcare data can be exchanged across various IT systems. Created and maintained by Health Level 7 (HL7), the FHIR standard uses an Application Programming Interface (API) and common web technologies to make interoperability easier for healthcare organizations to adopt.
According to the HL7 website, the FHIR standard is based on years of lessons learned through the development and implementation of several other HL7 standards. Emerging industry approaches also played a role in creating the FHIR standard. In an effort enable continuity and to integrate with existing health care systems, FHIR has gone through multiple iterations since its inception.
“FHIR is an evolving standard,” says Keith Boone, enterprise architect and interoperability guru at Audacious Inquiry. “It’s important for organizations to understand what’s stable, and where it is going to effectively use it as a tool to promote interoperability.”
The Audacious team has been deeply involved in the development of FHIR since its original inception more than a decade ago. In this blog post, we learned all about the FHIR fundamentals from Boone and fellow Audacious interoperability subject matter expert, Dave Pyke.
Why Do We Need FHIR?
Health information systems used by hospitals, physicians, labs, and pharmacies have historically been siloed from one another and were not designed to exchange data quickly or easily. The lack of interoperability between various healthcare IT systems — and lack of data standardization — resulted in fragmented personal health information.
That means that a patient’s data profile appeared differently in each provider’s system, resulting in providers trying to make clinical decisions using missing, inaccurate, or inconsistent patient data. This is an obvious issue, as providers need complete, accurate data to make informed decisions about their patient’s care.
What HL7 FHIR aims to do is facilitate and simplify secure data exchange between the various healthcare applications used by different providers to ensure that data can be sent and received seamlessly across disparate healthcare systems. FHIR is needed because it uses existing concepts and systems to simplify implementation and, ultimately, make interoperability more attainable.
FHIR resources can be extended and restricted in a process called profiling a resource. FHIR profiles are built for specific use cases and consist of all the resources and extensions that are needed for that use case. Essentially, profiles tell the relationship between the data elements in a resource. For example, you can limit the types of observations that a resource will hold by limiting the codes that are allowed to be used in that resource in a profile.
What is the FHIR API?
APIs are a modern way for applications to communicate information across different platforms. APIs help speed up the process of sending, receiving, storing, and interfacing with other healthcare data through cloud-based applications. The FHIR API uses a Representational State Transfer (REST) API as the basis for its data exchange.
“REST APIs are easy for developers to operate with at all skill levels,” says Boone, “They are supported by software development tools, and easy to connect to and test with.”
This is important because it means the FHIR standard is more accessible to all developers throughout healthcare and can help to speed up the process of integrating this standard into many systems. As FHIR becomes more widely used, it will ultimately support greater interoperability with faster, cleaner data exchange.
What Are RESTful APIs?
RESTful APIs are a simple and flexible way to access web services. REST is stateless, which means sensitive client data is not stored on the server and each request is processed on an individual basis. To understand the difference between REST and RESTful, you can check out this article comparing these APIs.
“The RESTful API allows for a healthcare system to only provide or fetch the data needed at the given time,” says Pyke. “FHIR allows for a system to only request a specific encounter or observation and then, when it needs to, get attached information such as the detail on the clinicians participating or other relevant information when it’s needed. This simplifies the data flow to only be the relevant information instead of a complete record.”
How to Implement the FHIR Standard
Though FHIR is designed to be easy to implement, there are things organizations should take into consideration when adopting the FHIR standard.
“Primarily, organizations need to review the data they have, how it is stored, and how that data is used in interoperability workflows,” says Pyke. “Because many systems work on messages, moving to the RESTful paradigm can have wide-ranging effects on how data is used by systems within and without the organization. Many organizations’ data isn’t stored in the way that FHIR exchanges it.”
This means organizations need to have a comprehensive review of their databases and work on mapping the data they have to the FHIR standard. While FHIR is not yet required for all organizations operating in the healthcare industry, it is on track to become the industry-wide standard that organizations will have to implement, making it smart to get ahead of it now.
Additionally, there have been myriad FHIR implementation guides that address specific use cases for interoperability. “These should be reviewed to see how they apply to the use cases that the organization has,” says Pyke. “This can ease exchange and prevent the organization from re-inventing the wheel.”
About the Author
Morgan Fitzgerald is a guest writer for Audacious Inquiry and a member of Silverback Strategies. As a content strategist, Morgan and the team at Silverback collaborate with Audacious Inquiry to create relevant and reliable content for the benefit of Audacious Inquiry’s healthcare audience. To learn more about Silverback Strategies, visit their website or LinkedIn.