Introduction
Are you struggling with a legacy healthcare records system that isn’t Fast Healthcare Interoperability Resources (FHIR) compliant?
If so, in this guide, we will help you assess whether an FHIR facade is right for you by looking at:
- Issues and Challenges
- Usage and Benefits
- Pros and Cons
- Implementation Options
We’ve helped a large variety of worldwide customers become FHIR-compliant. We’ll help you determine if an FHIR facade is right for you.
Consider an FHIR Facade
Healthcare applications need to send and receive data in different formats. No two internal data models of any healthcare applications are precisely the same. The underlying data models are always different. Yet, it is important to standardize incoming and outgoing message formats. HL7 FHIR provided this standard for electronic healthcare information exchange.
Why would a company consider using an FHIR facade?
Many companies cannot make a full-fledged transition to the FHIR standard.
This is often due to the complexity of their legacy systems and the risks involved with converting them to the FHIR standard. One solution is to build an FHIR facade that works as a “wrapper” around the legacy non-FHIR system. This FHIR wrapper exposes an FHIR-compliant interface to the outside world. The FHIR facade connects to the legacy system’s storage. In essence, this creates an FHIR interface for the legacy database of healthcare records.
How does an FHIR facade work?
An FHIR facade works by transforming a legacy format into the FHIR standard. To the outside world, it is as if the legacy system was built based on the FHIR standard. An FHIR facade converts formats for retrieving information from the legacy system and saving information to the legacy system. The facade supports both requests for retrieving information in FHIR format and requests to store information that is already in the FHIR standard. Also, the information being retrieved could be from local or remote data sources, so it could be a facade for remote FHIR servers as well.
Issues & Challenges
As mentioned, it may be impossible for companies to make a full-fledged transition to the FHIR standard. Many reasons may block them from making the change, such as:
- The legacy system is too complex.
- The risk of making changes to the legacy is too great, as they cannot afford outages.
- The staff is no longer capable of making changes to the legacy system.
- The data model of the legacy application cannot be changed to support FHIR.
Reports show that legacy systems burden organizations, causing many to spend 80% of their IT development budgets on support of legacy systems just to “keep the lights on.” They cannot consider making changes and putting their businesses at risk. Even wrapping their legacy databases with an FHIR facade may be beyond their capabilities.
Usage & Benefits of an FHIR Facade
Clearly, there must be a use case for the FHIR facade. First, we mentioned integration with a legacy back-end system; this is the most obvious usage for an FHIR facade, which acts as a “wrapper” around the non-FHIR system and exposes an FHIR-compliant API to the outside world. You might think of this as creating an FHIR interface directly on the legacy system. Depending on the request, the API layer intercepts incoming requests in the FHIR format and retrieves the appropriate information from the legacy database or stores the appropriate information.
There is an even more important benefit of an FHIR facade. The FHIR standard changes on a regular basis. It is not reasonable to consider changing back-end systems at the same rate as the FHIR standard changes. An FHIR facade insulates back-end systems from changes in the FHIR standard. The facade is updated to follow the appropriate FHIR standards. The API and conversions for the legacy system are updated.
In this way, the FHIR facade allows access to information from other applications. Healthcare record information can be accessed by external applications that are enabled to query via FHIR. Besides, information and healthcare records can be shared across multiple systems based on the FHIR standard.
Even if the back-end systems are not FHIR-compliant, an FHIR facade will provide a mechanism for systems to exchange or share information, allowing for a combined view of healthcare records based on systems that have an FHIR facade or are FHIR-compliant.
Finally, legacy systems typically do not support new interoperability standards like FHIR, but the vast majority of healthcare records are stored in legacy systems. To enable access to historical healthcare records, one solution is to incorporate an FHIR facade connected to the system’s historical storage, creating an FHIR interface for the legacy database of historical healthcare records.
Pros and Cons of an FHIR facade
The advantages of FHIR should be obvious. By implementing an FHIR facade, providers of healthcare data can ease the implementation of FHIR compatibility.
FHIR provides a single standardized format for data exchange. This means a single external API can be ensured to be up-to-date with the latest standards. A single external API means that back-end healthcare record systems avoid being updated for each change in standards or compliance requirements. Subsequently, this lowers IT costs for support and maintenance.
Additionally, an FHIR facade can be connected across several back-end systems, providing a single view of healthcare records. Disparate systems can appear as a single integrated whole by combining information behind the FHIR facade.
Patients, healthcare providers, and insurers will benefit from having a single view across many sources of healthcare records. Imagine having a single, lifetime view of all healthcare ever provided to an individual, from birth to death, including the integration of patient-generated healthcare data from smart watches and other personal medical devices. These benefits will result in better diagnosis, safer emergency medical care, improved medium-term follow-up, and appropriate long-term care.As mentioned, there are challenges to building an FHIR facade. Legacy systems are complex; it can be challenging to connect to the information required in the FHIR facade from a legacy system. Some organizations cannot devote resources or budgets to create FHIR “wrappers” for their legacy systems. Working with a legacy system is always risky; the majority of the “outages” we hear about among financial service organizations are those burdened with legacy systems in a similar manner to healthcare organizations.
FHIR Facade Implementation Options
There are various options regarding how to implement an FHIR facade. As mentioned, you should consider the requirements of the interface:
- Reading data, also called client read-only
- Adding/updating data, referred to as client read-write
Besides the implementation options, there are other questions to be addressed:
- How will your FHIR facade be used: is it for online application integration or batch-mode integration?
- What are the constraints related to security? How will you protect an existing internal system from intrusion and exploits?
- What about performance? Will your legacy system support simultaneous access from several remote systems? Can it support concurrent database updates?
One approach is to translate FHIR API calls to queries on the underlying healthcare records database. This creates an FHIR facade for your legacy database of healthcare records. The challenge is that you will need a good understanding of your legacy database so you can map your internal data model into the FHIR model.
Clearly, there are numerous implementation challenges in building your own FHIR facade.
Alternatives
Obviously, you can construct your own FHIR-compliant APIs, but isn’t that like reinventing the wheel? The experts have already developed FHIR facades. Focus your efforts on integrating these with your back-end legacy systems, rather than building an FHIR facade from scratch.
Consider using an expert who has already dealt with the requirements of securely retrieving electronic healthcare records through an FHIR facade. They can ensure that the appropriate FHIR-compliant information is obtained and that you are compliant with the FHIR standard.
Also, this will allow data to only be converted “on demand” and avoid keeping a copy of existing data in FHIR format. You might not want to expose all of your data to external FHIR clients; an FHIR facade allows you to expose only certain parts of your data.
Conclusion
Edenlab is a provider of FHIR facades and custom solutions focused on healthcare data interoperability. Medtech is Edenlab’s core domain, providing extensive expertise in interoperability with the HL7 FHIR standard. Edenlab has helped healthcare organizations, application developers, and integrators build FHIR-compliant solutions with their expertise in FHIR facade development.
In addition, Edenlab’s Kodjin FHIR server provides a low-code/no-code approach to ease the user’s usage of the HL7 FHIR specification. The FHIR server uses a modern microservices architecture to ensure future-proofing of your FHIR facade implementation. The solution is adapted to specific business problems through configuration without coding. Feel free to contact us for details.
