FHIR! FHIR! FHIR!
FHIR (Fast Healthcare Interoperability Resources) Specification is a standard published by HL7 for exchanging healthcare information electronically. And it’s a hot topic for payers and providers.
As patients and members move around the healthcare ecosystem, their electronic health records must be available, discoverable, and understandable. Simply put, consumers expect this experience. Further, to support automated clinical decision support and other machine-based processing, the data must be structured and standardized. Mandates demand it.
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 HL7 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 healthcare consumer. To that end, interoperability is the cornerstone of this consumer-first perspective – as an important support mechanism for the timely and effective exchange of information critical for delivering patient or member 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 and member 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.
Benefits of HL7 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 one EHR vendor, health system, or other for-profit health entity
- Open-source FHIR Server called HAPI FHIR that anyone can implement
Interested in becoming a FHIR developer? HL7 offers certification and proficiency testing to assess the knowledge and proficiency of its most frequently used health information technology (HIT) standards. It’s the same training our developers use. Get started here.
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.
EXPLORE MORE: An Interoperability Success Story: Modernizing Enterprise Data & Integrations in Healthcare
FHIR Use Case: Scattered Personal Health Records
EMR (Electronic Medical Record) System provides a RESTful API that allows consumers to access their own medical records via a common web portal of mobile app. In this example, the patient/member 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 one 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.
FHIR Use Case: Scattered Settlements
Aside from generic use of maintaining patient’s PHR together, there are certain use cases, workflows, and 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 to. 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.
FHIR 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).
FHIR Use Case 4: Opening Up Information Systems
Let’s imagine that the fictional Health Network Abbey has four hospitals, 25 outpatient clinics, and 200 providers. 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 vendors with whom they each have robust account management, business development, and ongoing enterprise relationships The vendors really want to deliver to their needs and spent months (or even years) deliberating how to build expensive, multi-million dollar interfaces, health exchanges between the vendors. Eventually the vendors need to talk to each other, which leads to 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.
FHIR Know-How and More
We often field the question, “Can you support FHIR?” The answer is: absolutely. It’s important to recognize, though, that while the FHIR standard is an important enabler, it is not the end-all-be-all for interoperability initiatives.
