FHIR Exchange Paradigms

This IG page includes summarized guidance derived from the base FHIR specification. Please note that this guidance is intended to be informative and provide a simplified overview of the information contained in the base specification. In the event of any discrepancies or conflicts between the summary presented here and the base specification, the base specification shall prevail. Users are encouraged to refer to the base FHIR specification for detailed and complete guidance.

FHIR supports a number of exchange paradigms that enable implementers with varying architectures and use case needs to exchange healthcare information.

The FHIR Base Specification includes detailed guidance on each of the methods summarized below. The additional exchange mechanisms are defined on FHIR R5's page - Approaches to Exchanging FHIR Data that lists many ways that data can be shared in FHIR.

Note: Implementers are encouraged to review the FHIR R5 guidance, particularly the decision tree for choosing an approach to exchange, which provides diagrammed decision points and their respective approaches (e.g., REST create, Batch Bundle, GraphQL search, Polling, Subscriptions).

Exchange Paradigm Description
RESTful API Involves the use of a client/server API that allows FHIR resources to be interacted with (Create, Read, Update, Delete, Search, Execute Operations)
Document Exchange Framework Intended for exchange of an immutable set of resources with a fixed presentation that is authored and/or attested by humans, organizations and devices. While this framework is not mutually exclusive of the RESTful approach - the framework has a particular focus on persistence in document storage and management systems
Messaging Exchange Framework Supports exchange between systems by sending routed messages from system to system. This exchange can be implemented on the RESTful API or using some other messaging technology
Services Framework Provides context regarding the use of FHIR (and particularly the RESTful API) in a wider enterprise architecture

FHIR also acknowledges the Database / Persistent Store of FHIR resources has the potential as a framework to drive standardization in. However, further guidance from FHIR is not available at this time.

CA:FeX Exchange Patterns

As an iterative specification, intended to assist the Canadian market in adopting best practices for implementing FHIR, CA:FeX is expected to grow over time to highlight guidance for each of the exchange paradigms below. However, aspects of RESTful API exchange & implementation of certain functional operations are in the Scope of the current version of this guide.

Exchanging with RESTful API

Most implementers focus on RESTful API where transactions are performed directly on the server resource using an HTTP request/response. Servers SHALL provide a Capability Statement that specifies which interactions and resources are supported. RESTful API focuses on requesting information and/or pushing information, i.e., push pattern, pull pattern, or async pattern.

Guidance on the syntax and structure of RESTful API interactions can be found on the RESTful API Interactions page of this guide.

Single Resource Exchange Framework

The simplest way of exchanging FHIR information is through the use of Create, Read, Update, Delete interactions against a FHIR instance (single resource type) as described here. In some cases, there is a requirement to perform a straightforward exchange with a single resource, for instance - the data requestors are aware of the id of the resource they want to retrieve (this id may be known because they have previously retrieved the resource and is looking for the most recent change), or data requestor creating.

Note: While the current scope of this implementation guide is RESTful API Exchange & Functional Operations, guidance on the use of RESTful APIs to exchange single resources has been broken out into a separate Data Exchange page to preserve readability.

Multiple Resources Exchange Framework

In most cases, when data is exchanged, it will be transferred as a collection of resources. These resources are bundled together in a Bundle resource, and are connected through references to make a clinical story. One of the exchange paradigms that support multiple-resource exchange, and is the focus of this guide, is explained below:

  • Exchange Documents: Creating and finding FHIR Document. The focus of document exchange is on human readability and persistence. Examples of documents include discharge summaries, history & physical notes, medical imaging reports, patient summaries, and more.

Note: While the current scope of this implementation guide is RESTful API Exchange & Functional Operations, guidance on the use of RESTful APIs to exchange documents has been broken out into a separate Document Exchange page to preserve readability.

Exchanging with FHIR Operations

It is possible to extend the basic interactions (e.g. POST, GET, PUT, DELETE) with a custom-defined operation. FHIR Operations are often used where the server needs to play an active role in formulating the content of the response, not merely return existing information.

The operations recommended in this guide can be found on the Operations page.

Other Exchange Patterns (Out-Of-Scope)

There are other advanced levels of exchange patterns that are out of current scope, such as non-RESTful document exchange, Messaging, Polling, Subscription, and advanced level of searches (GraphQL, CQL Search, etc.).