by: Alex Baumberg, Dmitry Baranov

In this article, we will share our experience of FHIR® façade implementation using “Intersystems IRIS for Health” (henceforth: “InterSystems IRIS”) platform in Leumit (one of the four leading HMO’s in Israel), managed by Outburn LTD - leading Israeli company helping healthcare organization become FHIR-complaint. 

First, let’s briefly define what is a FHIR façade:

A FHIR Facade is a layer of software that is located between a healthcare organization's internal data systems and external FHIR® clients. It serves as an interface that shields the internal systems from the complexity of FHIR while making it easier to exchange data with other systems that support the FHIR standard.

A FHIR Facade acts as a mediator that translates data from the internal systems into a FHIR-compliant format, and vice versa. This allows for seamless exchange of data between different healthcare organizations that use FHIR. It simplifies the process of integrating new FHIR services and makes it easier to manage and maintain the data exchange process.

In Outburn, we strongly believe in a phased implementation approach for healthcare organization entering the FHIR world, utilizing the following steps:

1. The organization adopts the FHIR façade approach for its first projects. Thus, the organization gains its first experience with the FHIR standard and can decide on the next steps with little risk and without dramatic changes related to its data management.
2. The organization may consider moving forward to a Hybrid approach – a transactional phase between FHIR façade and FHIR Server. At this point, some business entities (e.g. Patient) are translated into FHIR resources and stored persistently within the FHIR repository, while others are still created dynamically, according to project requirements.
3. Eventually, the organization creates and stores all data created by organizational healthcare systems as FHIR resources within the FHIR Server. This is a significant change in most organizations data management approach.

InterSystems IRIS provides a built-in FHIR Facade service that enables you to expose your data quickly and easily as FHIR resources. The FHIR Facade service is implemented as a set of classes that map your existing data model to FHIR resources. This means that you don't need to create and maintain a separate FHIR server, and can instead use the InterSystems IRIS instance to expose your data via FHIR.

InterSystems IRIS includes the following FHIR technologies:

• Customizable FHIR Server: A customizable FHIR server is an application that receives and processes FHIR requests while leveraging an architecture capable of storing and retrieving FHIR resources from an internal Resource Repository. Therefore, the FHIR Server can be customized and adapted to specific needs and deployment architecture, e.g., FHIR façade. In fact, there is no significant difference between the FHIR Server and FHIR façade in terms of deployment architecture except for persistence resources storage within the internal repository.

• FHIR Interoperability Adapter: for when your application must receive and process FHIR requests but does not need to store or retrieve resources from internal storage (nor will it need in the future). In such cases, your best option is to use the FHIR Interoperability Adapter, rather than a FHIR server. The Adapter installs the components needed for handling FHIR requests without installing the internal architecture of a FHIR server. The FHIR Interoperability Adapter always uses an interoperability production to process requests.

Deployment method considerations:

Considering both options in the initial phase of the Leumit IRIS deployment, we decided to deploy a Customizable FHIR Server technology. This will allow the seamless transition from FHIR façade to a FHIR Server, by enabling Resource repository for future persistent resources storage. This decision is based on the natural evolution of the FHIR deployment strategy within healthcare organizations: from FHIR façade towards a FHIR Server, or a hybrid architecture, which combines both approaches: some resources (e.g., Patient) are stored and managed within the repository, while others are created dynamically, as a result of the transformation of source system responses (e.g., REST Interface).

Project Overview:

The two following use cases were developed and deployed using InterSystems IRIS Customizable FHIR Server technology.

Coverage Eligibility Workflow (Tofes17)

In this project, we implemented a FHIR facade for an internal REST service, which receives information about the patient's coverage (Tofes17) from the Leumit source system managing coverage information.

The entire workflow aims to get coverage approval/refusal for a specific service, initiated by a Leumit member wishing to receive a medical service at the hospital.

Request for coverage approval initiated by the Client (hospital): CoverageEligibilityRequest (Henceforth: “Request”), contains patient identification information, an array of service codes for approval, and a target appointment date. According to the specification, the request submitted from the hospital may be a single batch of requests bundled into the Bundle resource.

The response is always constructed from two FHIR resources in a Bundle resource:

1. provides eligibility (approval, refusal) and plan details from the Request resource; and
2. a Coverage resource contains coverage-related information (e.g., coverage identifier, type, valid period etc.).

In case of a critical error occurrence, an OperationOutcome resource is sent back as a response to the Client. The timeout event (http: 408) is the only event specified as a possible exception.

The Request and CoverageEligibilityResponse (“Response”) are defined as event resources from a FHIR workflow perspective. The Response resource provides eligibility and plan details from processing a Request resource. According to the FHIR specs, submission of the Request is managed by the $submit operation, defined as "submitting an Request for assessment to the FHIR façade endpoint”. The output of a $submit operation is either a single Response, a Bundle, or an OperationOutcome resource.

