📖 Common ways to exchange FHIR information
FHIR information can move between systems in several ways. These are often called exchange approaches or exchange paradigms. The categories overlap, and the specification evolves, so there is no fixed number that learners need to memorize.
RESTful API
The FHIR RESTful API is a common way for a client to create, read,
update, search for, or delete resources on a FHIR server using HTTP. A
stored resource instance is typically addressed by its resource type
and logical id, for example Patient/123.
Not every resource in every exchange has its own resolvable server URL. Resources can also travel inside documents, messages, and other Bundles.
Messaging
FHIR messaging exchanges a message Bundle about an event, such as a notification that something happened. The receiving system processes the message according to the agreed message rules.
A message Bundle is not the same as a transaction Bundle. Messaging represents an event exchange; a transaction is a RESTful request that asks a server to process several operations atomically.
Documents
A FHIR document is a persistent, self-contained clinical statement assembled as a document Bundle. It is intended to be understood as a complete clinical document, such as a discharge summary, rather than as unrelated resources that happen to travel together.
Operations and services
FHIR also defines named operations for activities that do not fit a simple create, read, update, or delete interaction. Examples include validation and terminology operations. A project can use FHIR resources as the request and response data for a wider service as well.
Subscriptions
A client can create a subscription to ask for notifications when specified events occur. For example, a system might request a notification when a relevant resource changes. The exact notification channel and payload depend on the FHIR version and implementation guide.
Batch and transaction
Batch and transaction are RESTful interactions that send multiple requests together in one Bundle:
- a batch contains independent requests; each request succeeds or fails on its own; and
- a transaction is atomic: either every requested change succeeds, or the server rejects the transaction as a whole.
These are useful processing patterns, but they should not be confused with FHIR messaging.