FHIR Principles

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