Fast Healthcare Interoperability Resources (FHIR) Explained
Blog
  • Topics
  • Industries
  • Partners

Explore

Topics

Industries

Partners

Fast Healthcare Interoperability Resources (FHIR) Explained

What is FHIR?

FHIR (Fast Healthcare Interoperability Resources) Specification is a standard for exchanging healthcare information electronically. Healthcare records are increasingly becoming digitized. As patients move around the healthcare ecosystem, their electronic health records must be available, discoverable, and understandable. Further, to support automated clinical decision support and other machine-based processing, the data must be structured and standardized.

FHIR aims to simplify implementation without sacrificing information integrity. It leverages existing logical and theoretical models to provide a consistent, easy to implement, and rigorous mechanism for exchanging data between healthcare applications.

FHIR solutions are built from a set of modular components called “Resources”. These resources can easily be assembled into working systems that solve real world clinical and administrative problems at a fraction of the price of existing alternatives. FHIR is suitable for use in a wide variety of contexts – mobile phone apps, cloud communications, EHR-based data sharing, server communication in large institutional healthcare providers, and much more.

Why is FHIR Important?

Mobile API applications and FHIR are the future of interoperability and the future is here.

But what are API’s?

API’s are sets of requirements that govern how applications communicate and interact with one another. An API is an interface that provides developers with programmatic access to a proprietary software application. API’s interconnect any healthcare system, doctor, patient or medical device by normalizing all incoming requests and data as appropriate FHIR resources. FHIR is appealing because it is based on a truly modern web services approach that makes it easier for systems to exchange very specific, well-defined pieces of information such as a medication list, a problem list or lab results, rather than entire documents.

Healthcare IT should always be about the patient. To that end, interoperability is the cornerstone of this patient-first perspective — as an important support mechanism for the timely and effective exchange of information critical for delivering patient care, one of many reasons why FHIR is important.

Of course, some of the push for interoperability is a direct result of regulatory requirements. However, the need for various systems to share information using an industry standard like FHIR is real, and is not limited to what has been mandated by the government. It’s important for systems dealing with patient data to securely interoperate with each other, in order to ensure efficient and effective delivery of care. This secure, access-based, free movement and sharing of data is also important for helping consumers to maintain and manage their health. Government institution may mandate an institution/practice to use FHIR for data collection.

Benefits of FHIR

-Specification is free for use with no restrictions.

-Supports RESTful architectures: seamless exchange of information using messages or documents, and service based architectures.

-XML or JSON as the data transmission format.

-A strong focus on implementation – fast and easy to implement (multiple developers have had simple interfaces working in a single day).

-Independent of any 1 EHR Vendor, Health System, or other For-Profit health entity.

-Open-source FHIR Server called HAPI FHIR that anyone can implement.

Practical uses for FHIR

FHIR can be used in multiple use case scenarios. To understand FHIR is to understand the framework upon which the specification is built. FHIR uses the RESTful Level 2 Maturity model, and has capability for level 3 with use of extensions.

Use Case 1:

Personal Health Records: EMR (Electronic Medical Record) System provides a RESTful API that allows patients to access their own medical records via a common web portal of mobile app. In this example Patient will be the Resource type. It will provide demographic information to the client.

However only a portion of the PHR (Personal Health Record) is even in the 1 EMR System. It includes office visits, a medical summary, current medications, known allergies, but does not include updates to this data from clinicians outside of the system. There are multiple specialists, out-of-network EMR’s. This is where FHIR really shines.

Use Case 2:

Aside from generic use of maintaining patient’s PHR together, there are certain use cases, workflows, collections of documents regarding the patient, with administrative/financial burden. One such is Settlements for patients who got injured and their treatment/coverage falls under a litany of insurances, including Non-Group-Health-Plans…Workman’s comp. In this case, defining things such as Care Team a collection of individuals to restrict to medical modalities/specialties, but involving adjusters, medical experts. This helps leverage FHIR Resources such as Organization Resource, Practitioner Resource – which can be any type of professional, clinical and non-clinical. EMR’s fail to cover this kind of use case – they’re not intended too. If you rely on disparate information systems all with their own data standards to communicate this information, it’s a major headache. This is where FHIR comes into play.

Use Case 3:

Document Sharing: One common way to integrate healthcare information from a variety of sources is to build a repository of documents around a patient record. Building a repository of documents allows for less stringent alignment around policy, procedures and record-keeping/informatics standards.

FHIR provides an equivalent functionality to XDS (Cross Enterprise Document Sharing).

Use Case 4:

Opening up information systems – A fictional practical scenario for FHIR.

Health Network Abbey has 4 hospitals, 25 outpatient clinics and 200 Providers between all of this. They build up over ten years of patient health records, and incurred an EMR transition from one legacy to a new one, circa 2005.

Now, Health Network Abbey is being merged/acquired with Health Network Bennet, which has the same amount of hospitals, outpatient care and providers, but is on a totally separate EMR system.

Let’s talk about some of the solutions of the past. Health Networks Abbey and Bennet both go talk to their EMR Vendor’s who they have robust account management/business development, ongoing enterprise relationships with…the vendors really want to deliver to their needs…spend months/years deliberating how to build expensive, multi-million dollar interfaces, health exchanges between the vendors. Eventually the vendors need to talk to each other, more months and years, stand-offs, disagreement on technical specs. Maybe each has a consortium of health exchanges/ interoperability format, such as the NHIN Direct / Cerner / Epic that they now have to try and force each other into joining.

On the other hand, each system could simply agree to put their data into a FHIR format, in a separate server/database instance (FHIR), so that the other party can simply consume it. FHIR is an objective middleman here.

Briefly About Myself

I am a technical consultant on the BCBS MA Project, working on Digital IT Web Delivery Project which utilizes RESTful API’s to connect back end legacy systems and relational databases and front end UI. I was tasked with finding out about FHIR specification and writing up a blog post about it.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Subscribe to the Weekly Blog Digest:

Sign Up

Categories