Fundamental Principles of FHIR

Content on this page has been migrated to https://confluence.hl7.org/display/FHIR/Fundamental+Principles+of+FHIR

(aka The FHIR Code)

Introduction

The following is an assertion of the Fundamental Principles and objectives that are driving the definition, development, expression and Implementation of FHIR. As such, they provide the foundation on which specific Governance Precepts are defined to permit management of the FHIR processes within HL7. As the FHIR methodology continues to evolve, decisions on changes will be based on maximizing adherence to these principles.

FHIR Scope and Priorities

FHIR prioritizes implementation

Implementers are the target consumers of the specification. Implementability is the primary consideration in all specification design decisions.

This is the most fundamental precept of FHIR. Most other principles and precepts exist to support this objective.

Rationale: Standards that don't get implemented (or are implemented poorly) benefit no-one. Standards that place theoretical correctness, clinical perfection, modeling approach, preferred architecture or any other priority above implementability are unlikely to see significant adoption and thus will produce little overall benefit. That does not mean that other considerations can not be taken into account, only that implementability must remain the primary objective.

FHIR provides a flexible framework for interoperability

FHIR must work in a wide variety of environments and must be able to adapt as a given implementers needs change. Therefore, design decisions should not be made to accommodate one environment that would prevent FHIR from being useful in another.

Rationale: FHIR seeks to address a wide range of interoperability spaces including varying:

• environment (within a small clinic to across a country or around the world)
• implementation environments (institutional, community, home health, etc.)
• architectures (centralized/distributed, open/closed, tight/loose, etc.)
• data loads (SMS communication in the developing world to gigabyte/terabyte EHR data dumps)
• communication frequencies (daily/weekly updates to sub-second automated device data updates)

FHIR keeps complexity where it belongs

FHIR must support the breadth and edge cases of health care which sometimes involve considerable complexity, however it strives to do this without causing that complexity to manifest in the simple scenarios. Part of this is addressed using the 80% principle

"the core specification only includes those elements used by approximately 80% of implementers - other elements are handled using extensions"

In addition, FHIR will tend to impose additional complexity on servers rather than clients.

Rationale: Health care has many diverse needs driven by different disciplines, regulatory environments, types of patients, etc. Some of these can get quite complex. FHIR must support this range of needs in order to be useful. However, if even simple things become complicated to implement, the usefulness of the standard diminishes considerably.

Servers are typically better able to handle complexity and there will typically be many more clients than servers. (Thus imposing complexity in servers will result in less cost to the overall implementation environment)

FHIR supports but does not mandate tight specifications

The base FHIR specification is minimalist in defining conformance requirements to maximize flexibility in approach and architecture. However, FHIR provides the mechanisms to define specifications on top of the base specification that set conformance requirements with varying degrees of tightness, reflecting the needs of particular specifications and use-cases.

Rationale: Different implementation environments have a variety of requirements in terms of "tightness". FHIR must allow the definition of both highly rigorous and highly flexible specifications.

Open Development and Implementation Communities

FHIR leverages open source development principles

Participation in the development, support and standardization has and should continue to involve an array of volunteers, not all of whom will be HL7 members, who participate because they believe that FHIR provides value to both themselves and to the international health care community. More formally,

Open Collaboration is "any system of innovation or production that relies on goal-oriented yet loosely coordinated participants, who interact to create a product (or service) of economic value, which they make available to contributors and non-contributors alike". (from)

Rationale: These principles have proven extremely valuable in volunteer-led initiatives and support the open engagement and evolution needed in the standards process

FHIR is free to use

All information that is essential to developing and implementing systems that can communicate using FHIR should be available to all interested parties without cost.

(This does not preclude charging for non-essential support services such as training, connectathons, and certification.)

Rationale: FHIR is a standard that supports interoperability in spaces within which HL7 has not traditionally been involved. As a result, many of those who will need the standard are not members, and would be unlikely to become members in order to see if FHIR is relevant/right for them. As well, many implementers and governmental projects are reluctant to make use of standards that are not freely available. Interoperability standards benefit from a network effect - the more broadly they are supported, the more useful they are.

FHIR Technology and Dependencies

FHIR supports multiple exchange paradigms/architectures

The continuing evolution of computing and communications technology demands that standards such as FHIR are flexible and capable of being implemented in those technologies selected by the implementers. This variety includes approaches to security, transport, and persistence, and can make use of REST/Documents/Messaging/Services, etc.

Rationale: Different architectural approaches are appropriate in different circumstances. In addition, some implementers may be driven to particular approaches due to legacy, familiarity or for other reasons.

FHIR leverages common web technologies

FHIR takes advantage of HTTP, REST, OAuth and other technologies used in web-based services such as Amazon, Google, Twitter, etc. where possible rather than developing custom solutions.

Rationale: Web-based technologies are well understood and widely supported by the implementation community. Leveraging them allows FHIR to focus on the unique aspects of health care rather than technical issues common to other industries

FHIR is forward and backward compatible

FHIR will strive for version transparency - knowledge of the version of an instance will not be essential to safe interoperability

Rationale: Non-inter-version compatibility is a significant barrier to interoperability. The durability of V2 is largely derived from its adherence to a backwards and forwards compatibility premise. Both CDA and V3 messaging suffer from a lack of inter-version compatibility at the wire level and we do not want to repeat that mistake.

Tooling requirements are mainstream and minimal

As much as possible, FHIR specifications will be designed, published and implemented using off-the-shelf (and free) tooling.

Rationale: Easy implementability of FHIR derives in part from a suite of reference implementations, and from the expression of the specification in "processable" artifacts. For these characteristics to be sustained, the tools used by the developers and implementers must be current, mainstream technologies with little additional "baggage" when they are adopted.