Fundamental Principles of FHIR
Contents
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 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 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
- DH Is 'scalable' the best term here? usually means for big things. perhaps 'flexible'?
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/terabyte EHR data dumps)
- communication frequencies (daily/weekly updates to sub-second automated device data updates)
- EK: 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 accommodate one environment that would prevent FHIR from being useful in another".
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"
- DH suggest a mention that the 80% is a guide rather than absolute, and that the extension mechanism means that the '20%' requirements can easily be accomodated
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 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 mean that training, connectathon, certification and other non-essential support services will be free.)
- wb: How about: (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 n0t 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 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"?]
- WB: What about "internet" technologies rather than "web". "web" suggests browsers, rather than broader www communications. I with Ewout agree that "web" sounds a little too dumbed down.
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, 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.
- *see 20140415_FGB_concall