For deploying the workflow, we were guided by the FHIR operations implementation guide. InterSystems IRIS provides excellent capabilities for programming custom operation handlers, so we implemented our own $submit operation handler on the Coverage resource. The FHIR façade accepts a FHIR operation request and processes incoming FHIR request parameters. Then, it constructs parameters for another REST service, populates those parameters, and forwards the request to the internal REST service in a synchronous mode. Having received the response of the internal service, the FHIR façade converts the received data into the FHIR data format (to be more precise, a FHIR Bundle), and finally returns the response to the client.

The following diagram represents the high-level architecture:

High level, implementation diagram for Tofes17 FHIR façade project implementation.

HMO Extended coverage insurance plans national portal.

Another integration project uses IRIS’s FHIR extensibility capabilities to connect two systems. In this case, we used a different approach: The main idea was to override the behaviour of FHIR endpoint listeners, and create comprehensive architecture, enabling seamless transformation to the Hybrid solution, in which Patient resources, that were created by conversion from Leumit’s demographics database, are stored as persistent resources within the internal resource repository. In this project, a Patient resource, keeping complete demographic information, is stored within the repository for further consumption by different FHIR REST clients. Once storage of resources is enabled, data must be kept in sync between resources stored by the FHIR resource repository and the source organization’s systems. For this purpose, we are planning to build an interface which will propagate any change made within the demographic record.  

Brief explanation about the project:

The State of Israel maintains a national portal (“Har Habituach” – Hebrew for “Insurance Mountain”) that allows citizens to retrieve overall and comprehensive information about all their insurance plans, regardless of the insurer and type of insurance. The goal of our project is to provide information about extended healthcare coverage programs in HMOs in which a citizen is insured.

The request for receiving the insurance plan, initiated by the citizen, is followed by the authorization process. In fact, for the client (Har Habituach) to present the HMO coverage plan, it requires information about two business entities managed by the HMO: patient demographics, and the insurance plan.

From the FHIR perspective, the FHIR façade initiates two different REST requests to Leumit’s web services, one – a full set of demographic values which are then transformed to a Patient FHIR resource (that can be stored in the FHIR resource repository), and the other – is the insurance plan details, which are transformed to a Coverage FHIR resource. The response to the client is bundled into a Batch response Bundle holding those two FHIR resources.

Handling search requests from the Client:

Part of FHIR’s philosophy is to build a base set of resources that satisfy most common use cases. FHIR resources aim to define the information contents and structure for the core information set that is shared by most implementations. For example, a Patient FHIR resource will contain complete demographic information regardless of the client's requirements and limitations. In our case, the mandatory and regulatory requirement was to limit the set of data returned in the response.

We achieved this by adding the _elements parameter to the search parameters of the REST search query so it will limit the set of the returned elements. (e.g., _elements=identifier,birthdate,gender,name)

General implementation notes:

Regarding the solution development within the InterSystems IRIS platform, we intercept a request to the Patient endpoint and, after the validation, forward the request to another web service connected to a system that manages patient demographics and provides the data of interest to the client. Other interceptors can handle requests to Coverage, and other resources, if needed. Not every FHIR solution implementation provides such an opportunity, but InterSystems IRIS does, and such a function can be implemented within half an hour. Alternatively, a developer can easily intercept a search batch request with a Bundle inside the request body, parse the request, then get data from any external sources and from any external systems, then manually construct the response Bundle and finally send that Bundle back to the client.

The entire business process is managed by a business process engine, which is a component of the standard Intersystems IRIS for Health distribution. The business process engine provides a set of built-in classes which allow a developer to decompose a business process according to each component's responsibility. If we deal with a very complex business process, it can be designed with a graphical business process editor, which supports diagramming, so users who are familiar with the BPMN standard are sure to like the editor. The logic of simple business processes can be expressed directly in the program code.

In addition, the InterSystems IRIS library contains a set of message classes, which provide the ability for transfer of data between systems and components, as well as the possibility to serialize messages to and from XML and JSON.

All communication within a business process is accomplished with messages. To this end, the InterSystems IRIS management portal provides many tools for viewing and working with messages. Often, we have to deal with the transformation of messages of different types, and InterSystems IRIS DTL designer is yet another useful visual tool which allows a developer to design message transformations, using a graphical editor.

Intersystems IRIS provides developers with an object model of the FHIR standard, which increases development speed, and improves the quality of the code due to compile-time type checking. All the classes in the FHIR object model namespace provide built-in serialization capabilities.

High level, implementation diagram for Har Habituach project

Conclusion

Through these projects we have  concluded that the correct approach for organizations to migrate to FHIR® is through the use of the intermediate step of utilizing a FHIR façade. It is worth noting that with InterSystems IRIS for Health, both server and façade architectures are basically the same approach to implementation of the FHIR® standard in healthcare organizations, in terms of the data model – i.e., the resources. FHIR façade is a good first step, then the hybrid solution should be implemented, and finally – a full FHIR server should be the end goal. InterSystems IRIS will allow you to implement all three stages in a simple and uniform manner. It is imperative that the InterSystems IRIS integrator in your organization be well-versed in FHIR, both on the standard and its architecture.

Follow us on LinkedIn