FHIR Exchange Paradigms

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).

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. The API describes the FHIR resources as a set of operations (known as "interactions") on resources where individual resource instances are managed in collections by their type. Servers can choose which of these interactions are made available and which resource types they support. 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.

The pattern aims to support all RESTful FHIR interaction types Create, Read, Update and Delete operations, along with Search and Execute (Operations). One of the main benefits of using REST is that it leads to more scalable development and faster implementation. It also leverages modern web technologies (HTTPS, OAUTH2, OpenID, SMART on FHIR).

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). 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.

Possible Actions:

• Read/Search (e.g., Retrieve Condition record for a Patient)
• Create (e.g., Provider creating Allergy record for a Patient)
• Update (e.g., Updating Patient demographic details)
• Delete (e.g., Deleting a duplicate resource on a server)

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. Some of the exchange paradigms that support multiple-resource exchange are 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.
• Execute Transactions: Bundling the resources together and sending them to the server. These can be multiple actions on multiple resources of different types. However, if one of them is not posted successfully or fails then the transaction will be rolled back. The actions must be performed in a specific order based on the type of action. For example – a lab system may use transaction mode when they to send multiple resources that would otherwise require multiple interactions (e.g., Observations and DiagnosticReport for a Patient).
• Batches: In a batch, all the interactions are considered to be independent - some might succeed, and others might fail. There cannot be any references between resources manipulated in different Bundle entries such that failure of one action would cause a different action to be invalid. There should be no dependency on the order in which the actions are performed. An example of a Batch request is an application requesting the following details on a patient as batched requests: current medications, current allergies, current problems, and statements of medications not taken.

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. Operations are also relevant in cases where the intended purpose is to cause side effects such as the modification of existing resources, or creation of new resources.

Operations make use of a special infrastructure resource called Parameters that act as predictable inputs that guide the behaviour of the executing system. Parameters are also used to convey the expected outputs of the operation.

One example of a FHIR Defined Operation that makes use of Parameters is the $everything operation, which is performed on a Patient endpoint and allows the requester to supply parameters that change the period, type, and count of the resources returned in the searchset Bundle.

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.).