Difference between revisions of "Fundamental Principles of FHIR"
| Line 5: | Line 5: | ||
=FHIR Scope and Priorities= | =FHIR Scope and Priorities= | ||
==FHIR prioritizes implementation== | ==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. | This is the most fundamental precept of FHIR. Most other principles and precepts exist to support this objective. | ||
| Line 10: | Line 12: | ||
==FHIR provides a scaleable framework for interoperability== | ==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 | |
| − | FHIR seeks to address | + | '''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) | ||
| − | ==FHIR | + | ==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= | =Open Development and Implementation Communities= | ||
| Line 21: | Line 31: | ||
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, | 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". ([http://en.wikipedia.org/wiki/Open_Collaboration from]) | :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". ([http://en.wikipedia.org/wiki/Open_Collaboration 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== | ==FHIR is free== | ||
| Line 30: | Line 42: | ||
==FHIR supports multiple exchange paradigms/architectures== | ==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. | 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 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 | |
| − | |||
| − | + | ==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. | ||
==Support tooling requirements are mainstream and minimal== | ==Support tooling requirements are mainstream and minimal== | ||
| − | 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. | + | 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]] | *see [[20140415_FGB_concall]] | ||
Revision as of 18:56, 22 May 2014
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 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.
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)
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
Rationale: FHIR is a standard that supports interoperability in spaces within which HL7 has not traditionallybeen 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
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.
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.
