This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "FHIR Principles"

From HL7Wiki
Jump to navigation Jump to search
(Created page with "Fast Healthcare Interoperability Resources (FHIR) defines a set of resources for use in exchanging information about the healthcare processes. ==Resources== * Are the smallest ...")
 
 
(2 intermediate revisions by 2 users not shown)
Line 1: Line 1:
Fast Healthcare Interoperability Resources (FHIR) defines a set of resources for use in exchanging information about the healthcare processes.  
+
NOTE: This has been superseded [[Fundamental Principles of FHIR]]
 +
 
 +
 
 +
Fast Healthcare Interoperability Resources (FHIR) defines a set of resources for use in exchanging information about the healthcare  
 +
processes.  
  
 
==Resources==
 
==Resources==
Line 5: Line 9:
 
* Can be managed and understood in isolation: its data can be understood without requiring other referenced resources or context
 
* Can be managed and understood in isolation: its data can be understood without requiring other referenced resources or context
 
* Are useable, without alteration, in RESTful environments, classic message exchanges, human-centric clinical documents and enterprise SOA architecture
 
* Are useable, without alteration, in RESTful environments, classic message exchanges, human-centric clinical documents and enterprise SOA architecture
* Resources should be very common and useable in many different business transactions and be applicable for a wide spectrum of users and nationalities
+
* Should be very common and useable in many different business transactions and be applicable for a wide spectrum of users and nationalities
 
* Should differ from each other in meaning, not just in usage
 
* Should differ from each other in meaning, not just in usage
 
* Should be non-overlapping
 
* Should be non-overlapping
 
* Need to have a natural identity
 
* Need to have a natural identity
* Can have a lifecycle of its own, but should not tie concepts together that have independent life cycles.  
+
* Can have a lifecycle of its own, but should not tie concepts together that have independent life cycles.
  
 
==Attributes==
 
==Attributes==
Line 21: Line 25:
 
* Focus publication on documenting what the implementer needs, not what the modelers thought or designers need to remember
 
* Focus publication on documenting what the implementer needs, not what the modelers thought or designers need to remember
 
* Designs the physical, not the abstract
 
* Designs the physical, not the abstract
 +
 +
 +
Lloyd: I think the above are design principles or guidelines rather than "Core Principles".  Here's my take on Core Principles (not to be confused with the MnM doc of the same name):
 +
* <b>Implementation focused:</b> All other things being equal, FHIR will adopt the approach that will make implementation easiest for the largest portion of the potential implementation community
 +
* <b>Succinct:</b> FHIR will keep documentation as simple as possible while still providing the detail needed for safe interoperability
 +
* <b>Poly-paradigm:</b> FHIR will support REST, messaging, document & services paradigms using the same set of structures
 +
* <b>80% elements:</b> FHIR will directly support only those elements used by (or expected to be used by) 80% of implementers, everything else is handled as extensions.
 +
* <b>99% of domain:</b> FHIR will cover the domain space of 99% of healthcare implementations
 +
* <b>Minimal tooling:</b> FHIR will avoid dependency on complex and non open-source tooling as much as possible

Latest revision as of 01:31, 17 September 2014

NOTE: This has been superseded Fundamental Principles of FHIR


Fast Healthcare Interoperability Resources (FHIR) defines a set of resources for use in exchanging information about the healthcare processes.

Resources

  • Are the smallest unit of interchange and have a fixed and clear boundary
  • Can be managed and understood in isolation: its data can be understood without requiring other referenced resources or context
  • Are useable, without alteration, in RESTful environments, classic message exchanges, human-centric clinical documents and enterprise SOA architecture
  • Should be very common and useable in many different business transactions and be applicable for a wide spectrum of users and nationalities
  • Should differ from each other in meaning, not just in usage
  • Should be non-overlapping
  • Need to have a natural identity
  • Can have a lifecycle of its own, but should not tie concepts together that have independent life cycles.

Attributes

  • Resources contain only those attributes that are relevant to 80% of the implementers.
  • Allow easy extension for the remaining 20% of elements
  • Should only repeat if 80% of implementers will need repetitions
  • Should only be “mandatory” if the resource would be unusable without the data element present

FHIR

  • Uses open internet standards where possible or appropriate
  • Focus publication on documenting what the implementer needs, not what the modelers thought or designers need to remember
  • Designs the physical, not the abstract


Lloyd: I think the above are design principles or guidelines rather than "Core Principles". Here's my take on Core Principles (not to be confused with the MnM doc of the same name):

  • Implementation focused: All other things being equal, FHIR will adopt the approach that will make implementation easiest for the largest portion of the potential implementation community
  • Succinct: FHIR will keep documentation as simple as possible while still providing the detail needed for safe interoperability
  • Poly-paradigm: FHIR will support REST, messaging, document & services paradigms using the same set of structures
  • 80% elements: FHIR will directly support only those elements used by (or expected to be used by) 80% of implementers, everything else is handled as extensions.
  • 99% of domain: FHIR will cover the domain space of 99% of healthcare implementations
  • Minimal tooling: FHIR will avoid dependency on complex and non open-source tooling as much as possible