The API Gateway (or Proxy) pattern is popular in modern architecture. In this pattern, the API Gateway component acts as a single entry point and middleware between client applications and backend services. It provides various API management capabilities such as routing, request composition, audit and security, and more.

This article describes the potential benefits of implementing this pattern with FHIR Server-based solutions.

What is the API Gateway Pattern?

Microservice Architecture breaks down applications into smaller, independent services, each with its API. It improves modularity and flexibility at the cost of increased complexity in API management. The API Gateway pattern addresses this challenge by providing a central point of control for all the APIs across all the microservices.

Several solutions, both commercial and open-source, are available for implementing this pattern. Popular examples include Apigee, Kong, Nginx, and AWS API Gateway. Some solutions are relatively simple and function as API proxies, while others offer more comprehensive features and are referred to as API Management Platforms. However, for the sake of this article, we’ll use the term "API Gateway" to encompass all such solutions.

What are the good use cases for leveraging this pattern with FHIR API

FHIR standardizes healthcare data exchange, while API Gateways enhance FHIR APIs by:

1. Centralizaing API that abstracts internal service complexity.
2. Protecting public FHIR APIs from common web threats.
3. Enabling the addition of custom logic before requests reach the FHIR server.

This combination creates a robust and flexible healthcare data infrastructure.

Сentralized API that abstracts internal service complexity 

Problem

We have a complex backend solution composed of multiple services, and we need to allow access from web and mobile clients. If each client directly interacts with each service using specific hostnames and ports, any changes to the backend architecture would require updating every client, making it cumbersome to manage. How can we expose these backend services to clients in a way that hides the complexity and avoids the need to share too much internal information?

Solution

Implement an API Gateway that is a single entry point for all the clients.

• API Gateway provides a central stable interface for clients, allowing changes to backend architecture without needing to update client configurations. Adhering to the FHIR standard simplifies the process of creating and maintaining this stable interface.
• It routes the request to the correct service and helps balance the workload across multiple instances of a service, improving reliability and scalability.
• API Gateway centralizes and streamlines the Access Control by integrating with Identity and Access Management (IAM) Provider.

Protecting public FHIR API from web threats

Problem

Provide robust and secure access to the FHIR API to third-party developers or applications over the internet. How can we mitigate the risk of the common web threats in this case?

Solution

Implement an API Gateway to manage access and provide protection against web threats.

• The API Gateway can mitigate distributed denial-of-service (DDoS) attacks and other abuse by rate limiting and quotes, which restricts the number of requests a client can make to an API in a given period. 
• It can control access to APIs by allowing or denying requests from specific IP addresses or ranges, enhancing security by restricting access to trusted networks.
• The API Gateway also may be integrated with WAF (Web Application Firewall), the component specifically designed to detect and prevent various types of cyberattacks that target web applications.

Adding Custom Logic in front of FHIR

Problem

We need to implement additional business logic that goes beyond the native capabilities of the FHIR server. This includes handling complex authorization rules that rely on external data not stored within the FHIR server or applying custom routing rules, such as replicating requests to another legacy system during a migration process.

How can we gain full control over all requests processed by the FHIR server to implement these customizations effectively?

Solution

Implement a custom middleware component that sits in front of the FHIR server, allowing you to intercept and process all incoming requests, enabling the execution of your own business logic before they reach the FHIR server.

• The API Gateway can manage complex custom authentication and authorization workflows, including introspection of opaque tokens and using external data to make the authorization decisions.
• API Gateway can inspect, route, or block requests based on specific rules or conditions before they hit the FHIR server. For example, it may only allow certain types of queries or filter out sensitive information based on user roles.
• Requests can be directed to specific backend services or even be put to intermediate queue storage depending on the type of data or request, allowing the API Gateway to act as a smart router and handle complex scenarios, e.g. migration from one FHIR server to another. 

Using Aibox as API Gateway

Problem

We need to add custom operations to Aidbox using a programming language we already know. By avoiding introducing additional components into the architecture, we aim to minimize infrastructure overhead.

Solution

Use  Aidbox Apps functionality.

• Aidbox acts as a proxy, it handles authentication and authorization and routes the request to the custom App code.
• Multiple programming languages in the Aidbox SDK support Aidbox Apps.

Summary

Implementing API Gateway pattern offers powerful capabilities and you can even think of combining multiple patterns that we discussed. This could result in multiple layers of components processing each incoming request, adding more steps to the request flow.

However, it's essential to consider the potential drawbacks of implementing an API Gateway pattern:

• Increased complexity: Introducing an API Gateway adds an extra component to the architecture, requiring additional expertise for configuration, monitoring, and ensuring high availability.
• Performance impact: An API Gateway introduces an extra network hop, potentially increasing latency. In performance-sensitive systems, this added layer might become a bottleneck.
• More complex debugging: With an additional layer between clients and services, diagnosing issues can become more challenging, as problems could stem from the gateway or the underlying services.
• Customization limitations: Off-the-shelf API Gateway solutions may not provide the customization needed for certain specialized use cases.

When deciding whether to implement an API Gateway, carefully evaluate its pros and cons for your specific situation. The decision should be based on your system's architecture, requirements, team structure, and long-term goals.

Would you like to discuss your particular use case? Please don't hesitate to contact us. We're happy to help.

Aidbox FHIR server can be deployed locally in just 90 seconds or accessed even faster through a free cloud Sandbox, making it an ideal platform for learning and development.  Free Development licenses are also available.

Author:
Aleksandr Kislitsyn,
Solution Architect at Health Samurai