Release 4 5

This page is part of the FHIR Specification (v4.0.1: R4 (v5.0.0: R5 - Mixed Normative and STU ) ). This is the current published version in it's permanent home (it will always be available at this URL). 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 icon 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:

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 icon for C reate, R ead, U pdate and D elete operations, along with S earch and E xecute (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. 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 icon protocol as part of the overall secure API approach

3.0.3 Developmental Roadmap

RESTful API This is stable and currently being balloted mostly published as Normative. Normative (see Note about normative status ). No breaking changes are expected. No significant development is planned, but HL7 will continue to respond to user experience
Messaging Messaging has only be been implemented in a few projects; some of the infrastructure has not yet been used in production. It is not clear whether significant development will be needed or appropriate
Documents Documents have mostly only been used in prototype projects, though there is considerable impetus around implementation at this time. No significant development is planned, but HL7 will continue to respond to user experience
Services At this point in time, it's not clear whether further work is required or appropriate in terms of service orientated architecture / enterprise integration. HL7 will continue to monitor implementer experience and feedback
Database / Persistent Storage This is a new area with considerable action at this time, and many production implementations, though RDF itself is not getting much use. At this time, HL7 is monitoring implementer experience and feedback to see whether additional standardization is required
Trial-Use Note: Note to balloters: There's some interest in standardizing the use of ProtocolBuffers directly in the specification itself ( basis ). Ballot comments are welcome.