This page is part of the FHIR Specification (v1.8.0: STU 3 Draft). 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 R3

2.5 FHIR Overview - Architects

FHIR Infrastructure Work Group

Maturity Level: N/A

Ballot Status: STU 3

At its core, FHIR contains two primary components:

1. Resources - a collection of information models that define the data elements, constraints and relationships for the “business objects” most relevant to healthcare. From a model-driven architecture perspective, FHIR resources are notionally equivalent to a physical model implemented in XML or JSON. See the formal definition.
2. APIs – a collection of well-defined interfaces for interoperating between two applications. Although not required, the FHIR specification targets RESTful interfaces for API implementation. See details on FHIR RESTful interfaces.

In the healthcare domain, the set of “business objects” is not universally defined, but there is a notional and ongoing evolutionary, consensus-based process for standardizing on a core set of common business objects including things like “a patient”, “a procedure”, “an observation”, “an order”, etc. (see a list of defined resources). The FHIR specification provides a framework for defining these healthcare business objects (“resources”), for relating them together in a compositional manner, for implementing them in a computable form, and for sharing them across well-defined interfaces. The framework contains a verifiable and testable syntax, a set of rules and constraints, methods and interface signatures for “FHIR-aware” APIs, and specifications for the implementation of a server capable of requesting and delivering FHIR business objects.

From an operational perspective, HL7’s internal standards development and governance processes determine what constitutes a resource and which resources exist. However, the FHIR specification also provides a mechanism for contextualizing resources for specific needs within specific bounds (see Profiling Resources).

2.5.1 Architecture Frameworks and FHIR Alignment

FHIR resources fit firmly within the information architecture domain and the FHIR APIs for data exchange address aspects of application architecture.

2.5.2 FHIR and Architectural Principles

FHIR’s primary purpose is to address interoperability with well-structured, expressive data models and simple, efficient data exchange mechanisms. In addition, FHIR aligns to the following architectural principles:

1. Reuse and Composability – FHIR resources are designed with the 80/20 rule in mind – focus on the 20% of resources that satisfy 80% of the interoperability needs. To this end, resources are designed to meet the general or common data requirements of many use cases to avoid the proliferation of numerous, overlapping and redundant resources. Extension and customizations exist (see FHIR Profiles) to allow common, somewhat generic resources to be adopted and adapted as needed for specific use case requirements. In addition, FHIR resources are highly composable in that resources are commonly composed of other resources. This further promotes reuse and allows for complex resources to be built from more atomic resources.
2. Scalability – Aligning FHIR APIs to the REST architectural style ensure that all transactions are stateless which reduces memory usage, eliminates the needs for “sticky” sessions within a server farm and therefore supports horizontal scalability.
3. Performance – FHIR resources are lean and optimized for exchange across the network. This has the potential to improve performance in complex transactions across multiple systems connected via a shared and finite network.
4. Usability – FHIR resources are understood by technical experts and non-technical people alike. Even if the details of XML or JSON syntax are not understood, non-technical people can view these in any browser or text reader and understand the contents within them.
5. Data Fidelity – FHIR is strongly typed and has mechanisms built in for clinical terminology linkage and validation. In addition, XML and JSON documents can be validated syntactically as well as against a defined set of business rules. This promotes high data fidelity and goes a long way towards using FHIR to achieve semantic interoperability.
6. Implementability – One of the driving forces for FHIR is the need to create a standard with high adoption across disparate developer communities. FHIR is easily understood and readily implemented using industry standards and common mark-up and data exchange technologies.

There are additional architecture principles related to consistency, granularity, referential integrity, and others that are not as well established or proven. See the section below on Outstanding Issues for details.

2.5.3 FHIR Decomposition

As discussed, FHIR’s principle components are resources and RESTful APIs. However, there is more to the FHIR specification including the components depicted below.

