FHIR is the next-generation standard for health care data exchange. From an implementer standpoint, FHIR acts as a data exchange mechanism supporting the following methods of exchange, RESTFUL API, Messaging, Documents, Services, and Database/Persistent Storage. The RESTFUL API specifies specific endpoints designed to enable health data interchange using healthcare domain-specific resources to support a wide range of interoperability methods. The FHIR family of standards strongly focuses on implementation, allowing fast and easy development and simple interfaces to be developed in as little as a business day.

A problem GigaTECH recently addressed was how to make proprietary data available for standard interchange. A façade structure is the architectural strategy that GigatTECH implemented to achieve this desired result. A façade is a type of middleware solution that facilitates communication between two service locations. Examples of data communications are payer database to payer database or payer database to client-side user interface. The façade receives data from a payor database and transforms it into a usable FHIR resource. The newly transformed data is housed at the façade level and is available to be accessed by either the client-side user interface or an external payer database. This data flow illustrates the façade transforming data into FHIR resources.  When the originating database is already FHIR-enabled, a façade can still be utilized to house specific data for interchange between services.

One use case for a FHIR facade is the ability to expose a personalized CarePlan based on a specific condition derived from internal proprietary claims data. To help Providers know the program exists for those patients, a FHIR façade would be setup to map information from the Payer and then transform the data into a FHIR resource. GigaTECH would develop the FHIR resource to at least have the attributes of PlanDefinition, Patient, and a CarePlan tied to a specific medical condition. When the Provider enters or opens the chart of the patient, their demographics are sent to the façade layer and that data is run against the program’s requirements (age, sex, medical condition, etc.). At the façade level, if a patient’s information matched with the specific attributes to trigger the CarePlan, the Provider would be prompted to enroll this patient in the program through a SMART of FHIR application accessible directly from the Provider’s EHR. This type of façade setup is convenient for both the Payer and the Provider because the data exchange happens in real-time and requires little to no extra input from the Provider to obtain the relevant recommendation.

Another use-case for a FHIR façade is to setup data exchange between two separate payer systems.  This type of data exchange happens frequently with patients moving insurers through different workplace or spousal changes.  GigaTECH would engage with a Payer to learn the minimal necessary demographics to be shared amongst other payers and then build a façade that would house that information as an accessible API endpoint for other payers to obtain relevant information.  The façade would be built with the ability to continuously update information and hold the most up-to-date demographics.  When a patient transitioned to a new payer, the current Payer would provide the endpoint necessary to access that patient’s information and the data exchange would be completed.  This use-case relies heavily on security considerations.  It is important to fully formulate a security strategy with the Payer and understand where, how, and when to implement security measures in the process of data exchange.

One architectural trade off using a FHIR façade to transform non-FHIR data into FHIR resources is the potential for slightly diminished performance speeds. Performance and load times are always important and apart of any build process, but if, during testing, a user was to notice any delay in the system, a mitigation strategy would be implemented to address any delays.

In summary, facades act as a type of middleware software that facilitates communication between different user interfaces. FHIR-specific facades communicate FHIR compliant resources back and forth as well as transform non-FHIR compliant data to be communicated between systems. FHIR facades are a great architectural strategy for projects that seek to accomplish system communications effectively and passively. GigaTECH has a proven history of providing these types of solutions and fully evaluating a client’s system setup to determine the best overall architectural strategy. For a more in-depth look into how GigaTECH addressed a similar problem, check out one of our recent white papers here.