FHIR Release 3 (STU) Current Build
Work Group FHIR Infrastructure Ballot Standards Status : Informative

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

Content Management Resources.

Data Exchange Resources.

  • 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 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. 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 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. 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 be 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.

Much Several components 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 have now reached normative status. The focus over the next 18 18-24 months or so as the 4th 5th 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, non-normative elements and are not move them towards normative status, such as far advanced with regard to their development. Specifically Documents , Messaging Questionnaire, List, DocumentReference and Services are areas that still need further testing with regard to interoperability. HL7 expects to focus on testing these things Subscription. Exactly which resources will be candidates for normative release will be driven, in connectathons over part, by the next 18 months. degree of implementation - and whether that implementation is communicated back to HL7.