Summary
With the Interoperability and Patient Access final rule from the Centers for Medicaid & Medicare Services (CMS), health care stakeholders must ensure more streamlined data exchange between patients, providers, and payers. It’s a challenge that healthcare organizations can overcome by structuring healthcare data and making it interoperable via standards — particularly FHIR (Fast Healthcare Interoperability Resources), as suggested by the CMS.
FHIR is a relatively new standard for describing healthcare data in resources and specifications that enable health records exchange via an API. The organization responsible for FHIR is HL7 (Health Level Seven International), which creates health care standards.
This article will cover the HL7 FHIR in a short overview and its use for health data interoperability. Before getting into what FHIR is, it is essential to understand interoperability in the healthcare industry and its issues. So, let’s dive in!
The Issue of Interoperability of Healthcare Data
The easiest way to explain interoperability is through phones. Take any two smartphones, and they can connect through mobile data, a wireless connection, or Bluetooth regardless of what manufacturer made them. Healthcare organizations need such a level of connectivity.
But here’s where healthcare interoperability hits a few brick walls.
Industry challenges
As in other industries, expectations for a healthcare product are higher than for a Swiss watch:
- Higher requirements. Approaches such as patient-centric healthcare, data-driven healthcare, coordinated care, and value-based care require smooth data exchange.
- Higher expectations. Patients have growing expectations regarding service quality, data privacy, and healthcare efficiency, meaning more accurate and secure information sharing requirements.
- Growing volumes of data. Healthcare organizations need to support automated clinical decision-making and other machine-based processing, the growing demand for remote patient care, and the trend of telehealth. They need to produce, store, and exchange vast amounts of information, and the volume of data is growing enormously.
Request a custom price quote for your Healthcare challenge. Use the form to describe the project, and we will get in touch with you within one business day.
Data Privacy issue
Companies face strict requirements for handling personal data in many industries, but it’s especially true for healthcare. There’s more at stake — not only is this data-sensitive but mishandling it could cost lives.
Other pressing issues
While data privacy is always a risk, application bugs can increase the possibility of human error:
- Misleading healthcare data and mistakes in data exchange. Prescribing the wrong medication can cause patient death or lead to patient care errors.
- Lack of data exchange between different entities. Duplication of analyzes and increased costs for unnecessary examinations.
So, what can be done?
Overall, there’s a need for data interoperability, but data must be structured and standardized to satisfy the market demand and solve the issues mentioned above. Otherwise, healthcare systems won’t be able to exchange it correctly.
Precursors of FHIR — Why Earlier Standards Weren’t Good Enough
Standardizing healthcare data is a challenge because the domain is very complex, and data can have multiple contexts. For example, a diagnosis can have different attributes and use diverse code lists. Yet, standards are essential for interoperability in scale.
One of the organizations that develop standards is HL7. So, let’s see what it did previously and why earlier data interoperability standards could not satisfy the industry’s needs.
What is HL7?
HL7 is a non-profit organization accredited by the American National Standards Institute (ANSI), which develops standards and provides a framework for healthcare data interoperability. The standards describe how the information can be shared, retrieved, exchanged, and integrated to support the delivery and management of healthcare services. It affiliates with countries all over the world.
Standards provided by HL7
There are three primary interoperability standards in use: V2, CDA, and FHIR. There’s also V3, but it’s less widely used.
Let’s take a closer look at the standards preceding FHIR and their limitations.
HL7 Version 2 (V2) is a standard for messaging that facilitates data exchange between systems. It was created in the 1980s and is still widely used by healthcare organizations and IT vendors. However, this standard has a few logical gaps:
- It allows for too much optionality and ambiguity.
- It’s generic and doesn’t provide constrictions for specific-use cases.
- There are gaps and overlaps in the standard.
- Conformance is often not specific.
- V2 requires site-specific installation parameters and coding.
- There’s a lot of variance in the installation that’s not fully specified.
Since there is variance and limitation with V2, HL7 devised Version 3 (V3), which is more strict than the previous version. Unlike V2, V3 is based on XML and defines two types of objects: messages and documents. In the US, V3 adoption is slow, but some of its documents have been successful worldwide. The most notable is the Clinical Document Architecture (CDA).
CDA is a standard for clinical document markup based on XML. While it specifies the semantics and encoding of clinical statements, it also has some limitations:
- It doesn’t offer rules for transmission.
- It’s not constrained enough to represent specific-use cases of document types. With CDA, a healthcare system gets a structured document ready for exchange with another healthcare system.
Both V2 and CDA aren’t that easy to learn, with an almost flat learning curve. For example, earlier HL7 V2 isn’t human-readable and requires a lot of training for you to start developing with it. CDA utilizes read-only mode and large documents. It also doesn’t have modularity.
Thus, earlier standards:
- Are too generic (like CDA); result in everyone implementing it a bit differently.
- Are too strict (like V3); don’t cover all the use cases.
- Have too much variance and too many logical gaps (like V2).
Any extreme ends up with customizations that defeat interoperability. FHIR should counteract that.
Let’s look at FHIR in more detail.
Increase your Interoperability of Healthcare Data
Read about our FHIR solutions – get Kodjin Interoperability White Paper
FHIR — Is It the Right Solution for Interoperability?
FHIR was developed to answer the issues that surfaced from previous standards. What is it capable of that the other standards are not? Is FHIR a better solution? Let’s try to answer these questions.
The inceptive idea of FHIR can be attributed to an active volunteer at HL7 — Grahame Grieve. Then, it was actualized by HL7 to connect the different entities that use healthcare data and allow a smooth transfer via an API.
Domain experts that form various FHIR workgroups (e.g., financial, administrative, clinical) decide what data to define and how it should look.
Standards provided by HL7
FHIR is organized by resources — small independent components that can be independently queried, updated, extended, or adopted. Some examples are patient, procedure, and medication.
Similar to V2 segments, each resource can act as a stand-alone so that a system can interact with them independently. But they can also be linked together. Each resource has a human-readable text representation.
Resources are designed with the 80/20 rule in mind: focus on the 20% of requirements that satisfy 80% of the interoperability needs. The remaining 20% of needs have customizations to adapt the common, somewhat generic resources as needed for specific-use case requirements.
FHIR technology
HL7 took a fresh approach to standardization based on how web apps are built, so FHIR is designed for the web. FHIR uses web technologies:
- FHIR resources are formatted in XML or JSON formats that are commonly used in web communication.
- FHIR APIs are REST-full APIs that use the HTTP protocol — also common on the web.
- Every resource has a predictable web URL.
- For security, FHIR uses the OAUTH2 standard.
Using such technologies means that developers don’t need much time to get started with the standard, unlike previous versions.
FHIR implementation
FHIR is designed to be easy and fast to implement because it has implementation libraries in many programming languages (e.g., Python, JavaScript, C#, .NET). Many resources are free and readily available in the XML and JSON formats, as well as free test servers. It also includes V2 and V3 mapping.
FHIR has also achieved community support that offers professional events and online communication.
Great!
Our team we’ll be glad to share our expertise with you via email
So, is FHIR better than its predecessors?
Data can and should be customized to ensure interoperability but in a standard way. FHIR does just that. It deals with the complexity of the healthcare domain by allowing you to customize healthcare data in a standard way.
The overarching idea of FHIR is to give users just enough freedom to solve cases within the standard’s framework by using profiles, pluggable terminologies, and extensions.
FHIR is not too strict — it provides options for describing data. It doesn’t cause variance that could lead to misinterpretation.
FHIR’s Benefits for Patients, Care Providers, Insurers, and Governments
The main benefit of FHIR is that it provides interoperability for healthcare systems. What does this mean for its users?
The vision of interroperable health IT – imagine this…
- Available information supports improved care. FHIR allows for creating personal health records (PHR) which ensure:
- Better coordination among caregivers
- Availability of more complete data to aid clinical decisions
- Availability of data to more participants in the care process
- Possibility to customize treatments based on PHR
- Easier selection of insurers
- Patient and caregiver engagement. FHIR simplifies access to patient data stored in different systems—an essential for the US healthcare system as the federal government requires all healthcare providers to grant patients access to their data. For FHIR, this means patients can access their data, and caregivers can contribute data and access it on time.
- More efficient care, more value. FHIR ensures smoother workflows, fewer delays, and less redundant work.
- Data is available to improve population and public health. In a national context, government agencies can access public records to be better informed about the population’s health to find ways for improvement. In fact, CMS recommends FHIR as a best practice for payers and app developers.
Conclusion
Achieving interoperability in healthcare comes with a set of challenges, and it’s only possible if data is structured and organized according to specific standards. Despite the complexity and hardships, implementing the standards is the only way to go if you want to meet the increasing demands towards healthcare systems.
Implementation can become less daunting, thanks to the FHIR standard. Though only 24% of US healthcare stakeholders currently use APIs, 90% believe they are critical for the future of healthcare and estimate that FHIR will be widespread by 2024. Currently, even industry giants like Microsoft and Apple use the standard. Example: Apple’s Health Records app.
FHIR provides unification and structure to data and simplifies its sharing between healthcare entities and patients. It eliminates risks around data duplication, misinterpretation of diagnoses, reduces costs, simplifies patient management, and improves treatment.
If you want to implement FHIR and utilize its benefits, Edenlab is an excellent option. We have already implemented FHIR systems with over 36,5 million accounts and worked for the Ministry of Health of Ukraine, Turbota, and Heals, just to name a few of our clients.
