2.0.1 Relationships with other modules

• All the other modules depend on the foundation module
• The Linked Data module builds on the foundation model by adding RDF representations, and strengthening the definitions by facilitating linkage to external ontologies
• The Terminology module provides the formal basis for using Concepts defined in Code Systems in the definitions
• The Conformance module provides the basis for extending the foundation for national and local use
• The Security & Privacy provides the linking framework to external standards for security and privacy
• The Implementation Support module builds on the foundation to provide testing and reference implementations

2.0.2 Common use Cases: Exchanging Data

FHIR supports 4 different paradigms for exchange: the RESTful API, Messaging, Documents, and Services. Each of these approaches can be used to exchange information, and each has it's own strengths and weaknesses.

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

2.0.2.2 Messaging

In addition to the RESTful API, a Messaging exchange framework is documented, which supports exchange between systems by exchanging content by sending routed messages from system to system. This exchange can implemented on the RESTful API, or using some other messaging stack. The messaging paradigm is provided to support implementers who wish to use such a messaging paradigm.

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.

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

2.0.2.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 alternatives 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.

2.0.3 Developmental Roadmap

Much of the foundation module is well advanced through the maturity model process. Specifically, the following parts of the specification:

• Element / Resource + ElementDefinition
• The XML, & JSON formats
• Many of the Data Types
• The RESTful API + Search
• Binary, Bundle, OperationOutcome & Parameters

The focus over the next 18 months or so as the 4th release of FHIR is prepared is to focus on stability and move these artefacts to normative status. However some parts of the foundation module are not as well explored, and are not as far advanced with regard to their development. Specifically Documents, Messaging and Services are areas that still need further testing with regard to interoperability. HL7 expects to focus on testing these things in connectathons over the next 18 months.