In the world of healthcare and interoperability you probably have been hearing the term “FHIR” a lot recently. Actually pronounced “FIRE”, FHIR stands for Fast Healthcare Interoperability Resources. At a high level, it is a standard that describes data formats, its elements and an API for exchanging electronic health records. It was created by the Health Level International (better known as HL7) organization. Its major goal is to allow legacy health care systems to communicate and integrate with each other. Essentially making it easier to share health care information with providers and individuals across many different devices such as tablets, and cellphones. It also is supposed to make it easier for third party developers to make applications that can integrate with these systems. Let’s take a deeper dive into FHIR and talk about the strategic value it can provide for health care systems.
Whats the Standard?
FHIR essentially builds on data format standards already released by previous HL7 versions. However, the biggest value it can provide is that it makes use of API technology, which has become the gold standard of modern web application integration. Since it makes use of API technology, it is much easier to implement. This includes a HTTP based RESTful protocol, HTML and CSS for user interface integrations, an output of either JSON or XML for data representation and ATOM for results.
Instead of a document/paper based approach, FHIR allows the use of discreet data elements as part of its service. Each discreet data element, such as patients vitals or registration information can be created, updated, retrieved or deleted through the use of their specific endpoint. On a high level, this is just their own resource URL that maps directly to that data element on the back end of the system.
API usage is broken down to multiple categories: provide integration strategy and open patient data sharing. API’s builds on the HL7 v2 exchange but is much cheaper, easier and faster form of exchange of data. It will truly allow providers to be flexible to handle external data sharing requests and returns. In terms of open patient data, EHR’s are already required to provide access to data via an open API by Meaningful Use. FHIR endpoints essentially allows patients to request their health data via a portal or chosen application. Now this presents a challenge to EHRs as they must be able to create an integration layer where data has already been consolidated on the back end and able to be returned via an API. If this is achieved, then EHRs would be allowed to break free from data silos that already exist today in the system.
A Robust Health Data Infrastructure
FHIR is widely considered the leading candidate for to help establish a truly interoperable health care structure. The ability to provide standard information across legacy healthcare systems provides a lot of value.
Since it follows a standard, messages passed through FHIR endpoints can be parsed by analytics platforms for real time data gathering, similar to how those platforms work with HL7 messages (parsing data from specified segments in the FHIR messages). That data, in turn, can be routed to a data store where it can be integrated with other gathered informatics data. This is huge for genomics, pharmaceutical and medical profession as it can aide with epidemic tacking, drug interactions, emergency room wait times, drug frauds, etc.
Security is much easier with FHIR as it uses RESTFul web-services. Web service in general already have define security protocols (HTTPS) and use Oath 2.0. Healthcare organizations twill be able to adapt widely used security standards makes implementation much easier than with a v2 integration.
EHRs no longer have to worry about defining their data structure, they have any standard that can follow and would have to define one time. HL7 v2 allows for options in the way the data is presented by the HER.
As well, applications such as mobile applications were not able to handle vs messages and its requirements to be on a network with a persistent connection. At most, they were able to handle one or two HL7 segments. FHIR obliterates that as it gives application the power to request data elements it needs only.
FHIR will finally bring Healthcare integration up to speed with other industries such as social media news .
Value It Provides
FHIR APIs would allow developers to have data at their fingertips and opens up many new opportunities to improve patient care. This data includes patient most current health records. This type of availability of data and real time ability is not possible with current HL7 v2 transaction. HL7 interfaces usually require many steps to complete a typical workflow. With FHIR endpoints, developers will have access to a patient’s single source of truth which will allow applications to streamline these workflows and processes. They would be able to query for information that they need and only when it is needed. As well, API transactions do not require applications to store any information that is not needed, which as always been a a barrier in the past for mobile application integration.
Normal RESTful API’s and FHIR API’s
FHIR endpoints are implemented on top of HL7 and the HTTPS protocols. As mentioned above, this is what allows its content to be parsed by an analytics platform in a similar ways to HL7 interfaces messages could be. Remember that it is a standard, meaning that it will be the same across all organizations that create this resource. The data elements and standards that applications must use to send or retrieve data via the API are defined by the FHIR standard. FHIR APIs details what data will be accepted from outside applications and how data is kept and represented in the database for external use by applications. FHIR defines the layer on top of an EHR and gives direction on how other applications can interact with its data.
Normal RESTful API’s are built on top of HTTPS protocols and do not follow any healthcare standards for data. That means organizations can build RESTFul APIs to any specifications/standards they want. This is one of those situations where we can say that FHIR API’s are always a RESTful API’s but not all RESTful API’s are FHIR APIs. There are many healthcare organizations that make use of APIs that are closely based on FHIR standard or on an entire different standard alone. Essentially, these interfaces function similarly to traditional FTP or TCP/IP interfaces and transmit information securely over the internet. It is typical to see APIs that commonly only make use of the POST function and are very simple with its data manipulation functions and definitions.
Future Outlook
FHIR API could potentially replace VPN and integration struggles that we experience today with HL7 v2 interfaces. It can potentially be the base line for a truly interoperable industry. However, It could potentially remove the need for third-party companies who market themselves around connecting systems together. While I do not predict that will happen, it does seem like an intriguing conversation to be had.