This page is part of the FHIR Specification (v3.0.2: STU 3). The current version which supercedes this version is 5.0.0 . For a full list Continuous Integration Build of available versions, see FHIR (will be incorrect/inconsistent at times).
See the Directory of published versions . Page versions: R5 R4B R4 R3

Responsible Owner: Work Group FHIR Infrastructure

Ballot Standards Status : Informative

2.0 Foundation Module

The Foundation Module is responsible for the overall infrastructure of the FHIR specification. Every implementer works with the content in the foundation module however whichever way they use FHIR.

The Foundation Module maintains most of the basic documentation for the FHIR specification. In addition, the Foundation Module includes the following resources:

Foundation Framework Resource DomainResource Basic Binary Bundle Media

Content Management Resources. Questionnaire QuestionnaireResponse List Composition DocumentReference DocumentManifest

Data Exchange Resources. OperationOutcome Parameters Subscription MessageHeader SubscriptionStatus MessageDefinition SubscriptionTopic MessageHeader

2.0.1 Relationships with other modules

• All the other modules depend on the foundation module
• The Linked Data Exchange module builds on the foundation model by adding RDF representations, and strengthening defining the definitions by facilitating linkage to external ontologies recognized methods for exchange of resources
• 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 Developmental Roadmap 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 its own strengths and weaknesses.

Most implementers Several components of the foundation module have now reached normative status. The focus on RESTful API . This is a client/server API designed to follow over the principles next 18-24 months as the 6th release of RESTful design 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 FHIR is appropriate depends on architecture and deployment considerations. 2.0.2.2 Messaging In addition to the RESTful API, a messaging exchange framework prepared is documented, which supports exchange between systems by exchanging content by sending routed messages from system to system. This exchange can be implemented focus 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 of the RESTful API (or vice versa), these frameworks are provided to allow implementers to choose how to exchange content based on their own architectural non-normative elements and deployment considerations. 2.0.2.3 Documents This specification also defines a document based exchange framework , where content to move them towards normative status, such as Questionnaire, List, DocumentReference and Subscription. Exactly which resources will be exchanged is wrapped candidates for normative release will be driven, in part, by a Composition that provides the context degree of the content, implementation - and whether that has a fixed presentation for a human reader. The document framework implementation is provided to help with computer-assisted human communicated back to human communication uses - which are not uncommon in healthcare. HL7.

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 These resources are well established clinical governance arrangements. stable, normative, and widely used. No additional scope or features have been proposed:

• 2.0.2.4 Resource Services / SOA
• DomainResource In addition, this specification describes the use of FHIR in a services framework
• Binary (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.
• Bundle 2.0.3 Developmental Roadmap
• Parameters
• OperationOutcome

Much of the foundation module is well advanced through the maturity model process. Specifically, the following parts of the specification: These resources have been widely used, and are considered stable, but some new features are still in trial:

• Element / Resource + ElementDefinition Questionnaire
• The XML , & JSON QuestionnaireResponse formats
• Many of the Data Types List
• The RESTful API + Search DocumentReference (note that here have been significant redesigns in this version).

These resources have been used, and the use led to a significant redesign that is undergoing trial use:

• Subscription :
• Binary , Bundle , OperationOutcome & Parameters SubscriptionStatus :
• SubscriptionTopic :

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 artifacts to normative status. However, some parts of the foundation module are not as well explored, and are These resources have not as far advanced with regard to their development. Specifically Documents , Messaging and Services been widely used:

• Basic are areas (note that still need further testing with regard to interoperability. HL7 expects to focus on testing these things in connectathons over the next 18 months. no additional requirements have been identified since R2)
• MessageHeader