Fundamental Principles of FHIR

Category:FHIR Discussion

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.

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 appropriateness, modeling approach, preferred architecture or any other priority above implementability are unlikely to see significant adoption and thus will produce little overall benefit. That doesn't mean that other considerations can't be taken into account, only that implementability must remain the primary objective.

GG: Discussion with Bo - we need to clarify what we mean by "implementers"

FHIR provides a scaleable framework for interoperability

FHIR must work in a wide variety of environments and must be able to adapt as a given implementers needs change

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)
• data loads (sms communication in the developing world to gigabyte/terrabyte EHR data dumps)
• communication frequencies (daily/weekly updates to sub-second automated device data updates)

[This doesn't tell me how this principle influences design decisions. I think I'd add something like: "As a result, no design decisions should be made to accomodate one environment that would prevent FHIR from being useful in another". EK]

FHIR keeps complexity where it belongs

FHIR must support the breadth and edge cases of healthcare 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 80% of implementers"

Rationale: Healthcare 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.

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 helpful in volunteer-led initiatives and support the open engagement and evolution needed in the standards process

FHIR is free

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 mean that training, connectathon, certification and other non-essential support services will be free.)

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 aren't freely available. Interoperability standards benefit from a network effect - the more broadly they're 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 web technologies

FHIR uses HTTP, Atom, OAuth and other technologies used in web-based solutions such as Facebook, Google, Twitter, etc.

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 FHIR rather than technical issues common to other industries

[EK: does this really have to be "web"? Don't we mean "commonly used" or "modern". Or is FHIR really tied to the "web"?]

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. Both CDA and V3 messaging suffer from a lack of inter-version compatibility at the wire level and we don't want to repeat that mistake.

[EK: This puts us in a hard and difficult place, compared to Facebook and Twitter, who can upgrade their interfaces at will (but keeping older versions around for some time before they phase out). This will seriously influence our ability to adapt to change without having to resort to awkward solutions to remain forward AND backward compatible. In my opinion, this principle is unmaintainable]

Support tooling requirements are mainstream and minimal

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

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

• see 20140415_FGB_concall