This wiki has undergone a migration to Confluence found Here
Difference between revisions of "FHIR Principles"
Jump to navigation
Jump to search
Ewoutkramer (talk | contribs) (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 ...") |
Ewoutkramer (talk | contribs) |
||
Line 5: | Line 5: | ||
* 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 | ||
− | * | + | * 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== |
Revision as of 15:36, 29 August 2012
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