Confused by FHIR server options? This guide takes you through the common ones—Facade, Sync and Hybrid, and tells you what works.
Fast Healthcare Interoperability Resources or FHIR is a standard for the secure electronic exchange of healthcare data. An essential goal of FHIR is healthcare data interoperability, enabling building healthcare systems for the future. In this previous article, we do a deep dive into FHIR and how to make sense of it.
Additionally, FHIR is also a data standard. FHIR defines the organization of healthcare data into structured Resources, each of which can be exchanged independently or in combination with other resources. Patient, Observation, and Medication are examples of FHIR Resources. RESTful FHIR servers are an integral part of interoperable architectures built on FHIR, and there are several patterns available for implementing them.
In this article we will look at three main approaches to implementing RESTful FHIR servers - Facade, Synchronization and Hybrid. We’ll also discuss two more approaches to information exchange defined in FHIR, Documents and Messaging. Let’s begin by understanding what FHIR’s RESTful API looks like.
FHIR's RESTful APIs in practice#
FHIR uses REST principles for data exchange and management through APIs. This way, applications can use the FHIR API to integrate with and use healthcare data.
This is basically how a RESTful server operates,
REST requests are HTTP requests of the form VERB url, while Responses can be in json or xml formats. For example, the client makes a HTTP request, GET /Patient/123 and the FHIR server responds with the resource, i.e. Patient with id as 123, in json or xml format.
FHIR has detailed documentation for its RESTful APIs. It supports all HTTP methods - GET, POST, PUT, DELETE and PATCH - although PATCH is rarely used.
- GET: retrieve one or many resources
- POST: create a new resource
- PUT: update an existing resource
- DELETE: remove a resource
- PATCH: apply partial updates
Postman is a popular tool used for testing RESTful APIs, and there are also specific libraries available in all major programming languages e.g. HAPI FHIR. Open source and commercial FHIR Servers are also available for implementation including HAPI FHIR, Aidbox, AWS HealthLake and Google Cloud Healthcare API. In earlier tutorials, we’ve explored FHIR REST APIs hands-on in Python and Java.
Three common patterns for building FHIR servers#
FHIR Servers can be implemented in multiple ways, we’ll be exploring Facade, Synchronization and Hybrid.
Facade pattern#
The facade acts as an intermediary between HTTP requests and the existing database (this could be SQL/NoSQL). It doesn’t store FHIR data itself, but it queries the underlying database and converts its response to a FHIR resource.
This approach can be useful if there are preexisting EHR databases in place, and you only want to expose some of that data via FHIR.
Synchronization pattern#
In a Synchronization pattern, data is synchronized between an existing database and a fully FHIR-compliant database server. This can be implemented via FHIR change data capture with open source tools like Debezium. In this case however, a Client can only read data from the FHIR server, as write operations can cause data inconsistencies.
This approach is helpful for providing read-only access to data, i.e. summaries, reports for patients etc.
Hybrid pattern#
The Hybrid pattern combines the best of both paradigms, where a FHIR facade is used for write operations and a synchronized FHIR server is used to execute read operations. This approach can be helpful when both real-time updates to data and highly available read access to FHIR resources is required.
Other exchange paradigms#
Documents#
Another exchange paradigm defined in FHIR are Documents. Documents are represented by a Bundle of type document that starts with a Composition. It also additionally consists of references to specific frozen versions of other FHIR resources such as Patient, Observation and Encounter.
The International Patient Summary(IPS) is a single document that bundles essential health data for a patient including condition, allergies, medication etc.
Documents are useful for exchanging one-time documents such as discharge summaries or referral documents.
Messages#
Messaging in FHIR is especially useful for multi-step request/response workflows. This is made possible through using a Bundle of type message and MessageHeader, MessageDefinition and other referenced resources. An example of such a workflow is for prior authorization, where health insurance companies use messaging during claims processing.
Summary
As a data standard and a data exchange mechanism, FHIR is a powerful tool in the quest for interoperability. Apart from understanding different FHIR resources and their structures, it is also useful to know the different data exchange mechanisms FHIR supports. This includes REST API, Documents and Messaging.
In the case of implementing RESTful FHIR servers, Facade, Synchronization and Hybrid patterns can be used depending on your specific requirements. This will enable your EHR to communicate with applications through REST APIs. Documents, on the other hand, are useful for one-time or low frequency communication, e.g. in the case of discharge summaries. For multi-step request and response workflows Messages would be the right choice, e.g. in claims processing.
Each approach has its strengths, and it is crucial to evaluate your requirements and existing infrastructure in order to make an informed decision.
Ready to dive deeper into FHIR? Join our free webinar where we will answer your burning FHIR questions!