In this digital era, every individual wants to see updated health data as he/she moves around the healthcare ecosystem i.e. providers, patients and caregivers should have the data available, discoverable and easily understandable. Furthermore, to support business intelligence, analytics, clinical decision support and other machine-based processing, the data must be structured and standardized in a way that supports healthcare digitization. This has led to a growing pressure to broaden the scope of interoperability across organizations, handheld devices, mobile & cloud based applications; to ease the implementation process to ensure faster integration and enable flexible custom workflows.
With the new Medicare Access & CHIP Reauthorization Act of 2015 (MACRA) which reforms Medicare payment, interoperability is a critical element of any delivery system reform vision where electronic health information is unlocked and securely accessible to achieve the MACRA goal set by CMS for better care, smarter spending and healthier people.
When one hears interoperability, HL7 is the word that comes to mind.
So where does the problem lie?
- Almost 20 years old, HL7 V2 does not provide support to modern platforms for internal processing and manipulation of healthcare data. The flat file approach is too old school, hard to customize and extend as needed by the healthcare industry today.
- The implementation required for HL7 V3 is more time consuming and complex due to many customized tools. It has a very steep learning curve and as of now, has limited market adoption.
- A standard that emerged with EHR Incentive Program – CDA implementation was mandatory but it requires an extensive knowledge of RIM. Extensibility was offered but it required a lot of pre-processing. Every vendor in the market has its own style for extensions leading to errors while incorporating CDA from a different EHR vendor.
The HL7 organization wanted to come up with a new standard framework for exchanging healthcare information that combines the best features of HL7 V2, V3 and CDA.
Reasons driving the change are:
- Interoperability requirements are increasing by leaps and bounds to
- Increase collaborative care – need for coordination
- Adapt to changing payment models
- Aid patient engagement via patient portals
- Improve clinical decision support within EHR
- Provide access to primary care/community data
- Make population health analytics possible
- Need for real time access (API) E.g. Mobile devices
- Increase in the amount, type and source of data
- Analytics- population health solutions dictating the need to collect from many data sources
This necessitates the need for a next generation healthcare interoperable standard that can be used in electronic exchange of patient health information across heterogeneous systems by combining the best features of HL7v2, v3 and CDA.
This latest standard from HL7 organization that aims to address this need is “FHIR”.
FHIR – The nextgen healthcare interoperable standard
FHIR pronounced as ‘Fire, stands for
F – Fast (to design and implement)
H – Healthcare
I – Interoperability
R – Resources (Building blocks)
FHIR defines a set of “Resources” that represent granular clinical concepts. The resources can be managed in isolation, or aggregated into complex documents. Technically, FHIR is designed for the web; the resources are based on simple XML or JSON structures, with an http-based RESTful protocol where each resource has predictable URL.
The philosophy behind FHIR is to build a base set of resources that, either by themselves or when combined, satisfy the majority of common healthcare use cases.FHIR resources aim to define the information content and structure for the core information set that is shared by most implementations. There is a built-in extension mechanism that provides support for the remaining content.
Latest posts by Kiran Sangem (see all)
- Part 3 – FHIR: Why every EHR should follow the FHIR path - October 28, 2016