Difference between revisions of "FHIR Profiling Best Practices"
| Line 15: | Line 15: | ||
*conditional situations, invariants | *conditional situations, invariants | ||
*conformance "dimensions": essentiell, desired, conditional, optional | *conformance "dimensions": essentiell, desired, conditional, optional | ||
| + | *V2/V3: mandatory M, required R, required but may be empty R2, conditional C, optional O | ||
Revision as of 14:20, 13 May 2015
Contents
Introduction
(from FHIR gForge comment 7786) In addition to better "how-to" documentation on profiling, FHIR should provide guidance on best practices for profiling. There are many strategic and practical issues that are completely up in the air. For example: What standards should be followed in terms of profile naming? For URIs? When should a user specify an extension in the profile, versus at the resource level, or at the global level? Should profiles re-use structures such as extensions and bindings from other profiles sets? When should profiles profile other profiles? What should profiles in terms of constraining resource references? In what ways can different profiles relate to each other in terms of conformance, and what are the consequences? Since every developer needs to create or consume profiles, this is extremely important.
Profile Naming Conventions
URI Conventions
Specify extension in the profile, versus at the resource level, global level
Use of "mustSupport" in profiles
(probably a table is useful here to explain the real-world situation in the facets of the following suggested items
- sender and receiver behavior,
- cardinality
- mustSupoort
- conditional situations, invariants
- conformance "dimensions": essentiell, desired, conditional, optional
- V2/V3: mandatory M, required R, required but may be empty R2, conditional C, optional O
