This page is part of the FHIR Specification (v5.0.0-draft-final: Final QA Preview for R5 - see ballot notes). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4

Work Group FHIR Infrastructure

Standards Status: Informative

3.0 FHIR Exchange Module

3.0.1 Introduction / Index

FHIR is designed as an interface specification - it specifies the content of the data exchanged between healthcare applications, and how the exchange is implemented and managed. FHIR defines the following methods for exchanging data between systems:

• RESTful API
• Messaging
• Documents
• Services
• Database / Persistent Storage
• Subscriptions Framework

Each of these approaches can be used to exchange information, and each has its own strengths and weaknesses and applicability. Note that applications are allowed to use any other method to exchange resources; the methods described in this specification are the common methods that are used enough to justify the effort to describe or standardize their use.

The Approaches to Exchanging FHIR Data page explores the various ways of sharing FHIR content, covering the above primary mechanisms as well as variations of them, including providing guidance on how to choose the architectural approach that best suits a particular use-case.

3.0.1.1 RESTful API

Most implementers focus on RESTful API. This is a client/server API designed to follow the principles of RESTful design for Create, Read, Update and Delete operations, along with Search and Execute (Operations) support.

The RESTful API is a general-purpose interface that can be used to push and pull data between systems. Which is appropriate depends on architecture and deployment considerations. The RESTful API also supports Asynchronous Use and GraphQL.

3.0.1.2 Messaging

In addition to the RESTful API, a messaging exchange framework is documented, which 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.

Implementers should note that the messaging framework is not provided to fill any functional deficiency in the RESTful API (or vice versa), these frameworks are provided to allow implementers to choose how to exchange content based on their own architectural and deployment considerations. Messaging may be more suitable for exchange between disparate organizations with low levels of process integration and/or trust.

3.0.1.3 Documents

This specification also defines a document based exchange framework, where content to be exchanged is wrapped by a Composition that provides the context of the content, and that has a fixed presentation for a human reader. The document framework is provided to help with computer-assisted human to human communication uses - which are not uncommon in healthcare.

Typically, exchanging documents is associated with exchanging clinical information across clinical governance borders, while data-based exchange using the RESTful API is appropriate within where there are well established clinical governance arrangements.

3.0.1.4 Services / SOA

In addition, this specification describes the use of FHIR in a services framework(e.g. a SOA). Note that any use of any of the above approaches in production is a 'service' by some or many definitions. The services description provides context regarding the use of FHIR (and particularly the RESTful API) in a wider enterprise architecture.

3.0.1.5 Database / Persistent Store

Another way to make use of the resources defined by FHIR is to store them natively in a database or persistent store, where different applications or modules write and read the resources as part of their implementation. Using resources in this fashion is described here.

3.0.1.6 Subscriptions Framework

The Subscriptions Framework can be used to establish proactive event notifications from a FHIR application to another system. Applications which have implemented support for Subscriptions will advertise their use via the resources Subscription and SubscriptionTopic. Operations allowed on these resources may be discovered via the FHIR Application's CapabilityStatement.

3.0.2 Security and Privacy

All forms of data exchange should be appropriately secured. This requires the following:

• Only the parties to the exchange can access the communication
• The parties are authenticated and authorized as required
• Access control always checks that the only the appropriate data is exchanged
• Appropriate patient consent has been obtained for the exchange

This subject is described further in the Security Page.

With regard to the RESTful API, implementers should always consider the Smart App Launch protocol as part of the overall secure API approach

3.0.3 Developmental Roadmap