Difference between revisions of "Fundamental Principles of FHIR"
| Line 6: | Line 6: | ||
See Also [[FHIR Governance Precepts]] for early FGB start at a precepts spread sheet | See Also [[FHIR Governance Precepts]] for early FGB start at a precepts spread sheet | ||
| − | + | =Scope and Priorities= | |
==FHIR prioritizes implementation== | ==FHIR prioritizes implementation== | ||
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 14: | Line 14: | ||
==FHIR provides a scaleable framework for interoperability== | ==FHIR provides a scaleable framework for interoperability== | ||
(Need caveats around what scalablility means and framework) | (Need caveats around what scalablility means and framework) | ||
| + | |||
| + | ==FHIR supports the breadth and edge cases of healthcare while keeping the common things simple== | ||
| + | FHIR generally follows the [http://en.wikipedia.org/wiki/Pareto_principle Pareto principle] in that the core FHIR standard will be 20% of the size of Version 3 but will standardize the most-common 80% of healthcare data, workflow, and related challenges. The remaining 20% represent more realm- or speciality-centric issues. | ||
| + | |||
| + | =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". ([http://en.wikipedia.org/wiki/Open_Collaboration from]) | ||
==FHIR is free== | ==FHIR is free== | ||
| Line 20: | Line 28: | ||
'''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. | '''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 Dependency= | |
| − | |||
| − | |||
==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. | ||
| Line 32: | Line 38: | ||
Versioning gets managed at the conformance level | Versioning gets managed at the conformance level | ||
| − | (LLOYD (or someone | + | (LLOYD (or someone): I (Woody) find it difficult to express the "goodness" of this principle. Need others to wordsmith) |
==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. | 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 11:36, 20 May 2014
Precepts are (Ron - insert language explaining precepts here)
See also Establishing Precepts in HL7
See Also FHIR Governance Precepts for early FGB start at a precepts spread sheet
Contents
Scope and Priorities
FHIR prioritizes implementation
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
(Need caveats around what scalablility means and framework)
FHIR supports the breadth and edge cases of healthcare while keeping the common things simple
FHIR generally follows the Pareto principle in that the core FHIR standard will be 20% of the size of Version 3 but will standardize the most-common 80% of healthcare data, workflow, and related challenges. The remaining 20% represent more realm- or speciality-centric issues.
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)
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 Dependency
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.
FHIR leverages web technologies
HOW IS THIS DIFFERENT from the item above??
FHIR makes versions transparent at the instance level
Versioning gets managed at the conformance level
(LLOYD (or someone): I (Woody) find it difficult to express the "goodness" of this principle. Need others to wordsmith)
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.