NOTE: The term “component” is used loosely to mean a part of something and does not intend to carry the specific meanings for this term provided by rigorous ontologies, modeling frameworks, or other architectural and organizational constructs. Diagrammatically, the components below are depicted below as UML classes. This is done purely to take advantage of the semantics afforded using this notation. FHIR is neither objected oriented in its modelling approach not are the component that make up the FHIR specification UML classes or objects in the formal sense. Likewise, the UML packages shown below are notional and used for organizational purposes only.

As shown in the diagram below, it is convenient to think of the FHIR specification as having components that address the following:

• Information Model – the components of FHIR related to the creation of FHIR resources
• Constraints – the components of FHIR addressing constraints and validity
• Terminology – the components of FHIR related to clinical terminologies and ontologies
• Usage – the component of FHIR addressing the use of FHIR in a run-time capacity

Component definitions:

• FHIR Information Model
  • Base Clases: Element and Resource
  • Definitions for Base Classes: ElementDefinition and StructureDefinition
  • Data Types
• FHIR Conformance Model
  • Capability Statement
  • Profile
• FHIR Terminology
  • Code System
  • Value Set
• FHIR Usage
  • REST API

2.5.4 Organizing FHIR Resources

It is impractical to model the entirety of health data in a single information model. Every modeling initiative in healthcare from HL7 version 2 message specifications, to the CIMI clinical models, to the domains within the FHIM, to FHIR resources decomposes the healthcare domain into smaller, more manageable sub-domains or information model snippets. With FHIR, each resource is essentially a snippet of the larger healthcare information domain. With this approach, it is important to have a framework or set of guidelines in place to assemble the snippets to reconstitute the business domain when needed and to ensure that the snippets are logically congruent with each other.

To this end, FHIR has an informative (non-normative) part of the specification that describes how to organize FHIR resources into logical packages or sub-domains in a manner that promotes the reuse and consistency of resources such that they can be assembled to reconstitute the health data domain in a logical, non-duplicative, unambiguous and non-conflicting manner. The fact that there is not a normative framework and set of constraints in place to guarantee this speaks to more to the variability that exists in healthcare practice today than it does to the ability of the FHIR specification to define such rules. See the section below on Outstanding Issues for more on this topic.

The non-normative information model organization framework currently in place for suggesting how resources should be organized relative to each other can be found on the FHIR Resource Considerations page .

Another useful tool for visualizing how FHIR resources are organized relative to each other can be found using the Resource Reference Visualization tool on clinFHIR .

2.5.5 FHIR Implementation – High-Level Design Considerations

2.5.5.1 FHIR Servers and the FHIR APIs

A FHIR REST server is any software that implements the FHIR APIs and uses FHIR resources to exchange data. The diagram below describes the FHIR interface definitions. The methods are classified as:

• iServeInstance – methods that perform Get, Put or Delete operations on a resource
• iServeType – methods that get type information or metadata about resources
• iServeSystem – methods that expose or enable system behaviors.

Additional details on the FHIR APIs can be found at the FHIR RESTful Api and the Operations Framework.

2.5.5.2 FHIR Transactions

As mentioned, FHIR resources are optimized for stateless transactions with RESTful APIs. Although this is not the only way FHIR resources can be used, these types or transactions are the only ones with defined interfaces and behaviors in the FHIR specification.

FHIR transactions follow a simple request and response transaction pattern. The request and response can be for be for a single payload or can operate as batch. The payload or a request and response consists of a header and the content of interest. See diagram below for details.

2.5.5.3 Security

(section to be filled out) (but see Security in the meantime).

Example Use Cases Using FHIR

For illustrative purposes, the following diagram depicts a simple use case of a patient accessing their personal health record (portal) enabled by an underlying electronic medical record (EMR) system. The EMR plays the role of the FHIR server in this example.

The pre-conditions for this use case are:

• the EMR implements the necessary FHIR APIs
• the EMR implements the necessary authentication and authorization mechanisms
• the patient is successfully authenticated and authorized to access FHIR resources

The basic flow of the use case is that the patient registers (if required), logs in, enters search criteria to identify a patient or patients of interest (the patient is most like themselves in this use case), retrieves clinical documents for the patient and retrieves clinical resources for the patient. The use cases utilizes the GET methods on the iServeInstance interface and works with the following types of FHIR resources:

• The Patient resource
• One or more document resource(s)
• One or more clinical resource(s)

Although this example use case is very simple, more complex transactions using a combination of GETs, PUTs and DELETEs against resources and metadata can be envisioned. However, the exact details of these use cases including which methods are used, the orchestration of methods and the specific resources involved are outside the scope of the FHIR specification.

2.5.6 Outstanding Issues

• Resource Consistency and Granularity – there is nothing intrinsically prohibiting one resource from duplicating the same information as another resource. Further, there is nothing prohibiting resources with the same information from defining and modeling the data elements differently. HL7 has a number of processes to ensure that resources are consistently designed, but the question is when to be consistent within the specification, and when to be consistent with the real world practices of healthcare - these are sometimes in conflict with each other. Resource granularity is a related potential problem as there are variations in the size, complexity and comprehensiveness of the existing resources.
  Further, the degree to which the FHIR specification can impose consistency is limited to how much agreement can be gained across various communities. While the Implementers Safety Check List and the Considerations for FHIR Resource Considerations provide guidance and promote consistency, rules for achieving complete consistency of both content and granularity amongst resources are neither completely defined nor completely enforced. Considering that FHIR is still a new and emerging standard, an over-abundance of constraint and rigor has been avoided to maximize initial adoption. Further, there is a natural tension between consistency and an architectural virtue and the practicalities of supporting the real practice of health care. Considering that FHIR ultimately is a reflection of the health business processes it supports, FHIR will always carry forward some of the data discrepancies, inconsistencies and gaps that are present in the practice of healthcare across different organizations and practitioners. Nonetheless, the issues of resource consistency and granularity is a topic that gets considerable ongoing discussion, and may change as FHIR approaches a final normative standard and as FHIR adoption approaches a level where more control is warranted, or a more information/process consistency emerges in the existing healthcare systems.
• Resource References – there are currently a lack of strict rules for what resources should be referenced by other resources and under what circumstance. There is potential for ambiguity, duplication, inaccurate and/or conflicting information communicated by a resource graph (a collection of linked resources). Imagine the scenario where Resource A (e.g., procedure) references Resource B (e.g., encounter) and Resource C (e.g., patient), and Resource B (e.g., encounter) also references Resource C (e.g., patient). In this scenario, is the reference to Resource A to Resource C meant to provide the same information as the reference from Resource B to Resource C? If so, is this duplication of information problematic? Note that this is not unique to FHIR - it is an innate property of information systems. If the references to Resource C are actually to different instances of Resource C, how does the system know that the references are intentionally different versus an error or data anomaly? The problem is that there is limited ability to describe the intent of the reference which leads to the possibility of ambiguity and error. The Linkage resource can be used to help with this problem, but additional capabilities may be considered in the future to allow systems to address referential integrity.
• Conditional Semantics – Currently, the constraints for element definitions including things like data types, value sets, optionality and cardinality are defined at design time with limited consideration for variable run-time semantics. Imagine the scenario where the value of Data Element Y (e.g., “intolerance type”) is constrained differently depending on the value of Data Element X (e.g., “causative agent”) in a given instance of a resource. For example, if the instance of an Intolerance Resource has the “intolerance type” data element populated with “food intolerance”, then “causative agent” should be constrained to only valid values for this value set (e.g., valid foods instead of medications or environmental agents). Tools for addressing deep semantic consistency in this regard are only gradually developing.
• Business Rule Enforcement and Validation – As governance increases and more resource rules are defined, it may be advantageous to have a resource validation tool that checks for things like resource consistency, duplication, referential integrity, circular or non-sensical references, and other defined and approved validation rules. Once rules are agreed to, this level of automation can help address the other issues outlined above. These kind of faciliities are planned for the future.